使用 Azure Kubernetes 服务（AKS）的 Pod 沙盒

为了帮助保护容器工作负载免受不受信任或潜在恶意代码的影响，AKS 现在包含一种称为 Pod 沙盒的机制。 Pod 沙盒在容器应用程序与容器主机的共享内核和计算资源（例如 CPU、内存和网络）之间提供隔离边界。应用程序在独立的轻型 Pod 虚拟机（VM）中启动。 Pod 沙盒通过整体体系结构补充其他安全措施或数据保护控制措施，帮助你满足保护敏感信息的法规、行业或治理合规性要求。

本文可帮助你了解此新功能及其实施方式。

先决条件

Azure CLI 版本 2.44.1 或更高版本。可通过运行 az --version 查找版本，运行 az upgrade 升级版本。如果需要进行安装或升级，请参阅安装 Azure CLI。
AKS 支持 Kubernetes 1.27.0 及更高版本的 Pod 沙盒功能。
若要管理 Kubernetes 群集，请使用 Kubernetes 命令行客户端 kubectl。随 kubectl 提供了 Azure Cloud Shell。可以使用 az aks install-cli 命令在本地安装 kubectl。

限制

以下是适用于 Pod 沙盒的约束：

Kata 容器可能无法达到传统容器可以在 Azure 文件和高性能本地 SSD 上达到的 IOPS 性能的极限。
Microsoft Defender for Containers 不支持评估 Kata 运行时 Pod。
不支持Kata主机网络访问。无法直接从 VM 内部访问主机网络配置。
在 Pod 沙盒中，CPU 和内存分配具有与 runc 不同的注意事项。参考注意事项页中的内存管理部分。

工作原理

AKS 上的 Pod 沙盒在开源 Kata 容器项目的基础上生成。在用于 AKS 的 Azure Linux 容器主机上运行的 Kata 容器提供基于 VM 的隔离，并为每个 Pod 提供单独的内核。 Pod 沙盒允许用户为每个 Pod 分配资源，并且这些资源不会与在同一主机上运行的其他 Kata Containers 或命名空间容器共享。

解决方案体系结构基于以下主要组件：

AKS 的 Azure Linux 容器主机
Microsoft Hyper-V 虚拟机监控程序
开放源代码 Cloud-Hypervisor 虚拟机监控程序 (VMM)
与 Kata 容器集成用于运行时

使用 Kata 容器部署 Pod 沙盒类似于部署容器的标准containerd工作流。启用了 Pod 沙盒的群集附带可在 Pod 清单（runtimeClassName: kata-vm-isolation）中引用的特定运行时类。

若要将此功能与 Pod 配合使用，唯一的区别是将 runtimeClassNamekata-vm-isolation 添加到 Pod 规范中。当 Pod 使用 kata-vm-isolation runtimeClass 时，虚拟机监控程序会启动一个带有自己内核的轻型虚拟机，以便工作负荷能够在其中正常运行。

部署新群集

执行以下步骤，使用 Azure CLI 来部署 Azure Linux AKS 群集。

