Utilize um balanceador de carga padrão público em Azure Kubernetes Service (AKS)

O Balanceador de Carga do Azure funciona na camada 4 do modelo Open Systems Interconnection (OSI) que suporta cenários de entrada e saída. Distribui fluxos de entrada que chegam à extremidade dianteira do balançador de carga para as instâncias da piscina traseira.

Um equilibrador de carga pública integrado com AKS serve dois propósitos:

  1. Para fornecer ligações de saída aos nós de cluster dentro da rede virtual AKS. Para tal, traduz o endereço IP privado para um endereço IP público que faz parte do seu Outbound Pool.
  2. Para fornecer acesso a aplicações através dos serviços de tipo LoadBalancerKubernetes . Com ele, pode facilmente escalar as suas aplicações e criar serviços altamente disponíveis.

Um equilibrador de carga interno (ou privado) é utilizado onde apenas os IPs privados são permitidos como frontend. Os balançadores internos de carga são utilizados para carregar o tráfego de equilíbrio dentro de uma rede virtual. Um frontend de balançador de carga também pode ser acedido a partir de uma rede no local num cenário híbrido.

Este documento abrange a integração com o balanceador de carga pública. Para a integração interna do balançador de carga, consulte a documentação do balançador interno de carga da AKS.

Antes de começar

Balanceador de Carga do Azure está disponível em dois SKUs: Básico e Standard. Por padrão, o Standard SKU é utilizado quando cria um cluster AKS. O Standard SKU dá-lhe acesso a funcionalidades adicionais, como uma piscina de backend maior, piscinas de nós múltiplos, Zonas de Disponibilidade, e é seguro por padrão. É o balanceador de carga recomendado SKU para AKS.

Para obter mais informações sobre os SKUs Básicos e Standard , consulte a comparação SKU do balanceador de carga Azure.

Este artigo pressupõe que você tem um cluster AKS com o Balanceador de Carga do Azure Standard SKU. Se precisar de um cluster AKS, crie um utilizando o Azure CLI, Azure PowerShell ou o portal do Azure.

Importante

Se preferir não aproveitar a Balanceador de Carga do Azure para fornecer ligação de saída e, em vez disso, ter o seu próprio gateway, firewall ou proxy para o efeito, pode saltar a criação da piscina de saída do balanceador de carga e do respetivo FRONTend IP utilizando o tipo de saída como UserDefinedRouting (UDR). O tipo de saída define o método de saída para um cluster e os predefinidos para escrever loadBalancer.

Utilize o equilibrador de carga padrão público

Depois de criar um cluster AKS com tipo LoadBalancer de saída (padrão), o cluster está pronto a utilizar o equilibrador de carga para expor os serviços.

Para isso, pode criar um serviço público de tipo LoadBalancer. Comece por criar um manifesto de serviço chamado public-svc.yaml.

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

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

kubectl apply -f public-svc.yaml

O Balanceador de Carga do Azure será configurado com um novo IP público que irá fazer frente a este novo serviço. Uma vez que o Balanceador de Carga do Azure pode ter vários IPs frontend, cada novo serviço implantado receberá um novo IP dedicado para ser acedido de forma única.

Pode utilizar o seguinte comando para confirmar que o seu serviço foi criado e o equilibrador de carga está configurado.

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 vê os dados de serviço, o endereço IP público criado para este serviço no equilibrador de carga é mostrado na coluna EXTERNAL-IP . Pode levar alguns minutos para o endereço IP mudar de <pendente> para um endereço IP público real.

Configure o balançador de carga padrão público

Ao utilizar o balanceador de carga público padrão, há um conjunto de opções que pode personalizar no momento da criação ou atualizando o cluster. Estas opções permitem-lhe personalizar o equilibrador de carga para atender às suas necessidades de carga de trabalho e devem ser revistas em conformidade. Com o equilibrador de carga padrão, pode:

  • Definir ou escalar o número de IPs de saída geridos
  • Traga os seus próprios IPs de saída personalizados ou prefixo IP de saída
  • Personalize o número de portas de saída atribuídas a cada nó do cluster
  • Configure a definição de tempo limite para ligações inativas

