Nachfolgend etwas allgemeines Wissen über den OKD.

Grundsätzlich besteht ein OKD-Cluster aus den folgenden drei Rollen:

• Control Plane (Master)
  • kontrolliert den Cluster
• Worker (Nodes)
  • übernimmt die „Arbeit“ im Cluster
• Infrastructure (optional)
  • sinnvoll bei großen Umgebungen

OKD wird als Upstream von Red Hat OpenShift genutzt mit der Einschränkung, dass nur eine Version gepflegt werden darf. Zum Zeitpunkt der Dokumentationserstellung ist das Version 4.19. Nachdem Red Hat die neue Version 4.20 herausgebracht hat, wird auch OKD zeitnah auf die Version umstellen. Das bedeutet, dass eine baldige Aktualisierung ansteht.

Pods:

• Pods sind Container
• in der Regel beinhaltet eine Pod nur einen Container (wegen einer besseren Skalierbarkeit), er kann aber auch mehrere Container enthalten
• wenn ein Pods zum Beispiel einen Hilfsdienst braucht (zum Beispiel einen Connector), wird unter Umständen dieser Container zusätzlich zum Pod hinzugefügt

Service:

• ein Service ist kein Container
• werden benötigt, um einen Zugang zu den Pods zu erhalten
  • legt einen eindeutigen Namen für den Pod fest
  • definiert IP-Adressen und Ports für Zugriffe

Deployment (deployment.apps):

• siehe https://semaphore.io/blog/replicaset-statefulset-daemonset-deployments
• kann als Erweiterung vom Replica Set gesehen werden, weil es mehr Funktionen unterstützt
• Anleitung, wie der Pod gestartet werden soll

Replica Sets (replicaset.apps):

• siehe https://semaphore.io/blog/replicaset-statefulset-daemonset-deployments
• die kleinste Einheit ist ein Pod
• für die nächst größere Einheit (also mindestens zwei Instanzen vom Pod) wird ein Replica Set benötigt

Daemon Sets (daemonset.apps):

• oc apply
• oc patch <yaml-Datei>
• oc remove

• Home
  • Overview: Dashboard
  • Projects: Projekte (für jedes Projekt wird auch gleichzeitig ein Namenraum erstellt)
• Operators
  • OperatorHub: Operatoren, die installiert werden können (Market Place)
  • Installed Operators: installierte Operatoren vom Market Place
• Helm: fertige Installationspakete, so eine Art Appstore
• Workloads
  • Topology: Übersicht über den Namespace
  • Pods / Deployments / …: Informationen zu den Pods, zum Deployment, etc …
    • dort werden die selbst erstellten „Workloads“ (Applikationen) hinterlegt bzw. aufgebaut
• Networking
  • Service: Zugang zu den Pods des Projektes (netzwerkseitig)
    • Schnittstelle zwischen Namensräumen
  • Routes: ReverseProxy (kann nur HTTP/HTTPS)
  • Ingresses: TCP/UDP-Verbindungen über Ingress
  • NetworkPolicies: Einschränkung der Zugänge (Firewall)
  • UserDefinedNetworks: vermutlich selbstgenerierte Netzwerke
• Storage
  • PersistentVolumes: der endgültige Speicher
  • PersistentVolumeClaims: kann als Anforderung verstanden werden (Abstraktionsebene)
    • legt auch die Art der Persistenz des Speichers fest (reclaim-policy: „always“ oder „delete“)
  • StorageClass: Definition der Speicherklassen (Block-, Objekt- oder Dateisystemspeicher)
    • weiterhin werden hier die Funktionen des Speichers definiert
  • VolumeSnapshots:
  • VolumeSnapshotClasses:
  • VolumeSnapshotContents:
• Builds
• Observe: Abfrage von Metriken (Prometheus)
• Compute
  • Nodes: Clusterknoten
  • Machines: physikalische Ebene des Servers
  • MachineSets: Blaupausen für neue Server
  • MachineAutoscalers:
  • MachineHealthChecks:
  • MachineConfigs:
  • MachineConfigPools:
• User Management: Authentifizierungsinformationen
  • ServiceAccounts: Konten für privilegierte Zugriffe
• Administration: Cluster-weite Einstellungen
  • Namespaces: Namensraum (es wird dann auch gleichzeitig das Projekt dazu erstellt)

Kapazitäten:

