Kubernetes 複雜嗎？可以不復雜

作為雲原生的核心產品，Kubernetes 提供的編排和管理功能，能輕鬆完成大規模容器部署，但 Kubernetes 自身的複雜性也導致眾多企業一直徘徊於容器服務之外。據調查，只有不足 10% 的使用者表示使用 Kubernetes 時沒有遇到阻礙。

在 2019 年的一個關於容器技術的一個調查資料中，有 40% 的受訪者表示計劃採用容器。然而，據 UCloud 產品經理張鵬波透露說，在他們接觸的使用者當中，曾經在兩年前表示有興趣遷移到容器的使用者，兩年過去了，這些使用者很多依舊“計劃採用”容器服務。

這讓我好奇其中發生了什麼。讓我們一起來探尋一下其中的癥結，以及是否可以將複雜的 Kubernetes變得不復雜。

Kubernetes 複雜嗎？

自從 2017 年，Kubernetes 在容器編排三強爭霸賽中勝出後，就成為了容器編排領域的事實標準，極大的助推了容器技術在業界的發展。作為企業級的容器服務編排系統，Kubernetes 從技術上是現在、乃至未來的主流。

容器擁有很多優點，包括不可變環境、輕量級、快速啟動等優勢；而容器編排系統又在此基礎上更進一步，提供了更加強大的功能，包括自動部署、快速擴容、故障自愈等等。

然而，在這一系列令人神往的優勢和功能背後，Kubernetes 也相應的引入了更多的複雜性。這些複雜性體現在多個方面，比如說：

• 首先是 Kubernetes 架構，本質上，Kubernetes 是用來管理分散式系統的平臺。而一說到分散式，複雜性是不可避免的，管理分散式系統的平臺自然也不例外。
• 另外是容器支援的網路，Kubernetes 支援的網路型別很多。很多使用者對於 Kubernetes 的網路非常疑惑或者說很糾結，當業務要遷移到 Kubernetes 時，選擇什麼型別的網路是一個難以抉擇的問題。特別是在業務遷移上去之後又遇到一些問題的話，排查起來會非常麻煩，這給使用者帶來很大負擔。
• 最後還有就是各種各樣 Kubernetes 元件的配置，這些都是使用者將業務遷移到 Kubernetes 的障礙。

有什麼解決方案嗎？

如上所述，並不是每個使用者都能嚐到桃子的美味的，還有很多渴望遷移到容器環境的使用者被拒之門外。

在這種情況下，全球各家雲服務商，都紛紛推出自己的容器編排服務，在 Kubernetes上構建了自己的 Kubernetes發行版或定製產品。

而作為中國第一家公有云科創板上市公司，UCloud 利用在 UK8S 產品的技術沉澱，推出新的容器管理服務產品 Cube：兩步即可部署容器化應用；採用無伺服器形態，不需要再維護底層基礎設施；按秒後付費，無需預留資源；降低企業部署雲原生產品的學習和技術門檻。

為什麼要推出 Cube？

在容器和 Kubernetes 如火如荼發展的同時，UCloud 發現，在他們的 UK8S 上線大概兩年多的時間裡，之前曾經想把業務遷到 Kubernetes 的使用者。在兩年後的今天，他們還是說這個話，說我很想上 Kubernetes，還需要你們來做技術交流。

UCloud 產品經理張鵬波說：

這讓我們一度很困惑，我們一開始也做了一些嘗試，比如說做了很多線下的培訓、線上的交流，嘗試去推動使用者把他們的業務遷移到 UK8S 裡面來。但是發現這個過程非常緩慢，我們沒有辦法控制和推動使用者的遷移流程。很多公司的業務在快速發展，運維和研發是沒有辦法做架構上的調整的。

發現溝通、培訓這條路實際上是走不通之後的。後來我們想，能不能換一條路，能不能基於 Kubernetes提供這樣一個產品：這個產品只具有 Kubernetes 好處，掩蓋了 Kubernetes 的複雜性，只提供類似於自動部署、快速擴容這樣的特性，而使用者不需要關心底層的 Kubernetes 架構，不需要再操心 Kubernetes 的網路了，也不需要去學習 Kubernetes 的各種 API 了。

Cube 的設計思路

沿著這個思路，UCloud 形成了自己的 Cube 產品。它的設計是從以下幾個方面考慮的：

首先，Kubernetes 裡面哪些功能是會經常會用到的，比如 Deployment 控制多副本容器組的管理， Job 控制任務型容器組，Service 做服務發現，PVC可以用來抽象使用塊儲存以及檔案儲存。這是 Kubernetes 最核心的一些功能。UCloud 在設計 Cube 的時候，希望將這些功能全部保留。這意味著整個 Cube 是基於 Kubernetes 來實現的。把這些複雜性全部遮蔽掉，使用者不需要維護 Kubernetes 叢集，不需要操心 Kubernetes 網路方案，而是由 Cube 提供一個最優網路方案，把容器的網路和虛擬機器的網路扁平化。

其次，把業務遷移到 Kubernetes 的時候，把單體業務變成分散式業務、微服務的時候，使用者一定需要考慮容器日誌的統一收集、統一管理的問題。在 Cube 裡面自動完成了日誌的採集工作，整合了日誌管理工作。另外，對容器環境的監控也是同樣的道理，統一在 Cube 中完成。

當把這些產品全部整合到 Cube 裡以後，Cube 是一個什麼樣的產品形態呢？

首先保證 Kubernetes 最核心的功能，使用者能夠在 Cube 裡面建立 Kubernetes 常用的物件；另外 Cube 的產品形態應該是無伺服器的形式；最後，Cube 引入了輕量級的虛擬化技術，實現了容器組與容器組之間虛擬機器級別的隔離，這樣好處是什麼呢？

我們都知道容器的執行是共享使用宿主機的核心的，存在一定的安全風險，Cube 為每一個容器組實現了一層虛擬機器的封裝，可以使使用者安全的執行容器；同時 UCloud 容器團隊針對虛擬機器的啟動進行了深入最佳化，虛擬機器啟動速度最快只需要 125 毫秒。

Cube 的功能亮點

快速遷移

讓我們橫向對比一下，使用者使用 Kubernetes 和 Cube 的流程上會有哪些區別。

左邊是 Kubernetes，使用者要把業務遷移到 Kubernetes，大概要經過這幾個步驟：

• 第一個步驟學習 Kubernetes，不僅僅是一個人，也可能不僅僅是一個團隊，這個過程可能需要三個月到一年。
• 搭建叢集，考慮叢集的引數配置、叢集的維護工作。
• 然後是做業務映象。
• 之後還要考慮瞭解 Kubernetes的 API 以及 Kubernetes 應用。
• 最後才部署應用。

從 UCloud 觀察到的情況來看，如果是對 Kubernetes非常熟悉的使用者，這個過程可能要一兩個月；但是如果對 Kubernetes 不熟悉，需要半年乃至一年。

使用 Cube 的話，就不再需要學習複雜的 Kubernetes知識了，和建立虛擬機器一樣在 Cube 裡面建立一個應用，全部都是圖形化的方式。所以，Cube 整個流程只有兩步：

• 製作映象。
• 在 Cube 的介面上直接部署應用就好了。

UCloud 產品經理張鵬波說，“我們有幾個使用者知道了 Cube 公測，公測以後第一天進行了解，第二天就把自己部署的業務遷移到 Cube 上來了，一天的時間就可以完成業務遷移的工作。”

成本降低

另外在成本方面，我們知道 Kubernetes 是一個大型的分散式叢集，除了工作節點以外，還有管理節點。管理節點只是用來管理 Kubernetes 支援的應用，這部分開銷實際上從企業角度來看是浪費的。對業務沒有起到正向的作用，所以 Kubernetes 成本會比較高。

而對於 Cube，因為只需要為容器例項來付費，容器用了多少資源就付多少錢，不再考慮管理節點的開銷、資源預留的問題。

更多的便利性

此外，還有一些其他針對 Kubernetes 自身的一些的改進。在 Cube 整個研發過程中，引入了一些亮點。

第一個是映象預熱，我們知道容器的啟動速度其實很快的，基本一秒鐘就能拉起來容器例項。但是這是熱啟動的情況，就是說工作節點上有這個映象時，拉起來速度是很快的。而在冷啟動的情況下，如果虛擬機器上沒有對應的映象時，並且映象非常大時，這個過程就非常緩慢了。我們遇到過最大的映象有 20G 以上，容器的啟動的時間就要花費幾分鐘。這樣，容器本來說快速啟動的優勢就沒有了，比虛擬機器還慢了。所以，UCloud 在研發 Cube 的時候，使用了映象預熱的技術，把容器映象變成 MBD 裝置，在容器啟動的時候，把它納入到啟動容器的節點上去，省去了映象拉起的時間，讓容器冷啟動的時間從以前需要十幾分鍾變成現在只要幾秒鐘就拉起來了。

另外，因為 Kubernetes 是由谷歌開源的一項方案，很多理念和大部分企業更加超前一點。所以，在這種設計理念下，Kubernetes 每一個容器在重啟以後，容器的 IP 就會變化。而我們知道很多傳統的應用設計上是依賴於固定 IP 的，IP 一旦變化整個應用就會出現一些問題。很多使用者都希望讓容器重啟後 IP 保持不變。這對於特別是有狀態的服務尤為重要。所以，在 Cube 裡面使用了 UCloud 的 EIP 功能，能夠讓使用者容器重啟時其 IP 保持不變。

最後，Cube 要相容原有的運維習慣。傳統上，虛擬機器和 IDC 裡面的物理機在使用體驗上是沒有什麼差別的。有些使用者之前業務部署在虛擬機器，經常需要在出現問題的時候，直接登入到虛擬機器裡面去排錯，檢視一些日誌。所以，為了相容使用者以前使用虛擬機器的習慣，在 Cube 裡面的容器也提供了登入功能，讓使用者在業務出現問題的時候，能夠登入到容器裡去快速排查問題。

結語

說實話，關於 Kubernetes 和各種發行版，我們也看過和研究過不少產品了，但是更多的是葉公好龍，沒有將自己的應用遷移到 Kubernetes上的想法。一方面對著 Kubernetes 的各種先進特性饞涎欲滴，另外一方面卻擔心沒有足夠的精力面對全新的技術變化帶來的挑戰。

不過，今天看到 UCloud 的 Cube 產品，我決定要去親自試試這個桃子的味道了。