> ## 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. # Automatische Skalierung mit KEDA > Wie Vantage 3.0 selbstgehostet KEDA, Prometheus und Kubernetes-HPAs nutzt, um unterstützte Workloads zu skalieren. 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: ```bash theme={null} kubectl top nodes kubectl top pods -n $install_namespace ```
### Prometheus-Trigger
Asynchrone Worker-`ScaledObject`-Ressourcen nutzen Vantage-Anwendungsmetriken von Prometheus. Die wichtigsten Signale sind: ```promql theme={null} application_worker_priority_queue_length{namespace=""} application_worker_active_threads{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: 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: ```bash theme={null} 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: ```promql theme={null} application_worker_priority_queue_length{namespace=""} application_worker_active_threads{namespace=""} ``` Informationen zur Prometheus-Installation und zu den Service-Mesh-Anforderungen finden Sie unter [Überwachung mit Prometheus](/de/vantage/self-hosted/v3.0/monitoring/prometheus).
## Automatische Skalierung aktivieren
Aktivieren Sie KEDA in der Vantage-Konfiguration und den vom Chart erstellten `ServiceMonitor` über den separaten Top-Level-Block `observability`: ```yaml theme={null} 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: ```bash theme={null} kubectl -n $install_namespace get scaledobjects.keda.sh kubectl -n $install_namespace get hpa ``` Warten Sie, bis die `ScaledObject`-Ressourcen bereit sind: ```bash theme={null} kubectl -n $install_namespace wait \ --for=condition=Ready scaledobjects.keda.sh \ --all \ --timeout=5m ``` Prüfen Sie eine Ressource und ihre HPA: ```bash theme={null} kubectl -n $install_namespace describe scaledobject kubectl -n $install_namespace get scaledobject -o yaml kubectl -n $install_namespace describe 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 `` 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: ```bash theme={null} 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
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
| 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 `` 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](/de/vantage/self-hosted/v3.0/troubleshooting#keda-and-prometheus).
## Was kommt als Nächstes
Konfigurieren Sie das Scraping und prüfen Sie die von KEDA verwendeten Metriken. Prüfen Sie die Anforderungen an KEDA, Prometheus und die Clusterkapazität. Diagnostizieren Sie problematische ScaledObjects und nicht verfügbare Metriken. Prüfen Sie die unterstützten Versionen, bevor Sie KEDA oder Vantage aktualisieren.