Gérer les interruptions des nœuds GKE pour les GPU et les TPU

Au cours du cycle de vie d'un cluster GKE de longue durée, des perturbations périodiques des charges de travail se produisent en raison d'événements de maintenance automatique émis parGoogle Cloud pour les ressources Compute Engine sous-jacentes à l'infrastructure GKE. Cette page vous aide à comprendre ce que signifie l'interruption de nœud dans GKE, à surveiller les notifications de maintenance et à minimiser l'impact des interruptions sur vos nœuds GKE avec des GPU et des TPU associés.

Ce document s'adresse aux administrateurs et opérateurs de plate-forme qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Que signifie "perturbation de nœud" dans GKE ?

Vos clusters GKE gèrent le cycle de vie des nœuds GKE. Ces nœuds sont provisionnés sur des VM Compute Engine, qui subissent régulièrement des événements hôtes pour diverses raisons, par exemple:

  • Mises à jour et maintenance matérielles ou logicielles Les événements de maintenance automatique sont émis par Google Cloud.
  • les défaillances matérielles ;
  • Mises à niveau des VM Compute Engine. Ces mises à niveau sont différentes des mises à niveau du nœud GKE ou de la version du pool de nœuds.

Les événements hôtes sont émis pour l'infrastructure sous-jacente Google Cloud et contournent les règles et les exclusions de maintenance de GKE. Au cours du cycle de vie d'un cluster GKE de longue durée, les nœuds peuvent subir des perturbations périodiques des charges de travail d'entraînement ou de diffusion. Lorsque ces perturbations affectent vos nœuds GKE qui exécutent des charges de travail d'IA/de ML, GKE doit redémarrer à la fois les charges de travail en cours d'exécution et le nœud sous-jacent.

Pourquoi les GPU et les TPU nécessitent-ils une gestion des interruptions ?

La plupart des VM Compute Engine, à quelques exceptions près, ont une stratégie de maintenance de l'hôte définie sur migration à chaud, ce qui signifie que les charges de travail en cours d'exécution ne sont généralement pas interrompues. Toutefois, certaines classes de VM ne sont pas compatibles avec la migration à chaud, y compris les VM avec des GPU et des TPU associés. Lorsqu'un événement hôte se produit sur la VM d'une tranche de TPU, l'ensemble de la tranche est interrompu, puis reprogrammé, car tous les événements de maintenance sont coordonnés au niveau de la tranche. Par conséquent, si vous créez une tranche de TPU contenant des centaines de VM, toutes ces VM recevront le même calendrier d'événements de maintenance.

Lorsqu'un événement hôte se produit, GKE arrête le nœud et ses pods. Si les pods sont déployés dans le cadre d'une charge de travail plus importante, comme une tâche ou un déploiement, GKE redémarre les pods sur le nœud concerné.

C'est à vous ou aux frameworks que vous utilisez de gérer la configuration de la charge de travail pour réagir de manière appropriée aux événements de maintenance. Par exemple, vous pouvez enregistrer l'état de votre tâche d'entraînement d'IA pour réduire la perte de données.

Pour gérer les perturbations sur les charges de travail d'IA/ML, vous pouvez procéder comme suit:

Surveiller les notifications de maintenance

Compute Engine envoie des notifications lorsque des événements hôtes perturbateurs sont planifiés pour les nœuds et leurs VM sous-jacentes, et lorsque ces événements deviennent actifs. Les notifications incluent des informations sur l'heure de début prévue, le type d'événement et d'autres détails.

À partir de la version 1.31.1-gke.2008000 de GKE, vous pouvez surveiller les événements de maintenance à venir, y compris ceux décrits dans cette section.

Une maintenance est planifiée, mais n'est pas active

Avant qu'un événement de maintenance soit planifié pour une VM avec des GPU ou des TPU associés, Compute Engine envoie des notifications à toutes ses VM. Ces notifications indiquent le début de l'intervalle de maintenance. Lorsqu'une maintenance à venir est planifiée par la VM, mais qu'elle n'est pas active, GKE ajoute scheduled-maintenance-time au libellé du nœud.

Pour interroger ces notifications au niveau du nœud, exécutez la commande suivante:

kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
    -L cloud.google.com/scheduled-maintenance-time

Le résultat ressemble à ce qui suit :

NAME                         STATUS    SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name>  Ready     1733083200
<gke-accelerator-node-name>  Ready     1733083200
[...]

La colonne SCHEDULED-MAINTENANCE-TIME représente les secondes, qui sont affichées au format d'époque Unix.

Pour interroger ces notifications au niveau des métadonnées de nœud, vérifiez si les instances contiennent une notification d'événement de maintenance.

Début de la maintenance planifiée

Pour les familles de machines optimisées pour les accélérateurs compatibles avec la maintenance avancée, vous pouvez accéder au point de terminaison upcoming-maintenance, qui fournit des informations sur les événements de maintenance planifiés et démarrés.

Lorsque la maintenance planifiée commence, Compute Engine met à jour les métadonnées dans le répertoire http://metadata.google.internal/computeMetadata/v1/instance/attributes/. Compute Engine met à jour les libellés de métadonnées comme suit:

  • Définit maintenance-event sur TERMINATE_ON_HOST_MAINTENANCE.
  • Dans upcoming-maintenance, définit maintenance_status sur ONGOING.

