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

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:

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

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: "198" 
      limits.memory: 326Gi 
      requests.cpu: "32" 
      requests.memory: 130Gi

Entwicklungsprofil:

spec: 
    hard: 
      limits.cpu: "144" 
      limits.memory: 226Gi 
      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-Sicherheitsrichtlinien

Hinweis:

PodSecurityPolicy wurde in Kubernetes 1.25 entfernt.

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 die Einstellung "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: 117932853
        max: 117932853
  
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 117932853
        max: 117932853
  

Hinweis:

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

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.