故障现象

收到监控告警：线上环境k8s中node1上swap分区使用率超过50%。

登录到node1上使用top -->m发现swap分区占用率达到98%，但是内存使用率不到8%；

故障分析

1、swap分区使用率太高肯定是因为内存不够引起的，但是top看出内存利用率极低（256G，使用不到8%），这明显问题不在这里；

2、可能是swappiness参数导致？
使用cat /proc/sys/vm/swappiness 结果显示60 ，Linux默认就是60，同一批购买的其他机器上参数一样，却没有这个现象；如果将参数值调低，让进程尽可能的使用内存。此方法可能会有效，但是，这是线上环境，不敢随意修改内核参数；

3、排查看看是那个进程过多占用swap分区，网上找了很多方案，查出来的进程占用居然都是“0”。？？？
直接就麻爪了。。。事情还是要做，毕竟这是线上环境。

另辟蹊径排查

既然排查所有进程都没有占用swap分区，那么就一个一个业务进程排查；因为这是k8s的node，上面没有部署其他裸服务，全都是容器进程。那就先排查容器。先看每个容器的日志，基本上没啥问题；那就访问一下，如果是内存相关的问题，那么此业务访问应该很慢。通过访问发现只有prometheus这个pod的UI访问及其慢，那么很大问题可能就是这个prometheus业务导致的。

重启prometheus这个pod，发现没啥用；

登录这个pod也是及其卡，基本上登录不进去。这不就是资源不够的典型现象吗？然后直接删除这个deployment，发现swap就没有被占用了。妥妥的就是这个prometheus引起的了。查看prometheus的deployment的部署文件，里边有resource资源限制。为了测试直接注释掉资源限制配置。重新部署发现对应节点的swap分区没有被占用，内存略微有升高。prometheus的UI登录也比较流畅了。

至此问题解决。

总结

根据排查步骤以及结果反推：取消资源限制过后，使用kubectl top命令查看prometheus的pod内存占用为12G多，但是原来yaml文件资源限制是4G，内存完全不够，所以这个pod就认为自己内存不足，需要占用swap分区，这就导致对应node上的swap分区占用率极速上升。