[译] 全面解析 Istio 新型部署模式:环境模式

本文详细介绍了 Istio 的新型部署模式——环境模式(Ambient Mesh),这是一种实验性的无 sidecar 部署模式,旨在提高服务网格的性能和可靠性。

声明
此文为个人翻译,仅供参考,不代表我个人立场。翻译过程中可能有删改或遗漏,如需了解原文,请自行查阅。如有疏漏,欢迎指正。
查看本文大纲

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 处理分开,了解每一层中发生的网格行为是很重要的:

L4 L7
安全性
服务对服务认证 SPIFFE, 通过 mTLS 证书。Istio 发行一个编码了 pod 服务账户身份的短期 X.509 证书。 N/A—服务身份在 Istio 中基于 TLS。
服务对服务授权 基于网络的授权,加上基于身份的策略,例如:A 只能接受来自“10.2.0.0/16”的入站调用;A 可以调用 B 完整策略,例如:A 只能在拥有有效的终端用户凭据且包含 READ 范围时,从 B 获取 /foo。
终端用户认证 N/A—我们无法应用每个用户的设置。 本地认证 JWT,支持通过 OAuth 和 OIDC 流程的远程认证。
终端用户授权 N/A—见上文。 服务对服务策略可以扩展到要求具有特定范围、发行者、主体、受众等的终端用户凭据—但它不能用于全面的用户对资源的访问控制。全面的用户对资源的访问控制应该使用外部授权来实现。
Envoy 的外部授权 API (ext_authz) 不能执行任何每次请求的策略;ext_authz API 只能配置用于 L7 流量。 执行每次请求的策略,决策来自一个外部服务,例如 OPA。
可观测性
日志记录 基本网络信息:网络 5 元组,发送/接收的字节等。参见 Envoy 文档 完整的请求元数据日志记录,除了基本网络信息。
跟踪 今天不可行;可能最终通过 HBONE 实现。 Envoy 参与分布式跟踪。参见 Istio 跟踪概述
指标 仅 TCP(发送/接收的字节,数据包数量等)。 L7 RED 指标:请求率、错误率、请求持续时间(延迟)。
流量管理
负载均衡 仅在连接级别。参见 TCP 流量转移任务 每次请求,启用例如金丝雀部署、gRPC 流量等。参见 HTTP 流量转移任务
断路器 仅 TCP HTTP 设置 除了 TCP。
异常检测 在连接建立/失败时。 在请求成功/失败时。
速率限制 仅在连接建立时,L4 连接数据的速率限制,有全局和本地速率限制选项。 每次请求的 L7 请求元数据的速率限制
超时 仅在连接建立时(通过断路器设置配置连接保持活动)。 每次请求。
重试 重试连接建立。 重试每次请求失败。
故障注入 N/A—TCP 连接上不能配置故障注入。 全面的应用和连接级故障(超时、延迟、特定响应码)。
流量镜像 N/A—仅 HTTP。 请求的百分比基础镜像到多个后端

值得记住的是,一个在 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 处理——是否总体上值得仍有待观察。当然在同一可用区的云提供商网络中,由于延迟低且连接可靠,它可能是值得的。然而,我们的许多客户在预置和各种物理站点上部署服务网格,这些站点通常看起来不像云提供商网络。

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

关于环境模式的最后思考

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

最后更新于 2024/12/03