1.容器天然生成阻隔才能缺乏
1.1 容器是一种进程阻隔技能，并非虚拟化技能
容器（container），并不是一种虚拟化（virtualization）技能，而是一种进程阻隔（isolation）技能，从内核空间、资源和安全等方面对进程做阻隔。
Linux 容器选用 Linux 操控组（cgroups）和命名空间（namespace），其间，cgroups 界说了一个进程能运用什么（CPU、内存、网络等资源），namespace 界说了一个进程能看到什么（uid，gid，pid，mount，filesystem 等）。一方面，并非一切体系资源都能够经过这些机制来操控（比方时刻和Keyring，blog.jessfraz.com/post/two-ob…另一方面，在 Linux 容器中运转的应用程序与惯例（非容器化）应用程序以相同的方法拜访体系资源；直接对主机内核进行体系调用。内核以特权形式运转，答应它与必要的硬件交互并将结果回来阴应用程序。因而，即使运用了很多约束，内核依然面向歹意程序露出出了过多的攻击面。
除了 cgroups 和 namespace，Linux 容器还会运用到象 seccomp 这样的技能。seccomp是内核防火墙，约束一个进程对内核体系调用（systemcall）的拜访约束，能够在应用程序和内核之间供给更好的阻隔，可是它们要求用户创立预界说的体系调用白名单。在实践中，很难事前罗列出应用程序所需的一切体系调用。假如你需求调用的体系调用存在漏洞，那么这类过滤器也很难发挥作用。
因而，容器被以为不具备和虚拟机以及沙盒（sanbox）相同的阻隔才能。关于容器、虚拟机和沙盒之间的区别，Jessie 的这篇博文（Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs ）给出了很好的解说。
1.2 Kubernetes 的多租户阻隔
Jessie Frazelle（他的博客地址为blog.jessfraz.com强烈推荐）将多租户阻隔形式分为两大类：
- 弱阻隔（Soft multi-tenancy）：同一个安排中的多个用户运用同一个集群。这种阻隔形式中，由于用户处于同一个安排中，因而相互之间默许是信任关系，可是也存在或许的状况，比方有歹意的员工。这种阻隔形式的首要意图便是为了避免这种歹意事件。
- 强阻隔（Hard multi-tenancy）:来自不同安排的多个用户运用同一个集群。这种阻隔形式中，默许就假定一切用户都是潜在歹意的，因而这种形式的首要意图是阻挠租户之间的相互拜访。
从上面的界说能够看出，根本上，私有云的阻隔形式是弱阻隔形式，而公有云的阻隔形式是强阻隔形式。
由于容器天然生成阻隔缺乏，假如仅仅选用传统 Linux 容器的话，公有云往往选用每个用户单独创立 Kubernetes 集群的方法来完成强阻隔：
Jessie Frazelle 的这个图是假设 K8S 能够在不同的宿主机上创立和办理不同的 K8S 集群（那时候 K8S 真的成为集群操作体系了）。实践上，当时这种角色往往由公有云自己的云管平台完成，然后在若干台虚拟机或物理机上为每个用户搭建完好的 Kubernetes 集群，每个集群运用传统的 Linux 容器来运转客户的应用。由于传统 Linux 容器的阻隔性缺乏，每个用户的容器必须答应在独占的环境中。
可是，假如把运转环境从 Linux 传统容器换成微虚机（比方 kata container）的话，由于微虚机本身具有的强阻隔才能，则能够在一个宿主机上创立不同用户的这种运转环境，此时这些环境在集群中是混部的。
2.容器在亚马逊云科技上的落地方法（以 Lambda 为例）
亚马逊云科技上多个服务都运用到容器，比方 Lambda 运用了传统 Linux 容器，而 ECS 和 EKS 则运用了 Docker 容器。以 Lambda 为例，我们来看看过去和现在容器在亚马逊云科技上的落地方法。
2.1 过去容器在 Lambda 中的落地方法 – 用户函数运转在独占的 EC2 虚拟机中的 Linux 容器中
下图是 Lambda 的技能架构：
从名字上根本上就能够看出来每个组件是干什么的。其间， 一个 Worker 便是实践运转用户函数的一个安全环境。之前，一个 worker 是一个 EC2 实例，其操作体系为 Amazon Linux。
下图是 Worker 被创立以及函数被调度到 worker 中的根本流程：
其间，Worker manage 担任 worker 的创立和办理，Placement 服务担任将用户的函数调度到某个或某些 worker 上运转。
此时Lambda的强阻隔形式的完成方法如下图所示：
这个图仍是简单明了的，具体就不解说了。
引证 Amazon Lambda 团队工程师所说的，根据 CPU 的硬件虚拟化技能是亚马逊云科技上用户之间阻隔的最低要求。因而，和亚马逊云科技上很多运用容器的服务相同，Lambda 也运用了 EC2 虚机来完成用户之间的强阻隔。
可是，其局限也是显而易见的，比方：
- 资源糟蹋：用户的一个简单的测试函数也会占用一个虚机）
- 办理杂乱：需求办理杂乱的资源和安全形式
- 启动速度不够快：由于 EC2 虚机的创立时刻原因
2.2 现在容器在 Lambda 中的落地方法 – 用户函数运转在 Firecracker 微虚拟机中
亚马逊在2018 年 re:invent 大会上宣告了一个新的开源项目 Firecracker，并已经用在Lambda 和 Fargate 服务之中了。 Firecracker 是一种选用根据 Linux 内核的虚拟机 (KVM) 技能的开源虚拟机监控程序(VMM)。 Firecracker 担任创立和办理微虚机（microVM）。 Firecracker 微虚机提高了效率和运用率，内存开支极低，使得在一台物理服务器上能够创立数千个微虚机。后文下面再介绍。
运用 Firecracker 后的 Lambda 阻隔模型：
其优点也是不言自明的，比方：
- 运用 CPU 硬件虚拟化完成了用户之间的强阻隔。
- 提高物理硬件资源运用率。
- 缩短函数运转的启动时刻。
- 简化了安全模型。
- 简化了 Lambda 编程模型。
3. Firecracker 是什么
Firecracker 的中文意思是『鞭炮』。顾名猜意，不知道亚马逊云科技是不是以为在公有云上运转容器就像放鞭炮相同，看起来绚丽多彩，可是弄不好就会引起火灾。
简单地能够将 Firecracker 看做被大大简化了的 QEMU。它和 QEMU 相同，运用 KVM，担任创立和办理虚机。由于这种虚机面向 Serverless 这种场景，适合于运转暂时性（ transient and short-lived）进程，因而被称为微虚机，即 microVM。
由于公有云对微虚机的要求是具有象惯例虚拟机相同的阻隔才能，一起还有象Linux 容器那样的轻量特性（硬件开支小，启动快）。因而，Firecracker 的规划思路是：
- 内置安全性：供给了支撑多租户作业负载并且不会被客户过错禁用的核算安全性屏障。客户作业负载被以为既崇高（不行侵略）又邪恶（应当拒之门外）。
- 轻量虚拟化：注重瞬时性或无状况的作业负载，而非长时刻运转或持续性的作业负载。Firecracker 的硬件资源开支是明确且又保证的。
- 功用极简主义：不会构建非亚马逊云科技使命所明确要求的功用。每个功用仅施行一项。
- 核算超分：Firecracker 向宾客开放的一切硬件核算资源都能够安全地超分。
Firecracker 坚持精简主义的规划准则，它仅包含运转安全、轻量的虚拟机所需的组件。在规划进程的各个环节，都根据安全性、速度和效率要求来优化 Firecracker。例如，仅启动相对较新的 Linux 内核，并且仅启动运用特定配置选项集编译的内核（内核编译配置选项超过 1000 种）。此外，不支撑任何类型的图形卡或加速器，不支撑硬件透传，不支撑（大多数）老旧设备。只支撑四种设备虚拟化（virtio-net, virtio-block, serial console, 和只要一个按钮的键盘操控器）。
- 这么做的结果也是十分明显的，比方：
- 每个微虚机的内存开支小于 5MiB。
- 一台物理机上能启动的微虚机数意图约束仅仅硬件约束，数目能够是数千台。
在亚马逊云科技一次启动4000个微虚机的演示中，最长的微虚机耗时只要219毫秒，最短的只需求125毫秒。
项意图开源地址是firecracker-microvm.github.io/。更多信息，可查阅更多文章，甚至阅览源码。
4. 展望未来
亚马逊云科技宣告开源 Firecracker 在业界引起了很大的关注。加上之前已有的 Kata container（由Intel，Hyper.sh 和 OpenStack 主导）和 gVisor（由 Google 开源），微虚机越来越引起人们的注重。根据个人了解，对未来做一点不担任任的猜测：
- 公有云运用微虚机来落地容器会成为通用做法。以阿里云的秉性，信任他们很快会跟进，推出和亚马逊云科技类似的技能完成。很或许也会开源一个项目。
- 亚马逊云科技会将 Firecracker 作为其一致的容器落地形式。
-
- 微虚机生态（Kata container、gVisor 和 Firecracker）会发生很多风趣的变化。当时，每个项目都有各自的面向场景。从非技能层面看，由于亚马逊云科技对开源的情绪应该是『以我为主』，因而 Firecracker 仍是会继续由亚马逊云科技主导，以被亚马逊云科技上的服务运用为主；gVisor 由于来自 Google，Google 也有公有云，加上 Kubernetes 也源自 Google，不知道它是否会演进为事实上的微虚机标准；而 Kata container 或许将来会以面向私有云场景为主（想象一下OpenStack支撑 Kata 微虚机，而 K8S 支撑支撑 gVisor 微虚机，两者之间的 PK 是不是就成了编排才能的 PK？）。
参阅链接：
- docs.google.com/document/d/…
- blog.jessfraz.com/post/contai…
- www.youtube.com/watch?v=Qdz…
- www.slideshare.net/AmazonWebSe…
- aws.amazon.com/blogs/opens…
本篇作者
刘世民
云核算技能专家，曾上任于华为、IBM、海航等公司，专心于云核算。曾在海航集团易航科技担任云服务工作群总经理一职，担任 IDC、云平台、体系运维、信息安全以及用户服务等事务。维护有“世民谈云核算”技能博客和微信大众号。《OpenShift云原生架构原理与实践》作者之一、《Ceph Cookbook中文版》《通晓OpenStack》、《机器学习即服务:将Python机器学习构思快速转变为云端Web应用程序》译者之一。
阅览原文：dev.amazoncloud.cn/column/arti…
