Docker vs Kubernetes，容器生态圈现状如何？
对于近两年的容器圈， Kubernetes可以说是绝对的主角，其增长速度远超大家预期，毫无争议地赢得了容器化管理和协调的战争，容器生态圈局势基本已定。但是容器技术还有不成熟的地方，Kubernetes在全方位落地上也还有一定难度；整个容器生态市场中， Docker公司的热度已经在慢慢消退，以往的老对手VMware也在进军容器市场，目前容器生态圈和容器技术态势如何，Kubernetes发展良好的趋势下还面临什么问题？InfoQ借此机会采访了张磊老师为我们解读容器生态圈的现状。
Docker前路如何？
Kubernetes已经赢得了容器编排战，越来越多的提供商在拥抱Kubernetes。而2018年3月份，在Docker公司刚满五周岁的时候，创始人Solomon宣布离职，更多的人开始质疑Docker。但是不要忘了， Docker公司才是这些“拥抱Kubernetes的提供商”最具有分量的那位。更何况早在一年前，Solomon就已经开始不负责Docker公司的具体业务了，所以他的离任在公司层面不会产生太多影响。而Solomon此前在Docker公司所做的一系列举措，实际上就是一次赌博。一家技术创业公司身处以小博大的处境，做出这样的决策其实并没有太大的问题。相信彼时的CoreOS等竞争对手，也曾一度笼罩在Docker公司赌赢的恐慌中。即使到了最后，做出牺牲的只是Swarm等几个具体项目，Docker公司还是完成了预期的战略转型。
而另一方面，Docker公司一向擅长的开发者关系工作，依然保持着强大的战斗力，这是云计算尤其是公有云提供商的核心竞争力之一。尽管迫于形势Docker公司目前主要专注于企业服务等更加现实的业务上，一旦有某些公有云厂商回过神来，Docker公司的这部分价值会立即凸显出来，我们不妨拭目以待。
在技术层面上，containerd项目距离成为Kubernetes下一代默认容器运行时只差了一层窗户纸。LinuxKit项目则成功牵制了Unikernel的崛起势头，还进一步完成了Docker on Mac和宿主操作系统封装的重要任务。如果说Docker公司的势头在2015年到2016年期间达到了巅峰，那么现在充其量也只是有所衰减，并且依然是容器技术圈的执牛耳者。更何况， Docker公司的巅峰，已经超越了现有任何基础设施领域开源公司所能达到的高度。
相比Kubernetes项目的强势崛起等因素，CoreOS公司提前被收购才是目前Docker公司面临的现实障碍。作为Kubernetes社区的标杆玩家， CoreOS的收购案几乎划定了这一领域并购的天花板。在这样的背景下， Docker公司要突破这个天花板倒不算困难，但要重现当年微软40亿美金报价的无限风光，希望就非常渺茫了。
Kubernetes落地的技术障碍
作为基础设施领域的系统软件，工作层级太低是目前Kubernetes在更多场景中落地的主要技术障碍。
这就好比在Google内部，我们所熟知的基础软件如MapReduce， GFS, Dapper, BigTable, Spanner等都依赖于Borg的存在。Kubernetes的工作层次使得它在落地的过程中表现出来的侵入性非常强。很难去真正接管用户的全套基础设施体系来发挥出它的“容器化“能力。
另一方面，很多团队（包括很多技术能力很强的团队）在落地Kubernetes项目的过程中也存在一些误区，比如依然试图按照“试点测试”、“定制开发”、“内部推广”的思路来在运作这个开源项目。而实际上，Kubernetes项目的核心乃在于它鼓励的并不是单纯的“用”，而是深入的“玩”。它是在从代码层面保证参与者成为整个生态的一部分，这跟之前大部分基础设施开源项目的设计都是不太一样。
这也意味着，只有能“玩”好Kubernetes，才能真正保证团队在这次容器技术的浪潮中站稳脚跟。事实上，无论Microsoft、RedHat、CoreOS，还是Google，都不是Kubernetes的典型用户，但这并不妨碍他们成为这个领域数一数二的“玩家”。这其中的微妙差异，正体现了所谓的基础设施项目的“民主化”设计思路。
至于其他的功能或者性能问题，以目前Kubernetes生态的体量来说，基本上不存在非常困难的状况。但是如何能够鼓励用户以“白盒”化的方式去“玩好”Kubernetes项目，改变目前用户落地Kubernetes项目的思路，则是一个非常值得深入探讨的话题。
混合云环境不是目前Kubernetes项目的主旋律
虽然Kubernetes创始人Craig McLuckie说Kubernetes促成了多云， VMware也已经和Pivotal还有Google Cloud合作推出了PKS (Pivotal Container Service)，可以监控Kubernetes节点，适合多云环境，但是“跨混合云和多云环境”本质上是与公有云巨头，也就是Kubernetes和CNCF背后几位重要的支持者的现阶段利益（最大程度的争取最大规模的开发者）是相悖的。
所以不难理解，混合云的支持还不是当前Kubernetes项目在技术上需要关心的重点。当然，作为一个完全中立的Linux基金会项目，生态参与者们如何将Kubernetes应用在混合云的环境中是一件完全自主的事情。这当然也是Craig为之背书的主要原因：Heptio的解决方案必然是没有厂商锁定的。
所以，在确保用户只vendor lock在Kubernetes本身而不是某朵云的前提下，混合云的市场还是要交给vendor去打，比如这里提到的Heptio和VMware。Kubernetes社区中也有多集群联邦管理的能力在推进（注意：这个项目目前已经被RedHat基于Kubernetes的插件特性改造成了Multi-Cluster项目）。但这些并不是Kubernetes社区的主旋律，就目前情况而言，这个社区里还有很多更重要也更令人兴奋的事情要做。但需要指出的是，随着Kubernetes项目和社区的进一步成熟，以及网络、存储和多租户特性的完善，多集群管理的优先级必然会在未来得到提升。
在Kubernetes基础上的技术二次创新才是容器生态的焦点
我在总结2017年的容器生态圈的文章里说到在新的一年“曾经在国内外普遍开花的、以直接售卖Kubernetes集群为核心的各种‘CaaS'，将会沉寂许多”，但市面上从微软Azure到国内的腾讯云华为云都在提供“容器+Kubernetes"服务。对此我仍然坚持自己的看法：
Kubernetes已经成为了所有公有云提供商的标配，但这并不意味着2018年依然是“CaaS”们的春天。事实上，对市场变化更加敏感的容器创业公司们基本上都已经关停了公有“CaaS”服务，转而专注于企业落地或者咨询业务。而现今的容器技术圈子里真正“风声水起”的，早已不是Kubernetes业务本身，而是以Kubernetes为基础所构建出来的整个容器技术二次创新的生态。
我们不妨先来看Microsoft。2018年，Azure产品线上着重发力的明星业务是ACI（Serverless Container服务），重点推广的开源项目是virtual-kubelet（ACI的Kubernetes插件）和Brendan Burns自己的Metaparticle （Kubernetes的SDK）。尽管覆盖面并不相同，但这些产品的本质都是围绕着Azure本身的Kubernetes服务（ACS）逐步构建起来一系列Serverless业务，最终目的则是覆盖从开发者到运维人员的完整业务流程，对用户屏蔽学习曲线陡峭的Kubernetes API。
然后来看Google。Google Cloud在2018年专门创建了一个名为GoogleContainerTools的GitHub Organization，在短短几个月内密集发布了一系列基于Kubernetes的容器技术工具，这包括了Kubernetes集群专属的镜像制作项目kaniko和持续集成项目skaffold。而在Kubernetes社区， Google在重点发力的项目则是Metacontroller，这是一个帮助用户快速编写符合Kubernetes编程范式的API插件的工具。
此外，Google Cloud基础设施团队还在最近开源了基于用户态操作系统内核的gVisor容器项目，开始进入容器运行时安全这一新兴领域。作为Kubernetes的发起者，Google这一系列举措的目的不言而喻，我们不妨小小预言一下：Google Cloud的Serverless服务很快就会与大家见面了。
我们再来看Heptio。Heptio从创立一开始就推出的一系列开源项目，统统指向了Kubernetes集群运维这一传统痛点：Ark, Contour, Gimbal, Sonobuoy，分别对应Kubernetes集群备份与恢复，负载均衡，Ingress和配置管理，堪称Kubernetes项目的“运维全家桶”。而Heptio也于近日放弃了原本在sig-scheduling的日常管理权限，转而专注于sig-cluster-lifecycle （集群部署）的工作。不难看出，同样作为Kubernetes创始人之一，Joe Beda的思路清晰而明朗。
而CoreOS在被RedHat收购之后在社区的首次发声，则是高调宣布了Operator Framework计划。把已经在Kubernetes社区取得了显著成绩的Operator推到了一个全新的高度，大有一统作业管理领域的野心。这个举措看似微不足道，实际上却意义重大，要知道，Kubernetes作业管理领域的领导权，近乎等同于把持了Kubernetes项目的用户入口。这并非痴人说梦：同样的故事已经在前Deis的Helm项目上上演过一次，而CoreOS只不过把这个故事复制在了使用场景更加的广泛的有状态作业上而已。
上述四位不同体量的Kubernetes玩家，正是当前整个容器技术圈的一个缩影。事实上，我们已经强调过很多次，Kubernetes项目不会成为一个新的PaaS，它的设计初衷，不是直接在公有云上抢夺用户入口；它的发展过程，也不需要迎合诸如“Build Ship Run”、CI/CD、“不可变基础设施”等容器领域的热词。
Kubernetes的现状和未来，是成为云计算领域基础设施的核心依赖，然后进一步催生出构建于其上的“容器化革命”。在云计算平台竞争日趋严酷的大环境下，单纯基于Kubernetes的容器化PaaS（或者“CaaS”），是完全不足以拉开不同服务商之间的差距的。而构建于Kubernetes之上的工具链、Serverless Container Instance、Secure Container Runtime、ACI、Fargate、FaaS们才是接下来云平台上争抢用户的主角。
虚拟化容器技术很可能在Serverless场景成为主流
2017年年底，OpenStack基金会于KubeCon峰会正式发布基于Apache 2.0协议的容器技术KataContainers项目，主要目标是使用户能同时拥有虚拟机的安全和容器技术的迅速和易管理性。需要明确的是， KataContainers并不是OpenStack基金会自己推出的项目，而是Intel ClearContainer和Hyper runV两个独立项目合并之后的产物。这个项目本身目前托管于OpenStack基金会并接受OCI的指导。以KataContainers为代表的Secure Container Runtime，目前是Kubernetes社区最高优先级的特性之一，并会以API的方式固化在Kubernetes项目中，其重要性可见一斑。
这其实很容易理解，前面已经提到过，公有云上的容器产品之争，将会以各种形态的Serverless为主旋律。而多租户场景下高效的容器管理，Secure Container Runtime几乎是唯一的选择。毕竟，传统玩法先创建虚拟机再创建容器的执行效率，在Serverless场景下可谓捉肘见襟。而Secure Container Runtime无需虚拟机做宿主的关键特性，几乎就是为这种业务而生。无需多做猜测，未来世界上主流的公有云提供商都会上线Serverless Container服务，其中将有很大一部分会基于KataContainers或者类似技术来提供安全的容器环境。
另一方面，基于虚拟化的容器技术为多租户下的容器化业务提供了全新的可能，不同业务运行在不同的Guest Kernel之上、甚至Linux和Windows业务在同一宿主上混部，都是虚拟化容器的拿手好戏。更有甚者，譬如Google gVisor和Hyper linuxd项目，会选择直接在用户态运行定制后的Guest Kernel，从而在保证虚拟化级别的隔离能力的同时进一步降低Sandbox带来的性能损耗，在诸如Serverless等特定场景里，这样的安全容器技术将很有可能取代Docker成为主流，甚至间接促使诸如GAE等传统PaaS产品的“重生”。