Mise à niveau du runtime de cluster à partir d’Azure CLI

Article
09/25/2024

Ce guide pratique explique les étapes d’installation de l’interface Azure CLI et des extensions nécessaires pour interagir avec Operator Nexus.

Prérequis

L’étape Installer Azure CLI doit être effectuée.
L’extension CLI networkcloud est obligatoire. Si l’extension networkcloud n’est pas installée, vous pouvez le faire en suivant les étapes listées ici.
Accédez au portail Azure pour le cluster cible à mettre à niveau.
Vous devez être connecté au même abonnement que votre cluster cible via az login
Le cluster cible doit être dans un état d’exécution, avec tous les nœuds du plan de contrôle sains, et plus de 80 % des nœuds de calcul dans un état d’exécution et sain.

Recherche des versions de runtime disponibles

Dans le portail

Pour rechercher les versions de runtime pouvant être mises à niveau, accédez au cluster cible dans le portail Azure. Dans le volet de présentation du cluster, accédez à l’onglet Versions de mise à niveau disponibles.

Sous l’onglet Versions de mise à niveau disponibles, nous pouvons voir les différentes versions de cluster actuellement disponibles pour la mise à niveau. L’opérateur peut sélectionner une version parmi les versions de runtime cible listées. Après la sélection, passez à la mise à niveau du cluster.

Par Azure CLI

Les mises à niveau disponibles sont récupérables avec Azure CLI :

az networkcloud cluster show --name "clusterName" --resource-group "resourceGroup"

Dans la sortie, vous voyez la propriété availableUpgradeVersions et le champ targetClusterVersion :

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

S’il n’y a pas de mise à niveau de cluster disponible, la liste est vide.

Mise à niveau du runtime de cluster avec l’interface CLI

Pour effectuer une mise à niveau du runtime, utilisez la commande Azure CLI suivante :

az networkcloud cluster update-version --cluster-name "clusterName" --target-cluster-version
  "versionNumber" --resource-group "resourceGroupName"

La mise à niveau du runtime est un processus long. La mise à niveau met d’abord à niveau les nœuds de gestion, puis les nœuds worker rack par rack. La mise à niveau est considérée comme terminée quand 80 % des nœuds worker par rack et 100 % des nœuds de gestion ont été correctement mis à niveau. Les charges de travail peuvent être impactées pendant la mise à niveau des nœuds worker d’un rack, mais les charges de travail de tous les autres racks ne sont pas impactées. Nous vous encourageons à placer les charges de travail en fonction de cette conception d’implémentation.

La mise à niveau de tous les nœuds prend plusieurs heures, mais peut durer plus longtemps si d’autres processus, comme les mises à jour du microprogramme, font également partie de la mise à niveau. En raison de la durée du processus de mise à niveau, nous vous conseillons de consulter régulièrement l’état détaillé du cluster pour connaître l’état actuel de la mise à niveau. Pour vérifier l’état de la mise à niveau, consultez l’état détaillé du cluster. Cette vérification peut être effectuée en utilisant le portail ou l’interface CLI az.

Pour voir l’état de la mise à niveau dans le portail Azure, accédez à la ressource de cluster ciblée. Dans l’écran Vue d’ensemble du cluster, l’état détaillé est fourni avec un message d’état détaillé.

La mise à niveau du cluster est en cours quand detailedStatus est défini sur Updating et detailedStatusMessage montre la progression de la mise à niveau. Exemples de progression de mise à niveau indiquée dans detailedStatusMessage : Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading..., etc.

La mise à niveau du cluster est terminée quand detailedStatus est défini sur Running et detailedStatusMessage affiche le message Cluster is up and running

Pour voir l’état de mise à niveau avec Azure CLI, utilisez az networkcloud cluster show.

az networkcloud cluster show --cluster-name "clusterName" --resource-group "resourceGroupName"

La sortie doit indiquer les informations du cluster cible, et contenir l’état détaillé et le message d’état détaillé du cluster. Pour des informations plus détaillées sur la progression de la mise à niveau, vous pouvez consultez le BMM individuel de chaque rack pour obtenir l’état. Un exemple est fourni dans la section des informations de référence sous Rôles du matériel nu.

