我目前正在学习Kubernetes中的容器运行时接口（CRI），在学习过程中遇到了一个问题。
从1.20版本开始，Kubernetes停止了对Dockershim的支持，这意味着Docker不能再用作CRI。
然而，我发现Docker内部依赖于containerd，当使用kubeadm设置集群并安装Docker Daemon时，Kubernetes集群初始化工作顺利，没有任何问题。
那么，这是否意味着即使不支持Dockershim，Kubernetes也可以正常运行？
我想到的场景如下：最初，Kubernetes是通过一个名为Dockershim的接口构建的，它依赖于Docker和托管容器。
然而，Docker在内部使用了名为containerd的CRI，由于Kubernetes不再需要Dockershim，因此停止了对它的支持。
我的理解是否正确？
2条答案
按热度按时间sauutmhj1#
Dockershim也是一个CRI，事实上，它是Kubernetes支持的第一个CRI。随着时间的推移，他们采用了越来越多的CRI，其中最重要的一个是2018年的容器：read more here--至今仍支持containerd沿着其他CRI as you can see here
尽管dockershim不再受支持，但仍有插件/适配器为Docker Engine提供支持。还有一些计划在containerd上运行DinD（docker in docker）镜像，以支持在k8s集群内构建docker镜像（CI上下文）。
回答你的问题：
那么，这是否意味着即使不支持Dockershim，Kubernetes也可以正常运行？
Dockershim只是Docker本身的一小部分，它只代表了运行时--这实际上是一种“适应”，使Docker首先与K8一起工作。其他的一切都非常支持。引用他们在宣布放弃dockershim时的观点：
你看，我们称之为“Docker”的东西实际上并不是一个东西-它是一个完整的技术堆栈，其中一部分是一个名为“containerd”的东西，它本身就是一个高级容器运行时。Docker很酷也很有用，因为它有很多UX增强功能，使人类在进行开发工作时可以很容易地进行交互，但这些UX增强功能对于Kubernetes来说并不必要，因为它不是人类。
你可以从引用自here的帖子中阅读更多关于它的信息
我真的希望这对你的学习有帮助！
gzjq41n42#
从1.20版本开始，Kubernetes停止了对Dockershim的支持。
应该是1.24
即使不支持Dockershim，Kubernetes也能正常运行吗？
是的，相反的情况同样适用于docker adapter for K8s。
...Docker内部使用了名为containerd的CRI，
不是。CRI是K8s的API标准，用于与实现接口的任何容器引擎（例如containerd）集成。Docker引擎不兼容CRI。Docker与containerd的集成是原生的。
Kubernetes不再需要Dockershim，它停止了对它的支持。
这一点在这里得到了很好的解释。值得一提的是，docker支持许多其他功能（例如。构建、集群等），这些都是容器编排器（如K8s）不需要的。