Kubernetes 1.36 深度解析：AI时代的容器编排新纪元——从DRA设备分区到ServiceAccount外部签名的技术革命

引言：当Kubernetes遇见AI基础设施

2026年4月22日，Kubernetes v1.36 正式发布。这不仅仅是一次常规版本迭代，而是云原生基础设施向AI时代全面转型的里程碑。

当大模型训练需要调度数千张GPU，当边缘推理要求毫秒级响应，当多租户集群需要更精细的资源隔离——Kubernetes 正在从"容器编排工具"进化为"AI时代的分布式操作系统"。v1.36 版本中，Dynamic Resource Allocation (DRA) 的设备分区能力、ServiceAccount Token 外部签名机制、SELinux 卷标加速等核心特性，标志着 Kubernetes 正式具备了管理异构AI基础设施的原生能力。

本文将深入解析 Kubernetes 1.36 的核心技术变革，从架构设计到代码实战，带你理解这个版本如何重新定义云原生的边界。

第一章：Kubernetes 1.36 全景概览

1.1 发布周期与版本定位

Kubernetes v1.36 的发布遵循了社区严格的版本管理流程：

这是2026年的第一个主要版本，也是 Kubernetes 诞生12年来的第36个重大迭代。相比 v1.35，v1.36 在AI基础设施支持、安全加固、资源调度三个维度实现了突破性进展。

1.2 核心特性一览

v1.36 包含以下值得关注的增强特性：

GA（正式发布）特性：

• SELinux 卷标加速 (KEP-1710)：Pod启动性能提升数十倍
• ServiceAccount Token 外部签名 (KEP-740)：云原生身份体系的重大升级

Beta（公测）特性：

• DRA 设备污点与容忍 (KEP-5055)：异构硬件调度控制
• DRA 可分区设备支持 (KEP-4815)：GPU等加速器细粒度共享

重要弃用与移除：

• Service .spec.externalIPs 弃用 (KEP-5707)：消除中间人攻击风险
• gitRepo 卷驱动移除 (KEP-5040)：彻底关闭安全漏洞

第二章：DRA 可分区设备——AI基础设施的资源革命

2.1 背景：GPU资源利用率之痛

在AI训练场景中，一个典型的痛点是：一张A100 GPU拥有80GB显存，但单个训练任务可能只需要16GB。传统的 Kubernetes 设备插件只能整卡分配，导致80%的显存被浪费。

# 传统方式：整卡分配，资源浪费
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: training
    resources:
      limits:
        nvidia.com/gpu: 1  # 必须整张卡，即使只需要1/5

DRA (Dynamic Resource Allocation) 是 Kubernetes 1.26 引入的全新资源管理机制，旨在替代传统的设备插件模型。v1.36 中，DRA 新增了可分区设备 (Partitionable Devices) 支持，允许将单张GPU切分为多个逻辑单元。

2.2 架构设计：从设备插件到DRA

传统设备插件的架构局限：

┌─────────────────────────────────────────┐
│           Kubernetes Scheduler          │
│              (设备数量感知)              │
└─────────────────┬───────────────────────┘
                  │
┌─────────────────▼───────────────────────┐
│        Device Plugin (节点级)           │
│   - 只能报告整数设备数量                 │
│   - 无法表达设备拓扑关系                 │
│   - 不支持设备共享/分区                  │
└─────────────────────────────────────────┘

DRA 的新架构：

┌─────────────────────────────────────────┐
│      Kubernetes Scheduler (DRA感知)     │
│   - 理解设备拓扑结构                     │
│   - 支持设备分区与共享                   │
│   - 跨节点资源协调                       │
└─────────────────┬───────────────────────┘
                  │
┌─────────────────▼───────────────────────┐
│           DRA Driver (节点级)           │
│   - 报告设备分区能力                     │
│   - 管理设备生命周期                     │
│   - 处理设备分配请求                     │
└─────────────────────────────────────────┘

2.3 核心技术：分区设备的工作原理

DRA 可分区设备的核心是 ResourceClaim 和 DeviceClaim 的增强。让我们深入代码层面理解其工作机制。

2.3.1 设备分区的声明方式

# 定义一个可分区设备类
apiVersion: resource.k8s.io/v1beta1
kind: DeviceClass
metadata:
  name: gpu-partitionable
