Proteger o tráfego entre pods com políticas de rede no AKS (Serviço de Kubernetes do Azure)

Important

A partir de 30 de setembro de 2028, o AKS (Serviço de Kubernetes do Azure) não dá mais suporte ao NPM (Azure Network Policy Manager) em nós do Linux . Para evitar interrupções no serviço, você precisa migrar os clusters AKS que executam nós Linux do NPM para a Política de Rede Cilium até a data de fim do suporte. Para obter mais informações sobre essa desativação, consulte o comunicado de desativação do Azure Updates. Para se manter informado sobre anúncios e atualizações, acompanhe as notas de lançamento do AKS.

Identificar clusters afetados

Para localizar clusters do AKS com pools de nós Linux usando o Azure Network Policy Manager (NPM), execute a consulta do Azure Resource Graph que lista todos os clusters do AKS onde agentPool.osType != "Windows" e properties.networkProfile.networkPolicy == "azure".

Important

A partir de 31 de março de 2028, o AKS (Serviço de Kubernetes do Azure) não dá mais suporte à rede kubenet. Para evitar interrupções de serviço, atualize para a rede de sobreposição da CNI (Interface de Rede de Contêiner do Azure) antes da data de fim do suporte. Para obter mais informações sobre essa desativação, consulte o problema de desativação do GitHub e o anúncio de desativação do Azure Updates. Para se manter informado sobre anúncios e atualizações, acompanhe as notas de lançamento do AKS.

Instale um mecanismo de política de rede e crie políticas de rede do Kubernetes para controlar o fluxo de tráfego entre pods em clusters do AKS usando o CLI do Azure ou o Terraform.

Visão geral da política de rede

Por padrão, todos os pods em um cluster do AKS podem enviar e receber tráfego sem limitações. Para melhorar a segurança, você pode definir regras que controlam o fluxo de tráfego.

A política de rede é uma especificação do Kubernetes que define políticas de acesso para comunicação entre pods. Ao usar políticas de rede, você define um conjunto ordenado de regras para enviar e receber tráfego. Você aplica as regras a uma coleção de pods que correspondem a um ou mais seletores de rótulo.

Você define as regras de política de rede como manifestos YAML e pode incluí-las em manifestos mais amplos que também criam uma implantação ou serviço.

Opções de política de rede no AKS

O Azure fornece três mecanismos de política de rede para impor políticas de rede:

  • Cilium (para clusters AKS usando Azure CNI PowCiliumered por Cilium)
  • NPM (Gerenciador de Política de Rede do Azure)
  • Calico (uma solução de segurança de rede e rede de software livre fundada pela Tigera)

É recomendável usar o Cilium, que fornece suporte robusto para políticas nativas do Kubernetes, recursos estendidos como a política de Camada 7 e filtragem de FQDN e um plano de dados baseado em eBPF que oferece melhor desempenho, escalabilidade e segurança em comparação com soluções baseadas em IPTables.

Para aplicar as políticas especificadas, o Azure NPM usa IPTables nos nós Linux. As políticas são convertidas em conjuntos de pares de IP permitidos e não permitidos. O sistema programa esses pares como IPTable regras de filtro.

Diferenças entre mecanismos de política de rede: Cilium, NPM do Azure e Calico

Mecanismo de política de rede Plataformas com suporte Opções de rede com suporte Conformidade de especificação do Kubernetes Outros recursos Support
Cilium Linux CNI do Azure Dá suporte a todos os tipos de política FQDN, L3/4, L7 Equipe de engenharia e suporte do Azure
NPM do Azure Linux CNI do Azure Dá suporte a todos os tipos de política N/A Equipe de engenharia e suporte do Azure
Calico Linux, Windows Server 2019, Windows Server 2022 Azure CNI (Linux, Windows Server 2019, Windows Server 2022) e kubenet (Linux) Dá suporte a todos os tipos de política O AKS não testa nem dá suporte a recursos além da imposição de políticas networking.k8s.io. Equipe de engenharia e suporte do Azure

limitações do Gerenciador de Políticas de Rede Azure

