3. Cilium架构解析

Cilium 的架构可以理解为“控制面 + 数据面 + 状态存储”三层协作：控制面负责把用户意图翻译成 eBPF 程序与映射表，数据面负责在 Linux 内核里以 eBPF 完成转发、策略与可观测，状态存储负责在集群范围内同步身份、端点与策略信息。理解这五类组件各自“管什么、不管什么”，是后续排障与调优的基础。

一、Agent：每个节点上的执行者

Cilium Agent 以 DaemonSet 形式运行在每个 Kubernetes 节点上，是节点级的“本地控制面”。它主要做四件事：

• 监听本节点 Pod 的创建/删除事件，为每个 Pod 分配安全身份（Identity），并把端点信息写入本地状态；
• 把 NetworkPolicy、CiliumNetworkPolicy 等策略对象编译为 eBPF 程序，加载到内核；
• 维护 eBPF map（如 endpoints、policy、ct、ipcache），供数据路径查询；
• 通过 KVStore 或 CRD 与集群其他节点同步身份与端点信息。

Agent 的配置入口是 ConfigMap cilium-config，常用参数包括 tunnel（vxlan/geneve/disabled）、ipam（cluster-pool/kubernetes）、kube-proxy-replacement、enable-ipv4 等。修改后需重启 Agent 生效。查看 Agent 状态可用：

kubectl -n kube-system exec ds/cilium -- cilium status --verbose
kubectl -n kube-system exec ds/cilium -- cilium endpoint list
kubectl -n kube-system exec ds/cilium -- cilium bpf ct list global

其中 cilium status 会显示 KubeProxyReplacement、隧道模式、IPAM 模式、Controller 健康状态；cilium endpoint list 显示每个 Pod 的 ID、Identity、策略状态（如 ready、policy）。

二、Operator：集群级的协调者

Operator 通常以单副本 Deployment 运行，负责“全局性、非节点本地”的工作：

• IPAM 分配：在 cluster-pool 模式下，为每个节点分配 PodCIDR 段；
• CRD 管理：创建并维护 CiliumIdentity、CiliumEndpoint、CiliumNetworkPolicy 等 CRD；
• 身份回收：当 Pod 删除后，回收不再使用的 Identity；
• 与 Kubernetes API 交互，处理需要跨节点一致性的任务。

Operator 与 Agent 的分工可以概括为：Operator 管“集群级分配与回收”，Agent 管“节点级加载与执行”。如果 Operator 异常，常见现象是新节点无法获得 PodCIDR、Identity 无法回收、CRD 同步延迟。

三、CNI 插件：Pod 网络的入口

Cilium 的 CNI 插件是一个二进制文件，安装在每个节点的 /opt/cni/bin/cilium-cni，由 kubelet 在创建 Pod 时调用。它的职责是：

• 读取 CNI 配置（/etc/cni/net.d/05-cilium.conflist）；
• 为 Pod 创建 veth pair，把一端放入 Pod netns，另一端挂到宿主机的 cilium_host；
• 向 Agent 注册端点，触发身份分配与 eBPF 程序加载；
• 返回 Pod IP、网关等信息给 kubelet。

CNI 插件本身不转发数据，它只负责“把 Pod 接入 Cilium 数据路径”。真正的转发、策略、NAT 都由 eBPF 完成。

四、eBPF 数据路径：内核里的转发引擎

这是 Cilium 与传统 CNI 最大的区别。数据包进入节点后，不再经过 iptables 链，而是由挂载在 tc/XDP 钩子上的 eBPF 程序处理。典型路径如下：

• Pod 发出报文 → veth → 宿主机 tc egress → 查 ipcache 决定目的节点；
• 若目的在本节点，直接查 endpoints map 转发到目标 veth；
• 若目的在远端，按 tunnel 模式封装（VXLAN/Geneve）或直接路由；
• 策略检查在转发前完成，基于 Identity 而非 IP，避免策略随 IP 变化而失效。

关键 eBPF map 包括：cilium_ipcache（IP→Identity/节点）、cilium_endpoints（端点信息）、cilium_policy（策略）、cilium_ct（连接跟踪）。可用以下命令观察：

kubectl -n kube-system exec ds/cilium -- cilium bpf ipcache list
kubectl -n kube-system exec ds/cilium -- cilium bpf policy get <endpoint-id>
kubectl -n kube-system exec ds/cilium -- cilium monitor --type drop

cilium monitor 是排障利器，能实时看到被策略丢弃的包及其原因（如 Policy denied、Invalid source identity）。

五、KVStore 与 CRD：状态同步的两种模式

Cilium 支持两种状态存储模式：

在 CRD 模式下，Cilium 会创建 CiliumIdentity、CiliumEndpoint、CiliumNetworkPolicy、CiliumNode 等 CRD。每个 Pod 对应一个 CiliumEndpoint，记录其 IP、Identity、策略状态；每个安全身份对应一个 CiliumIdentity。Agent 通过 watch 这些 CRD 来感知集群变化。

六、组件协作全景

下面这张图把五类组件放在同一张架构图中，重点表现“控制面如何驱动数据面、状态如何同步”。

从图中可以清晰看到：Operator 与 K8s API 属于集群级控制面，Agent 与 CNI 插件属于节点级控制面，eBPF 是真正的数据面执行者，KVStore 是可选的跨节点状态同步通道。排障时先定位问题属于哪一层：CNI 插件失败会导致 Pod 无法获得网络；Agent 异常会导致策略不生效或端点未注册；eBPF map 异常会导致转发中断；Operator 异常会导致 IPAM 或 CRD 同步问题。