Isolation des pods avec Azure Kubernetes Service (AKS)

Sur AKS, l’isolation des pods utilise Kata Containers pour exécuter chaque pod isolé dans une machine virtuelle légère (VM) avec son propre noyau invité. Cette limite de calcul isole la charge de travail du noyau hôte et des charges de travail dans d’autres machines virtuelles pod. Pour en savoir plus sur l’architecture, les avantages et les cas d’usage, consultez Vue d’ensemble du bac à sable pod dans Azure Kubernetes Service (AKS).

Dans cet article, vous déployez le sandboxing de pod sur un cluster AKS Linux Azure nouveau ou existant, déployez une application avec le runtime Kata et vérifiez éventuellement l’isolation du noyau.

Prérequis

  • Azure CLI version 2.80.0 ou ultérieure. Exécutez az --version pour rechercher la version de votre interface de ligne de commande Azure, puis exécutez-la pour effectuer az upgrade la mise à niveau. Pour plus d’informations, consultez les étapes de l’installation d’Azure CLI.
  • AKS prend en charge le sandboxing des pods à partir de la version 1.27.0 de Kubernetes.
  • Pour gérer un cluster Kubernetes, utilisez le client kubectlde ligne de commande Kubernetes. Azure Cloud Shell comprend kubectl. Vous pouvez installer kubectl localement à l’aide de la az aks install-cli commande.

Limites

Les contraintes suivantes s’appliquent au sandboxing de pod :

  • Les conteneurs Kata peuvent ne pas atteindre les limites de performances d’IOPS que les conteneurs traditionnels peuvent atteindre sur Azure Files et ssd local hautes performances.
  • Microsoft Defender pour les conteneurs ne prend pas en charge l’évaluation des pods d’exécution Kata.
  • L’accès au réseau hôte Kata n’est pas pris en charge. Vous ne pouvez pas accéder directement à la configuration réseau de l’hôte à partir de la machine virtuelle.
  • L’allocation des ressources CPU et mémoire avec l’isolation des pods diffère de runc. Chaque pod Kata s’exécute dans une machine virtuelle de pod dont la taille de mémoire fixe est basée sur la limite de mémoire des pods ou est définie par défaut sur 512Mi si vous ne spécifiez pas de limite. Les limites du processeur déterminent l’allocation de processeurs virtuels de la machine virtuelle pod et les limites fractionnaires sont arrondies à un processeur virtuel entier pour cette allocation. Pour plus d’informations, consultez Considérations relatives à l’isolation des pods.
  • L’isolation des pods est prise en charge uniquement sur Azure Linux. Ubuntu et Windows ne sont pas pris en charge. Pour plus d’informations, consultez l’hôte de conteneur Azure Linux pour AKS.
  • Vous ne pouvez pas activer la norme FIPS (Federal Information Processing Standard) ni Trusted Launch sur un pool de nœuds qui utilise l’isolation de pod. Pour plus d’informations, consultez Considérations relatives à l’isolation des pods.
  • L’architecture Arm64 n’est pas prise en charge sur un pool de nœuds qui utilise le sandboxing de pod.

Fonctionnement

Le bac à sable de pods sur AKS s’appuie sur le projet Kata Containers open source. Les conteneurs Kata s’exécutant sur l’hôte de conteneur Linux Azure pour AKS fournissent une isolation basée sur une machine virtuelle et un noyau distinct pour chaque pod. Le sandboxing de pod permet d'allouer des ressources à chaque pod et ne les partage pas avec d’autres conteneurs Kata ou des conteneurs d’espaces de noms s’exécutant sur le même hôte.

L’architecture de la solution est basée sur les composants principaux suivants :

Le déploiement du bac à sable pod à l’aide de Kata Containers est similaire au flux de travail standard containerd pour déployer des conteneurs. Les clusters avec bac à sable pod activé sont fournis avec une classe runtime spécifique que vous pouvez référencer dans un manifeste de pod (runtimeClassName: kata-vm-isolation). Pour plus d’informations sur les paramètres par défaut et la personnalisation de la classe d’exécution, consultez Considérations relatives à l’isolation des pods.

