Kubernetes v1.36 全景剖析：从安全隔离到AI调度的生产级升级指南

一、引言：为什么 v1.36 是里程碑版本

Kubernetes v1.36 于 2026 年 4 月 22 日正式发布，这不是一个普通版本。作为 2026 年的首个主要版本，它带来了 71 项增强功能，其中 18 项晋升至 GA（稳定版），26 项进入 Beta，27 项为全新的 Alpha 特性。

但数字只是表象。真正让 v1.36 与众不同，是其关键词是「收口」而非「扩张」——一批在 Alpha 阶段跋涉了三四年的老功能，这次终于熬出头。更重要的是，它标志着 Kubernetes 从「功能堆砌」转向「安全默认」的战略转折。

本文将从程序员视角，深入剖析 v1.36 的核心变更、技术原理和实战应用，帮助你在生产环境中平滑升级并充分利用新特性。

二、安全革命：User Namespaces 正式 GA

2.1 四年磨一剑的突破

User Namespaces（用户命名空间）可能是整个 v1.36 最值得深入理解的安全特性。这个功能从 v1.25 开始进入 Alpha，历经四个版本周期，终于在 v1.36 正式 GA。

它的核心价值是什么？彻底改变容器安全模型。

2.2 技术原理：UID/GID 映射机制

Linux User Namespace 允许在容器内部看到的用户 ID（UID）与主机上的实际 UID 建立映射关系。传统容器中，容器内的 root（UID 0）就是主机上的 root，这是容器逃逸风险的根本来源。

User Namespaces 的突破在于：

# Pod 配置示例：启用 User Namespace 隔离
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  hostUsers: false  # 关键：禁用主机用户命名空间
  containers:
  - name: app
    image: nginx:latest
    securityContext:
      runAsUser: 0  # 容器内是 root
      runAsGroup: 0
  # 容器内的 UID 0 映射为主机上的非特权用户（如 UID 100000）

当 hostUsers: false 时，kubelet 会创建一个隔离的用户命名空间，容器内的 UID 0 被映射为主机上的一段非特权 UID（默认从 100000 开始）。

验证映射关系：

# 在容器内查看
$ kubectl exec -it secure-app -- id
uid=0(root) gid=0(root) groups=0(root)

# 在主机上查看对应进程
$ ps aux | grep nginx
100000  12345  0.0  0.1  nginx: master process
# 注意：UID 100000，不是 0

# 查看 /proc 的 UID 映射
$ cat /proc/12345/uid_map
         0     100000      65536
# 解释：容器内 UID 0-65535 映射为主机 UID 100000-165535

2.3 安全效果：逃逸后的权限边界

假设攻击者通过容器漏洞实现了逃逸：

# 传统容器逃逸后
$ whoami
root  # 危险：拥有主机完整权限

# User Namespace 容器逃逸后
$ whoami
uid=100000  # 安全：只是普通用户，无法执行特权操作

攻击者即使突破容器边界，也只能以非特权用户身份运行，无法：

• 修改系统文件（需要 root）
• 加载内核模块
• 执行 mount、iptables 等特权命令
• 访问其他用户的文件

2.4 性能考量与最佳实践

User Namespaces 引入了轻微的性能开销（约 1-3%），但换来的是显著的安全提升。

生产环境启用建议：

apiVersion: v1
kind: Pod
metadata:
  name: production-pod
  annotations:
    # 可选：自定义 UID 映射范围
    io.kubernetes.cri.userns-mode: "auto"
spec:
  hostUsers: false
  containers:
  - name: app
    image: myapp:v2
    securityContext:
      # 与 User Namespace 配合，实现深度防御
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL

注意事项：

1. 需要 containerd v1.7+ 或 CRI-O v1.29+ 支持
2. 镜像中硬编码 UID 的应用需要适配
3. 共享卷的 Pod 需要统一 UID 映射策略

三、准入控制新纪元：Mutating Admission Policies GA

3.1 从 Webhook 到原生策略

v1.36 另一个 GA 的重要特性是 Mutating Admission Policies（可变准入策略）。这标志着 Kubernetes 准入控制从「依赖外部 Webhook」进化到「原生 CEL 表达式」。

传统 Admission Webhook 的痛点：

• 需要独立部署和运维 Webhook 服务
• 网络延迟影响请求吞吐
• Webhook 故障会阻塞集群操作
• 安全策略需要额外开发

