Acerca del ajuste de escala automático de clústeres de GKE

En esta página, se explica cómo Google Kubernetes Engine (GKE) cambia el tamaño de los grupos de nodos de tu clúster de Standard de forma automática según las demandas de tus cargas de trabajo. Cuando la demanda es alta, el escalador automático del clúster agrega nodos al grupo. Para obtener más información sobre cómo configurar el escalador automático del clúster, consulta Ajusta la escala de un clúster de forma automática.

Esta página está destinada a administradores, arquitectos y operadores que planifican las necesidades de capacidad e infraestructura, y optimizan la arquitectura y los recursos de los sistemas para lograr el menor costo total de propiedad para su empresa o unidad de negocios. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Tareas y roles comunes de los usuarios de GKE Enterprise.

Con los clústeres de Autopilot, no tienes que preocuparte por aprovisionar nodos o administrar los grupos de nodos, ya que los grupos de nodos se aprovisionan automáticamente mediante el aprovisionamiento automático de nodos y se escalan de forma automática para cumplir con los requisitos de tus cargas de trabajo.

Antes de leer esta página, asegúrate de estar familiarizado con 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, los desarrolladores o cualquier otro equipo de tu organización que sea responsable de la implementación y el mantenimiento de tu aplicación.

Por qué usar el escalador automático de clústeres

El escalador automático del clúster de GKE cambia el tamaño de la cantidad de nodos en un grupo de nodos determinado de forma automática, en función de las demandas de las cargas de trabajo. Cuando la demanda es baja, el escalador automático del clúster reduce la escala al tamaño mínimo que hayas designado. Esto te permite contar con una mayor disponibilidad para tus cargas de trabajo cuando sea necesario sin incurrir en gastos excesivos. No es necesario que agregues o quites nodos de forma manual ni que sobreaprovisiones tus grupos de nodos. Solo debes especificar un tamaño mínimo y máximo para el grupo de nodos y dejar que los cambios necesarios se hagan de manera automática.

Si se borran o mueven recursos mientras se realiza el ajuste de escala automático del clúster, es posible que las cargas de trabajo sufran interrupciones transitorias. Por ejemplo, si tu carga de trabajo consta de un controlador con una sola réplica, es posible que el pod de esa réplica se reprograme en otro nodo si se borra el actual. Antes de habilitar el escalador automático del clúster, diseña tus cargas de trabajo para tolerar posibles interrupciones o asegúrate de que no se interrumpan los pods críticos.

Práctica recomendada:

Para aumentar la tolerancia de tu carga de trabajo a interrupciones, impleméntala con un controlador con varias réplicas, como una implementación.

Puedes aumentar el rendimiento del escalador automático del clúster con la transmisión de imágenes, que transmite de forma remota los datos de imágenes requeridos de las imágenes de contenedor aptas, al mismo tiempo que almacena en caché la imagen de forma local para permitir que las cargas de trabajo en nodos nuevos se inician más rápido.

Cómo funciona el escalador automático del clúster

El escalador automático de clúster funciona por grupo de nodos. Cuando configuras un grupo de nodos con el escalador automático del clúster, debes especificar un tamaño mínimo y máximo.

El escalador automático de clúster aumenta o disminuye el tamaño del grupo de nodos de forma automática si agregas o quitas instancias de máquina virtual (VM) en el grupo de instancias administrado (MIG) subyacente de Compute Engine para el grupo de nodos. El escalador automático de clúster toma estas decisiones de escalamiento en función de las solicitudes de recursos (en lugar del uso de recursos real) de los Pods que se ejecutan en los nodos de ese grupo de nodos. Periódicamente, el escalador verifica el estado de los pods y los nodos, y realiza las acciones correspondientes:

  • Si no se pueden programar Pods en ninguno de los nodos actuales, el escalador automático del clúster agrega nodos, hasta el tamaño máximo del grupo de nodos. Para obtener más información sobre cuándo el escalador automático de clústeres cambia el tamaño de un clúster, consulta ¿Cuándo cambia el escalador automático de clústeres el tamaño de un clúster?
  • Si GKE decide agregar nodos nuevos al grupo de nodos, el escalador automático del clúster agrega tantos nodos como sea necesario, hasta los límites por grupo de nodos o por clúster.
  • El escalador automático del clúster no espera a que se inicie un nodo antes de crear el siguiente. Una vez que GKE decide cuántos nodos crear, la creación de nodos ocurre en paralelo. El objetivo es minimizar el tiempo necesario para que los Pods no programables se conviertan en Active.
  • Si no se crean algunos nodos debido al agotamiento de la cuota, el escalador automático de clústeres espera hasta que se puedan programar los recursos correctamente.
  • Si sobra capacidad de nodos y resulta posible programar todos los Pods con una cantidad menor de nodos en el grupo, el escalador automático del clúster quita los nodos sobrantes (siempre y cuando no se haya alcanzado el tamaño mínimo configurado para el grupo). Si en un nodo hay Pods que no se pueden mover a otros nodos del clúster, el escalador automático de clústeres no intenta reducir la escala de ese nodo. Si los Pods se pueden mover a otros nodos, pero el nodo no se puede desviar de forma correcta después de un tiempo de espera (actualmente, de 10 minutos), se forzará su finalización. Los clústeres de GKE no permiten configurar el período de gracia. Para obtener más información sobre cómo funciona la reducción de escala verticalmente, consulta la documentación del escalador automático de clústeres.

