linux 磁盘IO满导致的宿主机卡机,pod失败(/kubepods/besteffort/pod4909103c-cdc)

本文主要是介绍linux 磁盘IO满导致的宿主机卡机,pod失败(/kubepods/besteffort/pod4909103c-cdc),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

背景

开发机上装了minikube,起了一个docker镜像当minikube的宿主机,在启动了一定量的deployment A之后,deployment A就全挂了(启动1~2个deployment A,没有问题,启动到第三个,就全挂)。然后宿主机卡爆。

查询pod挂的原因

kubectl describe pod ...Exit Code:    137Started:      Wed, 29 Sep 2021 16:02:30 +0800Finished:     Wed, 29 Sep 2021 16:04:19 +0800Ready:          FalseRestart Count:  12
...

看到了其中镜像挂了的返回值是137,此状态码一般是因为 pod 中容器内存达到了它的资源限制(resources.limits),一般是内存溢出(OOM),CPU达到限制只需要不分时间片给程序就可以。因为限制资源是通过 linux 的 cgroup 实现的,所以 cgroup 会将此容器强制杀掉,类似于 kill -9。
但是通过top查看发现cpu和内存都没满,但是内存交换满了(KiB Swap),感觉是因为宿主机没资源了,所以干掉pod中的资源,接着往下查,寻找更多node的信息。

因为minikube是起在docker中的,所以查看一下docker状态

docker stats94ec0f757f48        banfushen6_elasticsearch_1         1.24%               1.653GiB / 4.657GiB   35.49%              9.15GB / 6.79GB     85.3MB / 38.6GB     205
a57d56927433        banfushen6_dynamodb_1              17.73%              329.7MiB / 31.42GiB   1.02%               223MB / 188MB       17MB / 12.3kB       86
6aa3384e7433        banfushen6_mongooseim_1            0.02%               287.6MiB / 31.42GiB   0.89%               4.22MB / 0B         19.3MB / 1.03MB     27
6f8203c6c8bd        banfushen6_rabbitmq_1              0.11%               98.38MiB / 31.42GiB   0.31%               4.22MB / 0B         19.9MB / 3.94MB     307
722f40c6405f        minikube                           205.57%             7.398GiB / 7.812GiB   94.69%              441MB / 8.04MB      4.08MB / 48.1kB     2218

这下,找到了pod失败的原因。接下来查找宿主机卡住的原因。

查看node信息

kubectl describe node minikube
Name:               minikube
Roles:              master
Labels:             beta.kubernetes.io/arch=amd64beta.kubernetes.io/os=linuxkubernetes.io/arch=amd64kubernetes.io/hostname=minikubekubernetes.io/os=linuxminikube.k8s.io/commit=2c82918e2347188e21c4e44c8056fc80408bce10minikube.k8s.io/name=minikubeminikube.k8s.io/updated_at=2021_07_20T17_14_34_0700minikube.k8s.io/version=v1.14.2node-role.kubernetes.io/master=
Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.socknode.alpha.kubernetes.io/ttl: 0volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Tue, 20 Jul 2021 17:14:27 +0800
Taints:             <none>
Unschedulable:      false
Conditions:Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message----             ------  -----------------                 ------------------                ------                       -------MemoryPressure   False   Wed, 29 Sep 2021 17:02:14 +0800   Wed, 29 Sep 2021 16:37:39 +0800   KubeletHasSufficientMemory   kubelet has sufficient memory availableDiskPressure     False   Wed, 29 Sep 2021 17:02:14 +0800   Wed, 29 Sep 2021 16:37:39 +0800   KubeletHasNoDiskPressure     kubelet has no disk pressurePIDPressure      False   Wed, 29 Sep 2021 17:02:14 +0800   Wed, 29 Sep 2021 16:37:39 +0800   KubeletHasSufficientPID      kubelet has sufficient PID availableReady            True    Wed, 29 Sep 2021 17:02:14 +0800   Wed, 29 Sep 2021 16:57:04 +0800   KubeletReady                 kubelet is posting ready status

看到了这句话kubelet has no disk pressure,在结合之前top的交换内存满了,判定磁盘的问题。通过公司的monitor查看到机器的磁盘io使用率已满。
在这里插入图片描述

找出导致io爆炸的容器

我先用了pidstat -d 1查看哪个进程对io的占用最高,但是缺没找到任何相关信息,然后直接在宿主机查看内核日志

cat /var/log/messages | ag killedSep 29 17:50:31 bfs kernel: [5618442.047786] Task in /docker/722f40c6405f6933ac2722e40a40fef4c52e36b2ba0e44bdd1a8aba0027ca313/kubepods/besteffort/pod4909103c-cdc2-432e-92aa-2e06c2c7d1e3/9d62c1f82041c40d691498b2ded86caa663404489f7c3a62ad37c72eb2470911 killed as a result of limit of /docker/722f40c6405f6933ac2722e40a40fef4c52e36b2ba0e44bdd1a8aba0027ca313