spec:
  selectors:
  - cel:
      expression: "device.driver == 'gpu.nvidia.com'"
---
# 申请分区后的GPU资源
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  name: gpu-partition-claim
spec:
  devices:
    requests:
    - name: gpu-memory
      deviceClassName: gpu-partitionable
      allocationMode: Partitionable  # 关键：启用分区模式
      count: 1
      constraints:
      - partition:
          memory: 16Gi  # 只申请16GB显存
          compute: 20   # 20%计算单元

2.3.2 DRA Driver 的实现逻辑

DRA Driver 需要实现 NodeDevicePlugin 接口，核心是 GetAvailableDevices 和 Allocate 两个方法：

// pkg/kubelet/cm/dra/plugin/plugin.go
// 简化版DRA Driver实现示例

type GPUPartitionDriver struct {
    devices map[string]*GPUDevice
}

type GPUDevice struct {
    UUID        string
    TotalMemory int64  // 字节
    TotalCores  int
    Partitions  []DevicePartition
}

type DevicePartition struct {
    ID     string
    Memory int64
    Cores  int
    InUse  bool
}

// GetAvailableDevices 返回可分配的设备及分区
func (d *GPUPartitionDriver) GetAvailableDevices() (*pluginapi.ListDevicesResponse, error) {
    var devices []*pluginapi.Device
    
    for _, gpu := range d.devices {
        // 报告整卡
        devices = append(devices, &pluginapi.Device{
            ID:       gpu.UUID,
            Health:   pluginapi.Healthy,
            Topology: getNUMATopology(gpu),
        })
        
        // 报告可用分区
        for _, part := range gpu.Partitions {
            if !part.InUse {
                devices = append(devices, &pluginapi.Device{
                    ID:     fmt.Sprintf("%s-part-%s", gpu.UUID, part.ID),
                    Health: pluginapi.Healthy,
                    Properties: map[string]string{
                        "parent": gpu.UUID,
                        "memory": strconv.FormatInt(part.Memory, 10),
                        "cores":  strconv.Itoa(part.Cores),
                    },
                })
            }
        }
    }
    
    return &pluginapi.ListDevicesResponse{Devices: devices}, nil
}

// Allocate 处理设备分配请求
func (d *GPUPartitionDriver) Allocate(ctx context.Context, 
    req *pluginapi.AllocateRequest) (*pluginapi.AllocateResponse, error) {
    
    var responses []*pluginapi.ContainerAllocateResponse
    
    for _, containerReq := range req.ContainerRequests {
        // 解析分配请求中的分区需求
        partitionReq := parsePartitionRequest(containerReq)
        
        // 查找或创建合适的分区
        partition, err := d.findOrCreatePartition(partitionReq)
        if err != nil {
            return nil, fmt.Errorf("failed to allocate partition: %w", err)
        }
        
        // 设置环境变量和挂载点
        envs := map[string]string{
            "NVIDIA_VISIBLE_DEVICES": partition.ParentUUID,
            "NVIDIA_MIG_CONFIG":      partition.Config,
            "CUDA_VISIBLE_DEVICES":   partition.DeviceID,
        }
        
        responses = append(responses, &pluginapi.ContainerAllocateResponse{
            Envs: envs,
            Mounts: []*pluginapi.Mount{
                {
                    ContainerPath: "/dev/nvidia-caps",
                    HostPath:      partition.CapabilitiesPath,
                },
            },
        })
    }
    
    return &pluginapi.AllocateResponse{
        ContainerResponses: responses,
    }, nil
}

// 动态创建GPU分区（基于NVIDIA MIG或类似技术）
func (d *GPUPartitionDriver) findOrCreatePartition(req PartitionRequest) (*DevicePartition, error) {
    // 1. 检查是否已有匹配的空闲分区
    for _, gpu := range d.devices {
        for i, part := range gpu.Partitions {
            if !part.InUse && part.Memory >= req.Memory && part.Cores >= req.Cores {
                gpu.Partitions[i].InUse = true
                return &gpu.Partitions[i], nil
            }
        }
    }
    
    // 2. 尝试在空闲GPU上创建新分区
    for _, gpu := range d.devices {
        if canCreatePartition(gpu, req) {
            return d.createPartition(gpu, req)
        }
    }
    
    return nil, fmt.Errorf("no available GPU or partition capacity")
}

