Os tipos de Serviços Kubernetes — guia ultra-exaustivo

Projeto projet11-kubernetes-services · Documento de referência aprofundado.

Este documento vai muito mais longe do que o corrigé: detalha todos os tipos de Services, as noções internas (kube-proxy, Endpoints, EndpointSlices, DNS), os campos YAML importantes, as políticas de tráfego, a session affinity, o multi-porto, as armadilhas clássicas e as boas práticas.

Índice

1. Lembrete: o papel de um Service
2. Anatomia de um Service (todos os campos)
3. Tipo 1 — ClusterIP
4. Tipo 2 — NodePort
5. Tipo 3 — LoadBalancer
6. Tipo 4 — ExternalName
7. Service Headless (sem ClusterIP)
8. Service sem seletor (Endpoints manuais)
9. port vs targetPort vs nodePort
10. Multi-porto e portos nomeados
11. Como funciona por baixo: kube-proxy
12. Endpoints e EndpointSlices
13. O DNS dos Services (CoreDNS)
14. Políticas de tráfego (externalTrafficPolicy / internalTrafficPolicy)
15. Session affinity
16. Protocolos: TCP, UDP, SCTP, appProtocol
17. Service vs Ingress vs Gateway API
18. Tabela recapitulativa dos tipos
19. Armadilhas clássicas e resolução de problemas
20. Boas práticas
21. Mini-exercícios

1. Lembrete: o papel de um Service

Um Pod é efémero: pode ser recriado a qualquer momento, com um novo IP. Portanto não se pode apoiar no IP de um Pod para comunicar.

Um Service é uma abstração estável que:

• fornece uma identidade de rede permanente (um IP virtual e/ou um nome DNS);
• seleciona um conjunto de Pods através dos respetivos labels;
• reparte o tráfego (load balancing) entre esses Pods;
• atualiza-se automaticamente quando os Pods aparecem ou desaparecem.

Ideia mestra: o Service não « contém » os Pods. Encontra-os em contínuo graças ao seletor de labels, e mantém a lista dos respetivos endereços nos Endpoints.

2. Anatomia de um Service (todos os campos)

apiVersion: v1
kind: Service
metadata:
  name: mon-service
  labels:
    app: demo
  annotations: {}               # metadados (muitas vezes usados pelos LoadBalancer cloud)
spec:
  type: ClusterIP               # ClusterIP | NodePort | LoadBalancer | ExternalName
  selector:                     # que Pods este Service visa (por labels)
    app: demo
  ports:
    - name: http                # nome do porto (útil se houver vários portos)
      protocol: TCP             # TCP (defeito) | UDP | SCTP
      port: 80                  # porto do Service (o que os clientes veem)
      targetPort: 5000          # porto do contentor (ou nome de porto do contentor)
      nodePort: 30080           # (NodePort/LoadBalancer) porto aberto no nó
  clusterIP: 10.96.0.10         # (opcional) IP fixo ; "None" = headless
  sessionAffinity: None         # None | ClientIP
  externalTrafficPolicy: Cluster  # Cluster | Local (NodePort/LoadBalancer)
  internalTrafficPolicy: Cluster  # Cluster | Local
  ipFamilyPolicy: SingleStack   # SingleStack | PreferDualStack | RequireDualStack
  externalIPs: []               # IP externos encaminhados para este Service (avançado)

Cada campo é detalhado mais abaixo. Pode-se criar um Service mínimo em 8 linhas; todos os outros campos têm valores por defeito razoáveis.

3. Tipo 1 — ClusterIP

O tipo por defeito. Atribui um IP virtual interno (na gama Service CIDR, ex. 10.96.0.0/12), acessível apenas a partir do interior do cluster.

apiVersion: v1
kind: Service
metadata:
  name: demo-clusterip
spec:
  type: ClusterIP
  selector:
    app: demo-back
  ports:
    - port: 80
      targetPort: 5000

Características:

• Inacessível a partir do exterior (sem EXTERNAL-IP).
• Base da comunicação interna (frontend → backend, app → base de dados, microserviços entre si).
• Acessível por nome DNS: http://demo-clusterip (ver §13).

Quando usar: para tudo o que fica no cluster. É o tipo mais frequente.

4. Tipo 2 — NodePort

Faz tudo o que o ClusterIP faz (obtém um IP interno), mais: abre um porto estático em cada nó do cluster (gama por defeito 30000–32767).

apiVersion: v1
kind: Service
metadata:
  name: demo-nodeport
spec:
  type: NodePort
  selector:
    app: demo-back
  ports:
    - port: 80          # porto do Service (interno)
      targetPort: 5000  # porto do contentor
      nodePort: 30082   # porto aberto em CADA nó

Acesso: http://<ip-de-n-importe-quel-noeud>:30082 (com Docker Desktop: http://localhost:30082).

Pontos importantes:

• Se não precisares nodePort, o Kubernetes escolhe um na gama.
• O mesmo porto é aberto em todos os nós (graças ao routing mesh / kube-proxy), mesmo os que não alojam nenhum Pod do Service.
• Pouco elegante para produção (portos não standard, gestão manual), mas perfeito em dev/local e muitas vezes o tijolo por baixo de um LoadBalancer.

5. Tipo 3 — LoadBalancer

Faz tudo o que o NodePort faz, mais: pede à infraestrutura (a cloud) que provisione um equilibrador de carga externo com um IP público.

apiVersion: v1
kind: Service
metadata:
  name: demo-lb
spec:
  type: LoadBalancer
  selector:
    app: demo-back
  ports:
    - port: 8090
      targetPort: 5000

Conforme o ambiente:

Cadeia completa: LoadBalancer → NodePort → ClusterIP → Endpoints → Pods.

Annotations (específicas do fornecedor) pilotam o LB, por ex. na AWS:

metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"

Um LoadBalancer por serviço = caro na cloud. Em produção, prefere-se muitas vezes um único ponto de entrada (Ingress/Gateway) à frente de vários serviços (ver §17).

6. Tipo 4 — ExternalName

Caso particular: nenhum seletor, nenhum Pod, nenhum IP. Cria simplesmente um alias DNS (registo CNAME) para um nome externo.

apiVersion: v1
kind: Service
metadata:
  name: base-externe
spec:
  type: ExternalName
  externalName: db.exemple.com     # os Pods que chamam "base-externe" são reencaminhados para aqui

Uso: fazer apontar um nome interno estável (base-externe) para um serviço fora do cluster (uma base gerida, uma API de terceiros). Se o endereço mudar, altera-se um único sítio.

Limite: é DNS puro, sem repartição de carga nem controlo de porto. Não convém se o serviço externo espera um Host HTTP particular.

7. Service Headless (sem ClusterIP)

Ao pôr clusterIP: None, obtém-se um Service sem IP virtual. O DNS devolve então diretamente os IP de todos os Pods (uma lista de registos A), em vez de um único IP.

apiVersion: v1
kind: Service
metadata:
  name: demo-headless
spec:
  clusterIP: None        # <-- headless
  selector:
    app: demo-back
  ports:
    - port: 80
      targetPort: 5000

Para que serve:

• Quando o cliente quer ver cada Pod individualmente (sem LB centralizado).
• Indispensável para os StatefulSet: cada Pod obtém um nome DNS estável (pod-0.demo-headless, pod-1.demo-headless…), útil para bases de dados replicadas (Cassandra, Kafka, etc.).

8. Service sem seletor (Endpoints manuais)

Um Service pode não ter seletor. Nesse caso, o Kubernetes não preenche os Endpoints sozinho: tu defines-os à mão. Prático para expor um recurso externo sob um IP interno estável.

apiVersion: v1
kind: Service
metadata:
  name: api-legacy
spec:
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: v1
kind: Endpoints           # (ou EndpointSlice, mais moderno)
metadata:
  name: api-legacy         # o MESMO nome que o Service
subsets:
  - addresses:
      - ip: 192.168.1.50   # servidor externo
    ports:
      - port: 8080

Diferença em relação ao ExternalName: aqui encaminha-se por IP (com load balancing possível em vários IP), não por CNAME DNS.

9. port vs targetPort vs nodePort

Esta é a fonte de confusão. Três portos diferentes, três papéis:

Exemplo lido em voz alta: « os clientes batem no porto 80 do Service, que transmite para o porto 5000 do contentor; em NodePort, entra-se também pelo porto 30082 da máquina ».

targetPort pode referenciar um nome de porto definido no contentor (ver §10), o que evita escrever o número em duro.

10. Multi-porto e portos nomeados

Um Service pode expor vários portos (ex. HTTP + métricas). Nesse caso, cada entrada deve ter um name.

spec:
  selector:
    app: demo
  ports:
    - name: http
      port: 80
      targetPort: web          # referencia um porto NOMEADO do contentor
    - name: metrics
      port: 9090
      targetPort: 9090

Do lado do contentor, nomeiam-se os portos:

containers:
  - name: app
    ports:
      - name: web              # <-- reutilizado por targetPort: web
        containerPort: 5000
      - name: metrics
        containerPort: 9090

Vantagem dos portos nomeados: se o porto do contentor mudar, não há nada a alterar no Service.

11. Como funciona por baixo: kube-proxy

O Service é um objeto abstrato: não é um processo que recebe o tráfego. A magia é feita pelo kube-proxy, um componente presente em cada nó, que programa as regras de rede do kernel para reencaminhar « IP:porto do Service » para « IP:porto de um Pod ».

Modos do kube-proxy:

Consequências práticas:

• A repartição iptables é aleatória (não é um verdadeiro round-robin ordenado).
• O kube-proxy não vê a camada HTTP: é L3/L4 (IP/porto). Para encaminhamento HTTP (por caminho, por host), é preciso um Ingress (§17).

