Isolamento de pods com o Azure Kubernetes Service (AKS)

O sandboxing pod no AKS usa Kata Containers para executar cada pod sandboxado numa máquina virtual leve (VM) com o seu próprio kernel convidado. Esta fronteira de computação isola a carga de trabalho do kernel anfitrião e das cargas de trabalho noutras VMs pod. Para saber mais sobre a arquitetura, benefícios e casos de uso, consulte Visão Geral do Sandboxing Pod no Azure Kubernetes Service (AKS).

Neste artigo, implementa o sandboxing Pod num cluster Azure Linux AKS novo ou existente, implementa uma aplicação com o runtime Kata e, opcionalmente, verifica o isolamento do kernel.

Pré-requisitos

A versão CLI do Azure 2.80.0 ou posterior. Corre az --version para encontrar a versão da tua CLI do Azure e corre az upgrade para atualizar. Para mais detalhes, consulte os passos em Instalar CLI do Azure.
O AKS suporta sandboxing Pod na versão 1.27.0 do Kubernetes e superiores.
Para gerir um cluster Kubernetes, use o cliente kubectlde linha de comandos Kubernetes . Azure Cloud Shell vem com kubectl. Podes instalar kubectl localmente usando o az aks install-cli comando.

Limitações

As seguintes restrições aplicam-se ao sandboxing Pod:

Os contentores Kata podem não atingir os limites de desempenho do IOPS que os containers tradicionais conseguem atingir no Ficheiros do Azure e em SSD locais de alto desempenho.
O Microsoft Defender for Containers não oferece suporte à avaliação de pods de tempo de execução do Kata.
Acesso à rede host-network Kata não é suportado. Não podes aceder diretamente à configuração de rede do host a partir da VM.
A alocação de CPU e memória com sandboxing Pod difere de runc. Cada pod Kata é executado numa máquina virtual do pod cujo tamanho fixo de memória se baseia no limite de memória do pod ou é, por predefinição, de 512 Mi se não for especificado um limite. Os limites de CPU determinam a alocação de vCPU da VM pod, e os limites fracionados são arredondados para um vCPU inteiro nessa alocação. Para mais informações, veja considerações sobre o sandboxing de pods.
O sandboxing pod é suportado apenas no Azure Linux. Ubuntu e Windows não são suportados. Para mais informações, consulte Azure Linux container host para AKS.
Não pode ativar o Federal Information Processing Standard (FIPS) ou o Trusted Launch num pool de nós que utilize o sandboxing do Pod. Para mais informações, veja considerações sobre o sandboxing de pods.
A arquitetura Arm64 não é suportada num pool de nós que use sandboxing Pod.

Como funciona

O isolamento de pods no AKS baseia-se no projeto de código aberto Kata Containers. Os Kata Containers a correr no host de contentores Azure Linux para AKS fornecem isolamento baseado em VM e um kernel separado para cada pod. O sandboxing de pods permite alocar recursos para cada pod e não os partilha com outros Kata Containers ou containers de namespace a correr no mesmo host.

A arquitetura da solução baseia-se nos seguintes componentes principais:

O host de contêiner do Azure Linux para AKS
Hipervisor Microsoft Hyper-V
Monitor de Máquina Virtual (VMM) Cloud-Hypervisor de código aberto
Integração com Kata Containers para o runtime

Implementar sandboxing Pod usando Kata Containers é semelhante ao fluxo de trabalho padrão containerd para implementar containers. Clusters com sandboxing Pod ativado vêm com uma classe de runtime específica que podes consultar num manifesto pod (runtimeClassName: kata-vm-isolation). Para mais informações sobre os padrões e personalização das classes em tempo de execução, consulte Considerações para o sandboxing em Pods.

Para usar esta funcionalidade com um pod, a única diferença é adicionar o runtimeClassNamekata-vm-isolation à especificação do pod. Quando um pod usa a kata-vm-isolation runtimeClass, o hipervisor lança uma máquina virtual leve com o seu próprio kernel, para a carga de trabalho operar.

