Istio的複雜性導致一些使用者使用Linkerd –thenewstack

服務網格已經引起了很多關注，這是有充分理由的。通過在平臺層提供可靠性，安全性和可觀察性，服務網格可以在Kubernetes應用程式中扮演關鍵任務。

但是應用情況好壞參半：一些從業者報告說，由於它們看起來很複雜，他們避開了採用服務網格，而另一些從業者則報告說，使它們變得易於執行並執行起來。那是什麼呢？服務網格是否過於複雜以至於不值得付出努力，還是準備今天立即採用？

在本文中，我想重點介紹Linkerd，它是Cloud Native Computing Foundation服務網格（和類別的先驅），以強調簡單性而聞名。在日益擁擠的服務網格環境中，Linkerd在這種“ less-is-more”的方法以及在資料平面層使用基於Rust的專用“微代理”的過程中都是獨一無二的。

Linkerd網站列出了相當多的組織在生產環境中執行它，因此我著手與其中的一些人進行交談，並聽聽他們的經驗。為什麼選擇Linkerd，並將其與更復雜的服務網格（例如該領域當前的市場領導者Istio）進行比較？

對於這篇文章，我採訪了來自兩個不同組織的兩名DevOps專業人員。我們討論了他們在生產中執行Linkerd的過程，並在過程中收集了一些有趣的收穫。 大衛Sudia是一個高階的DevOps工程師GoSpotCheck，移動任務管理應用的現場服務團隊，在那裡他領導的運營小組。David在KubeCon + CloudNativeCon NA 2020上發表了有見地的主旨演講，“更大的力量，更少的痛苦：使用CNCF工具構建內部平臺。”

Freddy Andersen是YouMail（視覺語音郵件和垃圾郵件阻止服務）的CIO 。自大流行之前，YouMail團隊一直在進行遠端工作。

到目前為止，我們討論了他們的服務網格之旅，他們很高興分享他們的經驗。雖然我們分開講，但他們的故事有一些驚人的相似之處。他們兩個：

1. 對服務網格有類似的要求
2. 首先嚐試過Istio，但發現它過於複雜
3. 偶然發現了KubeCon的Linkerd展臺，此後一直在轉變。

詳細點選標題見原文。

最後，我向他們徵求他們對當今服務網格生態系統狀態的看法以及對Istio的看法。他們贊同Istio嘗試做很多事情的觀點，儘管這可能對其他組織也有用，但他們想要的是具有針對性，靈活的事情，併為他們選中了所有合適的框。這正是他們在Linkerd中找到的。

當談到Istio時，他們並不是特別受“ FOMO”的困擾，他們與Linkerd分享經驗的熱情充分說明了他們對該專案的支援。