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.
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.
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.
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 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 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.
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 VMs Spot.
- El escalador automático de clústeres considera las solicitudes de contenedor init antes de programar los Pods. Las solicitudes de contenedor Init pueden usar cualquier recurso sin asignar disponible en los nodos que podrían evitar que se programen los Pods. El escalador automático del clúster sigue las mismas reglas de cálculo de solicitudes que usa Kubernetes. Para obtener más información, consulta Usa 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 detecta los cambios manuales en los nodos y los grupos de nodos para escalar verticalmente.
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.
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 de GKE. 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 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 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 prioriza el uso de reservas sin usar y tiene en cuenta las restricciones actuales de los recursos disponibles. Esta política se recomienda 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 para los clústeres estándar. El perfilbalanced
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:
- ¿Cómo funciona la reducción de escala?
- ¿El escalador automático del clúster funciona con PodDisruptionBudget para la reducción de la escala?
- ¿Qué tipos de pods pueden impedir que el escalador automático del clúster quite un nodo?
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 de16x16
, 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.
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:
- Actualmente, 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 mediante
eventResult
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.
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.
¿Qué sigue?
- Aprende a realizar el ajuste de escala automático de tus nodos.
- Aprende a actualizar tus nodos automáticamente.
- Aprende a reparar tus nodos automáticamente.
- Aprende a reducir los tiempos de extracción de imágenes en nodos nuevos.