Résoudre les problèmes liés aux TPU dans GKE

Cette page explique comment résoudre les problèmes liés aux TPU dans Google Kubernetes Engine (GKE).

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Quota insuffisant pour répondre à la demande de TPU

Une erreur semblable à Insufficient quota to satisfy the request indique que votre projet Google Cloud ne dispose pas d'un quota suffisant pour répondre à la requête.

Pour résoudre ce problème, vérifiez la limite de quota et l'utilisation actuelle de votre projet. Si nécessaire, demandez une augmentation de votre quota de TPU.

Vérifier la limite de quota et l'utilisation actuelle

Pour vérifier la limite et l'utilisation actuelle de votre quota d'API Compute Engine pour les TPU, procédez comme suit :

  1. Accédez à la page Quotas de la console Google Cloud.

    Accéder à la section "Quotas"

  2. Dans la zone  Filtre, procédez comme suit :

    1. Sélectionnez la propriété Service, saisissez API Compute Engine, puis appuyez sur Entrée.

    2. Sélectionnez la propriété Type et choisissez Quota.

    3. Sélectionnez la propriété Dimensions (par exemple, emplacements) et saisissez region: suivi du nom de la région dans laquelle vous prévoyez de créer des TPU dans GKE. Par exemple, saisissez region:us-west4 si vous envisagez de créer des nœuds TPU dans la zone us-west4-a. Le quota de TPU est régional. Par conséquent, toutes les zones d'une même région consomment le même quota de TPU.

Si aucun quota ne correspond au filtre que vous avez saisi, le projet ne dispose d'aucun quota pour la région souhaitée et vous devez demander une augmentation de quota TPU.

Erreur lors de l'activation du provisionnement automatique des nœuds dans des pools de nœuds TPU

L'erreur suivante se produit lorsque vous activez le provisionnement automatique des nœuds dans un cluster GKE non compatible avec les TPU.

Le message d'erreur ressemble à ceci :

ERROR: (gcloud.container.clusters.create) ResponseError: code=400,
  message=Invalid resource: tpu-v4-podslice.

Pour résoudre ce problème, mettez à niveau votre cluster GKE vers la version 1.27.6 ou ultérieure.

GKE ne provisionne pas automatiquement les nœuds TPU

Les sections suivantes décrivent les cas où GKE ne provisionne pas automatiquement les nœuds TPU, et comment les résoudre.

Limiter les erreurs de configuration

GKE ne provisionne pas automatiquement les nœuds TPU si les limites de provisionnement automatique que vous avez définies pour un cluster sont trop faibles. Vous pouvez rencontrer les erreurs suivantes dans de tels scénarios :

  • Si un pool de nœuds TPU existe, mais que GKE ne peut pas effectuer un scaling à la hausse des nœuds en raison des limites de ressources, le message d'erreur suivant peut s'afficher lors de l'exécution de la commande kubectl get events :

    11s Normal NotTriggerScaleUp pod/tpu-workload-65b69f6c95-ccxwz pod didn't
trigger scale-up: 1 node(s) didn't match Pod's node affinity/selector, 1 max
cluster cpu, memory limit reached

    En outre, dans ce scénario, des messages d'avertissement semblables à ceux-ci peuvent s'afficher dans la console Google Cloud :

    "Your cluster has one or more unschedulable Pods"

  • Lorsque GKE tente de provisionner automatiquement un pool de nœuds TPU dépassant les limites de ressources, les journaux de visibilité de l'autoscaler de cluster affichent le message d'erreur suivant :

    messageId: "no.scale.up.nap.pod.zonal.resources.exceeded"

    En outre, dans ce scénario, des messages d'avertissement semblables à ceux-ci peuvent s'afficher dans la console Google Cloud :

    "Can't scale up because node auto-provisioning can't provision a node pool for
the Pod if it would exceed resource limits"

Pour résoudre ces problèmes, augmentez le nombre maximal de puces TPU, de cœurs de processeur et de mémoire dans le cluster.

