Gestion du comportement en cas d'échec lors d'une mise à niveau

Ce guide décrit les caractéristiques du comportement en cas d’échec lors d'une mise à niveau d'Azure Operator Service Manager (AOSM) pour des fonctions réseau conteneurisées (CNFs). Pour accélérer les nouvelles tentatives, utilisez la pause en cas d’échec. Pour revenir au point de départ, utilisez le rollback en cas d’échec.

Vue d’ensemble de la mise en pause en cas d’échec

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

• Un utilisateur lance une opération de gestion de réputation SNS avec l'option de pause en cas d'échec activée.
• Les nfApps sont traitées selon l’ordre défini par updateDependsOn ou dans l’ordre séquentiel de leur apparition.
• Si une opération d’installation ou de mise à niveau d’une nfApp échoue, le paramètre de rollback atomique associé à cette opération et à cette nfApp est respecté.
• Aucune nfApp déjà terminée n’est à nouveau opérée.
• La tâche se termine et laisse la ressource SNS dans un état d’échec.

Avec pause en cas d’échec, AOSM annule uniquement l'application nfApp ayant échoué, via les paramètres d’opération testOptions, installOptions ou upgradeOptions. Aucune action n’est effectuée sur les nfApps qui suivent la nfApp ayant échoué. Cette méthode permet à l’utilisateur final de dépanner l’application 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.

Mise à niveau réussie

Une mise à niveau est considérée comme réussie si toutes les nfApps atteignent l’état cible souhaité sans générer d’erreurs helm install ou helm upgrade. Dans de telles conditions, Azure Operator Service Manager retourne l’état opérationnel et le message suivants :

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

Échec de la mise à niveau

Une mise à niveau est considérée comme non réussie si une nfApp génère une erreur helm install ou helm upgrade. Dans de telles conditions, Azure Operator Service Manager retourne l’état opérationnel et le message suivants :

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

Vue d’ensemble du rollback en cas d’erreur

Pour résoudre les risques de non-correspondance des versions nfApp, Azure Operator Service Manager prend en charge la restauration au niveau NF en cas d’échec. Avec cette option activée, si une opération nfApp échoue, l’application nfapp ayant échoué et toutes les nfApps terminées antérieures peuvent être restaurées à l’état initial de la version. Cette méthode réduit ou élimine la durée pendant laquelle le NF est exposé à des incompatibilités de version nfApp. La fonctionnalité de restauration facultative en cas d'échec fonctionne comme suit :

• Un utilisateur lance une opération reput SNS avec le rollback en cas d’échec activé.
• Les nfApps sont traitées selon l’ordre défini par updateDependsOn ou dans l’ordre séquentiel de leur apparition.
• L’état atomique de toutes les NfApps est forcé à true, les valeurs fournies par les opérateurs sont ignorées.
• Un instantané des versions nfApp actuelles est capturé et stocké.
• L’instantané permet de déterminer les actions nfApp individuelles à effectuer afin d’inverser celles qui se sont terminées avec succès.
  • helm install action sur les composants supprimés,
  • Action helm rollback sur les composants mis à niveau,
  • helm delete action sur les composants nouvellement installés
• Si une opération d’installation ou de mise à niveau d’une nfApp échoue, un rollback atomique de la nfApp ayant échoué est exécuté en premier.
• Après le rollback atomique, les NfApps précédemment terminées sont restaurées à la version d’instantané d’origine, en annulant d’abord les actions les plus récentes.
• La tâche se termine et laisse la ressource SNS dans un état d’échec.

Mise à niveau réussie

Une mise à niveau est considérée comme réussie si toutes les nfApps atteignent l’état cible souhaité sans générer d’erreurs helm install ou helm upgrade. Dans de telles conditions, Azure Operator Service Manager retourne l’état opérationnel et le message suivants :

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

Retour arrière réussi

Un rollback est considéré comme réussi si toutes les NfApps précédemment terminées ont retrouvé l’état d’instantané d’origine sans générer d’erreur helm rollback. Dans de telles conditions, Azure Operator Service Manager retourne l’état opérationnel et le message suivants :

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

Rollback non réussi

Un rollback est considéré comme non réussi si une nfApp précédemment terminée ne parvient pas à retrouver l’état d’instantané d’origine et génère à la place une erreur helm rollback. Dans de telles conditions, Azure Operator Service Manager cesse de traiter les autres nfApps éligibles au rollback et se termine avec l’état opérationnel et le message suivants :

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

Configurer 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 du schéma de groupe de configuration (CGS), rollbackEnabled, afin d’autoriser le contrôle de la valeur du groupe de configuration (CGV) via roleOverrideValues dans la charge utile NF. Définissez d’abord le paramètre de CGS :

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

