企业级容器技术 k8s 控制器

pod分类有两种一种是自主式的控制器，当pod退出后不会被创建。
另一种pod由控制器进行管理，只要控制器还活着，将pod删除之后他会自动的再创建出来。
控制器也分好多种类，具体使用环境和分类请结合官网进行查看
https://kubernetes.io/zh/docs/concepts/workloads/controllers/

ReplicaSet (rs)控制器

首先写一个资源清单，其中控制器为ReplicaSet，使用一个更为方便的镜像ikubernetes/myapp，使用这个镜像以nginx为基础，里面有一个写好的测试页，可以查看主机名更为方便。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-example
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1

资源清单编写完成，继续创建集群。

[kubeadm@server1 ~]$ kubectl create -f rs-example.yaml 
[kubeadm@server1 ~]$ kubectl get pod -o wide
NAME                       READY   STATUS    RESTARTS   AGE   IP            NODE      NOMINATED NODE   READINESS GATES
replicaset-example-29hp2   1/1     Running   0          51s   10.244.2.6    server3   <none>           <none>
replicaset-example-sfhsx   1/1     Running   0          51s   10.244.0.15   server1   <none>           <none>
replicaset-example-tjtg2   1/1     Running   0          51s   10.244.3.7    server4   <none>           <none>

这样可以看到在三个机器上已经部署完成，并且可以使用curl命令进行访问。
ReplicaSet还有维护的功能，确保每个pod都在运行，但是他是靠什么东西分辨维护什么东西呢，使用的就是标签。
我们先将pod扩容，之后对一个pod进行标签的更改。
修改完成后我们的pod由6个变为了7个，因为修改了标签不认识被修改标签的pod，所以再次创建了一个来保证6个pod正常运行。

[kubeadm@server1 ~]$ kubectl get pod --show-labels 
NAME                       READY   STATUS    RESTARTS   AGE    LABELS
replicaset-example-29hp2   1/1     Running   0          18m    app=httpd
replicaset-example-7lnml   1/1     Running   0          117s   app=nginx
replicaset-example-p2858   1/1     Running   0          40s    app=nginx
replicaset-example-q9zvk   1/1     Running   0          117s   app=nginx
replicaset-example-r2hvl   1/1     Running   0          117s   app=nginx
replicaset-example-sfhsx   1/1     Running   0          18m    app=nginx
replicaset-example-tjtg2   1/1     Running   0          18m    app=nginx

虽然rs控制器可以独立运行，但是一般还是会用deployments控制器，因为deployments控制器他有更新和回滚的功能。

首先编写一个deployments控制器的资源清单

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 6
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v2
        ports:
        - containerPort: 80
[kubeadm@server1 ~]$ kubectl apply -f deployment-example.yaml  ##应用文件
deployment.apps/nginx-deployment created
[kubeadm@server1 ~]$ kubectl get pod
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-7d6f48b859-9wq24   1/1     Running   0          7s
nginx-deployment-7d6f48b859-h6gkt   1/1     Running   0          7s
nginx-deployment-7d6f48b859-wmlwk   1/1     Running   0          7s
[kubeadm@server1 ~]$ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-7d6f48b859   3         3         3       34s

在这里其实可以发现他们的名字和前面有些区别，pod的名字构成比原来的名字多了一段，这个号码是rs也就是控制器的号码。所以他的创建顺序是：
1在每个pod节点先创建一个rs（控制器）
2然后再创建pod
3在pod中在配置容器。

但其实一开始也说了deployment控制器他的可以进行更新等操作。操作也是十分的简单直接在资源清单上进行修改，接着读取文件就好了。
再更新中我们也可以看到他的更新并不是简单的只在原来基础上进行更新，而是将原来的pod进行删除从新建立pod。从pod名称中的rs号码就可以看出来。

nginx-deployment-6f7794c6c4-v8bg5   0/1     ContainerCreating   0          2s      <none>        server4   <none>           <none>
nginx-deployment-7d6f48b859-9l64f   0/1     Terminating         0          26s     10.244.3.13   server4   <none>           <none>

我们可以查看rs来验证一下这个过程

[kubeadm@server1 ~]$ kubectl get rs

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-6f7794c6c4   3         3         3       7m20s
nginx-deployment-7d6f48b859   0         0         0       15m

这里出现了两个rs控制器，一个是空闲的，这时我们想一下更新的时侯都将pod删除了，那么为什么不将rs一并删除呢？这个答案就是为了方便回滚。当切回原先的版本，那么就会在原先的rs上直接进行建立新pod。