企业灰度发布 07：深入 Istio 控制面、数据面与配置分发链路
Istio 经常被简化成“Envoy Sidecar + VirtualService”，这不足以解释生产故障。一次路由变更需要先被 Kubernetes API Server 接受，再由 istiod 观察和编译，之后通过 xDS 流式下发到目标代理，代理接受新快照后才会改变真实流量。任何一段出现选择器错误、配置冲突、推送延迟或代理拒绝，声明状态与实际状态都会分离。
企业灰度平台不能只读取 Git 中的 YAML。它必须知道期望配置是否已变成目标代理正在执行的配置。
istiod 是持续运行的配置编译器
早期 Istio 的 Pilot、Citadel、Galley 等职责后来整合进 istiod。从逻辑上看，它仍承担三类工作：服务发现与流量配置、安全身份与证书、配置校验和分发。它观察 Kubernetes Service、EndpointSlice、Pod、Gateway API 与 Istio CRD，将不同来源合并成代理需要的 listener、route、cluster、endpoint 与 secret 配置。
xDS 是一组动态发现协议的统称。控制面通常通过长期 gRPC 流增量推送，代理报告已接受或拒绝配置。一个 Kubernetes Deployment 更新可能改变 endpoint，一个 VirtualService 更新改变 route，一个授权策略改变 listener/filter chain；它们的影响范围和推送成本不同。
数据面怎样接管流量
Sidecar 模式下，代理与业务容器位于同一 Pod。初始化机制或 CNI 把入站、出站流量重定向到代理，应用通常无需改目标地址。代理根据本地配置决定服务发现、负载均衡、mTLS 和路由，再把流量送到目标工作负载的代理。
Ambient 模式把 L4 安全隧道放到每个节点的 ztunnel，需要 L7 路由和策略的工作负载再经过 waypoint。它改变的是代理部署拓扑，不改变“控制面声明、数据面本地执行”的基本关系。部署选型将在下一篇单独展开。
代理处于请求关键路径，因此资源声明必须基于测量。并发连接、TLS 握手、遥测、响应体大小和复杂匹配都会影响 CPU/内存。只按 Pod 数估算代理开销不可靠；平台应按每秒请求、连接数、协议和策略复杂度建立容量模型。
声明成功不代表配置生效
Kubernetes 接受一个 CRD，只证明 YAML 符合 API schema，不证明跨资源语义正确。例如 VirtualService 引用不存在的 subset，DestinationRule 的 label 选不到 Pod，Gateway 与 host 不匹配，资源仍可能创建成功。
发布准入要分四层：schema 校验、Istio 语义分析、目标代理分发状态、真实请求探测。istioctl analyze 能发现一部分冲突和引用错误；代理状态与配置 dump 能确认实际接收；合成请求才证明入口到应用的路径真的可用。
灰度控制器设置 10% 权重后，如果部分代理仍执行旧配置，实际流量会呈现分裂状态。平台不应立刻开始指标观察计时，而要先等待配置传播条件满足，再从流量指标验证 observed weight 与 desired weight 接近。
配置规模决定控制面压力
默认情况下，让每个代理都知道整个 Mesh 的所有服务，会带来内存与推送放大。服务、端点和代理数量增长后，一次全局配置变化可能触发广泛重算。大型 Mesh 应限制配置可见性与导出范围，让工作负载只接收需要的服务和策略。
控制面容量不仅由代理数量决定，还受配置变化率、端点抖动、多集群远端 watch 和配置作用域影响。压测应模拟真实 churn：HPA 扩缩容、批量发布、节点故障和证书轮换，而不是只让静态流量穿过代理。
控制面高可用怎样设计
istiod 可部署多副本并跨故障域分布，通过 PodDisruptionBudget、反亲和、合理资源和监控提高可用性。它不承载正常业务数据流，所以已有代理在短期控制面故障时通常继续服务；但新工作负载无法获得配置或证书、策略变更停滞，长时间故障会触及证书和服务发现的新鲜度。
关键指标包括 xDS 连接数、推送耗时、被拒配置、证书签发失败、代理同步状态、进程资源和 webhook 可用性。控制面升级要使用 revision 或 canary 策略，让一部分 namespace/代理先连接新版本，验证后再迁移，而不是原地替换整个控制面。
平台应暴露的诊断视图
| 视图 | 回答的问题 |
|---|---|
| 资源关系图 | Gateway、VirtualService、DestinationRule 引用是否完整 |
| 配置作用域 | 哪些代理应该收到这次变化 |
| 同步状态 | 目标代理 ACK/NACK 与版本是否一致 |
| 实际端点 | stable/canary subset 最终选中了哪些 Pod |
| 请求证据 | 合成探测经过了哪条路由、返回什么版本 |
| 变更审计 | 谁在何时改变了哪个字段，如何恢复 |
Istio 的强大来自声明与执行分离，也因此必须正视期望状态和实际状态之间的传播链。下一篇比较 Sidecar、Ambient、单/多集群以及控制面拓扑，给出灰度平台底座的实际部署决策。