Systemanforderungen

Nachfolgend werden die minimalen Hardware- und Infrastrukturanforderungen für die Ausführung von ArcGIS Enterprise on Kubernetes 11.0 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)

In dieser Produktversion wurden für jede Umgebung die folgenden unterstützten Versionen getestet:

ArcGIS Enterprise on Kubernetes	AKS	EKS	GKE	Red Hat OpenShift
Bereitstellen von Version 11.0 in einem vorhandenen Kubernetes-Cluster	1.21–1.24	1.21–1.24	1.21–1.24	4.7−4.10
Upgrade eines vorhandenen Kubernetes-Clusters nach Bereitstellung von Version 11.0	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt	N. z.

Hinweis:

Zum Aktivieren der automatischen Skalierung für GIS-Services benötigen Sie Metrics Server zum Sammeln von Knotenkennwerten. Beim Bereitstellen in EKS-Umgebungen müssen Sie Metrics Server mit Berechtigungen auf Cluster-Ebene im kube-system-Namespace installieren. In anderen unterstützten Umgebungen wird Metrics Server standardmäßig installiert.

Containerregistrierung

Container-Images für ArcGIS Enterprise on Kubernetes sind über ein privates Docker -Hub-Repository zugänglich. Esri bietet für die Benutzer Zugriff auf dieses Repository, die ArcGIS Enterprise on Kubernetes bereitstellen. Beim Bereitstellen in einer nicht verbundenen Umgebung müssen Sie die Containerregistrierung Ihrer Organisation verwenden.

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.

Kubernetes-Cluster

Für die Bereitstellung von ArcGIS Enterprise on Kubernetes wird ein Kubernetes-Cluster in einer der oben aufgeführten Umgebungen benötigt.

Hinweis:

Beim Erstellen eines Clusters in GKE müssen Sie den Standardmodus des Vorgangs verwenden. Der Autopilotmodus wird nicht unterstützt.

Hinweis:

In EKS müssen Sie bei der Erstellung oder beim Upgrade eines Clusters mit Kubernetes 1.23 und höheren Versionen das Add-on "Amazon EBS Container Storage Interface (CSI)" installieren. Weitere Informationen finden Sie in der Amazon EKS-Dokumentation.

Namespace

Für ArcGIS Enterprise on Kubernetes ist ein eigener dedizierter Namespace erforderlich. Dieser muss vor der Ausführung des Bereitstellungsskripts erstellt werden. Jede Bereitstellung von ArcGIS Enterprise on Kubernetes erfordert zudem einen dedizierten Namespace.

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
Standardverfügbarkeit	4	32	128
Erweiterte Verfügbarkeit	5	40	160
Entwicklung	3	24	96

Hinweis:

ArcGIS Enterprise on Kubernetes wird nur mit CPUs, die der x86_64-Architektur (64 Bit) entsprechen, unterstützt.

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.

Hinweis:

ArcGIS Enterprise on Kubernetes unterstützt keine Windows Server-Knoten-Images in GKE-Umgebungen.

Resource Quota-Objekt

Für ArcGIS Enterprise on Kubernetes-Pods bestehen vordefinierte Anforderungen und Beschränkungen für CPU und Arbeitsspeicher. Wenn der Namespace ein ResourceQuota-Objekt enthält, muss das Kontingent größer sein als die Summe der Anforderungen und Beschränkungen aller Pods. Wie im Folgenden beschrieben, sind diese Werte je nach ausgewähltem Architekturprofil unterschiedlich.

Hinweis:

Bei einem Upgrade auf Version 11.0 müssen Sie zunächst die Ressourcenkontingentwerte im Namespace gemäß den Anforderungen für Version 11.0 aktualisieren.

Am besten reservieren Sie mindestens 10 Prozent der Anforderungsressourcen für das ordnungsgemäße Funktionieren der Cluster-Knoten.

Die folgenden Kontingentempfehlungen für die einzelnen Profile beruhen auf den oben genannten Reservierungen. Die angegebenen Grenzwerte sind Platzhalter und müssen entsprechend den Skalierbarkeitsanforderungen konfiguriert werden:

Profil für Standardverfügbarkeit:

spec: 
    hard: 
      limits.cpu: "164" 
      limits.memory: 272Gi 
      requests.cpu: "24" 
      requests.memory: 108Gi

Profil für erweiterte Verfügbarkeit:

spec: 
    hard: 
      limits.cpu: "192" 
      limits.memory: 328Gi 
      requests.cpu: "30" 
      requests.memory: 156Gi

Entwicklungsprofil:

spec: 
    hard: 
      limits.cpu: "120" 
      limits.memory: 188Gi 
      requests.cpu: "16" 
      requests.memory: 72Gi

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 die defaultClusterRole "admin" zuweisen, indem Sie im Namespace eine RoleBinding erstellen.

Pod-Sicherheitsrichtlinie (eingeschränkter Sicherheitskontext in OpenShift) und virtueller Arbeitsspeicher

