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

Cette page explique comment gérer les clusters Google Kubernetes Engine (GKE) optimisés pour l'IA des types de machines A4X Max, A4X, A4, A3 Ultra, A3 Mega et A3 High (8 GPU), y compris les événements courants suivants pertinents pour 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 de l'hôte pour les charges de travail d'IA

Les nœuds GKE s'exécutent sur des instances Compute Engine qui subissent périodiquement des événements d'hôte pouvant perturber les charges de travail d'IA. Comme les événements d'hôte se produisent sur l'infrastructure sous-jacente Google Cloud , ils contournent les intervalles et les exclusions de maintenance GKE . Bien que la plupart des instances de calcul aient leur règle de maintenance d'hôte définie sur la migration àchaud, ce qui minimise la perturbation 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'exécutent sur le nœud. 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 affecté.

Pour en savoir plus sur la gestion de la maintenance de l'hôte 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 libellés 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.

Avec ces libellés de nœud, vous pouvez effectuer les opérations suivantes :

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

Une fois que Compute Engine a envoyé 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. Poursuivez également la lecture de cette section pour en savoir plus sur les points suivants :

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

Vous pouvez utiliser les informations de maintenance fournies par les libellés de nœud GKE , ainsi que l'affinité et l'anti-affinité des nœuds , 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 à venir

Vous pouvez demander à GKE de ne planifier des pods que sur des nœuds qui n'ont pas d'événements de maintenance planifiés à venir, 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 planifiée après une certaine date

Vous pouvez demander à GKE de ne planifier des pods que sur des nœuds dont la maintenance est planifiée après une certaine date en fournissant l'heure 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 perturbations.

Au cours du cycle de vie d'un cluster GKE, les charges de travail d'IA doivent être préparées aux perturbations 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 le 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 "Pas de mises à niveau mineures ou de 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 dont les instances de calcul sont provisionnées à l'aide du modèle de provisionnement lié à la réservation. Si vous souhaitez signaler un hôte défectueux pour un nœud provisionné à l’aide du modèle de provisionnement à démarrage flexible (aperçu), alors contactez plutôt votre équipe chargée du compte.

Si vous constatez 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 du système d'exploitation 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 un serveur physique unique dans le centre de données exécutant une instance de calcul qui héberge votre nœud GKE. Vous pouvez signaler des hôtes défectueux en appliquant un libellé de nœud fault-behavior au nœud GKE affecté. Une fois que vous avez appliqué le libellé de nœud à un nœud GKE particulier, GKE effectue les étapes suivantes :

  1. Il évince de manière concertée les charges de travail du nœud.
  2. Il empêche de planifier de nouveaux pods sur le nœud.
  3. Il appelle l'API sur l'instance de calcul pour marquer l'hôte comme défectueux.
  4. Il attend que l'instance de calcul soit rétablie sur une machine hôte saine. Pour les réservations qui utilisent le mode de fonctionnement de réservation toute la capacité, Compute Engine rétablit l'instance de calcul sur le même nœud une fois l'opération de réparation terminée.
  5. Il supprime le rejet et le libellé fault-behavior du nœud.

Le nœud sera alors prêt à traiter à nouveau les 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 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 qui est 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 est renvoyé et la machine hôte n'est pas marquée comme défectueuse.
  • Vous pouvez être limité en termes de débit sur le nombre d'appels à cette API par réservation et par mois en fonction d'une évaluation de l'état de vos blocs. Les limites de débit ne s'appliquent pas si votre réservation utilise le mode de fonctionnement de réservation toute la capacité.

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 NODE_NAME.

  2. Signalez le nœud comme défectueux à l'aide de la commande suivante. Vous pouvez fournir une raison 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 la raison de la défaillance appropriée à l'aide d'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 des autres schémas d'échec habituels, tels que la corruption silencieuse des données, n'est détecté.
      • SDC : utilisez cette valeur pour la corruption silencieuse des données si vous constatez une corruption des 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 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 la défaillance observée. Cela peut inclure le code d'erreur XID, les symptômes ou les codes temporels. Cette description est transmise à Compute Engine pour faciliter les diagnostics de réparation et 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 votre équipe chargée du compte ou Cloud Customer Care pour fournir des informations sur la défaillance.
Une fois que vous avez signalé un hôte défectueux pour un nœud, le moment où le nœud redémarre varie en fonction du mode de fonctionnement de la réservation spécifié dans la réservation utilisée par le nœud. Pour vérifier le mode de fonctionnement de la réservation, affichez le reservationOperationalMode champ dans la réservation. Le tableau suivant récapitule le processus d'hôte défectueux pour les deux modes de fonctionnement de réservation disponibles : mode toute la capacité et 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
Limitation du débit de l'API de rapport d'hôte défectueux Aucune limite de débit ne s'applique. Les appels à l'API peuvent être limités en termes de débit.
Processus de rapport d'hôte défectueux

