关于容器:容器在公有云上的落地姿势

1. 容器天生隔离能力有余

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

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

Linux 容器采纳 Linux 控制组（cgroups）和命名空间（namespace），其中，cgroups 定义了一个过程能应用什么（CPU、内存、网络等资源），namespace 定义了一个过程能看到什么（uid，gid，pid，mount，filesystem 等）。一方面，并非所有系统资源都能够通过这些机制来管制（比方工夫和 Keyring，https://blog.jessfraz.com/pos…）。另一方面，在 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（他的博客地址为 https://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 微虚机进步了效率和利用率，内存开销极低，使得在一台物理服务器上能够创立数千个微虚机。后文上面再介绍。

其益处也是不言自明的，比方：

利用 CPU 硬件虚拟化实现了用户之间的强隔离。
进步物理硬件资源利用率。
缩短函数运行的启动工夫。
简化了平安模型。
简化了 Lambda 编程模型。

3. Firecracker 是什么

Firecracker 的中文意思是『鞭炮』。顾名猜意，不晓得亚马逊云科技是不是认为在私有云上运行容器就像放鞭炮一样，看起来绚丽多彩，然而弄不好就会引起火灾。
应用 Firecracker 后的 Lambda 隔离模型：

简略地能够将 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 毫秒。

我的项目的开源地址是 https://firecracker-microvm.g…。更多信息，可查阅更多文章，甚至浏览源码。

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？）。

参考链接：

• https://docs.google.com/docum…
• https://blog.jessfraz.com/pos…
• https://www.youtube.com/watch…
• https://www.slideshare.net/Am…
• https://aws.amazon.com/blogs/…

本篇作者

刘世民

云计算技术专家，曾就任于华为、IBM、海航等公司，专一于云计算。曾在海航团体易航科技负责云服务事业群总经理一职，负责 IDC、云平台、零碎运维、信息安全以及用户服务等业务。保护有“世民谈云计算”技术博客和微信公众号。《OpenShift 云原生架构原理与实际》作者之一、《Ceph Cookbook 中文版》《精通 OpenStack》、《机器学习即服务: 将 Python 机器学习创意疾速转变为云端 Web 应用程序》译者之一。

浏览原文：https://dev.amazoncloud.cn/co…