关于架构:阿里云容器服务-ACK-的弹性架构实践

简介：本文次要探讨比心云平台如何利用阿里云容器服务 ACK，来构建利用弹性架构，进一步优化计算成本。

作者：韩韬|比心技术

前言

利用容器化革新后，不可避免地会面临这样一个问题：Kubernetes 集群的 Node 资源配置有余会导致 Pod 无奈及时运行，购买过多的 Node 又会导致资源的闲置节约。

那么如何利用 Kubernetes 的容器编排能力和云上资源的灵活性及规模化劣势，来保障业务的高弹性、低成本？

本文次要探讨比心云平台如何利用阿里云容器服务 ACK，来构建利用弹性架构，进一步优化计算成本。

留神：文中的「Node」等同于节点。集群中的 Node 和集群中的节点，是一个意思。

弹性伸缩概述

弹性伸缩是依据业务需要和策略，经济地主动调整弹性计算资源的治理服务。

弹性伸缩能够分为两个维度：

• 调度层弹性，次要负责批改 Workload（例如 Deployment）的调度容量变动。例如，HPA 是典型的调度层弹性组件，通过 HPA 能够调整利用的正本数，调整的正本数会扭转以后 Workload 占用的调度容量，从而实现调度层的伸缩。
• 资源层弹性，次要是集群的容量布局不能满足集群调度容量时，会通过程度弹出 Node 的形式进行调度容量的补充。

两层的弹性组件与能力能够离开应用，也能够联合在一起应用，并且两者之间是通过调度层面的容量状态进行解耦。

Kubernetes 中共有三种不同的弹性伸缩策略：HPA（HorizontalPodAutoscaling）、VPA（VerticalPodAutoscaling）与 CA（ClusterAutoscaler）。其中，HPA 和 VPA 的扩缩容对象是 Pod，而 CA 的扩缩容对象是 Node。

• HPA：调度层弹性组件，Kubernetes 内置，Pod 程度伸缩组件，次要面向在线业务。
• VPA：调度层弹性组件，Kubernetes 社区开源，Pod 垂直伸缩组件，次要面向大型单体利用。实用于无奈程度扩大的利用，通常是在 Pod 出现异常复原时失效。
• CA：资源层弹性组件，Kubernetes 社区开源，Node 程度伸缩组件。全场景实用。

另外各大云厂商（例如阿里云等）还提供了 Virtual Node 组件，提供无服务器运行时环境。用户无需关怀 Node 资源，只需针对 Pod 按量付费即可。实用于在线流量突增、CI/CD、大数据作业等场景。本文在介绍 Virtual Node 时会以阿里云为例。

Pod 程度伸缩 HPA

HPA（Horizontal Pod Autoscaler）是 Kubernetes 的内置组件，也是最罕用的 Pod 弹性计划。通过 HPA 能够主动调整 Workload 的正本数。HPA 主动伸缩个性使 Kubernetes 具备非常灵活的自适应能力，可能在用户设定内疾速扩容多个 Pod 副原本应答业务负载的急剧飙升，也能够在业务负载变小的状况下依据理论状况适当缩容来节俭计算资源给其余的服务，整个过程自动化无需人为干涉，适宜服务稳定较大、服务数量多且须要频繁扩缩容的业务场景。

HPA 实用于 Deployment、StatefulSet 等实现 scale 接口的对象，不适用于无奈扩缩的对象，例如 DaemonSet 资源。Kubernetes 内置有 HorizontalPodAutoscaler 资源，通常是对须要配置程度主动伸缩的 Workload 创立一个 HorizontalPodAutoscaler 资源，Workload 与 HorizontalPodAutoscaler 绝对应。

HPA 扩缩容流程

Pod 程度主动扩缩个性由 Kubernetes API 资源和控制器实现。资源利用指标决定控制器的行为，控制器会周期性的依据 Pod 资源利用状况调整服务 Pod 的正本数量，以使得工作负载的度量程度与用户所设定的目标值匹配。以 Deployment 和 CPU 使用率为例，其扩缩容流程如下图所示：

默认 HPA 只反对基于 CPU 和内存的主动伸缩，例如当 CPU 使用率超过阈值时就主动减少利用实例数，当 CPU 使用率又低于阈值时就主动缩小实例数。

