Linkerd、Consul、Istio、Kuma、Traefik、AWS App服務網格全方位對比

在討論微服務架構和容器化時,一組經過生產驗證的工具近年來引起了很大關注:服務網格。

確實,微服務架構和Kubernetes(通常是K8S)已迅速成爲可伸縮應用程序的規範,這使得管理服務之間的通信問題成爲熱門話題,並且服務網格成爲一種有吸引力的解決方案。我本人在生產中使用了服務網格,特別是Linkerd,Istio和早期的Ambassador形式。但是,服務網格的作用到底是什麼?最好使用哪一個?您怎麼知道是否應該使用那一個?

要回答這些問題,有助於理解爲什麼開發服務網格。從歷史上看,傳統的IT基礎架構具有作爲整體運行的應用程序。一種服務在一臺服務器上運行;如果需要更多容量,解決方案是通過配置更大的機器來垂直擴展它。

由於達到了這種方法的侷限性,大型科技公司迅速採用了三層架構,將負載均衡器與應用程序服務器和數據庫層分開。儘管該體系結構仍具有一定的可伸縮性,但他們決定將應用程序層分解爲微服務。爲了擴展應用程序,這些服務之間的通信對於監控和保護變得至關重要。

爲了允許服務間通信,這些公司開發了內部庫:Twitter上的Finagle,Netflix上的Hystrix和Google上的Stubby(於2016年成爲gRPC)。這些庫旨在解決微服務架構引起的問題:服務之間的安全性,延遲,監控和負載均衡。但是,將大型庫作爲多種語言作爲依賴項進行管理是複雜且耗時的。

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

什麼是服務網格?

服務網格是用於控制服務之間的通信的軟件基礎結構層。它通常由兩個部分組成:

  • 在數據平面,它處理應用程序近通信。如前所述,通常將其與應用程序一起部署爲一組網絡代理。
  • 在控制平面,這是服務網的“大腦”。控制平面與代理交互以推送配置,確保服務發現並集中可觀察性。

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

  • 連接性
  • 安全
  • 可觀察性

連接性

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

服務網格的主要特徵是負載平衡。通過代理劃分網格的所有服務都允許在服務之間實施負載平衡策略,例如輪詢,隨機請求和最少請求。這些策略是服務網格用來決定哪個副本將接收原始請求的策略,就像您在每個服務前面都裝有很小的負載平衡器一樣。

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

安全

在傳統的微服務體系結構中,服務之間使用未加密的流量進行通信。如今,就安全性而言,未加密的內部流量被認爲是一種不良做法,尤其是對於公有云基礎架構和零信任網絡而言。

除了在無法直接控制硬件的情況下保護客戶端數據的私密性之外,對內部流量進行加密還會在系統出現漏洞的情況下增加一層額外的複雜性。因此,所有服務網格都使用相互TLS(mTLS)加密進行服務間通信,即所有代理間通信。

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

可觀察性

服務網格的目標是使服務間通信具有可見性。通過控制網絡,服務網格可增強可觀察性,提供七層度量,從而在流量達到某些可自定義閾值時自動發出警報。

通常由第三方工具或Jaeger或Zipkin之類的插件支持,此類控件還允許通過注入HTTP頭進行注入跟蹤。

服務網格的好處

創建服務網格是爲了抵消微服務體系結構所帶來的一些運營負擔。那些具有微服務架構經驗的人知道,他們每天需要花費大量的工作來進行操作。要充分利用微服務的潛力,通常需要外部工具來處理集中式日誌記錄,配置管理和可伸縮性機制等。使用服務網格可標準化這些功能及其設置和集成。

尤其是服務網格的可觀察性,提供了極其通用的調試和優化方法。藉助對服務之間的交換的詳盡而完整的可見性,工程師(尤其是SRE)可以更快地解決可能的錯誤和系統配置錯誤。藉助服務網格跟蹤,他們可以跟蹤從請求進入系統(在負載平衡器或外部代理處)到堆棧內部私有服務的請求。他們可以使用日誌記錄來映射請求並記錄每個服務中遇到的延遲。最終深入瞭解系統性能指標。

流量管理提供了強大的可能性,然後才能逐步發佈服務的新版本:

  • 重新路由少量請求。
  • 更好的是,將生產請求到鏡像新版本以通過實時流量測試其行爲。
  • A / B測試任何服務或服務組合。

服務網格簡化了上述所有場景,從而更容易避免或減輕生產中的任何意外情況。

Kubernetes服務網格比較

在許多方面,服務網格是微服務體系結構的終極工具集。他們中的許多人都在頂級容器編排工具之一Kubernetes上運行。我們選擇了當今在Kubernetes上運行的三個主要服務網格:Linkerd(v2),Istio和Consul Connect。我們還將討論其他一些服務網格:Kuma,Traefik Mesh和AWS App Mesh。儘管目前在使用和社區方面不那麼突出,但他們有足夠的希望在這裏進行評論並保持常規狀態。

