如果使用Istio，Ambient会比Sidecar更好吗？— 人们转向Ambient的原因

直截了当地说，如果是在新的Kubernetes环境中引入Istio，现在有充分的理由首先考虑Ambient。然而，Ambient并非“消除L7代理的技术”。它是一种结构，移除了附加到每个Pod的Envoy sidecar，通过节点级的ztunnel通用化L4安全，并仅在需要HTTP·gRPC等L7功能的地方部署waypoint Envoy。

在考虑Istio时，最熟悉的图景仍然是应用程序容器旁边附加Envoy sidecar。这种结构经过长时间的运行和充分验证，从mTLS到精细的L7流量控制都提供了一致的支持。

然而，随着服务和Pod数量的增加，问题也随之而来。每个Pod真的需要自己专用的L7代理吗？对于数据库连接或简单的内部TCP通信，是否总是需要能够解析HTTP的Envoy？平台团队为了升级代理而必须重启应用程序Pod的结构是最佳选择吗？

Istio Ambient Mesh正面解决了这些问题。它于2024年11月在Istio 1.24中达到稳定状态，Istio项目解释说，不仅新用户，现有sidecar用户也在积极考虑转向Ambient。但这并不意味着sidecar将被废弃。官方路线图明确指出sidecar不会被废弃，并且转换是自愿的。

本文将逐步探讨Ambient实际改变了什么，为什么人们被这种方式所吸引，以及在哪些环境中sidecar仍然是更安全的选择。

首先纠正一个误解：Ambient并非无代理网格

“sidecarless”这个词很容易让人将Ambient理解为无代理的服务网格。然而，Ambient仍然有代理。它只是改变了代理的位置和职责。


层	Sidecar模式	Ambient模式
L4安全·传输	由每个Pod的Envoy处理	由每个节点的ztunnel处理
L7 HTTP·gRPC处理	每个Pod的Envoy始终可用	由所需服务·命名空间的waypoint处理
部署单元	每个应用程序Pod一个	每个节点一个ztunnel + 可选waypoint
代理实现	Envoy	ztunnel使用Rust，waypoint使用Envoy
运营责任	与应用程序部署紧密耦合	作为平台组件分离

ztunnel是一个轻量级的节点代理，仅处理L3·L4。它负责基于工作负载身份的mTLS、L4授权、TCP可观测性和加密隧道。它不终止HTTP请求或读取头部。

另一方面，waypoint是基于Envoy的L7代理。当需要HTTP头部路由、重试、超时、熔断、故障注入、L7授权、请求级指标和跟踪等L7功能时使用。它通常在命名空间或服务等安全边界单位内共享，并在应用程序Pod外部单独安装和扩展。

因此，准确的说法不是“Ambient消除了L7代理”，而是“Ambient不强制所有工作负载都使用L7代理”。

图：通过ztunnel和waypoint的Ambient L7数据路径 · 来源：Istio Ambient data plane官方文档, Apache-2.0

人们希望转向Ambient的第一个原因：代理成本的单位发生变化

在Sidecar模式下，每增加一个Pod，就会增加一个Envoy。如果应用程序有20个，每个服务运行10个Pod，那么代理就有200个。每个代理都会请求CPU和内存，接收配置，并处理连接和遥测。

这种方法的优点是隔离性明确。由于每个工作负载都有自己的代理，负载和故障范围按Pod划分。另一方面，即使对于实际流量较小的Pod，也必须考虑最坏情况预留代理资源，导致在副本数量多、流量波动大的环境中，未使用的冗余资源累积。

Ambient改变了成本的单位。

ztunnel在每个节点上运行一个。
不需要L7的工作负载只使用ztunnel。
只有需要L7的服务才使用waypoint。
waypoint可以像普通的Kubernetes Deployment一样，由多个工作负载共享并水平扩展。

也就是说，成本并没有消失，而是将每个Pod的固定成本转移到每个节点·L7边界的共享成本。平台团队可以根据实际的L4和L7流量规模，分别规划ztunnel和waypoint的容量。

在Istio 1.24官方基准测试中，处理每秒1,000个1KB HTTP请求时，一个2 worker的sidecar大约使用0.20 vCPU和60MB，一个waypoint大约使用0.25 vCPU和60MB，一个ztunnel大约使用0.06 vCPU和12MB。这些数字是特定硬件和测试条件下的参考值，不保证生产环境的性能。重要的是ztunnel和waypoint可以独立部署的结构，而不是具体的数字。

