189 8069 5689
这篇文章给大家介绍K8s的集群伸缩原理是什么，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
阿里云 K8s 集群的一个重要特性，是集群的节点可以动态的增加或减少。有了这个特性，集群才能在计算资源不足的情况下扩容新的节点，同时也可以在资源利用率降低的时候，释放节点以节省费用。
我们将讨论阿里云 K8s 集群扩容与缩容的实现原理。理解实现原理，在遇到问题的时候，我们就可以高效地排查并定位原因。
阿里云 K8s 集群可以给集群增加节点的方式有，添加已有节点，集群扩容，和自动伸缩。其中，添加已有节点又可分为手动添加已有节点和自动添加已有节点。节点的增加涉及到的组件有，节点准备，弹性伸缩（ESS），管控，Cluster Autoscaler 以及调度器。
节点准备，其实就是把一个普通的 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），而这些基本信息，对节点准备至关重要。
总体上来说，节点准备就做两件事情，读和写。读即数据收集，写即节点配置。
这里的读写过程，绝大部分都很基础，大家可以通过阅读脚本来了解细节。唯一需要特别说明的是，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 生成新的签名，然后将此签名与 cluster-info 内签名做对比，如果两个签名一致，则说明 cluster-info 和 bootstrap token 来自同一集群。新加节点因为信任管控，所以建立对 Master 的信任。
自动添加已有节点，不需要人为拷贝黏贴脚本到 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 的过程。
前边三种方式是需要人为干预的伸缩方式，而自动伸缩的本质不同，是它可以在业务需求量增加的时候，自动创建 ECS 实例并加入集群。为了实现自动化，这里引入了另外一个组件 Cluster Autoscaler。集群自动伸缩包括两个独立的过程。
其中第一个过程，主要用来配置节点的规格属性，包括设置节点的用户数据。这个用户数据和手动添加已有节点的脚本类似，不同的地方在于，其针对自动伸缩这种场景，增加了一些专门的标记。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 完成。
最后，经过 Cluster Autoscaler 动态增加的节点，则在集群 CPU 资源“预订率”降低的时候，由 Cluster Autoscaler 自动移除释放。其触发点是 CPU“预订率”，即上图写 Metrics 的原因。
总体上来说，K8s 集群节点的增加与减少，主要涉及四个组件，分别是 Cluster Autoscaler，ESS，管控以及节点本身（准备或清理）。根据场景不同，我们需要排查不同的组件。其中 Cluster Autoscaler 是一个普通的 Pod，其日志的获取和其他 Pod 无异；ESS 弹性伸缩有其专门的控制台，我们可以在控制台排查其伸缩配置、伸缩规则等相关子实例日志和状态；而管控的日志，可以通过查看日志功能来查看；最后，对于节点的准备与清理，其实就是排查对应的脚本的执行过程。
以上讲道理居多，但如果结合问题诊断实践，一定会对大家的运维工作有所帮助。
关于K8s的集群伸缩原理是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。