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

  • Artigo

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:

  1. Para fornecer conexões de saída para os nós de cluster dentro da 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.
  2. Para fornecer acesso a aplicativos por meio de serviços Kubernetes do tipo LoadBalancer, permitindo que você escalone facilmente seus aplicativos e crie serviços altamente disponíveis.

Um balanceador de carga interno (ou privado) é usado quando apenas IPs privados são permitidos como front-end. Os balanceadores de carga internos são usados para balancear a carga do tráfego dentro de uma rede virtual. Um front-end do balanceador de carga também pode ser acessado de uma rede local em um cenário híbrido.

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.

Antes de começar

  • O Azure Load Balancer está disponível em duas SKUs, Básica e Standard. Por padrão, o SKU Standard é usado quando você cria um cluster do AKS. O SKU Standard dá acesso a funcionalidades adicionais, como um pool de back-end maior, pools de vários nós e Zonas de Disponibilidade e é seguro por padrão. É a SKU do balanceador de carga recomendada para o AKS. Para obter mais informações sobre os SKUs Básico e Standard, confira Comparação de SKU 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, crie um usando a CLI do Azure, o Azure PowerShell ou o portal do Azure.
  • 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.

Importante

Se você preferir usar seu próprio gateway, firewall ou proxy para fornecer conexão de saída, você pode ignorar a criação do pool de saída do balanceador de carga e o respectivo IP de front-end usando o tipo de saída como UserDefinedRouting (UDR). O tipo de saída define o método de saída para um cluster e usa o tipo LoadBalancer como padrão.

Usar o Standard Load Balancer público

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.

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, há duas maneiras:

Importante

A adição da propriedade LoadBalancerIP ao manifesto YAML do balanceador de carga está substituindo o upstream Kubernetes a seguir. Embora o uso atual permaneça o mesmo e os serviços existentes funcionem sem modificação, é altamente recomendável definir anotações de serviço.

  • Definir anotações de serviço: use 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.
  • Adicione a propriedade LoadBalancerIP ao manifesto YAML do balanceador de carga: adicione a propriedade Service.Spec.LoadBalancerIP ao manifesto YAML do balanceador de carga. Esse campo está substituindo o upstream Kubernetes a seguir e não pode dar suporte a pilha dupla. O uso atual permanece o mesmo e espera-se que os serviços existentes funcionem sem modificação.

Implantar o manifesto do serviço

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 balanceador de carga do Azure é 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.

Confirme se o serviço foi criado e se o balanceador de carga está configurado usando o comando a seguir.

kubectl get service public-svc

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

Quando você vê os detalhes do serviço, o endereço IP público criado para ele no balanceador de carga é mostrado na coluna EXTERNAL-IP. Pode levar alguns minutos para que o endereço IP mude de <pendente> para um endereço IP público real.

Para obter informações mais detalhadas sobre seu serviço, utilize o seguinte 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:        52.156.88.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

Configurar o Standard Load Balancer público

Você pode personalizar configurações diferentes para o balanceador de carga público padrão no momento da criação do cluster ou atualizando o cluster. Essas opções de personalização permitem que você crie um balanceador de carga que atenda às suas necessidades de carga de trabalho. Com o Standard Load Balancer, você pode:

  • Defina ou escalone o número de IPs de saída gerenciados.
  • Traga seus IPs de saída ou prefixos de IP de saída personalizados.
  • Personalize o número de portas de saída alocadas para cada nó do cluster.
  • Defina a configuração de tempo limite para conexões ociosas.

Importante

Somente uma opção de IP de saída (IPs gerenciados, traga seu próprio IP ou prefixo de IP) pode ser usada por vez.

Alterar o tipo de pool de entrada

Os nós AKS podem ser referenciados nos pools de back-end do balanceador de carga pela sua configuração de IP (associação baseada em Conjuntos de Dimensionamento de Máquinas Virtuais do Azure) ou apenas pelo seu endereço IP. Utilizar a associação de pool de back-end baseada em endereço IP fornece maior eficiência ao atualizar serviços e provisionar balanceadores de carga, especialmente em contagens altas de nós. Agora há suporte para o provisionamento de novos clusters com pools de back-end baseados em IP e para a conversão de clusters existentes. Quando combinado com o Gateway da NAT ou com tipos de saída de roteamento definidos pelo usuário, o provisionamento de novos nós e serviços é mais eficiente.

