controller-manager
controller-manager是这些controller的管理者，控制器有很多，如：
replication controller
node controller
resourceQuota controller
namespace controller
serviceAccount controller
token controller
service controller
endpoint controller
deployment controller
router controller
volume controller
等等，每种controller都负责一种特定资源的控制流程。
replication controller
rc的作用是 确保与rc关联的pod数量在任何时候都保持预设值。
pod的重启策略是always的情况下，rc才会动态调整pod。
pod被创建后都不会消失，只有异常情况下，比如长时间处于failed状态（超时参数由系统设定），rc会回收这个pod，并在其他节点上创建pod副本。
rc创建完pod后，即使rc的yaml文件变更了，已创建出来的pod也不会更新，但是如果rc重新创建了pod副本，则新的pod是基于更改后的yaml创建的。
pod只需要修改标签就可以脱离rc的管控。
deployment controller
随着k8s发展，旧的rc已无法满足使用需求，所以有了deployment，旧有的rc已不再升级、维护。
deployment controller实际控制两类相关的资源对象：deployment和replicaSet。
创建deployment之后，deployment controller会自动创建replicaSet
deployment的滚动升级，也是deployment自动创建新的rs来实现的。
deployment作用
确保当前集群中有且只有N个pod实例，N是在rc中定义的pod副本数量
通过调整spec.relicas属性的值来实现系统扩容或者缩容。
通过改变pod模板（主要是镜像版本）来实现系统的滚动升级。
使用场景
重新调度。比如pod异常终止，deployment会自动回收pod并重新调度使pod达到预设值。
弹性伸缩。手动或者自动扩容代理修改副本控制器spec.replicas属性值，实现弹性伸缩。
滚动更新。deployment被设计成逐个替换pod来辅助服务的滚动更新。
node controller
通过api实时获取node状态，并尝试修改nodeStatusMap中节点状态信息。
controller manager在启动时设置了--cluster-cidr参数，为每个没有设置Spec.PodCIDR的Node都生成一个CIDR地址，并用该CIDR地址设置节点的SpecPodCIDR属性，防止不同节点的CIDR地址冲突。
逐个读取node信息，并将该节点的信息和nodeStatusMap中节点的状态比较；
1）以下情况，都会使用node controller所在节点的系统时间作为探测时间和节点状态变化时间：
1、判断没有收到kubelet发送的信息。
2、第一次收到节点kubelet发送的信息。
3、node controller处理过程中节点状态变成非健康状态。
4、在指定时间内收到节点信息且状态发生变化。
2）以下情况使用node controller所在节点的系统时间作为探测时间，将上次节点信息中的节点状态变化时间作为该节点的状态变化时间：
1、在指定时间内收到节点信息且节点状态无变化。
3）逐个读取节点信息，
1、如果节点状态变为非就绪状态，则将节点加入待删除队列，否则将节点从该队列中删除。
2、如果节点状态为非就绪状态，且系统指定了Cloud Provider，则node controller调用Cloud Provider查看节点，若发现节点故障，则删除etcd中的节点信息，并删除与该节点相关的pod等资源信息。
resourceQuota controller
作用：防止某些业务进程有缺陷占用过多的系统物理资源，从而导致其他的进程出现异常。
目前k8s有三个层次的资源配额管理
1）容器级别，对CPU、memory进行限制。
2）pod级别，对一个pod内所有的容器进行资源限制。
3）namespace级别，为namespace（多租户）级别的资源限制，包括：pod数量，rc数量，svc数量，resourceQuota数量，secret数量以及可持有的PV数量。
如果pod定义中声明了limitRanger，则通过api创建或修改pod资源时，admission control会计算当前配额的使用情况，如果不符合配额或者约束，则创建对象失败。
对于定义了resourceQuota的namespce，resourceQuota controller会定期统计和生成该namespace下各类对象的资源使用总量，统计包括pod、svc、rc、secret和pv等对象的实例个数，以及该ns下所有container实例的资源使用量，然后将这些结果写入etcd的resourceQuotaStatusStorage目录（resourceQuotas/status）下。
namespace controller
用户通过api 创建ns并保存在etcd中，ns controller定时通过api读取这些ns信息，如果ns被api标识为优雅删除（通过设置删除期限实现，即设置DeletionTimestamp属性），则将该ns的状态设置为Terminating并保存在etcd中。同时ns会删除其下的所有资源。
ns被设为Terminating后，由admission controller的nsLifecycle插件来阻止为该ns创建新的资源。同时ns controller 删除该ns所有资源后，ns controller会对该ns执行finalize操作，删除ns的spec.finalizers域中的信息。
如果ns controller观察到ns设置了删除期限，同时ns的spec.finalizers阈值是空的，那么ns controller将通过api删除该ns资源。
service controller / endpoints controller
endpoints controller
endpoints表示一个service对应的所有pod副本的访问地址，endpoints controller就是负责生成和维护所有endpoints对象的的控制器。
ep controller负责监听svc和对应pod副本变化，如果监测到svc被删除，则删除和该svc同名的endpoints对象。
如果监听到新的svc被创建或者被修改，则根据svc信息获取相关pod列表，然后创建或更新svc对应的endpoints对象。
如果监听到pod事件，则更新它所对应的svc的endpoints对象（增加、删除、修改对应endpoint条目）
每个node上的kube-proxy会获取每个svc的endpoints，实现了svc的负载均衡功能。
service controller
service controller 是k8s集群和外部的云平台之间的一个接口管理器，监听svc的变化，来调整对应资源的创建、删除以及更新路由转发表（根据endpoints的条目）。