Kata containers性能調(diào)優(yōu)探索與實踐

1、Kata containers 2.0 性能調(diào)優(yōu)探索與實踐技術(shù)創(chuàng)新，變革未來目錄移動云與kata containers的聯(lián)系選擇kata作為安全容器方案的考量kata的架構(gòu)與網(wǎng)絡(luò)模型概述性能調(diào)優(yōu)探索與優(yōu)化思路分享展望Q/A移動云與Kata Containers的聯(lián)系考量 - 安全容器方案對比安全容器方案實現(xiàn)方式隔離方式性能、輕量化通用、靈活性適用場景使用的廠商Google gVisor用戶態(tài)內(nèi)核攔截系統(tǒng)調(diào)用IO、網(wǎng)絡(luò)性能不佳較低，僅支持有限的 系統(tǒng)調(diào)用，不通用ServerlessGoogleAWS Firecracker輕量級虛擬化虛擬化高一般，不完整的虛擬 化，不夠通用Serverlessa

2、ws、ucloudKata Containers輕量級虛擬化虛擬化高高，支持多種輕量級 虛擬化hypervisor多種需求場景Baidu、Huawei、 Ant Financial、 Alibaba這里僅對比了3種較為主流的安全容器方案總結(jié)：Kata contaienrs靈活性高，可以根據(jù)自己的需求場景選擇合適的hypervisor，一套方案能覆蓋多種場景：普通場景、 serverless、邊緣端相比于gvisor，kata性能更好。相比于firecracker，更加云原生。直接使用gvisor和firecracker的容器方案廠商較少，kata容器國內(nèi)參與的廠商較多?？剂?- 我們的計劃、打

3、算Kata 整體架構(gòu)crictlcontainerdcri plugincontainerd-shim-kata-v2containerVfirecrackeragentcontainercontainercontainercontainerd-shim-runc-v1VqemuagentcontainercontainercontainerVcloud-hypervisoragentcontainercontainercontainerkubeletv2 APIShim v1 APIrunc runtimekata runtimecontainerd-shim-runc-v1containe

4、rcontainerd-shim-kata-v2containerd-shim-kata-v2Kata 網(wǎng)絡(luò)模型host netnstccontainerd-shim-kata-v2container netns1qemu/kvmagentcontainercontainercontainereth0if353veth9527ef07if3containerd-shim-kata-v2container netns2qemu/kvmagentcontainercontainereth0containerveth52fb9507if3eth0bridgeveth pairveth pairout

5、side networktcfiltermacvtapeth0if341tcfiltermacvtapgrpc on vsock技術(shù)要點總結(jié)：主要解決的問題：現(xiàn)有容器網(wǎng)絡(luò)模型 與現(xiàn)有虛擬機(jī)網(wǎng)絡(luò)模型不匹配的問題，將CNI網(wǎng)絡(luò)和虛機(jī)網(wǎng)絡(luò)對接。veth和tap連通方案：tcfilter：使用tc rules將veth的 ingress和egress隊列分別對接 tap的egress和ingress隊列實現(xiàn) veth和tap的直連macvtap：現(xiàn)有虛擬網(wǎng)卡連通技術(shù)grpc on vsock優(yōu)化思路：針對kata重新設(shè)計CNI直接打通cni0網(wǎng)橋與tap設(shè)備，實現(xiàn) 思路：直接attach tap到cn

6、i0基于dpdk實現(xiàn)，cni0變?yōu)橐粋€ vswitch，與VM中eth0，基于 dpdk + vhost-user都是現(xiàn)有虛擬化中比較成熟的方案，重點在于如何針對kata設(shè)計CNI關(guān)于kata容器的考量我們從哪些維度去考量kata containers？容器啟動速度CPU、內(nèi)存性能損耗資源開銷網(wǎng)絡(luò)性能文件IO性能整體表現(xiàn)1 容器啟動速度CPU: Intel(R) Xeon(R) CPU E5-2650 v2 2.60GHzHost kernel：4.19.0-193.1.3.bclinux.x86_64磁盤：機(jī)械硬盤測試命令：test1: time ctr run -runtime io.co

7、ntainerd.kata.v2 -t -rm docker.io/library/busybox:latest hello uname atest2: ctr run -runtime io.containerd.kata.v2 -t -rm docker.io/library/busybox:latest dmesgruntime + storage driver耗時runc + overlayfs0.5srunc + devmapper1.3skata + virtio-9p0.8skata + virtio-fs1.1skata + devmapper1.5s說明：test1中測試使用

8、的qemu，測出來的時間實際上是容器啟動 + 執(zhí)行命令 + 容器銷毀的總時間test1中virtiofs 比virtio9p多耗時0.2s，virtiofs需要啟動virtiofd，多出來的0.2s是virtiofsd啟動、銷毀時間開銷hypervisor耗時kata + qemu347ms (kernel) + 115ms (userspace) = 462mskata + cloud-hypervisor272ms (kernel) +79ms (userspace) = 352mskata + firecracker176ms (kernel) + 137ms (userspace) =

