Mit Kubernetes auf Hetzner die Infrastrukturkosten um 75 % senken

Hetzner

• Der Wechsel zu Hetzner erfolgte in erster Linie zur Kostensenkung. Die Preise von Hetzner sind weltweit wettbewerbsfähig.
• Hetzner bietet virtuelle Maschinen und Bare-Metal-Server an und ist im Vergleich zu AWS zwar eingeschränkter, gleicht das aber über den Preis aus.
• Durch den Umzug zu Hetzner konnten die Infrastrukturkosten um mehr als 75 % gesenkt werden.

Kubernetes auf Hetzner

Selbstverwaltetes Kubernetes

• Kubernetes wurde zuvor bei DigitalOcean betrieben und wird auch auf Hetzner im Self-Managed-Modell betrieben.
• Hetzner stellt keine verwaltete Kubernetes-Control-Plane bereit, daher muss diese selbst verwaltet werden.
• Die Knoten werden mit Terraform und Puppet verwaltet und konfiguriert.

Knotenrollen

• Über eine Namenskonvention für Knoten bleiben die Rollen im Cluster einfach: control-plane, worker, database.
• Das Hinzufügen weiterer Rollen ist einfach, kann aber die Effizienz der Ressourcennutzung beeinträchtigen.

Aufbau der Knoten

• Der Cluster wird mit Terraform gebootstrapped.
• Hetzner bietet verwaltete Firewalls und Networking, die sich mit Terraform einfach konfigurieren lassen.
• Die Server werden vollständig mit Terraform verwaltet; durch Module pro Rolle lässt sich das Hinzufügen neuer Server vereinfachen.

Networking

• Für administrative Verbindungen zu den Knoten wird ein Tailscale-VPN verwendet.
• Tailscale bietet NAT-Hole-Punching, sodass auch bei geschlossenen Ports sichere Verbindungen möglich sind.
• Mit den verwalteten Firewalls von Hetzner und UFW unter Ubuntu werden Ports blockiert.
• Calico wird zur Konfiguration der Container Network Interface verwendet.

Storage

• Hetzner bietet nVME-SSDs und SSD-basierten Block Storage.
• Die Volumes von Hetzner verfügen nicht über Snapshot-Funktionen, daher müssen Datensicherungen manuell durchgeführt werden.
• Auf den Datenbankknoten wird der Local Persistence Volume Static Provisioner verwendet, um lokale Volumes vorab zu provisionieren.

Backups

• Hetzner bietet keine Volume-Backups, wohl aber Backups ganzer Server.
• Mit Velero von VMware werden Namespaces und PVCs gesichert.
• Für Postgres wird pgBackRest verwendet.

Zusätzliche Funktionen

• SealedSecrets wird für das Secret-Management verwendet.
• Node Exporter, Prometheus, Grafana und Loki werden für das Cluster-Monitoring eingesetzt.
• Mit Alertmanager ist die Benachrichtigungsintegration in Slack umgesetzt.

Gedanken zum Betrieb von Kubernetes auf Hetzner

• Der Umzug zu Hetzner dauerte etwa eine Woche, zusätzliche Tests und Feinabstimmung noch einmal vier Wochen.
• Die Preise von Hetzner sind angemessen, und es wird erwartet, dass sie im Vergleich zu anderen Anbietern niedrig bleiben.
• Es gibt Einschränkungen bei der IP-Qualität von Hetzner und beim Kundenservice.
• Hetzner bringt zwar schnell neue Funktionen heraus, kann aber wenig rentable Dienste ebenso schnell wieder einstellen.
• Die Rechenzentrumsstandorte in Mitteleuropa sind Falkenstein und Nürnberg in Deutschland sowie Helsinki in Finnland.

Zusammenfassung

• Die Umstellung verlief reibungslos, senkte die Infrastrukturkosten um mehr als 75 % und verdoppelte die Compute-Ressourcen des Clusters.
• Hetzner ist eine sehr attraktive Wahl, wenn Kostensenkung wichtig ist.
• Die Open-Source-Controller von Hetzner erleichtern das Management von Load Balancern und das dauerhafte Anhängen von Volumes.

[GN⁺]

Hacker-News-Kommentare

• Es wird darauf hingewiesen, dass Nachhaltigkeit oder „Green Hosting“ nicht erwähnt werden; zudem wird angemerkt, dass die europäischen Rechenzentren von Hetzner umweltfreundliche Energie nutzen, die US-Standorte jedoch nicht
• Es wird von Erfahrungen mit dem Betrieb eines Kubernetes-Clusters bei Hetzner berichtet; dabei wird erklärt, dass die Kosten im Vergleich zu AWS auf etwa 20 % sinken können, es dafür aber viele Trade-offs gibt
  • Es musste das Update des Kubernetes-Clusters selbst verwaltet werden, es traten verschiedene Bugs bei Ceph und Kubernetes auf, und es wurde betont, dass viel Arbeit und Monitoring erforderlich waren
  • Bei der Nutzung großer Cloud-Anbieter wie AWS verringert sich die operative Last dank Managed Services
  • Es wird erklärt, dass Hetzner zwar günstig ist, der zusätzliche Zeitaufwand für DevOps die Einsparungen aber wieder aufzehren kann
• Es wird eine frühere Erfahrung aus dem Webhosting geteilt, bei der Hetzner-IPs blockiert wurden; dabei werden Probleme erwähnt, die mit günstigen VM-Anbietern verbunden sind
• Es werden Ideen zur Kostensenkung im Zusammenhang mit Kubernetes geteilt, darunter der Vorschlag, einen Cluster mit einer Mischung aus On-Premises-Nodes und Nodes von Cloud-Anbietern aufzusetzen
  • Es wird vermutet, dass Egress-Kosten der wichtigste Faktor sein dürften
• Es wird angemerkt, dass Erläuterungen zum Cluster und zu den Workloads fehlen, und dass man gern die absolute Höhe der eingesparten Kosten kennen würde
• Es wird ein GitHub-Projekt empfohlen, um Kubernetes bei Hetzner einzurichten und zu verwalten
• Es wird vor Vorsicht gewarnt, nachdem aufgrund von Problemen im Support-System von Hetzner ein Gameserver ausgefallen war
• Es wird von der Erfahrung berichtet, einen schlanken Operator implementiert zu haben, um den Load Balancer von Hetzner in Kubernetes zu integrieren; dabei wird ein entsprechendes Projekt vorgestellt
• Es wird berichtet, dass durch den Wechsel von Heroku zu DigitalOcean 75 % Kosten eingespart wurden; zudem wird vermutet, dass ein Wechsel zu Hetzner sogar 93 % Einsparung ermöglicht hätte
• Ein Missverständnis über den Managed Cluster von DigitalOcean wird richtiggestellt; es wird erklärt, dass keine zusätzlichen Node-Kosten anfallen, und die Attraktivität von DigitalOcean wird hervorgehoben