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

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.

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:

• 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    203.0.113.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:        203.0.113.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.

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.

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 \
    --generate-ssh-keys

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

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.

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> \
    --generate-ssh-keys

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> \
    --generate-ssh-keys

Configurar as portas de saída alocadas

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ó. Esse valor permite o dimensionamento para contar o máximo de nós do cluster sem exigir a reconfiguração da rede, mas pode tornar a exaustão da porta SNAT mais comum à medida que mais nós são adicionados. À medida que o número de nós no cluster aumenta, menos portas estão disponíveis por nó. Aumentar as contagens de nós através dos limites no gráfico (por exemplo, passando de 50 para 51 nós ou 100 para 101) pode causar interrupções na conectividade, pois as portas SNAT alocadas aos nós existentes são reduzidas para permitir mais nós. Recomenda-se o uso de um valor explícito para AllocatedOutboundPorts, conforme mostrado abaixo.

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.

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.

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.

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.

Manter o IP do cliente em conexões de entrada

Por padrão, um serviço do tipo LoadBalancer no 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.

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.