2. Cilium架构总览
Cilium 的控制面由多个独立部署但紧密协作的组件构成。理解每个组件的职责及其通信方式是进行故障排查的基础。本章将逐一解析 Cilium Agent、Cilium Operator、CNI 插件、Hubble 组件以及 KVStore (etcd) 的角色与交互流程。
2.1 核心组件角色一览
下表总结了各组件在 Cilium 控制面中的核心定位与关键职责：
| 组件 | 部署形态 | 核心职责 | 故障排查关注点 |
|---|---|---|---|
| Cilium Agent | DaemonSet (每节点一个) | 管理 eBPF 程序、同步网络策略、维护端点状态 | 与 API Server 通信、eBPF map 状态、本地策略一致性 |
| Cilium Operator | Deployment (通常 1-2 副本) | 集群级协调：IPAM、身份管理、故障恢复 | Leader 选举状态、IP 池耗尽、身份泄漏 |
| CNI 插件 | 二进制文件 (由 kubelet 调用) | Pod 网络接入：分配 IP、配置接口、调用 Agent | 二进制版本、Agent 响应超时、接口配置失败 |
| Hubble 组件 | DaemonSet + Deployment | 可观测性：流量抓取、服务依赖图、事件导出 | gRPC 连接、流丢失、Hubble Relay 缓存 |
| KVStore (etcd) | 外部集群 / 内置 | 分布式状态存储：身份、IP 分配、集群配置 | 读写延迟、watch 事件丢失、租约过期 |
2.2 组件交互流程与架构图
下图展示了 Cilium 控制面各组件之间的主要数据流与控制流。箭头方向表示通信发起方或数据流向。
2.3 关键组件深度解析
2.3.1 Cilium Agent — 数据面执行者
Agent 是 Cilium 中最核心的组件，以 DaemonSet 方式运行在每个 Kubernetes 节点上。它的主要工作包括：
- eBPF 程序管理：编译、加载并附着 eBPF 程序到网络接口（如 veth、cilium_host）。
- 网络策略同步：从 API Server 监听 NetworkPolicy 和 CiliumNetworkPolicy 资源，转换为 eBPF map 中的规则。
- 端点状态维护：跟踪本地所有 Pod 的标识、IP、安全身份（Security Identity）。
- KVStore 交互：将本地端点身份发布到 KVStore，并订阅全局身份变化。
故障排查提示： 当 Pod 网络不通时，首先检查
cilium agent status 输出中的 K8s 和 KVStore 状态。若显示 Failure，说明 Agent 与 API Server 或 etcd 的连接中断。
2.3.2 Cilium Operator — 集群级协调者
Operator 负责全局性的控制面任务，不直接参与数据面转发。其关键职责包括：
- IP 地址管理 (IPAM)：从 CIDR 池中分配 Pod IP，回收已删除 Pod 的 IP。
- 身份管理：为每个安全标签组合分配全局唯一的 Security Identity。
- 故障恢复：监控 Agent 健康状态，清理残留的端点或身份。
- Leader 选举：多副本部署时，仅 Leader 执行 IPAM 和身份分配操作。
| Operator 功能 | 依赖组件 | 故障影响 |
|---|---|---|
| IPAM | KVStore, API Server | 新 Pod 无法获取 IP，Pending 状态 |
| 身份分配 | KVStore | 网络策略无法生效，流量被默认拒绝 |
| Leader 选举 | API Server (Lease 对象) | 多 Operator 冲突，IPAM 混乱 |
2.3.3 CNI 插件 — Pod 网络接入点
CNI 插件是 kubelet 在创建 Pod 时调用的二进制文件。它不常驻运行，而是通过以下流程完成网络接入：
- kubelet 调用
cilium-cni二进制，传入 Pod 的 namespace/name 和网络配置。 - CNI 插件通过 gRPC 请求本地 Cilium Agent 分配 IP 并配置接口。
- Agent 创建 veth pair，将一端放入 Pod 网络命名空间，另一端挂载到 cilium_host 或 lxc 接口。
- Agent 加载针对该 Pod 的 eBPF 程序，设置网络策略和转发规则。
常见问题： CNI 插件版本与 Agent 版本不匹配会导致 gRPC 协议不兼容。排查时检查
/var/log/cilium-cni.log 中的 rpc error: code = Unimplemented 错误。
2.3.4 Hubble 组件 — 可观测性层
Hubble 提供基于 eBPF 的流量可观测性，由两个子组件构成：
- Hubble Agent：运行在每个节点上，从 Cilium Agent 的 eBPF map 中读取流量事件，通过 gRPC 流实时上报。
- Hubble Relay：集群级聚合器，连接所有 Hubble Agent，提供统一的查询接口（
hubble observe命令的后端）。
Hubble 不参与数据面转发，但它的数据流对排查网络策略问题至关重要：
- 通过
hubble observe --verdict DROPPED快速定位被策略拒绝的流量。 - 通过
hubble observe --identity验证源/目的安全身份是否正确。
2.3.5 KVStore (etcd) — 分布式状态中枢
KVStore 存储 Cilium 的全局状态，是控制面一致性的基石。存储的关键数据包括：
- Security Identity：标签到身份 ID 的映射。
- IP 分配记录：已分配的 Pod IP 及其所属节点。
- 节点状态：各节点的 Agent 心跳和健康信息。
- 集群配置：Cilium 全局配置（如隧道模式、原生路由）。
Agent 和 Operator 通过 watch 机制 监听 KVStore 中的变化。当 etcd 出现高延迟或 leader 切换时，可能导致：
- 身份分配延迟，新 Pod 长时间处于
Init状态。 - 网络策略更新滞后，旧策略残留导致流量异常。
- Agent 误判自身状态，触发不必要的重新加载。
2.4 组件交互时序总结
以下时序图展示了 Pod 创建过程中各组件的典型交互顺序：
2.5 故障排查关键路径
基于上述架构，当控制面出现故障时，建议按以下路径排查：
- 检查 Agent 状态：
cilium status确认与 API Server、KVStore 的连接。 - 检查 Operator 日志：
kubectl logs -n kube-system -l io.cilium/app=operator查找 IPAM 或身份分配错误。 - 检查 KVStore 健康：
cilium kvstore health查看延迟和 watch 事件数量。 - 检查 Hubble 流：
hubble observe --since 5m --verdict DROPPED确认策略是否按预期执行。 - 检查 CNI 日志：查看
/var/log/cilium-cni.log中是否有 gRPC 调用失败记录。
最佳实践： 在生产环境中，建议为 KVStore 配置独立的 etcd 集群，并启用
etcd-operator 的自动备份。Cilium Agent 的 --debug 模式仅在排查问题时临时开启，避免日志爆炸。