然而默认 HPA 驱动弹性的维度比拟繁多，并不能满足日常的运维需要。能够将 HPA 和开源的 Keda 联合应用，Keda 能够从事件、定时、自定义指标等维度来驱动弹性。

HPA 注意事项

• 如果设置了多个弹性伸缩指标，HPA 会根据各个指标，别离计算出指标正本数，取最大值进行扩缩容操作。
• 当指标类型抉择为 CPU 利用率（占 Request）时，必须为容器设置 CPU Request。
• HPA 在计算指标正本数时会有一个 10% 的稳定因子。如果在稳定范畴内，HPA 并不会调整正本数目。
• 如果服务对应的 Deployment.spec.replicas 值为 0，HPA 将不起作用。
• 如果对单个 Deployment 同时绑定多个 HPA，则创立的 HPA 会同时失效，会造成工作负载的正本反复扩缩。

Pod 垂直伸缩 VPA

VPA（VerticalPodAutoscaling）是社区开源组件，须要在 Kubernetes 集群上手动部署装置，VPA 提供垂直的 Pod 伸缩的性能。

VPA 会基于 Pod 的资源应用状况主动为 Pod 设置资源占用的限度，从而让集群将 Pod 调度到有足够资源的最佳节点上。VPA 也会放弃最后容器定义中资源 request 和 limit 的占比。此外，VPA 可用于向用户举荐更正当的 Request，在保障容器有足够应用的资源的状况下，晋升容器的资源利用率。

VPA 劣势

相较于 HPA，VPA 具备以下劣势：

VPA 可为有状态利用实现扩容，HPA 则不适宜有状态利用的程度扩容。
有些利用 Request 设置过大，缩容至一个 Pod 时资源利用率依然很低，此时能够通过 VPA 进行垂直缩容以进步资源利用率。

VPA 限度

应用 VPA 有以下限度和注意事项：

• 更新正在运行的 Pod 资源配置是 VPA 的一项试验性功能，会导致 Pod 的重建和重启，而且有可能被调度到其余的 Node 上。
• VPA 不会驱赶没有在正本控制器治理下的 Pod。目前对于这类 Pod，Auto 模式等同于 Initial 模式。
• 目前 VPA 不能和监控 CPU 和内存度量的 HPA 同时运行，除非 HPA 只监控除 CPU 和内存以外的指标。
• VPA 应用 admission webhook 作为其准入控制器。如果集群中有其余的 admission webhook，须要确保它们不会与 VPA 发生冲突。准入控制器的执行程序定义在 API Server 的配置参数中。
• VPA 会解决呈现的绝大多数 OOM 的事件，但不保障所有的场景下都无效。
• VPA 的性能还没有在大型集群中测试过。
• VPA 对 Pod 资源 requests 的批改值可能超过理论的资源下限，例如 Node 资源下限、闲暇资源或资源配额，从而造成 Pod 处于 Pending 状态无奈被调度。同时应用集群主动伸缩（ClusterAutoscaler）能够肯定水平上解决这个问题。
• 多个 VPA 同时匹配同一个 Pod 会造成未定义的行为。

Node 程度伸缩 CA

HPA 和 VPA 都是调度层的弹性，解决了 Pod 的弹性伸缩。如果集群整体的资源容量不能满足集群调度容量时，HPA 和 VPA 弹出的 Pod 还是会处于 Pending 状态。这时就须要资源层的弹性伸缩。

在 Kubernetes 中，Node 主动程度伸缩是通过社区开源的 CA（ClusterAutoscaler）组件实现的。社区 CA 反对设置多个伸缩组，反对设置扩容和缩容策略。各大云厂商在社区 CA 的根底上会退出一些特有的性能，例如反对多可用区、多实例规格、多种伸缩模式等，满足不同的 Node 伸缩场景。

在 Kubernetes 中，Node 主动伸缩的工作原理与传统意义上基于使用率阈值的模型有所差异。

传统弹性伸缩模型

传统的弹性伸缩模型是基于使用率的，例如：一个集群中有 3 个 Node，当集群中 Node 的 CPU、内存使用率超过特定的阈值时，就弹出新 Node。但当深刻思考时会发现以下几个问题：

