Istio 最近宣布了“环境模式”——一种实验性的、无 sidecar 的部署模式。我们最近在如何从服务网格中获得最大性能和弹性的背景下讨论了 sidecar 与无 sidecar。在本文中,我们将特别介绍环境模式。
环境模式是 Istio 最近引入的一种新的实验性部署模式。它将原本由 Envoy sidecar 执行的职责分解为两个独立的组件:一个节点级的加密组件(称为“ztunnel”)和一个每个服务部署的 L7 Envoy 实例,用于处理所有其他的流程(称为“waypoint”)。环境模式模型试图在生命周期和资源管理上获得一些效率提升——至少,这是其动机。
对于大多数服务网格用户来说,Istio 数据平面的确切部署模式可能不是你需要过多考虑的问题。默认设置可能就足够好。对于一些服务网格用户,特别是那些有大量横向扩展且服务数量少的用户——在这种情况下,waypoint 架构最能获得效率提升——环境模式模式随着其成熟为生产就绪的基础设施软件,将会变得有用。
本文的其余部分是我们对环境模型与 Istio 现有的 sidecar 部署模型的权衡,以及哪一个可能更适合你以及何时使用。
由于环境模式将 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,并且我们不建议在那之前将其用于生产环境。
总结环境模式公告博客文章,驱动架构的核心假设是:
我们与世界上一些最大的企业紧密合作,以促进服务网格的采用,这些经验并没有完全证明这些激励思想:
L7 功能:网格的一些 L7 功能可以使应用的采用更加困难,但根据我们的经验,应用入网的更多破坏是由于连接寿命的变化或双重加密的问题造成的。这些问题无论是 sidecar 还是节点级代理都会以类似的方式表现出来,但在节点部署模型中(通常缺乏权限检查特权/节点级组件的日志)对应用团队来说更难排查问题。深入了解节点级代理与 sidecar的区别,请参阅我们之前提到的博客文章。
L7 CVE: 查看这些,我们看到:
一个仅 L4 的 Envoy 确实提供了相比 L7 Envoy 更小的攻击面,因为代码更少(CVEs 也更少)。是否这样的攻击面足够低以证明在节点上保持每个 pod 的身份是个问题。环境模式安全模型的核心在于我们对 ztunnel 组件的信任程度——这是社区打算首先发展的组件。总体而言,环境的安全模型最好是与 sidecar 模型相比的一种侧步,但在将其纳入现有安全模型时,边界更难以推理。
资源利用:的确,如果没有配置 pod 资源请求,sidecar 可以导致资源利用不良,如果不使用配置资源可见性或sidecar API 资源等技术。然而,我们在严格控制资源可见性并通过 sidecar API 资源限制配置范围的 Istio 部署中的经验是,sidecar 资源利用非常低,我们可以为每个 sidecar 设置比 Istio 默认配置文件更小的资源请求。手动维护这种配置类型的 sidecar API 资源非常具有挑战性——这就是为什么 Tetrate Service Bridge 根据更高级别的访问构造自动生成它。
我们很高兴看到环境部署模型带来的资源利用改进——因为一个独立的 waypoint Envoy 通常可以处理比单个服务实例(及其 sidecar)看到的流量显著更多。
额外的网络跳数与 sidecar:环境部署模型提供的最有趣的可能性之一是在 sidecar 架构中移除额外的 L7 Envoy。因为网格中的通信是 sidecar 对 sidecar,客户端和
服务器都应用 L7 策策,我们必须对每个请求进行两次 L7 处理。在环境模式中,该策略将由服务器的 Waypoint 执行——所以 L7 处理只发生一次。然而,连接的两侧仍有 ztunnel 进行 L4 处理。
这种交易——一个网络跳数而不是 Envoy 进行 L7 处理——是否总体上值得仍有待观察。当然在同一可用区的云提供商网络中,由于延迟低且连接可靠,它可能是值得的。然而,我们的许多客户在预置和各种物理站点上部署服务网格,这些站点通常看起来不像云提供商网络。
环境模式是对无 sidecar 服务网格模型的一种有趣看法。我们很期待看到它的发展,特别是如果它能帮助简化网格的采用。有一些特定的用例我们预计这种方法会带来好处,但现在还很早,尚不清楚这些权衡是否值得。无论如何,环境模式在被认为准备好生产之前可能还需要一段时间。直到那时,正如人们所说,让我们拭目以待。
最后更新于 2024/12/03