Información sobre el autoescalado de clústeres de GKE

En esta página se explica cómo Google Kubernetes Engine (GKE) cambia automáticamente el tamaño de los grupos de nodos de tu clúster estándar en función de la demanda de tus cargas de trabajo. Cuando la demanda es alta, el autoescalador de clústeres añade nodos al grupo de nodos. Para saber cómo configurar la herramienta de adaptación dinámica de clústeres, consulta Adaptar la escala de un clúster automáticamente.

Esta página está dirigida a administradores, arquitectos y operadores que planifican las necesidades de capacidad e infraestructura, y optimizan la arquitectura de los sistemas y los recursos para conseguir el coste total de propiedad más bajo para su empresa o unidad de negocio. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas de usuario habituales de GKE.

Con los clústeres Autopilot, no tienes que preocuparte por aprovisionar nodos ni gestionar grupos de nodos, ya que estos se aprovisionan automáticamente mediante el aprovisionamiento automático de nodos y se escalan automáticamente para satisfacer los requisitos de tus cargas de trabajo.

Antes de leer esta página, asegúrate de que conoces los conceptos básicos de Kubernetes y cómo funcionan las solicitudes y los límites de recursos.

Práctica recomendada:

Planifica y diseña la configuración de tu clúster con los administradores y arquitectos, desarrolladores u otro equipo de tu organización que se encargue de implementar y mantener tu aplicación.

Por qué usar la herramienta de adaptación dinámica de clústeres

La función de autoescalado de clústeres de GKE cambia automáticamente el tamaño del número de nodos de un grupo de nodos determinado en función de las demandas de tus cargas de trabajo. Cuando la demanda es baja, la herramienta de escalado automático de clústeres reduce el tamaño hasta el mínimo que hayas designado. De esta forma, puedes aumentar la disponibilidad de tus cargas de trabajo cuando lo necesites y, al mismo tiempo, controlar los costes. No es necesario añadir ni quitar nodos manualmente, ni aprovisionar en exceso los grupos de nodos. En su lugar, especifica un tamaño mínimo y máximo para el grupo de nodos, y el resto se hace automáticamente.

Si se eliminan o se mueven recursos al autoescalar el clúster, es posible que tus cargas de trabajo sufran interrupciones transitorias. Por ejemplo, si tu carga de trabajo consta de un controlador con una sola réplica, el pod de esa réplica se puede reprogramar en otro nodo si se elimina el nodo actual. Antes de habilitar el escalador automático de clústeres, diseña tus cargas de trabajo para que toleren posibles interrupciones o asegúrate de que los pods críticos no se interrumpan.

Práctica recomendada:

Para aumentar la tolerancia a las interrupciones de tu carga de trabajo, despliégala con un controlador que tenga varias réplicas, como un Deployment.

Puedes aumentar el rendimiento del autoescalador de clústeres con Image streaming, que distribuye de forma remota los datos de imagen necesarios de las imágenes de contenedor aptas y, al mismo tiempo, almacena en caché la imagen de forma local para que las cargas de trabajo de los nodos nuevos se inicien más rápido.

Cómo funciona la herramienta de adaptación dinámica de clúster

La herramienta de adaptación dinámica de clústeres funciona por grupo de nodos. Cuando configuras un grupo de nodos con el autoescalador de clústeres, especificas un tamaño mínimo y máximo para el grupo de nodos.

