如何基于 K8S 多租能力構(gòu)建 Serverless Container

當(dāng)前 Kubernetes 已經(jīng)成為名副其實(shí)的企業(yè)級(jí)容器編排規(guī)范，很多云平臺(tái)都開始提供兼容 Kubernetes 接口的容器服務(wù)。而在多用戶支持方面，多數(shù)平臺(tái)選擇直接提供專屬虛機(jī)集群，用戶需要花費(fèi)大量精力處理集群規(guī)模、資源利用率、費(fèi)用等問(wèn)題。

本次分享帶來(lái)的是華為云在基于 K8S 構(gòu)建企業(yè)級(jí) Serverless Container 平臺(tái)過(guò)程中的探索與實(shí)踐，涉及容器安全隔離、多租管理、Serverless 理念在 Kubernetes 平臺(tái)的落地等相關(guān)內(nèi)容。

Kubernetes 在華為云的歷程

首先來(lái)了解一下華為云在 Kubernetes 的發(fā)展歷程。2014 年，華為云就開始研究并使用 Kubernetes，早期的重點(diǎn)是將 Kubernetes 應(yīng)用在私有云環(huán)境中。2016 年，華為公有云上發(fā)布了容器引擎平臺(tái) ( CCE），它的形式與市面上多數(shù)的公有云Kubernetes服務(wù)（如 GKE、AKS） 類似，是給用戶提供完整一套托管的K8S集群。而在今年年初，華為云發(fā)布了 Kubernetes 容器實(shí)例服務(wù)（Serverless Container），不過(guò)它與業(yè)界一些傳統(tǒng)的容器實(shí)例服務(wù)不太一樣。

容器的三大好處，為應(yīng)用而生
眾所周知，容器技術(shù)有三大好處。一是它提供資源隔離，用戶很容易通過(guò)應(yīng)用合設(shè)來(lái)提升資源利用率；二是，它具備秒級(jí)彈性的能力。因?yàn)槿萜鞅旧砑夹g(shù)特點(diǎn)，不用加載重型虛擬化，所以它可以做到非?？焖俚膹椥詳U(kuò)縮容；三是，容器鏡像技術(shù)，解決了包括應(yīng)用及其依賴環(huán)境的一致性問(wèn)題，簡(jiǎn)化業(yè)務(wù)交付流程。

但在實(shí)際環(huán)境中，容器技術(shù)帶來(lái)的終端便利有多少呢？這還得從Kubernetes的使用形態(tài)談起。

Kubernetes 的常見使用形態(tài)

私有云部署Kubernetes
人們使用Kubernetes的一種常見形式就是在自己的數(shù)據(jù)中心搭建集群。

這種做法的優(yōu)點(diǎn)在于：第一，可以享受DIY過(guò)程帶來(lái)的樂(lè)趣和成就感（當(dāng)然也可能隨使用時(shí)間的增長(zhǎng)，問(wèn)題越來(lái)越多而變成苦難）。第二，在全套私有化的模式下，數(shù)據(jù)請(qǐng)求都在本地處理，不會(huì)存在隱私顧慮。第三，資源規(guī)劃、集群安裝部署升級(jí)，都是用戶自己端到端控制。

但是缺點(diǎn)也很明顯：首先，很多人在自建時(shí)只看中了 Kubernetes，對(duì)周邊配套并沒做過(guò)很深度的研究，在實(shí)施過(guò)程中就會(huì)面臨網(wǎng)絡(luò)、存儲(chǔ)等配套系統(tǒng)的選型問(wèn)題。其次，用戶需要負(fù)擔(dān) 100% 的運(yùn)維成本，而且資源的投入往往是一次性（或階段性的），投入成本門檻非常高。此外，在自建的環(huán)境中 Kubernetes 的集群數(shù)量、中的單個(gè)集群規(guī)模往往不會(huì)很大，所以業(yè)務(wù)部署規(guī)模比較大時(shí)，彈性伸縮還會(huì)受限于底層資源規(guī)模，偏偏硬件資源的擴(kuò)容速度往往慢得不可想象。最后，開發(fā)者習(xí)慣于做比較多的資源預(yù)留，因此資源利用率也非常有限。也就是說(shuō)，自建者還要為全套資源利用率買單。

公有云半托管Kubernetes專屬集群