Há dois tipos de associação de pool diferentes disponíveis:

  • nodeIPConfiguration - Herdado da configuração de IP dos Conjuntos de Dimensionamento de Máquinas Virtuais com base no tipo de associação ao pool
  • nodeIP – Tipo de associação baseada em IP

Requisitos

  • O cluster do AKS precisa ser a versão 1.23 ou superior.
  • Ele precisa usar balanceadores de carga padrão e conjuntos de dimensionamento de máquinas virtuais.

Criar um cluster do AKS com uma associação de pool de entrada baseada em IP

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Atualizar um cluster do AKS existente para usar a associação de pool de entrada baseada em IP

Aviso

Essa operação causa uma interrupção temporária do tráfego de serviços de entrada no cluster. O tempo de impacto aumenta com clusters maiores que possuem muitos nós.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Escalar o número de IPs públicos de saída gerenciados

O Azure Load Balancer fornece conectividade de entrada e saída de uma rede virtual. As regras de saída simplificam a configuração da conversão de endereços de rede para o balanceador de carga padrão público.

As regras de saída seguem a mesma sintaxe que regras NAT de entrada e balanceamento de carga:

IPs de front-end + parâmetros + pool de back-end

Uma regra de saída configura o NAT de saída para todas as máquinas virtuais identificadas pelo pool de back-end a serem convertidas no front-end. Os parâmetros oferecem mais controle sobre o algoritmo NAT de saída.

Embora você possa usar uma regra de saída com um único endereço IP público, as regras de saída são ótimas para escalonar a NAT de saída porque facilitam a carga de configuração. Você pode usar vários endereços IP para planejar cenários de grande escala e regras de saída para atenuar padrões propensos ao esgotamento de SNAT. Cada endereço IP fornecido por um front-end fornece 64 mil portas efêmeras para o balanceador de carga usar como portas SNAT.

Ao usar um balanceador de carga com SKU Standard e IPs públicos de saída gerenciados (que são criados por padrão), você pode escalonar o número de IPs públicos de saída gerenciados usando o parâmetro --load-balancer-managed-outbound-ip-count.

Use o comando a seguir para atualizar um cluster existente. Você também pode definir esse parâmetro para ter vários IPs públicos de saída gerenciados.

Importante

Não é recomendado usar o portal do Azure para fazer alterações de regra de saída. Ao fazer essas alterações, você deve fazê-las por meio do cluster do AKS e não diretamente no recurso do Load Balancer.

As alterações das regras de saída feitas diretamente no recurso do balanceador de carga são removidas sempre que o cluster é reconciliado, por exemplo, quando é interrompido, iniciado, atualizado ou colocado em escala.

Use a CLI do Azure, conforme mostrado nos exemplos. As alterações de regra de saída feitas usando os comandos az aks da CLI são permanentes no tempo de inatividade do cluster.

Para obter mais informações, confira Regras de saída do Azure Load Balancer.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

O exemplo acima define o número de IPs públicos de saída gerenciados como 2 para o cluster myAKSCluster no myResourceGroup.

No momento da criação do cluster, você também pode definir o número inicial de IPs públicos de saída gerenciados anexando o parâmetro --load-balancer-managed-outbound-ip-count e definindo-o como o valor desejado. O número padrão de IPs públicos de saída gerenciados é 1.

Fornecer seus prefixos ou IPs públicos de saída

Quando você usa um balanceador de carga com SKU Standard, o cluster do AKS cria automaticamente um IP público no grupo de recursos da infraestrutura gerenciada pelo AKS e o atribui ao pool de saída do balanceador de carga por padrão.

Um IP público criado pelo AKS é um recurso gerenciado pelo AKS, o que significa que o AKS gerencia o ciclo de vida desse IP público e não exige ação do usuário diretamente no recurso de IP público. Como alternativa, você pode atribuir seu IP público personalizado ou prefixo de IP público no momento da criação do cluster. Os IPs personalizados também podem ser atualizados nas propriedades do balanceador de carga em um cluster existente.

Os requisitos para usar seu prefixo ou IP público incluem:

  • Os usuários devem criar e possuir endereços IP públicos personalizados. Os endereços IP públicos gerenciados criados pelo AKS não podem ser reutilizados na modalidade "traga seu próprio IP personalizado", pois isso pode causar conflitos de gerenciamento.
  • A identidade do cluster do AKS (entidade de serviço ou identidade gerenciada) deve ter permissões para acessar o IP de saída, conforme a lista de permissões de IP público obrigatórias.
  • Verifique se você atende aos pré-requisitos e restrições necessários para configurar IPs de saída ou prefixos de IP de saída.

