查看本文大纲

Istio 1.22 版本的发布标志着 Ambient 模式正式进入 beta 阶段，随之发布了一篇标题为 告别 Sidecar：Istio 的 Ambient 模式在 v1.22 中达到 Beta 的博客，声称 Layer 4 和 Layer 7 的功能现已可用于生产环境。其实社区早在一个月前的 KubeCon EU 上就宣布了这一里程碑。这种激动人心的宣传似乎在暗示我们可以彻底抛弃 Sidecar 模式，但事实真是如此吗？

为什么不急于告别 Sidecar 模式？

虽然我对新技术持开放态度，但完全告别 Sidecar 模式可能为时尚早。每种模式都有其特定的应用场景和优缺点。下面，我将详细分享 Ambient 模式相较于 Sidecar 模式的一些限制，帮助大家更好地理解两者之间的差异。

Ambient 模式与 Sidecar 模式的关键区别

流量管理

Ambient 模式的 L7 流量管理支持尚未成熟，尚未达到生产环境的可用水平。相较之下，Sidecar 模式在这方面更为稳定和可靠。

安全性

在 Ambient 模式下，mTLS 被强制在 namespace 级别开启，而 Sidecar 模式则赋予用户更大的灵活性，可以选择是否启用 mTLS。这种灵活性对于某些应用场景尤为重要。

可观测性

对于 L7 层的遥测数据，Ambient 模式能否像 Sidecar 模式一样对每个 pod 进行精确的监控和追踪仍是一个疑问。Sidecar 模式在可观测性方面已被广泛验证，其能力更为成熟。

运维

部署方面，Ambient 模式推荐使用 Helm，仅支持 Kubernetes 平台，而 Sidecar 模式还支持虚拟机和混合云环境。此外，Ambient 模式尚未得到主要云厂商的官方支持。在升级过程中，Ambient 模式的爆炸半径更大，暂不支持金丝雀发布，推荐使用蓝绿部署。对于从 Sidecar 模式向 Ambient 模式的迁移或二者共存，仍缺乏最佳实践。

扩展性

目前对于 Wasm 插件的支持，Ambient 模式仍不明确，而 Sidecar 模式在这方面已经有了较为完善的支持。

其他功能特性

Dual Stack 模式在 Sidecar 模式下虽然仍处于实验阶段，但至少已有一定的实现，而 Ambient 模式是否支持这一特性仍不明朗。

总结

虽然 Istio 1.22 带来了令人兴奋的 Ambient 模式，但在完全告别 Sidecar 模式之前，我们需要慎重考虑这些限制和差异。每种模式都有其独特的优势和适用场景，用户应根据自身需求做出明智的选择。我将继续对 Ambient 模式进行测试和追踪，更多深入解读敬请关注本博客。