由于容器基于操作系统虚拟化技术,因此它们在同一台机器上运行时是共享一个操作系统内核的。尽管与虚拟机提供的基于硬件虚拟化的隔离相比还有一定差距,但是这种系统级别的隔离在大部分情况下已经足够了。若以VM为基础来构建云原生应用则会有以下缺点:

  • 虚拟机的启动需要整个操作系统,因此花费的启动时间会更长。
  • 一台虚拟机包含了整个操作系统,通常有几个GB大小。而镜像通常存储在中央镜像仓库中,通过网络来传输它们则需要花不少时间。
  • 虚拟机的扩容也是一个挑战。纵向扩容(增加更多资源)意味创建然后启动一个新的、更大的虚拟机(更多CPU、内存、存储空间等)实例。而横向扩容意味着创建新的实例,因为虚拟机的启动很慢,所以往往无法达到快速响应的目的。
  • 虚拟机还会带来一些额外的开销,会消耗更多的内存、CPU和存储资源。所以它部署的密度(同一台机器上虚拟机实例的数量)就会受到制约。最常见的需要硬件虚拟化级别隔离的场景是有潜在风险的多租户场景。比如需要防止一个用户试图恶意突破隔离,尝试访问位于同一个基础架构或同一台服务器上的其他租户的资源。云服务提供商会在内部采用一些技术手段,在保持容器的启动速度和效率优势的情况下同时满足虚拟机级别的隔离性。诸如此类的技术有Hyper-V容器、沙盒容器(sandbox container)和微虚机(MicroVM)等。

Nabla


Nable容器通过使用Solo5项目中的unikernel技术来实现更好的隔离,这种技术限制了从容器对宿主机内核的系统调用。Nable容器的运行时环境(runc)是一个符合OCI(Open ContainerInitiative)规范的运行时环境。官网宣言:Nabla containers: a new approach to container isolation
###gVisor

这是一个用Go语言编写的运行于用户空间的内核,它提供了容器的运行时环境。新内核是一个可以满足系统调用需求的非特权进程,它防止了容器内与用户空间的直接交互。gVisor的运行时环境(runSC)是符合OCI规范的,同样也支持Kubernetes编排工具。官网宣言:gVisor is an application kernel for containers that provides efficient defense-in-depth anywhere.

微软的Hyper-V


容器微软的Hyper-V容器在几年前就推出了,代号Viridian, 旧称Windows Server Virtualization,是Microsoft的本地虚拟机管理程序,它可以在运行x86-64位的Windows上创建虚拟机。这种容器能够在兼容OCI标准的同时提供完整的虚拟机级别的隔离。但是目前不支持Kubernetes来管理Hyper-V容器。

Kata


Kata容器结合了Hyper.sh和Intel的clear container,并提供了经典的硬件辅助虚拟化。Kata 容器运行时是采用轻量级虚拟机来运行某一个用户的、一个应用的一个或多个容器实例, 这样的好处是利用不同用户、不同应用之间,都是使用独占的虚拟机来隔离容器,不会共享同一操作内核。Kata 既支持容器 OCI 接口,单虚拟机单容器模式;也支持 Kubernetes CRI 接口,单虚拟机多容器模式;同时,利用 OpenStack Keystone 的多租户和 Neutron 网络隔离能力,能带给容器生态更好的多租户隔离、更好的安全性。OpenStack 与 Kubernetes 融合,是两个基金会都主推和认可的最佳部署模式。

Firecracker


Firecracker是亚马逊的Lambada服务的底层技术基础,并且已经在Apache 2.0许可下开源。它是一种用户模式的VM解决方案,位于KVM API之上,旨在运行现代Linux内核。Firecracker的目标是以管理程序隔离(hypervisor-isolated)的方式来运行Linux容器,该隔离和Kata容器这样的容器隔离技术有些类似。官网宣言:Our mission is to enable secure, multi-tenant, minimal-overhead execution of container and function workloads.