Usar um balanceador de carga padrão no AKS (Serviço de Kubernetes do Azure)

O Azure Load Balancer opera na camada 4 do modelo de referência OSI que dá suporte a cenários de entrada e de saída. Ele distribui fluxos de entrada que chegam ao front-end do balanceador de carga para as instâncias do pool de back-end.

Quando integrado ao AKS, um balanceador de carga público tem duas finalidades:

• Forneça conexões de saída para os nós de cluster dentro da VNet (rede virtual) do AKS traduzindo o endereço IP privado para uma parte de endereço IP público de seu pool de saída.
• Forneça acesso a aplicativos por meio dos serviços de tipo LoadBalancerdo Kubernetes, permitindo que você dimensione facilmente seus aplicativos e crie serviços altamente disponíveis.

Este artigo aborda a integração com um balanceador de carga público no AKS. Para saber mais sobre a integração do balanceador de carga interno, confira Usar um balanceador de carga interno no AKS.

Pré-requisitos

• O AKS dá suporte ao Azure Load Balancer de SKU Standard, que é usado por padrão quando você cria um cluster do AKS. O SKU Standard dá acesso a funcionalidades como um pool de back-end maior, vários pools de nós, Zonas de Disponibilidade e é seguro por padrão. O SKU Básico foi desativado em 30 de setembro de 2025 e o AKS não dá mais suporte a ele. Se você já tem um cluster do AKS que usa o SKU Basic, consulte Atualização do Basic Load Balancer no AKS. Para obter mais informações sobre as SKUs do Load Balancer, consulte comparação de SKUs do Azure Load Balancer.
• Para obter uma lista completa das anotações com suporte para serviços do Kubernetes com o tipo LoadBalancer, confira Anotações do LoadBalancer.
• Este artigo pressupõe que você tenha um cluster do AKS com o Azure Load Balancer de SKU Standard. Se você precisar de um cluster do AKS, poderá criar um usando a CLI do Azure, o Azure PowerShell ou o portal do Azure.
• Você precisa ter o kubectl instalado e configurado para se conectar ao cluster do AKS. Para instalar kubectl, baixe suas credenciais de cluster e verifique a conexão, consulte Conectar-se ao cluster.

Limitations

As seguintes limitações se aplicam quando você cria e gerencia clusters do AKS que dão suporte a um balanceador de carga com o SKU Standard:

• O AKS gerencia o ciclo de vida e as operações dos nós do agente. Não há suporte para a modificação dos recursos de IaaS associados aos nós do agente. Um exemplo de uma operação sem suporte é fazer alterações manuais no grupo de recursos do balanceador de carga.

• Pelo menos um IP público ou prefixo de IP é necessário para permitir o tráfego de saída do cluster do AKS. O IP público ou o prefixo de IP é necessário para manter a conectividade entre o painel de controle e os nós do agente, bem como para manter a compatibilidade com as versões anteriores do AKS. Você tem as seguintes opções para especificar IPs públicos ou prefixos de IP ao usar um balanceador de carga SKU Standard:

  • Fornecer seus IPs públicos.
  • Forneça seus prefixos de IP público.
  • Especifique um número até 100 para permitir que o cluster do AKS crie esse tanto de IPs públicos de SKU Standard no mesmo grupo de recursos que o cluster do AKS. Esse grupo de recursos geralmente é nomeado com MC_ no início. O AKS atribui o IP público ao balanceador de carga de SKU Standard. Por padrão, um IP público é criado automaticamente no mesmo grupo de recursos que o cluster do AKS se nenhum IP público, prefixo de IP público ou número de IPs for especificado. Você também deve permitir endereços públicos e evitar a criação de qualquer política do Azure que cause banimento à criação do IP.

• Um IP público criado pelo AKS não pode ser reutilizado como um endereço IP público BYO (traga o seu). Você deve criar e gerenciar todos os endereços IP personalizados.

• Você não pode alterar a SKU do balanceador de carga modificando diretamente o recurso de balanceador de carga gerenciado pelo AKS. Para migrar um cluster AKS existente do SKU Basic descontinuado para o SKU Standard, use o processo de atualização do AKS com suporte. A migração causa tempo de inatividade e não pode ser revertida após o início.

