Escalador automático del clúster

En esta página, se explica cómo cambiar automáticamente el tamaño de los grupos de nodos de tu clúster de Google Kubernetes Engine (GKE) según las exigencias de tus cargas de trabajo. Cuando la demanda es alta, el escalador automático del clúster agrega nodos al grupo. 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. También puedes configurar el escalador automático para un clúster.

Descripción general

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. No es necesario que agregues o quites nodos de forma manual ni que sobreaprovisiones tus grupos de nodos. Simplemente especifica un tamaño mínimo y máximo para el grupo de nodos y deja que los cambios necesarios se hagan automáticamente.

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.

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 del clúster aumenta o disminuye el tamaño del grupo de nodos automáticamente según las solicitudes de recursos (no el uso real) de los pods que se ejecutan en los nodos del grupo. Periódicamente, el escalador verifica el estado de los pods y los nodos, y realiza las acciones correspondientes:

  • Si no es posible programar pods porque el grupo no tiene nodos suficientes, el escalador automático del clúster agrega los nodos necesarios (siempre y cuando no se haya alcanzado el tamaño máximo configurado para el grupo).
  • 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 un nodo no se puede desviar correctamente 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.

Si tus pods solicitan una cantidad insuficiente de recursos (o no cambian los valores predeterminados, que podrían no alcanzar) y tus nodos sufren escasez, 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.

Criterios operativos

El escalador automático del clúster actúa según las siguientes suposiciones cuando cambia el tamaño de un grupo de nodos:

  • Todos los pods replicados se pueden reiniciar en otro nodo, aunque es posible que esto provoque una interrupción breve. Si tus servicios no toleran las interrupciones, no es recomendable que uses el escalador automático del clúster.
  • Los usuarios o administradores no controlan los nodos de forma manual; es posible que se anulen todas las operaciones manuales que realizas.
  • 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. Este cálculo considera el costo reducido de los grupos de nodos que contienen VM interrumpibles.
  • 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.

Balance entre zonas

Si tu grupo de nodos tiene varios grupos administrados que contienen instancias del mismo tipo, el escalador automático del clúster intenta mantener balanceado su tamaño cuando se escala verticalmente. Esto puede ayudar a evitar una distribución desigual de nodos entre los grupos de instancias administrados en varias zonas de un grupo de nodos.

Para obtener más información sobre la forma en que el escalador automático del clúster toma decisiones de balanceo, consulta las Preguntas frecuentes sobre ajuste de escala automático en la documentación de Kubernetes.

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

Puedes especificar el tamaño mínimo y máximo de cada grupo de nodos del clúster, y el escalador automático tomará las decisiones de reescalamiento en función de estos límites. Si el tamaño actual del grupo de nodos es inferior al límite mínimo o superior al límite máximo, cuando habilitas el ajuste de escala automático, el sistema espera hasta que se necesite un nodo nuevo en el grupo o hasta que un nodo pueda borrarse de forma segura del grupo.

Límites del ajuste de escala automático

Cuando usas el ajuste de escala automático en los clústeres, los límites de escalamiento del grupo de nodos se determinan según la disponibilidad zonal.

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 \
  --zone us-central1-a \
  --node-locations us-central1-a,us-central1-b,us-central1-f \
  --num-nodes 2 --enable-autoscaling --min-nodes 1 --max-nodes 4

El tamaño total de este clúster es de entre tres y doce nodos repartidos en tres zonas. Si una de las zonas falla, el tamaño total del clúster pasa a ser de entre dos y ocho nodos.

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 en este momento son los siguientes:

  • balanced: El perfil predeterminado
  • optimize-utilization: Prioriza la optimización para el uso en lugar de mantener los recursos libres en el clúster. Cuando se selecciona, el escalador automático del clúster reduce la escala de clústeres de forma más contundente: puede quitar más nodos y quitarlos más rápido. Este perfil se optimizó para usarse con cargas de trabajo por lotes que no son sensibles a la latencia de inicio. En la actualidad, no recomendamos usar este perfil con cargas de trabajo de entrega

En la versión 1.18 y posteriores de GKE, cuando especificas el perfil de ajuste de escala automático optimize-utilization, GKE prefiere programar los Pods en los nodos que ya tienen un uso alto, lo que 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 beta container clusters update example-cluster \
--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 con almacenamiento local
  • 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 PodDisruptionBudget de una aplicación también puede impedir el ajuste de escala automático. Por ejemplo, si borrar un nodo provocaría que se supere el presupuesto, no se reduce la escala del clúster.

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:

Información adicional

Encontrarás 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:

  • PersistentVolumes locales.
  • Escalamiento vertical de un grupo de nodos de tamaño 0 para pods que solicitan recursos más allá de la CPU, la memoria y la GPU (p. Ej., almacenamiento efímero)
  • El escalador automático del clúster admite hasta 5,000 nodos con 30 Pods cada uno. Para obtener más detalles sobre las garantías de escalabilidad, consulta Informe de escalabilidad.
  • 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.

Próximos pasos