Skip to content

docker/kubernetes创建memory cgroup失败 #313

New issue
New issue
Closed
Closed
docker/kubernetes创建memory cgroup失败#313
Labels
help wanted请求外部帮助stale时间太久远无人问津
@dahsing

Description

@dahsing
dahsing
opened on Nov 23, 2018 · edited by dahsing

环境

版本和配置信息

  • kubernetes版本：
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:08:34Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"}
  • docker版本：
Containers: 21
 Running: 10
 Paused: 0
 Stopped: 11
Images: 33
Server Version: 18.06.0-ce
Storage Driver: overlay2
 Backing Filesystem: xfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: nvidia runc
Default Runtime: nvidia
Init Binary: docker-init
containerd version: d64c661f1d51c48782c9cec8fda7604785f93587
runc version: 69663f0bd4b60df09991c08812a60108003fa340-dirty (expected: 69663f0bd4b60df09991c08812a60108003fa340)
init version: fec3683
Security Options:
 seccomp
  Profile: default
Kernel Version: 3.10.0-693.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 32
Total Memory: 251.6GiB
Name: xxxxx
ID: Q2GS:I7UQ:GDDB:QICE:Z5E5:KXXQ:CWZT:EN6F:6GWR:AZ6P:UEWY:XTSQ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Registry Mirrors:
 https://kuamavit.mirror.aliyuncs.com/
 https://registry.docker-cn.com/
 https://docker.mirrors.ustc.edu.cn/
Live Restore Enabled: false
  • 网络插件：
flannel
calico
  • 存储类型：
xfs+overlay2
xfs+dm
  • 操作系统及内核：
CentOS Linux release 7.4.1708 (Core)
3.10.0-693.el7.x86_64

操作

导致该问题的操作或现象

集群在运行一段时间后（几天），会经常性的报不能创建memory cgroup子系统，如下:

cgroup configuration for process caused \"mkdir
/sys/fs/cgroup/memory/kubepods/burstable/podf1bd9e87-1ef2-11e8-afd3-fa163ecf2dce/8710c146b3c8b52f5da62e222273703b1e3d54a6a6270a0ea7ce1b194f1b5053:
no space left on device\""

也无法手动创建cgroup文件

[root@k8s07 ~]# mkdir /sys/fs/cgroup/memory/test
mkdir: cannot create directory ‘/sys/fs/cgroup/memory/test’: No space left on device

查看cgroup信息的时候发现，num_cgroups的数量很少，远远没有达到不能创建的64K大小，如下：

[root@k8s07 ~]# cat /proc/cgroups 
#subsys_name    hierarchy       num_cgroups     enabled
cpuset  9       23      1
cpu     8       110     1
cpuacct 8       110     1
memory  6       106     1
devices 3       111     1
freezer 7       22      1
net_cls 10      22      1
blkio   4       110     1
perf_event      5       22      1
hugetlb 2       22      1
pids    11      19      1
net_prio        10      22      1

为了避免/proc/cgroups的信息有误，又人工查了一下实际数量如下：

[root@k8s07 ~]# find /sys/fs/cgroup/memory/ -type d |wc -l
106

跟/proc/cgroups内数据一致。

有文章指出该问题和kernel版本有关（链接：http://dockone.io/article/4797，他上面描述的信息为创建的memory cgroup 在3.10及以下版本内核无法正常释放，导致最终达到cgroup的创建上限64K，但实际我这边情况是完全没有达到上限。

为了验证上述结果我特意将一个节点升级内核到了4.4版本，反而出现他文章上面描述的无法释放memory cgroup 问题，如下：

#subsys_name    hierarchy       num_cgroups     enabled
cpuset  10      56      1
cpu     2       251     1
cpuacct 2       251     1
blkio   3       251     1
memory  11      4913    1
devices 5       251     1
freezer 7       56      1
net_cls 8       56      1
perf_event      6       56      1
net_prio        8       56      1
hugetlb 9       56      1
pids    4       252     1

备注：

日志

日志或报错信息

cgroup configuration for process caused \"mkdir
/sys/fs/cgroup/memory/kubepods/burstable/podf1bd9e87-1ef2-11e8-afd3-fa163ecf2dce/8710c146b3c8b52f5da62e222273703b1e3d54a6a6270a0ea7ce1b194f1b5053:
no space left on device\""

Activity

rootsongjc
changed the title [-]请教一个关于docker/k8s创建memory cgroup失败的问题。[/-] [+]docker/kubernetes创建memory cgroup失败[/+] on Nov 23, 2018
rootsongjc
added
help wanted请求外部帮助
on Nov 23, 2018
bloodstars

bloodstars commented on Dec 3, 2018

@bloodstars
bloodstars
on Dec 3, 2018

有结果么？》我的1.11.0也遇到了这个问题，但是我升级kube到1.12.1就没有这个问题了

rootsongjc

rootsongjc commented on Dec 3, 2018

@rootsongjc
rootsongjc
on Dec 3, 2018
Owner

这个问题我也没遇到过，看看其他人有何反馈。

dahsing

dahsing commented on Dec 3, 2018

@dahsing
dahsing
on Dec 3, 2018
Author

有结果么？》我的1.11.0也遇到了这个问题，但是我升级kube到1.12.1就没有这个问题了

目前我们临时解决办法是将linux版本暂时替换成了ubutu kernel 4.2/4.4 ,ubuntu系统上面我们从来没有遇到这个问题，不过因为当时ubuntu使用的时候遇到过其它内核级别的问题。所以我们想着是两个内核问题解决一个问题，就可以暂时保证可用。

至于该如何解决该问题，等有一个大手子来回答了

Nebulazhang

Nebulazhang commented on Dec 6, 2018

@Nebulazhang
Nebulazhang
on Dec 6, 2018

有结果么？》我的1.11.0也遇到了这个问题，但是我升级kube到1.12.1就没有这个问题了

目前我们临时解决办法是将linux版本暂时替换成了ubutu kernel 4.2/4.4 ,ubuntu系统上面我们从来没有遇到这个问题，不过因为当时ubuntu使用的时候遇到过其它内核级别的问题。所以我们想着是两个内核问题解决一个问题，就可以暂时保证可用。

至于该如何解决该问题，等有一个大手子来回答了
”导致最终达到cgroup的创建上限64K，但实际我这边情况是完全没有达到上限“
请问你如何判断你没达到上限呢？泄露之后这个/proc/cgroup 数值是不准确的

dahsing

dahsing commented on Dec 6, 2018

@dahsing
dahsing
on Dec 6, 2018
Author

有结果么？》我的1.11.0也遇到了这个问题，但是我升级kube到1.12.1就没有这个问题了

目前我们临时解决办法是将linux版本暂时替换成了ubutu kernel 4.2/4.4 ,ubuntu系统上面我们从来没有遇到这个问题，不过因为当时ubuntu使用的时候遇到过其它内核级别的问题。所以我们想着是两个内核问题解决一个问题，就可以暂时保证可用。
至于该如何解决该问题，等有一个大手子来回答了
”导致最终达到cgroup的创建上限64K，但实际我这边情况是完全没有达到上限“
请问你如何判断你没达到上限呢？泄露之后这个/proc/cgroup 数值是不准确的

我这边还遍历了cgroup目录

find /sys/fs/cgroup/memory/ -type d |wc -l
106
Nebulazhang

Nebulazhang commented on Dec 6, 2018

@Nebulazhang
Nebulazhang
on Dec 6, 2018

有结果么？》我的1.11.0也遇到了这个问题，但是我升级kube到1.12.1就没有这个问题了

目前我们临时解决办法是将linux版本暂时替换成了ubutu kernel 4.2/4.4 ,ubuntu系统上面我们从来没有遇到这个问题，不过因为当时ubuntu使用的时候遇到过其它内核级别的问题。所以我们想着是两个内核问题解决一个问题，就可以暂时保证可用。
至于该如何解决该问题，等有一个大手子来回答了
”导致最终达到cgroup的创建上限64K，但实际我这边情况是完全没有达到上限“
请问你如何判断你没达到上限呢？泄露之后这个/proc/cgroup 数值是不准确的

我这边还遍历了cgroup目录

find /sys/fs/cgroup/memory/ -type d |wc -l
106

我认为按照这种创建方式是不准确的，因为目录和 /proc/cgroup 数量都是不准确的。我们认为通过这个http://dockone.io/article/4797中介绍的创建test文件方式能更加准确的判断是否达到上限

dahsing

dahsing commented on Dec 7, 2018

@dahsing
dahsing
on Dec 7, 2018
Author

有结果么？》我的1.11.0也遇到了这个问题，但是我升级kube到1.12.1就没有这个问题了

目前我们临时解决办法是将linux版本暂时替换成了ubutu kernel 4.2/4.4 ,ubuntu系统上面我们从来没有遇到这个问题，不过因为当时ubuntu使用的时候遇到过其它内核级别的问题。所以我们想着是两个内核问题解决一个问题，就可以暂时保证可用。
至于该如何解决该问题，等有一个大手子来回答了
”导致最终达到cgroup的创建上限64K，但实际我这边情况是完全没有达到上限“
请问你如何判断你没达到上限呢？泄露之后这个/proc/cgroup 数值是不准确的

我这边还遍历了cgroup目录

find /sys/fs/cgroup/memory/ -type d |wc -l
106

我认为按照这种创建方式是不准确的，因为目录和 /proc/cgroup 数量都是不准确的。我们认为通过这个http://dockone.io/article/4797中介绍的创建test文件方式能更加准确的判断是否达到上限

创建test文件对于解决问题没有意义，创建test文件目录跟我一开始的手动创建目录的方式一致的，

[root@k8s07 ~]# mkdir /sys/fs/cgroup/memory/test
mkdir: cannot create directory ‘/sys/fs/cgroup/memory/test’: No space left on device

如果这个就代表达到上限的话，那我也没办法了。

