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

Si tus nodos de Google Kubernetes Engine (GKE) no se reducen como se espera, suele deberse a que el escalador automático de clústeres no puede eliminarlos, lo que conlleva costes innecesarios y un uso ineficiente de los recursos.

Use esta página para diagnosticar y resolver problemas habituales que impiden que el escalado automático de clústeres se reduzca. Solucionar estos problemas ayuda a que tu clúster funcione de forma rentable y se adapte a los cambios en la carga de trabajo.

Esta información es importante para los administradores y operadores de la plataforma responsables de la eficiencia de los clústeres, la optimización de costes y la gestión de recursos. Los desarrolladores de aplicaciones también pueden necesitar esta información si sus configuraciones de carga de trabajo (como PodDisruptionBudgets o selectores de nodos) impiden que se eliminen nodos sin querer. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Cloud de Confiance by S3NS

Entender cuándo reduce la escala de los nodos la herramienta de adaptación dinámica de clústeres

Antes de seguir los pasos para solucionar el problema, puede ser útil saber cuándo intentará la herramienta de escalado automático de clúster reducir el tamaño de tus nodos. Puede que la herramienta de adaptación dinámica de clústeres no haya reducido la escala porque no era necesario.

La herramienta de ajuste automático de escala del clúster determina si un nodo está infrautilizado y si se puede reducir su escala calculando un factor de utilización. El factor de utilización se calcula dividiendo la vCPU y la memoria solicitadas por los pods del nodo entre la vCPU y la memoria asignables del nodo.

Cada 10 segundos, la herramienta de escalado automático de clústeres comprueba el factor de utilización de tus nodos para ver si está por debajo del umbral necesario. Si usas un balanced perfil de escalado automático, el umbral del factor de utilización es 0,5. Si usas el perfil optimize-utilization, el factor de utilización varía. Si el factor de utilización es inferior al umbral necesario tanto para la vCPU como para la memoria, el autoescalador de clústeres considera que el nodo está infrautilizado.

Cuando un nodo está infrautilizado, el autoescalador de clústeres lo marca para eliminarlo y lo monitoriza durante los 10 minutos siguientes para asegurarse de que el factor de utilización se mantiene por debajo del umbral requerido. Si el nodo sigue estando infrautilizado después de 10 minutos, la herramienta de escalado automático de clústeres debería eliminarlo.

Ejemplo: cálculo del factor de utilización

Tienes un clúster con la herramienta de adaptación dinámica de clústeres habilitada y usas el balancedperfil de autoescalado. Un nodo de este clúster se aprovisiona con el tipo de máquina e2-standard-4, que ofrece 4 vCPUs y 16 GB de memoria. Un pod de este nodo solicita 0,5 vCPUs y 10 GB de memoria, por lo que el autoescalador de clúster calcula los siguientes factores de utilización:

• Factor de utilización de vCPU: 0,5 vCPU / 4 vCPUs = 0,125
• Factor de utilización de la memoria: 10 GB / 16 GB = 0,625

En este caso, el autoescalador de clústeres no consideraría que este nodo está infrautilizado porque el factor de utilización de la memoria (0,625) supera el umbral de 0,5. Aunque la utilización de la vCPU sea baja, el mayor uso de memoria impide reducir la escala para asegurar que haya suficientes recursos disponibles para la carga de trabajo del pod.

Comprobar si el problema se debe a una limitación

Si observas que un clúster tiene una utilización baja durante más de 10 minutos y no se reduce, asegúrate de que el problema no se deba a una de las limitaciones de la herramienta de ajuste automático de escala de clústeres.

Ver errores

Si el problema no se debe a una limitación, a menudo puede diagnosticar la causa consultando los mensajes de error:

• Si ya has visto un mensaje de error, consulta la tabla de mensajes de error para obtener consejos 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 Cloud de Confiance consola.
  • 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 Cloud de Confiance consola. Estas notificaciones proporcionan información valiosa sobre por qué no se ha reducido el tamaño del clúster 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 Cloud de Confiance , sigue estos pasos:

1. En la Cloud de Confiance 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 reducción de escala:

   • Can't scale down nodes
   • Scale down blocked by pod

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 al 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 reducción, consulta Ver los eventos de la herramienta de escalado automático de clústeres.

Si sigues teniendo problemas después de revisar 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 ocurrió 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 Cloud de Confiance consola, sigue estos pasos:

