Solucionar problemas de la herramienta de adaptación dinámica de clústeres que no escala verticalmente

Cuando tus pods de Google Kubernetes Engine (GKE) se quedan en el estado Pending y no se añaden nodos nuevos, suele indicar que hay un problema con la función de ampliación 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 a la disponibilidad del servicio.

Utilice esta página para diagnosticar y resolver problemas habituales que impiden que el escalador automático de clústeres añada nodos. Al corregir estos problemas, el programador de Kubernetes puede colocar tus cargas de trabajo rápidamente y tu clúster puede adaptarse al aumento de la carga.

Esta información es importante para los desarrolladores de aplicaciones, que necesitan que sus aplicaciones y servicios se programen y se ejecuten de forma fiable, así como para los administradores y operadores de la plataforma, que son responsables de asegurarse de que el clúster pueda aprovisionar recursos de forma dinámica para cumplir los requisitos de las cargas de trabajo y mantener los niveles de servicio. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido de Trusted Cloud by S3NS , consulta Roles y tareas habituales de usuario de GKE.

Entender cuándo la herramienta de adaptación dinámica de clústeres aumenta el número de nodos

Antes de seguir los pasos para solucionar el problema, puede ser útil saber cuándo intentará la herramienta de adaptación dinámica de clústeres aumentar el número de nodos. El autoescalador de clústeres solo añade nodos cuando los recursos existentes son insuficientes.

Cada 10 segundos, la herramienta de escalado automático de clústeres comprueba si hay algún pod que no se pueda programar. Un pod no se puede programar cuando el programador de Kubernetes no puede colocarlo en ningún nodo debido a que no hay suficientes recursos, a las restricciones de los nodos o a que no se cumplen los requisitos del pod.

Cuando la herramienta de adaptación dinámica del clúster encuentra pods que no se pueden programar, evalúa si la adición de un nodo permitiría programar el pod. Si al añadir un nodo se permite que un pod se programe, el escalador automático de clúster añade un nodo nuevo al grupo de instancias gestionadas (MIG). El programador de Kubernetes puede programar el pod en el nodo recién aprovisionado.

Comprobar si tienes pods no programables

Para determinar si tu clúster necesita aumentar la escala, comprueba si hay pods sin programar:

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

   Ve a Cargas de trabajo.

2. En el campo filter_list Filtrar, introduce unschedulable y pulsa Intro.

   Si hay algún pod en la lista, significa que tienes pods que no se pueden programar. Para solucionar problemas con pods que no se pueden programar, consulta Error: Pod unschedulable. Si se resuelve la causa subyacente de los pods que no se pueden programar, a menudo se puede habilitar el escalado vertical automático del clúster. Para identificar y resolver errores específicos del escalador automático de clústeres, consulta las siguientes secciones.

   Si no aparece ningún pod, significa que la herramienta de adaptación dinámica de clústeres no necesita aumentar la escala y funciona correctamente.

Comprobar si has tenido Pods no programables anteriormente

Si quieres investigar por qué ha fallado la herramienta de adaptación dinámica de clústeres en el pasado, comprueba si hay pods que no se han podido programar:

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

   Ir a Explorador de registros

2. Especifique el intervalo de tiempo de las entradas de registro que quiera ver.

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

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

   Sustituye PROJECT_ID por el ID del proyecto.

4. Haz clic en Realizar una consulta.

   Si se muestra algún resultado, significa que tenías pods que no se podían programar en el periodo que has especificado.

Comprobar si el problema se debe a una limitación

Una vez que hayas confirmado que tienes pods no programados, asegúrate de que el problema con el escalador automático de clúster no se deba a una de las limitaciones del escalador automático de clúster.

Ver errores

A menudo, puedes diagnosticar la causa de los problemas de escalado viendo los mensajes de error:

• Si ya has visto un mensaje de error, consulta la tabla de mensajes de error para obtener información sobre cómo resolverlo.

• Si aún no has visto ningún mensaje, usa una de las siguientes opciones:

  • Problemas de menos de 72 horas: consulta las notificaciones de error en la consola Trusted Cloud .
  • Problemas de más de 72 horas: consulta los errores en los eventos de Cloud Logging.

Ver errores en las notificaciones

Si el problema que has observado ha ocurrido hace menos de 72 horas, consulta las notificaciones sobre errores en la Trusted Cloud consola. Estas notificaciones proporcionan información valiosa sobre por qué no se ha escalado verticalmente la herramienta de adaptación dinámica de clústeres y ofrecen consejos sobre cómo resolver el error y ver los registros pertinentes para investigar más a fondo.

