圖1/6

圖2/6

然而，仍有一個(gè)棘手的問(wèn)題有待解決，我認(rèn)為這也可能成為容器崩潰的核心原因——多租戶機(jī)制。

Linux容器在設(shè)計(jì)之初并沒(méi)有考慮到安全的隔離沙箱（例如Solaris Zones或者FreeBSD Jails）。相反，容器采用的是共享內(nèi)核模式，其利用內(nèi)核功能提供基礎(chǔ)性的進(jìn)程隔離功能。正如Jessie Frazelle在文章中指出，“容器并不真實(shí)存在。”

更麻煩的是，大多數(shù)Kubernetes組件無(wú)法感知到租戶。雖然我們可以使用命名空間以及Pod安全策略，但API本身確實(shí)不具備租戶感知能力。此外， kubelet或者kube-proxy等內(nèi)部組件也存在同樣的問(wèn)題。這意味著Kubernetes能夠提供的只是一種“軟租戶”模式。

抽象泄漏。建立在容器之上的平臺(tái)會(huì)繼承容器技術(shù)的諸多軟租戶因素。正如建立在硬多租戶虛擬機(jī)基礎(chǔ)之上的平臺(tái)（包括VMware、Amazon Web Srevices以及OpenStack等），也都繼承了這種硬租戶機(jī)制一樣。

Kubernetes集群本身成了“硬租戶”面臨的第一道坎，也因此導(dǎo)致大部分用戶只能使用“多集群”這一新興模式，而非“單一共享”集群。相信很多朋友都發(fā)現(xiàn)了，谷歌GKE Service的用戶往往需要面向多個(gè)團(tuán)隊(duì)部署數(shù)十個(gè)Kubernetes集群，有時(shí)候每一位開(kāi)發(fā)者都擁有自己的集群。這類(lèi)作法最終導(dǎo)致了嚴(yán)重的Kube泛濫問(wèn)題。

“這類(lèi)作法最終導(dǎo)致了嚴(yán)重的Kube泛濫問(wèn)題?！?/p>

通常來(lái)講，我們使用的最小集群包含四臺(tái)設(shè)備（或者虛擬機(jī)）。其中一臺(tái)（或者三臺(tái)，用以實(shí)現(xiàn)高可用性）作為Kubernetes主節(jié)點(diǎn)，另外三臺(tái)作為Kubernetes工作節(jié)點(diǎn)。這不僅會(huì)帶來(lái)極高的資金成本，同時(shí)也使得大部分系統(tǒng)資源長(zhǎng)期處于閑置狀態(tài)。

因此，我們需要以某種方式將Kubernetes轉(zhuǎn)換至硬租戶模式。Kubernetes社區(qū)對(duì)于這種需求有著明確的認(rèn)知，也建立起專(zhuān)門(mén)的多租戶工作組。該小組一直在努力解決這個(gè)問(wèn)題，并針對(duì)各類(lèi)可行模式給出了多種改進(jìn)建議。

針對(duì)速度進(jìn)行優(yōu)化的小型虛擬機(jī)更為可行……

Kata Containers是一個(gè)開(kāi)源項(xiàng)目與社區(qū)，致力于構(gòu)建輕量極虛擬機(jī)的標(biāo)準(zhǔn)實(shí)現(xiàn)方案。其使用感受與執(zhí)行效果與容器類(lèi)似，但能夠提供與虛擬機(jī)相同的工作負(fù)載隔離能力及安全優(yōu)勢(shì)。

Jessie建議使用Kata Containers這類(lèi)虛擬機(jī)容器技術(shù)。Kata Containers將虛擬機(jī)級(jí)別的隔離機(jī)制與容器的執(zhí)行及起效方式加以結(jié)合。如此一來(lái)，Kubernetes將能夠?yàn)槊總€(gè)租戶（我們假定每命名空間一個(gè)租戶）提供運(yùn)行在嵌套虛擬機(jī)容器（即由底層IaaS提供，運(yùn)行在虛擬機(jī)之內(nèi)的容器）內(nèi)的一組獨(dú)立Kubernetes系統(tǒng)服務(wù)。

image from Jessie Frazelle - Hard Multi-Tenancy in Kubernetes

這可謂是一種優(yōu)雅的Kubernetes多租戶問(wèn)題解決方案。Jessie甚至進(jìn)一步建議Kubernetes使用嵌套容器虛擬機(jī)處理運(yùn)行在Kubernetes之上的工作負(fù)載（Pod），從而大大提高資源利用率。

