探索云原生
·
Kubernetes教程(五十)---K8s 1.35：In-Place Pod Resize 正式 GA，实现 Pod 资源零中断调整
内容提要
Kubernetes 1.35 引入了原地 Pod 资源调整功能，允许在不重建 Pod 的情况下动态调整 CPU 和内存资源，实现零中断。这一功能提升了工作负载效率，支持自动缩放，简化运维。内存调整通常需重启，而 CPU 调整可即时生效，现已稳定，适用于生产环境。
关键要点
-
Kubernetes 1.35 引入了原地 Pod 资源调整功能，允许动态调整 CPU 和内存资源，提升工作负载效率。
-
CPU 调整无需重启，内存调整通常需要重启，但在必要时可实现零中断。
-
该功能支持自动缩放，简化运维，资源调优变为日常微调。
-
从 Kubernetes v1.27 开始，该功能经历了多次迭代，最终在 v1.35 正式 GA，适用于生产环境。
-
重要限制包括：内存调整通常需要重启，QoS 类不能通过调整改变，某些容器类型不支持调整。
-
新增的 Pod 状态可以实时监控调整进度，确保调整请求的可行性。
-
最佳实践建议包括优先使用 CPU 的原地调整能力，选择合适的内存调整策略，并保持 Pod 的 QoS 类不变。
延伸解读
原地 Pod 资源调整的实际应用
Kubernetes 1.35 的原地 Pod 资源调整功能为运维人员提供了更灵活的资源管理方式。通过动态调整 CPU 和内存，用户可以在流量激增时迅速响应，避免服务中断。这种能力特别适合对延迟敏感的应用，能够显著提升用户体验。
内存调整的注意事项
虽然内存调整在 Kubernetes 1.35 中得到了支持，但通常需要重启容器。运维人员在进行内存调整时，需特别注意当前内存使用量，以避免因超出新限制而导致的 OOM（内存溢出）问题。建议在调整前进行充分的监控和评估。
QoS 类限制与资源调整
在进行 Pod 资源调整时，QoS 类的限制不可忽视。调整后必须保持原有的 QoS 类不变，这意味着在某些情况下，可能无法满足资源调整的需求。用户应提前了解各类 QoS 的特性，以避免在调整过程中出现不必要的调度问题。
延伸问答
Kubernetes 1.35 的原地 Pod 资源调整功能有什么优势？
该功能允许动态调整 CPU 和内存资源，提升工作负载效率，CPU 调整无需重启，内存调整在必要时可实现零中断。
如何在 Kubernetes 中监控 Pod 资源调整的进度？
可以通过查看 Pod 状态，使用命令 kubectl get pod 和 kubectl describe pod 来实时监控调整进度。
内存调整时为什么需要重启 Pod？
大多数应用程序和容器运行时不支持动态调整内存分配，因此内存调整通常需要重启容器才能生效。
Kubernetes 1.35 的原地 Pod 资源调整功能适用于哪些生产环境？
该功能经过多次迭代，现已稳定，适用于各种生产环境，特别是对延迟或重启敏感的工作负载。
在 Kubernetes 中如何配置 Pod 的资源调整策略？
可以通过设置 resizePolicy 字段来配置资源调整策略，指定资源类型和是否需要重启容器。
Kubernetes 1.35 的原地 Pod 资源调整功能有哪些重要限制？
重要限制包括内存调整通常需要重启，QoS 类不能通过调整改变，某些容器类型不支持调整。
