以下是整理后的事故报告，使用Markdown格式：
接口超时事故报告
1. 事故概述
早晨接到上游反馈，调用我们的接口出现超时情况，但我们系统未收到任何报警。
2. 问题排查
2.1 初步调查
- 上游通过Kong网关请求我们的服务
- 第一次请求超时，客户端内部重试后成功
- 我们的系统只能看到成功请求的日志，无法看到失败请求
2.2 Kong日志分析
发现以下错误，出现82次：
*355713994 connect failed (113: No route to host) while connecting to upstream,", upstream: "grpc://10.120.162.183:8023"
2.3 Pod状态检查
- 初步判断可能是Pod挂起或假死
- Pod表面状态正常
- K8s健康检查机制每10分钟一次，存在漏检可能
2.4 资源使用情况
通过Grafana监控发现：
- CPU使用率逐渐接近扩容临界值
- 推测某个Pod压力过大，导致状态不佳
- 未触发自动扩容机制
3. 原因分析
- 单个Pod CPU压力过大
- 健康检查间隔较长，未能及时发现问题
- 自动扩容机制未及时触发
4. 后续措施
- 调整单个Pod的CPU request和limit上限
- 关注Kong的日志报警
- 考虑缩短健康检查间隔
- 优化自动扩容策略
5. 总结
本次事故主要由于单个Pod资源压力过大，coupled with 健康检查和自动扩容机制的不足导致。通过调整资源配置和优化监控机制，可以提高系统的稳定性和可靠性。
