Cluster-Lebenszyklus
Diese Seite beschreibt zwei Lebenszyklus-Verhalten bei gehosteten Clustern: wie eine vollständig ungenutzte Control Plane im Free-Modus irgendwann zurückgeholt wird, und was bei einer fehlgeschlagenen Zahlung auf einem Konto mit Abrechnung passiert.
Hosted
Die Rückholung ungenutzter Cluster betrifft nur gehostete Cluster auf einem Free-Konto. Das Verhalten bei Nichtzahlung weiter unten gilt für jedes Konto mit Abrechnung.
Rückholung ungenutzter Free-Cluster
Kostenlose gehostete Control Planes laufen auf einem geteilten Pool. Damit dieser Pool für alle gesund bleibt, die ihn aktiv nutzen, wird eine kostenlose Control Plane, die keinerlei Aktivität zeigt, irgendwann zurückgeholt. Das gilt nur für den Free-/Community-Modus. Cluster auf einem Supporter- oder Enterprise-Konto werden niemals wegen Inaktivität zurückgeholt.
Heute 0 € zu zahlen ist nicht der Free-Modus. Bis zum 1. Dezember 2026 ist alles kostenlos, also kostet derzeit kein Cluster etwas. Maßgeblich ist der Modus deines Kontos (Free, Supporter, Enterprise), nicht der Rechnungsbetrag und nicht die Größe des Clusters. Ein Cluster, der einem Supporter- oder Enterprise-Konto gehört, wird nie wegen Inaktivität zurückgeholt, egal wie groß er ist, auch nicht während des kostenlosen Zeitraums.
Nichts davon geschieht plötzlich. Die Rückholung läuft nach einem langen, klar angekündigten Zeitplan, und jede Aktivität setzt ihn sofort zurück.
Was als Aktivität zählt
Jede einzelne davon hält einen Cluster am Leben, oder nimmt einen pausierten sofort wieder auf:
- Herunterladen der kubeconfig aus dem Dashboard.
- Ändern von Cluster-Einstellungen.
- Hinzufügen oder Ändern von Workern.
- Der Heartbeat des Clusters: Ein laufender, verbundener Cluster meldet sich von selbst.
Du musst nichts anklicken, um „aktiv zu bleiben“, kein Formular und kein Support-Ticket: Jede der obigen Aktionen setzt die Uhr automatisch zurück.
Der Zeitplan
| Phase | Wann | Was passiert |
|---|---|---|
| Inaktivitäts-Warnung | nach ~14 Tagen ohne Aktivität | Wir schreiben dir eine E-Mail, dass der Cluster ungenutzt wirkt. Er läuft normal weiter. |
| Pausiert | ~7 Tage später, falls weiterhin ungenutzt | Der Cluster wird pausiert und ein 30-tägiger Entfernungs-Countdown startet. Du erhältst eine zweite E-Mail. |
| Entfernt | am Ende des 30-Tage-Countdowns, falls weiterhin ungenutzt | Die verwaltete Control Plane wird dauerhaft entfernt. Eine letzte E-Mail bestätigt dies. |
In jeder Phase stoppt eine einzige Aktivität den Vorgang und nimmt ihn, falls der Cluster pausiert war, wieder auf.
Deine Daten
Deine Kubernetes-Workloads und ihre Daten liegen auf deinen eigenen Workern, auf deinem Hetzner-Konto. Die Rückholung entfernt nach der langen Kulanzfrist oben die verwaltete Control Plane. Wenn du den Cluster nicht mehr brauchst, kannst du ihn einfach auslaufen lassen. Falls du ihn behalten möchtest, exportiere oder migriere während des Countdowns alles, was du benötigst (siehe Migration), oder führe eine einzige Aktivität aus, um den Cluster zu behalten.
Nichtzahlung
Vor dem 1. Dezember 2026 wird nichts berechnet
0 EUR bis 1. Dezember 2026
Die Nutzung ab diesem Datum wird monatlich abgerechnet. Die erste Rechnung und die erste Zahlung kommen Anfang Januar 2027 (siehe Preise). Alles in diesem Abschnitt beschreibt das Verhalten, sobald die Abrechnung startet.
Gehostete Control Planes werden gemessen und gemäß der Preisseite abgerechnet. Wenn eine Zahlung fehlschlägt, stoppt der Dienst nicht sofort:
- Kulanzfrist: Wir schreiben dir eine E-Mail zur fehlgeschlagenen Zahlung, und deine Cluster laufen weiter, während du sie klärst. Du hast ab der fehlgeschlagenen Zahlung 14 Tage bis zum nächsten Schritt.
- Gesperrt: Bleibt es ungelöst, wird das Konto gesperrt. Bestehende Cluster laufen weiter, aber das Erstellen oder Ändern von Ressourcen ist blockiert.
- Wiederhergestellt: Das Begleichen der Zahlung stellt den vollen Zugriff automatisch wieder her. Es ist nichts weiter zu tun.
- Wenn nie beglichen wird: Eine Sperre löscht nichts. Cluster bleiben gesperrt, und der einzige Weg zur Entfernung ist eine Kündigung nach §13 der AGB: 90 Tage Frist von uns, bei einem Verstoß gegen die AGB auch fristlos. Danach werden die Daten binnen 30 Tagen gelöscht. Deine Worker-Nodes liegen die ganze Zeit in deinem eigenen Hetzner-Konto und werden von Hetzner abgerechnet, nicht von uns.
Kubernetes-Versionslebenszyklus
Sie wählen die Kubernetes-Version Ihres gehosteten Clusters aus der angebotenen Liste und aktualisieren, wann es Ihnen passt: stets vorwärts, eine Minor-Version pro Schritt, ausgeführt in Ihrem Wartungsfenster. Der Versions-Picker im Dashboard zeigt vor der Auswahl, was jede Option bedeutet.
Der Ein-Klick-Upgrade-Ablauf wird noch ausgerollt. Bis er für Ihre Bereitstellung aktiv ist, fragen Sie uns, und wir führen das Upgrade für Sie aus. Siehe Verwaltete Upgrades.
Zwei Termine zählen für jede Minor-Version:
| Ereignis | Was passiert |
|---|---|
| Ein neuer Patch Ihrer Minor-Version erscheint | Wird im Dashboard angezeigt; das Upgrade planen Sie selbst. |
| Das upstream EOL-Datum Ihrer Minor-Version naht | Wir schreiben Ihnen 30, 14 und 7 Tage vorher. |
| Das EOL-Datum verstreicht | Sobald die Klausel zum erzwungenen EOL-Upgrade in den AGB steht (§14a), wird Ihr Cluster auf die nächste unterstützte Minor-Version aktualisiert (ein Schritt, nie mehr), in Ihrem Wartungsfenster. Bis dahin schreibt Ihnen die Plattform und überlässt Ihnen das Upgrade. |
Die EOL-Hinweise und die Bestätigung eines durchgeführten Upgrades sind betriebsnotwendig und lassen sich nicht stummschalten. Alles andere (Ankündigungen, Kapazitätshinweise) respektiert Ihre Benachrichtigungs- einstellungen.
Spaces (geteilte Control Plane) versionieren wir: die Flotte läuft eine Minor-Version hinter dem neuesten unterstützten Release, neue Patches rollen zwei Wochen nach Veröffentlichung aus. Vor dem Upgrade der Control Plane Ihres Space erhalten Sie eine Ankündigung, danach eine Bestätigung. Ihre Maschinen werden nie angefasst: Fällt das Kubelet eines Nodes aus dem unterstützten Versions-Skew, läuft er weiter, wird im Dashboard markiert, und wir bitten Sie, ihn bei Gelegenheit zu aktualisieren. Der Beitritt ist an derselben Linie begrenzt: eine Maschine, deren Kubelet mehr als zwei Minor-Versionen hinter der Control Plane des Space liegt, wird an der Tür abgewiesen (mit Begründung). Kubelet aktualisieren, dann erneut beitreten.
Nächste Schritte
- Einrichtung: Preise und was heute live ist.
- Migration: Workloads von einem Cluster exportieren und verschieben.
- Worker-Pools: hier liegen deine Worker und ihre Daten.
Doc-Status
| Aspekt | Detail |
|---|---|
| Zustand | Live: Rückholung live (Free-Konten); Mahnwesen live (Konten mit Abrechnung) |
| Zuletzt geprüft | 2026-07-14 |