Vorbereiten der Installation der Worker Nodes

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

Wir benötigen für diesen Schritt leider eine angeschlossene KVM-Konsole. Glücklicherweise bietet Hetzner dies kostenlos an. Wir können den Anschluss der “LARA” direkt beauftragen, indem wir im Robot im Menü des Servers unter support ein Ticket für “KVM” eröffnen.
Im Freitext geben wir direkt an, dass wir das Proxmox VE 6.1 ISO gern angeschlossen hätten. Der download-Link lautet:
https://www.proxmox.com/de/downloads/category/iso-images-pve

Die folgenden Schritte sind auf allen Worker Nodes identisch an der Konsole durchzuführen:

Proxmox Bootscreen
Sobald die KVM angeschlossen ist, sollten wir bereits den Boot-Screen der ISO am Bildschirm sehen.
Wir wählen den Ersten Punkt “Install Proxmox VE” und drücken Enter.

Den Willkommensbildschirm des Installers quittieren wir mit Next. Vorsicht beim HDD-Auswahlbildschirm. Klicken wir hier einfach wieder Next, installieren wir mit ext4 auf einer Einzelplatte. Wir wollen aber ZFS mit Redundanz. Dafür klicken wir auf “Options”.

Festplattenkonfiguration des Installers
In einem 2-Disk-Server wäre das Filesystem “zfs (RAID 1)” zu wählen, wir haben drei NVMes in unserem Server, daher wählen wir RAIDZ-1 was in der Funktion einem RAID5 ähnelt.
Bitte nicht über die Bildqualität wundern… Die KVM-Konsolen sind teilweise etwas eigen.

Im folgenden Schritt wählen wir unter Land (bitte englische Bezeichnung eingeben) sowie die Regionaleinstellung und anschließend legen wir ein Passwort fest.
Vorsicht: Dieser Bildschirm hält eine Falle parat! Löscht das @-Zeichen nicht! Ihr werdet es möglicherweise brauchen, denn Alt Gr funktioniert hier manchmal trotz korrekter KVM-Einstellungen nicht. Auch Alt+92 könnt ihr dann vergessen.

Netzwerkeinstellungen
Im nächsten Dialog setzt ihr die Netzwerkeinstellungen des Hosts.
Üblicherweise sind diese dank des Hetzner-DHCP vorausgefüllt. Die Netzwerkkarte hat bei euch wahrscheinlich eine Bezeichnung nach dem Muster enp**s*

Anschließend folgt eine Zusammenfassung der Einstellungen. Nach einer kurzen Überprüfung klicken wir auf Install und warten ab, bis die Installation abgeschlossen ist.

Installation des Master Node

Für die spätere Control Plane, die wir auch als Quorum in der PVE einsetzen wollen, nutzen wir einen vServer der Hetzner Cloud. Das Modell CX21 passt auf die Spezifikationen und ist als CEPH-Variante verfügbar, die durch das verteilte Filesystem hochverfügbar ist.
Die CX11 könnte eventuell (vor allem für Testumgebungen) auch ausreichen.
Wir lassen als Betriebssystem Debian 10 installieren, das ist im Grunde aber egal, da wir direkt ins Rescue System “linux64” wecheln.

Hetzner bietet im Rescue-System mit dem “installimage” Script eine mächtige Methode, um eine relativ weit anpassbare OS-Installation durchzuführen.
Auf unseren Worker Nodes wollen wir die aktuelle PVE installieren. Hierzu starten wir beide Hosts im 64 Bit Linux-Rescue System und verbinden uns per SSH mit der Cloud-VM. Schreibt euch das Passwort auf!

Zunächst starten wir das “installimage” script: # installimage
Nach ein paar Sekunden erhaltet ihr ein Auswahlmenü. Wir wollen “Other” gefolgt von “Proxmox-Virtualization-Environment-on-Debian-Buster” (Stand 12/2019)

Supportausschluss-Meldung
Dass Hetzner uns keinen Support für das Image gibt, können wir tolerieren und bestätigen mit OK
Eine Info-Meldung bzgl der Raidlevel-Konfiguration
Auch hier drücken wir wieder OK

Wir können weitestgehend überall die Standardeinstellungen belassen. Lediglich den HOSTNAME Parameter müssen wir anpassen:

