Kubelet不再支持Docker运行时

时间：2022-04-10 03:27:01 | 来源：行业动态

时间：2022-04-10 03:27:01 来源：行业动态

人们对Docker未来的担心源于Kubernetes 在1.20版本中的 ChangeLog 提到，kubelet 中的 Docker 支持功能现已弃用，并将在之后的版本中被删除。社区解释说，这么做的原因是，Kubelet 之前使用的是一个名为 dockershim 的模块，用以实现对 Docker 的 CRI 支持，但 Kubernetes 社区发现其维护存在问题，因此建议大家考虑使用包含 CRI 完整实现的可用容器运行时。

首先要说明的是，这里提到的Docker运行时并不等同于我们经常说的Docker，这可能是让人们以为Docker被Kubernetes抛弃的一个原因。运行时（Runtime）为应用程序运行时提供保障的一个环境，通常是一些可以重用的程序/库或者实例，这些实例可以在它们运行的时候被连接或者被任何程序调用。在Kubernetes集群内部也有一种称为容器运行时的组件，负责提取并运行容器镜像。Docker就是目前最流行的容器运行时，除此之外容器运行时还有Containerd与CRI-O。

与Containerd与CRI-O的定位就是一个运行时不同，Docker集成了太多功能，而很多功能作为一个运行时并非必须，比如容器创建，而且Docker最初在设计上也并未考虑到被嵌入到Kubernetes这种用法。

应该说，当初为了支持使用Docker的这个运行时，kubelet做出了妥协。如果采用Containerd与CRI-O运行时，其调用流程是：kubelet向CRI-Container插件发出调用请求，由CRI-Container再和容器运行时通信，完成请求的各种操作，但采用Docker运行时，这个流程就需要做出改变。由于Docker运行时并不兼容CRI，不得不引入一个新的插件Dockershimi作为缓冲。此时流程变成：kubelet先向Dockershimi发出请求，由Dockershimi调用Docker运行时，Docker运行时再调用其中的Containerd，由Containerd来负责完成请求的各种操作。可以看出，这个过程中Docker运行时有点尬尴，它的加入不仅在流程上多了一个环节，引入了Dockershimi，而Dockershimi的介入又引发了新的问题，必须额外加以维护，否则就可能引发安全问题。

如今，随着Kubernetes社区的逐渐强大，当初Kubernetes向Docker做出的妥协现在不打算继续了，这才有了kubelet不再支持Docker运行时的举措。目前来看这件事的影响不大，正如CNCF所言，Docker不会就此消亡，Docker会继续构建起不计其数的容器，开发人员仍然可以继续采用Docker，继续将Docker作为开发工具，Docker所生成的镜像仍可在Kubernetes集群内正常运行。

如果使用的是云上的容器服务，比如GKE或者EKS等托管Kubernetes服务，则需要确保在未来的Kubernetes版本彻底去除Docker支持之前，为工作节点引入受支持的容器运行时。如果是自己负责管理的集群，则要注意更新和调整运行时以避免服务中断。在1.20版本中，将收到Docker弃用警告。而在未来的Kubernets版本（计划在2021年下半年发布的1.23版本）中，Docker运行时将被彻底移除、不再受到支持。

然而，长期来看呢？