Kubernetes与Docker同床异梦

Kubernetes与Docker同床异梦

🗨

今天来讲讲目前Kubernetes生态圈的现状。

自2014年发布以来,Kubernetes发展迅速,从最开始以源自Google最佳实践的容器管理平台亮相, 再与Docker Swarm和Mesos一起争夺容器编排领域的主导位置,到最近开始整合整个容器生态的上下游。 Kubernetes始终保持着小步快跑的节奏,在每个Release当中不断推出新的Feature。 同时Kubernetes背后的组织CNCF还在不断吸收Kubernetes生态圈中的优秀开源项目,解决最终用户在生产部署中所存在的监控、 日志搜集等需求。

如今,Kubernetes已经超越了单纯的容器编排工具,企业选择Kubernetes本质上是拥抱以Kubernetes为核心的云原生最佳实践。 其中包含了网络、存储、计算等运行资源的调度,还涵盖了监控、日志搜集、应用分发、系统架构等研发和运维的操作流程。

容器引擎接口(Container Runtime Interface)

众所周知,Kubernetes和Docker是既合作又竞争的关系。Kubernetes使用Docker Engine作为底层容器引擎,在容器编排领域与Docker Swarm展开竞争。为了减少对Docker的依赖,同时满足生态中其他容器引擎与Kubernetes集成的需要,Kubernetes制定了容器引擎接口CRI。 随后Kubernetes发布了cri-o项目,开始研发自己的Docker兼容容器引擎。目前已经有Docker,rkt,cri-o三款容器引擎支持CRI接口。 此外支持CRI的还有Hyper.sh主导的frakti项目以及Mirantis主导的virtlet项目, 它们为Kubernetes增加了直接管理虚拟机的能力。

CRI的发布将Docker推到了一个非常难受的位置,如果不支持CRI,面临着在Kubernetes体系当中被其他容器引擎所替换的风险。 如果支持CRI,则意味着容器引擎的接口定义被竞争对手所主导,其他容器引擎也可以通过支持CRI来挑战Docker在容器引擎领域的事实标准地位。 最终,为了不被边缘化,Docker只能妥协,选择将containerd项目捐献给CNCF。在同一天,CoreOS也宣布将rkt项目捐献给CNCF。 至此CRI成为了容器引擎接口的统一标准,今后如果有新的容器引擎推出,将首先支持CRI。

容器网络接口(Container Network Interface)

因为Kubernetes没有内置容器网络组件,所以每一个Kubernetes用户都需要进行容器网络的选型,给新用户带来了不小的挑战。 从现状来看,不内置网络组件的策略虽然增加了部署的复杂度,但给众多SDN厂商留下了足够的公平竞争空间,从中长期来讲是有利于容器网络领域的良性发展的。

1.0版本的Kubernetes没有设计专门的网络接口,依赖Docker来实现每个Pod拥有独立IP、Pod之间可以不经过NAT互访的网络需要。 随着与Docker的竞争加剧以及Docker主导的CNM接口的推出,Kubernetes也推出了自己的容器网络接口CNI。

随着CNI的推出,各家SDN解决方案厂商纷纷表示支持。目前Flannel,Calico,Weave,Contiv这几款热门项目均已支持CNI, 用户可以根据需要为自己的Kubernetes集群选择适合的网络方案。面对CNI和CNM,主流厂商目前的选择是同时支持,但从中长期来看, 厂商一定会根据各个生态的发展进度来动态配置资源,这时Docker内置的原生网络组件有可能反而会影响和其他网络厂商的协作。

容器存储接口(Container Storage Interface)

在统一了容器引擎和容器网络之后,Kubernetes又将触角伸到了存储领域。目前还在制定过程当中的容器存储接口CSI有望复制CRI和CNI的成功, 为Kubernetes集群提供可替换的存储解决方案。不论是硬件存储厂商或是软件定义存储解决方案厂商,预计都将积极拥抱CSI。 因为不支持CSI就意味着放弃整个Kubernetes生态圈。

软件打包与分发(Packaging and Distribution)

在使用CRI,CNI,CSI解决底层运行环境的抽象以外,Kubernetes还在试图通过Helm项目以及Helm Charts来统一软件打包与分发的环节。 由于Kubernetes提供了底层的抽象,应用开发者可以利用Kubernetes内置的基础元素将上层应用打包为Chart,用户这时就能使用Helm完成一键安装以及一键升级的操作。

在系统架构越来越复杂的今天,能够方便的将复杂的分布式系统运行起来,无疑为Kubernetes的推广增加了不少亮点。 目前一些常见的开源系统,比如Redis,ElasticSearch等已经可以通过使用官方的Charts进行部署。相信未来会有更多的开源项目加入这个清单。

看到这一块商机的公司,比如CoreOS,已经推出了自己的软件仓库服务。由于这块离最终用户最近,相信未来在这一领域的竞争将会非常激烈。

云原生计算基金会(Cloud Native Computing Foundation)

前面列举的案例主要偏重技术解决方案,Kubernetes最有潜力的其实是在幕后团结容器生态中各方力量的CNCF组织。 与同期建立的Docker主导的OCI组织相比,当前CNCF不论是在项目数量,会员数量,会员质量等多个方面都明显领先。 可以说CNCF是事实上在推动整个容器生态向前发展的核心力量。

人的力量是最根本的也是最强大的,只有团结到尽可能多的玩家,才能制定出各方都能接受的标准。面对这么多的会员企业,要平衡各方的诉求实在不是容易的事情。 目前CNCF做的还不错,中立的基金会形式似乎更加容易被各方所接受。最近正在进行决策小组选举的讨论,有兴趣的朋友可以自行围观。

总结

有两句经常听到的话在Kubernetes身上得到了很好的体现,一是没有什么是不能通过增加一个抽象层解决的,二是一流的企业做标准,二流的企业做品牌,三流的企业做产品。 Kubernetes通过在具体实现上增加抽象层,试图为整个容器生态圈建立统一的标准。当标准逐步建立,用户开始依照标准选择解决方案, 将进一步强化Kubernetes位于整个容器生态核心的地位。这时容器生态的上下游将不得不面对,要么选择In拥抱Kubernetes所提出的标准, 要么选择Out被整个生态圈孤立的情况。面对这种选择,想必大部分厂商都将选择In,而更多的厂商加入将进一步强化标准的力量。

可以预见Kubernetes构建的组织、标准、开源项目三层体系,将有望统一容器生态圈的各方力量,而这种统一对最终用户是有益的。 在容器生态中的各个领域,开源的解决方案将与商业解决方案直接竞争,甚至开源解决方案之间也将展开竞争。这种竞争将促进整个容器生态的发展, 由于大家都遵守相同的标准,不论你在最初建设时选择的是哪一套解决方案,将来也可以用更新更好的方案来替换, 规避了商家绑定的风险。希望捐献给CNCF的项目将会越来越多,因为进入CNCF就意味着比其他相同功能的开源项目更加容易获得Kubernetes生态圈的认可。


频道:OS