Os Serviços Kubernetes — conceitos essenciais — Recursos

Projeto projet11-kubernetes-services · a teoria útil antes (ou durante) a prática.

Porque um Service?

Um Pod é efémero: pode ser apagado, recriado, deslocado para outro nó — e o endereço IP muda. Impossível, portanto, escrever « em duro » o IP de um Pod.

O Service resolve este problema: fornece um endereço estável (IP + nome DNS) e reparte automaticamente o tráfego para o conjunto dos Pods que correspondem ao seu seletor de labels.

O elo Service → Pods não é um IP fixo: é um seletor de labels. O Kubernetes mantém sozinho a lista dos Pods correspondentes (os Endpoints).

Os três tipos principais

1. ClusterIP (por defeito)

Endereço IP interno ao cluster, inacessível a partir do exterior.
Serve para a comunicação entre Pods (ex. o frontend chama o backend).
Base da descoberta de serviços: acessível por nome DNS (http://demo-clusterip).

2. NodePort

Abre um porto fixo em cada nó (gama 30000–32767).
Acesso externo simples: http://<ip-du-noeud>:<nodePort> (aqui http://localhost:30082).
Prático em dev/local; raramente exposto tal qual em produção.

3. LoadBalancer

Pede um IP externo à infraestrutura.
Na cloud (AWS/GCP/Azure): provisiona um verdadeiro load balancer.
Com o Docker Desktop: o EXTERNAL-IP torna-se localhost (http://localhost:8090).

Tabela comparativa

Tipo	Âmbito	Acesso	Caso de uso típico
ClusterIP	Interno	Nome DNS interno	Base de dados, API interna, comunicação Pod↔Pod
NodePort	Externo	`localhost:<30000-32767>`	Demo / dev local
LoadBalancer	Externo	IP público (localhost em local)	Serviço público em produção cloud

Existe também ExternalName (alias DNS para um serviço externo) e o Ingress (encaminhamento HTTP/HTTPS por nome de domínio, visto mais tarde) — fora deste projeto.

A descoberta de serviços (DNS interno)

O Kubernetes executa o CoreDNS no cluster. Cada Service recebe um nome DNS:

<nom-du-service>                       # no mesmo namespace
<nom-du-service>.<namespace>           # a partir de outro namespace
<nom-du-service>.<namespace>.svc.cluster.local   # nome completo (FQDN)

Assim, a partir de qualquer Pod do mesmo namespace:

bash

curl http://demo-clusterip            # resolvido pelo CoreDNS -> IP do Service -> um Pod

Service e Endpoints

O Service define o que expor (via o seletor).
Os Endpoints são a lista real dos IP:port dos Pods correspondentes, atualizada automaticamente pelo Kubernetes.

bash

kubectl get endpoints demo-clusterip   # affiche les IP des Pods derriere le Service

Se nenhum Pod corresponder ao seletor → Endpoints vazios → o Service responde « sem backend » (ligação recusada).
É o erro n.º 1: um label do Pod que não corresponde ao seletor do Service.

A reter

Um Service = endereço estável + repartição de carga + seletor de labels.
ClusterIP (interno, DNS), NodePort (porto do nó), LoadBalancer (IP externo).
A descoberta de serviços faz-se por nome DNS graças ao CoreDNS.
Os Endpoints ligam dinamicamente o Service aos seus Pods.

Curso criado pelo Dr. Haythem REHOUMA — Desenvolvimento e implantação de soluções de dados