Kubernetes運維的訴求是什么

這篇文章主要講解了“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 管理應用的公司和團隊都在自己定義應用。如下所示，我就搜到了兩家公司的應用定義：

應用定義實際上是應用交付/分發不可或缺的部分。但是在具體的實踐中，我們感受到這些內部的應用定義都面臨著如下的問題：

1. 定義是否足夠開放，是否可以復用？

2. 如何與開源生態協作？

3. 如何迭代與演進？

這三個問題帶來的挑戰都是巨大的，我在上文已經提到，一個應用定義需要容易上手，但又不失靈活性，更不能是一個黑盒。應用定義同樣需要跟開源生態緊密結合，沒有生態的應用定義注定是沒有未來的，自然也很難持續的迭代和演進。

讓我們回過頭來重新審視我們面臨的挑戰，歸根結底在于 K8s 的 All in One API 是為平臺提供者設計的，我們不能像下圖左側顯示的一樣，讓應用的研發、運維跟 K8s 團隊一樣面對這一團 API。

一個合理的應用模型應該具有區分使用者角色的分層結構，同時將運維能力模塊化的封裝。讓不同的角色使用不同的 API，正如上圖右側部分。

感謝各位的閱讀，以上就是“Kubernetes運維的訴求是什么”的內容了，經過本文的學習后，相信大家對Kubernetes運維的訴求是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！