Mutating Admission Policies 用 CEL（Common Expression Language）把变更逻辑定义为原生 Kubernetes 对象：

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: add-default-labels
spec:
  matchConstraints:
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      resources:   ["pods"]
      operations:  ["CREATE"]
  mutations:
  - patchType: "JSONPatch"
    jsonPatch:
      expression: |
        [
          JSONPatch{
            op: "add",
            path: "/metadata/labels/environment",
            value: object.metadata.namespace
          },
          JSONPatch{
            op: "add",
            path: "/metadata/labels/created-by",
            value: "admission-policy"
          }
        ]

3.2 实战场景：自动注入安全配置

# 生产级策略：强制安全上下文
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: enforce-security-context
spec:
  matchConstraints:
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      resources:   ["pods"]
      operations:  ["CREATE"]
  variables:
  - name: hasSecurityContext
    expression: "has(object.spec.securityContext)"
  - name: needsDefault
    expression: "!variables.hasSecurityContext || !has(object.spec.securityContext.runAsNonRoot)"
  mutations:
  - patchType: "JSONPatch"
    jsonPatch:
      expression: |
        variables.needsDefault ? 
        [
          JSONPatch{
            op: "ensure",
            path: "/spec/securityContext",
            value: object.spec.securityContext ?? {}
          },
          JSONPatch{
            op: "add",
            path: "/spec/securityContext/runAsNonRoot",
            value: true
          },
          JSONPatch{
            op: "add", 
            path: "/spec/securityContext/seccompProfile",
            value: {"type": "RuntimeDefault"}
          }
        ] : []

3.3 与 Validating Admission Policy 协同

v1.36 同时支持校验型（Validating）和变更型（Mutating）策略，形成完整的原生准入控制体系：

# 组合使用：先变更后校验
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: validate-security-baseline
spec:
  matchConstraints:
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      resources:   ["pods"]
  validations:
  - expression: "object.spec.securityContext.runAsNonRoot == true"
    message: "Pods must run as non-root user"
  - expression: "!has(object.spec.containers[*].securityContext.privileged) || object.spec.containers[*].securityContext.privileged != true"
    message: "Privileged containers are not allowed"
  failurePolicy: Fail

四、动态资源分配（DRA）进阶：设备共享与隔离

4.1 设备 Taint 和 Toleration（Beta）

DRA（Dynamic Resource Allocation）是 Kubernetes 处理特殊硬件（GPU、FPGA、RDMA 网卡等）的新范式。v1.36 将「设备 Taint」功能推进到 Beta。

场景：专用 GPU 保留给特定团队

# ResourceClass：标记 GPU 为团队专用
apiVersion: resource.k8s.io/v1alpha3
kind: DeviceClass
metadata:
  name: team-alpha-gpu
spec:
  nodeSelector:
    matchLabels:
      gpu-team: alpha
  selectors:
  - cel:
      expression: device.driver == "nvidia.com/gpu"
  config:
  - opaque:
      driver: nvidia.com
      parameters:
        taints:
        - key: "team-alpha/reserved"
          value: "true"
          effect: "NoSchedule"
---
# Pod：声明容忍设备 Taint
apiVersion: v1
kind: Pod
metadata:
  name: ml-training
spec:
  containers:
  - name: training
    image: pytorch/pytorch:latest
    resources:
      claims:
      - name: gpu
  resourceClaims:
  - name: gpu
    resourceClaimTemplateName: team-alpha-gpu-claim

4.2 可分区设备：GPU 资源精细化

v1.36 的 DRA 支持将单个硬件加速器分割成多个逻辑单元：

# 将一张 A100 分割为多个 20GB 实例
apiVersion: resource.k8s.io/v1alpha3
kind: ResourceClaim
metadata:
  name: partitioned-gpu
spec:
  deviceClassName: nvidia-a100
  config:
  - opaque:
      driver: nvidia.com
      parameters:
        partition:
          type: "MIG"
          profile: "1g.20gb"  # 20GB 显存分区
---
apiVersion: v1
kind: Pod
metadata:
  name: inference-pod
spec:
  containers:
  - name: inference
    image: tensorflow/serving:latest
    resources:
      claims:
      - name: gpu-partition
        request: inference-gpu
  resourceClaims:
  - name: gpu-partition
    resourceClaimName: partitioned-gpu

实际效果：

五、Ingress NGINX 退役：Gateway API 迁移实战

5.1 退役背景与时间线

2026 年 3 月 24 日，Kubernetes SIG Network 正式宣布 Ingress NGINX 项目退役。这是 Kubernetes 历史上最具争议但也最必要的决定之一。

退役原因：

