当前位置：首页 > news >正文

沙箱虚拟化技术虚拟机容器之间的关系详解

news 2025/6/10 7:41:08

问题

沙箱、虚拟化、容器三者分开一一介绍的话我知道他们各自都是什么东西，但是如果把三者放在一起，它们之间到底什么关系？又有什么联系呢？我不是很明白！！！

就比如说：

沙箱（sandbox），在计算机安全领域中是一种安全机制，为运行中的程序提供的隔离环境。进行恶意程序的动态分析时，需要将恶意程序放在沙箱中运行，通过观察恶意程序在运行的过程中产生的恶意行为，进一步达到检测恶意程序的目的。

虚拟化技术，它是一种抽象中间层，将任何一种形式的资源抽象成另一种形式的技术都是虚拟化。虚拟化是资源的逻辑表示，其不受物理限制的约束。

容器，又叫容器虚拟化技术，它是一种更加轻量级的虚拟化技术。

但是他们三者之间有什么关系呢？下面我们来探讨一下

从虚拟化到容器的发展史

1979年，Unix v7系统支持chroot，为应用构建一个独立的虚拟文件系统视图。

1999年，FreeBSD 4.0支持jail，第一个商用化的OS虚拟化技术。

2004年，Solaris 10支持Solaris Zone，第二个商用化的OS虚拟化技术。

2005年，OpenVZ发布，非常重要的Linux OS虚拟化技术先行者。

2004年 ~ 2007年，Google 内部大规模使用 Cgroups 等的OS虚拟化技术。

2006年，Google开源内部使用的process container技术，后续更名为cgroup。

2008年，Cgroups 进入了 Linux 内核主线。

2008年，LXC（Linux Container）项目具备了Linux容器的雏型。

2011年，CloudFoundry开发Warden系统，一个完整的容器管理系统雏型。

2013年，Google通过Let Me Contain That For You (LMCTFY) 开源内部容器系统。

2013年，Docker项目正式发布，让Linux容器技术逐步席卷天下。

2014年，Kubernetes项目正式发布，容器技术开始和编排系统起头并进。

2015年，由Google，Redhat、Microsoft及一些大型云厂商共同创立了CNCF，云原生浪潮启动。

2016年-2017年，容器生态开始模块化、规范化。CNCF接受Containerd、rkt项目，OCI发布1.0，CRI/CNI得到广泛支持。

2017年-2018年，容器服务商业化。AWS ECS，Google EKS，Alibaba ACK/ASK/ECI，华为CCI，Oracle Container Engine for Kubernetes；VMware，Redhat和Rancher开始提供基于Kubernetes的商业服务产品。

2017年-2019年，容器引擎技术飞速发展，新技术不断涌现。2018年底Kata Containers社区成立，2018年5月Google开源gVisor代码，2018年11月AWS开源firecracker，阿里云发布安全沙箱1.0。

2020年-202x年，容器引擎技术升级，Kata Containers开始2.0架构，阿里云发布沙箱容器2.0....

何谓虚拟化技术

1961 年 —— IBM709 机实现了分时系统

计算机历史上首个虚拟化技术实现于 1961 年，IBM709 计算机首次将 CPU 占用切分为多个极短 (1/100sec) 时间片，每一个时间片都用来执行着不同的任务。通过对这些时间片的轮询，这样就可以将一个 CPU 虚拟化或者伪装成为多个 CPU，并且让每一颗虚拟 CPU 看起来都是在同时运行的。这就是虚拟机的雏形。

容器的功能其实和虚拟机类似，无论容器还是虚拟机，其实都是在计算机不同的层面进行虚拟化，即使用逻辑来表示资源，从而摆脱物理限制的约束，提高物理资源的利用率。虚拟化技术是一个抽象又内涵丰富的概念，在不同的领域或层面有着不同的含义。

计算机系统对于大部分软件开发者来说可以分为以下层级结构：

应用程序层

函数库层

操作系统层

硬件层

各层级自底向上，每一层都向上提供了接口，同时每一层也只需要知道下一层的接口即可调用底层功能来实现上层操作（不需要知道底层的具体运作机制）。

