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

  • Artigo

O Azure Load Balancer opera na camada 4 do modelo OSI (Open Systems Interconnection) que suporta cenários de entrada e saída. Ele distribui fluxos de entrada que chegam ao front-end do balanceador de carga para as instâncias do pool de back-ends.

Um balanceador de carga público integrado ao AKS serve a dois propósitos:

  1. Para fornecer conexões de saída para os nós do cluster dentro da rede virtual AKS, traduzindo o endereço IP privado para um endereço IP público que faz parte do seu Pool de Saída.
  2. Para fornecer acesso a aplicativos por meio de serviços do tipo LoadBalancerKubernetes, permitindo que você dimensione 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 frontend. Os balanceadores de carga internos são usados para balancear a carga do tráfego dentro de uma rede virtual. Um front-end de 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 integração do balanceador de carga interno, consulte Usar um balanceador de carga interno no AKS.

Antes de começar

  • O Azure Load Balancer está disponível em duas SKUs: Basic e Standard. A SKU padrão é usada por padrão quando você cria um cluster AKS. O SKU padrão oferece acesso a funcionalidades adicionais, como um pool de back-end maior, pools de vários nós, zonas de disponibilidade e é seguro por padrão. É o SKU do balanceador de carga recomendado para AKS. Para obter mais informações sobre as SKUs Básica e Padrão, consulte Comparação de SKU do Balanceador de Carga do Azure.
  • Para obter uma lista completa das anotações suportadas para serviços Kubernetes com tipo LoadBalancer, consulte Anotações LoadBalancer.
  • Este artigo pressupõe que você tenha um cluster AKS com o Balanceador de Carga do Azure SKU Padrão . Se precisar de um cluster AKS, você pode criar 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 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 preferir usar seu próprio gateway, firewall ou proxy para fornecer conexão de saída, ignore a criação do pool de saída do balanceador de carga e respetivo 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 assume como padrão o tipo LoadBalancer.

Usar o balanceador de carga padrão público

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

Crie um manifesto de 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

Especifique 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

Adicionar a propriedade LoadBalancerIP ao manifesto YAML do balanceador de carga está substituindo o Kubernetes upstream. Embora o uso atual permaneça o mesmo e se espere que os serviços existentes funcionem sem modificações, é 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. Este campo está sendo preterido seguindo o Kubernetes upstream e não pode suportar pilha dupla. O uso atual permanece o mesmo e espera-se que os serviços existentes funcionem sem modificações.

Implantar o manifesto de serviço

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

kubectl apply -f public-svc.yaml

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

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ê visualiza 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 . 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, use o seguinte comando.

kubectl describe service public-svc

O exemplo de saída a seguir é uma versão condensada da saída depois de executar kubectl describe serviceo . LoadBalancer Ingress mostra o endereço IP externo exposto pelo seu serviç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 balanceador de carga padrão público

Você pode personalizar diferentes configurações para seu 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 balanceador de carga padrão, você pode:

  • Defina ou dimensione o número de IPs de saída gerenciados.
  • Traga seus próprios IPs de saída personalizados ou prefixo IP de saída.
  • Personalize o número de portas de saída alocadas para cada nó no cluster.
  • Configure a configuração de tempo limite para conexões ociosas.

Importante

Apenas uma opção de IP de saída (IPs gerenciados, traga seu próprio IP ou prefixo de IP) pode ser usada em um determinado momento.

Alterar o tipo de pool de entrada

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

Estão disponíveis dois tipos diferentes de membros de piscinas:

  • nodeIPConfiguration - Conjunto de Dimensionamento de Máquina Virtual herdado com base na configuração do tipo de associação ao pool
  • nodeIP - Tipo de associação baseada em IP

Requisitos

  • O cluster AKS deve ser a versão 1.23 ou mais recente.
  • O cluster AKS deve estar usando balanceadores de carga padrão e conjuntos de escala de máquina virtual.

Limitações

  • Os clusters que usam pools de back-end baseados em IP são limitados a 2500 nós.

Criar um novo cluster AKS com associação ao pool de entrada baseado em IP

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

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

Aviso

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

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

Dimensionar 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 do balanceamento de carga e das regras NAT de entrada:

IPs de frontend + 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 para o frontend. Os parâmetros fornecem 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 dimensionar o NAT de saída porque aliviam 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 reduzir os padrões propensos à exaustão do SNAT. Cada endereço IP fornecido por um frontend fornece 64k portas efêmeras para o balanceador de carga usar como portas SNAT.

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

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 recomendamos o uso do portal do Azure para fazer alterações nas regras de saída. Ao fazer essas alterações, você deve passar pelo cluster AKS e não diretamente no recurso do Balanceador de Carga.

