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

Cuando tus Pods en Google Kubernetes Engine (GKE) se quedan atascados en un estado Pending y no se agregan nodos nuevos, suele indicar un problema con la funcionalidad de escalamiento vertical del escalador automático del clúster. Este problema puede impedir que tus aplicaciones se escalen para satisfacer la demanda, retrasar las implementaciones y afectar la disponibilidad del servicio.

Usa esta página para diagnosticar y resolver problemas habituales que impiden que el escalador automático del clúster agregue nodos nuevos. Solucionar estos problemas permite que el programador de Kubernetes coloque tus cargas de trabajo con rapidez y ayuda a que tu clúster se adapte a la carga creciente.

Esta información es importante para los desarrolladores de aplicaciones, que necesitan que sus aplicaciones y servicios se programen y ejecuten de forma confiable, y para los administradores y operadores de la plataforma, que son responsables de garantizar que el clúster pueda aprovisionar recursos de forma dinámica para cumplir con los requisitos de carga de trabajo y mantener los niveles de servicio. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes del usuario de GKE.

Comprende cuándo el escalador automático de clústeres escala verticalmente 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 de clústeres solo agrega nodos cuando los recursos existentes son insuficientes.

Cada 10 segundos, el escalador automático del clúster verifica si hay Pods que no se pueden programar. 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 Pods no cumplidos.

Cuando el escalador automático del clúster encuentra Pods no programables, evalúa si agregar un nodo permitiría programar el Pod. Si agregar un nodo permite que se programe 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 recién aprovisionado.

Verifica 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 Google Cloud , ve a la página Cargas de trabajo.

    Ir a Cargas de trabajo

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

    Si hay Pods en la lista, significa que tienes Pods no programables. Para solucionar problemas de Pods no programables, consulta Error: Pod no programable. Resolver la causa subyacente de los Pods no programables suele permitir que el escalador automático de clústeres escale verticalmente. Para identificar y resolver errores específicos del escalador automático de clústeres, explora las siguientes secciones.

    Si no hay Pods en la lista, el escalador automático del clúster no necesita escalar verticalmente y funciona como se espera.

Verifica si anteriormente tenías Pods no programables

Si estás investigando qué causó que el escalador automático de clústeres fallara en el pasado, verifica si hay Pods no programables anteriormente:

  1. En la consola de Google Cloud , accede a la página Explorador de registros.

    Ve al Explorador de registros

  2. Especifica un período para las entradas de registro que quieres 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 tuviste 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.

Analiza las métricas de Cloud Monitoring para detectar problemas de escalamiento vertical

El escalador automático de clúster de GKE expone métricas a Cloud Monitoring que proporcionan estadísticas sobre sus decisiones, en especial en relación con las ComputeClasses. Estas métricas están disponibles en GKE versión 1.37 y posteriores, y son las siguientes.

  • Pods pendientes: kubernetes.io/autoscaler/cluster_pending_pods_per_ccc Muestra los Pods que el escalador automático intenta programar.
  • Intentos de aprovisionamiento: kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc Realiza un seguimiento de la frecuencia con la que el escalador automático intenta agregar nodos.
  • Fallas de aprovisionamiento: kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc muestra los intentos fallidos de creación de nodos y los motivos.

Estas métricas usan el tipo de recurso k8s_entity, en el que el valor del campo resource.labels.entity_type es ComputeClass. El valor del campo resource.labels.entity_name indica el nombre de ComputeClass. Si el campo entity_name tiene una cadena vacía ("") como valor, la métrica es para las decisiones del escalador automático del clúster que no están relacionadas con una ComputeClass.

Usa el Explorador de métricas para filtrar y agrupar los resultados por el campo entity_name. Por ejemplo, usa la cadena resource.labels.entity_name = "" para ver las actividades que no están relacionadas con ComputeClasses y las etiquetas de métricas (como reason) para comprender si los problemas de escalamiento vertical son específicos de una ComputeClass.

Para ver ejemplos de consultas, consulta Supervisa el aprovisionamiento de nodos y Supervisa el estado de los Pods pendientes.

Ver errores

A menudo, puedes diagnosticar la causa de los problemas de escalamiento vertical viendo 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 consola de Google Cloud . Estas notificaciones proporcionan estadísticas valiosas sobre por qué el escalador automático de clústeres no aumentó la escala 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 Google Cloud , completa los siguientes pasos:

  1. En la consola de Google Cloud , accede a la página 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 escalamiento vertical, consulta Cómo ver los 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 consola de Google Cloud , completa los siguientes pasos:

  1. En la consola de Google Cloud , accede a la página 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 escalamiento vertical, 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 escala verticalmente.

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 encontrar un EventResult que contenga el mismo eventId que el evento scaleUp. Luego, puedes mirar el campo errorMsg y consultar la lista de posibles mensajes de error de scaleUp.

  5. Como no encontraste ningún evento scaleUp, continúa buscando eventos noScaleUp y revisa 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 escalar verticalmente un grupo de nodos debido a un predicado de programación con errores para los Pods pendientes. Los parámetros son el nombre del predicado con errores y el motivo por el que falló.

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

