containerd的部署安装过程

admin

containerd的部署安装过程
! D: |7 @5 u3 `: w" {
  [1 m: Z- w! O& j8 R+ x8 R# z& t
早在2016年3月，Docker 1.11的Docker Engine里就包含了containerd，而现在则是把containerd从Docker Engine里彻底剥离出来，作为一个独立的开源项目独立发展，目标是提供一个更加开放、稳定的容器运行基础设施。和原先包含在Docker Engine里containerd相比，独立的containerd将具有更多的功能，可以涵盖整个容器运行时管理的所有需求。
/ A1 r# Z5 F3 hcontainerd并不是直接面向最终用户的，而是主要用于集成到更上层的系统里，比如Swarm, Kubernetes, Mesos等容器编排系统。
containerd以Daemon的形式运行在系统上，通过暴露底层的gRPC API，上层系统可以通过这些API管理机器上的容器。
每个containerd只负责一台机器，Pull镜像，对容器的操作（启动、停止等），网络，存储都是由containerd完成。具体运行容器由runC负责，实际上只要是符合OCI规范的容器都可以支持。
对于容器编排服务来说，运行时只需要使用containerd+runC，更加轻量，容易管理。
, b- w" B/ K) u% w独立之后containerd的特性演进可以和Docker Engine分开，专注容器运行时管理，可以更稳定。
, y5 V; v4 j$ S! L# _

! r( N* }  K3 ^

- Containerd 采用标准的 C/S 架构
  - 服务端通过 GRPC 协议提供稳定的 API
  - 客户端通过调用服务端的 API 进行高级的操作

# l8 }! ~9 }& I4 u! o7 j6 {( X% f- 为了实现解耦，Containerd 将不同的职责划分给不同的组件，每个组件就相当于一个子系统（subsystem）。连接不同子系统的组件被称为模块。


- Containerd 两大子系统为：

  - Bundle : 在 Containerd 中，Bundle 包含了配置、元数据和根文件系统数据，你可以理解为容器的文件系统。而 Bundle 子系统允许用户从镜像中提取和打包 Bundles。
  - Runtime : Runtime 子系统用来执行 Bundles，比如创建容器。
$ ?# W: ?. o. Q- E+ F% s
  其中，每一个子系统的行为都由一个或多个模块协作完成（架构图中的 Core 部分）。每一种类型的模块都以插件的形式集成到 Containerd 中，而且插件之间是相互依赖的。
- Z  S; L2 U4 Q8 [* ^
" Y# J* p) O5 \5 [( U( A/ f  例如，上图中的每一个长虚线的方框都表示一种类型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又会依赖 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一个小方框都表示一个细分的插件，例如 Metadata Plugin 依赖 Containers Plugin、Content Plugin 等。
* ^, F( _* v- n5 j7 \$ K
7 u7 P' A9 f- O! o$ } - Content Plugin** : 提供对镜像中可寻址内容的访问，所有不可变的内容都被存储在这里。
) {2 v- B( }. a7 C$ O- Snapshot Plugin** : 用来管理容器镜像的文件系统快照。镜像中的每一个 layer 都会被解压成文件系统快照，类似于 Docker 中的 `graphdriver`。
: Y4 x. R" q+ N' _; E5 d0 a$ }- Metrics** : 暴露各个组件的监控指标。


: g& [: C! L0 G# Y, B4 \6 Wcontainerd的安装

+ z8 i( I/ v& c6 q, g( [! f) N
! |8 m. e7 V( C
& i1 u3 n9 }, ]" w6 v
3 }# Z' L3 M; v3 D! C' U0 f
  g; B4 V" D) P0 T' i