Unbedingt einen validen FQDN verwenden. Ihr solltet auch den RDNS der IP-Adresse auf diesen Hostname legen sowie einen A Record einstellen.
Sicherheitsabfrage
Wenn alles fertig ist, bestätigen wir alles mit F10 und einem anschließenden Yes im wunderschönen Speicherdialog des mcedit
Warnung, dass alle Daten gelöscht werden
Hier bitte nochmal in euch gehen, ob ihr wirklich alle Daten auf dem Server löschen wollt und wenn das zutrifft, je Festplatte ein weiteres mal Yes wählen
Installation läuft...
Ihr seht nun einen wunderschönen Fortschritt des Scripts. Das dauert etwas.
Am Ende seht ihr hier einen Fehler, der tritt leider im Script auf, das stört aber später nicht, die Installation läuft trotzdem ordnungsgemäß durch. Auch das dauert nochmal einige Minuten.
Fertigstellungs-Dialog
Hat alles funktioniert, seht ihr abschließend diese Meldung.
Wir starten nun in das produktive System mittels reboot

An dieser Stelle habt ihr bereits eine funktionierende Proxmox VE. Wir überprüfen das kurz, indem wir nach dem Reboot (der durchaus eine Minute dauern kann) kurz das Webinterface aufrufen. Der Link hierzu ist https://<fqdn>:8006 wobei <fqdn> durch den FQDN des Hosts (siehe oben “HOSTNAME”) ersetzt wird.
Ihr könnt euch am Webinterface mit root und dem von Hetzner übermittelten Root-Kennwort einloggen, aber da wir hieraus noch einen Cluster bauen, braucht ihr das nicht tun.

Während der Server sein Betriebssystem installiert, ein kurzes Wort zum Zweck dieser VM:
Die Control Plane steuert den Kubernetes Cluster. Sie trägt sowohl die API als auch die Intelligenz, welche kontrolliert, was wo wann gestartet wird. Darüber hinaus werden wir den Cluster später so konfigurieren, dass noch der Ingress darauf laufen wird, da wir so die günstigen floating IPs der Hetzner Cloud für den Ingress nutzen können und von unserer Node-Hardware unabhängig sind. (Da wir die CX21-CEPH gewählt haben, ist diese VM und damit die Control Plane und der Ingress hochverfügbar)
Allerdings kann dieser “Node” am Ende keine KVM-Maschinen halten. Einstweilen mal eine LXC-Maschine wäre bei Bedarf denkbar (z.B. ein Reverse-Proxy), aber auch hier sind die Ressourcen sehr eng bemessen. Im Proxmox-Umfeld ist diese Maschine lediglich als Quorum und als Router gedacht, da wir deren Floating IPs für unseren Traffic nutzen werden.

Aus drei mach eins… Der PVE-Cluster

Im letzten Schritt für Teil 2 unserer Artikel-Serie werden wir nun die Netzwerkkonfiguration korrigieren, erweitern und die drei Nodes schlussendlich zu einem Proxmox-Cluster zusammenführen.

DNS-Konfiguration

Bevor wir einen Cluster formen können, müssen wir unbedingt bei allen Nodes prüfen, ob die Datei /etc/hosts einen Eintrag besitzt der den jeweiligen Hostnamen im FQDN zur jeweiligen öffentlichen IPv4 zuweist: nnn.xxx.yyy.zzz master.example.local master
Darüber hinaus müssen wir einen entsprechenden IPv6-Eintrag entfernen.
Die Datei sieht dann in etwa so aus (natürlich mit euren Daten):

### Hetzner Online GmbH installimage
# nameserver config
# IPv4
127.0.0.1 localhost.localdomain localhost
nnn.xxx.yyy.zzz master.example.com master
#
# IPv6
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Spezielles Netzwerk-Setup der Control Plane (“Master”)

Dieser Bereich wurde am 29.12.2019 wegen eines Strategiewechsels aktualisiert. Solltet ihr das Setup bereits vorher durchgeführt haben, passt die Konifguration bitte entsprechend an.

Als nächstes loggen wir uns in das Webinterface unserer Control Plane ein. https://master.example.com:8006 mit dem Benuternamen root und dem vom Hetzner Rescue-System gemerkten Passwort.