Azure NPM tem as seguintes limitações:

  • Não há suporte para escalonamento além de 250 nós e 20.000 pods. Se você tentar escalar além desses limites, poderão ocorrer erros por Memória Insuficiente (OOM). Para obter melhor escalabilidade e suporte ao IPv6, recomendamos usar ou atualizar para o CNI do Azure alimentado pelo Cilium para seu mecanismo de política de rede.
  • Não há suporte para o IPv6. Caso contrário, ele dá suporte total às especificações de política de rede no Linux.
  • A partir de 30 de setembro de 2026, o AKS (Serviço de Kubernetes do Azure) não oferece mais suporte ao Azure Network Policy Manager (NPM) em nós do Windows.

Problemas conhecidos com o Gerenciador de Políticas de Rede do Azure

Você pode enfrentar problemas temporários de conectividade para novas conexões de/para pods em nós afetados ao editar ou excluir uma política de rede “suficientemente grande”. Atingir essa condição de corrida nunca afeta as conexões ativas.

Se essa condição de corrida ocorrer para um nó, o pod do NPM do Azure nesse nó entrará em um estado em que ele não poderá atualizar as regras de segurança, o que pode levar a uma conectividade inesperada para novas conexões de/para pods no nó afetado. Para atenuar o problema, o pod do NPM do Azure reinicia automaticamente cerca de 15 segundos depois de entrar nesse estado. Enquanto é reinicializado no nó afetado, o NPM do Azure exclui todas as regras de segurança e, em seguida, reaplica as regras de segurança para todas as políticas de rede. Embora todas as regras de segurança estejam sendo reaplicadas, há uma chance de conectividade temporária e inesperada para novas conexões de/para pods no nó afetado.

Para limitar a chance de atingir essa condição de corrida, você pode reduzir o tamanho da política de rede. É mais provável que esse problema ocorra em uma política de rede com várias seções ipBlock. É menos provável que uma política de rede com quatro ou menosipBlock seções atinja o problema.

Limitações do Calico

  • O AKS não dá suporte à execução do Calico gerenciado pelo AKS ao lado do Calico Cloud ou do Calico Enterprise, pois essa combinação pode causar conflitos e comportamentos não intencionais. Se você usar o Calico Cloud ou Enterprise, Microsoft recomenda desabilitar o Calico gerenciado pelo AKS. Entre em contato com a Tigera para obter suporte com esses produtos.
  • O Calico gerenciado pelo AKS dá suporte apenas a políticas networking.k8s.io de rede. Se você pretende usar políticas projectcalico.org/v3, considere migrar para uma solução auto-hospedada, como Calico Cloud, Calico Enterprise ou BYOCNI.

Políticas de rede e serviços do balanceador de carga

O roteamento de serviço do Kubernetes para serviços de entrada e saída geralmente envolve reescrever os IPs de origem e de destino no tráfego que está sendo processado, incluindo o tráfego que entra no cluster de um LoadBalancer serviço. Esse comportamento de reescrita significa que as políticas de rede podem não processar corretamente o tráfego recebido ou enviado para um serviço externo. Para obter mais informações, consulte a documentação de Políticas de Rede do Kubernetes.

Para restringir quais fontes podem enviar tráfego para um serviço de balanceador de carga, use spec.loadBalancerSourceRanges para configurar o bloqueio de tráfego que se aplica antes de qualquer reescrita ocorrer. Para obter mais informações, consulte a documentação do balanceador de carga padrão do AKS.

Antes de começar

Você precisará da CLI do Azure versão 2.0.61 ou posterior instalada e configurada. Localize a versão executando o comando az --version. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure.

Em vez de usar uma identidade atribuída pelo sistema, você também pode usar uma identidade atribuída pelo usuário. Para obter mais informações, confira Usar identidades gerenciadas.

  • Terraform instalado, versão 1.6 ou posterior.
  • CLI do Azure instalada e autenticada. Localize a versão executando o comando az --version. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure. Use o CLI do Azure para se conectar ao cluster depois que o Terraform o criar.
  • kubectl instalado. Você pode instalá-lo localmente usando o az aks install-cli comando. Você usa kubectl para verificar o comportamento da política de rede.

