Systemanforderungen

Nachfolgend werden die minimalen Hardware- und Infrastrukturanforderungen für die Ausführung von ArcGIS Enterprise on Kubernetes 11.1 beschrieben. Diese Anforderungen gelten auch beim Bereitstellen in einer nicht verbundenen Umgebung.

Unterstützte Umgebungen

Die Systemanforderungen und Spezifikationen gelten für alle unterstützten Umgebungen, sofern nicht anders angegeben. Diese Version unterstützt die folgenden Umgebungen:

• Lokale Rechenzentren
  • Red Hat OpenShift Container Platform
• Verwaltete Kubernetes-Services in der Cloud
  • Amazon Elastic Kubernetes Service (EKS)
  • Google Kubernetes Engine (GKE)
  • Microsoft Azure Kubernetes Service (AKS)

Es wird empfohlen, die automatischen Upgrades in Ihrem Kubernetes-Cluster zu deaktivieren. Wenn die automatischen Upgrades in Ihrem Cluster aktiviert sind, werden die Knoten automatisch auf die neueste Version von Kubernetes aktualisiert. Diese zukünftigen Versionen werden jedoch möglicherweise noch nicht für ArcGIS Enterprise unterstützt.

Vorsicht:

Beim Upgrade der Umgebung müssen Sie zunächst ein Upgrade für ArcGIS Enterprise on Kubernetes durchführen, bevor ein Upgrade von Kubernetes auf eine unterstützte Version möglich ist.

Für jede Umgebung wurden die folgenden Versionen getestet und werden unterstützt:

Unterstützte Umgebung	Unterstützte Kubernetes-Version
Verwaltete Kubernetes-Services in der Cloud (AKS, EKS, GKE)	1.23–1.25
Red Hat OpenShift Container Platform	4.10–4.12

Hinweis:

ArcGIS Enterprise on Kubernetes wird nur mit CPUs, die der x86_64-Architektur (64 Bit) entsprechen, unterstützt. Es müssen Linux-basierte Worker-Knoten eingesetzt werden.

Container registry

Container-Images für ArcGIS Enterprise on Kubernetes sind über eine private Docker-Hub-Organisation zugänglich. Esri bietet Benutzern, die ArcGIS Enterprise on Kubernetes bereitstellen, Zugriff auf die Repositorys dieser Organisation. Beim Bereitstellen in einer nicht verbundenen Umgebung müssen Sie die Images aus der privaten Docker-Hub-Organisation in die Container-Registry Ihrer Organisation verschieben, die über Ihren Cluster zugänglich ist.

Abrufen einer Esri Lizenz

Damit Sie Ihre ArcGIS Enterprise-Organisation während der Bereitstellung autorisieren können, benötigen Sie eine ArcGIS Enterprise on Kubernetes-Lizenzdatei im JSON-Format (.json-Datei). Diese Lizenzdatei erhalten Sie mit den Berechtigungen zum Ausführen von Lizenzierungsaktionen unter My Esri.

CPU und Speicher

ArcGIS Enterprise on Kubernetes wird mit einem von drei Architekturprofilen bereitgestellt. Die Empfehlungen für Ressourcenanforderungen und -beschränkungen (CPU und Speicher) sowie für die Compute-Anforderungen insgesamt sind je nach ausgewähltem Profil unterschiedlich. Die Empfehlungen für die einzelnen Profile werden im Folgenden aufgeführt.

Für die einzelnen Architekturprofile gelten die folgenden Mindestanforderungen für Knoten. Jeder Worker-/Agent-Knoten sollte über mindestens 8 CPUs und 32 GiB Speicher verfügen.

Architekturprofil	Mindestens erforderliche Worker-/Agent-Knoten	Insgesamt mindestens erforderliche CPUs	Insgesamt mindestens erforderliche GiB
Erweiterte Verfügbarkeit	5	40	160
Standardverfügbarkeit	4	32	128
Entwicklung	3	24	96

