编程 Kubernetes v1.36 深度实战：当「Haru（春）」让云原生再进化——从 Pod User Namespaces 安全隔离、Mutating Admission Policies 到 DRA GPU 调度与 Ingress NGINX 退役迁移的完整工程指南（2026）

2026-07-21 05:42:44 +0800 CST views 44

Kubernetes v1.36 深度实战：当「Haru（春）」让云原生再进化——从 Pod User Namespaces 安全隔离、Mutating Admission Policies 到 DRA GPU 调度与 Ingress NGINX 退役迁移的完整工程指南（2026）

2026 年 4 月 22 日，Kubernetes 社区交付了 2026 年的首个正式版本 v1.36，代号 Haru（春）。这个版本没有惊雷般的架构变革，而是把过去三四年埋下的种子一一催熟：Pod User Namespaces 终于 GA、Mutating Admission Policies 告别 Webhook Server、Dynamic Resource Allocation（DRA）让 GPU 成为一等公民、而服役多年的 Ingress NGINX 正式退役。本文从工程视角，把这些变化拆成「为什么、是什么、怎么落地、怎么优化」四层，配可运行代码，给一线平台与研发同学一份能直接照做的升级手册。

一、背景介绍：为什么 v1.36 是「收口」之年

1.1 一个关于「等待与兑现」的版本

Kubernetes 的发布节奏很稳：每个大版本约 4 个月一更。v1.36 的 Release Lead 来自日本社区（Ryota Sawada），代号取自日语「ハル（Haru）」——春。上一个版本 Timbernetes（世界树）在 2025 年为这一年画下句点，Haru 则用一个新季节的姿态开启了 2026 的第一次更新。

先看一组数字：

71 项增强（KEP）
18 项毕业至 Stable（GA）
26 项进入 Beta

和过去几个「疯狂扩张」的版本相比，v1.36 的关键词不是「扩张」，而是**「收口」**——一批在 Alpha 阶段跋涉了三四年的老功能，这次终于熬出头。对运维和平台团队来说，这种版本比「新增一堆实验性开关」更有价值：你可以少用几个第三方工具，少维护几套自研组件，平台本身正在替你兜底。

1.2 三条主轴

官方与社区把 v1.36 的重心归纳为三条：

安全默认强化（Security Defaults）：User Namespaces GA、Mutating Admission Policies GA，让「零信任」从需要自研/三方组件，变成开箱即用的原生能力。
AI/ML 工作负载成熟：DRA 一系列 GA/Beta 增强，让 GPU、NPU、RDMA 等异构资源拥有结构化、拓扑感知的调度能力。
大规模 API 可扩展性：Mixed Version Proxy、指标与组件健康检查改进，让超大规模集群的升级与运维更平滑。

1.3 对工程团队的真实意义

很多团队对「升级 K8s」又爱又恨：新特性诱人，但破坏性变更、废弃 API、Webhook 兼容性像地雷。v1.36 的「收口」气质，恰恰意味着它对多数团队是低风险的红利版本：

不用再为 Pod 安全隔离引入 gVisor / Kata 的额外运行时复杂度；
不用再为「注入 sidecar / 强制打标」维护一套 Mutating Webhook 服务（含 TLS、CA、高可用）；
GPU 训练任务可以声明式地要求「H100 + 同一 NUMA 节点」，而不是在脚本里手动算 PCIe 拓扑；
入口从 Ingress 平滑迁移到 Gateway API，告别 NGINX Ingress 退役带来的安全真空。

下面我们逐层拆解。

二、核心概念：三个 GA 能力与一批 Beta 工程件

2.1 Pod User Namespaces（GA）

这是整个 v1.36 最值得讲清楚的特性。它从 Kubernetes v1.25（2022 年 8 月） 进入 Alpha，历经约四年、跨越多个内核与运行时版本，终于在 v1.36 毕业到 GA。

它解决什么问题？ 传统容器里，容器内以 root（UID 0）运行的进程，在宿主机内核视角里也对应着特权上下文。一旦容器逃逸（比如某个内核漏洞被利用），攻击者拿到的就是节点层面的高权限。User Namespaces 的思路是：给每个 Pod 一个独立的用户 ID 命名空间，把容器里的 UID 0 映射到宿主机上一个完全无特权的 UID。即使进程突破了容器边界，在宿主节点上也「几乎什么都做不了」。

