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


En esta página, se muestra cómo diagnosticar y resolver problemas que impiden que el escalador automático de clústeres reduzca los nodos 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 reduce 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 reducir la escala verticalmente de tus nodos. Es posible que el escalador automático de clústeres no haya reducido la escala verticalmente porque no era necesario.

El escalador automático de clústeres determina si un nodo tiene poco uso y es apto para reducir la escala mediante el cálculo de un factor de uso. Para calcular el factor de uso, se divide la CPU virtual y la memoria que solicitan los pods en el nodo por la CPU virtual y la memoria asignables en el nodo.

Cada 10 segundos, el escalador automático de clústeres verifica el factor de utilización de tus nodos para ver si está por debajo del umbral requerido. Si usas un perfil de ajuste de escala automático de balanced, el umbral del factor de utilización es 0.5. Si usas el perfil optimize-utilization, el factor de utilización varía. Cuando el factor de uso es inferior al umbral requerido para la CPU virtual y la memoria, el escalador automático del clúster considera que el nodo no se usa lo suficiente.

Cuando un nodo tiene un uso insuficiente, el escalador automático del clúster lo marca para quitarlo y lo supervisa durante los próximos 10 minutos para asegurarse de que el factor de uso permanezca por debajo del umbral requerido. Si el nodo sigue teniendo poco uso después de 10 minutos, el escalador automático del clúster debería quitarlo.

Ejemplo: Cálculo del factor de utilización

Tienes un clúster con el escalador automático habilitado y usas el perfil de ajuste de escala automático balanced. Un nodo de este clúster se aprovisiona con el tipo de máquina e2-standard-4, que ofrece 4 CPU virtuales y 16 GB de memoria. Un pod en este nodo solicita 0.5 vCPU y 10 GB de memoria, por lo que el escalador automático del clúster calcula los siguientes factores de uso:

  • Factor de uso de CPU virtual: 0.5 vCPU / 4 vCPU = 0.125
  • Factor de uso de memoria: 10 GB / 16 GB = 0.625

En esta situación, el escalador automático del clúster no consideraría que este nodo está subutilizado porque el factor de utilización de la memoria (0.625) supera el umbral de 0.5. Aunque el uso de la CPU virtual es bajo, el uso de memoria más alto evita la reducción de la escala verticalmente para garantizar que haya suficientes recursos disponibles para la carga de trabajo del pod.

Comprueba si el problema se debe a una limitación

Si observas un clúster con 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 del escalador automático de clústeres.

Ver errores

Si el problema no se debe a una limitación, a menudo puedes diagnosticar la causa 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 consola de Google Cloud . Estas notificaciones proporcionan estadísticas valiosas sobre por qué el escalador automático de clústeres no redujo la escala verticalmentey 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 , ve 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 reducción de la escala verticalmente:

    • Can't scale down nodes
    • Scale down blocked by pod
  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 reducción de la escala verticalmente, 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 , ve 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 reducción 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 reduce.

Situación:

Hace una semana, revisaste el panel de GKE Enterprise y notaste que tu clúster solo usó el 10% de su CPU y memoria. A pesar del bajo uso, el escalador automático de clústeres no borró el nodo como esperabas. Cuando miras el panel ahora, parece que el problema se resolvió, pero decides averiguar qué sucedió para evitar que vuelva a ocurrir.

Investigació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 scaleDown que contengan los nodos que pertenecen al clúster que estás investigando en el campo nodesToBeRemoved. 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 scaleDown. Sin embargo, si encontraste un evento scaleDown, puedes buscar un evento eventResult que contenga el eventId asociado. Luego, puedes buscar un error en el campo errorMsg.
  5. Decides continuar con la investigación y buscas eventos noScaleDown que tengan el nodo que estás investigando en el campo de nodos.

    Encontraste un evento noScaleDown que contiene un motivo por el que tu nodo no se reduce. 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 descubres que este mensaje significa que el pod está bloqueando la reducción de la escala verticalmente porque no está respaldado por un controlador. Descubres que una solución es agregar una anotación "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" al pod. Investigas test-single-pod y ves que un colega agregó la anotación y, después de aplicarla, el escalador automático de clústeres redujo la escala correctamente. Decides agregar la anotación a todos los demás Pods en los que sea seguro hacerlo para evitar que el problema vuelva a ocurrir.

Cómo resolver errores de reducción vertical de la escala

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

Errores de scaleDown

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