Avec le nouveau paramètre rollbackEnable défini, l’opérateur peut désormais fournir une valeur à l’exécution, sous roleOverrideValues, dans le cadre de la charge utile NF reput.

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

Gérer les nfApps qui ne prennent pas en charge le rollback

Presque tous les éditeurs présentent des nfApps qui ne sont pas compatibles avec helm rollback. Ces nfApps peuvent provenir de tiers qui ne prennent généralement pas en charge les exigences strictes en matière de résilience. Ces nfApps peuvent peut-être des applications de base de données avec des exigences complexes de gestion des schémas. Tenez compte des restrictions suivantes lors de l’intégration de services avec nfApps qui ne prennent pas en charge le retour en arrière.

• Les nfApps qui ne prennent pas en charge le rollback ne peuvent pas être ignorées.
• L’ordre de rollback des nfApp ne peut pas être modifié.
• L'approche Incremental-NFDV doit être utilisée dans ces situations.

Rollback sélectif à l’aide des NFDV incrémentiels

La composition d’une fonction réseau peut inclure des nfAppa qui ne prennent pas en charge un helm rollback. Les exemples connus sont Elastic et VoltDb. Toute tentative de rollback de l’une de ces nfApps provoquera son dysfonctionnement Poursuivre les améliorations de l’éditeur pour rendre ces nfApps compatibles avec le rollback est la meilleure solution. Un paramètre permettant d’ignorer le rollback n’est pas pris en charge, car il introduirait le risque d’un état déployé non défini dans un NFDV. Ce comportement non déterministe augmente considérablement la surface de la surface de test et sape les garanties de fiabilité des déploiements. Au lieu de cela, la méthode NFDV progressive permet une restauration sélective tout en garantissant des états de déploiement déterministes.

Approche NFDV incrémentielle

Il est recommandé que les éditeurs utilisent une combinaison de configurations applicationEnablement, skipUpgrade et nfRollbackEnabled dans les CGV, ainsi que plusieurs NFDV, afin de segmenter logiquement les nfApps en ensembles selon leur compatibilité avec le rollback. Cette stratégie NFDV incrémentielle permet aux opérateurs de segmenter les déploiements en plusieurs opérations, en omettant le rollback pour certains charts tout en le préservant pour les autres. Cette approche simule efficacement le comportement de retour en arrière pour chaque graphique à l’aide de constructions au niveau NFDV. Prenons l’exemple suivant où une fonction réseau est composée de 20 nfApps, dont cinq nfApps ne prennent pas en charge l'annulation.

• NFDV1
  • Effectue l’installation initiale de verions 1.
    • Contient les 20 nfApps, toutes en état activé.
  • En CGV1 : rollbackEnabled: true.
    • Lors de la première installation, un échec supprime les charts et n’utilise pas le rollback.
• NFDV2 :
  • Effectue la première étape de mise à niveau vers la version 2.
    • Contient les 20 nfApps, mais n’active que les cinq nfApps ne prenant pas en charge le rollback.
  • Dans CGV2 :
    • Utilisez skipUpgrade: true pour les 15 nfApps prenant en charge le rollback.
    • Définissez nfRollbackEnabled: false.
      • En cas de réussite, seules cinq nfApps sont mises à niveau.
      • En cas d’échec, aucun repli n’est effectué.
        • En raison des limitations du graphique, la charge de travail est laissée dans un état non déterministe. Aucune réversion n’est possible. Pour récupérer, il existe deux options :
          • Corrigez NFDV2 et réessayez la mise à niveau.
          • Rétrograder vers NFDV1 avec skipUpgrade: false
• NFDV3 :
  • Effectue la deuxième étape de mise à niveau vers la version 2
    • Contient les 20 nfApps, mais n’active que les 15 nfApps prenant en charge le rollback.
  • Dans CGV3 :
    • Utiliser skipUpgrade: true pour les 5 nfApps précédentes mises à niveau via NFDV2.
    • Définissez nfRollbackEnabled: true.
      • En cas de réussite, les 15 nfApps restants sont mis à niveau
      • En cas d’échec, un rebasculement se produit pour rétablir l’état initial.

Cette approche permet de mieux séparer et gérer les applications qui ne prennent pas en charge les opérations Helm standard. Maintient l’idempotence de l’opération ainsi que l’état sur le cluster tel que reflété par la dernière opération. NFDV 2/3 peut être utilisé directement pour les opérations d'installation, sans nécessité d'installer la version précédente, même en présence de différences dans l'état d'objectif. Le temps de mise à niveau global et la fiabilité du déploiement restent les mêmes.

Résoudre les problèmes liés à un rollback 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 du pod est en cours par Kubernetes.
• 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 les 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 tous 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.