1. En la Cloud de Confiance 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 reducción, consulta Ver eventos de la herramienta de ajuste automático de escala 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 reduce.

Situación:

Hace una semana, consultaste el panel de control de GKE Enterprise y te diste cuenta de que tu clúster solo había utilizado el 10% de su CPU y su memoria. A pesar del bajo uso, la herramienta de adaptación dinámica de clústeres no ha eliminado el nodo como esperabas. Ahora que consultas el panel de control, parece que el problema se ha resuelto, pero quieres saber qué ha pasado para evitar que vuelva a ocurrir.

Investigació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. Busca scaleDown eventos que contengan los nodos del clúster que estás investigando en el campo nodesToBeRemoved. Puedes filtrar las entradas de registro, incluso por el valor de un campo JSON concreto. Consulta más información en Consultas de registros avanzadas.
4. No encuentras ningún evento de scaleDown. Sin embargo, si has encontrado un evento scaleDown, puedes buscar un evento eventResult que contenga el eventId asociado. Después, puedes buscar un error en el campo errorMsg.

5. Decides continuar con tu investigación buscando eventos de noScaleDown que tengan el nodo que estás investigando en el campo de nodos.

   Busca un evento noScaleDown que contenga el motivo por el que tu nodo no se ha reducido. El ID del mensaje es "no.scale.down.node.pod.not.backed.by.controller" y hay un solo parámetro: "test-single-pod".

Resolución:

Consultas la tabla de mensajes de error y ves que este mensaje significa que el pod está bloqueando la reducción vertical porque no está respaldado por un controlador. Descubres que una solución es añadir una anotación "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" al Pod. Investigas test-single-pod y ves que un compañero ha añadido la anotación y, después de aplicarla, la herramienta de ajuste automático de escala del clúster ha reducido la escala del clúster correctamente. Decides añadir la anotación a todos los demás Pods en los que sea seguro hacerlo para evitar que vuelva a ocurrir el problema.

Resolver errores de reducción de tamaño

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

Errores de ScaleDown

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

Motivos de un evento noScaleDown

Un evento noScaleDown se emite periódicamente cuando hay nodos a los que la herramienta de escalado automático de clústeres no puede eliminar. Los eventos noScaleDown se realizan de la mejor forma posible y no cubren todos los casos posibles.

Motivos de nivel superior de NoScaleDown

Los mensajes de motivo de nivel superior de los eventos noScaleDown se muestran en el campo noDecisionStatus.noScaleDown.reason. El mensaje contiene un motivo de nivel superior por el que el escalador automático de clústeres no puede reducir el tamaño del clúster.

Motivos a nivel de nodo de NoScaleDown

Los mensajes de motivo a nivel de nodo de los eventos noScaleDown aparecen en noDecisionStatus.noScaleDown.nodes[].reason field. El mensaje contiene un motivo por el que el autoescalador de clústeres no puede eliminar un nodo 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, puedes ver los registros específicos del error:

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

   Ir a Explorador de registros

2. En el panel de consultas, escribe 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.down.error.failed.to.delete.node.min.size.reached.

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 Cloud de Confiance by S3NS. No es un producto con asistencia oficial. Cloud de Confiance by S3NS

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

• scale.down.error.failed.to.evict.pods
• no.scale.down.node.node.group.min.size.reached

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

Resolver errores complejos de reducció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.

Error: Los nodos del clúster han alcanzado el tamaño mínimo

Si ves los siguientes errores, significa que la herramienta de ajuste automático de escala del clúster no ha podido eliminar un nodo porque el número de nodos del clúster ya era el mínimo:

"scale.down.error.failed.to.delete.node.min.size.reached"

Para solucionar este problema, revise y actualice los límites mínimos del autoescalado:

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

   Ir a clústeres de Kubernetes

2. Haga clic en el nombre del clúster identificado en la notificación o en Cloud Logging.

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

4. Revisa el valor de la columna Número de nodos y compáralo con el número mínimo de nodos que aparece en la columna Autoescalado. Por ejemplo, si ves entre 4 y 6 nodos en la columna Autoescalado y el número de nodos del grupo de nodos es 4, el número de grupos de nodos ya es igual al tamaño mínimo, por lo que el autoescalador de clústeres no puede reducir más los nodos.

