k8s node CPU 毛刺问题排查

现象

k8s node 出现周期性cpu毛刺，每10分钟整出现，cpu.sys 占用峰值高于正常水位 10% 左右。

排查

期间用top命令查看，但没有观察到占用cpu高的进程。怀疑是占用cpu时间太短，这种情况可以通过perf采集cpu的性能数据进一步分析。

perf 介绍

perf 是 Linux 2.6.31 以后内置的性能分析工具。它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题。

使用perf排查

在9分58秒时，执行perf record -ag -- sleep 5。然后使用perf report（注意：如果采集的数据比较多，例如在配置高的node上，这条命令会占用大量内存）查看，发现占用cpu高的是sa1命令。这个命令是sysstat软件包的，安装sysstat后，会自动创建一个定时任务，用于每10分钟采集一次操作系统性能数据，并于每天的23点59分生成一份报告。

cat /etc/cron.d/sysstat 
# The first element of the path is a directory where the sa1
# script is located
PATH=/usr/lib/sysstat:/usr/sbin:/usr/sbin:/usr/bin:/sbin:/bin

# Activity reports every minute
*/10 * * * * root /usr/lib/sysstat/sa1 1 1

# Additional run at 23:59 to rotate the statistics file
59 23 * * * root /usr/lib/sysstat/sa1 60 2

注释这个定时任务后，再观察，发现问题依旧存在。接下来，需要排查这个命令是谁执行的。

我们知道命令的执行，一般是父进程通过fork创建一个子进程，这个动作会复制父进程的内存信息，并继续执行父进程的程序。此时再通过exec就可以执行其他程序了。

所以，我们可以使用bpftrace来监听exec事件，就可以得到执行sa1命令的父进程信息。

bpftrace介绍

bpftrace 是一个基于 eBPF 的高级跟踪工具，用于在 Linux 系统上进行动态跟踪和分析。它允许用户编写简单的脚本，通过 eBPF 技术在内核和用户空间中进行事件跟踪、性能分析和调试。

使用bpftrace排查

bpftrace -e '
tracepoint:syscalls:sys_enter_execve /str(args->filename) == "/usr/lib/sysstat/sa1"/ {
    printf("PID: %d, 父进程 PID: %d (%s), 爷爷进程 PID: %d (%s)\n", 
           pid, 
           curtask->parent->tgid, 
           curtask->parent->comm, 
           curtask->parent->parent->tgid, 
           curtask->parent->parent->comm);
}
'

通过此命令得到执行sa1命令的父进程和爷爷进程，而爷爷进程恰好是容器里的常驻进程，cat一下该进程的 /proc/{pid}/cgroup 就可以得到容器id了。

进容器后发现，确实存在同样的定时任务/etc/cron.d/sysstat。梳理了下，发现是基础镜像里安装sysstat引入进来的。

为什么这个问题以前没发现？

这个定时任务在基础镜像里存在很多年了，最近才有业务方反馈这个问题。看了下其他集群，并没有这个问题。出问题的集群有个特点，node上 pod 数量是其他集群的2-3倍，并且一个pod里除了业务容器，还有多个sidecar容器，导致该集群 node上的容器高于其他集群。

结论

基础镜像里安装sysstat软件包，引入了/etc/cron.d/sysstat 定时任务。业务镜像基于基础镜像镜像构建，也包含了这个定时任务。

出问题的集群单台node上的容器非常多，导致大量容器在同一时刻执行该定时任务，消耗node cpu性能明显，出现周期性毛刺。

解决方案

对于存量pod

使用自动化工具，批量在node上通过nsenter进入容器的namespace，停止该定时任务。

对于增量pod

在基础镜像里去掉该定时任务，业务镜像基于新的基础镜像来构建。

Post Views: 6

发送评论编辑评论

现象

排查