Criar um cluster do AKS com o Azure Network Policy Manager (Linux)

  1. Defina variáveis de ambiente para o nome do grupo de recursos, o nome do cluster e o local. Substitua os valores conforme necessário.

    export RESOURCE_GROUP=myResourceGroup
    export CLUSTER_NAME=myAKSCluster
    export LOCATION=eastus
    
  2. Crie o grupo de recursos usando o az group create comando.

    az group create --resource-group $RESOURCE_GROUP --location $LOCATION
    
  3. Crie um cluster do AKS usando az aks create e especifique azure para o network-plugin e network-policy.

    az aks create \
        --resource-group $RESOURCE_GROUP \
        --name $CLUSTER_NAME \
        --node-count 1 \
        --network-plugin azure \
        --network-policy azure \
        --generate-ssh-keys
    

    Cuidado

    O Azure Network Policy Manager (NPM) para nós Linux será desativado em 30 de setembro de 2028. Para novas implantações, recomendamos usar o CNI do Azure alimentado pelo Cilium com a Política de Rede Cilium. Para migrar clusters existentes, consulte Migrar do NPM para a Política de Rede do Cilium.

Criar um cluster do AKS com o Calico

Crie um cluster do AKS usando o az aks create comando. Especifique --network-plugin azure e --network-policy calico. Quando você especifica --network-policy calico, habilita o Calico em pools de nós Linux e Windows.

Se você planeja adicionar pools de nós do Windows ao seu cluster, inclua os parâmetros windows-admin-password e windows-admin-username que atendam aos requisitos de senha do Windows Server. Para criar um nome de usuário para usar como credenciais de administrador para seus contêineres de Windows Server em seu cluster, o comando a seguir solicita um nome de usuário. Defina-o como WINDOWS_USERNAME.

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

Important

Neste momento, o uso de políticas de rede do Calico com nós do Windows está disponível em novos clusters usando o Kubernetes versão 1.20 ou posterior com o Calico 3.17.2 e exige que você use a rede CNI do Azure. Os nós do Windows em clusters do AKS com o Calico habilitado também têm o IP flutuante habilitado por padrão.

Para os clusters com apenas pools de nós do Linux que executam o Kubernetes 1.20 com versões anteriores do Calico, a versão do Calico é atualizada automaticamente para 3.17.2.

Instalar o Azure Network Policy Manager ou o Calico em um cluster existente

Warning

Tenha as seguintes informações em mente ao instalar o NPM do Azure ou o Calico em um cluster existente:

  • O processo de atualização dispara cada pool de nós a ter a imagem recriada simultaneamente. Não há suporte para atualização de cada pool de nós separadamente.
  • Dentro de cada pool de nós, os nós seguem o mesmo processo de reimagem das operações padrão de atualização de versão do Kubernetes. Esse comportamento significa que os nós de buffer são adicionados temporariamente para minimizar a interrupção dos aplicativos em execução durante o processo de reimagem do nó. Quaisquer interrupções que possam ocorrer são semelhantes às que você pode encontrar durante a atualização da imagem de um nó ou na atualização da versão do Kubernetes.

As informações a seguir se aplicam a atualizações do kubenet com Calico para Azure CNI Overlay com Calico:

  • Em clusters kubenet com Calico habilitado, o Calico é usado como CNI e mecanismo de política de rede.
  • Nos clusters CNI do Azure, o Calico é usado apenas para aplicação de políticas de rede, não como CNI. Isso pode causar um pequeno atraso entre o início do pod e o momento em que o Calico permite o tráfego de saída do pod.

Atualize um cluster existente para instalar o NPM do Azure ou o Calico usando o az aks update comando e especificando azure ou calico para o --network-policy parâmetro. O seguinte comando de exemplo mostra como instalar o NPM do Azure:

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --network-policy azure

Atualizar um cluster existente com o NPM do Azure ou o Calico para o Cilium