Pour utiliser cette fonctionnalité avec un pod, l’unique différence consiste à ajouter le runtimeClassName, kata-vm-isolation à la spécification du pod. Lorsqu’un pod utilise la runtimeClass kata-vm-isolation, l’hyperviseur démarre une machine virtuelle légère avec son propre noyau, dans lequel la charge de travail peut s’exécuter.

Créer un cluster avec le sandboxing de pod

Effectuez les étapes suivantes pour déployer un cluster AKS Azure Linux en utilisant l’interface de ligne de commande Azure.

  1. Créez un cluster AKS en exécutant la az aks create commande avec les paramètres suivants :

    Paramètre Valeur requise Notes
    --workload-runtime KataVmIsolation Active le bac à sable pod sur le pool de nœuds.
    --os-sku AzureLinux Le sandboxing de pod prend uniquement en charge la référence SKU du système d’exploitation Linux Azure.
    --node-vm-size Taille de machine virtuelle de génération 2 qui prend en charge la virtualisation imbriquée Par exemple, utilisez une taille de machine virtuelle de la série Dsv3.
    --node-count 3 Crée trois nœuds pour cet exemple. Ajustez la valeur de votre charge de travail.

    L’exemple suivant crée un cluster nommé myAKSCluster avec trois nœuds dans 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. Exécutez la commande suivante pour obtenir les informations d'identification d'accès au cluster Kubernetes. Utilisez la az aks get-credentials commande et remplacez les valeurs du nom du cluster et du nom du groupe de ressources.

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

  3. Répertoriez tous les pods dans tous les espaces de noms en exécutant la kubectl get pods commande.

    kubectl get pods --all-namespaces

Activer le sandboxing de pod sur un cluster existant

Pour utiliser cette fonctionnalité avec un cluster AKS existant, les conditions suivantes doivent être satisfaites :

  • Le cluster exécute Kubernetes version 1.27.0 ou ultérieure.

  • Utilisez la commande suivante pour activer le sandboxing de pod en créant le pool de nœuds pour l’héberger.

  1. Ajoutez un pool de nœuds à votre cluster AKS à l’aide de la az aks nodepool add commande avec les paramètres suivants :

    Paramètre Valeur requise Notes
    --resource-group Groupe de ressources qui contient le cluster AKS existant Par exemple, utilisez myResourceGroup.
    --cluster-name Nom du cluster AKS existant Par exemple, utilisez myAKSCluster.
    --name Un nom de pool de nœuds unique Par exemple, utilisez nodepool2.
    --workload-runtime KataVmIsolation Active le bac à sable pod sur le pool de nœuds.
    --os-sku AzureLinux Le sandboxing de pod prend uniquement en charge la référence SKU du système d’exploitation Linux Azure.
    --node-vm-size Taille de machine virtuelle de génération 2 qui prend en charge la virtualisation imbriquée Par exemple, utilisez une taille de machine virtuelle de la série Dsv3.
    --node-count 1 Crée un nœud pour cet exemple. Ajustez la valeur de votre charge de travail.

    L’exemple suivant ajoute un pool de nœuds à myAKSCluster, avec un nœud dans nodepool2 du 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. Exécutez la commande az aks update pour réconcilier la configuration du cluster afin que celui-ci reconnaisse le nouveau pool de nœuds avec le runtime d’exécution des charges de travail KataVmIsolation.

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

  3. Vérifiez que la mise à jour du cluster s’est terminée correctement et que le pool de nœuds de bac à sable pod utilise le runtime de charge de travail attendu, la référence SKU du système d’exploitation et la taille de machine virtuelle.

    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

    L’état d’approvisionnement du cluster doit être Succeeded. La sortie du pool de nœuds doit afficher KataVmIsolation, AzureLinuxet la taille de machine virtuelle que vous avez sélectionnée.

Déployer des applications à l’aide du sandboxing de pod

En utilisant le bac à sable de pod, vous pouvez déployer un mélange de pods standard qui n’utilisent pas le runtime Kata avec des pods Kata qui utilisent le runtime. Un pod Kata spécifie runtimeClassName: kata-vm-isolation dans sa spécification de pod.

La classe d’exécution sélectionne l’environnement d’exécution Kata, mais vous devez également définir des contraintes de planification lorsque vous devez exécuter des charges de travail sur un pool de nœuds de sandboxing de pod spécifique. Par exemple, utilisez l’étiquette intégrée du pool de nœuds AKS dans un nodeSelector. Remplacez nodepool2 par le nom de votre pool de nœuds de bac à sable pod.

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

