Zum Hauptinhalt springen
KEDA ist die optionale, empfohlene Engine für die automatische Skalierung in Vantage 3.0 selbstgehostet. Wenn Sie sie aktivieren, erstellen die Komponenten-Charts von Vantage ScaledObject-Ressourcen für unterstützte Workloads. KEDA wertet deren Trigger aus und verwaltet Kubernetes-Ressourcen vom Typ HorizontalPodAutoscaler (HPA), die die Workloads hoch- und herunterskalieren.
Die Workload-Charts von Vantage erfordern KEDA 2.17.x. Verwenden Sie KEDA 2.17.3. KEDA 2.18 und höher kann einige ScaledObject-Felder, die von den aktuellen Vantage-Charts generiert werden, nicht verarbeiten.

​
Wie die automatische Skalierung funktioniert

KEDA passt die Replikatanzahl von Workloads an. Es fügt keine Kubernetes-Knoten hinzu, erhöht keine Kontingente und macht aus einem ungeeigneten Knoten keinen geeigneten für einen Workload. Stimmen Sie KEDA mit Ihrem Knoten-Autoscaler oder einem anderen Prozess zur Kapazitätsverwaltung ab.

​
Skalierungsstrategien

Die generierten ScaledObject-Ressourcen verwenden je nach Workload-Eigenschaften unterschiedliche Triggertypen. Die generierten Schwellenwerte, Replikatgrenzen, Abfragen und das HPA-Verhalten unterscheiden sich je nach Workload und Vantage-Chart-Version. Betrachten Sie die in Ihrer Installation generierten ScaledObject-Ressourcen als maßgebliche Referenz.

​
Trigger für CPU-Auslastung

CPU-Trigger vergleichen die durchschnittliche CPU-Auslastung eines Workloads mit seinem konfigurierten Zielwert. Die CPU-Auslastung wird relativ zu den CPU-Requests des Workloads berechnet. Daher muss die Kubernetes-Ressourcenmetriken-API funktionsfähig sein, und der Workload muss weiterhin gültige CPU-Requests aufweisen. Vergewissern Sie sich, dass Ressourcenmetriken verfügbar sind:

​
Prometheus-Trigger

Asynchrone Worker-ScaledObject-Ressourcen nutzen Vantage-Anwendungsmetriken von Prometheus. Die wichtigsten Signale sind:
  • application_worker_priority_queue_length meldet Arbeit, die auf einen Worker-Typ wartet.
  • application_worker_active_threads meldet aktive Verarbeitungs-Threads. Einige generierte Worker-Konfigurationen verwenden sie als zweiten Prometheus-Trigger zusätzlich zur Warteschlangentiefe: Der Worker wird damit vorsorglich hochskaliert, wenn keine Verarbeitungs-Threads mehr frei sind, sodass eine neu eingehende Aufgabe sofort übernommen wird, anstatt zu warten, bis sich ein Rückstau in der Warteschlange aufbaut.
Die vom Chart generierten Abfragen fügen workload-spezifische Selektoren für Service und Worker hinzu und verwenden möglicherweise gleitende Zeitfenster. Ersetzen Sie sie nicht durch die beiden allgemeinen Prüfabfragen oben. Einige ScaledObject-Ressourcen enthalten mehr als einen Trigger. Jeder Trigger kann eine Hochskalierung anfordern, und die HPA verwendet die höchste Replikat-Empfehlung. Wenn ein Workload unerwartet skaliert, prüfen Sie jeden Trigger statt nur den ersten.

​
Skalieren Sie Workertypen proportional zu Ihren Skills