Atualizar o cluster com seu IP público de saída

Use o comando az network public-ip show para listar as IDs dos seus IPs públicos.

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

O comando acima mostra a ID para o IP público myPublicIP no grupo de recursos myResourceGroup.

Use o comando az aks update com o parâmetro load-balancer-outbound-ips para atualizar o cluster com os IPs públicos.

O exemplo a seguir usa o parâmetro load-balancer-outbound-ips com as IDs do comando anterior.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

Atualizar o cluster com seu prefixo de IP público de saída

Você também pode usar prefixos de IP público para saída com seu balanceador de carga de SKU Standard. O exemplo a seguir usa o comando az network public-ip prefix show para listar as IDs dos seus prefixos de IP público.

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

O comando acima mostra a ID para o prefixo de IP público myPublicIPPrefix no grupo de recursos myResourceGroup.

O exemplo a seguir usa o parâmetro load-balancer-outbound-ip-prefixes com as IDs do comando anterior.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Criar o cluster com seu IP público ou prefixos

Ao criar seu cluster, você pode trazer seus endereços IP ou prefixos de IP para saída a fim de dar suporte a cenários como a adição de pontos de extremidade de saída para uma lista de permitidos. Para definir seus próprios IPs públicos e prefixos de IP no momento da criação do cluster, acrescente os mesmos parâmetros mostrados no comando anterior.

Use o comando az aks create com o parâmetro load-balancer-outbound-ips para criar um cluster com seus próprios IPs públicos.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

Use o comando az aks create com o parâmetro load-balancer-outbound-ip-prefixes para criar um cluster com seus próprios prefixos IP públicos.

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Configurar as portas de saída alocadas

Importante

Se você tiver aplicativos no seu cluster que possam estabelecer um grande número de conexões com um pequeno conjunto de destinos, como muitas instâncias de um aplicativo front-end conectado a um banco de dados, poderá ter um cenário suscetível ao esgotamento de portas SNAT. O esgotamento de portas SNAT acontece quando um aplicativo é executado fora das portas de saída a serem usadas para estabelecer uma conexão com outro aplicativo ou host. Se você tem um cenário suscetível ao esgotamento de portas SNAT, é altamente recomendável que você aumente as portas de saída alocadas e os IPs de front-end de saída no balanceador de carga.

Para obter mais informações sobre SNAT, consulte Usar SNAT para conexões de saída.

Por padrão, o AKS define AllocatedOutboundPorts em seu balanceador de carga para 0, que permite a atribuição automática de porta de saída com base no tamanho do pool de back-end ao criar um cluster. Por exemplo, se um cluster tiver 50 nós ou menos, 1.024 portas serão alocadas para cada nó. À medida que o número de nós no cluster aumenta, menos portas ficam disponíveis por nó.

Importante

Há um limite rígido de 1024 portas, independentemente da adição de IPs de front-end quando o tamanho do nó for menor que ou igual a 50 (1-50).

Para mostrar o valor de AllocatedOutboundPorts para o balanceador de carga do cluster AKS, use az network lb outbound-rule list.

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

A saída de exemplo a seguir mostra que a atribuição de porta de saída automática com base no tamanho do pool de back-end está habilitada para o cluster.

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus

Para configurar um valor específico para AllocatedOutboundPorts e endereço IP de saída ao criar ou atualizar um cluster, use load-balancer-outbound-ports e um entre load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips e load-balancer-outbound-ip-prefixes. Antes de definir um valor específico ou aumentar um valor existente para as portas de saída ou endereços IP de saída, você precisa calcular o número apropriado de portas de saída e endereços IP. Use a seguinte equação para esse cálculo arredondado para o inteiro mais próximo: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

Ao calcular o número de portas de saída e IPs e definir os valores, lembre-se das seguintes informações:

  • O número de portas de saída por nó é fixado com base no valor definido.
  • O valor das portas de saída deve ser um múltiplo de 8.
  • Adicionar mais IPs não adiciona mais portas a nenhum nó, mas fornece capacidade para mais nós no cluster.
  • Você precisa levar em conta os nós que podem ser adicionados como parte de atualizações, incluindo a contagem de nós especificados através de valores maxSurge.