La frecuencia con la que el escalador automático de clústeres inspecciona un clúster en busca de pods no programables depende en gran medida del tamaño del clúster. En clústeres pequeños, la inspección puede ocurrir cada pocos segundos. No es posible definir un período exacto requerido para esta inspección.

Si tus nodos sufren escasez porque tus Pods solicitaron recursos insuficientes o se establecieron de forma predeterminada, el escalador automático del clúster no corrige la situación. Para ayudar a que el escalador automático del clúster funcione de la manera más precisa posible, debes realizar solicitudes de recursos explícitas para todas tus cargas de trabajo.

No habilites el ajuste de escala automático para grupos de instancias administrados de Compute Engine en los nodos del clúster. El escalador automático del clúster de GKE es independiente del ajuste de escala automático de Compute Engine. Esto puede causar que los grupos de nodos no aumenten o disminuyan su escala, ya que el escalador automático de Compute Engine entrará en conflicto con el del clúster de GKE.

Criterios operativos

Cuando se cambia el tamaño de un grupo de nodos, el escalador automático del clúster hace las siguientes suposiciones:

  • Todos los pods replicados se pueden reiniciar en otro nodo, aunque es posible que esto provoque una interrupción breve.
  • Los usuarios o administradores no controlan los nodos de forma manual. El escalador automático del clúster puede anular cualquier operación manual de administración de nodos que realices.
  • Todos los nodos de un grupo tienen el mismo conjunto de etiquetas.
  • El escalador automático del clúster considera el costo relativo de los tipos de instancia en los diversos grupos y, luego, intenta expandir el grupo de nodos que genere el costo más bajo. El escalador automático del clúster considera el costo reducido de los grupos de nodos que contienen VMs Spot, que son interrumpibles.
  • El escalador automático de clústeres considera las solicitudes de contenedor de init antes de programar los pods. Las solicitudes de contenedores init pueden usar cualquier recurso sin asignar disponible en los nodos, lo que podría impedir que se programen Pods. El escalador automático de clústeres sigue las mismas reglas de cálculo de solicitudes que usa Kubernetes. Para obtener más información, consulta la documentación de Kubernetes para usar contenedores init.
  • No se realiza seguimiento de las etiquetas que se agregan manualmente después de la creación del clúster o grupo de nodos inicial. Los nodos que crea el escalador automático del clúster reciben las etiquetas especificadas con --node-labels cuando se creó el grupo de nodos.
  • En GKE versión 1.21 o anterior, el escalador automático de clústeres considera que la información de los taints de los nodos existentes de un grupo de nodos representa todo el grupo de nodos. A partir de la versión 1.22 de GKE, el escalador automático de clústeres combina información de nodos existentes en el clúster y el grupo de nodos. El escalador automático del clúster también detecta los cambios manuales que realizas en el nodo y el grupo de nodos.
Práctica recomendada:

No habilites el escalador automático del clúster si tus aplicaciones no toleran las interrupciones.

Balance entre zonas

Si tu grupo de nodos tiene varios grupos de instancias administrados con el mismo tipo de instancia, el escalador automático del clúster intenta mantener balanceado su tamaño cuando escala verticalmente. Esto ayuda a evitar una distribución desigual de nodos entre los grupos de instancias administrados en varias zonas de un grupo de nodos. GKE no tiene en cuenta la política de ajuste de escala automático cuando reduce la escala.

