基於Kubernetes的服務網格介紹

在Kubernetes和微服務之間，服務網格提供了重要的一層。

服務網格與Kubernetes和微服務結合的必要性

Kubernetes已經解決了容器編排的問題，對於雲原生生態圈來說，剩下的問題是如何使微服務的交付更有效和更有彈性。這個問題可以通過服務網格技術來實現。

近年來，像Istio, Envoy and Linkerd這樣的開源服務網格項目越來越受歡迎。本文主要探討服務網格的基本原理，單個vanilla Kubernetes面臨的挑戰，並介紹了幾種Kubernetes服務網格產品。

什麼是服務網格？

服務網格是一個網絡基礎設施層，應用程序不同部分之間的通訊通過它來控制和可視化。現在的應用往往都是通過這種方式工作的。網絡被分成不同的部分，每個部分都是一個服務，每個服務執行特定的業務功能。

一個服務可能需要從其它服務請求數據才能執行自身的功能。通常，有些服務會因爲請求過量而超載，這就是服務網格有用的地方。服務網格通過把請求從一個服務路由到另外一個服務，來優化不同部分之間的通信。

服務網絡組建包括：

當您使用一個普通的vanilla Kubernetes集羣而不是服務網格時，你將遇到以下的問題：

普通vanilla Kubernetes並不對集羣節點間的流量進行加密，因此，服務之間的通信並不安全。您可以使用TLS證書使得Kubernetes服務之間的通信變得安全。

使用TLS意味着DevOps團隊必須管理和更換證書。此外，您的開發團隊必須將TLS證書集成到每個服務中。

服務網格會加密所有的網絡流量，從而使您的團隊節省了時間。服務網格將TLS邊車插入到每個Kubernetes Pod中，通過控制平面爲您進行證書的更換。

單個vanilla Kubernetes集羣故障排除並不是每次都會給您提供造成問題的根源。例如，對於延遲問題，您必須分析單個服務的數據。然而，這些數據可能與外部服務的通信無關。造成問題的原因，有可能與查詢或者前端應用有關。

要解決這個問題，您必須監控代碼的性能，分析錯誤並且跟蹤應用程序中的每個服務請求。像Istio這樣的服務網格平臺提供了內置的分佈式跟蹤，並且不需要對代碼進行檢測。

服務網格使用代理邊車通過出口和入口路由流量。然後邊車添加請求頭信息，方便請求跟蹤，因此，您不需要分析代碼就能獲得所有請求的跟蹤信息。

當前端需要處理更多流量時，如何更快的精確定位流量瓶頸並擴大前端規模？單純的Kubernetes並不能提供解決方式。另一方面，服務網格提供了內置的度量標準，您可以利用這些度量來實現更先進的負載平衡。

下面的列表回顧了三種目前存在的Kubernetes服務網格產品。列表明確指出了選擇不同服務網格產品時的重要差異。

Istio是一個開源的服務網格，主要用於管理多個服務代理。Istio由Google, IBM和Lyft聯合研發。最開始僅針對Kubernetes部署，後又重新設計以支持所有的微服務平臺。Istio默認與Envoy代理集成。Istio更關注可伸縮性、性能、可移植性和保持鬆散耦合組件的靈活性。

Istio的控制平面使用Go語言編寫。操作人員使用控制平面來組合不同的管理策略，每個控制平面組件都被設計用於不同的應用程序，因此Istio可以與不同的底層數據平面配對使用。

Istio的主要功能包括：

Linkerd是2016年2月發佈的開源服務網格項目，是服務網格家族的第一個產品。平臺的服務網格設計很強大且功能很豐富，可以運行在任何環境。Linkerd基於Finagle庫，用Scala語言編寫。它可以通過擴展，每秒管理數千個請求。

Linkerd的包由一個控制平面和一個代理數據平面組成。Linkerd還有一個由Buoyant支持的商業版。當前Linkerd版本包含服務網格接口（SMI）流量API，此API能夠幫忙您自動化Canary部署和其它的高級交付方法。

Linkerd的主要功能包括：

AWS應用程序網格是一種服務網格解決方案，它簡化了AWS中的微服務監控和管理，使您能夠控制AWS服務（比如ECS、EKS、EC2）之間的通信和網絡流量。此外，應用程序網格使您能夠監視、跟蹤和查看微服務日誌記錄。

您可以在應用程序中部署應用程序網格的數據平面，但控制平面由Amazon管理，用戶無法訪問它。

希望本文能幫助您瞭解什麼是服務網格，以及如何使用這些工具，也希望幫助您確定在哪裏開始您的服務網格之旅。

評估服務網格選型需要全面研究，本文僅介紹了目前存在的三種方式。在決定一個解決方案之前，一定要嘗試不同的選擇，看看哪個最適合您的環境。