關於Sidecar代理的快速說明

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

服務網格的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,這是Linkerd的完整重寫,於2018年發佈,並於當年晚些時候重命名了Linkerd v2。Linkerd v2帶來了一些引人注目的改進。由於Buoyant很早就停止了對Linkerd v1的積極開發,因此本文其餘部分中對Linkerd的提及均指v2。

Linkerd是完全開源的,它用Rust編寫的自制代理作爲數據平面,而控制平面依賴於Go編寫。

連接性

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

  • Traefik
  • Nginx
  • GCE
  • Ambassador
  • Gloo
  • Contour
  • Kong

Linkerd中的服務配置文件提供增強的路由功能,爲每個路由提供用戶指標,重試調整和超時設置。至於負載均衡,Linkerd提供自動代理注入,其自己的儀表板以及對Grafana的本地支持。

安全

Linkerd中的mTLS支持非常方便,因爲它的初始設置是自動的,並且它的每日自動密鑰輪換也是自動的。

可觀察性

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

Linkerd可以插入Prometheus實例。

可以通過使用OpenTelemetry(以前稱爲OpenCensus)作爲收集器的插件來啓用跟蹤,而Jaeger可以自己進行跟蹤。

安裝

Linkerd安裝是通過注入sidecar代理完成的,該代理是通過在Kubernetes中的資源中添加註釋來完成的。有兩種方法可以解決此問題:

  • 使用helm。(對於許多人來說,Helm是Kubernetes資源的首選配置和模板管理器。)
  • 安裝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的流量拆分功能通過其符合Service Mesh Interface(SMI)的API公開,已經允許發佈canary版本。但是要使它們自動化和流量管理,您還需要外部工具,例如Flagger。

Flagger是一種漸進式交付工具,它將評估Linkerd所謂的黃金指標:請求量、成功率和等待時間分佈。(最初,Google SRE使用 黃金信號一詞,幷包含第四個信號-飽和度,但Linkerd並未涵蓋該信號,因爲那將需要無法直接訪問的指標(例如CPU和內存使用情況)。)Flagger在拆分流量時會跟蹤這些指標使用反饋迴路;因此,您可以實施自動化的,具有指標功能的金絲雀版本。

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

Linkerd服務網格摘要

優點:

Linkerd受益於其創建者的經驗,兩位曾在內部工具Finagle上工作的前Twitter工程師,後來從Linkerd v1中學習。作爲最早的服務網格之一,Linkerd擁有一個蒸蒸日上的社區(其Slack有5,000多個用戶,還有一個活動的郵件列表和Discord服務器)以及大量的文檔和教程。Linkerd的2.9版已經很成熟,這一點已被Nordstrom,eBay,Strava,Expedia和Subspace等大公司採用。對於Linkerd,Buoyant提供了有償的企業級支持。

缺點:

要使用Linkerd服務網格發揮其全部潛能,有一條相當強的學習曲線。Linkerd僅在Kubernetes容器中受支持(即,沒有基於VM的“通用”模式)。Linkerd Sidecar代理不是Envoy。儘管這確實使Buoyant可以按照自己的意願進行調整,但它消除了Envoy提供的固有可擴展性。這也意味着Linkerd缺少對斷路,延遲注入和速率限制的支持。沒有公開任何特定的API來輕鬆控制Linkerd控制平面。(不過,您可以找到gRPC API綁定。)

自v1以來,Linkerd在可用性和易於安裝方面取得了長足的進步。缺少正式公開的API是一個明顯的遺漏。但是由於有了其他經過深思熟慮的文檔,Linkerd中的開箱即用功能易於測試。

Consul

我們的下一個服務網格競爭者Consul Connect是一個獨特的混合體。HashiCorp的Consul以其分佈式結構的鍵值存儲而聞名,這種存儲已經存在了很多年。在Consul演變爲一整套服務工具之後,HashiCorp決定在其之上構建服務網格:Consul Connect。

確切地說,它具有混合性:

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

像大多數其他服務網格一樣,Consul Connect通過在應用程序pod內注入sidecar代理來工作。在架構方面,Consul Connect基於代理和服務器。開箱即用,Consul Connect旨在使用三臺或五臺服務器作爲StatefulSet指定的Pod Anti-affinity來具有高可用性(HA)。Pod反親和力是確保分佈式軟件系統的Pod不會最終出現在同一節點(服務器)上的做法,從而在任何單個節點發生故障的情況下保證可用性。

連接性

沒有什麼可以使Consul Connect在這一領域脫穎而出。它提供的任何服務網做什麼(這是相當多的),加上層七個特徵爲基於路徑的路由、故障切換和負載均衡。

