Kubernetes1.24弃用Docker的原因及其后果

2022年4月7日Kubernetes1.24版本正式删除和弃用dockershim,一年过去了,到底有多少人真的明白,这个是啥意思?我们聊一聊吧。

本文主要将介绍两个概念,OCI and CRI,搞懂这两个,基本上就搞明白了。

OCI(Open Container Initiative)

Initiative直译成中文是倡议,它是Linux基金倡导产生的一个轻量级开放治理项目。OCI于2015年6月22日由Docker、CoreOS以及其他几个大佬共同发起,其明确目是对于容器格式及运行时建立统一的行业标准。当年还是群雄逐鹿的年代,西方人的做事的风格就是这样,坐下来建立标准,最后由市场决定,谁是老大。

OCI主要定义两个规范:

  • 镜像规范(image-spec):OCI镜像规范的前身为Docker镜像规范v2,它定义了镜像的主要格式及内容。OCI镜像定义包括4个部分:镜像索引(Image Index)、清单(Manifest)、配置(Configuration)和层文件(Layers)。

  • 运行时规范(runtime-spec):运行时规范最本源的功能就是怎么样把磁盘上的镜像文件跑起来。其中Low-Level这部分其实已经被runC制霸了,runC就是目前使用最广泛的Low-Level容器运行时。runC最初是Docker将自己libcontainer实现合并到runC,最终捐赠给了OCI。(Low-Level是指轻量的容器运行时,主要实现了容器的启停、资源隔离等核心功能)

因此大家可以发现,Docker公司在早期OCI规范的形成中扮演了很重要的角色。

接下去看下目前市面上最主流的3个High-Level容器运行时(High-Level包括镜像传输、镜像管理、镜像解包和 API等高级功能):

  • Containerd(Cloud Native Computing Foundation):CNCF孵化器的开源项目。没错,你们猜对了,也是Docker捐献的。Docker把全家都安排到了关键岗位,占据有利位置。

  • Podman(Redhat):Podman 工具在RHEL8中作为完全支持的功能发布。

  • CRI-O(Cloud Native Computing Foundation):CNCF孵化器的开源项目。

最终我们再来看下Docker,按照上边那种分层,我们其实可以把Docker定义为"High-High-Level"容器运行时,它基于Containerd作为容器运行时,Containerd基于runC作为容器运行时。最终提供了一个完整的生产平台,涵盖容器的开发、分发、安全、编排的一体化解决方案。

最后补充一下我个人对于docker-compose这个项目的看法,我真心觉得,docker-compose是一个远远被低估的产品。灵活性、易用性以及可维护性,docker-compose都做的很棒,欢迎有同样看法的人在评论区留言。有时间专门写一篇docker-compose。

CRI(Kubernetes Container Runtime Interface)

CRI是kubernetes的容器运行时接口,主要包含两个服务,分别对应OCI的两个标准:

  • ImageService:主要实现拉取镜像、查看和删除镜像等操作。

  • RuntimeService:实现Pod和容器的生命周期管理,以及与容器交互的调用(exec/attach/port-forward)等操作。

但是在1.24之前,kubernetes给Docker开了一个贵宾通道,kubelet通过CRI接口调用dockershim,而不是直接调用Containerd。dockershim收到请求后, 再转化成Docker Daemon能识别的请求, 等于是绕了一圈。

2022年4月7日Kubernetes1.24版本正式删除和弃用dockershim。这件事情的本质是废弃了内置的 dockershim 功能,直接对接Containerd,不绕这一圈了。

Kubernetes卧薪尝胆,在基本可以确保一统江湖的情况下,适当的将贵宾席进行收回,使得整个调用的链路更加的简洁,属于合理的操作。你的Swarm没做起来,那就是没做起来,我没阴你吧。

同时Kubernetes并没有下死手,dockershim的支持被独立出一个项目cri-dockerd,归类为third-party replacement了。大家伙要切还是可以切换的: