共计 2240 个字符，预计需要花费 6 分钟才能阅读完成。
【本文由 Cloud Ace 整顿公布，谷歌云服务请拜访 Cloud Ace 官网】
灵便的应用程序架构、CI/CD 管道和容器工作负载通常运行不受信赖的代码，因而应该与敏感的基础设施隔离。一种常见的解决方案是部署纵深进攻产品（如应用 gVisor 的 GKE Sandbox）以通过额定的保护层隔离工作负载。Google Cloud 的无服务器产品（App Engine、Cloud Run、Cloud Functions）也应用 gVisor 对应用程序工作负载进行沙箱解决。
然而，减少进攻层也会带来新的性能挑战。当 gVisor 的用户空间内核须要多个操作来遍历文件系统门路时，而后谷歌发现了一个这样的挑战。为了解决这个问题并显着进步 gVisor 的性能，编写了一个全新的文件系统层，同时思考到性能，同时放弃雷同级别的安全性。新文件系统 (VFS2) 缩小了为文件系统零碎调用提供服务所需的操作数，缩小了锁争用，更无效地分配内存，并进步了与 Linux 的兼容性。
纵深进攻和文件系统
第一层进攻是在用户模式下运行的 gVisor 内核。gVisor 威逼模型假如歹意容器能够毁坏 gVisor 的内核，同时仍将歹意容器与底层主机基础设施或其余工作负载隔离开来。因为 gVisor 内核不可信赖，因而它无奈间接拜访文件系统。文件系统操作由代理（称为 Gofer）代理，该代理与可能的歹意工作负载隔离。关上、创立和统计等操作被转发到代理，通过审查，而后由代理执行。Gofers 作为一个独自的过程运行，pod 中的每个容器一个，并且还受到深度进攻层的爱护，仅授予它所需的拜访权限。
在 gofer 授予对文件的拜访权限后，在 gVisor 内核文件系统返工之前，须要大量操作来遍历文件门路，从而导致一些性能缺点。这个问题在应用 gofer 挂载文件系统时尤为显著，其中每个操作的往返老本因 RPC 和调度老本而加剧。更值得注意的是，gVisor 沙箱会向 gofer 收回新的 RPC 以遍历每个门路组件，这会大大降低性能。
改良的文件系统性能
应答这一挑战须要使 gVisor 的哨兵可能将门路解析间接委托给文件系统。这容许 gofer 文件系统收回单个 RPC 来执行大型遍历，而不是为操作中的每个门路组件收回一个 RPC。例如，在 VFS1 中，stat(/foo/bar/baz) 向 gofer (foo, bar, baz) 生成至多三个 RPC，而 VFS2 只生成一个。
借此机会，谷歌从新设计了 sandbox-gofer 协定层。而早些时候应用的是 9P2000.L 协定的批改版本。然而，这个协定十分繁琐，收回许多 RPC 并耗费大量内存。谷歌构建了一个名为 LISAFS（Linux 沙盒文件系统协定）的新协定来代替 9P。LISAFS 在 RPC 和内存应用方面更经济。LISAFS 为多路径组件行走提供 RPC。VFS2 中的 gofer 文件系统当初能够应用 LISAFS 执行这种一次性遍历。LISAFS 还能够通过 RPC 执行更快的文件 IO。
执行频繁文件系统操作（如关上、创立、统计、列表和加载库）的工作负载正在应用 VFS2 和 LISAFS 进步性能。这些工作负载的示例包含运行解释性语言（例如 Python 和 NodeJS）以及大量导入，或者从源代码构建二进制文件。CI/CD 工作负载（例如 bazel）构建在大型代码库上，并提供对文件系统性能的深刻理解。此类工作负载必须关上和读取大量源文件，并写入大量指标文件和二进制文件。
以下是截至 2022 年 12 月构建 gRPC 和 Abseil 的开源 bazel 基准测试的后果。这些基准测试在相似 GKE 的环境中运行。要了解后果，了解以下术语会很有帮忙：
·Runsc overhead： 这是 gVisor 相较于 native 减少的性能开销。例如，如果本机运行工作负载（应用 runc）须要 10 秒，而 runsc 须要 13 秒，则 runsc 开销为 30%。
·Root： 我的项目的源代码放在根文件系统中，以独占形式挂载。这意味着沙盒能够齐全管制文件系统并应用更踊跃的缓存来进步性能。
·绑定： 我的项目源代码放在绑定挂载中。所有绑定挂载都以共享模式挂载。这意味着可能会产生文件的内部批改，并且 gVisor 会在每次拜访时从新验证缓存以确保状态是最新的。
·tmpfs： 我的项目源代码放在 tmpfs（内存文件系统）中。
能够看到 VFS2 和 LISAFS 继续改良所有这些配置的性能，并使 runsc 更靠近本机 (runc) 性能。
VFS2 和 LISAFS 现已在所有 GKE 和无服务器产品中 100% 推出，并在几个月内逐渐推出了这些优化。这些还有助于缩短一些在初始化时执行大量文件系统工作的应用程序的冷启动工夫。例如，从 2022 年 8 月开始的 App Engine LISAFS 推出数据显示，LISAFS 均匀将冷启动进步了 25% 以上。
为大规模容器工作负载提供纵深平安进攻帮忙确定性能衡量，例如须要新施行的 gVisor 文件系统。这些改良大大放大了性能差距，而无需就义安全性。VFS2 架构使大家可能在提供企业就绪容器平安解决方案的同时，持续改良安全性和性能衡量。
立刻试用 GKE Sandbox 以加强工作负载安全性
GKE Sandbox 为您的工作负载提供了额定的平安层，您明天就能够试用了。浏览启用 GKE 沙盒指南，通过查看 GKE 沙盒概述理解无关容器平安的更多信息，或者立刻开始应用 Google Cloud 收费试用。
如果您想更深刻地理解技术细节，您能够查看官网 gVisor 文档，查看 GitHub 上的源代码，甚至可能做出奉献。期待看到更多沙盒工作负载在 Google Cloud 上运行！