容器在公有云上的落地姿式

时间 2019-11-05

标签容器公有落地繁體版

原文原文链接

1.容器天生隔离能力不足

1.1 容器是一种进程隔离技术，并不是虚拟化技术

容器（container），并非一种虚拟化（virtualization）技术，而是一种进程隔离（isolation）技术，从内核空间、资源和安全等方面对进程作隔离。linux

Linux 容器采用 Linux 控制组（cgroups）和命名空间（namespace），其中，cgroups 定义了一个进程能使用什么（CPU、内存、网络等资源），namespace 定义了一个进程能看到什么（uid，gid，pid，mount，filesystem等）。一方面，并不是全部系统资源均可以经过这些机制来控制（好比时间和Keyring，https://blog.jessfraz.com/post/two-objects-not-namespaced-linux-kernel/）。另外一方面，在Linux 容器中运行的应用程序与常规（非容器化）应用程序以相同的方式访问系统资源；直接对主机内核进行系统调用。内核以特权模式运行，容许它与必要的硬件交互并将结果返回阴应用程序。所以，即便使用了不少限制，内核仍然面向恶意程序暴露出了过多的攻击面。git

除了cgroups 和 namespace，Linux 容器还会使用到象 seccomp 这样的技术。seccomp是内核防火墙，限制一个进程对内核系统调用（systemcall）的访问限制，可以在应用程序和内核之间提供更好的隔离，可是它们要求用户建立预约义的系统调用白名单。在实际中，很难事先罗列出应用程序所需的全部系统调用。若是你须要调用的系统调用存在漏洞，那么这类过滤器也很难发挥做用。github

所以，容器被认为不具有和虚拟机以及沙盒（sanbox）同样的隔离能力。关于容器、虚拟机和沙盒之间的区别，Jessie 的这篇博文（Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs ）给出了很好的解释。编程

1.2 Kubernetes 的多租户隔离

Jessie Frazelle（他的博客地址为 https://blog.jessfraz.com，强烈推荐）将多租户隔离模式分为两大类：安全

弱隔离（Soft multi-tenancy）：同一个组织中的多个用户使用同一个集群。这种隔离模式中，由于用户处于同一个组织中，所以互相之间默认是信任关系，可是也存在可能的状况，好比有恶意的员工。这种隔离模式的主要目的就是为了防止这种恶意事件。服务器
强隔离（Hard multi-tenancy）:来自不一样组织的多个用户使用同一个集群。这种隔离模式中，默认就假定全部用户都是潜在恶意的，所以这种模式的主要目的是阻止租户之间的互相访问。

从上面的定义能够看出，基本上，私有云的隔离模式是弱隔离模式，而公有云的隔离模式是强隔离模式。微信

由于容器天生隔离不足，若是只是采用传统 Linux 容器的话，公有云每每采用每一个用户单首创建 Kubernetes 集群的方式来实现强隔离：网络

Jessie Frazelle 的这个图是假设 K8S 可以在不一样的宿主机上建立和管理不一样的K8S 集群（那时候 K8S 真的成为集群操做系统了）。实际上，当前这种角色每每由公有云本身的云管平台实现，而后在若干台虚拟机或物理机上为每一个用户搭建完整的Kubernetes集群，每一个集群利用传统的Linux 容器来运行客户的应用。由于传统Linux容器的隔离性不足，每一个用户的容器必须容许在独占的环境中。架构

可是，若是把运行环境从 Linux 传统容器换成微虚机（好比 kata container）的话，由于微虚机自己具备的强隔离能力，则能够在一个宿主机上建立不一样用户的这种运行环境，此时这些环境在集群中是混部的。less

2.容器在AWS 上的落地方式（以Lambda为例）

AWS 上多个服务都利用到容器，好比 Lambda 利用了传统Linux 容器，而 ECS 和 EKS 则利用了 Docker 容器。以 Lambda 为例，咱们来看看过去和如今容器在AWS上的落地方式。

2.1 过去容器在Lambda 中的落地方式 - 用户函数运行在独占的EC2虚拟机中的Linux容器中

下图是 Lambda 的技术架构：

