Staging und Produktion als getrennte Cluster betreiben

Das ist der vierte Schritt des Lernpfads. Du stellst einen Staging-Cluster neben die Produktion, gibst jedem seinen eigenen Release-Kanal und sein eigenes Wartungsfenster und deployst dieselbe App auf beide. Danach fällt jede Stage für sich aus, wird für sich upgegradet und für sich wiederhergestellt.

In Arbeit: noch nicht buchbar

Gebaut im Labor: Am 2026-10-10 hat das Portal Cluster auf echten Hetzner-Servern angelegt, wiederhergestellt, upgegradet und gelöscht. Die PaaSbox Platform ist am 2026-10-11 ebenfalls im Labor auf echten Hetzner-Servern gelaufen, aber das Release, das sie mitbringt, ist noch nicht veröffentlicht. Das Formular zum Anlegen und Upgrades, die auf das Wartungsfenster warten, 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.

Was du am Ende hast

Zwei Cluster für upcheck. upcheck-prod bleibt auf dem Kanal stable, mit seinem Wochenendfenster. upcheck-staging bekommt jedes Release zuerst, auf dem Kanal early, mit einem Fenster in einer Nacht unter der Woche. Jeder hat sein eigenes Hetzner-Projekt, seine eigenen Kubeconfigs, seine eigenen API-Bereiche und seine eigenen Snapshots, und beide betreiben dieselbe upcheck.yaml unter verschiedenen Namen.

Was das bringt: Ein Upgrade, eine Wiederherstellung oder ein außer Kontrolle geratener Test trifft eine Stage, und ein Release läuft auf Staging, bevor die Produktion es sieht. Was es kostet: den Preis zweimal, 29 € inkl. MwSt. pro Cluster und Monat, plus zwei Server zum Preis von Hetzner.

Was du brauchst

• upcheck-prod mit upcheck aus Schritt 2 und die Datei upcheck.yaml.
• Ein zweites Hetzner-Projekt für Staging, mit zwei Tokens mit Read & Write, wie in Schritt 1. Das Token in einem Cluster öffnet sein ganzes Projekt. Wer das Token von Staging lesen kann, darf die Server der Produktion nicht erreichen.
• Einen Bucket für die Snapshots von Staging, mit eigenen Schlüsseln, damit die Schlüssel von Staging die Snapshots der Produktion nicht lesen können.
• Einen zweiten Hostnamen, zum Beispiel upcheck-staging.example.com, in deiner DNS-Zone.

Den Staging-Cluster anlegen

1. Öffne PaaSbox Clusters → Hetzner projects, wähle Add a Hetzner project, nenne es upcheck-staging und füge das erste Token des neuen Projekts ein.

2. Wähle New cluster. Trag als Name upcheck-staging ein und wähle das neue Projekt unter Hetzner project, A new server, die Location der Produktion und den Server type cpx22.

3. Setz den Release channel auf early. Ein Release kommt zuerst auf early und bleibt dort sieben Tage, bevor es stable erreicht; Staging betreibt ein Release also etwa eine Woche, bevor die Produktion es kann.

4. Setz PaaSbox Platform auf saas-http01 und lass With observability (metrics, logs, traces, Grafana) frei: Mit Postgres braucht das einen Server mit 8 GB, und das Formular würde den cpx22 ablehnen. ACME e-mail ist mit deiner Adresse ausgefüllt; Let’s Encrypt legt das Konto unter ihr an. Der Cluster startet dann mit Flux und der Plattform, so wie upcheck-prod sie seit Schritt 2 hat.

5. Setz unter Maintenance window die Days nur auf Tuesday, From 02:00 To 05:00. Ein Upgrade, das in der Nacht auf Dienstag im Fenster von Staging läuft, kannst du am Dienstagmorgen prüfen, Tage vor dem Wochenendfenster der Produktion.

6. Richte die Snapshots auf den Bucket von Staging, mit dem Folder upcheck-staging. Öffne die API nur für deine Adresse, gib dem Cluster A separate token (recommended) mit dem zweiten Token und wähle Create cluster.

7. Ist der Cluster bereit, öffne seinen Reiter Upgrades. Nimm unter Channel das Häkchen bei Install patch releases in the window without a click heraus und wähle Save. Jedes Release wartet dann auf Staging auf deinen Klick, und Schritt 6 zeigt dir das Upgrade, während es läuft. Die Produktion behält die Einstellung: Patch-Releases installieren sich in ihrem Fenster von selbst.

Dieselbe App deployen

1. Hol dir auf dem Reiter Access von Staging eine admin-Kubeconfig und lade sie herunter. Behalte beide Dateien und nenne bei jedem Befehl eine davon, damit kein Befehl die falsche Stage trifft:

   PROD=~/Downloads/upcheck-prod-admin.kubeconfig
   STAGING=~/Downloads/upcheck-staging-admin.kubeconfig
   kubectl --kubeconfig $STAGING get platform

   Warte, bis die Platform READY True ist; der Reiter Add-ons sagt dann applied für Flux und PaaSbox Platform.

2. Lies auf der Overview von Staging die Address des Servers unter Nodes ab und richte upcheck-staging.example.com mit einem A-Record darauf.

3. Mach die Kopie der Datei für Staging, mit ihrem eigenen Namen, und wende sie an:

   sed 's/upcheck.example.com/upcheck-staging.example.com/' upcheck.yaml > upcheck-staging.yaml
   kubectl --kubeconfig $STAGING apply -f upcheck-staging.yaml
   kubectl --kubeconfig $STAGING -n upcheck get saasapp upcheck -w

4. Vergleiche die beiden Stages:

   kubectl --kubeconfig $PROD -n upcheck get saasapp
   kubectl --kubeconfig $STAGING -n upcheck get saasapp

   Dasselbe Image, zwei URLs. Die Datenbank von Staging gehört Staging: Nichts, was du dort tust, erreicht die Daten der Produktion.

Stattdessen aus einem Repository

Auf beiden Clustern läuft Flux, das mit der Plattform kam. Statt kubectl apply von deinem Rechner aus kann jeder Cluster seine Stage aus einem Deploy-Repository ziehen: ein Verzeichnis pro Stage, spec.image als die eine Zeile, die deine CI ändert, und die Produktion nur über einen Pull Request geändert. Du richtest Flux mit einem eigenen GitRepository und einer eigenen Kustomization auf das Repository. In Arbeit Im Labor hat Flux die Teile der Plattform selbst ausgerollt; ein eigenes Deploy-Repository ist mit PaaSbox noch nicht gelaufen.

Was du jetzt hast

Staging und Produktion als zwei Cluster, jeder mit eigenem Projekt, Kanal, Fenster, eigenen Schlüsseln und Snapshots, mit derselben App. Die nächsten Schritte nutzen Staging für das, was du nie zuerst an der Produktion probieren würdest: eine Wiederherstellung, dann ein Upgrade.

5 · Eine Wiederherstellung übenEinen Snapshot von Staging machen, etwas ändern, ihn wiederherstellen und prüfen, was zurückkam.

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