简介
调度器依靠资源请求来决定 Pod 的放置位置，kubelet 负责执行资源限制，而 HorizontalPodAutoscaler 则需要指标以及合理的利用率基准。这些控制机制共同构成了一套容量管理流程。
你将配置资源请求与限制、检查实时使用情况、创建 HPA、生成负载，并观察副本数量的变化。
这些设置之间存在依赖关系。CPU 请求建立利用率基准，metrics-server 报告近期使用量，HPA 将两者进行比较，以决定是否调整副本数量。如果不设置请求，基于百分比的 CPU 利用率就失去了计算依据。
设置请求与限制
在本步骤中，为 Kubernetes HPA 示例部署明确的资源配置。
请求是调度时使用的资源量，也是自动扩缩容计算利用率时的分母。限制是容器可使用的资源上限。CPU 使用核心数或毫核表示（100m 即 0.1 个核心）；内存则使用 Mi 等字节单位。
cd /home/labex/project/resource-autoscaling
kubectl create namespace practice-capacity
kubectl create deployment cpu-demo -n practice-capacity --image=registry.k8s.io/hpa-example:latest --replicas=1
为生成的 Deployment 添加资源配置。kubectl set resources 会更新 Pod 模板，因此会触发滚动更新：
kubectl set resources deployment/cpu-demo -n practice-capacity --requests=cpu=100m,memory=32Mi --limits=cpu=200m,memory=64Mi
kubectl expose deployment cpu-demo -n practice-capacity --port=80 --target-port=80
kubectl rollout status deployment/cpu-demo -n practice-capacity --timeout=60s
kubectl get deployment cpu-demo -n practice-capacity -o jsonpath='{.spec.template.spec.containers[0].resources}{"\n"}'
100m 表示十分之一个 CPU 核心。请求会影响调度和利用率计算；限制则会限制容器的资源消耗上限。
JSONPath 输出中应同时包含 requests 和 limits。仅声明限制并不能为 HPA 提供计算利用率所需的分母。
deployment "cpu-demo" successfully rolled out
{"limits":{"cpu":"200m","memory":"64Mi"},"requests":{"cpu":"100m","memory":"32Mi"}}
JSON 可能以不同顺序输出这些键。请检查四个值是否正确，不要依赖它们在行中的位置。
检查资源指标
在本步骤中，验证已准备好的指标链路并检查资源使用情况。
kubectl top 提供近期使用情况的快照，其作用类似于操作系统中的 top 命令。它不会显示已配置的请求或限制；这些配置仍属于工作负载定义的一部分。
cd /home/labex/project/resource-autoscaling
kubectl get deployment metrics-server -n kube-system
for attempt in $(seq 1 18); do
if kubectl top nodes >/dev/null 2>&1 && kubectl top pods -n practice-capacity --containers >/dev/null 2>&1; then
break
fi
echo "Waiting for the first metrics sample (${attempt}/18)..."
sleep 5
done
kubectl top nodes
kubectl top pods -n practice-capacity --containers
kubectl top 读取的是近期指标，而不是资源请求。指标可能需要一小段时间才会出现；如果新 Pod 暂时没有数据，请等待几秒后重试。
上面的循环会自动完成重试：它最多静默检查 18 次，每次间隔 5 秒；一旦有指标样本可用，就执行两个可见的 top 命令。在检查过程中，>/dev/null 会丢弃正常输出，2>&1 会将错误输出发送到同一位置，从而避免预期的「指标尚未就绪」消息干扰终端。对于刚建立的使用量指标链路而言，这种延迟是正常现象，并不表示 Pod 运行失败。
节点和 Pod 的数值会有所不同，因此应重点关注是否存在 CPU 和内存列，而不必关注具体数值。Pod 包含多个容器时，--containers 会分别显示每个容器的使用情况。
例如，测试环境产生的节点表和容器级别表如下：
NAME CPU(cores) CPU(%) MEMORY(bytes) MEMORY(%)
labex-v135 182m 9% 1602Mi 44%
POD NAME CPU(cores) MEMORY(bytes)
cpu-demo-... hpa-example 1m 9Mi
你的数值不同是正常的，因为这些是测量结果，而不是配置值。
创建 HorizontalPodAutoscaler
在本步骤中，将平均 CPU 利用率目标设置为 30%，并将副本数量限制在 1 至 4 个之间。
当 CPU 请求为 100m 时，30% 的目标值大约对应每个 Pod 平均使用 30m CPU。HPA 会调整 Deployment 的期望副本数，但不会低于 min=1，也不会高于 max=4。
cd /home/labex/project/resource-autoscaling
kubectl autoscale deployment cpu-demo -n practice-capacity --cpu=30% --min=1 --max=4
kubectl get hpa cpu-demo -n practice-capacity
kubectl describe hpa cpu-demo -n practice-capacity
利用率是相对于 100m CPU 请求计算的。如果没有这个请求，基于百分比的 CPU 目标就缺少计算分母。
当前的 kubectl autoscale 语法会通过 --cpu=30% 显式写入百分比。这取代了旧的 --cpu-percent 参数，Kubernetes 1.35 已将后者标记为弃用。
在最初几秒内，TARGETS 列可能显示 <unknown>，因为系统仍在收集新的指标样本。describe hpa 会显示相关条件和事件，帮助你判断控制器是否获得了可用指标。
因此，初始表格可能如下所示，这并不表示发生了错误：
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: <unknown>/30% 1 4 0
控制器完成下一次同步后，<unknown> 会变为实际测得的百分比，REPLICAS 也会反映 Deployment 的副本数。
生成负载并观察扩缩容
在本步骤中，运行一个临时客户端，在最长 60 秒内反复请求 Service。
BusyBox 的 timeout 命令会运行一个嵌套请求循环，持续 60 秒。while 循环会不断调用计算密集型示例端点，>/dev/null 会丢弃响应正文，使终端保持整洁。达到时间限制后，命令通常会返回非零状态，因此 || true 会将这一计划内的停止视为正常完成。
cd /home/labex/project/resource-autoscaling
kubectl run load-generator -n practice-capacity --image=busybox:1.36 --image-pull-policy=IfNotPresent --restart=Never --rm -i -- sh -c 'timeout 60 sh -c "while true; do wget -qO- http://cpu-demo >/dev/null; done" || true'
kubectl get hpa cpu-demo -n practice-capacity
kubectl get deployment cpu-demo -n practice-capacity
HPA 以异步方式运行，因此客户端退出后，副本数量仍可能继续变化。请检查 HPA 的条件和事件，不要假设扩缩容会立即完成。
如果第一张表中还没有出现扩缩容结果，可以短暂运行 kubectl get hpa cpu-demo -n practice-capacity -w，观察到变化后按 Ctrl+C 停止。-w 只会监视更新，不会修改 HPA。由于指标控制循环是异步的，验证过程不会要求固定的完成时间。
在测试运行中，HPA 观察到使用率超过目标值，将 Deployment 提升为两个就绪副本：
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: 55%/30% 1 4 2
NAME READY UP-TO-DATE AVAILABLE
cpu-demo 2/2 2 2
实际的利用率和副本数量可能不同。需要关注的是：当前利用率 55% 超过了目标值 30%，因此期望容量增加，同时仍处于 1 至 4 个副本的范围内。
总结
你已经将资源请求、限制、实时指标、利用率目标和 HPA 决策串联起来。容量管理本质上是一个反馈闭环：声明基准、观察使用情况、设定范围，并检查控制器状态。
