Usar um Standard Load Balancer no AKS (Serviço de Kubernetes do Azure)

O Azure Load Balancer está na L4 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 Load Balancer público tem duas finalidades:

  1. Fornecer conexões de saída para os nós de cluster dentro da rede virtual do AKS. Ele faz isso convertendo o endereço IP privado dos nós em um endereço IP público que faz parte de seu Pool de saída.
  2. Fornecer acesso a aplicativos por meio dos serviços do Kubernetes do tipo LoadBalancer. Com ele, você pode facilmente escalar aplicativos e criar serviços com alta disponibilidade.

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 documento aborda a integração com o Load Balancer público. Para saber mais sobre a integração do Load Balancer interno, confira a Documentação do Load Balancer interno do AKS.

Antes de começar

O Balanceador de carga do Azure está disponível em dois SKUs - Básico e Padrão. 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. É o SKU do Load Balancer recomendado para o AKS.

Para obter mais informações sobre os SKUs Básico e Standard, confira Comparação de SKU do Azure Load Balancer.

Este artigo pressupõe que você tenha um cluster do AKS com o SKU Standard do Azure Load Balancer e descreve como usar e configurar alguns dos recursos e funcionalidades do balanceador de carga. Se você precisar de um cluster do AKS, veja o início rápido do AKS usando a CLI do Azure, o Azure PowerShell ou o portal do Azure.

Importante

Se você prefere não usar o Azure Load Balancer para fornecer conexão de saída e, em vez disso, tem seu gateway, firewall ou proxy para essa finalidade, ignore 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 seu valor padrão é o balanceador de carga.

Usar o Standard Load Balancer público

Após a criação de um cluster do AKS com o tipo de saída Load Balancer (padrão), o cluster estará pronto para usar o balanceador de carga para expor serviços também.

Para isso, você pode criar um serviço público do tipo LoadBalancer, conforme mostrado no exemplo a seguir. Comece criando um manifesto do serviço chamado public-svc.yaml:

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

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 será configurado com um novo IP público que será o front-end do novo serviço. Como o Azure Load Balancer pode ter vários IPs de front-end, cada novo serviço implantado terá um novo IP de front-end dedicado para ser acessado de maneira exclusiva.

Confirme se o serviço foi criado e se o balanceador de carga está configurado executando, por exemplo:

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 um ou dois minutos para o endereço IP ser alterado de <pendente> para um endereço IP público real, conforme mostrado no exemplo a seguir.

Configurar o Standard Load Balancer público

Ao usar o Load Balancer público com o SKU Standard, há um conjunto de opções que podem ser personalizadas no momento da criação ou com a atualização do cluster. Essas opções permitem que você personalize o Load Balancer para atender às necessidades de suas cargas de trabalho e devem ser analisadas. Com o Standard Load Balancer, você pode:

  • Definir ou escalar o número de IPs de saída gerenciados
  • Trazer seus IPs de saída ou prefixos de IP de saída personalizados
  • Personalizar o número de portas de saída alocadas a cada nó do cluster
  • Definir 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.

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

O Azure Load Balancer fornece conectividade de saída de uma rede virtual além da entrada. Regras de saída simplificam a configuração da conversão de endereços de rede de saída do Standard Load Balancer público.

Como todas as regras do Load Balancer, regras de saída seguem a mesma sintaxe familiar 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 fornecem controle refinado adicional sobre o algoritmo NAT de saída.

Embora uma regra de saída possa ser usada com apenas um único endereço IP público, regras de saída aliviam a carga de configuração para o dimensionamento de NAT de saída. Você pode usar vários endereços IP para planejar cenários de grande escala e pode usar regras de saída para atenuar padrões propensos à exaustão de SNAT. Cada endereço IP adicional fornecido por um front-end fornece 64 mil portas efêmeras para o Load Balancer 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 escalar o número de IPs públicos de saída gerenciados usando o parâmetro load-balancer-managed-ip-count.