Pour une isolation plus forte, vous pouvez appliquer une teinte au pool de nœuds de sandboxing de pod et ajouter une tolération correspondante aux charges de travail Kata. Un taint sans tolération correspondante empêche les autres charges de travail d’être planifiées sur ce pool de nœuds. Pour plus d’informations, consultez Utiliser les taints de nœud dans un cluster AKS.

Déployer une application avec le runtime Kata

Pour déployer un pod avec le runtime Kata sur votre cluster AKS, procédez comme suit.

  1. Créez un fichier nommé kata-app.yaml pour décrire votre pod kata, puis collez le manifeste suivant.

    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"]

    La valeur de la spécification du pod pour runtimeClassName est kata-vm-isolation.

  2. Déployez le pod Kubernetes en exécutant la kubectl apply commande et en spécifiant votre fichier kata-app.yaml :

    kubectl apply -f kata-app.yaml

    La sortie de la commande ressemble à l’exemple suivant :

    pod/isolated-pod created

Vérifier l’isolation du noyau (facultatif)

  1. Pour comparer les noyaux des pods Kata et non Kata, créez un fichier nommé normal-app.yaml. Le manifeste suivant définit un pod standard sans le runtime 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. Déployez le pod standard à l’aide de la kubectl apply commande.

    kubectl apply -f normal-app.yaml

  2. Pour accéder à un conteneur à l’intérieur du cluster AKS, démarrez une session shell en exécutant la kubectl exec commande. Dans cet exemple, vous accédez au conteneur à l’intérieur d’un pod isolé.

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

    Kubectl se connecte à votre cluster, s’exécute /bin/sh à l’intérieur du premier conteneur et isolated-podtransfère les flux d’entrée et de sortie de votre terminal au processus du conteneur. Vous pouvez également démarrer une session shell sur le conteneur hébergeant le pod non Kata pour voir les différences.

  3. Après avoir ouvert une session shell dans le conteneur à partir de isolated-pod, exécutez des commandes pour vérifier que le conteneur kata s’exécute dans une sandbox de pod. Il utilise une version du noyau différente de celle du conteneur non-Kata situé hors de la sandbox.

    Pour consulter la version du noyau, exécutez la commande suivante :

    uname -r

    L'exemple suivant est similaire à la sortie du noyau pour le bac à sable de pod :

    [user]/# uname -r
6.6.96.mshv1

  4. Démarrez une session shell vers le conteneur à partir d’un pod normal pour vérifier la sortie du noyau :

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

    Pour consulter la version du noyau, exécutez la commande suivante :

    uname -r

    L’exemple suivant est semblable à la sortie de la machine virtuelle exécutant le pod normal, dont le noyau est différent du pod Kata s’exécutant dans le bac à sable de pod :

    6.6.100.mshv1-1.azl3

Nettoyer les ressources

  1. Une fois l’évaluation de cette fonctionnalité terminée, supprimez les ressources dont vous n’avez plus besoin afin d’éviter des frais Azure. Si vous avez déployé un nouveau cluster dans le cadre de votre évaluation ou test, exécutez la commande suivante az aks delete pour supprimer le cluster AKS.

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

  2. Si vous avez déployé le bac à sable pod sur un cluster existant, vous pouvez supprimer les pods à l’aide de la kubectl delete pod commande.

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

  3. Pour supprimer les ressources de calcul de sandboxing de pod, vous pouvez également supprimer le pool de nœuds Kata à l’aide de la commande az aks nodepool delete. Avant de supprimer le pool de nœuds, assurez-vous qu’aucune charge de travail que vous souhaitez conserver ne s’exécute sur celui-ci.

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

Étapes suivantes

  • En savoir plus sur les hôtes dédiés Azure pour les nœuds avec votre cluster AKS afin d’utiliser l’isolation matérielle et le contrôle des événements de maintenance de la plateforme Azure.
  • Pour explorer plus en détail l’isolation fournie par le sandboxing des pods et tester des scénarios de charge de travail, essayez les ateliers sur le sandboxing des pods.
  • Dernière mise à jour :