Nachfolgend werden die minimalen Hardware- und Infrastrukturanforderungen für die Ausführung von ArcGIS Enterprise on Kubernetes 11.3 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:
- Red Hat OpenShift Container Platform (RHOS)
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Microsoft Azure Kubernetes Service (AKS)
- Rancher Kubernetes Engine (RKE und RKE2)
Es wird empfohlen, die automatischen Upgrades im 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:
Um volle Kompatibilität und Unterstützung zu gewährleisten, vergewissern Sie sich vor dem Upgrade von ArcGIS Enterprise on Kubernetes, dass Ihre Kubernetes-Version unterstützt wird.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) Red Hat OpenShift Container Platform(einschließlich ROSA und ARO) [4.14] RKE und RKE2 | 1.27 - 1.29 |
Hinweis:
ArcGIS Enterprise on Kubernetes wird nur mit CPUs, die der x86_64-Architektur (64 Bit) entsprechen, unterstützt. Worker-Knoten müssen auf Linux basieren.
Containerregistrierung
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 Ihre eigene private Container-Registry 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 unter My Esri mit den Berechtigungen zum Ausführen von Lizenzierungsaktionen.
Worker-Knoten
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. Es werden zusätzliche Worker-Knoten benötigt, um die Skalierung von Workloads und die Aktivierung von Funktionen in Ihrer Organisation zu unterstützen.
Jeder Worker-/Agent-Knoten sollte über mindestens 8 CPUs und 32 GiB Speicher verfügen. Damit der Download der Container-Images, die zu ArcGIS Enterprise on Kubernetes gehören, ausgeglichen werden kann, empfiehlt es sich außerdem, mindestens 100 GiB Speicherplatz auf dem Stammlaufwerk zur Verfügung zu haben.
| 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. Die Uhren der Worker-Knoten müssen mit einer gemeinsamen Quelle synchronisiert werden, damit die Zeiten innerhalb des Clusters einheitlich sind. 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 Funktionalität 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. Weitere Informationen finden Sie in der RBAC-Rollenressource.
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 vollständig qualifizierter Domänenname (FQDN) und ein Load Balancer oder Reverseproxy, der den Datenverkehr von Clients über den Standard-HTTPS-Port (443) zu den konfigurierten Back-End-Zielen leitet. 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 einen vorhandene DNS (Domain Name System)-Service verwenden, um einen CNAME- oder A-Eintrag zu erstellen, oder Sie können sich in den DNS-Service eines Cloud-Anbieters wie Amazon Route 53 integrieren. Sie können den DNS-Datensatz nach der Bereitstellung erstellen, der FDQN muss jedoch während der Bereitstellung verfügbar sein. In dieser Version kann der FQDN nach der Bereitstellung nicht mehr geändert werden.
Load Balancer
Ein Load Balancer kann verwendet werden, um Datenverkehr an Ihre ArcGIS Enterprise on Kubernetes-Bereitstellung weiterzuleiten. Sie können die beiden Load Balancer auf Schicht 4 und Schicht 7 ohne manuelle Konfiguration aus dem Bereitstellungsskript bereitstellen: Load Balancer, die über das Bereitstellungsskript in die Bereitstellung integriert sind, leiten den Datenverkehr direkt an den NGINX-Ingress-Controller-Pod im Cluster weiter.
Alternativ können Sie ArcGIS Enterprise on Kubernetes Web Adaptor verwenden, um Datenverkehr an die Bereitstellung weiterzuleiten. Dafür muss der eingehende Datenverkehr auf einem bestimmten Port an die Worker-Knoten der Organisation gesendet werden.
Die folgenden Load Balancer auf Schicht 4 können ohne manuelle Konfiguration aus dem Bereitstellungsskript bereitgestellt werden:
- 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.
Die oben angegebenen Load Balancer können mithilfe von Annotationen zum zugrunde liegenden Kubernetes Service-Objekt angepasst werden. Sie können beispielsweise auf einem Network Load Balancer in AWS das zonenübergreifende Load-Balancing aktivieren oder einen Azure Blob Load Balancer einer bestimmten Ressourcengruppe zuordnen. Die im Bereitstellungsskript enthaltene deploy.properties-Vorlagendatei beinhaltet Beispiele für die Angabe von Annotationen während der automatischen Bereitstellung.
Das Bereitstellungsskript kann verwendet werden, um Load-Balancing-Funktionen auf Schicht 7 einzusetzen (z. B. eine Web Application Firewall) oder Organisationsanforderungen für eingehenden Datenverkehr zur bereitgestellten Anwendung über einen bereits vorhandenen Ingress-Controller zu erfüllen. Die folgenden Load Balancer auf Schicht 7 können direkt aus dem Bereitstellungsskript bereitgestellt oder integriert werden.
- AWS Application Load Balancer
Hinweis:
Das AWS Load Balancer Controller-Add-on ist erforderlich, um Application Load Balancer in einem öffentlichen oder einem privaten Subnetz zu erstellen.
- Azure Application Gateway
- Google Cloud Platform Application Load Balancer
Ein auf Clusterebene implementierter Ingress-Controller verwendet diese Load Balancer für die Implementierung von Ingress-Regeln auf Clusterebene, um eingehenden Datenverkehr an eine ArcGIS Enterprise on Kubernetes-Bereitstellung weiterzuleiten. Um diese Load Balancer vor der automatischen Bereitstellung aus dem Bereitstellungsskript zu implementieren, können Sie eine YAML-Vorlagendatei im layer-7-templates-Ordner ändern, sie auf der Client-Workstation speichern und diesen Speicherort für den Parameter CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME angeben. Siehe Ingress-Controller auf Clusterebene für weitere Informationen.
Bei Verwendung eines selbstverwalteten Load Balancers oder Reverseproxys wie NGINX muss der X-Forwarded-Host-Header auf den Host-Header-Wert der client-gerichteten URL festgelegt werden, um sicherzustellen, dass der Datenverkehr fehlerfrei an die URL Ihrer ArcGIS Enterprise-Organisation weitergeleitet wird. In NGINX kann dies durch die Verwendung der folgenden Richtlinie erzielt werden: proxy_set_header X-Forwarded-Host $host;
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, 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, 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 Volumes (PVs) für den Systemspeicher, die dynamisch über eine Speicherklasse oder statisch durch einen Administrator bereitgestellt werden können, bevor die Organisation erstellt wird. Weitere Informationen zu statischer Bereitstellung und dynamischer Bereitstellung.
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 selbstverwalteten Clustern.
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.3 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-, Bild- und Szenen-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.
Hinweis:
Gehostete Feature-Layer vom Typ "spatiotemporal" werden in dieser Version nicht unterstützt.
- Nutzungskennwertdaten: Speichert Nutzungsdaten für GIS-Services.
Definieren Sie die Größe der einzelnen PVs anhand der Speicheranforderungen Ihrer Organisation.
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-API-Server-Version sein. Beispielsweise ist kubectl 1.28 mit den Kubernetes-Cluster-Versionen 1.27–1.29 kompatibel.
Zur Verwaltung Ihrer Bereitstellung können Sie umgebungsspezifische Befehlszeilenwerkzeuge verwenden. Links für den Download der umgebungsspezifischen Befehlszeilenschnittstelle:
TLS-Zertifikat
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 (Transport Layer Security)-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.3 ist die letzte Begleitversion für ArcGIS Enterprise on Kubernetes 11.3 Wenn Sie die neuesten verfügbaren Funktionen nutzen möchten, verwenden Sie ArcGIS Pro 3.3.
- 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.3.0 aktualisieren.Weitere Informationen hierzu finden Sie unter Client- und Geodatabase-Kompatibilität.