Para atualizar um cluster existente, execute o comando a seguir. Esse parâmetro também pode ser definido no momento de criação do cluster para ter vários IPs públicos de saída gerenciados.

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.

Você também pode usar o parâmetro load-balancer-managed-ip-count para definir o número inicial de IPs públicos de saída gerenciados ao criar o cluster acrescentando o parâmetro --load-balancer-managed-outbound-ip-count e configurando-o com 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, por padrão, 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.

Um IP público criado pelo AKS é considerado um recurso gerenciado pelo AKS. Isso significa que o ciclo de vida desse IP público deve ser gerenciado pelo AKS e que não é necessária nenhuma 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.

Requisitos para usar seu prefixo ou IP público:

  • Endereços IP públicos personalizados devem ser criados pelo usuário e devem pertencer a ele. 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. De acordo com a lista de permissões de IP público necessárias.
  • Verifique se você se encaixa nos pré-requisitos e nas 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 seguinte exemplo 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

Talvez você queira trazer seus endereços IP ou prefixos de IP para saída no momento da criação do cluster para dar suporte a cenários como a adição de pontos de extremidade de saída a uma lista de permitidos. Acrescente os mesmos parâmetros mostrados acima à etapa de criação do cluster para definir seus IPs públicos e prefixos de IP no início do ciclo de vida de um cluster.

Use o comando az aks create com o parâmetro load-balancer-outbound-ips para criar um cluster com seus IPs públicos no início.

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 prefixos de IP públicos no início.

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 cluster que possam estabelecer um grande número de conexões com um pequeno conjunto de destinos, por exemplo, muitas instâncias de um aplicativo front-end conectando-se a um banco de dados, você poderá ter um cenário muito suscetível a encontrar 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 em que pode encontrar 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 evitar o esgotamento de portas SNAT. Confira abaixo informações sobre como calcular corretamente as portas de saída e os valores de saída do IP de front-end.

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ó. Para mostrar o valor de AllocatedOutboundPorts para o balanceador de carga do cluster AKS, use az network lb outbound-rule list. Por exemplo:

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 seguinte saída de exemplo 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 e o endereço IP de saída, você precisa calcular o número apropriado de portas de saída e o endereço 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:

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

Os seguintes exemplos mostram como o número de portas de saída e endereços IP são afetados pelos valores definidos:

  • Se os valores padrão são usados e o cluster tem 48 nós, cada nó terá 1.024 portas disponíveis.
  • Se os valores padrão são usados e o cluster é dimensionado de 48 a 52 nós, cada nó será atualizado de 1.024 portas disponíveis para 512 portas disponíveis.
  • Se as portas de saída estão definidas como 1.000 e a contagem de IP de saída está 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 as portas de saída estão definidas como 1.000 e a contagem de IP de saída está 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 as portas de saída estão definidas como 4.000 e a contagem de IP de saída está 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 as portas de saída estão definidas como 4.000 e a contagem de IP de saída está 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 precisava de 4.000 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. Por exemplo:

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 Load Balancer 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 e não é necessário que os dois lados iniciem keep alives 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 no modo ocioso por padrão e recomenda que você mantenha essa configuração ativada e utilize-a 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 como um valor diferente do padrão de 30 minutos, considere por quanto tempo suas cargas de trabalho precisarão 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

Alterar os valores de AllocatedOutboundPorts e IdleTimeoutInMinutes pode alterar significativamente o comportamento da regra de saída do balanceador de carga e é algo que não deve ser feito por qualquer motivo, sem compreender as compensações e os padrões de conexão do aplicativo. Confira a seção sobre como solucionar problemas de SNAT abaixo e examine as regras de saída do Load Balancer e as conexões de saída no Azure antes de atualizar esses valores para entender totalmente o impacto das alterações.

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

O seguinte manifesto 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 a 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.

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 será 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 seguinte manifesto 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 adicionais via Anotações do Kubernetes

