K8S系列文章之基础理论篇

第一部分：理解控制器

简介：当我们尝试去理解 Kubernetes 集群工作原理的时候，控制器肯定是一个难点。这是因为
控制器有很多，具体实现大相径庭；且控制器的实现用到了一些较为晦涩的机制，不易理解。但
是，我们又不能绕过控制器，因为它是集群的“大脑”。
当我们尝试去理解 Kubernetes 集群工作原理的时候，控制器肯定是一个难点。这是因为控制器有很
多，具体实现大相径庭；且控制器的实现用到了一些较为晦涩的机制，不易理解。但是，我们又不能绕
过控制器，因为它是集群的“大脑”。在这，我们通过分析一个简易冰箱的设计过程，来深入理解集群控
制器的产生，功能以及实现方法。
下图是 Kubernetes 集群的核心组件，包括数据库 etcd，调度器 scheduler，集群入口 API Server，控
制器 Controller，服务代理 kube-proxy 以及直接管理具体业务容器的 kubelet。这些组件逻辑上可以
被分为三个部分：核心组件 etcd 数据库，对 etcd 进行直接操作的入口组件 API Server，以及其他组
件。这里的“其他组件”之所以可以被划分为一类，是因为它们都可以被看做是集群的控制器。
在这里插入图片描述

今天我们要讲的就是集群控制器原理。

1.2 控制器原理

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

1.2.1 简易的冰箱

这个冰箱包括五个组件：箱体、制冷系统、照明系统、温控器以及门。冰箱只有两个功能：当有人打开
冰箱门的时候，冰箱内的灯会自动开启；当有人按下温控器的时候，制冷系统会根据温度设置，调节冰
箱内温度。
在这里插入图片描述

1.2.2 统一入口

对于上边的冰箱，我们可以简单抽象成两个部分：统一的操作入口和冰箱的所有组件。在这里，用户只
有通过入口，才能操作冰箱。这个入口提供给用户两个接口：开关门和调节温控器。用户执行这两个接
口的时候，入口会分别调整冰箱门和温控器的状态。

在这里插入图片描述

1.2.3 控制器

控制器就是为了解决上边的问题产生的。控制器就是用户的操作，和冰箱各个组件的正确状态之间的一
座桥梁：当用户打开门的时候，控制器观察到了门的变化，它替用户打开冰箱内的灯；当用户按下温控
器的时候，控制器观察到了用户设置的温度，它替用户管理制冷系统，调节冰箱内温度。

在这里插入图片描述

1.2.4 控制器管理器

冰箱有照明系统和制冷系统，显然相比一个控制器管理着两个组件，我们替每个组件分别实现一个控制
器是更为合理的选择。同时我们实现一个控制器管理器来统一维护所有这些控制器，来保证这些控制器
在正常工作。

在这里插入图片描述

1.2.5 SharedInformer

上边的控制器和控制器管理器，看起来已经相当不错了。但是当冰箱功能增加，势必有很多新的控制器
加进来。这些控制器都需要通过冰箱入口，时刻监控自己关心的组件的状态变化。比如照明系统控制器
就需要时刻监控冰箱门的状态。当大量控制器不断的和入口通信的时候，就会增加入口的压力。
这个时候，我们把监控冰箱组件状态变化这件事情，交给一个新的模块 SharedInformer 来实现。
SharedInformer 作为控制器的代理，替控制器监控冰箱组件的状态变化，并根据控制器的喜好，把不
同组件状态的变化，通知给对应的控制器。通过优化，这样的 SharedInformer 可以极大的缓解冰箱入
口的压力。

在这里插入图片描述

1.2.6 ListWatcher

在这里插入图片描述
假设 SharedInformer 和冰箱入口通过 http 协议通信的话，那么 http 分块编码（chunked transfer
encoding）就是实现 ListWatcher 的一个好的选择。控制器通过 ListWatcher 给冰箱入口发送一个查询
然后等待，当冰箱组件有变化的时候，入口通过分块的 http 响应通知控制器。控制器看到 chunked 响
应，会认为响应数据还没有发送完成，所以会持续等待。
在这里插入图片描述

1.3 举例

以上我们从一个简易冰箱的进化过程中，了解了控制器产生的意义，扮演的角色，以及实现的方式。现
在我们回到 Kubernetes 集群。Kubernetes 集群实现了大量的控制器，而且在可以预见的未来，新的
功能的控制器会不断出现，而一些旧的控制器也会被逐渐淘汰。
目前来说，我们比较常用的控制器，如 pod 控制器、deployment 控制器、service 控制器、replicaset
控制器等。这些控制器一部分是由 kube controller manager 这个管理器实现和管理，而像 route 控制
器和 service 控制器，则由 cloud controller manager 实现。
之所以会出现 cloud controller manager，是因为在不同的云环境中，一部分控制器的实现，会因为云
厂商、云环境的不同，出现很大的差别。这类控制器被划分出来，由云厂商各自基于 cloud controller
manager 分别实现。
这里我们以阿里云 Kubernetes 集群 cloud controller manager 实现的 route 控制器和 service 控制器
为例，简单说明 Kubernetes 控制器的工作原理。

1.3.1 服务控制器

首先，用户请求 API Server 创建一个 LoadBalancer 类型的服务，API Server 收到请求并把这个服务的
详细信息写入 etcd 数据库。而这个变化，被服务控制器观察到了。服务控制器理解 LoadBalancer 类
型的服务，除了包括存放在 etcd 内部的服务记录之外，还需要一个 SLB 作为服务入口，以及若干
endpoints 作为服务后端。所以服务控制器分别请求 SLB 的云 openapi 和 API Server，来创建云上
SLB 资源，和集群内 endpoints 资源。
在这里插入图片描述

1.3.2 路由控制器

在集群网络一章中，我们提到过，当一个节点加入一个 Kubernetes 集群的时候，集群需要在 VPC 路由
表里增加一条路由，来搭建这个新加入节点到 pod 网络的主干道。而这件事情，就是路由控制器来做
的。路由控制器完成这件事情的流程，与上边服务控制器的处理流程非常类似，这里不再赘述。
在这里插入图片描述