kubeadm init fails with K8s 1.9 + shared directory on btrfs

[dongsupark]

When testing kube-spawn with --kubernetes-version=v1.9.0, the cluster doesn't get created. While kubeadm init succeeds on the master node, kubeadm join fails on worker nodes, with the following error message:

[discovery] Failed to request cluster info, will try again: [Get https://10.22.0.3:6443/api/v1/namespaces/kube-public/configmaps/cluster-info: dial tcp 10.22.0.3:6443: getsockopt: connection refused]

I remember it worked until k8s v1.9.0-alpha.3 (?), but since then I haven't tested. So I'm not sure why.

[dongsupark]

It turns out to be a btrfs-specific issue. This issue happens only when the mounted directory /var/lib/kube-spawn/.../mount on the host is located inside btrfs. When it's ext4, it does not happen.

Question is, why this issue pops up only with k8s 1.9. I thought, kubelet 1.9 with docker already supports the storage driver "overlay2", which is supposed to work with btrfs well.

[dongsupark]

Related discussion in the #kubeadm slack channel:
https://kubernetes.slack.com/archives/C2P1JHS2E/p1513762692000023

Hi, I'm trying to create a development cluster using LXD with kubeadm. I created a storage pool for LXD with an LVM logical volume that uses BTRFS. Docker officially supports btrfs and I successfully installed docker v17.03.2 CE in a LXD container and ran a test container. I then tried running kubeadm init but the preflight check fails with an error saying DOCKER_GRAPH_DRIVER: btrfs is unsupported. Why does kubeadm consider btrfs unsupported when it's supported by docker?

luxas:

It means that #sig-node hasn't validated that btrfs works well with the kubelet. It might, or it might not work for you. Proabably it works just fine