Vorbereiten des Clusters

Lesen Sie sich die nachstehende Richtlinien zum Vorbereiten des Clusters sorgfältig durch, bevor Sie ArcGIS Enterprise on Kubernetes bereitstellen.

Namespace

Für ArcGIS Enterprise on Kubernetes ist ein eigener dedizierter Namespace erforderlich. Dieser muss vor der Ausführung des Bereitstellungsskripts erstellt werden. Wenn mehrere ArcGIS Enterprise on Kubernetes-Bereitstellungen in einem Cluster ausgeführt werden, ist für jede Bereitstellung ein eindeutiger Namespace erforderlich.

Ressourcenkontingent

Hinweis:

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

Für ArcGIS Enterprise on Kubernetes-Pods bestehen vordefinierte Anforderungen und Beschränkungen hinsichtlich 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:

Wenn Sie die Organisation mit Premiumfunktionen lizenzieren, müssen Sie die Ressourcenkontingentwerte unten um 10 % erhöhen, damit die zusätzlichen Funktionen unterstützt werden.

Die folgenden empfohlenen Werte entsprechen den Mindestanforderungen, die für die einzelnen Architekturprofile gelten. Beachten Sie, dass möglicherweise höhere Werte erforderlich sind, um den Skalierungsanforderungen Ihrer Organisation gerecht zu werden.

Profil für erweiterte Verfügbarkeit:

spec: 
    hard: 
      limits.cpu: "230" 
      limits.memory: 394Gi 
      requests.cpu: "36" 
      requests.memory: 188Gi

Profil für Standardverfügbarkeit:

spec: 
    hard: 
      limits.cpu: "218" 
      limits.memory: 359Gi 
      requests.cpu: "32" 
      requests.memory: 130Gi

Entwicklungsprofil:

spec: 
    hard: 
      limits.cpu: "144" 
      limits.memory: 249Gi 
      requests.cpu: "20" 
      requests.memory: 86Gi

Netzwerkanforderungen für Namespaces

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

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:

cluter.local ist die Standarddomäne des Clusters.

Pod-Sicherheitsstandards

Pod-Sicherheitsstandards sind eine Kubernetes-Funktion, mit der Administratoren einen Satz von Sicherheitsregeln für Pods erzwingen können, bevor die Pod-Planung im Cluster erfolgt. Standardmäßig sind drei Stufen verfügbar: "privileged", "baseline" und "restricted". Die Ausgabe von Warnungen und die Erzwingung dieser Standards wird auf Namespace-Ebene gesteuert.

Wenn die Erzwingungsstufe "baseline" oder "restricted" festgelegt wird, können Pods, die die Sicherheitsanforderungen der jeweiligen Stufe nicht erfüllen, nicht ausgeführt werden. Weitere Informationen zu den einzelnen Stufen finden Sie in den folgenden Themen:

• Privileged: Bei der Stufe "privileged" handelt es sich um einen Pod-Sicherheitsstandard ohne Einschränkungen, durch den der uneingeschränkte Zugriff auf eine Vielzahl von Berechtigungen zulässig ist. ArcGIS Enterprise kann bei dieser Stufe ohne Konfigurationsänderungen ausgeführt werden. Auf dieser Stufe besteht die Gefahr von Rechteausweitungen im Cluster, weshalb von der Ausführung auf dieser Stufe abgeraten wird.
• Baseline: Bei der Stufe "baseline" handelt es sich um einen Pod-Sicherheitsstandard mit gewissen Einschränkungen. Dabei wird der Zugriff auf das Dateisystem des Hosts über die Pods verhindert, und es bestehen Einschränkungen hinsichtlich anderer Volume-Typen und Funktionen. ArcGIS Enterprise kann bei der Erzwingungsstufe "baseline" ausgeführt werden, wenn die zugrunde liegenden Worker-Knoten außerhalb der laufenden Anwendung geändert werden. Dazu muss vor der Bereitstellung die Eigenschaft ALLOW_PRIVILEGED_CONTAINERS in der Eigenschaftendatei der Bereitstellung auf "false" festgelegt werden.

  Damit die Elastizität der der Worker-Knotengruppen entspricht, muss ein Administrator für jeden neu bereitgestellten Knoten die Einstellung vm.max_map_count per Skriptprozess auf 262144 erhöhen, indem er direkt die Startvorlage ändert.

• Restricted: Der Pod-Sicherheitsstandard "restricted" bietet die strengsten Sicherheitsvorkehrungen für Pods, und für die meisten securityContext-Eigenschaften ist eine explizite Angabe erforderlich. Die aktuelle ArcGIS Enterprise-Version kann bei der Stufe "restricted" nicht ausgeführt werden.

Weitere Informationen finden Sie unter Pod Security Admission und Pod Security Standards.

Metrics Server

Damit die automatische horizontale Podskalierung in ArcGIS Enterprise on Kubernetes genutzt werden kann, muss der Metrics Server Metriken zum Pod-Ressourcenverbrauch aus dem Kubelet-Prozess der einzelnen ausgeführten Knoten auslesen. Weitere Informationen hierzu finden Sie unter Kubernetes Metrics Server.