Isolamento em sandbox de pods com o AKS (Serviço de Kubernetes do Azure)

O sandbox de pods no AKS usa contêineres Kata para executar cada pod em sandbox em uma máquina virtual (VM) leve com seu próprio kernel convidado. Essa fronteira computacional isola a carga de trabalho tanto do kernel do host quanto das cargas de trabalho em outras VMs de pod. Para saber mais sobre a arquitetura, os benefícios e os casos de uso, consulte Visão geral do pod sandboxing em AKS (Serviço de Kubernetes do Azure).

Neste artigo, você implantará o pod sandboxing em um cluster novo ou existente do AKS do Azure Linux, implantará um aplicativo com o runtime kata e, opcionalmente, verificará o isolamento do kernel.

Pré-requisitos

A CLI do Azure versão 2.80.0 ou posterior. Execute az --version para localizar a versão da CLI do Azure e execute az upgrade para atualizar. Para obter mais detalhes, consulte as etapas na instalação da CLI do Azure.
O AKS dá suporte ao pod sandboxing no Kubernetes versão 1.27.0 e superior.
Para gerenciar um cluster do Kubernetes, use o cliente kubectlde linha de comando do Kubernetes. O Azure Cloud Shell vem com o kubectl. Você pode instalar kubectl localmente usando o az aks install-cli comando.

Limitações

As seguintes restrições se aplicam à área restrita do Pod:

Os Kata Containers podem não atingir os limites de desempenho de IOPS que os contêineres tradicionais conseguem alcançar nos Arquivos do Azure e no SSD local de alto desempenho.
O Microsoft Defender para Contêineres não dá suporte à avaliação de pods de runtime do Kata.
Não há suporte para acesso à rede de host kata. Você não pode acessar diretamente a configuração de rede de host de dentro da VM.
A alocação de CPU e de memória com isolamento do Pod difere de runc. Cada pod Kata é executado em uma VM de pod cujo tamanho de memória fixa é baseado no limite de memória do pod ou usa como padrão 512Mi se você não especificar um limite. Os limites de CPU determinam a alocação de vCPU da VM do pod e os limites fracionários são arredondados para uma vCPU inteira para essa alocação. Para obter mais informações, consulte Considerações sobre sandbox de pods.
O sandboxing de pod só tem suporte em Azure Linux. Não há suporte para Ubuntu e Windows. Para obter mais informações, consulte host Linux de contêineres do Azure para AKS.
Você não pode habilitar o FIPS (Federal Information Processing Standard) ou o Trusted Launch em um pool de nós que usa o pod sandboxing. Para obter mais informações, consulte Considerações sobre sandbox de pods.
A arquitetura Arm64 não é compatível com um pool de nós que usa sandbox de pods.

Como ele funciona

O pod sandboxing no AKS se baseia no projeto kata containers de software livre. Os Contêineres Kata executados no host de contêiner do Azure Linux para AKS oferecem isolamento baseado em VM e um kernel separado para cada pod. O sandbox de pods permite alocar recursos para cada pod e não os compartilha com outros contêineres Kata ou contêineres de namespace em execução 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 Hyper-V da Microsoft
Monitor de Máquina Virtual (VMM) de código aberto do Hipervisor de Nuvem
Integração do Kata Containers ao runtime

Implantar a área restrita do Pod usando contêineres Kata é semelhante ao fluxo de trabalho padrão containerd para implantar contêineres. Clusters com o isolamento de Pods habilitado vêm com uma classe de runtime específica que você pode referenciar em um manifesto de Pod (runtimeClassName: kata-vm-isolation). Para obter mais informações sobre os padrões e a personalização da classe de runtime, consulte Considerações sobre sandbox de pods.

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

Criar um cluster com área restrita do Pod

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

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

Parâmetro	Valor obrigatório	Observações
`--workload-runtime`	`KataVmIsolation`	Habilita o sandbox de pods no pool de nós.
`--os-sku`	`AzureLinux`	O sandboxing de pod dá suporte apenas à SKU do sistema operacional Linux Azure.
`--node-vm-size`	Um tamanho de VM de geração 2 que suporta virtualização aninhada	Por exemplo, use um tamanho de VM da série Dsv3 .
`--node-count`	`3`	Cria três nós para este exemplo. Ajuste o valor da sua carga de trabalho.

O exemplo a seguir 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 comando a seguir para obter credenciais de acesso para o cluster do Kubernetes. Use o az aks get-credentials comando e substitua os valores para o nome do cluster e o 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 isolamento de Pod em um cluster existente

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

