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 产品的“重生”。