Sichere Zukunft: Durchführen von nicht vernetzten Red Hat OpenShift Installationen mit dem agentenbasierten Installationsprogramm

In der modernen digitalen Welt sind Zuverlässigkeit und Sicherheits-Compliance wichtiger denn je. Für eine Organisation mit eingeschränkter oder schlechter Internetverbindung kann die Wahl zwischen einer standardmäßigen Installation von Red Hat OpenShift und einer nicht vernetzten oder Air-Gap-Installation einen entscheidenden Unterschied ausmachen. Mit einer nicht vernetzten Installation können Unternehmen OpenShift Cluster in isolierten, sicherheitsorientierten und eigenständigen Umgebungen einrichten und verwalten. Gleichzeitig sorgt sie für eine robuste Infrastruktur, die für den Erfolg in einer zunehmend komplexen Welt erforderlich ist.

In diesem Artikel untersuchen wir die Vorteile sowie wichtige Aspekte dieses grundlegenden Deployment- und Betriebsansatzes.

Installationsmethoden

Schauen wir uns zunächst die einzelnen Installationsmethoden an, die für selbst gemanagte OpenShift Cluster verfügbar sind.

Abbildung 1: Verschiedene Installationsmethoden

Installer-Provisioned Infrastructure (IPI)

IPI ist eine der unkompliziertesten Installationsmethoden. Sie ist für Nutzende geeignet, die eine geführte, automatische Installation bevorzugen. Bei der IPI-Methode wird die Infrastruktur, einschließlich virtueller Maschinen oder physischer Hardware, von OpenShift provisioniert. Sie wird normalerweise bei Cloud-Anbietern verwendet, kann aber auch für On-Premise-Installationen verwendet werden.

Assisted Installer (AI)

Assisted Installer ist ein webbasiertes interaktives Tool für die Durchführung von OpenShift Installationen. Die AI-Methode ist ein idealer Ansatz für Cluster, deren Netzwerke mit dem Internet verbunden sind. Sie bietet auch eine RESTful API für Automatisierungs- und erweiterte Konfigurationsszenarien. AI ist auch ein Bestandteil von Red Hat Advanced Cluster Management.

Agentenbasierte Installation (ABI)

Die agentenbasierte Installation umfasst eine startfähige ISO-Datei, die den Assisted Discovery Agent und den Assisted Service enthält. Die agentenbasierte Installation ist ein Unterbefehl des OpenShift Installationsprogramms. Bei der ABI-Methode wird ein startfähiges ISO-Image, das sämtliche für das Deployment eines OpenShift Clusters erforderlichen Assets enthält, mit einem verfügbaren OpenShift Release-Image generiert. Dieser Ansatz eignet sich ideal für Air-Gap-, nicht vernetzte oder eingeschränkte Umgebungen.

User-Provisioned Infrastructure (UPI)

UPI ist eine flexible Installationsmethode für Nutzende, die ihre eigene Infrastruktur verwalten möchten, sei es lokal, in ihren eigenen Rechenzentren oder bei Public Cloud-Anbietern. Bei UPI sind Nutzende für die Provisionierung von virtuellen Maschinen, Storage und Netzwerkkomponenten wie Load Balancern verantwortlich. Nach dem Provisionieren der Infrastruktur lässt sich mit dem OpenShift Installationsprogramm OpenShift auf der gewünschten Infrastruktur bereitstellen.

Gehostete Control Planes (HCP)

OpenShift Cluster können mit 2 verschiedenen Control Plane-Konfigurationen bereitgestellt werden: Standalone- oder gehostete Control Planes. Bei der Standalone-Konfiguration werden dedizierte virtuelle oder physische Maschinen zum Hosten der Control Plane verwendet. Bei der HCP-Methode für OpenShift erstellen Sie Control Planes als Pods auf einem Hosting-Cluster, ohne dass für die einzelnen Control Planes dedizierte virtuelle oder physische Maschinen erforderlich sind. Weitere Informationen finden Sie in der offiziellen HCP-Dokumentation und diesem Artikel.

Was ist eine nicht vernetzte Installation?

Es gibt verschiedene Installationsarten für verschiedene Szenarien. Dabei ist es wichtig, die richtige Methode für Ihren Use Case auszuwählen. Eine nicht vernetzte OpenShift Installation ist eine entscheidende Lösung für Organisationen und Umgebungen, in denen Sicherheits-Compliance, Kontrolle und Zuverlässigkeit von größter Bedeutung sind und eine direkte Internetverbindung eingeschränkt oder unerwünscht ist. Sie bietet die Infrastruktur, die für das Verwalten und Warten von OpenShift Clustern in isolierten, sicherheitsorientierten und eigenständigen Netzwerken erforderlich ist.

Eingeschränkt: Nicht vernetzt

Beim Betrieb in einer nicht vernetzten Umgebung verfügt der OpenShift Cluster über keine direkte Internetverbindung, nicht einmal über einen Proxy. Sämtliche zur Unterstützung der Umgebung erforderlichen Inhalte müssen lokal gespiegelt werden. Die Maschine, auf der das oc-Toolset ausgeführt wird, muss Zugang zum Internet, direkt oder indirekt über einen Proxy, sowie Zugriff auf eine Image Registry und die OpenShift-API haben.

Abbildung 2: Eingeschränkt – Nicht vernetzt

In diesem Blog konzentrieren wir uns auf die agentenbasierte Installationsmethode für nicht vernetzte/eingeschränkte Netzwerke, wobei eine Internetverbindung über den Bastion-Host möglich ist.

Eingeschränkt: Air Gap

Gemäß RFC 4949 liegt ein „Air Gap“ vor, wenn 2 Systeme nicht physisch verbunden sind und keine logische Verbindung automatisiert ist. Die Daten werden manuell, also durch menschlichen Eingriff, übertragen.

Abbildung 3: Eingeschränkt – Air Gap

In diesem Fall verfügt der OpenShift Cluster über keine direkte Internetverbindung, nicht einmal über einen Proxy. Sämtliche zur Unterstützung der Umgebung erforderlichen Inhalte werden lokal gespiegelt. Die Maschine, auf der die Installation ausgeführt wird, hat Zugriff auf die Mirror Registry und die OpenShift-API, jedoch KEINEN Zugriff auf das Internet. Die Inhalte müssen auf einem USB-Stick, auf optischen Medien oder über andere Offline-Methoden bereitgestellt werden.

Wenn der Bastion-Host nicht über eine Internetverbindung verfügt, finden Sie in diesem Abschnitt der offiziellen Dokumentation zusätzliche Schritte zum Mirroring des Image-Sets auf die Disk und anschließend zum Mirroring der Image-Set-Datei auf der Disk, die nicht Gegenstand dieses Artikels sind.

Erforderliche Tools zum Durchführen einer nicht vernetzten Installation

Bevor wir mit der eigentlichen Installation unter Verwendung der ABI-Methode beginnen, sollten wir die Tools besprechen, die für eine nicht vernetzte Installation erforderlich sind.

Mirror Registry für Red Hat OpenShift

Sie können die Images, die zur Unterstützung der OpenShift Installation und nachfolgender Produktaktualisierungen erforderlich sind, in eine Container Mirror Registry spiegeln, die Docker v2-2 unterstützt, wie etwa Red Hat Quay. Wenn Sie keinen Zugriff auf eine umfangreiche Container Registry haben, können Sie die Mirror Registry für Red Hat OpenShift verwenden. Hierbei handelt es sich um eine kleine Container Registry, die in OpenShift Subskriptionen enthalten ist.

OpenShift Client (oc) mirror-Plugin

Der Befehl oc-mirror ist ein OpenShift-CLI-Plugin (oc), das zum Mirroring von Images verwendet werden kann. Sie müssen oc-mirror auf einem System mit Internetverbindung ausführen, um den erforderlichen Inhalt von der Ursprungsquelle herunterzuladen.

