Soluciona problemas relacionados con ComputeClass personalizadas

Este documento te ayuda a solucionar problemas en los que las cargas de trabajo de GKE no se programan en los 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 y las tareas de ejemplo comunes a los que se hace referencia en el contenido de Google Cloud , consulta Roles y tareas comunes del usuario de GKE.

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 parámetros de configuración de nodos para el ajuste de escala automático. Para obtener más información, consulta Acerca de las ComputeClasses personalizadas.

  • Escalador automático de clústeres: 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 escalado 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 grupos de nodos de forma automática según los requisitos de la carga de trabajo. Para obtener más información, consulta Acerca de la creación automática de grupos de nodos.

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

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 realices 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
El escalador automático de clústeres no crea nodos nuevos que coincidan con la ComputeClass personalizada
El escalador automático de clúster crea tipos de máquinas predeterminados en lugar de tipos especializados Analiza el comportamiento de resguardo del escalador automático
El resultado del comando kubectl describe computeclass muestra un estado incorrecto Verifica los parámetros de configuración de ComputeClass personalizados
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 GPU o VM Spot tienen problemas de programación

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 de falta de disponibilidad de recursos que no están relacionados directamente con la lógica de resguardo de ComputeClass.

Identifica las 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 Es la 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 Es el nombre del grupo de nodos que se inspeccionará (si corresponde para los clústeres de Standard).
CUSTOM_COMPUTECLASS_NAME Es el nombre de la ComputeClass personalizada que solicita 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 visualizador 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, se requiere el rol de 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 que 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 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 un Deployment o un Job, 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 los nodos aprovisionados para la ComputeClass personalizada

Para verificar si hay nodos en el clúster que estén asociados con tu ComputeClass, enumera los nodos que coincidan con la etiqueta de ComputeClass:

kubectl get nodes -l cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME

Si el resultado es No resources found, no hay nodos asociados con la ComputeClass. Verifica que tus cargas de trabajo realmente hayan seleccionado esa ComputeClass y revisa tus eventos de ajuste de escala automático en busca de errores de aumento de escala.

Verifica los parámetros de configuración de la ComputeClass personalizada

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 de ComputeClass:

    kubectl get computeclass

  2. Describe el recurso ComputeClass específico:

    kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME

Evalúa el resultado

  • El estado de salud muestra True: la ComputeClass personalizada está en buen estado. A continuación, se muestra un ejemplo de un ComputeClass personalizado 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 de salud 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 corresponda al campo Reason en el resultado:
      • NodePoolNotExist: Asegúrate de que exista el grupo de nodos al que se hace referencia o actualiza la 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 la ComputeClass para usar un tipo de máquina que sea compatible con la región o zona del clúster.

Valida la política unsatisfiable

El campo whenUnsatisfiable determina el comportamiento cuando no se puede cumplir ninguna regla 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 falta de disponibilidad 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 un hardware específico, cambia la política a ScaleUpAnyway.
  • Si el valor es ScaleUpAnyway:
    • Interpretación: Este es el comportamiento esperado. GKE recurrirá a los tipos de nodos predeterminados porque los nodos preferidos no están disponibles.
    • Solució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 de tu Pod sea compatible con los atributos de los nodos aprovisionados por la ComputeClass personalizada.

Verifica las solicitudes de recursos de los Pods

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 la ComputeClass personalizada.

  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 de cpu, memory y las solicitudes de 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 suceder si el campo nodePoolAutoCreation está establecido en 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 la ComputeClass personalizada:
      • Reduce las solicitudes de recursos de Pods: 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áquinas más grandes: Si las solicitudes del Pod están justificadas, modifica el campo spec.priorities en el manifiesto de tu ComputeClass personalizada 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 reproche 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 taints adicionales, como el taint nvidia.com/gpu=present:NoSchedule. Si tu ComputeClass usa nodos con hardware especializado, los Pods deben tener una tolerancia para que estos reparos se programen 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 especializado. 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 las GPU, consulta Verifica la configuración de la GPU.

    • Solución: En el campo tolerations de la especificación del Pod, agrega las tolerancias necesarias para que coincidan con los taints en 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

