📚 课程目录第4章策略模型对比

4. 策略模型对比：Calico vs Cilium vs Antrea vs Kube-OVN

在 Kubernetes 容器网络接口（CNI）生态中，网络策略的实现方式、语法和作用域差异巨大。本章从策略语法、作用域、支持的操作（allow/deny/log）以及默认行为四个维度，对 Calico、Cilium、Antrea 和 Kube-OVN 进行系统性对比，帮助你在生产环境中做出正确的技术选型。

核心观点： 策略模型决定了安全规则的表达能力、运维复杂度和故障排查路径。选择 CNI 时，不仅要看性能，更要看策略模型是否匹配你的安全合规需求。

4.1 策略语法与表达能力

四种 CNI 的策略语法均基于 Kubernetes 原生 NetworkPolicy 进行扩展，但各自的 CRD（自定义资源定义）和标签选择器能力差异显著。

维度	Calico	Cilium	Antrea	Kube-OVN
策略 CRD	NetworkPolicy（原生） GlobalNetworkPolicy GlobalNetworkSet	CiliumNetworkPolicy CiliumClusterwideNetworkPolicy	NetworkPolicy（原生） AntreaClusterNetworkPolicy AntreaNetworkPolicy	NetworkPolicy（原生） Kube-OVN 使用 ACL 规则映射
标签选择器	支持 Kubernetes 标签 + 命名空间选择器 + 服务账户选择器	支持 Kubernetes 标签 + 端点选择器 + DNS 名称 + CIDR + 服务账户 + 集群实体	支持 Kubernetes 标签 + 命名空间选择器 + 节点选择器	支持 Kubernetes 标签 + 子网选择器 + VPC 选择器
规则语法	YAML 声明式，支持 ingress/egress 规则链	YAML 声明式，支持 L3/L4/L7 规则，支持 HTTP/gRPC/Kafka 协议过滤	YAML 声明式，支持 L3/L4 规则，支持 FQDN 规则	YAML 声明式 + 命令行 ACL，支持 L2/L3/L4 规则
策略优先级	通过 order 字段显式指定优先级（数字越小优先级越高）	通过 labels 和 priority 字段控制，支持默认拒绝优先级	通过 priority 字段指定，支持 tier 分组（Security、Platform、Network）	基于 ACL 规则的序号，序号越小优先级越高

  语法复杂度排名： Cilium > Calico > Antrea > Kube-OVN。Cilium 的 L7 策略能力最强，但学习曲线最陡；Kube-OVN 的 ACL 语法更接近传统网络设备，适合网络工程师。

4.2 作用域对比

作用域决定了策略可以影响哪些工作负载和网络流量。四种 CNI 在命名空间级别、集群级别和节点级别的支持情况如下：

4.3 支持的操作：allow / deny / log

策略操作决定了流量被允许、拒绝还是记录。四种 CNI 在操作支持上存在关键差异：

操作类型	Calico	Cilium	Antrea	Kube-OVN
allow	✅ 通过 action: Allow	✅ 通过 endpointSelector + toPorts	✅ 通过 action: Allow	✅ 通过 ACL allow 规则
deny	✅ 通过 action: Deny（显式拒绝）	✅ 通过 action: Deny（支持 L3/L4/L7 拒绝）	✅ 通过 action: Drop（默认拒绝）	✅ 通过 ACL drop 规则
log	✅ 通过 action: Log（仅记录，不阻断）	✅ 通过 action: Audit（审计模式，记录但不阻断）	❌ 不支持独立的 log 操作	✅ 通过 ACL log 规则（支持日志级别配置）
pass	✅ action: Pass（跳过后续策略）	❌ 不支持	❌ 不支持	❌ 不支持

关键差异： Calico 是唯一支持 Pass 操作的 CNI，允许策略链中跳过后续规则，这在多层级策略编排中非常有用。Antrea 不支持独立的 log 操作，日志记录需要依赖外部工具（如 Fluentd）抓取流日志。Cilium 的 Audit 模式可以在不阻断流量的情况下记录策略命中情况，适合策略上线前的灰度验证。

4.4 默认行为对比

默认行为决定了在没有匹配策略时流量的处理方式，这是安全合规中最容易忽略的陷阱。

4.5 策略模型综合对比总结

评估维度	Calico	Cilium	Antrea	Kube-OVN
策略表达能力	★★★★☆	★★★★★	★★★☆☆	★★★☆☆
作用域覆盖	★★★★★	★★★★★	★★★★☆	★★★☆☆
操作丰富度	★★★★★	★★★★☆	★★★☆☆	★★★★☆
默认安全	★★★☆☆	★★★☆☆	★★★★★	★★☆☆☆
运维复杂度	★★★☆☆	★★★★☆	★★☆☆☆	★★★☆☆
适用场景	混合云、多集群、主机安全	微服务、API 安全、eBPF 生态	VMware 集成、安全合规	传统网络迁移、VPC 网络

  选型决策树：

  • 需要 L7 应用层策略（HTTP/gRPC/Kafka）→ Cilium

  • 需要节点级别主机安全策略 → Calico

  • 需要开箱即用的默认拒绝安全模型 → Antrea

  • 需要与物理网络 ACL 模型对齐 → Kube-OVN

  • 需要策略审计和灰度验证（Audit/Log 模式）→ Calico 或 Cilium

4.6 策略模型故障排查要点

不同策略模型在故障排查时的切入点不同，以下是针对每种 CNI 的排查建议：

Calico： 使用 calicoctl get policy 查看策略优先级排序，使用 calicoctl get workloadEndpoint 检查端点策略应用状态。注意 order 字段的数值越小优先级越高，默认拒绝策略的 order 应设为最大值（如 10000）。
Cilium： 使用 cilium endpoint list 查看端点策略状态，使用 cilium policy trace 进行策略追踪。注意 Cilium 的 labels 匹配机制，标签不匹配是策略不生效的最常见原因。
Antrea： 使用 antctl get networkpolicy 查看策略应用状态，使用 antctl trace 进行流量路径追踪。注意 Antrea 的 tier 分组机制，Security 组的策略优先级高于 Platform 组。
Kube-OVN： 使用 kubectl ko nbctl list ACL 查看 OVN 中的 ACL 规则，使用 kubectl ko trace 进行流量路径分析。注意 Kube-OVN 的 ACL 规则序号决定了优先级，序号越小优先级越高。

常见陷阱： 所有 CNI 在策略未生效时，首先检查 标签选择器 是否匹配目标 Pod。标签拼写错误、命名空间选择器遗漏、服务账户选择器不匹配是策略故障的三大根源。建议在部署策略前，先使用 kubectl get pods --show-labels 确认目标 Pod 的标签。