本文闡述了 Istio Ambient Waypoint Proxy 的多種部署模式，解釋了按節(jié)點(diǎn)部署的弊端，并通過(guò)實(shí)例說(shuō)明了最佳實(shí)踐。

Ambient 模式是 Istio 在 2022 年引入的新型無(wú)邊車(chē)數(shù)據(jù)平面，并于今年 5 月達(dá)到 Beta[2] 狀態(tài)。Istio 社區(qū)正努力在下一個(gè) Istio v1.24 版本中將 Ambient 推向 GA（一般可用）狀態(tài)。Ambient 將 Istio 的功能分為兩個(gè)獨(dú)立的層：安全覆蓋層和第 7 層處理層。在與許多試用 Ambient 的用戶(hù)合作時(shí)，我想澄清關(guān)于 waypoint proxy 的一些常見(jiàn)問(wèn)題和困惑。它是一個(gè)可選的基于 Envoy 的組件，負(fù)責(zé)處理其管理的工作負(fù)載的 L7 事務(wù)。

Waypoint Proxy 的常見(jiàn)部署模式是什么？

理解 Waypoint Proxy

你可以將 waypoint proxy 簡(jiǎn)單地視為一組目的地的網(wǎng)關(guān)，這些目的地可以是來(lái)自一個(gè)或多個(gè)命名空間的一個(gè)或多個(gè)服務(wù)和工作負(fù)載。除了處理集群內(nèi)部的 L7 流量外，它與你的入口或出口網(wǎng)關(guān)沒(méi)有太大區(qū)別。這也是為什么在部署 waypoint proxy 時(shí)需要使用 Kubernetes 的 Gateway 資源的原因。

我非常喜歡 waypoint 架構(gòu)的靈活性，你可以選擇適合自己需求的架構(gòu)。以下是一些常見(jiàn)的模式：

A: 針對(duì)命名空間的 Waypoint Proxy

最常見(jiàn)的模式是，每個(gè)團(tuán)隊(duì)在集群中擁有一個(gè)命名空間，并管理該命名空間內(nèi)的服務(wù)和部署。在這種模式下，我們期望每個(gè)團(tuán)隊(duì)都有自己的 waypoint proxy，供命名空間內(nèi)的服務(wù)使用。按照這種模式，我們將默認(rèn)的 waypoint 部署設(shè)計(jì)為命名空間范圍，供命名空間內(nèi)的所有服務(wù)使用。在下圖中，服務(wù) A、B、C 位于同一命名空間內(nèi)。所有到服務(wù) A、B 或 C 的 Ambient Mesh 客戶(hù)端流量將通過(guò)命名空間的 waypoint proxy，由客戶(hù)端的 ztunnel 進(jìn)行編程。

Istio Ambient Waypoint 代理部署模型

注意：為簡(jiǎn)潔起見(jiàn)，省略了目的地端的 ztunnel

B: 針對(duì)部分服務(wù)的 Waypoint Proxy

如果你不希望到服務(wù) B 的流量經(jīng)過(guò) waypoint proxy 怎么辦？一個(gè)常見(jiàn)的原因是，你只需要對(duì)服務(wù) B 的流量進(jìn)行 L4 層的控制，這樣在調(diào)用它時(shí)就不需要通過(guò) waypoint proxy。例如，你有一個(gè)調(diào)用 MySQL 數(shù)據(jù)庫(kù)服務(wù)的 Web 服務(wù)，只需要對(duì)其進(jìn)行 L4 控制。另一個(gè)例子是，當(dāng)服務(wù)是 “內(nèi)部” 的，只被命名空間內(nèi)的其他服務(wù)調(diào)用，你只需要對(duì)跨命名空間邊界的服務(wù)進(jìn)行授權(quán)策略。例如，在著名的 Bookinfo 應(yīng)用程序 [3] 中，你可以為 productpage 服務(wù)啟用零信任，拒絕除端口 9080 上 GET 方法的流量之外的所有流量。對(duì)于所有內(nèi)部服務(wù)，如 reviews 或 details 服務(wù)，你可以繼續(xù)允許命名空間內(nèi)的所有流量。

