NodePort vs. LoadBalancer vs. Ingress: Escolhendo a Melhor Exposição de Serviço

Navegue pela escolha crítica de expor Serviços Kubernetes externamente comparando NodePort, LoadBalancer e Ingress. Este guia detalha a arquitetura, a camada operacional (L4 vs. L7), casos de uso e as principais diferenças de custo e complexidade para cada método. Aprenda quando usar o NodePort simples para testes, o LoadBalancer dedicado para serviços únicos ou o poderoso Ingress para roteamento centralizado e econômico na Camada 7 e ambientes complexos de múltiplos serviços.

27 visualizações

NodePort vs. LoadBalancer vs. Ingress: Escolhendo a Melhor Exposição de Serviço

Serviços Kubernetes são objetos fundamentais que fornecem rede estável a um conjunto dinâmico de Pods. Enquanto os serviços lidam com a comunicação interna do cluster, expor esses serviços externamente – permitindo que usuários ou aplicações externas interajam com eles – requer configuração específica. Escolher o método de exposição correto é crucial, impactando segurança, custo e complexidade.

Este artigo oferece uma comparação especializada dos três métodos principais para expor Serviços Kubernetes: NodePort, LoadBalancer e Ingress. Analisaremos os mecanismos, os casos de uso adequados e os fatores práticos para guiá-lo na seleção da solução ideal para suas aplicações conteinerizadas.


1. Tipo de Exposição de Serviço: NodePort

O tipo de serviço NodePort é a forma mais simples e primitiva de expor um serviço externamente. Ao definir um serviço como NodePort, o Kubernetes abre uma porta estática específica em cada Nó (Node) do cluster. Qualquer tráfego direcionado a essa porta em qualquer nó é roteado diretamente para o serviço.

Como o NodePort Funciona

  1. Uma porta aleatória dentro de um intervalo designado (padrão: 30000-32767) é selecionada automaticamente.
  2. Esta porta é aberta em todos os nós do cluster.
  3. O Serviço escuta nesta NodePort, encaminhando o tráfego para os Pods apropriados.

Para acessar a aplicação, você usa http://<Node_IP>:<NodePort>.

Casos de Uso e Limitações

Característica Descrição
Caso de Uso Ambientes de desenvolvimento, teste, ou onde o balanceamento de carga externo é tratado por um appliance externo, não-cloud.
Complexidade Muito Baixa.
Custo Zero (se ignorarmos os custos subjacentes da VM).
Limitação Requer gerenciamento manual de regras de firewall externas. IPs de Nó (Node IPs) são frequentemente dinâmicos. Restrição de intervalo de porta (30000-32767).

Exemplo de NodePort

apiVersion: v1
kind: Service
metadata:
  name: my-app-nodeport
spec:
  type: NodePort
  selector:
    app: my-web-app
  ports:
    - port: 80
      targetPort: 8080
      # Opcional: especifique uma NodePort, caso contrário uma é escolhida automaticamente
      # nodePort: 30001 

⚠️ Aviso: NodePort expõe o serviço através de todos os nós. Se um nó for removido ou seu IP for alterado, o acesso externo é interrompido. Geralmente, isso não é recomendado para ambientes de produção que dependem de estabilidade.


2. Tipo de Exposição de Serviço: LoadBalancer

O tipo de serviço LoadBalancer é o método padrão para expor aplicações à internet pública em ambientes de nuvem (AWS EKS, GCP GKE, Azure AKS).

Quando um serviço é definido como LoadBalancer, o Kubernetes provisiona automaticamente um balanceador de carga de nuvem dedicado de Camada 4 (L4) (por exemplo, AWS Classic ELB/NLB, Azure Load Balancer, GCP Network Load Balancer). Isso fornece um endereço IP externo estável e altamente disponível que roteia o tráfego diretamente para os Pods do serviço.

Integração com Provedores de Nuvem

O principal diferencial do LoadBalancer é a profunda integração com a infraestrutura de nuvem subjacente. O provedor de nuvem lida com o ciclo de vida do balanceador de carga, verificações de saúde (health checks) e roteamento.

Casos de Uso e Implicações de Custo

Característica Descrição
Caso de Uso Aplicações simples, voltadas para o público, que exigem um endereço IP estável e dedicado. Adequado para protocolos não-HTTP/S (TCP/UDP).
Complexidade Baixa (em termos de configuração).
Custo Alto. Cada serviço LoadBalancer provisiona um recurso de nuvem dedicado, frequentemente incorrendo em cobranças horárias.
Benefício Oferece alta disponibilidade imediata e verificações de saúde automáticas.

Exemplo de LoadBalancer

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

Após a criação, o cluster atribuirá um endereço IP externo (visível no status do serviço) gerenciado pelo provedor de nuvem.


3. Kubernetes Ingress: Roteamento de Camada 7

Ingress é fundamentalmente diferente de NodePort e LoadBalancer. Ingress não é um tipo de Serviço, mas sim um objeto de API que define regras para acesso externo, tipicamente HTTP e HTTPS (Camada 7).

O Ingress atua como um ponto de entrada central, permitindo roteamento sofisticado baseado em nomes de host (hostnames) e caminhos de URL (URL paths). Essa abordagem é essencial para gerenciar múltiplos serviços por trás de um único endereço IP.

O Papel do Ingress Controller

Para que as regras de Ingress funcionem, você deve primeiro implantar um Ingress Controller (por exemplo, Nginx, Traefik, Istio). O Controller observa as definições de recurso Ingress e configura um proxy reverso/balanceador de carga L7 subjacente com base nessas regras.

Crucialmente, o próprio Ingress Controller é geralmente exposto usando um único serviço LoadBalancer ou NodePort.

Funcionalidades Avançadas do Ingress

O Ingress se destaca quando você precisa de recursos avançados de gerenciamento de tráfego:

  1. Otimização de Custos: Use um único LoadBalancer de nuvem (para expor o Controller) em vez de um LoadBalancer por serviço de aplicação.
  2. Hospedagem Virtual (Virtual Hosting): Roteie o tráfego com base em nomes de host (api.example.com vai para o Serviço A; www.example.com vai para o Serviço B).
  3. Roteamento Baseado em Caminho (Path-Based Routing): Roteie o tráfego com base em caminhos de URL (/v1/users vai para o Serviço A; /v2/posts vai para o Serviço B).
  4. Terminação SSL/TLS: Lide com o gerenciamento de certificados e a descriptografia de forma centralizada.

Exemplo de Recurso Ingress

Este exemplo roteia o tráfego para api.example.com/v1 para o serviço my-api-v1.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: nginx # Especifique o controller em uso
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: my-api-v1
            port:
              number: 80
  # ... outras regras para diferentes serviços/hosts

4. Comparação e Guia de Seleção

Escolher o método ideal envolve ponderar fatores como ambiente, complexidade, conjunto de recursos e custo operacional.

Tabela de Comparação de Recursos

Característica NodePort LoadBalancer Ingress
Camada L4 (TCP/UDP) L4 (TCP/UDP) L7 (HTTP/S)
Estabilidade (IP) Instável (usa IP do Nó) Estável (IP Dedicado da Nuvem) Estável (Usa IP do Controller)
Custo Baixo (Sobrecarga operacional alta) Alto (Custo de recurso por serviço) Moderado (Um LoadBalancer para o Controller)
Lógica de Roteamento Simples encaminhamento de porta Simples encaminhamento de porta Nome de Host, Caminho, Terminação SSL
Dependência de Nuvem Nenhuma Alta Alta (Requer Controller exposto por LoadBalancer)
Pronto para Produção Não Sim (Aplicações Simples) Sim (Aplicações Complexas)

Critérios de Decisão: Escolhendo Seu Método de Exposição

  1. Apenas para Uso Interno ou Teste: Se você precisa apenas testar a conectividade dentro do seu cluster, ou se você gerencia o networking externo por conta própria (por exemplo, em um ambiente bare-metal), use NodePort.

  2. Para Exposição L4 Simples e Dedicada: Se sua aplicação usa protocolos não-HTTP (como protocolos TCP personalizados ou UDP) ou se você tem apenas uma única aplicação pública que precisa de acesso L4 dedicado e imediato, use LoadBalancer.

  3. Para Exposição L7 Complexa e Multi-Serviço: Se você tem múltiplos serviços para expor, requer roteamento baseado em caminho ou nome de host, precisa de terminação SSL centralizada, ou deseja minimizar os custos de nuvem compartilhando um único IP externo, use Ingress.

Melhor Prática: Para implantações de produção em ambientes de nuvem gerenciados, Ingress é geralmente a escolha preferencial. Ele fornece a sofisticação, centralização de segurança e eficiência de custos necessárias para gerenciar um número crescente de microsserviços.

Conclusão

O Kubernetes oferece um espectro de soluções para exposição de serviço, movendo-se do básico L4 NodePort, passando pelo L4 LoadBalancer integrado à nuvem, até as sofisticadas capacidades de roteamento L7 do Ingress. Ao entender a camada operacional, o modelo de custo e a lógica de roteamento exigida por cada método, os engenheiros podem projetar arquiteturas de rede escaláveis, seguras e econômicas para suas cargas de trabalho de produção.