转载https://segmentfault.com/a/1190000023618092
Containerd 模块从 docker 中分离出来后，功能变得更加丰富，依赖者变得更加广泛，不仅仅是docker在使用，可以看到在云原生应用中涉及到容器技术时基本都在依赖 containerd。
图片来源 https://www.slideshare.net/Docker/leveraging-the-power-of-containerd-events-evan-hazlett
一、Containerd 作用
containerd 的下层是runc，containerd 主要在为runc提供 oci（Open Container Initiative）runtime spec，oci 定义了两个标准，一个是关于镜像的，一个是关于容器运行时，容器运行时标准简单来说就是一个config.json文件和一个rootfs，关于oci的详细信息可以看官方github仓库或者文末参考。containerd就是oci一个标准实现。
containerd 在docker架构中的位置
二、Container架构分析
containerd本身就提供了ctr命令行工具，grpc接口用来管理容器的生命周期，containerd在镜像管理上进行了创新，不再像docker使用graphdriver来管理镜像，而是使用快照的方式，在容器的世界中存在两种镜像，一种是overlays filesystems（AUFS、OverlayFS）， 一种是snapshotting filesystems（devicemapper、btrfs、ZFS）
containerd中的数据流
containerd的工作主要分为以下几步
1）拉取镜像，存储到 metadata（metadata是个bolt键值型数据库） 和content中，content中的存储是带标签的存储，metadata中的存储是不带标签，content主要用来进行独立执行或者测试使用，查询的还是metadata中的数据。metadata中的content中的内容主要是 manifests 的index、manifests、config.json、image layer。在拉取完之后同时创建了一个镜像到metadata的image内容空间，还有几本snapshot的构建。
metadata 的schema
// keys.
// ├──version : <varint> - Latest version, see migrations
// └──v1 - Schema version bucket
// ╘══*namespace*
// ├──labels
// │ ╘══*key* : <string> - Label value
// ├──image
// │ ╘══*image name*
// │ ├──createdat : <binary time> - Created at
// │ ├──updatedat : <binary time> - Updated at
// │ ├──target
// │ │ ├──digest : <digest> - Descriptor digest
// │ │ ├──mediatype : <string> - Descriptor media type
// │ │ └──size : <varint> - Descriptor size
// │ └──labels
// │ ╘══*key* : <string> - Label value
// ├──containers
// │ ╘══*container id*
// │ ├──createdat : <binary time> - Created at
// │ ├──updatedat : <binary time> - Updated at
// │ ├──spec : <binary> - Proto marshaled spec
// │ ├──image : <string> - Image name
// │ ├──snapshotter : <string> - Snapshotter name
// │ ├──snapshotKey : <string> - Snapshot key
// │ ├──runtime
// │ │ ├──name : <string> - Runtime name
// │ │ ├──extensions
// │ │ │ ╘══*name* : <binary> - Proto marshaled extension
// │ │ └──options : <binary> - Proto marshaled options
// │ └──labels
// │ ╘══*key* : <string> - Label value
// ├──snapshots
// │ ╘══*snapshotter*
// │ ╘══*snapshot key*
// │ ├──name : <string> - Snapshot name in backend
// │ ├──createdat : <binary time> - Created at
// │ ├──updatedat : <binary time> - Updated at
// │ ├──parent : <string> - Parent snapshot name
// │ ├──children
// │ │ ╘══*snapshot key* : <nil> - Child snapshot reference
// │ └──labels
// │ ╘══*key* : <string> - Label value
// ├──content
// │ ├──blob
// │ │ ╘══*blob digest*
// │ │ ├──createdat : <binary time> - Created at
// │ │ ├──updatedat : <binary time> - Updated at
// │ │ ├──size : <varint> - Blob size
// │ │ └──labels
// │ │ ╘══*key* : <string> - Label value
// │ └──ingests
// │ ╘══*ingest reference*
// │ ├──ref : <string> - Ingest reference in backend
// │ ├──expireat : <binary time> - Time to expire ingest
// │ └──expected : <digest> - Expected commit digest
// └──leases
// ╘══*lease id*
// ├──createdat : <binary time> - Created at
// ├──labels
// │ ╘══*key* : <string> - Label value
// ├──snapshots
// │ ╘══*snapshotter*
// │ ╘══*snapshot key* : <nil> - Snapshot reference
// ├──content
// │ ╘══*blob digest* : <nil> - Content blob reference
// └──ingests
// ╘══*ingest reference* : <nil> - Content ingest reference
在contained中是存在namespace的概念的
2）当运行容器时，利用metadata中的content、snapshot、image信息进行active snapshot（可以理解为docker中的容器层）的构建，构建bundle，调用runc启动容器。
containerd中的插件机制
containerd对外接口有ctr命令行和有grpc，ctr也是通过grpc协议来与containerd server通信，grpc server不是像我们平时使用的那样将各个service导入到某个入口包中进行注册，containerd使用了插件注册机制，将task、content、snapshot、namespace、event、containers等服务以插件的方式注册然后提供服务.
这是containerd的内部插件
[root@master containerd]# ctr plugin ls
TYPE ID PLATFORMS STATUS
io.containerd.content.v1 content - ok
io.containerd.snapshotter.v1 aufs linux/amd64 error
io.containerd.snapshotter.v1 btrfs linux/amd64 error
io.containerd.snapshotter.v1 devmapper linux/amd64 error
io.containerd.snapshotter.v1 native linux/amd64 ok
io.containerd.snapshotter.v1 overlayfs linux/amd64 ok
io.containerd.snapshotter.v1 zfs linux/amd64 error
io.containerd.metadata.v1 bolt - ok
io.containerd.differ.v1 walking linux/amd64 ok
io.containerd.gc.v1 scheduler - ok
io.containerd.service.v1 introspection-service - ok
io.containerd.service.v1 containers-service - ok
io.containerd.service.v1 content-service - ok
io.containerd.service.v1 diff-service - ok
io.containerd.service.v1 images-service - ok
io.containerd.service.v1 leases-service - ok
io.containerd.service.v1 namespaces-service - ok
io.containerd.service.v1 snapshots-service - ok
io.containerd.runtime.v1 linux linux/amd64 ok
io.containerd.runtime.v2 task linux/amd64 ok
io.containerd.monitor.v1 cgroups linux/amd64 ok
io.containerd.service.v1 tasks-service - ok
io.containerd.internal.v1 restart - ok
io.containerd.grpc.v1 containers - ok
io.containerd.grpc.v1 content - ok
io.containerd.grpc.v1 diff - ok
io.containerd.grpc.v1 events - ok
io.containerd.grpc.v1 healthcheck - ok
io.containerd.grpc.v1 images - ok
io.containerd.grpc.v1 leases - ok
io.containerd.grpc.v1 namespaces - ok
io.containerd.internal.v1 opt - ok
io.containerd.grpc.v1 snapshots - ok
io.containerd.grpc.v1 tasks - ok
io.containerd.grpc.v1 version - ok
扩展插件的两种方式
1、通过二进制方式在containerd的命令行传入
2、通过配置containerd的配置文件来设置proxy pligin
runtime在containerd中有v1和v2两个版本，可以在执行ctr run命令中通过命令行传入
ctr run --runtime io.containerd.runc.v1自定义快照插件，/etc/containerd/config.toml 是containerd的默认配置文件，
[proxy_plugins]
[proxy_plugins.customsnapshot]
type = "snapshot"
address = "/var/run/mysnapshotter.sock"proxy plugin会在containerd启动时随着内部插件一起启动。
containerd中的event
containerd中实现了event的发订阅功能，在对每个资源操作后都会推送相关事件给订阅者，利用这个功能可以事件对containerd的监控和实现一些hook功能。
containerd中的namespace
通过上文中metadata中的scame可以看到在containerd中是存在命名空间的概念以及实现，类似opensatck中多租户一样，可以将不同的业务和应用进行隔离，比如kubernetes中使用containerd和docker在使用containerd时就使用了不同的namespace。
三、总结
containerd代码从docker中分离出来后，功能变得丰富强大以至于基本所有云计算中容器相关的底层都在利用containerd，在镜像管理上作者实现了微创新，docker中使用的是graph driver管理镜像，containerd中使用的snapshot，为什么会使用snapshot模型，因为snapshot在增量快照上是有严格的父子关系，这种关系和镜像的分层模型很一致，在容器世界有两种文件系统一种是块级别的一种是文件系统级别，container的将块级别的进行分层化，将文件系统级别的进行快照化。
登录容器验证 [root@containerd busybox]# ctr tasks list TASK PID STATUS busybox 15301 RUNNING [root@containerd busybox]# ctr tasks exec -t --exec-id 15301 busybox /bin/sh / # hostname containerd / # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 4.stop容器 [root@containerd busybox]# ctr tasks kill --signal 9 busybox [root@containerd busybox]# ctr tasks list TASK PID STATUS busybox 15301 STOPPED 5.删除容器 [root@containerd busybox]# ctr container delete busybox [root@containerd busybox]# ctr container list CONTAINER IMAGE RUNTIME 。