算命

Kubernetes在我的工作中已经发挥了重要作用，并且在将来它将变得更加重要。 但是2018年快要结束了，所以请别忘了谦虚并做出大胆的预测：

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

根据中国星座运势，2018年是狗年，但在技术上则是Kubernetes年。 现在许多人都在学习这项革命性的技术，各地的IT部门都在尝试制定“ Kubernetes战略” [1]。 一些组织已经将大量工作负载转移到Kubernetes。

[1]如果您试图制定Kubernetes策略，那么您已经失败了，但这是另一篇文章的主题。

换句话说，在“ Gartner感知周期”的每个步骤中，Kubernetes都有很多人。 有些人陷于失望的空洞中，或淹没在绝望的坑中。


Jeremykemp， 维基百科 。 创用CC CC BY-SA 3.0

我是容器的忠实拥护者，我不会说容器已死 。 在2013年，Docker为我们提供了一个用于Linux容器的外壳：一种构建，打包，共享和部署应用程序的惊人新方法。 它出现在正确的时间，因为我们开始认真对待连续交付。 他们的模型成为交付链的理想选择，并为PaaS平台和CaaS的出现做出了贡献。



Google工程师发现IT社区终于可以使用容器了。 Google已经使用容器很长时间了，从某种意义上说，它们可以被视为容器化的发明者。 他们开始开发Kubernetes。 如您所知，这是Google自己的Borg平台的免费转世。

很快，所有大型云（GKE，AKS，EKS）都提供了对Kubernetes的支持。 本地服务还快速提升了基于Kubernetes的平台（Pivotal Container Service，Openshift等）。

软多租户

有必要解决一个令人烦恼的问题，可以认为这是缺少容器的问题……这是多租户。

Linux容器不是作为安全沙箱创建的（例如Solaris Zones或FreeBSD Jails）。 相反，它们建立在使用内核功能提供基本进程隔离的通用内核模型上。 就像杰西·弗雷泽（Jesse Frazel）所说的那样 ，“容器不是真实的东西。”


Kubernetes的大多数组件都不了解租户这一事实使情况更加复杂。 当然，您拥有Pod 命名空间和安全策略 ，但是API中没有这样的东西。 以及内部组件（如kubelet或kube-proxy 。 这导致Kubernetes实施“软租金”（软租约）模型的事实。


Kubernetes体系结构

抽象进一步渗透。 容器顶部的平台继承了软租金的许多方面。 多租户虚拟机之上的平台继承了这一艰巨的租约（VMware，Amazon Web Services，OpenStack等）。

Kubernetes软租赁模型使服务提供商和发行商处于一种奇怪的状态。 Kubernetes集群本身正在成为“硬租”路线。 即使在同一组织内，也有许多原因要求在用户（或应用程序）之间付出高昂的租金。 由于公共云提供了完全托管的Kubernetes服务，因此客户可以轻松地使用自己的集群并将集群边界用作隔离点。

一些Kubernetes发行版（例如Pivotal Container Service（PKS））很好地意识到了这一租用问题，并使用类似的模型，提供了与Kubernetes相同的服务，该服务可以从公共云中获得，但位于您自己的数据中心。

这导致了“许多集群”模型的出现，而不是“一个大型公共集群”的出现。 通常，来自Google的GKE客户已经为多个团队部署了数十个Kubernetes集群。 通常每个开发人员都有自己的集群。 此行为生成了数量惊人的实例（Kubesprawl）。

另外，运营商可以在自己的数据中心中建立自己的Kubernetes集群，以进行其他工作来管理多个集群，或者同意轻柔地租用一个或两个大型集群。

通常，最小的群集是四台计算机（或虚拟机）。 Kubernetes Master有1个（对于HA，有3个），Kubernetes Workers有3个。 在大部分闲置的系统上花费了大量金钱。

因此，您需要以某种方式将Kubernetes推向严格的多租户。 Kubernetes社区非常了解这种需求。 一个多租赁工作组已经成立。 她正在努力解决这个问题，他们提供了几种模型以及有关如何使用每种模型的建议。

杰西·弗雷泽（Jesse Frazel）在这个主题上写了一篇博客文章 ，这很棒，因为她比我聪明得多，因此我可以向她推荐她，并摆脱十年的努力学习，以求达到她的水平。 如果您尚未阅读该帖子，请立即阅读。

只是针对速度进行了优化的非常小的VM ...

Kata Containers是一个开源项目和社区，致力于创建轻量级虚拟机的标准实现，这些虚拟机的外观和工作方式类似于容器，但提供了工作负载隔离和VM安全优势。

Jesse建议使用VM容器技术，例如Kata容器 。 它们提供VM级别的隔离，但是像容器一样工作。 这使Kubernetes可以为每个“租户”（我们假设租户在命名空间中）提供其自己的Kubernetes系统服务集，这些服务在嵌套VM容器（IaaS基础结构提供的虚拟机内部的VM容器）中运行。


杰西·弗雷瑟（Jesse Frasel）的照片：Kubernetes的艰苦多租户

这是一个优雅的Kubernetes多租用解决方案。 她的建议使Kubernetes进一步使用嵌套的VM容器处理在Kubernetes上运行的工作负载（Pods），这大大提高了资源利用率。

我们还剩下至少一项优化。 为基础架构提供商或云提供商创建正确的管理程序。 如果VM容器是IaaS提供的第一层抽象，那么我们将进一步提高资源利用率。 启动Kubernetes集群的最小VM数量减少到一台计算机（对于HA，则为三台）来托管Kubernetes管理系统，该系统可供“超级用户”使用。

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

具有两个名称空间和几个正在运行的应用程序的Kubernetes部署将如下所示：

注意：同一IaaS基础架构上还有其他负载。 由于这些是VM容器，因此它们具有与常规云VM相同的隔离级别。 因此，他们可以在同一虚拟机管理程序上以最小的风险工作。

最初，云中未部署任何基础架构，因此对于超级用户而言，成本为零。

超级用户从云请求Kubernetes集群。 云服务提供商创建了一个虚拟机，该虚拟机具有一个运行核心Kubernetes API和系统服务的容器（对于HA，则为三个）。 超级用户可以在系统名称空间中部署模块，也可以创建新的空间以委派其他用户访问。

超级用户创建两个名称空间foo和bar 。 Kubernetes针对每个级别的命名空间管理（Kubernetes API和系统服务）从云请求两个VM容器。 超级用户将对这些名称空间的访问权委派给某些用户，他们每个人都启动一些工作负载（模块），并且VM容器向这些容器请求这些工作负载。

在所有阶段，超级用户只为实际消耗的资源付费。 云服务提供商控制这些资源，任何云用户都可以使用它们。

我不是真的在说什么新东西...

云服务提供商已经朝着这个方向努力。 您可以通过观看社区事件来验证这一点（Amazon可能已经通过Fargate悄悄地做到了这一点）。

第一个技巧是Virtual Kubelet ，这是一种伪装成kubelet的开源工具。 它将Kubernetes连接到其他API，这使Kubernetes可以从云中的标准调度程序请求VM容器。

其他提示还有大量用于VM容器化的新技术，例如已经提到的Kata容器，以及Amazon的Firecracker和Google的gvisor 。

结论

如果您正确实施硬租模式的改进，您将找到Kubernetes虚拟化的圣杯。 完全隔离工作负载，无需额外费用。

如果您不使用公共云，您仍将获得更高资源利用率的好处，这将以更低的硬件要求获得回报。

我们希望VMware和OpenStack能够关注并基于轻量级VM容器和相应的Virtual Kubelet实现发布管理程序。