Analiza la métrica de Pods pendientes del escalador automático de clústeres

Versiones de GKE aplicables: 1.37 y posteriores

Para comprender por qué los Pods que solicitan una ComputeClass específica están pendientes, usa la métrica kubernetes.io/autoscaler/cluster_pending_pods_per_ccc en Cloud Monitoring. Esta métrica te ayuda a identificar si el problema es la falta de nodos adecuados para la ComputeClass, un problema con el aprovisionamiento o algo inherente a la configuración del Pod. Esta métrica muestra la cantidad de Pods que procesa el escalador automático de clústeres, desglosada por ComputeClass, el motivo por el que están pendientes y si son Pods del sistema o del usuario.

Pasos para realizar consultas

Para consultar la métrica en la consola de Google Cloud , sigue estos pasos:

  1. En la consola de Google Cloud , ve a la página Explorador de métricas.
  2. Selecciona el Tipo de recurso: k8s_entity.
  3. Selecciona la métrica kubernetes.io/autoscaler/cluster_pending_pods_per_ccc.
  4. Agrega un filtro: entity_type = ComputeClass.
  5. Agrega un filtro para tu ComputeClass específica: entity_name = "COMPUTECLASS_NAME".
    • Para ver los Pods que no usan ninguna ComputeClass, filtra con entity_name = "".
  6. Agrupa por metric.labels.reason para ver los estados del escalador automático de estos Pods. También puedes agrupar los Pods con la etiqueta de clave metric.labels.type.

Ejemplo de consulta de PromQL

Para encontrar el estado de los Pods de usuario pendientes que solicitan la ComputeClass "COMPUTECLASS_NAME", usa la siguiente consulta de PromQL:

sum by (reason) (
  kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
    monitored_resource="k8s_entity",
    entity_type="ComputeClass",
    entity_name="COMPUTECLASS_NAME",
    type="user_pod"
  }
)

Motivos de las métricas

El resultado de la etiqueta de clave metric.labels.reason puede incluir lo siguiente:

  • unable_to_provision: El escalador automático del clúster está bloqueado. Los Pods en este estado para una ComputeClass no se pueden programar porque no se pueden crear nodos nuevos. Verifica los registros del escalador automático de clústeres en el plano de control para obtener detalles sobre el agotamiento de stock, las cuotas o los errores de configuración en la definición de ComputeClass. También revisa los eventos de visibilidad del escalador automático de clústeres.

  • provisioning_in_progress: Se activó un aumento de escala para los nodos que deberían cumplir con los requisitos de ComputeClass. Si los Pods permanecen aquí, es posible que haya demoras en la creación o preparación de los nodos.

  • unprocessed: El escalador automático de clústeres aún no evaluó estos Pods. Un número alto persistente puede indicar un retraso del escalador automático.

  • no_action_taken: El escalador automático de clústeres decidió no escalar para estos Pods. Este comportamiento puede deberse a restricciones de Pods que no pueden satisfacerse con los tipos de nodos de ComputeClass o con otros límites a nivel del clúster. Examina la especificación del Pod (kubectl describe pod) y los registros del escalador automático del clúster.

Analiza las fallas de aprovisionamiento de nodos

Versiones de GKE aplicables: 1.37 y posteriores