O cluster executa o Kubernetes versão 1.27.0 ou superior.
Use o comando a seguir para habilitar a área restrita do Pod criando um pool de nós para hospedá-lo.

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

Parâmetro	Valor obrigatório	Observações
`--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 exclusivo do pool de nós	Por exemplo, use `nodepool2`.
`--workload-runtime`	`KataVmIsolation`	Habilita o sandbox de pods no pool de nós.
`--os-sku`	`AzureLinux`	O sandboxing de pod dá suporte apenas à SKU do sistema operacional Linux Azure.
`--node-vm-size`	Um tamanho de VM de geração 2 que suporta virtualização aninhada	Por exemplo, use um tamanho de VM da série Dsv3 .
`--node-count`	`1`	Cria um nó para este exemplo. Ajuste o valor da sua carga de trabalho.

O exemplo a seguir adiciona um pool de nós ao myAKSCluster com um nó no nodepool2 dentro do 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 êxito e se o pool de nós de área restrita pod usa o runtime de carga de trabalho esperado, a SKU do SISTEMA Operacional 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 você selecionou.

Implantar aplicativos usando o pod sandboxing

Ao usar o sandbox de pods, você pode implantar uma combinação de pods padrão que não usam o runtime Kata, juntamente com pods Kata que usam o runtime. Um pod Kata especifica runtimeClassName: kata-vm-isolation em sua especificação de pod.

A classe de runtime seleciona o runtime do Kata, mas você também deve definir restrições de agendamento quando precisar de cargas de trabalho para serem executadas em um pool de nós de área restrita do Pod específico. Por exemplo, use o rótulo de pool de nós AKS integrado em um nodeSelector. Substitua nodepool2 pelo nome do seu pool de nós de sandbox de Pod.

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

Para uma separação mais forte, você pode manchar o pool de nós de área restrita pod e adicionar uma tolerância correspondente às cargas de trabalho kata. Uma mancha sem tolerância correspondente impede que outras cargas de trabalho agendem nesse pool de nós. Para obter mais informações, consulte Usar taints de nó em um cluster do AKS.

Implantar um aplicativo com o runtime do Kata

Para implantar um pod com o runtime Kata no cluster do AKS, execute as etapas a seguir.

Crie um arquivo chamado kata-app.yaml para descrever seu pod kata e então cole o manifesto a seguir.

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.

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

Verificar o isolamento do kernel (opcional)

Para comparar os kernels de pods Kata e não Kata, crie um arquivo chamado normal-app.yaml. O manifesto a seguir define um pod padrão sem o runtime do 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"]

Implante o pod padrão usando o kubectl apply comando.
```
kubectl apply -f normal-app.yaml
```
Para acessar um contêiner dentro do cluster do AKS, inicie uma sessão de shell executando o kubectl exec comando. Neste exemplo, você está acessando o contêiner dentro de isolated-pod.
```
kubectl exec -it isolated-pod -- /bin/sh
```
O kubectl se conecta ao seu cluster, executa /bin/sh dentro do primeiro contêiner em isolated-pod, e encaminha os fluxos de entrada e saída do seu terminal para o processo do contêiner. Você também pode iniciar uma sessão de shell no contêiner que hospeda o pod não-Kata para ver as diferenças.
Após iniciar uma sessão de shell para o contêiner a partir de isolated-pod, execute comandos para verificar se o contêiner kata está sendo executado em um sandbox de pod. Ele possui uma versão de kernel diferente em comparação com o contêiner não-Kata fora do sandbox.

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

Limpar os recursos

Ao concluir a avaliação desta funcionalidade, remova os recursos de que não precisa mais para evitar cobranças do Azure. Se você implantou um novo cluster como parte de sua avaliação ou teste, execute o comando a seguir az aks delete para excluir o cluster do AKS.
```
az aks delete --resource-group myResourceGroup --name myAKSCluster
```
Se você implantou o pod sandboxing em um cluster existente, poderá 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 em sandbox do Pod, você também pode excluir o pool de nós Kata usando o comando az aks nodepool delete. Antes de excluir o pool de nós, verifique se nenhuma carga de trabalho que você deseja reter está em execução nele.
```
az aks nodepool delete \
  --cluster-name myAKSCluster \
  --resource-group myResourceGroup \
  --name nodepool2
```

Próximas etapas

Saiba mais sobre Hosts Dedicados do Azure para nós com seu cluster do AKS para usar o isolamento de hardware e o controle sobre eventos de manutenção da plataforma do Azure.
Para entender melhor o isolamento em sandbox de Pod e conhecer cenários de carga de trabalho, experimente os laboratórios de sandbox de Pod.

Comentários

Esta página foi útil?

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