La herramienta de escalado automático de clústeres aumenta o reduce el tamaño del grupo de nodos automáticamente añadiendo o eliminando instancias de máquina virtual (VM) en el grupo de instancias gestionado (MIG) de Compute Engine subyacente del grupo de nodos. La herramienta de adaptación dinámica de clústeres toma estas decisiones de escalado en función de las solicitudes de recursos (en lugar de la utilización real de los recursos) de los pods que se ejecutan en los nodos de ese grupo de nodos. Comprueba periódicamente el estado de los pods y los nodos, y toma medidas:

  • Si no se pueden programar pods en ninguno de los nodos actuales, la herramienta de escalado automático de clústeres añade nodos hasta alcanzar el tamaño máximo del grupo de nodos. Para obtener más información sobre cuándo cambia el tamaño de un clúster la herramienta de adaptación dinámica de clústeres, consulta ¿Cuándo cambia el tamaño de un clúster la herramienta de adaptación dinámica de clústeres?
  • Si GKE decide añadir nodos al grupo de nodos, el escalador automático del clúster añade tantos nodos como sea necesario, hasta los límites por grupo de nodos o por clúster.
  • La herramienta de ajuste automático de escala de clústeres no espera a que se inicie un nodo para crear el siguiente. Una vez que GKE decide cuántos nodos crear, la creación de nodos se realiza en paralelo. El objetivo es minimizar el tiempo necesario para que los pods no programables pasen a estar en estado Active.
  • Si no se crean algunos nodos porque se ha alcanzado el límite de cuota, la herramienta de ajuste automático de escala del clúster espera hasta que se puedan programar los recursos correctamente.
  • Si los nodos están infrautilizados y todos los pods se pueden programar incluso con menos nodos en el grupo de nodos, la herramienta de escalado automático de clústeres elimina nodos hasta alcanzar el tamaño mínimo del grupo de nodos. Si hay pods en un nodo que no se pueden mover a otros nodos del clúster, la herramienta de adaptación dinámica de clústeres no intentará reducir el tamaño de ese nodo. Si los pods se pueden mover a otros nodos, pero el nodo no se puede drenar correctamente después de un periodo de tiempo de espera (actualmente, 10 minutos), el nodo se termina de forma forzada. El periodo de gracia no se puede configurar en los clústeres de GKE. Para obtener más información sobre cómo funciona la reducción de la escala, consulta la documentación de la herramienta de adaptación dinámica de clústeres.

La frecuencia con la que la herramienta de adaptación dinámica del clúster inspecciona un clúster en busca de pods no programables depende en gran medida del tamaño del clúster. En los clústeres pequeños, la inspección puede realizarse cada pocos segundos. No es posible definir un plazo exacto para esta inspección.

Si tus nodos tienen escasez de recursos porque tus pods han solicitado o se han configurado de forma predeterminada con recursos insuficientes, el escalador automático del clúster no corregirá la situación. Puedes ayudar a garantizar que la herramienta de adaptación dinámica de clúster funcione de la forma más precisa posible realizando peticiones explícitas de recursos para todas tus cargas de trabajo.

No habilites el autoescalado de Compute Engine en los grupos de instancias gestionados de los nodos del clúster. La herramienta de adaptación dinámica de clústeres de GKE es independiente del autoescalado de Compute Engine. Esto puede provocar que los grupos de nodos no puedan aumentar o reducir su escala porque el autoescalador de Compute Engine entrará en conflicto con el autoescalador de clústeres de GKE.

Criterios operativos

Al cambiar el tamaño de un grupo de nodos, la herramienta de ajuste automático de escala del clúster hace las siguientes suposiciones:

  • Todos los pods replicados se pueden reiniciar en otro nodo, lo que puede provocar una breve interrupción.
  • Los usuarios o administradores no gestionan los nodos manualmente. La herramienta de escalado automático de clústeres puede anular cualquier operación de gestión de nodos manual que realices.
  • Todos los nodos de un mismo grupo de nodos tienen el mismo conjunto de etiquetas.
  • El autoescalador de clústeres tiene en cuenta el coste relativo de los tipos de instancia de los distintos grupos e intenta ampliar el grupo de nodos más económico posible. Sin embargo, el escalador automático de clústeres se comporta de la siguiente manera:
    • La herramienta de ajuste automático de escala del clúster tiene en cuenta el coste reducido de los grupos de nodos que contienen VMs de Spot, que son interrumpibles. Sin embargo, el escalador automático de clústeres también tiene en cuenta la disponibilidad de recursos en cada zona y puede elegir el recurso más caro, pero disponible.
    • Cuando varios grupos de nodos utilizan máquinas virtuales de Spot, el escalador automático de clústeres no selecciona automáticamente la opción de menor coste. Para optimizar el uso de las máquinas virtuales de Spot de forma rentable y evitar esta situación, te recomendamos que utilices clases de computación personalizadas.
  • El autoescalador de clústeres tiene en cuenta las solicitudes de los contenedores init antes de programar los pods. Las solicitudes de contenedores init pueden usar cualquier recurso no asignado disponible en los nodos, lo que puede impedir que se programen pods. La herramienta de adaptación dinámica de clústeres sigue las mismas reglas de cálculo de solicitudes que Kubernetes. Para obtener más información, consulta la documentación de Kubernetes sobre el uso de contenedores init.
  • Las etiquetas que se añaden manualmente después de la creación inicial del clúster o del grupo de nodos no se registran. A los nodos que crea la herramienta de ajuste automático de escala del clúster se les asignan las etiquetas especificadas con --node-labels en el momento de la creación del grupo de nodos.
  • En la versión 1.21 de GKE o en versiones anteriores, el autoescalador de clústeres tiene en cuenta la información de taint de los nodos de un grupo de nodos para representar todo el grupo de nodos. A partir de la versión 1.22 de GKE, el autoescalador de clústeres combina la información de los nodos y del grupo de nodos del clúster. El autoescalador de clústeres también detecta los cambios manuales que hagas en el nodo y en el grupo de nodos.
