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.
1 Kommentare
Meinungen auf Hacker News
Wir bieten Kunden seit einigen Jahren Kubernetes-Cluster auf Dedicated Servern von Hetzner an, und die Performance ist eindeutig hervorragend; die üblichen Request-Zeiten sinken etwa auf die Hälfte.
Die Hardware ist günstig genug, dass man pro Kunde auch dedizierte DevOps-Engineering-Zeit einplanen kann, aber es gibt ein paar Voraussetzungen. Ein Staging-Cluster zum Testen von Updates ist praktisch Pflicht, und niemand möchte Produktions-Updates sonntags auf gut Glück durchdrücken. Replikation auf Anwendungsebene ist am wichtigsten, danach kommt Replikation auf Blockebene; wir nutzen OpenEBS/Mayastor. Nachdem wir mehrere Postgres-Operatoren ausprobiert haben, halten wir derzeit StackGres für die beste Wahl.
Ansible-Playbooks sind ein Asset: Wenn man sie für einen bestimmten Dienst sauber aufbereitet und kommentiert, lässt sich derselbe Dienst später leichter an anderer Stelle erneut deployen. Wenn möglich, empfehle ich ein dediziertes 10G-Netzwerk für die Serververbindungen. 1G reicht nicht aus, wenn Produktionstraffic, Image-Pulls und Service-zu-Service-Traffic zusammenkommen, und die Latenz ist zehnmal besser als bei der Kommunikation innerhalb einer Availability Zone bei AWS.
Wenn Netzwerkredundanz nötig ist, kann man auf dem 1G-Port einen internen 1G-vSwitch (VLAN) anlegen, jedem Server eine Loopback-IP geben und die Routen per BGP verteilen (bird). Ein MinIO-Cluster ist nicht besonders schwierig, wenn man ihn über den Operator nach Lehrbuch betreibt, und liefert lokalen Objektspeicher mit hoher Bandbreite und niedriger Latenz. Für die Anfangsinvestition braucht man etwa 2 bis 4 Monate ungestörte Zeit erfahrener Engineers, und unterstützende, lästige Aufgaben wie HTTP-Load-Balancing kann man weiterhin an Cloud-Anbieter wie CloudFlare auslagern.
In der öffentlichen Dokumentation gibt es zwar eine 10G-Uplink-Option, die ist aber für das externe Netzwerk gedacht, und das 20-TB-Limit wirkt ziemlich eng. Bei internem Cluster-I/O könnten 20 TB leicht zum Problem werden.
Ich arbeite dort, und wir haben eine Plattform gebaut, die innerhalb weniger Minuten produktionsreife Cluster bereitstellt.
Als Beratungsfirma möchte man diese Arbeit vermutlich verkaufen, aber aus Kundensicht wirkt das überhaupt nicht lohnend, sofern nicht AWS-Kosten von etwa 10.000 Dollar pro Monat zu erwarten sind. Das erinnert an xkcd: https://xkcd.com/1319/
Ich habe Kubernetes-Cluster auf Hetzner-Dedicated-Servern betrieben und auch mit vollständig oder weitgehend gemanagten Diensten wie Aurora, S3 und ECS Fargate gearbeitet.
Meiner Erfahrung nach kann die Cloud-Rechnung bei Hetzner im Vergleich zu einem äquivalenten AWS-Setup auf etwa 20 % sinken, aber dieser Kostenvorteil bringt große Kompromisse mit sich.
Bei Hetzner Kubernetes habe ich einen Ceph-Cluster auf Basis von NVMe-Storage, einen MariaDB-Operator, Cilium fürs Networking und ArgoCD für Helm-Chart-Deployments verwaltet. Auch Kubernetes-Cluster-Updates mussten wir selbst übernehmen, und einmal hatten wir sogar einen Ausfall des gesamten Clusters. Wir sind auf mehrere Bugs in Kubernetes und Ceph gestoßen; viele davon waren in GitHub-Issues und im Ceph-Tracker dokumentiert. Die Liste der Dinge, die man verwalten und überwachen muss, ist endlos, und je nach Anzahl der Workloads und Komplexität der Umgebung kann die Pflege eines solchen Setups ein Vollzeitjob für ein DevOps-Team werden.
Umgekehrt ermöglicht AWS oder ein anderer großer Cloud-Anbieter ein Setup, bei dem man deutlich weniger selbst anfassen muss. Mit gemanagten Diensten sinkt der Wartungsaufwand erheblich und damit auch die operative Last fürs Team. Am Ende reduziert AWS den DevOps-Aufwand stark, während Hetzner die Cloud-Rechnung stark senkt. Welche Seite kosteneffizienter ist, erfordert eine Analyse der Total Cost of Ownership (TCO); selbst wenn Hetzner anfangs günstig wirkt, kann zusätzliche DevOps-Zeit die Einsparungen aufzehren.
Wenn man zum Beispiel eine Konfiguration mit 2 vCPUs und 4 GB mit einer ähnlichen AWS-Konfiguration vergleicht, ist AWS deutlich teurer; ich würde gern eine Kostenanalyse sehen. Als Tool zur Reduzierung des Betriebsaufwands gibt es auch https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner.
Die Root Cause herauszufinden war nicht einfach, und online gab es viele magisch wirkende Befehle zur Wiederherstellung, aber ich habe einfach alles gelöscht und den Cluster neu erstellt. Seitdem mache ich das alle paar Wochen. Ein echter Kubernetes-Operator hätte wohl automatische Zertifikats-Upgrades und viele andere Tools, aber als Unternehmen müsste man für so einen Operator wohl bezahlen.
Ich weiß, dass es eingesetzt wird, aber im Vergleich zu ausgereiften Systemen wie Lustre oder GPFS ist es eine enorme Zeitverschwendung. Besser ist es, mehrere kleinere Dateisysteme per NFS zu exportieren und Replikation auf Blockebene sicherzustellen. Ein Dateisystem mit einem einzigen Adressraum ist praktisch, aber oft ist es den Verwaltungsaufwand nicht wert, es in großem Maßstab zuverlässig zu machen. Wie beim Sharding von Datenbanken sollte man auch Dateisysteme sharden, und in Kubernetes lässt sich leicht Mapping-Logik hinzufügen, damit der richtige Storage an das richtige Image gehängt wird.
Damit kann man die DevOps-Last deutlich reduzieren und zugleich Performance und Flexibilität von Bare Metal bekommen. Es ist ein guter Hybrid zwischen teuren vollständig gemanagten Diensten und komplettem Eigenbau. Wegen der Kosten ist es für Startups vielleicht keine gute Wahl, aber bei Clustern ab 72 GB RAM oder 36 CPUs, also ungefähr 9 mittelgroßen Nodes, sollte man etwas wie OpenShift unbedingt in Betracht ziehen.
Das Problem, dass Hetzner-Volumes für Produktionsdatenbanken zu langsam sind, lässt sich überraschend leicht lösen. Man verwendet einfach sehr günstige Hetzner-Bare-Metal-Maschinen als Nodes.
Maschinen mit NVMe-Speicher haben eine hervorragende Datenbank-Performance und oft auch reichlich RAM. Es kann sogar besser sein, statt die Datenbank in Kubernetes laufen zu lassen, mindestens zwei solide Bare-Metal-Maschinen für eine Master-Replica-Konfiguration zu betreiben. Wenn die Einrichtung lästig ist, kann man moderne Pakete wie Pigsty nutzen: https://pigsty.cc/
Man kann Datenbank-Pods an bestimmte Nodes pinnen und den LocalPathProvisioner verwenden oder verteilte Lösungen wie JuiceFS oder OpenEBS einsetzen.
Ein für Kunden geschriebener Leitfaden ist hier: https://syself.com/docs/hetzner/apalla/how-to-guides/storage/local-storage-in-baremetal
Ich nutze Hetzner seit über 10 Jahren zufrieden; früher mit dedizierten Servern in deutschen Rechenzentren, dann bin ich auf Cloud-US-VMs umgestiegen, um die Latenz in den USA zu senken.
Es ist etwas enttäuschend, dass der zuvor großzügige kostenlose Traffic von 20 TB kürzlich auf 3 TB reduziert wurde und jedes zusätzliche TB €1,19 kostet. Trotzdem scheint Hetzner weiterhin ein deutlich besseres Preis-Leistungs-Verhältnis zu bieten als andere US-Cloud-Anbieter, die ich evaluiert habe.
Kubernetes würde ich nicht unbedingt wählen, aber ich habe unsere bestehenden SSH/Docker-Compose-Deployments erfolgreich auf GitHub Actions und kamal-deploy.org umgestellt. Die Einrichtung ist einfach, und die UX-Tools zum Monitoring remote deployter Apps sind gut: https://servicestack.net/posts/kamal-deployments
Die deutschen Rechenzentren bieten weiterhin 20 TB Bandbreite: https://www.hetzner.com/cloud/
In den USA ist es zum gleichen Preis jedoch mehr als eine Größenordnung weniger.
Früher habe ich meine Autoreparaturen selbst gemacht, um Geld zu sparen und weil es Spaß machte. Es war aber komplizierter als gedacht, und mit der Zeit ging hier und da etwas kaputt oder brach.
Ich habe viel Zeit damit verbracht, Dinge „noch einmal zu reparieren“, und über die Jahre vermutlich Tausende Dollar für Werkzeug ausgegeben. Dazu kamen Kosten für den Ersatz billiger Werkzeuge, die kaputtgingen oder schnell rosteten, und das Auto stand oft auf Unterstellböcken. Trotzdem habe ich viele wertvolle Lektionen gelernt; die wichtigste war, dass es manche Dinge nicht wert sind, sie selbst zu machen. Wenn der Lebensunterhalt davon abhängt, sollte man es einem Mechaniker überlassen oder das Auto leasen.
Selbst einfache Dinge wie ein Ölwechsel lohnen sich kaum selbst zu machen. Man muss Werkzeug wie Ölauffangwanne, Filterschlüssel, Trichter und Rollbrett kaufen, Zeit freihalten, dreckige Arbeitskleidung suchen, in den Laden fahren, neues Öl und einen Filter kaufen, nach Hause kommen und den Wechsel durchführen, und dann am selben oder an einem anderen Tag zu einer Stelle fahren, die Altöl annimmt. In der Werkstatt zahlt man dagegen etwa 15 Dollar mehr als für Öl und Filter und ist in 20 Minuten fertig.
Kubernetes ist ein ganzes Auto, und zwar ein kompliziertes. Wenn man es nicht zum Spaß macht, lohnt sich die eigene Wartung wirklich nicht.
Das ist eine ziemlich gute Rendite und eine Fähigkeit, die sich zu lernen lohnt. Dass ein Nachbar eine Hebebühne hat, hat definitiv geholfen.
Entscheidend ist, die richtige Balance zwischen selbst machen und auslagern zu finden; das ist nicht so einfach oder sauber, wie es hier klingt.
Aus Sicht eines Consultants, der häufig mit Kubernetes zu tun hat, ist es sinnvoll, anfangs Hilfe und einen Kanal für laufende Unterstützung zu haben, aber intern sollte auch jemand mit genügend Interesse mitlernen.
Consultants und Experten können am Anfang helfen, schlechte Entscheidungen zu vermeiden, und einem Monate ersparen, in denen man mit dem Kopf gegen die Wand rennt. Wenn man sich zugleich auf das Kerngeschäft konzentrieren muss, ist es nicht leicht, sich in vertretbarer Zeit die üblichen dunklen Ecken und Fallen einer Technologie oder eines Ökosystems anzueignen. Man sollte sich helfen lassen, aber auch lernen, wie man fischt und Feuer macht.
Ein interessanter Artikel, aber es fehlt gefühlt eine Beschreibung des Clusters und der Workloads, die darauf laufen.
Ich wüsste gern, wie viele Nodes es sind, wie viel Traffic sie verarbeiten und welche Anforderungen an Uptime und Latenz gelten. Außerdem zählt auch die absolute Kostensenkung: 75 % Ersparnis bei 100.000 Dollar pro Monat sind etwas völlig anderes als 75 % Ersparnis bei 100 Dollar pro Monat.
Tatsächlich sehe ich 100.000 Dollar pro Monat als Wendepunkt. Das sind 1,2 Millionen Dollar pro Jahr.
Um ein ausgefeiltes Bare-Metal-Deployment ordentlich zu unterstützen, kostet es etwa 400.000 Dollar pro Jahr an Engineering-Gehältern, dazu grob 100.000 Dollar pro Jahr für Rechenzentrumsverträge, Hardware-Abschreibung und Bandbreite. Solche Leute liefern meist auch in anderen Bereichen des Unternehmens viel Wert, während sie diese Arbeit machen, sodass die tatsächlichen Kosten niedriger sein können. Dann spart man 700.000 Dollar pro Jahr, was großartig ist; und je weiter die entsprechenden Cloud-Ausgaben darüber liegen, desto größer wird der Vorteil.
Als ich vor über 10 Jahren im Webhosting arbeitete, haben wir Hetzner-IPs wegen schlechten Verhaltens ständig geblackholed
Bei anderen günstigen VM-Anbietern war es genauso, und es hatte nichts mit Geo-Datenbanken zu tun, sondern ausschließlich mit dem Verhalten. Billig hat seinen Grund
Mir gefielen die Produktfunktionen, aber die Reputation der IPs im kostenlosen Tarif war furchtbar, und besonders bei Hotmail oder Yahoo wurden Mails kaum angenommen. Kostenlose Hosting-Dienste werden von Spammern und Betrügern überrannt, und günstige Dienste sind ähnlich, nur weniger stark. Je teurer der Preis, desto seltener wird es für Betrug und Spam genutzt
Auch AWS, Google, DigitalOcean, Linode, Contabo usw. hosten viele Brute-Force-Angriffe auf Logins und Scans nach gängigen Schwachstellen
Ich arbeite bei einer Beratungsfirma, die Unternehmen beim Aufbau und der Absicherung ihrer Infrastruktur hilft, und wir haben viele Kunden, die Kubernetes bei günstigen Anbietern wie Hetzner, bei regionalen Mittelklasse-Anbietern und bei den drei großen Clouds AWS/GCP/Azure betreiben
Es gibt auch Behörden sowie Finanz- und Gesundheitsunternehmen, die nicht in einer Public Cloud arbeiten können oder wollen; diese hosten wir normalerweise On-Premises
Wenn es bei Hetzner einmal im Monat ein Problem oder einen Ausfall gibt, dann bei Mittelklasse-Anbietern etwa alle 2–3 Monate und bei Anbietern wie AWS etwa alle 5–6 Monate. Allerdings bewegen sich auch die Preise ungefähr entsprechend dieser Beobachtung, daher muss man von Fall zu Fall sorgfältig abwägen, ob zusätzliche Geräte, Backups und Ausfallszenarien das bessere Geschäft sind
Ein großer Vorteil einfacher Hosting-Dienste ist, dass die Preisvorhersagbarkeit deutlich höher ist. Man bezahlt die Hardware und skaliert so weit, wie man sie braucht. Wenn man sich an Zusatzdienste von Anbietern wie AWS bindet, kann man unerwartet hohe Rechnungen bekommen, und der Ausstieg wird deutlich schwieriger. Als kleines Unternehmen sollte man sich am Anfang nicht von einfachen Lösungen oder „kostenlosen Credits“ zu kurzsichtigen Entscheidungen verleiten lassen, die die langfristige Überlebensfähigkeit gefährden
Es gibt hier keine richtige Antwort, nur Kompromisse
Ich habe es selbst nicht ausprobiert, aber https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner sieht nach einer hervorragenden Möglichkeit aus, Kubernetes auf Hetzner einzurichten und zu verwalten
Derzeit nutze ich den kostenlosen Oracle-Tarif, überlege aber ständig, dorthin zu wechseln, um von Oracle wegzukommen
Es funktioniert ziemlich gut. Ich habe auch einen Zeitplan, nach dem die Maschinen jeden Sonntag für automatische Sicherheitsupdates unter SuSE MicroOS neu gestartet werden. Ich habe auch schon Maschinen skaliert, um mit wachsender Workload mitzuhalten. Man muss jede Änderung, die Terraform durchführen will, unbedingt prüfen, aber wenn man das tut, ist es ziemlich sicher
Der einzige Nachteil ist, dass alle Nodes eine öffentliche IP brauchen, selbst wenn sie hinter einer Firewall stehen; daran wird aber gearbeitet
Der Cluster lief über Nacht und funktioniert ziemlich gut. Ein kleines Problem war, dass automatische Updates auf ARM-Nodes nicht ausgeführt wurden; zu dem Zeitpunkt lief nur ein einzelner Node, und wegen des Control-Plane-Taints konnte der Update-Pod nicht gestartet werden und blieb hängen
https://github.com/syself/cluster-api-provider-hetzner
Läuft sehr stabil
Ich frage mich, ob es konkrete Unannehmlichkeiten gibt, die dich zum Wechsel bewegen
Ich halte die Aussage nicht für richtig, dass DigitalOcean wie andere Anbieter zwar eine kostenlose verwaltete Control Plane anbietet, auf verwaltete Cluster-Nodes aber normalerweise 100 % Aufschlag erhebt
Bei DigitalOcean kosten Worker-Nodes genauso viel wie normale Droplets, ohne Zusatzkosten. Deshalb ist das Angebot von DigitalOcean ziemlich attraktiv. Es gibt eine kostenlose Control Plane, um die man sich nicht kümmern muss, kostenlose Upgrades und zusätzliche Integrationen wie Load Balancer und Storage. Mir fällt kaum ein Grund ein, warum man das nicht dem Selbstmanagement vorziehen sollte
Eine Shared-CPU-Instanz mit 8 GB RAM kostet bei Hetzner etwa 10 Dollar, das vergleichbare Angebot bei DigitalOcean 48 Dollar
Wenn man bei Hetzner eine Managed Experience möchte, kann man sich https://syself.com ansehen. Ich bin Mitarbeiter dieses Unternehmens