Cilium 网络策略生态变化带来哪些运维关注

如果你正在维护 Cilium 集群，最近真正值得关注的不是“又多了一个策略资源”，而是网络策略的治理边界正在变得更清晰：标准 Kubernetes NetworkPolicy、集群级 ClusterNetworkPolicy、Cilium 扩展的 CiliumNetworkPolicy 与 CiliumClusterwideNetworkPolicy 可以同时存在，但它们的范围、层级和升级影响并不相同。Cilium 1.20 的官方资料还把 Gateway API、CNI 配置版本和若干旧能力的迁移提醒放到了升级路径里。

本文把这次变化整理成一份运维关注清单：先看资源怎样分工，再看默认拒绝和范围风险，最后把升级前后的动作落到平台团队、应用团队和值班人员都能执行的项目上。

官方地址：https://cilium.io/

先把“生态变化”翻译成四个运维问题

我在整理策略仓库时，最容易出现的误区是把所有 YAML 都叫作“Cilium 策略”。更稳妥的做法是先回答四个问题：它由谁维护、选中哪些端点、作用于哪个范围、升级时谁需要配合。Cilium 官方文档当前列出了四类常见入口：

• NetworkPolicy：Kubernetes 原生资源，主要表达 Pod 的 L3/L4 入口和出口限制。
• ClusterNetworkPolicy：Kubernetes Network Policy API 的集群范围资源，Cilium 文档说明它从 1.20 开始获得支持，并带有 Admin、NetworkPolicy、Baseline 等层级概念。
• CiliumNetworkPolicy：命名空间内的 Cilium 扩展资源，可表达更丰富的 L3-L7 规则。
• CiliumClusterwideNetworkPolicy：非命名空间资源，适合集群级规则，并支持节点选择器。

因此，运维关注点从“有没有写规则”变成“规则的治理来源是否单一、范围是否可解释、升级后是否仍然能被团队理解”。

资源并存时，先建立一张范围账本

官方文档特别提醒，多种策略类型可以同时运行，但如果不认真梳理完整的允许流量，可能出现意外的放行行为。实际治理中，我会给每条规则补三列元数据：资源类型、选择器范围、责任团队。这样看到一条规则时，先知道它是命名空间内的应用策略，还是平台团队下发的集群基线。

可以用下面这段简化的 YAML 作为仓库约定示例。它不是一份可直接覆盖生产环境的完整策略，而是把责任范围写进描述，并用中文注释提示容易被忽略的字段：

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: platform-dns-baseline
spec:
  # 集群级基线只选择业务 Pod，避免误伤系统组件。
  endpointSelector:
    matchExpressions:
      - key: io.kubernetes.pod.namespace
        operator: NotIn
        values: [kube-system]
  egress:
    # 生产环境要明确 DNS 目标与 53 端口，否则默认拒绝会影响服务发现。
    - toEndpoints:
        - matchLabels:
            k8s-app: kube-dns
            io.kubernetes.pod.namespace: kube-system
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP

这张账本还有一个好处：应用团队新增命名空间策略时，不需要猜平台基线是否已经覆盖 DNS；平台团队也能知道哪些规则属于默认保护，哪些规则必须由应用团队维护。

首次选中端点后，默认拒绝会改变故障表现

Cilium 的默认模式并不是“安装后所有流量都立即拒绝”。官方策略文档描述的是：没有策略选中端点时，流量默认放行；当某条策略带有 ingress 或 egress 并选中端点后，对应方向会进入 default-deny，只有显式允许的流量才能继续。这个变化经常被误读成“策略已经生效但应用偶尔超时”，实际上可能是第一条策略刚刚改变了该端点的基线。

运维上要把排查从应用日志扩展到三个方向：

1. 检查新增规则的 endpointSelector 是否比预期更宽。
2. 分别检查 ingress 和 egress，不要把“允许对方访问”误认为“本端可以主动访问”。
3. 先确认 DNS、健康检查、遥测和控制面依赖是否写在允许集合里。

官方文档还说明，Cilium 的策略是白名单模型；如果多个规则匹配，允许集合会合并。也就是说，审查时不能只打开一份 YAML 判断结果，必须把同一端点命中的规则放在一起看。