• Node 资源使用率阈值是怎么抉择与判断的？

在一个集群中，局部热点节点的利用率会较高，而另外一个节点的利用率会很低。如果抉择均匀利用率，可能会造成弹性伸缩不及时。如果应用最低的节点的利用率，也会造成弹出资源的节约。

• 弹出 Node 后是怎么缓解压力的？

在 Kubernetes 中，利用是以 Pod 为最小单元。当一个 Pod 资源利用率较高的时候，即使此时所在的 Node 或者集群的总量触发了弹性扩容，然而该利用的 Pod 数目，以及 Pod 对应的资源 Limit 没有任何变动，那么负载的压力是无奈转移到新扩容出的 Node 上的。

• 怎么判断以及执行 Node 的缩容？

如果基于资源应用用率的形式判断 Node 是否缩容，那么很有可能呈现，Request 很大，然而 Usage 很小的 Pod 被驱赶，当集群中这种类型的 Pod 较多时，会导致集群的调度资源被占满，局部 Pod 无奈调度。

Kubernetes 节点伸缩模型

Kubernetes 节点伸缩是怎么解决以上问题的呢？Kubernetes 是通过调度与资源解耦的两层弹性模型来解决的。

基于资源的使用率来触发利用正本的变动，也就是调度单元（Pod）的变动。而当集群的调度水位达到 100% 的时候会触发资源层的弹性扩容，当 Node 资源弹出后，无奈调度的 Pod 会主动调度到新弹出的 Node 上，从而升高整个利用的负载情况。

• 如何判断 Node 的弹出？

CA 是通过对处在 Pending 状态的 Pod 进行监听而触发的。当 Pod 处在 Pending 的起因是调度资源有余的时候，会触发 CA 的模仿调度，模仿调度器会计算在配置的伸缩组中哪个伸缩组弹出 Node 后能够调度这些 Pending 的 Pod。如果有伸缩组能够满足，那么就弹出相应的 Node。

模仿调度就是将一个伸缩组当成一个形象的 Node，伸缩组中配置的机型规格对应会成为 Node 的 CPU/ 内存 的容量，而后设置伸缩组下面的 Label、Taint，也就是 Node 的 Label 与 Taint。模仿调度器会在调度模仿的时候，将该形象的 Node 纳入调度参考。如果 Pending 的 Pod 能够调度到形象的 Node，那么就会计算所需的 Node 的数目，驱动伸缩组弹出 Node。

• 如何判断 Node 的缩容？

首先只有弹性伸缩弹出的 Node 会被缩容，动态的 Node 是无奈被 CA 接管的。缩容的判断是对每个 Node 独自判断的。当任意一个 Node 的调度利用率低于所设置的调度阈值时，会触发 Node 的缩容判断。此时 CA 会尝试模仿驱赶 Node 下面的 Pod，判断以后 Node 是否能够排水彻底。如果有非凡的 Pod（kube-system 命名空间的非 DaemonSet Pod、PDB 管制的 Pod、非 Controller 创立的 Pod 等），则会跳过该 Node 而抉择其余的候选 Node。当 Node 产生驱赶时，会先进行排水，将 Node 上的 Pod 驱赶到其余的 Node，而后再下线该 Node。

• Node 扩容时在多个伸缩组之间如何抉择？

不同伸缩组之间，实际上相当于不同的虚构的 Node 之间的抉择，和调度策略一样，这里也存在一个打分的机制。首先合乎调度策略的 Node 会先过滤出来，在合乎调度策略的 Node 中，会依据 affinity 等亲和性的策略进行抉择。如果上述的策略都不存在，默认状况下 CA 会通过 least-waste 的策略来进行抉择。least-waste 策略的外围就是模仿弹出 Node 后，残余的资源起码，尽可能地缩小节约。此外，有一个特地的场景，当有一个 GPU 的伸缩组和 CPU 的伸缩组同时能够弹出失效时，默认 CPU 会优先于 GPU 弹出。

CA 限度

应用 CA 有以下限度和注意事项：

