Kubernetes 1.35GA 原地扩缩容（In-Place Pod Resize）完整解析：机制、差异与实战示例

在 Kubernetes 的资源管理模型中，长期存在一个看似“合理”、但在生产环境中代价极高的设计：

Pod 的 CPU / 内存一旦修改，就必须重建 Pod。

这意味着：

• 连接中断

• 状态丢失

• 冷启动

• 调度不确定性

而这些，恰恰是在线服务最不能承受的代价。

在 Kubernetes 1.35 中，这一历史限制终于被正式解除：
In-Place Pod Resize（Pod 原地扩容）进入 GA（General Availability）阶段。

这是一次真正改变运维方式的能力升级。

镜像拉取解决方案：https://zhiliaole.top/archives/1763544164789

一、什么是 Pod 原地扩容？

官方能力的工程化定义：

在不重启 Pod、不重启容器、不重新调度的前提下，在线修改 Pod 的 CPU / 内存 requests 与 limits。

一眼看懂的变化对比

二、支持与不支持的修改范围（非常关键）

✅ 支持原地修改的资源

❌ 不支持的修改项

核心原则：
👉 原地扩容只解决「资源弹性」，不解决「Pod 形态变化」。

三、CPU 与内存的行为差异（生产必读）

很多事故，来自于不了解 CPU 和内存 resize 行为差异。

行为对比表

Kubernetes 对内存缩容采用了保守策略：
宁可慢一点，也不制造 OOM 事故。

四、与传统资源调整方式的对比

不同方案能力对比

五、使用示例：如何真正用起来？

下面给出 可直接在 1.35 集群中使用的示例。

示例 1：直接对运行中的 Pod 进行原地扩容

原始 Pod 配置

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"
      limits:
        cpu: "1"
        memory: "1Gi"

原地扩容 CPU 和内存

kubectl patch pod demo-app -p '
spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: "2"
        memory: "2Gi"
      limits:
        cpu: "4"
        memory: "4Gi"
'

👉 结果：

• Pod 不会重建

• 容器 不会重启

• 连接 不会中断

示例 2：查看扩容状态

kubectl describe pod demo-app

你会看到类似状态：

• ContainerResizeInProgress

• ContainerResizeCompleted

• 或 ResizeFailed

示例 3：节点资源不足时的行为

这保证了失败是安全的、可回滚的。

六、与 VPA 结合：这才是“完全体”

原地扩容并不是替代 VPA，而是让 VPA 真正进入生产可用状态。

VPA 行为对比

这对以下服务是质变：

• JVM / Spring 服务

• 长连接网关

• 在线推理 / AI 服务

• 有状态中间件

七、对平台与运维团队的长期影响

运维方式变化

成本与容量管理

八、是否可以直接用于生产？

推荐条件

该特性已 GA，意味着：

• API 稳定

• 行为可预期

• 支持长期维护

九、总结

Pod 原地扩容是 Kubernetes 资源管理能力的一次“质变”。

它让 Kubernetes：

• 从“只能靠重启解决问题”

• 走向“真正的在线资源调度系统”

如果说 Kubernetes 早期解决的是
“如何把应用跑起来”，
那么 1.35 的原地扩容解决的是
“如何让应用长期、稳定、优雅地跑下去”。