5. Si la configuración es correcta y el valor del número de nodos es igual al mínimo definido para Autoscaling, el escalador automático de clústeres funciona correctamente. Si el número mínimo de nodos es demasiado alto para tus necesidades, reduce el tamaño mínimo para que los nodos puedan reducirse.

Error: No hay espacio para mover los pods

Los siguientes errores se producen cuando la herramienta de adaptación dinámica de clústeres intenta reducir verticalmente un nodo, pero no puede porque un pod de ese nodo no se puede mover a otro nodo:

"no.scale.down.node.no.place.to.move.pods"

Si no quieres que se reprograme esta conversación con Pod, este mensaje es el esperado y no tienes que hacer nada. Si quieres que se vuelva a programar el pod, investiga las siguientes definiciones en el pod.spec block del manifiesto del pod:

• NodeAffinity revisa los requisitos de programación de los pods del nodo infrautilizado. Puedes consultar estos requisitos examinando el manifiesto de Pod y buscando reglas de NodeAffinity o NodeSelector. Si el pod tiene un campo nodeSelector definido y no hay otros nodos (de otros grupos de nodos) en el clúster que coincidan con este selector, la herramienta de ajuste automático de escala del clúster no podrá mover el pod a otro nodo, lo que a su vez le impedirá eliminar los nodos infrautilizados.
• maxPodConstraint: si maxPodConstraint se ha configurado con un número distinto del predeterminado (110), confirma si se trata de un cambio intencionado. Si se reduce este valor, es más probable que se produzcan problemas. La herramienta de ajuste automático de escala del clúster no puede reprogramar pods en otros nodos si todos los demás nodos del clúster ya han alcanzado el valor definido en maxPodConstraint, por lo que no hay espacio para programar nuevos pods. Si aumentas el valor de maxPodConstraint, se podrán programar más pods en los nodos y el autoescalador de clúster tendrá espacio para reprogramar los pods y reducir la escala de los nodos infrautilizados. Cuando definas maxPodConstraint, ten en cuenta que hay aproximadamente 10 pods del sistema en cada nodo.
• hostPort: si se especifica un hostPort para el pod, solo se podrá ejecutar un pod en ese nodo. Esto puede dificultar que el escalador automático de clústeres reduzca el número de nodos, ya que es posible que el pod no pueda moverse a otro nodo si el puerto de ese nodo ya está en uso. Es completamente normal.
• Almacenamiento efímero: los pods dependen del almacenamiento efímero para los datos temporales. Si los nodos no tienen suficiente almacenamiento efímero, se puede impedir la programación de pods y la reducción de los nodos infrautilizados. Ejemplo: Un pod que requiere 6 GB de almacenamiento efímero no se puede programar en nodos con menos de 6 GB de almacenamiento efímero libre, aunque tengan suficientes recursos de CPU y memoria. Para mitigar las limitaciones del almacenamiento efímero, aumenta la capacidad de almacenamiento efímero aprovisionada de tus nodos. De esta forma, se asegura que haya capacidad suficiente para las operaciones de reubicación y escalado de pods.

Error: no se puede mover el pod kube-system

Se producen los siguientes errores cuando un pod del sistema impide la reducción:

"no.scale.down.node.pod.kube.system.unmovable"

Los pods del espacio de nombres kube-system se consideran pods del sistema. En la versión 1.32.4-gke.1236000 de GKE y posteriores, el autoescalador de clústeres puede reducir el número de nodos desalojando los pods del sistema que se hayan ejecutado durante al menos una hora. En versiones anteriores de GKE, el autoescalador de clústeres no elimina los pods del espacio de nombres kube-system, lo que puede impedir que se reduzca indefinidamente.

Para solucionar este error, elija una de las siguientes opciones:

• Añade un PodDisruptionBudget para los pods de kube-system. Para obtener más información sobre cómo añadir manualmente un PodDisruptionBudget a los pods kube-system, consulta las preguntas frecuentes sobre la herramienta de escalado automático de clústeres de Kubernetes.

  Crear un PodDisruptionBudget puede afectar a la disponibilidad de las cargas de trabajo del sistema, lo que puede provocar un tiempo de inactividad en el clúster. La herramienta de adaptación dinámica de clústeres reprograma estas cargas de trabajo del sistema en diferentes nodos de trabajo durante el proceso de reducción.