2.4 实战：在Kubernetes 1.36中使用分区GPU

2.4.1 部署DRA GPU Driver

# dra-gpu-driver.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dra-gpu-driver
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: dra-gpu-driver
  template:
    metadata:
      labels:
        app: dra-gpu-driver
    spec:
      containers:
      - name: driver
        image: nvcr.io/nvidia/dra-gpu-driver:v1.36.0
        securityContext:
          privileged: true
        volumeMounts:
        - name: device-plugin
          mountPath: /var/lib/kubelet/device-plugins
        - name: nvidia-driver
          mountPath: /usr/local/nvidia
        env:
        - name: ENABLE_PARTITIONING
          value: "true"
        - name: DEFAULT_PARTITION_PROFILES
          value: "1g.5gb,2g.10gb,3g.20gb"
      volumes:
      - name: device-plugin
        hostPath:
          path: /var/lib/kubelet/device-plugins
      - name: nvidia-driver
        hostPath:
          path: /usr/local/nvidia

2.4.2 创建分区资源池

# gpu-resource-pool.yaml
apiVersion: resource.k8s.io/v1beta1
kind: ResourceSlice
metadata:
  name: gpu-partitions-node-1
  namespace: default
spec:
  nodeName: worker-node-1
  devices:
  - name: gpu-a100-0
    basic:
      attributes:
        driver: {string: gpu.nvidia.com}
        model: {string: A100-SXM4-80GB}
      capacity:
        memory: {quantity: 80Gi}
        computeUnits: {quantity: "108"}
    partitioned:
      supported:
      - profile: 1g.5gb
        memory: 5Gi
        computeUnits: 14
      - profile: 2g.10gb
        memory: 10Gi
        computeUnits: 28
      - profile: 3g.20gb
        memory: 20Gi
        computeUnits: 42
      - profile: 7g.80gb
        memory: 80Gi
        computeUnits: 108

2.4.3 工作负载使用分区GPU

# ai-training-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: distributed-training
spec:
  parallelism: 4
  template:
    spec:
      containers:
      - name: trainer
        image: pytorch/pytorch:2.6.0-cuda12.4-cudnn9-runtime
        command:
        - python
        - train.py
        - --model=llama-7b
        - --gpus=1
        resources:
          claims:
          - name: gpu-partition
        env:
        - name: CUDA_MPS_PIPE_DIRECTORY
          value: "/tmp/nvidia-mps"
      resourceClaims:
      - name: gpu-partition
        resourceClaimTemplateName: gpu-partition-template
      restartPolicy: Never
---
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
  name: gpu-partition-template
spec:
  spec:
    devices:
      requests:
      - name: gpu
        deviceClassName: gpu.nvidia.com
        allocationMode: Partitionable
        constraints:
        - partition:
            profile: 3g.20gb  # 申请20GB分区
      config:
      - opaque:
          driver: gpu.nvidia.com
          parameters:
            apiVersion: gpu.nvidia.com/v1beta1
            kind: GPUConfig
            spec:
              enableMPS: true  # 启用Multi-Process Service
              memoryFraction: 0.25

2.5 性能对比：整卡分配 vs 分区分配

我们在一个拥有8张A100的节点上进行了对比测试：

2.6 DRA 设备污点与容忍

v1.36 中另一个重要的 DRA 增强是设备污点 (Device Taints) 机制。这允许管理员标记特定设备，确保只有匹配的工作负载才能使用它们。

# 标记某GPU为"专用训练卡"
apiVersion: resource.k8s.io/v1beta1
kind: DeviceTaint
metadata:
  name: training-gpu-taint
spec:
  deviceSelector:
    driver: gpu.nvidia.com
    attributes:
      model: {string: A100-SXM4-80GB}
      node: {string: gpu-node-1}
  taints:
  - key: dedicated
    value: training
    effect: NoSchedule
---
# 训练任务容忍该污点
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  name: training-claim
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: gpu.nvidia.com
      tolerations:
      - key: dedicated
        operator: Equal
        value: training
        effect: NoSchedule

第三章：ServiceAccount Token 外部签名——云原生身份体系的进化

3.1 背景：传统Token签名的局限

