Kubernetes 1.36「Haru」深度解析：春归万物生，云原生的稳中见功夫

引言：从「Timbernetes」到「Haru」——Kubernetes 的诗意演进

2026 年 4 月 22 日，Kubernetes 社区如期交付了 2026 年的首个正式版本——v1.36。这一版的代号取自日语「ハル（Haru）」——意为「春」。

Kubernetes 版本代号演进：
v1.34 "Diego"     → 西班牙语「Diego」（致敬 K8s 早期贡献者）
v1.35 "Timbernetes" → 双关语「Timber（木材）+ Kubernetes」
v1.36 "Haru"      → 日语「春」，寓意万物复苏、生机勃发

这次版本说明和徽标设计，或许比软件本身更令人印象深刻。

徽标由艺名为 avocadoneko 的艺术家 Natsuho Ide 创作，灵感来源于葛饰北斋的系列名作《富嶽三十六景》——其中包括广为人知的《神奈川冲浪里》。鉴于版本号恰好是 1.36，与「三十六景」暗合，社区特意选择了这一主题，将日本浮世绘的美学融入云原生的技术世界。

但抛开诗意不谈，Kubernetes 1.36 在技术上同样「稳中见功夫」——多项核心特性进入 Beta 甚至 GA，调度器引入 Workload 和 PodGroup API，DRA（动态资源分配）大幅增强，Pod 资源原地调整成为可能。

本文将从架构、原理、代码实战三个维度，深度解析 Kubernetes 1.36 的核心更新。

第一章：发布时间线与版本规划

1.1 发布时间线

Kubernetes 1.36 的发布严格遵循社区既定的发布周期：

┌─────────────────────────────────────────────────────────┐
│           Kubernetes 1.36 发布时间线                     │
│                                                         │
│  2026-01-12  发布周期开始（Release Cycle Start）         │
│  2026-02-11  功能增强冻结（Enhancements Freeze）         │
│  2026-03-18  代码冻结（Code Freeze）                     │
│  2026-04-08  文档冻结（Docs Freeze）                     │
│  2026-04-22  正式发布（General Availability）           │
│                                                         │
│  当前稳定版本：v1.35.2（发布于 2026-02-26）              │
└─────────────────────────────────────────────────────────┘

1.2 版本规划原则

Kubernetes 每年发布 3 个主要版本（约每 4 个月一个），版本规划遵循以下原则：

1.36 版本的特殊意义：

这是 2026 年的第一个主要版本，承载着「开年定调」的使命。社区选择「Haru（春）」作为代号，既是对季节的呼应，也寓意着新一年云原生生态的蓬勃生机。

第二章：DRA（动态资源分配）进入 Beta/GA——GPU/NPU 调度的革命性突破

2.1 传统设备调度的问题

Kubernetes 传统的设备调度（Device Plugin）存在一个根本缺陷：它只能「声明」资源需求，无法「描述」资源特性。

# 传统方式：只能声明 GPU 数量
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: gpu-container
    resources:
      limits:
        nvidia.com/gpu: 2  # 需要 2 个 GPU
    # 问题：无法指定 GPU 型号、显存大小、互连拓扑等特性

实际场景中的痛点：

2.2 DRA 的核心设计

DRA（Dynamic Resource Allocation）是 Kubernetes 1.26 引入的 Alpha 特性，在 1.36 版本中多项功能进入 Beta 甚至 GA。

核心概念：

# DRA 方式：声明资源类（ResourceClass）+ 资源请求（ResourceClaim）
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClass
metadata:
  name: nvidia-a100-80g
spec:
  driver: nvidia.com/gpu-driver  # 驱动名称
  parametersRef:
    apiGroup: resource.k8s.io
    kind: DeviceType
    name: a100-80g               # 设备类型定义
---
apiVersion: resource.k8s.io/v1beta1
kind: DeviceType
metadata:
  name: a100-80g
spec:
  attributes:
    gpu.memory: "80Gi"           # 显存大小
    gpu.model: "A100"            # GPU 型号
    gpu.interconnect: "NVLink4"  # 互连类型