另一個(gè)用例是，服務(wù) A 的流量非常大，你希望有一個(gè)專(zhuān)用的 waypoint proxy 來(lái)處理其 L7 處理，以便調(diào)整資源配置來(lái)應(yīng)對(duì)高負(fù)載。你可以配置服務(wù) B 或 C 使用不同的 waypoint，避免受到服務(wù) A 的影響，或根據(jù)需要跳過(guò)它。我們將在下面的部分中詳細(xì)討論這一點(diǎn)。

Istio ambient waypoint 代理部署模型

C: 多個(gè)命名空間共享一個(gè) Waypoint Proxy

你也可以通過(guò)為命名空間添加 istio.io/use-waypoint 標(biāo)簽，并在 Gateway 資源中配置 allowRoutes，來(lái)讓多個(gè)命名空間共享一個(gè) waypoint proxy。如果你運(yùn)行的是小型集群，想要優(yōu)化資源效率，并且對(duì)嘈雜鄰居問(wèn)題不太擔(dān)心，你可能希望為整個(gè)集群使用一個(gè) waypoint proxy。這種情況下的一個(gè)常見(jiàn)例子是所謂的 K8S-at-the-edge[4]。

“當(dāng)應(yīng)用程序跨越太多命名空間時(shí)，使用 waypoint 為多個(gè)命名空間服務(wù)更具資源效率，通過(guò)提升無(wú)邊車(chē)服務(wù)網(wǎng)格的概念，并在不同的命名空間中使用集中式的 L7 功能，而不影響性能和應(yīng)用可用性”，Ahmad Al-Masry[5]，DevSecOps 工程經(jīng)理說(shuō)道。

另一個(gè)例子是，一個(gè)團(tuán)隊(duì)擁有幾個(gè)組成單一信任域的命名空間，你希望通過(guò)共享一個(gè) waypoint proxy 來(lái)降低資源成本。在下圖中，ns-1 和 ns-2 命名空間中的所有服務(wù)都使用部署在 ns-1 命名空間中的 waypoint proxy：

Istio ambient waypoint 代理部署模型

由于 ns-2 與 ns-1 共享相同的 waypoint proxy，任何在 ns-1 中部署并附加到整個(gè) waypoint 的策略都會(huì)影響兩個(gè)命名空間。例如，如果你部署了一個(gè)附加到整個(gè) waypoint 的 AuthorizationPolicy，該策略將在兩個(gè)命名空間中的所有服務(wù)上由 waypoint 執(zhí)行。

為什么不簡(jiǎn)單地為每個(gè)節(jié)點(diǎn)部署一個(gè) Waypoint Proxy？

雖然將 waypoint proxy 配置為上述不同目的地范圍的網(wǎng)關(guān)非常好，但你可能會(huì)想，為什么不保持簡(jiǎn)單，為每個(gè)節(jié)點(diǎn)部署一個(gè) waypoint proxy 作為 Kubernetes DaemonSet[6] 來(lái)處理該節(jié)點(diǎn)的所有 L7 處理呢？

Waypoint proxy 需要高度可配置，因?yàn)閼?yīng)用程序可能有完全不同的性能要求和運(yùn)行時(shí)自定義。例如，你可以插入針對(duì)特定服務(wù)的外部授權(quán)策略或 WASM 擴(kuò)展。一個(gè)租戶(hù)的錯(cuò)誤 Envoy 配置可能會(huì)導(dǎo)致節(jié)點(diǎn)代理崩潰，影響該節(jié)點(diǎn)上的所有工作負(fù)載。

