Pod OOM相关故障梳理及监控，LoadAverag

文章由LinuxBoy分享于2023-03-24 09:03:05热评（88）

Pod OOM相关故障梳理及监控，LoadAverag

前言

Pod因内存不足消失，可能由2种不同的故障导致，其中对故障2的复现、监控比较繁琐、耗时、棘手；

先对Pod oom相关故障进行了梳理；

故障1：Pod自身内存不足

Pod中的运行进程占用空间超出了Pod设置的Limit限制，导致该Pod中进程被Pod内的OS内核Kill掉；

此时Pod的Status为OOMKilled，Pod的OOMKilled状态可以借助Prometheus进行监控；

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]

test-oom.yaml

现象如下

[root@master /]# kubectl delete -f test-oom.yaml 
pod "memory-demo" deleted
[root@master /]# kubectl apply -f test-oom.yaml 
pod/memory-demo created
[root@master /]# kubectl get pod -n mem-example -o wide -w
NAME          READY   STATUS              RESTARTS   AGE   IP       NODE    NOMINATED NODE   READINESS GATES
memory-demo   0/1     ContainerCreating   0          4s    <none>   node1   <none>           <none>
memory-demo   1/1     Running             0          18s   10.244.166.150   node1   <none>           <none>
memory-demo   0/1     OOMKilled           0          19s   10.244.166.150   node1   <none>           <none>

故障2：Node宿主机内存不足

由于Node宿主机内存不足，而跑在Node宿主机上的Pod（Pod中运行的进程）占用的内存空间太多，被Node宿主机的OS内核OOM killed；

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      limits:
        memory: "3Gi"
      requests:
        memory: "3Gi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "500M", "--vm-hang", "1"]

test-oom.yaml

在K8s的Node节点上经常有其他进程和Pod争抢内存资源，导致该Node出现OOM现象，最终导致运行在该Node节点上Pod被OS给Kill掉；

采用监控系统和日志系统对该现象进行监控报警，并通过日志系统收集的日志进行佐证；

stress --vm 4 --vm-bytes 730M --vm-keep

查看K8s node的/var/log/messages日志，发现Pod中运行的stress进程，由于node宿主机内存不足，已经被该node宿主机的OS内核Kill掉了；

一、使用Top命令

我们平时会部署一些应用到Linux服务器，所以经常需要了解服务器的运行状态；

Top命令是帮助我们了解服务器当前的CPU、内存、进程状态的实用工具；

在node宿主机使用top命令查看Pod进程的内存占用情况；

1.top快速入门

(base) [root@docker /]# 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      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                 
 8753 root      20   0  822868  47888   8040 S   0.7  0.1  11:52.10 python3.8                                                               
    1 root      20   0  191028   4040   2604 S   0.0  0.0   0:46.16 systemd                                                                 
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.26 kthreadd                                                                
    4 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H                                                            
    5 root      20   0       0      0      0 S   0.0  0.0   0:01.76 kworker/u16:0                                                           
    6 root      20   0       0      0      0 S   0.0  0.0   0:00.01 ksoftirqd/0                                                             
    7 root      rt   0       0      0      0 S   0.0  0.0   0:00.06 migration/0                                                             
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh                                                                  
    9 root      20   0       0      0      0 S   0.0  0.0   3:13.03 rcu_sched                                                               
   10 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 lru-add-drain                                                           
   11 root      rt   0       0      0      0 S   0.0  0.0   0:46.57 watchdog/0                                                              
   12 root      rt   0       0      0      0 S   0.0  0.0   0:41.06 watchdog/1                                                              
   13 root      rt   0       0      0      0 S   0.0  0.0   0:00.05 migration/1                                                             
   14 root      20   0       0      0      0 S   0.0  0.0   0:00.02 ksoftirqd/1                                                             
   16 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/1:0H                                                            
   17 root      rt   0       0      0      0 S   0.0  0.0   0:39.13 watchdog/2                                                              
   18 root      rt   0       0      0      0 S   0.0  0.0   0:00.07 migration/2                                                             
   19 root      20   0       0      0      0 S   0.0  0.0   0:00.01 ksoftirqd/2                                                             
   21 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/2:0H                                                            
   22 root      rt   0       0      0      0 S   0.0  0.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.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.进程状态概览

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

Tasks：当前系统中运行的进程总数

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 st

CPU分为用户态和内核态

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

sy：CPU在内核态花费的时间，sy+us<80%

id：CPU在空闲状态花费的时间

wa: 进程执行IO操作占用CPU的时间，<30%，不同功能的服务器，阈值不一，邮件服务器的wa很高；

5.内存使用概览

以CentOS-7.6为例

[root@node1 ~]# cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core) 
[root@node1 ~]# cat /proc/version 
Linux version 3.10.0-957.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Thu Nov 8 23:39:32 UTC 2018
[root@node1 ~]#

讲解Linux的内存

KiB Mem : 32779568 total, 31119584 free,   636676 used,  1023308 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 31707740 avail Mem

5.1.buff/cache占用内存的意义

Linux系统设计哲学之一是一切皆文件，所以该系统对IO性能要求比较高；

