containerd的部署安装过程

admin

containerd的部署安装过程


早在2016年3月，Docker 1.11的Docker Engine里就包含了containerd，而现在则是把containerd从Docker Engine里彻底剥离出来，作为一个独立的开源项目独立发展，目标是提供一个更加开放、稳定的容器运行基础设施。和原先包含在Docker Engine里containerd相比，独立的containerd将具有更多的功能，可以涵盖整个容器运行时管理的所有需求。
$ X$ K0 ~4 E' j4 mcontainerd并不是直接面向最终用户的，而是主要用于集成到更上层的系统里，比如Swarm, Kubernetes, Mesos等容器编排系统。
containerd以Daemon的形式运行在系统上，通过暴露底层的gRPC API，上层系统可以通过这些API管理机器上的容器。
9 y% X3 `# Q* r, u& {每个containerd只负责一台机器，Pull镜像，对容器的操作（启动、停止等），网络，存储都是由containerd完成。具体运行容器由runC负责，实际上只要是符合OCI规范的容器都可以支持。
对于容器编排服务来说，运行时只需要使用containerd+runC，更加轻量，容易管理。
独立之后containerd的特性演进可以和Docker Engine分开，专注容器运行时管理，可以更稳定。




- Containerd 采用标准的 C/S 架构
  - 服务端通过 GRPC 协议提供稳定的 API
0 v( z6 d3 D: b. S' h6 a' }  - 客户端通过调用服务端的 API 进行高级的操作

- 为了实现解耦，Containerd 将不同的职责划分给不同的组件，每个组件就相当于一个子系统（subsystem）。连接不同子系统的组件被称为模块。


- Containerd 两大子系统为：
8 R5 T" w) F9 }) b5 z. X
  - Bundle : 在 Containerd 中，Bundle 包含了配置、元数据和根文件系统数据，你可以理解为容器的文件系统。而 Bundle 子系统允许用户从镜像中提取和打包 Bundles。
) ?8 K% M! b! o  x  - Runtime : Runtime 子系统用来执行 Bundles，比如创建容器。

" `$ g  X8 m  ]4 L( v+ N! c" m  其中，每一个子系统的行为都由一个或多个模块协作完成（架构图中的 Core 部分）。每一种类型的模块都以插件的形式集成到 Containerd 中，而且插件之间是相互依赖的。
+ B2 |% \/ ?$ A, _+ w2 Z+ X
! B* X( m4 y. @& g  例如，上图中的每一个长虚线的方框都表示一种类型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又会依赖 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一个小方框都表示一个细分的插件，例如 Metadata Plugin 依赖 Containers Plugin、Content Plugin 等。
9 `, l, [# O% ?, R3 U$ V
- Content Plugin** : 提供对镜像中可寻址内容的访问，所有不可变的内容都被存储在这里。
1 _" m2 A& S3 p- Snapshot Plugin** : 用来管理容器镜像的文件系统快照。镜像中的每一个 layer 都会被解压成文件系统快照，类似于 Docker 中的 `graphdriver`。
1 I( }! r5 s/ a% m- Metrics** : 暴露各个组件的监控指标。

8 T; k* Q7 P% F! y$ h6 J
containerd的安装
  T3 F( \" J7 a! C& F$ ]



+ x3 B; m$ \  p
  o  X/ \! Y/ _  K* D. i0 S