“ Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. (#94624, @dims) ”

随着Kubernetes 1.20的公布，对于“kubernetes不再反对Docker！Docker不能用了！以前的Docker镜像不能用了！”等声音不绝于耳，事实真的是这样吗？


本文作者：蔡超

Mobvista 团体副总裁兼首席架构师

深刻细节

要理解事件的假相，就要深刻其细节。那就让咱们来看看于此相干的细节吧。

1. 对于容器

容器 = cgroup + namespace + rootfs + 容器运行时

cgroup：资源管制

cgroup 是 control group 的简称，是 Linux 内核提供的一个个性，用于限度和隔离一组过程对系统资源的应用，如：CPU，内存的应用等。

namespace：拜访隔离

Namespace 是将内核的全局资源做封装，使得每个namespace 都有一份独立的资源，因而不同的过程在各自的namespace内对同一种资源的应用互不烦扰，例如，hostname，过程ID和用户组等在各个namespace里都是独立的。

rootfs：文件系统隔离。镜像的实质就是一个rootfs文件

容器运行时：生命周期管制

2. 对于Docker

其实与很多人的意识不同，Docker自身并不是容器，它是创立容器的工具，是容器运行时。想要搞懂Docker，其实看它的两句口号就行。

"Build, Ship and Run"

"Build once，Run anywhere"

3. 对于Kubernetes

Kubernetes是一个容器编排平台，用于容器利用的自动化公布，伸缩和治理。

那么Kubernetes是如何实现容器治理的呢？

如咱们所知container/pod是运行在node上的，kubernetes在每一个node上都有一个kubelet用于治理node的container/pod。所以，最直观的想法就是kubelet间接调用一个容器运行时（container runtime），如Docker去创立和治理node上的container。

然而这样的简略连贯会带来一个问题，如果Kubernetes要去反对更多不同的容器运行时实现, 就要为不同容器运行时开发不同的kubelet去适配。为了解决这个扩展性问题，Kubernetes 1.5里引入了CRI（Container Runtime Interface）。CRI定义了kubelet反对的容器运行时的标准接口（一组gRPC调用），这样就变成了容器运行时要通过反对CRI来被动适配Kubernetes。

另一方面，Docker也在产生着扭转

为了防止容器的生态决裂为“小生态王国”，确保一个引擎上构建的容器能够运行在其余引擎之上，2015年由多家公司独特成立的我的项目OCI （Open Container Initiative），并由linux基金会进行治理，致力于容器运行时规范的制订。

Docker从原有的libcontainer中演化出了反对OCI的runC。容器运行时治理也从Docker Daemon中抽离进去，放到了一个叫containerd的过程中，containerd是一系列容器操作的facade，并最终通过runC来实现容器的操作。由此最终kubernetes和docker的关系变成了上面这样。内置在kubelet中Docker shim是为了让Docker Daemon适配CRI规范。

从上图大家发现Containrd曾经是一个容器运行时了，那么Docker Daeamon显得冗余，这样Kubernetes就能够进行1.20版本中提到的简化。

这样的构造将变得更加简化且正当，containerd的适配也通过在其中减少CRI-plugin来实现了，这样containerd就变成了一个反对CRI的容器运行时了。

传说中的Docker继任者

在一片Docker被放弃了的呼声中，大家听到最多还有CRI-O和Podman，他们仿佛是Docker的继任者。

首先，咱们来看看CRI-O，由下面的内容能够晓得其实，和kubernetes协同工作并反对现有的规范容器，就须要一个容器运行时可能桥接CRI和OCI，那么整个架构就能够大大简化，Redhat推出的CRI-O就是这样状况定制的容器运行时。

Podman是Redhat公司推出的容器管理工具（CRI-O并没有提供创立镜像，推送镜像至镜像库等性能），Podman起初是CRI-O的一部分，起初独自分离出来叫做libpod，应用Podman的命令简直和docker相似，事实上podman能够说兼容了docker的CLI，您甚至通过alias docker=podman来简略的替换Docker。

论断

Docker并没有被摈弃，将来kubernetes理论要去除的是对现有Docker运行时（Docker Daemon）的反对，通过去除了kubelet中Docker Shim来实现。这是kubernetes的一种标准化和简化，同时，应该留神到Docker理论在这些相干规范的制订中始终以来起着十分重要的作用。并且Docker给出的相干参考实现，如containerd，runC将持续被应用。

Docker运行时1.20中只是deprecated而不是removed，即Docker运行时能够失常应用。

即便在1.22版本kubelet移除docker shim后，docker 镜像还是能够应用的（docker镜像是合乎OCI的）

这个影响次要是运维和治理，对于开发的影响极小。即便要替换为podman，podman也是docker cli兼容的。