Para ver las notificaciones en la consola de Trusted Cloud , sigue estos pasos:

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

   Ir a clústeres de Kubernetes

2. Consulta la columna Notificaciones. Las siguientes notificaciones están asociadas a problemas de escalado:

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

3. Haga clic en la notificación correspondiente para ver un panel con detalles sobre la causa del problema y las acciones recomendadas para solucionarlo.

4. Opcional: Para ver los registros de este evento, haga clic en Registros. Esta acción te lleva a Explorador de registros con una consulta predefinida para ayudarte a investigar más a fondo el evento de escalado. Para obtener más información sobre cómo funcionan los eventos de ampliación, consulta Ver los eventos de la herramienta de adaptación dinámica de clústeres.

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

Ver errores en eventos

Si el problema que ha observado se produjo hace más de 72 horas, consulte los eventos en Cloud Logging. Cuando se produce un error, suele registrarse en un evento.

Para ver los registros de la herramienta de adaptación dinámica de clústeres en la Trusted Cloud consola, sigue estos pasos:

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

   Ir a clústeres de Kubernetes

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

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

4. En la pestaña Registros, haga clic en la pestaña Registros de escalado automático para ver los registros.

5. Opcional: Para aplicar filtros más avanzados y acotar los resultados, haz clic en el botón con la flecha situado en la parte derecha de la página para ver los registros en Explorador de registros.

Para obtener más información sobre cómo funcionan los eventos de escalado vertical, consulta Ver eventos de la herramienta de adaptación dinámica de clústeres. Para ver un ejemplo de cómo usar Cloud Logging, consulta este ejemplo de solución de problemas.

Ejemplo: Solucionar 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 ha marcado como no programable. La herramienta de escalado automático del clúster no ha aprovisionado ningún nodo nuevo para programar el pod.

Solución:

1. Como el problema ocurrió hace más de 72 horas, investiga el problema con Cloud Logging en lugar de consultar los mensajes de notificación.
2. En Cloud Logging, encontrarás los detalles de registro de los eventos del escalador automático de clústeres, tal como se describe en Ver errores en eventos.

3. Buscas scaleUp eventos que contengan el pod que estás investigando en el campo triggeringPods. Puede filtrar las entradas de registro, incluso por el valor de un campo JSON concreto. Consulte más información en Consultas de registros avanzadas.

4. No se encuentran eventos de escalado vertical. Sin embargo, si lo hicieras, podrías intentar encontrar un EventResult que contenga el mismo eventId que el evento scaleUp. A continuación, puedes consultar el campo errorMsg y la lista de posibles mensajes de error de scaleUp.

5. Como no has encontrado 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 generales que indican que se podría bloquear el aumento de escala.
   • skippedMigs: indica los motivos por los que se pueden omitir algunas MIGs.

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

Resolución:

Después de consultar la lista de mensajes de error, descubres que la herramienta de adaptación dinámica de clústeres no puede escalar verticalmente un grupo de nodos debido a un error en el predicado de programación de los pods pendientes. Los parámetros son el nombre del predicado que ha fallado y el motivo por el que ha fallado.

Para solucionar 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. Eliminas el selector del manifiesto del pod y vuelves a crear el pod. La herramienta de adaptación dinámica del clúster añade un nuevo nodo y se programa el pod.

Resolver errores de aumento de escala

Una vez que hayas identificado el error, consulta las siguientes tablas para saber qué lo ha provocado y cómo solucionarlo.

Errores de ScaleUp

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

Cuando una operación de escalado vertical falla porque supera una cuota, se produce un error de creación de nodos que activa un periodo de espera del sistema, que puede durar hasta 30 minutos. Para obtener más información, consulta Periodos de espera.

Motivos de un evento noScaleUp

Un evento noScaleUp se emite periódicamente cuando hay pods que no se pueden programar en el clúster y la herramienta de adaptación dinámica de clústeres no puede aumentar la escala del clúster para programar los pods. Los eventos noScaleUp se envían de la mejor forma posible y no cubren todos los casos posibles.

NoScaleUp top-level reasons

Los mensajes de motivo de nivel superior de los eventos noScaleUp se muestran en el campo noDecisionStatus.noScaleUp.reason. El mensaje contiene un motivo de nivel superior por el que la herramienta de adaptación dinámica de clústeres no puede escalar verticalmente el clúster.

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

Los mensajes de motivo del aprovisionamiento automático de nodos de nivel superior de los eventos noScaleUp aparecen en el campo noDecisionStatus.noScaleUp.napFailureReason. El mensaje contiene un motivo de nivel superior por el que la herramienta de adaptación dinámica del clúster no puede aprovisionar nuevos grupos de nodos.

