Istio 的未来：无 Sidecar 和带有 Ambient Mesh 的 Sidecar
Istio 的未来：无 Sidecar 和带有 Ambient Mesh 的 Sidecar
作者 | Lin Sun
译者 | 刘雅梦
策划 | 丁晓昀
Istio 的 Ambient Mesh（环境网格） 为 Istio 服务网格引入了一个新的无 Sidecar（Sidecar-Less）数据平面选项，其目的是简化应用程序的启动，增加增量采用，并降低 Istio 网格用户的基础设施成本。
Ambient Mesh 能同时支持 Sidecar 数据平面架构和无 Sidecar 数据平面两种架构，因此我们可以根据应用程序的需求来选择其中一种或两者。在 Istio 1.16 中，Sidecar 得到了增强，以支持 HBONE （HTTP-Based Overlay Network Environment），因此它们可以通过 ztunnel（零信任隧道，提供安全覆盖层）或 / 和 waypoint 代理（提供第 7 层处理层）与无 Sidecar 应用程序进行互操作，这些应用程序也需要能理解 HBONE。
Ambient 无 Sidecar 的优势
Ambient 的最大优势是它不需要对应用程序进行任何更改，这就是它被称为 ambient 的原因。Ambient 无 Sidecar 数据平面被设计成对应用程序是透明的，例如，不需要为应用程序改变 CI/CD 管道，也不需要在数据平面出现新漏洞（基于 Envoy 的 waypoint 代理或基于 Rust 的 ztunnel，更多详细信息请参阅下文）时重启应用程序。除了不需要更改应用程序外，无 Sidecar 数据平面还消除了 Istio 的许多 Sidecar应用程序要求，如服务器发送优先协议、无法支持 Kubernetes Jobs 或保留的 sidecar 端口列表，从而扩大了对应用程序的支持。
Ambient 中的两层（安全覆盖层和 L7 处理层）数据平面方式允许我们更好地逐步采用 Ambient 无 Sidecar 数据平面，而不是全有或全无 sidecar 注入。我们可以从安全覆盖层开始，同时享受该层带来的所有好处，比如具有加密身份的 mTLS、简单的第 4 层授权策略和遥测。在没有任何 L7 处理的情况下，安全覆盖层显著地减少了 CVE 和其他补丁的攻击面和更新数据平面的频率。两层架构使我们能够根据所需付费，并独立于工作负载扩展服务网格数据平面，从而降低了基础设施的成本。
Istio Ambient 的开发有什么新动向?
Istio 团队正在努力将 Ambient Mesh 作为下一个 Istio 版本的一部分，我们已经建立了 ztunnel 和 ambient项目委员会 来跟踪我们的进展，并衷心欢迎来自社区的贡献。所有 Ambient Mesh 贡献者会在 美国东部时间每周三的下午 1 点开会，讨论新的设计文档或贡献者的任何担忧。以下是我想强调的两大变化：
基于 Rust 的 ztunnel
当 Istio 的 Ambient 服务网格于 2022 年 9 月 7 日发布时，ztunnel 组件是使用 Envoy 代理实现的，因为我们想让每个人都能尽早安装并探索 Istio 的 Ambient Mesh。在最初发布后不久，社区评估了 ztunnel 是应该继续使用 Envoy 还是应该用 Rust 从头开始重写，John Howard 开始了 基于 Rust 的 ztunnel 项目。关于如何简化基于 Envoy 的 ztunnel，并消除对内部监听器的需求，我们进行了大量的思考，但最终，社区决定加入基于 Rust 的 ztunel 项目，原因如下：
- Rust 天生适合做高性能、低利用率的网络代理。Ztunnel 提供的安全覆盖层，其功能和攻击面都大大减少了，因此与全特性代理相比，它更容易编写。
- Rust 有丰富的库可供使用，包括 Tokio 异步运行时。
- Rust 有一个明确的 CVE 流程可供我们利用。
- 最后但同样重要的是，与 Envoy 不同，Rust 通过其 Tokio 库原生支持工作窃取（work stealing）。这对于 ztunnel 有效地重用连接非常重要。
想要了解更多关于基于 Rust 的 ztunnel 与基于 Envoy 的 ztunel 的决定，请参阅 这篇博客文章，其中详细解释的我们想法。
只包含目的服务的 waypoint 代理
当 Istio 的 Ambient 服务网格最初发布时，waypoint 代理配置比 ztunnel 配置更容易理解，因为它只处理共享同一服务帐户的工作负载，例如每个服务帐户一个 waypoint 代理。然而，waypoint 代理配置仍然非常复杂，因为源 waypoint 代理知道 Kubernetes 集群中的所有其他服务，而不管这些服务是否是实际的目的服务。
图 1：源 waypoint 代理能感知所有的其他服务（此处只展示了无 Sidecar 服务，但它们也可能是网格外服务的 Sidecar）
Istio v1.1 中引入的 Sidecar 资源通常用于 Istio 环境中，以减少 Envoy Sidecar 的配置，从而提高 Envoy Sidecar 的性能和资源利用率。当我们开始评估是否需要为 waypoint 代理（也是基于 Envoy 的）支持 Sidecar 资源时，我们意识到我们可以通过提供一个仅支持目的服务的 waypoint 代理即可大幅削减 waypoint 代理的配置。
通过只关注目的服务的 waypoint 代理，waypoint 代理配置仅需包含非常有限的动态集群、端点和路由相关的详细信息即可，其中 waypoint 代理需要连接到这些动态集群、端点和路由，而无需将所有潜在连接到其运行的 Kubernetes 集群中的任何服务的详细信息都包含内。这一更改有效地消除了对 waypoint 代理支持 Sidecar 资源的需求，也避免了用户手动配置 Sidecar 资源。
图 2：目的 waypoint 知道目的服务，但不知道其他服务
例如，在我的 Kubernetes 集群中，我将 sleep、helloworld 和 httpbin 应用程序以无 Sidecar 的形式部署在了 default 命名空间中。我还将 httpbin 应用程序与 Sidecar 一起部署在 foo 命名空间中。
图 3：在没有 Sidecar 的情况下部署的 helloworld、httpbin 和 sleep 应用程序，以及 foo 命名空间中使用 Sidecar 部署的 httpbin
以下是 foo 命名空间中 httpbin 的 sidecar 的路由配置，这与源 waypoint 代理非常相似，因为两者都知道所有其他服务的路由：
图 4：httpbin 的 sidecar 路由配置
相比之下，以下是 httpbin 大大减少了 waypoint 代理的路由配置。请注意，在 foo 命名空间中没有与 helloworld 或 sleep 应用程序或 httpbin 应用程序相关的路由。虽然这里使用动态路由作为示例，但与 Sidecar 相比，动态集群和端点也减少了仅限于目的的 waypoint 代理。
图 5：httpbin 的 waypoint 代理路由配置
只包含目的服务的 waypoint 代理意味着不会包含任何的源 waypoint 代理。如果没有源 waypoint 代理，如果我们的目的服务没有 waypoint 代理（例如 AWS Lambda 服务），并且我们想在连接到目的服务时添加弹性，会发生什么呢？
在这种情况下，我们需要一个出口网关或专用代理来处理出口流量。这个代理的优点在于，它将包含一个精简的列表，其中列出了我们需要连接的外部服务，而不会出现前面提到的臃肿配置问题，也不需要使用 Sidecar 资源或目的服务中的 networking.istio.io/exportTo 注解来修剪不必要的配置。
Ambient 无 Sidecar 模式这么好，那 Sidecar 呢？
Sidecar 不会很快消失，我们可以继续使用 Sidecar，只要我们觉得舒服，或者仅仅是因为我们已经从安全团队那里获得了所有的必要批准。即使 Ambient 无 Sidecar 已经成熟了，我预计 Sidecar 仍将继续在以下用例中发挥重要作用：
1. 源服务需要特定的客户端配置
对于只包含目的服务的 waypoint，waypoint 就像是目的服务的网关，其中 waypoint 代理实现流量管理和政策执行功能。这也意味着所有源服务共享相同的实施，缺乏配置特定于客户端配置覆盖的能力。在 Istio 的 VirtualService 资源中，我们可以使用 sourceLabels 配置特定于给定源的故障注入或重试或超时的覆盖；例如，仅为带有标签“env:prod”的客户端 pod 添加 HTTP 故障注入。
如果我们的特定源服务想要对重试 / 超时 / 故障注入 / 负载均衡器配置执行客户端覆盖，该怎么办呢？我们可以使用 Sidecar，它能为每个客户端提供细粒度的配置覆盖，这样我们的客户端就不需要使用目的服务提供的默认值了。
图 6：Source1 使用 Sidecar 进行配置覆盖
2. 目的服务需要特定于目的工作负载的策略
waypoint 代理是按服务帐户或名称空间来设计的；对于共享同一服务帐户的服务来说，如果其需要比服务帐户更细粒度的配置，该怎么办呢？例如，对于共享同一个服务帐户的 Destination1 服务和 Destination2 服务来说，Destination1 服务需要特定的 Telemetry 或 WasmPlugin 或 RequestAuthentication 或 EnvoyFilter 配置，而 Destination2 服务不需要。当我们需要比每个服务帐户更细粒度的特定于目的服务的配置时，我们可以继续使用 Sidecar。或者，我们可以使用自己的服务帐户为 Destination1 创建一个专用的 waypoint 代理，而不是使用 Sidecar 代理运行。
图 7：使用 Sidecar 在 Destination 1 服务上执行特定于目的服务的策略
3.Sidecar 和无 Sidecar 可以共存和互操作
Sidecar 和无 Sidecar 的起始边界是在命名空间级别，在命名空间级别上，我们可以通过 istio.io/dataplane mode=ambient 命名空间标签将一个或多个特定的命名空间定义为 sidecar-less。当 sidecar 注入标签与命名空间上的 ambient sidecar-less 标签共存时，sidecar 注入标签总是获胜。这种设计确保了我们可以根据特定的业务需求轻松地从 Sidecar 迁移到无 Sidecar，或者从是无 Sidecal 迁移到 Sidecar。
Istio Ambient Mesh 的未来
Istio 社区正在为 Ambient Mesh 做很多令人兴奋的事情。Ambient Mesh 已经从实验分支中分离出来，并合并到了上游的主干上，这样它就可以很容易地与即将发布的 Istio 1.18 或更新版本一起安装。我们正在继续发展 Ambient Mesh，以提高其性能、可扩展性和可调试性，正如上述基于 Rust 的 ztunnel 和仅包含目的服务的 waypoint 代理的更新所显示的那样。随着社区致力于使 Ambient Mesh 生产成为 Istio 的默认产品，我们邀请你共同参与这一旅程，请在 Istio Slack 或 GitHub 的 ambient 频道中提供反馈或贡献，以帮助我们共同塑造 Ambient Mesh。
原文链接：
https://www.infoq.com/articles/istio-ambient-mesh/