Práctica recomendada:

No habilites la herramienta de ajuste automático de escala del clúster si tus aplicaciones no toleran las interrupciones.

Balanceo en las zonas

Si tu pool de nodos contiene varios grupos de instancias gestionados con el mismo tipo de instancia, el escalador automático de clúster intentará mantener equilibrados los tamaños de estos grupos de instancias gestionados al aumentar la escala. De esta forma, se evita que los nodos se distribuyan de forma desigual entre los grupos de instancias gestionadas de varias zonas de un grupo de nodos. GKE no tiene en cuenta la política de autoescalado al reducir el escalado.

La herramienta de escalado automático de clústeres solo equilibra las zonas durante un evento de escalado vertical. La herramienta de adaptación dinámica del clúster reduce la escala de los nodos infrautilizados independientemente de los tamaños relativos de los grupos de instancias gestionados subyacentes de un grupo de nodos, lo que puede provocar que los nodos se distribuyan de forma desigual entre las zonas.

Política de ubicaciones

A partir de la versión 1.24.1-gke.800 de GKE, puedes cambiar la política de ubicación del autoescalador de clústeres. Puedes controlar la política de distribución del escalador automático de clústeres especificando la marca location_policy con cualquiera de los siguientes valores:

  • BALANCED: esta política indica a la herramienta de escalado automático de clústeres que distribuya los recursos del grupo de nodos entre las zonas seleccionadas de la forma más equitativa posible, de la mejor manera posible, teniendo en cuenta los requisitos de los pods (como la afinidad) y la disponibilidad de los recursos. Esta política es la política de ubicación predeterminada de los grupos de nodos que usan reservas o nodos bajo demanda, pero también puedes usarla en las Spot VMs. BALANCED no es compatible con los grupos de nodos del modo de aprovisionamiento de inicio flexible.
  • ANY: esta política indica al escalador automático de clústeres que busque la capacidad solicitada en todas las zonas especificadas. La herramienta de adaptación dinámica del clúster prioriza las reservas y las zonas sin usar que tienen capacidad suficiente, lo que puede provocar una concentración de recursos del grupo de nodos. Es la política de ubicación predeterminada para el modo de aprovisionamiento flex-start y los grupos de nodos que usan Spot VMs, pero también puedes usarla en grupos de nodos que usen reservas o nodos bajo demanda.
Práctica recomendada:

Usa la política BALANCED si tus cargas de trabajo solo usan recursos de acelerador fáciles de obtener y se benefician de estar distribuidas en varias zonas (por ejemplo, para mejorar la tolerancia a fallos). Usa la política ANY para priorizar la utilización de las reservas no utilizadas y aumentar la probabilidad de obtener recursos de computación escasos (como aceleradores).

Reservas

A partir de la versión 1.27 de GKE, el escalador automático de clústeres siempre tiene en cuenta las reservas a la hora de tomar decisiones de escalado vertical. Los grupos de nodos con reservas no utilizadas coincidentes tienen prioridad a la hora de elegir el grupo de nodos que se va a ampliar, aunque no sea el más eficiente. Además, las reservas no utilizadas siempre tienen prioridad a la hora de equilibrar los aumentos de escala multizonales.

Sin embargo, la herramienta de ajuste automático de escala de clústeres solo busca reservas en su propio proyecto. Por lo tanto, si hay disponible una opción de nodo menos costosa en el proyecto del clúster, el escalador automático podría seleccionar esa opción en lugar de la reserva compartida. Si necesitas compartir reservas entre proyectos, te recomendamos que uses clases de cálculo personalizadas, que te permiten configurar la prioridad que usa el autoescalador de clústeres para escalar nodos, incluidas las reservas compartidas.

Valores predeterminados

En el caso de los grupos de nodos de máquinas virtuales de spot, la política de distribución predeterminada del escalador automático de clústeres es ANY. En esta política, las máquinas virtuales de acceso puntual tienen un menor riesgo de ser desalojadas.

