Soluciona problemas relacionados con ComputeClass personalizado

Autopilot estándar

En este documento, se te ayuda a solucionar problemas en los que las cargas de trabajo de GKE no se pueden programar en nodos definidos por una ComputeClass personalizada o cuando el escalador automático del clúster no aprovisiona los tipos de máquinas esperados.

Este documento está dirigido a los desarrolladores de aplicaciones y a los administradores y operadores de plataformas que usan ComputeClasses personalizadas para administrar la programación de cargas de trabajo y la creación automática de grupos de nodos en GKE. Para obtener más información sobre los roles comunes y las tareas de ejemplo a los que se hace referencia en el contenido de Google Cloud , consulta Roles y tareas comunes del usuario de GKE.

Nota: Este documento se aplica a los clústeres de Standard y Autopilot. Debido a que el acceso directo a los nodos, como SSH, no se admite en los clústeres de Autopilot, debes ajustar los pasos de solución de problemas para esos entornos.

Conceptos clave

Para ayudarte a solucionar problemas, asegúrate de conocer los siguientes componentes y mecanismos de GKE:

• ComputeClass personalizada: Es un recurso específico de GKE que te permite definir una lista priorizada de configuraciones de nodos para el ajuste de escala automático. Para obtener más información, consulta Acerca de las clases de procesamiento personalizadas.

• Escalador automático del clúster: Es el componente que agrega o quita nodos automáticamente en tu clúster según la demanda de la carga de trabajo. Para obtener más información, consulta Acerca del escalador automático de clústeres de GKE.

• Creación automática de grupos de nodos: El escalador automático de clúster de GKE crea y administra automáticamente grupos de nodos según los requisitos de la carga de trabajo. Para obtener más información, consulta Acerca de la creación automática de nodos de POO.

• Lógica de resguardo: Es el mecanismo por el que el escalador automático del clúster intenta aprovisionar primero los nodos que coinciden con tu regla de mayor prioridad. Para obtener más información, consulta Elige las prioridades de procesamiento de respaldo.

Soluciona problemas según los síntomas

En este documento, se organizan los pasos para solucionar problemas en secuencia, desde las verificaciones fundamentales hasta las configuraciones más avanzadas. Para obtener un diagnóstico más completo, te recomendamos que sigas estos pasos en orden. Como alternativa, si tienes problemas específicos, consulta los vínculos pertinentes en la siguiente tabla:

Síntoma	Pasos para solucionar problemas
El Pod que solicita una ComputeClass personalizada está atascado en el estado Pending	Realiza verificaciones de diagnóstico básicas Verifica las restricciones de programación de Pods Configuración del grupo de nodos (para clústeres estándar)
El escalador automático de clúster no crea nodos nuevos que coincidan con la clase de procesamiento personalizada	Verifica la configuración personalizada de ComputeClass Verifica la configuración de la creación automática del grupo de nodos
El escalador automático del clúster crea tipos de máquina predeterminados en lugar de tipos especializados	Analiza el comportamiento de respaldo del escalador automático
El resultado del comando kubectl describe computeclass muestra un estado no saludable	Verifica la configuración personalizada de ComputeClass
Las cargas de trabajo no migran a nodos de mayor prioridad	Verifica el estado general del escalador automático de clústeres
Las cargas de trabajo de las VMs con GPU o Spot tienen problemas de programación	Verifica las restricciones de programación de Pods Verifica la configuración de las VMs con GPU o Spot Analiza el comportamiento de respaldo del escalador automático

Problemas fuera del alcance

En este documento, no se abordan los siguientes problemas:

• Problemas generales de redes de GKE, como la conectividad de Pod a Pod o el balanceo de cargas de servicios
• Problemas relacionados con el Horizontal Pod Autoscaler (HPA) o el escalador automático vertical de Pods (VPA)
• Problemas no relacionados con el mecanismo personalizado de ComputeClass, como errores a nivel de la aplicación o problemas de PersistentVolume que no están relacionados con las restricciones de programación
• Problemas de cuota o disponibilidad de recursos que no están directamente relacionados con la lógica de resguardo de ComputeClass

Cómo identificar variables de marcador de posición

Para personalizar los comandos de este documento, ingresa tus valores específicos en la columna Variable. Los valores editados se sincronizan automáticamente en todos los bloques de código y comandos.

