Linkerd 2.0迎來更新，向著Kubernetes再進一步
Linkerd社群對自身服務網格平臺進行一輪最新更新，旨在進一步提高開發人員與服務擁有者的效率，同時與持續發展的Kubernetes生態系統實現緊密整合。另外，此次更新還為Linkerd在日益擁擠的服務網格領域中爭取到一些喘息空間。
Bouyant公司CEO兼Linkerd社群初始開發者之一William Morgan表示，2.0版本最重要的特徵就在於基礎程式碼庫進行了完全重寫，且更加註重對服務網格部署的簡化。
此次重寫將控制層由JVM程式語言變更為Go程式語言。Morgan表示，與此前的迭代相比，這輪大規模調整使得Linkerd 2.0“體積更小，而速度更快。”
除了效能優勢之外，轉向Go語言還令Linkerd與Kubernetes生態系統更為接近。Morgan指出，“我們的大多數使用者都身在Kubernetes陣營，因此我們希望儘早解決這個問題。”
Morgan解釋稱，除了與Kubernetes生態系統相結合之外，Go程式語言也“更容易上手”，並將推動這套平臺迎來更為重大的創新。Linkerd與Kubernetes亦同屬於雲原生計算基金會（簡稱CNCF）生態系統中的組成部分。
服務邊掛
該平臺還擁有新的服務邊掛設計，即允許平臺僅執行一項服務，同時在無需配置或程式碼變更的前提下實現自動化觀察、可靠性與執行時診斷。
Morgan解釋道，這種方法與當前的服務網格平臺相反——因為後者採取“全有或全無”的價值主張。他指出，路由是一項部署強度較高的任務，特別是考慮到終端使用者對於雲原生空間往往並不熟悉。
Morgan在描述當前程序時表示，“這是一項重要技術，需要投入大量時間才能學習完成。此外，使用者還必須將相關知識與實際技術結合起來，這明顯會提高使用門檻。”
而對於缺少雲原生工程師或意見領袖的技術支援的服務擁有者而言，這道門檻無疑更高。Morgan指出，“人們並不關心Kubernetes、Docker或者服務網格，他們只是想讓其直接發揮作用。”
在Linkerd 2.0的幫助下，Morgan認為這些服務擁有者能夠使用邊掛方式啟動單一服務，從而簡化過渡流程。“服務擁有者將獲得可靠性、可見性與除錯能力，從而在白天高效運作，並在夜晚安心入睡。”
Morgan指出，此次Linkerd更新能夠在數秒之內完成服務安裝，這一能力與其它服務網格平臺“形成了鮮明的對比。”
服務網格空間
隨著服務網格空間受到越來越多新產品的關注，這種對比也顯得愈發必要。Istio無疑是其中最值得一提的對手，其目前已經得到谷歌、IBM以及Lyft等企業的採用。這套平臺於今年7月迎來了自己的通用版本（1.0）。
考慮到其源自谷歌的身份，Istio當然受到Google Cloud Platform的官方支援，但目前仍未能與Amazon Web Services（簡稱AWS）以及微軟Azure建立官方對接。此外，其亦嚴重依賴於同屬於雲原生基金會的Envoy服務代理平臺。
紅帽公司Istio產品經理Brian Harrington最近解釋稱，Istio與Linkerd之間存在明顯不同，因為前者充當的實際是用於服務網格管理的控制層。其能夠處理Enovy邊掛部署——即將Envoy部署在執行中的容器Pod旁側，並通過同Kubernetes或Apache Mesos等容器編排層平臺的配合實現部署協調。
Harrington同時補充稱，“通過這種流量攔截過程，Istio得以執行其「神奇的」服務元件自動連線能力。”
Linkerd社群此前已經新增過相關支援，允許使用者同時執行Linkerd與Istio——其中的具體方法是將Istio作為Linkerd例項的控制層。
此外，Linkerd的關注重點與HasiCorp的Consul服務網格平臺也比較相似。HashiGroup創始人兼聯席CTO Mitchell Hasimoto最近在採訪當中表示，與Istio相比，Consul無需強制要求使用者接受所有元件即可建立服務網格，這將為組織提供更多選擇。Hashimoto指出，“Istio在Kubernetes中的執行難度更低，但Consul則更具全域性能力。”
未來方向
Morgan認為，儘管目前的服務網格選項越來越多，但Linkerd社群仍將專注於提高平臺的可用性。他指出，憑藉著這一關注重點，Linkerd平臺本身仍將為廣大使用者所喜歡，並預計Linkerd將“比計劃時間更早”由雲原生基金會的“孵化”專案轉變為全面“結業”專案。
Morgan最後總結稱，“對我們來說，需求始終來自專案背後的使用者社群，而這才是我們需要關注的重點所在。”
原文連結：ofollow,noindex" target="_blank">Linkerd 2.0 Update Moves Closer to Kubernetes