第二種 Kubernetes 的常見形態(tài)是公有云的（半）托管集群?？梢赃@樣理解，用戶購(gòu)買一組虛機(jī)，云平臺(tái)則自動(dòng)在這些機(jī)器上部署一套 Kubernetes，而半托管含義在于有些平臺(tái)，它的控制面可能是附送的。

這種形態(tài)的優(yōu)點(diǎn)是：

（1）用戶自己擁有集群，不用擔(dān)心與其他用戶共用一套 Kubernetes 可能引起一系列干擾問(wèn)題。

（2）云平臺(tái)在提供 Kubernetes 服務(wù)時(shí)，往往經(jīng)過(guò)大量的測(cè)試和調(diào)優(yōu)，所以給出集群的配置是在自家平臺(tái)上的最佳實(shí)踐。用戶通過(guò)這種模式在云上運(yùn)行 Kubernetes，可以獲得比自己部署運(yùn)維好很多的體驗(yàn)。

（3） Kubernetes 社區(qū)發(fā)布新版本后，云平臺(tái)會(huì)至少做一輪額外的測(cè)試、問(wèn)題修復(fù)，再上線并推薦用戶升級(jí)。這用就節(jié)省了用戶對(duì)升級(jí)時(shí)機(jī)評(píng)估的工作量。而直接使用開源版本的用戶，如果對(duì)新版本跟進(jìn)太快，自己要踩很多坑，但要延后到哪個(gè)版本再升，則要持續(xù)跟進(jìn)社區(qū)bug和fix的進(jìn)度，費(fèi)時(shí)費(fèi)力。

（4）當(dāng)用戶的 Kubernetes 出現(xiàn)問(wèn)題時(shí)，可以從云平臺(tái)獲得專業(yè)的技術(shù)支持。所以在公有云上使用（半）托管的 Kubernetes 服務(wù)，是一種很好的成本轉(zhuǎn)嫁方式，運(yùn)維成本與云平臺(tái)共同分擔(dān)。

當(dāng)然仍有一些明顯的缺點(diǎn)，首先還是價(jià)格，當(dāng)用戶購(gòu)買一組虛機(jī)，需要付出的價(jià)格是 虛機(jī) Flavor 單價(jià) 乘以 節(jié)點(diǎn)數(shù)量 N。其次，因?yàn)橛脩舄?dú)占一套 Kubernetes 集群，規(guī)格不會(huì)太大，整體資源利用率仍然比較低。即使嘗試調(diào)優(yōu)也效果不大，況且多數(shù)情況下用戶名不能完全自定義控制面組件的配置。另外，當(dāng)集群空閑資源不多而業(yè)務(wù)需要擴(kuò)容時(shí)，還必須先擴(kuò)集群，端到端的擴(kuò)容會(huì)受限于虛機(jī)的創(chuàng)建時(shí)間。

容器實(shí)例服務(wù)

第三種，嚴(yán)格說(shuō)是用戶使用容器的形態(tài)，使用公有云的容器實(shí)例服務(wù)。

它的優(yōu)點(diǎn)顯而易見：用戶不感知底層集群，也無(wú)需運(yùn)維；資源定價(jià)顆粒度足夠細(xì)，用多少買多少；真正的秒級(jí)擴(kuò)縮容，并且是秒級(jí)計(jì)費(fèi)。

其缺點(diǎn)在于：很多平臺(tái)的容器實(shí)例服務(wù)主要提供私有API，并不能很好兼容kubernetes的API，而且容易被廠商綁定。
迫于滿足用戶使用K8S API的需求，這些容器實(shí)例服務(wù)也推出了基于virtual-kubelet項(xiàng)目的兼容方案。通過(guò)把整個(gè)容器實(shí)例服務(wù)虛擬成 Kubernetes 集群中的節(jié)點(diǎn)，對(duì)接 kubernetes master 來(lái)處理 Pod 的運(yùn)行。

然而，由于整個(gè)容器實(shí)例服務(wù)被虛擬成了一個(gè)超級(jí)節(jié)點(diǎn)。Kubernetes 中原本針對(duì)多節(jié)點(diǎn)精心設(shè)計(jì)的一系列應(yīng)用高可用相關(guān)特性都無(wú)法生效。另一個(gè)問(wèn)題是這個(gè)基于virtual-kubelet項(xiàng)目的兼容方案在數(shù)據(jù)面并不完整，這里包括項(xiàng)目成員在Kube-proxy部署層級(jí)位置上的搖擺，以及仍無(wú)音訊的容器存儲(chǔ)如何兼容。
如何基于 K8S 多租能力構(gòu)建 Serverless Container

