Soluciona problemas relacionados con el escalador automático de clústeres que no escala verticalmente

En esta página, se muestra cómo descubrir y resolver problemas relacionados con el escalador automático de clústeres que no aumenta la cantidad de nodos en tus clústeres de Google Kubernetes Engine (GKE).

Esta página está dirigida a los desarrolladores de aplicaciones que desean resolver una situación inesperada o negativa con su app o servicio, y a los administradores y operadores de la plataforma que desean evitar interrupciones en la entrega de productos y servicios.

Comprende cuándo el escalador automático de clústeres aumenta la escala de tus nodos

Antes de continuar con los pasos para solucionar problemas, puede ser útil comprender cuándo el escalador automático de clústeres intentaría aumentar la escala verticalmente de tus nodos. El escalador automático del clúster solo agrega nodos cuando los recursos existentes son insuficientes.

Cada 10 segundos, el escalador automático del clúster verifica si hay Pods no programables. Un Pod se vuelve no programable cuando el programador de Kubernetes no puede colocarlo en ningún nodo existente debido a recursos insuficientes, restricciones de nodos o requisitos de Pod no satisfechos.

Cuando el escalador automático de clústeres encuentra Pods no programables, evalúa si agregar un nodo permitiría programar el Pod. Si agregar un nodo permite programar un Pod, el escalador automático del clúster agrega un nodo nuevo al grupo de instancias administrado (MIG). Luego, el programador de Kubernetes puede programar el Pod en el nodo aprovisionado recientemente.

Comprueba si tienes Pods no programables

Para determinar si tu clúster necesita escalar verticalmente, verifica si hay Pods no programados:

  1. En la consola de Trusted Cloud , ve a la página Cargas de trabajo.

    Ir a Cargas de trabajo

  2. En el campo Filtro , ingresa unschedulable y presiona Intro.

    Si hay Pods en la lista, significa que tienes Pods no programables. Para solucionar problemas relacionados con los Pods no programables, consulta Error: Pod no programable. Resolver la causa subyacente de los Pods no programables a menudo puede permitir que el escalador automático del clúster realice un ajuste de escala. Para identificar y resolver errores específicos del escalador automático del clúster, explora las siguientes secciones.

    Si no se muestran Pods, el escalador automático del clúster no necesita aumentar la escala y funciona según lo esperado.

Comprueba si antes tenías Pods no programables

Si estás investigando qué causó la falla del escalador automático de clústeres en el pasado, verifica si hubo Pods no programables anteriormente:

  1. En la Trusted Cloud consola, ve a la página Explorador de registros.

    Ir al Explorador de registros

  2. Especifica un período para las entradas de registro que deseas ver.

  3. En el panel de consultas, ingresa la siguiente consulta:

    logName="projects/PROJECT_ID/logs/events"
jsonPayload.source.component="default-scheduler"
jsonPayload.reason="FailedScheduling"

    Reemplaza PROJECT_ID con el ID del proyecto.

  4. Haz clic en Ejecutar consulta.

    Si se muestran resultados, significa que tenías Pods no programables en el período que especificaste.

Comprueba si el problema se debe a una limitación

Después de confirmar que tienes Pods no programados, asegúrate de que el problema con el escalador automático de clústeres no se deba a una de las limitaciones del escalador automático de clústeres.

Ver errores

A menudo, puedes diagnosticar la causa de los problemas de aumento de escala si ves los mensajes de error:

Cómo ver errores en las notificaciones

Si el problema que observaste ocurrió hace menos de 72 horas, consulta las notificaciones sobre errores en la Trusted Cloud consola. Estas notificaciones proporcionan estadísticas valiosas sobre por qué el escalador automático de clústeres no escaló verticalmente y ofrecen sugerencias para resolver el error y ver los registros relevantes para una investigación más detallada.

Para ver las notificaciones en la consola de Trusted Cloud , completa los siguientes pasos:

  1. En la consola de Trusted Cloud , ve a la página de clústeres de Kubernetes.

    Ir a clústeres de Kubernetes

  2. Revisa la columna Notificaciones. Las siguientes notificaciones están asociadas con problemas de aumento de la escala verticalmente:

    • Can't scale up
    • Can't scale up pods
    • Can't scale up a node pool

  3. Haz clic en la notificación relevante para ver un panel con detalles sobre lo que causó el problema y las acciones recomendadas para resolverlo.

  4. Opcional: Para ver los registros de este evento, haz clic en Registros. Esta acción te dirige al Explorador de registros con una consulta prepropagada para ayudarte a investigar más a fondo el evento de escalamiento. Para obtener más información sobre cómo funcionan los eventos de aumento de escala, consulta Cómo ver eventos del escalador automático de clústeres.

