云原生技术已经成为加快企业数字化转型的一个不折不扣的风向标。而以容器为代表的云原生技术正在成为释放云价值的最短路径。本期智汇华云，带大家一起了解和体验安全容器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 confifiguration.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 

16 nodeSelector: 

17 kubernetes.io/hostname: 

k8s05 k8s05节点宿主机进程查看 

1 [root@k8s05 ~]# ps aux|grep kata 

2 root 500086 0.0 0.1 1412184 47796 ? Sl Jun18 14:00 /usr/bin/conta 

3 root 500117 0.0 0.0 129064 4960 ? Sl Jun18 0:00 /usr/libexec/k 

4 root 500155 0.2 3.2 4367516 1059672 ? Sl Jun18 41:47 /usr/bin/qemu- 

5 root 500158 0.0 0.8 5667064 271696 ? Sl Jun18 0:03 /usr/libexec/k

可以看到kata container v2 启动了新的与kubernetes对接的CRI进程containerd-shim-kata-v2， KVM虚拟机，还有2个virtiofsd进程。为什么会启动2个virtiofs呢？为了提⾼安全性，virtiofsd 进程 fork⾃⼰，以便进⼊新的 mount/pid/net 命名空间，只有⼦进程内存映射，CPU使⽤⽅⾯处于活跃状 态。

可以看到qemu 虚拟化了设备vhost-user-fs-pci，有⼀个tag为kataShared，这个就是虚拟机要 mount的源。tag就是⼀个⾃定义⽂件系统需要接收的参数，定义路径⽤的。 

Note that Linux 4.19-based virtio-fs kernels required a different mount syntax. mount -t virtio_fs none /mnt -o tag=myfs,rootmode=040000,user_id=0,group_id=0 instead. mount_tag: A tag which acts as a hint to the guest OS and is used to mount this exported path. 

1 -device vhost-user-fs-pci,chardev=char-538bb1c14588b18e,tag=kataShared 

进⼊kata容器观察 

1 [root@k8s01 kata-container]# kubectl exec -it kata-alpine -- sh 

2 / # df -h  

3 Filesystem Size Used Available Use% Mounted on 

4 kataShared 74.0G 49.5G 24.4G 67% / 

5 tmpfs 64.0M 0 64.0M 0% /dev 

6 tmpfs 1.4G 0 1.4G 0% /sys/fs/cgroup 

7 kataShared 74.0G 49.5G 24.4G 67% /etc/hosts 

8 kataShared 74.0G 49.5G 24.4G 67% /dev/termination-log 

9 kataShared 74.0G 49.5G 24.4G 67% /etc/hostname 

10 kataShared 74.0G 49.5G 24.4G 67% /etc/resolv.conf 

11 shm 1.4G 0 1.4G 0% /dev/shm 

12 kataShared 15.7G 12.0K 15.7G 0% /run/secrets/kubernetes.i 

13 tmpfs 64.0M 0 64.0M 0% /proc/keys 

14 tmpfs 64.0M 0 64.0M 0% /proc/timer_list

可以看到容器已经挂载了tag定义的⽂件系统。tag名字可以是任意取的，只要能guest挂载时候指定相同的就可以。对于kata 来说，已经整合好了，不需要⼿⼯指定

有时候如果处于调试⽬的或者是想看⼀下虚拟机的信息，可以配置kata 开启debug 模式，qemu暴露 vsock接⼝，虚拟机通过agent开启shell 

1 configuration.toml 

2

3 [agent.kata] 

4 debug_console_enabled = true 

宿主机再⼿动启动kata-monitor 进程,获取sandbox的vsock地址，⾃⼰监听localhost:8090端⼝，就可以通 过kata-runtime exec $sandboxId 接⼊虚拟机bash了 

1 [root@k8s05 kata]# /usr/bin/kata-monitor  

2 INFO[0010] add sandbox to cache container=7e4cef94733381a9d9c509aa2a0be87e0c0bd 

3 INFO[0020] delete sandbox from cache container=5246e787b17eeab4ca83e9e73583a1b5

进⼊虚拟机查看 

kata根据sandbox的ID，指定唯⼀的宿主机内存共享⽬录source， 传递给virtiofsd. 虚拟机挂载 virtiofsd导出的共享的⽬录到/run/kata-containers/shared/containers，然后再以bind mount的⽅ 式挂载进容器。 

1 [root@k8s05 ~]# kata-runtime exec 0965321e164975f01c85f997fbb0183773a9e97cb5767d9 

2 bash-4.2# df -h  

3 Filesystem Size Used Avail Use% Mounted on 

4 rootfs 1.4G 350M 1.1G 25% / 

5 dev 1.4G 0 1.4G 0% /dev 

6 tmpfs 1.5G 0 1.5G 0% /dev/shm 

7 tmpfs 1.5G 16K 1.5G 1% /run 

8 tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup 

9 kataShared 16G 1.6G 15G 11% /run/kata-containers/shared/containers 

