OKD Single-Node auf Hetzner

01 Voraussetzungen

Der einmalige Teil steht in Server-Basis: Hetzner-Konto + API-Token, hcloud CLI mit Kontext, SSH-Key bei Hetzner hinterlegt, oc/kubectl im PATH (Programmsuchpfad).

zusaetzlich WSL2

openshift-install laeuft nur unter Linux. Einmalig eine WSL2-Distribution installieren (Neustart noetig):

wsl --install -d Ubuntu
wsl -l -v            # muss die Distro mit VERSION 2 zeigen

• sno.ps1 holt openshift-install + oc selbst in die WSL (nach ~/okd-sno/bin) – nichts weiter einzurichten.
• Der WSL-Traffic geht ueber dieselbe oeffentliche IP (Internet Protocol) wie der Laptop – die Firewall-Regel fuer 6443 passt also automatisch.
• Server-Groesse: das offizielle SNO-Minimum ist 8 vCPU / 16 GB (cpx42) – das reicht fuer OKD leer (OKD belegt selbst schon ~11 GB RAM, CPU ist nie das Thema). sno.ps1 nimmt darum standardmaessig cpx52 (12 vCPU / 24 GB), damit auch eigene Workloads Platz haben. ccx33 (8 dediziert / 32 GB) laeuft am ruhigsten. Konkrete Auslastung mit einem ganzen Projekt-Stack: Bibliothek-Enterprise per Jenkins auf OKD.

02 Installation mit sno.ps1

Ein Befehl. Danach ~30–45 min warten (die ersten ~5 min mit Rueckfragen bei neuem SSH-Host-Key, der Rest laeuft durch). Server, Rescue, Ignition, kexec, wait-for – alles automatisch.

.\scripts\sno.ps1 install
# Vorgabe: -Type cpx52 (12 vCPU / 24 GB)
# optional: -Type cpx42   (16 GB, nur OKD leer)  |  -Type ccx33 (dediziert, ruhiger)
#           -Location fsn1  (anderer Standort)

Was das Skript der Reihe nach tut:

• neueste okd-scos-Version ermitteln, openshift-install+oc in die WSL holen
• Firewall okd-sno-fw (22+6443 nur von deiner IP, 80+443 offen) und eine reservierte Primary-IPv4 okd-sno-ip anlegen – die feste IP ist wichtig, weil die API-Zertifikate und die nip.io-Namen an ihr haengen
• Server okd-sno (cpx52, Ubuntu als Rescue-Traeger) erstellen, Rescue aktivieren, Hard-Reset (ein Soft-Reboot geht nicht in den Rescue)
• in der WSL die install-config.yaml + single-node-ignition-config erzeugen (mit der festen IP: baseDomain: <ip>.nip.io, Pull-Secret ist ein Dummy – OKD braucht kein echtes)
• Ignition + sno-kexec.sh ins Rescue hochladen, dort SCOS-Live-Kernel/initramfs holen, Ignition als /config.ign (xz-cpio) anhaengen, kexec
• vom Laptop aus openshift-install wait-for install-complete gegen api.sno.<ip>.nip.io:6443
• kubeconfig nach ~\.kube\okd-sno-hetzner.yaml kopieren, KUBECONFIG setzen, Console-URL + kubeadmin-Passwort ausgeben

03 Was dabei passiert (zum Mitlesen)

Waehrend wait-for laeuft, kannst du dem Node zusehen – .\scripts\sno.ps1 ssh (User core).

Der Node rebootet dabei ein- bis zweimal selbst (Machine Config Operator). Das ist normal.

04 Cluster pruefen

$env:KUBECONFIG = "$env:USERPROFILE\.kube\okd-sno-hetzner.yaml"
oc whoami                 # -> system:admin
oc get clusterversion     # AVAILABLE=True, "Cluster version is 4.x.x-okd-scos.y"
oc get co                 # alle 34 auf AVAILABLE=True
oc get nodes -o wide      # 1 Node, ROLES control-plane,master,worker, cri-o

KUBECONFIG dauerhaft: hat install schon per SetEnvironmentVariable(…,'User') gesetzt – in neuen Terminals aktiv. Zuruecksetzen macht sno.ps1 down / destroy.

