Kubernetes 1.36版本要来了

Kubernetes 1.36将于2026年4月22日正式发布，将聚焦AI硬件支持强化、网络架构升级、安全性与可维护性提升三大核心方向，同时引入多项实用特性并清理历史债务。以下是可能的新特性与变化详情：

1. 核心新特性

1.1 动态资源分配（DRA）增强：AI硬件精细化管控

Kubernetes 1.36进一步强化动态资源分配（DRA）对AI加速硬件（如GPU、TPU、FPGA）的支持，通过硬件级污点（Taints）与容忍度（Tolerations）机制，实现专用资源的精准绑定。

• 核心机制：为AI节点（如搭载NVIDIA GPU的节点）添加nvidia.com/gpu:NoSchedule等污点，仅允许声明对应容忍度（如tolerations: - key: "nvidia.com/gpu" operator: "Exists"）的工作负载调度至该节点。
• 价值：避免非AI工作负载占用昂贵的AI硬件资源，同时支持多租户场景下硬件资源的隔离与共享，解决了传统调度方式中“硬件资源被误用”或“关键 workload 无法获取资源”的痛点。

1.2 OCI制品挂载稳定化：标准化镜像管理

OCI（开放容器倡议）规范的制品挂载功能在1.36版本中升级为稳定（GA），成为Kubernetes容器运行的标准方式。

• 具体要求：kubelet会验证容器镜像是否符合OCI标准（如通过SHA-256校验和验证完整性），非OCI格式的镜像（如 legacy Docker 镜像）将被拒绝启动。
• 影响：推动镜像生态的标准化，减少因镜像格式不兼容导致的部署失败，同时为后续容器运行时的升级（如containerd 2.x）奠定基础。

1.3 HPA逻辑优化：消除“幽灵Pod”干扰

水平Pod自动伸缩（HPA）引入Alpha特性，优化指标收集逻辑，仅考虑目标工作负载直接管理的Pod指标（如排除处于Terminating状态的“幽灵Pod”或孤儿Pod）。

• 解决的问题：过往HPA可能因“无关Pod”的指标波动导致误伸缩（如旧版本Pod未完全终止时，其指标仍被计入HPA计算），此次优化使HPA决策更准确。

1.4 网络架构升级：Gateway API上位与kube-proxy转型

• Gateway API推广：Kubernetes社区逐步淡化对Ingress NGINX的依赖，推荐使用Gateway API（官方项目）作为新一代流量管理方案。Gateway API支持更丰富的协议（如HTTP/3、TCP/UDP）、跨命名空间引用及角色解耦（基础设施提供者、集群运维、应用开发者分工明确），是未来流量管理的“主流方向”。
• kube-proxy转向eBPF：kube-proxy的IPVS模式在1.35中被弃用，1.36版本彻底移除，全面转向基于nftables（默认）或eBPF（高性能）的服务代理方案。eBPF方案可提供更低的内核开销、更优的流量转发性能，适合大规模集群场景。

1.5 容器运行时与Windows支持：对齐未来生态

• containerd 1.6支持终止：1.36是最后一个支持containerd 1.6.x的版本，后续将强制要求使用containerd 2.x。此举旨在推动容器运行时生态的升级，利用containerd 2.x的新特性（如更高效的镜像管理、增强的安全性）。
• Windows容器支持进化：持续优化Windows容器的调度与管理能力，支持在同一集群中混合部署Linux微服务与Windows传统应用（如.NET Framework应用），提升混合架构场景下的稳定性与兼容性。

2. 重要变化与弃用**

2.1 移除gitRepo卷驱动：清理历史债务

gitRepo卷驱动（用于在Pod启动时克隆Git仓库）被彻底移除。过往该驱动存在“克隆过程不可控”“安全风险（如私钥泄露）”等问题，推荐替代方案：

• 静态内容：使用ConfigMap或Secret存储配置文件；
• 动态同步：使用GitOps工具（如Flux、Argo CD）实现Git仓库与工作负载的自动同步。

2.2 弃用service.spec.externalIPs：外部IP管理外部化

service.spec.externalIPs字段（用于手动指定Service的外部IP）被弃用，外部IP管理职责转移至外部工具（如Ingress控制器、云负载均衡器）。

• 影响：需通过云厂商提供的负载均衡器（如AWS NLB、GCP Cloud Load Balancing）或Ingress控制器（如NGINX Ingress、Traefik）实现外部IP的分配与管理，避免直接在Kubernetes API中配置。

2.3 apiserver就绪检查：等待watch缓存初始化

kube-apiserver的/readyz端点默认启用WatchCacheInitializationPostStartHook，即apiserver会等待watch缓存初始化完成后才报告“就绪”状态。

• 解决的问题：过往apiserver可能在watch缓存未完全初始化时就报告就绪，导致控制器（如Deployment、StatefulSet）提前发起list+watch请求，引发“惊群效应”（大量请求涌入apiserver，导致性能下降）。
• 注意事项：需调整外部负载均衡器或健康检查工具的超时时间（如延长至30秒以上），避免因apiserver就绪检查延迟导致的不必要重启。

3. 其他改进

• watch_list_duration_seconds指标升级：该指标（用于监控watch-list操作的耗时）从Alpha升级为Beta，提供更稳定的SLO（服务级别目标）参考，帮助用户识别watch操作的性能瓶颈。
• 安全增强：通过AuthorizePodWebsocketUpgradeCreatePermission（Beta）等特性，强化Pod的WebSocket连接权限管理，减少未授权访问风险。

4.总结

Kubernetes 1.36版本的更新重点在于适配AI时代的硬件需求（DRA增强）、推动网络架构现代化（Gateway API与eBPF）、清理历史债务（移除gitRepo、externalIPs）及提升稳定性（apiserver就绪检查优化）。

对于企业用户而言，需重点关注：

• AI硬件资源的精细化管控（如GPU节点的污点与容忍度配置）；
• 网络方案的迁移（从Ingress NGINX转向Gateway API）；
• 容器运行时与Windows支持的升级（containerd 2.x、Windows容器优化）；
• 历史债务的清理（gitRepo替换为GitOps、externalIPs迁移至外部负载均衡器）。