k8s 资源控制器 - 《容器知识库》

什么式控制器
控制器类型
示例说明
DaemonSet
Job
CronJob
- CronJob Spec

什么式控制器

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

控制器类型

ReplicationController（旧）和 ReplicaSet（新）
Deployment
DaemonSet
StateFulSet
Job/Cr onJob
Horizontal Pod Autoscaling

ReplicationController 和 ReplicaSet

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

Deployment

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

定义 Deployment 来创建 Pod 和 ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续 Deployment

DaemonSet

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

Job

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

CronJob

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

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

使用前提条件：当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）。对于先前版本的集群，版本 <
1.8，启动 API Server时，通过传递选项 —runtime-config=batch/v2alpha1=true 可以开启 batch/v2alpha1
API

典型的用法如下所示：

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

StatefulSet

StatefulSet 作为 Controller 为 Pod 提供唯一的标识。它可以保证部署和 scale 的顺序 StatefulSet 是为了解决有状态服务的问题（对应 Deployments 和 ReplicaSets 是为无状态服务而设计），其应用场景包括：

稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现
稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service （即没有

Cluster IP 的 Service）来实现
有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从 0 到 N-1，在下一个Pod运行之前所有之前的Pod必须都是 Running 和 Ready 状态），基于 init containers 来实现
有序收缩，有序删除（即从N-1到0 ）

Horizontal Pod Autoscaling

应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让service中的Pod 个数自动调整呢？这就有赖于Horizontal Pod Autoscaling了，顾名思义，使Pod水平自动缩放

示例说明

RS 与 RC 与 Deployment 关联

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

cat <<EOF >./rs.yaml
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: myapp
        image: hub.yangguoxiang.com/library/myapp:v1.0
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80
EOF

测试操作命令

$ kubectl create -f rs.yaml
$ kubectl delete pod --all
pod "frontend-6dxtx" deleted
pod "frontend-v2crs" deleted
pod "frontend-vzshs" deleted
$ kubectl get pod
NAME             READY   STATUS    RESTARTS   AGE
frontend-cn8j8   1/1     Running   0          82s
frontend-gvp6x   1/1     Running   0          82s
frontend-plmc6   1/1     Running   0          82s
# # 资源控制器创建的 pod 会自动重新创建 pod，NAME已经不同
$ kubectl get pod --show-labels
NAME             READY   STATUS    RESTARTS   AGE     LABELS
frontend-cn8j8   1/1     Running   0          3m45s   tier=frontend
frontend-gvp6x   1/1     Running   0          3m45s   tier=frontend
frontend-plmc6   1/1     Running   0          3m45s   tier=frontend
$ kubectl label pod frontend-cn8j8 tier=frontend_v1.0 --overwrite=True
pod/frontend-cn8j8 labeled
$ kubectl get pod --show-labels
NAME             READY   STATUS    RESTARTS   AGE     LABELS
frontend-cn8j8   1/1     Running   0          6m19s   tier=frontend_v1.0
frontend-gnsnq   1/1     Running   0          16s     tier=frontend
frontend-gvp6x   1/1     Running   0          6m19s   tier=frontend
frontend-plmc6   1/1     Running   0          6m19s   tier=frontend
# # 通过标签 spec.selector.matchLabels.tier = frontend 完成选择
$ kubectl delete rs --all
$ kubectl get pod --show-labels
NAME             READY   STATUS        RESTARTS   AGE     LABELS
frontend-cn8j8   1/1     Running       0          11m     tier=frontend_v1.0
frontend-gnsnq   1/1     Terminating   0          5m56s   tier=frontend
frontend-gvp6x   1/1     Terminating   0          11m     tier=frontend
frontend-plmc6   1/1     Terminating   0          11m     tier=frontend

RS 与 Deployment 的关联

Deployment

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

定义 Deployment 来创建 Pod 和 ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续 Deployment

Ⅰ、部署一个的 mapp 应用

cat <<EOF >./deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: hub.yangguoxiang.com/library/myapp:v1.0
        ports:
        - containerPort: 80
EOF

# # --record参数可以记录命令，我们可以很方便的查看每次 revision 的变化 
# kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record
$ kubectl apply -f deployment.yaml --record
$ kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
myapp-deployment   3/3     3            3           2m9s
$ kubectl get rs
NAME                         DESIRED   CURRENT   READY   AGE
myapp-deployment-f4769bfdf   3         3         3       2m15s
$ kubectl get pod --show-labels
NAME                               READY   STATUS    RESTARTS   AGE     LABELS
myapp-deployment-f4769bfdf-96lsd   1/1     Running   0          2m34s   app=nginx,pod-template-hash=f4769bfdf
myapp-deployment-f4769bfdf-hzh8z   1/1     Running   0          2m34s   app=nginx,pod-template-hash=f4769bfdf
myapp-deployment-f4769bfdf-jh7cj   1/1     Running   0          2m34s   app=nginx,pod-template-hash=f4769bfdf

