3 min read

Desvendando os Services no Kubernetes: Guia Completo para Acesso e Comunicação no Cluster

Desvendando os Services no Kubernetes: Guia Completo para Acesso e Comunicação no Cluster

Services no Kubernetes: habilitando o acesso dentro do cluster

No Kubernetes, os Services são fundamentais para expor aplicações que rodam em pods. Eles proporcionam um ponto de acesso estável, abstraindo o conjunto dinâmico e efêmero de pods, garantindo assim descoberta, balanceamento de carga e comunicação consistente entre os componentes do cluster.

Neste artigo, vamos detalhar os principais tipos de Services (ClusterIP, NodePort e LoadBalancer), explicar o funcionamento do DNS interno via CoreDNS, mostrar como o Service descobre pods por meio de seletores e endpoints, além de compartilhar dicas práticas de troubleshooting para casos em que o Service não localiza os pods corretamente.

Tipos de Service

1. ClusterIP (padrão)

O que é: cria um IP interno acessível apenas dentro do cluster.

Uso: comunicação entre pods, serviços internos e componentes do cluster.

Características: não expõe o serviço fora do cluster e usa balanceamento simples entre os pods selecionados.

apiVersion: v1
kind: Service
metadata:
  name: meu-servico-interno
spec:
  type: ClusterIP
  selector:
    app: minha-aplicacao
  ports:
  - port: 80          # porta do Service
    targetPort: 8080  # porta do pod

O Service escuta na porta 80 e encaminha o tráfego para a porta 8080 dos pods que têm o label app=minha-aplicacao.

2. NodePort

O que é: abre uma porta estática (geralmente entre 30000‑32767) em cada nó do cluster.

Uso: permite acesso externo ao serviço usando o IP do node e a porta configurada.

Características: útil em ambientes de desenvolvimento ou em clusters sem balanceador externo; menos seguro para produção sem regras de firewall adequadas.

apiVersion: v1
kind: Service
metadata:
  name: meu-servico-nodeport
spec:
  type: NodePort
  selector:
    app: minha-aplicacao
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 31000   # porta fixa exposta nos nodes

A aplicação pode ser acessada via http://<IP-do-node>:31000.

3. LoadBalancer

O que é: provisiona automaticamente um balanceador de carga gerenciado pelo provedor de nuvem.

Uso: ideal para ambientes de produção em nuvem, aplicações externas e alta disponibilidade.

Características: cria IP público, regras de firewall e roteamento de acordo com o provider (AWS ELB, GCP LB, etc.).

apiVersion: v1
kind: Service
metadata:
  name: meu-servico-lb
spec:
  type: LoadBalancer
  selector:
    app: minha-aplicacao
  ports:
  - port: 80
    targetPort: 8080

O Kubernetes provisiona um IP público e um balanceador de carga para acesso direto.

DNS interno (CoreDNS) e descoberta de serviços

O Kubernetes inclui um serviço DNS interno, normalmente CoreDNS, que resolve nomes de serviços e pods dentro do cluster.

  • Cada Service recebe um registro DNS no formato <service-name>.<namespace>.svc.cluster.local.
  • Os pods podem se comunicar usando apenas o nome do Service, sem precisar conhecer IPs que mudam dinamicamente.

Exemplo de uso:

$ curl http://meu-servico-interno.dev.svc.cluster.local
# ou, se estiver no mesmo namespace:
$ curl http://meu-servico-interno

Esse mecanismo simplifica a arquitetura de microsserviços.

Seletores, endpoints e troubleshooting

Seletores

O campo selector define quais pods pertencem ao Service por meio de um mapa de labels.

selector:
  app: minha-aplicacao
  role: backend

Só serão incluídos no Service os pods que possuam ambos os labels app=minha-aplicacao e role=backend.

Endpoints

Endpoints são recursos internos que armazenam os IPs reais dos pods que atendem ao Service. Eles são atualizados automaticamente pelo Kubernetes.

$ kubectl get endpoints meu-servico-interno

O comando mostra os IPs dos pods que fazem parte do Service.

Problemas comuns: Service não encontra pods

Sintoma Causa provável Como verificar
Service não encaminha tráfego Labels não coincidem kubectl get pods --show-labels
kubectl describe svc <svc>
Endpoints vazios Pods não Ready kubectl get pods
kubectl describe pod <pod>
Nenhum tráfego interno Namespaces diferentes Verifique o namespace dos pods e do Service (kubectl get svc -n <ns>).
Comunicação bloqueada NetworkPolicy ou firewall Revise as políticas de rede (kubectl get networkpolicy) e regras de firewall do provedor.

Se kubectl get endpoints <svc> retornar vazio, o Service não está encontrando pods – comece conferindo o selector e o estado dos pods.

Resumo rápido e dicas práticas

Conceito Descrição / Uso
ClusterIP IP interno; comunicação intra‑cluster (padrão).
NodePort Porta estática em cada node; acesso externo simples.
LoadBalancer Balanceador externo provisionado pelo cloud provider; produção.
CoreDNS DNS interno que resolve <svc>.<ns>.svc.cluster.local.
selector Mapeia labels dos pods ao Service.
endpoints Lista de IPs reais dos pods selecionados.
Problemas comuns Selector errado, pods não prontos, namespace diferente, políticas de rede.

Conclusão

Services são a espinha dorsal da comunicação no Kubernetes, abstraindo a natureza volátil dos pods e oferecendo estabilidade tanto para clientes internos quanto externos. Conhecer os tipos de Service, o funcionamento do DNS interno e saber diagnosticar problemas de seleção de pods garante alta disponibilidade e integridade das aplicações.

No próximo conteúdo, abordaremos ConfigMaps, Secrets e o gerenciamento de configuração dinâmica em clusters Kubernetes.

Geisler