企业灰度发布 08：Istio 应该怎样部署——Sidecar、Ambient 与多集群决策
“新项目直接 Ambient”与“生产必须 Sidecar”都是过度简化。Istio 数据面怎样部署，会改变资源模型、故障域、L7 策略路径、升级方式和多集群能力；而灰度平台依赖精确 L7 路由，更必须知道流量究竟经过哪种代理。
截至本文撰写时，Istio 最新文档版本为 1.30.3。Sidecar 仍是成熟、功能完整且多集群经验最丰富的路径；Ambient 已经适合单集群生产，跨网络多集群在 1.29 起进入 Beta，但仍有多主控制面、waypoint 命名、服务作用域和远端流量分布等限制。选型必须绑定版本和已验证能力，不能把路线图当现状。
Sidecar：每个工作负载拥有完整 L4/L7 代理
Sidecar 模式在每个 Pod 内放置 Envoy。优点是所有工作负载都能就地执行完整 L7 路由、授权和遥测，模型成熟，调试资料丰富，也支持 VM 和成熟多集群拓扑。对于依赖复杂 EnvoyFilter、细粒度每工作负载 L7 行为或既有大规模生产体系的团队，它仍是稳健选择。
代价是资源随 Pod 数增长。一个节点上 100 个业务 Pod 就有约 100 个 Sidecar；应用和代理生命周期耦合，注入模板或代理版本变化通常需要重启工作负载；端口重定向、启动顺序和资源限制也进入每个 Pod 的故障面。
Ambient：把 L4 与 L7 拆成两层
Ambient 的基础层是每节点 ztunnel，负责 L4 连接、身份与 mTLS；需要 HTTP 路由、L7 授权和丰富遥测的服务，再选择 waypoint Envoy，通常按 namespace 或服务共享。它让“加入安全 Mesh”和“使用完整 L7”不再是同一个开关。
如果只需要 mTLS 和 L4 身份，Ambient 可避免给每个 Pod 配置完整 L7 代理；需要灰度路由的目标服务则必须确认请求会经过 waypoint。入口 Gateway 默认是否经过 waypoint、调用方向的 waypoint 归属和策略绑定都要在架构中明确，不能看到 namespace 已加入 Ambient 就假设 VirtualService 一定执行。
Ambient 与 Sidecar 可以渐进共存，但迁移并非所有场景零风险。官方当前迁移说明指出，涉及 L7 策略时存在切换窗口；Sidecar 工作负载调用带 waypoint 的 Ambient 工作负载也有绕过 waypoint 的限制；EnvoyFilter 等扩展能力还需逐项检查。因此迁移应按 namespace 建立兼容矩阵，并为关键 L7 授权安排维护或双重验证。
单集群先决定网络与故障域
生产安装至少要分离 ingress gateway、控制面和业务节点的容量，控制面多副本跨可用区，Gateway 使用独立 HPA/PDB 和连接排空。不要把所有组件塞在 istio-system 后就认为边界完成；应根据团队和安全域划分 Gateway、waypoint、证书信任与配置所有权。
控制面升级推荐 revision/canary。安装新 revision，让一小部分非关键 namespace 或 waypoint/Sidecar 先连接，验证配置同步、延迟和协议，再迁移其余工作负载。数据面升级本身也是一次发布，必须有回退到旧 revision 的路径。
多集群要先回答“一个 Mesh 还是多个 Mesh”
多集群不等于必须跨集群服务发现。两个集群可以保持独立 Mesh，由全局负载均衡在南北向切流；也可以组成一个 Mesh，共享信任与服务发现，通过 east-west gateway 传递东西向流量。前者隔离强、故障域清晰，后者服务迁移和跨集群容灾更透明，但控制面和网络复杂度更高。
还要区分 single-network 与 multi-network。Pod IP 可直接路由时可视为同一网络；地址重叠或不可直达时需要 east-west gateway。多主控制面让每个集群拥有本地 istiod，减少控制面跨集群依赖；primary-remote 则由主集群控制面服务远端集群。当前 Ambient 多集群只支持 multiple-primary，不能照搬 Sidecar 的 primary-remote 方案。
灰度平台的推荐部署基线
对于新建单集群、以标准 HTTP/gRPC 为主、希望先获得 mTLS 再按需启用 L7 的平台，可以优先验证 Ambient，并为所有需要灰度的服务显式配置 waypoint 与端到端路由测试。对于已有成熟 Sidecar、强依赖 Envoy 扩展、VM 或复杂多集群的企业，不应为了“新”强迁，先用 revision 升级和资源治理改善现状。
对于跨集群灰度，第一阶段更建议每集群独立执行 Rollout，由上层平台协调批次：先集群 A 小流量，验证后再集群 B。不要一开始就让一个权重同时跨多个网络分配，否则远端负载不均、网络故障和版本回归会混在同一指标里。
| 条件 | 优先考虑 |
|---|---|
| 新单集群、标准协议、L4 安全为主 | Ambient + 按需 waypoint |
| 复杂 L7/Envoy 扩展、VM | Sidecar |
| 成熟 Sidecar 生产体系 | 保持并用 revision 渐进升级 |
| 多集群强隔离 | 多 Mesh + 上层流量协调 |
| 共享服务发现与东西向容灾 | 多主 Mesh，先验证网络与限制 |
部署验收不能只跑 Bookinfo
真正验收要覆盖：峰值连接和请求、证书轮换、istiod 故障、新 Pod 启动、Gateway 排空、配置 NACK、跨区延迟、节点升级、HPA 扩缩、双栈或重叠地址，以及 Sidecar/Ambient 共存路径。灰度发布还要额外验证 stable/canary 身份、waypoint 路径和 observed weight。
下一篇进入 Istio 流量对象：Gateway、VirtualService、DestinationRule 怎样协作完成百分比、Header、会话和镜像路由，以及最容易出现的配置陷阱。