服務網格大比拼：Istio、Linkerd、Linkerd2和Consul

Linkerd
我在DC / OS上廣泛使用了Linkerd並且非常喜歡它。然而，時代已經發生變化，並且有一些基本問題導致這對Kubernetes來說完全是死路一條。

Linkerd是用JVM語言編寫的，這意味著每個節點代理程式的佔用空間為110mb +記憶體。當你每個主機只執行一個節點代理時，這不是太糟糕，但是世界正在轉向每個pod代理邊車，我想每個人都意識到這屬於太多的開銷。

Linkerd也不代理TCP請求，也不支援websockets。

應付大規模訪問時，Linkerd擁有絕對驚人的流量控制它也是支援連線叢集外部的兩個服務網格之一。

Linkerd2
Linkerd2使用Golang和Rust完全重寫了Linkerd，專門用於Kubernetes。不幸的是，與每次重寫一樣，你從功能和穩定性的角度看需要再次從頭開始，會繼續領教到一些經驗教訓。

遷移到Rust的資料平板代理側面應該有助於緩解一些錯誤，還解決記憶體問題。它現在還支援所有主要協議，這是向前邁出的一大步。

與其他服務網格設計相比，一個有趣的區別是資料平版和控制平版服務之間的緊密預設耦合。

從功能角度來看還無法和Istio競爭。比如服務網格基本上需要的元件：分散式跟蹤。 這仍處於Linkerd2的規劃階段。

我很難猜測Linkerd2需要多長時間才能從穩定性和功能成熟度角度趕上Istio。這可能需要數年時間。

話雖如此，如果你嘗試使用Linkerd2並對功能集感到滿意，那麼這對未來來說似乎是一項很好的投資。許多人討厭Istio的高度複雜性，所以我認為隨著時間的推移，如果它仍然很簡單，這可能會成為最引人注目的選擇。

Consul
Consul的最新版本現在提供了“ connect ”功能，可以在現有群集上啟用。與大多數Hashicorp工具一樣，Consul是一個包含資料和控制平版的Go二進位制檔案。主要的獨特賣點似乎是你可以在Kubernetes上啟用跨服務的連線，並將它們加入到執行Consul的外部vm服務上。這可能對一些組織有吸引力。但是，根據我過去所做的工作，我並不認為這是一個很大的優勢。通常我們讓遺留系統自然死亡，然後處理新專案或將內容遷移到Kubernetes。

Consul確實具有輕微的架構優勢，因為它作為一個完整的網狀網路執行，沒有集中控制平版服務，理論上這是一種效能瓶頸。

layer4和layer7之間也有一個整齊的分離。我認為這種分離可能使Consul服務網格設計變得簡單，同時仍允許分割資料層。如果你需要更多第7層功能，你現在可以使用Envoy切換預設資料層代理。

但是，預設代理功能非常缺乏。要獲得跟蹤支援，或者許多更高階的第7層功能，你需要將代理換成像Envoy這樣的東西。這在網上沒有很好的記錄。

另一個值得關注的部分是控制平版配置。在這一層配置Istio是非常複雜的，我看到Consul有一個簡單的“服務訪問圖”功能。

Hashicorp在部落格上發表了關於區分安全領域的文章。Consul ACL提供主機安全性是一個非常好的功能。特別是如果你想以安全的方式從叢集外部的Kubernetes內部連線pod。代理快取，特別是對於auth，顯然使通訊效能優異。

就像Linkerd2一樣，這是值得關注的。Consul connect僅在幾周前釋出，因此網上的指南並不多。如果你已經對Hashicorp工具鏈進行了高度投資，那麼我將對此進行試用，並瞭解如何使用Envoy替換預設代理。

Istio
Istio穩定且功能豐富。在撰寫本文時，Istio擁有11.5k Github明星，244位貢獻者，並得到Lyft，Google和IBM的支援。Istio開創了許多其他服務網格模擬的想法。

其中一個突出的特點是自動側車注入，它與Helm圖表的效果非常好。

當然有些負面因素與模組化、外掛能力和最終的複雜性有關。你可以切換Istio元件並將其與其他系統整合。這一切都是以陡峭的學習曲線為代價的，並且有足夠的空間來踏坑。

但是，令人驚訝的是，如果你堅持使用預設值，你可以非常快速地啟動並執行Istio。在膝上型電腦上使用minikube，helm和Istio配置測試例項的工作時間不到5分鐘。線上還有數千篇關於如何配置其他整合的文章。這與其他服務網格形成鮮明對比。



獲勝者：Istio
Istio可能是目前最好的服務網格，但複雜性很高，與Kubernetes本身複雜性相比，卻並不是很高。它擁有最多的功能，並在幾個月前推出了第1版和生產版。它還得到了谷歌和大型社群的支援，推出了很酷的部落格和整合。

Ingress - kubedex.com