写点什么

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

用户头像
杨明越
关注
发布于: 2020 年 12 月 10 日
关于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”只是一朵浪花。



用户头像

杨明越

关注

明公正道,越凡遗世 2020.12.06 加入

资深技术专家,历经沧海仍为水,除却巫山还是云……

评论

发布
暂无评论
关于Kubernetes和Docker关系的八个问题