Ohne PaaSbox weiterbetreiben

Ein Cluster von PaaSbox Clusters läuft vollständig in deinem Hetzner-Projekt. Das Portal hat immer nur Anrufe von pbx-agent auf deinem Server beantwortet; deinen Cluster hat es nie betrieben. Wenn du abkoppelst oder PaaSbox verschwindet, läuft der Cluster weiter, und diese Seite ist, was du brauchst, um ihn selbst zu betreiben.

Was weiterläuft und was aufhört

Läuft weiter:

k3s und deine Workloads, der Server, sein privates Netz und seine Firewall.
Die geplanten Snapshots. k3s macht sie selbst und lädt sie in deinen Bucket, solange die Schlüssel im Secret kube-system/pbx-etcd-s3 gültig bleiben.

Hört auf:

Upgrades des Node-Images und von k3s.
Kubeconfigs aus dem Portal, Wiederherstellungen aus dem Portal und die Mails über ausgefallene Snapshots, fehlgeschlagene Upgrades und ablaufende Zertifikate.
Die Arbeit von pbx-agent. Einmal widerrufen, ändert er nichts mehr. Solange er das Portal bloß nicht erreicht, wendet er die zuletzt erhaltenen Einstellungen weiter an; entferne ihn darum (unten), bevor du die Objekte der Add-ons von Hand änderst. Danach gehören sie dir.

Was du schon hast

Was	Wo
root auf dem Server	SSH mit Schlüssel, ein Pod auf dem Node oder das Rescue-System von Hetzner: Root auf dem Server bekommen
Eine dauerhafte Admin-Kubeconfig	`/etc/rancher/k3s/k3s.yaml` auf dem Server
Das k3s-Server-Token	`/etc/rancher/k3s/config.yaml` auf dem Server, Schlüssel `token`; k3s hält es außerdem in `/var/lib/rancher/k3s/server/token`
Die Snapshots	dein Bucket, und die lokalen Kopien von k3s in `/var/lib/rancher/k3s/server/db/snapshots/` auf dem Server
Die Konfiguration von k3s	`/etc/rancher/k3s/config.yaml` und die Drop-ins in `/etc/rancher/k3s/config.yaml.d/`
Das Node-Image	ein Snapshot in deinem Hetzner-Projekt, mit dem Label `pbx-image`

/etc ist auf dem Node ein Overlay, das auf dem dauerhaften /var liegt; was du dort änderst, übersteht Neustarts und Image-Updates.

Vor dem Abkoppeln

Wenn du den Zeitpunkt wählen kannst, erledige das zuerst, solange das Portal noch funktioniert:

Verschaff dir eigenen root-Zugang. Trag deinen SSH-Schlüssel ein und öffne Port 22 für deine Adresse mit einer eigenen Firewall, wie Root auf dem Server bekommen zeigt. Melde dich einmal an, um es zu prüfen.
Kopier die Admin-Kubeconfig auf deinen Rechner:
Terminal-Fenster
```
scp root@<IPv4 des Servers>:/etc/rancher/k3s/k3s.yaml ./admin.kubeconfig
```
Ändere ihre Zeile server: von https://127.0.0.1:6443 auf den API-Namen des Clusters und verwahre die Datei sicher: Sie läuft nicht ab.
Bewahr eine Kopie des Server-Tokens auf, aus der Zeile token von /etc/rancher/k3s/config.yaml, in deinem Passwortmanager. Eine Wiederherstellung auf einem anderen Server braucht es.
Mach jetzt einen Snapshot im Portal und prüfe, dass er in deinem Bucket liegt.
Richte einen eigenen DNS-Namen ein (unten), solange der Name von PaaSbox noch antwortet.

Abkoppeln, dann pbx-agent entfernen

Kopple im Portal unter Settings → Detach ab. Dann, auf dem Server:

pbx-agent uninstall --yes

Das entfernt die Unit von pbx-agent, seinen Rollback-Timer, /var/lib/pbx-agent und /etc/pbx-agent, und lässt k3s, seine Konfiguration und jedes Kubernetes-Objekt in Ruhe. Die Namespaces pbx-access (die ServiceAccounts der Kubeconfigs aus dem Portal) und pbx-system (die Lease von pbx-agent) bleiben; lösch sie mit kubectl delete namespace pbx-access pbx-system, wenn du sie nicht mehr brauchst.

Ersetzen, was das Portal verwahrt hat

Das Portal hat Tokens und Schlüssel für dein Projekt und deinen Cluster verwahrt. Ersetze sie, damit seine Kopien nichts mehr öffnen.