Para clusters que já usam Azure CNI, atualize o plano de dados de rede para Cilium. Os clusters do Kubenet devem primeiro migrar para o Azure CNI Overlay e, em seguida, atualizar o plano de dados da rede para o Cilium em uma operação separada. Examine os pré-requisitos e siga as etapas em Atualizar um cluster existente para Azure CNI alimentado pelo Cilium.

Conecte-se ao cluster do AKS

Configure kubectl para se conectar ao seu cluster usando o comando az aks get-credentials. Este comando baixa as credenciais e configura a CLI do Kubernetes para usá-las.

az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

Verificar a configuração da política de rede

Para iniciar a verificação da política de rede, você criará um aplicativo de exemplo e definirá regras de tráfego.

  1. Crie um namespace nomeado demo para executar os pods de exemplo usando o kubectl create namespace comando.

    kubectl create namespace demo
    
  2. Crie um pod nomeado server para servir na porta TCP 80 usando o kubectl run comando.

    kubectl run server -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --labels="app=server" --port=80 --command -- /agnhost serve-hostname --tcp --http=false --port "80"
    
  3. Crie um pod nomeado client para executar o Bash usando o kubectl run comando.

    kubectl run -it client -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --command -- bash
    

    Note

    Se você quiser agendar o cliente ou o servidor em um nó específico, adicione o seguinte trecho de código antes do argumento --command no comando de criação do pod kubectl run: --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux|windows"}}}'.

  4. Em uma janela separada, obtenha o endereço IP do server pod usando o kubectl get pod comando.

    kubectl get pod --output=wide -n demo
    

    Sua saída deve ser parecida com o seguinte exemplo de saída:

    NAME     READY   STATUS    RESTARTS   AGE   IP            NODE             NOMINATED NODE   READINESS GATES
    server   1/1     Running   0          30s   10.224.0.72   akswin22000001   <none>           <none>
    

Testar a conectividade com políticas de rede

Dica

Para testar a conectividade sem políticas de rede, execute o seguinte comando no shell do cliente: /agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp. Substitua <server-ip> pelo endereço IP do pod do servidor. Se a conexão for bem-sucedida, não haverá saída.

  1. Crie um arquivo chamado demo-policy.yaml e cole o manifesto YAML a seguir:

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: demo-policy
      namespace: demo
    spec:
      podSelector:
        matchLabels:
          app: server
      ingress:
      - from:
        - podSelector:
            matchLabels:
              app: client
        ports:
        - port: 80
          protocol: TCP
    
  2. Aplique o manifesto da política de rede usando o kubectl apply comando.

    kubectl apply -f demo-policy.yaml
    
  3. No shell do cliente, verifique a conectividade com o servidor usando o seguinte /agnhost comando:

    /agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp
    

    A conectividade com o tráfego é bloqueada, pois o servidor é rotulado com app=server, mas o cliente não é rotulado. Sua saída deve ser parecida com o seguinte exemplo de saída:

    TIMEOUT
    
  4. Rotule o client e verifique a conectividade com o servidor usando o comando kubectl label.

    kubectl label pod client -n demo app=client
    

    Se a conexão for bem-sucedida, não haverá saída.

Migrar para o Calico com gerenciamento próprio

O AKS dá suporte apenas ao Calico para políticas de rede padrão do Kubernetes e não testa outros recursos. Se você quiser migrar para o Calico autogerenciado, siga as instruções do Tigera em Migrar do Calico gerenciado pelo Azure para o Calico autogerenciado. A documentação do Tigera menciona que, para o Calico autogerenciado, você define --network-policy none como na seção de desinstalação.

Desinstalar o Azure Network Policy Manager ou Calico

Note

Tenha as seguintes informações em mente ao desinstalar o NPM do Azure ou o Calico de um cluster:

  • O processo de desinstalação não remove CRDs (Definições de Recursos Personalizados) e CRs (Recursos Personalizados) usados pelo Calico. Todas essas CRDs e CRs têm nomes que terminam com projectcalico.org ou tigera.io. Você pode remover manualmente esses CRDs e CRs associados depois de desinstalar com êxito o Calico.
  • A atualização não remove nenhum recurso de política de rede no cluster, mas as políticas não são mais impostas após o processo de desinstalação.