En el caso de los grupos de nodos no preemptivos, la política de distribución predeterminada de la herramienta de ajuste automático de escala del clúster es BALANCED.

Tamaño mínimo y máximo de los grupos de nodos

Cuando creas un grupo de nodos, puedes especificar el tamaño mínimo y máximo de cada grupo de nodos de tu clúster. La herramienta de escalado automático del clúster toma decisiones de cambio de tamaño dentro de estas restricciones de escalado. Para actualizar el tamaño mínimo, cambia manualmente el tamaño del clúster a un tamaño que se ajuste a las nuevas restricciones después de especificar el nuevo valor mínimo. A continuación, la herramienta de adaptación dinámica del clúster toma decisiones de reescalado en función de las nuevas restricciones.

Tamaño actual del grupo de nodos Acción de la herramienta de adaptación dinámica de clústeres Restricciones de escalado
Inferior al mínimo que has especificado La herramienta de escalado automático de clústeres aumenta la escala para aprovisionar los pods pendientes. La reducción está inhabilitada. El grupo de nodos no se reduce por debajo del valor que haya especificado.
Dentro del tamaño mínimo y máximo que haya especificado La herramienta de escalado automático de clústeres aumenta o reduce los recursos en función de la demanda. El grupo de nodos se mantiene dentro de los límites de tamaño que has especificado.
Mayor que el máximo que has especificado La herramienta de escalado automático de clústeres solo reduce la escala de los nodos que se pueden eliminar de forma segura. El escalado vertical está inhabilitado. El grupo de nodos no se escalará por encima del valor que hayas especificado.

En los clústeres estándar, la herramienta de ajuste automático de escala de clústeres nunca reduce automáticamente la escala de un clúster a cero nodos. Uno o varios nodos deben estar siempre disponibles en el clúster para ejecutar pods del sistema. Además, si el número actual de nodos es cero debido a la eliminación manual de nodos, la herramienta de adaptación dinámica del clúster y el aprovisionamiento automático de nodos pueden aumentar la escala de clústeres con cero nodos.

Para obtener más información sobre las decisiones de las herramientas de adaptación dinámica, consulta las limitaciones de las herramientas de adaptación dinámica de clústeres.

Autoescalado de límites

Puedes definir el número mínimo y máximo de nodos que debe usar el escalador automático de clústeres al escalar un grupo de nodos. Usa las marcas --min-nodes y --max-nodes para definir el número mínimo y máximo de nodos por zona.

A partir de la versión 1.24 de GKE, puedes usar las marcas --total-min-nodes y --total-max-nodes en los clústeres nuevos. Estas marcas definen el número mínimo y máximo de nodos del grupo de nodos en todas las zonas.

Ejemplo de nodos mínimos y máximos

El siguiente comando crea un clúster multizonal con escalado automático que tiene seis nodos en tres zonas inicialmente, con un mínimo de un nodo por zona y un máximo de cuatro nodos por zona:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --min-nodes=1 --max-nodes=4

En este ejemplo, el tamaño total del clúster puede ser de entre tres y doce nodos, distribuidos en las tres zonas. Si falla una de las zonas, el tamaño total del clúster puede ser de entre dos y ocho nodos.

Ejemplo de total de nodos

El siguiente comando, disponible en la versión 1.24 de GKE o en versiones posteriores, crea un clúster multizonal de escalado automático con seis nodos en tres zonas inicialmente, con un mínimo de tres nodos y un máximo de doce nodos en el grupo de nodos de todas las zonas:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --total-min-nodes=3 --total-max-nodes=12

En este ejemplo, el tamaño total del clúster puede ser de entre tres y doce nodos, independientemente de la distribución entre zonas.

Perfiles de autoescalado

Para decidir cuándo debes eliminar un nodo, tienes que encontrar el equilibrio entre optimizar el uso o la disponibilidad de los recursos. El uso del clúster mejora cuando se eliminan los nodos infrautilizados, pero puede que las nuevas cargas de trabajo tengan que esperar a que vuelvan a aprovisionarse los recursos antes de poder ejecutarse.

