Kubernetes 1.36「Haru」深度解析：70 项增强背后的安全加固与 AI 工作负载革命

Kubernetes 1.36 代号「Haru」（春），2026 年 4 月 22 日正式发布。本文从架构原理、核心特性、代码实战、性能基准四个维度，深度拆解这次「稳中见功夫」的版本——User Namespaces 四年磨一剑 GA、可变准入策略原生替代 Webhook、工作负载感知抢占解决分布式训练部分抢占故障、分片列表监听破解超大规模集群性能瓶颈。

目录

1. 时代背景：为什么 1.36 是「收口」版本
2. 版本全景：70 项增强功能的数状图
3. 安全加固：从 User Namespaces 到可变准入策略
4. AI 工作负载：DRA 增强与工作负载感知抢占
5. 调度器革命：Gang 调度 API Beta 与原地垂直扩缩容
6. API 可扩展性：分片列表与分片监听流
7. 存储增强：卷组快照 GA 与声明式验证
8. 代码实战：从零部署 1.36 新特性
9. 性能基准：Benchmark 数据与资源开销对比
10. 升级指南：废弃功能与迁移路径
11. 总结展望：Kubernetes 的下一个五年

1. 时代背景：为什么 1.36 是「收口」版本

1.1 Kubernetes 的「青春期」结束了

2026 年，Kubernetes 迎来诞生后的第 12 个年头。从 2014 年 Google 开源至今，Kubernetes 已经完成了「统一容器编排市场」的历史使命。根据 CNCF 2025 年度调查报告，生产环境中 Kubernetes 的采用率已达到 96%（受访者中），成为事实上的云原生操作系统。

但在这个数字的背后，隐藏着一个不容忽视的现实：

• 版本碎片化严重：大量集群停留在 1.24~1.28 之间，新特性落地滞后
• 安全配置复杂：Pod 安全策略（PSP）废弃后，替代方案碎片化
• AI 工作负载支持不足：GPU 资源调度依赖厂商插件，缺乏统一抽象
• 超大规模集群性能瓶颈：etcd 负载、API Server 监听流成为扩展天花板

1. 36 版本的 Release Lead Ryota Sawada（来自日本社区）将代号定为「Haru」（春），寓意是「过去几年埋下的种子，终于抽出新叶」。

1.2 1.36 的三个关键词

与 1.35「Timbernetes」（世界树）的架构扩展主题不同，1.36 没有引入颠覆性的新范式，而是把过去三四年社区反复打磨的能力正式交付到用户手中。

2. 版本全景：70 项增强功能的数状图

1. 36 共包含 70 项增强功能（部分统计为 71 项，含文档修复），按成熟度分布如下：

Stable (GA):  18 项  ████████████████████
Beta:         25 项  ████████████████████████████████
Alpha:        25 项  ████████████████████████████████
Deprecated:   若干    ███

2.1 按 SIG 分类的核心特性

3. 安全加固：从 User Namespaces 到可变准入策略

3.1 User Namespaces（用户命名空间）—— 四年磨一剑

3.1.1 问题：容器 root 用户的安全隐患

传统容器运行时（Docker、containerd）中，容器内的 root（UID 0）默认映射到宿主机的 root（UID 0）。这意味着如果攻击者突破了容器隔离（例如通过内核漏洞），就能以 root 权限控制宿主机。

# 传统容器：容器内 root = 宿主机 root
docker run --rm -it ubuntu:22.04 id
# uid=0(root) gid=0(root) groups=0(root)

# 在容器内看到的 UID 0，在宿主机上也是 UID 0
# 容器内执行 `kill -9 <宿主机进程PID>` 可能成功！

3.1.2 User Namespaces 的原理

User Namespaces 是 Linux 内核的一项隔离机制，它允许将容器内的用户 ID 映射到宿主机上的非特权用户 ID 范围。