• 维护团队资源严重不足（核心维护者仅 2 人）
• 安全漏洞平均响应时间超过 90 天
• 社区资源转向 Gateway API

时间线：

• 2026-03-24：正式退役，停止所有维护
• 2026-04-22：v1.36 发布，官方推荐 Gateway API
• 2026-10：预计主流云厂商完成迁移工具发布

5.2 Gateway API 架构对比

传统 Ingress 是单层 API，所有路由规则在一个资源中定义：

# 传统 Ingress（已退役）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080

Gateway API 采用分层架构，职责分离：

# Gateway API：基础设施团队管理 Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: gateway-infra
spec:
  gatewayClassName: envoy-gateway-class
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: wildcard-cert
---
# Gateway API：应用团队管理 HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: production
spec:
  parentRefs:
  - name: production-gateway
    namespace: gateway-infra
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v2
    backendRefs:
    - name: api-service-v2
      port: 8080
    filters:
    - type: RequestHeaderModifier
      requestHeaderModifier:
        add:
        - name: X-Gateway-Version
          value: "v1.36"
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: api-service-v1
      port: 8080

5.3 迁移工具与自动化脚本

#!/bin/bash
# ingress-to-gateway-migrate.sh
# 自动迁移 Ingress 到 Gateway API

set -e

NAMESPACE="${1:-default}"
GATEWAY_NAME="${2:-production-gateway}"

echo "=== 开始迁移 Ingress 到 Gateway API ==="

# 1. 安装 Gateway API CRD
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml

# 2. 安装 Envoy Gateway
helm repo add envoy-gateway https://envoyproxy.github.io/gateway-helm
helm install envoy-gateway envoy-gateway/envoy-gateway -n envoy-gateway-system --create-namespace

# 3. 等待 Gateway Class 就绪
kubectl wait --for=condition=Available gatewayclass/envoy-gateway-class --timeout=120s

# 4. 创建 Gateway（如果不存在）
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: ${GATEWAY_NAME}
  namespace: ${NAMESPACE}
spec:
  gatewayClassName: envoy-gateway-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: tls-secret
        namespace: ${NAMESPACE}
EOF

# 5. 转换现有 Ingress
for ingress in $(kubectl get ingresses -n ${NAMESPACE} -o jsonpath='{.items[*].metadata.name}'); do
  echo "转换 Ingress: ${ingress}"
  kubectl get ingress ${ingress} -n ${NAMESPACE} -o yaml | \
    kubectl ingress-to-gateway convert - | \
    kubectl apply -f -
done

echo "=== 迁移完成 ==="
echo "请验证流量后删除旧 Ingress 资源"

六、性能优化：SELinux 卷标签的革命

6.1 问题：递归重标签的性能噩梦

在启用了 SELinux 的生产环境（如 RHEL/CentOS），挂载卷到 Pod 时需要为卷内所有文件应用正确的 SELinux 标签。传统方式是递归遍历整个文件系统：

# v1.35 及之前的行为
for file in $(find /var/lib/kubelet/pods/.../volumes -type f); do
    chcon -R -t svirt_sandbox_file_t "$file"
done

对于大卷（100GB+），这个过程可能需要数分钟，严重拖慢 Pod 启动速度。

6.2 解决方案：Mount 时一次性应用标签

v1.36 将 SELinux 卷标签优化推进到 GA，使用 mount -o context= 选项在挂载时一次性应用标签：

// 内核层面的优化（简化示意）
// 传统方式：递归遍历
int relabel_recursive(const char *path, security_context_t ctx) {
    DIR *d = opendir(path);
    struct dirent *ent;
    while ((ent = readdir(d))) {
        char fullpath[PATH_MAX];
        snprintf(fullpath, sizeof(fullpath), "%s/%s", path, ent->d_name);
        setfilecon(fullpath, ctx);
        if (ent->d_type == DT_DIR) {
            relabel_recursive(fullpath, ctx);  // 递归
        }
    }
    closedir(d);
}

// v1.36 方式：挂载选项
mount("ext4", "/dev/sdb1", "/mnt/data", 
      MS_NODEV, "context=system_u:object_r:svirt_sandbox_file_t:s0");
// 一次系统调用，内核自动处理所有文件

6.3 性能对比实测

启用配置：

apiVersion: v1
kind: Pod
metadata:
  name: selinux-optimized-pod
spec:
  securityContext:
    seLinuxOptions:
      level: "s0:c123,c456"
    seLinuxChangePolicy: MountOption  # 关键配置
  containers:
  - name: app
    image: centos:latest
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: large-data-pvc

