containerd系列——什么是containerd？

PinkGranite

已于 2022-02-09 11:31:26 修改

阅读量1.9k

点赞数 2

分类专栏：容器技术文章标签：容器 containerd

于 2022-02-09 11:30:41 首次发布

本文链接：https://blog.csdn.net/weixin_43860783/article/details/122835664

版权

5 篇文章 0 订阅

订阅专栏

1. 什么是containerd？

containerd

containerd是一个“container runtime”：什么是container runtime？runtime指的是容器运行时，也就是说containerd给予了容器运行时支持。但需要注意的是：containerd并不是一个真正意义上的运行时，它在某种程度上具备运行时的能力（主要归功于它的下游runtime支持）。从上图中可以看出，containerd向上承接了更高层次的容器管理的功能（例如Docker，K8S），而在其下层则配置有更低层次的runtime（例如runc等等——关于runc可以参考系列文章）。
containerd是一个资源管理者（resource manager）：containerd可以对容器的生命周期进行管理，涉及容器的创建、删除等等；可以对镜像进行管理；可以对文件系统快照进行管理；可以对容器的元信息以及依赖信息进行管理等等。
containerd是一个紧耦合的项目（tightly scoped）：containerd本身体量很想，很多功能建立在扩展插件系统之上。

原本containerd只是Docker运行的一个伴随应用，作为连接docker和底层runc的中间件
随着不断发展，containerd逐渐从一个容器的supervisor（也就是只具备基本的容器检测与执行功能）蜕变为具有完整功能的container runtime（全流程）
虽然containerd的诞生与docker密不可分，但是containerd设计了全新的容器与镜像管理接口
CRI本身作为独立与容器进程的插件现在也已经被集成到了containerd中，使containerd成为符合CRI标准的容器运行时

适用范围

K8S使用者：K8S目前是工业应用中最广泛被使用的容器管理项目，而K8S对containerd具有长足良好的支持，containerd在K8S中的使用也是最为成熟的。
对于开发者而言：如果你是一名开发者，使用docker kit进行镜像开发，那么实时上你已经使用了containerd，docker本身也对containerd进行了支持
边缘开发：如果你是一名边缘应用的开发者，containerd由于体量小，效率高等优势被广泛地使用在边缘虚拟化场景中，例如K3S（可以理解为K8S的缩小版，适用于边缘场景，请看考这里）
对于服务提供者：containerd能够很好的支持外界服务访问，参考faasd，IBM Cloud Function等
程序运行稳定性：containerd的daemon即使奔溃了也不会影响正在运行的容器以及程序
资源的有效利用：containerd daemon所需要的内存空间以及资源非常小（所以也适用于边缘场景）
文件系统资源管理：contianerd提供了垃圾回收机制，对于冗余以及不需要使用的文件系统资源，containerd可以自动回收，减少文件系统资源的无效占用

整体结构

总体来看contianerd由Client、API、Core、Backend（也可以认为API、Core、Backend是一个整体，为containerd core）、Shim共五个部分组成，构建在系统以及镜像仓库基础之上
控制信息与数据从Client向右流动，知道容器运行时shim

Client是用户使用containerd过程中的直接交互对象，对于containerd的初学者而言，Client是最应该首先入门的模块，它提供了丰富的功能以及灵活性可供探索新特性以及扩展
Container Management子模块是Client模块中与container runtimes进行交互的子模块：该子模块可以提供OCI specification创建，snapshot创建等功能
Image Distribution是Client中进行镜像管理的子模块，提供了镜像的导入，导出，拉取，推送等功能
containerd项目尽量保持了core部分的简洁精炼，因此Client部分也相应地承担了更多的功能与需求
Client模块可自配置——这意味着Client非常的灵活

该部分定义了containerd中使用的数据结构类型以及API接口
为什么containerd要提供这么多的接口（是否containerd过于依赖于接口的使用）？——实际上设置这些接口以及数据类型是为了containerd core成为一个数据信息转发的中间站，基于数据结构类型的定义，core能够对流经该部分的数据进行追踪以供更好的使用
数据从core部分流经并被core追踪以及记录，这就意味着core部分（以及其中的plugins）不需要存储数据——这也方便了core中的GC模块工作，减少了数据不一致等挑战带来的风险
对Plugin的支持是containerd core的一个重要特性，这使得containerd具有良好的可扩展性以及灵活性
plugin可以像core发送信息，core同样也可以向plugin发送信息，backend本身也是可插拔的（plugable）——例如core中的Snapshots就是以plugin的方式实现的
每一个插件都可以进行自我配置，而这些配置也会被包含导containerd的主配置中
如果我们有一个服务应用，那么它也可以通过grpc的方式与core进行交互——例如core中的CRI模块本身就是作为一个服务存在的，通过grpc的方式与core进行交互
默认情况下Client会通过proxy服务机遇grpc与core进行交互

containerd core中的Runtime子模块可以启动一个新的runtime shim，它可以传递oci spec以及其他控制信息给Shim
Shims是真正拥有container processes控制权的角色，Shim作为container的直接父进程存在（这里不知道对不对）
containerd core通过一个轻量级的grpc protocal ttrpc与Shim进行交互；如果重启containerd，那么containerd需要重新与shim建立连接以传递指令与数据
目前已经有了非常多种不同的Shim实现，其中最广泛使用的就是runc
runhcs是运行在windows上的Shim