那个文件实验的是内核无法释放cgroup，才会去创建64k的cgroup，并且最后提供的解决办法好像是kernel 4.3以上，我问题里面写升级到4.4后，反而出现了不能释放的这个问题。

bloodstars

bloodstars commented on Dec 14, 2018

@bloodstars
bloodstars
on Dec 14, 2018

我原来内核是3.10.862 发现会出现这个问题，我现在升级了4.19.2 测测情况，正在大量创建pod中~~~

melvynpan

melvynpan commented on Feb 14, 2019

@melvynpan
melvynpan
on Feb 14, 2019

这个问题我也没遇到过，看看其他人有何反馈。

同样遇到该问题，centos内核版本3.10.0-514，@rootsongjc 方便透露你们生产环境的内核版本和k8s版本么？

melvynpan

melvynpan commented on Feb 14, 2019

@melvynpan
melvynpan
on Feb 14, 2019

@BigXin 最终你们有解决了这个问题么？

rootsongjc

rootsongjc commented on Feb 14, 2019

@rootsongjc
rootsongjc
on Feb 14, 2019
Owner

@melvynpan 我并不直接维护kubernetes集群，一般生产上使用的至少是kubernetes1.9以上版本。

melvynpan

melvynpan commented on Feb 14, 2019

@melvynpan
melvynpan
on Feb 14, 2019

@melvynpan 我并不直接维护kubernetes集群，一般生产上使用的至少是kubernetes1.9以上版本。

thanks，该问题出现的业务场景一般是存在大量删除pod的情况，k8s有官方issues说是kmem在k8s1.8+版本被打开，目前我们自己编译了kubelet默认不打开kmem问题还是存在。暂时没有发现比较好的解决办法。

wyfaq

wyfaq commented on Jun 4, 2019

@wyfaq
wyfaq
on Jun 4, 2019 · edited by rootsongjc

1.13.5 遇到同样问题。

Events:
  Type     Reason                    Age                 From                   Message
  ----     ------                    ----                ----                   -------
  Normal   Scheduled                 15m                 default-scheduler      Successfully assigned jenkins/jenkins-7845b9b665-nrvks to 10.10.252.4
  Warning  FailedCreatePodContainer  25s (x70 over 15m)  kubelet, 10.10.252.4  unable to ensure pod container exists: failed to create container for [kubepods besteffort podc6eeec88-8664-11e9-9524-5254007057ba] : mkdir /sys/fs/cgroup/memory/kubepods/besteffort/podc6eeec88-8664-11e9-9524-5254007057ba: no space left on device

[root@sitk8sn1 ~]# kubectl get node
NAME             STATUS                     ROLES    AGE   VERSION
10.10.252.107   Ready,SchedulingDisabled   master   51d   v1.13.5
10.10.252.108   Ready,SchedulingDisabled   master   51d   v1.13.5
10.10.252.109   Ready,SchedulingDisabled   master   51d   v1.13.5
10.10.252.4     Ready                      node     51d   v1.13.5
10.10.252.5     Ready                      node     51d   v1.13.5
10.10.252.6     Ready                      node     51d   v1.13.5

内核版本
CentOS Linux release 7.5.1804 (Core) 3.10.0-862.6.3.el7.x86_64

imroc

imroc commented on Jun 17, 2019

@imroc
imroc
on Jun 17, 2019
Contributor

这个有遇到，晚点整理文档我贴下链接

chen-joe1015

chen-joe1015 commented on Jul 15, 2019

@chen-joe1015
chen-joe1015
on Jul 15, 2019

@imroc 请把解决方案贴出来下 同样遇到

a33151

a33151 commented on Jul 18, 2019

@a33151
a33151
on Jul 18, 2019

同样遇到 有朋友解决了吗?

melvynpan

melvynpan commented on Jul 18, 2019

@melvynpan
melvynpan
on Jul 18, 2019 via email
ajasonwang

ajasonwang commented on Jul 22, 2019

@ajasonwang
ajasonwang
on Jul 22, 2019 · edited by ajasonwang

升级docker版本的runc到0.7可以解决，或者直接升级docker版本到18.9.02 发自我的iPhone

你好，请问可以提供一些更详细的信息么？目前看到很多关于这个 issue 的问题都还是 open 状态

likakuli

likakuli commented on Aug 22, 2019

@likakuli
likakuli
on Aug 22, 2019

把kmem关掉就好了

sleep0nTime

sleep0nTime commented on Sep 17, 2019

@sleep0nTime
sleep0nTime
on Sep 17, 2019

https://tencentcloudcontainerteam.github.io/2018/12/29/cgroup-leaking/
禁用kmem要在runc和kubelet中都要禁用掉。

rootsongjc
closed this as completedon Feb 8, 2020
rootsongjc
added
stale时间太久远无人问津
on Feb 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wanted请求外部帮助stale时间太久远无人问津

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @rootsongjc@sleep0nTime@imroc@bloodstars@wyfaq

        Issue actions
          docker/kubernetes创建memory cgroup失败 · Issue #313 · rootsongjc/kubernetes-handbook