[Dúvida] Diferença entre port e nodePort no Service LoadBalancer

Estou usando Kubernetes localmente através do Docker Desktop no macOS.

Para testar o acesso a um Pod rodando nginx, criei um Service do tipo NodePort, e consegui acessá-lo via navegador com http://localhost:<nodePort>.

Isso funcionou normalmente e o nginx foi exibido.

Em seguida, quis testar o acesso ao mesmo Pod usando um Service do tipo LoadBalancer. Sei que esse tipo de serviço normalmente depende de um provedor de nuvem (como GKE, EKS, etc.) ou de algo como o MetalLB para funcionar localmente como um verdadeiro balanceador de carga.

No entanto, mesmo sem esses componentes, o Docker Desktop parece mapear o LoadBalancer para localhost. O manifesto que utilizei foi:

ports:
- port: 81
  targetPort: 80
  nodePort: 30000

Neste cenário:

Acessar localhost:30000 não funcionou Acessar localhost:81 funcionou perfeitamente

Por que no Service do tipo LoadBalancer o acesso é feito pela porta definida em port, enquanto o nodePort não funciona diretamente como acontece no serviço do tipo NodePort?

E mais: Qual é o papel do nodePort em um Service do tipo LoadBalancer? Existe diferença do seu comportamento em ambientes locais usando Docker Desktop com uma única máquina e em ambientes com um cluster verdadeiro?

Agradeço desde já qualquer explicação que possa esclarecer essa diferença de comportamento!

Olá Luiz, tudo bem?

Ótimas perguntas, e sua observação está correta!

Por que no Service do tipo LoadBalancer o acesso é feito pela porta port (81) e o nodePort não funciona diretamente, diferente do Service do tipo NodePort? • Service NodePort: expõe o serviço em todas as interfaces do nó (host) na porta definida em nodePort. Assim, você acessa o serviço pelo IP do nó (ou localhost, em cluster local) + porta nodePort. Exemplo: localhost:30000. • Service LoadBalancer: em provedores de nuvem, cria um balanceador externo que encaminha para a porta do serviço (port) do cluster, e o nodePort serve como porta intermediária usada internamente entre o load balancer e os nós.

No Docker Desktop, que simula um cluster Kubernetes local, não existe um balanceador real, mas ele faz um mapeamento simplificado: ele expõe a porta do Service (port: 81) diretamente no localhost, como se fosse o IP externo do LoadBalancer.

Por isso: • Você acessa localhost:81 e funciona porque o Docker Desktop mapeia essa porta do LoadBalancer direto pra sua máquina. • Já o nodePort (30000) nesse caso não fica exposto da mesma forma, pois o Service é do tipo LoadBalancer e o Docker Desktop não simula o nodePort separadamente para LoadBalancer.

⸻

Qual é o papel do nodePort em um Service LoadBalancer?

O nodePort é a porta onde o serviço está disponível em cada nó do cluster, funcionando como um “canal” para o LoadBalancer encaminhar o tráfego para o serviço interno.

Em ambientes de nuvem ou clusters reais, o balanceador externo usa essa porta para direcionar o tráfego para os nós.

⸻

Diferença entre ambientes locais (Docker Desktop) e clusters verdadeiros? • Em clusters reais: O LoadBalancer cria um IP público e um balanceador externo que encaminha tráfego para o nodePort em cada nó. O nodePort é essencial para esse roteamento. • No Docker Desktop local: Não há balanceador real, o Docker Desktop simplifica isso expondo a porta do Service direto na máquina local (via port), ignorando o comportamento do nodePort para o LoadBalancer.