Die Pods in der ArcGIS Enterprise on Kubernetes-Bereitstellung werden auf die Worker-Knoten im Cluster verteilt. Wenn Sie die Bereitstellung skalieren oder eine weitere ArcGIS Enterprise-Bereitstellung zum Cluster hinzufügen, müssen Sie entsprechend mehr Hardware bereitstellen. Dadurch kann sich die maximale Standardanzahl von Pods je Knoten erhöhen. Die Anzahl der anfänglich erstellten Pods ist je nach Architekturprofil unterschiedlich. Wenn Sie horizontal skalieren oder neue Funktionalitäten hinzufügen, erhöht sich die Anzahl der Pods.

Sicherheit

Nachfolgend werden die Sicherheitsanforderungen für ArcGIS Enterprise on Kubernetes beschrieben.

Rollenbasierte Zugriffssteuerung

Im Kubernetes-Cluster muss die rollenbasierte Zugriffssteuerung (Role-based access control, RBAC) aktiviert werden. Sie benötigen für die Bereitstellung von ArcGIS Enterprise on Kubernetes keine Admin-Berechtigungen für den Cluster. Benutzer ohne Admin-Berechtigungen für den Cluster benötigen mindestens Administratorberechtigungen für den Namespace. Sie können dem Benutzer eine Standard-ClusterRole zuweisen, indem Sie im Namespace eine RoleBinding erstellen.

Registrieren eines Datenorders

Um Elemente zu veröffentlichen, die dateibasierte Daten verwenden, wie zum Beispiel Elemente, die aus einer File-Geodatabase veröffentlicht wurden, müssen Sie die Daten an einem freigegebenen NFS-Speicherort ablegen. Diese NFS-Freigabe muss bei der ArcGIS Enterprise-Organisation registriert werden, um das Kopieren der Daten auf den Server beim Veröffentlichen zu vermeiden. Um den freigegebenen Ordner erfolgreich zu registrieren, müssen Sie anderen Benutzern die Berechtigungen zum Lesen auf Dateiebene erteilen. Die NFS-Freigabe können Sie auf Netzwerk- oder Infrastrukturebene sichern, indem Sie den Netzwerkzugriff auf den Pod-IP-Bereich erlauben.

Netzwerk

Zu den Netzwerkanforderungen gehören ein FQDN und ein Load Balancer. Details zu den einzelnen Anforderungen finden Sie unten.

Vollständig qualifizierter Domänenname

ArcGIS Enterprise on Kubernetes erfordert einen FQDN, z. B. map.company.com. Zur Erstellung können Sie ein vorhandenes Domain Name System (DNS) oder ein Cloud DNS wie Amazon Route 53 verwenden. Sie können den DNS-Datensatz nach der Bereitstellung erstellen, seinen Wert müssen Sie aber währenddessen definieren. In dieser Version kann der FQDN nach der Bereitstellung nicht mehr geändert werden.

Load Balancer

Ein Load Balancer ist erforderlich, um Datenverkehr auf die einzelnen Worker-Knoten zu verteilen. Sie können die folgenden Load Balancer ohne manuelle Konfiguration aus dem Bereitstellungsskript bereitstellen:

• Azure Load Balancer (öffentlich oder intern): Im Bereitstellungsskript kann eine vorab bereitgestellte öffentliche IP-Adresse und eine DNS-Bezeichnung angegeben werden.
• AWS Network Load Balancer (mit Internetzugriff oder intern): Es können auch andere Load-Balancer-Dienste verwendet werden; diese müssen allerdings an jedem einzelnen Cluster-Knoten manuell konfiguriert werden.

  Hinweis:

  Das AWS Load Balancer Controller-Add-on ist erforderlich, um Network Load Balancer in einem öffentlichen oder einem privaten Subnetz zu erstellen.

• Google Cloud Platform TCP Load Balancer (mit Internetzugriff oder intern): Im Bereitstellungsskript kann eine vorab bereitgestellte statische öffentliche IP-Adresse angegeben werden.

Auf einer OpenShift-Containerplattform können Routen konfiguriert werden, wenn diese auf den Eingangs-Controller-Dienst verweisen.

Sie können einen selbstverwalteten Load Balancer verwenden, der auf die Worker-Knoten am NodePort des Eingangs-Controller-Diensts verweist. Näheres hierzu finden Sie in der Beschreibung der Parameter in der Bereitstellungsanleitung für den Load Balancer.

