docker/kubernetes创建memory cgroup失败

dahsing commented 5 years ago

环境

版本和配置信息

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

备注：

整个环境装有匹配docker-ce的Nvidia-docker和nvidia-container-runtime,默认--runtime 为nvidia-container-runtime。
其它相关参考的issues: https://github.com/kubernetes/kubernetes/issues/61937 https://github.com/opencontainers/runc/issues/1725 https://github.com/moby/moby/issues/29638

日志

日志或报错信息

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

bloodstars commented 5 years ago

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

rootsongjc commented 5 years ago

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

dahsing commented 5 years ago

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

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

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

Nebulazhang commented 5 years ago

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

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

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

dahsing commented 5 years ago

有结果么？》我的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 commented 5 years ago

有结果么？》我的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 commented 5 years ago

有结果么？》我的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 commented 5 years ago

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

melvynpan commented 5 years ago

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

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

melvynpan commented 5 years ago

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

rootsongjc commented 5 years ago

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

melvynpan commented 5 years ago

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

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

wyfaq commented 5 years ago

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 commented 5 years ago

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

chen-joe1015 commented 5 years ago

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

a33151 commented 5 years ago

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

melvynpan commented 5 years ago

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

发自我的iPhone

------------------ 原始邮件 ------------------ 发件人: jia jie zhang notifications@github.com 发送时间: 2019年7月18日 18:49 收件人: rootsongjc/kubernetes-handbook kubernetes-handbook@noreply.github.com 抄送: melvynpan 24573168@qq.com, Mention mention@noreply.github.com 主题: 回复：[rootsongjc/kubernetes-handbook] docker/kubernetes创建memory cgroup失败 (#313)

ajasonwang commented 5 years ago

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

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

likakuli commented 5 years ago

把kmem关掉就好了

sleep0nTime commented 5 years ago

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

rootsongjc / kubernetes-handbook

docker/kubernetes创建memory cgroup失败 #313

环境

操作

备注：

日志