安全

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

可觀察性

Consul Connect採用最常見的可觀察性方法,將Envoy合併爲Sidecar代理,以提供7層代理功能。將Consul Connect的UI配置爲獲取指標涉及更改內置配置文件,還需要啓用Prometheus之類的指標提供程序。還可以配置一些Grafana儀表板以顯示相關的特定於服務的指標。

安裝

使用Helm圖表將Consul Connect安裝到Kubernetes集羣中:helm repo add hashicorp https://helm.releases.hashicorp.com

values.yaml如果要啓用UI或使Consul Connect模塊注入其sidecar代理,則需要修改默認值: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 Connect由HashiCorp支持;作爲免費增值產品,還有一個具有附加功能的企業版,可提供企業級支持。就開發團隊的經驗而言,Consul是市場上最古老的工具之一。
  • Consul Connect擁有堅實的企業社區,並且衆所周知,它可以在具有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問題之一而聲名狼藉。截至撰寫本文時,bug的未結數量約爲800個,已結bug的數量約爲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資源將很難管理,你將需要管理CRDs-的幾種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倍,它是Web上最受關注的服務網格。

  • 它在GitHub貢獻者同樣超出了Linkerd。Istio支持Kubernetes和VM模式。後者是1.9版的beta版。

缺點:

Istio並非免費,有兩種含義:

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

Istio是技術巨頭齊心協力創建一個開源項目來應對他們所面臨的挑戰的一個很好的例子。整個Istio項目花了一些時間來構造自身(回想起微服務到整體架構的轉變)並解決了許多最初的問題。如今,Istio完全可以滿足人們對服務網格的所有期望,並且可以大大擴展。但是,所有這些可能性都對知識、工作時間和計算資源提出了苛刻的要求,以支持其在生產環境中的使用。

Kuma快速評論

由Kong創建並開放源代碼,Kuma在2020年末達到1.0。在某種程度上,它是響應於第一個服務網格相當沉重且難以操作而創建的。

