K8S资源控制器

什么是控制器

kubernetes中建立了很多的controller（控制器），这相当于一个控制机，来管理pod的状态和行为。

控制器的类型

ReplicationController和ReplicaSet
Deployment 无状态负载
DaemonSet 守护进程集
StateFulSet 有状态负载
Job/cronJob 普通任务/计划任务
Horizontal Pod Autoscaling 自动扩展

ReplicationController和ReplicaSet

ReplicationController（RC）是用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会创建新的pod来代替，如果异常多出来的容器也会回收；

在新版本的kubernetes中建议使用ReplicaSet来代替ReplicationController，ReplicaSet 跟ReplicationController没有本质的不同，只是ReplicaSet支持集合式的selector（通过标签来选择）；而ReplicationController不支持。

Deployment

Deployment为Pod和ReplicaSet提供了一个声明式定义（declarative）方法，用来替代以前的ReplicationController来方便管理应用，典型的场景包括：

定义deployment来创建pod和replicaset
扩容和缩容
部署无状态应用，只关心数量，不论角色等，称无状态
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新，例如只更新一个新的image

例：部署一个nginx应用

创建一个rs.ymal的文件，定义deployment来创建pod和replicaset

apiVersion: apps/v1

kind: Deployment

metadata:

  name: nginx-deployment

spec:

  replicas: 3

  selector:

    matchLabels:

      app: nginx

  template:

    metadata:

      labels:

        app: nginx

    spec:

      containers:

      - name: nginx

        image: nginx

        ports:

         - containerPort: 80

~

[root@master ~]# kubectl apply -f rs.yaml            #创建一个pod

deployment.apps/nginx-deployment created

[root@master ~]# kubectl get pods                    # 查看pod信息

NAME                                READY   STATUS              RESTARTS   AGE

nginx-6799fc88d8-d9p6h              1/1     Running             0          27m

nginx-deployment-7848d4b86f-bnvdg   0/1     ContainerCreating   0          13s

nginx-deployment-7848d4b86f-xwn6c   0/1     ContainerCreating   0          13s

nginx-deployment-7848d4b86f-zf4bh   1/1     Running             0          13s

[root@master ~]# vim rs.yaml

[root@master ~]# kubectl get pods --show-labels        #查看pod的标签

NAME                                READY   STATUS    RESTARTS   AGE     LABELS

nginx-6799fc88d8-d9p6h              1/1     Running   0          30m     app=nginx,pod-template-hash=6799fc88d8

nginx-deployment-7848d4b86f-bnvdg   1/1     Running   0          3m42s   app=nginx,pod-template-hash=7848d4b86f

nginx-deployment-7848d4b86f-xwn6c   1/1     Running   0          3m42s   app=nginx,pod-template-hash=7848d4b86f

nginx-deployment-7848d4b86f-zf4bh   1/1     Running   0          3m42s   app=nginx,pod-template-hash=7848d4b86f

[root@master ~]# kubectl get deployment

NAME               READY   UP-TO-DATE   AVAILABLE   AGE

nginx              1/1     1            1           56d

nginx-deployment   3/3     3            3           6m53s

[root@master ~]# kubectl get rs     #查看pod的rs信息

NAME                          DESIRED   CURRENT   READY   AGE

nginx-6799fc88d8              1         1         1       35m

nginx-deployment-7848d4b86f   3         3         3       8m40s

[root@master ~]# kubectl get pods -o wide            #查看pod的详细信息

NAME                                READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES

nginx-6799fc88d8-d9p6h              1/1     Running   0          39m   10.101.11.5    node2   <none>           <none>

nginx-deployment-7848d4b86f-bnvdg   1/1     Running   0          11m   10.101.149.5   node1   <none>           <none>

nginx-deployment-7848d4b86f-xwn6c   1/1     Running   0          11m   10.101.149.4   node1   <none>           <none>

nginx-deployment-7848d4b86f-zf4bh   1/1     Running   0          11m   10.101.11.6    node2   <none>           <none>

扩容或者缩容，比如我们把pod数目扩容到10个

[root@master ~]# kubectl scale deployment nginx-deployment --replicas 10

deployment.apps/nginx-deployment scaled

[root@master ~]# kubectl get pods

NAME                                READY   STATUS    RESTARTS   AGE

