Gérer les clusters GKE optimisés pour l'IA

Cette page vous explique comment gérer les clusters Google Kubernetes Engine (GKE) optimisés pour l'IA des machines A4X Max, A4X, A4, A3 Ultra, A3 Mega et A3 High (8 GPU), y compris les événements courants suivants concernant les clusters GKE et les charges de travail d'IA :

  • Maintenance de l'hôte
  • Mise à niveau des clusters
  • Signalement d'un hôte défectueux

Gérer la maintenance des hôtes pour les charges de travail d'IA

Les nœuds GKE s'exécutent sur des instances Compute Engine qui subissent régulièrement des événements hôtes pouvant perturber les charges de travail d'IA. Étant donné que les événements d'hôte se produisent sur l'infrastructureGoogle Cloud sous-jacente, ils contournent les intervalles de maintenance et exclusions de GKE. Bien que la plupart des instances de calcul aient leur règle de maintenance de l'hôte définie sur migration à chaud, ce qui minimise l'interruption des charges de travail, les GPU et les TPU ne sont pas compatibles avec la migration à chaud. Lorsque ces événements d'hôte affectent vos nœuds GKE exécutant des charges de travail d'IA, GKE doit arrêter le nœud et les pods qui s'y exécutent. Si les pods sont déployés dans le cadre d'une charge de travail plus importante, telle qu'un job ou un déploiement, GKE tente de redémarrer les pods sur le nœud concerné.

Pour en savoir plus sur la gestion de la maintenance des hôtes des instances de calcul sous-jacentes, consultez Gérer les interruptions des nœuds GKE pour les GPU et les TPU.

Surveiller les événements de maintenance de l'hôte

Pour les clusters exécutant GKE version 1.31.1-gke.2008000 ou ultérieure, vous pouvez afficher l'heure de début planifiée de l'événement de maintenance de l'hôte de la manière suivante. L'heure de début est représentée par des étiquettes de nœud Kubernetes sur le nœud GKE correspondant pour tous les GPU et TPU.

Pour en savoir plus, consultez Surveiller les notifications de maintenance.

Ces libellés de nœud vous permettent d'effectuer les opérations suivantes :

Démarrer manuellement un événement de maintenance de l'hôte

Une fois que Compute Engine a émis une notification concernant un événement de maintenance planifié, vous pouvez démarrer manuellement la maintenance à un moment qui correspond à votre planning. Par exemple, vous pouvez choisir d'effectuer la maintenance pendant les périodes d'activité réduite.

Si vous ne démarrez pas manuellement un événement de maintenance de l'hôte, Compute Engine effectuera automatiquement la maintenance planifiée régulièrement.

Suivez les instructions pour démarrer manuellement un événement de maintenance de l'hôte. Continuez également à lire cette section pour en savoir plus sur les points suivants :

Utiliser les informations de maintenance de l'hôte lors de la planification de vos charges de travail

Vous pouvez utiliser les informations de maintenance affichées via les étiquettes de nœud GKE, ainsi que l'affinité et l'anti-affinité de nœud, pour minimiser les perturbations de vos charges de travail.

Consultez les sections suivantes pour obtenir des exemples d'utilisation de ces informations.

Planifier des pods sur des nœuds qui n'ont pas d'événements de maintenance planifiés à l'avenir

Vous pouvez indiquer à GKE de ne planifier des pods que sur des nœuds qui n'ont pas d'événements de maintenance planifiés à l'avenir, comme dans l'extrait suivant :

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: DoesNotExist

Planifier des pods sur des nœuds dont la maintenance est programmée après une certaine date

Vous pouvez indiquer à GKE de ne planifier des pods que sur les nœuds dont la maintenance est planifiée après une certaine date en fournissant l'heure d'epoch Unix :

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: Gt
            values:
            - 1733296000

Gérer les mises à niveau des clusters GKE pour les charges de travail d'IA

Les charges de travail d'IA sont sensibles aux interruptions.