Pour effectuer cette procédure, procédez comme suit :

  1. Calculez les besoins en ressources d'un type de machine TPU et d'un nombre donné. Notez que vous devez ajouter des ressources pour les pools de nœuds non TPU, tels que les charges de travail système.

  2. Obtenez une description du TPU, du processeur et de la mémoire disponibles pour un type de machine et une zone spécifiques. Utiliser la CLI gcloud

    gcloud compute machine-types describe MACHINE_TYPE \
    --zone COMPUTE_ZONE

    Remplacez les éléments suivants :

    • MACHINE_TYPE : type de machine à rechercher.
    • COMPUTE_ZONE : nom de la zone de calcul.

    Le résultat inclut une ligne de description semblable à celle-ci :

      description: 240 vCPUs, 407 GB RAM, 4 Google TPUs
  ```

  3. Calculez le nombre total de processeurs et de mémoire en multipliant ces quantités par le nombre de nœuds requis. Par exemple, le type de machine ct4p-hightpu-4t utilise 240 cœurs de processeur et 407 Go de RAM avec 4 puces TPU. En supposant que vous ayez besoin de 20 puces TPU, correspondant à cinq nœuds, vous devez définir les valeurs suivantes :

    • --max-accelerator=type=tpu-v4-podslice,count=20
    • CPU = 1200 (240 x 5)
    • memory = 2035 (407 x 5)

    Vous devez définir des limites avec une certaine marge pour les nœuds non TPU, tels que les charges de travail système.

  4. Mettez à jour les limites du cluster :

    gcloud container clusters update CLUSTER_NAME \
    --max-accelerator type=TPU_ACCELERATOR \
    count=MAXIMUM_ACCELERATOR \
    --max-cpu=MAXIMUM_CPU \
    --max-memory=MAXIMUM_MEMORY

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster.
    • TPU_ACCELERATOR : nom de l'accélérateur TPU.
    • MAXIMUM_ACCELERATOR : nombre maximal de puces TPU dans le cluster.
    • MAXIMUM_CPU : nombre maximal de cœurs dans le cluster.
    • MAXIMUM_MEMORY : quantité maximale de mémoire dans le cluster, en gigaoctets.

Mauvaise configuration de la charge de travail

Cette erreur se produit en raison d'une mauvaise configuration de la charge de travail. Voici quelques-unes des causes d'erreur les plus courantes :

  • Les libellés cloud.google.com/gke-tpu-accelerator et cloud.google.com/gke-tpu-topology sont incorrects ou manquants dans la spécification de pod. GKE ne provisionne pas de pools de nœuds TPU et le provisionnement automatique des nœuds ne peut pas effectuer un scaling à la hausse du cluster.
  • La spécification de pod ne spécifie pas google.com/tpu dans ses besoins en ressources.

Pour résoudre ce problème, effectuez l'une des opérations suivantes :

  1. Vérifiez qu'il n'existe aucun libellé non compatible dans le sélecteur de nœud de votre charge de travail. Par exemple, un sélecteur de nœuds pour le libellé cloud.google.com/gke-nodepool empêche GKE de créer des pools de nœuds supplémentaires pour vos pods.
  2. Assurez-vous que les spécifications du modèle de pod, dans lesquelles la charge de travail de votre TPU s'exécute, incluent les valeurs suivantes :
    • Les libellés cloud.google.com/gke-tpu-accelerator et cloud.google.com/gke-tpu-topology dans son nodeSelector.
    • google.com/tpu dans sa requête.

Pour savoir comment déployer des charges de travail TPU dans GKE, consultez la page Exécuter une charge de travail qui affiche le nombre de puces TPU disponibles dans un pool de nœuds TPU.

Erreurs de programmation lors du déploiement de pods consommant des TPU dans GKE

Le problème suivant se produit lorsque GKE ne peut pas planifier les pods demandant des TPU sur des nœuds TPU. Par exemple, cela peut se produire si certains pods non TPU ont déjà été programmés sur des nœuds TPU.

Le message d'erreur, émis en tant qu'événement FailedScheduling sur le pod, se présente comme suit :

Cannot schedule pods: Preemption is not helpful for scheduling.

Error message: 0/2 nodes are available: 2 node(s) had untolerated taint
{google.com/tpu: present}. preemption: 0/2 nodes are available: 2 Preemption is
not helpful for scheduling

Pour résoudre ce problème, procédez comme suit :

Vérifiez que votre cluster comporte au moins un pool de nœuds CPU afin que les pods critiques du système puissent s'exécuter dans les nœuds non TPU. Pour en savoir plus, consultez la page Déployer un pod sur un pool de nœuds spécifique.

Échec de l'initialisation du TPU

Le problème suivant se produit lorsque GKE ne peut pas provisionner de nouvelles charges de travail TPU en raison d'un manque d'autorisation d'accès aux appareils TPU.

Le message d'erreur ressemble à ceci :

TPU platform initialization failed: FAILED_PRECONDITION: Couldn't mmap: Resource
temporarily unavailable.; Unable to create Node RegisterInterface for node 0,
config: device_path: "/dev/accel0" mode: KERNEL debug_data_directory: ""
dump_anomalies_only: true crash_in_debug_dump: false allow_core_dump: true;
could not create driver instance

Pour résoudre ce problème, veillez à exécuter votre conteneur TPU en mode privilégié ou à augmenter ulimit dans votre conteneur.

Planifier un interblocage

La programmation d'au moins deux tâches peut résulter en un interblocage. Par exemple, dans le scénario où tous les événements suivants se produisent :

  • Vous avez deux jobs (job A et job B) avec des règles d'affinité de pod. GKE planifie les tranches de TPU des deux jobs avec une topologie TPU de v4-32.
  • Vous disposez de deux tranches de TPU v4-32 dans le cluster.
  • Votre cluster dispose d'une capacité suffisante pour planifier les deux jobs et, en théorie, chaque job peut être rapidement planifié sur chaque tranche de TPU.
  • Le programmeur Kubernetes planifie un pod du job A sur une tranche, puis en planifie un autre pour le job B sur la même tranche.

Dans ce cas, en fonction des règles d'affinité de pod du job A, le programmeur tente de planifier tous les pods restants des jobs A et B, chacun sur une seule tranche de TPU. Par conséquent, GKE ne peut pas planifier entièrement le job A ou le job B. L'état des deux jobs reste donc en attente.

Pour résoudre ce problème, utilisez l'anti-affinité de pod avec cloud.google.com/gke-nodepool comme topologyKey, comme indiqué dans l'exemple suivant :

apiVersion: batch/v1
kind: Job
metadata:
 name: pi
spec:
 parallelism: 2
 template:
   metadata:
     labels:
       job: pi
   spec:
     affinity:
       podAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: In
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: NotIn
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
           namespaceSelector:
             matchExpressions:
             - key: kubernetes.io/metadata.name
               operator: NotIn
               values:
               - kube-system
     containers:
     - name: pi
       image: perl:5.34.0
       command: ["sleep",  "60"]
     restartPolicy: Never
 backoffLimit: 4

Autorisation refusée lors de la création du cluster dans us-central2

Si vous essayez de créer un cluster dans la région us-central2 (seule région où les TPU v4 sont disponibles), vous pouvez rencontrer un message d'erreur semblable à celui-ci :

ERROR: (gcloud.container.clusters.create) ResponseError: code=403,
message=Permission denied on 'locations/us-central2' (or it may not exist).

Cette erreur est due au fait que la région us-central2 est une région privée.

Pour résoudre ce problème, envoyez une demande d'assistance ou contactez l'équipe chargée de votre compte pour demander à ce que la région us-central2 soit rendue visible au sein de votre projet Google Cloud.

Quota insuffisant lors de la création d'un pool de nœuds TPU dans la région us-central2

Si vous essayez de créer un pool de nœuds TPU dans us-central2 (seule région où les TPU v4 sont disponibles), vous devrez peut-être augmenter les quotas suivants liés à GKE lors de la création initiale des pools de nœuds TPU v4 :

  • SSD Persistent Disk (Go) dans la région us-central2 : le disque de démarrage de chaque nœud Kubernetes nécessite 100 Go par défaut. Par conséquent, ce quota doit être défini au moins aussi haut que le produit du nombre maximal de nœuds GKE que vous prévoyez de créer dans us-central2 et 100 Go (maximum_nodes X 100 GB).
  • Quota d'adresses IP en cours d'utilisation dans la région us-central2 : chaque nœud Kubernetes consomme une adresse IP. Par conséquent, ce quota doit être défini au moins autant que le nombre maximal de nœuds GKE que vous prévoyez de créer dans us-central2.

Sous-réseau manquant lors de la création du cluster GKE

Si vous essayez de créer un cluster dans la région us-central2 (seule région où les TPU v4 sont disponibles), vous pouvez rencontrer un message d'erreur semblable à celui-ci :

ERROR: (gcloud.container.clusters.create) ResponseError: code=404,
message=Not found: project <PROJECT> does not have an auto-mode subnetwork
for network "default" in region <REGION>.

Vous devez ajouter un sous-réseau dans votre réseau VPC pour fournir la connectivité à vos nœuds GKE. Toutefois, dans certaines régions telles que us-central2, un sous-réseau par défaut ne peut pas être créé, même lorsque vous utilisez le réseau VPC par défaut en mode automatique (pour la création de sous-réseau).

Pour résoudre ce problème, assurez-vous d'avoir créé un sous-réseau personnalisé dans la région avant de créer votre cluster GKE. Ce sous-réseau ne doit pas chevaucher d'autres sous-réseaux créés dans d'autres régions sur le même réseau VPC.

Étapes suivantes

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.