这两年只要跟Kubernetes沾边的团队几乎都会聊到弹性伸缩。我这些年在一线折腾过不少集群从最早以为加个 HPA 就万事大吉到后来被线上抖动、扩容滞后和成本账单来回折磨才算是把这一整套机制吃透。Kubernetes弹性伸缩实际上不是某一个独立功能而是三件事的组合Pod 级别的水平扩缩容HPA、Pod 资源规格的垂直调整VPA、以及集群节点容量的自动增删Cluster Autoscaler。这三件事各自解决不同层面的问题又互相咬合少看一眼都会在线上吃亏。这篇文章我就把自己的理解和实操经验完整梳理一遍适合刚准备上伸缩的团队也适合已经被 HPA 折磨过的运维同学对照排坑。1. 为什么我劝每个 K8s 运维都早点把弹性伸缩搞明白1.1 弹性伸缩到底解决什么痛点先看一个最常见的场景。某公司的业务服务白天上班时间 QPS 能冲到几千晚上可能只有几百月初月末有报表类任务流量又是另一副模样。如果按峰值固定部署 20 个副本那凌晨 3 点大部分副本的 CPU 利用率只有百分之几钱全花在空转上如果按低峰固定部署 5 个副本白天流量稍微起来接口延迟就飙升用户开始投诉运维收到一堆告警。这是所有固定容量方案的通病流量是波动的资源是静态的中间永远匹配不上。弹性伸缩存在的意义就是让副本数量和实际负载动态匹配。负载上来系统自动加副本负载下去系统自动收副本。收益分两头业务侧高峰期不会因为容量不够而故障成本侧低峰期不会因为过度预留而烧钱。很多团队优化代码抠那点性能收益花了大力气省下的成本可能还不如一次合理的缩容策略来得明显。但很多人对弹性伸缩的理解停留在“加个 HPA”。实际落地时你会发现HPA 只管 Deployment 有多少个 PodPod 能不能调度到节点还取决于节点容量节点不够的时候需要 Cluster Autoscaler 去加机器。一层接一层任何一个环节掉链子整个伸缩链路都不通。所以统一的思路应该是先搭容量底座再配工作负载伸缩策略最后用指标去联动而不是上来就抄一份 YAML。1.2 三种伸缩机制的分工机制作用层级调整对象典型依据生效节奏HPA工作负载层Deployment、StatefulSet 的副本数CPU、内存、自定义指标秒到分钟级VPAPod 规格层每个 Pod 的 requests 和 limits历史资源使用、当前指标分钟到小时级调整时需重建 PodCluster Autoscaler基础设施层节点池里的节点数量是否存在无法调度的 Pod分钟级取决于节点池扩容速度这三者的关系像一个自下而上的链路HPA 把副本数往上调新 Pod 创建出来但如果没有足够的节点资源Pod 就会一直停留在 Pending 状态这时 Cluster Autoscaler 发现集群里有调度不上去的 Pod于是去节点池里加机器机器就绪后 Pod 完成调度扩容才真正闭环。反过来负载下降后 HPA 把副本数降下来节点利用率低到一定程度Cluster Autoscaler 再把多余的机器回收。一个容易踩的理解误区是HPA 和 VPA 不要同时启用。HPA 在调副本数VPA 在改每个 Pod 的 requests两个变量互相干扰谁也不知道该听谁的。我见过一个团队同时上了这两个组件结果副本数像心电图一样上下乱跳最后排查了半天才发现是两套机制在打架。2. HPA 背后的原理和关键指标2.1 HPA 怎么决定扩不扩HPA 的决策逻辑其实就一条公式期望副本数 ceil(当前副本数 × 当前指标值 / 期望指标值)。举个例子一个 Deployment 当前 10 个副本HPA 目标是 CPU 平均利用率 50%现在实际平均值到了 70%那么期望副本数 ceil(10 × 70 / 50) 14。因为当前副本的 CPU 要降到 50%按比例就得扩到 14 个才够。这里有两个隐藏的细节。第一个是容差tolerance默认值是 0.1。也就是说只有当当前指标和目标指标的比值超过 1.1 或者低于 0.9 的时候HPA 才会动手10% 以内的波动会被忽略。这个设计是为了避免副本数在微小的网络抖动上来回跳。第二个是同步周期默认是 15 秒。HPA 控制器每隔 15 秒拉取一次指标、算一次期望副本数并决定是否调整所以你不要指望它能在一秒内响应突发流量。HPA 拿到的指标从哪来关键 API 有三个metrics.k8s.io资源指标比如 CPU 和内存由 Metrics Server 提供、custom.metrics.k8s.io自定义指标比如 QPS、队列长度一般由监控系统适配器提供、external.metrics.k8s.io外部指标比如消息队列的积压量。HPA 通过 API 发现机制找到这些 API再按指标名取值。日常最常用的是第一类因为装上 Metrics Server 就能用零成本起步。2.2 度量指标怎么选选指标是弹性伸缩成败的关键比选 YAML 字段重要得多。CPU 指标最好理解但有个前提应用进程必须是 CPU 密集型的。纯计算型服务用 CPU 做扩缩依据很准但一个 IO 等待严重、线程卡在网络上的服务CPU 平均值可能一直很低流量却已经很高了这时候指望 CPU 扩容就是刻舟求剑。内存指标要小心。很多语言的运行时内存占用是锯齿状的GC 之后又回落如果只盯着内存利用率去扩缩很容易出现“刚扩容又缩容”的抖动。内存更适合用来做兜底比如设一个比较高的目标值比如 80%防止某次异常导致 OOM而不是用来精确跟随流量。自定义指标才是控制业务体验的正道。典型例子网关入口的 QPS、队列长度、P99 延迟。这类指标能直接反映用户感受。实现上一般要把业务指标暴露出来通过监控系统采集再用适配器把指标暴露成 custom.metrics.k8s.io 里的数据最后在 HPA 里引用。我在第二次落地 HPA 的时候基本都会优先上 QPS 或请求延迟准确率比纯 CPU 高一大截。指标类型也需要区分Pod 类型指标是每个 Pod 单独取值再求平均值适合 CPU、内存这种按 Pod 分摊的Object 类型指标是服务对象整体聚合出的一个值适合网关总 QPS 这类整体值。类型用错目标值的语义就错了扩缩逻辑会变得非常奇怪。2.3 参数怎么配才科学minReplicas 不要为了省钱设成 1。业务 Pod 至少要冗余到可用区数量乘以单区副本数比如跨 3 个可用区每个区至少 1 个副本那 minReplicas 至少是 3。另外要考虑滚动更新Deployment 滚动时新老副本共存minReplicas 太小更新过程会让可用副本瞬间不足。maxReplicas 不要拍脑袋写 100。上限要结合下游容量、中间件连接数、数据库连接数来定。我见过一个团队把 maxReplicas 设得很大副本倒是起来了结果把下游数据库的连接池打满整个链路雪崩。容量规划里副本上限应该是下游压测出来的安全值而不是随意填的数字。targetAverageUtilization 不建议设太高也不建议设太低。设成 90%看起来省资源但从触发扩容到新 Pod ready 需要一小段时间这个窗口里 CPU 持续高位新 Pod 还没就绪老 Pod 已经扛不住了。我一般建议在 50% 到 70% 之间留足缓冲。有些团队对成本极端敏感用 80%但前提是扩容链路足够快否则就是拿稳定性换账单。behavior 字段很多人不知道其实是整个伸缩策略的油门和刹车。默认情况下扩容阶段没有稳定窗口缩容阶段有 300 秒稳定窗口。生产环境我习惯把扩容的稳定窗口设置成 0保证判定后立刻执行同时加一条策略允许一次最多扩 100%每 60 秒一次这样突发流量能在几个周期内快速拉起缩容则保留 300 到 600 秒稳定窗口每次最多缩 1 个 Pod防止低峰期副本数过山车。3. VPA 与集群级伸缩的适用场景3.1 VPA 什么时候用VPA 的全称是 Vertical Pod Autoscaler它不调整副本数而是调整每个 Pod 的 requests 和 limits相当于给每个 Pod“换个尺寸”。适合什么场景无状态服务大多能用 HPA 水平扩缩但有些有状态服务不好水平扩比如数据分片固定、每个副本处理固定分片的数据还有些老应用启动慢、水平扩容代价太大。这时候让 VPA 根据实际用量把 Pod 的 requests 抬高或降低比硬改成 HPA 现实得多。VPA 有三种运行模式Off 模式只出建议不执行Initial 模式只在 Pod 创建时应用一次Auto 或 Recreate 模式动态调整并重建 Pod。生产环境最稳妥的是先跑 Off 模式观察一段时间用建议值手动调整 requests确认模型稳定之后再切 Auto。一上来就 Auto 的风险在于VPA 可能因为某个短时峰值把 requests 调得过高导致集群资源被浪费Pod 反而排不上。这里再强调一遍为什么 HPA 和 VPA 不要同时用在同一 Deployment 上HPA 在按 CPU 目标调整副本数VPA 又在按 CPU 实际使用调整 requests两者都在改同一个链条上的变量。CPU 利用率等于实际使用除以 requests这个分数的分母被你改来改去HPA 算出来的期望副本数必然来回漂移。如果非要同时用通常做法是把 VPA 设为 Off只用它的建议来人工校准 requestsHPA 单独控制副本数。3.2 Cluster Autoscaler 的节奏Cluster Autoscaler以下简称 CA解决的是节点级容量问题。它盯着集群里有没有 Pending 的 Pod一旦有 Pod 因为节点资源不足而调度不上去CA 就自动往节点池里加机器反过来节点长时间低利用率且上面的 Pod 都能被调度到别处CA 就把机器回收。对使用云资源的团队来说这就是把“按需付费”做到自动化。CA 有几个默认行为要知道扩容触发是异步的机器真正 join 集群要等几分钟取决于底层平台缩容判定需要节点利用率连续低于阈值一段时间默认大概 10 分钟并且所有 Pod 都能迁移到其他节点才会执行如果有 Pod 设置了 PodDisruptionBudget也就是 PDB且 PDB 不允许中断缩容会被卡住。经验上我会给不同业务的 Pod 划分不同的节点池比如核心在线服务用一个池子批处理任务用另一个池子池子各自设置最小和最大节点数。这样缩容互不影响成本也看得清楚。千万不要把所有 Pod 塞进同一个池子一旦某个大任务把池子撑爆连核心服务都会跟着遭殃。节点池的扩缩容策略也要提前测试生产环境第一次扩容机器时发现等了三五分钟都没起来那种感觉相当煎熬。4. 从零配置一套可用的伸缩环境4.1 前提组件要跑 HPA集群里必须先有 Metrics Server。它负责从每个节点收集 CPU 和内存数据通过 metrics.k8s.io API 暴露。安装方式各发行版不同一般集群管理界面或插件市场都能一键安装。装完先验证kubectl top nodes 和 kubectl top pods 能输出数字就说明链路通了。如果要用自定义指标还得部署监控采集系统和对应的适配器。以常见的监控方案为例应用暴露指标监控系统抓取适配器把监控里的值暴露到 custom.metrics.k8s.ioHPA 再去读取。这套链路的每一环都需要有人维护所以新手先从 CPU 和内存起步最省心。HPA 本身是内建 API不需要单独装组件。用 kubectl get hpa 能看到对应资源配置。如果报错说没有此资源先检查集群版本老集群用 autoscaling/v2beta2新版本统一是 autoscaling/v2。4.2 一份能落地的 HPA 配置直接给一份我常用的配置先看再看解释apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-hpa namespace: prod spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web minReplicas: 3 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 behavior: scaleUp: stabilizationWindowSeconds: 0 policies: - type: Percent value: 100 periodSeconds: 60 scaleDown: stabilizationWindowSeconds: 300 policies: - type: Pods value: 1 periodSeconds: 60几个字段逐个说明。scaleTargetRef 指向要控制的 DeploymentminReplicas 和 maxReplicas 给出上下限metrics 列表里我同时配了 CPU 和内存HPA 会分别计算需要的副本数然后取最大值作为最终结果所以内存这里设成 80% 是兜底逻辑。behavior 字段是核心scaleUp 的稳定窗口设为 0表示一旦判定需要扩容就立刻执行policy 允许每 60 秒最多翻倍scaleDown 的稳定窗口保留 300 秒每次最多缩 1 个防止副本数在低负载边缘上下横跳。还有一点如果 HPA 要按平均利用率算Deployment 里的 Pod 必须配置 resource.requests。HPA 计算的是实际使用量除以 requests 的平均值没有 requests 的 Pod 在指标 API 里拿不到资源请求值会被判定为无法计算HPA 状态里 CPU 那一栏会一直显示 unknown。4.3 压测验证与效果观察配置写好后别急着收工压一下看真实表现。找一台机器对服务发起持续增长的请求然后开另一个终端观察NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS web-hpa Deployment/web 45%/60% 3 20 3 web-hpa Deployment/web 78%/60% 3 20 6 web-hpa Deployment/web 95%/60% 3 20 12 web-hpa Deployment/web 58%/60% 3 20 18这个过程能暴露很多问题如果 REPLICAS 一直不动说明指标链路或目标值有问题如果副本数狂飙到 maxReplicas 还压不住说明单个副本的 requests 设得太小一个 Pod 根本吃不下那么多流量这时候要考虑的是加大 requests而不是无限扩副本。压到目标后停掉压测观察缩容。按上面的配置缩容至少会触发 300 秒稳定窗口再加上 HPA 每 60 秒最多缩 1 个 Pod 的速率从 18 个缩回 3 个需要十几个周期也就是十几分钟。这个迟钝是故意的让负载观察区和 Pod 排空时间都足够避免刚缩完又因为瞬时流量反弹。压测时还要盯一下节点容量。如果集群节点不够HPA 扩上去的 Pod 会一直 Pendingkubectl get pods 能看到一堆 Pending。这时候如果没有 Cluster Autoscaler扩容链路就是断的有 CA 的集群看 CA 日志会看到它触发了节点扩容。5. 常见问题与排查技巧实录5.1 metrics 不可用最常遇到的第一个坑kubectl describe hpa 显示 unable to fetch metrics 或者 failed to get cpu utilization。十有八九是 Metrics Server 没装好或数据没上来。我的排查顺序固定是这样先 kubectl get apiservices | grep metrics看看 metrics.k8s.io 是否可用再 kubectl top nodes能出数据说明采集没问题最后再看 Metrics Server 本身的 Pod 日志很多证书类环境的坑都在日志里写得明明白白。自建集群常见的另一个原因是 Metrics Server 连不上节点的 kubelet 端口。有些场景需要给 Metrics Server 加相应的启动参数跳过证书校验才能采集到数据具体根据发行版文档来改了之后记得重启组件再看 top 命令是否恢复。5.2 副本数不停抖动抖动是弹性伸缩的经典问题。表现是 Replicas 一会儿上去一会儿下来像心电图。原因基本有三类目标值设得太紧比如 CPU 目标 40%实际在 45% 和 35% 之间摆动容差又带不动就会反复扩缩缺少 scaleDown 稳定窗口低负载来临后立刻缩结果下个周期指标又上去指标本身波动大比如内存锯齿状或某条自定义指标有偶发尖峰。解决思路就是给 behavior 和指标做平滑放大稳定窗口、限制缩放速率、选更平稳的指标。还有一个反直觉的情况HPA 看的是平均值如果两三个 Pod 的 CPU 突然飙到 100%其他 Pod 很低平均值可能刚过目标线HPA 扩一个副本下来把热点摊平之后又缩回去形成规律性抖动。这种场景可以考虑按 Pod 数量加权或者用更平滑的指标而不是只盯着平均值。5.3 扩容慢或者缩容慢HPA 不是实时系统。从指标变化到副本数变化要走完“采集指标—HPA 同步—Pod 调度—镜像拉取—容器启动—就绪探针通过”整条链路快的话 30 秒慢的话几分钟。尤其第一次扩容要拉镜像、要等待节点资源体感延迟非常明显。应对办法有几个把就绪探针的 initialDelay 和 timeout 调合理别让新 Pod 一直卡在未就绪状态在集群层面给关键业务的镜像做预缓存核心链路提前储备节点或给节点池配置更快的扩容策略。缩容慢多半是好事但有时候用户看到副本一直不缩也慌。缩容默认就有 300 秒稳定窗口再加上 CA 判断节点回收还有更长的观察期从流量下降到最后节点减少半小时到一小时都可能。这是保护机制我不建议为了省成本盲目把窗口调成 0那会制造更大的不稳定。5.4 其他容易踩的小坑Pod 没有配置 requestsHPA 状态里指标一直显示 unknown本质是算不出利用率。HPA 不支持 DaemonSet想给 DaemonSet 弹性伸缩得换个思路比如改造成 Deployment 加亲和性。PodDisruptionBudget 卡死缩容缩容时 HPA 会把副本数往下调但 PDB 限制同一时间中断数量可能导致副本数卡在下限附近动不了。HPA 和 VPA 同用两者互相改指标副本数量和 requests 来回漂移必须错开使用场景。只盯 HPA 不看节点Pod 全是 PendingHPA 指标正常但副本数起不来问题出在容量链路不在伸缩配置。我把这套东西完整跑通之后最大的体会是弹性伸缩不是配置一个 HPA 就自动省钱的魔法而是一套需要跟业务特征、成本预算、集群容量一起设计的系统工程。最实用的路线是先装上 Metrics Server把 CPU 和内存的 HPA 跑起来再盯着线上副本数变化和压测结果把 behavior 调明白最后根据业务的真实瓶颈决定要不要上自定义指标和 Cluster Autoscaler。副本数、节点数、成本这三个数字最好都接上告警别等账单出来才肉疼。