• Control Plane: 4 vCPU, 16 GB RAM und 128 GB Festplatte
• Worker: 4 vCPU, 16 GB RAM und 128 GB Festplatte (Grundausstattung)

Netzwerk:

• okd-cp1.fritz.box: 192.168.1.101
• okd-cp2.fritz.box: 192.168.1.102
• okd-cp3.fritz.box: 192.168.1.103
• okd-wrk1.fritz.box: 192.168.1.104
• okd-wrk2.fritz.box: 192.168.1.105
• apps.fritz.box: 192.168.1.111
  • Präfix: „apps.“ → Endpunkt für die Weboberfläche, ist das Routing-Interface mit eigener IP-Adresse
• api.fritz.box: 192.168.1.112
  • Präfix: „api.“ → Endpunkt für die Steuerung des Clusters mit eigener IP-Adresse

Firewall:

• „api.fritz.box“ → Port 6443
• „apps.fritz.box“ → Port 80 und 443
• Control Planes → Port 6443

Zertifikate:

• Adresse „*.apps.fritz.box“ (Wildcard-Zertifikat)
  • zusätzlich sollten noch „api.fritz.box“ und „apps.fritz.box“ im Zertifikat enthalten sein

Die Systemeinrichtung beschreibt üblicherweise die Installation und Konfiguration eines Systems.

Grundsätzlich gibt es mehrere Methoden zur Installation eines OKD-Clusters (siehe hierzu auf docs.okd.io). Nachfolgend wurde sich bezüglich unserer Umgebung für die einfachere Lösung entschieden: „Full control“ (unter OpenShift: „Agent base installer“ genannt). Daraus ergeben sich für die Systemeinrichtung die nachfolgenden Schritte:

• Bereitstellen der Verzeichnisstruktur
• Beschaffen der Programme „oc“ und „openshift-install“
• Erstellen der „ImageSetConfiguration“-Datei (ISC)
• Herunterladen der Abbilder aus dem Internet in den Harbor
• Erstellen der Konfigurationsdateien für die Installation („install-config.yaml“ und „agent-config.yaml“)
• Erstellen der Bootstrap-ISO-Datei
• Installation des Clusters

Auf dem („Bau“)-Rechner „slxkubernetes.fritz.box“ gibt es den Benutzer „osc“. In dessen Home-Verzeichnis „/service/osc“ gibt es das Verzeichnis „okd“. Dort werden die Bewegungsdaten abgelegt. Zusätzlich gibt es das GIT-Repository „kubernetes“. Dies ist auf dem Baurechner unter „~/okdrepo“ ausgecheckt. Dort gibt es ebenfalls das Unterverzeichnis „okd“, welches alle Konfigurationsdateien und Skripte beinhaltet.

Bewegungsdaten („~/okd/“):

• „oc-mirror/ “: Daten vom Spiegelprozess mit „oc-mirror“ und Ablage der Kopie der YAML-Konfigurationsdatei „isc.yaml“ (Konfigurationsdatei für „oc-mirror“)
  • Unterverzeichnis „data/ “: Datenablage vom Spiegelprozess (Verzeichnis muss einmalig erstellt werden)
• „openshift-install/ “: Daten für die Erstellung der Boostrap-ISO-Datei
  • die Bootstrap-ISO-Datei selbst
  • Logdaten
  • Unterverzeichnis „auth/ “: Daten zur Authentifizierung am Cluster mittels „oc“

Konfigurationsdaten und Skripte („~/kubernetes/okd/“):

• „agent-based-installer/“: Konfigurationsdateien und Skripte für Erstellung der Bootstrap-ISO-Datei, sowie für die Überwachung der Installation des Clusters
  • „agent-config.yaml “: spezifische Netzwerkkonfiguration des Clusters
  • „build_iso.sh “: Skript zur Erstellung der Bootstrap-ISO-Datei
  • „install-config.yaml “: Konfigurationsdatei für die Installation (Clustername, Netzwerk, VIP, Quellen, Zertifikate, SSH-Schlüssel)
  • „SSH_KEY “ und „SSK_KEY.pub “: SSH-Zertifikat zur Verbindung mit dem Cluster über SSH
  • „track-and-verifying-installation.sh “: Skript zur Überwachung der Bootstrap-Installation der Knoten
  • „verify-successful-installation.sh “: Skript zur Überwachung der endgültigen Clusterinstallation und Anzeige der Authentifizierungsinformationen