启用方式极其克制——一个布尔字段：

apiVersion: v1
kind: Pod
metadata:
  name: hardened
spec:
  hostUsers: false   # 关键：让该 Pod 运行在独立 user namespace 中
  containers:
    - name: app
      image: my-app:1.0
      securityContext:
        runAsNonRoot: true

过去要做到这种级别的隔离，要么依赖 gVisor、Kata Containers 等独立运行时（引入额外复杂度与性能损耗），要么依赖繁琐的 seccomp/AppArmor 配置。User Namespaces 把这件事降维成「一行声明」。

2.2 Mutating Admission Policies（GA）

Kubernetes 的准入控制（Admission Control）是「请求到达 etcd 之前最后一公里的改动机会」。过去你想做「自动注入 sidecar」「强制打安全标签」「给没有 resource 的 Pod 补默认资源」，标准做法是用 MutatingAdmissionWebhook：写一个 HTTP 服务，部署进集群，配置 TLS 证书、CA、超时、重试、高可用……运维负担极重，而且 Webhook 挂掉会直接雪崩整个集群的创建请求。

v1.36 把 MutatingAdmissionPolicy 推至 GA 并默认开启。变更逻辑可以用原生 Kubernetes 对象直接表达，底层基于 CEL（Common Expression Language），彻底摆脱 Webhook Server 依赖。配合早先 GA 的 ValidatingAdmissionPolicy，准入控制进入「声明式」时代：

策略即 YAML，纳入 GitOps，review/回滚和普通资源一样；
无独立服务、无 TLS/CA、无「Webhook 超时导致集群创建全挂」的事故面；
CEL 表达式由 kube-apiserver 编译并缓存，性能稳定可预测。

2.3 Dynamic Resource Allocation（DRA）一系列增强

AI/ML 时代，GPU 是最金贵、也最难调度的资源。Kubernetes 传统的 resources.limits.nvidia.com/gpu: 1 只能做「整数张数」的粗粒度分配，无法表达「要同一 NUMA 节点的两张 H100」「要支持 MIG 切分的某块卡」「要带 RDMA 网卡亲和」这类诉求。

DRA 是为此而生的资源模型，v1.36 把它大幅催熟：

能力	状态	说明
DRA 可消费容量（Consumable Capacity）	GA（默认开启）	支持对设备容量做可分区消费
DRA 优先列表（Prioritization List）	GA	调度器按优先级列表挑选最优设备
DRA 管理员访问（Admin Access）	GA	管理员可读设备状态
DRA 设备绑定条件（Device Binding Conditions）	Beta（默认开启）	设备绑定状态可观测、可条件化
DRA 设备污点与容忍（Device Taints/Tolerations）	Beta	类比节点污点，标记「不可用/需特定容忍」的设备
DRA 分区设备（Partitionable Devices）	Beta	一块物理卡可切成多份分配
DRA 原生资源映射（Native Resource Mapping）	Alpha	把设备映射回原生 CPU/内存资源

对做大模型训练/推理的团队，这等于把「GPU 拓扑调度」从「写一堆脚本 + 祈祷」变成「声明式 YAML」。

2.4 其他重要变更清单

Ingress NGINX 退役：2026 年 3 月，SIG Network 与安全响应委员会宣布 Ingress NGINX 项目正式退役，不再发布、不再修 bug/安全漏洞。迁移到 Gateway API 已成必答题。
Mixed Version Proxy（混合版本代理）：Beta 且默认开启（UnknownVersionInteroperabilityProxy）。多 apiserver 版本并存升级时，自动把请求代理到正确版本的 apiserver，避免升级期间出现意外 404。
调度器 PreBind 插件并行化：调度器框架现在支持并行运行 PreBind 插件，自定义插件需实现 PreBindPreFlight 显式允许并行。
监控指标重命名：volume_operation_total_errors → volume_operation_errors_total；etcd_bookmark_counts → etcd_bookmark_total。自定义监控/告警需同步更新。
kubeadm 移除 FlexVolume 内置支持：如需继续用，需自定义 KCM 镜像并手动挂载插件目录。
OCI VolumeSource：新增 spec.volumes[].oci，可直接把 OCI 制品（如制品仓库里的工件）挂载为卷。
Workload / PodGroup API（scheduling.k8s.io/v1alpha2）：引入工作负载级调度（Gang Scheduling），让「一组 Pod 要么全调度、要么都不调度」成为原生能力。

