前言

容器技术很早就有了,Docker 是目前最广泛的容器引擎技术, 使用 Linux Cgroup namespace 等技术分隔进程。为了更好的规范容器技术的发展,Docker、CoreOS 和容器行业中的其他领导者在 2015年6月共同发起了 Open Container initiative(OCI) 基金会。OCI 基金会领导社区进行制定了相关规范,主要包括:

  • 镜像规范(image spec)
  • 运行时规范(runtime spec)

Docker 在容器社区的贡献

在 OCI 基金成立后,Docker 将自己 libcontainer 实现移动到 runC 并捐赠给了 OCI。此时容器社区的运行时规范有了第一个参考实现。runC 是一个轻量可移植的容器运行时,实现了容器的启停、资源隔离等功能。

2016 年,Docker 开源并将 Containerd 捐赠给了 CNCF,Containerd 几乎攘括了单机运行一个容器运行时所需的一切:执行、分发、监控、网络、构建、日志等。

image.png

从上图可以看出:containerd 向上为Docker Daemon 提供了gRPC接口,使得 Docker Daemon 屏蔽下面的结构变化,确保原有接口向下兼容。向下通过 containerd-shim 结合 runC,使得引擎可以独立升级,避免之前 Docker Daemon 升级会导致所有容器不可用的问题。

dockerd(从 Docker 1.11 开始 docker Daemon 改为 dockerd) 本身实属是对容器相关操作的api的最上层封装。
containerd-shim:(垫片)containerd 每次都会启动一个新的 docker-containerd-shim 进程来创建容器,让这个进程成为容器的父进程。这样的好处,一方面可以跟 containerd 解耦(不至于一个 containerd 挂了所有容器跟着挂)另一方面当容器的 pid=1 进程退出了可以接管容器的子进程进行清理工作。他直接通过指定的三个参数:容器id,boundle目录(containerd的对应某个容器生成的目录,一般位于:/var/run/docker/libcontainerd/containerID),运行时二进制(默认为runc)来调用 runc 的 api 创建一个容器。

CRI 接口

CRI(Container Runtime Interface 容器运行时接口),kubelet 调用容器运行时的 grpc 接口。早期 kubernetes 直接通过硬编码的方式支持 docker,后面 Kubernetes 为了支持更多更精简的容器运行时,Google 就和红帽主导推出了 CRI 标准。

image.png

  • dockershim:CRI 标准推出早期影响力有限,很多容器运行时不会主动去实现 CRI 接口,于是有了一层 shim(垫片,适配层)。又因为 docker 的地位很高,所以 dockershim 直接被内置在 kubelet 中。但是 kubernetes 1.21 版本已经将其标注为废弃接口,此事件一顿引起社区对 docker 未来的担忧。但从另一个角度看,docker 将自己的核心功能整合开源了 containerd,通过 containerd 可以直接操作容器的整个生命周期。而且现在 containerd 是社区标准实现,所以 k8s 废弃 docker-api,改为直接对接 containerd 无可厚非,kubernetes 的开发者相同的一个功能点不用往2个地方都去兼容,整个调用链路也会缩短。
  • CRI-containerd:最早 containerd 还会去适配其他系统(swarm) 没有直接实现 CRI,所以实现的任务就交给 cri-containerd 这个 shim。 containerd 1.1 版本后就去掉了 CRI-Containerd 这个 shim,直接把适配逻辑作为插件的方式集成到了 containerd 主进程中。
  • CRI-O:专注于 kubernetes 运行容器的轻量级 CRI 接口实现,由 redhat 发起并开源且由社区驱动的 container-runtime,其主要目的就是能够取代 docker 作为kubernetes集群的容器运行时。他只能配合 kubernetes 使用,不能像 docker功能一样全能独立运行管理容器。

链路调用关系演进

  1. 一开始

    kubectl -CRI-> dockershim -> docker -> containerd -> containerd-shim -> runc
  2. 去除 docker

    kubectl -CRI-> cri-containerd -> containerd -> containerd-shim -> runc
  3. cri-containerd 提炼到 containerd 里面

    kubectl -CRI-> containerd -> containerd-shim -> runc

小结

  1. 我们如果要使用容器,不一定非要用 docker,因为有多种容器运行时。
  2. docker 跟其他容器运行时相比功能比较全,但是也比较重。
  3. docker 已经将自己的核心技术封装成 containerd ,并开源出去了。docker daemon 也只是调用 containerd 的一层薄薄的封装 + 镜像、存储卷的一些功能。
  4. docker 默认的容器运行时是 runc,但是只要符合 oci 的 runtimespec 规范都是可以的。启动 Docker Daemon 时增加 –add-runtime 参数来选择其他的运行时实现。
docker daemon --add-runtime "custom=/usr/local/bin/my-runc-replacement"

点赞(3) 打赏

Comment list 共有 0 条评论

暂无评论
立即
投稿
发表
评论
返回
顶部