10 shm 1.5G 0 1.5G 0% /run/kata-containers/sandbox/shm

kata根据sandbox的ID，指定唯⼀的宿主机内存共享⽬录source， 传递给virtiofsd. 虚拟机挂载 virtiofsd导出的共享的⽬录到/run/kata-containers/shared/containers，然后再以bind mount的⽅ 式挂载进容器。

持久卷挂载 

⽹络持久卷⽐如iscsi也是能直接挂载进kata容器的，例如创建⼀个pod，直接指定pvc，pv使⽤某⼀个 iscsi lun，然后在容器中创建⼀个⽂件 

1 [root@k8s01 kata-container]# kubectl exec -it iscsipd -- sh  

2 / # cd /mnt/iscsipd 

3 /mnt/iscsipd # ls 

4 lost+found 

5 /mnt/iscsipd # touch aaaa.txt 

在虚拟机⾥⾯已经通过virtiofs挂载在了⼀个容器id⽬录之下 

1 [root@k8s05 ~]# kata-runtime exec e96d0ce2249e9027f0e1102e66a0c0013473ac48a088240 

2 bash-4.2# mount 

3 rootfs on / type rootfs (rw,size=1444588k,nr_inodes=361147) 

4 kataShared on /run/kata-containers/shared/containers type virtiofs (rw,relatime)

5 kataShared on /run/kata-containers/e96d0ce2249e9027f0e1102e66a0c0013473ac48a08824 

6 kataShared on /run/kata-containers/839162f25b7907bf91ecb027305e64dd5ccf36f55b15b6 

7 bash-4.2# find / -name aaaa.txt 

8 /run/kata-containers/shared/containers/839162f25b7907bf91ecb027305e64dd5ccf36f55b

在宿主机上是识别为硬盘块设备/dev/sdd，被kubelet挂载在特定⽬录下⾯，⼀个是sandbox_id，⼀ 个是应⽤container_id

1 [root@k8s05 ~]# lsblk 

2 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT 

3 sda 8:0 0 50G 0 disk  

4 ├─sda1 8:1 0 1G 0 part /boot 

5 sdc 8:32 0 2G 0 disk  

6 sdd 8:48 0 2G 0 disk /run/kata-containers/shared/sandboxes/e96d0ce2

就如前⽂说的，所有数据都要经过virtiofs，不管是镜像数据还是⽹络存储卷。虚拟机要和宿主机数据 交互，就必须要穿过qemu，virtiofs就是穿过qemu的桥梁，提供共享⽂件机制。数据相关的操作最终 还是在宿主机上，⽐如镜像层的合并，仍然是containerd的存储层插件snapshotter完成，底层仍然是 调⽤了overlayfs⽂件系统

1 /etc/containerd/config.toml

2 [plugins."io.containerd.grpc.v1.cri".containerd] 

3 snapshotter = "overlayfs" 

4 default_runtime_name = "runc" 

5 no_pivot = false 

6 disable_snapshot_annotations = true 

7 discard_unpacked_layers = false 

8 ... 

9 [plugins."io.containerd.service.v1.diff-service"] 10 default = ["walking"]

另外kata container 整合使⽤virtiofs的⽅式，与独⽴⼿⼯操作virtiofs的⽅式，有些地⽅稍有不同，⽐ 如按virtiofs官⽅说明，可以指定host⽂件⽬录$TESTDIR作为源

1 ./virtiofsd --socket-path=/tmp/vhostqemu -o source=$TESTDIR -o cache=alwa

⽽在kata runtime⾥⾯是不允许的，⽐如在confifiguration.toml ⾥配置

1 virtio_fs_extra_args = ["-o","--thread-pool-size=1","-o","/opt/kata-instance"]

kubelet 会报错:

Warning FailedCreatePodSandBox 1s (x14 over 15s) kubelet, k8s05 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create containerd task: failed to launch qemu: exit status 1, error messages from qemu log: qemu-system- x86_64: cannot create PID fifile: Cannot open pid fifile: No such fifile or directory

kata还会打开vhost-user socket ⽂件描述符，传递给virtiofsd。可能有⼈会有疑问，为什么每⼀个 virtiofsd进程的fd参数都等于3，会不会有冲突。其实不会，因为⽂件描述符是进程独⽴的，STDIO占 据了0，1和2，那么virtiofsd第⼀个可⽤的fd num就是3了

virtiofsd cache guest 

guest ⽣成是会指定内存⼤⼩，virtiofsd会共享使⽤guest的内存。默认使⽤memory-backend-fifile内存对象 

virtiofsd共享使⽤VM内存，confifiguration.toml 配置参数default_memory 

qemu 命令⾏接受的参数

1 -object memory-backend-file,id=dimm1,size=3072M,mem-path=/dev/shm,share=on -numa  

guest和host数据传输都是通过virtio-fs，包括容器镜像和容器卷，读写权限取决于virtiofsd进程的权限

DAX(直接访问)

dax

