Saltar al contenido principal
KEDA es el motor de escalado automático opcional recomendado para Vantage 3.0 autoalojado. Cuando se habilita, los charts de componentes de Vantage crean recursos ScaledObject para las cargas de trabajo compatibles. KEDA evalúa sus triggers y administra recursos HorizontalPodAutoscaler (HPA) de Kubernetes que aumentan o reducen la escala de las cargas de trabajo.
Los charts de cargas de trabajo de Vantage requieren KEDA 2.17.x. Use KEDA 2.17.3. KEDA 2.18 y versiones posteriores no pueden procesar algunos campos de ScaledObject generados por los charts actuales de Vantage.

​
Cómo funciona el escalado automático

KEDA ajusta el número de réplicas de las cargas de trabajo. No agrega nodos de Kubernetes, no aumenta las cuotas ni convierte en apto para una carga de trabajo a un nodo que no lo es. Coordine KEDA con su autoscaler de nodos u otro proceso de gestión de capacidad.

​
Estrategias de escalado

Los recursos ScaledObject generados usan distintos tipos de triggers según las características de cada carga de trabajo. Los umbrales, los límites de réplicas, las consultas y el comportamiento de HPA generados varían según la carga de trabajo y la versión del chart de Vantage. Considere los recursos ScaledObject generados en su instalación como la referencia definitiva.

​
Triggers de utilización de CPU

Los triggers de CPU comparan la utilización promedio de CPU de una carga de trabajo con el objetivo configurado. La utilización de CPU se calcula en relación con las solicitudes de CPU de la carga de trabajo, por lo que la API de métricas de recursos de Kubernetes debe funcionar correctamente y la carga de trabajo debe conservar solicitudes de CPU válidas. Confirme que las métricas de recursos estén disponibles:

​
Triggers de Prometheus

Los recursos ScaledObject de los worker asíncronos usan métricas de la aplicación Vantage procedentes de Prometheus. Las principales señales son:
  • application_worker_priority_queue_length informa del trabajo en espera para un tipo de worker.
  • application_worker_active_threads informa de los hilos de procesamiento activos. Algunas configuraciones de worker generadas lo usan como segundo trigger de Prometheus junto con la profundidad de la cola: escala el worker de forma preventiva cuando ya no queda ningún hilo de procesamiento libre, para que una tarea recién llegada se procese de inmediato en lugar de esperar a que se acumule trabajo en la cola.
Las consultas generadas por el chart añaden selectores de servicio y de worker específicos de la carga de trabajo, y pueden usar ventanas temporales móviles. No las sustituya por las dos consultas amplias de inspección anteriores. Algunos recursos ScaledObject contienen más de un trigger. Cualquiera de ellos puede solicitar un escalado horizontal, y la HPA usa la recomendación de réplicas más alta. Cuando una carga de trabajo se escala de forma inesperada, inspeccione todos los triggers en lugar de solo el primero.

​
Escale los tipos de worker en proporción a sus skills

El procesamiento de TechCore se divide en tipos de worker, como OCR, Extraction y Classification, y cada tipo de worker escala de forma independiente en su propia cola. Las skills que implemente determinan qué tipos de worker asumen la mayor carga de trabajo: una combinación de skills con mucho OCR incrementa la demanda de workers de OCR, mientras que una combinación centrada en la extracción incrementa la demanda de workers de Extraction. Como los documentos avanzan por estos tipos de worker por etapas, un desequilibrio de capacidad entre etapas se refleja en tiempos de espera, no en errores. Si una etapa tiene menos recursos de los necesarios en comparación con la etapa que la alimenta (por ejemplo, suficiente capacidad de OCR pero muy pocos workers de Extraction), los documentos completan rápidamente la primera etapa y luego quedan en espera durante varios minutos mientras se vacía la cola de la etapa siguiente y sus workers escalan horizontalmente. Supervise la profundidad de la cola por tipo de worker durante una prueba de carga representativa con su combinación de skills de producción y analice con su ABBYY account team los ajustes de los límites relativos de las réplicas.

​
Requisitos previos

Antes de habilitar KEDA, confirma que:
  1. KEDA 2.17.3 está instalado y que su operator y su servidor de API de métricas funcionan correctamente.
  2. La API de métricas de recursos de Kubernetes devuelve datos de CPU.
  3. Se puede acceder a Prometheus en http://prometheus-operated.observability.svc.cluster.local:9090.
  4. El ServiceMonitor de Vantage existe y Prometheus informa que los destinos de Vantage /metrics-text están UP.
  5. Prometheus devuelve valores actuales para las métricas de worker de Vantage.
  6. El clúster tiene suficiente capacidad programable para las réplicas adicionales, incluidos los nodos etiquetados para los workers de TechCore.
