Cilium 1.21.0-pre.0 解读：delta-split xDS 让网络策略走增量同步

在 Kubernetes 集群里用 Cilium 做 L7 网络策略的人，多半遇到过这样的现象：策略越多、Endpoint 越多，每一次 kubectl apply 一个 CiliumNetworkPolicy 之后，节点上 cilium-agent 内嵌的 Envoy 都要"抖一下"。根因之一是 Cilium 向 Envoy 下发配置走的 xDS 通道：在 1.21 之前，网络策略相关资源默认以 State-of-the-World（SOTW，全量）方式推送，每次变更都要把当前全量策略重新喂一遍给 Envoy。策略规模一大，CPU 抖动和策略生效延迟都会被放大。

2026 年 8 月 3 日发布的 Cilium v1.21.0-pre.0 预发布版里，出现了一条值得注意的主特性（Major Change）：Envoy 资源（Listeners、Network Policies 等）现在可以增量同步，并通过新选项 –envoy-xds-mode=delta-split（Helm 值 envoy.xdsMode=delta-split）开启。本文基于该版本的官方发布说明与对应的 GitHub PR，拆解 delta-split xDS 到底改了什么、怎么开、以及它目前还不是"生产默认"的几个诚实限制。

范围与证据

本文所有结论均可追溯到以下公开来源，写作时核对日期为 2026-08-05：

• Cilium v1.21.0-pre.0 发布说明与 Release 页面（GitHub）。
• 实现 delta-split xDS 的 PR #45288 及其 GitHub API 元数据（合并状态、合并时间、合并 commit）。
• Cilium 仓库主页 API 返回的项目元信息（描述、语言、许可证）。

需要先说清楚一件事：v1.21.0-pre.0 是 预发布版（Pre-release），不是稳定版；delta-split xDS 在该版本中是 opt-in（需显式开启） 的能力，并未成为默认。我没有在本地跑基准测试，文中不会出现"快了 X%""CPU 降了 Y%"这类没有证据支撑的数字。涉及性能收益的描述，均会标注为 PR 作者的目标性陈述而非实测值。

说明：GitHub 仓库的 star 数等动态统计在本文写作时通过 API 读取到的快照与 releases 时间线不一致（疑似代理缓存），为避免写入不可核实的数据，本文与配图均不引用 star 数。

一条事实表先立在这里

SOTW vs delta-split：先把概念说清楚

Envoy 的 xDS 协议有两类推送方式：SOTW（State-of-the-World，全量）和 Incremental（增量）。SOTW 每次把"当前世界的完整状态"整体发给 Envoy；Incremental 只发送"本次新增/更新/删除"的差异。Cilium 在 cilium-agent 内运行了一个 xDS server，把 CiliumNetworkPolicy 等资源翻译成 Envoy 能消费的 xDS 资源，再推送给同 Pod 内的 Envoy。

PR #45288 的描述把 delta-split 做的事讲得很直接：把 selectors 与 policies 分开同步，并对 selectors 和 Network Policies（即 NetworkPolicyResources）实现 Delta xDS 更新，从而使一次增量策略更新只包含新增/更新/删除的 selectors，"should be much faster than a full State-of-the-World policy update"。

注意这句"much faster"是 PR 作者的目标性陈述，不是本文的实测结论。可以确定的、有证据支撑的事实只有两点：第一，delta-split 把推送模型从全量改成了增量；第二，它把 selectors 与 policies 拆成了两条独立的同步通道（这正是 "split" 的含义）。

图 1：SOTW 与 delta-split 两种 xDS 推送模型的数据流对比（概念示意图，不代表实测数据）。左图为 1.21 之前的全量推送：每次策略变更都把全量策略重发给 Envoy；右图为 delta-split：selectors 与 policies 拆分，仅推送差异。

在 1.21.0-pre.0 里 delta-split 长什么样

落到可配置的形态上，发布说明给出了两个对等的开关：

• cilium-agent 命令行选项：–envoy-xds-mode=delta-split
• Helm 值：envoy.xdsMode=delta-split

也就是说，如果你已经在用 Cilium 的 Helm Chart，升级到 1.21.0-pre.0 后，只需在 values 里加一行即可在测试集群里开启该模式。一个最小化的 values 片段如下：

# values.yaml（仅 delta-split 相关字段，其余沿用默认）
envoy:
enabled: true # 1.21 默认仍以 L4 为主，L7/Envoy 需显式启用
xdsMode: delta-split # 1.21.0-pre.0 新增；不设置则沿用旧行为

对应的安装/升级命令：

# 拉取 1.21.0-pre.0 的 Helm Chart 并启用 delta-split
helm upgrade –install cilium cilium/cilium \\
–version 1.21.0-pre.0 \\
–namespace kube-system \\
-f values.yaml

安装完成后，确认 agent 实际生效的选项值（这一步用于自检，不依赖任何外部指标）：

# 查看 cilium-agent 启动参数，确认 envoy-xds-mode 已生效
kubectl -n kube-system get pods -l app.kubernetes.io/name=cilium-agent \\
-o name | head -n1 | xargs -I{} kubectl -n kube-system exec {} — \\
cilium-agent –help | grep -A1 envoy-xds-mode

