Mein Geheimnis für die Skalierung von Kubernetes für unvorhersehbare Agenten-Workloads

Hallo zusammen, Kollegen im Agentenmanagement! Maya Singh hier, zurück, um die Feinheiten des Deployments von Agenten auf agntup.com zu erkunden. Heute möchte ich über etwas sprechen, das mich fast so sehr wach hält wie die Suche nach meiner nächsten Serie, die ich auf meinem Streaming-Dienst ansehen kann: die Skalierbarkeit unserer Agenten-Deployments in Kubernetes.

Genauer gesagt möchte ich die oft übersehenen, aber entscheidenden Aspekte des intelligenten horizontalen Autoscalings von Pods für unvorhersehbare Agenten-Workloads ansprechen. Wir alle wissen, dass HPA großartig ist, aber wenn Ihre Agenten sehr unterschiedliche Aufgaben ausführen oder externe Ereignisse plötzliche und massive Spitzen verursachen, reichen die standardmäßigen CPU-/Speichermetriken einfach nicht aus. Es ist, als würde man versuchen, ein Formel-1-Auto nur mit einem Geschwindigkeitsmesser zu fahren – man verpasst eine Menge kritischer Informationen.

Das aktuelle Datum ist der 18. März 2026, und wenn Sie sich immer noch ausschließlich auf die CPU-Nutzung verlassen, um Ihre Agentenflotte zu skalieren, geben Sie wahrscheinlich zu viel für inaktive Ressourcen aus oder spielen ständig Catch-Up, was zu einer Verschlechterung der Leistung und unzufriedenen Benutzern führt. Lassen Sie uns das beheben.

Die CPU/Speicher-Falle: Warum das Standard-HPA für intelligente Agenten nicht ausreicht

Ich erinnere mich an einen Vorfall vor etwa anderthalb Jahren, als wir eine neue Funktion für unsere Überwachungsagenten eingeführt hatten. Diese Agenten sollten sehr spezifische Protokolle und Metriken der Kundeninfrastruktur sammeln, sie lokal verarbeiten und dann an unsere zentrale Plattform zurücksenden. Das klingt einfach, oder? Falsche Antwort.

Das Problem war, dass wir einige Unternehmenskunden mit unglaublich ausführlichen Protokollierungs-Konfigurationen hatten. Ein Kunde, eine große Finanzinstitution, entschied sich, die Debug-Protokollierung für seine gesamte Flotte direkt nach unserem Release zu aktivieren. Plötzlich begannen unsere Agenten, die normalerweise mit 20 % CPU für die meisten Kunden arbeiteten, bei diesem einen Kunden auf 90 % und mehr zu steigen. Unser HPA, das auf ein Ziel von 70 % CPU konfiguriert war, wurde aktiviert und fügte weitere Pods hinzu. Aber hier ist der Haken: Der Flaschenhals war nicht nur die CPU. Es war auch die Rate, mit der sie Daten verarbeiten und senden konnten, was manchmal externe API-Aufrufe mit Ratenlimits beinhaltete.

Wir endeten mit Dutzenden von Pods für diesen einen Kunden, alle überlastet, was die Situation nicht wirklich verbesserte, da der externe Flaschenhals weiterhin bestand. Unsere Kosten explodierten, und die Kundenerfahrung war schrecklich. Wir haben mehr skaliert, aber nicht intelligenter.

Diese Erfahrung hat eine grundlegende Wahrheit ans Licht gebracht: Generische Ressourcenmetriken (CPU, Speicher) sind gut für allgemeine Anwendungen, aber für Agenten mit spezifischen Aufgaben, insbesondere solche, die mit externen Systemen interagieren oder variable Workloads verarbeiten, ist es notwendig, weiter zu gehen. Sie benötigen benutzerdefinierte Metriken.

Über die Grundlagen hinaus: Benutzerdefinierte Metriken für intelligenteres Autoscaling

Hier geschieht die Magie. Das HPA von Kubernetes ermöglicht es Ihnen, basierend auf benutzerdefinierten Metriken zu skalieren, die Sie definieren. Diese können alles sein, was die tatsächliche Arbeitslast widerspiegelt, die Ihre Agenten bewältigen. Denken Sie darüber nach, was Ihre Agenten wirklich belastet oder auf einen Rückstand hinweist. Für meine Protokollverarbeitungsagenten war es nicht nur die CPU; es war:

• Protokollzeilen pro Sekunde: Eine direkte Messung des Eingangsvolumens.
• Wartende Ereignisse in der internen Warteschlange: Ein Indikator für einen internen Rückstand, bevor Daten gesendet werden.
• Latency/Error-Rate von externen API-Aufrufen: Wenn Ihr Agent mit externen Diensten kommuniziert, ist das entscheidend.

