Proxy 解读 Istio Waypoint 部署模型 Ambient

本文论述了 Istio Ambient Waypoint Proxy 的多种部署形式，解释了按节点部署的弊病，并经过实例说明了最佳通常。

Ambient 形式是 Istio 在 2022 年引入的新型无际车数据平面，并于往年 5 月到达Beta[2]形态。Istio 社区正致力在下一个 Istio v1.24 版本中将 Ambient 推向 GA（普通可用）形态。Ambient 将 Istio 的性能分为两个独立的层：安保笼罩层和第 7 层解决层。在与许多试用 Ambient 的用户协作时，我想廓清关于 waypoint proxy 的一些经常出现疑问和困惑。它是一个可选的基于 Envoy 的组件，担任解决其控制的上班负载的 L7 事务。

Waypoint Proxy 的经常出现部署形式是什么？

了解 Waypoint Proxy

你可以将 waypoint proxy 便捷地视为一组目的地的网关，这些目的地可以是来自一个或多个命名空间的一个或多个服务和上班负载。除了解决集群外部的 L7 流量外，它与你的入口或进口网关没有太大区别。这也是为什么在部署 waypoint proxy 时须要经常使用 Kubernetes 的 Gateway 资源的要素。

我十分青睐 waypoint 架构的灵敏性，你可以选用适宜自己需求的架构。以下是一些经常出现的形式：

A: 针对命名空间的 Waypoint Proxy

最经常出现的形式是，每个团队在集群中领有一个命名空间，并控制该命名空间内的服务和部署。在这种形式下，咱们希冀每个团队都有自己的 waypoint proxy，供命名空间内的服务经常使用。依照这种形式，咱们将自动的 waypoint 部署设计为命名空间范畴，供命名空间内的一切服务经常使用。在下图中，服务 A、B、C 位于同一命名空间内。一切到服务 A、B 或 C 的 Ambient Mesh 客户端流量将经过命名空间的 waypoint proxy，由客户端的 ztunnel 启动编程。

留意：为繁复起见，省略了目的地端的 ztunnel

B: 针对局部服务的 Waypoint Proxy

假设你不宿愿到服务 B 的流量经过 waypoint proxy 怎样办？一个经常出现的要素是，你只有要对服务 B 的流量启动 L4 层的控制，这样在调用它时就不须要经过 waypoint proxy。例如，你有一个调用 MySQL 数据库服务的 Web 服务，只有要对其启动 L4 控制。另一个例子是，当服务是 “外部” 的，只被命名空间内的其余服务调用，你只有要对跨命名空间边界的服务启动授权战略。例如，在驰名的Bookinfo 运行程序[3]中，你可认为 productpage 服务启用零信赖，拒绝除端口 9080 上 GET 方法的流量之外的一切流量。关于一切外部服务，如 reviews 或 details 服务，你可以继续准许命名空间内的一切流量。

另一个用例是，服务 A 的流量十分大，你宿愿有一个公用的 waypoint proxy 来解决其 L7 解决，以便调整资源性能来应答高负载。你可以性能服务 B 或 C 经常使用不同的 waypoint，防止遭到服务 A 的影响，或依据须要跳过它。咱们将在上方的局部中详细探讨这一点。

C: 多个命名空间共享一个 Waypoint Proxy

你也可以经过为命名空间参与istio.io/use-waypoint标签，并在 Gateway 资源中性能allowRoutes，来让多个命名空间共享一个 waypoint proxy。假设你运转的是小型集群，想要优化资源效率，并且对喧闹街坊疑问不太担忧，你或许宿愿为整个集群经常使用一个 waypoint proxy。这种状况下的一个经常出现例子是所谓的K8S-at-the-edge[4]。

另一个例子是，一个团队领有几个组成繁多信赖域的命名空间，你宿愿经过共享一个 waypoint proxy 来降落资源老本。在下图中，ns-1 和 ns-2 命名空间中的一切服务都经常使用部署在 ns-1 命名空间中的 waypoint proxy：

由于 ns-2 与 ns-1 共享相反的 waypoint proxy，任何在 ns-1 中部署并附加到整个 waypoint 的战略都会影响两个命名空间。例如，假设你部署了一个附加到整个 waypoint 的AuthorizationPolicy，该战略将在两个命名空间中的一切服务上由 waypoint 口头。

为什么不便捷地为每个节点部署一个 Waypoint Proxy？

只管将 waypoint proxy 性能为上述不同目的地范畴的网关十分好，但你或许会想，为什么不坚持便捷，为每个节点部署一个 waypoint proxy 作为 KubernetesDaemonSet[6]来解决该节点的一切 L7 解决呢？

Waypoint proxy 须要高度可性能，由于运行程序或许有齐全不同的性能要求和运转时自定义。例如，你可以拔出针对特定服务的外部授权战略或 WASM 裁减。一个租户的失误 Envoy 性能或许会造成节点代理解体，影响该节点上的一切上班负载。