Variable	Descripción
PROJECT_ID	Es el ID de tu proyecto de Google Cloud .
LOCATION	Región o zona de Compute Engine en la que se encuentra el clúster.
CLUSTER_NAME	Es el nombre de tu clúster.
NODE_POOL_NAME	Nombre del grupo de nodos que se inspeccionará (si corresponde a clústeres estándar).
CUSTOM_COMPUTECLASS_NAME	Nombre de la ComputeClass personalizada que solicitó el Pod.
NAMESPACE	Es el espacio de nombres del Pod que no se puede programar.
POD_NAME	Es el nombre del Pod que no se puede programar.

Antes de comenzar

Para obtener los permisos que necesitas para realizar las tareas de este documento, pídele a tu administrador que te otorgue los siguientes roles de IAM en tu proyecto de Google Cloud :

• Para acceder a los clústeres de GKE, usa el Lector de clústeres de Kubernetes Engine (roles/container.viewer).
• Para ver los registros, usa el Visor de registros (roles/logging.viewer).
• Para administrar clústeres de GKE: Administrador de Kubernetes Engine (roles/container.admin).

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios a través de roles personalizados o cualquier otro rol predefinido.

Para configurar kubectl para que se comunique con el clúster, ejecuta el siguiente comando:

  gcloud container clusters get-credentials CLUSTER_NAME
      --location LOCATION
      --project PROJECT_ID

Realiza verificaciones de diagnóstico básicas

Verifica que los componentes principales estén configurados correctamente y que el clúster admita ComputeClasses personalizadas.

Verifica el estado y el selector del Pod

Confirma que el Pod esté en el estado Pending y solicite correctamente la ComputeClass personalizada.

1. Enumera los Pods en el estado Pending:

   kubectl get pods --all-namespaces -o wide | grep Pending
   

2. Inspecciona la especificación del Pod para ver el campo nodeSelector:

   kubectl get pod POD_NAME
       -n NAMESPACE
       -o jsonpath='{.spec.nodeSelector}'
   

Evalúa el resultado

• El resultado muestra la etiqueta: El campo nodeSelector está configurado correctamente con la etiqueta cloud.google.com/compute-class.
• El resultado no muestra la etiqueta:
  • Interpretación: Es posible que falte un campo nodeSelector o que sea incorrecto para la etiqueta cloud.google.com/compute-class en la configuración de implementación de tu carga de trabajo.
  • Solución: Modifica el archivo YAML de tu carga de trabajo, como una Deployment o un trabajo, para incluir el campo nodeSelector en la sección spec.template.spec.

Verifica la compatibilidad de la versión del clúster

Las ComputeClasses personalizadas requieren la versión 1.30.3-gke.1451000 de GKE o una posterior. Verifica que tu clúster ejecute una versión que admita ComputeClasses personalizadas.

Verifica la versión de tu clúster:

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(currentMasterVersion)"

Evalúa el resultado

• Versión 1.30.3-gke.1451000 o posterior: La versión de tu clúster admite ComputeClasses personalizadas.
• Versión anterior a 1.30.3-gke.1451000:
  • Interpretación: Tu clúster no se actualizó a una versión que admite ComputeClasses personalizadas.
  • Resolución: Debes actualizar tu clúster para usar ComputeClasses personalizadas.

Verifica la configuración personalizada de ComputeClass

Los errores de configuración en el recurso ComputeClass personalizado pueden impedir que se programen los Pods o que GKE aprovisione los nodos correctamente.

Verifica el estado y el bienestar de ComputeClass

Verifica que GKE informe que la ComputeClass personalizada está en buen estado.

1. Enumera todos los recursos ComputeClass:

   kubectl get computeclass
   

2. Describe el recurso ComputeClass específico:

   kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME
   

Evalúa el resultado

• El estado muestra True: La ComputeClass personalizada está en buen estado. A continuación, se muestra un ejemplo de una ComputeClass personalizada en buen estado:

  Status:
    Conditions:
      Last Transition Time:  2024-01-19T17:18:48Z
      Message:               CCC is healthy.
      Reason:                Health
      Status:                True
      Type:                  Health
  

• El estado muestra False:

  • Interpretación: La ComputeClass personalizada no está en buen estado. Revisa los campos Message y Reason en el resultado para identificar el problema.
  • Resolución: Realiza la acción que corresponde al campo Reason en el resultado:
    • NodePoolNotExist: Asegúrate de que exista el grupo de nodos al que se hace referencia o actualiza ComputeClass para que haga referencia a un grupo de nodos existente.
    • ReservationUnusable: Verifica la configuración y el uso de la reserva a la que se hace referencia.
    • Invalid machine type: Actualiza ComputeClass para usar un tipo de máquina que sea compatible con la región o zona del clúster.

