Acerca de los búferes de capacidad

Los búferes de capacidad te ayudan a reducir la latencia de inicio de los Pods para tus cargas de trabajo de Google Kubernetes Engine (GKE), ya que te permiten declarar de forma proactiva niveles de búferes de capacidad activos o en espera en tu clúster. Si declaras la capacidad de reserva con anticipación, puedes lograr inicios de cargas de trabajo más rápidos de manera rentable.

En este documento, se explica cómo funcionan los búferes de capacidad. Para aprender a habilitar y usar los búferes de capacidad, consulta Configura búferes de capacidad.

Cuándo usar búferes de capacidad

Usa búferes de capacidad para las aplicaciones que son sensibles a la latencia de inicio y necesitan escalar con rapidez. Cuando experimentas aumentos repentinos en el tráfico, un búfer activo proporciona capacidad aprovisionada previamente que está diseñada para el escalamiento de baja latencia. Cuando experimentas un aumento sostenido en el tráfico, un búfer en espera proporciona la programación de Pods a un costo más asequible que el aprovisionamiento previo.

Los búferes de capacidad proporcionan los siguientes beneficios:

  • Minimiza la latencia de escalamiento: Los búferes activos proporcionan nodos en ejecución, lo que ayuda a minimizar la latencia. Los búferes en espera se reanudan con rapidez, lo que proporciona una disponibilidad de capacidad más rápida que los nodos nuevos a un costo menor en comparación con los búferes activos.
  • Aprovisionamiento excesivo rentable: Los búferes de capacidad te ayudan a mantener una red de seguridad. Para las cargas de trabajo a gran escala, este enfoque suele ser más rentable que otros métodos de aprovisionamiento excesivo, como reducir los objetivos de uso del escalador automático horizontal de Pods (HPA), lo que puede aumentar la capacidad inactiva de forma lineal a medida que crece el clúster.
  • Cumple con los requisitos de las cargas de trabajo: Tienes control total sobre la configuración del búfer de capacidad. Entre las opciones, se incluye incorporar DaemonSets personalizados para precargar imágenes, ajustar el tiempo de inicio y controlar los tamaños de búfer para adaptarlos a tus necesidades.

Recomendamos los búferes de capacidad para las cargas de trabajo sensibles a la latencia que requieren un escalamiento vertical rápido, como los agentes de IA, la inferencia de IA, las aplicaciones de venta minorista durante los eventos de ofertas o los servidores de juegos durante los picos de actividad de los jugadores.

Cómo funcionan los búferes de capacidad

Implementa un búfer de capacidad con un recurso personalizado CapacityBuffer de Kubernetes para definir un búfer de capacidad libre. El escalador automático del clúster de GKE supervisa los recursos de CapacityBuffer y los trata como demanda pendiente para garantizar que haya capacidad adicional disponible. Si tu clúster no tiene suficiente capacidad para satisfacer las solicitudes de recursos definidas en el búfer, el escalador automático del clúster aprovisiona nodos adicionales.

Cuando una carga de trabajo escala verticalmente, GKE programa los Pods pendientes en la capacidad disponible en el siguiente orden de prioridad:

  1. Ejecuta nodos en un búfer activo
  2. Nodos en ejecución en un búfer en espera que aún no se suspendieron
  3. Nodos suspendidos en un búfer en espera
  4. Nodos recién aprovisionados

Para programar los Pods pendientes lo más rápido posible, GKE usa la capacidad de búfer disponible antes de aprovisionar nodos nuevos. Esta prioridad se aplica incluso si una regla de mayor prioridad en una ComputeClass personalizada aprovisionaría un nodo nuevo.

La capacidad del búfer no se restringe a la carga de trabajo a la que se hace referencia en el campo scalableRef. Cualquier Pod pendiente cuyas restricciones de programación, como los selectores de nodos, las tolerancias y las solicitudes de recursos, coincidan con la configuración del nodo de búfer puede reclamar esa capacidad. Para reservar un búfer de capacidad para una carga de trabajo específica, configura la separación de cargas de trabajo agregando tolerancias y selectores de nodos (o afinidades de nodos) coincidentes tanto a la carga de trabajo como al búfer de capacidad. Para obtener instrucciones, consulta Dedica un búfer de capacidad a una carga de trabajo específica.