Au cours du cycle de vie d'un cluster GKE, les charges de travail d'IA doivent être préparées aux interruptions des instances de calcul sous-jacentes, ainsi que du cluster GKE lui-même :

Nous vous recommandons de laisser votre cluster enregistré dans un version disponible. Par défaut, les clusters GKE sont enregistrés dans le canal de publication standard. Pour en savoir plus sur les avantages des canaux de publication, consultez la comparaison entre les clusters enregistrés et non enregistrés dans un canal de publication.

Avec les canaux de publication, vous avez accès à davantage de fonctionnalités, y compris des champs d'application d'exclusion de maintenance supplémentaires. Nous recommandons le champ d'application "Aucune mise à niveau mineure ni de mise à niveau des nœuds" pour les charges de travail d'IA.

Signaler des hôtes défectueux via GKE

Cette section explique comment, via GKE, vous pouvez signaler un hôte défectueux sur lequel des instances de calcul sont provisionnées à l'aide du modèle de provisionnement standard, de démarrage flexible ou lié à une réservation. Si vous souhaitez signaler un hôte défectueux pour un nœud provisionné à l'aide du modèle de provisionnement Spot ou qui utilise des GPU généraux, contactez plutôt l'équipe chargée de votre compte.

Si vous observez des erreurs de mémoire GPU ou Xid sur un nœud et que vous souhaitez vérifier si des mesures de récupération manuelles, telles que le déclenchement d'un redémarrage de l'OS invité (kubectl label nodes <NODE_NAME> cloud.google.com/perform-reboot=true), peuvent résoudre le problème avant de signaler l'hôte comme défectueux, consultez Examiner les messages Xid.

Un hôte est une machine de serveur physique unique dans le centre de données qui exécute une instance de calcul hébergeant votre nœud GKE. Vous pouvez signaler les hôtes défectueux en appliquant une étiquette de nœud fault-behavior au nœud GKE concerné. Une fois que vous avez appliqué l'étiquette de nœud à un nœud GKE particulier, GKE effectue les étapes suivantes :

  1. Supprime de manière optimale les charges de travail du nœud.
  2. Empêche de programmer de nouveaux pods sur le nœud.
  3. Appelle l'API sur l'instance de calcul pour marquer l'hôte comme défectueux.
  4. Attendre que l'instance de calcul soit remise en service sur une machine hôte opérationnelle. Pour les réservations qui utilisent le mode opérationnel de réservation toute la capacité, Compute Engine restaure l'instance de calcul sur le même nœud une fois l'opération de réparation terminée.
  5. Supprime le rejet et l'étiquette fault-behavior du nœud.

Le nœud sera alors de nouveau prêt à diffuser des charges de travail.

Conditions requises

Pour signaler un hôte défectueux, votre nœud GKE doit répondre aux exigences suivantes :

  • Vous devez exécuter la version de correctif GKE 1.32.3-gke.1057001 ou une version ultérieure.
  • Vous devez exécuter l'un des types de machines GPU suivants : A4X Max, A4X, A4, A3 Ultra, A3 Mega et A3 High (8 GPU).
  • Vous devez exécuter vos nœuds GKE sur une instance de calcul liée à une réservation.
  • Votre nœud GKE doit être à l'état RUNNING. Si vous essayez de signaler un hôte défectueux après avoir supprimé l'instance de calcul, un message d'erreur s'affiche et la machine hôte n'est pas marquée comme défectueuse.
  • Le nombre d'appels à cette API par réservation et par mois peut être limité en fonction de l'évaluation de l'état de vos blocs. Les limites de débit ne s'appliquent pas si votre réservation utilise le mode opérationnel de réservation de capacité totale.

Signaler un hôte défectueux

