Change:
// scoped to the set control groups it understands.  this is being discussed // in https://github.com/opencontainers/runc/issues/1440 // once resolved, we can remove this code. <del> whitelistControllers := sets.NewString("cpu", "cpuacct", "cpuset", "memory", "hugetlb", "systemd") </del> <ins> whitelistControllers := sets.NewString("cpu", "cpuacct", "cpuset", "memory", "systemd") </ins> // If even one cgroup path doesn't exist, then the cgroup doesn't exist. for controller, path := range cgroupPaths {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In kubernetes 1.6.4, I configure kubelet with parameter ' --system-reserved=cpu=500m,memory=400Mi --system-reserved-cgroup=/system --enforce-node-allocatable=pods,system-reserved'. kubelet work failed, and output group /system not exist. the output kublet log is: ] Failed to start ContainerManager Failed to enforce System Reserved Cgroup Limits on "/system": "/system" cgroup does not exist. What you expected to happen: kublet work well, and setting --system-reserved can isolate the resources reserved for system process. How to reproduce it (as minimally and precisely as possible): run kubernetes 1.6.4 on fedora atomic 25. and setting the startup parameters(--system-reserved=cpu=500m,memory=400Mi --system-reserved-cgroup=/system --enforce-node-allocatable=pods,system-reserved) for kubelet process Anything else we need to know?: from the kubelet code v1.6.4, know it will first check --system-reserved-cgroup cgroup exist. the check way is see is exist in all subsystem. check the fedora os, I can know [fedora ~]$ sudo find /sys/fs/cgroup -name "" /sys/fs/cgroup/cpu, and check the latest kubelet code, I find the code is like this only check the subsystem defined in whitelistControllers. But the default system, not exists in hugetlb subsystem. and more important, in kubelet, this is not relevant to hugetlb subsystem. I think can delete 'hugetlb' from the whitelistControllers. Environment: Kubernetes version (use ):kubernetes 1.6.4 Cloud provider or hardware configuration**:None OS (e.g.

from /etc/os-release): [fedora cgroup]$ cat /etc/os-release NAME=Fedora VERSION="25 (Atomic Host)" ID=fedora VERSIONID=25 PRETTYNAME="Fedora 25 (Atomic Host)" ANSICOLOR="0;34" CPENAME="cpe:/o:fedoraproject:fedora:25" HOMEURL="" BUGREPORTURL="" REDHATBUGZILLAPRODUCT="Fedora" REDHATBUGZILLAPRODUCTVERSION=25 REDHATSUPPORTPRODUCT="Fedora" REDHATSUPPORTPRODUCTVERSION=25 VARIANT="Atomic Host" Kernel (e.g. ): Linux test2.novalocal 4.10.14-200.fc25.x8664 SMP Wed May 3 22:52:30 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area kubelet /sig node /assign
I encountered same error, but I fixed it now. hope can help you.
I am having a similar issue but with cpuset controller instead of hugetlb on Centos 7. cpuset is not a default controller, so even though it is mounted, no processes are using it. This prevents kubelet from finding ANY cgroups that I specify for --kube-reserved-cgroup or --system-reserved-cgroup. If I simply create a directory, for example at , I stop getting those errors. Is there an issue about changing how cpuset is handled?
ref fixed it