【Istio 控制面】生产侧 SotW 与 Delta：debounce、全量推与端点抖动
内容提要
本文探讨Istio控制面生产侧推送机制：协议变体（SotW/Delta）与推送范围（Full/Incremental）是正交轴，由`req.Full`决定是否重算全局状态。debounce合并K8s watch事件，减少端点抖动压力，但默认日志级别隐藏增量推送，易低估推送频率。
延伸解读
协议与推送范围：两根正交轴
文章强调，SotW/Delta 是客户端选择的传输协议，而 Full/Incremental 是 istiod 根据 req.Full 判断是否重算全局状态。即使客户端使用 Delta 协议，若生成器不支持 GenerateDeltas，istiod 仍会全量生成再做差集，模拟 Delta 语义。因此，生产环境需同时关注这两根轴，避免误以为 Delta 协议必然带来增量推送。
日志分级：增量推送的可见性盲区
默认日志级别下，非 Full 推送仅记录 Debug 日志，而 Full 推送记录 Info 日志。这意味着端点抖动时大量 EDS 增量推送在 Info 日志中不可见，运维可能低估推送频率。这是设计取舍，但排障时需开启 Debug 日志或关注 'XDS: Pushing Services' 等 Full 信号，以准确判断控制面活动。
debounce 与端点抖动：合并与过滤的双层缓解
debounce 机制通过 DebounceAfter、debounceMax 和 enableEDSDebounce 参数合并 K8s watch 事件，减少推送次数。关闭 EDS debounce 可降低延迟但增加推送压力。推送时 ProxyNeedsPush 过滤不关心变更的代理，避免全网无差别推送。这两层机制共同缓解端点抖动，但需权衡收敛延迟与控制面负载。
Q&A
Istio 控制面中，SotW/Delta 协议变体与 Full/Incremental 推送范围是什么关系？
它们是两根正交的轴。SotW/Delta 是客户端选择的 gRPC 方法（StreamAggregatedResources 或 DeltaAggregatedResources），而 Full/Incremental 由 istiod 根据 model.PushRequest.Full 字段决定是否重算全局状态。即使客户端使用 Delta 协议，如果生成器不支持 GenerateDeltas，istiod 仍会全量生成再做差集模拟 Delta 语义。
Istio 中哪些情况会触发 Full 推送（req.Full=true）？
三类触发源：1) 代理主动请求，如首次连接或重连；2) 调试接口全量重推（AdsPushAll 手动触发）；3) 单实例定向刷新（如 xds proxy 请求，ProxyUpdate 构造 Full: true, Forced: true）。
Istio 的 debounce 机制是如何工作的？有哪些参数控制？
debounce 机制合并 K8s watch 事件，减少推送次数。它由 DebounceAfter（静默期）、debounceMax（强制上限）和 enableEDSDebounce 三个参数控制。每来一个事件重置 DebounceAfter 计时器，若事件持续到达且未超过 debounceMax，则推迟推送并合并事件。若 enableEDSDebounce 为 false，纯端点更新会跳过合并窗口立即触发。
Istio 控制面如何缓解端点抖动带来的压力？
分两层：1) debounce 层：合并短时间内多次端点变化为一次 PushRequest；2) push 层：通过 ProxyNeedsPush 过滤不关心变更的代理，只向相关代理推送，避免全网无差别推送。
为什么默认日志级别下难以观察到 Istio 的增量推送？
因为非 Full 推送（req.Full=false）在 pushXds 中只打 Debug 日志，而 Full 推送才打 Info 日志。默认日志级别为 Info，所以增量推送几乎不可见，容易让运维低估真实推送频率。这是设计取舍，不是故障。
如何从 Istio 日志判断一次推送是 Full 还是 Incremental？
Full 推送会打印 'XDS: Pushing Services:%d' 日志，包含 Service 总数；Incremental 推送打印 'XDS: Incremental Pushing' 日志，没有 Service 计数。此外，debounce 日志中的 full=%v 字段直接指示本次推送是否为全量。
