OpenShift 4.18 – Installationsvorbereitung Disconnected

Überblick: Zweck des Formulars

Bei einer Disconnected-Installation gibt es kein Internet als Rückfallebene. Alles, was der Cluster braucht, muss der Kunde vorher bereitstellen – das Formular sammelt genau diese Punkte ein.

Warum die Vorbereitung hier alles ist

Bei einer connected Installation zieht sich OpenShift Images, Updates und Kataloge selbst aus dem Internet. Disconnected fällt das weg: DNS, NTP, Registry, Zertifikate und Zugangsdaten müssen vor dem Installationstermin stehen und getestet sein. Das Formular ist deshalb zweigeteilt – der Kunde füllt aus bzw. hakt ab, der System Engineer (SE) prüft technisch und gibt frei.

AusfüllenKunde trägt Eckdaten, Nodes, Netzwerk und Registry ein (Abschnitte B–H des Formulars).
AbhakenKunde bestätigt getestete Voraussetzungen: DNS in beide Richtungen, NTP erreichbar, Reservierungen angelegt.
FreigebenSE prüft technisch, beide unterschreiben (Abschnitt M) – erst dann steht der Installationstermin.

Die Clusterdomain als Fundament

Aus Cluster-Name und Base Domain entsteht die Clusterdomain: <Cluster-Name>.<Base Domain>, z. B. mycluster.myorg.com. Alle DNS-Records in Abschnitt 3 leiten sich daraus ab – wer diese beiden Werte spät ändert, muss DNS, Zertifikate und Konfiguration neu machen.

api.mycluster.myorg.com api-int.mycluster.myorg.com *.apps.mycluster.myorg.com

Clusterdomain = Straßenname – alle Hausnummern (DNS-Records) hängen daran. Wird die Straße umbenannt, stimmt keine einzige Adresse mehr.

Cluster-Eckdaten: Topologie, Methode, Umgebung

Drei Entscheidungen bestimmen den gesamten Rest: Wie viele Nodes, welche Installationsmethode, wie disconnected ist die Umgebung wirklich.

Topologie

Variante	Nodes	Wofür
Single-Node (SNO)	1	Edge, kleine Standorte – keine Redundanz
Compact	3	Master und Worker auf denselben drei Nodes
Standard-HA	3 + n	3 Master plus separate Worker

Achtung: Bei SNO ist während eines Updates der gesamte Cluster inkl. Workloads nicht verfügbar – ein Node, ein Reboot. Das muss der Kunde vor der Topologie-Entscheidung wissen, nicht beim ersten Update.

Installationsmethode

Agent-based Installer – Empfehlung, disconnected-fähig
Manuell / UPI – Boot-Image, PXE, maximale Kontrolle
Assisted Installer – Web-UI, aber nur connected
IPI – Full-stack Automation, braucht passende Plattform

Umgebung

Vollständig disconnected (air-gapped) – Transfer nur per Datenträger
Eingeschränkt – Proxy oder Bastion-Host mit Internetzugang spiegelt direkt in die lokale Registry

Die Antwort entscheidet über den Spiegel-Weg in Abschnitt 4.

Achtung: „Wir sind disconnected, aber der Assisted Installer wäre so bequem" – geht nicht. Der Assisted Installer braucht die Red-Hat-Cloud. Wer disconnected ist, landet beim Agent-based Installer oder UPI.

Hardware und Nodes

Pro Node eine Zeile im Formular: Hostname, Rolle, MAC, IP, Install-Disk. Jede dieser Angaben wird beim Boot wirklich gebraucht.

Was pro Node feststehen muss

Feld	Wozu
Hostname (FQDN)	Muss zu den DNS-Records aus Abschnitt 3 passen
Rolle	master oder worker
MAC-Adresse	Für DHCP-Reservierungen bzw. Node-Zuordnung im Installer
IP-Adresse	Fest – per DHCP-Reservierung oder statisch
Install-Disk	Ziel-Device für RHCOS, z. B. `/dev/sda`

SNO-Minimum laut Formular: 8 vCPU, 16 GiB RAM, 120 GiB Disk.

Achtung: Die Install-Disk wird beim Schreiben von RHCOS überschrieben. Bei Nodes mit mehreren Platten zeigt ein falsches Device (/dev/sda statt /dev/sdb) auf die falsche Platte – die Installation läuft trotzdem sauber durch, nur eben auf dem falschen Datenträger.

Hinweis: Am Installationstag muss Boot per ISO oder PXE über Remote-Konsole/BMC möglich sein – das gehört zur Checkliste in Abschnitt 6, wird aber gern vergessen, weil es „nur" Hardware-Zugang ist.

