4、Cilium 网络策略模型：Endpoint、Identity、NetworkPolicy、CiliumNetworkPolicy
在 GitOps 声明式发布模型中，网络策略的声明与生效是保障微服务安全通信的核心环节。Cilium 基于 eBPF 实现的网络策略模型，相比传统 iptables 策略，提供了更细粒度的身份感知与 L7 协议控制能力。理解 Endpoint、Identity、NetworkPolicy 和 CiliumNetworkPolicy 四个核心概念，是进行日志关联与根因定位的基础。
4.1 核心概念定义
| 概念 | 缩写 | 定义与作用 | 在 GitOps 中的角色 |
|---|---|---|---|
| Endpoint | CEP | 代表一个 Pod 或一组容器的网络接入点，是策略执行的最小单元。 | GitOps 通过 Deployment/StatefulSet 声明 Pod，Cilium 自动创建对应的 Endpoint。 |
| Identity | CiliumIdentity | 基于标签（Label）为 Endpoint 分配的唯一安全标识，用于策略匹配。 | GitOps 中标签的变更会触发 Identity 的重新计算与策略重载。 |
| NetworkPolicy | K8s NP | Kubernetes 原生 L3/L4 网络策略，基于 IP 和端口进行访问控制。 | 适用于简单的命名空间隔离场景，声明在 YAML 中直接生效。 |
| CiliumNetworkPolicy | CNP | Cilium 扩展的 L3-L7 网络策略，支持 HTTP/gRPC/Kafka 协议过滤。 | GitOps 发布中用于声明微服务间的精细化 API 访问规则。 |
关键区别： K8s NetworkPolicy 只能基于 IP 和端口做 L3/L4 过滤，而 CiliumNetworkPolicy 可以基于 HTTP 方法、路径、Header 等 L7 字段做精细化控制。在 GitOps 异常样本分析中，CNP 的日志字段更丰富，便于根因定位。
4.2 策略模型架构图
下图展示了 Cilium 策略模型的核心组件及其交互关系：
4.3 策略匹配优先级与日志字段
当数据包到达 Cilium 管理的 Endpoint 时，策略匹配遵循以下优先级顺序：
- Endpoint 本地 Identity 查找：根据源/目的 IP 在 eBPF Map 中查找对应的 Identity。
- K8s NetworkPolicy 匹配：先匹配命名空间级别的 L3/L4 规则。
- CiliumNetworkPolicy 匹配：再匹配集群范围的 L3-L7 规则，支持协议感知。
- 默认拒绝：如果没有任何策略显式允许，则拒绝该数据包。
日志关联要点： 在 GitOps 异常样本中，如果发现流量被拒绝，应优先检查
cilium identity list 确认 Endpoint 的 Identity 是否正确，再通过 hubble observe 查看策略匹配详情。关键日志字段包括 identity、verdict、policy_name。
4.4 四种策略对象的对比
| 特性 | Endpoint | Identity | NetworkPolicy | CiliumNetworkPolicy |
|---|---|---|---|---|
| 作用范围 | 单个 Pod | 一组相同标签的 Pod | 命名空间 | 集群 / 命名空间 |
| 匹配依据 | IP + 容器 ID | K8s 标签 | PodSelector + IPBlock | EndpointSelector + 标签 |
| 协议支持 | L2-L4 | 无（仅身份标识） | L3/L4 (TCP/UDP/SCTP) | L3-L7 (HTTP/gRPC/Kafka/DNS) |
| 日志可见性 | 低（仅连接跟踪） | 中（Identity 变更事件） | 中（允许/拒绝事件） | 高（包含 HTTP 方法、路径、Header） |
| GitOps 声明方式 | 自动生成 | 自动生成 | YAML (apiVersion: networking.k8s.io/v1) | YAML (apiVersion: cilium.io/v2) |
4.5 异常样本中的典型问题模式
- Identity 漂移：GitOps 发布新版本时，Pod 标签变更导致 Identity 重新分配，旧策略未及时更新，造成流量中断。
- 策略顺序冲突：K8s NetworkPolicy 与 CiliumNetworkPolicy 同时存在，且规则相互覆盖，导致预期允许的流量被拒绝。
- L7 规则误配：CiliumNetworkPolicy 中 HTTP 路径或方法写错，导致 API 调用被拒绝，但 L3/L4 规则允许，日志中表现为
verdict=DROPPED且reason=Policy denied。 - Endpoint 未就绪：Pod 启动后 Cilium Endpoint 尚未完成 Identity 分配，此时流量被默认拒绝。
排查建议： 在 GitOps 发布流水线中，建议在策略变更后增加
cilium connectivity test 步骤，并开启 Hubble 实时监控。对于 L7 策略，务必在 CiliumNetworkPolicy 中显式声明 toFQDNs 或 toEndpoints，避免依赖默认行为。
4.6 策略生效的声明式流程
在 GitOps 模型中，网络策略的声明式生效遵循以下步骤：
- 提交：开发者将 NetworkPolicy 或 CiliumNetworkPolicy YAML 提交到 Git 仓库。
- 同步：GitOps 工具（如 ArgoCD）将 YAML 同步到目标集群。
- 解析：Kubernetes API Server 存储策略对象，Cilium Operator 监听策略变更。
- 下发：Cilium Agent 将策略规则编译为 eBPF 程序，并加载到内核。
- 执行：后续数据包经过 eBPF 程序，匹配 Identity 与策略规则，执行允许或拒绝。
- 观测：Hubble 采集策略决策事件，输出到监控系统或日志平台。