Valida la política de unsatisfiable

El campo whenUnsatisfiable determina el comportamiento cuando no se pueden cumplir reglas de prioridad.

Revisa la política:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Inspecciona el campo spec.whenUnsatisfiable en el resultado. Este campo puede tener uno de los siguientes valores:

• DoNotScaleUp: Los Pods permanecen en el estado Pending si no se pueden crear nodos preferidos.
• ScaleUpAnyway: Es posible que los pods se ejecuten en tipos de nodos predeterminados (como la serie E2) si los nodos preferidos no están disponibles.

Evalúa el resultado

El efecto de la política whenUnsatisfiable depende de su valor:

• Si el valor es DoNotScaleUp:
  • Interpretación: Este es el comportamiento esperado cuando no se puede satisfacer ninguna regla de prioridad, posiblemente debido a la indisponibilidad de recursos o a límites de cuota. Si los Pods deben esperar hardware específico, este valor es correcto.
  • Resolución: Si ejecutar la carga de trabajo es más importante que ejecutarla en hardware específico, cambia la política a ScaleUpAnyway.
• Si el valor es ScaleUpAnyway:
  • Interpretación: Este es el comportamiento esperado. GKE recurre a los tipos de nodos predeterminados porque los nodos preferidos no están disponibles.
  • Resolución: Si los Pods no deben ejecutarse en tipos de nodos predeterminados, cambia la política a DoNotScaleUp.
• Comportamiento predeterminado: Si no especificaste un valor para el campo whenUnsatisfiable y usas una versión de GKE anterior a la 1.33, la política se establece de forma predeterminada en ScaleUpAnyway.

En el siguiente ejemplo, se muestra cómo actualizar la política editando el campo whenUnsatisfiable en tu manifiesto de ComputeClass:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: CUSTOM_COMPUTECLASS_NAME
spec:
  # ... other fields
  whenUnsatisfiable: DoNotScaleUp # or ScaleUpAnyway

Verifica las restricciones de programación de Pods

Asegúrate de que la especificación del Pod sea compatible con los atributos de los nodos aprovisionados por la ComputeClass personalizada.

Verifica las solicitudes de recursos de Pod

Verifica si las solicitudes de CPU, memoria y GPU del Pod se pueden satisfacer con al menos uno de los tipos de máquinas definidos en el campo priorities de ComputeClass personalizado.

1. Obtén las solicitudes de recursos de Pods:

   kubectl get pod POD_NAME
       -n NAMESPACE
       -o jsonpath='{.spec.containers[*].resources.requests}'
   

   Inspecciona el resultado para ver las solicitudes de cpu, memory y GPU, como nvidia.com/gpu.

2. Compara estas solicitudes con los tipos de máquinas definidos en el campo priorities de la ComputeClass personalizada:

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME
       -o jsonpath='{.spec.priorities}'
   

   Inspecciona el resultado para ver los campos machineType o machineFamily. Para cada tipo de máquina en la ComputeClass personalizada, verifica sus especificaciones en la documentación de tipos de máquinas y comprueba si sus recursos asignables son mayores que las solicitudes del Pod.

Evalúa el resultado

• Recursos compatibles: Las solicitudes de recursos del Pod son menores o iguales a los recursos asignables de al menos un tipo de máquina en ComputeClass.

• Los recursos superan la capacidad:

  • Interpretación: No se puede programar el Pod porque ningún tipo de máquina en ComputeClass proporciona suficiente CPU, memoria o GPU. Esto también puede ocurrir si el campo nodePoolAutoCreation está configurado como true y la solicitud de memoria del Pod supera los límites de los grupos de nodos creados automáticamente.
  • Resolución: Ajusta las solicitudes de recursos del Pod o los tipos de máquinas de ComputeClass personalizados:
    • Reduce las solicitudes de recursos del Pod: Si las solicitudes de recursos son altas, disminuye los valores de cpu, memory o gpu en el archivo YAML de la carga de trabajo.
    • Cambia a tipos de máquina más grandes: Si las solicitudes del Pod están justificadas, modifica el campo spec.priorities en tu manifiesto de ComputeClass personalizado para incluir opciones de machineType o machineFamily más grandes que puedan satisfacer las demandas del Pod. Por ejemplo:

  spec:
    priorities:
    - machineType: n2d-highmem-96 # A larger machine type
      spot: true
    # ... other priorities
  