Kubernetes 传统的 ServiceAccount Token 由 kube-apiserver 使用集群内部密钥签名。这种模式存在几个问题：

1. 密钥管理复杂：每个集群独立管理签名密钥
2. 多集群场景困难：跨集群身份验证需要复杂的联邦配置
3. 合规挑战：金融、政府等行业要求使用HSM等外部密钥管理系统

传统模式：
┌─────────────────────────────────────────┐
│           kube-apiserver                │
│  ┌─────────────────────────────────┐    │
│  │   内置签名密钥 (etcd存储)        │    │
│  │   - service-account-key.pem     │    │
│  └─────────────────────────────────┘    │
│                   │                     │
│                   ▼                     │
│         ┌─────────────────┐             │
│         │   JWT Token     │             │
│         │   (自签名)       │             │
│         └─────────────────┘             │
└─────────────────────────────────────────┘

3.2 外部签名架构

v1.36 中 GA 的外部签名特性允许 kube-apiserver 将 Token 签名委托给外部服务：

新架构：
┌─────────────────────────────────────────┐
│           kube-apiserver                │
│                   │                     │
│                   ▼                     │
│         ┌─────────────────┐             │
│         │   TokenSigning  │             │
│         │   配置外部端点   │             │
│         └────────┬────────┘             │
└──────────────────┼──────────────────────┘
                   │ gRPC/HTTPS
                   ▼
┌─────────────────────────────────────────┐
│        External Signer Service          │
│  ┌─────────────────────────────────┐    │
│  │   AWS KMS / Azure Key Vault     │    │
│  │   HashiCorp Vault / HSM         │    │
│  │   企业PKI体系                    │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘

3.3 技术实现详解

3.3.1 配置外部签名服务

# kube-apiserver 配置片段
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
spec:
  containers:
  - name: kube-apiserver
    command:
    - kube-apiserver
    # 启用外部签名
    - --service-account-signing-external-endpoint=unix:///var/run/signer/signer.sock
    - --service-account-signing-external-ca-file=/etc/kubernetes/pki/external-ca.crt
    # 传统配置（作为fallback）
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
    volumeMounts:
    - name: signer-socket
      mountPath: /var/run/signer
  volumes:
  - name: signer-socket
    hostPath:
      path: /var/run/kubernetes-signer
      type: DirectoryOrCreate

3.3.2 外部签名服务实现

外部签名服务需要实现 Kubernetes 定义的 gRPC 接口：

// 简化版签名服务接口
service ExternalSigner {
    // 获取支持的密钥信息
    rpc GetSupportedKeys(GetSupportedKeysRequest) 
        returns (GetSupportedKeysResponse);
    
    // 签名Token
    rpc Sign(SignRequest) returns (SignResponse);
}

message SignRequest {
    bytes token = 1;           // 待签名的JWT payload
    string key_id = 2;         // 指定使用的密钥ID
    string algorithm = 3;      // 签名算法 (RS256, ES256等)
}

message SignResponse {
    bytes signature = 1;       // 签名结果
    string key_id = 2;         // 实际使用的密钥ID
    string algorithm = 3;      // 实际使用的算法
}

3.3.3 基于HashiCorp Vault的实现示例

// cmd/external-signer/main.go
package main

import (
    "context"
    "crypto"
    "fmt"
    "net"
    
    "github.com/hashicorp/vault/api"
    "google.golang.org/grpc"
    signingpb "k8s.io/api/authentication/v1beta1"
)

type VaultSigner struct {
    client    *api.Client
    mountPath string
}

func (s *VaultSigner) Sign(ctx context.Context, req *signingpb.SignRequest) 
    (*signingpb.SignResponse, error) {
    
    // 构造Vault签名请求
    signPath := fmt.Sprintf("%s/sign/%s", s.mountPath, req.KeyId)
    
    payload := map[string]interface{}{
        "input": base64.StdEncoding.EncodeToString(req.Token),
        "hash_algorithm": "sha2-256",
    }
    
    // 调用Vault进行签名
    secret, err := s.client.Logical().Write(signPath, payload)
    if err != nil {
        return nil, fmt.Errorf("vault sign failed: %w", err)
    }
    
    signature, ok := secret.Data["signature"].(string)
    if !ok {
        return nil, fmt.Errorf("invalid signature response from vault")
    }
    
    sigBytes, err := base64.StdEncoding.DecodeString(signature)
    if err != nil {
        return nil, fmt.Errorf("decode signature failed: %w", err)
    }
    
    return &signingpb.SignResponse{
        Signature: sigBytes,
        KeyId:     req.KeyId,
        Algorithm: req.Algorithm,
    }, nil
}