三、架构分析

3.1 User Namespaces 的内核底座

Linux 的 user_namespaces 机制允许一个进程拥有独立的 UID/GID 映射表。内核通过 /proc/<pid>/uid_map 与 /proc/<pid>/gid_map 描述「命名空间内的 ID」到「宿主命名空间 ID」的映射。容器运行时（containerd / CRI-O）在创建 Pod 的 Pause 容器与业务容器时，为其建立一份「把容器内 UID 0 映射到宿主机某个大号非特权 UID（如 100000+）」的映射。

kubelet 在这里的角色是「编排者」：它读取 Pod 的 spec.hostUsers，与运行时协商是否启用 user namespace，并确保底层内核（需要较新的 Linux 内核与运行时版本）支持。架构上的关键差异：

方案	隔离强度	额外运行时	性能损耗	运维复杂度
传统容器 + rootless 配置	中	无	极低	中（需仔细配 capability）
gVisor / Kata	高（含系统调用拦截/微 VM）	需要	中~高	高
Pod User Namespaces（v1.36 GA）	高（UID 映射 + 逃逸后无特权）	无	极低	低（一行声明）

换句话说，User Namespaces 用「内核原生能力」换来了接近 gVisor 的安全收益，却几乎不付性能与运维代价——这正是它值得在所有通用负载上默认开启的原因。

3.2 Mutating Admission Policies 的 CEL 引擎

CEL 是 Google 为策略场景设计的轻量表达式语言，Kubernetes 在 ValidatingAdmissionPolicy 中已验证多年，v1.36 把同样的能力扩展到「变更（mutate）」。

其执行链路：

kube-apiserver 收到创建/更新请求；
依据 matchConstraints 判断该资源是否命中某条 MutatingAdmissionPolicy；
编译并类型检查 CEL 表达式（结果缓存，避免每次请求重编译）；
执行 mutations[].applyConfiguration.expression，返回一份「部分对象（partial object）」；
用 Server-Side Apply 语义把这份补丁合并进原对象，写回 etcd。

与 Webhook 的核心差异在于信任边界与故障域：Webhook 是 apiserver 之外的网络调用，任何 CA 过期、Pod 重启、网络抖动都会放大成集群级事故；而 CEL Policy 是 apiserver 进程内的纯计算，没有外部依赖，失败可预测、可回滚、可被单元测试覆盖。

3.3 DRA 的调度路径

DRA 的资源模型由四类对象构成：

DeviceClass：对一类设备的抽象（如 nvidia-gpu、rdma-nic），可携带默认选择参数。
ResourceSlice：由设备插件（Device Plugin）上报，描述「节点上有哪些具体设备、容量多少、属性如何」。
ResourceClaim / ResourceClaimTemplate：Pod 对设备的「申领」。Template 形式下，每个 Pod 副本会生成独立 Claim。
Pod 引用：Pod 通过 spec.resourceClaims + 容器 resources.claims 把 Claim 挂到容器。

调度器在调度 Pod 时，会先根据 Claim 的 selectors（支持 CEL 表达式，如「型号 == H100」「拓扑域 == node-1」）在 ResourceSlice 中挑设备，再结合节点亲和、NUMA 拓扑做联合决策。这就是「结构化参数（structured parameters）」取代旧 scheduler.extender 的思路——调度决策留在原生调度器内，而不是甩给外部扩展器。

3.4 流量入口的范式切换

Ingress（networking.k8s.io/v1）的设计目标是「简单 L7 路由」，字段里有大量 NGINX 专属 annotation（nginx.ingress.kubernetes.io/...），可移植性差，也无法优雅表达 TCP/UDP、分层 Gateway、多租户流量切分。

