Kubeadm: Laufende Preflight-Checks hängen

Mit v10-Parameter.

[ root@vm03 etcd]# kubeadm join vm10.andrefagundes. org: 6443 --token 07nh7g.v8p5fcs61fn3o2h4 --discovery-token-ca-cert-hash sha256: 039a5f9229dafe39d4a51af6899c20adff1de5dda23f780ac9b896e95f95623a --experimental-control-Ebene --certificate-key cf3c8ca4f74751bfe7fc9d3e00e03a37619d36a6d6fb79fb5ba3645d74dd7bf4 -v10
I0401 00:34:08.531961 16893 join.go:367] [Preflight] gefunden NodeName leer; Verwendung des OS-Hostnamens als NodeName
I0401 00:34:08.532014 16893 join.go:371] [Preflight] gefunden advertiseAddress leer; unter Verwendung der IP-Adresse der Standardschnittstelle als advertiseAddress
I0401 00:34:08.532048 16893 initconfiguration.go:105] erkannt und verwendet CRI-Socket: /var/run/dockershim.sock
I0401 00:34:08.532179 16893 interface.go:384] Suche nach Standardrouten mit IPv4-Adressen
I0401 00:34:08.532187 16893 interface.go:389] Standardroute übergibt Schnittstelle „eth0“
I0401 00:34:08.532324 16893 interface.go:196] Schnittstelle eth0 ist aktiv
I0401 00:34:08.532380 16893 interface.go:244] Schnittstelle "eth0" hat 4 Adressen :[192.168.122.103/24 fe80::a3c0:2a34:91f2:e0eb/64 fe80::8439:c3eb:5848:c1f2/ 64 fe80::4381:b4a5:5836:a0e1/64].
I0401 00:34:08.532399 16893 interface.go:211] Prüfe Adresse 192.168.122.103/24.
I0401 00:34:08.532407 16893 interface.go:218] IP gefunden 192.168.122.103
I0401 00:34:08.532415 16893 interface.go:250] Gültige IPv4-Adresse 192.168.122.103 für Schnittstelle „eth0“ gefunden.
I0401 00:34:08.532421 16893 interface.go:395] Aktive IP 192.168.122.103 gefunden
[preflight] Durchführung von Preflight-Checks
I0401 00:34:08.532495 16893 preflight.go:90] [preflight] Allgemeine Überprüfungen werden ausgeführt
I0401 00:34:08.532539 16893 checks.go:254] Überprüfung der Existenz und Leerheit des Verzeichnisses /etc/kubernetes/manifests
I0401 00:34:08.532570 16893 checks.go:292] Validierung der Existenz der Datei /etc/kubernetes/kubelet.conf
I0401 00:34:08.532579 16893 checks.go:292] Validierung der Existenz der Datei /etc/kubernetes/bootstrap-kubelet.conf
I0401 00:34:08.532586 16893 checks.go:105] Validierung der Containerlaufzeit
I0401 00:34:08.580885 16893 checks.go:131] überprüft, ob der Dienst aktiviert und aktiv ist
I0401 00:34:08.638659 16893 checks.go:341] Validierung des Inhalts der Datei /proc/sys/net/bridge/bridge-nf-call-iptables
I0401 00:34:08.638724 16893 checks.go:341] Validierung des Inhalts der Datei /proc/sys/net/ipv4/ip_forward
I0401 00:34:08.638755 16893 checks.go:653] überprüft, ob Swap aktiviert ist oder nicht
I0401 00:34:08.638788 16893 checks.go:382] Validierung des Vorhandenseins einer ausführbaren IP
I0401 00:34:08.638809 16893 checks.go:382] validieren, ob ausführbare iptables vorhanden sind
I0401 00:34:08.638824 16893 checks.go:382] validiert das Vorhandensein eines ausführbaren Mounts
I0401 00:34:08.638837 16893 checks.go:382] überprüft das Vorhandensein von ausführbarem nsenter
I0401 00:34:08.638849 16893 checks.go:382] validieren, ob ausführbare ebtables vorhanden sind
I0401 00:34:08.638860 16893 checks.go:382] validieren, ob das ausführbare ethtool vorhanden ist
I0401 00:34:08.638871 16893 checks.go:382] Validierung des Vorhandenseins einer ausführbaren Socat
I0401 00:34:08.638883 16893 checks.go:382] Validierung des Vorhandenseins von ausführbarem tc
I0401 00:34:08.638894 16893 checks.go:382] validiert das Vorhandensein einer ausführbaren Berührung
I0401 00:34:08.638914 16893 checks.go:524] alle Prüfungen ausführen
I0401 00:34:08.664826 16893 checks.go:412] überprüft, ob der angegebene Knotenname mit net.LookupHost erreichbar ist
I0401 00:34:08.665583 16893 checks.go:622] Validierung der Kubelet-Version
I0401 00:34:08.709573 16893 checks.go:131] überprüft, ob der Dienst aktiviert und aktiv ist
I0401 00:34:08.716270 16893 checks.go:209] Validierung der Verfügbarkeit von Port 10250
I0401 00:34:08.716418 16893 checks.go:439] überprüft, ob der Verbindungstyp über Proxy oder direkt erfolgt
I0401 00:34:08.716444 16893 join.go:427] [Preflight] Discovering cluster-info
I0401 00:34:08.716498 16893 token.go:200] [Erkennung] Verbindungsversuch zum API-Server „ vm10.andrefagundes.org:6443 “
I0401 00:34:08.716961 16893 token.go:75] [discovery] Cluster-Info-Discovery-Client erstellt, Informationen von „ https://vm10.andrefagundes.org :6443“ angefordert
I0401 00:34:08.717031 16893 round_trippers.go:419] curl -k -v -XGET -H "Accept: application/json, / " -H "User-Agent: kubeadm/v1.14.0 (linux/amd64) kubernetes/ 641856d" ' https://vm10.andrefagundes.org :6443/api/v1/namespaces/kube-public/configmaps/cluster-info'
I0401 00:34:08.722405 16893 round_trippers.go:438] GET https://vm10.andrefagundes.org :6443/api/v1/namespaces/kube-public/configmaps/cluster-info 403 Verboten in 5 Millisekunden
I0401 00:34:08.722423 16893 round_trippers.go:444] Antwort-Header:
I0401 00:34:08.722432 16893 round_trippers.go:447] Inhaltstyp: application/json
I0401 00:34:08.722441 16893 round_trippers.go:447] X-Content-Type-Options: nosniff
I0401 00:34:08.722450 16893 round_trippers.go:447] Inhaltslänge: 321
I0401 00:34:08.722458 16893 round_trippers.go:447] Datum: Mo, 1. April 2019 03:34:08 GMT
I0401 00:34:08.722497 16893 request.go:942] Antworttext: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message ":"configmaps \"cluster-info\" ist verboten: Benutzer \" system:anonymous\ " kann Ressource \"configmaps\" in API-Gruppe \"\" im Namespace \"kube-public\" nicht abrufen"," reason":"Forbidden","details":{"name":"cluster-info","kind":"configmaps"},"code":403}
I0401 00:34:08.722937 16893 token.go:83] [discovery] Cluster-Informationen konnten nicht angefordert werden, versuchen Sie es erneut: [configmaps „cluster-info“ ist verboten: Benutzer „ system:anonymous “ kann Ressource „configmaps“ nicht in API abrufen Gruppe "" im Namespace "kube-public"]