Die TechCore-Verarbeitung ist in Workertypen wie OCR, Extraction und Classification unterteilt, und jeder Workertyp skaliert unabhängig in seiner eigenen Warteschlange. Welche Workertypen die meiste Last tragen, hängt von Ihren bereitgestellten Skills ab: Ein OCR-lastiger Skill-Mix erhöht den Bedarf an OCR-Workern, während ein extraktionslastiger Mix den Bedarf an Extraction-Workern erhöht. Da Dokumente diese Workertypen stufenweise durchlaufen, äußern sich Kapazitätsungleichgewichte zwischen den Stufen eher in Wartezeiten als in Fehlern. Wenn eine Stufe im Verhältnis zu der vorgelagerten Stufe unterversorgt ist (zum Beispiel reichlich OCR-Kapazität, aber zu wenige Extraction-Worker), durchlaufen Dokumente die erste Stufe schnell und pausieren dann mehrere Minuten, während sich die nachgelagerte Warteschlange leert und ihre Worker hochskalieren. Beobachten Sie bei einem repräsentativen Lasttest mit Ihrem produktiven Skill-Mix die Warteschlangentiefe pro Workertyp und besprechen Sie Anpassungen der relativen Replikagrenzen mit Ihrem ABBYY Account Team.

​
Voraussetzungen

Bevor Sie KEDA aktivieren, stellen Sie sicher, dass:
  1. KEDA 2.17.3 installiert ist und sein Operator sowie der Metrics API Server fehlerfrei laufen.
  2. Die API für Kubernetes-Ressourcenmetriken CPU-Daten zurückgibt.
  3. Prometheus unter http://prometheus-operated.observability.svc.cluster.local:9090 erreichbar ist.
  4. Der Vantage-ServiceMonitor vorhanden ist und Prometheus die Vantage-/metrics-text-Ziele als UP meldet.
  5. Prometheus aktuelle Werte für die Vantage-Worker-Metriken zurückgibt.
  6. Im Cluster genügend einplanbare Kapazität für die zusätzlichen Replikate vorhanden ist, einschließlich Knoten, die für TechCore-Worker gekennzeichnet sind.
Der Prometheus-Service-Name, Namespace und Port in Punkt 3 bilden einen festen Endpunkt für die generierten ScaledObject-Ressourcen. Verwenden Sie diese Prüfungen, bevor Sie fortfahren:
Vergewissern Sie sich in Prometheus, dass diese Abfragen Zeitreihen für Ihren Installations-Namespace zurückgeben:
Informationen zur Prometheus-Installation und zu den Service-Mesh-Anforderungen finden Sie unter Überwachung mit Prometheus.

​
Automatische Skalierung aktivieren

Aktivieren Sie KEDA in der Vantage-Konfiguration und den vom Chart erstellten ServiceMonitor über den separaten Top-Level-Block observability:
Der Abschnitt observability ist weder Teil von vantage noch der Vantage-Custom-Resource. Er steuert Ressourcen für die Überwachung, die direkt vom vantage-selfhosted-Chart erzeugt werden. Wenden Sie die Werte über Ihr vorhandenes vantage-selfhosted-Helm-Release an. ArgoCD erstellt die Anwendungen der Komponenten und ihre ScaledObject-Ressourcen asynchron.

​
Automatische Skalierung überprüfen

Listen Sie die generierten Ressourcen auf:
Warten Sie, bis die ScaledObject-Ressourcen bereit sind:
Prüfen Sie eine Ressource und ihre HPA:
Beachten Sie den Status sorgfältig:
  • Ready=True bedeutet, dass KEDA die Trigger-Konfiguration akzeptiert hat.
  • Active=True bedeutet, dass derzeit mindestens ein Trigger eine Skalierungsaktivität anfordert.
  • Active=False kann normal sein, wenn es keinen Traffic und keine Arbeit in der Warteschlange gibt.
  • Ein HPA-Metrikwert von <unknown> weist darauf hin, dass Kubernetes keinen aktuellen Wert für diese Metrik abrufen kann.
Beobachten Sie während eines kontrollierten Workload-Tests den Workload, die HPA und die Knotenkapazität gemeinsam:
Vergewissern Sie sich, dass die angeforderten Replikate den Status Running erreichen. Wenn die vom HPA gewünschte Anzahl steigt, die Pods aber weiterhin Pending bleiben, handelt es sich um ein Kapazitäts- oder Scheduling-Problem, nicht um ein Problem mit dem KEDA-Trigger.

