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-routenamespace:?ecommerce spec:hosts:-?products?#?interpreted?as?products.ecommerce.svc.cluster.localhttp:-?match:-?uri:prefix:?"/listv1"-?uri:prefix:?"/catalog"rewrite:uri:?"/listproducts"route:-?destination:host:?products?#?interpreted?as?products.ecommerce.svc.cluster.localsubset:?v2-?route:-?destination:host:?products?#?interpreted?asproducts.ecommerce.svc.cluster.localsubset:?v1相應的DestinationRule可以是：
apiVersion:?networking.istio.io/v1alpha3 kind:?DestinationRule metadata:name:?products spec:host:?productstrafficPolicy:loadBalancer:simple:?RANDOM?#?or?LEAST_CONN?or?ROUND_ROBINsubsets:-?name:?v1labels:version:?v1-?name:?v2labels:version:?v2-?name:?v3labels:version:?v3最后，我們的Gateway：
apiVersion:?networking.istio.io/v1alpha3 kind:?Gateway metadata:name:?cert-manager-gatewaynamespace:?istio-system spec:selector:istio:?ingressgatewayservers:-?port:number:?80name:?httpprotocol:?HTTPhosts:-?"*"有了這三個文件后，一個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容器技術，微服務架構經歷了什么？
隨手關注或者”在看“，誠摯感謝
總結
以上是生活随笔為你收集整理的Linkerd、Consul、Istio、Kuma、Traefik、AWS App服务网格全方位对比的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 关于sklearn下class_weig
- 下一篇： 如何创建强命名程序集（Strong Na