这些概念可以分为以下大类：

• 容器运行时Container Runtimes
• 容器运行时接口Container Runtime Interface(CRI)
• 容器网络接口Container Network Interface(CNI)
• 容器网络接口Container Storage Interface(CSI)

分类具体说明如下：

一、容器运行时Container Runtimes

  1.1、容器规范OCI (Open Container Initiative)

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

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

  1.2、容器实现产品

     对于OCI容器运行时规范，其常见实现产品有：containerd、Docker、CRI-O、runc、LXC等等

在容器技术中，容器运行时可以分为三种类型：

1. 低级运行时：指的是负责容器隔离和生命周期管理的基本运行时组件。在这种运行时中，容器是通过Linux内核的cgroups和namespace机制进行隔离和管理的。常见的低级运行时包括Docker的runc、lxc等。这种运行时通常具有轻量化和高性能的优点，但缺乏高级特性和管理工具。

2. 高级运行时：是在低级运行时的基础上，提供了更丰富的特性和管理工具的容器运行时。这些特性可以包括容器网络、存储、监控、镜像传输、镜像管理、镜像API等功能，以及各种管理工具等。常见的高级运行时包括Docker、Containerd和CRI-O等。这种运行时通常具有更为丰富的特性和管理工具，但也带来了更高的复杂性和资源消耗。高级运行时不是真正的运行时，需要调用低级运行时才能运行。

3. 沙盒或虚拟化运行时：是在容器运行时中使用沙盒技术或虚拟化技术实现容器隔离和管理的运行时。这种运行时通常具有更强的隔离性和安全性，但也会带来更高的性能开销和复杂性。常见的沙盒或虚拟化运行时包括gVisor、Kata Containers等。

• containerd

     containerd 诞生于原始 Docker 项目，后被单独拆分出来作为独立的一部分，可以不与Docker绑定。它负责管理容器的生命周期（创建、启动、停止）以及镜像的拉取、存储等操作。

     特点：轻量级、模块化，提供核心的容器管理功能。是 Kubernetes 默认的容器运行时（通过 CRI 集成）。 符合 OCI 规范，支持标准的容器镜像和容器规范。使用场景：广泛用于 Kubernetes 环境，适合需要高效、稳定运行时的场景。

     

• Docker

     这里的Docker指Docker Engine。Docker 是一个大而完备的应用，提供了丰富的开发工具，支持容器的构建、运行、网络、存储管理。

    特点：提供了丰富的开发工具，支持容器的构建、运行、网络、存储管理。拥有 Docker Hub 这样的大规模公共镜像库。支持多平台，包括 Linux、Windows 和 macOS。使用场景：适用于开发者进行本地开发、测试和小规模生产环境。

    Docker 由 3 部分构成：Docker Server (docker daemon, 简称 dockerd)、REST API 和 Docker CLI。借助 Docker Engine 既能便捷地运行容器进程进行集成开发、也能快速构建分发镜像。Docker与containerd的关系图如下。

• CRI-O

     CRI-O 是专门为 Kubernetes 设计的轻量级容器运行时，旨在通过遵循 Kubernetes 的 CRI（Container Runtime Interface）规范，简化与 Kubernetes 的集成。CRI-O 使用 OCI 容器镜像格式和 runc 作为默认运行时。 

     特点：专为 Kubernetes 优化，减少了与 Docker 一样的额外功能，轻量级且更高效。兼容 OCI 标准，支持标准的镜像格式和运行时。易于与 OpenShift 等 Kubernetes 发行版集成。适合在大规模生产环境下使用，特别是与 Kubernetes 搭配使用。

• runc

     runc 是一个符合 OCI 标准的命令行工具，用于根据容器配置文件创建和运行容器。它最初由 Docker 开发，现在已经成为一个独立项目，并作为很多容器运行时的底层执行引擎。属于低级运行时。

    特点：非常轻量，专注于启动和运行容器。符合 OCI 容器运行时规范，作为标准容器运行时的核心组件。是 containerd 和 CRI-O 的底层运行时。使用场景：用于开发自定义容器运行时，或者作为容器执行引擎集成在其他运行时中。

