3. Cilium基础架构：eBPF技术栈、Cilium Agent、Cilium Operator、Cilium CLI与Hubble
Cilium 的核心竞争力在于将 eBPF 技术与 Kubernetes 网络、安全、可观测性深度绑定。理解其基础架构，是进行日志关联与根因定位的前提。本章从 eBPF 技术栈出发，逐一拆解 Cilium Agent、Operator、CLI 及 Hubble 的职责与协作关系。
3.1 eBPF 技术栈：Cilium 的底层引擎
eBPF（extended Berkeley Packet Filter）允许用户在 Linux 内核中安全地运行沙箱化程序，而无需修改内核源码或加载内核模块。Cilium 利用 eBPF 实现网络数据平面、安全策略执行与可观测性数据采集。
| eBPF 组件 | Cilium 中的角色 | 关键能力 |
|---|---|---|
| BPF 程序类型 | XDP、TC、cgroup、socket filter | 在数据包最早入口（XDP）或内核协议栈（TC）执行转发、过滤、封装 |
| BPF Map | 端点映射、策略映射、NAT 表、路由表 | 用户态与内核态共享数据，支持高效查找与更新 |
| BPF Hook | 网络事件、系统调用、跟踪点 | 捕获 Pod 创建/删除、网络连接、DNS 请求等事件 |
| BPF CO-RE | BTF + 一次编译到处运行 | 解决不同内核版本兼容性，无需预编译内核模块 |
关键认知： eBPF 使 Cilium 无需 iptables 或 kube-proxy 即可实现 Service 负载均衡、网络策略与可观测性，大幅降低延迟与 CPU 开销。
3.2 Cilium Agent：节点级数据面核心
Cilium Agent 以 DaemonSet 形式运行在每个 Kubernetes 节点上，是数据面的执行者。它负责管理 eBPF 程序的加载、端点生命周期、网络策略下发以及指标暴露。
- 端点管理： 监听 Kubernetes Pod 事件，为每个 Pod 创建 CiliumEndpoint 对象，并生成对应的 BPF 程序与 Map。
- 策略执行： 将 CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy 翻译为 BPF Map 条目，实现 L3/L4/L7 过滤。
- Service 负载均衡： 通过 eBPF 实现 kube-proxy 替代，支持 Maglev 一致性哈希与 DSR（直接服务器返回）。
- 可观测性导出： 通过 Hubble 组件导出流日志与指标，支持 Prometheus 与 OpenTelemetry。
排障提示： 当 Pod 网络不通时，首先检查
cilium endpoint list 确认端点状态是否为 ready，以及 cilium bpf policy list 查看策略是否命中。
3.3 Cilium Operator：集群级控制面
Cilium Operator 是集群级别的控制器，通常以 Deployment 形式运行（高可用场景下为 2 副本）。它不参与数据面转发，而是负责全局协调。
| 职责 | 说明 | 异常影响 |
|---|---|---|
| IPAM（IP 地址管理） | 分配 PodCIDR 与 Pod IP，支持 CRD、Kuberenetes HostScope、AWS ENI、Azure 等模式 | Pod 无法获取 IP，Pending 状态 |
| 身份管理 | 为每个安全标签组合分配全局唯一 Security Identity | 网络策略失效，流量被误拦截 |
| 负载均衡器 IP 分配 | 管理 CiliumLoadBalancerIPPool 与 L2 通告 | Service 无法获取 LB IP |
| CNI 配置同步 | 确保每个节点的 CNI 配置与 Cilium 版本一致 | 新 Pod 无法接入网络 |
3.4 Cilium CLI：运维诊断工具
cilium 命令行工具是日常排障的瑞士军刀，直接与本地节点的 Cilium Agent 通信。常用命令分类如下：
- 状态检查：
cilium status、cilium health、cilium connectivity test - 端点与策略：
cilium endpoint list、cilium policy get、cilium bpf policy list - 网络调试：
cilium monitor（实时流日志）、cilium bpf nat list、cilium bpf lb list - eBPF 诊断：
cilium bpf metrics list、cilium debuginfo
# 查看节点 Cilium 整体状态
cilium status --verbose
# 实时监控节点上的网络流日志（类似 tcpdump 但更上层）
cilium monitor -v
# 查看当前节点所有端点的安全策略命中情况
cilium bpf policy list
# 执行集群级连通性测试
cilium connectivity test3.5 Hubble：可观测性与流日志平台
Hubble 是 Cilium 的可观测性层，基于 eBPF 采集网络流日志，并提供 Service Map、DNS 监控、HTTP/gRPC 协议解析等能力。它由以下组件构成：
| 组件 | 部署形态 | 功能 |
|---|---|---|
| Hubble Agent | 嵌入 Cilium Agent 进程 | 从 eBPF 获取流事件，生成 JSON 格式流日志 |
| Hubble Relay | Deployment | 聚合集群所有节点的流日志，提供统一查询 API |
| Hubble UI | Deployment | 可视化 Service Map 与流日志，支持过滤与搜索 |
| hubble CLI | 二进制工具 | 命令行查询流日志，支持 JSON 输出与过滤表达式 |
根因定位关键： 在 GitOps 发布异常场景中，Hubble 流日志是关联“发布变更”与“网络行为异常”的核心桥梁。通过
hubble observe --verdict DROPPED 可快速定位被策略拦截的流量。
3.6 组件协作关系总结
在 GitOps 发布场景中，各组件按以下链路协作：
- GitOps 工具（如 ArgoCD）将新版本的 Deployment/Service 应用到集群。
- Cilium Operator 监听到 Pod 创建事件，分配 IP 与 Security Identity。
- Cilium Agent 在节点上创建端点，加载对应的 eBPF 程序与策略。
- eBPF 程序 执行数据包转发、策略检查与流日志生成。
- Hubble Agent 将流日志发送给 Hubble Relay，供 Hubble UI / CLI 查询。
- 运维人员通过 cilium CLI 或 hubble CLI 定位异常流量，关联到 GitOps 发布的变更。
架构要点： Cilium Agent 是节点级数据面核心，Operator 是集群级控制面，Hubble 是可观测性桥梁，CLI 是排障入口。四者缺一不可，共同构成 GitOps 发布场景下的网络根因定位基础。