但由于早期计算机厂商生产出来的硬件遵循各自的标准和规范，使得操作系统在不同计算机硬件之间的兼容性很差；同理，不同的软件在不同的操作系统下的兼容性也很差。于是，就有开发者人为地在层与层之间创造了抽象层：

应用层函数库层 API 抽象层 操作系统层 硬件抽象层 硬件层

就我们探讨的层面来说，所谓虚拟化就是在上下两层之间，人为地创造出一个新的抽象层，使得上层软件可以直接运行在新的虚拟环境上。简单来说，虚拟化就是通过模访下层原有的功能模块创造接口，来“欺骗”上层，从而达到跨平台开发的目的。

综合上述理念，我们就可以重新认识如今几大广为人知的虚拟化技术：

虚拟机：存在于硬件层和操作系统层间的虚拟化技术。

虚拟机通过“伪造”一个硬件抽象接口，将一个操作系统以及操作系统层以上的层嫁接到硬件上，实现和真实物理机几乎一样的功能。比如我们在一台 Windows 系统的电脑上使用 Android 虚拟机，就能够用这台电脑打开 Android 系统上的应用。

容器：存在于操作系统层和函数库层之间的虚拟化技术。

容器通过“伪造”操作系统的接口，将函数库层以上的功能置于操作系统上。以 Docker 为例，其就是一个基于 Linux 操作系统的 Namespace 和 Cgroup 功能实现的隔离容器，可以模拟操作系统的功能。简单来说，如果虚拟机是把整个操作系统封装隔离，从而实现跨平台应用的话，那么容器则是把一个个应用单独封装隔离，从而实现跨平台应用。所以容器体积比虚拟机小很多，理论上占用资源更少。

JVM：存在于函数库层和应用程序之间的虚拟化技术。

Java 虚拟机同样具有跨平台特性，所谓跨平台特性实际上也就是虚拟化的功劳。我们知道 Java 语言是调用操作系统函数库的，JVM 就是在应用层与函数库层之间建立一个抽象层，对下通过不同的版本适应不同的操作系统函数库，对上提供统一的运行环境交给程序和开发者，使开发者能够调用不同操作系统的函数库。

在大致理解了虚拟化技术之后，接下来我们就可以来了解容器的诞生历史。虽然容器概念是在 Docker 出现以后才开始在全球范围内火起来的，但在 Docker 之前，就已经有无数先驱在探索这一极具前瞻性的虚拟化技术。

容器的前身 “Jail”

1979 年 —— 贝尔实验室发明 chroot

容器主要的特性之一就是进程隔离。早在 1979 年，贝尔实验室在 Unix V7 的开发过程中，发现当一个系统软件编译和安装完成后，整个测试环境的变量就会发生改变，如果要进行下一次构建、安装和测试，就必须重新搭建和配置测试环境。要知道在那个年代，一块 64K 的内存条就要卖 419 美元，“快速销毁和重建基础设施”的成本实在是太高了。

开发者们开始思考，能否在现有的操作系统环境下，隔离出一个用来重构和测试软件的独立环境？于是，一个叫做 chroot （Change Root）的系统调用功能就此诞生。

chroot 可以重定向进程及其子进程的 root 目录到文件系统上的新位置，也就是说使用它可以分离每个进程的文件访问权限，使得该进程无法接触到外面的文件，因此这个被隔离出来的新环境也得到了一个非常形象的命名，叫做 Chroot Jail （监狱）。之后只要把需要的系统文件一并拷贝到 Chroot Jail 中，就能够实现软件重构和测试。这项进步开启了进程隔离的大门，为 Unix 提供了一种简单的系统隔离功能，尤其是 jail 的思路为容器技术的发展奠定了基础。但是此时 chroot 的隔离功能仅限于文件系统，进程和网络空间并没有得到相应的处理。

进入 21 世纪，此时的虚拟机（VM）技术已经相对成熟，人们可以通过虚拟机技术实现跨操作系统的开发。但由于 VM 需要对整个操作系统进行封装隔离，占用资源很大，在生产环境中显得太过于笨重。于是人们开始追求一种更加轻便的虚拟化技术，众多基于 chroot 扩展实现的进程隔离技术陆续诞生。