此外，需要在 waypoint proxy 上有大量處理的嘈雜鄰居可能會(huì)導(dǎo)致另一個(gè)應(yīng)用程序性能不佳，僅僅因?yàn)樵搼?yīng)用程序也部署在同一節(jié)點(diǎn)上。通過(guò)為 waypoint proxy 每個(gè)節(jié)點(diǎn)部署 Envoy，實(shí)際上是強(qiáng)制節(jié)點(diǎn)上的所有應(yīng)用程序共享相同的故障域，而不管它們的應(yīng)用延遲或運(yùn)行時(shí)要求。Envoy 沒(méi)有租戶(hù)控制，你無(wú)法劃分其 CPU 或內(nèi)存來(lái)防止嘈雜鄰居搶占其他應(yīng)用程序。具有復(fù)雜 L7 策略的高流量應(yīng)用程序?qū)⑿枰嗟?CPU 和 waypoint 的內(nèi)存。Kubernetes DaemonSet 的資源預(yù)留是固定的，無(wú)法在不增加所有 waypoint pod 的 CPU 和內(nèi)存的情況下，根據(jù)流量負(fù)載水平水平或垂直擴(kuò)展特定的 DaemonSet pod。成本分?jǐn)傇诖四Ｐ椭幸埠芾щy，你無(wú)法正確地將 waypoint 引起的資源成本歸因于每個(gè)租戶(hù)。

讓我們通過(guò)一個(gè)具體的例子來(lái)說(shuō)明。我在兩個(gè)命名空間中部署了 Bookinfo 應(yīng)用程序，每個(gè)命名空間都有其默認(rèn)配置的命名空間 waypoint。我將每個(gè)命名空間的 waypoint proxy 配置為與各自的 productpage pod 共置。在每個(gè)命名空間中，我部署了一個(gè)簡(jiǎn)單的 L7 AuthorizationPolicy，只允許特定命名空間執(zhí)行 GET 方法：

Istio ambient waypoint 代理部署模型

注意：為簡(jiǎn)潔起見(jiàn)，省略了源和目的地端的 ztunnel

當(dāng)我從 Fortio 向第一個(gè)命名空間的 productpage 服務(wù)發(fā)送 6500 RPS 的請(qǐng)求，并在 3 秒后向第二個(gè)命名空間的 productpage 服務(wù)發(fā)送相同的請(qǐng)求時(shí)，平均響應(yīng)時(shí)間分別為 30.8ms 和 30.4ms，如下圖所示：

命名空間 1

命名空間 1：通過(guò)其 waypoint 向第一個(gè)命名空間的 productpage 服務(wù)發(fā)送 6500 QPS，650 個(gè)連接的 Fortio 測(cè)試

命名空間 2

命名空間 2：通過(guò)其 waypoint 向第二個(gè)命名空間的 productpage 服務(wù)發(fā)送 6500 QPS，650 個(gè)連接的 Fortio 測(cè)試

由于兩個(gè) Bookinfo 應(yīng)用程序都有非常大的負(fù)載，每個(gè)應(yīng)用程序都有自己的 waypoint proxy 是合理的，這樣它們不會(huì)相互爭(zhēng)搶資源。那么，如果 waypoint proxy 改為按節(jié)點(diǎn)部署會(huì)怎樣？

我可以手動(dòng)將 waypoint proxy 作為 DaemonSet 部署，使用非常復(fù)雜的 Envoy 配置。在運(yùn)行兩個(gè) productpage pod 的節(jié)點(diǎn)上，waypoint proxy pod 將被兩個(gè) productpage pod 使用。然而，這需要深入了解 Envoy 配置，這方面我并不擅長(zhǎng)。一種簡(jiǎn)單的測(cè)試方法是，將兩個(gè)命名空間配置為使用相同的 waypoint proxy，這對(duì)于不需要非常高負(fù)載或?qū)Ｓ?waypoint proxy 的應(yīng)用程序是推薦的（參見(jiàn)前面的模式 C 了解更多信息）。注意：對(duì)于這種情況，我不推薦模式 C，因?yàn)閮蓚€(gè) Bookinfo 應(yīng)用程序的負(fù)載非常大。

在確保 ns-1 命名空間中的 waypoint proxy pod 也部署在與兩個(gè) productpage pod 相同的節(jié)點(diǎn)上后，我進(jìn)行了一個(gè)簡(jiǎn)單的更改，將兩個(gè)命名空間都配置為使用 ns-1 命名空間中的 waypoint proxy。這使我能夠快速測(cè)試一個(gè) waypoint proxy pod，被部署在同一節(jié)點(diǎn)上的兩個(gè) productpage pod 使用，就像我將 waypoint 作為 DaemonSet 部署一樣。

5_Istio ambient waypoint proxy deployment model ex

當(dāng)我從 Fortio 負(fù)載客戶(hù)端向第一個(gè)命名空間的 productpage 服務(wù)發(fā)送 6500 RPS 時(shí)，平均響應(yīng)時(shí)間從 30ms 增加到了 59ms！在 3 秒后向第二個(gè)命名空間的 productpage 發(fā)送相同的負(fù)載（基本上重復(fù)之前的測(cè)試，但這次使用共享的 waypoint），它報(bào)告了 32% 的錯(cuò)誤，從之前的 0% 增加了！當(dāng)它們共享同一節(jié)點(diǎn)上的同一個(gè) waypoint proxy 時(shí)，對(duì)兩者的影響有多大！由于兩個(gè)應(yīng)用程序在高負(fù)載下都變得非常嘈雜，waypoint proxy 達(dá)到了其默認(rèn)的 CPU 限制（2 核）和 上游連接限制 [7]（1024），因此許多稍后開(kāi)始的來(lái)自第二個(gè)命名空間的請(qǐng)求以高比例的錯(cuò)誤失敗。Kubernetes 工作節(jié)點(diǎn)仍然有充足的 CPU，在峰值時(shí)有約 50% 的 CPU 和 6% 的內(nèi)存利用率。

命名空間 1.2

命名空間 1：通過(guò)共享的 waypoint 向第一個(gè)命名空間的 productpage 服務(wù)發(fā)送 6500 QPS，650 個(gè)連接的 Fortio 測(cè)試

命名空間 2.1

命名空間 2：通過(guò)共享的 waypoint 向第二個(gè)命名空間的 productpage 服務(wù)發(fā)送 6500 QPS，650 個(gè)連接的 Fortio 測(cè)試

這個(gè)實(shí)驗(yàn)表明，在節(jié)點(diǎn)上使用相同的 waypoint proxy 共享相同的故障域，可能很容易在嘈雜的鄰居下觸發(fā)故障場(chǎng)景，而這些可以通過(guò)為非常繁忙的租戶(hù)提供專(zhuān)用的 waypoint 來(lái)避免。雖然在測(cè)試中使用了非常嘈雜的鄰居，但也可能是錯(cuò)誤的 Envoy 配置或特定的 Envoy 擴(kuò)展，在多個(gè)租戶(hù)共享相同的故障域時(shí)觸發(fā)類(lèi)似的問(wèn)題。

引用鏈接

[1] Istio Ambient Waypoint Proxy Deployment Model Explained: https://www.solo.io/blog/istio-ambient-waypoint-proxy-deployment-model-explained/

[2] Beta: https://istio.io/latest/blog/2024/ambient-reaches-beta/

[3] Bookinfo 應(yīng)用程序: https://istio.io/latest/docs/examples/bookinfo/

[4] K8S-at-the-edge: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/kubernetes-on-edge-day/#about

[5] Ahmad Al-Masry: https://www.linkedin.com/in/ahmad-al-masry-9ab90858/

[6] DaemonSet: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

[7] 上游連接限制: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/cluster/v3/circuit_breaker.proto#envoy-v3-api-field-config-cluster-v3-circuitbreakers-thresholds-max-connections