kubernetes V1.35的重大变革：移除cgroupv1,弃用ipvs，contianerd v1.x|sean的农场

官方出处：

网络侧提案：《KEP-5495: Deprecate ipvs mode in kube-proxy》（https://github.com/kubernetes/enhancements/issues/5495 ）

运行时侧公告：《Kubernetes 1.35：containerd 1.x Support Ends, Migration to containerd 2.0 Required》（https://kubernetes.io/blog/2025/11/26/kubernetes-v1-35-sneak-peek/ ）

Kubernetes v1.35 版本迎来了两大里程碑式底层变更，旨在彻底清理社区长期积累的技术债务：

组件	旧方案（废弃	新方案（推荐/强制）	变更目的
网络代理	kube-proxy IPVS 模式	nftables 模式	移除高维护成本的“中间态” IPVS，实现 O(1) 性能与双栈原生支持。
容器运行时	containerd 1.x LTS 版本	containerd 2.0+	遵循上游支持周期，增强安全特性，提高运行时稳定性。

这两项变更标志着 K8s 底层依赖的 “去复杂、提效率” 升级进入收尾阶段，为后续网络功能迭代与运行时安全加固铺路。

时间线提醒：

v1.35：IPVS 模式被废弃；containerd 1.x 最后支持版本。
v1.36：kubelet 将拒绝连接 containerd 1.x；IPVS 模式进入正式移除流程。
v1.37：IPVS 模式代码计划彻底移除。

⚙️ 2. 前置认知：Linux 包处理框架的迭代逻辑

kube-proxy 模式切换的核心，是 Linux 内核包处理技术的代际更替：

2.1 iptables：传统包过滤的“遗产框架”

特点	描述	局限性
核心结构	基于“四表五链”，规则按顺序线性匹配。	O(N) 复杂度：万级 Service 规则量超 10 万条，匹配耗时达秒级。
规则更新	逐条操作。	存在“半生效”窗口，更新延迟高。
双栈支持	IPv4/IPv6 需分开维护两套规则（iptables / ip6tables）。	双栈场景运维成本高。

2.2 nftables：新一代可编程包处理引擎

NFTables 是 Linux 内核为替代 iptables 重构的框架，完美契合 Kubernetes 的代理需求：

核心优势	描述	内核要求
统一双栈	单 `inet` 表原生支持 IPv4/IPv6，无需分开配置。	推荐 Linux 5.10+ （RHEL 9, Ubuntu 22.04+ 已内置）。
高性能	基于 `set` / `map` 数据结构，规则匹配哈希查找 O(1) 。	万级 Service 规则量可降至 1k 内。
原子更新	规则变更以事务为单位，无“半生效”风险。	更新耗时缩至 50 毫秒内。

🔄 3. kube-proxy 的“三次进化”：从适配到原生

3.1 初代方案：userspace → iptables

kube-proxy 从低效的 userspace 模式切换至 iptables 模式，实现了转发逻辑的内核态迁移，但性能瓶颈依然存在。

3.2 过渡方案：IPVS 模式（v1.14 GA）

维度	逻辑与功能	致命缺陷（废弃原因）
原理逻辑	基于 Linux 内核 IPVS 模块，为每个 Service 创建虚拟服务。采用哈希表实现 O(1) 调度，支持 10 种算法。	定位错位：IPVS 是 L4 负载均衡器，而非通用代理。需要大量“胶水代码”适配 K8s 场景（如 Hairpin）。
核心价值	高并发场景 CPU 消耗比 iptables 低 80%+，支持会话保持。	维护地狱：保证与 iptables 模式功能一致性（Feature Parity）成本极高，阻碍新功能迭代。
运维注意	需提前加载 `ip_vs` 系列内核模块，否则可能退化。	依赖冗余：仍需依赖 iptables 完成辅助规则，链路长且复杂。

3.3 终局方案：v1.35 默认 nftables 模式（GA）

NFTables 模式完美解决了 IPVS 的痛点，成为官方最终推荐：

对比维度	IPVS 模式	nftables 模式
核心性能	O(1) 哈希调度	O(1) Set/Map 查找
规则规模	万级 Service 下 10 万+	万级 Service 下 <1k
更新耗时	1-3 秒	≤50 毫秒
双栈支持	配置复杂	原生单表支持
调度算法	支持 10 种+	目前支持 RR（轮询），后续将扩展

🛠️ 4. 运维实操指南：双变更同步迁移步骤

4.1 前置检查（必做，避免踩坑）

(1) nftables 支持检查

# 验证 nftables 工具与内核模块
nft list ruleset >/dev/null && echo "nftables支持正常" || echo "需升级内核或安装nftables"

# 检查内核版本（推荐≥5.10）
uname -r

# 加载 nf_tables 模块（若未加载）
modprobe nf_tables && echo "nf_tables模块加载成功"

(2) containerd 版本检查

