容器技术之容器引擎与江湖门派

来来来，搬好小板凳我们继续开聊容器技术。读过本系列第一篇文章“容器技术之发展简史”的读者，可能已经理解了容器和云原生的关系，以及容器技术恒等式：

我们今天先聊执行引擎，后续将有一篇关于容器镜像的专题文章具体聊镜像格式和镜像加速。

从集装箱革命说起

有一本非常有名的书，叫《集装箱改变世界》，说的是看起来平淡无奇的铁箱子，如何从二十世纪起永久性的改变了这个世界，并促进了全球化和全球分工。集装箱的出现和发展是实体货物包装、运输、交付方式的一次革命。

《经济学家》杂志曾经评价说“没有集装箱，不可能有全球化”。集装箱为什么具有革命性？经济全球化的基础就是现代运输体系,而一个高度自动化、低成本和低复杂性的货物运输系统的核心就是集装箱。集装箱最大的成功在于其产品的标准化及由此建立的一整套运输体系。能够让一个载重几十吨的庞然大物实现标准化，并且以此为基础逐步实现全球范围内的船舶、港口、航线、公路、中转站、桥梁、隧道、多式联运相配套的物流系统，这的确堪称人类有史以来创造的伟大奇迹之一，而撬动这个系统的理念就是标准化和系统化。

改变世界的不仅仅是集装箱本身，还有一整套货物处理的新方法，包括港口、货船、起重机、卡车，还有发货人的自身操作方式等。容器技术对于IT领域的意义非常类似于集装箱，只是里面装载的不再是实体货物，而是虚拟世界的二进制代码和软件。

制作集装箱可以采用不同的材料与工艺流程，只需要符合相应的标准。同理，容器技术也有不同架构和实现，只要遵循相应的技术规范，就是合格的容器技术。在具体介绍容器执行引擎方案及技术路线之前，先上一张容器引擎技术江湖门派概览图，以飨读者。

提到容器引擎（Container Engine）、容器运行时（Container Runtime）这些名称，总是有点容易让人犯晕。为了让事情简化一些，我们关注在云原生、K8S场景下的定义吧。从CNCF Cloud Native Interactive Landscape可以发现，容器引擎领域是一个很活跃的技术领域，该领域的大致发展（战争）史如右下图。

相对较为正式的术语定义如下图，可以把容器管理系统分为三层：

1. High-level Container Management：容器管控的UI层。直接实现容器的管控和使用界面，也是用户最熟悉的子系统。
2. High-level Container Runtime：容器状态及资源供给。包括镜像管理、网络接入、容器状态、调用Low Level Runtime执行容器等功能。习惯上这层称之为容器引擎（Container Engine）。
3. Low-level Container Runtime：容器执行层。负责具体构建容器运行环境并执行容器进程。习惯上这层直接简称为容器运行时（Container Runtime）。

High-level Container Management和Container Engine之间的接口规范是CRI，Container Engine和Container Runtime之间的接口规范是OCI。

下文将分别从容器引擎（High-level container runtime）和容器运行时（Low-level container runtime）两个纬度讨论容器执行引擎相关技术。

容器引擎

容器引擎的核心是准备运行容器所需要的资源以及管理容器生命周期。在K8S生态圈中，容器编排系统通过CRI接口来调用容器引擎。支持CRI接口的容器引擎主要有docker、rkt、pouch、containerd和cri-o等，其中活跃度比较高的是containerd和CRI-O。

containerd

Containerd是从dockerd中抽离出来的容器管理的核心功能，是在社区影响下dockerd模块化的结果，也是现在最热门的容器引擎。由于containerd是从dockerd演化出来的，使用接口是针对容器管理而设计，内置管理对象是Image和Container。K8S CRI的管控对象是Image/Pod/Container，为了让containerd支持Pod对象以及实现CRI接口，引入了CRI-container