做容器化改造这几年接触最多的就是 K8s 的弹性伸缩。先说个结论如果你用的是阿里云业务量又有明显的波峰波谷ASK 这套 Serverless 容器服务配合弹性伸缩是目前成本效率最平衡的方案之一。标题里这几个关键词——弹性伸缩、Serverless、容器服务、ASK——串起来就是一条完整链路ASK 解决“容器跑在哪”弹性伸缩解决“跑几个容器”两者叠加之后你的集群就不需要为应对流量高峰而长期预留一堆闲置资源。峰值过去了Pod 自动缩掉账单也跟着缩掉。适合的人群也很明确不想每天盯着节点运维、又希望保留标准 K8s API 体验的团队以及正在做云原生改造、被弹性伸缩折腾过的人。我最早接触 ASK 是为了处理一个典型的定时爬虫业务每天凌晨两点到六点是高峰期白天几乎没流量。用普通 K8s 集群就得常年保留几台 ECS大部分时间 CPU 使用率不到 5%但高峰期又怕节点不够。后来换成 ASK高峰期 Pod 自动拉起来任务跑完自动缩到 0成本直接降到原来的三分之一不到。这篇文章我就把整个实战过程梳理一遍从 Serverless 架构选型、弹性伸缩原理到 HPA 配置、定时伸缩和事件驱动伸缩再到我踩过的一些坑一次性讲清楚。1. 为什么选择 ASKServerless 容器服务的核心价值1.1 ASK 和普通 K8s 集群的差别刚接触 ASK 的人容易把它理解成“没有节点的 K8s”。这个说法对但不够准确。更准确的理解是控制面由阿里云托管数据面不固定——你的 Pod 被调度到阿里云底层的 ECI弹性容器实例上运行每个 Pod 独占一个轻量虚拟沙箱系统帮你屏蔽了节点层的所有运维工作。和普通 K8s 集群相比最直观的区别在于是否需要管理节点。自建 K8s 你要维护 master 节点、work node、系统组件升级、内核漏洞修复、节点磁盘监控随便哪一项出问题都够喝一壶。ACK 托管集群帮你省掉了 master 的运维但 worker 节点依然要关心规格、扩缩容、NodePort 范围、系统盘水位。到了 ASK 这里连 worker 节点都不存在了你的 API 操作对象直接变成 Pod。这里的取舍非常关键。有些团队不敢用 ASK是觉得“没有节点心里没底”其实恰恰反过来节点不是目的跑业务才是目的。把节点层的复杂度完全交给云厂商自己只关心 Deployment、Service、Ingress 这些上层资源这对应用团队来说反而是减负。当然代价是你失去了对底层节点的完全控制比如不能自定义 kubelet 参数、不能给节点打特殊标签。99% 的业务根本用不上这些能力这就够了。1.2 弹性伸缩的核心优势从预留资源到按需付费传统架构里应对流量高峰靠的是“预留余量”。比如预估峰值需要 20 台 ECS就常年开着 20 台哪怕平时只有 2 台的负载。本质上你在为永远不会发生的峰值付全天的钱。ASK 的弹性伸缩把这件事彻底改掉了。Pod 不占用任何常驻资源业务没流量时副本数可以就是 0所有成本归零。流量来了HPA 根据指标把 Pod 拉起来流量走了再缩回去。计费粒度按秒Pod 创建多少秒就算多少钱没有“最低消费”的概念。这就是 Serverless 本身的设计哲学按实际使用付费而不是按最大容量付费。和普通 K8s 集群的节点伸缩相比ASK 的伸缩速度也有优势。普通 K8s 要新增 Pod得先等节点池扩容——新的 ECS 创建、初始化、加入集群、再调度 Pod整个过程最快也要两三分钟。ASK 里 Pod 直接由 ECI 支撑省掉了节点创建环节可以做到几十秒内完成扩容。这个差距在突发流量场景下是决定性的。1.3 适用场景与成本模型不是所有应用都适合无脑上 ASK。根据我自己的实践下面这几类业务放到 ASK 上收益最明显有明显的波峰波谷比如每天早上 9 点到晚上 11 点流量高凌晨几乎没人用定时批处理任务比如财务对账、数据清洗、日志压缩每天固定那几小时跑事件驱动型任务比如 Kafka 里来了消息才触发处理没消息就不需要任何常驻资源短期项目或活动页比如大促临时扩容、测试环境、Demo 环境如果是那种 7x24 小时、流量非常平稳的核心业务ASK 的成本不一定比包年包月的 ECS 更低。因为长期稳定负载下包年包月的折扣价要便宜得多。所以选型时先问自己一个问题我的业务的流量曲线是平的还是锯齿形的平的用包年包月锯齿形的才适合 Serverless。成本模型上要注意ASK 按 vCPU 和内存计费部署时每个 Pod 的规格怎么设置直接决定账单。建议给 Pod 设置合理的 requests 和 limits不要盲目给大规格否则流量低的时候成本也会显得很离谱。2. 弹性伸缩的整体设计从指标采集到 Pod 扩缩容2.1 一次完整弹性伸缩的链路长什么样很多人配置弹性伸缩只停留在写一个 HPA 的 YAML发现不好使就开始怀疑是 ASK 的问题。其实弹性伸缩是一条完整链路任何一环出问题都会导致伸缩失效。以 CPU 使用率触发的 HPA 为例完整链路是这样的首先metrics-server 通过 kubelet 的 API 采集每个 Pod 的 CPU 用量接着HPA 控制器从 metrics-server 读取这些指标计算当前平均使用率然后HPA 控制器把计算结果和设定的目标值比较计算期望副本数最后HPA 控制器直接修改 Deployment 的 replicas 字段触发一次滚动更新或扩容。在 ASK 集群里这条链路有几个埋点。metrics-server 是阿里云默认提供好的你不需要自己安装但要注意 Pod 的 requests 有没有配。HPA 计算 CPU 使用率时分母用的是 Pod 的 requests 值不是 limits也不是物理机的真实容量。如果你的 Pod 连 requests 都没写HPA 的 CPU 目标根本不会生效——这一点真的很多人踩坑后面我会展开讲。2.2 HPA 控制器如何计算期望副本数HPA 的核心公式其实很简单也是一个值得所有做弹性伸缩的人记住的公式desiredReplicas ceil[currentReplicas * (currentMetricValue / desiredMetricValue)]举个例子假设当前有 2 个 Pod平均 CPU 使用率是 160%你设定的目标是 80%那期望副本数就是ceil(2 * (160 / 80)) 4。如果当前平均使用率是 40%目标是 80%那期望副本数就是ceil(2 * (40 / 80)) 1会缩到 1 个。K8s 在计算时还会引入一个默认容忍度默认是 0.1意思是当前指标偏离目标值 10% 以内时不做伸缩避免指标的小幅抖动引起副本数频繁变化。这个参数可以通过 kube-controller-manager 的--horizontal-pod-autoscaler-tolerance调整但它在 ASK 托管控制面上不太好直接改我一般不会动它靠下面的冷却机制来控制抖动就够了。2.3 冷却机制为什么缩容不会立即发生冷却机制是整个弹性伸缩里最容易被忽视、也最容易让新手困惑的部分。你压测时看到 CPU 飙到 300%HPA 立刻扩容了但停止压测之后Pod 并不会马上缩回原来的数量。这是因为 K8s 默认设置了缩容稳定窗口默认 5 分钟。在这 5 分钟内即使指标已经降到很低HPA 也不会缩容目的是防止刚缩掉 Pod 流量又涨回来导致来回抖动。这个机制非常重要。想象一下早高峰结束后瞬间流量下降如果系统在 1 分钟内就把 Pod 从 20 缩到 2紧接着某几个请求又把 CPU 拉起来了系统又得重新扩容——这个过程就白折腾了。稳定窗口相当于一层缓冲让系统在面对噪声指标时不会“反应过度”。从业务角度看5 分钟缩容延迟是完全可以接受的毕竟你省下的成本是以分钟计而不是以秒计。ASK 里没有节点层扩容的额外负担Pod 级伸缩几乎可以在指标变化后的一两个周期内完成。所以我默认不会去修改 HPA 的同步周期保持默认的 15 秒同步一次就够了。如果你觉得扩容不够快先排查指标采集链路而不是急着调参数。3. 核心配置实战HPA 从入门到落地3.1 准备一个适合做演示的示例应用我习惯用一个简单的 nginx Deployment 来演示整个弹性伸缩过程。nginx 对 CPU 压测非常敏感压测流量上去之后 CPU 使用率能快速攀升方便观察 HPA 的行为。先把这个 Deployment 部署到 ASK 集群里。apiVersion: apps/v1 kind: Deployment metadata: name: sample-app namespace: default spec: replicas: 2 selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 resources: requests: cpu: 250m memory: 128Mi limits: cpu: 500m memory: 256Mi这里注意两个地方。第一我设置了resources.requests.cpu为 250m。这个字段是 HPA 计算 CPU 使用率的分母没有它 HPA 的 CPU 指标就不会有数据。第二requests 和 limits 我故意留了差距requests 250m、limits 500m这样 CPU 可以短时突发到上限但 HPA 计算时用的是 250m 作为基准。为了能从集群外面压测到这个应用我再创建一个 LoadBalancer 类型的 ServiceapiVersion: v1 kind: Service metadata: name: sample-app-svc spec: type: LoadBalancer selector: app: sample-app ports: - port: 80 targetPort: 80在 ASK 集群中LoadBalancer 会自动创建阿里云的 SLB 实例SLB 的内网或公网地址就是你的压测入口。3.2 创建 HPA完整 YAML 与字段解析部署好应用后创建 HPA。先看最基础的一个版本apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: sample-app-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: sample-app minReplicas: 1 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50autoscaling/v2是 HPA 的稳定版本尽量别再用autoscaling/v1v1 只能配置 CPU 百分比v2 支持内存指标、自定义指标和多指标策略。scaleTargetRef指定伸缩对象可以是 Deployment也可以是 StatefulSet。这里需要注意的是必须存在对应 workload而且 workload 内的 Pod 模板里要有resources.requests否则 HPA 会显示unknown状态。minReplicas和maxReplicas是伸缩的下限和上限。在 ASK 里我建议 minReplicas 直接设为 0这是普通 K8s 集群做不到的但 Serverless 容器支持缩到 0。如果你的业务允许冷启动延迟0 副本是对成本最友好的。不过要注意如果设成 0首次访问会有几十秒的冷启动时间你需要在业务入口做相应的超时重试机制。averageUtilization: 50的意思是希望所有 Pod 的平均 CPU 使用率维持在 50% 左右。这里目标值设得越低扩容越激进——目标 20% 的话CPU 一到 30% 就会扩容目标 80% 的话CPU 到 100% 都可能不扩容。我一般建议从 50% 开始调不要一开始就设得很低避免扩容过于敏感造成频繁创建销毁 Pod。3.3 HPA 的进阶配置behavior 策略和稳定性窗口K8s 的 HPA 从 1.18 版本开始原生支持behavior字段除了指定最大最小副本数之外你还可以精确控制扩容和缩容的行为。对于 ASK 上跑的业务来说这个字段是调优弹性伸缩体验的利器。举一个稳妥的配置示例spec: minReplicas: 1 maxReplicas: 20 behavior: scaleUp: stabilizationWindowSeconds: 0 policies: - type: Percent value: 100 periodSeconds: 15 scaleDown: stabilizationWindowSeconds: 300 policies: - type: Pods value: 1 periodSeconds: 60scaleUp里我设置了双重策略比率策略 100%、周期 15 秒意思是每 15 秒最多把当前副本数翻一倍同时我建议你可以再加一个绝对值策略比如每 15 秒最多加 4 个 Pod防止突发流量下翻倍策略扩张太快。stabilizationWindowSeconds设为 0代表指标一触达立刻扩容不等待。scaleDown里稳一点稳定窗口 300 秒且每 60 秒最多缩 1 个 Pod。这样即使业务波动剧烈也不会把刚扩容出来的 Pod 快速杀掉保证服务质量。这个配置是我在多个项目里实测下来比较好用的“稳健型”模板。如果你做的是大促瞬时流量scaleUp的节奏再激进一点也没关系如果业务流量本来就平稳缩容的绝对值策略甚至可以调成每 5 分钟缩 2 个。3.4 压测验证如何确认 HPA 真的在起作用配置完成后别急着收工一定要实测验证。我常用的压测工具是hey它比 ab 更轻量能直观看到每秒请求数和延迟。先确认当前状态kubectl get pods -o wide kubectl get hpa sample-app-hpa正常情况下HPA 的TARGETS列会显示类似3% / 50%的形式含义是当前所有副本的平均 CPU 使用率 3%目标 50%。然后开始压测。从公网压测试环境注意 SLB 的带宽和性能建议从一台跳板机发起压测hey -z 1m -c 50 -q 200 http://SLB地址/这里的参数含义是持续 1 分钟50 个并发连接每秒每个连接最多 200 个请求。实际流量压力可能非常猛CPU 会很快打到 100% 以上。压测过程中以 10 秒一次的频率执行kubectl get hpa sample-app-hpa -w你会看到类似这样的变化过程NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE sample-app-hpa Deployment/sample-app 142% / 50% 1 10 4 5m sample-app-hpa Deployment/sample-app 168% / 50% 1 10 8 5m再看一下 Pod 数量是否跟上kubectl get pods -l appsample-app压测结束后继续观察几分钟Pod 会分批缩回 minReplicas这个过程因为有稳定窗口的限制不会特别快。如果你看到扩容正常、缩容正常那这套 HPA 配置就可以认为通过了验证。4. 进阶玩法CronHPA 定时伸缩与事件驱动伸缩4.1 CronHPA适合规律性明显的业务HPA 是响应式的它只能看到当前指标涨了再去扩容始终慢半拍。如果你的业务有非常明显的时间规律比如每天早上 8 点流量开始上涨、晚上 11 点回落那就可以用 CronHPA 提前把副本数调上去让系统在流量到达之前就已经“热好身”了。阿里云提供了一套在 ACK 和 ASK 上都可用的定时伸缩方案使用上其实就是在 Deployment 旁边部署一个 CronHPA 资源声明“几点钟把副本数调到多少”。和 HPA 配合使用时CronHPA 负责定基调HPA 负责在基调基础上做微调。部署前先确认集群里有没有安装 ack-autoscaling-placeholder 和相关 CRD。可以用下面的命令查一下kubectl get crd | grep cronhpa kubectl get deploy -n kube-system | grep kron如果没有安装去组件管理里找到弹性伸缩组件一键安装即可。安装完成后写一个 CronHPA 资源apiVersion: autoscaling.alibabacloud.com/v1beta1 kind: CronHorizontalPodAutoscaler metadata: name: sample-app-cronhpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: sample-app excludeDates: - 2025-01-28 jobs: - name: scale-up-at-8am schedule: 0 8 * * * targetSize: 10 - name: scale-down-at-11pm schedule: 0 23 * * * targetSize: 1这里schedule是标准的 crontab 表达式0 8 * * *表示每天 8:00 整excludeDates可以用来跳过某些特殊日期比如大促期间可能就不需要定时扩缩或者希望用一套单独的伸缩计划。一个要注意的地方是 CronHPA 和 HPA 同时作用于同一个 Deployment 时可能存在“争夺控制权”的问题。CronHPA 到了 8 点把 replicas 改成 10HPA 如果发现当前指标很低可能立刻又把它缩回 2。这个情况很关键我遇到过不止一次。解决思路是让 CronHPA 修改的 targetSize 是一个“保底下限”而 HPA 的 minReplicas 也对应调整确保 HPA 不会缩到比 CronHPA 设定值更低的数量。也可以借助官方的 placeholder 机制让 CronHPA 给 Deployment 额外注入一个标记HPA 只在标记范围内做微调最终以 CronHPA 设定的值为准。4.2 KEDA以事件驱动的方式自动伸缩除了时间和 CPU真正生产环境里的扩容触发器往往是业务指标消息队列里积压了多少条消息、数据库连接池占用率、某条业务链路的响应时间。这些指标 HPA 本身是感知不到的于是就有了 KEDAKubernetes Event-Driven Autoscaling这个开源方案。KEDA 的原理不复杂它运行一个 operator监听 ScaledObject 自定义资源从外部系统读取指标并把指标转换成 HPA 可识别的格式喂给 HPA。所以 KEDA 并不是替代 HPA而是把“外部事件”翻译成“标准指标”最终还是由 HPA 完成副本数的调整。KEDA 支持几十种触发器消息队列、数据库、HTTP、定时任务都有现成的实现。比如我的一个任务队列场景里我用 RocketMQ 的触发器队列积压超过 1000 条时扩容积压清空后缩容。apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: consumer-scaledobject namespace: default spec: scaleTargetRef: name: consumer minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 10 cooldownPeriod: 60 triggers: - type: rocketmq metadata: brokerUrl: http://rocketmq-broker:9876 topic: order-topic group: consumer-group threshold: 1000这个配置下消费者 Pod 平时是 0 个一旦队列积压超过 1000 条消息Pod 会被自动拉起来处理消息队列处理完了Pod 又会在冷却期结束后缩回 0。对 ASK 来说这几乎是为它量身定做的场景事件驱动 弹性伸缩 Serverless 容器三者配合可以做到“有消息才跑没消息成本归零”。部署 KEDA 也简单在 ASK 集群里直接用 Helm 安装即可。默认安装会在集群里创建几个 operator 的 Deployment因为 operator 本身也需要消耗资源注意给它们设置合理的 requests否则它们会被调度到虚拟节点上按 ECI 计费。4.3 多种伸缩策略并存时的优先级问题实际项目中往往不只一种伸缩策略。最常见的是 HPA CronHPA 并存或者 HPA KEDA 并存。多策略并存核心要搞清楚每套机制的定位HPA基于资源指标的实时伸缩决定“当前该跑多少个”CronHPA基于时间的预置伸缩决定“某些时刻最少跑多少个”KEDA基于事件指标的伸缩决定“业务积压时该跑多少个”我的经验是不要把所有策略都叠在同一个 Deployment 上。最好是主线业务用 HPA时间规律非常明确的用 CronHPA事件触发的独立任务用 KEDA 单独管理。如果确实要叠加优先规则要明确CronHPA 管下限HPA 管上限两者之间的重叠区间交给 HPA 按指标微调KEDA 则尽量用在独立的消费者应用上不和 HPA 共用同一个 workload。5. 常见问题与排查技巧实录5.1 扩容没生效先从指标链路查起遇到 HPA 不工作我一般按下面的顺序排查。第一步看 HPA 的状态kubectl describe hpa sample-app-hpa输出的Status部分如果显示FailedGetResourceMetric说明 metrics-server 拿不到 Pod 的指标。原因通常是 Pod 没有设置 requests 字段或者 metrics-server 没有正常采集。问一下自己Deployment 的 Pod 模板里resources.requests写了吗没写的话HPA 的 CPU 目标就形同虚设。第二步确认 Pod 状态正常kubectl top pods如果kubectl top pods返回空或者报错说明 metrics-server 到 kubelet 的链路有问题。在 ASK 中这个组件通常是预置的不需要单独处理偶尔因为网络策略或 VPC 配置问题导致采集失败需要检查集群的网络安全组配置确保 443 和 10250 端口没有被封掉。第三步确认 SLB 是最新创建的。如果你用旧的 Service 或 SLB压测流量可能根本没有打到新 Pod 上CPU 指标自然上不去扩容自然也不会发生。这种情况我在排查时遇到过不止一次压测工具报告 QPS 很高但 HPA 指标纹丝不动最后发现访问的还是旧 Service 的 CLB 地址。5.2 ASK 冷启动延迟问题Serverless 容器有个绕不开的话题就是冷启动。Pod 从 0 开始创建ECI 要分配虚拟机、拉取镜像、启动容器整个流程在 30 秒到 1 分钟都是正常的。如果你的应用还需要加载很大的模型文件或者初始化数据库连接这个时间会更长。解决冷启动延迟最有效的办法是阿里云的镜像缓存。启用 imagedata 缓存后常用镜像的启动会快很多。做法是在 ASK 控制台的镜像缓存页面创建一个缓存规则把生产环境常用的镜像和版本填进去系统会提前把镜像快照准备好。Pod 创建时直接基于快照启动冷启动时间能缩短一半以上。另一个辅助手段是应用层的预热。在 Deployment 里配置 readiness 探针让新 Pod 完成初始化后再接收流量避免刚启动就被压垮。探针可以用 HTTP 检查readinessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 5 periodSeconds: 10再加上lifecycle.preStop优雅退出配置这样在缩容时也不会突然杀掉正在处理请求的 Pod。5.3 缩容频繁抖动怎么处理还有一种常见场景实际业务量波动不大但 HPA 常常出现扩了又缩、缩了又扩的抖动。这类问题往往不是扩容逻辑的问题而是缩容策略太激进。检查 HPA 配置里的behavior.scaleDown.stabilizationWindowSeconds。如果这个值小于 60 秒很容易出现抖动。我建议在不追求秒级缩容的场景里把稳定窗口拉到 300 秒以上再结合按绝对值缩容的策略比如每 60 秒只缩 1 个 Pod让副本数平稳回落。另外也要检查指标本身是不是有噪声。比如某个 Pod 的 CPU 使用率在 40% 到 60% 之间反复横跳而目标值是 50%那 HPA 可能每隔几个周期就试图调整副本数。这时候可以考虑把averageUtilization的目标值调高一点或者增加--horizontal-pod-autoscaler-tolerance的容忍度。不过在 ASK 托管版里改全局参数不容易还是优先用行为策略解决。5.4 常见错误速查表把以上踩坑经验整理成一张速查表遇到对应问题直接对照。现象可能原因排查/解决方式HPA 显示unknownPod 未设置 requests在 Deployment 模板中配置resources.requestsHPA 有数据但不扩容target 值过高或压测流量未到达新 Pod降低 averageUtilization确认 Service/SLB 指向正确Pod 长时间 PendingvSwitch 配置不足或 ECI 资源不足增加可用区 vSwitch检查 ECI 规格是否匹配缩容非常慢默认稳定窗口 5 分钟生效合理设置behavior.scaleDown.stabilizationWindowSecondsCronHPA 和 HPA 互相打架两者同时改同一个 Deployment 的 replicas让 CronHPA 管下限、HPA 管上限或使用 placeholder 机制冷启动时间长镜像较大且无缓存配置镜像缓存并开启懒加载成本高于预期Pod 规格设置过大或 minReplicas 过高按业务实际调整 requests 和 limits考虑 minReplicas 设为 06. 写在最后一些个人体会说了这么多配置和原理最后分享几个实际运维中的感受。第一条是Serverless 容器不是万能的但它的弹性伸缩能力确实让很多传统 K8s 集群头痛的问题变得不值一提。你不再需要为“节点会不会不够”而失眠因为 Pod 就是最小的扩容单位没有中间层。第二条体会是关于成本的ASK 的弹性帐单确实漂亮但前提是你要管好 Pod 规格。我见过有团队把所有 Pod 的 requests 都设成 4C8G结果流量低谷期还开着 20 个副本成本比原来还高。弹性伸缩解决的是“副本数量”的问题Pod 规格本身还是要靠人肉控制建议每季度审视一遍各服务的资源规格把明显偏大的调小。最后分享一个小技巧在 ASK 上做弹性伸缩测试时一定要区分“扩容测试”和“压测验证”。扩容测试用低压力验证 HPA 能触发压测验证用真实流量验证系统能撑住。两者别混在一起否则你会很难判断到底是压测工具的问题还是弹性伸缩逻辑的问题。先把链路走通再把压力加满这是我一直在用的节奏。如果你正准备把业务迁到 ASK 上我的建议是不要一次全量迁移。挑一个非核心的、有明显波峰波谷的服务先跑两周观察成本曲线和伸缩稳定性稳定之后再逐步扩大范围。弹性伸缩这套东西看起来是几个 YAML 的事真正落地后才知道它改变的是你对资源规划和成本管理的整个思考方式。