Pour signaler un hôte défectueux :

  1. Utilisez les outils d'observabilité GKE, vos propres outils de surveillance ou les journaux pour identifier les nœuds GKE qui rencontrent des problèmes de performances. Enregistrez le fichier NODE_NAME.

  2. Signalez le nœud comme défectueux à l'aide de la commande suivante. Vous pouvez fournir un motif et, avec les versions ultérieures, une description :

      kubectl patch node NODE_NAME --type merge -p '{
    "metadata": {
      "labels": {
        "cloud.google.com/fault-behavior": "FAULT_REASON"
      },
      "annotations": {
        "cloud.google.com/fault-description": "FAULT_DESCRIPTION"
      }
    }
  }'

    Modifiez la commande comme suit :

    • Remplacez NODE_NAME par le nom du nœud défectueux.
    • Remplacez FAULT_REASON par le motif d'erreur approprié en utilisant une ou plusieurs des valeurs suivantes :
      • PERFORMANCE : utilisez cette valeur si les GPU d'une instance de calcul sont plus lents que les autres GPU du cluster et que vous ne voyez aucune erreur XID dans les journaux, et qu'aucun autre schéma d'échec habituel, tel qu'une corruption de données silencieuse, n'est détecté.
      • SDC : utilisez cette valeur pour la corruption de données silencieuse, si vous constatez une corruption de données, mais pas de plantage du système. Cette corruption des données peut être causée par des défauts du processeur, des bugs logiciels tels que l'utilisation après libération ou l'écrasement de la mémoire, des problèmes de noyau ou d'autres défauts. Le plus souvent, ce terme est utilisé pour désigner les défauts induits par le matériel.
      • XID : utilisez cette valeur si vous avez identifié une erreur de GPU irrécupérable avec un XID pour une instance de calcul.
      • unspecified : utilisez cette valeur si vous ne savez pas quel comportement est à l'origine du problème avec votre instance de calcul. Il s'agit de la valeur par défaut. Toutefois, nous vous recommandons de spécifier l'une des autres valeurs, le cas échéant.
    • Ajustez le bloc annotations en fonction de la version du plan de contrôle de votre cluster GKE :
      • 1.35.6-gke.1017000 ou version ultérieure, ou 1.36.0-gke.3251000 ou version ultérieure : conservez le bloc d'annotations et remplacez FAULT_DESCRIPTION par une description textuelle de l'erreur observée. Il peut s'agir du code d'erreur XID, des symptômes ou des codes temporels. Cette description est transmise à Compute Engine pour faciliter le diagnostic de réparation. Elle est automatiquement supprimée du nœud une fois l'opération terminée. Par exemple : GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z.
      • Versions antérieures : supprimez l'intégralité du bloc annotations de la commande. Le champ fault-description n'est pas transmis à Compute Engine dans ces versions et n'est pas automatiquement supprimé du nœud. Contactez plutôt l'équipe chargée de votre compte ou Cloud Customer Care pour fournir des détails sur l'erreur.
Après avoir signalé un hôte défectueux pour un nœud, l'heure de redémarrage du nœud varie en fonction du mode opérationnel de réservation spécifié dans la réservation utilisée par le nœud. Pour vérifier le mode opérationnel d'une réservation, affichez le champ reservationOperationalMode dans la réservation. Le tableau suivant récapitule le processus d'hôte défaillant pour les deux modes opérationnels de réservation disponibles : le mode de capacité totale et le mode géré.
Mode Toute la capacité (ALL_CAPACITY) Mode géré (HIGHLY_AVAILABLE_CAPACITY)
Types de machines compatibles A4X Max et A4X A4, A3 Ultra, A3 Mega et A3 High (8 GPU)
Limitation du débit de l'API de signalement d'hôte défectueux Aucune limite de débit ne s'applique. Le débit des appels d'API peut être limité.
Processus de signalement d'un hôte défectueux