Puedes especificar qué perfil de escalado automático quieres usar al tomar estas decisiones. Los perfiles disponibles son los siguientes:

  • balanced: perfil predeterminado que prioriza mantener más recursos disponibles para los pods entrantes y, por lo tanto, reduce el tiempo necesario para que estén activos en los clústeres estándar. El perfil balanced no está disponible para los clústeres de Autopilot.
  • optimize-utilization: prioriza la optimización de la utilización en lugar de mantener recursos de reserva en el clúster. Si habilitas este perfil, la herramienta de adaptación dinámica de clústeres reducirá el tamaño del clúster de forma más agresiva. GKE puede eliminar más nodos y hacerlo más rápido. GKE prefiere programar pods en nodos que ya tengan una asignación alta de CPU, memoria o GPUs. Sin embargo, hay otros factores que influyen en la programación, como la distribución de los pods que pertenecen a la misma implementación, StatefulSet o servicio entre los nodos.

El perfil de autoescalado optimize-utilization ayuda al autoescalador de clústeres a identificar y eliminar los nodos infrautilizados. Para conseguir esta optimización, GKE asigna el nombre del programador en la especificación del pod a gke.io/optimize-utilization-scheduler. Los pods que especifican un programador personalizado no se ven afectados.

El siguiente comando habilita el perfil de autoescalado optimize-utilization en un clúster que ya existe:

gcloud container clusters update CLUSTER_NAME \
    --autoscaling-profile optimize-utilization

Consideraciones sobre la programación y las interrupciones de los pods

Al reducir el escalado, el escalador automático de clústeres respeta las reglas de programación y desalojo definidas en los pods. Estas restricciones pueden impedir que el escalador automático elimine un nodo. No se podrá eliminar un nodo si contiene un pod que cumpla alguna de estas condiciones:

  • Las reglas de afinidad o antiafinidad del pod impiden que se reprograme.
  • El pod no está gestionado por un controlador, como una implementación, un StatefulSet, un trabajo o un ReplicaSet.
  • El pod tiene almacenamiento local y la versión del plano de control de GKE es anterior a la 1.22. En los clústeres de GKE con la versión 1.22 o posterior del plano de control, los pods con almacenamiento local ya no bloquean la reducción del escalado.
  • El pod tiene la anotación "cluster-autoscaler.kubernetes.io/safe-to-evict": "false".
  • Si se elimina el nodo, se superaría el valor de PodDisruptionBudget configurado.

Para obtener más información sobre la herramienta de adaptación dinámica de clústeres y cómo evitar interrupciones, consulta las siguientes preguntas de las preguntas frecuentes sobre la herramienta de adaptación dinámica de clústeres:

Autoescalar TPUs en GKE

GKE admite unidades de procesamiento de tensor (TPUs) para acelerar las cargas de trabajo de aprendizaje automático. Tanto el grupo de nodos de segmento de TPU de un solo host como el grupo de nodos de segmento de TPU de varios hosts admiten el autoescalado y el aprovisionamiento automático.

Con la marca --enable-autoprovisioning en un clúster de GKE, GKE crea o elimina grupos de nodos de slices de TPU de un solo host o de varios hosts con una versión y una topología de TPU que cumplan los requisitos de las cargas de trabajo pendientes.

Cuando usas --enable-autoscaling, GKE escala el grupo de nodos en función de su tipo, de la siguiente manera:

  • Grupo de nodos de segmento de TPU de un solo host: GKE añade o elimina nodos de TPU en el grupo de nodos que ya existe. El grupo de nodos puede contener cualquier número de nodos de TPU entre cero y el tamaño máximo del grupo de nodos, determinado por las marcas --max-nodes y --total-max-nodes. Cuando se escala el grupo de nodos, todos los nodos de TPU del grupo de nodos tienen el mismo tipo de máquina y la misma topología. Para obtener más información sobre cómo crear un grupo de nodos de una porción de TPU de un solo host, consulta Crear un grupo de nodos.

  • Grupo de nodos de un segmento de TPU multihost: GKE escala de forma atómica el grupo de nodos de cero al número de nodos necesarios para cumplir la topología de la TPU. Por ejemplo, si tienes un grupo de nodos de TPU con el tipo de máquina ct5lp-hightpu-4t y una topología 16x16, el grupo de nodos contendrá 64 nodos. El escalador automático de GKE se asegura de que este grupo de nodos tenga exactamente 0 o 64 nodos. Cuando se reduce la escala, GKE expulsa todos los pods programados y reduce a cero todo el grupo de nodos. Para obtener más información sobre cómo crear un grupo de nodos de una porción de TPU de varios hosts, consulta Crear un grupo de nodos.

Máquinas virtuales de acceso puntual y herramienta de adaptación dinámica de clústeres