Configurer les paramètres de seuil de calcul pour la mise à niveau du runtime en utilisant cluster updateStrategy

La commande Azure CLI suivante permet de configurer les paramètres de seuil de calcul pour une mise à niveau de runtime :

az networkcloud cluster update /
--name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> /
wait-time-minutes=<waitTimeBetweenRacks>

Paramètres obligatoires :

strategy-type : définit la stratégie de mise à jour. Dans ce cas, « Rack » signifie que les mises à jour se produisent rack par rack. La valeur par défaut est « Rack ».
threshold-type : détermine la façon dont le seuil doit être évalué, appliqué dans les unités définies par la stratégie. La valeur par défaut est « PercentSuccess ».
threshold-value : valeur de seuil numérique utilisée pour évaluer une mise à jour. La valeur par défaut est 80.

Paramètres facultatifs :

max-unavailable : nombre maximal de nœuds worker pouvant être hors connexion, c’est-à-dire mis à niveau pour chaque rack à la fois. La valeur par défaut est 32767.
wait-time-minutes : délai ou période d’attente avant la mise à jour d’un rack. La valeur par défaut est 15.

Voici un exemple d’utilisation de la commande :

az networkcloud cluster update --name "cluster01" --resource-group "cluster01-rg" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=70 max-unavailable=16 wait-time-minutes=15

Une fois la commande exécutée, les valeurs updateStrategy spécifiées sont appliquées au cluster :

    "updateStrategy": {
      "maxUnavailable": 16,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 70,
      "waitTimeMinutes": 15,
    }

Remarque

Quand une valeur de seuil inférieure à 100 % est définie, il est possible que les nœuds non sains ne soient pas mis à niveau, alors que l’état du « cluster » peut néanmoins indiquer que la mise à niveau a réussi. Pour résoudre les problèmes liés aux machines nues, reportez-vous à Résoudre les problèmes du serveur Azure Operator Nexus

Mettre à niveau avec la stratégie PauseRack

À compter de la version d’API 2024-06-01-preview, les mises à niveau du runtime peuvent être déclenchées en utilisant une stratégie « PauseRack ». Quand vous exécutez une mise à niveau du runtime de cluster avec la stratégie « PauseRack », elle met à jour un rack à la fois dans le cluster puis s’arrête, attendant une confirmation avant de passer au rack suivant. Tous les seuils existants continueront d’être respectés avec la stratégie « PauseRack ». Pour effectuer une mise à niveau du runtime de cluster en utilisant la stratégie « PauseRack », suivez les étapes décrites dans Mise à niveau du runtime de cluster avec une stratégie PauseRack.

Forums Aux Questions (FAQ)

Identification du blocage de la mise à niveau du cluster

Pendant une mise à niveau du runtime, il est possible que la mise à niveau ne progresse plus, mais que l’état détaillé indique que la mise à niveau est toujours en cours. Parce que la mise à niveau du runtime peut prendre très longtemps, il n’y a pas de durée définie pour l’expiration du délai d’attente. Par conséquent, nous vous conseillons également de vérifier régulièrement l’état détaillé et les journaux de votre cluster pour déterminer si la mise à niveau tente indéfiniment de s’effectuer.

Nous pouvons identifier ce cas en consultant les journaux du cluster, les messages détaillés et le message d’état détaillé. Si une expiration du délai d’attente s’est produite, nous observons que le cluster tourne en boucle et qu’il ne progresse pas. À partir de là, nous vous recommandons de consulter les journaux du cluster ou le LAW configuré, pour vérifier s’il y a une défaillance ou si une mise à niveau spécifique provoque le blocage de la progression.

Une défaillance matérielle ne nécessite pas la réexécution de la mise à niveau

Si une défaillance matérielle se produit pendant la mise à niveau, la mise à niveau du runtime continue tant que les seuils définis sont respectés pour les nœuds de calcul et de gestion/contrôle. Une fois la machine corrigée ou remplacée, elle est provisionnée avec le système d’exploitation de la plateforme actuelle du runtime, qui contient la version ciblée du runtime.