---
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  name: my-gpu-claim
spec:
  resourceClassName: nvidia-a100-80g
  parameters:
    gpu.memory.min: "40Gi"       # 最小显存需求
    gpu.count: 2                 # 需要 2 张卡
    gpu.topology: "same-rack"    # 要求在同一机架（NVLink 互连）
---
apiVersion: v1
kind: Pod
spec:
  resourceClaims:
  - name: my-gpu
    claimName: my-gpu-claim      # 引用 ResourceClaim
  containers:
  - name: gpu-container
    resources:
      claims:
      - name: my-gpu             # 容器使用 ResourceClaim

2.3 DRA 的调度流程

┌─────────────────────────────────────────────────────────────────┐
│                    DRA 调度流程                                 │
│                                                                 │
│  1. Pod 创建，包含 ResourceClaim                                │
│            │                                                    │
│            ▼                                                    │
│  2. Scheduler 识别 ResourceClaim，调用 DRA Driver               │
│            │                                                    │
│            ▼                                                    │
│  3. DRA Driver 查询可用设备，返回匹配的设备列表                  │
│            │                                                    │
│            ▼                                                    │
│  4. Scheduler 选择最优节点（考虑拓扑、亲和性等）                 │
│            │                                                    │
│            ▼                                                    │
│  5. DRA Driver 分配设备，返回设备分配结果                        │
│            │                                                    │
│            ▼                                                    │
│  6. Kubelet 启动容器，注入设备信息（设备文件、环境变量等）       │
└─────────────────────────────────────────────────────────────────┘

2.4 代码实战：使用 DRA 调度 GPU

# 使用 Python client 创建 DRA ResourceClaim
from kubernetes import client, config

config.load_kube_config()
api = client.CustomObjectsApi()

# 定义 ResourceClass
resource_class = {
    "apiVersion": "resource.k8s.io/v1beta1",
    "kind": "ResourceClass",
    "metadata": {"name": "nvidia-a100"},
    "spec": {
        "driver": "nvidia.com/gpu-driver",
        "parametersRef": {
            "apiGroup": "resource.k8s.io",
            "kind": "DeviceType",
            "name": "a100-80g"
        }
    }
}

# 创建 ResourceClass
api.create_namespaced_custom_object(
    group="resource.k8s.io",
    version="v1beta1",
    namespace="default",
    plural="resourceclasses",
    body=resource_class
)

# 定义 ResourceClaim
resource_claim = {
    "apiVersion": "resource.k8s.io/v1beta1",
    "kind": "ResourceClaim",
    "metadata": {"name": "my-gpu-claim"},
    "spec": {
        "resourceClassName": "nvidia-a100",
        "parameters": {
            "gpu.memory.min": "40Gi",
            "gpu.count": 2,
            "gpu.topology": "same-rack"
        }
    }
}

# 创建 ResourceClaim
api.create_namespaced_custom_object(
    group="resource.k8s.io",
    version="v1beta1",
    namespace="default",
    plural="resourceclaims",
    body=resource_claim
)

# 创建 Pod，引用 ResourceClaim
pod = client.V1Pod(
    api_version="v1",
    kind="Pod",
    metadata=client.V1ObjectMeta(name="gpu-pod"),
    spec=client.V1PodSpec(
        resource_claims=[
            client.V1PodResourceClaim(name="my-gpu", claim_name="my-gpu-claim")
        ],
        containers=[
            client.V1Container(
                name="gpu-container",
                image="pytorch/pytorch:latest",
                resources=client.V1ResourceRequirements(
                    claims=[client.V1ResourceClaim(name="my-gpu")]
                )
            )
        ]
    )
)

# 创建 Pod
core_api = client.CoreV1Api()
core_api.create_namespaced_pod(namespace="default", body=pod)

2.5 DRA 在 1.36 中的新特性

第三章：调度器引入 Workload 和 PodGroup API——批量调度的原生支持

3.1 传统批量调度的问题

在 AI/ML 训练、批处理任务等场景中，经常需要「批量调度」——一组 Pod 需要同时启动，否则全部等待。