容器内 UID/GID 命名空间          宿主机真实 UID/GID
┌─────────────────┐              ┌─────────────────┐
│ UID 0 (root)   │  ──映射──►  │ UID 100000     │
│ UID 1 (daemon) │  ──映射──►  │ UID 100001     │
│ UID 65534(nobody)│ ──映射──► │ UID 165534    │
└─────────────────┘              └─────────────────┘

即使容器内的进程认为自己是以 root 身份运行，在宿主机上它实际上只是一个普通用户（UID 100000+），无法对宿主机系统造成实质性损害。

3.1.3 Kubernetes 中的实现

User Namespaces 在 Kubernetes 中通过 PodSpec 的 hostUsers 字段控制：

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  hostUsers: false  # 启用 User Namespace 隔离
  containers:
  - name: app
    image: nginx:1.27
    securityContext:
      runAsNonRoot: true
      runAsUser: 101  # nginx 用户（容器内）

关键细节：

• hostUsers: false 需要容器运行时支持（containerd 2.0+、CRI-O 1.30+）
• 内核版本要求：Linux 5.12+（完整的 User Namespace 功能支持）
• 与 runAsNonRoot 配合使用，提供深度防御

3.1.4 性能开销测试

根据社区 Benchmark，User Namespaces 带来的性能开销主要在文件系统 UID/GID 转换上：

结论：CPU 和网络开销几乎可以忽略，文件系统操作有约 15% 的开销，在绝大多数场景下可接受。

3.2 Mutating Admission Policies（可变准入策略）—— Webhook 的原生替代

3.2.1 传统 Mutating Webhook 的痛点

在 1.36 之前，如果需要对 Pod 进行动态修改（例如注入 sidecar、设置默认资源请求），必须部署独立的 Mutating Webhook 服务器：

API Server → HTTP 调用 → Mutating Webhook Service → 返回修改后的对象

问题：

1. 延迟：每次 Pod 创建都要额外 HTTP 往返（通常 10~50ms）
2. 可用性：Webhook 服务宕机导致整个集群 Pod 创建失败
3. 复杂性：需要维护额外的 Deployment、Service、TLS 证书

3.2.2 Mutating Admission Policies 的原理

1. 36 中，Mutating Admission Policies 正式 GA。它允许使用 CEL（Common Expression Language） 定义变更逻辑，作为原生 Kubernetes 对象存储：

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: inject-sidecar-policy
spec:
  webhookName: ""
  rules:
  - operations: ["CREATE"]
    resources: ["pods"]
  failurePolicy: Fail
  mutations:
  - patchType: JSONPatch
    jsonPatch:
      expression: |
        [JSONPatch{
          op: "add",
          path: "/spec/containers/-",
          value: {
            "name": "istio-proxy",
            "image": "istio/proxyv2:1.25.0",
            "ports": [{"containerPort": 15001}]
          }
        }]

优势对比：

3.2.3 CEL 表达式实战

CEL 是一种轻量级表达式语言，语法类似 Go：

// 条件判断：只为特定 namespace 注入
variables.namespace.startsWith('prod-')

// 数值计算：设置默认 CPU 请求
has(object.spec.containers[0].resources.requests.cpu) ? 
  object.spec.containers[0].resources.requests.cpu : 
  "100m"

// 字符串处理：生成 sidecar 名称
object.metadata.name + "-sidecar"

3.3 Fine-Grained Kubelet API Authorization —— 最小权限访问控制

3.3.1 问题：nodes/proxy 权限过于宽泛

在 1.36 之前，任何需要访问 Kubelet HTTPS API 的工具（例如 kubectl logs、kubectl exec、监控 Agent）都需要授予 nodes/proxy 权限：

# 传统方式：监控 Agent 需要过大权限
apiGroups: [""]
resources: ["nodes/proxy"]
verbs: ["get", "create"]  # 可以访问任意节点的任意端口！

nodes/proxy 允许访问 Kubelet 的所有 HTTPS API（包括 /run、/exec、/logs 等敏感端点），违反了最小权限原则。

3.3.2 1.36 的细分权限

1. 36 引入了细粒度的 Kubelet API 授权，将权限拆分为多个独立资源：