• 可扩容 Node 数量受公有网络、容器网络、云商 Kubernetes 集群节点配额及可购买云服务器配额限度。
• 扩容 Node 受机型以后售卖状况限度。若机型呈现售罄，将无奈扩容节点。
• Node 从触发扩容到交付使用，等待时间比拟长，对于须要疾速启动 Pod 的场景不实用。
• Node 缩容时，如果 Node 上有 Pod 无奈驱赶，该 Node 将无奈下线，造成资源节约。

Virtual Node

Virtual Node（虚构节点）是各大云厂商基于社区开源我的项目 Virtual Kubelet 而开发的插件，作为一种虚构的 Kubelet 用来连贯 Kubernetes 集群和其余平台的 API。Virtual Kubelet 的次要场景是将 Kubernetes API 扩大到无服务器的容器平台。

通过虚构节点，Kubernetes 集群能够轻松取得极大的弹性能力，而不用受限于集群的节点计算容量。用户也能够灵便动静地按需创立 Pod，免去集群容量布局的麻烦。

Virtual Kubelet 简介

在 Kubernetes 集群中每个节点都会启动一个 Kubelet 过程，能够把 Kubelet 了解成 Server-Agent 架构中的 Agent。

Virtual Kubelet 是基于 Kubelet 的典型个性实现，向上伪装成 Kubelet，从而模拟出 Node 对象，对接 Kubernetes 的原生资源对象；向下提供 API，可对接其余资源管理平台提供的 Provider。不同的平台通过实现 Virtual Kubelet 定义的办法，容许 Node 由其对应的 Provider 提供反对，实现 Serverless，也能够通过 Provider 纳管其余 Kubernetes 集群。

Virtual Kubelet 模仿了 Node 资源对象，并负责对 Pod 调度到 Virtual Kubelet 假装的虚构节点之后，对 Pod 进行生命周期治理。

从 Kubernetes API Server 的角度来看，Virtual Kubelet 看起来像一般的 Kubelet，但其要害区别在于 Virtual Kubelet 在其余中央调度 Pod，例如在云无服务器 API 中，而不是在实在 Node 上。

Virutal Kubelet 的架构如下图：

阿里云 ECI 弹性调度

各大云厂商基本上都提供了无服务器容器服务和 Kubernetes Virtual Node 的能力，本文以阿里云为例，介绍下阿里云基于 Virtual Node 和 ECI 的弹性调度。

阿里云 ECI 和 Virtual Node 简介

弹性容器实例（Elastic Container Instance，简称 ECI）是阿里云联合容器和 Serverless 技术提供的容器运行服务。通过容器服务 ACK 来应用 ECI，可能充分发挥 ECI 的劣势，使得在阿里云上部署容器时，无需购买和治理云服务器 ECS，能够间接在阿里云上运行 Pod 和容器。从购买配置 ECS 再部署容器（ECS 模式）到间接部署容器（ECI 模式），ECI 省去了底层服务器的运维和管理工作，并且仅须要为容器配置的资源付费（按量按秒计费），能够节约老本。

阿里云 Kubernetes Virtual Node 是通过 ack-virtual-node 组件实现，ack-virtual-node 组件是基于社区开源我的项目 Virtual Kubelet，扩大了对 Aliyun Provider 的反对，并做了大量优化，实现 Kubernetes 与弹性容器实例 ECI 的无缝连贯。

有了虚构节点后，当 Kubernetes 集群 Node 资源有余时，无需布局 Node 的计算容量，能够间接在虚构节点下按需创立 Pod，每个 Pod 对应一个 ECI 实例，ECI 与集群中实在 Node 上的 Pod 之间网络互通。

虚构节点非常适合运行在如下多个场景，极大升高计算成本，晋升计算弹性效率：

• 应用 ECI 作为弹性资源池，应答突发流量。
• 在线业务有比拟显著的波峰波谷特色，应用虚构节点能够显著缩小固定资源池的保护，升高计算成本。
• 计算类的离线工作，例如机器学习等对实时性要求不高，然而对老本敏感的业务利用。
• CI/CD Pipeline，例如 Jenkins、Gitlab-Runner。
• Job 工作，定时工作。

