Escolhendo o Tipo de Serviço Kubernetes Correto: ClusterIP vs NodePort vs LoadBalancer

Escolher o tipo de Serviço Kubernetes correto decide quem pode alcançar seu aplicativo e como o tráfego chega até ele. Escolha o errado e você pode acabar com um aplicativo inacessível, superexposto ou apoiado por recursos de nuvem que você não precisava.

Este guia fornece uma comparação abrangente dos três tipos fundamentais de Serviço Kubernetes: ClusterIP, NodePort e LoadBalancer. Ao entender o caso de uso, o mecanismo de implementação e as compensações associadas para cada tipo, você pode tomar decisões informadas que se alinham perfeitamente com os requisitos de rede do seu aplicativo, garantindo que tanto a comunicação interna quanto a acessibilidade externa sejam gerenciadas de forma eficaz.

Entendendo os Serviços Kubernetes

Antes de mergulhar nos tipos específicos, é crucial lembrar o papel de um Serviço Kubernetes. Os Pods são efêmeros; seus endereços IP mudam à medida que são criados, destruídos ou reagendados. Um Serviço fornece um endpoint estável (um endereço IP fixo e um nome DNS) para um conjunto de Pods que mudam dinamicamente, permitindo comunicação confiável dentro do cluster.

Os Serviços são definidos usando um manifesto de objeto Service, tipicamente especificando um selector para encontrar os Pods relevantes e um type para definir como esse Serviço é exposto.

ClusterIP: Comunicação Interna

ClusterIP é o tipo de Serviço padrão e mais básico. Ele expõe o Serviço em um endereço IP interno dentro do cluster. Este Serviço só é acessível de dentro do próprio cluster.

Casos de Uso para ClusterIP

Serviços de Backend: Ideal para bancos de dados, APIs internas, camadas de cache ou microsserviços que só precisam se comunicar com outros serviços ou aplicativos frontend executados dentro do mesmo cluster Kubernetes.
Descoberta Interna: Ele aproveita o DNS interno do Kubernetes para fornecer nomes de descoberta de serviço estáveis (por exemplo, my-database.namespace.svc.cluster.local).

Detalhes de Implementação

Quando um serviço ClusterIP é criado, o Kubernetes atribui a ele um endereço IP virtual que só é roteável dentro da estrutura de rede do cluster. O tráfego externo não pode alcançar este IP diretamente.

Manifesto de Exemplo (ClusterIP):

apiVersion: v1
kind: Service
metadata:
  name: internal-api
spec:
  selector:
    app: backend-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

Dica: Se você está apenas construindo um sistema distribuído onde todos os componentes residem dentro do cluster, ClusterIP é a escolha mais segura e eficiente, pois evita exposição externa desnecessária.

NodePort: Expondo Serviços Através dos Nós do Cluster

NodePort é a maneira mais simples de expor um Serviço externamente. Ele abre uma porta específica em cada Nó (VM ou máquina física) no cluster e roteia o tráfego externo que chega nessa porta para o Serviço.

Casos de Uso para NodePort

Desenvolvimento e Teste: Útil para testar rapidamente serviços acessíveis externamente durante o desenvolvimento, quando uma configuração completa de balanceador de carga em nuvem é exagerada.
Ambientes Não-Nuvem: Essencial em instalações Kubernetes bare-metal ou on-premises onde integrações nativas de balanceamento de carga em nuvem não estão disponíveis.

Detalhes de Implementação

Quando um serviço NodePort é criado, o Kubernetes seleciona uma porta estática na faixa configurada (o padrão é 30000–32767) em cada nó. O Serviço expõe o aplicativo via:

http://<NodeIP>:<NodePort>

Se você tem três nós com IPs 10.0.0.1, 10.0.0.2 e 10.0.0.3, e o NodePort é 30080, você pode acessar o serviço através de qualquer um desses três IPs na porta 30080.

Manifesto de Exemplo (NodePort):

apiVersion: v1
kind: Service
metadata:
  name: test-web-app
spec:
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30080 # Opcional: Especifique a porta externa, ou o Kubernetes escolhe uma
  type: NodePort

