概述

本文档介绍 CCE 安全容器的架构、核心优势、适用场景和使用限制。安全容器运行时将应用及其依赖环境运行在轻量级虚拟机中，为应用 Pod 提供独立内核层模拟或者细粒度的隔离层，这样可以有效防止容器内部的恶意攻击或漏洞，避免影响到宿主机或其他容器。

背景信息

安全容器特别适合于不可信应用隔离、故障隔离、性能隔离、多用户间负载隔离等场景。在提升安全性的同时，对性能影响非常小，并且具备与 Docker 容器一样的用户体验，例如日志、监控、弹性等。

架构图

核心优势

安全容器是基于社区 Kata Containers 轻量虚拟机技术构建的安全容器运行时，主要核心优势如下：

• 基于轻量虚拟机，实现沙箱之间的超强隔离。
• 具有传统 runC 容器的应用兼容性。
• 在监控、日志、存储等方面有着与 runC 一致的使用体验。
• 使用门槛低，简单易用。
• 兼容开源社区 Kata Containers，有关 Kata Containers 的详细信息，请参见 Kata Containers。

CCE 安全容器适用场景

场景一：安全沙箱容器可以强隔离不可信应用

安全容器可以隔离潜在安全风险。

通过把存在潜在安全风险的应用放置到成熟的轻量级虚拟机安全容器中，应用运行在独立的 GuestOS Kernel 上。即便 GuestOS Kernel 出现安全漏洞，攻击破坏面也仅限于一个安全容器内，不会对 Host Kernel 以及其他容器产生任何影响。安全容器配合 Terway 的 NetworkPolicy 能力，可以灵活地配置 Pod 的网络访问策略，真正做到系统隔离、数据隔离以及网络隔离。

场景二：解决故障放大、资源争抢、性能干扰方面的问题

Kubernetes 使得我们很容易在一个节点上混合部署不同的应用容器。由于 Cgroups 并不能很好地解决资源争抢问题，同一节点上相同资源密集型（如 CPU 密集型、IO 密集型等）的不同应用会相互争抢资源，导致应用的响应时间出现严重波动，总体响应时间偏长。当节点上某一应用异常和故障，如内存泄露、频繁 CoreDump 等，导致节点整体负载升高，或者单容器触发 Host Kernel Bug 导致系统宕机时，单应用的故障可能延展到整个节点，甚至进一步导致整个集群不响应。安全容器通过独立的 GuestOS Kernel 和 Hypervisor，可以很好地解决 Containerd 容器在故障放大、资源争抢、性能干扰方面的问题。

场景三：多租户服务

通常，一个企业内有多个业务线或部门部署自己的应用，不同的业务线或部门（多个租户）之间有着较强的隔离诉求。例如，金融类业务不期望自己的物理环境运行着其他非安全敏感应用，而传统容器无法有效避免不可信应用带来的潜在安全风险。有了安全容器后，可以把集群内不可信应用通过虚拟机沙箱隔离起来，而不用担心不可信应用容器逃逸造成的安全风险。这样，所有节点都可以混合运行各类应用容器，这样做的好处是：

• 减少了资源调度的复杂度。
• 节点不再被单个业务独占，减少资源碎片，提高节点资源利用率，节省集群整体资源成本。

使用限制

• 集群版本：仅支持 1.28 及以上版本的 CCE 托管集群或 CCE 独立集群。
• 操作系统：安全容器节点组不支持自定义镜像和 GPU 镜像，仅支持公共镜像 Baidu Linux 3。

• 实例规格：仅支持弹性裸金属服务器规格下的这三种套餐：

  • ebc.l5.c128m512.4d
  • ebc.l7.c208m1024.2d
  • ebc.l5.c128m512.1d
• 网络模式：安全容器节点组仅支持 VPC-ENI 网络模式，不支持独占弹性网卡模式，不支持启用 DataPath v2 功能。