虚构节点和 ECI 就像是 Kubernetes 集群的“魔法口袋”，让咱们解脱 Node 计算力有余的搅扰，也防止了 Node 的闲置节约，满足有限计算力的设想，Pod 按需创立，轻松应答计算的波峰波谷。

调度 Pod 到 ECI

在混合应用 ECI 和一般 Node 的模式下，个别能够通过以下三种形式将 Pod 调度到 ECI：

（1）配置 Pod Label

如果有个别 Pod 须要调度到 ECI 上运行，能够间接为 Pod 增加特定的 Label（alibabacloud.com/eci=true），则该 Pod 将运行在虚构节点的 ECI 实例上。

（2）配置 Namespace Label

如果有一类 Pod 要调度到 ECI 上运行，可创立一个 Namespace，并对该 Namespace 增加特定 Label（alibabacloud.com/eci=true），则该 Namespace 下的所有 Pod 将运行在虚构节点的 ECI 实例上。

（3）配置 ECI 弹性调度

ECI 弹性调度是阿里云提供的一种弹性调度策略，在部署服务时，能够在 Pod Template 中增加 Annotations 来申明只应用一般 Node 的资源或者虚构节点的 ECI 资源，或者在一般 Node 的资源有余时主动应用 ECI 资源，以满足不同场景下对弹性资源的不同需要。

对应的 Annotations 配置项为 alibabacloud.com/burst-resource，取值如下：

• 默认不填 Annotations 时，只应用集群现有的 ECS 资源。
• eci：以后集群 ECS 资源有余时，应用 ECI 弹性资源。
• eci_only：只应用 ECI 弹性资源，不应用集群的 ECS 资源。

上述三种形式均须要对存量资源做肯定的批改，无奈做到零侵入。对于这种状况，ECI 反对通过配置 ECI Profile 来解决。

在 ECI Profile 中，能够申明须要匹配的 Namespace 或者 Pod 的 Label，对于 Label 可能匹配上的 Pod，将被主动调度到 ECI。

也能够在 ECI Profile 中申明须要对 Pod 追加的 Annotation 和 Label，对于 Label 可能匹配上的 Pod，也将主动追加配置的 Annotation 和 Label。

混用 Virtual Node 和一般 Node 的问题

依然以阿里云为例，阿里云上的 Kubernetes 集群部署了 Virtual Node，混合应用 ECI 和一般 Node。

设想一下这样的场景：某个利用（Deployment）配置了 HPA 和 ECI 弹性调度, 在一般 Node 资源有余的状况下，当触发 HPA 扩容时，局部 Pod 会被调度到 ECI，然而当 HPA 缩容时，并不会固定删除 ECI 实例，也有可能把一般 Node 上的 Pod 删除而保留 ECI 实例。因为 ECI 是按量付费，如果应用工夫过长，费用会比包年包月的 ECS（阿里云服务器）要贵。

这就引申出了须要解决的两个问题：

• 调度问题：当正本数目达到某个数值后，如何管制调度策略的变动。
• 生命周期治理问题：在生命周期治理时，如何优先解决某些 Pod。

Kubernetes 原生的控制器和 Workload 都不能很好地解决上述场景。而阿里云 Kubernetes 的 Elastic Workload 组件（未开源）和阿里云开源的 OpenKruise 都提供了很好的解决办法。

Elastic Workload 和 OpenKruise

Elastic Workload 简介

Elastic Workload 是阿里云 Kubernetes 特有的一个组件，装置该组件后，会多一种新的资源类型 Elastic Workload，Elastic Workload 的应用形式与 HPA 相似，通过内部挂载的形式应用，对原有的业务无侵入。

一个典型的 Elastic Workload 次要分为两个局部：

sourceTarget 局部次要定义原始 Workload 的类型、正本数目可变动的范畴。原始 Workload 还不反对 CloneSet，且短期内无反对打算。
elasticUnit 局部是一个数组，定义弹性单元的调度策略，如果有多个弹性单元，则依照模板的程序定义。

Elastic Workload Controller 会监听原始 Workload，并依据弹性单元设定的调度策略，克隆并生成弹性单元的 Workload。依据 Elastic Workload 中总正本的变动，动静的调配原始 Workload 和弹性单元下面的正本数目。

