3. Cilium 网络策略基础:L3/L4/L7 策略模型、Identity 概念、Endpoint 与 Identity 的映射关系

Cilium 的网络策略模型基于 Identity(身份) 而非传统的 IP 地址或 CIDR 范围。这一设计从根本上改变了策略的定义、分发与执行方式,也是控制面故障排查中需要重点理解的核心机制。本节将系统梳理 L3/L4/L7 策略模型、Identity 概念以及 Endpoint 与 Identity 的映射关系。

3.1 策略模型分层:L3 / L4 / L7

Cilium 策略按 OSI 模型分层设计,每一层关注不同粒度的流量控制。下表对比了三层策略的核心差异:

策略层级 匹配维度 典型字段 应用场景 性能开销
L3 网络层 源/目的 Identity、CIDR 跨集群、跨节点、外部网络访问控制 极低(eBPF 直接匹配)
L4 传输层 协议(TCP/UDP/SCTP)、端口 服务端口级访问控制、微服务隔离 低(eBPF 哈希查找)
L7 应用层 HTTP 方法、路径、Host;gRPC 服务名;Kafka Topic API 粒度鉴权、流量审计、七层协议过滤 中等(需代理或 eBPF 解析)
故障排查提示: 当策略未生效时,首先确认策略层级是否正确。L7 策略依赖 Envoy 代理 或 eBPF 七层解析,若代理未就绪,L7 策略会静默失效,而 L3/L4 策略仍正常工作。

3.2 Identity 概念:策略执行的核心单元

在 Cilium 中,Identity 是一个全局唯一的 64 位整数,用于标识一组具有相同安全标签的 Endpoint。Identity 的生成与分发完全由 Cilium Operator 和 KV-Store(etcd/Consul) 协作完成。

Identity 的关键特性:

  • 基于标签派生: 每个 Identity 由一组 Kubernetes 标签(如 app=frontend、version=v2)计算哈希生成。
  • 全局唯一: 同一集群内,相同标签组合的 Endpoint 共享同一个 Identity。
  • 动态分配: 当新 Pod 启动或标签变更时,Cilium Operator 通过 KV-Store 分配或回收 Identity。
  • 策略绑定: 网络策略中引用的 fromEndpoints / toEndpoints 最终被解析为 Identity 列表。
Identity 生命周期: 创建 → 分配(Operator 写入 KV-Store)→ 同步(Agent 监听并缓存)→ 使用(eBPF Map 中生效)→ 回收(Endpoint 删除后延迟释放)。

3.3 Endpoint 与 Identity 的映射关系

每个 Cilium Endpoint(通常对应一个 Pod)在 Agent 本地维护一张 Identity 映射表,记录该 Endpoint 当前绑定的 Identity 以及集群中所有已知的 Identity 列表。映射关系通过以下流程建立:

  1. Endpoint 创建: Cilium Agent 检测到新 Pod 启动,为其创建 Endpoint 对象。
  2. 标签收集: Agent 读取 Pod 的 Kubernetes 标签,计算标签哈希。
  3. Identity 请求: Agent 向本地 KV-Store 发起 Identity 分配请求(或从缓存中匹配)。
  4. 映射写入: 分配成功后,Agent 将 Identity 写入 eBPF Map(cilium_identity),同时更新本地缓存。
  5. 策略解析: 当网络策略引用该 Identity 时,Agent 将其转换为 eBPF 程序可识别的数值。
常见故障模式: 若 KV-Store 网络分区或 Operator 故障,Agent 无法分配新 Identity,导致新 Pod 处于 identity-unavailable 状态,所有流量被默认拒绝。排查时优先检查 cilium identity list 输出是否完整。

3.4 映射关系可视化:Endpoint ↔ Identity ↔ Policy

下图展示了 Endpoint、Identity 与网络策略之间的映射关系,以及数据包匹配策略的完整路径:

Endpoint ↔ Identity ↔ Policy 映射关系图 Endpoint ↔ Identity ↔ Policy 映射关系 Endpoint 组 Pod: frontend-v1 Pod: frontend-v2 Pod: frontend-v3 Identity 层 Identity: 16789 标签: app=frontend 版本: v1,v2,v3 Policy 层 fromEndpoints: Identity: 16789 toPorts: 80/TCP 标签匹配 策略引用 数据包匹配路径 入站包 → 提取源 Identity → 查询 eBPF Map → 匹配 Policy → 允许/拒绝 故障排查关键点 检查 cilium identity list 确认 Identity 分配 | 检查 cilium endpoint list 确认映射状态

3.5 映射关系在 eBPF 中的实现

Cilium Agent 将 Endpoint 与 Identity 的映射关系写入两个关键的 eBPF Map:

eBPF Map 名称 Key Value 作用
cilium_identity Identity (uint64) 标签列表、引用计数 全局 Identity 定义,用于策略解析
cilium_ipcache IP 地址 (uint32) Identity + 元数据 IP → Identity 反向查找,用于数据面快速匹配
cilium_endpoint Endpoint ID (uint16) Identity + 策略状态 本地 Endpoint 状态管理
排查命令速查:
cilium identity list — 查看所有 Identity 及其标签
cilium endpoint list — 查看 Endpoint 与 Identity 映射
cilium bpf ipcache list — 查看 IP → Identity 映射(数据面视角)
cilium bpf policy get <endpoint-id> — 查看某 Endpoint 的最终策略列表

3.6 映射关系异常场景

在控制面故障排查中,以下映射异常场景需要重点关注:

  • Identity 缺失: 新 Pod 启动后 cilium endpoint list 显示 identity=0,通常因 KV-Store 不可达或 Operator 未响应。
  • Identity 冲突: 不同标签组合计算出相同哈希(极低概率),导致策略意外放行或拒绝。
  • 映射过期: Pod 删除后 Identity 未及时回收,导致残留策略引用,影响新 Pod 的 Identity 分配。
  • 缓存不一致: Agent 本地缓存与 KV-Store 中 Identity 数据不一致,导致策略决策错误。
实战建议: 在变更标签或大规模滚动更新后,执行 cilium identity flush 强制刷新本地缓存,并观察 cilium monitor 输出中是否有 identity-not-found 告警。