El escalador automático del clúster solo equilibra las zonas cuando aumenta la escala. El escalador automático del clúster reduce los nodos infrautilizados independientemente de los tamaños relativos de los grupos de instancias administradas subyacentes de un grupo de nodos, lo que puede hacer que la distribución de los nodos en distintas zonas sea dispareja.

Política de ubicación

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

  • BALANCED: El escalador automático del clúster considera los requisitos del Pod y la disponibilidad de los recursos en cada zona. Esto no garantiza que los grupos de nodos similares tengan exactamente los mismos tamaños, ya que el escalador automático del clúster considera muchos factores, incluidas la capacidad disponible en una zona determinada y las afinidades de zona de los Pods que activaron el escalamiento vertical.
  • ANY: El escalador automático del clúster prioriza el uso de reservas sin usar y tiene en cuenta las restricciones actuales de los recursos disponibles.
Práctica recomendada:

Usa la política ANY si usas VMs Spot o si deseas usar reservas de VM que no son iguales entre zonas.

Reservas

A partir de la versión 1.27 de GKE, el escalador automático del clúster siempre considera reservas cuando toma decisiones de escalamiento vertical. Los grupos de nodos con reservas coincidentes sin usar se priorizan cuando se elige el grupo de nodos para escalar verticalmente, incluso cuando el grupo de nodos no es el más eficiente. Además, las reservas sin usar siempre tienen prioridad cuando se balancean los escalamientos verticales de varias zonas.

Valores predeterminados

Para los grupos de nodos de VM Spot, la política predeterminada de distribución del escalador automático del clúster es ANY. En esta política, las VM Spot tienen un riesgo menor de interrupción.

Para los grupos de nodos no interrumpibles, la política predeterminada de distribución del escalador automático del clúster es BALANCED.

Tamaño mínimo y máximo del grupo de nodos

Cuando creas un grupo de nodos nuevo, puedes especificar el tamaño mínimo y máximo de cada grupo en el clúster, y el escalador automático de clústeres toma decisiones de reescalamiento dentro de estas restricciones. Para actualizar el tamaño mínimo, cambia el tamaño del clúster de forma manual a un tamaño dentro de las nuevas restricciones después de especificar el valor mínimo nuevo. Luego, el escalador automático de clústeres toma decisiones de reescalamiento según las restricciones nuevas.

Tamaño actual del grupo de nodos Acción del escalador automático de clústeres Restricciones de escalamiento
Menor que el mínimo que especificaste El escalador automático de clústeres escala verticalmente para aprovisionar pods pendientes. La reducción de la escala está inhabilitada. El grupo de nodos no se reduce al valor que especificaste.
Dentro del tamaño mínimo y máximo que especificaste El escalador automático del clúster aumenta o reduce la escala según la demanda. El grupo de nodos se mantiene dentro de los límites de tamaño que especificaste.
Mayor que el máximo especificado Cuando el escalador automático del clúster reduce solo los nodos que se pueden quitar de forma segura. El escalamiento vertical está inhabilitado. El grupo de nodos no escala por encima del valor que especificaste.

En los clústeres estándar, el escalador automático de clústeres nunca reduce la escala de un clúster automáticamente a cero nodos. Uno o más nodos siempre deben estar disponibles en el clúster para ejecutar los Pods del sistema. Además, si la cantidad actual de nodos es cero debido a la eliminación manual de nodos, el escalador automático de clústeres y el aprovisionamiento automático de nodos pueden escalar verticalmente desde clústeres de cero nodos.

Para obtener más información sobre las decisiones de los escaladores automáticos, consulta Limitaciones del escalador automático de clústeres.

Límites del ajuste de escala automático

Puedes configurar la cantidad de nodos mínima y máxima que pueden usar el escalador automático de clústeres cuando escalas un grupo de nodos. Usa las marcas --min-nodes y --max-nodes para establecer la cantidad mínima y máxima 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 para los clústeres nuevos. Estas marcas establecen la cantidad mínima y máxima del total de nodos en el grupo de nodos en todas las zonas.

Ejemplo de cantidad mínima y máxima de nodos

