Aislamiento de pods con Azure Kubernetes Service (AKS)

El aislamiento de pods en AKS usa Kata Containers para ejecutar cada pod aislado en una máquina virtual ligera (VM) con su propio kernel invitado. Este límite de computación aísla la carga de trabajo del kernel del host y de las cargas de trabajo de otras VM de pod. Para obtener más información sobre la arquitectura, las ventajas y los casos de uso, consulte Descripción general del aislamiento de pods en Azure Kubernetes Service (AKS).

En este artículo, desplegará el aislamiento de pods en un clúster de AKS de Azure Linux nuevo o existente, desplegará una aplicación con el runtime Kata y, opcionalmente, verificará el aislamiento del kernel.

Requisitos previos

  • La CLI de Azure versión 2.80.0 o posterior. Ejecute az --version para buscar la versión de la CLI de Azure y ejecutarla az upgrade para actualizarla. Para más información, consulte los pasos descritos en Instalación de la CLI de Azure.
  • AKS admite el aislamiento de pods en Kubernetes 1.27.0 y versiones posteriores.
  • Para administrar un clúster de Kubernetes, use el cliente kubectlde línea de comandos de Kubernetes . Azure Cloud Shell viene con kubectl. Puede instalar kubectl localmente mediante el az aks install-cli comando .

Limitaciones

Las siguientes restricciones se aplican al aislamiento de pods:

  • Es posible que los contenedores kata no alcancen los límites de rendimiento de IOPS que los contenedores tradicionales pueden alcanzar en Azure Files y SSD local de alto rendimiento.
  • Microsoft Defender para contenedores no admite la evaluación de pods en tiempo de ejecución de Kata.
  • El acceso de red del host de kata no está admitido. No puede acceder directamente a la configuración de red del host desde la máquina virtual.
  • La asignación de CPU y memoria con aislamiento de pods difiere de runc. Cada pod de Kata se ejecuta en una VM de pod cuyo tamaño fijo de memoria depende del límite de memoria del pod, o usa 512Mi de forma predeterminada si no especificas ningún límite. Los límites de CPU determinan la asignación de vCPU de la máquina virtual de pod y los límites fraccionarios se redondean hasta una vCPU completa para esa asignación. Para más información, consulte Consideraciones sobre el espacio aislado de pods.
  • El aislamiento de pods solo es compatible con Azure Linux. Ubuntu y Windows no son compatibles. Para más información, consulte host de contenedores Azure Linux para AKS.
  • No se puede habilitar Federal Information Processing Standard (FIPS) ni Trusted Launch en un grupo de nodos que use aislamiento de pods. Para más información, consulte Consideraciones sobre el espacio aislado de pods.
  • La arquitectura Arm64 no es compatible con un grupo de nodos que utilice el aislamiento de pods.

Funcionamiento

El pod sandboxing en AKS se basa en el proyecto de código abierto Kata Containers. Kata Containers, que se ejecuta en el host de contenedores Azure Linux para AKS, proporciona aislamiento basado en VM y un kernel independiente para cada pod. El aislamiento de pods permite asignar recursos a cada pod y no compartirlos con otros Kata Containers ni con contenedores de espacio de nombres que se ejecutan en el mismo anfitrión.

La arquitectura de la solución se basa en los siguientes componentes principales:

Implementar el aislamiento de pods con Kata Containers es similar al flujo de trabajo estándar containerd para desplegar contenedores. Los clústeres con aislamiento de pods habilitado vienen con una RuntimeClass específica a la que se puede hacer referencia en un manifiesto de pod (runtimeClassName: kata-vm-isolation). Para obtener más información sobre los valores predeterminados y la personalización de las clases de tiempo de ejecución, consulte Consideraciones sobre el pod sandboxing.

Para usar esta característica con un pod, la única diferencia es agregar runtimeClassNamekata-vm-isolation a la especificación de pod. Cuando un pod usa runtimeClasskata-vm-isolation, el hipervisor pone en marcha una máquina virtual ligera con su propio kernel, para que la carga de trabajo funcione.

Crear un clúster con aislamiento de pods

