3. HPA 原理深度解析

在 Serverless 平台容量调优场景中，Horizontal Pod Autoscaler（HPA）是连接业务负载与底层资源的核心决策引擎。理解 HPA 的工作原理、指标采集管道以及扩缩容算法，是进行租户配额校准的前提。本章将深入剖析 HPA 的内部机制，帮助运维人员精准掌握其行为边界。

3.1 Kubernetes HPA 工作原理

HPA 是一个控制循环组件，周期性地（默认 15 秒）检查 Pod 的指标数据，并根据预设的目标值计算期望的副本数。其核心工作流包含三个步骤：采集 → 计算 → 执行。

3.2 指标采集管道

HPA 依赖标准的指标 API 获取数据。Kubernetes 生态中主要有两种采集管道：Metrics Server（资源指标）和 Prometheus Adapter（自定义指标）。

3.2.1 Metrics Server

Metrics Server 是一个集群级别的资源指标聚合器，从每个节点的 kubelet 收集 CPU 和内存使用数据。它通过 metrics.k8s.io API 对外暴露数据，是 HPA 使用资源指标（Resource Metrics）的默认来源。

• 数据来源： kubelet 内置的 cAdvisor 接口。
• 采集粒度： 默认每 60 秒采集一次，数据保留在内存中。
• 适用场景： 基于 CPU 利用率、内存利用率的简单扩缩容。
• 局限性： 不支持自定义指标（如 QPS、请求延迟），数据精度较低。

3.2.2 Prometheus Adapter

Prometheus Adapter 是一个自定义指标适配器，它从 Prometheus 查询数据，并将其转换为 Kubernetes 自定义指标 API（custom.metrics.k8s.io）或外部指标 API（external.metrics.k8s.io）的格式。

• 数据来源： Prometheus 时序数据库。
• 采集粒度： 取决于 Prometheus 的 scrape 配置，通常为 15-30 秒。
• 适用场景： 基于业务指标（如 HTTP 请求数、队列深度、gRPC 延迟）的精细化扩缩容。
• 配置方式： 通过 ConfigMap 定义指标查询规则（seriesQuery、metricsQuery）。

3.3 扩缩容算法与冷却窗口

HPA 的扩缩容决策基于一个核心公式，并辅以冷却窗口机制来防止震荡。

3.3.1 核心算法公式

HPA 计算期望副本数的公式如下：

desiredReplicas = ceil[currentReplicas × (currentMetricValue / desiredMetricValue)]

• currentMetricValue： 当前所有 Pod 的指标平均值。
• desiredMetricValue： HPA 配置的目标值。
• currentReplicas： 当前运行的 Pod 副本数。
• ceil： 向上取整，确保副本数不会出现小数。

例如，当前有 4 个 Pod，CPU 平均利用率为 80%，目标值为 50%，则期望副本数为 ceil[4 × (80% / 50%)] = ceil[6.4] = 7。

3.3.2 冷却窗口机制

为了防止指标抖动导致频繁扩缩容，HPA 引入了冷却窗口（Cool Down Window）。

• 扩容冷却窗口（--horizontal-pod-autoscaler-upscale-delay）： 默认 3 分钟。HPA 在触发扩容后，必须等待该时间窗口才能再次执行扩容决策。
• 缩容冷却窗口（--horizontal-pod-autoscaler-downscale-delay）： 默认 5 分钟。HPA 在触发缩容后，必须等待该时间窗口才能再次执行缩容决策。

3.3.3 算法行为细节

HPA 在计算时还会考虑以下边界条件：

• 稳定窗口（Stabilization Window）： 在缩容时，HPA 会取稳定窗口内所有计算结果的最大值，避免因瞬时低指标导致过度缩容。
• 容忍度（Tolerance）： 默认 0.1（10%）。当指标偏差在 10% 以内时，HPA 不会触发扩缩容，避免无意义的副本数调整。
• 最大/最小副本数： 由 HPA 配置的 minReplicas 和 maxReplicas 硬性约束。

3.4 关键参数与调优建议

在 Serverless 平台中，HPA 的默认参数通常无法满足租户配额校准的精度要求。以下参数需要重点关注：