为什么做图书管理网站,装潢设计什么意思,wordpress掐件,传媒视频软件下载网站容器与 Docker 这个名称并不紧密相关。你可以使用其他工具来运行容器
您可以使用 Docker 或一堆非Docker 的其他工具来运行容器。docker只是众多选项之一#xff0c;Docker#xff08;公司#xff09;在生态系统中创建了一些很棒的工具#xff0c;但不是全部。
容器方面有…容器与 Docker 这个名称并不紧密相关。你可以使用其他工具来运行容器
您可以使用 Docker 或一堆非Docker 的其他工具来运行容器。docker只是众多选项之一Docker公司在生态系统中创建了一些很棒的工具但不是全部。
容器方面有两大标准
开放容器计划OCI一组容器标准描述镜像格式、运行时和分发。Kubernetes中的容器运行时接口CRI允许您在 Kubernetes 中使用不同容器运行时的 API。 Docker 堆栈的工作原理 Docker Engine 附带一系列工具让开发人员或系统管理员可以轻松构建和运行容器。它基本上 是一个用于处理容器的命令行界面 (CLI)。
因此实际上当您使用 运行容器时docker您实际上是通过 Docker 守护进程运行它它会调用 containerd然后使用 runc。
但docker命令只是拼图的一小部分。它实际上调用一些较低级别的工具来完成繁重的工作 Docker 堆栈中的低级工具有哪些
ddocker从下往上这些是用于运行容器的工具
最低级别 低级容器运行时。runc 是一个低级容器运行时。它使用 Linux 的原生功能来创建和运行容器。它遵循 OCI 标准并包含libcontainer这是一个用于创建容器的 Go 库。高级容器运行时。containerd 位于低级运行时之上并添加了许多功能例如传输图像、存储和网络。它还完全支持 OCI 规范。 Docker 守护进程。dockerd 是一个守护进程在后台运行的长时间运行的进程它提供标准 API并与容器运行时进行通信最高级别 Docker CLI 工具。最后docker-cli让您能够使用命令与 Docker 守护程序进行交互docker ...。这样您就可以控制容器而无需了解较低级别。 Kubernetes 使用 Docker 吗
一个非常常见的问题是“容器如何在 Kubernetes 中运行”。Kubernetes 使用 Docker 吗嗯现在它不再使用 Docker 了——但以前是使用 Docker 的。
最初Kubernetes 使用 DockerDocker Engine来运行容器。
但随着时间的推移Kubernetes 逐渐演变成一个与容器无关的平台。Kubernetes中创建了容器运行时接口 (CRI) API允许将不同的容器运行时插入其中。
Docker Engine 是一个比 Kubernetes 更老的项目它没有实现 CRI。因此为了帮助过渡Kubernetes 项目包含了一个名为dockershim的组件它允许 Kubernetes 使用 Docker 运行时运行容器。
它弥合了新旧世界之间的差距。
垫片shim的消亡
但从 Kubernetes 1.24 开始dockershim 组件被彻底移除Kubernetes 不再支持 Docker 作为容器运行时你需要选择实现了 CRI 的容器运行时。
Kubernetes 集群中 Docker Engine 的逻辑继任者是...... containerd。如果你答对了可以得 10 分或者你也可以使用其他运行时比如CRI-O。
这并不意味着 Kubernetes 无法运行所谓的 Docker 格式的容器。containerd和CRI -O 都可以在 Kubernetes 中运行 Docker 格式和 OCI 格式的镜像它们无需使用命令docker或 Docker 守护进程即可完成此操作。 开放容器计划 (OCI) 规范
OCI是首批为容器世界制定标准的组织之一。它由 Docker 和其他公司于 2015 年成立。
OCI 得到了众多科技公司的支持并维护着容器镜像格式以及容器运行方式的规范。
例如您可能对 Linux 主机使用一个符合 OCI 标准的运行时但对 Windows 主机使用不同的运行时。 Kubernetes 容器运行时接口
我们需要讨论的另一个标准是容器运行时接口CRI。这是由 Kubernetes 项目创建的 API。
CRI 是 Kubernetes 用于控制创建和管理容器的不同运行时的接口。 因此如果您更喜欢使用containerd在 Kubernetes 中运行容器那么您可以这样做或者如果您更喜欢使用CRI-O那么也可以。这是因为这两个运行时都实现了 CRI 规范。
但是如果您付费从供应商处获得支持安全性、错误修复等那么您选择的容器运行时可能会为您做出选择。例如Red Hat 的OpenShift 使用CRI-O并为其提供支持。Docker 为他们自己的containerd提供支持。
containerd 和 CRI-O
我们已经看到 Docker Engine 调用了一堆底层工具。但这些工具是什么它们如何组合在一起
第一层是高级运行时由 Docker 创建的containerd和由 Red Hat 创建的CRI-O 。
容器 containerd是源自 Docker 的高级容器运行时。它实现了 CRI 规范。它从注册表中提取镜像对其进行管理然后将其移交给较低级别的运行时后者使用 Linux 内核的功能来创建我们称为“容器”的进程。
克里欧 CRI-O是另一个实现 Kubernetes 容器运行时接口 (CRI) 的高级容器运行时。它是 containerd 的替代品。它从注册表中提取容器映像在磁盘上管理它们并启动较低级别的运行时来运行容器进程。
是的CRI-O 是另一个容器运行时。它诞生于 Red Hat、IBM、Intel 和 SUSE。 runc 和其他低级运行时 r unc是一个兼容 OCI 的容器运行时它实现了 OCI 规范并运行容器进程。
runc有时被称为 OCI 的“参考实现”。
其他低级运行时 但是runc 并不是唯一的低级运行时。OCI 规范允许其他工具以不同的方式实现相同的功能
crun 是一个用C编写的容器运行时相比之下runc 是用 Go 编写的。AWS 的firecracker-containerd它将 OCI 规范作为单独的轻量级虚拟机实现它也与支持 AWS Lambda 的技术相同Google 的gVisor可以创建具有自己内核的容器。它在其运行时中实现了 OCI称为runsc。
概括 有一套开放标准理论上可以更轻松地更换不同的实现。containerd 、runc和CRI -O等项目实现了这些标准的部分内容。
在 Kubernetes 中你可以选择要使用的容器运行时只要它支持 CRI API 即可。你可以使用containerd或CRI-O。
最后这个故事的寓意是
在 k8s 1.24 版本之后docker/dockershim 已被弃用即容器无法通过 docker 命令管理 但您可以使用支持 CRIK8s 原生 API的其他容器运行时 通过使用 crictl 命令或其他支持的命令来管理容器/pod而不是 docker 命令。
通过 crictl 映射 docker cli https://medium.com/vineetcic/mapping-from-dockercli-to-crictl-life-after-docker-is-cri-a39ea5649d6c
享受
