<p>kubeadm Reset erfolgreich, aber diese Knoten-IP befindet sich noch in der kubeadm-config configmap</p>

cc @fabriziopandini

Idealerweise gibt es eine Möglichkeit, den ClusterStatus zu "aktualisieren". Wir führen Cluster mit Chaostests aus. Es ist durchaus möglich, dass ein Knoten der Steuerebene ohne Vorwarnung und ohne die Möglichkeit, kubeadm reset auszuführen, beendet wird. Im Idealfall gibt es eine saubere Möglichkeit, den ClusterStatus explizit zu aktualisieren, um Steuerebenenknoten zu entfernen, von denen wir wissen, dass sie sich nicht mehr im Cluster befinden. Dies ist etwas, das getan werden würde, bevor kubeadm join --control-plane ... oder möglicherweise ist es eingebaut?

Einige Kommentare hier:

kubeadm-config ConfigMap entfernt diese Knoten-IP.

@pytimer Ich weiß, dass es nicht ideal ist, eine Knoten-API-Adresse im Cluster-Status zu haben, aber ich bin daran interessiert zu verstehen, ob dieser "Mangel an Bereinigung" Probleme verursacht oder nicht. Haben Sie versucht, sich wieder derselben Kontrollebene anzuschließen? Haben Sie versucht, sich einer anderen Kontrollebene anzuschließen? Ich erwarte keine Probleme, aber eine Bestätigung zu diesem Punkt wird sehr geschätzt.

Ich habe noch eine Frage, warum kubeadm reset diesen Knoten nicht direkt aus dem Cluster löscht. Führen Sie stattdessen kubectl delete node ausmanuell.

@luxas könnte ein bisschen historischer Kontext sein, der hier helfen kann.
Ich vermute, dass der Knoten nicht das Privileg hatte, sich selbst zu löschen (dies gilt jedoch für Arbeiterknoten, nicht für Knoten auf Steuerebene ...).

Idealerweise gibt es eine Möglichkeit, den ClusterStatus zu "aktualisieren" / es gibt eine saubere Möglichkeit, den ClusterStatus explizit zu aktualisieren

@ Danbeaulieu das ist ein guter Punkt. Es ist eine gute Idee, einen expliziten Befehl zum Synchronisieren des Clusterstatus und zum Erzwingen der automatischen Synchronisierung zu haben, wenn kubeadm ausgeführt wird.
Da kubeadm jedoch keinen kontinuierlich laufenden Regelkreis hat, besteht meiner Meinung nach immer die Möglichkeit, dass ClusterStatus nicht synchron ist.
Dies sollte kein Problem sein, oder insbesondere sollte es kein Problem sein, eine Knoten-IP für nicht mehr vorhandene Knoten zu haben (fehlende Bereinigung).
Wenn stattdessen ein Knoten vorhanden ist und die entsprechende Knoten-IP in ClusterStatus fehlt (falsche Initialisierung), kann dies zu Problemen führen, z. B. bei Aktualisierungen.

Könnten Sie uns bitte mitteilen, ob die oben genannten Annahmen durch Ihre Chaostests bestätigt wurden? Jedes Feedback wird sehr geschätzt.

@fabriziopandini Ich Steuerebene bei, es ist fehlgeschlagen.

Meine Beitrittsschritte:

Die IP des zweiten Steuerebenenknotens ist 192.168.46.212 .

• Entfernen Sie das etcd-Mitglied des Knotens 192.168.46.212 aus dem etcd-Cluster.
• kubectl delete node k8s-212
• kubeadm reset -f auf diesem Knoten der Steuerebene.
• Führen Sie kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 erneut aus.

kubeadm Join-Protokolle:

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

Ich sehe den Kubeadm-Code und ich denke, dieses Problem kann durch 192.168.46.212 verursacht werden, das in der kubeadm-config ConfigMap verblieben ist.

Kubeadm erhält API-Endpunkte von kubeadm-config ConfigMap, wenn der Knoten der Steuerebene verbunden wird, und etcd-Endpunkte sind dieselben wie API-Endpunkte. Der Knoten 912.168.46.212 Control-Plane wurde entfernt und ist noch nicht verbunden. Überprüfen Sie daher, ob der Zustand des etcd-Clusters falsch ist.

Wenn ich den API-Endpunkt 192.168.46.212 aus der ConfigMap kubeadm-config entferne und diesen Knoten

@pytimer danke!
Dies sollte untersucht werden. Es gibt bereits eine Logik, die versucht, die vermeintliche Liste der etcd-Endpunkte mit dem realen etcd-Listenendpunkt zu synchronisieren, aber etwas scheint nicht richtig zu funktionieren

