云原生技術已經成為加快企業數字化轉型的一個不折不扣的風向標。而以容器為代表的云原生技術正在成為釋放云價值的最短路徑。本期智匯華云，帶大家一起了解和體驗安全容器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

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??是不允許的，?如在configuration.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內存，configuration.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 分?

configuration.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,內存映射，容器等多種技術，?且還是? 較新的技術。但云原?安全?是未來越來越受到重視的領域，極?影響業務容器化的決策。希望?業 能更多的參與到安全容器上來，增加實踐場景，暢快投?云原?的懷抱。

免責聲明：市場有風險，選擇需謹慎!此文僅供參考，不作買賣依據。