【读书笔记/深入理解K8S】集群控制器

前言

这几天看完了阿里云团队基于阿里云本身实践出版的书《深入理解Kubernetes》，略有收获，为了避免读完就忘。特地写几篇读书笔记来巩固一下。

如何理解集群控制器

k8s集群大体框架

我们知道，集群控制器是k8s集群的大脑。但是，控制器又是一个很难理解的点，因为控制器种类众多，具体实现大相径庭，并且还经常用到一些晦涩的机制。因此，我们本章就来详细拆解一下这部分内容。

我们知道，k8s集群核心组件有以下：

1. 数据库etcd
2. 调度器schedule
3. 集群入口 API Server
4. 控制器 Controller
5. 服务代理kube-proxy
6. 直接管理具体业务的 kubelet

他们大体可以分为三个部分：

1. etcd数据库
2. 对etcd进行操作的入口组件API Server
3. 其他组件（都可以算作集群的控制器）

控制器

对k8s集群有了大体的一个框架后，我们现在来看看什么是控制器。

其实在日常生活中，我们经常能看到控制器。比如有说：洗衣机，冰箱，空调等。这些设备都是用控制器来控制的，因此我们可以与k8s集群的控制器进行类比，来领会什么是k8s集群控制器。

就拿冰箱来说，假如冰箱可以分为这几个系统：

1. 箱体
   1. 制冷系统
   2. 照明系统
2. 温控器
3. 门

我们会发现，冰箱的温控器控制制冷系统，门控制照明系统。同时，我们可以给冰箱抽象一个统一的入口，那么这个入口就会给用户提供两个接口：门的开关和温控器的调节。这两个接口会调整门和温控器的状态，从而控制整个冰箱的运行。

同时，我针对这两个接口实现控制器，得到以下的拓扑图：

不过该系统还有个问题，假如这个冰箱升级进化，多了许多新功能，升级成了变形金刚。那么这个架构就会有一个新问题出现——过多的控制器都需要时刻地通过统一入口监控自己关心的组件的状态变化，这给统一入口增加太多的压力，而且本身性能并不好。

这时，我们可以在中间加一层SharedInformer，用来记录系统中所有组件的状态变化，当某个组件状态发生变化，就立刻通知相应的控制器，这样就避免了控制器需要一直去监控，节省了大量的开销。

我们需要知道，k8s集群里，每个系统的物理底层是一个个物理机or虚拟机，他们之间需要通信。那我们想一下这里的SharedInformer该如何得知各个组件状态的变化呢？这时候，我们可以采用http协议的chunked编码，chunked编码相比于传统的http协议不需要Content—Length，而是通过分块的编码，每一个分块用 "
/r/n"来区分，当全部结束后，用"0/r/n"来结束，且该编码基于http1.1，可以支持长连接，就可以一直监听所有组件的状态变化信息。我们将这种方式抽象成一个名字叫:listwatch

最后，我们的一个功能完善的控制器就完成了，现在我们来看看k8s集群的控制器。

k8s集群控制器

冰箱的进化给我们展示了一个控制器的进化流程。在k8s中，我们有许多常用的控制器，比如：

• pod控制器
• deployment控制器
• service控制器
• replicaset控制器
• ...

这些控制器统一由kube controller manager这个管理器进行实现和管理。

而除了这些，还有一些控制器是由cloud controller manager来进行实现和管理，之所以有这样的区分，是因为各家云厂商的云环境的不同。比如阿里云的route控制器和service控制器。

service控制器

流程：

1. 用户请求API Server创建一个LoadBalancer类型的服务
2. API Server将这个请求服务的详细信息写入etcd数据库
3. 服务控制器观察到该请求所需资源，请求SLB的云openapi和API Server创建资源

路由控制器

与service控制器大同小异，不再赘述。