过去几年，服务网格几乎等同于在每个Pod里注入一个Sidecar代理。这套模式解决了流量治理、mTLS加密与可观测性问题，却也让资源开销、升级复杂度和排障难度同步上升。随着Istio在2024年底宣布Ambient模式正式GA，云上服务网格正在从边车无处不在转向按需代理、分层处理的新阶段。
Sidecar模式的甜蜜与负担
Sidecar的思路很直观：把网络能力下沉到与应用同生命周期的代理进程里，应用不改一行代码，就能获得重试、熔断、灰度、加密等能力。但代价同样明显。每个Pod都要额外消耗CPU与内存，数千个Pod就意味着数千个代理进程；升级代理版本往往要连带重启业务容器；代理与应用共享网络命名空间，出故障时很难界定责任边界。当集群规模上万，这些成本会被迅速放大。
分层：ztunnel与waypoint
Ambient模式的核心是把网格能力拆成两层。第一层是节点级的ztunnel，用Rust编写，负责L4转发、mTLS身份认证与HBONE隧道封装，每个节点只运行一个实例。第二层是可选的waypoint代理，基于Envoy构建，仅在需要L7策略时才按命名空间或服务部署，用来处理HTTP路由、请求头匹配、按路径限流等能力。不需要L7语义的工作负载，就只承担ztunnel的基础开销。
带来的实际变化
- 资源占用下降：节点级代理取代逐Pod代理，空闲服务的常驻开销明显减少。
- 升级解耦：ztunnel与waypoint可独立升级，不必重启业务容器。
- 渐进迁移：可以只为部分命名空间开启L7能力，其余保持L4，降低一次性改造风险。
- 身份统一：证书签发与身份体系仍由网格统一管理，安全边界不因分层而削弱。
仍需面对的问题
分层并非没有成本。L4与L7分离后，请求链路变长，排障需要同时观察ztunnel与waypoint两侧的指标；waypoint的部署粒度如果设计不当，也可能重新出现代理泛滥的老问题。此外，HBONE隧道对底层网络栈有额外要求，部分内核版本与CNI插件需要针对性适配。可观测性数据也要重新组织，指标、日志与链路追踪必须跨越两层做关联，否则定位延迟毛刺会变得更麻烦。
结语
从Sidecar到Ambient，本质是把默认全量代理改为默认轻量、按需增强。对已经在Kubernetes上运行大量微服务的企业来说，这提供了一条更平滑的路径：先用L4拿到加密与身份，再针对关键业务逐步开启L7治理。服务网格的竞争，也正在从功能清单转向单位资源的治理效率。