☰

„kubeadm init“ schlägt beim Einrichten hochverfügbarer Cluster fehl

tag-icon • tag-icon 18.04 docker kubernetes
„kubeadm init“ schlägt beim Einrichten hochverfügbarer Cluster fehl

Ich versuche, ein haproxy'd Multi-Master-Node-Setup für Kubernetes einzurichten, wie in [1]. Meine Netzwerkkonfigurationen sind:

  • haproxy = 192.168.1.213
  • master0|1|2 = 192.168.1.210|211|212
  • worker0|1|2 = 192.168.1.220|221|222 (an dieser Stelle nicht interessant)

alle Hosts können sich miteinander verbinden (DNS wird für jeden Knoten aufgelöst). Auf jedem Knoten läuft Ubuntu 18.04.3 (LTS). Docker ist installiert als

  • docker.io/bionic-updates,bionic-security,now 18.09.7-0ubuntu1~18.04.4 amd64 [installiert]

Derzeit installierte Kubernetes-Pakete sind

  • kubeadm/kubernetes-xenial,jetzt 1.16.3-00 amd64 [installiert]
  • kubectl/kubernetes-xenial,jetzt 1.16.3-00 amd64 [installiert]
  • kubelet/kubernetes-xenial,jetzt 1.16.3-00 amd64 [installiert,automatisch]
  • kubernetes-cni/kubernetes-xenial,jetzt 0.7.5-00 amd64 [installiert,automatisch]

unter Verwendung eines zusätzlichen Repository wie in [2] (ich weiß, dass ich es bionicauf meinen VMs installiert habe, aber das „neueste“ verfügbare Repo ist immer noch xenial).

Mein Haproxy ist installiert haproxy/bionic,now 2.0.9-1ppa1~bionic amd64 [installed]ab [3] Repository.

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

Beim Versuch, meine erste Kontrollebene einzurichten, läuft sie kubeadm init --control-plane-endpoint "haproxy.my.lan:6443" --upload-certs -v=6wie in [4] führt zu diesem Fehler:

Error writing Crisocket information for the control-plane node

vollständige Anmeldung [5]. Ich bin ziemlich ratlos, ob in meiner Haproxy-Konfiguration ein Fehler vorliegt oder ob vielleicht ein Fehler in Docker oder Kubernetes selbst vorliegt.

Meines /etc/docker/daemon.jsonsieht so aus:

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

Antwort1

Obwohl ich keine vernünftige Lösung finden konnte und ein Problem im ursprünglichen „kubeadm“-Projekt bei GitHub verursacht habe, siehe hier:https://github.com/kubernetes/kubeadm/issues/1930.

Da die im Problem vorgeschlagene „Triage“ für mich nicht durchführbar war (Ubuntu ist so ziemlich „eingestellt“), habe ich schließlich eine andere Docker-Distribution eingerichtet, wie hier beschrieben:https://docs.docker.com/install/linux/docker-ce/ubuntu/, Löschen der installierten Verteilung vor dem Starten des neuen Setups.

Beim Ausführen von Docker (Community) v19.03.5über kubeadm v1.16.3wird die folgende Warnung ausgegeben:

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

die Ergebnisse sind ziemlich gut, ich habe es geschafft, meinen HA-Cluster wie in der Originaldokumentation beschrieben einzurichten.

Dies kann also als eineProblemumgehung,NICHTals Lösung für mein ursprüngliches Problem!

verwandte Informationen