K8S从懵圈到熟练 – 集群伸缩原理

本文涉及的产品
云服务器 ECS,每月免费额度280元 3个月
云服务器ECS,u1 2核4GB 1个月
简介: 阿里云K8S集群的一个重要特性,是集群的节点可以动态的增加或减少。有了这个特性,集群才能在计算资源不足的情况下扩容新的节点,同时也可以在资源利用率降低的时候,释放节点以节省费用。 这篇文章,我们讨论阿里云K8S集群扩容与缩容的实现原理。

阿里云K8S集群的一个重要特性,是集群的节点可以动态的增加或减少。有了这个特性,集群才能在计算资源不足的情况下扩容新的节点,同时也可以在资源利用率降低的时候,释放节点以节省费用。

这篇文章,我们讨论阿里云K8S集群扩容与缩容的实现原理。理解实现原理,在遇到问题的时候,我们就可以高效地排查并定位原因。我们的讨论基于当前的1.12.6版本。

节点增加原理

阿里云K8S集群可以给集群增加节点的方式有,添加已有节点,集群扩容,和自动伸缩。其中,添加已有节点又可分为手动添加已有节点和自动添加已有节点。节点的增加涉及到的组件有,节点准备,弹性伸缩(ESS),管控,Cluster Autoscaler以及调度器。

a

手动添加已有节点

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

curl http:///public/pkg/run/attach//attach_node.sh | bash -s -- --openapi-token

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

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

总体上来说,节点准备就做两件事情,读和写。读即数据收集,写即节点配置。

b

这里的读写过程,绝大部分都很基础,大家可以通过阅读脚本来了解细节。唯一需要特别说明的是,kubeadm join把节点注册到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生成b新的签名,然后将此签名与cluster-info内签名做对比,如果两个签名一致,则说明cluster-info和bootstrap token来自同一集群。新加节点因为信任管控,所以建立对Master的信任。

c

自动添加已有节点

自动添加已有节点,不需要人为拷贝黏贴脚本到ECS命令行来完成节点准备的过程。管控使用了ECS userdata的特性,把类似以上节点准备的脚本,写入ECS userdata,然后重启ECS并更换系统盘。当ECS重启之后,会自动执行Userdata里边的脚本,来完成节点添加的过程。这部分内容,大家其实可以通过查看节点userdata来确认。

!/bin/bash

mkdir -p /var/log/acs

curl http:///public/pkg/run/attach/1.12.6-aliyun.1/attach_node.sh | bash -s -- --docker-version --token --endpoint --cluster-dns > /var/log/acs/init.log

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

集群扩容

集群扩容与以上添加已有节点不同,此功能针对需要新购节点的情形。集群扩容的实现,在添加已有节点的基础上,引入了弹性伸缩ESS组件。ESS组件负责从无到有的过程,而剩下的过程与添加已有节点类似,即依靠ECS userdata脚本来完成节点准备。下图是管控通过ESS从无到有创建ECS的过程。

d

自动伸缩

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

e

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

!/bin/sh

curl http:///public/pkg/run/attach/1.12.6-aliyun.1/attach_node.sh | bash -s -- --openapi-token --ess true --labels k8s.io/cluster-autoscaler=true,workload_type=cpu,k8s.aliyun.com=true

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

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

节点减少原理

与增加节点不同,集群减少节点的操作只有一个移除节点的入口。但对于用不同方法加入的节点,其各自移除方式略有不同。

首先,通过添加已有节点加入的节点,需要三步去移除:管控通过ECS API清楚ECS userdata;管控通过K8S API从集群中删除节点;管控通过ECS InvokeCommand在ECS上执行kubeadm reset命令清理节点。

其次,通过集群扩容加入的节点,则在上边的基础上,增加了断开ESS和ECS关系的操作。此操作由管控调用ESS API完成。

f

最后,经过Cluster Autoscaler动态增加的节点,则在集群CPU资源“预订率”降低的时候,由Cluster Autoscaler自动移除释放。其触发点是CPU“预订率”,即上图写Metrics的原因。

总结

总体上来说,K8S集群节点的增加与减少,主要涉及四个组件,分别是Cluster Autoscaler,ESS,管控以及节点本身(准备或清理)。根据场景不同,我们需要排查不同的组件。其中Cluster Autoscaler是一个普通的Pod,其日志的获取和其他Pod无异;ESS弹性伸缩有其专门的控制台,我们可以在控制台排查其伸缩配置、伸缩规则等相关子实例日志和状态;而管控的日志,可以通过查看日志功能来查看;最后,对于节点的准备与清理,其实就是排查对应的脚本的执行过程。

以上讲道理居多,希望对大家排查问题有所帮助。

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
存储 数据采集 Prometheus
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(一)
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(一)
1223 0
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(一)
|
11月前
|
弹性计算 运维 API
《企业运维之弹性计算原理与实践》——第五章 CMS&ESS——第五章(下)实验:ESS 结合 CMS 自动弹性伸缩(2)
《企业运维之弹性计算原理与实践》——第五章 CMS&ESS——第五章(下)实验:ESS 结合 CMS 自动弹性伸缩(2)
56 0
|
11月前
|
弹性计算 运维 监控
《企业运维之弹性计算原理与实践》——第五章 CMS&ESS——第五章(下)实验:ESS 结合 CMS 自动弹性伸缩(4)
《企业运维之弹性计算原理与实践》——第五章 CMS&ESS——第五章(下)实验:ESS 结合 CMS 自动弹性伸缩(4)
42 0
|
11月前
|
弹性计算 运维 负载均衡
《企业运维之弹性计算原理与实践》——第五章 CMS&ESS——第五章(下)实验:ESS 结合 CMS 自动弹性伸缩(1)
《企业运维之弹性计算原理与实践》——第五章 CMS&ESS——第五章(下)实验:ESS 结合 CMS 自动弹性伸缩(1)
84 0
|
11月前
|
弹性计算 运维
《企业运维之弹性计算原理与实践》——第五章 CMS&ESS——第五章(下)实验:ESS 结合 CMS 自动弹性伸缩(3)
《企业运维之弹性计算原理与实践》——第五章 CMS&ESS——第五章(下)实验:ESS 结合 CMS 自动弹性伸缩(3)
53 0
|
SQL 弹性计算 Prometheus
第五节:PolarDB-X 集群运维2(一)|学习笔记
快速学习第五节:PolarDB-X 集群运维2(一)
259 0
第五节:PolarDB-X 集群运维2(一)|学习笔记
|
存储 数据采集 Prometheus
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(三)
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(三)
491 0
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(三)
|
Prometheus 监控 Cloud Native
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(二)
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(二)
359 0
【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)(二)
|
存储 Kubernetes 负载均衡
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(二)
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(二)
160 0
【云原生Kubernetes系列项目实战第一篇】k8s集群+高可用负载均衡层+防火墙( 提及年少一词,应与平庸相斥)(二)
|
弹性计算 负载均衡 监控
图文详解弹性伸缩的工作流程
本文主要介绍弹性伸缩的工作流程。
1185 0