kubernetes 1.35的新特性和变化

Kubernetes v1.35（代号“Timbernetes”，意为“世界树”）于2025年12月17日正式发布，作为2025年的收官版本，其核心主题是通过“嫁接”新功能（增长）与“修剪”旧特性（优化），推动集群的稳定性、安全性与可扩展性进一步提升。本次发布共包含60项增强功能，其中17项升级为稳定（GA）、19项进入测试（Beta）、22项为新增（Alpha），同时伴随多项关键特性的弃用与移除。以下从核心功能升级、新特性解析、弃用与移除、生态与社区四大维度，详细阐述v1.35的重要变化：

1. 核心功能升级：稳定特性落地，提升生产可用性

v1.35的17项稳定特性聚焦于解决用户长期以来的痛点，尤其在资源管理、调度可靠性、网络流量控制等方面实现突破，直接提升生产环境的稳定性与易用性。

1.1 Pod资源原地更新（In-place Update）：无需重启的动态资源调整（GA）

此特性可以说是1.35版本最有价值的特性，也是大家盼望已久的特性，终于升级为稳定特性了。在1.35版本之前，如果你想调整Pod的资源限制（比如给某个服务增加一些内存），驱除现有的POD，等待新的POD启动，重新调度到阶段，这对于一些有状态的应用，如数据库来说是致命问题，这相当于在新机器上完全重新拉去一个新数据库，导致因连接中断、事务回滚而导致的应用报错和中断，更有可能因为缓存失效导致CPU飙升。这也是为什么在kubernetes中跑数据库很危险的地方。当前1.35版本之后，如果节点的资源不足，仍然会回退到以前的模式，需要非常小心。

在之前的Kubernetes中，Pod的CPU/内存资源（.spec.resources）为不可变字段，修改需删除并重建Pod，导致有状态服务（如数据库、StatefulSet）或批处理任务中断。

1.35版本之后将“Pod资源原地更新”升级为稳定特性（KEP #1287），支持在不重启Pod或容器的情况下，动态调整CPU/内存的requests与limits。kubelet会通过CRI（容器运行时接口）直接向容器运行时发送资源调整请求，更新cgroup配置，确保Pod持续运行。

1.2 节点声明式特性（Node Declared Features）：解决版本偏移的调度难题（Alpha→Beta）

• 背景：集群升级时，控制平面（如API Server）可能先于工作节点启用新特性（如“Pod资源原地更新”），导致调度器将依赖新特性的Pod分配到未支持的旧节点，引发运行时错误。
• 变化：v1.35引入“节点声明式特性”框架（KEP #5328），允许节点通过.status.declaredFeatures字段向控制平面报告其支持的特性（如“UserNamespaces”“ImageVolumes”）。调度器、准入控制器可基于该信息，强制约束Pod仅调度到兼容节点，避免版本偏移问题。
• 价值
  • 提升调度准确性：确保Pod运行在支持其所需特性的节点上；
  • 简化集群管理：无需手动为节点打标签，降低运维成本；
  • 支持异构集群：兼容不同版本的节点，适应 gradual rollout（逐步升级）场景。

1.3 Pod证书（Pod Certificates）：原生工作负载身份与自动轮换（Beta）

之前的版本在如服务网格中的mTLS认证等任务是需依赖外部工具（如cert-manager、SPIFFE/SPIRE），通过sidecar或init容器实现证书的生成与轮换，增加了架构复杂度。v1.35推出“Pod证书”特性（KEP #4317），允许kubelet直接为Pod生成密钥、请求证书（通过PodCertificateRequest），并将证书与私钥挂载到Pod的文件系统中（如/var/run/secrets/kubernetes.io/serviceaccount/certs）。证书支持自动轮换，无需人工干预。
这个功能简化服务网格部署，如原生支持mTLS，无需额外工具；证书轮换自动化，降低证书泄露风险；无需管理sidecar容器或CRD，减少了运维开销。

1.4 流量路由优化：PreferSameNode与PreferSameZone（GA）

