3. Cilium 架构：核心组件、eBPF 数据路径与 kube-proxy 关系
Cilium 是一个基于 eBPF 的云原生网络、安全和可观测性项目。其架构设计围绕 eBPF 的高效性与 Kubernetes 的声明式管理展开。本章深入剖析 Cilium 的三大核心组件（Agent、Operator、CNI）、eBPF 数据路径的转发原理，以及它如何替代传统的 kube-proxy 组件。
3.1 Cilium 核心组件
Cilium 采用无中心化的数据平面与轻量级控制平面相结合的设计。其核心组件包括运行在每个节点上的 Cilium Agent、管理集群级资源的 Cilium Operator，以及实现 Pod 网络接入的 CNI 插件。
| 组件 | 部署模式 | 核心职责 | 关键技术 |
|---|---|---|---|
| Cilium Agent (DaemonSet) | 每个节点一个 | 管理 eBPF 程序、实现网络策略、服务负载均衡、可观测性数据采集 | eBPF、Go、gRPC、Kubernetes API Watch |
| Cilium Operator (Deployment) | 集群级（通常 1-2 副本） | 处理集群级任务：IPAM（IP 地址管理）、CiliumNetworkPolicy 状态校验、节点间隧道/路由配置 | Kubernetes Controller、Leader Election |
| Cilium-CNI (二进制插件) | 每个节点（由 kubelet 调用） | 将 Pod 接入 Cilium 网络，配置网络接口和路由 | CNI Spec、Netlink、eBPF |
3.1.1 Cilium Agent
Cilium Agent 是数据平面的核心。它通过监听 Kubernetes API Server 获取 Pod、Service、Endpoint、NetworkPolicy 等资源的变化，并将这些事件转化为 eBPF 程序挂载到内核中。Agent 负责以下关键任务：
- eBPF 程序生命周期管理：编译、加载、挂载和卸载 eBPF 程序到网络接口、cgroup 或 XDP 挂载点。
- 网络策略执行：将 CiliumNetworkPolicy 翻译为 eBPF Map 中的规则，实现 L3/L4/L7 层访问控制。
- 服务负载均衡：通过 eBPF 实现 Maglev 或随机一致性哈希，替代 kube-proxy 的 iptables/IPVS 模式。
- 可观测性：通过 Hubble 组件采集 eBPF 事件，提供网络流日志、指标和分布式追踪能力。
3.1.2 Cilium Operator
Cilium Operator 负责处理集群范围的、非节点本地的逻辑。它不直接参与数据路径，而是作为控制平面的协调者：
- IPAM（IP 地址管理）：根据集群配置（如 CRD-backed、Kuberenetes HostScope、AWS ENI、GCP IP 等）为节点分配 PodCIDR 或单个 IP。
- Endpoint 同步：确保 CiliumEndpoint 资源与集群中的 Pod 状态一致。
- 策略校验：对 CiliumNetworkPolicy 和 CiliumClusterwideNetworkPolicy 进行准入校验。
- 故障恢复：在节点故障时，清理残留的 eBPF 状态或重新分配 IP。
3.1.3 Cilium-CNI 插件
当 kubelet 需要创建 Pod 网络时，会调用 Cilium-CNI 二进制插件。该插件执行以下步骤：
- ADD 操作：创建 veth pair，一端放入 Pod 网络命名空间，另一端接入主机网络。
- IP 分配：从 Cilium Agent 的本地 IPAM 池中获取 IP 地址。
- 路由配置：在主机侧和 Pod 侧配置路由，确保流量通过 eBPF 程序处理。
- eBPF 关联：通知 Cilium Agent 新 Pod 的元数据，Agent 随即加载对应的 eBPF 程序。
cilium-agent Pod 日志中的 CNI 调用记录。使用 cilium endpoint list 命令可以查看当前节点上所有 Pod 的 eBPF 状态。
3.2 eBPF 数据路径
Cilium 的数据路径完全基于 eBPF，绕过了传统的 iptables 和 netfilter 框架。eBPF 程序被挂载到内核网络栈的不同钩子点，实现高效的数据包处理。
上图展示了 Cilium 在主机网络栈中挂载的 eBPF 钩子点。Pod 出站流量通过 veth 到达主机侧，首先经过 TC Ingress 钩子（入站方向），在这里执行网络策略检查和 Service 负载均衡。随后流量经过 TC Egress 钩子（出站方向），进行封装（如 VXLAN/Geneve）或直接路由。XDP 钩子作为更早期的处理点，可用于高性能 DDoS 防护或节点外流量的快速转发。
3.3 与 kube-proxy 的关系
Cilium 可以完全替代 kube-proxy，提供更高效、更灵活的服务负载均衡。在 Cilium 部署中，通常建议禁用 kube-proxy，以避免两者冲突或重复处理。
| 特性 | kube-proxy (iptables/IPVS) | Cilium (eBPF) |
|---|---|---|
| 数据平面 | 用户态 iptables/IPVS 规则 | 内核态 eBPF 程序 |
| 性能 | 规则链线性遍历，大规模 Service 下性能下降 | 哈希查找，O(1) 复杂度，性能稳定 |
| 负载均衡算法 | 随机、轮询 (IPVS) | Maglev 一致性哈希、随机、轮询 |
| 外部流量策略 | 需额外配置 externalTrafficPolicy | 原生支持 Local/Cluster 模式，eBPF 直接处理 |
| 可观测性 | 需额外工具 (如 conntrack) | 内置 Hubble，提供流日志、指标、分布式追踪 |
| IPv6/IPsec | 支持有限，配置复杂 | 原生支持，eBPF 直接处理加密 |
3.3.1 替代机制
当 Cilium 启用 kubeProxyReplacement=true 时，它会接管以下原本由 kube-proxy 处理的功能：
- ClusterIP 服务：通过 eBPF 在 TC Ingress 钩子中实现 DNAT，将请求转发到后端 Pod。
- NodePort 服务：在主机网络接口的 TC Ingress 钩子中处理 NodePort 流量，支持 DSR（Direct Server Return）模式。
- LoadBalancer 服务：与云厂商集成，通过 eBPF 实现外部负载均衡器的流量分发。
- ExternalName 服务：通过 eBPF 实现 DNS 级别的重定向。
cilium status 命令验证 kubeProxyReplacement 状态。
3.3.2 配置示例
以下是在 Helm 部署中启用 kube-proxy 替代的典型配置：
# values.yaml
kubeProxyReplacement: true
# 可选：启用 NodePort DSR 模式
nodePort:
mode: dsr
# 可选：启用 Maglev 负载均衡
loadBalancer:
algorithm: maglev部署后，可以通过以下命令验证 kube-proxy 是否已被成功替代：
# 检查 Cilium 状态
kubectl exec -n kube-system ds/cilium -- cilium status | grep KubeProxyReplacement
# 预期输出
KubeProxyReplacement: Strict [eth0 10.0.0.0/8]当显示 Strict 模式时，表示 Cilium 已完全接管所有服务负载均衡功能，集群中不再需要 kube-proxy 组件。