Netzwerk, DNS und Zeit

Diese Dienste müssen vor der Installation stehen – der Installer richtet sie nicht ein, er setzt sie voraus.

Netzwerk-Basisdaten

Machine-Network (CIDR), Default Gateway, ggf. VLAN
DNS-Server und NTP-Server (IP bzw. FQDN) – NTP muss von allen Cluster-Nodes erreichbar sein
IP-Vergabe: DHCP mit statischen MAC-Reservierungen (Empfehlung) oder statisch per Nmstate

Falls DHCP: Reservierungen für alle Nodes aus Abschnitt 2 müssen vor dem Termin angelegt sein.

Die drei Pflicht-Records

Record	Zweck
api.<cluster>.<domain>	Kubernetes-API, extern und intern erreichbar
api-int.<cluster>.<domain>	Interne API, von allen Cluster-Nodes erreichbar
*.apps.<cluster>.<domain>	Wildcard für Ingress/Routen – Console und Apps

Dazu kommen A-Records für alle Nodes (Forward) und PTR-Records in der Reverse-Zone. Beides ist Pflicht, beides muss vor dem Termin mit dig/nslookup in beide Richtungen getestet sein.

Achtung: Die Reverse-Zone ist der Klassiker unter den stillen Fehlern. Ohne PTR-Records bootet erstmal alles – aber die Nodes bekommen u. a. ihre Hostnamen über PTR gesetzt, und die Auflösung wird für TLS genutzt. Symptome zeigen sich erst später und sehen nach allem Möglichen aus, nur nicht nach DNS.

Forward-Zone = Telefonbuch, Reverse-Zone = Rückwärtssuche – der Cluster braucht beide Richtungen. Nur Namen nachschlagen können reicht nicht, er muss auch zur Nummer den Namen finden.

Lokale Registry und Mirror-Host

Die lokale Registry ersetzt die Red-Hat-Registries im Internet. Ohne sie gibt es keine Images – sie ist das Herzstück jeder Disconnected-Installation.

Registry klären

Produkt und URL – Quay, Harbor, mirror-registry o. ä.; vorhanden, vom Kunden bereitgestellt oder vom SE aufzusetzen
Speicherplatz – mindestens 32 GiB für die Plattform, mit Operator-Katalogen je nach Auswahl bis ~900 GiB
Zertifikat – kommt das Registry-Zertifikat von einer firmeneigenen CA, muss das CA-Zertifikat dem SE bereitgestellt werden (additionalTrustBundle)
Zugangsdaten – Push und Pull, Übergabe über sicheren Kanal (Passwort-Manager, verschlüsselte Mail)

Achtung: „32 GiB reichen" stimmt nur für die nackte Plattform. Wer Operator-Kataloge spiegelt, liegt schnell im dreistelligen GiB-Bereich – bis ~900 GiB. Läuft die Registry beim Spiegeln voll, bricht der Mirror-Vorgang mittendrin ab und der Installationstermin platzt.

Spiegel-Weg

Bastion-Host – hat Internet und Zugriff auf die Registry, spiegelt direkt
Air-gapped – mirror-to-disk auf einen Datenträger, dann physischer Transfer

Im Formular festhalten: Bastion-/Mirror-Host (Hostname/IP, OS) und wer den Transfer verantwortet – Kunde oder SE.

Zugänge

Red-Hat-Pull-Secret – von console.redhat.com, vorhanden oder vom SE mitgebracht
SSH-Public-Key des SE – darf auf den Cluster-Nodes hinterlegt werden (sshKey)

Registry = Vorratskammer – disconnected liefert kein Supermarkt mehr. Was am Installationstag nicht in der Kammer liegt, kann nicht gekocht werden; und die Kammer muss groß genug für den ganzen Einkauf sein.

Firewall, LDAP und Betrieb

Erreichbarkeiten für den Installationstag, optionale LDAP-Anbindung ab Day 1 und die Absprachen für den späteren Betrieb.

Firewall-Freigaben

Verbindung	Port
Alle Nodes → lokale Registry	443 bzw. registrierter Port
Admin-Workstation SE → API-Endpunkt	6443
SE → Nodes (während der Installation)	22 (SSH)
Cluster → LDAP-Server (falls LDAP)	636 (LDAPS) bzw. 389

Besonderheiten wie Proxy, spezielle Freigabeprozesse oder Sicherheitsauflagen (z. B. BSI) gehören ins Formular – vor dem Termin, nicht als Überraschung währenddessen.