nginx-6799fc88d8-d9p6h              1/1     Running   0          50m

nginx-deployment-7848d4b86f-bnvdg   1/1     Running   0          22m

nginx-deployment-7848d4b86f-fjhld   1/1     Running   0          92s

nginx-deployment-7848d4b86f-nld5c   1/1     Running   0          92s

nginx-deployment-7848d4b86f-nmxlf   1/1     Running   0          92s

nginx-deployment-7848d4b86f-vmjgl   1/1     Running   0          92s

nginx-deployment-7848d4b86f-wbfbq   1/1     Running   0          92s

nginx-deployment-7848d4b86f-x86hq   1/1     Running   0          92s

nginx-deployment-7848d4b86f-xngl5   1/1     Running   0          92s

nginx-deployment-7848d4b86f-xwn6c   1/1     Running   0          22m

nginx-deployment-7848d4b86f-zf4bh   1/1     Running   0          22m

更新镜像

查看当前pod中的镜像（以nginx为例）

[root@master ~]# kubectl get pod -o wide

NAME                   READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES

web1-9d68ffd75-bnvdg   1/1     Running   0          9h    10.101.11.7    node2   <none>           <none>

web1-9d68ffd75-x86hq   1/1     Running   0          9h    10.101.149.4   node1   <none>           <none>

web1-9d68ffd75-zf4bh   1/1     Running   0          9h    10.101.149.5   node1   <none>           <none>

[root@master ~]# kubectl describe pod web1-9d68ffd75-bnvdg | grep image

  Normal  Pulled     9h    kubelet            Container image "nginx:1.21.4" already present on machine

[root@master ~]#

查看当前镜像的nginx为1.21.4版本升级1.21.5版本命令为

kubectl set image deployment web1（需要更新镜像的deployment名称） nginx=nginx：1.21.5 （新版本镜像名称） --rcode #可以记录镜像更新信息。

[root@master ~]# kubectl set image deployment web1 nginx=nginx:1.21.5

deployment.apps/web1 image updated

[root@master ~]# kubectl get pod

NAME                   READY   STATUS             RESTARTS   AGE

web1-594b7b7c6-xngl5   0/1     ImagePullBackOff   0          20s

web1-9d68ffd75-bnvdg   1/1     Running            0          9h

web1-9d68ffd75-x86hq   1/1     Running            0          9h

web1-9d68ffd75-zf4bh   1/1     Running            0          9h

[root@master ~]#

等待片刻再次检查镜像版本，发现镜像已经变为1.21.5版本。

[root@master ~]# kubectl describe pod web1-594b7b7c6-fkqt9 | grep image

  Normal  Pulled     2m49s  kubelet            Container image "nginx:1.21.5" already present on machine

回滚

kubectl rollout undo deployment web1

[root@master ~]# kubectl rollout undo deployment web1

deployment.apps/web1 rolled back

[root@master ~]# kubectl get pod -o wide

NAME                   READY   STATUS        RESTARTS   AGE     IP             NODE    NOMINATED NODE   READINESS GATES

web1-594b7b7c6-fkqt9   0/1     Terminating   0          4m58s   10.101.149.6   node1   <none>           <none>

web1-594b7b7c6-nmxlf   0/1     Terminating   0          4m59s   10.101.11.10   node2   <none>           <none>

web1-594b7b7c6-xngl5   0/1     Terminating   0          40m     10.101.11.9    node2   <none>           <none>

web1-9d68ffd75-fjhld   1/1     Running       0          5s      10.101.11.11   node2   <none>           <none>

web1-9d68ffd75-vmjgl   1/1     Running       0          6s      10.101.149.7   node1   <none>           <none>

web1-9d68ffd75-wbfbq   1/1     Running       0          3s      10.101.149.8   node1   <none>           <none>

[root@master ~]#

Deployment更新策略　

滚动更新（rollingUpdate）和重建更新（Recreate）。这两种更新策略差异如下：

重建更新（Recreate）
重建更新指的是先全部删除已有的Pod对象，然后创建新版本的Pod对象。这种更新方式，最大的弊端是在更新过程中，运行的服务要有一定时间的中断。但是有点在于这种方式的更新，没有出现新、老版本的Pod共存，并且共同提供服务的阶段。但是，相比于其有点，其缺点尤为明显。

