UCloud優(yōu)刻得為了幫助企業(yè)降低容器和Kubernetes的使用門檻，UCloud優(yōu)刻得在2020年7月份推出一款Serverless容器實例服務Cube，UCloud優(yōu)刻得用戶通過Cube用戶只需要提供打包好的Docker鏡像，即可快速、批量部署容器化應用，并且只需為容器實際運行消耗的資源付費。

　　隨著容器、Kubernetes、Serverless等云原生技術的快速發(fā)展，越來越多的企業(yè)開始擁抱云原生。UCloud優(yōu)刻得使用容器縮短了企業(yè)應用從開發(fā)、構建到發(fā)布、運行的整個生命周期，但由于Docker往往難以獨立支撐起大規(guī)模容器化部署，因此誕生了Kubernetes等容器編排工具。然而Kubernetes的使用體系非常復雜，對于企業(yè)的開發(fā)運維人員而言，需要具備一定的網(wǎng)絡、存儲、系統(tǒng)等方面的技術能力。

　　這樣一款Serverless產(chǎn)品，究竟是如何在技術上實現(xiàn)的呢?就在10月23日剛結束的UCloud優(yōu)刻得TIC2020大會的技術分論壇上，UCloud優(yōu)刻得容器云研發(fā)負責人張苗磊在《UCloud Cube容器技術解析》議題中著重介紹了UCloud優(yōu)刻得 Cube產(chǎn)品背后的技術架構，并且從虛擬化/網(wǎng)絡/存儲等多方面展示無服務器化容器的技術細節(jié)。本文是演講內(nèi)容整理，供大家學習參考。

　　為什么要推出Cube?

　　說到云原生的概念，張苗磊講到，云原生其實對云廠商帶來很大的沖擊，其中一個比較明顯的變化就是用戶需求和云廠商提供的能力之間的變化。

　　在云原生之前，用戶從云廠商購買的是比較基礎的計算能力和服務器資源，用戶需要在此基礎上一層層封裝，最終來實現(xiàn)支撐自己應用服務的能力。而在云原生之后，云廠商則希望提供一種能夠更加向應用靠攏的能力，用戶僅僅需要關心應用，而其他所有的業(yè)務完全都可以交給云廠商來實現(xiàn)。

　　在此基礎上，就很自然的誕生了所有Serverless產(chǎn)品的概念，即用戶不需要再購買具體的服務器資源，而僅僅需要將它應用封裝成一個比較標準的格式傳遞給云廠商，然后調(diào)用云廠商的API來直接運行它的程序，所需要的資源完全按需并且彈性靈活。

　　Serverless的概念在業(yè)界有很多具體的實現(xiàn)，比如容器和K8S就是一個比較好的例子，容器提供了對應用的封裝，而K8S產(chǎn)品提供了對運行環(huán)境的管理。因此近年來包括UCloud優(yōu)刻得在內(nèi)的云廠商都推出了自己的K8S產(chǎn)品，即用戶可以一鍵在云主機內(nèi)構建一個K8S集群，K8S所需的其他能力完全由云廠商的插件來提供。

　　但是在K8S產(chǎn)品的推廣過程中，我們發(fā)現(xiàn)K8S的概念還是比較復雜。用戶在關心其應用的同時還要學習K8S知識，這是有些背離最初云原生提出的，僅以應用為中心的設計目標的。因此我們就想著能否進一步包裝K8S的產(chǎn)品，僅將K8S最小的運行單元pod的概念暴露給用戶，而其他所有的能力完全交給云廠商來實現(xiàn)。在此基礎上，我們想能否將K8S的最小運行單元pod直接暴露出來，而將其他K8S繁瑣的概念統(tǒng)統(tǒng)封裝起來?

　　這樣一來，我們就推出了一款Serverless容器實例服務Cube，Cube對外僅暴露pod的概念，而用戶所需要的鏡像運行命令和其他資源關聯(lián)的關系都可以通過標準的K8S yaml提交給UCloud API。這樣pod就可以輕松直接運行起來，用戶實際所需要負責的，僅僅是pod所需要的資源大小。

　　Cube實現(xiàn)背后的技術原理

　　輕量級運行時

　　我們知道原生的docker實現(xiàn)，由于不能很好的做到資源隔離和租戶隔離，因此無法在云廠商上直接暴露給用戶。于是我們的Cube對docker運行時進行了大量的改造。

　　圖中可以看到標準的虛擬機內(nèi)實現(xiàn)的容器是左邊所示，QEMU提供了虛擬機的隔離能力，而用戶在QEMU虛擬機內(nèi)會部署一個完整的docker或者containerd，并在此基礎上拉起容器。我們在想能否將QEMU和虛擬機的二者能力結合為一起。于是在Cube中我們基于虛擬機實現(xiàn)了容器實例即我們的Cube，對外暴露的是標準的K8S CRI接口，但具體的實現(xiàn)是一個輕量級的虛擬機，用戶實際需要運行的容器是在輕量級的虛擬機內(nèi)拉起的。這樣帶來的好處是Cube融合了虛擬機資源隔離和容器快速啟動的優(yōu)點。

