这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。
代表 Kubernetes 项目，我很高兴地宣布，原地 Pod 调整大小特性（也称为原地 Pod 垂直缩放）， 在 Kubernetes v1.27 中首次引入为 Alpha 版本，现在已升级为 Beta 版本， 并将在 Kubernetes v1.33 发行版中默认启用！ 这标志着 Kubernetes 工作负载的资源管理变得更加灵活和不那么具有干扰性的一个重要里程碑。
传统上，更改分配给容器的 CPU 或内存资源需要重启 Pod。 虽然这对于许多无状态应用来说是可以接受的， 但这对于有状态服务、批处理作业或任何对重启敏感的工作负载可能会造成干扰。
原地 Pod 调整大小允许你更改运行中的 Pod 内容器的 CPU 和内存请求及限制，通常无需重启容器。
核心思想如下：
spec.containers[*].resources 字段现在代表期望的资源，并且对于 CPU 和内存是可变更的。status.containerStatuses[*].resources 字段反映当前运行容器上已配置的实际资源。resize 子资源更新 Pod 规约中的期望资源来触发调整大小。你可以在 v1.33 的 Kubernetes 集群上使用 kubectl 编辑 Pod 来尝试（需要 v1.32+ 的 kubectl）：
kubectl edit pod <Pod 名称> --subresource resize
有关详细使用说明和示例，请参阅官方 Kubernetes 文档： 调整分配给容器的 CPU 和内存资源。
Kubernetes 在水平扩缩工作负载（添加或移除副本）方面仍然表现出色，但原地 Pod 调整大小为垂直扩缩解锁了几个关键优势：
减少干扰： 有状态应用、长时间运行的批处理作业和敏感工作负载可以在不经历 Pod 重启相关的停机或状态丢失的情况下调整资源。
改进资源利用率： 无需中断即可缩小过度配置的 Pod，从而释放集群中的资源。 相反，在重负载下的 Pod 可以在不重启的情况下获得更多的资源。
更快的扩缩： 更快速地解决瞬时资源需求。例如，Java 应用在启动期间通常比在稳定状态下需要更多的 CPU。 可以开始时使用更高的 CPU 配置，然后在之后调整减小。
自从 v1.27 的 Alpha 版本发布以来，为了完善此特性、 提高其稳定性并根据反馈和进一步开发优化用户体验，已经进行了大量工作。 以下是关键变化：
resize 子资源： 修改 Pod 资源现在必须通过 Pod 的 resize
子资源进行（kubectl patch pod <name> --subresource resize ...）。
kubectl 版本 v1.32+ 支持此参数。status.resize 字段已被弃用。
调整大小操作的状态现在通过两个 Pod 状况暴露：PodResizePending：表示 kubelet 无法立即批准调整大小
（例如，如果暂时不能，则 reason: Deferred；如果在节点上不可能，则 reason: Infeasible）。PodResizeInProgress：表示调整大小已被接受并正在应用。
在此阶段遇到的错误现在会在此状况的消息中报告为 reason: Error。allocated_pods_state，actuated_pods_state）以可靠地管理
kubelet 重启时的调整大小状态，并处理运行时报告的资源与请求的资源不同的边缘情况。
修复了几个与检查点和状态恢复相关的错误。还提高了检查点的效率。UpdatePodSandboxResources CRI 调用，
以更好地通知运行时和插件（如 NRI）有关 Pod 级别的资源变化。晋升为 Beta 意味着该特性已经准备好被更广泛地采用，但开发工作并不会止步于此！ 以下是社区接下来的关注重点：
随着 InPlacePodVerticalScaling 特性门控在 v1.33 中默认启用， 你可以立即开始尝试原地 Pod 资源调整大小！
参考文档获取详细的指南和示例。
随着此特性从 Beta 阶段逐步推进，你的反馈是无价的。请通过 Kubernetes 标准沟通渠道（GitHub Issues、邮件列表、Slack）报告任何问题或分享你的经验。 你也可以查看 KEP-1287: In-place Update of Pod Resources 以获取完整的深入设计细节。
我们期待看到社区如何利用原地 Pod 调整大小来构建更高效、弹性更好的 Kubernetes 应用！