iSula 容器引擎具备优点呈现 | 性能测试

原创
2020/09/15 13:01
阅读数 777

iSula容器引擎具有很多优点:轻、快等等。那么,如何呈现这些优点呢?本篇文章我们主要关注iSula 容器引擎的“快”


为了证明“快”,那就需要有参照物进行对比。环视业内,我们发现几个能打的:容器引擎鼻祖Docker、红帽的Podman以及CRI-O。


现在目标确定了,我们开始明确对比范围。

01

测试范围


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


• 客户端使用模式:多见于个人开发、测试以及部分生产场景;

• PAAS通过CRI接口使用模式:云计算的经典场景,通过CRI接口调用容器引擎能力,管理pod集群;


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


客户端模式


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


• Docker

• Podman

• iSula 


CRI模式


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


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


• Docker

• CRI-O

• iSula 


02

环境准备


机器环境


X86 



ARM


安装iSulad 


参考官方文档:安装即可。



安装cri-tools


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



安装docker


根据官方文档安装即可。



安装kubelet


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


准备源码


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



开始下载源码:



编译



注意:


K8S的版本对go的版本有要求,例如 V1.15.0 需要go 1.12版本

• 可以使用 go mod tidy ,测试依赖代码下载,如果存在鉴权失败的仓库,可以使用 go get -v insecure 下载 


安装



启动kubelet



注:cgroup由systemd管理


安装CRI-O


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



安装podman


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



03

测试方案


本篇文章主要关注容器引擎的容器生命周期的性能,所以测试方案如下:


• 单容器的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插件执行失败。



方案详细设计


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



客户端模式


X86环境测试结果


单容器操作性能对比



100容器并发操作性能对比



ARM环境测试结果

单容器操作性能对比



100容器并发操作性能对比



CRI模式


X86环境测试结果


单pod操作



单pod单容器操作


100并发pod操作



100并发pod容器操作



ARM环境测试结果


单pod操作



单pod单容器操作



100并发pod操作



100并发pod容器操作



04

总结分析


从测试数据来看,在容器的生命周期的操作和并发操作上面,我们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的流程没有描述,大体结构如下:



从架构来看,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
• iSulad安装文档:
https://gitee.com/openeuler/iSulad/blob/master/docs/build_guide.md
• docker安装文档:
https://docs.docker.com/engine/install/fedora/



☆每周二、周四晚8点,更多iSula容器详细解读
我们在openEuler直播间等你~



观众老爷们来点一波关注
支持一下吧~!


本文分享自微信公众号 - openEuler(openEulercommunity)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部