• 背景：传统Service的trafficDistribution字段仅支持“PreferClose”（优先路由到近端点），但未明确区分“节点级”与“区域级”偏好，导致流量路由不够精准。
• 变化：v1.35对trafficDistribution进行重构（KEP #3015）：
  • 新增PreferSameNode选项：优先路由到本地节点的端点（如Pod与Service在同一节点），降低延迟；
  • 将原有PreferClose重命名为PreferSameZone：明确指向同一可用区的端点，避免歧义。
• 价值：
  • 提升流量效率：PreferSameNode适用于对延迟敏感的应用（如边缘计算）；
  • 明确路由逻辑：PreferSameZone更符合用户对“区域级”流量的预期，减少配置错误。

2. 新特性解析：聚焦未来需求，拓展集群能力边界

v1.35的19项Beta特性与22项Alpha特性，主要围绕安全增强、存储管理、网络扩展、用户体验等方向，为未来的云原生场景（如AI/ML、边缘计算、多集群）奠定基础。

2.1 安全增强：用户命名空间与CSI Token传递优化

• 用户命名空间（User Namespaces）：更强的Pod隔离（Beta）（KEP #127）：
  传统Pod中，容器以root（UID 0）运行，若发生逃逸，攻击者可直接获取节点root权限。v1.35引入用户命名空间支持，允许将容器内的root用户映射到节点上的高编号非特权UID（如10000+），实现“容器内root、节点上非root”的隔离，降低逃逸风险。
• CSI Driver Token传递：敏感信息安全存储（Alpha）（KEP #5538）：
  传统CSI驱动（如云存储）需将服务账户令牌存储在VolumeContext（非敏感信息字段）中，存在泄露风险。v1.35新增serviceAccountTokenInSecrets字段，允许CSI驱动将令牌存储在Secrets（敏感信息字段）中，提升安全性。

2.2 存储管理：原生存储版本迁移与镜像清理优化

• 原生存储版本迁移（Native Storage Version Migration）：简化CRD升级（Beta）：
  传统Custom Resource Definition（CRD）升级时，需手动迁移存储版本（如从v1alpha1到v1），过程繁琐且易出错。v1.35将“原生存储版本迁移”升级为Beta，集成迁移逻辑到核心控制平面，支持自动转换CRD的存储版本，减少人工干预。
• 基于时间的镜像清理（Time-based Image Cleanup）：更灵活的磁盘管理（Alpha）（KEP #4210）：
  传统镜像清理仅基于磁盘使用率（如达到80%时清理未使用镜像），可能导致频繁清理或磁盘浪费。v1.35新增ImageMaximumGCAge配置，允许管理员指定“未使用镜像的最大存活时间”（如7天），到期后自动清理，优化磁盘资源利用。

2.3 网络扩展：Gateway API与本地节点优先路由

• Gateway API：替代Ingress NGINX的未来流量入口（Alpha）：
  由于维护成本高、技术债务重，Kubernetes项目宣布Ingress NGINX将于2026年3月退役。v1.35强化Gateway API的支持，将其作为推荐的流量入口方案，支持更复杂的路由规则（如路径-based、主机-based）与服务网格集成。
• 本地节点优先路由（PreferSameNode）：低延迟流量分发（GA）（KEP #3015）：
  如前所述，PreferSameNode选项允许Service优先将流量路由到本地节点的端点，适用于边缘计算或对延迟敏感的应用（如实时数据处理）。

3. 弃用与移除：清理技术债务，推动架构现代化

v1.35的弃用与移除主要集中在过时技术（如cgroup v1、containerd v1.x）与高维护成本特性（如kube-proxy IPVS模式），旨在减少技术债务，推动集群架构向更现代的方向演进。

3.1 移除cgroup v1支持：全面拥抱cgroup v2