# 检测是否存在 1.x 版本（需迁移）
ctr version | grep "Version: 1\." && echo "发现containerd 1.x，需升级至2.0+" || echo "containerd版本符合要求"

4.2 组件版本兼容矩阵

Kubernetes版本	支持的containerd版本	kube-proxy默认模式	IPVS模式支持状态	iptables模式支持状态
≤1.34	1.x/2.0+	iptables	可选启用	默认启用
1.35	1.7（最后支持）/2.0+	nftables	可选回退（1.37将移除）	可选启用（兜底）
≥1.36	2.0+	nftables	不支持	可选启用（兜底）

4.3 kube-proxy 模式切换（滚动更新，无中断）

编辑 kube-proxy ConfigMap：

kubectl -n kube-system edit cm kube-proxy

修改模式： 将 mode 字段改为 "nftables"。同时，移除原 IPVS 相关配置（如 ipvs.scheduler 等，已失效）。
```
mode: "nftables"
```

滚动重启：

kubectl -n kube-system rollout restart ds kube-proxy

验证性能： 观察规则更新耗时指标，应有显著下降。

kubectl get --raw /metrics | grep kubeproxy_sync_proxy_rules_duration_seconds_sum

4.4 containerd 升级（1.7 → 2.0，CentOS 示例）

(1) 预检查
确认集群 Seccomp 策略支持 containerd 2.0 的 enable_unprivileged_ports 与 enable_unprivileged_icmp 配置。

(2) 升级步骤（注意备份配置和数据）

# 停止 containerd 服务
systemctl stop containerd

# 卸载旧版本（保留数据目录，避免 Pod 数据丢失）
yum remove containerd.io -y

# 安装 containerd 2.0 版本（替换为最新稳定版）
yum install containerd.io-2.0.0-1.el9.x86_64 -y

# 启动服务并设置开机自启
systemctl start containerd && systemctl enable containerd

# 验证版本
ctr version | grep "Version: 2\." && echo "containerd升级成功"

# 验证集群状态
kubectl get pods --all-namespaces | grep -v Running && echo "存在异常Pod，需排查" || echo "集群状态正常"

4.5 调试工具替换指南

操作场景	旧工具（IPVS / containerd 1.x）	新工具（nftables / containerd 2.0）
查看负载均衡规则	`ipvsadm -Ln`	`nft list table ip kube-proxy`
查看连接状态	`ipvsadm -Lnc`	`nft list chain ip kube-proxy services`
查看运行时版本	`ctr version`	`ctr version` （命令兼容）
管理容器镜像	`ctr images ls`	`ctr images ls` （命令兼容）

4.6 监控与告警配置（关键指标）

(1) kube-proxy（nftables 模式）

kubeproxy_nftables_rules_total：规则总量，突增需排查兼容模式回退。
kubeproxy_sync_failures_total：nft 事务提交失败，需紧急处理。
kubeproxy_sync_proxy_rules_duration_seconds：规则更新耗时，异常升高需检查节点负载。

(2) containerd

containerd_runtime_version：监控节点是否仍存在 1.x 版本。

(3) 内核参数调优（针对巨型 Service 场景）
调大 nft_chain_blob_size 参数，以支持更大的原子事务：

# 临时调整（重启失效）
sysctl -w net.netfilter.nft_chain_blob_size=524288

# 永久生效（写入配置文件）
echo "net.netfilter.nft_chain_blob_size=524288" >> /etc/sysctl.d/k8s.conf
sysctl -p /etc/sysctl.d/k8s.conf

4.7 紧急回退方案（仅 v1.35 支持）

(1) kube-proxy 回退至 IPVS 模式

kubectl -n kube-system edit cm kube-proxy
# 修改 mode: "ipvs"  # 或 iptables
kubectl -n kube-system rollout restart ds kube-proxy

(2) containerd 回退（不推荐生产环境操作）

systemctl stop containerd
# 根据实际情况安装旧版本
yum install containerd.io-1.7.11-1.el9.x86_64 -y
systemctl start containerd

💡 5. 总结：双变更背后的技术趋势

Kubernetes v1.35 的双重底层变更，是项目朝着 “更简单、更高效、更现代” 架构演进的关键一步：

网络层：用 nftables 的原生可编程框架，彻底取代了 IPVS 这种高维护成本的“适配代理”方案，解决了长期困扰社区的性能与功能一致性问题。
运行时层：强制迁移至 containerd 2.0，不仅获得了更优的安全特性与性能，也同步跟进了上游技术支持周期。

这次切换虽然短期内增加了运维迁移成本，但长期将显著降低集群的维护复杂度与性能损耗。

运维核心行动建议：

优先：在测试集群完成 “内核升级 → nftables 验证 → containerd 升级” 全流程测试。
扫描：利用 kubelet_cri_losing_support 指标批量扫描，提前完成 containerd 1.x 节点迁移。
重构：重构基于 ipvsadm 的运维脚本，全面适配 nft 工具链。

转载链接：https://blog.csdn.net/weixin_66855479/article/details/155309538