Gateway API（gateway.networking.k8s.io/v1）把「谁拥有负载均衡器」「流量如何路由」「谁能引用」拆成三个角色：

GatewayClass：由基础设施提供商实现（如 Envoy、Contour、Istio）。
Gateway：集群运维/平台团队拥有，描述「监听哪些端口、用什么 TLS、允许哪些命名空间挂路由」。
HTTPRoute / TCPRoute / ...：应用团队拥有，描述「host + path 匹配到哪个 Service」。

这种「角色分离」天然契合企业多团队治理——平台团队把控入口安全边界，业务团队自助发布路由，互不越权。

四、代码实战

下面所有 YAML 均可在支持 v1.36 的集群上直接 kubectl apply -f。

4.1 实战一：开启 Pod User Namespaces 并验证

第一步，确认节点内核与运行时支持（containerd ≥ 某新版本 / CRI-O 对应版本），然后直接声明：

# 01-userns.yaml
apiVersion: v1
kind: Pod
metadata:
  name: hardened
  labels:
    app: demo
spec:
  hostUsers: false          # 核心开关：独立 user namespace
  containers:
    - name: app
      image: busybox:1.36
      command: ["/bin/sh", "-c", "sleep 9999"]
      securityContext:
        runAsNonRoot: true   # 配合，双保险

验证容器内看自己是 root，但宿主机视角是无特权用户：

# 容器内：看到的是 UID 0（自以为 root）
kubectl exec hardened -- id
# uid=0(root) gid=0(root)

# 看 uid 映射：容器内 0 被映射到宿主机的大号 UID
kubectl exec hardened -- cat /proc/self/uid_map
# 0 100000 65536   # 容器内 0 ~ 65535 映射到宿主 100000 ~ 165535

# 在节点上另开一个 shell，找到该容器进程的真实 UID
# 可见其在宿主命名空间里并非 0，逃逸后拿不到节点特权
ps -o pid,user,comm -C busybox

工程建议：把 spec.hostUsers: false 写进团队的 Pod 安全「基线模板」，配合 Pod Security Admission 的 restricted 档位，作为所有通用负载的默认。

4.2 实战二：用 MutatingAdmissionPolicy 自动注入 sidecar

需求：所有新建 Pod 自动追加一个日志 sidecar，无需业务改代码、无需维护 Webhook 服务。

# 02-mutating-policy.yaml
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: "add-log-sidecar"
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
  # 可选：排除系统命名空间
  matchConditions:
    - name: "exclude-system"
      expression: "!(object.metadata.namespace in ['kube-system','kube-public'])"
  mutations:
    - applyConfiguration:
        expression: >
          Object.withContainer({
            "name": "log-sidecar",
            "image": "busybox:1.36",
            "command": ["/bin/sh", "-c", "sleep 9999"],
            "volumeMounts": [{"name": "logs", "mountPath": "/var/log/app"}]
          })

说明：Object.withContainer({...}) 是 CEL「apply configuration」风格的构建器，返回「追加了一个容器的部分对象」。实际字段命名以官方 admissionregistration.k8s.io/v1 文档为准；核心语义——用 CEL 返回 partial object，由 apiserver 以 SSA 语义合并——是稳定的。

配合一条 ValidatingAdmissionPolicy 做「强制打安全标签」也很常见：

# 02b-validate-labels.yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: "require-team-label"
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: "object.metadata.labels.exists(l, l == 'team')"
      message: "所有 Pod 必须带 team 标签"

迁移收益：原本需要 1 个 Deployment + 1 个 Service + 1 套证书 + 1 份 Validating/MutatingWebhookConfiguration 的活儿，现在变成 2 个 YAML，随 GitOps 一起 versioned。

4.3 实战三：用 DRA 声明式调度 GPU（带拓扑约束）

先定义一个 DeviceClass（可由 GPU 设备插件自动创建，这里展示如何加默认选择器）：

# 03-deviceclass.yaml
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: nvidia-gpu
spec:
  # 默认选择参数（可选）
  selectors:
    - cel:
        expression: "device.driver == 'nvidia'"