Remova o Azure Network Policy Manager ou o Calico de um cluster existente usando o az aks update comando e especificando none o --network-policy parâmetro.

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --network-policy none

Alterar a política de rede do cluster

As etapas a seguir mostram como alterar a política de rede existente de um cluster para o Calico. O procedimento requer que a política de rede seja alterada para none e, em seguida, alterada para calico.

Os comandos usam variáveis especificadas anteriormente neste artigo Criar um cluster do AKS com o Linux (Azure Network Policy Manager). Caso contrário, substitua $RESOURCE_GROUP e $CLUSTER_NAME pelo nome e o grupo de recursos do cluster.

  1. Execute o comando a seguir para mostrar a política de rede existente do cluster.

    az aks show \
      --resource-group $RESOURCE_GROUP \
      --name $CLUSTER_NAME \
      --query "networkProfile" \
      --output table
    
  2. Execute o comando a seguir para definir a política de rede como none.

    az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --network-policy none
    
  3. Execute o comando a seguir para definir a política de rede como calico.

    az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --network-policy calico
    

Limpar os recursos

Neste artigo, você criou dois namespaces e dois pods e aplicou uma política de rede. Se você não precisar mais desses recursos, poderá excluí-los.

Exclua os recursos usando o kubectl delete comando.

kubectl delete namespace demo

Se você seguiu as etapas deste artigo para criar um cluster do AKS, use o az group delete comando para excluir o grupo de recursos do AKS e seu grupo de recursos relacionado com um nome que começa com MC_.

az group delete --resource-group $RESOURCE_GROUP --no-wait --yes

Criar um cluster do AKS com a política de rede Cilium usando o Terraform

Esta seção mostra como usar o Terraform para implantar um cluster do AKS que usa Azure CNI Powered by Cilium para rede e aplicação de políticas de rede e, em seguida, usar um recurso de Kubernetes NetworkPolicy para controlar o tráfego entre pods.

Este exemplo implanta:

  • Um grupo de recursos.
  • Um cluster do AKS que utiliza rede de sobreposição do Azure CNI com o Cilium como mecanismo de política de rede e plano de dados da rede.
  1. Crie um diretório para testar e executar o código terraform de exemplo e torná-lo o diretório atual.

  2. Crie um arquivo chamado main.tf, depois insira o código a seguir:

    terraform {
      required_version = ">= 1.6.0"
      required_providers {
        azurerm = {
          source  = "hashicorp/azurerm"
          version = "~> 4.0"
        }
      }
    }
    
    provider "azurerm" {
      features {}
    }
    
    resource "azurerm_resource_group" "example" {
      name     = "rg-aks-network-policy-example"
      location = "eastus"
    }
    
    resource "azurerm_kubernetes_cluster" "example" {
      name                = "aks-network-policy-example"
      location            = azurerm_resource_group.example.location
      resource_group_name = azurerm_resource_group.example.name
      dns_prefix          = "aksnetpolicyexample"
    
      default_node_pool {
        name       = "default"
        node_count = 1
        vm_size    = "Standard_D2s_v3"
    
        upgrade_settings {
          drain_timeout_in_minutes      = 0
          max_surge                     = "10%"
          node_soak_duration_in_minutes = 0
        }
      }
    
      identity {
        type = "SystemAssigned"
      }
    
      network_profile {
        network_plugin      = "azure"
        network_plugin_mode = "overlay"
        network_policy      = "cilium"
        network_data_plane  = "cilium"
        load_balancer_sku   = "standard"
      }
    }
    
  3. Inicialize o Terraform executando o terraform init comando. Esse comando baixa o provedor do Azure necessário para gerenciar recursos do Azure com o Terraform.

    terraform init
    
  4. Formate e valide a configuração executando os comandos terraform validate e terraform fmt.

    terraform fmt
    terraform validate
    
  5. Crie um plano de execução do Terraform executando o terraform plan comando. Este comando mostra os recursos que o Terraform cria ou modifica em sua assinatura Azure.

    terraform plan
    
  6. Aplique o plano de execução do Terraform executando o terraform apply comando. Esse comando cria os recursos definidos em seu main.tf arquivo em sua assinatura Azure.

    terraform apply
    