Como la herramienta de adaptación dinámica de clústeres prefiere ampliar los grupos de nodos menos caros, cuando tus cargas de trabajo y la disponibilidad de recursos lo permiten, añade VMs Spot al escalar verticalmente.

Sin embargo, aunque el autoescalador de clústeres prefiere añadir VMs de Spot, esta preferencia no garantiza que la mayoría de tus pods se ejecuten en este tipo de VMs. Las máquinas virtuales de acceso puntual se pueden interrumpir. Debido a esta expropiación, es más probable que se expulsen los pods de las VMs de acceso puntual. Cuando se les expulsa, solo tienen 15 segundos para terminar.

Por ejemplo, imagina una situación en la que tienes 10 pods y una combinación de VMs bajo demanda y Spot:

  • Empiezas con 10 pods que se ejecutan en VMs bajo demanda porque las VMs de acceso puntual no estaban disponibles.
  • No necesitas los 10 pods, por lo que la herramienta de escalado automático de clústeres elimina dos pods y cierra las VMs bajo demanda adicionales.
  • Cuando vuelvas a necesitar 10 pods, el autoescalador de clústeres añadirá máquinas virtuales de Spot (porque son más baratas) y programará dos pods en ellas. Los otros ocho pods permanecen en las máquinas virtuales bajo demanda.
  • Si el autoescalador de clústeres necesita reducir la escala de nuevo, es probable que las VMs de Spot se interrumpan primero, lo que dejará la mayoría de tus pods ejecutándose en VMs bajo demanda.

Para priorizar las máquinas virtuales de Spot y evitar la situación anterior, te recomendamos que uses clases de computación personalizadas. Las clases de computación personalizadas te permiten crear reglas de prioridad que favorezcan a las máquinas virtuales de acceso puntual durante el escalado vertical, ya que les dan una prioridad más alta que a los nodos bajo demanda. Para aumentar aún más la probabilidad de que tus pods se ejecuten en nodos respaldados por VMs de acceso puntual, configura la migración activa.

En el siguiente ejemplo se muestra una forma de usar clases de cálculo personalizadas para priorizar las VMs de Spot. Para obtener más información sobre los parámetros de ComputeClass, consulta la documentación de CRD de ComputeClass:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: prefer-l4-spot
spec:
  # Defines a prioritized list of machine types and configurations for node provisioning.
  priorities:
  - machineType: g2-standard-24
    # Specifically requests Spot VMs for this configuration. GKE will try to provision these VMs first.
    spot: true
    gpu:
      type: nvidia-l4
      count: 2
  # If GKE can't satisfy the preceding rule, request on-demand nodes with the same configuration
  - machineType: g2-standard-24
    spot: false
    gpu:
      type: nvidia-l4
      count: 2
  nodePoolAutoCreation:
    enabled: true
  # Configures active migration behavior for workloads using this ComputeClass.
  activeMigration:
    optimizeRulePriority: true
    # Enables Cluster Autoscaler to attempt to migrate workloads to Spot VMs
    # if Spot capacity becomes available and the workload is currently
    # running on an on-demand VM (based on the priority rules in this example).

En el ejemplo anterior, la regla de prioridad declara una preferencia por crear nodos con el tipo de máquina g2-standard-24 y máquinas virtuales de Spot. Si las VMs esporádicas no están disponibles, GKE usa VMs bajo demanda como alternativa. Esta clase de computación también habilita activeMigration, lo que permite que el autoescalador de clústeres migre cargas de trabajo a máquinas virtuales de acceso puntual cuando haya capacidad disponible.

Si no puedes usar clases de cálculo personalizadas, añade una afinidad, un taint o una tolerancia de nodo. Por ejemplo, la siguiente regla de afinidad de nodo declara una preferencia por programar pods en nodos respaldados por VMs Spot (GKE añade automáticamente la etiqueta cloud.google.com/gke-spot=true a estos tipos de nodos):

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        # set to "true". GKE automatically applies this label to Spot VMs.
        - key: cloud.google.com/gke-spot
          operator: Equal
          values:
          - true

Para obtener más información sobre cómo usar la afinidad de nodos, las intolerancias y las tolerancias para programar máquinas virtuales de Spot, consulta la entrada de blog Running a GKE application on spot nodes with on-demand nodes as fallback (Ejecutar una aplicación de GKE en nodos de Spot con nodos bajo demanda como alternativa).

CRD de ProvisioningRequest