Lorsque vous signalez un hôte défectueux pour un nœud qui s'exécute en mode de capacité totale, voici ce qui se produit :

  1. Évincer les pods : une fois l'étiquette appliquée au nœud défaillant, GKE applique un rejet au nœud pour bloquer la planification de nouveaux pods. GKE commence également à expulser progressivement les pods en cours d'exécution sur le nœud. GKE respecte les budgets d'interruption de pod (PDB) et le champ spec.terminationGracePeriodSeconds de vos fichiers manifestes de pod. Pour en savoir plus, consultez Configurer GKE pour arrêter correctement vos charges de travail.
  2. Signaler et réparer l'hôte défectueux : GKE appelle l'API Compute Engine pour signaler et réparer l'hôte défectueux. Cette séquence d'opérations prend généralement entre 10 et 12 minutes pour signaler l'hôte défectueux, et entre 3 et 14 jours, voire plus, pour réparer l'hôte.

  3. Redémarrer le nœud : une fois l'opération de réparation de l'hôte terminée, l'un des événements suivants se produit :

    • Si le nœud est à l'état REPAIRING et que les ressources sont disponibles une fois la réparation terminée, Compute Engine redémarre automatiquement le nœud sur l'hôte réparé.
    • Sinon, si le nœud est à l'état TERMINATED ou si les ressources ne sont pas disponibles une fois la réparation terminée, l'état du nœud reste ou passe à TERMINATED. Vous devez redémarrer manuellement le nœud lorsque vous souhaitez l'exécuter. Toutefois, si les ressources ne sont pas disponibles lorsque vous redémarrez le nœud (par exemple, si d'autres instances de calcul utilisent déjà l'hôte réparé), le redémarrage peut échouer.

Lorsque vous signalez un hôte défectueux pour un nœud qui s'exécute en mode géré, voici ce qui se produit :

  1. Évincer les pods : une fois l'étiquette appliquée au nœud défaillant, GKE applique un rejet au nœud pour bloquer la planification de nouveaux pods. GKE commence également à expulser progressivement les pods en cours d'exécution sur le nœud. GKE respecte les budgets d'interruption de pod (PDB) et le champ spec.terminationGracePeriodSeconds de vos fichiers manifestes de pod. Pour en savoir plus, consultez Configurer GKE pour arrêter correctement vos charges de travail.

  2. Signaler et commencer à réparer l'hôte défectueux : GKE appelle l'API Compute Engine pour signaler et réparer l'hôte défectueux. Cette séquence d'opérations prend généralement entre 10 et 12 minutes pour signaler l'hôte défectueux.

    Le comportement du nœud au démarrage de l'opération de réparation de l'hôte varie selon la série de machines :

    • A4 et A3 Ultra : GKE tente de migrer à chaud le nœud vers un autre hôte. Si vous ne disposez pas d'une capacité réservée suffisante ou si la capacité n'est pas disponible dans la zone du nœud, celui-ci s'arrête.
    • A3 Mega et A3 High : GKE arrête le nœud et le redémarre sur un hôte opérationnel.

    La réparation de l'hôte défectueux d'origine peut prendre de 3 à 14 jours, voire plus dans certains cas.

  3. Migrer ou redémarrer le nœud : une fois l'opération de réparation de l'hôte lancée, Compute Engine tente de réserver un hôte opérationnel pour remplacer l'hôte défectueux signalé dans votre capacité réservée. Si Compute Engine trouve un hôte de remplacement, les événements suivants se produisent :

    • A4 et A3 Ultra : si le nœud a été migré à chaud à l'étape précédente, il continue de s'exécuter sur l'hôte de remplacement. Si le nœud a été arrêté, il redémarre sur l'hôte de remplacement.
    • A3 Mega et A3 High : le nœud redémarre sur l'hôte de remplacement.

    Si Compute Engine ne trouve pas d'hôte de remplacement immédiatement, le nœud redémarre comme suit :

    • Si le nœud est à l'état REPAIRING et que des ressources sont disponibles avant ou au moment où la réparation se termine, Compute Engine redémarre automatiquement le nœud sur un hôte opérationnel.
    • Sinon, si le nœud est à l'état TERMINATED ou si les ressources ne sont pas disponibles avant ou lorsque la réparation est terminée, l'état du nœud reste ou passe à TERMINATED. Vous devez redémarrer manuellement le nœud lorsque vous souhaitez l'exécuter.

    Contrairement au mode "Toute la capacité", vous n'avez pas besoin d'attendre que l'hôte défectueux d'origine soit réparé pour que votre charge de travail puisse reprendre.

