
关于
所有 Pod 运行在 crs 命名空间。当 crs 命名空间中的 Pod 处于 CrashLoopBackOff、OOMKilled 或重启状态时使用。
name: debug-buttercup description: "所有 Pod 运行在 crs 命名空间中。当 crs 命名空间中的 Pod 处于 CrashLoopBackOff、OOMKilled 或重启状态,多个服务同时重启(级联故障),或 Redis 无响应或显示 AOF 警告时使用。" risk: unknown source: community
调试 Buttercup
何时使用
crs命名空间中的 Pod 处于 CrashLoopBackOff、OOMKilled 或重启状态- 多个服务同时重启(级联故障)
- Redis 无响应或显示 AOF 警告
- 队列持续增长但任务未推进
- 节点显示 DiskPressure、MemoryPressure 或 PID 压力
- Build-bot 无法连接 Docker 守护进程(DinD 故障)
- 调度器卡住且未推进任务状态
- 健康检查探针意外失败
- 已部署的 Helm 值与实际 Pod 配置不匹配
不应使用的情况
- 部署或升级 Buttercup(请使用 Helm 和部署指南)
- 调试
crsKubernetes 命名空间之外的问题 - 不涉及故障症状的性能调优
命名空间和服务
所有 Pod 运行在命名空间 crs 中。关键服务:
| 层级 | 服务 | |------|------| | 基础设施 | redis, dind, litellm, registry-cache | | 编排 | scheduler, task-server, task-downloader, scratch-cleaner | | 模糊测试 | build-bot, fuzzer-bot, coverage-bot, tracer-bot, merger-bot | | 分析 | patcher, seed-gen, program-model, pov-reproducer | | 接口 | competition-api, ui |
分诊工作流
始终从分诊开始。首先运行以下三个命令:
# 1. Pod 状态 - 查找重启、CrashLoopBackOff、OOMKilled
kubectl get pods -n crs -o wide
# 2. 事件 - 故障时间线
kubectl get events -n crs --sort-by='.lastTimestamp'
# 3. 仅警告 - 过滤噪音
kubectl get events -n crs --field-selector type=Warning --sort-by='.lastTimestamp'
然后缩小范围:
# 特定 Pod 为何重启?检查 Last State Reason(OOMKilled、Error、Completed)
kubectl describe pod -n crs <pod-name> | grep -A8 'Last State:'
# 检查实际资源限制与预期是否一致
kubectl get pod -n crs <pod-name> -o jsonpath='{.spec.containers[0].resources}'
# 崩溃容器的日志(--previous = 已终止的容器)
kubectl logs -n crs <pod-name> --previous --tail=200
# 当前日志
kubectl logs -n crs <pod-name> --tail=200
历史问题 vs 正在发生的问题
高重启次数不一定意味着问题正在发生——重启次数会在 Pod 生命周期内累积。务必区分:
--tail显示日志缓冲区末尾,可能包含旧消息。使用--since=300s确认问题是否正在活跃发生。- 日志输出中使用
--timestamps有助于跨服务关联事件。 - 检查
describe pod中的Last State时间戳,查看最近一次崩溃的实际发生时间。
级联检测
当多个 Pod 在同一时间段重启时,先检查共享依赖故障,再逐个排查。最常见的级联:Redis 宕机 -> 所有服务收到 ConnectionError/ConnectionRefusedError -> 大规模重启。查看多个 --previous 日志中是否出现相同错误——如果都显示 redis.exceptions.ConnectionError,应调试 Redis 而非各个服务。
日志分析
# 一次查看某服务的所有副本
kubectl logs -n crs -l app=fuzzer-bot --tail=100 --prefix
# 实时流式查看
kubectl logs -n crs -l app.kubernetes.io/name=redis -f
# 将所有日志收集到磁盘(现有脚本)
bash deployment/collect-logs.sh
资源压力
# 每个 Pod 的 CPU/内存
kubectl top pods -n crs
# 节点级别
kubectl top nodes
# 节点状况(磁盘压力、内存压力、PID 压力)
kubectl describe node <node> | grep -A5 Conditions
# Pod 内部磁盘使用情况
kubectl exec -n crs <pod> -- df -h
# 查看磁盘占用来源
kubectl exec -n crs <pod> -- sh -c 'du -sh /corpus/* 2>/dev/null'
kubectl exec -n crs <pod> -- sh -c 'du -sh /scratch/* 2>/dev/null'
Redis 调试
Redis 是核心骨干。当它宕机时,一切都会级联故障。
# Redis Pod 状态
kubectl get pods -n crs -l app.kubernetes.io/name=redis
# Redis 日志(AOF 警告、OOM、连接问题)
kubectl logs -n crs -l app.kubernetes.io/name=redis --tail=200
# 连接 Redis CLI
kubectl exec -n crs <redis-pod> -- redis-cli
# 在 redis-cli 中:关键诊断命令
INFO memory # used_memory_human, maxmemory
INFO persistence # aof_enabled, aof_last_bgrewrite_status, aof_delayed_fsync
INFO clients # connected_clients, blocked_clients
INFO stats # total_connections_received, rejected_connections
CLIENT LIST # 查看已连接的客户端
DBSIZE # 总键数
# AOF 配置
CONFIG GET appendonly # AOF 是否启用?
CONFIG GET appendfsync # fsync 策略:everysec、always 或 no
# /data 挂载在什么上?(磁盘 vs tmpfs 影响 AOF 性能)
kubectl exec -n crs <redis-pod> -- mount | grep /data
兼容工具
Claude CodeCursor
标签
后端开发