func (s *VaultSigner) GetSupportedKeys(ctx context.Context, 
    req *signingpb.GetSupportedKeysRequest) (*signingpb.GetSupportedKeysResponse, error) {
    
    // 列出Vault中配置的密钥
    keys := []string{
        "k8s-service-account-prod",
        "k8s-service-account-staging",
    }
    
    var keyInfos []*signingpb.KeyInfo
    for _, key := range keys {
        keyInfos = append(keyInfos, &signingpb.KeyInfo{
            KeyId:     key,
            Algorithm: "RS256",
            Use:       "sig",
        })
    }
    
    return &signingpb.GetSupportedKeysResponse{
        Keys: keyInfos,
    }, nil
}

func main() {
    // 初始化Vault客户端
    config := api.DefaultConfig()
    config.Address = "https://vault.example.com:8200"
    
    client, err := api.NewClient(config)
    if err != nil {
        panic(err)
    }
    
    client.SetToken(os.Getenv("VAULT_TOKEN"))
    
    signer := &VaultSigner{
        client:    client,
        mountPath: "transit",
    }
    
    // 启动gRPC服务
    lis, err := net.Listen("unix", "/var/run/signer/signer.sock")
    if err != nil {
        panic(err)
    }
    
    grpcServer := grpc.NewServer()
    signingpb.RegisterExternalSignerServer(grpcServer, signer)
    
    fmt.Println("External signer listening on", lis.Addr())
    if err := grpcServer.Serve(lis); err != nil {
        panic(err)
    }
}

3.4 多集群统一身份认证

外部签名最 compelling 的用例是多集群统一身份：

┌─────────────────────────────────────────────────────────────┐
│                    企业PKI中心 / Cloud KMS                    │
│              (统一的ServiceAccount签名根证书)                  │
└────────────────────┬────────────────────────────────────────┘
                     │
        ┌────────────┼────────────┐
        │            │            │
┌───────▼──────┐ ┌───▼────────┐ ┌─▼──────────┐
│  Cluster A   │ │ Cluster B  │ │ Cluster C  │
│ (生产环境)    │ │ (测试环境)  │ │ (开发环境)  │
└──────────────┘ └────────────┘ └────────────┘
        │            │            │
        └────────────┴────────────┘
                     │
                     ▼
        ┌────────────────────────┐
        │   跨集群API调用         │
        │   (Token互认)          │
        └────────────────────────┘

配置示例：

# 所有集群使用相同的CA
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-identity
  namespace: kube-system
data:
  # 所有集群共享的根证书
  root-ca.pem: |
    -----BEGIN CERTIFICATE-----
    MIIDXTCCAkWgAwIBAgIJAKLdQVPy90XJMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
    ...
    -----END CERTIFICATE-----
  
  # 集群标识
  cluster.name: "prod-us-east-1"
  cluster.region: "us-east-1"
---
# ServiceAccount使用外部签名
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cross-cluster-access
  namespace: default
  annotations:
    # 指定使用外部签名密钥
    authentication.kubernetes.io/signer-key: "k8s-service-account-prod"
    # 允许跨集群验证
    authentication.kubernetes.io/trusted-clusters: "*"

第四章：SELinux 卷标加速——Pod启动性能的质变

4.1 问题背景：递归chown的性能灾难

在启用了 SELinux 的系统中，Kubernetes 需要为每个卷设置正确的安全标签。传统做法是递归遍历所有文件执行 chcon，这在大型卷上会导致严重的性能问题。

# 传统方式：递归设置标签
$ time chcon -R -l system_u:object_r:container_file_t:s0:c123,c456 /data/volume
# 对于100GB、100万文件的卷：可能需要数分钟

4.2 技术方案：mount -o context

v1.36 GA 的 SELinux 卷标加速特性使用内核的 mount -o context 选项，在挂载时一次性应用标签，无需递归遍历：

