3. 常见CNI准入策略引擎：Calico、Cilium、Antrea、Kube-OVN与OVN-Kubernetes

在Kubernetes网络生态中，准入策略引擎是实现租户隔离、微服务安全与合规审计的核心组件。不同CNI插件对网络策略的实现深度、语法扩展与底层转发机制存在显著差异。本章对五种主流引擎进行横向对比，并深入其策略模型与故障排查要点。

3.1 策略引擎能力矩阵

3.2 Calico NetworkPolicy：iptables与eBPF双引擎

Calico的策略引擎基于Felix组件，通过将策略规则转换为iptables链或eBPF程序实现。其核心优势在于GlobalNetworkPolicy支持跨命名空间的全局规则，适用于安全基线管控。

3.2.1 策略语法示例

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: deny-all-except-dns
  namespace: production
spec:
  selector: app == 'web-frontend'
  ingress:
    - action: Allow
      protocol: UDP
      destination:
        ports:
          - 53
    - action: Deny
      protocol: TCP
      destination:
        ports:
          - 8080
  egress:
    - action: Allow
      protocol: UDP
      destination:
        ports:
          - 53
    - action: Deny

3.2.2 故障排查要点

• Felix日志级别： 设置 FELIX_LOGSEVERITYSCREEN=debug 可查看策略计算与iptables更新过程。
• iptables规则验证： 使用 iptables -L -n -v | grep cali- 检查策略链是否命中。
• eBPF模式排查： 使用 calicoctl get hep -A 查看主机端点状态，确认策略是否下发到BPF map。

3.3 Cilium NetworkPolicy：eBPF原生与L7感知

Cilium利用eBPF在内核态执行策略，支持L3/L4/L7多层匹配。其CiliumNetworkPolicy资源可基于Pod标签、IP、端口、HTTP方法、gRPC服务名等维度进行精细化控制。

3.3.1 L7策略示例

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-http-get
  namespace: api
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/v1/orders"

3.3.2 Hubble流日志分析

Hubble提供实时流日志，可用于策略命中验证与故障定位：

# 查看被拒绝的流量
hubble observe --verdict DROPPED --since 5m

# 查看特定Pod的L7请求
hubble observe --pod backend-7f8b9c --protocol http --since 10m

3.4 Antrea NetworkPolicy：基于OVS的Kubernetes原生扩展

Antrea以Open vSwitch为数据面，策略通过OVS流表实现。其Antrea ClusterNetworkPolicy支持集群范围的策略，并引入AppliedTo字段实现更灵活的Pod选择。

3.4.1 策略结构对比

3.4.2 故障排查命令

# 查看OVS流表
ovs-ofctl dump-flows br-int

# 查看Antrea Agent策略状态
antctl get networkpolicy -n production

# 查看AppliedTo组
antctl get appliedtogroup -n production

3.5 Kube-OVN与OVN-Kubernetes ACL：基于OVN的流表策略

Kube-OVN和OVN-Kubernetes均基于OVN（Open Virtual Network）实现，策略以ACL（Access Control List）形式写入OVN北向数据库，最终由OVS流表执行。两者语法高度相似，但Kube-OVN在子网与VPC隔离方面提供了更丰富的抽象。

3.5.1 ACL语法示例（Kube-OVN）

apiVersion: kubeovn.io/v1
kind: ACL
metadata:
  name: deny-cross-ns
spec:
  namespace: production
  priority: 1000
  direction: ingress
  match:
    - srcIP: "10.16.0.0/16"
      dstIP: "10.16.1.0/24"
      protocol: TCP
      dstPort: "3306"
  action: drop

3.5.2 OVN流表排查流程

1. 查看逻辑流表： ovn-sbctl lflow-list 列出所有逻辑流，确认ACL规则是否生成。
2. 查看ACL状态： kubectl get acl -A 确认ACL资源已同步。
3. 数据面验证： ovs-appctl ofproto/trace br-int in_port=1,tcp,nw_src=10.16.0.5,nw_dst=10.16.1.10,tp_dst=3306 模拟流量路径。

3.6 策略引擎架构对比图

下图展示了五种引擎的策略下发路径与数据面转发模型，帮助理解各引擎的故障排查切入点。

3.7 策略生效延迟对比

策略从下发到完全生效的延迟直接影响故障排查窗口。以下为各引擎在100条策略规模下的实测数据：