# 只读监控：只需 logs 权限
apiGroups: [""]
resources: ["nodes/log"]
verbs: ["get"]

# 调试工具：需要 exec 权限
apiGroups: [""]
resources: ["nodes/exec"]
verbs: ["create"]

# 端口转发：需要 portForward 权限
apiGroups: [""]
resources: ["nodes/portForward"]
verbs: ["create"]

迁移示例：Prometheus Node Exporter 只需要 nodes/log 和 nodes/metrics，不再需要 nodes/proxy。

3.4 SELinux Volume Labels GA —— 告别递归文件重标记

3.4.1 传统 SELinux 的 Pod 启动延迟问题

在 SELinux 强制模式下，容器访问的卷需要正确的 SELinux 标签（container_t、container_ro_t 等）。传统实现方式是在 Pod 启动前递归重标记整个卷：

# 传统方式：递归 chcon（可能耗时数分钟）
chcon -R -t container_t /var/lib/kubelet/pods/<pod-id>/volumes/...

对于大型 PV（TB 级别），这个操作可能导致 Pod 启动延迟达到数分钟。

3.4.2 1.36 的解决方案：挂载时标签

1. 36 支持在卷挂载时通过 mount -o context=XYZ 选项直接设置 SELinux 标签，无需递归重标记：

apiVersion: v1
kind: Pod
metadata:
  name: selinux-app
spec:
  securityContext:
    seLinuxOptions:
      level: "s0:c123,c456"  # MCS 标签
  containers:
  - name: app
    image: nginx:1.27
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: selinux-pvc

性能对比（基于 100GB PV 测试）：

4. AI 工作负载：DRA 增强与工作负载感知抢占

4.1 背景：为什么 AI 工作负载需要特殊调度

2026 年，AI/ML 训练任务已成为 Kubernetes 集群中资源消耗最大的工作负载类型。一个典型的分布式训练任务具有以下特点：

• 多 Pod 协同：8 个 Pod 分别对应 8 张 GPU，需要同时调度
• 资源异构：不同 Pod 可能需要不同型号的 GPU（H100、A100、L40S）
• 部分抢占故障：如果 8 个 Pod 中 7 个被调度，1 个被抢占，整个训练任务无法推进

传统 Kubernetes 调度器以单个 Pod 为调度单元，无法很好地处理上述场景。

4.2 DRA（Dynamic Resource Allocation）增强

DRA 是 Kubernetes 用于管理复杂硬件资源（GPU、FPGA、专用网卡）的框架。1.36 中，多项 DRA 增强进入 Beta 并默认启用。

4.2.1 DRA 可分区设备（Partitionable Devices）—— Beta

传统 GPU 设备插件（例如 NVIDIA Device Plugin）以整卡为分配单元：

# 传统方式：必须申请整张 GPU
resources:
  limits:
    nvidia.com/gpu: 1  # 一张 H100，无论实际利用率

在模型推理场景下，一张 H100 的算力可能只利用了 20%，其余 80% 被浪费。

DRA 可分区设备允许将一张 GPU 逻辑分区给多个 Pod：

apiVersion: resource.k8s.io/v1beta2
kind: ResourceClaim
metadata:
  name: gpu-partition-claim
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: nvidia.com-h100-partitionable
      selectors:
      - cel:
          expression: "device.attributes['nvidia.com/slice-count'] >= 2"
    config:
    - instances:
      - model:
          name: compute-slice
          slices: 2  # 将一张 GPU 分为 2 个计算切片

4.2.2 DRA 设备污点与容忍（Device Taints and Tolerations）—— Beta

类似 Node Taints，DRA 设备污点允许标记「有问题」的硬件设备：

# 标记有 ECC 错误的 GPU
apiVersion: resource.k8s.io/v1beta2
kind: DeviceClass
metadata:
  name: nvidia-gpu
spec:
  deviceTaints:
  - key: hardware/ecc-error
    effect: NoSchedule
    message: "GPU has uncorrectable ECC errors"

4.2.3 DRA 可消耗容量（Consumable Capacity）—— GA