12. Endpoints e EndpointSlices

O elo Service ↔ Pods materializa-se em objetos:

• Endpoints (histórico): um único objeto a listar todos os IP:port dos Pods prontos.
• EndpointSlices (moderno, recomendado): a lista é dividida em fatias (máx. ~100 endpoints cada) → escalabilidade bem melhor nos serviços grandes.

kubectl get endpoints demo-clusterip
kubectl get endpointslices -l kubernetes.io/service-name=demo-clusterip

Quem atualiza a lista? O endpoint controller: assim que um Pod fica Ready (readinessProbe OK) e corresponde ao seletor, o IP entra; se cair, sai.

Um Pod não Ready é retirado dos Endpoints → não recebe tráfego. Por isso a readinessProbe é essencial: controla quem está « dentro » do Service. (Exceção: publishNotReadyAddresses: true publica também os Pods não prontos — uso headless específico.)

13. O DNS dos Services (CoreDNS)

O Kubernetes faz correr o CoreDNS. Cada Service recebe um nome DNS determinista:

<service>                                   # mesmo namespace
<service>.<namespace>                        # outro namespace
<service>.<namespace>.svc.cluster.local      # FQDN completo

Exemplo a partir de um Pod:

curl http://demo-clusterip                       # mesmo namespace
curl http://demo-clusterip.default               # explícito
curl http://demo-clusterip.default.svc.cluster.local

Registos produzidos:

• Service normal → um registo A para o ClusterIP.
• Service headless → vários A, um por Pod.
• Portos nomeados → registos SRV: _http._tcp.demo-clusterip….
• ExternalName → CNAME para o alvo.

Historicamente, o Kubernetes também injetava variáveis de ambiente (DEMO_CLUSTERIP_SERVICE_HOST, ..._PORT) nos Pods criados depois do Service. O DNS continua a ser o método recomendado (funciona independentemente da ordem de criação).

14. Políticas de tráfego

externalTrafficPolicy (tráfego entrante externo, NodePort/LoadBalancer)

internalTrafficPolicy (tráfego interno, entre Pods)

externalTrafficPolicy: Local é o ajuste-chave quando precisas de conhecer o verdadeiro IP do cliente (logs, segurança, geolocalização).

15. Session affinity

Por defeito, cada pedido pode ir para qualquer Pod. Para « colar » um cliente ao mesmo Pod:

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800     # 3 h

• None (defeito): repartição a cada pedido.
• ClientIP: todos os pedidos de um mesmo IP vão para o mesmo Pod (sticky sessions básicas L4).

Para sessões HTTP mais finas (por cookie), usa-se antes um Ingress (L7).

16. Protocolos: TCP, UDP, SCTP, appProtocol

• protocol: TCP (defeito), UDP (DNS, jogos, streaming), SCTP (telecoms).
• Pode-se misturar vários protocolos no mesmo Service (portos distintos).
• appProtocol (indicativo) precisa o protocolo aplicacional (http, https, grpc) para as ferramentas/LB.

ports:
  - name: dns-udp
    port: 53
    protocol: UDP
    targetPort: 53
  - name: dns-tcp
    port: 53
    protocol: TCP
    targetPort: 53

17. Service vs Ingress vs Gateway API

Um Service trabalha em L4 (IP/porto). Não sabe encaminhar segundo o URL, o nome de anfitrião, nem gerir o TLS. Para isso:

Modelo típico em produção: um único LoadBalancer → Ingress → vários ClusterIP internos. Poupa-se nos LB caros e centraliza-se TLS/encaminhamento.

18. Tabela recapitulativa dos tipos

19. Armadilhas clássicas e resolução de problemas

Comandos de diagnóstico:

kubectl get svc <nom> -o wide
kubectl describe svc <nom>
kubectl get endpoints <nom>
kubectl get endpointslices -l kubernetes.io/service-name=<nom>
kubectl run test --rm -it --image=busybox:1.36 -- sh   # nslookup <svc>, wget -qO- http://<svc>

20. Boas práticas

• Por defeito, ClusterIP. Só exposes ao exterior o que deve sê-lo.
• Um único LoadBalancer + Ingress à frente de vários ClusterIP (custo + TLS centralizado).
• Nomeia os portos (multi-porto, e targetPort por nome → desacoplamento).
• Cuida das readinessProbe: elas decidem quem está dentro dos Endpoints.
• Coerência labels/seletores: é o erro n.º 1. Mantém labels estáveis (app, tier, version).
• Usa externalTrafficPolicy: Local quando o verdadeiro IP do cliente importa.
• Prefere os EndpointSlices (ativos por defeito nas versões recentes) para a escalabilidade.
• Nunca escrevas um IP de Pod em duro: usa o nome DNS do Service.

21. Mini-exercícios

Regresso ao corrigé do projeto · Conceitos de base: 01-CONCEPTS-SERVICES.md · Comandos: 02-COMMANDES.md.

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