Para verificar el estado actual de una ComputeClass, consulta Verifica el estado de ComputeClass. Si observas que los Pods asociados a una ComputeClass están en estado unable_to_provision, el escalador automático de clústeres no aprovisiona nodos nuevos que coincidan con los requisitos de la ComputeClass. Puedes usar la métrica de Cloud Monitoring kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc para diagnosticar la causa raíz.

  1. En la consola de Google Cloud , ve a Monitoring y, luego, a Explorador de métricas.
  2. Selecciona el Tipo de recurso como k8s_entity.
  3. Selecciona la Métrica como kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc.
  4. Agrega un Filtro: resource.labels.entity_type = ComputeClass.
  5. Agrega un filtro para tu ComputeClass específica: entity_name = "CUSTOM_COMPUTECLASS_NAME".
    • Para ver los Pods que no usan ninguna ComputeClass, filtra con entity_name = "".
  6. En la sección Agrupar por, selecciona metric.labels.reason y resource.labels.entity_name.
  7. Elige un Agregador, como rate o delta.

Se muestra la tasa o el cambio en las fallas, desglosados por el motivo.

Interpreta los motivos de las fallas

El campo metric.labels.reason proporciona información sobre por qué falla la creación del nodo. Si identificas los motivos principales de las fallas, puedes tomar medidas correctivas.

Estas son algunas de las posibles razones:

Motivo Explicación Posibles medidas correctivas
QUOTA_EXCEEDED Se alcanzó un límite de cuota de Google Cloud (por ejemplo, CPU, discos o direcciones IP). Revisa las cuotas de tu proyecto. Solicitar un aumento de la cuota.
RESOURCE_POOL_EXHAUSTED No disponibilidad de Compute Engine; capacidad insuficiente para los recursos solicitados en la zona. Prueba con diferentes tipos de máquinas o zonas. Modifica ComputeClass para incluir tipos de máquinas o zonas de respaldo. Usar reservas
IP_SPACE_EXHAUSTED La subred del nodo se quedó sin direcciones IP disponibles. Expande el rango de direcciones IP principal de la subred.
PERMISSIONS_ERROR La cuenta de servicio de GKE no tiene los permisos de IAM necesarios para crear recursos (por ejemplo, instancias o discos). Otorga los roles necesarios a la cuenta de servicio de GKE.
VM_EXTERNAL_IP_ACCESS_POLICY_CONSTRAINT Una política de la organización (constraints/compute.vmExternalIpAccess) impide crear nodos con IPs externas según la configuración. Revisa y modifica la política de la organización o la configuración del nodo ComputeClass.
INVALID_RESERVATION La reserva de Compute Engine configurada no es válida, está mal configurada o no coincide con la solicitud del nodo. Verifica la configuración de la reserva y la definición de ComputeClass.
RESERVATION_NOT_FOUND No existe el nombre de reserva de Compute Engine especificado. Verifica el nombre de la reserva en ComputeClass.
RESERVATION_NOT_READY La reserva de destino aún no está activa o todavía se está aprovisionando. Espera a que la reserva se active.
RESERVATION_CAPACITY_EXCEEDED La reserva está llena y no puede alojar la solicitud. Aumenta el tamaño de la reserva o usa otros tipos de máquinas.
RESERVATION_INCOMPATIBLE La configuración del nodo (por ejemplo, el tipo de máquina o la zona) no coincide con las propiedades de la reserva. Alinea la especificación del nodo ComputeClass con las propiedades de la reserva.
AUTOMATIC_RESERVATIONS_NOT_AVAILABLE Se produjo un problema cuando se intentaba usar las reservas automáticas. Revisa los registros. Es posible que debas comunicarte con Atención al cliente de Cloud.
AUTOMATIC_RESERVATIONS_NO_CAPACITY Las reservas automáticas no tienen capacidad suficiente. Es posible que debas cambiar a reservas manuales o a diferentes tipos de máquinas.
UNSUPPORTED_TPU_CONFIGURATION La configuración de TPU solicitada no es válida o no se admite en la zona o el proyecto seleccionados. Consulta la documentación de TPU y la ComputeClass.
GkePersistentOperationError Se produjo un error persistente en el plano de control de GKE durante el proceso de creación del nodo. Comunícate con Atención al cliente de Cloud.
OTHER Es una explicación general para las fallas que no se ajustan a otras categorías. Para obtener más detalles, revisa los registros del escalador automático del clúster en el plano de control.

