深入分析与解决 Kubernetes 中的 Kmem 内存泄漏

1. 引言

1.1 Kubernetes (K8s) 概述

Kubernetes 是一个开源的容器编排平台，提供自动化部署、扩展和管理容器化应用的能力。其核心功能包括容器的调度、服务发现、负载均衡、自动扩展、自我修复等。Kubernetes 的设计理念是通过抽象基础设施细节，使得开发和运维团队能够以统一的方式管理和扩展容器化应用。然而，随着集群规模的扩大和应用的复杂性增加，内存管理问题变得日益重要。

1.2 理解 Linux 内存管理

在 Linux 系统中，内存管理通过虚拟内存和物理内存的协调使用来实现。虚拟内存为每个进程提供一个独立的地址空间，而物理内存则是系统实际可用的内存。Linux 的内核内存（Kmem）是指内核使用的内存区域，专门用于管理内核数据结构、缓存、I/O 操作等。Kmem 是系统稳定运行的基础，其管理的复杂性和重要性使得内存泄漏问题具有极大的挑战性。

1.3 识别和解决内存泄漏的重要性

内存泄漏是指程序在执行过程中无法释放已分配的内存，导致可用内存逐渐减少。如果在 Kubernetes 环境中发生 kmem 内存泄漏，可能会导致系统响应变慢、节点资源耗尽，甚至引发 OOM（Out of Memory）错误，影响整个集群的稳定性。识别和解决内存泄漏问题不仅能够保障系统的性能，还能防止潜在的服务中断风险。

1.4 本文目标

本文将从 kmem 内存泄漏的技术原理、影响、诊断方法及解决方案等方面进行详细分析，结合实际场景，帮助读者深入理解这一问题，并掌握有效的应对策略。

---

在深入探讨Kubernetes的kmem内存泄露问题之前，先来了解一下cgroup和kmem account的背景。

cgroup和kmem account简介

cgroup（Control Groups）是Linux内核提供的一种用于限制、隔离和统计系统资源（如CPU、内存、磁盘I/O等）使用的机制。它被广泛应用于容器技术中，如Docker、Kubernetes等，以确保容器之间的资源隔离。

kmem account（CONFIG_MEMCG_KMEM）是cgroup的一项扩展功能，专门用于追踪和统计内核内存（kmem）的使用情况。通过开启kmem account，系统可以将内核对象的内存使用情况归属于特定的cgroup，从而更精确地控制和监控内核内存的使用。

kmem account在3.x内核中的问题

虽然kmem account为内核内存的管理带来了精细化控制的能力，但在3.x版本的Linux内核中，尤其是3.10版本中，这个特性被标记为实验性质的功能，并且存在严重的内存泄露问题。

在开启kmem account后，系统会追踪每个cgroup内的内核内存使用情况。然而，在3.10内核中，由于kmem account模块的实现问题，当内核内存被分配和释放时，相关的内存资源并未被正确回收，导致可分配内存逐渐减少。随着时间的推移，系统的可用内存会越来越少，最终导致无法创建新的Pod，甚至可能导致节点宕机或其他异常行为。

4.x内核中的修复

到了4.x版本的Linux内核，kmem account的内存泄露问题得到了修复。内核在处理kmem account的过程中，改进了内存资源的管理，确保了内存的正确分配和回收。因此，在使用4.x及以上版本的内核时，kmem account功能可以安全启用，并且不会导致内存泄露的问题。

Kubernetes中的kmem account使用

Kubernetes依赖于cgroup来实现资源的隔离和限制。由于kmem account是cgroup的扩展功能，现代的容器运行时如runc、Docker和Kubernetes默认都启用了kmem account属性。尽管kmem account在3.10内核中存在内存泄露问题，但在Kubernetes的兼容性上，依然保持默认启用该功能，这意味着在3.10内核上运行Kubernetes时，可能会遇到前述的内存泄露问题。

需要特别注意的是，这个问题并不是内核本身的缺陷，而是由于在不完全兼容的内核版本中启用了实验性质的kmem account特性所引发的。因此，在生产环境中，尤其是在使用Kubernetes管理大量Pod和节点的场景下，强烈建议使用4.x及以上版本的Linux内核，避免由于kmem account引发的内存泄露问题。

实际场景中的问题分析

在实际运维中，如果你发现Kubernetes集群中的节点出现了无法调度新的Pod，内存使用异常增加，甚至节点频繁宕机的现象，那么很可能就是kmem account导致的内存泄露问题。此时，检查集群所使用的内核版本非常重要。

例如，在某个大规模的Kubernetes集群中，运维团队发现随着时间的推移，节点的内存使用率不断增加，最终导致多个节点发生宕机。经过分析，发现该集群的内核版本是3.10，而kmem account功能被默认启用。在排查了其他可能的内存泄露原因后，最终确认是kmem account引发的内存泄露。解决方案是升级内核到4.x版本，问题得以彻底解决。

kmem account是一个非常有用的cgroup扩展功能，在4.x及以上版本的内核中，它能够为Kubernetes等容器管理平台提供更精细的内存控制能力。然而，在3.x版本的内核中，尤其是3.10内核上启用kmem account会引发严重的内存泄露问题。因此，确保你的Kubernetes集群运行在兼容且稳定的内核版本上，对于避免此类问题至关重要。

修改/etc/default/grub，在GRUB_CMDLINE_LINUX中添加cgroup.memory=nokmem:

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet cgroup.memory=nokmem"
GRUB_DISABLE_RECOVERY="true"
/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg

[root@k8s-master01 ~]# cat /boot/config-3.10.0-1160.119.1.el7.x86_64 | grep CONFIG_MEMCG
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_MEMCG_KMEM=y
[root@k8s-master01 ~]#  

2. 理解 Kmem 和内存泄漏

2.1 什么是 Kmem？

Kmem 是 Linux 内核空间中的内存分配区域，负责管理系统内核所需的内存。内核空间与用户空间的主要区别在于，内核空间是操作系统核心模块运行的地方，具有更高的权限和访问能力。内核内存通常用于缓存数据、管理内核对象（如进程控制块、内存页表）、处理中断请求（IRQ），以及支持文件系统和网络栈的操作。

• Slab 分配器：Kmem 使用 Slab 分配器进行内存管理，Slab 分配器的原理是将内存划分为小块（slab），并在需要时分配给内核对象。这种分配机制能够减少内存碎片，提升内存分配的效率。

• 内核模块的内存需求：内核模块（如设备驱动、网络协议栈）可能会频繁请求内存以处理复杂操作。如果这些模块没有正确释放内存或分配内存时发生错误，就可能导致 kmem 内存泄漏。

2.2 Kmem 内存泄漏的常见原因

Kmem 内存泄漏的常见原因包括以下几种：

1. 内核模块 Bug：内核模块中的错误可能导致内存没有被正确释放。例如，某些内核版本的网络栈在处理大量连接请求时，可能会由于未正确清理连接信息而导致内存泄漏。

2. 设备驱动程序问题：设备驱动程序可能会出现内存分配不当的情况，特别是在高负载或频繁的 I/O 操作下，驱动程序可能未能释放某些中间数据结构，从而导致 kmem 泄漏。

3. 系统配置错误：不当的系统配置，尤其是在网络、存储等高频率操作场景下，可能会触发 kmem 泄漏。例如，某些调度器策略或内存分配策略配置不当，可能导致内存得不到及时释放。

4. 并发处理中的内存管理问题：在多线程或多进程的并发处理中，某些内存分配和释放操作可能会因为竞争条件（race condition）而出现问题，导致内存泄漏。例如，在并发的情况下，多个线程同时试图修改同一个内存区域，但未能正确协调内存的分配和释放，可能导致内存泄漏。

2.3 Kmem 泄漏如何影响 Kubernetes 环境

在 Kubernetes 集群中，kmem 内存泄漏问题的影响尤为显著，因为 Kubernetes 依赖节点的稳定性来维持整个集群的健康运行。Kmem 泄漏会导致以下问题：

• 节点资源耗尽：随着内存泄漏的持续，节点的可用内存逐渐减少，最终导致节点无法再分配内存给新的进程或容器。
• 系统性能下降：内存不足会导致系统频繁使用交换空间（swap），从而显著降低系统的性能，影响服务的响应速度。
• OOM 错误：一旦节点的可用内存耗尽，系统将触发 OOM 杀手（Out of Memory Killer），强制终止部分进程以释放内存。对于 Kubernetes 而言，这可能导致重要的 Pod 被杀死，从而引发服务中断。

