Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Automatisation du basculement des applications avec état avec Trident

PDF

La fonctionnalité de détachement forcé de Trident permet de détacher automatiquement les volumes des nœuds défaillants d'un cluster Kubernetes, évitant ainsi la corruption des données et garantissant la disponibilité des applications. Cette fonctionnalité est particulièrement utile dans les scénarios où des nœuds deviennent indisponibles ou sont mis hors ligne pour maintenance.

Détails concernant le détachement forcé

Le détachement forcé est disponible pour ontap-san, ontap-san-economy, ontap-nas et ontap-nas-economy uniquement. Avant d'activer le détachement forcé, l'arrêt brutal des nœuds (NGNS) doit être activé sur le cluster Kubernetes. NGNS est activé par défaut pour Kubernetes 1.28 et versions ultérieures. Pour plus d'informations, consultez "Kubernetes : arrêt non gracieux d'un nœud".

Remarque Lorsque vous utilisez le ontap-nas ou ontap-nas-economy pilote, vous devez définir le paramètre autoExportPolicy dans la configuration du backend sur true afin que Trident puisse restreindre l'accès depuis le nœud Kubernetes avec la contamination appliquée à l'aide de politiques d'exportation gérées.
Avertissement Étant donné que Trident repose sur Kubernetes NGNS, ne supprimez pas out-of-service les taints d'un nœud défaillant tant que toutes les charges de travail non tolérables n'ont pas été reprogrammées. Appliquer ou supprimer le taint sans précaution peut compromettre la protection des données du backend.

Lorsque l'administrateur du cluster Kubernetes a appliqué la node.kubernetes.io/out-of-service=nodeshutdown:NoExecute`taint au nœud et `enableForceDetach`est définie sur `true, Trident déterminera l'état du nœud et :

  1. Arrêtez l'accès E/S du backend pour les volumes montés sur ce nœud.

  2. Marquez l'objet nœud Trident comme dirty (non sûr pour les nouvelles publications).

    Remarque Le contrôleur Trident refusera les nouvelles demandes de publication de volumes tant que le nœud n'aura pas été requalifié (après avoir été marqué comme dirty) par le pod Trident du nœud. Les charges de travail planifiées avec un PVC monté (même après que le nœud de cluster soit opérationnel et prêt) ne seront pas acceptées tant que Trident ne peut pas vérifier le nœud clean (sécurisé pour de nouvelles publications).

Lorsque l'intégrité du nœud est rétablie et que la contamination est supprimée, Trident :

  1. Identifiez et nettoyez les chemins publiés obsolètes sur le nœud.

  2. Si le nœud est dans un cleanable état (la contamination hors service a été supprimée et le nœud est dans un Ready état) et que tous les chemins publiés obsolètes sont propres, Trident réadmettra le nœud en clean et autorisera de nouveaux volumes publiés sur le nœud.

Détails sur le basculement automatique

Vous pouvez automatiser le processus de déconnexion forcée grâce à l'intégration avec "opérateur de vérification de l'état des nœuds (NHC)". Lorsqu'une défaillance de nœud se produit, NHC déclenche la remédiation du nœud Trident (TNR) et la déconnexion forcée automatiquement en créant un CR TridentNodeRemediation dans l'espace de noms de Trident, définissant le nœud défaillant. La TNR est créée uniquement lors d'une défaillance de nœud et supprimée par NHC une fois que le nœud est remis en ligne ou supprimé.

Échec du processus de suppression du pod du nœud

Le basculement automatique sélectionne les charges de travail à retirer du nœud défaillant. Lorsqu'un TNR est créé, le contrôleur TNR marque le nœud comme sale, empêchant toute nouvelle publication de volume et commence à supprimer les pods compatibles avec le détachement forcé ainsi que leurs attachements de volumes.

Tous les volumes/PVC pris en charge par force-detach sont pris en charge par automated-failover :

  • Volumes NAS et NAS-economy utilisant des politiques d'auto-exportation (SMB n'est pas encore pris en charge).

  • Volumes SAN et SAN-economy.