看了前面這么多的背景，你可能不禁要問(wèn)：為什么不嘗試使用 Kubernetes 的多租方案來(lái)構(gòu)建 Serverless Container 服務(wù)？實(shí)際上基于 Kubernetes 多租來(lái)構(gòu)建容器實(shí)例服務(wù)，優(yōu)點(diǎn)有很多，最大的在于是支持 K8S 原生 API 和命令行。用戶圍繞 Kubernetes 開發(fā)的應(yīng)用都以直接在基于 K8S 的 Serverless Container 上部署和運(yùn)行。因?yàn)槿萜骺梢宰龅矫爰?jí)計(jì)費(fèi)，用戶可以享受容器實(shí)例服務(wù)價(jià)格門檻較低的特點(diǎn)。另外，這種形態(tài)下通常是云平臺(tái)來(lái)運(yùn)維一個(gè)大資源池，用戶只需為業(yè)務(wù)容器的資源付費(fèi)，不需要關(guān)心底層集群的資源利用率，也沒有集群運(yùn)維的開銷。

這種形體現(xiàn)存的主要挑戰(zhàn)是 K8S 原生只支持軟多租，隔離性等方面還有有欠缺。

接下來(lái)我們回顧一下 K8S 中典型的多租場(chǎng)景。

第一是 SaaS 平臺(tái)，或其他基于 K8S 封裝提供的服務(wù)，它不直接暴露 K8S 的 API。因?yàn)橛幸粚幼约旱?API 封裝，平臺(tái)可以做很多額外工作，比如自己實(shí)現(xiàn)租戶定義，所以對(duì)于 k8s 控制面的租戶隔離要求較低。而應(yīng)用來(lái)自最終用戶，并不可信，所以實(shí)際上在容器運(yùn)行時(shí)，需要較強(qiáng)的數(shù)據(jù)面資源隔離和訪問(wèn)控制。

第二小公司的內(nèi)部平臺(tái)。用戶和應(yīng)用都來(lái)自于公司內(nèi)部，互信程度比較高，控制面和數(shù)據(jù)面都不需要做過(guò)多額外的隔離增強(qiáng)。原生的 K8S 就能滿足需要。

第三是大型企業(yè)的平臺(tái)，這種場(chǎng)景下 K8S 的用戶，基本來(lái)自于企業(yè)內(nèi)部的各個(gè)部門，開發(fā)部署的應(yīng)用也是經(jīng)過(guò)內(nèi)部的驗(yàn)證之后才可以上線。所以應(yīng)用的行為是可信的，數(shù)據(jù)面不需要做太多的隔離。更多的是要在控制面做一些防護(hù)控制，來(lái)避免不同部門、業(yè)務(wù)之間的管理干擾，如API調(diào)用時(shí)，需要實(shí)現(xiàn)針對(duì)租戶的限流。

第四種場(chǎng)景，在公有云上對(duì)外提供一個(gè)多租的 K8S 平臺(tái)，它對(duì)控制面和數(shù)據(jù)面的要求都是最高的。因?yàn)閼?yīng)用的來(lái)源不可控，很可能包含一些惡意代碼。而 K8S 的 API 直接暴露給最終用戶，控制面的隔離能力，如區(qū)分租戶的API限流、訪問(wèn)控制等都是不可或缺的。

總結(jié)一下，對(duì)于 K8S 來(lái)說(shuō)，如果要在公有云場(chǎng)景下提供 Serverless Container 服務(wù)，需要解決三大類挑戰(zhàn)。一是租戶概念的引入、訪問(wèn)控制實(shí)現(xiàn)。目前 K8S 仍然沒有原生的租戶概念，以 Namespace 為邊界的并不能很多好適配多租場(chǎng)景。二是節(jié)點(diǎn) (計(jì)算資源) 的隔離還有 Runtime 的安全。三是網(wǎng)絡(luò)隔離，K8S 默認(rèn)網(wǎng)絡(luò)全通的模式在這種景下會(huì)有很多問(wèn)題。