Por ejemplo, el siguiente comando crea un clúster de varias zonas con ajuste de escala automático, que tiene seis nodos en tres zonas, con un mínimo de un nodo por zona y un máximo de cuatro:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --zone=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 se puede establecer entre tres y doce nodos repartidos en las tres zonas. Si una de las zonas falla, el tamaño total del clúster se puede establecer entre dos y ocho nodos.

Ejemplo de nodos totales

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

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --zone=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 3 y 12 nodos, sin importar si se distribuye entre zonas.

Perfiles de ajuste de escala automático

La decisión de cuándo quitar un nodo representa el equilibrio entre la optimización para el uso o la disponibilidad de los recursos. Quitar los nodos poco usados mejora el uso del clúster, pero es posible que las cargas de trabajo nuevas tengan que esperar hasta que los recursos se vuelvan a aprovisionar para poder ejecutarse.

Puedes especificar qué perfil de ajuste de escala automático usar cuando tomes esas decisiones. Los perfiles disponibles son los siguientes:

  • balanced: Es el perfil predeterminado que prioriza mantener más recursos disponibles para los pods entrantes y, de esta manera, reducir el tiempo necesario para tenerlos 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 para el uso en lugar de mantener los recursos libres en el clúster. Cuando habilitas este perfil, el escalador automático de clústeres reduce la escala verticalmente de clústeres de forma más contundente. GKE puede quitar más nodos y hacerlo más rápido. GKE prefiere programar los Pods en los nodos que ya tienen una asignación alta de CPU, memoria o GPU. Sin embargo, otros factores de programación de influencia, como la expansión de Pods que pertenecen al mismo Deployment, StatefulSet o Service, en todos los nodos.

El perfil de ajuste de escala automático optimize-utilization ayuda al escalador automático del clúster a identificar y quitar los nodos con poco uso. Para lograr esta optimización, GKE establece el nombre del programador en la especificación del Pod en gke.io/optimize-utilization-scheduler. Los Pods que especifican un programador personalizado no se ven afectados.

Con el siguiente comando, se habilita el perfil de ajuste de escala automático optimize-utilization en un clúster existente:

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

Considera la programación y la interrupción de pods

Cuando reduce la escala, el escalador automático del clúster respeta las reglas de programación y expulsión establecidas para los pods. Estas restricciones pueden impedir que el escalador automático borre un nodo. Puede que se impida la eliminación de un nodo si este contiene un pod con alguna de las siguientes condiciones:

  • Pods con reglas de afinidad o antiafinidad que impiden las reprogramaciones
  • Pods que no están bajo la administración de un Controlador, tal 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 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 de la escala.
  • El Pod tiene la anotación "cluster-autoscaler.kubernetes.io/safe-to-evict": "false".
  • La eliminación del nodo excedería el PodDisruptionBudget configurado.

Para obtener más información sobre el escalador automático del clúster y la prevención de interrupciones, consulta las siguientes dudas en las Preguntas frecuentes sobre el escalador automático del clúster:

Ajuste de escala automático de TPU en GKE

GKE es compatible con unidades de procesamiento tensorial (TPU) para acelerar las cargas de trabajo de aprendizaje automático. El grupo de nodos de porción de TPU de host único y el grupo de nodos de porción de TPU de varios hosts admiten el ajuste de escala automático y el aprovisionamiento automático.

Con la marca --enable-autoprovisioning en un clúster de GKE, este último crea o borra grupos de nodos de porción de TPU de host único o multihost con una versión de TPU y una topología que cumple con los requisitos de las cargas de trabajo pendientes.

Cuando usas --enable-autoscaling, GKE escala el grupo de nodos según su tipo de la siguiente manera:

  • Grupo de nodos de porción de TPU de host único: GKE agrega o quita nodos TPU en el grupo de nodos existente. El grupo de nodos puede contener cualquier cantidad de nodos TPU entre cero y el tamaño máximo del grupo de nodos según lo determinado por --max-nodes y el valor --total-max-nodes. Cuando el grupo de nodos escala, todos los nodos TPU del grupo tienen el mismo tipo de máquina y topología. Para obtener más información sobre cómo crear un grupo de nodos de porción de TPU de host único, consulta Crea un grupo de nodos.

  • Grupo de nodos de porción de TPU de varios hosts: GKE escala verticalmente el grupo de nodos de forma atómica desde cero hasta la cantidad de nodos necesarios para satisfacer la topología de TPU. Por ejemplo, con un grupo de nodos TPU con un tipo de máquina ct5lp-hightpu-4t y una topología de 16x16, el grupo de nodos contiene 64 nodos. El escalador automático de GKE garantiza que este grupo de nodos tenga exactamente 0 o 64 nodos. Cuando se reduce la escala, GKE expulsa todos los Pods programados y vacía todo el grupo de nodos a cero. Para obtener más información sobre cómo crear un grupo de nodos de porción de TPU de varios hosts, consulta Crea un grupo de nodos.

