Kubernetes 1.35 升级前要处理的四件事：cgroup v1 会让 kubelet 直接起不来

Kubernetes v1.35（Timbernetes，世界树）于 2025-12-17 发布，共 15 项增强进入 stable。功能之外，升级路径上有几个硬性阻塞项：cgroup v1 支持被移除、kube-proxy 的 ipvs 模式弃用、containerd v1.x 进入最后一个支持版本、Ingress NGINX 公布了退役时间表。下面按升级顺序过一遍。

v1.35 进入 stable 的增强

共 15 项，包括：

• 为 CPUManager 策略新增选项，把 reservedSystemCPUs 限制给系统守护进程与中断处理
• Pod Generation
• Invariant Testing
• In-Place Update of Pod Resources
• Fine-grained SupplementalGroups control
• 支持 kubelet 配置的 drop-in 目录
• 移除 Kubernetes API types 对 gogo protobuf 的依赖
• kubelet 按最大存活时间做镜像 GC（image GC after a maximum age）
• kubelet 并行镜像拉取上限（limit of Parallel Image Pulls）
• TopologyManager 策略新增选项 MaxAllowableNUMANodes
• 在 kubectl 的 HTTP 请求头里包含 kubectl 命令元数据
• PreferSameNode Traffic Distribution（原 PreferLocal traffic policy / Node-level topology）
• Job API 的 managed-by 机制
• 从 SPDY 过渡到 WebSockets

弃用与移除

1. cgroup v1 支持移除（KEP-5573）

Kubernetes 自 v1.25 起支持 cgroup v2。v1.35 正式退役 cgroup v1：节点如果仍运行在不支持 cgroup v2 的旧 Linux 发行版上，kubelet 会启动失败。这类节点必须先迁移到启用了 cgroup v2 的系统，再升级 kubelet。

KEP-5573: Remove cgroup v1 support。

2. kube-proxy 的 ipvs 模式弃用（KEP-5495）

当年引入 ipvs 是为了比 iptables 更快的负载均衡，但同步新网络需求的维护成本与复杂度太高。v1.35 里 ipvs 模式仍可用，但 kube-proxy 启动时会打警告。Linux 节点应开始转向 nftables，它现在是推荐替代方案。

KEP-5495: Deprecate ipvs mode in kube-proxy。

kube-proxy 配置中对应字段：

mode: "nftables"

3. containerd v1.x 的最后支持版本（KEP-4033）

v1.35 仍支持 containerd 1.7 等 LTS 版本，但这是最后一个支持 containerd v1.x 系列的 Kubernetes 版本。升级到下一个 Kubernetes 版本前，必须切到 containerd 2.0 或更新版本。

可以通过监控 kubelet_cri_losing_support 指标找出需要处理的节点。

CHANGELOG 还提到，containerd v1 相关的弃用移除时间线从 1.37 调整到 1.38；kubeadm 的 preflight check ContainerRuntimeVersion 会校验已安装的容器运行时版本，并对较老的 kubelet 使用 RuntimeConfig gRPC 方法。

KEP-4033: Discover cgroup driver from CRI。

4. Ingress NGINX 退役

Ingress NGINX controller 长期是社区入口方案的常见选择，但维护者严重不足、技术债累积，社区决定退役。这不严格属于 v1.35 的发布内容，但项目已宣布：Ingress NGINX 只提供尽力而为的维护到 2026 年 3 月，之后归档、不再更新。推荐迁移路径是 Gateway API。

版本与补丁节奏

来自 kubernetes.io/releases/1.35/：

• Release Status: Actively Supported
• 最新补丁：1.35.9（2026-09-15）
• Maintenance Mode 开始：2026-12-28
• EOL：2027-02-28
• 1.35.10 目标日期：2026-10-13
• 1.35.2（2026-02-26）是带外（out of band）补丁，只为一个新版 Go 修复若干 Go CVE，无其他改动

Feature gates 页面记录：

• GangScheduling：Alpha，1.35–1.36
• CSIMigrationPortworx：1.33–1.35
• HonorPVReclaimPolicy：1.33–1.35
• InTreePluginPortworxUnregister：1.23–1.35
• AllowServiceLBStatusOnNonLB：1.29–1.34，已弃用

已移除的 gate 不再被识别为合法 gate，即使写进配置也不会产生行为差异，这一点与 GA 或已弃用的 gate 不同。

升级前检查清单

按顺序执行，输出决定是否需要先改节点或改配置。

1. 确认节点 cgroup 版本

stat -fc %T /sys/fs/cgroup/

输出 cgroup2fs 表示 cgroup v2；tmpfs 表示仍在使用 cgroup v1。每台节点都要确认。

2. 确认 kube-proxy 代理模式

kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.mode}{"\n"}'
kubectl -n kube-system get daemonset kube-proxy -o yaml | grep -- --proxy-mode

输出为 ipvs 时，规划迁移到 nftables。

3. 确认容器运行时版本

kubectl get nodes -o wide
containerd --version

CONTAINER-RUNTIME 列会显示每个节点实际使用的运行时与版本。

4. 找出仍在使用 containerd v1 的节点

kubelet_cri_losing_support > 0

也可以直接抓取 kubelet 的 metrics 端点过滤该指标。结果非空的节点需要在升级到 1.35 之后、下一个 Kubernetes 版本之前完成 containerd 2.0+ 切换。

5. 检查 Ingress NGINX 使用情况

kubectl get ingressclass
kubectl get pods -A -l app.kubernetes.io/name=ingress-nginx

有输出就说明入口流量仍走 Ingress NGINX，需要在 2026 年 3 月前规划 Gateway API 迁移。

6. 跑 kubeadm 预检

kubeadm upgrade plan

升级执行时 preflight check ContainerRuntimeVersion 会校验已安装的运行时版本。

7. 确认目标补丁版本

kubectl version

1.35.2 是带外补丁，修的是 Go CVE；升级目标版本不应低于它。