如何基于 K8S 多租能力構建 Serverless Container

當前 Kubernetes 已經成為名副其實的企業級容器編排規范，很多云平臺都開始提供兼容 Kubernetes 接口的容器服務。而在多用戶支持方面，多數平臺選擇直接提供專屬虛機集群，用戶需要花費大量精力處理集群規模、資源利用率、費用等問題。

本次分享帶來的是華為云在基于 K8S 構建企業級 Serverless Container 平臺過程中的探索與實踐，涉及容器安全隔離、多租管理、Serverless 理念在 Kubernetes 平臺的落地等相關內容。

Kubernetes 在華為云的歷程

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

容器的三大好處，為應用而生
眾所周知，容器技術有三大好處。一是它提供資源隔離，用戶很容易通過應用合設來提升資源利用率；二是，它具備秒級彈性的能力。因為容器本身技術特點，不用加載重型虛擬化，所以它可以做到非常快速的彈性擴縮容；三是，容器鏡像技術，解決了包括應用及其依賴環境的一致性問題，簡化業務交付流程。

但在實際環境中，容器技術帶來的終端便利有多少呢？這還得從Kubernetes的使用形態談起。

Kubernetes 的常見使用形態

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

這種做法的優點在于：第一，可以享受DIY過程帶來的樂趣和成就感（當然也可能隨使用時間的增長，問題越來越多而變成苦難）。第二，在全套私有化的模式下，數據請求都在本地處理，不會存在隱私顧慮。第三，資源規劃、集群安裝部署升級，都是用戶自己端到端控制。

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

公有云半托管Kubernetes專屬集群

第二種 Kubernetes 的常見形態是公有云的（半）托管集群。可以這樣理解，用戶購買一組虛機，云平臺則自動在這些機器上部署一套 Kubernetes，而半托管含義在于有些平臺，它的控制面可能是附送的。

這種形態的優點是：

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

（2）云平臺在提供 Kubernetes 服務時，往往經過大量的測試和調優，所以給出集群的配置是在自家平臺上的最佳實踐。用戶通過這種模式在云上運行 Kubernetes，可以獲得比自己部署運維好很多的體驗。

（3） Kubernetes 社區發布新版本后，云平臺會至少做一輪額外的測試、問題修復，再上線并推薦用戶升級。這用就節省了用戶對升級時機評估的工作量。而直接使用開源版本的用戶，如果對新版本跟進太快，自己要踩很多坑，但要延后到哪個版本再升，則要持續跟進社區bug和fix的進度，費時費力。

（4）當用戶的 Kubernetes 出現問題時，可以從云平臺獲得專業的技術支持。所以在公有云上使用（半）托管的 Kubernetes 服務，是一種很好的成本轉嫁方式，運維成本與云平臺共同分擔。

當然仍有一些明顯的缺點，首先還是價格，當用戶購買一組虛機，需要付出的價格是 虛機 Flavor 單價 乘以 節點數量 N。其次，因為用戶獨占一套 Kubernetes 集群，規格不會太大，整體資源利用率仍然比較低。即使嘗試調優也效果不大，況且多數情況下用戶名不能完全自定義控制面組件的配置。另外，當集群空閑資源不多而業務需要擴容時，還必須先擴集群，端到端的擴容會受限于虛機的創建時間。

容器實例服務

第三種，嚴格說是用戶使用容器的形態，使用公有云的容器實例服務。

它的優點顯而易見：用戶不感知底層集群，也無需運維；資源定價顆粒度足夠細，用多少買多少；真正的秒級擴縮容，并且是秒級計費。

其缺點在于：很多平臺的容器實例服務主要提供私有API，并不能很好兼容kubernetes的API，而且容易被廠商綁定。
迫于滿足用戶使用K8S API的需求，這些容器實例服務也推出了基于virtual-kubelet項目的兼容方案。通過把整個容器實例服務虛擬成 Kubernetes 集群中的節點，對接 kubernetes master 來處理 Pod 的運行。

然而，由于整個容器實例服務被虛擬成了一個超級節點。Kubernetes 中原本針對多節點精心設計的一系列應用高可用相關特性都無法生效。另一個問題是這個基于virtual-kubelet項目的兼容方案在數據面并不完整，這里包括項目成員在Kube-proxy部署層級位置上的搖擺，以及仍無音訊的容器存儲如何兼容。
如何基于 K8S 多租能力構建 Serverless Container

看了前面這么多的背景，你可能不禁要問：為什么不嘗試使用 Kubernetes 的多租方案來構建 Serverless Container 服務？實際上基于 Kubernetes 多租來構建容器實例服務，優點有很多，最大的在于是支持 K8S 原生 API 和命令行。用戶圍繞 Kubernetes 開發的應用都以直接在基于 K8S 的 Serverless Container 上部署和運行。因為容器可以做到秒級計費，用戶可以享受容器實例服務價格門檻較低的特點。另外，這種形態下通常是云平臺來運維一個大資源池，用戶只需為業務容器的資源付費，不需要關心底層集群的資源利用率，也沒有集群運維的開銷。

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

接下來我們回顧一下 K8S 中典型的多租場景。

第一是 SaaS 平臺，或其他基于 K8S 封裝提供的服務，它不直接暴露 K8S 的 API。因為有一層自己的 API 封裝，平臺可以做很多額外工作，比如自己實現租戶定義，所以對于 k8s 控制面的租戶隔離要求較低。而應用來自最終用戶，并不可信，所以實際上在容器運行時，需要較強的數據面資源隔離和訪問控制。

第二小公司的內部平臺。用戶和應用都來自于公司內部，互信程度比較高，控制面和數據面都不需要做過多額外的隔離增強。原生的 K8S 就能滿足需要。

第三是大型企業的平臺，這種場景下 K8S 的用戶，基本來自于企業內部的各個部門，開發部署的應用也是經過內部的驗證之后才可以上線。所以應用的行為是可信的，數據面不需要做太多的隔離。更多的是要在控制面做一些防護控制，來避免不同部門、業務之間的管理干擾，如API調用時，需要實現針對租戶的限流。

第四種場景，在公有云上對外提供一個多租的 K8S 平臺，它對控制面和數據面的要求都是最高的。因為應用的來源不可控，很可能包含一些惡意代碼。而 K8S 的 API 直接暴露給最終用戶，控制面的隔離能力，如區分租戶的API限流、訪問控制等都是不可或缺的。

總結一下，對于 K8S 來說，如果要在公有云場景下提供 Serverless Container 服務，需要解決三大類挑戰。一是租戶概念的引入、訪問控制實現。目前 K8S 仍然沒有原生的租戶概念，以 Namespace 為邊界的并不能很多好適配多租場景。二是節點 (計算資源) 的隔離還有 Runtime 的安全。三是網絡隔離，K8S 默認網絡全通的模式在這種景下會有很多問題。