Ⅱ、扩容

$ kubectl scale deployment myapp-deployment --replicas 5

Ⅲ、如果集群支持 horizontal pod autoscaling 的话，还可以为Deployment设置自动扩展

$ kubectl autoscale deployment myapp-deployment --min=5 --max=10 --cpu-percent=80

Ⅳ、更新镜像也比较简单

$ kubectl set image deployment/myapp-deployment myapp=hub.yangguoxiang.com/library/myapp:v2.0

Ⅴ、回滚

$ kubectl rollout undo deployment/myapp-deployment

更新 Deployment

假如我们现在想要让 myapp pod 使用 myapp:v2.0 的镜像来代替原来的 myapp:v1.0 的镜像

$ kubectl set image deployment/myapp-deployment nginx=hub.yangguoxiang.com/library/myapp:v2.0
deployment.extensions/myapp-deployment image updated

可以使用 edit 命令来编辑 Deployment

$ kubectl edit deployment/myapp-deployment
deployment "myapp-deployment" edited

查看 rollout 的状态

$ kubectl rollout status deployment/myapp-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...  
deployment "myapp-deployment" successfully rolled out

查看历史 RS

$ kubectl get rs
NAME                         DESIRED   CURRENT   READY   AGE
myapp-deployment-65bcf8d44   0         0         0       11m
myapp-deployment-f4769bfdf   5         5         5       9m8s

Deployment 更新策略

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

$ kubectl describe deployments

Rollover（多个rollout并行）

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

回退 Deployment

$ kubectl set image deployment/myapp-deployment myapp=hub.yangguoxiang.com/library/myapp:v2.0
$ kubectl rollout status deployments myapp-deployment
$ kubectl get pods
$ kubectl rollout history deployment/myapp-deployment
$ kubectl rollout undo deployment/myapp-deployment
# # 可以使用 --revision 数指定某个历史版本号
$ kubectl rollout undo deployment/myapp-deployment --to-revision=2
# # 暂停 deployment 的更新
$ kubectl rollout pause deployment/myapp-deployment

您可以用 kubectl rollout status 命令查看 Deployment 是否完成。如果 rollout 成功完成， kubectl rollou status=一个0值的 Exit Code

$ kubectl rollout status deployment/myapp-deployment
Waiting for rollout to finish: 2 of 3 updated replicas are available...  
deployment "myapp" successfully rolled out  
$ echo $?  
0

清理 Policy

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

DaemonSet

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

cat <<EOF >./deamonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: deamonset-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: deamonset-example
  template:
    metadata:
      labels:
        name: deamonset-example
    spec:
      containers:
      - name: daemonset-example
        image: hub.yangguoxiang.com/library/myapp:v2.0
EOF

Job

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

特殊说明

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

apiVersion: batch/v1
kind: 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

CronJob

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 的并发执行。只允许指定下面策略中的一种：
- Allow （默认）：允许并发运行 Job
- Forbid ：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
- Replace ：取消当前正在运行的 Job ，用一个新的来替换
  
  注意，当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job ，它们创建的 Job 之间总
  是允许并发运行。
.spec.suspend ：挂起，该字段也是可选的。如果设置为 true ，后续所有执行都会被挂起。它对已经开始

执行的 Job 不起作用。默认值为 false 。

.spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit ：历史限制，是可选的字段。它

们指定了可以保留多少完成和失败的 Job。默认情况下，它们分别设置为 3 和 1 。设置限制的值为 0 ，相
关类型的 Job 完成后将不会被保留。

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

$ kubectl get cronjob
NAME      SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
hello     */1 * * * *   False     0         <none>
$ kubectl get jobs
NAME               DESIRED   SUCCESSFUL   AGE
hello-1202039034   1         1            49s
$ pods=$(kubectl get pods --selector=job-name=hello-1202039034 --output=jsonpath=
{.items..metadata.name})
$ kubectl logs $pods
Mon Aug 29 21:34:09 UTC 2016
Hello from the Kubernetes cluster
# 注意，删除 cronjob 的时候不会自动删除 job，这些 job 可以用 kubectl delete job 来删除
$ kubectl delete cronjob hello
cronjob "hello" deleted
CrondJob 本身的一些限制                                                                                                        
创建 Job 操作应该是 幂等的