Eine weitere Info ... vm10.andrefagundes.org ist ein Haproxy vor meiner Kontrollebene.

scheint mir ein Netzwerkproblem zu sein.
Sind Sie sicher, dass dieser beitretende Knoten eine Verbindung zu Port 6443 auf dem LB hat und vm10.andrefagundes.org auflösen kann?

Ja, ich habe auch vm10 so geändert, dass es auf die Steuerungsebene zeigt. Ich habe gesehen, wie Verkehr auf der Kontrollebene mit TCDUMP überwacht wurde.

Sehen Sie ausstehende Fehler in den Kubelet-Protokollen?

Es gibt mehrere Fehler in den Protokollen. Ich habe auch versucht, den Cluster einige Male neu zu installieren, und jedes Mal erhalte ich verschiedene Fehler. Ich gebe auf. Wir können den Fall schließen. Danke!!

Funktioniert das Erstellen eines einzelnen Steuerungsebenenknotens + einiger Worker-Knoten für Sie oder tritt das Problem nur auf, wenn zusätzliche Steuerungsebenenknoten hinzugefügt werden?

Benutzer " system:anonymous " kann Ressource "configmaps" in API-Gruppe "" im Namespace "kube-public" nicht abrufen","reason":"Forbidden","details":{"name":"cluster-info", "kind": "configmaps"}, "code": 403

Scheint, als ob kubeadm init Cluster-Info nicht richtig erstellt/konfiguriert
Könnten Sie die kubeadm-Init-Protokolle freigeben?

Ich habe den gleichen Fehler, nachdem ich den Befehl 'kubeadm join ...' ausgeführt habe: Das Ausführen von Preflight-Checks bleibt hängen. Ich habe keine Ahnung, damit umzugehen.

Ich hatte das gleiche Problem. Ich musste den Master neu starten und danach funktionierte das erneute Ausführen des Befehls ‚kubeadm join ...‘ auf den Knoten für mich.

Ich hatte die gleichen Probleme mit kubeadm v1.15 , Reboot Master funktioniert bei mir nicht

Ich hatte die gleichen Probleme mit kubeadm v1.15 , Reboot Master funktioniert bei mir nicht

Zurückgreifen auf kubelet & kubeadm v1.13.1 hat diese Probleme behoben

Stellen Sie sicher, dass Sie kubeadm init/join mit zB --v=2 anrufen, um mehr Details darüber zu erfahren, was vor sich geht.