Importante

Apenas uma opção IP de saída (IPs geridos, traga o seu próprio IP ou prefixo IP) pode ser usada num dado momento.

Escalar o número de IPs públicos geridos

Balanceador de Carga do Azure fornece conectividade de saída a partir de uma rede virtual, além de entrada. As regras de saída simplificam a tradução de endereços de rede para o balanceador de carga padrão público.

Como todas as regras do balançador de carga, as regras de saída seguem a mesma sintaxe que o equilíbrio de carga e as regras NAT de entrada:

IPs frontend + parâmetros + piscina de backend

Uma regra de saída configura o NAT de saída para todas as máquinas virtuais identificadas pela piscina de backend para serem traduzidas para o frontend. Os parâmetros fornecem controlo adicional sobre o algoritmo NAT de saída.

Embora uma regra de saída possa ser usada com um único endereço IP público, as regras de saída facilitam o fardo de configuração para escalar o NAT de saída. Você pode usar vários endereços IP para planear cenários em larga escala, e você pode usar regras de saída para mitigar padrões propensos à exaustão SNAT. Cada endereço IP adicional fornecido por um frontend fornece portas efémeras de 64k para o equilibrador de carga utilizar como portas SNAT.

Ao utilizar um balanceador de carga Standard SKU com IPs públicos de saída geridos, que são criados por padrão, pode escalar o número de IPs públicos geridos utilizando o load-balancer-managed-ip-count parâmetro.

Para atualizar um cluster existente, executar o seguinte comando. Este parâmetro também pode ser definido no tempo de criação de cluster para ter múltiplos IPs públicos geridos.

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 geridos de saída para 2 para o cluster myAKSCluster no myResourceGroup.

Também pode utilizar o load-balancer-managed-ip-count parâmetro para definir o número inicial de IPs públicos geridos ao criar o seu cluster, fixando o parâmetro e definindo-o --load-balancer-managed-outbound-ip-count para o valor pretendido. O número predefinido de IPs públicos geridos é 1.

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

Quando utiliza um balanceador de carga Standard SKU, o cluster AKS cria automaticamente um IP público no grupo de recursos de infraestrutura gerido pela AKS e atribui-o ao pool de saída do balanceador de carga por padrão.

Um IP público criado pela AKS é considerado um recurso gerido pela AKS. Isto significa que o ciclo de vida desse IP público destina-se a ser gerido pela AKS e não requer nenhuma ação do utilizador diretamente no recurso IP público. Em alternativa, pode atribuir o seu próprio prefixo IP público personalizado ou IP público no tempo de criação do cluster. Os seus IPs personalizados também podem ser atualizados sobre as propriedades do balanceador de carga existentes.

Requisitos para a utilização do seu próprio IP público ou prefixo:

  • Os endereços IP públicos personalizados devem ser criados e propriedade do utilizador. Os endereços IP públicos geridos criados pela AKS não podem ser reutilizados como um IP personalizado, pois pode causar conflitos de gestão.
  • Deve garantir que a identidade do cluster AKS (Service Principal ou Identidade Gerida) tem permissões para aceder ao IP de saída, de acordo com a lista de permissões IP públicas exigidas.
  • Certifique-se de que cumpre os requisitos e restrições necessários para configurar iPs de saída ou prefixos IP de saída.

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

Utilize o comando de exibição público-ip da rede az para listar os IDs dos seus IPs públicos.

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

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

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

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

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

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

Também pode utilizar prefixos IP públicos para saídas com o seu equilibrador de carga SKU Standard . O exemplo a seguir utiliza o comando de exibição de prefixo ip da rede az para listar os IDs dos seus prefixos IP públicos.

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

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

O exemplo a seguir utiliza o parâmetro de pré-prefixos de saída-equilíbrio-tempo de carga-ip-prefixos com os IDs do comando anterior.

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

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

Pode trazer os seus próprios endereços IP ou prefixos IP para saídas no tempo de criação do cluster para suportar cenários como adicionar pontos finais de saída a uma lista de admissões. Anexar os mesmos parâmetros acima mostrados ao seu passo de criação de cluster para definir os seus próprios ips públicos e prefixos IP no início do ciclo de vida de um cluster.

