（四）k8s资源控制器

一、Pod 的分类

• 自主式 Pod：Pod 退出了，此类型的 Pod 不会被创建

  就是我们直接创建一个kind为Pod的资源

• 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目

  就是我们创建 kind为rs，deployment,dameSet,Job等等的控制器，而pod由他们来控制

创建的格式

kutectl create/apply -f xxx.yaml

推荐使用，但是你如果说我就全都使用apply或者全都使用create那也是没有问题的

• 申明式编程 （Deployment） apply（优） create
• 命令式 （rs） create（优） apply

二、控制器整体说明

Kubernetes 中内建了很多 controller（控制器），这些相当于一个状态机，用来控制 Pod 的具体状态和行为。

类型	说明
ReplicationController & ReplicaSet& Deployment > HPA (HorizontalPodAutoScale)	ReplicationController 用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代；而如果异常多出来的容器也会自动回收。在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationControlle,ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector(比如通过标签删除管理pod),虽然 ReplicaSet 可以独立使用，但一般还是建议使用 Deployment 来自动管理 ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet 不支持rolling-update 但 Deployment 支持）, Deployment为Pod 和 ReplicaSet 提供了一个声明式定义（declarative）方法，用来替 代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括：1、定义 Deployment,来创建 Pod 和 ReplicaSet；2、滚动升级和回滚应用；3、扩容和缩容4、暂停和继续Deployment。这个图就是说Depliyment的自动扩容的能力
Horizontal Pod Autoscaling	这个组件和前面的rs和Deployment是一样的，但是单独按出来说，因为这个组件我没有在华为云和腾讯云的k8s后台看到过， Horizontal Pod Autoscaling 仅适用于 Deployment 和 Replicaset , 在 vlalpha 版本中，支持根据内存和用户自定义的metric扩缩容。如下面这张图，说明当CPU大于80%时，可以扩容到10，但是最多10，当CPU下来时，可以缩减，但是最少也得有2个。
StatefullSet	Statefulset 是为了解决有状态服务的问题（对应 Deployments 和 Replicasets 是为无状态服务而设计），其应用场景包括：1、稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现；2、稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service （即没有 Cluster IP 的 Service ）来实现；3、有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从 0 到 N - - 1 ，在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态） , 基于 init containers 来实现；4、有序收缩，有序删除（即从 N 一 1 到 0 )
DaemonSet	Daemonset 确保全部（或者一些） Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 Daemonset 将会删除它创建的所有 Pod 。使用 Daemonset 的一些典型用法：1、运行集群存储 daemon ，例如在每个 Node 上运行 glusterd 、 ceph ；2、在每个 Node 上运行日志收集 daemon ，例如 fluentd 、 logstash 。3、在每个 Node 上运行监控 daemon ，例如 Prometheus Node Exporter
Job,Cronjob	Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束 Crofi Job 管理基于时间的 Job ，即：在给定时间点只运行一次周期性地在给定时间点运行

三、RS 控制器

RC （ReplicationController ）主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数 。即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收
Kubernetes 官方建议使用 RS（ReplicaSet ） 替代 RC （ReplicationController ） 进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector（如标签等等）

# 实验
vim rs.yaml

内容如下

apiVersion: extensions/v1beta1
kind: ReplicaSet  # 类型是 rs
metadata:
  name: frontend  # rs 叫做  frontend
spec:
  replicas: 3 # 管理的pod 副本数是3个
  selector:
    matchLabels:
      tier: frontend  # 当前这个rs 只管理标签 tier=frontend 的pod，所以，等下后面的pod必须要需要设置标签  tier=frontend 
  template:
    metadata:
      labels:
        tier: frontend  # 设置当前pod的标签，这样就会被上面的rs管理
    spec:
      containers:
      - name: php-redis # 容器名称
        image: gcr.io/google_samples/gb-frontend:v3
        env:
        - name: GET_HOSTS_FROM  # 定义一个环境变量的名称
          value: dns   # GET_HOSTS_FROM环境变量的值
        ports:
        - containerPort: 80  # 说明暴露的端口，这个加不加无所谓

直接删除pod后，会重新创建，因为当前的rs设置了3个pod副本，数量不满足，会自动新建

查看这些pod的标签，都带了 tier=frontend

kubectl get pod --show-labels

