> ## 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. # Mise à l’échelle automatique avec KEDA > Comment Vantage 3.0 auto-hébergé utilise KEDA, Prometheus et les HPA Kubernetes pour adapter la capacité des charges de travail prises en charge. KEDA est l’Engine de mise à l’échelle automatique facultatif recommandé pour Vantage 3.0 auto-hébergé. Lorsque vous l’activez, les charts des composants Vantage créent des ressources `ScaledObject` pour les charges de travail prises en charge. KEDA évalue leurs déclencheurs et gère les ressources Kubernetes HorizontalPodAutoscaler (HPA), qui adaptent automatiquement la capacité des charges de travail à la hausse comme à la baisse. Les charts de charge de travail Vantage nécessitent KEDA 2.17.x. Utilisez KEDA 2.17.3. KEDA 2.18 et les versions ultérieures ne peuvent pas traiter certains champs `ScaledObject` générés par les charts Vantage actuels.
## Comment fonctionne la mise à l’échelle automatique
| Stage | Component | Responsibility | | ----- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | Charges de travail Vantage | Consomment du CPU et exposent des métriques d’application, telles que la longueur de la file d’attente et le nombre de threads de travail actifs. | | 2 | Métriques de ressources Kubernetes et Prometheus | Fournissent l’utilisation du CPU et les métriques d’application Vantage aux déclencheurs configurés. | | 3 | Opérateur KEDA | Surveille les ressources `ScaledObject` générées par le chart et évalue leurs déclencheurs. | | 4 | HPA Kubernetes | Utilise la recommandation de réplicas produite pour chaque métrique et retient la recommandation la plus élevée. | | 5 | Planificateur Kubernetes | Place les réplicas demandés sur des nœuds éligibles disposant de ressources disponibles. | KEDA modifie le nombre de réplicas des charges de travail. Il n’ajoute pas de nœuds Kubernetes, n’augmente pas les quotas et ne rend pas éligible un nœud qui ne l’est pas pour une charge de travail. Coordonnez KEDA avec votre autoscaler de nœuds ou tout autre processus de gestion de capacité.
## Stratégies de scalabilité
Les ressources `ScaledObject` générées utilisent différents types de déclencheurs selon les caractéristiques des charges de travail. | Profil de charge de travail | Déclencheur | Pourquoi il est utilisé | | ------------------------------------------ | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | API synchrones et services d’orchestration | Utilisation du CPU | La charge des requêtes se traduit généralement par une consommation CPU lorsque le service traite le trafic. | | Traitement asynchrone et workers TechCore | Métriques Prometheus de file d’attente et de workers | L’arriéré et l’activité des workers indiquent plus directement le travail en attente que l’utilisation du CPU. | Les seuils générés, les limites de réplicas, les requêtes et le comportement du HPA diffèrent selon la charge de travail et la version du chart Vantage. Considérez les ressources `ScaledObject` générées dans votre installation comme la référence.
### Déclencheurs d’utilisation du CPU
Les déclencheurs CPU comparent l’utilisation moyenne du CPU d’une charge de travail à l’objectif configuré. L’utilisation du CPU est calculée par rapport aux requêtes CPU de la charge de travail. L’API Kubernetes des métriques de ressources doit donc être opérationnelle, et la charge de travail doit conserver des requêtes CPU valides. Vérifiez que les métriques de ressources sont disponibles : ```bash theme={null} kubectl top nodes kubectl top pods -n $install_namespace ```
### Déclencheurs Prometheus
Les ressources `ScaledObject` des workers asynchrones utilisent les métriques applicatives de Vantage issues de Prometheus. Les signaux principaux sont : ```promql theme={null} application_worker_priority_queue_length{namespace=""} application_worker_active_threads{namespace=""} ``` * `application_worker_priority_queue_length` indique le volume de travail en attente pour un type de worker. * `application_worker_active_threads` indique le nombre de threads de traitement actifs. Certaines configurations de worker générées l’utilisent comme second déclencheur Prometheus, en plus de la profondeur de la file d’attente : cela augmente préventivement le nombre de workers lorsqu’il ne reste plus de threads de traitement disponibles, afin qu’une nouvelle tâche soit prise en charge immédiatement au lieu d’attendre qu’un engorgement de la file d’attente se forme. Les requêtes générées par le chart ajoutent des sélecteurs de service et de worker propres à la charge de travail et peuvent utiliser des fenêtres temporelles glissantes. Ne les remplacez pas par les deux requêtes d’inspection générales ci-dessus. Certaines ressources `ScaledObject` contiennent plusieurs déclencheurs. N’importe lequel peut demander une montée en charge, et le HPA utilise la recommandation du nombre de réplicas la plus élevée. Lorsqu’une charge de travail change d’échelle de manière inattendue, inspectez tous les déclencheurs, et pas seulement le premier.
### Dimensionnez les types de workers en fonction de vos compétences
Le traitement TechCore est réparti entre différents types de workers, tels que l’OCR, l’Extraction et la Classification, et chaque type de worker monte en charge indépendamment dans sa propre file d’attente. Les compétences que vous déployez déterminent quels types de workers supportent la plus grande charge de travail : un ensemble de compétences fortement axé sur l’OCR augmente la demande en workers OCR, tandis qu’un ensemble davantage axé sur l’extraction augmente la demande en workers d’Extraction. Comme les documents passent par ces types de workers par étapes, un déséquilibre de capacité entre les étapes se traduit par de l’attente plutôt que par des erreurs. Si une étape est sous-dimensionnée par rapport à celle qui l’alimente (par exemple, une capacité OCR suffisante mais trop peu de workers d’Extraction), les documents franchissent rapidement la première étape, puis restent en attente pendant plusieurs minutes, le temps que la file d’attente en aval se résorbe et que ses workers montent en charge. Surveillez la longueur de la file d’attente pour chaque type de worker pendant un test de charge représentatif avec votre ensemble de compétences de production, puis discutez des ajustements des limites relatives des réplicas avec l’équipe ABBYY en charge de votre compte.
## Prérequis
Avant d’activer KEDA, vérifiez les points suivants : 1. KEDA 2.17.3 est installé et son opérateur ainsi que son serveur d’API de métriques sont en bon état de fonctionnement. 2. L’API de métriques des ressources Kubernetes renvoie des données CPU. 3. Prometheus est accessible à l’adresse `http://prometheus-operated.observability.svc.cluster.local:9090`. 4. Le `ServiceMonitor` de Vantage existe et Prometheus indique que les cibles Vantage `/metrics-text` sont `UP`. 5. Prometheus renvoie les valeurs actuelles des métriques des workers Vantage. 6. Le cluster dispose d’une capacité disponible suffisante pour planifier les réplicas supplémentaires, y compris sur les nœuds étiquetés pour les workers TechCore. Le nom du service Prometheus, le namespace et le port mentionnés au point 3 constituent un point de terminaison fixe pour les ressources `ScaledObject` générées. Effectuez ces vérifications avant de continuer : ```bash theme={null} kubectl get deployment --all-namespaces | grep keda-operator kubectl -n observability get service prometheus-operated kubectl -n $install_namespace get servicemonitor ``` Dans Prometheus, vérifiez que ces requêtes renvoient des séries pour le namespace de votre installation : ```promql theme={null} application_worker_priority_queue_length{namespace=""} application_worker_active_threads{namespace=""} ``` Pour connaître les exigences relatives à l’installation de Prometheus et au maillage de services, consultez [Monitoring avec Prometheus](/fr/vantage/self-hosted/v3.0/monitoring/prometheus).
## Activer la mise à l’échelle automatique
Activez KEDA dans la configuration de Vantage et activez le `ServiceMonitor` créé par le chart via la section `observability` distincte de premier niveau : ```yaml theme={null} vantage: keda: enabled: true observability: prometheus: namespace: observability serviceMonitor: create: true ``` La section `observability` ne fait pas partie de `vantage` ni de la ressource personnalisée `Vantage`. Elle contrôle les ressources de supervision générées directement par le chart `vantage-selfhosted`. Appliquez ces valeurs via votre release Helm `vantage-selfhosted` existante. ArgoCD crée de manière asynchrone les applications des composants et leurs ressources `ScaledObject`.
## Vérifier la mise à l’échelle automatique
Listez les ressources générées : ```bash theme={null} kubectl -n $install_namespace get scaledobjects.keda.sh kubectl -n $install_namespace get hpa ``` Attendez que les ressources `ScaledObject` soient prêtes : ```bash theme={null} kubectl -n $install_namespace wait \ --for=condition=Ready scaledobjects.keda.sh \ --all \ --timeout=5m ``` Inspectez une ressource spécifique et son HPA : ```bash theme={null} kubectl -n $install_namespace describe scaledobject kubectl -n $install_namespace get scaledobject -o yaml kubectl -n $install_namespace describe hpa ``` Utilisez le statut avec précaution : * `Ready=True` signifie que KEDA a accepté la configuration du déclencheur. * `Active=True` signifie qu’au moins un déclencheur sollicite actuellement une mise à l’échelle. * `Active=False` peut être normal lorsqu’il n’y a ni trafic ni travail en file d’attente. * Une valeur de métrique HPA de `` indique que Kubernetes ne peut pas obtenir la valeur actuelle de cette métrique. Lors d’un test contrôlé de charge de travail, surveillez conjointement la charge de travail, le HPA et la capacité des nœuds : ```bash theme={null} kubectl -n $install_namespace get deployment,hpa,pod --watch ``` Vérifiez que les réplicas demandés passent à l’état `Running`. Si le nombre souhaité par le HPA augmente alors que les pods restent à l’état `Pending`, il s’agit d’un problème de capacité ou d’ordonnancement, et non d’un problème de déclencheur KEDA.
## Comprendre le comportement généré
Les charts de charge de travail Vantage fournissent des paramètres propres à chaque charge de travail pour : * Les seuils de déclenchement et les requêtes Prometheus. * Les limites minimale et maximale du nombre de réplicas. * Le rythme de mise à l’échelle et le comportement de stabilisation. * Le rythme de réduction et le comportement de stabilisation. La configuration est conçue pour monter rapidement en charge lorsqu’un arriéré apparaît, puis pour réduire la capacité avec prudence au moyen d’une fenêtre de stabilisation : une période de refroidissement qui maintient les réplicas en cours d’exécution jusqu’à ce que la file d’attente soit restée inactive pendant une durée définie. Les workers de modèles et d’entraînement utilisent une période de refroidissement plus longue que les services d’API légers, car la suppression de leurs réplicas vide les modèles mis en cache, et le rechargement de ces modèles ralentit sensiblement la tâche suivante. Considérez les durées de fenêtre de vos ressources générées comme des valeurs de référence pour cette version du chart, et non comme des paramètres à ajuster. Les valeurs exactes relèvent de la configuration du produit, et non d’une recommandation universelle de capacité. Elles peuvent changer selon les versions du chart Vantage, à mesure que les caractéristiques de la charge de travail et les données de validation évoluent. Ne copiez pas de manifestes `ScaledObject` ou de seuils depuis un autre environnement, et ne modifiez pas directement les ressources générées. ArgoCD peut restaurer la configuration générée par le chart lors de la réconciliation ou d’une mise à niveau. Utilisez uniquement les valeurs de chart Vantage prises en charge ; contactez l’équipe ABBYY en charge de votre compte avant d’appliquer des remplacements d’autoscaling supplémentaires.
## Planifier la capacité du cluster
La mise à l’échelle automatique ne peut pas compenser un cluster sous-dimensionné ou soumis à des contraintes. Tenez compte des éléments suivants : * Le taux d’arrivée maximal des documents et le temps d’attente acceptable dans la file d’attente. * La durée de traitement moyenne et aux percentiles supérieurs pour des documents et des compétences représentatifs. * Le temps de démarrage des pods et de préchauffage du modèle. * Les demandes de CPU et de mémoire pour chaque charge de travail mise à l’échelle simultanément. * Le temps de provisionnement du node-autoscaler et la taille maximale du pool de nœuds. * Les quotas de namespace, les limites du cluster et le débit de récupération depuis le registry. * Les labels de nœud TechCore, les taints, les accélérateurs et l’isolation des workers d’entraînement. * La tolérance aux pannes lorsqu’un nœud ou une zone de disponibilité est indisponible. Mesurez la longueur de la file d’attente, la latence de traitement, le temps de démarrage des pods, le nombre de réplicas souhaité par le HPA et les pods en attente pendant un test de charge représentatif. Appuyez-vous sur ces observations lorsque vous échangez avec ABBYY au sujet des réglages propres à l’environnement.
## Dépannage
| Symptôme | Élément à inspecter en priorité | | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Aucune ressource `ScaledObject` n’apparaît | Vérifiez que `vantage.keda.enabled: true` est bien défini et examinez les applications ArgoCD générées. | | `Ready=False` ou `ScaledObjectCheckFailed` | Vérifiez que vous utilisez KEDA 2.17.3 et examinez les événements du `ScaledObject` pour repérer un champ de déclencheur non pris en charge. | | Les métriques HPA affichent `` | Vérifiez le service Prometheus, `ServiceMonitor`, les cibles de collecte, la politique de maillage et les résultats de requête. | | HPA demande davantage de réplicas mais les pods restent `Pending` | Vérifiez la capacité des nœuds, les quotas, les demandes de ressources, les labels TechCore, les taints et la planification des volumes persistants. | | Une charge de travail se met à l’échelle alors que sa file d’attente semble inactive | Examinez tous les déclencheurs ; un autre déclencheur Prometheus ou CPU est peut-être actif. | | Le comportement de mise à l’échelle change après une mise à niveau | Comparez le `ScaledObject` généré à la configuration versionnée du chart et vérifiez que les deux charts Vantage utilisent la même version. | Pour des étapes correctives détaillées, consultez [Dépannage de KEDA et Prometheus](/fr/vantage/self-hosted/v3.0/troubleshooting#keda-and-prometheus).
## Étapes suivantes
Configurez le scraping et vérifiez les métriques utilisées par KEDA. Consultez les exigences relatives à KEDA, Prometheus et à la capacité du cluster. Diagnostiquez les problèmes de ScaledObjects défaillants et de métriques indisponibles. Vérifiez les versions prises en charge avant de mettre à niveau KEDA ou Vantage.