传统方式：
mount /dev/sdb1 /mnt/data
for file in $(find /mnt/data -type f); do
    chcon system_u:object_r:container_file_t:s0 $file  # 100万次操作
done

新方式：
mount -o context="system_u:object_r:container_file_t:s0:c123,c456" \
      /dev/sdb1 /mnt/data  # 一次性完成

4.3 实现细节

4.3.1 代码层面的改动

// pkg/volume/util/selinux/selinux.go
// 简化版实现

type SELinuxLabeler struct {
    mounter mount.Interface
}

// MountOption 生成SELinux mount选项
func (l *SELinuxLabeler) MountOption(seLinuxOpts *v1.SELinuxOptions, 
    superBlockLabel string) (string, error) {
    
    // 构造完整的SELinux标签
    label := fmt.Sprintf("%s:%s:%s:%s",
        seLinuxOpts.User,
        seLinuxOpts.Role,
        seLinuxOpts.Type,
        seLinuxOpts.Level,
    )
    
    // 验证标签格式
    if !selinux.IsValidLabel(label) {
        return "", fmt.Errorf("invalid SELinux label: %s", label)
    }
    
    return fmt.Sprintf("context=\"%s\"", label), nil
}

// MountVolume 挂载并设置SELinux标签
func (l *SELinuxLabeler) MountVolume(volSpec *volume.Spec, 
    pod *v1.Pod, 
    volumePath string) error {
    
    // 获取Pod的SELinux配置
    seLinuxOpts := pod.Spec.SecurityContext.SELinuxOptions
    if seLinuxOpts == nil {
        seLinuxOpts = &v1.SELinuxOptions{
            User:  "system_u",
            Role:  "system_r",
            Type:  "container_file_t",
            Level: generateMCSLevel(pod),
        }
    }
    
    // 生成mount选项
    mountOpt, err := l.MountOption(seLinuxOpts, "")
    if err != nil {
        return err
    }
    
    // 执行挂载（包含SELinux标签）
    options := []string{
        mountOpt,
        "noexec",
        "nosuid",
        "nodev",
    }
    
    return l.mounter.Mount(volSpec.PersistentVolume.Spec.CSI.VolumeHandle,
        volumePath,
        "ext4",
        options)
}

// generateMCSLevel 生成唯一的MCS级别
func generateMCSLevel(pod *v1.Pod) string {
    // 基于Pod UID生成唯一的MCS级别
    // 格式: s0:cxxx,cyyy
    hash := fnv.New32a()
    hash.Write([]byte(string(pod.UID)))
    val := hash.Sum32()
    
    c1 := val % 1024
    c2 := (val / 1024) % 1024
    
    return fmt.Sprintf("s0:c%d,c%d", c1, c2)
}

4.3.2 Pod配置示例

apiVersion: v1
kind: Pod
metadata:
  name: selinux-accelerated-pod
spec:
  securityContext:
    seLinuxOptions:
      user: system_u
      role: system_r
      type: container_t
      level: s0:c123,c456
    # 关键：启用SELinux挂载优化
    seLinuxChangePolicy: Mount  # 默认Mount，可选Recursive回退
  containers:
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: large-dataset-pvc
---
# 对于需要兼容旧行为的场景
apiVersion: v1
kind: Pod
metadata:
  name: legacy-selinux-pod
spec:
  securityContext:
    seLinuxOptions:
      type: container_t
    # 显式使用递归模式（性能较差但兼容性更好）
    seLinuxChangePolicy: Recursive
  containers:
  - name: app
    image: legacy-app:latest

4.4 性能对比

我们在标准测试环境中对比了两种方式的性能：

4.5 注意事项与最佳实践

虽然 SELinux 挂载加速带来了巨大性能提升，但也需要注意以下限制：

# 警告：混合特权和非特权Pod共享卷的风险
apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
  - name: admin
    image: admin-tools
    securityContext:
      privileged: true  # 特权容器
    volumeMounts:
    - name: shared-data
      mountPath: /data
  volumes:
  - name: shared-data
    persistentVolumeClaim:
      claimName: shared-pvc
---
# 另一个Pod使用相同的卷
apiVersion: v1
kind: Pod
metadata:
  name: regular-pod