Das Hetzner-Token, das du dem Portal gegeben hast. Widerrufe es in der Hetzner-Konsole unter Security → API tokens. Der Cluster benutzt es nicht, mit einer Ausnahme: Hast du für den Cluster A copy of the project’s token gewählt, benutzt der Cluster genau dieses Token. Dann ersetze zuerst das Token des Clusters (nächster Punkt).

Das Hetzner-Token im Cluster. Leg ein neues Token desselben Projekts an, schreib es ins Secret kube-system/hcloud (Schlüssel token; behalte den Schlüssel network) und starte die Workloads neu, die es lesen:

kubectl -n kube-system create secret generic hcloud \
  --from-literal=token=<neues Token> \
  --from-literal=network=$(kubectl -n kube-system get secret hcloud -o jsonpath='{.data.network}' | base64 -d) \
  --dry-run=client -o yaml | kubectl apply -f -
kubectl -n kube-system get deploy,ds | grep hcloud
kubectl -n kube-system rollout restart deployment/<jedes gelistete>   # und daemonset/<…>

Widerrufe danach das alte Token in der Hetzner-Konsole.

Die S3-Schlüssel, wenn das Portal sie gehalten hat. Leg bei deinem S3-Anbieter neue an, trag sie ins Secret kube-system/pbx-etcd-s3 ein (Schlüssel etcd-s3-access-key und etcd-s3-secret-key) und widerrufe die alten. k3s liest das Secret bei jedem Snapshot; ein Neustart ist nicht nötig.
Die DNS-Tokens der Add-ons, die eines nutzen: cert-manager, external-dns und die PaaSbox Platform mit Wildcard-Zertifikaten. Jedes steht in der Werte-Datei im Secret des Add-ons, kube-system/pbx-addon-<name>. Ersetze das Token dort und widerrufe das alte dort, wo du es angelegt hast.
Das k3s-Server-Token hat das Portal ebenfalls verwahrt. k3s kann es mit k3s token rotate ersetzen; Snapshots von davor brauchen zur Wiederherstellung das alte Token, also behalte es.

Auf einen eigenen DNS-Namen umziehen

Der Name der API, <label>.<team>.k3s. in der Zone von PaaSbox, bleibt nach dem Abkoppeln 30 Tage. Verschwindet PaaSbox, ist er sofort weg. So ziehst du auf einen eigenen Namen um:

Leg in deiner eigenen DNS-Zone einen A-Eintrag für einen Namen wie k8s.example.com an, der auf die öffentliche IPv4 des Servers zeigt (die Hetzner-Konsole zeigt sie).
Füge den Namen auf dem Server mit einem Drop-in zum Zertifikat der API hinzu, /etc/rancher/k3s/config.yaml.d/60-own-name.yaml:
```
tls-san+:
  - k8s.example.com
```
Das + hängt an die schon konfigurierten Namen an, statt sie zu ersetzen.
Starte k3s neu: systemctl restart k3s. Die Kubernetes-API ist für den Neustart weg; deine Workloads laufen weiter, weil ein Neustart von k3s die Container in Ruhe lässt. k3s nimmt den neuen Namen in sein Zertifikat auf.
Ändere in deinen Kubeconfigs die Zeile server: auf https://k8s.example.com:6443.

Die Firewall öffnet Port 6443 weiter nur für die Bereiche, die du gewählt hast. Das Portal ändert sie nicht mehr; ihre Regeln bearbeitest du in der Hetzner-Konsole.

Snapshots nach dem Portal

Zeitplan und Anzahl stehen in /etc/rancher/k3s/config.yaml.d/50-pbx-backup.yaml. Bearbeite die Datei und starte k3s neu, um sie zu ändern.
Bucket und Schlüssel stehen im Secret kube-system/pbx-etcd-s3.
Einen Snapshot von Hand machst du mit k3s etcd-snapshot save --name manual. Ist der Bucket eingerichtet, lädt k3s ihn auch dorthin. k3s etcd-snapshot list listet die Snapshots, die k3s kennt.
Die Daten in deinen Volumes waren nie Teil eines Snapshots; dein eigenes Backup davon läuft weiter wie bisher.

Einen Snapshot von Hand wiederherstellen

Das setzt den Zustand des Clusters auf demselben Server auf einen Snapshot zurück, so wie die Wiederherstellung von pbx-agent. Alles, was der Cluster nach dem Snapshot gespeichert hat, ist weg; die Daten in deinen Volumes bleiben. Als root auf dem Server:

Wähle den Snapshot. k3s etcd-snapshot list, oder liste deinen Bucket. Die Namen sehen aus wie <name>-<node>-<Unix-Zeit>.zip.
Leg ihn entpackt auf den Node. k3s kann einen komprimierten Snapshot nicht von einem Pfad wiederherstellen; das habe ich mit k3s v1.36.4 gemessen. Entpack ihn auf deinem Rechner: Nimm die lokale Kopie von k3s aus /var/lib/rancher/k3s/server/db/snapshots/ auf dem Server, oder lade ihn mit einem beliebigen S3-Client aus deinem Bucket. Kopier dann die entpackte Datei zurück in dieses Verzeichnis:
Terminal-Fenster
```
scp root@<IPv4 des Servers>:/var/lib/rancher/k3s/server/db/snapshots/<name>.zip .
unzip <name>.zip
scp ./<entpackte Datei> root@<IPv4 des Servers>:/var/lib/rancher/k3s/server/db/snapshots/
```
Halte k3s an.
Terminal-Fenster
```
systemctl stop k3s
```
Setz den Zustand des Clusters auf den Snapshot zurück.
Terminal-Fenster
```
k3s server --cluster-reset \
  --cluster-reset-restore-path=/var/lib/rancher/k3s/server/db/snapshots/<entpackte Datei> \
  --etcd-s3=false
```
--etcd-s3=false ist nötig, weil die Konfiguration den Bucket aus einem Kubernetes-Secret liest, das k3s bei einer Wiederherstellung nicht benutzen will. k3s beendet sich, wenn das Zurücksetzen fertig ist, mit dem Hinweis, ohne --cluster-reset neu zu starten. Sein Exit-Status ist kein verlässliches Urteil: Prüfe stattdessen, dass /var/lib/rancher/k3s/server/db/reset-flag gerade eben geschrieben wurde; stat /var/lib/rancher/k3s/server/db/reset-flag zeigt die Zeit.

Starte k3s und warte auf die API:

systemctl start k3s
kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml get nodes

Das Server-Token in config.yaml muss das sein, das galt, als der Snapshot gemacht wurde. Auf demselben Server, ohne Token-Wechsel dazwischen, ist es das.

Wiederherstellung auf einen neuen Server

Geplant Eine Schritt-für-Schritt-Anleitung ist geplant. In Umrissen: Ein neuer k3s-Server mit derselben oder einer neueren k3s-Version führt dasselbe Zurücksetzen mit dem alten Server-Token aus (--token=<Server-Token>), bevor er zum ersten Mal als Server startet. Auf dem Node-Image braucht der Server außerdem die k3s-Konfiguration, die pbx-agent geschrieben hätte. Die Daten auf der Platte des alten Servers kommen nicht zurück.

Upgrades nach dem Portal

Das Root-Dateisystem des Node-Images ist schreibgeschützt, und k3s ist Teil davon; k3s lässt sich also nicht allein aktualisieren. Was es heute gibt:

Auf deinem Release bleiben. Es läuft weiter. Starte k3s mindestens einmal im Jahr neu: k3s erneuert beim Start seine Zertifikate, wenn sie in weniger als 120 Tagen ablaufen. k3s certificate check zeigt die Daten.
Das Image so aktualisieren, wie pbx-agent es tut. Das Image bootet über systemd-boot von der EFI-Partition des Servers und behält zwei Einträge. Ein Update schreibt die neue Image-Datei neben die laufende, bootet sie einmal (bootctl set-oneshot) und macht sie zum Standard (bootctl set-default), wenn der Node gesund ist. Dieses Update und der Weg zurück bestanden im Labor 24 von 24 Prüfungen, in einer virtuellen Maschine (2026-09-24). Geplant Eine Anleitung dafür von Hand, mit dem Ort der Image-Dateien, ist geplant.
Umziehen. Bau einen Cluster woanders auf und zieh deine Workloads um, mit dem Snapshot oder mit deinen eigenen Deployment-Dateien.

Wenn PaaSbox ohne Vorwarnung verschwindet

Alles oben gilt, mit drei Unterschieden:

Der DNS-Name der API ist sofort weg. Bis dein eigener Name funktioniert, erreichst du die API über die Adresse des Servers und sagst kubectl, welchen Namen das Zertifikat trägt: kubectl --server https://<IPv4 des Servers>:6443 --tls-server-name <der alte API-Name>.
pbx-agent versucht weiter, das Portal zu erreichen, mit bis zu fünf Minuten Pause zwischen den Versuchen, und wendet die zuletzt erhaltenen Einstellungen an, bis du ihn entfernst.
Die Kopien deiner Tokens und Schlüssel beim Portal liegen außerhalb deiner Kontrolle, darum ist sie zu ersetzen das Erste, was du tust.

Einen Cluster abkoppeln oder löschenWas ein Abkoppeln tut, und wie du pbx-agent vom Server entfernst.

Root auf dem Server bekommenEinen SSH-Schlüssel über den Cluster hinzufügen, oder das Rescue-System von Hetzner nutzen.