3. Cilium 网络策略基础：NetworkPolicy 与 CiliumNetworkPolicy 的区别、策略层级与作用域
3.1 为什么需要理解两种策略模型？
在 Kubernetes 原生生态中，NetworkPolicy 是集群网络准入控制的基石，但它仅支持 L3/L4 层（IP+端口）的粗粒度控制。Cilium 在此基础上扩展出 CiliumNetworkPolicy (CNP) 和 CiliumClusterwideNetworkPolicy (CCNP)，将策略能力提升至 L7（HTTP/gRPC/Kafka）、身份标识（Identity）与 DNS 层面。理解两者的差异，是后续将传统 NetworkPolicy 移植到 Cilium 准入策略的关键前提。
核心认知： Cilium 完全兼容 Kubernetes NetworkPolicy 语义，但 CNP/CCNP 提供了更细粒度的控制面。在平台门户集成场景中，我们通常使用 CNP 实现租户级隔离，使用 CCNP 实现全局基线策略。
3.2 策略层级与作用域全景
Cilium 的策略体系分为三个层级，每个层级对应不同的作用域和优先级：
- 集群级（Cluster-wide）： 由
CiliumClusterwideNetworkPolicy定义，不绑定任何 Namespace，作用于整个集群的所有 Pod。适用于全局白名单、审计规则或基础设施策略。 - 命名空间级（Namespace-scoped）： 由
CiliumNetworkPolicy定义，绑定到特定 Namespace，仅对该 Namespace 内的 Pod 生效。适用于租户或应用的隔离策略。 - Kubernetes 原生级（K8s-native）： 由
NetworkPolicy定义，同样绑定 Namespace，但仅支持 L3/L4 规则。Cilium 会将其自动转换为内部 Identity 规则。
优先级规则： 当同一 Pod 匹配多个层级的策略时，Cilium 采用“最宽匹配”原则——只要任一策略允许流量，则允许；所有策略都未明确允许，则拒绝。集群级策略通常用于“默认拒绝”的基线，命名空间级策略用于“显式允许”的业务规则。
3.3 NetworkPolicy 与 CiliumNetworkPolicy 核心差异
| 对比维度 | Kubernetes NetworkPolicy | CiliumNetworkPolicy (CNP) |
|---|---|---|
| 协议层支持 | 仅 L3/L4（TCP/UDP/SCTP + IP + 端口） | L3/L4 + L7（HTTP/gRPC/Kafka/DNS/ICMP） |
| 选择器机制 | 基于 Pod Label 和 Namespace Label | 基于 Label + 身份标识（Identity）+ CIDR + DNS + Service |
| 规则方向 | ingress / egress 双向 | ingress / egress 双向，支持 toFQDN、toCIDR、toEntities |
| 策略作用域 | 仅 Namespace 级 | Namespace 级（CNP）+ 集群级（CCNP） |
| 审计与日志 | 无原生审计 | 支持策略审计模式（audit mode）、Hubble 流量可视化 |
| 规则匹配逻辑 | 基于 IP 和端口，Pod 重启后 IP 变化需重新匹配 | 基于身份标识（Security Identity），Pod 重启后身份不变，策略持续生效 |
| API 版本 | networking.k8s.io/v1 |
cilium.io/v2 |
移植陷阱： 直接将 NetworkPolicy 的
ipBlock 规则迁移到 CNP 时，需注意 Cilium 推荐使用 toCIDR / fromCIDR 并配合 except 排除列表。此外，NetworkPolicy 中的 podSelector: {}（空选择器）在 CNP 中需显式转换为 fromEndpoints: [{}] 或使用 fromEntities: all，否则语义可能不一致。
3.4 策略作用域与优先级详解
Cilium 的策略引擎按以下顺序评估流量：
- 集群级策略（CCNP） 最先加载，提供全局默认行为（通常为默认拒绝）。
- 命名空间级策略（CNP） 在各自 Namespace 内叠加，可覆盖集群级策略的允许规则。
- Kubernetes 原生策略（NetworkPolicy） 由 Cilium 自动转换为内部 Identity 规则，与 CNP 在同一 Namespace 内共存。
当多个策略同时匹配时，Cilium 采用 “允许优先” 的合并逻辑：
- 如果集群级策略拒绝某流量，但命名空间级策略显式允许，则流量被允许。
- 如果命名空间级策略未定义任何规则，则继承集群级策略的默认行为。
- 如果同一 Namespace 内存在多个 CNP，规则按 “并集” 合并——只要任一 CNP 允许，则允许。
3.5 策略移植适配要点
在平台门户集成场景中，将传统 NetworkPolicy 移植到 Cilium 策略体系时，需重点关注以下适配点：
- L7 规则扩展： 原 NetworkPolicy 仅能控制端口，移植后可在 CNP 中增加 HTTP 方法、路径、gRPC 服务名等 L7 规则，实现更细粒度的 API 级准入。
- 身份标识替换 IP： 将
ipBlock规则替换为fromEndpoints/toEndpoints基于 Label 的选择，避免因 Pod IP 变化导致策略失效。 - 集群级基线策略： 使用 CCNP 定义全局默认拒绝规则，然后在各 Namespace 的 CNP 中显式放行业务流量，实现“零信任”基线。
- 审计模式过渡： 在移植初期，为 CNP 开启
spec.enableAudit: true，在不阻断流量的情况下记录策略匹配日志，验证规则正确性后再切换为强制模式。
最佳实践： 在平台门户中，建议将 CCNP 用于基础设施策略（如允许 kube-dns、节点健康检查），将 CNP 用于租户业务策略。通过 Hubble 实时监控策略命中情况，定期审计未使用的规则，保持策略集精简。