Si los problemas persisten después de revisar los consejos de la notificación, consulta las tablas de mensajes de error para obtener más ayuda.

Cómo ver errores en los eventos

Si el problema que observaste ocurrió hace más de 72 horas, consulta los eventos en Cloud Logging. Cuando se produce un error, suele registrarse en un evento.

Para ver los registros del escalador automático de clústeres en la Trusted Cloud consola, completa los siguientes pasos:

  1. En la consola de Trusted Cloud , ve a la página de clústeres de Kubernetes.

    Ir a clústeres de Kubernetes

  2. Selecciona el nombre del clúster que deseas investigar para ver su página Detalles del clúster.

  3. En la página Detalles del clúster, haz clic en la pestaña Registros.

  4. En la pestaña Registros, haz clic en la pestaña Registros del escalador automático para ver los registros.

  5. Si deseas aplicar filtros más avanzados para limitar los resultados, haz clic en el botón de la flecha ubicada en el lado derecho de la página a fin de ver los registros en Explorador de registros (opcional).

Para obtener más información sobre el funcionamiento de los eventos de aumento vertical de la escala, consulta Cómo ver eventos del escalador automático de clústeres. Para ver un ejemplo de cómo usar Cloud Logging, consulta el siguiente ejemplo de solución de problemas.

Ejemplo: Soluciona un problema que tiene más de 72 horas

En el siguiente ejemplo, se muestra cómo investigar y resolver un problema con un clúster que no se expande.

Situación: Durante la última hora, un Pod se marcó como no programable. El escalador automático de clústeres no aprovisionó ningún nodo nuevo para programar el Pod.

Solución:

  1. Como el problema ocurrió hace más de 72 horas, lo investigas con Cloud Logging en lugar de mirar los mensajes de notificación.
  2. En Cloud Logging, encontrarás los detalles de registro para los eventos del escalador automático de clústeres, como se describe en Cómo ver errores en los eventos.

  3. Buscas eventos scaleUp que contengan el Pod que estás investigando en el campo triggeringPods. Podrías filtrar las entradas de registro, incluido el filtrado por un valor de campo JSON particular. Obtén más información en Consultas avanzadas de registros.

  4. No encontrarás ningún evento de escalamiento vertical. Sin embargo, si lo hiciste, puedes intentar buscar un EventResult que contenga el mismo eventId que el evento scaleUp. Luego, puedes mirar el campo errorMsg y consultar la lista de mensajes de error de scaleUp posibles.

  5. Como no encontraste ningún evento scaleUp, sigues buscando eventos noScaleUp y revisas los siguientes campos:

    • unhandledPodGroups: contiene información sobre el pod (o el controlador del pod).
    • reason: proporciona motivos globales que indican que el escalamiento vertical podría estar bloqueado.
    • skippedMigs: proporciona los motivos por los que se pueden omitir algunos MIG.

  6. Encontraste un evento noScaleUp para tu pod y todos los MIG en el campo rejectedMigs tienen el mismo ID de mensaje de motivo de "no.scale.up.mig.failing.predicate" con dos parámetros: "NodeAffinity" y "node(s) did not match node selector".

Solución:

Después de consultar la lista de mensajes de error, descubres que el escalador automático de clústeres no puede aumentar la escala de un grupo de nodos debido a un error en el predicado de programación para los Pods pendientes. Los parámetros son el nombre del predicado con errores y la razón por la que falló.

Para resolver el problema, revisas el manifiesto del Pod y descubres que tiene un selector de nodos que no coincide con ningún MIG en el clúster. Borra el selector del manifiesto del Pod y vuelve a crear el Pod. El escalador automático de clústeres agrega un nodo nuevo y el Pod se programa.

Cómo resolver errores de aumento de escala

Después de identificar el error, usa las siguientes tablas para ayudarte a comprender qué lo causó y cómo resolverlo.

Errores de scaleUp

Puedes encontrar mensajes de eventos de error para los eventos scaleUp en el evento eventResult correspondiente, en el campo resultInfo.results[].errorMsg.

