Load Balancing no Kubernetes: 5 opções técnicas com exemplos

O que é load balancing no Kubernetes?

O load balancing no Kubernetes é o processo automatizado de distribuir o tráfego de rede entre vários Pods para garantir alta disponibilidade, escalabilidade e desempenho ideal. Ele opera em duas camadas principais: o gerenciamento interno dentro do cluster e a exposição externa para usuários de fora.

Ao abstrair a complexidade de rotear e distribuir requisições, o Kubernetes permite que desenvolvedores implantem aplicações escaláveis sem gerenciar manualmente a distribuição de tráfego. Essa automação é essencial para alta disponibilidade, tolerância a falhas e desempenho em ambientes modernos e conteinerizados.

Opções técnicas para implementar load balancing no Kubernetes:

• ClusterIP (interno): usa um IP virtual para distribuir o tráfego entre Pods dentro do cluster, sendo a opção padrão para a comunicação interna entre serviços.
• NodePort: expõe um Service em uma porta estática em cada nó do cluster, permitindo que clientes externos acessem as aplicações via <NodeIP>:<NodePort>.
• LoadBalancer: integra-se a balanceadores de carga da nuvem ou da infraestrutura para fornecer um endereço IP externo que distribui o tráfego entre os nós do cluster e os Pods de backend.
• Ingress: fornece roteamento HTTP/HTTPS na camada 7, permitindo que vários Services compartilhem um único endpoint externo com regras de roteamento baseadas em host e caminho.
• Gateway API: usa recursos dedicados de Gateway e Route para oferecer gerenciamento de tráfego avançado e orientado por políticas, com suporte a múltiplos protocolos e separação entre equipes.

Este conteúdo faz parte de uma série de artigos sobre Kubernetes scheduling.

Por que o load balancing é necessário no Kubernetes

Ambientes Kubernetes são dinâmicos. Pods podem ser criados, encerrados, reagendados ou escalados a qualquer momento, conforme a demanda da aplicação ou as condições do cluster. Sem load balancing, o tráfego poderia continuar fluindo para pods sobrecarregados ou indisponíveis, causando respostas lentas, requisições com falha ou indisponibilidade.

O load balancing ajuda o Kubernetes a manter o desempenho e a disponibilidade das aplicações de forma consistente. Ele distribui as requisições entre pods saudáveis e redireciona o tráfego quando ocorrem falhas. Isso permite que as aplicações continuem atendendo os usuários durante quedas de pods, atualizações contínuas (rolling updates) ou mudanças na infraestrutura.

Os principais motivos pelos quais o load balancing é necessário no Kubernetes incluem:

• Evitar sobrecarga de tráfego em um único pod ou nó
• Dar suporte ao escalonamento horizontal, distribuindo requisições entre réplicas
• Manter alta disponibilidade durante falhas de pods ou nós
• Viabilizar deployments sem downtime e rolling updates
• Melhorar os tempos de resposta e a confiabilidade das aplicações
• Simplificar o roteamento de tráfego em ambientes dinâmicos de contêineres
• Permitir que os serviços escalem automaticamente conforme o tráfego varia

Como os contêineres são efêmeros e os workloads mudam constantemente, o load balancing automatizado é um requisito central para operações estáveis no Kubernetes.

5 formas de implementar load balancing no Kubernetes

1. ClusterIP (interno)

ClusterIP é o tipo de Service padrão do Kubernetes. Ele cria um endereço IP virtual acessível apenas de dentro do cluster, sendo adequado para a comunicação entre serviços internos, como workloads de front-end, API e banco de dados. Clientes externos não conseguem acessar um Service ClusterIP diretamente, o que ajuda a isolar os serviços de backend das redes públicas.

