流量一涨 Pod 扩不出来？K8s HPA 弹性伸缩配置避坑指南

线上流量一涨，Pod 半天扩不出来，用户请求超时报 502；流量刚下去，Pod 又疯狂缩容，服务直接被中断。你打开 kubectl describe hpa，看到 current 那一栏写着 <unknown>------心态直接崩了。我踩过这个坑不止一次。这篇文章把 K8s HPA 弹性伸缩的 YAML 配置、工作原理、核心参数调优和常见故障排查一次性讲清楚。测试环境：K8s v1.28~v1.35，HPA API 版本 autoscaling/v2。

⚡ 速查急救包

遇到 HPA 不干活，先跑这几条命令：

bash 复制代码

# 1. 看 HPA 当前状态和事件
kubectl describe hpa <hpa-name> -n <namespace>

# 2. 检查 metrics-server 是否正常
kubectl top pods -n <namespace>

# 3. 检查 resource metrics API 是否可用
kubectl get apiservice | grep metrics

# 4. 先拿到 metrics-server Pod 名再查日志
kubectl get pods -n kube-system | grep metrics
kubectl logs <metrics-server-pod> -n kube-system --tail=50

# 5. 确认 Pod 的 requests 是否配置
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].resources.requests}'

如果第 1 条命令的 Conditions 里出现 FailedGetResourceMetric，直接跳到"常见报错排查"一节。

💡 为什么扩容慢？先看这三个延迟 。HPA controller 的默认同步周期是 15 秒 ，由 kube-controller-manager 的 --horizontal-pod-autoscaler-sync-period 参数控制。但 metrics-server 从 kubelet 采集数据大约需要 60 秒一次，再加上 Pod 启动时间（拉镜像、初始化），从流量上涨到新 Pod 真正就绪，通常有 1.5~3 分钟的感知延迟。如果你的业务对扩容速度敏感，需要从这三个环节分别优化，光调 HPA 参数解决不了根本问题。

搞清楚了延迟来源，接下来看看 HPA 到底是怎么做计算决策的------理解了公式，才知道为什么 requests 是命门。

🧠 HPA 到底怎么算的？搞懂这个才不会瞎配

HPA 的核心逻辑说白了就一个公式：

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

注意，CPU 利用率的"当前值"是基于 requests 算出来的，不是 limits，也不是节点实际 CPU 使用率。官方文档写得很清楚：controller 计算利用率时，用的是 Pod 中各容器 resource request 的百分比 。比如你给容器配了 requests.cpu: 500m，当前用了 400m，那利用率就是 80%。如果你配了 target.averageUtilization: 70，HPA 就认为需要扩容了。

📌 关键点 ：如果你的容器没配 requests，HPA 直接罢工，current 显示 <unknown>。很多新手以为设了 limits 就够了，结果 HPA 死活不动------问题就出在这。

HPA 决策路径表

| 阶段 | 做什么 | 关键参数 | | --- | --- | --- | | 采集 | 从 metrics-server 拉 CPU/内存，从 Adapter 拉自定义指标 | metrics-server 必须正常运行 | | 计算 | 按公式算出期望副本数 | requests 必须配置 | | 决策 | 和 maxReplicas/minReplicas 比对，应用 tolerance 过滤 | 默认 tolerance 10%，1.33 起可配置 | | 执行 | 通过 behavior 策略限制扩缩幅度和速度 | stabilizationWindowSeconds、policies、selectPolicy |

整个循环默认每 15 秒跑一次。容差（tolerance）的默认值是 10% ------算出来的期望值和当前值差距不到 10% 时 HPA 不动手，这是为了避免指标轻微波动就触发扩缩容。官方博客的示例给出了典型用法：扩容容差设 0（快速响应），缩容容差设 0.05（避免频繁抖动），配置写在 spec.behavior.scaleDown.tolerance 和 spec.behavior.scaleUp.tolerance 下。

这个特性经历了三个阶段：1.33 引入 Alpha （需手动启用 HPAConfigurableTolerance feature gate），1.35 升级为 Beta 并默认启用 ，计划在 1.37 达到 Stable 。KEP-4951 的官方 Issue 页面和 kep.yaml 文件都记录了这三个版本号，PR #5564 的标题就是"Set the beta graduation of KEP-4951 to 1.35"，diff 中可以看到 beta: "v1.35" 的设置。

