Usar um balanceador de carga padrão no AKS (Serviço de Kubernetes do Azure)
O Azure Load Balancer opera na camada 4 do modelo de referência OSI que dá suporte a cenários de entrada e de saída. Ele distribui fluxos de entrada que chegam ao front-end do balanceador de carga para as instâncias do pool de back-end.
Quando integrado ao AKS, um balanceador de carga público tem duas finalidades:
- Para fornecer conexões de saída para os nós de cluster dentro da rede virtual do AKS traduzindo o endereço IP privado para uma parte de endereço IP público de seu pool de saída.
- Para fornecer acesso a aplicativos por meio de serviços Kubernetes do tipo
LoadBalancer
, permitindo que você escalone facilmente seus aplicativos e crie serviços altamente disponíveis.
Um balanceador de carga interno (ou privado) é usado quando apenas IPs privados são permitidos como front-end. Os balanceadores de carga internos são usados para balancear a carga do tráfego dentro de uma rede virtual. Um front-end do balanceador de carga também pode ser acessado de uma rede local em um cenário híbrido.
Este artigo aborda a integração com um balanceador de carga público no AKS. Para saber mais sobre a integração do balanceador de carga interno, confira Usar um balanceador de carga interno no AKS.
Antes de começar
- O Azure Load Balancer está disponível em duas SKUs, Básica e Standard. Por padrão, o SKU Standard é usado quando você cria um cluster do AKS. O SKU Standard dá acesso a funcionalidades adicionais, como um pool de back-end maior, pools de vários nós e Zonas de Disponibilidade e é seguro por padrão. É a SKU do balanceador de carga recomendada para o AKS. Para obter mais informações sobre os SKUs Básico e Standard, confira Comparação de SKU do Azure Load Balancer.
- Para obter uma lista completa das anotações com suporte para serviços do Kubernetes com o tipo
LoadBalancer
, confira Anotações do LoadBalancer. - Este artigo pressupõe que você tenha um cluster do AKS com o Azure Load Balancer de SKU Standard. Se você precisar de um cluster do AKS, crie um usando a CLI do Azure, o Azure PowerShell ou o portal do Azure.
- O AKS gerencia o ciclo de vida e as operações dos nós do agente. Não há suporte para a modificação dos recursos de IaaS associados aos nós do agente. Um exemplo de uma operação sem suporte é fazer alterações manuais no grupo de recursos do balanceador de carga.
Importante
Se você preferir usar seu próprio gateway, firewall ou proxy para fornecer conexão de saída, você pode ignorar a criação do pool de saída do balanceador de carga e o respectivo IP de front-end usando o tipo de saída como UserDefinedRouting (UDR). O tipo de saída define o método de saída para um cluster e usa o tipo LoadBalancer
como padrão.
Usar o Standard Load Balancer público
Depois que você criar um cluster do AKS com o tipo de saída LoadBalancer
(padrão), seu cluster estará pronto para usar o balanceador de carga para expor serviços.
Crie um manifesto do serviço chamado public-svc.yaml
, que cria um serviço público do tipo LoadBalancer
.
apiVersion: v1
kind: Service
metadata:
name: public-svc
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: public-app
Especificar o endereço IP do balanceador de carga
Se você quiser usar um endereço IP específico com o balanceador de carga, há duas maneiras:
Importante
A adição da propriedade LoadBalancerIP ao manifesto YAML do balanceador de carga está substituindo o upstream Kubernetes a seguir. Embora o uso atual permaneça o mesmo e os serviços existentes funcionem sem modificação, é altamente recomendável definir anotações de serviço.
- Definir anotações de serviço: use
service.beta.kubernetes.io/azure-load-balancer-ipv4
para um endereço IPv4 eservice.beta.kubernetes.io/azure-load-balancer-ipv6
para um endereço IPv6. - Adicione a propriedade LoadBalancerIP ao manifesto YAML do balanceador de carga: adicione a propriedade Service.Spec.LoadBalancerIP ao manifesto YAML do balanceador de carga. Esse campo está substituindo o upstream Kubernetes a seguir e não pode dar suporte a pilha dupla. O uso atual permanece o mesmo e espera-se que os serviços existentes funcionem sem modificação.
Implantar o manifesto do serviço
Implante o manifesto do serviço público usando kubectl apply
e especifique o nome do manifesto YAML.
kubectl apply -f public-svc.yaml
O balanceador de carga do Azure é configurado com um novo IP público que faz a frente do novo serviço. Como o Azure Load Balancer pode ter vários IPs de front-end, cada novo serviço implantado recebe um novo IP de front-end dedicado para ser acessado de forma exclusiva.
Confirme se o serviço foi criado e se o balanceador de carga está configurado usando o comando a seguir.
kubectl get service public-svc
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default public-svc LoadBalancer 10.0.39.110 52.156.88.187 80:32068/TCP 52s
Quando você vê os detalhes do serviço, o endereço IP público criado para ele no balanceador de carga é mostrado na coluna EXTERNAL-IP. Pode levar alguns minutos para que o endereço IP mude de <pendente> para um endereço IP público real.
Para obter informações mais detalhadas sobre seu serviço, utilize o seguinte comando.
kubectl describe service public-svc
A saída de exemplo a seguir é uma versão condensada da saída após a execução de kubectl describe service
. A Entrada do Azure Load Balancer mostra o endereço IP externo exposto pelo serviço. O IP mostra os endereços internos.
Name: public-svc
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=public-app
...
IP: 10.0.39.110
...
LoadBalancer Ingress: 52.156.88.187
...
TargetPort: 80/TCP
NodePort: 32068/TCP
...
Session Affinity: None
External Traffic Policy: Cluster
...
Configurar o Standard Load Balancer público
Você pode personalizar configurações diferentes para o balanceador de carga público padrão no momento da criação do cluster ou atualizando o cluster. Essas opções de personalização permitem que você crie um balanceador de carga que atenda às suas necessidades de carga de trabalho. Com o Standard Load Balancer, você pode:
- Defina ou escalone o número de IPs de saída gerenciados.
- Traga seus IPs de saída ou prefixos de IP de saída personalizados.
- Personalize o número de portas de saída alocadas para cada nó do cluster.
- Defina a configuração de tempo limite para conexões ociosas.
Importante
Somente uma opção de IP de saída (IPs gerenciados, traga seu próprio IP ou prefixo de IP) pode ser usada por vez.
Alterar o tipo de pool de entrada
Os nós AKS podem ser referenciados nos pools de back-end do balanceador de carga pela sua configuração de IP (associação baseada em Conjuntos de Dimensionamento de Máquinas Virtuais do Azure) ou apenas pelo seu endereço IP. Utilizar a associação de pool de back-end baseada em endereço IP fornece maior eficiência ao atualizar serviços e provisionar balanceadores de carga, especialmente em contagens altas de nós. Agora há suporte para o provisionamento de novos clusters com pools de back-end baseados em IP e para a conversão de clusters existentes. Quando combinado com o Gateway da NAT ou com tipos de saída de roteamento definidos pelo usuário, o provisionamento de novos nós e serviços é mais eficiente.
Há dois tipos de associação de pool diferentes disponíveis:
nodeIPConfiguration
- Herdado da configuração de IP dos Conjuntos de Dimensionamento de Máquinas Virtuais com base no tipo de associação ao poolnodeIP
– Tipo de associação baseada em IP
Requisitos
- O cluster do AKS precisa ser a versão 1.23 ou superior.
- Ele precisa usar balanceadores de carga padrão e conjuntos de dimensionamento de máquinas virtuais.
Criar um cluster do AKS com uma associação de pool de entrada baseada em IP
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--load-balancer-backend-pool-type=nodeIP \
--generate-ssh-keys
Atualizar um cluster do AKS existente para usar a associação de pool de entrada baseada em IP
Aviso
Essa operação causa uma interrupção temporária do tráfego de serviços de entrada no cluster. O tempo de impacto aumenta com clusters maiores que possuem muitos nós.
az aks update \
--resource-group myResourceGroup \
--name myAKSCluster \
--load-balancer-backend-pool-type=nodeIP
Escalar o número de IPs públicos de saída gerenciados
O Azure Load Balancer fornece conectividade de entrada e saída de uma rede virtual. As regras de saída simplificam a configuração da conversão de endereços de rede para o balanceador de carga padrão público.
As regras de saída seguem a mesma sintaxe que regras NAT de entrada e balanceamento de carga:
IPs de front-end + parâmetros + pool de back-end
Uma regra de saída configura o NAT de saída para todas as máquinas virtuais identificadas pelo pool de back-end a serem convertidas no front-end. Os parâmetros oferecem mais controle sobre o algoritmo NAT de saída.
Embora você possa usar uma regra de saída com um único endereço IP público, as regras de saída são ótimas para escalonar a NAT de saída porque facilitam a carga de configuração. Você pode usar vários endereços IP para planejar cenários de grande escala e regras de saída para atenuar padrões propensos ao esgotamento de SNAT. Cada endereço IP fornecido por um front-end fornece 64 mil portas efêmeras para o balanceador de carga usar como portas SNAT.
Ao usar um balanceador de carga com SKU Standard e IPs públicos de saída gerenciados (que são criados por padrão), você pode escalonar o número de IPs públicos de saída gerenciados usando o parâmetro --load-balancer-managed-outbound-ip-count
.
Use o comando a seguir para atualizar um cluster existente. Você também pode definir esse parâmetro para ter vários IPs públicos de saída gerenciados.
Importante
Não é recomendado usar o portal do Azure para fazer alterações de regra de saída. Ao fazer essas alterações, você deve fazê-las por meio do cluster do AKS e não diretamente no recurso do Load Balancer.
As alterações das regras de saída feitas diretamente no recurso do balanceador de carga são removidas sempre que o cluster é reconciliado, por exemplo, quando é interrompido, iniciado, atualizado ou colocado em escala.
Use a CLI do Azure, conforme mostrado nos exemplos. As alterações de regra de saída feitas usando os comandos az aks
da CLI são permanentes no tempo de inatividade do cluster.
Para obter mais informações, confira Regras de saída do Azure Load Balancer.
az aks update \
--resource-group myResourceGroup \
--name myAKSCluster \
--load-balancer-managed-outbound-ip-count 2
O exemplo acima define o número de IPs públicos de saída gerenciados como 2 para o cluster myAKSCluster no myResourceGroup.
No momento da criação do cluster, você também pode definir o número inicial de IPs públicos de saída gerenciados anexando o parâmetro --load-balancer-managed-outbound-ip-count
e definindo-o como o valor desejado. O número padrão de IPs públicos de saída gerenciados é 1.
Fornecer seus prefixos ou IPs públicos de saída
Quando você usa um balanceador de carga com SKU Standard, o cluster do AKS cria automaticamente um IP público no grupo de recursos da infraestrutura gerenciada pelo AKS e o atribui ao pool de saída do balanceador de carga por padrão.
Um IP público criado pelo AKS é um recurso gerenciado pelo AKS, o que significa que o AKS gerencia o ciclo de vida desse IP público e não exige ação do usuário diretamente no recurso de IP público. Como alternativa, você pode atribuir seu IP público personalizado ou prefixo de IP público no momento da criação do cluster. Os IPs personalizados também podem ser atualizados nas propriedades do balanceador de carga em um cluster existente.
Os requisitos para usar seu prefixo ou IP público incluem:
- Os usuários devem criar e possuir endereços IP públicos personalizados. Os endereços IP públicos gerenciados criados pelo AKS não podem ser reutilizados na modalidade "traga seu próprio IP personalizado", pois isso pode causar conflitos de gerenciamento.
- A identidade do cluster do AKS (entidade de serviço ou identidade gerenciada) deve ter permissões para acessar o IP de saída, conforme a lista de permissões de IP público obrigatórias.
- Verifique se você atende aos pré-requisitos e restrições necessários para configurar IPs de saída ou prefixos de IP de saída.
Atualizar o cluster com seu IP público de saída
Use o comando az network public-ip show
para listar as IDs dos seus IPs públicos.
az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv
O comando acima mostra a ID para o IP público myPublicIP no grupo de recursos myResourceGroup.
Use o comando az aks update
com o parâmetro load-balancer-outbound-ips
para atualizar o cluster com os IPs públicos.
O exemplo a seguir usa o parâmetro load-balancer-outbound-ips
com as IDs do comando anterior.
az aks update \
--resource-group myResourceGroup \
--name myAKSCluster \
--load-balancer-outbound-ips <publicIpId1>,<publicIpId2>
Atualizar o cluster com seu prefixo de IP público de saída
Você também pode usar prefixos de IP público para saída com seu balanceador de carga de SKU Standard. O exemplo a seguir usa o comando az network public-ip prefix show para listar as IDs dos seus prefixos de IP público.
az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv
O comando acima mostra a ID para o prefixo de IP público myPublicIPPrefix no grupo de recursos myResourceGroup.
O exemplo a seguir usa o parâmetro load-balancer-outbound-ip-prefixes com as IDs do comando anterior.
az aks update \
--resource-group myResourceGroup \
--name myAKSCluster \
--load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>
Criar o cluster com seu IP público ou prefixos
Ao criar seu cluster, você pode trazer seus endereços IP ou prefixos de IP para saída a fim de dar suporte a cenários como a adição de pontos de extremidade de saída para uma lista de permitidos. Para definir seus próprios IPs públicos e prefixos de IP no momento da criação do cluster, acrescente os mesmos parâmetros mostrados no comando anterior.
Use o comando az aks create
com o parâmetro load-balancer-outbound-ips
para criar um cluster com seus próprios IPs públicos.
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--load-balancer-outbound-ips <publicIpId1>,<publicIpId2> \
--generate-ssh-keys
Use o comando az aks create
com o parâmetro load-balancer-outbound-ip-prefixes
para criar um cluster com seus próprios prefixos IP públicos.
az aks create \
--resource-group myResourceGroup \
--load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2> \
--generate-ssh-keys
Configurar as portas de saída alocadas
Importante
Se você tiver aplicativos no seu cluster que possam estabelecer um grande número de conexões com um pequeno conjunto de destinos, como muitas instâncias de um aplicativo front-end conectado a um banco de dados, poderá ter um cenário suscetível ao esgotamento de portas SNAT. O esgotamento de portas SNAT acontece quando um aplicativo é executado fora das portas de saída a serem usadas para estabelecer uma conexão com outro aplicativo ou host. Se você tem um cenário suscetível ao esgotamento de portas SNAT, é altamente recomendável que você aumente as portas de saída alocadas e os IPs de front-end de saída no balanceador de carga.
Para obter mais informações sobre SNAT, consulte Usar SNAT para conexões de saída.
Por padrão, o AKS define AllocatedOutboundPorts em seu balanceador de carga para 0
, que permite a atribuição automática de porta de saída com base no tamanho do pool de back-end ao criar um cluster. Por exemplo, se um cluster tiver 50 nós ou menos, 1.024 portas serão alocadas para cada nó. À medida que o número de nós no cluster aumenta, menos portas ficam disponíveis por nó.
Importante
Há um limite rígido de 1024 portas, independentemente da adição de IPs de front-end quando o tamanho do nó for menor que ou igual a 50 (1-50).
Para mostrar o valor de AllocatedOutboundPorts para o balanceador de carga do cluster AKS, use az network lb outbound-rule list
.
NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table
A saída de exemplo a seguir mostra que a atribuição de porta de saída automática com base no tamanho do pool de back-end está habilitada para o cluster.
AllocatedOutboundPorts EnableTcpReset IdleTimeoutInMinutes Name Protocol ProvisioningState ResourceGroup
------------------------ ---------------- ---------------------- --------------- ---------- ------------------- -------------
0 True 30 aksOutboundRule All Succeeded MC_myResourceGroup_myAKSCluster_eastus
Para configurar um valor específico para AllocatedOutboundPorts e endereço IP de saída ao criar ou atualizar um cluster, use load-balancer-outbound-ports
e um entre load-balancer-managed-outbound-ip-count
, load-balancer-outbound-ips
e load-balancer-outbound-ip-prefixes
. Antes de definir um valor específico ou aumentar um valor existente para as portas de saída ou endereços IP de saída, você precisa calcular o número apropriado de portas de saída e endereços IP. Use a seguinte equação para esse cálculo arredondado para o inteiro mais próximo: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>
.
Ao calcular o número de portas de saída e IPs e definir os valores, lembre-se das seguintes informações:
- O número de portas de saída por nó é fixado com base no valor definido.
- O valor das portas de saída deve ser um múltiplo de 8.
- Adicionar mais IPs não adiciona mais portas a nenhum nó, mas fornece capacidade para mais nós no cluster.
- Você precisa levar em conta os nós que podem ser adicionados como parte de atualizações, incluindo a contagem de nós especificados através de valores maxSurge.
Os exemplos a seguir mostram como os valores definidos afetam o número de portas de saída e endereços IP:
- Se os valores padrão forem utilizados e o cluster tiver 48 nós, cada nó terá 1024 portas disponíveis.
- Se os valores padrão forem utilizados e o cluster for escalado de 48 para 52 nós, cada nó será atualizado de 1024 portas disponíveis para 512 portas disponíveis.
- Se o número de portas de saída estiver definido como 1.000 e a contagem de IP de saída estiver definida como 2, o cluster pode dar suporte a um máximo de 128 nós:
64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes
. - Se o número de portas de saída estiver definido como 1.000 e a contagem de IP de saída estiver definida como 7, o cluster pode dar suporte a um máximo de 448 nós:
64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes
. - Se o número de portas de saída estiver definido como 4.000 e a contagem de IP de saída estiver definida como 2, o cluster pode dar suporte a um máximo de 32 nós:
64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes
. - Se o número de portas de saída estiver definido como 4.000 e a contagem de IP de saída estiver definida como 7, o cluster pode dar suporte a um máximo de 112 nós:
64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes
.
Importante
Depois de calcular o número de IPs e portas de saída, verifique se você tem capacidade de porta de saída adicional para lidar com o aumento de nós durante as atualizações. É essencial alocar portas excedentes suficientes para os nós adicionais necessários para a atualização e outras operações. O AKS assume como padrão um nó de buffer para operações de atualização. Se estiver usando valores de maxSurge, multiplique as portas de saída por nó pelo valor de maxSurge para determinar o número de portas exigido. Por exemplo, se você tiver calculado que precisa de 4000 portas por nó com 7 endereços IP em um cluster com um máximo de 100 nós e um aumento máximo de 2:
- 2 nós de aumento * 4.000 portas por nó = 8.000 portas necessárias para o aumento de nó durante atualizações.
- 100 nós * 4.000 portas por nó = 400.000 portas necessárias para o cluster.
- 7 IPs * 64.000 portas por IP = 448.000 portas disponíveis para o cluster.
O exemplo acima mostra que o cluster tem uma capacidade de 48.000 portas excedentes, o que é suficiente para dar conta das 8.000 portas exigidas para o aumento de nó durante atualizações.
Depois que os valores tiverem sido calculados e verificados, você poderá aplicar esses valores usando load-balancer-outbound-ports
e um entre load-balancer-managed-outbound-ip-count
, load-balancer-outbound-ips
e load-balancer-outbound-ip-prefixes
ao criar ou atualizar um cluster.
az aks update \
--resource-group myResourceGroup \
--name myAKSCluster \
--load-balancer-managed-outbound-ip-count 7 \
--load-balancer-outbound-ports 4000
Configurar o tempo limite ocioso do balanceador de carga
Quando os recursos da porta SNAT estão esgotados, os fluxos de saída falham até que os fluxos existentes liberem as portas SNAT. O balanceador de carga recupera portas SNAT quando o fluxo é fechado e o balanceador de carga configurado pelo AKS usa um tempo limite ocioso de 30 minutos para recuperar portas SNAT de fluxos ociosos.
Você também pode usar o transporte (por exemplo, TCP keepalives
ou application-layer keepalives
) para atualizar um fluxo ocioso e redefinir esse tempo limite ocioso, se necessário. Configure o tempo limite seguindo este exemplo.
az aks update \
--resource-group myResourceGroup \
--name myAKSCluster \
--load-balancer-idle-timeout 4
Se você espera ter várias conexões curtas e nenhuma conexão longa e pode ter longos períodos de ociosidade, como ao usar kubectl proxy
ou kubectl port-forward
, considere usar um valor de tempo limite baixo, como 4 minutos. Ao usar keep alives TCP, é suficiente habilitá-los em um lado da conexão. Por exemplo, é suficiente habilitá-los no lado do servidor apenas para redefinir o temporizador de ociosidade do fluxo. Não é necessário que ambos os lados iniciem keepalives TCP. Conceitos semelhantes existem para a camada de aplicativo, incluindo as configurações de cliente-servidor de banco de dados. Verifique o lado do servidor quanto às opções existentes para keep alives específicos do aplicativo.
Importante
O AKS habilita a Redefinição de TCP em ociosidade por padrão. É recomendado manter essa configuração e utilizá-la para um comportamento de aplicativo mais previsível em seus cenários.
O RST TCP só é enviado durante a conexão TCP no estado estabelecido. Leia mais sobre isso aqui.
Ao definir IdleTimeoutInMinutes para um valor diferente do padrão de 30 minutos, considere por quanto tempo suas cargas de trabalho precisam de uma conexão de saída. Considere também que o valor do tempo limite padrão para um balanceador de carga de SKU Standard usado fora do AKS é de 4 minutos. Um valor IdleTimeoutInMinutes que reflete com mais precisão sua carga de trabalho do AKS específica pode ajudar a diminuir o esgotamento de SNAT causado pela associação de conexões que não são mais usadas.
Aviso
A alteração dos valores para AllocatedOutboundPorts e IdleTimeoutInMinutes pode alterar significativamente o comportamento da regra de saída para seu balanceador de carga e não deve ser feito sem cuidadosa consideração. Confira a seção Solução de problemas de SNAT e analise as regras de saída do balanceador de carga e as conexões de saída no Azure antes de atualizar esses valores para entender totalmente o impacto de suas alterações.
Restringir o tráfego de entrada a intervalos de IP específicos
O manifesto a seguir usa loadBalancerSourceRanges para especificar um novo intervalo de IP para o tráfego externo de entrada.
apiVersion: v1
kind: Service
metadata:
name: azure-vote-front
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: azure-vote-front
loadBalancerSourceRanges:
- MY_EXTERNAL_IP_RANGE
Este exemplo atualiza a regra para permitir o tráfego externo de entrada somente do intervalo MY_EXTERNAL_IP_RANGE
. Se você substituir MY_EXTERNAL_IP_RANGE
pelo endereço IP da sub-rede interna, o tráfego será restrito somente a IPs internos do cluster. Se o tráfego for restrito aos IPs internos do cluster, os clientes fora do cluster do Kubernetes não poderão acessar o balanceador de carga.
Observação
- O tráfego externo de entrada flui do balanceador de carga para a rede virtual do cluster do AKS. A rede virtual tem um NSG (grupo de segurança de rede) que permite todo o tráfego de entrada do balanceador de carga. Esse NSG usa uma marca de serviço do tipo LoadBalancer para permitir o tráfego do balanceador de carga.
- O CIDR do Pod deverá ser adicionado a loadBalancerSourceRanges se houver Pods que precisem acessar o IP do LoadBalancer do serviço para clusters com a versão v1.25 ou superior.
Manter o IP do cliente em conexões de entrada
Por padrão, um serviço do tipo LoadBalancer
no Kubernetes e no AKS não mantém o endereço IP do cliente na conexão com o pod. O IP de origem no pacote que é entregue ao pod se torna o IP privado do nó. Para manter o endereço IP do cliente, você precisa definir service.spec.externalTrafficPolicy
como local
na definição do serviço. O manifesto a seguir mostra um exemplo.
apiVersion: v1
kind: Service
metadata:
name: azure-vote-front
spec:
type: LoadBalancer
externalTrafficPolicy: Local
ports:
- port: 80
selector:
app: azure-vote-front
Personalizações via Anotações do Kubernetes
As anotações a seguir têm suporte para serviços do Kubernetes com o tipo LoadBalancer
e se aplicam apenas a fluxos de ENTRADA.
Annotation | Valor | Descrição |
---|---|---|
service.beta.kubernetes.io/azure-load-balancer-internal |
true ou false |
Especifique se o balanceador de carga deve ser interno. Se não estiver definido, o padrão será público. |
service.beta.kubernetes.io/azure-load-balancer-internal-subnet |
Nome da sub-rede | Especifique a qual sub-rede o balanceador de carga interno deve ser associado. Se não estiver definido, o padrão será a sub-rede configurada no arquivo de configuração de nuvem. |
service.beta.kubernetes.io/azure-dns-label-name |
Nome do rótulo DNS em IPs públicos | Especifique o nome do rótulo DNS para o serviço público. Se for definido como uma cadeia de caracteres vazia, a entrada do DNS no IP público não será utilizada. |
service.beta.kubernetes.io/azure-shared-securityrule |
true ou false |
Especifique expor o serviço por meio de uma regra de segurança do Azure potencialmente compartilhada para aumentar a exposição do serviço, utilizando as Regras de Segurança Aumentadas do Azure em grupos de Segurança de Rede. |
service.beta.kubernetes.io/azure-load-balancer-resource-group |
Nome do grupo de recursos | Especifique o grupo de recursos dos IPs públicos do balanceador de carga que não estão no mesmo grupo de recursos que a infraestrutura de cluster (grupo de recursos de nó). |
service.beta.kubernetes.io/azure-allowed-service-tags |
Lista de marcas de serviço permitidas | Especifique uma lista de marcas de serviço permitidas separadas por vírgulas. |
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout |
Tempos limite ociosos de TCP em minutos | Especifique o tempo, em minutos, para que os tempos limite ociosos da conexão TCP ocorram no balanceador de carga. O valor padrão e mínimo é 4. O valor máximo é 30. O valor deve ser um inteiro. |
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset |
true ou false |
Especifique se o balanceador de carga deve desabilitar a redefinição de TCP no tempo limite ocioso. |
service.beta.kubernetes.io/azure-load-balancer-ipv4 |
Endereço IPv4 | Especifique o endereço IPv4 a ser atribuído ao balanceador de carga. |
service.beta.kubernetes.io/azure-load-balancer-ipv6 |
Endereço IPv6 | Especifique o endereço IPv6 a ser atribuído ao balanceador de carga. |
Personalize a investigação de integridade do balanceador de carga
Annotation | Valor | Descrição |
---|---|---|
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval |
Intervalo de investigação de integridade | |
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe |
O número mínimo de respostas não íntegras da investigação de integridade | |
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path |
Caminho para solicitação da investigação de integridade | |
service.beta.kubernetes.io/port_{port}_no_lb_rule |
true/false | {port} é o número da porta de serviço. Quando definido como true, nenhuma regra lb ou regra de investigação de integridade para essa porta é gerada. O serviço de verificação de integridade não deve ser exposto à Internet pública(por exemplo, serviço de verificação de integridade istio/envoy) |
service.beta.kubernetes.io/port_{port}_no_probe_rule |
true/false | {port} é o número da porta de serviço. Quando definido como true, nenhuma regra de investigação de integridade para essa porta é gerada. |
service.beta.kubernetes.io/port_{port}_health-probe_protocol |
Protocolo de investigação de integridade | {port} é o número da porta de serviço. Protocolo explícito para a investigação de integridade da porta de serviço {port}, substituindo port.appProtocol, se definido. |
service.beta.kubernetes.io/port_{port}_health-probe_port |
número da porta ou nome da porta no manifesto do serviço | {port} é o número da porta de serviço. Porta explícita para a investigação de integridade da porta de serviço {port}, substituindo o valor padrão. |
service.beta.kubernetes.io/port_{port}_health-probe_interval |
Intervalo de investigação de integridade | {port} é o número da porta de serviço. |
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe |
O número mínimo de respostas não íntegras da investigação de integridade | {port} é o número da porta de serviço. |
service.beta.kubernetes.io/port_{port}_health-probe_request-path |
Caminho para solicitação da investigação de integridade | {port} é o número da porta de serviço. |
Conforme documentado aqui, Tcp, Http e Https são três protocolos compatíveis com o serviço de balanceador de carga.
Atualmente, o protocolo padrão da investigação de integridade varia entre serviços com diferentes protocolos de transporte, protocolos de aplicativo, anotações e políticas de tráfego externo.
- para serviços locais, HTTP e /healthz seriam usados. A investigação de integridade consultará NodeHealthPort em vez do atual serviço de back-end
- para serviços TCP de cluster, o TCP seria usado.
- para serviços UDP de cluster, não há investigações de integridade.
Observação
Para serviços locais com integração PLS e protocolo proxy PLS habilitado, a investigação de integridade padrão HTTP+/healthz não funciona. Portanto, a investigação de integridade pode ser personalizada da mesma forma que os serviços de cluster para dar suporte a esse cenário.
Desde a v1.20, a anotação de serviço service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path
está introduzida para determinar o comportamento da investigação de integridade.
- Para clusters <=1.23,
spec.ports.appProtocol
só seriam usados como protocolo de investigação quandoservice.beta.kubernetes.io/azure-load-balancer-health-probe-request-path
também estiver definido. - Para clusters >1.24,
spec.ports.appProtocol
seriam usados como protocolo de investigação e/
seriam usados como caminho de solicitação de investigação padrão (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path
poderia ser usado para alterar para um caminho de solicitação diferente).
Observe que o caminho de solicitação seria ignorado ao usar TCP ou se o spec.ports.appProtocol
estiver vazio. Mais especificamente:
loadbalancer sku | externalTrafficPolicy |
spec.ports.Protocol | spec.ports.AppProtocol | service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path |
Protocolo de Investigação LB | Caminho de Solicitação de Investigação LB |
---|---|---|---|---|---|---|
padrão | local | qualquer | qualquer | qualquer | http | /healthz |
padrão | cluster | udp | qualquer | qualquer | null | null |
padrão | cluster | TCP | (ignorado) | TCP | nulo | |
padrão | cluster | TCP | TCP | (ignorado) | TCP | nulo |
padrão | cluster | TCP | http/https | TCP(<=1.23) ou http/https(>=1.24) | nulo(<=1.23) ou / (>=1.24) |
|
padrão | cluster | TCP | http/https | /custom-path |
http/https | /custom-path |
padrão | cluster | TCP | protocolo sem suporte | /custom-path |
TCP | nulo |
básico | local | qualquer | qualquer | qualquer | http | /healthz |
básico | cluster | TCP | (ignorado) | TCP | nulo | |
básico | cluster | TCP | TCP | (ignorado) | TCP | nulo |
básico | cluster | TCP | http | TCP(<=1.23) ou http/https(>=1.24) | nulo(<=1.23) ou / (>=1.24) |
|
básico | cluster | TCP | http | /custom-path |
http | /custom-path |
básico | cluster | TCP | protocolo sem suporte | /custom-path |
TCP | nulo |
Desde a v1.21, duas anotações de serviço service.beta.kubernetes.io/azure-load-balancer-health-probe-interval
e load-balancer-health-probe-num-of-probe
estão introduzidas, que personalizam a configuração da investigação de integridade. Se service.beta.kubernetes.io/azure-load-balancer-health-probe-interval
não estiver definido, o Valor padrão de 5 será aplicado. Se load-balancer-health-probe-num-of-probe
não estiver definido, o Valor padrão de 2 será aplicado. E a investigação total deve ser inferior a 120 segundos.
Investigação de integridade do Balanceador de Carga Personalizado para a porta
Portas diferentes em um serviço podem exigir diferentes configurações de investigação de integridade. Isso pode ser devido ao design do serviço (como um único ponto de extremidade de integridade que controla várias portas) ou aos recursos do Kubernetes, como o MixedProtocolLBService.
As seguintes anotações podem ser usadas para personalizar a configuração da investigação por porta de serviço.
anotação específica da porta | anotação da investigação global | Uso |
---|---|---|
service.beta.kubernetes.io/port_{port}_no_lb_rule | N/A (não há equivalente a nível global) | se definido como true, nenhuma regra de lb e regra de investigação será gerada |
service.beta.kubernetes.io/port_{port}_no_probe_rule | N/A (não há equivalente a nível global) | se definido como true, nenhuma regra de investigação será gerada |
service.beta.kubernetes.io/port_{port}_health-probe_protocol | N/A (não há equivalente a nível global) | Define o protocolo de investigação de integridade para essa porta de serviço (por exemplo, Http, Https, Tcp) |
service.beta.kubernetes.io/port_{port}_health-probe_port | N/A (não há equivalente a nível global) | Define a porta de investigação de integridade para essa porta de serviço (por exemplo, 15021) |
service.beta.kubernetes.io/port_{port}_health-probe_request-path | service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path | Para Http ou Https, define o caminho da solicitação da investigação de integridade. O padrão é / |
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe | service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe | Número de falhas consecutivas de investigação antes que a porta seja considerada não íntegra |
service.beta.kubernetes.io/port_{port}_health-probe_interval | service.beta.kubernetes.io/azure-load-balancer-health-probe-interval | A quantidade de tempo entre tentativas de investigação |
Para o seguinte manifesto, a regra de investigação para a porta httpsserver é diferente para httpserver porque as anotações pora a porta httpsserver são especificadas.
apiVersion: v1
kind: Service
metadata:
name: appservice
annotations:
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
type: LoadBalancer
selector:
app: server
ports:
- name: httpserver
protocol: TCP
port: 80
targetPort: 30102
- name: httpsserver
protocol: TCP
appProtocol: HTTPS
port: 443
targetPort: 30104
Nesse manifesto, as portas https usam uma porta de nó diferente, uma verificação de prontidão HTTP na porta 10256 em /healthz(ponto de extremidade healthz do kube-proxy).
apiVersion: v1
kind: Service
metadata:
name: istio
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
service.beta.kubernetes.io/port_443_health-probe_port: "10256"
service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
ports:
- name: https
protocol: TCP
port: 443
targetPort: 8443
nodePort: 30104
appProtocol: https
selector:
app: istio-ingressgateway
gateway: istio-ingressgateway
istio: ingressgateway
type: LoadBalancer
sessionAffinity: None
externalTrafficPolicy: Local
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
allocateLoadBalancerNodePorts: true
internalTrafficPolicy: Cluster
Nesse manifesto, as portas https usam um diferente ponto de extremidade da investigação de integridade, uma verificação de prontidão HTTP na porta 30000 em /healthz/ready.
apiVersion: v1
kind: Service
metadata:
name: istio
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
service.beta.kubernetes.io/port_443_health-probe_port: "30000"
service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
ports:
- name: https
protocol: TCP
port: 443
targetPort: 8443
appProtocol: https
selector:
app: istio-ingressgateway
gateway: istio-ingressgateway
istio: ingressgateway
type: LoadBalancer
sessionAffinity: None
externalTrafficPolicy: Local
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
allocateLoadBalancerNodePorts: true
internalTrafficPolicy: Cluster
Solucionar problemas de SNAT
Se você sabe que está iniciando muitas conexões TCP ou UDP de saída para o mesmo endereço e porta IP de destino, e observa conexões de saída com falha ou o suporte informa que as portas SNAT (portas efêmeras pré-alocadas usadas pela PAT) estão se esgotando, você tem várias opções gerais para mitigação. Examine essas opções e decida qual é a melhor para seu cenário. É possível que uma ou mais possam ajudar a gerenciar o seu cenário. Para informações detalhadas, confira o Guia de solução de problemas de conexões de saída.
A causa raiz do esgotamento de SNAT é frequentemente um antipadrão para a forma como a conectividade de saída é estabelecida e gerenciada, ou como os temporizadores configuráveis têm os valores padrão alterados. Revise esta seção com cuidado.
Etapas
- Verifique se suas conexões permanecem ociosas por muito tempo e se baseiam no tempo limite ocioso padrão para liberar a porta. Se for esse o caso, poderá ser preciso reduzir o tempo limite padrão de 30 minutos para seu cenário.
- Investigue como o aplicativo cria a conectividade de saída (por exemplo, revisão de código ou captura de pacote).
- Determinar se essa atividade é um comportamento esperado ou se o aplicativo está tendo um comportamento inadequado. Use métricas e logs no Azure Monitor para substanciar suas conclusões. Por exemplo, use a categoria "Falha" para a métrica de conexões SNAT.
- Avalie se os padrões apropriados são seguidos.
- Avalie se o esgotamento de porta SNAT deve ser mitigado com mais endereços IP de saída e mais portas de saída alocadas.
Padrões de design
Aproveite a reutilização de conexão e o pool de conexões quando possível. Esses padrões ajudam a evitar problemas de esgotamento de recursos e resultam em um comportamento previsível. Os primitivos desses padrões podem ser encontrados em muitas bibliotecas e estruturas de desenvolvimento.
- Geralmente, solicitações atômicas (uma solicitação por conexão) não são uma boa opção de design. Esses antipadrões limitam a escala, reduzem o desempenho e diminuem a confiabilidade. Em vez disso, reutilize as conexões HTTP/S para reduzir os números de conexões e as portas SNAT associadas. A escalada do aplicativo aumenta e o desempenho melhora devido à redução dos handshakes, da sobrecarga e do custo da operação criptográfica ao utilizar o TLS.
- Se você está usando um DNS personalizado/fora do cluster ou servidores upstream personalizados no coreDNS, tenha em mente que o DNS pode introduzir muitos fluxos individuais com volume quando o cliente não está armazenando em cache o resultado do resolvedor de DNS. Certifique-se de personalizar o coreDNS primeiro em vez de usar servidores DNS personalizados e de definir um bom valor de cache.
- Os fluxos UDP (por exemplo, pesquisas de DNS) alocam portas SNAT durante o tempo limite ocioso. Quanto maior o tempo limite de ociosidade, maior a pressão em portas SNAT. Use o tempo limite ocioso curto (por exemplo, 4 minutos).
- Use pools de conexão para formatar o volume de conexão.
- Nunca abandone silenciosamente um fluxo de TCP nem dependa de temporizadores TCP para limpar o fluxo. Se você não permitir que o TCP feche explicitamente a conexão, o estado permanecerá alocado em sistemas intermediários e pontos de extremidade, e isso tornará as portas SNAT indisponíveis para outras conexões. Esse padrão pode disparar falhas de aplicativo e esgotamento de SNAT.
- Não altere os valores de temporizador relacionados ao fechamento de TCP no nível do sistema operacional sem um conhecimento especializado do impacto. Enquanto a pilha TCP se recupera, o desempenho do seu aplicativo pode ser afetado negativamente quando os pontos de extremidade de uma conexão têm expectativas incompatíveis. O desejo de alterar temporizadores geralmente é um sinal de um problema de design subjacente. Examine as seguintes recomendações.
Migrar de um balanceador de carga de SKU Básico para o SKU Standard
Se você tiver um cluster existente com o balanceador de carga de SKU Básico, haverá diferenças comportamentais importantes a serem observadas ao migrar para o balanceador de carga de SKU Standard.
Por exemplo, fazer implantações azuis/verdes para migrar clusters é uma prática comum considerando que o tipo load-balancer-sku
de um cluster só pode ser definido no momento da criação do cluster. No entanto, balanceadores de carga de SKU Básico usam os Endereços IP do SKU Básico que não são compatíveis com os balanceadores de carga de SKU Standard. Os balanceadores de carga de SKU Standard requerem endereços IP de SKU Standard. Ao migrar clusters para atualizar SKUs do balanceador de carga, é necessário um novo endereço IP com um SKU de endereço IP compatível.
Para ver mais considerações sobre como migrar clusters, acesse nossa documentação sobre considerações sobre migração.
Limitações
As seguintes limitações se aplicam quando você cria e gerencia clusters do AKS que dão suporte a um balanceador de carga com o SKU Standard:
- Pelo menos um IP público ou prefixo de IP é necessário para permitir o tráfego de saída do cluster do AKS. O IP público ou o prefixo de IP é necessário para manter a conectividade entre o painel de controle e os nós do agente, bem como para manter a compatibilidade com as versões anteriores do AKS. Você tem as seguintes opções para especificar IPs públicos ou prefixos de IP com um balanceador de carga de SKU Standard:
- Fornecer seus IPs públicos.
- Forneça seus prefixos de IP público.
- Especifique um número até 100 para permitir que o cluster do AKS crie esse tanto de IPs públicos de SKU Standard no mesmo grupo de recursos que o cluster do AKS. Esse grupo de recursos geralmente é nomeado com MC_ no início. O AKS atribui o IP público ao balanceador de carga de SKU Standard. Por padrão, um IP público é criado automaticamente no mesmo grupo de recursos que o cluster do AKS se nenhum IP público, prefixo de IP público ou número de IPs for especificado. Você também deve permitir endereços públicos e evitar a criação de qualquer política do Azure que cause banimento à criação do IP.
- Um IP público criado pelo AKS não pode ser reutilizado na modalidade traga seu próprio endereço IP público personalizado. Os usuários devem criar e gerenciar todos os endereços IP personalizados.
- Definir o SKU do balanceador de carga só pode ser feito ao criar um cluster do AKS. Você não poderá alterar o SKU do balanceador de carga depois que um cluster do AKS for criado.
- Você só pode usar um tipo de SKU do balanceador de carga (Básico ou Standard) em um cluster.
- Os balanceadores de carga de SKU Standard dão suporte apenas a endereços IP de SKU Standard.
Próximas etapas
Para saber mais sobre os serviços do Kubernetes, confira a Documentação dos serviços do Kubernetes.
Para saber mais sobre como usar o balanceador de carga interno para tráfego de entrada, confira a documentação do balanceador de carga interno do AKS.
Azure Kubernetes Service