从名字上基本上就能够看出来每一个组件是干什么的。其中，一个 Worker 就是实际运行用户函数的一个安全环境。以前，一个 worker 是一个 EC2 实例，其操做系统为 Amazon Linux。

下图是 Worker 被建立以及函数被调度到 worker 中的基本流程：

其中，Worker manage 负责 worker 的建立和管理，Placement 服务负责将用户的函数调度到某个或某些worker 上运行。

此时Lambda的强隔离模式的实现方式以下图所示：

这个图仍是简单明了的，具体就不解释了。

引用 AWS Lambda 团队工程师所说的，基于CPU的硬件虚拟化技术是AWS上用户之间隔离的最低要求。所以，和 AWS 上不少利用容器的服务同样，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 的中文意思是『鞭炮』。顾名猜意，不知道AWS是否是认为在公有云上运行容器就像放鞭炮同样，看起来绚丽多彩，可是弄很差就会引发火灾。

简单地能够将 Firecracker 看作被大大简化了的 QEMU。它和 QEMU 同样，利用 KVM，负责建立和管理虚机。由于这种虚机面向 Serverless 这种场景，适合于运行暂时性（ transient and short-lived）进程，所以被称为微虚机，即microVM。

由于公有云对微虚机的要求是具备象常规虚拟机同样的隔离能力，同时还有象Linux 容器那样的轻量特性（硬件开销小，启动快）。所以，Firecracker 的设计思路是：

内置安全性：提供了支持多租户工做负载而且不会被客户错误禁用的计算安全性屏障。客户工做负载被认为既神圣（不可侵犯）又邪恶（应当拒之门外）。
轻量虚拟化：重视瞬时性或无状态的工做负载，而非长时间运行或持续性的工做负载。Firecracker 的硬件资源开销是明确且又保障的。
功能极简主义：不会构建非AWS任务所明确要求的功能。每一个功能仅实施一项。
计算超分：Firecracker 向来宾开放的全部硬件计算资源均可以安全地超分。

Firecracker 坚持精简主义的设计原则，它仅包含运行安全、轻量的虚拟机所需的组件。在设计过程的各个环节，都依据安全性、速度和效率要求来优化 Firecracker。例如，仅启动相对较新的 Linux 内核，而且仅启动使用特定配置选项集编译的内核（内核编译配置选项超过 1000 种）。此外，不支持任何类型的图形卡或加速器，不支持硬件透传，不支持（大多数）老旧设备。只支持四种设备虚拟化（virtio-net, virtio-block, serial console, 和只有一个按钮的键盘控制器）。

这么作的结果也是很是明显的，好比：

每一个微虚机的内存开销小于 5MiB。
一台物理机上能启动的微虚机数目的限制只是硬件限制，数目能够是数千台。
在AWS 一次启动4000个微虚机的演示中，最长的微虚机耗时只有219毫秒，最短的只须要125毫秒。

项目的开源地址是 https://firecracker-microvm.github.io/。更多信息，可查阅更多文章，甚至阅读源码。

4. 展望将来

AWS 宣布开源 Firecracker在业界引发了很大的关注。加上以前已有的 Kata container（由Intel，Hyper.sh 和 OpenStack主导）和 gVisor（由Google开源），微虚机愈来愈引发人们的重视。基于我的理解，对将来作一点不负责任的预测：

公有云利用微虚机来落地容器会成为通用作法。以阿里云的秉性，相信他们很快会跟进，推出和AWS相似的技术实现。极可能也会开源一个项目。
AWS 会将 Firecracker 做为其统一的容器落地模式。

微虚机生态（Kata container、gVisor 和 Firecracker）会发生不少有趣的变化。当前，每一个项目都有各自的面向场景。从非技术层面看，由于AWS 对开源的态度应该是『以我为主』，所以 Firecracker 仍是会继续由AWS主导，以被AWS上的服务使用为主；gVisor 由于来自Google，Google 也有公有云，加上 Kubernetes 也源自Google，不知道它是否会演进为事实上的微虚机标准；而 Kata container 也许未来会以面向私有云场景为主（设想一下OpenStack支持 Kata 微虚机，而 K8S 支持支持 gVisor 微虚机，二者之间的PK是否是就成了编排能力的PK？）。

参考连接：

感谢您的阅读，欢迎关注个人微信公众号：