如果说2017年的容器技术圈子只能用一个关键词来概括的话，那一定非“Kubernetes”莫属。
从2017年2月，“Kubernetes”开始频繁登上各大技术媒体头条，来自不同维度不同渠道的商业分析和技术文章也纷至沓来。有趣的是，无论是官方报道还是个人评述，无论是直接还是委婉，无一不在透露着一个同样的信息：“Kubernetes要赢！”
可是，描述这样一个连商业实体都没有的开源项目“要赢”，总是听起来有些奇怪。
“要赢谁？”
“为什么要赢？”
“赢了之后呢？”
我们不妨就从这个论断说起吧。
Kubernetes赢在何处
如果说错失了Big Data时代的Google实在令人扼腕，那么Container时代的Google终于靠开源社区打了个翻身仗。虽然在最初的lmctfy项目（Google自研容器）上依然栽了跟头，虽然同Docker公司共举容器编排大业的计划依然吃了闭门羹。但Google还是笑到了最后。
不过，Kubernetes项目的发展绝非一帆风顺。它的前期只有一篇不温不火的B类会议文章Borg来站台，远没有“三大paper”一举奠定大数据基石那么耀眼。而在它发布的之后，炙手可热Docker公司却始终拒绝同Google开展任何形式的合作。而与此同时，Mesos等一票老牌调度系统的阴影则从一开始就让Kubernetes团队心有芥蒂。种种不利因素，再加上当时Google在Kubernetes上投入资源时的捉肘见襟，无论再怎么乐观，这个“要赢”的论断恐怕都不容易成为现实，
当然，如果不是Google找到了一个靠谱的盟友的话。
这位盟友有多靠谱？它是这个世界上唯一一家年盈利超10亿美元的开源技术公司。
Kubernetes刚发起的时候，其核心的理念来自几位“Elder（元老）”的构想，他们大多是Borg和Omega项目的开发者或者架构师，一直专注于如何在没有cloud的场景下构建足够规模的通用Infrastructure Layer的实践，并且在这个领域摸索的过程中，这批技术人员也逐渐形成了一套创新性的设计理念，这些观点在Borg论文中曾经透露出了一些端倪，但真正全面揭晓还是依托于Kubernetes开源项目。所以如果大家回头去翻Kubernetes最早的一些Issue和Design，其实都是一篇篇“小论文”，思路严谨，论证充分（废话连篇），这跟大多数开源项目早期的头脑风暴，或者围绕一个核心设计逐渐展开的做法，是有很大不同的。
另一方面，彼时的RedHat正苦于自家OpenShift被竞争对手碾压的境况。经典PaaS不能破局的困难，反倒让RedHat对Docker这个有望颠覆PaaS的项目格外上心。这样一个在操作系统领域积累深厚、资源充足、并且蠢蠢欲动以求变革的开源巨头，碰上了满脑子Idea却对全面推进Kubernetes心有余而力不足的Google团队，可谓一拍即合。2014年12月，在Google正式发布Kubernetes项目不久，RedHat即官方宣布与Google开展战略合作，全面投入Kubernetes。在当时的一份官宣中，RedHat以非常自信的姿态表达了对容器的“颠覆性”创新的认可，并大胆预言Kubernetes会在2015年后取得应用编排与管理领域的统治地位：
……（RedHat的竞争对手们） 必须要认识到自研任何容器的局限性，尽早接纳Docker项目 ……
…… （RedHat的竞争对手们）必须要认识到没有人能够同Google在成规模的容器编排和管理领域里相抗衡 ……
谁曾想到，当年这套透露着几分“终于傍上大腿”的侥幸、甚至“托大”的说辞，现在看起来却几乎句句“实锤”。
这也是为何，Kubernetes虽一直大幅受益于Google的声誉和名望，还长期拥有Borg/Omega团队的技术加持，但如果从技术实现上来审视，这个项目却称得上是半个RedHat项目。也正是凭借最初阶段“Google赋予灵魂，RedHat赋予实体”的策略，Kubernetes才能够秉持着天马行空的设计思想的同时，稳扎稳打，然后一步步崛起于社区。
如今的Kubernetes，既赢得了GitHub等众多明星用户的青睐，也受到了全世界所有公有云巨头的热捧，还硬生生把Docker公司逼到改旗换帅、彻底摒弃了以往“暴力不合作”的路线，如果用一个“赢”字来描述它现在的情形，倒也并不为过。不过，这个“赢”字背后的原因，又在哪里呢？
Rancher的创始人梁胜博士最近有过一句评论，可谓道破天机：
时至今日，在容器技术领域依然有许多创新，只不过这些创新大多发生在Kubernetes以及CNCF生态系统中了
没错，容器技术圈的创新能力，在2015年后就已经逐渐转移到了Kubernetes生态，这是一个不争的事实，却也是一个曾经被忽视的变化。实际上，伴随着DockerCon越来越“boring”，Kubernetes的专属生态CNCF基金会却开始风生水起的原因也正在于此。
而从技术的角度上看，Kubernetes生态能取得这样的成功，依托的乃是一项其他竞争对手所不具备的核心能力：“使能用户二次创新“。
何谓“使能用户二次创新”？这其实是Kubernetes项目从开始设计之初就高度重视的一项关键诉求：
第一：从上层API到底层容器运行时，Kubernetes工作流中的每个环节，都希望具备完善的可扩展性。
第二：Kubernetes任何功能特性的设计和实现，都尽可能针对更通用的用户场景而非特定需求。
原生“使能二次创新”的技术基础，加上Google与生俱来的技术号召力，在加上CNCF基金会的整合和商业运作，以Kubernetes为核心所建立起来的这套容器编排生态，绝不比Docker公司最初建立起来的以容器为核心社区有任何逊色。再加上容器编排与管理的概念天生就更接近用户，Kubernetes的理念很快被社区接纳乃至追捧，也是情理之中。
一个直观的例子就是CoreOS的Operator项目。我们知道，在Kubernetes里部署任务，经常使用的是Deployment（Replication）来管理多个副本组成集群。但如果我们这次要部署的任务比较特殊，它的集群需要在增/删副本之后/之前做手动的运维操作呢？各种数据库集群就是最典型的例子。而Operator实际上是个用户自己编写的管理器，通过编程的方式把“运维”逻辑写进了管理器的代码当中。但关键在于，这个管理器的编写过程是完全“无脑”的，无非就是复制粘贴官方模板、然后填充自己的运维逻辑而已。这是因为Operator是构建于Kubernetes的CRD（自定义API资源）特性之上的，这个特性的目的就是允许并帮助用户自己编写一个可以与系统etcd交互的、Kubernetes风格的API资源管理器，并无缝地衔接到Kubernetes的核心API当中。
这个设计看起来很很直白，但是却解决了一个长期以来困扰系统级开源项目的难题：用户对项目的API不满意怎么办？
在过去的实践中，原封不动使用开源项目的场景是非常少见的，更常见的情况是用户把开源项目的API修改的面目全非。但在Kubernetes的场景下，用户的自定义API和原生API可以友好共处，统一对外服务，而且不会随着upstream变更而分家。这是保证Kubernetes社区完整性和被接纳程度的一个核心手段。
更为重要的是，有了这些标准化的扩展性API，用户就可以发挥自己的能动性，在Kubernetes之上构建出更多的扩展，甚至把这些扩展再交还给社区中的其他用户推广和使用。正如CoreOS的Operator，现在已经成为了社区运维有状态应用的一大法宝。
当然，“二次创新”的例子远不止于此。
2017年5月24日，Lyft，IBM联合Google共同宣布了Istio项目，一举撼动了微服务这个以往“光说不练”的“花架子”领域。Istio的核心思想，乃是借助一个proxy来接管容器里业务的进出流量，从而通过在proxy上的控制操作来完成应用流量的切分、访问授权、策略配置等一些列微服务治理功能。可以看到，这里有一个核心问题是：如何保证每一个需要治理的容器都绑定这样一个proxy呢？
解决这个问题的手段就是Pod。作为Kubernetes里的核心概念和原子调度单位，Pod是一组亲密耦合的容器集合，容器之间共享同一Network Namespace，显然，Istio框架中的proxy和业务容器正属于这样的耦合关系。但这还不是关键所在，这里最棘手的问题在于，Istio要做的是一个非侵入型的微服务框架，不可能要求用户在自己的部署文件中每次都额外定义一个proxy容器。怎么办？
答案还是借助Kubernetes。Kubernetes中有一个叫Initializer的扩展机制，允许用户在不修改业务Pod部署描述前提下，请求Kubernetes为业务Pod“自动注入”并启动一个预先定义号的容器。在Istio里，这个自动注入的容器正是前面不断提到的proxy：Envoy（Lyft自研的高性能服务代理）。
可以看到，通过组合Initializer等一系列Kubernetes标准API，用户可以优雅地实现很多以往繁琐或者困难的分布式系统的构建工作：就比如Istio里这套Spring AOP（面向切面编程）风格的组合方式。也正是因为有了这种标准化的实现手段，用户基于Kubernetes的“二次创新”才有可能再次交还给Kubernetes社区，从而碰撞出更多的创新火花和更新颖的用户案例。最终，不断激发出的创新开始吸引了更多人力和资本的进入，而资本与生俱来的促进作用就会推动这个社区的更强势的扩张。这种“开源-社区-商业”互相促进而构建出来的正向激励循环，正是Kubernetes生态在过去一年里“势不可挡”的重要原因。
回想在Kubernetes刚发布的时候，甚至在2017年初，Kubernetes的Pod以及Pod所体现出来的“解耦容器关系”的设计模式，依然时常被质疑为“用处不大”或者“过度设计”，然后现在回头来看Istio项目的炙手可热，我们确实要感慨“技术视野”的培育绝非一朝一夕。
从利用CNI、CRI等一系列良好设计的通用接口来实现不同类型、不同功能的网络和容器运行时，到使用API Aggregation扩展Kubernetes API Server从而支持自定义资源监控格式并以此来做Auto-Scaling，Kubernetes生态之中类似的“二次创新”的例子已然不胜枚举。依托于这种原生地鼓励用户发挥自己聪明才智的先进理念，在2018年，我们有足够的理由相信“二次创新”将继续成为Kubernetes生态中的一大关键词，各种基于Kubernetes可扩展能力的创新工作将成为社区的常态，甚至成为更多团队“一战成名”的不二法宝。
在未来，已经争取到领先地位的Kubernetes项目的进化重点，将逐步转移到安全性、稳定性、多租户能力、规模和性能优化、可扩展性设计等更多横向功能的升级上面。另外，将更多的非核心功能从主干代码中移除也将是未来一段时间Kubernetes社区的主要工作之一。2017年里，随client-go、apimachinery等API库的独立，已经为CRD等可扩展性功能的实现带来了极大的便利，而将来诸如部署工具kubeadm，内置的各种Cloud Provider，内置的rkt集成，各种各样的volume plugin等代码，也都将逐步迁移到它们单独的库中维护，这将有希望大大降低Kubernetes主库的复杂度和维护难度。
另一方面，Kubernetes可扩展性上的另一个重要设计CSI（Container Storage Interface）也已经发布。这意味着不久的将来，就如同容器运行时一样，容器持久化存储方案也将不必再跟Kubernetes的核心代码耦合，Kubernetes将使用统一的gRPC接口在完全独立的控制逻辑中维护容器存储卷（volume）生命周期。这个设计也很有可能会刺激容器存储领域更多的创新工作和更多的存储选择出现在Kubernetes社区当中。而包括KataContainers在内的虚拟化容器运行时，也将受益于存储解耦带来的、完全不同于现有容器存储设计的高性能的持久化存储方案。
在接下来的集群管理能力上，目前最大5000个节点的支持能力已经能够满足大多数用户的生产需求，而IPVS Service的引入也有很大希望能解决以往纯iptables Service引发的大规模集群中性能额外损耗问题。而在调度层面，默认调度器的可配置规则已经大幅增加，调度优先级和抢占技术也已经进入了默认调度器的alpha功能当中。而通过灵活配置亲密/反亲密关系、Taint/Toleration规则，Kubernetes的使用者已经能够解决绝大多数生产环境中的运维和调度需求。
在多租户与安全能力上，Kubernetes项目终于弥补上了这部分的短板。RBAC（基于角色的访问控制）功能目前已经成熟应用于很多基于CRD的Kubernetes外部扩展上面，Secret存储的加密也已经实现，集群部署中的节点通信加密配置也成为了默认功能。而在社区中，更完善的“强多租户”设计也第一次被提出，以便真正满足多租户环境下的集群管理需求。不过需要指出的是，Kubernetes的角色定位依然是Layer 0（Infrastructure Layer），更倾向于对上提供必要的多租户支持API和规范而不是实现完整的多租户模型。后者还是需要依靠Layer 1（Service Layer）来自己完成。
2017年也是人工智能技术席卷全球的一年，Kubernetes在其中也扮演了推波助澜的作用。在与之相对应的硬件加速器（Hardware Accelerator）功能的设计上，Kubernetes社区在Google，NVIDIA和Intel的牵头下发布了Device Plugin来允许用户自己编写自定义的、自发现的高性能硬件资源描述，并且以此为基础，将支持NUMA，InfinitiBand，FPGA等硬件框架的设计纳入了路线图。随着Kubeflow等项目的发布，不难预料到，Kubernetes在新的一年里会继续加大同人工智能社区合作，向成为机器学习领域支撑大规模分布式训练和AI服务的默认框架这一目标上不断挺进，而在此过程中，各家vendor在Kubernetes社区中进行技术上的角逐，亦将成为这个领域的主旋律之一。
随着Kubernetes项目的逐渐稳定，其开发迭代周期也将有所放缓，将目前每3个月一次release周期延长已经被提上讨论日程。与此同时，随着社区自动化管理能力（bot）的提高和SIG（Special Interest Group）组织的进一步完善，现有社区成员的写权限回收也是将来可能发生的大概率事件。这些都是Kubernetes社区逐步走向成熟的标志性里程碑。
容器运行时的二次繁荣
2017年，Kubernetes引领了容器编排与管理领域的蓬勃发展，而与此同时，另一个很有意思的现象则是容器运行时（Container Runtime）迎来了一次难得的二次繁荣。
一般来说，伴随着容器编排领域的迅速发展和成熟，容器运行时技术一定会因为被上层编排框架所屏蔽而逐渐淡出用户视野。事实上，这也正是Docker公司自成立以来的心病：光有一个容器运行时Docker，并不足以吸引用户真正投入到有价值的商业产品（比如PaaS）上来，更何况容器技术本身又是一个门槛相对不高的组合性创新成果，不能形成长期有效的技术壁垒。这个事实，也正是Docker公司一定要强推Swarm和SwarmKit等项目，以及Mesosphere曾短暂取得瞩目的一个主要原因。
当然，在Kubernetes依托社区和强大的创新能力崛起之后，容器运行时和它背后的主体的淡出便成了不可避免的宿命。这也是为什么我们会看到Docker公司会宣布将它的开源项目改名为Moby，这其实是它自己宣布将要放弃在开源社区中继续同Kubernetes和CNCF社区对抗的重要信号。这也是为什么我们会看到containerd和rkt被接连捐献给CNCF基金会：各类容器运行时的历史使命已经走向尾声了。
但是历史总有意外。Kubernetes的扩展性设计中一项核心功能的确立，却为容器运行时的创新者带来了新的机遇，这就是CRI（Container Runtime Interface）。
CRI的诞生还得追溯到容器运行时第一次繁荣、也就是容器理念第一次席卷技术圈的时候。彼时，Docker公司手持Docker项目大杀四方、是当之无愧的容器技术领导者。而CoreOS公司在选择拥抱Google和Kubernetes的同时，则发布了rkt以制衡Docker，以希望维护自己在容器技术上的话语权。这两位，再加上RedHat，他们在容器运行时领域的合作与竞争，直接推动了OCI这一容器技术标准的诞生。但实际上我们不难看到，Docker公司在容器运行时领域所占据的绝对主导地位，以及OCI本身对Docker公司商业利益的不友好意味，使得OCI长期以来并没能发挥出“标准”所应起到的推动和整合作用。
也正是在这个阶段，以Intel ClearContainer和Hyper为代表虚拟化容器技术，则开始从安全和多租户角度进入到开发者的视野。一时间，容器运行时领域可谓熙熙攘攘，不胜热闹。
而在Kubernetes发布之后，很多机敏的技术人员其实已经嗅到了其中的机遇。在Kubernetes未来有大概率会成功的前提下，谁能在Kubernetes内置的容器运行时中抢占到一个位置，谁才有可能在将来的容器技术圈子中争取到一席之地。所以很快，CoreOS公司通过政治和技术双管齐下的努力下，rkt成功跻身为Docker之后第二个被Kubernetes支持的容器运行时。但也正在这时，一些连锁反应式的问题也被激发出来。
一方面，彼时的Kubernetes羽翼未丰，并没有强势到能直接帮扶起rkt这个相对弱势的容器运行时的地步，更何况当时的Docker项目正突飞猛进，没有给同质的rkt留下任何喘息和反击的机会。所以虽然很早就进入了Kubernetes体系，rkt却一直处于少有用户问津的尴尬地位。
而另一方面，在当时快速迭代、完全没有稳定的Kubernetes尤其是kubelet组件中，额外引入的rkt运行时其实带来了大量的维护工作，并且这些工作很多时候还要依赖于CoreOS的介入才能解决，这无疑给Kubernetes团队带来了很大的压力。
与此同时，Kubernetes团队本身并不希望锁定在Docker容器之上。Docker公司不断推进Swarm项目的决心，很难让人对继续使用这样一个唯一的、不稳定的、将来甚至可能会变成一个PaaS的“容器”感到放心。
在这样的背景下，适逢Kubernetes团队也开始尝试逐步在项目中引入虚拟化容器技术，能不能提供一个通用的、与下层容器运行时无关的接入层来无缝对接上述所有容器运行时，就成为了当时Kubernetes能否更进一步关键所在。更重要的是，这也是Docker的软肋之一。由于显而易见的原因，Swarm体系并没有动力去支持任何非Docker之外的容器运行时，而另一方面，彼时的OCI话语权不济，并不能发挥对接其他容器运行时的作用，这就意味着Kubernetes项目会成为对接非Docker容器运行时的唯一出路。
就这样，一套由Google，Hyper和CoreOS共同主导的、以Kubernetes项目为核心的容器运行时接口的设计，应运而生。
CRI的及时发布，使得Kubernetes团队在后续SwarmKit等事件中可以处变不惊。而它的诞生，也直接推动了容器运行时这原本应该逐步淡化的领域焕发了第二次繁荣。
cri-o与cri-containerd
这次繁荣的第一个标志性的事件，是runC容器运行时cri-o的发布。
cri-o的初衷非常直白，既然现在Kubernetes可以借助CRI对接任何容器运行时甚至虚拟机，那么我们自然会想到，为什么不直接把runC封装成一个CRI的实现呢？这样不就可以绕过现有Docker容器的大部分机制而直接操作Linux容器了么？
所以，不同于Docker，除了用来响应CRI的gRPC server，cri-o并不需要额外的daemon组件来维护Linux容器。CRI的API调用在这里被直接翻译成对runC的操作命令，然后在宿主机上创建并启动runC容器。不难看出，这个工作流其实跟containerd的功能是基本一致的，但有意思的是，cri-o的发起者RedHat并没有使用containerd而是重新造了轮子。这其中，containerd的实际维护者是Docker公司恐怕是主要的考量因素之一。
实际上，在Docker公司决定打造自己的封闭生态之后，RedHat就跟Docker公司走向了对立的一面。毕竟相比Google专注于公有云业务而不太在意企业及市场，Docker公司随后发布的每一项产品（项目），却都在不同领域实实在在争抢着RedHat的蛋糕。作为曾经一起同推进容器技术的“兄弟”，如今“分手”后的RedHat对Docker公司的负面态度是可想而知的。所以，cri-o在某些实现细节上透露出来的一些偏执，也是这种思想指导下的必然产物。从最初放出言论要“fork Docker”，到现在cri-o的实际落地，RedHat在容器运行时领域的志向目前都压在这个项目之上。这也是为何RedHat的宣传机器在2017年 可谓开足了马力，连Kubernetes首席布道师Kelsey Hightower也曾短期被“攻陷”过。
然而，开源社区里最有意思的事情也莫过于此。就在cri-o几乎要以下一代Kubernetes默认容器运行时的身份粉墨登场之时，Google和IBM以及containerd的维护者们却默默的上线了cri-containerd项目。这个项目的思路更加显而易见：鉴于containerd已经捐给了CNCF，现在只要在其基础上略微封装，就可以为Kubernetes打造一个Docker native的、身份中立的CRI实现。相比cri-o每个release都要推广一番的风风火火，cri-containerd的进展可谓低调，仅在最近的DockerCon上小幅亮相了一次，并且期间一直与cri-o保持的良好的合作关系（比如共同维护lib）。但低调并不意味着不作为，2017年底，cri-containerd项目悄无声息地开始了与containerd项目的合并计划，这意味着很快containerd本身将会原生支持Kubernetes CRI。
CRI的成功我们有目共睹，但Kubernetes下一代默认容器运行时目前却尚无定论。Kelsey Hightower一向不太“待见”Docker，他的成名作“Kubernetes the Hard Way”在短暂试用cri-o后目前还是切换到了cri-containerd上。不过这也并不足以说明所有问题，至少在未来一段时间内，“No Default”还是可以继续作为这一领域的官方说辞。
不过，cri-o本身的崛起，侧面说明了“得编排者得天下”是目前容器运行时领域进一步发展的正确思路。CRI的及时发布，使得Kubernetes团队在后续SwarmKit等事件中可以处变不惊。而它的诞生，也直接推动了容器运行时这原本应该逐步淡化的领域焕发了第二次繁荣
Kata！Kata!
这个事件，正是Hyper runV同Intel ClearContainer的合并。合并之后的项目以KataContainers命名并托管于中立基金会，为虚拟化容器技术路线之争画上了句号。
实际上，在Hyper推出了runV技术之后，部分敏锐的技术人员就迅速开始了往Kubernetes推进基于runV的虚拟化容器技术的的集成工作。相比于Swarm体系的封闭和Mesos社区的后知后觉，Kubernetes项目从一开始就展现出来的技术远见，使得这个选择倒并不意外。而这次技术行为的直接结果，则是推动了CRI这一关键特性的诞生和落地：又是一个典型的社区“二次创新”然后再反哺社区的故事。在这个过程中，kubernetes/frakti项目作为虚拟化容器运行时的官方CRI实现，正是推动这项技术进入Kubernetes生态核心的关键一步。
不过，相比于Linux容器领域的Docker项目的一枝独秀，虚拟化容器技术则有一个困扰社区许久的问题，那就是几乎同期发布的Intel ClearContainer项目一直以来跟runV处于重合位置。尽管在项目的后期，Intel和Hyper团队已经开始共同维护很多公有的子项目，但开源社区的掣肘关系依然牵制了虚拟化容器技术进入容器生态核心的步伐。
不过，明智的是，runV并没有固执地在容器API层面同Intel开展类似Docker和rkt之间的竞争，而是把原生接入Kubernetes当成了第一要务，希望借助上层编排框架来为容器运行时发声。这个策略无疑改变了社区对虚拟化容器技术在整个生态中所处位置的看法。事实上，相比于我们所熟知的硬件级别隔离和容器安全这样的常识，虚拟化容器技术的独立内核特性为Kubernetes支持遗留应用和传统业务带来的巨大的想象空间，才是这种技术最大优势所在。尤其是伴随着2017年后期“强多租户”概念被引入到Kubernetes社区，能够从容器运行时层就开始进行租户隔离的设计已经成了一种刚性需求。没有虚拟化级别的隔离能力和独立内核来保证业务的多样性，“强多租户”基本无从谈起。试想一下，在一个真正的多租户云数据中心里，有的租户的应用是Windows的，有的是Linux的，除非做低效的静态划分，常规Linux容器又该如何应对这样的需求呢？
KataContainers项目的出现，把刚刚崭露头角的虚拟化容器技术推向了一个新的阶段。作为OpenStack基金会力图革新后发起的第一个项目，托管于该基金会下面的KataContainers却不必遵守OpenStack社区任何现有的规范，其自由度和改革力度，可见一斑。而这次合并的最终促成虽然被OpenStack基金会抢了先机，但CNCF基金会则开始从OCI入手，试图将KataContainers的运行时再纳入到OCI的范畴之中。我们有理由相信，在两大基金会的通力合作之下，KataContainers的前景非常光明。
不过，更为重要的是，以KataContainers为代表的虚拟化容器技术在云计算领域的探索，正有意无意地打开了公有云的一个新篇章。
ACI，Fargate与“Serverless容器云”
在runV容器发布之后，为了验证虚拟化容器对公有云带来的变化，一个名为hyper.sh服务同步上线并随后迅速霸榜了HackerNews头条。这个服务的创新之初在于，虽然它的整个技术栈都基于Kubernetes，但是它却不对外暴露任何Kubernetes API，也没有提供任何操作console，而是让用户用本地的“hyper run <IMAGE>”指令来在云端创建和启动容器。由于使用了虚拟化容器技术，这个工作流里完全不需要虚拟机的介入，所有租户的容器直接运行在裸物理机集群当中。
虽然看起来简单，但这个设计的本质，却提供了一种容器云的Serverless的设计思路。在这个“无服务器”云的设计中，云的用户完全不必学习任何Kubernetes或者云平台API或者文档，仅靠开发者所熟悉的本地容器操作就可以完成作业的云端部署，然后按秒计费。
而在2017年，这种颇有远见的容器云Serverless开始得到了公有云巨头的青睐。这一次的始作俑者正是近年来在云服务领域出手“稳”、“准”、“狠”的Microsoft。2017年7月26日，Microsoft Azure团队宣布了ACI（Azure Container Instance）服务的发布，其通过“az container create”创建容器的思路，与hyper.sh如出一辙，并且同样屏蔽了所有下层的PaaS和IaaS概念然后按秒计费。一石激起千层浪，国外容器技术圈子对这种服务的讨论迅速成为了当时的技术头条。有人说它是AWS Lamda的有力竞争者，也有人说这才是Serverless服务的终极形态。
紧接着，在2017年11月，堪称全球云计算技术风向标的AWS re:Invent 大会上，AWS高调宣布了同类型服务Fargate的诞生，把Serverless Container Cloud的理念推向了新的高潮。作为回应，Microsoft则联合Hyper发起了virtual-kubelet项目，旨在定制一套标准，允许云提供商把自己的Serverless Container Cloud，以kubelet API的方式接入到任意的Kubernetes集群中作为一个特殊的节点而存在，从而轻松实现一个基于Kubernetes的混合云。目前，AWS、甚至OpenStack都已经加入这个项目开始贡献自己的实现，对应的基金会和开源生态正迅速形成。不出意外，很快Google、国内的阿里云等巨头，也会推出类似的Serverless Container Cloud服务，并且加入到virtual-kubelet项目当中。
Serverless Container Cloud服务备受欢迎的本质，乃在于公有云计算所服务的用户，尤其是广大的开发者群体，对于追求“简单高效”的热情其实是非常高涨的。对于他们来说，在各种设计拙劣的云管理界面上进行凌乱的鼠标操作，绝对不如在键盘上敲打本地命令来的舒服。这种微妙的体验变化，正如同git对比SVN，Docker对比OpenStack。更为重要的是，这种服务形态也正符合了Kubernetes技术继续发展的正确路线：Kubernetes所要扮演的角色，乃是取代传统的Infrastructure Layer并鼓励技术人员进行上层的“二次创新”，而并不是直接面对最终用户（实际上Kubernetes本身的声明式API也是对运维而非开发友好的）。真正为最终用户提供云服务的，很大概率应该是构建于Kubernetes之上的、更加简洁高效的服务型API，而Serverless，尤其是Serverless Container Cloud的设计，正是这种需求下最为贴切的实现方式之一。
不难预料，在新的一年，基于Kubernetes之上构建出来的创新型Serverless服务（当然也包括OpenFaaS等优秀的Function），将会是大小云计算提供商进一步角逐的一个关键领域。相比之下，曾经在国内外普遍开花的、以直接售卖Kubernetes集群为核心的各种“CaaS”，将会沉寂许多。
Docker Inc的未来
毫无疑问，2017年的Docker公司依然是容器圈子里的主角。只不过这一次，波澜之中的Docker公司的确并不好过。
从2017年4月Docker项目毫无征兆地改名为Moby开始，Docker公司顶着巨大的争议，逐步完成了开源技术创新公司到商业公司的转变，也开始正视长期以来同Kubernetes社区竞争所带来的极其不利的商业局面：伴随着Kubernetes项目的成功，Swarm已成为明日黄花，曾一度承载着新希望的SwarmKit也渐渐淡出社区视野。2017年10月，在DockerCon EU上，Docker公司官方宣布下一版本的Docker EE中将全力拥抱Kubernetes，标志着持续了近三年之久的容器编排之争彻底落下帷幕。紧接着，所有纷争的始作俑者、曾经携Docker对抗整个容器社区的Solomon Hykes也宣布自己“角色转变”，不再负责Docker产品的具体技术事宜。
曾经纷纷扰扰的容器圈子，竟然一夜之间尘埃落定，个中滋味，不免让人心生惆怅。Docker公司和Solomon的经历可能不算是传奇，但也绝对能够在云计算历史中留下了浓墨重彩的一笔。我们甚至会不时想象，如果当初Solomon没有去做Swarm，而是选择同Google合作共举Kubernetes，如今的CoreOS还会不会活着？如今的Docker公司又是什么样子？
历史难做假设。
但是Docker公司的未来却依然是光明的。
在积极拥抱Kubernetes社区之后，Docker公司正走向正确的轨道。大家不要忘记，在迎合开发者社群和技术微创新这两个关键手段上，Docker公司的实力绝不容忽视。2018年初，Docker Mac集成Kubernetes的版本正式发布，并立刻在开发者群体中掀起了轩然大波。在Mac OS上如此流畅启动和运行Kubernetes的体验，在这么短的时间内就被Docker公司带到了开发者手里，这其中体现出来的技术能力与产品理念，正是将来Docker公司继续立足的核心所在。当然，Docker公司最终的成功，依然取决于其商业产品能否赢得重量级客户的青睐，在这一点上，Kubernetes的坚定盟友CoreOS已然占尽先机并且完成了转型。但是Docker公司在容器领域不俗的创新能力和产品积累其实是有增无减，其产品线也更完整，在开发者群体中的基础也更雄厚，这样一个人气与技术兼备的创业公司的未来，绝不见得会像某些文章中描述的那样一片哀鸿。这一点，我们不妨拭目以待。
国内
相比于过去默默无闻，2017年的国内容器技术玩家终于得意发声，而且“不鸣则已，一鸣惊人”。阿里集团在双11过后，高调发布了源自其内部容器T4的开源项目Pouch，并迅速成为了当时的技术热点。事实上，早在Docker和Kubernetes技术如火如荼的2015年，业界就发出过疑问：在此领域积累深厚（百度有Matrix，阿里有T4）的国内的互联网巨头为何迟迟不见动作？
好在厂商会迟到，但技术不会。Pouch的发布，也正是前面提到的“2017年容器运行时技术二次繁荣”的又一例证。在Docker公司逐渐式微、rkt几乎退役的档口，Kubernetes的崛起和CRI的成熟正在为所有的容器运行时玩家带来全新的机会。从代码上看，Pouch并非“Docker fork”，而是利用类似技术进行的全新实现。从功能上看，Pouch原生接入了runV来提供多样化的隔离机制，内置“富容器”能力以满足不同的业务场景，打包了Dragonfly来实现高效的镜像分发，这意味着这套技术栈从底自上有着同Docker整体不一样的业务考量。
但另一方面，如今的时间点不同与2015年，用户的关注点已经从容器运行时转移到了上层容器编排管理的服务能力。而作为近来Linux容器的第三个实现（cri-o只支持Kubernetes，不能算作完整的容器实现），尽管功能上有所差异，但Pouch仍然难免会陷入同质竞争的不利局面。不过需要指出的是，阿里集团接下来亦在酝酿其内部集群管理系统Sigma项目的开源工作，并且会积极地将Sigma纳入到Kubernetes的现有生态当中，这就为Pouch未来的前景增添了一层有趣的砝码。毕竟，Pouch本身在Docker的优势地位中突围可以说困难重重，但正如前面所提到过的，如果能够借助上层容器编排能力重新表达这一容器运行时的关键作用，那这套技术方案的应用前景和接纳难度很可能会发生变化。这也正回到了我们最开始谈到“Kubernetes赢在何处”时所作出的阐述：Kubernetes社区通过从技术和生态双重层面上使能用户二次创新的做法，必将推动这个生态走向一个更加繁荣而有意义的新阶段。
总结
“任何一个被浓厚的商业兴趣所充斥的开源社区，最后都难免走向有毒的方向”
— Solomon Hykes
2017年，曾经的弄潮儿Docker公司在巨大的争议中终于完成了向商业公司的重要转变，也宣告了由Kubernetes社区所主导的、全新的容器生态正式拉开序幕。在回顾Kubernetes如何赢得这次竞争的同时，我们应该意识到容器运行时“二次繁荣”的短暂窗口正在为我们带来新的机遇。与此同时，容器公有云的形态正在悄然发生变化，伴随着这次变革而存在的，固然有风险，但也有很可能会催生出新的云计算赢家甚至独角兽。最为重要的是，伴随着Kubernetes社区的日益壮大，如何避免这个生态陷入Solomon所警告的“有毒”陷阱，恐怕很快就会成为摆在这个社区所有参与者面前的一道难题。是的，是所有参与者都对此负有责任，而绝不仅仅是CNCF或者Google就有能力独自解决的一次危机。
作者
张磊，浙江大学博士研究员，Hyper项目成员，Kubernetes项目资深成员与社区维护者。长期专注并活跃于容器集群管理与云计算数据中心领域，连续多次被微软授予该领域“最有价值专家（MVP）”称号。
来源：infoq
http://www.infoq.com/cn/articles/2017-container-Kubernetes
Kubernetes中文社区
