ambient 网格介绍

今天，我们很高兴推出“ambient 网格”及其参考实现：一种新的 Istio 数据平面模式，旨在简化操作，扩大应用程序兼容性并降低基础设施成本。ambient 网格使用户可以选择放弃 sidecar 代理，转而使用集成到其基础设施中的数据平面，同时保持 Istio 的零信任安全性、遥测和流量管理的核心功能。我们正在与 Istio 社区共享 ambient 网格的预览版，我们正在努力在未来几个月内将其推向生产就绪状态。

Istio 和 sidecar

自成立以来，Istio 架构的一个决定性特征是使用 *sidecar* - 与应用程序容器一起部署的可编程代理。Sidecar 允许运营商获得 Istio 的好处，而无需应用程序进行重大手术及其相关成本。

虽然 sidecar 相比于重构应用程序具有显著优势，但它们并没有提供应用程序和 Istio 数据平面之间的完美分离。这会导致一些限制

• **侵入性** - Sidecar 必须通过修改应用程序的 Kubernetes Pod 规范并在 Pod 中重定向流量来“注入”到应用程序中。因此，安装或升级 sidecar 需要重新启动应用程序 Pod，这可能会对工作负载造成干扰。
• **资源利用不足** - 由于 sidecar 代理专用于其关联的工作负载，因此必须为每个单独 Pod 的最坏情况使用情况预配 CPU 和内存资源。这累积起来会导致大量的预留，从而导致整个集群的资源利用不足。
• **流量中断** - 流量捕获和 HTTP 处理（通常由 Istio 的 sidecar 执行）在计算上代价高昂，并且可能会破坏一些具有不符合标准的 HTTP 实现的应用程序。

虽然 sidecar 有其存在的位置 - 我们稍后会详细讨论 - 但我们认为需要一个侵入性更小、更易于使用的选项，这将更适合许多服务网格用户。

分层

传统上，Istio 在单个架构组件（sidecar）中实现了所有数据平面功能，从基本加密到高级 L7 策略。实际上，这使得 sidecar 成为一种非此即彼的方案。即使工作负载只需要简单的传输安全性，管理员仍然需要支付部署和维护 sidecar 的运营成本。Sidecar 每个工作负载的运营成本固定，无法根据用例的复杂性进行扩展。

ambient 数据平面采用了一种不同的方法。它将 Istio 的功能划分为两个不同的层。在底部，有一个安全覆盖层，用于处理流量的路由和零信任安全性。在上面，根据需要，用户可以启用 L7 处理以访问 Istio 的全部功能范围。L7 处理模式虽然比安全覆盖层更繁重，但它仍然作为基础设施的 ambient 组件运行，不需要修改应用程序 Pod。

这种分层方法允许用户以更渐进的方式采用 Istio，从无网格平滑过渡到安全覆盖层，再到完整的 L7 处理 - 根据需要，在每个命名空间的基础上进行过渡。此外，在不同 ambient 层中运行的工作负载，或者使用 sidecar 的工作负载，可以无缝地互操作，允许用户根据不断变化的特定需求混合匹配功能。

构建 ambient 网格

Istio 的 ambient 数据平面模式使用一个共享代理，在 Kubernetes 集群中的每个节点上运行。该代理是一个零信任隧道（或 **ztunnel**），其主要职责是安全地连接和验证网格中的元素。节点上的网络栈将所有参与工作负载的流量重定向到本地 ztunnel 代理。这完全将 Istio 的数据平面与应用程序的关注点分离，最终允许运营商启用、禁用、扩展和升级数据平面，而不会干扰应用程序。ztunnel 不会对工作负载流量执行任何 L7 处理，使其比 sidecar 显著精简。这种复杂性和相关资源成本的大幅降低使其适合作为共享基础设施交付。

Ztunnel 实现了服务网格的核心功能：零信任。当为命名空间启用 ambient 模式时，就会创建安全覆盖层。它为工作负载提供 mTLS、遥测、身份验证和 L4 授权，而不会终止或解析 HTTP。

在启用 ambient 模式并创建安全覆盖层后，可以将命名空间配置为使用 L7 功能。这允许命名空间实现 Istio 的全部功能集，包括 虚拟服务 API、L7 遥测 和 L7 授权策略。以这种模式运行的命名空间使用一个或多个基于 Envoy 的 **航路点代理** 来处理该命名空间中工作负载的 L7 处理。Istio 的控制平面将集群中的 ztunnel 配置为将所有需要 L7 处理的流量通过航路点代理。重要的是，从 Kubernetes 的角度来看，航路点代理只是普通的 Pod，可以像任何其他 Kubernetes 部署一样自动扩展。我们预计这将为用户带来巨大的资源节省，因为航路点代理可以自动扩展以适应其所服务命名空间的实时流量需求，而不是运营商预期 的最大最坏情况负载。

ambient 网格使用 mTLS 上的 HTTP CONNECT 来实现其安全隧道并在路径中插入航路点代理，我们称这种模式为 HBONE（基于 HTTP 的覆盖网络环境）。HBONE 为流量提供了比 TLS 本身更清晰的封装，同时能够与常见的负载均衡器基础设施互操作。默认情况下使用 FIPS 版本以满足合规性需求。关于 HBONE、其基于标准的方法以及 UDP 和其他非 TCP 协议的计划的更多详细信息将在以后的博客中提供。

在单个网格中混合使用 sidecar 和 ambient 模式不会对系统的功能或安全特性造成限制。Istio 控制平面确保无论选择哪种部署模型，策略都得到正确 enforcement。ambient 模式只是引入了一个具有更好的人体工程学和更多灵活性的选项。

为什么本地节点上没有 L7 处理？

