关于 Kubernetes 和 Docker 关系的八个问题

【摘要】关于“Kubernetes弃用Docker”的讨论，已经从技术领域转移到了非技术领域。本访谈，仅代表技术专家杨明越的个人观点。

1 Kubernetes和Docker之间是否存在竞争关系？如果有互补关系，主要体现是在哪儿呢？

简单来说，Kubernetes和Docker有互补，有竞争。

首先

在一般的认知中，Kubernetes和Docker是互补关系：

• Dockers属于下层——容器引擎；

• Kubernetes属于上层——编排调度层。

Docker源于Linux Container，可以将一台机器的资源分成N份容器，做到资源的隔离，并将可运行的程序定义为标准的docker image；Kubernetes则可以把不同机器的每份容器进行编排、调度，组成分布式系统。

其次

Kubernetes和Docker并不完全是“泾渭分明”的互补关系，它之间有重叠部分，也可以说成是竞争，主要在于几个点：

第一、 系统三大移植资源是计算、存储、网络，从Kubernetes角度Docker属于“Runtime（运行时）”，也就是计算资源；但是Docker技术体系里面，本身也包括存储层、网络层。上下层职责的重叠，也可以看作竞争。

第二、 Docker原本有个原生的调度引擎——Swarm，几年前在调度编排领域，还是Kubernetes、Mesos、Swarm三者并存，Kubernetes最终胜出，但Docker仍有“继续向上做一层的意愿”。





第三、 Kubernetes在如何使用Docker方面，存在争议和变数。kubernetes1.20 ChangeLog中所谓要废弃Docker的传言，也是无风不起浪。换句话说，即便Kubernetes一直用Docker，也不是用Docker的全部，多少是不一样的。



第四、 在Kubernetes的实现中，已经有了一个新的东西podman，它是兼容docker，又是彻底的docker替代品。

从logo来看，似乎是降低——从鲸鱼到海狮。







2 Kubernetes和Docker各自适应哪些场景？现在企业主要应用的是谁？

近几年，Kubernetes已经成为自有机房、云上广泛使用的容器编排方案，最广泛的使用方式是Kubernetes+Docker。从DevOps人员的角度，一面用kubctl命令、k8s API来操作集群，一面在单机用docker命令来管理镜像、运行镜像。

单独用docker的情况，在一些公司的场景里面也是有的。一种场景是“只分不合”，把一台机器用docker做资源隔离，但是不需要将多容器“编排”。

单独用Kubernetes，下层不是Docker的情况，并不算很多。虽然Kubernetes可以更换Runtime，虽然Kubernetes+Podman未来可能是趋势，但现阶段它们仍是冷门。

3 这次Kubernetes弃用Docker运行时的行为会影响到哪些开发者和企业？

一些“民间架构专家”对于此事其实是一知半解，甚至于以讹传讹。

首先，“弃用Docker”这个词本身有多重的含义，Docker并非一个单层软件，Kubernetes 1.20启用dockershim并不代表弃用了Docker的全部，仍有containerd可以对接docker。



其次，即便是Kubernetes+podman替代docker，那至少docker image 还是可以用的。



第三，由于老技术实现的惯性，在生产环境大量使用的经典Kubernetes+ docker方案依然运行，且运维已经成熟，不会很快升级。



第四，对于开发人员、企业，对于K8S API的使用频率、变数，远远大于Docker API，至于Kubernetes和docker的桥接，更不用关心。因此，即便“彻底弃用Docker”，对开发者与企业的影响也非常有限。

4 开发人员需要将集群从Docker迁移到例如containerd、cri-o，这种迁移的复杂度如何？

此问题的简单答案是：迁移的复杂度并不大，普通的开发人员甚至不用关心。

Docker与k8S的关系，可以理解成kubelet守护进程如何调用docker，作为运行时的实现，dockers并非硬件相关（存储、网络）的环节，因此迁移的难度并不是很大问题。从dockershim到cri-containerd，核心流程其实都是软件层面的变化，而非硬件层面的移植。



