Mises à niveau du runtime Nexus de l’opérateur Azure

La mise à niveau du runtime de la plateforme Nexus est une mise à niveau perturbatrice, gérée par les clients, pour mettre à jour le logiciel sous-jacent sur les serveurs d’une instance Opérateur Nexus. L’interruption se produit sur les serveurs de calcul au sein d’un rack mis à niveau. Les mises à niveau des serveurs d’administration sont considérées comme nondisruptives.

Étendue des versions du runtime

La mise à niveau du runtime est conçue pour mettre à jour les composants fondamentaux de la plateforme pour chaque serveur de l’instance. Certains exemples de composants mis à jour pendant la mise à niveau du runtime sont le système d’exploitation, le cluster Kubernetes souscloud, le microprogramme de calcul, le cluster etcd et le CNI (Interface réseau de conteneur). Chaque serveur est réimagené pour charger l’image de version du runtime sélectionnée.

Fréquence de mise en production

Versions majeures/mineures

Les versions mineures du runtime sont produites pour l’infrastructure de calcul trois fois par an en février, juin et octobre. Ces versions sont prises en charge pendant environ un an après la publication et les clients ne peuvent pas ignorer les versions mineures.

Sorties de correctifs

La version de correctif du runtime est publiée mensuellement entre les versions mineures. Ces versions sont facultatives, sauf si recommandé par Microsoft pour des fonctionnalités spécifiques ou pour des raisons de sécurité.

Vue d’ensemble des flux de travail

Le démarrage d’une mise à niveau du runtime est défini sous Mise à niveau du runtime de cluster via Azure CLI.

La mise à niveau du runtime commence par mettre à niveau les trois serveurs d’administration désignés comme nœuds du plan de contrôle. Le serveur du plan de contrôle de rechange est le premier serveur à mettre à niveau. Le dernier serveur du plan de contrôle est déprovisionné et passe à l'état Available. Ces serveurs sont mis à jour en série et continuent uniquement une fois terminés. Les serveurs d’administration restants sont séparés en deux groupes. La mise à niveau du runtime tire désormais parti de deux groupes d’administration, au lieu d’un seul groupe. Chaque groupe est mis à niveau en deux étapes et séquentiellement avec 50% seuil de réussite dans chaque groupe. L’introduction de cette fonctionnalité permet aux composants s’exécutant sur les serveurs d’administration de garantir la résilience pendant la mise à niveau du runtime en appliquant des règles d’affinité. Pour cette version, chaque CSN tire parti de cette fonctionnalité en plaçant une instance dans chaque groupe d’administration. Aucune interaction client avec cette fonctionnalité. Des étiquettes supplémentaires peuvent être affichées sur les nœuds de gestion pour identifier les groupes.

Une fois que tous les serveurs d’administration sont mis à niveau, la mise à niveau progresse vers les serveurs de calcul. Chaque rack est mis à niveau dans l’ordre alphanumérique, et il existe différentes configurations que les clients peuvent utiliser pour dicter la façon dont les calculs sont mis à niveau pour limiter la meilleure interruption. Différents contrôles d'intégrité sont effectués à mesure que chaque rack progresse, afin de garantir que la mise à niveau de la version est réussie et qu'un nombre suffisant de systèmes de calcul dans un rack reviennent à l'état opérationnel. Lorsqu’un rack est terminé, un temps d’attente défini par le client commence à fournir du temps supplémentaire pour que les charges de travail viennent en ligne. Une fois que chaque rack est mis à niveau, l'upgrade est terminée, et le cluster retourne à l'état Running.

Les étapes d’exécution d’une mise à niveau du runtime de cluster se trouvent ici.

Stratégies de mise à niveau du runtime

Chacune des stratégies expliquées fournit aux utilisateurs différents contrôles pour savoir comment et quand les racks de calcul sont mis à niveau. Ces valeurs s’appliquent uniquement aux serveurs de calcul et non aux serveurs d’administration. Chaque stratégie utilise un thresholdType et un thresholdValue pour définir le nombre ou le pourcentage de serveurs de calcul correctement mis à niveau dans un rack avant de passer au rack suivant.

Les valeurs de seuil sont un calcul effectué pendant la mise à niveau pour déterminer le nombre de serveurs de calcul disponibles après la mise à niveau.

Rack par rack