在這方面，我們至少還能夠做出一項(xiàng)深層優(yōu)化，即為底層IaaS或云服務(wù)供應(yīng)商構(gòu)建合適的虛擬機(jī)管理程序。如果其中虛擬機(jī)容器代表著由IaaS提供的第一層抽象，那么我們甚至能夠進(jìn)一步優(yōu)化資源利用率。具體來(lái)講，我們可以將運(yùn)行Kubernetes集群所需要的最低虛擬機(jī)數(shù)量減少至一個(gè)（或者三個(gè)以實(shí)現(xiàn)高可用性），并用以承載開(kāi)放給“超級(jí)用戶”的Kubernetes控制平面。

資源（成本）優(yōu)化型多租戶機(jī)制

配合兩個(gè)命名空間并運(yùn)行有多款應(yīng)用程序的Kubernetes集群將如下所示。

注意：同一IaaS基礎(chǔ)設(shè)施之上還運(yùn)行有其他云用戶的工作負(fù)載。由于這些屬于虛擬機(jī)容器，因此其擁有與常規(guī)云虛擬機(jī)相同的隔離級(jí)別，因此，它們能夠以最低風(fēng)險(xiǎn)運(yùn)行在同一虛擬機(jī)管理程序之上。

起初，云基礎(chǔ)設(shè)施上的部署量為零，因此超級(jí)用戶的成本也為零。

該超級(jí)用戶從云端請(qǐng)求Kubernetes集群，云服務(wù)供應(yīng)商負(fù)責(zé)創(chuàng)建單一容器虛擬機(jī)（或者三個(gè)容器虛擬機(jī)以實(shí)現(xiàn)高可用性）以運(yùn)行主Kubernetes API與系統(tǒng)服務(wù)。超級(jí)用戶可以選擇在系統(tǒng)命名空間當(dāng)中部署Pod，或者創(chuàng)建新的命名空間以分配面向其他用戶的訪問(wèn)。

超級(jí)用戶創(chuàng)建兩個(gè)命名空間，分別為foo與bar。Kubernetes從云端為每個(gè)命名空間的控制平面（即Kubernetes API與系統(tǒng)服務(wù)）請(qǐng)求兩個(gè)虛擬機(jī)容器。超級(jí)用戶為各用戶分配該命名空間的訪問(wèn)權(quán)限，從而允許這些用戶各自部署一部分工作負(fù)載（Pod），而用戶自己的控制平面又進(jìn)一步請(qǐng)求用于運(yùn)行這些工作負(fù)載的虛擬機(jī)容器。

在整個(gè)執(zhí)行流程當(dāng)中，超級(jí)用戶只需要為實(shí)際消費(fèi)的資源付費(fèi)，云端可供用戶使用的全部容量皆歸云服務(wù)供應(yīng)商所有。

其實(shí)這并不是什么新鮮事物……

云服務(wù)供應(yīng)商們已經(jīng)在努力實(shí)現(xiàn)上述目標(biāo)。關(guān)注開(kāi)源社區(qū)動(dòng)態(tài)的朋友肯定已經(jīng)發(fā)現(xiàn)了相關(guān)跡象。（更具體地講，亞馬遜希望通過(guò)Fargate達(dá)到的正是這一效果，只是并未公開(kāi)宣布。）

第一個(gè)跡象就是Virtual Kubelet，這款開(kāi)源工具旨在模擬kubelet。其將Kubernetes與其它API相連，從而允許Kubernetes從云端的容器虛擬機(jī)調(diào)度程序處請(qǐng)求容器虛擬機(jī)。

其它多種新興虛擬機(jī)容器技術(shù)中也存在著類(lèi)似的跡象，包括之前提到的Kata Containers、亞馬遜的Firecracker以及谷歌的gvisor等等。

總結(jié)

將正確的改進(jìn)效果同Kubernetes硬租戶模式相結(jié)合，大家將真正發(fā)揮Kubernetes的全部潛能。Kubernetes工作負(fù)載的全面隔離與每Pod成本消費(fèi)模式將最終使Kubernetes成為工作負(fù)載運(yùn)行的最佳選項(xiàng)。

對(duì)于并沒(méi)有使用公有云的朋友，雖然業(yè)務(wù)體系中不存在基礎(chǔ)設(shè)施供應(yīng)商（這種情況下，基礎(chǔ)設(shè)施將由您自行提供），因此無(wú)法獲得同樣的容量消費(fèi)模式，但大家仍然可以通過(guò)這種方式實(shí)現(xiàn)資源利用率提升與總體容量需求削減。

我們也熱切希望VMware與OpenStack關(guān)注這一趨勢(shì)，并為我們帶來(lái)基于虛擬機(jī)管理程序的輕量級(jí)虛擬機(jī)容器技術(shù)以及理想的Virtual Kubelet實(shí)現(xiàn)方案。