Quando uma requisição é enviada ao endereço ClusterIP, o kube-proxy intercepta o tráfego e o encaminha para um dos Pods saudáveis por trás do Service. Ele atualiza automaticamente as regras de roteamento conforme os Pods são adicionados, removidos ou substituídos, garantindo que as requisições sejam distribuídas entre as réplicas disponíveis sem que as aplicações precisem acompanhar os endereços IP dos Pods.

A decisão de balanceamento normalmente usa implementações de rede baseadas em iptables, IPVS ou eBPF, dependendo da configuração do cluster. As aplicações se comunicam com um endpoint estável do Service enquanto o Kubernetes lida com as mudanças nos Pods subjacentes, tornando o ClusterIP a base da maior parte da comunicação interna entre serviços.

2. NodePort

Um Service NodePort expõe uma aplicação em uma porta estática em todos os nós do cluster Kubernetes. Os clientes podem acessar a aplicação enviando requisições para <NodeIP>:<NodePort>, permitindo que o tráfego externo alcance os workloads sem exigir um balanceador de carga dedicado na nuvem.

Depois que o tráfego chega a um nó, o kube-proxy roteia a requisição para um dos Pods selecionados pelo Service, mesmo que esse Pod esteja em execução em outro nó. O Kubernetes continua balanceando as requisições entre os Pods saudáveis conforme o número de réplicas muda, enquanto o NodePort permanece constante.

Como todos os nós escutam na mesma porta, os usuários podem se conectar a qualquer nó do cluster e alcançar a aplicação. O NodePort é comumente usado em ambientes de desenvolvimento, clusters on-premises ou como base para serviços de nível superior, como o LoadBalancer, embora expor aplicações diretamente via NodePorts seja menos comum em produção.

3. LoadBalancer

Um Service LoadBalancer se apoia no NodePort e integra o Kubernetes a um balanceador de carga externo fornecido por uma plataforma de nuvem ou infraestrutura compatível. Ele provisiona um endereço IP público ou privado que os clientes usam para acessar a aplicação sem se conectar diretamente a nós individuais do cluster.

O balanceador de carga externo distribui as conexões de entrada entre os nós do cluster. As requisições são então encaminhadas pelo Service NodePort correspondente, onde o kube-proxy seleciona um Pod de backend saudável. Isso proporciona tanto balanceamento no nível da infraestrutura, entre nós, quanto balanceamento no nível do Kubernetes, entre Pods.

A maioria dos serviços gerenciados de Kubernetes provisiona automaticamente balanceadores de carga nativos da nuvem de provedores como AWS, Azure ou Google Cloud quando esse tipo de Service é criado. Health checks garantem que o tráfego seja enviado apenas para nós saudáveis, enquanto o Kubernetes atualiza continuamente os endpoints de backend conforme os Pods escalam ou são substituídos.

4. Ingress

O Ingress fornece roteamento na camada 7 (HTTP/HTTPS) para várias aplicações por meio de um único ponto de entrada. Em vez de expor cada Service com seu próprio endereço IP externo, um recurso Ingress define regras de roteamento baseadas em hostnames, caminhos de URL ou outros atributos HTTP. Um Ingress controller, como o Traefik, implementa essas regras.

Quando um cliente envia uma requisição HTTP ou HTTPS, o Ingress controller avalia as regras de roteamento e encaminha a requisição ao Service Kubernetes apropriado. O Service então distribui o tráfego entre seus Pods de backend. Essa abordagem simplifica a exposição de aplicações e ainda suporta recursos como terminação TLS, redirecionamentos, autenticação e reescrita de requisições.

Como vários Services podem compartilhar o mesmo endpoint externo, o Ingress reduz o número de endereços IP públicos e balanceadores de carga necessários. Ele é comumente usado para expor aplicações web, APIs e microsserviços, oferecendo gerenciamento centralizado do tráfego HTTP e HTTPS.

5. Gateway API

A Gateway API é um padrão de rede mais recente do Kubernetes que oferece uma forma mais flexível e extensível de gerenciar o tráfego de aplicações. Ela separa a configuração de infraestrutura do roteamento de aplicações, permitindo que as equipes de plataforma gerenciem os gateways enquanto as equipes de aplicação definem como seus serviços recebem tráfego.