Utilize os az aks criar comando com o parâmetro de saída ips de saída de equilíbrio de carga para criar um novo cluster com os seus IPs públicos no início.

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

Utilize o az aks criar comando com o parâmetro de pré-prefixos de saída ip-out-balanceador de carga para criar um novo cluster com os seus prefixos IP públicos no início.

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

Configure os portos de saída atribuídos

Importante

Se tiver aplicações no seu cluster que podem estabelecer um grande número de ligações a um pequeno conjunto de destinos, como muitas instâncias de uma aplicação frontal conectada a uma base de dados, você pode ter um cenário muito suscetível de encontrar a exaustão do porto SNAT. A exaustão da porta SNAT acontece quando uma aplicação fica fora das portas de saída para usar para estabelecer uma ligação a outra aplicação ou hospedeiro. Se tiver um cenário em que possa encontrar a exaustão do porto SNAT, recomendamos vivamente que aumente as portas de saída atribuídas e os IPs frontend de saída no equilibrador de carga para evitar a exaustão do porto SNAT. Consulte abaixo informações sobre como calcular corretamente as portas de saída e os valores ip frontend de saída.

Por predefinição, a AKS define Os Portos De saída Atribuídos no seu balanceador de carga para , o que permite a 0atribuição automática de porta de saída com base no tamanho da piscina de backend ao criar um cluster. Por exemplo, se um cluster tiver 50 ou menos nós, 1024 portas são alocadas a cada nó. À medida que o número de nós no cluster é aumentado, menos portas estarão disponíveis por nó. Para mostrar o valor de OutboundPorts atribuído para o balanceador de carga de cluster AKS, utilize 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 da porta de saída baseada no tamanho da piscina de backend está ativada 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 Os Portos De saída e endereço IP de saída ao criar ou atualizar um cluster, utilize load-balancer-outbound-ports e qualquer um 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 e endereço IP de saída, deve calcular o número adequado de portas de saída e endereços IP. Utilize a seguinte equação para este cálculo arredondado 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, lembre-se:

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

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

  • Se os valores predefinidos forem utilizados e o cluster tiver 48 nós, cada nó terá 1024 portas disponíveis.
  • Se forem utilizados os valores predefinidos e as escalas de cluster de 48 a 52 nós, cada nó será atualizado a partir de 1024 portas disponíveis para 512 portas disponíveis.
  • Se as portas de saída estiverem definidas para 1.000 e a contagem de IP de saída estiver definida para 2, então o cluster pode suportar 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 estiverem definidas para 1.000 e a contagem de IP de saída estiver definida para 7, então o cluster pode suportar 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 estiverem definidas para 4.000 e a contagem de IP de saída estiver definida para 2, então o cluster pode suportar 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 estiverem definidas para 4.000 e a contagem de IP de saída estiver definida para 7, então o cluster pode 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 e IPs de saída, verifique se tem capacidade adicional de saída para lidar com o aumento do nó durante as atualizações. É fundamental atribuir portos excedentários suficientes para os nós adicionais necessários para a atualização e outras operações. AKS falha num nó tampão para operações de atualização. Se utilizar valores maxSurge, multiplique as portas de saída por nó pelo seu valor máximoSurge para determinar o número de portas necessárias. Por exemplo, se calculasse que precisava de 4000 portas por nó com 7 endereço IP num cluster com um máximo de 100 nóns e uma onda máxima de 2:

  • 2 nós de ascensão * 4000 portas por nó = 8000 portas necessárias para o aumento do nó durante as atualizações.
  • 100 nós * 4000 portas por nó = 400.000 portas necessárias para o seu cluster.
  • 7 IPs * 64000 portas por IP = 448.000 portas disponíveis para o seu cluster.

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

Uma vez calculados e verificados os valores, pode aplicar esses valores utilizando load-balancer-outbound-ports e quer load-balancer-managed-outbound-ip-count, load-balancer-outbound-ipsou 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

Configure o tempo limite de marcha lenta o vez que o balançador de carga está parada