例如，假设在一个 Kubernetes 集群中，有一个节点运行了大量高负载的容器，这些容器涉及大量的网络操作。由于内核版本存在 Bug，网络栈无法正确释放连接信息，导致 kmem 内存泄漏。随着时间的推移，节点的内存使用率逐渐增加，系统开始变得不稳定，最终触发 OOM 错误，导致一些关键服务停止运行。

---

3. 真实案例分析

3.1 案例研究 1：内核版本 X.Y.Z 中的 Kmem 泄漏

背景：在某一大型互联网公司的 Kubernetes 集群中，运维团队发现部分节点的内存使用率异常高，且内存并未被释放。经过详细的分析，发现这是由 Linux 内核版本 X.Y.Z 中的一个 Bug 导致的。

问题分析：该 Bug 涉及内核网络栈中的连接管理模块，该模块在处理大量并发连接时未能正确释放一些内核对象，导致 kmem 内存泄漏。具体来说，内核在处理 TCP 连接时，某些特定的状态转换过程中，没有正确释放连接控制块（TCP Control Block, TCB），这些未释放的 TCB 占用了大量的 kmem 内存。

解决方案：运维团队联系了 Linux 内核社区，确认该问题已在后续版本中修复。通过升级内核至最新版本，问题得到了彻底解决。此外，团队还加强了对内核版本的跟踪和测试，避免类似问题再次发生。

经验教训：该案例表明，及时跟踪和更新内核版本是预防 kmem 内存泄漏的有效手段。此外，深入理解系统日志和内存使用情况，对于快速定位和解决问题至关重要。

3.2 案例研究 2：生产环境中的影响

背景：在另一个生产环境中，某金融企业的 Kubernetes 集群遭遇了严重的内存泄漏问题，导致多个节点发生 OOM 错误，影响了关键业务的正常运行。

问题分析：该问题发生在高负载的交易系统中，系统每秒处理数千笔交易请求。经过分析，发现问题源自一个自定义开发的内核模块，该模块在处理并发交易时，未能正确释放用于缓存交易数据的内存。由于该模块在内核空间中运行，其内存泄漏直接导致了 kmem 的耗尽。

解决方案：由于该模块是企业内部开发的，团队无法立即依赖社区提供解决方案。因此，团队采取了短期的变通措施，如定期重启受影响的节点，并在负载低谷期进行手动内存清理。最终，开发团队修复了该模块的内存管理逻辑，彻底解决了问题。

经验教训：自定义内核模块在生产环境中部署时，务必进行充分的测试，尤其是内存管理相关的测试。此外，定期监控系统的内存使用情况，并制定应急预案，可以有效减少内存泄漏带来的影响。

3.3 经验教训

从上述案例可以看出，kmem 内存泄漏问题在生产环境中可能带来严重的后果。因此，预防和及时解决内存泄漏问题至关重要。以下是一些关键的经验教训：

• 及时更新内核版本：许多 kmem 内存泄漏问题来源于内核 Bug，因此保持

内核的及时更新是预防问题的有效手段。

• 自定义模块的严格测试：自定义的内核模块可能引入内存管理方面的问题，必须经过严格的测试，特别是在高负载和并发场景下。
• 系统资源监控：定期监控系统的内存使用情况，能够提前发现潜在的问题，并采取预防措施。
• 应急预案：在生产环境中，应制定并定期演练应急预案，以应对突发的内存泄漏问题。

---

4. 诊断和监控内存泄漏

4.1 使用 slabtop 工具

slabtop 是一个强大的工具，用于实时监控 Linux 系统中的 slab 缓存使用情况。Slab 缓存是 Linux 内核用来存储小型内核对象的地方，slabtop 能够帮助管理员识别哪些 slab 缓存消耗了大量内存，从而发现潜在的内存泄漏。

示例使用：

$ slabtop -o

在输出中，您将看到各类 slab 缓存的使用情况，尤其是 Active_objs 和 Objsize 列，这两项指标可以帮助您判断某些 slab 缓存是否存在异常增长的趋势。例如，如果某个 slab 缓存持续占用大量内存，而其使用率却没有降低，那么这可能是内存泄漏的一个征兆。

4.2 使用 kmemleak 检测内存泄漏

kmemleak 是 Linux 内核提供的一个用于检测内存泄漏的工具。它通过追踪内核的内存分配和释放操作，来检测内存泄漏。kmemleak 会定期扫描系统的内存分配情况，如果发现某些分配的内存未被释放且无法访问，它会报告为内存泄漏。

激活 kmemleak：

