Vom Token zum Cluster

Du fügst einen Hetzner-Cloud-API-Token ein; rund 10–15 Minuten später führst du kubectl get nodes gegen deinen eigenen Cluster aus. Diese Seite geht Schritt für Schritt durch, was dazwischen passiert, was in deinem Hetzner-Projekt auftaucht (und was nie), und welche drei optionalen Topologien du für deine Worker-Nodes wählen kannst.

Bevor du startest

Du brauchst drei Dinge:

• Ein Hetzner-Cloud-Projekt. Wir empfehlen ein Projekt nur für PaaSbox: Der Token, den du uns gibst, gilt für genau ein Projekt – ein dediziertes Projekt zieht also eine saubere Grenze zwischen dem, was die Plattform verwaltet, und allem anderen, was du bei Hetzner betreibst.
• Einen API-Token für dieses Projekt mit Lese- und Schreibrechten (Hetzner Console → dein Projekt → Security → API tokens). Read/write ist nötig, weil On-Demand-Node-Pools legitim Server erstellen und löschen – die ehrlichen Details stehen im FAQ, inklusive der Frage, warum adoptierte Server niemals gelöscht werden, egal was der Token erlauben würde.
• Eine hinterlegte Zahlungsmethode – die Karte ist die Voraussetzung fürs Erstellen von Clustern; abgebucht wird erst, wenn du einen Cluster startest. Siehe So funktioniert PaaSbox.

Token-Verwahrung. Der Token gelangt einmal in die Plattform, wird verschlüsselt gespeichert und nie wieder angezeigt – weder in der Konsole noch in der API. Er wird ausschließlich benutzt, um Cluster-Ressourcen in deinem Projekt zu provisionieren und zu verwalten: dort Server, Netzwerke, Load Balancer und Volumes zu erstellen und zu konfigurieren. Er gewährt keinen Zugriff auf irgendetwas außerhalb dieses Projekts, und du kannst ihn jederzeit im Portal rotieren – oder bei Hetzner widerrufen.

Die Provisionierungs-Timeline

1. Dein Token wird validiert

   PaaSbox prüft, ob der Token dein Projekt auflisten kann, und speichert ihn dann verschlüsselt. Wenn du vorhandene Server mitbringen willst, listet das Portal jetzt die Server deines Projekts auf, damit du auswählen kannst, welche du adoptierst.

2. Das Betriebssystem-Image für die Nodes landet in deinem Projekt

   Hetzner-Images sind projektgebunden – es gibt kein projektübergreifendes Image-Sharing –, also veröffentlichen wir unser Node-OS-Image als einen Snapshot von etwa 0,25 GB in dein Projekt. Der Snapshot-Speicher kostet dich einen Bruchteil eines Cents pro Monat. Das passiert einmal pro Projekt; spätere Image-Versionen kommen auf demselben Weg (siehe laufender Betrieb).

3. Deine Control Plane startet – auf unserer Infrastruktur

   Die Control Plane des Clusters (API-Server, etcd, Scheduler, Controller) startet als managed Pods auf der Plattform, die wir betreiben. Sie läuft nie in deinem Projekt und taucht nie auf deiner Hetzner-Rechnung auf – sie ist durch die Pauschale abgedeckt. Siehe Was du mitbringst & was wir betreiben.

4. Worker-Server erscheinen in deinem Projekt

   Ein privates Netzwerk wird für den Cluster angelegt, dann kommen die Node-Pools hoch:

   • Managed-Pools (on-demand) – neue Server werden aus dem Snapshot erstellt, zu aktuellen Hetzner-Preisen.
   • Pooled-Pools (adoptiert) – deine vorhandenen Server werden an Ort und Stelle neu installiert und treten dem Cluster bei, wie sie sind. Keine Neubestellung, keine Löschung – genau so überlebt ihr Bestandspreis (grandfathered).

5. Nodes treten dem Cluster bei

   Jeder Worker bootet aus dem Image, konfiguriert sich selbst und öffnet eine ausgehende Verbindung zu deiner Control Plane. Dein Projekt braucht keinen eingehenden Zugriff von uns – es gibt nichts zu öffnen oder zu exponieren.

