Conceitos · Workloads

Ciclo de Vida do Pod

Fases, condições, estados dos containers e políticas de restart. Entender o lifecycle evita metade dos problemas de troubleshooting.

// FLUXO DE FASES
Pending
▶️
Running
Succeeded
Failed
Unknown
Pending

O Pod foi aceito pelo cluster, mas um ou mais containers ainda não estão rodando. Pode estar aguardando scheduling ou download da imagem.

  • ·Aguardando scheduler alocar em um node
  • ·Imagem sendo baixada (pulling)
  • ·PVC ainda não bound
  • ·Recursos insuficientes nos nodes
▶️Running

O Pod foi alocado em um node, todos os containers foram criados e pelo menos um está rodando, iniciando ou reiniciando.

  • ·Estado normal de operação
  • ·Container pode estar em CrashLoop mesmo com status Running
  • ·Checar READY column: 2/2 significa ambos prontos
Succeeded

Todos os containers terminaram com sucesso (exit code 0) e não serão reiniciados. Típico de Jobs e CronJobs.

  • ·Job completou com sucesso
  • ·Init container terminou
  • ·Batch process finalizado
Failed

Todos os containers terminaram e pelo menos um terminou com falha (exit code != 0 ou foi morto pelo sistema).

  • ·Container saiu com código de erro
  • ·OOMKilled: processo morto por falta de memória
  • ·Liveness probe falhou repetidamente
Unknown

O estado do Pod não pôde ser obtido, geralmente por falha de comunicação com o node onde o Pod deveria estar rodando.

  • ·Node perdeu conectividade com o Control Plane
  • ·kubelet do node parou de responder
  • ·Problema de rede entre node e API Server

Condições do Pod (Pod Conditions)

Enquanto Fase é o estado geral, Condições são flags booleanas mais granulares. Veja com kubectl describe pod.

PodScheduledPod foi alocado em um node pelo scheduler
ContainersReadyTodos os containers do Pod estão prontos
InitializedTodos os init containers completaram com sucesso
ReadyPod pode receber tráfego — adicionado aos Endpoints dos Services
DisruptionTargetPod está sendo encerrado por disrupção voluntária (drain, eviction)

Estados dos Containers

Um Pod pode estar Running mas seus containers podem ter estados diferentes. Veja com kubectl describe pod <pod> → seção Containers.

Waiting

Container aguardando para iniciar. Razão pode ser: ContainerCreating, PullImage, CrashLoopBackOff.

Running

Container executando sem problemas. startedAt indica quando iniciou.

Terminated

Container finalizou execução. exitCode e reason indicam o motivo (Completed, OOMKilled, Error).

Restart Policies

Definida em spec.restartPolicy. Aplica-se a todos os containers do Pod.

Always

Reinicia o container sempre que ele parar, independente do exit code. Padrão para Deployments.

OnFailure

Reinicia apenas se o container terminar com erro (exit code != 0). Usado em Jobs.

Never

Nunca reinicia o container, independente do resultado. Usado em Jobs one-shot.

🚦 Init Containers

Rodam antes dos containers principais, em sequência. Cada um deve completar com sucesso antes do próximo iniciar. Se falhar, o Pod é reiniciado.

  • ·Aguardar banco de dados ficar disponível
  • ·Baixar configurações de um S3
  • ·Rodar migrations antes da API subir
  • ·Configurar permissões de arquivos

🔄 Sidecar Containers

Rodam junto com o container principal no mesmo Pod, compartilhando rede e volumes. Desde K8s 1.29 existe o tipo nativo initContainer com restartPolicy: Always.

  • ·Fluentbit: coletar logs do app principal
  • ·Envoy/Istio: proxy de rede (service mesh)
  • ·Datadog Agent: métricas do processo
  • ·Coletor de traces para Jaeger/X-Ray
💡 Dica de diagnóstico: Use kubectl get pod <name> -o yaml | grep -A5 containerStatuses para ver o estado detalhado de cada container, incluindo lastState com o exit code do crash anterior.