ArcGIS Enterprise on Kubernetes stellt Elasticsearch zur Unterstützung verschiedener Funktionen der ArcGIS Enterprise-Organisation bereit. Standardmäßig speichert Elasticsearch erforderliche Indizes im mmapfs-Verzeichnis. Die Standardbeschränkungen des Betriebssystems für die Zuordnungsanzahl sind für die Bereitstellung möglicherweise unzureichend. Elasticsearch empfiehlt für vm.max_map_count den Standardwert 262144. Die Änderung des Standardwerts erfordert eine höhere Berechtigung (Root-Berechtigung) für die einzelnen Knoten.

Je nachdem, ob im Kubernetes-Cluster eine Pod-Sicherheitsrichtlinie enthalten ist und Container mit oder ohne Berechtigungen ausgeführt werden können, sind folgende Maßnahmen erforderlich:

• Wenn im Kubernetes-Cluster keine Pod-Sicherheitsrichtlinie enthalten ist, aber Container mit Berechtigungen ausgeführt werden können, ist keine Aktion erforderlich.
• Mit Berechtigungen: Wenn für den Kubernetes-Cluster die Pod-Sicherheit definiert wurde und er die Ausführung von Containern mit Berechtigungen zulässt, müssen Sie dem Elasticsearch-Dienstkonto die Ausführung von Containern mit Berechtigungen erlauben. In anderen Dienstkonten brauchen keine Container mit Berechtigungen ausgeführt zu werden. ArcGIS Enterprise on Kubernetes kann einen Init-Container mit Berechtigungen auf dem Elasticsearch-Knoten ausführen, wobei der Wert von vm.max_map_count geändert wird. Das Bereitstellungsskript für ArcGIS Enterprise on Kubernetes erstellt unter dem eigenen Namespace ein Dienstkonto für die Verwendung der API-Server-Authentifizierung für Prozesse innerhalb der Pods. Der Elasticsearch-Pod verwendet das eigene Dienstkonto, das nicht für andere Workloads freigegeben ist. Als Elasticsearch-Dienstkonto wird standardmäßig das Konto arcgis-elastic-serviceaccount verwendet. Sie können der Pod-Sicherheitsrichtlinie mit RBAC-Rollen und RoleBindings den Zugriff auf das Dienstkonto gewähren. Unter OpenShift können Sie dem eingeschränkten Sicherheitskontext mit Berechtigungen den Zugriff auf das Dienstkonto gewähren, indem Sie Folgendes zum Benutzerabschnitt hinzufügen:
  “-system:serviceaccount: <Namespace>:arcgis-elastic-serviceaccount"
  

• Ohne Berechtigungen: Wenn für den Kubernetes-Cluster die Pod-Sicherheit definiert wurde und er dem Elasticsearch-Dienstkonto die Ausführung von Containern mit Berechtigungen nicht erlauben kann, müssen Sie jeden Knoten manuell einrichten, indem Sie den folgenden Befehl als Root-Benutzer ausführen:
  sysctl -w vm.max_map_count=262144
  

• Wenn Sie die PodSecurityPolicy-Ressource erstellt haben, müssen Sie im ArcGIS Enterprise-Namespace die folgenden Dienstkonten autorisieren.
  • arcgis-admin-serviceaccount
  • arcgis-elastic-serviceaccount
  • arcgis-ingress-serviceaccount
  • arcgis-prometheus-serviceaccount
  • arcgis-queue-serviceaccount
  • default

  ArcGIS Enterprise on Kubernetes-Container können ohne Root-Berechtigungen ausgeführt werden. Allerdings muss der Steuerungsaspekt von fsGroup und supplementalGroups von PodSecurityPolicy entweder RunAsAny oder einen Bereich mit dem Wert 117932853 enthalten, wie in den folgenden Beispielen dargestellt.

  supplementalGroups:
      rule: 'RunAsAny'
  fsGroup:
      rule: 'RunAsAny'
  

  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 117932853
  
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 117932853
  

Wenn Sie Kubernetes NetworkPolicies verwenden, stellen Sie sicher, dass im ArcGIS Enterprise-Namespace eine unterbrechungsfreie Kommunikation zwischen den Pods und zwischen Pods und Services erlaubt sind.

Stellen Sie zudem auch sicher, dass die Pods im Namespace Zugriff auf den Kubernetes-API-Server haben. Auf den API-Server kann über einen Service mit dem Namen Kubernetes im Standard-Namespace zugegriffen werden. ArcGIS Enterprise-Pods nutzen den vollständig qualifizierten Domänennamen (FQDN) kubernetes.default.svc.cluster.local, um den API-Server abzufragen.

Hinweis:

cluster.local ist die Standarddomäne des Clusters.

Hinweis:

Pods im Cluster müssen mit der FSGroup- und SupplementalGroup-ID 117932853 ausgeführt werden können.

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. Wenn Sie AKS oder EKS verwenden, können Sie 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.

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.

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. Diese können dynamisch oder statisch bereitgestellt werden. Für beide Arten von PVs können Sie benutzerdefinierte (größere) Größen und Bezeichnungen verwenden. Zu den zustandsbehafteten Workloads von ArcGIS Enterprise gehören sowohl relationale Datenbankmanagementsysteme als auch NoSQL-Datenbanken. Es wird empfohlen, Blockspeichergeräte mit geringer Latenz zu verwenden, wie etwa EBS-Volumes, Azure-Datenträger oder vSphereVolume.