⚠️ 三个细节需要留意：

一是 PR #5564 提交时 stable 字段还是 TBD，1.37 的 stable 目标是在后续更新中才确定的 ------如果你去查这个 PR 的 diff，看到 stable: TBD 是正常的。

二是 KEP 文件中 latest-milestone 设为 "v1.35"。这个字段表示当前正在推进的活跃阶段是 Beta，其对应的版本号是 1.35 ------而 milestone 字段记录的是各成熟度阶段（alpha/beta/stable）分别对应的版本号。两者结合看，Beta 是当前正在推进的阶段，Stable 目标已确定为 1.37。

三是 Kubernetes 博客的更新提交中曾出现过"promoted to beta in version 1.34"的表述，与 KEP 官方记录不一致。这种差异可能源于 feature gate 的代码合入时间与正式发布版本之间的调整 ------PR 可能先合入 1.34 分支，但正式对外宣布的 Beta 版本跟随 KEP 记录为 1.35。以 KEP 官方记录为准，Beta 目标版本是 1.35。

还有一点容易困惑：API 文档中 tolerance 字段的标注存在来源不一致 。官方 API 参考文档（pkg.go.dev）中该字段的注释仍然写着"This is an alpha field and requires enabling the HPAConfigurableTolerance feature gate"，但 Pulumi 等第三方文档和社区 CRD 已经更新为"This is an beta field"。这是官方 API 文档更新滞后的表现，不代表 feature gate 本身还是 Alpha。你在 1.35 集群上启用并看到这个标注时，直接看 feature gate 的实际状态即可。

🔧 YAML 怎么写？从最小可用到生产级

最小可用版本

bash 复制代码

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70   # CPU 利用率超过 70% 触发扩容

这个配置能跑，但生产环境大概率不够用。因为它没配 behavior，缩容走的是默认策略------缩容稳定窗口默认 300 秒，扩容稳定窗口是 0。问题在于扩容策略默认每 15 秒最多翻倍，在流量突增场景下可能不够快。

生产级配置：加上 behavior 精细控制

这是我目前在用的模板，扩得快、缩得慢、不抖动：

bash 复制代码

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 30
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 65
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0   # 扩容不等，立刻响应
      policies:
      - type: Percent
        value: 100                    # 一次最多扩 1 倍
        periodSeconds: 15
      - type: Pods
        value: 5                      # 一次最多加 5 个 Pod
        periodSeconds: 15
      selectPolicy: Max               # 选扩容幅度最大的策略
    scaleDown:
      stabilizationWindowSeconds: 300 # 缩容看 5 分钟，避免抖动
      policies:
      - type: Percent
        value: 20                     # 一次最多缩 20%
        periodSeconds: 60
      selectPolicy: Min               # 选缩容幅度最小的策略

这套配置在线上跑了半年多，没出现过流量抖动导致的误缩容。

stabilizationWindowSeconds 到底怎么工作的？ HPA 在这个窗口内会回看历史扩缩建议。缩容时取窗口内最高的建议值，扩容时取最低的建议值。为什么？因为缩容取最高值意味着"缩得最少"，扩容取最低值意味着"扩得最少"------本质都是取最保守的那个结果。

Red Hat 文档对这个机制的解释非常到位：考虑过去 5 分钟内所有计算出的期望状态，"这近似于一个滚动最大值 （rolling maximum），避免扩缩算法频繁地删除 Pod 又紧接着触发重新创建等量的 Pod"。取最高值意味着缩容窗口起到的是"刹车"作用，而不是"油门"------它不是在推动缩容，而是在阻止缩容。

⚠️ selectPolicy 的默认值是 Max------这是最隐蔽的坑

selectPolicy 字段决定了当有多个缩容策略时用哪个。Red Hat 官方文档写得非常明确：

"如果定义了多个策略，则决定首先使用哪个策略。指定 Max 使用允许最多更改的策略 ，Min 使用允许最小更改的策略，或者 Disabled 阻止 HPA 在策略方向进行扩展。默认值为 Max。"

