Compartir a través de

Aislamiento de pods con Azure Kubernetes Service (AKS)

Para ayudar a proteger las cargas de trabajo de contenedores frente a código no confiable o potencialmente malintencionado, AKS ahora incluye un mecanismo denominado Pod Sandboxing. Los espacios aislados de pods proporcionan un límite de aislamiento entre la aplicación contenedora y el kernel compartido y los recursos de proceso (CPU, memoria y red) del host de contenedor. Las aplicaciones se activan en máquinas virtuales tipo pod, que son aisladas y ligeras. Espacios aislados de pods complementa otras medidas de seguridad o controles de protección de datos con su arquitectura general para ayudarle a cumplir los requisitos normativos, del sector o de cumplimiento de gobernanza para proteger la información confidencial.

Este artículo le ayuda a comprender e implementar esta nueva característica.

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 la versión 1.27.0 y posteriores de Kubernetes.

  • Para administrar un clúster de Kubernetes, use kubectl, el cliente de línea de comandos de Kubernetes. Azure Cloud Shell viene con kubectl. Puede instalar kubectl localmente. Para ello debe usar el comando az aks install-cli.

Limitaciones

A continuación se muestran restricciones aplicables 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 es posible acceder directamente a la configuración de red del host desde la máquina virtual.

  • La asignación de CPU y memoria con el aislamiento de pods tiene otras consideraciones en comparación con runc. Haga referencia a las secciones de administración de memoria en la página de consideraciones.

Funcionamiento

El aislamiento de pods en AKS se basa en el proyecto de código abierto Kata Containers. Los Contenedores Kata que se ejecutan en el host de contenedores Linux de Azure para AKS proporcionan aislamiento basado en VM y un kernel independiente para cada pod. El aislamiento de pods permite a los usuarios asignar recursos para cada pod y no comparte esos recursos con otros Kata Containers o contenedores de espacio de nombres que se ejecutan en el mismo host.

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

La implementación de aislamiento de pods con Kata Containers es similar al flujo de trabajo de containerd estándar para implementar contenedores. Los clústeres con el aislamiento de pods habilitado incluyen una clase de tiempo de ejecución específica a la que se puede hacer referencia en un manifiesto de pod (runtimeClassName: kata-vm-isolation).

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.

Implementación de un nuevo clúster

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 mediante el comando az aks create y especifique los parámetros siguientes:

    • --workload-runtime: Especifique KataVmIsolation para habilitar la característica de aislamiento de pods en el grupo de nodos. Con este parámetro, estos otros parámetros deben cumplir los siguientes requisitos. De lo contrario, el comando produce un error y notifica un problema con los parámetros correspondientes.
    • --os-sku: AzureLinux. Solo el SKU de Azure Linux admite esta funcionalidad.
    • --node-vm-size: Cualquier tamaño de VM de Azure que sea una VM de 2.ª generación y admita trabajos de virtualización anidada. Por ejemplo, VM Dsv3.

    En el siguiente ejemplo se crea un clúster denominado myAKSCluster con un nodo 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 comando az aks get-credentials 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 mediante el comando kubectl get pods.

    kubectl get pods --all-namespaces

Implementación en un clúster existente

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

  • Compruebe que el clúster ejecuta kubernetes versión 1.27.0 y versiones posteriores.

Use el siguiente comando para habilitar el sandboxing de Pods mediante la creación de un grupo de nodos para hospedarlo.

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

    • --resource-group: Escriba el nombre de un grupo de recursos existente en el que va a crear el clúster de AKS.
    • --cluster-name: Escriba un nombre único para el clúster de AKS, como myAKSCluster.
    • --name: Escriba un nombre único para el grupo de nodos de clústeres, como nodepool2.
    • --workload-runtime: Especifique KataVmIsolation para habilitar la característica de aislamiento de pods en el grupo de nodos. Junto con el parámetro --workload-runtime, estos otros parámetros cumplirán los siguientes requisitos. De lo contrario, se produce un error en el comando e informa de un problema con el parámetro correspondiente.
      • --os-sku: AzureLinux. Solo el SKU de Azure Linux admite esta funcionalidad.
      • --node-vm-size: Cualquier tamaño de VM de Azure que sea una VM de 2.ª generación y admita trabajos de virtualización anidada. Por ejemplo, VM Dsv3.

    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

  2. Ejecute el comando az aks update para habilitar el aislamiento de pods en el clúster.

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

Implementación de las aplicaciones

Con el aislamiento de pods, puede implementar una combinación de pods "normales" que no usan el runtime de Kata junto con pods Kata que sí usan el runtime. La principal diferencia entre los dos, al implementar, se encuentra en el hecho de que un pod Kata tiene la línea runtimeClassName: kata-vm-isolation en su especificación.

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 runtimeClassNameSpec es kata-vm-isolation.

  2. Implemente el pod de Kubernetes mediante la ejecución del comando kubectl apply y especifique el archivo kata-app.yaml :

    kubectl apply -f kata-app.yaml

    La salida del comando es similar al ejemplo siguiente:

    pod/isolated-pod created

(Opcional) Comprobación de la configuración del aislamiento de kernel

Si desea comprobar la diferencia entre el kernel de un pod con Kata y uno sin Kata, puede iniciar otra carga de trabajo que no tenga el tiempo de ejecución 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. Para acceder a un contenedor dentro del clúster de AKS, inicie una sesión de shell con el comando kubectl exec. En este ejemplo, estás accediendo al contenedor dentro de kata-pod.

    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.

  2. Después de iniciar una sesión de shell en el contenedor desde kata-pod, puede ejecutar comandos para comprobar que el contenedor de kata se ejecuta en un aislamiento de pod. Verá que tiene una versión de kernel diferente en comparación con el contenedor de kata fuera del aislamiento.

    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

  3. 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

Cuando haya terminado de evaluar esta característica, para evitar cargos de Azure, limpie los recursos innecesarios. Si ha implementado un nuevo clúster como parte de la evaluación o prueba, puede eliminar el clúster con el comando az aks delete.

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

Si ha implementado Pod Sandboxing en un clúster existente, puede quitar los pods mediante el comando kubectl delete pod .

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

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 investigar aún más el aislamiento de Pod Sandboxing y explorar escenarios de carga de trabajo, pruebe los laboratorios de Pod Sandboxing.
  • Last updated on