containerd的部署安装过程

admin

containerd的部署安装过程

( \$ h6 ^% {& C& ~( u' E' B1 ^+ ]8 a
  b% D& {' z% i. c早在2016年3月，Docker 1.11的Docker Engine里就包含了containerd，而现在则是把containerd从Docker Engine里彻底剥离出来，作为一个独立的开源项目独立发展，目标是提供一个更加开放、稳定的容器运行基础设施。和原先包含在Docker Engine里containerd相比，独立的containerd将具有更多的功能，可以涵盖整个容器运行时管理的所有需求。
  z) l7 V# E" X7 j# wcontainerd并不是直接面向最终用户的，而是主要用于集成到更上层的系统里，比如Swarm, Kubernetes, Mesos等容器编排系统。
7 k# x" O% }; M' |" L5 T% u3 ycontainerd以Daemon的形式运行在系统上，通过暴露底层的gRPC API，上层系统可以通过这些API管理机器上的容器。
* r8 G8 m4 C4 z; U3 Q  S9 j每个containerd只负责一台机器，Pull镜像，对容器的操作（启动、停止等），网络，存储都是由containerd完成。具体运行容器由runC负责，实际上只要是符合OCI规范的容器都可以支持。
对于容器编排服务来说，运行时只需要使用containerd+runC，更加轻量，容易管理。
独立之后containerd的特性演进可以和Docker Engine分开，专注容器运行时管理，可以更稳定。


: Z: R3 c& y8 a4 m& j

- Containerd 采用标准的 C/S 架构
! T/ ~4 N/ ]/ {, U' h  - 服务端通过 GRPC 协议提供稳定的 API
3 B) x) s9 F9 w  - 客户端通过调用服务端的 API 进行高级的操作
9 ^. j$ f) C( R5 y
# `+ E1 I, b( |& `- 为了实现解耦，Containerd 将不同的职责划分给不同的组件，每个组件就相当于一个子系统（subsystem）。连接不同子系统的组件被称为模块。
1 e4 C+ s; ~* x' v0 }

- Containerd 两大子系统为：
/ a9 p$ Z2 V3 _  T: p/ b# R7 a# V( W3 _- F
3 i) M; h( P0 @7 s* x3 `- P  - Bundle : 在 Containerd 中，Bundle 包含了配置、元数据和根文件系统数据，你可以理解为容器的文件系统。而 Bundle 子系统允许用户从镜像中提取和打包 Bundles。
" h" w* K- U# v9 }6 ?  - Runtime : Runtime 子系统用来执行 Bundles，比如创建容器。

  其中，每一个子系统的行为都由一个或多个模块协作完成（架构图中的 Core 部分）。每一种类型的模块都以插件的形式集成到 Containerd 中，而且插件之间是相互依赖的。

3 W" }* u  X5 Y+ x* }. Q  例如，上图中的每一个长虚线的方框都表示一种类型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又会依赖 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一个小方框都表示一个细分的插件，例如 Metadata Plugin 依赖 Containers Plugin、Content Plugin 等。
+ z' j4 o* @! \7 K, m
% o) c6 C: r7 r7 j - Content Plugin** : 提供对镜像中可寻址内容的访问，所有不可变的内容都被存储在这里。
- Snapshot Plugin** : 用来管理容器镜像的文件系统快照。镜像中的每一个 layer 都会被解压成文件系统快照，类似于 Docker 中的 `graphdriver`。
4 T+ l  l6 j  d6 w: F% {- Metrics** : 暴露各个组件的监控指标。

0 U5 U$ d( D  Q, w& n0 F' X+ F
containerd的安装

$ o5 d8 I! @( w$ S) \$ M' s

  P: U6 q5 R1 l; S
% x! ]; p- R, J2 n9 r. E, d& V