Ja, das scheint ein Fehler zu sein. Wir haben eine 3-Knoten-Steuerebene ASG. Wenn wir eine Instanz beenden, wird eine neue gemäß den ASG-Regeln erstellt. Während dieser Zeit wird der terminierte Knoten in der Mitgliederliste von etcd als fehlerhaft aufgeführt. Wenn die neue Instanz gestartet wird, bevor kubeadm join... , wird das ungesunde Mitglied aus etcd entfernt. Zu dem Zeitpunkt, an dem wir kubeadm join... ausführen, ist der etcd-Cluster mit 2 Knoten gemäß etcd fehlerfrei. Kubeadm verwendet jedoch den ClusterStatus als Quelle der Wahrheit, in der immer noch die alte Instanz aufgeführt ist.

Die Problemumgehung für uns besteht direkt nach der Verwaltung der etcd-Mitgliedschaft darin, die kubeadm-config ConfigMap mit der Wahrheit des Clusters zu aktualisieren und dann kubeadm join... auszuführen.

Idealerweise würde kubeadm join... etcd als Quelle der Wahrheit verwenden und die kubeadm-config ConfigMap entsprechend aktualisieren.

@fabianofranz Ich habe vielleicht die Ursache für dieses Problem gefunden.

Wenn Sie die etcd-Endpunkte mit der realen etcd-Endpunktliste synchronisieren, ist die Synchronisierung erfolgreich. Weisen Sie die realen etcd-Endpunkte jedoch dem etcd-Client Endpoints . Diese Clientvariable ist kein Zeiger. Wenn also anderer Code den Client verwendet, sind diese Clientendpunkte immer noch alte Endpunkte, nicht die realen Endpunkte nach der Synchronisierung.

Ich habe dieses Problem in meinem Fork-Repository behoben. Sie können diese PR unter https://github.com/pytimer/kubernetes/commit/0cdf6cad87a317be5326f868bafe4faecc80f033 überprüfen join the same control-plane node User Case, es verbindet Erfolg.

@pytimer Sieht gut aus! Gut erkannt!
Könnten Sie bitte eine PR senden? IMO ist dies für die Kirschernte geeignet.

@ neolit123 @timothysc ^^^

@fabianofranz Die erste PR ist falsch, ich vergesse, CLA zu bestätigen.

Diese PR https://github.com/kubernetes/kubernetes/pull/71945 können Sie überprüfen. Wenn etwas nicht stimmt, hoffe ich, dass Sie darauf hinweisen.

@fabriziopandini Ich Steuerebene bei, es ist fehlgeschlagen.

Meine Beitrittsschritte:

Die IP des zweiten Steuerebenenknotens ist 192.168.46.212 .

• Entfernen Sie das etcd-Mitglied des Knotens 192.168.46.212 aus dem etcd-Cluster.
• kubectl delete node k8s-212
• kubeadm reset -f auf diesem Knoten der Steuerebene.
• Führen Sie kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 erneut aus.

kubeadm Join-Protokolle:

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

Ich sehe den Kubeadm-Code und ich denke, dieses Problem kann durch 192.168.46.212 verursacht werden, das in der kubeadm-config ConfigMap verblieben ist.

Kubeadm erhält API-Endpunkte von kubeadm-config ConfigMap, wenn der Knoten der Steuerebene verbunden wird, und etcd-Endpunkte sind dieselben wie API-Endpunkte. Der Knoten 912.168.46.212 Control-Plane wurde entfernt und ist noch nicht verbunden. Überprüfen Sie daher, ob der Zustand des etcd-Clusters falsch ist.

Wenn ich den API-Endpunkt 192.168.46.212 aus der ConfigMap kubeadm-config entferne und diesen Knoten

Ich habe den gleichen Fehler in kubeadm Version 1.13.2 erhalten. Ich habe versucht, den Knoten manuell zu entfernen und kubeadm-config zu aktualisieren. Es funktioniert nicht. Die restlichen etcd-Knoten versuchen immer noch, den entfernten Knoten zu verbinden

Wenn ich den 192.168.46.212 api-Endpunkt von der kubeadm-config ConfigMap entferne und diesen Steuerebenenknoten erneut beitrete, wird er erfolgreich verbunden.

@pytimer Können Sie bitte erläutern, wie Sie den alten API-Server manuell entfernt haben?

Ich verwende 1.13.3. Entfernen des alten Servers manuell über:

1. kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
2. manually edit /tmp/conf.yml to remove the old server
3. kubectl -n kube-system apply -f /tmp/conf.yml 

Ich kann dem Cluster aufgrund des Fehlers immer noch nicht beitreten:

[etcd] Checking etcd cluster health
etcd cluster is not healthy: context deadline exceeded

Ich habe dann die API-Pods und die etcd-Pods (jeweils 2) getötet.

Sie werden neu erstellt, aber ich habe immer noch den gleichen Fehler, wenn ich versuche, den zusätzlichen Knoten zu verbinden.

Hatte das gleiche Problem in 1.13.3 (HA-Cluster-Setup: 3 Master-Knoten + 3 Worker). Der Masterknoten wurde erst nach den nächsten Schritten erfolgreich ersetzt:

Knoten aus Cluster löschen

kubectl delete node master03

Laden Sie etcdctl herunter (zum Beispiel auf master01)

mkdir /opt/tools && cd /opt/tools
wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-arm64.tar.gz
tar xfz etcd-v3.3.12-linux-arm64.tar.gz

Entfernen Sie den Masterknoten von etcd

cd /opt/tools/etcd-v3.3.12-linux-arm64
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member list
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member remove 28a9dabfcfbca673

Aus kubeadm-config entfernen

kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
manually edit /tmp/conf.yml to remove the old server
kubectl -n kube-system apply -f /tmp/conf.yml

@zhangyelong Jetzt kann kubeadm reset das etcd-Mitglied nicht entfernen, sodass Sie festgestellt haben, dass der etcd-Cluster immer noch den entfernten etcd-Knoten verbindet. Sie sollten das etcd-Mitglied jetzt manuell mit etcdctl entfernen.

Ich sende eine PR, um zu implementieren, entfernen Sie den etcd-Knoten, wenn Sie zurücksetzen, können Sie sehen. https://github.com/kubernetes/kubernetes/pull/74112

@lvangool Sie können @Halytskyi Schritte folgen. Der PR: https://github.com/kubernetes/kubernetes/pull/71945 behebt die Synchronisierung von etcd-Endpunkten beim Beitritt zum Steuerebenenknoten. Das etcd-Mitglied kann nicht entfernt werden.

Entfernen Sie das etcd-Mitglied aus dem etcd-Cluster, wenn Sie es zurücksetzen. Sie sehen kubernetes / kubernetes # 74112.

Dies scheint immer noch ein Fehler in 1.13.4 zu sein.

Wir müssen die kubeadm-Konfigurationszuordnung unter https://github.com/kubernetes/kubeadm/issues/1300#issuecomment -463374200 noch manuell aktualisieren

Ist es nicht der Fall, dass das Update in
kubernetes / kubernetes # 71945 würde die etcd-Cluster-Mitgliedschaft als Quelle der Wahrheit für Cluster-Mitglieder verwenden? Wenn nicht, was genau hat diese PR behoben?

Interessanterweise funktioniert es sporadisch, weil im Golang-Bereich über Karten wie ClusterStatus nicht deterministisch ist . Wenn der erste gefundene Endpunkt von einem alten Endpunkt stammt, der nicht mehr existiert, schlagen die Dinge fehl. Wenn ein fehlerfreier Endpunkt gefunden wird, wird der ClusterStatus über die etcd-Synchronisierung aktualisiert.

Ich glaube, die Hauptursache hierfür ist ein Fehler im etcd clientv3, bei dem der Client aufgrund des Fehlers die anderen Endpunkte nicht erneut versucht, wenn der erste fehlschlägt. Https://github.com/etcd-io/etcd/issues/9949.

Verwenden Sie das folgende Problem, um Verbesserungen beim Zurücksetzen zu verfolgen

• https://github.com/kubernetes/kubeadm/issues/1312 Entfernen Sie Knoten der Steuerebene aus ClusterStatus ( @Klaven https://github.com/kubernetes/kubernetes/pull/72886)
• https://github.com/kubernetes/kubeadm/issues/1211 Entfernen Sie etcd-Mitglieder aus dem etcd-Cluster ( @pytimer https://github.com/kubernetes/kubernetes/pull/74112)

@fabriziopandini Hier gibt es mindestens ein weiteres Problem, das nichts mit kubeadm reset tun hat .

Wenn ein Knoten ausfällt, ohne dass die Möglichkeit besteht, einen Kubeadm-Reset durchzuführen (Instanzbeendigung, Hardwarefehler usw.)
Der Cluster befindet sich in einem Zustand, in dem ClusterStatus.apiEndpoints noch einen Knoten auflistet, der sich nicht mehr im Cluster befindet. Dies erfordert die Problemumgehung zum Lesen, Bearbeiten und Aktualisieren der Konfigurationszuordnung, bevor kubeadm join . Kubeadm hat wahrscheinlich 2 Möglichkeiten:

1) Implementieren Sie den etcd-Client erneut, wenn das Wählen fehlschlägt
2) Warten Sie, bis der go-grpc-Fehler behoben ist, und warten Sie dann, bis der Fehler auf dem etcd-Client behoben ist

Dieses Problem kann ein gutes Problem sein, um eine dieser Optionen zu verfolgen.

Wenn ein Knoten ausfällt, ohne dass die Möglichkeit besteht, einen Kubeadm-Reset durchzuführen (Instanzbeendigung, Hardwarefehler usw.)
Der Cluster befindet sich in einem Zustand, in dem ClusterStatus.apiEndpoints noch einen Knoten auflistet, der sich nicht mehr im Cluster befindet. Dies erfordert die Problemumgehung zum Lesen, Bearbeiten und Aktualisieren der Konfigurationszuordnung, bevor kubeadm join .

Das heißt, ohne Reset aufrufen zu müssen, müssen Sie den ClusterStatus manuell aktualisieren.
Wir haben keinen Befehl, der das tut. Wenn Sie der Meinung sind, dass dies eine Funktion ist, die kubeadm unterstützen sollte, reichen Sie bitte ein separates Ticket ein.

Habe das heute am 1.14.1 erlebt

Die Instanz, auf der einer meiner Masterknoten ausgeführt wird, ist fehlgeschlagen, sodass er nicht ordnungsgemäß entfernt werden konnte. Wenn ein neuer Knoten versucht wurde einzutreten, konnte er aufgrund des in diesem Ticket beschriebenen Fehlers nicht beitreten.

Ich musste das etcd-Mitglied manuell über etcdctl entfernen, dann konnte ich einem neuen Knoten beitreten. Ich habe den Knoten auch manuell aus der kubeadm-config ConfigMap entfernt, bin mir aber nicht sicher, ob dies erforderlich war.

@Halytskyi Danke etcdctl Abschnitt hat mir geholfen .....

Habe dies heute in 1.15.5 erlebt

In meinem Fall bin ich dem Cluster beigetreten, jedoch mit der Version 1.16. Löschen Sie dann diesen Knoten kubectl delete node , führen Sie ein Downgrade auf 15.5.5 durch und versuchen Sie erneut, sich anzumelden (gleiche IP-Adresse, gleicher Hostname, andere Version) und erhalten Sie den fehlerhaften Fehler etcd.

Gelöst von (basierend auf der Antwort von @Halytskyi , aber mit aktualisiertem etcdctl):

• Löschen Sie den Knoten aus der kubeadm-config-Konfigurationskarte

>: kubectl edit configmap  kubeadm-config -n kube-system
configmap/kubeadm-config edited

• kubeadm reset -f im problematischen Knoten && iptables -t -f -X und so weiter.

• etcd-Mitglied löschen (dies ist der Schlüssel):

root@k8s-nebula-m-115-2:wget https://github.com/etcd-io/etcd/releases/download/v3.4.3/etcd-v3.4.3-linux-amd64.tar.gz
root@k8s-nebula-m-115-2:tar xfz etcd-v3.4.3-linux-amd64.tar.gz

`` `Shell
root @ k8s-nebula-m-115-2 : ~ / etcdctl / etcd-v3.4.3-linux-amd64 # ./etcdctl --endpoints https://127.0.0.1 : 2379 --cacert / etc / kubernetes / pki /etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key Mitgliederliste
289ed62da3c6e9e5, gestartet, k8s-nebula-m-115-1, https://10.205.30.2 : 2380, https://10.205.30.2 : 2379, false
917e16b9e790c427, gestartet, k8s-nebula-m-115-0, https://10.205.30.1 : 2380, https://10.205.30.1 : 2379, false
ad6b76d968b18085, gestartet, k8s-nebula-m-115-2, https://10.205.30.0 : 2380, https://10.205.30.0 : 2379, false

```shell
root@k8s-nebula-m-115-2:~/etcdctl/etcd-v3.4.3-linux-amd64# ./etcdctl --endpoints https://127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key member remove 289ed62da3c6e9e5
Member 289ed62da3c6e9e5 removed from cluster d4913a539ea2384e

Und dann wieder beitreten funktioniert.

Dies kann passieren, wenn kubeadm reset unterbrochen wird und der Knoten nicht aus dem kubeadm CM gelöscht werden kann.
In diesem Fall müssen Sie es manuell aus dem kubeadm CM löschen.

Wenn ich also den Knoten mit kubectl delete node foobar lösche, ist dies nicht der Fall
aus etcd Mitglied löschen? Aber wenn ich kubeadm reset in dem Knoten mache, den ich will
zu löschen, dann macht es das? 🙄

