RedHat OKD (OpenShift Cluster Community Edition) unter Proxmox – Variante 1: Single Node Cluster

Nachdem ich letztes Jahr zum Red Hat OpenShift-Administrator ausgebildet wurde, habe ich mich entschieden, mich auch privat mehr damit zu befassen. Da OpenShift ein kommerzielles Produkt von IBM Red Hat ist, das auf einem sogenannten Subskriptionsmodell (Abo-Support) beruht, kommt das für mich im privaten Umfeld weniger in Frage.

Ich bin ein großer Fan von Open Source und schätze es, wenn Firmen ihren Code als Open Source anbieten. In diesem Fall ist ein kostenpflichtiges Support-Abo ein fairer Weg, um Kosten und Risiken auszugleichen. OKD ist das Community-Projekt von OpenShift und steht dem in nichts nach. Zu den Unterschieden im Detail könnt ihr hier nachlesen.

Sowohl OKD als auch OpenShift sind einheitliche Plattformen zur Entwicklung und Bereitstellung von nativen Cloudanwendungen auf Basis von Kubernetes. Während Kubernetes nur ein Framework ist, stellen OpenShift und OKD viele weitere Tools zur Verfügung, die die Cluster-Administration erheblich vereinfachen.

Am Anfang stellen sich natürlich ein paar Fragen nach der benötigten Hardware und den Ressourcen. Grundsätzlich kannst du OpenShift/OKD auf nahezu jeder Plattform installieren, sei es Bare Metal (also direkt auf der Hardware) oder in einer vorkonfigurierten Cloud wie AWS, Google, Azure und Co. Auch eine Installation auf einer bestehenden Virtualisierung wie OpenStack, VMware vSphere usw. ist möglich. Die Möglichkeiten sind vielfältig, siehe hier. Weiterhin musst du für dich klären, auf wie vielen Knoten (Nodes) du das Cluster verteilen willst, also wie viele Hardware-Server du benötigst.

An dieser Stelle mache ich dicke Backen, denn ich bin nicht bereit, mir ein 19-Zoll-Rack in den Keller zu stellen, um ein bisschen „herumzuclustern”. Den Energieversorger würde es vermutlich freuen, weil ihm dann Dollarzeichen (oder bei uns eher Euro) in den Augen aufblitzen. Mir tut es einfach nur weh und es ist unnötig. Typische Hardwarevoraussetzungen sind laut OKD:

Voraussetzungen

Control‑Plane‑Nodes (darauf laufen die für das Cluster notwendigen Komponenten):

• mindestens ca. 2–4 vCPU
• mindestens ca. 16 GiB RAM
• mind. 40–120 GiB Storage (schneller Storage empfohlen, speziell für etcd).​

Worker‑Nodes (darauf laufen die gewünschten individuellen Cluster-Anwendungen, wie Webserver, Datenbanken, etc.):

• mindestens ca. 2 vCPU
• mindestens ca. 8 GiB RAM
• mindestens ca. 40–120 GiB Storage, je nach Workload.​

Da mein gesamtes Homelab auf mehreren energiesparenden Intel-NUCs basiert, fiel meine Wahl auch dieses Mal wieder auf ein solches Gerät. Ich habe mich für ein Modell mit der Bezeichnung „Intel NUC12SNKi72” entschieden. Es verfügt über einen Intel Core i7-12700H mit 14 Kernen (20 Threads), 64 GB DDR4-3200-RAM und zwei 1-TB-NVMe-SSDs. Dieses Modell verfügt neben der internen Grafikkarte Intel Iris Xe Graphics über eine weitere dedizierte Grafikkarte, eine Intel Arc A770M mit 16 GB GDDR6, die jedoch für mein OKD-Cluster keine Rolle spielt. Auf dieser Hardware-Basis, die den oben genannten Empfehlungen von OKD grundsätzlich entspricht, habe ich das Proxmox Virtual Environment installiert – spätestens jetzt macht die dedizierte Grafikkarte Sinn, da ich diese an eine virtuelle macOS-VM durchreichen kann. Das ist jedoch ein anderes Thema. Das ist meine Hardware-Basis für das OKD-Cluster.

Im ersten Schritt werde ich beschreiben, wie ich ein Single-Node-Cluster – also ein Cluster, das aus nur einem Node besteht – unter Proxmox installiert und betreibe. Das Aufsetzen dauert insgesamt ca. 2–3 Stunden, dann ist das Cluster voll lauffähig. Zugegeben, ein Cluster mit nur einem Knoten wirkt etwas hilflos, aber um den Umgang mit den Kommandos zur Administration eines Clusters zu üben, ist ein Single-Node (SNO) völlig ausreichend. Auf Basis der Proxmox-Umgebung werde ich später jedoch ein Multi-Node-Cluster aufsetzen, um auch Redundanz ausrollen und testen zu können. Das wird jedoch Thema eines späteren Blogbeitrags sein.

