/tags/vpa/ Recent content in vpa on Hugo -- gohugo.io en Thu, 09 Apr 2026 10:00:00 +0800 /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 的资源定义 目标是不重建 降低垂直调容带来的扰动 一句话总结：