Configuración del grupo de nodos (clústeres de Standard)

En los clústeres de GKE Standard, los grupos de nodos creados de forma manual deben etiquetarse y aplicarse taints para que funcionen 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, toma nota de 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

  • Grupo de nodos 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.

  • Grupo de nodos mal configurado:

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

    • Resolució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 el taint de 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 creación automática de grupos de nodos

Para los clústeres de Autopilot y Standard con nodePoolAutoCreation configurado como true, la creación automática de grupos de nodos debe estar configurada de forma correcta.

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

  1. Verifica si el campo nodePoolAutoCreation.enabled de 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 ellas 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 se establece 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 se inhabilita 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 para la CPU y la memoria en todo el clúster. Si el uso actual del clúster más los recursos de un nodo nuevo superan estos límites, la creación automática de grupos de nodos no aprovisionará nodos nuevos.

  1. Para ver los límites de recursos, haz lo siguiente:

    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 sus especificaciones de CPU y memoria en la documentación sobre 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 nodo nuevo potencial no debe superar 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 de grupos de nodos aprovisione un nodo nuevo.

  • Límites superados:

    • 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 la ComputeClass.

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

      1. Determina 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 resguardo del escalador automático

Esta sección 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 las de resguardo, o no escalar verticalmente.

Las ComputeClasses personalizadas usan una lógica de resguardo priorizada. Si un Pod no se programa en nodos que coinciden con la regla de prioridad más alta, suele deberse 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 del clúster prueba de inmediato la siguiente regla de la lista priorities. No hay un período de espera antes de que GKE vuelva a la siguiente prioridad, excepto cuando se usan TPU o el modelo de aprovisionamiento de inicio flexible, que admiten una demora configurable.

Verifica la no disponibilidad de recursos

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

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

En la consola de Google Cloud , 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 del 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 de la falla de escalamiento vertical.

  • 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 porque un Pod está restringido por la afinidad de PersistentVolume con una zona que experimenta falta de disponibilidad de recursos.

    • Resolució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 o familias de máquinas 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 zona única. El uso de clústeres regionales permite que el escalador automático del clúster intente aprovisionar nodos en otras zonas dentro de la región en la que podría haber capacidad disponible.

      • Usa reservas de Compute Engine: Para las cargas de trabajo críticas que no pueden tolerar retrasos, 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 las cuotas 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 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 GPU en la ComputeClass personalizada y asegúrate de que el Pod tenga la tolerancia obligatoria nvidia.com/gpu.

  1. Verifica el YAML de la ComputeClass personalizada 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"

  • GPU mal configurada:

    • Interpretación: Es posible que el Pod no tenga la tolerancia nvidia.com/gpu requerida, que ComputeClass no esté en buen estado debido a discrepancias en el campo 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 se relaciona con los campos de GPU, verifica si hay problemas conocidos y actualiza a una versión de GKE con parches, 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

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

  • No se pueden programar las VMs Spot:

    • 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 no hay recursos disponibles, consulta Verifica la falta de disponibilidad de recursos.

      • Para controlar la selección de VMs Spot, enumera de forma explícita las entradas de machineType en el campo priorities, de la más barata a la más cara 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 de clústeres

Esta sección te ayuda a verificar si hay problemas que podrían no estar relacionados directamente con la configuración de la ComputeClass personalizada, 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. GKE tiene límites en las operaciones simultáneas, 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 la 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 escalado automático hasta que se complete esta operación.

Evalúa el resultado

  • No hay 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 se establece 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 de los Pods, 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 mover las cargas de trabajo a nodos de mayor prioridad cuando estén disponibles.

  • La migración activa está inhabilitada o no es eficaz:

    • 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 los nodos de menor prioridad cuando hay nodos de mayor prioridad disponibles. Este enfoque permite que las cargas de trabajo se programen en 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 aplica el archivo YAML:

        spec:
  activeMigration:
    optimizeRulePriority: true

Obtén asistencia

¿Qué sigue?