我们直接修改其中一个pod的标签，改为 tier=frontend1，会发现有4个pod了，标签 tier=frontend的有三个，其中一个是新的，tier=frontend1 的有一个，是从fonttend改的，原因是我们将原有的3个pod中一个改了标签，那么它就不归当前这个rs管理，而rs发现它管理的只有2个了，又会新增一个，因为副本数是3个，所以现在就又4个pod了。

其实如果还有其它的rs并且管理的标签是 tier=frontend1 那么那个修改的就会移动到那个rs下面了。这样就可能完成更具标签管理了。

# kubectl label pod podName tier=frontend1 
kubectl label pod fronted-m8hpc tier=frontend1 

删除rs（注意这里是rs ，不是deployment，所以删除rs后，rs是不会从新创建的），会发现 改完的那个标签的pod没有rs管理了，因为标签已经不一致了

四、deployment

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

• 定义Deployment来创建Pod和ReplicaSet
• 滚动升级和回滚应用 （deploment 特有的）
• 扩容和缩容 （rs 自带的）
• 暂停和继续Deployment （deploment 特有的）

deployment 会管理rs，rs 再管理pod，所以，这里如果你需要删除的话，必须直接删除deployment，不然你删除rs或者pod,都会根据副本数自动重建。

有一点需要说明的时，更新时，rs不会删除，只会把老的rs下的pod删除，这样回滚/回退的时候，直接在老版本的rs下面建立pod即可

这里这是给pod加上了标签，但是deployment 并没有设置匹配标签

vim deployment.yaml
# 构建的时候，加上 --record 等下我们在看历史的时候，会记录一些信息（虽然不咋滴）
kutectl apply -f deploment.yaml --record

内容如下

apiVersion: extensions/v1beta1
kind: Deployment  # 类型为Deploment
metadata:
  name: nginx-deployment
spec:
  replicas: 3  # 副本数为3
  template:  # 从template 开始就是 具体的pod了
    metadata:
      labels:
        app: nginx  # 当前的pod 设置标签 app=nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

访问

# 使用 wide 可以看的信息会更多一些，比如k8s内的网络
kubectl get pod -o wide

扩容，同时可以看到 rs，还是之前的那个rs，扩容和缩容都不会修改模板信息rs,只有 更新/删除 操作会修改

# kubectl scale 类型(rs,pod,deployment) 具体的名称 --replicas 副本数量
kubectl scale deployment nginx-deployment --replicas 10

更新，升级版本，会发现rs 也会修改，会创建一个新的rs，老版本的rs不会删除，和之前的图是一样的

# kubectl set image 类型(rs,pod,deployment)/具体的名称 容器的名称(main C的名称)=镜像:镜像版本
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

并且此时的pod也是修改完成了，会在最新的rs下面

回滚 rs从最新的xxx75d8回滚到之前的xxx767f,这也是说明一点，在升级的时候，rs并不会被删除，只是会清空下面的pod


回滚到指定版本

# 查看这个类型资源的更新历史，也可以看到版本方便回退， 
# kubectl rollout history 类型(rs,pod,deployment)/具体的名称
kubectl rollout history deployment/nginx-deployment
# 回退到版本1，如果不加参数   --to-revision 则默认回滚到上一次
# kubectl rollout undo deployment/nginx-deployment --to-revision=1

并且你可以查看rs，得知回滚了几次，因为历史的rs是不会删除的

4.1、deployment 一些操作说明

假如我们现在想要让 nginx pod 使用 nginx:1.9.1 的镜像来代替原来的 nginx:1.7.9 的镜像

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

可以使用 edit 命令来编辑 Deployment

kubectl edit deployment/nginx-deployment

查看 rollout 的状态

kubectl rollout status deployment/nginx-deployment

4.2、deployment 更新策略

• Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）
• Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge ）
• 未来的 Kuberentes 版本中，将从1-1变成25%-25%

意思就是在更新的时候如果有4个pod副本，对于两个rs，只会同时删除/新建 一个pod（4 * 25% = 1），这会影响更新的速度。

4.3、Rollover（多个rollout并行）

假如您创建了一个有5个 niginx:1.7.9 replica的 Deployment，但是当还只有3个 nginx:1.7.9 的 replica 创建出来的时候您就开始更新含有5个 nginx:1.9.1 replica 的 Deployment。在这种情况下Deployment 会立即杀掉已创建的3个 nginx:1.7.9 的 Pod，并开始创建 nginx:1.9.1 的 Pod。它不会等到所有的5个 nginx:1.7.9 的Pod 都创建完成后才开始改变航道

