比較服務網格：Linkerd 2.x與Istio 1.x

banq發表於2019-03-07

所有垂直行業的組織都在繼續加速採用微服務。這導致容器和客戶/服務通訊的使用量相應爆炸式增長。事實證明，安全，大規模和可觀察地管理這些通訊非常具有挑戰性。這在企業內部造成了越來越多的複雜性和波動性。因此，運營商和開發人員都強烈希望封裝網路的複雜性並將其推入新的網路基礎設施層。目前，處理這些複雜問題的最流行的方法是服務網格。
因此，對於這篇博文，我們將比較和對比兩個流行服務網格Linkerd和Istio的功能集。我們還將探討使用服務網格的引數，以及根據您的用例或體系結構，其他型別的解決方案可能更有意義的場景。

什麼是服務網格？
服務網格是一個專用的基礎設施層，可在微服務架構內進行服務到服務呼叫，可靠，快速和安全。它是可以插入服務的代理網格，完全從業務服務中抽象出網路。簡而言之，服務網格旨在解決開發人員在與遠端端點通訊時面臨的諸多挑戰。

什麼是Istio？
Istio是一個開源服務網格，最初由谷歌，IBM和Lyft開發。該專案於2017年5月公佈，其1.0版本於2018年7月釋出.Istio建立在作為其資料平面的Envoy代理之上。儘管它顯然是目前最流行的服務網格，但它僅用於所有實用目的，僅適用於Kubernetes。

什麼是Linkerd？
 Linkerd最初是用Scala編寫的，旨在基於每個主機進行部署。對其相對較大的記憶體佔用的批評隨後促成了Conduit的開發，這是一種專門針對Kubernetes的輕量級服務網，用Rust和Go編寫。此後，Conduit專案已被摺疊成Linkerd，後者重新推出了Linkerd 2.0。雖然Linkerd 2.x目前特定於Kubernetes，但Linkerd 1.x可以基於每個節點進行部署，因此在需要支援各種環境的情況下使其成為更靈活的選擇。除非另有說明，否則下面的比較是指Linkerd 2.x.

比較特徵和功能
1. 架構
Istio和Linkerd都支援透過流行的邊車模式進行部署，該模式為每個微服務分配一個單獨的代理。微服務不是直接呼叫其他服務，而是連線到本地代理。然後，此代理將呼叫路由到相應的服務例項的代理，該代理又將呼叫傳遞給其本地微服務。這個服務代理網格形成資料平面。在服務網格中，資料平面由控制平面配置和監視，控制平面通常單獨部署。

2.控制平面
控制平面是一組API和工具，用於控制網格中的代理行為。控制平面是使用者指定身份驗證策略，收集度量標準和配置資料平面的整體。
Istio的控制平面由三個部分組成。首先，Pilot負責配置資料平面。接下來，Mixer收集流量指標並響應來自資料平面的各種查詢，例如授權，訪問控制和配額檢查。根據啟用的介面卡，它還可以與日誌記錄和監視系統連線。最後，Citadel允許開發人員基於服務標識而不是網路控制來構建零信任環境。它負責為每個服務分配證書，並且還可以在需要時接受外部證書頒發機構金鑰。

Linkerd的控制平面由一個控制器元件，一個提供管理儀表板的Web元件和一個度量元件組成，該元件由Prometheus和Grafana的修改版本組成。

3. 資料平面
在典型的服務網格中，服務部署被修改為包括專用的邊車代理。服務不是直接透過網路呼叫服務，而是呼叫其本地邊車代理，這反過來又封裝了服務到服務交換的複雜性。服務網格中的互連代理集代表其資料平面。
預設情況下，Istio使用Envoy作為其資料平面，即使它被設計為與其他代理（如Nginx）一起使用。Linkerd提供自己的代理。

