一、什么是控制器
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了。