Geben Sie bei Verwendung eines selbstverwalteten Load Balancers oder Reverseproxys wie NGINX die folgende Verbindung an: proxy_set_header X-Forwarded-Host $host;. Dieser Header wird benötigt, um sicherzustellen, dass Traffic ordnungsgemäß an die URL Ihrer ArcGIS Enterprise-Organisation weitergeleitet wird.

Hinweis:

Die SSL-Auslagerung über einen Reverseproxy oder Load Balancer wird von ArcGIS Enterprise nicht unterstützt. Wird in Ihrer Konfiguration ein Reverseproxy verwendet, muss die Weiterleitung über HTTPS entweder an ArcGIS Web Adaptor oder direkt an die Organisation erfolgen.

IP-Anforderungen

Für die erfolgreiche Bereitstellung Ihres Cluster-Netzwerks mit geeigneten Skalierungsanforderungen und der Möglichkeit von Upgrades ist die entsprechende Planung im Voraus unerlässlich. Je nach Architektur-Profil stellt ArcGIS Enterprise on Kubernetes anfänglich 47−66 Pods bereit. Die Anzahl der Pods nimmt zu, wenn zusätzliche Funktionen hinzugefügt werden, die Bereitstellung skaliert wird und ein Upgrade durchgeführt wird.

Jedem Pod wird eine eindeutige IP-Adresse zugewiesen, die je nach Konfiguration des Cluster-Netzwerks aus einem Adressraum, der sich logisch von dem des Host-Netzwerks (Overlay-Netzwerk) unterscheidet, oder vom Host-Teilnetz stammen kann. Wenn Sie zum Beispiel Ihren Cluster so konfigurieren, dass Kubenet in Azure verwendet wird (Standard), dann erhalten die Pods eine IP-Adresse aus einem logisch anderen Adressraum und können Azure-Ressourcen unter Verwendung von NAT erreichen.

Kubernetes unterstützt Container Networking Interface (CNI) und Plattformen wie AKS und EKS, die plattformspezifische CNI-Plug-ins für den Cluster-Netzwerkbetrieb verwenden. EKS-Cluster verwenden zum Beispiel standardmäßig VPC-CNI (Virtual Private Cloud CNI). Wenn der Cluster mit einem CNI-Plug-in konfiguriert ist, dann erhalten die Pods ihre IP-Adressen aus dem Host-Teilnetz und einem entsprechenden Pool der verfügbaren IPs im VPC/VNet.

Wenn die Anzahl der verfügbaren IPs in den Host-Teilnetzen nicht ausreicht, dann schlägt die Bereitstellung entweder sofort fehl oder kann von Ihnen später nicht skaliert werden. Wenn zum Beispiel ein EKS-Cluster mit jeweils 2 Teilnetzen und einem /26-IPv4-Adresspräfix (jeweils 64 verfügbare IPv4-Adressen) konfiguriert ist, dann können nicht mehr als 126 IP-Adressen für die Pods verfügbar sein. Sie können zwar möglicherweise ArcGIS Enterprise on Kubernetes in diesem Cluster bereitstellen, sind dann aber nicht in der Lage, diese Bereitstellung auf 80 Feature-Service-Pods zu skalieren, da diese Skalierungsanforderung die Anzahl der verfügbaren IP-Adressen überschreitet.

Systemspeicher

ArcGIS Enterprise on Kubernetes erfordert persistente Datenträger (PVs) für den Systemspeicher, die dynamisch über eine Speicherklasse oder statisch durch einen Administrator bereitgestellt werden können, bevor die Organisation erstellt wird. Zu den zustandsbehafteten Workloads von ArcGIS Enterprise gehören relationale Datenbankmanagementsysteme und NoSQL-Datenbanken. Es wird empfohlen, PVs auf Blockspeichergeräten mit geringer Latenz bereitzustellen, wie etwa auf EBS-Volumes bei Verwendung von EKS, auf Azure-Datenträgern bei Verwendung von AKS, auf persistenten Datenträgern bei Verwendung von GKE und auf vSphereVolume oder Longhorn-Volumes bei lokalen Bereitstellungen.