Kubernetes 上游 API 参考中 HPAScalingPolicy 的 selectPolicy 字段说明也是同样的默认值语义。翻译成人话：如果你配了 scaleDown 的 policies 但没写 selectPolicy: Min，缩容会走 Max------哪个策略允许缩得最多就用哪个。我见过不止一个团队踩了这个坑，配了缩容策略以为能限制缩容速度，结果 Pod 缩得比预期快，排查了两天才发现是默认值在作祟。

上面生产级 YAML 里我显式写了 selectPolicy: Min，这才是"选缩容幅度最小的策略"的正确姿势。

🕳️ 那些年我踩过的坑

坑一：requests 配太低，HPA 一直以为在过载

有次上线一个新服务，requests.cpu 配了 100m，target utilization 设了 70%。结果 Pod 一启动 HPA 就疯狂扩容------因为实际启动阶段 CPU 用了 200m，利用率直接飙到 200%。等了十分钟才稳定下来，白白多跑了一堆 Pod。

教训：requests 要按稳态运行时的实际用量配，别图省钱往低了写。一般建议 requests 设成基线用量的 1.2~1.5 倍。但有个前提：如果你同时启用了 VPA 的 Auto 模式，这个倍数需要重新评估 。VPA 降低 requests 会导致 HPA 计算的利用率虚高，HPA 扩容后单个 Pod 负载降低，VPA 再次调低 requests，循环往复------社区里管这个叫 VPA/HPA 正反馈循环风险 。我的建议是：HPA 和 VPA 不要同时基于 CPU/内存工作，要么用 VPA 的 Off 模式只做推荐，要么 HPA 改用自定义指标（比如 QPS、队列长度），把资源维度的调控交给 VPA。

坑二：K8s 1.23 之后还在调全局参数

这个坑很多人踩。1.23 之前可以通过 kube-controller-manager 的 --horizontal-pod-autoscaler-upscale-delay 和 --horizontal-pod-autoscaler-downscale-delay 控制扩缩容延迟。1.23 之后这些全局参数弃用了，改成在 HPA YAML 里配 behavior。我第一次升级集群的时候没注意，改了半天 kube-controller-manager 的启动参数，HPA 纹丝不动。

坑三：多指标场景下的"最大副本数"逻辑

配了 CPU 和内存两个指标的时候，HPA 分别算出各自的期望副本数，然后取最大值。这个机制完整链条是这样的：

假设 CPU 利用率 40%、目标 70%，比值 0.57，当前 5 个副本 → CPU 期望 3 个。内存利用率 90%、目标 70%，比值 1.28，当前 5 个副本 → 内存期望 7 个。HPA 取 max(3, 7) = 7，也就是按内存那条线来扩。

问题出在内存 requests 配得特别小的时候：利用率虚高 → 比值虚高 → 期望副本数虚高。CPU 其实还闲着呢，HPA 已经按内存的"假信号"扩了一堆 Pod。所以两个指标的 requests 都要配得合理。

配置层面理顺了，基础设施层面还有一个最容易忽略的坑------

坑四：metrics-server 挂了但没人发现

HPA 显示 <unknown> 的根源基本都在 metrics-server 或者 resource metrics API。我遇到过最隐蔽的一次是 metrics-server 的 http2 库在网络抖动时报 http2: no cached connection was available，导致 kubectl top pod 间歇性无返回，HPA 跟着间歇性失效。

这个报错原文在阿里云 ACK 的官方文档中有明确记录，影响版本是 v0.2.2-473c961-aliyun 和 v0.2.2-b4bf266-aliyun，修复版本是 v0.2.3-8a48069-aliyun 及以上。但如果你是 自建集群 用的上游 metrics-server，碰到网络抖动时更常见的表现是 context deadline exceeded 或直接超时无返回，不一定出现这个特定的 http2 报错。

⚠️ 通用排查思路 ：无论你用哪个发行版，如果 kubectl top pod 出现间歇性无返回 ，都应该优先排查 metrics-server 与 kubelet 之间的网络连接稳定性。具体表现为：kubectl top 时好时坏、HPA 的 current 值偶尔变成 <unknown>、删除 namespace 时卡在 Terminating 状态。

