本文介绍安全沙箱运行时的核心优势、适用场景，并对比容器服务Kubernetes版（ACK）安全沙箱和社区Kata Containers的性能，帮助您了解为什么选择安全沙箱运行时。
背景信息
相比原有Docker运行时，安全沙箱为您提供了一种新的容器运行时选项，具备以下特点：
它可以让您的应用运行在一个轻量虚拟机沙箱环境中，拥有独立的内核，具备更好的安全隔离能力。
相比社区方案（Kata Containers），安全沙箱在存储、网络和稳定性方面都有优化和提升。
安全沙箱特别适合于不可信应用隔离、故障隔离、性能隔离、多用户间负载隔离等场景，在提升安全性的同时，对性能影响非常小，并且具备与Docker容器一样的用户体验，例如日志、监控、弹性等。
安全沙箱核心优势
对比Docker运行时，安全沙箱核心优势如下：
基于轻量虚拟机沙箱超强隔离。
NAS、直挂沙箱，直挂后的存储性能与宿主机挂载模式性能一致。
媲美传统runC容器的应用兼容性。
极高的应用综合性能（相当于90% runC容器应用性能）。
在监控、日志、存储等方面有着与runC一样的使用体感。
支持RuntimeClass。
技能门槛要求低、简单易用，您无需理解虚拟机技术原理，也不需要在虚拟机上操作。
相对社区Kata Containers，有着更强的稳定性。
ACK安全沙箱和社区Kata Containers对比
ACK安全沙箱相比社区Kata Containers，在性能上面具有较大优势，如下表所示。
性能 | 性能分类 | ACK安全沙箱v2 | 社区Kata Containers |
沙箱启动速度 | 约150ms | 约500ms | |
沙箱额外开销 | 低 | 高 | |
容器RootFS | virtio-fs，性能：☆☆☆☆ | 9pfs，性能：☆ | |
容器存储卷 | HostPath/EmptyDir | virtio-fs，性能：☆☆☆☆ | |
云盘块存储 | virtio-fs，性能：☆☆☆☆ | ||
NAS文件存储 |
| ||
OSS对象存储 | virtio-fs，性能：☆☆☆☆ | ||
网络插件 |
| Flannel | |
监控告警 |
| 缺失安全沙箱Pod的磁盘和网络监控指标。 | |
稳定性 | ☆☆☆☆☆ | ☆☆ | |
ACK安全沙箱三大适用场景
以下是安全沙箱的三大适用场景。
场景一：相对于runC容器，安全沙箱（runV）容器可以强隔离不可信应用。
runC容器的安全风险
通过Namespace和Cgroups技术隔离的容器攻击面大。
节点上所有容器共享Host Kernel，一旦内核出现漏洞，恶意代码会逃逸到Host上，渗透到后端内网，执行恶意特权代码，破坏系统服务和其他应用，窃取重要数据等。
应用本身的漏洞同样会造成攻击者渗透到内网。
您可以通过以下措施降低runC容器的安全风险：
Seccomp：系统调用过滤。
SElinux：限制容器进程、文件和用户的权限。
Capability：限制容器进程Capability。
Rootless模式：禁止用户以root身份运行容器Runtime和容器。
虽然以上措施可以在一定程度上强化runC容器的安全性，降低恶意容器应用攻击Host Kernel的几率，但是仍然无法解决容器逃逸利用Host Kernel漏洞的安全问题。
安全沙箱（runV）容器隔离潜在安全风险
通过把存在潜在安全风险的应用放置到成熟的轻量级虚拟机沙箱中，应用运行在独立的GuestOS Kernel上，即便GuestOS Kernel出现安全漏洞，那么攻击破坏面仅限于一个沙箱内，不会对Host Kernel以及其他容器有任何影响。安全沙箱（runV）容器配合Terway的NetworkPolicy能力，可以灵活地配置Pod的网络访问策略，真正做到系统隔离、数据隔离以及网络隔离。
场景二：解决runC容器在故障放大、资源争抢、性能干扰方面的问题。
Kubernetes使得我们很容易在一个节点上混合部署不同的应用容器，由于Cgroups并不能很好解决资源争抢问题，导致同一节点上相同资源密集型（如CPU密集型、IO密集型等）的不同应用相互争抢资源，导致应用的响应时间出现了严重的波动，总体响应时间偏长。当节点上某一应用异常和故障，如内存泄露、频繁CoreDump等等导致节点整体负载升高，单容器触发Host Kernel Bug导致系统宕机，单应用的故障延展到了整个节点，甚至进一步导致整个集群的不响应。安全沙箱（runV）容器通过独立的GuestOS Kernel和Hypervisor，可以很好地解决runC容器在故障放大、资源争抢、性能干扰方面的问题。
场景三：多租户服务
通常一个企业内有多个业务线或部门部署自己的应用，不同的业务线或部门（多个租户）之间有着较强的隔离诉求，如金融类业务不期望自己的物理环境运行着其他非安全敏感应用，传统runC容器是无法有效避免不可信应用带来的潜在安全风险。这种情况下，通常会选择：
多个单租户集群，如金融业务集群和其他非安全敏感业务分隔到多个独立集群。
单个多租户集群，需把不同业务线应用分隔到不同的Namespace中，每个节点只可被某个业务线独占，配合资源配额、网络策略等实现多租户隔离。相对于多个单租户集群，管控面较少，管理成本较低，但仍然没有解决因某些租户资源利用率低导致节点资源闲置浪费问题。
有了安全沙箱（runV）容器后，可以把集群内不可信应用通过虚拟机沙箱隔离起来，而不用担心不可信应用容器逃逸造成的安全风险，这样所有节点都可以混合各类应用容器，这样做的好处是：
减少了资源调度的复杂度。
节点不再被单个业务独占，减少资源碎片，提高节点资源利用率，节省集群整体资源成本。
安全沙箱（runV）容器使用轻量级虚拟机，性能媲美runC容器。