Un ProvisioningRequest es un recurso personalizado con espacio de nombres que permite a los usuarios solicitar capacidad para un grupo de pods a la herramienta de ajuste automático de escala de clústeres. Esto resulta especialmente útil en aplicaciones con pods interconectados que deben programarse juntos como una sola unidad.

Clases de aprovisionamiento admitidas

Hay tres ProvisioningClasses admitidas:

  • queued-provisioning.gke.io: esta clase específica de GKE se integra con Dynamic Workload Scheduler, lo que te permite poner en cola las solicitudes y completarlas cuando haya recursos disponibles. Es ideal para tareas por lotes o cargas de trabajo tolerantes a retrasos. Consulta Desplegar GPUs para cargas de trabajo por lotes y de IA con Dynamic Workload Scheduler para obtener información sobre cómo usar el aprovisionamiento en cola en GKE. Se admite a partir de la versión 1.28.3-gke.1098000 de GKE en clústeres estándar y de la versión 1.30.3-gke.1451000 de GKE en clústeres de Autopilot.

  • check-capacity.autoscaling.x-k8s.io: esta clase de código abierto verifica la disponibilidad de los recursos antes de intentar programar los pods. Compatible con la versión 1.30.2-gke.1468000 de GKE.

  • best-effort-atomic.autoscaling.x-k8s.io: esta clase de código abierto intenta aprovisionar recursos para todos los pods de la solicitud a la vez. Si es imposible aprovisionar suficientes recursos para todos los pods, no se aprovisionarán recursos y se producirá un error en toda la solicitud. Compatible con la versión 1.31.27 de GKE.

Para obtener más información sobre las clases CheckCapacity y BestEffortAtomicScaleUp, consulta la documentación de código abierto.

Limitaciones al usar ProvisioningRequest

  • El autoescalador de clústeres de GKE solo admite una PodTemplate por ProvisioningRequest.
  • La herramienta de adaptación dinámica de clústeres de GKE solo puede escalar un grupo de nodos a la vez. Si tu ProvisioningRequest requiere recursos de varios grupos de nodos, debes crear ProvisioningRequests independientes para cada grupo de nodos.

Prácticas recomendadas al usar ProvisioningRequest

  • Usa total-max-nodes: en lugar de limitar el número máximo de nodos (--max nodes), usa --total-max-nodes para restringir los recursos totales que consume tu aplicación.
  • Usar location-policy=ANY: este ajuste permite programar tus pods en cualquier ubicación disponible, lo que puede acelerar el aprovisionamiento y optimizar la utilización de los recursos.
  • Opcional: Integración con Kueue: Kueue puede automatizar la creación de ProvisioningRequests, lo que optimiza tu flujo de trabajo. Para obtener más información, consulta la documentación de Kueue.

Periodos de retirada

Una operación de escalado vertical puede fallar debido a errores de creación de nodos, como una cuota insuficiente o el agotamiento de las direcciones IP. Cuando se producen estos errores, el grupo de instancias gestionadas (MIG) subyacente vuelve a intentar la operación después de un tiempo de espera inicial de cinco minutos. Si los errores continúan, este periodo de espera aumenta de forma exponencial hasta un máximo de 30 minutos. Durante este tiempo, la herramienta de escalado automático de clústeres puede seguir escalando verticalmente otros grupos de nodos del clúster que no tengan errores.

Información adicional

Puedes consultar más información sobre la herramienta de adaptación dinámica de clústeres en las preguntas frecuentes sobre el autoescalado del proyecto de código abierto Kubernetes.

Limitaciones