有个可操作的 workaround：在 metrics-server 的启动参数中加入 --disable-http2-serving=true 可以绕过 http2 连接复用问题 ，OpenShift 的 metrics-server 部署中已经默认加了这个参数。该标志源于上游 SecureServingOptions 中的 DisableHTTP2Serving（上游 Kubernetes PR #122176 引入，metrics-server 在 v0.8.0 及之后的版本中集成了该标志）。但要注意三点：一是如果你的 metrics-server 版本较旧，加了会报 unknown flag ，建议先通过 kubectl logs 或 --help 确认支持的启动参数；二是 该标志主要影响的是外部客户端（如 kubectl top、HPA controller）连接 metrics-server 时的 HTTP/2 连接复用问题 。如果你的 http2 报错出现在 metrics-server 主动去拉取 kubelet 指标的链路上，这个标志不起作用，需要从网络层面排查 metrics-server 到 kubelet 的 10250 端口连通性；三是 禁用 HTTP/2 后回退到 HTTP/1.1，在某些大规模集群下可能带来 CPU 开销增加，不过 OpenShift 的实践表明这个代价在大多数场景下是可接受的。

这种间歇性问题最难排查，建议给 metrics-server 的可用性加监控告警，别等 HPA 不干活了才发现。

✅ 验证 HPA 是否正常工作

配好之后别急着上线，按这几步验证：

第零步：确认 target 存在

bash 复制代码

kubectl get deployment my-app -n production
# 如果 Deployment 不存在，HPA 的 Events 会提示 failed to get scale target

第一步：确认 metrics 能拉到数据

bash 复制代码

kubectl top pods -n production
# 有输出说明 metrics-server 正常
# 报错 "error: Metrics API not available" 说明 metrics-server 有问题

第二步：看 HPA 的 current 值

bash 复制代码

kubectl describe hpa my-app-hpa -n production
# 关注 Metrics 那一行，current 不能是 <unknown>
# 关注 Conditions，ScalingActive 应该是 True

第三步：压测验证扩缩行为

用 hey 或 wrk 打一波流量上去，观察 Pod 数量变化：

bash 复制代码

kubectl get pods -n production -w -l app=my-app

❓ 常见报错排查

报错一： the server is currently unable to handle the request (get pods.metrics.k8s.io)

这是 HPA 最常见的报错，原因是 kube-controller-manager 访问不到 resource metrics API。排查顺序：

bash 复制代码

# 1. 先看 metrics-server Pod 状态
kubectl get pods -n kube-system | grep metrics-server

# 2. 再看 apiservice 状态
kubectl get apiservice v1beta1.metrics.k8s.io -o yaml

# 3. 如果 metrics-server 是 Running 但没数据，先拿到 Pod 名再查日志
kubectl logs <metrics-server-pod> -n kube-system

常见修复方式：metrics-server 需要加 --kubelet-insecure-tls 参数（测试环境），或者检查网络策略是否阻断了 metrics-server 到 kubelet 的 10250 端口。

报错二： unable to get metrics for resource cpu: no metrics returned

这个通常是因为 Pod 没有配 requests.cpu。HPA 计算 CPU 利用率的公式是 usage / requests，没有 requests 分母就是零，直接报错。检查方法：

bash 复制代码

kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].resources.requests.cpu}'
# 返回空就是没配

报错三：HPA 显示 ScalingActive: False, reason: FailedGetResourceMetric

如果 kubectl top pod 有数据但 HPA 还是报这个错，大概率是 kube-controller-manager 的 --horizontal-pod-autoscaler-use-rest-clients 配置问题，或者 API Aggregation 层有故障。先重启一下 metrics-server 试试，还不行就得看 kube-controller-manager 的日志了。

🎁 彩蛋：三个少有人知的细节

⚠️ HPA + VPA 同时用？原地扩缩容的"永久失真"比你想的严重。

核心问题一句话：HPA 从 pod.spec 读取 requests 计算利用率，但原地扩缩容时 Kubelet 异步调整 cgroups------spec 已经更新但实际资源还没跟上 。Issue #142155 的原文指出，ReplicaCalculator 严格从 pod.spec 读取容器资源请求，而物理容量的实际生效通过 Kubelet cgroups 是异步的。

