Bevor Sie ArcGIS Enterprise on Kubernetes in RedHat OpenShift (RHOS) bereitstellen, müssen Sie einen RHOS-Cluster vorbereiten, der die Systemanforderungen von ArcGIS Enterprise erfüllt.
Die Vorbereitung eines RedHat OpenShift-Clusters besteht einerseits aus allgemeinen Schritten, die für alle unterstützten Umgebungen durchgeführt werden müssen – wie z. B. der Einrichtung des Kubernetes-Clusters und der zugehörigen Knoten – und andererseits aus umgebungsspezifischen Schritten wie der Erstellung einer dedizierten Sicherheitskontextbeschränkung (SCC) und dem Umgang mit dem Zugang zu der Anwendung.
Sehen Sie sich die folgenden Schritte an, und lesen Sie die RedHat OpenShift-Dokumentation, um weitere detaillierte Anweisungen zur Vorbereitung Ihrer Umgebung zu erhalten.
- Erstellen Sie ein RedHat OpenShift-Cluster.
Ein RHOS-Cluster kann mit vielen Methoden bereitgestellt werden. Informationen zu lokalen Bereitstellungen finden Sie in der RedHat-Dokumentation. Informationen zu cloud-basierten Bereitstellungen finden Sie in den Dokumentationen RedHat OpenShift unter AWS (ROSA) oder Azure RedHat OpenShift.
- Aktualisieren Sie die oc-(kubectl-)Konfiguration.
Nach der Erstellung des Clusters können Sie mit der OpenShift-Befehlszeilenschnittstelle (Command Line Interface, CLI) die Informationen zur authentifizierten Benutzerverbindung in die kubeconfig-Datei übertragen. Dies können Sie mithilfe des folgenden Befehls tun:
oc login https://<serverName>:<serverPort>
- Erstellen Sie Speicherklassen.
Damit die Eigenschaften von reclaimPolicy und allowVolumeExpansion an die Anforderungen Ihrer Organisation und die Arbeitslasten angepasst werden können, sollten Sie eine Speicherklasse erstellen, die einen der unterstützten Provisioner, wie z. B. Cinder, Manila oder vSphere Volume, referenziert. Wenden Sie mit dem folgenden Befehl die entsprechende YAML-Datei auf den Cluster an:
Weitere Informationen finden Sie in der Beispiel-YAML-Datei für die Standardspeicherklasse und der Beispiel-YAML-Datei für die Sicherungsspeicherklasse.oc apply -f <storageClass.yaml>
- Verwalten Sie Einschränkungen im Sicherheitskontext.
In OpenShift agieren SCCs vor der Zeitplanung als benutzerdefinierte Zugangs-Controller für Pods. Standardmäßig werden alle Pods basierend auf den SCCs restricted oder restricted-v2 zugelassen, da die zulässige Gruppe system:authenticated ist.
Je nach Einrichtung müssen Sie ggf. weitere Rechte einräumen, um die ArcGIS Enterprise-Anforderungen zu erfüllen. Sehen Sie sich Folgendes an:- Lassen Sie zu, dass die Pods mit einer bestimmten fsGroup ausgeführt werden.
ArcGIS Enterprise-Arbeitslasten haben einen hart codierten fsGroup-Wert, mit dem Volume-Berechtigungen auf neu bereitgestellten persistenten Blockspeicher-Volumes initialisiert werden können. Dieser fsGroup-Wert muss von einem SCC zugelassen werden, da die Ausführung standardmäßig als beliebiger Bereich erfolgt. Hierzu muss eine Kopie des SCC des Typs restricted oder restricted-v2 mit dem folgenden Abschnitt aktualisiert werden:
fsGroup: ranges: - max: 117932853 min: 117932853 type: MustRunAs groups: - 'system:serviceaccounts:<deployment-project>'
- Lassen Sie zu, dass der Ingress-Controller an Ports mit Berechtigungen bindet.
Bei OpenShift-Versionen vor Version 4.11 lässt der beschränkte Kontext nicht zu, dass den Pods die Funktion NET_BIND_SERVICE hinzugefügt wird, was für den Ingress-Controller erforderlich ist. Ein neuer SCC muss aus der beschränkten Richtlinie und dem folgenden angehängten Abschnitt geklont werden:
allowedCapabilities: - NET_BIND_SERVICE
Dieser SCC muss dafür sorgen, dass das Service-Konto arcgis-ingress-serviceaccount zulässt, dass der Ingress-Controller ordnungsgemäß startet.
oc adm policy add-scc-to-user restricted-esri system:serviceaccount:<deployment-project>:arcgis-ingress-serviceaccount
Bei OpenShift Version 4.11 und höher ist die erforderliche Funktion im SCC restricted-v2 bereits vorhanden.
- Vergrößern Sie den maximalen Speicher für die Kartenbereiche.
Beim spatiotemporalen StatefulSet muss der zugrunde liegende Knoten für vm.max_map_count über einen größeren Wert verfügen. Die Aktivierung erfolgt standardmäßig mithilfe eines Init-Containers, aber der Befehl erfordert privilegierten Zugriff auf den zugrunde liegenden Host, damit er ausgeführt werden kann:
sysctl -w vm.max_map_count=262144
Die Worker-Knoten können beim Programmstart verändert werden, indem an der Ignition-Konfigurationsdatei Änderungen vorgenommen werden, damit der Befehl während des Bootstrappings ausgeführt wird. Die Eigenschaft für ALLOW_PRIVILEGED_CONTAINERS muss im Bereitstellungsskript auf "false" gesetzt sein.
Weitere Informationen finden Sie in der RedHat OpenShift-Dokumentation.
Alternativ erteilen Sie dem arcgis-elastic-serviceaccount-Service-Konto die Erlaubnis zum Ausführen eines Containers mit Berechtigungen, damit der Init-Container den erforderlichen sysctl-Befehl ausführen kann.
oc adm policy add-scc-to-user privileged-esri system:serviceaccount:<deployment-project>:arcgis-elastic-serviceaccount
Weitere Informationen finden Sie in den Beispiel-SCC YAML-Dateien.
- Lassen Sie zu, dass die Pods mit einer bestimmten fsGroup ausgeführt werden.
- Konfigurieren Sie Red Hat OpenShift Routes.
OpenShift beinhaltet einen sofort einsatzbereiten Ingress-Controller, der in Verbindung mit dem Ingress-Controller verwendet werden kann, der im Lieferumfang von ArcGIS Enterprise on Kubernetes enthalten ist. Wenn Sie eine OpenShift-Route über die Befehlszeile erstellen, kann sie mithilfe der Beispiel-YAML-Datei erstellt werden. Um über die OpenShift-Konsole eine Route einrichten zu können, muss zunächst das Bereitstellungsskript ausgeführt werden. Anschließend kann eine Route erstellt werden, die auf das interne Service-Ziel verweist.
Wenn die Frage nach der OpenShift-Route im Bereitstellungsskript mit yes beantwortet wird, ist der ArcGIS-Ingress-Controller-Service nicht von außerhalb des Cluster-Subnetzes zugänglich und wird als ClusterIP-Typ erstellt.
Je nachdem, wo Sie den Client-SSL beenden möchten, sollte als Beendigungsmodus für die sichere Route entweder re-encrypt oder passthrough verwendet werden. Wenn Sie re-encrypt auswählen, benötigen Sie als Eingabe für die Route ein TLS-Zertifikat, während bei passthrough das in der Bereitstellungsphase definierte TLS-Zertifikat den externen Clients präsentiert wird.