UCloud優刻得為了幫助企業降低容器和Kubernetes的使用門檻，UCloud優刻得在2020年7月份推出一款Serverless容器實例服務Cube，UCloud優刻得用戶通過Cube用戶只需要提供打包好的Docker鏡像，即可快速、批量部署容器化應用，并且只需為容器實際運行消耗的資源付費。
隨著容器、Kubernetes、Serverless等云原生技術的快速發展，越來越多的企業開始擁抱云原生。UCloud優刻得使用容器縮短了企業應用從開發、構建到發布、運行的整個生命周期，但由于Docker往往難以獨立支撐起大規模容器化部署，因此誕生了Kubernetes等容器編排工具。然而Kubernetes的使用體系非常復雜，對于企業的開發運維人員而言，需要具備一定的網絡、存儲、系統等方面的技術能力。
這樣一款Serverless產品，究竟是如何在技術上實現的呢?就在10月23日剛結束的UCloud優刻得TIC2020大會的技術分論壇上，UCloud優刻得容器云研發負責人張苗磊在《UCloud Cube容器技術解析》議題中著重介紹了UCloud優刻得 Cube產品背后的技術架構，并且從虛擬化/網絡/存儲等多方面展示無服務器化容器的技術細節。本文是演講內容整理，供大家學習參考。
為什么要推出Cube?
說到云原生的概念，張苗磊講到，云原生其實對云廠商帶來很大的沖擊，其中一個比較明顯的變化就是用戶需求和云廠商提供的能力之間的變化。
在云原生之前，用戶從云廠商購買的是比較基礎的計算能力和服務器資源，用戶需要在此基礎上一層層封裝，最終來實現支撐自己應用服務的能力。而在云原生之后，云廠商則希望提供一種能夠更加向應用靠攏的能力，用戶僅僅需要關心應用，而其他所有的業務完全都可以交給云廠商來實現。
在此基礎上，就很自然的誕生了所有Serverless產品的概念，即用戶不需要再購買具體的服務器資源，而僅僅需要將它應用封裝成一個比較標準的格式傳遞給云廠商，然后調用云廠商的API來直接運行它的程序，所需要的資源完全按需并且彈性靈活。
Serverless的概念在業界有很多具體的實現，比如容器和K8S就是一個比較好的例子，容器提供了對應用的封裝，而K8S產品提供了對運行環境的管理。因此近年來包括UCloud優刻得在內的云廠商都推出了自己的K8S產品，即用戶可以一鍵在云主機內構建一個K8S集群，K8S所需的其他能力完全由云廠商的插件來提供。
但是在K8S產品的推廣過程中，我們發現K8S的概念還是比較復雜。用戶在關心其應用的同時還要學習K8S知識，這是有些背離最初云原生提出的，僅以應用為中心的設計目標的。因此我們就想著能否進一步包裝K8S的產品，僅將K8S最小的運行單元pod的概念暴露給用戶，而其他所有的能力完全交給云廠商來實現。在此基礎上，我們想能否將K8S的最小運行單元pod直接暴露出來，而將其他K8S繁瑣的概念統統封裝起來?
這樣一來，我們就推出了一款Serverless容器實例服務Cube，Cube對外僅暴露pod的概念，而用戶所需要的鏡像運行命令和其他資源關聯的關系都可以通過標準的K8S yaml提交給UCloud API。這樣pod就可以輕松直接運行起來，用戶實際所需要負責的，僅僅是pod所需要的資源大小。
Cube實現背后的技術原理
輕量級運行時
我們知道原生的docker實現，由于不能很好的做到資源隔離和租戶隔離，因此無法在云廠商上直接暴露給用戶。于是我們的Cube對docker運行時進行了大量的改造。
圖中可以看到標準的虛擬機內實現的容器是左邊所示，QEMU提供了虛擬機的隔離能力，而用戶在QEMU虛擬機內會部署一個完整的docker或者containerd，并在此基礎上拉起容器。我們在想能否將QEMU和虛擬機的二者能力結合為一起。于是在Cube中我們基于虛擬機實現了容器實例即我們的Cube，對外暴露的是標準的K8S CRI接口，但具體的實現是一個輕量級的虛擬機，用戶實際需要運行的容器是在輕量級的虛擬機內拉起的。這樣帶來的好處是Cube融合了虛擬機資源隔離和容器快速啟動的優點。
當然為了完全的比擬docker，實現的容器快速啟動，我們在性能上也做了很多優化，比如將QEMU虛擬機換成了Firecracker輕量級虛擬機，僅實現了最小設備，進一步的降低虛擬化損耗。并且拉起速度能夠降低到100毫秒。
當然容器的快速啟動時間，也不僅包括容器啟動的時間，還包括了鏡像拉取的時間。我們在實際的應用推廣過程中，也發現經常會遇到用戶的容器特別大，而導致鏡像拉取時間很長，進而導致啟動速度慢。
為了解決這種問題，我們實現了鏡像緩存的功能。即用戶的實際鏡像拉取在第一次拉取中，會緩存在我們的鏡像緩存中心，而后的鏡像加載是直接通過NBD的形式直接掛載到Cube容器里，這樣就可以實現Cube的快速啟動，從而跳過了鏡像拉取的時間。對于特別大的鏡像，用戶也可以選擇預先加載的形式直接加載到我們的鏡像緩存中心，從而進一步降低了啟動時間。
網絡實現
和標準的docker網絡實現有些不同，我們知道一個Cube的 pod相當于一個虛擬機，因此Cube的pod可以直接利用原先底層SDN網絡為虛擬機提供的能力，實現VPC內Cube和VPC內所有資源的二層互通，以及不同VPC內資源的互相隔離。另外從滿足用戶需求的角度出發，我們也實現了Cube固定內網IP的功能，即在Cube實例更新的過程中，我們可以保持容器pod IP不變。
Cube的外網連通性也可以很好利用現有云平臺的網絡架構，對于入向流量，我們可以將Cube掛在ULB背后，利用多個Cube實例實現高可用和彈性伸縮;對于出向流量，我們也可以通過NETGW來實現Cube對外的訪問需求。另外對于需要固定外網IP的情況，我們也可以將單個EIP綁定Cube。
存儲實現
Cube的存儲也可以很好的對標K8S，主要分為以下幾類：一種是K8S內置的Config map Secret和EmptyDir，這些都是作為K8S標準的功能，我們也在Cube實現的CRI中紛紛予以了支持;對于云廠商提供的文件存儲、對象存儲，我們是通過agent的掛載來實現的，其中文件存儲主要是通過agent自動掛載了NFS協議，而對象存儲是通過agent掛載了S3fuse的協議;塊存儲是我們改動比較大的地方，為了提高性能，我們改動了Cube所使用的虛擬機IO路徑。通過vhost-user協議，對接到SPDK實現了Cube上高性能RSSD云盤的掛載。
監控和日志的實現
監控和日志這二者的架構比較類似，都是將容器內的信息反饋給用戶的一種形式。其中監控信息是通過我們自研的Cubelet組件，將監控信息匯集后上報給prometheus，最終再轉發給UCloud API的。而日志信息是通過Promtail采集后轉發給Loki Log Cluster集群，再轉交給UCloud API，另外對于長期日志，我們還提供了自動轉存至對象存儲US3的功能。
典型使用場景
最后，張苗磊分享了一個 Cube比較典型的使用場景，從這個圖中我們可以看到所有的計算功能都可以通過Cube容器的實例來提供，而入向流量通過ULB來實現，后接的存儲、數據庫都可以通過云上原生提供的mysql或者UFS來實現，這樣架構可以很好的提供計算、存儲分離，并且能夠提供快速橫向擴展和彈性資源使用的能力。關于這個架構具體的使用情況可以通過B站觀看詳情。
除此之外，Cube在互聯網削峰場景、數據采集、實時音視頻轉碼等場景均可以發揮免服務器運維、秒級啟動、自愈性、秒級計費等多重優勢，助力企業在容器化應用部署過程中進一步降本增效。
