Private Cluster
Ein privater Cluster ist einer, in dem kein Worker-Node eine nutzbare öffentliche Adresse besitzt. Cloud-Worker bekommen keine öffentliche IP; dedizierte Server hören auf, ihre zu benutzen. Jedes ausgehende Paket verlässt den Cluster über ein NAT-Gateway pro Cluster, das in deinem Hetzner-Projekt lebt, von der Plattform erstellt und wieder abgebaut wird, eine verpflichtende Host-Firewall trägt, Metriken und Logs exportiert und eine Allow-List durchsetzen kann, wohin dein Cluster sprechen darf.
Eingehender Traffic bleibt unverändert: Deine Load Balancer funktionieren weiter, sie zielen lediglich auf private Node-Adressen. Die Control Plane erreicht die Nodes so oder so über einen ausgehenden Tunnel – private Nodes verlieren also nichts.
- Eine stabile Egress-Identität. Partner, Payment-Provider und Datenbanken außerhalb des Clusters sehen eine Adresse, die du bei ihnen auf die Allow-List setzen kannst. Node-Rolls und Autoscaling ändern sie nicht.
- Eine kleinere Angriffsfläche. Kein öffentlicher Port auf irgendeinem Worker; SSH nur aus Netzen, die du auflistest.
- Kontrolle darüber, was hinausgeht. Eine Allow-List von Zielen, nach Netz oder nach Name, mit einem Audit-Modus, der protokolliert, was blockiert würde, bevor du irgendetwas durchsetzt.
Was du einstellst
Abschnitt betitelt „Was du einstellst“| Einstellung | Was sie bewirkt |
|---|---|
| Egress: öffentlich oder privat | clusterweit; ein privater Cluster hat keinen Pool mit öffentlichen Adressen |
| Servertyp des Gateways | der Hetzner-Typ, auf dem das Gateway läuft; validiert gegen das, was dein Rechenzentrum verkauft |
| SSH erlaubt aus | Netze, die Port 22 auf dem Gateway und auf deinen Nodes erreichen dürfen; leer heißt keine |
| Allow-List: Netze, Namen, Modus | Ziele, die dein Cluster erreichen darf; audit protokolliert und zählt ohne zu blockieren, enforce blockiert |
| Logging | verworfene Pakete und Denials werden standardmäßig protokolliert; Flow-Logs pro Verbindung sind optional; beides geht an einen Collector, den du in deinem Netzwerk benennst |
| Metriken erlaubt aus | Netze, die die Metriken des Gateways von außen abfragen dürfen, hinter TLS und Basic Auth |
Ziele, die der Cluster zum Funktionieren braucht – die Endpunkte der Plattform, die Registries, aus denen die System-Komponenten ziehen, NTP und die Resolver – sind immer erlaubt; deine Liste kann nur ergänzen.
Was das Gateway für die Nodes tut
Abschnitt betitelt „Was das Gateway für die Nodes tut“Das Gateway ist der DNS-Resolver der Nodes. Was es nach Name erlaubt, ist konstruktionsbedingt genau das, was es den Nodes gesagt hat – ein Name, der hinter einem CDN auf wechselnde Adressen auflöst, funktioniert also weiter. Ein Worker, der bootet, erreicht als Erstes das Gateway, noch vor allem anderen.
Der Lebenszyklus des Gateways
Abschnitt betitelt „Der Lebenszyklus des Gateways“- Image. Standardmäßig Debian 13, Ubuntu 24.04 ist verfügbar. Das Gateway aktualisiert beim ersten Boot einmal alle Pakete, installiert täglich Sicherheitsupdates und startet nur zu Beginn deines Wartungsfensters neu – mit Jitter, damit Cluster, die sich ein Fenster teilen, nicht in derselben Minute neu starten. Ein Neustart kostet den Cluster etwa eine halbe Minute ausgehende Konnektivität; Nodes gehen dabei nicht auf NotReady.
- Ersetzen statt Patchen. Wird ein neueres Gateway-Image gepinnt, wird ein Ersatz gebaut, und die Route zieht innerhalb deines Wartungsfensters um; der Aussetzer ist der Routenwechsel, etwa fünfzehn Sekunden. Du kannst das Ersetzen von der Cluster-Seite aus früher auslösen.
- Selbstheilung. Die Plattform prüft das Gateway alle 30 Sekunden durch deinen Cluster hindurch. Ein Gateway, das nicht mehr antwortet, wird in der Konsole markiert; nach zwei Minuten wird es eingeschaltet, falls es aus ist, oder hart zurückgesetzt, falls es hängt, und nach sechs Minuten wird es ersetzt – gemessen: 22 Sekunden bis zur Markierung, unter drei Minuten bis zum Reset, etwa vier Minuten bis zur Heilung. Das alles bleibt innerhalb des Zehn-Minuten-Fensters, nach dem Kubernetes anfangen würde, die Worker selbst zu ersetzen.
- Kosten. Das Gateway ist ein kleiner Hetzner-Server in deinem Projekt, auf deiner Hetzner-Rechnung, plus eine öffentliche IPv4-Adresse.
Metriken, Logs, Alarme
Abschnitt betitelt „Metriken, Logs, Alarme“Das Gateway exportiert seine Metriken auf seiner privaten Adresse; der Monitoring-Stack eines Produktions-Clusters scrapt sie und alarmiert bei einem Gateway, das down ist, einer Firewall, die nicht durchsetzt, einer Verbindungstabelle über 80 %, Denials und einer veralteten Allow-List. Jedes Prometheus, das du im Cluster betreibst, kann denselben Endpunkt scrapen. Log-Zeilen erreichen die Plattform nie – sie gehen an den Collector, den du innerhalb deines Netzwerks benennst. Siehe Monitoring & Alarme.
Dedizierte Server in einem privaten Cluster
Abschnitt betitelt „Dedizierte Server in einem privaten Cluster“Dedizierte (Robot-)Server treten einem privaten Cluster über den vSwitch bei und nutzen das Gateway des Clusters als Route und Resolver; ihr öffentliches Interface bleibt konfiguriert, trägt aber keine Default-Route. Dedizierte Node-Pools richten wir im Onboarding auf Anfrage ein.
Eigenes Netzwerk mitbringen
Abschnitt betitelt „Eigenes Netzwerk mitbringen“Wenn du bereits ein Hetzner-Netzwerk mit eigenem NAT betreibst, häng die Worker des Clusters stattdessen dort an: Die Plattform erstellt oder löscht dieses Netzwerk nie, sie ergänzt nur das Subnetz der Worker. Ein Cluster in deinem Netzwerk bekommt kein Gateway von der Plattform; dein NAT ist der Egress.
Einen bestehenden Cluster umstellen
Abschnitt betitelt „Einen bestehenden Cluster umstellen“Einen Cluster zwischen öffentlichem und privatem Egress umzustellen ersetzt jeden Worker-Node – On-Demand-Nodes werden neu bestellt, adoptierte Server an Ort und Stelle neu aufgebaut, dedizierte Server erneut onboardet. Die Konsole verlangt eine ausdrückliche Bestätigung und benennt den Wirkungsradius, bevor sie startet.