As alterações de regra de saída feitas diretamente no recurso do Balanceador de Carga são removidas sempre que o cluster é reconciliado, como quando é interrompido, iniciado, atualizado ou dimensionado.

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

Para obter mais informações, consulte Regras de saída do Balanceador de Carga do Azure.

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 em 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 --load-balancer-managed-outbound-ip-count parâmetro e definindo-o para o valor desejado. O número padrão de IPs públicos de saída gerenciados é 1.

Forneça seus próprios IPs ou prefixos públicos de saída

Quando você usa um balanceador de carga SKU padrão , o cluster AKS cria automaticamente um IP público no grupo de recursos de infraestrutura gerenciado 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 requer ação do usuário diretamente no recurso IP público. Como alternativa, você pode atribuir seu próprio IP público personalizado ou prefixo IP público no momento da criação do cluster. Seus IPs personalizados também podem ser atualizados nas propriedades do balanceador de carga de um cluster existente.

Os requisitos para usar seu próprio IP público ou prefixo 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 como um "traga seu próprio IP personalizado", pois pode causar conflitos de gerenciamento.
  • Você deve garantir que a identidade do cluster AKS (Entidade de Serviço ou Identidade Gerenciada) tenha permissões para acessar o IP de saída, de acordo com a lista de permissões de IP público necessária.
  • Certifique-se de atender aos pré-requisitos e restrições necessários para configurar IPs de saída ou prefixos IP de saída.

Atualize o cluster com seu próprio IP público de saída

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

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

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

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

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

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

Atualize o cluster com seu próprio prefixo IP público de saída

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

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

O comando acima mostra a ID do prefixo 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>

Crie o cluster com seu próprio IP público ou prefixos

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

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

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

Use o az aks create comando com o load-balancer-outbound-ip-prefixes parâmetro para criar um novo 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 em seu cluster que podem estabelecer um grande número de conexões com um pequeno conjunto de destinos, como muitas instâncias de um aplicativo frontend se conectando a um banco de dados, você pode ter um cenário suscetível a encontrar esgotamento da porta SNAT. O esgotamento da porta SNAT acontece quando um aplicativo fica sem portas de saída para usar para estabelecer uma conexão com outro aplicativo ou host. Se você tiver um cenário suscetível ao esgotamento da porta SNAT, é altamente recomendável aumentar as portas de saída alocadas e os IPs de frontend 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 como , o 0que permite a atribuição automática de portas de saída com base no tamanho do pool de back-end ao criar um cluster. Por exemplo, se um cluster tiver 50 ou menos nós, 1024 portas serão alocadas para cada nó. À medida que o número de nós no cluster aumenta, menos portas estão disponíveis por nó.

Importante

Há um limite rígido de 1024 portas, independentemente de IPs front-end serem adicionados quando o tamanho do nó é menor ou igual a 50 (1-50).

Para mostrar o valor AllocatedOutboundPorts para o balanceador de carga de 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 automática de porta de saída 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 load-balancer-managed-outbound-ip-count, load-balancer-outbound-ipsou load-balancer-outbound-ip-prefixes. Antes de definir um valor específico ou aumentar um valor existente para portas de saída ou endereços IP de saída, você deve calcular o número apropriado de portas de saída e endereços IP. Para este cálculo, utilize a seguinte equação arredondada para o número 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, tenha em mente as seguintes informações:

  • O número de portas de saída por nó é fixo com base no valor definido.
  • O valor para 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ê deve considerar os nós que podem ser adicionados como parte das atualizações, incluindo a contagem de nós especificados por meio dos 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 usados e o cluster tiver 48 nós, cada nó terá 1024 portas disponíveis.
  • Se os valores padrão forem usados e o cluster for dimensionado de 48 a 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 poderá suportar 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 poderá suportar 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 poderá suportar 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 poderá suportar 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 portas de saída e IPs, verifique se você tem capacidade adicional de porta de saída para lidar com o aumento de nós durante as atualizações. É fundamental alocar portas excedentes suficientes para nós adicionais necessários para 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 maxSurge, multiplique as portas de saída por nó pelo valor maxSurge para determinar o número de portas necessárias. Por exemplo, se você calcular 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 * 4000 portas por nó = 8000 portas necessárias para aumento de nós durante as atualizações.
  • 100 nós * 4000 portas por nó = 400.000 portas necessárias para o cluster.
  • 7 IPs * 64000 portas por IP = 448.000 portas disponíveis para o cluster.

