📚 课程目录第2章 Cilium架构基础

Cilium 架构基础：核心组件、eBPF 数据路径与 kube-proxy 关系

Cilium 是一个基于 eBPF（extended Berkeley Packet Filter）的云原生网络、安全与可观测性项目。理解其架构是进行网络策略设计与资源画像优化的前提。本章将深入拆解 Cilium 的核心组件、数据路径以及它与传统 kube-proxy 的替代关系。

2.1 Cilium 核心组件详解

Cilium 采用 DaemonSet + Deployment 的部署模式，主要由 Cilium Agent、Cilium Operator 和 CNI 插件 三部分组成。它们各司其职，协同完成数据面与控制面的工作。

组件	部署类型	核心职责	关键说明
Cilium Agent	DaemonSet	管理 eBPF 程序、实现网络策略、服务负载均衡、监控与可观测性	每个节点运行一个实例，是数据面的核心执行者
Cilium Operator	Deployment	集群级协调、身份管理、端点清理、CRD 同步、故障恢复	通常只需 1-2 个副本，负责控制面逻辑
Cilium CNI	二进制插件	实现 CNI 标准接口，负责 Pod 网络接口的创建与配置	由 kubelet 调用，快速完成网络接入

2.1.1 Cilium Agent

Agent 是 Cilium 最关键的组件，运行在每个 Kubernetes 节点上。它通过 eBPF 程序 直接挂载到网络设备、系统调用等内核钩子点，实现高性能的数据包处理。

端点管理：维护本地节点上所有 Pod 的 Endpoint 信息，包括 IP、安全标签、策略映射。
策略执行：将用户定义的 CiliumNetworkPolicy 编译为 eBPF 映射（Map），在数据路径上实时生效。
服务负载均衡：通过 eBPF 实现 kube-proxy 的功能，支持 Maglev、随机等负载均衡算法。
可观测性：通过 Hubble 组件（通常与 Agent 同进程）采集网络流日志与指标。

资源画像关键点：Agent 的 CPU 和内存消耗与节点上的 Pod 数量、网络策略复杂度、并发连接数直接相关。在升级成本优化中，需要重点监控 Agent 的资源使用基线。

2.1.2 Cilium Operator

Operator 负责集群级别的控制面任务，不参与数据路径处理。它的主要工作包括：

身份管理：为每个安全标识（Security Identity）分配全局唯一的数字 ID，用于策略匹配。
端点清理：当节点故障或 Agent 异常退出时，Operator 负责清理残留的端点状态。
CRD 同步：监听 CiliumNetworkPolicy、CiliumClusterwideNetworkPolicy 等 CRD 的变化，并通知各节点 Agent 更新。
故障恢复：处理 IP 地址池（IPAM）的冲突与回收。

高可用注意：Operator 通常部署 2 个副本，避免单点故障。在集群升级期间，应确保 Operator 先于 Agent 完成更新，避免策略同步延迟。

2.1.3 Cilium CNI 插件

Cilium 实现了标准的 CNI 接口规范。当 kubelet 请求创建 Pod 网络时，CNI 插件执行以下步骤：

调用 Cilium Agent 的 API 获取 IP 地址与安全标签。
创建 veth 对，一端放入 Pod 网络命名空间，另一端接入主机。
在主机端 veth 上挂载 eBPF 程序，实现流量转发与策略执行。
返回 Pod 的网络接口信息给 kubelet。

# CNI 配置示例（通常位于 /etc/cni/net.d/05-cilium.conf）
{
  "cniVersion": "0.3.1",
  "name": "cilium",
  "type": "cilium-cni",
  "enable-debug": false
}

2.2 eBPF 数据路径

eBPF 是 Cilium 的技术基石。它允许用户在 Linux 内核中安全地运行沙箱化程序，而无需修改内核源码或加载内核模块。Cilium 利用 eBPF 实现了完整的数据路径。

上图展示了典型的南北向流量路径。关键钩子点包括：

XDP（eXpress Data Path）：在网络驱动层处理数据包，性能最高，适用于 DDoS 防护和转发。
TC（Traffic Control）：在协议栈入口/出口处理，Cilium 默认使用 TC ingress/egress 钩子。
Socket 层：通过 BPF 系统调用，在应用层实现策略与负载均衡，减少上下文切换。

2.3 Cilium 与 kube-proxy 的关系

在传统 Kubernetes 集群中，kube-proxy 负责实现 Service 的负载均衡。Cilium 可以完全替代 kube-proxy，提供更高效、更灵活的服务网络能力。

对比维度	kube-proxy (iptables/IPVS)	Cilium (eBPF)
数据路径	通过 iptables 规则链或 IPVS 表进行 DNAT	通过 eBPF Map 直接查找后端，绕过 iptables
性能	规则数量随 Service 增长而线性增加，延迟较高	O(1) 查找，延迟稳定，吞吐量高
可观测性	依赖 iptables 日志或 IPVS 统计，粒度粗	原生支持 L3/L4/L7 流日志，与 Hubble 集成
策略能力	仅支持 DNAT，无安全策略	支持网络策略、身份认证、API 级访问控制
部署模式	独立 DaemonSet，与 CNI 解耦	集成在 Cilium Agent 中，统一管理

升级成本优化启示：在集群升级时，如果从 kube-proxy 迁移到 Cilium 的 eBPF 服务实现，可以移除 kube-proxy 组件，减少一个 DaemonSet 的资源消耗。同时，eBPF 的高效转发能降低节点 CPU 开销，为升级期间的资源预留提供更多弹性。

2.3.1 如何禁用 kube-proxy

在 Cilium 中启用 kube-proxy 替代功能，需要在安装时设置以下 Helm 参数：

helm upgrade cilium cilium/cilium --version 1.15.0 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=6443

启用后，Cilium 会通过 eBPF 直接处理 ClusterIP、NodePort、LoadBalancer 和 ExternalIP 类型的 Service，不再依赖 kube-proxy 的 iptables 规则。

2.4 本章小结

Cilium 的架构设计围绕 eBPF 展开，通过 Agent、Operator 和 CNI 插件三个核心组件，实现了高性能的数据路径与灵活的控制面。理解这些组件的工作方式，特别是 eBPF 如何替代 iptables 和 kube-proxy，是后续进行网络策略优化和资源画像分析的基础。在集群升级场景中，Cilium 的架构优势可以转化为更低的资源开销和更稳定的网络性能。