Pod-sandboxing met Azure Kubernetes Service (AKS)

Pod-sandboxing op AKS maakt gebruik van Kata Containers om elke sandbox-pod uit te voeren op een lichtgewicht virtuele machine (VM) met een eigen gastkernel. Deze rekengrens isoleert de workload van de hostkernel en workloads in andere pod-VM's. Zie Overzicht van Pod-sandboxing in Azure Kubernetes Service (AKS) voor meer informatie over de architectuur, voordelen en use cases.

In dit artikel implementeert u Pod-sandboxing op een nieuw of bestaand Azure Linux AKS-cluster, implementeert u een toepassing met de Kata-runtime en controleert u eventueel kernelisolatie.

Vereisten

De Azure CLI versie 2.80.0 of hoger. Voer az --version uit om de versie van uw Azure CLI te vinden en az upgrade om te upgraden. Zie de stappen bij Azure CLI installeren voor meer informatie.
AKS ondersteunt Pod-sandboxing op Kubernetes versie 1.27.0 en hoger.
Als u een Kubernetes-cluster wilt beheren, gebruikt u de Kubernetes-opdrachtregelclient kubectl. Azure Cloud Shell wordt geleverd met kubectl. U kunt lokaal installeren kubectl met behulp van de az aks install-cli opdracht.

Beperkingen

De volgende beperkingen zijn van toepassing op pod-sandboxing:

Kata-containers bereiken mogelijk niet de IOPS-prestatielimieten die traditionele containers kunnen bereiken op Azure Files en lokale SSD met hoge prestaties.
Microsoft Defender for Containers ondersteunt het beoordelen van Kata-runtime-pods niet.
Kata-hostnetwerktoegang wordt niet ondersteund. U hebt geen rechtstreeks toegang tot de hostnetwerkconfiguratie vanuit de VIRTUELE machine.
CPU- en geheugentoewijzing met Pod-sandboxing verschilt van runc. Elke Kata-pod wordt uitgevoerd op een pod-VM waarvan de vaste geheugengrootte is gebaseerd op de geheugenlimiet van de pod, of standaard 512Mi als u geen limiet opgeeft. CPU-limieten bepalen de vCPU-toewijzing van de pod-VM en fractionele limieten worden voor die toewijzing naar een volledige vCPU afgerond. Zie Overwegingen voor pod-sandboxing voor meer informatie.
Pod-sandboxing wordt alleen ondersteund in Azure Linux. Ubuntu en Windows worden niet ondersteund. Zie Azure Linux-containerhost voor AKS voor meer informatie.
U kunt Federal Information Processing Standard (FIPS) of Trusted Launch niet inschakelen voor een knooppuntgroep die gebruikmaakt van Pod-sandboxing. Zie Overwegingen voor pod-sandboxing voor meer informatie.
Arm64-architectuur wordt niet ondersteund in een knooppuntgroep die gebruikmaakt van Pod-sandboxing.

Hoe het werkt

Pod-sandboxing in AKS is gebaseerd op het open-sourceproject Kata Containers. Kata-containers die worden uitgevoerd op de Azure Linux-containerhost voor AKS biedt isolatie op basis van VM's en een afzonderlijke kernel voor elke pod. Met pod-sandboxing kunt u resources toewijzen voor elke pod en deze niet delen met andere Kata-containers of naamruimtecontainers die op dezelfde host worden uitgevoerd.

De oplossingsarchitectuur is gebaseerd op de volgende hoofdonderdelen:

De Azure Linux-containerhost voor AKS
Microsoft Hyper-V Hypervisor
Opensource Cloud-Hypervisor Virtual Machine Monitor (VMM)
Integratie met Kata Containers voor de runtime

Het implementeren van Pod-sandboxing met behulp van Kata Containers is vergelijkbaar met de standaardwerkstroom containerd voor het implementeren van containers. Clusters waarvoor Pod-sandboxing is ingeschakeld, worden geleverd met een specifieke runtimeklasse waarnaar u kunt verwijzen in een podmanifest (runtimeClassName: kata-vm-isolation). Zie Overwegingen voor pod-sandboxing voor meer informatie over de standaardinstellingen en aanpassingen van runtimeklassen.

Als u deze functie met een pod wilt gebruiken, is het enige verschil om de runtimeClassNamekata-vm-isolation toe te voegen aan de podspecificatie. Wanneer een pod gebruikmaakt van runtimeClasskata-vm-isolation, draait de hypervisor een lichtgewicht virtuele machine met een eigen kernel om de werkbelasting te laten werken.

Een cluster maken met pod-sandboxing