Quando os recursos portuários SNAT estão esgotados, os fluxos de saída falham até que os fluxos existentes libertem as portas SNAT. O balanceador de carga recupera as portas SNAT quando o fluxo se fecha e o balançador de carga configurado pela AKS utiliza um tempo limite de 30 minutos para recuperar as portas SNAT dos fluxos inativos.

Também pode utilizar o transporte (por exemplo, TCP keepalives ou application-layer keepalives) para refrescar um fluxo inativo e redefinir este tempo de inatividade, se necessário. Pode configurar este intervalo seguindo o exemplo abaixo.

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

Se espera ter numerosas ligações de curta duração e nenhuma ligação de longa duração que possa ter longos períodos de inatividade, como alavancagem kubectl proxy ou kubectl port-forward, considere usar um baixo valor de tempo limite, como 4 minutos. Ao utilizar as keepalives TCP, é suficiente para os ativar de um lado da ligação. Por exemplo, é suficiente para permitir que fiquem do lado do servidor apenas para repor o temporizador inativo do fluxo. Não é necessário que ambos os lados iniciem as keepalives da TCP. Existem conceitos semelhantes para a camada de aplicação, incluindo configurações de servidor de clientes de base de dados. Verifique o lado do servidor para saber quais as opções existentes para manterias específicas da aplicação.

Importante

AKS permite o reset do TCP por defeito. Recomendamos que mantenha esta configuração e a aproveite para um comportamento de aplicação mais previsível nos seus cenários.

O TCP RST só é enviado durante a ligação TCP no estado estabelecido. Leia mais sobre o assunto aqui.

Ao configurar o IdleTimeoutInMinutes para um valor diferente do padrão de 30 minutos, considere quanto tempo as suas cargas de trabalho precisarão de uma ligação de saída. Considere também que o valor de tempo limite padrão para um balanceador de carga Standard SKU utilizado fora da AKS é de 4 minutos. Um valor IdleTimeoutInMinutes que reflita com mais precisão a sua carga de trabalho específica da AKS pode ajudar a diminuir a exaustão do SNAT causada pela ligação de ligações que já não são usadas.

Aviso

Alterar os valores para AlocedOutboundPorts e IdleTimeoutInMinutes pode alterar significativamente o comportamento da regra de saída para o seu equilibrador de carga e não deve ser feito de ânimo leve. Consulte a secção de resolução de problemas SNAT abaixo e reveja as regras de saída Balanceador de Carga e as ligações de saída em Azure antes de atualizar estes valores para entender completamente o impacto das suas alterações.

Restringir o tráfego de entrada a gamas IP específicas

O manifesto seguinte utiliza loadBalancerSourceRanges para especificar uma nova gama 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 apenas a MY_EXTERNAL_IP_RANGE partir do intervalo. Se substituir MY_EXTERNAL_IP_RANGE pelo endereço IP da sub-rede interna, o tráfego é limitado apenas a IPs internos do cluster. Se o tráfego for restrito a IPs internos de cluster, os clientes fora do seu cluster Kubernetes não poderão aceder ao equilibrador de carga.

Nota

A entrada, o tráfego externo flui do equilibrador de carga para a rede virtual para o seu cluster AKS. A rede virtual tem um grupo de segurança de rede (NSG) que permite todo o tráfego de entrada a partir do equilibrador de carga. Este NSG utiliza uma etiqueta de serviço do tipo LoadBalancer para permitir o tráfego do equilibrador de carga.

Mantenha o IP do cliente em ligações de entrada

Por padrão, um serviço de tipo LoadBalancerem Kubernetes e em AKS não persistirá o endereço IP do cliente na ligação ao pod. O IP de origem no pacote que é entregue na cápsula será o IP privado do nó. Para manter o endereço IP do cliente, tem de estar local definido service.spec.externalTrafficPolicy na definição de serviço. O manifesto que se segue 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 através de anotações de Kubernetes

Abaixo está uma lista de anotações suportadas para serviços Kubernetes com tipo LoadBalancer, estas anotações aplicam-se apenas aos fluxos INBOUND :