2000 年 —— FreeBSD 推出 FreeBSD Jail

在 chroot 诞生 21 年后，FreeBSD 4.0 版本推出了一套微型主机环境共享系统 FreeBSD Jail，将 chroot 已有的机制进行了扩展。在 FreeBSD Jail 中，程序除了有自己的文件系统以外，还有独立的进程和网络空间，Jail 中的进程既不能访问也不能看到 Jail 之外的文件、进程和网络资源。

2001 年 —— Linux VServer 诞生

2001 年，Linux 内核新增 Linux VServer （虚拟服务器），为 Linux 系统提供虚拟化功能。Linux VServer 采取的也是一种 jail 机制，它能够划分计算机系统上的文件系统、网络地址和内存，并允许一次运行多个虚拟单元。

2004 年 —— SUN 发布 Solaris Containers

该技术同样由 chroot 进一步发展而来。2004 年 2 月，SUN 发布类 Unix 系统 Solaris 的 10 beta 版，新增操作系统虚拟化功能 Container，并在之后的 Solaris 10 正式版中完善。Solaris Containers 支持 x86 和 SPARC 系统，SUN 创造了一个 zone 功能与 Container 配合使用，前者是一个单一操作系统中完全隔离的虚拟服务器，由系统资源控制和 zones 提供的边界分离实现进程隔离。

2005 年 —— OpenVZ 诞生

类似于 Solaris Containers，它通过对 Linux 内核进行补丁来提供虚拟化、隔离、资源管理和状态检查 checkpointing。每个 OpenVZ 容器都有一套隔离的文件系统、用户及用户组、进程树、网络、设备和 IPC 对象。

这个时期的进程隔离技术大多以 Jail 模式为核心，基本实现了进程相关资源的隔离操作，但由于此时的生产开发仍未有相应的使用场景，这一技术始终被局限在了小众而有限的世界里。

就在此时，一种名为“云”的新技术正悄然萌发……

“云”的诞生

2003 年至 2006 年间，Google 公司陆续发布了 3 篇产品设计论文，从计算方式到存储方式，开创性地提出了分布式计算架构，奠定了大数据计算技术的基础。在此基础上，Google 颠覆性地提出“Google 101”计划，并正式创造“云”的概念。一时间，“云计算”、“云存储”等全新词汇轰动全球。随后，亚马逊、IBM 等行业巨头也陆续宣布各自的“云”计划，宣告“云”技术时代的来临。

也是从这时期开始，进程隔离技术进入了一个更高级的阶段。在 Google 提出的云计算框架下，被隔离的进程不仅仅是一个与外界隔绝但本身却巍然不动的 Jail，它们更需要像一个个轻便的容器，除了能够与外界隔离之外，还要能够被控制与调配，从而实现分布式应用场景下的跨平台、高可用、可扩展等特性。

2006 年 —— Google 推出 Process Containers，后更名为 Cgroups

Process Container 是 Google 工程师眼中“容器”技术的雏形，用来对一组进程进行限制、记账、隔离资源（CPU、内存、磁盘 I/O、网络等）。这与前面提到的进程隔离技术的目标其实是一致的。由于技术更加成熟，Process Container 在 2006 年正式推出后，第二年就进入了 Linux 内核主干，并正式更名为 Cgroups，标志着 Linux 阵营中“容器”的概念开始被重新审视和实现。

2008 年 —— Linux 容器工具 LXC 诞生

在 2008 年，通过将 Cgroups 的资源管理能力和 Linux Namespace （命名空间）的视图隔离能力组合在一起，一项完整的容器技术 LXC （Linux Container）出现在了 Linux 内核中，这就是如今被广泛应用的容器技术的实现基础。我们知道，一个进程可以调用它所在物理机上的所有资源，这样一来就会挤占其它进程的可用资源，为了限制这样的情况，Linux 内核开发者提供了一种特性，进程在一个 Cgroup 中运行的情况与在一个命名空间中类似，但是 Cgroup 可以限制该进程可用的资源。尽管 LXC 提供给用户的能力跟前面提到的各种 Jails 以及 OpenVZ 等早期 Linux 沙箱技术是非常相似的，但伴随着各种 Linux 发行版开始迅速占领商用服务器市场，包括 Google 在内的众多云计算先锋厂商得以充分活用这一早期容器技术，让 LXC 在云计算领域获得了远超前辈的发展空间。