Mensaje Detalles Parámetros Mitigación
"scale.up.error.out.of.resources" Los errores de recursos se producen cuando intentas solicitar recursos nuevos en una zona que no puede admitir tu solicitud debido a la falta de disponibilidad actual de un recurso de Compute Engine, como GPU o CPU. Son los IDs de MIG con errores. Sigue los pasos para solucionar problemas de disponibilidad de recursos en la documentación de Compute Engine.
"scale.up.error.quota.exceeded" El evento scaleUp falló porque algunos de los MIG no se pudieron aumentar debido a que se superó la cuota de Compute Engine. Son los IDs de MIG con errores. Consulta la pestaña Errores del MIG en la consola de Trusted Cloud para ver qué cuota se está excediendo. Una vez que sepas qué cuota se está excediendo, sigue las instrucciones para solicitar un aumento de cuota.
"scale.up.error.waiting.for.instances.timeout" No se pudo escalar verticalmente el grupo de instancias administrado debido a un tiempo de espera agotado. Son los IDs de MIG con errores. Este mensaje debe ser transitorio.
"scale.up.error.ip.space.exhausted" No se puede escalar verticalmente porque las instancias de algunos de los grupos de instancias administrados se quedaron sin IP. Esto significa que el clúster no tiene suficiente espacio de direcciones IP sin asignar para agregar nodos o Pods nuevos. Son los IDs de MIG con errores. Sigue los pasos para solucionar problemas en No hay suficiente espacio de direcciones IP gratuito para Pods.
"scale.up.error.service.account.deleted" No se puede escalar verticalmente porque se borró la cuenta de servicio. Son los IDs de MIG con errores. Intenta recuperar la cuenta de servicio.

Motivos de un evento noScaleUp

Un evento noScaleUp se emite de forma periódica cuando hay Pods no programables en el clúster y el escalador automático de clústeres no puede escalar el clúster para alojar los Pods. Los eventos noScaleUp se basan en el mejor esfuerzo y no abarcan todos los casos posibles.

Motivos de nivel superior de NoScaleUp

Los mensajes de motivo de nivel superior para los eventos noScaleUp aparecen en el campo noDecisionStatus.noScaleUp.reason. El mensaje contiene un motivo de nivel superior que explica por qué el escalador automático de clústeres no puede escalar verticalmente el clúster.

Mensaje Detalles Mitigación
"no.scale.up.in.backoff" No se escaló verticalmente porque este proceso está en un período de retirada (bloqueado temporalmente). Este mensaje puede ocurrir durante eventos de escalamiento vertical con una gran cantidad de Pods. Este mensaje debe ser transitorio. Verifica este error después de unos minutos.

Motivos de aprovisionamiento automático de nodos de nivel superior de noScaleUp

Los mensajes de motivo de aprovisionamiento automático de nodos de nivel superior para eventos noScaleUp aparecen en el campo noDecisionStatus.noScaleUp.napFailureReason. El mensaje contiene un motivo de nivel superior que explica por qué el escalador automático de clústeres no puede aprovisionar nuevos grupos de nodos.

Mensaje Detalles Mitigación
"no.scale.up.nap.disabled"

El aprovisionamiento automático de nodos no pudo escalarse verticalmente porque no está habilitado a nivel del clúster.

Si se inhabilita el aprovisionamiento automático de nodos, los nodos nuevos no se aprovisionarán de forma automática si el Pod pendiente tiene requisitos que ningún grupo de nodos existente puede satisfacer.

 Revisa la configuración del clúster y consulta Habilita el aprovisionamiento automático de nodos.

Motivos de nivel de MIG de noScaleUp

Los mensajes de motivo de nivel MIG para los eventos noScaleUp aparecen en los campos noDecisionStatus.noScaleUp.skippedMigs[].reason y noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason. El mensaje contiene un motivo por el que el escalador automático de clústeres no puede aumentar el tamaño de un MIG en particular.

Mensaje Detalles Parámetros Mitigación
"no.scale.up.mig.skipped" No se puede escalar verticalmente un MIG porque se omitió durante la simulación. Son los motivos por los que se omitió el MIG (por ejemplo, falta un requisito de Pod). Revisa los parámetros incluidos en el mensaje de error y aborda por qué se omitió el MIG.
"no.scale.up.mig.failing.predicate" No se puede escalar verticalmente un grupo de nodos debido a un predicado de programación con fallas para los Pods pendientes. Nombre del predicado que falló y motivos por los que falló. Revisa los requisitos del Pod, como las reglas de afinidad, los taints o las tolerancias, y los requisitos de los recursos

