Nachfolgend werden die minimalen Hardware- und Infrastrukturanforderungen für die Ausführung von ArcGIS Enterprise on Kubernetes 11.2 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:
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) Red Hat OpenShift Container Platform(einschließlich ROSA und ARO) [4.12 - 4.14] RKE und RKE2 | 1.25 - 1.28 |
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. 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.
Wenn Sie die Organisation mit Premiumfunktionen lizenzieren, müssen Sie für jedes Architekturprofil einen weiteren Worker-Knoten hinzufügen, damit die zusätzlichen Funktionen unterstützt werden.
| 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 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.
Führen Sie die Bereitstellungsschritte für die Integration mit einem Ingress-Controller auf Clusterebene aus, um Load-Balancing-Funktionen auf Schicht 7 zu implementieren (z. B. eine Web Application Firewall) oder andere Organisationsanforderungen für eingehenden Datenverkehr zur bereitgestellten Anwendung über einen bereits vorhandenen Ingress-Controller zu erfüllen.
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, 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.2 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-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:
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-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.2 ist die Begleitversion für ArcGIS Enterprise on Kubernetes 11.2. Wenn Sie die neuesten verfügbaren Funktionen nutzen möchten, verwenden Sie ArcGIS Pro 3.2.
- 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 die Geodatabase auf Version 11.2.0.3.2 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.