O exemplo acima mostra que o cluster tem uma capacidade excedente de 48.000 portas, o que é suficiente para lidar com as 8000 portas necessárias para o aumento do nó durante as atualizações.

Depois que os valores tiverem sido calculados e verificados, você poderá aplicá-los usando load-balancer-outbound-ports e load-balancer-managed-outbound-ip-count, load-balancer-outbound-ipsou 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 fecha, 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, ou application-layer keepalives) para atualizar um fluxo ocioso e redefinir esse tempo limite ocioso, TCP keepalives se necessário. Você pode configurar esse tempo limite seguindo o exemplo abaixo.

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

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

Importante

O AKS habilita o TCP Reset no modo inativo por padrão. Recomendamos que você mantenha essa configuração e a aproveite para um comportamento de aplicativo mais previsível em seus cenários.

O TCP RST só é enviado durante a ligação TCP no estado ESTABELECIDO. Leia mais sobre o assunto 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 de tempo limite padrão para um balanceador de carga SKU padrão usado fora do AKS é de 4 minutos. Um valor IdleTimeoutInMinutes que reflita com mais precisão sua carga de trabalho específica do AKS pode ajudar a diminuir a exaustão do SNAT causada pela vinculação de conexões que não estão mais sendo usadas.

Aviso

Alterar os valores de AllocatedOutboundPorts e IdleTimeoutInMinutes pode alterar significativamente o comportamento da regra de saída para seu balanceador de carga e não deve ser feito de ânimo leve. Verifique a seção Solução de problemas do SNAT e revise as regras de saída e as conexões de saída do Balanceador de Carga no Azure antes de atualizar esses valores para entender completamente 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 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 MY_EXTERNAL_IP_RANGE intervalo. Se você substituir MY_EXTERNAL_IP_RANGE pelo endereço IP da sub-rede interna, o tráfego será restrito apenas aos IPs internos do cluster. Se o tráfego estiver restrito a IPs internos do cluster, os clientes fora do cluster Kubernetes não poderão acessar o balanceador de carga.

Nota

  • O tráfego externo de entrada flui do balanceador de carga para a rede virtual do seu cluster AKS. A rede virtual tem um grupo de segurança de rede (NSG) que permite todo o tráfego de entrada do balanceador de carga. Este NSG usa uma etiqueta de serviço do tipo LoadBalancer para permitir o tráfego do balanceador de carga.
  • Pod CIDR deve ser adicionado a loadBalancerSourceRanges se houver Pods precisando acessar o IP LoadBalancer do serviço para clusters com 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 persiste o endereço IP do cliente na conexão com o pod. O IP de origem no pacote que é entregue ao pod torna-se o IP privado do nó. Para manter o endereço IP do cliente, você deve definir service.spec.externalTrafficPolicy como local na definição de 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 são suportadas para serviços Kubernetes com tipo LoadBalancer, e só se aplicam a fluxos de entrada .

Anotação valor Description
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 estar vinculado. Se não estiver definido, o padrão será a sub-rede configurada no arquivo de configuração da 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 estiver definida como uma cadeia de caracteres vazia, a entrada DNS no IP público não será usada.
service.beta.kubernetes.io/azure-shared-securityrule true ou false Especifique a exposição do 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 Aumentada 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 de 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 tags de serviço permitidas Especifique uma lista de tags de serviço permitidas separadas por vírgulas.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout Tempos limite de ociosidade TCP em minutos Especifique o tempo, em minutos, para que os tempos limite de inatividade 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 de inatividade.
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.

Personalizar a sonda de integridade do balanceador de carga