buffer：用于存放从内存即将输出到磁盘的数据

cache：用于存放从磁盘读取到内存中，待今后使用的数据

Linux借内存空间，造buff/cache，是为了提升Linux系统的IO性能，使Linux用起来更加流畅；

当进程可使用的内存空间严重不足时，Linux会把借用的buff/cache内存空间让进程占用，虽然内存空间还回来了，但此时Linux会变得卡顿起来。

5.2.如何查看进程使用的内存空间大小

[root@node1 ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:           7.1G        2.0G        2.8G        397M        2.3G        4.3G
Swap:            0B          0B          0B
[root@node1 ~]#

total：total=used(进程使用的内存)+buff/cache(提升Linux系统的IO性能花销的内存)+free(空闲的)
used：正在运行的进程使用的内存(used= total – free – buff/cache)
free: 未使用的内存 (free= total – used – buff/cache)
shared：多个进程共享的内存
buffers：内存保留用于内核操作一个进程队列请求
cache：在 RAM 中保存最近使用的文件的页面缓存的大小
buff/cache：Buffers + Cache
available：在不使用Swap分区的前提下，预计有多少内存可用于将程序启动为进程，available = free + buffer/cache (注：只是大概的计算方法）

6.进程详细状态

 PID   USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM  TIME+      COMMAND                                                                 
 8753  root      20   0  822868  47888   8040 S   0.7  0.1  11:52.10   python3.8

PID：进程编号

USER：执行进程的用户

PR（Priority）：进程优先级，由OS决定的；（PR越低越优先被CPU调度），越低越优先

NI（Nice）：进程的Nice值，用户可以设置进程的执行优先权，root（-20到19），普通user 0-19

VIRT(Virtual memory usage )：进程需要的虚拟内存空间大小

RES（Resident Memory Usage）：进程当前实际占用的物理内存大小，但不包括swap out

SHR(Shared Memory）：除了自身进程的共享内存，也包括其他进程的共享内存

S（Status）：进程状态D（Dead）R（运行） T（跟踪/停止）Z（僵尸）

%CPU：当前进程占用CPU时间的百分比

%MEM：当前进程占用内存空间的百分比

TIME+：当前进程使用CPU时间的总和

COMMAND：命令行

6.1.虚拟内存和物理内存的关系

虚拟内存和物理内存通过Page Table关联起来。

虚拟内存空间中着色的部分，分别被映射到物理内存空间对应相同着色的部分。

然而虚拟内存空间中的灰色部分，在物理内存空间中没有与之对应的部分，也就是说灰色部分没有被映射到物理内存空间中。

如此设计是本着“按需映射”的指导思想。

因为虚拟内存空间很大，虚拟内存中很多部分，在1次程序运行过程中根本不需要访问；

所以也就没有必要，将虚拟内存空间中的这些不需要被访问的部分映射到物理内存空间上。

6.2.虚拟内存（Virtual Memory）

VIRT=Swap分区+Resident Memory

虚拟内存是1个假象的内存空间，在程序运行过程中虚拟内存空间中需要被访问的部分会被映射到物理内存空间中。

虚拟内存空间大只能表示1个程序运行过程中可访问的内存空间比较大，不代表占用实际物理内存的空间。

6.3.驻留内存（Resident Memory）

RES=Code+Data

驻留内存，是指那些被映射到虚拟内存空间中的物理内存。

上图中，在系统物理内存空间中被着色的部分都是驻留内存。

比如，A1、A2、A3和A4是进程A的驻留内存，B1、B2和B3是进程B的驻留内存。

驻留内存就是进程实实在在占用的物理内存，一般我们所讲的进程占用了多少内存，其实就是说的占用了多少驻留内存而不是多少虚拟内存。

因为进程的虚拟内存大，并不意味着进程运行过程成所占用的物理内存大。

6.4.共享内存（Shared Memory）

多个进程之间通过共享内存的方式相互通信也会出现了共享内存。

7.常用快捷键

shift+e：切换内存单位显示格式 (可重复按键切换）
z：换是否彩色显示(可复按键换
m：切换内存使用率显示格式(可重复按键切换)
e：切换底部各个进程详细中单位的显示模式 (可重复按键切换)
b：切换高亮选中 (可重复按键切换)
W：把当前配置保存到文件中，下次启动top会使用当前的配置
h：进入帮助菜单(进入菜单后，可按ESC或q退出帮助菜单)
q：退出 top命令

8.字段排序

top底部的进程列表信息是可以选择指定列进行排序的

按f进入字段选择界面
按上下键选择要进行排序的字段/ space键选择该字段是否显示
按下s键激活这个选择
按q键退出排序字段选择界面

二、Node宿主机内存不足监控方案

当Pod被调度在Node宿主机之后，Pod本质就是运行在Node宿主机的1个进程；

ps -ef | grep "app-workspace-373-1675214627414" | grep -v grep

我们可以通过Pod容器中运行的程序名称，来识别该Pod进程；

[root@byg612sv036 ~]# docker ps | grep "app-workspace-373-1675214627414" | grep -v grep
040582751cbc   registry.docker.aimaster.lenovo.com:20443/library/373/workspace                     "jupyter lab --port …"   8 minutes ago    Up 8 minutes              k8s_app-workspace-373-1675214627414-podgroup-pfhh-pod_app-workspace-373-1675214627414-podgroup-pfhh-d42q6_aimaster-user-namespace-373_4881e655-9c3e-41a0-81d7-187ce8bcbafc_0
1d331fcc018b   registry.access.redhat.com/rhel7/pod-infrastructure:latest                          "/usr/bin/pod"           8 minutes ago    Up 8 minutes              k8s_POD_app-workspace-373-1675214627414-podgroup-pfhh-d42q6_aimaster-user-namespace-373_4881e655-9c3e-41a0-81d7-187ce8bcbafc_0
[root@byg612sv036 ~]# ps -ef | grep "app-workspace-373-1675214627414" | grep -v grep
root     43434 43404  0 09:58 pts/0    00:00:04 /usr/bin/python /usr/local/bin/jupyter-lab --port 8888 --allow-root --config='/dfs/share-read-only/jupyter_notebook_config.py' --LabApp.base_url='/app-workspace-373-1675214627414' --NotebookApp.token='6745c8z8'

1./proc/pid

Linux一切皆文件，每1个进程的详细信息，都记录在/proc/pid目录下；

/proc/pid/cmdline 进程启动命令
/proc/pid/cwd 链接到进程当前工作目录
/proc/pid/environ 进程环境变量列表
/proc/pid/exe 链接到进程的执行命令文件
/proc/pid/fd 包含进程相关的所有的文件描述符
/proc/pid/maps 与进程相关的内存映射信息
/proc/pid/mem 指代进程持有的内存,不可读
/proc/pid/root 链接到进程的根目录
/proc/pid/stat 进程的状态
/proc/pid/statm 进程使用的内存的状态
/proc/pid/status 进程状态信息,比stat/statm更具可读性
/proc/self 链接到当前正在运行的进程

[centos@docker 8751]$ ps -ef | grep python
root       867     1  0  2022 ?        00:20:30 /usr/bin/python2 -Es /usr/sbin/tuned -l -P
root      8751     1  0 Feb22 ?        00:00:00 python3.8 manage.py runserver 0.0.0.0:8001
root      8753  8751  0 Feb22 ?        00:30:33 /usr/local/miniconda3/bin/python3.8 manage.py runserver 0.0.0.0:8001
centos   12048 12007  0 09:50 pts/0    00:00:00 grep --color=auto python
[centos@docker 8751]$ pwd
/proc/8751
[centos@docker 8751]$ ls
ls: cannot read symbolic link cwd: Permission denied
ls: cannot read symbolic link root: Permission denied
ls: cannot read symbolic link exe: Permission denied
attr        cmdline          environ  io         mem         ns             pagemap      sched      stack    task
autogroup   comm             exe      limits     mountinfo   numa_maps      patch_state  schedstat  stat     timers
auxv        coredump_filter  fd       loginuid   mounts      oom_adj        personality  sessionid  statm    uid_map
cgroup      cpuset           fdinfo   map_files  mountstats  oom_score      projid_map   setgroups  status   wchan
clear_refs  cwd              gid_map  maps       net         oom_score_adj  root         smaps      syscall
[centos@docker 8751]$ '

View Code

2.cgroups

cgroups，其名称源自控制组群（control groups）的简写，是Linux内核的一个功能;

用来限制、控制与分离一个进程组的资源（如CPU、内存、磁盘输入输出等）。

[root@node1 43359]# ps -ef | grep stress
root      43359  43338  0 16:09 ?        00:00:00 stress --vm 1 --vm-bytes 150M --vm-hang 1
root      43372  43359  5 16:09 ?        00:01:10 stress --vm 1 --vm-bytes 150M --vm-hang 1
root      62876  26220  0 16:28 pts/2    00:00:00 grep --color=auto stress
[root@node1 43359]# docker inspect --format '{{.Config.Hostname}}' $(cat /proc/43359/cgroup|awk -F 'docker-' '{print $2}' |cut -c1-12| head -n 1)
memory-demo
[root@node1 43359]#

3.Node宿主机监控插件

每1个Pod运行到Node宿主机上之后，Pod中运行进程，都会以进程的方式运行在Node宿主机上，以下称为Pod进程；

基于以上原理，考虑到监控插件的通用性，在Node宿主机上额外部署1个Shell/Golang监控插件；

该监控插件的功能大致如下：

Pod在CI/CD阶段规范Pod中运行进程的进程名称；
根据规范的进程名称，实时更新每该Pod 进程对应的PID，更新到Pod进程和Pid的映射关系表；
一旦Prometheus监控到某1个Pod停止，立即根据该Pod进程名称，锁定该Pod进程最后1次使用的PID;
使用该PID做为Keyword去ES中(源自/var/log/messages)中进行Phrase查询
最终判断该PID的进程是否出现oom kill现象？

参考

推荐文章：

Pod OOM相关故障梳理及监控，LoadAverag