某些设备（例如 GPU）不仅有「设备本身」，还有「配套资源」（显存、L2 Cache）。DRA 可消耗容量允许将显存作为可消耗资源单独分配：

apiVersion: resource.k8s.io/v1beta2
kind: ResourceClaim
metadata:
  name: gpu-with-vram
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: nvidia.com-h100
  consumableCapacity:
  - name: vram
    quantity: "80Gi"  # 申请 80GB 显存（H100 总共 80GB）

4.3 Workload-Aware Preemption（工作负载感知抢占）—— Alpha

4.3.1 问题：分布式训练的「部分抢占故障模式」

假设一个 8-GPU 分布式训练任务正在运行，此时集群中来了更高优先级的任务。传统调度器可能抢占其中 1 个 GPU Pod：

训练任务 Pod 状态（抢占前）：
Pod-0: Running (GPU 0)
Pod-1: Running (GPU 1)
...
Pod-7: Running (GPU 7)

抢占后：
Pod-0: Running (GPU 0)
Pod-1: Pending  ← 被抢占
...
Pod-7: Running (GPU 7)

结果：7 个 Pod 在运行，但训练无法推进（需要全部 8 个 Pod 协同）

这种「部分抢占」导致资源浪费（7 个 Pod 占着 GPU 但无法工作）和任务停滞。

4.3.2 Workload-Aware Preemption 的原理

1. 36 引入的 Workload-Aware Preemption 将 PodGroup 视为一个整体抢占单元：

调度器决策流程：
1. 检查高优先级任务是否需要 8 个 GPU
2. 检查低优先级 PodGroup 是否占用 8 个 GPU
3. 如果抢占 1~7 个 Pod 无法满足高优先级任务 → 不执行部分抢占
4. 只有当可以抢占整个 PodGroup（8 个 Pod）并立即调度高优先级任务时 → 执行抢占

配置方式（Alpha 阶段需要通过 Feature Gate 启用）：

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: training-job-group
spec:
  scheduleTimeoutSeconds: 300
  workloadPriorityClassName: high-priority

4.3.3 Gang Scheduling API —— Beta

Gang Scheduling（组调度）确保一个任务的所有 Pod 要么全部调度，要么全部不调度：

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: distributed-training
spec:
  minAvailable: 8  # 需要 8 个 Pod 全部就绪
---
apiVersion: v1
kind: Pod
metadata:
  name: training-pod-0
  labels:
    pod-group: distributed-training
spec:
  containers:
  - name: train
    image: pytorch:2.5
    resources:
      limits:
        nvidia.com/gpu: 1

4.4 Mutable Pod Resources for Suspended Jobs（暂停作业的 Pod 可变资源）—— Beta

4.4.1 场景：队列系统中的动态资源调整

在 AI 训练队列系统中，作业可能被暂停（suspended）等待资源。传统实现中，调整已暂停作业的资源请求需要：

1. 删除所有 Pod
2. 修改 Job 定义
3. 重新创建 Pod

这个过程耗时且可能导致检查点丢失。

4.4.2 1.36 的解决方案

1. 36 允许直接修改已暂停作业的 Pod 资源请求，无需删除 Pod：

apiVersion: batch/v1
kind: Job
metadata:
  name: training-job
spec:
  suspended: true  # 作业已暂停
  template:
    spec:
      containers:
      - name: train
        resources:
          requests:
            nvidia.com/gpu: 1
            cpu: "4"
            memory: "32Gi"
          limits:
            nvidia.com/gpu: 1
            cpu: "4"
            memory: "32Gi"

当集群资源变化时，队列控制器可以直接修改 requests/limits，然后恢复作业：

# 修改已暂停作业的资源请求
kubectl patch job training-job --type='json' \
  -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value": "8"},
       {"op": "replace", "path": "/spec/template/spec/containers/0/resources/limits/cpu", "value": "8"}]'

# 恢复作业
kubectl patch job training-job -p '{"spec": {"suspended": false}}'

5. 调度器革命：Gang 调度 API Beta 与原地垂直扩缩容