Mensaje del evento Detalles Parámetro Mitigación
"scale.down.error.failed.to.mark.to.be.deleted" No se pudo marcar un nodo para su eliminación. Nombre del nodo con errores. Este mensaje debe ser transitorio. Si persiste, comunícate con Atención al cliente de Cloud para realizar una investigación más detallada.
"scale.down.error.failed.to.evict.pods" El escalador automático de clústeres no puede reducir la escala verticalmente porque algunos de los pods no se pudieron expulsar de un nodo. Nombre del nodo con errores. Revisa la PodDisruptionBudget del Pod y asegúrate de que las reglas permitan la expulsión de las réplicas de la aplicación cuando sea aceptable. Para obtener más información, consulta Especifica un presupuesto de interrupción para tu aplicación en la documentación de Kubernetes.
"scale.down.error.failed.to.delete.node.min.size.reached" El escalador automático del clúster no puede reducir la escala verticalmente porque no se pudo borrar un nodo debido a que el clúster ya tenía el tamaño mínimo. Nombre del nodo con errores. Revisa el valor mínimo establecido para el ajuste de escala automático de grupos de nodos y ajusta la configuración según sea necesario. Para obtener más información, consulta el artículo Error: Los nodos del clúster alcanzaron el tamaño mínimo.

Motivos de un evento noScaleDown

Un evento noScaleDown se emite de forma periódica cuando hay nodos bloqueados para que el escalador automático de clústeres no los borre. Los eventos noScaleDown se basan en el mejor esfuerzo y no abarcan todos los casos posibles.

Motivos de nivel superior de noScaleDown

Los mensajes de motivo de nivel superior para los eventos noScaleDown aparecen 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 la escala del clúster.

Mensaje del evento Detalles Mitigación
"no.scale.down.in.backoff" El escalador automático de clústeres no puede reducir la escala verticalmente porque el proceso se encuentra en un período de retirada (bloqueado temporalmente).

Este mensaje debe ser transitorio y puede ocurrir cuando se produjo un evento de escalamiento vertical reciente.

Si el mensaje persiste, comunícate con Atención al cliente de Cloud para realizar una investigación más detallada.

"no.scale.down.in.progress"

El escalador automático de clúster no puede reducir la escala verticalmente porque una reducción anterior todavía estaba en curso.

Este mensaje debe ser transitorio, ya que el Pod se quitará de manera forzada. Si este mensaje aparece con frecuencia, revisa el período de gracia de finalización para la reducción de escala verticalmente de bloqueo de los Pods. Para acelerar la resolución, también puedes borrar el Pod si ya no es necesario.

Motivos de nivel de nodo de noScaleDown

Los mensajes de motivo de nivel de nodo para los eventos noScaleDown aparecen en el noDecisionStatus.noScaleDown.nodes[].reason field. El mensaje contiene un motivo por el que el escalador automático de clústeres no puede quitar un nodo en particular.

Mensaje del evento Detalles Parámetros Mitigación
"no.scale.down.node.scale.down.disabled.annotation" El escalador automático de clústeres no puede quitar un nodo del grupo de nodos porque está anotado con cluster-autoscaler.kubernetes.io/scale-down-disabled: true. N/A El escalador automático de clústeres omite los nodos con esta anotación sin considerar su uso, y este mensaje se registra independientemente del factor de uso del nodo. Si deseas que el escalador automático del clúster reduzca la escala verticalmente de estos nodos, quita la anotación.
"no.scale.down.node.node.group.min.size.reached"

El escalador automático de clústeres no puede reducir la escala verticalmente cuando el tamaño del grupo de nodos supera el límite de tamaño mínimo.

Esto sucede porque quitar nodos infringiría los límites de recursos mínimos de todo el clúster definidos en la configuración de aprovisionamiento automático de nodos.

N/A Revisa el valor mínimo establecido para el ajuste de escala automático del grupo de nodos. Si deseas que el escalador automático del clúster reduzca la escala verticalmente de este nodo, ajusta el valor mínimo.
"no.scale.down.node.minimal.resource.limits.exceeded"

El escalador automático del clúster no puede reducir la escala verticalmente de los nodos porque infringiría los límites mínimos de recursos en todo el clúster.

Estos son los límites de recursos establecidos para el aprovisionamiento automático de nodos.

N/A Revisa los límites de memoria y CPU virtual y, si deseas que el escalador automático del clúster reduzca la escala verticalmente de este nodo, disminuye los límites.
"no.scale.down.node.no.place.to.move.pods" El escalador automático de clústeres no puede reducir la escala verticalmente porque no hay lugar para mover los Pods. N/A Si esperas que el Pod se reprograme, revisa los requisitos de programación de los Pods en el nodo con poco uso para determinar si se pueden mover a otro nodo del clúster. Para obtener más información, consulta el error "No place to move Pods".
"no.scale.down.node.pod.not.backed.by.controller"

El Pod bloquea la reducción de escala vertical porque no está respaldado por un controlador.

Específicamente, el escalador automático de clústeres no puede reducir la escala verticalmente de un nodo con poco uso debido a un Pod que no tiene un controlador reconocido. Los controladores permitidos incluyen ReplicationController, DaemonSet, Job, StatefulSet o ReplicaSet.