此外，Elastic Workload 也反对与 HPA 配合应用，能够将 HPA 作用在 Elastic Workload 上，如下图：

Elastic Workload 会依据 HPA 的状态动静调整每个单元的正本散布，例如如果以后是从 6 个正本缩容到 4 个正本，那么会优先将弹性单元的正本进行缩容。

Elastic Workload 一方面通过克隆和覆写调度策略的形式生成多个 Workload，实现了调度策略的治理，另一方面通过下层的正本计算，调整原始 Workload 和弹性单元的正本调配，实现了针对一部分 Pod 的优先解决。

Elastic Workload 目前仅反对 Deployment。

OpenKruise 简介

OpenKruise 是由阿里云容器服务团队开源针对 Kubernetes 的加强能力套件，聚焦于云原生利用的部署、降级、运维、稳定性防护等畛域。所有的性能都通过 CRD 等规范形式扩大，能够实用于 1.16 以上版本的任意 Kubernetes 集群。

OpenKruise 能力

• 加强版本的 Workload

OpenKruise 蕴含了一系列加强版本的 Workload，例如 CloneSet、Advanced StatefulSet、Advanced DaemonSet、BroadcastJob 等。它们不仅反对相似于 Kubernetes 原生 Workload 的根底性能，还提供了如原地降级、可配置的扩缩容 / 公布策略、并发操作等能力。

• 利用的旁路治理

OpenKruise 提供了多种通过旁路治理利用 sidecar 容器、多区域部署的形式，“旁路”意味着用户能够不须要批改利用的 Workload 来实现它们。

例如，UnitedDeployment 能够提供一个模板来定义利用，并通过治理多个 Workload 来治理多个区域下的 Pod。而 WorkloadSpread 能够束缚无状态 Workload 扩容进去 Pod 的区域散布，赋予繁多 Workload 多区域和弹性部署的能力。

OpenKruise 就是通过 WorkloadSpread 解决上文中提到的混用 Virtual Node 和一般 Node 的问题。

• 高可用性防护

OpenKruise 在为利用的高可用性防护方面也做出了很多致力。目前它能够爱护 Kubernetes 资源不受级联删除机制的烦扰，包含 CRD、Namespace、以及简直全副的 Workload 类型资源。相比于 Kubernetes 原生的 PDB 只提供针对 Pod Eviction 的防护，PodUnavailableBudget 可能防护 Pod Deletion、Eviction、Update 等许多种 voluntary disruption 场景。

WorkloadSpread

在 Kubernetes 集群中装置 OpenKruise 后，会多出一个 WorkloadSpread 资源。WorkloadSpread 可能将 Workload 的 Pod 按肯定规定散布到不同类型的 Node 上，能够以无侵入的形式赋予繁多 Workload 多区域部署、弹性部署和精细化治理的能力。

常见的一些规定包含：

• 程度打散。例如按 Node、Available Zone 等维度的均匀打散。
• 按指定比例打散。例如按比例部署 Pod 到几个指定的 Available Zone 中。
• 带优先级的分区治理。例如：1）优先部署到 ECS，资源有余时部署到 ECI。2）优先部署固定数量个 Pod 到 ECS，其余到 ECI。
• 定制化分区治理。例如：1）管制 Workload 部署不同数量的 Pod 到不同的 CPU 架构上。2）确保不同的 CPU 架构上的 Pod 配有不同的资源配额。

每一个 WorkloadSpread 定义多个区域（定义为 subset），每个 subset 对应一个 maxReplicas 数量。WorkloadSpread 利用 Webhook 注入 subset 定义的域信息，同时管制 Pod 的扩缩容程序。

和 ElasticWorkload 不同的是，ElasticWorkload 治理多个 Workload，而一个 WorkloadSpread 仅作用在单个 Workload 之上，Workload 和 WorkloadSpread 是一一对应的。

WorkloadSpread 以后反对的 Workload 类型有 CloneSet 和 Deployment。

Elastic Workload 和 WorkloadSpread 如何抉择

Elastic Workload 是阿里云 Kubernetes 独有的，容易造成云商绑定，且应用老本比拟高，只反对 Deployment 这一原生 Workload。