Motivos a nivel de MIG de NoScaleUp

Los mensajes de motivo a nivel de MIG de 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 la herramienta de escalado automático de clústeres no puede aumentar el tamaño de un MIG concreto.

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

Los mensajes de motivo del aprovisionamiento automático de nodos a nivel de grupo de pods para eventos noScaleUp aparecen en el campo noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[]. El mensaje contiene el motivo por el que la herramienta de adaptación dinámica del clúster no puede aprovisionar un nuevo grupo de nodos para programar un grupo de pods concreto.

Llevar a cabo una investigación más exhaustiva

En las siguientes secciones se explica cómo usar el Explorador de registros y gcpdiag para obtener más información sobre los errores.

Investigar errores en el explorador de registros

Si quieres investigar más a fondo 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 a Explorador de registros

2. En el panel de consulta, introduce la siguiente consulta:

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

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

3. Haz clic en Realizar una consulta.

Depurar algunos errores con gcpdiag

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

Si has recibido 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 ver una lista y una descripción de todas las marcas de herramientas de gcpdiag, consulta las gcpdiag instrucciones de uso.

Resolver errores complejos de ampliación

En las siguientes secciones se ofrecen directrices para resolver errores en los que las mitigaciones implican varios pasos y errores que no tienen asociado ningún mensaje de evento de escalado automático de clúster.

Problema: el pod no cabe en el nodo

La herramienta de adaptación dinámica de clústeres solo programa un pod en un nodo si este tiene suficientes recursos, como GPUs, memoria y almacenamiento, para satisfacer los requisitos del pod. Para determinar si este es el motivo por el que la herramienta de adaptación dinámica de clústeres no ha escalado verticalmente, compara las solicitudes de recursos con los recursos proporcionados.

En el siguiente ejemplo se muestra cómo comprobar 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, sigue estos pasos:

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

   Ve 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, empieza por el primero y repite el siguiente proceso con cada uno de ellos.

4. En la página de detalles del pod, ve a la pestaña Eventos.

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

6. Anota las solicitudes de recursos de cada contenedor del pod para saber cuál es el total de solicitudes de recursos. Por ejemplo, en la siguiente configuración de 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 Trusted Cloud consola, ve a la página Clústeres de Kubernetes.

      Ir a clústeres de Kubernetes

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

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

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

9. Compara la solicitud de recursos con las vCPUs que proporciona el tipo de máquina. Por ejemplo, si un pod solicita 2 vCPUs, pero los nodos disponibles tienen el tipo de máquina n1-standard-1, los nodos solo tendrían 1 vCPU. Con una configuración como esta, la herramienta de adaptación dinámica del clúster no activaría el escalado vertical, ya que, aunque añadiera un nuevo nodo, este pod no cabría en él. Si quieres obtener más información sobre los tipos de máquinas disponibles, consulta la guía de recursos y comparación de familias de máquinas en la documentación de Compute Engine.

También debes tener en cuenta que los recursos asignables de un nodo son inferiores a 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 de los nodos.

Para solucionar este problema, decida si las solicitudes de recursos definidas para la carga de trabajo se ajustan a sus 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 procedente 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 escalado vertical

Es posible que la herramienta de adaptación dinámica de clústeres no aumente la escala si considera que un clúster no está en buen estado. El mal estado de un 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, la herramienta de adaptación dinámica de clústeres detiene todas las operaciones.

Si este es el motivo por el que la herramienta de adaptación dinámica de clústeres no se escala verticalmente, hay un evento en el ConfigMap de la herramienta de adaptación dinámica 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 solucionar este problema, reduzca el número de nodos incorrectos.

También es posible que algunos de los nodos estén listos, aunque el escalador automático de clústeres no los considere como tal. Esto ocurre cuando un taint con el prefijo ignore-taint.cluster-autoscaler.kubernetes.io/ está presente en un nodo. La herramienta de ajuste automático de escala del clúster considera que un nodo está NotReady mientras esté presente ese taint.

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

Siguientes pasos

• Consulta las preguntas frecuentes sobre el autoescalador de clústeres de Kubernetes.

• Ve un vídeo de YouTube sobre cómo solucionar problemas de escalado.

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

  • Abrir un caso de asistencia poniéndose en contacto con el equipo de Atención al Cliente de Cloud.
  • Obtener asistencia de la comunidad haciendo preguntas en Stack Overflow y usando la etiqueta google-kubernetes-engine para buscar problemas similares. También puedes unirte al #kubernetes-enginecanal de Slack para obtener más ayuda de la comunidad.
  • Abrir errores o solicitudes de funciones mediante el seguimiento de problemas público.