Surveiller la progression de l'opération

Vous pouvez surveiller la progression de l'opération de GKE à l'aide de l'étiquette de nœud cloud.google.com/report-and-replace-status sur votre nœud GKE, qui possède l'une des valeurs suivantes :

  • PodsEvicted : GKE a terminé l'éviction des pods du nœud concerné.
  • OperationRUNNING : l'opération de signalement de l'hôte défectueux est en cours d'exécution.
  • OperationDONE : l'hôte sous-jacent a été signalé comme défectueux et le nœud GKE est prêt à être déplacé vers un nouvel hôte.
  • OperationFAILED : l'API sur l'instance de calcul a échoué en raison de limites de quota ou d'autres problèmes d'infrastructure. Pour comprendre l'erreur, consultez Résoudre les erreurs de l'API de signalement d'hôte défectueux. Pour savoir comment récupérer, consultez Gérer les échecs de signalement et de remplacement.
  • Error : l'appel d'API a échoué, car la requête ne répondait pas à l'une des exigences décrites dans la section précédente.

Vous pouvez également afficher l'étiquette de nœud node.gke.io/report-and-replace-operation pour afficher l'ID d'opération Compute Engine afin de surveiller l'état de l'opération.

Vous pouvez afficher ces deux étiquettes de nœud à l'aide de la commande suivante :

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,node.gke.io/report-and-replace-operation

Si une erreur d'API se produit, GKE définit l'étiquette de nœud cloud.google.com/report-and-replace-status sur Error. En cas d'échec de l'opération, GKE définit l'étiquette sur OperationFAILED. Dans les deux cas, GKE supprime l'étiquette de nœud cloud.google.com/fault-behavior. De plus, dans GKE version 1.35.6-gke.1256000 ou ultérieure, ou 1.36.0-gke.4060000 ou ultérieure, GKE applique un rejet cloud.google.com/report-and-replace-failed:NoSchedule au nœud. Ce rejet empêche la planification de nouveaux pods sur le nœud, ce qui garantit que les charges de travail ne sont pas placées sur un nœud dont l'hôte est potentiellement défectueux. Pour en savoir plus, consultez Gérer les échecs de signalement et de remplacement.

Pour savoir comment suivre l'état détaillé d'une opération de signalement d'hôte défectueux, consultez Examiner les opérations de signalement d'hôte défectueux.

Gérer les échecs de signalement et de remplacement

Lorsqu'une opération de signalement et de remplacement échoue, GKE applique le rejet cloud.google.com/report-and-replace-failed:NoSchedule au nœud concerné. Ce rejet permet de maintenir le nœud marqué comme non ordonnançable afin qu'aucune nouvelle charge de travail ne soit planifiée sur celui-ci, car l'hôte sous-jacent peut toujours être défaillant.

Rechercher le rejet d'échec

Pour vérifier si un nœud présente le rejet d'échec de signalement et de remplacement, exécutez la commande suivante :

  kubectl describe node NODE_NAME | grep "report-and-replace-failed"

Récupération après un échec de signalement et de remplacement

Pour récupérer un échec de signalement et de remplacement, effectuez l'une des opérations suivantes :

  • Réessayez l'opération en appliquant à nouveau l'étiquette cloud.google.com/fault-behavior au nœud. Si la nouvelle tentative réussit, GKE supprime automatiquement le rejet cloud.google.com/report-and-replace-failed:NoSchedule :

      kubectl label node NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON

  • Supprimez manuellement le rejet si vous avez déterminé que le nœud est opérationnel ou si vous souhaitez le remettre en service :

      kubectl taint nodes NODE_NAME cloud.google.com/report-and-replace-failed:NoSchedule-

Étapes suivantes