【Istio 控制面】选型收束与开放问题：CRD、Gateway API 与 eBPF L4 的排除树
内容提要
本文是Istio控制面内核系列终章，提出选型排除树：先问是否需要独立于应用发布的L7策略、跨实现可移植路由或去sidecar，再选Istio CRD、Gateway API/GAMMA、Ambient或eBPF L4。强调各路径机制成本不同，xDS语义需承担推送/NACK调参，eBPF则用Map更新替代。GAMMA与CRD双轨并存，冲突规则待演进。开放问题包括推送SLO定义、Ambient优化缺口等，需实测验证。
延伸解读
选型先问不变量，再谈产品
文章提出的排除树强调，选型应首先明确是否需要独立于应用发布的L7策略、跨实现可移植路由或去sidecar，再决定采用Istio CRD、Gateway API/GAMMA、Ambient还是eBPF L4。这避免了仅凭印象选择，而是基于机制需求。例如，若只需L3/L4策略，可直接考虑eBPF方案，无需引入xDS链路。
xDS与eBPF：机制成本不同，无零成本选项
选择xDS语义（如Istio CRD或Gateway API）需承担推送、NACK调参等成本；而eBPF L4则用Map更新替代，但引入Identity模型等新机制。文章强调没有零成本选项，跨列比较（如功能丰富度与转发性能）容易掩盖本质差异，应先确定落在哪一列再比较。
GAMMA双轨并存，冲突规则待明确
GAMMA与Istio CRD目前双轨并存，两者都编译到同一套RDS/CDS，但混用时的冲突判定规则尚未明确，不能假设优先级关系显而易见。文章建议在GAMMA走向Standard过程中，关注权威源判定规则是否变化，并可能需要新增显式冲突检测层。
开放问题需实测验证，而非预测
文章列出三个开放问题：推送SLO定义、Ambient scoping优化缺口、GAMMA双轨冲突判定。这些问题均需通过实际测量（如pilot_total_xds_rejects分布、CPU差异、冲突发生率）来回答，而非依赖推测。文章明确不预测数字，强调用机制坐标去量。
Q&A
Istio 控制面选型时，应该先问哪些问题？
选型时应先问三个问题：是否需要独立于应用发布节奏变更的 L7 策略？是否需要跨实现可移植的路由 API？是否需要去掉 sidecar？根据这些问题的答案，再决定选择 Istio CRD、Gateway API/GAMMA、Ambient 还是 eBPF L4。
Istio CRD 和 Gateway API/GAMMA 在机制上有何异同？
两者最终都由 istiod 编译成同一套 RDS/CDS 资源，推送机制相同。区别在于配置源：Istio CRD 使用 VirtualService/DestinationRule，是 Istio 专属；Gateway API/GAMMA 使用标准化的 HTTPRoute/Gateway，跨实现可移植。目前双轨并存，冲突判定规则仍在演进。
eBPF L4 方案（如 Cilium）与 Istio 的 xDS 机制有何本质区别？
eBPF L4 方案完全不使用 xDS，而是通过 BPF Map 原子更新和基于数字 Identity 的策略来实现 L3/L4 转发与安全。Istio 则依赖 xDS 推送、ACK/NACK 和 warming 机制。因此，如果只需要 L4 身份与网络策略，eBPF 方案更直接，无需承担 xDS 的调参成本。
Ambient 模式与 eBPF L4 方案在机制上有什么不同？
Ambient 的 ztunnel 仍然是 xDS 客户端，订阅 Address/WorkloadAuthorization 等资源，而 eBPF CNI 完全不运行 xDS。Ambient 将纯 L4 场景从完整 xDS 资源树中剥离，但并未完全跳出 xDS 体系；eBPF L4 则完全独立于 xDS。
选择 Istio CRD 或 Gateway API 时，各自适用的典型场景是什么？
Istio CRD 适用于已有存量配置、团队只用 Istio、不需要跨实现可移植路由的场景。Gateway API/GAMMA 适用于需要在多个实现之间复用路由定义，或南北向已用 Gateway API 并希望统一心智模型的场景。
Istio 控制面系列提出了哪些开放问题？
开放问题包括：如何定义推送 SLO（配置已生效的端到端延迟）；Ambient 的 scoping 优化缺口何时补上；GAMMA 双轨配置（同一 Service 同时被 VirtualService 和 HTTPRoute 引用）的冲突判定规则是否会变化。这些问题需要后续实测验证。