它的功能列表表明它是非常模塊化的。Kuma背後的想法是將其定位爲與已經在Kubernetes或其他基礎架構上運行的應用程序集成。

  • 在流量管理領域,Kuma提供了常見的服務網格功能,例如故障注入和斷路。
  • 除了服務間mTLS加密之外,還可以通過數據平面代理令牌在Kuma中保護數據平面和控制平面之間的交換。
  • 在Kuma中,通過圍繞度量標準,跟蹤和日誌記錄的不同流量策略定義了可觀察性。
  • 由於Kuma在控制平面的端口5653上運行了自己的DNS解析器,因此可以通過Kuma進行服務發現。
  • Kuma十分強調多網格功能:您可以輕鬆地將多個Kubernetes羣集或VM環境結合到具有其多區域部署類型的常見Kuma羣集中。
  • 對於現有的Kong用戶,Kuma可以輕鬆地與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。(雖然從1.12開始,Azure默認使用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託管,因此它是一項完全託管的服務,這意味着不必擔心資源使用或控制平面可用性。
  • 可以通過Prometheus或AWS X-Ray實現AWS App Mesh中的可觀察性。

該項目不是開源的,不支持SMI,並且在線上沒有太多有關控制平面的HA標準的信息。AWS App Mesh的設置比其他Kubernetes本地服務網格更復雜,並且在線社區很少(Stack Overflow上有24個答案,GitHub上有400個星),但這是因爲用戶必須從AWS支持中受益。

AWS App Mesh與AWS進行了本機集成,從EKS開始,並擴展到其他AWS服務,例如ECS(Fargate)和EC2。與Traefik Mesh不同,它具有多集羣支持。另外,像大多數服務網格一樣,它是基於Envoy注入的,該Envoy是經過大量測試的Sidecar代理。

Kubernetes服務網格比較表

這裏介紹的六個Kubernetes服務網格選項有一些共同點:

  • 協議支持:它們都可與HTTP,HTTP / 2,gRPC,TCP和WebSockets一起使用。
  • 默認情況下,它們在代理之間均具有mTLS形式的基本安全性。
  • 通過設計,服務網格可提供某種形式的負載平衡。
  • 至少這六個工具在其流量管理功能中還至少包括一個請求重試選項。
  • 最後,服務發現是任何服務網格的核心功能。

但是,在服務網格基礎結構,流量管理,可觀察性,部署和其他方面,肯定有一些值得強調的差異。

基礎設施

流量管理

可觀察性

OpenCensus和OpenTracing在2019年合併爲OpenTelemetry,但您可能會發現Linkerd文章涉及OpenCensus,以及Istio和Traefik Mesh文章涉及OpenTracing。

部署方式

注意事項

我們應該使用Kubernetes服務網格嗎?

現在,我們已經瞭解了什麼是服務網格,它們如何工作以及它們之間的衆多差異,我們可以問:我們是否需要服務網格?

這是過去幾年中SRE和雲工程師面臨的一個大問題。實際上,微服務給服務網格可以解決的網絡通信帶來了運營挑戰。但是,在安裝和操作方面,服務網格在大多數情況下會帶來自身的挑戰。

我們可以看到,在許多項目中出現的一個問題是,服務網格在概念驗證階段和生產階段之間存在差距。也就是說,對於公司而言,實現在各個方面都與生產相同的過渡環境是非常罕見的。由於服務網格涉及關鍵基礎架構,因此與規模和邊緣相關的影響可能會帶來部署方面的意外。

服務網格仍在大力發展和改進。對於部署頻率較高的團隊來說,這實際上可能是有吸引力的,這些團隊已經掌握了保持最新版本並可以密切關注雲原生工具的開發週期。

但是,對於其他人而言,服務網格演進的速度可能更是一個陷阱。設置服務網格將很容易,但如果隨後沒有及時維護它。安全補丁可能無法應用,或者即使被記住,也可能以不推薦使用的功能或經過修改的依賴項集的形式帶來計劃外的問題。

就在生產中建立服務網格的人力而言,這也是一筆可觀的成本。任何團隊評估此信息並瞭解服務網格的好處是否會超過初始設置時間,將是一個明智的目標。無論“簡易”演示安裝顯示了什麼,服務網格都是很難的。

簡而言之,服務網格可以解決大規模部署項目中常見的一些問題,但可能會引入其他問題,因此要準備投入時間和精力。在一個假設的基礎結構中,該基礎結構涉及25個微服務,並且每秒要處理5個查詢,我建議至少有一個人(最好是兩個人)專門工作至少一個月,以準備概念證明並驗證關鍵方面,然後再考慮在生產環境中運行它。設置完成後,請預測是否需要頻繁升級-它們將影響基礎架構的核心組件,即網絡通信。

Kubernetes服務網格:可擴展應用程序架構中的(複雜)演進

我們已經瞭解了什麼是服務網格:一套工具,可以應對微服務架構引入的新挑戰。通過流量管理,可觀察性,服務發現和增強的安全性,服務網格可以揭示對應用程序基礎架構的深入瞭解。

市場上有多個參與者,有時是由GAFAM等組織提倡的,在某些情況下,它們是開源的或促進了他們自己的內部工具。儘管有兩種不同的實現類型,但是服務網格將始終具有由代理構成的控制平面(系統的大腦)和數據平面,這些代理將攔截您的應用程序的請求。

回顧三個最大的服務網格(Linkerd,Consul Connect和Istio),我們看到了他們選擇實施的不同策略以及它們帶來的優勢。Linkerd是市場上最古老的服務網格,得益於其在Twitter上的創建者經驗。就HashiCorp而言,它提供企業級的Consul Connect,並具有高水平的專業知識和支持。Istio最初在網絡上引起了足夠的關注,但現在已經發展成爲一個成熟的項目,最終提供了功能完善的平臺。

但是,這些角色遠非僅有這些角色,而是出現了一些鮮爲人知的服務網格:Kuma,Traefik Mesh和AWS App Mesh等。來自Kong的Kuma的創建是爲了使服務網格的想法“簡單”並且可插入任何系統中,而不僅僅是Kubernetes。Traefik Mesh得益於已有的Traefik Proxy的經驗,並做出了避免使用邊車代理的罕見決定。最後但並非最不重要的一點是,AWS決定開發自己的版本的服務網格,但是它依賴可靠的Envoy Sidecar代理。

實際上,服務網格仍然很難實現。儘管服務網格的好處引人注目,但它們的影響卻在兩個方面都截然不同:服務網格的失敗可能使您的微服務無法相互通信,從而可能破壞整個堆棧。一個臭名昭著的例子是:Linkerd版本和Kubernetes版本之間的不兼容性在在線銀行Monzo造成了全面的生產中斷。

儘管如此,整個行業都在圍繞Kubernetes和諸如Microsoft帶頭的SMI之類的計劃進行結構調整,SMI是Kubernetes上服務網格的標準接口。在衆多其他項目中,Cloud Native Computing Foundation(CNCF)擁有基於Envoy的開放服務網格(OSM)計劃,該計劃最初也是由Microsoft引入的。服務網格生態系統仍然很熱鬧,我預測在未來幾年會出現一個冠軍,就像Kubernetes成爲事實上的容器編排工具一樣。

推薦


過早關注基礎設施建設是萬惡之源

Kubernetes入門培訓(內含PPT)

從Ice到Kubernetes容器技術,微服務架構經歷了什麼?


隨手關注或者”在看“,誠摯感謝

本文分享自微信公衆號 - 雲原生技術愛好者社區(programmer_java)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章