Sélection élective des ressources dans Azure Operator Nexus Kubernetes

Les instances Nexus de l'opérateur sont déployées dans les locaux du client. Chaque instance comprend une ou plusieurs baies de serveurs métalliques nus.

Lorsqu’un utilisateur crée un cluster Kubernetes Nexus (NKS), il spécifie un nombre et un unité de conservation de stock (référence SKU) pour les machines virtuelles qui composent le plan de contrôle Kubernetes et un ou plusieurs pools d’agents. Les pools d'agents sont l'ensemble des nœuds worker sur lesquels s'exécutent les fonctions réseau conteneurisées d'un client.

La plateforme Nexus est chargée de décider du serveur nu sur lequel chaque machine virtuelle NKS est lancée.

Comment la plateforme Nexus planifie une machine virtuelle de cluster Kubernetes Nexus

Nexus identifie d’abord l’ensemble de serveurs nus potentiels qui répondent à toutes les exigences de ressources de la référence SKU de machine virtuelle NKS. Par exemple, si l’utilisateur a spécifié une référence SKU de machine virtuelle NC_G48_224_v1 pour son pool d’agents, Nexus collecte les serveurs nus qui ont une capacité disponible pour 48 processeurs virtuels, 224Gi de RAM, etc.

Nexus examine ensuite le champ AvailabilityZones du pool d’agents ou du plan de contrôle planifié. Si ce champ n'est pas vide, Nexus filtre la liste des serveurs en matériel nu potentiels en ne retenant que les serveurs situés dans les zones de disponibilité (racks) spécifiées. Ce comportement est une contrainte de planification difficile. S’il n’existe aucun serveur de matériel nu dans la liste filtrée, Nexus ne planifie pas la machine virtuelle NKS et le cluster ne parvient pas à provisionner.

Une fois Nexus identifié une liste de serveurs nus potentiels sur lesquels placer la machine virtuelle NKS, Nexus sélectionne ensuite l’un des serveurs de matériel nus après avoir appliqué les règles de tri suivantes :

1. Préférez les serveurs de matériel nus dans les zones de disponibilité (racks) qui n’ont pas de machines virtuelles NKS à partir de ce cluster NKS. En d’autres termes, répartissez les machines virtuelles NKS pour un cluster NKS entre les zones de disponibilité.

2. Préférez les serveurs de matériel nus dans une seule zone de disponibilité (rack) qui n’ont pas d’autres machines virtuelles NKS à partir du même cluster NKS. En d’autres termes, répartissez les machines virtuelles NKS pour un cluster NKS sur des serveurs de matériel nus au sein d’une zone de disponibilité.

3. Si la référence SKU de machine virtuelle NKS est NC_G48_224_v1 ou NC_P46_224_v1, préférez les serveurs de matériel nus qui hébergent déjà NC_G48_224_v1 ou NC_P46_224_v1 machines virtuelles NKS à partir d’autres clusters NKS. En d’autres termes, regrouper les machines virtuelles extra-volumineuses de différents clusters NKS sur les mêmes serveurs de matériel nus. Cette règle « bin packs » les machines virtuelles extra-volumineuses afin de réduire la fragmentation des ressources de calcul disponibles.

Exemples de scénarios de placement

Les sections suivantes mettent en évidence le comportement attendu par les utilisateurs de Nexus lors de la création de clusters NKS sur un environnement Nexus opérateur.

Conseil: vous pouvez voir quel serveur de matériel nu vos machines virtuelles NKS ont été planifiées en examinant la propriété nodes.bareMetalMachineId de la ressource KubernetesCluster NKS ou en consultant la colonne « Hôte » dans l’affichage du portail Azure des nœuds de cluster Kubernetes.

L’exemple d’environnement Opérateur Nexus présente les spécifications suivantes :

• Huit racks de 16 serveurs nus
• Chaque serveur nu contient deux cellules d’accès à la mémoire non uniforme (NUMA)
• Chaque cellule NUMA fournit 48 processeurs et 224Gi de RAM

Environnement vide

Étant donné un environnement Nexus Operator vide avec la capacité donnée, nous créons trois clusters Nexus Kubernetes de tailles différentes.

Les clusters NKS ont ces spécifications, et nous partons du principe que l’utilisateur crée les trois clusters dans l’ordre suivant :

Cluster A

• Plan de contrôle, référence SKU NC_G12_56_v1, trois nombres
• Pool d’agents n°1, référence SKU NC_P46_224_v1, 24 nombres
• Pool d’agents n°2, référence SKU NC_G6_28_v1, six nombres

