runtime cri
同理去理解CRI
在k8s刚出来的时候，除了docker之外并没有几个runtime（运行时，就是管理容器的东西），所以呢在k8s里就内置了代码来适配docker，如下图。
后来除了docker之外又有了其他的runtime，比如rkt。然后呢在kubernetes代码里也内置了代码来适配rkt。
后来又有了越来越多的runtime，比如cri-o、containerd等，他们也想集成到kubernetes里让kubernetes以他们作为runtime。
这样一来，kubernetes发现，这样不行啊，这样没完没了的，我这代码太臃肿了不好维护。干脆我就开发一个叫做CRI（容器运行时接口）的标准，并对这些运行时说：“你们也别都想着让把你们整合到我的代码里了，我这开发了一个接口叫做CRI，你们这些runtime只要符合CRI标准就能连接到我了。当然了，如果你们不符合CRI标准的话，你们自己就弄一个转接口转接一下就行了。这个转接口就称之为shim（垫片）吧”。
然后呢有些runtime就开发了符合CRI标准的转接线就是一个shim，叫做CRI-shim。当然有些runtime本身就符合CRI接口了，那么这个runtime就是CRI-shim。
但是呢docker说，我没有CRI接口也开发不出来符合CRI接口的shim。那咋办呢？没办法，因为docker太强大了，所以kubernetes（其实是kubelet）里仍然内置了连接docker的代码叫做（dockershim）。
除了dockershim是内置的，其他的shim一律称之为remote。所以在使用除docker之外的runtime，kubelet都会有一个选项叫做KUBELET_EXTRA_ARGS=–container-runtime=remote。
又过了几年，这时kubernetes已经足够强大了，而且也有了很多其他runtime可选，也不是非docker不可了，所以他必须要一视同仁，所以呢从kubernetes 1.24版本里就把dockershim从kubernetes（其实是kubelet）的代码中移除了。
这下完了，docker不能再作为kubernetes的runtime了。如果要非想让docker作为kubernetes的runtime的话，那么就必须要找一个符合CRI标准的转接口了，这个就是cri-docker，他是一个符合CRI标准的shim（转接口），他可以作为一个转接口连接kubernetes和docker。
1.1 什么是runc
要理解runc，我们需要了解容器标准OCI（Open Container Initiative）可以理解为容器运行标准，是由多个组织共同成立，主要是维护runc的标准协议和相关的开发工作。所谓的runc主要是负责容器生命周期的管理，以及对容器状态的描述。runc的实现标准主要是根据OCI相关的规范来实现容器生命周期的管理，也是所有容器运行的基础功能。runc容器可以说实现了cgroup/linux kernel相关的隔离抽象接口。自从docker项目改为moby以后，docker按OCI标准抽出runc的项目，docker根据containerd直接调用了runc的api。总结，runc抽象出来的一个容器运行标准的api，主要是容器生命周期管理的一个项目。
1.2 runc与docker,k8s
- runc for docker docker主要在docker engine上实现了对runc的调用，通过docker的contanerd来对runc api相关的调用操作。runc主要是containerd底层的实现逻辑。如图：
- runc for k8s k8s我们其实可以理解为一个强档的调度系统，可以实现灵活的容器调度。在k8s初期的版本中，是可以实现对docker的兼容方式，k8s通过docker engine的api直接调用来实现容器的周期管理。但是在k8s 1.5+版本之后，k8s实现了自己的CRI（containcer runtime interface），实现CRI之后一个非常大的好处就是对容器的调度实现了自主管理，这样很多时候久不依赖docker engine的api接口了，同k8s引入了pod的概念，pod是k8s运行的基础单元，对于k8s pod解析可以放到后面。 docker调用runc主要是通过contained来实现对容器的周期管理，k8s同时也实现了CRI的containerd，然后CRI contanerd调用docker的containerd。如图：
当然我们可以发现市场上还有很多容器方案，比如阿里的pouch实现的容器方案，也是给予runc来实现。
综上，基于runc标准实现，给我们容器镜像的迁移兼容变得非常简单。
1.3 runc 实现解析
runc实现了容器的init，run，create，ps...我们在运行容器所需要的cmd。runc的项目可以分为2个部分，第一个就是底层隔离，网络等实现，这个主要在libcontainer中实现，这一层主要是对操作系统调用的封装,还有就是对docker文件系统的实现。第二层就是提供基础容器cmd调用，比如提到的create，ps等cmd. 基本runc主要是这2块功能，其实只要有这2大块功能，其实就可以自己实现对container生命周期管理了。以下我将解析几个cmd来说明怎么调用的libcontainer。
自此，K8s 慢慢成为云原生领域的标配，其生态也越做越大、越做越完善。Docker 公司为了融入生态，开源了 Docker 的核心依赖 containerd 。此外 K8s 为了对接下一层的容器，也因为其中立性搞了一个运行时接口，也就是 CRI（Container Runtime Interface），runc、containerd 等运行时都去支持此接口。由于当时确实没有啥 high level 的 runtime，oci-o 虽然支持 CRI 接口，但其功能太弱；containerd 也尚未成熟，而且其当时的定位是嵌入到系统中，并非给终端用户使用；rkt 有自己的一套体系（后来这个项目也失败了）。只能暂时为了适配 Docker 搞了个 shim，将 CRI 转换为 Docker API。K8s 和 Docker 进入了冷静期，双方都在各自优化自己，互不干扰。然而平静之下仍是暗潮汹涌，CNCF 社区一直在不断完善 containerd，其定位也发生了改变，由原来的系统嵌入组件，变成了今天的“工业标准容器运行时”，并提供给终端用户使用。直到去年，K8s 宣布废弃使用 Docker，而改用 Containerd。其实除了这些商业因素，另一方面 K8s 已经提供了标准接口对接底层容器运行时，不再想单独维护一个 类似于 Docker shim 的适配层去迎合不同的运行时，这样做也无可厚非（其实我看就是自己做大了，把锅扔给底层了~嘘
当然了，这也不能说docker不行了，docker仍然是非常有用的，比如构建镜像、搭建仓库等。
我们都知道，容器技术其实在很久以前就已经出现，但只是在最近十年由于云计算的发展才逐渐进入大众的视野。对于容器运行时，传统意义上来说就是代表容器从拉取镜像到启动运行再到中止的整个生命周期，较类似于 Java 中的 Java hotspot 运行时。在本文中我会介绍容器运行时相关概念及组件原理，梳理下我们常听到的 OCI、runc、containerd 等名词之间的关系。
何为容器运行时
容器运行时顾名思义就是要掌控容器运行的整个生命周期，以 docker 为例，其作为一个整体的系统，主要提供的功能如下：
-
制定容器镜像格式
-
构建容器镜像
docker build -
管理容器镜像
docker images -
管理容器实例
docker ps -
运行容器
docker run -
实现容器镜像共享
docker pull/push
然而这些功能均可由小的组件单独实现，且没有相互依赖。而后 Docker 公司与 CoreOS 和 Google 共同创建了 OCI (Open Container Initial)，并提供了两种规范：
-
运行时规范(https://github.com/opencontainers/runtime-spec) 描述如何运行
filesystem bundle -
镜像规范(https://github.com/opencontainers/image-spec) 制定镜像格式、操作等
filesystem bundle(文件系统束): 定义了一种将容器编码为文件系统束的格式，即以某种方式组织的一组文件，并包含所有符合要求的运行时对其执行所有标准操作的必要数据和元数据，即config.json 与 根文件系统。
而后，Docker、Google等开源了用于运行容器的工具和库 runc，作为 OCI 的一种实现参考。在此之后，各种运行时工具和库也慢慢出现，例如 rkt、containerd、cri-o 等，然而这些工具所拥有的功能却不尽相同，有的只有运行容器(runc、lxc)，而有的除此之外也可以对镜像进行管理(containerd、cri-o)。目前较为流行的说法是将容器运行时分成了 low-level 和 high-level 两类。
low-level: 指的是仅关注运行容器的容器运行时，调用操作系统，使用 namespace 和 cgroup 实现资源隔离和限制。high-level: 指包含了更多上层功能，例如 grpc调用，镜像存储管理等。
————————————————
版权声明：本文为CSDN博主「老段工作室」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lduan_001/article/details/125301335
