原文發表於kubernetes中文社區，爲作者原創翻譯 ，原文地址
更多kubernetes文章，請多關注kubernetes中文社區
目錄
服務網格不是一個新概念，在雲原生時代，服務網格成爲了將運行在Kubernetes之上的微服務連接成爲容器化平臺的一種實現方式。如果沒有服務網格，則每個微服務都需要配置接收（或發送）來自其他微服務的流量。服務網格完全改變了這一點。
有了服務網格，微服務就能夠以可靠，安全和可控制的方式相互通信，而不必進行手動配置，也不必花費大量時間和精力來維護微服務之間的連接。
Kubernetes和服務網格是相互協作的，同時使用服務網格可以很輕鬆地實現更復雜的容器化架構。
有很多方法可以在Kubernetes之上搭建服務網格，在本文中，我們將比較一些常見的可用於建立服務網格的工具，以查看哪種工具更適合自己的業務場景。
AWS App Mesh
現在許多基於Kubernetes的應用程序和微服務都在Amazon Web Services環境中運行，因此很難不談AWS App Mesh。顧名思義，AWS App Mesh是Amazon自研的服務網格，旨在爲Amazon服務創建服務網格層。
作爲Amazon產品，AWS App Mesh選擇與Envoy結合來作爲其服務代理。AWS App Mesh通過創建虛擬服務，可以實現在同一名稱空間( namespace )內服務間的連接通信。這是因爲，AWS環境中的每個微服務都可以找到該虛擬服務，利用其可將通信引導至其他微服務。
AWS App Mesh可以與其他服務（如EKS，Fargate和EC2）的無縫集成是其最大的優勢，但是在使用App Mesh方面也存在一些限制，例如，你不能遷移到App Mesh的外部環境或在多雲環境中使用此服務。
App Mesh還藉助CloudWatch和AWS X-Ray來管理服務網格，這就意味着你可以在AWS 主儀表板上控制管理服務網格。儘管App Mesh不支持授權規則，但也支持諸如mTLS支持和負載均衡之類的安全功能。
Istio
Istio是Kubernetes中最受歡迎的服務網格工具。它最初是爲Lyft開發的，但後來成爲Lyft，Google和IBM的聯合開發項目。考慮到Google是Kubernetes背後的公司，Istio能夠支持Kubernetes中的多種部署類型，也並不奇怪。
與App Mesh相似，Istio也可以使用Envoy作爲其服務代理，但並不僅限於Envoy作爲唯一的入口控制器( ingress controller )。Istio的獨特之處在於它提供了巨大的靈活性，而沒有通常的複雜性。也可以將Istio用於其他容器化平臺，但是它與Kubernetes的無縫集成使其成爲有用的工具。
例如，Istio支持網格擴展和多集羣網格，這兩個功能都是App Mesh和許多其他服務網格工具所沒有的。Istio也可以控制處理流量訪問和負載均衡，甚至還支持故障注入和延遲注入。
使用Istio的唯一缺點是你可能會對它提供的功能感到不知所措。如果你有足夠的資源使用Istio處理服務網格層，那麼Istio可以利用其功能幫助簡化組織最複雜的微服務體系結構。
Linkerd
在Linkerd v2.x版本發佈之前，Linkerd已是一種非常流行的服務網格工具。Kubernetes社區已經很好地集成了Linkerd新版本。並且在2020年4月中旬，Linkerd穩定的2.7.1版本已經發布。
Linkerd完全是作爲獨立的服務網格工具構建的，因此它不依賴Envoy等第三方工具進行管理，內部使用linkerd-proxy作爲服務代理。
Linkerd最近的升級，還包括儀表板改進和針對金絲雀部署的流量拆分功能的可視化。這使其成爲實時監視和編排金絲雀或藍/綠部署的絕佳工具。
Linkerd在保持獨立性的同時，還與入口控制器( ingress controller )保持高度兼容性。實際上，Linkerd能夠與你使用的任何入口控制器一起使用，從而使其在這方面最靈活。要使服務網格與你的應用程序集成在一起，只需要一個簡單的 linkerd inject命令即可。
Linkerd2也經過高度優化，安裝僅需60秒。如果你正在尋找一種具有最佳性能的服務網格工具，那麼可以嘗試一下Linkerd2。作爲非侵入性服務網格工具，Linkerd部署後不需要太多優化。開箱即用的配置足以支持複雜的微服務架構，並且能夠防止重大攻擊。Linkerd通過mTLS加密來增強應用程序安全性
Linkerd的不足是，它目前可能不支持在多雲環境和多集羣網格中創建。
但是，Linkerd也是專門爲Kubernetes開發的工具，當用作Kubernetes實例的服務網格層時，它的功能不會因此降低。此外，它還可以與OpenCensus配合使用，使跟蹤和管理變得非常容易。
Kuma
Kuma使用Envoy作爲服務代理，並支持任何入口控制器。Kuma與Consul Connect非常相似（我們將在下文介紹），但具有一些令人耳目一新的功能。
Kuma不僅可以投入生產，而且還具有功能強大的服務網格工具所期望的功能。它支持與OpenTracing兼容的所有後端，並允許你使用外部CA證書。
不幸的是，此工具仍缺少某些功能。
目前，在Kuma中無法進行基於路徑( path-based )或基於請求頭( header-based )的流量拆分。也不支持流量訪問控制和流量指標等功能。這些功能可能會在以後的更新中引入，但是就目前而言，你必須手動進行代理模板處理才能解決這些工具的不足。
儘管如此，Kuma看起來很有希望成爲服務網格工具。它尚未達到其1.0.0版本（當前爲0.4.0），但是該工具背後的開發人員聽取了社區的意見，並樂於促使其成爲功能強大的服務網格工具。
Consul Connect
HashiCorp的Consul Connect也是一個服務網格工具。Consul Connect可以與Envoy等服務代理一起使用。它還可以與任何入口控制器一起使用，使其成爲最容易集成到現有Kubernetes集羣中的一種服務網格工具。
Consul Connect可在任何Consul環境中無縫運行。不幸的是，它只能在 Consul 環境中工作。
Consul Connect服務網格工具提供了許多方便的功能，還可以與HashiCorp其他產品一起使用。
Consul Connect支持從TCP到gRPC的所有內容，可與Kubernetes，VM和Nomads一起使用。Consul Connect完全支持網格擴展，因此你可以在一個跨多個雲服務和集羣的環境，使用它作爲服務網格層來支持組織內的微服務。
Consul Connect需要改進的一方面是監視。但是，你可以集成Prometheus和Grafana之類的工具來監視數據。你只需要從服務代理中提取數據即可，而不是直接從Consul Connect中提取數據。
Envoy Proxy
以上這些服務網格工具都可以採用Envoy作爲其服務代理。與其他代理工具相比，Envoy確實具有一些優勢，負載均衡是所有這些工具中最突出的優勢。
Envoy自動重試，本地負載均衡和請求屏蔽，使你可以配置流量負載均衡以實現最佳性能。
另一方面，可觀察性使Envoy成爲能夠支持功能強大的網絡的理想解決方案。
總結
以上這些服務網格工具的主要目標是：創建一種雲體系結構，在該體系結構中，微服務能夠以可靠，安全的方式相互通信。好消息是，無論使用哪種工具，你都將能夠實現這一目標。
譯文鏈接： https://caylent.com/a-kubernetes-service-mesh-tool-comparison-for-2020