9、 314mstest1: 測試啟動銷毀總耗時test2: vm啟動時間容器啟動速度kata container啟動時間構(gòu)成分析：Step1: qemu啟動 + virtiofsd (vhost-user-fs server)啟動 + kvm創(chuàng)建vm資源Step2: guest os內(nèi)核態(tài)：kernel bootupStep3: guest os用戶態(tài)：systemd + agent啟動Step4: vm中agent創(chuàng)建container + container啟動調(diào)優(yōu)、優(yōu)化思路：使用輕量化hypervisor，好處是進(jìn)一步精簡了VM的設(shè)備模型，減少了內(nèi)核中設(shè)備初始化時間開銷開啟vm templ

10、ate，將Step1 Step3變?yōu)榱藇m template clone and resume，減少了總的時間開銷host kernel打補丁加固：df12eb6d6cd9 (net: virtio_vsock: Enhance connection semantics“)使用固態(tài)硬盤作為物理存儲，加快文件讀取2 CPU、內(nèi)存性能損耗OCI runtimeCPU損耗Mem損耗runc0.5% 0.5 %kata2%1 %CPU: Intel(R) Xeon(R) CPU E5-2650 v2 2.60GHzHost kernel：4.19.0-193.1.3.bclinux.x86_64Pod

11、規(guī)格：4c4g測試命令：CPU損耗：kubectl exec -ti $pod - sysbench cpu runMem損耗：kubectl exec -ti $pod - sysbench memory -memory-block-size=4k -memory-total-size=4G run性能損耗低原因：高版本的kernel kvm模塊、qemu代碼做了優(yōu)化，虛擬化的開銷 1.5%3 資源開銷CPU: Intel(R) Xeon(R) CPU E5-2650 v2 2.60GHzHost kernel：4.19.0-193.1.3.bclinux.x86_64Pod規(guī)格：4c4g測

12、試命令：ctr run -runtime io.containerd.runc.v1 -rm -t docker.io/library/busybox:latest helloshcat /proc/$vm_pid/state |grep i vmrsshypervisorMem Overheadqemu142820 kBcloud-hypervisor255428 kBfirecracker88276 kB4 網(wǎng)絡(luò)性能調(diào)優(yōu)、優(yōu)化思路：開啟虛擬網(wǎng)卡多隊列（kata支持，但存在“缺陷”，默認(rèn)單vcpu，單隊列，需要 改進(jìn)）虛機(jī)內(nèi)部中斷均衡（實測表現(xiàn)性能提升不明顯）虛擬網(wǎng)卡ring buffer長

13、度默認(rèn)是256，建議修改為1024 18.718.115.817.9151416171819網(wǎng)卡：2個萬兆卡組mode 4的bond，理論帶寬是20Gb/sk8s網(wǎng)絡(luò)插件: flannel，backend為vxlanPod規(guī)格: 4c4g測試命令：kubectl exec ti $pod - - iperf3 c $server P 4網(wǎng)絡(luò)性能-帶寬(GB/s)barekata(vhost-net)單隊列runckata(vhost-net)多隊列Runtime帶寬(GB/s)bare18.7runc18.1kata vhost-net單隊列15.8kata vhost-net多隊列17.95

14、 文件IO性能磁盤：機(jī)械硬盤Pod規(guī)格：4c4g測試命令：fio -directory=/testdir -rw=$rw -bs=$bs -size=4G -numjobs=4 -iodepth=128 -runtime=30 -direct=1 -ioengine=libaio -group_reporting -name=rand$rw_$bs_test參數(shù)：帶寬測試：bs=128k，順序讀、順序?qū)慽ops測試：bs=4k，隨機(jī)讀、隨機(jī)寫調(diào)優(yōu)、優(yōu)化思路：使用device mapper作為存儲驅(qū)動，性能較好且穩(wěn)定，缺 點是排查問題相對復(fù)雜打開iothread使用高性能固態(tài)盤、或是上spdk遇

15、到的問題/疑問：virtio-fs cache設(shè)為none后，測試發(fā)現(xiàn)沒有生效，還 是會使用host page cachevirtio-9p無法關(guān)閉cache500450400350300250200150100500隨機(jī)讀隨機(jī)寫barerunc+devmapperrunc+overlayfskata + devmapper125130135140145150155順序讀順序?qū)慖O性能測試 帶寬(MB/s)barerunc+device mapperrunc+overlayfsIOPS性能測試kata + device mapper6 nginx性能runtime&rootfsnginx 1 workerrunc16948.77 req/skata + virtio-9p1181.99 req/skata + virtio-fs3786.81 req/sKata + devmapper8854.39 req/s調(diào)優(yōu)、優(yōu)化思路：針對nginx、redis、mysql不同類型的具體應(yīng)用，來設(shè)置內(nèi)核調(diào)優(yōu)參數(shù)使用高性能固態(tài)硬盤nginx壓測P