Kubernetes v1.34：Pod 级别资源升级至 Beta
我很高兴代表 Kubernetes 社区宣布，Pod 级别资源特性已在 Kubernetes v1.34 发行版中升级至 Beta 并默认启用！ 这一重要里程碑为定义和管理 Pod 的资源分配引入了新的灵活性。 这种灵活性来自于能够为整个 Pod 指定 CPU 和内存资源。 Pod 级别资源可以与容器级别的规约组合使用，从而表达应用所需的准确资源请求和限制。
Pod 级别资源规约
直到最近，适用于 Pod 的资源规约主要还是在各个容器级别定义。 虽然这种方式有效，但有时需要在单个 Pod 的多个容器之间重复设置或仔细计算资源需求。 作为一项 Beta 特性，Kubernetes 允许你在 Pod 级别指定 CPU、内存和大页内存资源。 这意味着你现在可以为整个 Pod 定义资源请求和限制，从而更容易地共享资源； 在不需要细粒度按容器管理这些资源的场景下，也不必再逐个容器进行管理。
为什么 Pod 级别规约很重要？
此特性通过在 Pod 和容器两个级别提供灵活的资源管理，增强了 Kubernetes 中的资源管理能力。
它提供了一种整合式的资源声明方式，减少了进行细致的按容器管理的需要， 对于包含多个容器的 Pod 尤其有用。
Pod 级别资源使 Pod 内的容器能够彼此共享未使用的资源， 从而促进 Pod 内资源的高效利用。 例如，它可以防止边车容器成为性能瓶颈。 过去，某个边车（例如日志代理或服务网格代理）达到自身 CPU 限制时可能会被限流， 并拖慢整个 Pod，即使主应用容器还有大量空闲 CPU。 使用 Pod 级别资源后，边车和主容器可以共享 Pod 的资源预算， 确保在流量高峰期间平稳运行：要么整个 Pod 被限流，要么所有容器都能工作。
当同时指定 Pod 级别和容器级别资源时，Pod 级别的请求和限制优先。 这为你和集群管理员提供了一种强有力的方式来对 Pod 实施整体资源边界。
对于调度而言，如果显式定义了 Pod 级别请求，调度器会使用该特定值来寻找合适的节点， 而不是使用各个容器请求的聚合值。 在运行时，Pod 级别限制会作为所有容器组合资源用量的硬性上限。 关键在于，这个 Pod 级别限制是绝对的执行边界； 即使各个容器限制之和更高，总资源消耗也永远不能超过 Pod 级别限制。
Pod 级别资源在影响 Pod 的服务质量（QoS）类时优先。
对于运行在 Linux 节点上的 Pod，内存不足（OOM）分数调整计算会同时考虑 Pod 级别和容器级别的资源请求。
Pod 级别资源被设计为与现有 Kubernetes 功能兼容，确保可以顺畅集成到你的工作流中。
如何为整个 Pod 指定资源
使用 PodLevelResources
特性门控时，要求所有集群组件
（包括控制平面和每个节点）均为 Kubernetes v1.34 或更高版本。
此特性门控处于 Beta 阶段，并在 v1.34 中默认启用。
示例清单
你可以直接在 Pod 规约清单中通过整个 Pod 的 resources 字段指定 CPU、内存和 HugePages 资源。
下面的示例展示了一个在 Pod 级别定义了 CPU 和内存请求及限制的 Pod：
apiVersion: v1
kind: Pod
metadata:
name: pod-resources-demo
namespace: pod-resources-example
spec:
# Pod 规约级别的 'resources' 字段定义了此 Pod 内所有容器合计的整体资源预算。
resources: # Pod 级别资源
# 'limits' 指定 Pod 可使用的最大资源量。
# Pod 中所有容器限制之和不能超过这些值。
limits:
cpu: "1" # 整个 Pod 不能使用超过 1 个 CPU 核心。
memory: "200Mi" # 整个 Pod 不能使用超过 200 MiB 内存。
# 'requests' 指定为 Pod 保证的最小资源量。
# Kubernetes 调度器会使用此值来寻找具有足够容量的节点。
requests:
cpu: "1" # 调度后，Pod 保证可获得 1 个 CPU 核心。
memory: "100Mi" # 调度后，Pod 保证可获得 100 MiB 内存。
containers:
- name: main-app-container
image: nginx
...
# 此容器没有指定资源请求或限制。
- name: auxiliary-container
image: fedora
command: ["sleep", "inf"]
...
# 此容器没有指定资源请求或限制。
在此示例中，pod-resources-demo Pod 整体请求 1 个 CPU 和 100 MiB 内存，
并被限制为最多使用 1 个 CPU 和 200 MiB 内存。
其中的容器将在这些整体 Pod 级别约束下运行，如下一节所述。
与容器级别资源请求或限制的交互
当同时指定 Pod 级别和容器级别资源时，Pod 级别请求和限制优先。 这意味着节点会基于 Pod 级别规约来分配资源。
设想一个包含两个容器的 Pod，其中定义了 Pod 级别的 CPU 和内存请求及限制， 并且只有一个容器具有自己的显式资源定义：
apiVersion: v1
kind: Pod
metadata:
name: pod-resources-demo
namespace: pod-resources-example
spec:
resources:
limits:
cpu: "1"
memory: "200Mi"
requests:
cpu: "1"
memory: "100Mi"
containers:
- name: main-app-container
image: nginx
resources:
requests:
cpu: "0.5"
memory: "50Mi"
- name: auxiliary-container
image: fedora
command: [ "sleep", "inf"]
# 此容器没有指定资源请求或限制。
Pod 级别限制：Pod 级别限制（cpu: "1", memory: "200Mi"）为整个 Pod 建立了绝对边界。 其所有容器消耗的资源总和会受此上限约束，不能超过该上限。
资源共享和突增：容器可以动态借用任何未使用的容量， 只要 Pod 的聚合用量仍在整体限制之内，就可以按需突增。
Pod 级别请求：Pod 级别请求（cpu: "1", memory: "100Mi"）是整个 Pod 的基础资源保证。 该值会影响调度器的放置决策，并表示在节点级别资源竞争期间 Pod 可以依赖的最小资源量。
容器级别请求：容器级别请求会在 Pod 的保证预算内创建一个优先级体系。 因为
main-app-container有显式请求（cpu: "0.5", memory: "50Mi"）， 所以在资源压力下，相比没有这种显式声明的auxiliary-container， 它会优先获得自己的资源份额。
限制
首先，Kubernetes v1.34（及更早版本）不支持对 Pod 级别资源进行原地调整大小。 尝试修改运行中 Pod 的 _Pod 级别_资源限制或请求会导致错误：调整大小请求会被拒绝。 v1.34 中 Pod 级别资源的实现重点在于允许初始声明适用于整个 Pod的整体资源包络。 这与原地 Pod 调整大小不同；后者（尽管名称可能有些误导）允许你在运行中的 Pod 内动态调整_容器_资源请求和限制，并且可能无需重启容器。 原地调整大小也尚未成为稳定特性；它在 v1.33 发行版中升级至 Beta。
只能在 Pod 级别指定 CPU、内存和大页内存资源。
Windows Pod 不支持 Pod 级别资源。 如果 Pod 规约显式以 Windows 为目标（例如设置
spec.os.name: "windows"）， API 服务器会在验证步骤拒绝该 Pod。 如果 Pod 没有显式标记为 Windows，但被调度到 Windows 节点（例如通过nodeSelector）， 该 Windows 节点上的 kubelet 会在其准入过程中拒绝该 Pod。拓扑管理器、内存管理器和 CPU 管理器不会基于 Pod 级别资源对 Pod 和容器进行对齐，因为这些资源管理器目前不支持 Pod 级别资源。
开始使用并提供反馈
准备探索 Pod 级别资源 特性了吗？
你需要一个运行 1.34 或更高版本的 Kubernetes 集群。
请记得在控制平面和所有节点上启用 PodLevelResources
特性门控。
随着此特性在 Beta 阶段继续演进，你的反馈非常宝贵。 请通过标准 Kubernetes 沟通渠道报告任何问题或分享你的使用经验：