Da auf diesen PVs Daten und Einstellungen gespeichert werden, müssen Sie sie mit restriktiven Sicherheitsrichtlinien schützen. Legen Sie bei PVs, die auf einer Netzwerkdateispeicherung beruhen, wie etwa NFS, Azure Files oder GlusterFS, die Berechtigungen so fest, dass ein unberechtigter Zugriff nicht möglich ist. Begrenzen Sie bei Blockspeichern wie EBS, Azure Disk, vSphereVolume und Longhorn-Volumes den Zugriff auf die Speichervolumen auf diejenigen Benutzer, die Zugriff benötigen.

Im Folgenden werden Speicher-Volumes und der jeweils vorgesehene Zweck beschrieben:

Hinweis:

Die aufgeführten Anforderungen an PVs gelten für Version 11.1 und können sich von vorherigen Versionen unterscheiden.

• In-Memory: Speichert temporäre Systemressourcen.
• Elementpakete: Speichert umfangreiche Uploads und Pakete im Rahmen von Veröffentlichungs-Workflows.
• Objekt: Speichert hochgeladene und gespeicherte Inhalte, gehostete Kachel- und Bild-Layer-Caches sowie Geoverarbeitungsausgaben.
• Warteschlange: Speichert asynchrone Geoverarbeitungsaufträge.
• Relational: Speichert gehostete Feature-Daten und administrative Elemente wie Anpassungs- und Konfigurationseinstellungen. Für die Bereitstellung sind zwei Datenträger erforderlich.
• Spatiotemporal und Index: Speichert Protokolle und Indizes sowie gehostete Feature-Daten.
• Nutzungskennwertdaten: Speichert Nutzungsdaten für GIS-Services.

Definieren Sie die Größe der einzelnen PVs anhand der Speicheranforderungen Ihrer Organisation.

Statische PVs

Wenn Sie statische PVs vor der Bereitstellung zur Verfügung stellen, werden die unten beschriebenen Spezifikationen und Bezeichnungen empfohlen.

Im Folgenden wird die Anzahl der für die einzelnen Architekturprofile erforderlichen PVs aufgeführt.

Volumen	Profil für erweiterte Verfügbarkeit	Profil für Standardverfügbarkeit	Entwicklungsprofil
in-memory-volume	1	1	1
item-packages-volume	2	2	1
object-volume	8	3	1
queue-volume	2	2	1
relational-volume	2	2	2
spatiotemporal-and-index-volume	5	3	1
usage-metric-volume	1	1	1

Wenn Sie Ihre Organisation so konfigurieren, dass vorhandene statische PVs verwendet werden, werden die folgenden Werte der einzelnen persistenten Volumen (PVC) verwendet, um sie per Beschriftungsauswahl an die PVs zu binden: Größe, Zugriffsmodus und Beschriftungen. Diese Werte können im Setup-Assistenten oder in der Datei mit den Konfigurationseigenschaften so angepasst werden, dass die vorab bereitgestellten PVs mit den einzelnen zustandsbehafteten Spezifikationen übereinstimmen.

Volumen	Größe in GiB (Minimum)	Zugriffsmodus	Beschriftung
in-memory-volume	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=ignite
item-packages-volume	16	ReadWriteOnce	arcgis/tier=api, arcgis/app=sharing
object-volume	32	ReadWriteOnce	arcgis/tier=storage, arcgis/app=ozone
queue-volume	16	ReadWriteOnce	arcgis/tier=queue, arcgis/app=rabbitmq
relational-volume	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=postgres
spatiotemporal-and-index-volume	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=elasticsearch
usage-metric-volume	30	ReadWriteOnce	arcgis/tier=storage, arcgis/app=prometheus

Zusätzliche Überlegungen für statische PVs

Die Anforderungen für Upgrades und die Skalierung sind abhängig vom Typ des bereitgestellten Speichers, den Sie bei der Bereitstellung konfigurieren:

• Dynamische PVs: Der Speicher wird durch die Software skaliert und angepasst, sofern genügend Speicher verfügbar ist und die Speicherklassenspezifikationen eingehalten werden.
• Statische PVs: Wenn Sie die Einrichtung für Ihre Bereitstellung vorbereiten, müssen Sie zusätzliche item-packages-PVs mit denselben Spezifikationen (Beschriftungen, Größe und Zugriffsmodus), die auch bei der Bereitstellung angegeben wurden, bereitstellen, damit die Workflows für Skalierung und Upgrade unterstützt werden.

Erstellen zusätzlicher PVs zur Skalierung der Portal-API-Bereitstellung

Zur Skalierung der Portal-API-Bereitstellung (Erhöhung der Anzahl der beteiligten Pods) wird ein zusätzliches item-packages-PV für jeden zusätzlichen Pod, der der Bereitstellung hinzugefügt wird, benötigt. Wenn die Organisation beispielsweise drei zusätzliche Pods für die Portal-API-Bereitstellung benötigt, müssen mindestens drei zusätzliche item-packages-PVs bereitgestellt und mit Spezifikationen konfiguriert werden, die den bei der Bereitstellung angegebenen Spezifikationen entsprechen.

Dynamische PVs

Bei der dynamischen Bereitstellung ist eine StorageClass erforderlich.

Der Parameter reclaimPolicy für die StorageClass kann auf Löschen festgelegt werden, um die Verwaltung zu vereinfachen. Dadurch wird das verbundene PV bereinigt, wenn ein PVC gelöscht wird (wenn Sie beispielsweise die Bereitstellung der Software aufheben).

Bei der Konfiguration des gehosteten Sicherungsspeichers sollte eine separate StorageClass verwendet werden, wobei der Parameter reclaimPolicy auf Beibehalten festgelegt werden sollte, damit das PV dauerhaft weiterbesteht, wenn Sie die Bereitstellung aufheben und erneuern.

Der Parameter allowVolumeExpansion der StorageClass kann auf true gesetzt werden, wenn Ihr Speicher-Provider die Erweiterung von PVs unterstützt.

Hinweis:

Premiumdatenträger in Azure werden nicht von allen VM-Typen unterstützt. Wenn der VM-Typ Premiumdatenträger unterstützt, verwenden Sie einen Premiumdatenträger.

• Es folgt ein Beispiel für eine StorageClass-Definition mit Azure Premium-Datenträger unter AKS:
  apiVersion: storage.k8s.io/v1  
  kind: StorageClass  
  metadata: 
    name: arcgis-storage-default 
  provisioner: disk.csi.azure.com 
  parameters: 
    kind: Managed 
    storageaccounttype: Premium_LRS 
  reclaimPolicy: Delete
  allowVolumeExpansion: true
  volumeBindingMode: WaitForFirstConsumer
  

• Im Folgenden ein Beispiel für eine StorageClass-Definition mit EBS-Datenträgern vom Typ "GP3" unter EKS:
  apiVersion: storage.k8s.io/v1   
  kind: StorageClass 
  metadata: 
    name: arcgis-storage-default  
  provisioner: ebs.csi.aws.com 
  parameters: 
    fsType: ext4 
    type: gp3 
  reclaimPolicy: Delete
  allowVolumeExpansion: true
  volumeBindingMode: WaitForFirstConsumer
  

• Es folgt ein Beispiel für eine StorageClass-Definition mit persistentem SSD-Datenträger unter GKE:
  apiVersion: storage.k8s.io/v1   
  kind: StorageClass 
  metadata: 
    name: arcgis-storage-default  
  provisioner: pd.csi.storage.gke.io 
  parameters: 
    type: pd-ssd 
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer
  allowVolumeExpansion: true
  

Sie können auch die zusammen mit einem EKS-Cluster (GP2), AKS-Cluster (managed oder managed-premium) oder GKE-Cluster (persistentdisk) bereitgestellten Standardspeicherklassen verwenden, aber möglicherweise müssen Sie einen CSI-Treiber installieren, damit die Bereitstellung in Kubernetes Version 1.23 oder höher unterstützt wird. Sie müssen bestätigen, dass die Eigenschaften reclaimPolicy und allowVolumeExpansion Ihrem Bedarf entsprechen, bevor Sie die Organisation erstellen.

Client-Workstation

Die Bereitstellungsskripte sind Bash-Skripte, die über eine Remote-Client-Workstation ausgeführt werden können. Der Benutzer, der die Skripte ausführt, muss Lese- und Schreibzugriff auf die Skripte haben, um temporäre Ressourcendateien in Unterverzeichnisse schreiben zu können.

Hinweis:

Aufgrund bekannter Kompatibilitätsprobleme werden Linux-Emulatoren zur Bereitstellung von ArcGIS Enterprise on Kubernetes nicht unterstützt.

Für die Einrichtung Ihrer Client-Workstation benötigen Sie folgende Komponenten (Links für den Download anbei):

• Kubectl
• Eine umgebungsspezifische Befehlszeilenschnittstelle (CLI)

Kubectl ist für die Ausführung des Bereitstellungsskripts erforderlich. Laden Sie das Kubernetes-Befehlszeilenwerkzeug über Kubectl installation and setup herunter.

Hinweis:

Die kubectl-Client-Version muss Teil einer Nebenversion der Kubernetes-Server-Version sein. Beispielsweise ist kubectl 1.24 mit den Kubernetes-Cluster-Versionen 1.23–1.25 kompatibel.

Zur Verwaltung Ihrer Bereitstellung können Sie umgebungsspezifische Befehlszeilenwerkzeuge verwenden. Links für den Download der umgebungsspezifischen Befehlszeilenschnittstelle:

• Azure CLI
• AWS CLI
• GKE CLI
• OpenShift CLI

TLS certificate

ArcGIS Enterprise on Kubernetes verwendet einen auf NGINX-basierenden Eingangs-Controller. Dieser ist Namespace-bezogen und wird bereitgestellt, um ausschließlich den eingehenden Datenverkehr für den ArcGIS Enterprise-Namespace abzuhören. Für den FQDN im allgemeinen Namen des Zertifikats und den alternativen Namen ist ein TLS-Zertifikat erforderlich. Hierbei kann ein von einer Zertifizierungsstelle signiertes Zertifikat oder ein selbstsigniertes Zertifikat verwendet werden. Aus Sicherheitsgründen wird ein von einer Zertifizierungsstelle signiertes Zertifikat empfohlen. Dies ist das Standard-TLS-Zertifikat für den Eingangs-Controller. Im Bereitstellungsskript stehen die folgenden Zertifikatoptionen für die Anwendung eines TLS-Zertifikats für eingehenden Datenverkehr zur Verfügung:

• Ein vorhandenes TLS-Secret mit einem privaten Schlüssel und einem Zertifikat
• Eine .pfx-Datei mit einem privaten Schlüssel und einem Zertifikat
• Ein PEM-formatierter privater Schlüssel und ein Zertifikat
• Ein selbstsigniertes Zertifikat

ArcGIS Enterprise on Kubernetes unterstützt die Verwendung eines TLS-Zertifikats für den Eingangs-Controller, das durch Kubernetes cert-manager ausgegeben und verwaltet wird. Diese Zertifikat muss in einem TLS-Secret im selben Namespace wie ArcGIS Enterprise gespeichert werden. Das TLS-Secret kann dann entweder während der Bereitstellung oder nach der Erstellung der ArcGIS Enterprise-Organisation referenziert werden.

ArcGIS Pro

• ArcGIS Pro 3.1 ist die Begleitversion für ArcGIS Enterprise on Kubernetes 11.1. Wenn Sie die neuesten verfügbaren Funktionen nutzen möchten, verwenden Sie ArcGIS Pro 3.1.
• Zum Veröffentlichen von Services in ArcGIS Enterprise on Kubernetes ist ArcGIS Pro 2.8 oder höher erforderlich.
• Zum Verwenden von Services aus ArcGIS Enterprise on Kubernetes ist ArcGIS Pro 2.7 oder höher erforderlich.

Beim Registrieren eines Data-Store-Elements aus einer Enterprise-Geodatabase muss die Geodatabase die Version 10.9.0.2.8 oder höher aufweisen.

