【摘要】不管公有云仍是私有云厂商，都认识到了将虚拟化的隔离性和容器的高效运维特性相结合，是云原平生台发展的必然趋势。
容器是如何解决隔离问题的
众所周知，容器技术的出现有两个关键缘由：node
1. 软件运行过程当中的资源和环境的隔离。linux
2. 软件由于运行环境多样带来的打包和配置的复杂性。git
而对于软件运行环境的隔离需求，从计算机出现之初就已经开始了，多任务分时操做系统和虚拟地址的引入，都是为了解决多个任务在同一主机上运行，而且让任务自己认为本身独占机器。固然这样的隔离是远远不够的，当今软件，根据不一样的层级，能够将隔离技术分为如下三类：github
1. 进程级别的隔离docker
2. 操做系统级别的隔离shell
3. 虚拟化级别的隔离安全
操做系统以进程做为程序运行过程的抽象，进程拥有独立的地址空间，进程的执行依靠操做系统的调度。可是进程共享了文件系统，函数库等资源，程序之间出现互相干扰的可能性很大。这个层级的隔离适合在相同主机上运行单个用户的不一样程序，由用户本身保证程序之间的资源分配。网络
上世纪70年代出现了chroot，进行文件系统的隔离，21世纪初开始，随着计算硬件的性能提高，软件隔离的需求更增强烈，这时候开始出现如jail，cgroup，namespace等各类不一样资源的隔离技术。咱们将这些技术统一划分到操做系统的隔离技术，这类隔离技术能够实现软件在诸如硬件资源、文件系统、网络、进程号等方面的隔离，可是不一样的应用依然是运行在相同的操做系统内核上，对于恶意的利用漏洞攻击的场景，这种隔离技术依然会捉襟见肘。可是这种级别的隔离带来的额外资源消耗较小，适合相同的组织内不一样用户的应用在相同主机上运行。架构
虚拟化技术的出现，让相同的物理机上也能运行多个不一样的操做系统。操做系统对硬件的接口，由虚拟机管理程序(VMM)负责模拟。运行在不一样系统中的程序，内核也是隔离的。硬件资源则经过各类硬件辅助手段进行划分，虚拟机上的程序很难突破虚拟化层加上的资源限制。而且由于内核的隔离，资源的可见性也作到了很强的隔离性。即便是恶意的用户，也很难突破这层虚拟化的限制，已达到攻击物理机，或者相同主机上其余虚拟机的目的。框架
以上三种隔离是按照层级一步一步增强的，同时带来的理论损耗也是逐步递进的。虚拟化因为须要模拟各类设备，带来的资源损耗比其余两种隔离方式要大不少。
什么是“安全容器”
容器概念出来的时候，最初你们作隔离的思路，几乎都是操做系统级的隔离，也就是基于内核提供的namespace、cgroup、seccomp等机制，实现容器内的资源、文件、系统调用等限制和隔离。这种隔离方式更加高效，损耗更小。可是随着容器的大规模使用，尤为是各类容器编排系统，如k8s的深刻使用，人们逐渐发现这样的隔离级别每每不能知足要求。在公有云场景下，相同主机若是须要运行不一样租户的应用，由于这种隔离级别依然采用了共内核的机制，存在这普遍的攻击面，容器的隔离级别彻底不能知足要求。因此最初的公有云上的容器服务，都是配合虚拟机的使用来完成的，首先是用户须要建立一批虚拟机做为运行容器的节点，造成一个私有的集群，而后才能在其上建立容器应用。虚拟化级别的隔离已经被各类公有云的实践证实，是一种安全的隔离技术。
自从云计算的概念提出开始，虚拟机一直是云平台的基础，不管是平台自己服务仍是用户的使用，都是从IaaS平台建立通用虚拟机开始的。通常都是建立相应的规格的虚拟机，使用一个完成操做系统镜像启动一个完整的操做系统，随后在其安装，配置，运行软件和服务。包括咱们上节提到的公有云容器服务的提供形式也是如此。
虚拟化自己带来的隔离能力是受到广泛承认的，不过IaaS层但愿提供的是一个和应用彻底无关的基础设施层，它几乎彻底不感知应用的任何信息。因而从基础设施到应用运维，中间巨大的鸿沟则是由PaaS和用户本身来填平，这中间依然须要耗费无数的人力和成本。通用的虚拟机服务诚然有它的好处，好比完整的操做系统很适合程序调试，或者做为工做办公环境等等。可是对于多数运行于云平台的软件，它须要的是它独有的运行环境，它的运行环境由它的镜像已经彻底定义好了。若是在此以外，又启动一个完整的操做系统，既浪费资源，也增长了运维的成本。为何不能直接将虚拟化级别的隔离引入到容器技术中呢？结合虚拟化的安全性和容器在软件生命周期管理方面的优点，是否是能够给软件开发运维带来巨大的便利呢？
也就是在这个时间，docker和coreos等一块儿成立了OCI组织，其目的是将容器的运行时和镜像管理等流程标准化。OCI标准定义了一套容器运行时的命令行接口和文件规范，docker将其RunC捐给OCI做为运行时标准的一个参考实现。2015年Hyper.sh开源了RunV，则是一种基于虚拟化的容器运行时接口的实现，它很好地结合了虚拟化的安全性和容器的便利性。后来RunV和ClearContainer合并成立了kata项目，kata提供了更加完整的基于虚拟化的容器实现。咱们把这种基于虚拟化的容器实现称做安全容器。
除kata以外，还相继出现了多个安全容器的实现方式，好比google的gVisor、AWS的firecracker-containerd、IBM的Nabla、VMware的CRX等等，其原理不尽相同，但共同反应了一个趋势，就是将容器的便利和虚拟化的安全隔离结合起来，让虚拟化直接和应用运维结合，成为云原生技术的大势所趋。下面对这些“安全容器”的实现技术进行简要的介绍和对比。
Google gVisor
相比于其余几种实现，gVisor的显著不一样之处在于，它经过拦截容器中应用的系统调用，模拟了一个操做系统内核，所以gVisor实际上没有虚拟化，而是在用户态实现了一个操做系统。这种方式能够下降由于虚拟化带来的模拟设备内存损耗。gVisor提供的runsc符合OCI标准，能够直接对接docker、containerd等容器平台，同时它也彻底兼容docker的镜像格式。可是因为不是一个标准linux内核，由于应用的兼容性有较大问题。另外拦截系统调用带来的巨大的性能损耗也是阻止其普遍使用的一个阻碍。
IBM nabla
nabla是继承于unikernel的隔离方式，应用采用rumprun打包成一个unikernel镜像，直接运行在一个专为运行unikernel定制虚拟机(ukvm)中。应用直接打包首先能够下降不少内核态和用户态转换的开销，另外经过ukvm暴露很是有限的主机上的syscall(只剩7个)，能够大大缩小主机的攻击面。它是这些安全容器实现中，最安全的。不过因为它要求应用打包成unikernel镜像，所以和当前docker的镜像标准是不兼容的。另外，unikernel应用在诸如支持建立子进程等一些常规操做上都有很难解决的问题。
AWS Firecracker
最初firecracker是为AWS的Lambda打造的高密度轻量级虚拟化组件。因为它是从头开始构建虚拟化，带着轻量化的目的，所以他抛掉了qemu这种通用虚拟化组件的大部分功能，只留下运行容器和Function必要的一些模拟设备。所以它的内存开销很是小（小于5M），启动速度很是快（小于125ms），一秒钟能够在一个节点上运行150个轻量级虚拟机。
为了让firecracker-microvm更好的运行容器，AWS启动了firecracker-containerd项目，firecracker-containerd是containerd-shim-v2的一个实现，不符合OCI标准，可是能够直接对接containerd启动容器，也就很容易经过containerd对接k8s的CRI接口。containerd-shim-v2是containerd定义的新的runtime接口，它是对最初shim-v1的一个简化，能够大大精简runtime的组件和内存使用。containerd是一个全插件化的代码框架，扩展性很是好。firecracker-containerd在该框架下，实现了一个snapshotter做为镜像插件，负责块设备镜像的生成；实现了一个shim-v2的runtime，负责容器的生命周期管理。另外还有个fc-control-plugin做为虚拟机的管理插件，提供grpc接口供runtime调用。在轻量级虚拟机内部，有一个agent负责监听runtime传进来的vsock，接收runtime的指令进行虚机内部真正的容器生命周期管理操做，它是直接调用runc来管理容器的。
图片来自https://github.com/firecracker-microvm/firecracker-containerd/blob/master/docs/architecture.md
VMware CRX
VMware发布的vSphere 7与kubernetes进行了融合，它利用k8s的CRD将其集群的虚拟机、容器、函数等运行实体管理的全部功能都集成到了k8s中。VMware是一个作虚拟化起家的公司，所以虚拟化做为它的老本行，这块的积累是很深厚的。它将虚拟化融合到它的容器runtime CRX中，所以和firecracker-containerd和kata相似，也是一个基于轻量级虚拟化的容器runtime的实现。经过对其虚拟化组件和guest内核的精简，CRX 容器一样作到了很低的内存损耗(20MB)、快速(100ms)的启动以及高密度部署(单个节点大于1000个pod)。
图片来自https://cormachogan.com/2019/11/22/project-pacific-vmworld-2019-deep-dive-updates/
vSphere对node上的kubelet组件改造比较大，节点上的Spherelet部分功能和kubelet重合，负责pod的生命周期管理（他们称之为Native Pod），运行在虚拟机中的SphereletAgent则集成了符合OCI接口规范的libcontainer，实现容器的生命周期管理，以及容器的监控日志采集、容器的shell登陆(kubectl exec)。Spherelet和虚机中的SphereletAgent交互实现相似于kubelet使用CRI接口管理pod的效果。
kata containers
相比于以上几种，kata containers 最大的特色是它专一于实现一个开放的符合OCI标准的安全容器runtime实现，对于对接什么样的虚拟化方案，它抽象了一套hypervisor接口，现在已经对接了多种虚拟化实现，好比qemu、nemu、firecracker、cloud-hypervisor等等。
图片来自https://katacontainers.io/
经过containerd-shim-v2和vsock技术，kata精简了大量的组件，配合轻量级hypervisor和精简内核，kata能够作到将额外内存消耗下降到10MB如下。容器启动时间下降到100ms如下。后续还会经过rust语言重写等方式，提供更低内存额外消耗。
图片来自https://github.com/kata-containers/documentation/blob/master/design/architecture.md
现有安全容器技术对比
安全容器技术发展趋势
随着Serverless等技术的兴起，应用部署和运维工做已经下沉到云平台上，人们须要一个更加高效的云原生技术平台。从这几年涌现的安全容器实现技术能够观察到，不管公有云仍是私有云厂商，都认识到了将虚拟化的隔离性和容器的高效运维特性相结合，是云原平生台发展的必然趋势。结合当前安全容器实现中遇到的一些问题，咱们能够预见到，将来这项技术发展的几个走向：
1. 须要一个为安全容器而生的轻量级hypervisor，当前qemu+kvm是主流的虚拟化技术，但由于qemu是为通用的虚拟机而设计的，其体量过于庞大，而对于安全容器而言，一个模块化可定制的虚拟化实现尤其重要。若是结合gVisor和nabla的实现来看，内核的可定制性也是安全容器场景的必然要求。rust-vmm便是这样一种模块化的虚拟化组件库。linux内核自己的模块化特性能够部分知足容器场景下的内核定制需求，不过也许像gVisor那样实现一个专为容器而生的内核也许是将来的趋势。
2. 容器的启动时间是衡量一个云原平生台效率的重要指标，尤为是在Serverless场景下，程序运行时间自己可能很短，这时候启动时间可能占用了其绝大部分，那么这种低效就显得尤其明显。安全容器经过极致的轻量化，能够将容器启动时间下降到100ms如下，可是容器镜像拉取时间过长还是当前容器部署过程当中的一个短板。因为当前容器镜像格式和镜像挂载方式等方面的限制，须要在启动容器以前将容器镜像拉取到本地之后，才能启动容器。而容器启动自己须要的数据只占镜像的6%左右。所以咱们亟需一个高效的镜像挂载方式，当前已经有一些免下载和懒加载（Lazy-Loading）的技术原型，后续须要尽快推出一个可商用的镜像下载加速方案。
3. 当前公有云的网络广泛采用原IaaS的网络管理模式，在地址分配，网络配置效率等方面彻底赶不上容器快速启停的需求，docker容器采用的veth方式在性能等方面也很难知足高效转发的要求。所以须要一个专为云原生设计的网络管理方案。
4. 咱们看到云平台对应用的管理逐步深刻，从只管理基础设施的IaaS层，发展到管理应用总体部署和运维的PaaS，再到现在服务网格（Service Mesh）技术将平台管理能力深刻到应用内部的微服务级别。同时咱们也看到，以K8s容器、Istio服务网格为表明的云原生技术已经和下层的计算/网络虚拟化等技术逐步整合到了一块儿，好比安全容器便是容器与计算虚拟化的结合，而Istio服务网格也会与虚拟化网络进行深度整合以提供更高的性能与更精细的QoS控制。
5. 当前硬件加速技术在AI和大数据等领域大行其道，安全容器须要与各类计算加速硬件技术进行结合，使得AI、大数据、科学计算等批量计算领域的用户能够利用云平台直接投递其海量的计算任务，可大大下降他们在底层技术上的心智负担。经过硬件加速也是提高云平台自己效率、下降云平台运行成本的有效手段。好比华为云擎天架构在硬件加速方面拥有的技术优点在“安全容器”领域已获得充分的证实，CCE Turbo裸金属容器已经实现了安全容器的部分硬件卸载能力。
总结
将来必然是云原生技术大行其道的时代，咱们已经看到不少传统行业也逐渐认识到云原生技术能够给传统企业的IT软件，工业自动化，线上运维和数据管理等带来明显的效率提高。咱们将看到经过对底层硬件和上层服务的全栈整合，打造出一个高效智能的云计算技术平台，而这中间，容器将是串联整个技术栈的关键所在。