同年，Google 基于 LXC 推出首款应用托管平台 GAE （Google App Engine），首次把开发平台当做一种服务来提供。GAE 是一种分布式平台服务，Google 通过虚拟化技术为用户提供开发环境、服务器平台、硬件资源等服务，用户可以在平台基础上定制开发自己的应用程序并通过 Google 的服务器和互联网资源进行分发，大大降低了用户自身的硬件要求。

值得一提的是，Google 在 GAE 中使用了一个能够对 LXC 进行编排和调度的工具 —— Borg （Kubernetes 的前身）。Borg 是 Google 内部使用的大规模集群管理系统，可以承载十万级的任务、数千个不同的应用、同时管理数万台机器。Borg 通过权限管理、资源共享、性能隔离等来达到高资源利用率。它能够支持高可用应用，并通过调度策略减少出现故障的概率，提供了任务描述语言、实时任务监控、分析工具等。如果说一个个隔离的容器是集装箱，那么 Borg 可以说是最早的港口系统，而 LXC + Borg 就是最早的容器编排框架。此时，容器已经不再是一种单纯的进程隔离功能，而是一种灵活、轻便的程序封装模式。

2011 年 —— Cloud Foundry 推出 Warden

Cloud Foundry 是知名云服务供应商 VMware 在 2009 年推出的一个云平台，也是业内首个正式定义 PaaS （平台即服务）模式的项目，“PaaS 项目通过对应用的直接管理、编排和调度让开发者专注于业务逻辑而非基础设施”，以及“PaaS 项目通过容器技术来封装和启动应用”等理念都出自 Cloud Foundry。Warden 是 Cloud Foundry 核心部分的资源管理容器，它最开始是一个 LXC 的封装，后来重构成了直接对 Cgroups 以及 Linux Namespace 操作的架构。

随着“云”服务市场的不断开拓，各种 PaaS 项目陆续出现，容器技术也迎来了一个爆发式增长的时代，一大批围绕容器技术进行的创业项目陆续涌现。当然，后来的故事很多人都知道了，一家叫 Docker 的创业公司横空出世，让 Docker 几乎成为了“容器”的代名词。

Docker 横空出世

2013 年 —— Docker 诞生

Docker 最初是一个叫做 dotCloud 的 PaaS 服务公司的内部项目，后来该公司改名为 Docker。Docker 在初期与 Warden 类似，使用的也是 LXC ，之后才开始采用自己开发的 libcontainer 来替代 LXC 。与其他只做容器的项目不同的是，Docker 引入了一整套管理容器的生态系统，这包括高效、分层的容器镜像模型、全局和本地的容器注册库、清晰的 REST API、命令行等等。

Docker 本身其实也是属于 LXC 的一种封装，提供简单易用的容器使用接口。它最大的特性就是引入了容器镜像。Docker 通过容器镜像，将应用程序与运行该程序需要的环境，打包放在一个文件里面。运行这个文件，就会生成一个虚拟容器。

更为重要的是，Docker 项目还采用了 Git 的思路 —— 在容器镜像的制作上引入了“层”的概念。基于不同的“层”，容器可以加入不同的信息，使其可以进行版本管理、复制、分享、修改，就像管理普通的代码一样。通过制作 Docker 镜像，开发者可以通过 DockerHub 这样的镜像托管仓库，把软件直接进行分发。

也就是说，Docker 的诞生不仅解决了软件开发层面的容器化问题，还一并解决了软件分发环节的问题，为“云”时代的软件生命周期流程提供了一套完整的解决方案。

很快，Docker 在业内名声大噪，被很多公司选为云计算基础设施建设的标准，容器化技术也成为业内最炙手可热的前沿技术，围绕容器的生态建设风风火火地开始了。

容器江湖之争

一项新技术的兴起同时也带来了一片新的市场，一场关于容器的蓝海之争也在所难免。