用 ResourceClaimTemplate 让每个训练 Pod 拿到独立 Claim，并用 CEL selector 要求「H100 且在同一 NUMA 节点」：

# 04-gpu-claim-template.yaml
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: h100-claim-template
spec:
  spec:
    devices:
      requests:
        - name: gpu
          deviceClassName: nvidia-gpu
          selectors:
            - cel:
                expression: >
                  device.attributes['nvidia.com/gpu'].model == 'H100' &&
                  device.attributes['nvidia.com/gpu'].nodemask == 0

Pod 引用该 Template：

# 05-gpu-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: cuda-train
spec:
  containers:
    - name: trainer
      image: nvcr.io/nvidia/pytorch:24.04-py3
      command: ["python", "train.py"]
      resources:
        claims:
          - name: gpu
  resourceClaims:
    - name: gpu
      resourceClaimTemplateName: h100-claim-template

调度器会据此在 ResourceSlice 中挑选满足「H100 + NUMA 0」的物理卡，避免训练任务跨 PCIe 交换机通信带来的带宽损耗。对多卡训练（NCCL）而言，这一步的拓扑正确性直接决定吞吐。

4.4 实战四：从 Ingress NGINX 迁移到 Gateway API

旧版（退役中，请勿在新集群继续使用）：

# 旧：Ingress NGINX（仅作对照，不推荐新部署）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc
                port:
                  number: 80

新版（Gateway API，推荐）：

# 06-gateway.yaml —— 平台团队拥有
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
spec:
  gatewayClassName: envoy          # 由基础设施提供
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: example-com-cert
      allowedRoutes:
        namespaces:
          from: All               # 允许业务命名空间挂路由
---
# 07-httproute.yaml —— 业务团队拥有
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route
spec:
  parentRefs:
    - name: prod-gateway
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web-svc
          port: 80

迁移要点：

先用 kubectl get ingressclass 清点存量 Ingress，按业务域分批迁移；
用 Gateway API 的 HTTPRoute 等价表达 path/host/backend，annotation 逻辑改用 filters（如 URLRewrite）表达；
灰度切流：新旧网关同时挂同一域名的不同权重，验证无误后下掉旧 Ingress；
用 gateway-api 的 ReferenceGrant 处理跨命名空间引用授权。

4.5 实战五：Mixed Version Proxy 让升级不再「心跳骤停」

多 apiserver 滚动升级时，旧版可能不认识新版才引入的资源。开启 UnknownVersionInteroperabilityProxy 后，apiserver 之间会自动代理跨版本请求：

# kube-apiserver 启动参数（示例）
kube-apiserver \
  --feature-gates=UnknownVersionInteroperabilityProxy=true \
  --peer-ca-file=/etc/kubernetes/pki/peer-ca.crt \
  --proxy-client-cert-file=/etc/kubernetes/pki/proxy-client.crt \
  --proxy-client-key-file=/etc/kubernetes/pki/proxy-client.key \
  --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt \
  --requestheader-allowed-names=front-proxy-client \
  --peer-advertise-ip=10.0.0.1 \
  --peer-advertise-port=6443

启用后，升级窗口内用户不会再因「新版资源被旧 apiserver 拒收」而看到 404，集群升级的可用性显著提升。

4.6 实战六：调度器 PreBind 并行与 Gang 调度

若你维护了自定义调度器插件，v1.36 的 PreBind 默认可并行。需显式声明允许：

// myplugin.go（调度器插件片段）
func (pl *myPlugin) PreBindPreFlight(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
) (*framework.PreBindPreFlightResult, *framework.Status) {
    // 声明本插件的 PreBind 可并行执行
    return &framework.PreBindPreFlightResult{AllowParallel: true}, nil
}

func (pl *myPlugin) PreBind(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
    nodeName string,
) *framework.Status {
    // 原有绑定前逻辑……
    return nil
}