图：Istio 1.24官方HTTP/1.1 P99延迟比较。特定基准测试环境的结果，不保证一般性能 · 来源：Istio Performance and Scalability官方文档, Apache-2.0

第二个原因：解耦网格引入与应用程序重启

Sidecar注入会改变应用程序Pod的形态。即使在命名空间上附加了注入标签，已运行的Pod也不会生成sidecar，因此需要重启。更改代理版本或注入模板时，也需要管理工作负载的滚动重启。

在Ambient中，只需在命名空间或工作负载上附加ambient标签，即可将正在运行的Pod注册到L4网格中。它不改变应用程序容器的spec，也不添加sidecar。

这一变化对于以下对象尤其重要：

重启成本高的有状态工作负载
运行时间短，容易与sidecar启动·停止冲突的Job
数百个Deployment由多个团队分管的集群
平台团队希望独立于应用程序发布升级网格的组织

但是，从现有sidecar迁移到Ambient时，必须遵循顺序。官方指南建议的顺序是：激活waypoint、注册ambient、移除sidecar注入、重启现有Pod。Ambient注册本身不需要重启，但要移除现有Pod中已运行的sidecar，最终仍需要替换一次Pod。

第三个原因：可以分阶段引入L4安全和L7功能

传统的sidecar功能丰富，但实际上是捆绑产品。即使只需要mTLS，每个Pod也会拥有能够执行HTTP路由和重试的整个Envoy。

Ambient将网格引入分为两个阶段：

首先通过ztunnel应用工作负载身份、mTLS、L4授权和TCP遥测。
然后，仅在实际需要HTTP感知的命名空间或服务中添加waypoint。

这种方式为难以一次性在全公司范围内应用服务网格的组织提供了现实的切入点。最初，他们可以只实现“通过基于身份的mTLS加密集群内部通信并统一L4策略”的目标，然后选择性地添加需要金丝雀路由或L7授权的服务。

需要L7功能的典型情况包括：

基于URL·头部·方法的路由和授权
HTTP重试、超时和熔断
流量分割和故障注入
请求级指标、访问日志和分布式跟踪

Ambient的魅力不在于放弃L7。它在于让L7的需求和成本在每个服务中明确化。

第四个原因：平台团队与应用程序团队的责任边界更加清晰

Sidecar位于应用程序Pod内部，但大部分由平台团队管理。这种模糊的位置导致了运营冲突。

应用程序团队必须接受未请求的容器和资源预留。
平台团队为了升级代理，必须与应用程序部署计划协调。
发生故障时，必须共同调查是应用程序还是sidecar导致的问题。
HPA、startup probe和Job终止等行为可能会受到sidecar生命周期的影响。

Ambient的ztunnel和waypoint是位于应用程序Pod之外的明确基础设施组件。平台团队负责代理的部署、扩展和升级，而应用程序团队则声明需要哪些L4·L7策略。

waypoint使用Kubernetes Gateway API这一点也很重要。waypoint本身作为Gateway资源部署，而HTTPRoute和AuthorizationPolicy等策略则连接到目标服务。这使得代理拓扑与应用程序部署分离，创建了一个更接近Kubernetes标准的运营模型。

第五个原因：可以减少L7请求通过代理的次数

在Sidecar模式下，当服务A调用服务B时，请求通常会依次通过A的sidecar和B的sidecar。L7处理发生在源和目的两端。

在Ambient中，L7策略基本上由目的地的waypoint负责。A的ztunnel将请求发送到负责B的waypoint，waypoint处理策略后，再转发到B节点的ztunnel。这种结构使得相同的请求只需通过L7 Envoy一次。

这并不意味着它总是更快。结果可能因到waypoint的网络路径、共享代理的负载、连接重用、数据包大小和策略复杂性而异。然而，它显然有可能将之前在两个sidecar上重复执行相同L7处理的路径简化为以目的地为中心的一个点。

在判断性能时，应在实际环境中测量以下指标，而不是依赖产品介绍资料的平均值：

L4专用路径和L4+L7路径的p50·p95·p99延迟时间
没有waypoint的服务和有waypoint的服务的CPU·内存使用量
waypoint水平扩展期间连接和错误率的变化
ztunnel或waypoint发生故障时的影响范围
遥测级别导致的成本变化

安全并非无条件改善，而是信任边界发生变化