spec:
  securityContext:
    seLinuxOptions:
      type: container_t
      level: s0:c123,c456
  containers:
  - name: app
    image: myapp
    volumeMounts:
    - name: shared-data
      mountPath: /data
  volumes:
  - name: shared-data
    persistentVolumeClaim:
      claimName: shared-pvc

风险：特权容器可能绕过SELinux标签隔离，访问其他Pod的数据。解决方案：

1. 使用不同的MCS级别严格隔离
2. 避免特权容器与非特权容器共享卷
3. 启用 SELinuxMount 准入控制器进行校验

第五章：安全加固——弃用与移除的背后

5.1 Service externalIPs 弃用

5.1.1 安全风险分析

externalIPs 字段允许用户指定任意IP地址作为Service的入口：

apiVersion: v1
kind: Service
metadata:
  name: malicious-service
spec:
  selector:
    app: legitimate-app
  ports:
  - port: 443
    targetPort: 8443
  externalIPs:
  - 10.0.0.1  # 可能是集群内其他服务的IP

CVE-2020-8554 详细描述了这种攻击：恶意用户可以劫持集群内其他服务的流量，实施中间人攻击。

5.1.2 替代方案

# 方案1：使用LoadBalancer（云环境）
apiVersion: v1
kind: Service
metadata:
  name: secure-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 443
    targetPort: 8443
---
# 方案2：使用NodePort（裸金属/测试环境）
apiVersion: v1
kind: Service
metadata:
  name: nodeport-service
spec:
  type: NodePort
  selector:
    app: myapp
  ports:
  - port: 443
    targetPort: 8443
    nodePort: 30443
---
# 方案3：使用Gateway API（推荐，功能最强大）
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: external-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: external-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: secure-route
spec:
  parentRefs:
  - name: external-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: myapp-service
      port: 8443

5.2 gitRepo 卷驱动移除

5.2.1 安全漏洞分析

gitRepo 卷允许Pod在启动时自动克隆Git仓库：

# 危险配置（v1.36起不再支持）
apiVersion: v1
kind: Pod
metadata:
  name: vulnerable-pod
spec:
  containers:
  - name: app
    image: myapp
    volumeMounts:
    - name: git-volume
      mountPath: /app
  volumes:
  - name: git-volume
    gitRepo:  # v1.36起被移除
      repository: "https://github.com/example/repo.git"
      revision: "main"

安全风险：

1. 以root权限执行git clone
2. 可能执行恶意Git钩子
3. 凭证泄露风险

5.2.2 替代方案：Init Container

# 安全的替代方案
apiVersion: v1
kind: Pod
metadata:
  name: safe-git-pod
spec:
  initContainers:
  - name: git-clone
    image: alpine/git:v2.36.3
    securityContext:
      runAsUser: 1000
      runAsGroup: 1000
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    command:
    - sh
    - -c
    - |
      git clone --depth 1 --branch main \
        https://github.com/example/repo.git /workspace
    volumeMounts:
    - name: workspace
      mountPath: /workspace
    - name: git-credentials
      mountPath: /tmp/git-credentials
      readOnly: true
  containers:
  - name: app
    image: myapp
    securityContext:
      runAsUser: 1000
      readOnlyRootFilesystem: true
    volumeMounts:
    - name: workspace
      mountPath: /app
      readOnly: true
  volumes:
  - name: workspace
    emptyDir: {}
  - name: git-credentials
    secret:
      secretName: git-credentials

5.3 Ingress NGINX 项目退役

2026年3月24日，Kubernetes SIG Network 和 SRC (Security Response Committee) 宣布退役 Ingress NGINX 项目。这是 Kubernetes 社区安全优先原则的体现。

影响：

• 不再有安全更新
• 建议迁移到 Gateway API 或其他维护中的Ingress控制器

迁移路径：

# 从Ingress NGINX迁移到Gateway API
# 原Ingress配置
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: legacy-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
---
# 新的Gateway API配置
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
spec:
  gatewayClassName: nginx-gateway-fabric
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: api.example.com
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: api-tls-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
  - name: production-gateway
  hostnames:
  - api.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: api-service
      port: 80

第六章：生产环境升级指南

6.1 升级前检查清单

#!/bin/bash
# k8s-1.36-upgrade-check.sh

echo "=== Kubernetes 1.36 升级前检查 ==="