Verifica si hay taints y tolerancias en conflicto

Los nodos creados para una ComputeClass personalizada tienen el efecto secundario cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule. GKE agrega esta tolerancia a los Pods de forma automática.

Sin embargo, el hardware especializado, como las GPU, tiene contaminaciones adicionales, como la contaminación nvidia.com/gpu=present:NoSchedule. Si tu ComputeClass usa nodos con hardware especializado, los Pods deben tener una tolerancia para estos taint para programarse en esos nodos.

Verifica el campo tolerations del Pod:

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.tolerations}'

Evalúa el resultado

• Tolerancias correctas: Las exclusiones y las tolerancias están configuradas correctamente.

• Tolerancias faltantes:

  • Interpretación: Las tolerancias faltantes impiden que el Pod se programe en nodos con taints de hardware especializados. Por ejemplo, si ComputeClass usa nodos de GPU, es posible que el Pod no tenga la tolerancia nvidia.com/gpu=present:NoSchedule. Para conocer los requisitos específicos de la GPU, consulta Verifica la configuración de la GPU.

  • Resolución: En el campo tolerations de la especificación del Pod, agrega las tolerancias necesarias para que coincidan con los taints de los nodos definidos por ComputeClass. Por ejemplo, para los nodos de GPU, agrega una tolerancia para el taint nvidia.com/gpu=present:NoSchedule de la siguiente manera:

    spec:
    template:
    spec:
    tolerations:
    - key: "nvidia.com/gpu"
    operator: "Exists"
    effect: "NoSchedule"
    # ... other tolerations and Pod spec
    

Configuración del grupo de nodos (clústeres estándar)

En los clústeres de GKE Standard, los grupos de nodos creados de forma manual deben tener etiquetas y taints para funcionar con una ComputeClass personalizada.

Verifica las etiquetas y los taints del grupo de nodos

1. Identifica los grupos de nodos en tu ComputeClass personalizada. Si la ComputeClass personalizada usa el campo nodePools, ten en cuenta los nombres de los grupos de nodos que se indican:

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

2. Para cada grupo de nodos que identificaste, verifica su configuración:

   gcloud container node-pools describe NODE_POOL_NAME
       --cluster CLUSTER_NAME
       --location LOCATION
       --format="yaml(config.labels, config.taints)"
   

Evalúa el resultado

• El grupo de nodos está configurado correctamente: El grupo de nodos tiene la etiqueta cloud.google.com/compute-class: CUSTOM_COMPUTECLASS_NAME y el taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule.

• El grupo de nodos está mal configurado:

  • Interpretación: El grupo de nodos no se configuró con la etiqueta y el taint necesarios para asociarlo con la ComputeClass personalizada.

  • Solución: Actualiza el grupo de nodos para agregar la etiqueta y el taint:

    1. Agrega o actualiza la etiqueta del nodo:

       gcloud container node-pools update NODE_POOL_NAME \
           --cluster=CLUSTER_NAME --location=LOCATION \
           --node-labels=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME
       

    2. Agrega o actualiza la contaminación del nodo:

       gcloud container node-pools update NODE_POOL_NAME \
           --cluster=CLUSTER_NAME --location=LOCATION \
           --node-taints=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule
       

Verifica la configuración de la creación automática del grupo de nodos

Tanto para los clústeres de Autopilot como para los de Standard con nodePoolAutoCreation establecido en true, se debe configurar correctamente la creación automática de grupos de nodos.

Verifica que la creación automática del grupo de nodos esté habilitada

1. Verifica si el campo nodePoolAutoCreation.enabled en la ComputeClass personalizada está configurado como true:

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

2. Verifica si la creación automática de grupos de nodos está habilitada en el clúster:

   gcloud container clusters describe CLUSTER_NAME
       --location LOCATION
       --format="value(autoscaling.enableNodeAutoprovisioning)"
   

Si alguna de las opciones está inhabilitada, la creación automática de grupos de nodos no creará grupos de nodos nuevos para tu ComputeClass personalizada.

Evalúa el resultado

• Creación automática de grupos de nodos habilitada: En ComputeClass, el campo nodePoolAutoCreation.enabled está establecido en true y el aprovisionamiento automático de nodos está habilitado a nivel del clúster.