Os exemplos a seguir mostram como os valores definidos afetam o número de portas de saída e endereços IP:

  • Se os valores padrão forem utilizados e o cluster tiver 48 nós, cada nó terá 1024 portas disponíveis.
  • Se os valores padrão forem utilizados e o cluster for escalado de 48 para 52 nós, cada nó será atualizado de 1024 portas disponíveis para 512 portas disponíveis.
  • Se o número de portas de saída estiver definido como 1.000 e a contagem de IP de saída estiver definida como 2, o cluster pode dar suporte a um máximo de 128 nós: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
  • Se o número de portas de saída estiver definido como 1.000 e a contagem de IP de saída estiver definida como 7, o cluster pode dar suporte a um máximo de 448 nós: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
  • Se o número de portas de saída estiver definido como 4.000 e a contagem de IP de saída estiver definida como 2, o cluster pode dar suporte a um máximo de 32 nós: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
  • Se o número de portas de saída estiver definido como 4.000 e a contagem de IP de saída estiver definida como 7, o cluster pode dar suporte a um máximo de 112 nós: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

Importante

Depois de calcular o número de IPs e portas de saída, verifique se você tem capacidade de porta de saída adicional para lidar com o aumento de nós durante as atualizações. É essencial alocar portas excedentes suficientes para os nós adicionais necessários para a atualização e outras operações. O AKS assume como padrão um nó de buffer para operações de atualização. Se estiver usando valores de maxSurge, multiplique as portas de saída por nó pelo valor de maxSurge para determinar o número de portas exigido. Por exemplo, se você tiver calculado que precisa de 4000 portas por nó com 7 endereços IP em um cluster com um máximo de 100 nós e um aumento máximo de 2:

  • 2 nós de aumento * 4.000 portas por nó = 8.000 portas necessárias para o aumento de nó durante atualizações.
  • 100 nós * 4.000 portas por nó = 400.000 portas necessárias para o cluster.
  • 7 IPs * 64.000 portas por IP = 448.000 portas disponíveis para o cluster.

O exemplo acima mostra que o cluster tem uma capacidade de 48.000 portas excedentes, o que é suficiente para dar conta das 8.000 portas exigidas para o aumento de nó durante atualizações.

Depois que os valores tiverem sido calculados e verificados, você poderá aplicar esses valores usando load-balancer-outbound-ports e um entre load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips e load-balancer-outbound-ip-prefixes ao criar ou atualizar um cluster.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

Configurar o tempo limite ocioso do balanceador de carga

Quando os recursos da porta SNAT estão esgotados, os fluxos de saída falham até que os fluxos existentes liberem as portas SNAT. O balanceador de carga recupera portas SNAT quando o fluxo é fechado e o balanceador de carga configurado pelo AKS usa um tempo limite ocioso de 30 minutos para recuperar portas SNAT de fluxos ociosos.

Você também pode usar o transporte (por exemplo, TCP keepalives ou application-layer keepalives) para atualizar um fluxo ocioso e redefinir esse tempo limite ocioso, se necessário. Configure o tempo limite seguindo este exemplo.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

Se você espera ter várias conexões curtas e nenhuma conexão longa e pode ter longos períodos de ociosidade, como ao usar kubectl proxy ou kubectl port-forward, considere usar um valor de tempo limite baixo, como 4 minutos. Ao usar keep alives TCP, é suficiente habilitá-los em um lado da conexão. Por exemplo, é suficiente habilitá-los no lado do servidor apenas para redefinir o temporizador de ociosidade do fluxo. Não é necessário que ambos os lados iniciem keepalives TCP. Conceitos semelhantes existem para a camada de aplicativo, incluindo as configurações de cliente-servidor de banco de dados. Verifique o lado do servidor quanto às opções existentes para keep alives específicos do aplicativo.

Importante

O AKS habilita a Redefinição de TCP em ociosidade por padrão. É recomendado manter essa configuração e utilizá-la para um comportamento de aplicativo mais previsível em seus cenários.

O RST TCP só é enviado durante a conexão TCP no estado estabelecido. Leia mais sobre isso aqui.

