网站建设视频教程。,怎么备案域名,代理注册公司违法吗,美术生最吃香的专业Kubernetes1.24 版本发布时#xff0c;正式宣布弃用 Dockershim#xff0c;转向 Containerd 作为默认的容器运行环境。Kubernetes 以 CRI(Container Runtime Interface) 容器运行时接口制定接入准则#xff0c;用户可以使用 Containerd、CRI-O、CRI- Dockerd 及其他容器运行…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 DaemonDocker Client 是 Docker 的客户端它可以通过命令行或 API 向 Docker Daemon 发送请求。Docker Daemon 是 Docker 的核心组件负责管理镜像、容器、网络和卷等资源并将 Docker API 暴露给客户端。
Docker 镜像和 Docker 容器Docker 镜像是只读的模板包含了所有用于运行应用程序所需要的代码、库文件、环境变量和配置文件等内容。Docker 容器是基于 Docker 镜像创建的可运行实例。每个容器都是一个独立的、轻量级的操作系统它们之间相互隔离并且可以共享主机的内核。
CRIContainer Runtime Interface和容器运行时CRI 是 Kubernetes 的容器运行时标准接口满足这个标准的所有容器运行时都可以被使用。容器运行时则提供了一个轻量级的容器运行环境用于创建、启动和停止容器。
OCIOpen Container Initiative和 runcOCI 是一个开放的容器组织它制定了容器运行时的规范包括运行时规范、容器镜像规范等。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 的发展趋势将更加紧密地结合在一起共同推动容器技术的不断创新和发展。
参考文档 https://kubernetes.io/zh-cn/blog/2022/02/17/dockershim-faq/ https://kubernetes.io/zh-cn/blog/2020/12/02/dont-panic-kubernetes-and-docker/
