Cilium 网络策略生态更新后怎样评估替换成本

Cilium 网络策略生态更新后，是否值得替换现有 CNI 或策略方案，不能只看“新增了多少功能”。更可靠的判断是：把现有规则、身份模型、流量观测、跨集群能力、入口链路和回滚动作逐项盘点，再用一小段并行流量验证实际兼容性。这样算出来的替换成本，通常比把 YAML 全部改写一遍更接近真实项目。

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

Cilium 1.20 的生态信号很明确：Gateway API 支持继续扩大，Kubernetes ClusterNetworkPolicy（KCNP）提供了集群级、分层的策略模型，Cluster Mesh 也加入了更简洁的跨集群策略实体。但这些变化同时说明，Cilium 的能力已经分成“上游标准资源”“Cilium 扩展”和“运行时观测/平台能力”三层。替换前先分层，才不会把可迁移的规则和强绑定能力混在一起。

先把生态更新拆成三层

第一层是 Kubernetes 标准资源。传统 NetworkPolicy 主要表达命名空间级的 L3/L4 进出站规则；Cilium 文档当前还列出了集群范围的 ClusterNetworkPolicy。Cilium 1.20 对 KCNP 的支持引入了 Admin 和 Baseline 两类策略层级，平台侧可以设置更高优先级的集群护栏，应用命名空间的规则不能随意覆盖 Admin 层。

第二层是 Cilium 自己的策略资源，包括 CiliumNetworkPolicy 和 CiliumClusterwideNetworkPolicy。它们能表达标准 NetworkPolicy 尚未覆盖的能力，例如基于身份的选择器、DNS/FQDN 或 L7 规则。它们带来的收益很直接，但也是迁移时最容易产生供应商耦合的部分。

第三层是运行时与观测能力。Cilium 使用由标签生成的 security identity，而不是把 Pod IP 当成唯一安全边界；Hubble 则把策略 verdict、服务流量和身份元数据放到观测链路里。若值班手册、告警面板和排障习惯都依赖这些对象，替换成本就不只是一批 YAML。

先盘点现有策略，而不是先做字段转换

把当前集群中的策略按四个问题拆开：规则写在什么资源里，选择器依赖哪些标签，流量经过哪些入口/代理，故障时靠什么证据判断。可以先导出对象清单，作为变更单的输入：

# 只读取策略对象和关键状态，不在这一步修改集群
kubectl get networkpolicy -A -o name
kubectl get cnp,ccnp -A -o name
kubectl get clusternetworkpolicy -A -o name

# 把入口、服务网格和跨集群依赖单独列出，避免只盘点策略 YAML
kubectl get gateway,gatewayclass,httproute -A -o wide
kubectl get ciliumnetworkpolicies,ciliumclusterwidenetworkpolicies -A -o yaml

这份清单至少要标出五种高成本项：只在 Cilium 规则中出现的 L7 字段、依赖 DNS 名称的出站规则、依赖 Cilium identity 的跨命名空间选择器、Cluster Mesh 远端实体，以及 Ingress/Gateway 前后的双策略检查点。任何一项没有目标方案，都应暂列为“待验证”，而不是在迁移脚本里静默删除。

替换成本要按五类工作盘点

一是策略语义成本。标准 NetworkPolicy、KCNP、CiliumNetworkPolicy 的优先级、作用域和可表达字段不同。把“资源能创建”当成“规则等价”会漏掉拒绝优先级、L7 条件和集群级护栏。二是身份成本。Cilium 的标签到安全身份映射会影响规则选择和跨节点通信，不能只用现有 Pod IP 白名单替代。

三是观测成本。原有方案可能依赖 iptables 日志或云厂商流日志，而 Cilium 团队可能依赖 Hubble flow、policy verdict 和服务地图。要逐项确认谁看什么指标、告警如何定位到 namespace、pod、身份和端口。四是跨集群成本。Cluster Mesh 的实体和服务发现让规则更简洁，但它们不是所有 CNI 都能原样承接的契约。五是入口成本。Cilium 的 Ingress/Gateway 流量可能在外部来源到 Envoy、再到后端之间经历两个逻辑策略点；只验证后端 Pod 的入站规则，不能覆盖入口链路。