Ao definir IdleTimeoutInMinutes para um valor diferente do padrão de 30 minutos, considere por quanto tempo suas cargas de trabalho precisam de uma conexão de saída. Considere também que o valor do tempo limite padrão para um balanceador de carga de SKU Standard usado fora do AKS é de 4 minutos. Um valor IdleTimeoutInMinutes que reflete com mais precisão sua carga de trabalho do AKS específica pode ajudar a diminuir o esgotamento de SNAT causado pela associação de conexões que não são mais usadas.

Aviso

A alteração dos valores para AllocatedOutboundPorts e IdleTimeoutInMinutes pode alterar significativamente o comportamento da regra de saída para seu balanceador de carga e não deve ser feito sem cuidadosa consideração. Confira a seção Solução de problemas de SNAT e analise as regras de saída do balanceador de carga e as conexões de saída no Azure antes de atualizar esses valores para entender totalmente o impacto de suas alterações.

Restringir o tráfego de entrada a intervalos de IP específicos

O manifesto a seguir usa loadBalancerSourceRanges para especificar um novo intervalo de IP para o tráfego externo de entrada.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

Este exemplo atualiza a regra para permitir o tráfego externo de entrada somente do intervalo MY_EXTERNAL_IP_RANGE. Se você substituir MY_EXTERNAL_IP_RANGE pelo endereço IP da sub-rede interna, o tráfego será restrito somente a IPs internos do cluster. Se o tráfego for restrito aos IPs internos do cluster, os clientes fora do cluster do Kubernetes não poderão acessar o balanceador de carga.

Observação

  • O tráfego externo de entrada flui do balanceador de carga para a rede virtual do cluster do AKS. A rede virtual tem um NSG (grupo de segurança de rede) que permite todo o tráfego de entrada do balanceador de carga. Esse NSG usa uma marca de serviço do tipo LoadBalancer para permitir o tráfego do balanceador de carga.
  • O CIDR do Pod deverá ser adicionado a loadBalancerSourceRanges se houver Pods que precisem acessar o IP do LoadBalancer do serviço para clusters com a versão v1.25 ou superior.

Manter o IP do cliente em conexões de entrada

Por padrão, um serviço do tipo LoadBalancerno Kubernetes e no AKS não mantém o endereço IP do cliente na conexão com o pod. O IP de origem no pacote que é entregue ao pod se torna o IP privado do nó. Para manter o endereço IP do cliente, você precisa definir service.spec.externalTrafficPolicy como local na definição do serviço. O manifesto a seguir mostra um exemplo.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Personalizações via Anotações do Kubernetes

As anotações a seguir têm suporte para serviços do Kubernetes com o tipo LoadBalancer e se aplicam apenas a fluxos de ENTRADA.

Annotation Valor Descrição
service.beta.kubernetes.io/azure-load-balancer-internal true ou false Especifique se o balanceador de carga deve ser interno. Se não estiver definido, o padrão será público.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet Nome da sub-rede Especifique a qual sub-rede o balanceador de carga interno deve ser associado. Se não estiver definido, o padrão será a sub-rede configurada no arquivo de configuração de nuvem.
service.beta.kubernetes.io/azure-dns-label-name Nome do rótulo DNS em IPs públicos Especifique o nome do rótulo DNS para o serviço público. Se for definido como uma cadeia de caracteres vazia, a entrada do DNS no IP público não será utilizada.
service.beta.kubernetes.io/azure-shared-securityrule true ou false Especifique expor o serviço por meio de uma regra de segurança do Azure potencialmente compartilhada para aumentar a exposição do serviço, utilizando as Regras de Segurança Aumentadas do Azure em grupos de Segurança de Rede.
service.beta.kubernetes.io/azure-load-balancer-resource-group Nome do grupo de recursos Especifique o grupo de recursos dos IPs públicos do balanceador de carga que não estão no mesmo grupo de recursos que a infraestrutura de cluster (grupo de recursos de nó).
service.beta.kubernetes.io/azure-allowed-service-tags Lista de marcas de serviço permitidas Especifique uma lista de marcas de serviço permitidas separadas por vírgulas.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout Tempos limite ociosos de TCP em minutos Especifique o tempo, em minutos, para que os tempos limite ociosos da conexão TCP ocorram no balanceador de carga. O valor padrão e mínimo é 4. O valor máximo é 30. O valor deve ser um inteiro.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true ou false Especifique se o balanceador de carga deve desabilitar a redefinição de TCP no tempo limite ocioso.
service.beta.kubernetes.io/azure-load-balancer-ipv4 Endereço IPv4 Especifique o endereço IPv4 a ser atribuído ao balanceador de carga.
service.beta.kubernetes.io/azure-load-balancer-ipv6 Endereço IPv6 Especifique o endereço IPv6 a ser atribuído ao balanceador de carga.

