Istio 最近宣布了“环境模式”——一种实验性的、无 sidecar 的部署模式。我们最近在如何从服务网格中获得最大性能和弹性的背景下讨论了 sidecar 与无 sidecar。在本文中，我们将特别介绍环境模式。

什么是环境模式？

环境模式是 Istio 最近引入的一种新的实验性部署模式。它将原本由 Envoy sidecar 执行的职责分解为两个独立的组件：一个节点级的加密组件（称为“ztunnel”）和一个每个服务部署的 L7 Envoy 实例，用于处理所有其他的流程（称为“waypoint”）。环境模式模型试图在生命周期和资源管理上获得一些效率提升——至少，这是其动机。

为什么应该关心环境模式？

对于大多数服务网格用户来说，Istio 数据平面的确切部署模式可能不是你需要过多考虑的问题。默认设置可能就足够好。对于一些服务网格用户，特别是那些有大量横向扩展且服务数量少的用户——在这种情况下，waypoint 架构最能获得效率提升——环境模式模式随着其成熟为生产就绪的基础设施软件，将会变得有用。

简要总结

• 环境模式部署模式相较于 sidecar 模式在生命周期管理、资源利用、故障排除和安全姿态方面做了一些权衡。两者并没有明显的优劣。
• 环境模式是一项实验，最早将在 2023 年前成为生产就绪——即，现在还不能在生产中使用。当前的性能更差，功能不那么丰富，广泛使用的技术如 CNI 行为不明确。然而，我们预计随着实现的加固，这种情况将在未来几个月迅速改善。
• 你关心的许多网格功能——如每次请求的流量管理和安全控制、分布式跟踪和应用级 RED 指标——都在 L7 层发生。目前尚不清楚仅 L4 部分的环境模式的适用范围有多广，以及分解这些数据平面职责将在多大程度上帮助推动网格的采用。

本文的其余部分是我们对环境模型与 Istio 现有的 sidecar 部署模型的权衡，以及哪一个可能更适合你以及何时使用。

Istio 中的 L4 和 L7 处理是如何工作的？

由于环境模式将 L4 和 L7 处理分开，了解每一层中发生的网格行为是很重要的：

值得记住的是，一个在 L7 操作的代理可以执行 L4 和 L7 栏中的所有操作，而一个仅在 L4 操作的代理只能执行 L4 栏中的操作。了解何处发生了什么以及 L4 与 L7 的限制，我们可以看看环境模式与 sidecar 模型相比的权衡。

现在可以使用环境模式吗？（还不行）

截至其 2022 年 9 月的公告，环境模式是一个实验性的概念验证。根据几乎所有的度量，它的表现不如 sidecar，并且有不少限制。环境模式还没有准备好在生产环境中使用（对我们的客户来说——大型企业的平台团队——应用开发和测试环境也算是生产环境）。

然而，我们预计这种状态会相对快速地改变，因为整个社区的工程师正在努力改进这种部署模型。它将像所有其他 Istio 功能一样，通过功能阶段发展。关注Istio 功能列表，环境模式可能在 2023 年某个时候被提升为 Alpha 状态。我们预计它会在 2023 年底或 2024 年初离开 Beta，并且我们不建议在那之前将其用于生产环境。

关于服务网格和 Istio 的环境模式假设

总结环境模式公告博客文章，驱动架构的核心假设是：

1. 假设：Envoy 的 L7 功能是使新应用加入网格变得困难的原因。
2. 假设：Envoy 的 L7 功能是发现 CVE 的地方（绝大多数 Envoy CVE 都在 L7 代码中，而不是处理 TLS 和连接的 L4 代码），因此，在节点级别保持多个容器的证书在严格的 L4 代理中是可接受的，而在节点级别进行 L7 处理则不是。
3. 假设：sidecar 常常导致资源过度分配。
4. 假设：额外的网络跳数比 Envoy 进行 L7 计算更便宜（从两个 L7 sidecar 转到一个 L7 waypoint 增加了一个跳数，但减少了一个执行 L7 处理的 Envoy）。
5. 假设：Istio 最有价值的功能是传输中的加密，因此，优化使这一用例易于实现是有价值的。

