开发者社区> 以尘> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

动手实操,让你的 Kubernetes 集群弹起来!

简介: 本文将对于集群自动弹性伸缩(cluster-autosclaer)进行介绍,并在 ACK 集群上进行实操。
+关注继续查看

目录

什么是集群自动弹性伸缩?

为什么需要集群自动弹性伸缩?

集群自动弹性伸缩的原理是什么?

实践环节


什么是集群自动弹性伸缩?

集群自动弹性伸缩(cluster-autoscaler) 是一个可以自动扩缩 Kubernetes 集群规模的工具,独立于 Kubernetes 主代码仓库以外,与 VPA、Addon-Resizer 等组件共同维护在 kubernetes/autoscaler 仓库,并且各云厂商贡献了对标准扩展接口(CloudProvider)的实现。


为什么需要集群自动弹性伸缩?

cluster-autosclaer 属于弹性伸缩的重要一部分,只要谈到弹性伸缩,一般都会首先想到两个关键词:成本、效率


cluster-autoscaler 根据用户配置的策略,自动的调整集群的规模,优势主要体现在:

  • 资源动态调整:在业务高峰期时可以结合对工作负载的弹性扩容来调整扩大集群规模,承载更大的计算量。业务低峰期,动态的对工作负载分布进行调整,对节点进行排水、回收,以此降低计算资源成本。
  • 屏蔽底层资源:可以让开发者专注于业务开发,屏蔽对底层资源的感知,降低运维人员的运维难度以及运维成本。


集群自动弹性伸缩的原理是什么?

cluster-autoscaler 声明了 CloudProvider接口,通过抽象的 NodeGroup概念来对接各云厂商的弹性伸缩服务(比如阿里云的 ess,华为云的 as 等)。


提示:

CloudProvider Interface: https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/cloud_provider.go#L89


按照用户指定的策略定期的去检查集群中 Pending 状态的 Pod 以及 Node 的资源水位,来执行 Scale操作,其中主要是 Scale Up 以及 Scale Down操作,分别对应节点的弹出以及销毁。


Scale Up

ScaleUp 的逻辑流程如下:

  1. cluster-autoscaler 会对由于资源不足导致 Pending 状态的 Pod 进行监听。
  2. 获取配置的多个弹性伸缩组,当存在上述 Pending 的Pod 时,会根据需要的资源、Pod 调度需要的条件(Label,Taint,GPU等)在伸缩组中进行匹配筛选。
  3. 如果可以满足调度的条件,会根据计算结果驱动对应伸缩组创建节点


我们来画一下流程会更直观一点

image



上面我们有提到,Scale Up 的逻辑是从多个弹性伸缩组中去判断筛选,去弹出新的节点。


这里就会涉及到弹性伸缩组的选择策略,去选择合适的 NodeGroup ,官方声明了如下 6 种策略,通过 expander 参数可以指定,不同云厂商对于策略的支持有限的,并不是支持所有策略

  • random:随机选择
  • most-pods:选择可以容纳最多当前 Pods 的伸缩组,会与 Pending Pod 亲和性等相关
  • least-waste:选择一个资源浪费最少的节点池进行扩容
  • price:选择性价比最高的伸缩组
  • priority:优先级策略,可以在 kube-system 下的 cluster-autoscaler-priority-expander configmap 配置,按照配置伸缩组的优先级进行选择,可以参考 priority
  • grpc:通过 GRPC 调用外部的选择服务来选择伸缩组,相当于自定义扩展


Scale Down

对于节点回收这种比较敏感且可能造成数据丢失的功能,并不是强制开启的,cluster-autoscaler 的参数中可以通过 scale-down-enabled 来控制。


Scale Down 的流程如下:

  1. 当 cluster-autoscaler 监听到 Node 的利用率低于设置的阈值时scale-down-utilization-threshold 参数)会触发判断
  2. 尝试判断是否可以将此 Node 上的 Pod 彻底驱逐到其他的节点,有些特殊的 Pod 不在判断范围内(比如 skip-nodes-with-system-pods 参数可以控制是否跳过 kube-system 等 Pod)
  3. 判断完成后,将先驱逐节点上的 Pod 到其他节点,再移除节点


同样的,我们来画一下流程图会更清晰一些

image


实践环节

百说不如一练,接下来我们动手实践一下,实践环节将基于 ACK 的自动伸缩能力来进行,并结合 HPA 来使用 ClusterAutoscaler。


前期准备

准备阶段,我们需要准备如下内容:


提示:

本次演示应用发布以及 HPA 在 Erda 平台上操作,相关操作可以直接替换为其他 PaaS 平台的弹性伸缩或原生 kubectl 操作。


集群自动弹性伸缩配置

首先我们来到 容器服务控制台,在集群更多中选择 自动伸缩

自动伸缩页面.png

进入后我们需要配置如下参数:

  • 缩容阈值:节点上 Request 的资源与总资源量的比值,低于阈值触发集群缩容
  • 缩容触发时延:节点缩容时需要连续满足触发时延所设定的时间才可进行缩容
  • 静默时间: 扩容出的节点,在静默时间过后,方可进入缩容判断
  • 弹性灵敏度: 判断伸缩的间隔时间
  • 节点池扩容顺序策略: 这里我们选择 least-waste


提示:

更详细的参数解释,请参考 配置自动伸缩

参数配置页面.png

节点池配置

创建完成后,可以看到伸缩状态为 待激活,接下来我们创建节点池

节点池配置.png


点击 创建节点池,如下几个配置需要我们着重注意

  1. 填写基本信息,这里容器运行时我们选择 containerd建议容器运行时保持与当前集群一致,可以通过如下命令查看
kubectl get no -owide --no-headers