Criar um cluster com sandboxing Pod

Execute as etapas a seguir para implantar um cluster do Azure Linux AKS usando a CLI do Azure.

Crie um cluster AKS executando o az aks create comando com os seguintes parâmetros:

Parâmetro	Valor obrigatório	Notes
`--workload-runtime`	`KataVmIsolation`	Ativa o isolamento em sandbox dos pods no pool de nós.
`--os-sku`	`AzureLinux`	O sandboxing pod suporta apenas o SKU Azure Linux OS.
`--node-vm-size`	Um tamanho de máquina virtual de geração 2 que suporta virtualização aninhada	Por exemplo, use o tamanho de uma VM da série Dsv3 .
`--node-count`	`3`	Cria três nós para este exemplo. Ajuste o valor de acordo com a sua carga de trabalho.

O exemplo seguinte cria um cluster chamado myAKSCluster com três nós no 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

Execute o seguinte comando para obter credenciais de acesso para o cluster Kubernetes. Use o az aks get-credentials comando e substitua os valores do nome do cluster e do nome do grupo de recursos.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```
Liste todos os Pods em todos os namespaces executando o kubectl get pods comando.
```
kubectl get pods --all-namespaces
```

Ativar o sandboxing Pod num cluster existente

Para usar esse recurso com um cluster AKS existente, os seguintes requisitos devem ser atendidos:

O cluster executa Kubernetes versão 1.27.0 ou superior.
Use o comando seguinte para ativar o sandboxing do Pod, criando um pool de nós para o hospedar.

Adicione um conjunto de nós ao seu cluster AKS usando o az aks nodepool add comando com os seguintes parâmetros:

Parâmetro	Valor obrigatório	Notes
`--resource-group`	O grupo de recursos que contém o cluster AKS existente	Por exemplo, use `myResourceGroup`.
`--cluster-name`	O nome do cluster AKS existente	Por exemplo, use `myAKSCluster`.
`--name`	Um nome de pool de nós único	Por exemplo, use `nodepool2`.
`--workload-runtime`	`KataVmIsolation`	Ativa o isolamento em sandbox dos pods no pool de nós.
`--os-sku`	`AzureLinux`	O sandboxing pod suporta apenas o SKU Azure Linux OS.
`--node-vm-size`	Um tamanho de máquina virtual de geração 2 que suporta virtualização aninhada	Por exemplo, use o tamanho de uma VM da série Dsv3 .
`--node-count`	`1`	Cria um nó para este exemplo. Ajuste o valor de acordo com a sua carga de trabalho.

O exemplo a seguir adiciona um pool de nós a myAKSCluster com um nó em nodepool2 no 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

Execute o comando az aks update para reconciliar a configuração do cluster, para que o cluster reconheça o novo pool de nós com o runtime de carga de trabalho KataVmIsolation.
```
az aks update --name myAKSCluster --resource-group myResourceGroup
```
Verifique se a atualização do cluster foi concluída com sucesso e se o pool de nós de sandboxing do Pod utiliza o tempo de execução esperado da carga de trabalho, o SKU do SO e o tamanho da VM.
```
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
```
O estado de provisionamento do cluster deve ser Succeeded. A saída do pool de nós deve mostrar KataVmIsolation, AzureLinux, e o tamanho da VM que selecionaste.

Implementar aplicações usando sandboxing Pod

Ao usar o sandboxing de pods, pode implementar uma combinação de pods padrão que não usam o runtime Kata juntamente com pods Kata que usam esse runtime. Um pod Kata especifica runtimeClassName: kata-vm-isolation na sua especificação do pod.

A classe de runtime seleciona o runtime Kata, mas também deves definir restrições de agendamento quando precisares que cargas de trabalho corram num pool específico de nós de sandboxing Pod. Por exemplo, use o rótulo do conjunto de nós do AKS integrado num nodeSelector. Substitui nodepool2 pelo nome do pool de nós de sandboxing do teu Pod.

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

Para uma separação mais forte, podes contaminar o pool de nós de sandboxing do Pod e adicionar uma tolerância correspondente às cargas de trabalho do Kata. Uma contaminação sem tolerância correspondente impede que outras cargas de trabalho se escalonem nesse pool de nós. Para mais informações, consulte Utilizar taints de nós num cluster do AKS.

Implementar uma aplicação com o runtime Kata

Para implementar um pod com o runtime Kata no teu cluster AKS, realiza os seguintes passos.

Cria um ficheiro chamado kata-app.yaml para descrever o teu kata pod e depois cola o seguinte manifesto.

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

O valor da especificação do pod para runtimeClassName é kata-vm-isolation.

Implemente o pod Kubernetes executando o kubectl apply comando e especifique o seu ficheiro kata-app.yaml :
```
kubectl apply -f kata-app.yaml
```
A saída do comando é semelhante ao seguinte exemplo:
```
pod/isolated-pod created
```

Verificar isolamento do kernel (opcional)

Para comparar os núcleos dos pods Kata e não-Kata, crie um ficheiro chamado normal-app.yaml. O manifesto seguinte define um pod padrão sem o ambiente de execução 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"]

Acione o pod padrão usando o kubectl apply comando.
```
kubectl apply -f normal-app.yaml
```
Para aceder a um contentor dentro do cluster AKS, inicie uma sessão shell executando o kubectl exec comando. Neste exemplo, estás a aceder ao contentor dentro de isolated-pod.
```
kubectl exec -it isolated-pod -- /bin/sh
```
O Kubectl liga-se ao seu cluster, executa /bin/sh dentro do primeiro container dentro de isolated-pod, e encaminha os fluxos de entrada e saída do seu terminal para o processo do container. Também podes iniciar uma sessão de shell no contentor que hospeda o pod não-Kata para veres as diferenças.
Depois de iniciar uma sessão de shell com o contentor a partir de isolated-pod, execute os comandos para verificar se o contentor kata está em execução numa sandbox de pod. Tem uma versão de kernel diferente em comparação com o contentor não-Kata fora do sandbox.

Para ver a versão do kernel, execute o seguinte comando:
```
uname -r
```
O exemplo a seguir é semelhante à saída do kernel do pod sandbox:
```
[user]/# uname -r
6.6.96.mshv1
```
Inicie uma sessão de shell no contentor a partir de normal-pod para verificar a saída do kernel.
```
kubectl exec -it normal-pod -- /bin/bash
```
Para ver a versão do kernel, execute o seguinte comando:
```
uname -r
```
O exemplo seguinte assemelha-se à saída da VM que está em execução com normal-pod, que utiliza um kernel diferente do pod Kata em execução dentro do pod sandbox.
```
6.6.100.mshv1-1.azl3
```

Limpeza de recursos

Quando terminares de avaliar esta funcionalidade, limpa os recursos que já não precisas para evitar as cobranças do Azure. Se implementou um novo cluster como parte da sua avaliação ou teste, execute o seguinte az aks delete comando para eliminar o cluster AKS.
```
az aks delete --resource-group myResourceGroup --name myAKSCluster
```
Se implementaste o sandboxing de pods num cluster existente, podes remover os pods usando o kubectl delete pod comando.
```
kubectl get pods
kubectl delete pod <kata-pod-name>
```
Para remover os recursos de computação do Pod sandboxing, também podes eliminar o pool de nós Kata usando o az aks nodepool delete comando. Antes de eliminar o pool de nós, certifique-se de que não há cargas de trabalho que queira manter a correr nele.
```
az aks nodepool delete \
  --cluster-name myAKSCluster \
  --resource-group myResourceGroup \
  --name nodepool2
```

Próximos passos

Saiba mais sobre os Azure Dedicated hosts para os nós do seu cluster AKS, permitindo o uso de isolamento de hardware e controle sobre eventos de manutenção da plataforma Azure.
Para aprofundar a exploração do isolamento em sandbox do Pod e dos cenários de carga de trabalho, experimente os laboratórios de isolamento em sandbox do Pod.

Comentários

Esta página foi útil?

Última atualização a 2026-10-02