Veja uma lista de anotações com suporte para serviços do Kubernetes do tipo LoadBalancer. Estas anotações se aplicam somente 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 for definido, usará público como padrão.
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 for definido, usará a sub-rede configurada no arquivo de configuração de nuvem como padrão.
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 DNS no IP público não será usada.
service.beta.kubernetes.io/azure-shared-securityrule true ou false Especifique que o serviço deve ser exposto usando uma regra de segurança do Azure que pode ser compartilhada com outro serviço, trocando a especificidade das regras por um aumento no número de serviços que podem ser expostos. Esta anotação depende do recurso de Regras de segurança aumentadas do Azure dos 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. Deve ser um inteiro.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true Desabilite enableTcpReset para SLB. Preterido no Kubernetes 1.18 e removido na versão 1.20.

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 você observa conexões de saída com falha ou é informado pelo suporte 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. Avalie essas opções e decida o que está disponível e melhor para o seu cenário. É possível que uma ou mais possam ajudar a gerenciar esse cenário. Para obter informações detalhadas, confira o Guia de solução de problemas de conexões de saída.

Frequentemente, a causa raiz do esgotamento de SNAT é um antipadrão para a forma como a conectividade de saída é estabelecida, 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, o tempo limite padrão de 30 minutos poderá precisar ser reduzido para seu cenário.
  2. Investigar como o aplicativo está criando 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. Use a categoria "Falha" para obter a métrica de Conexões SNAT, por exemplo.
  4. Avalie se os padrões apropriados são seguidos.
  5. Avalie se o esgotamento de porta SNAT deve ser mitigado com endereços IP de saída adicionais + portas de saída alocadas adicionais.

Padrões de design

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

  • Solicitações atômicas (uma solicitação por conexão) não são uma boa opção de design. Esses limites de padrão 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 escala do aplicativo aumentará e o desempenho melhorará devido à redução de handshakes, de sobrecarga e do custo da operação de criptografia ao usar 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. Personalize o coreDNS primeiro em vez de usar servidores DNS personalizados e defina um bom valor de cache.
  • Os fluxos UDP (por exemplo, pesquisas de DNS) alocam portas SNAT para a duração do tempo limite de ociosidade. Quanto maior o tempo limite de ociosidade, maior a pressão em portas SNAT. Use o tempo limite de ociosidade 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 tornará as portas SNAT não disponí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. Embora a pilha de TCP seja recuperada, o desempenho do aplicativo poderá ser prejudicado quando os pontos de extremidade de uma conexão tiverem uma incompatibilidade de expectativas. O desejo de alterar temporizadores geralmente é um sinal de um problema de design subjacente. Examine as seguintes recomendações.

Migrar de um Load Balancer de SKU Básico para o SKU Standard

Se você tiver um cluster existente com o Load Balancer de SKU Básico, haverá diferenças comportamentais importantes a serem observadas ao migrar para usar um cluster com o Load Balancer 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, Load Balancers de SKU Básico usam os Endereços IP do SKU Básico que não são compatíveis com os Load Balancers de SKU Standard porque exigem Endereços IP de SKU Standard. Ao migrar clusters para atualizar SKUs do Load Balancer, será 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 para ver uma lista de tópicos importantes a serem considerados durante a migração. As limitações abaixo também são importantes diferenças comportamentais a serem observadas ao usar Load Balancers de SKU Standard no AKS.

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 também é 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 criado que o cluster do AKS, que geralmente é chamado de 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 será criado automaticamente no mesmo grupo de recursos que o cluster 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 Azure Policy 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. Todos os endereços IP personalizados devem ser criados e gerenciados pelo usuário.
  • 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

Saiba mais sobre os serviços do Kubernetes na documentação dos serviços do Kubernetes.

Saiba mais sobre como usar o Load Balancer interno para tráfego de entrada na documentação do Load Balancer interno do AKS.