- 阿里云数字新基建系列:云原生操作系统Kubernetes
- 罗建龙等
- 1286字
- 2021-02-26 12:12:18
2.2 控制器的产生与演进
虽然控制器是Kubernetes比较复杂的组件,但是控制器这个概念本身,对我们来说并不陌生。我们生活中使用的洗衣机、冰箱、空调等,都要有控制器才能正常工作。
在本节中我们通过思考一个简易冰箱的设计过程,来理解Kubernetes集群控制器的原理和实现。
2.2.1 设计一台冰箱
图2-2所示是一台简易的冰箱。冰箱包括五个组件,分别是箱体、制冷系统、照明系统、温控器和门。冰箱有两个典型使用场景:当有人打开冰箱门的时候,冰箱内的灯会自动开启;当有人调节温控器的时候,制冷系统会根据温度设置调节冰箱内的温度。
图2-2 一台简易的冰箱(只画出了部分组件)
2.2.2 统一操作入口
实际上,我们可以把冰箱简单抽象成图2-3中的两个部分:统一的操作入口和其他组件。用户只有通过操作入口才能操作冰箱,这个入口为用户提供了开关门和调节温控器这两个接口。用户调用这两个接口的时候,入口逻辑会调整冰箱门或温控器的状态。
图2-3 统一入口之后的冰箱系统
但是这里有一个问题,就是用户通过这两个接口,既不能让冰箱内部的灯打开,也不能调节冰箱内的温度,因为这两个接口和照明或者制冷系统没有任何必然的联系。
2.2.3 引入控制器
如图2-4所示,控制器就是为了解决上面的问题而产生的。控制器是用户操作和冰箱各个组件状态之间的一座桥梁。当用户打开门的时候,控制器“观察”到了门的变化,帮助用户打开冰箱内的灯;当用户调节温控器的时候,控制器“观察”到了用户设置的温度,替用户管理制冷系统以便调整冰箱内温度。
图2-4 增加了控制器的冰箱系统
2.2.4 统一管理控制器
因为冰箱有照明系统和制冷系统,所以与一个控制器管理着两个组件相比,为每个组件分别设置一个控制器是更为合理的选择。同时为了方便管理,可以设置一个控制器管理器来统一维护所有这些控制器,以确保这些控制器在正常工作,如图2-5所示。
图2-5 增加了控制器管理器之后的冰箱系统
2.2.5 Shared Informer
有了控制器和控制器管理器之后,冰箱的设计看起来已经相当不错了。但是随着冰箱功能的增加,必然会有新的控制器不断地加进来。这些控制器都需要通过冰箱入口,时刻监控自己“关心”的组件的状态变化,就如同照明系统控制器在时刻监控冰箱门状态一样。当大量控制器不断地和操作入口通信的时候,就会增加操作入口的压力。
如图2-6所示,这时我们可以把监控冰箱组件状态变化这件事情,交给一个新的模块Shared Informer来做。Shared Informer作为控制器的代理,替控制器监控冰箱组件的状态变化,并根据控制器的“喜好”,把不同组件状态的变化通知对应的控制器。
Shared Informer模块的增加,实际上可以极大地缓解冰箱操作入口的压力。
图2-6 增加了Shared Informer模块之后的冰箱系统
2.2.6 List Watcher
Shared Informer方便了控制器对冰箱组件的监控,而这个机制最核心的功能,当然是主动获取组件状态和被动接收组件状态变化的通知。这两个功能加起来,就是List Watcher机制,如图2-7所示。
假设Shared Informer和冰箱入口通过HTTP协议通信的,那么HTTP分块编码(chunked transfer encoding)就是实现List Watcher的一个好的选择。
控制器通过List Watcher给冰箱入口发送一个查询请求然后等待,当冰箱组件有变化的时候,入口通过分块的HTTP响应通知控制器。控制器“看到”Chunked响应,会认为响应数据还没有发送完成,所以会持续等待,如图2-8所示。
图2-7 增加了List Watcher之后的冰箱系统
图2-8 用HTTP分块编码机制实现List Watcher