2017 年是容器生态发展上具有里程碑意义的一年，AWS、Azure 和 Alibaba Cloud 都相继在其原有容器服务上新增了 Kubernetes 支持，而 Docker 也在今年 10 月宣布同时支持 Swarm 和 Kubernetes。有人说，容器编排大战就此宣告结束。那么，Google 的 Kubernetes 为何发展如此迅猛，而 Docker 公司为何改变了最初的决策，如此红火的容器生态发生了怎样的变化？
Kubernetes 的“开挂”之路
2017 年 Kubernetes 共发布了四个版本，在多用户、多负载、安全性、使用易用性等做出了改进：
Kubernetes 1.6 伸缩性 SLO 支持包含 5000 个节点（15 万个 Pod）的集群，可以将多个 Kubernetes 集群结合并通过单独的 API 端点使用，发布一系列高级调度和全面的存储自动化功能。
Kubernetes 1.7 推出 Network Policy API，并加强了网络安全性，以 beta 版提供了存储和由状态工作负载的管理、API 聚合层。
Kubernetes 1.8 版本在安全方面做出了努力，曾经在 1.6 版本处于 beta 状态的基于角色访问功能已经稳定，新增 beta 状态的 Pod 横向自动伸缩自定义功能，允许源码树外（out-of-tree）的卷驱动，架设 Kubernetes 集群的命令 kubeadm 加入了集群升级的支持。
Kubernetes 1.9 版本全面提供了 App Workload 应用编程接口、新增对 Windows 系统的支持、并在存储方面新增了 Container Storage Interface 功能。
Constellation Research 公司首席分析师、副总裁 Holger Mueller 表示，CSI 的演化可能是目前 Kubernetes 最重要的新功能。他指出，Kubernetes 在过去几年中实现了跨越式的发展，设定了一个非常高的标准，成为一个快速赢得关注、“不到两年时间内从零到发展成为明确领导者”的标准。
Kubernetes 于 2014 年 6 月开源，在 Docker 公司推出著名开源项目 14 个月之后。早期 Kubernetes 受到了 Google 内部 Borg 系统的影响，Google 称其已经使用了十余年容器化技术，而坊间流传 Borg 才是 Google 的内部容器管理系统。早在 2015 年，Kubernetes 还尚不如现在般成熟，其发布版本等相关消息也很少被业界提及。而 2015 年 7 月，Google 做了一个非常明智的决定，与 Linux 基金会合作创立 CNCF 基金会（Cloud Native Computing Foundation）并捐献 Kubernetes 作为种子项目。再往后，Kubernetes 在开源社区中呼声不断升高，各大 IT 巨头相继加入 CNCF 基金会，从此 Kubernetes 进入了势不可挡的发展期。
Docker 的变革
Docker 在 2017 年也是动作不小，先是 4 月份将项目重新梳理并拆分为 Moby 和 LinuxKit，再是 10 月份宣称同时支持 Swarm 和 Kubernetes。
虽然更名为 Moby 让广大开发者一片哗然，但是 Rancher 的 Darren Stepherd 在其 tweet 中总结到：“被 Moby 困扰了吗？简单说，这对 Docker 的使用者而言没有什么变化。这样的项目在内部做了改变，可以帮助如 Rancher Labs 的系统构建者。”Docker 公司经过此番改革之后，使用者可以通过需求定制一款自己的容器系统；而 Docker 二进制文件并没有改变，用户并不会受到影响。
2017年10月DockerCon上传来另一重磅消息，经过与Google一年的合作，Docker宣布支持Kubernetes，可以在同一个集群中运行Kubernetes和Swarm。大会邀请到了Kubernetes 核心作者 Tim Hockin，他在大会上说道“如果没有Docker，就没有Kubernetes’这种说法并不夸张。在大家看来，容器技术发展四年，已经很久了。但是，实际上今天建立分布式系统依然很难，开发者们依旧很难一起快速地搭建可靠的、可扩展的应用程序。未来还有很多需要做的事情，我相信：这仅仅是一个开始，接下来（双方的）合作一定会给大家带来更多。” 而Docker创始人Solomon Hykes则表示“渐渐地我们意识到，我们是同样的一群人，关注的是同样的事情，我们争论并希望解决的都是同样的问题。我们就像一个大家庭，这次其实更像是家庭的团聚。”
12月，Docker拆分Docker Engine后捐献的containerd也正式发行1.0版本，添加了包括创建压力测试系统、垃圾收集和填充内存使用等性能改进。这意味着Docker兑现了他一年前的承诺，containerd是可以用于工业级的容器运行时标准。
CoreOS重新启程
在Docker推出其火爆的开源项目之后，CoreOS于2013年10月开源了其Container Linux，一款基于Linux Kernel的轻量级操作系统，该系统旨在为集群部署提供基础架构，同时侧重于自动化、易于部署应用程序、安全性、可靠性和可扩展性。作为轻量操作系统，Container Linux仅提供在软件容器内部署应用程序所需的最小功能，以及用于服务发现和配置共享的内置机制。Container Linux还提供了一个守护进程etcd，它运行在集群中的所有计算机上，并提供一个动态配置注册表，允许在集群成员之间轻松可靠地共享各种配置数据。最初CoreOS与Docker紧密合作，但是后来认为Docker不满足于“一个简单的基础单元”，在2014年底推出开源容器引擎Rocket（简称rkt）。
而2017年，rkt派系的CoreOS舍弃掉自己调度工具Fleet，将重心转移至Kubernetes，并在刚刚发布了商用Kubernetes平台Tectonic1.8版本，新增开放云服务，可以进行维护、自动化、修补和升级等，而且可以跨裸机、本地数据中心、公有云等多样环境运作。
依然在坚持的Mesos
比Docker的Kubernetes支持举措早一个月，Mesos今年九月也宣布了对Kubernetes的支持，其平台用户可以安装、扩展和升级多个生产级的Kubernete集群。对此Mesosphere CTO Tobi Knaup称此举是为了让客户们可以有更多的编排系统选择。“我们的客户是运维团队，有时他们需要支持上万个开发者，他们需要多样化的软件，不应该将他们局限在一个选择之中。选择非常重要。”
要知道Mesos的Marathon可是第一个Docker容器的编排系统，比Swarm和Kubernetes都要早。在容器发展的早期，很多人会选择Mesos来解决容器的编排问题。Apache Mesos的商业版本是DCOS，这家在第四轮融资1.12亿美元的公司拥有来自HPE、微软等强力支持，Mesosphere毫不隐晦其DCOS的目标是在全球拥有2000个客户。目前，Mesosphere也确实拥有不错的成绩：美国十大金融服务公司中五家公司、北美十大银行中五家银行、全球十大通信运营商中五家、六个最大connected cars的汽车制造厂商都选择了Mesos。而IT公司如Autodesk、yelp、当当网、豆瓣网也其忠实用户。
在2017年的KubeCon主题演讲中，Kelsey Hightower讲到，运维不要指望仅靠一个共享集群就能满足所有人，Google的Borg系统并不是这么设计的。对此，Mesosphere的产品市场经理Chris Gaun评价道：“Kubernetes并不是孤岛，最少它需要与CI/CD方案结合在一起，在此基础上，如果能够配以现代化的高效数据服务和基于机器学习框架的解决方案，则会让用户更加满意。”
Rancher的重大转变
Rancher Labs致力打造操作系统级别的虚拟化工具，其中最为著名的是Linux容器。Rancher Labs公司成立与2014年，它有两款产品即Cattle 是 Rancher自有的Docker容器管理平台，RancherOS轻量的开源容器Linux操作系统。
曾经，Cattle是Rancher内置的编排系统，并也支持Swarm、Mesos、Kubernetes编排系统；但是今年，和CoreOS类似，Racher推出了其2.0版本的容器管理平台并宣布all-in Kubernetes，2.0版本基于Kubernetes设计了UI，有对CLI、AP、Docker Compose的支持，还可以导入并配置自有或第三方云厂商的集群。
Rancher Labs CEO梁胜在一次媒体采访中说到：“许多客户都拥有Kubernetes集群，但是他们并没有Google般理想的均一化架构。他们需要控制访问的工具，以区分不同团队、不同项目和不同应用。他们需要一个集中控制台，以处理不同类型的基础设备；Kubernetes在这上面依然不尽人意，Kubernetes提供的都是自有的监控配置和网络驱动，这需一个普适的解决方案。”
IaaS厂商也纷纷支持Kubernetes
Google虽然内部使用的是Borg系统，但是其公有云容器服务采用Kubernetes作编办系统。与Kuberentes升温曲线，比较有趣的巧合是在Gartner的IaaS厂商魔力四象限中，创立于2011年的Google云从2014年时与IBM等其他数家厂商在Visionaries象限优势微弱，到2016年Google云则独占Visionaries象限，而在2017年Google云则在Visionaries象限中保持一定优势。
今年，Azure于二月份、IBM于三月份、Oracle于九月份、阿里云于十一月、AWS于十二月宣布正式支持Kubernetes。其实上述厂商也都已经是 Docker的合作伙伴，并提供了相关的企业级产品服务，如提供Docker Enterprise Edition（Docker EE）支持。除了常见的微服务、应用迁移场景之外，AWS、Azure、阿里云的容器服务也支持机器学习场景。而Google、IBM和Oracle则直接提供了AI平台化服务。另一方面，AWS、Azure、阿里云、Google云等厂商在公有云上所提供的容器服务近乎免费（Google），收费的只是用户消耗的资源，关于容器编排管理的市场价值我们会下段有所提及。
Kubernetes与Docker是敌是友？在容器生态发展的层面，这或许是个伪命题
创业公司Docker被估值10亿美元，它提供了容器运行时几乎被默认为事实标准。而另一方面，Google的Kubernetes似乎赢得了编排引擎之争。通常人们认为编排系统一层会带来巨大的市场收益，所以人们都说Kubernetes对Docker造成了直接威胁。而在Cloud Technology Partnership 的首席架构师兼Forbes观察员Mike Kavis看来，真正有市场价值的是整个的PaaS/CaaS平台，而编排系统只是其中一层而已。真正应该与Docker相提并论的应该是VMWare、CloudFoundry等，Docker盈利模式应该是对应的支持服务。
相信不少人记得去年Kelsey Hightower和Solomon Hykes的Twitter争执，其中的建设性批评应该在一定程度上帮助Docker重新审视其产品规划。现在Kubernetes成为了Docker的赋能者；曾经任职Google 的Docker现任首席布道师Patrick Chanezon在一次采访中表示，早些时候Kubernetes的安全性能仍然有待提高，现在情况得到了改善。
Juilia Evans在其tweet上贴出了一张Kubernetes components示意图。
对于开发者而言，多家编排系统相互支持是皆大欢喜的事情。开源届英雄辈出，动态和趋势此起彼伏，连曾经公开“吵红脸”的Kubernetes和Docker都已经不计前嫌，旁人何须再纠结于过往。
而Google和Docker等容器玩家更关注的是如何将成熟的容器化技术服务于企业，正如Tim Hockin说道“实际上今天建立分布式系统依然很难，开发者们依旧很难一起快速地搭建可靠的、可扩展的应用程序。”
结语
容器技术的价值在于开放的社区、开放的生态。如果说容器圈今年的主旋律是什么？应该就是标准化。Kubernetes的成功在于其开放的社区政策，在于实现了开放的容器编排标准。而Docker也终于在12月份提交了容器运行时标准 containerd 1.0。
标准化，意味着人们对这件事已经达成共识，并愿意在此基础上进行协助创新。不需要再去争吵，不需要再各自造轮子，业界整体得以更高速有效地积累经验和拓展新领域，从而进入稳定的成长期。
Market Share 和 Mind Share是不同的概念。开源社区中呼声甚高的 Kubernetes 可以说在 Mind Share 上完胜，它赢得了越来越多开发者的芳心；“不战而屈人之兵”，它的市场自然也会随之升温，这也是为什么几乎各大云厂商都陆续决定提供Kubernetes编排服务。
一个开发者的项目想获得商业的成功，必须要首先在开源社区中得到认同。在开源社区，大家可以得到最真切和最‘刺耳’的建议，Show your code please，没有哪里比这里更相信技术实力。GitHub曾经在一次媒体采访中说道：“开源社区已经发展出了自己的社会结构，而且这种社会结构还在不停地进化中。如果你没有全程参与进去，迟早你会被历史的进程所抛弃。” 今天，恐怕没有哪个IT厂商会逆行倒施。
在12月初刚刚结束的KubeCon上，许多主题演讲者屡次提到‘boring’一词，并表示让Kubernetes走向成功需要再次让这个项目变得枯燥无味。有些抱怨者说，除非对构建互联网分布式系统略知一二，否则Kubernetes是个难以理解和使用的项目，这是一个很复杂的系统。难道Kubernetes就不能不这么‘boring’吗？“这恰恰是一直以来的目标，在需要的地方创立Kubernetes，然后由此发展相关生态体系，而这个核心部分需要保持无聊。”Kubernetes布道师Kelsey Hightower说道。同时，红帽公司的Clayton Coleman也表示，开发应用才是令人兴奋的环节，但是运行应用这个环节需要无聊。
It is getting boring and getting good. 八卦和谈资越来越少的时候，正是人们在安心做事的时候。业界都关心怎样能通过容器技术带来应用层创新，带来更多的价值。未来，让我们拭目以待。
备注：本文转载自InfoQ高效开发运维，原文链接。
