Kubernetes的未来是虚拟机

18-12-27 banq
                   

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

中国的十二生肖认为2018年属于狗年,技术上是属于Kubernetes的一年。现在有很多人只是在学习Kubernetes。各地的CIO都在努力制定“Kubernetes战略”。一些组织已经在Kubernetes上运行大量生产工作负载。

换句话说,在Kartnetes的Gartner Hype Cycle的每个阶段都有很多人。许多人陷入了幻灭的低谷,或者陷入了绝望的陷阱。

我是容器的忠实粉丝,我不会试图暗示容器已经死了。Docker在2013年带给我们的是基于Linux容器的包装。他们向我们展示了一种构建,打包,共享和部署应用程序的惊人新方法。这是在我们开始认真对待持续交付的恰当时机。他们的模型非常适合现代交付管道以及PaaS和后来的CaaS平台的出现。

Google已经在很长一段时间内使用(或多或少发明)容器。他们开始构建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 Services,Openstack等)。

Kubernetes集群本身就成了“硬性租约”的一条线。这导致了是一种“许多集群”,而不是“一个大共享”集群的新兴模式。看到Google GKE服务的客户为多个团队部署了数十个Kubernetes集群并不罕见。通常每个开发人员都有自己的集群。这种行为会导致令人震惊的Kubesprawl数量。

通常,您获得的最小集群是4台计算机(或VM)。Kubernetes Master的一个(或3个HA),Kubernetes Worker的三个。这在系统中占了大量资金,而这些系统大部分只是闲置在那里。

所以我们需要以某种方式将Kubernetes转移到硬租赁模型!

Kubernetes社区非常了解这一需求,并拥有一个多租户工作组。这个小组一直在努力解决这个问题,他们有几个建议的模型和建议如何解决每个模型。

Jessie Frazelle撰写了一篇 关于这个确切主题的博客文章,这篇文章非常棒,因为她比我更聪明,所以我可以将你与她联系起来,并为自己节省了十年的努力学习,试图赶上她。如果您还没有阅读,请在这里停止阅读并先阅读。

只需制作针对速度优化的小型虚拟机

Jessie建议使用VM容器技术,例如Kata Containers

Kata Containers是一个开源项目和社区,致力于构建轻量级虚拟机(VM)的标准实现,感知和执行类似容器,但提供VM的工作负载隔离和安全优势。

Kata Containers结合了虚拟机级别隔离,可以像容器一样执行和执行。这允许Kubernetes为嵌套的VM容器(在底层IaaS提供的VM内运行的VM容器)中运行的每个租户(我们假定每个命名空间的租户)提供自己的一组Kubernetes系统服务。这是Kubernetes多租户的优雅解决方案。

她的建议甚至进一步表明Kubernetes使用嵌套的容器虚拟机来运行Kubernetes上的工作负载(Pod),从而大大提高了资源利用率。

我们在这里至少还有一个优化。为底层IaaS或云提供商构建合适的Hypervisor。如果VM容器是IaaS提供的第一级抽象,那么我们甚至可以进一步提高资源利用率。运行Kubernetes集群所需的最小VM数量下降到一个(或三个HA)以承载暴露给“超级用户”的Kubernetes控制平面。

资源(成本)优化多租户​​​​​​​

具有两个名称空间的Kubernetes部署都运行了许多应用程序,最初,部署到云的基础设施为零,因此超级用户的成本为零。

超级用户从云端请求Kubernetes集群。云提供商为运行主Kubernetes API和系统服务创建单个Container VM(或3个用于HA)。超级用户可以选择在系统命名空间中部署pod,或者创建新的命名空间以委派对其他用户的访问权限。

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

在此的所有阶段,超级用户仅支付实际消耗的资源。云提供商拥有云的任何用户可用的容量。

没有新东西

云提供商已经在努力实现这一未来。您可以通过观察开源社区中发生的事情来看到这种情况。(可以说亚马逊已经与Fargate不透明地做了这件事)。

第一个提示是Virtual Kubelet,它是一个开源工具,旨在伪装成一个kubelet。它将Kubernetes连接到其他API。这将允许Kubernetes从Cloud的Container VM调度程序请求Container VM。

其他提示包括新兴VM容器技术的数量,已经提到的Kata容器,还有来自亚马逊的Firecracker和来自Google的gvisor

结论​​​​​​​

与Kubernetes硬租赁模型的正确改进相结合,您将获得Kubernetes的圣杯。完全隔离Kubernetes工作负载和纯每个Pod消耗成本模型,以在Kubernetes上运行工作负载。

对于那些不在公共云上的人,我们没有获得与基础设施提供商(在这种情况下是您自己)的容量负担相同的消费模型。您仍然可以获得更高资源利用率的好处,这可以降低容量需求。​​​​​​​