Skalierung von Kubernetes-Pods mit KEDA auf Basis der Warteschlangentiefe von Amazon SQS

Einführung

In ereignisgesteuerten Kubernetes-Architekturen spiegeln die CPU- und Speicherauslastung oft nicht die tatsächliche Systemauslastung wider. Ein Worker-Pod kann aus CPU-Sicht im Leerlauf sein, während sich Tausende von Nachrichten in einer Amazon-SQS-Warteschlange stauen. In anderen Fällen laufen Pods möglicherweise noch lange weiter, nachdem ein Traffic-Spitzenwert bereits abgeklungen ist.

Bei asynchronen, warteschlangenbasierten Workloads ist der Auftragsrückstand das eigentliche Skalierungssignal – nicht die Auslastung der Infrastruktur.

In diesem Artikel erfahren Sie:

• Warum die Warteschlangentiefe von Amazon SQS eine bessere Metrik für die automatische Skalierung ist als die CPU-Auslastung bei ereignisgesteuerten Workern
• So skalieren Sie Workloads auf Amazon EKS mithilfe von KEDA und AWS Pod Identity
• Wie KEDA die gewünschte Anzahl an Replikaten anhand der Warteschlangentiefe berechnet
• So passen Sie „queueLength“, „activationQueueLength“, die Abklingzeiten und das HPA-Verhalten an
• So überprüfen Sie das Skalierungsverhalten und beheben häufige Probleme

Warum das wichtig ist:
In warteschlangengesteuerten Systemen wirken sich Verzögerungen bei der Nachrichtenverarbeitung direkt auf die Benutzer und nachgelagerte Systeme aus. Die Skalierung auf Basis der SQS-Warteschlangentiefe passt die automatische Skalierung an den tatsächlichen Bedarf an und ermöglicht so eine schnellere Bewältigung von Spitzenauslastungen sowie geringere Leerlaufkosten, wenn die Warteschlangen leer sind.

1. Voraussetzungen

Bevor Sie die KEDA-basierte automatische Skalierung mit Amazon SQS implementieren, stellen Sie sicher, dass Sie über Folgendes verfügen:

• Ein Amazon EKS-Cluster, auf dem eine unterstützte Kubernetes-Version ausgeführt wird
• KEDA wurde im Cluster installiert (beispielsweise über das Helm-Chart „kedacore“)
• Eine AWS-Authentifizierungsmethode wurde ausgewählt (IRSA oder EKS-Pod-Identität)
• Eine bereits vorhandene Amazon SQS-Warteschlange
• Ein Worker-Einsatz, der darauf ausgelegt ist, Nachrichten aus der Warteschlange zu verarbeiten

2. Architektur und Anforderungsablauf

Diese Architektur basiert darauf, dass KEDA die Metriken der Amazon SQS-Warteschlangen überwacht und einen Kubernetes Horizontal Pod Autoscaler (HPA) auf der Grundlage des Backlogs verwaltet.

Ablauf der Anfrage:

1. Produzenten senden Nachrichten an die Amazon SQS-Warteschlange
2. KEDA ermittelt anhand von Warteschlangenattributen den Rückstand
3. KEDA aktualisiert die Zielkennzahlen im HPA
4. Die HPA skaliert den Arbeitseinsatz der Mitarbeiter
5. Kubernetes plant zusätzliche Pods ein, um Nachrichten zu verarbeiten
6. Wenn die Warteschlange leer wird, wird die Anzahl der Replikate wieder reduziert

Bei diesem Modell werden Entscheidungen zur automatischen Skalierung direkt an den Arbeitsrückstand gekoppelt.

3. Umsetzungsschritte

KEDA über Helm installieren

Die empfohlene Vorgehensweise zur Installation von KEDA ist die Verwendung von Helm:

# Add the KEDA Helm repository
helm repo add kedacore https://kedacore.github.io/charts
helm repo update

# Install KEDA into a dedicated namespace
helm install keda kedacore/keda \
  --namespace keda \
  --create-namespace

Funktionsweise:
Stellt den KEDA-Operator und den Metrik-API-Server bereit, zusammen mit CRDs wie „ScaledObject“ und „TriggerAuthentication“.

Den Worker mit zugewiesener AWS-Identität bereitstellen

Ein SQS-Consumer benötigt in der Regel folgende Berechtigungen:

• GetQueueAttributes
• GetQueueUrl
• ReceiveMessage
• Nachricht löschen
• Nachrichtensichtbarkeit ändern

Beispiel für eine IAM-Richtlinie:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ConsumeFromQueue",
      "Effect": "Allow",
      "Action": [
        "sqs:GetQueueAttributes",
        "sqs:GetQueueUrl",
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:ChangeMessageVisibility"
      ],
      "Resource": "arn:aws:sqs:us-east-1:123456789012:orders-queue"
    }
  ]
}