Nehmen wir das Beispiel „wartende Ereignisse in der internen Warteschlange“. Stellen Sie sich vor, Ihr Agent sammelt Daten, legt sie in eine In-Memory-Warteschlange und dann verarbeitet eine Hintergrundroutine diese und sendet sie. Wenn diese Warteschlange schnell wächst, bedeutet das, dass Ihr Agent nicht mithalten kann. Das Skalieren basierend auf der Länge dieser Warteschlange spricht direkt den Flaschenhals an.

Wie man benutzerdefinierte Metriken in HPA integriert

Das umfasst in der Regel einige Komponenten:

1. Ihr Agent: Er muss diese Metriken bereitstellen. Das Prometheus-Expositionsformat ist hier der Standard. Instrumentieren Sie den Code Ihres Agenten mit einer Clientbibliothek (Go, Python, Java usw.), um Metriken wie agent_pending_events_total oder agent_log_lines_processed_per_second bereitzustellen.
2. Prometheus: Holt sich Ihre Agenten-Pods und speichert diese Metriken.
3. Prometheus-Adapter oder KEDA: Das ist die Brücke.

Ich persönlich neige zu KEDA (Kubernetes Event-driven Autoscaling) für solche Szenarien, insbesondere wenn es um externe Warteschlangen oder Ereignisquellen geht. Während der Prometheus-Adapter solide für einfache benutzerdefinierte Metriken ist, die von Ihrer Anwendung bereitgestellt werden, glänzt KEDA, wenn Ihr Skalierungs-Trigger ein echter Ereignisstrom oder die Länge der Warteschlange eines Elements wie Kafka, RabbitMQ, SQS oder sogar einer benutzerdefinierten externen API ist. Das bietet eine deklarativere und oft einfachere Möglichkeit, diese Skalierungsregeln zu definieren.

Angenommen, unser Agent stellt eine Prometheus-Metrik namens agent_pending_events_total bereit. Wir möchten skalieren, wenn der Durchschnittswert dieser Metrik über alle Pods für ein bestimmtes Deployment 1000 überschreitet.

Zuerst stellen Sie sicher, dass Ihr Agent diese Metrik bereitstellt:

# Beispiel für einen Python-Snippet, der die Prometheus-Clientbibliothek verwendet
from prometheus_client import Gauge, start_http_server
import time
import random

pending_events_gauge = Gauge('agent_pending_events_total', 'Anzahl der wartenden Ereignisse in der internen Warteschlange')

def run_agent_loop():
 while True:
 # Arbeit und Warteschlangenänderungen simulieren
 current_pending = random.randint(100, 1500) # Variablen Rückstand simulieren
 pending_events_gauge.set(current_pending)
 print(f"Aktuelle wartende Ereignisse: {current_pending}")
 time.sleep(5)

if __name__ == '__main__':
 start_http_server(8000) # Stellt die Metriken auf Port 8000 bereit
 run_agent_loop()

Als nächstes sollten Sie Ihre Prometheus-Konfiguration einrichten, um diese Metriken von Ihren Agenten-Pods abzurufen. Vorausgesetzt, Ihre Agenten-Pods haben die Annotation prometheus.io/scrape: "true" und prometheus.io/port: "8000", wird Prometheus sie abrufen.

Jetzt schauen wir uns eine ScaledObject-Definition von KEDA an. Dies setzt voraus, dass Sie KEDA in Ihrem Cluster installiert haben.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: my-agent-scaler
 namespace: agents
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: my-agent-deployment # Name Ihres Agenten-Deployments
 minReplicaCount: 1
 maxReplicaCount: 10
 pollingInterval: 30 # Überprüfen Sie die Metriken alle 30 Sekunden
 triggers:
 - type: prometheus
 metadata:
 serverAddress: http://prometheus-kube-prometheus-thanos-proxy.monitoring.svc.cluster.local:9090 # Ihr Prometheus-Service-Endpunkt
 metricName: agent_pending_events_total
 query: |
 avg(agent_pending_events_total) by (pod) # Durchschnittliche wartende Ereignisse pro Pod
 threshold: "1000" # Skalieren, wenn die durchschnittlichen wartenden Ereignisse pro Pod 1000 überschreiten
 # Verwenden Sie `query` anstelle von `metricName` und `threshold` für komplexere Szenarien
 # Zum Beispiel, um einen Durchschnitt über das gesamte Deployment hinweg anstelle von pro Pod zu zielen:
 # query: |
 # sum(agent_pending_events_total) / count(agent_pending_events_total)
 # threshold: "1000"
 # Dieses Beispiel zielt auf den Durchschnitt pro Pod ab, was oft nützlicher für die individuelle Agentenkapazität ist.