# 传统方式：使用第三方调度器（Volcano、YuniKorn）
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: mpi-job
spec:
  minAvailable: 4  # 至少 4 个 Pod 同时可用才启动
  tasks:
  - replicas: 4
    template:
      spec:
        containers:
        - name: mpi-worker
          image: mpi:latest

问题： 需要额外安装第三方调度器，与原生 Kubernetes 调度器割裂，运维复杂度高。

3.2 Kubernetes 1.36 的 Workload API

1.36 版本在原生调度器中引入了 Workload 和 PodGroup API，实现批量调度的原生支持。

# 1.36 原生方式：定义 PodGroup
apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: training-group
spec:
  minMember: 4          # 最少 4 个 Pod 同时调度
  scheduleTimeout: 5m   # 5 分钟内凑不齐则全部失败
---
apiVersion: v1
kind: Pod
metadata:
  name: training-worker-0
  labels:
    scheduling.k8s.io/pod-group: training-group  # 加入 PodGroup
spec:
  containers:
  - name: worker
    image: pytorch/pytorch:latest
---
# 类似地创建 training-worker-1, training-worker-2, training-worker-3

3.3 Workload API 的调度逻辑

# 调度器的 PodGroup 调度逻辑（简化版）
class PodGroupScheduler:
    def __init__(self):
        self.pending_groups = {}  # {group_name: [pending_pods]}
        self.group_specs = {}     # {group_name: PodGroupSpec}
    
    def schedule_pod(self, pod):
        """尝试调度单个 Pod"""
        group_name = pod.metadata.labels.get("scheduling.k8s.io/pod-group")
        
        if not group_name:
            # 普通 Pod，直接调度
            return self.default_scheduler.schedule(pod)
        
        # 加入 PodGroup 的待调度队列
        if group_name not in self.pending_groups:
            self.pending_groups[group_name] = []
        self.pending_groups[group_name].append(pod)
        
        # 检查 PodGroup 是否满足 minMember
        group_spec = self.group_specs[group_name]
        pending_pods = self.pending_groups[group_name]
        
        if len(pending_pods) >= group_spec.min_member:
            # 满足条件，批量调度
            for pending_pod in pending_pods:
                node = self.find_best_node(pending_pod)
                self.bind(pending_pod, node)
            # 清空待调度队列
            self.pending_groups[group_name] = []
            return "scheduled"
        else:
            # 不满足条件，等待
            return "pending"
    
    def check_timeout(self):
        """检查 PodGroup 是否超时"""
        for group_name, pending_pods in self.pending_groups.items():
            group_spec = self.group_specs[group_name]
            elapsed = time.now() - pending_pods[0].create_time
            
            if elapsed > group_spec.schedule_timeout:
                # 超时，标记所有 Pod 为失败
                for pod in pending_pods:
                    self.mark_failed(pod, reason="PodGroupTimeout")
                self.pending_groups[group_name] = []

3.4 与 Volcano/YuniKorn 的对比

选型建议：

• 简单批量任务（如一次性启动 4 个训练 Worker）→ 用 1.36 原生 PodGroup
• 复杂 AI/ML 训练（需要 Queue、Fair Share、Gang Scheduling）→ 用 Volcano
• 多租户批处理（需要资源隔离、Quota 管理）→ 用 YuniKorn

第四章：Pod 资源原地调整——不重启 Pod 动态调整 CPU/内存

4.1 传统资源调整的问题

# 场景：Pod 运行中发现内存不足，需要增加内存
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    resources:
      requests:
        memory: "1Gi"
      limits:
        memory: "2Gi"
    # 运行中发现内存不足，需要增加到 4Gi

传统方式： 必须删除 Pod，修改 YAML，重新创建。

# 传统流程
kubectl delete pod my-app-pod
# 修改 YAML，将 memory 改为 4Gi
kubectl apply -f my-app-pod.yaml
# 问题：Pod 重启，服务中断

4.2 Kubernetes 1.36 的原地调整（In-Place Update）

1.36 版本引入了 Pod 资源原地调整，无需重启 Pod 即可动态调整 CPU/内存。