Conectar-se ao cluster do AKS usando o Terraform

  1. Instale a ferramenta de linha de comando do Kubernetes executando o az aks install-cli comando e verifique a instalação.

    az aks install-cli
    kubectl version --client
    
  2. Configure kubectl para se conectar ao seu cluster executando o comando az aks get-credentials. Este comando baixa as credenciais e configura a CLI do Kubernetes para usá-las.

    az aks get-credentials \
        --resource-group rg-aks-network-policy-example \
        --name aks-network-policy-example
    
  3. Verifique se o cluster está em execução executando o kubectl get nodes comando.

    kubectl get nodes
    

Verificar a configuração da política de rede usando o Terraform

Para verificar a configuração da política de rede, crie um aplicativo de exemplo e defina regras de tráfego.

  1. Crie um namespace nomeado demo para executar os pods de exemplo usando o kubectl create namespace comando.

    kubectl create namespace demo
    
  2. Crie um pod nomeado server para servir na porta TCP 80 executando o kubectl run comando.

    kubectl run server \
      -n demo \
      --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 \
      --labels="app=server" \
      --port=80 \
      --command -- /agnhost serve-hostname --tcp --http=false --port "80"
    
  3. Crie um pod nomeado client para executar o Bash usando o kubectl run comando.

    kubectl run -it client \
      -n demo \
      --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 \
      --command -- bash
    
  4. Em uma janela separada, obtenha o endereço IP do server pod usando o kubectl get pod comando.

    kubectl get pod --output=wide -n demo
    

    Use o endereço IP do pod server ao testar a conectividade a partir do shell client na próxima seção.

Testar a conectividade com políticas de rede usando o Terraform

O exemplo inclui um manifesto do Kubernetes NetworkPolicy que permite tráfego de entrada para pods rotulados app=server apenas a partir de pods rotulados app=client na porta TCP 80.

  1. Crie um arquivo chamado network-policy.yaml, depois insira o código a seguir:

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: demo-policy
      namespace: demo
    spec:
      podSelector:
        matchLabels:
          app: server
      policyTypes:
        - Ingress
      ingress:
        - from:
            - podSelector:
                matchLabels:
                  app: client
          ports:
            - protocol: TCP
              port: 80
    
  2. Aplique a política de rede usando o kubectl apply comando.

    kubectl apply -f network-policy.yaml
    
  3. client No shell, teste a conectividade com o servidor usando o seguinte /agnhost comando:

    /agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp
    

    A conectividade é bloqueada porque o servidor é rotulado com app=server, mas o cliente não está rotulado. Sua saída deve ser parecida com o seguinte exemplo de saída:

    TIMEOUT
    
  4. Rotule client e verifique a conectividade com o servidor usando o comando kubectl label.

    kubectl label pod client -n demo app=client
    
  5. client No shell, teste a conectividade com o servidor novamente usando o mesmo /agnhost comando:

    /agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp
    

    Se a conexão for bem-sucedida, não haverá saída.

  6. Verifique a política de rede usando os comandos kubectl describe networkpolicy e kubectl get networkpolicy.

    kubectl get networkpolicy -n demo
    kubectl describe networkpolicy demo-policy -n demo
    

    A saída mostra que os pods rotulados app=server estão selecionados, o tráfego de entrada é permitido na porta TCP 80 e somente os pods rotulados app=client podem iniciar conexões.

Limpar recursos usando o Terraform

Nesta seção, você criou um namespace, dois pods e uma política de rede. Se você não precisar mais desses recursos do Kubernetes, exclua-os antes de remover a infraestrutura de Azure subjacente.

Use o kubectl delete comando para excluir os recursos.

kubectl delete namespace demo

Warning

O comando a seguir remove o grupo de recursos, o cluster do AKS e todos os outros recursos associados ao grupo de recursos criado para este exemplo. Se você implantou outros recursos dentro desse grupo de recursos, o comando os excluirá também.

Remova os recursos de Azure usando o terraform destroy comando.

terraform destroy