• Creación automática de grupos de nodos inhabilitada:

  • Interpretación: La creación automática de grupos de nodos está inhabilitada si el valor del campo nodePoolAutoCreation.enabled es false o falta en ComputeClass, o si el aprovisionamiento automático de nodos a nivel del clúster está inhabilitado.

  • Resolución: Habilita la creación automática de grupos de nodos:

    1. Edita el archivo YAML de ComputeClass personalizado para incluir nodePoolAutoCreation: enabled: true:

       spec:
         # ... priorities
         nodePoolAutoCreation:
           enabled: true
       

    2. Habilita la creación automática de grupos de nodos a nivel del clúster y configura los límites de recursos:

       gcloud container clusters update CLUSTER_NAME --location LOCATION \
         --enable-autoprovisioning \
         --autoprovisioning-min-cpu=MIN_CPU \
         --autoprovisioning-max-cpu=MAX_CPU \
         --autoprovisioning-min-memory=MIN_MEMORY \
         --autoprovisioning-max-memory=MAX_MEMORY
       

Verifica los límites de recursos para la creación automática de grupos de nodos

La creación automática de grupos de nodos tiene límites en todo el clúster para la CPU y la memoria. Si el uso actual del clúster más los recursos de un nodo nuevo superan estos límites, la creación automática del grupo de nodos no aprovisionará nodos nuevos.

1. Sigue estos pasos para ver los límites de recursos:

   gcloud container clusters describe CLUSTER_NAME
       --location LOCATION
   --format="value(autoscaling.resourceLimits)"
   

   El resultado enumera los campos resourceType, minimum y maximum para la CPU y la memoria (en GB).

2. Revisa los tipos de máquinas en las prioridades de tu ComputeClass personalizada. Consulta las especificaciones de CPU y memoria en la documentación sobre los tipos de máquinas.

3. Determina la capacidad total actual de CPU y memoria de todos los nodos del clúster. La suma de la capacidad actual más los recursos de un posible nodo nuevo no debe exceder el límite máximo para la creación automática de grupos de nodos.

Evalúa el resultado

• Capacidad suficiente: El clúster tiene suficiente capacidad de CPU y memoria dentro de los límites de recursos para que la creación automática del grupo de nodos aprovisione un nodo nuevo.

• Se superaron los límites:

  • Interpretación: La creación automática de grupos de nodos no puede aprovisionar nodos nuevos porque el clúster alcanzó los límites de CPU o memoria, o bien los límites se establecieron demasiado bajos para los tipos de máquinas en ComputeClass.

  • Solución: Aumenta los límites de recursos para la creación automática de grupos de nodos:

    1. Determina los nuevos límites máximos que tengan en cuenta el uso actual y el crecimiento futuro, incluidos los tipos de máquinas más grandes en la ComputeClass personalizada.

    2. Actualiza los límites de recursos para la creación automática de grupos de nodos. Puedes configurar varios recursos en un solo comando:

       gcloud container clusters update CLUSTER_NAME --location LOCATION \
         --set-nap-resource-limits resourceType=cpu,maximum=NEW_MAX_CPU \
         --set-nap-resource-limits resourceType=memory,maximum=NEW_MAX_GB
       

Analiza el comportamiento de respaldo del escalador automático

En esta sección, se te ayuda a investigar factores externos para comprender por qué el escalador automático de clústeres podría omitir las opciones preferidas y usar alternativas, o no lograr escalar verticalmente.

Las ComputeClasses personalizadas usan lógica de resguardo priorizada. Si un Pod no se programa en nodos que coinciden con la regla de mayor prioridad, a menudo se debe a restricciones como la falta de disponibilidad de recursos o las cuotas del proyecto. Cuando GKE no puede aprovisionar nodos que coincidan con una regla de prioridad específica, por ejemplo, debido a un error ZONE_RESOURCE_POOL_EXHAUSTED o QUOTA_EXCEEDED de Compute Engine, el escalador automático de clústeres intenta de inmediato la siguiente regla en la lista priorities. No hay un período de espera antes de que GKE recurra a la siguiente prioridad, excepto cuando se usan TPU o el modelo de aprovisionamiento de Flex Start, que admiten una demora configurable.

Verifica si hay recursos no disponibles

Verifica si los recursos no están disponibles en la zona especificada. Para ello, consulta los registros del escalador automático del clúster o los errores del grupo de instancias administrado (MIG) de Compute Engine.

Opción 1: Verifica los eventos de visibilidad del escalador automático de clústeres

