Kubernetes: Ciclo de Vida de Imagens em Pods

O que acontece com a imagem Docker quando um pod é atualizado no Kubernetes: cache, garbage collection e imagePullPolicy explicados.

Quando você faz um novo deploy no Kubernetes e um pod é atualizado, uma dúvida natural surge: a imagem anterior é apagada automaticamente ou fica no cluster?

A resposta curta é: a imagem antiga permanece em cache no node até que o garbage collector do kubelet precise liberar espaço em disco.

O que acontece no deploy

Considere um fluxo típico de atualização:

Deploy v1 → pull da imagem v1 → pod roda com v1
Deploy v2 → pull da imagem v2 → pod roda com v2
           → imagem v1 ainda está no disco do node

O Kubernetes não apaga a imagem anterior no momento do rollout. Ela fica em cache local no node porque:

Outro pod pode ainda estar usando aquela imagem
Um rollback pode ser necessário — ter a imagem em cache torna isso muito mais rápido
A limpeza é feita de forma assíncrona pelo kubelet, não durante o deploy

Garbage Collection de Imagens

O kubelet possui um garbage collector de imagens que roda periodicamente. Ele entra em ação quando o disco do node atinge determinados thresholds:

Parâmetro kubelet	Valor padrão	Comportamento
`--image-gc-high-threshold`	85%	Inicia limpeza ao atingir esse uso de disco
`--image-gc-low-threshold`	80%	Para de limpar quando uso cai abaixo desse valor

A ordem de remoção prioriza as imagens menos usadas recentemente (LRU — Least Recently Used). Imagens que estão sendo usadas por pods ativos nunca são removidas pelo GC.

imagePullPolicy: influencia o pull, não a remoção

Uma confusão comum é pensar que imagePullPolicy controla quando imagens são deletadas. Ele controla apenas quando o kubelet tenta fazer pull de uma imagem, não quando ela é removida.

Policy	Comportamento
`IfNotPresent`	Usa a imagem em cache se já existir no node; faz pull só se não existir
`Always`	Faz pull toda vez que o pod sobe, mesmo que a imagem já esteja no node
`Never`	Nunca faz pull; falha se a imagem não estiver em cache

Atenção com latest: usar a tag latest sem imagePullPolicy: Always pode fazer o node rodar uma versão desatualizada sem sinalizar erro, porque a imagem latest local satisfaz IfNotPresent.

# Recomendado para produção: tag imutável + pull explícito
containers:
  - name: minha-api
    image: minha-api:1.4.2
    imagePullPolicy: IfNotPresent

Layer caching e eficiência de pull

Mesmo com Always, o pull não precisa baixar tudo novamente. O runtime de container (containerd, CRI-O) trabalha com camadas OCI. Se as camadas da imagem nova forem iguais às da anterior (base image, dependências), elas são reaproveitadas do cache local — apenas as camadas que mudaram são baixadas.

Por isso, boas práticas de Dockerfile (separar dependências do código da aplicação) impactam diretamente a velocidade de deploys no Kubernetes.

Inspecionando imagens no node

Para ver quais imagens estão em cache em um node específico:

# Lista todos os nodes
kubectl get nodes

# Acessa o node via debug pod (Kubernetes 1.23+)
kubectl debug node/<nome-do-node> -it --image=busybox

# Dentro do node, usa crictl para listar imagens
crictl images

Para remover uma imagem manualmente de um node:

crictl rmi <image-id>

Resumo

Situação	O que acontece
Pod atualizado para nova versão	Imagem antiga permanece no node
GC em disco > 85%	Imagens menos usadas são removidas (LRU)
Pod com imagem em uso	Nunca removida pelo GC
`imagePullPolicy: Always`	Verifica o registry a cada subida de pod
Rollback	Pode usar imagem já em cache — sem pull necessário

A gestão de imagens no Kubernetes é projetada para favorecer velocidade e resiliência: manter o cache local acelera rollbacks e reduz dependência de disponibilidade do registry durante incidentes.