WorkloadSpread 是开源的，在 1.16 以上版本的任意 Kubernetes 集群都能够应用，反对原生 Workload Deployment 和 OpenKruise 扩大 Workload Cloneset。

然而 WorkloadSpread 的优先删除规定依赖 Kubernetes 的 deletion-cost feature。Cloneset 曾经反对 deletion-cost feature。而原生 Workload 需 Kubernetes 版本大于等于 1.21，且 1.21 版本须要显式开启 PodDeletionCost feature-gate，自 1.22 版本起默认开启。

所以如果应用阿里云的 Kubernetes，可参考以下几项进行抉择：

• 如果应用 Deployment 并且 Kubernetes 版本小于 1.21，则只能抉择 ElasticWorkload。
• 如果应用 Deployment 并且 Kubernetes 版本大于等于 1.21，则抉择 WorkloadSpread。
• 如果应用 Cloneset（OpenKruise 提供的加强 Workload），并且 Kubernetes 版本大于 1.16，则抉择 WorkloadSpread。

比心基于 ACK + ECI 的低成本高弹性实际

上文介绍了 Kubernetes 罕用的弹性伸缩组件，并以阿里云为例介绍了 Virtual Node 和 ECI，以及阿里云的 Elastic Workload，开源的 OpenKruise。这一章来探讨下如何正当地应用这些组件，以及比心在阿里云上基于 ECI 的低成本高弹性实际。

比心能够应用弹性伸缩的场景：

• Job 工作，例如 Flink 的计算工作，Jenkins 的 Pipline。
• 外围利用须要应用 HPA 来应答突发流量。
• 有流动时，对流动波及到的利用配置定时 HPA，在流动开始时扩容，在流动完结时缩容。
• 因为 Node 资源不够导致 HPA 弹出的 Pod 处于 Pending 状态。
• 利用上线和公布时，因为 Node 资源不够导致 Pod 处于 Pending 状态。

对于这些场景，能够将 Kubernetes 的各弹性组件联合应用，实现业务的高弹性和低成本。

因为 Node 程度扩容的交付工夫比拟长，暂不思考应用 Node 程度主动伸缩。

Pod 程度伸缩的整体思路是利用 Kubernetes 的 HPA、阿里云的 Virtual Node 和 ECI，在阿里云上混合应用 ECS 和 ECI，平时业务应用包年包月的 ECS 承载，节省成本；弹性业务应用 ECI 承载，无需执行弹性局部容量布局。并且联合阿里云的 Elastic Workload 或开源组件 OpenKruise 实现在利用缩容时优先删除 ECI 实例。

下文会别离对 Job 工作、Deployment、CloneSet 这三种在比心罕用资源的程度伸缩做简略介绍。

至于 Pod 垂直伸缩，因为 VPA 技术还不成熟，且应用限度较多，暂不思考 VPA 的主动伸缩能力。然而能够应用 VPA 举荐正当 Request 的能力，在保障容器有足够应用的资源的状况下，晋升容器的资源利用率，防止容器的资源 Request 设置不合理。

Job 工作只应用 ECI

对于 Job 工作，间接为 Pod 增加特定的 Label alibabacloud.com/eci=true，让 Job 工作全副运行在 ECI 上，工作完结则 ECI 开释。无需为 Job 工作预留计算资源，从而解脱集群计算力有余和扩容的搅扰。

Deployment

在所有 Deployment 的 Pod Template 增加 Annotations alibabacloud.com/burst-resource: eci，以启用 ECI 弹性调度，当集群 ECS 资源（一般 Node）有余时，应用 ECI 弹性资源。因为比心的 Kubernetes 集群版本都在 1.21 以下，所以如果要实现 Deployment 缩容时优先删除 ECI 实例，只能应用阿里云的 Elastic Workload 组件。

对于没有 HPA 的利用，只应用 ECI 弹性调度。最终成果：

• ECS 资源短缺时，优先应用 ECS。
• ECS 资源有余时，将 Pod 调度到 ECI。但在下一次公布之前，ECI 实例并不会被主动开释，即便对一般 Node 扩容使一般 Node 资源短缺。
• 如果对利用手动缩容，不会优先删除 ECI。