Ich bin auf das gleiche Problem gestoßen, aber das Problem wurde auf die Netzwerkkonnektivität meiner Seite mit meinen Keepalived- und Haproxy-Daemons zurückgeführt, die falsch konfiguriert waren und verhinderten, dass der Hang-Master-Knoten dem Cluster über den API-Service-VIP beitritt

Erwähnenswert ist, dass ich das Problem durch Ausführen von kubeadm init/join mit --v=2 lösen konnte

Stellen Sie sicher, dass Sie kubeadm init/join mit zB --v=2 anrufen, um mehr Details darüber zu erfahren, was vor sich geht.

kubeadm v1.15

kubeadm join .. --v=2

I0802 11:47:31.027812 359 token.go:202] [Erkennung] Fehler beim Herstellen einer Verbindung zum API-Server "": Token-ID "r5uyqk" ist für diesen Cluster ungültig oder abgelaufen. Verwenden Sie „kubeadm token create“ auf dem Knoten der Steuerungsebene, um ein neues gültiges Token zu erstellen

kubeadm-Init-Phase upload-certs --upload-certs
kubeadm-Token erstellen

dann kubeadm beitreten erfolgreich

In meinem Fall konnte ich dem Knoten erfolgreich beitreten, indem ich die Firewall auf dem Master-Knoten stoppte.

systemctl stop firewall

In meinem Fall konnte ich dem Knoten erfolgreich beitreten, indem ich die Firewall auf dem Master-Knoten stoppte.

systemctl stop firewall

Dieser funktionierte wie ein Zauber.
[ root@localhost ~]# kubeadm join 192.168.8.128:6443 --token 38lhr8.kxi5uy8aoy71dj17 --discovery-token-ca-cert-hash sha256:a12c805b8d98f42a256486d27e87463e22aaba190ab8f5bdce8
[preflight] Durchführung von Preflight-Checks
[WARNUNG IsDockerSystemdCheck]: „cgroupfs“ als Docker-cgroup-Treiber erkannt. Der empfohlene Treiber ist "systemd". Bitte folgen Sie der Anleitung unter https://kubernetes.io/docs/setup/cri/
[WARNUNG SystemVerification]: Diese Docker-Version ist nicht auf der Liste der validierten Versionen: 19.03.1. Letzte validierte Version: 18.09
[Preflight] Konfiguration aus dem Cluster lesen...
[Preflight] FYI: Sie können sich diese Konfigurationsdatei mit „kubectl -n kube-system get cm kubeadm-config -oyaml“ ansehen.
[kubelet-start] Herunterladen der Konfiguration für das kubelet aus der ConfigMap „kubelet-config-1.14“ im kube-system-Namespace
[kubelet-start] Kubelet-Konfiguration in Datei „/var/lib/kubelet/config.yaml“ schreiben
[kubelet-start] Kubelet-Umgebungsdatei mit Flags in die Datei „/var/lib/kubelet/kubeadm-flags.env“ schreiben
[kubelet-start] Aktivierung des kubelet-Dienstes
[kubelet-start] Warten, bis das Kubelet den TLS-Bootstrap ausführt...

Dieser Knoten ist dem Cluster beigetreten:

• Zertifikatsignierungsanforderung wurde an apiserver gesendet und eine Antwort wurde empfangen.
• Das Kubelet wurde über die neuen sicheren Verbindungsdetails informiert.

Führen Sie „kubectl get nodes“ auf der Steuerungsebene aus, um zu sehen, wie dieser Knoten dem Cluster beitritt.

Wenn Sie sich das Protokoll im OP erneut ansehen, ist dies kein "Hängen" im Preflight, sondern es kann nicht auf die Cluster-Info-Konfigurationskarte zugegriffen werden. Dies könnte nur passieren, wenn die "Boostrap-Token" -Phase von "init" wird übersprungen.

Wenn ich mir spätere Berichte ansehe, sehe ich Probleme mit Netzwerken und abgelaufenen Token, die unter "Support"-Elemente und nicht unter Bugs fallen.

/Triage-Unterstützung
Bei Fragen versuchen Sie es mit stackoverflow, reddit oder #kubeadm auf k8s slack.

Wenn Sie einen echten Fehler finden, öffnen Sie bitte ein neues Problem.

In meinem Fall konnte ich dem Knoten erfolgreich beitreten, indem ich die Firewall auf dem Master-Knoten stoppte.

systemctl stop firewall

systemctl Firewall stoppen

Ich finde, dass der Datenverkehr nicht erlaubt war, den Master-Knoten zu verbinden.

Das Hinzufügen von Regeln in sg hat mein Problem gelöst

Ich habe den gleichen Fehler, nachdem ich den Befehl 'kubeadm join ...' ausgeführt habe: Das Ausführen von Preflight-Checks bleibt hängen. Ich habe keine Ahnung, damit umzugehen.

Hast du eine Lösung gefunden?

Ich finde, dass der Datenverkehr nicht erlaubt war, den Master-Knoten zu verbinden.

Das Hinzufügen von Regeln in sg hat mein Problem gelöst

Welchen eingehenden Port hast du zugelassen?