我们在回顾下pod的启动流程：
- 用户通过kubectl，向api-server 发起请求
- api-server接受请求，并将数据写入etcd
- kube-scheduler通过watch检测到未绑定node 的pod，调度pod到某一node上，并通知给api-server，api-server将其写入etcd
- kubelet通过watch 检测到有新的pod调度过来，通过container runtime 运行新pod
- kubelet 通过cri 拉起pause 容器
- kubelet 通过cni 为pause容器创建网络(虚拟网络设备，ip地址)
- kubelet 拉起业务容器，业务容器和pause容器共享同一个网络空间
1.Controller Manager原理解析
一般来说，智能系统和自动系统通常会通过一个"操作系统"不断修正系统的工作状态 。在 Kubernetes 集群中，每个 Controller 都是这样的一个"操作系统"，它们通过 API Server提供的 (List-Watch) 接口实时监控集群中特定资源的状态变化，当发生各种故障导致某资渥对象的状态变化时， Controller 会尝试将其状态调整为期望的状态 。 比如当某个 Node意外岩机时， Node Controller 会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态下 。 Controller Manager 是 Kubernetes 中各种操作系统的管理者，是集群内部的管理控制中心，也是 Kubernetes 自动化功能的核心。
如下图所示，Controller Manager内部包含Replication Controller、Node Controller、ResourceQuota Controller、Namespace Controller、ServiceAccount Controller、Token Controller、Service Controller、Endpoint Controller、Deployment Controller、Router Controller、Volume Controller等资源控制器，每种Controller都负责一种特定资源的控制流程，而Controller Manager正式这些Controller的核心管理者。
2.副本调度控制器
具有副本调度控制功能的两个Controller：Deployment Controller和Replication Controller
2.1 Replication Controller
Replication Controller（简称RC）的核心作用是确保集群中某个RC关联的Pod副本数量 任何时候都保持预设值。如果发现Pod的副本数量超过预设值，则RC会销毁一些副本，反之，则会重新创建一些副本。注意：只有当Pod的重启策略是Always时（RestartPolicy=Always），RC才会管理该Pod的操作（增加、销毁、重启等）。在通常情况下， Pod 对象被成功创建后都不会消失，唯一 的例外是 Pod 处于succeeded 或 failed 状态的时间过长（超时参数由系统设定），此时该 Pod 会被系统自动回收，管理该 Pod 的副本控制器将在其他工作节点上重新创建 、 运行该 Pod 副本。
随着Kubernetes的不断升级迭代，旧的RC已不能满足需求，所以就有了Deployment，Deployment可以视为Replication Controller的替代者
2.2 Deployment Controller
作用：
1.确保在当前集群中有且仅有N个Pod实例，N是RC中定义的pod副本数量
2.通过调整spec.replicas属性来实现系统扩容或缩容
3.通过修改Pod模板（主要是镜像版本）来实现系统的滚动升级
主要使用三个场景：重新调度、弹性伸缩、滚动更新
3.Node Controller
kubelet进程在启动时通过API Server注册自身节点信息，并定时向API Server汇报状态信息，API Server在接收到这些信息后，会将这些信息更新到etcd中，在etcd中存储的节点信息包括节点健康状态、节点资源、节点名称、节点地址信息、操作系统版本、Docker版本、kubelet版本等。节点健康状态包括就绪（True）、未就绪（False）、未知（Unknown）。
Node Controller通过API Server实时获取node的相关信息，实现管理和监控集群中各个Node的相关功能，Node Controller核心工作流程如下图：
4.ResourceQuota Controller
资源配额管理确保指定的资源对象在任何时候都不会超量占用系统物理资源，避免由于某些业务进程在设计或实现上的缺陷导致整个系统运行紊乱甚至意外岩机，对整个集群的平稳运行和稳定性都有非常重要的作用 。
目前kubernetes支持如下三个层次的资源配额管理：
1.容器级别：可以对CPU和Memory进行限制
2.Pod级别：可以对一个Pod内所有容器的可用资源进行限制
3.Namespace级别：为Namespace多租户级别的资源限制，包括：Pod数量、RC数量、Service数量、Secret数量和可持有的PV数量
Kubernetes的配额管理是通过Admission Control（准入控制）来控制的，Admission Control当前提供了两种方式的配额约束，分别是LimitRanger与ResourceQuota，其中LimitRanger作用于Pod和Container；ResourceQuota则作用于Namespace，限定一个Namespace里各种资源的使用总额
流程图如下：
5.Namespace Controller
用户通过 API Server 可以创建新的 Namespace 并将其保存在 etcd 中， Namespace Controller 定时通过 API Server 读取这些 Namespace 的信息 。 如果 Namespace 被 API 标识为优雅删除（通过设置删除期限实现，即设置 DeletionTimestamp 属性），则将该 NameSpace的状态设置成 Terminating 并保存在 etcd 中 。 同时， Namespace Controller 删除该 Namespace下的 ServiceAccount、RC、Pod、Secret、PersistentVolurne、ListRange、ResourceQuota 和Event 等资源对象。
在 Namespace 的状态被设置成 Terminating 后，由 Admission Controller 的 NamespaceL让ecycle插件来阻止为该 Namespace 创建新的资源 。 同时，在 Namespace Controller 删除该Namespace 中的所有资源对象后，Namespace Controller会对该Namespace执行finalize操作，删除Namespace的spec.finalizers域中的信息 。
如果Namespace Controller观察到Namespace设置了删除期限，同时Namespace的spe c.finalizers域值是空的，那么Namespace Controller将通过API Server删除该Namespace资源
6.Service Controller 与 Endpoints Controller
Endpoints 表示一个 Service 对应的所有 Pod 副本的访问地址， Endpoints Controller 就是负责生成和维护所有 Endpoints 对象的控制器 。
Endpoints Controller 负责监听Service和对应的Pod副本的变化，如果监测到Service
被删除，则删除和该 Service同名的Endpoints 对象。如果监测到新的Service被创建或者修改，则根据该Service信息获得相关的 Pod 列表，然后创建或者更新Service对应的Endpoints 对象。如果监测到Pod的事件，则更新它所对应的Service的Endpoints对象（增加、删除或者修改对应的 Endpoint条目）。