DAX windows 是⼀块虚拟内存区域，通过PCI Bar 把⽂件映射到guest⾥⾯，并不真正的占⽤主机那 么多内存，即使有100个虚拟机，设置的DAX cache是1G，也不会真的使⽤100G内存。只是⼀种page 映射机制，所以也不需要任何的cache 策略。

要任何的cache 策

kata container官⽅下载的版本默认没有不⽀持，需要编译安装gitlab托管的virtio-fs qemu项⽬ qemu5.0-virtiofs-dax 分⽀

confifiguration.toml 设置virtio_fs_cache_size dax window ⼤⼩，qemu初始化vhost-user-fs-pci设 备

1 -machine q35,accel=kvm,kernel_irqchip,nvdimm 

2 -device nvdimm,id=nv0,memdev=mem0 -object memory-backend-file,id=mem0,mem-path=/o

3 -device vhost-user-fs-pci,chardev=char-ea09ec33d071ac42,tag=kataShared,cache-size

如果是rootfs image 可以看到模拟的nvdimm信息，⾃⼰编译镜像的话，image_builder.sh构建脚本会 在image⽂件头部写⼊dax metadata信息。initrd image看不到。image 相当于是直接⽤rootfs引导， initramfs（initrd）是把cpio+gz打包压缩的rootfs解压到内存⾥，再⽤内存⾥的initramfs来引导。前 者可以利⽤dax，让guest os认为这就是个dimm内存，不需要再加载到另⼀块内存⾥，后者就是需要 解压到⼀块内存。 

DAX 背后的想法是避免在guest中使⽤ _second_ 缓冲区缓存。⼀般对于常规⽂件，guest会维护⾃⼰ ⽂件系统缓冲区。 

现在呢，对于与 virtiofs 共享的⽂件，由于它们驻留在主机上，您将在主机上拥有⼀份缓存副本，然后 virtiofs 会将其发送给guest ，然后guest就也有了⼀份副本，成本就⽐较⾼。 DAX 就是为了解决这个问题的，它所做的就是将主机buffffer map到客户机中，guest使⽤与主机相同 的物理内存，即使它使⽤不同的虚拟地址。如果没有 DAX，内存使⽤量可能会⾮常⼤，因为每个 guest都有⾃⼰的⽂件缓冲区。例如，如果您启动⼀个 Fedora 容器并“dnf install something”，您将 看到内存使⽤量增加了约 300M，因为在该操作期间读取/写⼊了许多⽂件。如果没有 DAX，那么 guest也需要分配 350M。使⽤ DAX，它就会直接使⽤宿主机中已为这些⽂件缓冲分配的350M内存 

性能测试 

测测DAX window⼤⼩对性能的影响(virtio_fs_cache_size = 512) 

⼩⽂件测试

1 fio --name=small-file-multi-read --directory=/usr/share/nginx/html \ 

2 --rw=randread --file_service_type=sequential \ 

3 --bs=4k --filesize=10M --nrfiles=100 \ 

4 --runtime=60 --time_based --numjobs=1 

5 ... 

6 small-file-multi-read: (groupid=0, jobs=1): err= 0: pid=190: Mon Jul 5 07:05:18 

7 read: IOPS=12.0k, BW=46.0MiB/s (49.2MB/s)(212MiB/4505msec)

⼤⽂件测试

1 fio --name=5G-bigfile-rand-read --directory=/usr/share/nginx/html --rw=ra 

2 ... 

3 5G-bigfile-rand-read: (groupid=0, jobs=1): err= 0: pid=184: Mon Jul 5 06:57:08 2 4 read: IOPS=1255, BW=5024KiB/s (5144kB/s)(294MiB/60002msec)

从压测观察到当读写的⽂件超过dax window后，性能下降很多，原因和dax映射机制有关，dax窗⼝的 回收是⽐较慢的，当活跃数据超过dax window ，产⽣很多的回收⼯作会导致性能很差。另外dax window的映射单元是按每2MB内存⼤⼩映射的，具体来说就是由512个 struct page (one struct page for each 4K range) 和⼀个 struct fuse_dax_mapping 。每个单元映射范围⼤约需要消耗32K 额外内存。⽐如1GB of dax window: 512 * 32K = 16MB of memory usage.

同时还观察到virtiofsd占⽤内存很⾼，⽐如本实例qemu-system-x86_64 rss 内存3.1G，virtiofsd rss 1.6G，⽣产中对资源的控制需要细节控制。

总结

kata container 还是⼀项⽐较复杂的技术组合，实践⽂档较少，有问题要不就是求教于社区，要不就 得翻源码，源码牵涉到linux kernel，qemu/kvm,fifilesystem,内存映射，容器等多种技术，⽽且还是⽐ 较新的技术。但云原⽣安全⼜是未来越来越受到重视的领域，极⼤影响业务容器化的决策。希望⾏业 能更多的参与到安全容器上来，增加实践场景，畅快投⼊云原⽣的怀抱