Partager via

Vue d’ensemble de Nexus Kubernetes Cluster

  • Article

Cet article décrit les concepts de base de Nexus Kubernetes Cluster, service Kubernetes managé que vous pouvez utiliser pour déployer et exploiter des applications conteneurisées sur Azure Operator Nexus Platform.

Présentation de Kubernetes

Kubernetes est une plateforme évoluant rapidement qui gère les applications basées sur les conteneurs, ainsi que leurs composants de mise en réseau et de stockage. Kubernetes se concentre sur les charges de travail d’application, pas sur les composants de l’infrastructure sous-jacente. Il fournit une approche déclarative des déploiements, assortie d’un ensemble robuste d’API pour les opérations de gestion. Consultez Qu’est-ce que Kubernetes pour découvrir Kubernetes.

Nexus Kubernetes Service

Nexus Kubernetes Cluster Service est une distribution Kubernetes conçue pour un déploiement local sur des instances Nexus. Il est conçu pour simplifier la création automatisée de conteneurs et est optimisé pour exécuter des charges de travail associées aux fonctions réseau gourmandes en données.

Comme n’importe quel cluster Kubernetes, le cluster Kubernetes Nexus a deux composants :

  • Plan de contrôle : fournit les services Kubernetes de base et gère le cycle de vie des charges de travail applicatives.

  • Nœuds : Pour exécuter vos applications et services de support, vous avez besoin d’un nœud Kubernetes. Il fournit l’environnement d’exécution des conteneurs. Chaque cluster NKS a au moins un nœud. Le nœud est hébergé sur une machine virtuelle (VM) qui exécute les composants de nœud Kubernetes. La machine virtuelle est créée dans le cadre du déploiement de cluster NKS sur une instance Nexus. Il existe deux types de pools de nœuds dans les clusters Nexus Kubernetes

    • Lorsque vous créez un cluster AKS; vous définissez le nombre initial de nœuds et leur taille (référence SKU), opération qui crée un pool de nœuds système. Les pools de nœuds système hébergent des pods système critiques.
    • Par ailleurs, pour prendre en charge les applications ayant des exigences de calcul ou de stockage différentes, vous pouvez créer des pools de nœuds utilisateur, également connus sous le nom de pool d’agents Nexus. Chaque machine virtuelle d’un pool d’agents Nexus suit une configuration uniforme, telle que le processeur, la mémoire, le disque, etc. Une fois qu’un pool d’agents est établi, le nombre de machines virtuelles qu’il contient reste fixe. Pour mettre à l’échelle la capacité d’un cluster Kubernetes Nexus, d’autres pools d’agents peuvent être créés et intégrés au cluster existant. En d’autres termes, le pool d’agents Nexus prend en charge la mise à l’échelle horizontale en autorisant l’ajout ou la suppression de pools d’agents au sein du cluster Nexus Kubernetes.

Cela étant, les pods d’application peuvent être planifiés sur des pools de nœuds système si l’utilisateur ne veut qu’un seul pool de nœuds dans son cluster. Chaque cluster Nexus Kubernetes doit contenir au moins un pool de nœuds système avec au moins un nœud.

Nexus Kubernetes Cluster Add-ons

Nexus Kubernetes Cluster Add-ons est une fonctionnalité de la plateforme Nexus qui permet aux clients d’améliorer leurs clusters Nexus Kubernetes avec des packages ou fonctionnalités supplémentaires. Les modules complémentaires (add-ons) sont classés en deux types : obligatoire et facultatif.

  • Modules complémentaires obligatoires : automatiquement déployés sur les clusters Nexus Kubernetes approvisionnés. Les modules complémentaires de base, tels que Calico, MetalLB, Nexus Storage CSI, les plug-ins IPAM, metrics-server, node-local-dns, Arc pour Kubernetes et Arc pour serveurs, sont compris par défaut lors de la création de clusters. La réussite du processus d’approvisionnement de clusters dépend de la réussite de l’installation de ces modules complémentaires. Si l’installation d’un module complémentaire obligatoire échoue et ne peut pas être réparée, l’état du cluster est marqué comme en échec.

  • Modules complémentaires facultatifs : services supplémentaires associés à une ressource de cluster Kubernetes. Les clients peuvent choisir d’activer ou de désactiver ces modules complémentaires à la demande. Par exemple, les services supplémentaires pourraient comprendre le déploiement du registre de mise en cache d’images locales au niveau du cluster au sein du cluster NKS pour prendre en charge les scénarios de déconnexion. NKS permet au client d’observer l’état, l’intégrité et la version de chaque module complémentaire obligatoire et facultatif, qui peuvent être surveillés dans le portail Azure, ou l’état peut être récupéré à l’aide d’API Azure Resource Manager.

Les modules complémentaires sont installés une seule fois et peuvent être mis à jour ou mis à niveau seulement lorsque le client met à niveau le cluster Nexus Kubernetes. Cela permet aux clients d’appliquer des correctifs de production critiques sans que des opérations d’infrastructure sous-jacentes n’interfèrent, qui pourraient sinon écraser les modifications de leur cluster.

Zones disponibles Nexus

Nexus introduit un concept de zone de disponibilité. Elle est délimitée au niveau du rack et permet aux clients de répartir leurs charges de travail dans l’instance afin d’obtenir une meilleure disponibilité. Pour une instance Nexus avec huit racks, les clients obtiennent huit zones de disponibilité. Chaque zone comprend une paire de serveurs d’administration avec redondance et une collection de serveurs de calcul qui fonctionnent comme un pool de ressources. Pendant les déploiements multiracks dans Nexus et lors de l’exécution de mises à niveau de bundle d’exécution, les zones de disponibilité offrent l’avantage supplémentaire de faire office de domaine de mise à niveau. Cela garantit qu’au pire, seuls les serveurs au sein d’un seul rack sont mis hors connexion pour ces mises à niveau.

Domaine de défaillance

Operator Nexus garantit que les nœuds Nexus Kubernetes Cluster sont distribués entre les domaines de mise à niveau. Cette distribution est effectuée de manière à améliorer la résilience et la disponibilité du cluster. Operator Nexus utilise des règles d’affinité Kubernetes pour planifier des nœuds dans des zones spécifiques. Il garantit que les machines virtuelles sous-jacentes ne sont pas placées sur le même serveur physique ou dans le même domaine de mise à niveau, ce qui améliore la tolérance de panne du cluster.

Étapes suivantes