Cilium
在测试集群上把 CNI 从 Calico v3.25.0 就地换成 Cilium v1.20.2（深度模式）， 数据面由 eBPF 接管，并停用传统上负责 Service 转发的 kube-proxy。
环境：192.168.60.128（单节点 master，Ubuntu 26.04，k8s v1.35.4，docker 29.7.2 + cri-dockerd） 日期：2026-10-09。本文结论来自该机器上的实测输出。
四篇笔记
- 概念、组件与 Calico 对比 — 三条要点、组件与分层、Pod 配网流程、与 Calico 的逐流程对比、优缺点与选型
- 全过程讲解 — 三个必须先有的心智模型、为什么 eBPF 优于 iptables、逐步复盘、两个真实的坑、日常命令手册
- 方案与风险 — 值不值得做、技术选型表、前置事实、风险清单与回滚
- 执行结果 — 前后对比、实测证据、已知问题与 Hubble UI 用法
架构图
数据面：一切都在内核里
- Pod 发出的包一到 veth 就被 eBPF 钩子接管
- Service 的 DNAT 查 BPF service map，O(1)
- 不再有 kube-proxy，不再有上千条 iptables 链
- 实测 iptables 行数 406 → 101
L7 代理：谁能用、边界在哪
- 七层策略（按 HTTP 方法 / 路径）现在就能用
- 南北向入口（替代 nginx-ingress）需要开 ingressController
- 不是完整网关：限流、JWT、复杂 rewrite 弱于 nginx、APISIX、Kong
- 引擎是 cilium-envoy，这个集群已经在跑
可观测：Hubble
- eBPF 顺手把 flow 上报，不是抓包
- UI：
http://192.168.60.128:31000（NodePort，已实测 HTTP 200） - 空闲集群看不到数据 —— 默认会过滤基础设施噪声
- 有业务流量才出服务依赖图
关键结论（前后对比）
| 指标 | 之前（Calico） | 之后（Cilium） |
|---|---|---|
| CNI | Calico v3.25.0 | Cilium v1.20.2 |
| 数据面 | iptables + IPIP 隧道 | eBPF + VXLAN |
| Service 转发 | kube-proxy（iptables） | Cilium eBPF（kubeProxyReplacement=true） |
| kube-proxy | systemd 服务在跑 | 已 disable，规则已清 |
| Pod 网段 | 172.16.0.0/16 | 10.244.0.0/24 |
| iptables 总行数 | 406 | 101（-75%） |
| tunl0 隧道 | 有 | 已删 |
| 可观测 | 无 | Hubble + Hubble UI |
IPAM 用的是 cluster-pool：池是 10.244.0.0/16，本节点实际分配到的是 10.244.0.0/24，两者不矛盾。
版本组合：Cilium v1.20.2 · kubeProxyReplacement=true · routing: tunnel(vxlan) · IPAM: cluster-pool 10.244.0.0/16