spec:

  replicas: 1

  strategy:            #更新策略

    type: Recreate     #重建更新，默认是rollingUpdate

滚动更新（rollingUpdate）
在删除一部分老旧版本的Pod的同时，创建新版本的Pod资源。这种更新方式的好处在于，可以维持服务的正常提供，服务运行不会中断。但是这样做的问题在于，会存在一段时间，新版本的Pod和旧版本的Pod同时提供服务，客户端接收的服务可能来源于老版本的Pod，也可能来源于新版本的Pod，这将会导致服务上的差异性。事实上，相对比与其缺点，滚动更新策略的优点更加明显，即业务连续不中断，并且新老版本Pod并存可以使得提前检验新版本Pod的可用性，如果发现更新后服务出现问题，更是可以提前发现，提前处理。同时，滚动更新的缺点也可以通过分区域更新等方式来进行解决。因此，我们最常用的更新策略就是滚动更新，并且滚动更新也是Deployment控制器的默认更新策略。

Deployment可以保证在升级时只有一定数量的pod是down的，默认的，他会确保至少比期望的pod数量少一个是up状态

DaemonSet

Daemonset确保全部（或者一些）Node上运行一个pod的副本。　当有Node加入集群时，也会为它新增一个pod。当有Node从集群中删除时，这些pod也会被回收。删除Daemonset时会删除它创建的所有pod。

使用Daemonset的一些典型用法：

运行集群存储daemon，例如在每个Node上运行ceph、glusterd
在每个Node上运行日志收集daemon，例如logstash、fluentd
在每个Node上运行监控daemon，例如Prometheus Node Exporter

文档：https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/daemonset/

job

job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或者多个pod成功结束

特殊说明:

spec.template格式同pod一样
restartpolicy仅支持never或 onfailure
单个pod时，默认pod成功运行job即结束

cronjob

cronjob管理基于时间的job，即：

在给定时间点运行一次

周期性的在给定时间点运行

典型用法是：

在给定的时间点运行job

创建周期性的运行job，比如发送邮件，数据库备份等等。

StateFulSet

StateFulSet作为controller为pod提供唯一的标识，它可以保证部署和scale的顺序。

StateFulSet是为了解决有状态服务的问题（对应的deployment和Replicaset是为无状态服务而设计），应用场景包括：

稳定的持久化存储，即pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标识，即pod重新调度后其PodName和HostName不变，基于headless service（即没有cluster IP 的service）来实现
有序部署，有序扩展，即pod是有顺序的，在部署或者扩展时要依据定义的顺序依次进行（即从0到N-1，在下一个pod运行之前所有之前的pod都是running或者ready状态），基于init container来实现。
有序收缩，有序删除

例：

vim statefuset.yaml

apiVersion: v1

kind: Service

metadata:

  name: nginx

  labels:

    app: nginx

spec:

  ports:

  - port: 80

    name: web

  clusterIP: None

  selector:

    app: nginx

---

apiVersion: apps/v1

kind: StatefulSet

metadata:

  name: web

spec:

  selector:

    matchLabels:

      app: nginx # 必须匹配 .spec.template.metadata.labels

  serviceName: "nginx"

  replicas: 3 # 默认值是 1

  template:

    metadata:

      labels:

        app: nginx # 必须匹配 .spec.selector.matchLabels

    spec:

      containers:

      - name: nginx

        image: nginx:1.21.4

        ports:

        - containerPort: 80

          name: web

[root@master ~]# kubectl create -f statefuset.yaml

service/nginx created

statefulset.apps/web created