Si une défaillance matérielle se produit et que la mise à niveau du runtime échoue parce que les seuils n’ont pas été respectés pour les nœuds de calcul et de contrôle, la réexécution de la mise à niveau du runtime peut être nécessaire en fonction du moment où la défaillance s’est produite et de l’état des serveurs individuels dans un rack. Si un rack a été mis à jour avant une défaillance, la version du runtime mis à niveau est utilisée quand les nœuds sont reprovisionnés. Si la spécification du rack n’a pas été mise à jour vers la version du runtime mis à niveau avant la défaillance matérielle, la machine est provisionnée avec la version précédente du runtime. Pour une mise à niveau vers la nouvelle version du runtime, envoyez une nouvelle demande de mise à niveau de cluster et seuls les nœuds avec la version précédente du runtime sont mis à niveau. Les hôtes qui ont réussi dans l’action de mise à niveau précédente ne sont pas mis à niveau.

Après une mise à niveau du runtime, le cluster affiche l’état de provisionnement « Échec »

Pendant une mise à niveau du runtime, le cluster bascule à l’état Upgrading. En cas de défaillance de la mise à niveau du runtime, le cluster bascule à l’état d’approvisionnement Failed. Les défaillances pendant la mise à niveau peuvent être causées par des composants d’infrastructure (par exemple, l’appliance de stockage). Dans certains scénarios, il peut être nécessaire de diagnostiquer l’échec avec le Support Microsoft.

Impact sur les charges de travail de locataire Nexus Kubernetes pendant la mise à niveau du runtime du cluster

Lors d’une mise à niveau du runtime, les nœuds de cluster Nexus Kubernetes impactés sont isolés et vidés avant la mise à niveau des hôtes nus (BMH, Bare Metal Host). L’isolation du nœud de cluster Kubernetes empêche de nouveaux pods d’être planifiés sur celui-ci, et le vidage du nœud de cluster Kubernetes permet aux pods qui exécutent des charges de travail de locataire de basculer vers un autre nœud de cluster Kubernetes disponible, ce qui permet de réduire l’impact sur les services. L’efficacité du mécanisme de vidage dépend de la capacité disponible dans le cluster Nexus Kubernetes. Si le cluster Kubernetes est proche de la capacité totale et manque d’espace pour que les pods puissent être relocalisés, ils passent à un état En attente après le processus de vidage.

Une fois le processus d’isolation et de drainage du nœud de cluster de locataire terminé, la mise à niveau du BMH se poursuit. Chaque nœud de cluster de locataire dispose de dix minutes pour effectuer le processus de drainage, après quoi la mise à niveau du BMH commence. Cela garantit la progression de la mise à niveau du BMH. Les BMH sont mis à niveau un rack à la fois, et les mises à niveau sont effectuées en parallèle dans le même rack. La mise à niveau de BMH n’attend pas que les ressources de locataire soient mises en ligne avant de poursuivre la mise à niveau du runtime de BMH dans le rack en cours de mise à niveau. L’avantage est que la durée d’attente globale maximale d’une mise à niveau de rack est limitée à dix minutes, quel que soit le nombre de nœuds disponibles. Cette durée d’attente maximale est propre à la procédure d’isolation et de drainage, et n’est pas appliquée à la procédure de mise à niveau globale. À la fin de chaque mise à niveau de BMH, le nœud de cluster Nexus Kubernetes démarre, rejoint le cluster, et sort de l’isolation, ce qui permet aux pods d’être à nouveau planifiés sur le nœud.

Il est important de noter que le nœud de cluster Nexus Kubernetes ne sera pas arrêté après le processus d’isolation et de drainage. Le BMH est redémarré avec la nouvelle image dès que tous les nœuds de cluster Nexus Kubernetes ont été isolés et drainés, après dix minutes si le processus de drainage n’est pas terminé. En outre, le processus d’isolation et de drainage n’est pas lancé pour les actions de mise hors tension ou de redémarrage du BMH ; il est activé exclusivement pendant une mise à niveau du runtime.

Il est important de noter que suite à la mise à niveau du runtime, il peut arriver qu’un nœud de cluster Nexus Kubernetes reste isolé. Pour ce scénario, vous pouvez annuler manuellement l’isolation du nœud 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

Partager via