摘要

在中国的生肖中，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 s Kubernetes中的刚性多租户

这是一个优雅的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

创作场景

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