Pod-Sandboxing mit Azure Kubernetes Service (AKS)

Pod Sandboxing auf AKS verwendet Kata-Container, um jeden Sandkasten-Pod in einem einfachen virtuellen Computer (VM) mit seinem eigenen Gastkernkern auszuführen. Diese Berechnungsgrenze isoliert die Workload vom Hostkernel und Workloads in anderen Pod-VMs. Informationen zu Architektur, Vorteilen und Anwendungsfällen finden Sie in der Übersicht über die Pod-Sandboxing in Azure Kubernetes Service (AKS).

In diesem Artikel aktivieren Sie Pod-Sandboxing in einem neuen oder vorhandenen Azure Linux AKS-Cluster, stellen eine Anwendung mit der Kata-Runtime bereit und überprüfen optional die Kernel-Isolation.

Voraussetzungen

  • Die Azure CLI-Version 2.80.0 oder höher. Führen Sie az --version aus, um die Version Ihrer Azure CLI festzustellen, und az upgrade um ein Upgrade durchzuführen. Weitere Details finden Sie in den Schritten unter Installieren der Azure CLI.
  • AKS unterstützt pod sandboxing auf Kubernetes, Version 1.27.0 und höher.
  • Verwenden Sie den Kubernetes-Befehlszeilenclient kubectl, um einen Kubernetes-Cluster zu verwalten. kubectl ist in Azure Cloud Shell enthalten. Sie können kubectl lokal installieren, indem Sie den Befehl az aks install-cli verwenden.

Einschränkungen

Die folgenden Einschränkungen gelten für pod-Sandboxing:

  • Kata-Container erreichen möglicherweise nicht die IOPS-Leistungsbeschränkungen, die herkömmliche Container auf Azure Files und leistungsstarker lokaler SSD erreichen können.
  • Microsoft Defender for Containers unterstützt die Bewertung von Kata-Runtime-Pods nicht.
  • Der Zugriff auf das Host-Netzwerk von Kata wird nicht unterstützt. Sie können nicht direkt auf die Hostnetzwerkkonfiguration innerhalb der VM zugreifen.
  • Die CPU- und Speicherzuweisung mit Pod-Sandboxing unterscheidet sich von runc. Jeder Kata-Pod wird in einer Pod-VM ausgeführt, deren feste Speichergröße auf dem Speicherlimit des Pods basiert oder standardmäßig 512Mi beträgt, wenn Sie kein Limit angeben. CPU-Limits legen die vCPU-Zuweisung der Pod-VM fest, und Bruchteile eines vCPU-Limits werden bei dieser Zuweisung auf eine ganze vCPU aufgerundet. Weitere Informationen finden Sie unter Aspekte des Pod-Sandboxings.
  • Pod-Sandboxing wird nur unter Azure Linux unterstützt. Ubuntu und Windows werden nicht unterstützt. Weitere Informationen finden Sie unter Azure Linux-Containerhost für AKS.
  • Sie können den Federal Information Processing Standard (FIPS) oder den vertrauenswürdigen Start nicht für einen Knotenpool aktivieren, der Pod-Sandboxing verwendet. Weitere Informationen finden Sie unter Aspekte des Pod-Sandboxings.
  • Die Arm64-Architektur wird für einen Knotenpool, der pod-Sandboxing verwendet, nicht unterstützt.

Funktionsweise

Pod-Sandboxing auf AKS basiert auf dem Open-Source-Projekt Kata Containers. Kata-Container, die auf dem Azure Linux-Containerhost für AKS ausgeführt werden, bieten VM-basierte Isolation und einen separaten Kernel für jeden Pod. Pod-Sandboxing ermöglicht die Zuweisung von Ressourcen für jeden Pod, ohne diese Ressourcen mit anderen Kata-Containern oder Containern in Namespaces zu teilen, die auf demselben Host ausgeführt werden.

Die Lösungsarchitektur basiert auf den folgenden Hauptkomponenten:

Das Bereitstellen von Pod-Sandboxing mithilfe von Kata-Containern ähnelt dem Standardworkflow containerd zum Bereitstellen von Containern. Cluster mit aktivierter Pod-Sandboxing verfügen über eine bestimmte Laufzeitklasse, auf die Sie in einem Pod-Manifest (runtimeClassName: kata-vm-isolation) verweisen können. Weitere Informationen zu Standardeinstellungen und Anpassungen der Laufzeitklasse finden Sie unter Überlegungen zur Pod-Sandboxing.

Um dieses Feature mit einem Pod zu verwenden, besteht der einzige Unterschied darin, der Pod-Spezifikation den runtimeClassNamekata-vm-isolation hinzuzufügen. Wenn ein Pod die runtimeClass kata-vm-isolation verwendet, startet der Hypervisor eine leichtgewichtige VM mit eigenem Kernel, damit die Workload darin ausgeführt werden kann.