Cómo resolver errores de aumento vertical de la escala

Si usas ComputeClasses personalizadas y los problemas de escalamiento vertical están relacionados con las configuraciones de nodos específicas definidas en tu ComputeClass, consulta Soluciona problemas de ComputeClass personalizadas.

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

Errores scaleUp

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

Cuando una operación de escalamiento vertical falla porque supera una cuota, se produce un error de creación de nodos que activa un período de retirada del sistema, el cual puede durar hasta 30 minutos. Para obtener más información, consulta Períodos de retirada.

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 alojar la solicitud debido a la falta de disponibilidad actual de un recurso de Compute Engine, como las GPU o CPU. Son los IDs de MIG con errores. Sigue los pasos para solucionar problemas relacionados con la 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 Google 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 que se agotó el tiempo de espera. Son los IDs de MIG con errores. Si las instancias se inician, pero no se registran en el plano de control, sigue los pasos que se indican en Busca una instancia que falló el registro de nodos. Para conocer otras causas, consulta Las instancias de MIG no aparecieron a tiempo. Por lo general, este error es transitorio. Si el error persiste, comunícate con Atención al cliente de Cloud para realizar una investigación más detallada.
"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 incluidos en No hay suficiente espacio de direcciones IP libre para los 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. Si ese procedimiento no funciona, comunícate con Atención al cliente de Cloud para investigar en más detalle.

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 verticalmente 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 (se bloqueó de manera temporal). Este mensaje puede aparecer durante eventos de escalamiento vertical con una gran cantidad de Pods. Este mensaje debe ser momentáneo. Verifica este error después de unos minutos. Si este mensaje persiste, comunícate con Atención al cliente de Cloud para investigar en más detalle.

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 este proceso no está habilitado a nivel del clúster.

Si el aprovisionamiento automático de nodos está inhabilitado, 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 a nivel de MIG de noScaleUp

Los mensajes de motivos a nivel de 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 el motivo por el que 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 errores para los Pods pendientes. Es el nombre del predicado con errores y los 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 a nivel de grupo de Pods de noScaleUp

Los mensajes de motivos de aprovisionamiento automático de nodos a nivel de grupo de Pods 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 programar 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. Es el 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 del 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. Es el tipo de GPU solicitado. Verifica la configuración del Pod pendiente para el tipo de GPU y 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. Es el 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. Es el nombre de la zona en cuestión y los 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 consola de Google Cloud , accede a la página Explorador de registros.

    Ve al Explorador de registros

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

    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 Google Cloud. No es un producto de Google Cloud 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 que requieren varios pasos o no tienen un mensaje de evento asociado del escalador automático de clústeres.

El Pod no cabe en el nodo

Síntomas:

Tus Pods permanecen en un estado Pending con el mensaje de error PodUnschedulable, o tu clúster muestra el mensaje de error Pods unschedulable, y el escalador automático del clúster no escala verticalmente para agregar nodos.

Causa:

El escalador automático de clústeres solo agrega nodos a un grupo de nodos si el tipo de máquina proporciona recursos suficientes, como CPU, GPU, memoria y almacenamiento, para un Pod pendiente. Si las solicitudes de recursos de un Pod superan los recursos de un solo nodo, el escalador automático del clúster no escala verticalmente porque el Pod aún no puede caber en un nodo nuevo.

Además, los recursos asignables de un nodo son menores que sus recursos totales porque los componentes del sistema reservan una parte de esos recursos. Para obtener más información sobre cómo GKE calcula los recursos asignables, consulta Recursos asignables de nodos.

Solución:

Para verificar si las solicitudes de recursos de un Pod superan los recursos que proporcionan tus nodos y resolver el problema, completa los siguientes pasos. En este ejemplo, se verifican los recursos de CPU, pero se aplican los mismos pasos a los recursos de GPU, memoria y almacenamiento:

  1. En la consola de Google 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, haz clic en la pestaña YAML.

  5. 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 de Pod, el Pod necesita 2 CPUs virtuales:

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

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

    1. En la consola de Google Cloud , accede a la página Clústeres de Kubernetes.

      Ir a clústeres de Kubernetes

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

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

    4. En la sección Grupos de nodos, observa el valor en la columna Tipo de máquina, por ejemplo, n1-standard-1.

  7. 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 usan el tipo de máquina n1-standard-1, los nodos solo tienen 1 CPU virtual. Con una configuración como esta, el escalador automático de clústeres no activa un escalamiento vertical porque el Pod aún no cabe en un nodo nuevo. Para 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.

  8. Resuelve la discrepancia según las necesidades de tu carga de trabajo:

    • Si el Pod requiere los recursos solicitados, crea un grupo de nodos con un tipo de máquina que pueda admitir las solicitudes de recursos del Pod.
    • Si las solicitudes de recursos del Pod no son precisas, actualiza la definición del Pod para que pueda caber en los nodos existentes.

