自动伸缩：解密HPA、VPA、CA和CPA智能调整应用大小和数量

本文主要是介绍自动伸缩：解密HPA、VPA、CA和CPA智能调整应用大小和数量，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

关注【云原生百宝箱】公众号，快速掌握云原生

Kubernetes提供了多种自动伸缩机制，例如HPA（Horizontal Pod Autoscaling），可以根据不同情况动态调整Pod副本数量。此功能使 Pod 能够有效地处理当前流量，而无需管理员不断干预来调整副本数量。

除了HPA之外，Kubernetes还提供了其他相关机制，例如VPA（Vertical Pod Autoscaler）、CA（Cluster Autoscaler）和CPA（Custom Pod Autoscaler）。在本文中，我们将探讨这些类别，重点关注三个方面：

1. 适用场景
2. 触发条件
3. 调整目标

我们将深入研究每个机制的这三个维度。

HPA（水平 Pod 自动缩放器）

适用场景

Deployment/ReplicaSet 可以部署 Pod 的多个副本，但固定数量缺乏灵活性，尤其是当应用程序流量根据特定时段波动时。在这种场景下，你可以使用HPA（Horizontal Pod Autoscaler）[1]来动态调整Pod的数量。

触发条件

HPA 是 Kubernetes 中的内置控制器。它与API Server通信以确定是否调整Pod的数量（增加或减少）。当 Metrics Server 安装在环境中时，它可以利用 CPU/内存等资源使用指标来做出决策。这些指标与 Pod 中配置的 CPU/内存请求进行比较，以确定是否超出阈值。此外，可以根据总体 Pod 使用情况或特定容器使用情况来计算使用情况。

调整目标

HPA 调整 Pod 的数量。 有多个参数（包括Behaviour）可以调整，允许你指定每次调整时 Pod 数量应变化的百分比或绝对值。

除了默认的资源使用情况外，HPA 还可以结合 KEDA（https://keda.sh/）等指标或项目来提供不同角度的决策。

VPA（垂直 Pod 自动缩放器）

适用场景

与水平扩展副本数量以处理流量的 HPA 不同，VPA[2]会调整各个实例的资源使用情况，例如 CPU 和内存。将新应用程序部署到 Kubernetes 时，通常会遇到配置资源请求/限制设置的困难。VPA持续观察实例的资源使用情况并执行相关操作。这些操作可能涉及调整设置和重新启动 Pod，或者只是提供建议而不重新启动 Pod。后者依赖Operator根据观察到的资源使用情况收集和修改Deployment文件。

触发条件

在环境中部署 VPA 控制器后，你可以创建 VPA 来指定需要观察哪些Deployment。VPA 主要侧重于观察和计算 CPU/内存请求/限制设置的适当数字。观察这一点需要时间，并且基于太短的收集时间获得的结果可能会导致不适当的使用估计。

调整目标

VPA 以每个 Pod 为基础运行。它不会修改 Pod 副本的数量，但会估计 CPU/内存请求/限制使用情况。 Auto/Recreate模式下，设置相应的值，并重启Pod。在Off模式下，仅执行计算而不重新启动 Pod。

CPA（集群比例自动缩放器）

适用场景

HPA和VPA是管理资源使用、基于水平和垂直方面调整应用程序以满足当前需求的常用方法。CPA[3]旨在根据集群规模水平扩展 Pod 副本数量。一个常见的例子是 DNS 服务。CPA可以根据当前集群规模动态调整DNS实例数量，集群规模可以是节点数，也可以是整体CPU容量。

触发条件

与HPA/VPA关注应用本身的资源使用情况不同，CPA的触发调整是根据节点自身的能力进行的。设置从应用程序的角度开始，探索每个副本可以处理多少个节点实例或总 CPU 实例。相关设置包括coresPerReplica和nodesPerReplica。当前合适的 Pod 数量使用以下公式计算：

副本 = max(ceil(核心 * 1/coresPerReplica), ceil(节点 * 1/nodesPerReplica))

调整目标

CPA根据配置的coresPerReplica和nodesPerReplica以及当前节点规模计算出合适的数量。它动态调整目标 Pod 副本。

CA（集群自动缩放器）

适用场景

之前的HPA、VPA、CPA等方法都是根据各种情况动态调整Pod的数量。CA[4]则根据具体情况动态调整节点数量。例如，当 Pod 充分利用所有节点上的资源，没有为新部署留下 CPU/内存资源时，CA 会动态添加新节点以提供额外的计算资源。反之，当节点资源使用率较低时，可以动态移除节点，尤其是在云环境中，以节省成本。

在节点移除过程中，常见的做法是使用类似于Drain的方法。必须注意PodDisruptionBudget和TerminationGracePeriodSeconds等参数，以确保应用程序过渡期间对现有服务的影响最小。

Drain 命令能否成功完成取决于该节点上的所有 Pod 是否都被成功移除。如果有 Pod 需要较长的时间（terminationGracePeriodSeconds）来处理 Grafecul 关闭过程，则节点驱逐的时间取决于这些 Pod 是否顺利终止。

触发条件

一个常见的触发场景是当任何 Pod 由于 k8s 集群资源不足而进入 Pending 状态时。此操作会提示 CA 控制器添加新节点。一旦新节点成功添加到 Kubernetes 集群并变为 Ready，应用程序就可以顺利部署和运行。相反，当节点使用率在一定时间内低于阈值时，可以移动目标节点上的 Pod 并删除该节点。

不同的 Kubernetes 平台有不同的实现，因此需要确认具体的实现和相关设置，例如将新节点均匀分布在不同的可用区或使用注释来防止特定应用程序被驱逐。所有设置均取决于平台。

调整目标

CA 根据每个节点进行调整。 当一个节点被删除时，所有正在运行的 Pod 都会被重新调度到其他节点。

总结

Kubernetes提供了多种自动伸缩机制，如HPA（水平Pod自动缩放器），可根据不同情况动态调整Pod副本数量。此功能使Pod能够有效处理当前流量，无需管理员不断干预。除了HPA外，还有VPA（垂直Pod自动缩放器）、CA（集群比例自动缩放器）和CPA（自定义Pod自动缩放器）。它们分别从水平和垂直方面，以及整个集群规模角度，调整Pod和节点数量。这些机制相互补充，可根据需求灵活运用。

1. 上述所有机制并不相互排斥。例如，某个应用类别可以使用HPA来调整Pod数量，并与CA相辅相成，动态调整节点数量以满足需求。
2. 由于这些操作导致 Pod 和节点数量的增加或减少，可能会出现意外的 Pod 分发场景。在这种情况下，可能需要像descheduler[5]或Affinity、SpreadConstraint 这样的机制来平衡部署情况。

引用链接

[1] HPA（Horizontal Pod Autoscaler）: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
[2] VPA: https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler
[3] CPA: https://github.com/kubernetes-sigs/cluster-proportional-autoscaler
[4] CA: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
[5] descheduler: https://github.com/kubernetes-sigs/descheduler

- END -