Resolver problemas de distribuição de tráfego desigual

Neste documento, mostramos como resolver problemas com a distribuição desigual de tráfego para serviços do Kubernetes.

Identificar sintomas de distribuição desigual de tráfego

A distribuição desigual de tráfego, geralmente chamada de pontos de acesso, ocorre quando um subconjunto de pods ou nós lida com uma quantidade desproporcional da carga de trabalho total, enquanto outros permanecem subutilizados.

Os sintomas comuns incluem:

• Gargalos de desempenho: os usuários podem ter tempos limite intermitentes, erros HTTP 5xx ou perda de pacotes em conexões de rede superutilizadas.
• Exaustão de recursos: pods ou nós específicos mostram uma utilização de CPU ou memória significativamente maior do que o restante da frota.
• Padrões de desequilíbrio de tráfego:
  • Desequilíbrio por pod: o tráfego atinge apenas um pequeno subconjunto de pods disponíveis, mesmo que todos os pods sejam relatados como íntegros e prontos.
  • Desequilíbrio por nó: um ou mais nós recebem significativamente mais pacotes ou solicitações do que outros, o que geralmente acontece ao usar externalTrafficPolicy: Local com posicionamento desigual de pods.
  • Sessões de cliente fixas: todas as solicitações de um único cliente de alto volume são roteadas consistentemente para o mesmo pod de back-end.

Diagnóstico usando o Cloud Monitoring

Para confirmar esses sintomas, visualize os padrões de tráfego usando as seguintes métricas:

• Para a camada 7 (entrada/gateway): crie um gráfico de loadbalancing.googleapis.com/backend/request_count e agrupe por backend_target para comparar volumes de solicitações em diferentes back-ends.

Entenda as causas comuns da distribuição desigual de tráfego

Esta seção descreve as causas comuns de distribuição desigual de tráfego para serviços do Kubernetes. Esse desequilíbrio pode levar a gargalos de desempenho, esgotamento de recursos em determinados pods e redução da disponibilidade de aplicativos, com alguns pods recebendo significativamente mais tráfego do que outros, enquanto alguns recebem muito pouco ou nenhum.

A afinidade da sessão causa uma distribuição desigual

O problema a seguir ocorre quando os balanceadores de carga com afinidade da sessão ativada encaminham consistentemente solicitações do mesmo cliente para o mesmo pod de back-end. Se um cliente específico gerar um grande volume de tráfego, esse pod ficará sobrecarregado, resultando em um hotspot em que ele recebe muito mais carga do que outros, enquanto outros pods permanecem subutilizados.

É possível configurar a afinidade da sessão em objetos de serviço do Kubernetes usando o campo sessionAffinity.

Quando sessionAffinity é definido como ClientIP, o serviço garante que todas as conexões originadas do mesmo endereço IP do cliente sejam encaminhadas de forma consistente para o mesmo pod de back-end. Isso fornece afinidade da sessão real baseada em IP do cliente.

Quando sessionAffinity é definido como None (o comportamento padrão), os balanceadores de carga de camada 4 normalmente distribuem conexões usando um hash de vários parâmetros de rede, como uma tupla de 4 (endereço IP do cliente, endereço IP de destino, porta de destino, protocolo) ou uma tupla de 5 (incluindo a porta de origem). Embora esse hash possa fornecer alguma "aderência" de conexão, roteando consistentemente conexões com valores de tupla idênticos para o mesmo back-end, ele não garante que todas as conexões de um endereço IP do cliente específico sempre vão para o mesmo pod se outros elementos de tupla mudarem.

Para mais informações, consulte Afinidade da sessão.

Para o gateway do GKE, o CRD GCPTrafficDistributionPolicy configura a afinidade da sessão. Para mais informações, consulte Configurar recursos de gateway usando políticas.

Para balanceadores de carga de rede de passagem externa regionais, é possível usar a afinidade da sessão para manter a fixação da conexão a um back-end específico. No entanto, a afinidade da sessão pode causar uma distribuição desigual se alguns clientes gerarem mais tráfego do que outros.

Para mais informações, consulte Afinidade da sessão e Visão geral do balanceador de carga de rede de passagem externa baseado em serviço de back-end.

O exemplo a seguir mostra um manifesto de Serviço com sessionAffinity: ClientIP:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  sessionAffinity: ClientIP  # This can cause uneven distribution
  ports:
  -   port: 80
    targetPort: 8080
  selector:
    app: my-app

