强隔离容器的那些事

为什么需要强隔离容器

我们在生产环境中运行容器已久，第一次对强隔离容器诉求是java类应用引起的，如果不配置jvm参数，java虚拟机会根据系统资源信息进行内存gc线程数等配置，在不给容器配额的情况下问题不大，一旦配额了。。。

普通的容器在容器中看到的资源还是宿主机的资源，那么假设宿主机128G而你给容器配额2G，此时堆内存按照128G去分，可想而知后果，同理还有gc线程数等
<!--more-->

给jvm配置参数就行了呗

我们很难改变用户行为，让用户都去改动参数不太现实。

lxcfs一定程度上解决了这个问题

lxcfs可以让容器有更好的资源可视性，如内存，cpuset等，原理也非常简单，就是把proc下的一些文件还在给容器，容器内进程读取资源信息时系统调用会被lxcfs拦截，然后到cgroup下去查该进程资源配额信息进行计算，大部分场景可以通过这个方式修修补补

然鹅，lxcfs的缺陷

第一，支持lxcfs的运行时甚少
第二，用户使用时不透明，需要自行挂载很多文件不友好
第三，由于第二点，你就得去开发一些特性去支持它，主流方式有几种

1.k8s上监听一些对象的创建，进行修改
2.修改kubelet，在volume里默认加上，我们就是这样做的，正在把这个特性PR给社区
3.修改runtime，或者直接选择支持这个特性的运行时，如pouch

第四，cpushare的方式，我们也正在把这个特性pr给社区，通过计算占比把计算后的cpu核数上报给进程
第五，很多应用从system下面去读取资源信息，而非proc，这样又是一大波定制需求。。。还有remout等等问题

总体来说都是修修补补，不能从彻底上解决问题

这让我越来越看好轻量级虚拟化技术

kata runv等技术的出现真的是把虚拟机容器的优势强强结合，容器的调度编排管理生态，镜像标准，再加上虚拟机的强隔离

下面开始一大波名词解释以及他们之间的关系

containerd地位难以撼动，真正管理容器的守护进程，k8s和docker都可以通过unix socket去调用它，然后每起一个容器containerd会去调用runc runv kata等

kata runv qemu firecracker rust-vmm都是啥关系

kata和runv都是可以被containerd调用然后调用qemu命令去启动虚拟机

qemu 和firecracker是一个级别，真正去启动虚拟机的，和张磊大佬交流时这里引用大佬一句话:qemu是在一大坨功能上做减法，firecracker是在非常核心简单的功能上做加法。

那么我们到底因该选qemu还是firecracker呢，那肯定是与场景相关了，比如我们希望用重量级虚拟机，有状态，需要迁移，需要systemd sshd等，那么肯定还是走qemu libvirt， 如果我们走轻量级虚拟机firecracker是个非常不错的选择，而且潜力巨大，毕竟是来跑亚马逊函数计算的，不是盖的。看下firecracker api就发现真简单，再去看qemu文档。。。。什么**鸟玩意儿。。。

qemu大神别喷我，我承认其强大，但是很多时候遇到问题有点无从下手，很多使用方法我也是从源码中摸索出来的，个人还是喜欢更轻量级的东西。不过我依然还是对学习qemu有很大热情。

顺便提一下libvirt，既然重，那不如再重一点，libvirt能让你更方便的管理qemu虚拟机和qemu开发，细节不赘述了

rust-vmm是个更底层的一系列组件，大佬说是政治产物，自己如果对写hypervisor有兴趣可以抱着学习态度去开发玩，生产中直接firecracker就好了，所以rust的潜力还是巨大的，为了写虚拟机为了写操作系统，和我一起学rust