Solução de problemas em workloads

Introdução

As implantações nem sempre saem como planejado. Quando algo dá errado, você precisa de um método de solução de problemas que possa repetir.

Neste laboratório, você resolverá "O caso da imagem desaparecida".

No Kubernetes, a solução de problemas geralmente começa pelo status do objeto, passa pelos eventos e depois chega a uma inspeção mais detalhada. Este laboratório se concentra nesse fluxo baseado em evidências.

Você vai:

Criar a cena do problema: implantar intencionalmente um Pod com falha.
Investigar: usar "binóculos" (get) para verificar que há algo errado.
Reunir evidências: usar uma "lupa" (describe) para encontrar a causa raiz.
Resolver o caso: corrigir a configuração e observar a recuperação da aplicação.

Criar um Pod com falha

Vamos começar implantando um Pod com um erro de digitação intencional. Isso simula um erro comum: especificar uma imagem que não existe.

Este é um bom lembrete de que o Kubernetes aceita muitos manifests cujos problemas só são descobertos mais tarde. Um arquivo YAML pode ser sintaticamente válido e ainda assim estar incorreto do ponto de vista operacional. Por isso, a solução de problemas precisa separar “O objeto foi aceito?” de “O workload realmente foi iniciado corretamente?”.

Crie um arquivo chamado broken-pod.yaml:

nano broken-pod.yaml

Cole o conteúdo a seguir. Observe a tag de imagem suspeita wrongtag123.

apiVersion: v1
kind: Pod
metadata:
  name: broken-pod
spec:
  containers:
    - name: nginx
      image: nginx:wrongtag123

Salve e saia (Ctrl+X, Y, Enter).

Implante o Pod:

kubectl apply -f broken-pod.yaml

O Kubernetes aceita o arquivo porque o formato YAML está correto. O “problema” ainda não foi detectado.

Observar a falha

Agora, vamos verificar o status da nossa implantação. É como usar binóculos para examinar a cena.

Status como ErrImagePull e ImagePullBackOff são sintomas, não explicações finais. Eles indicam onde você deve investigar em seguida. Uma boa solução de problemas trata a saída do status como a primeira pista, e não como o diagnóstico completo.

Verifique os Pods no namespace padrão:

kubectl get pods

Inicialmente, você pode ver ContainerCreating, mas, depois de alguns segundos, o status provavelmente mudará para ImagePullBackOff ou ErrImagePull.

ImagePullBackOff é a forma como o Kubernetes diz: “Tentei baixar esta imagem, mas falhei. Vou esperar um pouco e tentar novamente mais tarde”.

Isso confirma que a vítima — o Pod — não está saudável.

Inspecionar os eventos

Sabemos que houve uma falha, mas não sabemos por quê. Para descobrir, precisamos examinar o problema de perto.

O comando kubectl describe é a sua lupa. Ele mostra os eventos internos e os logs de um recurso específico.

A seção Events é especialmente importante porque preserva uma breve narrativa dos componentes do Kubernetes, como o scheduler e o kubelet. Quando iniciantes aplicam correções aleatórias sem ler os eventos, frequentemente perdem tempo resolvendo o problema errado.

Inspecione o Pod com falha:

kubectl describe pod broken-pod

Esse comando exibe muitos dados. Role até o final para encontrar a seção Events.

Você deverá ver algo parecido com isto:

Type     Reason     Message
----     ------     -------
Normal   Pulling    Pulling image "nginx:wrongtag123"
Warning  Failed     Failed to pull image "nginx:wrongtag123": manifest unknown
Warning  Failed     Error: ErrImagePull

A mensagem manifest unknown é a prova decisiva. Isso significa que o registro do Docker, onde as imagens ficam armazenadas, não tem nenhum registro de nginx:wrongtag123.

Caso resolvido: a tag da imagem é inválida.

Corrigir o Pod

Agora que conhecemos a causa raiz, podemos corrigi-la.

Esta etapa final também ilustra um padrão mais amplo: observar, formular uma hipótese com base nas evidências, fazer uma única alteração direcionada e verificar a recuperação. Esse ciclo disciplinado é mais confiável do que fazer várias alterações especulativas ao mesmo tempo.

Abra novamente o arquivo broken-pod.yaml:

nano broken-pod.yaml

Corrija o “erro de digitação”. Altere nginx:wrongtag123 para apenas nginx — esse valor usa nginx:latest por padrão, que é uma imagem válida.

apiVersion: v1
kind: Pod
metadata:
  name: broken-pod
spec:
  containers:
    - name: nginx
      image: nginx

Salve e saia.

Aplique a correção. O Kubernetes consegue atualizar o Pod existente com as novas informações.

kubectl apply -f broken-pod.yaml

Agora, observe a recuperação:

kubectl get pods -w

Você deverá ver o status mudar de ImagePullBackOff para Running.

Pressione Ctrl+C para interromper a observação.

Excelente trabalho, detetive! Você identificou o erro e restaurou o serviço com sucesso.

Resumo

Neste laboratório, você aprendeu o fluxo fundamental para solucionar problemas no Kubernetes:

Observar: verificar kubectl get pods para identificar workloads com falha.
Inspecionar: usar kubectl describe pod para visualizar o log de eventos e encontrar as mensagens de erro.
Corrigir: atualizar o manifest YAML e aplicar a correção.

Esse processo — Get, Describe, Fix — resolverá 90% dos problemas de implantação que você encontrará na sua carreira com Kubernetes.