El nombre del servicio de Prometheus, el namespace y el puerto del elemento 3 forman un endpoint fijo para los recursos ScaledObject generados. Usa estas comprobaciones antes de continuar:
En Prometheus, confirma que estas consultas devuelven series para el namespace de tu instalación:
Para conocer los requisitos de instalación de Prometheus y de la malla de servicios, consulte Monitorización con Prometheus.

​
Habilitar el escalado automático

Habilite KEDA en la configuración de Vantage y habilite el ServiceMonitor que crea el chart mediante la sección independiente observability de nivel superior:
La sección observability no forma parte de vantage ni del recurso personalizado Vantage. Controla los recursos de monitorización generados directamente por el chart vantage-selfhosted. Aplique los valores mediante la release de Helm vantage-selfhosted existente. ArgoCD crea de forma asíncrona las aplicaciones de los componentes y sus recursos ScaledObject.

​
Compruebe el escalado automático

Enumere los recursos generados:
Espera a que los recursos ScaledObject estén listos:
Inspeccione un recurso individual y su HPA:
Usa el estado con cuidado:
  • Ready=True significa que KEDA aceptó la configuración del trigger.
  • Active=True significa que al menos un trigger está solicitando actividad de escalado en ese momento.
  • Active=False puede ser normal cuando no hay tráfico ni trabajo en cola.
  • Un valor de métrica de HPA de <unknown> indica que Kubernetes no puede obtener un valor actual de esa métrica.
Durante una prueba controlada de la carga de trabajo, supervisa a la vez la carga de trabajo, la HPA y la capacidad del nodo:
Confirma que las réplicas solicitadas pasen a Running. Si aumenta el número deseado del HPA y los pods siguen en Pending, se trata de un problema de capacidad o programación, no de un problema del activador de KEDA.

​
Comprenda el comportamiento generado

Los charts de carga de trabajo de Vantage proporcionan configuraciones específicas para cada carga de trabajo en lo siguiente:
  • Umbrales de activación y consultas de Prometheus.
  • Límites mínimos y máximos de réplicas.
  • Velocidad de aumento de escala y comportamiento de estabilización.
  • Velocidad de reducción de escala y comportamiento de estabilización.
La configuración está diseñada para aumentar la escala rápidamente cuando aparece una acumulación de trabajo y para reducirla con cautela mediante una ventana de estabilización: un período de enfriamiento que mantiene las réplicas en ejecución hasta que la cola haya permanecido inactiva durante un período determinado. Los modelos y los workers de entrenamiento usan un período de enfriamiento más largo que los servicios de API ligeros porque eliminar sus réplicas descarta los modelos almacenados en caché, y volver a cargarlos hace que la siguiente tarea sea notablemente más lenta. Considere las duraciones de ventana de los resources generados como valores de referencia para esa versión del chart, no como objetivos de ajuste. Los valores exactos forman parte de la configuración del producto, no de una recomendación universal de capacidad. Pueden cambiar entre versiones del chart de Vantage a medida que evolucionan las características de la carga de trabajo y los datos de validación.
No copie manifiestos de ScaledObject ni umbrales de otro entorno, y no edite directamente los resources generados. ArgoCD puede restaurar la configuración generada por el chart durante la reconciliación o la actualización. Use solo los valores admitidos del chart de Vantage; póngase en contacto con su equipo de cuenta de ABBYY antes de aplicar configuraciones adicionales de autoescalado.

​
Planifique la capacidad del clúster

El escalado automático no puede compensar un clúster con capacidad insuficiente o con restricciones. Planifique teniendo en cuenta lo siguiente:
  • La tasa máxima de llegada de documentos y el tiempo de espera aceptable en la cola.
  • La duración media del procesamiento y la de percentiles altos para documentos y skills representativos.
  • El tiempo de arranque del pod y de calentamiento del modelo.
  • Las solicitudes de CPU y memoria para cada carga de trabajo que escale de forma simultánea.
  • El tiempo de aprovisionamiento del autoscaler de nodos y el tamaño máximo del pool de nodos.
  • Las cuotas del namespace, los límites del clúster y el rendimiento de descarga desde el registry.
  • Las etiquetas de nodo de TechCore, los taints, los aceleradores y el aislamiento del training-worker.
  • La tolerancia a fallos cuando un nodo o una zona de disponibilidad no están disponibles.
Mida la profundidad de la cola, la latencia de procesamiento, el tiempo de arranque del pod, el número deseado de réplicas de HPA y los pods pendientes durante una prueba de carga representativa. Use esas observaciones al analizar con ABBYY el ajuste específico del entorno.

​
Resolución de problemas

Para ver los pasos correctivos detallados, consulte Resolución de problemas de KEDA y Prometheus.

​
Qué sigue

Monitorización con Prometheus

Configure el scraping y verifique las métricas que utiliza KEDA.

Requisitos previos

Revise los requisitos de KEDA, Prometheus y la capacidad del clúster.

Solución de problemas

Diagnostique ScaledObjects no saludables y métricas no disponibles.

Compatibilidad

Compruebe las versiones compatibles antes de actualizar KEDA o Vantage.