Cilium 替换 Calico 方案与风险（深度模式）
目标机：192.168.60.128（master，单节点，Ubuntu 26.04，k8s v1.35.4，docker 29.7.2 + cri-dockerd） 环境：192.168.60.128（master，单节点，Ubuntu 26.04，k8s v1.35.4，docker 29.7.2 + cri-dockerd） 日期：2026-10-09
0. 结论：有必要吗？
以「学习 + 验证」为目的：值得做。理由：
- 成本低：单节点测试机，镜像通道已实测可用，回滚只需恢复基础快照。
- 能明显看到的东西（功能/可观测层面）真实存在，见下方优点清单。
- 但要摆正性能预期：单节点上"性能提升"有限。因为所有 Pod 都在同一台机、不经封装，Calico 的 IPIP 开销根本用不上。 真正的性能收益出现在「多节点 + 大量 Service/NodePort」场景（kube-proxy 退化为纯 eBPF，绕开 iptables 逐包遍历）。 所以这次在你这台机上，收益主要是"能力/可观测/架构现代化"，吞吐提升只会有几个百分点量级。
换完之后你能拿到的优点（按"能不能在这台机上看到"标注）：
- 彻底移除 kube-proxy：Service/ClusterIP/NodePort 全部由 eBPF 处理（本机可见 ✔）
- iptables 规则数大幅下降（本机可见 ✔，我们会做前后对比）
- Hubble 全链路可观测：hubble observe 能看到每一次 L3/L4（甚至 L7）请求（本机可见 ✔）
- L7 网络策略：可按 HTTP 方法/路径做策略（Calico 需要额外组件）（本机可验证 ✔）
- 原生 NetworkPolicy + CiliumNetworkPolicy + Clusterwide 策略（本机可见 ✔）
- 更干净的 NodePort / LB / 大流量转发路径（本机可见 ✔）
- 内核 eBPF 数据面，无需 IPIP 隧道（本机可见：tunl0 消失 ✔）
- 后续可平滑用上：带宽管理、BGP、Gateway API、服务网格（ambient）（扩展方向）
1. 技术选型（已按你这台机实测校准）
| 项 | 取值 | 依据 |
|---|---|---|
| Cilium 版本 | 1.20.2（最新稳定） | k8s 1.35 属其 e2e 保证范围（1.20 支持 1.33–1.36）；1.19.8 亦可 |
| 内核要求 | ≥5.10 | 本机 7.0.0-22 ✔ |
| 数据面 | kubeProxyReplacement=true | 深度模式目标 |
| 可观测 | Hubble + Relay + UI | 深度模式目标 |
| IPAM | cluster-pool，Pod CIDR 10.244.0.0/16 | 与 kube-controller-manager 现网参数对齐（修正现存不一致） |
| 路由 | tunnel(VXLAN)（默认） | 单节点最稳；后续可切 native |
| 设备 | devices=ens32 | 避免 Cilium 误接管 docker0/cali |
| API 直连 | k8sServiceHost=192.168.60.128 / k8sServicePort=6443 | 无 kube-proxy 后 Pod 访问 API 需要 |
| 安装方式 | cilium CLI（内置 helm，无需另装 helm） | 步骤最少 |
关键前置事实（实测）：
- 运行时 = docker 29.7.2 + cri-dockerd，CRI socket：unix:///var/run/cri-dockerd.sock
- CNI 现状：/etc/cni/net.d/10-calico.conflist + calico-kubeconfig；二进制 /opt/cni/bin/calico, calico-ipam
- Calico 以 DaemonSet(calico-node) + Deployment(calico-kube-controllers) 运行，宿主无清单文件
- kube-proxy 是 systemd 服务（/usr/local/bin/kube-proxy），不是 DaemonSet → 深度模式要 disable 它
- 服务网段 10.96.0.0/12，DNS 10.96.0.10，kubernetes svc 10.96.0.1
- 现 Pod 网段 172.16.0.0/16（Calico IPPool）；节点网卡 ens32=192.168.60.128，docker0=172.17.0.1/16
- 内核 eBPF 就绪：CONFIG_BPF / BPF_SYSCALL / BPF_JIT 均 =y，bpf fs 已挂载，cgroup2 已挂载
- 镜像与工具通道：quay.io 直连可达；github.com 直连可达；raw.githubusercontent.com 需走代理 192.168.60.1:12450
- 基线 iptables：filter 276 行 + nat 82 行
- 集群内无任何 NetworkPolicy（无需迁移策略）
2. 实施步骤（概览）
逐步命令与每条命令背后的原理，见 替换 Calico 全过程讲解。 这里只保留方案阶段独有的两项准备。
| 步骤 | 做什么 | 为什么 |
|---|---|---|
| Step 0 | 采集基线（只读） | 没有基线就无法证明改动效果，也无法出问题时对照 |
| Step 1 | 装 cilium CLI + 预拉镜像 | 缩短变更窗口，避免安装时卡在 ImagePull |
| Step 2 | 卸载 Calico | 清 K8s 对象 + 宿主 CNI 文件 + 内核残留（iptables/路由/隧道口） |
| Step 3 | 停用 kube-proxy | 必须与 Step 4 紧邻执行，否则 ClusterIP 会分钟级失效 |
| Step 4 | 安装 Cilium（深度模式） | 见选型表里的参数取值 |
| Step 5 | 重建工作负载 | 老 Pod 还带 Calico 时代的 172.16.x IP，Cilium 管不了 |
| Step 6 | 验证 | cilium status / connectivity test / netshoot 手测 |
| Step 7 | 前后对比 | iptables 行数、kube-proxy 状态、tunl0 是否消失 |
本次预拉的镜像
bash
docker pull quay.io/cilium/cilium:v1.20.2
docker pull quay.io/cilium/operator-generic:v1.20.2
docker pull quay.io/cilium/hubble-relay:v1.20.2
docker pull quay.io/cilium/hubble-ui:v0.13.2 || true
docker pull quay.io/cilium/hubble-ui-backend:v0.13.2 || true内网拉取用的代理变量
bash
export https_proxy=http://192.168.60.1:12450 http_proxy=http://192.168.60.1:12450
export no_proxy=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local3. 风险与取舍
| # | 风险 | 等级 | 处置 |
|---|---|---|---|
| 1 | cri-dockerd(docker) 运行时：Cilium 主测目标是 containerd/CRI-O | 中 | 最大不确定点。Step 6 的 cilium connectivity test 就是实测它；失败即回滚 |
| 2 | 切换期间集群内网络短暂中断（registry 短暂不可用） | 中 | Step 2–4 连续执行，缩短窗口；接受测试机中断 |
| 3 | 停 kube-proxy 后若 Cilium 起不来 → ClusterIP 全断 | 高 | 立即回滚基础快照 |
| 4 | Pod 网段 172.16→10.244，若有资产硬编码 172.16.x 需改 | 低 | 本机 /etc/hosts、CoreDNS 不受影响 |
| 5 | docker0(172.17/16) 干扰 Cilium 设备识别 | 低 | 已用 devices=ens32 规避 |
| 6 | cali-* iptables 残留影响计数/干净度 | 低 | 已提供清理脚本 |
| 7 | 单节点上性能提升不明显 | — | 预期管理：本次看能力，不看吞吐 |
取舍：牺牲「零中断」换取「干净的、无 kube-proxy 的 eBPF 数据面」。测试机可接受。
4. 回滚方案
- 首选：VMware 恢复基础快照（最快最干净）。
- 若不回滚：
cilium uninstall→ 用你的二进制安装器重装 Calico → 恢复 kube-proxy：bashsystemctl enable --now kube-proxy