跨集群和层级策略，重点是“范围是否真的如你所想”

Cluster Mesh 场景下，策略的跨集群语义尤其值得单独记录。Cilium 官方文档指出，安全策略不会自动分发到所有集群；需要在各集群分别应用相应的 NetworkPolicy 或 CiliumNetworkPolicy。同时，端点选择默认偏向本地集群，若要匹配其他集群，应显式使用集群标签。

这意味着“集群级”不等于“所有集群级”。跨集群治理至少要保留以下判断：

• 规则是在本集群的 Kubernetes API 中声明，还是已经同步到远端集群。
• CiliumClusterwideNetworkPolicy 的集群范围，和 Cluster Mesh 的多集群范围不是同一个概念。
• 采用 cluster 或 cluster-mesh 等实体时，需确认它是否包含期望的远端身份。

若团队准备从旧的集群级策略逐步迁移到 Kubernetes ClusterNetworkPolicy，还要特别记录 Admin、NetworkPolicy、Baseline 三层之间的覆盖关系。官方说明中，Admin 层规则优先级高于 NetworkPolicy 层，普通命名空间策略不能覆盖它。这个事实应该写进变更单，而不是只存在于平台工程师的记忆里。

升级 Cilium 1.20，别只盯着镜像标签

Cilium 1.20 的官方升级指南给出的注意事项，说明网络策略生态变化已经和周边组件绑定在一起。升级前至少要把以下事项变成清单：

1. 检查 Gateway API 版本。官方说明要求 Cilium 1.20 的 Gateway API 支持至少使用 v1.6.1；如果正在使用 TLSRoute，应先备份资源并确认 CRD 版本转换不会让对象在 API Server 中不可读。
2. 检查策略中的旧代理扩展字段。Envoy Go Extensions 已移除，旧策略中涉及 kafka、l7 或 l7proto 的 toPorts.rules 需要按升级指南处理。
3. 检查 CNI 配置版本。Cilium 1.20 默认使用 CNI standard v1.0.0；自定义 CNI 配置需要确认请求的版本是否仍然适配。
4. 检查跨集群默认范围。官方升级说明提到 policy-default-local-cluster 相关行为变化，使用跨集群端点选择的策略要逐条复核。
5. 按相邻小版本升级。官方指南强调，测试过的升级和回滚路径是连续的小版本之间；先把当前版本更新到最新补丁，再进入下一小版本。

把变化落到一份可交接的运维清单

如果只是读完发布说明，过几周仍然容易回到“出问题再查”。我更建议把清单拆成三种角色，避免所有事情都压在一个平台值班人身上。

遇到策略拒绝时，也要注意默认的错误表现。官方文档写明，默认的 deny response 是静默丢弃，应用侧通常看到连接超时；实验性的 ICMP 响应只覆盖特定的 IPv4/IPv6 egress 情况，不能把它当成所有拒绝都能立即返回错误。

我的结论是：Cilium 网络策略生态的变化，核心不是多记几个 CRD 名字，而是重新建立“资源类型—作用范围—责任团队—升级依赖”的对应关系。先把账本补齐，再把 1.20 升级说明转成逐项动作，策略数量增加并不会自动变成治理失控。

相关问题

CiliumNetworkPolicy 和 NetworkPolicy 应该怎么选？

能用 Kubernetes 原生 L3/L4 表达的应用规则优先保持标准资源；需要 Cilium 扩展能力或更细的 L7 表达时，再使用 CiliumNetworkPolicy，并明确责任边界。

为什么一条新策略会让原来正常的请求超时？

如果策略选中了端点并包含对应方向，端点可能进入 default-deny，未显式允许的流量会被丢弃。应先确认选择器和 DNS、健康检查等依赖。

CiliumClusterwideNetworkPolicy 能自动覆盖 Cluster Mesh 的所有集群吗？

不能直接这样理解。集群级资源仍属于声明它的集群，跨集群策略需要按官方文档在各集群配置，并显式表达远端集群身份。

升级 Cilium 1.20 前最先看哪份资料？

先看官方 Upgrade Guide 的 1.20 版本说明，再按 Gateway API、旧代理扩展、CNI 自定义配置和跨集群策略选择逐项对照。