Workloads

Pod é a unidade de agendamento: seus containers compartilham rede e ciclo de vida. Para serviço sem estado, use Deployment; para identidade estável e volume por réplica, use StatefulSet; para um Pod em cada nó, DaemonSet; para trabalho finito, Job ou CronJob. Não use Deployment para banco apenas porque é o controlador mais conhecido.

spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: api
          image: registry.exemplo.com/api@sha256:SUBSTITUA
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits: { memory: 256Mi }
          startupProbe: { httpGet: { path: /healthz, port: 8080 }, failureThreshold: 30, periodSeconds: 5 }
          readinessProbe: { httpGet: { path: /readyz, port: 8080 } }
          livenessProbe: { httpGet: { path: /healthz, port: 8080 } }

startupProbe dá tempo para a partida; enquanto ela falha, liveness/readiness não agem. Readiness remove um Pod do tráfego sem reiniciá-lo; liveness reinicia apenas processo realmente travado. Uma liveness que testa dependência externa cria cascata de reinícios. Requests definem reserva para o scheduler; limite de memória impede um container de consumir o nó e pode resultar em OOMKilled. Limite de CPU causa throttling, portanto meça a latência antes de definir um teto arbitrário.

O encerramento precisa respeitar tráfego em andamento: readiness deve ficar falsa, a aplicação tratar SIGTERM e o grace period caber no tempo de drenagem. Um PodDisruptionBudget limita quantos Pods voluntariamente indisponíveis o cluster aceita, mas não protege de queda simultânea de nó nem substitui réplicas distribuídas.

Próximo passo: exponha esse workload na trilha de Rede Kubernetes e use o roteiro de Diagnóstico quando o Pod não ficar Ready.