Lorsque vous signalez un hôte défectueux pour un nœud qui s'exécute en mode toute la capacité, les événements suivants se produisent :

  1. Évincer les pods : une fois le libellé appliqué au nœud défectueux, GKE rejette le nœud pour bloquer la planification de nouveaux pods. GKE commence également à évincer de manière concertée les pods en cours d'exécution sur le nœud. GKE respecte les budgets d'interruptions de pods (PDB) et le spec.terminationGracePeriodSeconds champ de vos manifestes de pods. Pour en savoir plus, consultez Configurer GKE pour arrêter vos charges de travail de manière concertée.
  2. Signaler et réparer l'hôte défectueux : GKE signale et répare automatiquement l'hôte défectueux en appelant l'API Compute Engine, ce qui entraîne une séquence d'opérations qui prend généralement 10 à 12 minutes pour signaler l'hôte défectueux, puis peut prendre 3 à 14 jours, voire plus parfois, pour réparer l'hôte.

  3. Redémarrer l'instance : une fois l'opération de réparation de l'hôte terminée (généralement 3 à 14 jours), l'un des événements suivants se produit :

    • Si l'instance est à l'état REPAIRING et que les ressources sont disponibles une fois la réparation terminée, Compute Engine redémarre automatiquement l'instance sur l'hôte réparé.
    • Sinon, si l'instance est à l'état TERMINATED ou si les ressources ne sont pas disponibles une fois la réparation terminée, l'état de l'instance reste à TERMINATED ou passe à cet état. Vous devez redémarrer manuellement l'instance lorsque vous souhaitez qu'elle s'exécute. Toutefois, le redémarrage de l'instance peut échouer si les ressources ne sont pas disponibles lorsque vous redémarrez l'instance. Par exemple, cela peut se produire si d'autres instances utilisent déjà l'hôte réparé.

Lorsque vous signalez un hôte défectueux pour un nœud qui s'exécute en mode géré, les événements suivants se produisent :

  1. Évincer les pods : une fois le libellé appliqué au nœud défectueux, GKE rejette le nœud pour bloquer la planification de nouveaux pods. GKE commence également à évincer de manière concertée les pods en cours d'exécution sur le nœud. GKE respecte les budgets d'interruptions de pods (PDB) et le spec.terminationGracePeriodSeconds champ de vos manifestes de pods. Pour en savoir plus, consultez Configurer GKE pour arrêter vos charges de travail de manière concertée.
  2. Signaler et commencer à réparer l'hôte défectueux : GKE signale et répare automatiquement l'hôte défectueux en appelant l'API Compute Engine, ce qui entraîne une séquence d'opérations qui prend généralement 10 à 12 minutes pour signaler l'hôte défectueux, puis 3 à 14 jours, voire plus parfois, pour réparer l'hôte.

  3. Migrer et redémarrer l'instance : une fois l'opération de réparation de l'hôte démarrée (généralement 10 à 12 minutes), Compute Engine tente de réserver un hôte supplémentaire pour remplacer l'hôte défectueux que vous avez signalé dans votre capacité réservée. Si Compute Engine trouve un hôte sain (s'il remplace l'hôte défectueux ou s'il trouve un hôte sain correspondant dans votre capacité réservée), il migre l'instance vers cet hôte. Le redémarrage de l'instance se produit ensuite de l'une des manières suivantes :

    • Si l'instance est à l'état REPAIRING et que les ressources sont disponibles avant ou lorsque la réparation est terminée, Compute Engine redémarre automatiquement l'instance sur un hôte sain.
    • Sinon, si l'instance est à l'état TERMINATED ou si les ressources ne sont pas disponibles avant ou lorsque la réparation est terminée, l'état de l'instance reste à TERMINATED ou passe à cet état. Vous devez redémarrer manuellement l'instance lorsque vous souhaitez qu'elle s'exécute. Toutefois, le redémarrage de l'instance peut échouer si les ressources ne sont pas disponibles lorsque vous redémarrez l'instance. Par exemple, cela peut se produire si d'autres instances utilisent déjà l'hôte réparé.

Surveiller la progression de l'opération

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

  • PodsEvicted: GKE a terminé d'évincer les pods du nœud affecté.
  • 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 d'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 le libellé 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 libellés 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 le libellé de nœud cloud.google.com/report-and-replace-status sur Error. Si une erreur d'opération se produit, GKE définit le libellé sur OperationFAILED. Dans les deux cas, GKE supprime le libellé 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 de planifier de nouveaux pods sur le nœud, ce qui garantit que les charges de travail ne sont pas placées sur un nœud avec un hôte 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 affecté. Ce rejet maintient le nœud en quarantaine afin qu'aucune nouvelle charge de travail ne soit planifiée sur celui-ci tant que l'hôte sous-jacent est potentiellement défectueux.

Rechercher le rejet d'échec

Pour vérifier si un nœud comporte 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érer après un échec de signalement et de remplacement

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

  • Effectuez une nouvelle tentative en appliquant à nouveau le libellé 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 sain ou si vous souhaitez le remettre en service :

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

Étape suivante