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 :

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 :

application_worker_priority_queue_length{namespace="<install-namespace>"}
application_worker_active_threads{namespace="<install-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 :

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 :

application_worker_priority_queue_length{namespace="<install-namespace>"}
application_worker_active_threads{namespace="<install-namespace>"}

Pour connaître les exigences relatives à l’installation de Prometheus et au maillage de services, consultez Monitoring avec 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 :

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 :

kubectl -n $install_namespace get scaledobjects.keda.sh
kubectl -n $install_namespace get hpa

Attendez que les ressources ScaledObject soient prêtes :

kubectl -n $install_namespace wait \
  --for=condition=Ready scaledobjects.keda.sh \
  --all \
  --timeout=5m

Inspectez une ressource spécifique et son HPA :

kubectl -n $install_namespace describe scaledobject <scaledobject-name>
kubectl -n $install_namespace get scaledobject <scaledobject-name> -o yaml
kubectl -n $install_namespace describe hpa <hpa-name>

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 <unknown> 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 :

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. Partez des chiffres de production indiqués sur la page Dimensionnement.
• Le temps de provisionnement de l’autoscaler de nœuds 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 <unknown>	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.

​

Étapes suivantes

Monitoring avec Prometheus

Configurez le scraping et vérifiez les métriques utilisées par KEDA.

Prérequis

Consultez les exigences relatives à KEDA, Prometheus et à la capacité du cluster.

Dépannage

Diagnostiquez les problèmes de ScaledObjects défaillants et de métriques indisponibles.

Compatibilité

Vérifiez les versions prises en charge avant de mettre à niveau KEDA ou Vantage.