第 10 到 15 篇把控制面内核钉成了可核对的机制：生产侧推送范围、NACK 责任、多集群扇出、Ambient 双客户端、Linkerd 对照、排障五轴。选型如果还是回到”Istio 功能全但重，Gateway API 是未来，eBPF 快”这种没有机制依据的印象，等于把前面十几篇的工作丢掉。本文用机制排除树收束：先问不变量，再决定该用哪一层做翻译，以及什么时候该完全跳出 xDS 语义。
不做产品评选，不编造跨方案延迟排行榜；对照细节外链站内已有篇章。
本文是「Istio 控制面内核」系列第 16 篇（共 16 篇 · 终章）。→ 系列目录
版本锚定：Istio 1.30.3；Gateway API/GAMMA 对照见站内 k8s-network/18；数据面机制回指 Envoy v1.39.0 系列 §5.1/5.2。
一、先排除，再选择
flowchart TD
need{"Need L7 policy that changes<br/>independent of app deploy?"}
need -->|"no"| l4only{"Need only L3/L4<br/>identity + policy?"}
l4only -->|"yes"| ebpf["eBPF L4<br/>(e.g. Cilium, no xDS)"]
l4only -->|"no, need HTTP semantics"| minimal["Minimal reverse proxy<br/>+ file/reload path"]
need -->|"yes"| api{"Who authors the routing API:<br/>mesh CRD or Gateway API?"}
api -->|"existing VS/DR investment,<br/>single-vendor mesh"| istiocrd["Istio CRD -> istiod translation<br/>(this series 05-09)"]
api -->|"portable, multi-implementation,<br/>north-south + GAMMA mesh"| gwapi["Gateway API / HTTPRoute<br/>(k8s-network/18)"]
istiocrd --> ambientq{"Need sidecar-free<br/>L4 baseline + selective L7?"}
gwapi --> ambientq
ambientq -->|"yes"| ambient["Ambient: ztunnel + waypoint<br/>(series 13)"]
ambientq -->|"no"| sidecar["Sidecar Envoy<br/>(per-workload xDS client)"]| 问题 | 若答案为”否” | 倾向 |
|---|---|---|
| 需要独立于应用发布节奏变更的 L7 策略？ | 应用内部处理或简单反代即可 | 不需要 istiod 翻译层 |
| 只需要 L3/L4 身份与网络策略？ | 不需要理解 HTTP 语义 | eBPF L4（如 Cilium，无需 xDS，见 k8s-network/13） |
| 路由 API 需要跨实现可移植？ | 单一网格闭环即可接受 | Istio CRD（VirtualService/DestinationRule）足够 |
| 需要南北向与东西向统一到同一套 HTTPRoute？ | 只做南北向或只做 mesh 内部 | Gateway API / GAMMA（k8s-network/18） |
| 需要砍掉 per-Pod sidecar 但保留选择性 L7？ | 全量 L7 策略、sidecar 税可接受 | Ambient（本系列第 13 篇） |
排除树要诚实面对一个前提：这棵树的每一个”选 Istio”分支，背后都是本系列 10–15 篇讨论的推送/NACK/warming/排障机制——选了 xDS 语义，就要承担第 10、11 篇的调参与责任划分成本；选了 eBPF L4，这些成本换成了《k8s-network/13》里另一套机制（Map 更新、Identity 模型）的成本，不是”没有成本”。
二、Istio CRD vs Gateway API：翻译层的两条输入
系列第
6 篇已经讲了 VirtualService/HTTPRoute 翻译到 RDS
的冲突边界，这里只给选型层面的机制结论。GAMMA（Gateway API
for Mesh Management and Administration）把 Gateway API
的资源模型从南北向扩展到东西向：HTTPRoute 的
parentRef 可以指向一个
Service，表达”如何路由到这个 Service 的流量”，这与传统的
VirtualService + DestinationRule
组合是两条平行的配置输入，最终都要被 istiod
编译成同一套 RDS/CDS
资源——机制上没有第二套推送体系，只是翻译的源头 CRD
不同。
选型判断句：
- 继续用 VirtualService/DestinationRule：已有存量配置、团队只用 Istio、不需要把路由规则暴露成跨网格厂商可移植的标准。
- 迁移到 HTTPRoute/GAMMA：需要在多个实现（不仅 Istio）之间复用同一份路由定义，或者南北向已经在用 Gateway API、想统一到一套心智模型。截至 GAMMA 进入 Experimental channel 阶段，官方与社区文档显示 Istio 对 GAMMA 的支持最完整（Service parentRef、流量分割、Header 路由），但这仍是一个双轨并存的阶段——两条输入都能产生有效配置，混用时的冲突判定规则需要额外确认，不能假设两者优先级关系是”显而易见”的。
三、eBPF L4：完全跳出 xDS 语义的选项
《k8s-network/13》已经详细拆解过 Cilium 的 eBPF 数据面：Service 查找是 O(1) Map 查找，安全策略基于数字 Identity 而非 IP，完全不经过 Envoy 的 Filter Chain。这与本系列所有机制（xDS 资源类型、ACK/NACK、warming）没有交集——如果需求止步于 L3/L4 网络策略，eBPF 方案不需要理解本系列任何一篇的内容，因为它压根不跑 xDS。
排除提示（呼应 Envoy 第 16 篇的排除树）：只要 L4 身份与路径就够，优先问 eBPF/CNI，而不是先把 Istio CRD 翻译链路和推送机制铺开再发现用不上其中的 L7 能力。Ambient 的 ztunnel（第 13 篇）某种程度上是 Istio 生态对这个判断的回应——把纯 L4 场景从”必须经过完整 xDS 资源树”里剥离出来，但 ztunnel 仍然是 xDS 客户端（订阅 Address/WorkloadAuthorization），与完全不跑 xDS 的 eBPF CNI 不是同一件事，边界不要混淆。
四、三条路径的机制对照（非产品评分）
| 维度 | Istio CRD → istiod | Gateway API / GAMMA → istiod | eBPF L4（如 Cilium） |
|---|---|---|---|
| 配置一等公民 | VirtualService/DestinationRule 等 mesh 专属 CRD | 标准化的 HTTPRoute/Gateway，跨实现可移植 | CiliumNetworkPolicy 等，L3/L4 语义 |
| 是否经过 xDS | 是，编译为 RDS/CDS/EDS | 是，编译为同一套 RDS/CDS/EDS（第二部分翻译层内容） | 否，不生成 xDS 资源 |
| 推送/ACK/warming 机制是否适用 | 适用（本系列 10、11 篇） | 适用（翻译源不同，推送机制相同） | 不适用，用 BPF Map 原子更新替代 |
| 跨实现可移植性 | 低（Istio 专属字段） | 高（Gateway API 是 K8s SIG-Network 标准） | 不涉及路由可移植性问题，本身是网络层 |
| 典型适用场景 | 存量 Istio 部署、需要 Istio 特有字段（如细粒度 outlier detection） | 多实现环境、南北向东西向统一心智模型 | 纯 L3/L4 策略、kube-proxy 替代、不需要 HTTP 语义 |
这张表要配合前三节读：前两列的机制成本几乎相同（都要过 xDS 推送/ACK/warming），差别主要在配置的可移植性；第三列是完全不同的机制体系，不存在”选哪个 xDS 变体”的问题，因为压根不用 xDS。选型时先确定落在哪一列，再在列内比较，跨列比较（例如直接拿 Istio CRD 的功能丰富度和 eBPF 的转发性能做加权打分）容易掩盖两者本来就不是同一层的问题这一事实。
五、系列阅读路径回收
| 路径 | 篇目 | 收回什么 |
|---|---|---|
| 推送与失败 | 10 → 11 → 15 | debounce、NACK 责任、排障五轴 |
| 规模与拓扑 | 10 → 12 → 13 | 端点抖动、多集群扇出、Ambient 双客户端 |
| 对照与边界 | 13 → 14 → 16 | Ambient、Linkerd 非 xDS 对照、选型排除树 |
| 完整通读 | 1 → … → 16 | 坐标、翻译、规模、Ambient、对照、排障到选型的完整链路 |
10–16 篇在系列里承接第一部分（坐标与推送图，1–4）与第二部分（翻译层，5–9）：istiod 的推送范围决策（10）→ NACK 与顺序责任（11）→ 多集群把输入端复杂度扩大（12）→ Ambient 把客户端类型复杂度扩大（13）→ Linkerd 证明这套复杂度不是唯一解（14）→ 排障要把所有机制串成五轴核对（15）→ 选型要先问不变量而不是先选产品（16）。
六、系列级开放问题
5.1 推送 SLO：如何定义”配置已生效”
回指 Envoy 第
16 篇 §5.1 与本系列第 10、11、15
篇：pilot_total_xds_rejects、proxy-status
同步状态、Envoy warming/ACK
信号目前分散在不同工具里，没有统一关联键。一个可检验的子问题：能否在不引入额外一致性协议的前提下，把”从配置变更提交到某个具体代理真正按新配置服务”的端到端延迟，定义成一个可采样、可跨版本比较的分布——而不是只统计”istiod
已发送”这个更容易测量但语义更弱的指标。
5.2 Ambient 成熟度：scoping 优化的缺口何时补上
第 13
篇钉住的是一个源码级事实，不是印象：DefaultProxyNeedsPush
对 waypoint/ztunnel/agentgateway 显式跳过了 sidecar
已有的作用域过滤优化，注释写着
TODO: implement ambient aware scoping。开放问题是这个优化补上后，大规模集群下
ambient 推送开销与同规模 sidecar
部署的差距会缩小多少——这需要该优化落地后的真实基准，本篇不预测数字。
5.3 GAMMA 双轨：Istio CRD 与 HTTPRoute 长期共存的冲突判定
系列第
6 篇已经具体拆过 VirtualService 与 HTTPRoute
的冲突规则；系列级的开放问题是：GAMMA 从 Experimental 走向
Standard 的过程中，双轨配置（同一 Service 同时被
VirtualService 和 HTTPRoute
引用）的权威源判定规则是否会变化，现有基于两条输入分别翻译到同一套
RDS/CDS
的机制是否需要为”冲突检测”新增一层显式校验，而不是依赖
istioctl analyze 事后发现。
一个必须重复的立场：这些问题不要求本篇”拍板”。它们要求后续文章或事故复盘带着本系列建立的机制坐标回去量——量的是
pilot_total_xds_rejects 分布、ambient scoping
优化前后的 CPU 差异、GAMMA
双轨冲突的实际发生率——而不是重新写一张没有口径的选型排行榜。
七、参考资料
规范 / 官方文档（A）
- Istio 1.30 官方文档：Ambient overview、Multicluster、GAMMA 相关章节。
- Gateway API
规范（
gateway-api.sigs.k8s.io），GAMMA 子项目说明。
站内对照
- 系列目录
- 系列第 11 篇 · NACK / Warming 责任
- 系列第 13 篇 · Ambient：ztunnel / waypoint
- Envoy 第 16 篇 · 选型收束
- k8s-network/18 · Gateway API
- k8s-network/13 · Cilium 深度拆解
- architecture/76 · Service Mesh
实验台账
- 本篇无跨方案 benchmark；选型依据为机制排除，非跑分；开放问题章节明确标注哪些数字尚未实测。
八、小结
- 用排除树选型：先问是否需要独立于应用发布的 L7 策略、是否需要跨实现可移植路由、是否需要砍掉 sidecar，再决定落在 Istio CRD、Gateway API/GAMMA、Ambient 还是 eBPF L4。
- 每个分支都有对应的机制成本：选 xDS 语义就要承担第 10、11 篇的调参与责任划分；选 eBPF 就要承担 Cilium 那套 Identity/Map 机制的成本；没有零成本选项。
- GAMMA 与 Istio CRD 目前双轨并存，翻译到同一套 RDS/CDS，但冲突判定规则仍在演进,不能假设两者优先级关系天然清晰。
- 系列收束：推送范围 → NACK 责任 → 多集群扇出 → Ambient 双客户端 → Linkerd 对照 → 排障五轴 → 本篇选型排除树。
- 开放问题留给后续验证：推送 SLO 定义、Ambient scoping 优化缺口、GAMMA 双轨冲突判定——都是可检验的具体问题，不是”以后会更好”式的收尾。
同主题继续阅读
把当前热点继续串成多页阅读，而不是停在单篇消费。
【Istio 控制面】VirtualService / mesh HTTPRoute → RDS：两条编译路径，一份路由表
拆解 istiod 的 RdsGenerator 如何把 VirtualService 与 Gateway API HTTPRoute（含 GAMMA mesh 模式）都编译成同一份内部路由模型，说明为何双轨输入会在同一 host 上产生冲突，以及两套 API 的合并顺序为何一个确定、一个未定义。
Istio / 网格控制面内核：从 CRD 到 xDS
补齐 Envoy 数据面 xDS 消费侧与 Mesh 选型叙事之间的控制面内核：istiod 推送图、CRD/HTTPRoute 翻译、Ambient 多客户端、NACK/warming 责任与排障对齐。
【Istio 控制面】控制面全景：从 CRD 到 xDS 的翻译与推送内核
定位 Istio 控制面内核相对 Envoy 消费侧、Service Mesh 税文与 Gateway API 资源模型的缺口；给出五条坐标系、16 篇地图与本系列明确不写的范围，钉住 istiod 1.30.3 为主线。
【Istio 控制面】代理身份与订阅：sidecar、ztunnel、waypoint、Gateway 谁在订阅什么
拆解 istiod 如何从节点 ID 与 mTLS/JWT 得到一个 model.Proxy 身份，以及 NodeType 如何决定该连接会订阅哪一套 xDS 资源类型：sidecar/Router 走标准 LDS/RDS/CDS/EDS，ztunnel 走自定义 Address/Authorization，waypoint 是 Envoy 但推送触发条件不同。