Wenn wir nun links den Node auswählen und unter System auf Network (ja ich nutze das englische Interface) klicken, können wir die Netzwereinstellungen des Nodes anpassen.
Wir benötigen im folgenden ein Overlay-Netzwerk über alle Hosts, um die WAN-Pakete an die VMs zu bringen, da der Master Node unser Tor zur Außenwelt sein wird. Wir benötigen hierfür ein paar Pakete:
apt update ; apt -y install openvswitch-switch ifupdown2

Das “virtuelle WAN Netz” bekommt außerdem einen privaten Adressbereich, über den alle Nodes miteinander reden können. Wir dürfen dabei aber nicht vergessen, dass diese Pakete mittels GRE-Kapselung über das Internet geroutet werden und daher nicht so sicher sind wie man es von privaten Netzen gewohnt ist.
Als IP-Bereich nutze ich hierfür 192.168.254.0/24 wobei eich .10 für den Master Node nutze und .11ff für die Worker. Üblicherweise erwartet man für einen Router die “.1”, diese nutze ich aber aus dem Grund nicht, weil Hetzner für Cloud VM Netzwerke die .1 reserviert und ich mir die Option offen halten will, später auch diese Funktion mit einbeziehen zu können.

Wir klicken nun im Webinterface oben auf Create -> OVS Bridge und tragen als IP Adresse die eben festgelegte IP des Masters – also in meinem Fall 192.168.254.10/24 – als IP ein. Ein Gateway sowie Bridge Ports geben wir nicht an, denn wir werden die Pakete routen und die IPs dahinter per Proxy ARP ins Internet – bzw an die Hetzner Router – “bekanntgeben”.

Ist das erledigt, starten wir die VM einmal neu.

Netzwerk-Setup der Proxmox Worker Nodes

Die folgenden Schritte sind auf allen Worker Nodes als root durchzuführen.
Bevor wir mit der Konfiguration beginnen, installieren wir auch hier das Open vSwitch-Paket und ifupdown2 mittels apt update ; apt -y install openvswitch-switch ifupdown2
Wir öffnen das Webinterface des Worker Nodes und klicken dort zunächst auf den Node selbst, dann auf Network.
Wie man sieht, wurde vom Installer vmbr0 als Bridge angelegt, deren Member unsere physikalische Netzwerkkarte ist. Da das gegen unser späteres WAN-Konzept geht, ändern wir das wie folgt ab:

Wir notieren und IP, CIDR-Maske und Gateway der vmbr0 und löschen diese. Danach fügen wir die Daten in die Netzwerkkarte direkt wieder ein.
Wichtig: Autostart-Haken nicht vergessen!

Adapterkonfiguration
vmbr0 wurde gelöscht und die Netzwerkkarte konfiguriert

Da wir einen unnötigen zusätzlichen Neustart so vermeiden können, legen wir auch gleich zwei OVS Bridges vmbr0 und 1 an (0 für WAN, 1 für LAN). Wir vergeben auf der WAN-Bridge wieder eine IP aus unserem Helper-Netz. Wir haben hierfür wie oben bereits erwähnt die .11ff für die Worker Nodes gewählt.

Es gibt hier wieder eine kleine Besonderheit bei Hetzner. Per Default kann man nun noch nicht die IPs erreichen, die im Subnetz des Nodes liegen. Hierfür muss man trotz bzw. gerade wegen des selben Subnetzes eine Route anlegen.
Wir öffnen die Datei /etc/network/interfaces.new

Wir müssen hier am Ende des enp34s-Blocks die route ins eigene Subnet via unseres Gateways eintragen (natürlich wieder mit euren individuellen IPs – zu finden im Hetzner Robot, im Bereich des Servers unter IPs – Zum herausfinden der Netzwerk-Adresse ist ein Rechner hilfreich):

auto enp34s0
iface enp34s0 inet static
	address  nnn.xxx.yyy.134
	netmask  27
	gateway  nnn.xxx.yyy.129
	up route add -net nnn.xxx.yyy.128 netmask 255.255.255.224 gw nnn.xxx.yyy.129

Daumen drücken!

Ist das erledigt, starten wir alle Nodes einmal neu, sodass alle Änderungen übernommen werden.

Finale Teil 2: Proxmox Cluster erstellen

Jetzt ist es endlich so weit, dass wir die Nodes zusammenschalten können. Wir öffnen wieder das Webinterface unseres “Masters”, also der Control Plane.
Unter Datacenter -> Cluster klicken wir oben auf Create Cluster.
Wir geben dem Cluster hier den Namen HybridClu – Das ist aber frei wählbar.

