Partager via

Contrôler le comportement d’échec d’une mise à niveau

  • Article

Vue d’ensemble

Ce guide décrit les fonctionnalités du comportement d’échec d’une mise à niveau d’Azure Operator Service Manager (AOSM) pour des fonctions réseau conteneurisées (CNF). Ces fonctionnalités, dans le cadre de l’initiative des pratiques de mise à niveau sécurisées d’AOSM, offrent le choix entre des nouvelles tentatives plus rapides avec une pause en cas d’échec par rapport au retour au point de départ avec une restauration en cas d’échec.

Pause en cas d’échec

Toute mise à niveau utilisant AOSM commence par une opération reput de service de réseau de site (SNS). L’opération reput traite les applications de fonction réseau (NfApps) détectées dans la version de conception de fonction réseau (NFDV). L’opération reput implémente la logique par défaut suivante :

  • Les NfApps sont traitées en suivant l’ordre updateDependsOn ou dans l’ordre séquentiel de leur apparition.
  • Les NfApps avec le paramètre « applicationEnabled » définies pour la désactivation sont ignorées.
  • Les NfApps présentes, mais non référencées par la nouvelle NFDV, sont supprimées.
  • La séquence d’exécution est mise en pause si l’une des mises à niveau de NfApp échoue et qu’une restauration est envisagée.
  • La défaillance quitte la ressource NF dans un état d’échec.

Avec la pause en cas d’échec, AOSM restaure uniquement la NfApp en échec via les paramètres testOptions, installOptions ou upgradeOptions. Aucune action n’est entreprise sur les NfApps qui donnent suite à la NfApp ayant échoué. Cette méthode permet à l’utilisateur final de dépanner la NfApp ayant échoué, puis de redémarrer la mise à niveau à partir de ce point. En tant que comportement par défaut, cette méthode est la plus efficace, mais elle peut entraîner des incohérences de la fonction réseau (NF) pendant un état de version mixte.

Restauration en cas d’échec

Pour résoudre le risque de versions NfApp non compatibles, AOSM prend désormais en charge la restauration au niveau de la fonction réseau en cas d’échec. Quand cette option est activée et qu’une opération NfApp échoue, la NfApp en échec et toutes les NfApps terminées précédentes peuvent être restaurées vers leur état de version initial. Cette méthode minimise ou élimine le temps d’exposition de la fonction réseau aux incompatibilités de version NfApp. La restauration facultative sur une fonctionnalité d’échec fonctionne comme suit :

  • Un utilisateur lance une opération reput sSNS et active la restauration en cas d’échec.
  • Une capture instantanée des versions NfApp actuelles est capturée et stockée.
  • La capture instantanée est utilisée pour déterminer les actions NfApp individuelles entreprises afin d’inverser les actions correctement terminées.
    • L’action « helm install » sur des composants supprimés,
    • L’action « helm rollback » sur des composants mis à niveau,
    • L’action « helm delete » sur des composants nouvellement installés
  • L’échec de NfApp se produit, AOSM restaure les NfApps vers l’état de version de la capture instantanée avant la mise à niveau, avec les actions les plus récentes rétablies en premier.

Remarque

  • AOSM ne crée pas de capture instantanée si un utilisateur n’active pas la restauration en cas d’échec.
  • La restauration en cas d’échec s’applique uniquement aux NFApps correctement terminées.
    • Utilisez les paramètres testOptions, installOptions ou upgradeOptions pour contrôler la restauration d’une NfApp ayant échoué.

AOSM retourne les messages et l’état opérationnel suivants, compte tenu des résultats respectifs :

  - Upgrade Succeeded
    - Provisioning State: Succeeded
    - Message: <empty>

  - Upgrade Failed, Rollback Succeeded
    - Provisioning State: Failed
    - Message: Application(<ComponentName>) : <Failure Reason>; Rollback succeeded

  - Upgrade Failed, Rollback Failed
    - Provisioning State: Failed
    - Message: Application(<ComponentName>) : <Failure reason>; Rollback Failed (<RollbackComponentName>) : <Rollback Failure reason>

Méthode de configuration de la restauration en cas d’échec

La méthode la plus flexible pour contrôler le comportement d’échec consiste à étendre un nouveau paramètre de schéma de groupe de configurations (CGS), rollbackEnabled, pour autoriser le contrôle de valeur de groupe de configurations (CGV) via roleOverrideValues dans la charge utile de fonction réseau. Définissez d’abord le paramètre de CGS :

{
  "description": "NF configuration",
  "type": "object",
  "properties": {
    "nfConfiguration": {
      "type": "object",
      "properties": {
        "rollbackEnabled": {
          "type": "boolean"
        }
      },
      "required": [
        "rollbackEnabled"
      ]
    }
  }
}

Remarque

  • Si le paramètre nfConfiguration n’est pas fourni via le paramètre roleOverrideValues, la restauration est par défaut désactivée.

Une fois le nouveau paramètre rollbackEnable défini, l’opérateur peut maintenant fournir une valeur de temps d’exécution sous roleOverrideValues dans le cadre de la charge utile reput de fonction réseau.

example:
{
  "location": "eastus",
  "properties": {
    // ...
    "roleOverrideValues": [
          "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",
            "{\"name\":\"nfApp1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Disabled\"}}",
            "{\"name\":\"nfApp2\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Disabled\"}}",
          //... other nfapps overrides
       ]
  }
}

Remarque

  • Chaque entrée roleOverrideValues remplace le comportement par défaut des NfAapps.
  • Si plusieurs entrées de nfConfiguration sont détectées dans le paramètre roleOverrideValues, l’opération NF reput est retournée comme requête incorrecte.

Procédure de dépannage d’une restauration en cas d’échec

Comprendre les états d’un pod

La compréhension des différents états d’un pod est cruciale pour une bonne résolution des problèmes. Voici les états de pod les plus courants :

  • En attente : la planification de pod par Kubernetes est en cours.
  • Exécution en cours : tous les conteneurs du pod s’exécutent et sont sains.
  • Échec : un ou plusieurs conteneurs du pod sont annulés avec un code de sortie différent de zéro.
  • CrashLoopBackOff : un conteneur du pod se bloque à plusieurs reprises et Kubernetes ne peut pas le redémarrer.
  • ContainerCreating : la création de conteneur par le runtime de conteneur est en cours.

Vérifier l’état du pod et les journaux d’activité

Commencez d’abord par vérifier l’état du pod et des journaux d’activité en utilisant une commande kubectl :

$ kubectl get pods
$ kubectl logs <pod-name>

La commande get pods répertorie tous les pods dans l’espace de noms actuel, ainsi que leur état actuel. La commande logs récupère les journaux d’activité d’un pod spécifique, ce qui vous permet d’inspecter toutes les erreurs ou exceptions. Pour résoudre des problèmes de mise en réseau, utilisez les commandes suivantes :

$ kubectl get services
$ kubectl describe service <service-name>

La commande get services affiche tous les services dans l’espace de noms actuel. La commande fournit des informations sur un service spécifique, notamment les points de terminaison associés et tous les messages d’erreur pertinents. Si vous rencontrez des problèmes avec des revendications de volume persistant (PVC), vous pouvez utiliser les commandes suivantes pour les déboguer :

$ kubectl get persistentvolumeclaims
$ kubectl describe persistentvolumeclaims <pvc-name>

La commande « get persistentvolumeclaims » répertorie toutes les PVC dans l’espace de noms actuel. La commande describe fournit des informations détaillées sur une PVC spécifique, notamment l’état, la classe de stockage associée et tous les événements ou toutes les erreurs applicables.