Kubernetes 1.35带来了一个重要更新：Pod原地扩容功能正式GA。这意味着调整Pod资源时，容器不再需要重启。这项技术对有状态应用尤为重要，数据库、消息队列等都可以实现无缝资源调整。
01resizePolicy配置详解
原地扩容的核心在于resizePolicy配置。K8s 1.35引入了resizePolicy字段，允许用户定义CPU和内存调整时的重启策略：
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
containers:
- name: app
image: nginx:latest
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
resizePolicy:
- resourceName: "cpu"
restartPolicy: "NotRequired"
- resourceName: "memory"
restartPolicy: "RestartContainer"
resizePolicy字段解析：
•resourceName: 指定要配置的资源类型（cpu或memory）
•restartPolicy: 定义资源调整时的容器行为
•CPU默认策略：NotRequired（无需重启）
•Memory默认策略：RestartContainer（需要重启容器）对于需要极致性能的应用，v1.33+版本也支持内存使用NotRequired策略：
resizePolicy:
- resourceName: "memory"
restartPolicy: "NotRequired"
02kubectl resize subresource操作
要执行原地扩容，需要使用--subresource resize参数：
# 查看Pod当前资源配置
kubectl get pod my-app -o yaml | grep -A5 "resources:"
# 使用patch命令进行资源调整
kubectl patch pod my-app --subresource resize --type merge -p '{
"spec": {
"containers": [{
"name": "app",
"resources": {
"requests": {
"memory": "512Mi",
"cpu": "500m"
},
"limits": {
"memory": "1Gi",
"cpu": "1"
}
}
}]
}
}'
关键参数说明：
•--subresource resize: 启用原地扩容子资源操作
•--type merge: 使用合并更新方式，避免覆盖其他配置
•-p: 指定patch内容，包含新的资源规格
03应用场景
数据库动态扩容： MySQL、PostgreSQL等数据库在业务高峰期经常需要临时扩容内存。传统方式需要停机维护，现在可以零停机完成。特别是对于内存密集型的OLAP查询，可以根据查询复杂度动态调整资源。
游戏服务器弹性伸缩： 游戏服务器在开服、活动期间流量暴增，需要快速扩容。原地扩容让游戏服务器可以在线调整资源，玩家完全无感知，避免了因服务器重启导致的掉线和重连问题。
突发流量应对： 电商大促、秒杀活动等场景，应用负载会瞬间飙升。配合VPA（Vertical Pod Autoscaler）的InPlaceOrRecreate策略，可以实现自动垂直伸缩。
Java应用启动优化： Java应用启动时需要较多内存进行JIT编译和类加载，运行后内存需求下降。现在可以在启动时分配较大内存，运行稳定后再动态缩减，既保证了启动速度，又节省了资源。
04使用限制与注意事项
原地扩容虽然强大，但也有限制：
1.资源类型限制：目前仅支持CPU和内存资源调整
2.QoS类别不变：Pod的QoS类别（Guaranteed/Burstable/BestEffort）创建后无法更改
3.Init容器不支持：初始化容器不支持原地扩容
4.内存缩减需谨慎：内存减少是尽力而为的，应用需要主动释放内存
5.Windows Pod不支持：目前仅支持Linux容器
6.节点约束：某些CPU/内存管理器可能会阻止变更
05与HPA/VPA的结合
原地扩容不是要取代HPA（水平Pod自动伸缩）和VPA（垂直Pod自动伸缩），而是让它们更加完善：
•HPA：负责横向扩展，增加Pod副本数
•VPA + 原地扩容：负责纵向扩展，调整单个Pod的资源规格
•最佳实践：先用VPA进行纵向扩容，达到节点资源上限后再用HPA横向扩展VPA现在支持InPlaceOrRecreate更新策略，会优先尝试原地扩容，失败时才回退到Pod重建：
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: my-vsea
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: my-deployment
updatePolicy:
updateMode: "Auto"
minReplicas: 1
containerScalingMode: "InPlaceOrRecreate"
06技术意义
原地扩容解决了Kubernetes长期以来的一个设计痛点：资源调整必须重启容器。这不仅影响了有状态应用，也让自动伸缩变得不够"自动"。从技术角度看，这是Kubernetes向"真正的云原生基础设施"迈出的重要一步。它让：
•有状态应用：数据库、消息队列等可以无中断扩容
•AI/ML训练：训练任务可以动态调整资源，提高GPU利用率
•边缘计算：资源受限环境下可以更灵活地调整应用规格
•成本优化：根据实际负载动态调整资源，避免过度配置
07总结
Kubernetes 1.35的原地扩容功能正式GA，标志着容器编排技术进入了一个新阶段。它不仅是一项技术进步，更是对生产环境真实需求的深度响应。
对于运维工程师来说，这意味着更少的维护窗口、更高的服务可用性；对于开发者来说，这意味着更灵活的资源配置、更快的迭代速度；对于业务来说，这意味着更好的用户体验、更低的运营成本。
新技术总有学习曲线。建议大家在测试环境充分验证，制定完善的监控和回滚策略，然后逐步在生产环境推广。毕竟，能够在不重启的情况下调整资源，这种感觉真的很酷！
作者介绍：
我是老卢，一个在运维领域摸爬滚打了七年的90后，专注 k8s、DevOps、云原生、AIOps 技术。白天搬砖踩坑，晚上码字分享。相信技术改变生活，坚持输出有温度的文章。