对于配置了 HPA 的利用，能够对这些利用增加 Elastic Workload 资源。一个利用对应一个 Elastic Workload。HPA 作用在 Elastic Workload 上。最终成果：

• 失常的 Pod 优先调度到 ECS。
• 在 ECS 资源有余时，失常的 Pod 也会被调度到 ECI。但在下一次公布之前，ECI 实例并不会被主动开释，即便对一般 Node 扩容使一般 Node 资源短缺。
• HPA 弹出的 Pod 全副调度到 ECI。
• HPA 缩容时只缩容 ECI 实例。
• 利用公布时只须要更新源 Deployment 中的镜像，弹性单元中的镜像会主动批改。

CloneSet

创立 CloneSet 之前，先创立 WorkloadSpread 资源。一个 WorkloadSpread 仅作用在一个 CloneSet 上。

对于没有 HPA 的利用，WorkloadSpread 的 Subset ECS 和 Subset ECI 都不设置最大正本数。

最终成果：

• ECS 资源短缺时，优先应用 ECS。
• ECS 资源有余时，将 Pod 调度到 ECI。但在下一次公布之前，ECI 实例并不会被主动开释，即便对一般 Node 扩容使一般 Node 资源短缺。
• 对利用手动缩容时，会优先删除 ECI 实例。

对于有 HPA 的利用，HPA 依然作用于 CloneSet。WorkloadSpread 的 Subset ECS 的最大正本数设置为和 HPA 的最小正本数相等，Subset ECI 不设置最大正本数，批改 HPA 的最小正本数时要同步批改 Subset ECS 的最大正本数。

最终成果：

• 失常的 Pod 优先调度到 ECS。
• 在 ECS 资源有余时，失常的 Pod 也会被调度到 ECI。但在下一次公布之前，ECI 实例并不会被主动开释，即便对一般 Node 扩容使一般 Node 资源短缺。
• HPA 弹出的 Pod 全副调度到 ECI。
• HPA 缩容时也优先删除 ECI 实例。

监控计算资源

从上文 Deployment 和 Cloneset 的程度弹性伸缩办法能够看出，ECI 实例并不能 100% 被及时地主动删除。

ECI 是按量付费，如果应用工夫过长，费用会比包年包月的 ECS 要贵。所以还要联合监控，在一般 Node 资源有余时，及时对一般 Node 资源进行扩容。还要对 ECI 实例做监控告警，如果有长时间（例如三天）运行的 ECI 实例，须要告诉到这些实例的利用负责人，让利用负责人自行重启这些 ECI 实例，新的 Pod 会调度到 ECS。

应用 VPA 获取 Request 推荐值

有些利用的 Request 设置过大，缩容至一个 Pod 时资源利用率依然很低，此时能够通过 VPA 进行垂直缩容以进步资源利用率。然而 VPA 的字段伸缩目前还处于试验阶段，不举荐应用。能够只应用 VPA 获取正当的 Request 推荐值。

VPA 组件在 Kubernetes 上部署实现后，会新增一个 VerticalPodAutoscaler 资源类型。能够对每一个 Deployment 创立一个 updateMode 为 Off 的 VerticalPodAutoscaler 对象。VPA 会周期性地从 Metrics Server 获取 Deployment 下所有容器的资源应用指标，并计算出正当的 Request 推荐值，而后把推荐值记录在该 Deployment 对应的 VerticalPodAutoscaler 对象中。

能够本人写代码将 VerticalPodAutoscaler 对象中的推荐值取出来，而后以利用为维度进行聚合、计算，最终将后果展现到页面中。利用负责人能够在页面上直观地看出利用的 Request 设置是否正当，运维人员也能够根据这些数据去推动利用的降配。

总结

本文简略介绍了 HPA、VPA、CA、Virtual Kubelet、阿里云 ACK、阿里云 ECI、阿里云 ElasticWorkload、Openkruise WorkloadSpread 等弹性伸缩组件，并探讨了比心如何应用这些组件实现 Kubernetes 的低成本高弹性。目前比心正在踊跃地落地局部组件，利用其弹性伸缩能力切实地降低成本，也会继续关注行业动态，不断完善弹性计划。

原文链接
本文为阿里云原创内容，未经容许不得转载。