> ## Documentation Index > Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt > Use this file to discover all available pages before exploring further. # Escalado automático con KEDA > Cómo Vantage 3.0 autoalojado usa KEDA, Prometheus y los HPA de Kubernetes para escalar las cargas de trabajo compatibles. 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
| Etapa | Componente | Responsabilidad | | ----- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | 1 | Cargas de trabajo de Vantage | Consumen CPU y exponen métricas de la aplicación, como la longitud de la cola y los hilos de worker activos. | | 2 | Métricas de recursos de Kubernetes y Prometheus | Proporcionan el uso de CPU y las métricas de la aplicación de Vantage a los triggers configurados. | | 3 | Operador de KEDA | Supervisa los recursos `ScaledObject` generados por el chart y evalúa sus triggers. | | 4 | HPA de Kubernetes | Usa la recomendación de réplicas generada para cada métrica y selecciona la recomendación más alta. | | 5 | Planificador de Kubernetes | Ubica las réplicas solicitadas en nodos aptos con recursos disponibles. | 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. | Patrón de carga de trabajo | Trigger | Por qué se usa | | --------------------------------------------- | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | API síncronas y servicios de orquestación | Utilización de CPU | La carga de solicitudes suele reflejarse en el consumo de CPU mientras el servicio gestiona el tráfico. | | Procesamiento asíncrono y workers de TechCore | Métricas de cola y worker de Prometheus | La acumulación de trabajo y la actividad del worker indican el trabajo pendiente de forma más directa que la utilización de CPU. | 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: ```bash theme={null} kubectl top nodes kubectl top pods -n $install_namespace ```
### 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: ```promql theme={null} application_worker_priority_queue_length{namespace=""} application_worker_active_threads{namespace=""} ``` * `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: ```bash theme={null} kubectl get deployment --all-namespaces | grep keda-operator kubectl -n observability get service prometheus-operated kubectl -n $install_namespace get servicemonitor ``` En Prometheus, confirma que estas consultas devuelven series para el namespace de tu instalación: ```promql theme={null} application_worker_priority_queue_length{namespace=""} application_worker_active_threads{namespace=""} ``` Para conocer los requisitos de instalación de Prometheus y de la malla de servicios, consulte [Monitorización con Prometheus](/es/vantage/self-hosted/v3.0/monitoring/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: ```yaml theme={null} vantage: keda: enabled: true observability: prometheus: namespace: observability serviceMonitor: create: true ``` 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: ```bash theme={null} kubectl -n $install_namespace get scaledobjects.keda.sh kubectl -n $install_namespace get hpa ``` Espera a que los recursos `ScaledObject` estén listos: ```bash theme={null} kubectl -n $install_namespace wait \ --for=condition=Ready scaledobjects.keda.sh \ --all \ --timeout=5m ``` Inspeccione un recurso individual y su HPA: ```bash theme={null} kubectl -n $install_namespace describe scaledobject kubectl -n $install_namespace get scaledobject -o yaml kubectl -n $install_namespace describe 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 `` 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: ```bash theme={null} kubectl -n $install_namespace get deployment,hpa,pod --watch ``` 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
| Síntoma | Área probable que revisar | | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | No aparecen recursos `ScaledObject` | Confirme `vantage.keda.enabled: true` e inspeccione las aplicaciones de ArgoCD generadas. | | `Ready=False` o `ScaledObjectCheckFailed` | Confirme que usa KEDA 2.17.3 e inspeccione los eventos de `ScaledObject` para detectar un campo de trigger no admitido. | | Las métricas de HPA muestran `` | Revise el servicio de Prometheus, `ServiceMonitor`, los scrape targets, la política de mesh y los resultados de la consulta. | | HPA solicita más réplicas, pero los pods permanecen en `Pending` | Revise la capacidad de los nodos, las cuotas, las solicitudes de recursos, las labels de TechCore, los taints y la programación de volúmenes persistentes. | | Una carga de trabajo se escala cuando su cola parece inactiva | Inspeccione todos los triggers; es posible que haya otro trigger de Prometheus o de CPU activo. | | El comportamiento del escalado cambia después de una actualización | Compare el `ScaledObject` generado con la configuración versionada del chart y confirme que ambos charts de Vantage usen la misma versión. | Para ver los pasos correctivos detallados, consulte [Resolución de problemas de KEDA y Prometheus](/es/vantage/self-hosted/v3.0/troubleshooting#keda-and-prometheus).
## Qué sigue
Configure el scraping y verifique las métricas que utiliza KEDA. Revise los requisitos de KEDA, Prometheus y la capacidad del clúster. Diagnostique ScaledObjects no saludables y métricas no disponibles. Compruebe las versiones compatibles antes de actualizar KEDA o Vantage.