调整分配给 Pod 的 CPU 和内存资源
特性状态：
Kubernetes v1.36 [beta]（默认启用）本页面说明了如何在不重新创建 Pod 的情况下，更改在 Pod 级别设置的 CPU 和内存资源。
就地 Pod 调整功能允许修改运行中 Pod 的资源分配，从而避免干扰应用。 调整单个容器资源的流程详见调整分配给容器的 CPU 和内存资源。
本页面重点介绍就地 Pod 级别资源调整。Pod 级别资源定义在 spec.resources 中，
作为 Pod 中所有容器消耗资源的总量上限。就地 Pod 级别资源调整功能允许你直接更改运行中
Pod 的这些 CPU 和内存总量分配。
准备开始
你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。 建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：
你的 Kubernetes 服务器版本必须不低于版本 1.35.要获知版本信息，请输入 kubectl version.
你需要在控制平面和集群中的所有节点上启用以下特性门控：
InPlacePodLevelResourcesVerticalScalingPodLevelResourcesInPlacePodVerticalScalingNodeDeclaredFeatures
要使用 --subresource=resize 参数，kubectl 客户端版本需至少为 v1.32。
Pod 调整状态和重试逻辑
kubelet 用于跟踪和重试资源变更的机制在容器级别和 Pod 级别的调整请求之间是共享的。
状态、原因和重试优先级与容器调整中定义的完全相同：
- 状态条件：
kubelet使用 PodResizePending（原因如 Infeasible 或 Deferred）和 PodResizeInProgress 来传达请求的状态。 - 重试优先级：Deferred 调整根据 PriorityClass 进行重试，然后是 QoS 类（Guaranteed 优先于 Burstable），最后按被延迟的持续时间排序。
- 跟踪：你可以使用
observedGeneration字段来跟踪哪个 Pod 规约（metadata.generation）对应于最近处理的调整请求的状态。
有关这些条件和重试逻辑的完整描述，参阅容器调整文档中的 Pod 调整状态部分。
容器调整策略和 Pod 级别调整
Pod 级别资源调整不支持也不需要自己的重启策略。
-
无 Pod 级别策略：对 Pod 总量资源（spec.resources）的更改始终就地应用，不会触发重启。 这是因为 Pod 级别资源作为 Pod cgroup 的整体约束，不直接管理容器内的应用运行时。
-
容器策略仍然有效：
resizePolicy仍必须在容器级别（spec.containers[*].resizePolicy）配置。 此策略控制当单个容器的资源请求或限制发生变更时是否重启该容器，无论该变更是由直接的容器级别调整发起的， 还是由整体 Pod 级别资源边界的更新发起的。
限制
对于 Kubernetes 1.36，就地调整 Pod 级别资源受限于容器级别资源调整中描述的所有限制， 详见调整分配给容器的 CPU 和内存资源：限制。
此外，以下约束是 Pod 级别资源调整特有的：
-
容器请求验证：仅当调整后的 Pod 级别资源请求（spec.resources.requests）大于或等于 Pod 中所有单个容器的对应资源请求之和时，才允许调整。这确保了 Pod 的最低保证资源可用性。
-
容器限制验证：当单个容器限制小于或等于 Pod 级别资源限制（spec.resources.limits）时， 允许调整。Pod 级别限制作为一个边界，任何单个容器都不能超过，但容器限制之和允许超过 Pod 级别限制，从而实现 Pod 内容器之间的资源共享。
示例：调整 Pod 级别资源
首先，创建一个设计用于就地 CPU 调整和需要重启的内存调整的 Pod。
apiVersion: v1
kind: Pod
metadata:
name: pod-level-resize-demo
spec:
containers:
- name: pause
image: registry.k8s.io/pause:3.9
resizePolicy:
- resourceName: cpu
restartPolicy: NotRequired # 默认值，但此处需显式指定
- resourceName: memory
restartPolicy: RestartContainer
resources:
requests:
cpu: 100m
memory: 100Mi
- name: nginx-server
image: registry.k8s.io/nginx:latest
resizePolicy:
- resourceName: cpu
restartPolicy: RestartContainer
- resourceName: memory
restartPolicy: RestartContainer
resources: # Pod 级别资源
requests:
cpu: 200m
memory: 200Mi
limits:
cpu: 200m
memory: 200Mi
创建 Pod：
kubectl create -f pod-level-resize.yaml
此 Pod 以 Guaranteed QoS 类启动，因为 Pod 级别的请求等于限制。验证其初始状态：
# 等待 Pod 运行
kubectl get pod pod-level-resize-demo --output=yaml
观察 spec.resources（200m CPU，200Mi 内存）。注意
status.containerStatuses[0].restartCount（应为 0）和
status.containerStatuses[1].restartCount（应为 0）。
现在，将 Pod 级别的 CPU 请求和限制增加到 300m。使用带有 --subresource resize 命令行参数的 kubectl patch。
kubectl patch pod pod-level-resize-demo --subresource resize --patch \
'{"spec":{"resources":{"requests":{"cpu":"300m"}, "limits":{"cpu":"300m"}}}}'
# 替代方法：
# kubectl edit pod pod-level-resize-demo --subresource resize
# kubectl apply -f <updated-manifest> --subresource resize --server-side
说明：
--subresource resize 命令行参数要求 kubectl 客户端版本为 v1.32.0 或更高。
较早版本会报告 invalid subresource 错误。
在应用补丁后再次检查 Pod 状态：
kubectl get pod pod-level-resize-demo --output=yaml
你应该看到：
spec.resources.requests和spec.resources.limits现在显示cpu: 300m。status.containerStatuses[0].restartCount保持为0，因为 CPU 的resizePolicy为NotRequired。status.containerStatuses[1].restartCount增加到1，表明容器已重启以应用 CPU 变更。 尽管调整是在 Pod 级别应用的，容器 1 仍然发生了重启，这是由于 Pod 级别限制与容器级别策略之间的复杂关系所致。 由于容器 1 未指定显式的 CPU 限制，其底层资源配置（例如 cgroups）隐式地将 Pod 的整体 CPU 限制作为其有效的最大消耗边界。当 Pod 级别的 CPU 限制从 200m 修补为 300m 时，此操作也随之改变了容器 1 上实施的隐式限制。由于容器 1 的resizePolicy对 CPU 显式设置为RestartContainer，kubelet必须重启容器以正确应用底层资源执行机制中的此变更， 这证实了即使在未直接定义容器限制的情况下，更改 Pod 级别限制也能触发容器重启策略。
清理
删除 Pod：
kubectl delete pod pod-level-resize-demo