标签：没有 app ubunt utc pos ima safe hat ssl
基于轻量级虚拟机的容器，不同容器跑在一个个不同的虚拟机（kernel）上，比起传统容器提供了更好的隔离性和安全性。同时继承了容器快速启动和快速部署等优点。
轻量级虚拟机，就是号称我比你快安全性还比你更屌的那些，此类的 paper 比比皆是，比如 SOSP‘17 的 My VM is Lighter (and Safer) than your Container 。但一直不成气候的原因，我个人觉得就是没有对接工业界的标准，比如说 OCI 。像 Docker 最成功的地方在于构建了一套快速部署的容器生态，比如说你需要跑一个 nginx 容器，那么只需 docker pull nginx 即可把 image 从仓库拉到本地，然后 run 一下就跑起来了。
如果我们能够利用起 Docker 构建的这套 “上层建筑”，再将其底层替换成我们自己的实现，岂不美哉？
根据 OCI 的 specification，虚拟机 runtime 阵营主要有 hyperhq/runv 和 clearcontainers/runtime
runV 看名字就是和 docker 的 runC 对着干的。通过对接 Docker/Containerd 的接口，使其可以作为 docker 的 runtime 运行容器。
而 clearcontainers 是 Intel 搞出的一套 runtime。同样可以作为 docker 的 runtime 运行容器。
Kata Containers 是这两个项目合并，代表了虚拟机容器阵营的前进方向：
关于该项目，官网 的内容也比较简单，网上也只有寥寥几篇新闻稿，通过以下几幅图我们可以先窥一斑：
区别于传统容器共享同一个 kernel ，Kata 容器每个容器都使用专有内核，更安全。
作为 runtime ，上接 docker / kubernetes / openstack 生态。
还在开发中。根据 zhihu 的消息，比较稳定的版本，保守的话估计是今年（2018）H1，激进的话最早也要今年（2018）Q1，赶上 Ubuntu 18.04 。
相信看到这里的你和我一样索然无味，既然 Kata 还不能用，那么我们先来折腾下 runV 和 clearcontainers 。所以说本文其实是一篇安装配置文章。
首先需要安装 docker ，这点就不多说了。
首先下载、编译、安装 runV：
| apt-get install autoconf automake pkg-config make gcc golang qemu libvirt-bin libvirt-dev | |
| mkdir $GOPATH/src/github.com/hyperhq | |
| cd $GOPATH/src/github.com/hyperhq | |
| git clone https://github.com/hyperhq/runv/ | |
| cd runv | |
| ./autogen.sh | |
| ./configure --without-xen | |
| make | |
| sudo make install |
注意除了当前用户需要配置 $GOPATH 外，root 也需要设置，否则在最后一步 sudo 时找不到 $GOPATH 会报错安装不上。
然后需要安装 hyperstart，来为运行容器的 Guest OS 提供 kernel 和 initrd ，这个 kernel 是定制过的，可能后续会做成 Unikernel 。
| git clone https://github.com/hyperhq/hyperstart.git | |
| cd hyperstart | |
| ./autogen.sh | |
| ./configure | |
| make | |
| sudo mkdir /var/lib/hyper/ | |
| sudo cp build/hyper-initrd.img build/arch/x86_64/kernel /var/lib/hyper |
会将生成的 hyper-initrd.img 、kernel 拷贝到 /var/lib/hyper 目录下。
修改 docker 默认的 runtime 为 runv ，即往 /etc/docker/daemon.json 写入：
| { | |
| "default-runtime": "runv", | |
| "runtimes": { | |
| "runv": { | |
| "path": "runv" | |
| } | |
| } | |
| } |
然后重启 docker ：
| sudo systemctl restart docker |
然后就可以通过 docker 来跑虚拟机容器了：
| docker run --rm -it busybox |
我们查看运行的进程：
| root 25711 0.0 0.0 486732 20488 ? Ssl 20:21 0:00 runv --root /run/runv --log_dir /var/log/hyper proxy --vmid vm-JUmNdtgAMR --hyperstart-ctl-sock unix:///var/run/hyper/vm-JUmNdtgAMR/hyper.sock --hyperstart-stream-sock unix:///var/run/hyper/vm-JUmNdtgAMR/tty.sock --proxy-hyperstart /var/run/hyper/vm-JUmNdtgAMR/hyperstartgrpc.sock | |
| root 25731 0.0 0.0 409768 22288 ? Ssl 20:21 0:00 runv --root /run/runv --log_dir /var/log/hyper watcher --watch-vm-console /var/run/hyper/vm-JUmNdtgAMR/console.sock --console-proto telnet --watch-hyperstart --watch-vm | |
| root 25732 0.0 0.0 500660 24220 pts/19 Ssl+ 20:21 0:00 runv --root /run/runv --log_dir /var/log/hyper/shim-1f2a463701d94e31b22b929c5136ae24c24c0081f4012d886ca42a59f4bc2410 shim --container 1f2a463701d94e31b22b929c5136ae24c24c0081f4012d886ca42a59f4bc2410 --process init --proxy-stdio --proxy-exit-code --proxy-signal --proxy-winsize | |
| root 181072 0.0 0.0 412744 20768 ? Ssl Dec24 0:01 runv --root /run/runv --log_dir /var/log/hyper proxy --vmid vm-HhvgYYBcQT --hyperstart-ctl-sock unix:///var/run/hyper/vm-HhvgYYBcQT/hyper.sock --hyperstart-stream-sock unix:///var/run/hyper/vm-HhvgYYBcQT/tty.sock --proxy-hyperstart /var/run/hyper/vm-HhvgYYBcQT/hyperstartgrpc.sock | |
| ... | |
| root 25722 0.1 0.1 677436 125788 ? Sl 20:21 0:02 /usr/bin/qemu-system-x86_64 -machine pc-i440fx-2.1,accel=kvm,usb=off -global kvm-pit.lost_tick_policy=discard -cpu host -kernel /var/lib/hyper/kernel -initrd /var/lib/hyper/hyper-initrd.img -append console=ttyS0 panic=1 no_timer_check iommu=off -realtime mlock=off -no-user-config -nodefaults -no-hpet -rtc base=utc,clock=vm,driftfix=slew -no-reboot -display none -boot strict=on -m size=128,slots=1,maxmem=32768M -smp cpus=1,maxcpus=8 -numa node,nodeid=0,cpus=0-7,mem=128 -qmp unix:/var/run/hyper/vm-JUmNdtgAMR/qmp.sock,server,nowait -serial unix:/var/run/hyper/vm-JUmNdtgAMR/console.sock,server,nowait -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x3 -chardev socket,id=charch0,path=/var/run/hyper/vm-JUmNdtgAMR/hyper.sock,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charch0,id=channel0,name=sh.hyper.channel.0 -chardev socket,id=charch1,path=/var/run/hyper/vm-JUmNdtgAMR/tty.sock,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charch1,id=channel1,name=sh.hyper.channel.1 -fsdev local,id=virtio9p,path=/var/run/hyper/vm-JUmNdtgAMR/share_dir,security_model=none -device virtio-9p-pci,fsdev=virtio9p,mount_tag=share_dir -daemonize -pidfile /var/run/hyper/vm-JUmNdtgAMR/pidfile -D /var/log/hyper/qemu/vm-JUmNdtgAM.log |
可见 runV 是作为一个中间件，底层跑的是 QEMU 和 KVM 。整体架构是：
| docker - containerd - runv-shim - runv-proxy - QEMU - KVM |
| sudo sh -c "echo ‘deb http://download.opensuse.org/repositories/home:/clearcontainers:/clear-containers-3/xUbuntu_$(lsb_release -rs)/ /‘ >> /etc/apt/sources.list.d/clear-containers.list" | |
| wget -qO - http://download.opensuse.org/repositories/home:/clearcontainers:/clear-containers-3/xUbuntu_$(lsb_release -rs)/Release.key | sudo apt-key add - | |
| sudo -E apt-get update | |
| sudo -E apt-get -y install cc-runtime cc-proxy cc-shim |
像 runV 一样，修改 docker 默认的 runtime 为 rcc-runtime ，即往 /etc/docker/daemon.json 写入：
| { | |
| "default-runtime": "cc-runtime", | |
| "runtimes": { | |
| "cc-runtime": { | |
| "path": "/usr/bin/cc-runtime" | |
| } | |
| } | |
| } |
然后重启 docker ：
| sudo systemctl restart docker |
启动 cc-proxy：
| sudo systemctl enable cc-proxy.socket | |
| sudo systemctl start cc-proxy.socket |
然后就可以通过 docker 来跑虚拟机容器了：
| docker run --rm -it busybox |
感觉 cc-runtime 明显比 runV 快。
我们查看运行的进程：
| root 140668 0.0 0.0 413956 3904 ? Sl 20:02 0:00 docker-containerd-shim 5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a /var/run/docker/libcontainerd/5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a /usr/bin/cc-runtime | |
| root 140785 0.0 0.0 187760 7252 ? Sl 20:02 0:00 /usr/libexec/clear-containers/cc-proxy -uri unix:///run/virtcontainers/pods/5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a/proxy.sock | |
| root 140792 0.0 0.0 4368 664 pts/21 Ss+ 20:02 0:00 /usr/libexec/clear-containers/cc-shim -c 5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a -t CxUmdrsTsov3PDMh0BWhRZlnV21mFB3ZboUSsjV9y8E= -u unix:///run/virtcontainers/pods/5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a/proxy.sock | |
| root 140793 0.0 0.0 4368 120 pts/21 S+ 20:02 0:00 /usr/libexec/clear-containers/cc-shim -c 5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a -t CxUmdrsTsov3PDMh0BWhRZlnV21mFB3ZboUSsjV9y8E= -u unix:///run/virtcontainers/pods/5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a/proxy.sock | |
| root 140726 3.0 0.2 5935252 146892 ? Sl 20:02 0:03 /usr/bin/qemu-lite-system-x86_64 -name pod-5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a -uuid a9ea1387-5e7c-4c7f-97ca-7288cde30a5a -machine pc,accel=kvm,kernel_irqchip,nvdimm -cpu host -qmp unix:/run/virtcontainers/pods/5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a/a9ea1387-5e7c-4c7,server,nowait -qmp unix:/run/virtcontainers/pods/5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a/a9ea1387-5e7c-4c7,server,nowait -m 2048M,slots=2,maxmem=65206M -device virtio-serial-pci,id=serial0 -device virtconsole,chardev=charconsole0,id=console0 -chardev socket,id=charconsole0,path=/run/virtcontainers/pods/5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a/console.sock,server,nowait -device nvdimm,id=nv0,memdev=mem0 -object memory-backend-file,id=mem0,mem-path=/usr/share/clear-containers/clear-19790-containers.img,size=235929600 -device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on -device virtserialport,chardev=charch0,id=channel0,name=sh.hyper.channel.0 -chardev socket,id=charch0,path=/run/virtcontainers/pods/5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a/hyper.sock,server,nowait -device virtserialport,chardev=charch1,id=channel1,name=sh.hyper.channel.1 -chardev socket,id=charch1,path=/run/virtcontainers/pods/5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a/tty.sock,server,nowait -device virtio-9p-pci,fsdev=extra-9p-hyperShared,mount_tag=hyperShared -fsdev local,id=extra-9p-hyperShared,path=/run/hyper/shared/pods/5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a,security_model=none -netdev tap,id=network-0,vhost=on,vhostfds=3:4:5:6:7:8:9:10,fds=11:12:13:14:15:16:17:18 -device driver=virtio-net-pci,netdev=network-0,mac=02:42:ac:11:00:02,mq=on,vectors=18 -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config -nodefaults -nographic -daemonize -kernel /usr/share/clear-containers/vmlinuz-4.9.60-82.container -append root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro rw rootfstype=ext4 tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k panic=1 console=hvc0 console=hvc1 initcall_debug iommu=off cryptomgr.notests net.ifnames=0 quiet systemd.show_status=false init=/usr/lib/systemd/systemd systemd.unit=clear-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket ip=::::::5359409043a5fd13d9898a37af0422907c811d24661b2c4cc4ae6ff6db1aea8a::off:: -smp 48,cores=48,threads=1,sockets=1 |
嗯？ qemu-lite-system-x86_64 是什么东西？Google 了一下，发现是 Intel 自己魔改的一个轻量级 QEMU 。
这时想起了 Intel Clear Container 吹的：
Clear Containers boot time and memory footprint are significantly optimized by using a specific QEMU version called qemu-lite
虽然它的默认 machine type 为 pc ，但可以指定为 pc-lite：
In the past pc-lite was utilized which provided the following improvements: Removed many of the legacy hardware devices support so that the guest kernel does not waste time initializing devices of no use for containers. Skipped the guest BIOS/firmware and jumped straight to the Clear Containers kernel.
整体架构是：
| (connect) | |
| docker - containerd - containerd-shim - cc-shim - cc-proxy - | |
| (create) | |
| cc-runtime - QEMU-lite - KVM - VM(cc-agent) |
看了 18 年 11 月份 Hyper.sh 在 OpenStack Summit 上的演讲，对该项目有了更多的了解，在此更新一发。
相比 gVisor，Kata 本质上还是跑 KVM 虚拟机，因此能够利用 QEMU-KVM 的诸多优化如 IO 能 Passthrough 或用 Vhost 系列等，IO 性能更好：
runV 和 clear container 启动的 Guest 会暴露出 socket ，供 docker ，更准确来说是 runtime 进行管理。
它们都使用了自己的 kernel 和 initrd ，目的是加快启动速度。同时，都使用了 virtio 来提高 IO 设备的效率。
在模拟机器的类型选择上，runV 用的是 pc-i440fx ，而 clear container 默认为 pc，目前两者对 Q35 的支持还不完善。
Kata Containers 合并了 Intel Clear Containers 和 Hyper runV 两个项目，强强联手，代表了虚拟机容器阵营的前进方向。
希望在未来能够解决这两个项目当前的 Limitations ，期待有一天能达到或者接近容器的性能，又快又方便又安全，岂不美哉！
标签：没有 app ubunt utc pos ima safe hat ssl
原文地址：https://www.cnblogs.com/dream397/p/13787128.html