5.1 In-Place Vertical Scaling for Pod-Level Resources（Pod 级资源原地垂直扩缩容）—— Beta

5.1.1 传统垂直扩缩容的问题

在 1.36 之前，修改 Pod 的 CPU/内存资源需要删除并重建 Pod：

# 传统方式：修改 Deployment，触发滚动更新
kubectl set resources deployment/my-app --limits=cpu=2,memory=4Gi
# 这会导致 Pod 重启，可能中断服务

对于状态ful 应用（数据库、消息队列），这种重启是不可接受的。

5.1.2 1.36 的原地垂直扩缩容

1. 36 支持不重启容器直接修改 Pod 的 resource requests/limits：

apiVersion: v1
kind: Pod
metadata:
  name: database
  annotations:
    resize.kubernetes.io/allow-resize: "true"  # 允许原地调整
spec:
  containers:
  - name: postgres
    image: postgres:17
    resources:
      requests:
        cpu: "2"
        memory: "4Gi"
      limits:
        cpu: "4"
        memory: "8Gi"

调整方式：

# 原地增加内存限制（不重启 Pod！）
kubectl patch pod database --type='json' \
  -p='[{"op": "replace", "path": "/spec/containers/0/resources/limits/memory", "value": "16Gi"}]'

内核要求：需要 cgroup v2 支持（Linux 5.10+）。

5.1.3 新事件类型：ResizeDeferred

如果节点资源不足，无法立即执行扩缩容，Kubernetes 会推迟操作并生成 ResizeDeferred 事件：

kubectl describe pod database
# ...
# Events:
#   Type     Reason           Age   From     Message
#   ----     ------           ----  ----     -------
#   Warning  ResizeDeferred   10s   kubelet  Node has insufficient memory, retry after 5m0s

当节点资源充足时，Kubelet 会自动重试完成扩缩容。

5.2 Memory QoS via cgroup v2（内存服务质量）—— Beta

5.2.1 问题：容器之间的内存争用

在 Kubernetes 节点上，多个 Pod 可能同时面临内存压力。传统 Linux 内核的 OOM Killer 采用「先到先杀」策略，可能误杀关键业务 Pod。

5.2.2 Memory QoS 的原理

Memory QoS 通过 cgroup v2 的 memory.min、memory.low、memory.high、memory.max 接口，提供分层的内存保护：

apiVersion: v1
kind: Pod
metadata:
  name: critical-app
spec:
  containers:
  - name: app
    image: my-app:1.0
    resources:
      requests:
        memory: "4Gi"
      limits:
        memory: "8Gi"
  # 通过 annotation 设置 Memory QoS 参数
  annotations:
    memory.qos.kubernetes.io/enable: "true"
    memory.qos.kubernetes.io/min: "2Gi"   # 保护 2Gi 不被回收
    memory.qos.kubernetes.io/low: "4Gi"    # 低于 4Gi 时降低回收优先级
    memory.qos.kubernetes.io/high: "6Gi"   # 超过 6Gi 时积极回收

保护级别：

6. API 可扩展性：分片列表与分片监听流

6.1 问题：超大规模集群的 API Server 瓶颈

在拥有 5000+ 节点的集群中，API Server 的监听流（Watch）可能成为性能瓶颈：

单个 kube-controller-manager 需要监听：
- Pod 变化（所有命名空间）
- Node 变化（所有节点）
- Endpoint 变化（所有服务）

每个监听器通过一个 HTTP 长连接接收所有更新 → 单连接成为瓶颈

6.2 Sharded Lists and Watches（分片列表与监听）—— Alpha

1. 36 引入了分片机制，允许将单个资源的监听流拆分到多个连接中：

# API Server 配置（Alpha 阶段，需要 Feature Gate）
apiVersion: apiserver.config.k8s.io/v1
kind: EgressSelectorConfiguration
egressSelections:
- name: pods
  connection:
    type: HTTP2
    shardCount: 4  # 将 Pod 监听流拆分为 4 个分片

