Sandboxing dei pod con Servizio Azure Kubernetes (AKS)

Il sandboxing dei pod in AKS usa Kata Containers per eseguire ogni pod sottoposto a sandboxing in una macchina virtuale (VM) leggera con un proprio kernel guest. Questo limite di calcolo isola il carico di lavoro dal kernel host e dai carichi di lavoro in altre macchine virtuali pod. Per informazioni su architettura, vantaggi e casi d'uso, vedere Panoramica del sandboxing dei pod in Servizio Azure Kubernetes (AKS).

In questo articolo distribuirai il sandboxing dei pod in un cluster AKS Azure Linux nuovo o esistente, distribuirai un'applicazione con il runtime Kata e, facoltativamente, verificherai l'isolamento del kernel.

Prerequisiti

  • CLI di Azure versione 2.80.0 o successiva. Eseguire az --version per trovare la versione dell'interfaccia della riga di comando di Azure ed eseguire az upgrade per eseguire l'aggiornamento. Per maggiori dettagli, consulta i passaggi in Installare l'interfaccia della riga di comando di Azure.
  • Il servizio Azure Kubernetes supporta la sandbox dei pod nella versione 1.27.0 e successive.
  • Per gestire un cluster Kubernetes, usare il client kubectldella riga di comando kubernetes. Azure Cloud Shell include kubectl. È possibile eseguire l'installazione kubectl in locale usando il az aks install-cli comando .

Limitazioni

I seguenti vincoli si applicano al sandboxing dei Pod:

  • I contenitori Kata potrebbero non raggiungere i limiti di prestazioni delle operazioni di I/O al secondo che i container tradizionali possono raggiungere in File di Azure e unità SSD locali con prestazioni elevate.
  • Microsoft Defender per contenitori non supporta la valutazione dei pod di runtime Kata.
  • L'accesso alla rete host Kata non è supportato. Non è possibile accedere direttamente alla configurazione di rete host dall'interno della macchina virtuale.
  • L'allocazione della CPU e della memoria con il sandbox del pod è diversa da runc. Ogni pod Kata viene eseguito in una macchina virtuale pod la cui dimensione di memoria fissa è basata sul limite di memoria del pod o il valore predefinito è 512Mi se non si specifica un limite. I limiti della CPU determinano l'allocazione vCPU della macchina virtuale pod e i limiti frazionari vengono arrotondati a un'intera vCPU per tale allocazione. Per ulteriori informazioni, consulta Considerazioni sulla sandbox dei pod.
  • Il sandboxing dei pod è supportato solo in Azure Linux. Ubuntu e Windows non sono supportati. Per altre informazioni, vedi host di contenitori Linux di Azure per AKS.
  • Non è possibile abilitare Federal Information Processing Standard (FIPS) o Avvio attendibile su un pool di nodi che utilizza il sandboxing dei pod. Per ulteriori informazioni, consulta Considerazioni sulla sandbox dei pod.
  • L'architettura Arm64 non è supportata su un pool di nodi che utilizza il sandboxing dei pod.

Funzionamento

Il sandboxing dei pod in AKS si basa sul progetto open source Kata Containers. Kata Containers in esecuzione nell'host per contenitori Linux in Azure per il servizio Azure Kubernetes offre isolamento basato su macchina virtuale e un kernel separato per ogni pod. L'isolamento dei pod consente di allocare risorse a ciascun pod senza condividerle con altri Kata Containers o con contenitori del namespace in esecuzione sullo stesso host.

L'architettura della soluzione si basa sui componenti principali seguenti:

La distribuzione in modalità sandbox dei pod usando Kata Containers è simile al flusso di lavoro standard containerd per distribuire i container. I cluster con sandboxing pod abilitati sono dotati di una classe di runtime specifica a cui è possibile fare riferimento in un manifesto del pod (runtimeClassName: kata-vm-isolation). Per altre informazioni sulle impostazioni predefinite e sulla personalizzazione della classe di runtime, vedere Considerazioni per il sandboxing dei pod.

