繼UK8S后，UCloud再推容器實例Cube，為了誰？

原標題：繼UK8S后，UCloud再推容器實例Cube，為了誰？

又是一年Think in Cloud，疫情原因，形式變了，線上+線下同步進行，但精彩不變。此次大會上，UCloud帶來了眾多最新的產(chǎn)品技術和最佳實踐，一天跟下來，無數(shù)次感嘆，UCloud能在巨頭夾擊的公有云市場存活下來，并且成為公有云上市第一股，絕不是靠運氣，UCloud有兩把刷子。

本文就借著UCloud新產(chǎn)品Cube容器實例（以下簡稱“Cube”）發(fā)布的契機，聊聊UCloud為什么能成功。

談起容器，大家應該不陌生。

伴隨云計算2.0時代的到來，云原生受到空前關注，容器作為云原生最基礎的技術，在短時間也實現(xiàn)了快速普及。來自權威機構的調查數(shù)據(jù)顯示，2019年已有43.9%的用戶采用了容器技術，另外有40.8%的用戶計劃采用容器技術，容器發(fā)展勢頭可以說非常迅猛。與此同時，Kubernetes已成事實上的標準，幾乎一統(tǒng)容器天下。

那么一連串問題就來了，既然Kubernetes大器已成，UCloud為什么還會做Cube這樣一款產(chǎn)品？事實上，UCloud也有Kubernetes的產(chǎn)品UK8S，Cube有什么獨特價值？Cube和UK8S是什么關系？下面我們來一一解答這些問題。

01

Cube，為了讓更多客戶獲益

Kubernetes香歸香，但不是所有用戶都能共享到Kubernetes的技術紅利。為什么這么說？UCloud近兩年的客戶服務歷程可以說就是最好的注解。

UCloud產(chǎn)品經(jīng)理張鵬波在演講中提到一個非常有趣的現(xiàn)象，兩年前他們在和一些客戶溝通時，對方就說想把業(yè)務嵌到Kubernetes中，但兩年過去了，他們還在說著同樣的話。

UCloud很困惑，因為這其中UCloud也做了很多線上線下的技術培訓。但結果依舊很不理想，本質原因究竟是什么？其實就一句話，Kubernetes太復雜了，很多企業(yè)沒有足夠的能力、資源去系統(tǒng)學習、規(guī)劃、全面上Kubernetes。

事實上，這也是自2018年，UCloud推出Kubernetes產(chǎn)品UK8S至今，兩年間服務客戶過程中收到的問題反饋的集中體現(xiàn)。據(jù)張鵬波介紹，用戶對Kubernetes的困惑可以歸納總結為三個方面：

一、Kubernetes體系較為復雜，學習曲線比較陡峭，需要客戶團隊有一定技術儲備，對于已經(jīng)使用容器但尚未嘗試Kubernetes的客戶也是如此，一方面需要了解Kubernetes的技術體系，另一方面需要修改應用架構適配Kubernetes。

二、維護Kubernetes集群會增加額外的負擔，用戶除了管應用還需要管后端資源，并不能實現(xiàn)以應用為中心的業(yè)務管理。

三、Kubernetes會造成資源浪費，因為它是基于虛擬架構建容器，而不是直接建立容器，這也導致應用就緒等待時間較長，并不能完全體現(xiàn)容器敏捷的特性。

所有這些因素促使UCloud下決心研發(fā)一款新的容器產(chǎn)品，讓沒有太強技術能力的企業(yè)也能用上、用好。這款新產(chǎn)品也就是本文要講的Cube。

02

Cube，有什么不一樣

下面來全面認識一下Cube。

先來直觀的看下Kubernetes和Cube的使用流程對比，如下圖，一目了然，Cube相較Kubernetes，省去了三個費時費力的步驟，Kubernetes是先學習，而Cube只需要容器鏡像就能使用。

對Cube有了直觀的認識后，下面再來詳細拆解一下Cube。

簡單理解Cube，它是一個小號的Kubernetes體系。在Cube中，UCloud保留了諸如Kubernetes自動部署調度、快速擴容、故障自愈等便捷用戶使用的功能，去掉、屏蔽了像Kubernetes架構、配置、網(wǎng)絡等的復雜性。

所以，Cube基本上可以理解為一個傻瓜式的平臺，點點鼠標就能完成部署應用。就如張鵬波所說，通過Cube，用戶只需要提供打包好的容器鏡像，即可快速、批量部署容器化應用，而不需要預先購買云主機或UK8S集群。換句話說，無論是技術層面還是成本方面，Cube都能帶來極大的改善。

具體來說，firecracker輕量級虛擬化、cri-o + firecracker-containerd容器管理服務，以及Kubernetes基本調度框架是Cube的基本組成單元。當然，每一部分UCloud都進行了相應的優(yōu)化。