Cuando una carga de trabajo consume capacidad de un búfer activo, el escalador automático del clúster lo reabastece reanudando un nodo de un búfer en espera compatible, si existe, o aprovisionando un nodo nuevo. Cuando una carga de trabajo o un búfer activo consumen un nodo de un búfer en espera, el escalador automático del clúster vuelve a llenar el búfer en espera aprovisionando y suspendiendo un nodo nuevo. Cuando tu carga de trabajo reduce la escala verticalmente y los nodos se usan de forma insuficiente, el escalador automático de clústeres borra los nodos en ejecución excedentes después de la ventana de estabilización de reducción de escala vertical en lugar de volver a suspenderlos en el búfer en espera. Para reponer el búfer en espera, GKE aprovisiona y suspende los nodos nuevos por separado.

Estrategias de búfer de capacidad

Puedes configurar los búferes de capacidad con diferentes estrategias de aprovisionamiento según tus requisitos de latencia y costo.

Búfer activo

Un búfer activo proporciona nodos en ejecución para el escalamiento de baja latencia de las cargas de trabajo que se ajustan a la capacidad reservada. Debido a que los nodos ya se están ejecutando, proporcionan una latencia mínima para reclamar Pods durante un evento de escalamiento vertical.

Búfer en espera

Un búfer en espera proporciona nodos suspendidos. La estrategia de espera es más rentable que la estrategia activa, pero introduce una pequeña demora para reanudar el nodo antes de que acepte cargas de trabajo.

Costo y precios

Los búferes de capacidad se proporcionan sin cargo adicional, además de los costos de procesamiento estándar basados en nodos, que se aplican a los grupos de nodos de Standard y a las cargas de trabajo de Autopilot que seleccionan hardware específico. Los búferes de capacidad no admiten el modelo de facturación basado en Pods.

La facturación de los nodos subyacentes varía según el tipo de búfer:

  • Búferes activos: Se te cobran tarifas de procesamiento estándar basadas en nodos por las VMs en ejecución que GKE mantiene para que sirvan como capacidad de búfer activa.
  • Búferes en espera: Mientras las instancias de VM están suspendidas, no pagas costos de procesamiento (CPU o memoria). Se generan cargos menores por almacenamiento (por ejemplo, discos de arranque de VM y estado de memoria almacenado) y costos por recursos asociados, como direcciones IP externas estáticas. Cuando GKE reanuda las VMs en espera para alojar cargas de trabajo, se aplican las tarifas de procesamiento estándar basadas en nodos. Para obtener más información, consulta Precios de instancias suspendidas.

CRD de CapacityBuffer

Para configurar un búfer de capacidad, crea una CustomResourceDefinition (CRD) de CapacityBuffer. Puedes configurar el búfer de capacidad para que cumpla con diferentes criterios:

  • Réplicas fijas: Especifica una cantidad fija de Pods de búfer para crear en función de las solicitudes de recursos de una plantilla de Pods de referencia. Esta configuración es la forma más sencilla de crear un búfer de un tamaño conocido.
  • Límites de recursos: Especifica la cantidad total de CPU y memoria que debe reservar el búfer. El controlador calcula cuántos Pods de búfer se deben crear en función de las solicitudes de recursos de una plantilla de Pods de referencia.
  • Basado en porcentajes: Define el tamaño del búfer como un porcentaje de un objeto escalable existente que define un subrecurso de escalamiento (como un Deployment, un StatefulSet, un ReplicaSet o un Job). El tamaño del búfer se ajusta de forma dinámica a medida que escala la carga de trabajo de referencia. Los búferes de capacidad basados en porcentajes solo se admiten para los objetos que implementan el subrecurso de escalamiento de Kubernetes.

Puedes combinar estas opciones, por ejemplo, configurando replicas y percentage para que GKE use el valor más grande como un piso mínimo y configurando limits como un límite superior.

Para obtener más información, consulta la documentación de referencia de la CRD de CapacityBuffer.

Prácticas recomendadas