　　當然為了完全的比擬docker，實現(xiàn)的容器快速啟動，我們在性能上也做了很多優(yōu)化，比如將QEMU虛擬機換成了Firecracker輕量級虛擬機，僅實現(xiàn)了最小設備，進一步的降低虛擬化損耗。并且拉起速度能夠降低到100毫秒。

　　當然容器的快速啟動時間，也不僅包括容器啟動的時間，還包括了鏡像拉取的時間。我們在實際的應用推廣過程中，也發(fā)現(xiàn)經(jīng)常會遇到用戶的容器特別大，而導致鏡像拉取時間很長，進而導致啟動速度慢。

　　為了解決這種問題，我們實現(xiàn)了鏡像緩存的功能。即用戶的實際鏡像拉取在第一次拉取中，會緩存在我們的鏡像緩存中心，而后的鏡像加載是直接通過NBD的形式直接掛載到Cube容器里，這樣就可以實現(xiàn)Cube的快速啟動，從而跳過了鏡像拉取的時間。對于特別大的鏡像，用戶也可以選擇預先加載的形式直接加載到我們的鏡像緩存中心，從而進一步降低了啟動時間。

　　網(wǎng)絡實現(xiàn)

　　和標準的docker網(wǎng)絡實現(xiàn)有些不同，我們知道一個Cube的 pod相當于一個虛擬機，因此Cube的pod可以直接利用原先底層SDN網(wǎng)絡為虛擬機提供的能力，實現(xiàn)VPC內(nèi)Cube和VPC內(nèi)所有資源的二層互通，以及不同VPC內(nèi)資源的互相隔離。另外從滿足用戶需求的角度出發(fā)，我們也實現(xiàn)了Cube固定內(nèi)網(wǎng)IP的功能，即在Cube實例更新的過程中，我們可以保持容器pod IP不變。

　　Cube的外網(wǎng)連通性也可以很好利用現(xiàn)有云平臺的網(wǎng)絡架構，對于入向流量，我們可以將Cube掛在ULB背后，利用多個Cube實例實現(xiàn)高可用和彈性伸縮;對于出向流量，我們也可以通過NETGW來實現(xiàn)Cube對外的訪問需求。另外對于需要固定外網(wǎng)IP的情況，我們也可以將單個EIP綁定Cube。

　　存儲實現(xiàn)

　　Cube的存儲也可以很好的對標K8S，主要分為以下幾類：一種是K8S內(nèi)置的Config map Secret和EmptyDir，這些都是作為K8S標準的功能，我們也在Cube實現(xiàn)的CRI中紛紛予以了支持;對于云廠商提供的文件存儲、對象存儲，我們是通過agent的掛載來實現(xiàn)的，其中文件存儲主要是通過agent自動掛載了NFS協(xié)議，而對象存儲是通過agent掛載了S3fuse的協(xié)議;塊存儲是我們改動比較大的地方，為了提高性能，我們改動了Cube所使用的虛擬機IO路徑。通過vhost-user協(xié)議，對接到SPDK實現(xiàn)了Cube上高性能RSSD云盤的掛載。

　　監(jiān)控和日志的實現(xiàn)

　　監(jiān)控和日志這二者的架構比較類似，都是將容器內(nèi)的信息反饋給用戶的一種形式。其中監(jiān)控信息是通過我們自研的Cubelet組件，將監(jiān)控信息匯集后上報給prometheus，最終再轉(zhuǎn)發(fā)給UCloud API的。而日志信息是通過Promtail采集后轉(zhuǎn)發(fā)給Loki Log Cluster集群，再轉(zhuǎn)交給UCloud API，另外對于長期日志，我們還提供了自動轉(zhuǎn)存至對象存儲US3的功能。

　　典型使用場景

　　最后，張苗磊分享了一個 Cube比較典型的使用場景，從這個圖中我們可以看到所有的計算功能都可以通過Cube容器的實例來提供，而入向流量通過ULB來實現(xiàn)，后接的存儲、數(shù)據(jù)庫都可以通過云上原生提供的mysql或者UFS來實現(xiàn)，這樣架構可以很好的提供計算、存儲分離，并且能夠提供快速橫向擴展和彈性資源使用的能力。關于這個架構具體的使用情況可以通過B站觀看詳情。

　　除此之外，Cube在互聯(lián)網(wǎng)削峰場景、數(shù)據(jù)采集、實時音視頻轉(zhuǎn)碼等場景均可以發(fā)揮免服務器運維、秒級啟動、自愈性、秒級計費等多重優(yōu)勢，助力企業(yè)在容器化應用部署過程中進一步降本增效。