Mettre à niveau le runtime de cluster à partir d’Azure CLI

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

Prerequisites

Installez la dernière version des extensions Azure CLI appropriées.
La dernière networkcloud extension CLI est requise. Elle peut être installée en suivant les étapes répertoriées ici.
Accès à l'abonnement pour exécuter les commandes d'extension CLI pour le tissu réseau Azure Operator Nexus (NF) et le cloud réseau (NC).
Collectez les informations suivantes :
- ID d’abonnement (SUBSCRIPTION)
- Nom du cluster (CLUSTER)
- Groupe de ressources (CLUSTER_RG)
L’état détaillé du cluster doit être Running.
La connectivité du cluster au Gestionnaire de cluster doit être Connected.
Sous Cluster > Serveurs de calcul > de charge de travail
- Trois des quatre nœuds du plan de contrôle doivent être dans l’état de puissance On, l’état de cordon Uncordoned, l’état prêt Yes, et détérioré No.
  - Le nœud du plan de contrôle de rechange doit être dans l'état de puissance Off, en état Prêt No, et en état Dégradé No.
- Les serveurs du plan de gestion sont divisés en deux groupes, disposés sur des racks numérotés impairs et pairs. Pour chaque groupe, au moins la moitié des serveurs doivent être dans l’état d'alimentation On, en isolation Uncordoned, état prêt Yes, et dégradé No.
  - Il est recommandé d’avoir plus de 50% des serveurs du plan d’administration disponibles pour atténuer tout risque.
- Les numéros de serveur du plan de calcul varient en fonction des paramètres de seuil d’exécution du cluster individuels. Les utilisateurs doivent déterminer leur nombre minimal en fonction de leurs paramètres, recherchant l'état d'alimentation On, l'état de cordon Uncordoned, l'état prêt Yes, et l'état dégradé No.
Sous Cluster > Managed Resource Group, sélectionnez le nom du groupe pour accéder à la page du groupe de ressources.
- Dans le groupe de ressources, recherchez Kubernetes - Azure Arc pour identifier les informations Azure Arc et sélectionnez-les. L’état doit être Connected.
  - Dans la page Azure Arc, sélectionnez Extensions de paramètres > .
    - nc-platform-extension doit être dans l’état Succeeded.
  - nc-platform-runtime-extension doit être dans l’état Succeeded.

Note

Ces mêmes vérifications doivent également être effectuées après la mise à niveau pour garantir que le cluster est sain.

Vérification de la version d'exécution actuelle

Vérifiez la version actuelle du runtime du cluster avant la mise à niveau : comment vérifier la version actuelle du runtime du cluster.

Recherche des versions de runtime disponibles

Via le portail Azure

Pour rechercher les versions d’exécution pouvant être mises à niveau disponibles, accédez au cluster cible dans le portail Azure. Dans le volet vue d’ensemble 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. Une fois sélectionné, passez à la mise à niveau du cluster.

Via l’interface de ligne de commande Azure

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

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A8 availableUpgradeVersions

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’existe aucune mise à niveau de cluster disponible, la liste est vide.

Configurer les paramètres de seuil de calcul pour la mise à niveau du runtime à l’aide du 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 "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="<strategyType>" threshold-type="<thresholdType>" \
threshold-value="<thresholdValue>" max-unavailable="<maxNodesOffline>" \
wait-time-minutes="<waitTimeBetweenRacks>" \
--subscription "<SUBSCRIPTION>"

Paramètres obligatoires :

strategy-type : définit la stratégie de mise à jour. Le paramètre utilisé est Rack (Rack-by-Rack) OU PauseAfterRack (Pause pour l’utilisateur avant le démarrage de chaque rack). La valeur par défaut est Rack. Pour effectuer une mise à niveau du runtime de cluster à l’aide de la PauseAfterRack stratégie, suivez les étapes décrites dans Upgrade Cluster Runtime with PauseAfterRack Strategy.
threshold-type : détermine la façon dont le seuil doit être évalué, appliqué dans les unités définies par la stratégie. Les paramètres utilisés sont PercentSuccess OR CountSuccess. 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.

L’exemple suivant est destiné à un client utilisant la stratégie Rack-by-Rack avec un pourcentage de réussite de 60% et une pause de 1 minute.

az networkcloud cluster update --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" \
threshold-value=60 wait-time-minutes=1 \
--subscription "<SUBSCRIPTION>"

Vérifiez la mise à jour :

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A5 updateStrategy

  "updateStrategy": {
    "maxUnavailable": 32767,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

Dans cet exemple, si moins de 60 % des nœuds de calcul en cour d’approvisionnement dans un rack ne parviennent pas à être approvisionnés (rack par rack), la mise à niveau du cluster attend indéfiniment jusqu’à ce que la condition soit remplie. Si 60 % des nœuds de calcul ou plus sont correctement provisionnés, le déploiement du cluster passe au rack de nœuds de calcul suivant. S’il y a trop de défaillances dans le rack, le matériel doit être réparé avant que la mise à niveau puisse continuer.

L’exemple suivant est destiné à un client utilisant la stratégie Rack-by-Rack avec un type CountSuccess de seuil de 10 nœuds par rack et une pause de 1 minute.

az networkcloud cluster update --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" \
threshold-value=10 wait-time-minutes=1 \
--subscription "<SUBSCRIPTION>"

Vérifiez la mise à jour :

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A5 updateStrategy

  "updateStrategy": {
    "maxUnavailable": 32767,
      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

Dans cet exemple, si moins de 10 nœuds de calcul configurés dans un rack ne parviennent pas à provisionner (sur une base rack par rack), la mise à niveau du cluster attend indéfiniment jusqu’à ce que la condition soit remplie. Si 10 nœuds de calcul ou plus sont correctement approvisionnés, le déploiement du cluster passe au rack suivant de nœuds de calcul. S’il y a trop de défaillances dans le rack, le matériel doit être réparé avant que la mise à niveau puisse continuer.

Note

update-strategy ne peut pas être modifié une fois la mise à niveau du runtime du cluster démarrée. Lorsqu’une valeur de seuil inférieure à 100% est définie, il est possible que les nœuds non sains ne soient pas mis à niveau, mais l’état « Cluster » peut toujours 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 le runtime de cluster à l’aide de l’interface CLI

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

az networkcloud cluster update-version --cluster-name "<CLUSTER>" \
--target-cluster-version "<versionNumber>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>"

Cette commande lance le processus de mise à niveau du runtime pour le cluster spécifié. La commande elle-même se termine généralement dans environ 5 minutes, mais cette commande démarre uniquement le processus de mise à niveau. La mise à niveau réelle du runtime continue à s’exécuter en arrière-plan et peut prendre plusieurs heures, car elle met à niveau les nœuds rack par rack et installe la nouvelle version du système d’exploitation.

Des informations détaillées sur l’état et le diagnostic de l’étape d’initiation sont disponibles dans le portail Azure dans la JSON View ressource Cluster (Opérateur Nexus). Les informations suivantes sont incluses dans l’entrée du champ, lors de l’utilisation updateVersion de la version properties.actionStates de l’API 2025-07-01-preview ou ultérieure.

Heure de début et de fin de l’action.
État actuel (Succeeded, Failedou InProgress).
Tout contexte ou message d’erreur supplémentaire associé à l’état actuel.
ID de corrélation de l’opération d’origine cluster update-version , comme indiqué dans le journal d’activité Azure.
Liste triée des étapes individuelles et de leur état , par exemple Validate Cluster conditions and upgrade versions, et Initiate Platform Runtime Extension update.

Important

L’entrée properties.actionStates pour updateVersion refléter uniquement la phase d’initiation courte (validation et initiation de demande qui se termine généralement en ~5 minutes). Il ne suit pas la progression du rack par rack de la mise à niveau principale. Pour surveiller la mise à niveau complète, utilisez l’état détaillé du cluster et le message d’état détaillé dans la vue d’ensemble de la ressource ou interrogez via az networkcloud cluster show.

Exemple de JSON View sortie pour la ressource Cluster (Opérateur Nexus) :

{
  "properties": {
    "actionStates": [
      {
        "correlationId": "b66643b7-2e1d-4a5c-a954-ca0e38368984",
        "status": "Completed",
        "actionType": "Microsoft.NetworkCloud/clusters/updateVersion",
        "endTime": "2025-08-01T03:46:13Z",
        "message": "Cluster upgrade to 4.6.0 successfully initiated - monitor progress via cluster detailed status",
        "startTime": "2025-08-01T03:42:08Z",
        "stepStates": [
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:42:08Z",
            "message": "Cluster validation and version checks passed",
            "startTime": "2025-08-01T03:42:08Z",
            "stepName": "Validate Cluster conditions and upgrade versions"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:11Z",
            "message": "Platform Runtime Extension deployment initiated",
            "startTime": "2025-08-01T03:42:39Z",
            "stepName": "Initiate Platform Runtime Extension update"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:11Z",
            "message": "Platform Runtime Extension installation completed",
            "startTime": "2025-08-01T03:46:11Z",
            "stepName": "Monitor Platform Runtime Extension readiness"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:13Z",
            "message": "Platform Cluster version updated successfully",
            "startTime": "2025-08-01T03:46:13Z",
            "stepName": "Update Platform Cluster version specification"
          }
        ]
      }
    ]
  }
}

Une fois cette commande terminée, le processus de mise à niveau du runtime complet commence. Ce processus peut prendre plusieurs heures, en fonction du nombre de racks dans le cluster et du nombre de nœuds Worker de chaque rack.

La mise à niveau met d’abord à niveau les nœuds worker, puis séquentiellement rack par rack pour les nœuds de travail.
Les serveurs d’administration sont séparés en deux groupes, qui sont mis à niveau séparément. Cette approche 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é.
Les CSN tirent également parti de cette fonctionnalité en plaçant une instance dans chaque groupe d’administration.
Il n’existe aucune interaction client avec cette fonctionnalité. Toutefois, il peut y avoir des étiquettes supplémentaires visibles sur les nœuds de gestion pour identifier les groupes.

La mise à niveau est considérée comme terminée lorsque 80 % des nœuds worker par rack et 50 % des nœuds de gestion dans chaque groupe sont correctement mis à niveau. Les charges de travail peuvent être affectées lorsque les nœuds worker d'un rack sont en cours de mise à niveau. Toutefois, les charges de travail de tous les autres racks ne sont pas affecté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, selon le nombre de racks existants pour le cluster. En raison de la longueur du processus de mise à niveau, l'état détaillé du cluster doit être vérifié périodiquement pour connaître l'état actuel de la mise à niveau. Pour vérifier l’état de la mise à niveau, observez l’état détaillé du cluster. Cette vérification peut être effectuée en utilisant le portail ou l’interface CLI az.

Pour afficher l’état de mise à niveau via 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 "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>"

La sortie doit inclure les informations du cluster cible ainsi que l'état détaillé du cluster et le message d'état détaillé. Pour des informations plus détaillées sur la progression de la mise à niveau, l'état de chaque nœud individuel dans chaque rack peut être vérifié. Un exemple de vérification du statut est fourni dans la section de référence sous Rôles de la machine BareMetal.

Questions fréquentes

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. Étant donné que la mise à niveau du runtime peut prendre beaucoup de temps pour se terminer, il n’y a pas de délai d’attente défini actuellement spécifié. 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 une situation indefinitely attempting to upgrade en consultant les journaux du cluster, le message détaillé et le message d'état détaillé. Si un délai d'attente se produit, nous observerons que le cluster se réconcilie continuellement sur la même chose indéfiniment et n'avance 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.

Identification de la mise à niveau de machine nue bloquée

Un guide permettant d’identifier les problèmes de provisionnement des nœuds de travail est fourni dans Troubleshooting Bare Metal Machine Provisioning.

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

Si une panne matérielle se produit pendant une mise à niveau, la mise à niveau d'exécution se poursuit 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 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 mise à niveau avant la défaillance matérielle, la machine provisionne avec la version précédente du runtime lorsque le matériel est réparé. La machine est mise à niveau avec le rack lorsque le rack démarre sa mise à niveau.

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

Pendant une mise à niveau du temps d'exécution, le cluster entre dans l’étatUpgrading. Si la mise à niveau du runtime échoue, le cluster passe à un état d’approvisionnement Failed . Les composants de l'infrastructure (par exemple, le dispositif de stockage) peuvent provoquer des pannes lors de la mise à niveau. Dans certains scénarios, il peut être nécessaire de diagnostiquer l’échec avec le Support Microsoft.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-11-21