阿里云代理商：K8s HPA 在云计算中的配置与触发机制

最新推荐文章于 2025-12-04 18:16:54 发布

原创最新推荐文章于 2025-12-04 18:16:54 发布 · 1.5k 阅读

22 ·

CC 4.0 BY-SA版权

文章标签：

#云计算 #阿里云 #kubernetes

阿里云代理商同时被 3 个专栏收录

128 篇文章

订阅专栏

阿里云

128 篇文章

订阅专栏

云计算

84 篇文章

订阅专栏

在云计算时代，弹性伸缩（Scalability）是衡量系统是否具备高效资源利用能力的核心指标。它允许我们根据实时业务负载的变化，动态地增加或减少计算资源，从而在保障服务稳定性的同时，实现成本的最优化。在容器编排领域，Kubernetes（简称K8s）的**水平 Pod 自动伸缩（Horizontal Pod Autoscaler，HPA）**正是实现这一目标的关键利器。

HPA 的出现，使得我们不再需要手动监控和调整副本数量来应对流量高峰或低谷。它能够自动观察 CPU、内存等指标，并根据预设的规则，自动调整 Pod 副本的数量。本文将深入探讨 K8s HPA 的工作原理、配置方法、触发机制以及在云计算环境下的最佳实践，旨在为您提供一篇全面且具有实操性的技术科普文章。

一、理解 HPA：从手动伸缩到智能自动化

在 K8s 中，通过 kubectl scale 命令可以手动调整 Pod 的副本数量，但这显然无法应对瞬息万变的线上流量。HPA 的设计初衷正是为了解决这一痛点，它将“伸缩”这一繁琐且容易出错的任务交给了自动化系统。

HPA 的核心功能

自动监控：HPA 会持续监控 Pod 的资源使用情况，如 CPU 利用率、内存使用率等。
智能决策：基于监控数据，HPA 会与预设的伸缩规则进行对比，判断是否需要增加或减少 Pod 副本。
动态调整：HPA 会自动调整关联的 Deployment、ReplicaSet 或 StatefulSet 中的副本数，以适应当前的负载。

二、HPA 的工作原理与触发机制

HPA 的工作流程可以概括为“观察-决策-执行”三个阶段。它通过 K8s API Server 与 Metrics Server 紧密协作，共同完成自动伸缩。

1. 工作流程详解

收集指标：HPA 控制器周期性（默认30秒）地从 Metrics Server 收集 Pod 的指标数据。Metrics Server 是 K8s 集群的度量数据聚合器，它从每个节点上的 Kubelet 收集资源使用数据。
计算目标：HPA 控制器根据收集到的指标数据和用户在 HPA 对象中定义的伸缩规则，计算出期望的 Pod 副本数量。
更新副本数：如果计算出的期望副本数与当前的实际副本数不符，HPA 控制器会向关联的 Deployment 或 ReplicaSet 发送更新请求，调整其 replicas 字段的值。
调度生效：Deployment 或 ReplicaSet 收到更新后，会立即创建或销毁 Pod 副本，以达到新的期望数量。

2. HPA 的触发指标

HPA 支持多种类型的触发指标，使得其伸缩策略能够更加灵活和精准。

资源指标（Resource Metrics）：这是最常用也是最简单的触发方式。HPA 可以基于 Pod 的 CPU 或内存利用率进行伸缩。
- CPU 利用率：当 Pod 的平均 CPU 利用率超过或低于目标值时触发。例如，设置目标 CPU 利用率为 80%，当所有 Pod 的平均利用率达到 85% 时，HPA 会增加 Pod 副本；当降至 70% 时，会减少副本。
- 内存利用率：与 CPU 类似，基于 Pod 的平均内存使用率进行伸缩。
自定义指标（Custom Metrics）：当资源指标无法满足业务需求时，可以使用自定义指标。例如，可以根据队列消息积压数量、每秒请求数（RPS）等业务指标来触发伸缩。这需要一个支持自定义指标的监控系统（如 Prometheus）与 K8s 集成，并通过 Metrics API 暴露这些指标。
外部指标（External Metrics）：外部指标与自定义指标类似，但其数据来源于 K8s 集群外部的系统。例如，可以根据数据库连接数、云服务商的队列长度等外部数据来触发伸缩。

三、HPA 的配置方法与关键参数

HPA 的配置通过一个 YAML 文件完成，这个文件定义了伸缩的规则、指标和范围。

1. HPA YAML 文件示例

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 500Mi

2. 关键参数详解