Anotação valor Description
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Intervalo da sonda de saúde
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe O número mínimo de respostas insalubres da sonda de saúde
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Caminho de solicitação da sonda de integridade
service.beta.kubernetes.io/port_{port}_no_lb_rule verdadeiro/falso {port} é o número da porta de serviço. Quando definido como true, nenhuma regra lb ou regra de teste de integridade para essa porta é gerada. O serviço de verificação do estado de saúde não deve ser exposto à Internet pública (por exemplo, o serviço de verificação do estado de saúde do istio/enviado)
service.beta.kubernetes.io/port_{port}_no_probe_rule verdadeiro/falso {port} é o número da porta de serviço. Quando definido como true, nenhuma regra de teste de integridade para essa porta é gerada.
service.beta.kubernetes.io/port_{port}_health-probe_protocol Protocolo de sonda de saúde {port} é o número da porta de serviço. Protocolo explícito para a sonda de integridade para a 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 o teste de integridade da porta de serviço {port}, substituindo o valor padrão.
service.beta.kubernetes.io/port_{port}_health-probe_interval Intervalo da sonda de saúde {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 insalubres da sonda de saúde {port} é o número da porta de serviço.
service.beta.kubernetes.io/port_{port}_health-probe_request-path Caminho de solicitação da sonda de integridade {port} é o número da porta de serviço.

Conforme documentado aqui, Tcp, Http e Https são três protocolos suportados pelo serviço de balanceador de carga.

Atualmente, o protocolo padrão da sonda 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. O teste de integridade consultará NodeHealthPort em vez do serviço de back-end real
  2. para serviços TCP de cluster, o TCP seria usado.
  3. para serviços UDP de cluster, sem testes de integridade.

Nota

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

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

  • Para clusters <=1,23, spec.ports.appProtocol só seria usado como protocolo de sonda quando service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path também estiver definido.
  • Para clusters >1.24, spec.ports.appProtocol seria usado como protocolo de teste e / seria usado como caminho de solicitação de teste 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 da solicitação seria ignorado ao usar TCP ou o spec.ports.appProtocol está vazio. Mais especificamente:

SKU do balanceador de carga externalTrafficPolicy spec.ports.Protocolo spec.ports.AppProtocol service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Protocolo de Sonda LB Caminho de solicitação de sonda LB
padrão local qualquer qualquer qualquer http /healthz
padrão cluster UDP qualquer qualquer nulo nulo
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) null(<=1,23) ou /(>=1,24)
padrão cluster tcp http/https /custom-path http/https /custom-path
padrão cluster tcp protocolo não suportado /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) null(<=1,23) ou /(>=1,24)
básico cluster tcp http /custom-path http /custom-path
básico cluster tcp protocolo não suportado /custom-path tcp nulo

Desde a v1.21, duas anotações service.beta.kubernetes.io/azure-load-balancer-health-probe-interval de serviço e load-balancer-health-probe-num-of-probe são introduzidas, que personalizam a configuração da sonda 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 sonda total deve ser inferior a 120 segundos.

Sonda de integridade do Balanceador de Carga Personalizado para porta

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

As anotações a seguir podem ser usadas para personalizar a configuração do teste por porta de serviço.

