Docker-containerd-CRI-CRI-O-OCI-runc
1、云原生：cloud native
云原生是一种基于云的基础之上的软件架构思想，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。
云原生从字面意思上来看可以分成云和原生两个部分。
云是和本地相对的，传统的应用必须跑在本地服务器上，现在流行的应用都跑在云端，云包含了 IaaS,、PaaS 和 SaaS。
原生就是土生土长的意思，我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的，要充分利用云资源的优点，比如云服务的弹性和分布式优势。
2、CNCF：全称Cloud Native Computing Foundation（云原生计算基金会）
是一个开源软件基金会，它致力于云原生（Cloud Native）技术的普及和可持续发展
成立CNCF这个组织的初衷或者愿景，简单说：推动云原生计算可持续发展；帮助云原生技术开发人员快速地构建出色的产品
3、K8S：全称Kubernetes
是一个用于管理容器的开源平台，
它可以让用户更加方便地部署、扩展和管理容器化应用程序，
并通过自动化的方式实现负载均衡、服务发现和自动弹性伸缩等功能。
4、Docker：是一种容器管理工具
Docker 可以构建、拉取、推送容器镜像，创建、启动和管理容器。
Docker 组成： Docker 守护程序、containerd 和 runc
注：当Docker 运行一个容器时实际上是通过 Docker 守护程序、containerd 和 runc 来运行它。
5、CRI：全称Container Runtime Interface（容器运行时接口）
是 Kubernetes 用来控制创建和管理容器的不同运行时的 API，它使 Kubernetes 更容易使用不同的容器运行时。
它是一个插件接口，这意味着任何符合该标准实现的容器运行时都可以被 Kubernetes 所使用。
注意：Docker不符合CRI接口规范，Containerd符合,所以安装K8S的时候，需要安装docker-containerd
6、OCI：全称Open Container Initiative（开放容器倡议）
是一个由科技公司组成的团体，其目的是围绕容器镜像和运行时创建开放的行业标准。
他们维护容器镜像格式的规范，以及容器应该如何运行，从而达到"一个标准，多种实现"
Docker 镜像，实际上是以 Open Container Initiative（OCI）格式打包的镜像
7、Containerd、CRI-O：
它们都是符合CRI规范的高级别容器运行时，可以使用 OCI（开放容器倡议）兼容的运行时。
这些容器运行时都遵循了 OCI 规范，并通过 runc 来实现与操作系统内核交互来完成容器的创建和运行
虽然可以通过cri-dockerd继续使用 Docker，但更推荐的做法是迁移到原生支持 CRI 的容器运行时：
Containerd：轻量级、原生支持 CRI，是 Docker 的底层运行时，也是 Kubernetes 的官方推荐选择。
CRI-O：专为 Kubernetes 设计的轻量级运行时，专注于符合 CRI 标准。
8、runc
runc 是一个在 Linux 上运行容器的工具，windows中也有相对应的容器运行工具
runc：这是低级别的容器运行时（实际创建和运行容器的东西）,一个用于创建容器的基于 Go 的本地实现，
runc 是轻量级的通用运行时容器，它遵守 OCI 规范，是实现 OCI 接口的最低级别的组件，它与内核交互创建并运行容器，
runc 为容器提供了所有的低级功能，与现有的低级 Linux 功能交互，如命名空间和控制组，它使用这些功能来创建和运行容器进程。
Docker中，containerd：负责容器的生命周期管理（创建、启动、停止等），runc：负责容器的实际创建和执行，是 containerd 的底层依赖。
下图描述了Docker、Kubernetes、CRI、OCI、containerd 和 runc 在这个生态系统中是如何结合的。
其工作流程简单来说是这样的：
1. Docker，Kubernetes 等工具运行一个容器时会通过（CRI）调用容器运行时，如 containerd，CRI-O
2. 通过容器运行时来完成容器的创建、运行、销毁等实际工作
3. Docker 使用的是 containerd 作为其运行时；Kubernetes 支持 containerd，CRI-O 等多种容器运行时
4. 这些容器运行时都遵循了 OCI 规范，并通过 runc 来实现与操作系统内核交互来完成容器的创建和运行
如果安装 K8S 时安装了 cri - dockerd ，此时运行时实际还是 Docker 。
cri - dockerd 是一个垫片（shim ），在 Kubernetes 不再原生支持 Docker 作为容器运行时（从 1.24 版本移除 dockershim ）的情况下，它能在 kubelet 和 Docker 之间建立桥梁 。通过 cri - dockerd ，一头遵循 CRI 标准与 kubelet 交互，另一头与 Docker API 交互，从而使 Docker 能继续作为 K8S 的容器运行时，实现容器的创建、运行、管理等操作 。 图中涉及的 containerd、CRI - O 等运行时此时不处于直接使用状态 。
知识花絮：
1. Dockershim
在 Kubernetes 包括一个名为 dockershim 的组件，使它能够支持 Docker。但 Docker 由于比 Kubernetes 更早，没有实现 CRI，所以这就是 dockershim 存在的原因，它支持将 Docker 被硬编码到 Kubernetes 中。
随着容器化成为行业标准，Kubernetes 项目增加了对额外运行时的支持，比如通过 Container Runtime Interface (CRI) 容器运行时接口来支持运行容器。因此 dockershim 成为了 Kubernetes 项目中的一个异类，对 Docker 和 dockershim 的依赖已经渗透到云原生计算基金会（CNCF）生态系统中的各种工具和项目中，导致代码脆弱。
2022 年 4 月 dockershim 将会从 Kubernetes 1.24 中完全移除。今后 Kubernetes 将取消对 Docker 的直接支持，而倾向于只使用实现其容器运行时接口的容器运行时，这可能意味着使用 containerd 或 CRI-O。
这并不意味着 Kubernetes 将不能运行 Docker 格式的容器。containerd 和 CRI-O 都可以运行 Docker 格式（实际上是 OCI 格式）的镜像，它们只是无需使用 docker 命令或 Docker 守护程序。
Kubernetes 项目不必手动添加对每个运行时的支持，CRI API 描述了 Kubernetes 如何与每个运行时进行交互，由运行时决定如何实际管理容器，因此只要它遵守 CRI 的 API 即可。
你可以使用你喜欢的 containerd 来运行你的容器，也可以使用 CRI-O 来运行你的容器，因为这两个运行时都实现了 CRI 规范。
2. containerd
containerd 是一个来自 Docker 的高级容器运行时，并实现了 CRI 规范。它是从 Docker 项目中分离出来，之后 containerd 被捐赠给云原生计算基金会（CNCF）为容器社区提供创建新容器解决方案的基础。
所以 Docker 自己在内部使用 containerd，当你安装 Docker 时也会安装 containerd。
containerd 通过其 CRI 插件实现了 Kubernetes 容器运行时接口（CRI），它可以管理容器的整个生命周期，包括从镜像的传输、存储到容器的执行、监控再到网络。
3. CRI-O
CRI-O 是另一个实现了容器运行时接口（CRI）的高级别容器运行时，可以使用 OCI（开放容器倡议）兼容的运行时，它是 containerd 的一个替代品（同类产品）。
CRI-O 诞生于 RedHat、IBM、英特尔、SUSE、Hyper 等公司。它是专门从头开始创建的，作为 Kubernetes 的一个容器运行时，它提供了启动、停止和重启容器的能力，就像 containerd 一样。
4. Runc
runc 是一个轻量级的开源工具，用于在 Linux 系统上创建和运行符合 Open Container Initiative (OCI) 规范的容器。它是容器技术栈中的底层组件，负责执行容器的实际启动、运行和资源隔离，是许多容器运行时（如 Docker、containerd、CRI-O）的核心依赖。
runc 的几个替代品：
crun一个用 C 语言编写的容器运行时（相比之下，runc 是用Go编写的。）来自 Katacontainers 项目的kata-runtime，它将 OCI 规范实现为单独的轻量级虚拟机（硬件虚拟化）。
Google 的gVisor，它创建了拥有自己内核的容器。它在其运行时中实现了 OCI，称为 runsc。
runc 是一个在 Linux 上运行容器的工具，所以这意味着它可以在 Linux 上、裸机上或虚拟机内运行。
在 Windows 上，它略有不同，与 runc 相当于是微软的主机计算服务（HCS），它包括一个叫runhcs的工具，它本身是 runc 的一个分叉，也实现了开放容器倡议的规范。