还不会用 K8s 集群控制器?那你会用冰箱吗?(多图详解)

作者|阿里云售后技术专家声东导读:当我们尝试去理解K8s集群工作原理的时候,控制器(Controller)肯定是一个难点。这是因为控制器有很多,具体实现大相径庭;且控制器的实现用到了一些较为晦涩的机制,不易理解。但是,我们又不能绕过控制器,因为它是集群的“大脑”。今天这篇文章,作者通过分析一个简易冰箱的设计过程,来帮助读者深入理解集群控制器的产生,功能以及实现方法。K8s集群核心组件大图下图是K8...

还不会用 K8s 集群控制器?那你会用冰箱吗?(多图详解)

file
作者 | 阿里云售后技术专家�声东

导读:当我们尝试去理解 K8s 集群工作原理的时候,控制器(Controller)肯定是一个难点。这是因为控制器有很多,具体实现大相径庭;且控制器的实现用到了一些较为晦涩的机制,不易理解。但是,我们又不能绕过控制器,因为它是集群的“大脑”。今天这篇文章,作者通过分析一个简易冰箱的设计过程,来帮助读者深入理解集群控制器的产生,功能以及实现方法。

K8s 集群核心组件大图

下图是 K8s 集群的核心组件,包括数据库 etcd,调度器 Scheduler,集群入口 API Server,控制器 Controller,服务代理 kube-proxy 以及直接管理具体业务容器的 kubelet。

这些组件逻辑上可以被分为三个部分:

  • 核心组件 etc 数据库;
  • 对 etcd 进行直接操作的入口组件 API Server;
  • 其他组件, 这里的“其他组件”之所以可以被划分为一类,是因为它们都可以被看做是集群的控制器。

file

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

控制器原理

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

简易的冰箱

这个冰箱包括五个组件:箱体、制冷系统、照明系统、温控器以及门。

冰箱只有两个功能:

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

file

统一入口

对于上边的冰箱,我们可以简单抽象成两个部分:统一的操作入口和冰箱的所有组件。

在这里,用户只有通过入口,才能操作冰箱。这个入口提供给用户两个接口:开关门和调节温控器。用户执行这两个接口的时候,入口会分别调整冰箱门和温控器的状态。

file

但是这里有一个问题,就是用户通过这两个接口,既不能让冰箱内部的灯打开,也不能调节冰箱的温度。

控制器

控制器就是为了解决上边的问题产生的。控制器就是用户的操作,和冰箱各个组件的正确状态之间的一座桥梁:

  • 当用户打开门的时候,控制器观察到了门的变化,它替用户打开冰箱内的灯;
  • 当用户按下温控器的时候,控制器观察到了用户设置的温度,它替用户管理制冷系统,调节冰箱内温度。

file

控制器管理器

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

file

SharedInformer

上边的控制器和控制器管理器,看起来已经相当不错了。但是当冰箱功能增加,势必有很多新的控制器加进来。这些控制器都需要通过冰箱入口,时刻监控自己关心的组件的状态变化。比如照明系统控制器就需要时刻监控冰箱门的状态。当大量控制器不断的和入口通信的时候,就会增加入口的压力。

这个时候,我们把监控冰箱组件状态变化这件事情,交给一个新的模块 SharedInformer 来实现。

SharedInformer 作为控制器的代理,替控制器监控冰箱组件的状态变化,并根据控制器的喜好,把不同组件状态的变化,通知给对应的控制器。通过优化,这样的 SharedInformer 可以极大的缓解冰箱入口的压力。

file

ListWatcher

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

file

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

file

举例说明

以上我们从一个简易冰箱的进化过程中,了解了控制器产生的意义,扮演的角色,以及实现的方式。现在我们回到K8s 集群。K8s 集群实现了大量的控制器,而且在可以预见的未来,新的功能的控制器会不断出现,而一些旧的控制器也会被逐渐淘汰。


目前来说,我们比较常用的控制器,如 Pod 控制器、Deployment 控制器、Service 控制器、Replicaset 控制器等。这些控制器一部分是由 kube controller manager 这个管理器实现和管理,而像 route 控制器和 service 控制器,则由 cloud controller manager 实现。


之所以会出现 cloud controller manager,是因为在不同的云环境中,一部分控制器的实现,会因为云厂商、云环境的不同,出现很大的差别。这类控制器被划分出来,由云厂商各自基于 cloud controller manager 分别实现。


这里我们以阿里云 K8s 集群 cloud controller manager 实现的 route� 控制器和 service 控制器为例,简单说明 K8s 控制器的工作原理。

服务控制器

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

file

路由控制器

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

file

结束语

基本上来说,K8s 集群的控制器,其实扮演着集群大脑的角色。有了控制器,K8s 集群才有机会摆脱机械和被动,变成一个自动、智能、有大用的系统。

源文地址:https://www.guoxiongfei.cn/cntech/26841.html