Voir Détails concernant le détachement forcé.

Comportement par défaut:

  • Les pods utilisant des volumes compatibles avec le détachement forcé sont supprimés du nœud défaillant. Kubernetes les reprogrammera sur un nœud sain.

  • Les pods utilisant un volume non pris en charge par le force-detach, y compris les volumes non-Trident, ne sont pas supprimés du nœud défaillant.

  • Les pods sans état (et non les PVC) ne sont pas supprimés du nœud défaillant, sauf si l’annotation du pod trident.netapp.io/podRemediationPolicy: delete est définie.

Remplacement du comportement de suppression des pods :

Le comportement de suppression des pods peut être personnalisé à l'aide d'une annotation : trident.netapp.io/podRemediationPolicy[retain, delete]. Ces annotations sont examinées et utilisées lors d'un basculement. Appliquez des annotations à la spécification du pod du déploiement/replicaset Kubernetes pour éviter que l'annotation ne disparaisse après un basculement :

  • retain - Le pod ne sera PAS supprimé du nœud défaillant lors d'un basculement automatique.

  • delete - Le pod sera supprimé du nœud défaillant lors d'un basculement automatique.

Ces annotations peuvent être appliquées à n'importe quel pod.

Avertissement

  • Les opérations d'E/S seront bloquées uniquement sur les nœuds défaillants pour les volumes prenant en charge force-detach.

  • Pour les volumes qui ne prennent pas en charge le détachement forcé, il existe un risque de corruption des données et de problèmes de multi-connexion.

CR TridentNodeRemediation

Le TridentNodeRemediation (TNR) CR définit un nœud défaillant. Le nom du TNR est le nom du nœud défaillant.

Exemple de TNR:

apiVersion: trident.netapp.io/v1
kind: TridentNodeRemediation
metadata:
  name: <K8s-node-name>
spec: {}

États TNR : Utilisez les commandes suivantes pour afficher l’état des TNR :
kubectl get tnr <name> -n <trident-namespace>

Les TNR peuvent se trouver dans l'un des états suivants :

  • Remédiation :

    • Cessez l'accès aux E/S du backend pour les volumes pris en charge par force-detach montés sur ce nœud.

    • L'objet nœud Trident est marqué comme sale (non sûr pour les nouvelles publications).

    • Supprimez les pods et les attachements de volumes du nœud

  • Récupération du nœud en attente:

    • Le contrôleur attend que le nœud soit de nouveau en ligne.

    • Une fois le nœud en ligne, publish-enforcement garantira que le nœud est propre et prêt pour de nouvelles publications de volumes.

  • Si le nœud est supprimé de K8s, le contrôleur TNR supprimera le TNR et cessera la réconciliation.

  • Réussi:

    • Toutes les étapes de correction et de récupération du nœud ont été réalisées avec succès. Le nœud est propre et prêt pour la publication de nouveaux volumes.

  • Échec :

    • Erreur irrécupérable. Les raisons de l'erreur sont indiquées dans le champ status.message de la CR.

Activation du basculement automatique

Prérequis :

Remarque Vous pouvez également utiliser d'autres méthodes pour détecter les défaillances de nœud, comme spécifié dans la section [Integrating Custom Node Health Check Solutions] ci-dessous.

Voir "Opérateur de vérification de l'état des nœuds" pour plus d'informations.

Étapes

  1. Créez une ressource personnalisée NodeHealthCheck (NHC) dans l'espace de noms Trident pour surveiller les nœuds de travail du cluster. Exemple :

    apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: <CR name>
spec:
  selector:
    matchExpressions:
      - key: node-role.kubernetes.io/control-plane
        operator: DoesNotExist
      - key: node-role.kubernetes.io/master
        operator: DoesNotExist
  remediationTemplate:
    apiVersion: trident.netapp.io/v1
    kind: TridentNodeRemediationTemplate
    namespace: <Trident installation namespace>
    name: trident-node-remediation-template
  minHealthy: 0 # Trigger force-detach upon one or more node failures
  unhealthyConditions:
    - type: Ready
      status: "False"
      duration: 0s
    - type: Ready
      status: Unknown
      duration: 0s

  2. Appliquez le CR de vérification de l'état du nœud dans l'espace de noms trident.

    kubectl apply -f <nhc-cr-file>.yaml -n <trident-namespace>

La ressource personnalisée (CR) ci-dessus est configurée pour surveiller les nœuds de travail K8s et détecter les états Ready: false et Unknown. Automated-Failover sera déclenché lorsqu'un nœud passe à l'état Ready: false ou Ready: Unknown.

Le unhealthyConditions dans le CR utilise un délai de grâce de 0 seconde. Cela provoque un basculement automatique immédiat dès que K8s définit la condition Ready : false, ce qui se produit après que K8s a perdu le signal de présence d'un nœud. K8s attend par défaut 40 secondes après le dernier signal de présence avant de définir Ready : false. Ce délai de grâce peut être personnalisé dans les options de déploiement de K8s.

Pour plus d'options de configuration, veuillez vous référer à "Documentation de l'opérateur Node-Healthcheck-Operator".

Informations de configuration supplémentaires

Lorsque Trident est installé avec le détachement forcé activé, deux ressources supplémentaires sont automatiquement créées dans l'espace de noms Trident pour faciliter l'intégration avec NHC : TridentNodeRemediationTemplate (TNRT) et ClusterRole.

TridentNodeRemediationTemplate (TNRT) :

Le TNRT sert de modèle au contrôleur NHC, qui utilise TNRT pour générer des ressources TNR selon les besoins.

apiVersion: trident.netapp.io/v1
kind: TridentNodeRemediationTemplate
metadata:
  name: trident-node-remediation-template
  namespace: trident
spec:
  template:
    spec: {}

ClusterRole :

Un rôle de cluster est également ajouté lors de l'installation lorsque le détachement forcé est activé. Cela donne à NHC les autorisations pour les TNR dans l'espace de noms Trident.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    rbac.ext-remediation/aggregate-to-ext-remediation: "true"
  name: tridentnoderemediation-access
rules:
- apiGroups:
  - trident.netapp.io
  resources:
  - tridentnoderemediationtemplates
  - tridentnoderemediations
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete

Mises à niveau et maintenance des clusters K8s

Pour éviter tout basculement, suspendez le basculement automatique pendant la maintenance ou la mise à niveau de K8s, lorsque les nœuds doivent être arrêtés ou redémarrés. Vous pouvez suspendre le CR NHC (décrit ci-dessus) en modifiant son CR :

kubectl patch NodeHealthCheck <cr-name> --patch '{"spec":{"pauseRequests":["<description-for-reason-of-pause>"]}}' --type=merge

Cela suspend le basculement automatique. Pour réactiver le basculement automatique, supprimez le pauseRequests de la spécification après la fin de la maintenance.

Limitations

  • Les opérations d'E/S sont bloquées uniquement sur les nœuds défaillants pour les volumes pris en charge par force-detach. Seuls les pods utilisant des volumes/PVCs pris en charge par force-detach sont automatiquement supprimés.

  • Le basculement automatique et le détachement forcé s'exécutent au sein du pod trident-controller. Si le nœud hébergeant trident-controller tombe en panne, le basculement automatique sera différé jusqu'à ce que K8s déplace le pod vers un nœud sain.

Intégration de solutions personnalisées de vérification de l'état des nœuds

Vous pouvez remplacer Node Healthcheck Operator par d'autres outils de détection des pannes de nœuds pour déclencher un basculement automatique. Pour garantir la compatibilité avec le mécanisme de basculement automatique, votre solution personnalisée doit :

  • Créez un TNR lorsqu'une défaillance de nœud est détectée, en utilisant le nom du nœud défaillant comme nom du CR TNR.

  • Supprimez le TNR lorsque le nœud a récupéré et que le TNR est à l'état Succeeded.