1 控制器

无论你的负载是单一组件还是由多个一同工作的组件构成，在 Kubernetes 中可以在一组 Pods 中运行它。 在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组容器。

Kubernetes Pods 有确定的生命周期。 例如，一旦某 Pod 在你的集群中运行，Pod 运行所在的 节点 出现致命错误时， 所有该节点上的 Pods 都会失败。Kubernetes 将这类失败视为最终状态： 即使该节点后来恢复正常运行，你也需要创建新的 Pod 来恢复应用。

用户并不需要直接管理每个 Pod。，可以使用负载资源来替你管理一组 Pods。 这些资源配置控制器确保合适类型的、处于运行状态的 Pod 个数是正确的，与所指定的状态相一致

1.1 Replication Controller和ReplicaSet

ReplicaSet 是下一代的 Replication Controller，官方推荐使用ReplicaSet。

• ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持，ReplicaSet支持新的基于集合的选择器需求
• ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行
• 虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制

Pod 的生命：一般Pod 不会消失，直到人为销毁

Pod 的分类：

• 自主式 Pod：Pod 退出后不会被创建
• 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目

建议创建适当的控制器来创建 Pod，因为控制器创建的 Pod 在机器故障的情况下可以自动复原

2 常用的控制器类型

Deployment 和 ReplicaSet （替换原来的资源 ReplicationController）

• Deployment 很适合用来管理集群上的无状态应用，Deployment 中的所有 Pod 都是相互等价的，并且在需要的时候被换掉。

• StatefulSet 能够运行一个或者多个以某种方式跟踪应用状态的 Pods。 例如，如果你的负载会将数据作持久存储，可以运行一个StatefulSet，将每个 Pod 与某个 PersistentVolume 对应起来。在 StatefulSet 中各个 Pod内运行的代码可以将数据复制到同一 StatefulSet 中的其它 Pod 中以提高整体的服务可靠性。

• DaemonSet 定义提供节点本地支撑设施的 Pods。这些 Pods 可能对于集群的运维是非常重要的，例如作为网络链接的辅助工具或者作为网络 插件 的一部分等等。每次向集群中添加一个新节点时，如果该节点与某 DaemonSet的规约匹配，则控制面会为该 DaemonSet 调度一个 Pod 到该新节点上运行。

  Job 和 CronJob。：定义一些一直运行到结束并停止的任务。Job 用来表达的是一次性的任务，而 CronJob 会根据其时间规划反复运行。

三种可用的控制器使用的场景

• 使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。
• 对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web
  服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。
• 提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod 。

2.1 ReplicaSet

副本集合（ReplicaSet）的作用是，在任何时刻，都维护一个Pod对象数目固定的副本集合，这些Pod对象都相同，通常用于保证可用性

Replication Controller和ReplicaSet

• Replication Controller的作用是确保Pod以指定的副本个数运行，ReplicaSet是Replication
  Controller升级版
• ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持，ReplicaSet支持新的基于集合的选择器需求。
• ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。
• 虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制。

（1）编辑清单资源文件：vim deployment.yml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: deployment
spec:
  replicas: 3 ## 副本的书目
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

• 创建容器： kubectl apply -f rs.yml
• 查看pod的信息：kubectl get pod
• 查看ReplicaSet：kubectl get rs

（2） 副本的拉伸

• 编辑清单资源文件：vim deployment.yml，可以直接拉伸副本的数量

• 更新容器： kubectl apply -f rs.yml
• 查看ReplicaSet：kubectl get rs
• 查看pod的信息：kubectl get pod

2.2 Deployment

DeploymentController 作为管理 Deployment 资源的控制器，会在启动时通过 Informer 监听三种不同资源的通知，Pod、ReplicaSet 和 Deployment，这三种资源的变动都会触发 DeploymentController 中的回调。

（1） 编辑清单资源文件： vim deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment
spec:
  replicas: 3
  selector:   ## 选择器匹配的标签
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx  ## 标签
    spec:
      containers:
      - name: nginx
        image: myapp:v1

