容器SRE工程师的日常：揭秘Kubelet资源异常之谜
一背景
在现代软件部署领域，容器技术已占据举足轻重的地位，尤其在云计算和微服务架构中扮演着核心角色。随着容器化应用的广泛采用，确保容器环境的稳定性变得至关重要，这正是容器SRE（Site Reliability Engineering，站点可靠性工程）的核心职责。容器SRE工程师不仅需保障系统的高可用性，还要优化运行效率，确保系统在面对各种压力和突发事件时仍能保持稳定。然而，他们的工作往往是默默无闻的，涉及大量看似琐碎却极为关键的维护任务。例如，当发现K8s集群中的Kubelet进程CPU使用异常升高时，容器SRE工程师必须立即介入，进行深入的问题诊断和排查，以防止此类问题在生产环境中造成潜在风险。这种排查过程通常涉及复杂且不可预测的环境，要求SRE工程师具备高度的专业知识和迅速应对问题的能力。因此，尽管容器SRE工程师的努力可能不为外界所见，但对于依赖软件和云服务的现代系统而言，他们的工作至关重要。本文将深入探讨容器SRE在日常工作中所面临的挑战，以及他们如何运用专业技能和创新技术方案来定位和解决问题，确保技术平台的稳定运行。这些看似微不足道的琐事，实际上是确保企业技术架构弹性和可靠性的关键所在。2024年4月19日，一条关于宿主机Node CPU告警的消息引起了我们的注意，由此展开了一场排查之旅......
容器SRE工程师的日常揭秘Kubelet资源异常之谜
二问题现象
在容器单机上，容器管理组件Kubelet的CPU和内存使用率异常高企。以机器43.113为例，Kubelet进程的资源使用在top命令中一直名列前茅，CPU占用率高达2022%（是正常实例的200倍），内存占用达到8.6G。为了进行对比分析，我们从集群中随机抽取了多台配置相同的机器：正常情况下，Kubelet的CPU占用约为26.7%，内存占用仅为700M左右。K8s单机的Kubelet进程作为单机的管控程序，其资源占用通常不会出现如此大的波动。经过单机和多台主机的对比分析，我们可以确定主机43.113的Kubelet进程出现了异常。那么，是什么导致了CPU和内存使用的飙升呢？我们决定从宿主机43.113的整体状况和Kubelet进程两个方向进行分析。从宿主机维度分析是为了确定是否单机负载或进程异常导致了Kubelet异常，而从进程维度排查则是为了定位Kubelet资源异常使用的具体原因。当然，这两个维度的分析并不是孤立进行的，中间的分析过程可能会涉及到多次的交替验证。
三问题分析
单机整体分析
首先，让我们了解一下43.113的整体环境信息：硬件规格及资源为48核vCPU、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 Device 2，它是Ext4文件系统中实现日志文件系统的组件。jbd2的工作原理是通过记录对文件系统所做的更改来提高数据的完整性和恢复能力。在系统崩溃或非正常关机的情况下，日志可以用来恢复文件系统到早期一致的状态，减少数据损坏的风险。
本文主题词：容器kubernetes,kubernetespause容器,容器技术k8s,k8s容器资源限制,容器技术dockerk8s,kubernetes如何简化容器化部署,容器container,容器operator,容器exited,kubernetes容器管理