1. 在启动内核时，添加启动参数 kmemleak=on 以启用 kmemleak 功能。
2. 系统启动后，您可以通过以下命令检查内存泄漏报告：

$ cat /sys/kernel/debug/kmemleak

如果 kmemleak 发现内存泄漏，它会在输出中显示相关的内存地址和调用栈信息。这些信息对于定位问题代码至关重要。

4.3 结合 cgroups 实现精细化内存管理

cgroups 是 Linux 提供的资源控制机制，可以限制和监控系统中进程组的资源使用情况，包括 CPU、内存、I/O 等。通过 cgroups，管理员可以为每个容器或进程设置内存限制，从而防止单个进程或容器耗尽系统的内存资源。

创建内存控制组：

$ mkdir /sys/fs/cgroup/memory/mygroup
$ echo 1G > /sys/fs/cgroup/memory/mygroup/memory.limit_in_bytes

然后将一个进程加入到该控制组中：

$ echo <PID> > /sys/fs/cgroup/memory/mygroup/cgroup.procs

此时，该进程将被限制在 1G 内存的范围内，超出限制将触发 OOM 错误。这种方式能够有效避免单个进程或容器导致的系统级内存泄漏。

4.4 实时监控工具的应用

在 Kubernetes 环境中，结合 Prometheus 和 Grafana 等监控工具，可以实现对节点内存使用情况的实时监控。例如，通过安装 Node Exporter，您可以获取各个节点的详细内存使用情况，并在 Grafana 中可视化展示。

Prometheus 配置示例：

scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['<node-ip>:9100']

通过这样的配置，Prometheus 会定期抓取 Node Exporter 的数据，Grafana 则可以基于这些数据生成内存使用情况的监控图表。当某个节点的 kmem 内存使用率异常增长时，您可以设置告警规则，及时收到通知并进行处理。

4.5 日志分析与自动化运维

内存泄漏问题通常会在系统日志中体现，尤其是当系统发生 OOM 错误时，内核会记录详细的错误信息。通过分析系统日志，您可以了解内存泄漏发生的时间点、相关进程以及触发条件。这些信息对于问题的定位和解决非常关键。

此外，可以使用 ELK（Elasticsearch, Logstash, Kibana）等日志管理工具，对系统日志进行集中采集、分析和可视化。结合自动化运维工具（如 Ansible、SaltStack），您可以自动化地执行内存泄漏检测、日志分析和节点重启等操作，从而提升运维效率和问题处理速度。

---

5. 解决方案和最佳实践

5.1 升级内核和 Kubernetes 版本

背景：在解决 kmem 内存泄漏问题时，升级内核和 Kubernetes 版本是最直接的方式。由于内核是内存管理的核心组件，许多内存泄漏问题都是通过内核更新来修复的。Kubernetes 社区也会定期发布新版本，其中包括对资源管理的优化和 Bug 修复。

操作步骤：

1. 备份与测试：在升级内核或 Kubernetes 之前，务必进行全面的备份，并在测试环境中验证新版本的稳定性和兼容性。

2. 版本选择：选择长期支持（LTS）版本的内核和 Kubernetes，确保其经过广泛测试，并且在社区中有足够的支持。

3. 滚动升级：对于生产环境，建议采用滚动升级策略，即逐步更新集群中的节点，确保服务不中断。如果升级过程中发现问题，可以随时回滚到上一个稳定版本。

最佳实践：

• 定期更新：保持定期更新内核和 Kubernetes 版本，尤其是在官方发布重要安全修复和性能优化的情况下。
• 关注社区动态：及时跟踪 Linux 内核和 Kubernetes 社区的动态，获取最新的 Bug 报告和解决方案。
• 测试与验证：在升级前务必进行充分的测试，特别是高负载和关键业务场景下的测试。

5.2 优化内核参数配置

背景：在特定场景下，优化内核参数配置可以显著减少内存泄漏的风险。例如，通过调整内存分配策略、缓存管理参数等，可以提高系统的稳定性和内存利用率。

操作步骤：

1. 分析现状：通过 slabtop、vmstat 等工具，分析当前系统的内存使用情况和内核参数的默认配置。

2. 调整参数：根据分析结果，调整 /etc/sysctl.conf 中的内核参数。例如，vm.min_free_kbytes 可以控制系统保留的最小可用内存，vm.dirty_ratio 控制内存中脏页的最大比例。

3. 应用配置：修改配置文件后，使用以下命令应用新的配置：

