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

O Kubernetes atribui IPs temporários aos Pods e, em seguida, usa Serviços para fornecer uma maneira estável de alcançá-los. Dentro do cluster, um Serviço ClusterIP normal geralmente é suficiente. A questão se torna mais interessante quando algo fora do cluster precisa se conectar.

Os três nomes que aparecem com mais frequência são NodePort, LoadBalancer e Ingress. Eles estão relacionados, mas não são intercambiáveis. NodePort abre uma porta em cada nó. LoadBalancer solicita ao provedor de infraestrutura um balanceador de carga externo. Ingress define regras de roteamento HTTP e precisa de um controlador Ingress para tornar essas regras realidade.

---

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

O tipo de serviço NodePort é a maneira mais simples e primitiva de expor um serviço externamente. Quando você define um serviço como NodePort, o Kubernetes abre uma porta estática específica em cada Nó 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://<IP_do_No>:<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 dispositivo externo não baseado em nuvem.
Complexidade	Muito Baixa.
Custo	Zero (se ignorar os custos subjacentes da VM).
Limitação	Requer gerenciamento manual de regras de firewall externas. Os IPs dos nós são frequentemente dinâmicos. Restrição de intervalo de portas (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: especificar um NodePort, caso contrário, um é escolhido automaticamente
      # nodePort: 30001 

Aviso: NodePort expõe o serviço através dos IPs dos nós e de uma porta alta. Pode ser útil por trás do seu próprio balanceador de carga externo, especialmente em bare metal, mas é estranho como interface pública para uma aplicação web de produção.

---

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 solicita à integração de balanceador de carga do cluster que provisione um balanceador de carga externo. Em clusters de nuvem gerenciados, isso geralmente significa um balanceador de carga L4 de nuvem. Em clusters bare-metal, pode significar um projeto como MetalLB ou outra integração local. O resultado é geralmente um endereço externo estável que encaminha o tráfego para o Serviço.

Integração com o Provedor de Nuvem

O principal diferencial do LoadBalancer é a integração profunda com a infraestrutura de nuvem subjacente. O provedor de nuvem gerencia o ciclo de vida do balanceador de carga, verificações de saúde 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 dedicado e estável. Adequado para protocolos não HTTP/S (TCP/UDP).
Complexidade	Baixa (em termos de configuração).
Custo	Frequentemente maior em ambientes de nuvem porque cada Serviço pode criar um recurso de balanceador de carga separado.
Benefício	Fornece 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. Ingress do Kubernetes: Roteamento na Camada 7

O Ingress é fundamentalmente diferente do NodePort e do 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 e caminhos de URL. Esta abordagem é essencial para gerenciar múltiplos serviços por trás de um único endereço IP.

O Papel do Controlador Ingress

Para que as regras do Ingress funcionem, você deve primeiro implantar um Controlador Ingress como ingress-nginx, Traefik, HAProxy ou um controlador do provedor de nuvem. Malhas de serviço como Istio também podem fornecer gerenciamento de tráfego no estilo gateway, mas não são a mesma coisa que a API básica de Ingress do Kubernetes.

O próprio controlador Ingress geralmente é exposto usando um único Serviço LoadBalancer ou NodePort.

Recursos Avançados 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 Controlador) em vez de um LoadBalancer por serviço de aplicação.
2. Hospedagem Virtual: Roteie o tráfego com base em nomes de host (api.exemplo.com vai para o Serviço A; www.exemplo.com vai para o Serviço B).
3. Roteamento Baseado em Caminho: Roteie o tráfego com base em caminhos de URL (/v1/usuarios vai para o Serviço A; /v2/posts vai para o Serviço B).
4. Terminação SSL/TLS: Gerencie certificados e descriptografia centralmente.

Exemplo de Recurso Ingress

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

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

---

4. Guia de Comparação e 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 de Nuvem Dedicado)	Estável (usa IP do Controlador)
Custo	Baixo (Alta sobrecarga operacional)	Alto (Custo de recurso por serviço)	Moderado (Um LoadBalancer para o Controlador)
Lógica de Roteamento	Encaminhamento de porta simples	Encaminhamento de porta simples	Nome do Host, Caminho, Terminação SSL
Dependência de Nuvem	Nenhuma	Depende da integração do provedor	Depende do controlador e método de exposição
Pronto para Produção	Às vezes, geralmente atrás de outro balanceador de carga	Sim para exposição L4 simples	Sim para roteamento HTTP/S

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

1. Para Uso Interno ou Apenas Testes: Se você precisa apenas testar a conectividade dentro do seu cluster, ou se gerencia a rede externa 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 imediato e dedicado, use LoadBalancer.

3. Para Exposição L7 Complexa com Múltiplos Serviços: Se você tem vários 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.

Para muitas aplicações HTTP/S de produção, o Ingress é a escolha usual porque centraliza certificados e roteamento. Para bancos de dados, corretores de mensagens, servidores de jogos, serviços TCP brutos ou qualquer coisa que não seja realmente HTTP, um Serviço LoadBalancer pode ser mais claro. Para clusters bare-metal, o NodePort ainda pode fazer parte do design, mas geralmente é colocado atrás de um balanceador de carga externo adequado ou regra de firewall.

Como Eles se Encaixam em Clusters Reais

Uma parte confusa é que essas opções podem ser empilhadas umas sobre as outras. Um objeto Ingress não expõe pacotes por si só. O controlador recebe tráfego de alguma forma, e esse "alguma forma" geralmente é um Serviço LoadBalancer em um cluster de nuvem:

Internet
  -> Balanceador de Carga da Nuvem
  -> Serviço tipo LoadBalancer para ingress-nginx
  -> Pods do Controlador Ingress
  -> Regra Ingress
  -> Serviço ClusterIP
  -> Pods da Aplicação

Em bare metal, o caminho pode usar NodePort:

Internet ou rede do escritório
  -> Balanceador de carga / firewall externo
  -> NodeIP:NodePort
  -> Pods do Controlador Ingress
  -> Serviço da Aplicação

É por isso que dizer "use Ingress em vez de LoadBalancer" é um pouco impreciso. O Ingress geralmente ainda usa um balanceador de carga, mas permite que muitas aplicações HTTP compartilhem um ponto de entrada.

Exemplos Práticos

Use NodePort quando estiver depurando um cluster de laboratório, expondo um serviço temporariamente a uma rede privada ou integrando-se a hardware de balanceamento de carga que você já gerencia. Não faça os usuários memorizarem https://app.exemplo.com:31427 a menos que seja realmente uma ferramenta interna.

Use LoadBalancer quando um serviço precisar de um endereço externo estável e o encaminhamento L4 for suficiente. Uma API TCP pública, um serviço UDP ou um endpoint de administração interno único podem ser mais simples desta forma. Também é útil quando o protocolo da aplicação não se encaixa no roteamento normal de host/caminho HTTP.

Use Ingress quando você tiver aplicações web. Se api.exemplo.com, docs.exemplo.com e app.exemplo.com estiverem todos no mesmo cluster, o Ingress oferece um único lugar para gerenciar o roteamento de host e TLS. Adicione o cert-manager, e a renovação de certificados pode se tornar um fluxo de trabalho normal do cluster em vez de uma tarefa manual de servidor.

Verificações de Segurança e Operações

O objeto de exposição é apenas uma parte da decisão de produção. Você também precisa perguntar quem pode alcançar o endpoint, onde o TLS termina, como os IPs de origem são preservados e como as falhas são observadas.

Com NodePort, verifique as regras de firewall cuidadosamente. O Kubernetes pode abrir a porta em cada nó, mas sua rede ainda decide se o mundo exterior pode alcançá-la. Em ambientes de nuvem, grupos de segurança ou regras de firewall geralmente precisam permitir o intervalo NodePort. Em bare metal, a mesma preocupação pode estar em um firewall de perímetro. Se você pretende que apenas uma ferramenta de administração privada seja acessível a partir de uma VPN, aplique isso fora do Kubernetes também.

Com LoadBalancer, inspecione as anotações específicas do provedor. Elas geralmente controlam se o balanceador de carga é interno ou voltado para a internet, qual protocolo ele usa, qual caminho de verificação de saúde ele sonda e se preserva o IP de origem do cliente. Esses detalhes variam por provedor, portanto, não presuma que um manifesto copiado de uma nuvem se comportará da mesma forma em outra.

Com Ingress, o centro operacional se move para o controlador. Você precisa de logs e métricas dos pods do controlador, não apenas dos pods da aplicação. Se uma rota falhar, o Serviço e os Pods podem estar saudáveis enquanto o controlador rejeitou a regra, usou a classe de ingress errada, perdeu um segredo TLS ou roteou para o caminho de backend errado. Uma lista de verificação rápida ajuda:

kubectl get ingress
kubectl describe ingress example-ingress
kubectl get svc -n ingress-nginx
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

Além disso, seja claro sobre o TLS. O Ingress geralmente termina o HTTPS no controlador e envia HTTP para o Serviço de backend. Isso é bom para muitos clusters internos, mas algumas equipes exigem criptografia até o pod da aplicação. Se esse for seu requisito, configure o TLS de backend intencionalmente, em vez de presumir que o Ingress o fornece automaticamente.

Modos Comuns de Falha

Se um NodePort funciona de um nó, mas não de outro, verifique se o kube-proxy ou o CNI do cluster está saudável no nó com falha. Verifique também se o firewall externo permite tráfego para cada IP de nó que você espera usar.

Se um Serviço LoadBalancer permanecer em Pending, o cluster provavelmente não consegue provisionar o balanceador de carga externo. No Kubernetes gerenciado, isso pode significar falta de integração do controlador de nuvem, permissões, tags de sub-rede, cota ou configurações específicas do provedor. No Kubernetes bare-metal, geralmente significa que não há implementação de balanceador de carga instalada.

Se um Ingress retornar uma página de backend padrão ou um 404 do controlador, a solicitação chegou ao controlador, mas não correspondeu à sua regra de host ou caminho. Verifique o DNS, o cabeçalho Host, ingressClassName, o tipo de caminho e se o nome do Serviço e a porta estão corretos. Se você obtiver um certificado TLS para o nome de host errado, verifique o segredo referenciado pelo Ingress e se outra regra de Ingress está reivindicando o mesmo host.

Um Atalho Simples para Decisão

Comece pelo protocolo. Se for HTTP ou HTTPS e mais de um aplicativo puder eventualmente compartilhar o ponto de entrada, use Ingress. Se for TCP ou UDP bruto e precisar de um endereço externo estável, use LoadBalancer. Se você estiver testando, integrando com seu próprio equipamento de rede ou construindo um caminho bare-metal, o NodePort pode fazer parte da resposta.

Em seguida, verifique o modelo operacional. Uma equipe pequena executando uma API pública pode preferir um LoadBalancer porque é óbvio e fácil de depurar. Uma equipe de plataforma que hospeda dezenas de serviços web geralmente preferirá o Ingress porque o roteamento compartilhado, certificados e políticas são mais importantes do que a camada extra do controlador.

Notas Finais

Escolha com base no protocolo e nas operações, não em qual objeto parece mais avançado. NodePort é um bloco de construção. LoadBalancer é acesso L4 externo direto. Ingress é roteamento HTTP/S através de um controlador. Em um cluster pequeno, todos os três podem aparecer no mesmo design, e tudo bem, desde que cada um tenha um trabalho claro.