O tráfego entra primeiro em um Gateway, que representa o ponto de entrada da rede. Recursos de roteamento, como o HTTPRoute, especificam como as requisições devem ser correspondidas e encaminhadas aos Services do Kubernetes. Quando uma requisição chega ao Service selecionado, o Kubernetes a distribui entre os Pods disponíveis usando seus mecanismos padrão de balanceamento.

Em comparação com o Ingress, a Gateway API oferece controle mais granular sobre políticas de roteamento, divisão de tráfego e ambientes multi-tenant. Ela também suporta múltiplos protocolos além do HTTP, incluindo TCP e gRPC, sendo mais adequada para requisitos de rede complexos e implantações Kubernetes em larga escala.

LoadBalancer vs. Ingress vs. API Gateway no Kubernetes

A tabela a seguir resume as diferenças entre essas opções:

Casos de uso de load balancing no Kubernetes

Balanceamento interno entre serviços

O balanceamento interno entre serviços distribui o tráfego entre aplicações em execução dentro do mesmo cluster Kubernetes. Ele permite que os serviços se comuniquem por meio de endpoints estáveis, enquanto o Kubernetes roteia automaticamente as requisições para os pods disponíveis. Essa abordagem ajuda a manter o desempenho e a disponibilidade conforme os workloads escalam ou os pods são substituídos.

Tecnologias relevantes: Service do Kubernetes (ClusterIP), kube-proxy, redes baseadas em eBPF, service mesh, descoberta de serviços baseada em DNS.

Balanceamento externo

O balanceamento externo gerencia o tráfego que entra no cluster a partir de usuários, aplicações ou sistemas externos. Ele fornece um ponto de entrada público e distribui as requisições recebidas entre os serviços de backend saudáveis. Isso permite que as aplicações lidem com volumes maiores de tráfego enquanto permanecem disponíveis durante falhas, eventos de manutenção ou operações de escalonamento.

Tecnologias relevantes: Service LoadBalancer, balanceadores de camada 4, Ingress, Gateway API, terminação TLS.

Gerenciamento de tráfego norte-sul

O gerenciamento de tráfego norte-sul lida com o tráfego que flui entre clientes externos e os workloads em execução dentro do cluster. É comumente usado em aplicações públicas, APIs e integrações com parceiros. Além do load balancing, costuma incluir roteamento, aplicação de políticas de segurança, filtragem de tráfego e criptografia para controlar como as requisições externas acessam os serviços internos.

Tecnologias relevantes: Ingress, Gateway API, roteamento na camada 7, terminação TLS, políticas de autenticação e autorização, integração com web application firewall.

Gerenciamento de tráfego leste-oeste

O gerenciamento de tráfego leste-oeste foca na comunicação entre serviços dentro do cluster ou entre ambientes Kubernetes conectados. Em arquiteturas de microsserviços, as aplicações trocam requisições internamente com frequência, tornando a distribuição eficiente do tráfego crítica para desempenho e confiabilidade. Esse tipo de balanceamento também suporta observabilidade, políticas de segurança e controle de tráfego entre serviços.

Tecnologias relevantes: Service do Kubernetes, kube-proxy, service mesh, redes baseadas em eBPF, mTLS, políticas de tráfego, descoberta de serviços.

Balanceamento multi-cluster e global

O balanceamento multi-cluster e global distribui o tráfego entre vários clusters Kubernetes localizados em diferentes regiões, zonas de disponibilidade, provedores de nuvem ou data centers. Isso melhora a resiliência ao evitar que um único cluster se torne um ponto de falha e pode reduzir a latência ao direcionar os usuários para a localização mais adequada. É comumente usado para disaster recovery, aplicações globais e implantações em larga escala.