05 Erstes Projekt, App & Route

Normaler OpenShift-Workflow – wie im grossen Cluster.

oc new-project demo
oc new-app --image=docker.io/library/nginx --name=web
oc expose service/web                          # -> Route auf *.apps.sno.<ip>.nip.io
oc get route
# -> http://web-demo.apps.sno.<ip>.nip.io  (Port 80/443 sind fuer alle offen)

• S2I-Builds, BuildConfig, DeploymentConfig, SCCs (Security Context Constraints), oc adm – alles da, es ist ein echtes OpenShift.
• Auto-Deploy: Manifeste in Git + Argo CD (Continuous Delivery)/Flux (OLM/OperatorHub ist installiert).
• Ganzes Projekt per CI (Continuous Integration): Bibliothek-Enterprise per Jenkins auf OKD – Jenkins baut die Images, pusht in die interne Registry, deployt per Helm (jede Falle dokumentiert).
• Privat statt Route: oc port-forward svc/web 8080:80.

06 Kosten steuern: down / up

.\scripts\sno.ps1 down       # kubelet stoppen -> Snapshot -> Server loeschen (IP + Snapshot bleiben)
.\scripts\sno.ps1 up         # Server aus dem Snapshot, gleiche feste IP -> Cluster kommt zurueck
.\scripts\sno.ps1 status     # laeuft er? seit wann? ~Kosten? API erreichbar?
.\scripts\sno.ps1 destroy    # alles weg: Server, Snapshot, reservierte IP, Firewall

Nach down laufen nur IP + Snapshot weiter (~0,75 €/Monat). Eine 3-h-Session auf cpx52 ist ~40 Cent. Warum die feste IP: API-Zertifikate und alle nip.io-Namen sind auf die IP ausgestellt – mit einer neuen IP muesste man neu installieren.

+ Manuell (ohne sno.ps1)

Falls du den Ablauf verstehen oder anpassen willst. Die drei Bausteine im Repo: scripts/sno.ps1 (Orchestrierung), scripts/sno-wsl.sh (Linux-Teil), scripts/sno-kexec.sh (Rescue-Teil).

1 WSL: Werkzeuge + Ignition

W=~/okd-sno; mkdir -p $W/bin; cd $W
OKD=4.22.0-okd-scos.8   # neueste: github.com/okd-project/okd/releases/latest
curl -L https://github.com/okd-project/okd-scos/releases/download/$OKD/openshift-install-linux-$OKD.tar.gz | tar xz -C bin
curl -L https://github.com/okd-project/okd-scos/releases/download/$OKD/openshift-client-linux-$OKD.tar.gz  | tar xz -C bin oc kubectl

apiVersion: v1
baseDomain: <ip>.nip.io
metadata:
  name: sno
compute:
- { name: worker, replicas: 0 }
controlPlane:
  name: master
  replicas: 1
networking:
  networkType: OVNKubernetes
  machineNetwork:
  - cidr: <ip>/32
platform:
  none: {}
bootstrapInPlace:
  installationDisk: /dev/sda
pullSecret: '{"auths":{"fake":{"auth":"aWQ6cGFzcwo="}}}'
sshKey: |
  <dein id_ed25519.pub>

bin/openshift-install --dir cfg create single-node-ignition-config
# -> cfg/bootstrap-in-place-for-live-iso.ign  (+ cfg/auth/kubeconfig, kubeadmin-password)
bin/openshift-install coreos print-stream-json | grep -oE 'https://[^"]+live-(kernel|initramfs|rootfs)[^"]*'

2 Hetzner: Server + Rescue

