您好,登錄后才能下訂單哦!
這篇文章主要講解了“Kubernetes運維的訴求是什么”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“Kubernetes運維的訴求是什么”吧!
K8s 的 CRD Operator 機制非常靈活而強大,不光是復雜應用可以通過編寫 CRD Operator 實現,我們的運維能力也大量通過 Operator 來擴展,比如灰度發布、流量管理、彈性擴縮容等等。
我們常常贊嘆于 K8s 的靈活性,它讓我們基礎平臺團隊對外提供能力非常方便,但是對應用運維來說,他們要使用我們提供的這些運維能力,卻變得有些困難。
比如我們上線了一個 CronHPA,可以定時設置在每個階段會根據 CPU 調整實例數的范圍。應用運維并不知道跟原生不帶定時功能的 HPA 會產生沖突,而我們也沒有一個統一的渠道幫助管理這么多種復雜的擴展能力,結果自然是引起了故障。這血的教訓提醒我們要做事前檢查,熟悉 K8s 的機制很容易讓我們想到為每個 Operator 加上 admission webhook。
這個 admission webhook 需要拿到這個應用綁定的所有運維能力以及應用本身的運行模式,然后做統一的校驗。如果這些運維能力都是一方提供的還好,如果存在兩方,甚至三方提供的擴展能力,我們就沒有一個統一的方式去獲知了。
事實上如果我們想的更遠一些就會發現,我們需要一個統一的模型來協商并管理這些復雜的擴展能力。
當我們把應用的 Operator 以及對應的運維能力都寫好以后,我們很容易想到要打包交付這個應用,這樣無論是公有云還是專有云都可以通過一個統一的方式去交互。社區的主流方式目前就是使用 Helm 來打包應用,而我們也采用了這樣的方式給我們的用戶交付,但是卻發現我們的用戶需求遠不止于此。
云原生應用有一個很大的特點,那就是它往往會依賴云上的資源,包括數據庫、網絡、負載均衡、緩存等一系列資源。
當我們使用 Helm 打包時,我們只能針對 K8s 原生 API,而如果我們還想啟動 RDS 數據庫,就比較困難了。如果不想去數據庫的交互頁面,想通過 K8s 的 API 來管理,那就又不得不去寫一個 CRD 來定義了,然后通過 Operator 去調用實際云資源的 API。
這一整套交付物實際上就是一個應用的完整描述,即我們所說的“應用定義”。但事實上,我們發現“應用定義”這個東西,在整個云原生社區里其實是缺失的。這也是為什么阿里巴巴內部有很多團隊開始嘗試設計了自己的“應用定義”。
這種定義方式最終所有的配置還是會全部堆疊到一個文件里,這跟 K8s API all-in-one 的問題其實是一樣的,甚至還更嚴重了。而且,這些應用定義最終也都成為了黑盒,除了對應項目本身可以使用,其他系統基本無法復用,自然就更無法使得多方協作復用了。
事實上幾乎每個基于 K8s 管理應用的公司和團隊都在自己定義應用。如下所示,我就搜到了兩家公司的應用定義:
應用定義實際上是應用交付/分發不可或缺的部分。但是在具體的實踐中,我們感受到這些內部的應用定義都面臨著如下的問題:
定義是否足夠開放,是否可以復用?
如何與開源生態協作?
如何迭代與演進?
這三個問題帶來的挑戰都是巨大的,我在上文已經提到,一個應用定義需要容易上手,但又不失靈活性,更不能是一個黑盒。應用定義同樣需要跟開源生態緊密結合,沒有生態的應用定義注定是沒有未來的,自然也很難持續的迭代和演進。
區分使用者的分層模型與模塊化的封裝
讓我們回過頭來重新審視我們面臨的挑戰,歸根結底在于 K8s 的 All in One API 是為平臺提供者設計的,我們不能像下圖左側顯示的一樣,讓應用的研發、運維跟 K8s 團隊一樣面對這一團 API。
一個合理的應用模型應該具有區分使用者角色的分層結構,同時將運維能力模塊化的封裝。讓不同的角色使用不同的 API,正如上圖右側部分。
感謝各位的閱讀,以上就是“Kubernetes運維的訴求是什么”的內容了,經過本文的學習后,相信大家對Kubernetes運維的訴求是什么這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。