得物SRE K8s 故障诊断：从 CPU 高负载到挂载泄露根源揭示

一、背景

现代软件部署中，容器技术已成为不可或缺的一环，在云计算和微服务架构中发挥着核心作用。随着容器化应用的普及，确保容器环境的可靠性成为了一个至关重要的任务。这就是容器SRE（Site Reliability Engineering，站点可靠性工程）的职责所在。容器SRE工程师不仅要保证系统的高可用性，还需要优化运行效率，确保系统在各种压力和突发情况下的韧性。

然而，容器SRE的工作常常是背后默默的付出，通常涉及着大量看似琐碎却极其关键的维护任务。例如某一天，你可能发现K8s集群中的Kubelet进程CPU使用异常飙高，这就需要容器SRE工程师立即介入，进行深入的诊断和问题排查，避免类似问题成为生产环境中的隐患。这种排查过程往往涉及复杂且难以预测的环境，通常需要SRE工程师具备高度的专业知识和快速应变能力。因此，虽然容器SRE工程师的努力可能不为大众所见，但对于现代依赖软件和云服务的任何系统来说，这些工作显得尤为严谨和重要。

通过本文，我们将深入探讨容器SRE在日常工作中面临的挑战和如何通过专业技能和创新技术方案来定位和解决问题，确保技术平台的稳健运行。这些看似“摸不着头脑”的琐碎事务，实际上是确保企业技术架构弹性和可靠性的关键所在。

2024.4.19日，一条普通的宿主机Node CPU告警引起了我们的关注，自此开始了排查的旅程......

二、问题现象

容器单机上容器管理组件Kubelet CPU和内存过高，Kubelet进程的资源使用在top命令中一直处于遥遥领先的位置，CPU占用2022%（为正常实例200倍），内存占用8.6G，这里我们以机器43.113为例排查分析。

我们从集群中随机抽取多台配置相同的机器进行对比分析：正常的Kubelet CPU占用26.7%，内存占用仅在700M左右，K8s单机的Kubelet进程作为单机的管控程序，资源占用不会出现如此大的波动。

经过单机和多台主机对比分析，我们可以确定主机43.113的Kubelet进程出现了异常，那么是什么原因导致的CPU和内存使用飙升呢？

首先我们想到的是从宿主机43.113整体状况和Kubelet进程两个方向进行分析，从宿主机维度分析为了确定是否单机负载或者进程异常导致Kubelet异常，从进程维度排查是为了定位Kubelet资源异常使用具体原因。当然，这两个维度的分析也并不是独立进行，中间分析过程中可能会涉及到多次的交替验证过程。

三、问题分析

单机整体分析

首先，我们整体交代一下43.113整体环境信息：

• 硬件规格及资源：vCPU为48核、内存310GiB；
• 操作系统内核：操作系统为云厂商提供的操作系统，内核版本4.19.91-26.6.al7.x86_64；
• 近期负载：1分钟、5分钟、15分钟负载分别为48.03、43.91和42.94，与单机的48核vCPU来讲，负载正常（一般的排查经验是运行负载小于<1.5vCPU，则表明机器负载并不过高，但是高负载并完全对等CPU饱和）。

通过在主机上运行top命令，我们可以发现尽管单机负载在合理范围内，但是单机的进程数量存在过大的情况，48个vCPU单机运行的进程总量有20155个（Linux内核中一般称作Task任务），运行中的进程仅有10个，处于睡眠状态（Sleeping）的进程有13265个。为了定位进程的数量异常，我们继续使用“ps | wc -l”命令进行了再次确认，系统中的确存在2万多个进程。

$ ps aux|wc -l
20135