• Usa una combinación de tolerancias y taints de grupos de nodos para separar los pods de kube-system de los pods de tu aplicación. Para obtener más información, consulta Aprovisionamiento automático de nodos en GKE.

Verifica que los nodos tengan kube-system pods.

Si no sabes con certeza si tus nodos están ejecutando pods kube-system y quieres verificarlo, sigue estos pasos:

1. Ve a la página Explorador de registros de la consola de Cloud de Confiance .

   Ir a Explorador de registros

2. Haz clic en Creador de consultas.

3. Usa la siguiente consulta para encontrar todos los registros de políticas de red:

   - resource.labels.location="CLUSTER_LOCATION"
   resource.labels.cluster_name="CLUSTER_NAME"
   logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
   jsonPayload.noDecisionStatus.noScaleDown.nodes.node.mig.nodepool="NODE_POOL_NAME"
   

   Haz los cambios siguientes:

   • CLUSTER_LOCATION: la región en la que se encuentra tu clúster.
   • CLUSTER_NAME: el nombre del clúster.
   • PROJECT_ID: el ID del proyecto al que pertenece tu clúster.
   • NODE_POOL_NAME: el nombre del grupo de nodos.

   Si hay kube-system pods en ejecución en tu grupo de nodos, el resultado incluye lo siguiente:

   "no.scale.down.node.pod.kube.system.unmovable"
   

Error: no hay suficientes PodDisruptionBudget

Se producen los siguientes errores cuando PodDisruptionBudget impide la reducción:

NoScaleDownNodePodNotEnoughPdb: "no.scale.down.node.pod.not.enough.pdb"

Para comprobar si una PodDisruptionBudget es demasiado restrictiva, revisa su configuración:

kubectl get pdb --all-namespaces

El resultado debería ser similar al siguiente:

NAMESPACE        NAME    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       N/A             1                 1               12d
example-app-two  two_pdb       N/A             0                 0               12d

En este ejemplo, el escalador automático de clústeres no expulsará ningún pod que coincida con el selector de etiquetas two_pdb. El ajuste maxUnavailable: 0 de este PodDisruptionBudget indica que todas las réplicas deben estar disponibles en todo momento. Además, disruptionsAllowed: 0 prohíbe cualquier interrupción de estos pódcasts. Por lo tanto, los nodos que ejecutan estos pods no se pueden reducir, ya que esto provocaría una interrupción e infringiría el PodDisruptionBudget.

Si tu PodDisruptionBudget funciona como quieres, no tienes que hacer nada más. Si quieres ajustar tu PodDisruptionBudget para que los pods de un nodo infrautilizado se puedan mover, edita el manifiesto del PodDisruptionBudget. Por ejemplo, si has definido maxUnavailable como 0, puedes cambiarlo a 1 para que la herramienta de ajuste automático de escala del clúster pueda reducir la escala.

Problema: El nodo permanece en estado de acordonamiento y no se elimina

Se producen errores similares a los siguientes cuando el escalador automático de clústeres no puede reducir el tamaño del grupo de nodos porque la cuenta de servicio de Google no tiene el rol Editor:

Required 'compute.instanceGroups.update' permission for 'INSTANCE_GROUP_NAME'.

Un síntoma habitual de este problema es que la herramienta de adaptación dinámica del clúster intenta reducir el tamaño del grupo de nodos, pero el nodo no cambia de estado.

Para solucionar este problema, comprueba si la cuenta de servicio predeterminada (PROJECT_NUMBER@cloudservices.s3ns-system.iam.gserviceaccount.com) tiene el rol Editor (roles/editor) en el proyecto. Si la cuenta de servicio no tiene este rol, añádelo. GKE usa esta cuenta de servicio para gestionar los recursos de tu proyecto. Para saber cómo hacerlo, consulta el artículo Conceder o revocar un solo rol de la documentación de gestión de identidades y accesos.

Siguientes pasos

• Consulta las siguientes preguntas en las preguntas frecuentes sobre la herramienta de adaptación dinámica de clústeres de Kubernetes:

  • ¿Cómo funciona la reducción de escala?
  • ¿La herramienta de adaptación dinámica de clústeres funciona con PodDisruptionBudget en la reducción de escala?
  • ¿Qué tipos de pods pueden impedir que la herramienta de escalado automático de clústeres elimine un nodo?

• Ver 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.