做 Kubernetes 这行绕不开的话题就是弹性伸缩。很多人觉得只要部署到集群里流量大了自然就能扩容结果一到促销或者突发流量就被报警轰醒才发现 Pod 数量没有动节点也快被打满了。原因很简单Kubernetes 的弹性伸缩不是开关而是一套由多个模块配合完成的机制你需要先搞清楚扩的是什么、靠什么触发、扩完之后谁能回收。这篇文章我从实际使用角度把 Pod 伸缩、节点伸缩、基于事件的伸缩三种方式串起来讲一遍包括配置细节、踩坑记录和验证方法适合正在维护生产集群、或者刚接触 Kubernetes 弹性伸缩的开发者参考。1. 弹性伸缩的整体思路先想清楚要扩什么1.1 三个维度的伸缩很多初学者以为弹性伸缩就是“Pod 不够了加 Pod”其实在 Kubernetes 里伸缩至少有三个层面。第一个是 Pod 数量层面也就是水平伸缩Horizontal Pod Autoscaling简称 HPA。它会根据 CPU、内存或者自定义指标调整 Deployment、StatefulSet 的副本数。这类伸缩反应最快也是日常用得最多的。第二个是单个 Pod 的资源大小层面也就是垂直伸缩Vertical Pod Autoscaling简称 VPA它会修改 Pod 的 CPU、内存 request 和 limit。VPA 解决的是 Pod 数量不变但单个 Pod 资源不够的问题。第三个是集群节点层面也就是节点自动伸缩Cluster Autoscaler简称 CA当所有节点都放不下新 Pod 时自动帮集群加机器当节点利用率很低而且上面的 Pod 可以被调度走时自动释放节点。再加上事件驱动伸缩Event Driven Autoscaling比如 KEDA本质上还是在调整 Pod 数量但触发条件从“指标达到阈值”变成了“消息队列积压了多少条”、“延迟达到了多少毫秒”这类更贴近业务的事件。理解了这几种伸缩的层次你就明白它们不是互相替代的关系而是协同工作的上下游HPA 负责把负载分散到更多 Pod 上CA 负责让这些多出来的 Pod 有地方可去。我用一个生活类比帮助记忆HPA 像是餐厅高峰期临时加桌子VPA 是给每张桌子换更大的餐盘CA 则是把餐厅旁边的空地也租下来。只加桌子但没租地桌子没地方放只租地但没加桌子也就白白浪费租金。1.2 为什么 Kubernetes 适合做弹性伸缩Kubernetes 能把弹性伸缩做得这么灵活根本原因是它把应用做成了可声明、可调度、可观测的“对象”。Deployment 副本数只是个字段意味着你可以通过 API 动态修改Pod 的资源 request 是调度依据意味着新建的 Pod 能准确判断该放到哪个节点监控数据通过 Metrics API 暴露给控制面控制器就能基于这些数据不停计算期望副本数。另一个关键点是 Kubernetes 控制器循环control loop的天然属性。HPA 控制器每隔一段时间就去拉取指标和当前副本数对比计算出期望值然后更新 Deployment 副本数。这个循环不需要人工介入只要指标源稳定它就能一直自己调节。更重要的是伸缩行为是可审计的HPA 的事件、副本数的变化都记录在 Kubernetes API 里出问题能通过kubectl describe查到原因这在生产环境非常重要。当然有利就有弊。Kubernetes 弹性伸缩的灵活性也带来了配置复杂度。指标采集延迟、阈值设得太低、稳定窗口过长任何一个环节没调好都可能造成抖动。所以后面我会尽可能把每一步的参数含义和选择原因写清楚。2. 最常用的 HPAPod 水平自动伸缩2.1 HPA 的工作原理HPA 是 Kubernetes 自带的控制器它的完整工作流程可以概括为四步采集指标、计算期望副本数、更新工作负载、回写状态。首先HPA 控制器通过 metrics API 读取指标数据。Kubernetes 默认的指标来源是 metrics-server它只采集节点和 Pod 的 CPU 与内存使用量。如果你需要自定义指标比如 QPS、队列长度就得接 Prometheus custom metrics API 或者使用 KEDA 这类方案。接着HPA 根据当前指标值和目标值计算期望副本数公式是期望副本数 ceil(当前副本数 × (当前指标值 / 期望指标值))举个具体例子假设当前有 4 个副本每个 Pod 的 CPU 使用率是 80%HPA 配置的目标值是 50%那么计算结果是 4 × (80 / 50) 6.4向上取整得到 7 个副本。如果当前指标值是 30%目标值是 50%计算结果是 4 × (30 / 50) 2.4向上取整是 3HPA 会缩到 3 个。注意这里有一个缩放策略的概念为了避免抖动HPA 不会立即把副本数增加到 7而是先根据稳定窗口 stabilization window判断趋势然后逐步调整。然后控制器调用 Deployment 的 scale 子资源更新副本数。最后HPA 会把当前的副本数、目标副本数、观察到的指标值写到 status 字段里通过kubectl get hpa -o yaml可以看到具体明细。2.2 配置 HPA 的完整示例与关键字段下面是一个最基础的 HPA 配置针对一个名为web-server的 DeploymentapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-server-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web-server minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 behavior: scaleUp: stabilizationWindowSeconds: 60 scaleDown: stabilizationWindowSeconds: 300这里有几处细节值得展开。apiVersion建议直接使用autoscaling/v2它支持多指标和behavior配置老版本的v1只能配 CPU。我在排查问题时就遇到过有人还在用v1导致内存指标根本不生效。target的type可以选Utilization利用率或者AverageValue平均值。Utilization是相对于 Pod 声明的 request 值来计算比例的比如 Pod 只请求了 0.5 核 CPU那么 100% 利用率对应的是 0.5 核AverageValue是直接指定所有 Pod 的平均值比如平均 CPU 使用量 200m。前者更适合大多数场景因为每个 Pod 的 request 大小可以不同后者适合需要精确控制资源总量的场景。behavior是 v2 API 新增的缩放策略配置。scaleUp里的stabilizationWindowSeconds表示 HPA 在扩容时会等待窗口期内所有候选副本数中的最大值避免瞬时尖刺导致疯狂扩容。scaleDown的窗口通常要设置得比scaleUp长我一般会设置成 5 到 10 分钟防止缩容过快导致 CPU 又立刻涨回去。2.3 多指标与自定义指标生产环境的业务很少只靠 CPU 判断负载。比如一个网关服务CPU 使用率可能很低但每秒请求数已经很高只配 CPU 的话 HPA 根本不动。所以 v2 版本支持在一个 HPA 里配置多个指标控制器会分别计算每个指标对应的期望副本数然后取最大值作为最终副本数。多指标配置示例metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: 100Pods类型表示指标来自每个 Pod 的维度Kubernetes 会计算所有 Pod 指标的平均值。还有Object类型用于指标关联到某个对象比如 Ingress 的 QPS。但需要注意如果 memory 指标的利用率超过 80% 不会自动解决因为内存不像 CPU 那样可以压缩Pod 内存涨上去之后很难通过扩容立刻降低反而可能因为新 Pod 也占用内存而继续积压。实际使用中我更推荐内存指标只用来做兜底不适合作为唯一伸缩依据。自定义指标需要额外提供 metrics API 服务。常见的方案是在集群里部署 Prometheus再通过 Prometheus Adapter 将 Prometheus 查询结果暴露为自定义指标然后在 HPA 里引用。这套体系完善但代价是需要维护 Adapter 的配置和指标暴露结构对于只想简单按 Redis 队列长度伸缩的团队后面介绍的 KEDA 会更轻。2.4 HPA 的稳定窗口与冷却为什么需要稳定窗口和冷却直接看一个实际场景在线商城在做秒杀活动流量 10 秒内从 100 QPS 涨到 500 QPSHPA 采集到指标后计算需要扩容于是从 3 个副本扩到 8 个。假如没有稳定窗口第二次采集指标时发现 QPS 又降到了 200按公式计算只需要 4 个副本它就会立刻缩回 4 个如此反复整个集群都在频繁创建和销毁 Pod用户请求可能直接被掐断。Kubernetes HPA 中的stabilizationWindowSeconds正是为了解决这个问题。在窗口期内控制器会记录每次计算的“期望副本数”最终取窗口期内的最大值扩容或最小值缩容这样即使指标瞬时下降也不会马上缩容。我的建议配置是先保守再激进扩容窗口设短一点比如 30 到 60 秒缩容窗口设长一点比如 300 到 600 秒。理由很简单扩容慢最多是短期性能受影响但缩容太快会造成抖动影响面更大。另外还有一个selectPolicy选项可以设置成Max、Min或者Disabled控制扩容/缩容时在连续周期内选择哪个策略。如果集群资源有限可以把scaleDown的selectPolicy设成Disabled直接禁止缩容避免高峰期后自动回收副本带来风险。3. VPA 与垂直伸缩另外一种玩法3.1 VPA 是什么VPAVertical Pod Autoscaler负责调整 Pod 的 CPU 和内存 request/limit。它通常以 Deployment 方式运行在集群中包含三个组件Recommender 负责根据历史使用量计算推荐值Updater 负责更新已经运行的 Pod 的资源和触发重启Admission Controller 则在新建 Pod 时自动注入推荐资源值。为什么需要 VPA最常见的一个场景是服务的资源 request 设置得比较随意有的开发者直接给 4 核 8G但实际只用 100m 和 200M浪费了大量节点资源另一个场景是服务负载模式稳定但单个 Pod 峰值时内存会突然涨高这时候如果只靠水平扩容可能副本多了但每个副本都在内存边缘不如直接把每个 Pod 调到更大的规格。VPA 的推荐有三种模式Auto自动更新并重启 Pod、Initial只在 Pod 创建时注入推荐值不更新已有 Pod、Off只做推荐不自动修改。在测试环境用Auto没什么问题但生产环境我会强烈建议大家先用Off模式观察一段时间确认推荐值合理后再切换到Auto否则 VPA 可能会在业务高峰期强行重启所有 Pod造成大面积中断。3.2 VPA 部署和配置VPA 本身不是 Kubernetes 的核心组件需要单独部署。部署完成后通过VerticalPodAutoscaler资源对象使用。一个最小配置示例apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: web-server-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: web-server updatePolicy: updateMode: Off resourcePolicy: containerPolicies: - containerName: * minAllowed: cpu: 100m memory: 128Mi maxAllowed: cpu: 2 memory: 4Gi推荐值计算并不只看平均值而是会结合一个安全边际。比如 Pod 过去一小时 CPU 平均使用 200m但 95 分位使用率是 400mVPA 就可能推荐 600m给后续峰值留足空间。内存同理通常会推荐比历史最高值高一些的值。关键点在于内存 request 和 limit 的区别。VPA 推荐的是 request当 request 提高后Pod 会被重新调度到能满足这个 request 的节点上这个过程可能导致 Pod 重建。如果业务是无状态的没问题但对于有状态的数据库类应用Pod 重建通常意味着数据迁移风险较高。所以 VPA 更适合无状态的工作负载。3.3 HPA 与 VPA 能否同时用官方文档明确不建议对同一个 Deployment 同时启用基于同一资源比如 CPU的 HPA 和 VPA。原因很简单HPA 会不停调节副本数VPA 会不停调节单个 Pod 资源大小两者同时操作会导致控制目标冲突集群资源被一边扩容一边缩容地互相拉扯。那是不是完全不能用也不是。你可以让 VPA 只工作在Initial模式也就是只在 Deployment 刚创建时注入一次资源推荐值之后交给 HPA 做水平伸缩。这样既拿到了合理资源基线又不会在运行期和 HPA 打架。另一个思路是让 HPA 基于自定义指标比如 QPS伸缩而 VPA 基于 CPU/内存在后台调整两者指标源不同互相干扰会小一些但我也建议谨慎使用需要做充分压测。实际项目中常见的问题是开发者直接给 Pod 设置了过大的 request导致集群里塞不下几个 Pod 就触发了节点扩容成本飙升。用 VPA 的推荐值对比一下往往能发现大量资源被浪费。所以即使你不打算用 VPA 自动更新也建议部署它并开Off模式定期看看推荐值手动调优资源规格。4. 集群层面的弹性Cluster Autoscaler4.1 CA 的工作原理Cluster Autoscaler以下简称 CA处理的是节点级别的伸缩。它独立于 HPA 工作运行在集群内部定时扫描集群里有没有“Pending”状态的 Pod。如果一个 Pod 因为所有节点资源不足而无法调度CA 会启动扩容流程根据节点池的配置扩容策略创建新节点并在节点 Ready 后让调度器把 Pending 的 Pod 调度上去。缩容逻辑正好相反。CA 会检查每个节点如果满足以下条件就考虑删除节点上所有 Pod 的 request 总和低于节点配置的缩容阈值默认是 50%并且这些 Pod 都能被调度到其他节点上。同时CA 会跳过有 local storage、有 PDBPodDisruptionBudget限制保护、或者不能被安全驱逐的 Pod。这里有一个容易忽略的细节CA 看到的是 Pod 的资源 request而不是实际使用量。如果业务 Pod 的 request 设置得特别小即使实际已经挤到 CPU 爆满CA 也不会认为需要扩容因为这从调度角度上看资源是够的。所以做好资源 request 的准确设置是 CA 能正常工作的前提。4.2 CA 配置要点CA 一般通过 Deployment 部署核心参数都在启动命令里。一个常见的部署命令示例./cluster-autoscaler \ --cloud-provider你的云厂商 \ --node-group-auto-discoveryasg:tagk8s.io/cluster-autoscaler/enabled \ --scale-down-utilization-threshold0.5 \ --scale-down-unneeded-time10m \ --max-nodes-total100 \ --expanderrandomscale-down-utilization-threshold是缩容阈值默认 0.5 表示节点利用率低于 50% 时考虑缩容我会根据业务波动调到 0.4 或 0.6。scale-down-unneeded-time表示节点保持低利用率多长时间后才开始缩容建议 10 分钟以上防止短时间波动导致节点被误删。max-nodes-total是集群节点上限没有上限的话一次故障可能导致费用爆炸。CA 扩容时支持多种策略random、least-waste、most-pods等。我建议在多节点池环境中使用least-waste它会选择扩出来的节点浪费最少节省成本如果希望尽快让 Pod 跑起来random也可以。这里特别注意CA 不负责像 HPA 那样响应实时流量它有自己的扫描周期通常是每 10 秒检查一次 pending Pod。如果你发现扩容节点要等好几分钟很多时间是在等云厂商的 API 创建实例、初始化配置、加入集群这些时间没法完全靠 CA 参数规避。4.3 多节点池与多云场景在生产环境我们通常不只用一个节点池。比如用一个 fixed 节点池承载核心数据库用两个 autoscaling 节点池承载无状态业务其中一个用 Spot 实例降低成本另一个用按量付费保证稳定。CA 配合nodeSelector、topologySpreadConstraints、PodDisruptionBudget可以做到把 Pod 引导到合适的节点池。多节点池还有一个重要技巧给不同的节点池设置不同的PriorityClass或者通过expander的优先级控制扩容顺序。CA 在扩容时可能有多组实例可选如果优先使用便宜的 Spot 实例就可以把expander配置为priority并给节点池打上带优先级的标注。不过我这里要提醒一点如果你的关键业务不能容忍中断不要让所有副本都跑在同一批 Spot 实例上至少保持 minReplicas 或者固定节点池能兜底。多云场景下CA 更多是作为每种云环境对应的插件来使用比如 AWS 对应 AWS 的实现OpenStack 对应另一套实现。跨云统一管理往往要借助更上层的多集群方案这时候 CA 的思维依然是通用的但它只能感知单集群的节点情况。在规划多集群弹性时最好把伸缩策略分成两层本集群内用 CA跨集群流量调度交给上层负载均衡或者服务网格。5. 事件驱动的伸缩KEDA5.1 KEDA 能解决什么问题KEDAKubernetes Event Driven Autoscaling解决的是“指标来自外部系统”的伸缩需求。日常中最典型的场景是消费队列里的消息消费者 Pod 处理 Kafka 或 RabbitMQ 中的消息消息积压越多需要的消费者就越多但 Kubernetes 内置 HPA 无法直接感知 Kafka 的积压数量。传统做法是写一个 exporter 把队列长度变成 Prometheus 指标再接 HPA但流程长、维护成本高。KEDA 把“监听外部事件源”这部分直接做成了 scaler内置支持 Kafka、RabbitMQ、Redis 等几十种组件。KEDA 的另一个价值是支持从 0 缩放scale to zero。如果 HPA 的最小副本数是 0它本身做不到因为你没法完全停止接收流量但 KEDA 可以它会把 Deployment 降到 0 个副本当消息到来时再快速拉起。这非常契合低频任务的成本优化场景——没有事件时一个 Pod 都不用跑节省资源。5.2 KEDA 架构与部署KEDA 由两个核心组件组成Operator 和 Metrics Adapter。Operator 负责管理 ScaledObject 生命周期Metrics Adapter 会将 SDK 拉取到的外部指标暴露成 Kubernetes custom metrics API供 HPA 使用。本质上是 KEDA 创建了一个隐藏的 HPA 对象并实时提供指标给它所以对于 Kubernetes 本身来说还是 HPA 在工作只是指标源由 KEDA 接管。部署 KEDA 很简单直接使用 Helm 或者官方 YAML 即可。安装完成后可以使用kubectl get scaledobject查看所有伸缩定义。需要提前在集群里装好 metrics-server因为 KEDA 最终还是要依托 Kubernetes 自己的 HPA 控制器而 HPA 依赖 metrics API。5.3 ScaledObject 配置示例以一个 Redis 队列消费服务为例apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-consumer-scaler spec: scaleTargetRef: name: redis-consumer minReplicaCount: 0 maxReplicaCount: 10 cooldownPeriod: 60 triggers: - type: redis metadata: address: redis-service:6379 listName: myqueue listLength: 10上面配置的意思是当 Redis 中的myqueue列表长度超过 10 时开始扩容消息处理完后缩容到 0。cooldownPeriod相当于冷却时间表示触发条件消失后要等待多少秒再开始缩容避免队列长度刚低于阈值就缩回去。KEDA 在部署时还需要创建一个TriggerAuthentication或ClusterTriggerAuthentication资源用来保存连接外部系统的凭据。比如连接 Kafka 的用户名密码、连接 AWS SQS 的密钥等不要直接写死在 ScaledObject 里避免敏感信息泄露。我在实际项目里用 KEDA 做过一个离线报表任务每天早上消息队列产生大量任务消费者 Pod 从 0 自动扩展到 20任务跑完后慢慢缩回 0整个集群本来需要常驻 5 个副本现在高峰期之外的时段全部释放成本下降非常明显。如果你做的是批处理、异步任务、事件流处理类服务强烈建议试试 KEDA。6. 实操中的避坑经验6.1 常见坑与排查我整理了自己在生产环境遇到过的几个高频问题按排查顺序列出来。第一个坑是 HPA 一直显示Unknown指标或者扩容失败。先检查 metrics-server 是否在正常运行然后看 Pod 是否启用了资源 request。很多同学只设置了 limit 没有 request或者容器没有显式指定资源HPA 算不出利用率自然就不工作。另外如果你的应用是单进程会 fork 子进程CPU 指标的准确性也可能受影响。第二个坑是扩容后立刻缩容形成“抖动”。典型原因是缩容窗口太短或者behavior配置了激进的scaleDown。我曾经把一个服务的缩容窗口设成 60 秒结果高峰期一过集群节点上所有 Pod 都在疯狂重建连数据库连接都被打崩了。后来把缩容窗口调到 10 分钟问题消失。第三个坑是 CA 不缩容节点。排查思路是看节点上是否有 PDB 规则拦截驱逐是否有带 local storage 的 Pod或者节点本身处于被 Disabled 状态。还可以用kubectl describe node查看节点的cluster-autoscaler.kubernetes.io/scale-down-disabled标注。第四个坑是节点扩容出来了但 Pod 却迟迟没有调度过去。这通常是节点池的标签和 Deployment 的nodeSelector不匹配或者新节点加入了集群但还有 Taints/Tolerations 不匹配。可以用kubectl describe pod pending-pod查看 Events里面会写明被哪个节点拒绝以及原因。6.2 压测验证方法配置完弹性伸缩不能直接上线指望它自己跑好一定要做压测验证。我的验证流程一般是这样先给工作负载设置一个合理的基线资源 request然后启动压测工具比如hey、wrk或者云厂商的压测产品向服务发请求。在压测过程中同时观察三个终端窗口一个是kubectl get hpa -w看 HPA 期望副本数的变化一个是kubectl get pods -o wide -w看 Pod 的创建和分布另一个是kubectl top nodes看节点资源变化。如果 HPA 已经扩容到最大值但 QPS 还没有达标先看单个 Pod 的资源利用率。如果单个 Pod 已经 CPU 打满说明需要加副本数上限或者调大 request如果单个 Pod 利用率还很低说明应用的瓶颈不在 CPU需要改用自定义指标。压测结束后继续观察缩容过程确认缩容窗口生效没有出现抖动。注意压测前一定要先确认所有服务的最小副本数足够支撑压测工具本身的流量否则压测可能先把自己压崩得到的结论没有参考意义。6.3 设计建议结合经验我对 Kubernetes 弹性伸缩的整体设计给几个建议。第一资源 request 是弹性伸缩的地基。Kubernetes 调度和 HPA 计算都基于 request所以最重要的不是 task 大小而是把每个容器的 request 调准。建议先运行一段时间用 VPA 推荐值或者监控数据校准再启用伸缩策略。第二能分层的不要混在一起。HPA 管应用副本数CA 管节点数量KEDA 管事件驱动的触发它们各管一段尽量不要在同一个指标上做双重控制。否则你很难定位问题到底是 HPA 没触发还是 CA 扩容慢第三给所有伸缩策略设上限。HPA 的 maxReplicas、CA 的 max-nodes-total都要显式配置。线上出现过一次某个服务因为指标采集异常HPA 直接将副本数拉到上限再加上 CA 扩容账单瞬间变大。设上限不一定能完全防止故障但能把爆炸半径控制住。最后一定要为每个伸缩对象配上合理的 PodDisruptionBudget尤其是缩容和节点回收会频繁发生的场景。PDB 能保证在任何时候最少有多少个副本存活配合缩容窗口能最大程度降低对用户的影响。我踩过几次坑之后才明白弹性伸缩不是快就行要稳要在扩容速度和缩容安全之间找到平衡点。根据我个人实际操作经验最稳的开始方式是先用 VPA 的 Off 模式观察一周压测数据再把 HPA 稳定窗口和 CA 缩容时间同时调好最后在流量低谷期手动模拟一次缩容观察无异常后再交给自动化。