Tecnologias relevantes: Gateway API, balanceamento global, roteamento de tráfego baseado em DNS, redes multi-cluster, service mesh, failover de tráfego, geo-roteamento.

Exemplos de load balancing no Kubernetes

Os exemplos desta seção foram adaptados da documentação do Kubernetes.

Exemplo de Service no Kubernetes

O Deployment a seguir cria três réplicas de uma aplicação NGINX. Cada Pod recebe o rótulo app: nginx, o que permite que um Service do Kubernetes selecione os Pods e envie tráfego para eles.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10

Esse Deployment mantém três Pods NGINX em execução. Se um Pod for excluído ou falhar, o ReplicaSet do Deployment cria um Pod substituto. A readiness probe ajuda o Kubernetes a determinar quando cada Pod está pronto para receber tráfego por meio de um Service.

Exemplo de Service ClusterIP

O Service ClusterIP a seguir expõe o Deployment NGINX dentro do cluster. O Service seleciona os Pods com o rótulo app: nginx e encaminha o tráfego da porta 80 do Service para a porta 80 dos Pods selecionados.

apiVersion: v1
kind: Service
metadata:
  name: nginx-clusterip
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Esse Service é acessível de dentro do cluster. Outros Pods podem se conectar a ele usando o nome do Service, nginx-clusterip, desde que o DNS do cluster esteja disponível.

Exemplo de Service LoadBalancer

O Service a seguir expõe os mesmos Pods NGINX externamente usando um provedor de nuvem ou outro ambiente com suporte a balanceadores de carga externos.

apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Quando esse Service é criado em um ambiente compatível, o Kubernetes provisiona ou configura um balanceador de carga externo e registra o endereço externo no status do Service. O tráfego enviado ao endereço externo é encaminhado ao Service e, em seguida, aos Pods de backend correspondentes.

Exemplo de Ingress

O Ingress a seguir roteia o tráfego HTTP de example.com para o Service interno nginx-clusterip.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-clusterip
                port:
                  number: 80

Esse Ingress define regras de roteamento HTTP, mas só funciona se houver um Ingress controller em execução no cluster. O Ingress controller implementa o comportamento de roteamento e encaminha as requisições correspondentes ao Service de backend.

Exemplo de API Gateway

O exemplo a seguir usa a Gateway API do Kubernetes para rotear o tráfego HTTP por meio de um Gateway até o Service interno nginx-clusterip. A Gateway API é uma família de APIs de rede do Kubernetes para provisionamento dinâmico de infraestrutura e roteamento avançado de tráfego, e os recursos HTTPRoute podem corresponder a requisições HTTP e encaminhá-las aos Services do Kubernetes.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: nginx-gateway
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: api.example.com
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-api-route
spec:
  parentRefs:
    - name: nginx-gateway
  hostnames:
    - api.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: nginx-clusterip
          port: 80

Neste exemplo, o Gateway representa o ponto de entrada do API gateway, enquanto o HTTPRoute define como as requisições HTTP devem ser roteadas. As requisições enviadas para api.example.com/api são aceitas pelo listener do Gateway, correspondidas pela rota e encaminhadas ao Service nginx-clusterip. O Service então distribui o tráfego entre os Pods NGINX correspondentes.

Nota: este exemplo usa o NGINX Gateway Fabric como implementação da gateway class, que é diferente do controlador Ingress NGINX mantido pela comunidade.

Essa abordagem é semelhante ao Ingress, mas a Gateway API oferece um modelo mais expressivo e orientado a papéis. As equipes de infraestrutura podem gerenciar os recursos de Gateway, enquanto as equipes de aplicação gerenciam recursos de rota, como o HTTPRoute. Isso a torna útil para padrões de API gateway em que as equipes precisam de roteamento baseado em hostname, roteamento baseado em caminho, controle de políticas de tráfego e uma separação mais clara entre a configuração da plataforma e o roteamento das aplicações.