【Kubernetes 网络深度系列】Cilium 深度拆解：eBPF 原生的云原生网络
内容提要
Cilium采用纯eBPF数据面，替代iptables和kube-proxy，通过Identity数字身份实现O(1)策略查找，支持Maglev负载均衡、DSR回包优化及无sidecar的Service Mesh。Hubble提供可观测性，ClusterMesh实现多集群连接。文章详解数据路径、安全模型、生产调参及与Calico的对比。
延伸解读
eBPF 数据面与 iptables 的取舍
Cilium 选择纯 eBPF 数据面，完全绕过 netfilter，用 O(1) 哈希查找替代 iptables 的 O(n) 线性匹配，并用原子 Map 更新替代全量刷新。这种设计在数千 Service、数万策略的大规模集群中优势明显，但需要内核 5.10+ 才能获得完整功能。对于内核版本较旧或对 BGP 有强依赖的环境，Calico 可能更合适。
Identity 模型：策略与 Pod 解耦
Cilium 用数字 Identity 替代 IP 作为策略匹配依据，标签相同的 Pod 共享同一 Identity，Pod 重启或扩缩容时策略无需更新。这避免了传统 IP 规则在大规模集群中的频繁重算，但需注意高基数标签（如 pod-template-hash）可能引发 Identity 爆炸，需合理配置安全相关标签。
kube-proxy 替代的实践要点
Cilium 内置 kube-proxy 替代，支持 Maglev 一致性哈希和 DSR 模式，提升负载均衡效率和回包路径。启用时需确保集群未安装 kube-proxy，并正确配置 API server 地址。DSR 模式要求底层网络允许源 IP 为 Service VIP 的包通过，部分云平台可能限制，需提前验证。
无 sidecar Service Mesh 的边界
Cilium 采用每节点一个 Envoy 实例，通过 BPF 重定向处理 L7 策略，相比 sidecar 模式显著降低资源开销。但该方案仅对 TCP 生效，且 L7 策略需重定向到 Envoy，纯 L3/L4 策略则直接在 BPF 层执行。跨节点、UDP 等场景仍走完整协议栈，与 sidecar 的全协议支持存在差异。
Q&A
Cilium 为什么选择 eBPF 作为唯一数据面，而不是使用 iptables？
Cilium 选择 eBPF 作为唯一数据面，是因为 iptables 存在 O(n) 规则匹配、全量刷新和全局锁、conntrack 锁竞争等性能瓶颈。eBPF 程序直接挂载在 TC、XDP、cgroup 等 hook 点，在包进入 netfilter 之前完成负载均衡、NAT、策略执行和连接追踪，实现 O(1) 哈希查找和原子 Map 更新，从而提升大规模集群下的性能。
Cilium 的 Identity 是什么？它如何解决 IP 变化导致的策略更新问题？
Identity 是 Cilium 中基于 Pod 安全相关标签的哈希值生成的数字编号。所有标签完全相同的 Pod 共享同一个 Identity。当 Pod 重启或 IP 变化时，只要标签不变，Identity 就不变，因此策略规则无需更新。这避免了传统 IP 匹配方式中每次 IP 变化都需要重新计算和更新 iptables 规则的问题。
Cilium 如何实现 kube-proxy 替代？它解决了 kube-proxy 的哪些问题？
Cilium 通过 eBPF 程序实现 kube-proxy 替代，使用 BPF Map 进行 O(1) 的 Service 查找，原子 Map 更新，以及 per-CPU 的 conntrack。这解决了 kube-proxy 的 iptables O(n) 匹配、iptables-restore 全量刷新和全局锁、conntrack 锁竞争等问题。启用方式为设置 kubeProxyReplacement=true。
Cilium 的 Service Mesh 与传统的 sidecar 模式（如 Istio）相比有什么优势？
Cilium 的 Service Mesh 采用 per-node Envoy 模型，每个节点运行一个 Envoy 实例，而不是每个 Pod 一个 sidecar。优势包括：Proxy 实例数从每 Pod 一个减少到每节点一个，内存开销大幅降低；纯 L3/L4 策略由 BPF 直接执行，不经过 Envoy；升级只需重启 DaemonSet，无需重启所有 Pod。
Hubble 在 Cilium 中扮演什么角色？它如何提供网络可观测性？
Hubble 是 Cilium 内置的可观测性组件，它消费 eBPF 程序在关键决策点写入的 BPF 事件，提供实时流量观测、集群级流量聚合和可视化界面。Hubble CLI 可以查看流量详情，包括源/目标 IP、Identity、端口、协议和策略判定结果；Hubble Metrics 可以将事件聚合为 Prometheus metrics，对接 Grafana。
ClusterMesh 如何实现多集群连接？它解决了什么问题？
ClusterMesh 通过 etcd 联邦实现多集群连接，每个集群的 Cilium Agent 额外连接到其他集群的 etcd 或 Kubernetes API，同步 IPCACHE、Service 和 Identity 信息。它支持跨集群 Pod-to-Pod 直连、全局 Service 负载均衡和跨集群 NetworkPolicy，解决了单一集群规模上限和跨区域容灾需求。
Cilium 的 DSR 模式是什么？它有什么优势和限制？
DSR（Direct Server Return）模式让 Service 的回包直接从后端 Pod 所在节点发回客户端，绕过入口节点，降低延迟和入口节点 CPU 开销，并让后端 Pod 看到客户端真实源 IP。限制是需要底层网络允许源 IP 为 Service VIP 的包通过，一些云平台的反欺骗规则会阻止。
Cilium 与 Calico 在数据面、安全模型和功能上有哪些主要区别？
Cilium 采用纯 eBPF 数据面，安全模型基于 Identity，内置 kube-proxy 替代、Service Mesh（per-node Envoy）和 Hubble 可观测性，多集群支持 ClusterMesh，但 BGP 支持有限。Calico 使用 iptables 或 eBPF 数据面，安全模型基于 IP，BGP 支持原生 BIRD，但不内置 Service Mesh 和高级可观测性。选型建议：需要 BGP 深度集成选 Calico，需要 Service Mesh 和高级可观测性选 Cilium。