Personalize a investigação de integridade do balanceador de carga

Annotation Valor Descrição
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Intervalo de investigação de integridade
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe O número mínimo de respostas não íntegras da investigação de integridade
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Caminho para solicitação da investigação de integridade
service.beta.kubernetes.io/port_{port}_no_lb_rule true/false {port} é o número da porta de serviço. Quando definido como true, nenhuma regra lb ou regra de investigação de integridade para essa porta é gerada. O serviço de verificação de integridade não deve ser exposto à Internet pública(por exemplo, serviço de verificação de integridade istio/envoy)
service.beta.kubernetes.io/port_{port}_no_probe_rule true/false {port} é o número da porta de serviço. Quando definido como true, nenhuma regra de investigação de integridade para essa porta é gerada.
service.beta.kubernetes.io/port_{port}_health-probe_protocol Protocolo de investigação de integridade {port} é o número da porta de serviço. Protocolo explícito para a investigação de integridade da porta de serviço {port}, substituindo port.appProtocol, se definido.
service.beta.kubernetes.io/port_{port}_health-probe_port número da porta ou nome da porta no manifesto do serviço {port} é o número da porta de serviço. Porta explícita para a investigação de integridade da porta de serviço {port}, substituindo o valor padrão.
service.beta.kubernetes.io/port_{port}_health-probe_interval Intervalo de investigação de integridade {port} é o número da porta de serviço.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe O número mínimo de respostas não íntegras da investigação de integridade {port} é o número da porta de serviço.
service.beta.kubernetes.io/port_{port}_health-probe_request-path Caminho para solicitação da investigação de integridade {port} é o número da porta de serviço.

Conforme documentado aqui, Tcp, Http e Https são três protocolos compatíveis com o serviço de balanceador de carga.

Atualmente, o protocolo padrão da investigação de integridade varia entre serviços com diferentes protocolos de transporte, protocolos de aplicativo, anotações e políticas de tráfego externo.

  1. para serviços locais, HTTP e /healthz seriam usados. A investigação de integridade consultará NodeHealthPort em vez do atual serviço de back-end
  2. para serviços TCP de cluster, o TCP seria usado.
  3. para serviços UDP de cluster, não há investigações de integridade.

Observação

Para serviços locais com integração PLS e protocolo proxy PLS habilitado, a investigação de integridade padrão HTTP+/healthz não funciona. Portanto, a investigação de integridade pode ser personalizada da mesma forma que os serviços de cluster para dar suporte a esse cenário.

Desde a v1.20, a anotação de serviço service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path está introduzida para determinar o comportamento da investigação de integridade.

  • Para clusters <=1.23, spec.ports.appProtocol só seriam usados como protocolo de investigação quando service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path também estiver definido.
  • Para clusters >1.24, spec.ports.appProtocol seriam usados como protocolo de investigação e / seriam usados como caminho de solicitação de investigação padrão (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path poderia ser usado para alterar para um caminho de solicitação diferente).

Observe que o caminho de solicitação seria ignorado ao usar TCP ou se o spec.ports.appProtocol estiver vazio. Mais especificamente:

loadbalancer sku externalTrafficPolicy spec.ports.Protocol spec.ports.AppProtocol service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Protocolo de Investigação LB Caminho de Solicitação de Investigação LB
padrão local qualquer qualquer qualquer http /healthz
padrão cluster udp qualquer qualquer null null
padrão cluster TCP (ignorado) TCP nulo
padrão cluster TCP TCP (ignorado) TCP nulo
padrão cluster TCP http/https TCP(<=1.23) ou http/https(>=1.24) nulo(<=1.23) ou /(>=1.24)
padrão cluster TCP http/https /custom-path http/https /custom-path
padrão cluster TCP protocolo sem suporte /custom-path TCP nulo
básico local qualquer qualquer qualquer http /healthz
básico cluster TCP (ignorado) TCP nulo
básico cluster TCP TCP (ignorado) TCP nulo
básico cluster TCP http TCP(<=1.23) ou http/https(>=1.24) nulo(<=1.23) ou /(>=1.24)
básico cluster TCP http /custom-path http /custom-path
básico cluster TCP protocolo sem suporte /custom-path TCP nulo