• 应用文件： kubectl apply -f deployment.yml，在 Kubernetes 集群中创建上述 Deployment 对象时，它不只会创建 Deployment 资源，还会创建另外的 ReplicaSet 以及三个 Pod 对象
• 每一个 Deployment 都会和它的依赖组成以下的拓扑结构，在这个拓扑结构中的子节点都是『稳定』的，任意节点的删除都会被 Kubernetes 的控制器重启
• deployment——>ReplicaSet——>pod

• 查看pod的信息：kubectl get pod
• 查看deployment 控制器的信息：kubectl get deployments.apps deployment

（2）控制器通过标签控制，一旦标签更改，pod将不受控制

• 删除控制器：kubectl delete -f deployment.yml
• 应用文件：kubectl apply -f deployment.yml
• 查看pod的信息：kubectl get pod
• 查看标签：kubectl get pod --show-labels

• 更改pod标签：kubectl label pod deployment-6456d7c676-4gb7g app=myapp --overwrite，deployment-6456d7c676-4gb7g的标签更改为app=myapp，此时该pod将不受deployment控制器的控制，而控制器为了保证副本的数量会自动生成一个新的标签为app=myapp的pod

[root@server2 ~]# kubectl get pod --show-labels 
NAME                          READY   STATUS    RESTARTS   AGE     LABELS
demo                          1/1     Running   1          3h30m   run=demo
deployment-6456d7c676-4gb7g   1/1     Running   0          63s     app=myapp,pod-template-hash=6456d7c676
 ## 保证标签的数量新建副本
deployment-6456d7c676-6fmhn   1/1     Running   0          63s     app=nginx,pod-template-hash=6456d7c676
deployment-6456d7c676-f9pzg   1/1     Running   0          63s     app=nginx,pod-template-hash=6456d7c676
deployment-6456d7c676-lcthl   1/1     Running   0          3s      app=nginx,pod-template-hash=6456d7c676

（3）更新镜像的版本

• 编辑清单资源文件：vim deployment.yml

• 应用文件：kubectl apply -f deployment.yml，新版本的rs运行成功后旧版本rs中的被回收

• 由于deployment-6456d7c676-4gb7g的标签已经改变，此pod不受控制器的控制删除后，控制器也不会创建新的pod替代

• 查看ReplicaSet：kubectl get rs，旧的rs并未被删除

（4）回滚镜像的版本

• 编辑清单资源文件：vim deployment.yml

• 应用配置文件：kubectl apply -f deployment.yml，v1版本的副本创建3个，v2版本的副本将会减少到0

[root@server2 ~]# kubectl get rs  ## 查看副本的信息
NAME                    DESIRED   CURRENT   READY   AGE
deployment-6456d7c676   2         2         1       6m34s
deployment-6d4f5bf58f   2         2         2       2m53s
[root@server2 ~]# kubectl get rs
NAME                    DESIRED   CURRENT   READY   AGE
deployment-6456d7c676   3         3         2       6m36s
deployment-6d4f5bf58f   1         1         1       2m55s
[root@server2 ~]# kubectl get rs
NAME                    DESIRED   CURRENT   READY   AGE
deployment-6456d7c676   3         3         3       6m37s
deployment-6d4f5bf58f   0         1         1       2m56s
[root@server2 ~]# kubectl get rs
NAME                    DESIRED   CURRENT   READY   AGE
deployment-6456d7c676   3         3         3       19m
deployment-6d4f5bf58f   0         0         0       15m

• 过滤app的标签：kubectl get pod -L app，v2中rs的pod被回收，v1的rs中创建3个副本

deployment中镜像升级和回滚的工作原理

（1）创建副本的原理：deployment——>myapp：v1——>rs-6456d7c676——>3个副本

（2）升级v1——>v2：(默认旧的rs不会被回收)

• 回收rs中的pod：rs-6456d7c676——>3个副本
• deployment——>myapp：v2——>rs-6d4f5bf58f——>3个副本

2.3 DaemonSet控制器

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