每个分片只接收部分对象的更新（基于对象 UID 的哈希），从而降低单个连接的负载。

性能数据（基于 10000 节点集群测试）：

7. 存储增强：卷组快照 GA 与声明式验证

7.1 Volume Group Snapshots（卷组快照）—— GA

7.1.1 场景：分布式存储的一致性快照

在分布式数据库（例如 Cassandra、MongoDB）中，数据分布在多个 PV 上。传统快照方式对每个 PV 独立创建快照，可能无法保证跨卷的一致性。

7.1.2 卷组快照的原理

卷组快照允许为多个 PVC 同时创建崩溃一致性快照：

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshot
metadata:
  name: db-group-snapshot
spec:
  sourceSelectors:
  - matchLabels:
      app: cassandra
  volumeGroupSnapshotClassName: csi-aws-group-snapshotter

恢复时，可以从卷组快照一次性恢复所有 PVC：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cassandra-data-0
spec:
  dataSource:
    kind: VolumeGroupSnapshotContent
    name: db-group-snapshot-content
    apiGroup: snapshot.storage.k8s.io
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

7.2 Declarative Validation with validation-gen —— GA

7.2.1 问题：手写 Validation 代码容易出错

在开发自定义资源（CRD）时，需要编写 Validate 函数确保对象字段合法性：

// 传统方式：手写 Validate 函数
func ValidateMyResource(obj *MyResource) field.ErrorList {
    errs := field.ErrorList{}
    if obj.Spec.Replicas < 0 {
        errs = append(errs, field.Invalid(path, obj.Spec.Replicas, "must be >= 0"))
    }
    // ... 数百行相似代码
    return errs
}

7.2.2 validation-gen 的原理

validation-gen 允许通过 Go struct tag 声明验证规则，自动生成 Validate 函数：

// +k8s:validation-gen=true
type MyResourceSpec struct {
    // +k8s:validation:minimum=0
    // +k8s:validation:maximum=100
    Replicas int32 `json:"replicas"`

    // +k8s:validation:required
    // +k8s:validation:pattern=^[a-z]+$
    Name string `json:"name"`

    // +k8s:validation:enum=auto,manual
    Mode string `json:"mode"`
}

运行 controller-gen validation:paths=./... 后，会自动生成 zz_generated.validation.go 文件，包含完整的验证逻辑。

8. 代码实战：从零部署 1.36 新特性

8.1 环境准备：部署 Kubernetes 1.36 集群

8.1.1 使用 kubeadm 部署（要求 containerd 2.0+）

# 添加 Kubernetes 1.36 仓库
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.36/deb/ /
EOF

# 安装 kubeadm、kubelet、kubectl
sudo apt update
sudo apt install -y kubeadm=1.36.0-1.1 kubelet=1.36.0-1.1 kubectl=1.36.0-1.1

# 初始化控制平面
sudo kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --kubernetes-version=v1.36.0 \
  --feature-gates="UserNamespacesSupport=true,MutatingAdmissionPolicy=true"

8.1.2 启用 1.36 新特性 Feature Gates

编辑 /etc/kubernetes/manifests/kube-apiserver.yaml，添加 Feature Gates：

spec:
  containers:
  - command:
    - kube-apiserver
    - --feature-gates=UserNamespacesSupport=true,MutatingAdmissionPolicy=true,ShardedListsAndWatches=true
    # ... 其他参数

8.2 实战 1：部署启用 User Namespaces 的 Pod

# user-namespace-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: user-ns-demo
spec:
  hostUsers: false  # 启用 User Namespace
  containers:
  - name: app
    image: nginx:1.27
    securityContext:
      runAsNonRoot: true
      runAsUser: 101
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    emptyDir: {}

部署并验证：

kubectl apply -f user-namespace-demo.yaml

# 检查 User Namespace 是否生效
kubectl exec user-ns-demo -- id
# uid=101(nginx) gid=101(nginx) groups=101(nginx)

# 在宿主机上查看真实 UID
sudo cat /proc/$(kubectl get pod user-ns-demo -o jsonpath='{.status.containerStatuses[0].containerID}' | sed 's|containerd://||')/status
# 真实 UID 应该是 100000+ 范围