scaleTargetRef：指定 HPA 所关联的资源对象，通常是 Deployment 或 ReplicaSet。
minReplicas：定义 Pod 副本的最小数量。即使负载很低，HPA 也不会将副本数减少到这个值以下。
maxReplicas：定义 Pod 副本的最大数量。这是为了防止系统在极端情况下过度伸缩，导致资源耗尽或成本失控。
metrics：伸缩的触发指标列表。
- type: Resource：指定指标类型为资源指标。
  - name: cpu：指标名称为 CPU。
  - target.type: Utilization：指标目标类型为利用率。
  - target.averageUtilization: 80：Pod 的平均 CPU 利用率达到 80% 时触发伸缩。
- type: Resource：指定指标类型为资源指标。
  - name: memory：指标名称为内存。
  - target.type: AverageValue：指标目标类型为平均值。
  - target.averageValue: 500Mi：Pod 的平均内存使用量达到 500MiB 时触发伸缩。

四、HPA 的伸缩算法与计算细节

HPA 的核心是其计算期望副本数的算法。理解这个算法对于调优 HPA 至关重要。

1. 伸缩算法

HPA 控制器会为每个指标独立计算一个期望的副本数，然后取这些计算结果中的最大值作为最终的期望副本数。

对于资源指标（如 CPU 利用率），HPA 使用以下公式：

期望副本数 = ceil[当前副本数 * (当前指标值 / 目标指标值)]

例如，当前有3个 Pod 副本，目标 CPU 利用率为 80%，而当前平均 CPU 利用率为 120%。

期望副本数 = ceil[3 * (120% / 80%)] = ceil[3 * 1.5] = 5

HPA 将会把副本数增加到5个。

2. 冷却与延迟

为了防止 Pod 数量频繁波动，HPA 内置了冷却（Cooling）和延迟机制。

稳定窗口（stabilizationWindowSeconds）：在默认情况下，HPA 在缩容时会有一个延迟。控制器会考虑在最近一段时间内（默认300秒）观察到的最高期望副本数，以防止因短暂的负载下降而频繁缩容。
冷却时间（--horizontal-pod-autoscaler-downscale-stabilization）：这是 HPA 控制器的一个参数，用于控制 Pod 缩容后需要等待多久才能再次缩容。默认值也是300秒。

五、HPA 在云计算中的最佳实践与高级配置

在实际的生产环境中，正确配置和优化 HPA 能够显著提升业务的稳定性和成本效益。

1. 配置资源请求（Requests）与限制（Limits）

HPA 的资源指标（如 CPU 利用率）是基于 Pod 的**资源请求（requests）**来计算的。因此，为 Pod 配置合理的 requests 是 HPA 正常工作的先决条件。

requests：Pod 启动时向 K8s 申请的最低资源。这是 HPA 计算利用率的分母。
limits：Pod 能够使用的最大资源上限。这用于防止单个 Pod 消耗过多资源影响其他 Pod。

2. 避免过度伸缩与“饥饿”问题

设置合理的 minReplicas：根据业务的最低负载，设置一个合理的最小副本数，以应对突发流量。
设置合理的 maxReplicas：防止因伸缩失控导致资源耗尽。
使用自定义指标：当 CPU 或内存指标无法准确反映业务负载时，应使用自定义指标。例如，对于消息队列消费者，根据队列中的消息数量进行伸缩更为合理。

3. 应对突发流量的伸缩策略

HPA 默认的伸缩速度可能无法应对瞬时巨大的流量高峰。在这种情况下，可以调整 HPA 的伸缩策略。

伸缩策略（scalingPolicy）：HPA v2 API 引入了伸缩策略，允许我们配置更激进的伸缩行为。
- type: Pods：根据 Pod 的数量进行伸缩。
- periodSeconds：在一个时间窗口内，可以增加或减少的 Pod 数量。
- value：具体增加或减少的 Pod 数量。

4. 多 HPA 实例与多指标组合

一个 Deployment 可以关联多个 HPA 对象，但官方不推荐这种做法。更推荐的是在一个 HPA 对象中配置多个指标。HPA 控制器会计算每个指标对应的期望副本数，然后取其中最大值进行伸缩。

5. 结合 Cluster Autoscaler

HPA 只负责在已有的节点上调整 Pod 数量。当所有节点的资源都已耗尽，HPA 将无法再增加 Pod。这时，就需要Cluster Autoscaler（集群自动伸缩器）出场。

工作流程：HPA 尝试增加 Pod 数量，但没有足够的资源。Pod 保持在 Pending 状态。Cluster Autoscaler 检测到 Pending 状态的 Pod，并判断当前集群无法满足资源需求。它会向云服务商请求增加新的节点。新节点加入集群后，Pending 状态的 Pod 将被调度到新节点上运行。

HPA 与 Cluster Autoscaler 的协同工作，构成了云计算环境下完整的弹性伸缩解决方案。