Compartir a través de

Pod 沙盒(预览版)与 Azure Kubernetes 服务 (AKS)

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

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

先决条件

  • Azure CLI 版本 2.44.1 或更高版本。 可通过运行 az --version 查找版本,运行 az upgrade 升级版本。 如果需要进行安装或升级,请参阅安装 Azure CLI

  • aks-preview Azure CLI 扩展版本 0.5.123 或更高版本。

  • 在 Azure 订阅中注册 KataVMIsolationPreview 功能。

  • AKS 在 1.24.0 及更高版本上支持 Pod 沙盒(预览版)以及所有 AKS 网络插件。

  • 若要管理 Kubernetes 群集,请使用 Kubernetes 命令行客户端 kubectl。 随 kubectl 提供了 Azure Cloud Shell。 可以使用 az aks install-cli 命令在本地安装 kubectl。

安装 aks-preview Azure CLI 扩展

重要

AKS 预览功能是可选择启用的自助功能。 预览功能是“按现状”和“按可用”提供的,不包括在服务级别协议和有限保证中。 AKS 预览功能是由客户支持尽最大努力部分覆盖。 因此,这些功能并不适合用于生产。 有关详细信息,请参阅以下支持文章:

若要安装 aks-preview 扩展,请运行以下命令:

az extension add --name aks-preview

运行以下命令以更新到已发布的最新扩展版本:

az extension update --name aks-preview

注册 KataVMIsolationPreview 功能标志

使用 KataVMIsolationPreview 命令注册 KataVMIsolationPreview 功能标志,如以下示例所示:

az feature register --namespace "Microsoft.ContainerService" --name "KataVMIsolationPreview"

状态显示为“已注册”需要几分钟时间。 使用 az feature show 命令验证注册状态:

az feature show --namespace "Microsoft.ContainerService" --name "KataVMIsolationPreview"

当状态反映为“已注册”时,使用 az provider register 命令刷新 Microsoft.ContainerService 资源提供程序的注册:

az provider register --namespace "Microsoft.ContainerService"

限制

以下是此 Pod 沙盒(预览版)预览版的约束:

工作原理

为了在 AKS 上实现此功能,在 AKS 堆栈的 Azure Linux 容器主机上运行的 Kata 容器提供了由硬件实施的隔离。 Pod 沙盒扩展了硬件隔离的优势,例如每个 Kata Pod 都有单独的内核。 硬件隔离为每个 Pod 分配资源,不与同一主机上运行的其他 Kata 容器或命名空间容器共享资源。

解决方案体系结构基于以下组件:

使用 Kata 容器部署 Pod 沙盒类似于部署容器的标准容器化工作流。 部署包括可在 Pod 模板中定义的 kata 运行时选项。

若要将此功能与 Pod 配合使用,唯一的区别是将 runtimeClassName kata-mshv-vm-isolation 添加到 Pod 规范。

当 Pod 使用 kata-mshv-vm-isolation runtimeClass 时,它会创建一个 VM 作为 Pod 沙盒来托管容器。 如果容器资源清单 (containers[].resources.limits) 未指定 CPU 和内存限制,则 VM 的默认内存为 2 GB,默认 CPU 为一个核心。 在容器资源清单中指定 CPU 或内存限制时,VM 具有 containers[].resources.limits.cpucontainers[].resources.limits.memory,前者参数为 1,表示使用 1 个 + xCPU,后者参数为 2,指定 2 GB + yMemory。 容器只能使用 CPU 和内存来限制容器。 在此预览版中将忽略 containers[].resources.requests,并且我们正努力减少 CPU 和内存开销。

部署新群集

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

  1. 使用 az aks create 命令并指定以下参数创建 AKS 群集:

    • --workload-runtime:指定 KataMshvVmIsolation 以在节点池上启用 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 KataMshvVmIsolation \
        --node-vm-size Standard_D4s_v3 \
        --node-count 1 \
        --generate-ssh-keys
    
  2. 运行以下命令以获取 Kubernetes 群集的访问凭据。 使用 az aks get-credentials 命令,并替换群集名称和资源组名称的值。

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
    
  3. 使用 kubectl get pods 命令列出所有命名空间中的所有 Pod。

    kubectl get pods --all-namespaces
    

