eBPF + 容器：Cilium 的数据面为什么不再需要 iptables
内容提要
Kubernetes 集群中，kube-proxy 使用 iptables 管理服务，导致性能瓶颈。Cilium 通过 eBPF 替代 iptables，实现 O(1) 哈希查找和原子更新，显著提升性能，并支持无 Sidecar 的服务网格，适合大规模集群。
关键要点
-
Kubernetes 集群中，kube-proxy 使用 iptables 管理服务，导致性能瓶颈。
-
Cilium 通过 eBPF 替代 iptables，实现 O(1) 哈希查找和原子更新，显著提升性能。
-
Cilium 支持无 Sidecar 的服务网格，减少内存和延迟开销。
-
Cilium 的 eBPF Map 替代 iptables 规则链，查找时间不随服务数量增加而变化。
-
Cilium 的连接跟踪使用 eBPF Map，避免了 nf_conntrack 的全局哈希表和自旋锁问题。
-
Cilium 在节点级别实现 mTLS，减少 TLS 握手的开销。
-
Cilium 的内核版本要求较高，调试难度上升，适合大规模集群使用。
延伸解读
Cilium 的性能优势
Cilium 通过 eBPF 实现 O(1) 哈希查找，显著提升了服务的查找效率。与传统的 iptables 规则链相比，Cilium 的查找时间不受服务数量增加的影响，这使得在大规模集群中，Cilium 能够保持低延迟和高吞吐量，适合需要高性能的应用场景。
内核版本要求与调试挑战
Cilium 对内核版本有较高的要求，最低需 4.19 版本，最佳性能需 6.1 以上。这可能限制了某些企业的使用。此外，Cilium 的调试难度较高，虽然提供了 Hubble 可视化工具，但相较于 iptables 的直观调试，Cilium 仍需团队具备一定的 eBPF 调试能力。
无 Sidecar 的服务网格
Cilium 支持无 Sidecar 的服务网格架构，减少了每个 Pod 的内存和延迟开销。传统的服务网格如 Istio 需要为每个 Pod 注入 Envoy 代理，而 Cilium 通过内核层的处理，显著降低了资源消耗和延迟，适合对性能要求高的微服务架构。
延伸问答
Cilium 如何解决 kube-proxy 的性能瓶颈问题？
Cilium 通过使用 eBPF 替代 iptables，实现 O(1) 哈希查找和原子更新，显著提升性能，避免了 iptables 的 O(n) 线性匹配问题。
Cilium 的 eBPF Map 有什么优势？
Cilium 的 eBPF Map 替代了 iptables 规则链，查找时间不随服务数量增加而变化，且支持原子更新，避免了全量刷新带来的延迟。
Cilium 如何支持无 Sidecar 的服务网格？
Cilium 通过在内核层实现 L7 代理，使用 socket-level redirect，避免了传统 Sidecar 模型的内存和延迟开销。
Cilium 对内核版本有什么要求？
Cilium 对内核版本有较高要求，建议使用 5.10 及以上版本以获得全功能支持，低于 4.19 的版本不支持。
Cilium 的连接跟踪是如何实现的？
Cilium 使用自己的 eBPF conntrack Map，避免了传统 nf_conntrack 的全局哈希表和自旋锁问题，提供更高效的连接跟踪。
使用 Cilium 的主要限制是什么？
Cilium 的主要限制包括较高的内核版本要求、调试难度上升以及对已有 NetworkPolicy 的兼容性问题。
