iSula容器引擎具有很多优点：轻、快等等。那么，如何呈现这些优点呢？这篇文章我们主要关注iSula容器引擎的“快”。为了证明“快”，那就需要有参照物进行对比。环视业内，我们发现几个能打的；容器引擎鼻祖Docker、红帽的Podman以及CRI-O。

目标确定了，我们开始明确对比范围了。

测试范围 ​

容器引擎的使用模式主要是：

• 客户端使用模式：多见于个人开发、测试以及部分生产场景；
• PAAS通过CRI接口使用模式：云计算的经典场景，通过CRI接口调用容器引擎能力，管理pod集群；

为了尽量覆盖应用场景，因此我们需要覆盖上述两种场景，对客户端模式和CRI模式分别进行测试对比。

客户端模式 ​

由于CRI-O不具备客户端功能，所以我们选择的测试对象是：

• Docker
• Podman
• iSula

CRI模式 ​

CRI接口，需要通过cri-tools工具进行测试。

为了对比的观赏性，我们在CRI模式下也选择三个测试对象：

• Docker
• CRI-O
• iSula

环境准备 ​

机器环境 ​

X86 ​

ARM ​

安装iSulad ​

参考官方文档安装即可。

$ isula version

Client:
  Version:	2.0.3
  Git commit:	3bb24761f07cc0ac399e1cb783053db8b33b263d
  Built:	2020-08-01T09:40:06.568848951+08:00

Server:
  Version:	2.0.3
  Git commit:	3bb24761f07cc0ac399e1cb783053db8b33b263d
  Built:	2020-08-01T09:40:06.568848951+08:00

OCI config:
  Version:	1.0.1
  Default file:	/etc/default/isulad/config.json

安装cri-tools ​

CRI测试，使用统一的客户端工具进行测试，选择K8S对应的V1.15.0版本即可。

$ git clone https://github.com/kubernetes-sigs/cri-tools
$ cd cri-tools
$ git checkout v1.15.0
$ make
$ export PATH=$PATH:$GOPATH/bin

安装docker ​

根据官方文档安装即可。

$ docker version

Client:
 Version:           19.03.11
 API version:       1.40
 Go version:        go1.14.3
 Git commit:        42e35e6
 Built:             Sun Jun 7 21:16:58 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.11
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.14.3
  Git commit:       42e35e6
  Built:            Sun Jun 7 00:00:00 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.3.3
  GitCommit:        
 runc:
  Version:          1.0.0-rc10+dev
  GitCommit:        fbdbaf85ecbc0e077f336c03062710435607dbf1
 docker-init:
  Version:          0.18.0
  GitCommit:

安装kubelet ​

我们选择V1.15.0版本作为测试版本，下载源码https://github.com/kubernetes/kubernetes.git。

准备源码 ​

如果下载失败或者太慢，可以配置代理：

# 设置国内代理
go env -w GOPROXY=https://goproxy.cn,direct
# 设置私有仓库地址
go env -w GOPRIVATE=.gitlab.com,.gitee.com
# 设置sum验证服务地址
go env -w GOSUMDB="sum.golang.google.cn"

开始下载源码：

$ cd $GOPATH/src/k8s.io
$ git clone https://github.com/kubernetes/kubernetes.git
$ cd kubernetes
$ git checkout v1.15.0
$ go mod tidy

编译 ​

$ make all WHAT=cmd/kubelet

注意：

• K8S的版本对go的版本有要求，例如V1.15.0需要go 1.12版本
• 可以使用go mod tidy，测试依赖代码下载，如果存在鉴权失败的仓库，可以使用go get -v -insecure下载

安装 ​

$ cp _output/bin/kubelet /usr/local/bin/kubelet
$ kubelet --version
  Kubernetes v1.15.0

启动kubelet ​

$ kubelet --network-plugin=cni --runtime-cgroups=/systemd/system.slice --kubelet-cgroups=/systemd/system.slice --cgroup-driver="systemd"  --fail-swap-on=false  -v 5 --enable-controller-attach-detach=false --experimental-dockershim

注：cgroup由systemd管理

安装CRI-O ​

由于直接通过dnf安装CRI-O的v1.15.4版本有问题，所以需要源码编译安装。

$ dnf install glib-2.0 glibc-devel glibc-static container-common
$ git clone https://github.com/cri-o/cri-o.git
$ cd crio
$ make
$ make install
$ mkdir -p /etc/crio && cp crio.conf /etc/crio/

