K8s节点OOM驱逐Pod故障监控方法

我的天呀

前言

在K8s的Node节点上经常有其他进程和Pod争抢内存资源，导致该Node出现OOM现象，最终导致运行在该Node节点上Pod被OS给Kill掉；
采用监控系统和日志系统对该现象进行监控报警，并通过日志系统收集的日志进行佐证；
 
一、Top命令

我们平时会部署一些应用到Linux服务器，所以经常需要了解服务器的运行状态；
Top命令是帮助我们了解服务器当前的CPU、内存、进程状态的实用工具；
1.快速入门

1. (base) [root@docker /]# top
2. top - 09:57:23 up 137 days, 25 min,  2 users,  load average: 0.05, 0.03, 0.05
3. Tasks: 148 total,   1 running, 147 sleeping,   0 stopped,   0 zombie
4. %Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
5. KiB Mem : 32779568 total, 31119584 free,   636676 used,  1023308 buff/cache
6. KiB Swap:        0 total,        0 free,        0 used. 31707740 avail Mem
8.   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                 
9. 8753 root      20   0  822868  47888   8040 S   0.7  0.1  11:52.10 python3.8                                                               
10.     1 root      20   0  191028   4040   2604 S   0.0  0.0   0:46.16 systemd                                                                 
11.     2 root      20   0       0      0      0 S   0.0  0.0   0:00.26 kthreadd                                                               
12.     4 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H                                                            
13.     5 root      20   0       0      0      0 S   0.0  0.0   0:01.76 kworker/u16:0                                                           
14.     6 root      20   0       0      0      0 S   0.0  0.0   0:00.01 ksoftirqd/0                                                            
15.     7 root      rt   0       0      0      0 S   0.0  0.0   0:00.06 migration/0                                                            
16.     8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh                                                                  
17.     9 root      20   0       0      0      0 S   0.0  0.0   3:13.03 rcu_sched                                                               
18.    10 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 lru-add-drain                                                           
19.    11 root      rt   0       0      0      0 S   0.0  0.0   0:46.57 watchdog/0                                                              
20.    12 root      rt   0       0      0      0 S   0.0  0.0   0:41.06 watchdog/1                                                              
21.    13 root      rt   0       0      0      0 S   0.0  0.0   0:00.05 migration/1                                                            
22.    14 root      20   0       0      0      0 S   0.0  0.0   0:00.02 ksoftirqd/1                                                            
23.    16 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/1:0H                                                            
24.    17 root      rt   0       0      0      0 S   0.0  0.0   0:39.13 watchdog/2                                                              
25.    18 root      rt   0       0      0      0 S   0.0  0.0   0:00.07 migration/2                                                            
26.    19 root      20   0       0      0      0 S   0.0  0.0   0:00.01 ksoftirqd/2                                                            
27.    21 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/2:0H                                                            
28.    22 root      rt   0       0      0      0 S   0.0  0.0   0:40.14 watchdog/3      

复制代码

2.系统状态概览

第一行是对当前Linux系统情况的整体概况；

1. top - 09:57:23 up 137 days, 25 min,  2 users,  load average: 0.05, 0.03, 0.05

复制代码

top:当前处在Top命令模式，系统时间
up：Linux操作系统运行了多久
users：当前活跃用户
load average：5分钟、10分钟、15分钟之内的CPU负载
2.1.load average

Linux系统中的Load是对当前CPU工作量的度量，简单的说是进程队列的长度。
Load Average 就是一个时间段 (1 分钟、5分钟、15分钟) 内CPU的平均 Load 。
2.2.如何衡量cpu load

假设1台电脑只有1个CPU，所有进程中的运算任务，都必须由这1个CPU来完成。
那么，我们不妨把这个CPU想象成1座单向通行大桥，桥上只有1根车道，所有车辆都必须从这1根车道上通过。
2.2.1.系统负荷为0

意味着大桥上1辆车也没有。

2.2.2.系统负荷为0.5

意味着大桥的一半，被车流占用了。

2.2.3.系统负荷为1.0

意味着大桥的全部，被车流占满了，但是直到此时该大桥还是能顺畅通行的，没有堵车；

2.2.4.系统负荷为1.7

大桥在通车的时候, 不光桥上的车流会影响通车的效率, 后面排队等着还没有上桥的车也增加道路的拥堵,；
如果把等待进入大桥的车，也算到负载中去, 那么Load就会 > 1.0.
例：系统负荷为1.7，意味着车辆太多了，大桥已经被占满了（100%），后面等待上桥的车辆为大桥上车辆的70%。

2.2.5.系统负荷高会造成什么影响？

以此类推，系统负荷2.0，意味着等待上桥的车辆与桥面的车辆一样多；
系统负荷3.0，意味着等待上桥的车辆是桥面车辆的2倍。
总之，当cpu load大于1时，后面的车辆（进程）就必须等待了，系统负荷越大，过桥的时间就越久。
2.3.cpu load和cpu使用率

CPU Load 低 CPU利用率低 ：CPU资源良好，系统运行正常
CPU Load 低 CPU利用率高：确定程序是否有问题，少量进程消耗大量COP计算资源
CPU Load 高 CPU利用率低：程序中IO操作比较多，导致系统出现IO瓶颈；
CPU Load 高 CPU利用率高：CPU资源不足
3.进程状态概览

1. Tasks: 148 total,   1 running, 147 sleeping,   0 stopped,   0 zombie

复制代码

Tasks：当前系统中运行的进程总数
Running：当前系统中处在running  状态的进程个数
Sleeping：当前系统中处在sleeping状态的进程个数
Stopped：当前系统中处在Stopped状态的进程个数
Zombie：当前系统中处在Zombie状态的进程个数，子进程比父进程先结束，父进程无法获取到子进程的Exit状态，该进程称为僵尸进程。
4.CPU状态概览

1. %Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

复制代码

CPU分为用户态和内核态

us：CPU在用户态花费的时间 ，应该