Curso Kubernetes 08 — Deployments, StatefulSets, DaemonSets e Jobs

Kubernetes tem poucos tipos de workload, mas escolher o errado custa caro. Um banco de dados em Deployment até sobe — e depois te ensina, do jeito difícil, por que StatefulSet existe.

Selo do curso: testado em Kubernetes 1.35.

O mapa

Tipo	Para quê	Identidade estável?	Storage estável?
Pod	testes pontuais	não	não
Deployment	aplicações stateless	não	não
StatefulSet	bancos, filas, clusters	sim	sim
DaemonSet	um agente por nó	por nó	depende
Job	tarefa até concluir	não	não
CronJob	tarefa agendada	não	não

Deployment: o padrão para stateless

Um Deployment garante réplicas, rollout e rollback. Os pods são descartáveis e intercambiáveis.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/exemplo/api:1.4.2
          ports:
            - containerPort: 8080

Rollout:

kubectl rollout status deployment/api
kubectl rollout history deployment/api
kubectl rollout undo deployment/api

Cuidados:

• maxSurge/maxUnavailable precisam caber na capacidade dos nós.
• Probes mal configuradas transformam rollout em CrashLoopBackOff.
• revisionHistoryLimit evita acúmulo infinito de ReplicaSets.

StatefulSet: identidade importa

StatefulSet dá a cada pod:

• Nome ordinal (db-0, db-1, db-2).
• Rede estável via headless Service.
• PVC próprio via volumeClaimTemplates.
• Ordem de criação/remoção (normalmente sequencial).

apiVersion: v1
kind: Service
metadata:
  name: db-headless
spec:
  clusterIP: None
  selector:
    app: db
  ports:
    - port: 5432
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db-headless
  replicas: 3
  selector:
    matchLabels:
      app: db
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
        - name: db
          image: postgres:16
          ports:
            - containerPort: 5432
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 5Gi

Se você deletar db-1, ele volta com o mesmo nome e o mesmo PVC. É isso que permite um banco ou um cluster de filas sobreviver.

Cuidados:

• PVC órfão após deletar o StatefulSet (por padrão, o PVC fica).
• Ordem de inicialização pode deixar o cluster lento; alguns bancos precisam de init próprio.
• Atualizações exigem estratégia (RollingUpdate ou OnDelete).

DaemonSet: um por nó

DaemonSet roda um pod em cada nó (ou em um subconjunto). É o padrão para:

• CNI (flannel, Cilium).
• Coleta de logs (Fluent Bit).
• Métricas de nó (node-exporter).
• Agentes de backup (Velero node-agent).

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      tolerations:
        - operator: Exists
      containers:
        - name: node-exporter
          image: prom/node-exporter:v1.8.2
          ports:
            - containerPort: 9100

Cuidado: taints. Se o nó tem taint e o DaemonSet não tolera, o pod não roda — e você descobre que o agente de monitoramento não cobre justamente o nó problemático.

Job e CronJob: tarefas

Job roda até concluir:

apiVersion: batch/v1
kind: Job
metadata:
  name: backup
spec:
  backoffLimit: 3
  completions: 1
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: backup
          image: ghcr.io/exemplo/backup:1.0

CronJob agenda:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-diario
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: backup
              image: ghcr.io/exemplo/backup:1.0

Cuidados:

• concurrencyPolicy: Forbid evita duas execuções sobrepostas.
• backoffLimit alto pode gerar retry infinito e barulho.
• Job que nunca termina precisa de activeDeadlineSeconds.
• CronJob em fuso: o cluster roda em UTC por padrão; ajuste se o horário importa.

Laboratório

1. StatefulSet com PVC:

kubectl create ns workloads
kubectl -n workloads apply -f statefulset.yaml
kubectl -n workloads get pods,pvc
kubectl -n workloads delete pod db-1
kubectl -n workloads get pods -w

Veja db-1 voltar com o mesmo nome e o mesmo PVC.

2. DaemonSet:

kubectl -n workloads apply -f daemonset.yaml
kubectl -n workloads get pods -o wide

3. Job e CronJob:

kubectl -n workloads create job hello --image=busybox:1.36 -- echo hello
kubectl -n workloads logs job/hello
kubectl -n workloads create cronjob hello-cron --image=busybox:1.36 --schedule="*/1 * * * *" -- date

Erros comuns

Sintoma	Causa
StatefulSet Pending	PVC sem storageClass ou sem PV
Pods do DaemonSet ausentes em um nó	taint sem toleration
Job em loop	backoffLimit alto + erro permanente
CronJob sobreposto	concurrencyPolicy: Allow
Deployment não atualiza	imagem/tag igual ou selector errado
PVC não reaproveitado	StatefulSet recriado com outro nome

Checklist

• [ ] Sei se a carga é stateless ou stateful.
• [ ] Deployment tem strategy e probes.
• [ ] StatefulSet tem headless Service e volumeClaimTemplates.
• [ ] DaemonSet tolera as taints dos nós.
• [ ] Jobs têm limite de retry e deadline.
• [ ] CronJobs têm concurrencyPolicy definida.

Glossário

• headless Service: Service sem ClusterIP, usado para DNS estável por pod.
• volumeClaimTemplates: template de PVC por réplica do StatefulSet.
• taint/toleration: regra que afasta/permite pods em nós.
• backoffLimit: número de tentativas de um Job.
• concurrencyPolicy: se o CronJob pode rodar em paralelo.

Próximo

Agora que você sabe escolher o workload, vamos expor tudo com Services, Ingress, DNS e TLS.

Próximo: Curso Kubernetes 09 — Services, Ingress, DNS e TLS