---

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 和部署指南）
• 调试 crs Kubernetes 命名空间之外的问题
• 不涉及故障症状的性能调优

命名空间和服务

所有 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