基於 K8S 構建企業級 Serverless Container 平臺的探索與實踐

時間 2019-12-02

標籤基於 k8s 構建企業 serverless container 平臺探索實踐简体版

原文原文鏈接

前言

當前 Kubernetes 已經成爲名副其實的企業級容器編排規範，不少雲平臺都開始提供兼容 Kubernetes 接口的容器服務。而在多用戶支持方面，多數平臺選擇直接提供專屬虛機集羣，用戶須要花費大量精力處理集羣規模、資源利用率、費用等問題。本次分享帶來的是華爲雲在基於 K8S 構建企業級 Serverless Container 平臺過程當中的探索與實踐，涉及容器安全隔離、多租管理、Serverless 理念在 Kubernetes 平臺的落地等相關內容。docker

Kubernetes 在華爲雲的歷程

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

容器的三大好處，爲應用而生

衆所周知，容器技術有三大好處。安全

一是它提供資源隔離，用戶很容易經過應用合設來提高資源利用率；
二是，它具有秒級彈性的能力。由於容器自己技術特色，不用加載重型虛擬化，因此它能夠作到很是快速的彈性擴縮容；
三是，容器鏡像技術，解決了包括應用及其依賴環境的一致性問題，簡化業務交付流程。

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

Kubernetes 的常見使用形態

私有云部署Kubernetes

人們使用 Kubernetes 的一種常見形式就是在本身的數據中心搭建集羣。網絡

這種作法的優勢在於：less

第一，能夠享受DIY過程帶來的樂趣和成就感（固然也可能隨使用時間的增加，問題愈來愈多而變成苦難）。
第二，在全套私有化的模式下，數據請求都在本地處理，不會存在隱私顧慮。
第三，資源規劃、集羣安裝部署升級，都是用戶本身端到端控制。

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

公有云半托管Kubernetes專屬集羣

第二種 Kubernetes 的常見形態是公有云的（半）託管集羣。性能

能夠這樣理解，用戶購買一組虛機，雲平臺則自動在這些機器上部署一套 Kubernetes，而半托管含義在於有些平臺，它的控制面多是附送的。測試

這種形態的優勢是：優化

用戶本身擁有集羣，不用擔憂與其餘用戶共用一套 Kubernetes 可能引發一系列干擾問題。
雲平臺在提供 Kubernetes 服務時，每每通過大量的測試和調優，因此給出集羣的配置是在自家平臺上的最佳實踐。用戶經過這種模式在雲上運行 Kubernetes，能夠得到比本身部署運維好不少的體驗。
Kubernetes 社區發佈新版本後，雲平臺會至少作一輪額外的測試、問題修復，再上線並推薦用戶升級。這用就節省了用戶對升級時機評估的工做量。而直接使用開源版本的用戶，若是對新版本跟進太快，本身要踩不少坑，但要延後到哪一個版本再升，則要持續跟進社區bug和fix的進度，費時費力。
當用戶的 Kubernetes 出現問題時，能夠從雲平臺得到專業的技術支持。因此在公有云上使用（半）託管的 Kubernetes 服務，是一種很好的成本轉嫁方式，運維成本與雲平臺共同分擔。

固然仍有一些明顯的缺點spa

首先仍是價格，當用戶購買一組虛機，須要付出的價格是虛機 Flavor 單價乘以節點數量 N。其次，由於用戶獨佔一套 Kubernetes 集羣，規格不會太大，總體資源利用率仍然比較低。即便嘗試調優也效果不大，何況多數狀況下用戶名不能徹底自定義控制面組件的配置。另外，當集羣空閒資源很少而業務須要擴容時，還必須先擴集羣，端到端的擴容會受限於虛機的建立時間。

容器實例服務

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

它的優勢顯而易見：

用戶不感知底層集羣，也無需運維；
資源訂價顆粒度足夠細，用多少買多少；
真正的秒級擴縮容，而且是秒級計費。

其缺點在於：

不少平臺的容器實例服務主要提供私有API，並不能很好兼容kubernetes的API，並且容易被廠商綁定。

迫於知足用戶使用K8S API的需求，這些容器實例服務也推出了基於virtual-kubelet項目的兼容方案。經過把整個容器實例服務虛擬成 Kubernetes 集羣中的節點，對接 kubernetes master 來處理 Pod 的運行。

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

看了前面這麼多的背景，你可能不由要問： 爲何不嘗試使用 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 默認網絡全通的模式在這種景下會有不少問題。

華爲雲的探索與實踐

