K8s 环境下 Buttercup 服务的故障排查与诊断指南

解决 Buttercup 集群在 crs 命名空间中出现的 Pod 频繁重启、内存溢出（OOM）、Redis 响应缓慢或服务级联崩溃等稳定性问题。

为什么需要这个技能

在复杂的分布式系统中，单个组件（如 Redis）的失效往往会导致整个服务链路崩溃，产生难以追踪的级联失败。对于 Buttercup 这样依赖 Redis 队列和 K8s 编排的系统，简单的 kubectl logs 往往不足以快速定位根因。

本技能提供了一套结构化的 triage（分诊）工作流，帮助开发者快速区分是单个 Pod 的资源问题，还是底层的存储、网络或依赖服务故障，避免在错误的方向上浪费调试时间。

适用场景

• Pod 状态异常：crs 命名空间内的 Pod 处于 CrashLoopBackOff 或被 OOMKilled。
• 级联故障：多个服务同时重启，且日志中出现大量连接错误。
• Redis 性能问题：Redis 响应缓慢、出现 AOF 写入警告或内存压力。
• 任务停滞：队列长度持续增加，但任务处理没有进展。
• 资源压力：节点出现 DiskPressure 或 MemoryPressure。

核心工作流

1. 快速分诊 (Triage)

首先执行以下命令获取全貌，重点查看重启次数和警告事件：

# 查看 Pod 状态与重启次数
kubectl get pods -n crs -o wide

# 按时间排序查看所有事件
kubectl get events -n crs --sort-by='.lastTimestamp'

# 仅过滤警告信息
kubectl get events -n crs --field-selector type=Warning --sort-by='.lastTimestamp'

2. 根因定位

针对可疑 Pod，分析其最后一次崩溃的原因及实时资源状态：

# 查看 Pod 崩溃原因（如 OOMKilled）
kubectl describe pod -n crs <pod-name> | grep -A8 'Last State:'

# 查看崩溃前的最后 200 行日志
kubectl logs -n crs <pod-name> --previous --tail=200

3. 级联失效检测

如果多个服务同时重启，优先检查 Redis。若所有服务日志均显示 redis.exceptions.ConnectionError，应立即停止排查业务 Pod，转而诊断 Redis：

# 检查 Redis 内存与持久化状态
kubectl exec -n crs <redis-pod> -- redis-cli INFO memory
kubectl exec -n crs <redis-pod> -- redis-cli INFO persistence

4. 队列与压力分析

检查 Redis Stream 队列长度以确认任务是否积压：

# 检查构建队列长度
kubectl exec -n crs <redis-pod> -- redis-cli XLEN fuzzer_build_queue

# 检查节点资源压力
kubectl top nodes
kubectl describe node <node> | grep -A5 Conditions

下载和安装

下载 debug-buttercup 中文版 Skill ZIP

解压后将目录放入你的 AI 工具 skills 文件夹，重启工具后即可使用。具体路径参考内附的 USAGE.zh.md。

你可能还需要

暂无推荐