OpenShift Disconnected – Der Fahrplan (DO0032

Grundlagen: Wie OpenShift installiert wird

Bevor du losbaust: Der Installer ist „opinionated“ – er nimmt dir Entscheidungen ab und baut nach Best Practices. Angepasst wird danach (Day 2), nicht während der Installation.

Der Bootstrap-Prozess in 8 Schritten

Bild: Der Bootstrap-Node ist das Baugerüst – er hält alles, bis die echte Control-Plane steht, und wird dann abgerissen.

Konfiguration liefernDu gibst die install-config.yaml vor.
Ignition-Dateien generierenDer Installer erzeugt sie für Bootstrap-, Control-Plane- und Compute-Nodes.
Bootstrap-Node bootenMit der Bootstrap-Ignition-Konfiguration.
Temporäre Control-PlaneDer Bootstrap-Node startet ein provisorisches Kubernetes.
Control-Plane-Nodes bootenSie holen ihre Ignition-Konfig vom Bootstrap-Node.
etcd formiert sichDie Control-Plane-Nodes treten bei und bilden den permanenten etcd-Cluster.
Übergabe & AbrissBootstrap übergibt an die permanente Control-Plane und fährt herunter.
Compute-Nodes beitretenBooten, Konfig holen, Cluster beitreten.

Ignition läuft beim allerersten Boot der RHCOS-Maschinen: formatiert Disks, schreibt Dateien, konfiguriert systemd-Units.

RHCOS vs. RHEL als Node-OS

	RHCOS	RHEL
Control-Plane	Pflicht	nicht unterstützt
Compute	Standard	möglich (ab 8.8, als Day-2)
OS-Updates	automatisch & atomar via MCO	Admin macht's selbst
Wofür	immutable, cluster-verwaltet	eigene Kernel-Module, non-containerized Agents

RHCOS = Mietwohnung (der Cluster renoviert für dich), RHEL = Eigenheim (volle Freiheit, aber du streichst selbst).

Topologien

Topologie	Aufbau	Einsatz
Standard-HA	3 Control-Plane + ≥ 2 Compute	Produktion, HA, getrennte Rollen
Compact	3 Nodes = Control-Plane und Compute	wenig Hardware, trotzdem HA
Single-Node (SNO)	1 Server für alles	Edge: wenig Platz & Strom

Disconnected heißt immer: lokale Registry + oc-mirror (→ Etappe 1).

Die vier Installationswege

Methode	Kern-Idee	Wann
Assisted Installer	Web-UI auf console.redhat.com, Discovery-ISO, Prüfung der Voraussetzungen online	connected; Bare Metal, Nutanix, vSphere (Red-Hat-Empfehlung)
Agent-based Installer	CLI baut ein autonomes Boot-ISO, keine Console nötig	Bare Metal, Edge, disconnected (→ Etappe 3)
Full-stack Automation (IPI)	Installer baut die Infrastruktur selbst (VMs, LB, DNS) über die Plattform-API	Cloud (AWS/Azure/GCP), vSphere, OpenStack
Pre-existing Infrastructure (UPI)	Du baust Netz, DNS, LB, Maschinen – der Installer liefert nur Ignition	Spezial-Anpassungen, strenge Compliance

IPI = „Installer Packt's Ich-mach-alles“, UPI = „User Packt's Immer-selbst“. Gemeinsam bleibt nur: Ignition erzeugt immer der Installer.

IPI vs. UPI im Detail

Aufgabe	IPI	UPI
Netzwerk, Load Balancer, DNS	Installer	User
Hardware/VMs provisionieren, OS installieren	Installer	User
Ignition-Dateien	Installer	Installer
Compute-OS	RHCOS	RHCOS oder RHEL
Registry-Storage / dynamischer Storage-Provider	Installer (außer Bare Metal)	User
Node-Provisioning & Autoscaling	Installer	nur mit Machine-API-Integration (Bare Metal: nein)

Managed-Angebote (falls du gar nicht selbst installieren willst)

Red Hat OpenShift Service on AWS – vollständig verwaltet, native AWS-Integration, Pay-as-you-go, eigenes CLI
Microsoft Azure Red Hat OpenShift – gemeinsam von Microsoft & Red Hat betrieben
Red Hat OpenShift on IBM Cloud – managed auf IBM Cloud
Red Hat OpenShift Dedicated – von Red Hat betrieben auf AWS oder GCP

Control-Plane- und Infrastruktur-Betrieb liegen bei Red Hat/Cloud-Provider – du kümmerst dich um Apps.

Disconnected-Installation vorbereiten

Ohne Internet muss alles, was der Cluster braucht, vorher in dein Netz: Images in eine lokale Registry, CLI-Tools auf die Workstation, Infrastrukturdienste ins Netz.

Die drei Baustellen im Überblick

Images spiegelnRelease-Images, Operator-Kataloge und Zusatz-Images per oc-mirror (v2) in eine lokale Registry bringen.
Tools bereitstellenoc, openshift-install, butane, coreos-installer + RHCOS-Live-ISO herunterladen.
Infrastruktur aufsetzenNTP, DHCP und DNS im disconnected Netz konfigurieren – ohne sauberes DNS keine Installation.

Spiegeln mit oc-mirror v2

Bild: Die Registry ist dein lokaler Supermarkt. oc-mirror ist der LKW, der ihn von außen befüllt. Die ImageSetConfiguration ist der Einkaufszettel.

Registry wählenBestehende private Registry (z. B. Quay) für den Dauerbetrieb – oder die kleine „mirror registry for Red Hat OpenShift“ nur für die Installation.
oc-mirror installierenVon console.redhat.com oder mirror.openshift.com laden, nach /usr/local/bin legen.
Credentials bündelnPull-Secret nach ~/.docker/config.json kopieren, dann podman login --authfile für die lokale Registry – eine Datei, beide Registries.
Einkaufszettel schreibenImageSetConfiguration: Plattform-Channel + Versionsbereich, Operatoren, additionalImages (z. B. support-tools).
Spiegelnoc mirror --v2 ausführen – immer mit demselben --workspace, denn dort liegen Cache + Metadaten.

Platzbedarf: Plattform-Images ≈ 32 GiB. Alle Operatoren eines Releases ≈ 900 GiB. Alle Channels aller Kataloge: mehrere TiB. Filtern lohnt sich.

Befehle & Beispiel-Konfiguration

# Credentials zusammenführen
cp ~/Downloads/pull-secret ~/.docker/config.json
podman login --authfile ~/.docker/config.json -u myuser registry.example.com

# Was gibt es? (Releases / Kataloge auflisten)
oc-mirror list releases --version=4.18
oc-mirror list operators --catalogs --version=4.18

# Spiegeln (immer --v2, v1 ist deprecated)
oc mirror --v2 \
  --config image-set-config.yaml \
  --workspace file://mirror/ \
  docker://registry.example.com

kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v2alpha1
mirror:
  platform:
    channels:
    - name: stable-4.18
      type: ocp
      minVersion: 4.18.6
      maxVersion: 4.18.6
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.18
    packages:
    - name: openshift-gitops-operator
  additionalImages:
  - name: registry.redhat.io/rhel9/support-tools:latest

Ergebnis im Workspace: u. a. idms-oc-mirror.yaml (ImageDigestMirrorSet) – leitet später Pulls auf die lokale Registry um. Wiederholtes Ausführen spiegelt nur Neues (Cache).

Voll-air-gapped in drei Schritten: mirror-to-disk (online) → Transfer (Datenträger) → disk-to-mirror (offline in die Registry).

Werkzeugkiste

oc – Cluster installieren & verwalten
openshift-install – startet & überwacht die Installation
butane – baut aus Konfig-Dateien MachineConfigs (z. B. lokale NTP-Konfig)
coreos-installer – bettet Ignition in das RHCOS-Live-ISO ein
RHCOS-Live-ISO – das Boot-Medium für die Nodes
SSH-Key + Pull-Secret – Key kommt auf die Nodes; Pull-Secret enthält hier die Zugangsdaten der lokalen Registry

Infrastrukturdienste

NTP – lokale Zeitquelle (chrony), sonst kippen TLS-Zertifikate
DHCP – feste IPs per MAC-Reservierung (Red-Hat-Empfehlung statt Boot-Parametern)
DNS – Forward- und Reverse-Zone; PTR-Records setzen u. a. die Hostnamen

Pflicht-Records:

api.<cluster>.<domain> api-int.<cluster>.<domain> *.apps.<cluster>.<domain>

„A-A-A“: api (extern), api-int (intern), apps (Wildcard für Routen) – plus PTR für jeden Node.

Single-Node OpenShift manuell installieren

Der Weg über openshift-install + eigenes Boot-ISO. Die Pipeline ist immer dieselbe: install-config → Manifeste → Ignition → ISO → Boot.

Die 7 Schritte

Voraussetzungen erfüllenMirror, Tools, DNS/DHCP/NTP aus Etappe 1. SNO-Minimum: 8 vCPU, 16 GiB RAM, 120 GiB Disk.
Installationsverzeichnis anlegenmkdir ocp4-cluster – hier landet alles Generierte.
install-config.yaml schreiben1 Control-Plane, 0 Worker, bootstrapInPlace.installationDisk, plus Disconnected-Extras (siehe unten).
Manifeste generierenopenshift-install create manifests; eigene MachineConfigs (z. B. chrony via Butane) nach openshift/ legen.
Ignition erzeugencreate single-node-ignition-config → bootstrap-in-place-for-live-iso.ign.
ISO bauen & bootenIgnition mit coreos-installer iso ignition embed ins RHCOS-Live-ISO einbetten, Node davon starten (rebootet mehrfach).
Überwachen & prüfenopenshift-install wait-for install-complete, danach Health-Checks.

Zwei Fallen: Der Installer löscht die install-config.yaml beim Verarbeiten – vorher sichern. Und Ignition-Dateien sind nur 24 h gültig (Zertifikate) – bei Fehlschlag Verzeichnis löschen und aus dem Backup neu generieren.

„KIMII“ für die Pipeline: Konfig → Manifeste → Ignition → ISO → Installation.

Disconnected-Extras in der install-config.yaml

pullSecret – Zugangsdaten der lokalen Registry (nicht mehr das Red-Hat-Secret)
imageDigestSources – Mapping „Red-Hat-Registry → lokaler Mirror“; passt die Image-Quelle eines Pods, wird vom Mirror gezogen
additionalTrustBundle – CA-Zertifikat deiner Registry, damit der Cluster ihr vertraut

Beispiel install-config.yaml (SNO, disconnected)

apiVersion: v1
metadata:
  name: mycluster
baseDomain: myorg.com          # Clusterdomain: mycluster.myorg.com
bootstrapInPlace:
  installationDisk: /dev/sda
compute:
- name: worker
  replicas: 0
controlPlane:
  name: master
  replicas: 1
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork:
  - 172.30.0.0/16
  networkType: OVNKubernetes
platform:
  none: {}
sshKey: 'ssh-rsa AAAA...'
pullSecret: '{"auths":{"myregistry.example.com":{"auth":...}}}'
imageDigestSources:
- mirrors:
  - myregistry.example.com/openshift/release
  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
additionalTrustBundle: |
  -----BEGIN CERTIFICATE-----
  ...

Feld unklar? openshift-install explain installconfig.networking.serviceNetwork

Chrony-MachineConfig mit Butane

# chrony-master.bu
variant: openshift
version: 4.18.0
metadata:
  name: 99-master-chrony
  labels:
    machineconfiguration.openshift.io/role: master
storage:
  files:
  - path: /etc/chrony.conf
    mode: 0644
    overwrite: true
    contents:
      inline: |
        server 192.168.50.254 iburst
        driftfile /var/lib/chrony/drift
        makestep 1.0 3
        rtcsync

# konvertieren, direkt ins openshift/-Verzeichnis
butane chrony-master.bu --output ocp4-cluster/openshift/99_chrony_master.yaml

ISO bauen & Installation verfolgen

# ISO-URL herausfinden
openshift-install coreos print-stream-json | grep -F .iso

# Ignition einbetten
coreos-installer iso ignition embed --force \
  --ignition-file ocp4-cluster/bootstrap-in-place-for-live-iso.ign \
  --output sno.iso rhcos-...-live.x86_64.iso

# beobachten (startet nichts, schaut nur zu!)
openshift-install wait-for install-complete --dir ocp4-cluster --log-level debug

# parallel per oc
export KUBECONFIG=~/ocp4-cluster/auth/kubeconfig
watch 'oc get clusterversion; oc get clusteroperators; oc get nodes'
oc get events -A --field-selector 'type!=Normal' --watch

kubeconfig und kubeadmin-password liegen in ocp4-cluster/auth/ – Admin-Rechte, sicher verwahren.

Troubleshooting entlang der 5 Phasen

Bild: Der Node baut sich sein Haus selbst – erst Bauleitung im Zelt (temporäre Control-Plane), dann zieht er ins fertige Haus ein.

Phase	Was passiert	Debug-Werkzeug
Bootkube	`release-image`-Service zieht Images, `bootkube` startet die temporäre Control-Plane	SSH als `core` → `journalctl -b -f -u release-image.service -u bootkube.service`, `crictl pods`
Temp. Control-Plane	Manifeste werden verarbeitet, am Ende entsteht `master.ign`	weiter `journalctl`; remote: `openshift-install gather bootstrap`
RHCOS auf Disk	`install-to-disk` schreibt System + Ignition, Reboot	–
Konfig & Update	Ignition wird angewandt, MCO aktualisiert & rebootet	`podman ps` / `podman logs --latest` auf dem Node
Prod. Control-Plane	CVO installiert alle Operatoren	`oc adm node-logs --unit crio\|kubelet`, `oc debug node/…`

Typischer Fehler in Phase 1: Node kommt nicht an die Images (Auth/Netz zur Registry).

Health-Check nach der Installation

NTP – chronyc sources auf jedem Node (via oc debug node/…)
Nodes – alle Ready? oc get nodes · Metriken: oc adm top node
CSRs – nichts Pending: oc get csr | grep Pending
Version & Operatoren – oc get clusterversion / oc get clusteroperators (alle Available, nicht Degraded)
etcd – oc rsh -n openshift-etcd etcd-… → etcdctl endpoint health --cluster
API & Console – curl -k https://api…:6443/version, Console-Route per curl -kIs
Registry & Ingress – Deployments image-registry und router-default ready, Pods auf verschiedenen Nodes

Support-Daten sammeln (must-gather / sos)

oc adm must-gather --dest-dir must-gather-data
oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
tar cvaf must-gather-<datum>-<cluster-id>.tar.gz ./must-gather-data

# SOS-Report von Nodes (nutzt registry.redhat.io/rhel8/support-tools – vorher spiegeln!)
sos collect --no-local

SNO mit dem Agent-based Installer

Der bequemere Weg für Bare-Metal, Edge und disconnected: Alles steckt in einem bootfähigen ISO. Ein Node – der Rendezvous-Host – spielt Bauleiter und wird danach selbst Cluster-Node.

Manuell vs. Agent-based

	Manuell	Agent-based
Bootstrap	eigener Bootstrap-Host (außer SNO)	in-place: Rendezvous-Host wird Cluster-Node
Konfig-Dateien	install-config + Ignition	install-config + agent-config
Netzwerk	meist DHCP / manuell	deklarativ per Nmstate – ideal für statische IPs
Medium	RHCOS-ISO + Ignition selbst kombinieren	ein generiertes `agent.x86_64.iso`
Orchestrierung	bootkube	assisted-Service (Podman-Pod) + agent (systemd) auf jedem Node

Ablauf

install-config.yaml anpassenWie in Etappe 2, aber: kein bootstrapInPlace, dafür networking.machineNetwork (bei SNO die Node-IP als /32).
agent-config.yaml schreibenrendezvousIP (bei SNO = Node-IP), additionalNTPSources, hosts mit rootDeviceHints, Interfaces und Nmstate-networkConfig.
Optional: Custom-ManifesteMachineConfigs (z. B. chrony) ins openshift/-Unterverzeichnis.
ISO bauenopenshift-install agent create image --dir ocp4-cluster → agent.x86_64.iso.
Booten & zurücklehnenNode(s) vom ISO starten; assisted-Service validiert, installiert, rebootet – vollautomatisch.

Merke: additionalNTPSources gilt nur für die Live-Umgebung während der Installation. Für den fertigen Cluster brauchst du weiterhin die chrony-MachineConfig.

Rendezvous = Treffpunkt: Alle Agents „treffen sich“ beim Rendezvous-Host, der die Installation dirigiert – und am Ende selbst beitritt.

Beispiel agent-config.yaml (mit statischem Netz)

apiVersion: v1alpha1
kind: AgentConfig
metadata:
  name: agent-sno
rendezvousIP: 192.168.50.10
additionalNTPSources:
- 192.168.50.254
hosts:
- hostname: master02
  rootDeviceHints:
    deviceName: /dev/sda
  interfaces:
  - name: eth0
    macAddress: 52:54:00:00:32:0a
  networkConfig:              # Nmstate-Format
    interfaces:
    - name: eth0
      type: ethernet
      state: up
      mac-address: 52:54:00:00:32:0a
      ipv4:
        enabled: true
        address:
        - ip: 192.168.50.10
          prefix-length: 24
        dhcp: false
    dns-resolver:
      config:
        server:
        - 192.168.50.254
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: 192.168.50.254
        next-hop-interface: eth0

Die Phasen bei Multi-Node (3 Master)

Boot & Preflight – alle Nodes booten vom ISO, konfigurieren ihr Netz, prüfen den Registry-Zugriff; Agents melden Hardware an den assisted-Service.
Temporäre Control-Plane – Rendezvous-Host startet sie; alle anderen Nodes schreiben RHCOS auf Disk und rebooten.
Beitritt – die Nodes bilden den Cluster; zuletzt rebootet der Rendezvous-Host selbst und wird regulärer Control-Plane-Node.

Compute-Nodes per PXE hinzufügen

SNO nachträglich erweitern – ohne ISO anstecken, rein übers Netz. Empfehlung: max. 2 Worker, sonst überfordert die Ein-Node-Control-Plane.

Die vier Netzwerkdienste für PXE

Dienst	Rolle
DHCP	IP + Verweis auf TFTP-Server (`next-server`) und Bootloader (`filename`)
TFTP	liefert Bootloader + MAC-spezifische Boot-Konfig (`pxelinux.cfg/01-<mac>`)
HTTP	liefert die großen Dateien: Kernel, initramfs, rootfs, Ignition
DNS	neuer Node ↔ Cluster müssen sich gegenseitig auflösen (Forward + Reverse)

PXE-Staffellauf: DHCP gibt die Adresse, TFTP den Startschuss (Bootloader), HTTP trägt das Gepäck (Kernel/rootfs/Ignition), DNS kennt alle Namen.

Ablauf

Boot-Artefakte erzeugenopenshift-install agent create pxe-files --dir ocp4-cluster → Kernel, initrd, rootfs + Kernel-Parameter. Achtung: Wurde das Verzeichnis schon fürs ISO benutzt, sind die Konfig-Dateien weg → frisches Verzeichnis mit den Originaldateien.
Worker-Ignition aus dem Cluster ziehenLiegt als Secret worker-user-data-managed in openshift-machine-api: oc extract … --keys userData --to - > compute.ign
DHCP + DNS ergänzenStatische Reservierung (MAC → IP, Hostname, Domain) und Forward-/Reverse-Records für den neuen Node.
Artefakte auf Webserver, TFTP-Konfig anlegenDatei pxelinux.cfg/01-<mac-mit-bindestrichen> („01“ = ARP-Typ Ethernet), verweist per HTTP auf Kernel, initrd, rootfs, compute.ign und Zieldisk.
BootenMaschine startet: DHCP → TFTP-Bootloader → Downloads via HTTP → RHCOS-Install mit Ignition → Reboot → Beitrittsversuch.
2 CSRs genehmigenoc get csr → oc adm certificate approve <csr> … – manueller Sicherheits-Check, ohne den kein Beitritt.
Prüfenoc get nodes – neuer Node Ready mit Rolle worker.

Warum zwei CSRs? ① Client-Zertifikat: Kubelet darf mit dem API-Server reden (registrieren, Heartbeats, Pod-Status). ② Serving-Zertifikat: der API-Server darf mit dem Kubelet reden (Logs, exec, Port-Forward, Metriken). Merksatz: erst reden dürfen, dann angesprochen werden.

Beispiel: dhcpd.conf + PXE-Boot-Datei

# /etc/dhcp/dhcpd.conf – Reservierung
subnet 192.168.50.0 netmask 255.255.255.0 {
  next-server 192.168.50.254;
  filename "pxelinux.0";
  host compute01.mycluster.myorg.com {
    hardware ethernet 52:54:00:00:32:0D;
    fixed-address 192.168.50.13;
    option host-name "compute01";
    option domain-name "mycluster.myorg.com";
  }
}

# /var/lib/tftpboot/pxelinux.cfg/01-52-54-00-00-32-0d
DEFAULT pxeboot
TIMEOUT 20
PROMPT 0
LABEL pxeboot
  KERNEL http://192.168.50.254/boot-artifacts/agent.x86_64-vmlinuz
  APPEND initrd=http://192.168.50.254/boot-artifacts/agent.x86_64-initrd.img \
    coreos.live.rootfs_url=http://192.168.50.254/boot-artifacts/agent.x86_64-rootfs.img \
    coreos.inst.ignition_url=http://192.168.50.254/compute.ign \
    coreos.inst.install_dev=/dev/sda \
    rw ignition.firstboot ignition.platform.id=metal

# Ignition extrahieren & CSRs freigeben
oc extract -n openshift-machine-api secret/worker-user-data-managed \
  --keys userData --to - > compute.ign
oc get csr
oc adm certificate approve csr-6wxpj csr-k7ckz
oc get nodes

Day-1: OLM lokal & LDAP-Login

Der Cluster läuft – jetzt anschließen: OperatorHub auf die lokale Registry umbiegen und echte Benutzer statt kubeadmin zulassen.

OLM für disconnected

Default-Kataloge abschaltenSonst versucht OLM vergeblich, ins Internet zu telefonieren.
Lokale CatalogSource anlegenZeigt auf das gespiegelte Index-Image – oc-mirror hat die YAML schon generiert.

oc patch OperatorHub cluster --type json \
  -p '[{"op":"add","path":"/spec/disableAllDefaultSources","value":true}]'

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: cs-redhat-operator-index-v4-18
  namespace: openshift-marketplace
spec:
  image: registry.example.com/redhat/redhat-operator-index:v4.18
  sourceType: grpc

Danach zeigt der OperatorHub in der Console nur noch lokal verfügbare Operatoren.

LDAP-Identity-Provider (z. B. IdM)

VorbereitenLDAP-FQDN, Base-DN, Attribut-Mapping, Netzweg (389/636), CA-Zertifikat des LDAP-Servers, Service-Account mit minimalen Rechten (+ dessen DN).
CA als ConfigMapoc create configmap idm-ca --from-file ca.crt=… -n openshift-config
Bind-Passwort als Secretoc create secret generic idm-bind-password --from-literal bindPassword=… -n openshift-config
OAuth-Ressource konfigurierenIdP-Name, Attribut-Mapping, bindDN, Verweise auf Secret + ConfigMap, LDAP-URL.
Warten & testenAuth-Operator rollt neu aus; der IdP erscheint als Option auf der Login-Seite.

Die LDAP-URL entschlüsselt

ldaps://host:636/basedn?attribut?scope?filter
        └─────┘ └────┘ └──────┘ └───┘ └────┘
         wo?    ab wo   Login-   wie   wen?
                suchen  Attribut tief  (optional)

„Wo – ab wo – wer – wie tief – wen“: Host, Base-DN, Login-Attribut (meist uid), Scope (sub/one), Filter. Beim Login baut OpenShift daraus (&(filter)(attribut=benutzername)).

Beispiel: OAuth-Spec für LDAP

spec:
  identityProviders:
  - name: my-idm                 # erscheint auf der Login-Seite
    mappingMethod: claim
    type: LDAP
    ldap:
      attributes:
        id: [dn]
        email: [mail]
        name: [cn]
        preferredUsername: [uid]
      bindDN: uid=rhocp-svc,cn=users,cn=accounts,dc=idm,dc=example,dc=com
      bindPassword:
        name: idm-bind-password
      ca:
        name: idm-ca
      insecure: false
      url: ldaps://idm.example.com:636/cn=users,cn=accounts,dc=idm,dc=example,dc=com?uid?sub?(uid=*)

Disconnected-Cluster updaten

Normalerweise fragt der Cluster den OpenShift Update Service (OSUS) im Internet nach gültigen Pfaden. Offline gibt es zwei Wege: einen lokalen OSUS betreiben – oder manuell updaten (hier beschrieben).

Die 6 Schritte zum manuellen Update

Update-Pfad prüfenUpdate-Graph-Tool (access.redhat.com/labs/ocpupgradegraph): Nicht jeder Sprung ist erlaubt – manchmal braucht es Zwischenversionen, manche darf man überspringen.
Ziel-Release spiegelnoc mirror --v2 mit ImageSet für die Zielversion; graph: true nur, wenn du einen lokalen OSUS betreibst.
Signatur-ConfigMap anwendenAus dem Workspace: signature-configmap.yaml – damit kann der Cluster das Release-Image verifizieren. Vor dem Update einspielen.
etcd sichernoc debug --as-root node/master01 → chroot /host → cluster-backup.sh /home/core/assets/backup; Backup extern ablegen.
PodDisruptionBudgets prüfenPDBs können das Node-Draining blockieren → mit den Entwicklern ein Update-Fenster planen, PDB ggf. temporär entfernen.
Update startenDigest aus der lokalen Registry holen, dann explizit updaten (siehe unten); Fortschritt via oc get clusterversion / clusteroperators oder Console → Cluster Settings.

SNO-Besonderheit: Beim Update ist der ganze Cluster samt Workloads offline – ein Node, ein Reboot, alles weg. Wartungsfenster einplanen.

„Pfad – Spiegel – Signatur – Sicherung – Budgets – Start“ – die sechs S-Stationen vor jedem Offline-Update (gut: erst 4× absichern, dann starten).

Befehle

# ImageSet für das Ziel-Release
kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v2alpha1
mirror:
  platform:
    channels:
    - name: stable-4.18
      type: ocp
      minVersion: 4.18.8
      maxVersion: 4.18.8
      graph: true      # nur für lokalen OSUS nötig (Default: false)

oc mirror --v2 --config image-set-config.yaml \
  --workspace file://mirror/ docker://registry.example.com

# Digest des gespiegelten Releases
oc adm release info -o 'jsonpath={.digest}{"\n"}' \
  myregistry.example.com/openshift/release-images:4.18.8-x86_64

# explizites Update auf das Image (per Digest!)
oc adm upgrade --allow-explicit-upgrade-to-image \
  myregistry.example.com/openshift/release-images@sha256:5098...2690