此外，须要在 waypoint proxy 上有少量解决的喧闹街坊或许会造成另一个运行程序性能不佳，仅仅由于该运行程序也部署在同一节点上。经过为 waypoint proxy 每个节点部署 Envoy，实践上是强迫节点上的一切运行程序共享相反的缺点域，而不论它们的运行提前或运转时要求。Envoy 没有租户控制，你无法划分其 CPU 或内存来防止喧闹街坊抢占其余运行程序。具备复杂 L7 战略的高流量运行程序将须要更多的 CPU 和 waypoint 的内存。Kubernetes DaemonSet 的资源预留是固定的，无法在不参与一切 waypoint pod 的 CPU 和内存的状况下，依据流量负载水平水平或垂直裁减特定的 DaemonSet pod。老本摊派在此模型中也很艰巨，你无法正确地将 waypoint 惹起的资源老本归因于每个租户。

让咱们经过一个详细的例子来说明。我在两个命名空间中部署了 Bookinfo 运行程序，每个命名空间都有其自动性能的命名空间 waypoint。我将每个命名空间的 waypoint proxy 性能为与各自的productpagepod 共置。在每个命名空间中，我部署了一个便捷的 L7 AuthorizationPolicy，只准许特定命名空间口头 GET 方法：

留意：为繁复起见，省略了源和目的地端的 ztunnel

当我从 Fortio 向第一个命名空间的 productpage 服务发送 6500 RPS 的恳求，并在 3 秒后向第二个命名空间的 productpage 服务发送相反的恳求时，平均照应期间区分为 30.8ms 和 30.4ms，如下图所示：

命名空间 1：经过其 waypoint 向第一个命名空间的 productpage 服务发送 6500 QPS，650 个衔接的 Fortio 测试

命名空间 2：经过其 waypoint 向第二个命名空间的 productpage 服务发送 6500 QPS，650 个衔接的 Fortio 测试

由于两个 Bookinfo 运行程序都有十分大的负载，每个运行程序都有自己的 waypoint proxy 是正当的，这样它们不会相互争抢资源。那么，假设 waypoint proxy 改为按节点部署会怎样？

我可以手动将 waypoint proxy 作为 DaemonSet 部署，经常使用十分复杂的 Envoy 性能。在运转两个 productpage pod 的节点上，waypoint proxy pod 将被两个 productpage pod 经常使用。但是，这须要深化了解 Envoy 性能，这方面我并不长于。一种便捷的测试方法是，将两个命名空间性能为经常使用相反的 waypoint proxy，这关于不须要十分高负载或公用 waypoint proxy 的运行程序是介绍的（参见前面的形式 C 了解更多消息）。留意：关于这种状况，我不介绍形式 C，由于两个 Bookinfo 运行程序的负载十分大。

在确保 ns-1 命名空间中的 waypoint proxy pod 也部署在与两个 productpage pod 相反的节点上后，我启动了一个便捷的更改，将两个命名空间都性能为经常使用 ns-1 命名空间中的 waypoint proxy。这使我能够极速测试一个 waypoint proxy pod，被部署在同一节点上的两个 productpage pod 经常使用，就像我将 waypoint 作为 DaemonSet 部署一样。

当我从 Fortio 负载客户端向第一个命名空间的 productpage 服务发送 6500 RPS 时，平均照应期间从 30ms 参与到了 59ms！在 3 秒后向第二个命名空间的 productpage 发送相反的负载（基本上重复之前的测试，但这次经常使用共享的 waypoint），它报告了 32% 的失误，从之前的 0% 参与了！当它们共享同一节点上的同一个 waypoint proxy 时，对两者的影响有多大！由于两个运行程序在高负载下都变得十分喧闹，waypoint proxy 到达了其自动的 CPU 限度（2 核）和抢先衔接限度[7]（1024），因此许多稍后开局的来自第二个命名空间的恳求以高比例的失误失败。Kubernetes 上班节点依然有短缺的 CPU，在峰值时有约 50% 的 CPU 和 6% 的内存应用率。

命名空间 1：经过共享的 waypoint 向第一个命名空间的 productpage 服务发送 6500 QPS，650 个衔接的 Fortio 测试

命名空间 2：经过共享的 waypoint 向第二个命名空间的 productpage 服务发送 6500 QPS，650 个衔接的 Fortio 测试

这个试验标明，在节点上经常使用相反的 waypoint proxy 共享相反的缺点域，或许很容易在喧闹的街坊下触发缺点场景，而这些可以经过为十分忙碌的租户提供公用的 waypoint 来防止。只管在测试中经常使用了十分喧闹的街坊，但也或许是失误的 Envoy 性能或特定的 Envoy 裁减，在多个租户共享相反的缺点域时触发相似的疑问。

援用链接

[1]Istio Ambient Waypoint Proxy Deployment Model Explained:

[2]Beta:

[3]Bookinfo 运行程序:

[4]K8S-at-the-edge:

[5]Ahmad Al-Masry:

[6]DaemonSet:

[7]抢先衔接限度: