Kubernetes 服務網格比較

在討論微服務架構和容器化時，一組經過生產驗證的工具近年來吸引了大部分注意力：服務網格。

事實上，微服務架構和 Kubernetes（通常是風格化的“K8s”）已經迅速成為可擴展應用程序的標準，這使得管理服務之間的通信問題成為熱門話題，而服務網格也是一個有吸引力的解決方案。 我自己在生產中使用過服務網格，特別是 Linkerd、Istio 和早期形式的 Ambassador。 但是服務網格到底是做什麼的呢？ 哪個最好用？ 你怎麼知道你是否應該使用一個？

要回答這些問題，有助於理解為什麼要開發服務網格。 從歷史上看，傳統的 IT 基礎設施的應用程序都是作為單體運行的。 一項服務在一台服務器上運行； 如果它需要更多容量，解決方案是通過配置更大的機器來垂直擴展它。

達到這種方法的極限後，大型科技公司迅速採用了三層架構，將負載均衡器與應用程序服務器和數據庫層分開。 雖然這種架構在一定程度上保持可擴展性，但他們決定將應用程序層分解為微服務。 為了使應用程序擴展，這些服務之間的通信對於監控和保護變得至關重要。

為了實現服務間通信，這些公司開發了內部庫：Twitter 的 Finagle、Netflix 的 Hystrix 和 Google 的 Stubby（2016 年成為 gRPC）。 這些庫旨在解決微服務架構引發的問題：服務之間的安全性、延遲、監控和負載平衡。 但是以多種語言將大型庫作為依賴項進行管理是複雜且耗時的。

最後，這種類型的庫被更易於使用的輕量級代理所取代。 此類代理在外部獨立於應用程序層——對應用程序可能是透明的——並且更易於更新、維護和部署。 於是，服務網格誕生了。

什麼是服務網格？

服務網格是用於控制服務之間通信的軟件基礎設施層； 它通常由兩個組件組成：

1. 數據平面，處理應用程序附近的通信。 通常，這與應用程序一起部署為一組網絡代理，如前所述。
2. 控制平面，是服務網格的“大腦”。 控制平面與代理交互以推送配置、確保服務發現和集中可觀察性。

服務網格圍繞服務間通信具有三個主要目標：

1. 連接性
2. 安全
3. 可觀察性

連接性

服務網格架構的這一方面允許服務發現和動態路由。 它還涵蓋了通信彈性，例如重試、超時、斷路和速率限制。

服務網格的一個主要特性是負載均衡。 由代理網狀的所有服務都允許在服務之間實施負載平衡策略，例如循環、隨機和最少請求。 這些策略是服務網格用來決定哪個副本將接收原始請求的策略，就像在每個服務前面都有微型負載均衡器一樣。

最後，服務網格以流量轉移和鏡像的形式提供路由控制。

安全

在傳統的微服務架構中，服務之間通過未加密的流量進行通信。 如今，未加密的內部流量在安全性方面被認為是一種不好的做法，尤其是對於公共雲基礎設施和零信任網絡。

除了在無法直接控制硬件的情況下保護客戶端數據的隱私之外，加密內部流量還增加了一個受歡迎的額外複雜性，以防系統遭到破壞。 因此，所有服務網格都使用雙向 TLS (mTLS)加密進行服務間通信，即所有代理間通信。

服務網格甚至可以強制執行複雜的授權策略矩陣，根據針對特定環境和服務的策略允許或拒絕流量。

可觀察性

服務網格的目標是為服務間通信帶來可見性。 通過控製網絡，服務網格強制實施可觀察性，提供第七層指標，這反過來又允許在流量達到某個可定制的閾值時自動發出警報。

通常由 Jaeger 或 Zipkin 等第三方工具或插件支持，此類控件還允許通過注入 HTTP 跟踪標頭進行跟踪。

服務網格的好處

創建服務網格是為了抵消微服務架構造成的一些操作負擔。 那些在微服務架構方面有經驗的人都知道，他們每天都需要做大量的工作。 充分利用微服務的潛力通常需要外部工具來處理集中式日誌記錄、配置管理和可擴展性機制等。 使用服務網格可以標準化這些功能，以及它們的設置和集成。

特別是服務網格可觀察性提供了極其通用的調試和優化方法。 由於對服務之間交換的精細和完整的可見性，工程師（尤其是 SRE）可以更快地排除可能的錯誤和系統錯誤配置。 通過服務網格跟踪，他們可以跟踪從進入系統（在負載均衡器或外部代理）到堆棧內的私有服務的請求。 他們可以使用日誌記錄來映射請求並記錄它在每個服務中遇到的延遲。 最終結果：詳細了解系統性能。

在升級到服務的新版本的完整版本之前，流量管理提供了強大的可能性：

1. 重新路由一小部分請求。
2. 更好的是，將生產請求鏡像到新版本，以通過實時流量測試其行為。
3. A/B 測試任何服務或服務組合。

服務網格簡化了上述所有場景，使其更容易避免和/或減輕生產中的任何意外。

Kubernetes 服務網格比較

在許多方面，服務網格是微服務架構的終極工具集； 它們中的許多都在頂級容器編排工具之一 Kubernetes 上運行。 我們選擇了今天在 Kubernetes 上運行的三個主要服務網格：Linkerd (v2)、Istio 和 Consul Connect。 我們還將討論其他一些服務網格：Kuma、Traefik Mesh 和 AWS App Mesh。 雖然目前在使用和社區方面不太突出，但他們很有希望在這裡進行審查並保持關注。

關於 Sidecar 代理的快速說明

並非所有 Kubernetes 服務網格都採用相同的架構方法，但一種常見的方法是利用 sidecar 模式。 這涉及將代理（sidecar）附加到主應用程序以攔截和調節應用程序的入站和出站網絡流量。 實際上，這是在 Kubernetes 中通過每個應用程序 pod 中的輔助容器完成的，該容器將遵循應用程序容器的生命週期。

服務網格的 Sidecar 方法有兩個主要優點：

• Sidecar 代理獨立於運行時甚至應用程序的編程語言。
  • 這意味著在整個堆棧中，無論在何處使用，都可以輕鬆啟用服務網格的所有功能。
• Sidecar 具有與應用程序相同級別的權限和對資源的訪問權限。
  • Sidecar 可以幫助監控主應用程序使用的資源，而無需將監控集成到主應用程序代碼庫中。

但是 sidecar 是喜憂參半，因為它們直接影響應用程序：

• Sidecar 初始化可能會使應用程序的啟動機制死鎖。
• Sidecar 代理會在您的應用程序之上增加潛在的延遲。
• Sidecar 代理還增加了資源佔用，這可能會在規模上花費大量資金。

鑑於這些優點和缺點，sidecar 方法經常成為服務網格社區中爭論的主題。 也就是說，這裡比較的六個服務網格中有四個使用 Envoy sidecar 代理，而 Linkerd 使用自己的 sidecar 實現； Traefik Mesh 在其設計中不使用邊車。

Linkerd 評論

Linkerd 於 2017 年首次亮相，是市場上最古老的服務網格。 Linkerd v1 由 Buoyant（一家由兩名前 Twitter 工程師創辦的公司）創建，基於 Finagle 和 Netty。

Linkerd v1 被描述為領先於時代，因為它是一個完整的、可用於生產的服務網格。 同時，它在資源使用方面有點沉重。 此外，文檔中的重大差距使得難以在生產中設置和運行。

有了這個，Buoyant 有機會使用完整的生產模型，從中獲得經驗，並應用這種智慧。 結果是 Conduit，該公司於 2018 年發布了完整的 Linkerd 重寫，並在當年晚些時候更名為 Linkerd v2。 Linkerd v2 帶來了一些引人注目的改進； 由於 Buoyant 對 Linkerd v1 的積極開發很久以前就停止了，我們在本文其餘部分提到的“Linkerd”指的是 v2。

完全開源，Linkerd 依賴於用 Rust 編寫的自製代理作為數據平面和用 Go 編寫的源代碼作為控制平面。

連接性

Linkerd 代理具有重試和超時功能，但在撰寫本文時沒有斷路或延遲注入。 入口支持廣泛； Linkerd 擁有與以下入口控制器的集成：

• 特拉菲克
• Nginx
• 普通教育證書
• 大使
• 格洛
• 輪廓
• 孔

Linkerd 中的服務配置文件提供增強的路由功能，提供用戶指標、重試調整和超時設置，所有這些都基於每個路由。 至於負載均衡，Linkerd 提供自動代理注入、自己的儀表板和對 Grafana 的原生支持。

安全

Linkerd 中的 mTLS 支持很方便，因為它的初始設置是自動的，就像它的自動每日密鑰輪換一樣。

可觀察性

開箱即用，Linkerd 統計數據和路由可通過 CLI 觀察。 在 GUI 方面，選項包括預製的 Grafana 儀表板和本機 Linkerd 儀表板。

Linkerd 可以插入 Prometheus 的實例。

可以通過使用 OpenTelemetry（以前稱為 OpenCensus）作為收集器的附加組件啟用跟踪，並由 Jaeger 自己進行跟踪。

安裝

Linkerd 安裝是通過注入一個 sidecar 代理來完成的，這是通過在 Kubernetes 中為您的資源添加註釋來完成的。 有兩種方法可以解決這個問題：

1. 使用 Helm 圖表。 （對於許多人來說，Helm 是 Kubernetes 資源的首選配置和模板管理器。）
2. 安裝 Linkerd CLI，然後使用它將 Linkerd 安裝到集群中。

第二種方法從下載並運行安裝腳本開始：

 curl -sL https://run.linkerd.io/install | sh

從那裡，Linkerd CLI 工具linkerd提供了一個有用的工具包，可幫助安裝 Linkerd 的其餘部分並與應用程序集群和控制平面進行交互。

linkerd check --pre將運行您的 Linkerd 安裝所需的所有初步檢查，提供清晰準確的日誌，說明潛在的 Linkerd 安裝可能無法正常工作的原因。 如果沒有--pre ，此命令可用於安裝後調試。

下一步是通過運行以下命令在集群中安裝 Linkerd：

 linkerd install | kubectl apply -f -

然後，Linkerd 將安裝許多不同的組件，佔用的資源非常少； 因此，他們自己有一種微服務方法：

• linkerd-controller ，它提供了 CLI 和儀表板與之交互的公共 API
• linkerd-identity ，它提供了實現 mTLS 的證書頒發機構
• linkerd-proxy-injector ，它通過改變 pod 的配置來處理代理的注入
• linkerd-web ，它提供了一個儀表板，允許監控部署和 Pod，以及內部 Linkerd 組件

Linkerd 的大部分配置基於CustomResourceDefinitions (CRD)。 這被認為是開發 Kubernetes 附加軟件時的最佳實踐——就像在 Kubernetes 集群中持久安裝插件一樣。

添加分佈式跟踪——由於一些常見的誤解，這可能是也可能不是 Linkerd 用戶實際追求的——需要使用 linkerd-collector 和 linkerd-jaeger 的另一個步驟。 為此，我們將首先創建一個配置文件：

 cat >> config.yaml << EOF tracing: enabled: true EOF

要啟用跟踪，我們將運行：

 linkerd upgrade --config config.yaml | kubectl apply -f -

與任何基於 sidecar 代理的服務網格一樣，您需要修改應用程序代碼以啟用跟踪。 其中大部分只是添加一個客戶端庫來傳播跟踪標頭； 然後需要將它包含在每個服務中。

Linkerd 的流量拆分功能通過其符合服務網格接口 (SMI) 的 API 公開，已經允許金絲雀發布。 但要使它們和流量管理自動化，您還需要像 Flagger 這樣的外部工具。

Flagger 是一種漸進式交付工具，它將評估 Linkerd 所謂的“黃金”指標：“請求量、成功率和延遲分佈”。 （最初，Google SRE 使用術語黃金信號並包括第四個信號——飽和度——但 Linkerd 並未涵蓋它，因為這需要無法直接訪問的指標，例如 CPU 和內存使用情況。）Flagger 在拆分流量時跟踪這些指標使用反饋迴路； 因此，您可以實現自動化和指標感知的金絲雀版本。

在深入研究安裝過程之後，很明顯要讓 Linkerd 服務網格運行並利用通常需要的功能，很容易最終運行至少十幾個服務。 也就是說，與其他服務網格相比，它們中的更多是由 Linkerd 在安裝時提供的。

Linkerd 服務網格總結

優點：

Linkerd 受益於其創建者的經驗，兩位前 Twitter 工程師曾在內部工具 Finagle 上工作，後來從 Linkerd v1 中學習。 作為最早的服務網格之一，Linkerd 擁有一個蓬勃發展的社區（它的 Slack 擁有超過 5,000 名用戶，此外它還有一個活躍的郵件列表和 Discord 服務器）以及大量的文檔和教程。 Linkerd 2.9 版的發布已經成熟，Nordstrom、eBay、Strava、Expedia 和 Subspace 等大公司採用了它就證明了這一點。 來自 Buoyant 的付費企業級支持可用於 Linkerd。

缺點：

要充分發揮 Linkerd 服務網格的潛力，有一個非常強大的學習曲線。 Linkerd 僅在 Kubernetes 容器中受支持（即，沒有基於 VM 的“通用”模式）。 Linkerd sidecar 代理不是 Envoy。 雖然這確實允許 Buoyant 在他們認為合適的時候對其進行調整，但它消除了 Envoy 提供的固有可擴展性。 這也意味著 Linkerd 缺少對斷路、延遲注入和速率限制的支持。 沒有公開特定的 API 來輕鬆控制 Linkerd 控制平面。 （不過，您可以找到 gRPC API 綁定。）

自 v1 以來，Linkerd 在可用性和易於安裝方面取得了長足的進步。 缺乏官方公開的 API 是一個明顯的遺漏。 但多虧了經過深思熟慮的文檔，Linkerd 中的開箱即用功能很容易測試。

領事連接評論

我們的下一個服務網格競爭者 Consul Connect 是一個獨特的混合體。 HashiCorp 的 Consul 以其分佈式架構的鍵值存儲而聞名，該技術已經存在多年。 在 Consul 演變成一整套服務工具之後，HashiCorp 決定在其之上構建一個服務網格：Consul Connect。

確切地說，它的混合性質：

Consul Connect 數據平面基於 Envoy，它是用 C++ 編寫的。 Consul Connect 的控制平面是用 Go 編寫的。 這是由鍵值存儲 Consul KV 支持的部分。

與大多數其他服務網格一樣，Consul Connect 通過在應用程序 pod 中註入 sidecar 代理來工作。 在架構方面，Consul Connect 是基於代理和服務器的。 開箱即用，Consul Connect 旨在使用三或五台服務器作為指定 pod 反關聯性的StatefulSet來實現高可用性 (HA)。 Pod 反親和性是確保分佈式軟件系統的 Pod 不會最終位於同一節點（服務器）上的做法，從而保證在任何單個節點發生故障時的可用性。

連接性

Consul Connect 在這一領域脫穎而出的原因並不多。 它提供了任何服務網格的功能（相當多），以及用於基於路徑的路由、流量轉移和負載平衡的第七層功能。

安全

與其他服務網格一樣，Consul Connect 提供基本的 mTLS 功能。 它還具有 Consul 和 Vault 之間的本地集成（也由 HashiCorp 提供），可用作 CA 提供程序來管理和簽署集群中的證書。

可觀察性

Consul Connect 採用最常見的可觀察性方法，將 Envoy 合併為 sidecar 代理以提供第七層功能。 配置 Consul Connect 的 UI 以獲取指標涉及更改內置配置文件並啟用像 Prometheus 這樣的指標提供程序。 還可以配置一些 Grafana 儀表板以顯示相關的特定於服務的指標。

安裝

Consul Connect 使用 Helm 圖表安裝到 Kubernetes 集群中：

 helm repo add hashicorp https://helm.releases.hashicorp.com

如果要啟用 UI 或讓 Consul Connect 模塊注入其 sidecar 代理，則需要修改默認values.yaml ：

 helm install -f consul-values.yml hashicorp hashicorp/consul

要諮詢成員並檢查各個節點，Consul 建議exec到其中一個容器中，然後使用 CLI 工具consul 。

要提供 Consul 提供的開箱即用 Web UI，請運行kubectl port-forward service/hashicorp-consul-ui 18500:80 。

Consul Connect 服務網格總結

優點：

• Consul 得到 HashiCorp 的支持； 作為免費增值產品，還有一個帶有附加功能的企業版，可提供企業級支持。 就開發團隊的經驗而言，Consul 是市場上最古老的工具之一。
• Consul 擁有穩固的企業社區，並且以在具有 50,000 個節點的基礎設施上運行而聞名。 此外，它自 2014 年以來一直存在，使其成為相對於市場而言的成熟產品。
• 由於本機支持，Consul Connect 在 VM 內運行良好。
• 使用 Consul Connect，可以實現與頂級科技公司的服務前網格實施一樣深入的應用程序集成。 這要歸功於完整記錄的庫級 API 的公開。

缺點：

• Consul Connect 的學習曲線比其他服務網格更陡峭，並且需要更多調整才能運行可視化儀表板和指標。
• HashiCorp 的文檔並不簡單，讓用戶去挖掘和試驗以正確配置它。
• 流量管理文檔很難找到，並且主要包含指向 Envoy 文檔的鏈接，其中沒有特別提供有關 Consul Connect 流量管理的詳細信息。
• Consul Connect 的 SMI 接口仍處於試驗階段。

對於那些尋求企業級產品的人來說，Consul Connect 可能是一個非常好的選擇。 HashiCorp 以其產品質量而聞名，Consul Connect 也不例外。 與其他服務網格相比，我可以在這裡看到兩個強大的優勢：公司對企業版的強大支持和適用於各種架構（不僅僅是 Kubernetes）的工具。

Istio 評論

2017 年 5 月，谷歌、IBM 和 Lyft 宣布推出 Istio。 當 Istio 進入服務網格工具競賽時，它在技術領域獲得了很好的曝光率。 它的作者在 1.9 版中一直根據用戶反饋添加功能。

Istio 在當時承諾了超越其競爭對手的重要新功能：自動負載平衡、故障注入等等。 這為它贏得了社區的廣泛關注，但正如我們將在下面詳細介紹的那樣，使用 Istio 絕非易事：Istio 被認為投入生產特別複雜。

從歷史上看，Istio 項目在源代碼更改方面經常出現反彈。 一旦為控制平面採用微服務架構，Istio 現在（從 1.5 版開始）又回到了單體架構。 Istio 回歸集中化的理由是，微服務很難讓運維人員監控，代碼庫過於冗餘，而且項目已經達到組織成熟度——不再需要許多小團隊在孤島中工作。

然而，在此過程中，Istio 因擁有最多的開放 GitHub 問題之一而臭名昭著。 在撰寫本文時，該數量約為 800 個未解決問題和約 12,000 個已關閉問題。 雖然問題計數可能具有欺騙性，但在這種情況下，它們確實代表了以前損壞的功能和失控的資源使用方面的有意義的改進。

連接性

與 Consul Connect 和 Linkerd 相比，Istio 在流量管理方面非常強大。 這要歸功於提供了廣泛的子功能：請求路由、故障注入、流量轉移、請求超時、斷路以及控制服務網格的入口和出口流量。 虛擬服務和目標規則的概念使其在流量管理方面非常完整。

然而，所有這些可能性都伴隨著學習曲線，以及對 Kubernetes 集群上這些新資源的管理。

安全

Istio 擁有一整套與安全相關的工具，主要有兩個方面：身份驗證和授權。 Istio 可以在不同的範圍內實施不同級別的策略：特定於工作負載、命名空間範圍或網格範圍。 所有此類安全資源都通過 Istio CRD 進行管理，例如AuthorizationPolicy或PeerAuthentication 。

除了標準的 mTLS 支持之外，Istio 還可以配置為接受或拒絕未加密的流量。

可觀察性

在這裡，Istio 非常先進，開箱即用，有多種遙測技術提供對服務網格的深入洞察。 指標基於四個黃金信號（延遲、流量、錯誤，在某種程度上，飽和度）。

值得注意的是，Istio 為控制平面本身提供了指標。 它還提供分佈式跟踪和訪問日誌，具有與 Jaeger、Lightstep 和 Zipkin 的明確兼容性以啟用跟踪。

沒有原生儀表板，但有官方支持 Kiali 管理控制台。

安裝

安裝就像按照官方步驟一樣簡單。 Istio 也作為 beta 功能原生集成到 GKE 中，但 GKE 使用 Istio 1.4.X，較舊的微服務版本，而不是最新的單體版本。

原生安裝從下載最新版本開始：

 curl -L https://istio.io/downloadIstio | sh -

在cd進入新創建的istio-*文件夾後，您可以將其添加到您的路徑中，以便您可以使用istioctl實用工具：

 export PATH=$PWD/bin:$PATH

從那裡，您可以通過istioctl將 Istio 安裝到您的 Kubernetes 集群：

 istioctl install

這將使用default配置文件安裝 Istio。 istioctl配置文件允許您創建不同的安裝配置並在必要時在它們之間切換。 但是即使在單配置的場景下，你也可以通過修改一些 CRD 來深度定制 Istio 的安裝。

Istio 資源將更難管理，因為您需要管理多種 CRD——至少VirtualService 、 DestinationRule和Gateway以確保流量管理到位。

• VirtualService資源是聲明服務和應用於請求的不同路由規則的配置。
• DestinationRule資源用於對特定於目標的流量策略進行分組和實施。
• 創建Gateway資源來管理入站和出站服務網格流量（即，額外的 Envoy 代理，但在邊緣運行而不是作為邊車。）

語義細節超出了本次審查的範圍，但讓我們看一個快速示例，展示其中的每一個一起工作。 假設我們有一個電子商務網站，其中包含一項名為products的服務。 我們的VirtualService可能如下所示：

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

相應的DestinationRule可以是：

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

最後，我們的Gateway ：

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

有了這三個文件，Istio 安裝就可以處理基本流量了。

Istio 服務網格總結

優點：

• 在不同的服務網格中，Istio 是撰寫本文時擁有最大在線社區的服務網格。 Stack Overflow 的結果是其主要競爭對手的 10 倍以上，它是網絡上最受關注的服務網格； 它的 GitHub 貢獻者同樣比 Linkerd 高出一個數量級。
• Istio 同時支持 Kubernetes 和 VM 模式； 後者在 1.9 版中處於測試階段。

缺點：

• Istio 不是免費的，從兩個方面來說：
  • 在閱讀文檔、設置文檔、使其正常工作和維護文檔所需的時間方面，它的要求很高。 根據基礎設施規模和服務數量，Istio 將需要數周到數月的全職工作才能完全發揮作用並集成到生產中。
  • 它還增加了大量的資源開銷：Envoy 容器每秒每 1,000 個請求 (RPS) 將需要 350 個毫核 (mCPU)。 甚至控制平面本身也會消耗資源。 （以前，資源使用情況很難預測，但經過一些努力， istiod已穩定在使用 1 個 vCPU 和 1.5 GB 內存左右。）
• 與 Linkerd 不同，它沒有本地管理儀表板。
• Istio 需要使用自己的入口網關。
• Istio 控制平面僅在 Kubernetes 容器中受支持（即，與 Istio 的數據平面不同，沒有 VM 模式）。