• „oc-mirror/ “: alle Konfigurationsdateien für den Spiegelprozess mit „oc-mirror“
  • „isc.yaml “: Konfigurationsdatei für die Spiegelung mit „oc-mirror“
  • „secret.json “: Authentifizierungsinformationen für die Spiegelung

Die beiden Programme „oc“ und „openshift-install“ werden von Github (https://github.com/okd-project/okd/releases/tag/4.19.0-okd-scos.16) heruntergeladen. Die „Baumaschine“ („slxkubernetes.fritz.box“) ist ein Rocky 9, somit müssen auch die beiden Programme passend zur Distribution heruntergeladen werden:

• „oc“: https://github.com/okd-project/okd/releases/download/4.19.0-okd-scos.16/openshift-client-linux-amd64-rhel9-4.19.0-okd-scos.16.tar.gz
• „openshift-install“: https://github.com/okd-project/okd/releases/download/4.19.0-okd-scos.16/openshift-install-linux-4.19.0-okd-scos.16.tar.gz

Die beiden Archive müssen entpackt und die enthaltenen Programme „oc“, „kubectl“ und „openshift-install“ auf dem Rechner global verfügbar gemacht werden.

Zusätzlich wird das Programm „oc-mirror“ verwendet, welches OKD-Images aus dem Internet laden und im Harbor ablegen kann. Das Programm wird von Red Hat direkt heruntergeladen: https://console.redhat.com/openshift/downloads (Achtung: Es wird ein gültiger Login benötigt): „OpenShift Client (oc) mirror plugin“: https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/latest/oc-mirror.rhel9.tar.gz. Es wird immer die aktuellste Version heruntergeladen.

Das Archiv muss ebenfalls entpackt und das Programm „oc-mirror“ global verfügbar gemacht werden.

Als letztes kann das folgende Programm unter Umständen noch nützlich sein:

• skopeo

Die „Image-Set-Configuration“-Datei (kurz: „ISC“) ist eine YAML-Konfigurationsdatei, welche als Beispielkonfiguration auf der Webseite von docs.okd.io zur Verfügung gestellt wird:

kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v2alpha1
mirror:
  platform:
    channels:
    - name: stable-4.19
      minVersion: 4.19.2
      maxVersion: 4.19.2
    graph: true
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.19
      packages:
       - name: aws-load-balancer-operator
       - name: 3scale-operator
       - name: node-observability-operator
  additionalImages:
   - name: registry.redhat.io/ubi8/ubi:latest
   - name: registry.redhat.io/ubi9/ubi@sha256:20f695d2a91352d4eaa25107535126727b5945bff38ed36a3e59590f495046f0

Bei der ersten Spiegelung der Abbilder zeigt die Synchronisation Fehler an: „OCP_SIGNATURE_VERIFICATION_PK“ (Signaturfehler während der Synchronisation). Nach umfassender Recherche im Internet konnte ermittelt werden, dass die ISC-YAML-Datei anders aufgebaut sein muss, damit von OKD gespiegelt werden kann:

apiVersion: mirror.openshift.io/v2alpha1
kind: ImageSetConfiguration
mirror:
  platform:
    graph: false
    channels:
      - name: 4-stable
        minVersion: 4.18.0-okd-scos.8
        maxVersion: 4.18.0-okd-scos.8
        type: okd

Weiterhin ist dort nachzulesen, dass für eine erfolgreiche Spiegelung zwei Umgebungsvariablen gesetzt sein müssen:

• OCP_SIGNATURE_URL=„https://storage.googleapis.com/openshift-ci-release/releases/signatures/openshift/release/“
• OCP_SIGNATURE_VERIFICATION_PK=„<'oc-mirror'-Arbeitsverzeichnis>/ocp-sign-key“

Der Schlüssel „ocp-sign-key“ kann von der Webseite „https://raw.githubusercontent.com/openshift/cluster-update-keys/master/keys/verifier-public-key-openshift-ci-4“ heruntergeladen werden.

Das gezeigte Beispiel ist aber veraltet, es muss auf die aktuelle stabile Version angepasst werden, welche unter openshift.org nachgelesen werden kann:

apiVersion: mirror.openshift.io/v2alpha1
kind: ImageSetConfiguration
mirror:
  platform:
    graph: true
    channels:
      - name: okd
        type: okd
        minVersion: 4.19.0-okd-scos.16
        maxVersion: 4.19.0-okd-scos.16

Grundsätzlich reicht diese Konfiguration aus, um einen OKD-Cluster zu erstellen. Nach erster Installation hat sich zudem gezeigt, dass der korrekte „channel“ - also Update-Kanal - „stable-scos-4“ lautet.
Wir möchten zusätzlich aber auch den Aktualisierungsdienst von OKD („cincinnati-operator“) nutzen, sowie ein Terminal im Webbrowser („web-terminal“). Unter der Variablen „catalog“ findet sich hier der Red-Hat-Operator-Katalog. Man kann sich diesen Katalog als eine Art Inhaltsverzeichnis vorstellen, welcher gültige Operatoren auflistet (nähere Informationen sind unter okd.io zu finden). Hinzu kommt noch der „crunchy-postgres-operator“, um hochverfügbare PostgreSQL Datenbanken im Cluster bereitstellen zu können.
Damit das Web-Terminal nicht nur für Pods, sonder auch für die Nodes funktioniert müssen zusätzlich die support-tools verfügbar sein. Da hier je nach Anwendungsfall ubi images (also RHEL Container Images) sowie die Support Tools für RHEL 8 und 9 benutzt werden, werden diese als „additionalImages“ hinzugefügt.

Somit ergibt sich die nachfolgende finale ISC-YAML-Datei:

apiVersion: mirror.openshift.io/v2alpha1
kind: ImageSetConfiguration
mirror:
  platform:
    graph: true
    channels:
      - name: stable-scos-4
        type: okd
        minVersion: 4.19.0-okd-scos.16
        maxVersion: 4.19.0-okd-scos.16
    architectures:
      - amd64

  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.19
      packages:
        - name: cincinnati-operator
        - name: web-terminal

    - catalog: registry.redhat.io/redhat/certified-operator-index:v4.19
      packages:
        - name: crunchy-postgres-operator

  additionalImages:
    - name: registry.redhat.io/ubi8/ubi:latest
    - name: registry.redhat.io/ubi9/ubi:latest
    - name: registry.redhat.io/rhel8/support-tools:latest
    - name: registry.redhat.io/rhel9/support-tools:latest

Zur Erklärung:

• „platform“: OKD Cluster Images
  • „graph “: Datenbank für den Openshift-Update-Service (OSUS) (damit der Dienst weiß, was er wie aktualisieren muss)
  • „channel “: Festlegen, was in welcher Version synchronisiert werden soll
    • bei OKD hat der Wert der Variablen „name“ keine konkrete Bedeutung, es kann dort irgendwas eingetragen werden - wie sich später herausgestellt hat ist dieser korrekterweise „stable-scos-4 (Info aus OKD Web-Interfac Administration→ Cluster Configuration)
    • der Typ (“type„) muss auf jeden Fall auf “okd„ gesetzt werden
  • „architectures “: Angabe der Architektur (wobei OKD aktuell nur “amd64„ anbietet und es somit weggelassen werden könnte)
• „operators “: legt den zu nutzenden Katalog fest
  • „catalog“: legt den Katalog fest, aus dem Pakete synchronisiert werden sollen
  • „packages “: definiert alle Pakete, die zusätzlich noch gespiegelt werden sollen
• „additionalImages“: Zusätzliche Images die synchronisiert werden sollen - Hier sollten nur „Cluster-nahe“ Images, die vom Cluster fest vorgegeben werden eingetragen werden. (Bei eigenen Deployments kann der Image-Pfad zum Harbor als Quelle hinterlegt werden)

Nach der finalen Fertigstellung der ISC-YAML-Datei kann diese zur Spiegelung der Abbilder in den Harbor genutzt werden. Zum Harbor gibt es im Wiki eine eigene Seite, welche alle wichtigen Punkte zum Produkt besdchreibt: Harbor.

Hier der grundsätzliche Befehl zur Spiegelung der Abbilder:

~$ oc-mirror --v2 -c isc.yaml --workspace file://<Workspace-Verzeichnis> docker://<Harbor-FQDN>/<Projektname>

Zur Erklärung:

• „oc-mirror “: Programm zum Spiegeln der Abbilder
• „–v2 “: Version, die verwendet werden soll (Version 1 ist veraltet und soll nicht mehr verwendet werden)
• „-c isc.yaml “: Angabe der oben erstellten ISC-YAML-Datei
• „–workspace file:<Workspace-Verzeichnis>“: Angabe eines lokalen Verzeichnisses, in welchem notwendige Zwischendaten gespeichert werden * „docker:<Harbor-FQDN>/<Projektname> “: Angabe des Harbors inklusive eines zugeordneten Projektes

Zur Verbindung mit dem Harbor wurde dort ein passendes Projekt “okd„ erstellt und ein “Robot Account„ “oc-mirror„ darauf berechtigt (die entsprechenden Berechtigungen können hier nachgelesen werden). Beim Erstellen des “oc-mirror„-Accounts wird am Ende ein sogenanntes “Secret„ (was dem Passwort des Benutzers entspricht) angezeigt. Diese Information muss zusammen mit dem Accountnamen BASE64-kodiert werden:

~$ echo -n 'robot$oc-mirror:Td11ruxCbx********************dC' | base64 -w0 \\ cm9**************************jVRdlZYd2phe******GRD \\ ~$

Jetzt kann diese Information, zusammen mit der Harbor-Adresse als “secret.json„-Datei abgelegt werden:

{
  "auths": {
    "slxharbor.fritz.box": {
      "auth": "cm9**************************jVRdlZYd2phe******GRD",
      "email": "admin@fritz.box"
    }
}

Weil wir in der ISC-YAML-Datei zusätzliche Pakete nutzen, muss die “secret.json„-Datei um diese Registrierung erweitert werden:

{
 "auths": {
   "slxharbor.fritz.box": {
     "auth": "cm9**************************jVRdlZYd2phe******GRD",
     "email": "admin@fritz.box"
   },
   "registry.redhat.io": {
     "auth": "fHVoYy1*************************************************ZZbF91aWdZS0xHRQ==",
     "email": "admin@fritz.box"
   }
 }
}

Diese JSON-Datei muss im Verzeichnis “~/.docker/„ (damit ist das Benutzerverzeichnis des ausführenden Benutzers) als Datei “config.json„ abgelegt werden.

Zum Zeitpunkt der Erstellung der Dokumentation konnte von der Seite https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/latest/oc-mirror.rhel9.tar.gz nur die Version 4.19 heruntergeladen werden, in welcher der oben beschriebene Fehler noch nicht behoben ist. Deswegen wurde eine neuere Version kompiliert. Alle notwendigen Schritte dazu werden unter https://github.com/openshift/oc-mirror/tree/release-4.20 beschrieben.

Für die Spiegelung der Abbilder sind mehrere Vorbereitungsschritte notwendig. Es wurde daher ein Skript erstellt, welches zum Beispiel auch die Umgebungsvariablen setzt (und wieder entfernt, nach Fertigstellung). Dieses Skript ist ebenfalls im GIT eingecheckt (unter “kubernetes/okd/oc-mirror/sync.sh„).

Im Verzeichnis “~/okd/oc-mirror/working-dir/cluster-resources/„ liegen nach der erfolgreichen Synchronisation mehrere Konfigurationsdateien (“*.yaml„), die im Cluster angewendet werden, damit dieser weiß, von wo aus er seine Daten herbekommt:

• cc-redhat-operator-index-v4-19.yaml (cc = cluster catalog) und cs-redhat-operator-index-v4-19.yaml (cs = catalog source) :
  • : beinhalten die Konfiguration für den Marketplace, um entsrepchende Operatoren in OKD zu installieren
• idms-oc-mirror.yaml, itms-oc-mirror.yaml, signature-configmap.yaml, updateService.yaml
  • beinhalten Informationen für den OSUS

Nach der Spiegelung der Abbilder in den Harbor kann die Konfigurationsdatei für die Installation (“Agent Base Installer„: install-config.yaml), sowie die Anweisung, wie das Betriebssystem zu konfigurieren ist (“Agent Config„: agent-config.yaml)

Die OKD-Seite “docs.okd.io„ zeigt unter dem Punkt “Sample install-config.yaml file for bare metal„ eine Beispielkonfiguration für eine Installationsdatei:

apiVersion: v1
baseDomain: example.com
compute:
- hyperthreading: Enabled
name: worker
replicas: 0
controlPlane:
hyperthreading: Enabled
name: master
replicas: 3
metadata:
name: test
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
none: {}
pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}'
sshKey: 'ssh-ed25519 AAAA...'
additionalTrustBundle: |
-----BEGIN CERTIFICATE-----
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
-----END CERTIFICATE-----
imageContentSources:
- mirrors:
- <local_registry>/<local_repository_name>/release
source: quay.io/openshift-release-dev/ocp-release
- mirrors:
- <local_registry>/<local_repository_name>/release
source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

Dieses Dokument wird als Grundlage für unsere nachfolgende angepasste Konfigurationsdatei verwendet.

Für den Zugriff auf den Harbor zum Herunterladen von Daten wird wieder ein Benutzer (“Robot Account„) benötigt, mit entsprechenden Berechtigungen auf das Projekt “okd„ (siehe Bild: harbor-okd-berechtigungen.png ). Das vom Harbor erzeugte “Secret„ muss dann ebenfalls zusammen mit anderen Daten BASE64-kodiert und in die Konfigurationsdatei eingetragen.

Hier die angepasste Konfigurationsdatei:

apiVersion: v1
 baseDomain: fritz.box
 controlPlane:
 name: master
 replicas: 3
 compute:
 - name: worker
 replicas: 2
 metadata:
 name: okd
 networking:
 machineNetwork:
 - cidr: 192.168.1.0/24
 clusterNetwork:
 - cidr: 172.28.0.0/14 # bis 172.31.255.255 = 262142 Pods
 hostPrefix: 23
 serviceNetwork:
 - 172.27.0.0/16 # bis 172.27.255.255 = 65534 Services
 networkType: OVNKubernetes
 platform:
 baremetal:
 apiVIPs:
 - 192.168.1.112
 ingressVIPs:
 - 192.168.1.111
 imageDigestSources:
 - mirrors:
 - slxharbor.fritz.box/okd/openshift/release
 source: quay.io/okd/scos-content
 - mirrors:
 - slxharbor.fritz.box/okd/openshift/release-images
 source: quay.io/okd/scos-release
 additionalTrustBundle: |
 -----BEGIN CERTIFICATE-----
 MIIDiDCCAn*************************************************mlho3Urn9rYk=
 -----END CERTIFICATE-----
 fips: false
 pullSecret: '{
   "auths": {
     "slxharbor.fritz.box": {
       "auth": "cm9**************************jVRdlZYd2phe******GRD"",
       "email": "admin@fritz.box"
     }
   }
 }'
 sshKey: 'ssh-ed25519 AAAAC************************************YNZUcfcOiw OpenShift Admin Node Key'

Erklärung:

• „machineNetwork “: Netzwerk, in welchem die Rechner beheimatet sind (für den „physischen“ Zugriff auf die Server)
• „platform “: Hinterlegen der beiden zusätzlichen VIP-Adressen für die API und die Apps
• „imageContentSources “: Anpassung der Quellen (“source„) entsprechend passend zur Umgebung
  • die korrekten Quellen sind in der Datei “~/okd/oc-mirror/data/working-dir/cluster-resources/idms-oc-mirror.yaml„ zu finden
• „additionalTrustBundle “: hier ist das Zertifikat hinterlegt
• „sshKey “: Anmeldung an den OKD-Knoten (öffentlicher SSH-Schlüssel)
  • dafür werden die beiden Dateien “SSH_KEY„ und “SSH_KEY.pub„ benötigt

Leider bietet die OKD-Seite keine gut beschriebene Beispieldatei für eine “Agent Config„-Datei, die aber sehr spärlich aufgebaut ist:

apiVersion: v1beta1
metadata:
  name: <cluster_name>
  namespace: <cluster_namespace>
rendezvousIP: <ip_address_from_CIDR>
bootArtifactsBaseURL: <server_URL>

Alternativ konnte bei Red Hat eine Beschreibung gefunden werden, welche Parameter erforderlich und welche optional sind. Es ergibt sich folgende finale Datei:

apiVersion: v1alpha1
kind: AgentConfig
rendezvousIP: 192.168.1.101
additionalNTPSources:
  - ntp.fritz.box
  - 192.168.1.1
metadata:
  name: okd
hosts:
  - hostname: okd-cp1
    role: master
    rootDeviceHints:
      deviceName: "/dev/disk/by-path/pci-0000:09:01.0-scsi-0:0:0:0"
    interfaces:
      - name: enp6s18 # OS-Management
        macAddress: BC:30:12:81:71:4A
    networkConfig:
      interfaces:
        - name: enp6s18 # OS-Management
          type: ethernet
          state: up
          mac-address: BC:30:12:81:71:4A
          ipv4:
            enabled: true
            address:
              - ip: 192.168.1.101
                prefix-length: 24
            dhcp: false
      dns-resolver:
        config:
          server:
            - 192.168.1.1
      routes:
        config:
          - destination: 0.0.0.0/0
            next-hop-address: 192.168.1.1
            next-hop-interface: enp6s18
            table-id: 254
  - hostname: okd-cp2
    role: master
    rootDeviceHints:
      deviceName: "/dev/disk/by-path/pci-0000:09:01.0-scsi-0:0:0:0"
    interfaces:
      - name: enp6s18 # OS-Management
        macAddress: BC:30:12:81:71:4B
    networkConfig:
      interfaces:
        - name: enp6s18 # OS-Management
          type: ethernet
          state: up
          mac-address: BC:30:12:81:71:4B
          ipv4:
            enabled: true
            address:
              - ip: 192.168.1.102
                prefix-length: 24
            dhcp: false
      dns-resolver:
        config:
          server:
            - 192.168.1.1
      routes:
        config:
          - destination: 0.0.0.0/0
            next-hop-address: 192.168.1.1
            next-hop-interface: enp6s18
            table-id: 254
  - hostname: okd-cp3
    role: master
    rootDeviceHints:
      deviceName: "/dev/disk/by-path/pci-0000:09:01.0-scsi-0:0:0:0"
    interfaces:
      - name: enp6s18 # OS-Management
        macAddress: BC:30:12:81:71:4C
    networkConfig:
      interfaces:
        - name: enp6s18 # OS-Management
          type: ethernet
          state: up
          mac-address: BC:30:12:81:71:4C
          ipv4:
            enabled: true
            address:
              - ip: 192.168.1.103
                prefix-length: 24
            dhcp: false
      dns-resolver:
        config:
          server:
            - 192.168.1.1
      routes:
        config:
          - destination: 0.0.0.0/0
            next-hop-address: 192.168.1.1
            next-hop-interface: enp6s18
            table-id: 254
  - hostname: okd-wrk1
    role: master
    rootDeviceHints:
      deviceName: "/dev/disk/by-path/pci-0000:09:01.0-scsi-0:0:0:0"
    interfaces:
      - name: enp6s18 # OS-Management
        macAddress: BC:30:12:81:71:4D
    networkConfig:
      interfaces:
        - name: enp6s18 # OS-Management
          type: ethernet
          state: up
          mac-address: BC:30:12:81:71:4D
          ipv4:
            enabled: true
            address:
              - ip: 192.168.1.104
                prefix-length: 24
            dhcp: false
      dns-resolver:
        config:
          server:
            - 192.168.1.1
      routes:
        config:
          - destination: 0.0.0.0/0
            next-hop-address: 192.168.1.1
            next-hop-interface: enp6s18
            table-id: 254
  - hostname: okd-wrk2
    role: master
    rootDeviceHints:
      deviceName: "/dev/disk/by-path/pci-0000:09:01.0-scsi-0:0:0:0"
    interfaces:
      - name: enp6s18 # OS-Management
        macAddress: BC:30:12:81:71:4E
    networkConfig:
      interfaces:
        - name: enp6s18 # OS-Management
          type: ethernet
          state: up
          mac-address: BC:30:12:81:71:4E
          ipv4:
            enabled: true
            address:
              - ip: 192.168.1.105
                prefix-length: 24
            dhcp: false
      dns-resolver:
        config:
          server:
            - 192.168.1.1
      routes:
        config:
          - destination: 0.0.0.0/0
            next-hop-address: 192.168.1.1
            next-hop-interface: enp6s18
            table-id: 254

