Automatische Skalierung mit KEDA

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

Stufe	Komponente	Verantwortung
1	Vantage-Workloads	Verbrauchen CPU-Ressourcen und stellen Anwendungsmetriken wie Warteschlangenlänge und aktive Worker-Threads bereit.
2	Kubernetes-Ressourcenmetriken und Prometheus	Liefern CPU-Auslastung und Vantage-Anwendungsmetriken an die konfigurierten Trigger.
3	KEDA-Operator	Überwacht die vom Chart generierten `ScaledObject`-Ressourcen und wertet deren Trigger aus.
4	Kubernetes-HPA	Verwendet die für jede Metrik ermittelte Replikatempfehlung und wählt die höchste Empfehlung aus.
5	Kubernetes-Scheduler	Platziert die angeforderten Replikate auf geeigneten Knoten mit verfügbaren Ressourcen.

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.

Workload-Muster	Trigger	Warum er verwendet wird
Synchrone APIs und Orchestrierungsservices	CPU-Auslastung	Die Anfragelast zeigt sich in der Regel in der CPU-Auslastung, während der Service den Datenverkehr verarbeitet.
Asynchrone Verarbeitung und TechCore-Worker	Prometheus-Warteschlangen- und Worker-Metriken	Warteschlangenrückstand und Worker-Aktivität zeigen ausstehende Arbeit direkter an als die CPU-Auslastung.

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:

kubectl top nodes
kubectl top pods -n $install_namespace

Prometheus-Trigger

Asynchrone Worker-ScaledObject-Ressourcen nutzen Vantage-Anwendungsmetriken von Prometheus. Die wichtigsten Signale sind:

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

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:

KEDA 2.17.3 installiert ist und sein Operator sowie der Metrics API Server fehlerfrei laufen.
Die API für Kubernetes-Ressourcenmetriken CPU-Daten zurückgibt.
Prometheus unter http://prometheus-operated.observability.svc.cluster.local:9090 erreichbar ist.
Der Vantage-ServiceMonitor vorhanden ist und Prometheus die Vantage-/metrics-text-Ziele als UP meldet.
Prometheus aktuelle Werte für die Vantage-Worker-Metriken zurückgibt.
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:

kubectl get deployment --all-namespaces | grep keda-operator
kubectl -n observability get service prometheus-operated
kubectl -n $install_namespace get servicemonitor

Vergewissern Sie sich in Prometheus, dass diese Abfragen Zeitreihen für Ihren Installations-Namespace zurückgeben:

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

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:

vantage:
  keda:
    enabled: true

observability:
  prometheus:
    namespace: observability
    serviceMonitor:
      create: true

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:

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

Warten Sie, bis die ScaledObject-Ressourcen bereit sind:

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

Prüfen Sie eine Ressource und ihre 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>

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:

kubectl -n $install_namespace get deployment,hpa,pod --watch

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

Die automatische Skalierung 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. Gehen Sie von den Produktionswerten auf der Seite Sizing aus.
Die Bereitstellungszeit des Knoten-Autoscalers und die maximale Größe des Knoten-Pools.
Namespace-Quoten, Cluster-Limits und den Pull-Durchsatz der Registry.
TechCore-Knoten-Labels, Taints, Beschleuniger und die Isolierung von Training-Workern.
Die Fehlertoleranz, wenn ein Knoten 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

Symptom	Wahrscheinlicher Prüfbereich
Es werden keine `ScaledObject`-Ressourcen angezeigt	Vergewissern Sie sich, dass `vantage.keda.enabled: true` gesetzt ist, und prüfen Sie die generierten ArgoCD-Anwendungen.
`Ready=False` oder `ScaledObjectCheckFailed`	Vergewissern Sie sich, dass KEDA 2.17.3 verwendet wird, und prüfen Sie die `ScaledObject`-Ereignisse auf ein nicht unterstütztes Trigger-Feld.
HPA-Metriken zeigen `<unknown>` an	Prüfen Sie den Prometheus-Service, `ServiceMonitor`, Scrape-Ziele, die Mesh-Richtlinie und die Abfrageergebnisse.
HPA fordert mehr Replikate an, aber Pods bleiben auf `Pending`	Prüfen Sie Knotenkapazität, Kontingente, Ressourcenanforderungen, TechCore-Labels, Taints und die Planung persistenter Volumes.
Eine Workload skaliert, obwohl ihre Warteschlange inaktiv erscheint	Prüfen Sie alle Trigger; möglicherweise ist ein anderer Prometheus- oder CPU-Trigger aktiv.
Das Skalierungsverhalten ändert sich nach einem Upgrade	Vergleichen Sie das generierte `ScaledObject` mit der versionierten Chart-Konfiguration und vergewissern Sie sich, dass beide Vantage-Charts dieselbe Version verwenden.

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.

Configuration

Lifecycle

Monitoring

Performance

Diagnostics

Migration

Wie die automatische Skalierung funktioniert

Skalierungsstrategien

Trigger für CPU-Auslastung

Prometheus-Trigger

Skalieren Sie Workertypen proportional zu Ihren Skills

Voraussetzungen

Automatische Skalierung aktivieren

Automatische Skalierung überprüfen

Generiertes Verhalten verstehen

Cluster-Kapazität planen

Fehlerbehebung

Was kommt als Nächstes

Überwachung mit Prometheus

Voraussetzungen

Fehlerbehebung

Kompatibilität

​Wie die automatische Skalierung funktioniert

​Skalierungsstrategien

​Trigger für CPU-Auslastung

​Prometheus-Trigger

​Skalieren Sie Workertypen proportional zu Ihren Skills

​Voraussetzungen

​Automatische Skalierung aktivieren

​Automatische Skalierung überprüfen

​Generiertes Verhalten verstehen

​Cluster-Kapazität planen

​Fehlerbehebung

​Was kommt als Nächstes

Überwachung mit Prometheus

Voraussetzungen

Fehlerbehebung

Kompatibilität

Wie die automatische Skalierung funktioniert

Skalierungsstrategien

Trigger für CPU-Auslastung

Prometheus-Trigger

Skalieren Sie Workertypen proportional zu Ihren Skills

Voraussetzungen

Automatische Skalierung aktivieren

Automatische Skalierung überprüfen

Generiertes Verhalten verstehen

Cluster-Kapazität planen

Fehlerbehebung

Was kommt als Nächstes