2013 年 —— CoreOS 发布

在 Docker 爆火后，同年年末，CoreOS 应运而生。CoreOS 是一个基于 Linux 内核的轻量级操作系统，专为云计算时代计算机集群的基础设施建设而设计，拥有自动化、易部署、安全可靠、规模化等特性。其在当时有一个非常显眼的标签：专为容器设计的操作系统。

借着 Docker 的东风，CoreOS 迅速在云计算领域蹿红，一时间，Docker + CoreOS 成为业内容器部署的黄金搭档。同时，CoreOS 也为 Docker 的推广与社区建设做出了巨大的贡献。

然而，日渐壮大的 Docker 似乎有着更大的“野心”。不甘于只做“一种简单的基础单元”的 Docker，自行开发了一系列相关的容器组件，同时收购了一些容器化技术的公司，开始打造属于自己的容器生态平台。显然，这对于 CoreOS 来说形成了直接的竞争关系。

2014 年 —— CoreOS 发布开源容器引擎 Rocket

2014 年末，CoreOS 推出了自己的容器引擎 Rocket （简称 rkt），试图与 Docker 分庭抗礼。rkt 和 Docker 类似，都能帮助开发者打包应用和依赖包到可移植容器中，简化搭环境等部署工作。rkt 和 Docker 不同的地方在于，rkt 没有 Docker 那些为企业用户提供的“友好功能”，比如云服务加速工具、集群系统等。反过来说，rkt 想做的，是一个更纯粹的业界标准。

2014 年 —— Google 推出开源的容器编排引擎 Kubernetes

为了适应混合云场景下大规模集群的容器部署、管理等问题，Google 在 2014 年 6 月推出了容器集群管理系统 Kubernetes （简称 K8S）。K8S 来源于我们前面提到的 Borg，拥有在混合云场景的生产环境下对容器进行管理、编排的功能。Kubernetes 在容器的基础上引入了 Pod 功能，这个功能可以让不同容器之间互相通信，实现容器的分组调配。

得益于 Google 在大规模集群基础设施建设的强大积累，脱胎于 Borg 的 K8S 很快成为了行业的标准应用，堪称容器编排的必备工具。而作为容器生态圈举足轻重的一员，Google 在 Docker 与 rkt 的容器之争中站在了 CoreOS 一边，并将 K8S 支持 rkt 作为一个重要里程碑。

2015 年 —— Docker 推出容器集群管理工具 Docker Swarm

作为回应，Docker 公司在 2015 年发布的 Docker 1.12 版本中也开始加入了一个容器集群管理工具 Docker swarm 。

随后，Google 于 2015 年 4 月领投 CoreOS 1200 万美元，并与 CoreOS 合作发布了首个企业发行版的 Kubernetes —— Tectonic 。从此，容器江湖分为两大阵营，Google 派系和 Docker 派系。

两大派系的竞争愈演愈烈，逐渐延伸到行业标准的建立之争。

2015 年 6 月 —— Docker 带头成立 OCI

Docker 联合 Linux 基金会成立 OCI （Open Container Initiative）组织，旨在“制定并维护容器镜像格式和容器运行时的正式规范（“OCI Specifications”），围绕容器格式和运行时制定一个开放的工业化标准。

2015 年 7 月 —— Google 带头成立 CNCF

而战略目标聚焦于“云”的 Google 在同年 7 月也联合 Linux 基金会成立 CNCF （Cloud Native Computing Foundation）云原生计算基金会，并将 Kubernetes 作为首个编入 CNCF 管理体系的开源项目，旨在“构建云原生计算 —— 一种围绕着微服务、容器和应用动态调度的、以基础设施为中心的架构，并促进其广泛使用”。

这两大围绕容器相关开源项目建立的开源基金会为推动日后的云原生发展发挥了重要的作用，二者相辅相成，制定了一系列行业事实标准，成为当下最为活跃的开源组织。

Kubernetes 生态一统江湖

虽然这些年来 Docker 一直力压 rkt，成为当之无愧的容器一哥，但作为一个庞大的容器技术生态来说，Docker 生态还是在后来的容器编排之争中败给了 Google 的 Kubernetes 。

