Im Wartungsfenster upgraden

Das ist der letzte Schritt des Lernpfads. Du upgradest Staging auf ein neueres Release, während du zusiehst, misst, wie lange die Kubernetes-API und deine App weg sind, prüfst die App und lässt die Produktion dasselbe Release dann in ihrem Wartungsfenster übernehmen.

In Arbeit: noch nicht buchbar

Gebaut im Labor: Am 2026-10-10 hat pbx-agent einen Cluster auf einem echten Hetzner-Server mit Now von Release 2026.10.0 auf 2026.10.1 upgegradet, in 83 Sekunden, mit einem Snapshot vorweg. Upgrades, die auf das Wartungsfenster warten, und die automatische Rückkehr zum vorigen Image nach einem ungesunden Start sind In Arbeit. Die Oberfläche des Portals ist englisch, darum stehen ihre Beschriftungen hier auf Englisch. Nachgehen kannst du die Schritte noch nicht. Sag mir, wenn es buchbar ist.

Jedes Upgrade startet den Server neu. Auf einem einzelnen Node sind die Kubernetes-API und deine Apps weg, solange er neu startet; im Labor war die API 34 Sekunden lang nicht erreichbar.

Was du am Ende hast

Staging auf dem neueren Release, die Ausfallzeit von dir selbst gemessen, und die Produktion für ihr Fenster eingeplant. Das ist die Reihenfolge, für die PaaSbox gebaut ist: Ein Release erreicht zuerst Staging, und die Produktion übernimmt es erst, nachdem Staging es betrieben hat.

Was du brauchst

• upcheck-staging und upcheck-prod aus Schritt 4. Staging ist auf dem Kanal early, und seine Patch-Releases warten auf deinen Klick.
• Ein neueres Release auf early. Der Reiter Upgrades von Staging zeigt es als Karte, Release und seine Version, mit seinen Notizen. Sagt er, dass auf dem Kanal kein neueres Release angeboten wird, gibt es noch keines; Releases und Kanäle listet die Releases.
• Eine Admin-Kubeconfig von Staging, gültig für eine Stunde oder länger.

API und App beobachten

Starte in einem zweiten Terminal eine Schleife, die einmal pro Sekunde die API und die App fragt:

export KUBECONFIG=~/Downloads/upcheck-staging-admin.kubeconfig
while true; do
  api=$(kubectl get --raw /readyz --request-timeout=2s 2>/dev/null || echo down)
  app=$(curl -s -o /dev/null -m 2 -w '%{http_code}' https://upcheck-staging.example.com/)
  echo "$(date +%T) api=$api app=$app"
  sleep 1
done

api=ok app=200 ist ein gesunder Cluster. Lass die Schleife laufen.

Staging jetzt upgraden

1. Lies auf dem Reiter Upgrades von Staging die Notizen des Release. Die Karte sagt, ob das Release ein Patch ist (dieselbe k3s-Minor-Version) oder eine neue k3s-Minor-Version. Wähle Now. Das Portal stellt das Upgrade in die Warteschlange, und pbx-agent holt es bei seiner nächsten Synchronisation ab; er synchronisiert alle 30 Sekunden.

2. Verfolge die Schritte im Hinweis über der Karte:

   • preflight: Die Signatur des Release stimmt, der Cluster darf von seinem Release aus dorthin wechseln, und die Boot-Partition hat Platz für das neue Image.
   • pre_snapshot: ein Snapshot des Clusters, in deinen Bucket.
   • fetch_image und stage_slot: Das neue Node-Image wird heruntergeladen, gegen das signierte Release geprüft und als zweiter Boot-Eintrag neben das laufende geschrieben.
   • reboot: Der Server startet das neue Image. Deine Schleife zeigt jetzt api=down und keine 200.
   • health_gate: pbx-agent wartet auf die API, darauf, dass der Node auf dem neuen k3s Ready ist, auf den neuen Boot-Eintrag und auf jedes Deployment in kube-system.
   • commit: Das neue Image wird zum Standard. Das vorige bleibt als zweiter Eintrag.

3. Lies die Zeiten der Schleife ab. Im Labor war die API 34 Sekunden lang nicht erreichbar, und das ganze Upgrade dauerte vom Klick bis zum Erfolg 83 Sekunden. Deine App antwortet wieder, sobald ihre Pods gestartet sind; das Health-Gate wartet nicht auf sie.

4. Der Kopf der Cluster-Seite nennt jetzt das neue Release, und Upgrade history führt das Upgrade als erfolgreich. Der Snapshot aus pre_snapshot liegt in deinem Bucket, benannt mit pbx-pre-upgrade- und dem Release.

Besteht der Node das Health-Gate nicht innerhalb von 20 Minuten nach dem Neustart, startet pbx-agent ihn in das vorige Image neu und meldet das Upgrade als fehlgeschlagen. In Arbeit Diese Rückkehr ist auf einem echten Node noch nie ausgelöst worden. Hat der Node das Gate bestanden, wird nichts mehr von selbst zurückgerollt: Der Snapshot aus pre_snapshot ist der Weg zurück für den Zustand des Clusters, wie in Schritt 5.

Die App prüfen

kubectl -n upcheck get saasapp upcheck

Die Phase ist Ready, und die Schleife zeigt wieder app=200. Öffne die App im Browser und benutze sie so, wie deine Nutzer es tun. Diese Prüfung ist deine: Kein Teil von PaaSbox weiß, was deine App antworten soll. Beende die Schleife mit Ctrl-C.

Die Produktion für ihr Fenster einplanen

1. Warte, bis das Release stable erreicht: nach seinen sieben Tagen auf early. Der Reiter Upgrades der Produktion zeigt dann dieselbe Karte.

2. Mit Häkchen bei Install patch releases in the window without a click, wie bei der Produktion, stellt das Portal ein Patch-Release innerhalb einer Stunde von selbst ein: Der Hinweis sagt, dass das Upgrade für das Fenster eingeplant ist, mit Beginn und Ende. Eine neue k3s-Minor-Version wartet auf deinen Klick: Wähle In the next window.

3. Die Overview zeigt unter Facts das Next window. Dort läuft das Upgrade, mit denselben Schritten und demselben Neustart. Verpasst es ein Fenster, weil pbx-agent nicht rechtzeitig erreichbar war, rückt es ins nächste, bis zu 14 Tage lang.

In Arbeit Upgrades, die für das Fenster eingeplant sind, sind auf einem echten Server noch nicht gelaufen.

Was du jetzt hast

Den ganzen Pfad: einen Cluster in deinem eigenen Projekt, eine App darauf, einen Agenten, der in einem eigenen Cluster testet, Staging und Produktion getrennt, eine geübte Wiederherstellung und ein Upgrade, das du beobachtet hast, bevor die Produktion es übernahm. Die nächsten Seiten geben diese Arbeit an einen Agenten ab.

Warum isolierte Cluster für AgentenEin Cluster pro Test, pro Stage und pro App: was es bringt, was es kostet, wovor es nicht schützt.

Rezept: Ein Agent upgradet zuerst StagingEin Agent upgradet Staging, wenn ein Release kommt, prüft die App und plant die Produktion nur ein, wenn Staging bestanden hat.