2. HPA 架构解析：HPA 控制器、Metrics Server、目标工作负载之间的数据流与交互逻辑
Horizontal Pod Autoscaler（HPA）是 Kubernetes 实现工作负载弹性伸缩的核心组件。理解 HPA 的内部数据流与交互逻辑，是进行参数调优与压测验证的前提。本章从组件职责、数据采集链路、决策循环三个维度，拆解 HPA 的完整架构。
2.1 核心组件与职责
HPA 的运作依赖三个关键角色：HPA 控制器、Metrics Server 和 目标工作负载（Deployment / StatefulSet）。三者通过标准的 Kubernetes API 与指标管道协作。
| 组件 | 运行位置 | 核心职责 | 数据来源 |
|---|---|---|---|
| HPA 控制器 | kube-controller-manager 内 | 定期执行扩缩容算法，计算期望副本数，更新目标工作负载的 replicas 字段 | Metrics Server 提供的 Pod 指标；自定义/外部指标 API |
| Metrics Server | 集群内独立 Pod（kube-system） | 从 kubelet 的 cAdvisor 接口采集 Pod 资源指标（CPU / 内存），聚合后通过 metrics.k8s.io API 暴露 | kubelet / cAdvisor |
| 目标工作负载 | 集群内业务命名空间 | 运行业务容器，暴露 Pod 标签与资源请求/限制；HPA 通过 scale 子资源调整其副本数 | 自身 Pod 状态 |
关键认知：Metrics Server 仅提供实时快照数据，不存储历史指标。HPA 控制器每次评估时都会重新拉取最新指标，因此 Metrics Server 的响应延迟直接影响 HPA 决策的时效性。
2.2 数据流与交互逻辑
HPA 的完整数据流遵循一个闭环周期：指标采集 → 指标暴露 → 控制器拉取 → 算法计算 → 副本调整 → 状态反馈。下图展示了这一交互逻辑。
2.3 指标采集与暴露链路
Metrics Server 是 HPA 获取资源指标的唯一标准来源。其内部工作流程如下：
- kubelet 内置 cAdvisor：每个节点上的 kubelet 内嵌 cAdvisor，以 15s 为周期采集本地 Pod 的 CPU 和内存使用数据。
- Metrics Server 拉取：Metrics Server 通过 kubelet 的
/metrics/resource端点，以--kubelet-use-node-status-port方式获取每个节点的 Pod 指标。 - 聚合与暴露：Metrics Server 将原始指标按 Pod 维度聚合，通过
metrics.k8s.ioAPI 对外暴露。HPA 控制器通过APIService注册的路径/apis/metrics.k8s.io/v1beta1拉取数据。
性能要点：Metrics Server 默认每 15s 从 kubelet 拉取一次指标，HPA 控制器默认每 15s 评估一次。这意味着从指标产生到 HPA 做出决策，理论最大延迟为 30s（15s 采集间隔 + 15s 评估间隔）。在压测场景中，这一延迟直接影响扩容响应速度。
2.4 HPA 控制器决策循环
HPA 控制器内部运行一个定时循环，每次迭代执行以下步骤：
| 步骤 | 操作 | 涉及 API | 关键参数 |
|---|---|---|---|
| 1 | 获取目标工作负载的当前副本数 | /apis/apps/v1/namespaces/{ns}/deployments/{name}/scale |
spec.replicas |
| 2 | 拉取所有关联 Pod 的当前指标 | /apis/metrics.k8s.io/v1beta1/namespaces/{ns}/pods |
Pod 标签选择器 |
| 3 | 计算当前指标平均值（总指标 / 副本数） | 内部计算 | 忽略未就绪 Pod |
| 4 | 执行扩缩容算法：desiredReplicas = ceil[currentReplicas × (currentMetric / desiredMetric)] |
内部计算 | --horizontal-pod-autoscaler-tolerance（默认 0.1） |
| 5 | 检查是否满足冷却/稳定窗口 | 内部状态 | --horizontal-pod-autoscaler-downscale-stabilization-window（默认 5m） |
| 6 | 更新目标工作负载的 spec.replicas |
PUT /apis/apps/v1/namespaces/{ns}/deployments/{name}/scale |
新副本数 |
2.5 关键交互细节
- Pod 就绪状态过滤：HPA 在计算指标平均值时，默认只统计
status.conditions[type=Ready].status=True的 Pod。未就绪 Pod 的指标会被忽略，避免扩容期间指标被稀释。 - 指标缺失处理：如果某个 Pod 的指标完全缺失（例如刚启动），HPA 会将其视为 0 值参与平均计算。这可能导致扩容不足，因此生产环境建议配合
--horizontal-pod-autoscaler-initial-readiness-delay参数（默认 30s）延迟纳入。 - 并发与一致性：HPA 控制器通过
resourceVersion乐观锁更新 scale 子资源，避免多个 HPA 对象或手动调整副本数时产生冲突。
常见陷阱：如果 Metrics Server 响应缓慢或 Pod 指标采集超时，HPA 控制器会跳过本次评估周期，并在日志中记录
failed to get metrics。压测时务必监控 Metrics Server 的 metrics_server_scraper_duration_seconds 指标，确保采集延迟在 5s 以内。
2.6 架构总结
HPA 的架构设计遵循“松耦合、标准接口”原则：
- 数据面：kubelet → Metrics Server → HPA 控制器，形成单向指标流。
- 控制面：HPA 控制器 → API Server → 工作负载控制器，形成副本调整闭环。
- 关键约束：指标采集周期、评估周期、冷却窗口共同决定了弹性伸缩的响应速度与稳定性。