/tags/autoscaling/ Recent content in autoscaling on Hugo -- gohugo.io en Mon, 01 Jun 2026 09:00:00 +0800 /reading/queue-it/autoscaling-in-production/ Mon, 01 Jun 2026 09:00:00 +0800 /reading/queue-it/autoscaling-in-production/ Queue-it 做的是 virtual waiting room（虚拟等候室）——专门在抢购、票务、新品发布这类瞬时高并发场景里，把洪峰流量挡在等候室里、按可控速率放行。这期 Autoscaling in Production: When It Works and When It Doesn’t 的嘉宾是 Queue-it 的 Šimon Bučko（Senior Software Engineer）和 Zaigham Sarfaraz（Engineering Manager），主持人 José Quaresma，主题是生产环境里 autoscaling 有效和失效的边界。 一句结论：autoscaling 是必要条件，不是充分条件 整期最值得记的一句是 “autoscaling is necessary but not sufficient”。autoscaling 擅长应对线性、渐进的流量增长——监控 CPU、内存、请求数等指标，越过阈值就加实例，load balancer 通过 health check 发现新实例并分流。这套机制对"流量缓慢爬坡"几乎是理想方案。 但它有一个关键前提：扩容本身需要时间。新实例从触发到就绪是分钟级的。一旦流量是瞬时、非线性地砸下来，autoscaling 的反应速度就跟不上了。 那次 iPhone 发布的翻车 播客里的一个具体例子，是 2023 年一次 iPhone 发布（播客录制时大约三年前）。流量从 0 瞬间冲到上百万请求。他们当时虽然做了一些 vertical 预扩容，但主要还是指望 autoscaling 去接住尖峰——结果新服务器要 3–4 分钟才能初始化完成，对这种瞬时洪峰来说太慢了，终端用户直接看到了报错。 这个故事点出的边界很清楚：autoscaling 隐含"流量随时间平滑变化"的假设，而他们客户的流量曲线根本不平滑——用 Zaigham 的话说，大意是"零，然后瞬间一百万，然后又归零"。用一个为线性增长设计的机制去接非线性尖峰，差的那 3–4 分钟就是事故。 他们的应对：把"可预测"和"不可预测"分开处理 翻车之后他们发展出一套 pre-scaling（预扩容）流程，核心思路是把流量分成两类： /posts/kubernetes-vpa-inplace-resize/ Thu, 09 Apr 2026 10:00:00 +0800 /posts/kubernetes-vpa-inplace-resize/ 背景 如果你在 Kubernetes 里用过 Vertical Pod Autoscaler（VPA），大概率遇到过一个很现实的问题：推荐值有了，但真正生效时，Pod 先被驱逐，再由控制器拉起新实例。 对无状态服务来说，这种做法还能接受。但对数据库、消息队列、长任务、状态服务，甚至一些对尾延迟敏感的 API 服务来说，重建 Pod 本身就是一次明显的扰动。 如果你还没有把 requests / limits、QoS 和 throttling 这些基础概念串起来，可以先看我之前的这篇：Kubernetes CPU 资源管理与 QoS 机制。 Kubernetes 1.35（2025 年 12 月发布）把这个能力补齐了： In-Place Pod Resize 已经 GA VPA 的 InPlaceOrRecreate 更新模式进入 beta 也就是说，VPA 现在可以优先尝试在原地修改运行中 Pod 的 CPU 和内存资源，而不是直接把 Pod 赶走。 先区分三件事 很多讨论会把 HPA、VPA 和 in-place resize 混在一起，其实它们解决的是三层不同的问题。 能力 调整对象 会不会重建 Pod 典型用途 HPA 副本数 不一定 跟随流量扩缩容 VPA 单个 Pod 的 requests / limits 旧模式通常会 让资源更贴合真实负载 In-Place Resize 运行中 Pod 的资源定义 目标是不重建 降低垂直调容带来的扰动 一句话总结：