En la Google Cloud consola, ve a Cloud Logging > Explorador de registros y ejecuta la siguiente consulta para encontrar eventos del escalador automático que podrían indicar que no hay recursos disponibles:

resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.resource.exhausted"

Opción 2: Verifica los errores de MIG

Puedes verificar si hay errores de MIG en la consola de Google Cloud o con una consulta de Cloud Logging.

• Usa la consola de Google Cloud :

  1. En la consola de Google Cloud , ve a Compute Engine > Grupos de instancias.
  2. Busca el MIG correspondiente al grupo de nodos que no se puede escalar verticalmente.
  3. Haz clic en el nombre del MIG y ve a la pestaña Errores. Busca mensajes que indiquen que se agotaron los recursos.

• Usa la consulta de Cloud Logging:

  1. En la consola de Google Cloud , ve a Cloud Logging > Explorador de registros.
  2. Ejecuta la siguiente consulta para verificar si hay errores de agotamiento de recursos en el MIG:

  resource.type="gce_instance"
  log_id("cloudaudit.googleapis.com/activity")
  protoPayload.status.message:("ZONE_RESOURCE_POOL_EXHAUSTED" OR "does not have enough resources available to fulfill the request" OR "resource pool exhausted" OR "does not exist in zone")
  

Evalúa el resultado

• Los recursos están disponibles: Si los registros no muestran los mensajes ZONE_RESOURCE_POOL_EXHAUSTED, es poco probable que la falta de disponibilidad de recursos sea la causa del error de aumento de escala.

• Los recursos no están disponibles:

  • Interpretación: El aprovisionamiento de nodos falla debido a una alta demanda temporal de un tipo de máquina específico (en especial, VMs Spot o GPUs) en esa zona, o bien porque un Pod está restringido por la afinidad de PersistentVolume a una zona que experimenta falta de disponibilidad de recursos.

  • Solución: La falta de disponibilidad de recursos es transitoria, pero puedes mejorar la resiliencia agregando flexibilidad a tu configuración:

    • Diversifica los tipos de máquinas: Asegúrate de que el campo spec.priorities en el objeto ComputeClass personalizado contenga varios tipos de máquinas o familias como alternativas:

      spec:
        priorities:
        - machineFamily: c3  # Highest priority
        - machineFamily: n2d # Fallback option
        - machineFamily: e2  # Lowest priority
      

    • Usa clústeres regionales: Si el clúster es zonal, es vulnerable a la falta de disponibilidad de recursos en esa única zona. El uso de clústeres regionales permite que el escalador automático del clúster intente aprovisionar nodos en otras zonas de la región en las que podría haber capacidad disponible.

    • Usa reservas de Compute Engine: Para las cargas de trabajo críticas que no pueden tolerar demoras, crea reservas de Compute Engine para garantizar la capacidad de tipos de máquinas específicos.

Verifica las cuotas del proyecto

Confirma que tu proyecto tenga la cuota suficiente para los recursos, como las CPU, las GPU y las direcciones IP que requieren los nodos nuevos.

1. Revisa los registros del escalador automático en busca de errores de cuota. Usa Cloud Logging para buscar mensajes de error relacionados con la cuota en los eventos de visibilidad del escalador automático:

   resource.type="k8s_cluster"
   resource.labels.location="LOCATION"
   resource.labels.cluster_name="CLUSTER_NAME"
   log_id("container.googleapis.com/cluster-autoscaler-visibility")
   jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.quota.exceeded"
   

   Como alternativa, usa la siguiente consulta de Cloud Logging para verificar los registros de errores relacionados con la cuota del MIG:

   resource.type="gce_instance"
   protoPayload.methodName:"compute.instances.insert"
   protoPayload.status.message:"QUOTA_EXCEEDED"
   severity=ERROR
   

2. Revisa las cuotas en la consola de Google Cloud :

   1. En la consola de Google Cloud , ve a IAM y administración > Cuotas.
   2. Filtra el servicio de la API de Compute Engine.
   3. Verifica el uso de las métricas pertinentes, como las CPU, las GPU (de todos los tipos) y las direcciones IP en uso para la región en la que se encuentra tu clúster de GKE. Verifica que el uso actual no haya alcanzado el límite.

Evalúa el resultado

