4. Cilium 网络策略模型:Identity-based 策略、Layer 3/4/7 策略、Endpoint Selector 与 CIDR 规则

Cilium 的网络策略模型基于 eBPF 和 Kubernetes 身份标识(Identity),提供了比传统 iptables 或 NetworkPolicy 更精细、更高效的流量控制能力。本章深入解析 Cilium 策略的核心组件:基于身份的访问控制、L3/L4 与 L7 策略、端点选择器以及 CIDR 规则,帮助你在 GitOps 流水线中精准定义安全边界。

4.1 策略模型核心:基于身份(Identity-based)

传统 Kubernetes NetworkPolicy 依赖 Pod 的 IP 地址和标签选择器,在动态环境中 IP 频繁变化,策略维护成本高。Cilium 引入 Security Identity(安全身份)概念,将每个 Pod 的标签组合映射为一个 24 位整数 ID。策略不再绑定 IP,而是绑定 Identity,大幅提升可扩展性和动态适应性。

关键优势: 当 Pod 重启或迁移时,IP 改变但 Identity 不变,策略无需更新;集群规模增长时,Identity 数量远小于 IP 数量,控制面压力更低。
Identity 分配机制: Cilium Agent 通过 Kubernetes API 监听 Pod 事件,提取标签并计算 SHA256 哈希,取低 24 位作为 Identity。相同标签的 Pod 共享同一 Identity,减少策略规则数量。

4.2 策略层级:Layer 3/4 与 Layer 7

Cilium 策略按 OSI 模型分层,支持从网络层到应用层的细粒度控制。下表对比各层策略的能力与适用场景:

策略层级 匹配维度 典型规则 性能开销 适用场景
L3 源/目的 IP、CIDR、Security Identity 允许 10.0.0.0/8 访问 极低(eBPF 直接匹配) 集群间通信、外部网络隔离
L4 协议(TCP/UDP/SCTP)、端口 允许 TCP 443 入站 低(eBPF 端口匹配) 服务端口暴露、数据库访问控制
L7 HTTP 方法、路径、头部;gRPC 服务名;Kafka Topic 等 允许 GET /api/v1/* 中等(需代理或 eBPF 解析) 微服务 API 鉴权、API 网关策略
性能调优提示: L7 策略需要启用 Cilium 的代理(Envoy)或 eBPF L7 解析器,会引入额外延迟。在 GitOps 流水线中,建议对高吞吐路径仅使用 L3/L4 策略,仅在安全审计或 API 版本控制场景启用 L7。

4.3 端点选择器(Endpoint Selector)与 CIDR 规则

Cilium 策略使用 endpointSelector 和 cidr 字段定义流量目标。两者结合可实现集群内部与外部流量的统一管理。

4.3.1 Endpoint Selector:基于标签的精准匹配

endpointSelector 使用 Kubernetes 标签选择器语法,匹配集群内的 Pod 或外部端点(如 VM、裸金属)。支持 matchLabels(精确匹配)和 matchExpressions(集合/存在性匹配)。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

4.3.2 CIDR 规则:外部网络访问控制

对于集群外部的 IP 范围(如云服务、数据库、外部 API),使用 fromCIDR 或 toCIDR 定义。CIDR 规则支持 IPv4 和 IPv6,可与端口规则组合。

spec:
  egress:
  - toCIDR:
    - 192.168.1.0/24
    - 10.0.0.0/8
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP
最佳实践: 在 GitOps 流水线中,将 CIDR 规则定义为 ConfigMap 或 Helm values,便于环境间复用。避免硬编码 IP,使用 DNS 名称或 ExternalName 服务替代。

4.4 策略模型架构图

下图展示 Cilium 策略模型的核心组件及其关系:Identity 分配、策略匹配层级、端点选择器与 CIDR 规则的协同工作流。

Cilium 网络策略模型架构 Cilium 网络策略模型架构 Kubernetes 集群 Security Identity 分配器 标签 → 24位 Identity Cilium 策略引擎 eBPF 规则编译与注入 eBPF 数据面 内核级策略执行 策略层级 L3 网络层 IP/CIDR/Identity 允许/拒绝 IP 范围 性能:极低 L4 传输层 协议 + 端口 TCP/UDP/SCTP 性能:低 L7 应用层 HTTP/gRPC/Kafka 方法/路径/头部 性能:中等 流量目标定义 • Endpoint Selector:matchLabels / matchExpressions → 集群内 Pod/VM • CIDR 规则:fromCIDR / toCIDR → 外部网络(云服务、数据库、外部 API)

4.5 策略组合示例:Identity + L4 + CIDR

以下策略展示如何组合 Identity、L4 端口和 CIDR 规则,实现微服务对外部数据库的安全访问:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: secure-db-access
spec:
  endpointSelector:
    matchLabels:
      app: order-service
  egress:
  - toCIDR:
    - 10.100.0.0/16    # 数据库子网
    toPorts:
    - ports:
      - port: "5432"
        protocol: TCP
  - toEndpoints:
    - matchLabels:
        app: logging
    toPorts:
    - ports:
      - port: "9090"
        protocol: TCP
GitOps 集成要点: 将策略 YAML 存储在 Git 仓库,通过 Argo CD 或 Flux 自动同步。使用 Kustomize 或 Helm 管理环境差异(如开发/生产数据库 CIDR 不同),避免手动修改策略。

4.6 性能调优建议

  • Identity 缓存优化: 确保 Cilium Agent 的 identity-allocation-mode 为 "crd"(默认),避免频繁 API 调用。
  • 策略规则合并: 将多个小策略合并为一个大策略,减少 eBPF 程序数量,提升编译效率。
  • CIDR 聚合: 使用尽可能大的 CIDR 块(如 /16 而非 /24),减少规则条目。
  • L7 策略范围控制: 仅在必要路径启用 L7,使用 toFQDNs 替代 CIDR 可减少策略更新频率。
监控指标: 使用 cilium monitor 或 Hubble 观察策略命中次数与延迟。关注 cilium_policy_l7_total 和 cilium_policy_l4_total 指标,评估策略性能开销。