Diese Artikel-Serie beschäftigt sich mit der Einrichtung eines hybriden Kubernetes- und KVM-Clusters mithilfe von Proxmox bei Hetzner Online.
Erster Teil | Vorheriger Teil | Nächster Teil
Als Fachinformatiker kümmere ich mich natürlich selbst um die technische Infrastruktur von Firesplash Entertainment.
Meine Anforderung besteht hierbei darin, ein möglichst hoch verfügbares und leistungsfähiges System bei geringen Kosten aufzubauen. Als Budget habe ich mir für das aktuelle Projekt ca 120€/Monat eingeräumt. Wir lösen damit ein bestehendes System ab, das derzeit zzgl weiterem nachzurüstendem Flash-Speicher ca 100€/Monat kosten würde.
Ob damit der Aufbau eines Low-Cost Kubernetes und Proxmox Hybrid-Cluster bei Hetzner Online möglich ist?
Anforderungen
Der neue Cluster soll primär folgende Systeme tragen und noch “Luft nach oben” haben:
| System | Bedarf Speicher | Bedarf RAM | Bedarf CPU | Bedarf Verfügbarkeit |
| Diverse Kubernetes Deployments U.a. Datenbank-Cluster | 100 GiB je Node | 16 GiB je Node | Mittel | Hoch |
| GitLab & Collab Server (KVM) | 250 GiB | 12 GiB | Mittel | Gering |
| Build-Server auf Windows 10 Basis (KVM) | 80 GiB | 8 GiB | Hoch (zeitweise) | Gering |
| Build-Server auf Linux-Basis (Debian, KVM) | 50 GiB | 4 GiB | Mittel | Gering |
| Mailserver* (LXC) | 100 GiB | 4GiB | Gering | Gering |
| GameNet Gluu Server (Debian, KVM) | 30 GiB | 8 GiB | Gering | Hoch |
| Billing System (LXC) | 25 GiB | 1 GiB | Gering | Mittel |
| OpnSense als LB und Gateway | 32 GiB | 1 GiB | Gering | Hoch |
Für die Verfügbarkeit bewerte ich in drei Kategorien:
Gering: Ein längerfristiger Ausfall (z.B. bei Hardwaredefekt, rechnerisch 1-2 Tage) kann toleriert werden
Mittel: Ein kurzzeitiger Ausfall (z.B. bei Reboots, Hardwaretausch, … – Rechnerisch max 1h) kann toleriert werden
Hoch: Ausfälle müssen vermieden werden, maximal 1-2 Minuten sind tolerabel.
*) Der Mailserver ist deshalb als gering verfügbar eingestuft, da es außerhalb einen zweiten gibt, der nahtlos übernehmen kann.
Auswertung der Tabelle
Da vor allem die Build-Server während sie aktiv ind relativ viel IOs produzieren und darüber hinaus viele Container und VMs laufen werden, kommen Magnetplatten hier nicht in Frage. Die Wahl fällt aufgrund der hohen CPU-Performance und des geringen Preises auf die AX41-NVMe Server. Diese lasse ich mit einer zusätzlichen 512 GB NVMe bestücken.
Um die Hochverfügbarkeit des Kubernetes-Ingress und der Control Plane gewährleisten zu können, setzen wir zusätzlich einen VX21-CEPH aus der Hetzner Cloud ein. Dieser wird darüber hinaus als Quorum-Device für den Proxmox-Cluster dienen, auch wenn wir hier keine echte HA implementieren werden.
Das Projekt
Die Auswertung in ein Konzept zu übersetzen war nicht ganz einfach, gerade unter dem Aspekt, Kosten zu vermeiden.
Der Plan wird sein, beide EX-Server mit Proxmox VE der aktuellsten Version zu bestücken, dann dort mittels kubeadm einen Bare-Metal Kubernetes Cluster direkt auf den Hosts (nicht unbedingt best practise) zu installieren. Die Control Plane wird auf einem gesondert angemieteten VX21 laufen, der nebenbei auch Quorum für die PVE spielen wird.
Die echte Hochverfügbarkeit (live) wird innerhalb von Kubernetes verwaltet. Auf VM-Ebene setzen wir auf eine reine Replikation der “Mittel” und “Hoch” eingestuften VMs. Die “Niedrig” eingestufen VMs werden gar nicht repliziert, sondern lediglich regelmäßig auf eine Storage Box gesichert.
Wer Hetzner kennt, dem fällt sofort auf: Wie kommen die Daten denn in die VMs bzw wie die VMs ins Internet? Hetzner konnte lange keine floating IP pools abbilden. Neuerdings geht das mit VLANs, jedoch ist es relativ kostspielig. Wir werden in diesem Projekt versuchen, mit nur einer einzigen IP den gesamten cluster anzubinden. Lediglich der Mailserver bekommt eine eigene IP, die aber auf den Host “festgenagelt” sein wird.
Der Kubernetes-Ingress wird über den Control Plane-Host laufen, der eine Zusatz-IP zugeordnet bekommt.
Die gemeinsame Nutzung der Well-Known-Ports ist kaum benötigt, außer bei HTTP – Hier kommt ein Reverse-Proxy zum Einsatz.
Wie geht’s weiter?
Die Details sind bisher eine fundierte Idee. Möglicherweise ergeben sich im Verlauf des Projekts noch Änderungen. Ich hoffe, dass der Low-Cost Aspekt uns hier keinen Strich durch die Rechnung machen wird.
Dieser Beitrag ist der erste Teil einer Serie. Die weiteren Posts erscheinen nun voraussichtlich wöchentlich.
Habt ihr Ideen oder Fragen zum Projekt? Dann ab in die Kommentare!
Moin moin! Sehr coole Beitragsreihe. Mir werfen sich noch einpaar fragen auf. Könnte man bei dem Master nicht auch von ZFS Profitieren? Eben damit man sich nicht mehr auf die Worker einloggen muss?
Auch wäre es cool zu wissen, wie “statische IPs” in dieser Konfiguration gelöst werden. Wird da auch wieder eine Floating IP bestellt, ich schätze mal ein Subnet für den vSwitch wäre hier zu teuer, und auf eine VM geroutet? Alternativ könnte man ja ein Subnet für einen Dedi bestellen, hier hätte man aber wieder probleme sollte man mal die VM verschieben, jedoch besteht das gleiche Problem doch auch bei dem routen der Floating IP, oder nicht?
An sich wirklich ein cooles Projekt, ich habe etwas ähnliches vor, da ich mich dann doch langsam mal mit K8s beschäftigen sollte, möchte aber nicht auf meine Gameserver (wovon einige leider eine dedizierte, statische IP brauchen) verzichten.
Hallo Philipp,
Dankesehr!
> Könnte man bei dem Master nicht auch von ZFS Profitieren?
Inwiefern? Unser “Master” ist ja eine Hetzner Cloud VM, diese kann damit keine Workloads (außer evtl LXC – Wäre zu klären) tragen.
Dieser “Master” ist eigentlich nur ein überdimensioniertes Quorum-Device und – der Hauptgrund – der Router für unser “HA-WAN”.
> Eben damit man sich nicht mehr auf die Worker einloggen muss?
Das verstehe ich nicht. Verwechselst du da eventuell etwas?
> Auch wäre es cool zu wissen, wie “statische IPs” in dieser Konfiguration gelöst werden.
https://cybernaut.eu/2019/12/29/ha-kubernetes-proxmox-cluster-bei-hetzner-teil-3/
In Teil 3 konfigurieren wir ein ”Open vSwitch Netzwerk” (vmbr0) so, dass alle Nodes inklusive dem “Master” in einem virtuellen Netz verbunden werden.
Der Master bekommt dann von Hetzner-Seite die Floating IPs zu 2€/IP zugeordnet und routet diese weiter in unsere vmbr0.
Die VMs, welche diese WAN-IPs nutzen sollen (in unserem Beispiel die OpnSense Firewall), müssen Member dieses Netzes sein und eine korrekte MTU eingestellt haben (wichtig!) damit der Traffic sauber geroutet wird.
Die WAN-IP wird dann ganz normal am Interface in der VM konfiguriert.
Gateway ist dann die öffentliche IP des Masters, dafür braucht die VM eine statische Route über vmbr0 zu eben dieser IP.
Man muss halt dran denken, am Master und in der VM jeweils die Route zu setzen.
Was ich mache, ist die IPs alle an der OpnSense zu konfigurieren und dann per 1:1 NAT nur die relevanten Ports an die jeweiligen Server weiterreichen. Aus Security-Sicht die bessere Lösung.
Mach doch mal einen trace auf “git.firesplash.de”. Dieser Server hat seine “eigene” Public IP – Terminierend an der Firewall, dann über 1:1 NAT weitergereicht. Ganz im Gegensatz zu gateway.firesplash.de, welcher viele Server bedient.
Ein Subnet ist im Vorentscheid rausgeflogen, weil ein /29er failover-fähig bereits ca 18€ kostet. Dann muss man sich auch noch um das “Failovern” kümmern (oder ein Skript schreiben, das den robot per API bedient).
Nutze ich ein vSwitch-Subnet – das wäre die beste Alternative – kostet das auch 18€, aber ich muss ab dem 2. TB (riesige) 1,19€/TB zahlen.
Okay, das wäre heute vielleicht das alternative Mittel der Wahl.
Die Floating IP auf dem Master tut ihren Zweck hier etwas günstiger – wenn man die VM eh zahlt – und hat ein 10TB Traffic-Limit für die gesamte VM.
Zum Routing: Nein. Die floating IP hängt am Master – Der ja auf der Hetzner Cloud läuft. Der ist in deren CEPH-Pool erstellt und damit hochverfügbar.
Das Routing dieser IP machen wir selbst im o.g. virtuellen Netz.
Ich hoffe, ich konnte helfen.
>> Könnte man bei dem Master nicht auch von ZFS Profitieren?
>Inwiefern? Unser “Master” ist ja eine Hetzner Cloud VM, diese kann damit keine Workloads (außer evtl LXC – Wäre zu klären) tragen.
>Dieser “Master” ist eigentlich nur ein überdimensioniertes Quorum-Device und – der Hauptgrund – der Router für unser “HA-WAN”.
>> Eben damit man sich nicht mehr auf die Worker einloggen muss?
>Das verstehe ich nicht. Verwechselst du da eventuell etwas?
Richtig, aber wir haben uns ja in Teil 3 (glaube ich) auf einen Worker eingeloggt um das ZFS zu konfigurieren. Wenn ich richtig bin, zumindest lese ich des öfteren davon, loggt man sich ja immer über ein “Center” ein, hierbei schätze ich ist es der Master, damit man die “Worker” Webserver per Firewall blockieren kann, zwecks Sicherheit. Wenn wir jetzt ZFS auf dem Master hätten, hätten wir uns nicht auf einen Worker einloggen müsste. Das war so der Grundsatz meiner Idee dahinter.
>> Auch wäre es cool zu wissen, wie “statische IPs” in dieser Konfiguration gelöst werden.
>https://cybernaut.eu/2019/12/29/ha-kubernetes-proxmox-cluster-bei-hetzner-teil-3/
>In Teil 3 konfigurieren wir ein ”Open vSwitch Netzwerk” (vmbr0) so, dass alle Nodes inklusive dem “Master” in einem virtuellen Netz verbunden werden.
>Der Master bekommt dann von Hetzner-Seite die Floating IPs zu 2€/IP zugeordnet und routet diese weiter in unsere vmbr0.
>Die VMs, welche diese WAN-IPs nutzen sollen (in unserem Beispiel die OpnSense Firewall), müssen Member dieses Netzes sein und eine korrekte MTU eingestellt haben (wichtig!) damit der Traffic sauber geroutet wird.
>Die WAN-IP wird dann ganz normal am Interface in der VM konfiguriert.
>Gateway ist dann die öffentliche IP des Masters, dafür braucht die VM eine statische Route über vmbr0 zu eben dieser IP.
>Man muss halt dran denken, am Master und in der VM jeweils die Route zu setzen.
>Was ich mache, ist die IPs alle an der OpnSense zu konfigurieren und dann per 1:1 NAT nur die relevanten Ports an die jeweiligen Server weiterreichen. Aus Security-Sicht die bessere Lösung.
>Mach doch mal einen trace auf “git.firesplash.de”. Dieser Server hat seine “eigene” Public IP – Terminierend an der Firewall, dann über 1:1 NAT weitergereicht. Ganz im Gegensatz zu gateway.firesplash.de, welcher viele Server bedient.
Hier stelle ich die frage einmal anders. Die Cloud hat ja ein basis limit von 10 IPs. Dieses Limit kann man natürlich erhöhen, jedoch war meine frage gezielt darauf getrimmt ob eventuell hier bei den Servern, direkt im Robot für den Server, IPs gekauft wurden.
>Ein Subnet ist im Vorentscheid rausgeflogen, weil ein /29er failover-fähig bereits ca 18€ kostet. Dann muss man sich auch noch um das “Failovern” kümmern (oder ein Skript schreiben, das den robot per API bedient).
>Nutze ich ein vSwitch-Subnet – das wäre die beste Alternative – kostet das auch 18€, aber ich muss ab dem 2. TB (riesige) 1,19€/TB zahlen.
>Okay, das wäre heute vielleicht das alternative Mittel der Wahl.
>Die Floating IP auf dem Master tut ihren Zweck hier etwas günstiger – wenn man die VM eh zahlt – und hat ein 10TB Traffic-Limit für die gesamte VM.
>Zum Routing: Nein. Die floating IP hängt am Master – Der ja auf der Hetzner Cloud läuft. Der ist in deren CEPH-Pool erstellt und damit hochverfügbar.
>Das Routing dieser IP machen wir selbst im o.g. virtuellen Netz.
Erläutert meine Antwort von Oben.
>Ich hoffe, ich konnte helfen.
Kindof, yes. Vieles hat sich natürlich aus den Tutorialreihen wiederholt und nicht direkt meine Fragen beantwortet, jedoch nochmal das Insight komprimierend zusammengefasst. Erhofft hätte ich mir zu wissen, wie eben genau Subnets bzw. größere mengen an öffentlichen IPs gehandhabt werden. Ich schätze dafür ist das Setup nicht direkt ausgelegt, wenn man kein Albanischer Ölprinz ist und 2€ Pro IP und ab dem 2 TB für jedes TB zahlen möchte – soll ja ne low budged lösung sein.