第十二节 HPA 指标驱动弹性伸缩

约 1221 字大约 4 分钟

KubernetesHPAMetrics ServerAutoscaling

2026-07-28

本课目标

为虚构业务“云帆商城”建立 CPU 指标驱动的水平扩缩容；安装并验证资源指标链路，执行限时压测，记录 HPA 的指标、副本和事件时间线。

12.1 接单：弹性不是简单地“副本加一”

HPA 控制器周期读取指标，根据当前副本与目标值计算期望副本，更新 Deployment 的 scale 子资源。

期望副本数 = ceil(当前副本数 × 当前指标值 ÷ 目标指标值)

HPA 如何计算期望副本

观察指标、请求值、目标利用率与副本上限。

1 / 5

阶段 1Metrics API已观察

→

阶段 2当前/目标比值待观察

→

阶段 3期望副本待观察

→

阶段 4Scale待观察

CPU 利用率以容器 resources.requests.cpu 为基准。没有 CPU request 时，HPA 无法为该 Pod 计算基于利用率的伸缩建议。

12.2 前置条件：打通资源指标 API

先检查指标链路：

kubectl get apiservice v1beta1.metrics.k8s.io
kubectl top nodes
kubectl top pods -A

若尚未安装 Metrics Server，本地 kind 实验可锁定官方 v0.8.1 清单。资源指标 API 组名是 metrics.k8s.io。

仅限本地实验

--kubelet-insecure-tls 会跳过 kubelet 服务证书校验，只用于 kind 本地实验。生产环境应配置可验证的 kubelet 证书与网络边界，不能照搬此参数。

若 kubectl top 暂无数据，等待一个采集周期后再试，并检查：

kubectl logs -n kube-system deployment/metrics-server
kubectl describe apiservice v1beta1.metrics.k8s.io

12.3 创建可伸缩工作负载

CPU request 字段名是 requests。它既影响调度，也为 CPU 利用率型 HPA 提供分母。

kubectl apply -f manifests/12-hpa/yunfan-hpa.yaml
kubectl rollout status deployment/yunfan-hpa-demo \
  -n yunfan-shop \
  --timeout=120s
kubectl get hpa yunfan-hpa-demo -n yunfan-shop
kubectl top pod -n yunfan-shop \
  -l app.kubernetes.io/name=yunfan-hpa-demo

TARGETS 初期可能显示 <unknown>；只有指标 API、Pod 指标和 CPU request 同时可用，HPA 才能进入正常计算。

12.4 限时压测与副本时间线

扩容与回落为什么有延迟

按时间观察负载、指标、建议副本和实际副本。

1 / 5

阶段 1负载已观察

→

阶段 2指标采集待观察

→

阶段 3扩容待观察

→

阶段 4稳定与回落待观察

创建最长运行 120 秒的负载发生器：

kubectl run yunfan-load \
  -n yunfan-shop \
  --image=busybox:1.36.1 \
  --restart=Never \
  --command -- \
  sh -c 'end=$(($(date +%s)+120)); while [ "$(date +%s)" -lt "$end" ]; do wget -q -O- http://yunfan-hpa-demo; done'

另开终端观察：

kubectl get hpa,pod -n yunfan-shop -w

记录至少四个时间点：

时间	CPU TARGETS	DESIRED	CURRENT	事件
基线	低于目标	1	1	无负载
升压	高于目标	增加	1	ScaleUp
稳态	接近目标	稳定	多副本	负载分摊
降压后	回落	逐步减少	多副本到 1	稳定窗口生效

压测结束后：

kubectl logs yunfan-load -n yunfan-shop
kubectl delete pod yunfan-load -n yunfan-shop --ignore-not-found
kubectl describe hpa yunfan-hpa-demo -n yunfan-shop

扩容不会瞬时完成，缩容通常更慢，这是采样周期、容器启动和稳定窗口共同作用的结果。

12.5 常见故障矩阵

现象	首查	常见根因
`kubectl top` 报错	APIService、Metrics Server 日志	指标 API 未就绪或证书连接失败
HPA TARGETS 为 unknown	Pod request、指标 API	缺少 CPU request 或无指标
CPU 很高但不扩容	maxReplicas、事件	已到上限或控制器无法读取指标
负载结束后不立即缩容	behavior、时间线	稳定窗口与采样延迟
Pod 增加但 Pending	节点资源、调度事件	集群容量不足

HPA 只能增加或减少副本，不能自动增加节点；本地 kind 集群没有集群自动扩容器。

12.6 交付

锁定 Metrics Server 版本的安装与验证记录。
Deployment、Service 与 autoscaling/v2 HPA 清单。
CPU、DESIRED、CURRENT 与事件的时间线。
一段说明：为什么 request、最大副本和集群容量共同限制弹性。

本章小测

本章小结

HPA 是读取指标、计算期望副本并更新 scale 子资源的反馈控制循环。
CPU 利用率型 HPA 依赖 Metrics Server 和容器 CPU request。
扩缩容存在采样、启动和稳定窗口延迟，必须用时间线验证。
HPA 解决 Pod 副本弹性，不等于节点容量会自动增长。