Enunciado — Projeto 11: Os Serviços Kubernetes (ClusterIP, NodePort, LoadBalancer) — Recursos

Prática · Módulo 07 — Kubernetes: conceitos de base · Nível intermédio

Tenta primeiro sozinho! Realiza o projeto só com este enunciado. O corrigé (manifestos comentados + comandos) está no README.md, recolhido. Só o abras depois de teres tentado.

Pré-requisitos

O cluster Kubernetes do Docker Desktop ativado (tipo Kubeadm) — ver o projeto 10.
A imagem demo-k8s:1.0 já construída (senão: docker build -t demo-k8s:1.0 ./app).

Objetivo

Compreender para que serve um Service e dominar os três tipos principais:

ClusterIP — acesso interno ao cluster + descoberta de serviços por nome DNS;
NodePort — acesso externo via um porto da máquina;
LoadBalancer — acesso externo via um IP « público » (localhost com Docker Desktop).

Tudo por cima de um mesmo Deployment: um só lote de Pods, três formas de os expor.

O problema a resolver

Os Pods são efémeros: nascem, morrem, mudam de IP. Portanto não se pode contar com o IP de um Pod. É preciso um endereço estável que reparta o tráfego para os Pods certos: esse é o papel do Service, que encontra os Pods graças aos labels.

Trabalho a realizar

Parte 1 — O Deployment (os Pods a expor)

Implanta uma app em 3 réplicas que mostre o nome do Pod (reutiliza demo-k8s:1.0).
Dá aos Pods um label claro (ex. app: demo-back).

Parte 2 — ClusterIP + descoberta de serviços

Cria um Service ClusterIP chamado demo-clusterip (porto 80 → 5000).
Demonstra a descoberta por DNS: lança um Pod cliente temporário e chama o serviço pelo nome:
```
curl http://demo-clusterip
```
Recarrega várias vezes e constata que o nome do Pod muda (repartição de carga interna).

Parte 3 — NodePort (acesso externo)

Cria um Service NodePort chamado demo-nodeport (nodePort 30082).
Abre http://localhost:30082 no navegador.

Parte 4 — LoadBalancer (acesso externo « cloud »)

Cria um Service LoadBalancer chamado demo-lb (porto 8090).
Verifica o EXTERNAL-IP (kubectl get svc) e abre http://localhost:8090.

Parte 5 — Observar e compreender

Lista os Services (kubectl get svc) e identifica: TYPE, CLUSTER-IP, EXTERNAL-IP, PORT(S).
Olha para os Endpoints (kubectl get endpoints demo-clusterip): são os IP dos Pods atrás do Service.
Altera um label de um Pod (ou do seletor) e observa que ele sai dos Endpoints.

Perguntas de reflexão

Porque é que não se pode simplesmente usar o IP de um Pod?
Que tipo de Service para: (a) uma base de dados interna, (b) um sítio web público em dev local, (c) uma API pública em produção cloud?
Como é que um Pod encontra outro serviço pelo nome? (papel do CoreDNS)
O que contém a lista dos Endpoints de um Service, e quem a atualiza?
O que acontece se nenhum Pod corresponder ao seletor do Service?

Entregáveis

k8s/deployment.yaml e os três Services (service-clusterip.yaml, service-nodeport.yaml, service-loadbalancer.yaml).
Uma captura de kubectl get svc a mostrar os 3 tipos.
Uma captura da descoberta por DNS (curl http://demo-clusterip a partir de um Pod cliente) com 2 nomes de Pods diferentes.
Uma captura de kubectl get endpoints demo-clusterip.

Critérios de sucesso

Critério	Esperado
ClusterIP	Acessível por nome DNS a partir de outro Pod
NodePort	Acessível em `http://localhost:30082`
LoadBalancer	`EXTERNAL-IP` = localhost, acessível em `http://localhost:8090`
Repartição	O nome do Pod muda entre dois pedidos
Endpoints	Os IP dos 3 Pods aparecem atrás do Service

Bloqueado? O README.md contém o corrigé completo, as noções estão detalhadas em 01-CONCEPTS-SERVICES.md, e 02-COMMANDES.md lista todo o kubectl útil — a consultar depois de teres tentado.