在解释Ambient时，如果断定“比sidecar更安全”，就会忽略重要的权衡。

Sidecar模式为每个工作负载提供独立的代理和身份密钥，因此在代理本身未被入侵的前提下，提供了最细粒度的隔离。但是，应用程序容器和sidecar共享同一个Pod的网络和安全边界。如果应用程序Pod被完全入侵，攻击者就有可能访问sidecar通信或网格凭证。

在Ambient中，网格密钥不放在应用程序Pod中。ztunnel负责其节点上工作负载的身份和流量，因此即使一般的应用程序容器被入侵，攻击者也难以直接获取网格凭证。

反之，ztunnel由节点上的多个工作负载共享。如果ztunnel被入侵，该节点上工作负载的网络和密钥可能会受到影响。也就是说，Ambient分离了应用程序Pod和代理之间的信任边界，但同时也将节点级共享代理变成了重要的安全边界。


安全视角	Sidecar	Ambient
网格密钥位置	每个应用程序Pod的sidecar	节点的ztunnel
应用程序被入侵时	同一Pod的代理·密钥访问风险	网格密钥位于应用程序Pod之外
代理被入侵影响	以受影响的工作负载为中心	可能扩大到该节点的工作负载
隔离单位	Pod	ztunnel是节点级，waypoint是选定边界

哪种更安全取决于威胁模型。如果“将应用程序容器视为不可信边界”，那么Ambient的分离是一个优势。如果“最小化共享节点代理的影响范围是首要任务”，那么sidecar的按Pod隔离可能更熟悉。

那么，新Istio是否应该Ambient-first？

如果符合以下许多条件，将Ambient作为首选方案是合理的：

是基于Kubernetes的新Istio环境。
优先需要的功能是mTLS、工作负载身份和L4授权。
L7策略仅在部分命名空间或服务中需要。
希望避免向Pod和Job注入sidecar并重启的运营负担。
平台团队希望独立于应用程序发布管理网格数据平面。
计划以Gateway API为中心标准化流量策略。
小Pod数量多，导致按Pod预留代理资源的效率低下。

特别是如果“想引入服务网格但不想将sidecar的运营负担转嫁给所有团队”，Ambient的价值巨大。因为它首先提供了L4安全基础，L7可以在实际需求出现时再添加。

Sidecar仍然是更保守选择的情况

尽管Ambient已达到稳定状态，但并非所有Istio功能都以相同的成熟度迁移过来。在以下条件下，保留sidecar或在充分验证后进行转换会更安全：

1. 必须将VM工作负载包含在网格中

目前Ambient不支持VM工作负载。如果将Kubernetes Pod和VM绑定到同一个网格是核心需求，那么基于sidecar的Istio更适合。

2. 复杂的跨集群·跨网络配置是核心

Ambient的多网络、多主多集群功能从Istio 1.29开始提供Beta版本。然而，它不支持primary-remote拓扑，并且单网络配置目前也不是官方安装路径的重点。如果混合了多个CNI、VM和复杂拓扑，sidecar的长期运营经验会更安全。

3. 严重依赖EnvoyFilter或特殊扩展

目前不支持针对waypoint的EnvoyFilter。如果自定义Envoy过滤器、特殊Wasm扩展或精细的代理调整是核心，则需要首先检查功能兼容性。

4. 现有VirtualService非常复杂

在Ambient迁移指南中，VirtualService支持被标记为Alpha，并建议转换为Gateway API的HTTPRoute。同一个工作负载也无法混合使用VirtualService和HTTPRoute。如果专用API中积累了大量复杂策略，转换和回归测试的成本会很高。

5. L7授权不允许出现任何瞬间的空白

Sidecar和Ambient可以在同一个集群中共存，并且可以按命名空间回滚。但是，对于使用L7策略的现有工作负载，目前难以实现完全的零停机迁移。转换过程中可能会出现短暂的策略执行空白，因此如果持续的L7强制执行是必需的，则需要维护窗口。

现有Sidecar环境中尤其需要注意的迁移陷阱

Ambient可以逐步引入，但并非一个标签就能完成所有工作。

检查混合区域中waypoint绕过的可能性

从Sidecar发出的流量在迁移过程中可能会绕过目的地的waypoint。即使在目的地创建了基于waypoint的L7 AuthorizationPolicy，如果源工作负载仍然是sidecar，预期的策略可能不会生效。

来自Ingress的流量默认也会绕过waypoint

