Ordenar eventos do kubectl por tempo

kubectl get events --sort-by='.lastTimestamp' coloca o evento mais recente do cluster por último, em vez de despejá-los na ordem qualquer que a API devolve. Eventos são o primeiro lugar para olhar, antes dos logs — os logs dizem o que a aplicação fez, os eventos dizem o que o cluster fez com ela. Metade das falhas que realmente importam (sem espaço em disco, uma imagem que não baixa, recursos insuficientes, um volume que nunca montou) não aparece em log nenhum.

1. Como ordenar os eventos do kubectl por tempo?

$ clai mostra os eventos do cluster, os mais recentes no final→ kubectl get events --sort-by='.lastTimestamp'

Sem ordenação, os eventos saem na ordem qualquer em que a API os guarda, o que os torna inúteis de revisar. A chave de ordenação começa com ponto porque é um JSONPath dentro do objeto do evento.

2. Como ver só os avisos de um namespace?

$ clai mostra os avisos no namespace production de um tempo pra cá→ kubectl get events -n production --field-selector type=Warning --sort-by='.lastTimestamp'

Eventos têm dois tipos, Normal e Warning. Normal só atrapalha quando você está analisando um incidente. --field-selector filtra do lado do servidor, então continua rápido mesmo num cluster grande.

3. Como ver os eventos de um pod específico?

$ clai mostra o que aconteceu com esse pod→ kubectl describe pod my-app-7d9f8 -n production

describe imprime os eventos no final da saída, já associados ao objeto — geralmente mais rápido do que filtrar a lista inteira de eventos. É ali que você vê motivos como FailedScheduling, ImagePullBackOff ou OOMKilled.

4. Como pegar os logs de um container que caiu?

$ clai mostra os logs da execução anterior desse container→ kubectl logs my-app-7d9f8 -n production --previous

Quando um container reinicia, os logs dele são substituídos pelos da nova instância. --previous traz os logs da instância anterior — os que de fato registraram por que ele caiu. Sem essa flag, você está olhando um processo recém-iniciado que ainda não tem nada pra dizer.

5. Como acompanhar eventos em tempo real?

$ clai acompanha os eventos desse namespace agora mesmo→ kubectl get events -n production --watch

Útil durante um rollout: dá pra ver o scheduler posicionando os pods, as imagens sendo baixadas e os checks de readiness passando em tempo real. Ctrl+C para parar.

6. Por que um pod não sobe?

$ clai mostra os pods que não estão em Running, e os eventos deles→ kubectl get pods -n production --field-selector status.phase!=Running

Primeiro reduza aos pods com problema, depois rode describe em cada um. Pending quase sempre significa que o scheduler não tem onde colocar o pod — recursos insuficientes, restrições de posicionamento que não batem, ou um volume que não foi encontrado.

Pegadinhas

• Eventos duram cerca de uma hora. --event-ttl é de 1 hora por padrão, e depois disso o evento some. Não sobra nada pra reconstruir o incidente de ontem a partir de eventos — precisa de um coletor externo.
• --sort-by precisa de um JSONPath com ponto no início. --sort-by='.lastTimestamp', não lastTimestamp. Sem o ponto, o comando devolve silenciosamente uma lista sem ordenação.
• Eventos são presos a um namespace. Sem -n você está olhando o namespace padrão e não vê nada de production. Para o quadro completo use --all-namespaces.

Perguntas relacionadas

Logs ou eventos — por onde começar? Pelos eventos. Eles dizem se a aplicação sequer chegou a iniciar. Logs só importam depois que o container está de fato rodando.

Por que kubectl logs vem vazio? Ou o container nunca iniciou, ou não escreve no stdout, ou já reiniciou. Os eventos respondem os dois primeiros casos; a flag --previous responde o terceiro.

Qual a diferença entre kubectl events e kubectl get events? O comando independente kubectl events surgiu depois e ordena por tempo por padrão. get events funciona em todo lugar, incluindo clusters mais antigos.

Veja também

• Docker e Kubernetes: a memória muscular, substituída
• Docker comeu seu disco: como recuperar o espaço
• Leia os logs de um serviço com journalctl

CliAI transforma uma pergunta em linguagem natural sobre um pod no comando kubectl certo, sem você precisar decorar seletores de campo ou a sintaxe do JSONPath. Instale em uma linha.