Eine Anmerkung zur Prometheus-Abfrage: Ich habe avg(agent_pending_events_total) by (pod) verwendet. KEDA (und HPA mit dem Prometheus-Adapter) aggregiert in der Regel die Metriken über die Pods, die zur skalierten Zielgruppe gehören. Wenn Sie einen Durchschnitt *pro Pod* anvisieren, ist das eine gute Möglichkeit, einen Schwellenwert zu definieren, der die individuelle Last der Agenten tatsächlich widerspiegelt. Wenn Sie basierend auf dem gesamten Rückstand über das gesamte Deployment skalieren möchten, würden Sie die Abfrage entsprechend anpassen.

Erweiterte Szenarien: Metriken und prädiktives Autoscaling kombinieren

Was ist, wenn eine Metrik nicht ausreicht? Was tun, wenn Sie sowohl die Warteschlangentiefe als auch die CPU berücksichtigen müssen? Hier wird es wirklich interessant. KEDA ermöglicht es Ihnen, mehrere Trigger zu definieren. Das ScaledObject wird dann basierend auf dem Trigger skalieren, der die meisten Replikate anfordert.

Stellen Sie sich vor, unser Agent führt auch eine rechenintensive Bildverarbeitung durch, wodurch die CPU wieder ein relevantes Faktor wird. Wir könnten einen weiteren Trigger hinzufügen:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: my-agent-scaler
 namespace: agents
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: my-agent-deployment
 minReplicaCount: 1
 maxReplicaCount: 10
 pollingInterval: 30
 triggers:
 - type: prometheus # Auslöser 1: Wartende Ereignisse
 metadata:
 serverAddress: http://prometheus-kube-prometheus-thanos-proxy.monitoring.svc.cluster.local:9090
 metricName: agent_pending_events_total
 query: |
 avg(agent_pending_events_total) by (pod)
 threshold: "1000"
 - type: cpu # Auslöser 2: CPU-Nutzung
 metadata:
 value: "70" # Skalieren, wenn die durchschnittliche CPU-Nutzung 70 % überschreitet

Jetzt wird KEDA dafür sorgen, dass Ihr Deployment skaliert, wenn entweder die wartenden Ereignisse pro Pod 1000 überschreiten oder die durchschnittliche CPU-Nutzung 70 % übersteigt. Das gibt Ihnen eine ganzheitlichere und stabilere Autoscaling-Strategie.

Prädiktives Autoscaling: In die Zukunft schauen

Während KEDA und benutzerdefinierte Metriken reaktive Skalierbarkeit hervorragend behandeln, ist manchmal selbst die schnellste Reaktion nicht ausreichend. Denken Sie an geplante Batch-Jobs, die Ihre Agenten jeden Tag um 3 Uhr morgens erreichen, oder an eine bekannte Marketingkampagne, die einen Anstieg der Benutzeranmeldungen generiert, wobei jede Interaktion mit einem Agenten erforderlich ist. Hier kommt das prädiktive Autoscaling ins Spiel.

Prädiktives Autoscaling ist nichts, was KEDA oder der native HPA direkt tun, aber sie können in externe Systeme integriert werden. Sie würden in der Regel Folgendes benötigen:

• Historische Daten: Halten Sie Ihre benutzerdefinierten Metriken und Skalierungsereignisse im Laufe der Zeit fest.
• Vorhersagemodell: Verwenden Sie maschinelles Lernen (z. B. ARIMA, Prophet), um zukünftige Arbeitslastspitzen basierend auf historischen Mustern vorherzusagen.
• Externer Scaler: Ein benutzerdefinierter Controller oder Skript, der diese Vorhersagen nutzt, um Ihre minReplicaCount anzupassen oder sogar direkt Ihr Deployment über die Kubernetes-API *vor* dem Eintreten des Spitzenwerts zu skalieren.

Ich habe mit einer einfachen Version davon experimentiert, indem ich ein Python-Skript verwendet habe, das Daten von Prometheus extrahiert, ein einfaches Prophet-Modell ausführt und dann kubectl scale verwendet, um das Deployment anzupassen. Das ist nicht für alle produktionsbereit, aber für vorhersehbare und wiederkehrende Spitzen kann es Ihnen diese panischen Momente „Warum sterben all unsere Agenten?!“ ersparen. Wichtig ist, eine gute Rückkopplungsschleife zu haben und Ihre Vorhersagen kontinuierlich zu verfeinern.

Die Effizienz Ihres Autoscalings überwachen