随着越来越多的开发者使用 Docker 来部署容器，编排平台的重要性日益突出。在 Docker 流行之后，一大批开源项目和专有平台陆续出现，以解决容器编排的问题。Mesos、Docker Swarm 和 Kubernetes 等均提供了不同的抽象来管理容器。这一时期，对于软件开发者来说，选择容器编排平台就像是一场豪赌，因为一旦选择的平台在以后的竞争中败下阵来，就意味着接下来开发的东西在未来将失去市场。就像当初 Android、iOS 和 WP 的手机系统之争一样，只有胜利者才能获得更大的市场前景，失败者甚至会销声匿迹。容器编排平台之争就此拉开帷幕。

2016 年 —— CRI-O 诞生

2016 年，Kubernetes 项目推出了 CRI （容器运行时接口），这个插件接口让 kubelet （一种用来创建 pod、启动容器的集群节点代理）能够使用不同的、符合 OCI 的容器运行时环境，而不需要重新编译 Kubernetes。基于 CRI ，一个名为 CRI-O 的开源项目诞生，旨在为 Kubernetes 提供一种轻量级运行时环境。

CRI-O 可以让开发者直接从 Kubernetes 来运行容器，这意味着 Kubernetes 可以不依赖于传统的容器引擎（比如 Docker ），也能够管理容器化工作负载。这样一来，在 Kubernetes 平台上，只要容器符合 OCI 标准（不一定得是 Docker），CRI-O 就可以运行它，让容器回归其最基本的功能 —— 能够封装并运行云原生程序即可。

同时，CRI-O 的出现让使用容器技术进行软件管理和运维的人们发现，相对于 Docker 本身的标准容器引擎， Kubernetes 技术栈（比如编排系统、 CRI 和 CRI-O ）更适合用来管理复杂的生产环境。可以说，CRI-O 将容器编排工具放在了容器技术栈的重要位置，从而降低了容器引擎的重要性。

在 K8S 顺利抢占先机的情况下，Docker 在推广自己的容器编排平台 Docker Swarm 时反而犯下了错误。2016 年底，业内曝出 Docker 为了更好地适配 Swarm，将有可能改变 Docker 标准的传言。这让许多开发者在平台的选择上更倾向于与市场兼容性更强的 Kubernetes 。

因此，在进入 2017 年之后，更多的厂商愿意把宝压在 K8S 上，投入到 K8S 相关生态的建设中来。容器编排之争以 Google 阵营的胜利告一段落。与此同时，以 K8S 为核心的 CNCF 也开始迅猛发展，成为当下最火的开源项目基金会。这两年包括阿里云、腾讯、百度等中国科技企业也陆续加入 CNCF ，全面拥抱容器技术与云原生。

结语

从数十年前在实验室里对进程隔离功能的探索，再到如今遍布生产环境的云原生基础设施建设，可以说容器技术凝聚了几代开发者的心血，才从一个小小的集装箱发展到一个大型的现代化港口。可以预见的是，从现在到未来很长一段时间里，容器技术都将是软件开发和运维的重要基础设施。

总结

虚拟化技术，使用逻辑来表示资源，从而摆脱物理限制的约束，提高物理资源的利用率。
虚拟机、容器、JVM都是在计算机不同的层面进行虚拟化，都属于虚拟化技术的一种表现。
虚拟机是位于硬件与操作系统之间的虚拟化技术，是对硬件的虚拟；
容器是是位于操作系统与函数库之间的虚拟化技术，是对操作系统的虚拟；
JVM是位于函数库与应用程序之间的虚拟化技术，是对函数库的虚拟；
沙箱是一种安全隔离的理论框架，而虚拟机、容器、JVM都可以看作是这种理论框架通过虚拟化技术的不同实现方式。
反过来说，每个容器就是一个单独的沙箱环境，每个容器的资源，例如文件系统、进程和网络都会被安置在一个虚拟的隔离环境之中，其它容器无法访问这一隔离环境。

补充内容

信任边界