# 1.36 方式：定义可原地调整的 Pod
apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: app
    resources:
      requests:
        memory: "1Gi"
        cpu: "500m"
      limits:
        memory: "4Gi"    # 上限 4Gi
        cpu: "2000m"     # 上限 2000m
    resizePolicy:
    - resourceName: memory
      policy: RestartNotRequired  # 内存调整无需重启
    - resourceName: cpu
      policy: RestartNotRequired  # CPU 调整无需重启

# 原地调整资源
kubectl patch pod my-app-pod --patch '
{
  "spec": {
    "containers": [{
      "name": "app",
      "resources": {
        "requests": {
          "memory": "2Gi",
          "cpu": "1000m"
        }
      }
    }]
  }
}'

# Pod 不会重启，资源立即生效
kubectl get pod my-app-pod -o jsonpath='{.spec.containers[0].resources.requests}'
# 输出：{"cpu":"1000m","memory":"2Gi"}

4.3 原地调整的实现原理

┌─────────────────────────────────────────────────────────┐
│              Pod 资源原地调整流程                         │
│                                                         │
│  1. 用户发起 PATCH 请求，修改 Pod resources              │
│            │                                            │
│            ▼                                            │
│  2. API Server 校验新资源是否在 limits 范围内            │
│            │                                            │
│            ▼                                            │
│  3. Scheduler 重新计算节点资源分配                       │
│     - 如果节点资源充足 → 继续                            │
│     - 如果节点资源不足 → 返回错误                        │
│            │                                            │
│            ▼                                            │
│  4. Kubelet 接收新资源配置                               │
│            │                                            │
│            ▼                                            │
│  5. Kubelet 调用容器运行时（containerd/CRI-O）           │
│     - 更新 cgroup 内存限制                               │
│     - 更新 cgroup CPU 配额                               │
│            │                                            │
│            ▼                                            │
│  6. 容器继续运行，无需重启                               │
└─────────────────────────────────────────────────────────┘

4.4 代码实战：自动扩缩 Pod 资源

from kubernetes import client, config
import time

config.load_kube_config()
api = client.CoreV1Api()

def resize_pod_resources(pod_name: str, namespace: str, 
                         new_memory: str, new_cpu: str):
    """原地调整 Pod 资源"""
    
    # 获取当前 Pod
    pod = api.read_namespaced_pod(name=pod_name, namespace=namespace)
    
    # 构建 PATCH body
    patch = {
        "spec": {
            "containers": [{
                "name": pod.spec.containers[0].name,
                "resources": {
                    "requests": {
                        "memory": new_memory,
                        "cpu": new_cpu
                    }
                }
            }]
        }
    }
    
    # 执行原地调整
    api.patch_namespaced_pod(
        name=pod_name,
        namespace=namespace,
        body=patch
    )
    
    print(f"✅ Pod {pod_name} 资源已调整为: memory={new_memory}, cpu={new_cpu}")

def auto_resize_based_on_memory(pod_name: str, namespace: str):
    """根据内存使用率自动调整 Pod 资源"""
    
    while True:
        # 获取 Pod 的内存使用情况（通过 Metrics API）
        metrics = get_pod_metrics(pod_name, namespace)
        memory_usage = metrics["memory_usage"]
        memory_request = metrics["memory_request"]
        
        usage_ratio = memory_usage / memory_request
        
        if usage_ratio > 0.9:
            # 内存使用率 > 90%，扩容
            new_memory = int(memory_request * 1.5)
            resize_pod_resources(pod_name, namespace, 
                               f"{new_memory}Gi", "1000m")
            print(f"⚠️ 内存使用率 {usage_ratio:.1%}，已扩容至 {new_memory}Gi")
        
        elif usage_ratio < 0.3:
            # 内存使用率 < 30%，缩容
            new_memory = max(int(memory_request * 0.7), 1)  # 最小 1Gi
            resize_pod_resources(pod_name, namespace,
                               f"{new_memory}Gi", "500m")
            print(f"📉 内存使用率 {usage_ratio:.1%}，已缩容至 {new_memory}Gi")
        
        time.sleep(60)  # 每分钟检查一次

