[[254590]]

Kubernetes這項技術對于我今年的職業生涯而言可謂至關重要，相信其重要意義在新的一年中還將繼續保持。值此辭舊迎新之際，請大家允許我結合個人體會做出一點大膽的預測：Kubernetes的未來在于虛擬機，而非容器。

2018年是中國十二生肖中的狗年，同時也是技術層面的Kubernetes元年。如今，學習Kubernetes的朋友已經為數不少，各公司的CIO也在努力制定自己的“Kubernetes戰略”。更有部分組織已經開始在Kubernetes上運行大規模生產工作負載。

如果您剛剛嘗試建立Kubernetes策略，那么您恐怕已經失敗了——我們會在后續文章中就此展開探討。

換句話說，在Gartner為Kubernetes提出的炒作周期各個階段當中，都有很多人陷入了幻滅的低谷甚至是絕望的陷阱。

我個人正是容器技術的忠實粉絲，我也絕對不是說容器技術會走向消亡。Docker于2013年為我們帶來了Linux容器的打包方案，其顯示出一種令人印象深刻的應用程序構建、打包、共享與部署新方法。容器的成功可謂正當其時，畢竟這時候我們正在認真考慮如何實現持續交付。容器模型非常適合現代交付管道與PaaS，同時也高度契合之后出現的CaaS平臺。

谷歌公司的工程師們也意識到，技術社區終于為容器的出現做好了準備。長久以來，谷歌方面一直在使用(甚至在一定程度上發明了)容器技術。他們開始構建Kubernetes，現在我們知道其靈感源自谷歌內部的Borg平臺，而項目本身則以社區開發的形式運作。

不久之后，各大公有云供應商就為Kubernetes提供了***的發揮舞臺(GKE、AKS以及EKS等)。內部人員也很快建立起自己的基于Kubernetes平臺(Pivotal Container Service以及OpenShift等)。

令人頭痛的多租戶機制

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

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

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

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

Kubernetes集群本身成了“硬租戶”面臨的***道坎，也因此導致大部分用戶只能使用“多集群”這一新興模式，而非“單一共享”集群。相信很多朋友都發現了，谷歌GKE Service的用戶往往需要面向多個團隊部署數十個Kubernetes集群，有時候每一位開發者都擁有自己的集群。這類作法最終導致了嚴重的Kube泛濫問題。

“這類作法最終導致了嚴重的Kube泛濫問題。”

通常來講，我們使用的最小集群包含四臺設備(或者虛擬機)。其中一臺(或者三臺，用以實現高可用性)作為Kubernetes主節點，另外三臺作為Kubernetes工作節點。這不僅會帶來極高的資金成本，同時也使得大部分系統資源長期處于閑置狀態。

因此，我們需要以某種方式將Kubernetes轉換至硬租戶模式。Kubernetes社區對于這種需求有著明確的認知，也建立起專門的多租戶工作組。該小組一直在努力解決這個問題，并針對各類可行模式給出了多種改進建議。

針對速度進行優化的小型虛擬機更為可行……

Kata Containers是一個開源項目與社區，致力于構建輕量極虛擬機的標準實現方案。其使用感受與執行效果與容器類似，但能夠提供與虛擬機相同的工作負載隔離能力及安全優勢。

Jessie建議使用Kata Containers這類虛擬機容器技術。Kata Containers將虛擬機級別的隔離機制與容器的執行及起效方式加以結合。如此一來，Kubernetes將能夠為每個租戶(我們假定每命名空間一個租戶)提供運行在嵌套虛擬機容器(即由底層IaaS提供，運行在虛擬機之內的容器)內的一組獨立Kubernetes系統服務。

image from Jessie Frazelle - Hard Multi-Tenancy in Kubernetes

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

在這方面，我們至少還能夠做出一項深層優化，即為底層IaaS或云服務供應商構建合適的虛擬機管理程序。如果其中虛擬機容器代表著由IaaS提供的***層抽象，那么我們甚至能夠進一步優化資源利用率。具體來講，我們可以將運行Kubernetes集群所需要的***虛擬機數量減少至一個(或者三個以實現高可用性)，并用以承載開放給“超級用戶”的Kubernetes控制平面。

資源(成本)優化型多租戶機制

配合兩個命名空間并運行有多款應用程序的Kubernetes集群將如下所示。

注意：同一IaaS基礎設施之上還運行有其他云用戶的工作負載。由于這些屬于虛擬機容器，因此其擁有與常規云虛擬機相同的隔離級別，因此，它們能夠以***風險運行在同一虛擬機管理程序之上。

起初，云基礎設施上的部署量為零，因此超級用戶的成本也為零。

該超級用戶從云端請求Kubernetes集群，云服務供應商負責創建單一容器虛擬機(或者三個容器虛擬機以實現高可用性)以運行主Kubernetes API與系統服務。超級用戶可以選擇在系統命名空間當中部署Pod，或者創建新的命名空間以分配面向其他用戶的訪問。

超級用戶創建兩個命名空間，分別為foo與bar。Kubernetes從云端為每個命名空間的控制平面(即Kubernetes API與系統服務)請求兩個虛擬機容器。超級用戶為各用戶分配該命名空間的訪問權限，從而允許這些用戶各自部署一部分工作負載(Pod)，而用戶自己的控制平面又進一步請求用于運行這些工作負載的虛擬機容器。

在整個執行流程當中，超級用戶只需要為實際消費的資源付費，云端可供用戶使用的全部容量皆歸云服務供應商所有。

其實這并不是什么新鮮事物……

云服務供應商們已經在努力實現上述目標。關注開源社區動態的朋友肯定已經發現了相關跡象。(更具體地講，亞馬遜希望通過Fargate達到的正是這一效果，只是并未公開宣布。)

***個跡象就是Virtual Kubelet，這款開源工具旨在模擬kubelet。其將Kubernetes與其它API相連，從而允許Kubernetes從云端的容器虛擬機調度程序處請求容器虛擬機。

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

總結

將正確的改進效果同Kubernetes硬租戶模式相結合，大家將真正發揮Kubernetes的全部潛能。Kubernetes工作負載的全面隔離與每Pod成本消費模式將最終使Kubernetes成為工作負載運行的***選項。

對于并沒有使用公有云的朋友，雖然業務體系中不存在基礎設施供應商(這種情況下，基礎設施將由您自行提供)，因此無法獲得同樣的容量消費模式，但大家仍然可以通過這種方式實現資源利用率提升與總體容量需求削減。

我們也熱切希望VMware與OpenStack關注這一趨勢，并為我們帶來基于虛擬機管理程序的輕量級虛擬機容器技術以及理想的Virtual Kubelet實現方案。