必须确保Metrics Server就绪、Deployment设置CPU requests、HPA与Deployment同命名空间，三者缺一不可；否则HPA的TARGETS列显示“<unknown>/50%”，无法正常扩缩容。
在Kubernetes集群中让服务随CPU负载变化自动增减Pod副本数，必须确保Metrics Server已就绪、目标Deployment设置了资源requests、且HPA对象能正确关联到控制器。缺一不可，否则TARGETS列会始终显示
确认前置条件是否满足
执行kubectl get apiservice v1beta1.metrics.k8s.io，返回STATUS为True才代表Metrics Server已正常注册；若为False或NotFound，HPA无法获取任何指标数据，后续所有配置都无效。
检查你的Deployment中每个容器是否定义了resources.requests.cpu，例如cpu: 100m。HPA计算利用率的分母就是这个值，没有它，指标值无法归一化，HPA直接拒绝工作。
运行kubectl get hpa，如果看到某条记录的TARGETS列为
方法一：用kubectl autoscale命令快速创建
执行kubectl autoscale deployment hpa-demo --cpu-percent=50 --min=1 --max=10，这条命令会在当前命名空间下立即生成一个v1版HPA对象。
该命令隐式绑定到名为hpa-demo的Deployment，要求其至少有1个副本、最多10个，当所有Pod平均CPU使用率持续超过50%时触发扩容，低于50%则缩容。
【注意】此方式仅支持CPU指标，且生成的是v1版本HPA，无法叠加内存或自定义指标。
方法二：用YAML文件精确控制（推荐）
创建hpa-cpu.yaml文件，内容如下：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: hpa-cpu-demo
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: hpa-demo
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
执行kubectl apply -f hpa-cpu.yaml即可生效。v2版本支持多指标、行为控制（behavior）、更细粒度的目标类型（如averageValue），是生产环境首选。
其中scaleTargetRef.name必须与目标Deployment的metadata.name完全一致，大小写敏感；若填错，HPA将找不到被控对象，状态长期卡在
验证HPA是否真正开始工作
第一步：执行kubectl get hpa hpa-cpu-demo，观察TARGETS列是否从
第二步：对服务制造真实CPU压力，例如用kubectl exec进入Pod后运行yes > /dev/null &，持续1分钟后观察REPLICAS列是否上升。
第三步：停止压测，等待约5分钟（HPA默认缩容冷却期为5分钟），确认副本数回落。若不缩容，大概率是behavior中没有显式配置scaleDown，v2默认缩容策略保守，需手动补全。
执行kubectl describe hpa hpa-cpu-demo，重点查看Events部分是否有Warning级别的FailedGetResourceMetric或FailedComputeMetricsReplicas事件，它们会明确指出是指标拉取失败还是计算逻辑被阻断。