4.4、回退 Deployment 的一些命令

kubectl set image deployment/nginx-deployment nginx=nginx:1.91
kubectl rollout status deployments nginx-deployment
kubectl get pods
kubectl rollout history deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment --to-revision=2   ## 可以使用 --revision参数指定
某个历史版本
kubectl rollout pause deployment/nginx-deployment    ## 暂停 deployment 的更新

您可以用 kubectl rollout status 命令查看 Deployment 是否完成。如果 rollout 成功完成， kubectl rollout status 将返回一个0值的 Exit Code，这个操作可以用在shell脚本中，判断是否执行成功

$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $? # $? 获取上个命令的结果
0

4.5、清理 Policy

您可以通过设置 .spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision；如果将该项设置为0，Deployment 就不允许回退了

五、deamonset 控制器

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

• 运行集群存储 daemon，例如在每个 Node 上运行 glusterd 、 ceph
• 在每个 Node 上运行日志收集 daemon，例如 fluentd 、 logstash
• 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、
• New Relic 代理，或 Ganglia gmond

不需要指定副本数，默认会在每一个work节点创建一个（master节点有污点，不会创建pod）,并且你会发现所有的pod都不会在master节点上创建，那是因为master上面有污点，pod不会在上面创建

vim deamonset.yaml

内容如下

apiVersion: apps/v1
kind: DaemonSet # 类型为DaeminSet
metadata:
  name: deamonset-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: deamonset-example  # 当前这个 daemenset 只管理标签 name=deamonset-example的pod
  template:
    metadata:
      labels:
        name: deamonset-example  # 设置标签 匹配上文
    spec:
      containers:
      - name: daemonset-example
        image: wangyanglinux/myapp:v1

如果此时你删除 node01节点上面的deamonset ，它还会自动在那个节点创建一个新的，始终保存副本数为1。

五、job 控制器

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

特殊说明

• spec.template格式同Pod
• RestartPolicy仅支持Never或OnFailure
• 单个Pod时，默认Pod成功运行后Job即结束
• .spec.completions 标志Job结束需要成功运行的Pod个数，默认为1（如果设置为4，表明这个job必须有4次正常运行的退出才行）
• .spec.parallelism 标志并行运行的Pod的个数，默认为1
• spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试

vim job.yaml

内容,输出圆周率小数点 2000位

apiVersion: batch/v1
kind: Job  # 类型为Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

查看，当前 completions为 0/1 未执行状态

执行完成后，查看日志是否输出 圆周率

六、cronjob 控制器

• spec.template格式同Pod
• RestartPolicy仅支持Never或OnFailure
• 单个Pod时，默认Pod成功运行后Job即结束
• .spec.completions 标志Job结束需要成功运行的Pod个数，默认为1
• .spec.parallelism 标志并行运行的Pod的个数，默认为1
• spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试

Cron Job 管理基于时间的 Job，即

• 在给定时间点只运行一次
• 周期性地在给定时间点运行

使用条件：当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）

典型的用法如下所示：

• 在给定的时间点调度 Job 运行
• 创建周期性运行的 Job，例如：数据库备份、发送邮件

CronJob Spec

字段	说明
.spec.schedule	调度，必需字段，指定任务运行周期，格式同 Cron
.spec.jobTemplate	Job 模板，必需字段，指定需要运行的任务，格式同 Job
.spec.startingDeadlineSeconds	启动 Job 的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度的时间，那么错过执行时间的 Job 将被认为是失败的。如果没有指定，则没有期限
.spec.concurrencyPolicy	并发策略，该字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种：1）、Allow （默认）：允许并发运行 Job；2）、Forbid ：禁止并发运行，如果前一个还没有完成，则直接跳过下一个；3）、Replace ：取消当前正在运行的 Job，用一个新的来替换；注意，当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job，它们创建的 Job 之间总是允许并发运行。
.spec.suspend	挂起，该字段也是可选的。如果设置为 true ，后续所有执行都会被挂起。它对已经开始执行的 Job 不起作用。默认值为 false 。
.spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit	历史限制，是可选的字段。它们指定了可以保留多少完成和失败的 Job。默认情况下，它们分别设置为 3 和 1 。设置限制的值为 0 ，相关类型的 Job 完成后将不会被保留。

创建

vim cronjob.yaml

内容如下

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

查看，cronjob 会去管理job，而job又会去管理pod