Optional: LDAP-Anbindung ab Day 1

Nur relevant, wenn Benutzer-Login über LDAP/IdM gewünscht ist. Der Service-Account braucht ausschließlich Leserechte – mehr Rechte sind ein unnötiges Risiko.

LDAP-Server (FQDN) und Port – Standard LDAPS: 636
Base-DN – Benutzer-Suchbasis
Bind-DN des Service-Accounts, Passwort über sicheren Kanal
Login-Attribut – meist uid
CA-Zertifikat des LDAP-Servers wird bereitgestellt

Updates und Wartung

Wartungsfenster festlegen (z. B. Sa 22–02 Uhr) und klären, wer Updates verantwortet – Kunde, SE oder gemeinsam
etcd-Backups brauchen einen externen Ablageort – ein Backup, das nur auf dem Cluster liegt, ist keins
Updates disconnected: entweder lokaler OpenShift Update Service (OSUS) oder manuelle Updates per Digest

Hinweis: Ohne OSUS zeigt die Console keinen Update-Pfad an – manuelle Updates per Digest sind der Normalfall im Disconnected-Betrieb, kein Fehlerbild.

Checkliste vor dem Installationstermin

Die Punkte aus dem Formular in sinnvoller Reihenfolge. Alles muss abgehakt sein, bevor der Termin bestätigt wird – die Unterschrift beider Seiten macht es verbindlich.

Die drei Phasen auf einen Blick

Phase A · FestlegenSchritte 1–2: Eckdaten und Hardware final.
Phase B · BereitstellenSchritte 3–5: DNS, Netzwerk und Registry stehen und sind getestet.
Phase C · ÜbergebenSchritte 6–7: Zugänge sicher übergeben, Freigabe unterschreiben.

Phase A · Festlegen

Schritt 1 · Formularabschnitte B–H vollständig und geprüft

Cluster-Name, Base Domain und Zielversion sind das Fundament – spätere Änderungen ziehen DNS und Zertifikate nach sich. Topologie und Methode müssen zur Umgebung passen (disconnected → Agent-based oder UPI).

Schritt 2 · Hardware steht, Boot per ISO/PXE möglich

Pro Node: Hostname, Rolle, MAC, IP, Install-Disk. Zusätzlich muss der Zugang über Remote-Konsole/BMC funktionieren – ohne Boot-Möglichkeit beginnt die Installation gar nicht erst.

Phase B · Bereitstellen

Schritt 3 · DNS-Records angelegt und in beide Richtungen getestet

api, api-int, *.apps plus A- und PTR-Records aller Nodes. Der Test in beide Richtungen ist der wichtigste Einzelpunkt der ganzen Liste – fehlende PTR-Records fallen sonst erst nach der Installation auf.

# Forward und Reverse für jeden Node prüfen
dig api.mycluster.myorg.com
dig -x <node_ip>

Schritt 4 · NTP erreichbar, IP-Vergabe final

Der lokale NTP-Server muss von allen Cluster-Nodes erreichbar sein – ohne saubere Zeit scheitern Zertifikatsprüfungen. DHCP-Reservierungen bzw. statische IP-Daten sind final, keine „klären wir noch"-Einträge.

Schritt 5 · Registry erreichbar, Speicherplatz und CA geklärt

Alle Nodes erreichen die Registry auf Port 443. Speicherplatz ist gegen die Operator-Auswahl gerechnet (32 GiB bis ~900 GiB), das CA-Zertifikat liegt dem SE vor. Der Spiegel-Weg (Bastion oder mirror-to-disk) ist entschieden und der Transfer-Verantwortliche benannt.

Phase C · Übergeben

Schritt 6 · Zugangsdaten und Pull-Secret sicher übergeben

Registry-Credentials, Pull-Secret und ggf. LDAP-Service-Account-Passwort gehen über den vereinbarten sicheren Kanal – nie per unverschlüsselter Mail. Der SSH-Key des SE ist zur Hinterlegung freigegeben.

Schritt 7 · Freigabe unterschreiben

Kunde bestätigt die Richtigkeit der Angaben, SE die technische Prüfung (Abschnitt M des Formulars). Offene Punkte und Abweichungen stehen in den Bemerkungen – nicht im Kopf einzelner Beteiligter.

Achtung: Ein Termin mit „das DNS machen wir am Morgen der Installation fertig" ist kein vorbereiteter Termin. Alles auf dieser Liste ist Voraussetzung, nichts davon ist Tagesgeschäft des Installationstags.