OpenShift – Cluster-Recovery nach langer Offline-Zeit

Ausgangslage: zwei Wochen offline, Nodes NotReady

Nach dem Power-on wirkt vieles normal – die Maschinen booten, Prozesse laufen. Trotzdem wird der Cluster nicht gesund: Während der Offline-Zeit sind Node-Zertifikate abgelaufen, die Erneuerungsanträge (CSRs) stapeln sich unbestätigt, und ohne gültige Zertifikate kommen die Nodes nicht auf Ready.

Symptome und Recovery-Plan

Symptom	Dahinter steckt
Cluster über zwei Wochen offline	Zertifikats-Rotation konnte nicht laufen
Mehrere CSRs in `Pending`	Erneuerungsanträge warten auf Freigabe
Nodes werden nicht Ready	erst nach dem Approve der CSRs kamen sie zurück
Kein normaler API-/Admin-Zugriff	Zugang musste über einen Master-Node hergestellt werden

Der Weg zurück in sechs Schritten:

Einen Master im RHCOS Emergency Mode bootenGRUB-Eintrag editieren, single anhängen. → Abschnitt 1
Hinterlegten SSH-Key identifizieren und verbindenÜber die Konsole des Masters. → Abschnitt 2
Lokale kubeconfig nutzenlocalhost.kubeconfig aus den Static-Pod-Resources. → Abschnitt 3
Pending CSRs prüfenoc get csr mit der lokalen kubeconfig. → Abschnitt 4
Alle pending CSRs approvenDanach kommen die Nodes zurück. → Abschnitt 4
Bei Bedarf PVCs aufräumenVom selben Master aus. → Abschnitt 5

Alles bootet, nichts wird gesund: Das Tückische an diesem Fehlerbild ist die Stille – kein Crash, keine rote Konsole. Die Nodes hängen einfach in NotReady, weil niemand die wartenden CSRs stempelt. Nach langen Offline-Phasen deshalb früh auf pending CSRs prüfen, bevor man anderswo sucht.

CSRs sind Passverlängerungsanträge nach dem langen Urlaub: Während der Cluster schlief, sind die Ausweise der Nodes abgelaufen. Die Anträge liegen fertig auf dem Amt – es fehlt nur der Stempel. Ohne Stempel kommt kein Node durch die Kontrolle.

Einen Master im RHCOS Emergency Mode booten

Wenn kein normaler Zugriff mehr existiert, führt der Weg über die Konsole eines Master-Nodes. Ab RHCOS 4.7 lässt sich der Boot-Eintrag in GRUB direkt anpassen.

GRUB-Eintrag editieren

Node rebooten, GRUB-Menü unterbrechenBeim Start das Bootmenü abfangen.
e drückenÖffnet den Boot-Eintrag zum Editieren.
console-Parameter aufräumenIn der Kernel-Kommandozeile nur den tatsächlich genutzten console=-Parameter behalten, den ungenutzten entfernen – im Beispiel: console=ttyS0,115200n8 raus.
single anhängenAls zusätzlichen Boot-Parameter.
Ctrl+XBoot mit den geänderten Parametern fortsetzen.

Der falsche console-Parameter macht die Konsole stumm: Zeigt console= auf eine serielle Schnittstelle, die gar nicht angeschlossen ist, wandert die Boot-Ausgabe ins Leere – am Bildschirm sieht der Boot wie eingefroren aus, obwohl er läuft. Deshalb vor dem Weiterbooten den ungenutzten Eintrag entfernen.

single ist der Werkstatt-Modus: Der Wagen fährt nicht auf die Straße, sondern auf die Hebebühne – genug System, um dranzuarbeiten, ohne dass alles andere mitläuft.

SSH-Key identifizieren und verbinden

Mit Konsolenzugriff auf den Master lässt sich nachsehen, welcher SSH-Public-Key auf dem Node hinterlegt ist – und damit der passende private Key für die Verbindung wählen.

Als core-User auf den Master

Sobald klar ist, welcher Key hinterlegt ist, geht es per SSH auf den Node; alle folgenden Schritte laufen in dieser Session.

ssh core@<master-ip> -i <ssh-key>

Die lokale kubeconfig des Masters nutzen

Jeder Master trägt in den Static-Pod-Resources des kube-apiservers eine lokale kubeconfig – sie öffnet den Cluster-Zugriff direkt vom Node aus, ganz ohne die normalen Zugangswege.

localhost.kubeconfig aus den Static-Pod-Resources

cd /etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/
oc --kubeconfig=localhost.kubeconfig get po -A

Liefert der Befehl Pod-Listen, steht der Zugriff – ab hier funktionieren alle oc-Kommandos mit --kubeconfig=localhost.kubeconfig.

Der Hausschlüssel unter der Fußmatte: Wenn alle regulären Türen (API-URL, oauth, Admin-kubeconfig) klemmen, liegt auf jedem Master noch ein lokaler Schlüssel bereit. Man muss nur erst physisch vor der Tür stehen – genau dafür waren Abschnitt 1 und 2 da.

Pending CSRs prüfen und approven

Der Kern des Recovery: Erst die Lage sichten, dann alle wartenden Anträge in einem Zug freigeben. Im beschriebenen Fall kamen die Nodes direkt danach zurück.

Sichten, dann stempeln

# Lage pruefen - viele CSRs standen auf Pending
oc --kubeconfig=localhost.kubeconfig get csr

# alle pending CSRs in einem Zug approven
oc --kubeconfig=localhost.kubeconfig get csr -o name \
  | xargs oc --kubeconfig=localhost.kubeconfig adm certificate approve

Nach dem Approve begannen die Nodes, wieder online zu kommen. Dabei können neue CSRs nachrücken – get csr also wiederholen, bis nichts mehr auf Pending steht.

Hinweis: Der xargs-Einzeiler gibt alle vorhandenen CSRs frei. Im Recovery-Fall nach langer Offline-Zeit ist genau das gewollt – im Normalbetrieb gehört vor jedes Approve ein Blick, wer da eigentlich anfragt.

Aufräumen und Merkposten

Vom selben Master lassen sich mit der lokalen kubeconfig auch Aufräumarbeiten erledigen – im beschriebenen Fall das Löschen betroffener PVCs.

PVCs löschen (falls nötig)

oc --kubeconfig=localhost.kubeconfig delete pvc <pvc-name> -n <namespace>

Bei Bedarf für alle betroffenen Namespaces und PVCs wiederholen.

Was aus dem Fall bleibt

Ein Master reicht. Ohne API- und Admin-Zugriff genügt ein erreichbarer Master-Node, um den Cluster-Zugriff wiederherzustellen
CSRs zuerst. Nach langen Offline-Phasen früh auf pending CSRs prüfen – sie sind der häufige Grund, warum Nodes nicht Ready werden
localhost.kubeconfig kennen. Der Pfad unter /etc/kubernetes/static-pod-resources/.../node-kubeconfigs/ ist der Rettungsanker, wenn die normalen Zugangswege tot sind