Voer de volgende stappen uit om een Azure Linux AKS-cluster te implementeren met behulp van de Azure CLI.

Maak een AKS-cluster door de az aks create opdracht uit te voeren met de volgende parameters:

Parameter	Vereiste waarde	Aantekeningen
`--workload-runtime`	`KataVmIsolation`	Schakelt Pod-sandboxing in op de knooppuntpool.
`--os-sku`	`AzureLinux`	Pod-sandboxing ondersteunt alleen de Azure Linux OS-SKU.
`--node-vm-size`	Een VM-grootte van de tweede generatie die ondersteuning biedt voor geneste virtualisatie	Gebruik bijvoorbeeld een VM-grootte uit de Dsv3-serie .
`--node-count`	`3`	Hiermee maakt u drie knooppunten voor dit voorbeeld. Pas de waarde voor uw workload aan.

In het volgende voorbeeld wordt een cluster met de naam myAKSCluster gemaakt met drie knooppunten 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

Voer de volgende opdracht uit om toegangsreferenties op te halen voor het Kubernetes-cluster. Gebruik de az aks get-credentials opdracht en vervang de waarden voor de clusternaam en de naam van de resourcegroep.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```
Geef alle pods in alle naamruimten weer door de opdracht uit te kubectl get pods voeren.
```
kubectl get pods --all-namespaces
```

Pod-sandboxing inschakelen op een bestaand cluster

Als u deze functie wilt gebruiken met een bestaand AKS-cluster, moet aan de volgende vereisten worden voldaan:

In het cluster wordt Kubernetes versie 1.27.0 of hoger uitgevoerd.
Gebruik de volgende opdracht om Pod-sandboxing in te schakelen door een knooppuntgroep te maken om deze te hosten.

Voeg een knooppuntgroep toe aan uw AKS-cluster met behulp van de az aks nodepool add opdracht met de volgende parameters:

Parameter	Vereiste waarde	Aantekeningen
`--resource-group`	De resourcegroep die het bestaande AKS-cluster bevat	Gebruik bijvoorbeeld `myResourceGroup`.
`--cluster-name`	De naam van het bestaande AKS-cluster	Gebruik bijvoorbeeld `myAKSCluster`.
`--name`	Een unieke naam van een knooppuntgroep	Gebruik bijvoorbeeld `nodepool2`.
`--workload-runtime`	`KataVmIsolation`	Schakelt Pod-sandboxing in op de knooppuntpool.
`--os-sku`	`AzureLinux`	Pod-sandboxing ondersteunt alleen de Azure Linux OS-SKU.
`--node-vm-size`	Een VM-grootte van de tweede generatie die ondersteuning biedt voor geneste virtualisatie	Gebruik bijvoorbeeld een VM-grootte uit de Dsv3-serie .
`--node-count`	`1`	Hiermee maakt u één knooppunt voor dit voorbeeld. Pas de waarde voor uw workload aan.

In het volgende voorbeeld wordt een knooppuntgroep toegevoegd aan myAKSCluster met één knooppunt 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

Voer de az aks update opdracht uit om de clusterconfiguratie af te stemmen, zodat het cluster de nieuwe knooppuntgroep herkent met de KataVmIsolation workloadruntime.
```
az aks update --name myAKSCluster --resource-group myResourceGroup
```

Controleer of de clusterupdate is voltooid en of de pod-sandbox-knooppuntgroep gebruikmaakt van de verwachte workloadruntime, de SKU van het besturingssysteem en de VM-grootte.

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

De inrichtingsstatus van het cluster moet zijn Succeeded. De uitvoer van de knooppuntpool moet AzureLinux, KataVmIsolation en de VM-grootte weergeven die u hebt geselecteerd.

Toepassingen implementeren met pod-sandboxing

Met pod-sandboxing kunt u een combinatie van standaardpods implementeren die niet gebruikmaken van de Kata-runtime naast Kata-pods die gebruikmaken van de runtime. Een Kata-pod specificeert runtimeClassName: kata-vm-isolation in zijn podspecificatie.

De runtimeklasse selecteert de Kata-runtime, maar u moet ook planningsrestricties definiëren wanneer u wilt dat workloads worden uitgevoerd op een specifieke knooppuntgroep voor Pod-sandboxing. Gebruik bijvoorbeeld het ingebouwde AKS-knooppuntgroeplabel in een nodeSelector. Vervang nodepool2 door de naam van uw nodepool voor Pod sandboxing.

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

Voor betere isolatie kunt u de knooppuntgroep voor Pod-sandboxing van een taint voorzien en een bijbehorende toleration toevoegen aan Kata-workloads. Een taint zonder overeenkomende tolerantie voorkomt dat andere workloads op die knooppuntgroep worden ingepland. Zie Taints voor knooppunten gebruiken in een AKS-cluster voor meer informatie.

Een toepassing implementeren met de Kata-runtime

Voer de volgende stappen uit om een pod te implementeren met de Kata-runtime op uw AKS-cluster.

Maak een bestand met de naam kata-app.yaml om uw kata-pod te beschrijven en plak het volgende manifest.

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

De waarde voor de podspecificatie runtimeClassName is kata-vm-isolation.

Implementeer de Kubernetes-pod door de kubectl apply opdracht uit te voeren en uw kata-app.yaml-bestand op te geven:
```
kubectl apply -f kata-app.yaml
```
De uitvoer van de opdracht lijkt op het volgende voorbeeld:
```
pod/isolated-pod created
```

Kernelisolatie controleren (optioneel)

Als u de kernels van Kata- en niet-Kata-pods wilt vergelijken, maakt u een bestand met de naam normal-app.yaml. Het volgende manifest definieert een standaardpod zonder de Kata-runtime:

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

Implementeer de standaardpod met behulp van de kubectl apply opdracht.
```
kubectl apply -f normal-app.yaml
```
Als u toegang wilt krijgen tot een container in het AKS-cluster, start u een shellsessie door de opdracht uit te kubectl exec voeren. In dit voorbeeld benadert u de container binnen isolated-pod.
```
kubectl exec -it isolated-pod -- /bin/sh
```
Kubectl maakt verbinding met uw cluster, voert /bin/sh uit in de eerste container binnen isolated-pod, en stuurt de invoer- en uitvoerstromen van uw terminal door naar het proces van de container. U kunt ook een shellsessie starten naar de container die als host fungeert voor de niet-Kata-pod om de verschillen te zien.
Nadat u een shellsessie naar de container hebt gestart vanuit een geïsoleerde pod, voert u opdrachten uit om te controleren of de kata-container wordt uitgevoerd in een pod-sandbox. Het gebruikt een andere kernelversie dan de non-Kata-container buiten de sandbox.

Voer de volgende opdracht uit om de kernelversie te zien:
```
uname -r
```
Het volgende voorbeeld is vergelijkbaar met uitvoer van de kernel van de podsandbox:
```
[user]/# uname -r
6.6.96.mshv1
```
Start een shellsessie naar de container vanaf de normale pod om de kerneluitvoer te controleren:
```
kubectl exec -it normal-pod -- /bin/bash
```
Voer de volgende opdracht uit om de kernelversie te zien:
```
uname -r
```
Het volgende voorbeeld lijkt op uitvoer van de VIRTUELE machine waarop normal-pod wordt uitgevoerd. Dit is een andere kernel dan de Kata-pod die wordt uitgevoerd in de pod-sandbox:
```
6.6.100.mshv1-1.azl3
```

De hulpbronnen opschonen

Wanneer u klaar bent met het evalueren van deze functie, moet u resources opschonen die u niet meer nodig hebt om Azure kosten te voorkomen. Als u een nieuw cluster hebt geïmplementeerd als onderdeel van uw evaluatie of test, voert u de volgende az aks delete opdracht uit om het AKS-cluster te verwijderen.
```
az aks delete --resource-group myResourceGroup --name myAKSCluster
```
Als u Pod-sandboxing hebt geïmplementeerd op een bestaand cluster, kunt u de pods verwijderen met behulp van de kubectl delete pod opdracht.
```
kubectl get pods
kubectl delete pod <kata-pod-name>
```
Als u de sandbox-computeresources van de pod wilt verwijderen, kunt u ook de Kata-knooppuntenpool verwijderen met de opdracht az aks nodepool delete. Voordat u de knooppuntgroep verwijdert, moet u ervoor zorgen dat er geen workloads worden uitgevoerd die u wilt behouden.
```
az aks nodepool delete \
  --cluster-name myAKSCluster \
  --resource-group myResourceGroup \
  --name nodepool2
```

Volgende stappen

Meer informatie over Azure Dedicated-hosts voor knooppunten met uw AKS-cluster voor het gebruik van hardware-isolatie en controle over onderhoudsgebeurtenissen van het Azure-platform.
Als u de isolatie van pod-sandboxing verder wilt onderzoeken en workloadscenario’s wilt verkennen, probeer dan eens de Pod-sandboxing-labs uit.

Feedback

Is deze pagina nuttig?

Laatst bijgewerkt om 2026-10-02