记一次pod频繁重启事故分析

1.背景

某一天下午阿里云频繁打电话给到我的手机，报警内容是waf防火墙的某个域名出现大量5xx报警，我立即去阿里云ack集群查看对应域名的pod状态，发现对应的pod处于重启状态，查看日志与详细信息，发现是存活探针造成的重启。

 这是截取的日志。

2.处理方案

1.我的处理方案是第一时间重启pod，pod在running状态保持一段时间后又开始重启，紧接着业务方开始反馈接口调用不通，开始有用户投诉

2.通过日志我们可以看见是pod去调用其他服务出现超时，我们的pod是没有在资源限制上面做limites限制，所以在k8s层面不会产生oom，而且我第一时间通过监控查看节点与pod的cpu与内存使用率，并没有什么问题

3.网络层面出了问题，比如tcp队列被打满，导致请求得不到处理

4.web容器比如tomcat、jetty的线程池饱和了，这时后来的任务会堆积在线程池的队列中（需要开发配合）

5.jvm卡顿了，比如让开发闻风丧胆的fullgc+stw（需要开发配合）

3.现在一一排查

1.ss  -ntupl查看tcp队列情况，并没有堆积、溢出情况，排除网络层面问题

2.jstack查看线程情况发现一段报错日志：

org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:282

这个正是HttpClient中的连接池满了的迹象，线程在等待可用连接，最终导致jetty的线程被打满，造成服务假死，自然是不能及时响应健康检查，最终触发k8s的重启策略（开发人员分析）

3.后期通过业务部门了解发现是第三方有大量调用操作，但是并没有通知我们运维扩容pod数量，造成这次线上事故。

4.后期思考

1.k8s在应对突发高并发流量我们运维应该如何去做（如何去做好线上环境的hpa）？

2.运维应该如何去了解java应用里面有关线程池，如何在k8s中去评估一个java应用的最大连接数

3.java应用如果有线程堵塞会造成什么影响（了解多线程的具体原理）