Disponibilidade de Material de Apoio

Esta cópia do catálogo contém as orientações embutidas abaixo, mas não inclui os seguintes caminhos de suporte. Eles são pré-requisitos externos, não arquivos incluídos:

• <support-root>/references/failure-patterns.md

Solicite o material de suporte original ou uma instalação existente antes de usar uma etapa que dependa desses caminhos; este catálogo não identifica uma fonte de download verificada para eles. Resolva cada caminho em relação a essa instalação, inspecione seu conteúdo e verifique quaisquer licenças e pré-requisitos de execução aplicáveis. Não execute um comando nem afirme que um procedimento referenciado foi seguido até que seu arquivo necessário exista. Não crie os scripts ausentes nem trate um arquivo não relacionado com o mesmo nome como equivalente. Etapas independentes totalmente documentadas aqui podem prosseguir dentro do escopo autorizado do usuário; relate qualquer etapa dependente como indisponível.

Debug Buttercup

Quando Usar

• Pods no namespace crs estão em CrashLoopBackOff, OOMKilled ou reiniciando
• Vários serviços reiniciam simultaneamente (falha em cascata)
• Redis está sem resposta ou mostrando avisos de AOF
• Filas estão crescendo, mas tarefas não estão progredindo
• Nós mostram DiskPressure, MemoryPressure ou PID pressure
• Build-bot não consegue alcançar o daemon Docker (falhas DinD)
• Scheduler está travado e não avançando o estado da tarefa
• Sondas de verificação de integridade estão falhando inesperadamente
• Valores de Helm implantados não correspondem à configuração real do pod

Quando NÃO Usar

• Implantando ou atualizando Buttercup (use guias de Helm e de implantação)
• Depurando problemas fora do namespace Kubernetes crs
• Ajuste de desempenho que não envolve um sintoma de falha

Namespace e Serviços

Todos os pods rodam no namespace crs. Serviços principais:

Fluxo de Trabalho de Triagem

Sempre comece com a triagem. Execute estes três comandos primeiro:

# 1. Pod status - look for restarts, CrashLoopBackOff, OOMKilled
kubectl get pods -n crs -o wide

# 2. Events - the timeline of what went wrong
kubectl get events -n crs --sort-by='.lastTimestamp'

# 3. Warnings only - filter the noise
kubectl get events -n crs --field-selector type=Warning --sort-by='.lastTimestamp'

Em seguida, restrinja:

# Why did a specific pod restart? Check Last State Reason (OOMKilled, Error, Completed)
kubectl describe pod -n crs <pod-name> | grep -A8 'Last State:'

# Check actual resource limits vs intended
kubectl get pod -n crs <pod-name> -o jsonpath='{.spec.containers[0].resources}'

# Crashed container's logs (--previous = the container that died)
kubectl logs -n crs <pod-name> --previous --tail=200

# Current logs
kubectl logs -n crs <pod-name> --tail=200

Problemas Históricos vs. Atuais

Altas contagens de reinicialização não significam necessariamente que um problema está em andamento -- reinicializações se acumulam ao longo da vida útil de um pod. Sempre distinga:

• --tail mostra o final do buffer de log, que pode conter mensagens antigas. Use --since=300s para confirmar que os problemas estão acontecendo ativamente agora.
• --timestamps na saída do log ajuda a correlacionar eventos entre serviços.
• Verifique os carimbos de data/hora de Last State em describe pod para ver quando o crash mais recente realmente ocorreu.

Detecção de Cascata

Quando muitos pods reiniciam aproximadamente ao mesmo tempo, verifique uma falha de dependência compartilhada antes de investigar pods individuais. A cascata mais comum: Redis cai -> todo serviço recebe ConnectionError/ConnectionRefusedError -> reinicializações em massa. Procure o mesmo erro em vários logs de --previous -- se todos disserem redis.exceptions.ConnectionError, depure o Redis, não os serviços individuais.

Análise de Logs

# All replicas of a service at once
kubectl logs -n crs -l app=fuzzer-bot --tail=100 --prefix

# Stream live
kubectl logs -n crs -l app.kubernetes.io/name=redis -f

# Collect all logs to disk (existing script)
bash deployment/collect-logs.sh

Pressão de Recursos

# CPU/memória por pod
kubectl top pods -n crs

# Nível do nó
kubectl top nodes

# Condições do nó (pressão de disco, pressão de memória, pressão de PID)
kubectl describe node <node> | grep -A5 Conditions

# Uso de disco dentro de um pod
kubectl exec -n crs <pod> -- df -h

# O que está consumindo disco

…