​
Generiertes Verhalten verstehen

Die Vantage-Workload-Charts liefern workload-spezifische Einstellungen für:
  • Auslöseschwellen und Prometheus-Abfragen
  • minimale und maximale Replikagrenzen
  • die Scale-up-Rate und das Stabilisierungsverhalten
  • die Scale-down-Rate und das Stabilisierungsverhalten
Die Konfiguration ist darauf ausgelegt, bei entstehendem Rückstau schnell hochzuskalieren und über ein Stabilisierungsfenster vorsichtig herunterzuskalieren: eine Cooldown-Phase, in der Replikate weiterlaufen, bis die Warteschlange für einen festgelegten Zeitraum ruhig geblieben ist. Modell- und Training-Worker verwenden eine längere Cooldown-Phase als schlanke API-Services, weil beim Entfernen ihrer Replikate zwischengespeicherte Modelle verworfen werden und das erneute Laden dieser Modelle die nächste Aufgabe spürbar verlangsamt. Betrachten Sie die Fensterdauern in Ihren generierten Ressourcen als Referenzwerte für diese Chart-Version, nicht als Optimierungsziele. Exakte Werte sind Teil der Produktkonfiguration und keine allgemeingültige Kapazitätsempfehlung. Sie können sich mit den Vantage-Chart-Versionen ändern, wenn sich Workload-Eigenschaften und Validierungsdaten weiterentwickeln.
Kopieren Sie keine ScaledObject-Manifeste oder Schwellenwerte aus einer anderen Umgebung und bearbeiten Sie generierte Ressourcen nicht direkt. ArgoCD kann die vom Chart gerenderte Konfiguration während der Reconciliation oder eines Upgrades wiederherstellen. Verwenden Sie nur unterstützte Vantage-Chart-Werte; wenden Sie sich an Ihr ABBYY Account Team, bevor Sie zusätzliche Overrides für die automatische Skalierung anwenden.

​
Cluster-Kapazität planen

Autoscaling kann einen zu klein dimensionierten oder ressourcenbeschränkten Cluster nicht ausgleichen. Berücksichtigen Sie bei der Planung Folgendes:
  • Die maximale Ankunftsrate von Dokumenten und die akzeptable Wartezeit in der Warteschlange.
  • Die durchschnittliche Verarbeitungsdauer sowie die Verarbeitungsdauer in hohen Perzentilen für repräsentative Dokumente und Skills.
  • Die Startzeit von Pods und die Aufwärmzeit des Modells.
  • CPU- und Speicheranforderungen für jede Workload, die gleichzeitig skaliert.
  • Die Bereitstellungszeit des Node-Autoscalers und die maximale Größe des Node-Pools.
  • Namespace-Quoten, Cluster-Limits und den Pull-Durchsatz der Registry.
  • TechCore-Node-Labels, Taints, Beschleuniger und die Isolierung von Training-Workern.
  • Die Fehlertoleranz, wenn ein Node oder eine Verfügbarkeitszone ausfällt.
Messen Sie bei einem repräsentativen Lasttest die Warteschlangentiefe, die Verarbeitungslatenz, die Startzeit der Pods, die von HPA angeforderte Anzahl von Replikaten und wartende Pods. Verwenden Sie diese Beobachtungen, wenn Sie mit ABBYY über umgebungsspezifisches Tuning sprechen.

​
Fehlerbehebung

Detaillierte Schritte zur Problembehebung finden Sie unter Fehlerbehebung für KEDA und Prometheus.

​
Was kommt als Nächstes

Überwachung mit Prometheus

Konfigurieren Sie das Scraping und prüfen Sie die von KEDA verwendeten Metriken.

Voraussetzungen

Prüfen Sie die Anforderungen an KEDA, Prometheus und die Clusterkapazität.

Fehlerbehebung

Diagnostizieren Sie problematische ScaledObjects und nicht verfügbare Metriken.

Kompatibilität

Prüfen Sie die unterstützten Versionen, bevor Sie KEDA oder Vantage aktualisieren.