anotação específica da porta Anotação de teste global Utilização
service.beta.kubernetes.io/port_{port}_no_lb_rule N/D (sem equivalente a nível global) Se definido True, nenhuma regra LB e regras de teste serão geradas
service.beta.kubernetes.io/port_{port}_no_probe_rule N/D (sem equivalente a nível global) Se definido True, nenhuma regra de teste será gerada
service.beta.kubernetes.io/port_{port}_health-probe_protocol N/D (sem equivalente a nível global) Definir o protocolo de teste de integridade para esta porta de serviço (por exemplo, Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port N/D (sem equivalente a nível global) Define a porta da sonda de integridade para esta 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 de teste de integridade. Padrões para /
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 da sonda 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 as tentativas de sonda

Para o manifesto a seguir, a regra de teste para a porta httpsserver é diferente da regra para httpserver porque as anotações para 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

Neste manifesto, as portas https usam uma porta de nó diferente, uma verificação de prontidão HTTP na porta 10256 em /healthz(healthz endpoint of 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

Neste manifesto, as portas https usam um ponto de extremidade de teste de integridade diferente, uma verificação de preparaçã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

Solução de problemas do SNAT

Se você souber que está iniciando muitas conexões TCP ou UDP de saída para o mesmo endereço IP e porta de destino e observar conexões de saída falhando ou o suporte notificará que está esgotando as portas SNAT (portas efêmeras pré-alocadas usadas pelo PAT), você tem várias opções gerais de mitigação. Analise essas opções e decida o que é melhor para o seu cenário. É possível que um ou mais possam ajudar a gerenciar seu cenário. Para obter informações detalhadas, consulte o guia de solução de problemas de conexões de saída.

A causa raiz da exaustão do SNAT é freqüentemente um antipadrão de como a conectividade de saída é estabelecida, gerenciada ou os temporizadores configuráveis são alterados de seus valores padrão. Leia esta secção atentamente.

Passos

  1. Verifique se suas conexões permanecem ociosas por muito tempo e confie no tempo limite de ociosidade padrão para liberar essa porta. Nesse caso, o tempo limite padrão de 30 minutos pode precisar ser reduzido para o seu cenário.
  2. Investigue como seu aplicativo cria conectividade de saída (por exemplo, revisão de código ou captura de pacotes).
  3. Determine se essa atividade é um comportamento esperado ou se o aplicativo está se comportando incorretamente. Use métricas e logs no Azure Monitor para fundamentar suas descobertas. 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 da porta SNAT deve ser atenuado com mais endereços IP de saída + mais portas de saída alocadas.

Padrões de design

Aproveite a reutilização e o pool de conexões sempre que possível. Esses padrões ajudam a evitar problemas de esgotamento de recursos e resultam em um comportamento previsível. Primitivos para esses padrões podem ser encontrados em muitas bibliotecas e estruturas de desenvolvimento.

  • Solicitações atômicas (uma solicitação por conexão) geralmente não são uma boa escolha de design. Esses antipadrões limitam a escala, reduzem o desempenho e diminuem a confiabilidade. Em vez disso, reutilize conexões HTTP/S para reduzir o número de conexões e portas SNAT associadas. A escala do aplicativo aumenta e o desempenho melhora devido à redução de apertos de mão, sobrecarga e custo de operação criptográfica ao usar TLS.
  • Se você estiver usando DNS fora do cluster/personalizado ou servidores upstream personalizados no coreDNS, lembre-se de que o DNS pode introduzir muitos fluxos individuais no volume quando o cliente não estiver armazenando em cache o resultado dos resolvedores de DNS. Certifique-se de personalizar coreDNS primeiro em vez de usar servidores DNS personalizados e definir um bom valor de cache.
  • Os fluxos UDP (por exemplo, pesquisas de DNS) alocam portas SNAT durante o tempo limite de inatividade. Quanto maior o tempo limite de inatividade, maior a pressão nas portas SNAT. Use um tempo limite de inatividade curto (por exemplo, 4 minutos).
  • Use pools de conexões para moldar seu volume de conexão.
  • Nunca abandone silenciosamente um fluxo TCP e confie nos 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 desencadear falhas de aplicativos e esgotamento do SNAT.
  • Não altere os valores do temporizador TCP relacionado ao fechamento do sistema operacional sem conhecimento especializado do impacto. Enquanto a pilha TCP se recupera, o desempenho do aplicativo pode ser afetado negativamente quando os pontos de extremidade de uma conexão não correspondem às expectativas. Desejar alterar os temporizadores é geralmente um sinal de um problema de design subjacente. Reveja seguindo as recomendações.

Mudando de um balanceador de carga SKU básico para SKU padrão

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

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

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

Limitações

As limitações a seguir se aplicam quando você cria e gerencia clusters AKS que suportam um balanceador de carga com a SKU padrão :

  • É necessário, pelo menos, um prefixo IP ou IP público para permitir o tráfego de saída do cluster do AKS. O prefixo IP ou IP público é necessário para manter a conectividade entre o plano de controlo e os nós do agente e para manter a compatibilidade com versões anteriores do AKS. Você tem as seguintes opções para especificar IPs públicos ou prefixos IP com um balanceador de carga SKU padrão :
    • Disponibilizar os seus próprios IPs públicos.
    • Disponibilizar os seus próprios prefixos de IPs públicos.
    • Especifique um número até 100 para permitir que o cluster AKS crie muitos IPs públicos de SKU padrão no mesmo grupo de recursos que o cluster AKS. Esse grupo de recursos geralmente é nomeado com MC_ no início. O AKS atribui o IP público ao balanceador de carga SKU padrão . Por padrão, um IP público é criado automaticamente no mesmo grupo de recursos que o cluster AKS se nenhum IP público, prefixo IP público ou número de IPs for especificado. Também tem de permitir endereços públicos e evitar criar políticas do Azure que proíbam a criação de IPs.
  • Um IP público criado pelo AKS não pode ser reutilizado como um 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 quando cria um cluster do AKS. Não pode alterar o SKU do balanceador de carga depois de ter sido criado um cluster do AKS.
  • Você só pode usar um tipo de balanceador de carga SKU (Basic ou Standard) em um único cluster.
  • Os balanceadores de carga SKU padrão suportam apenas endereços IP SKU padrão .

Próximos passos

Para saber mais sobre os serviços do Kubernetes, consulte a documentação dos serviços do Kubernetes.

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