下圖是華爲雲容器實例服務的全貌，它基於 Kubernetes 打造，對最終用戶直接提供 K8S 的 API。正如前面所說，它最大的優勢是用戶能夠圍繞 K8S 直接定義運行應用。

這裏值得一提是，咱們採用了全物理機的方案，對於端到端資源利用率有一個很大的提高。而在 K8S 之上咱們經過一層封裝實現了超規模資源池。你們知道 K8S 現開源的版本最大隻能支持到 5000 節點，而且這是在 Google 雲上的驗證結果，而在不少其餘的雲平臺每每達不到。主要是受限於底層網絡和存儲系統。

因此在華爲雲，咱們的作法是經過一層封裝和引入 Federation 來得到總體服務的超大規模。同時由於 K8S 原生多租能力很是有限，因此咱們選擇將額外基於租戶的驗證、多租限流等工做放在這一層封裝中實現。但對於應用定義等接口，則是直接透傳 K8S 原生的 API 數據，只是在調用過程當中增長如請求合法性等的校驗。圖中右側的容器網絡、容器存儲，現有的開源方案是沒法知足的，因此華爲雲採用自研的策略。

租戶概念和網絡隔離

前面已經講過，K8S 原生並無租戶概念，只有一層以 Namespace 爲邊界的隔離。在 Namespace 這一層，除了API對象的可見性隔離，K8S 還提供了 Resource Quota（資源總和限制）以及 Limit Range（定義每一個Pod、Container能使用的資源範圍）等精細的配額管理能力。而在華爲雲上，咱們設計的租戶模型是：租戶（用戶）、項目、Namespace 三層模型，方便用戶管理多個項目的開發、測試、生產等不一樣階段。

網絡隔離方面，採用多網絡模型，一個項目中能夠定義多個VPC，VPC 和 Namespace 是一對多的關係。用戶能夠結合實際須要將開發、測試階段的應用部署在同個 VPC 的不一樣 Namespace 中便於調試和問題定位，生產環境部署在擁有單獨 VPC 的 Namespace 保證不受其餘活動干擾。

Runtime安全與隔離

再看 Runtime，因爲是全物理機的模式，節點被不一樣的租戶共享，普通docker容器沒法知足Pod間的隔離性要求，Runtime採用的是安全容器（即早期的runV，如今的Kata Container）。使用安全容器的主要思路，就是在Pod外圍包一層輕量級虛擬機，這樣既保證了Pod間的隔離性，又兼容了K8S原生Pod內容器共享網絡和存儲的設計。而包裝這層輕量級的虛機，由於裏面只須要運行容器，能夠經過裁剪等手段優化到與普通容器相同數量級的啓動時間。

接口層面，按照社區如今的進展，推薦的作法是使用 CRI (container runtime interface) 直接對接安全容器的 CRI-shim 實現。不過由於項目啓動很早，CRI 還沒有成熟，咱們採用的是在 Docker 內部分支處理的方案：在容器引擎服務中，仍然是原來的邏輯，直接建立普通容器；而在咱們的容器實例服務裏，經過 Docker API 調用建立出來的則是安全容器。用戶本來使用 Docker 容器的習慣幾乎沒有改變，在指定容器鏡像時也是須要指定所需運行的 Docker 鏡像，外層輕量級虛機的鏡像直接由宿主機提供。這樣既解決了安全隔離的問題，又不會給用戶帶來額外的切換成本。

最後，讓咱們來回顧一下本次分享的關鍵內容。

首先，咱們基於 Kubernetes 構建了華爲雲容器實例服務的核心部分，在其上封裝實現了多租戶的定義和訪問隔離。對用戶來講，最大的好處是可使用原生 K8S 的 API 和命令行，不須要感知 K8S 集羣和底層資源，不須要在使用前建立集羣，使用過程當中也不用擔憂集羣出現任何問題，徹底由平臺自身來保證服務的可用性。
其次，在計算資源隔離方面，咱們採用是Docker原生API後端對接 kata container，能夠最大限度兼容兩個項目的生態。而對於最終用戶來講，用戶只須要知道安全隔離足夠可靠。而在網絡隔離方面，採用多網絡的模型，用戶能夠定義多個 VPC，將 Namespace 和應用建立到不一樣的 VPC 中，以此實現彼此之間的隔離。
此外，針對高性能計算場景，咱們還完成了GPU、FPGA加速芯片的分配調度優化，配合高性能網絡與本地存儲加速，進一步提高了端到端計算性能。