Erklärung:

• „apiVersion “: wird auf „v1alpha1“ gesetzt (“v1alpha1„ hat sich bisher bewährt, Version “v1beta1„ wird gegebenenfalls noch getestet)
• „kind “: Art der Konfigurationsdatei
• „rendezvousIP “: im Normalfall ist das die erste (oder eine) Adresse eines “Control Plane„-Servers
• „additionalNTPSources “: Angabe eines gültigen NTP-Servers
• „host “: hier erfolgt die Konfiguration der Rechner
  • “deviceName„ und “interfaces„ werden hier zur Identifikation des richtigen Rechner genutzt
  • “networkConfig„: hier werden dann alle Netzwerkparameter festgelegt, wie IP-Adresse, DNS, Route und Gateway

Mit den beiden Konfigurationdateien “install-config.yaml„ und “agent-config.yaml„ kann jetzt die Bootstrap-ISO-Datei erstellt werden. Dies wird mittels des Programms “openshift-install„ durchgeführt:

~$ openshift-install --dir <OpenshiftInstall-Arbeitsverzeichnis> agent create image

Hinweis: Hier im Beispiel liegt das „OpenshiftInstall-Arbeitsverzeichnis“ unter “~/okd/openshift-install„.

Es wird vorausgesetzt, dass die zwei Dateien “install-config.yaml„ und “agent-config.yaml„ im “Workspace„-Verzeichnis abgelegt werden.

Die Ausgabe kann wie folgt aussehen:

Start building ISO
WARNING imageContentSources is deprecated, please use ImageDigestSources
INFO Configuration has 3 master replicas and 2 worker replicas
INFO The rendezvous host IP (node0 IP) is 192.168.1.101
INFO Extracting base ISO from release payload
INFO Base ISO obtained from release and cached at [/service/osc/.cache/agent/image_cache/coreos-x86_64.iso]
WARNING base ISO version mismatch in release payload. Expected version 9.0.20250510-0 but found 9.0.20250411-0
INFO Consuming Agent Config from target directory
INFO Consuming Install Config from target directory
INFO Generated ISO at /service/osc/okd/openshift-install/agent.x86_64.iso.
Finished after 58 seconds!

Die erstellte ISO-Datei muss in allen oben definierten Servern (“Control Plane„ und “Worker„) eingelegt und davon gebootet werden.

Die Installation startet üblicherweise mit dem Rechner, welcher als Rendevousz-Server angegeben wurde.

Zur Verfolgung der Installation kann ebenfalls das Programm “openshift-install„ verwendet werden:

~$ openshift-install --dir <Arbeitsverzeichnis> agent wait-for bootstrap-complete --log-level info

Hinweis: Hier im Beispiel liegt das „Arbeitsverzeichnis“ unter “~/okd/openshift-install„.