七、弃用与移除：破坏性变更处理指南

7.1 gitRepo 卷驱动永久禁用

gitRepo 卷类型自 v1.11 弃用，v1.36 正式移除。使用该卷类型的 Pod 将无法启动。

迁移方案：使用 initContainer + git-sync

apiVersion: v1
kind: Pod
metadata:
  name: config-sync-pod
spec:
  volumes:
  - name: git-config
    emptyDir: {}
  initContainers:
  - name: git-sync
    image: registry.k8s.io/git-sync/git-sync:v4.6.0
    args:
    - "--repo=https://github.com/org/config-repo"
    - "--branch=main"
    - "--depth=1"
    - "--period=60s"
    - "--root=/git"
    - "--dest=config"
    volumeMounts:
    - name: git-config
      mountPath: /git
  containers:
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: git-config
      mountPath: /etc/config
      readOnly: true

7.2 Service.spec.externalIPs 弃用

externalIPs 字段允许将任意 IP 绑定到 Service，存在安全风险（CVE-2020-8554）。v1.36 开始显示弃用警告。

迁移方案：

# 错误：使用 externalIPs（已弃用）
apiVersion: v1
kind: Service
metadata:
  name: legacy-service
spec:
  type: ClusterIP
  externalIPs:
  - 192.168.1.100  # 弃用
  ports:
  - port: 80

---
# 正确：使用 LoadBalancer 或 Gateway API
apiVersion: v1
kind: Service
metadata:
  name: modern-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080

八、AI 工作负载支持：GPU 调度增强

8.1 Job 控制器增强

v1.36 为 AI/ML 批处理任务提供了多项优化：

apiVersion: batch/v1
kind: Job
metadata:
  name: distributed-training
spec:
  managedBy: "kueue.x-k8s.io/multikueue"  # 新字段：支持外部控制器
  parallelism: 4
  completions: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: training-headless  # 支持无头服务发现
      containers:
      - name: trainer
        image: pytorch/pytorch:latest
        command: ["torchrun", "--nproc_per_node=1", "train.py"]
        resources:
          limits:
            nvidia.com/gpu: 1
          claims:
          - name: gpu-pool
---
apiVersion: resource.k8s.io/v1alpha3
kind: ResourceClaimTemplate
metadata:
  name: gpu-pool-template
spec:
  spec:
    deviceClassName: nvidia-h100

8.2 Pod 原地调整资源（Beta）

v1.36 将「Pod 原地调整资源」功能推进到 Beta，允许动态修改容器资源请求而不重建 Pod：

# 原地调整示例
apiVersion: v1
kind: Pod
metadata:
  name: elastic-pod
spec:
  containers:
  - name: worker
    image: myapp:latest
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"
      limits:
        cpu: "2"
        memory: "2Gi"
---
# 调整资源（无需删除 Pod）
kubectl patch pod elastic-pod --type=merge -d '
spec:
  containers:
  - name: worker
    resources:
      requests:
        cpu: "1000m"
        memory: "1Gi"
'

九、生产环境升级检查清单

9.1 升级前审计脚本

#!/bin/bash
# k8s-v136-upgrade-check.sh
# Kubernetes v1.36 升级前完整检查

set -e

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'

echo "=========================================="
echo "Kubernetes v1.36 升级前检查"
echo "=========================================="

# 检查 gitRepo 卷
echo -e "\n${YELLOW}[1/7] 检查 gitRepo 卷使用...${NC}"
GITREPO_PODS=$(kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] | select(.spec.volumes[]?.gitRepo) | .metadata.name' | wc -l)
if [ "$GITREPO_PODS" -gt 0 ]; then
  echo -e "${RED}发现 $GITREPO_PODS 个 Pod 使用 gitRepo 卷，必须迁移！${NC}"
  kubectl get pods --all-namespaces -o json | \
    jq -r '.items[] | select(.spec.volumes[]?.gitRepo) | "\(.metadata.namespace)/\(.metadata.name)"'
else
  echo -e "${GREEN}✓ 无 gitRepo 卷使用${NC}"
fi

# 检查 externalIPs
echo -e "\n${YELLOW}[2/7] 检查 externalIPs 使用...${NC}"
EXTERNAL_IP_SVCS=$(kubectl get svc --all-namespaces -o json | \
  jq -r '.items[] | select(.spec.externalIPs != null and .spec.externalIPs != []) | .metadata.name' | wc -l)