GitHub Issue #142155 描述了两个方向的失真：

扩方向（requests 调大） ：requests 从 1 核调到 4 核，分母立即跳到 4 核，但容器实际还在用 1 核运行。HPA 用 0.9 核除以 4 核，利用率从 90% 虚假地跌到 22.5%，触发不必要的缩容。
缩方向（requests 调小） ：VPA 把 requests 从 4 核调到 1 核，分母的下降速度远快于 cgroups 的调整速度，利用率出现虚假峰值，触发不必要的横向扩容。

最严重的情况是 Infeasible Resizes ：如果节点资源不够，resize 被标记为 PodResizePending: Infeasible，pod.spec 会永久保留那个不可达的请求值，Pod 一直以原始资源运行，HPA 的计算永久失真，而且没有任何告警。

社区已提交修复 PR #142157，方案是让 ReplicaCalculator 改为从 pod.status 读取已生效的资源容量。这个 PR 被标记了 /kind bug------说明官方已经把它当作一个正式的 bug 来处理。⚠️ 需要注意的是，PR #142157 的修复依赖于 features.InPlacePodVerticalScaling feature gate ------如果你的集群没有启用 In-Place Pod Vertical Scaling，这个修复不会生效，上面描述的失真问题也不会出现（因为没有原地扩缩容）。截至本文写作时，该 PR 仍处于开放状态，尚未合并 ，生产环境不要依赖这个"修复"已生效。生产环境同时启用 HPA 和 VPA 的话，建议先给 VPA 设 updateMode: "Off" 只做推荐，观察一段时间再决定是否放行。

💡 用 averageValue 替代 averageUtilization，绕开 requests 依赖 。averageUtilization 的语义是"所有相关 Pod 的资源指标均值，表示为 Pod 资源请求值的百分比"，仅对 Resource 指标源类型有效 ；而 averageValue 的语义是"所有相关 Pod 的指标均值的目标值（数量）"，在 Resource 和 External/Pods 指标源下都可以使用。区别在于：averageUtilization 依赖 requests 配得准不准，averageValue 直接用绝对值做目标，不依赖 requests。比如你设 averageValue: 500Mi，意思就是每个 Pod 平均内存用量超过 500Mi 就扩容。

有一个容易混淆的细节：对 Resource 类型， averageValue 的分母与 averageUtilization 一样，都是 Pod 数量，区别仅在于目标值的表示方式 ------前者是绝对数值（如 500Mi），后者是 requests 的百分比。换句话说，averageValue: 500Mi 和 averageUtilization: 50（当 requests.memory 为 1Gi 时）是等价的，只是前者不依赖 requests 的配置。

但要注意 averageValue 在不同指标类型下的分母行为有差异 ：对 Resource 类型，分母是 Pod 数量；对 External 类型，分母同样是 HPA 当前管理的 Pod 数量 。如果 HPA 管理的 Pod 数量为 0 （比如 Deployment 的 replicas 被手动设为 0），External 类型的 AverageValue 会无法计算，HPA 状态会显示 <unknown>------这是一个容易被忽略的边界情况。

还有一个细节：HPA 状态中显示的 current value 可能包含非 Running 状态的 Pod，但推荐计算时只使用 Running Pod 作为分母 。Issue #118273 记录了这个差异------一个 HPA 因为 84 个 Pod 处于 OutOfpods 状态（即 Pod 调度失败，无法分配到节点），导致 kubectl describe 显示的 current value 与实际推荐计算使用的值不一致（9094764 / (47 + 84) = 69425）。OutOfpods 状态的 Pod 不会被计入推荐计算的分母，但会被计入状态显示的分母。该 Issue 目前仍处于开放状态，这个显示差异在当前版本中仍然存在，排查时需注意。如果你在用 VPA 做 requests 推荐，HPA 用 averageValue 可以大幅降低两者冲突的概率。

📌 Prometheus Adapter 最小配置示例。如果你的服务是消息队列消费者，队列长度比 CPU 更能反映真实负载。下面是 Adapter 侧的最小可用 rule 配置。