Las instancias de MIG no aparecieron a tiempo

Síntomas:

Tal vez veas alguno de los siguientes mensajes de error:

  • En la consola de Google Cloud , el clúster muestra la siguiente notificación:

    Can't scale up because instances in managed instance groups hosting node pools failed to appear in time

  • En Logging, el evento eventResult para el escalamiento vertical contiene el siguiente mensaje de error:

    scale.up.error.waiting.for.instances.timeout

Causa:

Compute Engine no puede crear nodos en el MIG o los nodos nuevos no se registran en el plano de control antes de que se agote el tiempo de espera de la operación de escalamiento vertical. Este problema puede ocurrir por cualquiera de los siguientes motivos:

  • Error en el registro de nodos: Compute Engine crea los nodos, pero no se registran en el plano de control debido a una o más reglas de firewall, un cambio reciente en el acceso privado a servicios o el intercambio de tráfico entre redes de VPC, o una cuenta de servicio de Identity and Access Management (IAM) que falta.
  • Se superaron las cuotas del proyecto: Las instancias nuevas en el MIG no aparecen porque tu proyecto supera una cuota de CPU, direcciones IP o algún otro recurso.
  • Direcciones IP no disponibles: La subred no tiene suficientes direcciones IP libres para crear nodos nuevos.
  • Plantilla de instancias no válida: El MIG usa una plantilla de instancias no válida, como una plantilla con una imagen faltante, lo que impide el escalamiento vertical.
  • Recursos insuficientes: La zona no tiene suficientes recursos de Compute Engine, como GPU o CPU, para crear un nodo nuevo.
  • APIs inaccesibles: No se puede acceder a una API obligatoria, como compute.googleapis.com, debido a una regla de firewall o un perímetro de Controles del servicio de VPC.
  • Latencia de red: la latencia de red significativa retrasa la creación o la usabilidad de un nodo nuevo.

Solución:

  1. Para identificar la causa del tiempo de espera, enumera los errores de la instancia en el MIG y, luego, verifica el resultado:

    • El MIG no enumera los errores desde el momento de la falla: Compute Engine creó los nodos, pero estos no se registraron en el plano de control antes del tiempo de espera. En el siguiente paso, comienza con Registro de nodos con errores. Si los nodos se registraron, pero tardaron demasiado, consulta Latencia de red.

    • El MIG enumera los errores desde el momento de la falla: Compute Engine no pudo crear los nodos. Usa el código y el mensaje de error para encontrar la causa en el siguiente paso. Entre los códigos de error comunes, se incluyen los siguientes:

      • QUOTA_EXCEEDED: Se excedieron las cuotas del proyecto
      • IP_SPACE_EXHAUSTED: Direcciones IP no disponibles
      • ZONE_RESOURCE_POOL_EXHAUSTED: recursos insuficientes

      Algunos códigos de error tienen un sufijo _WITH_DETAILS y, además, incluyen más información en el mensaje de error. Si el mensaje de error informa un recurso que no existe, como una imagen de origen, consulta la viñeta Plantilla de instancias no válida.

  2. Usa la resolución que corresponda a la causa de tu problema:

    • Registro de nodos con errores: Sigue los pasos que se indican en Busca una instancia que falló el registro de nodos. También puedes verificar si hay cambios recientes en la configuración:

      • Reglas de firewall: Para verificar si se creó, actualizó o borró una regla de firewall recientemente, ejecuta la siguiente consulta en el Explorador de registros:

        resource.type="gce_firewall_rule"
log_id("cloudaudit.googleapis.com/activity")

        Si un cambio bloquea el tráfico entre los nodos y el plano de control o a las APIs de Google, actualiza o reemplaza la regla de firewall. Para obtener más información sobre la conectividad requerida, consulta Requisitos previos para el registro correcto de nodos.

      • Cuenta de servicio de IAM: Para una cuenta de servicio faltante, consulta la fila scale.up.error.service.account.deleted en la tabla Errores de ScaleUp.

      • Acceso privado a servicios: Para verificar los cambios recientes en los registros de auditoría, consulta Registros de auditoría del acceso privado a servicios.

      • Intercambio de tráfico entre redes de VPC: Para verificar si se agregó, actualizó o quitó el intercambio de tráfico recientemente, ejecuta la siguiente consulta en el Explorador de registros para cada proyecto con intercambio de tráfico:

        log_id("cloudaudit.googleapis.com/activity")
