K8s内存溢出问题剖析：排查与解决方案

一、背景
二、排查方案：
- [1. 可能是数据量超出了限制的大小，检查数据目录大小](#1. 可能是数据量超出了限制的大小，检查数据目录大小)
- [2. 查看是否是内存溢出](#2. 查看是否是内存溢出)
- - [2.1 排查数据量（查看数据目录大小是否超过limit限制）](#2.1 排查数据量（查看数据目录大小是否超过limit限制）)
  - [2.2 查看pod详情发现问题](#2.2 查看pod详情发现问题)
三、解决过程

一、背景

做redis压测过程中，发现paas环境的redis被OOMKill老是不断重启

Pod日志：

开始排查

limit限制为64G 查到数据目录占用很少忽略此问题

为了更准确的定位问题，查看是否是内存泄露问题，查看系统参数（正常是没有输出）

确定是由于压测导致的Cgroup内存泄露问题

定位原因以后解决问题：处理内存泄露问题（试了三个方案才得以解决）

方案一：（修改grub文件）

修改/etc/default/grub 为：
GRUB_CMDLINE_LINUX="crashkernel=auto net.ifnames=0 biosdevname=0 intel_pstate=disable cgroup.memory=nokmem"
是追加 GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0 crashkernel=512M-2G:128M,2G:512M rd.lvm.lv=bel/root rhgb quiet cgroup.memory=nokmem" 把 cgroup.memory=nokmem
追加到最后即可
生成配置： /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
重启机器： reboot
验证： cat /sys/fs/cgroup/memory/kubepods/burstable/pod*/*/memory.kmem.slabinfo 无输出即可。
x版本cgroup.memory存在bug，docker或其他使用cgroup.memory中kmem功能的应用会造成slab内存泄漏部分系统可以通过升级到4.x的修复版本来解决，或者通过 cgroup.memory=nokmem 启动项来规避。部分系统不支持cgroup.memory=nokmem 启动项，可以通过 cgroup_disable=memory 启动项来规避。（此方案解决部分机器，并未全部解决）

方案二：（升级内核、Iaas建议）

由于服务器均为多系统，可以进行此操作

这种方式的缺点是：需要升级所有节点，节点重启的话已有 pod 肯定要漂移，如果节点规模很大，这个升级操作会很繁琐，业务部门也会有意见，要事先沟通。这个问题归根结底是软件兼容问题，3.x 自己都说了不成熟，不建议你使用该特性，k8s、docker却还要开启这个属性。（此方案并不奏效）

方案三：（grubby在线修改内核参数）

查看当前内核版本

--update-kernel 为当前内核版本文件
grubby --args=cgroup.memory=nokmem --update-kernel=/boot/vmlinuz-3.10.0-1160.el7.x86_64

重启主机查看系统参数（显示正常）

查看pod正常运行

附加知识点：（内存buff占用清理 -hcache）

wget https://silenceshell-1255345740.cos.ap-shanghai.myqcloud.com/hcache
chmod 755 hcache && mv hcache /usr/local/bin/
hcache --top 10

查看内存 free -h

buffers: 用于块设备数据缓冲，记录文件系统metadata（目录，权限，属性等)

cached: 用于文件内容的缓冲

分别查看

清理缓存

清理交换空间：swapoff -a && swapon -a