性能文章>如何收集pod重启前现场>

如何收集pod重启前现场原创

11月前
296800

之前分享过几篇优化pod重启的文章,有朋友发私信问:看你的优化文章很过瘾,可否分享下如何收集pod重启前的现场。

 

案例分享-full gc导致k8s pod重启

记一次k8s pod频繁重启的优化之旅

 

的确是个好问题,之前写文章的时候忽略了这一点,一个完整的现场对破案的作用不言而喻,今天花点时间和大伙探讨一下。

 

守株待兔阶段

这个时期处于人工盯屏阶段,打开rancher(一款k8s集群管理工具)界面观察pod的状态,如果发现pod的状态变成下图(Container with unready status意味着健康检查失败)这样的时候立刻进入容器的命令行使用jmap命令收集dump信息。

 

显然运气的成分多一些,比较浪费时间。

 

全自动阶段

盯屏效率太低,有没有机制能在pod重启前自动收集现场,无人值守,为开发在事后分析提供充分的证据。

 

接下来就是今天的主角登场,容器的生命周期回调,Kubernetes 为容器提供了生命周期回调。回调使容器能够了解其管理生命周期中的事件,并在执行相应的生命周期回调时运行在处理程序中实现的代码。

 

有两个回调暴露给容器:

PostStart

这个回调在容器被创建之后立即被执行。但是,不能保证回调会在容器入口点(ENTRYPOINT)之前执行。没有参数传递给处理程序。

PreStop

在容器因 API 请求或者管理事件(诸如存活态探针、启动探针失败、资源抢占、资源竞争等) 而被终止之前,此回调会被调用。如果容器已经处于已终止或者已完成状态,则对 preStop 回调的调用将失败。在用来停止容器的 TERM 信号被发出之前,回调必须执行结束。Pod 的终止宽限周期在 PreStop 回调被执行之前即开始计数, 所以无论回调函数的执行结果如何,容器最终都会在 Pod 的终止宽限期内被终止。没有参数会被传递给处理程序。

我们最终决定借助PreStop回调来实现自动收集现场,配置如下:

lifecycle:
          preStop:
            exec:
              command:
              - /bin/sh
              - -c
              - pid=`ps -ef |grep java | grep -v grep |awk '{print $1}'`; jmap -dump:format=b,file=/data/dump/${JAR_NAME}.dump
                ${pid}

大致意思是在容器销毁前通过jmap命令收集dump到指定目录。

有两点需要特别说明:

1.注意这个目录需要做持久化,而且要及时清理减少磁盘占用,因为日常的发布也会触发preStop;

2.另一个需要注意的是终止宽限期-terminationGracePeriodSeconds需要调整,给jmap预留充分的时间保留现场,也不能太长,调长的副作用是滚动发布会变慢。

 

推荐阅读

https://kubernetes.io/zh-cn/docs/concepts/containers/container-lifecycle-hooks/

 

https://a.perfma.net/img/5202472

点赞收藏
踩刀诗人

聊聊技术,唠唠段子,偶尔做菜写诗,欢迎关注我的公众号 踩刀诗人

请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

API性能调优
0
0