La herramienta de ajuste automático de escala de clústeres tiene las siguientes limitaciones:

  • El autoescalador de clústeres no admite PersistentVolumes locales.
  • En las versiones del plano de control de GKE anteriores a la 1.24.5-gke.600, cuando los pods solicitan almacenamiento efímero, el autoescalador de clústeres no admite el escalado vertical de un grupo de nodos con cero nodos que utilice SSD locales como almacenamiento efímero.
  • Limitaciones en el tamaño de los clústeres: hasta 15.000 nodos. Ten en cuenta otros límites de clústeres y nuestras prácticas recomendadas cuando ejecutes clústeres de este tamaño.
  • Al reducir el escalado, el escalador automático del clúster respeta un periodo de finalización gradual de 10 minutos para reprogramar los pods del nodo en otro nodo antes de finalizar el nodo de forma forzosa.
  • En ocasiones, la herramienta de adaptación dinámica de clústeres no puede reducir la escala por completo y queda un nodo adicional después de la reducción. Esto puede ocurrir cuando los pods del sistema necesarios se programan en nodos diferentes, ya que no hay ningún activador para que esos pods se muevan a otro nodo. Consulta Tengo un par de nodos con una utilización baja, pero no se han reducido. ¿Por qué?. Para evitar esta limitación, puedes configurar un presupuesto de interrupción de pods.
  • No se admite la programación personalizada con filtros modificados.
  • La herramienta de ajuste automático de escala de clúster tiene en cuenta el comportamiento predeterminado de kube-scheduler al decidir aprovisionar nuevos nodos para los pods pendientes. No se admite el uso de programadores personalizados, ya que puede provocar un comportamiento de escalado inesperado.
  • Los nodos no se escalarán si los pods tienen un valor de PriorityClass inferior a -10. Consulte más información en ¿Cómo funciona Cluster Autoscaler con la prioridad y la preferencia de los pods?
  • Es posible que la herramienta de adaptación dinámica del clúster no tenga suficiente espacio de direcciones IP sin asignar para añadir nodos o pods nuevos, lo que provoca errores de escalado vertical, que se indican mediante eventos eventResult con el motivo scale.up.error.ip.space.exhausted. Puedes añadir más direcciones IP para los nodos ampliando la subred principal o añadir nuevas direcciones IP para los pods mediante CIDR de varios pods no contiguos. Para obtener más información, consulta No hay suficiente espacio de IP libre para los pods.
  • La herramienta de escalado automático de clústeres de GKE es diferente de la herramienta de escalado automático de clústeres del proyecto de código abierto Kubernetes. Los parámetros del escalador automático de clústeres de GKE dependen de la configuración del clúster y están sujetos a cambios. Si necesitas más control sobre el comportamiento del autoescalado, inhabilita la herramienta de adaptación dinámica de clústeres de GKE y ejecuta la herramienta de adaptación dinámica de clústeres de Kubernetes de código abierto. Sin embargo, el código abierto de Kubernetes no tiene asistencia. Google Cloud
  • Cuando eliminas un grupo de nodos de GKE que tiene habilitado el autoescalado, los nodos reciben la marca NoSchedule y se expulsan inmediatamente los pods de esos nodos. Para mitigar la disminución repentina de los recursos disponibles, la herramienta de escalado automático del grupo de nodos puede aprovisionar nuevos nodos en el mismo grupo. Estos nodos recién creados estarán disponibles para la programación y los pods desalojados se volverán a programar en ellos. Finalmente, se elimina todo el grupo de nodos, incluidos los nodos recién aprovisionados y sus pods, lo que puede provocar interrupciones en el servicio. Como solución alternativa, para evitar que la herramienta de ajuste automático de escala aprovisione nuevos nodos durante la eliminación, inhabilita el ajuste automático de escala en el grupo de nodos antes de iniciar la eliminación.
  • La herramienta de adaptación dinámica del clúster necesita predecir la cantidad de recursos disponibles en los nodos nuevos para tomar decisiones de escalado. Se incluyen los pods de DaemonSet, lo que reduce los recursos disponibles. Las predicciones no son 100% precisas y la cantidad de recursos disponibles puede cambiar entre versiones de GKE. Por este motivo, no recomendamos dimensionar ni restringir las cargas de trabajo para que se ajusten a un tipo de instancia concreto. Te recomendamos que uses clases de cálculo personalizadas. Si una carga de trabajo debe orientarse a un tipo de instancia concreto, asegúrese de que tenga el tamaño adecuado para que quede un búfer de recursos asignables en los nodos. En ese caso, también debes asegurarte de que todos los pods de DaemonSet relevantes quepan en los nodos junto con los pods de tu carga de trabajo.
  • El escalador automático de clústeres no admite restricciones de distribución de topología de pods estrictas cuando el campo whenUnsatisfiable tiene el valor DoNotSchedule. Puedes suavizar los requisitos de dispersión configurando el campo whenUnsatisfiable con el valor ScheduleAnyway.

Problemas conocidos

  • En las versiones del plano de control de GKE anteriores a la 1.22, el escalador automático de clústeres de GKE deja de aumentar la escala de todos los grupos de nodos en clústeres vacíos (con cero nodos). Este comportamiento no se produce en GKE 1.22 ni en versiones posteriores.

Solución de problemas

Para obtener consejos sobre cómo solucionar problemas, consulta las siguientes páginas:

Siguientes pasos