Siga los pasos siguientes para implementar clústeres de AKS en Linux en Azure con la CLI de Azure.

  1. Cree un clúster de AKS ejecutando el az aks create comando con los parámetros siguientes:

    Parámetro Valor requerido Notas
    --workload-runtime KataVmIsolation Habilita el aislamiento de pods en el grupo de nodos.
    --os-sku AzureLinux El espacio aislado de pod solo admite la SKU del sistema operativo Linux de Azure.
    --node-vm-size Tamaño de máquina virtual de generación 2 que admite la virtualización anidada Por ejemplo, use un tamaño de máquina virtual de la serie Dsv3 .
    --node-count 3 Crea tres nodos para este ejemplo. Ajuste el valor de la carga de trabajo.

    En el ejemplo siguiente se crea un clúster denominado myAKSCluster con tres nodos en 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

  2. Ejecute el siguiente comando para obtener las credenciales de acceso del clúster de Kubernetes. Use el az aks get-credentials comando y reemplace los valores del nombre del clúster y el nombre del grupo de recursos.

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

  3. Enumere todos los pods de todos los espacios de nombres ejecutando el comando kubectl get pods.

    kubectl get pods --all-namespaces

Habilitar el aislamiento de pods en un clúster existente

Para usar esta característica con un clúster de AKS existente, se deben cumplir los siguientes requisitos:

  • El clúster ejecuta la versión 1.27.0 o posterior de Kubernetes.

  • Utilice el siguiente comando para habilitar el aislamiento de Pods mediante la creación de un grupo de nodos que lo aloje.

  1. Agregue un grupo de nodos al clúster de AKS mediante el az aks nodepool add comando con los parámetros siguientes:

    Parámetro Valor requerido Notas
    --resource-group El grupo de recursos que contiene el clúster de AKS existente Por ejemplo, use myResourceGroup.
    --cluster-name Nombre del clúster de AKS existente Por ejemplo, use myAKSCluster.
    --name Un nombre de grupo de nodos único Por ejemplo, use nodepool2.
    --workload-runtime KataVmIsolation Habilita el aislamiento de pods en el grupo de nodos.
    --os-sku AzureLinux El espacio aislado de pod solo admite la SKU del sistema operativo Linux de Azure.
    --node-vm-size Tamaño de máquina virtual de generación 2 que admite la virtualización anidada Por ejemplo, use un tamaño de máquina virtual de la serie Dsv3 .
    --node-count 1 Crea un nodo para este ejemplo. Ajuste el valor de la carga de trabajo.

    En el ejemplo siguiente se agrega un grupo de nodos a myAKSCluster con un nodo en nodepool2 en myResourceGroup:

    az aks nodepool add --cluster-name myAKSCluster --resource-group myResourceGroup --name nodepool2 --os-sku AzureLinux --workload-runtime KataVmIsolation --node-vm-size Standard_D4s_v3 --node-count 1

  2. Ejecute el az aks update comando para conciliar la configuración del clúster para que el clúster reconozca el nuevo grupo de nodos con el entorno de ejecución de la KataVmIsolation carga de trabajo.

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

  3. Compruebe que la actualización del clúster se completó correctamente y que el grupo de nodos de espacio aislado de pod usa el tiempo de ejecución de carga de trabajo esperado, la SKU del sistema operativo y el tamaño de la máquina virtual.

    az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query provisioningState \
    --output tsv

az aks nodepool show \
    --cluster-name myAKSCluster \
    --resource-group myResourceGroup \
    --name nodepool2 \
    --query "{workloadRuntime:workloadRuntime, osSKU:osSKU, vmSize:vmSize}" \
    --output table

    El estado de aprovisionamiento del clúster debe ser Succeeded. La salida del grupo de nodos debe mostrar KataVmIsolation, AzureLinuxy el tamaño de máquina virtual seleccionado.

Desplegar aplicaciones mediante el aislamiento de pods

Al usar el aislamiento de pods, puede desplegar una combinación de pods estándar que no usan el entorno de ejecución Kata junto con pods Kata que usan ese entorno de ejecución. Un pod de Kata especifica runtimeClassName: kata-vm-isolation en la especificación del pod.

La clase de tiempo de ejecución selecciona el tiempo de ejecución de Kata, pero también debes definir restricciones de programación cuando necesites que las cargas de trabajo se ejecuten en un grupo de nodos de sandboxing de Pod específico. Por ejemplo, utilice la etiqueta integrada del grupo de nodos de AKS en un nodeSelector. Sustituye nodepool2 por el nombre de tu grupo de nodos de sandboxing de Pod.

spec:
  runtimeClassName: kata-vm-isolation
  nodeSelector:
    kubernetes.azure.com/agentpool: nodepool2

