这篇文章主要介绍”如何解决k8集群环境内存不足导致容器被杀死问题”,在日常操作中,相信很多人在如何解决k8集群环境内存不足导致容器被杀死问题问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答“如何解决k8集群环境内存不足导致容器被杀死问题”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
<节> <人力资源数据工具=癿dnice编辑器"/>,背景
最近线上环境上出现了一个问题,k8集群环境豆荚中tomcat的容器运行一段时间后直接被killd,但有时一切看起来正常,不能准确判断在什么时机出现被killd问题。
本文就此问题介绍了Linux内存不足原因以及为什么特定进程会被杀死。并提供了Kubernetes集群环境故障排除指南教程。
,tomcat进程被杀死原因分析
当这个应用程序被杀死问题进行故障排除时,很大程度上确定是操作系统杀死的,因为整个过程确认没有进行杀操作。当我查看tomcat日志时发现,tomcat只是简单的提示了killd,至于原因,日志中没有给出详尽的提示。紧接着我查看了syslog日志<代码> grep - i杀死/var/log/messages *>
<代码> Oct 1, 20:37:21 k8swork 内核:,Memory cgroup out of 记忆:,Kill process 13547, (java), score 1273年,趁机sacrifice 孩子,
如果当服务已经挂掉,使用免费查看内存占用,对我们排除问题不会有太大帮助,因为这个时候服务占用内存已经随着服务的挂掉而释放。如下所示:
<代码> [root@k8swork 日志]#,free - lm,
,,,,,,,,,,,,, total ,,,,,, used ,,,,,, free ,,,, shared ,,, buffers ,,,,缓存
Mem:,,,,,,,,,,, 498,,,,,,,,, 93,,,,,,,, 405,,,,,,,,,, 0,,,,,,,,, 15,,,,,,,,, 32
低:,,,,,,,,,,,498,,,,,,,,,93,,,,,,,,405
高:,,,,,,,,,,,,0,,,,,,,,,,0,,,,,,,,,,0
-/+,缓冲/缓存:,,,,,,,,,44岁,,,,,,,,453
互换:,,,,,,,,,1023,,,,,,,,,,0,,,,,,1023,
但是Linux vmstat可以使用以下命令将的输出重定向到文件。我们甚至可以调整持续时间和次数以监控更长的时间。当命令运行时,我们可以随时查看输出文件以查看结果。我们每120秒查看内存1000次。该,行末尾的允许我们将其作为一个进程运行并重新获得终端。
<代码> vmstat -SM 120年,1000年,祝辞,memoryuse.out ,,
通过如上信息可以判定罪魁祸首是这个Java进程占用内存超过资源限制,直接被系统杀死。为什么会出现这个问题呢?
首先第一点,已经在编排文件中限制资源最大使用量为4 g,理论上豆荚中容器是不可能占用这么多资源,默认情况下Java占用物理资源的1/4左右,但是既然出现了这个问题,说明Java进程占用资源超过了这个限制。
于是在网上找到了如下信息,大概意思是说,jdk从131版本之后开始通过选项支持对容器对内存和CPU的限制,如下图所示:
<图数据工具=癿dnice编辑器”>
解决方式也很简单,直接在tomcat服务中配置最大最小内存占用,在Java层面限制其内存占用。但是具体Java进程为什么占用这么高的内存就需要业务开发人员排查解决了。
,总结
通过本文可以看出基于Java虚拟机构建项目,在容器化过程中要尽量适配高版本或者对码头工人容器有亲和性的Jdk版本,如果没有,一定要在虚拟机层面限制Java服务占用内存大小。另外一定要在服务上添加存活探针,如果没有添加存活探针,类似于tomcat这种容器类服务,即使内部服务挂了了,Kubernetes不会自动帮你拉起的,原因很简单,它无法感知到你的服务是否存活。所以服务一定要添加Http存活探针(基于TCP层面的探针只是检测端口是否存活,大多数情况下,服务会出现假死问题,但端口依然可以正常访问)。
