本文主要是介绍Kubernetes弃用Dockershim，转向Containerd：影响及如何应对，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Kubernetes1.24版本发布时，正式宣布弃用Dockershim，转向Containerd作为默认的容器运行环境。Kubernetes以CRI(Container Runtime Interface)容器运行时接口制定接入准则，用户可以使用Containerd、CRI-O、CRI- Dockerd及其他容器运行时作为Kubernetes的容器引擎。
Kubernetes为何弃用Dockershim？
Docker在早期没有实现Container Runtime Interface (CRI)，而CRI是Kubernetes后来增加的对额外运行时的支持标准。Dockershim的存在是为了支持将Docker硬编码到Kubernetes中，但随着容器化成为行业标准，Kubernetes项目增加了对额外运行时的支持，比如通过Container Runtime Interface (CRI)容器运行时接口来支持运行容器。因此，在Kubernetes1.20版本发布的时候提到未来会弃用Dockershim引擎，而在Kubernetes1.24版本发布时， 正式弃用之。
什么是 Containerd ？
containerd是一种容器运行时引擎，原属于Docker的组件的一部分，主要提供容器生命周期管理（从创建到销毁容器）、拉取和推送镜像、存储管理（管理镜像及容器数据的存储）、调用runc容器运行等，现已由开源社区拆分脱离出来单独作为容器运行时项目。
在Kubernetes中，Containerd作为容器运行环境，负责管理Pod的生命周期，包括容器的创建、启动、停止和删除等操作。与Dockershim相比，Containerd具有更好的性能、更强的可扩展性以及更简洁的架构。
容器运行底层组件有哪些关系？
Docker Client和Docker Daemon：Docker Client是Docker的客户端，它可以通过命令行或API向Docker Daemon发送请求。Docker Daemon是Docker的核心组件，负责管理镜像、容器、网络和卷等资源，并将Docker API暴露给客户端。
Docker镜像和Docker容器：Docker镜像是只读的模板，包含了所有用于运行应用程序所需要的代码、库文件、环境变量和配置文件等内容。Docker容器是基于Docker镜像创建的可运行实例。每个容器都是一个独立的、轻量级的操作系统，它们之间相互隔离并且可以共享主机的内核。
CRI（Container Runtime Interface）和容器运行时：CRI是Kubernetes的容器运行时标准接口，满足这个标准的所有容器运行时都可以被使用。容器运行时则提供了一个轻量级的容器运行环境，用于创建、启动和停止容器。
OCI（Open Container Initiative）和runc：OCI是一个开放的容器组织，它制定了容器运行时的规范，包括运行时规范、容器镜像规范等。runc是OCI标准的一个参考实现，它与容器所依赖的cgroup/linux kernel等进行交互，是容器最终运行的形态之一。
Containerd在Kubernetes的运行变化
在Kubernetes 1.24版本以前，Kubernetes通过调用Docker命令来创建容器。具体来说，Kubernetes将任务发送给Docker客户端，然后Docker客户端通过与Docker守护进程（daemon）通信来创建容器。Docker守护进程会通过Image模块下载镜像并保存，然后通过client调用containerd创建并运行容器。在这个过程中，如果需要给容器添加持久化存储，可以使用volume参数；如果需要配置容器网络，可以通过network参数来实现。
然而，Kubernetes提供了更强大的卷挂载能力和集群级别的网络能力。在集群中，kubelet只会使用到Docker提供的镜像下载和容器管理功能，而编排、网络、存储等功能都不会用到。
在Kubernetes 1.24版本以后，Containerd作为容器运行时被引入，带来了创建Pod所需的所有功能。与之前的方案相比，这不仅带来了更纯粹的功能模块，而且缩短了调用链，提高了系统的效率和稳定性。因此，用户可以使用Containerd、CRI-O、CRI-Dockerd及其他容器运行时作为Kubernetes的容器引擎。
Containerd在Kubernetes中的工作流
-
Kubelet通过CRI运行时服务API调用CRI插件来创建Pod。
-
CRI创建一个特殊的沙箱容器（pause容器），并将其放置在Pod的Cgroups和NameSpace命名空间中。
-
CRI使用CNI配置Pod的网络命名空间。
-
Kubelet随后通过CRI镜像服务API调用CRI插件来拉取应用容器镜像。如果镜像不存在于节点上，CRI会进一步使用Containerd来拉取镜像。
-
Kubelet通过CRI运行时服务API调用CRI，并使用拉取的容器镜像在Pod内创建和启动应用程序容器。
-
CRI创建应用程序容器，将其放入Pod的Cgroups和NameSpace中，然后启动Pod的新应用容器。
在这些步骤之后，一个Pod及其相应的应用程序容器被创建并运行。
Kubernetes弃用Dockershim的影响
容器镜像，由于Docker镜像符合OCI规范，因此可以直接使用而不受影响。此外，原镜像打包方式仍然可用，即使用docker build方式打包镜像。这意味着用户在构建和打包镜像时不需要做出任何改变
Kubernetes中的运行过程，作为终端用户（Kubernetes使用者）基本也不会有任何影响，因为Kubernetes的使用逻辑没有任何变化。然而，与Dockershim相关的API接口已经弃用，如果创建了此类CRD，需要注意修改相关代码。
运维方式，节点后端运维时使用的命令由docker命令改为containerd。如果旧环境使用的是Dockershim引擎，需要先改为containerd运行时再进行升级。运维人员则需要适应新的命令行工具和运行时环境。
Kubernetes弃用Dockershim而采用containerd作为容器运行时对用户和运维方式会有一些影响，但对于已经符合OCI规范的镜像和使用docker build方式打包镜像的用户来说，基本无感知。
Kubernetes用户如何应对？
用户需要按照Kubernetes官方提供的迁移指南进行操作。这包括更新Kubernetes版本、修改Pod配置文件、调整部署流程、更换镜像管理工具以及重新配置监控和日志采集工具等步骤。在迁移过程中，用户还需要注意测试新环境的稳定性和性能，确保迁移成功。
在迁移过程中，用户可能会遇到各种问题，如配置错误、兼容性问题、性能下降等。为了解决这些问题，用户可以参考Kubernetes官方文档和社区资源，或者向灵雀云的服务团队寻求帮助和支持。此外，用户还可以在测试环境中模拟迁移过程，提前发现和解决问题。
迁移到Containerd后，用户可以对系统进行一系列优化和改进，以提高性能和稳定性。例如，优化Pod的配置和部署流程、使用更高效的网络配置方式、改进监控和日志采集策略等。此外，用户还可以关注Kubernetes和Containerd的最新版本和功能更新，及时跟进技术发展趋势。
结论与展望
Kubernetes弃用Dockershim并转向Containerd已经成为一个明显的趋势信号。对于现有的Kubernetes用户来说，应尽快了解这一变化的影响和应对策略，找到适合自己的方案并尽早进行改进。未来，Kubernetes与Containerd的发展趋势将更加紧密地结合在一起，共同推动容器技术的不断创新和发展。
这篇关于Kubernetes弃用Dockershim，转向Containerd：影响及如何应对的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