weitere Voraussetzungen

Okay, damit haben wir die Hardware-Basis unseres Clusters geklärt. Was fehlt noch?

Du wirst einen Admin-PC benötigen. Ich empfehle dir eine Linux-VM (Fedora, CentOS, Ubuntu, …) oder macOS. Auf diesem PC kannst du die entsprechenden OpenShift-Kommandos zur Installation und Administration deines Clusters ausführen. Außerdem sollte diese Linux-VM über eine grafische Oberfläche verfügen, damit du dein Cluster auch per Webbrowser administrieren kannst (sofern du das möchtest).

Zum anderen müssen wir über das Netzwerk selbst sprechen. Aus Sicherheitsgründen läuft das Cluster grundsätzlich in einem eigenen IP-Subnetz. Ein 24er-Netz wie vermutlich dein Heimnetz verfügt jedoch nicht über ausreichend IP-Adressen, um ein solches Cluster zu betreiben. Nur zur Information: Im Cluster laufen unmittelbar nach der Installation bereits knapp 120 Pods mit jeweils eigener IP-Adresse, obwohl noch keine einzige Anwendung installiert wurde. Der folgende Screenshot zeigt nur einen Auszug:

Wir müssen uns also Gedanken über unser Netzwerk machen. Das Cluster verwaltet später den zugeteilten IP-Adressbereich selbst, um allen Cluster-Komponenten eine IP-Adresse zuweisen zu können. Dieses Netz kannst du bei der Erstinstallation festlegen. Um den Rest kümmert sich später das Cluster. Nach den Best Practices habe ich dafür ein Netz aus dem klassichen Class-A-Netz genommen: 10.128.0.0/14. Das Ziel ist ein sehr flaches Netzwerk, sodass jeder Pod jeden anderen Pod im Cluster direkt erreichen kann, unabhängig vom Node (was sehr praktisch ist, damit ein Webserver-Pod seinen Datenbank-Pod erreichen kann). Dies später zu ändern (oder zu vergrößern) ist nahezu unmöglich.

