Kubernetes 的未来是虚拟机，而不是容器？

摘要

在中国的生肖中，2018 年是“狗年”，在科技领域则是“Kubernetes 年”。现在，有很多人才开始了解 Kubernetes。世界各地的首席信息官都在努力制定“Kubernetes 战略”。一些组织已经在 Kubernetes 上运行了大量的生产工作负载。

正文

本文最初发布于 Paul 的博客，经原作者授权由 InfoQ 中文站翻译并分享。

概述

作为一项技术，Kubernetes 今年对我的职业生涯非常重要，明年更是如此。在 2018 年即将结束之际，我们应该摒弃傲慢，做出大胆的预测。Kubernetes 的未来是虚拟机，而不是容器。

Kubernetes 的未来是虚拟机，而不是容器。

在中国的生肖中，2018 年是“狗年”，在科技领域则是“Kubernetes 年”。现在，有很多人才开始了解 Kubernetes。世界各地的首席信息官都在努力制定“Kubernetes 战略”。一些组织已经在 Kubernetes 上运行了大量的生产工作负载。

换句话说，对于 Kubernetes 来说，Gartner 炒作周期的每个阶段都有很多人。许多人被困在幻灭的低谷，或者被淹没在绝望的深渊。

来自Wikipedia，由 Jeremykemp 提供（Creative Commons CC BY-SA 3.0*）** *

我是容器的超级粉丝，我不会试图说明容器已死。在 2013 年，Docker 带给我们的是一个围绕 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 的“软性租户（Soft Tenancy）”模型。

抽象泄漏。构建在容器之上的平台将继承容器软性租户的许多方面。构建在刚性多租户虚拟机之上的平台都继承了刚性租户（VMware、Amazon Web Services、OpenStack 等）。

Kubesprawl 统治了我周围的一切

Kubernetes 的软性租户模型将服务提供和分发置于一个奇怪的位置。Kubernetes 集群本身成了“刚性租户”。有许多原因（甚至在同一个组织内部）要求在用户（或应用程序）之间实现刚性租户。由于公有云提供了全托管的 Kubernetes 服务，所以每个租户都很容易获得自己的集群并使用集群边界作为隔离点。

像Pivotal Container Service（PKS）这样的一些 Kubernetes 发行版非常清楚这个租户问题，它们采用了类似的模型，提供了与你从公有云中获得的服务体验相同的 Kubernetes，但是是在你自己的数据中心里。

这导致“多集群”模式的出现，而不是“一个大型共享集群”的模式。谷歌 GKE 服务的客户为多个团队部署了几十个 Kubernetes 集群，这种情况并不少见。通常，每个开发人员都有自己的集群。这种行为导致了数量惊人的 Kubesprawl。

或者，在自己的数据中心里运行自己的 Kubernetes 集群（上游或基于分布式的）的 Kubernetes 运营商可以自行承担管理大量集群的额外工作，或者只在一两个比较大的集群上接受软性租户。

“这种行为导致了数量惊人的 Kubesprawl。”

通常，最小的集群包含 4 台机器（或 VM），一台（或者 3 个，为实现 HA）作为 Kubernetes 主节点，三个作为 Kubernetes 工作节点。在大多数部分都空闲的系统中，这就占用了大量的资金。

所以，我们需要以某种方式将 Kubernetes 转移到一个刚性租户模型。Kubernetes 社区非常了解这种需要，并有一个多租户工作组。这个小组正在努力解决这个问题，他们就如何处理每个模型提出了几个建议模型和提案。

Jessie Frazelle 就这个话题写了一篇博文，很棒的一篇文章，因为她比我聪明得多，所以我可以让你和她取得联系，这样我就不用花十年的时间努力学习来赶上她了。如果你还没有读过，就不要往下读了，先去读那篇文章吧。

优化小型 VM 的速度

Kata 容器是一个开源项目和社区，致力于构建轻量级虚拟机（VM）的标准实现，这些虚拟机看起来和执行起来都像容器，但提供了 VM 的工作负载隔离和安全优势。

Jessie 建议使用 VM 容器技术，比如Kata容器。Kata 容器兼有虚拟机级别的隔离，表现和执行都跟容器类似。这使得 Kubernetes 可以为每个租户（假设每个名称空间有一个租户）提供一组在嵌套 VM 容器中运行的 Kubernetes 系统服务（VM 容器在底层 IaaS 提供的 VM 中运行）。

图片来自*ti-tenancy. Her sKubernetes中的刚性多租户

这是一个优雅的 Kubernetes 多租户解决方案。她甚至进一步建议 Kubernetes 把嵌套容器 VM 用于运行在 Kubernetes 上的工作负载（Pod），这样可以显著提高资源利用率。

这里至少还可以做一项优化。为底层 IaaS 或云提供商构建合适的虚拟机管理程序。如果 VM 容器是 IaaS 提供的第一级抽象，那么我们就可以进一步提高资源利用率。运行 Kubernetes 集群所需的最少 VM 数量下降到一个（或三个，为实现 HA），用于承载提供给“超级用户”的 Kubernetes 控制平面。

资源（成本）优化的多租户

下图是一个具有两个称空间的 Kubernetes 部署，每个部署运行多个应用程序。

注意：还有其他云租户工作负载运行在相同的 IaaS 基础设施上。因为这些是 VM 容器，所以它们具有与常规云 VM 相同的隔离级别。因此，它们就可以以最小的风险在同一个虚拟机管理程序上运行。

最初部署到云上的基础设施为零，因此超级用户的成本为零。

超级用户从云请求一个 Kubernetes 集群。云提供商创建一个单独的容器 VM（或三个，为实现 HA），它运行主要的 Kubernetes API 和系统服务。超级用户可以选择在系统名称空间中部署 Pod，或者创建新的名称空间以便把访问委托给其他用户。

超级用户创建两个名称空间 foo 和 bar。Kubernetes 从云中为每个名称空间的控制平面（Kubernetes API 和系统服务）申请两个 VM 容器。超级用户将对这些名称空间的访问委托给一些用户，这些用户各自部署一些工作负载（Pod），他们各自的控制平面为每个工作负载请求 VM 容器。

在所有阶段，超级用户只为实际消耗的资源付费。云提供商拥有任何云用户都可以使用的生产力。

我并没有说什么新东西

云提供商已经在朝着这个向努力了。通过观察开源社区中正在发生的事情，你就可以看到这个形成过程。(可以说，亚马逊已经在用 Fargate 做这件事了)。

第一个线索是Virtual Kubelet，这是一个开源工具，被伪装成了 Kubelet。它将 Kubernetes 与其他 API 连接起来。这将使得 Kubernetes 可以从云的容器 VM 调度器请求容器 VM。

其他线索包括新兴 VM 容器技术的数量，已经提到的Kata容器，还有来自亚马逊的Firecracker和来自谷歌的gvisor。

小结

结合对 Kubernetes 刚性租户模型的恰当改进，你将得到 Kubernetes 的圣杯。完全隔离 Kubernetes 工作负载和在 Kubernetes 上运行工作负载时纯粹按 Pod 计算的消费成本模型。

对于那些不在公有云上的人，我们没有相同的消费模型，因为生产力职责在基础设施提供商（在这种情况下是你自己）那里。你仍然可以获得更高的资源利用率所带来的好处，从较低的生产力需求中得到回报。

我们希望 VMware 和 OpenStack 能够注意到这一点，并为我们带来基于虚拟机管理程序的轻量级 VM 容器技术和适当的 Virtual Kubelet 实现。

查看英文原文：The future of Kubernetes is Virtual Machines