作者：韩韬｜比心技能

前言

运用容器化改造后，不可避免地会面临这样一个问题：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 运用率为例，其扩缩容流程如下图所示：

比心云平台基于阿里云容器服务 ACK 的弹性架构实践

默许 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 上，然后降低整个运用的负载状况。

比心云平台基于阿里云容器服务 ACK 的弹性架构实践

  • 怎样判别 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 的架构如下图：

比心云平台基于阿里云容器服务 ACK 的弹性架构实践

阿里云ECI 弹性调度

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

阿里云 ECI 和 Virtual Node 简介

弹性容器实例（ Elastic Container Instance ，简称 ECI ） 是阿里云结合容器和 Serverless 技能供给的容器运转服务。经过容器服务 ACK 来运用 ECI ，能够充分发挥ECI的优势，使得在阿里云上布置容器时，无需购买和办理云服务器 ECS，能够直接在阿里云上运转 Pod 和容器。从购买装备 ECS 再布置容器（ ECS 形式 ）到直接布置容器（ ECI 形式 ），ECI 省去了底层服务器的运维和办理作业，而且仅需求为容器装备的资源付费（ 按量按秒计费 ），能够节省本钱。

比心云平台基于阿里云容器服务 ACK 的弹性架构实践

阿里云 Kubernetes Virtual Node 是经过 ack-virtual-node 组件完成，ack-virtual-node 组件是根据社区开源项目 Virtual Kubelet，扩展了对 Aliyun Provider 的支撑，并做了大量优化，完成 Kubernetes 与弹性容器实例 ECI 的无缝衔接。

有了虚拟节点后，当 Kubernetes 集群 Node 资源缺乏时，无需规划 Node 的核算容量，能够直接在虚拟节点下按需创立 Pod ，每个 Pod 对应一个 ECI 实例 ，ECI 与集群中真实 Node 上的 Pod 之间网络互通。

比心云平台基于阿里云容器服务 ACK 的弹性架构实践

虚拟节点十分合适运转在如下多个场景，极大降低核算本钱，进步核算弹性功率：

  • 运用 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 都供给了很好的处理办法。

ElasticWorkload 和 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 上，如下图：

比心云平台基于阿里云容器服务 ACK 的弹性架构实践

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。

比心云平台基于阿里云容器服务 ACK 的弹性架构实践

关于装备了 HPA 的运用，能够对这些运用增加 Elastic Workload 资源。一个运用对应一个 Elastic Workload。HPA 作用在 Elastic Workload上。终究作用：

  • 正常的 Pod 优先调度到 ECS。
  • 在 ECS 资源缺乏时，正常的 Pod 也会被调度到 ECI。但在下一次发布之前，ECI 实例并不会被主动开释，即便对一般 Node 扩容使一般 Node 资源足够。
  • HPA 弹出的 Pod 悉数调度到 ECI。
  • HPA 缩容时只缩容 ECI 实例。
  • 运用发布时只需求更新源 Deployment 中的镜像，弹性单元中的镜像会主动修正。

比心云平台基于阿里云容器服务 ACK 的弹性架构实践

CloneSet

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

关于没有 HPA 的运用，WorkloadSpread 的 Subset ECS 和 Subset ECI 都不设置最大副本数。

终究作用：

  • ECS 资源足够时，优先运用 ECS。
  • ECS 资源缺乏时，将 Pod 调度到 ECI。但在下一次发布之前，ECI 实例并不会被主动开释，即便对一般 Node 扩容使一般 Node 资源足够。
  • 对运用手动缩容时，会优先删去 ECI 实例。

比心云平台基于阿里云容器服务 ACK 的弹性架构实践

关于有 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 实例。

比心云平台基于阿里云容器服务 ACK 的弹性架构实践

监控核算资源

从上文 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 的低本钱高弹性。目前比心正在积极地落地部分组件，使用其弹性弹性才能切实地降低本钱，也会持续关注行业动态，不断完善弹性计划。

更多阅读：

1）阿里云 ACK+ECI 帮助文档：

www.alibabacloud.com/help/zh/ela…

2）CNCF OpenKruise 官网：

openkruise.io/

点击此处，前往容器服务 ACK 官网查看更多相关资讯！

——本篇转载自「比心技能」，更多相关技能创新、实践可前往该大众号进行查阅