VM Spot y escalador automático de clústeres

Debido a que el escalador automático del clúster prefiere expandir los grupos de nodos menos costosos, cuando tus cargas de trabajo lo permiten, agrega VMs Spot cuando se realiza el escalamiento.

Sin embargo, aunque el escalador automático del clúster prefiere agregar VMs Spot, esta preferencia no garantiza que la mayoría de tus Pods se ejecuten en estos tipos de VMs. Las VMs Spot se pueden interrumpir. Debido a esta preemptión, es más probable que se expulsen los pods de las VMs Spot. Cuando se desalojan, solo tienen 15 segundos para finalizar.

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

  • Comienzas con 10 pods que se ejecutan en VMs on demand porque las VMs Spot no estaban disponibles.
  • No necesitas los 10 Pods, por lo que el escalador automático del clúster quita dos Pods y cierra las VMs adicionales a pedido.
  • Cuando vuelvas a necesitar 10 pods, el escalador automático del clúster agregará VMs Spot (porque son más económicas) y programará dos pods en ellas. Los otros ocho Pods permanecen en las VMs a pedido.
  • Si el escalador automático del clúster necesita reducir la escala nuevamente, es probable que las VMs Spot se interrumpan primero, lo que dejará a la mayoría de tus Pods ejecutándose en VMs on demand.

Para priorizar las VMs Spot y evitar la situación anterior, te recomendamos que uses clases de procesamiento personalizadas. Las clases de procesamiento personalizadas te permiten crear reglas de prioridad que favorezcan a las VMs Spot durante la escalabilidad, ya que les asignan una prioridad más alta que a los nodos a pedido. Para maximizar aún más la probabilidad de que tus pods se ejecuten en nodos respaldados por VMs Spot, configura la migración activa.

En el siguiente ejemplo, se muestra una forma de usar clases de procesamiento personalizadas para priorizar las VMs Spot:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: prefer-l4-spot
spec:
  priorities:
  - machineType: g2-standard-24
    spot: true
    gpu:
      type: nvidia-l4
      count: 2
  - machineType: g2-standard-24
    spot: false
    gpu:
      type: nvidia-l4
      count: 2
  nodePoolAutoCreation:
    enabled: true
  activeMigration:
    optimizeRulePriority: true

En el ejemplo anterior, la regla de prioridad declara una preferencia para crear nudos con el tipo de máquina g2-standard-24 y las VMs Spot. Si las VMs Spot no están disponibles, GKE usa las VMs a pedido como opción de resguardo. Esta clase de procesamiento también habilita activeMigration, lo que permite que el escalador automático de clústeres migre cargas de trabajo a VMs Spot cuando la capacidad esté disponible.

Si no puedes usar clases de procesamiento personalizadas, agrega una afinidad, contaminación o tolerancia de nodos. Por ejemplo, la siguiente regla de afinidad de nodos declara una preferencia para programar Pods en nodos respaldados por VMs Spot (GKE agrega automáticamente la etiqueta cloud.google.com/gke-spot=true a estos tipos de nodos):

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
    preference:
      matchExpressions:
      - key: cloud.google.com/gke-spot
        operator: Equal
        values:
        - true

Para obtener más información sobre el uso de afinidades de nodos, taints y tolerancias para programar VMs Spot, consulta el blog Cómo ejecutar una aplicación de GKE en nodos Spot con nodos a pedido como resguardo.

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 desde el escalador de clústeres. Esto es particularmente útil para aplicaciones con pods interconectados que deben programarse juntos como una sola unidad.

Clases de aprovisionamiento compatibles