Kubernetes对接最终容器运行时的过程，一头一尾分别是kubelet和RucC，中间的dockershim、cri-containerd、cri-o属于封装实现的流派，它们只是表示不同的“套娃”方法。

5 2019年的容器报告数据显示，Docker占据79%，containerd占据18%，cri-o占据4%，弃多用少，这样做的主要目的是什么？

首先，明确一个概念，此问题里面提到的docker，准确说应为dockershim，containerd应为cri-containerd。



Kubernetes的kubelet对接Runtime的来龙去脉非常复杂，从目前（2020年12月）的时间点，主要就是三种：

• dockershim：通过调用docker的方式，也就是所谓要被“放弃“；

• cri-containerd：对接docker的另外一种方式，也是docker主动对接k8s的方式；

• cri-o：RedHat主导，并且也是目前Kubernetes推崇的方式。



Kubelet对接dockershim、cri-containerd、cri-o三者的关系，可以用下面的图来表示。



回到问题本身，“弃少从多“原本就是一个正常的逻辑，因为所谓的多（dockershim）正式因为它比较老、使用时间早，占有率自然高。但这种老方式在架构合理性、稳定性上面，存在短板，因此它要被”弃用“。

6 之前谷歌很明白的表示弃用Docker，现在Kubernetes弃用Docker运行时，目的会不会都是因为背后企业存在竞争关系？

对于这个话题本身，竞争肯定是有的，既有企业之间的竞争，也有技术流派的竞争。

从技术流派的角度，Kubernetes和docker的竞争，前面已经说过，二者的功能有重叠，上下层边界不算很确定。

从技术的角度，Kubernetes可以说是非常开放的产物，但是docker已经不是。 原本开源的docker已经变成了商业化的版本，甚至出现了docker-ce、docker-ee这种名字，开源社区的docker目前正式的名字叫moby。

从鲸鱼到鲸鱼尾巴，是不是也可以看出docker对开源版本的态度？



正如人际关系，从风雨同舟到分道扬镳，甚至到反目成仇，这其中的转折点，并非一两次冲突，而是价值取向的背离。当已无共同初心之时，关系变坏的趋势也难以逆转了。

Kubernetes与docker已经有了渐行渐远的趋势，初心本身都是来自开源社区，在很多场景仍是结合使用。分道扬镳的里程碑，并不是2020下半年的一个Kubernetes新版本，而是docker早已走上商业化的道路。

人际关系方面，朋友尚能“相逢一笑泯恩仇“，但Kubernetes与docker在快速技术发展的当下，则更难重回当年之亲密状态了——因为它们的关系本像夫妻，而非伙伴。CRI-O、podman俨然Kubernetes的新伴侣。

7之前Docker限定镜像拉取次数，而且Docker盈利状况一直堪忧，如何看待Docker的处境和未来？Docker会逐渐消亡吗？

Docker盈利状况的不利，一个很重要的原因，因为它原本是开源的项目，是开源生态的一部分。在转型商业化版本之后，盈利的目标对于docker来说，属于“强扭的瓜“。



Kubernetes对docker的态度，合情合理，这也注定了今后docker在技术应用领域，更有走向弱势的趋势。

总体来说，docker的弱势来自于公司的盈利、技术应用面两方面，但如果谈docker的消亡，目前看还为时过早。因为docker本身也是一系列技术模块的组合体系，而非一个东西。

8 这种趋势对云原生技术的影响是什么？

近几年，Cloud Native发展很快，也是“越来越好”。由于docker 已经商业化，因此从云原生技术的角度，找到docker的替代品，对技术显然是好事。



在Cloud Native广袤的全局图当中，运行时只占很小的一部分，又是比较标准化的部分，占整体技术发展的比重并不大。

可以说Cloud Native的征途是星辰大海，“弃用docker”只是一朵浪花。