我们说了kubelet和CRI的设计和具体工作原理,讲解CRI的诞生,也因此一些虚拟化或者独立内核的安全容器项目也会逐渐的成熟
使用虚拟化技术来做一个Docker一样的容器项目,并不新鲜,在Docker项目发布时候,Google就这么做了,这是试图使用常规虚拟化技术来运行的一个尝试,但并没有继续发展下去,而是选择了放弃
但是这次开源还是给了不少第三方公司灵感,于是再后来推出了Kate Containers项目,其特点就是,像虚拟机一样安全,像容器一样敏捷.
而Google公司后来,又发布了一个名为gVisor的项目,gVisor项目给容器进程配置了一个用Go语言实现的,运行在用户态的极小的独立内核,这个内核对容器进程暴露Linux内核ABI,扮演着Guest Kernel的角色,从而将容器和宿主机隔离开了
不管是Kata Container,还是gVisor,都是给容器创建了一个独立的操作系统内核,从而避免了让容器共享宿主机的内核,这样容器进程能够看到的就不是真实的宿主机内核,而是一个独立的,极小的,以容器为单位的内核,有效解决了容器进程发生逃逸或者夺取宿主机控制权的问题
Kate Container和gVisor两者之间的不同,就是在于实现这个独立的内核
Kate Container使用的是传统的虚拟化技术,通过虚拟硬件模拟出了一个小型的虚拟机,然后,在小虚拟机里面安装了一个裁剪后的Linux内核来进行隔离实现
而gVisor则是用Go模拟出了一个运行在用户态的操作系统内核,然后通过这个模拟的内核就代替容器进程向宿主机发起调用
接下来分别看下KateContainer和gVisor的实现原理
首先是Kate Containers,工作原理如下所示
Kate Containers本质就是一个轻量化的虚拟机,所以启动一个Kate Containers之后,就会看到一个正常的虚拟机在运行,这意味着,必然会有一个标准的虚拟机管理程序 VMM 来进行运行管理这些轻量级的虚拟机,在具体实现上,Kate Containers的虚拟机里会有特殊的Init进程负责管理管理虚拟机里面的用户容器,并且为这些容器设置好对应的Mount Namesapce,并且由于虚拟机的
特殊性,所以原生就是共享Network和Namespace的
所以,具体的架构中,Kate Container实现方式和一个正常的虚拟机很相似,具体的原理图如下
Kata Containers运行起来后,虚拟机里的用户容器,只会看到虚拟机中的,被裁剪的Guest Kernel,以及通过Hypervisor虚拟出来的硬件设备
为了可以对这个IO进行优化,Kata Containers通过vhost技术来实现Guest和Host之间高效的通信,并且使用PCI技术来让Guest里的进程直接访问到宿主机上的物理设备
而gVisor的实现则更加激进些,为应用程序,用户容器,启动了一个名为Sentry的进程,主要的职责,就是提供一个传统的操作系统的内核能力,运行用户的程序,执行系统调用所以Sentry实际上就是一个对应用进程冒充内核的系统组件
这就导致Sentry需要自己实现一个Linux网络栈,处理应用的外部处理请求,以便处理应用进程的通信请求,然后发给真正的Kubernetes的网络组件
此外,Sentry对Volume的操作,需要一个协议,名为9p,交给一个名为Gofer的代理进程完成,从而代理应用来完成对宿主机上的文件操作
而且,在Sentry之中,也有着多种的实现方式,去拦截处理
比如,第一种实现方式,就是通过Ptrace机制来拦截用户应用的系统调用,然后将其交给Sentry来处理,这个过程是让Sentry扮演系统函数的实现则,但是这种调用拦截的性能太差了
第二种方式,更加普适性,工作原理则是这种实现,Sentry进行KVM进行系统调用的拦截,这个性能更好,为了能够做到这一点,Sentry就需要扮演一个Guest Kernel的角色,负责进行执行用户的调用,将用户进程发起的请求,进行一些处理,从而去完成实际系统的调用,比如处理地址空间切换等细节
在Google内部,使用的就是第二种基于Hypervisor的gVisor
所以通过上述讲述,相信对Kate Containers和gVisor的实现就有了基本的认识,而且看出gVisor的实现并不是很完善,性能不是很好,当然有着Google的技术支持,这些问题会逐一被解决
AWS在2018年末发布了一个Firecracker的安全容器的项目,这个项目的核心,就是一个Rust语言写的VMM,虚拟机管理器,这就是和Kata Containers的本质原理,其实是一样的,不过Kata Containers默认的是Qemu,而Firecracker,使用的是自己编写的VMM
本章中,我们对比了KateContainers和gVisor的设计和实现一些
性能上,在启动速度和资源占用上gVisor略胜一筹,但是对于IO或者网络频繁使用的应用,gVisor就会因为频繁拦截系统调用而出现性能下降的问题
但是虽然gVisor没有任何优势,但是这种通过用户态运行一个操作系统的内核,是一种未来容器演化的趋势
那么思考下,如果宿主机的Linux内核的版本是3.6,容器要求使用4.0,是否能够运行在KateContainers中,是否能够运行在gVisor中?
不能运行在gVisor中,gVisor本质上是委托给了实际的宿主机内核去执行,有些高版本的api,低版本再如何也无法实现