为Kubernetes选择合适的容器运行时

前 言

作为后台支撑，Kubernetes优势明显，具有自动化部署、服务伸缩、故障自我修复、负载均衡等特性。咪付的蓝牙过闸系统和全态识别AI系统的后台支撑采用了Kubernetes，经过线上的长期运行，其状态良好运行平稳。

蓝牙过闸系统和全态识别AI系统有着不同的数据特性，对数据的安全要求及运行效率也各不一样，因此如何选择容器的运行时成为了一个重点考虑的因素。

本文将介绍Kubernetes支持哪些容器运行时以及如何选择合适的容器运行时。

这篇文章包含以下内容：

介绍CRI接口规范内容

介绍不同OCI项目的技术特点

CRI是如何衔接Kubelet和OCI层及当前CRI格局

Kubernetes如何支持多种容器运行时

如何选择合适的容器运行时

01 CRI的由来

CRI（Container Runtime Interface）是Kubernetes提出的容器运行时接口规范。

在Kubernetes体系中，是由Kubelet组件负责与容器运行时交互的。Kubelet调用容器运行时的流程如上图所示。CRI shim是实现CRI接口的gRPC server服务，负责连接Kubelet和Container runtime，Container runtime是容器运行时工具，它为用户进程隔离出一个独立的运行环境；具体的流程是Kubelet调用CRI shim接口，CRI shim响应请求，然后调用底层的Container runtime工具运行容器。Kubelet、CRI shim和Container runtime都部署在一个Kubernetes worker节点上，前两者是以独立的守护进程的方式启动的，而Container runtime不是守护进程，它通常是一个命令行工具。

Kubernetes在v1.5版本之前是没有CRI接口的，那时Kubelet源码内部只集成了两个容器运行时(Docker和rkt)的相关代码。这两种容器运行时并不能满足所有用户的使用需求，在某些业务场景，用户对容器的安全隔离性有着更高的需求，用户希望Kubernetes能支持更多种类的容器运行时。因此，Kubernetes在1.5版本推出了CRI接口，各个容器运行时只要实现了CRI接口规范，就可以接入到Kubernetes平台为用户提供容器服务。

CRI接口带来的好处，首先它很好的将Kubernetes和容器运行时解耦，容器运行时的每次更新迭代，都不必对Kubelet工程源码进行编译发布；其次解放了容器运行时更新迭代的步伐，也能保证Kubernetes的代码质量和平台的稳定。

02 OCI是什么

OCI规范（Open Container Initiative 开放容器标准），该规范包含两部分内容：容器运行时标准（runtime spec）、容器镜像标准（image spec）。其具体内容的定义如下图：

容器运行时标准

runtime spec包含配置文件、运行环境、生命周期三部分内容。

• 配置文件 -

config.json，包含容器的配置信息（mounts、process、hostname、hooks等）。

• 运行环境 -

定义运行环境，是为了确保应用程序在多个运行时之间，能具有一致的环境 。

• 容器生命周期 -

定义了运行时的相关指令及其行为：state、create、start、kill、delete、prestart hooks、poststart hooks、poststop hooks。

容器镜像标准

通常我们根据Dockerfile定义的内容制作镜像，目的是构建一个符合OCI标准的镜像文件，那么OCI标准镜像文件的内容都有哪些呢？在OCI规范里的image spec对容器镜像格式做了定义，它主要包括以下几块内容：

• 文件系统 -

描述了如何以layer的方式叠加成一个完整的文件系统，以及如何用layer去表示对文件作出的改动（增加、删除、修改）。

• config文件 -

保存了文件系统的层级信息（每个层级的 hash 值、历史信息），以及容器运行时需要的一些信息（比如环境变量、工作目录、命令参数、mount 列表等）。

• manifest文件 -

记录镜像元信息，包括Image Config和Image Layers。

• index文件 -

可选的文件，指向不同平台的 manifest 文件，相当于整个镜像的入口，从这个文件可以获取整个镜像依赖的所有文件信息。

OCI项目

下表是兼容OCI规范的容器运行时项目：