En esta página, se muestra cómo resolver problemas relacionados con las TPU en Google Kubernetes Engine (GKE).
Cuota insuficiente para satisfacer la solicitud TPU
Un error similar a Insufficient quota to satisfy the request
indica que tu proyecto de Google Cloud tiene una cuota insuficiente para satisfacer la solicitud.
Para resolver este problema, verifica el límite de cuota y el uso actual de tu proyecto. Si es necesario, solicita un aumento de tu cuota de TPU.
Comprueba el límite de cuota y el uso actual
Para verificar el límite de cuota de TPU y el uso actual, sigue estos pasos.
Dirígete a la página Cuotas en la consola de Google Cloud.
En la casilla
Filtro, haz lo siguiente:Selecciona la propiedad Servicio, ingresa API de Compute Engine y presiona Intro.
Selecciona la propiedad Cuota y, luego, ingresa el nombre de la cuota según la versión de TPU y el tipo de máquina. Por ejemplo, si planeas crear nodos TPU v5e a pedido cuyo tipo de máquina comience con
ct5lp-
, ingresaTPU v5 Lite PodSlice chips
.Versión de TPU El tipo de máquina comienza con Nombre de la cuota para instancias bajo demanda Nombre de la cuota para instancias de VMs Spot1 Nombre de la cuota para las instancias reservadas2 TPU v4 ct4p-
TPU v4 PodSlice chips
Preemptible TPU v4 PodSlice chips
Committed TPU v4 PodSlice chips
TPU v5e ct5l-
TPU v5 Lite Device chips
Preemptible TPU v5 Lite Device chips
Committed TPU v5 Lite Device chips
TPU v5e ct5lp-
TPU v5 Lite PodSlice chips
Preemptible TPU v5 Lite PodSlice chips
Committed TPU v5 Lite PodSlice chips
De forma opcional, si deseas aplicar filtros más avanzados para limitar los resultados, selecciona la propiedad Dimensiones (p. ej., ubicaciones), agrega el nombre de la región en la que deseas crear TPU en GKE y presiona Intro. Por ejemplo, ingresa
region:us-west4
si planeas crear nodos TPU v5e en la zonaus-west4-a
.
Si ninguna cuota coincide con el filtro que ingresaste, no se le otorgó ninguna de las cuotas especificadas al proyecto y debes solicitar un aumento de la cuota de TPU.
Solicita un aumento de cuota de TPU
Si necesitas cuota adicional para crear nodos TPU en GKE, comunícate con tu representante de cuenta de Google Cloud a fin de solicitar un aumento en tu cuota de TPU. Las TPU suministradas con GKE usan la cuota asignada de la API de Compute Engine. La cuota solicitada para la cuota de la API de Cloud TPU no se aplica cuando se usan TPU en GKE.
Error cuando se habilita el aprovisionamiento automático de nodos en grupos de nodos TPU
El siguiente error ocurre cuando habilitas el aprovisionamiento automático de nodos en un clúster de GKE que no admite TPU.
El mensaje de error es similar al siguiente:
ERROR: (gcloud.container.clusters.create) ResponseError: code=400,
message=Invalid resource: tpu-v4-podslice.
Para resolver este problema, actualiza tu clúster de GKE a la versión 1.27.6 o posterior.
GKE no aprovisiona de forma automática los nodos TPU
En las siguientes secciones, se describen los casos en los que GKE no aprovisiona de forma automática los nodos TPU y cómo solucionarlos.
Limita la configuración incorrecta
GKE no aprovisiona de forma automática los nodos TPU si los límites de aprovisionamiento automático que definiste para un clúster son demasiado bajos. Puedes observar los siguientes errores en esas situaciones:
Si existe un grupo de nodos TPU, pero GKE no puede escalar verticalmente los nodos debido a incumplimiento de los límites de los recursos, puedes ver el siguiente mensaje de error cuando ejecutas el comando
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
Además, en esta situación, puedes ver mensajes de advertencia similares a los siguientes en la consola de Google Cloud:
"Your cluster has one or more unschedulable Pods"
Cuando GKE intenta aprovisionar de forma automática un grupo de nodos TPU que exceda los límites de recursos, los registros de visibilidad del escalador automático de clústeres mostrarán el siguiente mensaje de error:
messageId: "no.scale.up.nap.pod.zonal.resources.exceeded"
Además, en esta situación, puedes ver mensajes de advertencia similares a los siguientes en la consola de 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"
Para resolver estos problemas, aumenta la cantidad máxima de chips TPU, núcleos de CPU y memoria en el clúster.
Para completar estos pasos, sigue estos pasos:
- Calcula los requisitos de recursos para un recuento y un tipo de máquina de TPU determinados. Ten en cuenta que debes agregar recursos para grupos de nodos que no sean de TPU, como las cargas de trabajo del sistema.
Obtén una descripción de la TPU, la CPU y la memoria disponibles para un tipo de máquina y una zona específicos. Usa la CLI de gcloud:
gcloud compute machine-types describe MACHINE_TYPE \ --zone COMPUTE_ZONE
Reemplaza lo siguiente:
MACHINE_TYPE
: El tipo de máquina que se buscará.COMPUTE_ZONE
: Es el nombre de la zona de procesamiento.
El resultado incluye una línea descriptiva similar a la siguiente:
description: 240 vCPUs, 407 GB RAM, 4 Google TPUs ```
Calcula la cantidad total de CPU y memoria mediante la multiplicación de estas cantidades por la cantidad requerida de nodos. Por ejemplo, el tipo de máquina
ct4p-hightpu-4t
usa 240 núcleos de CPU y 407 GB de RAM con 4 chips TPU. Si suponemos que necesitas 20 chips TPU, que corresponden a cinco nodos, debes definir los siguientes valores:--max-accelerator=type=tpu-v4-podslice,count=20
CPU = 1200
(240 veces 5)memory = 2035
(407 veces 5)
Debes definir los límites con algún margen para alojar nodos que no sean TPU, como las cargas de trabajo del sistema.
Actualiza los límites del clúster:
gcloud container clusters update CLUSTER_NAME \ --max-accelerator type=TPU_ACCELERATOR \ count=MAXIMUM_ACCELERATOR \ --max-cpu=MAXIMUM_CPU \ --max-memory=MAXIMUM_MEMORY
Reemplaza lo siguiente:
CLUSTER_NAME
: Es el nombre del clúster.TPU_ACCELERATOR
: Es el nombre del acelerador de TPU.MAXIMUM_ACCELERATOR
: Es la cantidad máxima de chips TPU en el clúster.MAXIMUM_CPU
: Es la cantidad máxima de núcleos en el clúster.MAXIMUM_MEMORY
: Es la cantidad máxima de gigabytes de memoria en el clúster.
Configuración incorrecta de la carga de trabajo
Este error se produce debido a una configuración incorrecta de la carga de trabajo. Las siguientes son algunas de las causas más comunes de este error:
- Las etiquetas
cloud.google.com/gke-tpu-accelerator
ycloud.google.com/gke-tpu-topology
son incorrectas o faltan en la especificación del pod. GKE no aprovisionará grupos de nodos TPU y el aprovisionamiento automático de nodos no podrá escalar verticalmente el clúster. - La especificación del pod no especifica
google.com/tpu
en sus requisitos de recursos.
Para solucionar este problema, realiza una de las siguientes acciones:
- Verifica que no haya etiquetas no compatibles en el selector de nodos de la carga de trabajo.
Por ejemplo, un selector de nodos para la etiqueta
cloud.google.com/gke-nodepool
evitará que GKE cree grupos de nodos adicionales para tus Pods. - Asegúrate de que las especificaciones de la plantilla de pod, en las que se ejecuta tu carga de trabajo de TPU, incluyan los siguientes valores:
- Etiquetas
cloud.google.com/gke-tpu-accelerator
ycloud.google.com/gke-tpu-topology
en sunodeSelector
. google.com/tpu
en su solicitud.
- Etiquetas
Para aprender a implementar cargas de trabajo de TPU en GKE, consulta Ejecuta una carga de trabajo que muestre la cantidad de chips TPU disponibles en un grupo de nodos TPU.
Programación de errores cuando se implementan Pods que consumen TPU en GKE
El siguiente problema se produce cuando GKE no puede programar los pods que solicitan TPU en los nodos TPU. Por ejemplo, esto puede suceder si algunos Pods que no son de TPU ya estaban programados en los nodos TPU.
El mensaje de error, emitido como un evento FailedScheduling
en el Pod, es similar al siguiente:
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
Para solucionar este problema, haz lo siguiente:
Verifica que tengas al menos un grupo de nodos de CPU en tu clúster para que los pods críticos del sistema puedan ejecutarse en los nodos que no son TPU. Para obtener más información, consulta Implementa un Pod en un grupo de nodos específico.
No se pudo inicializar la TPU
El siguiente problema se produce cuando GKE no puede aprovisionar cargas de trabajo de TPU nuevas debido a la falta de permisos para acceder a los dispositivos de TPU.
El mensaje de error es similar al siguiente:
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
Para resolver este problema, asegúrate de ejecutar tu contenedor de TPU en modo privilegiado o aumentar ulimit
dentro de tu contenedor.
Programación de interbloqueo
La programación de dos o más trabajos puede fallar en un interbloqueo. Por ejemplo, en una situación en la que ocurre todo lo siguiente:
- Tienes dos trabajos (trabajo A y trabajo B) con reglas de afinidad de Pods.
GKE programa las porciones de TPU para ambos trabajos con una topología de TPU de
v4-32
. - Tienes dos porciones de TPU
v4-32
en el clúster. - Tu clúster tiene una capacidad suficiente para programar ambos trabajos y, en teoría, cada trabajo se puede programar con rapidez en cada porción de TPU.
- El programador de Kubernetes programa un pod del trabajo A en una porción y, luego, programa un pod del trabajo B en la misma porción.
En este caso, dadas las reglas de afinidad de Pods para el trabajo A, el programador intenta programar todos los Pods restantes para el trabajo A y el trabajo B, en una sola porción de TPU cada uno. Como resultado, GKE no podrá programar por completo el trabajo A o el trabajo B. Por lo tanto, el estado de ambos trabajos permanecerá pendiente.
Para resolver este problema, usa la antiafinidad del Pod con cloud.google.com/gke-nodepool
como con topologyKey
, como se muestra en el siguiente ejemplo:
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
Permiso denegado durante la creación del clúster en us-central2
Si intentas crear un clúster en us-central2
(la única región en la que TPU v4 está disponible), es posible que veas un mensaje de error similar al siguiente:
ERROR: (gcloud.container.clusters.create) ResponseError: code=403,
message=Permission denied on 'locations/us-central2' (or it may not exist).
Este error se debe a que la región us-central2
es privada.
Para resolver este problema, presenta un caso de asistencia o comunícate con el equipo de cuentas para solicitar que us-central2
se muestre en tu proyecto de Google Cloud.
Falta la subred durante la creación del clúster de GKE
Si intentas crear un clúster en us-central2
(la única región en la que TPU v4 está disponible), es posible que veas un mensaje de error similar al siguiente:
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>.
Se requiere una subred en tu red de VPC para proporcionar conectividad a los nodos de GKE. Sin embargo, en ciertas regiones, como us-central2
, es posible que no se cree una subred predeterminada, incluso cuando usas la red de VPC predeterminada en modo automático (para crear subredes).
Para resolver este problema, asegúrate de haber creado una subred personalizada en la región antes de crear el clúster de GKE. Esta subred no debe superponerse con otras subredes creadas en otras regiones de la misma red de VPC.