6. Ready – hol dir deine kubeconfig

   Sobald der Cluster Ready meldet, lade eine kurzlebige Admin-kubeconfig aus der Konsole oder über die API herunter (Zugriff auf deinen Cluster) – oder binde deinen eigenen Identity Provider an. Ab hier heißt es kubectl, Helm oder Flux – dein Cluster, deine Tools.

Das Adoptieren vorhandener Server fügt der Uhr einen Schritt hinzu: Die Adoption installiert das OS neu, was die Festplatte leert – jeder adoptierte Server durchläuft also einen Rebuild, bevor er beitritt. Migriere Workloads vorher weg; das Portal lässt dich das explizit bestätigen.

Was du in deinem Hetzner-Projekt siehst

Nach der Provisionierung enthält dein Projekt genau die Ressourcen, aus denen dein Cluster besteht:

Ressource	Anzahl	Was es ist
OS-Snapshot	1–2	Das Betriebssystem-Image der Nodes (~0,25 GB pro Stück). Wir behalten die aktuelle und die vorherige Version.
Privates Netzwerk	1	Node-zu-Node- und Node-zu-Control-Plane-Traffic des Clusters.
Worker-Server	N	Deine Node-Pools – aus dem Snapshot erstellt oder deine adoptierten Server. Von Hetzner direkt an dich berechnet.
Load Balancer	0+	Werden on demand erstellt, wenn du einen Service vom Typ LoadBalancer anlegst.
Volumes	0+	Werden on demand erstellt, wenn deine Workloads persistenten Speicher anfordern (PVCs). Resize online, in place.

Diese Ressourcen sind verwaltet – bearbeite sie nicht von Hand

Wenn du den Snapshot, das private Netzwerk oder die Worker-Server in der Hetzner Console löschst oder veränderst, geht dein Cluster kaputt – die Plattform gleicht kontinuierlich gegen sie ab. Um etwas zu entfernen, handle stattdessen in der PaaSbox-Konsole: Skaliere einen Pool herunter oder lösche den Cluster (was entfernt, was wir erstellt haben – aber niemals deine adoptierten Server).

Die drei optionalen Topologien

Ein Standard-Cluster läuft auf Cloud-Servern mit öffentlichen IPs. Drei optionale Topologien verändern, wie deine Worker-Flotte aussieht – kombinierbar pro Node-Pool.

Private Worker-Nodes hinter einem NAT-Gateway

Wähl das, wenn du eine kleinere Angriffsfläche willst – Worker ganz ohne öffentliche IPv4 – und Hetzners IPv4-Gebühr pro Adresse nicht länger für jeden Node zahlen möchtest.

Was sich ändert: Deine Worker bekommen keine öffentliche IP; sie leben nur im privaten Netzwerk des Clusters. Ein kleines NAT-Gateway – von der Plattform deployt und verwaltet – trägt ihren ausgehenden Traffic (Image-Pulls, OS-Updates, den Egress deiner Workloads). Load Balancer exponieren deine Services weiterhin genau wie zuvor ins Internet.

Die Provisionierung funktioniert unverändert: Ein neuer Node erhält seine First-Boot-Konfiguration über den internen Metadaten-Kanal der Cloud, der keine öffentliche IP braucht – private Nodes werden also genauso erstellt, treten genauso bei und aktualisieren sich genauso wie öffentliche.

Early Access. Privates Networking rollt Cluster für Cluster aus – sag uns beim Erstellen deines Clusters Bescheid, und wir schalten es für dich frei.

Deine vorhandenen (preisgeschützten) Server als Node-Pool

Wähl das, wenn du Server hast, die vor Hetzners Preiserhöhung bestellt wurden, und diesen Preis behalten willst, während sie als Kubernetes-Nodes laufen. Das ist der Grund, warum es PaaSbox gibt.

Was sich ändert: Nichts wird bestellt und nichts gelöscht. Deine Server werden adoptiert: an Ort und Stelle neu installiert, dem Cluster beigetreten und von da an unter einer strikten Regel betrieben – nur das Löschen eines Servers oder das Ändern seines Plans setzt den Preis je neu, und PaaSbox tut beides nie. Jede Lifecycle-Operation (Upgrades, Node-Reparatur, Image-Wechsel, Ruhezustand und Aufwecken) läuft als Neuinstallation desselben Servers an Ort und Stelle, und Hetzners eigener Löschschutz ist als zweite Absicherung aktiviert. Auf Node-Pools, deren OS es unterstützt, werden Updates in place auf dem laufenden Server eingespielt – keine Neuinstallation, kein Ersatz, und der Preis überlebt so oder so.

Der Ausstieg ist genauso sicher: Entferne einen Pool oder lösche den Cluster, und deine adoptierten Server werden dir intakt zurückgegeben – immer noch deine, immer noch zu deinem Preis.

Dedicated-Server (Bare Metal) hinter einem vSwitch

Wähl das, wenn du ernsthafte, konstante Kapazität pro Euro willst: Hetzners Dedicated-Reihen bieten weit mehr Kerne und Speicher pro Monats-Euro als Cloud-Server, und preisgeschützte Dedicated-Maschinen behalten ihren Preis auch hier.

Was sich ändert: Deine physischen Server treten dem Cluster über ein privates VLAN (Hetzner vSwitch) bei, das in das Cloud-Netzwerk des Clusters gebrückt wird – Dedicated- und Cloud-Nodes sprechen also privat miteinander, als ein Cluster. Gemischte Pools sind eine unterstützte Konstellation, mit Cloud-Nodes für Lastspitzen und Metal für die Grundlast. Da Bare Metal nicht von einem Cloud-Snapshot booten kann, läuft das Imaging stattdessen über Hetzners Rescue-System. Dieselbe Niemals-löschen-Disziplin gilt auch hier: Dedicated-Server werden von der Plattform nie gekündigt.

Bald verfügbar. Dedicated-Node-Pools sind noch nicht allgemein verfügbar. Wenn du Robot-Server mitbringen möchtest, registriere dein Interesse – wie bei neuen Regionen priorisieren wir nach Nachfrage.

Nach Tag eins: der laufende Betrieb

• Image-Updates kommen automatisch. Wenn wir eine neue Node-OS-Version veröffentlichen, wird der neue Snapshot auf demselben Weg in dein Projekt publiziert wie der erste. Das ist unterbrechungsfrei – ein Snapshot ist nur ruhende Daten, bis Nodes davon aktualisieren.
• Node-Updates rollen in deinem Wartungsfenster. Kubernetes- und OS-Updates laufen in dem Wartungsfenster, das du am Cluster einstellst – nie zu einem Zeitpunkt, den wir aussuchen. Auf unterstützten Pools wird das Update in place auf dem laufenden Server eingespielt; adoptierte Server werden andernfalls an Ort und Stelle neu installiert; nur On-Demand-Nodes werden je ersetzt.
• Snapshots werden für dich aufgeräumt. Wir behalten die aktuelle und die vorherige Image-Version in deinem Projekt und entfernen ältere – der Snapshot-Speicher bleibt so im Bereich eines Rundungsfehlers.

Häufige Fragen

Was passiert, wenn ich den Token widerrufe?

Dein Cluster läuft weiter – Nodes und Control Plane hängen nicht von Minute zu Minute am Token, und deine kubeconfig funktioniert weiter. Was stoppt, ist die Verwaltung deines Projekts: kein Skalieren, keine neuen oder reparierten Nodes, keine Load-Balancer- oder Volume-Änderungen, keine Image-Updates. Die Konsole zeigt die Verbindung als ungültig an; füge einen frischen Token ein, und die Verwaltung läuft wieder.

Welche Kosten landen in meinem Projekt, und welche bei euch?

Deine (von Hetzner berechnet): Worker-Server, Load Balancer, Volumes, öffentliche IPv4-Adressen und die ~0,25 GB Snapshot-Speicher. Unsere (durch die Pauschale abgedeckt): die Control Plane und alles andere, was wir betreiben – siehe Preise & Fair-Use.

Läuft irgendetwas von mir auf eurer Infrastruktur?

Nur die Control Plane deines Clusters. Deine Workloads laufen ausschließlich auf den Workern in deinem eigenen Projekt – deinen Anwendungs-Traffic und deine Daten bekommen wir nie zu sehen, und sie laufen nie über unsere Systeme.