3. Cilium 基础架构：Cilium Agent、eBPF 数据路径、Hubble 可观测性组件、Cilium Operator

在深入排查网络策略故障之前，必须理解 Cilium 的四大核心组件及其协作方式。Cilium 并非传统意义上的 CNI 插件，而是一个基于 eBPF 的数据平面与控制平面系统。其架构可概括为：Agent 负责策略下发与状态管理，eBPF 负责内核态高速转发，Hubble 负责流量可视化，Operator 负责集群级协调。

3.1 组件总览与职责划分

下表列出了 Cilium 各组件的部署形态与核心职责，这是排障时定位问题组件的基础。

3.2 Cilium Agent：策略执行的核心

Cilium Agent 是运行在每个 Kubernetes 节点上的守护进程。它通过监听 Kubernetes API Server 中的 Pod、Service、NetworkPolicy、CiliumNetworkPolicy 等资源变化，动态生成 eBPF 程序并加载到内核。

Agent 的内部工作流程如下：

1. 监听事件：通过 Informer 机制监听 Pod/Service/Policy 变化。
2. 端点管理：维护本地节点上所有 Pod 的 端点（Endpoint） 对象，包含身份标识（Security Identity）、标签、IP 地址。
3. 策略计算：将 Kubernetes NetworkPolicy 和 CiliumNetworkPolicy 翻译为基于身份（Identity）的 eBPF map 条目。
4. eBPF 加载：通过 bpffs 挂载点将编译好的 eBPF 程序附加到网络设备（如 lxc、eth0）的 tc 或 XDP 钩子上。
5. 健康检查：定期上报节点状态，维护与 Operator 的心跳。

# 查看 Agent 状态
kubectl -n kube-system exec ds/cilium -- cilium status

# 列出本地所有端点及其安全身份
kubectl -n kube-system exec ds/cilium -- cilium endpoint list

# 查看特定端点的策略应用情况
kubectl -n kube-system exec ds/cilium -- cilium endpoint get <endpoint-id>

3.3 eBPF 数据路径：内核态高速转发

eBPF 数据路径是 Cilium 性能的核心。与传统 iptables 或 IPVS 不同，eBPF 程序直接运行在内核事件钩子中，无需上下文切换。Cilium 主要使用以下两种钩子：

• XDP（eXpress Data Path）：在网卡驱动层处理包，性能最高，适用于 DDoS 防护和入口策略。
• tc（Traffic Control）：在协议栈入口/出口处理包，功能更全面，支持 L3/L4/L7 策略。

数据路径的核心逻辑通过 eBPF Map 实现策略查找：

包到达节点
    │
    ▼
XDP/tc 钩子触发
    │
    ▼
查找 "Policy Map" (key: 源身份 + 目标身份 + 端口)
    │
    ├── ALLOW → 放行包，继续协议栈处理
    ├── DROP  → 丢弃包，记录丢弃原因到 "Drop Notification Map"
    └── 无匹配 → 根据默认行为（Deny/Allow）处理

下图展示了 eBPF 数据路径中策略查找的完整流程：

3.4 Hubble 可观测性组件

Hubble 是 Cilium 的可观测性层，它利用 eBPF 在内核中直接采集网络事件，无需修改应用代码或 sidecar 代理。Hubble 由三个子组件构成：

• Hubble Agent：运行在每个节点上，从 Cilium Agent 获取 eBPF 事件，聚合为流日志和指标。
• Hubble Relay：集群级聚合层，将所有节点的 Hubble Agent 数据合并，提供全局视图。
• Hubble UI：基于 Web 的可视化界面，展示服务依赖图、流量拓扑和策略审计结果。

在策略排障中，Hubble 最核心的能力是 策略审计（Policy Audit）。当策略被拒绝时，Hubble 会记录：

{
  "time": "2025-03-15T10:30:00Z",
  "verdict": "DROPPED",
  "source": {
    "pod": "frontend-7d8f9c5b6c-xk2l3",
    "identity": 12345,
    "labels": ["app=frontend"]
  },
  "destination": {
    "pod": "backend-6f9d4c7b8a-p9q2r",
    "identity": 67890,
    "labels": ["app=backend"]
  },
  "policy_match": "CiliumNetworkPolicy:deny-frontend-to-backend",
  "reason": "Policy violation"
}

# 实时查看 Hubble 流日志
hubble observe --from-pod frontend-7d8f9c5b6c-xk2l3 --to-pod backend-6f9d4c7b8a-p9q2r

# 查看策略拒绝事件
hubble observe --verdict DROPPED

# 通过 Hubble UI 查看服务依赖图（默认端口 12000）
kubectl port-forward -n kube-system svc/hubble-ui 12000:80

3.5 Cilium Operator：集群级协调者

Cilium Operator 是控制平面的关键组件，负责集群级别的状态管理，不直接参与数据路径转发。其主要职责包括：

下图展示了 Cilium 各组件的协作关系：

3.6 排障思维导图：组件故障定位

当网络策略出现异常时，可以按照以下组件维度进行快速定位：