在Kubernetes中使用dockershim和containerd的历史是什么?

wf82jlnq  于 2023-06-28  发布在  Kubernetes
关注(0)|答案(2)|浏览(95)

我目前正在学习Kubernetes中的容器运行时接口(CRI),在学习过程中遇到了一个问题。
从1.20版本开始,Kubernetes停止了对Dockershim的支持,这意味着Docker不能再用作CRI。
然而,我发现Docker内部依赖于containerd,当使用kubeadm设置集群并安装Docker Daemon时,Kubernetes集群初始化工作顺利,没有任何问题。
那么,这是否意味着即使不支持Dockershim,Kubernetes也可以正常运行?
我想到的场景如下:最初,Kubernetes是通过一个名为Dockershim的接口构建的,它依赖于Docker和托管容器。
然而,Docker在内部使用了名为containerd的CRI,由于Kubernetes不再需要Dockershim,因此停止了对它的支持。
我的理解是否正确?

sauutmhj

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的帖子中阅读更多关于它的信息
我真的希望这对你的学习有帮助!

gzjq41n4

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)不需要的。

相关问题