乐趣区

关于云计算:Docker-向全面集成-containerd-又迈进一步

jiezi

Docker 在刚刚公布的 Docker Desktop 4.12.0 中，退出了试验个性：进一步集成 containerd，应用 containerd 来治理和存储镜像。

为什么说是“进一步集成”？这就要翻翻 Docker 和 containerd 的历史了。

containerd 的诞生

containerd 最早呈现在 Docker Engine 中，起初为了将 Docker Engine 做得更加轻量、疾速和强壮，在 2016 年 Docker 将 containerd 从 daemon（dockerd）中独立进去，并实现了与 daemon 的集成。独立进去的 containerd 全面反对 OCI（Open Container Initiative）资源的启动和生命周期的治理，也因而 containerd 能够反对 runc（前身是 Docker 中的 libcontainer，起初捐献给 LF）以外的其余 OCI 实现。2017 年 Docker 将 containerd 募捐给 CNCF；2019 年 2 月，containerd 毕业。

containerd 独立进去之后，发送到 Docker Engine 的申请：

  1. Docker daemon 实现镜像治理的操作（拉取、更新镜像）
  2. daemon 会为创立容器进行筹备工作（创立 OCI bundles）：镜像的信息和运行时的信息。
  3. daemon 调用 containerd 的 API。
  4. 收到申请的 containerd 不会间接去操作容器（不间接作为容器的父过程，避免 containerd 挂掉影响容器），而是先创立一个 container-shim 过程。
  5. container-shim 调用 runc cli 来运行容器，并启动 Unix domain socket 裸露 API 提供给 containerd 进行容器的治理。

随着 containerd 的一直演进，除了容器创立和容器申明周期治理以外，从 1.1 开始 containerd 退出了 CRI（Container Runtime Interface）的反对。

CRI

在《源码解析 kubectl port-forward 工作原理》中层提到 kubelet 会调用 rumtime service 的 gRPC 接口，除了用于 portforward 流的 stream server 以外，其实还有实现 CRI 接口 RuntimeService 和 ImageService 的 RuntimeServiceServer 和 ImageServiceServer。

RuntimeServiceServer 用于接管并解决容器及其生命周期相干的操作，而 ImageServiceServer 则是用来解决镜像相干的操作。containerd 提供了镜像拉取、删除、查看、存储等性能。

既然 containerd 能够进行镜像的治理，而且 Docker 曾经在应用，Docker 也没有必要本人持续保护一套雷同的性能。

切换到 containerd 的镜像治理

在 Docker Desktop 的设置中启动 containerd 治理镜像后，运行 docker info 会发现存储的驱动从原来的 overlay2 变成了 containerd 的 stargz。

切换前：

切换后：

既然应用了 containerd 的 snapshotters 来治理存储（挂在容器的根文件系统），就能够反对多种 snapshotters，比方 stargz 的提早拉取。

此外，得益于 containerd 原生反对多平台镜像的存储，还是因为 snapshotters 的起因，能够应用 docker 来构建多平台的镜像了。

# 切换前
docker buildx build -t demo --no-cache --platform linux/amd64,linux/arm64 .
[+] Building 0.0s (0/0)
error: multiple platforms feature is currently not supported for docker driver. Please switch to a different driver (eg. "docker buildx create --use")

切换后：

图片来自 docker 官网博客

总结

应用 containerd 作为 Docker 的镜像治理目前还处于实验性阶段，必可防止会存在问题，应用时请审慎看待。

随着 Docker Swarm 在容器编排之战中的落败，Kubernetes 的话语权也越来越强。在 Kubernetes 1.24.0 中移除了 docker shim 代码，看起来更像是 containerd 取代了 Docker 已经的位置，而 Docker 也越来越名声不显。从趋势来看，Docker 将来将会齐全集成 containerd。

参考

  • Extending Docker’s Integration with containerd
  • Docker containerd integration

  • Learning Containers From The Bottom Up

    关注 ” 云原生指北 ” 微信公众号
    （转载本站文章请注明作者和出处盛世浮生，请勿用于任何商业用途）

退出移动版