Ich empfehle, ausdrücklich das Interface mit der öffentlichen IPv4 (sollte die physikalische Schnittstelle – nicht wie im Bild vmbr0 – sein) anzugeben. Das beugt Fehlern vor. Das private WAN Netz würde ich hier zwecks Stabilität nicht nehmen. Sicherer ist es ohnehin nicht.
Proxmox bestätigt diese Aktion nach ein paar Sekunden mit einem “TASK OK”

Einmal das Webinterface reloaden und oben links steht der Cluster Name. Nun können wir die Worker verbinden.
Wir benötigen hierfür noch die Join-Informationen, die man durch einen Klick auf den Button Join Information erhält. Genauer gesagt benötigen wir davon den unteren String.

Aufnahme der Worker Nodes

Die folgenden Schritte werden auch wieder auf jedem einzelnen Worker Node der Reihe nach durchgeführt (erst Node 1, dann 2 usw).

Wir öffnen zunächst das Proxmox Webinterface unseres Worker Nodes und melden uns als root an. Dort klicken wir dann wieder links im Baum auf Datacenter, anschließend auf Cluster und dieses Mal jedoch auf Join Cluster.

In das sich öffnende Dialogfeld fügen wir die kodierten Join-Informationen ein, die wir uns vom Master Node kopiert haben. Zusätzlich benötigen wir das Root-Passwort des Masters.
Falls unser “Master” eine IPv6-Konfiguration hat, müssen wir unbedingt bei de Peer Address darauf achten, dass hier die IPv4 übernommen wurde, ansonsten müssen die daten manuell eingetragen werden (dazu oben den Haken bei Assisted Join entfernen)
Bei Link 0 wählen wir wieder das Interface mit der öffentlichen WAN IPv4 aus, wie auch schon beim Master. Hier heißt es nun aber in der Regel enp34s0
Ist das erledigt, klicken wir auf Join

Nicht erschrecken: Das Status-Fenster bleibt vielleicht leer oder hängt sich auf. Das ist normal, da der Host jetzt ein Cluster-Zertifikat bekommt, und der Browser sich dabei in die Hose macht. Oder etwas fachlicher ausgedrückt: Er vertraut dem Host nicht mehr.
Nach circa einer Minute einmal kurz reloaden und ihr seht, was ich meine.

Wenn alles gut gelaufen ist, könnt ihr jetzt alle Nodes im Cluster sehen.
Sucht euch einen Node aus, öffnet das Webinterface und checkt den Cluster-Status durch einen Klick auf Datacenter -> Summary
Sieht das in etwa so aus, ist alles gut gelaufen und euer Cluster bereit:

Der Cluster muss “Quorate” sein, sonst lief etwas schief (oder ihr habt eine gerade Anzahl an Hosts und die Vote-Counts noch nicht angepasst). Ein “Fatal” bei der Subscription ist normal, es sei denn ihr habt euch Support bei Proxmox mit der Enterprise-Lizenz eingekauft.

Schlusswort und Vorschau

Im zweiten Teil unserer Serie haben wir unsere Nodes mit Proxmox installiert, eine Grundkonfiguration erstellt und zu einem Cluster verbunden.

Im nächsten Teil werden wir unsere Nodes mittels zweier Techniken so miteinander vernetzen, dass die Open vSwitch Bridges ein großes Netz ergeben, um die VMs untereinander über Hosts hinweg kommunizieren zu lassen.
Weiterhin werden wir Backup-Storage anbinden und einen Platz für Templates und ISO-Images schaffen.

Habt ihr Fragen, Wünsche oder Anregungen zum Projekt? Dann ab in die Kommentare damit!

Da es in zwei Tagen bereits wieder so weit ist, möchte ich an dieser Stelle noch allen Lesern und Leserinnen (und diversen Lesern – ist das so richtig?) ein frohes Weihnachtsfest bzw schöne Feiertage oder einfach nur eine tolle Woche wünschen.
(Wahnsinn, wie lang ein “Frohes Fest” wird, wenn man es international und politisch korrekt machen will)

About the Author

Inhaber / Streamer / Lead Dev von Firesplash Entertainment und ganz nebenbei Fachinformatiker Systemintegration in einem mittelständigen Unternehmen

View Articles