if [ "$EXTERNAL_IP_SVCS" -gt 0 ]; then
  echo -e "${YELLOW}警告：发现 $EXTERNAL_IP_SVCS 个 Service 使用 externalIPs（已弃用）${NC}"
  kubectl get svc --all-namespaces -o json | \
    jq -r '.items[] | select(.spec.externalIPs != null and .spec.externalIPs != []) | "\(.metadata.namespace)/\(.metadata.name): \(.spec.externalIPs)"'
else
  echo -e "${GREEN}✓ 无 externalIPs 使用${NC}"
fi

# 检查 Ingress NGINX
echo -e "\n\n${YELLOW}[3/7] 检查 Ingress NGINX 部署...${NC}"
NGINX_DEPLOY=$(kubectl get deploy -n ingress-nginx -o json 2>/dev/null | jq '.items | length' || echo 0)
if [ "$NGINX_DEPLOY" -gt 0 ]; then
  echo -e "${YELLOW}警告：Ingress NGINX 已退役，请迁移到 Gateway API${NC}"
  kubectl get deploy -n ingress-nginx -o wide
else
  echo -e "${GREEN}✓ 无 Ingress NGINX 部署${NC}"
fi

# 检查节点运行时
echo -e "\n${YELLOW}[4/7] 检查容器运行时...${NC}"
RUNTIME=$(kubectl get nodes -o jsonpath='{.items[0].status.nodeInfo.containerRuntimeVersion}')
echo "当前运行时: $RUNTIME"
if [[ $RUNTIME == dockershim* ]]; then
  echo -e "${RED}错误：dockershim 已在 v1.24 移除，请升级运行时${NC}"
  exit 1
else
  echo -e "${GREEN}✓ 运行时版本正常${NC}"
fi

# 检查 API 版本
echo -e "\n${YELLOW}[5/7] 检查已弃用 API...${NC}"
kubectl get pods,svc,deploy --all-namespaces -o yaml 2>/dev/null | \
  grep -E "extensions/v1beta1|apps/v1beta1" || \
  echo -e "${GREEN}✓ 无已弃用 API 使用${NC}"

# 检查证书有效期
echo -e "\n${YELLOW}[6/7] 检查控制平面证书...${NC}"
kubeadm certs check-expiration 2>/dev/null || \
  echo "非 kubeadm 部署，请手动检查证书"

# 当前版本
echo -e "\n${YELLOW}[7/7] 当前 Kubernetes 版本${NC}"
kubectl version -o yaml

echo -e "\n=========================================="
echo "检查完成，请根据上述结果处理后再升级"
echo "=========================================="

9.2 升级步骤（kubeadm）

#!/bin/bash
# k8s-v136-upgrade.sh
# 使用 kubeadm 升级到 v1.36

set -e

NEW_VERSION="1.36.0-1.1"

echo "=== 开始升级到 Kubernetes v1.36 ==="

# 1. 备份 etcd
echo "[1/6] 备份 etcd 数据..."
ETCD_POD=$(kubectl get pods -n kube-system -l component=etcd -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n kube-system ${ETCD_POD} -- \
  etcdctl snapshot save /tmp/etcd-backup-$(date +%Y%m%d).db \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# 2. 升级 kubeadm
echo "[2/6] 升级 kubeadm..."
sudo yum install -y kubeadm-${NEW_VERSION}

# 3. 验证下载
kubeadm version

# 4. 预检
echo "[3/6] 预检查..."
sudo kubeadm upgrade check v1.36.0

# 5. 升级控制平面
echo "[4/6] 升级控制平面..."
sudo kubeadm upgrade apply v1.36.0

# 6. 升级 kubelet 和 kubectl
echo "[5/6] 升级 kubelet 和 kubectl..."
sudo yum install -y kubelet-${NEW_VERSION} kubectl-${NEW_VERSION}
sudo systemctl daemon-reload
sudo systemctl restart kubelet

# 7. 验证集群状态
echo "[6/6] 验证集群..."
kubectl get nodes
kubectl get pods -A

echo "=== 升级完成 ==="

十、总结与展望

Kubernetes v1.36 是一个承上启下的重要版本：

升级建议时间表

v1.36 的发布，标志着 Kubernetes 从「功能丰富」进入「安全稳健」的新阶段。对于运维团队而言，这是一个必须认真对待的版本；对于开发者而言，新的安全特性和 AI 支持将显著改变应用部署方式。

参考资料：

• Kubernetes v1.36 Release Notes
• Gateway API Documentation
• User Namespace Design Doc