Motivos de aprovisionamiento automático de nodos de nivel de grupo de pods

Los mensajes de motivo de aprovisionamiento automático de nodos de nivel de grupo para los eventos noScaleUp aparecen en el campo noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[]. El mensaje contiene un motivo por el que el escalador automático de clústeres no puede aprovisionar un grupo de nodos nuevo para alojar un grupo de pods en particular.

Mensaje Detalles Parámetros Mitigación
"no.scale.up.nap.pod.gpu.no.limit.defined" El aprovisionamiento automático de nodos no pudo aprovisionar ningún grupo de nodos porque un Pod pendiente tiene una solicitud de GPU, pero los límites de recursos de GPU no se definen a nivel del clúster. Tipo de GPU solicitado. Revisa la solicitud de GPU del Pod pendiente y actualiza la configuración para los límites de GPU del aprovisionamiento automático de nodos a nivel de clúster.
"no.scale.up.nap.pod.gpu.type.not.supported" El aprovisionamiento automático de nodos no aprovisionó ningún grupo de nodos para el Pod porque tiene solicitudes de un tipo de GPU desconocido. Tipo de GPU solicitado. Verifica la configuración del Pod pendiente para el tipo de GPU a fin de asegurarte de que coincida con un tipo de GPU compatible.
"no.scale.up.nap.pod.zonal.resources.exceeded" El aprovisionamiento automático de nodos no aprovisionó ningún grupo de nodos para el Pod en esta zona porque hacerlo infringiría los límites de recursos máximos en todo el clúster, excedería los recursos disponibles en la zona o no existiría ningún tipo de máquina que pueda ajustarse a la solicitud. Nombre de la zona en cuestión. Revisa y actualiza los límites de recursos máximos en todo el clúster, las solicitudes de recursos de Pods o las zonas disponibles para el aprovisionamiento automático de nodos.
"no.scale.up.nap.pod.zonal.failing.predicates" El aprovisionamiento automático de nodos no aprovisionó ningún grupo de nodos para el pod en esta zona debido a errores en los predicados. Nombre de la zona considerada y motivos por los que fallaron los predicados. Revisa los requisitos del Pod pendiente, como las reglas de afinidad, los taints, las tolerancias o los requisitos de los recursos.

Realiza una investigación más detallada

En las siguientes secciones, se proporciona orientación para usar el Explorador de registros y gcpdiag para obtener estadísticas adicionales sobre tus errores.

Investiga errores en el Explorador de registros

Si quieres investigar más el mensaje de error, consulta los registros específicos de tu error:

  1. En la Trusted Cloud consola, ve a la página Explorador de registros.

    Ir al Explorador de registros

  2. En el panel de consultas, ingresa la siguiente consulta:

    resource.type="k8s_cluster"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"

    Reemplaza ERROR_MESSAGE por el mensaje que deseas investigar. Por ejemplo, scale.up.error.out.of.resources

  3. Haz clic en Ejecutar consulta.

Cómo depurar algunos errores con gcpdiag

gcpdiag es una herramienta de código abierto creada con la asistencia de los ingenieros técnicos de Trusted Cloud by S3NS. No es un producto Trusted Cloud by S3NS compatible oficialmente.

Si recibiste uno de los siguientes mensajes de error, puedes usar gcpdiag para solucionar el problema:

  • scale.up.error.out.of.resources
  • scale.up.error.quota.exceeded
  • scale.up.error.waiting.for.instances.timeout
  • scale.up.error.ip.space.exhausted
  • scale.up.error.service.account.deleted

Para obtener una lista y una descripción de todas las marcas de la herramienta gcpdiag, consulta las instrucciones de uso de gcpdiag.

Cómo resolver errores complejos de aumento de escala verticalmente

En las siguientes secciones, se ofrece orientación para resolver errores en los que las mitigaciones implican varios pasos y errores que no tienen un mensaje de evento del escalador automático de clústeres asociado.

Problema: El Pod no cabe en el nodo