Para optimizar la rentabilidad y la capacidad de respuesta cuando configures búferes de capacidad, usa las siguientes recomendaciones:

  • Usa una estrategia de costo óptimo que priorice el modo en espera: Prioriza los búferes en espera si tus cargas de trabajo pueden tolerar un breve retraso de escalamiento vertical de aproximadamente 30 segundos. Esta estrategia evita los arranques en frío de VMs nuevas sin tener que incurrir en el costo total de las VMs activas.
  • Usa búferes activos para cargas de trabajo sensibles a la latencia: Usa búferes activos para las cargas de trabajo que no pueden tolerar los tiempos de reanudación de los nodos cuando el tiempo de programación de los Pods debe ser lo más bajo posible.
  • Usa una estrategia híbrida para equilibrar el rendimiento y el costo: Combina un búfer activo pequeño con un búfer en espera más grande para obtener una configuración rentable. GKE prioriza volver a llenar el búfer activo reanudando los nodos del búfer en espera (lo que tarda unos 30 segundos), mientras que los nodos nuevos se aprovisionan en segundo plano para rellenar el búfer en espera. Esta configuración absorbe los picos iniciales con capacidad activa y se adapta al crecimiento sostenido con la capacidad en espera de menor costo.
  • Ajusta el tamaño de los búferes activos para los aumentos repentinos iniciales: Define el tamaño de tu búfer activo para cubrir los aumentos repentinos iniciales de réplicas que esperas encontrar antes de que se puedan reanudar los nodos del búfer en espera.
  • Ajusta el tamaño de los búferes en espera para la carga sostenida: Define búferes en espera que sean suficientes para cubrir la carga extendida que esperas encontrar, de modo que los búferes puedan rellenarse en segundo plano desde un inicio en frío. Un búfer en espera con un tamaño suficiente puede reducir la latencia máxima de programación de Pods al tiempo que se tarda en reanudar un nodo, que es de aproximadamente 30 segundos. Cuando el búfer de capacidad comienza a usarse y se vuelve a llenar, los nodos de búfer nuevos pasan a un estado activo antes de suspenderse. Esta estrategia ayuda a aumentar la capacidad activa durante una carga prolongada.
  • Usa el simulador de búfer: Experimenta con diferentes tamaños de búfer activos y en espera para obtener el mejor resultado para tu carga de trabajo específica. Ejecuta simulaciones del comportamiento de escalamiento de las cargas de trabajo con el simulador de búferes de GKE de código abierto en https://github.com/gke-labs/buffers-simulator para ajustar las reglas de dimensionamiento de los búferes y alcanzar tus objetivos de rendimiento.
  • Reduce la latencia de inicio en frío cuando se escalan las cargas de trabajo desde cero: vincula las cargas de trabajo que se escalan desde y hacia cero con HPA (minReplicas: 0) con búferes de capacidad. Cuando la demanda aumenta y la carga de trabajo se escala verticalmente desde cero, GKE programa de inmediato los Pods en nodos de búfer precalentados en lugar de esperar a que se aprovisionen nodos de procesamiento nuevos.
  • Considera el perfil de escalado automático optimize-utilization en los clústeres de Standard: debido a que los búferes de capacidad ya mantienen un margen de capacidad adicional, puedes configurar el perfil de escalado automático optimize-utilization (--autoscaling-profile=optimize-utilization) para que el escalador automático del clúster reduzca la escala verticalmente de los nodos con poco uso con mayor rapidez después de que disminuya la demanda. Este perfil también empaqueta los Pods de forma más ajustada en los nodos, por lo que debes evaluar si el empaquetado en contenedores más ajustado se adapta a los requisitos de disponibilidad de tu carga de trabajo antes de habilitarlo.

Calcula el tamaño del búfer

Cuando combinas un búfer activo con uno en espera, puedes estimar la cantidad de réplicas de búfer o Pods de búfer simulados que se necesitan para absorber un aumento repentino del tráfico. Calcula esta estimación con tu tasa de escalamiento vertical esperada en Pods por segundo, la latencia de reanudación de los nodos en espera y la latencia de creación de nodos en frío. Estas latencias varían según la serie de máquinas de VM y la configuración del nodo. Por ejemplo, la latencia de reanudación del nodo en espera suele ser de 30 a 35 segundos, y la latencia de creación de un nodo nuevo suele ser de 60 a 120 segundos, según la serie de máquinas. Para medir las latencias reales de tu clúster, consulta Supervisa las métricas de latencia de inicio.

  1. Calcula el tamaño del búfer activo para cubrir los Pods creados mientras se reanudan los nodos en espera:

    \[ \text{Active buffer replicas} = \text{Expected scale-up rate} \times \text{Standby node resume latency} \]

  2. Calcula el tamaño del búfer en espera para cubrir los Pods restantes creados mientras los nodos inactivos nuevos terminan de aprovisionarse:

    \[ \text{Standby buffer replicas} = (\text{Expected scale-up rate} \times \text{Cold node creation latency}) - \text{Active buffer replicas} \]

