导航：首页 > 服务器 >

Containerd的特性有哪些

发表于：2024-11-23 作者：千家信息网编辑

千家信息网最后更新 2024年11月23日，本篇内容主要讲解"Containerd的特性有哪些"，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习"Containerd的特性有哪些"吧!Containerd

千家信息网最后更新 2024年11月23日Containerd的特性有哪些

本篇内容主要讲解"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支持哪些能力

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访问。