8.3 实战 2：使用 Mutating Admission Policy 注入 Sidecar

# mutating-policy-sidecar.yaml
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: inject-logging-sidecar
spec:
  paramKind:
    apiVersion: admissionregistration.k8s.io/v1
    kind: MutatingAdmissionPolicyBinding
  rules:
  - operations: ["CREATE"]
    resources: ["pods"]
    scope: "*"
  mutations:
  - patchType: JSONPatch
    jsonPatch:
      expression: |
        [JSONPatch{
          op: "add",
          path: "/spec/containers/-",
          value: {
            "name": "log-collector",
            "image": "fluentd:v1.17",
            "volumeMounts": [{"name": "varlog", "mountPath": "/var/log"}]
          }
        }]
---
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicyBinding
metadata:
  name: inject-logging-sidecar-binding
spec:
  policyName: inject-logging-sidecar
  paramRef:
    name: default

部署并测试：

kubectl apply -f mutating-policy-sidecar.yaml

# 创建测试 Pod
kubectl run test --image=nginx:1.27

# 检查 Sidecar 是否自动注入
kubectl get pod test -o jsonpath='{.spec.containers[*].name}'
# 应该输出：test log-collector

8.4 实战 3：配置 Gang Scheduling for 分布式训练

# gang-scheduling-training.yaml
apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: pytorch-training-group
  namespace: default
spec:
  minAvailable: 4  # 需要 4 个 Pod 全部调度成功
  scheduleTimeoutSeconds: 600
---
apiVersion: batch/v1
kind: Job
metadata:
  name: pytorch-training
spec:
  parallelism: 4
  completions: 4
  template:
    metadata:
      labels:
        pod-group: pytorch-training-group
    spec:
      restartPolicy: Never
      containers:
      - name: trainer
        image: pytorch/pytorch:2.5-cuda12.1-cudnn9-runtime
        resources:
          requests:
            nvidia.com/gpu: 1
            cpu: "4"
            memory: "32Gi"
          limits:
            nvidia.com/gpu: 1
            cpu: "4"
            memory: "32Gi"
        command:
        - torchrun
        - --nproc_per_node=1
        - --nnodes=4
        - --master_addr=pytorch-training-0
        - --master_port=29500
        - train.py

部署后观察调度行为：

kubectl get pods -l pod-group=pytorch-training-group -w
# 应该看到 4 个 Pod 同时变为 Running（而不是逐个调度）

8.5 实战 4：原地垂直扩缩容

# in-place-vpa-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: database
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
      annotations:
        resize.kubernetes.io/allow-resize: "true"
    spec:
      containers:
      - name: postgres
        image: postgres:17
        env:
        - name: POSTGRES_PASSWORD
          value: "secret"
        resources:
          requests:
            cpu: "1"
            memory: "2Gi"
          limits:
            cpu: "2"
            memory: "4Gi"

部署后，模拟资源不足场景，执行原地扩容：

# 查看当前资源
kubectl get pod -l app=postgres -o jsonpath='{.items[0].spec.containers[0].resources}'

# 原地增加内存限制（不重启！）
kubectl patch pod $(kubectl get pod -l app=postgres -o jsonpath='{.items[0].metadata.name}') \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/containers/0/resources/limits/memory", "value": "8Gi"}]'

# 验证 Pod 是否重启
kubectl get pod -l app=postgres -o jsonpath='{.items[0].status.containerStatuses[0].restartCount}'
# 应该输出：0（未重启）

9. 性能基准：Benchmark 数据与资源开销对比

9.1 调度器性能

9.2 API Server 性能（10000 节点集群）

9.3 安全特性开销

10. 升级指南：废弃功能与迁移路径

10.1 已移除的功能

10.1.1 gitRepo 卷插件

原因：存在安全漏洞（允许攻击者在节点上以 root 权限执行代码）。

迁移方案：使用 initContainer + emptyDir：