环境模式假设与客户现场的经验如何匹配

我们与世界上一些最大的企业紧密合作，以促进服务网格的采用，这些经验并没有完全证明这些激励思想：

1. L7 功能：网格的一些 L7 功能可以使应用的采用更加困难，但根据我们的经验，应用入网的更多破坏是由于连接寿命的变化或双重加密的问题造成的。这些问题无论是 sidecar 还是节点级代理都会以类似的方式表现出来，但在节点部署模型中（通常缺乏权限检查特权/节点级组件的日志）对应用团队来说更难排查问题。深入了解节点级代理与 sidecar的区别，请参阅我们之前提到的博客文章。

2. L7 CVE: 查看这些，我们看到：

   • 三十三个与 L7 处理相关，主要是解析或 HTTP 处理。
   • 剩下的 12 个是 L4 或 Envoy 固有的（连接处理、证书处理、噪声邻居 DOS、缓冲区溢出等）。
   • L7 CVEs 的平均严重性高于非 L7 CVE。

   一个仅 L4 的 Envoy 确实提供了相比 L7 Envoy 更小的攻击面，因为代码更少（CVEs 也更少）。是否这样的攻击面足够低以证明在节点上保持每个 pod 的身份是个问题。环境模式安全模型的核心在于我们对 ztunnel 组件的信任程度——这是社区打算首先发展的组件。总体而言，环境的安全模型最好是与 sidecar 模型相比的一种侧步，但在将其纳入现有安全模型时，边界更难以推理。

3. 资源利用：的确，如果没有配置 pod 资源请求，sidecar 可以导致资源利用不良，如果不使用配置资源可见性或sidecar API 资源等技术。然而，我们在严格控制资源可见性并通过 sidecar API 资源限制配置范围的 Istio 部署中的经验是，sidecar 资源利用非常低，我们可以为每个 sidecar 设置比 Istio 默认配置文件更小的资源请求。手动维护这种配置类型的 sidecar API 资源非常具有挑战性——这就是为什么 Tetrate Service Bridge 根据更高级别的访问构造自动生成它。

   我们很高兴看到环境部署模型带来的资源利用改进——因为一个独立的 waypoint Envoy 通常可以处理比单个服务实例（及其 sidecar）看到的流量显著更多。

4. 额外的网络跳数与 sidecar：环境部署模型提供的最有趣的可能性之一是在 sidecar 架构中移除额外的 L7 Envoy。因为网格中的通信是 sidecar 对 sidecar，客户端和

服务器都应用 L7 策策，我们必须对每个请求进行两次 L7 处理。在环境模式中，该策略将由服务器的 Waypoint 执行——所以 L7 处理只发生一次。然而，连接的两侧仍有 ztunnel 进行 L4 处理。

这种交易——一个网络跳数而不是 Envoy 进行 L7 处理——是否总体上值得仍有待观察。当然在同一可用区的云提供商网络中，由于延迟低且连接可靠，它可能是值得的。然而，我们的许多客户在预置和各种物理站点上部署服务网格，这些站点通常看起来不像云提供商网络。

5. mTLS：Istio 的传输中加密无疑是其最强大的功能之一。它被用于（以 FIPS 验证的形式）FIPS 合规、PCI 合规 和在各种安全优先的环境中。然而，当我们看到网格的能力时，通常加密本身并不是采用的原因：通常是加密与 L7 策略（包括流量控制）和可观测性一起激励技术投资。从上表中可以看出，这些能力不能仅靠 ztunnel 实现——它们需要一个 L7 Envoy。事实上，我们今天看到的大多数网格使用都需要一个 L7 Envoy。我们对任何使网格采用更容易的事情都感到非常热情，但我们还没有信心环境模式的部署模型将在这方面显著提供。

关于环境模式的最后思考

环境模式是对无 sidecar 服务网格模型的一种有趣看法。我们很期待看到它的发展，特别是如果它能帮助简化网格的采用。有一些特定的用例我们预计这种方法会带来好处，但现在还很早，尚不清楚这些权衡是否值得。无论如何，环境模式在被认为准备好生产之前可能还需要一段时间。直到那时，正如人们所说，让我们拭目以待。