El escalador automático del clúster solo programa un Pod en un nodo si hay un nodo con suficientes recursos, como GPU, memoria y almacenamiento, para satisfacer los requisitos del Pod. Para determinar si esta es la razón por la que el escalador automático del clúster no aumentó la escala, compara las solicitudes de recursos con los recursos proporcionados.

En el siguiente ejemplo, se muestra cómo verificar los recursos de CPU, pero los mismos pasos se aplican a los recursos de GPU, memoria y almacenamiento. Para comparar las solicitudes de CPU con las CPUs aprovisionadas, completa los siguientes pasos:

  1. En la consola de Trusted Cloud , ve a la página Cargas de trabajo.

    Ir a Cargas de trabajo

  2. Haz clic en el mensaje de error PodUnschedulable.

  3. En el panel Detalles, haz clic en el nombre del Pod. Si hay varios Pods, comienza con el primero y repite el siguiente proceso para cada uno.

  4. En la página Detalles del Pod, ve a la pestaña Eventos.

  5. En la pestaña Eventos, ve a la pestaña YAML.

  6. Toma nota de las solicitudes de recursos de cada contenedor en el Pod para encontrar el total de solicitudes de recursos. Por ejemplo, en la siguiente configuración del Pod, el Pod necesita 2 vCPUs:

    resources:
  limits:
    cpu: "3"
 requests:
    cpu: "2"

  7. Consulta los detalles del grupo de nodos del clúster con el Pod no programado:

    1. En la consola de Trusted Cloud , ve a la página de clústeres de Kubernetes.

      Ir a clústeres de Kubernetes

    2. Haz clic en el nombre del clúster que muestra el mensaje de error Pods unschedulable.

    3. En la página Detalles del clúster, ve a la pestaña Nodos.

  8. En la sección Grupos de nodos, anota el valor en la columna Tipo de máquina. Por ejemplo, n1-standard-1.

  9. Compara la solicitud de recursos con las CPU virtuales que proporciona el tipo de máquina. Por ejemplo, si un Pod solicita 2 CPU virtuales, pero los nodos disponibles tienen el tipo de máquina n1-standard-1, los nodos solo tendrán 1 CPU virtual. Con una configuración como esta, el escalador automático de clústeres no activaría el escalamiento vertical, ya que, incluso si agregara un nodo nuevo, este Pod no cabría en él. Si deseas obtener más información sobre los tipos de máquinas disponibles, consulta la guía de comparación y recursos de familias de máquinas en la documentación de Compute Engine.

También ten en cuenta que los recursos asignables de un nodo son menores que los recursos totales, ya que se necesita una parte para ejecutar los componentes del sistema. Para obtener más información sobre cómo se calcula, consulta Recursos asignables del nodo.

Para resolver este problema, decide si las solicitudes de recursos definidas para la carga de trabajo son adecuadas para tus necesidades. Si no se debe cambiar el tipo de máquina, crea un grupo de nodos con un tipo de máquina que pueda admitir la solicitud proveniente del Pod. Si las solicitudes de recursos del Pod no son precisas, actualiza la definición del Pod para que los Pods puedan ajustarse a los nodos.

Problema: Clústeres en mal estado que impiden el escalamiento vertical

Es posible que el escalador automático del clúster no realice el ajuste de escala vertical si considera que un clúster no está en buen estado. El mal estado del clúster no se basa en el buen estado del plano de control, sino en la proporción de nodos en buen estado y listos. Si el 45% de los nodos de un clúster no están en buen estado o no están listos, el escalador automático de clústeres detiene todas las operaciones.

Si este es el motivo por el que tu escalador automático de clústeres no se escala verticalmente, hay un evento en el ConfigMap del escalador automático de clústeres con el tipo Warning y ClusterUnhealthy como motivo.

Para ver el ConfigMap, ejecuta el siguiente comando:

kubectl describe configmap cluster-autoscaler-status -n kube-system

Para resolver este problema, disminuye la cantidad de nodos en mal estado.

También es posible que algunos de los nodos estén listos, aunque el escalador automático de clústeres no los considere como tales. Esto sucede cuando un taint con el prefijo ignore-taint.cluster-autoscaler.kubernetes.io/ está presente en un nodo. El escalador automático de clústeres considera que un nodo está NotReady mientras esté presente esa contaminación.

Si el comportamiento se debe a la presencia de la contaminación ignore-taint.cluster-autoscaler.kubernetes.io/.*, quítala.

¿Qué sigue?