• Os balanceadores de carga de SKU Standard dão suporte apenas a endereços IP de SKU Standard.

• Não há suporte para o Serviço de Link Privado quando o tipo de pool de back-end do balanceador de carga é definido como nodeIP.

Criar um serviço de balanceador de carga no AKS

Depois que você criar um cluster do AKS com o tipo de saída LoadBalancer (padrão), seu cluster estará pronto para usar o balanceador de carga para expor serviços.

1. Verifique se o cluster tem pelo menos um pod em execução e pronto com o rótulo app: public-app. O manifesto do serviço na próxima etapa seleciona pods com esse rótulo, mas não cria uma implantação.

   kubectl get pods -l app=public-app
   

2. Crie um manifesto do serviço chamado public-svc.yaml, que cria um serviço público do tipo LoadBalancer.

   apiVersion: v1
   kind: Service
   metadata:
     name: public-svc
   spec:
     type: LoadBalancer
     ports:
     - port: 80
     selector:
       app: public-app
   

Especificar o endereço IP do balanceador de carga

Se você quiser usar um endereço IP específico com o balanceador de carga, terá duas opções para especificar o endereço IP:

• Definir anotações de serviço (recomendado): use service.beta.kubernetes.io/azure-pip-name para especificar um recurso de IP público existente pelo nome. Essa anotação é a opção mais eficiente e ajuda a evitar possíveis limitações. Você também pode usar service.beta.kubernetes.io/azure-load-balancer-ipv4 para um endereço IPv4 e service.beta.kubernetes.io/azure-load-balancer-ipv6 para um endereço IPv6. Para requisitos de recurso de IP público, grupo de recursos e identidade, veja Usar um endereço IP público estático com o balanceador de carga do AKS.
• Adicione a propriedade LoadBalancerIP ao manifesto YAML do balanceador de carga: adicione a Service.Spec.LoadBalancerIP propriedade ao manifesto YAML do balanceador de carga. Este campo foi descontinuado em conformidade com o Kubernetes upstream e não oferece suporte a dual-stack. O uso atual permanece o mesmo e espera-se que os serviços existentes funcionem sem modificação.

Implante o manifesto do serviço de balanceamento de carga

1. Implante o manifesto do serviço público usando kubectl apply e especifique o nome do manifesto YAML.

   kubectl apply -f public-svc.yaml
   

   O Azure Load Balancer é configurado com um novo IP público que faz a frente do novo serviço. Como o Azure Load Balancer pode ter vários IPs de front-end, cada novo serviço implantado recebe um novo IP de front-end dedicado para ser acessado de forma exclusiva.

2. Confirme se o serviço foi criado e se o balanceador de carga está configurado usando o kubectl get service comando.

   kubectl get service public-svc
   

   Quando você exibe os detalhes do serviço, o endereço IP público criado para esse serviço no balanceador de carga é mostrado na coluna EXTERNAL-IP da saída. Pode levar alguns minutos para que o endereço IP mude de <pendente> para um endereço IP público real. A saída de exemplo a seguir mostra a criação bem-sucedida do serviço:

   NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
   default       public-svc    LoadBalancer   10.0.39.110    203.0.113.187   80:32068/TCP    52s
   

3. Obtenha informações mais detalhadas sobre seu serviço usando o kubectl describe service comando.

   kubectl describe service public-svc
   

   A saída de exemplo a seguir é uma versão condensada da saída após a execução de kubectl describe service. A Entrada do Azure Load Balancer mostra o endereço IP externo exposto pelo serviço. O IP mostra os endereços internos.

   Name:                        public-svc
   Namespace:                   default
   Labels:                      <none>
   Annotations:                 <none>
   Selector:                    app=public-app
   ...
   IP:                          10.0.39.110
   ...
   LoadBalancer Ingress:        203.0.113.187
   ...
   TargetPort:                  80/TCP
   NodePort:                    32068/TCP
   ...
   Session Affinity:            None
   External Traffic Policy:     Cluster
   ...
   

Próxima etapa