[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 2m24s
web-1 1/1 Running 0 2m23s
web-2 1/1 Running 0 2m22s
[root@master ~]#

StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。该标识和 Pod 是绑定的，与该 Pod 调度到哪个节点上无关。

对于具有 N 个副本的 StatefulSet，该 StatefulSet 中的每个 Pod 将被分配一个从 0 到 N-1 的整数序号，该序号在此 StatefulSet 上是唯一的。

创建一个busybox的pod来测试一下，可以直接访问到statufulset集群内部

[root@master ~]# kubectl run  busybox --image=busybox

pod/busybox created

[root@master ~]# kubectl get pods -o wide

NAME                   READY   STATUS    RESTARTS   AGE     IP              NODE    NOMINATED NODE   READINESS GATES

busybox                1/1     Running   0          4s      10.101.11.20    node2   <none>           <none>

web-0  （唯一标识符）     1/1     Running   0          49m     10.101.11.14    node2   <none>           <none>

web-1                  1/1     Running   0          49m     10.101.11.15    node2   <none>           <none>

web-2                  1/1     Running   0          49m     10.101.149.10   node1   <none>           <none>

[root@master ~]# kubectl exec -it busybox -- sh

/ # ping web-0.nginx     # $(服务名称).$(名字空间)

PING web-0.nginx (10.101.11.22): 56 data bytes

64 bytes from 10.101.11.22: seq=0 ttl=63 time=0.133 ms

64 bytes from 10.101.11.22: seq=1 ttl=63 time=0.108 ms

64 bytes from 10.101.11.22: seq=2 ttl=63 time=0.097 ms

64 bytes from 10.101.11.22: seq=3 ttl=63 time=0.097 ms

statefulset更新策略

StatefulSet 的 .spec.updateStrategy 字段让你可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。有两个允许的值：

OnDelet
当 StatefulSet 的 .spec.updateStrategy.type 设置为 OnDelete 时，它的控制器将不会自动更新 StatefulSet 中的 Pod。用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的 .spec.template 的变动作出反应。
RollingUpdate
RollingUpdate 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。这是默认的更新策略。

当 StatefulSet 的 .spec.updateStrategy.type 被设置为 RollingUpdate 时， StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。

Kubernetes 控制平面会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。如果你设置了 .spec.minReadySeconds（查看最短就绪秒数），控制平面在 Pod 就绪后会额外等待一定的时间再执行下一步。

分区滚动更新(灰度发布)

通过声明 .spec.updateStrategy.rollingUpdate.partition 的方式，RollingUpdate 更新策略可以实现分区。如果声明了一个分区，当 StatefulSet 的 .spec.template 被更新时，所有序号大于等于该分区序号的 Pod 都会被更新。所有序号小于该分区序号的 Pod 都不会被更新，并且，即使它们被删除也会依据之前的版本进行重建。

[root@master ~]# kubectl edit sts web

apiVersion: apps/v1

kind: StatefulSet

metadata:

  annotations:

    kubectl.kubernetes.io/last-applied-configuration: |

      {"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"web","namespace":"default"},"spec":{"replicas":3,"selector":{"matchLabels":{"app":"nginx"}},"serviceName":"nginx","template":{"metadata":{"labels":{"app":"nginx"}},"spec":{"containers":[{"image":"nginx:1.21.4","name":"nginx","ports":[{"containerPort":80,"name":"web"}]}]}}}}

  creationTimestamp: "2022-07-26T07:51:51Z"

  generation: 1

  name: web

  namespace: default

  resourceVersion: "57225"

  uid: 4b527fd0-6b5d-4bae-8312-d0cabb523ae3

spec:

  podManagementPolicy: OrderedReady

  replicas: 3

  revisionHistoryLimit: 10

  selector:

    matchLabels:

      app: nginx

  serviceName: nginx

  template:

    metadata:

      creationTimestamp: null

      labels:

        app: nginx

    spec:

      containers:

      - image: nginx:1.21.4

        imagePullPolicy: IfNotPresent

        name: nginx

        ports:

        - containerPort: 80

          name: web

          protocol: TCP

        resources: {}

        terminationMessagePath: /dev/termination-log

        terminationMessagePolicy: File

      dnsPolicy: ClusterFirst

      restartPolicy: Always

      schedulerName: default-scheduler

      securityContext: {}

      terminationGracePeriodSeconds: 30

  updateStrategy:

    rollingUpdate:

      partition: 0  比如当replicas数目为3时，把这里的0改为3的话，当更新版本时，只有web-2才会更新。

    type: RollingUpdate

status:

  collisionCount: 0

  currentReplicas: 3

  currentRevision: web-6cf5dbfdf7

  observedGeneration: 1

  readyReplicas: 3

  replicas: 3

  updateRevision: web-6cf5dbfdf7

  updatedReplicas: 3

Horizontal Pod Autoscaling

应用的资源使用率通常有高峰和低谷的时候，如何肖峰填谷，提高集群的整体资源使用率，让service中的pod数量自动调整呢？这就需要Horizontal Pod Autoscaling ，顾名思义，使pod水平缩放。