Per usare questa funzionalità con un pod, l'unica differenza consiste nell'aggiungere runtimeClassNamekata-vm-isolation alla specifica del pod. Quando un pod usa runtimeClasskata-vm-isolation, l'hypervisor avvia una macchina virtuale leggera con il proprio kernel, in modo che il carico di lavoro funzioni.

Creare un cluster con sandbox del pod

Seguire questa procedura per distribuire un cluster del servizio Azure Kubernetes Linux usando l'interfaccia della riga di comando di Azure.

  1. Crea un cluster AKS eseguendo il comando az aks create con i parametri seguenti:

    Parametro Valore obbligatorio Note
    --workload-runtime KataVmIsolation Abilita la sandbox dei pod nel pool di nodi.
    --os-sku AzureLinux Il sandboxing dei pod supporta solo lo SKU del sistema operativo Azure Linux.
    --node-vm-size Dimensioni di vm di seconda generazione che supportano la virtualizzazione annidata Ad esempio, usare una dimensione di macchina virtuale serie Dsv3 .
    --node-count 3 Crea tre nodi per questo esempio. Regola il valore del carico di lavoro.

    L'esempio seguente crea un cluster denominato myAKSCluster con tre nodi in 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. Eseguire il comando seguente per ottenere le credenziali di accesso per il cluster Kubernetes. Usare il az aks get-credentials comando e sostituire i valori per il nome del cluster e il nome del gruppo di risorse.

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

  3. Elenca tutti i Pods in tutti i namespace eseguendo il comando kubectl get pods.

    kubectl get pods --all-namespaces

Abilitare il sandboxing dei pod in un cluster esistente

Per usare questa funzionalità con un cluster del servizio Azure Kubernetes esistente, è necessario soddisfare i requisiti seguenti:

  • Il cluster esegue Kubernetes versione 1.27.0 o successiva.

  • Usare il comando seguente per abilitare la sandbox dei pod creando un pool di nodi per ospitarlo.

  1. Aggiungere un pool di nodi al cluster del servizio Azure Kubernetes usando il az aks nodepool add comando con i parametri seguenti:

    Parametro Valore obbligatorio Note
    --resource-group Il gruppo di risorse che contiene il cluster AKS esistente Ad esempio, usare myResourceGroup.
    --cluster-name Nome del cluster AKS esistente Ad esempio, usare myAKSCluster.
    --name Nome univoco del pool di nodi Ad esempio, usare nodepool2.
    --workload-runtime KataVmIsolation Abilita la sandbox dei pod nel pool di nodi.
    --os-sku AzureLinux Il sandboxing dei pod supporta solo lo SKU del sistema operativo Azure Linux.
    --node-vm-size Dimensioni di vm di seconda generazione che supportano la virtualizzazione annidata Ad esempio, usare una dimensione di macchina virtuale serie Dsv3 .
    --node-count 1 Crea un nodo per questo esempio. Regola il valore del carico di lavoro.

    L'esempio seguente aggiunge un pool di nodi a myAKSCluster con un nodo in nodepool2 in 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. Eseguire il az aks update comando per riconciliare la configurazione del cluster in modo che il cluster riconosca il nuovo pool di nodi con il runtime del KataVmIsolation carico di lavoro.

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

  3. Verifica che l'aggiornamento del cluster sia stato completato correttamente e che il pool di nodi per il sandboxing dei pod usi il runtime del carico di lavoro, la SKU del sistema operativo e le dimensioni della VM previste.

    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

    Lo stato del provisioning del cluster deve essere Succeeded. L'output del pool di nodi dovrebbe mostrare KataVmIsolation, AzureLinuxe le dimensioni della macchina virtuale selezionate.

Distribuire applicazioni usando il sandbox del pod

Usando la sandbox dei pod, è possibile distribuire una combinazione di pod standard che non usano il runtime Kata insieme ai pod Kata che usano il runtime. Un pod Kata specifica runtimeClassName: kata-vm-isolation nella specifica del pod.

