containerd的部署安装过程

admin

containerd的部署安装过程


1 X% e- \  `- C# f6 P5 ?; o& d- p早在2016年3月，Docker 1.11的Docker Engine里就包含了containerd，而现在则是把containerd从Docker Engine里彻底剥离出来，作为一个独立的开源项目独立发展，目标是提供一个更加开放、稳定的容器运行基础设施。和原先包含在Docker Engine里containerd相比，独立的containerd将具有更多的功能，可以涵盖整个容器运行时管理的所有需求。
+ y. r8 g& E3 R/ Q+ bcontainerd并不是直接面向最终用户的，而是主要用于集成到更上层的系统里，比如Swarm, Kubernetes, Mesos等容器编排系统。
containerd以Daemon的形式运行在系统上，通过暴露底层的gRPC API，上层系统可以通过这些API管理机器上的容器。
6 a0 [: D& u- {3 t. l. z6 H每个containerd只负责一台机器，Pull镜像，对容器的操作（启动、停止等），网络，存储都是由containerd完成。具体运行容器由runC负责，实际上只要是符合OCI规范的容器都可以支持。
2 O# x% }; k, J/ T对于容器编排服务来说，运行时只需要使用containerd+runC，更加轻量，容易管理。
" \- _2 _0 _2 [% V! i* C- d+ p0 @9 g2 y独立之后containerd的特性演进可以和Docker Engine分开，专注容器运行时管理，可以更稳定。



$ c( ]+ }& j+ I, P) ~
- Containerd 采用标准的 C/S 架构
  `9 }9 A* S! [7 a  - 服务端通过 GRPC 协议提供稳定的 API
! z$ ?4 g) d7 Y0 O4 s9 Q8 H: P* H  - 客户端通过调用服务端的 API 进行高级的操作
5 E( }6 c4 W2 [4 X) C8 v
- 为了实现解耦，Containerd 将不同的职责划分给不同的组件，每个组件就相当于一个子系统（subsystem）。连接不同子系统的组件被称为模块。
# {& U" z+ M, S2 I' T* M

- Containerd 两大子系统为：

( i. O; y" `! q) @- ?: }% ~  - Bundle : 在 Containerd 中，Bundle 包含了配置、元数据和根文件系统数据，你可以理解为容器的文件系统。而 Bundle 子系统允许用户从镜像中提取和打包 Bundles。
  - Runtime : Runtime 子系统用来执行 Bundles，比如创建容器。

" ~" ?7 ]2 ~3 [# a, b* ^( z$ k  其中，每一个子系统的行为都由一个或多个模块协作完成（架构图中的 Core 部分）。每一种类型的模块都以插件的形式集成到 Containerd 中，而且插件之间是相互依赖的。

: W+ m# z  O0 O9 e. C+ I; q8 F( W  例如，上图中的每一个长虚线的方框都表示一种类型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又会依赖 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一个小方框都表示一个细分的插件，例如 Metadata Plugin 依赖 Containers Plugin、Content Plugin 等。
: j5 j' T8 U/ Z& O- A2 \! [
# z3 I& K; N7 a+ V0 P# f6 U - Content Plugin** : 提供对镜像中可寻址内容的访问，所有不可变的内容都被存储在这里。
; c- \2 [3 q5 k1 k! @- Snapshot Plugin** : 用来管理容器镜像的文件系统快照。镜像中的每一个 layer 都会被解压成文件系统快照，类似于 Docker 中的 `graphdriver`。
- Metrics** : 暴露各个组件的监控指标。
: `2 W9 Q) I/ h2 g( u

containerd的安装

- S+ t- @9 {* w/ s4 r0 V- v


9 I4 D" {" G- e, V2 Y( o5 t: b
+ M, d' c& N' h, o$ o