SNO, CRC und Deploy-Weg praktisch einordnen

1 Drei Orte, zwei Cluster, ein Deploy-Weg

CRC und SNO sind zwei getrennte OpenShift-Cluster. Git und Jenkins stehen außerhalb beider Cluster und liefern nur Quelltext, Images und Manifeste.

2 Die Sicherheitsgrenze dieses Labs

Die folgenden Prüfungen starten keinen Cluster, erzeugen keinen Hetzner-Server und führen keinen Deploy aus.

3 Verfügbare Werkzeuge inventarisieren

$names = 'oc','crc','hcloud','tailscale','podman','git','wsl'
$names | ForEach-Object {
  $command = Get-Command $_ -ErrorAction SilentlyContinue
  [pscustomobject]@{
    Werkzeug = $_
    Gefunden = [bool]$command
    Pfad = if ($command) { $command.Source } else { '-' }
  }
} | Format-Table -AutoSize

Ein fehlender Befehl bedeutet nur, dass dieser Teil auf dem aktuellen Laptop nicht geprüft werden kann. Es sagt nichts über den Zustand des entfernten Clusters aus.

.\scripts\sno.ps1 status
crc status
podman machine list
tailscale status

scripts/sno.ps1 ist der sichere Einstieg für den Hetzner-SNO. Die Aktion status liest Server-, Snapshot- und Erreichbarkeitszustand, ohne den Server anzulegen.

4 Den aktiven OpenShift-Cluster eindeutig erkennen

Kontext bedeutet die Kombination aus Clusteradresse, Benutzer und Standard-Namespace in der lokalen Kubeconfig.

oc config current-context
oc whoami
oc whoami --show-server
oc get clusterversion version -o custom-columns=VERSION:.status.desired.version,CHANNEL:.spec.channel
oc get infrastructure cluster -o custom-columns=PLATFORM:.status.platformStatus.type,CONTROL-PLANE:.status.controlPlaneTopology,INFRA:.status.infrastructureTopology
oc get ingress.config.openshift.io cluster -o jsonpath='{.spec.domain}{"\n"}'
oc get nodes -o custom-columns=NAME:.metadata.name,ROLES:.metadata.labels,EFFECTIVE-OS:.status.nodeInfo.osImage,KERNEL:.status.nodeInfo.kernelVersion

Wenn mehrere Kontexte vorhanden sind, verwende für Vergleiche oc --context <name> get …. Das ist sicherer als den globalen aktuellen Kontext umzuschalten.

5 Den SNO-Aufbau aus Skript und Ist-Zustand ableiten

Single-Node OpenShift, kurz SNO, vereint Steuerungsebene und Anwendungs-Workloads auf einem Node. Der Hetzner-Weg dieses Repositorys nutzt das Rescue-System als Sprungbrett zu SCOS.

Select-String -LiteralPath .\scripts\sno.ps1 -Pattern 'Rescue|ReservedIP|TailscaleHost|Invoke-Install|wait-for'
Select-String -LiteralPath .\scripts\sno-wsl.sh -Pattern 'bootstrap-in-place|wait-for|install-config'
Select-String -LiteralPath .\scripts\sno-kexec.sh -Pattern 'kexec|config.ign|initramfs'
.\scripts\sno.ps1 status

SCOS bedeutet CentOS Stream CoreOS und ist das unveränderliche Node-Betriebssystem von OKD. Bei OpenShift Container Platform übernimmt RHCOS, Red Hat Enterprise Linux CoreOS, diese Rolle. „Unveränderlich“ bedeutet hier, dass Node-Konfiguration über deklarierte Clustermechanismen statt durch manuelles Paketinstallieren gepflegt wird.

oc whoami --show-server
oc get nodes -o custom-columns=NAME:.metadata.name,ROLES:.metadata.labels,OS:.status.nodeInfo.osImage
oc get clusterversion version
oc get clusteroperator
oc get machineconfigpool

6 CRC als lokalen Cluster vermessen

CRC ist das Upstream-Werkzeug hinter Red Hat OpenShift Local. Es stellt einen vollständigen OpenShift-Single-Node in einer lokalen VM für Entwicklung und Lernen bereit.

crc status
crc config view
crc ip
oc config get-contexts

$crcContexts = @(oc config get-contexts -o name | Where-Object { $_ -match 'crc' })
$crcContext = $crcContexts | Where-Object { $_ -match 'admin' } | Select-Object -First 1
if (-not $crcContext) { $crcContext = $crcContexts | Select-Object -First 1 }
if (-not $crcContext) { throw 'Kein CRC-Kontext in der Kubeconfig gefunden.' }

oc --context $crcContext whoami --show-server
oc --context $crcContext get nodes -o wide
oc --context $crcContext get clusteroperator

crc status
crc config view
crc ip
oc config get-contexts