Da auf diesen persistenten Volumes Daten und Einstellungen gespeichert werden, sollten sie mit restriktiven Sicherheitsrichtlinien geschützt werden. Legen Sie bei persistenten Volumes, die auf einer dateibasierten Speicherung beruhen, wie etwa NFS, Azure File oder Gluster, die Berechtigungen für die Verzeichnisse so fest, dass ein unberechtigter Zugriff nicht möglich ist. Begrenzen Sie bei Blockspeichern wie EBS-Volumes, Azure-Datenträgern und iSCSI den Zugriff auf die Benutzer, die auf die Blockspeichergeräte zugreifen müssen.

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

Hinweis:

Die aufgeführten Anforderungen an PVs gelten für Version 11.0 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. Für die Bereitstellung sind vier Datenträger erforderlich.
• 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	Entwicklungsprofil	Profil für Standardverfügbarkeit	Profil für erweiterte Verfügbarkeit
in-memory-volume	1	1	1
item-packages-volume	1	2	2
object-volume	1	3	8
queue-volume	1	2	2
relational-volume	2	2	2
spatiotemporal-and-index-volume	1	3	5
usage-metric-volume	1	1	1

Beim Konfigurieren einer Organisation mit dem Setup-Assistenten werden für die Volume-Bindung Angaben wie die folgenden (Volume-Name, Größe, App und Ebene) verwendet. Sie können diese jedoch nach Bedarf anpassen:

Volume	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.

Anpassen statischer 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 reclaimPolicy-Parameter für die StorageClass muss auf retain festgelegt werden.

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:
  kind: StorageClass 
  apiVersion: storage.k8s.io/v1 
  metadata: 
    name: arcgis-storage-default 
  provisioner: kubernetes.io/azure-disk 
  parameters: 
    kind: Managed 
    storageaccounttype: Premium_LRS 
  reclaimPolicy: Retain
  allowVolumeExpansion: true
  volumeBindingMode: WaitForFirstConsumer
  

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

Sie können auch die zusammen mit einem AKS- oder EKS-Cluster bereitgestellten Standardspeicherklassen verwenden. In AKS ist dies die Speicherklasse "default (Azure disk)" oder "managed-premium". In EKS ist dies eine Speicherklasse vom Typ "GP2".

Client-Workstation

Die Bereitstellungsskripte sind Bash-Skripte, die über eine Remote-Client-Workstation ausgeführt werden können.

Hinweis:

Die verwendete Client-Workstation muss zu den unterstützten Umgebungen gehören. Linux-Emulatoren werden zum Bereitstellen 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.

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.0 ist die Begleitversion für ArcGIS Enterprise on Kubernetes 11.0. Wenn Sie die neuesten verfügbaren Funktionen nutzen möchten, dann verwenden Sie ArcGIS Pro 3.0.
• 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, dann müssen Sie Ihre Geodatabase auf Version 11.0.0.3.0 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.

• 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.
• 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.
• Wenn Sie ein Upgrade von Version 10.9.1 durchführen, müssen Sie mindestens fünfzig Prozent (50 %) an zusätzlichem Speicher für die Aufnahme neuer Objektspeicher-PVs für jedes Architektur-Profil bereitstellen. Wenn Sie zum Beispiel 100 GB Speicher für Objektspeicher-PVs pro Objektspeicher-Pod zugeordnet haben, müssen Sie mindestens 150 GB an zusätzlichem Speicher bereitstellen.
• 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 Containerregistrierung Ihrer Organisation verwendet haben, müssen Sie die erforderlichen Container-Images aus dem Esri Repository in die Registrierung 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- und Warteschlangenspeicher-Bereitstellung der Organisation ein item-packages- bzw. queue-volume-PV konfiguriert. Bei der Vorbereitung eines Upgrades muss für jeden Pod in der Portal-API- und Warteschlangenspeicher-Bereitstellung ein zusätzliches PV konfiguriert werden.

Wenn beispielsweise vor einem Upgrade drei ausgeführte Pods für die und Warteschlangenspeicher- oder 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- oder Warteschlangenspeicher-Bereitstellung verwendet und der ursprüngliche Satz kann entfernt werden.

Für Objektspeicher-Bereitstellungen müssen beim Upgrade zusätzliche statische PVs gemäß der folgenden Tabelle bereitgestellt werden:

Bereitstellungstyp	Statische Standard-object-volume-PVs	Zusätzlich erforderliche statische PVs für Upgrades
Entwicklungsprofil	1	1 zusätzliches PV erstellen
Profil für Standardverfügbarkeit	3	3 zusätzliche PVs erstellen
Profil für erweiterte Verfügbarkeit	8	8 zusätzliche PVs erstellen