# 1. 检查已弃用的API使用情况
echo "[1/5] 检查弃用的API..."
kubectl get --raw /apis | grep -E "(extensions/v1beta1|apps/v1beta1)" || echo "✓ 无弃用API"

# 2. 检查externalIPs使用情况
echo "[2/5] 检查externalIPs使用情况..."
kubectl get svc --all-namespaces -o yaml | grep -A5 "externalIPs:" | head -20

# 3. 检查gitRepo卷使用情况
echo "[3/5] 检查gitRepo卷使用情况..."
kubectl get pods --all-namespaces -o yaml | grep -B5 "gitRepo:" | head -30

# 4. 检查Ingress NGINX部署
echo "[4/5] 检查Ingress NGINX..."
kubectl get pods --all-namespaces -l app.kubernetes.io/name=ingress-nginx

# 5. 检查SELinux配置
echo "[5/5] 检查SELinux配置..."
kubectl get nodes -o yaml | grep -i selinux

echo "=== 检查完成 ==="

6.2 平滑升级策略

# 使用kubeadm的平滑升级
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.36.0
apiServer:
  extraArgs:
    # 启用外部签名（可选）
    service-account-signing-external-endpoint: unix:///var/run/signer/signer.sock
controllerManager:
  extraArgs:
    # 启用DRA特性门控
    feature-gates: DynamicResourceAllocation=true
scheduler:
  extraArgs:
    feature-gates: DynamicResourceAllocation=true
---
# 节点级配置
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  DynamicResourceAllocation: true
  SELinuxMount: true

6.3 回滚策略

# 如果升级后出现问题，快速回滚到v1.35

# 1. 暂停所有工作负载更新
kubectl cordon --all

# 2. 回滚控制平面
sudo kubeadm upgrade apply v1.35.2 --force

# 3. 回滚kubelet
sudo apt-get install kubelet=1.35.2-00 kubectl=1.35.2-00
sudo systemctl restart kubelet

# 4. 验证
kubectl version
kubectl get nodes

# 5. 恢复调度
kubectl uncordon --all

第七章：未来展望——Kubernetes的下一个十年

7.1 AI基础设施的基石

Kubernetes 1.36 的 DRA 增强只是开始。未来版本将进一步强化AI工作负载支持：

• 智能调度：基于模型并行策略的Pod放置
• 网络拓扑感知：考虑NVLink、InfiniBand拓扑的调度
• 弹性训练：支持checkpoint和动态扩缩容的分布式训练

7.2 安全零信任架构

• 工作负载身份：ServiceAccount与SPIFFE/SPIRE深度集成
• 网络微分段：基于eBPF的零信任网络策略
• 供应链安全：镜像签名验证成为默认行为

7.3 边缘与IoT

• 轻量级控制平面：单节点Kubernetes资源占用降至100MB以下
• 离线自治：边缘节点在断网情况下继续运行
• 异构设备支持：ARM、RISC-V、FPGA等设备的原生管理

结语

Kubernetes 1.36 是一个承前启后的版本。它既修复了长期存在的安全隐患，又为AI时代的基础设施需求铺平了道路。

从 DRA 的设备分区到 ServiceAccount 的外部签名，从 SELinux 挂载加速到安全加固，每一个特性都体现了 Kubernetes 社区的深思熟虑：在追求创新的同时，始终将安全性和稳定性放在首位。

对于运维工程师，这意味着需要关注 externalIPs 和 gitRepo 的弃用，规划平滑的升级路径。对于平台开发者，DRA 和外部签名提供了构建企业级多集群平台的新能力。对于AI工程师，GPU分区将显著提升资源利用率，降低训练成本。

Kubernetes 正在从"容器编排工具"进化为"分布式操作系统"。v1.36 是这一进化过程中的重要里程碑。让我们期待下一个版本带来的更多惊喜。

参考资源

• Kubernetes v1.36 Release Notes
• KEP-1710: Speed up recursive SELinux label change
• KEP-740: Support external signing of service account tokens
• KEP-4815: DRA Partitionable Devices
• KEP-5055: DRA: device taints and tolerations
• Ingress NGINX Retirement Announcement
• CVE-2020-8554: Man in the middle using LoadBalancer or ExternalIPs

本文基于 Kubernetes 1.36 预览版本撰写，正式发布后部分细节可能有所调整。建议参考官方文档获取最新信息。