kubeadm: Kubeadm init fails with "Error writing Crisocket information for the control-plane node: timed out waiting for the condition"

Is this a BUG REPORT or FEATURE REQUEST?

BUG REPORT

Versions

kubeadm version (use kubeadm version): sudo kubeadm version kubeadm version: &version.Info{Major:“1”, Minor:“13”, GitVersion:“v1.13.2”, GitCommit:“cff46ab41ff0bb44d8584413b598ad8360ec1def”, GitTreeState:“clean”, BuildDate:“2019-01-29T12:00:00Z”, GoVersion:“go1.11.10”, Compiler:“gc”, Platform:“linux/amd64”}

Environment:

  • Kubernetes version (use kubectl version):~> kubectl version Client Version: version.Info{Major:“1”, Minor:“13”, GitVersion:“v1.13.6”, GitCommit:“abdda3f9fefa29172298a2e42f5102e777a8ec25”, GitTreeState:“clean”, BuildDate:“2019-05-08T13:53:53Z”, GoVersion:“go1.11.5”, Compiler:“gc”, Platform:“linux/amd64”} Server Version: version.Info{Major:“1”, Minor:“13”, GitVersion:“v1.13.6”, GitCommit:“abdda3f9fefa29172298a2e42f5102e777a8ec25”, GitTreeState:“clean”, BuildDate:“2019-05-08T13:46:28Z”, GoVersion:“go1.11.5”, Compiler:“gc”, Platform:“linux/amd64”}
  • Cloud provider or hardware configuration:
  • OS (e.g. from /etc/os-release): cat /etc/os-release NAME=“SLES” VERSION=“15” VERSION_ID=“15” PRETTY_NAME=“SUSE Linux Enterprise Server 15” ID=“sles” ID_LIKE=“suse” ANSI_COLOR=“0;32” CPE_NAME=“cpe:/o:suse:sles:15”
  • Kernel (e.g. uname -a):Linux master-2 4.12.14-150.17-default #1 SMP Thu May 2 15:15:46 UTC 2019 (bf13fb8) x86_64 x86_64 x86_64 GNU/Linux

What happened?

kubeadm failed with error “Error writing Crisocket information for the control-plane node: timed out waiting for the condition”

What you expected to happen?

“sudo kubeadm init --pod-network-cidr 10.248.0.0/16” command should have setup all the component of master succesfully.

How to reproduce it (as minimally and precisely as possible)?

