Kubernetes應用管理的難題是什么

這篇文章主要講解了“Kubernetes應用管理的難題是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Kubernetes應用管理的難題是什么”吧！

研發對應用管理的訴求

讓我們來看一下這樣一個 K8s 的 yaml 文件，這個 yaml 文件已經是被簡化過的，但是我們可以看到它仍然還是比較長。

面對這樣一個廣受“復雜”詬病的 YAML 文件，我相信大家都會忍不住想該怎么簡化。

自上而下，我們大致把它們分為三塊：

• 一塊是擴縮容、滾動升級相關的參數，這一塊應該是應用運維的同學比較關心的；

• 中間一塊是鏡像、端口、啟動參數相關的，這一塊應該是開發的同學比較關心的；

• 最后一塊大家可能根本看不懂，通常情況下也不太需要明白，可以把它們理解為 K8s 平臺層的同學需要關心的。

看到這樣一個 yaml 文件，我們很容易想到，只要把里面的字段封裝一下，把該暴露的暴露出來就好了。確實，我們內部就有 PaaS 平臺這么做。

內部的某個 PaaS 平臺精心挑選了部分字段，并做了一個漂亮的前端界面給用戶，只透出給用戶 5 個左右的字段，大大降低了用戶理解 K8s 的心智負擔。然后底層實現用類似模板的方式把用戶這五個字段渲染出來一個完整的 yaml 文件。

突出的字段大概如下圖所示：

不得不說這種方式是非常有效的，針對簡單無狀態的應用，精簡 API 可以大大降低 K8s 的門檻，快速并且高效的對接用戶，PaaS 平臺也順利讓大家使用了起來。同時，我也從一些技術分享中了解到許多其他公司也是用這種類似的方式簡化的 K8s API。

但是當用戶的業務開始大規模對接以后，我們就會自然而然遇到有狀態的復雜應用，用戶就會開始抱怨 PaaS 平臺能力不夠了。比如我們的 Zookeeper 多實例選主、主從切換這些邏輯，在這五個字段里就很難展開了。

歸根結底就是屏蔽大量字段的方式會限制基礎設施本身的能力演進，但是 K8s 的能力是非常強大而靈活的。我們不可能為了簡化而放棄掉 K8s 強大的能力。

就比如當前這個例子，我們很容易想到，針對復雜有狀態的應用，應該通過 K8s 里面的 CRD 和 Operator 來解決。

確實，我們內部對接復雜應用云原生化的時候，也推薦他們編寫 Operator，但是經常出現這樣一段對話。

中間件的工程師跟我們說，我這有個 Zookeeper 該用哪種 K8s 的 Workload 接入啊？我們想了想，K8s 設計如此精妙，自然沒有解決不了的問題，于是我們推薦他們使用 Operator。他們就懵了，說你們搞云原生的這幾年造新詞的能力絕對一流，之前都沒聽說過。

想想也是，業務方理解這些新概念不難，但是真的要自己去上手實現，還是非常困難的。我們自然也覺得業務方更應該專注于他們的業務本身，于是我們不得不幫他們一起寫。

可以看到，我們亟需一個統一的模型去解決研發對應用管理的訴求。

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