Erstellen eines Clusters mit Pod-Sandkasten

Führen Sie die folgenden Schritte aus, um einen Azure Linux AKS-Cluster mithilfe der Azure CLI bereitzustellen.

  1. Erstellen Sie einen AKS-Cluster, indem Sie den az aks create Befehl mit den folgenden Parametern ausführen:

    Parameter Erforderlicher Wert Notes
    --workload-runtime KataVmIsolation Aktiviert die Pod-Sandboxing im Knotenpool.
    --os-sku AzureLinux Pod-Sandboxing unterstützt nur die Azure Linux-Betriebssystem-SKU.
    --node-vm-size Eine VM-Größe der Generation 2, die geschachtelte Virtualisierung unterstützt Verwenden Sie beispielsweise eine VM-Größe der Dsv3-Serie .
    --node-count 3 Erstellt drei Knoten für dieses Beispiel. Passen Sie den Wert Ihrer Workload an.

    Im folgenden Beispiel wird ein Cluster namens myAKSCluster mit drei Knoten in myResourceGroup erstellt:

    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. Führen Sie den folgenden Befehl aus, um Anmeldeinformationen für den Zugriff auf den Kubernetes-Cluster zu erhalten. Verwenden Sie den az aks get-credentials Befehl, und ersetzen Sie die Werte für den Clusternamen und den Ressourcengruppennamen.

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

  3. Alle Pods in allen Namespaces auflisten, indem Sie den kubectl get pods Befehl ausführen.

    kubectl get pods --all-namespaces

Pod-Sandboxing in einem vorhandenen Cluster aktivieren

Um dieses Feature mit einem vorhandenen AKS-Cluster verwenden zu können, müssen die folgenden Anforderungen erfüllt sein:

  • Der Cluster führt Kubernetes, Version 1.27.0 oder höher, aus.

  • Verwenden Sie den folgenden Befehl, um pod sandboxing zu aktivieren, indem Sie einen Knotenpool zum Hosten erstellen.

  1. Fügen Sie ihrem AKS-Cluster einen Knotenpool hinzu, indem Sie den az aks nodepool add Befehl mit den folgenden Parametern verwenden:

    Parameter Erforderlicher Wert Notes
    --resource-group Die Ressourcengruppe, die den vorhandenen AKS-Cluster enthält Verwenden Sie z. B. myResourceGroup.
    --cluster-name Der Name des vorhandenen AKS-Clusters Verwenden Sie z. B. myAKSCluster.
    --name Ein eindeutiger Knotenpoolname Verwenden Sie z. B. nodepool2.
    --workload-runtime KataVmIsolation Aktiviert die Pod-Sandboxing im Knotenpool.
    --os-sku AzureLinux Pod-Sandboxing unterstützt nur die Azure Linux-Betriebssystem-SKU.
    --node-vm-size Eine VM-Größe der Generation 2, die geschachtelte Virtualisierung unterstützt Verwenden Sie beispielsweise eine VM-Größe der Dsv3-Serie .
    --node-count 1 Erstellt einen Knoten für dieses Beispiel. Passen Sie den Wert Ihrer Workload an.

    Im folgenden Beispiel wird dem Cluster myAKSCluster ein Knotenpool mit einem Knoten in nodepool2 in der Ressourcengruppe myResourceGroup hinzugefügt:

    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. Führen Sie den az aks update Befehl aus, um die Clusterkonfiguration abzugleichen, damit der Cluster den neuen Knotenpool mit der KataVmIsolation Workload-Laufzeit erkennt.

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

  3. Stellen Sie sicher, dass das Clusterupdate erfolgreich abgeschlossen wurde und dass der Pod-Sandkastenknotenpool die erwartete Workload-Laufzeit, Betriebssystem-SKU und VM-Größe verwendet.

    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

    Der Clusterbereitstellungsstatus sollte sein Succeeded. Die Ausgabe des Knotenpools sollte KataVmIsolation, AzureLinux und die ausgewählte VM-Größe anzeigen.

Bereitstellen von Anwendungen mit Pod-Sandboxing

Mithilfe von Pod-Sandboxing können Sie eine Mischung aus Standard-Pods bereitstellen, die die Kata-Runtime nicht verwenden, und Kata-Pods, die die Runtime verwenden. Ein Kata-Pod gibt in seiner Podspezifikation an runtimeClassName: kata-vm-isolation .

Die Laufzeitklasse wählt die Kata-Laufzeit aus, Sie sollten jedoch auch Planungseinschränkungen definieren, wenn Workloads in einem bestimmten Pod-Sandboxknotenpool ausgeführt werden müssen. Verwenden Sie beispielsweise das integrierte AKS-Knotenpool-Label in nodeSelector. Ersetzen Sie nodepool2 durch den Namen Ihres Knotenpools für Pod-Sandboxing.

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