可以看到,docker被内核干掉了,拿到docker的id前缀,去查找看是什么容器造成的。

docker@minikube:~$ docker ps | grep  e5bdaaef
e5bdaaefff4a        7c797432e61c           "/usr/local/bin/dock…"   11 minutes ago      Up 11 minutes                               k8s_elasticsearch

发现,原来是pod中启动了es,多个es导致io炸裂,最后修改pod资源,不启动es,解决问题

这篇关于linux 磁盘IO满导致的宿主机卡机,pod失败(/kubepods/besteffort/pod4909103c-cdc)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/320859

相关文章

防止Linux rm命令误操作的多场景防护方案与实践

《防止Linuxrm命令误操作的多场景防护方案与实践》在Linux系统中,rm命令是删除文件和目录的高效工具,但一旦误操作,如执行rm-rf/或rm-rf/*,极易导致系统数据灾难,本文针对不同场景... 目录引言理解 rm 命令及误操作风险rm 命令基础常见误操作案例防护方案使用 rm编程 别名及安全删除

Linux下MySQL数据库定时备份脚本与Crontab配置教学

《Linux下MySQL数据库定时备份脚本与Crontab配置教学》在生产环境中,数据库是核心资产之一,定期备份数据库可以有效防止意外数据丢失,本文将分享一份MySQL定时备份脚本,并讲解如何通过cr... 目录备份脚本详解脚本功能说明授权与可执行权限使用 Crontab 定时执行编辑 Crontab添加定

使用docker搭建嵌入式Linux开发环境

《使用docker搭建嵌入式Linux开发环境》本文主要介绍了使用docker搭建嵌入式Linux开发环境,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面... 目录1、前言2、安装docker3、编写容器管理脚本4、创建容器1、前言在日常开发全志、rk等不同

linux系统上安装JDK8全过程

《linux系统上安装JDK8全过程》文章介绍安装JDK的必要性及Linux下JDK8的安装步骤,包括卸载旧版本、下载解压、配置环境变量等,强调开发需JDK,运行可选JRE,现JDK已集成JRE... 目录为什么要安装jdk?1.查看linux系统是否有自带的jdk:2.下载jdk压缩包2.解压3.配置环境

Linux搭建ftp服务器的步骤

《Linux搭建ftp服务器的步骤》本文给大家分享Linux搭建ftp服务器的步骤,本文通过图文并茂的形式给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录ftp搭建1:下载vsftpd工具2:下载客户端工具3:进入配置文件目录vsftpd.conf配置文件4:

Linux实现查看某一端口是否开放

《Linux实现查看某一端口是否开放》文章介绍了三种检查端口6379是否开放的方法:通过lsof查看进程占用,用netstat区分TCP/UDP监听状态,以及用telnet测试远程连接可达性... 目录1、使用lsof 命令来查看端口是否开放2、使用netstat 命令来查看端口是否开放3、使用telnet

SysMain服务可以关吗? 解决SysMain服务导致的高CPU使用率问题

《SysMain服务可以关吗?解决SysMain服务导致的高CPU使用率问题》SysMain服务是超级预读取,该服务会记录您打开应用程序的模式,并预先将它们加载到内存中以节省时间,但它可能占用大量... 在使用电脑的过程中,CPU使用率居高不下是许多用户都遇到过的问题,其中名为SysMain的服务往往是罪魁

Linux系统管理与进程任务管理方式

《Linux系统管理与进程任务管理方式》本文系统讲解Linux管理核心技能,涵盖引导流程、服务控制(Systemd与GRUB2)、进程管理(前台/后台运行、工具使用)、计划任务(at/cron)及常用... 目录引言一、linux系统引导过程与服务控制1.1 系统引导的五个关键阶段1.2 GRUB2的进化优

Linux查询服务器 IP 地址的命令详解

《Linux查询服务器IP地址的命令详解》在服务器管理和网络运维中,快速准确地获取服务器的IP地址是一项基本但至关重要的技能,下面我们来看看Linux中查询服务器IP的相关命令使用吧... 目录一、hostname 命令:简单高效的 IP 查询工具命令详解实际应用技巧注意事项二、ip 命令:新一代网络配置全

linux安装、更新、卸载anaconda实践

《linux安装、更新、卸载anaconda实践》Anaconda是基于conda的科学计算环境,集成1400+包及依赖,安装需下载脚本、接受协议、设置路径、配置环境变量,更新与卸载通过conda命令... 目录随意找一个目录下载安装脚本检查许可证协议,ENTER就可以安装完毕之后激活anaconda安装更