比如，虛擬化層，UCloud對firecracker的kernel/rootfs/init進程等做了充分地精簡優(yōu)化，只保留了最基本的功能，以加快啟動速度，減小安全攻擊面，降低資源消耗。另外，UCloud還在firecracker中內(nèi)置了infra container，使得Cube作為pod運行時可以不必掛載額外的infra容器。

容器管理層，UCloud修改了cri-o管理容器組的架構，采用了單pod對應單shim的模型，這樣可以顯著降低shim資源消耗，簡化容器管理。

調度層，針對Kubernetes，在控制面，UCloud采用了自定義的調度器，可以更好的滿足多租戶場景下任務優(yōu)先級、調度速度、資源管理的需求。在宿主節(jié)點上，鑒于Cube運行的特點，UCloud精簡了一些不需要kubelet實現(xiàn)的功能，例如在宿主上掛載configmap/volume目錄、運行cni插件、收集特定目錄日志等，增強了容器與宿主之間的隔離安全性。

從以上內(nèi)容不難看出，Cube不是基于開源軟件簡單改改而來的一款產(chǎn)品，而是UCloud真正從用戶需求側出發(fā)，一點點打磨出來的一款產(chǎn)品。事實上，這也是UCloud成功的一個決定性因素，以客戶為中心，狠抓產(chǎn)品創(chuàng)新，回顧UCloud的發(fā)展史，這樣的例子不勝枚舉，比如安全屋就是另一個典型。

全面創(chuàng)新使得Cube有著與眾不同的特性，比如：

• 免運維。不需要云主機自然就省去了維護過程，真正讓用戶做到以應用為中心。

• 無操作系統(tǒng)占用。不需要基礎運行環(huán)境，做到申請多少資源，容器就能使用多少資源，能用盡用，按需付費，最大程度減少浪費。

• 更小的規(guī)格。容器可以創(chuàng)建的足夠小，Cube最小規(guī)格可以做到0.1核128Mi，給用戶更細粒度的業(yè)務選擇。

• 虛擬機級別強隔離。firecracker輕量虛擬化技術能使每個容器組之間形成隔離，注意不是進程級別的隔離，提高了容器運行的安全性。

• 按秒付費。Cube實現(xiàn)了用戶只需為容器運行的生命周期進行付費。

Cube值得一提的特性還有很多，比如每個Cube實例都具備獨立的內(nèi)網(wǎng)和外網(wǎng)IP，Cube實例重啟后，內(nèi)網(wǎng)和外網(wǎng)IP保持不變，并且可以作為ULB的后端服務節(jié)點對外暴露服務，提供穩(wěn)定可靠的服務。再比如，Cube目前已支持在創(chuàng)建時直接掛載UFS作為持久存儲，這一點在便利性上甚至比云主機更好。

綜上所述，Cube有兩個關鍵詞：簡化、節(jié)約。為的都是降低門檻，讓更多用戶用上容器這樣先進的技術，享受時代的紅利。

03

承上啟下，Cube的大用處

最后聊一下Cube和Kubernetes的關系。

前面提到了Cube的調度層用的也是Kubernetes，只不過做了一些改造，所以Cube和Kubernetes的關系其實很簡單，Cube可以向上對接Kubernetes。在UCloud內(nèi)部，Cube被定義為一個承上啟下的產(chǎn)品。

對下，Cube可以讓在技術、支出方面有顧慮的客戶用起來，向上，如果客戶容器應用規(guī)模逐步擴大，又可以無縫銜接更加強大的Kubernetes體系。換句話說，UCloud給客戶提供了一種分層建設的路徑。

正因如此，在7月初UCloud將Cube推出公測至今短短幾個月時間，吸引了很多容器的客戶，典型場景如業(yè)務彈性擴縮容，比如達達就屬于此，再比如數(shù)據(jù)采集、轉發(fā)業(yè)務，因為Cube能夠以更小的規(guī)格實現(xiàn)，能夠幫助客戶節(jié)約成本。

張鵬波表示，Cube的適用范圍是很廣的，對于已經(jīng)使用Kubernetes的頭部客戶來說，可以把Cube作為資源池來使用，做彈性擴縮容。對于腰部客戶、小客戶，Cube則可以帶領他們?nèi)腴T，提前享受容器技術的紅利。

總結全文，透過Cube我們不僅看到了UCloud的產(chǎn)品匠心。Cube更像一面鏡子，透過它，能讀懂UCloud的很多。以客戶為中心，不能只關注大客戶的需求，還應該有廣大的中小客戶痛點，這才是UCloud成功的關鍵。未來，Cube還會朝著簡化、節(jié)約的目標再前進，UCloud也將秉承初心，去幫助客戶上云，完成數(shù)字化升級。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。