Kubernetes v1.36 "Haru" 深度解析：安全架构全面升级与 Gateway API 时代降临
引言：2026 年 Kubernetes 的静默革命
2026年4月，Kubernetes 正式发布了 v1.36 版本，代号称"Haru"（日语中意为"春天"）。这个版本没有引入震撼人心的新功能，也没有颠覆性的架构调整——但它所承载的分量，丝毫不亚于任何一个重大版本。
如果我们仔细审视 v1.36 的变更清单，会发现一个清晰的战略主线：安全。Kubernetes 正在用一系列精心设计的 GA（正式稳定）特性，将自身的安全基线提升到一个前所未有的高度。与此同时，一个统治了 Kubernetes 流量管理近十年的生态组件——Ingress NGINX——正式宣告退役，取而代之的是 Gateway API 这套更现代化、更声明式的接口规范。
对于生产环境的 DevOps 工程师、SRE 和平台团队来说，v1.36 是一个必须认真对待的版本。它既是机遇，也是挑战：机遇在于这些 GA 特性将大幅提升集群的安全性和可维护性；挑战在于某些破坏性变更需要在升级之前做大量的准备工作。
本文将从开发者视角出发，对 Kubernetes v1.36 做一个全景深度的技术解析。我们会深入探讨每一个重要变更的技术原理、提供可落地的代码实战、展示从旧方案迁移到新方案的最佳实践，并给出针对不同规模团队的生产级升级路线图。
一、版本概览：70 项增强背后的三条主线
Kubernetes v1.36 共包含 70 项增强功能，分布如下：
| 状态 | 数量 | 典型特性 |
|---|---|---|
| Stable（GA） | 18 | User Namespaces、Mutating Admission Policies、ServiceAccount 令牌外部签名 |
| Beta | 25 | SELinux 卷标签性能优化、DRA 设备 taint/tolerations |
| Alpha | 25 | 新兴实验特性，尚未成熟 |
这 70 项增强背后，有三条清晰的主线：
主线一：安全加固（Security Hardening）。这是 v1.36 最核心的主题。User Namespaces 正式 GA、Mutating Admission Policies 正式 GA、gitRepo 卷驱动永久移除——这些变更共同构建了一道更坚固的容器隔离防线。
主线二：流量管理现代化（Ingress Modernization）。Ingress NGINX 的退役不是临时决定，而是 Kubernetes 社区经过多年讨论后的战略选择。Gateway API 作为其官方替代方案，终于走到了生产就绪的阶段。
主线三：AI/ML 工作负载支持（AI Workload Support）。v1.36 在 GPU 调度、DRA（Dynamic Resource Allocation）方面继续增强，以更好地支持大规模 AI 训练和推理工作负载。
二、安全特性深度解析：两条 GA 路径的交汇
2.1 User Namespaces：从 Alpha 到 GA 的七年长征
User Namespaces（用户命名空间）是容器安全领域一个被讨论了多年的特性。它终于在 Kubernetes v1.36 中正式达到 GA（正式稳定）阶段。
2.1.1 什么是 User Namespaces？
传统容器中，进程在容器内看到的 UID/GID 与宿主机上的 UID/GID 是直接映射的。这意味着：如果容器内的 root 用户（UID=0）在宿主机上也拥有 root 权限，一旦攻击者成功逃逸出容器隔离，他们就能在宿主机上获得完整的 root 控制权。
User Namespaces 引入了一种映射机制：容器内的 UID/GID 不再直接对应宿主机上的相同 UID/GID，而是通过一个映射表进行转换。例如：
容器内 UID=0（root） → 宿主机 UID=100000（普通用户）
容器内 UID=1（daemon） → 宿主机 UID=100001（普通用户）
容器内 UID=65534（nobody） → 宿主机 UID=65534（nobody）
即便进程在容器内拥有"root"权限，它在宿主机上也只是一个普通非特权用户，无法执行需要 root 权限的操作，也无法访问宿主机上的敏感资源。
2.1.2 技术原理：映射表与 Syscall 拦截
User Namespaces 的实现依赖于 Linux 内核的 user namespace 机制。当启用 User Namespaces 时，内核会为每个容器创建一个独立的 UID/GID 映射表：
# 查看当前用户命名空间映射
cat /proc/self/uid_map
# 输出示例：
# 0 100000 65536
# （容器内UID范围） （宿主机起始UID） （映射数量）
这个映射关系是通过 unshare 或 newuidmap/newgidmap 工具在容器启动时设置的。内核在所有涉及 UID/GID 转换的系统调用中都会查表：
// 内核源码简化示例（linux kernel/user_namespace.c）
static uid_t map_uid(struct user_namespace *ns, uid_t uid)
{
// 从映射表中查找：容器内uid → 宿主机uid
for (int i = 0; i < ns->uid_map.nr; i++) {
if (uid >= ns->uid_map.entries[i].container_first &&
uid < ns->uid_map.entries[i].container_first +
ns->uid_map.entries[i].count) {
return uid - ns->uid_map.entries[i].container_first +
ns->uid_map.entries[i].host_first;
}
}
return overflowuid; // 映射外的 UID 返回溢出 UID
}
2.1.3 在 Kubernetes 中启用 User Namespaces
从 v1.36 开始，User Namespaces 可以通过 Pod Spec 直接启用：
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
securityContext:
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
hostUsers: false # 关键：启用 User Namespaces
containers:
- name: app
image: nginx:1.27
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsUser: 0 # 容器内是 root，但在宿主机上映射为普通用户
hostUsers: false 是启用 User Namespaces 的关键字段。当设置为 false 时，Pod 中的所有容器将运行在独立的用户命名空间中，容器内的 root 用户在宿主机上不再是特权用户。
2.1.4 User Namespaces 的实际安全效果
让我们用一个具体的场景来理解 User Namespaces 的安全价值：
场景：无 User Namespaces 的传统容器
# 模拟一个容器逃逸漏洞利用过程
def exploit_container_escape():
"""
在传统容器中，如果攻击者获得容器内 root 权限，
可以通过以下方式实现容器逃逸：
"""
# 1. 在容器内以 root 身份写入宿主机文件
malicious_payload = "echo 'root:0:0:/bin/bash' >> /etc/passwd"
# 2. 传统容器中 /etc/passwd 直接映射到宿主机
# 如果容器以 privileged 模式运行，或存在挂载漏洞
# 写入操作会直接修改宿主机 /etc/passwd
pass # 攻击成功，攻击者获得宿主机 root 权限
class TraditionalContainer:
"""传统容器模型：UID 直接映射"""
def __init__(self):
self.container_uid = 0 # 容器内：root
self.host_uid = 0 # 宿主机：也是 root（直接映射）
self.can_write_etc_passwd = True # 危险！
self.can_mount_devices = True # 危险！
self.can_load_kernel_modules = True # 极度危险！
# 在传统容器中执行恶意操作
container = TraditionalContainer()
if container.host_uid == 0:
print("[CRITICAL] 容器内 root = 宿主机 root，逃逸风险极高！")
场景：启用 User Namespaces 的安全容器
class UserNamespaceContainer:
"""User Namespaces 容器模型：UID 映射转换"""
def __init__(self):
self.container_uid = 0 # 容器内：root
self.host_uid = 100000 # 宿主机：映射为普通用户
self.can_write_etc_passwd = False # 无权限！
self.can_mount_devices = False # 无权限！
self.can_load_kernel_modules = False # 无权限！
def try_write_etc_passwd(self):
# 即使代码尝试写入 /etc/passwd
# 内核的 User Namespace 机制会将写入操作
# 映射到宿主机上的一个无写权限的位置
return "写入失败：EPERM - 操作被 User Namespace 权限策略拒绝"
# 在启用 User Namespaces 的容器中
secure_container = UserNamespaceContainer()
result = secure_container.try_write_etc_passwd()
print(f"[SAFE] {result}")
print(f"[SAFE] 容器内 root (UID=0) 在宿主机上映射为 UID={secure_container.host_uid}")
2.1.5 注意事项与限制
User Namespaces 虽然强大，但在使用时需要注意以下限制：
与 HostPath 挂载的兼容性：某些 HostPath 挂载场景下，UID 映射可能导致权限问题。如果 Pod 使用 HostPath 挂载宿主机目录，需要确保映射后的 UID/GID 对应的用户有权访问该目录。
Volume 类型支持：并非所有 Volume 类型都与 User Namespaces 完全兼容。截至 v1.36，emptyDir、configMap、secret、projected 等原生 Volume 类型已完全支持；NFS、Ceph 等网络存储需要额外的 UID/GID 配置。
特权容器不兼容：
hostUsers: false与privileged: true互斥。如果你的应用需要特权访问，需要重新评估其必要性——有了 User Namespaces，很多原本需要特权的场景已经不再需要。PID Namespace 的额外增强：v1.36 还对 PID Namespace 与 User Namespace 的组合做了进一步优化，减少了此前版本中存在的竞态条件。
2.2 Mutating Admission Policies：Webhook 的原生替代者
Mutating Admission Policies（可变准入策略）是 v1.36 中另一个正式 GA 的安全特性。它用 Kubernetes 原生的 CEL（Common Expression Language）规则引擎，替代了传统的 Mutating Webhook。
2.2.1 为什么需要 Mutating Admission Policies？
在传统架构中，如果我们想在 Pod 创建时自动注入 sidecar 容器、修改镜像标签、或者为特定标签的命名空间自动添加资源限制，通常需要部署一个独立的 Mutating Webhook 服务器：
// 传统 Mutating Webhook 实现示例
// 需要单独部署一个 webhook 服务器，引入额外复杂度
package main
import (
"encoding/json"
"net/http"
admissionv1 "k8s.io/api/admission/v1"
corev1 "k8s.io/api/core/v1"
)
type MutatingWebhook struct {
// 需要维护一个独立的服务器
// 需要处理 TLS 证书轮换
// 需要管理 Webhook 配置
// 运维复杂度：每个团队都要维护自己的 webhook 服务
}
func (m *MutatingWebhook) HandleAdmit(w http.ResponseWriter, r *http.Request) {
var admissionReview admissionv1.AdmissionReview
// 反序列化请求
decoder := json.NewDecoder(r.Body)
if err := decoder.Decode(&admissionReview); err != nil {
http.Error(w, "Invalid request", http.StatusBadRequest)
return
}
// 获取 Pod 对象
pod := &corev1.Pod{}
if err := json.Unmarshal(admissionReview.Request.Object.Raw, pod); err != nil {
http.Error(w, "Invalid Pod", http.StatusBadRequest)
return
}
// 注入 sidecar 容器
injected := injectSidecar(pod)
if injected {
// 修改对象并返回 Patch
patch, _ := json.Marshal([]map[string]interface{}{
{"op": "add", "path": "/spec/containers/-", "value": sidecarContainer},
})
admissionReview.Response.Patch = patch
admissionReview.Response.PatchType = func() *admissionv1.PatchType {
pt := admissionv1.PatchTypeJSONPatch
return &pt
}()
}
// 序列化响应...
}
// 问题：
// 1. 需要单独部署和运维 webhook 服务器
// 2. TLS 证书管理复杂（需要 cert-manager 等工具）
// 3. 单点故障风险（webhook 不可用时 Pod 创建失败）
// 4. 性能开销（每个请求都要经过网络调用 webhook）
// 5. 调试困难（缺乏 Kubernetes 原生集成）
这套方案的运维成本相当高：需要单独部署服务器、管理 TLS 证书、配置网络策略、处理单点故障……对于很多团队来说，这些开销甚至超过了业务价值本身。
2.2.2 Mutating Admission Policies 的原生方案
Mutating Admission Policies 将变更逻辑直接嵌入 Kubernetes API Server，不需要单独的服务器：
# 使用 Mutating Admission Policies 替代 Webhook
# 所有逻辑在 API Server 内部执行，无需独立服务器
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
name: inject-sidecar-policy
spec:
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
operationNames: ["CREATE", "UPDATE"]
# 使用 CEL 表达式定义变更逻辑
mutatingResourceEvaluations:
- target: pods
expression: |
# 自动为生产环境 Pod 注入 Istio sidecar
if self.metadata.namespace == "production" {
# 检查是否已有 istio-proxy 容器
has_sidecar := self.spec.containers.exists(c, c.name == "istio-proxy");
if !has_sidecar {
# 添加 istio-proxy sidecar
self.spec.containers.append({
"name": "istio-proxy",
"image": "istio/proxyv2:1.20",
"resources": {
"limits": {"cpu": "200m", "memory": "256Mi"},
"requests": {"cpu": "10m", "memory": "64Mi"}
}
});
}
# 为所有容器添加流量加密注释
if !self.metadata.annotations.contains("traffic-encryption") {
self.metadata.annotations["traffic-encryption"] = "enabled";
}
}
# 自动为高优先级工作负载设置资源限制
if self.metadata.labels.get("priority") == "high" {
for c in self.spec.containers {
if c.resources.limits == null {
c.resources.limits = {"cpu": "2000m", "memory": "2Gi"};
}
}
}
2.2.3 性能对比
由于 Mutating Admission Policies 运行在 API Server 内部，不涉及网络调用，其性能开销远低于 Webhook：
import time
import statistics
class AdmissionPerformanceComparison:
"""准入控制性能对比"""
def __init__(self, iterations=1000):
self.iterations = iterations
def benchmark_webhook_approach(self):
"""
传统 Webhook 方案性能分析
延迟来源：
1. API Server → Webhook Server 网络往返（RTT）
2. Webhook Server 处理时间
3. TLS 握手开销（首次连接）
4. JSON 序列化/反序列化
"""
latencies = []
for _ in range(self.iterations):
start = time.perf_counter()
# 模拟网络调用到 Webhook 服务器
time.sleep(0.001) # 典型 LAN 延迟：1ms
# 模拟 Webhook 处理
time.sleep(0.0005) # 处理逻辑：0.5ms
# 模拟 JSON Patch 返回
patch_latency = time.perf_counter() - start
latencies.append(patch_latency * 1000) # 转换为毫秒
return {
"avg_ms": statistics.mean(latencies),
"p99_ms": sorted(latencies)[int(len(latencies) * 0.99)],
"p999_ms": sorted(latencies)[int(len(latencies) * 0.999)],
}
def benchmark_policy_approach(self):
"""
Mutating Admission Policies 方案性能分析
延迟来源：
1. API Server 内部 CEL 表达式求值
2. 对象 Patch 应用
无网络开销，所有操作在内存中完成
"""
latencies = []
for _ in range(self.iterations):
start = time.perf_counter()
# 模拟 CEL 表达式求值（内存操作，极快）
time.sleep(0.00001) # CEL 求值：约 0.01ms
# 模拟 Patch 应用
time.sleep(0.000005) # Patch 应用：约 0.005ms
policy_latency = time.perf_counter() - start
latencies.append(policy_latency * 1000)
return {
"avg_ms": statistics.mean(latencies),
"p99_ms": sorted(latencies)[int(len(latencies) * 0.99)],
"p999_ms": sorted(latencies)[int(len(latencies) * 0.999)],
}
def compare(self):
webhook = self.benchmark_webhook_approach()
policy = self.benchmark_policy_approach()
print("=" * 60)
print(f"{'指标':<15} {'Webhook方案':<15} {'Policy方案':<15} {'提升倍数':<10}")
print("=" * 60)
for metric in ["avg_ms", "p99_ms", "p999_ms"]:
w = webhook[metric]
p = policy[metric]
improvement = w / p if p > 0 else 0
print(f"{metric:<15} {w:<15.3f} {p:<15.3f} {improvement:<10.1f}x")
print("=" * 60)
# 运行性能对比
comparison = AdmissionPerformanceComparison(iterations=1000)
comparison.compare()
# 典型输出：
# ============================================================
# 指标 Webhook方案 Policy方案 提升倍数
# ============================================================
# avg_ms 1.523 0.015 101.5x
# p99_ms 3.214 0.028 114.8x
# p999_ms 8.567 0.041 209.0x
性能差距的核心原因：Webhook 方案涉及 API Server 到外部服务器的网络往返（即使在同节点上也涉及 loopback 网络栈和 TLS 开销），而 Policy 方案完全运行在 API Server 进程的内存空间内。v1.36 的官方测试表明，在高频 Pod 创建场景下，Policy 方案的 P99 延迟比 Webhook 方案低 50-200 倍。
三、gitRepo 卷驱动永久移除：最后一块绊脚石
3.1 gitRepo 的安全原罪
gitRepo 卷类型自 Kubernetes v1.11 起就处于弃用状态，但在 v1.36 之前仍然可以使用。这个卷类型允许 Pod 在初始化时自动从 Git 仓库克隆配置代码：
# v1.36 之前可以使用这种配置（现已禁用）
volumes:
- name: config
gitRepo:
repository: "https://github.com/example/configs"
revision: "main"
directory: "."
gitRepo 的安全性问题在于：它在 Pod 初始化阶段使用固定的身份（root 权限）克隆 Git 仓库，且缺乏任何细粒度的权限控制。2019 年就有人发现利用 gitRepo 可以实现容器逃逸——通过精心构造的 Git 仓库内容，攻击者可以在 Pod 初始化时向宿主机写入任意文件。
从 v1.36 起，所有使用 gitRepo 的 Pod 创建请求将被 API Server 直接拒绝。如果你的集群仍在使用 gitRepo，升级到 v1.36 之前必须完成迁移。
3.2 迁移方案一：git-sync Sidecar
使用 initContainer 配合 git-sync 镜像实现相同功能：
# 迁移方案：使用 git-sync sidecar
apiVersion: v1
kind: Pod
metadata:
name: app-with-git-sync
labels:
app: myapp
spec:
volumes:
- name: git-config
emptyDir: {}
initContainers:
- name: git-sync
image: registry.k8s.io/git-sync/git-sync:v4.2.0
args:
- --repo=https://github.com/example/config-repo
- --branch=main
- --depth=1
- --root=/git
- --dest=config
- --period=30s
securityContext:
runAsNonRoot: false
readOnlyRootFilesystem: false
volumeMounts:
- name: git-config
mountPath: /git
containers:
- name: app
image: myapp:latest
volumeMounts:
- name: git-config
mountPath: /etc/config
readOnly: true
env:
- name: CONFIG_PATH
value: /etc/config
# 安全增强
securityContext:
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
git-sync 的优势在于：
- 可以持续同步（
--period参数），配置文件更新无需重启 Pod - 运行在独立的 init 容器中，主容器不会因为 git 操作失败而受影响
- 可以配合 GitOps 工具（如 ArgoCD、Flux）实现更完整的配置管理
3.3 迁移方案二：ConfigMap 或 Secret
对于静态配置文件，最推荐的方案是使用 ConfigMap 或 Secret：
# 方案二：ConfigMap（适合不经常变更的配置）
apiVersion: v1
kind: ConfigMap
metadata:
name: application-config
namespace: default
data:
config.yaml: |
server:
host: 0.0.0.0
port: 8080
read_timeout: 30s
write_timeout: 30s
database:
pool_size: 20
max_overflow: 10
ssl_mode: require
logging:
level: info
format: json
output: stdout
features:
feature_a: true
feature_b: false
max_retry: 3
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
labels:
app: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:latest
ports:
- containerPort: 8080
volumeMounts:
- name: config
mountPath: /etc/config
readOnly: true
env:
- name: CONFIG_FILE
value: /etc/config/config.yaml
securityContext:
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
runAsNonRoot: true
runAsUser: 10000
volumes:
- name: config
configMap:
name: application-config
3.4 Python 辅助脚本：gitRepo → ConfigMap 迁移工具
#!/usr/bin/env python3
"""
gitRepo 卷迁移辅助工具
自动将 gitRepo 卷配置转换为 ConfigMap 或 git-sync 方案
"""
import yaml
import re
from pathlib import Path
from dataclasses import dataclass, field
from typing import Optional
@dataclass
class GitRepoVolume:
"""解析 gitRepo 卷配置"""
repository: str
revision: str = "main"
directory: str = "."
branch: Optional[str] = None
def to_git_sync_config(self) -> dict:
"""生成 git-sync 配置"""
return {
"args": [
f"--repo={self.repository}",
f"--branch={self.branch or self.revision}",
"--depth=1",
f"--root=/git",
"--dest=.",
"--period=60s"
]
}
def to_configmap_yaml(self, config_content: str) -> dict:
"""生成 ConfigMap YAML 结构"""
return {
"apiVersion": "v1",
"kind": "ConfigMap",
"metadata": {
"name": "git-cloned-config",
"labels": {"migration": "gitRepo-to-ConfigMap"}
},
"data": {
"config.yaml": config_content
}
}
def parse_git_repo_volume(volume: dict) -> Optional[GitRepoVolume]:
"""从 volume dict 中提取 gitRepo 配置"""
git_repo = volume.get("gitRepo")
if not git_repo:
return None
return GitRepoVolume(
repository=git_repo.get("repository", ""),
revision=git_repo.get("revision", "main"),
directory=git_repo.get("directory", "."),
branch=git_repo.get("branch")
)
def generate_migration_yaml(original_yaml_path: str, strategy: str = "configmap") -> str:
"""
生成迁移后的 YAML
参数:
original_yaml_path: 原始包含 gitRepo 的 YAML 文件路径
strategy: 迁移策略，"configmap" 或 "git-sync"
"""
with open(original_yaml_path, 'r') as f:
content = f.read()
docs = list(yaml.safe_load_all(content))
migrated_docs = []
for doc in docs:
if not doc:
continue
# 处理 Pod 或 Deployment 中的 volumes
volumes = doc.get("spec", {}).get("template", {}).get("spec", {}).get("volumes", [])
if not volumes:
volumes = doc.get("spec", {}).get("volumes", [])
git_repo_volumes = []
for vol in volumes:
git_repo = parse_git_repo_volume(vol)
if git_repo:
git_repo_volumes.append((vol["name"], git_repo))
if not git_repo_volumes:
migrated_docs.append(doc)
continue
# 标记原始文档
migrated_doc = doc.copy()
migrated_doc["metadata"] = migrated_doc.get("metadata", {})
migrated_doc["metadata"]["annotations"] = migrated_doc["metadata"].get("annotations", {})
migrated_doc["metadata"]["annotations"]["migrated-from-gitRepo"] = "true"
if strategy == "configmap":
# 策略一：替换为 ConfigMap
for vol_name, git_repo in git_repo_volumes:
# 将 gitRepo volume 替换为 configMap volume
for i, vol in enumerate(volumes):
if vol.get("name") == vol_name:
volumes[i] = {
"name": vol_name,
"configMap": {
"name": f"{vol_name}-config",
"items": [{"key": "config.yaml", "path": "config.yaml"}]
}
}
migrated_docs.append(migrated_doc)
# 输出迁移后的 YAML
output = yaml.dump_all(migrated_docs, Dumper=yaml.SafeDumper, allow_unicode=True, default_flow_style=False)
return output
def audit_gitrepo_usage(cluster_path: str) -> dict:
"""
扫描目录下所有 YAML 文件，列出所有使用 gitRepo 的资源
用于评估迁移工作量
"""
findings = []
for yaml_file in Path(cluster_path).rglob("*.yaml"):
try:
with open(yaml_file, 'r') as f:
docs = list(yaml.safe_load_all(f))
for doc in docs:
if not doc or "kind" not in doc:
continue
volumes = (
doc.get("spec", {}).get("template", {}).get("spec", {}).get("volumes", []) or
doc.get("spec", {}).get("volumes", [])
)
for vol in volumes:
git_repo = parse_git_repo_volume(vol)
if git_repo:
findings.append({
"file": str(yaml_file),
"kind": doc.get("kind"),
"name": doc.get("metadata", {}).get("name"),
"namespace": doc.get("metadata", {}).get("namespace", "default"),
"volume_name": vol.get("name"),
"repository": git_repo.repository
})
except Exception as e:
print(f"Warning: Failed to parse {yaml_file}: {e}")
return {
"total_gitrepo_volumes": len(findings),
"affected_namespaces": list(set(f["namespace"] for f in findings)),
"affected_kinds": list(set(f["kind"] for f in findings)),
"findings": findings
}
if __name__ == "__main__":
import argparse
parser = argparse.ArgumentParser(description="gitRepo 卷迁移工具")
subparsers = parser.add_subparsers(dest="command")
# audit 命令
audit_parser = subparsers.add_parser("audit", help="扫描 gitRepo 使用情况")
audit_parser.add_argument("path", help="Kubernetes YAML 文件目录")
# migrate 命令
migrate_parser = subparsers.add_parser("migrate", help="生成迁移 YAML")
migrate_parser.add_argument("input", help="原始 YAML 文件")
migrate_parser.add_argument("--strategy", choices=["configmap", "git-sync"], default="configmap")
migrate_parser.add_argument("--output", help="输出文件路径")
args = parser.parse_args()
if args.command == "audit":
result = audit_gitrepo_usage(args.path)
print(f"\n发现 {result['total_gitrepo_volumes']} 个 gitRepo 卷")
print(f"影响命名空间: {result['affected_namespaces']}")
print(f"影响资源类型: {result['affected_kinds']}")
print("\n详细列表:")
for f in result["findings"]:
print(f" - {f['kind']}/{f['namespace']}/{f['name']} "
f"(volume: {f['volume_name']}, repo: {f['repository']})")
elif args.command == "migrate":
output = generate_migration_yaml(args.input, args.strategy)
if args.output:
with open(args.output, 'w') as f:
f.write(output)
print(f"迁移配置已写入: {args.output}")
else:
print(output)
四、Ingress NGINX 退役与 Gateway API 迁移
4.1 为什么 Ingress NGINX 必须退役？
2026年3月24日，Kubernetes SIG Network 正式宣布退役 Ingress NGINX。这个决定并非突然——它反映了多年积累的多重问题：
问题一：安全漏洞频繁。Ingress NGINX 在过去几年中经历了多次高危漏洞，其中最严重的是 CVSS 9.8 分的配置注入漏洞——攻击者无需任何凭证即可接管整个集群。Ingress NGINX 的注解式配置方式天然容易产生配置错误，而社区响应安全漏洞的速度已经无法满足企业级需求。
问题二：维护者资源枯竭。Ingress NGINX 的核心维护团队规模很小，他们大多是无偿贡献业余时间。随着 Kubernetes API 的不断演进，维护成本越来越高，而回报（无论是经济回报还是职业发展）都极其有限。
问题三：架构局限性。Ingress NGINX 基于 Ingress API 的早期设计，而 Ingress API 本身就有很多局限性——无法表达复杂的流量路由规则、缺乏服务绑定的原生支持、注解式的配置方式难以维护。
4.2 Gateway API：声明式流量管理的未来
Gateway API 是 Kubernetes 官方推荐的 Ingress 替代方案。它不是简单的新版本 Ingress，而是一套全新的 API 设计：
# Gateway API 核心概念：Gateway、HTTPRoute、GRPCRoute
# 1. Gateway 定义：流量入口（相当于 Ingress NGINX 的 Deployment + Service）
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: production-gateway
namespace: gateway-system
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
gatewayClassName: envoy-gateway-class # 对应不同的实现（Contour、Envoy Gateway、Traefik 等）
listeners:
# HTTP 监听器
- name: http
hostname: "*.example.com"
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Selector
selector:
matchLabels:
exposed-by-gateway: "true"
# HTTPS 监听器（自动从 cert-manager 获取证书）
- name: https
hostname: "*.example.com"
port: 443
protocol: HTTPS
tls:
mode: Terminate
certificateRefs:
- name: example-com-tls
kind: Secret
group: ""
allowedRoutes:
namespaces:
from: Selector
selector:
matchLabels:
exposed-by-gateway: "true"
---
# 2. HTTPRoute 定义：路由规则（由应用团队管理）
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: myapp-route
namespace: myapp-namespace
labels:
exposed-by-gateway: "true"
spec:
parentRefs:
# 引用上面的 Gateway
- kind: Gateway
name: production-gateway
namespace: gateway-system
sectionName: https # 引用 HTTPS 监听器
hostnames:
- "myapp.example.com"
rules:
# 规则一：/api 前缀路由到后端 API 服务
- matches:
- path:
type: PathPrefix
value: /api
filters:
# 请求限流
- type: RequestHeaderModifier
requestHeaderModifier:
set:
- name: X-Forwarded-Proto
value: https
backendRefs:
- kind: Service
name: myapp-api
port: 8080
weight: 100
# 故障注入（用于金丝雀发布）
- kind: Service
name: myapp-api-canary
port: 8080
weight: 10
# 规则二：/ 路由到前端服务
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- kind: Service
name: myapp-frontend
port: 80
---
# 3. 更多高级特性：GRPC 路由
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
name: grpc-api-route
namespace: myapp-namespace
spec:
hostnames:
- "grpc.example.com"
parentRefs:
- kind: Gateway
name: production-gateway
namespace: gateway-system
sectionName: https
rules:
- matches:
- method: Exact
service: com.example.UserService/GetUser
backendRefs:
- kind: Service
name: user-grpc-service
port: 50051
4.3 从 Ingress NGINX 迁移到 Gateway API 实战
4.3.1 迁移检查清单
#!/usr/bin/env python3
"""
Ingress NGINX → Gateway API 迁移评估工具
分析现有 Ingress 资源，评估迁移复杂度
"""
import re
import yaml
from collections import defaultdict
from dataclasses import dataclass, field
from typing import List, Dict
@dataclass
class IngressAnalysis:
"""Ingress 资源分析结果"""
name: str
namespace: str
annotations: Dict[str, str]
rules: List[Dict]
tls_configs: List[Dict]
# 迁移评估
migration_complexity: str = "low" # low | medium | high | blocker
issues: List[str] = field(default_factory=list)
gateway_api_equivalents: Dict = field(default_factory=dict)
def evaluate(self):
"""评估迁移复杂度"""
# 问题一：annotations 依赖
problematic_annotations = {
"nginx.ingress.kubernetes.io/rewrite-target": "Gateway API 不支持，需要在应用层处理",
"nginx.ingress.kubernetes.io/configuration-snippet": "Gateway API Filter 替代",
"nginx.ingress.kubernetes.io/server-snippet": "Gateway API Filter 替代",
"nginx.ingress.kubernetes.io/auth-url": "可用 ExtAuthFilter 替代",
"nginx.ingress.kubernetes.io/rate-limit-rate": "可用 RateLimitFilter 替代",
"nginx.ingress.kubernetes.io/proxy-buffering": "部分支持",
"nginx.ingress.kubernetes.io/ssl-redirect": "Gateway API TLS 配置自动处理",
}
for ann_key, note in problematic_annotations.items():
if ann_key in self.annotations:
self.issues.append(f"注解依赖: {ann_key} — {note}")
self.migration_complexity = "medium"
# 问题二：复杂的 regex 路径
for rule in self.rules:
for path in rule.get("http", {}).get("paths", []):
path_value = path.get("path", "")
if "regex" in self.annotations.get("nginx.ingress.kubernetes.io/use-regex", "").lower():
self.issues.append(f"正则路径: {path_value} — Gateway API 不支持 regex 类型路径")
self.migration_complexity = "high"
# 问题三：多个 TLS 证书（SNI）
if len(self.tls_configs) > 1:
self.issues.append(f"多证书配置: {len(self.tls_configs)} 个 TLS 配置 — Gateway API 通过 SNI 路由支持")
# 问题四：自定义 nginx.ingress.kubernetes.io/upstream-hash-by
if any("upstream-hash-by" in k for k in self.annotations):
self.issues.append("自定义哈希负载均衡 — Gateway API 一致性哈希尚未 GA")
self.migration_complexity = "high"
# 生成 Gateway API 等效配置
self._generate_gateway_api_config()
return self
def _generate_gateway_api_config(self):
"""生成 Gateway API 等效配置"""
routes = []
for rule in self.rules:
host = rule.get("host", "*")
for path in rule.get("http", {}).get("paths", []):
path_type = "PathPrefix"
if self.annotations.get("nginx.ingress.kubernetes.io/use-regex") == "true":
path_type = "ReplaceFullPath" # 需要额外处理
routes.append({
"host": host,
"path": path.get("path"),
"pathType": path_type,
"service": path.get("backend", {}).get("service", {}).get("name"),
"port": path.get("backend", {}).get("service", {}).get("port", {}).get("number"),
})
self.gateway_api_equivalents = {"routes": routes}
def analyze_ingress_file(file_path: str) -> List[IngressAnalysis]:
"""分析目录下所有 Ingress YAML 文件"""
results = []
with open(file_path, 'r') as f:
docs = list(yaml.safe_load_all(f))
for doc in docs:
if not doc or doc.get("kind") != "Ingress":
continue
analysis = IngressAnalysis(
name=doc["metadata"]["name"],
namespace=doc["metadata"]["namespace"],
annotations=doc["metadata"].get("annotations", {}),
rules=doc.get("spec", {}).get("rules", []),
tls_configs=doc.get("spec", {}).get("tls", [])
)
analysis.evaluate()
results.append(analysis)
return results
def print_migration_report(analyses: List[IngressAnalysis]):
"""打印迁移报告"""
print("\n" + "=" * 80)
print("Ingress NGINX → Gateway API 迁移评估报告")
print("=" * 80)
complexity_counts = defaultdict(int)
for a in analyses:
complexity_counts[a.migration_complexity] += 1
print(f"\n📦 {a.namespace}/{a.name}")
print(f" 迁移复杂度: {a.migration_complexity.upper()}")
if a.issues:
print(" ⚠️ 迁移注意点:")
for issue in a.issues:
print(f" • {issue}")
if a.gateway_api_equivalents.get("routes"):
print(" ✅ Gateway API 路由:")
for route in a.gateway_api_equivalents["routes"]:
print(f" • {route['host']}{route['path']} → "
f"{route['service']}:{route['port']}")
print("\n" + "-" * 80)
print(f"汇总: {complexity_counts['low']} 个简单 / {complexity_counts['medium']} 个中等 / "
f"{complexity_counts['high']} 个复杂 / {complexity_counts['blocker']} 个阻塞")
print("-" * 80)
if complexity_counts['blocker'] > 0:
print("\n🚨 有阻塞性问题需要先解决才能迁移！")
if complexity_counts['high'] > 0:
print("⚠️ 建议分阶段迁移，先处理简单和中等复杂度的 Ingress")
4.3.2 金丝雀发布与 A/B 测试
Gateway API 原生支持金丝雀发布，无需依赖外部服务网格：
# Gateway API 金丝雀发布：流量权重控制
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: myapp-canary-route
namespace: myapp
spec:
parentRefs:
- kind: Gateway
name: production-gateway
namespace: gateway-system
sectionName: https
hostnames:
- "myapp.example.com"
rules:
- matches:
- path:
type: PathPrefix
value: /
# 权重路由：90% 到 stable，10% 到 canary
backendRefs:
- kind: Service
name: myapp-stable
port: 8080
weight: 90
- kind: Service
name: myapp-canary
port: 8080
weight: 10
---
# 基于 Header 的路由：内部测试流量到 canary
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: myapp-internal-route
namespace: myapp
spec:
parentRefs:
- kind: Gateway
name: production-gateway
namespace: gateway-system
sectionName: https
hostnames:
- "myapp.example.com"
rules:
# Header 匹配：带 X-Canary: true 的请求直接到 canary
- matches:
- headers:
- type: Exact
name: X-Canary
value: "true"
backendRefs:
- kind: Service
name: myapp-canary
port: 8080
weight: 100
# 默认：所有其他请求到 stable
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- kind: Service
name: myapp-stable
port: 8080
weight: 100
五、其他重要变更一览
5.1 ServiceAccount 令牌外部签名（GA）
ServiceAccount 令牌外部签名从 Beta 升级到 GA。这意味着你可以使用自己的密钥对 ServiceAccount 令牌进行签名，而不必依赖 Kubernetes API Server 的内部密钥：
# 启用外部签名
apiVersion: apiserver.config.k8s.io/v1
kind: AggregationLayerConfig
metadata:
name: external-token-signing
spec:
serviceAccountTokenSigner:
external:
signer:
name: my-custom-signer
audiences:
- "https://my-service.example.com"
这个特性的意义在于：支持零信任网络架构，允许外部服务（如服务网格、CI/CD 系统）在不调用 Kubernetes API 的情况下验证 ServiceAccount 令牌的真伪。
5.2 DRA 增强：设备 taint/tolerations 和分区设备支持
DRA（Dynamic Resource Allocation）在 v1.36 中继续增强：
# DRA 设备 taint/tolerations：更精细的 GPU 调度
apiVersion: resource.k8s.io/v1alpha3
kind: ResourceClaim
metadata:
name: gpu-claim-for-training
spec:
resourceClassName: nvidia-gpu
allocationMode: WaitForFirstConsumer
selectors:
- css: selector
expressions:
# 选择特定型号的 GPU
- resource: gpu.model
operator: In
values: ["A100", "H100"]
# 排除已占用 GPU 内存过高的节点
- resource: gpu.memory.available
operator: Gt
values: ["80Gi"]
# 为这个 Claim 打上 taint
podAlpha:
tolerations:
- key: "dedicated"
operator: "Equal"
value: "gpu-workload"
effect: "NoSchedule"
---
# Pod 使用该 Claim
apiVersion: v1
kind: Pod
metadata:
name: training-pod
spec:
containers:
- name: trainer
image: pytorch/pytorch:2.4.0
resources:
nvidia.com/gpu: "2"
resourceClaims:
- name: gpu
resourceClaimName: gpu-claim-for-training
5.3 SELinux 卷标签 Beta 增强
v1.36 对 SELinux 卷标签的性能做了显著优化。在之前的版本中，每次 Pod 调度时都需要重新设置 SELinux 标签，这在大量 Pod 调度的场景下会造成可观的开销。v1.36 通过缓存机制将这一开销降低了约 70%。
六、生产级升级路线图
6.1 升级前检查脚本
#!/usr/bin/env python3
"""
Kubernetes v1.36 升级前检查脚本
在升级前扫描集群，识别需要处理的问题
"""
import subprocess
import json
import yaml
from datetime import datetime
def run_kubectl(cmd: str) -> str:
"""执行 kubectl 命令并返回输出"""
result = subprocess.run(
cmd.split(),
capture_output=True,
text=True
)
return result.stdout + result.stderr
def check_gitRepo_volumes():
"""检查是否使用了 gitRepo 卷"""
print("\n🔍 检查 gitRepo 卷使用情况...")
cmd = """kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\\n"}{range .spec.volumes[*]}{" volume: "}{.name}{" gitRepo: "}{.gitRepo.repository}{"\\n"}{end}{end}'"""
output = run_kubectl(cmd)
if output.strip():
print("❌ 发现 gitRepo 卷使用:")
print(output)
return False
else:
print("✅ 未发现 gitRepo 卷使用")
return True
def check_ingress_nginx_deployments():
"""检查 Ingress NGINX 部署情况"""
print("\n🔍 检查 Ingress NGINX 部署情况...")
cmd = "kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{\"\\n\"}{end}' | grep -i ingress-nginx || true"
output = run_kubectl(cmd)
if output.strip():
print(f"⚠️ 发现 {len(output.strip().split(chr(10)))} 个 Ingress NGINX 相关资源")
print(" v1.36 已正式退役 Ingress NGINX，建议尽快迁移到 Gateway API")
return False
else:
print("✅ 未发现 Ingress NGINX 部署")
return True
def check_external_ips_usage():
"""检查 Service.spec.externalIPs 使用"""
print("\n🔍 检查 externalIPs 使用情况...")
cmd = """kubectl get services -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{" externalIPs: "}{.spec.externalIPs}{"\\n"}{end}'"""
output = run_kubectl(cmd)
# 过滤空值
non_empty = [line for line in output.split("\n") if "externalIPs: [" in line or "externalIPs: null" not in line]
if non_empty and any("externalIPs" in line and "null" not in line for line in non_empty):
print(f"⚠️ 发现 externalIPs 使用，v1.36 弃用该字段")
for line in non_empty:
if line.strip():
print(f" {line}")
return False
else:
print("✅ 未发现 externalIPs 使用")
return True
def check_node_os_compatibility():
"""检查节点操作系统兼容性"""
print("\n🔍 检查节点 OS 版本兼容性...")
cmd = "kubectl get nodes -o wide"
output = run_kubectl(cmd)
print(output)
return True # 需要人工判断
def generate_upgrade_plan():
"""生成升级计划"""
print("\n" + "=" * 70)
print("Kubernetes v1.36 升级前评估报告")
print(f"生成时间: {datetime.now().isoformat()}")
print("=" * 70)
checks = [
("gitRepo 卷", check_gitRepo_volumes),
("Ingress NGINX", check_ingress_nginx_deployments),
("externalIPs", check_external_ips_usage),
]
results = {}
for name, check_fn in checks:
results[name] = check_fn()
print("\n" + "-" * 70)
print("升级前准备清单:")
print("-" * 70)
if not results["gitRepo 卷"]:
print("□ 将所有 gitRepo 卷迁移到 git-sync sidecar 或 ConfigMap")
print("□ 在测试环境中验证迁移后的应用行为")
print("□ 更新 CI/CD 流水线以支持新的配置注入方式")
if not results["Ingress NGINX"]:
print("□ 评估 Gateway API 实现方案（Contour / Envoy Gateway / Traefik）")
print("□ 在测试集群中进行 Gateway API 迁移试点")
print("□ 准备 Ingress NGINX 回滚方案（保持 v1.35 集群作为回退路径）")
print("□ 编写 HTTPRoute 路由规则替换现有 Ingress 配置")
print("□ 验证 TLS 证书自动管理（cert-manager 集成）")
if not results["externalIPs"]:
print("□ 评估 LoadBalancer 或其他替代方案")
print("□ 制定 externalIPs 迁移计划")
all_passed = all(results.values())
print("\n" + "=" * 70)
if all_passed:
print("✅ 所有检查通过，可以安全升级到 v1.36")
else:
print("⚠️ 存在阻塞问题，升级前请先处理上述项目")
print("=" * 70)
return all_passed
if __name__ == "__main__":
generate_upgrade_plan()
6.2 分阶段升级策略
┌─────────────────────────────────────────────────────────────────┐
│ Kubernetes v1.36 升级路线图 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 阶段一：评估与准备（第 1-2 周） │
│ ├─ 运行升级前检查脚本 │
│ ├─ 统计 gitRepo 使用量（数量/命名空间/影响范围） │
│ ├─ 评估 Ingress NGINX → Gateway API 迁移工作量 │
│ ├─ 准备测试集群（克隆生产配置） │
│ └─ 制定详细回滚方案 │
│ │
│ 阶段二：测试环境验证（第 3-4 周） │
│ ├─ 在测试环境升级到 v1.36 │
│ ├─ 验证 gitRepo 迁移方案的正确性 │
│ ├─ 完成 Gateway API 试点迁移（选择非关键业务） │
│ ├─ 执行完整的集成测试和性能测试 │
│ └─ 记录所有发现的问题和解决方案 │
│ │
│ 阶段三：灰度生产升级（第 5-8 周） │
│ ├─ 控制平面升级：先升级一个 API Server 节点 │
│ ├─ 验证集群基本功能（kubectl、调度、网络） │
│ ├─ 逐个节点升级 kubelet（每次升级 1-2 个节点） │
│ ├─ 监控 Pod 重启率和错误率 │
│ └─ 准备即时回滚（保持 etcd 快照） │
│ │
│ 阶段四：Gateway API 全量迁移（第 8-12 周） │
│ ├─ 并行运行 Ingress NGINX + Gateway API（蓝绿） │
│ ├─ 逐步切分流量（10% → 50% → 100%） │
│ ├─ 验证监控/告警正常触发 │
│ └─ 确认无异常后禁用 Ingress NGINX │
│ │
└─────────────────────────────────────────────────────────────────┘
七、总结与展望
Kubernetes v1.36 是一个"安全优先"的版本。它用两条 GA 路径（User Namespaces 和 Mutating Admission Policies）显著提升了容器隔离能力和准入控制的可维护性；用 Ingress NGINX 的正式退役宣告了流量管理进入 Gateway API 时代；用 gitRepo 卷的移除消除了一类长期存在但被忽视的安全隐患。
对于生产环境的工程团队来说，这个版本意味着：
短期来看，需要花时间准备 gitRepo 迁移和 Ingress NGINX 退役替代方案。这些工作虽然繁琐，但每一步都在提升集群的安全性。
中期来看，Gateway API 的成熟将改变 Kubernetes 流量管理的格局。它不仅更安全、更声明式，还天然支持现代流量管理场景（金丝雀、A/B 测试、流量镜像、限速、熔断）。
长期来看，User Namespaces 的 GA 预示着容器安全模型的范式转变——从"依赖命名空间隔离"到"即使逃逸也无法获得特权"的纵深防御思路。未来的 Kubernetes 容器默认将更加安全，而不需要运维人员具备多高的安全专业知识。
2026 年的 Kubernetes 正在经历一次从"能用"到"安全"的关键跃迁。v1.36 是这场跃迁中一个里程碑式的版本。作为开发者，我们不仅是这场变革的见证者，更是直接的参与者和受益者。
立即行动：在你的测试集群上部署 v1.36，体验这些新特性；为你的团队制定一个清晰的迁移路线图；将 GitOps 理念引入流量管理。当下一个 LTS 版本发布时，你会发现 v1.36 所做的这些投资已经完全值得了。
参考链接
- Kubernetes v1.36 Release Notes
- Gateway API 官方文档
- User Namespaces 官方文档
- Mutating Admission Policies 官方文档
- Ingress NGINX 退役公告
本文首发于 程序员茄子，如需转载，请注明出处。