Ingress gateway发送到后端的请求在默认设置下不会经过waypoint。要在waypoint强制执行L7策略，需要审查istio.io/ingress-use-waypoint设置。

策略的目标指定方式发生变化

Ambient的L7 AuthorizationPolicy使用targetRefs而不是selector来指定waypoint或服务。RequestAuthentication和WasmPlugin也需要连接到waypoint。直接迁移现有YAML可能会导致策略应用于非预期的层。

可观测性的形态也发生变化

从Sidecar迁移到ztunnel和waypoint会改变reporter标签、指标收集位置和跟踪span的形态。不要假设现有的Grafana仪表板和警报可以保持不变。istioctl proxy-status也不显示ztunnel状态，因此需要将istioctl ztunnel-config workloads等Ambient专用检查方法纳入运营流程。

决策表：哪个适合我们的团队？


问题	Ambient有利的答案	Sidecar有利的答案
所有工作负载都需要L7吗？	仅部分需要	几乎所有都需要
希望解耦平台和应用发布吗？	强烈希望	当前耦合没问题
VM是网格的核心吗？	否	是
对现有EnvoyFilter依赖度高吗？	低	高
可以迁移到Gateway API吗？	可能	需要维护复杂的VirtualService
准备好运营共享代理了吗？	waypoint容量·故障隔离可能	按Pod隔离更熟悉
可以容忍现有L7策略的瞬间空白吗？	可确保维护窗口	不允许转换空白
是新部署吗？	考虑Ambient-first	对已验证的sidecar有明确要求

实际操作的默认值可以总结如下：

对于新的Kubernetes网格，首先使用Ambient构建L4基础，并仅在需要L7的边界添加waypoint。对于现有的sidecar环境，应根据策略、可观测性和安全执行路径，而不是功能列表，来设计命名空间单位的迁移。

验证Ambient时需要检查的清单

在生产环境之前，建议在一个小的命名空间中实际验证以下各项：

功能

仅使用ztunnel时，mTLS和L4 AuthorizationPolicy是否按预期工作？
添加waypoint后，HTTPRoute、重试和超时是否准确应用？
入口、出口和跨命名空间调用是否按预期通过waypoint？
现有VirtualService、DestinationRule和EnvoyFilter中哪些需要替换？

安全

没有waypoint的L4段和有waypoint的L7段之间的策略边界是否清晰？
STRICT PeerAuthentication和AuthorizationPolicy的组合是否按预期工作？
在sidecar和Ambient共存期间是否存在绕行路径？
ztunnel和waypoint服务账户的权限是否最小化？

运营

ztunnel和waypoint故障时的影响范围和恢复时间是多少？
waypoint自动伸缩标准和最小副本数是否合适？
是否可以在不部署应用程序的情况下执行升级和回滚？
现有Grafana仪表板、警报和跟踪是否反映了新的数据路径？

性能

L4和L4+L7路径的p95·p99延迟时间是多少？
流量集中时waypoint的CPU·内存和队列如何变化？
与sidecar相比，节点总预留资源和实际使用量变化了多少？
大规模配置部署和端点变化是否稳定收敛？

结论：Ambient并非Sidecar的删除，而是角色的重新分配

人们希望转向Ambient，不仅仅是为了消除一个sidecar容器。

Ambient重新划分了服务网格的职责。所有工作负载共同需要的身份、mTLS和L4策略集中到节点的ztunnel中，而成本更高的L7处理则仅放置在实际需要的服务的waypoint上。它将代理的生命周期与应用程序部署分离，使平台团队能够将其作为共享基础设施进行运营。

因此，对于新的Kubernetes中心环境，Ambient-first正在成为自然的默认选择。因为它在资源预留、Pod重启、Job兼容性、配置部署规模和团队间责任边界方面，提供了比sidecar更容易管理的运营模型。

然而，Ambient并非sidecar的完全上位替代。VM、复杂的跨集群、EnvoyFilter、现有VirtualService和零停机L7策略转换等要求仍然需要谨慎。共享ztunnel和waypoint所创建的故障·安全边界也需要重新设计。

最好的选择不是追随潮流，而是明确数据路径。你必须首先回答你的工作负载中L4足够的部分有多少，哪些服务需要L7，谁来运营代理，以及在转换过程中可以容忍哪些策略空白。当这些答案明确时，Ambient就不再是简单的“没有sidecar的Istio”，而是一个更具阶段性和可操作性的服务网格设计。