Anotação Valor Descrição
service.beta.kubernetes.io/azure-load-balancer-internal true ou false Especificar se o balançador de carga deve ser interno. É indefinitivo para o público, se não definido.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet Nome da sub-rede Especificar a que sub-rede o balançador de carga interno deve estar ligado. Está a falhar na sub-rede configurada em ficheiro configurado em nuvem se não estiver definida.
service.beta.kubernetes.io/azure-dns-label-name Nome da etiqueta DNS em IPs públicos Especifique o nome da etiqueta DNS para o serviço público . Se estiver definido para o fio vazio, a entrada DNS no IP público não será utilizada.
service.beta.kubernetes.io/azure-shared-securityrule true ou false Especifique que o serviço deve ser exposto usando uma regra de segurança Azure que pode ser partilhada com outro serviço, comercializando a especificidade das regras para um aumento do número de serviços que podem ser expostos. Esta anotação baseia-se na funcionalidade Azure Aumentada Security Rules dos grupos de segurança da 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 etiquetas de serviço permitidas Especifique uma lista de etiquetas de serviço permitidas separadas por vírgula.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout Intervalos de tempo inativos da TCP em minutos Especifique a hora, em minutos, para que os intervalos de inatividade da ligação TCP ocorram no balançador de carga. O padrão e o valor mínimo são 4. O valor máximo é de 30. Deve ser um inteiro.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true Desative enableTcpReset para SLB. Deprefetado em Kubernetes 1.18 e removido em 1.20.

SNAT de resolução de problemas

Se você sabe que você está começando muitas ligações TCP ou UDP de saída para o mesmo endereço IP de destino e porto, e você observa ligações de saída falhadas ou é aconselhado por suporte que você está esgotando portas SNAT (portas efémeras pré-locadas usadas pela PAT), você tem várias opções gerais de mitigação. Reveja estas opções e decida o que é melhor para o seu cenário. É possível que um ou mais possam ajudar a gerir este cenário. Para obter informações detalhadas, reveja o guia de resolução de problemas de ligações de saída.

Frequentemente, a causa principal da exaustão do SNAT é um anti-padrão para a forma como a conectividade de saída é estabelecida, gerida ou configurável dos seus valores padrão. Leia esta secção atentamente.

Passos

  1. Verifique se as suas ligações permanecem inativas durante muito tempo e confie no tempo limite de marcha lenta padrão para libertar essa porta. Em caso afirmativo, o tempo limite de 30 minutos pode ter de ser reduzido para o seu cenário.
  2. Investigue como a sua aplicação está a criar conectividade de saída (por exemplo, revisão de código ou captura de pacotes).
  3. Determine se esta atividade é um comportamento esperado ou se a aplicação está a portar-se mal. Utilize métricas e registos no Azure Monitor para fundamentar as suas descobertas. Por exemplo, utilize a categoria "Falhado" para a métrica das ligações SNAT.
  4. Avalie se os padrões adequados são seguidos .
  5. Avaliar se o esgotamento da porta SNAT deve ser atenuado com endereços IP adicionais de saída + portas de saída adicionais atribuídas .

Padrões de design

