一篇文章搞清楚cri oci docker cri-o containerd[未完待续]

1. CRI （Container Runtime Interface)

Kubernetes 推出CRI（Container Runtime Interface）的原因主要是为了提高容器运行时的灵活性、解耦 Kubernetes 与 Docker 的依赖，并促进容器生态系统的发展。

早期，Kubernetes 主要依赖于 Docker 作为容器运行时。虽然 Docker 是非常流行的容器工具，但它实际上是一个集成了多个组件的复杂平台，而 Kubernetes 只需要其中的部分功能（容器运行时部分）。Docker 本身依赖于 containerd 和 runc 来实现底层的容器运行，但这些额外的功能对于 Kubernetes 来说是不必要的。为了解决这个依赖性问题，Kubernetes 决定引入 CRI。

• 定义：CRI 是 Kubernetes 定义的一个接口，用来抽象化容器运行时，使得 Kubernetes 可以与不同的容器运行时进行通信。
• 作用：CRI 定义了一套 API，使 Kubernetes（通过 kubelet）可以与底层的容器运行时（如 containerd 或 CRI-O）进行交互，而不依赖于特定的容器运行时。
• 典型实现：
• containerd 和 CRI-O 都是符合 CRI 规范的容器运行时。containerd 通常与 Docker 一起使用，而 CRI-O 则是一个轻量的运行时，专门为 Kubernetes 提供支持。

k8s官方文档是这样介绍的：
参考： https://kubernetes.io/zh-cn/docs/concepts/architecture/cri/

容器运行时接口（CRI）

CRI 是一个插件接口，它使 kubelet 能够使用各种容器运行时，无需重新编译集群组件。
你需要在集群中的每个节点上都有一个可以正常工作的容器运行时， 这样 kubelet 能启动 Pod 及其容器。
容器运行时接口（CRI）是 kubelet 和容器运行时之间通信的主要协议。
Kubernetes 容器运行时接口（Container Runtime Interface；CRI）定义了主要 gRPC 协议， 用于节点组件 kubelet 和容器运行时之间的通信。

API

特性状态： Kubernetes v1.23 [stable]

当通过 gRPC 连接到容器运行时，kubelet 将充当客户端。运行时和镜像服务端点必须在容器运行时中可用， 可以使用 --image-service-endpoint 命令行标志在 kubelet 中单独配置。

对 Kubernetes v1.31，kubelet 偏向于使用 CRI v1 版本。 如果容器运行时不支持 CRI 的 v1 版本，那么 kubelet 会尝试协商较老的、仍被支持的所有版本。 v1.31 版本的 kubelet 也可协商 CRI v1alpha2 版本，但该版本被视为已弃用。 如果 kubelet 无法协商出可支持的 CRI 版本，则 kubelet 放弃并且不会注册为节点。

升级
升级 Kubernetes 时，kubelet 会尝试在组件重启时自动选择最新的 CRI 版本。 如果失败，则将如上所述进行回退。如果由于容器运行时已升级而需要 gRPC 重拨， 则容器运行时还必须支持最初选择的版本，否则重拨预计会失败。 这需要重新启动 kubelet。

2. OCI (Open Container Initiative)

定义：OCI 是一个开放标准，用于定义容器格式和运行时的规范。它旨在确保容器镜像的格式和容器运行时的操作方式在不同的实现之间保持兼容性。
• 主要组件：
• OCI 镜像规范：定义了容器镜像的存储和分发格式。
• OCI 运行时规范：定义了如何运行和管理容器，例如容器的生命周期、资源限制等。
• 典型实现：像 runc 就是一个 OCI 标准的运行时实现，负责实际运行容器。

官方文档： https://opencontainers.org/

3. container runtime

容器运行时.

常见的容器运行时包括以下几种，它们大多符合 OCI（Open Container Initiative）标准，并在不同场景中广泛使用。每种运行时有其独特的优势和适用场景。

1. Docker
   • 概述：Docker 是最早也是最流行的容器运行时，专注于为开发者提供容器的打包、分发和运行功能。它最初包含一个完整的容器引擎，但随着架构的演变，Docker 现在主要依赖 containerd 作为其底层运行时。
   • 特点：
   • 提供了丰富的开发工具，支持容器的构建、运行、网络、存储管理。
   • 拥有 Docker Hub 这样的大规模公共镜像库。
   • 支持多平台，包括 Linux、Windows 和 macOS。
   • 使用场景：适用于开发者进行本地开发、测试和小规模生产环境。

2. Containerd
   • 概述：containerd 是一个高效的容器运行时，最初是 Docker 的一部分，后来被独立出来。它负责管理容器的生命周期（创建、启动、停止）以及镜像的拉取、存储等操作。
   • 特点：
   • 轻量级、模块化，提供核心的容器管理功能。
   • 是 Kubernetes 默认的容器运行时（通过 CRI 集成）。
   • 符合 OCI 规范，支持标准的容器镜像和容器规范。
   • 使用场景：广泛用于 Kubernetes 环境，适合需要高效、稳定运行时的场景。

3. CRI-O
   • 概述：CRI-O 是专门为 Kubernetes 设计的轻量级容器运行时，旨在通过遵循 Kubernetes 的 CRI（Container Runtime Interface）规范，简化与 Kubernetes 的集成。CRI-O 使用 OCI 容器镜像格式和 runc 作为默认运行时。
   • 特点：
   • 专为 Kubernetes 优化，减少了与 Docker 一样的额外功能，轻量级且更高效。
   • 兼容 OCI 标准，支持标准的镜像格式和运行时。
   • 易于与 OpenShift 等 Kubernetes 发行版集成。
   • 使用场景：适合在大规模生产环境下使用，特别是与 Kubernetes 搭配使用。