• Cuota por debajo de los límites: Si el uso de la cuota está por debajo de los límites y no se encuentran errores de QUOTA_EXCEEDED en los registros, los límites de la cuota no bloquearán el aumento de escala.
• Se superó la cuota:
  • Interpretación: El aprovisionamiento de nodos falla debido a una cuota insuficiente para recursos como CPU, GPU, direcciones IP o MIG.
  • Resolución: Si tu proyecto alcanzó un límite de cuota, solicita un aumento de cuota.

Configuración avanzada

Las configuraciones, como las GPU, las VMs Spot y las reservas de Compute Engine, tienen sus propios requisitos específicos y posibles puntos de falla que se deben verificar.

Verifica la configuración de la GPU

En el caso de las ComputeClasses personalizadas que aprovisionan nodos de GPU, valida la configuración de la GPU en la ComputeClass personalizada y asegúrate de que el Pod tenga la tolerancia obligatoria nvidia.com/gpu.

1. Verifica el YAML de ComputeClass personalizado para ver si hay un bloque gpu dentro de una regla de prioridad:

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

   El bloque gpu debe especificar un campo type y un campo count, por ejemplo:

   priorities:
   - machineType: a2-highgpu-1g
     gpu:
       type: nvidia-tesla-a100
       count: 1
   

2. Inspecciona el Pod para verificar la tolerancia de la GPU. Cualquier Pod que deba programarse en un nodo de GPU debe tener la tolerancia nvidia.com/gpu, incluso si el Pod no solicita una GPU.

   kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations}'
   

   Verifica la tolerancia en el campo spec.tolerations.

Evalúa el resultado

• La GPU está configurada correctamente: Si ComputeClass define GPU type y count, y los Pods incluyen la tolerancia nvidia.com/gpu, la configuración de la GPU es correcta. A continuación, se muestra la tolerancia requerida:

  tolerations:
  - key: "nvidia.com/gpu"
    operator: "Exists"
    effect: "NoSchedule"
  

• La GPU está mal configurada:

  • Interpretación: Es posible que al Pod le falte la tolerancia nvidia.com/gpu requerida, que ComputeClass no esté en buen estado debido a discrepancias en los campos de la GPU o que la versión de GKE no controle la configuración de la GPU correctamente.
  • Resolución: Realiza una de las siguientes acciones:
    • Modifica el archivo YAML de la carga de trabajo para incluir la tolerancia obligatoria de la GPU y vuelve a aplicar el archivo YAML.
    • Actualiza el clúster de GKE. Si la ComputeClass personalizada no está en buen estado y el problema está relacionado con los campos de GPU, verifica si hay problemas conocidos y actualiza a una versión de GKE con parche, por ejemplo, 1.31.8-gke.1045000 o posterior.

Verifica la configuración de las VMs Spot

Si usas VMs Spot, asegúrate de que el parámetro de configuración spot: true esté en las reglas de prioridad correctas de tu manifiesto de ComputeClass. Además, asegúrate de comprender la lógica de precios del escalador automático de clústeres.

Inspecciona el manifiesto de ComputeClass:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

En el resultado, busca spot: true en el campo spec.priorities, por ejemplo:

priorities:
- machineFamily: n2d
  spot: true

El escalador automático del clúster puede usar los datos de precios de us-central1 como referencia cuando compara el costo de los diferentes tipos de VMs Spot, lo que puede generar opciones aparentemente no óptimas en otras regiones. Este es un comportamiento conocido.

Evalúa el resultado

• Las VMs Spot están configuradas correctamente: Si se especifica el campo spot: true y el escalador automático del clúster aprovisiona VMs Spot, la configuración funciona según lo previsto.

• Las VMs Spot no se pueden programar:

  • Interpretación: Es posible que los Pods que requieren VMs Spot no se puedan programar en VMs Spot debido a la falta de recursos en la zona de destino o porque el escalador automático del clúster podría elegir un tipo de VM diferente según su modelo de precios de us-central1.

  • Resolución:

    • Si sospechas que un recurso no está disponible, consulta Cómo verificar si un recurso no está disponible.

    • Para controlar la selección de VMs Spot, enumera explícitamente las entradas machineType en tu campo priorities, de la más barata a la más costosa para tu región. Este enfoque te brinda control directo sobre el orden de resguardo. Por ejemplo:

      spec:
        priorities:
        - machineType: t2d-standard-48 # Cheapest in this region
          spot: true
        - machineType: n2d-standard-48 # Fallback Spot option
          spot: true
        - machineType: n2d-standard-48 # On-demand fallback
          spot: false
      

Estado general del escalador automático del clúster

