智汇华云 | kata container virtiofs测试和技术分析

云原生技术已经成为加快企业数字化转型的一个不折不扣的风向标。而以容器为代表的云原生技术正在成为释放云价值的最短路径。本期智汇华云，带大家一起了解和体验安全容器kata container的⼀些特性。

前⾔

当前云原⽣技术发展的如⽕如荼，容器化技术以及kubernetes容器化应⽤管理平台，带来了全新的⽣ 态系统. 随着容器技术的发展，容器运⾏时规范OCI也逐渐脱离Docker被单独提了出来，kubernetes⻓期使⽤的容器运⾏时是runC，轻量，性能⾼，但因为共⽤linux内核以及namespace机制隔离的不彻 底，存在⼀定的安全问题，业界涌现了好⼏个安全容器的解决⽅案，⽐如Google的gVisor, Amazon的 Firecracker，vmware的CRX等, 开源世界⾥⾯⽐较有名的解决⽅案是kata container，本⽂主要就关 注在安全容器kata container的⼀些特性了解和体验。 kata Container

kata container 由⼀系列技术组成，来源于两个项⽬的合并，Intel Clear Containers和Hyper runV，然 后⼜加上redhat贡献的virtio-fs，⼀种在guest和宿主机之间共享⽂件系统的⽅案。涉及的技术有 QEMU/KVM，Linux kernel，⽂件系统，容器运⾏时，容器⽹络等，是⼀项⽐较复杂的组合产品，⽽ 且还保持着很⾼的新特性开发进度，本次主要体验和梳理virtiofs相关的内容，这些内容有部分是来源 于kata的社区邮件列表以及slack，还有微信群，⾮常感慨，kata的社区真是⾮常的Nice，专业程度和 热⼼都令⼈感动。

virtiofs ⽂件系统结构

默认容器是使⽤cgroup和namespace做进程，⽹络，⽂件系统挂载点等隔离，是⾮常轻量级的。⽽ kata container为了实现安全容器，使⽤了VM虚拟机作为强隔离⼿段，有独⽴的内核和虚拟机镜像， 为了降低资源消耗，hypervisor使⽤了⾮常⼩的guest kernel和guest image，⾼度优化了内核的启动 时间，最⼩化了内存占⽤，只提供容器负载所需要的最基本的服务。virtio-fs⽂件系统，在资源消耗上 也使⽤了多种优化特性。 下⾯就来看⼀看具体是怎么使⽤的，以及特性理解 kata container作为除了runC之外另⼀种runtime，需要先在kubernetes环境中做集成部署，以便做各 种观察。当然直接使⽤他的CTR⼯具也是可以，只是缺少CNI的⽀持，⽹络⽅⾯不能⾃动配置。kata container configuration.toml 配置参数有两种共享⽂件系统类型可以选择，之前默认是virtio-9p ，现 在基本上都会选择 virtio-fs，有若⼲优点。 virtio- 9p 和 virtio-fs ⽂件系统对⽐

1. virtio-9p基于现存的⽹络协议，并没有虚拟化场景提供优化

2. virtio-fs利⽤了hypervisor和虚拟机处于相同节点的优势

DAX特性，⽂件内容能够映射到宿主机的内存窗⼝，允许客户机直接访问宿主机的page cache

减少内存占⽤，因为客户机cache已经被绕过了

不需要⽹络节点通信，提⾼了IO性能

测试

kata container 与整合使⽤virtiofsd，把宿主机⽬录共享给微虚拟机使⽤。测试环境版本: Centos 8

qemu-kvm 5.1

kubernetes 1.18

containerd 1.4.4

kata container 2.0.4

使⽤kubernetes 新版本的RuntimeClass 对象，指定handler：kata

创建pod

1 apiVersion: v1

2 kind: Pod

3 metadata:

4 name: kata-alpine

5 spec:

6 runtimeClassName: kataclass

7 containers:

8 - name: alpine

9 image: alpine:latest

10 imagePullPolicy: IfNotPresent

11 command:

12 - /bin/sh

13 - “-c”

14 - “sleep 60m”

15 restartPolicy: Always