本篇内容主要讲解“Containerd的特性有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Containerd的特性有哪些”吧!
Containerd概述
“早在16年3月，Docker 1.11的Docker Engine里就包含了containerd，而现在则是把containerd从Docker Engine里彻底剥离出来，作为一个独立的开源项目独立发展，目标是提供一个更加开放、稳定的容器运行基础设施。和原先包含在Docker Engine里containerd相比，独立的containerd将具有更多的功能，可以涵盖整个容器运行时管理的所有需求。
containerd并不是直接面向最终用户的，而是主要用于集成到更上层的系统里，比如Swarm, Kubernetes, Mesos等容器编排系统。containerd以Daemon的形式运行在系统上，通过unix domain docket暴露很低层的gRPC API，上层系统可以通过这些API管理机器上的容器。每个containerd只负责一台机器，Pull镜像，对容器的操作（启动、停止等），网络，存储都是由containerd完成。具体运行容器由runC负责，实际上只要是符合OCI规范的容器都可以支持。
对于容器编排服务来说，运行时只需要使用containerd+runC，更加轻量，容易管理。而独立之后containerd的特性演进可以和Docker Engine分开，专注容器运行时管理，可以更稳定。在向后兼容上也可以做的更好，containerd第一个正式版本1.0 Release之后将提供一年的支持，包括安全更新和Bugfix，而每次升级也会向后兼容一个小版本。”
Containerd特性
职能单一
通常一个容器运行时需要包括哪些功能特性呢？
这里是containerd的架构图。中间这一层里包含了三个子系统，从这里可以看出containerd支持哪些能力
可以看出containerd非常的干净，提供的都是运行时真正需要的功能。
Cotainerd 只负责容器运行时 和 基本的镜像管理，和一些普遍需要的支持。
* 容器管理
* 镜像管理
* 存储卷管理
* 性能采集
* 日志管理
* 网络
特性和路线图
* 支持OCI镜像
* 支持OCI运行时（runC）
* 支持镜像的pull/push操作
* 容器运行时和生命周期管理
* 网络原语：创建/修改/删除接口
* 让容器加入已有的Network Namespace
* 使用“内容可寻址”存储支持全局镜像多租户共享
Namespace支持
由于需要兼容上层多个编排系统，docker 和 k8s 在一个node上可能存在多个containerd。在不同的命名空间，可以有相同名字的容器。当下载不同namespace的镜像时，可以拿其他namespace的镜像做软链，以节省存储空间，无需重复下载。
Plugin模式
好处：功能易扩展。当需要对接上层编排系统时，可以通过插件的方式进行对接。 cri-containerd 变成一个插件，可以让k8s直接对接containerd的功能。
两种方式集成：原生代码集成 和 动态库的方式。 原生代码集成，顾名思义，就是代码在一个repo里构建成一个二进制文件。 所谓动态库的方式，就是把.so文件加入规定的目录下，在不重新编译containerd二进制的情况下，加载某个插件。
Containerd的CRI实现
项目： https://github.com/containerd/cri
原名cri-containerd:目前 cri-conainerd 已经变成containerd的一个插件。
支持K8s CRI规范的所有特性
提供了使用ansible和kubeadm工具部署k8s集群的方法。
Containerd的CRI实现
-- 插件化前
缺点：实际上通过containerd client调用 containerd ，多了一层grpc的调用，性能上有损耗。
-- 插件化后
功能上没有变化，性能较大提升。
Containerd & CRI 现状 -- Containerd vs docker
优点：
dockershim的代码是集成在 kubelet内部的，dockershim的作用是把docker的接口用CRI标准封装起来。
docker 17.11版本开始使用Containerd v1.0
cri-conainerd 已经变成containerd的一个插件。
缺点：
性能对比（docker vs containerd）
图上半部是docker的数据, 图下半部是containerd 的数据。
第一列，对比Pod创建时延 ，使用k8s测试工具density 创建 50%，90% ，99% 的pod 花费的时间。
第二列，单位时间内能创建多少pod。
上图测试创建105个 pod，对机器资源的消耗。
分析：一个容器对应一个dockershim，在docker中dockershim占用的内存与 containerd占用内存对比，更小。
未来规划
进一步优化 * cri-containerd插件化后再瘦身 * containerd-shim耗费内存比较多 换一种语言实现？
重要事件
Plan 2018
Containerd架构图
理解这些组件模块以及之间的关系对修改和扩展系统十分关键。
整个架构的目标是为了协调bundles的创建和执行。bundles是指被Runtime使用的,包括配置、元数据、rootfs数据。bundle在文件系统上代表运行时容器，简化为一个目录。
Code layout并没有反映实际的架构。
Subsystems: 外部用户通过GRPC API暴露的服务来进行交互。
每个子系统有一个以上的controller 组件、实现了子系统的行为，并通过服务的方式暴露给外部访问。
Modules
除了子系统之外，还有一些组件可能跨子系统实现。
Executor: 实现了实际容器运行时。
Supervisor: 监控和报告容器状态。
Metadata: 在graph db中存储元数据。保存与镜像和bundles相关的所有文件。保存在数据库中的数据有schema,包含与模块间协作入口。还包括回收磁盘空间的垃圾回收hook。
Content: 提供内容可寻址的存储。所有不可改变的内容通过hash key保存在这里。
Snapshot: 管理文件系统上容器镜像的快照。类比于Docker中的 graphdriver
Events: 支持收集和消费事件，提供一致地以事件驱动的行为和审计。事件可以以多种模型进行重放。
Metrics: 每个组件会导出多个metrics，通过metrics API访问。
Client-side Subsystems
创建bundle的data-flow
到此，相信大家对“Containerd的特性有哪些”有了更深的了解，不妨来实际操作一番吧！这里是天达云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！