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
  • Signaler 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 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 et exclusions de maintenance GKE. Bien que la règle de maintenance de l'hôte de la plupart des instances de calcul soit 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 y sont exécutés. Si les pods sont déployés dans le cadre d'une charge de travail plus importante, comme un Job ou un Deployment, 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 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.

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 vous a envoyé une notification concernant un événement de maintenance planifié, vous pouvez démarrer manuellement la maintenance à un moment qui correspond à votre emploi du temps. 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 de 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é 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 à venir

Vous pouvez indiquer à GKE de ne planifier les pods que sur les 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 pour lesquels une maintenance est prévue après une certaine date

Vous pouvez indiquer à GKE de ne planifier les pods que sur les nœuds pour lesquels une maintenance est prévue 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 perturbations des instances de calcul sous-jacentes et 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 la version disponible 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.

Les canaux de publication vous donnent accès à davantage de fonctionnalités, y compris à des champ d'application d'exclusion de maintenance supplémentaires. Nous recommandons le champ d'application "Pas de mises à niveau mineures ni de nœuds" pour les charges de travail d'IA.

Signaler des hôtes défectueux via GKE

Cette section explique comment signaler un hôte défectueux sur lequel des instances de calcul sont provisionnées à l'aide du modèle de provisionnement lié à une réservation via GKE. 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), contactez plutôt votre équipe chargée du compte.

Un hôte est un 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 des hôtes défectueux en appliquant un libellé 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 spécifique, 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. Attend que l'instance de calcul soit rétablie 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 rétablit 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 le libellé fault-behavior du nœud.

Le nœud sera alors à nouveau prêt à traiter 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 1.32.3-gke.1057001 ou ultérieure de GKE.
  • 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 dans 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'é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 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 :

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

    Remplacez les éléments suivants :

    • NODE_NAME : nom du nœud défectueux.
    • FAULT_REASON : motif de l'erreur approprié, à l'aide d'une ou de 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, si aucune erreur XID n'est détectée dans les journaux et si aucun des autres schémas d'échec habituels, comme la corruption silencieuse des données, n'est détecté.
      • SDC : utilisez cette valeur en cas de corruption silencieuse des données, si vous constatez une corruption des données, mais pas de plantage du système. Cette corruption de 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 mémoire, des problèmes de noyau ou d'autres défauts. Le plus souvent, ce terme fait référence à des 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.
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 opérationnel de la 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éfectueux pour les deux modes opérationnels 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 signalement d'hôtes défectueux Aucune limite de débit ne s'applique. Les appels à l'API peuvent être soumis à une limite de fréquence.
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 "Toutes capacités", les événements suivants se produisent :

  1. Évacuer les pods : une fois le libellé appliqué au nœud défectueux, GKE rejette le nœud pour empêcher la planification de nouveaux pods. GKE commence également à évincer progressivement les pods en cours d'exécution sur le nœud. GKE respecte les budgets d'interruptions de pods (PDB) et le champ spec.terminationGracePeriodSeconds de vos manifestes de pods. 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 signale et répare automatiquement l'hôte défectueux en appelant l'API Compute Engine. Cela 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 le réparer.

  3. Redémarrez l'instance : une fois l'opération de réparation de l'hôte terminée (généralement entre 3 et 14 jours), l'une des situations suivantes 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é.
    • Dans le cas contraire, 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 à TERMINATED. 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 au moment du redémarrage. 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. Évacuer les pods : une fois le libellé appliqué au nœud défectueux, GKE rejette le nœud pour empêcher la planification de nouveaux pods. GKE commence également à évincer progressivement les pods en cours d'exécution sur le nœud. GKE respecte les budgets d'interruptions de pods (PDB) et le champ spec.terminationGracePeriodSeconds de vos manifestes de pods. 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 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. Il faut généralement 10 à 12 minutes pour signaler l'hôte défectueux, puis 3 à 14 jours, voire plus parfois, pour le réparer.

  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 signalé dans votre capacité réservée. Si Compute Engine trouve un hôte sain (s'il remplace l'hôte défectueux ou 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 s'effectue ensuite de l'une des manières suivantes :

    • Si l'instance est à l'état REPAIRING et que des ressources sont disponibles avant ou au moment de la réparation, 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 à la fin de la réparation, l'état de l'instance reste à TERMINATED ou passe à TERMINATED. 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 au moment du redémarrage. 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 GKE à l'aide du libellé de nœud cloud.google.com/report-and-replace-status sur votre nœud GKE, qui présente l'une des valeurs suivantes :

  • PodsEvicted : GKE a terminé d'évincer les 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.
  • Error : l'appel d'API a échoué, pour des raisons incluant l'une des exigences décrites dans la section précédente.

Vous pouvez également afficher le libellé du nœud cloud.google.com/report-and-replace-operation pour consulter l'ID d'opération Compute Engine et 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,cloud.google.com/report-and-replace-operation

En cas d'erreur d'API, GKE définit le libellé de nœud cloud.google.com/report-and-replace-status=ERROR. GKE efface les rejets de nœud et supprime le libellé de nœud cloud.google.com/fault-behavior.

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

Pour réessayer l'opération en cas d'erreurs temporaires telles que des limites de débit, réappliquez le libellé cloud.google.com/fault-behavior au nœud.

Étapes suivantes