（1） 编辑资源清单文件：vim daemonSet.yml

• 在每个 Node 上运行监控:zabbix-agent

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example
  labels:
    k8s-app: zabbix-agent
spec:
  selector:
    matchLabels:
      name: zabbix-agent
  template:
    metadata:
      labels:
        name: zabbix-agent
    spec:
      containers:
      - name: zabbix-agent
        image: zabbix-agent  ## 镜像

• 应用资源清单文件：kubectl apply -f daemonSet.yml
• 查看pod的信息，每个子节点创建一个

kubectl get pod
kubectl get pod -o wide

2.4 jobs

Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直到指定数量的 Pods 成功终止。 随着 Pods 成功结束，Job 跟踪记录成功完成的 Pods 个数。 当数量达到指定的成功个数阈值时，任务（即 Job）结束。 删除 Job 的操作会清除所创建的全部 Pods。

一种简单的使用场景下，你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成。 当第一个 Pod 失败或者被删除（比如因为节点硬件失效或者重启）时，Job 对象会启动一个新的 Pod。

• 官方文档：https://kubernetes.io/zh/docs/concepts/workloads/controllers/cron-jobs/

（1）job 配置示例：计算 π 到小数点后 2000 位，并将结果打印出来

• 编辑清单资源文件：vim job.yml

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl  ## 镜像
        ## 执行的命令
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never   ## 只执行一次
  backoffLimit: 4  ## restartPolicy设置为 Never时，pod的error次数，当error次数超过该值时，job也会被自动退出

• 运行此示例：kubectl create -f job.yml，pod只运行一次
• 查看日志信息： kubectl logs pi-2whln

2.5 Cron Job

官方文档：https://kubernetes.io/zh/docs/concepts/workloads/controllers/cron-jobs/

Cron Job 创建基于时间调度的 Jobs

一个 CronJob 对象就像 crontab (cron table) 文件中的一行。 它用 Cron 格式进行编写， 并周期性地在给定的调度时间执行 Job。

注意：

所有 CronJob 的 schedule: 时间都是基于 kube-controller-manager. 的时区。

如果你的控制平面在 Pod 或是裸容器中运行了 kube-controller-manager， 那么为该容器所设置的时区将会决定 Cron Job 的控制器所使用的时区。

（1）Cron 时间表语法

# ┌───────────── 分钟 (0 - 59)
# │ ┌───────────── 小时 (0 - 23)
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6) （周日到周一；在某些系统上，7 也是星期日）
# │ │ │ │ │                                   
# │ │ │ │ │
# │ │ │ │ │
# * * * * *

下面的 CronJob 示例清单会在每分钟打印出当前时间和问候消息

• 编辑清单资源文件：vim cronjob.yml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"  ## 每分钟执行一次
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            args:  ## 执行的shell命令
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure  ## 表示在容器失败的时候重启容器

• 运行示例：kubectl create -f cronjob.yml

[root@server2 ~]# kubectl get pod
NAME                     READY   STATUS              RESTARTS   AGE
demo                     1/1     Running             1          5h26m
hello-1614033900-wrnn2   0/1     ContainerCreating   0          4s
[root@server2 ~]# kubectl get pod
NAME                     READY   STATUS              RESTARTS   AGE
demo                     1/1     Running             1          5h27m
hello-1614033900-wrnn2   0/1     ContainerCreating   0          27s
[root@server2 ~]# kubectl get pod
NAME                     READY   STATUS      RESTARTS   AGE
demo                     1/1     Running     1          5h27m
hello-1614033900-wrnn2   0/1     Completed   0          50s
[root@server2 ~]# kubectl get pod
NAME                     READY   STATUS      RESTARTS   AGE
demo                     1/1     Running     1          5h28m
hello-1614033900-wrnn2   0/1     Completed   0          92s
hello-1614033960-z8wxm   0/1     Completed   0          31s

• 查看日志信息：

kubectl logs hello-1614033960-z8wxm
kubectl logs hello-1614033900-wrnn2