$ sysctl -p

示例配置：

vm.min_free_kbytes = 65536
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

最佳实践：

• 监控与调整：定期监控系统的内存使用情况，并根据业务需求调整内核参数配置。
• 文档记录：对每次配置调整进行详细记录，包括调整原因、参数变化及其对系统性能的影响。
• 自动化配置管理：使用 Ansible 或 Puppet 等工具，实现内核参数的自动化配置管理，确保集群中所有节点的配置一致性。

5.3 通过资源请求和限制优化容器内存管理

背景：在 Kubernetes 中，合理设置容器的资源请求（Request）和限制（Limit）可以有效防止单个容器耗尽节点资源，从而降低 kmem 内存泄漏的风险。

操作步骤：

1. 定义资源请求和限制：在 Pod 的配置文件中，定义每个容器的资源请求和限制。例如：

resources:
  requests:
    memory: "512Mi"
  limits:
    memory: "1Gi"

2. 监控资源使用情况：使用 Kubernetes 自带的监控工具（如 Metrics Server）或第三方监控解决方案（如 Prometheus），实时监控容器的内存使用情况。

3. 调整配置：根据监控数据，动态调整容器的资源请求和限制，确保资源分配的合理性。

最佳实践：

• 分阶段调整：在初期部署时，设置较低的资源请求和限制，并逐步调整到最优配置。
• 使用 Vertical Pod Autoscaler

：在资源使用波动较大的场景下，使用 Vertical Pod Autoscaler（VPA）自动调整容器的资源请求和限制。

• 合理划分节点资源：通过 Node Affinity 或 Taints/Tolerations，将关键业务的 Pod 调度到具有更高资源保障的节点上。

5.4 定期重启节点和清理内存

背景：在长期运行的生产环境中，节点可能会因为 kmem 内存泄漏而逐渐耗尽内存资源。定期重启节点并清理内存，可以有效缓解此类问题。

操作步骤：

1. 计划重启：制定节点重启计划，例如每周或每月重启一次。在重启前，确保节点上的 Pod 能够顺利迁移到其他节点上。

2. 清理内存：在节点重启或服务重启前，使用 echo 3 > /proc/sys/vm/drop_caches 命令清理文件系统缓存，以释放更多内存资源。

3. 检查系统状态：重启节点后，检查系统日志和内存使用情况，确保内存泄漏问题得到缓解。

最佳实践：

• 自动化重启流程：使用 Kubernetes 的 DaemonSet 结合脚本实现节点的自动化重启流程，避免人工操作带来的风险。
• 定期检查：定期检查节点的内存使用情况和系统日志，及时发现和处理潜在的内存泄漏问题。
• 节点分批重启：在大规模集群中，采用分批重启的策略，避免因为重启操作导致业务中断。

5.5 加强日志和监控系统

背景：对于内存泄漏问题，日志和监控系统的作用不可忽视。通过细致的日志记录和全面的系统监控，可以提前预警问题并快速定位内存泄漏的根源。

操作步骤：

1. 配置详细日志：在 /etc/rsyslog.conf 或 /etc/systemd/journald.conf 中，配置详细的系统日志记录，特别是内核日志和 OOM 错误日志。

2. 部署监控系统：使用 Prometheus、Grafana 等工具，部署全面的监控系统，包括节点级和容器级的内存使用监控。

3. 设置告警规则：根据业务需求，设置合理的内存使用告警规则。例如，当节点的 kmem 使用率超过 80% 时，触发告警并自动执行相应的处理措施。

最佳实践：

• 日志轮转：配置日志轮转策略，避免日志文件占用大量磁盘空间。
• 集中日志管理：使用 ELK 等工具，将分散在各节点的日志集中管理，便于统一分析和处理。
• 定期审核：定期审核和优化监控系统的配置，确保监控范围的全面性和告警规则的合理性。

---

6. 内存泄露问题与cgroup的kmem account特性

在Kubernetes集群中，尤其是在使用较旧版本的Linux内核（如3.x系列）时，运维人员可能会遇到一个令人困惑的问题：随着时间的推移，系统的可分配内存逐渐减少，最终导致无法创建新的Pod或节点出现异常。这种现象通常会伴随着以下的错误日志：