La RuntimeClass seleziona il runtime Kata, ma è anche necessario definire vincoli di pianificazione quando è necessario eseguire i carichi di lavoro su uno specifico pool di nodi per il sandboxing dei Pod. Ad esempio, usare l'etichetta integrata del pool di nodi del servizio Azure Kubernetes in un nodeSelector. Sostituisci nodepool2 con il nome del pool di nodi per il sandboxing dei Pod.

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

Per una separazione più netta, puoi applicare un taint al pool di nodi per il sandboxing dei Pod e aggiungere una toleration corrispondente ai carichi di lavoro Kata. Un taint senza una tollerazione corrispondente impedisce ad altri carichi di lavoro di pianificare in tale pool di nodi. Per altre informazioni, vedi Usare i taint dei nodi in un cluster AKS.

Distribuire un'applicazione con il runtime Kata

Per distribuire un pod con il runtime Kata nel cluster AKS, seguire i passaggi seguenti.

  1. Creare un file denominato kata-app.yaml per descrivere il pod kata e quindi incollare il manifesto seguente.

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

    Il valore della specifica del pod per runtimeClassName è kata-vm-isolation.

  2. Distribuire il pod Kubernetes eseguendo il kubectl apply comando e specificando il file kata-app.yaml :

    kubectl apply -f kata-app.yaml

    L'output del comando è simile all'esempio seguente:

    pod/isolated-pod created

Verificare l'isolamento del kernel (facoltativo)

  1. Per confrontare i kernel dei pod Kata e non Kata, creare un file denominato normal-app.yaml. Il manifesto seguente definisce un pod standard senza il 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. Distribuisci il pod standard utilizzando il comando kubectl apply.

    kubectl apply -f normal-app.yaml

  2. Per accedere a un contenitore all'interno del cluster AKS, avviare una sessione shell eseguendo il comando kubectl exec. In questo esempio si accede al contenitore all'interno di un pod isolato.

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

    Kubectl si connette al cluster, esegue /bin/sh all'interno del primo container di isolated-pod e inoltra i flussi di input e output del terminale al processo del container. È anche possibile avviare una sessione della shell nel contenitore che ospita il pod non Kata per visualizzare le differenze.

  3. Dopo aver avviato una sessione shell nel container da isolated-pod, eseguire i comandi per verificare che il container kata sia in esecuzione all'interno di una sandbox del pod. Ha una versione del kernel diversa rispetto al container non Kata al di fuori della sandbox.

    Per visualizzare la versione del kernel, eseguire il comando seguente:

    uname -r

    L'esempio seguente è simile all'output del kernel sandbox del pod:

    [user]/# uname -r
6.6.96.mshv1

  4. Avvia una sessione shell per il contenitore da normal-pod per verificare l'output del kernel.

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

    Per visualizzare la versione del kernel, eseguire il comando seguente:

    uname -r

    L'esempio seguente è simile all'output della macchina virtuale che esegue il pod normale, che è un kernel diverso rispetto al pod Kata in esecuzione all'interno della sandbox del pod:

    6.6.100.mshv1-1.azl3

Pulire le risorse

  1. Al termine della valutazione di questa funzionalità, elimina le risorse che non ti servono più per evitare addebiti di Azure. Se hai distribuito un nuovo cluster nell'ambito della valutazione o dei test, esegui il comando seguente az aks delete per eliminare il cluster AKS.

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

  2. Se hai distribuito il sandboxing dei pod su un cluster esistente, puoi rimuovere i pod usando il comando kubectl delete pod.

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

  3. Per rimuovere le risorse di calcolo della sandbox dei pod, è anche possibile eliminare il pool di nodi Kata usando il az aks nodepool delete comando . Prima di eliminare il pool di nodi, assicurarsi che non siano in esecuzione carichi di lavoro da conservare.

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

Passaggi successivi

  • Altre informazioni sugli host dedicati di Azure per i nodi con il cluster del servizio Azure Kubernetes per usare l'isolamento hardware e il controllo sugli eventi di manutenzione della piattaforma Azure.
  • Per esplorare ulteriormente l'isolamento della sandbox dei pod ed esplorare gli scenari di carico di lavoro, provare i lab di sandboxing dei pod.
  • Ultimo aggiornamento: