kubeadm: BUG REPORT:kubelet cgroup driver

I hit this same issue with kubeadm v1.9.2 but I can see kubelet is configured to use systemd cgroup driver.

kubelet is using --cgroup-driver=systemd

cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
Environment="KUBELET_CADVISOR_ARGS=--cadvisor-port=0"
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
Environment="KUBELET_CERTIFICATE_ARGS=--rotate-certificates=true --cert-dir=/var/lib/kubelet/pki"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CADVISOR_ARGS $KUBELET_CGROUP_ARGS $KUBELET_CERTIFICATE_ARGS $KUBELET_EXTRA_ARGS

docker info | grep -i cgroup

 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
Cgroup Driver: systemd

kubelet logs

I0206 16:20:40.010949    5712 feature_gate.go:220] feature gates: &{{} map[]}
I0206 16:20:40.011054    5712 controller.go:114] kubelet config controller: starting controller
I0206 16:20:40.011061    5712 controller.go:118] kubelet config controller: validating combination of defaults and flags
W0206 16:20:40.015566    5712 cni.go:171] Unable to update cni config: No networks found in /etc/cni/net.d
I0206 16:20:40.019079    5712 server.go:182] Version: v1.9.2
I0206 16:20:40.019136    5712 feature_gate.go:220] feature gates: &{{} map[]}
I0206 16:20:40.019240    5712 plugins.go:101] No cloud provider specified.
W0206 16:20:40.019273    5712 server.go:328] standalone mode, no API client
W0206 16:20:40.041031    5712 server.go:236] No api server defined - no events will be sent to API server.
I0206 16:20:40.041058    5712 server.go:428] --cgroups-per-qos enabled, but --cgroup-root was not specified.  defaulting to /
I0206 16:20:40.041295    5712 container_manager_linux.go:242] container manager verified user specified cgroup-root exists: /
I0206 16:20:40.041308    5712 container_manager_linux.go:247] Creating Container Manager object based on Node Config: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: ContainerRuntime:docker CgroupsPerQOS:true CgroupRoot:/ CgroupDriver:cgroupfs KubeletRootDir:/var/lib/kubelet ProtectKernelDefaults:false NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAllocatable:map[pods:{}] KubeReserved:map[] SystemReserved:map[] HardEvictionThresholds:[{Signal:memory.available Operator:LessThan Value:{Quantity:100Mi Percentage:0} GracePeriod:0s MinReclaim:<nil>} {Signal:nodefs.available Operator:LessThan Value:{Quantity:<nil> Percentage:0.1} GracePeriod:0s MinReclaim:<nil>} {Signal:nodefs.inodesFree Operator:LessThan Value:{Quantity:<nil> Percentage:0.05} GracePeriod:0s MinReclaim:<nil>} {Signal:imagefs.available Operator:LessThan Value:{Quantity:<nil> Percentage:0.15} GracePeriod:0s MinReclaim:<nil>}]} ExperimentalQOSReserved:map[] ExperimentalCPUManagerPolicy:none ExperimentalCPUManagerReconcilePeriod:10s}
I0206 16:20:40.041412    5712 container_manager_linux.go:266] Creating device plugin manager: false
W0206 16:20:40.043521    5712 kubelet_network.go:139] Hairpin mode set to "promiscuous-bridge" but kubenet is not enabled, falling back to "hairpin-veth"
I0206 16:20:40.043541    5712 kubelet.go:571] Hairpin mode set to "hairpin-veth"
I0206 16:20:40.044909    5712 client.go:80] Connecting to docker on unix:///var/run/docker.sock
I0206 16:20:40.044937    5712 client.go:109] Start docker client with request timeout=2m0s
W0206 16:20:40.046785    5712 cni.go:171] Unable to update cni config: No networks found in /etc/cni/net.d
I0206 16:20:40.049953    5712 docker_service.go:232] Docker cri networking managed by kubernetes.io/no-op
I0206 16:20:40.055138    5712 docker_service.go:237] Docker Info: &{ID:ZXWO:G2FL:QM3S:IAWM:ITQL:XHRH:ZA3T:FJMV:5JDW:IMKI:NIFS:2Z4M Containers:8 ContainersRunning:0 ContainersPaused:0 ContainersStopped:8 Images:11 Driver:devicemapper DriverStatus:[[Pool Name docker-253:0-33593794-pool] [Pool Blocksize 65.54 kB] [Base Device Size 10.74 GB] [Backing Filesystem xfs] [Data file /dev/loop0] [Metadata file /dev/loop1] [Data Space Used 1.775 GB] [Data Space Total 107.4 GB] [Data Space Available 14.72 GB] [Metadata Space Used 2.093 MB] [Metadata Space Total 2.147 GB] [Metadata Space Available 2.145 GB] [Thin Pool Minimum Free Space 10.74 GB] [Udev Sync Supported true] [Deferred Removal Enabled true] [Deferred Deletion Enabled true] [Deferred Deleted Device Count 0] [Data loop file /var/lib/docker/devicemapper/devicemapper/data] [Metadata loop file /var/lib/docker/devicemapper/devicemapper/metadata] [Library Version 1.02.140-RHEL7 (2017-05-03)]] SystemStatus:[] Plugins:{Volume:[local] Network:[overlay host null bridge] Authorization:[] Log:[]} MemoryLimit:true SwapLimit:true KernelMemory:true CPUCfsPeriod:true CPUCfsQuota:true CPUShares:true CPUSet:true IPv4Forwarding:true BridgeNfIptables:true BridgeNfIP6tables:true Debug:true NFd:16 OomKillDisable:true NGoroutines:25 SystemTime:2018-02-06T16:20:40.054685386Z LoggingDriver:journald CgroupDriver:systemd NEventsListener:0 KernelVersion:3.10.0-693.el7.x86_64 OperatingSystem:CentOS Linux 7 (Core) OSType:linux Architecture:x86_64 IndexServerAddress:https://index.docker.io/v1/ RegistryConfig:0xc42021a380 NCPU:2 MemTotal:2097782784 GenericResources:[] DockerRootDir:/var/lib/docker HTTPProxy: HTTPSProxy: NoProxy: Name:master1 Labels:[] ExperimentalBuild:false ServerVersion:1.12.6 ClusterStore: ClusterAdvertise: Runtimes:map[docker-runc:{Path:/usr/libexec/docker/docker-runc-current Args:[]} runc:{Path:docker-runc Args:[]}] DefaultRuntime:docker-runc Swarm:{NodeID: NodeAddr: LocalNodeState:inactive ControlAvailable:false Error: RemoteManagers:[] Nodes:0 Managers:0 Cluster:0xc420472640} LiveRestoreEnabled:false Isolation: InitBinary: ContainerdCommit:{ID: Expected:} RuncCommit:{ID: Expected:} InitCommit:{ID: Expected:} SecurityOptions:[seccomp]}
error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"

Version Info:

 kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

kubelet --version
Kubernetes v1.9.2

docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-71.git3e8e77d.el7.centos.1.x86_64
 Go version:      go1.8.3
 Git commit:      3e8e77d/1.12.6
 Built:           Tue Jan 30 09:17:00 2018
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-71.git3e8e77d.el7.centos.1.x86_64
 Go version:      go1.8.3
 Git commit:      3e8e77d/1.12.6
 Built:           Tue Jan 30 09:17:00 2018
 OS/Arch:         linux/amd64

I propose to close this issue

I’ve observed 2 reasons that cause most of the reports here:

1. forgetting to run ‘systemctl daemon-reload’ after editing systemd drop-ins. Eventhough -cgroup-driver=systemd was added to /etc/systemd/system/kubelet.service.d/10-kubeadm.conf it didn’t make any effect and default(or previously specified with --cgroup-driver) driver was used.

2. running ‘kubelet logs’ command to see kubelet logs. ‘logs’ subcommand doesn’t exist in kubelet, so ‘kubelet logs’ and ‘kubelet’ are the same commands. ‘kubelet logs’ runs kubelet with the default cgroup driver ‘cgroupfs’ and kubelet complains about inconsistency between kubelet and docker drivers. ‘journalctl -ux kubelet’ should be used to see the logs.

I tested --cgroup-driver=systemd option with kubelet 1.8.0, 1.9.0, 1.9.3 and 1.9.5. There were no error messages “cgroupfs is different from docker cgroup driver: systemd” in the logs.

@FrostyLeaf Thank you! I could reproduce this as well. Seems to be a bug. Looking at it.

As a temporary workaround you can switch docker and kubelet to cgroupfs driver. It should work.

error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: “cgroupfs” is different from docker cgroup driver: “systemd”

docker info |grep -i cgroup Cgroup Driver: systemd

I can confirm this.

@lavender2020 You need to manually append --cgroup-driver=systemd to kubelet startup args and reload kubelet unit file to restart the service.

The default driver that the kubelet uses to manipulate cgroups on the host is cgroupfs.

this is still happening, nothing worked!

I do think it’s a bug. I checked the docker version and kubeadm file, of course the kubeadm script does that check too. however i get the mismatch err msg. If someone ever read carefully you can see some of above has the issue AFTER correctly set the parameter.

@dragosrosculete

we are improving our troubleshooting docs, but also in 1.11 and later the cgroup driver for docker should be automatically matched by kubeadm.

I had this same problem on Ubuntu 16.04, Kube version v1.10.4 . Docker version 1.13.1 Docker was starting with native.cgroupdriver=systemd . This config was set by me in /etc/docker/daemon.json

{
"exec-opts": ["native.cgroupdriver=systemd"]
}

I have modified the config in /etc/systemd/system/kubelet.service.d/10-kubeadm.conf Added a new line: Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd" And add the parameter $KUBELET_CGROUP_ARGS in ExecStart

Then did a systemctl daemon-reload and service kubelet restart . Kubelet started correctly .

is this a bug and will be fixed in v1.11

IMO this is a configuration mismatch between docker and kubelet, rather than a bug.

Before running kubeadm init, a prerequisite check on cgroup driver should be done.