对于「一组 Pod 必须一起调度」的分布式训练/大数据作业，v1.36 引入的 Workload / PodGroup API（scheduling.k8s.io/v1alpha2） 提供原生 Gang 调度能力。其语义是：只有当一个 Workload 下所有 PodGroup 的 minMember 都能满足时，才统一放行调度，避免「部分副本起来、互相等不到同伴」的资源死锁。迁移自研 Gang 调度器的团队，可评估直接用该 API 替代。

五、性能优化与运维

5.1 立刻检查你的监控告警

v1.36 重命名了若干指标，若你的 Grafana 面板或 Prometheus 告警直接引用旧名，升级后会静默失效：

旧指标名	新指标名
`volume_operation_total_errors`	`volume_operation_errors_total`
`etcd_bookmark_counts`	`etcd_bookmark_total`

升级前，用 grep 扫一遍告警规则与面板 JSON，提前改好。

5.2 调度器 PreBind 并行的真实收益

在大规模集群（数千节点、绑定阶段涉及大量 PVC/设备校验）中，PreBind 串行曾是创建延迟的隐形瓶颈。把无副作用、可并行的 PreBind 插件（如某些标签补全、卷存在性校验）声明 AllowParallel: true，可在创建高峰把「Pod 已调度→已绑定」的尾延迟明显压低。

5.3 DRA 对大模型训练的「拓扑红利」

很多人以为 GPU 调度只是「数卡」。实际上，跨 NUMA、跨 PCIe 交换机的两张卡，其 NCCL 通信带宽可能相差数倍。DRA 的 CEL selector + 设备属性（model / NUMA mask / 带宽等级）让你可以把拓扑约束写进声明，调度器据此联合决策。这在千卡训练里，直接体现为更短的单 step 时间、更稳的吞吐曲线。

5.4 升级检查清单（建议照做）

入口前置：清点 Ingress NGINX 存量，制定 Gateway API 迁移计划（v1.36 不强制删除，但安全更新已停）。
FeatureGate 默认值：Mixed Version Proxy 默认开，确认你的 apiserver 启动参数与之兼容。
kubeadm FlexVolume：若仍依赖 FlexVolume，需提前准备自定义 KCM 镜像与插件挂载。
指标重命名：更新监控/告警（见 5.1）。
Webhook 收敛：评估哪些 Mutating/Validating Webhook 可改写为原生 Policy，减少故障域。
灰度节奏：先升级测试集群 → 抱 IMP（Mixed Version Proxy）做控制面滚动 → 最后升级节点 kubelet。

六、总结展望

v1.36「Haru（春）」的气质，是稳中见功夫。它没有用颠覆性范式刷存在感，而是把多年沉淀的能力，一一交付成你今天就能用的默认行为：

安全默认：Pod User Namespaces 把「容器逃逸后的权限」压到极低；Mutating/Validating Admission Policies 用 CEL 取代 Webhook，让准入逻辑回归声明式、可 GitOps、可单测。平台团队可以关掉一批自研/三方组件，运维负担结构性下降。
AI 负载成一等公民：DRA 在 v1.36 大规模毕业，GPU/NPU/RDMA 的拓扑感知调度从「脚本玄学」变成「YAML 声明」。这对正在卷大模型训练效率的团队，是实打实的红利。
入口现代化：Ingress NGINX 退役不是终点，而是 Gateway API 全面接管流量的起点。角色分离的治理模型，更适配企业多团队现实。
可扩展性兜底：Mixed Version Proxy、指标与组件健康改进，让超大规模集群的升级不再让人「心跳骤停」。

给团队的建议很直接：v1.36 是一个低风险、高回报的升级目标。它不像某些「激进大版本」那样要求你重写大量 YAML，而是悄悄替你把安全与调度的基础打牢。趁 Ingress NGINX 退役的窗口，把入口迁到 Gateway API；趁 User Namespaces 与 Admission Policies GA，把那些年维护的 Webhook 收进历史；趁 DRA 成熟，把 GPU 调度的主动权交还给声明式配置。

云原生的下一个春天，不靠某一个颠覆性特性，而靠这些「终于稳了」的底座。Haru，名副其实。

本文基于 Kubernetes v1.36（Haru，2026-04-22）官方发布说明与社区技术解读整理，代码示例以实际集群版本为准，建议在测试环境验证后落地生产。