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

公司主營業(yè)務(wù)：網(wǎng)站制作、網(wǎng)站建設(shè)、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)建站是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)建站推出烏拉特前免費做網(wǎng)站回饋大家。

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

Kubernetes 在華為云的歷程

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

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

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

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

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

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

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

公有云半托管Kubernetes專屬集群

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

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

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

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

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

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

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

容器實例服務(wù)

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

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

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

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

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

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

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

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

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

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

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

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

標題名稱：如何基于K8S多租能力構(gòu)建ServerlessContainer
文章分享：http://chinadenli.net/article42/gesoec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供響應(yīng)式網(wǎng)站、小程序開發(fā)、軟件開發(fā)、企業(yè)網(wǎng)站制作、網(wǎng)站導(dǎo)航、云服務(wù)器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)