GKE éliminera correctement les pods et arrêtera les charges de travail dans le délai maximal prédéfini limité de la période de notification de maintenance.

Réduire l'impact des perturbations

Pour minimiser l'impact de la perturbation du nœud, vous pouvez démarrer manuellement un événement de maintenance de l'hôte.

Si vous ne démarrez pas d'événement de maintenance, Compute Engine effectuera la maintenance planifiée régulièrement.

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

Lorsque Compute Engine envoie une notification concernant un événement de maintenance planifié, vous pouvez démarrer manuellement la maintenance à un moment qui correspond à votre calendrier opérationnel, par exemple pendant les périodes d'activité réduite.

Sur un nœud du pool de nœuds, définissez l'étiquette de nœud cloud.google.com/perform-maintenance sur true. Exemple :

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

GKE expulsera progressivement les pods et arrêtera les charges de travail avant le début de l'événement de maintenance avec l'action perform-maintenance. La durée entre l'application de l'étiquette et le début de la maintenance varie.

Configurer GKE pour qu'il arrête correctement vos charges de travail

Dans cette section, vous allez configurer GKE pour gérer le cycle de vie de votre application et réduire les perturbations sur votre charge de travail. Si vous ne configurez pas de délai de grâce, il est défini par défaut sur 30 secondes.

GKE s'efforce d'arrêter ces pods de manière élégante et d'exécuter l'action d'arrêt que vous définissez, par exemple, en enregistrant un état d'entraînement. GKE envoie un signal SIGTERM aux pods au début du délai de grâce. Si les pods ne s'arrêtent pas à la fin du délai de grâce, GKE envoie un signal SIGKILL de suivi à tous les processus toujours en cours d'exécution dans un conteneur du pod.

Pour configurer la période d'arrêt correct, définissez le délai de grâce de l'arrêt (en secondes) dans le champ spec.terminationGracePeriodSeconds de votre fichier manifeste de pod. Par exemple, pour obtenir une heure de notification de 10 minutes, définissez le champ spec.terminationGracePeriodSeconds dans le fichier manifeste de votre pod sur 600 secondes comme suit:

    spec:
      terminationGracePeriodSeconds: 600

Nous vous recommandons de définir un délai de grâce avant l'arrêt suffisamment long pour que les tâches en cours se terminent dans le délai de notification. Si votre charge de travail utilise un framework de ML tel que MaxText, Pax ou JAX avec Orbax, les charges de travail peuvent capturer le signal SIGTERM de fermeture et lancer un processus de création de points de contrôle. Pour en savoir plus, consultez Point de contrôle automatique TPU.

Processus de résiliation progressive

Lorsqu'un événement de perturbation commence, qu'il soit déclenché manuellement ou automatiquement par la VM, Compute Engine signale l'arrêt imminent de la machine en mettant à jour la clé de métadonnées maintenance-event. Dans les deux cas d'arrêt imminent du nœud, GKE démarre l'arrêt progressif.

Le workflow suivant montre comment GKE exécute l'arrêt optimal des nœuds en cas de fermeture imminente d'un nœud:

  1. Dans les 60 secondes, les événements suivants se produisent :
    1. Les composants système appliquent le libellé de nœud cloud.google.com/active-node-maintenance défini sur ONGOING pour indiquer que les charges de travail sont arrêtées.
    2. GKE applique le rejet du nœud pour empêcher la planification de nouveaux pods sur le nœud. Le rejet est associé à la clé cloud.google.com/impending-node-termination:NoSchedule. Nous vous recommandons de modifier vos charges de travail pour tolérer cette altération en raison de l'arrêt connu qui se produit.
  2. Le composant maintenance-handler commence à éjecter les pods en éjectant d'abord les pods de charge de travail, puis les pods système (par exemple, kube-system).
  3. GKE envoie un signal d'arrêt SIGTERM aux pods de charge de travail exécutés sur le nœud pour les alerter d'un arrêt imminent. Les pods peuvent utiliser cette alerte pour terminer les tâches en cours. GKE s'efforce d'arrêter ces pods de manière appropriée.
  4. Une fois l'éviction terminée, GKE met à jour la valeur du libellé cloud.google.com/active-node-maintenance sur terminating pour indiquer que le nœud est prêt à s'arrêter.

Ensuite, le nœud est arrêté et un nœud de remplacement est alloué. GKE efface les libellés et les rejets une fois le processus terminé. Pour augmenter la période d'arrêt de vos charges de travail à l'aide de GPU ou de TPU, suivez la procédure décrite dans la section Démarrer manuellement un événement de maintenance de l'hôte.

Surveiller la progression d'un arrêt progressif actif

Vous pouvez filtrer les journaux GKE en fonction des événements d'arrêt progressif suivants:

  • Lorsque la VM détecte une perturbation due à une imminente terminaison de nœud, comme un événement de maintenance de l'hôte Compute Engine, GKE définit cloud.google.com/active-node-maintenance sur ONGOING lorsque les charges de travail sont arrêtées et sur terminating lorsque les charges de travail sont terminées et que le nœud est prêt à s'arrêter.
  • Lorsque vous limitez la planification de nouvelles charges de travail, GKE applique le rejet cloud.google.com/impending-node-termination:NoSchedule.

Étapes suivantes