虛擬機才是 Kubernetes 的未來？
Kubernetes 的未來到底在哪裡？本文作者一一為你解析。
作者 | Paul Czarkowski
譯者 | 彎月
責編 | 屠敏
出品 | CSDN（ID：CSDNNews）
凝視水晶球
今年對我的職業生涯而言，Kubernetes 是一項非常重要的技術，明年亦會如此。隨著 2018 年的結束，我將在此做出一個大膽的預測。虛擬機才是 Kubernetes 的未來，而不是容器。
虛擬機才是 Kubernetes 的未來，而不是容器。
2018 年是中國農曆的狗年，但在技術領域今年是 Kubernetes 年。現在有很多人都在學習 Kubernetes。各位首席信息官都在努力制定「Kubernetes 戰略」（如果你還在嘗試開發 Kubernetes 策略，那就已經輸在了起跑線上，但那是另一個故事）。有些組織已經在 Kubernetes 上運行大量的生產工作負載了。
換句話說，縱觀 Kubernetes 的加德納技術成熟度曲線（Gartner Hype Cycle），每個階段都有很多人。許多人正處於幻滅的低谷，或者陷入了絕望的陷阱。
圖片來自維基百科，作者：Jeremykemp
我是容器的忠實粉絲，而且我沒有暗示容器已死。2013 年 Docker 給我們帶來了 Linux 容器的包裝器，向我們展示了一種驚艷的構建、打包、共享和部署應用程序的新方法。當時我們已經開始認真對待持續交付，所以這個時機再恰當不過了。這些容器的模型非常適合現代交付流程，以及 PaaS 和後來的 CaaS 平台。
在 Google 工作的工程師都看到技術社區終於準備好迎接容器了。Google 使用（或多或少地發明）容器已經有相當長一段時間了。他們開始構建的 Kubernetes 正是現在眾所周知的 Google 自己的 Borg 平台的重新構思，而 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 Services，OpenStack等）。
Kubesprawl 統治著我周圍的一切
Kubernetes 的軟租賃模式導致服務提供商和發行商處於一種尷尬的境地。 Kubernetes 集群本身屬於「硬租賃」。由於種種原因（甚至在同一組織內部）要求用戶（或應用程序）之間保持「硬租賃」。由於公共雲提供完全託管的 Kubernetes 即服務產品，因此每個租戶都可以輕鬆獲得自己的集群，並以集群邊界作為隔離點。
有些 Kubernetes 發行商（比如 Pivotal Container Service，PKS）非常了解這個租賃的問題，並採用了一種類似的模型，提供與公共雲相同的 Kubernetes 即服務體驗，只不過是在自家的數據中心實現的。
這導致了「許多集群」而非「一個大型共享集群」的新興模式。Google GKE 服務的客戶為多個團隊部署數十個 Kubernetes 集群的現象並不罕見。通常每個開發商都會獲得自己的集群。這種行為會產生驚人數量的 Kubesprawl。
在自家數據中心運行 Kubernetes 集群（基於上游或基於分布）的 Kubernetes 運營商可以選擇自行承擔管理大量集群的額外工作，或者直接接受一個或兩個較大集群上的軟租賃。
「這種行為會產生驚人數量的 Kubesprawl。」
通常，你可以獲得的最小集群是 4 台計算機（或虛擬機）。一台（如需要高可用性則需要3台）給 Kubernetes Master，三台給 Kubernetes Worker。所以即使系統的大部分只是閑置在一邊，也需要耗費巨額資金。
所以我們需要通過某種方式將 Kubernetes 轉成硬租賃模型。Kubernetes 社區非常清楚這一需求，而且他們擁有一個多租戶工作組。這個小組一直在努力解決這個問題，他們有幾個建議的模型以及如何解決各個模型的提議。
Jessie Frazelle 撰寫了一篇關於這個主題的文章（https://blog.jessfraz.com/post/hard-multi-tenancy-in-kubernetes/），這篇文章非常棒，因為她比我更聰明，「聽她一席話，勝讀十年書」，所以你也可以關注她。如果你還沒有閱讀上面她的這篇文章，那麼我建議你先暫停去讀讀看。
小型虛擬機的速度優化
Kata Containers 是一個開源項目和社區，致力於構建輕量級虛擬機的標準實現，這種虛擬機給人的感覺和執行就如同容器一樣，但是還可以提供工作負載隔離和虛擬機的安全優勢。
Jessie 建議使用 Kata Containers 等虛擬機容器技術。Kata Containers 結合了虛擬機級別的隔離，其動作和執行與容器一樣。如此一來，Kubernetes 就可以為嵌套虛擬機容器（在底層IaaS提供的虛擬機內運行的虛擬機容器）中運行的每個租戶（我們假定每個命名空間只有一個租戶）提供自己的一組 Kubernetes 系統服務。
圖片來自Jessie Frazelle的《Kubernetes的硬性多租戶》（https://blo
這是一種針對 Kubernetes 多租戶問題的一個優雅的解決方案。Jessie 還進一步建議 Kubernetes 使用嵌套的容器虛擬機來運行 Kubernetes 上的工作負載（Pod），如此即可大大提高了資源的利用率。
在此我們還有一個優化需要做，即為底層 IaaS 或雲提供商構建合適的管理程序。如果虛擬機容器是 IaaS 提供的第一級抽象，那麼我們就可以進一步提高資源的利用率。運行 Kubernetes 集群所需的最小虛擬機數量下降到一個（如需要高可用性則需要 3 個），即通過一台虛擬機來運行面向「超級用戶」的 Kubernetes 控制平面。
多租戶的資源（成本）優化
擁有兩個名稱空間且每個都運行了許多應用程序的Kubernetes部署大致如下：
注意：同一 IaaS 基礎架構上還運行了其他雲租戶的工作負載。由於這些是虛擬機容器，因此它們的隔離級別常規雲虛擬機相同。因此，它們能夠以最小的風險在同一個虛擬機管理程序上運行。
最初，部署到雲的基礎設施為零，因此超級用戶的成本也為零。
超級用戶通過雲向 Kubernetes 集群發請求。雲提供商創建一個容器虛擬機（如需要高可用性則需要 3 個），來運行主要的 Kubernetes API 和系統服務。超級用戶可以選擇在系統命名空間中部署 pod，或者創建新的命名空間以委派其他用戶的訪問許可權。
超級用戶創建兩個命名空間 foo 和 bar。Kubernetes 向雲請求兩個虛擬機容器來運行每個命名空間的控制平面（Kubernetes API 和系統服務）。超級用戶將這些命名空間的訪問委派給每個部署一些工作負載（Pod）的用戶，他們各自的控制平面再向虛擬機發請求來運行每個工作負載。
在此過程的所有階段中，超級用戶只需支付實際消耗的資源。所有雲用戶的可用資源屬於雲提供商。
舊事重提
雲提供商已經在朝這個方向努力了。我們可以從開源社區發生的種種情況中看出一些端倪。（亞馬遜的 Fargate 已經在秘密地有所行動了。）
最具代表性的是 Virtual Kubelet，它是一個開源工具，旨在偽裝成一個 kubelet。它將 Kubernetes 連接到其他 API。如此便可允許 Kubernetes 通過雲的容器虛擬機調度程序請求容器虛擬機。
還有許多其他新興的虛擬機容器技術，例如上述提到的 Kata Containers，還有來自亞馬遜的 Firecracker 和來自 Google的gvisor。
總結
通過正確地改進 Kubernetes 硬租賃模型，你就可以取得 Kubernetes 的成功。我們應該通過完全隔離 Kubernetes 工作負載與每個 Pod 的消耗成本模型，在 Kubernetes 上運行工作負載。
對於那些沒有使用公共雲的人來說，你無法獲得與基礎設施提供商（在這種情況下就是你自己）的容量負擔相同的消耗模型。但是你仍然可以獲得資源高利用率的好處，這可以降低對容量的需求。
我希望 VMware 和 OpenStack 可以關注這些問題，並為我們帶來基於管理程序和適當的 Virtual Kubelet 實現的輕量級虛擬機容器技術。
原文：https://tech.paulcz.net/blog/future-of-kubernetes-is-virtual-machines/
作者：Paul Czarkowski，IBM 雲開發實驗室的技術主管。
本文為 CSDN 翻譯，如需轉載，請註明來源出處。
TAG:CSDN |