K8S的资源控制器

一、什么是控制器

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

二、控制器类型

ReplicationController 和 ReplicaSet
Deployment
DaemonSet
StateFulSet
Job/CronJob
Horizontal Pod Autoscaling

2.1 ReplicationController 和 ReplicaSet

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

在新版本的Kubernetes中建议使用ReplicaSet（RS，命令式定义方法）来取代ReplicationController。RS与RC没有本质的不同，但是RS支持集合式的selector；

2.2 Deployment

Deployment为Pod和RS提供了一个声明式定义（declarative）方法，用来替代以前的RC来方便的管理应用。Deployment并不会直接创建Pod，它是通过控制RS来创建Pod的。

2.2.1 典型的应用场景包括：

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

2.2.2 更新策略

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

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

未来的K8S版本中，将1-1（更新1个，删除1个）变成25%-25%（更新25%的Pod，删除25%的Pod）

2.2.3 Rollover（多个rollout并行）

假设创建了1个有5个nginx:1.7.9 replica的Deployment，但是当只有3个nginx:1.7.9的replica被创建出来的时候，我们就决定开始将nginx的版本更新为1.9.1。在这种情况下，Deployment会立即杀掉已创建的3个nginx:1.7.9的Pod，并开始创建nginx:1.9.1的Pod。它不会等到所有的5个nginx:1.7.9的Pod都创建完成后才开始更新。

2.2.4 回退 Deployment

//1. 查看回滚状态
kubectl rollout status deployment名称（例如：deployment/nginx-deployment）
//2.查看历史版本
kubectl rollout history deployment名称（例如：deployment/nginx-deployment）
//3.回退到指定版本，假设当前版本是3，想要回退到版本1
kubectl rollout undo deployment名称 --to-revision=1
//4.暂停操作
kubectl rollout pause deployment名称
//5.可以使用 ‘kubectl rollout status’命令查看Deployment是否完成。如果rollout成功完成，‘kubectl rollout status’将返回一个0值的Exit Code
// 可以使用 ‘echo $?’ 代替 ‘kubectl rollout status’ 命令查看Deployment是否完成
echo $?

2.2.5 清理策略

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

扩展：

命令式编程：它侧重于如何实现程序，就像我们刚接触编程的时候那样，我们需要把程序的实现过程按照逻辑结果一步步写下来
声明式编程：它侧重于定义想要什么，然后告诉计算机/引擎，让它帮助你实现

2.3 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

2.4 Job

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

2.5 CronJob

CronJob管理基于时间的Job

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

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

典型用法如下所示：

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

2.6 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来实现
有序收缩，有序删除（即从N-1 到 0）

2.7 Horizontal Pod Autoscaling

Horizontal Pod Autoscaling（HPA，Pod水平自动缩放）其实不属于真正的控制器，它是通过控制其他控制器实现自己的目标。应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让service中的Pod个数自动调整，这种场景下就需要使用HPA了。