Istio 1.31 adds agentgateway waypoints in ambient mode, with a canary configuration fix included in 1.31.1. It also ends the publication of images and Helm charts to Google Cloud, requiring...

> 本文是写作规划，不是可发布正文。拆解对象：Istio 网格控制面内核——以 Istio 1.30.x（稳定线；源码与文档钉 1.30.3，2026-07-16 patch）为主线，把 CRD / Gateway API 资源如何经 istiod 编译成 LDS/RDS/CDS/EDS/SDS、再经 ADS 推给 s…

本文对比Linkerd 2.20与Istio xDS、Ambient及Cilium L4的机制差异，聚焦控制面协议、数据面引擎与排障坐标。Linkerd采用专用gRPC API与per-Pod代理，适合接受专用API的团队；Istio xDS适合存量CRD或多客户端场景；Ambient在xDS内去sidecar；Cilium适合仅需L3/L4。不比较性能，仅提供机制选型依据。

本文介绍Linkerd 2.20控制面与linkerd2-proxy间的四套gRPC API：destination、identity、inbound和tap。与istiod/xDS通用协议不同，Linkerd采用专用API，按目标服务名流式查询，错误处理基于gRPC状态码而非ACK/NACK。排障时需查destination.Get流，而非EDS快照。文章强调版本锚定v0.20.0，并对比了与Istio在组件拓扑、L7信息和身份路径上的差异。

本文对比Envoy Gateway与Cilium、Istio、Ingress注解等替代方案，聚焦翻译内核与排障坐标差异，而非性能。核心观点：各实现虽支持Gateway API，但控制面机制不同，如Cilium嵌入Envoy、Istio用istiod、Contour独立翻译器。选型需考虑团队隔离与观测链需求，避免硬套统一排障方法。

本文是“Istio/网格控制面内核”系列首篇，旨在填补Envoy消费侧与Mesh选型之间的缺口，聚焦istiod如何将CRD或Gateway API资源编译为xDS资源图并推送。文章梳理了xDS从协议到控制面产品的三次分叉，提出五条坐标系（资源来源、订阅身份、推送图、一致性、作用域），并明确系列16篇的边界与不涉及内容。

istiod 是集 discovery、config、CA、injection 于一体的单一二进制，但各组件独立运行。启动顺序有硬依赖：CA 先于证书，证书先于安全 gRPC 和 webhook。xDS 推送热路径仅含 pushChannel 和 Generator，CA 签发、注入等不在此列。多副本中 xDS 无主，但状态写回控制器需选主。

本文介绍Istio 1.30.3中四类xDS客户端（Sidecar、Router、Waypoint、Ztunnel）的身份与订阅机制。身份分两层：节点ID是自述，仅认证后的SPIFFE身份可信。订阅范围由类型URL决定，标准Envoy请求LDS/CDS等，Ztunnel请求自定义Address类型，两者生成器路径不相交。NodeType影响推送判定而非订阅权限。Ztunnel用Rust实现，资源占用更优，但需独立维护生成器。

本文详解Istio控制面一次配置变更如何转化为代理收到的DiscoveryResponse，梳理六阶段完整链路：事件汇入、debounce合并、全局重算、按代理排队、生成发送及代理确认。强调PushQueue合并机制、Full决定重算范围、VersionInfo统一生成，并指出xds.Send成功不等于Envoy已生效，排障需区分各阶段。

本文介绍Istio控制面中K8s Service、EndpointSlice和WorkloadEntry如何转换为Envoy的CDS/EDS资源。核心是服务注册聚合层将三种来源统一为model.Service和model.IstioEndpoint，CDS按“Service×端口”生成Cluster，EDS按hostname索引端点。两者通过service_name字符串对齐，WorkloadEntry需特殊开关接入，健康状态无kubelet兜底。

本文探讨Istio中VirtualService与Gateway API HTTPRoute两条配置路径如何汇合至同一RDS生成器。两者均编译为内部VirtualService对象，但合并规则不同：VirtualService跨资源顺序未定义，HTTPRoute有确定性优先级算法。双写同一host是生产风险，Istio计划以Gateway API为默认。

本文介绍Istio中DestinationRule如何配置Envoy Cluster：它不创建服务，仅对匹配的host追加配置；TrafficPolicy四组件（连接池、异常检测、负载均衡、TLS）按序映射到Cluster字段；subset只生成Cluster，需VirtualService配合路由；四层合并规则中，subset继承顶层，port级不继承而回落Envoy默认值；TLS模式管客户端出站，与PeerAuthentication对应。

本文介绍Istio控制面中PeerAuthentication和AuthorizationPolicy两种安全策略的翻译与分发机制。PeerAuthentication管理入站连接的mTLS要求，AuthorizationPolicy编译为RBAC过滤器。CUSTOM操作通过shadow RBAC评估和metadata门控调用外部授权服务。证书由istiod CA签发，经istio-agent本地SDS服务器分发给Envoy，身份匹配依赖mTLS对端证书中的SPIFFE身份。

本文介绍Istio中Sidecar、Telemetry、EnvoyFilter三种资源在配置生成流水线中的作用：Sidecar在生成前裁剪可见输入，Telemetry在生成中注入可观测配置，EnvoyFilter在生成后直接打补丁。三者各有合并规则，不能简单套用“更具体覆盖更宽泛”的直觉。重点强调Sidecar裁剪不等于流量阻断、Telemetry禁用继承不对称、EnvoyFilter按创建时间排序而非修改时间等易错点。

本文探讨Istio控制面生产侧推送机制：协议变体（SotW/Delta）与推送范围（Full/Incremental）是正交轴，由`req.Full`决定是否重算全局状态。debounce合并K8s watch事件，减少端点抖动压力，但默认日志级别隐藏增量推送，易低估推送频率。

本文分析Istio控制面istiod对Envoy NACK的处理机制：istiod仅记录错误并计数，不重试或回滚；通过PushOrder常量实现CDS→EDS→LDS→RDS的推送顺序，但只保证同批发送顺序；istiod可观测性止步于协议层，warming等Envoy内部状态无法感知，排障需结合控制面与数据面信号。

本文介绍Istio多集群控制面机制：istiod通过remote secret跨集群watch多个API Server，自动聚合服务发现端点，但配置分发需外部工具保证一致性。输出端采用Split-Horizon EDS，按网络重写端点，跨网络端点替换为东西向网关地址，Envoy无感知。网络标签决定重写，Locality仅影响优先级。网关健康由数据面兜底，多primary配置漂移无检测机制。

本文探讨Istio Ambient模式下控制面istiod如何区分并服务ztunnel与waypoint两类代理。ztunnel按节点部署，仅处理L4，订阅地址与授权资源；waypoint是标准Envoy，按挂载关系订阅资源。当前ambient代理跳过sidecar的作用域过滤优化，源码留有TODO，是大规模部署的已知差距。

Linkerd控制面与Istio不同，不实现xDS，而是拆分为destination、identity、proxy-injector三个独立组件。其API为linkerd2-proxy定制，按目标服务名查询，身份签发走专用CSR接口。Istio合并进istiod单进程，用通用xDS协议。两者是不同工程取舍，无优劣之分。