[k8s] k8s 和 CRI 的简单介绍

毫无疑问, Docker 开启并推动了容器 (container) 的大流行. 但其将同一个名词 (docker) 在多个领域的复用, 人为制造了认知上的混乱. 随后 k8s 的流行和各家大公司的入局, 又制造了大量的专业术语, 进一步的推高了认知成本.

Docker

Docker 应该是大多数人最熟悉的容器相关工具, 我们先从这儿入手.

docker cli -> docker engine -> containerd -> runc -> container

container 代表运行中的容器.
runc, 是符合 OCI 标准的 low-level container runtime 实现, 直接调用 Linux cgroups 来管理容器.
containerd, 是 high-level container runtime, 我们后续会展开讲它是什么, 以及为什么会出现.
docker engine, 常驻的后台进程, 接收 docker cli 发出的指令并通过 containerd 来关联容器和镜像.
docker cli, 我们直接使用的工具包.

使用 mac 的同学也许注意到另外一个名词, Docker Desktop. 这是一个针对个人的 Docker 客户端, 包括了 linux 虚拟机, docker engine 和其他一些可视化工具.

当然, Docker 在 13 年刚出现时并不是我们上面讲诉的样子.

容器的基础是 Linux 系统 08 年引入的 cgroups. 通过 cgroups 我们可以限制一组进程使用的各类资源, 包括 CPU, 内存和磁盘等.

13 年推出的 Docker 基于 cgroups, 通过简化镜像的定义, 构建和管理, 以及容器的运行, 获得了巨大的成功. 到了 15 年, Docker 公司推动成立了 Open Container Initiative (OCI), 尝试为新兴的容器生态建立互通标准. 核心产物是 runtime-spec, 定义了创建和运行容器的标准. runc 是这份协议的官方实现, 由 Docker 公司捐赠.

containerd 的出现是 Docker 为了更好的模块化, 官方说法. 但也有可能是 k8s 称为容器编排的事实标准后, Docker 的挽救措施.

Container Runtime Interface

k8s 在推出之初直接使用 docker engine 来运行容器. 但其作为一个容器编排平台显然不应该绑定容器运行时, 所以他推出了 Container Runtime Interface, CRI. CRI 定义了一套 gRPC API, kubelet 作为客户端, 可以通过任意实现了这套 API 的容器运行时来管理容器. CRI 完美的实现了 k8s 的容器中立, 简化了容器运行时开发者的对接成本, 允许使用者自行指定容器运行时.

基于 Docker 和 k8s 当初的竞争关系, CRI 的定义显然不会兼容 docker engine, Docker 也不会主动去适配 CRI. 所以 k8s 推出了 dockershim, 可以将 docker engine 包装成符合 CRI 要求的容器运行时. 但是在 k8s v1.20 开始, dockershim 就进入不再维护状态, 并在 v1.24 开始被彻底抛弃.

Container Runtime

我会把支持了 OCI image-spec, distribution-spec 和 runtime-spec 的容器运行时称为 high-level, 把仅实现了 runtime-spec 的容器运行时称为 low-level.

High-level runtime 即可以构建, 推送和拉取镜像, 也可以创建和销毁容器. 大多数情况下, 它们也实现了 CRI. 主流 high-level container runtime 包括 containerd 和 CRI-O.

Low-level runtime 的典型是 runc.

[k8s] k8s 和 CRI 的简单介绍

[k8s] k8s 和 CRI 的简单介绍

Docker

Container Runtime Interface

Container Runtime

References