Pour comprendre la configuration système requise et les prérequis liés à ArcGIS Enterprise on Kubernetes, familiarisez-vous avec les concepts et l’architecture de Kubernetes. Les termes courants sont décrits ci-dessous ; ils sont utilisés tout au long de la documentation.
Agrégat
Un cluster est un ensemble de nœuds worker qui fonctionnent ensemble pour exécuter des applications conteneurisées. Un cluster Kubernetes est un prérequis au déploiement de ArcGIS Enterprise on Kubernetes.
Nœud
Un nœud est une machine virtuelle ou physique qui a été spécifiée avec un ensemble minimal d’exigences matérielles. Le nombre de nœuds requis pour le déploiement varie en fonction du profil d’architecture sélectionné lors du déploiement. Consultez la configuration système requise afin de déterminer le nombre minimal de nœuds requis pour le déploiement.
Espace de noms
Un espace de noms permet d’organiser des objets dans le cluster Kubernetes. Un cluster peut contenir un ou plusieurs espaces de noms, chacun d’entre eux étant spécifié avec un nom unique. La suppression d’un espace de noms entraîne le retrait de tous ses objets. Un espace de noms est un prérequis au déploiement de ArcGIS Enterprise on Kubernetes.
Contrôle d’accès basé sur le rôle (RBAC)
Le contrôle d’accès basé sur le rôle permet de gérer les autorisations pour les ressources au sein du cluster.
Quotas de ressources
Des quotas de ressources permettent de contrôler les limites des ressources, comme le processeur et la mémoire dans un espace de noms désigné.
Secrets
Un secret permet de stocker et gérer des mots de passe, des jetons, des clés ou d’autres informations à caractère confidentiel dans l’espace de noms.
Pod
Un pod est la plus petite unité d’un cluster Kubernetes. Les pods sont une abstraction d’un conteneur ou, dans certains cas, d’un ensemble de conteneurs. Une adresse IP unique et disponible en interne est attribuée à chaque pod d’un cluster.
Déploiement
Un déploiement est un groupement d’un ensemble désigné de pods, de ReplicaSets et de services qui fonctionnent ensemble pour exécuter des applications conteneurisées. Un déploiement gère les mises à jour d’un ensemble de pods qui peuvent évoluer et être mis à jour avec des limites de ressources optimisées. Dans ArcGIS Enterprise on Kubernetes, les déploiements sont gérés à partir de ArcGIS Enterprise Manager ou de API ArcGIS Enterprise Administrator. Dans ArcGIS Enterprise on Kubernetes, les administrateurs gèrent les applications et les services SIG en tant que déploiements.
ReplicaSet
Un déploiement utilise un ReplicaSet afin de garantir l’exécution d’un ensemble désigné de réplicas pour un pod donné. Un ReplicaSet crée ou supprime des pods si nécessaire pour répondre aux exigences de l’ensemble de réplicas souhaité spécifié via un déploiement. Les ReplicaSets sont sans état.
StatefulSets
Les StatefulSets gèrent les pods créés avec le même ensemble de spécifications. Ils gèrent un ID unique pour chaque pod avec leur déploiement respectif pour garantir que les pods sont uniques et attribués de manière appropriée à des volumes de stockage persistants. Les StatefulSets ont un état.
Service
Un service permet de grouper un ensemble de pods et fournit l’accès à ces derniers si nécessaire. Un service utilise un seul nom de système de nom de domaine (DNS) pour le groupe de pods et achemine le trafic réseau interne vers une série de pods afin de gérer la charge et fournir la communication interpod. Un service est défini par une adresse IP statique qui peut être associée et reconnue par des pods participant.
Les cycles de vie d’un service et d’un pod sont indépendants, ce qui signifie qu’un pod peut s’arrêter et être remplacé par un nouveau pod. Dans ce cas, le service reconnaît la nouvelle adresse IP en conséquence.
Un service garantit l’acheminement du trafic réseau vers un ensemble actuel de pods désigné pour la charge.
Ingress (entrée réseau)
Ingress permet d’acheminer le trafic externe vers le cluster. Il peut également être utilisé pour fournir un équilibrage de la charge supplémentaire aux services du cluster.
Volume persistant
Les volumes persistants sont des ressources disponibles pour le cluster en vue du stockage des données et des ressources système. Les conteneurs et les pods du cluster accèdent aux volumes persistants avec une réclamation de volume persistant. Les informations suivantes s’appliquent aux volumes persistants :
- Un administrateur peut établir des connexions à partir du cluster Kubernetes vers le stockage physique, comme un stockage cloud, un système de fichiers réseau (NFS), etc.
- Elles ne dépendent pas du cycle de vie d’un pod.
- Elles ne sont pas liées à un nœud spécifique et sont associées à la totalité du cluster.
- Les volumes persistants résident en dehors de l’espace de noms pour fournir un stockage à la totalité du cluster.
Les volumes persistants sont définis par un administrateur comme une série de propriétés. Les spécifications requises dans le fichier varient et sont basées sur le type de stockage physique. Les volumes persistants peuvent être provisionnés de manière statique avant le déploiement. Ils peuvent également être provisionnés de manière dynamique pendant le déploiement lorsqu’une classe de stockage est utilisée.
Pour avoir plus de détails sur les volumes persistants, consultez la configuration système requise.
Classe de stockage
Une classe de stockage décrit les attributs d’un type de stockage disponible. Une classe de stockage est utilisée lorsque des volumes persistants sont provisionnés de manière dynamique. Une classe de stockage est spécifiée en tant qu’ensemble de propriétés via l’attribut provisionneur. Chaque fournisseur de stockage physique inclut un provisionneur.
Réclamation de volume persistant
Une réclamation de volume persistant demande ou réclame aux volumes persistants de fournir des ressources à un pod. Un pod réclame un stockage via la réclamation de volume persistant, qui à son tour demande du stockage via une classe de stockage. Les réclamations de volume persistant résident dans l’espace de noms. Le stockage persistant est utilisé pour gérer des données sauvegardées, des fichiers de configuration aux contenu des membres en passant par les journaux.
Communication de pod à pod
Les pods communiquent les uns avec les autres via un service dans un réseau virtuel. Une adresse IP est attribuée aux pods individuels ; cette adresse est reconnue par le service tout au long du cycle de vie du pod. Lorsqu’un pod s’arrête, éventuellement en raison d’un échec d’une application dans son conteneur, un pod de remplacement et son adresse IP associée sont créées à sa place.
Contraintes de dispersion de la topologie
La propriété topologySpreadConstraint peut être appliquée aux modèles de pod. Elle contrôle le mode de planification dans une topologie d’agrégat. Un domaine de topologie est défini lorsque chaque valeur unique est attribuée à la même clé d’étiquette. La propriété topologySpreadConstraint garantit une distribution régulière dans les domaines de topologie conformément à une propriété maxSkew définie. Si la propriété maxSkew est définie sur 1, le nombre de pods par domaine de topologie ne peut se situer qu’à 1 réplica par rapport aux autres. Par conséquent, si vous utilisiez trois domaines de topologie, le programmateur n’autorisera pas 0, 1 et 2 réplicas dans chacun des trois domaines et planifiera plutôt 1, 1, 1.
Vous avez un commentaire à formuler concernant cette rubrique ?