⚠️ 以下示例基于 GOV.UK 的生产环境实践做了简化 ------GOV.UK 原始配置中 name.as 为 ai_sidekiq_queue_backlog，此处简化为 my_queue_backlog 便于理解。如果你要对照 GOV.UK 的原始文档，请以其官方命名为准。

bash 复制代码

# Adapter 侧 rule 配置（简化示例）
# 注意：此处使用简化命名 my_queue_backlog，与 GOV.UK 原始命名 ai_sidekiq_queue_backlog 不同
rules:
- seriesQuery: 'sidekiq_queue_backlog{job="my-worker"}'
  name:
    as: "my_queue_backlog"   # 原始配置为 ai_sidekiq_queue_backlog
  resources:
    overrides:
      namespace: {resource: "namespace"}
  metricsQuery: 'max(sidekiq_queue_backlog{job="my-worker"})'

配好 Adapter 之后，HPA 侧改成这样：

bash 复制代码

metrics:
- type: External
  external:
    metric:
      name: my_queue_backlog    # 必须与 Adapter 的 name.as 完全一致
    target:
      type: AverageValue
      averageValue: "10"        # 每个 Pod 平均积压超过 10 条就扩容

⚠️ 两个最常见的配置错误 ：一是 Adapter 侧 name.as 与 HPA 侧 metric.name 不一致 ，差一个字符都会导致 FailedGetExternalMetric；二是 averageValue 的语义理解偏差 ------averageValue: "10" 在 External 类型下的意思是"HPA 管理的所有 Pod 平均队列积压值超过 10"，不是"总积压超过 10"。如果 HPA 匹配到 5 个 Pod，每个 Pod 平均积压 3 条，总积压 15 条，但平均值是 3，不会触发扩容。如果你想要的是"总积压超过某个值就扩容"，应该改用 type: Value。

总结

一句话：HPA 的核心就三件事------requests 配准确、behavior 调合理、metrics 链路通畅。

HPA 的 CPU 利用率基于 requests 计算，不是 limits，requests 没配 HPA 直接不工作
K8s 1.23+ 用 behavior 替代全局参数控制扩缩速度；selectPolicy 默认值是 Max，缩容不显式写 Min 会缩得比预期快
容差特性 1.33 Alpha（需启用 feature gate）、1.35 Beta 默认启用、1.37 Stable，以 KEP-4951 官方记录为准（PR #5564 提交时 stable 字段还是 TBD，latest-milestone 为 v1.35 表示当前正在推进 Beta 阶段；官方 API 参考文档中该字段注释可能仍标注 alpha，以 feature gate 实际状态为准）；HPA 同步周期默认 15 秒，metrics-server 采集约 60 秒一次，扩容"慢"通常不是 HPA 参数的问题
多指标场景取最大期望副本数，每个指标的 requests 都要配合理
HPA + VPA 同时用要警惕 PodResizePending: Infeasible 导致的永久失真；社区已提交修复 PR #142157（标记为 /kind bug），截至本文写作时仍处于开放状态，尚未合并 ，且其修复依赖于 features.InPlacePodVerticalScaling feature gate，生产环境不要依赖这个"修复"已生效
用 averageValue 替代 averageUtilization 可以降低 HPA/VPA 冲突概率------对 Resource 类型，两者分母相同（都是 Pod 数量），区别仅在于目标值表示方式；但要注意 External 类型下 Pod 数量为 0 时无法计算，以及 HPA 状态显示可能包含 OutOfpods 等非 Running 状态的 Pod（Issue #118273 仍处于开放状态），而推荐计算只使用 Running Pod
用 Prometheus Adapter 做外部指标时，Adapter 侧 name.as 与 HPA 侧 metric.name 必须完全一致 ，否则直接报 FailedGetExternalMetric
metrics-server 的 --disable-http2-serving=true 解决的是服务端 http2 连接复用问题（metrics-server v0.8.0+ 支持），不覆盖 metrics-server 作为客户端连接 kubelet 的链路

你们线上 HPA 的 targetUtilization 一般设多少？缩容窗口设了多久？欢迎在评论区聊聊你的调参经验。觉得有用的话，转发给团队里正在跟 HPA 斗争的同学------这份配置模板可以直接拿去用。