Es el nombre del Pod que causa el bloqueo. Configura la anotación "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para el Pod o define un controlador aceptable.
"no.scale.down.node.pod.not.safe.to.evict.annotation" Un Pod en el nodo tiene la anotación safe-to-evict=false. Es el nombre del Pod que causa el bloqueo. Si el Pod puede expulsarse de forma segura, edita el manifiesto del Pod y actualiza la anotación a "cluster-autoscaler.kubernetes.io/safe-to-evict": "true".
"no.scale.down.node.pod.kube.system.unmovable" El Pod está bloqueando la reducción de escala vertical porque es un Pod sin DaemonSet, duplicados y sin un PodDisruptionBudget en el espacio de nombres kube-system. Es el nombre del Pod que causa el bloqueo.

De forma predeterminada, el escalador automático de clústeres no quita los pods del espacio de nombres kube-system.

Para resolver este problema, agrega un PodDisruptionBudget para los Pods kube-system o usa una combinación de taints y tolerancias de grupos de nodos para separar los Pods kube-system de los de tu aplicación. Para obtener más información, consulta Error: No se puede mover el Pod de kube-system.

"no.scale.down.node.pod.not.enough.pdb" El Pod está bloqueando la reducción vertical de la escala porque no tiene suficiente presupuesto de interrupción. Es el nombre del Pod que causa el bloqueo. Revisa la PodDisruptionBudget del Pod y considera hacerla menos restrictiva. Para obtener más información, consulta Error: No hay suficientes PodDisruptionBudget.
"no.scale.down.node.pod.controller.not.found" El Pod está bloqueando la reducción de escala vertical porque no se puede encontrar su controlador (por ejemplo, un Deployment o ReplicaSet). N/A Para determinar qué acciones se llevaron a cabo y que dejaron el Pod en ejecución después de quitar su controlador, revisa los registros. Para resolver este problema, borra el Pod de forma manual.
"no.scale.down.node.pod.unexpected.error" El Pod bloquea la reducción de escala vertical debido a un error inesperado. N/A Se desconoce la causa raíz de este error. Comunícate con Atención al cliente de Cloud para realizar una investigación más detallada.

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, puedes ver los registros específicos de tu error:

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

    Ir 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.down.error.failed.to.delete.node.min.size.reached

  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.down.error.failed.to.evict.pods
  • no.scale.down.node.node.group.min.size.reached

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 reducción 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.

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

Si ves los siguientes errores, significa que el escalador automático del clúster no pudo borrar un nodo porque la cantidad de nodos en el clúster ya tenía el tamaño mínimo:

Notificación

Se bloqueó la reducción de escala vertical de un nodo con poco uso porque se alcanzaron los límites de recursos mínimos del escalador automático del clúster.

Evento

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

Para resolver este problema, revisa y actualiza los límites mínimos del ajuste de escala automático:

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

    Ir a clústeres de Kubernetes

  2. Haz 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, ve a la pestaña Nodos.

  4. Revisa el valor de la columna Cantidad de nodos y compáralo con la cantidad mínima de nodos que aparece en la columna Ajuste de escala automático. Por ejemplo, si ves entre 4 y 6 nodos en la columna Ajuste de escala automático y la cantidad de nodos en el grupo es 4, la cantidad de grupos de nodos ya es igual al tamaño mínimo, por lo que el escalador automático de clústeres no puede reducir la escala verticalmente de los nodos.

  5. Si la configuración es correcta y el valor de la cantidad de nodos es igual al mínimo definido para el ajuste de escala automático, el escalador automático del clúster funciona según lo previsto. Si la cantidad mínima de nodos es demasiado alta para tus necesidades, reduce el tamaño mínimo para que los nodos puedan reducir la escala verticalmente.

Error: No hay lugar para mover los Pods

Los siguientes errores se producen cuando el escalador automático de clústeres intenta reducir la escala verticalmente de un nodo, pero no puede hacerlo porque un Pod en ese nodo no se puede mover a otro nodo:

Notificación

Se bloqueó la reducción de escala vertical de un nodo con poco uso porque tiene un Pod que no se puede mover a otro nodo del clúster.

Evento

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