Para lograr un mayor aislamiento, puede aplicar un taint al grupo de nodos para el aislamiento de pods y añadir una tolerancia correspondiente a las cargas de trabajo de Kata. Una marca de contaminación sin una tolerancia correspondiente impide que otras cargas de trabajo se programen en ese grupo de nodos. Para obtener más información, consulta Uso de marcas de contaminación de nodos en un clúster de AKS.

Implementación de una aplicación con el entorno de ejecución kata

Para implementar un pod con el entorno de ejecución Kata en el clúster de AKS, siga los pasos siguientes.

  1. Cree un archivo denominado kata-app.yaml para describir un pod de kata y, a continuación, pegue el manifiesto siguiente.

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

    El valor de la especificación del pod para runtimeClassName es kata-vm-isolation.

  2. Implemente el pod de Kubernetes ejecutando el comando kubectl apply y especifique su archivo kata-app.yaml:

    kubectl apply -f kata-app.yaml

    La salida del comando es similar al ejemplo siguiente:

    pod/isolated-pod created

Comprobación del aislamiento del kernel (opcional)

  1. Para comparar los kernels de Kata y los pods no Kata, cree un archivo llamado normal-app.yaml. El siguiente manifiesto define un pod estándar sin el runtime de Kata:
kind: Pod
apiVersion: v1
metadata:
  name: normal-pod
spec:
  containers:
  - name: non-kata
    image: mcr.microsoft.com/aks/fundamental/base-ubuntu:v0.0.11
    command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]

  1. Implemente el pod estándar mediante el kubectl apply comando .

    kubectl apply -f normal-app.yaml

  2. Para acceder a un contenedor dentro del clúster de AKS, inicie una sesión de shell mediante la ejecución del kubectl exec comando . En este ejemplo, va a acceder al contenedor dentro de un pod aislado.

    kubectl exec -it isolated-pod -- /bin/sh

    Kubectl se conecta al clúster, ejecuta /bin/sh dentro del primer contenedor de isolated-pod, y reenvía los flujos de entrada y salida del terminal al proceso del contenedor. También puedes iniciar una sesión de shell en el contenedor que hospeda el pod no-Kata para ver las diferencias.

  3. Después de iniciar una sesión de shell en el contenedor desde isolated-pod, ejecute comandos para comprobar que el contenedor kata se está ejecutando en un entorno de aislamiento de pods. Tiene una versión del núcleo diferente en comparación con el contenedor no Kata fuera del entorno aislado.

    Para ver la versión del kernel, ejecute el comando siguiente:

    uname -r

    El ejemplo siguiente es similar a la salida del kernel del espacio aislado del pod:

    [user]/# uname -r
6.6.96.mshv1

  4. Inicie una sesión shell en el contenedor desde normal-pod para verificar la salida del kernel:

    kubectl exec -it normal-pod -- /bin/bash

    Para ver la versión del kernel, ejecute el comando siguiente:

    uname -r

    El ejemplo siguiente se parece a la salida de la VM que ejecuta normal-pod, que es un kernel diferente al pod de Kata que se ejecuta en el aislamiento del pod:

    6.6.100.mshv1-1.azl3

Limpieza de recursos

  1. Cuando termine de evaluar esta función, elimine los recursos que ya no necesite para evitar cargos de Azure. Si ha implementado un nuevo clúster como parte de la evaluación o las pruebas, ejecute el siguiente az aks delete comando para eliminar el clúster de AKS.

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

  2. Si ha desplegado el aislamiento de pods en un clúster existente, puede eliminar los pods mediante el comando kubectl delete pod.

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

  3. Para eliminar los recursos de proceso del entorno de aislamiento de pods, también puede eliminar el grupo de nodos de Kata mediante el comando az aks nodepool delete. Antes de eliminar el grupo de nodos, asegúrese de que no hay cargas de trabajo que quiera conservar en él.

    az aks nodepool delete \
  --cluster-name myAKSCluster \
  --resource-group myResourceGroup \
  --name nodepool2

Pasos siguientes

  • Obtenga más información sobre los hosts dedicados de Azure para los nodos con el clúster de AKS para usar el aislamiento de hardware y el control sobre los eventos de mantenimiento iniciados por la plataforma Azure.
  • Para profundizar en el aislamiento de pods y explorar escenarios de cargas de trabajo, pruebe los laboratorios de aislamiento de pods.
  • Se actualizó por última vez el