Cluster B

• Plan de contrôle, référence SKU NC_G24_112_v1, cinq nombres
• Pool d’agents n°1, référence SKU NC_P46_224_v1, 48 nombres
• Pool d’agents n°2, référence SKU NC_P22_112_v1, 24 nombres

Cluster C

• Plan de contrôle, référence SKU NC_G12_56_v1, trois nombres
• Pool d’agents n°1, référence SKU NC_P46_224_v1, 12 nombres, AvailabilityZones = [1,4]

Voici un tableau résumant ce que l'utilisateur devrait voir après avoir lancé les clusters A, B et C sur un environnement Operator Nexus vide.

Cluster	pool	SKU	Nombre total	Nombre de racks attendus	Nombre de racks réels	Nombre attendu de machines virtuelles par rack	Nombre réel de machines virtuelles par rack
A	Plan de contrôle	NC_G12_56_v1	3	3	3	1	1
A	Pool d'agents n°1	NC_P46_224_v1	24	8	8	3	3
A	Pool d'agents n°2	NC_G6_28_v1	6	6	6	1	1
G	Plan de contrôle	NC_G24_112_v1	5	5	5	1	1
G	Pool d'agents n°1	NC_P46_224_v1	48	8	8	6	6
G	Pool d'agents n°2	NC_P22_112_v1	24	8	8	3	3
C	Plan de contrôle	NC_G12_56_v1	3	3	3	1	1
C	Pool d'agents n°1	NC_P46_224_v1	12	2	2	6	6

Comme il y a huit racks, les machines virtuelles de chaque pool sont réparties sur huit racks. Les pools avec plus de huit machines virtuelles nécessitent plusieurs machines virtuelles par rack répartis sur différents serveurs nus.

Le pool d’agents C de cluster n°1 comporte 12 machines virtuelles limitées à AvailabilityZones [1, 4] afin qu’elle dispose de 12 machines virtuelles sur 12 serveurs nus, six dans chacun des racks 1 et 4.

Les machines virtuelles extra-volumineuses (la référence SKU NC_P46_224_v1) provenant de différents clusters sont placées sur les mêmes serveurs de matériel nus (voir la règle 3 dans Comment la plateforme Nexus planifie une machine virtuelle de cluster Nexus Kubernetes).

Voici une visualisation de la disposition que l'utilisateur pourrait voir après avoir déployé les grappes A, B et C dans un environnement vide.

Environnement à moitié plein

Nous exécutons maintenant un exemple de lancement d’un autre cluster NKS lorsque l’environnement cible est à moitié plein. L'environnement cible est à moitié plein après le déploiement des clusters A, B et C dans l'environnement cible.

Le cluster D présente les spécifications suivantes :

• Plan de contrôle, référence SKU NC_G24_112_v1, cinq nombres
• Pool d’agents n°1, référence SKU NC_P46_224_v1, 24 nombres, AvailabilityZones = [7,8]
• Pool d’agents n°2, référence SKU NC_P22_112_v1, 24 nombres

Voici un tableau résumant ce que l'utilisateur devrait voir après avoir lancé le cluster D dans l’environnement Operator Nexus à moitié plein qui existe après le lancement des clusters A, B et C.

Cluster	pool	SKU	Nombre total	Nombre de racks attendus	Nombre de racks réels	Nombre attendu de machines virtuelles par rack	Nombre réel de machines virtuelles par rack
D	Plan de contrôle	NC_G12_56_v1	5	5	5	1	1
D	Pool d'agents n°1	NC_P46_224_v1	24	2	2	12	12
D	Pool d'agents n°2	NC_P22_112_v1	24	8	8	3	3

Le pool d’agents D de cluster n°1 comporte 12 machines virtuelles limitées à AvailabilityZones [7, 8] afin qu’elle dispose de 12 machines virtuelles sur 12 serveurs nus, six dans chacun des racks 7 et 8. Ces machines virtuelles atterrissent sur des serveurs métalliques nus qui hébergent également des machines virtuelles extra-larges d'autres clusters en raison de la règle de tri qui regroupe les machines virtuelles extra-larges de différents clusters sur les mêmes serveurs métalliques nus.

Si une machine virtuelle de plan de contrôle D de cluster atterrit sur le rack 7 ou 8, il est probable qu’une machine virtuelle cluster D du pool d'agents n°1 se trouve sur le même serveur nu que cette machine virtuelle de plan de contrôle D de cluster. Ce comportement est dû au fait que le pool d’agents n°1 est « épinglé » aux racks 7 et 8. Les contraintes de capacité dans ces racks entraînent la colocalisation d’une machine virtuelle de plan de contrôle et d’une machine virtuelle de pool d’agents #1 à partir du même cluster NKS.