Le comportement par défaut des mises à niveau à l'exécution effectue une itération sur chaque rack individuellement jusqu'à ce que les seuils spécifiés pour l'ensemble du site soient atteints.

Rack en pause

Cette stratégie interrompt la mise à niveau une fois que le rack a terminé la mise à niveau. Le rack suivant ne démarre pas tant que le client n’exécute pas l’API de mise à niveau.

Vous trouverez ici des détails sur l’exécution d’une mise à niveau avec la pause rack.

Charges de travail du locataire Nexus pendant la mise à niveau du runtime du cluster

Pendant une mise à niveau du runtime, les nœuds de cluster Kubernetes Nexus qui s’exécutent sur des serveurs planifiés pour la mise à niveau sont cordonnés, vidés, puis correctement arrêtés avant le début de la mise à niveau. Mettre un nœud en cordon empêche les nouveaux pods d’être planifiés dessus, tandis que le drainage permet aux pods exécutant des charges de travail des locataires de passer à d’autres nœuds disponibles, ce qui minimise la perturbation du service. L’efficacité du drainage dépend de la capacité disponible dans le cluster. Si le cluster est proche de la capacité totale et manque d’espace pour le déplacement des pods, ces pods entrent dans un état en attente après le drainage.

Une fois le cordon et les étapes de drainage terminées, le nœud est arrêté dans le cadre du processus de mise à niveau. Après la mise à niveau du serveur baremetal, le nœud est redémarré, rejoint le cluster et est décordoné, ce qui permet à nouveau la planification des pods.

Pour les machines virtuelles Nexus, le processus est similaire. Les machines virtuelles sont arrêtées avant la mise à niveau du serveur baremetal et redémarrées automatiquement une fois que le serveur est de nouveau en ligne.

Chaque nœud de cluster client est autorisé jusqu’à 20 minutes pour que le processus de drainage se termine. Après cette fenêtre, la mise à niveau du serveur se poursuit indépendamment de l’achèvement du drainage pour garantir la progression. Les serveurs sont mis à niveau un rack à la fois, avec des mises à niveau effectuées en parallèle dans le même rack. La mise à niveau des serveurs n'attend pas que les ressources du locataire soient en ligne avant de poursuivre l'environnement d'exécution d'autres serveurs dans le rack. En plus du délai d’expiration du drainage, un délai d’expiration de 10 minutes est alloué pour l'arrêt des machines virtuelles. Cette approche garantit que le temps d’attente maximal par rack reste de 30 minutes, propre au cordon, au drain et à la procédure d’arrêt, et non à la mise à niveau globale.

Il est important de noter que suite à la mise à niveau du runtime, il peut y avoir une instance où un nœud de cluster Nexus Kubernetes reste cordonné. Pour ce scénario, vous localisez des nœuds uncordon en exécutant la commande suivante.

az networkcloud baremetalmachine list -g $mrg --subscription $sub --query "sort_by([].{name:name,kubernetesNodeName:kubernetesNodeName,location:location,readyState:readyState,provisioningState:provisioningState,detailedStatus:detailedStatus,detailedStatusMessage:detailedStatusMessage,powerState:powerState,tags:tags.Status,machineRoles:join(', ', machineRoles),cordonStatus:cordonStatus,createdAt:systemData.createdAt}, &name)" 
--output table

Opérations d'ensemble de clés BareMetalMachine (BMM) pendant la mise à niveau du runtime du cluster

Lorsqu’un serveur est mis à niveau pour utiliser un nouveau système d’exploitation, les ensembles de clés BMM doivent être rétablis avec le nouveau logiciel. Ce processus démarre une fois la mise à niveau du runtime terminée pour l’instance. Les serveurs qui n’ont pas encore subi une mise à niveau du runtime sont toujours accessibles via le jeu de clés BMM. Si l’accès à une machine est nécessaire pendant la mise à niveau, l’utilisateur de la console est disponible.

Serveurs non mis à niveau avec succès

Un serveur reste indisponible s’il échoue à la mise à niveau ou au provisionnement à partir d’un problème matériel possible lors du redémarrage ou du problème avec cloud-init (mise en réseau, chronyd, etc.). Le problème sous-jacent doit être résolu et une opération de remplacement ou de réimagerie de la machine physique devrait être exécutée. Retirer manuellement les restrictions du serveur ne résoudra pas les problèmes.