容器是一种对应用进行打包、分享和部署的现代化方式。与把所有功能打包为单一软件的单体应用，容器化应用或微服务的设计目标是专注于单一任务。容器中包含要完成这一任务所需的所有依赖项目（包、库和一些二进制文件）。正因如此，容器化应用是平台无关的，能够在任何操作系统上运行，并不在意其版本或者已部署软件。这给开发人员带来了极大的方便！

当容器在主机上完成部署之后，每个容器的资源，例如文件系统、进程和网络栈都会被安置在一个虚拟的隔离环境之中，其它容器无法访问这一隔离环境。这个技术能够在一个集群内同时运行几百或几千个容器，容器化应用能够轻松的通过复制容器实例的方式进行伸缩。

容器运行时为每个容器模拟一个操作系统，虚拟机（VMM）则为每个虚拟机模拟一个硬件环境，容器共享主机操作系统的内核以及物理硬件，虚拟机共享主机的物理硬件。因为容器从主机上共享的资源更多，它们对存储、内存以及 CPU 的利用比虚拟机更加有效。然而共享越多，其代价就是容器之间、容器和主机之间的信任边界就越模糊。虚拟机和容器的架构差异如下：

相对于命名空间隔离技术而言，虚拟化硬件隔离通常会有更好的安全边界。容器（进程）中逃出的攻击者，往往比虚拟机中逃出的攻击者具有更大的威胁。命名空间和 cgroup 的弱隔离是造成这种风险的原因。

这些安全性方面的担忧，促使开发人员不断为容器构建更强的信任边界。具体的解决方式就是创建一个真正的沙箱容器。以近期了解的前端安全沙箱技术 FinClip为例，这是一种嵌入式安全沙箱，又被称之为小程序容器，它的本质其实是建立在Security Capability model基础上的浏览器内核的扩展，其沙箱的特点，体现在三个方面：

1、沙箱内小程序之间的隔离。

2、沙箱对运行其中的小程序代码，隔离其对宿主环境的资源访问。

3、沙箱隔离了宿主对于沙箱中运行的小程序所产生的数据。

具体来说，类似 FinClip 这样的安全沙箱来讲，为业务代码提供一个封闭的安全环境，有效对抗外部代码的干扰和数据泄露风险；第三方App只能通过SDK暴露的接口启动SDK，SDK完全管控对业务代码所需要的运行环境以及业务代码所有对外通信，可以通过多种机制保证网络通信不被拦截和干扰；SDK 内部使用独立的浏览器内核，运行环境与系统浏览器完全隔离 (在 Android 上)。

安全沙箱原理

这种安全沙箱中运行的主要是轻应用、小程序，在应用范式上兼容互联网主流的小程序规范，应用落地的门槛很低，能迅速投入应用。对于对接大量外部应用的企业来说，这个设计是非常巧妙的。换句话说，不管小程序的“供应商”是谁，它们的代码都被隔离、同时也被保护在沙箱环境中。

沙盒化容器（一种介于虚拟机与容器之间的东西）

与普通容器相比，沙盒容器提供了更强的隔离性，这种强隔离提供了更高的安全性。同时这类容器技术支持 OCI 和 CRI 规范，可以与现有的容器工具以及 Kubernetes 很好的集成。

容器是打包、共享和部署应用的现代化方式，帮助企业实现快速、标准、灵活地完成服务交互。容器化是建立在 Linux 的命名空间（namespace）和控制组（cgroup）的设计之上。

命名空间创建一个几乎隔离的用户空间，并为应用提供专用的系统资源，如文件系统、网络堆栈、进程ID和用户ID。随着用户命名空间的引入，内核版本 3.8 提供了对容器功能的支持：Mount（mnt）、进程 ID（pid）、Network（net）、进程间通信（ipc）、UTS、用户 ID（user）6 个命名空间（如今已达 8 个，后续加入了 cgroup 和 time 命名空间）。

cgroup 则实施对应用的资源限制、优先级、记账和控制。cgroup可以控制 CPU、内存、设备和网络等资源。

同时使用 namespace 和 cgroup 使得我们可以在一台主机上安全地运行多个应用，并且每个应用都位于隔离的环境中。