Le pool d’agents du cluster D n°2 a trois machines virtuelles sur différents serveurs nus sur chacun des huit racks. Les contraintes de capacité résultent du pool d’agents du cluster D n°1 épinglé aux racks 7 et 8. Par conséquent, les machines virtuelles du pool d’agents du cluster D n°1 et du pool d’agents n°2 sont colocalisées sur les mêmes serveurs nus dans les racks 7 et 8.

Voici une visualisation de la disposition que l'utilisateur pourrait voir après avoir déployé le cluster D dans l’environnement cible.

Environnement presque plein

Dans notre exemple d'environnement cible, quatre des huit baies sont proches de leur capacité. Essayons de lancer un autre cluster NKS.

Le cluster E présente les spécifications suivantes :

• Plan de contrôle, référence SKU NC_G24_112_v1, cinq nombres
• Pool d’agents n°1, référence SKU NC_P46_224_v1, 32 nombres

Voici un tableau résumant ce que l'utilisateur devrait voir après avoir lancé le cluster E dans l’environnement cible.

Cluster	pool	SKU	Nombre total	Nombre de racks attendus	Nombre de racks réels	Nombre attendu de machines virtuelles par rack	Nombre réel de machines virtuelles par rack
E	Plan de contrôle	NC_G24_112_v1	5	5	5	1	1
E	Pool d'agents n°1	NC_P46_224_v1	32	8	8	4	3, 4 ou 5

Le pool d’agents du cluster E n°1 se répartit de manière inégale sur les huit racks. Les racks 7 et 8 auront trois machines virtuelles NKS du pool d’agents #1 au lieu des quatre machines virtuelles NKS attendues, car il n’y a plus de capacité pour les machines virtuelles de référence SKU extra-volumineuses dans ces racks après la planification des clusters A à D. Étant donné que les racks 7 et 8 n’ont pas de capacité pour la quatrième référence SKU extra-volumineuse dans le pool d’agents #1, cinq machines virtuelles NKS atterriront sur les deux racks les moins utilisés. Dans notre exemple, ces racks les moins utilisés étaient des racks 3 et 6.

Voici une visualisation de la disposition que l'utilisateur pourrait voir après avoir déployé le cluster E dans l’environnement cible.

Placement lors d'une mise à jour de l'exécution

Depuis avril 2024 (version de Network Cloud 2304.1), les mises à niveau du runtime sont effectuées à l’aide d’une stratégie rack par rack. Les serveurs nus en rack 1 sont ré-imagés en même temps. Le processus de mise à niveau s'interrompt jusqu'à ce que tous les serveurs en matériel nu redémarrent avec succès et indiquent à Nexus qu'ils sont prêts à recevoir des charges de travail.

Remarque

Il est possible d’indiquer à l’opérateur Nexus de réimager uniquement une partie des serveurs nus dans un rack à la fois, mais la valeur par défaut consiste à réimager tous les serveurs nus dans un rack en parallèle.

Lorsqu’un serveur de matériel nu individuel est réimagené, toutes les charges de travail s’exécutant sur ce serveur nu, y compris toutes les machines virtuelles NKS, perdent la puissance et la connectivité. Les conteneurs de charge de travail s’exécutant sur des machines virtuelles NKS perdent à leur tour la puissance et la connectivité. Après une minute sans être en mesure d’atteindre ces conteneurs de charge de travail, le plan de contrôle Kubernetes du cluster NKS marque les pods correspondants comme non sains. Si les pods sont membres d’un déploiement ou d’un StatefulSet, le plan de contrôle Kubernetes du cluster NKS tente de lancer des pods de remplacement pour ramener le nombre de réplicas observé du déploiement ou avec état au nombre de réplicas souhaité.

Les nouveaux pods ne démarrent que s’il existe une capacité disponible pour le pod dans les machines virtuelles NKS saines restantes. Depuis avril 2024 (version Network Cloud 2304.1), les nouvelles machines virtuelles NKS ne sont pas créées pour remplacer les machines virtuelles NKS qui se trouvaient sur le serveur de matériel nu réimaged.