Existen tres ProvisioningClasses compatibles:

  • queued-provisioning.gke.io: Esta clase específica de GKE se integra en el programador de cargas de trabajo dinámico y te permite poner en cola solicitudes y que se completen cuando los recursos estén disponibles. Esto es ideal para trabajos por lotes o cargas de trabajo tolerantes a demoras. Consulta Implementa GPUs para cargas de trabajo por lotes y de IA con el programador dinámico de cargas de trabajo para aprender a usar el aprovisionamiento en cola en GKE. Se admite desde la versión 1.28.3-gke.1098000 de GKE en clústeres estándar y desde 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 Pods. Compatible a partir de 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 los recursos de todos los pods de la solicitud en conjunto. Si es imposible aprovisionar suficientes recursos para todos los pods, no se aprovisionarán recursos y fallará toda la solicitud. Compatible a partir de 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 cuando se usa ProvisioningRequest

  • El escalador automático de clústeres de GKE solo admite 1 PodTemplate por ProvisioningRequest.
  • El escalador automático de clústeres de GKE puede escalar solo 1 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 para usar ProvisioningRequest

  • Usa total-max-nodes: En lugar de limitar la cantidad máxima de nodos (--max nodes), usa --total-max-nodes para restringir los recursos totales que consume tu aplicación.
  • Usa location-policy=ANY: Este parámetro de configuración permite que tus pods se programen en cualquier ubicación disponible, lo que puede acelerar el aprovisionamiento y optimizar el uso de los recursos.
  • Integración con Kueue (opcional): 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.

Información adicional

Puedes encontrar más información sobre el escalador automático del clúster en las Preguntas frecuentes sobre el ajuste de escala automático del proyecto de código abierto de Kubernetes.

Limitaciones

El escalador automático de clúster tiene las siguientes limitaciones:

  • El escalador automático de clústeres no admite los PersistentVolumes locales.
  • En la versión del plano de control de GKE anterior a 1.24.5-gke.600, cuando los Pods solicitan almacenamiento efímero, el escalador automático de clústeres no admite el escalamiento vertical de un grupo de nodos sin nodos que usa SSD locales como almacenamiento efímero.
  • Limitaciones de tamaño del clúster: hasta 15,000 nodos. Ten en cuenta otros límites de clúster y nuestras prácticas recomendadas cuando ejecutes clústeres de este tamaño.
  • Cuando se reduce la escala, el escalador automático del clúster contempla un período de cierre de gracia de 10 minutos para la reprogramación de los Pods de un nodo a otro antes de que se fuerce su interrupción.
  • En ocasiones, el escalador automático del clúster no puede reducir la escala por completo, y sigue existiendo un nodo de más después de reducir la escala. Esto puede ocurrir cuando los pods obligatorios del sistema están programados en nodos diferentes, ya que no hay ningún activador que haga que esos pods se transfieran a otro nodo. Consulta Tengo un par de nodos con baja utilización, pero el ajuste de escala no los quita. ¿Por qué? Como solución alternativa a esta limitación, puedes configurar un presupuesto de interrupción de pods.
  • No se admite la programación personalizada con filtros alterados.
  • Los nodos no se escalarán verticalmente si los Pods tienen un valor PriorityClass inferior a -10. Obtén más información en ¿Cómo funciona el escalador automático del clúster con la prioridad y la interrupción del pod?
  • Es posible que el escalador automático del clúster no tenga suficiente espacio de direcciones IP sin asignar para agregar nodos o Pods nuevos, lo que genera fallas de escalamiento vertical, que se indican medianteeventResult eventos con el motivoscale.up.error.ip.space.exhausted. Puedes agregar más direcciones IP para los nodos si expandes la subred principal o agregas direcciones IP nuevas para los pods con CIDR de varios pods discontinuos. Si deseas obtener más información, consulta No hay suficiente espacio IP gratuito para pods.
  • El escalador automático de clústeres de GKE es diferente del escalador automático de clústeres del proyecto de código abierto de 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 ajuste de escala automático, inhabilita el escalador automático de clústeres de GKE y ejecuta el escalador automático de Kubernetes de código abierto. Sin embargo, Kubernetes de código abierto no tiene Google Cloud compatibilidad.

Problemas conocidos

  • En la versión del plano de control de GKE anterior a la 1.22, el escalador automático de clústeres de GKE deja de escalar todos los grupos de nodos en clústeres vacíos (cero nodos). Este comportamiento no se produce en la versión 1.22 de GKE y en versiones posteriores.

Soluciona problemas

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

¿Qué sigue?