kubernetes 资源控制器

pod 分类

• 自主式 pod：pod 一旦退出，该类型 pod 不会被创建，可以理解 无管理者
• 控制器管理 pod：在控制器的生命周期中始终维持 pod 的副本数目

什么是控制器

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，通过标签进行控制的

Deployment

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

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

命令式编程：它侧重于如何实现程序，就像我们刚接触编程时候那样，需要把程序的实现过程按照逻辑结果一步步写下来；（RS， 最优创建方法：apply）

声明式编程：它侧重于定义想要什么，然后告诉计算机/引擎去帮实现；（Deployment, 最优创建方法：create）

Deployment 与 RS 的关系

DaemonSet--类似于守护进程的方案

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

使用 DaemonSet 的一些典型用法：

• 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph
• 在每个 Node 上运行日志收集 daemon，例如 fluentd、logstash
• 在每个 Node 上运行监控 daemon，例如 prometheus、collectd、datadog代理、New Relic代理

Job

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

CronJob

CronJob 管理基于时间的 Job，在特定时间循环创建 Job，即：

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

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

典型用法：

• 在给定时间点调度 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 containers(init C)来实现
• 有序收缩、有序删除（即从 N-1 到 0）

Horizontal Pod Autoscaling

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

RS RC 与 Deployment 关联

RC 主要作用就是用来确保容器应用的副本数始终保持在用户定义的副本数。如果有容器异常退出，会自动创建新的 Pod 来代替，异常退出的容器会进行回收

kubernetes 官方建议使用 RS（ReplicaSet）来 RC 进行部署，因为 RS 支持集合式的 selector

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  # 副本数
  replicas: 3
  # 选择标签
  selector:
    mathLabels:
      tier: frontend
  template:
    matadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: myapp
        image: test/myapp:v1
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

所有副本数目的监控都是以标签为基础进行监控

示例

一、部署一个简单的 nginx 应用

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas:3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

创建 deployment 应用

kubectl apply -f nginx-deployment.yaml --record

--record 参数可以记录命令，可以很方便的查看每次 reversion 的变化

二、扩容

kubectl scale deployment nginx-deployment --replicas=5

如果集群支持 HPA，还可以为 Deployment 设置自动扩展

kubectl autoscale deployment nginx-deployment --min=3 --max=10 --cpu-percent=80

三、更新镜像

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

四、回滚

kubectl rollout undo deployment/nginx-deployment

Deployment 更新策略

Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的，默认它会确保至少有比期望的 Pod 数量少一个是 up 状态（最多一个不可用）

Deployment 同时也可以确保只创建出超过期望的一定数量 pod。默认它会确保最多比期望的 Pod 数量多一个的 Pod 是 up（最多一个 surge）

未来的 kubernetes 版本中，将从 1-1 变成 25%-25%

kubectl describe deployments

Rollover（多个 rollout 并行）

假如创建一个有 5 个 nginx:1.7.9 replica 的 deployment，但是当还只有三个 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 都创建完成后才开始改变航道。

回退 Deployment

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
# 查看deployment回退是否完成
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的更新

清理 Policy

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

DaemonSet

DaemonSet 确保全部 Node 上运行一个 Pod 的副本。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: daemonset-example
    template:
      metadata:
        labels:
          name: daemonset-example
      spec:
        containers:
        - name: daemonset-example
          image: test/myapp:v1

Job

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

特殊说明：

• spec.template 格式同 Pod
• RestartPolicy 仅支持 Never 或 OnFailure
• 单个 pod 时，默认 Pod 成功运行后 Job 即结束
• .spec.completions 标志 Job 结束需要成功运行的 Pod 个数，默认为 1
• .spec.parallelism 标志并运行的 pod 个数，默认为 1
• .spec.activeDeadlineSenconds 标志失败的 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)"]
      resrartPolicy: Never

CronJob

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

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

使用条件：kubernetes 版本 >=1.8

典型用法：

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

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.successfullJobsHistoryLimit 和 .spec.failedJobsHistoryLimit：历史限制，是可选字段。它们指定了可以保留多少完成和失败的 Job。默认情况下，它们分别设置为 3 和 1。设置限制的值为 0，相关类型的 Job 完成后将不会保留

模板

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

查看 CronJob

kubectl get cronjob

查看 Job

kubectl get jobs

删除 CronJob

kubectl delete cronjob $(cronjob-name)

CronJob 本身的限制：创建 Job 操作应该是 幂等的