共计 3317 个字符，预计需要花费 9 分钟才能阅读完成。
本篇内容主要讲解“Containerd 的特性有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“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 支持哪些能力
Distribution: 和 Docker Registry 打交道，拉取镜像
Bundle: 管理本地磁盘上面镜像的子系统。
Runtime：创建容器、管理容器的子系统。
可以看出 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
优点：
Stability 职责单一，更容易稳定
Compatibility 跟随 kubernetes 的需求
Neutral Foundation 中立，CNCF 项目之一
Performance
dockershim 的代码是集成在 kubelet 内部的，dockershim 的作用是把 docker 的接口用 CRI 标准封装起来。
docker 17.11 版本开始使用 Containerd v1.0
cri-conainerd 已经变成 containerd 的一个插件。
缺点：
User Adaption 调试工具手段相比 docker 还有差距
Maturity 需要时间成熟
性能对比（docker vs containerd）
图上半部是 docker 的数据, 图下半部是 containerd 的数据。
第一列，对比 Pod 创建时延，使用 k8s 测试工具 density 创建 50%，90%，99% 的 pod 花费的时间。
第二列，单位时间内能创建多少 pod。
上图测试创建 105 个 pod，对机器资源的消耗。
分析：一个容器对应一个 dockershim，在 docker 中 dockershim 占用的内存与 containerd 占用内存对比，更小。
未来规划
进一步优化 * cri-containerd 插件化后再瘦身 * containerd-shim 耗费内存比较多 换一种语言实现？
重要事件
Containerd 原生支持 CRI
项目已经合并，cri-containerd 作为 Containerd 的一个插件，改名 cri，不再独立存在。
版本：伴随 kubernetes 1.10，发布 cri-containerd 1.0.0-rc.0 , Containerd 1.1
Plan 2018
secure Pod (kata container etc)
Windows container
性能优化部分 …
Containerd 架构图
理解这些组件模块以及之间的关系对修改和扩展系统十分关键。
整个架构的目标是为了协调 bundles 的创建和执行。bundles 是指被 Runtime 使用的, 包括配置、元数据、rootfs 数据。bundle 在文件系统上代表运行时容器，简化为一个目录。
Code layout 并没有反映实际的架构。
Subsystems: 外部用户通过 GRPC API 暴露的服务来进行交互。
Bundle: bundle 服务允许用户从硬盘镜像中解压和打包 bundles.
Runtime: runtime 服务支持 bundles 的执行，包括创建容器运行时
每个子系统有一个以上的 controller 组件、实现了子系统的行为，并通过服务的方式暴露给外部访问。
Modules
除了子系统之外，还有一些组件可能跨子系统实现。
Executor: 实现了实际容器运行时。
Supervisor: 监控和报告容器状态。
Metadata: 在 graph db 中存储元数据。保存与镜像和 bundles 相关的所有文件。保存在数据库中的数据有 schema, 包含与模块间协作入口。还包括回收磁盘空间的垃圾回收 hook。
Content: 提供内容可寻址的存储。所有不可改变的内容通过 hash key 保存在这里。
Snapshot: 管理文件系统上容器镜像的快照。类比于 Docker 中的 graphdriver
Events: 支持收集和消费事件，提供一致地以事件驱动的行为和审计。事件可以以多种模型进行重放。
Metrics: 每个组件会导出多个 metrics，通过 metrics API 访问。
Client-side Subsystems
Distribution: 提供上传和下载镜像的功能
创建 bundle 的 data-flow
到此，相信大家对“Containerd 的特性有哪些”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
