3. Cilium核心架构：Cilium组件（Agent、Operator、CNI）、eBPF数据路径、与kube-proxy的关系
理解Cilium的核心架构是进行网络性能调优的前提。Cilium并非一个简单的CNI插件，而是一个由多个协同组件构成的、基于eBPF的完整网络、安全与可观测性平台。本章将深入剖析其三大核心组件（Agent、Operator、CNI）、eBPF数据路径的工作原理，以及它如何替代传统的kube-proxy，实现高性能的服务负载均衡。
3.1 Cilium核心组件架构
Cilium采用去中心化的控制平面与分布式数据平面相结合的设计。其核心组件包括运行在每个节点上的Cilium Agent、管理集群级任务的Cilium Operator，以及符合CNI规范的cilium-cni插件。
架构核心思想： Cilium Agent负责将用户意图（如网络策略、服务定义）通过eBPF程序直接注入Linux内核，实现高性能的数据包处理，无需对数据包进行昂贵的用户态-内核态切换。
3.1.1 组件功能对比
| 组件 | 部署模式 | 核心职责 | 关键交互对象 |
|---|---|---|---|
| Cilium Agent (cilium-agent) | DaemonSet，每个节点一个 | 管理eBPF程序、本地端点、网络策略、服务映射；与Kubernetes API Server通信 | Kubernetes API Server、本地节点内核、cilium-cni |
| Cilium Operator (cilium-operator) | Deployment，集群级 | 处理集群范围任务：IP地址管理（IPAM）、多集群网络、节点间身份同步 | Kubernetes API Server、Cilium Agent |
| cilium-cni 插件 | 二进制文件，由kubelet调用 | 实现CNI接口，将Pod网络命名空间接入Cilium管理的网络 | kubelet、Cilium Agent（通过Unix Socket） |
3.1.2 组件工作流程
- Pod创建触发： kubelet调用
cilium-cni插件。 - CNI插件转发：
cilium-cni将请求通过本地Unix Socket转发给本节点的Cilium Agent。 - Agent配置网络： Cilium Agent为Pod分配IP地址（从本地IP池或CRI-RM），创建网络接口（veth pair），并将接口一端放入Pod网络命名空间。
- eBPF程序挂载： Cilium Agent在宿主机侧的网络接口上挂载eBPF程序，用于处理该Pod的入站和出站流量。
- 策略与身份下发： Cilium Agent根据集群范围的网络策略和服务定义，更新本地eBPF Map，确保数据路径能够正确执行转发和策略决策。
3.2 eBPF数据路径
eBPF数据路径是Cilium性能优势的根本来源。与传统基于iptables或IPVS的转发路径不同，Cilium将eBPF程序直接附着在Linux内核的网络栈关键钩子点（如XDP、TC、cgroup），实现对数据包的极速处理。
3.2.1 关键钩子点与功能
| 钩子点 | 附着位置 | 在Cilium中的主要用途 | 性能优势 |
|---|---|---|---|
| XDP | 网卡驱动层（最早） | DDoS防御、早期包过滤、负载均衡（DSR模式） | 极低延迟，无需分配sk_buff |
| TC (ingress/egress) | 内核网络栈 | Pod间通信、网络策略执行、封装/解封装（VXLAN/Geneve） | 灵活，可访问完整网络栈上下文 |
| cgroup/cgroup2 | 控制组层级 | 套接字级策略（如禁止特定端口出站）、DNS策略 | 细粒度，与Pod生命周期强关联 |
3.2.2 数据包处理流程（以Pod间通信为例）
- 源Pod发包： 数据包从Pod的veth接口进入宿主机网络命名空间。
- TC ingress 处理： 宿主机侧veth接口上的TC ingress eBPF程序被触发。程序查询eBPF Map，确定目标Pod是否在同一节点。
- 策略检查： 根据源Pod的安全身份和目标Pod的标签，查询网络策略Map。如果策略不允许，数据包被直接丢弃（
TC_ACT_SHOT）。 - 转发决策：
- 同节点： 直接通过veth pair将数据包转发到目标Pod。
- 跨节点： 查询路由表或隧道Map，进行封装（如VXLAN）后，通过物理网卡发送。
- 目标Pod接收： 目标Pod侧veth接口上的TC egress程序（或对端ingress）接收数据包，完成最终交付。
性能关键点： 整个数据路径完全在内核态完成，没有上下文切换，没有用户态代理参与。eBPF Map作为高效的键值存储，用于查找端点、策略和服务信息，其查找速度远快于iptables规则遍历。
3.3 Cilium与kube-proxy的关系
在Kubernetes集群中，kube-proxy负责实现Service的负载均衡。Cilium可以完全替代kube-proxy，提供更高效、更灵活的服务转发能力。
3.3.1 替代模式：kube-proxy replacement
Cilium通过其kube-proxy replacement功能，在eBPF层面直接实现Service的ClusterIP、NodePort、LoadBalancer和ExternalIP的转发。当启用此模式时，集群中不应再运行kube-proxy。
3.3.2 性能对比：Cilium eBPF vs. kube-proxy (iptables/IPVS)
| 特性 | kube-proxy (iptables) | kube-proxy (IPVS) | Cilium eBPF (kube-proxy replacement) |
|---|---|---|---|
| 数据路径 | 内核Netfilter钩子，规则链遍历 | 内核IPVS哈希表 | eBPF Map + 内核钩子 |
| 扩展性（Service数） | 差（规则数随Pod数平方增长） | 好（哈希查找，O(1)） | 极好（eBPF Map，O(1)） |
| 延迟 | 高（规则遍历） | 中等 | 极低（直接内核态决策） |
| NodePort 性能 | 需要SNAT，回程路径长 | 需要SNAT | 支持DSR（直接服务器返回），回程不经过节点 |
| 外部流量策略 | 仅支持 local 或 cluster |
仅支持 local 或 cluster |
支持 local、cluster 及更精细的控制 |
| 可观测性 | 低（依赖conntrack） | 低 | 高（通过eBPF导出L3/L4/L7指标） |
3.3.3 启用kube-proxy replacement的配置
在Cilium的ConfigMap中，通过以下关键配置启用该功能：
# cilium-config ConfigMap 关键配置
kube-proxy-replacement: strict # 可选: "strict", "probe", "partial"
# 当设置为 "strict" 时，Cilium会完全接管所有Service功能，并检查集群中是否还有kube-proxy运行。
# 推荐生产环境使用 "strict" 模式，以获得最佳性能和一致性。
重要提示： 在启用
kube-proxy-replacement: strict 之前，必须确保集群中所有节点的kube-proxy已被移除或停止。否则，Cilium Agent会启动失败，并报告冲突。建议在部署Cilium时，通过Helm参数 --set kubeProxyReplacement=true 进行配置。
3.3.4 蓝绿发布场景下的优势
在蓝绿发布中，Service的流量切换是关键操作。Cilium的kube-proxy replacement提供了以下优势：
- 瞬时切换： 通过更新eBPF Map中的后端端点，实现毫秒级的流量切换，无需重建连接或重启服务。
- 精细化流量控制： 可以基于L7协议（如HTTP Header）或源IP进行流量分发，实现金丝雀发布与蓝绿发布的结合。
- 减少抖动： 由于eBPF程序直接在内核态更新，避免了kube-proxy更新iptables规则时可能引起的连接中断（conntrack问题）。