# 旧方式（已移除）
volumes:
- name: git-repo
  gitRepo:
    repository: "https://github.com/example/repo.git"
    revision: "main"

# 新方式
initContainers:
- name: git-clone
  image: alpine/git:latest
  command: ["git", "clone", "https://github.com/example/repo.git", "/repo"]
  volumeMounts:
  - name: git-repo
    mountPath: /repo
containers:
- name: app
  image: my-app:1.0
  volumeMounts:
  - name: git-repo
    mountPath: /app/repo
volumes:
- name: git-repo
  emptyDir: {}

10.1.2 kube-proxy IPVS 模式

原因：维护成本高，且 IPVS 内核模块在Linux 6.8+ 中被标记为 deprecated。

迁移方案：切换到 iptables 模式或 nftables 模式：

# 修改 kube-proxy ConfigMap
kubectl edit configmap kube-proxy -n kube-system
# 将 mode: "ipvs" 改为 mode: "iptables"

10.1.3 Ingress NGINX 退役

原因：维护团队解散，安全漏洞无法及时修复。

迁移方案：使用 gateway-api + envoy-gateway 或 nginx-ingress（F5 官方维护版本）：

# Gateway API 示例
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
spec:
  gatewayClassName: envoy-gateway
  listeners:
  - name: http
    port: 80
    protocol: HTTP

10.2 升级前检查清单

1. 检查是否已使用废弃 API：

   kubectl get pods --all-namespaces -o json | \
     jq '.items[] | select(.spec.volumes[]?.gitRepo != null) | .metadata.name'
   

2. 备份 etcd：

   ETCDCTL_API=3 etcdctl snapshot save snapshot.db
   

3. 使用 kubeadm upgrade plan 检查兼容性：

   sudo kubeadm upgrade plan
   

4. 逐节点滚动升级：

   # 标记节点为不可调度
   kubectl cordon node-1
   
   # 驱逐 Pod
   kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data
   
   # 升级 kubelet 和 kubectl
   sudo apt update && sudo apt install -y kubelet=1.36.0-1.1 kubectl=1.36.0-1.1
   
   # 重启 kubelet
   sudo systemctl restart kubelet
   
   # 恢复节点可调度
   kubectl uncordon node-1
   

11. 总结展望：Kubernetes 的下一个五年

11.1 1.36 的历史定位

Kubernetes 1.36 「Haru」是一个承上启下的版本：

• 承上：将过去三四年社区反复打磨的能力（User Namespaces、DRA、Gang Scheduling）正式交付 GA/Beta
• 启下：为下一个五年的技术方向奠定基础（AI 工作负载原生支持、超大规模集群性能优化、安全默认配置强化）

11.2 值得关注的下一代特性（Alpha 阶段）

1. DRA 原生资源映射（将 GPU 显存、NPU 算力映射为原生 CPU/内存类资源）
2. 拓扑感知工作负载调度（TAS）（基于 NUMA、PCIe 拓扑优化调度决策）
3. 分片列表与监听（破解超大规模集群的 API Server 瓶颈）
4. 工作负载感知抢占（解决分布式训练的部分抢占故障）

11.3 对开发者的建议

1. 立即采用：User Namespaces、Mutating Admission Policies、Fine-Grained Kubelet API Authorization
2. 测试环境验证：DRA 可分区设备、Gang Scheduling、In-Place Vertical Scaling
3. 规划迁移：从 Ingress NGINX 迁移到 Gateway API，从 IPVS 切换到 iptables/nftables

参考资源

• Kubernetes 1.36 Release Notes
• User Namespaces Design Proposal
• Dynamic Resource Allocation (DRA) Documentation
• Mutating Admission Policies GA Blog
• CNCF 2025 Annual Survey Report

作者：程序员茄子 | 发布时间：2026 年 6 月 | 字数：约 18000 字

本文深入分析了 Kubernetes 1.36 的核心特性，涵盖安全加固、AI 工作负载优化、调度器革命、API 可扩展性等多个维度，并提供了完整的代码实战示例和性能基准数据。