• LXC（Linux Containers）

     LXC 是 Linux 上最早的容器化技术之一，基于 Linux 内核的 cgroups 和 namespaces 提供轻量级的容器管理。尽管 Docker 现在已经广泛流行，LXC 仍然被某些特定场景下使用。

    特点： 基于内核的轻量级容器技术。 提供与传统虚拟机类似的用户体验，支持复杂的网络和存储配置。使用场景：适用于那些需要稳定、长期支持的容器化工作负载，特别是在嵌入式系统或老旧系统中

二、容器运行时接口Container Runtime Interface (CRI)

  2.1 CRI概念

      Kubernetes中的Kubelet组件通过Container Runtime Interface (CRI)与容器运行时交互。

      容器运行时接口（CRI）是 在 kubelet 与容器运行时之间通信的主要协议。Kubernetes 容器运行时接口（CRI）定义了在节点组件 kubelet 和容器运行时之间通信的主要 gRPC 协议

      文档网址：https://kubernetes.io/docs/concepts/architecture/cri/

  2.2 kubelet与Docker的交互关系变迁

     如上图，在Kubernetes＜1.24版，通过dockershim操作dockerd，实现对容器运行时的操纵。在Kubernetes 1.24 版本中移除 dockershim，也无需dockerd作为中介，直接操作容器。

另：dockershim原由Kubernetes维护，被移除淘汰后不再维护。后Mirantis和Docker接手将dockershim改名为cri-dockerd并继续维护。cri-dockerd是一个“垫片”适配器，使得可以通过Kubernetes的CRI来控制Docker(Docker Engine)。其官网：

https://mirantis.github.io/cri-dockerd/

    从2018年Containerd 1.1版本开始，集成了以前在外部CRI-Containerd，以CRI plugin插件形式作为containerd内的一部分。见下图：

    2.3 现在kubelet与Containerd交互

    现在通常使用Containerd 1.6+或者更高版本，因此交互关系是上图最下面的方式（既Containerd 1.1版的交互方式）。对此：

    一方面，在安装Kubernetes的kubelet时会自动安装cri-tools工具集合，工具里包括crictl的CRI客户端工具，以便客户端工具通过访问CRI plugin插件来操纵Containerd。

    另一方面，在安装完Containerd后，还需要确认CRI plugin插件也已安装（手工或自动安装），这样Containerd才能通过CRI plugin被kubelet访问到。

三、容器网络接口Container Network Interface (CNI)

    随着容器技术逐步落地，对于容器云的网络特性要求也越来越高，跨节点的容器间网络已是最基本要求，更高的要求包括容器固定IP地址、支持一个容器多个IP、多个子网隔离、ACL控制策略、SDN集成等。目前容器网络模型主要有：Docker提出的Container Network Model（CNM）和CoreOS公司提出的Container Network Interface (CNI)。

	CNI (被Kubernetes采纳)	CNM (Docker Swarm)
设计理念	插件化接口规范	整体解决方案
生命周期管理	容器启停时动态调用插件	网络驱动全程托管
网络作用域	Pod级别	Network Sandbox/Endpoint/Network三个组件
主流实现	Flannel、Calico、Weave、Contiv、Multus、Romana等	Docker Swarm内置驱动 Cisco Contiv、Kuryr、OVN、Weave、Project Calico等
配置复杂度	需手动维护插件配置	声明式网络定义
跨平台支持	支持Kubernetes/Mesos等	仅限Docker生态

   CNI已被Kubernetes采纳，CNI是一个用于配置容器网络接口的规范和库集合，主要用于容器之间的网络通信（对于Kubernetes则为Pod之间网络通信）。CNI已成为Kubernetes等容器编排系统的标准网络接口，提供了灵活的网络配置能力。

    该CNI接口有多种实现提供者，例如Flannel、Calico等、Weave、Cilium‌‌。由于Calico比较出色，功能丰富，使用广泛。多数情况选择Calico作为CNI网络插件。

四、容器存储接口Container Storage Interface (CSI)

      Container Storage Interface (CSI) 用于Kubernetes与具体存储系统之间建立一套标准的存储接口。

     虽然Kubernetes通过PV、PVC、StorageClass已经提供了强大的基于存储插件的存储管理机制，但是各种存储插件都是在Kubernetes代码的主干仓中，这种代码混合在一起会带来很多问题。因此，Kubernetes逐步推出CSI标准，目的是标准与具体实现分离，存储提供者与Kubernetes代码彻底解耦。