Funktionsweise:
Sichert den Zugriff nach dem Prinzip der geringsten Berechtigungen, indem nur Berechtigungen für die erforderliche SQS-Warteschlange erteilt werden.

KEDA-Authentifizierung und ScaledObject konfigurieren

KEDA verbindet die Bereitstellung mithilfe von „TriggerAuthentication“ und „ScaledObject“ mit der SQS-Warteschlange. Durch die Verwendung von „queueURLFromEnv“ wird eine feste Programmierung der Warteschlangen-URL vermieden.

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: sqs-processor-auth
  namespace: workers
spec:
  podIdentity:
    provider: aws
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sqs-processor
  namespace: workers
spec:
  scaleTargetRef:
    name: sqs-processor
  pollingInterval: 10
  cooldownPeriod: 120
  minReplicaCount: 0
  maxReplicaCount: 30
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 60
  triggers:
    - type: aws-sqs-queue
      authenticationRef:
        name: sqs-processor-auth
      metadata:
        queueURLFromEnv: QUEUE_URL
        awsRegion: us-east-1
        queueLength: "10"
        activationQueueLength: "1"

Funktionsweise:
Legt fest, wie KEDA die Authentifizierung bei AWS durchführt und wie die Anzahl der Replikate berechnet wird. Jeder Pod ist auf 10 Nachrichten ausgelegt, und die Skalierung auf Null wird aktiviert, sobald die Warteschlange leer ist.

4. Berechnungslogik für Replikate

KEDA berechnet den Arbeitsrückstand wie folgt:

UngefähreAnzahlDerNachrichten
+ UngefähreAnzahlDerNichtSichtbarenNachrichten
(+ verzögerte Nachrichten, falls aktiviert)

Replikationsberechnung:

gewünschte Replikate = ceil(offene Nachrichten / Warteschlangenlänge)

Beispiel (queueLength: „10“):

• 0 Nachrichten → 0 Pods
• 8 Nachrichten → 1 Pod
• 25 Nachrichten → 3 Pods
• 95 Nachrichten → 10 Pods

Die endgültige Anzahl der Replikate wird durch minReplicaCount und maxReplicaCount begrenzt.

5. Überprüfung

Nach dem Anwenden der Manifeste:

1. 50 Nachrichten an die SQS-Warteschlange senden

2. Überprüfen Sie das ScaledObject:

kubectl get scaledobject sqs-processor -n workers

3. Skalierung der Watch-Pods:

kubectl get pods -n workers -w

4. Überprüfen Sie, ob die Anzahl der Pods nach Abschluss der Verarbeitung wieder auf null zurückgeht

6. Behebung häufiger Probleme

Keine Skalierung nach außen

• Ursache: Falsche Warteschlangen-URL oder IAM-Berechtigungen
• Überprüfen Sie: `kubectl describe scaledobject`, KEDA-Operator-Protokolle

Zu viele Kapseln

• Grund: Zählung der Nachrichten während des Fluges
• Überprüfen: „scaleOnInFlight“, SQS-Sichtbarkeits-Timeout

Wird niemals auf Null skaliert

• Ursache: Verzögerte oder nicht bestätigte Nachrichten
• Überprüfen: Warteschlangenattribute und Anwendungsverhalten

HPA ist vorhanden, aber keine Skalierung

• Ursache: Fehler bei der Authentifizierung oder beim Abrufen von Metriken
• Überprüfung: KEDA-Protokolle und Fallback-Status

7. Tipps zur Produktionsoptimierung

• Wählen Sie die Warteschlangenlänge anhand des Durchsatzes aus, nicht nach dem Bauchgefühl
• Passen Sie die Abklingzeit und das HPA-Verhalten separat an – sie steuern unterschiedliche Skalierungswege nach unten
• Aktivieren Sie Fallback-Replikate zur Gewährleistung der Ausfallsicherheit, falls Metriken nicht mehr verfügbar sind
• Entscheiden Sie, ob „In-Flight“-Meldungen basierend auf dem Verhalten des Sichtbarkeits-Timeouts berücksichtigt werden sollen

Schlussfolgerung

Bei warteschlangenbasierten Workloads ist die CPU-basierte automatische Skalierung oft zu indirekt. KEDA ermöglicht es Kubernetes, die Skalierung direkt anhand des Amazon SQS-Backlogs vorzunehmen – der Kennzahl, die den tatsächlichen Bedarf widerspiegelt.

Das Ergebnis sind schnellere Reaktionen auf Spitzenauslastungen, geringere Leerlaufkosten und ein Skalierungsverhalten, das sich eng an der tatsächlichen Arbeitsauslastung orientiert. Für ereignisgesteuerte Systeme ist die Skalierung anhand der Warteschlangentiefe oft genau das Autoscaling-Modell, das Teams schon immer gebraucht haben.

Weitere Blogbeiträge findest duhier.