部署到现有群集

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

使用以下命令,通过创建节点池来启用 Pod 沙盒(预览版)以托管它。

  1. 使用 az aks nodepool add 命令将节点池添加到 AKS 群集。 指定下列参数:

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

    以下示例将节点池添加到 myAKSCluster,其中一个节点位于 myResourceGroupnodepool2 中:

    az aks nodepool add --cluster-name myAKSCluster --resource-group myResourceGroup --name nodepool2 --os-sku AzureLinux --workload-runtime KataMshvVmIsolation --node-vm-size Standard_D4s_v3
    
  2. 运行 az aks update 命令,在群集上启用 Pod 沙盒(预览版)。

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

部署受信任的应用程序

若要演示在 AKS 群集的共享内核上部署受信任的应用程序,请执行以下步骤。

  1. 创建名为 trusted-app.yaml 的文件来描述受信任的 Pod,然后粘贴以下清单。

    kind: Pod
    apiVersion: v1
    metadata:
      name: trusted
    spec:
      containers:
      - name: trusted
        image: mcr.azk8s.cn/aks/fundamental/base-ubuntu:v0.0.11
        command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]
    
  2. 通过运行 kubectl apply 命令并指定 trusted-app.yaml 文件来部署 Kubernetes Pod:

    kubectl apply -f trusted-app.yaml
    

    该命令的输出类似于以下示例:

    pod/trusted created
    

部署不受信任的应用程序

若要演示在 AKS 群集的 Pod 沙盒上部署不受信任的应用程序,请执行以下步骤。

  1. 创建名为 untrusted-app.yaml 的文件来描述不受信任的 Pod,然后粘贴以下清单。

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

    runtimeClassNameSpec 的值为 kata-mhsv-vm-isolation

  2. 通过运行 kubectl apply 命令并指定 untrusted-app.yaml 文件来部署 Kubernetes Pod:

    kubectl apply -f untrusted-app.yaml
    

    该命令的输出类似于以下示例:

    pod/untrusted created
    

验证内核隔离配置

  1. 若要访问 AKS 群集内的容器,请运行 kubectl exec 命令来启动 shell 会话。 在此示例中,你将访问不受信任 Pod 内的容器。

    kubectl exec -it untrusted -- /bin/bash
    

    Kubectl 连接到你的群集,在不受信任 Pod 内的第一个容器内运行 /bin/sh,并将终端的输入和输出流转发到容器的进程。 还可以启动与托管受信任 Pod 的容器的 shell 会话。

  2. 启动与不受信任 Pod 的容器的 shell 会话后,可以运行命令来验证不受信任容器是否在 Pod 沙盒中运行。 你会注意到,与沙盒外部的受信任容器相比,它具有不同的内核版本。

    若要查看内核版本,请运行以下命令:

    uname -r
    

    以下示例类似于 Pod 沙盒内核的输出:

    root@untrusted:/# uname -r
    5.15.48.1-8.cm2
    
  3. 启动与受信任 Pod 的容器的 shell 会话,以验证内核输出:

    kubectl exec -it trusted -- /bin/bash
    

    若要查看内核版本,请运行以下命令:

    uname -r
    

    以下示例类似于运行受信任 Pod 的 VM 的输出,该内核与 Pod 沙盒中运行的不受信任 Pod 不同:

    5.15.80.mshv2-hvl1.m2
    

清理

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

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

如果在现有群集上启用了 Pod 沙盒(预览版),则可以使用 kubectl delete pod 命令删除 Pod。

kubectl delete pod pod-name

后续步骤

详细了解如何对 AKS 群集中的节点使用 Azure 专用主机,以便对 Azure 平台维护事件使用硬件隔离和控制。