ProjectCalico中多GlobalNetworkPolicy策略叠加问题的深度解析

背景介绍

在Kubernetes网络策略管理中，ProjectCalico作为一款流行的网络策略引擎，其GlobalNetworkPolicy功能允许管理员定义集群范围的网络策略。但在实际使用中，当多个GlobalNetworkPolicy策略作用于同一组资源时，策略之间并非简单的叠加关系，而是存在覆盖行为，这一特性值得深入探讨。

问题现象

用户在使用Calico时发现，当定义两个具有相同namespaceSelector的GlobalNetworkPolicy时：

1. 第一个策略(base)允许特定命名空间访问kube-system命名空间中的kube-dns服务(UDP Lite协议，端口53)
2. 第二个策略(egress)允许相同命名空间访问任意目的地的443端口(TCP协议)

预期行为是这两个策略应该叠加生效，即允许同时访问DNS服务和外部443端口。但实际观察到的行为是后者策略完全覆盖了前者，导致DNS访问被阻断。

技术原理分析

Calico的策略评估机制采用"顺序优先"原则，而非叠加合并。当多个策略匹配同一组资源时：

1. 策略按照特定顺序进行评估(通常按名称字母顺序)
2. 只有最后一个匹配的策略会生效
3. 不会自动合并多个策略的规则

这种设计源于网络安全领域的"默认拒绝"原则，确保策略评估具有确定性和可预测性，避免因规则合并产生意外问题。

解决方案

针对这种需求，Calico提供了两种实现方式：

方案一：合并策略规则

将多个策略规则合并到单个GlobalNetworkPolicy中：

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: combined-policy
spec:
  namespaceSelector: has(example)
  types:
    - Egress
  egress:
    - action: Allow
      protocol: UDPLite
      destination:
        namespaceSelector: projectcalico.org/name == "kube-system"
        selector: k8s-app == "kube-dns"
        ports:
          - 53
    - action: Allow
      protocol: TCP
      destination:
        nets:
          - 0.0.0.0/0
        ports:
          - 443

方案二：使用策略顺序控制

通过精心设计策略名称来控制评估顺序(按字母顺序)：

# 命名为0-base确保先评估
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: 0-base
spec:
  # ...DNS规则...

# 命名为1-egress确保后评估
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: 1-egress
spec:
  # ...443规则...

协议选择注意事项

值得注意的是，在DNS策略中使用UDPLite协议是一个特殊案例。通常情况下，DNS服务使用UDP协议，但在某些Calico实现中可能需要特定协议配置。这反映了网络策略实施中的复杂性，管理员应根据实际环境测试验证协议选择。

版本兼容性说明

在GKE环境中，默认安装的是Calico的v1 CRD版本，而最新功能通常需要v3 API。管理员可以通过以下方式升级：

1. 安装Calico API服务器组件
2. 使用calicoctl工具管理v3资源
3. 确保集群组件版本兼容性

最佳实践建议

1. 尽量合并相关规则到单个策略中，减少策略数量
2. 如必须使用多个策略，采用明确的命名约定控制评估顺序
3. 新部署优先使用v3 API版本
4. 实施策略前进行全面测试，特别是协议和端口组合
5. 建立策略文档，记录每个策略的业务目的

通过理解Calico策略评估机制并采用适当的设计模式，管理员可以构建既安全又符合业务需求的网络策略体系。