请先阅读《云原生》中的第一章（云时代的前夜：虚拟化）

一、容器技术发展史

上面这个图应该从下往上看才符合历史轨迹。

（一）OCI 规范 与 RunC

OCI 规范：制定并维护 容器镜像格式 和 容器运行时 的正式规范（OCI Specifications）。其核心产出是： OCI Runtime Spec（容器运行时规范）、OCI Image Spec（镜像格式规范）、OCI Distribution Spec（镜像分发规范）。所以 OCI 组织解决 的是容器的构建、分发和运行。

RunC 的本质就是：可以不通过 Docker Damon 直接操纵容器， 是 Docker 公司捐出的 Libcontainer 项目改名的。

（二）CRI 与 Container Runtime

容器编排的主权的争夺以 K8S 胜出为结果。

1. CRI 标准

CRI 标准：用于 K8S 和 特定的容器运行时 解耦

2. Container Runtime

（1）为什么需要 Container Runtime

如果我们想自动化管理容器，我们就需要一个容器管理器。为什么这样？RunC 不是已经可以操纵容器了吗？但我们不妨想象下面的情况：如何启动数十几个容器并跟踪它们的状态?当某些容器在失败时需要重新启动 或者 需要在终止时释放资源，都必须从注册表中提取图像？需要配置容器间网络…于是就需要有 Low-Level 和 High-Level 容器运行时，显然 runc 就是 Low-Level 的实现。

---

（2）High-Level Container Runtime
Containerd：被 Docker 从 Docker Engine 种剥离出来捐献给 CNCF 作为运行时标准。但最初的 Containerd 并不接入 CRI 标准，于是 Google 开发了 cri-containerd 将 containerd 加入到 CRI 标准中，用来完成 K8S 和容器之间的交互。直到在 CRI-O 之后，才倒逼了 Containerd 接入 CRI 标准。
其实我们可以把 runc 看作一个命令行工具，而 containerd 是一个长期居住守护进程。runc 的实例并不能超过底层容器进程，而 containerd 可以管理超过数千个 runc 容器。containerd 更像是一个服务器，它侦听传入请求以启动、停止或报告容器的状态。然而 containerd 不仅仅是一个容器生命周期管理器，它还负责镜像管理（从注册中心拉取和推送镜像，在本地存储镜像等）、跨容器网络管理和其他一些功能。

CRI-O：可以让开发者直接从 Kubernetes 来运行容器，这意味着** Kubernetes 可以不依赖于传统的容器引擎（比如 Docker），也能够管理容器化工作负载**。容器此时也回归到自己的位置：更好的封装云原生的程序。

---

（2）什么是 Container Runtime

Container Runtime：管理容器的一类软件组件。它提供了一种隔离和管理应用程序的环境**，使得应用程序可以在独立的环境中运行，而不会相互干扰。除资源隔离外，容器运行时还会负责处理容器的创建、启动、停止和销毁等生命周期管理任务**，以及 与Host OS和 Hardware 的交互。

（3）修改节点的 Container Runtime 镜像源

cd /etc/containerd
ls
vi config.toml # 将 IP 地址修改为当前 DCE5火种机 的地址
systemctl restart containerd