Desde a v1.21, duas anotações de serviço service.beta.kubernetes.io/azure-load-balancer-health-probe-interval e load-balancer-health-probe-num-of-probe estão introduzidas, que personalizam a configuração da investigação de integridade. Se service.beta.kubernetes.io/azure-load-balancer-health-probe-interval não estiver definido, o Valor padrão de 5 será aplicado. Se load-balancer-health-probe-num-of-probe não estiver definido, o Valor padrão de 2 será aplicado. E a investigação total deve ser inferior a 120 segundos.

Investigação de integridade do Balanceador de Carga Personalizado para a porta

Portas diferentes em um serviço podem exigir diferentes configurações de investigação de integridade. Isso pode ser devido ao design do serviço (como um único ponto de extremidade de integridade que controla várias portas) ou aos recursos do Kubernetes, como o MixedProtocolLBService.

As seguintes anotações podem ser usadas para personalizar a configuração da investigação por porta de serviço.

anotação específica da porta anotação da investigação global Uso
service.beta.kubernetes.io/port_{port}_no_lb_rule N/A (não há equivalente a nível global) se definido como true, nenhuma regra de lb e regra de investigação será gerada
service.beta.kubernetes.io/port_{port}_no_probe_rule N/A (não há equivalente a nível global) se definido como true, nenhuma regra de investigação será gerada
service.beta.kubernetes.io/port_{port}_health-probe_protocol N/A (não há equivalente a nível global) Define o protocolo de investigação de integridade para essa porta de serviço (por exemplo, Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port N/A (não há equivalente a nível global) Define a porta de investigação de integridade para essa porta de serviço (por exemplo, 15021)
service.beta.kubernetes.io/port_{port}_health-probe_request-path service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Para Http ou Https, define o caminho da solicitação da investigação de integridade. O padrão é /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Número de falhas consecutivas de investigação antes que a porta seja considerada não íntegra
service.beta.kubernetes.io/port_{port}_health-probe_interval service.beta.kubernetes.io/azure-load-balancer-health-probe-interval A quantidade de tempo entre tentativas de investigação

Para o seguinte manifesto, a regra de investigação para a porta httpsserver é diferente para httpserver porque as anotações pora a porta httpsserver são especificadas.

apiVersion: v1
kind: Service
metadata:
  name: appservice
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
    service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: httpserver
      protocol: TCP
      port: 80
      targetPort: 30102
    - name: httpsserver
      protocol: TCP
      appProtocol: HTTPS
      port: 443
      targetPort: 30104

Nesse manifesto, as portas https usam uma porta de nó diferente, uma verificação de prontidão HTTP na porta 10256 em /healthz(ponto de extremidade healthz do kube-proxy).

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "10256"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      nodePort: 30104
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

Nesse manifesto, as portas https usam um diferente ponto de extremidade da investigação de integridade, uma verificação de prontidão HTTP na porta 30000 em /healthz/ready.

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "30000"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

Solucionar problemas de SNAT

Se você sabe que está iniciando muitas conexões TCP ou UDP de saída para o mesmo endereço e porta IP de destino, e observa conexões de saída com falha ou o suporte informa que as portas SNAT (portas efêmeras pré-alocadas usadas pela PAT) estão se esgotando, você tem várias opções gerais para mitigação. Examine essas opções e decida qual é a melhor para seu cenário. É possível que uma ou mais possam ajudar a gerenciar o seu cenário. Para informações detalhadas, confira o Guia de solução de problemas de conexões de saída.

A causa raiz do esgotamento de SNAT é frequentemente um antipadrão para a forma como a conectividade de saída é estabelecida e gerenciada, ou como os temporizadores configuráveis têm os valores padrão alterados. Revise esta seção com cuidado.

Etapas

  1. Verifique se suas conexões permanecem ociosas por muito tempo e se baseiam no tempo limite ocioso padrão para liberar a porta. Se for esse o caso, poderá ser preciso reduzir o tempo limite padrão de 30 minutos para seu cenário.
  2. Investigue como o aplicativo cria a conectividade de saída (por exemplo, revisão de código ou captura de pacote).
  3. Determinar se essa atividade é um comportamento esperado ou se o aplicativo está tendo um comportamento inadequado. Use métricas e logs no Azure Monitor para substanciar suas conclusões. Por exemplo, use a categoria "Falha" para a métrica de conexões SNAT.
  4. Avalie se os padrões apropriados são seguidos.
  5. Avalie se o esgotamento de porta SNAT deve ser mitigado com mais endereços IP de saída e mais portas de saída alocadas.

Padrões de design

Aproveite a reutilização de conexão e o pool de conexões quando possível. Esses padrões ajudam a evitar problemas de esgotamento de recursos e resultam em um comportamento previsível. Os primitivos desses padrões podem ser encontrados em muitas bibliotecas e estruturas de desenvolvimento.

  • Geralmente, solicitações atômicas (uma solicitação por conexão) não são uma boa opção de design. Esses antipadrões limitam a escala, reduzem o desempenho e diminuem a confiabilidade. Em vez disso, reutilize as conexões HTTP/S para reduzir os números de conexões e as portas SNAT associadas. A escalada do aplicativo aumenta e o desempenho melhora devido à redução dos handshakes, da sobrecarga e do custo da operação criptográfica ao utilizar o TLS.
  • Se você está usando um DNS personalizado/fora do cluster ou servidores upstream personalizados no coreDNS, tenha em mente que o DNS pode introduzir muitos fluxos individuais com volume quando o cliente não está armazenando em cache o resultado do resolvedor de DNS. Certifique-se de personalizar o coreDNS primeiro em vez de usar servidores DNS personalizados e de definir um bom valor de cache.
  • Os fluxos UDP (por exemplo, pesquisas de DNS) alocam portas SNAT durante o tempo limite ocioso. Quanto maior o tempo limite de ociosidade, maior a pressão em portas SNAT. Use o tempo limite ocioso curto (por exemplo, 4 minutos).
  • Use pools de conexão para formatar o volume de conexão.
  • Nunca abandone silenciosamente um fluxo de TCP nem dependa de temporizadores TCP para limpar o fluxo. Se você não permitir que o TCP feche explicitamente a conexão, o estado permanecerá alocado em sistemas intermediários e pontos de extremidade, e isso tornará as portas SNAT indisponíveis para outras conexões. Esse padrão pode disparar falhas de aplicativo e esgotamento de SNAT.
  • Não altere os valores de temporizador relacionados ao fechamento de TCP no nível do sistema operacional sem um conhecimento especializado do impacto. Enquanto a pilha TCP se recupera, o desempenho do seu aplicativo pode ser afetado negativamente quando os pontos de extremidade de uma conexão têm expectativas incompatíveis. O desejo de alterar temporizadores geralmente é um sinal de um problema de design subjacente. Examine as seguintes recomendações.

Migrar de um balanceador de carga de SKU Básico para o SKU Standard

Se você tiver um cluster existente com o balanceador de carga de SKU Básico, haverá diferenças comportamentais importantes a serem observadas ao migrar para o balanceador de carga de SKU Standard.

Por exemplo, fazer implantações azuis/verdes para migrar clusters é uma prática comum considerando que o tipo load-balancer-sku de um cluster só pode ser definido no momento da criação do cluster. No entanto, balanceadores de carga de SKU Básico usam os Endereços IP do SKU Básico que não são compatíveis com os balanceadores de carga de SKU Standard. Os balanceadores de carga de SKU Standard requerem endereços IP de SKU Standard. Ao migrar clusters para atualizar SKUs do balanceador de carga, é necessário um novo endereço IP com um SKU de endereço IP compatível.

Para ver mais considerações sobre como migrar clusters, acesse nossa documentação sobre considerações sobre migração.

Limitações

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:

  • 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 com um balanceador de carga de 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 na modalidade traga seu próprio endereço IP público personalizado. Os usuários devem criar e gerenciar todos os endereços IP personalizados.
  • Definir o SKU do balanceador de carga só pode ser feito ao criar um cluster do AKS. Você não poderá alterar o SKU do balanceador de carga depois que um cluster do AKS for criado.
  • Você só pode usar um tipo de SKU do balanceador de carga (Básico ou Standard) em um cluster.
  • Os balanceadores de carga de SKU Standard dão suporte apenas a endereços IP de SKU Standard.

Próximas etapas

Para saber mais sobre os serviços do Kubernetes, confira a Documentação dos serviços do Kubernetes.

Para saber mais sobre como usar o balanceador de carga interno para tráfego de entrada, confira a documentação do balanceador de carga interno do AKS.