Une fois le serveur nu réimagené et en mesure d’accepter de nouvelles machines virtuelles NKS, les machines virtuelles NKS qui étaient initialement sur le même serveur nu relancé sur le nouveau serveur de matériel nu. Les conteneurs de charge de travail peuvent ensuite être planifiés sur ces machines virtuelles NKS, ce qui peut restaurer les déploiements ou les ensembles avec état qui avaient des pods sur des machines virtuelles NKS qui se trouvaient sur le serveur en matériel nu.

Remarque

Ce comportement peut sembler à l’utilisateur comme si les machines virtuelles NKS n’ont pas « déplacé » du serveur nu, quand en fait une nouvelle instance d’une machine virtuelle NKS identique a été lancée sur le serveur nu nouvellement réimagené qui a conservé le même nom de serveur en matériel nu qu’avant la reimaging.

Bonnes pratiques

Lorsque vous travaillez avec Operator Nexus, gardez à l'esprit les meilleures pratiques suivantes.

• Évitez de spécifier un pool d’agents AvailabilityZones.
• Lancez des clusters NKS plus volumineux avant de les réduire.
• Réduisez le nombre de pools d'agents avant de réduire la taille des SKU de machine virtuelle.

Éviter de spécifier des zones de disponibilité pour un pool d'agents

Comme vous pouvez le dire dans les scénarios de placement ci-dessus, spécifier AvailabilityZones pour un pool d’agents est la principale raison pour laquelle les machines virtuelles NKS du même cluster NKS se retrouvent sur le même serveur en matériel nu. En spécifiant AvailabilityZones, vous « épinglez » le pool d’agents à un sous-ensemble de racks et limitez donc le nombre de serveurs de matériels nus potentiels dans cet ensemble de racks pour d’autres clusters NKS et d’autres machines virtuelles du pool d’agents dans le même cluster NKS à atterrir.

Par conséquent, notre première bonne pratique consiste à éviter de spécifier AvailabilityZones pour un pool d’agents. Si vous devez rattacher un pool d'agents à un ensemble de Zones de disponibilité Azure, faites en sorte que cet ensemble soit le plus grand possible afin de minimiser le déséquilibre qui peut se produire.

La seule exception à cette bonne pratique est le scénario dans lequel il n'y a que deux ou trois machines virtuelles dans un pool d'agents. Vous pouvez envisager de définir AvailabilityZones pour ce pool d’agents sur [1,3,5,7] ou [0,2,4,6] pour augmenter la disponibilité pendant les mises à niveau du runtime.

Lancer des clusters NKS plus volumineux avant de les réduire

Depuis avril 2024 et la version Network Cloud 2403.1, les clusters NKS sont planifiés dans l’ordre dans lequel ils sont créés. Pour pack votre environnement cible plus efficacement, nous vous recommandons de créer des clusters NKS plus volumineux avant de les réduire. De même, nous vous recommandons de programmer les pools d'agents les plus importants avant les plus petits.

Cette suggestion est importante pour les pools d’agents à l’aide de la référence SKU NC_G48_224_v1 ou NC_P46_224_v1 extra-volumineuse. La planification des pools d’agents avec le plus grand nombre de ces machines virtuelles de référence SKU extra-volumineuses crée un plus grand ensemble de serveurs en matériels nus sur lesquels d’autres machines virtuelles de référence SKU extra-volumineuses provenant de pools d’agents dans d’autres clusters NKS peuvent colocaliser.

Réduisez le nombre de pools d'agents avant de réduire la taille des SKU de machine virtuelle

Si vous rencontrez des contraintes de capacité lors du lancement d’un cluster ou d’un pool d’agents NKS, réduisez le nombre du pool d’agents avant d’ajuster la taille de la référence SKU de machine virtuelle. Par exemple, si vous tentez de créer un cluster NKS avec un pool d’agents avec une taille de référence SKU de machine virtuelle de NC_P46_224_v1 et un nombre de 24 et de récupérer un échec de provisionnement du cluster NKS en raison de ressources insuffisantes, vous pouvez être tenté d’utiliser une taille de référence SKU de machine virtuelle de NC_P36_168_v1 et continuer avec un nombre de 24. Toutefois, étant donné que les charges de travail des machines virtuelles doivent être alignées sur une seule cellule NUMA sur un serveur en matériel nu, il est probable que cette même requête entraîne des défaillances similaires de ressources insuffisantes. Au lieu de réduire la taille de la référence SKU de machine virtuelle, envisagez de réduire le nombre du pool d’agents à 20. Il y a plus de chances que votre requête s'inscrive dans la capacité de ressources de l'environnement cible et que votre déploiement global dispose de plus de cœurs de processeur que si vous réduisiez la taille du SKU de machine virtuelle.