Intelligentes Autoscaling zu implementieren ist keine „Einrichten und Vergessen“-Operation. Sie müssen seine Effizienz überwachen. Ich installiere immer Dashboards in Grafana, um Folgendes zu verfolgen:

• Anzahl der Replikate: Wie viele Pods laufen für jedes Deployment.
• Zielmetriken: Die tatsächlichen Werte der benutzerdefinierten Metriken, auf denen Sie skalieren (z. B. agent_pending_events_total, CPU-Nutzung).
• Ressourcennutzung: Tatsächliche CPU- und Speicherauslastung der Pods.
• Agentenlatenz/-fehler: End-to-End-Leistungsmetriken, um sicherzustellen, dass das Skalieren tatsächlich die Benutzererfahrung verbessert.

Durch die Korrelation dieser Elemente können Sie sehen, ob Ihre Skalierungsstrategie wie geplant funktioniert. Skalieren Sie schnell? Sind Sie überversorgt? Entlastet die hinzugefügte Kapazität wirklich den Engpass? Diese Fragen sind entscheidend, um sowohl die Leistung als auch die Kosten zu optimieren.

Eine spezifische Sache, nach der ich suche, ist ein „schwingendes“ Verhalten – bei dem die Anzahl der Replikate schnell steigt und fällt. Das deutet oft darauf hin, dass Ihre Schwellenwerte zu aggressiv sind oder dass Ihr Abfrageintervall zu kurz ist, was zu Instabilität führt. Sie möchten ein flüssiges und reaktives Skalieren, keine Achterbahn.

Praktische Tipps für Ihr nächstes Agenten-Deployment

1. Wahre Engpässe identifizieren: Gehen Sie nicht davon aus, dass die CPU immer das Problem ist. Bei Agenten-Workloads denken Sie an Warteschlangentiefe, I/O-Raten, externe API-Abhängigkeiten oder spezifische Aufgabenerledigungsraten.
2. Instrumentieren Sie Ihre Agenten: Stellen Sie sicher, dass Ihre Agenten relevante benutzerdefinierte Metriken in einem Standardformat (wie Prometheus) bereitstellen. Das ist grundlegend.
3. KEDA annehmen: Für die skalierung basierend auf Ereignissen oder benutzerdefinierten Metriken ist KEDA ein leistungsstarkes und flexibles Tool, das die Konfiguration im Vergleich zu einem groben HPA mit Prometheus-Adapter für komplexe Szenarien vereinfacht.
4. Metriken kombinieren: Scheuen Sie sich nicht, mehrere Auslöser (CPU + benutzerdefinierte Metrik) zu verwenden, um eine umfassende Skalierungsabdeckung zu gewährleisten. KEDA verwaltet dies elegant, indem es auf die höchste Nachfrage nach Replikaten reagiert.
5. Überwachen und iterieren: Autoscaling ist ein iterativer Prozess. Überwachen Sie kontinuierlich das Verhalten Ihrer Skalierung, die Ressourcennutzung und die Anwendungsleistung. Passen Sie die Schwellenwerte, Abfrageintervalle und sogar Ihre benutzerdefinierten Metriken nach Bedarf an.
6. Prädiktives Skalieren in Betracht ziehen (mit Vorsicht): Für Workloads mit sehr vorhersehbaren Mustern erkunden Sie die Integration von Vorhersagemodellen mit einem externen Controller, um Ihre Deployments vorab zu skalieren. Beginnen Sie einfach und validieren Sie rigoros.

Effektives Skalieren von Agenten bedeutet nicht einfach, mehr Rechenleistung zum Problem hinzuzufügen; es geht darum, die richtige Menge an Rechenleistung zur richtigen Zeit bereitzustellen, basierend auf dem, was tatsächlich die Arbeitslast Ihres Agenten antreibt. Indem Sie über generische CPU- und Speichermetriken hinausgehen und benutzerdefinierte, anwendungsspezifische Signale annehmen, können Sie eine wirklich resiliente, kosteneffiziente und leistungsstarke Flotte von Agenten aufbauen. Und glauben Sie mir, Ihr Schlafplan wird es Ihnen danken.

Freue mich darauf, Sie wiederzusehen, halten Sie diese Agenten aktiv!

Maya Singh, agntup.com

Verwandte Artikel

• Ich skaliere meine Cloud-Agenten-Deployments, ohne den Schlaf zu verlieren
• Wie man Authentifizierung mit Weaviate hinzufügt (Schritt für Schritt)
• Gesundheitschecks für Agenten: Eine tiefgehende Analyse mit praktischen Beispielen

🕒 Published: March 29, 2026