Services e networking no Kubernetes: como workloads se encontram
Entenda por que o IP de um Pod não é uma identidade durável, como Services e DNS criam pontos estáveis de comunicação e onde entram ClusterIP, NodePort, LoadBalancer, Ingress e Gateway API.
No conteúdo anterior, vimos que Pods são unidades substituíveis. Um Pod pode desaparecer porque falhou, porque um Deployment iniciou um rollout, porque houve mudança de escala ou porque o nó onde ele estava deixou de estar disponível.
Essa característica é essencial para a reconciliação do Kubernetes, mas cria imediatamente outro problema: se as instâncias mudam, como uma parte da aplicação encontra outra sem depender da identidade de um Pod específico?
A resposta não começa com portas, YAML ou comandos. Começa com a diferença entre instância e serviço.
Uma instância pode nascer e morrer. Um serviço representa uma capacidade que a aplicação espera continuar encontrando apesar dessas substituições.
O problema: o IP do Pod não é uma identidade durável
Quando um Pod recebe conectividade no cluster, ele passa a ter um endereço de rede. É tentador imaginar que outro componente poderia simplesmente guardar esse IP e usá-lo como destino.
Isso funciona até o Pod desaparecer.
O substituto pode receber outro endereço. Um Deployment pode aumentar de três para seis réplicas. Uma atualização pode remover gradualmente os Pods antigos enquanto cria novos. Um Pod pode deixar de estar pronto para receber tráfego antes mesmo de ser removido.
Se cada consumidor precisasse acompanhar essas mudanças por conta própria, teríamos recriado um sistema de descoberta manual em cima de uma plataforma que justamente tenta tornar workloads substituíveis.
consumidor
↓
IP de um Pod específico
↓
Pod desaparece
↓
referência fica inválida
O problema não é que IP seja inútil. O problema é usar o endereço de uma instância efêmera como se ele fosse a identidade permanente de uma capacidade da aplicação.
Uma API pode ter cinco Pods hoje e oito amanhã. Para quem consome essa API, o que deveria permanecer estável é a ideia de “serviço da API”, não a lista manual de endereços das réplicas atuais.
Service como ponto estável sobre workloads substituíveis
É para essa separação que existe o objeto Service.
Em alto nível, um Service oferece um ponto lógico estável para alcançar um conjunto de backends. Em cenários comuns, esses backends são Pods identificados por labels, e o Kubernetes mantém EndpointSlices representando os endpoints que correspondem ao serviço.
O modelo mental é este:
consumidores
↓
Service
↓
conjunto atual de endpoints
↓ ↓ ↓
Pod A Pod B Pod C
Se Pod B desaparece e um novo Pod D assume seu lugar, o consumidor não precisa ser reconfigurado para conhecer a nova réplica. A associação entre Service e endpoints é atualizada pelo sistema.
Essa abstração é importante porque preserva duas ideias ao mesmo tempo:
- os Pods continuam descartáveis e substituíveis;
- a capacidade oferecida pelo conjunto continua encontrável por um ponto estável.
Service não torna um Pod permanente. Ele evita que consumidores precisem tratar a identidade de cada Pod como permanente.
Também não significa que todo Service seja automaticamente público. Na verdade, o modelo mais básico é justamente o contrário: comunicação estável dentro do cluster.
ClusterIP como modelo base de tráfego interno
ClusterIP é o tipo padrão de Service no Kubernetes. Ele representa bem o primeiro caso que vale entender: um componente interno precisa alcançar outro componente interno sem conhecer cada backend individualmente.
Imagine uma aplicação com frontend, API e um serviço de processamento.
O frontend não deveria carregar uma lista de IPs dos Pods da API. A API não deveria precisar saber em qual nó cada processador está rodando. Cada consumidor fala com o Service correspondente, enquanto a plataforma mantém a relação com os endpoints atuais.
frontend
↓
Service da API
↓
Pods da API
API
↓
Service do processamento
↓
Pods de processamento
O endereço de um ClusterIP é pensado para ser acessível dentro da rede do cluster. Isso o torna uma boa abstração base para comunicação serviço-a-serviço interna.
Outros tipos de Service adicionam formas de exposição sobre essa base, mas aprender Kubernetes começando por NodePort ou por um load balancer externo costuma inverter a ordem pedagógica. Primeiro vem o problema da identidade estável; depois vem a decisão de quem precisa acessar aquela capacidade e de onde.
Descoberta por DNS: nomes estáveis em vez de decorar endereços
Mesmo que um Service possua um endereço virtual estável, ainda seria ruim espalhar IPs pela configuração das aplicações.
Kubernetes normalmente combina Services com DNS do cluster. O DNS publica registros que permitem aos workloads encontrar Services por nomes consistentes.
Em vez de uma aplicação depender de algo como:
10.x.y.z
ela pode depender conceitualmente de um nome de serviço, respeitando namespace e domínio do cluster.
Isso muda a natureza da dependência. A aplicação passa a conhecer o nome lógico do destino, enquanto a infraestrutura resolve onde aquele destino está naquele ambiente.
Dentro do mesmo namespace, nomes mais curtos podem ser resolvidos conforme a configuração de DNS do Pod. Entre namespaces, o nome precisa deixar mais claro onde o Service está. O detalhe importante aqui não é memorizar o formato completo; é entender que Kubernetes oferece descoberta baseada em nomes para evitar que consumidores sejam acoplados a endereços de instâncias.
Essa é a mesma razão pela qual DNS é tão importante fora de Kubernetes: nomes desacoplam quem consome de detalhes de endereçamento que podem mudar.
Como o tráfego chega aos backends
Existe uma diferença entre descobrir o Service e encaminhar tráfego para um endpoint saudável daquele Service.
O DNS normalmente leva o consumidor ao endereço do Service. A implementação de service proxying do cluster — por exemplo, kube-proxy ou mecanismos equivalentes oferecidos por algumas soluções de rede — cuida do encaminhamento para endpoints associados.
O consumidor não precisa escolher manualmente um Pod.
Essa abstração também permite que a lista de backends mude sem alterar a configuração dos clientes. Um rollout pode substituir réplicas; scaling pode adicionar ou remover Pods; readiness pode influenciar quais endpoints estão aptos a receber tráfego.
Aqui vale uma distinção importante:
Service discovery não é health check de negócio.
O sistema pode saber quais endpoints estão prontos segundo o contrato técnico configurado e ainda assim a aplicação apresentar erros lógicos, latência alta ou dependências degradadas. O artigo final do 2B vai conectar readiness, liveness, scaling, rollout e observabilidade justamente para mostrar esse limite.
NodePort e LoadBalancer: posicionamento, não receita
Depois de entender comunicação interna, fica mais fácil posicionar os tipos usados para exposição além da rede interna.
Um Service NodePort abre uma porta nos nós do cluster e encaminha tráfego recebido nela para o Service. Ele pode ser útil como componente de uma arquitetura de exposição ou em ambientes específicos, mas não é sinônimo de “a forma correta de publicar aplicações Kubernetes”.
Um Service LoadBalancer, quando existe integração compatível com a infraestrutura, solicita ou integra um balanceador externo capaz de encaminhar tráfego para o Service. Em ambientes de cloud isso frequentemente se conecta ao load balancer oferecido pelo provedor; em outros ambientes, a implementação depende da plataforma disponível.
O ponto deste artigo não é ensinar qual campo configurar. É separar responsabilidades:
ClusterIP
→ acesso estável dentro do cluster
NodePort
→ exposição por porta dos nós
LoadBalancer
→ integração com um balanceador externo
Essas opções não resolvem por si só roteamento HTTP por hostname, caminhos, políticas avançadas ou a organização de múltiplas aplicações atrás de uma mesma borda.
É aí que aparece outra camada.
Ingress e Gateway API: a camada de entrada vem depois do Service
Para tráfego HTTP/HTTPS entrando no cluster, Kubernetes possui abstrações que conseguem expressar regras mais próximas da camada de aplicação, como hostnames e caminhos.
Ingress é a API histórica para esse problema. Ela continua estável e suportada, mas o projeto Kubernetes declara sua API congelada e recomenda Gateway API para novos recursos e evolução dessa camada.
Gateway API oferece um modelo mais expressivo e orientado a papéis, separando conceitos como a classe da infraestrutura, a instância de gateway e as rotas que apontam para backends — frequentemente Services.
A relação conceitual pode ser vista assim:
Internet / rede externa
↓
Ingress ou Gateway/Route
↓
Service
↓
Pods
Isso não significa que toda aplicação precisa de Gateway API. Nem que você deve migrar um Ingress existente só porque existe uma API mais nova. A decisão depende da implementação disponível e das necessidades de roteamento.
O que importa para o modelo mental é que Service e camada de entrada resolvem problemas diferentes. O Service estabiliza o acesso a backends. Ingress/Gateway organizam como tráfego externo, especialmente HTTP e HTTPS, chega aos Services adequados.
Onde entra CNI
Até aqui falamos sobre objetos e abstrações visíveis para quem desenvolve aplicações. Mas alguém ainda precisa implementar a rede que permite comunicação entre Pods, nós e Services.
No ecossistema Kubernetes, a rede de Pods costuma ser implementada por software compatível com CNI — Container Network Interface. Kubernetes define o modelo e os pontos de integração; soluções de rede concretas materializam conectividade, endereçamento e, dependendo da implementação, capacidades adicionais como NetworkPolicy ou service proxying.
Para quem está aprendendo fundamentos, basta guardar:
Service/DNS
→ abstrações usadas pela aplicação
CNI / implementação de rede
→ camada que ajuda a materializar a rede do cluster
Escolher, instalar e operar um plugin CNI é assunto de cluster e plataforma. Isso pertence ao Lab/curso prático, não a este artigo conceitual.
E service mesh?
Service mesh aparece frequentemente ao lado de Kubernetes porque também lida com comunicação entre serviços. Mas ele está em outra camada de preocupação.
Um mesh pode adicionar recursos como políticas de tráfego, identidade entre workloads, telemetria e controle avançado de comunicação. Isso não substitui o conceito básico de Service nem é requisito para ter aplicações distribuídas no Kubernetes.
Introduzir mesh antes de dominar Service, DNS, readiness e observabilidade costuma apenas adicionar uma nova camada de proxies e políticas a um modelo que ainda não está claro.
Por isso, service mesh fica fora deste ciclo de fundamentos.
Confusões comuns sobre Services e networking
“Service é um Pod especial.” Não. Service é uma abstração de rede que representa acesso a um conjunto de endpoints; os Pods continuam sendo workloads separados.
“Service deixa meus Pods públicos.” Não necessariamente. O tipo padrão, ClusterIP, é voltado ao acesso dentro do cluster.
“DNS aponta diretamente para todos os Pods.” Para um Service normal, o nome normalmente resolve para o ClusterIP do Service. Headless Services têm comportamento diferente e podem expor diretamente endereços dos endpoints, mas esse é um aprofundamento específico.
“LoadBalancer substitui Ingress ou Gateway.” Não é uma equivalência direta. Um load balancer pode fornecer exposição de rede; Ingress/Gateway expressam regras e relacionamentos de roteamento de camada de aplicação de forma mais rica.
“Se uso Kubernetes, preciso escolher um service mesh.” Não. Mesh é uma extensão opcional, não requisito básico do modelo de networking.
“O IP do Pod é inútil porque muda.” Também não. O endereço do Pod é real e importante para a rede. O erro é transformá-lo em contrato estável entre partes da aplicação que precisam sobreviver à substituição de instâncias.
O modelo mental que vale guardar
A cadeia fica mais simples quando cada camada responde a uma pergunta:
Pod
→ onde esta instância está agora?
Service
→ como encontro esta capacidade de forma estável?
DNS
→ como encontro o Service por nome?
Ingress / Gateway
→ como tráfego externo chega ao Service correto?
CNI / implementação de rede
→ como a conectividade do cluster é materializada?
Não é necessário dominar todas essas camadas para publicar uma primeira aplicação. Mas confundi-las cria arquiteturas frágeis, especialmente quando a equipe tenta resolver descoberta, exposição e roteamento com a mesma ferramenta.
Próximo passo: configuração, segredos e volumes
Depois de resolver como workloads substituíveis se encontram, aparece outro problema inevitável.
Uma nova réplica precisa nascer sabendo como se configurar, como acessar credenciais e quais dados podem desaparecer ou precisam sobreviver à troca do Pod.
Se essas informações estiverem embutidas na imagem ou presas ao filesystem local de uma instância, a substituição automática perde boa parte do valor.
É por isso que o próximo passo é separar três responsabilidades que costumam ser misturadas: ConfigMaps para configuração não sensível, Secrets para dados sensíveis com limites explícitos de segurança e volumes para dados que precisam existir fora do filesystem descartável do container.