Kubernetes v1.36 Haru 发布：70 个增强功能全解析
Kubernetes v1.36（代号 Haru）于 2026 年 4 月正式发布，带来 70 个增强功能——18 个晋升 Stable、25 个进入 Beta、25 个全新 Alpha。本文重点解析最具实用价值的变化：User Namespaces 正式 GA（容器隔离再进一步）、Mutating Admission Policies GA（无需 Webhook 即可做变更控制）、In-Place Pod 资源调整 GA（不重启修改 CPU/内存）、Sidecar 容器生命周期正式稳定，以及 Ingress NGINX 已于 2026 年 3 月正式退役、社区建议迁往 Gateway API。
Kubernetes v1.36 于 2026 年 4 月 22 日正式发布，代号 Haru（春），是 2026 年第一个主要版本。这次发布包含 70 个增强功能：18 个晋升 Stable、25 个进入 Beta、25 个全新 Alpha。
本文挑出最值得运维和开发团队关注的变化，逐一说清楚它能解决什么问题。
版本信息速览
版本： v1.36.0（2026-04-22 发布）
代号： Haru（日语"春"）
最新补丁：v1.36.2（2026-06-09）
EOL： 2027-06-28
增强统计：
Stable（GA）：18 个
Beta： 25 个
Alpha： 25 个
总计： 70 个重要：Ingress NGINX 已正式退役
在讲新功能之前，先说一个影响面最广的变化。
Ingress NGINX 于 2026 年 3 月 24 日停止维护，Kubernetes SIG Network 和安全响应委员会宣布：从该日起，不再有新版本发布、不再修复 Bug、不再修补安全漏洞。
受影响的仓库：kubernetes/ingress-nginx
停止维护时间：2026-03-24
如果你的集群仍在使用 ingress-nginx：
✗ 不会再有安全补丁
✗ 不会再有 Kubernetes 新版本的兼容性更新
→ 应当尽快迁移到替代方案
推荐迁移方向：
Gateway API（官方推荐，是 Ingress 的继任者）
Envoy Gateway（基于 Gateway API 的实现）
Cilium Gateway（如果集群已用 Cilium CNI）
Nginx Gateway Fabric（NGINX 官方支持的 Gateway API 实现）迁移方法会在另一篇文章中详细讲解，这里先提醒大家尽快评估影响范围。
GA（Stable）重点功能
1. User Namespaces 正式 GA
User Namespaces 是 Linux 内核功能，允许容器内的 root 用户映射到宿主机上的非特权用户。v1.36 让这个功能正式进入 Stable 状态。
功能解决的问题：
容器内进程以 root（UID 0）运行很常见
但如果容器逃逸，宿主机上对应的也是 root → 危险
User Namespaces 的作用：
容器内 UID 0（root）→ 宿主机 UID 65536（普通用户）
即使容器被突破，攻击者拿到的也只是宿主机的非特权身份
启用方式：
在 Pod spec 中设置 hostUsers: false
示例：apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
hostUsers: false # 启用 User Namespace 隔离
containers:
- name: app
image: nginx:alpine
securityContext:
runAsUser: 0 # 容器内以 root 运行
# 但宿主机上映射到非特权 UID注意事项：
需要宿主机内核 >= 5.19（推荐 6.x）
需要使用支持 idmap 挂载的文件系统（ext4/xfs/overlayfs）
hostNetwork: true 或 hostPID: true 时不可用
安全收益：
明显降低容器逃逸的影响半径
不需要改应用代码，只改 Pod spec2. Mutating Admission Policies GA
v1.36 之前，如果你需要自动修改进入集群的资源（比如给所有 Pod 自动加标签、注入 sidecar），必须部署和维护一个 Webhook 服务。
现在有了 MutatingAdmissionPolicy——直接在集群内用 CEL 表达式写变更逻辑，不需要额外的 Webhook 服务。
# 示例：给所有没有 environment 标签的 Pod 自动加上 environment=default
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
name: add-default-environment-label
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["pods"]
mutations:
- patchType: ApplyConfiguration
applyConfiguration:
expression: >
Object{
metadata: Object.metadata{
labels: object.metadata.?labels.orValue({}) +
(has(object.metadata.labels) &&
"environment" in object.metadata.labels
? {}
: {"environment": "default"})
}
}
---
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicyBinding
metadata:
name: add-default-environment-label-binding
spec:
policyName: add-default-environment-label
validationActions: [Deny]对比传统 Webhook 的优势：
不需要部署额外服务（减少运维负担）
不需要维护 TLS 证书
逻辑直接存在 etcd 中，审计更方便
CEL 表达式有沙箱保护，不会因代码 Bug 导致集群不可用
适用场景：
自动注入标准标签/注解
强制设置资源默认值（如 imagePullPolicy）
自动调整资源限制（如内存 limit 不能超过 request 的 2 倍）3. Fine-Grained Kubelet API Authorization GA
之前 Kubelet API 的权限控制比较粗糙——要么能访问，要么不能访问。v1.36 让这个权限可以细粒度控制。
实际意义：
可以给不同的系统组件分配不同的 Kubelet API 权限
比如：监控系统只能读 /metrics，不能执行 exec
减少最小权限原则下的过度授权
对 CIS 安全基线合规有帮助4. SELinux 卷挂载优化 GA
涉及 SELinux 的卷挂载现在有了更好的性能优化，减少了容器启动时 SELinux 标签重新打标的开销。
影响场景：
容器挂载大量文件的 Volume 时启动很慢（SELinux 打标导致）
GA 后，通过 idmap 挂载绕过逐文件打标，启动速度大幅提升
对运行 SELinux 的 RHEL/CentOS 集群有明显收益Beta 重点功能
In-Place Pod 资源调整（进入 Beta）
这是 v1.36 中最实用的功能之一。传统上，修改 Pod 的 CPU/Memory 限制必须删除重建 Pod（Deployment 会触发滚动更新）。
In-Place Pod Resizing 允许在不重启 Pod 的情况下动态调整资源配额。
# 创建一个 Pod
apiVersion: v1
kind: Pod
metadata:
name: resize-demo
spec:
containers:
- name: app
image: nginx:alpine
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "200m"
memory: "256Mi"
resizePolicy:
- resourceName: cpu
restartPolicy: NotRequired # CPU 调整不需要重启
- resourceName: memory
restartPolicy: NotRequired # 内存调整不需要重启# 直接 patch，不触发 Pod 重建
kubectl patch pod resize-demo --subresource=resize \
--patch='{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"200m","memory":"256Mi"},"limits":{"cpu":"400m","memory":"512Mi"}}}]}}'
# 查看调整状态
kubectl describe pod resize-demo | grep -A 5 "Resize"使用场景：
流量高峰临时扩容（不影响正在处理的请求）
HPA 纵向扩展（VPA + In-Place）
减少不必要的 Pod 重启带来的服务中断
注意：
部分内存调整仍可能需要重启（取决于应用行为）
restartPolicy 字段控制调整策略Sidecar 容器生命周期稳定化（Beta）
v1.29 引入的 Sidecar 容器（通过 initContainers + restartPolicy: Always 实现）在 v1.36 进一步稳定，解决了更多边缘场景下的生命周期问题。
apiVersion: v1
kind: Pod
metadata:
name: pod-with-sidecar
spec:
initContainers:
- name: log-agent # Sidecar：以 initContainer 形式声明
image: fluent/fluent-bit:latest
restartPolicy: Always # 关键：设为 Always 才是 Sidecar 语义
volumeMounts:
- name: logs
mountPath: /var/log/app
containers:
- name: app
image: my-app:latest
volumeMounts:
- name: logs
mountPath: /var/log/app
volumes:
- name: logs
emptyDir: {}Sidecar 语义保证：
主容器启动前，Sidecar 先启动并 Ready
主容器退出后，Sidecar 才退出（不会先于主容器被杀）
Job 完成时，Sidecar 跟随正确关闭（解决了旧方式 Job hang 的问题）
典型使用场景：
日志采集（Fluentd/Fluent Bit）
服务网格代理（Envoy/Istio）
配置热加载 AgentDynamic Resource Allocation（DRA）进入 Beta
DRA 解决的是 GPU、FPGA、高速网卡等特殊硬件资源的调度问题。
当前状态（v1.36 Beta）：
Structured Parameters（结构化参数）GA
基本的 ResourceClaim API 稳定
意义：
GPU 调度不再只能依赖简单的 nvidia.com/gpu: 1
可以描述复杂的硬件拓扑需求（比如要求两个 GPU 在同一个 NVLink 域内）
AI 训练集群的调度效率明显提升升级注意事项
从 v1.35 升级到 v1.36：
移除/变更的 API（需提前确认）：
检查命令：kubectl api-resources --verbs=list
重点检查：
如果使用了 Ingress NGINX → 制定迁移计划
如果使用了旧的 Admission Webhook → 评估迁移到 CEL Policy
升级顺序（多节点集群）：
1. 升级控制平面（先备份 etcd）
2. 确认控制平面健康
3. 逐节点升级工作节点（drain → 升级 → uncordon）
kubeadm 升级命令：# 查看可用版本
kubeadm upgrade plan
# 升级控制平面
kubeadm upgrade apply v1.36.2
# 升级 kubelet（每个节点）
apt-get update && apt-get install -y kubelet=1.36.2-* kubeadm=1.36.2-*
systemctl daemon-reload && systemctl restart kubelet小结
v1.36 的核心主题是安全加固和 AI 工作负载支持。
User Namespaces GA 和 Fine-Grained Kubelet Authorization GA 让集群安全基线更高；In-Place Pod Resizing Beta 和 DRA Beta 直接针对 AI 训练/推理工作负载的动态资源管理痛点；Mutating Admission Policies GA 则让策略管理更简单、更安全。
Ingress NGINX 退役是这次最需要行动的变化——如果你的集群还在使用，现在就应该开始规划迁移了。