Istio的複雜性揭祕
很長一段時間以來,Istio 一直被批評為出了名的複雜和難以使用。作為一個在這個專案上工作了四年多的人,在 Istio釋出的前兩年我同意這個說法。但是,從Istio 1.3 開始,Istio 社群專注於簡化,現在 Istio 更加精簡和易於使用,尤其是在Istio 1.6或更新版本中。我親自觀察到改進的簡單性和易用性,我們的許多使用者都報告了類似的體驗。
從本質上講,今天的 Istio 更加直接,任何因為早期版本更難使用而避免使用 Istio 的人都應該考慮再看看。
由於 Istio 社群非常關注簡單性,我很自豪地說,現在有了 Istio,簡單的事情變得很容易。讓我從三個具體的例子開始:
1. 一鍵安裝
在 Istio 的早期,我記得我總是需要在 istio.io 中查詢安裝說明。這不是一個簡單的命令要記住。今天,使用者可以使用istioctl install命令輕鬆安裝 Istio ,該命令為他們設定預設配置檔案。此外,使用者可以指定--profile指示不同的配置檔案。很容易記住吧?
Istio 安裝大約需要一分鐘,只安裝了十幾個自定義資源定義(CRD):
2. 分析您的 Istio 資源
早在使用 Istio 的時候,我記得在將一個簡單的留言板應用程式從 Kubernetes 載入到 Istio 服務網格時,花了幾個小時除錯我的 Istio 資源出了什麼問題。現在不會再發生!istioctl analyze會考慮到叢集中的其他 Istio 資源,可以立即告訴我 Istio 資源出了什麼問題。
3. 簡單的安全策略
我們的大多數使用者都在採用服務網格,因為他們的安全或架構團隊要求他們保護微服務通訊。Istio 使這變得非常簡單:網格平臺團隊只需應用身份驗證策略並在具有匹配標籤的任何服務上啟用雙向 TLS。我喜歡這個,因為這意味著服務所有者不需要做任何事情,除了標記他們的部署以要求使用 mTLS 與他們的服務進行所有通訊。您可能認為您可以在沒有服務網格的情況下自己管理所有這些,但是修改您的應用程式程式碼並建立一個自行開發的框架來管理證書分發和輪換會困難得多。
服務網格的複雜性
服務網格資料平面是基礎架構的關鍵元件,當您需要處理雲原生工作負載以及虛擬機器或裸機上的舊工作負載時,它本質上是複雜的。
以安裝過程為例,Istio 專案因提供太多選擇而受到批評。雖然使用 istioctl 安裝 Istio 非常簡單,但我們有些使用者不想在生產中執行 istioctl,因為它需要更新他們的交付管道,他們必須為此尋求額外的批准。一些常用工具,如Helm已經在他們的組織中得到支援,他們可以更容易地利用這些預先批准的工具。此外,我們的一些使用者希望控制平面在他們的叢集之外執行,以便可以由不同的團隊單獨管理,因此外部控制平面是我們提供的另一種安裝方法。因為每個公司或團隊都有很多不同的用例和要求,我認為最好根據使用者的各種要求提供選擇和靈活性,而不是僅僅提供一種使用istioctl install.
Istio 也因其網路 API 的複雜性而受到批評。複雜性部分是由於可用的豐富功能同時為南北流量和東西流量提供一致的 API。有趣的是,在過去的幾年裡,我發現所有這些功能都是使用者努力解決各種挑戰所要求的。應用層組網比較複雜,從邊緣到東西向的流量需要考慮很多場景,例如:
- 你的主機名是什麼?您是在邊緣處終止流量還是使用直通?
- 您使用的是什麼協議和埠?
- 你如何確保你的優勢?
- 您希望如何將流量路由到您的服務?
- 您如何提高服務的彈性?
- 您是否需要故障轉移策略(可能基於位置)?
Istio 的下一步是什麼?
由於有大量使用者投入生產,我們希望確保我們的使用者成功地在全球範圍內大規模執行服務網格。我很高興與 Solo.io 的 Istio 和Gloo Mesh使用者合作,幫助他們大規模採用 Istio,同時將他們的需求也帶到上游 Istio。
隨著 API 變得更加成熟,我們還將標準化我們的 API,並根據角色明確分離我們的 API。社群正在將這些 API 標準化為自己的自定義資源,以便使用者可以輕鬆地配置遙測或擴充套件或代理配置,而無需詢問平臺團隊修改全域性網格配置。
我們將繼續將我們的功能從不太成熟的階段(實驗或 alpha)升級到成熟階段(beta 或穩定)。與其他所有成功的專案一樣,我們希望保持房屋清潔並刪除使用者不感興趣的功能。對於長時間停留在實驗或 alpha 階段的功能尤其如此。我們將繼續使簡單的場景變得簡單,但為我們的使用者啟用複雜的場景。
作者:孫琳
Lin 是 Solo.io 的開源主管。自 2017 年以來,她一直致力於 Istio 服務網格,並在 Istio 技術監督委員會任職。此前,她曾在 Istio 指導委員會任職三年,並在 IBM 擔任高階技術人員和發明大師超過 15 年。她是《Istio Explained 》一書的作者,擁有 200 多項專利。
相關文章
- Slime 2022 展望:把 Istio 的複雜性塞入智慧的黑盒
- Istio的複雜性導致一些使用者使用Linkerd –thenewstack
- 複雜性Complex與複雜Complicated區別 - Sonja
- 解決DDD核心的複雜性
- 如何降低軟體的複雜性?
- 直面不確定性與非線性的複雜現實:邁向複雜性經濟 - Cilliers
- 害怕軟體的複雜嗎?其實複雜性是必須存在的 - ferd
- 揭開C++移動與複製的神祕面紗C++
- 揭祕ThreadLocalthread
- 揭祕instancetype
- 位元組跳動資料平臺技術揭祕:基於 ClickHouse 的複雜查詢實現與優化優化
- 資料複雜性和簡單
- 什麼是 幾何複雜性
- 複雜性是心智殺手 - PhilipK
- 揭祕 YYModel 的魔法(下)
- 「Python實用祕技01」複雜zip檔案的解壓Python
- 揭祕區塊鏈的核心技術之「雜湊與加密演算法 」區塊鏈加密演算法
- 揭祕區塊鏈的核心技術之“雜湊與加密演算法”區塊鏈加密演算法
- 揭祕JavaScript中“神祕”的this關鍵字JavaScript
- 高複雜性下的藍芽安全危機藍芽
- 如何開始複雜性科學的研究? - systemsinnovation
- 外觀模式-簡化子系統的複雜性模式
- 軟體的複雜性正在殺死我們
- 科學論文的可複製性、被引用量和創新性的複雜關係
- 關於管理軟體複雜性的最佳書籍?
- 複雜性系統的戰略分析要點 -Dave
- 談談Bug引起的複雜性“Bug-O” — OverreactedReact
- Kubernetes會不會被自身的複雜性壓垮?
- synchronized底層揭祕synchronized
- 揭祕前端儲存前端
- ReactJS底層揭祕ReactJS
- DDD之理解複雜度、尊重複雜度、掌控複雜度複雜度
- 複雜度分析的套路及常見的複雜度複雜度
- 揭開 Kubernetes 的神祕面紗
- 揭祕webpack外掛的工作原理Web
- 揭開“QUIC”的神祕面紗UI
- 揭祕 Python 中的 enumerate() 函式Python函式
- [譯]Python的enumerate()函式揭祕Python函式