Por ejemplo, si tu carga de trabajo escala verticalmente a 2 Pods por segundo, los nodos en espera tardan 30 segundos en reanudarse y los nodos fríos nuevos tardan 90 segundos en aprovisionarse:

  • Tu búfer activo necesita \( 2 \times 30 = 60 \) réplicas para absorber los primeros 30 segundos del aumento repentino.
  • Tu búfer en espera necesita \( (2 \times 90) - 60 = 120 \) réplicas para cubrir los 60 segundos restantes mientras el escalador automático del clúster aprovisiona nodos fríos nuevos en segundo plano para reponer tus búferes. Si el aumento continúa más allá de los 90 segundos con la misma tasa, esos nodos reabastecidos estarán listos para entregar los Pods entrantes sin tiempo de espera.

Para probar estas estimaciones con tus patrones de escalamiento de cargas de trabajo, ejecuta simulaciones con el simulador de búferes de GKE.

Escalabilidad

Los búferes de capacidad no tienen límites estrictos, pero superar la escala recomendada puede ralentizar el aprovisionamiento de nodos y la programación de Pods. Las réplicas de búfer son los Pods de búfer simulados para los que un búfer reserva capacidad, no nodos. Para obtener un rendimiento confiable, mantén tu clúster dentro de los siguientes lineamientos:

Escala recomendada del búfer de capacidad por clúster
Tipo de búfer Total de réplicas de búfer por clúster Búferes por clúster
Búferes activos Hasta 7,000 Hasta 100
Búferes en espera Hasta 5,000 Hasta 25

En el caso de los búferes activos y en espera, evita crear muchos búferes que requieran un grupo de nodos independiente, como los búferes que usan diferentes ComputeClasses o diferentes parámetros de configuración de separación de cargas de trabajo. Cuando el escalador automático del clúster aprovisiona nodos nuevos, escala verticalmente un grupo de nodos a la vez, por lo que se necesita más tiempo para llenar y volver a llenar los búferes con nodos nuevos a medida que agregas más búferes. Esta limitación no se aplica a la reanudación de nodos suspendidos en búferes de espera.

Requisitos y limitaciones

Los búferes de capacidad tienen los siguientes requisitos y limitaciones:

  • Los búferes de capacidad están disponibles para los clústeres de GKE que ejecutan la versión 1.37.1-gke.3020000 o posterior.
  • Los búferes de capacidad solo admiten cargas de trabajo que usan un modelo de facturación basado en nodos para grupos de nodos de Standard y grupos de nodos de Autopilot que seleccionan hardware específico. Los búferes de capacidad no admiten cargas de trabajo que usen el modelo de facturación basado en Pods.
  • En los clústeres de Standard, te recomendamos que habilites la creación automática de grupos de nodos. La creación automática de grupos de nodos permite que el escalador automático del clúster cree grupos de nodos nuevos según las solicitudes de recursos en tu CapacityBuffer. Si no habilitas la creación automática de grupos de nodos, el escalador automático del clúster solo escala verticalmente los grupos de nodos existentes.
  • Los búferes de capacidad activos y en espera consumen cuotas de manera diferente:
    • La ejecución de nodos en un búfer activo se descuenta de tus cuotas de Compute Engine de CPU virtual, memoria, disco y dirección IP.
    • Los nodos suspendidos en un búfer en espera no se consideran para las cuotas de CPU virtuales o memoria de Compute Engine mientras están suspendidos. Sin embargo, siguen consumiendo cuotas de direcciones IP y cuotas de disco, incluida la cuota de Persistent disk standard (GB) que se usa para almacenar la memoria de la VM suspendida.
    • En Kubernetes, las unidades de búfer en espera activas y suspendidas se consideran para las cuotas de recursos de Kubernetes en tu espacio de nombres como si los Pods de búfer se estuvieran ejecutando.
  • Si la dependencia de configuración de CapacityBuffer (por ejemplo, un PodTemplate) selecciona una ComputeClass personalizada, la dependencia debe definir las tolerancias, los selectores de nodos o las clases de entorno de ejecución necesarios para programar en los nodos aprovisionados (por ejemplo, los requisitos de GKE Sandbox). Para obtener instrucciones, consulta la documentación de ComputeClass personalizada.

Los búferes en espera tienen las siguientes limitaciones adicionales:

¿Qué sigue?