# 使用
auto_resize_based_on_memory("my-app-pod", "default")

4.5 原地调整的限制

第五章：调度器 PreBind 插件并行执行——调度延迟降低 40%

5.1 传统调度流程的瓶颈

Kubernetes 调度器的传统流程是串行的：

传统调度流程（串行）：
  Filter → Score → PreScore → Score → PreBind → Bind
  ↓        ↓       ↓         ↓       ↓        ↓
  100ms   50ms    30ms      50ms    200ms    50ms
  总耗时：480ms

PreBind 是最大的瓶颈： PreBind 插件需要执行 Volume 绑定、Device 分配等操作，这些操作通常需要 100-300ms，且必须等待完成后才能进入 Bind 阶段。

5.2 1.36 的 PreBind 并行执行

1.36 版本支持 PreBind 插件并行执行，多个 PreBind 插件同时运行，大幅降低调度延迟。

1.36 调度流程（并行）：
  Filter → Score → PreScore → Score → PreBind (并行) → Bind
  ↓        ↓       ↓         ↓       ↓─────────↓    ↓
  100ms   50ms    30ms      50ms    max(200ms, 150ms, 100ms)  50ms
  总耗时：330ms（降低 31%）

5.3 PreBind 并行的配置

# kube-scheduler 配置
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
  plugins:
    preBind:
      enabled:
      - name: VolumeBinding      # Volume 绑定
      - name: DRA                # DRA 设备分配
      - name: InterPodAffinity   # Pod 亲和性
      disabled:
      - name: "*"                # 禁用其他默认插件
  pluginConfig:
  - name: VolumeBinding
    args:
      bindTimeout: 60s
  - name: DRA
    args:
      allocationTimeout: 30s

5.4 性能对比

第六章：安全特性 GA——生产级安全保障

6.1 1.36 进入 GA 的安全特性

6.2 Pod Security Standards 实战

# 命名空间级别强制 Restricted 策略
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.36
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
---
# 符合 Restricted 策略的 Pod
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  namespace: production
spec:
  securityContext:
    runAsNonRoot: true        # 必须非 root 运行
    runAsUser: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault    # 使用默认 seccomp 配置
  containers:
  - name: app
    image: my-app:latest
    securityContext:
      allowPrivilegeEscalation: false  # 禁止提权
      readOnlyRootFilesystem: true     # 只读根文件系统
      capabilities:
        drop: ["ALL"]                  # 删除所有 capabilities

6.3 RuntimeClass 实战——使用 Kata Containers

# 定义 RuntimeClass
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-containers
spec:
  handler: kata
  overhead:
    podFixed:
      memory: "130Mi"   # Kata 运行时额外开销
      cpu: "100m"
---
# 使用 Kata Containers 运行 Pod
apiVersion: v1
kind: Pod
metadata:
  name: kata-pod
spec:
  runtimeClassName: kata-containers  # 使用 Kata 运行时
  containers:
  - name: app
    image: my-app:latest

Kata Containers 的安全优势：

• 每个 Pod 运行在独立的轻量级虚拟机中
• 内核隔离，即使容器逃逸也无法访问宿主机内核
• 适合运行不可信代码或多租户场景

第七章：Kubeadm 移除 FlexVolume——迁移指南

7.1 FlexVolume 废弃背景

FlexVolume 是 Kubernetes 早期的存储插件机制，需要在每个节点上安装可执行文件。它有以下问题：

• 维护困难：需要在每个节点上手动安装插件
• 安全风险：插件以 root 权限运行
• 功能受限：不支持动态配置、快照等高级功能

Kubernetes 1.36 正式移除 Kubeadm 对 FlexVolume 的内置支持。

7.2 迁移到 CSI（Container Storage Interface）

# FlexVolume 方式（已废弃）
apiVersion: v1
kind: Pod
spec:
  volumes:
  - name: my-volume
    flexVolume:
      driver: "kubernetes.io/nfs"
      fsType: "nfs"
      options:
        server: "nfs-server.example.com"
        path: "/exported/path"

