Um die Systemanforderungen und Voraussetzungen von ArcGIS Enterprise on Kubernetes zu verstehen, machen Sie sich mit den Konzepten und der Architektur von Kubernetes vertraut. Gängige Begriffe werden im Folgenden erläutert und in der gesamten Dokumentation verwendet.
Cluster
Ein Cluster ist eine Gruppe von Worker-Knoten, die zusammenarbeiten, um Containeranwendungen auszuführen. Ein Kubernetes-Cluster ist eine Voraussetzung für die Bereitstellung von ArcGIS Enterprise on Kubernetes.
Knoten
Ein Knoten ist ein virtueller oder physischer Computer, der mit einem Minimum an Hardwareanforderungen definiert wurde. Die Anzahl der für die Bereitstellung erforderlichen Knoten variiert in Abhängigkeit von dem Architekturprofil, das während der Bereitstellung ausgewählt wurde. Überprüfen Sie die Systemanforderungen, um die minimalen Knotenanforderungen für die Bereitstellung zu ermitteln.
Namespace
Ein Namespace wird verwendet, um Objekte im Kubernetes-Cluster zu organisieren. Ein Cluster kann einen oder mehrere Namespaces enthalten, für die jeweils ein eindeutiger Name angegeben wurde. Beim Löschen eines Namespace werden auch dessen Objekte entfernt. Ein Namespace ist eine Voraussetzung für die Bereitstellung von ArcGIS Enterprise on Kubernetes.
Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC)
Die rollenbasierte Zugriffssteuerung wird verwendet, um Berechtigungen für Ressourcen innerhalb des Clusters zu verwalten.
Ressourcenkontingente
Ressourcenkontingente werden verwendet, um Ressourcenbegrenzungen wie CPU und Speicher in einem bestimmten Namespace zu steuern.
Secrets
Secrets dienen dazu, Kennwörter, Token, Schlüssel oder andere hochsensible Informationen im Namespace zu speichern und zu verwalten.
Pod
Ein Pod ist die kleinste Einheit in einem Kubernetes-Cluster. Pods stellen eine Abstraktionsebene oberhalb eines Containers bzw. einer Gruppe von Containern dar. Jedem Pod in einem Cluster wird eine eindeutige und intern verfügbare IP-Adresse zugewiesen.
Bereitstellung
Eine Bereitstellung ist eine Gruppierung bestimmter Pods, ReplicaSets und Services, die zusammenarbeiten, um Containeranwendungen auszuführen. Eine Bereitstellung verwaltet Aktualisierungen für eine Gruppe von Pods, wobei diese mit optimierten Ressourcenbegrenzungen skaliert und aktualisiert werden können. In ArcGIS Enterprise on Kubernetes werden Bereitstellungen über ArcGIS Enterprise Manager oder die ArcGIS Enterprise Administrator API verwaltet. In ArcGIS Enterprise on Kubernetes verwalten Administratoren GIS-Services und -Apps als Bereitstellungen.
ReplicaSet
Eine Bereitstellung nutzt ein ReplicaSet, um sicherzustellen, dass eine bestimmte Replikatgruppe für einen angegebenen Pod ausgeführt wird. Ein ReplicaSet erstellt oder löscht Pods nach Bedarf, sodass sie der gewünschten Replikatgruppe entsprechen, die durch eine Bereitstellung angegeben wurde. ReplicaSets sind zustandslos.
StatefulSets
Mit StatefulSets werden Pods verwaltet, die mit den gleichen Spezifikationen erstellt wurden. Sie verwalten eine eindeutige ID für jeden Pod innerhalb der jeweiligen Bereitstellung und stellen dadurch sicher, dass die Pods eindeutig sind und den Persistent Volumes entsprechend zugewiesen werden. StatefulSets sind zustandsbehaftet.
Service
Ein Service wird verwendet, um Pods zu gruppieren und ggf. den Zugriff darauf zu ermöglichen. Ein Service verwendet einen einzigen DNS-Namen (Domain Name System) für die Gruppe von Pods und leitet den internen Netzwerkverkehr an eine Reihe von Pods weiter, um die Arbeitslast zu verwalten und die Kommunikation zwischen den Pods zu ermöglichen. Ein Service wird durch eine statische IP-Adresse definiert, die von den teilnehmenden Pods angehängt und erkannt werden kann.
Die Lebenszyklen eines Service und eines Pods sind nicht voneinander abhängig, d. h. ein Pod kann beendet und durch einen neuen Pod ersetzt werden. In diesem Fall erkennt der Service die entsprechende neue IP-Adresse.
Ein Service stellt sicher, dass der Netzwerkverkehr an eine aktuelle Gruppe von Pods weitergeleitet werden kann, die für die Arbeitslast bestimmt sind.
Eingang
Über den Eingang wird externer Datenverkehr an den Cluster weitergeleitet. Darüber hinaus kann er verwendet werden, um zusätzliches Load-Balancing für Services im Cluster bereitzustellen.
Persistent Volume
Persistent Volumes sind Ressourcen, die dem Cluster zum Speichern von Daten und Systemressourcen zur Verfügung stehen. Container und Pods im Cluster greifen über Persistent Volume Claims auf Persistent Volumes zu. Die folgenden Informationen beziehen sich auf Persistent Volumes:
- Ein Administrator kann Verbindungen zwischen dem Kubernetes-Cluster und einem physischem Speicher, z. B. einem Cloud-Speicher oder einem Netzwerkdateisystem (Network File System, NFS), herstellen.
- Diese sind nicht vom Lebenszyklus eines Pods abhängig.
- Sie sind nicht an einen bestimmten Knoten gebunden, sondern mit dem gesamten Cluster verknüpft.
- Persistent Volumes befinden sich außerhalb des Namespace und stellen Speicherplatz für den gesamten Cluster zur Verfügung.
Persistent Volumes werden von einem Administrator als eine Reihe von Eigenschaften definiert. Die erforderlichen Spezifikationen in der Datei variieren basierend auf dem physischen Speichertyp. Persistent Volumes können vor der Bereitstellung statisch angegeben werden. Wenn eine Speicherklasse verwendet wird, können sie auch während der Bereitstellung dynamisch angegeben werden.
Weitere Informationen zu Persistent Volumes finden Sie in den Systemanforderungen.
Speicherklasse
Eine Speicherklasse beschreibt Attribute für einen verfügbaren Speichertyp. Sie wird verwendet, wenn Persistent Volumes dynamisch bereitgestellt werden. Eine Speicherklasse wird über das Provisioner-Attribut als eine Reihe von Eigenschaften angegeben. Jeder Anbieter von physischem Speicher beinhaltet einen Provisioner.
Persistent Volume Claim
Ein Persistent Volume Claim fordert oder beansprucht Persistent Volumes, um Ressourcen für einen Pod bereitzustellen. Ein Pod beansprucht Speicherplatz über einen Persistent Volume Claim, der wiederum Speicherplatz über eine Speicherklasse anfordert. Persistent Volume Claims befinden sich innerhalb des Namespace. Persistenter Speicher wird verwendet, um gespeicherte Daten zu verwalten, von Konfigurationsdateien und Protokollen bis hin zu Inhalten, die von Mitgliedern erstellt wurden.
Kommunikation zwischen Pods
Pods kommunizieren über einen Service in einem virtuellen Netzwerk miteinander. Einzelnen Pods wird eine IP-Adresse zugewiesen, die der Service während des gesamten Lebenszyklus des Pods erkennt. Wenn ein Pod beendet wird, z. B. aufgrund des Ausfalls einer Anwendung im Container, werden an dessen Stelle ein Ersatz-Pod und eine entsprechende IP-Adresse erstellt.
Topology Spread Constraints
Mit der Eigenschaft "topologySpreadConstraint", die auf Pod-Vorlagen angewendet werden kann, lässt sich die Planung in einer Cluster-Topologie steuern. Eine Topologie-Domäne wird dadurch definiert, dass jeder Einzelwert demselben Label-Schlüssel zugewiesen wird. Mit "topologySpreadConstraint" wird eine gleichmäßige Verteilung auf die Topologie-Domänen gemäß einer definierten maxSkew-Eigenschaft sichergestellt. Wenn für "maxSkew" der Wert 1 festgelegt wird, darf die Anzahl der Pods pro Topologie-Domäne nur innerhalb von 1 Replikat zueinander liegen. Bei Verwendung von drei Topologie-Domänen lässt der Scheduler also 0, 1 und 2 Replikate in jeder der drei Domänen nicht zu und legt für die Planung stattdessen 1, 1, 1 fest.