Hinweis:

Wenn Sie die neuesten verfügbaren Funktionen nutzen möchten, müssen Sie Ihre Geodatabase auf Version 11.1.0.3.1 aktualisieren.

Die Geodatabase-Versionsnummer ist eine Kombination aus der ArcGIS Enterprise- und der ArcGIS Pro-Versionsnummer. Weitere Informationen hierzu finden Sie unter Client- und Geodatabase-Kompatibilität.

Anforderungen für Upgrades und Aktualisierungen

Bevor Sie ein Upgrade durchführen können, müssen einige Anforderungen erfüllt werden, wie zum Beispiel.

• Beim Upgrade der Umgebung müssen Sie zunächst ein Upgrade für ArcGIS Enterprise on Kubernetes durchführen, bevor ein Upgrade von Kubernetes auf eine unterstützte Version möglich ist.
• Wenn eine erforderliche Aktualisierung verfügbar ist, müssen Sie diese anwenden, bevor Sie ein Upgrade auf diese Version durchführen. In den Versionshinweisen finden Sie Informationen zur letzten erforderlichen Aktualisierung.
• Sie benötigen eine einheitliche ArcGIS Enterprise on Kubernetes-Lizenz für diese Version.
• Sie müssen die Ressourcenkontingentwerte in Ihrem Namespace gemäß den aktuellen Anforderungen aktualisieren.
• Vergewissern Sie sich, bevor Sie das Upgrade durchführen, dass Ihre Umgebung die Pod-Sicherheitsstandards erfüllt, wie z. B. die Pod-Sicherheitszugangsstandards.
• Wenn Ihre Umgebung sich im Red Hat OpenShift Container Platform befindet, stellen Sie sicher, dass sie die aktuellen Sicherheitskontextbeschränkungen einhält.
• Wenn Sie statische PVs bereitgestellt haben, müssen Sie zusätzlichen Speicher bereitstellen, um die Upgrade-Anforderungen zu erfüllen. Weitere Informationen finden Sie im Abschnitt Anpassen statischer PVs für Upgrades.
• Wenn Ihr bereitgestellter Speicher dynamische PVs enthält, müssen Sie sicherstellen, dass ausreichend Speicher für die zusätzlichen Elementpakete, das object-volume und das queue-volume vorhanden ist.
• Führen Sie das Preupgrade-Skript aus. Mit diesem Skript stellen Sie sicher, dass die Funktionsanforderungen den Anforderungen der aktuellen Softwareversion gerecht werden.
• Wenn Sie einen Web Adaptor mit Ihrer Organisation konfiguriert haben, dann lesen Sie die Anforderungen für Installation und Aktualisierung.
• Wenn sich Ihre Organisation in einer nicht verbundenen Umgebung befindet, dann befolgen Sie die Schritte zum Installieren eines Upgrades oder Updates in nicht verbundenen Umgebungen.
• Wenn Sie bei der Bereitstellung von ArcGIS Enterprise on Kubernetes die Container-Registry Ihrer Organisation verwendet haben, müssen Sie die erforderlichen Container-Images aus dem Esri Repository in die Registry Ihrer Organisation kopieren, bevor Sie das Update oder das Upgrade ausführen.

Anpassen statischer PVs für Upgrades

Vor einem Upgrade wurde für jeden Pod in der Portal-API-Bereitstellung der Organisation ein item-packages volume-PV konfiguriert. Bei der Vorbereitung eines Upgrades muss für jeden Pod in der Portal-API-Bereitstellung ein zusätzliches PV konfiguriert werden.

Wenn beispielsweise vor einem Upgrade drei ausgeführte Pods für die Portal-API-Bereitstellung konfiguriert werden, müssen drei zusätzliche PVs bereitgestellt und mit Spezifikationen konfiguriert werden, die den während der Bereitstellung angegebenen Spezifikationen entsprechen.

Nachdem das Upgrade abgeschlossen ist, werden die neu bereitgestellten Persistent Volumes und Persistent Volume Claims in der Portal-API-Bereitstellung verwendet und der ursprüngliche Satz kann entfernt werden.