浅谈 K8s CRI

1. 概述

进入 K8s 的世界，会发现有很多方便扩展的 Interface，包括 CRI, CSI, CNI 等，将这些接口抽象出来，是为了更好的提供开放、扩展、规范等能力。

K8s CRI(Container Runtime Interface) 是 K8s 定义的一组与容器运行时进行交互的接口，用于将 K8s 平台与特定的容器运行时实现解耦。CRI 在 Kubernetes 1.5 中引入，并充当 kubelet 和容器运行时之间的桥梁。目前实现了 CRI spec 的 Runtime 有 Docker Engine、containerd、CRI-O、Mirantis Container Runtime(Docker 企业版) 等。

2020 年，K8s 宣布弃用 dockershim^[1]，标志着容器运行时正式向 CRI 切换，一方面是为了将 kubelet 核心主干代码与 Runtime 相关代码解耦，便于更好的维护；另一方面则是为了便于生态圈按 CRI spec 实现自己的运行时插件，提供个性化的运行时扩展能力，以满足对更多 Runtime 的支持，提高 K8s 生态的开放性和扩展性。

本文将从 Docker Engine、Kubelet 启动、Pod 创建/删除、Container 创建/删除、CRI RPC 调用等核心流程，对 CRI 实现机制进行了解析。

流程概览如下：

K8s-CRI

本文及后续相关文章都基于 K8s v1.23

2. 从 Docker 说起

2.1 Docker Engine

Docker Engine 是用来运行和管理容器的核心软件。通常人们会简单地将其代指为 Docker 或 Docker 平台。

Docker Engine 主要的组件构成：Docker 客户端（Docker Client）、Docker 守护进程（Docker daemon）、Docker APIs、containerd 以及 runc，它们共同负责容器的创建和运行。

docker-engine

2.2 OCI

OCI（Open Container Initiative，开放容器计划），是在 2015 年由 Docker、CoreOS 等公司共同成立的项目，并由 Linux 基金会进行管理，致力于 container runtime 标准的制定和 runc 的开发等工作。

所谓 container runtime，主要负责的是容器的生命周期的管理。OCI 主要分为容器运行时规范(runtime-spec) 和镜像规范(image-spec) 两部分，runtime-spec 标准对容器的创建、删除、查看、状态等操作进行了定义，image-spec 对镜像格式、打包(Bundle)、存储等进行了定义。

2.3 runc

runc，是由 Docker 贡献的对于 OCI 标准的一个参考实现，是一个可以用于创建和运行容器的 CLI(command-line interface) 工具。runc 直接与容器所依赖的 Cgroup/OS 等进行交互，负责为容器配置 Cgroup/namespace 等启动容器所需的环境，创建启动容器的相关进程。

为了兼容 OCI 标准，Docker 也做了架构调整。将容器运行时相关的程序从 Docker daemon 剥离出来，形成了containerd。containerd 向 Docker 提供运行容器的 API，二者通过 gRPC 进行交互。containerd 最后会通过 runc 来实际运行容器。

runc

3. CRI