• 背景：cgroup v1存在“控制组层次结构不一致”“资源隔离不完善”等问题，而cgroup v2通过统一的层次结构与更强大的资源控制（如IO权重、内存压力）解决了这些问题。Kubernetes自v1.25起支持cgroup v2，经过多个版本的过渡，v1.35正式移除cgroup v1支持。
• 影响：
  • 若节点仍使用cgroup v1（如CentOS 7、Ubuntu 18.04），升级到v1.35后kubelet将无法启动；
  • 需将节点升级到支持cgroup v2的系统（如CentOS 8+、Ubuntu 20.04+），或修改kubelet配置（failCgroupV1: false，但不推荐）。

3.2 废弃kube-proxy IPVS模式：推荐使用nftables

• 背景：kube-proxy的IPVS模式虽能提供高性能负载均衡，但存在“与其他模式（如iptables）功能不对齐”“维护难度大”等问题。v1.35将IPVS模式标记为“废弃”（Deprecated），推荐使用nftables模式（更高效、更易维护）。
• 影响：
  • 现有IPVS模式的集群仍可运行，但会在日志中打印警告；
  • 需逐步迁移到nftables模式（修改kube-proxy的ConfigMap，将mode: ipvs改为mode: nftables）。

3.3 停止支持containerd v1.x：强制升级到v2.0+

• 背景：containerd v1.x已进入生命周期末期（EOL），而containerd v2.0+提供了更强大的功能（如OCI artifact支持、更高效的镜像管理）。v1.35是最后一个支持containerd v1.x的Kubernetes版本。
• 影响：
  • 升级到v1.36及以上版本前，必须将containerd升级到2.0+；
  • 可通过kubelet_cri_losing_support指标监控集群中是否存在使用containerd v1.x的节点。

4. 生态与社区：强化协作，连接云原生生态

v1.35的生态与社区变化，主要体现在多集群管理、边缘计算支持、社区参与等方面，推动Kubernetes与云原生生态的深度融合。

4.1 多集群管理：MultiKueue与Job API的managed-by机制

• MultiKueue：跨集群Job分发（KEP #4368）：
  v1.35将“Job API的managed-by机制”升级为稳定特性，支持通过MultiKueue（多集群调度系统）将Job从管理集群镜像到工作集群执行，状态更新自动同步回管理集群。适用于跨地域、跨云的批量任务处理（如AI训练、数据备份）。
• 价值：简化多集群管理，提升资源利用率。

4.2 边缘计算：本地节点优先路由与轻量级运行时

• 本地节点优先路由（PreferSameNode）：如前所述，适用于边缘计算场景，将流量路由到边缘节点的端点，降低延迟。
• 轻量级运行时支持：v1.35优化了kubelet与轻量级运行时（如containerd lite）的集成，支持更小的节点资源占用（如内存≤512MB），适合边缘设备。

4.3 社区参与：全球协作与Special Interest Groups（SIGs）

• 贡献者规模：v1.35共有85家公司、419名个人贡献者参与，涵盖代码提交、评审、文档编写等环节；
• 社区活动：鼓励用户加入SIGs（如SIG Node、SIG Network），参与功能设计与讨论；
• 生态系统：整合了MultiKueue、Gateway API、SPIFFE/SPIRE等项目，推动云原生生态的协同发展。

5. 总结：v1.35的核心价值

Kubernetes v1.35作为2025年的收官版本，其核心价值在于“稳定现有功能”与“探索未来需求”的平衡：

• 稳定功能：通过Pod资源原地更新、节点声明式特性等，解决用户长期以来的痛点，提升生产环境的稳定性；
• 新特性：通过Pod证书、用户命名空间、Gateway API等，拓展集群的能力边界，适应未来的云原生场景（如AI/ML、边缘计算）；
• 生态协同：通过MultiKueue、containerd v2.0+等，强化与云原生生态的融合，推动Kubernetes成为连接不同场景的“世界树”。

对于用户而言，v1.35是一次“必须升级”的版本，尤其是其稳定特性（如Pod资源原地更新）能直接提升生产效率；同时，需关注弃用与移除的影响（如cgroup v1、containerd v1.x），提前规划升级路径，避免集群中断。