crayadm@master-2:~> sudo kubeadm init --pod-network-cidr 10.248.0.0/16 I0531 18:16:32.726064 5686 version.go:237] remote version is much newer: v1.14.2; falling back to: stable-1.13 [init] Using Kubernetes version: v1.13.6 [preflight] Running pre-flight checks [preflight] Pulling images required for setting up a Kubernetes cluster [preflight] This might take a minute or two, depending on the speed of your internet connection [preflight] You can also perform this action in beforehand using ‘kubeadm config images pull’ [kubelet-start] Writing kubelet environment file with flags to file “/var/lib/kubelet/kubeadm-flags.env” [kubelet-start] Writing kubelet configuration to file “/var/lib/kubelet/config.yaml” [kubelet-start] Activating the kubelet service [certs] Using certificateDir folder “/etc/kubernetes/pki” [certs] Generating “etcd/ca” certificate and key [certs] Generating “apiserver-etcd-client” certificate and key [certs] Generating “etcd/server” certificate and key [certs] etcd/server serving cert is signed for DNS names [master-2 localhost] and IPs [10.248.0.210 127.0.0.1 ::1] [certs] Generating “etcd/peer” certificate and key [certs] etcd/peer serving cert is signed for DNS names [master-2 localhost] and IPs [10.248.0.210 127.0.0.1 ::1] [certs] Generating “etcd/healthcheck-client” certificate and key [certs] Generating “ca” certificate and key [certs] Generating “apiserver” certificate and key [certs] apiserver serving cert is signed for DNS names [master-2 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.248.0.210] [certs] Generating “apiserver-kubelet-client” certificate and key [certs] Generating “front-proxy-ca” certificate and key [certs] Generating “front-proxy-client” certificate and key [certs] Generating “sa” key and public key [kubeconfig] Using kubeconfig folder “/etc/kubernetes” [kubeconfig] Writing “admin.conf” kubeconfig file [kubeconfig] Writing “kubelet.conf” kubeconfig file [kubeconfig] Writing “controller-manager.conf” kubeconfig file [kubeconfig] Writing “scheduler.conf” kubeconfig file [control-plane] Using manifest folder “/etc/kubernetes/manifests” [control-plane] Creating static Pod manifest for “kube-apiserver” [control-plane] Creating static Pod manifest for “kube-controller-manager” [control-plane] Creating static Pod manifest for “kube-scheduler” [etcd] Creating static Pod manifest for local etcd in “/etc/kubernetes/manifests” [wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory “/etc/kubernetes/manifests”. This can take up to 4m0s [apiclient] All control plane components are healthy after 14.003255 seconds [uploadconfig] storing the configuration used in ConfigMap “kubeadm-config” in the “kube-system” Namespace [kubelet] Creating a ConfigMap “kubelet-config-1.13” in namespace kube-system with the configuration for the kubelets in the cluster [patchnode] Uploading the CRI Socket information “/var/run/dockershim.sock” to the Node API object “master-2” as an annotation [kubelet-check] Initial timeout of 40s passed. error execution phase upload-config/kubelet: Error writing Crisocket information for the control-plane node: timed out waiting for the condition.

Anything else we need to know?

~> cat /etc/crictl.yaml runtime-endpoint: unix:///var/run/dockershim.sock image-endpoint: unix:///var/run/dockershim.sock timeout: 10 debug: true ~> crictl pods FATA[0010] failed to connect: failed to connect: context deadline exceeded ~> systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled) Active: active (running) since Sat 2019-05-25 14:29:49 UTC; 6 days ago Docs: http://docs.docker.com Main PID: 19508 (dockerd) Tasks: 120 Memory: 103.3M CPU: 48min 59.396s CGroup: /system.slice/docker.service ├─ 5878 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/50ba657c71cfeccf8ffd3544334ab2fa9f0576> ├─ 5880 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/830a32f38fec61cd909a31543bc65d2b9b6abe> ├─ 5883 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/95bd179c9c1c90c0f3f97c8e8ee22203b75ecc> ├─ 5897 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/3ccce84564cc38018df299ca780f0929b63fa0> ├─ 5934 /pause ├─ 5941 /pause ├─ 5946 /pause ├─ 5968 /pause ├─ 6045 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/9d66fe3c91d7154e3115620d2c6bc4334548a8> ├─ 6059 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/41fca5033552e43d50a53433228a5f7c3e413c> ├─ 6060 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/a39bffdf8469140338eaabc2d2b490aeaf013b> ├─ 6061 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/2de48a98c6d58d3e7b9322939bd542a9e6a273> ├─ 6094 kube-apiserver --authorization-mode=Node,RBAC --advertise-address=10.248.0.210 --allow-privileged=true --client-ca-file=/etc/kubernetes/pki/ca.crt --enable-> ├─ 6111 etcd --advertise-client-urls=https://10.248.0.210:2379 --cert-file=/etc/kubernetes/pki/etcd/server.crt --client-cert-auth=true --data-dir=/var/lib/etcd --in> ├─ 6130 kube-controller-manager --address=127.0.0.1 --allocate-node-cidrs=true --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-k> ├─ 6140 kube-scheduler --address=127.0.0.1 --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true ├─19508 /usr/bin/dockerd --add-runtime oci=/usr/sbin/docker-runc └─19515 docker-containerd --config /var/run/docker/containerd/containerd.toml

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 2
  • Comments: 24 (10 by maintainers)

Most upvoted comments

This fixed for me. https://github.com/kubernetes/kubeadm/issues/1438#issuecomment-493004994 drop 20-etcd-service-manager.conf under /etc/systemd/system/kubelet.service.d

sudo kubeadm reset worked for me

Ok - Finally, this is solved. The issue was this.

When we did kubeadm reset and it worked. It said that it deleted the directory.

[reset] Deleting contents of stateful directories: [/var/lib/kubelet /etc/cni/net.d /var/lib/dockershim /var/run/kubernetes]

And we assumed that it did what it said. When I checked /var/lib/kubelet - it was still there. I tried deleting this manually, and it failed for the pods directory that was there from previous Kubernetes installation. The reason - it was not able to delete mount directory due to read only attribute set to it by Portworx previously. I had to use chattr -i mount, and then I was able to delete the pods directory from /var/lib/kubelet directory. The kubeadm join worked perfectly after that.

It consumed our whole day. When kubeadm reset says that it deleted some directories - Make sure that those are gone in fact. I hope that this helps someone else who might have similar issues. The kubeadm should throw an error if a directory deletion was not successful.