K8S控制器理解-摘录自《云原生操作系统Kubernetes》

摘录自罗建龙等著的《云原生操作系统Kubernetes》，详细了解请查看原著。

虽然控制器是Kubernetes比较复杂的组件，但是控制器这个概念本身，对我们来说并不陌生。我们生活中使用的洗衣机、冰箱、空调等，都要有控制器才能正常工作。
以下我们通过思考一个简易冰箱的设计过程，来理解Kubernetes集群控制器的原理和实现。

设计一台冰箱

如下图所示是一台简易冰箱。

冰箱包括五个组件，分别是箱体、制冷系统、照明系统、温控器和门。

冰箱有两个典型使用场景：

• 当有人打开冰箱门的时候，冰箱内的灯会自动开启；
• 当有人调节温控器的时候，制冷系统会根据温度设置调节冰箱内的温度。

统一操作入口

实际上，我们可以把冰箱简单抽象成下图图中的两个部分：统一的操作入口和其他组件。用户只有通过操作入口才能操作冰箱，这个入口为用户提供了开关门和调节温控器这两个接口。用户调用这两个接口的时候，入口逻辑会调整冰箱门或温控器的状态。

但是这里有一个问题，就是用户通过这两个接口，既不能让冰箱内部的灯打开，也不能调节冰箱内的温度，因为这两个接口和照明或者制冷系统没有任何必然的联系。

引入控制器

如下图所示，控制器就是为了解决上面的问题而产生的。控制器是用户操作和冰箱各个组件状态之间的一座桥梁。当用户打开门的时候，控制器“观察”到了门的变化，帮助用户打开冰箱内的灯；当用户调节温控器的时候，控制器“观察”到了用户设置的温度，替用户管理制冷系统以便调整冰箱内温度。

统一管理控制器

因为冰箱有照明系统和制冷系统，所以与一个控制器管理着两个组件相比，为每个组件分别设置一个控制器是更为合理的选择。同时为了方便管理，可以设置一个控制器管理器来统一维护所有这些控制器，以确保这些控制器在正常工作。

Shared Informer

有了控制器和控制器管理器之后，冰箱的设计看起来已经相当不错了。但是随着冰箱功能的增加，必然会有新的控制器不断地加进来。这些控制器都需要通过冰箱入口，时刻监控自己“关心”的组件的状态变化，就如同照明系统控制器在时刻监控冰箱门状态一样。当大量控制器不断地和操作入口通信的时候，就会增加操作入口的压力。

如下图所示，这时我们可以把监控冰箱组件状态变化这件事情，交给一个新的模块Shared Informer来做。Shared Informer作为控制器的代理，替控制器监控冰箱组件的状态变化，并根据控制器的“喜好”，把不同组件状态的变化通知对应的控制器。

Shared Informer模块的增加，实际上可以极大地缓解冰箱操作入口的压力。

List Watcher

Shared Informer方便了控制器对冰箱组件的监控，而这个机制最核心的功能，当然是主动获取组件状态和被动接收组件状态变化的通知。这两个功能加起来，就是List Watcher机制。

假设Shared Informer和冰箱入口通过HTTP协议通信的，那么HTTP分块编码（chunked transfer encoding）就是实现List Watcher的一个好的选择。

控制器通过List Watcher给冰箱入口发送一个查询请求然后等待，当冰箱组件有变化的时候，入口通过分块的HTTP响应通知控制器。控制器“看到”Chunked响应，会认为响应数据还没有发送完成，所以会持续等待。