HPA 这个词只要搞过 Kubernetes 生产环境的人基本都绕不过去。刚开始用的时候我以为它就是一段 YAML 加上一个 metrics-server 的事直到线上流量突然翻倍Pod 却迟迟不扩容我才真正意识到不了解 HPA 内部的原理你根本没法在关键时刻相信它。这次就把我对 Kubernetes Horizontal Pod Autoscaler简称 HPA的原理理解完整拆一遍从它为什么存在、怎样工作、怎样配置到生产环境里那些坑和排查方法全部说透。内容偏实操但原理部分也不跳过适合已经把 Kubernetes 跑起来、正在琢磨怎么让业务自动伸缩的人。1. HPA 是什么从为什么需要自动伸缩讲起1.1 手动扩容的困局刚接触 Kubernetes 时我们服务的副本数基本靠人肉调整。业务上线前评估一下峰值给 Deployment 写死一个固定的 replicas。问题是互联网业务的流量曲线根本猜不准白天和晚上不一样活动日和普通日不一样有时候上游一个服务抖动流量瞬间就上来了。扩容靠值班同学盯监控看到 CPU 涨到 80% 再手动执行kubectl scale deployment my-app --replicas10反应慢不说容易扩过头把集群资源打满然后又要手动缩容。遇到深夜突发流量等跑到电脑前操作的时候用户已经开始报错了。这种局面下HPA 解决的不只是自动而是把伸缩这件事变得可预期、可管理。它根据观察到的负载指标持续计算一个期望副本数然后通过 Kubernetes 控制面自动修改 Deployment、StatefulSet 这类工作负载的副本数。你不需要人为盯着监控也不需要提前精确预估容量只需要告诉它按 70% 的 CPU 利用率来扩缩剩下的事它自己循环去做。1.2 HPA 的核心目标与基本概念HPA 的全称是 Horizontal Pod Autoscaler水平 Pod 自动扩缩器。它的作用方向是横向扩容也就是增加 Pod 的副本数量而不是给单个 Pod 增加 CPU 或内存这种垂直扩容。水平扩展的核心理念是把无状态服务的负载分摊到多个副本上副本多了每个副本分到的流量就小响应速度就上去。HPA 本身是 Kubernetes 控制器的一部分就像 Deployment 控制器管理 ReplicaSetHPA 控制器也拥有自己的控制循环。它通过 API Server 读取你配置的伸缩规则定期地获取 Pod 的度量数据按照固定算法算出一个目标副本数再把结果写回到工作负载的scale子资源上。整套机制里你只需要关心几个概念scaleTargetRef要伸缩的目标负载比如指向一个 Deployment。metrics伸缩依据的指标数组可以是资源指标CPU、内存也可以是自定义指标。minReplicas和maxReplicas副本数的下限和上限防止伸缩到失控。behavior可选配置用来控制扩容和缩容的具体行为策略。明白了这几个词你已经理解了 HPA 大半。接下来真正重要的部分在于它到底靠什么数据、按什么公式来决策。2. HPA 的工作机制拆解从指标采集到副本调整2.1 控制循环Reconciliation LoopKubernetes 里的控制器基本都是期望状态驱动。HPA 控制器每隔一段时间默认通过--horizontal-pod-autoscaler-sync-period控制通常是 15 秒就会执行一次调和循环。这个循环做的事情可以拆成四步获取目标工作负载的当前副本数以及它声明的资源请求。获取所有 Pod 上绑定的监控指标。代入算法计算出期望副本数。如果期望副本数和当前副本数不一致就通过scale子资源更新副本数。这四步看起来简单但每一步都有干扰项。比如 Pod 还没 Ready指标就可能是 0比如某个 Pod 被驱逐了它的历史指标残留还会影响计算又比如指标数据延迟了几分钟那扩缩决策就基于旧数据。生产环境里 HPA 表现得迟钝多半就是这些环节的延迟叠加的效果。调和的本质是比较现状和期望驱向期望。它不像事件驱动系统那样来了一个请求就立刻触发扩容而是一个采样-计算的周期过程。所以在设计 HPA 时你需要接受一个事实它是离散反馈控制不是实时响应系统。流量瞬间飙升时通常会有数十秒到几分钟的滞后这一部分依赖 Pod 启动速度和指标聚合速度。2.2 指标来源与 Metrics Server要算期望副本数必须有指标输入。Kubernetes 1.8 之前HPA 只能读 CPU指标来源是 Heapster。现在主流的指标源有两类资源指标通过 Metrics Server 提供它从 kubelet 上的 Summary API 采集每个容器的 CPU 和内存使用量然后聚合成 Pod 级别的指标。自定义指标通过 Metrics API 兼容的适配器提供比如 Prometheus Adapter、外部指标AWS CloudWatch、Google Cloud Monitoring等。Metrics Server 本身也是运行在集群里的一个 Deployment它每隔一定时间默认 15 秒到 1 分钟通过 kubelet 抓取数据然后缓存在内存里。HPA 控制器调用的是metrics.k8s.io/v1beta1这个 API如果你集群里没装 Metrics Server执行kubectl get hpa时指标会显示unknownHPA 也就无法工作。这里有很关键的一个点CPU 利用率指标用的是使用量除以请求值而不是节点的物理 CPU 总量。举例来说一个 Pod 声明了requests.cpu500m当前实际用了 250m那么它的 util 就是 50%。这个请求值就是整个 HPA 计算逻辑的锚点后面还会详细说。至于自定义指标它走两种 APIcustom.metrics.k8s.io和external.metrics.k8s.io。前者通常与 Pod 对象直接绑定比如根据 Pod 每秒请求数 QPS 扩容后者不绑定 Pod比如根据队列积压消息数来扩容。适配器本质就是一组 APIService把外部监控数据的查询结果翻译成 Kubernetes API 对象。2.3 算法期望副本数计算与速率限制HPA 官方文档给了一套很直白的计算公式desiredReplicas ceil[ currentReplicas * ( currentMetricValue / desiredMetricValue ) ]举个例子当前副本数是 4当前 CPU 实际平均利用率是 95%目标利用率是 50%那么期望值就是ceil(4 * 95 / 50) ceil(7.6) 8。如果当前平均利用率是 20%那就是ceil(4 * 20 / 50) ceil(1.6) 2。注意它不会小于minReplicas也不会大于maxReplicas。但公式只是基础真正的控制器还内置了几条限速规则来防止震荡扩容速率默认情况下扩容最多每 15 秒增加一倍副本数通过--horizontal-pod-autoscaler-tolerance和--horizontal-pod-autoscaler-upscale-delay等参数控制。也就是说即使计算出来需要从 4 个变 100 个第一次只会加到 8 个下一次循环再加到 16 个。缩容速率缩容更保守默认 Pod 数量下降的速度由--horizontal-pod-autoscaler-downscale-stabilization控制默认 5 分钟。意味着就算当前指标显示只需要 2 个副本控制器也要观察 5 分钟确认不是瞬时抖动后才允许缩。容忍度如果currentMetricValue / desiredMetricValue在 1.0 左右的容忍区间内默认 0.1即 90%~110%HPA 不会调整副本数。这个容差避免了频繁微调。理解了这些限速规则你就能解释很多现象。比如某次大促扩容很慢不是因为 HPA 坏了而是它每一轮最多只能翻倍逻辑上可能要经过 3~4 轮每轮间隔 15 秒叠加指标采集延迟实际扩容成功可能要 1 分钟以上。反过来流量下来之后缩容要等 5 分钟这也是稳定策略防止副本数像心电图一样上下乱跳。3. 核心配置与实操示例3.1 配置清单关键字段HPA 在 Kubernetes 里是一个资源对象最常用的 API 版本是autoscaling/v2Kubernetes 1.23 稳定可用。一个最典型的 YAML 长这样apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 behavior: scaleUp: stabilizationWindowSeconds: 0 policies: - type: Percent value: 100 periodSeconds: 15 scaleDown: stabilizationWindowSeconds: 300 policies: - type: Pods value: 1 periodSeconds: 60字段没什么难度但要说明一点minReplicas和maxReplicas不只是数字它们也是保护边界。min 设 1 的风险在于如果某个节点故障导致 Pod 重建一个孤零零的副本在重新调度前可能等于没有max 设太高则可能把整个集群资源耗尽所以需要结合集群容量评估。metrics数组里可以写多个指标。HPA 会分别计算每个指标的期望副本数然后取最大值作为最终副本数。比如 CPU 期望 8 个内存期望 12 个那就按 12 个来。这种多指标模式适合那些 CPU 不高但内存吃紧的应用。3.2 示例基于 CPU 的 HPA下面是我在本地环境实际验证过的一段操作过程直接照着做就行。第一步确认集群里已经装了 Metrics Serverkubectl get deployment metrics-server -n kube-system如果没有就用官方 YAML 装一下。第二步准备一个测试 Deployment记得一定要给容器写resources.requests。没有请求值HPA 根本没法算利用率apiVersion: apps/v1 kind: Deployment metadata: name: cpu-demo spec: replicas: 1 selector: matchLabels: app: cpu-demo template: metadata: labels: app: cpu-demo spec: containers: - name: main image: myapp:v1 resources: requests: cpu: 200m第三步创建 HPAkubectl apply -f hpa-cpu.yaml然后查看状态kubectl get hpa cpu-demo如果一切正常输出里TARGETS列会显示类似10%/60%。10%是当前所有 Pod 的 CPU 利用率平均值60%是你设定的目标。想要验证扩容就用一个压测工具对应用制造 CPU 压力过一会儿你会看到副本数开始上涨。这里有个操作细节本地压测时如果负载比较小其实很难撑过容忍度区间。比如目标 60%当前已经 55%按公式计算1 * 55/60 0.9接近 1.0HPA 会选择不动。如果你想快速看到效果可以把目标值设低一点比如averageUtilization: 30。3.3 示例自定义指标Prometheus adapter要说生产环境最有用的 HPA 玩法还得是自定义指标。常见的套路是用 Prometheus 抓取应用指标再部署一个 prometheus-adapter让它把 Prometheus 查询结果暴露成custom.metrics.k8s.io接口。适配器的核心是一个ConfigMap里面写规则。例如想根据 HTTP 请求 QPS 扩容可以配置一个 series 查询rules: - seriesQuery: http_requests_total{namespace!,pod!} resources: overrides: namespace: { resource: namespace } pod: { resource: pod } name: matches: http_requests_total as: http_requests_per_second metricsQuery: sum(rate(http_requests_total{.LabelMatchers}[2m])) by (.GroupBy)然后 HPA 的 metrics 字段写成metrics: - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: 100type: Pods表示指标是按 Pod 聚合的averageValue: 100表示每个 Pod 的平均 QPS 目标为 100。如果当前每个 Pod 达到 300 QPS副本数就会相应增加。这个方案成熟但排查起来也要注意适配器查询的速度和 Prometheus 的 step 对齐问题很容易踩。适配器默认会把 query 包装成last 6 minutes的区间并取最大值所以你的rate函数窗口如果太短可能取不到平滑数据导致指标忽高忽低。3.4 配置项细节behavior、scaleTargetRef、metricsbehavior是配置扩缩容策略最重要的入口。它里面有scaleUp和scaleDown两个部分各有stabilizationWindowSeconds稳定窗口、selectPolicy多策略选择方式和policies策略列表。policies支持两种类型Pods允许改变的副本数和Percent允许改变副本数的百分比。每个策略还有个periodSeconds表示在窗口内生效的时长。比如behavior: scaleUp: policies: - type: Percent value: 100 periodSeconds: 15这条规则的意思是每 15 秒最多允许扩大 100%也就是翻倍。如果你还想限制单次最多加 4 个可以在 policies 里再加一条Pods类型然后selectPolicy: Min让控制器取两条策略计算结果里更小的那个。在生产环境我建议把缩容的stabilizationWindowSeconds调大一些比如 600 秒甚至 900 秒尤其是在下游有任务队列或者数据库连接池的场景。缩容太快会导致正在处理的请求被掐断慢一点更安全。对于扩容稳定窗口则通常设 0因为业务流量上升时每一秒都值钱。4. 生产环境注意事项与常见坑4.1 为什么抖动稳定窗口与冷却时间我踩过最经典一个坑某个服务流量在一天内有几个持续半小时的高峰HPA 设置了基于 QPS 的扩容目标结果高峰一到副本数猛涨高峰一过副本数又开始降。由于 Pod 启动比较慢业务压力又上来了于是反复横跳8 个变 16 个16 个又降回 8 个。每次缩容需要等 Pod Terminating期间新请求仍然会路由过来导致 Pod 数量长时间处于高位震荡而不是稳定在峰值。后来我调大了scaleDown.stabilizationWindowSeconds到 900 秒同时把缩容策略从Percent改成一次最多缩 1 个 Pod。这样即使指标瞬间降下来缩容也是一步一步走的给了负载评估足够的时间基本不再震荡。另外要注意缩容还有一个默认的--horizontal-pod-autoscaler-downscale-delay参数默认 5 分钟这是在你设置了稳定窗口之前就有的保护。所以不要以为稳定窗口设小就一定会立刻缩还要看控制平面参数。4.2 资源请求值HPA 的分母基于 CPU 或内存的 HPA分母永远是resources.requests不是节点容量也不是容器 limit。这是一个很容易被新同学忽略的细节。假设一个 Pod 的requests.cpu11000m但limits.cpu4实际它用了 2 核。按 HPA 的 CPU 利用率算法它是2000m / 1000m 200%。如果目标利用率 60%那期望副本数会很高。很多人觉得我明明设置 limits4为什么 2 核也算 200%因为你设的请求值是 1HPA 内部只看 utilisation 比值。所以一个重要的调优经验是不要随意把 requests 设得远低于业务实际使用量。如果经过压测发现服务的平均 CPU 使用就是 800m那 requests 最好设置在 800m 左右。设低虽然可以压缩资源占用但会让 HPA 反应过于激进导致副本数浮动大。理论上你甚至可以把 requests 设得高于实际使用量来稀释 HPA 的扩容量但这违背了资源调度的初衷一般不建议。合理做法是定期根据监控数据重新校准 requests。4.3 readinessProbe 与就绪、毛刺HPA 扩容后新增的 Pod 什么时候开始接收流量取决于 readinessProbe。这个探针如果配置不合理可能出现两种情况一种是新 Pod 明明可以接收流量但探针太严格导致它一直 NotReadyHPA 检测到指标没变化新 Pod 无流量继续再扩一批另一种是探针太宽松新 Pod 还没初始化好就进 Service 后端把个别请求打挂造成指标平均线异常偏低或偏高。这里面还有一层更隐性的问题HPA 计算指标平均值时只统计已就绪 Pod吗实际上指标来源是所有的目标 Pod而就绪状态会影响流量分配但并不直接过滤指标数据。如果你新扩容的 Pod 还没就绪它们可能没有业务指标上报导致平均指标被拉低这会影响 HPA 的判断方向。比如 CPU 平均使用率因为新加了很多空载 Pod 从 90% 降到 40%而实际老 Pod 仍然高负载HPA 可能会误判为不需要扩容。这种毛刺问题在自定义指标里尤其常见。解决思路是确保 Pod 启动阶段能够上报一个保守初始值或者让适配器在聚合时只统计就绪 Pod。但前者依赖应用配合后者需要自定义 adapter 的规则。对于绝大多数团队我更推荐在业务入口的监控埋点上下功夫把 QPS、延迟这类业务指标作为 HPA 依据比单纯看 CPU 更贴合实际。4.4 自定义指标排查技巧自定义 HPA 出现问题第一件事永远是确认 API 有没有返回数据。执行kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1 | jq如果这个接口都没有注册对应的资源名就需要检查 adapter 的 Deployment 是否正常。接下来针对具体指标查询kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/http_requests_per_second | jq这一步能直接看到适配器返回的每个 Pod 的指标值和时间戳。如果返回[]空列表说明 Prometheus 里没有数据如果返回的数据里有 NaN说明计算规则里出现了除零如果时间戳不是最近说明采集有延迟。还有个容易被忽视的坑是metricName的大小写规范。adapter 的规则中as字段定义的名字通常会被转换成符合 Kubernetes API 要求的格式比如连字符会被转换成下划线。如果你的 HPA 里写的 name 和 adapter 暴露出来的名字不一致HPA 会报unable to fetch metrics from ...但 Prometheus 本身监控一切正常很容易让人怀疑 adapter 版本问题。5. 从 v1 到 v2演进与生态5.1 autoscaling/v1 vs v2早些年大家用的都是autoscaling/v1它只有一个字段只能设置 CPU 平均利用率apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler spec: scaleTargetRef: ... minReplicas: 1 maxReplicas: 10 targetCPUUtilizationPercentage: 80这个版本在 Kubernetes 1.6 引入简单但太死板不支持自定义指标也不支持多指标和缩放策略。到了 1.12 左右autoscaling/v2beta2出现后续稳定为autoscaling/v2增加了metrics、behavior等字段。现在的文档和示例基本都是 v2如果你的项目里还看到 v1 的 YAML建议迁移。v1 依然存在是为了兼容旧 API控制器的计算规则也相同但无法享受新特性。从 v1 到 v2 最大的变化不是语法而是伸缩策略从计算后立即生效变成了计算后还要受策略约束。v2 里你可以让 HPA 即使算出来需要缩 10 个实际也只每 5 分钟缩 1 个可以单独针对首次扩容做加速可以指定多策略取最大或最小。这些都大大提高了自动伸缩的可控性。5.2 多指标组合配置多个指标时HPA 对每个指标独立计算期望副本数然后取max。这个设计容易引起一个反直觉行为某指标由于瞬时毛刺被放大会直接影响最终结果。比如 CPU 正常需要 4 个副本但某个内存指标因为缓存命中率降低期望副本数算成了 20那 HPA 会直接将副本扩大到 20。过了一段时间缓存恢复又缩回来。这种按最大者的策略在某些组合下会造成资源浪费。应对方式可以借助behavior里的缩容稳定窗口削弱突变影响也可以在监控层面为每个指标设置合理的聚合方式。比如 Prometheus Adapter 里对指标可以使用maxValue、averageValue等聚合。更精细的办法是使用ContainerResource类型直接针对容器而不是 Pod 级别这在多容器 Pod 里很常见。多指标组合还有一个最佳实践不要把所有指标都设为硬性伸缩依据有的指标适合只作为观测不作为决策。HPA 目前没有weight概念没有主次指标权重的设计。如果你真的想让某指标优先建议拆分成多个 HPA 指向同一个 Deployment但要非常小心副本数冲突。实际上 Kubernetes 不允许两个 HPA 同时管理同一个负载所以常规做法还是把最核心的指标放进同一个 HPA 的 metrics 数组。5.3 与 Cluster Autoscaler 的配合HPA 负责调整应用副本数Cluster AutoscalerCA负责调整集群节点数。二者配合得好就是一套完整的弹性伸缩方案。典型流转路径是业务流量增长 → 指标涨 → HPA 计算期望副本数 → 副本数增加 → 新 Pod 调度时发现集群资源不足 → Pod Pending → CA 检测到有 Pod 无法调度 → CA 触发节点扩容 → 节点就绪 → Pod 调度成功 → 业务恢复。这整个过程看起来简单但涉及多个控制器的时间尺度HPA 每次 15 秒循环CA 每次 10 秒循环节点启动几十秒Pod 拉镜像几秒到几分钟。端到端延迟往往在数分钟级别。所以如果你的业务对扩容速度很敏感还需要叠加 PDB、preStop hooks 和节点池弹性策略。另一个常见问题是你给 HPA 设了maxReplicas: 20集群只有 3 个节点每个节点只能容纳 5 个 Pod但你没有装 CA那么 HPA 的扩容会停在 Pending 状态导致 Pod 一直无法启动。排查时要同时看 HPA 状态和 Pod 事件别只盯着kubectl get hpa的 REPLICAS 列。生产环境里我还建议把 CA 的扩容策略和 HPA 的 maxReplicas 联动起来。比如给不同应用设置不同的 nodeSelector 和 resource requests让突发扩容的 Pod 落在专用节点池避免和在线业务互相争抢。这些都是构架层面的取舍但 HPA 本身并不感知节点状态它只负责按指标改 replica功过都在这个边界之内。结尾一点个人的实操体会HPA 用了几年我最大的体会是它属于策略简单、实际复杂的组件。文档上写清楚公式但真正让它稳定工作靠的是对指标质量的控制和对缩扩容行为的约束。我现在上生产前一定会做一套扩容演练人为制造高负载观察 HPA 从发现指标变化到执行扩容的时间以及 Pod 从 Pending 到 Ready 的时间记录下来作为容量预案的一部分。这样上线后心里就有底知道最差的情况延迟是多少。最后再分享一个实用小技巧如果线上 HPA 出现了指标正常但不扩容的情况优先检查kubectl describe hpa里 Events 的内容它会直接给出FailedGetResourceMetric或unable to get metric类似的原因。大多数时候不是算法问题而是指标链路不通或资源请求值没配。先把这条链路打通再谈调优顺序别反过来。
HPA 这个词只要搞过 Kubernetes 生产环境的人基本都绕不过去。刚开始用的时候我以为它就是一段 YAML 加上一个 metrics-server 的事直到线上流量突然翻倍Pod 却迟迟不扩容我才真正意识到不了解 HPA 内部的原理你根本没法在关键时刻相信它。这次就把我对 Kubernetes Horizontal Pod Autoscaler简称 HPA的原理理解完整拆一遍从它为什么存在、怎样工作、怎样配置到生产环境里那些坑和排查方法全部说透。内容偏实操但原理部分也不跳过适合已经把 Kubernetes 跑起来、正在琢磨怎么让业务自动伸缩的人。1. HPA 是什么从为什么需要自动伸缩讲起1.1 手动扩容的困局刚接触 Kubernetes 时我们服务的副本数基本靠人肉调整。业务上线前评估一下峰值给 Deployment 写死一个固定的 replicas。问题是互联网业务的流量曲线根本猜不准白天和晚上不一样活动日和普通日不一样有时候上游一个服务抖动流量瞬间就上来了。扩容靠值班同学盯监控看到 CPU 涨到 80% 再手动执行kubectl scale deployment my-app --replicas10反应慢不说容易扩过头把集群资源打满然后又要手动缩容。遇到深夜突发流量等跑到电脑前操作的时候用户已经开始报错了。这种局面下HPA 解决的不只是自动而是把伸缩这件事变得可预期、可管理。它根据观察到的负载指标持续计算一个期望副本数然后通过 Kubernetes 控制面自动修改 Deployment、StatefulSet 这类工作负载的副本数。你不需要人为盯着监控也不需要提前精确预估容量只需要告诉它按 70% 的 CPU 利用率来扩缩剩下的事它自己循环去做。1.2 HPA 的核心目标与基本概念HPA 的全称是 Horizontal Pod Autoscaler水平 Pod 自动扩缩器。它的作用方向是横向扩容也就是增加 Pod 的副本数量而不是给单个 Pod 增加 CPU 或内存这种垂直扩容。水平扩展的核心理念是把无状态服务的负载分摊到多个副本上副本多了每个副本分到的流量就小响应速度就上去。HPA 本身是 Kubernetes 控制器的一部分就像 Deployment 控制器管理 ReplicaSetHPA 控制器也拥有自己的控制循环。它通过 API Server 读取你配置的伸缩规则定期地获取 Pod 的度量数据按照固定算法算出一个目标副本数再把结果写回到工作负载的scale子资源上。整套机制里你只需要关心几个概念scaleTargetRef要伸缩的目标负载比如指向一个 Deployment。metrics伸缩依据的指标数组可以是资源指标CPU、内存也可以是自定义指标。minReplicas和maxReplicas副本数的下限和上限防止伸缩到失控。behavior可选配置用来控制扩容和缩容的具体行为策略。明白了这几个词你已经理解了 HPA 大半。接下来真正重要的部分在于它到底靠什么数据、按什么公式来决策。2. HPA 的工作机制拆解从指标采集到副本调整2.1 控制循环Reconciliation LoopKubernetes 里的控制器基本都是期望状态驱动。HPA 控制器每隔一段时间默认通过--horizontal-pod-autoscaler-sync-period控制通常是 15 秒就会执行一次调和循环。这个循环做的事情可以拆成四步获取目标工作负载的当前副本数以及它声明的资源请求。获取所有 Pod 上绑定的监控指标。代入算法计算出期望副本数。如果期望副本数和当前副本数不一致就通过scale子资源更新副本数。这四步看起来简单但每一步都有干扰项。比如 Pod 还没 Ready指标就可能是 0比如某个 Pod 被驱逐了它的历史指标残留还会影响计算又比如指标数据延迟了几分钟那扩缩决策就基于旧数据。生产环境里 HPA 表现得迟钝多半就是这些环节的延迟叠加的效果。调和的本质是比较现状和期望驱向期望。它不像事件驱动系统那样来了一个请求就立刻触发扩容而是一个采样-计算的周期过程。所以在设计 HPA 时你需要接受一个事实它是离散反馈控制不是实时响应系统。流量瞬间飙升时通常会有数十秒到几分钟的滞后这一部分依赖 Pod 启动速度和指标聚合速度。2.2 指标来源与 Metrics Server要算期望副本数必须有指标输入。Kubernetes 1.8 之前HPA 只能读 CPU指标来源是 Heapster。现在主流的指标源有两类资源指标通过 Metrics Server 提供它从 kubelet 上的 Summary API 采集每个容器的 CPU 和内存使用量然后聚合成 Pod 级别的指标。自定义指标通过 Metrics API 兼容的适配器提供比如 Prometheus Adapter、外部指标AWS CloudWatch、Google Cloud Monitoring等。Metrics Server 本身也是运行在集群里的一个 Deployment它每隔一定时间默认 15 秒到 1 分钟通过 kubelet 抓取数据然后缓存在内存里。HPA 控制器调用的是metrics.k8s.io/v1beta1这个 API如果你集群里没装 Metrics Server执行kubectl get hpa时指标会显示unknownHPA 也就无法工作。这里有很关键的一个点CPU 利用率指标用的是使用量除以请求值而不是节点的物理 CPU 总量。举例来说一个 Pod 声明了requests.cpu500m当前实际用了 250m那么它的 util 就是 50%。这个请求值就是整个 HPA 计算逻辑的锚点后面还会详细说。至于自定义指标它走两种 APIcustom.metrics.k8s.io和external.metrics.k8s.io。前者通常与 Pod 对象直接绑定比如根据 Pod 每秒请求数 QPS 扩容后者不绑定 Pod比如根据队列积压消息数来扩容。适配器本质就是一组 APIService把外部监控数据的查询结果翻译成 Kubernetes API 对象。2.3 算法期望副本数计算与速率限制HPA 官方文档给了一套很直白的计算公式desiredReplicas ceil[ currentReplicas * ( currentMetricValue / desiredMetricValue ) ]举个例子当前副本数是 4当前 CPU 实际平均利用率是 95%目标利用率是 50%那么期望值就是ceil(4 * 95 / 50) ceil(7.6) 8。如果当前平均利用率是 20%那就是ceil(4 * 20 / 50) ceil(1.6) 2。注意它不会小于minReplicas也不会大于maxReplicas。但公式只是基础真正的控制器还内置了几条限速规则来防止震荡扩容速率默认情况下扩容最多每 15 秒增加一倍副本数通过--horizontal-pod-autoscaler-tolerance和--horizontal-pod-autoscaler-upscale-delay等参数控制。也就是说即使计算出来需要从 4 个变 100 个第一次只会加到 8 个下一次循环再加到 16 个。缩容速率缩容更保守默认 Pod 数量下降的速度由--horizontal-pod-autoscaler-downscale-stabilization控制默认 5 分钟。意味着就算当前指标显示只需要 2 个副本控制器也要观察 5 分钟确认不是瞬时抖动后才允许缩。容忍度如果currentMetricValue / desiredMetricValue在 1.0 左右的容忍区间内默认 0.1即 90%~110%HPA 不会调整副本数。这个容差避免了频繁微调。理解了这些限速规则你就能解释很多现象。比如某次大促扩容很慢不是因为 HPA 坏了而是它每一轮最多只能翻倍逻辑上可能要经过 3~4 轮每轮间隔 15 秒叠加指标采集延迟实际扩容成功可能要 1 分钟以上。反过来流量下来之后缩容要等 5 分钟这也是稳定策略防止副本数像心电图一样上下乱跳。3. 核心配置与实操示例3.1 配置清单关键字段HPA 在 Kubernetes 里是一个资源对象最常用的 API 版本是autoscaling/v2Kubernetes 1.23 稳定可用。一个最典型的 YAML 长这样apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 behavior: scaleUp: stabilizationWindowSeconds: 0 policies: - type: Percent value: 100 periodSeconds: 15 scaleDown: stabilizationWindowSeconds: 300 policies: - type: Pods value: 1 periodSeconds: 60字段没什么难度但要说明一点minReplicas和maxReplicas不只是数字它们也是保护边界。min 设 1 的风险在于如果某个节点故障导致 Pod 重建一个孤零零的副本在重新调度前可能等于没有max 设太高则可能把整个集群资源耗尽所以需要结合集群容量评估。metrics数组里可以写多个指标。HPA 会分别计算每个指标的期望副本数然后取最大值作为最终副本数。比如 CPU 期望 8 个内存期望 12 个那就按 12 个来。这种多指标模式适合那些 CPU 不高但内存吃紧的应用。3.2 示例基于 CPU 的 HPA下面是我在本地环境实际验证过的一段操作过程直接照着做就行。第一步确认集群里已经装了 Metrics Serverkubectl get deployment metrics-server -n kube-system如果没有就用官方 YAML 装一下。第二步准备一个测试 Deployment记得一定要给容器写resources.requests。没有请求值HPA 根本没法算利用率apiVersion: apps/v1 kind: Deployment metadata: name: cpu-demo spec: replicas: 1 selector: matchLabels: app: cpu-demo template: metadata: labels: app: cpu-demo spec: containers: - name: main image: myapp:v1 resources: requests: cpu: 200m第三步创建 HPAkubectl apply -f hpa-cpu.yaml然后查看状态kubectl get hpa cpu-demo如果一切正常输出里TARGETS列会显示类似10%/60%。10%是当前所有 Pod 的 CPU 利用率平均值60%是你设定的目标。想要验证扩容就用一个压测工具对应用制造 CPU 压力过一会儿你会看到副本数开始上涨。这里有个操作细节本地压测时如果负载比较小其实很难撑过容忍度区间。比如目标 60%当前已经 55%按公式计算1 * 55/60 0.9接近 1.0HPA 会选择不动。如果你想快速看到效果可以把目标值设低一点比如averageUtilization: 30。3.3 示例自定义指标Prometheus adapter要说生产环境最有用的 HPA 玩法还得是自定义指标。常见的套路是用 Prometheus 抓取应用指标再部署一个 prometheus-adapter让它把 Prometheus 查询结果暴露成custom.metrics.k8s.io接口。适配器的核心是一个ConfigMap里面写规则。例如想根据 HTTP 请求 QPS 扩容可以配置一个 series 查询rules: - seriesQuery: http_requests_total{namespace!,pod!} resources: overrides: namespace: { resource: namespace } pod: { resource: pod } name: matches: http_requests_total as: http_requests_per_second metricsQuery: sum(rate(http_requests_total{.LabelMatchers}[2m])) by (.GroupBy)然后 HPA 的 metrics 字段写成metrics: - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: 100type: Pods表示指标是按 Pod 聚合的averageValue: 100表示每个 Pod 的平均 QPS 目标为 100。如果当前每个 Pod 达到 300 QPS副本数就会相应增加。这个方案成熟但排查起来也要注意适配器查询的速度和 Prometheus 的 step 对齐问题很容易踩。适配器默认会把 query 包装成last 6 minutes的区间并取最大值所以你的rate函数窗口如果太短可能取不到平滑数据导致指标忽高忽低。3.4 配置项细节behavior、scaleTargetRef、metricsbehavior是配置扩缩容策略最重要的入口。它里面有scaleUp和scaleDown两个部分各有stabilizationWindowSeconds稳定窗口、selectPolicy多策略选择方式和policies策略列表。policies支持两种类型Pods允许改变的副本数和Percent允许改变副本数的百分比。每个策略还有个periodSeconds表示在窗口内生效的时长。比如behavior: scaleUp: policies: - type: Percent value: 100 periodSeconds: 15这条规则的意思是每 15 秒最多允许扩大 100%也就是翻倍。如果你还想限制单次最多加 4 个可以在 policies 里再加一条Pods类型然后selectPolicy: Min让控制器取两条策略计算结果里更小的那个。在生产环境我建议把缩容的stabilizationWindowSeconds调大一些比如 600 秒甚至 900 秒尤其是在下游有任务队列或者数据库连接池的场景。缩容太快会导致正在处理的请求被掐断慢一点更安全。对于扩容稳定窗口则通常设 0因为业务流量上升时每一秒都值钱。4. 生产环境注意事项与常见坑4.1 为什么抖动稳定窗口与冷却时间我踩过最经典一个坑某个服务流量在一天内有几个持续半小时的高峰HPA 设置了基于 QPS 的扩容目标结果高峰一到副本数猛涨高峰一过副本数又开始降。由于 Pod 启动比较慢业务压力又上来了于是反复横跳8 个变 16 个16 个又降回 8 个。每次缩容需要等 Pod Terminating期间新请求仍然会路由过来导致 Pod 数量长时间处于高位震荡而不是稳定在峰值。后来我调大了scaleDown.stabilizationWindowSeconds到 900 秒同时把缩容策略从Percent改成一次最多缩 1 个 Pod。这样即使指标瞬间降下来缩容也是一步一步走的给了负载评估足够的时间基本不再震荡。另外要注意缩容还有一个默认的--horizontal-pod-autoscaler-downscale-delay参数默认 5 分钟这是在你设置了稳定窗口之前就有的保护。所以不要以为稳定窗口设小就一定会立刻缩还要看控制平面参数。4.2 资源请求值HPA 的分母基于 CPU 或内存的 HPA分母永远是resources.requests不是节点容量也不是容器 limit。这是一个很容易被新同学忽略的细节。假设一个 Pod 的requests.cpu11000m但limits.cpu4实际它用了 2 核。按 HPA 的 CPU 利用率算法它是2000m / 1000m 200%。如果目标利用率 60%那期望副本数会很高。很多人觉得我明明设置 limits4为什么 2 核也算 200%因为你设的请求值是 1HPA 内部只看 utilisation 比值。所以一个重要的调优经验是不要随意把 requests 设得远低于业务实际使用量。如果经过压测发现服务的平均 CPU 使用就是 800m那 requests 最好设置在 800m 左右。设低虽然可以压缩资源占用但会让 HPA 反应过于激进导致副本数浮动大。理论上你甚至可以把 requests 设得高于实际使用量来稀释 HPA 的扩容量但这违背了资源调度的初衷一般不建议。合理做法是定期根据监控数据重新校准 requests。4.3 readinessProbe 与就绪、毛刺HPA 扩容后新增的 Pod 什么时候开始接收流量取决于 readinessProbe。这个探针如果配置不合理可能出现两种情况一种是新 Pod 明明可以接收流量但探针太严格导致它一直 NotReadyHPA 检测到指标没变化新 Pod 无流量继续再扩一批另一种是探针太宽松新 Pod 还没初始化好就进 Service 后端把个别请求打挂造成指标平均线异常偏低或偏高。这里面还有一层更隐性的问题HPA 计算指标平均值时只统计已就绪 Pod吗实际上指标来源是所有的目标 Pod而就绪状态会影响流量分配但并不直接过滤指标数据。如果你新扩容的 Pod 还没就绪它们可能没有业务指标上报导致平均指标被拉低这会影响 HPA 的判断方向。比如 CPU 平均使用率因为新加了很多空载 Pod 从 90% 降到 40%而实际老 Pod 仍然高负载HPA 可能会误判为不需要扩容。这种毛刺问题在自定义指标里尤其常见。解决思路是确保 Pod 启动阶段能够上报一个保守初始值或者让适配器在聚合时只统计就绪 Pod。但前者依赖应用配合后者需要自定义 adapter 的规则。对于绝大多数团队我更推荐在业务入口的监控埋点上下功夫把 QPS、延迟这类业务指标作为 HPA 依据比单纯看 CPU 更贴合实际。4.4 自定义指标排查技巧自定义 HPA 出现问题第一件事永远是确认 API 有没有返回数据。执行kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1 | jq如果这个接口都没有注册对应的资源名就需要检查 adapter 的 Deployment 是否正常。接下来针对具体指标查询kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/http_requests_per_second | jq这一步能直接看到适配器返回的每个 Pod 的指标值和时间戳。如果返回[]空列表说明 Prometheus 里没有数据如果返回的数据里有 NaN说明计算规则里出现了除零如果时间戳不是最近说明采集有延迟。还有个容易被忽视的坑是metricName的大小写规范。adapter 的规则中as字段定义的名字通常会被转换成符合 Kubernetes API 要求的格式比如连字符会被转换成下划线。如果你的 HPA 里写的 name 和 adapter 暴露出来的名字不一致HPA 会报unable to fetch metrics from ...但 Prometheus 本身监控一切正常很容易让人怀疑 adapter 版本问题。5. 从 v1 到 v2演进与生态5.1 autoscaling/v1 vs v2早些年大家用的都是autoscaling/v1它只有一个字段只能设置 CPU 平均利用率apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler spec: scaleTargetRef: ... minReplicas: 1 maxReplicas: 10 targetCPUUtilizationPercentage: 80这个版本在 Kubernetes 1.6 引入简单但太死板不支持自定义指标也不支持多指标和缩放策略。到了 1.12 左右autoscaling/v2beta2出现后续稳定为autoscaling/v2增加了metrics、behavior等字段。现在的文档和示例基本都是 v2如果你的项目里还看到 v1 的 YAML建议迁移。v1 依然存在是为了兼容旧 API控制器的计算规则也相同但无法享受新特性。从 v1 到 v2 最大的变化不是语法而是伸缩策略从计算后立即生效变成了计算后还要受策略约束。v2 里你可以让 HPA 即使算出来需要缩 10 个实际也只每 5 分钟缩 1 个可以单独针对首次扩容做加速可以指定多策略取最大或最小。这些都大大提高了自动伸缩的可控性。5.2 多指标组合配置多个指标时HPA 对每个指标独立计算期望副本数然后取max。这个设计容易引起一个反直觉行为某指标由于瞬时毛刺被放大会直接影响最终结果。比如 CPU 正常需要 4 个副本但某个内存指标因为缓存命中率降低期望副本数算成了 20那 HPA 会直接将副本扩大到 20。过了一段时间缓存恢复又缩回来。这种按最大者的策略在某些组合下会造成资源浪费。应对方式可以借助behavior里的缩容稳定窗口削弱突变影响也可以在监控层面为每个指标设置合理的聚合方式。比如 Prometheus Adapter 里对指标可以使用maxValue、averageValue等聚合。更精细的办法是使用ContainerResource类型直接针对容器而不是 Pod 级别这在多容器 Pod 里很常见。多指标组合还有一个最佳实践不要把所有指标都设为硬性伸缩依据有的指标适合只作为观测不作为决策。HPA 目前没有weight概念没有主次指标权重的设计。如果你真的想让某指标优先建议拆分成多个 HPA 指向同一个 Deployment但要非常小心副本数冲突。实际上 Kubernetes 不允许两个 HPA 同时管理同一个负载所以常规做法还是把最核心的指标放进同一个 HPA 的 metrics 数组。5.3 与 Cluster Autoscaler 的配合HPA 负责调整应用副本数Cluster AutoscalerCA负责调整集群节点数。二者配合得好就是一套完整的弹性伸缩方案。典型流转路径是业务流量增长 → 指标涨 → HPA 计算期望副本数 → 副本数增加 → 新 Pod 调度时发现集群资源不足 → Pod Pending → CA 检测到有 Pod 无法调度 → CA 触发节点扩容 → 节点就绪 → Pod 调度成功 → 业务恢复。这整个过程看起来简单但涉及多个控制器的时间尺度HPA 每次 15 秒循环CA 每次 10 秒循环节点启动几十秒Pod 拉镜像几秒到几分钟。端到端延迟往往在数分钟级别。所以如果你的业务对扩容速度很敏感还需要叠加 PDB、preStop hooks 和节点池弹性策略。另一个常见问题是你给 HPA 设了maxReplicas: 20集群只有 3 个节点每个节点只能容纳 5 个 Pod但你没有装 CA那么 HPA 的扩容会停在 Pending 状态导致 Pod 一直无法启动。排查时要同时看 HPA 状态和 Pod 事件别只盯着kubectl get hpa的 REPLICAS 列。生产环境里我还建议把 CA 的扩容策略和 HPA 的 maxReplicas 联动起来。比如给不同应用设置不同的 nodeSelector 和 resource requests让突发扩容的 Pod 落在专用节点池避免和在线业务互相争抢。这些都是构架层面的取舍但 HPA 本身并不感知节点状态它只负责按指标改 replica功过都在这个边界之内。结尾一点个人的实操体会HPA 用了几年我最大的体会是它属于策略简单、实际复杂的组件。文档上写清楚公式但真正让它稳定工作靠的是对指标质量的控制和对缩扩容行为的约束。我现在上生产前一定会做一套扩容演练人为制造高负载观察 HPA 从发现指标变化到执行扩容的时间以及 Pod 从 Pending 到 Ready 的时间记录下来作为容量预案的一部分。这样上线后心里就有底知道最差的情况延迟是多少。最后再分享一个实用小技巧如果线上 HPA 出现了指标正常但不扩容的情况优先检查kubectl describe hpa里 Events 的内容它会直接给出FailedGetResourceMetric或unable to get metric类似的原因。大多数时候不是算法问题而是指标链路不通或资源请求值没配。先把这条链路打通再谈调优顺序别反过来。
