eBPF + 容器：Cilium 的数据面为什么不再需要 iptables
内容提要
Kubernetes 集群中，kube-proxy 使用 iptables 管理服务，导致性能瓶颈。Cilium 通过 eBPF 替代 iptables，实现 O(1) 哈希查找和原子更新，显著提升性能，并支持无 Sidecar 的服务网格，适合大规模集群。
延伸解读
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 通过内核层的处理，显著降低了资源消耗和延迟，适合对性能要求高的微服务架构。
Q&A
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 的兼容性问题。