基于ps详情进行进一步确认分析，我们可发现数量众多的“[jbd2/vdnx-y]/[jbd2-ckpt/vdx]”格式的进程，“[xxx]”格式的任务属于内核线程，由内核进行管理和分配，比如我们常见的用于管理内核软中断管理的[ksoftirqd/7]。内核中的线程一般都是针对某类资源进行管理，前缀一般为会表明内核作用，比如“ksoftirqd”就代表内核软中断处理，7表示为系统CPU#7上运行。通过查询资料，确认了“[jbd2/vdx-y]”格式中的jbd2代表的是：Journaling Block Device2，jbd2是Ext4文件系统中实现日志文件系统的组件，其工作原理是通过记录对文件系统所做的更改来提高数据的完整性和恢复能力。在系统崩溃或非正常关机的情况下，日志可以用来恢复文件系统到早期一致的状态，减少数据损坏的风险。

通过内核线程数量确认，内核线程总量为19798，为以[jbd2/vdx-y]开头的内核线程有12769个，[ext4-rsv-conver]内核线程的数量为6385个，两者总和为19154个，占内核线程的97%。同时在进程详情中，还有个明显的特征基本上3个内核线程为一组，比如[jbd2/vdfiw-8]、[jbd2-ckpt/vdfiw]和[ext4-rsv-conver]，后续类似基本上都有这种特征，初步判断这一组内核线程是针对设备vdfiw（/dev/vdfiw-8)在内核中的进行管理的一组内核线程。

$ ps aux|grep '\['|wc -l   # 内核线程总量
19798


$ ps aux|grep '\[jbd2'|wc -l # 内核线程以 jbd2 开头的总量
12769


$ ps aux|grep -v '\[jbd2'|grep ext4-rsv-conver |wc -l  # 内核中 ext4-rsv-conver 的线程数量
6385


$ ps aux|grep '\['|more
...
root        1951  0.0  0.0      0     0 ?        S    Feb01   0:00 [jbd2/vdfiw-8]
root        1952  0.0  0.0      0     0 ?        S    Feb01   0:00 [jbd2-ckpt/vdfiw]
root        1953  0.0  0.0      0     0 ?        I<   Feb01   0:00 [ext4-rsv-conver]


root        2078  0.0  0.0      0     0 ?        I<    2023   4:26 [kworker/6:1H-kb]


root        3009  0.0  0.0      0     0 ?        S    Feb01   0:00 [jbd2/vdfjp-8]
root        3010  0.0  0.0      0     0 ?        S    Feb01   0:00 [jbd2-ckpt/vdfjp]
root        3011  0.0  0.0      0     0 ?        I<   Feb01   0:00 [ext4-rsv-conver]
...

以设备vdfiw为例：

• jbd2/vdfiw-8是一个与jbd2（Journaling Block Device version 2）内核文件操作日志系统存储的的内核线程；
• jbd2-ckpt/vdfiw是一个特定于jbd2的内核线程，其中ckpt代表“checkpoint”（检查点）。在jbd2和使用它的文件系统（如ext4）中，检查点是一种机制，用于定期将日志中的信息转移到文件系统本身，以减少在系统崩溃后恢复所需的时间；
• ext4-rsv-conver则是ext4由实现用于处理来自写回的转换工作，即“需要未写入的扩展处理并保留事务的已完成IO”。

文件系统是否启用日志文件功能，可通过dumpe2fs命令进程检查确认：

dumpe2fs /dev/vdc | grep has_journal

dumpe2fs 1.43.5 (04-Aug-2017)

Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

通过“df”命令查看设备vdfiw的详情：

df |grep vdfiw
/dev/vdfiw                                                                                  308521792    56841364     251664044  19% /var/lib/kubelet/plugins/kubernetes.io/csi/pv/d-bp1iau7367wkpf6xqdpv/globalmount

本机磁盘/dev/vdfiw为通过K8s存储机制动态挂载的磁盘设备，在K8s持久化存储通过PV/PVC机制进行管理，由单机负责管理存储的进程负责磁盘的创建和挂载（这里的场景为ESSD远端云盘）。简单一点讲&#