☰

Was macht einen Kubernetes-Knoten fehlerhaft?

tag-icon • tag-icon google-cloud-platform kubernetes google-kubernetes-engine
Was macht einen Kubernetes-Knoten fehlerhaft?

Wir haben im letzten Monat 4 AUTO_REPAIR_NODESEreignisse (angezeigt durch den Befehl gcloud container operations list) auf unserem GKE-Cluster erlebt. Die Folge der automatischen Knotenreparatur ist, dass der Knoten neu erstellt und an eine neue externe IP-Adresse angehängt wird. Die neue externe IP-Adresse, die nicht von Drittanbieterdiensten auf die Whitelist gesetzt wurde, führte schließlich zum Ausfall der auf dem neuen Knoten ausgeführten Dienste.

Mir ist aufgefallen, dass wir "Automatische Knotenreparatur" in unserem Kubernetes-Cluster aktiviert und war versucht, dies zu deaktivieren, aber bevor ich das tue, muss ich mehr über die Situation wissen.

Meine Fragen sind:

  1. Was sind die häufigsten Ursachen, die einen Knoten überhaupt erst in einen schlechten Zustand versetzen? Ich kenne diesen Artikelhttps://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair#node_repair_processDarin heißt es: „Ein Knoten meldet eineNicht bereitStatus bei aufeinanderfolgenden Prüfungen über den angegebenen Zeitschwellenwert" würde eine automatische Reparatur auslösen. Aber was könnte dazu führen, dass ein KnotenNicht bereit?
  2. Ich kenne auch diesen Artikelhttps://kubernetes.io/docs/concepts/architecture/nodes/#node-statusDarin wird die vollständige Liste der Knotenstatus aufgeführt: {OutOfDisk, Ready, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable, ConfigOK}. Ich frage mich, ob ein Knoten NotReady wird, wenn einer der folgenden Zustände zutrifft: {OutOfDisk, MemoryPressure, PIDPressure, DiskPressure, NetworkUnavailable}
  3. Welche negativen Konsequenzen könnten auftreten, wenn ich die „Automatische Knotenreparatur“ im Cluster deaktiviere?Ich frage mich grundsätzlich, ob wir in einer schlimmeren Situation landen könnten als mit automatisch reparierten Knoten und neu angeschlossenen, nicht auf der Whitelist stehenden IP-Adressen.. Wenn die „Automatische Knotenreparatur“ deaktiviert ist, würde Kubernetes dann für die Pods, die auf einem fehlerhaften Knoten ausgeführt werden, der automatisch repariert worden wäre, neue Pods auf anderen Knoten erstellen?

Antwort1

  1. Der Master führt im Wesentlichen eine Integritätsprüfung des Knotens durch. Wenn der Knoten nicht antworten kann oder sich selbst als „Nicht bereit“ deklariert, wird er durch die automatische Knotenreparatur repariert. Auf GKE-Knoten gibt es außerdem einen Knotenproblemdetektor, der Probleme im Betriebssystem erkennen kann.

  2. Jede der genannten Bedingungen kann dazu führen, dass der Knoten in den Status „NotReady“ wechselt. Es gibt auch einige andere mögliche Faktoren, wie z. B. sich wiederholende Fehler auf Betriebssystemebene.

  3. Das Deaktivieren der automatischen Knotenreparatur kann dazu führen, dass Knoten in den Zustand „NotReady“ versetzt werden und in diesem Zustand bleiben. Obwohl der Knoten in vielen Fällen versucht, das Problem zu beheben, indem er entweder Pods oder Prozesse beendet, ist es möglich, dass ein Knoten in „NotReady“ hängen bleibt.

Anstatt die automatische Knotenreparatur zu deaktivieren, würde ich aufgrund der Whitelist-Anforderung empfehlen, Ihr Setup zu ändern. Stattdessen können SieRichten Sie ein NAT-Gateway für den gesamten ausgehenden GKE-Verkehr ein; Sie können dem NAT eine statische IP zuweisen und sich nur darum kümmern, diese IP auf die Whitelist zu setzen. Sie müssen sich keine Sorgen mehr darüber machen, dass die Knoten ihre IPs ändern.

verwandte Informationen