Weiterhin braucht das Cluster ein Service-Netzwerk. Dabei handelt es sich um virtuelle IP-Adressen vor den Pods, um diese von außen erreichbar zu machen. Das Cluster installiert intern eigene Load-Balancer und macht die Pods über die virtuellen IP-Adressen aus dem Service-Netzwerk von außen erreichbar. Aber Achtung! Auch dieses Service-Netzwerk ist nur intern im Cluster geroutet und dient letztendlich dazu, z.B. mehrere Webserver-Pods, die alle denselben Webserver redundant halten (sogenannte Replicas), unter einer virtuellen IP-Adresse erreichbar zu machen. In diesem Subnetz betreibt das Cluster neben der eigenen IP-Adressverwaltung auch einen DNS-Dienst (Operator dns.operator.openshift.io/v1), um beispielsweise einen Dienst, der auf verschiedenen Nodes redundant läuft, unter einem DNS-Eintrag wie my-svc.my-namespace.svc.cluster.local erreichbar zu machen. In meinem Single-Node-Cluster wird das Subnetz 172.30.0.0/16 verwendet, was großzügig gewählt ist, da alles clusterintern ist und keine Netzwerkressourcen in meinem Homelab beansprucht. Vereinfacht dargestellt sieht das wie folgt aus: (Quelle https://www.redhat.com/en/blog/using-integrated-load-balancing-with-on-premises-openshift-4-ipi):

Wie du siehst, hat das Cluster zwei Verbindungen in die „Außenwelt“: Administration über die API (Port 6443) und für die ausgerollten Clusteranwendungen über die Subdomain *.apps und die Ports 80 und 443.
Der dargestellte DNS-Operator ist einer von knapp 120, die direkt nach der Erstinstallation zur Verfügung stehen.

Kommen wir nun zur Verbindung des Clusters mit der echten Welt.

In meinem Beispiel läuft der Proxmox-Server (PVE) im Homelab unter 192.168.28.2/24. Dessen Gateway ist die .1 (der Home-Router). Alle Geräte in diesem Netzwerk können den PVE-Server erreichen und somit den Admin-PC erreichen, den ich dort als Linux-VM installiert habe. Über die Konsole kann man ihn dann visuell darstellen. Wer sich mit meinem Homelab schon einmal auseinandergesetzt hat, weiß, dass ich alle Standorte per WireGuard untereinander verbunden habe und somit von überall auch auf das Subnetz 192.168.28.0/24 zugreifen kann. Das sollte aber nicht weiter relevant sein.

Damit dein Admin-PC und dein Cluster miteinander kommunizieren können, müssen sich beide im selben IP-Subnetz befinden und denselben DNS-Server nutzen. Das Cluster selbst kümmert sich nämlich nur um den internen DNS/DHCP.
Sowohl dein Cluster als auch der Admin-PC benötigen also ein weiteres gemeinsames IP-Subnetz. Bei mir ist das die 192.168.1.0/24. Dieses Subnetz stellt auch den DHCP- und DNS-Server für dein Cluster bereit. Der DHCP verteilt IP-Adressen an alle Nodes (bei mir erstmal nur an einen Single-Node) und an den Admin-Client. Damit das auch zuverlässig funktioniert, nutze ich einen OpenWRT-Router als VM unter Proxmox. Der kann sowohl DHCP als auch DNS. Er könnte später auch die Basis sein, um dein Cluster über einen Reverse Proxy (Haproxy) aus dem Internet erreichbar zu machen – je nachdem, wie weit deine Ambitionen gehen.

Für den Zugriff auf einige grundlegende Ressourcen benötigst du außerdem das sogenannte RedHat Pull Secret. Das ist ein Token, den du unter https://console.redhat.com/openshift/install/pull-secret herunterladen kannst, nachdem du dich dort angemeldet bzw. ggf. zuvor registriert hast. Die Registrierung ist kostenlos, aber notwendig.

Okay, damit haben wir jetzt die Grundlagen besprochen. Legen wir los.

VM1: Admin-Client-VM

Ich habe mich für Fedora Workstation entschieden, damit meine Umgebung vollständig im IBM-Universum bleibt. Alternativen habe ich ja bereits oben beschrieben. Gehe zunächst auf https://fedoraproject.org/workstation/download bzw. auf die Download-Seite einer anderen Linux- oder macOS-Distribution deiner Wahl und lade das passende ISO-Image für deine Architektur herunter. Bei mir ist das x86_64. Dieses lädst du anschließend auf deinen Proxmox-Server im Ordner „ISO-Images/Upload” hoch. Wie du im Screenshot siehst, läuft bei mir hier schon mehr als nur der AdminClient.

Klicke in Proxmox auf „Create VM”, mache die notwendigen Einstellungen (4 GB RAM, 4 Kerne und 32 GB HDD sollten mehr als ausreichen) und gib das ISO als Installationsimage an. Folgst du der Anleitung, installierst du Fedora. Starte danach die Maschine, verbinde dich mit der Kommandozeile (logge dich also ein und starte ggf. das Terminal) und bringe die VM mit „dnf update” auf den aktuellsten Stand.

Prüfe dann auf der rechten Seite unter https://github.com/okd-project/okd, welches das derzeit aktuelle stabile Release ist. Zum Zeitpunkt der Erstellung dieser Anleitung war es 4.20-okd-scos.16.

Nutze diese Information sowie deine Prozessorarchitektur (in den meisten Fällen und definitiv bei einem Intel NUC x86_64) um im Terminal deiner Admin-Client-VM diese beiden Variablen festzulegen.

export OKD_VERSION=4.20.0-okd-scos.16
export ARCH=x86_64

Wenn ich es nicht explizit erwähne, werden alle Schritte, die ich hier aufführe, auf der gerade installierten Admin-Client-VM ausgeführt.

Als Nächstes laden wir den OpenShift-Client (oc) herunter.

curl -L "https://github.com/okd-project/okd/releases/download/${OKD_VERSION}/openshift-client-linux-${OKD_VERSION}.tar.gz" -o oc.tar.gz
tar zxf oc.tar.gz
chmod +x oc kubectl
sudo mv oc kubectl /usr/local/bin/
oc version

Du solltest anschließend eine ähnliche Ausgabe wie die folgende erhalten (sicherlich mit anderen Versionsnummern):

Als nächstes laden wir den OpenShift-Installer herunter:

curl -L "https://github.com/okd-project/okd/releases/download/${OKD_VERSION}/openshift-install-linux-${OKD_VERSION}.tar.gz" -o openshift-install-linux.tar.gz
tar zxvf openshift-install-linux.tar.gz
chmod +x openshift-install
sudo mv openshift-install /usr/local/bin/
openshift-install version

Ergebnis sollte am Ende ähnlich wie folgt aussehen:

Danach laden wir Fedora CoreOS (FCOS) als Basis für unser Cluster-Image herunter.

ISO_URL=$(openshift-install coreos print-stream-json \
  | jq -r ".architectures.\"${ARCH}\".artifacts.metal.formats.iso.disk.location")

echo "Downloading FCOS ISO from: ${ISO_URL}"
curl -L "${ISO_URL}" -o fcos-live.iso

Das sollte dann so ähnlich aussehen:

Als Nächstes generieren wir einen SSH-Key, damit der Admin-Client zukünftig passwortlos auf das Cluster zugreifen kann, um Installationen und Konfigurationen durchzuführen.

ssh-keygen

Dann lässt du dir mit dem Befehl cat ~/.ssh/*.pub den Inhalt deines öffentlichen Schlüssels ausgeben und speicherst ihn vorübergehend in eine Textdatei auf deinem Admin-Client oder in die Zwischenablage. Den brauchen wir gleich.

Damit haben wir zunächst alles zusammen, was wir benötigen. Als Nächstes erstellen wir eine Datei, die die grundlegende Cluster-Konfiguration für die Installation enthält.

nano install-config.yaml

Dort fügst du folgendes ein (und machst die nötigen Anpassungen!):

apiVersion: v1
baseDomain: okd.internal # Your local base domain
metadata:
  name: okd4sno    # der Name deines Clusters
compute:
- name: worker
  replicas: 0     # ein SNO hat keine dedizierten Worker-Nodes, ist ja alles All-in-One
controlPlane:
  name: master
  replicas: 1     # nur eine Control-Plane (normalerweise sollten das 3 sein)
networking:
  networkType: OVNKubernetes
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 192.168.28.0/24 # Das ist das Subnetz, in dem sowohl dein Admin-PC als auch das Cluster ist
  serviceNetwork:
  - 172.30.0.0/16
platform:
  none: {} # die Proxmox-Installation verhält sich aus Sicht des Clusters wie ein Bare-Metal
bootstrapInPlace:
  installationDisk: /dev/vda
pullSecret: '<REDHAT_PULL_SECRET_HERE>' # Inhalt des RedHat-Pull-Secret zwischen die ''
sshKey: |
  ssh-ed25519 AAAA...YOUR_SSH_PUBLIC_KEY # Ersetze diese Zeile mit der Ausgabe deines SSH-PubKey.

So, jetzt noch ein paar Erläuterungen zu dein einzelnen Zeilen:

baseDomain ist deine BASIS-URL, also entweder etwas rein internes oder wenn du später dein Cluster von außen (Internet) erreichbar haben willst, z.B. okd.duckdns.org (<- wobei die schon vergeben ist)
metadata/name ist der Name deines Clusters, du könntest ja auch mehrere Cluster unter einer Domain erreichbar haben, z.B. okd4sno. Dein Cluster wäre dann z.B. später vom Admin-Client unter api.okd4sno.okd.duckdns.org erreichbar, eine mögliche WebApplikation, also ein z.B. Blog unter blog.apps.okd4sno.okd.duckdns.org. Jetzt wird dir vielleicht auch klar, an welcher Stelle OpenWRT wichtig wird, denn irgendwer muss ja schließlich von extern (und wenn es nur der Admin-PC ist) derartige Domains auflösen, um das Cluster erreichen zu können.
machineNetwork/cidr ist das Subnetz, über das das Cluster von der Außenwelt erreichbar ist. In dem befinden sich also Admin-Client, Cluster und der OpenWRT-Router
bootstrapInPlace/installationDisk ist bei mir /dev/vda – das ist abhängig davon, welcher Typ dein Datenträger des Cluster-SingleNode hat, dazu kommen wir gleich nochmal bei der Konfiguration der entsprechenden VM
pullSecret ist der heruntergeladene Token. Achte darauf, das dieser vollständig zwischen den beiden einfachen Anführungszeichen gesetzt wird, die Anzeige ist etwas tricky, da dieser nicht in eine Zeile passt.
sshKey ist die Ausgabe deines frisch erzeugten SSH-Publick-Key (der private bleibt schön da wo er ist!)

Speichere die Datei und beende den Editor mit STRG-X.

Als Nächstes erstellen wir ein zukünftiges Arbeitsverzeichnis und kopieren sowohl die install-config.yaml als auch die ISO dorthin. Das ist wichtig, weil die install-config.yaml während der Abarbeitung automatisch gelöscht wird (so geht es bei einem eventuellen zweiten Versuch schneller, falls etwas nicht reibungslos funktioniert).

mkdir okd-sno-install
cd okd-sno-install
copy install-config.yaml ../
copy ../fcos.iso .

Dein Arbeitsverzeichnis sollte wie folgt aussehen:

Jetzt generieren wir die Patches für die ISO auf Basis der install-config.yaml mit:

openshift-install create single-node-ignition-config

Wie du siehst, werden auch gleich Zertifikate erzeugt:

„Consuming“ ist hier in der Tat wörtlich zu nehmen (install-config.yaml ist weg), dein Verzeichnis sollte jetzt etwas mehr „Leben“ haben.

Als nächstes modifizieren wir das ISO dahingehend, das die entsprechenden Cluster-Konfig in das ISO geschrieben werden:

podman run --privileged --pull always --rm \
  -v /dev:/dev -v /run/udev:/run/udev -v "$PWD":"$PWD" -w "$PWD" \
  quay.io/coreos/coreos-installer:release \
  iso ignition embed -fi bootstrap-in-place-for-live-iso.ign fcos-live.iso

Das dauert einen kleinem Moment, aber danach ist die fcos.iso nicht mehr ganz dieselbe (siehst du ggf. auch am Zeitstempel).

Diese ISO lädst du jetzt auf deinen Proxmox-Server durch folgendes Komando hoch:

scp fcos-live.iso root@192.168.28.2:/var/lib/vz/template/iso/

Denke daran, dass die IP-Adresse deines Proxmox-Servers sicherlich eine andere ist. Hier wirst du nach deinem Proxmox-Root-Passwort gefragt, sobald du den Fingerprint mit „YES” bestätigt hast.

Damit ist der Teil Admin-PC soweit vorbereitet, kommen wir zu OpenWRT.

VM2: OpenWRT

Hier bedienen wir uns einfach dem Proxmox-Helper-Scripts. Öffne eine Terminal-Session auf deinem Proxmox-Server und führe folgenden Code aus:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/vm/openwrt-vm.sh)"

Der Rest ist eine Next-Next-FINISH-Installation, um die Konfiguration kümmern wir uns gleich.

Standardmäßig wird ein OpenWRT-Router mit zwei Netzwerkkarten (WAN/LAN) und minimalen weiteren Hardware-Ressourcen installiert – mehr ist auch nicht nötig.

Das WAN-Interface holt sich per DHCP eine IP-Adresse aus deinem HomeLAN (Fritzbox etc.) und das LAN-Interface hat die Adresse 192.168.1.1. Es stellt sowohl DNS als auch DHCP bereit. Wie du in Proxmox sehen kannst, hat das LAN als VLAN-Tag die 999 und ist somit logisch vom Rest des Netzwerks getrennt.

Als Nächstes muss auch dein Admin-PC eine weitere Netzwerkkarte im VLAN 999 erhalten, damit du den OpenWRT-Router bequem über die WebGUI konfigurieren kannst. Gehe dazu in der Proxmox-WebGUI auf die Hardware-Einstellungen deines Admin-Clients, klicke auf „Add/Network Device” und füge eine weitere Netzwerkkarte mit dem VLAN-Tag 999 hinzu.

Starte ggf. den AdminClient neu, damit die Einstellungen übernommen werden. Normalerweise erkennt er das auch ohne Neustart. Nun müssen wir das Netzwerk des AdminClients ein wenig anpassen, da er jetzt aus zwei Netzwerken per DHCP sowohl eine IP-Adresse als auch ein Gateway erhält. Zwei Gateways sind in diesem Fall keine gute Idee. Mit dem Befehl „ip route” kannst du prüfen, welche Standard-Routen es gerade gibt. Wenn das Ergebnis dem meinen gleicht, kannst du die Einstellungen so belassen.

Das Standard-Gateway der zuletzt hinzugefügten Netzwerkkarte wurde automatisch auf eine Metrik höher als die der anderen gesetzt (101 statt 100) – die kleinere Metrik setzt sich durch. Das bedeutet, dass Verbindungen, die nicht zum Cluster gehen, ins HomeLAN geroutet werden und somit in Richtung Internet. Falls das bei dir wider Erwarten verkehrt herum ist, kannst du die Metrik entweder mittels nmcli manuell anpassen oder du gehst in die grafische Oberfläche zu den Netzwerkeinstellungen und vergibst dem Admin-PC auf der zweiten Karte eine manuelle IP-Adresse ohne Angabe eines Gateways.

Wenn das soweit passt, öffne den Firefox auf deinem Admin-Client und gib in der Adresszeile 192.168.1.1 ein. Als Erstes solltest du ein Passwort setzen.

Okay, DHCP läuft standardmäßig im VLAN 999. Um DNS kümmern wir uns, sobald der Single-Node-Cluster erstmals startet und eine IP-Adresse hat, die wir dann zuordnen können.

VM3: SingleCluster-Node

Kommen wir zur dritten VM, deinem eigentlichen ClusterSingleNode. Wie du weißt, haben wir dafür ein spezielles Image erstellt und auf deinem Proxmox-Server hochgeladen. Jetzt erstellen wir durch einen Klick auf „Create VM” eine neue virtuelle Maschine mit folgenden Einstellungen:

Unter „General” kannst du den Namen frei wählen, das ist nicht weiter relevant.

Unter OS stellst du sicher, das dein fcos-live.iso als auch bei Guest OS Linux 6.x-2.6 Kernel ausgewählt ist.

Unter System wählst du q35 als Maschinentyp, BIOS OVMF (UEFI), aktivierst EFI Disk, wählst einen passenden Speicher dafür aus und aktivierst Qemu Agent.

Wähle unter „Disks” statt „SCSI” die Option „VirtIO Block” aus und ändere die Größe der Disk (die vorausgewählten 32 GB entsprechen nicht den Voraussetzungen für einen Clusterbetrieb).

Wenn du an dieser Stelle SCSI stehen lässt, was durchaus möglich wäre, musst du das auch in deiner install-config.yaml entsprechend berücksichtigen. Denn je nachdem wird dein Datenträger in dieser neuen VM als /dev/sda oder /dev/vda eingebunden. Bei einer falschen Konfiguration kann der OKD-/OpenShift-Installer deine virtuelle Platte sonst nicht verwalten.

Unter CPU wählst du mindestens 8 Kerne und als Typ Host, damit keine weitere Virtualisierungsebene dazwischengeschaltet wird, was Performance kosten würde.

Gönne der VM mindestens 32 GB RAM und deaktiviere Ballooning Device, damit diese auch von Anfang an vollumfänglich der VM zur Verfügung stehen.

Die Netzwerkeinstellungen kannst du bis auf das VLAN-Tag so belassen, das setzt du auf 999, damit Cluster, der OpenWRT-Router und natürlich der Admin-PC in demselben Netzwerksegment sind.

Ändere vor dem Start der VM noch die Bootreihenfolge unter „Options”. Das Netzwerk kannst du komplett deaktivieren und „virtio0” sollte an erster Stelle stehen. Das stellt sicher, dass solange virtio0 selbst nicht bootfähig ist, von der CD gebootet wird. Nach der Erstinstallation startet die VM dann automatisch von der Platte.

Cluster-Installation

Starte jetzt die VM. FCOS sollte nun von der Live-ISO booten. Da diese entsprechend gepatched ist, sollte /dev/vda mit „Leben” gefüllt werden und die VM startet anschließend neu (nun von der Festplatte). Beobachte währenddessen (außer unmittelbar nach dem Boot, da kann es zwei bis drei Minuten dauern) Aktivitäten in der Proxmox-Konsole dieser VM. Schau aber nicht zu lange zu, denn irgendwann wird deine Installation hängen bleiben, weil dein DNS nicht sauber konfiguriert ist.

Hier ein paar Screenshots, die zeigen, wie der Vorgang in etwa abläuft:

Du kannst die Installation auch vom Admin-Client aus überwachen, in dem du mit folgendem Befehl auf das Cluster zugreifst:

openshift-install wait-for bootstrap-complete --log-level=info

…dieser DNS von deinem Admin-Client (noch) gar nicht auflösbar ist. Das kannst du auch mittels ping oder dig (nslookup) versuchen. Die IP deines Clusters kannst du erreichen, per DNS geht da nix. Deswegen hängt die Installation auch an dem Punkt, aber keine Sorge. Sobald der DNS erreichbar ist, macht das Cluster einfach weiter.

DNS

In der install-config.yaml hast du dich bereits auf einen FQDN für dein Cluster festgelegt. In meinem Beispiel oben war das okd4sno.okd.internal. Das weiß das Cluster intern. Um jedoch die API und die Apps erreichbar zu machen, musst du einen externen DNS betreiben, der darauf verweisen kann. Dafür haben wir ja OpenWRT installiert.

Unter „Network/DHCP und DNS” kommst du zu den entsprechenden Einstellungen. Hier darfst du jetzt keinen Fehler machen. Die meisten Fehler im Zusammenhang mit dem Cluster liegen im DNS. Wenn es nicht am DNS liegt, schaue trotzdem ins DNS! Es liegt immer am DNS!

Aber zunächst fixieren wir die IP deines Clusters, DHCP hin oder her – aber niemand will, dass sie diese IP wirklich dynamisch ändert. Dazu gehst du auf deinem Admin-PC in der WebGUI des OpenWRT-Routers auf „Network” > „DHCP und DNS” und wechselst dort auf die Registerkarte „Static Leases”.

Hier siehst du, dass deinem Cluster eine IP-Adresse zugewiesen wurde (bei mir 192.168.1.49). Diese reservierst du fest im DNS, indem du auf die Schaltfläche „Add” oberhalb klickst. Lege anschließend einen Hostnamen fest und wähle aus der Liste unter „IP address” die IP-Adresse deines Clusters aus. Scrolle dann nach unten und klicke auf „Safe”.

Damit sollte die IP-Adresse zunächst unveränderlich sein.

Jetzt kommt DNS dran. Jetzt können deine Einstellungen natürlich von meinen abweichen. Davon ausgehend das deine Basis-URL okd.internal und dein Clustername okd4nso lautet (also exakt so wie oben in der install-config.yaml) und müssen die Einstellungen wir folgt aussehen:

Hier nochmal zum kopieren, aber achte darauf, das dein FQDN und machineName vermutlich ein anderer ist.

• okd.lan → 192.168.1.1 # okd.lan verweist auf deinen OpenWRT-Router (VLAN 999)
• api.okd4sno.okd.lan → 192.168.1.149 # damit der Zugriff in der API funktioniert
• api-int.okd4sno.okd.lan → 192.168.1.149 # damit der interne Zugriff für die API funktioniert
• console-openshift-console.apps.okd4sno.okd.lan → 192.168.1.149 # damit der Webzugriff funktioniert
• oauth-openshift.apps.okd4sno.okd.lan → 192.168.1.149 # damit SingleSignOn funktioniert
• *.apps.okd4sno.okd.lan → 192.168.1.149 # Wildcard, damit deine CLuster-Apps erreichbar sind

Und kaum ist dein DNS sauber konfiguriert, ist auch die API erreichbar und die Installation kann abgeschlossen werden:

Das siehst du auch wieder in der Console der VM

Jetzt lass die Installation weiterlaufen und verifiziere den Verlauf vom Admin-Client aus mit

openshift-install wait-for bootstrap-complete --log-level=info

Sobald der bootstrap etcd member entfernt wurde kannst du mit folgendem Kommando den Abschluss der Installation verfolgen:

openshift-install wait-for install-complete --log-level=info

Und wie du siehst, weitere gut 12 min später ist das Cluster lauffähig! In der VM schaut das so aus:

Wenn du jetzt wie oben in Terminal des AdminClient beschrieben im Webbrowser https://console-openshift-console.apps.okd4sno.okd.internal aufrufst, kommt nach 2x Sicherheitswarnung wegen nicht prüfbaren Zertifikat der Login-Screen.

Nach dem Login kannst du eine kleine Entdeckungstour unternehmen oder diese einfach weg-skippen 🙂

Das war es schon! Das Single-Node-Cluster ist lauffähig und du kannst deine erste Anwendung ausrollen.

Umgang mit dem Cluster (Kommandozeile)

Ich bin kein Freund grafischer Oberflächen. Unter der Haube wird auch dort Kommandozeilenkram gemacht, sei es Shell, Powershell oder WMI. Das ist hier nicht anders. Ein Kubernetes-Cluster wird mit kubectl administriert, OpenShift/OKD wiederum mit steuert kubectl mit oc (und bringt dabei noch etliche Features mit). Die grafische Oberfläche greift genauso wie oc oder kubectl auf die Cluster-API zu.

Du hast ja bereits den OpenShift-Client (oc) auf deinem Admin-Client installiert. Alles, was du dem Client jetzt noch mitteilen musst, sind seine Zugangsdaten für das Cluster. Diese liegen unter ~/okd-sno-install/auth/kubeconfig, also in ./auth unterhalb unseres Arbeitsverzeichnisses. Wir legen diese Datei einfach als Variable fest, damit wir sie nicht bei jedem oc-Kommando erneut eingeben müssen.

cd ~
export KUBECONFIG="${PWD}/okd-sno-install/auth/kubeconfig"
oc whoami

Mit einem oc get nodes siehst du deine installierten Nodes – also nur den einen in deinem Single-Node-Cluster.

Zunächst wollen wir jedoch einen neuen, dauerhaften Admin anlegen. Der Standard-Account „kubeadmin” ist in Testumgebungen zwar noch okay, aber spätestens in einer Multi-User-Umgebung – und darauf läuft es bei Clustern ja fast immer hinaus – ist das Teilen dieses Accounts keine Option. Erstellen wir also einen neuen Account, sagen wir Hans Dampf. Der Username wird in meinem Beispiel also hdampf.

htpasswd -c -B -b users.htpasswd hdampf DEIN_GEHEIMES_PASSWORT
oc create secret generic htpasswd-secret --from-file=htpasswd=users.htpasswd -n openshift-config
rm users.htpasswd

Die erste Zeile generiert (-c) ein Passwortfile mit BCRYPT (-B) als Hashing-Methode und liest das Passwort selbst von der Command-Line (-b) ein. Die zweite Zeile erstellt in OKD ein htpasswd-secret mit dem generierten Passwortfile und die dritte Zeile löscht das Passwortfile wieder aus dem Verzeichnis.

Jetzt interagieren wir zum ersten Mal richtig mit unserem neuen Cluster, indem wir eine Konfigurationsdatei im YAML-Format erstellen und diese auf das Cluster anwenden. Oder besser: Wir übergeben das der API, die sich dann darum kümmert.

Erstelle am besten ein neues Arbeitsverzeichnis für YAML-Dateien, um die Übersicht zu verbessern, und wechsle dorthin. Dann startest du den Editor mit oauth.yaml als Argument.

mkdir yaml
cd yaml
nano oauth.yaml

Zunächst müssen wir festlegen, wofür die YAML-Datei gedacht ist (hier: OAuth, also ein Identifizierungsprovider). Der Rest ist, denke ich, recht selbsterklärend. Das htpasswd-Secret haben wir dem Cluster ja bereits übergeben. Denke daran, bei YAML-Dateien keine Tabulatoren zu benutzen, sondern Leerzeichen mit der Leertaste zu setzen. Die Einrückung bei YAML ist nicht freiwillig.

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: local_htpasswd
    mappingMethod: claim
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpasswd-secret

Dann „werfen“ wir diese YAML gegen das Cluster:

oc apply -f oauth.yaml

Dann fügen wir dem User hdampf den Cluster-Admin als Cluster-Rolle hinzu.

oc adm policy add-cluster-role-to-user cluster-admin hdampf

Du kannst dich dann umgehend auf der Konsole mit dem neuen User anmelden, das abschalten der Zertifikatsprüfung ist leider erforderlich, da in der bisherigen Konfiguration der Admin-Client dem Zertifikat des Clusters nicht vertraut, dazu müssten wir erst Zertifikate hin- und hertauschen, aber als Testlab reicht es auch so, denke ich.

oc login https://api.okd4sno.okd.internal:6443 --insecure-skip-tls-verify=true -u hdampf

Und ja, der hdampf kann sich natürlich jetzt auch an der Weboberfläche anmelden (wer’s mag), die sich ab jetzt wie folgt präsentiert:

Schon kann hdampf die „Erkundungstour“ mit OpenShift machen:

Troubleshooting

Auf die Gefahr mich zu wiederholen:

Die meisten Fehler in Verbindung mit Cluster liegen im DNS. Ist es nicht DNS, schaue trotzdem ins DNS! Wenn dir jemand sagt, es liegt am Netzwerk….checke DNS! Es ist immer DNS!

Allgemeines:

1. Bei der Generierung der Ignition-Files zum patchen des Live-ISO werden Zertifikate erzeugt, die teilweise nur ein paar Stunden (max. 24h) gültig sind. Wenn du mit der Fehler suche also länger beschäftigt bist, fängst du besser mit dem löschen des Arbeitsverzeichnises an und setzt an diesem Punkt der Anleitung wieder ein
   cd ~
rm -R okd-sno-install
mkdir okd-sno-install
cd okd-sno-install
copy install-config.yaml ../
copy ../fcos.iso .
2. Falls du von vorne anfangen willst, aber die 24h noch nicht rum sind, kannst du auch in Proxmox die HDD der okd4sno-VM detachen, eine neue bauen und einhängen, die Boot-Reihenfolge anpassen und die VM neu starten (FCOS-ISO liegt ja noch bereit)

Dinge, die du vom AdminClient aus prüfen kannst

1. Starte ggf. deinen OpenWRT nach den Änderungen am DNS einmal neu durch
2. ping okd.internal, um die Konnektivität inkl. DNS zum OpenWRT zu testen
3. ping api.okd4sno.okd.internal, um die Konnektivität inkl. DNS zum Cluster zu testen
4. ssh core@192.168.1.149 -o StrictHostKeyChecking=no, um eine ssh-Verbindung zum Cluster aufzubauen und Prüfung des HostKeys zu umgehen, denn die ändert sich mehrfach während der Installation (Umbenennung Hostname, etc.)
   • journalctl -b -f -u release-image.service -u bootkube.service während der ersten Phase der VM-Installation
   • auch hier kannst du die o.a. ping-Kommandos ausführen und DNS prüfen
5. openshift-install wait-for bootstrap-complete --log-level=info während der Bootstrap-Phase
6. openshift-install wait-for install-complete --log-level=info während der Abschluss der VM-Installation
7. Wenn dir als Node localhost.localdomain angezeigt wird, ist das nicht schlimm, dann hat dein DNS-Server den PTR-Record nicht rechtzeitig ausgeliefert und der Node wurde mit einem Default-Hostname eingerichtet, hat aber für die Funktion deines Clusters keine Auswirkungen. Bei einem Multi-Node-Cluster wäre das allein wegen der Übersicht kontraprodruktiv, aber hier ist es nur Schmuck am Nachthemd. 🙂
   
8. Mit oc get co kannst du prüfen, ob alle Cluster Operatoren laufen, keiner sollte in Spalte Degraded ein True stehen haben.

Dinge, die du auf dem okd4sno-VM prüfen kannst

Siehe oben unter Dinge auf dem Admin-Client, aber wenn die Installation erstmal fertig ist, sollte ssh auf dem Cluster-Node nur noch erfolgen, wenn du den so richtig kaputt gemacht hast, denn sonst gibt es bessere Clustertools für dessen Verwaltung, z.B.:

oc debug node/<NODE_NAME>
chroot /host

Ergänzungen für diesen Blogeintrag (folgen wenn ich Zeit habe)…

• persistenter Speicher
• lokale Registry
• Anwendung ausrollen und von extern erreichbar machen

Und wenn ich damit genug gespielt habe, baue ich mir auf derselben Hardware ein Multi-Node-Cluster….Beitrag für Variante 2 folgt dann zeitgerecht…