Beim Erstellen der ISO-Datei wird im Verzeichnis “~/okd/openshift-install„ das Unterverzeichnis “auth„ erstellt, welches die notwendigen Authentifizierungsdaten enthält, um die Überwachung durchzuführen.

Während der Installation starten die Server unter Umständen mehrmals neu (die entsprechenden Logmeldungen wurden nicht kopiert). Nach der Fertigstellung kann die erfolgreiche Installation mit einem Befehl überprüft werden:

~$ openshift-install --dir <Arbeitsverzeichnis> agent wait-for install-complete
INFO Bootstrap Kube API Initialized
INFO Bootstrap configMap status is complete
INFO Bootstrap is complete
INFO cluster bootstrap is complete
INFO Cluster is installed
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run
INFO     export KUBECONFIG=/service/osc/okd/openshift-install/auth/kubeconfig
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.fritz.box
INFO Login to the console with user: "kubeadmin", and password: "q9**j-A***W-8***F-j***a"
~$

Hinweis: Hier im Beispiel liegt das „Arbeitsverzeichnis“ unter “~/okd/openshift-install„.

In der Ausgabe wird auch angegeben, was zu tun ist, um den Cluster mittels des Programmes “oc„ zu erreichen ist:

~$ export KUBECONFIG=/service/osc/okd/openshift-install/auth/kubeconfig

Jetzt können, wieder mit “oc„, zum Beispiel die Knoten aufgelistet werden:

~$ oc get nodes
NAME            STATUS   ROLES                  AGE   VERSION
okd-cp1         Ready    control-plane,master   13h   v1.32.7
okd-cp2         Ready    control-plane,master   13h   v1.32.7
okd-cp3         Ready    control-plane,master   13h   v1.32.7
okd-wrk1        Ready    worker                 13h   v1.32.7
okd-wrk2        Ready    worker                 13h   v1.32.7
~$

Nach einer erfolgreichen Installation kann die Weberoberfläche unter: https://console-openshift-console.apps.fritz.box/ und die API-Schnittstelle unter: https://api.fritz.box:6443/ erreicht werden.

_{.Ende des Dokuments}