Für eine stärkere Trennung können Sie den Node-Pool für Pod-Sandboxing mit einem Taint versehen und eine passende Toleration zu Kata-Workloads hinzufügen. Ein Taint ohne passende Toleration verhindert, dass andere Workloads auf diesem Knotenpool geplant werden. Weitere Informationen finden Sie unter Verwenden von Knotentaints in einem AKS-Cluster.

Bereitstellen einer Anwendung mit der Kata-Laufzeit

Führen Sie die folgenden Schritte aus, um einen Pod mit der Kata-Runtime auf Ihrem AKS-Cluster bereitzustellen.

  1. Erstellen Sie eine Datei namens kata-app.yaml , um Ihren Kata-Pod zu beschreiben, und fügen Sie dann das folgende Manifest ein.

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

    Der Pod-Spezifikationswert für runtimeClassName ist kata-vm-isolation.

  2. Stellen Sie den Kubernetes-Pod bereit, indem Sie den kubectl apply Befehl ausführen und die Datei kata-app.yaml angeben:

    kubectl apply -f kata-app.yaml

    Die Ausgabe des Befehls sieht in etwa wie im folgenden Beispiel aus:

    pod/isolated-pod created

Überprüfen der Kernelisolation (optional)

  1. Um die Kernel von Kata- und Nicht-Kata-Pods zu vergleichen, erstellen Sie eine Datei mit dem Namen "normal-app.yaml". Das folgende Manifest definiert einen Standard-Pod ohne die Kata-Laufzeit:
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. Stellen Sie den Standard-Pod mithilfe des kubectl apply Befehls bereit.

    kubectl apply -f normal-app.yaml

  2. Um auf einen Container innerhalb des AKS-Clusters zuzugreifen, starten Sie eine Shellsitzung, indem Sie den kubectl exec Befehl ausführen. In diesem Beispiel greifen Sie auf den Container innerhalb von isolated-pod zu.

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

    Kubectl stellt eine Verbindung zu Ihrem Cluster her, führt /bin/sh im ersten Container innerhalb von isolated-pod aus und leitet die Eingabe- und Ausgabeströme Ihres Terminals an den Prozess des Containers weiter. Sie können auch eine Shell-Sitzung auf dem Container starten, der den Nicht-Kata-Pod hostet, um die Unterschiede zu erkennen.

  3. Führen Sie nach dem Starten einer Shell-Sitzung zum Container aus isolated-pod Befehle aus, um zu überprüfen, ob der Container kata in einer Pod-Sandbox ausgeführt wird. Es verfügt über eine andere Kernelversion als der Nicht-Kata-Container außerhalb der Sandbox.

    Die Kernelversion wird mit dem folgenden Befehl abgerufen:

    uname -r

    Das folgende Beispiel ähnelt der Ausgabe des Podsandbox-Kernels:

    [user]/# uname -r
6.6.96.mshv1

  4. Starten Sie eine Shellsitzung mit dem Container von normal-pod , um die Kernelausgabe zu überprüfen:

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

    Die Kernelversion wird mit dem folgenden Befehl abgerufen:

    uname -r

    Das folgende Beispiel ähnelt der Ausgabe des virtuellen Computers, der einen normalen Pod ausführt. Dies ist ein anderer Kernel als der Kata-Pod, der innerhalb der Pod-Sandbox ausgeführt wird:

    6.6.100.mshv1-1.azl3

Bereinigen von Ressourcen

  1. Wenn Sie mit der Auswertung dieses Features fertig sind, bereinigen Sie Ressourcen, die Sie nicht mehr benötigen, um Azure Gebühren zu vermeiden. Wenn Sie einen neuen Cluster als Teil Ihrer Auswertung oder Tests bereitgestellt haben, führen Sie den folgenden az aks delete Befehl aus, um den AKS-Cluster zu löschen.

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

  2. Wenn Sie pod sandboxing auf einem vorhandenen Cluster bereitgestellt haben, können Sie die Pods mithilfe des kubectl delete pod Befehls entfernen.

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

  3. Um die Pod-Sandkasten-Computeressourcen zu entfernen, können Sie den Kata-Knotenpool auch mithilfe des az aks nodepool delete Befehls löschen. Stellen Sie vor dem Löschen des Knotenpools sicher, dass darauf keine Workloads ausgeführt werden, die Sie beibehalten möchten.

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

Nächste Schritte

  • Erfahren Sie mehr über Azure Dedicated Hosts für Knoten mit Ihrem AKS-Cluster, um Hardwareisolation und Kontrolle über Wartungsereignisse der Azure-Plattform zu verwenden.
  • Um die Pod-Sandkastenisolation weiter zu erkunden und Workloadszenarien zu erkunden, probieren Sie die Pod-Sandkastenlabore aus.
  • Zuletzt aktualisiert um