关于云计算:沙盒化容器是容器还是虚拟机

7次阅读

共计 2470 个字符，预计需要花费 7 分钟才能阅读完成。

随着 IT 技术的倒退，AI、区块链和大数据等技术晋升了对利用毫秒级扩大的需要，开发人员也面临着的性能疾速推出的压力。混合云是新常态，数字化转型是放弃竞争力的必要条件，虚拟化成为这些挑战的根本技术。

在虚拟化的世界，有两个词耳熟能详：虚拟机和容器。前者是对硬件的虚拟化，后者则更像是操作系统的虚拟化。两者都提供了沙箱的能力：虚拟机通过硬件级形象提供，而容器则应用公共内核提供过程级的隔离。有很多人将容器看成是“轻量化的虚拟机”，通常状况下咱们认为容器是平安的，那到底是不是跟咱们设想的一样？

容器是打包、共享和部署利用的现代化形式，帮忙企业实现疾速、规范、灵便地实现服务交互。容器化是建设在 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 能够说集二者之大成。

与传统的容器相比，Kata Container 做到了虚拟机的隔离，集虚拟机的安全性和容器的性能于一身。

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