Ein Agent upgradet zuerst Staging

Mit einem Cluster pro Stage muss jedes Release mehr als einmal installiert werden. Dieses Rezept gibt das an einen Agenten ab, in fester Reihenfolge: Wird Staging ein neues Release angeboten, upgradet der Agent Staging sofort, prüft die App und plant die Produktion nur dann für ihr nächstes Wartungsfenster ein, wenn alles bestanden hat. Scheitert Staging, bleibt die Produktion unberührt.

In Arbeit: noch nicht buchbar

In Arbeit Die MCP-Tools und die REST-API gibt es als Code im Portal; gegen einen echten Cluster sind sie noch nicht gelaufen. Ein sofort gestartetes Upgrade ist am 2026-10-10 Gebaut im Labor auf echten Hetzner-Servern gelaufen. Ein Upgrade, das auf das Wartungsfenster wartet, und der Rückfall auf das vorherige Release, wenn das neue seine Gesundheitsprüfung nicht besteht, sind auf einem echten Node noch nicht gelaufen: In Arbeit. Die Oberfläche des Portals ist englisch, darum stehen ihre Beschriftungen hier auf Englisch. Sag mir, wenn es buchbar ist.

Was du brauchst

• Staging und Produktion als getrennte Cluster, upcheck-staging und upcheck-prod, wie in Lernschritt 4. Setz auf dem Reiter Upgrades jedes Clusters den Release channel: early für Staging, stable für die Produktion. Ein Release erreicht zuerst early und nach seiner Zeit dort stable, so sieht Staging es, bevor es der Produktion angeboten wird.
• Nimm bei der Produktion den Haken bei Install patch releases in the window without a click heraus. Sonst installieren sich Patch-Releases im Fenster der Produktion, ob Staging bestanden hat oder nicht.
• Einen API-Schlüssel aus API keys & agents, angelegt von einem Team-Admin, mit k3s:read, k3s:write und k3s:access. k3s:destructive braucht er nicht: Ein Upgrade gehört nicht zu den zerstörerischen Operationen.
• Die Prüfungen deiner App: was nach einem Upgrade wahr sein muss, etwa dass die Health-Seite antwortet und ein Login funktioniert.

Die Routine

Gib deinem Agenten diese Schritte und lass ihn einmal am Tag laufen, oder wenn ein Release angekündigt ist.

1. Nach einem Release sehen. get_cluster für upcheck-staging. Unter upgrade ist available das angebotene Release mit seiner version, seiner k3s-Version und seinen Notizen, und patch sagt, ob es bei der k3s-Minor-Version bleibt. canSchedule ist wahr, wenn der Cluster bereit ist und kein Upgrade ansteht. Nichts angeboten: Schluss.

2. Staging jetzt upgraden. schedule_upgrade mit when now und release gleich dieser Version: Wird bis dahin eine andere Version angeboten, lehnt das Portal den Aufruf mit 409 ab, statt sie zu installieren. Das Upgrade macht zuerst einen Snapshot, schreibt das neue Image neben das laufende, startet den Node darin neu und prüft seine Gesundheit. Im Labor dauerte es 83 Sekunden, und die Kubernetes-API war 34 Sekunden lang nicht erreichbar.

3. Auf das Ergebnis warten. Frag get_operation ab, bis state succeeded oder failed ist.

4. Staging prüfen. Bestanden ist es, wenn all das gilt:

   • die Operation ist succeeded;
   • get_cluster zeigt state ready, als release die neue Version und keine Zustandsaussage, die vorher nicht da war;
   • mit einer admin-Kubeconfig aus request_kubeconfig (eine view-Kubeconfig kann die Nodes nicht auflisten) zeigt kubectl get nodes den Node Ready und kubectl -n upcheck get saasapp upcheck zeigt Ready;
   • die eigenen Prüfungen deiner App bestehen.

5. Die Produktion einplanen, oder nicht. Hat Staging bestanden, warte, bis get_cluster für upcheck-prod dieselbe Version anbietet, und ruf dann schedule_upgrade mit when window und release gleich dieser Version auf. Das Upgrade wartet auf das nächste Wartungsfenster der Produktion, das upgrade.nextWindow zeigt. Wird der Produktion eine Version angeboten, die auf Staging nie lief, plane nichts ein und berichte es.

6. Berichten. Welche Version, das Ergebnis auf Staging mit ID und Dauer der Operation, und ob die Produktion eingeplant ist und für wann.

Wenn Staging scheitert

Der Agent hält an, plant nichts für die Produktion ein und berichtet den fehlgeschlagenen Schritt der Operation und ihre Meldung aus get_operation. Er versucht es nicht von selbst noch einmal.

Wie Staging nach einem Fehlschlag aussieht, hängt vom Schritt ab. Vor dem Neustart läuft auf dem Node noch das Release, das er hatte. Nach dem Neustart wird ein Node, der auf dem neuen Release nicht innerhalb von 20 Minuten gesund ist, in das vorherige neu gestartet In Arbeit; dieser Rückfall ist auf einem echten Node noch nicht gelaufen. So oder so liegt der Snapshot, den das Upgrade zuerst gemacht hat und dessen Name mit pbx-pre-upgrade- beginnt, in deinem Bucket, und Snapshots machen und wiederherstellen hat die Wiederherstellung.

Was der Agent nicht kann

Mit diesem Schlüssel kann der Agent weder den Kanal eines Clusters noch sein Wartungsfenster noch die Einstellung für Patch-Releases ändern: Die stehen auf den Reitern Upgrades und Settings, und dafür gibt es kein Tool. Er kann auch nichts wiederherstellen oder löschen, weil der Schlüssel kein k3s:destructive hat.

6 · Im Wartungsfenster upgradenDieselbe Reihenfolge von Hand: Staging jetzt, die Produktion in ihrem Fenster.

Einen Cluster upgradenKanäle, die Einstellung für Patch-Releases, und was passiert, wenn ein Upgrade scheitert.