Aproveite sempre que possível a reutilização da ligação e a ligação. Estes padrões evitarão problemas de exaustão de recursos e resultarão em comportamentos previsíveis. Os primitivos para estes padrões podem ser encontrados em muitas bibliotecas e estruturas de desenvolvimento.

  • Os pedidos atómicos (um pedido por ligação) geralmente não são uma boa escolha de design. Tais anti-padrões limitam a escala, reduzem o desempenho e diminuem a fiabilidade. Em vez disso, reutilizar as ligações HTTP/S para reduzir o número de ligações e portas SNAT associadas. A escala de aplicação aumentará e o desempenho melhorará devido à redução dos apertos de mão, sobrecarga e custo de operação criptográfico ao utilizar o TLS.
  • Se estiver a utilizar DNS de cluster/personalizado ou servidores a montante personalizados no coreDNS, tenha em mente que o DNS pode introduzir muitos fluxos individuais em volume quando o cliente não está a caching o resultado dos resolvers DNS. Certifique-se de personalizar o coreDNS primeiro em vez de usar servidores DNS personalizados e definir um bom valor de caching.
  • Os fluxos de UDP (por exemplo, pesquisas de DNS) alocam portas SNAT durante o tempo limite de marcha lenta. Quanto mais tempo o tempo de pressão, maior a pressão nas portas SNAT. Utilize um tempo curto de marcha lenta (por exemplo, 4 minutos). Utilize piscinas de ligação para moldar o seu volume de ligação.
  • Nunca abandone silenciosamente um fluxo de TCP e confie nos temporizadores TCP para limpar o fluxo. Se não deixar a TCP fechar explicitamente a ligação, o estado permanece alocado em sistemas intermédios e pontos finais e torna as portas SNAT indisponíveis para outras ligações. Este padrão pode desencadear falhas de aplicação e exaustão do SNAT.
  • Não altere os valores de temporizador de proximidade de nível de OS sem conhecimento especializado do impacto. Enquanto a pilha de TCP vai recuperar, o desempenho da sua aplicação pode ser negativamente afetado quando os pontos finais de uma ligação têm expectativas desajustadas. Querer mudar os temporizadores é geralmente um sinal de um problema de design subjacente. Reveja as recomendações.

Passar de um balanceador de carga SKU básico para o Standard SKU

Se tiver um cluster existente com o balanceador de carga Basic SKU, existem diferenças comportamentais importantes a notar ao migrar para usar um cluster com o balanceador de carga SKU padrão .

Por exemplo, fazer implantações azuis/verdes para migrar clusters é uma prática comum dado que o load-balancer-sku tipo de um cluster só pode ser definido no cluster criar tempo. No entanto, os equilibradores básicos de carga SKU utilizam endereços IP Básicos SKU, que não são compatíveis com os equilibradores de carga Standard SKU , uma vez que requerem endereços IP Standard SKU . Ao migrar clusters para atualizar os SKUs do balanceador de carga, será necessário um novo endereço IP com um endereço IP compatível SKU.

Para mais considerações sobre como migrar clusters, visite a nossa documentação sobre considerações migratórias para ver uma lista de tópicos importantes a ter em conta na migração. As limitações abaixo também são diferenças comportamentais importantes a notar ao usar equilibradores de carga Standard SKU em AKS.

Limitações

Aplicam-se as seguintes limitações quando cria e gere clusters AKS que suportam um equilibrador de carga com o SKU padrão :

  • Pelo menos um prefixo IP ou IP público é necessário para permitir o tráfego de saída do cluster AKS. O prefixo IP ou IP público também é necessário para manter a conectividade entre o plano de controlo e os nós do agente e para manter a compatibilidade com as versões anteriores da AKS. Tem as seguintes opções para especificar ips públicos ou prefixos IP com um balanceador de carga SKU standard :
    • Forneça os seus próprios iPs públicos.
    • Forneça os seus próprios prefixos IP públicos.
    • Especifique um número até 100 para permitir que o cluster AKS crie muitos IPs públicos Standard SKU no mesmo grupo de recursos criado como o cluster AKS, que é geralmente nomeado com MC_ no início. A AKS atribui o IP público ao balanceador de carga Standard SKU. Por padrão, um IP público será automaticamente criado no mesmo grupo de recursos que o cluster AKS, se não for especificado nenhum IP público, prefixo IP público ou número de IPs. Também deve permitir endereços públicos e evitar criar qualquer política de Azure que proíba a criação de IP.
  • Um IP público criado pela AKS não pode ser reutilizado como um endereço IP público. Todos os endereços IP personalizados devem ser criados e geridos pelo utilizador.
  • A definição do equilibrador de carga SKU só pode ser feita quando se cria um cluster AKS. Não é possível alterar o balanceador de carga SKU depois de ter sido criado um cluster AKS.
  • Só pode utilizar um tipo de balanceador de carga SKU (Básico ou Standard) num único cluster.
  • Padrão Os equilibradores de carga SKU suportam apenas endereços IP Standard SKU.

Passos seguintes

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

Saiba mais sobre a utilização do balançador interno de carga para o tráfego de entrada na documentação do balançador interno de carga da AKS.