使用 az aks create 命令并指定以下参数创建 AKS 群集：
- --workload-runtime：指定 KataVmIsolation 以在节点池上启用 Pod 沙盒功能。使用此参数时，这些其他参数应满足以下要求。否则，该命令将失败并报告相应参数的问题。
- --os-sku：AzureLinux。只有 Azure Linux os-sku 支持此功能。
- --node-vm-size：属于第 2 代 VM 并支持嵌套虚拟化的任何 Azure VM 大小都有效。例如，Dsv3 VM。
以下示例创建名为“myAKSCluster”的群集，其中一个节点位于 myResourceGroup 中：
```
az aks create
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --os-sku AzureLinux \
    --workload-runtime KataVmIsolation \
    --node-vm-size Standard_D4s_v3 \
    --node-count 3 \
    --generate-ssh-keys
```
运行以下命令以获取 Kubernetes 群集的访问凭据。使用 az aks get-credentials 命令，并替换群集名称和资源组名称的值。
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```
使用 kubectl get pods 命令列出所有命名空间中的所有 Pod。
```
kubectl get pods --all-namespaces
```

部署到现有群集

若要将此功能用于现有 AKS 群集，必须满足以下要求：

验证群集是否正在运行 Kubernetes 版本 1.27.0 及更高版本。

使用以下命令启用 Pod 沙盒化功能，并通过创建节点池来对其进行托管。

使用 az aks nodepool add 命令将节点池添加到 AKS 群集。指定下列参数：
- --resource-group：输入要在其中创建 AKS 群集的现有资源组的名称。
- --cluster-name：输入 AKS 群集的唯一名称，例如 myAKSCluster。
- --name：输入群集节点池的唯一名称，例如 nodepool2。
- --workload-runtime：指定 KataVmIsolation 以在节点池上启用 Pod 沙盒功能。除了 --workload-runtime 参数外，这些其他参数应满足以下要求。否则，该命令将失败并报告相应参数的问题。
  - --os-sku：AzureLinux。只有 Azure Linux os-sku 支持此功能。
  - --node-vm-size：属于第 2 代 VM 并支持嵌套虚拟化的任何 Azure VM 大小都有效。例如，Dsv3 VM。
以下示例将节点池添加到 myAKSCluster，其中一个节点位于 myResourceGroup 的 nodepool2 中：
```
az aks nodepool add --cluster-name myAKSCluster --resource-group myResourceGroup --name nodepool2 --os-sku AzureLinux --workload-runtime KataVmIsolation --node-vm-size Standard_D4s_v3
```

运行 az aks update 命令，在集群上启用 Pod 沙盒。

az aks update --name myAKSCluster --resource-group myResourceGroup

部署应用程序

使用 Pod 沙盒，可以同时部署不使用 Kata 运行时的“普通”Pod，以及使用 Kata 运行时的 Pod。两者在部署时的主要区别在于，Kata pod 的规格中有一行 runtimeClassName: kata-vm-isolation。

使用 Kata 运行时部署应用程序

若要在 AKS 群集上使用 Kata 运行时部署 Pod，请执行以下步骤。

创建名为 kata-app.yaml 的文件来描述你的 Kata Pod，然后粘贴以下的清单。

kind: Pod
apiVersion: v1
metadata:
  name: isolated-pod
spec:
  runtimeClassName: kata-vm-isolation
  containers:
  - name: kata
    image: mcr.azk8s.cn/aks/fundamental/base-ubuntu:v0.0.11
    command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]

runtimeClassNameSpec 的值为 kata-vm-isolation。

通过运行 kubectl apply 命令并指定 kata-app.yaml 文件来部署 Kubernetes Pod：
```
kubectl apply -f kata-app.yaml
```
该命令的输出类似于以下示例：
```
pod/isolated-pod created
```

（可选）验证内核隔离配置

如果你想验证 Kata Pod 与非 Kata Pod 在内核上的差异，可启动另一个不使用 Kata 运行时的工作负载。

kind: Pod
apiVersion: v1
metadata:
  name: normal-pod
spec:
  containers:
  - name: non-kata
    image: mcr.azk8s.cn/aks/fundamental/base-ubuntu:v0.0.11
    command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]

若要访问 AKS 群集内的容器，请运行 kubectl exec 命令来启动 shell 会话。在此示例中，你将访问 kata-pod 中的容器。
```
kubectl exec -it isolated-pod -- /bin/sh
```
Kubectl 连接到您的群集，在第一个容器内运行/bin/sh，并将您的终端的输入和输出流转发到isolated-pod的进程。还可以启动托管非 Kata Pod 的容器的 shell 会话，以查看差异。
从 kata-pod 启动 shell 会话到容器后，可以运行命令来验证 kata 容器是否在 pod 沙盒中运行。请注意，与沙箱外的非 Kata 容器相比，其内核版本不同。

若要查看内核版本，请运行以下命令：
```
uname -r
```
以下示例类似于 Pod 沙盒内核的输出：
```
[user]/# uname -r
6.6.96.mshv1
```
从 normal-pod 启动到容器的 shell 会话，以验证内核输出：
```
kubectl exec -it normal-pod -- /bin/bash
```
若要查看内核版本，请运行以下命令：
```
uname -r
```
以下示例类似于运行 normal-pod 的 VM 的输出，该内核与 Pod 沙盒中运行的 Kata Pod 不同：
```
6.6.100.mshv1-1.azl3
```

清理

完成此功能的评估后，为避免 Azure 费用，请清理不必要的资源。如果在评估或测试过程中部署了新群集，则可以使用 az aks delete 命令删除该群集。

az aks delete --resource-group myResourceGroup --name myAKSCluster

如果在现有群集上部署了 Pod 沙盒，则可以使用 kubectl delete pod 命令删除 Pod。

kubectl get pods
kubectl delete pod <kata-pod-name>

后续步骤

详细了解如何对 AKS 群集中的节点使用 Azure 专用主机，以便对 Azure 平台维护事件使用硬件隔离和控制。
若要进一步探索 Pod 沙盒隔离并探索工作负荷方案，请尝试 Pod 沙盒实验室。

Last updated on 2025-11-27