kubernetes Master节点组件（三）- Controller Manager

首先我们来看一下kubernetes官网上对于Controller Manager的定义：

The Kubernetes controller manager is a daemon that embeds the core control loops shipped with Kubernetes. In applications of robotics and automation, a control loop is a non-terminating loop that regulates the state of the system. In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller.

从定义来看，Controller Manager 以守护进程的形式运行着kubernetes几个核心的控制循环（也就是控制器），包括deployment，replicaset，namespace，serviceaccount，node等等。
我们也可以在kubernetes的源码中看到Controller Manager里面管理的控制器的列表。

而一个控制器则是通过调用Api Server 的 list watch接口来监控自己负责的资源的配置变化情况，然后根据配置的变化对资源进行配置以达到预期的情况。
其逻辑可以用伪代码表示为：

for {
  实际状态 := 获取集群中对象 X 的实际状态（Actual State）
  期望状态 := 获取集群中对象 X 的期望状态（Desired State）
  if 实际状态 == 期望状态{
    什么都不做
  } else {
    执行编排动作，将实际状态调整为期望状态
  }
}

以我们最常用的deployment为例：

如上图的一个deployment定义，它定义了我们希望添加的pod的副本数为2， 同时指定了我们创建pod的模板。
那么其实际运行的过程是怎么样的呢？
实际上deployment并不直接控制其对应的pod的生命周期，而是在中间引入了replicaset这一层来进行代理。

所以当我们通过kubectl添加了一个deployment的yaml文件到api server之后，api server会将其添加到etcd中。

1. 当deployment控制器监控到这个deployment的add事件之后，就会根据其对控制器的定义生成对应的replicaset发到api server
2. 当replicaset控制器收到这个replicaset的add事件之后，就会根据其定义的pod副本个数，以及模板生成对应的pod发到api server
   而当我们需要对pod进行水平伸缩的话，通过修改deployment的副本数就能控制deployment-replicaset对pod的个数进行增加或者减少

这样做的另外一个好处是在需要对pod进行升级更新的时候，deployment可以对其下多个不同版本的replicasets的副本个数进行此消彼长的控制来实现滚动升级，同时在升级有问题时，也能够对升级进行回滚。

比如当我们对deployment内的pod的docker image版本进行修改，并通过kubectl将请求发到api server之后

1. deployment控制器监控到这次update事件后会添加一个新的replicaset来负责添加新版本的pod，这个时候replicaset的副本数为0
2. deployment会首先将新的replicaset的副本数增加为1，这个时候就会有个新版本的pod被创建
3. deployment会将旧版本的replicaset的副本数减1，这个时候旧版本的pod就会减少一个
4. 这样交替操作，直到所有的旧版本的pod都被新版本的pod替代，这个时候就完成了滚动升级
   同样，如果升级遇到问题，需要回滚的话，也是通过交替的方式让pod回到旧版本。