controller-manager类型及其作用

controller-manager介绍

Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

controller-manager类型

replicationcontroller & replicaset & deployment（后面我会容rc和rs代替replicationcontroller & replicaset进行说明）

rc用来确保容器应用的副本数使用保持再用户定义的副本数，即如果有容器异常退出，回自动创建新的pod来替代，而如果一次多出的容器也会自动回收。

rs和rc没有本质区别，但是rs支持集合式的selector

虽然rs可以独立使用，但是一般还是建立使用deployment来自动管理rs，，这样就无需担心根其他跟其他机制的不兼容问题（比如replicaset不支持rooling-update滚动更新，但deployment支持）

 

Hpa

仅适用于deployment和rs，在v1版本中仅支持根据pod的cpu利用率扩缩容，在vlalpha版本中，支持根据内存和用户自定义的metric扩缩容

这里就体现出来k8s的强大之处，他能设置一个副本数的最大值，和最小值，假设现在副本数为3，cpu使用率大于80%，那么他就会继续创建副本数直到等于最大数，或者cpu使用率等于80%，如果cpu使用率小于80%，他就会删除多余副本，知道等于最小值，或者cpu使用率等于80%

 

statefulset

 

是为了解决有状态服务的问题（对应deployments和replicasets是为了无状态服务而设计）

其实在k8s运行有状态服务是非常困难的

应用场景：

稳定的持久化存储，即pod重新调度后还是能访问到相同的的持久化数据，基于PVC来实现

稳定的网络标志，即pod重启调度后其PodName和HostName不变，基于Headless Service来实现

有序部署，有序扩展，即pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行，基于init containers来实现

daemonset

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

这个控制器会用在prometheus中，由于监控需要在所有被监控端安装一个node_exporter，这样利用这个控制器就完美的解决了这个问题

 

 

job与crontjob

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

cron job管理基于时间的job，即：在给定时间点只运行一次，周期性地在给定时间点运行

 

这个控制器就和系统中计划任务的功能是一样的，但是为什么还要有这个控制器呢？

其实它的强大之处在于，如果是脚本执行失败了就会自动退出，而控制器却会一直去执行