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应用如果有线程堵塞会造成什么影响(了解多线程的具体原理)

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