Am Mittwoch, 30. Oktober 2019, 13:27 Uhr Lubomir I. Ivanov, [email protected]
schrieb:

Dies kann passieren, wenn kubeadm reset unterbrochen wird und das nicht gelöscht werden kann
Knoten vom kubeadm CM.
In diesem Fall müssen Sie es manuell aus dem kubeadm CM löschen.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubeadm/issues/1300?
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AF7BZL4EOZV7GQYNQOM3773QRF4SXANCNFSM4GIIZTPA
.

"kubeadm reset" sollte es aus dem kubeadm CM löschen, aber es ist auch der Aufruf von "kubectl delete node" erforderlich, wodurch das Node API-Objekt gelöscht wird.

In meinem Fall hat das Löschen des Knotens aus de configmap ihn nicht aus dem gelöscht
etcd Cluster Ich musste manuell etcdctl delete member .

Am Do, 31. Oktober 2019 um 16:28 Uhr, Lubomir I. Ivanov [email protected]
schrieb:

"kubeadm reset" sollte es aus dem kubeadm CM löschen, aber "kubectl" aufrufen
Knoten löschen "wird ebenfalls benötigt, wodurch das Knoten-API-Objekt gelöscht wird.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubeadm/issues/1300?
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AF7BZL2KB3GVLTFKQTJTYXLQRL2TLANCNFSM4GIIZTPA
.

kubeadm reset sollte auch das etcd-Mitglied aus dem etcd-Cluster entfernen.
Versuchen Sie es mit zB --v = 5 auszuführen und sehen Sie, was es tut.

Beachten Sie jedoch, dass das Zurücksetzen von kubeadm ein Best-Effort-Befehl ist. Wenn es aus irgendeinem Grund fehlschlägt, wird möglicherweise nur eine Warnung ausgegeben.

kubectl delete node löscht es also nicht aus etcd. Stattdessen wird es im Knoten kubeadm reset .
klingt für mich kaputt, ich denke kubectl delete node sollte es auch aus etcd löschen. Oder fehlt mir ein offensichtlicher Anwendungsfall?
Vielleicht fragen, ob es auch von dort gelöscht werden soll?
Trotzdem danke für die Klarstellung Steuerebene und habe dann einen Reset durchgeführt, denke, es war zu spät, um sich von der etcd zu löschen.

Es gibt also unterschiedliche Verantwortlichkeiten.
kubectl delete node, löscht das Node API-Objekt - Sie sollten dies tun, wenn Sie wirklich sicher sind, dass der Knoten nicht mehr vorhanden sein soll.
davor sollten Sie kubeadm reset auf diesem Knoten aufrufen. Ich bereinige den Status auf der Festplatte und entferne auch das etcd-Mitglied (wenn dies ein Steuerebenenknoten ist und Sie die Standardoption verwenden, bei der etcd-Instanzen pro Steuerebenenknoten ausgeführt werden).

kubeadm reset setzt den Knoten zurück, löscht das Node-Objekt jedoch aus mehreren Gründen nicht:

• Zurücksetzen setzt nur den Knoten zurück und Sie können ihn wieder verbinden. Der Knotenname bleibt reserviert.
• Der Knoten selbst verfügt nicht über genügend Berechtigungen, um sein Knotenobjekt zu löschen. Dies liegt in der Verantwortung des Eigentümers der "admin.conf" (zB Administrator).

kubeadm reset ist ein Best-Effort-Befehl

Diesbezüglich: Wenn kubeadm reset aus irgendeinem Grund nicht abgeschlossen werden kann (einschließlich eines schweren Ausfalls des zugrunde liegenden Servers, sodass das Zurücksetzen von kubeadm überhaupt nicht ausgeführt wird), gibt es neben der manuellen Bearbeitung auch Optionen zum manuellen Abgleichen des Status das kubeadm-config configmap Objekt und den Knoten entfernen?

Wenn der Knoten schwer ausgefallen ist und Sie kubeadm reset nicht aufrufen können, sind manuelle Schritte erforderlich. Sie müssten:
1) Entfernen Sie die IP der Steuerebene aus dem kubeadm-config CM ClusterStatus
2) Entfernen Sie das etcd-Mitglied mit etcdctl
3) Löschen Sie das Node-Objekt mit kubectl (wenn Sie den Node nicht mehr haben möchten)

1 und 2 gelten nur für Steuerebenenknoten.

Gibt es eine Möglichkeit, dieses Failover zu automatisieren, wenn kubeadm reset nicht ausgeführt werden kann?

Gleiche Probleme am 1.9. Danke für die Lösungen.