K8s节点OOM驱逐Pod故障监控方法
前言在K8s的Node节点上经常有其他进程和Pod争抢内存资源，导致该Node出现OOM现象，最终导致运行在该Node节点上Pod被OS给Kill掉；
采用监控系统和日志系统对该现象进行监控报警，并通过日志系统收集的日志进行佐证；
一、Top命令
我们平时会部署一些应用到Linux服务器，所以经常需要了解服务器的运行状态；
Top命令是帮助我们了解服务器当前的CPU、内存、进程状态的实用工具；
1.快速入门
(base) # top
top - 09:57:23 up 137 days, 25 min,2 users,load average: 0.05, 0.03, 0.05
Tasks: 148 total, 1 running, 147 sleeping, 0 stopped, 0 zombie
%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
KiB Mem : 32779568 total, 31119584 free, 636676 used,1023308 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 31707740 avail Mem
PID USER PRNI VIRT RES SHR S%CPU %MEM TIME+ COMMAND
8753 root 20 082286847888 8040 S 0.70.111:52.10 python3.8
1 root 20 0191028 4040 2604 S 0.00.0 0:46.16 systemd
2 root 20 0 0 0 0 S 0.00.0 0:00.26 kthreadd
4 root 0 -20 0 0 0 S 0.00.0 0:00.00 kworker/0:0H
5 root 20 0 0 0 0 S 0.00.0 0:01.76 kworker/u16:0
6 root 20 0 0 0 0 S 0.00.0 0:00.01 ksoftirqd/0
7 root rt 0 0 0 0 S 0.00.0 0:00.06 migration/0
8 root 20 0 0 0 0 S 0.00.0 0:00.00 rcu_bh
9 root 20 0 0 0 0 S 0.00.0 3:13.03 rcu_sched
10 root 0 -20 0 0 0 S 0.00.0 0:00.00 lru-add-drain
11 root rt 0 0 0 0 S 0.00.0 0:46.57 watchdog/0
12 root rt 0 0 0 0 S 0.00.0 0:41.06 watchdog/1
13 root rt 0 0 0 0 S 0.00.0 0:00.05 migration/1
14 root 20 0 0 0 0 S 0.00.0 0:00.02 ksoftirqd/1
16 root 0 -20 0 0 0 S 0.00.0 0:00.00 kworker/1:0H
17 root rt 0 0 0 0 S 0.00.0 0:39.13 watchdog/2
18 root rt 0 0 0 0 S 0.00.0 0:00.07 migration/2
19 root 20 0 0 0 0 S 0.00.0 0:00.01 ksoftirqd/2
21 root 0 -20 0 0 0 S 0.00.0 0:00.00 kworker/2:0H
22 root rt 0 0 0 0 S 0.00.0 0:40.14 watchdog/3 2.系统状态概览
第一行是对当前Linux系统情况的整体概况；
top - 09:57:23 up 137 days, 25 min,2 users,load average: 0.05, 0.03, 0.05top:当前处在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.进程状态概览
Tasks: 148 total, 1 running, 147 sleeping, 0 stopped, 0 zombieTasks：当前系统中运行的进程总数
Running：当前系统中处在running 状态的进程个数
Sleeping：当前系统中处在sleeping状态的进程个数
Stopped：当前系统中处在Stopped状态的进程个数
Zombie：当前系统中处在Zombie状态的进程个数，子进程比父进程先结束，父进程无法获取到子进程的Exit状态，该进程称为僵尸进程。
4.CPU状态概览
%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 stCPU分为用户态和内核态
us：CPU在用户态花费的时间 ，应该
页:
[1]