hcloud primary-ip create --type ipv4 --name okd-sno-ip --location hel1 --assignee-type server
hcloud server create --name okd-sno --type cpx52 --image ubuntu-24.04 `
  --ssh-key laptop --firewall okd-sno-fw --location hel1 --primary-ipv4 okd-sno-ip
hcloud server enable-rescue okd-sno --ssh-key laptop
hcloud server reset okd-sno            # HARD reset - Soft-Reboot geht nicht in den Rescue

3 Rescue: kexec in SCOS-Live

Ignition + scripts/sno-kexec.sh ins Rescue kopieren, dann:

KERNEL_URL=… INITRD_URL=… ROOTFS_URL=… IGN=/root/sno.ign bash /root/sno-kexec.sh

Das Skript installiert kexec-tools, laedt Kernel+initramfs, haengt die Ignition als /config.ign (xz-cpio) an das initramfs (genau das macht coreos-installer pxe customize intern – der Container-Weg scheitert im Rescue an fehlendem BPF) und loest systemctl kexec aus. Ab hier laeuft alles selbst.

4 Warten & kubeconfig

bin/openshift-install --dir cfg wait-for install-complete
cp cfg/auth/kubeconfig /mnt/c/Users/<du>/.kube/okd-sno-hetzner.yaml
cat cfg/auth/kubeadmin-password

+ Absicherung

• API + SSH nur ueber Tailscale – okd-sno-fw lässt nur noch 80/443 offen (App-Routes). 22 und 6443 sind zu. oc/helm/SSH laufen übers Tailnet (siehe Kasten). Klassisch mit Firewall-Regeln von deiner IP geht auch – dann $TailscaleHost = '' in sno.ps1.
  Ausnahme: der Hetzner-Jenkins (Jenkins → OKD) ist nicht im Tailnet – jenkins.ps1 stanzt daher beim up eine eigene 6443-Regel in okd-sno-fw und raeumt sie beim down wieder weg. Ein lokal betriebener Jenkins braucht das nicht.
• kubeadmin ist Voll-Admin – nach dem Einrichten eines eigenen Identity-Providers (htpasswd/OIDC) abschalten. Die kubeadmin-kubeconfig nicht weitergeben.
• SCOS updatet sich ueber den Cluster (oc adm upgrade) – kein dnf auf dem Node.
• SSH zum Node nur als core mit Key.

VER=$(curl -fsSL 'https://pkgs.tailscale.com/stable/?mode=json' | grep -oE '"Version":"[0-9.]+"' | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')
curl -fsSL -o /tmp/ts.tgz "https://pkgs.tailscale.com/stable/tailscale_${VER}_amd64.tgz"
sudo tar xzf /tmp/ts.tgz -C /tmp
cd /tmp/tailscale_${VER}_amd64
sudo install -m 0755 tailscale tailscaled /usr/local/bin/
sudo sed 's#/usr/sbin/tailscaled#/usr/local/bin/tailscaled#' systemd/tailscaled.service | sudo tee /etc/systemd/system/tailscaled.service >/dev/null
sudo cp systemd/tailscaled.defaults /etc/default/tailscaled
# sudo hat /usr/local/bin nicht im PATH -> ergaenzen (SCOS-minimal):
echo 'Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"' | sudo tee /etc/sudoers.d/10-localpath >/dev/null
sudo systemctl daemon-reload && sudo systemctl enable --now tailscaled
sudo /usr/local/bin/tailscale up --ssh --hostname sno   # druckt Login-URL

+ Grenzen & andere Wege

• Keine HA (Hochverfügbarkeit). Ein Node = ein Ausfallpunkt. Fuer „echt betreiben“ der mehrknotige OKD-Cluster (Stufe 4).
• RAM statt CPU (Central Processing Unit) ist der Engpass. OKD selbst belegt ~11 GB (CPU < 1 Kern im Leerlauf). cpx42 (16 GB) reicht nur fuer OKD leer, Vorgabe ist darum cpx52 (24 GB). Mit einem ganzen Projekt-Stack (Beispiel: ~15,6 GB gesamt) ist cpx52 knapp bequem, ccx33/cpx62 entspannt.
• Nur Kubernetes, ohne OpenShift-Schicht: die k3s-Anleitung – leichter, schneller, ~512 MB (Megabyte) Overhead.
• Nur oc ueben, kostenlos: die Developer Sandbox (Stufe 0) – gehostetes OpenShift von Red Hat, kein Server.
• nip.io hatte schon laengere Ausfaelle. Fuer mehr als ein Lab eine echte Wildcard-Domain (*.apps.sno.deine-domain) auf die feste IP zeigen lassen.