ambient 模式在节点上使用一个共享的 ztunnel 代理，它处理网格的零信任方面，而 L7 处理则在单独计划的 Pod 中的航路点代理中进行。为什么还要绕道，不直接在节点上使用一个共享的完整 L7 代理呢？这样做有几个原因

• Envoy 本质上不是多租户的。因此，我们对在共享实例中混合来自多个不受约束的租户的 L7 流量的复杂处理规则存在安全问题。通过严格限制为 L4 处理，我们显著减少了攻击面。
• ztunnel 提供的 mTLS 和 L4 功能与航路点代理中所需的 L7 处理相比，需要更少的 CPU 和内存占用。通过将航路点代理作为共享命名空间资源运行，我们可以根据该命名空间的需求独立地对其进行扩展，并且其成本不会不公平地分配给无关的租户。
• 通过缩减 ztunnel 的范围，我们允许将其替换为其他能够满足定义良好的互操作性契约的安全隧道实现。

但是，那些额外的跳跃呢？

在 ambient 模式下，航路点不一定是与它所服务的工作负载位于同一节点上。虽然乍一看这似乎是一个性能问题，但我们相信延迟最终会与 Istio 当前的 sidecar 实现保持一致。我们将在专门的性能博客文章中进行更多讨论，但现在我们将总结为两点

• 实际上，Istio 的大部分网络延迟并非来自网络 (现代云提供商拥有极其快速的网络)。相反，最大的罪魁祸首是 Istio 需要实施其复杂的功能集而进行的密集的 L7 处理。与每个连接实现两个 L7 处理步骤（每个 sidecar 一个）的 sidecar 不同，ambient 模式将这两个步骤合并为一个。在大多数情况下，我们预计这种降低的处理成本将抵消额外的网络跳跃。
• 用户通常会部署一个网格来首先启用零信任安全策略，然后根据需要选择性地启用 L7 功能。ambient 模式允许这些用户在不需要 L7 处理时完全绕过其成本。

资源开销

总体而言，我们预计 Istio 的 ambient 模式对大多数用户来说将具有更少且更可预测的资源需求。ztunnel 的有限职责允许它作为节点上的共享资源部署。这将大幅降低大多数用户所需的每个工作负载的预留。此外，由于航路点代理是普通的 Kubernetes Pod，因此可以根据其所服务工作负载的实时流量需求对其进行动态部署和扩展。

另一方面，sidecar 需要为每个工作负载的 worst case 预留内存和 CPU。进行这些计算很复杂，因此在实践中管理员往往会过度预配。这会导致由于高预留而导致节点利用率不足，从而阻止其他工作负载被调度。ambient 模式更低的每个节点固定开销和动态扩展的航路点代理将总体上需要更少的资源预留，从而导致更有效地利用集群。

安全性呢？

全新的架构自然会带来关于安全性的问题。 环境模式安全博客 深入探讨了这个问题，这里我们将进行简要概括。

Sidecar 与它们服务的负载并置，因此，一个 Sidecar 中的漏洞会危害另一个 Sidecar。在环境网格模型中，即使应用程序被入侵，ztunnel 和航点代理仍然可以对受损应用程序的流量强制执行严格的安全策略。此外，鉴于 Envoy 是一款由全球最大的网络运营商使用的成熟且经过实战考验的软件，它可能比它运行 alongside 的应用程序更不容易受到攻击。

虽然 ztunnel 是一个共享资源，但它只能访问当前运行在它所在节点上的负载的密钥。因此，它的爆炸半径不比任何其他依赖于每个节点密钥进行加密的加密 CNI 更糟糕。此外，鉴于 ztunnel 的 L4 攻击面有限，以及 Envoy 上述的安全特性，我们认为这种风险是有限的，可以接受的。

最后，虽然航点代理是共享资源，但它们仅限于为一个服务帐户提供服务。这使得它们与如今的 Sidecar 一样好；如果一个航点代理被入侵，与该航点相关的凭据就会丢失，其他任何东西都不会受到影响。

这是 Sidecar 的终点吗？

当然不是。虽然我们相信环境网格将成为未来许多网格用户最佳选择，但对于那些需要专用数据平面资源（例如为了合规性或性能调整）的用户来说，Sidecar 仍然是一个不错的选择。Istio 将继续支持 Sidecar，更重要的是，允许它们与环境模式无缝互操作。事实上，我们今天发布的环境模式代码已经支持与基于 Sidecar 的 Istio 互操作。

了解更多

观看一个简短的视频，观看 Christian 演示 Istio 环境模式组件并演示一些功能

参与进来

我们今天发布的是 Istio 中环境模式的早期版本，它仍在积极开发中。我们很高兴与更广泛的社区分享它，并期待更多人参与进来，在我们迈向 2023 年的生产就绪阶段，共同塑造它。

我们渴望得到您的反馈，以帮助塑造解决方案。支持环境模式的 Istio 版本可供您 下载并尝试 在 Istio Experimental 仓库 中。在 README 中提供了缺少的功能和工作项列表。请尝试一下，并 告诉我们您的想法！

感谢为环境网格发布做出贡献的团队！

• Google：Craig Box, John Howard, Ethan J. Jackson, Abhi Joglekar, Steven Landow, Oliver Liu, Justin Pettit, Doug Reid, Louis Ryan, Kuat Yessenov, Francis Zhou
• Solo.io：Aaron Birkland, Kevin Dorosh, Greg Hanson, Daniel Hawton, Denis Jannot, Yuval Kohavi, Idit Levine, Yossi Mesika, Neeraj Poddar, Nina Polshakova, Christian Posta, Lin Sun, Eitan Yarmush