阿里云数字新基建系列:云原生操作系统Kubernetes
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

4.1 节点增加原理

阿里云Kubernetes集群增加节点的方式有三类:添加已有节点、集群扩容和自动伸缩。其中,添加已有节点又可分为手动添加已有节点和自动添加已有节点。

节点的增加涉及的组件有节点准备、ESS(弹性伸缩)、集群管控、Cluster Autoscaler和调度器,如图4-1所示。

图4-1 集群节点增加原理

4.1.1 手动添加已有节点

节点准备,其实就是把一个普通的ECS实例安装配置成一个Kubernetes集群节点的过程。这个过程仅靠一条命令就可以完成。这条命令使用curl下载attach_node.sh脚本,然后以openapi token为参数,在ECS上运行。

这里token是一个<key, value>对的key,而value是当前集群的基本信息。阿里云Kubernetes集群的管控,在接到手动添加已有节点请求的时候,会生成这个<key, value>对,并把key作为token返回给用户。

这个token(key)存在的价值,是其可以让attach_node.sh脚本匿名在ECS上检索到集群的基本信息(value),而这些基本信息对节点准备至关重要。

总体上来说,节点准备就做两件事情:读和写。读即数据收集,写即节点配置。节点初始化过程如图4-2所示。

图4-2 节点初始化过程

这里的读写过程,绝大部分内容都比较基础,大家可以通过阅读脚本来了解细节。唯一需要特别说明的是Kubeadm把节点注册到Master的过程,此过程需要新加节点和集群Master之间建立互信。

一方面,新加节点从管控处获取的bootstrap token(与openapi token不同,此token是value的一部分内容),实际上是管控通过可信的途径从集群Master上获取的。新加节点使用这个bootstrap token连接Master,Master则可通过验证这个bootstrap token来建立对新加节点的信任。

另一方面,新加节点以匿名身份从Master kube-public命名空间中获取集群cluster-info,cluster-info包括集群CA(证书授权中心)证书,和使用集群bootstrap token对这个CA做的签名。新加节点使用从管控处获取的bootstrap token,对CA生成新的签名,然后将此签名与cluster-info内签名做对比,如果两个签名一致,则说明cluster-info和bootstrap token来自同一集群。新加节点因为信任管控,所以建立对Master的信任。集群节点注册机制如图4-3所示。

图4-3 集群节点注册机制

4.1.2 自动添加已有节点

自动添加已有节点,不需要人为把脚本拷贝到ECS命令行来完成节点准备的过程。管控使用了ECS Userdata的特性,把类似以上节点准备的脚本写入ECS Userdata,然后重启ECS并更换系统盘。当ECS重启之后,会自动执行Userdata里边的脚本,来完成节点添加的过程。

这里我们看到,attach_node.sh的参数与前一节的参数有很大的不同。其实这里的参数都是前一节value的内容,即管控创建并维护的集群基本信息。自动添加已有节点省略了通过key获取value的过程。

4.1.3 集群扩容

集群扩容与以上添加已有节点不同,此功能针对需要新购节点的情形。集群扩容的实现,在添加已有节点的基础上引入了ESS组件。ESS组件负责从无到有的过程,而剩下的过程与添加已有节点类似,即依靠ECS Userdata脚本来完成节点准备。图4-4所示为集群扩容过程。

图4-4 集群扩容过程

4.1.4 自动伸缩

前面几种方式是需要人为干预的伸缩方式,而自动伸缩的本质不同,因为它可以在业务需求量增加的时候,自动创建ECS实例并加入集群。为了实现自动化,这里引入了另外一个组件Cluster Autoscaler。集群自动伸缩包括两个独立的过程,如图4-5所示。

其中第一个过程主要用来配置节点的规格属性,包括设置节点的用户数据。这个用户数据和手动添加已有节点的脚本类似,不同的地方在于,其针对自动伸缩这种场景增加了一些专门的标记。attach_node.sh脚本会根据这些标记来设置节点的属性。

而第二个过程是实现自动增加节点的关键。这里引入了一个新的组件Autoscaler,它以Pod的形式运行在Kubernetes集群中。从理论上来说,我们可以把这个组件当作一个控制器。因为它的作用与控制器类似,基本上还是监听Pod状态,以便在Pod因为节点资源不足而不能被调度时,去修改ESS的伸缩规则来增加新的节点。

图4-5 集群自动伸缩过程

这里有一个知识点,即集群调度器衡量资源是否充足的标准是“预订率”,而不是“使用率”。这两者的差别,类似酒店房间预订率和实际入住率:完全有可能有人预订了酒店,但是并没有实际入住。在开启自动伸缩功能的时候,我们需要设置缩容阈值,就是“预订率”的下限。之所以不需要设置扩容阈值,是因为Autoscaler扩容集群依靠的是Pod的调度状态:当Pod因为节点资源“预订率”太高而无法被调度的时候,Autoscaler就会扩容集群。