用并行验证控制切换风险

替换前先建立“旧方案仍负责生产、Cilium 只接管测试节点或测试工作负载”的并行阶段。Cilium 官方迁移文档建议按节点逐步迁移，并提醒迁移期间策略执行需要特别安排；具体集群还应先在测试环境试跑。这里的目标不是证明所有流量都能通，而是把不确定项变成可记录的 verdict。

# 查看 Cilium 组件状态，确认测试集群的控制面已就绪
cilium status --wait

# 只观察最近的策略 verdict，记录来源身份、目标身份、端口和动作
kubectl -n kube-system exec ds/cilium -- \
  hubble observe --type policy-verdict --last 50

# 变更前后都保存对象状态，失败时可以按清单回退
kubectl get networkpolicy,cnp,ccnp -A -o yaml > policy-before.yaml
kubectl get gateway,gatewayclass,httproute -A -o yaml > gateway-before.yaml

每条验证结果都要回答三个问题：原规则允许或拒绝的流量，在新方案中是否得到同样结论；结论依赖的是标签、身份、CIDR 还是域名；如果结果不同，是预期的收紧、能力缺失，还是观测链路没有采到。没有这三项记录，就不应把“测试请求成功”写成迁移完成。

回滚路径要先于正式切换写好

回滚至少分成配置回退和网络提供者回退。配置回退是恢复旧策略对象、旧入口路由和旧告警规则；网络提供者回退则涉及节点排空、CNI 配置、接口和残留规则。Cilium 文档特别强调，迁移高度依赖现有集群配置，不能用一个通用命令替代现场判断。

变更单中应固定这些门槛：哪些命名空间先切、哪些外部地址不能变化、哪些 Hubble 或旧日志信号必须持续存在、发生何种拒绝率或连接重置就停止扩大范围，以及谁有权限执行回退。若策略含有跨集群或 Gateway/Envoy 规则，还要把远端集群和入口控制器的回退顺序写清。

告警确认和复盘项怎么定

告警不要只盯“策略对象数量”。更有价值的是观察被拒绝流量是否集中在某个身份、端口或入口阶段，跨集群连接是否出现新的解析/发现错误，Gateway 或 Envoy 是否出现连接重置，以及旧方案和新方案的日志是否能对同一请求给出可关联的证据。

复盘时把成本分为一次性迁移成本和长期维护成本。一次性成本包括规则转换、双写策略、测试流量和节点滚动；长期成本包括团队是否要继续维护 Cilium 专有 CRD、是否能用上游 API 替代、Hubble 数据是否有存储预算、跨集群实体是否会随拓扑变化，以及下一次升级是否需要再次调整告警与回滚脚本。

最后用一张决策表收口

结论是：Cilium 生态更新带来的价值，往往在标准化、可观测性和跨集群治理上体现；替换成本则藏在策略语义、身份模型、入口链路和团队运维习惯里。只要先完成五类盘点，再以并行验证和可回滚切换推进，就能把“要不要换”从产品印象题变成一份有证据的工程决策。

相关问题

Cilium 的 CiliumNetworkPolicy 能完全替代标准 NetworkPolicy 吗？

不应直接这样理解。CiliumNetworkPolicy 扩展了标准资源未覆盖的表达能力，但越依赖专有字段，未来更换实现时的迁移成本越高。应按规则逐项判断是否能回到标准资源。

只迁移 Cilium CNI，不迁移策略可以吗？

可以作为阶段性方案，但必须明确旧策略提供者与 Cilium 的执行边界。迁移期间的策略执行安排和流量误拦截风险需要在测试集群先确认。

为什么只看 Pod 到 Pod 流量还不够？

入口流量可能先经过外部世界到 Ingress/Envoy，再由代理转发到后端，策略引擎会有不同的身份和检查点。只验证后端直连会遗漏入口路径。