Aviso: Como o serviço é exposto em todos os nós, sua camada de roteamento externa ainda precisa evitar nós não saudáveis. A faixa padrão do NodePort é 30000-32767, embora os administradores do cluster possam configurar uma faixa diferente.

LoadBalancer: Exposição Externa Nativa da Nuvem

LoadBalancer expõe um Serviço através de um balanceador de carga externo quando seu cluster tem uma integração que pode provisionar um. É comum em plataformas Kubernetes gerenciadas em nuvem. Em muitas configurações de produção, você também pode colocar um Ingress ou Gateway na frente de vários Serviços internos em vez de criar um balanceador de carga por aplicativo.

Casos de Uso para LoadBalancer

Implantações de Produção: Fornece acesso externo robusto e altamente disponível que se integra perfeitamente com a infraestrutura do provedor de nuvem.
Gerenciamento Automático de IP: Ele abstrai a necessidade de conhecer IPs de Nó individuais ou gerenciar conflitos de porta.

Detalhes de Implementação

Quando um Serviço do tipo LoadBalancer é criado em um ambiente suportado, o gerenciador de controlador de nuvem ou o controlador de balanceador de carga provisiona um balanceador de carga externo e o configura para rotear o tráfego para o Serviço.

O endereço externo é atribuído pelo provedor. Pode ser estável durante a vida útil do Serviço, mas nem sempre é um IP estático reservado, a menos que você configure isso através de configurações específicas do provedor.

Manifesto de Exemplo (LoadBalancer):

apiVersion: v1
kind: Service
metadata:
  name: public-web-service
spec:
  selector:
    app: public-facing
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Quando isso é criado, a saída (usando kubectl get svc) mostrará um IP externo atribuído:

NAME                  TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
public-web-service    LoadBalancer   10.96.45.11   34.120.200.55    80:30021/TCP   1m

O aplicativo agora está acessível via http://34.120.200.55.

Melhores Práticas: Para HTTPS, use o padrão que sua plataforma suporta melhor: anotações de balanceador de carga em nuvem, um controlador Ingress ou a API Kubernetes Gateway. Mantenha a configuração TLS em uma camada bem gerenciada em vez de espalhá-la por todos os Pods.

Tabela de Comparação Resumida

Característica	ClusterIP	NodePort	LoadBalancer
Uso Principal	Comunicação interna de serviço	Acesso externo simples (Teste/Bare-metal)	Produção, Acesso externo nativo da nuvem
Alcance	Apenas dentro do cluster	Cada nó em uma porta estática (30000-32767)	IP externo gerenciado pelo provedor de nuvem
Estabilidade do IP	IP interno estável	IPs de nó estáveis, mas requer conhecimento da porta
Dependência de Nuvem	Nenhuma	Nenhuma	Requer uma integração de balanceador de carga
Custo	Sem balanceador de carga externo	Usa recursos do nó	Geralmente cobrado como recursos de balanceador de carga externo
Complexidade de Configuração	Mais baixa	Baixa	Moderada (Requer configuração de nuvem)

Conclusão

Selecionar o tipo de Serviço correto é um passo fundamental na rede Kubernetes:

Comece Interno (ClusterIP): Se seu serviço nunca precisa ser acessado de fora do cluster, use sempre ClusterIP. Isso minimiza a superfície de ataque e a sobrecarga.
Teste/Bare-metal (NodePort): Se você precisa de testes externos básicos ou está executando Kubernetes fora de um ambiente de nuvem importante, NodePort fornece acesso externo imediato, embora menos robusto.
Produção em Nuvem (LoadBalancer): Para qualquer aplicativo de produção hospedado em AWS, GCP ou Azure que exija um ponto de entrada externo durável, estável e dedicado, LoadBalancer é a escolha correta, aproveitando a infraestrutura de nuvem para resiliência.

Ao alinhar o tipo de Serviço com a acessibilidade necessária e o ambiente de implantação, você garante desempenho, segurança e integração ideais dentro de sua arquitetura de orquestração de contêineres.