crc_context=$(oc config get-contexts -o name | grep 'crc' | grep 'admin' | head -1)
test -n "$crc_context" || crc_context=$(oc config get-contexts -o name | grep 'crc' | head -1)
test -n "$crc_context" || { printf 'Kein CRC-Kontext gefunden.\n' >&2; exit 1; }

oc --context "$crc_context" whoami --show-server
oc --context "$crc_context" get nodes -o wide
oc --context "$crc_context" get clusteroperator

crc status unterscheidet VM, OpenShift und Disk-Nutzung. crc config view zeigt die lokal gewählten CPU-, RAM- und Disk-Werte. Wenn CRC gestoppt ist, bleibt diese Konfiguration lesbar, Clusterabfragen schlagen aber erwartbar fehl.

7 Ein-Node-Grenzen am Cluster beweisen

oc get nodes -L node-role.kubernetes.io/master,node-role.kubernetes.io/worker
oc get storageclass
oc get volumesnapshotclass
oc get machineconfigpool
oc get clusteroperator monitoring
oc get pods -A -o wide

Wenn oc get volumesnapshotclass meldet, dass dieser Ressourcentyp unbekannt ist, ist die Snapshot-API nicht installiert. Eine leere Liste bedeutet dagegen, dass die API existiert, aber keine Klasse angeboten wird.

8 Den Tailscale-Pfad zur SNO prüfen

Tailscale bildet ein privates Overlay-Netz, Tailnet genannt. MagicDNS ordnet seinen Geräten stabile Namen zu. Die OpenShift-API behält trotzdem ihren Zertifikatsnamen.

tailscale status
$apiUri = [Uri](oc whoami --show-server)
$apiHost = $apiUri.Host
"API-Name: $apiHost"
Resolve-DnsName $apiHost
Test-NetConnection $apiHost -Port 6443
Get-Content -LiteralPath "$env:WINDIR\System32\drivers\etc\hosts" |
  Select-String -SimpleMatch $apiHost

Der Eintrag in C:\Windows\System32\drivers\etc\hosts ist wichtig, wenn der öffentliche nip.io-Name lokal auf die private Tailscale-IP zeigen soll. Der Name bleibt gleich, damit die Subject Alternative Names, kurz SANs, im API-Zertifikat passen.

9 Den lokalen Jenkins und seine Engine finden

Jenkins läuft hier als Container in der Podman-Maschine. Die Maschine stellt Linux auf Windows bereit, der Jenkins-Container orchestriert die Pipeline und die Host-Engine baut die Images.

podman machine list
podman system connection list
podman ps --filter name=shared-jenkins --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
podman port shared-jenkins
podman stats shared-jenkins --no-stream

Wenn die Podman-Maschine gestoppt ist, kann podman ps keine Container liefern. Das ist ein klarer Schichtfehler vor Jenkins und kein OpenShift-Problem.

10 Das Ergebnis eines Deploys im Cluster verfolgen

Die Pipeline ist erst bewiesen, wenn Commit, Image und laufender Pod zusammenpassen. Diese Abfragen starten keinen Build.

Im Anwendungs-Repository

git remote get-url origin
git branch --show-current
git rev-parse --short HEAD
git status --short

Im Zielcluster

oc whoami --show-server
oc get namespace library
oc -n library get deployment -o custom-columns=NAME:.metadata.name,READY:.status.readyReplicas,IMAGE:.spec.template.spec.containers[*].image
oc -n library get replicaset --sort-by=.metadata.creationTimestamp
oc -n library get pod -o wide
oc -n library get route
oc -n library get serviceaccount pipeline
oc get route default-route -n openshift-image-registry

Ein laufender Pod beweist nur den letzten Abschnitt. Die Zuordnung zum Commit gelingt über den verwendeten Image-Tag oder besser über Digest und Build-Metadaten. Fehlt diese Verbindung, ist der Rollout technisch erfolgreich, aber nicht vollständig nachvollziehbar.

11 Für jede Frage die kleinste passende Umgebung wählen

12 Dateien und Herkunft sauber trennen

13 Fehler zuerst der richtigen Schicht zuordnen

Die Reihenfolge verhindert, dass ein Tunnelproblem im Deployment gesucht oder ein falscher Kontext als fehlgeschlagener Rollout interpretiert wird.

14 Lernkontrolle

• Ich kann CRC und Hetzner-SNO anhand von API-Adresse, Domain und lokalem Status unterscheiden.
• Ich kann erklären, warum Rescue, kexec, SCOS, Ignition und Bootstrap nacheinander nötig sind.
• Ich kann Ein-Node-Grenzen von fehlenden OpenShift-Funktionen unterscheiden.
• Ich kann DNS-Auflösung, Tailscale-Verbindung und API-Port getrennt prüfen.
• Ich kann lokalen Jenkins, Podman-Engine und Zielcluster als drei getrennte Schichten diagnostizieren.
• Ich kann einen laufenden Pod über Image, Deployment und Pipeline bis zu einem Git-Commit zurückverfolgen.