targetaverageutilization仅适用于cpu/memory资源指标（百分比），targetaveragevalue用于自定义/外部指标（具体数值）；混用会导致hpa无法获取指标而失败。
HPA 里 targetAverageUtilization 和 targetAverageValue 别混用
这两个参数看着像一对，其实语义完全不同：前者只对 CPU 和 memory 这类资源指标生效，且是百分比（比如 70 表示 70% 的 request）；后者才是通用数值型目标，比如你想让 Pod 平均每秒处理 100 个请求，就得用 targetAverageValue: 100，还得配 metricName 和 metrics 字段。
常见错误现象：targetAverageUtilization 被误用于自定义指标（如 http_requests_total），结果 HPA 一直报 failed to get cpu utilization 或直接不拉伸——它压根不认这个字段。
- 用 CPU/memory → 优先选
targetAverageUtilization，写法简单、兼容性好（所有 K8s 版本都支持） - 用自定义指标或外部指标 → 必须弃用
targetAverageUtilization，改用metrics数组 +targetAverageValue或targetValue - K8s v1.23+ 开始，
autoscaling/v2beta2已废弃，统一用autoscaling/v2，字段结构有变化，老配置直接 apply 会失败
Python 应用暴露指标前，先确认 metrics-server 能抓到你的 Pod
HPA 不读 Prometheus，它默认只认 metrics-server 提供的 cpu 和 memory。如果你的 Python 服务加了 prometheus-client 暴露 /metrics，但没装 prometheus-adapter，HPA 就完全看不到那些自定义指标。
验证方法很简单：运行 kubectl top pods。如果返回空或报错 unable to fetch metrics，说明 metrics-server 没跑起来，或者你的 Pod 没设 resources.requests（它依赖 requests 计算利用率）。
立即学习“Python免费学习笔记（深入）”；
- 必须给容器加
resources.requests，哪怕只是cpu: 100m，否则targetAverageUtilization算不出百分比 -
metrics-server默认不采集自定义指标，别指望它能读你 Python 的http_requests_total - 想用自定义指标？得部署
prometheus-adapter，并确保它的rules正确把 Prometheus 查询映射成 HPA 可识别的 metric name
HPA 的 minReplicas 和 maxReplicas 不是“安全区”，而是硬边界
很多人以为设了 minReplicas: 2 就能防止单点故障，其实不是：当负载极低时，HPA 会缩到 2，但若整个 Deployment 只剩一个可用 Pod（比如滚动更新中），HPA 不会干预——它只管扩缩，不管可用性。
更关键的是，minReplicas 会影响 HPA 的初始行为。如果刚创建 HPA 时 Pod 还没就绪，它可能卡在 Unknown 状态，直到第一个 Pod Ready 并上报指标。
-
minReplicas设太小（比如 1），遇到瞬时毛刺可能反复扩缩，尤其 Python 启动慢，新 Pod 还没 ready 就又缩容了 -
maxReplicas不是性能上限，而是你愿为这服务付多少成本的红线；超过后 HPA 直接拒绝扩容，不会报警也不会降级 - 别依赖 HPA 保活，健康检查（
livenessProbe）和滚动更新策略（maxUnavailable）才是防宕机的关键
用 kubectl get hpa 看状态时，UNKNOWN 和 0%/70% 含义差很远
UNKNOWN 表示 HPA 根本没拿到任何指标数据——可能是 metrics-server 挂了、Pod 没 ready、指标名拼错，或者权限没给够（system:auth-delegator 角色缺失）。而 0%/70% 是正常态，表示当前利用率是 0%，目标是 70%，HPA 在等负载上来。
查不到数据时，别急着调参数。先跑 kubectl describe hpa <code>your-hpa-name，重点看 Events 里最后一行是不是 failed to get memory utilization 或类似提示。
- Events 里出现
did not receive metrics for any ready pods→ 检查 Pod 是否处于 Running + Ready 状态 - 出现
unable to get metrics for resource cpu→metrics-server连不上 kubelet，查其日志（kubectl logs -n kube-system deployment/metrics-server） - 看到
no metrics returned from custom metrics API→prometheus-adapter的 service 或 APIService 配置有问题
HPA 的延迟和抖动比想象中大：从指标采集、HPA controller 轮询（默认 15 秒）、到 Deployment 扩容（镜像拉取 + 启动），整个链路轻松超过 1 分钟。别拿它当实时响应工具，尤其是 Python 这种启动慢的服务。