O agrupamento de conexões causa distribuição desigual

O pool de conexões ocorre quando os balanceadores de carga reutilizam conexões atuais com pods específicos, mesmo que outros pods tenham capacidade disponível. Esse comportamento pode causar um desequilíbrio se algumas conexões durarem mais ou processarem muito mais solicitações do que outras. Isso concentra o tráfego em determinados pods, semelhante à afinidade da sessão, criando pontos de acesso em que esses pods ficam sobrecarregados enquanto outros permanecem subutilizados.

Os balanceadores de carga implementam o pool de conexões para melhorar a performance, reduzindo a sobrecarga de estabelecer novas conexões. No entanto, se não for gerenciado corretamente, o pooling de conexões pode causar uma distribuição desigual do tráfego, especialmente com aplicativos que mantêm conexões de longa duração.

Para mitigar a distribuição desigual causada pelo pool de conexões, implemente estratégias no nível do aplicativo ou do cliente:

• Configure os clientes para usar várias conexões: em vez de depender de uma única conexão de longa duração, configure os clientes para abrir e gerenciar um pool de várias conexões com o balanceador de carga. Isso permite que o balanceador de carga distribua novas tentativas de conexão entre os pods de back-end disponíveis, melhorando a distribuição geral do tráfego.

• Fechar e reabrir conexões periodicamente: para aplicativos que naturalmente mantêm conexões de longa duração, configure-os ou configure os clientes para fechar e reabrir conexões periodicamente. Embora isso gere uma pequena sobrecarga de restabelecimento de conexão, ele oferece ao balanceador de carga novas oportunidades de distribuir as tentativas de conexão subsequentes para pods de back-end diferentes e menos utilizados. Essa abordagem é particularmente eficaz para serviços em que o encerramento e o restabelecimento da conexão não são muito disruptivos.

• Implemente a diminuição da conexão agressiva: verifique se os pods estão configurados para encerramento completo e diminuição da conexão. Quando um pod é encerrado normalmente (por exemplo, durante uma implantação ou redução de escala), o balanceador de carga para de enviar novas conexões a ele e permite que as conexões atuais sejam concluídas ou esgotadas. Isso permite que o tráfego mude para outros pods com mais facilidade e ajuda a evitar que ele se concentre em pods de encerramento.

Ao gerenciar ativamente o comportamento da conexão, você ajuda os balanceadores de carga a distribuir o tráfego de maneira mais uniforme, mesmo com conexões de longa duração.

A hash de 5 tuplas causa uma distribuição desigual

Esse é o comportamento padrão de muitos balanceadores de carga da camada 4 quando você não configura explicitamente a afinidade da sessão. Se muitas conexões se originarem do mesmo cliente ou usarem as mesmas combinações de porta, isso vai resultar em uma distribuição desigual.

Para resolver desequilíbrios causados por hash, considere o seguinte:

• Use o balanceamento de carga da camada 7: o GKE Ingress e o Gateway operam no nível da solicitação, permitindo que distribuam solicitações de um único cliente em vários pods de back-end.

• Ajuste o comportamento do cliente: configure os clientes para usar várias conexões ou um pool maior de portas de origem.

A distribuição desigual de pods entre os nós causa uma distribuição desigual

Esse problema ocorre quando os pods não são distribuídos uniformemente entre os nós e o balanceador de carga não usa o balanceamento de carga nativo de contêiner. Nós com mais pods recebem mais tráfego, o que pode levar à sobrecarga de alguns nós e à subutilização de outros.

Esse problema é especialmente relevante quando você usa externalTrafficPolicy: Local.

As configurações da política de tráfego externo causam distribuição desigual

A configuração externalTrafficPolicy no seu serviço afeta como o tráfego é roteado.

• Cluster: permite que o balanceador de carga distribua o tráfego para qualquer nó no cluster. Use a configuração Cluster para a distribuição mais uniforme em todos os nós e pods disponíveis.
• Local: encaminha o tráfego apenas para pods em execução no mesmo nó que recebeu o tráfego. Isso pode levar a uma distribuição desigual se você não distribuir os pods de maneira uniforme entre os nós.

A afinidade de nós causa uma distribuição desigual

Usar a afinidade de nó para restringir pods a um subconjunto de nós pode fazer com que esses nós fiquem sobrecarregados, especialmente se a carga de trabalho não estiver bem equilibrada entre eles.

Confira se os pods não estão fixados em nós específicos.