resource.type="gce_network"
protoPayload.methodName:("compute.networks.addPeering" OR
"compute.networks.updatePeering" OR
"compute.networks.removePeering")

        Si un cambio de intercambio de tráfico interrumpió la conectividad con el plano de control, actualiza la conexión de intercambio de tráfico. Si se borró la conexión, consulta La conexión de intercambio de tráfico entre redes de VPC se borra por accidente.

    • Se excedieron las cuotas del proyecto: consulta la fila scale.up.error.quota.exceeded en la tabla Errores de ScaleUp.

    • Direcciones IP no disponibles: consulta la fila scale.up.error.ip.space.exhausted en la tabla Errores de escalamiento vertical.

    • Plantilla de instancias no válida: consulta La plantilla de instancias no es válida en la documentación de Compute Engine.

    • Recursos insuficientes: consulta la fila scale.up.error.out.of.resources en la tabla Errores de ScaleUp.

    • APIs inaccesibles: En el Explorador de registros, ejecuta una consulta para verificar la actividad relacionada con las reglas de firewall o los perímetros de los Controles del servicio de VPC:

      • Para verificar si una regla de firewall se cambió recientemente, ejecuta la consulta de registro de auditoría en la viñeta Reglas de firewall de Registro de nodos con errores. Si habilitaste el registro de reglas de firewall para tus reglas, también puedes ver las conexiones que tus reglas rechazaron ejecutando la siguiente consulta:

        resource.type="gce_subnetwork"
log_id("compute.googleapis.com/firewall")
jsonPayload.disposition="DENIED"

        Si los registros muestran una regla de firewall que bloquea el tráfico a las APIs de Google necesarias, actualiza o reemplaza la regla de firewall para permitir el tráfico. Para obtener más información sobre los requisitos de red, consulta Requisitos para la conexión de red a los servicios y las APIs de Google.

      • Si usas los Controles del servicio de VPC, selecciona tu organización en la consola de Google Cloud y ejecuta la siguiente consulta en el Explorador de registros para verificar si se agregó o modificó un perímetro recientemente:

        logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.serviceName="accesscontextmanager.googleapis.com"

        Reemplaza ORGANIZATION_ID por el ID de tu organización.

        También puedes agregar los siguientes filtros para encontrar una actualización o creación de un perímetro de Controles del servicio de VPC:

        severity=NOTICE
protoPayload.methodName=("google.identity.accesscontextmanager.v1.AccessContextManager.CreateServicePerimeter"
OR "google.identity.accesscontextmanager.v1.AccessContextManager.UpdateServicePerimeter")

        Si un perímetro nuevo o modificado bloquea el acceso a las APIs de Google necesarias, recupera los errores de los Controles del servicio de VPC de los registros de auditoría para identificar el servicio bloqueado y actualiza el perímetro de servicio para permitir el acceso. Para obtener más información sobre el uso del escalador automático de clústeres en un perímetro, consulta El escalador automático no funciona en perímetros con servicios accesibles y servicios restringidos habilitados.

    • Latencia de red: la latencia de red transitoria suele resolverse en los intentos de escalamiento vertical posteriores. Para la latencia persistente, consulta Soluciona problemas habituales de redes en la documentación de Compute Engine.

Los clústeres en mal estado impiden el escalamiento vertical

Síntomas:

El escalador automático de clústeres detiene todas las operaciones de escalamiento, y el ConfigMap cluster-autoscaler-status contiene un evento con el tipo Warning y ClusterUnhealthy como el motivo.

Para ver el ConfigMap de cluster-autoscaler-status, ejecuta el siguiente comando:

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

Causa:

El escalador automático de clústeres no escala verticalmente si considera que un clúster no está en buen estado. El escalador automático del clúster determina el estado del clúster según la proporción de nodos en buen estado y listos, no según el estado del plano de control. Si el 45% de los nodos de un clúster no está en buen estado o no está listo, el escalador automático de clústeres detiene todas las operaciones.

El escalador automático de clústeres también considera que un nodo listo es NotReady cuando el nodo tiene un taint con el prefijo ignore-taint.cluster-autoscaler.kubernetes.io/. El escalador automático de clústeres trata al nodo como NotReady mientras ese taint esté presente.

Solución:

Para resolver este problema, disminuye la cantidad de nodos en mal estado realizando una o ambas de las siguientes acciones:

  • Investiga y repara los nodos en mal estado o NotReady para que menos del 45% de los nodos del clúster estén en mal estado.
  • Si los nodos listos tienen un taint con el prefijo ignore-taint.cluster-autoscaler.kubernetes.io/, quítalo.

¿Qué sigue?