image

  1. 配置自动伸缩实例的规格,会从第一个规格开始按顺序尝试购买

节点池详细配置-规格.png

  1. 配置节点池的数量上下限以及节点标签,这里因为我们服务是发在 Erda 平台上的,并且是期望生产环境、无状态服务的弹性伸缩,所以需要如下标签。

提示:

需要根据当前集群应用交付的实际场景去配置合适的标签

iShot_2022-08-12_10.39.12.png

  1. 实例自定义数据,弹出的节点在一些场景下我们需要进行数据的初始化,需要用到该选项,采用标准的 cloud-init 方式执行shell。

这里我们执行如下脚本,修改 containerd 的镜像仓库配置以及将宿主机 DNS 指向 CoreDNS

export REGISTRY_ADDR="erda-registry.erda-system.svc.cluster.local:5000"
curl https://erda-project.oss-cn-hangzhou.aliyuncs.com/scripts/ack_ca_init.sh | bash

image


节点池配置完成后,等待初始化完成。从集群中我们可以看到 cluster-autoscaler 组件已经创建出来,并且集群弹性伸缩状态变为 已激活

[root@node-010000000190 ~]# kubectl get po -n kube-system | grep autoscaler
cluster-autoscaler-674d5f5479-8v5pl                        1/1     Running     0          14s

ACK节点池创建成功.png


结果验证

首先我们在 Erda 平台上发布一个服务

image


接下来我们配置弹性伸缩策略,当 CPU 平均使用率在 80% 以上,触发扩容

image


我们可以直接查看该 Deployment Erda 创建的 Keda ScaledObject,大家可以按照 keda 官方的配置去作用在自己的 Deployment 上,详细参考 ScaledObject spec

kubectl get so -A | grep web


配置完成后,我们进入服务的 控制台, 输入如下命令,提高服务 CPU 的平均使用率

for i in `seq 1 $(cat /proc/cpuinfo |grep "physical id" |wc -l)`; do dd if=/dev/zero of=/dev/null & done

控制台提高CPU.png


等待片刻后,可以看到触发了 Keda 的事件,实例扩容为 2 个

弹性开始事件.png


从 ACK 节点池中,我们可以看到出现了伸缩活动,弹出了一台 ECS

ACK伸缩事件-扩容.png

从 Erda 中我们可以看到,新的实例已经运行在了集群弹出的新节点上

ErdaRuntime新实例调度新节点截图.png


验证完成集群节点扩容,接下来我们降低 CPU 的平均使用率,触发 HPA 缩容,我们进入服务 控制台 执行如下命令,停止 CPU 占用,降低平均使用率

pkill -9 dd


稍等片刻后,从集群事件中可以看到,所有指标已经低于目标值,触发实例恢复,恢复到扩容之前的 1 个实例

弹性恢复事件.png

此时我们登陆 ACK 控制台,在节点池伸缩活动中可以看到,触发了节点的缩容,ECS 被删除回收

ACK伸缩事件-缩容.png

到这里我们的验证就完成了,以上就是经典的 HPA 结合 ClusterAutoscaler 的应用场景。


相关链接:

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
在 Kubernetes 集群上部署 VSCode
在 Kubernetes 集群上部署 Visual Studio Code 是一个轻量级但功能强大的源代码编辑器,可在您的桌面上运行,适用于 Windows、macOS 和 Linux。它内置了对 JavaScript、TypeScript 和 Node.js 的支持,并为其他语言(如 C++、C#、Java、Python、PHP、Go)和运行时(如 .NET 和 Unity)提供了丰富的扩展生态系统.
76 0
在kubernetes集群中部署open-falcon
公司最近监控系统从zabbix切换到open-falcon,需要将open-falcon部署到私有的kubernetes集群上。open-falcon团队最近没有更新维护,提交的PR没有反应,所以将部署方法记录到这里。
57 0
Kubernetes 集群包管理器 Helm3 部署
Kuberbetes 能够很好地组织和编排容器,但它缺少一个更高层次的应用打包工具,而 Helm 就是解决这个问题的。
239 0
Kubernetes 集群部署 Ingress Traefik v2.4
Traefik 是一个开源的可以使服务发布变得轻松有趣的边缘路由器。它负责接收你系统的请求,然后使用合适的组件来对这些请求进行处理。
329 0
Kubernetes集群的详细部署
一、集群机器 linux-node1:192.168.56.11 ---master 部署的服务: etcd kube-apiserver kube-controller-manager kube-scheduler docker linux-node2:192.
1205 0
在Kubernetes集群中部署Heapster
背景 公司的容器云平台需要新增应用的自动扩缩容的功能,以便能够更加智能化的对应用进行管理。 Kubernetes官方提供了HPA(Horizontal Pod Autoscaling)资源对象。要让我们部署的应用做到自动的水平的(水平指的是增减Pod副本数量)进行扩缩容,我们只需要在Kubernetes集群中创建HPA资源对象,然后让该资源对象关联某一需要进行自动扩缩容的应用即可。
1852 0
使用 C# 开发 Kubernetes 组件,获取集群资源信息
使用 C# 开发 Kubernetes 组件,获取集群资源信息
65 0
Kubernetes集群升级指南:从理论到实践
摘要:集群升级是Kubernetes集群生命周期中最为重要的一环,也是也是众多使用者最为谨慎对待的操作之一。为了更好地理解集群升级这件事情的内涵外延,我们首先会对集群升级的必要性和难点进行阐述。随后我们会对集群升级前必须要做的前置检查进行逐一讲解。接下来我们会对两种常见的升级方式进行展开介绍。最后我们对集群升级的三个步骤进行讲解,帮助读者从理论走入实践。   升级的必要性&a
324 0
+关注
以尘
github.com/iutx
19
文章
5
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载