Aug 20 23:24:12 bigmodel-dn-14-074 dockerd: time="2024-08-20T23:24:12.007850119+08:00" level=error msg="Handler for POST /containers/f338a76170dcfd4a8719c595e3410ac6b250bee2197c653a4b55d77c32b7a85c/start returned error: OCI runtime create failed: runc create failed: unable to start container process: unable to apply cgroup configuration: mkdir /sys/fs/cgroup/memory/kubepods/pode34f3919-07a1-48ad-8640-a04a54b67789/f338a76170dcfd4a8719c595e3410ac6b250bee2197c653a4b55d77c32b7a85c: cannot allocate memory: unknown"

此类错误通常源于cgroup的kmem account特性在3.x内核版本上的内存泄露问题。kmem account是cgroup的一个扩展，官方全称为CONFIG_MEMCG_KMEM，主要用于跟踪内核内存的使用情况。在许多Linux发行版中，这个特性默认是开启的，并且被runc、docker、k8s等容器管理工具所支持。

6.1. kmem account特性分析

尽管kmem account本身作为cgroup的扩展功能具有很强的实用性，能够帮助我们更好地管理内核内存，但它在3.10内核中被标记为实验性质，且存在一个严重的内存泄露漏洞。这个漏洞会导致随着内核内存分配的增加，系统的可用内存逐渐减少，直至完全耗尽。这种情况下，即使物理内存充足，系统也会因为无法分配新的内核内存而导致新Pod创建失败或系统进程异常。

在4.x内核中，这个问题已经得到了修复，删除cgroup后，内核能够正确释放分配的内存。

6.2. 问题复现

为了更直观地展示这个问题，我们可以通过以下步骤在CentOS 3.10.0-862.9.1.el7.x86_64及以下内核上复现这一内存泄露现象：

1. 把系统memory cgroup配额占满

   执行以下命令：

   for i in `seq 1 65536`; do mkdir /sys/fs/cgroup/memory/${i}; done
   

   你将看到以下错误：

   mkdir: cannot create directory '/sys/fs/cgroup/memory/65530': No space left on device
   

   这是因为该内核版本最多只能有65535个memory cgroup共存，systemd已经创建了一些，所以这里创建不到65535个就会遇到报错。

2. 确认删掉一个memory cgroup，腾出一个“配额”

   删除一个cgroup：

   rmdir /sys/fs/cgroup/memory/1
   mkdir /sys/fs/cgroup/memory/test
   

3. 给一个memory cgroup开启kmem accounting

   cd /sys/fs/cgroup/memory/test/
   echo 1 > memory.kmem.limit_in_bytes
   echo -1 > memory.kmem.limit_in_bytes
   

4. 把一个进程加进某个memory cgroup, 并执行一次fork系统调用

   最简单的方法是将当前shell进程加进去：

   echo $$ > /sys/fs/cgroup/memory/test/tasks
   sleep 100 &
   cat /sys/fs/cgroup/memory/test/tasks
   

5. 把该memory cgroup里面的进程都挪走并删除cgroup

   for p in `cat /sys/fs/cgroup/memory/test/tasks`; do echo ${p} > /sys/fs/cgroup/memory/tasks; done
   rmdir /sys/fs/cgroup/memory/test
   

6. 验证删除的memory cgroup所占的配额是否释放

   创建一个新的memory cgroup：

   mkdir /sys/fs/cgroup/memory/xx
   

   如果系统再次报错：

   mkdir: cannot create directory ‘/sys/fs/cgroup/memory/xx’: No space left on device
   

   说明配额并没有被释放。

6.3. 内核差异

在3.10内核上执行上述步骤时，删除一个memory cgroup后，其所占的配额并没有释放；而在4.19内核上，配额会成功释放。这表明，3.10内核存在内存泄露问题，而在4.19及以上版本中问题已被解决。

6.4. 对策与建议

在Kubernetes集群中，如果发现节点频繁出现无法分配内存的问题，且系统日志中有类似的错误信息，可以通过以下几种方式来解决或缓解：

1. 升级内核：如果条件允许，建议将内核升级到4.x版本，以彻底解决kmem account特性的内存泄露问题。

2. 禁用kmem accounting：如果无法升级内核，可以考虑禁用kmem accounting功能。需要注意的是，禁用该功能可能会影响某些内核内存管理功能。

3. 定期清理和重启：在无法升级内核且kmem accounting必须启用的情况下，定期清理不必要的cgroup或定期重启节点，可以在一定程度上缓解问题。

4. 升级kubelet和runc：https://blog.csdn.net/qq_39382769/article/details/124812543