随着 AKS 群集不断扩展规模，并承载来自多个团队或租户的工作负载，共享基础设施会使隔离变得更加复杂。 你可能需要更强的隔离，以防止资源密集型或突发型工作负载干扰可预测的工作负载。 可能还需要隔离敏感工作负载以满足安全要求。
为了满足这些要求，可以通过逻辑或物理隔离策略隔离工作负荷。 对于逻辑隔离，请使用 Kubernetes 命名空间 分隔资源和部署。 命名空间共享基础群集基础结构，因此它们不提供与单独的群集相同的物理隔离边界。 虽然单独的群集提供物理边界，但当群集不使用其完整容量时，此策略可能会增加成本。
AKS 上的 Pod 沙盒化使你能够在独立的轻量级 Pod 虚拟机（VM）中运行工作负载。 每个 Pod VM 提供计算隔离边界：工作负荷使用自己的来宾内核运行，并与其他 Pod VM 中的主机内核和工作负荷隔离。
Pod 沙盒基于开源 Kata 容器 项目构建。
重要
Pod VM 边界仅提供计算隔离。 它不会隔离 AKS 控制平面、存储或数据路径，也不会隔离具有群集管理员访问权限的用户执行的操作。 仅靠 Pod 沙盒无法实现完整的硬隔离多租户。
体系结构和组件
Pod 沙盒化使用 Kata Containers 运行时为每个沙盒化 Pod 创建一个轻量级 Pod VM。 下图显示了主机端组件如何创建和管理隔离的 Pod VM 以及来宾端组件如何运行工作负荷。
- 在 Pod 清单中，将
runtimeClassName: kata-vm-isolation设为选择 Kata Containers 运行时。 - 容器调用 Kata 填充码（
containerd-shim-kata-v2）而不是标准运行时填充码。 - Kata shim 启动 Cloud Hypervisor 虚拟机监视器（VMM），由其创建一个包含独立客户机内核和 Kata agent 的 Pod 虚拟机。
- Kata 代理在 Pod VM 中创建和管理容器和工作负荷进程。
- 当 Pod VM 被删除时，Kata shim 会关闭该 Pod VM，并将其资源释放回容器主机。
优点和用例
Pod 沙盒化将每个被沙盒化的 Pod 隔离在一个具有其自身来宾内核的轻量级 Pod VM 中。 此计算边界将工作负荷与其他 Pod VM 中的主机内核和工作负荷分开。 将 Pod 沙盒与网络策略和Azure Policy等控件相结合，以解决 Pod VM 边界未涵盖的网络和管理风险。
常见用例
Pod 沙盒可以帮助你：
- 在同一 AKS 群集上托管来自不同租户的工作负荷，同时为每个沙盒 Pod 提供单独的计算隔离边界。
- 在继续使用共享群集容量的同时，将不受信任的工作负荷与其他 Pod VM 中的主机内核和工作负荷隔离开来。
- 保护敏感或高价值工作负载，使其免受其他 Pod VM 中运行的工作负载的影响。
- 通过将 CPU 和内存请求和限制应用于每个 Pod VM，减少资源密集型或突发工作负荷在其他沙盒 Pod 上的影响。
- 将工作负载故障导致的计算影响范围限制在其所属的 Pod VM 内。
工作负荷隔离
使用 Pod 沙盒，可以在共享群集节点上并置工作负载，同时为每个沙盒 Pod 维护单独的计算隔离边界。
可以为工作负荷声明资源请求和限制。 如果省略默认值，AKS 会应用默认值。 Pod VM 将资源密集型工作负荷限制为分配给该 VM 的 CPU 和内存。 如果工作负荷导致其 Pod VM 失败，则计算隔离边界可保护其他 Pod VM 中的工作负荷免受该故障的影响。
灵活性
可以在同一个集群中运行沙盒 Pod 和标准 Pod。 这种灵活性使你只能将 Pod VM 隔离应用于需要它的工作负荷。
开源组件
Pod 沙盒使用开源组件，包括 云虚拟机监控程序 VMM 和 Kata 容器 运行时。 开放开发提供隔离组件的透明度，并启用社区评审。 该体系结构还会将每个 Pod VM 中的来宾内核与 Azure Linux 主机内核分开。
迁移现有工作负载
对于基本部署，请将 Kata 运行时类添加到现有 Pod 规范，以在 Pod VM 中运行工作负荷。 此清单更改不能保证与使用标准 runc 运行时的 Pod 相同的行为。 在迁移之前，验证工作负载的运行行为以及 Kubernetes 功能兼容性，并将 Pod VM 的资源规格和开销考虑在内。 有关详细信息，请参阅 Pod 沙盒的注意事项。
后续步骤
- 在部署之前查阅Pod 沙盒化注意事项。
- 在 AKS 上部署 Pod 沙盒化。