4. Runc
   • 概述：runc 是一个符合 OCI 标准的命令行工具，用于根据容器配置文件创建和运行容器。它最初由 Docker 开发，现在已经成为一个独立项目，并作为很多容器运行时的底层执行引擎。
   • 特点：
   • 非常轻量，专注于启动和运行容器。
   • 符合 OCI 容器运行时规范，作为标准容器运行时的核心组件。
   • 是 containerd 和 CRI-O 的底层运行时。
   • 使用场景：用于开发自定义容器运行时，或者作为容器执行引擎集成在其他运行时中。

5. Kata Containers
   • 概述：Kata Containers 是一种结合了容器的轻量性和虚拟机的隔离性的容器运行时。它通过使用轻量级虚拟机来运行容器，从而提供比传统容器更强的安全隔离。
   • 特点：
   • 提供比传统容器更强的安全性，利用虚拟机进行更深层次的隔离。
   • 支持多种 hypervisor（虚拟机管理程序），如 QEMU、Firecracker。
   • 符合 OCI 规范，兼容现有的容器生态系统。
   • 使用场景：适合对隔离要求极高的场景，如多租户环境或需要高安全性隔离的企业环境。

6. gVisor
   • 概述：gVisor 是由 Google 开发的一个容器运行时，它通过在用户空间实现部分 Linux 内核系统调用来提供安全隔离，介于传统容器和虚拟机之间。
   • 特点：
   • 提供更高的安全性，避免容器直接访问主机内核。
   • 不依赖虚拟化技术，可以使用标准的容器管理工具运行。
   • 兼容 OCI 容器规范。
   • 使用场景：适合那些需要在 Kubernetes 环境中运行高安全隔离容器的用户。

7. Firecracker
   • 概述：Firecracker 是一种用于安全、多租户服务的轻量级虚拟化技术，最初由 AWS 开发，专门用于快速启动和管理微虚拟机（microVMs）。它与 containerd 集成良好，可以用于运行容器。
   • 特点：
   • 启动速度快，资源占用低，适合大规模、多租户环境。
   • 提供与虚拟机级别相似的隔离性，确保高安全性。
   • 兼容 OCI 规范，通过 containerd 集成。
   • 使用场景：适合在 AWS Lambda、Fargate 等环境中使用，特别是对安全性和启动时间要求高的场景。

8. Podman
   • 概述：Podman 是一个与 Docker 类似的容器运行时，但与 Docker 不同，Podman 不需要守护进程，可以以 rootless 模式运行容器。它与 Docker 兼容，允许使用与 Docker 相同的命令来管理容器。
   • 特点：
   • 无需守护进程，用户可以直接在命令行管理容器。
   • 支持 rootless 容器，增强了安全性。
   • 兼容 Docker CLI，允许开发者使用相同的工作流。
   • 使用场景：适合那些需要无守护进程运行的场景，或者需要增强的安全隔离的开发者环境。

9. LXC（Linux Containers）
   • 概述：LXC 是 Linux 上最早的容器化技术之一，基于 Linux 内核的 cgroups 和 namespaces 提供轻量级的容器管理。尽管 Docker 现在已经广泛流行，LXC 仍然被某些特定场景下使用。
   • 特点：
   • 基于内核的轻量级容器技术。
   • 提供与传统虚拟机类似的用户体验，支持复杂的网络和存储配置。
   • 使用场景：适用于那些需要稳定、长期支持的容器化工作负载，特别是在嵌入式系统或老旧系统中。

总结
Docker 和 containerd 是最广泛使用的容器运行时。
CRI-O 专注于 Kubernetes 环境，适合生产环境中的大规模集成。
Kata Containers 和 gVisor 提供增强的安全隔离，适用于需要高安全性的多租户场景。
Firecracker 适合资源受限、启动速度要求高的环境。
Podman 提供与 Docker 类似的体验，但无需守护进程，适合开发者和轻量化需求。

4.k8s发展容器运行时历程

早期 Kubernetes 完全依赖且绑定 Docker，并没有过多考虑够日后使用其他容器引擎的可能性。当时 kubernetes 管理容器的方式通过内部的 DockerManager 直接调用 Docker API 来创建和管理容器。

不过这里同样也有一个例外，那就是 Docker，由于 Docker 当时的江湖地位很高，Kubernetes 是直接内置了 dockershim 在 kubelet 中的，所以如果你使用的是 Docker 这种容器运行时的话是不需要单独去安装配置适配器之类的，当然这个举动似乎也麻痹了 Docker 公司。

与此同时 Kubernetes 社区也做了一个专门用于 Kubernetes 的 CRI 运行时 CRI-O，直接兼容 CRI 和 OCI 规范。

https://kubernetes.io/zh-cn/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/

只是移除了Dockershim的支持，docker还是可以作为容器运行时，因为docker有containerd组件。

https://blog.youkuaiyun.com/A_M_O_R_/article/details/125426652
https://www.thebyte.com.cn/container/CRI-in-Kubernetes.html#cri
https://www.qikqiak.com/k8strain2/containerd/runtime/
https://blog.51cto.com/u_14035463/5585118
https://blog.youkuaiyun.com/A_M_O_R_/article/details/125426652
https://blog.youkuaiyun.com/yangchao1125/article/details/134695917