En esta sección, se te ayuda a verificar si hay problemas que podrían no estar directamente relacionados con la configuración personalizada de ComputeClass, pero que podrían afectar su funcionamiento.

Verifica si hay operaciones simultáneas

Verifica que no haya otras operaciones de clúster o grupo de nodos en curso de forma simultánea. Por lo general, GKE solo permite una operación a la vez, lo que puede bloquear el ajuste de escala automático.

Enumera las operaciones en curso que no se encuentran en estado DONE:

gcloud container operations list \
    --location=LOCATION \
    --filter='targetLink~"/clusters/CLUSTER_NAME" AND status!=DONE'

Si el comando devuelve alguna operación, es posible que esté en curso una acción como una actualización del clúster, la creación de un grupo de nodos o alguna otra modificación. Es posible que se bloqueen los eventos de ajuste de escala automático hasta que se complete esta operación.

Evalúa el resultado

• Sin operaciones simultáneas: Si el comando list devuelve una lista vacía, el escalador automático del clúster no está bloqueado por ninguna operación.

• Se encontraron operaciones simultáneas:

  • Interpretación: Si el comando enumera operaciones con el estado RUNNING o PENDING, es posible que haya una operación simultánea en curso, como una actualización del clúster o una modificación del grupo de nodos, que esté bloqueando el ajuste de escala automático.

  • Resolución: Espera a que se complete la operación en curso. Puedes supervisar el estado con un ID de operación de la siguiente manera:

    gcloud container operations wait OPERATION_ID --location LOCATION
    

    Reemplaza OPERATION_ID por el ID del resultado del comando list. Una vez que se complete la operación de bloqueo, el escalador automático del clúster debería reanudar su funcionamiento normal.

Revisa la migración activa

Si observas que las cargas de trabajo permanecen en nodos de menor prioridad cuando hay nodos de mayor prioridad disponibles, verifica si la migración activa está habilitada. Si el campo activeMigration.optimizeRulePriority está establecido en false o se omite en tu ComputeClass, GKE no moverá automáticamente las cargas de trabajo a nodos de mayor prioridad cuando estén disponibles.

1. Para verificar las tolerancias del Pod, revisa el campo spec.tolerations. Si el Pod tiene tolerancias que coinciden con las exclusiones en varios grupos de nodos de diferentes prioridades, es posible que el programador lo coloque en un nodo de menor prioridad si está disponible primero.

   kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations[*]}{"\n"}'
   

2. Para verificar si la migración activa está habilitada, inspecciona el manifiesto de ComputeClass en busca del campo spec.activeMigration.optimizeRulePriority.

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

Evalúa el resultado

• Migración activa habilitada: Si el campo activeMigration.optimizeRulePriority es true, GKE intenta trasladar las cargas de trabajo a nodos de mayor prioridad cuando están disponibles.

• Migración activa inhabilitada o ineficaz:

  • Interpretación: Si el campo activeMigration.optimizeRulePriority es false o se omite, o si las tolerancias del Pod son demasiado amplias, las cargas de trabajo permanecen en nodos de menor prioridad cuando hay nodos de mayor prioridad disponibles. Este enfoque permite que las cargas de trabajo se programen en los nodos de menor prioridad que estén disponibles primero.

  • Resolución: Si deseas que las cargas de trabajo se muevan a nodos de mayor prioridad, realiza una de las siguientes acciones:

    • Usa restricciones de programación más específicas, como nodeAffinity, para preferir grupos de nodos de mayor prioridad.

    • Edita el manifiesto de ComputeClass para establecer activeMigration.optimizeRulePriority: true y aplicar el archivo YAML:

      spec:
        activeMigration:
          optimizeRulePriority: true
      

Obtén asistencia

• Si no encuentras una solución a tu problema en la documentación, consulta Obtener asistencia para obtener más ayuda, como asesoramiento en los siguientes temas:

  • Comunicarse con Atención al cliente de Cloud para abrir un caso de asistencia.
  • Hacer preguntas en StackOverflow para obtener asistencia de la comunidad y usar la etiqueta google-kubernetes-engine para buscar problemas similares. También puedes unirte al canal de Slack #kubernetes-engine para obtener más Asistencia de la comunidad.
  • Abrir problemas o solicitudes de funciones con la herramienta de seguimiento de errores pública

¿Qué sigue?

• Aplica ComputeClasses a los Pods de forma predeterminada
• Configura la separación de cargas de trabajo en GKE
• Soluciona problemas de aumento de escala del escalador automático de clústeres