# 或者直接看 agent 进程的运行参数
kubectl -n kube-system get pods -l app.kubernetes.io/name=cilium-agent -o name \\
| head -n1 | xargs -I{} kubectl -n kube-system exec {} — \\
sh -c 'cat /proc/1/cmdline | tr "\\0" " " | grep -o — "–envoy-xds-mode=[^ ]*"'

需要强调：xdsMode 只在启用了 Envoy（L7 能力）的前提下才有意义。如果你的集群只用 Cilium 做 L3/L4 网络，没有开 L7 策略，delta-split 不会带来可感知的变化。

一次策略变更，推送内容有什么不同

这是理解 delta-split 价值的关键。假设你只新增了一条 CiliumNetworkPolicy 规则：

• 旧行为（SOTW）：cilium-agent 重新计算当前全量策略集合，把所有 Listeners、所有 NetworkPolicy 资源整体重新下发一遍给 Envoy。策略越多，单次变更的推送体积越大，与"本次到底改了什么"无关。
• delta-split 行为：cilium-agent 只把本次"新增/更新/删除"的 selectors 和受影响的 NetworkPolicy 资源作为差异下发。推送体积与"本次变更量"成正比，而不是与"全量策略规模"成正比。

这对策略规模大、变更频繁的集群（例如多租户、CI 环境频繁 apply 策略）意义更明显。但再次提醒：这只是模型层面的分析，具体收益取决于你集群的策略规模与变更频率，需要自行实测。

图 2：delta-split xDS 从 PR 到预发布的关键时间线。三个节点均来自公开来源：PR #45288 于 2026-04-10 开启（初始标题 "Envoy: Delta NPDS PoC"，状态 Draft）；同 PR 于 2026-07-14 合并（标题已更新为 "Envoy: Implement Delta xDS"，merge_commit edcb780）；v1.21.0-pre.0 于 2026-08-03 发布。本图数据另存于 data/release-timeline.json。

1.21.0-pre.0 里其他值得留意的变化

除了 delta-split，这个预发布版还有几条与运维直接相关的变更，均来自发布说明：

• 弃用 WireGuard 节点加密（PR #47219，Minor Changes）。如果你在用 WireGuard Node Encryption，需要提前规划迁移路径，后续版本会进一步移除。
• iptables 从 1.8.8 升到 1.8.11（PR #47623）。属于构建依赖升级，对运行时行为通常无感，但升级时若遇到 iptables 相关的兼容性问题可以对照这条排查。
• clustermesh 静态 IP 变更不再重启 Pod（PR #47190）。当远端 clustermesh-apiserver 的 IP 以静态方式（不带 DNS 名）变更时，不再触发 Pod 重启，对多集群运维是减少抖动的小改进。
• CT map 自适应 GC 间隔计算改进（PR #46796）。影响连接跟踪表的垃圾回收节奏，属内部优化。
• 新增 agent 侧 baseline network driver 与 dummy device manager（PR #47254，Major Changes）。这是为后续网络驱动扩展打地基的内部基础设施，普通用户暂无直接可观测行为。
• Bugfix：envoy 恢复 http-idle-timeout 作为 route idle timeout 的来源（PR #47583）。如果你踩过 L7 超时配置不生效的问题，这条值得关注。

完整变更列表请以官方 Release 页面为准，本文只挑了与运维相关性较高的几条。

限制与诚实说明

• 预发布版，不要用于生产。v1.21.0-pre.0 明确标注为 Pre-release，特性集合在正式 1.21 版本前仍可能调整。
• delta-split 是 opt-in 预览能力，非默认。开启前请在测试环境验证；它是否进入 1.21 稳定版的默认行为，以官方最终发布说明为准。
• 不提供性能基准。本文没有跑 benchmark，"reducing CPU load and policy update latency" 是发布说明与 PR 作者的目标性陈述，不是本文实测。如果你需要量化收益，应在你自己的集群、你自己的策略规模下实测。
• 依赖上游 Envoy。PR 早期描述中提到该特性与 Envoy 的开发构建相关，delta-split 的最终行为依赖 Cilium 所打包的 Envoy 版本，升级时请一并核对 cilium-envoy 镜像版本。
• 命令以 Linux shell 为准。文中 kubectl … | xargs 命令在 Linux/macOS 直接可用；Windows 下请在 WSL 或 Git Bash 中执行，PowerShell 的管道语义不同。

结论与项目链接

v1.21.0-pre.0 最值得关注的是把 Envoy xDS 从"全量推送"推向"增量同步"的 delta-split 模式，它把网络策略的同步粒度从"整个世界"细化到了"本次差异"。对策略规模大、变更频繁的集群，这是一个方向性的改进；但它是预发布、opt-in、未默认启用，离生产可用还有距离，具体收益需自行实测。如果你的集群在用 Cilium 的 L7 能力且策略量较大，值得在测试环境用 envoy.xdsMode=delta-split 开起来观察行为，并跟踪 1.21 稳定版的后续说明。

项目地址：https://github.com/cilium/cilium ，

本次发布页面：https://github.com/cilium/cilium/releases/tag/v1.21.0-pre.0 ，

核心实现 PR：https://github.com/cilium/cilium/pull/45288 。