<p>I try to setup a haproxy'd multi-master node setup for Kubernetes, as described in [<a href="https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/" rel="nofollow noreferrer">1</a>]. My network configurations are:</p>

<ul>
<li>haproxy = 192.168.1.213</li>
<li>master0|1|2 = 192.168.1.210|211|212</li>
<li>worker0|1|2 = 192.168.1.220|221|222 (not interesting at this point)</li>
</ul>

<p>all hosts are able to connect to each other (DNS is resolved for each node). Each node is running Ubuntu 18.04.3 (LTS). Docker is installed as </p>

<ul>
<li>docker.io/bionic-updates,bionic-security,now 18.09.7-0ubuntu1~18.04.4 amd64 [installed] </li>
</ul>

<p>Kubernetes packages currently installed are</p>

<ul>
<li>kubeadm/kubernetes-xenial,now 1.16.3-00 amd64 [installed]</li>
<li>kubectl/kubernetes-xenial,now 1.16.3-00 amd64 [installed]</li>
<li>kubelet/kubernetes-xenial,now 1.16.3-00 amd64 [installed,automatic]</li>
<li>kubernetes-cni/kubernetes-xenial,now 0.7.5-00 amd64 [installed,automatic]</li>
</ul>

<p>using an additional repository as described in [<a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-using-native-package-management" rel="nofollow noreferrer">2</a>] (i'm aware that i've installed <code>bionic</code> on my VMs, but the "newest" repo available is still <code>xenial</code>).</p>

<p>My haproxy is installed as <code>haproxy/bionic,now 2.0.9-1ppa1~bionic amd64 [installed]</code> from [<a href="https://launchpad.net/~vbernat/+archive/ubuntu/haproxy-2.0" rel="nofollow noreferrer">3</a>] repository.</p>

<pre><code>global
    log /dev/log        local0
    log /dev/log        local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

defaults
    log global
    mode http
    retries 2
    timeout connect 3000ms
    timeout client  5000ms
    timeout server  5000ms

frontend kubernetes
    bind        *:6443
    option      tcplog
    mode        tcp
    default_backend kubernetes-master-nodes

backend kubernetes-master-nodes
    mode    tcp
    balance roundrobin
    option  tcp-check
    server  master0 192.168.1.210:6443 check fall 3 rise 2
    server  master1 192.168.1.211:6443 check fall 3 rise 2
    server  master2 192.168.1.212:6443 check fall 3 rise 2
</code></pre>

<p>While trying to setup my first control plane, running <code>kubeadm init --control-plane-endpoint "haproxy.my.lan:6443" --upload-certs -v=6</code> as described in [<a href="https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/#stacked-control-plane-and-etcd-nodes" rel="nofollow noreferrer">4</a>] results in this error:</p>

<pre><code>Error writing Crisocket information for the control-plane node
</code></pre>

<p>full log in [<a href="https://pastebin.com/QD5mbiyN" rel="nofollow noreferrer">5</a>]. I'm pretty lost, if there's a mistake in my haproxy configuration or if there might be some fault in docker or kubernetes itself.</p>

<p>My <code>/etc/docker/daemon.json</code> looks like this:</p>

<pre><code>{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
</code></pre>

<ul>
<li>[1] <a href="https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/" rel="nofollow noreferrer">https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/</a></li>
<li>[2] <a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-using-native-package-management" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-using-native-package-management</a></li>
<li>[3] <a href="https://launchpad.net/~vbernat/+archive/ubuntu/haproxy-2.0" rel="nofollow noreferrer">https://launchpad.net/~vbernat/+archive/ubuntu/haproxy-2.0</a></li>
<li>[4] <a href="https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/#stacked-control-plane-and-etcd-nodes" rel="nofollow noreferrer">https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/#stacked-control-plane-and-etcd-nodes</a></li>
<li>[5] <a href="https://pastebin.com/QD5mbiyN" rel="nofollow noreferrer">https://pastebin.com/QD5mbiyN</a></li>
</ul>

Robert Heine
<p>While not being able to find a decent solution and created an issue in the original  "kubeadm" project at github, see here: <a href="https://github.com/kubernetes/kubeadm/issues/1930" rel="nofollow noreferrer">https://github.com/kubernetes/kubeadm/issues/1930</a> . </p>

<p>Since the "triage" suggested in the issue was not feasable (Ubuntu is pretty much "set") for me, I ended in setting up another Docker distribution, as described here: <a href="https://docs.docker.com/install/linux/docker-ce/ubuntu/" rel="nofollow noreferrer">https://docs.docker.com/install/linux/docker-ce/ubuntu/</a> , purging installed distribution before starting the new setup.</p>

<p>While running Docker (Community) <code>v19.03.5</code> through kubeadm <code>v1.16.3</code> throws the following warning:</p>

<pre><code>[WARNING SystemVerification]: this Docker version is not on the list of validated versions: 19.03.5. Latest validated version: 18.09
</code></pre>

<p>the results are pretty fine, I managed to setup my ha cluster, as described in the original documentation.</p>

<p>So, this can be considered as a <strong>workaround</strong>, <em>NOT</em> as a solution to my original issue!</p>
