Inhaltsverzeichnis

Was ist OKD?

OpenShift Origin, seit August 2018 auch als OKD (Origin Community Distribution) bekannt, ist das Upstream-Community-Projekt, das in OpenShift Online, OpenShift Dedicated und OpenShift Container Platform verwendet wird. Origin basiert auf einem Kern der Docker-Container-Packages und des Kubernetes-Container-Cluster-Managements und wird durch die Funktionen des Application-Lifecycle-Managements und der DevOps-Tools erweitert. Origin bietet eine Open-Source-Anwendungscontainerplattform. Der gesamte Quellcode für das Origin-Projekt ist unter der Apache-Lizenz (Version 2.0) auf GitHub verfügbar. (Quelle: Wikipedia)

Allgemeines

Nachfolgend etwas allgemeines Wissen über den OKD.

Rollen

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

Versionen

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.

Syntax

Pods:

Service:

Deployment (deployment.apps):

Replica Sets (replicaset.apps):

Daemon Sets (daemonset.apps):

Befehle

Weboberfläche

Ausstattung und Nomenklatur

Kapazitäten:

Netzwerk:

Firewall:

Zertifikate:

Systemeinrichtung

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

Analyse

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:

Verzeichnisstruktur

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/“):

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

Programme

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:

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:

ISC

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:

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:

Spiegeln der Abbilder

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:

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.

Release 4.20

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.

Synchronisationsskript

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„).

Cluster-Ressourcen

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:

Installationskonfigurationsdateien

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)

Install Config

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.

Harbor-Account

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.

Finale Datei

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:

Agent Config

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:

Bootstrap-ISO

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.

Cluster-Installation

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

Überwachung

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
~$

Erreichbarkeit

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