Kubernetes这项技术对于我今年的职业生涯而言可谓至关重要，相信其重要意义在新的一年中还将继续保持。值此辞旧迎新之际，请大家允许我结合个人体会做出一点大胆的预测：Kubernetes的未来在于虚拟机，而非容器。
2018年是中国十二生肖中的狗年，同时也是技术层面的Kubernetes元年。如今，学习Kubernetes的朋友已经为数不少，各公司的CIO也在努力制定自己的“Kubernetes战略”。更有部分组织已经开始在Kubernetes上运行大规模生产工作负载。
如果您刚刚尝试建立Kubernetes策略，那么您恐怕已经失败了——我们会在后续文章中就此展开探讨。
换句话说，在Gartner为Kubernetes提出的炒作周期各个阶段当中，都有很多人陷入了幻灭的低谷甚至是绝望的陷阱。
我个人正是容器技术的忠实粉丝，我也绝对不是说容器技术会走向消亡。Docker于2013年为我们带来了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能够提供的只是一种“软租户”模式。
抽象泄漏。建立在容器之上的平台会继承容器技术的诸多软租户因素。正如建立在硬多租户虚拟机基础之上的平台(包括VMware、Amazon Web Srevices以及OpenStack等)，也都继承了这种硬租户机制一样。
Kubernetes集群本身成了“硬租户”面临的***道坎，也因此导致大部分用户只能使用“多集群”这一新兴模式，而非“单一共享”集群。相信很多朋友都发现了，谷歌GKE Service的用户往往需要面向多个团队部署数十个Kubernetes集群，有时候每一位开发者都拥有自己的集群。这类作法最终导致了严重的Kube泛滥问题。
“这类作法最终导致了严重的Kube泛滥问题。”
通常来讲，我们使用的最小集群包含四台设备(或者虚拟机)。其中一台(或者三台，用以实现高可用性)作为Kubernetes主节点，另外三台作为Kubernetes工作节点。这不仅会带来极高的资金成本，同时也使得大部分系统资源长期处于闲置状态。
因此，我们需要以某种方式将Kubernetes转换至硬租户模式。Kubernetes社区对于这种需求有着明确的认知，也建立起专门的多租户工作组。该小组一直在努力解决这个问题，并针对各类可行模式给出了多种改进建议。
针对速度进行优化的小型虚拟机更为可行……
Kata Containers是一个开源项目与社区，致力于构建轻量极虚拟机的标准实现方案。其使用感受与执行效果与容器类似，但能够提供与虚拟机相同的工作负载隔离能力及安全优势。
Jessie建议使用Kata Containers这类虚拟机容器技术。Kata Containers将虚拟机级别的隔离机制与容器的执行及起效方式加以结合。如此一来，Kubernetes将能够为每个租户(我们假定每命名空间一个租户)提供运行在嵌套虚拟机容器(即由底层IaaS提供，运行在虚拟机之内的容器)内的一组独立Kubernetes系统服务。
image from Jessie Frazelle - Hard Multi-Tenancy in Kubernetes
这可谓是一种优雅的Kubernetes多租户问题解决方案。Jessie甚至进一步建议Kubernetes使用嵌套容器虚拟机处理运行在Kubernetes之上的工作负载(Pod)，从而大大提高资源利用率。
在这方面，我们至少还能够做出一项深层优化，即为底层IaaS或云服务供应商构建合适的虚拟机管理程序。如果其中虚拟机容器代表着由IaaS提供的***层抽象，那么我们甚至能够进一步优化资源利用率。具体来讲，我们可以将运行Kubernetes集群所需要的***虚拟机数量减少至一个(或者三个以实现高可用性)，并用以承载开放给“超级用户”的Kubernetes控制平面。
资源(成本)优化型多租户机制
配合两个命名空间并运行有多款应用程序的Kubernetes集群将如下所示。
注意：同一IaaS基础设施之上还运行有其他云用户的工作负载。由于这些属于虚拟机容器，因此其拥有与常规云虚拟机相同的隔离级别，因此，它们能够以***风险运行在同一虚拟机管理程序之上。
起初，云基础设施上的部署量为零，因此超级用户的成本也为零。
该超级用户从云端请求Kubernetes集群，云服务供应商负责创建单一容器虚拟机(或者三个容器虚拟机以实现高可用性)以运行主Kubernetes API与系统服务。超级用户可以选择在系统命名空间当中部署Pod，或者创建新的命名空间以分配面向其他用户的访问。
超级用户创建两个命名空间，分别为foo与bar。Kubernetes从云端为每个命名空间的控制平面(即Kubernetes API与系统服务)请求两个虚拟机容器。超级用户为各用户分配该命名空间的访问权限，从而允许这些用户各自部署一部分工作负载(Pod)，而用户自己的控制平面又进一步请求用于运行这些工作负载的虚拟机容器。
在整个执行流程当中，超级用户只需要为实际消费的资源付费，云端可供用户使用的全部容量皆归云服务供应商所有。
其实这并不是什么新鲜事物……
云服务供应商们已经在努力实现上述目标。关注开源社区动态的朋友肯定已经发现了相关迹象。(更具体地讲，亚马逊希望通过Fargate达到的正是这一效果，只是并未公开宣布。)
***个迹象就是Virtual Kubelet，这款开源工具旨在模拟kubelet。其将Kubernetes与其它API相连，从而允许Kubernetes从云端的容器虚拟机调度程序处请求容器虚拟机。
其它多种新兴虚拟机容器技术中也存在着类似的迹象，包括之前提到的Kata Containers、亚马逊的Firecracker以及谷歌的gvisor等等。
总结
将正确的改进效果同Kubernetes硬租户模式相结合，大家将真正发挥Kubernetes的全部潜能。Kubernetes工作负载的全面隔离与每Pod成本消费模式将最终使Kubernetes成为工作负载运行的***选项。
对于并没有使用公有云的朋友，虽然业务体系中不存在基础设施供应商(这种情况下，基础设施将由您自行提供)，因此无法获得同样的容量消费模式，但大家仍然可以通过这种方式实现资源利用率提升与总体容量需求削减。
我们也热切希望VMware与OpenStack关注这一趋势，并为我们带来基于虚拟机管理程序的轻量级虚拟机容器技术以及理想的Virtual Kubelet实现方案。
