背景与问题界定

某跨国电商平台的 Kubernetes 集群同时承载了内部业务、第三方集成和面向公网的 API 网关，租户隔离仅靠 namespace 逻辑分隔。安全审计发现：一个被攻破的博客容器可以通过 Cluster IP 直接访问支付数据库 Pod 的 3306 端口，没有任何网络层面的访问控制。Kubernetes 原生的 NetworkPolicy 提供了五元组规则的抽象语义，但在实际生产环境中面临着性能瓶颈、策略粒度不够精细、日志审计缺失等多重挑战。随着 Cilium 基于 eBPF 的技术路线成为 CNCF 毕业项目，团队需要在 Calico 和 Cilium 之间做出符合长期技术架构方向的选择。

目标拆解与工程约束

  1. 高性能策略执行：网络策略的匹配和执行必须对 Pod 间的网络延迟产生小于 5% 的影响，在大规模集群（300+ 节点、5000+ 策略规则）下，策略更新的收敛时间不能超过 10 秒。
  2. L7 层策略支持：除了传统的 IP:Port 五元组控制，需要支持基于 HTTP 方法、路径、gRPC 服务名、Kafka Topic 等七层协议粒度的访问控制，满足微服务粒度的最小权限原则。
  3. 日志审计与可视化：被拒绝的流量必须记录完整的客户端/服务端信息、协议类型和拒绝理由，通过标准接口导出到 SIEM 系统，同时提供可视化拓扑图用于策略编排和合规审计。
  4. 多云可移植性：网络策略的定义和 API 需要在 AWS、阿里云和自建机房之间保持语义一致，不依赖特定云厂商的网络 overlay 实现，策略即代码（Policy as Code）可版本化管理和 GitOps 化。

方案设计

我们对比了 Calico 和 Cilium 两种方案。Calico 采用基于 iptables 和 IPVS 的数据面，NetworkPolicy 通过 Felix Agent 转换为 iptables 规则链。优势是成熟稳定、社区支持广泛、对传统网络运维友好；但在大规模集群中，iptables 规则链的线性匹配导致性能退化明显，策略变更时需要全量刷新规则，5000 条规则的集群中策略收敛耗时达 30 秒以上。

Cilium 使用 eBPF 技术直接在 Linux 内核中执行网络策略，每个策略规则编译为 BPF 程序挂载到网络路径的 hook 点，规则匹配复杂度从 O(n) 降为 O(1)（通过 BPF map 的哈希查找）。Cilium 1.14+ 引入的 NetworkPolicy v2 API 提供了原生 L7 策略支持：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payment-isolation
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: api-gateway
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/api/v1/payments"
  - fromEndpoints:
    - matchLabels:
        app: monitoring
    toPorts:
    - ports:
      - port: "9090"
          protocol: TCP

L7 策略的解析通过 Cilium 的代理模式（Envoy）或原生 eBPF 模式实现。对于性能敏感的支付服务，我们选择原生 eBPF L7 策略（Cilium 通过 bpf_host 程序直接解析 HTTP/1.x 和 HTTP/2），避免 Envoy 代理引入的额外上下文切换开销。

实施路径与关键决策

  • 第一步：建立策略优先的安全模型——默认 deny 所有跨 namespace 的流量，然后基于服务依赖关系图逐步放行。使用 k8s-network-policy-controller 工具扫描集群现有的网络流量模式，自动生成 Baseline 策略。
  • 第二步：现有 Calico 集群逐步迁移到 Cilium，采用 Cilium 的 cni-chaining 模式先并行运行，逐步将节点迁移到 Cilium 纯模式，利用 Hubble UI 的流量可视化确认服务通信未受影响。
  • 第三步：部署 Hubble Relay 提供全局网络流的分布式查询和审计日志，流量日志接入 Elasticsearch 存储 90 天，通过 Fluentd 实时输出到 SIEM 系统，配合 Cilium 的 monitor 命令实时追踪策略命中情况。
  • 第四步：将 NetworkPolicy 纳入 GitOps 工作流，通过 OPA Gatekeeper 的 validate 策略强制要求每个 namespace 必须包含 NetworkPolicy 资源，不满足的 Deployment 拒绝创建。

验证指标与可持续迭代

安全性提升通过以下指标量化：东西向流量违规拦截从零提升到日均发现并阻断 45 次异常连接；策略误拦截导致的业务故障降低到每月不超过 2 起；策略变更的收敛时间从 30s（iptables 全量刷新）降至 3s（eBPF 增量更新）。每周通过 Hubble 的 Network Policy Review 面板进行策略一致性核查，自动化检测"过于宽松"的策略（如 from: {} 允许所有入口流量）。

工程落地思考

网络策略的关键挑战不在于"怎么写规则"，而在于"怎么确定规则的范围"。很多团队倾向于先写 Allow-All 策略再逐步收紧，但生产环境中的历史遗留流量可能包含被遗忘的抓包工具、过期的监控探针和不规范的 Sidecar 代理。我们的实践经验是：先在 Hubble 中开启流日志追踪 7-14 天，基于实际流量模式自动生成推荐策略，再用 CiliumNetworkPolicy（非集群作用域）替代全局策略，逐步收紧到最小权限。Cilium 虽然在性能和创新上领先，但在裸机和离线环境中的部署复杂度高于 Calico，选择时需考虑团队的 eBPF 技术储备和运维能力。