1、控制器，是k8s集群的“大脑”
控制器本身对我们来说并不陌生的。我们每天使用的洗衣机、冰箱、空调等，都是依靠控制器才能正常工作
K8S集群的核心组件逻辑上可以被分为三个部分：核心组件etc数据库，对etcd进行直接操作的入口组件API Server，以及其他组件调度器scheduler
2、类比学习法之“简易的冰箱”
通过分析简易冰箱的设计过程，来理解K8S 集群控制器的原理
这个冰箱包括五个组件：箱体、制冷系统、照明系统、温控器以及门。
冰箱只有两个功能：当有人打开冰箱门的时候，冰箱内的灯会自动开启；当有人按下温控器的时候，制冷系统会根据温度设置，调节冰箱内温度。
3、统一入口
这个入口提供给用户两个接口：开关门和调节温控器，那么入口又是通过什么方式来具体调整冰箱门和温控器状态的呢，这是个问题
4、控制器
控制器就是为了解决上边的问题产生的。控制器就是用户的操作，和冰箱各个组件的正确状态之间的一座桥梁：当用户打开门的时候，控制器观察到了门的变化，它
替用户打开冰箱内的灯；当用户按下温控器的时候，控制器观察到了用户设置的温度，它替用户管理制冷系统，调节冰箱内温度。
5、控制器管理器
冰箱有照明系统和制冷系统，显然相比一个控制器管理着两个组件，我们替每个组件分别实现一个控制器是更为合理的选择。同时我们实现一个控制器管理器来统一
维护所有这些控制器，来保证这些控制器在正常工作。
6、SharedInformer
我们把监控冰箱组件状态变化这件事情， 交给一个新的模块SharedInformer 来实现。SharedInformer 作为控制器的代理，替控制器监控冰箱
组件的状态变化，并根据控制器的喜好，把不同组件状态的变化，通知给对应的控制器。通过优化，这样的SharedInformer 可以极大的缓解冰箱入口的压力。
7、ListWatcher
假设SharedInformer 和冰箱入口通过http 协议通信的话，那么http 分块编码（chunked transfer encoding）就是实现ListWatcher 的一个好的选择。
控制器通过ListWatcher 给冰箱入口发送一个查询然后等待，当冰箱组件有变化的时候，入口通过分块的http 响应通知控制器。
控制器看到chunked 响应，会认为响应数据还没有发送完成，所以会持续等待。
8、举例
以上我们从一个简易冰箱的进化过程中，了解了控制器产生的意义，扮演的角色，以及实现的方式。现在我们回到K8S 集群。K8S 集群实现了大量的控制器，而且在可
以预见的未来，新的功能的控制器会不断出现，而一些旧的控制器也会被逐渐淘汰。目前来说，我们比较常用的控制器，如pod 控制器、deployment 控制器、
service 控制器、replicaset 控制器等。这些控制器一部分是由kube controller manager 这个管理器实现和管理， 而像route 控制器和service 控制器， 则由cloud controller manager 实现。
8.1 服务控制器
首先， 用户请求API Server 创建一个LoadBalancer 类型的服务，API
Server 收到请求并把这个服务的详细信息写入etcd 数据库。而这个变化，被服务控
制器观察到了。服务控制器理解LoadBalancer 类型的服务，除了包括存放在etcd
内部的服务记录之外，还需要一个SLB 作为服务入口，以及若干endpoints 作为服
务后端。所以服务控制器分别请求SLB 的云openapi 和API Server，来创建云上
SLB 资源，和集群内endpoints 资源。
8.2 路由控制器
在集群网络一章中，我们提到过，当一个节点加入一个K8S 集群的时候，集群
需要在VPC 路由表里增加一条路由，来搭建这个新加入节点到pod 网络的主干道。
而这件事情，就是路由控制器来做的。路由控制器完成这件事情的流程，与上边服务
控制器的处理流程非常类似，这里不再赘述。
结束语
基本上来说，K8S 集群的控制器，其实扮演着集群大脑的角色。有了控制器，K8S 集群才有机会摆脱机械和被动，变成一个自动、智能、有大用的系统。