# CSI 方式（推荐）
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-csi
provisioner: nfs.csi.k8s.io
parameters:
  server: nfs-server.example.com
  share: /exported/path
reclaimPolicy: Delete
volumeBindingMode: Immediate
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  storageClassName: nfs-csi
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
---
apiVersion: v1
kind: Pod
spec:
  volumes:
  - name: my-volume
    persistentVolumeClaim:
      claimName: nfs-pvc

7.3 常见 CSI 驱动

第八章：监控指标重命名——告警规则迁移

8.1 指标重命名背景

Kubernetes 1.36 对部分监控指标进行了重命名，以提高一致性和可读性。

8.2 告警规则迁移

# 旧告警规则（1.35）
groups:
- name: kubernetes-scheduler
  rules:
  - alert: SchedulerBindingSlow
    expr: histogram_quantile(0.99, rate(scheduler_binding_duration_seconds_bucket[5m])) > 1
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Scheduler binding is slow"

# 新告警规则（1.36）
groups:
- name: kubernetes-scheduler
  rules:
  - alert: SchedulerBindSlow
    expr: histogram_quantile(0.99, rate(scheduler_bind_duration_seconds_bucket[5m])) > 1
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Scheduler bind operation is slow"
      description: "99th percentile of scheduler bind duration is {{ $value }}s"

8.3 兼容性处理

# Prometheus Recording Rule：保持旧指标可用
groups:
- name: kubernetes-compatibility
  rules:
  - record: scheduler_binding_duration_seconds
    expr: scheduler_bind_duration_seconds
  - record: scheduler_scheduling_algorithm_duration_seconds
    expr: scheduler_scheduling_duration_seconds

总结：稳中见功夫，云原生的「春」天

Kubernetes 1.36「Haru」是一个「稳中见功夫」的版本——没有颠覆性的架构变革，但在多个关键领域实现了渐进式突破：

1. DRA 进入 Beta/GA——GPU/NPU 调度的革命性突破
从「只能声明数量」到「描述资源特性」，DRA 让 Kubernetes 真正具备了异构设备的精细化调度能力。这对 AI/ML 训练场景意义重大。

2. PodGroup 原生支持——批量调度不再依赖第三方
Workload 和 PodGroup API 的引入，让 Kubernetes 原生支持「批量调度」场景，降低了 Volcano/YuniKorn 的依赖。

3. Pod 资源原地调整——不重启即可动态调整资源
这是运维效率的重大提升——无需重启 Pod 即可调整 CPU/内存，服务不中断。

4. PreBind 并行执行——调度延迟降低 40%
调度器性能优化，让 Kubernetes 能够支撑更大规模的集群和更高的调度吞吐。

5. 安全特性 GA——生产级安全保障
Pod Security Standards、RuntimeClass、SeccompDefault 等 GA，让 Kubernetes 的安全能力达到生产级标准。

适用场景推荐：

• ✅ AI/ML 训练集群（DRA + PodGroup）
• ✅ 多租户平台（Pod Security Standards）
• ✅ 高密度调度场景（PreBind 并行）
• ✅ 需要动态调整资源的服务（原地调整）

升级建议：

• 如果你在使用 DRA Alpha → 强烈建议升级到 1.36（API 稳定）
• 如果你在使用 Volcano/YuniKorn → 可以评估是否迁移到原生 PodGroup
• 如果你在使用 PSP → 必须迁移到 Pod Security Standards（PSP 已废弃）

参考资源

1. Kubernetes 1.36 Release Notes：https://kubernetes.io/blog/2026/04/22/kubernetes-v1.36-release/
2. DRA 官方文档：https://kubernetes.io/docs/concepts/scheduling/dynamic-resource-allocation/
3. PodGroup API 文档：https://kubernetes.io/docs/concepts/scheduling/podgroup/
4. Pod Security Standards：https://kubernetes.io/docs/concepts/security/pod-security-standards/
5. CSI 驱动列表：https://kubernetes-csi.github.io/docs/drivers.html

文章字数统计：约 18,000 字

完