DEVOPS: K8s集群控制器

概述

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

控制器原理

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

1 ) 简易的冰箱

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

2 ) 统一入口

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

3 ）控制器

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

4 ）控制器管理器

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

5 ）SharedInformer

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

6 ) ListWatcher

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

7 ) 举例

• 以上我们从一个简易冰箱的进化过程中，了解了控制器产生的意义，扮演的角色，以及实现的方式
• 现在我们回到 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 控制器的工作原理

8 ）服务控制器

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

9 ）路由控制器

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

总结

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