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 capacidad de reserva con anticipación, puedes lograr inicios más rápidos de las cargas de trabajo de una manera rentable.

En este documento, se explica cómo funcionan los búferes de capacidad. Si deseas obtener información para habilitar y usar los búferes de capacidad, consulta Cómo configurar búferes de capacidad.

Cuándo usar los búferes de capacidad

Usa búferes de capacidad para las aplicaciones que son sensibles a la latencia de inicio y necesitan escalar rápidamente. 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 de reserva proporciona 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 del escalamiento: Los búferes activos proporcionan nodos en ejecución, lo que ayuda a minimizar la latencia. Los búferes en espera se reanudan rápidamente, lo que proporciona una disponibilidad de capacidad más rápida que los nodos nuevos a un costo más bajo 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 tu clúster.
  • Cumple con los requisitos de la carga de trabajo: Tienes control total sobre la configuración de tu búfer de capacidad. Entre las opciones, se incluyen la incorporación de DaemonSets personalizados para precargar imágenes, el ajuste del tiempo de inicio y el control de los tamaños del búfer para satisfacer tus necesidades.

Recomendamos los búferes de capacidad para las cargas de trabajo sensibles a la latencia que requieren un aumento rápido de la escala, como los agentes de IA, la inferencia de IA, las aplicaciones de venta minorista durante los eventos de ventas o los servidores de juegos durante la actividad máxima 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 de reserva 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 se aumenta la escala de una carga de trabajo de alta prioridad, GKE programa la carga de trabajo en la capacidad disponible del búfer de inmediato. Esta programación inmediata se aplica a la cantidad de réplicas o a la cantidad de recursos que se reservan en el búfer, lo que evita la demora típica asociada al aprovisionamiento de nodos. Cuando una carga de trabajo usa una unidad de búfer, el escalador automático del clúster aprovisiona un nodo nuevo para reabastecer el búfer.

Estrategias de búfer de capacidad

Puedes configurar 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 ajuste de escala de baja latencia de cargas de trabajo que se ajustan a la capacidad reservada. Como los nodos ya se están ejecutando, proporcionan una latencia mínima para reclamar Pods durante un evento de aumento de escala.

Búfer de espera

Un búfer de espera proporciona nodos suspendidos. La estrategia de reserva 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.

Costos y precios

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

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

CRD de CapacityBuffer

Para configurar un búfer de capacidad, crea un 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 a la que se hace 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 Pod a la que se hace referencia.
  • Basado en porcentaje: Define el tamaño del búfer como un porcentaje de un objeto escalable existente que define un subrecurso de escala (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 se 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 escala de Kubernetes.

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

Prácticas recomendadas

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

  • Usa una estrategia de reserva primero y óptima en cuanto a costos: Prioriza los búferes de reserva si tus cargas de trabajo pueden tolerar una breve demora en el aumento de escala de aproximadamente 30 segundos. Esta estrategia evita los inicios en frío de nodos 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 cargas de trabajo que no pueden tolerar los tiempos de reanudación de nodos cuando el tiempo de programación de 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 de reserva más grande para lograr una configuración rentable. GKE prioriza el reabastecimiento del 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 reabastecer el búfer en espera. Esta configuración absorbe los picos iniciales con capacidad activa y admite el crecimiento sostenido con la capacidad de reserva de menor costo.
  • Tamaño de los búferes activos para las ráfagas 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.
  • Tamaño de los búferes de reserva para la carga sostenida: Define búferes de reserva que sean suficientes para cubrir la carga extendida que esperas encontrar, de modo que los búferes se puedan volver a llenar en segundo plano desde un inicio en frío. Un búfer de reserva de 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 se comienza a usar el búfer de capacidad 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 la carga de trabajo con el simulador de búferes de GKE de código abierto en https://github.com/gke-labs/buffers-simulator para ajustar tus reglas de dimensionamiento de búferes y alcanzar tus objetivos de rendimiento.
  • Reduce la latencia de inicio en frío cuando se escalan cargas de trabajo desde cero: Asocia las cargas de trabajo que se escalan a cero y desde cero con el HPA (minReplicas: 0) con búferes de capacidad. Cuando aumenta la demanda y la carga de trabajo se escala 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.

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.35.2-gke.1842000 o posterior para los búferes activos, y la versión 1.36.0-gke.2253000 para los búferes en espera.
  • Los búferes de capacidad solo admiten cargas de trabajo que usan un modelo de facturación basado en nodos para los grupos de nodos Standard y los grupos de nodos de Autopilot que seleccionan hardware específico. Los búferes de capacidad no admiten cargas de trabajo que usan el modelo de facturación basado en Pods.
  • En los clústeres de Standard, te recomendamos que habilites el aprovisionamiento automático de nodos. El aprovisionamiento automático 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 el aprovisionamiento automático de nodos, el escalador automático del clúster solo ajustará la escala verticalmente de los grupos de nodos existentes.
  • Los búferes de capacidad activa y de reserva se tienen en cuenta para las cuotas de Compute Engine.
  • Si tu dependencia de configuración de CapacityBuffer (por ejemplo, un PodTemplate) selecciona un ComputeClass personalizado, la dependencia debe definir las tolerancias, los selectores de nodos o las clases de tiempo de ejecución necesarios para programar en los nodos aprovisionados (por ejemplo, requisitos para GKE Sandbox). Para obtener instrucciones, consulta la documentación de ComputeClass personalizada.

Los búferes de reserva tienen las siguientes limitaciones adicionales:

  • Se admiten en clústeres de Standard con el aprovisionamiento automático de nodos habilitado.
  • Se admiten en clústeres de Autopilot que ejecutan la versión 1.36.0-gke.2853000 o posterior.
  • No se admiten nodos con GPUs o TPUs adjuntas.
  • Las SSD locales no son compatibles.
  • No se admiten los nodos confidenciales de Google Kubernetes Engine.
  • Debes conocer las limitaciones relacionadas con las operaciones de suspensión y reanudación de Compute Engine. Estas son algunas limitaciones clave:
    • No se admiten nodos con discos protegidos por claves de encriptación proporcionadas por el cliente (CSEK).
    • No se admiten nodos con más de 208 GB de memoria.
    • No se admiten las instancias de Bare Metal.
    • El SO del nodo debe admitir señales de suspensión S3 de ACPI.
    • La duración del proceso de suspensión es proporcional al tamaño de la memoria.
    • La reanudación depende de la disponibilidad de los recursos subyacentes necesarios para reanudar la operación.

¿Qué sigue?