Voraussetzungen für die Mirror Registry

• Eine OpenShift Subskription.
• Red Hat Enterprise Linux (RHEL) 8 oder 9 mit Podman 3.4.2 oder höher und installiertem OpenSSL.
• Vollständig qualifizierter Domain-Name für den Red Hat Quay Service, der über einen DNS-Server aufgelöst werden muss.
• 2 oder mehr vCPUs.
• 8 GB RAM.
• Etwa 17 GB für OpenShift 4.13 Release-Images oder etwa 358 GB für OpenShift 4.13 Release-Images und OpenShift 4.13 Red Hat Operator-Images. Bis zu 1 TB oder mehr für jeden Stream wird empfohlen.

Installationsaufgaben

Laden Sie nach der Installation der RHEL-Basis-VM die folgenden Tools auf den Bastion-Host herunter:

• Podman 3.4.2 oder höher

$ sudo dnf install -y podman

• OpenShift Client (oc CLI) 

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz
$ tar --extract --file openshift-client-linux.tar.gz
$ chmod +x oc
$ sudo mv oc /usr/local/bin/

• Mirror Registry

$ wget https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/mirror-registry/latest/mirror-registry.tar.gz
$ tar --extract --file mirror-registry.tar.gz
$ chmod +x mirror-registry

• oc mirror

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/oc-mirror.tar.gz
$ tar --extract --file oc-mirror.tar.gz
$ chmod +x oc-mirror
$ sudo mv oc-mirror /usr/local/bin/

Mirror Registry-Installation

Die Mirror Registry kann mit einem einzigen Befehl installiert werden:

$ ./mirror-registry install --quayHostname<hostname fqdn> \
--quayRoot /root/ocpmirror

Zum Beispiel:

$ sudo mirror-registry install \
--quayHostname bastion.j9287.dynamic.opentlc.com \
--quayRoot /root/ocpmirror

Nach einer erfolgreichen Installation der Mirror Registry wird folgende Ausgabe angezeigt:

[...]
INFO[2023-10-31 11:17:28] Quay installed successfully, config data is stored in /root/ocpmirror
INFO[2023-10-31 11:17:28] Quay is available at https://bastion.j9287.dynamic.opentlc.com:8443 with credentials (init, 7HFdq385A9EG0ngVWo4cKeDtxRzp621N)

Stellen Sie sicher, dass der Zugriff auf die Mirror Registry über die URL in den angegebenen Zugangsdaten möglich ist:

$ podman login -u init -p <password generated by installer> \
https://<hostname fqdn>:8443 \
--tls-verify=false

Zum Beispiel:

$ podman login -u init \
-p 7HFdq385A9EG0ngVWo4cKeDtxRzp621N \ https://bastion.j9287.dynamic.opentlc.com:8443 \
--tls-verify=false

Da die Mirror Registry mit einer benutzerdefinierten CA ausgeliefert wird, können Sie die folgende Variable exportieren, um sicher auf die Registry zuzugreifen:

$ export SSL_CERT_DIR=/root/ocpmirror/quay-rootCA/
$ podman login -u init \
-p 7HFdq385A9EG0ngVWo4cKeDtxRzp621N \
https://bastion.j9287.dynamic.opentlc.com:8443

Laden Sie Ihr OpenShift Pull Secret von https://console.redhat.com/openshift/downloads herunter, und speichern Sie die heruntergeladene Datei als pull-secret.

Führen Sie die folgenden Befehle von Ihrem Benutzerverzeichnis aus, um die Registry-Authentifizierung zu konfigurieren:

$ cat pull-secret | jq . > pull-secret.json
$ mkdir .docker ; cp pull-secret.json ~/.docker/config.json
$ echo -n 'init:7HFdq385A9EG0ngVWo4cKeDtxRzp621N' | \
base64 -w0

Verwenden Sie die Ausgabe des vorherigen Befehls, um die Datei so anzupassen, dass die lokale Mirroring-Authentifizierung in ~/.docker/config.json einbezogen wird:

"auths": {
 "bastion.j9287.dynamic.opentlc.com:8443": {
   "auth": "aW5pdDo3SEZkcTM3NUE5RUcwbmdWV280Y0tlRHR4UnpwNjIxTg==",
   "email": "[email protected]"
 },

Zu diesem Zeitpunkt ist eine Mirror Registry installiert und konfiguriert. Weitere Informationen finden Sie in der offiziellen Dokumentation.

Mirroring von Images

In diesem Abschnitt wird das OpenShift CLI-Plugin oc mirror verwendet, um den erforderlichen Inhalt in die Mirror Registry zu spiegeln.

In einer nicht vernetzten Umgebung können Sie ein Image-Set direkt in die gewünschte Mirror Registry spiegeln.

In einer Air-Gap-Umgebung müssen Sie zuerst das Image-Set auf die Disk spiegeln und dann die Image-Set-Datei auf der Disk in einen Mirror spiegeln.

Erstellen Sie zunächst eine neue Datei für die ImageSetConfiguration:

kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
 registry:
   imageURL: bastion.j9287.dynamic.opentlc.com:8443/mirror/oc-mirror-metadata # Local mirror registry URL
   skipTLS: false
mirror:
 platform:
   channels:
   - name: stable-4.13    # Version of OpenShift to be mirrored
     minVersion: 4.13.17  # Minimum version of OpenShift to be mirrored
     maxVersion: 4.13.18  # Maximum version of OpenShift to be mirrored
     shortestPath: true
     type: ocp
   graph: true   # Useful when updating in disconnected setup with OSUS operator
 operators:
 - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.13 # Operators catalog to mirror
 additionalImages:
 - name: registry.redhat.io/ubi8/ubi:latest
 helm: {}

Eine Beispieldatei finden Sie in diesem Repository. Eine vollständige Liste der Optionen zum Anpassen dieser Datei an Ihre Anforderungen finden Sie in der offiziellen Dokumentation.
 

In diesem Beispiel verwendet die Datei ImageSetConfiguration ein Registry Storage Backend (bastion.j9287.dynamic.opentlc.com:8443/mirror/oc-mirror-metadata) und enthält sämtliche OpenShift Versionen ab der Mindestversion 4.13.17 bis zur aktuellen Version im Kanal (hier 4.13.18). Bei jedem Aufruf von oc-mirror mit dieser Image-Set-Konfiguration wird das aktuelle Release des Kanals stable-4.13 ausgewertet. Wenn Sie oc-mirror in regelmäßigen Abständen ausführen, stellen Sie sicher, dass Sie automatisch die neuesten Releases von OpenShift Images erhalten.

Führen Sie, sobald die Datei ImageSetConfiguration fertiggestellt ist, den folgenden Befehl aus, um den Inhalt in die Registry zu spiegeln. Die für den Mirroring-Vorgang erforderliche Zeit hängt von Ihrer Konfiguration und der Verbindungsgeschwindigkeit ab.

$ oc mirror --config=imageset-config.yaml \
docker://<hostname fqdn>:8443 

Zum Beispiel:

$ oc mirror --config=imageset-config.yaml \  docker://bastion.j9287.dynamic.opentlc.com:8443

Die optionalen Parameter --continue-on-error und --skip-missing sind hilfreich, wenn Sie Fehler ignorieren müssen.

Nach der erfolgreichen Ausführung des vorherigen Befehls wird die folgende Ausgabe angezeigt:

[...]
bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images:4.13.17-x86_64
bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images:4.13.18-x86_64
Writing image mapping to oc-mirror-workspace/results-1698872844/mapping.txt
Writing UpdateService manifests to oc-mirror-workspace/results-1698872844
Writing CatalogSource manifests to oc-mirror-workspace/results-1698872844
Writing ICSP manifests to oc-mirror-workspace/results-1698872844

Einige Dateien werden von oc-mirror generiert. Dazu gehört updateService:

apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
 name: update-service-oc-mirror
spec:
 graphDataImage: bastion.j9287.dynamic.opentlc.com:8443/openshift/graph-image@sha256:a8730004abd6a4c1d02f52d8052a69a014a4e3de677135b2dfe50259fb6b63fa
 releases: bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
 replicas: 2

Die Datei ImageContentSourcePolicy:

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
 name: release-0
spec:
 repositoryDigestMirrors:
 - mirrors:
   - bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
   source: quay.io/openshift-release-dev/ocp-release
 - mirrors:
   - bastion.j9287.dynamic.opentlc.com:8443/openshift/release
   source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

Und schließlich CatalogSource:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
 name: redhat-operator-index
 namespace: openshift-marketplace
spec:
 image: bastion.j9287.dynamic.opentlc.com:8443/redhat/redhat-operator-index:v4.13
 sourceType: grpc

Diese Dateien werden später benötigt, um die Mirror Registry für die Installation zu konfigurieren und um Operatoren und Update Service anzuweisen, die lokale Registry zu verwenden.

Sie können sich auch über  https://:8443 bei der Mirror Registry-Benutzeroberfläche anmelden.

Agentenbasierte Installation

Wenn die lokale Mirror Registry installiert und konfiguriert ist, können wir uns die Installation von OpenShift mithilfe des agentenbasierten Installationsprogramms ansehen. Zum Zeitpunkt der Erstellung dieses Dokuments unterstützt das agentenbasierte Installationsprogramm die folgenden Plattformen:

• baremetal
• vSphere
• none

Bei der agentenbasierten Installation wird eine startfähige ISO-Datei verwendet, die den Assisted Discovery Agent und den Assisted Service enthält. Beide Komponenten sind für die Cluster-Installation erforderlich, wobei letztere jedoch nur auf einem der Hosts ausgeführt werden kann. Der Unterbefehl openshift-install agent create image generiert eine temporäre ISO-Datei basierend auf Ihren Eingaben.

In der Datei install-config.yaml müssen Sie das Pull Secret und das zusätzliche CA-Bundle der lokalen Mirror Registry und ImageContentSources einschließen, die auf den lokalen Mirror verweisen.

In der Datei agent-config.yaml müssen Sie den Parameter „rendezvousIP“ einschließen. Hierbei handelt es sich um die IP-Adresse des Hosts, der während der Installation zum temporären Bootstrap-Knoten wird. Diese IP-Adresse sollte mit einem der Knoten übereinstimmen.

Eine vollständige Liste der Installationsvorbereitungsschritte mit dem agentenbasierten Installationsprogramm finden Sie unter diesem Link. Die Beispieldateien install-config.yaml und agent-config.yaml befinden sich in diesem Repository.

Erstellen der ISO-Datei

Nachdem Sie die Dateien install-config.yaml und agent-config.yaml angepasst haben, können Sie das ISO-Image erstellen.

Installieren Sie zunächst das Paket nmstate:

$ sudo dnf install /usr/bin/nmstatectl

Laden Sie dann das OpenShift Installationsprogramm herunter. Die Version des heruntergeladenen OpenShift Installationsprogramms muss mit der Cluster-Version übereinstimmen, die Sie installieren möchten. In diesem Artikel verwenden wir OpenShift 4.13.17, also installieren wir OpenShift zuerst und aktualisieren dann den Cluster auf 4.13.18.

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/4.13.17/openshift-install-linux.tar.gz
$ tar --extract --file openshift-install-linux.tar.gz
$ chmod +x openshift-install
$ sudo mv openshift-install /usr/local/bin/

Erstellen Sie abschließend die ISO-Datei:

$ openshift-install agent create image --dir <directory>

Sie erhalten eine ähnliche Ausgabe wie folgende:

INFO Configuration has 3 master replicas and 3 worker replicas
INFO The rendezvous host IP (node0 IP) is 192.168.94.21
INFO Extracting base ISO from release payload    
INFO Base ISO obtained from release and cached at [/root/.cache/agent/image_cache/coreos-x86_64.iso]
INFO Consuming Install Config from target directory
INFO Consuming Agent Config from target directory

Je nach Plattform müssen Sie die Knoten (BareMetal oder VM) für die Control Plane und die Rechenknoten vorbereiten. Stellen Sie sicher, dass sämtliche Knoten des Clusters über das generierte ISO-Image starten.

Erstellen der DNS-Einträge

Sie müssen DNS-Einträge für 2 statische IP-Adressen in DNS erstellen. In jedem Eintrag entspricht <cluster_name> dem Namen des Clusters und <base_domain> der Basis-Domain des Clusters, die Sie beim Installieren des Clusters festlegen. Ein vollständiger DNS-Eintrag hat die Form: <component>.<cluster_name>.<base_domain>

API-VIP – api.<cluster_name>.<base_domain>

Ingress-VIP – *.apps.<cluster_name>.<base_domain>

Erstellen des OpenShift Clusters

Sie starten das ISO-Image auf jedem Cluster-Host, einschließlich Ihrer virtuellen Medien, dem startfähigen USB und der DVD.

Konfigurieren Sie die Knoten so, dass sie über das von Ihnen erstellte ISO-Image gestartet werden. Wenn sämtliche Knoten über das ISO-Image gestartet wurden, können Sie die Installation mit dem folgenden Befehl überwachen:

$ openshift-install agent wait-for bootstrap-complete \
--dir <directory> --log-level=debug
[...]
INFO Cluster is ready for install                
INFO Cluster validation: All hosts in the cluster are ready to install.
INFO Preparing cluster for installation
INFO Cluster installation in progress
INFO Bootstrap configMap status is complete      
INFO cluster bootstrap is complete

Wenn der Bootstrap-Prozess abgeschlossen ist, können Sie den folgenden Befehl ausführen, um den weiteren Fortschritt zu überwachen.

$ openshift-install agent wait-for install-complete \
--dir <directory> --log-level=debug
[...]
INFO Cluster is installed                        
INFO Install complete!                           
INFO To access the cluster as the system:admin user when using 'oc', run
INFO     export KUBECONFIG=/root/auth/kubeconfig 
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.j9287.dynamic.opentlc.com
INFO Login to the console with user: "kubeadmin", and password: "HR377-xxxxx-yyyyy-ynxGC"

Sobald Sie die Meldung erhalten, dass die Installation abgeschlossen ist, können Sie sich mit dem Befehl „oc“ beim Cluster anmelden und die Version des OpenShift Clusters überprüfen.

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.17   True        False         11m     Cluster version is 4.13.17

Weitere Details zum agentenbasierten Installationsprogramm finden Sie in der offiziellen OpenShift Dokumentation.

Sie können die ImageContentSourcePolicy überprüfen, um sicherzustellen, dass der OpenShift Cluster Images von der lokalen Mirror Registry erhält:

$ oc get imagecontentsourcepolicy
NAME             AGE
image-policy-0   18h
image-policy-1   18h
$ oc describe imagecontentsourcepolicy image-policy-0 |grep -A4 Spec:
Spec:
 Repository Digest Mirrors:
   Mirrors:
     bastion.j9287.dynamic.opentlc.com:8443/openshift/release
   Source:  quay.io/openshift-release-dev/ocp-v4.0-art-dev
$ oc describe imagecontentsourcepolicy image-policy-1 |grep -A4 Spec:
Spec:
 Repository Digest Mirrors:
   Mirrors:
     bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
   Source:  quay.io/openshift-release-dev/ocp-release

Sie müssen einige zusätzliche Konfigurationen vornehmen, um alle Standardkatalogquellen zu entfernen, da Ihr Cluster nicht mit dem Internet verbunden ist. Führen Sie die folgenden Befehle zum Patchen der OperatorHub-Ressource aus, um die standardmäßigen CatalogSources zu deaktivieren:

$ oc get catsrc -A
NAMESPACE               NAME                  DISPLAY               TYPE   PUBLISHER   AGE
openshift-marketplace   certified-operators   Certified Operators   grpc   Red Hat     32m
openshift-marketplace   community-operators   Community Operators   grpc   Red Hat     32m
openshift-marketplace   redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     32m
openshift-marketplace   redhat-operators      Red Hat Operators     grpc   Red Hat     32m
$ oc patch OperatorHub cluster --type json \
-p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
operatorhub.config.openshift.io/cluster patched
$ oc get catsrc -A
No resources found

Erstellen Sie eine neue CatalogSource-Ressource, die auf die lokale Mirror Registry verweist, indem Sie CatalogSource.yaml aus dem obigen Abschnitt über Image Mirroring anwenden.

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
 name: redhat-operator-index
 namespace: openshift-marketplace
spec:
 image: bastion.j9287.dynamic.opentlc.com:8443/redhat/redhat-operator-index:v4.13
 sourceType: grpc
 
$ oc apply -f ./oc-mirror-workspace/results-1698872844/
$ oc apply -f ./oc-mirror-workspace/results-1698872844/release-signatures/

Führen Sie nach der Anwendung die zuvor versuchten Überprüfungsschritte erneut aus:

$ oc get po -n openshift-marketplace
NAME                                    READY   STATUS    RESTARTS   AGE
marketplace-operator-7bc7549555-4ckdm   1/1     Running   0          48m
redhat-operator-index-t4cgd             1/1     Running   0          75s
$ oc get catsrc -A
NAMESPACE               NAME                    DISPLAY   TYPE   PUBLISHER   AGE
openshift-marketplace   redhat-operator-index             grpc               82s

Nun sind folgende Schritte abgeschlossen:

• Ein neuer OpenShift Cluster wurde mit der ABI-Methode installiert.
• Die Installations-Images wurden aus der lokalen Mirror Registry anstatt aus dem Internet abgerufen.
• Der Operator Hub wurde so konfiguriert, dass die lokale Mirror Registry verwendet wird.

OpenShift Updates in nicht vernetzten Umgebungen

Im ersten Teil des Blogs haben wir eine lokale Registry mit den beiden OpenShift-Versionen 4.13.17 und 4.13.18 gespiegelt (siehe Inhalt der Datei ImageSetConfiguration ). Für Cluster mit Internetzugriff bietet Red Hat OTA-Updates (Over-the-Air) mithilfe eines OpenShift Update Service (OSUS) als gehosteten Service, der sich hinter öffentlichen APIs befindet. In diesem Beispiel konzentrieren wir uns aber auf den nicht vernetzten Modus. OSUS wurde in diesem Guide für OpenShift Updates zur Cluster-Administration ausführlicher behandelt.

Es gibt 2 Methoden, um OpenShift Updates in nicht vernetzten/Air-Gap-Umgebungen durchzuführen: Ohne OpenShift Update Service Operator (OSUS) oder mit OpenShift Update Service Operator (OSUS).

Ohne OpenShift Update Service Operator (OSUS)

Schauen wir uns zunächst die einfachste Option zum Aktualisieren des OpenShift Clusters von 4.13.17 auf 4.13.18 an. Führen Sie die folgenden Befehle auf einem Laptop oder System aus, wenn der Befehl oc verfügbar ist und eine aktive Internetverbindung besteht:

$ export OCP_RELEASE_VERSION=4.13.18
$ export ARCHITECTURE=x86_64
$ oc adm release info -o 'jsonpath={.digest}{"\n"}' quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_VERSION}-${ARCHITECTURE}
sha256:d0fd9d3ab8690605f816c879d74f4e6d6d9f72982f63a3e0ef3e027ecc512e1c

Aktualisieren Sie anhand der Ausgabe des vorherigen Befehls den OpenShift Cluster vom Bastion-Knoten aus, auf dem Sie auf den OpenShift Cluster zugreifen können:

$ oc adm upgrade --allow-explicit-upgrade \
--to-image quay.io/openshift-release-dev/ocp-release@sha256:d0fd9d3ab8690605f816c879d74f4e6d6d9f72982f63a3e0ef3e027ecc512e1c
Requested update to 4.13.18
$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.17   True        True          78m     Working towards 4.13.18: 106 of 843 done (12% complete), waiting up to 40 minutes on etcd, kube-apiserver
$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.18   True        False         5m25s   Cluster version is 4.13.18

Weitere Informationen zum Aktualisieren von OpenShift finden Sie in der offiziellen Dokumentation.

Mit OpenShift Update Service Operator (OSUS)

Für die Verwendung des OpenShift Update Service Operator (OSUS) müssen Sie den Zugriff auf eine gesicherte Registry konfigurieren, wenn sich die Registry von der für die Installation verwendeten unterscheidet. Dies gilt nicht für diesen Artikel, da wir eine lokale Mirror Registry verwendet haben.

Sie müssen auch das globale Pull Secret des Clusters aktualisieren, um auf Ihre Mirror Registry zuzugreifen, wenn die Registry sich von der für die Installation verwendeten unterscheidet. Dies gilt nicht für diesen Artikel, da wir eine lokale Mirror Registry verwendet haben.

Zum Verwenden von OSUS müssen Sie zunächst den OSUS-Operator über den Operator Hub installieren.

Als Nächstes erstellen Sie ein Container Image mit Diagrammdaten für den OpenShift Update Service. Dieser Schritt ist für das Beispiel in diesem Artikel nicht erforderlich, da in diesem Artikel oc mirror für das Mirroring der Images verwendet wird und graph: true beim Mirroring in die Datei ImageSetConfiguration einbezogen wurde.

Installieren Sie anschließend die OSUS-Anwendung, und konfigurieren Sie Ihre Cluster so, dass sie den lokalen OpenShift Update Service verwenden. Verwenden Sie UpdateService.yaml, um die erforderliche Konfiguration anzuwenden. Zum Beispiel:

apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
 name: update-service-oc-mirror
spec:
 graphDataImage: bastion.j9287.dynamic.opentlc.com:8443/openshift/graph-image@sha256:a8730004abd6a4c1d02f52d8052a69a014a4e3de677135b2dfe50259fb6b63fa
 releases: bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
 replicas: 2

Führen Sie nach der Installation der OSUS-Anwendung die folgenden Befehle aus, damit der CVO (Cluster Version Operator) die Diagrammdaten aus dem lokal installierten OSUS anstatt aus dem Internet abruft.

$ export NAMESPACE=openshift-update-service
$ export NAME=update-service-oc-mirror
$ export POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"
$ export PATCH="{\"spec\":{\"upstream\":\"${POLICY_ENGINE_GRAPH_URI}\"}}"
$ oc patch clusterversion version -p $PATCH --type merge

Wenn beim Ausführen des Befehls oc adm upgrade Zertifikatsfehler angezeigt werden, überprüfen Sie, ob Sie einen clusterweiten Proxy aktiviert haben, und konfigurieren Sie die CA so, dass der Update-Server als vertrauenswürdig eingestuft wird.

Führen Sie abschließend das Update-Verfahren aus, wie im vorherigen Abschnitt beschrieben. Weitere Informationen zum OpenShift Update Service Operator finden Sie in der Dokumentation.

Zusammenfassung

In diesem Blog-Beitrag finden Sie eine detaillierte Anleitung zum Verwenden von Tools wie Mirror Registry und oc mirror, um ein lokales Repository für nicht vernetzte/Air-Gap-Installationen einzurichten. Mit diesem Wissen können OpenShift Admins lokal gespiegelte Images nicht nur zum Installieren eines OpenShift Clusters, sondern auch zum Durchführen von Upgrades und Updates verwenden.