Si no quieres que se reprograme este Pod, se espera este mensaje y no se requieren cambios. Si quieres que se reprograme 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 en el nodo con poco uso. Para revisar estos requisitos, examina el manifiesto del Pod y busca reglas de NodeAffinity o NodeSelector. Si el Pod tiene un nodeSelector definido y no hay otros nodos (de otros grupos de nodos) en el clúster que coincidan con este selector, el escalador automático de clústeres no puede mover el Pod a otro nodo, lo que, a su vez, evita que quite los nodos que no se utilizan lo suficiente.
  • maxPodConstraint: Si maxPodConstraint está configurado en cualquier otro número que no sea el número predeterminado de 110, confirma si este fue un cambio intencional. Si disminuyes este valor, aumenta la probabilidad de que se produzcan problemas. El escalador automático de clústeres no puede reprogramar Pods en otros nodos si todos los demás nodos del clúster ya alcanzaron el valor definido en maxPodConstraint, lo que no deja espacio para programar Pods nuevos. Aumentar el valor de maxPodConstraint permite programar más pods en los nodos, y el escalador automático del clúster tendrá espacio para reprogramar pods y reducir la escala verticalmente de nodos infrautilizados. Cuando definas maxPodConstraint, ten en cuenta que hay aproximadamente 10 Pods del sistema en cada nodo.
  • hostPort: Especificar un hostPort para el Pod significa que solo se puede ejecutar un Pod en ese nodo. Esto puede dificultar que el escalador automático de clústeres reduzca la cantidad 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. Se prevé que esto suceda.

Error: No se puede mover el Pod kube-system

Los siguientes errores ocurren cuando un Pod del sistema evita la reducción de la escala verticalmente:

Notificación

El Pod está bloqueando la reducción de escala vertical porque es un Pod sin DaemonSet, duplicados y sin un PodDisruptionBudget en el espacio de nombres kube-system.

Evento

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

Un Pod en el espacio de nombres kube-system se considera un Pod del sistema. De forma predeterminada, el escalador automático del clúster no quita Pods del espacio de nombres kube-system.

Para resolver este error, elige una de las siguientes resoluciones:

  • Agrega un PodDisruptionBudget para los Pods de kube-system. A fin de obtener más información sobre cómo agregar un PodDisruptionBudget de forma manual para los Pods de kube-system, consulta las Preguntas frecuentes sobre el escalador automático de clústeres de Kubernetes.

    Crear un PodDisruptionBudget puede afectar la disponibilidad de las cargas de trabajo del sistema, lo que puede provocar un tiempo de inactividad en el clúster. El escalador automático del clúster vuelve a programar estas cargas de trabajo del sistema en diferentes nodos de trabajo durante el proceso de reducción de la escala verticalmente.

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

Verifica que los nodos tengan kube-system pods

Si no estás seguro de que tus nodos ejecuten Pods kube-system y quieres verificarlo, completa los siguientes pasos:

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

    Ir al Explorador de registros

  2. Haz clic en Compilador de consultas.

  3. Usa la siguiente consulta para encontrar todos los registros de las 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"
    

    Reemplaza lo siguiente:

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

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

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

Error: No hay suficiente PodDisruptionBudget

Los siguientes errores ocurren cuando tu PodDisruptionBudget impide la escalamiento hacia abajo:

Notificación

Se bloqueó la reducción de escala vertical de un nodo con poco uso porque tiene un Pod en ejecución que no tiene suficiente presupuesto de interrupción del Pod para permitir la expulsión del Pod.

Evento

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

Para ver si un PodDisruptionBudget es demasiado restrictivo, revisa su configuración:

kubectl get pdb --all-namespaces

El resultado es similar a este:

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. La configuración de maxUnavailable: 0 en esta PodDisruptionBudget establece que todas las réplicas deben permanecer disponibles en todo momento. Además, disruptionsAllowed: 0 prohíbe cualquier interrupción en estos pods. En consecuencia, no se puede reducir la escala de los nodos que ejecutan estos Pods, ya que hacerlo provocaría una interrupción y contravendría el PodDisruptionBudget.

Si tu PodDisruptionBudget funciona como deseas, no es necesario que realices ninguna otra acción. Si deseas ajustar tu PodDisruptionBudget para que se puedan mover los Pods de un nodo que se usa poco, edita el manifiesto de la PodDisruptionBudget. Por ejemplo, si configuraste maxUnavailable en 0, puedes cambiarlo a 1 para que el escalador automático del clúster pueda reducir la escala verticalmente.

Problema: El nodo permanece en estado de aislamiento y no se quita

Se producen errores similares al siguiente cuando el escalador automático del clúster no puede reducir el tamaño del grupo de nodos porque la cuenta de servicio de Google no tiene el rol de editor:

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

Un síntoma común de este problema es cuando el escalador automático del clúster intenta reducir el tamaño del grupo de nodos, pero el nodo no cambia de estado.

Para resolver este problema, verifica si la cuenta de servicio predeterminada (PROJECT_NUMBER@cloudservices.gserviceaccount.com) tiene el rol de editor (roles/editor) en el proyecto. Si la cuenta de servicio no tiene este rol, agrégalo. GKE usa esta cuenta de servicio para administrar los recursos de tu proyecto. Para obtener información sobre cómo hacerlo, consulta Otorga o revoca un solo rol en la documentación de IAM.

¿Qué sigue?