Envoy

背景与问题界定 某互联网公司的 Istio 服务网格从 2022 年开始大规模落地，管理着 1500+ 个服务实例的通信。随着规模增长，运维团队逐渐发现了 Sidecar 模式的系统性痛点：每个 Pod 中增加的 Envoy 代理占用了 70MB 内存和 0.3 核 CPU，全集群 Sidecar 的总资源消耗相当于额外支付了 15% 的基础设施成本；Envoy 的启动顺序问题导致 Pod Ready 延迟从 5 秒增加到 15 秒（需要等待 Envoy Warm-up）；更严重的是，Istio 1.16 控制面 Pilot 在推送 30000+ XDS 端点时出现了周期性 CPU 飙升导致配置下发延迟超过 30 秒。2022 年 9 月 Istio 宣布了 Ambient Mesh 模式——一种移除 Sidecar 的服务网格新架构，通过 ztunnel（零信任隧道代理）在节点级别实现 L4 和 L7 的流量管理。 目标拆解与工程约束 消除 Sidecar 资源开销：Ambient 模式的目标是将服务网格的代理资源开销从"每个 Pod 一份"降低到"每个节点一份"，期望将整体的基础设施额外成本从 15% 降低到 3% 以下。 无侵入的应用容器升级：应用无需要更容器启动逻辑或 Pod spec 的配置——Ambient 模式下应用容器完全不知道服务网格的存在，不需要修改 Kubernetes Deployment 的 YAML。 渐进式迁移能力：允许同一个集群中 Sidecar 模式和 Ambient 模式的服务共存（即 Ambient 的 waypoint proxy 可以和 Sidecar Pod 相互通信），支持服务级别的粒度切换，避免 Big Bang 迁移。 保持现有 Istio CRD 兼容性：已有的 VirtualService、DestinationRule、AuthorizationPolicy 等配置在所有服务网格模式下保持语义一致，不要求团队重写已有的流量管理和安全策略。 方案设计 Ambient Mesh 的架构分为三个核心组件：ztunnel（节点级别的 L4 代理）、Waypoint Proxy（服务级别的 L7 代理，可选）、Istiod（统一控制面）。通信流程分为两种模式：纯 L4 模式——流量直接通过节点上的 ztunnel 进行 mTLS 加密和 L4 AuthorizationPolicy 的执行，不经过 Waypoint；L7 模式——当需要 HTTP 路由、重试、超时等七层能力时，将流量先重定向到对应服务的 Waypoint Proxy，处理完后再转发给目标 Pod。 ...