虽然容器很棒，足够轻量级。但通过上面的描述，同一个主机上的多个容器其实是共享同一个操作系统内核，只是做到了操作系统级的虚拟化。虽然命名空间提供了高度的隔离，但仍然有容器可以访问的资源，这些资源并没有提供命名空间。这些资源是主机上所有容器共有的，比如内核 Keyring、/proc、系统时间、内核模块、硬件。

我们都知道没有 100% 安全的软件，容器化的应用也一样，从应用源码到依赖库到容器 base 镜像，甚至容器引擎本身都可能存在安全漏洞。发生容器逃逸的风险远高于虚拟机，黑客可以利用这些逃逸漏洞，操作容器的外部资源也就是宿主机上的资源。除了漏洞，有时使用的不当也会带来安全风险，比如为容器分配了过高的权限（CAP_SYS_ADMIN 功能、特权权限），都可能导致容器逃逸。

而虚拟机依靠硬件级的虚拟化，实现的硬件隔离比命名空间隔离提供了更强大的安全边界。与容器相比，虚拟机提供了更高程度的隔离，只因其有自己的内核。

由此可见，容器并不是真正的“沙盒”，也并不是轻量化的虚拟机。有没有可能为容器增加一个更安全的边界，尽可能的与主机操作系统隔离，做到类似虚拟机的强隔离，使其成为真正的“沙盒”？

答案是有，就是沙盒容器。这种容器就像虚拟机一样有自己的内核，这层内核成为用户空间内核。这层内核要保持容器的轻量级，使用现代编程技术编写，本身非常轻，仅用于作为容器和主机之间的强隔离层。

并且还要支持 OCI 和 CRI 规范，可以与 Docker 和 Kubernetes 等容器工具很好的集成。

这里简单介绍下 gVisor 和 Kata Containers。

gVisor 是使用 Go 编写的应用内核，实现了 Linux 操作系统的大部分接口。其包含了一个叫做 runsc 的 OCI 运行时，提供了应用和宿主机内核间的隔离层。runsc 也实现了与 Docker 和 Kubernetes 的集成，可以很容易的运行沙盒容器。

gVisor 为每个容器提供了独立的操作系统内核。应用与 gVisor 内核提供的虚拟环境进行交互，不是直接访问宿主机的内核。gVisor 还限制和管理文件和网络操作，确保容器化应用和主机操作系统之间有两个隔离层。通过减少和限制应用与主机内核的交互，尽可能减小攻击者绕过容器隔离机制的攻击面。

与大部分内核不同，gVisor 不需要固定的物理资源；相反，其利用现有的主机内核功能，并作为一个正常进程运行。换句话说，gVisor 以 Linux 的方式实现了 Linux。

gVisor 沙盒由多个进程组成，这些进程共同构成了可以运行一个或多个容器的环境。

每个沙盒都有其独立的实例：

Sentry：运行容器的内核，拦截并响应应用的系统调用。

沙盒中的每个容器都有其独立的实例：

Gofer：提供容器文件系统的访问。

Kata Containers 与容器一样轻量级且快，并与容器管理层集成-- 包括 Docker 和 Kubernetes 等流行的容器编排工具 -- 同时还提供了与虚拟机一样的安全。

Kata Containers 与 OCI、容器运行时接口（CRI）和容器网络接口（CNI）完全集成。它支持各种类型的网络模型（例如，passthrough、MacVTap、桥接、tc 镜像）和可配置的访客内核，以便需要特殊网络模型或内核版本的应用都可以在上面运行。上图显示了 Kata VM 中的容器如何与现有编排平台交互。

Kata 在主机上有一个 kata 运行时来启动和配置新容器。对于 Kata VM 中的每个容器，主机上都有一个相应的 Kata Shim。Kata Shim 接收来自客户端（例如 docker 或 kubectl）的 API 请求，并通过 VSock 将请求转发给 Kata VM 内的代理。Kata 容器进一步进行了几项优化，以减少 VM 启动时间。

Kata Containers 由两个开源项目合并而来：Intel 的 Clear containers 和 Hyper runV。前者注重性能（引导时间小于 100ms）和安全；而后者通过支持不同的 CPU 架构和管理系统，将技术无关放在首位。Kata Containers 可以说集二者之大成。