Istio 是科技巨頭攜手創建開源項目以應對他們都面臨的挑戰的一個很好的例子。 Istio 項目作為一個整體花費了一些時間來構建自身（回顧微服務到單體架構的轉變）並解決其許多初始問題。 今天，Istio 完全可以滿足人們對服務網格的期望，並且可以大大擴展。 但所有這些可能性都伴隨著對知識、工作時間和計算資源的苛刻要求，以支持其在生產環境中的使用。

隈研吾快速回顧

由 Kong 創建然後開源的 Kuma 在 2020 年底達到了 1.0。在某種程度上，它是為了應對第一個服務網格相當重且難以操作的情況而創建的。

它的功能列表表明它非常模塊化； Kuma 背後的想法是將其導向與已經在 Kubernetes 或其他基礎設施上運行的應用程序的集成。

• 在流量管理領域，Kuma 提供了常見的服務網格功能，例如故障注入和斷路。
• 除了服務間 mTLS 加密之外，數據平面​​和控制平面之間的交換通過數據平面代理令牌在 Kuma 中得到保護。
• 在 Kuma 中，可觀察性是通過圍繞指標、跟踪和日誌記錄的不同流量策略定義的。
• 由於 Kuma 自己的 DNS 解析器在控制平面的端口 5653 上運行，服務發現可以通過 Kuma 獲得。
• Kuma 非常強調多網格功能：您可以輕鬆地將多個 Kubernetes 集群或 VM 環境組合成一個具有多區域部署類型的通用 Kuma 集群。
• Kuma 為現有的 Kong 用戶輕鬆與 Kong Gateway 集成。

Kuma 的通用（非 Kubernetes）版本需要 PostgreSQL 作為依賴項，而 Kong 的 CTO 一直特別反對支持 SMI。 但 Kuma 從一開始就基於多雲和多集群部署的理念而開發，其儀表板反映了這一點。

雖然 Kuma 在服務網格領域還很年輕，到目前為止還很少有生產使用的案例，但它是一個有趣且有前途的競爭者。

Traefik Mesh 快速回顧

Traefik Mesh（由 Traefik Labs 開發）最初名為 Maesh，是服務網格工具競賽中的另一個新人。 項目使命是通過使其易於使用和配置來使服務網格民主化； 開發人員使用經過深思熟慮的 Traefik Proxy 的經驗使他們處於實現這一目標的首要位置。

• Traefik Mesh 中的流量管理功能包括斷路和速率限制。
• 在可觀察性方面，Traefik Mesh 具有原生 OpenTracing 支持和開箱即用的指標（標準安裝自動包括 Prometheus 和 Grafana），從而節省了設置時間。
• 為了安全——除了 mTLS——規範是符合 SMI 的，Traefik Mesh 允許通過訪問控制微調流量權限。

Traefik Mesh 需要在集群上安裝 CoreDNS。 （雖然 Azure 從 1.12 開始默認使用 CoreDNS，但 GKE 在撰寫本文時默認使用 kube-dns，這意味著在這種情況下涉及一個重要的額外步驟。）它還缺乏多集群功能。

也就是說，Traefik Mesh 在我們的服務網格比較中是獨一無二的，因為它不使用邊車注入。 相反，它作為 DaemonSet 部署在所有節點上，充當服務之間的代理，使其具有非侵入性。 總體而言，Traefik Mesh 易於安裝和使用。

AWS App Mesh 快速回顧

在雲提供商的世界中，AWS 是第一個實現可插入 Kubernetes（或特別是 EKS）以及其他服務的本機服務網格的公司。 AWS App Mesh 於 2018 年 11 月發布，從那時起 AWS 一直在對其進行迭代。 AWS App Mesh 的主要優勢在於已有的 AWS 生態系統和市場地位； AWS 背後的大型社區將繼續推動其使用和可用性。

• AWS App Mesh 中的流量管理包括常見功能之上的斷路。
• 由於 AWS App Mesh 由 AWS 託管，因此它是一項完全託管的服務，這意味著不必擔心資源使用或控制平面的可用性。
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

基礎設施

交通管理

可觀察性

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

部署

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.