安装podman ​

直接使用dnf的源安装即可：

$ dnf install -y podman

$ podman --version
  podman version 2.0.3

测试方案 ​

本文档主要关注容器引擎的容器生命周期的性能，所以测试方案如下：

• 单容器的create、start、stop、rm和run等操作的性能；
• 100个容器并发create、start、stop、rm和run等操作的性能；
• 单pod的runp、stopp和rmp等操作的性能；
• 单pod包含单容器的run、stop和rm等操作的性能；
• 100个pod并发runp、stopp和rmp等操作的性能；
• 100个包含单容器的pod并发run、stop和rm等操作的性能；

注：pod的配置，必须指定linux，不然docker会给pod创建一个默认的网卡，导致cni插件执行失败。

{
    "metadata": {
        "name": "nginx-sandbox",
        "namespace": "default",
        "attempt": 1,
        "uid": "hdishd83djaidwnduwk28bcsb"
    },
    // linux字段必须存在
    "linux": {
    }
}

方案详细设计 ​

单次测试和并发测试虽然是两种测试场景，但是单次可以看成并发的特例。因此，设计测试用例的时候，通过控制并发数量来实现两种场景的区分。具体设计如下图：

graph TD
	classDef notestyle fill:#98A092,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5, 5;
	classDef parallelstyle fill:#C969A3,stroke:#666,stroke-width:1px,color:#ffa,stroke-dasharray: 5, 5;
	subgraph pretest;
	A[download images] --> B[do clean]
	end
	subgraph dotest
	C[foreach 1->10]
	D{{runtest}}
	E(remove max and min cases)
	X(calculate avg of residual case)
	C --> D
	D --> E
	E --> X
	end
	B --> C
	subgraph runtest
	R(begin test)
	F>t1: get begin time point]
	G(parallel run all cases)
	H[wait all cases finish]
	I>t2: get end time point]
	R --> F
	F --> G
	F --> H
	H -. wait .-> G
	H --> I
	end
	R -. implements .-> D
	subgraph posttest
	Z[do clean]
	end
	X --> Z
	class R notestyle;
	class G parallelstyle;

客户端模式 ​

X86环境测试结果 ​

单容器操作性能对比

100容器并发操作性能对比

ARM环境测试结果 ​

单容器操作性能对比

100容器并发操作性能对比

CRI模式 ​

X86环境测试结果 ​

单pod操作

单pod单容器操作

100并发pod操作

100并发pod容器操作

ARM环境测试结果 ​

单pod操作

单pod单容器操作

100并发pod操作

100并发pod容器操作

总结分析 ​

从测试数据来看，在容器的生命周期的操作和并发操作上面，我们iSulad都是优于其他容器引擎的。尤其是在ARM上的表现尤为出色，并发性能已经接近于X86的性能了；而其他容器引擎在ARM上面的表现不尽如人意，甚至出现性能下降1倍以上。

那么，我们iSulad为什么有这么大的优势呢？我觉得，主要是从下面几个方面来看。

• 首先，iSulad是用C/C++语言写的，而Docker/Podman/CRI-O都是用golang写的；C/C++在速度方面本身就有优势；
• 架构设计上面，相对于Docker，iSulad架构更加简单，调用链更短；而Podman是serverless模式，并发更加不具备优势；
• 在容器创建流程中，减小锁粒度、消减容器的依赖（例如镜像管理模块），从而提高了并发的性能；

架构对比 ​

iSulad架构设计如下：

Docker官网给的架构图如下：

但是，docker daemon里面还涉及到containerd和runc的流程没有描述，大体结构如下：

graph LR
	A(docker daemon)
	B(containerd)
	C(runc)
	A -. grpc .-> B
	B -. fork/exec .-> C

从架构来看，docker的容器生命周期流程涉及：客户端到docker daemon的restful通信；daemon到containerd的GRPC通信；然后fork执行runc。而iSulad的流程：客户端到服务端的GRPC通信，然后fork执行lxc-start。

参考文档 ​

• https://stackoverflow.com/questions/46726216/kubelet-fails-to-get-cgroup-stats-for-docker-and-kubelet-services
• https://developer.aliyun.com/article/630682
• https://blog.csdn.net/bingshiwuyu/article/details/107333259
• https://github.com/cri-o/cri-o
• https://gitee.com/openeuler/iSulad/blob/master/docs/build_guide.md