4. 平臺支援
雖然Istio 聲稱支援各種環境和框架，但在實踐中，它僅在Kubernetes上得到很好的支援，使其成為較窄的服務網格選項之一。
同樣，Linkerd 2.x目前也需要Kubernetes。但是，Linkerd 1.x仍然廣泛部署並正在積極開發中，旨在執行在許多環境和框架中，包括AWS ECS，DC / OS和Docker。這種更廣泛的環境支援的主要原因是每個[url=https://linkerd.io/1/advanced/deployment/per-host]主機[/url]可以部署 Linkerd 1.x ，這使它可以與不適合邊車部署的環境整合。
每主機部署模型的缺點是單個代理故障將影響多個服務。另一方面，與邊車模型相比，每主機部署導致更低的資源消耗，考慮到Linkerd 1.x的相對較高的資源需求，這是一個重要的考慮因素。

5.支援的協議
Istio和Linkerd 2.x都透過其sidecar代理支援服務之間的HTTP 1.1，HTTP2，gRPC和TCP通訊。Linkerd 1.x不支援TCP連線。

6.實施語言
Istio（控制平面）和Linkerd 2.x都用Go編寫。用於Istio資料平面的代理Envoy是用C ++編寫的，而實現Linkerd 2.x資料平面的代理是用Rust編寫的。Linkerd 1.x是用Scala編寫的。

7.安全性，加密和授權
Istio的控制平面元件提供以下安全功能：

  • Citadel：金鑰和證書管理。
  • Pilot：分發身份驗證策略和安全命名資訊。
  • 混音器：授權和審計的管理。
  • Sidecars：在代理之間實現安全通訊，支援TLS加密。

在撰寫本文時，Linkerd中的自動TLS加密被標記為“實驗性”，並且不支援主機到主機的身份驗證。

8.邊車注入
將邊車新增到部署工件並將其與服務網格控制平面一起註冊的過程稱為“邊車注入”.Entio和Linkerd都支援手動和自動邊車注入。

9. 高可用性
如果配置了多個副本並使用了podAntiAffinity標誌，則Istio支援Kubernetes的高可用性。
Linkerd的高可用性功能目前標記為“實驗性”。

10.監控和跟蹤支援
Istio本身支援Prometheus並與Jaeger整合以進行分散式跟蹤。Linkerd支援Prometheus和Grafana開箱即用，但目前不支援分散式跟蹤。

11.效能
Linkerd 2.x的效能開銷通常低於Istio的效能開銷。在兩個服務網格之間的效能基準測試中，顯示對於由HTTP回聲組成的測試負載，每秒的查詢從基線每秒30-35000次查詢（kqps）下降到10-12 kqps，用於Linkerd和3.2 Istio為-3.9 kqps。


什麼時候服務網格可能是一個壞主意？

您可能不希望考慮使用服務網格來管理微服務架構所帶來的潛在複雜網路挑戰，這有五個主要原因。
1.服務網格是有意見的
服務網格是一種平臺解決方案，因此往往非常自以為是。這意味著您可能會發現自己必須“按照自己的方式工作”而不是對您的業務或技術堆疊最有意義的方式。根據您的具體情況，這項前期投資可能過於昂貴。
同樣，如果控制應用程式和服務如何相互通訊對您的組織來說具有戰略重要性，那麼使用現有的服務網格毫無意義。採用服務網格可以讓您從技術漲潮中受益，但不允許您控制自己的命運。

2.服務網格很複雜
部署服務網格會增加相當大的複雜性。部署需要接收邊車，服務網格需要整合到環境中然後不斷重新配置，並且可能必須重新設計加密。因此，在像Kubernetes這樣的平臺上執行服務網格將要求您不僅成為您選擇的服務網格的專家，而且還要成為平臺的專家。

3.服務網格可能很慢
隨著網格的增長和路由表的大小增加，透過一系列代理路由流量會變得非常緩慢。

4.服務網格更喜歡自包含的藍圖
採用服務網格來跟蹤服務中的請求並不總是像它第一次出現那樣有價值。例如，如果您的微服務環境結合了來自不同團隊的應用程式和服務，那麼當跨越不同工程團隊和業務部門的邊界時，解釋跟蹤可能非常具有挑戰性，更不用說企業或雲提供商了。

5.服務網格適用於開發人員
服務網格專注於戰術開發人員對服務到服務呼叫的關注。它們無助於控制複雜的新興行為，這些行為是以規模和非預期的方式相互互動的應用程式和服務有機地發展而來的。

 

相關文章