Event-Driven Autoscaling in Kubernetes mit KEDA

Kubernetes Event-driven Autoscaling (KEDA) ist eine Open-Source-Komponente für Kubernetes, die das Autoscaling um eine ereignisgesteuerte Skalierung auf Basis benutzerdefinierter Metriken und externer Trigger erweitert. Sie baut auf dem Standard-Horizontal Pod Autoscaler (HPA) in Kubernetes auf und ermöglicht eine flexiblere und feingranularere Skalierung.

Einige der Funktionen von KEDA im Überblick:

• Event-driven Autoscaling: KEDA skaliert Anwendungen anhand externer Ereignisse – etwa der Anzahl von Nachrichten in einem Kafka-Topic oder Events in einem Azure Event Hub. So passen sich Ihre Anwendungen in Echtzeit an die Nachfrage an.
• Integrierte Scaler: KEDA bringt einen umfangreichen Katalog vorgefertigter Scaler für diverse Cloud-Plattformen, Datenbanken, Messaging-Systeme, Telemetrielösungen, CI/CD und mehr mit. Der Einstieg ins Event-driven Autoscaling fällt damit leicht.
• Unterstützung verschiedener Workload-Typen: KEDA unterstützt eine Vielzahl von workloads – darunter Deployments, Jobs und Custom Resources mit der /scale-Subresource. Damit eignet es sich für unterschiedlichste Anwendungsfälle.
• Erweiterbar: KEDA lässt sich beliebig erweitern – Sie können eigene Scaler einbringen oder von der Community gepflegte Scaler nutzen und KEDA so passgenau auf Ihre Anwendungen zuschneiden.
• Kosteneinsparungen: KEDA senkt Cloud-Kosten, indem Anwendungen auf null heruntergefahren werden, wenn sie nicht benötigt werden. Gerade bei stark schwankenden workloads bringt das spürbare Einsparungen.
• Anbieterunabhängig: KEDA ist anbieterunabhängig und funktioniert mit jedem Kubernetes-Cluster – ideal für Organisationen, die Kubernetes on-premises, in der Cloud oder am Edge betreiben.
• Einfache Konfiguration und Verwaltung: KEDA setzt auf einen deklarativen Ansatz über Kubernetes-Manifeste. Autoscaling-Regeln und Trigger definieren Sie per YAML- oder JSON-Datei – das macht Konfiguration und Betrieb unkompliziert.

Sehen wir uns an, wie sich KEDA in GKE einsetzen lässt, um auf Basis von Pub/Sub-Nachrichten-Metriken zu skalieren. Die Beispielanwendung und die Kubernetes-Manifeste finden Sie im GitHub-Repo.

Voraussetzungen

• Ein GKE-Cluster mit aktivierter Workload Identity
• Helm und Kubectl

Mit den folgenden Befehlen legen Sie ein Pub/Sub-Topic samt Subscription an.

GCP_PROJECT_ID=$(gcloud config get-value project)
TOPIC_NAME=keda-demo-topic
SUBSCRIPTION_NAME=keda-demo-topic-subscription

# Topic anlegen
gcloud pubsub topics create $TOPIC_NAME --project $GCP_PROJECT_ID

# Subscription anlegen
gcloud pubsub subscriptions create $SUBSCRIPTION_NAME \
--topic $TOPIC_NAME \
--project $GCP_PROJECT_ID

GCP Workload Identity erlaubt workloads in GKE-Clustern, Dienstkonten von Identity and Access Management (IAM) zu impersonieren und so auf Google-Cloud-Dienste zuzugreifen. Workload Identity ist der empfohlene Weg, damit workloads in GKE sicher und gut verwaltbar auf Google-Cloud-Dienste zugreifen können.

Mit den folgenden Befehlen richten Sie Workload Identity für KEDA ein.

KEDA_GCP_SERVICE_ACCOUNT=keda-operator
KEDA_NAMESPACE=keda
KEDA_K8S_SERVICE_ACCOUNT=keda-operator

#GCP-Dienstkonto anlegen
gcloud iam service-accounts create $KEDA_GCP_SERVICE_ACCOUNT \
--project=$GCP_PROJECT_ID

#IAM-Rollenbindungen erstellen
gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
--member "serviceAccount:$KEDA_GCP_SERVICE_ACCOUNT@$GCP_PROJECT_ID.iam.gserviceaccount.com" \
--role "roles/monitoring.viewer"

#Kubernetes-Dienstkonto erlauben, das GCP-Dienstkonto zu impersonieren
gcloud iam service-accounts add-iam-policy-binding $KEDA_GCP_SERVICE_ACCOUNT@$GCP_PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:$GCP_PROJECT_ID.svc.id.goog[$KEDA_NAMESPACE/$KEDA_K8S_SERVICE_ACCOUNT]"

Für die Installation von KEDA auf einem Kubernetes-Cluster gibt es mehrere Optionen:

• Helm Charts
• Operator Hub
• YAML-Deklarationen

Wir nutzen das Helm Chart, um KEDA im GKE-Cluster auszurollen.

• Helm-Repo hinzufügen und aktualisieren.

helm repo add kedacore https://kedacore.github.io/charts
helm repo update

• Aktuelles KEDA Helm Chart installieren.

helm upgrade -install keda kedacore/keda \
--namespace keda \
--set 'serviceAccount.annotations.iam\.gke\.io\/gcp-service-account'="$KEDA_SERVICE_ACCOUNT@$GCP_PROJECT_ID.iam.gserviceaccount.com" \
--create-namespace \
--debug \
--wait

Prüfen Sie die Logs der keda-Pods und stellen Sie sicher, dass die Anwendung fehlerfrei läuft.

Die KEDA-Webhook-Aufrufe laufen über Port 9443. Stellen Sie daher sicher, dass jede Firewall-Regel zwischen Control Plane und Node die Kommunikation über Port 9443 zulässt. In GKE erlauben die automatisch generierten Firewall-Regeln nur die Ports 443 und 10250 – für Port 9443 müssen Sie eine zusätzliche Regel anlegen.

Beispiel für einen gcloud-Firewall-Befehl:

gcloud compute firewall-rules create allow-api-server-to-keda-webhook \
--description="Allow kubernetes api server to keda webhook call on worker nodes TCP port 9443" \
--direction=INGRESS \
--priority=1000 \
--network=$VPC-NETWORK-NAME \
--action=ALLOW \
--rules=tcp:9443 \
--source-ranges=$CONTROL-PLANE-IP-RANGE \
--target-tags=$NETWORK-TAGS-ASSIGNED-TO-NODES

Richten Sie Workload Identity für die Beispielanwendung ein, damit diese die Nachrichten aus der Pub/Sub-Subscription verarbeiten kann.

SAMPLE_APP_GCP_SERVICE_ACCOUNT=keda-demo
SAMPLE_APP_NAMESPACE=default
SAMPLE_APP_K8S_SERVICE_ACCOUNT=keda-demo

#GCP-Dienstkonto anlegen
gcloud iam service-accounts create $SAMPLE_APP_GCP_SERVICE_ACCOUNT \
--project=$GCP_PROJECT_ID

#IAM-Rollenbindungen erstellen
gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
--member "serviceAccount:$SAMPLE_APP_GCP_SERVICE_ACCOUNT@$GCP_PROJECT_ID.iam.gserviceaccount.com" \
--role "roles/pubsub.subscriber"

#Kubernetes-Dienstkonto erlauben, das GCP-Dienstkonto zu impersonieren
gcloud iam service-accounts add-iam-policy-binding $SAMPLE_APP_GCP_SERVICE_ACCOUNT@$GCP_PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:$GCP_PROJECT_ID.svc.id.goog[$KEDA_NAMESPACE/$KEDA_SERVICE_ACCOUNT]"

Deployen Sie die Beispielanwendung im GKE-Cluster.

cat <<EOF | kubectl apply -f -
---
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: keda-demo@$GCP_PROJECT_ID.iam.gserviceaccount.com
  name: keda-demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: keda-demo
spec:
  selector:
    matchLabels:
      app: keda-demo
  replicas: 1
  template:
    metadata:
      labels:
        app: keda-demo
    spec:
      serviceAccountName: keda-demo
      containers:
      - image: simbu1290/keda-demo:v1
        name: consumer
        env:
        - name: PUB_SUB_PROJECT
          value: $GCP_PROJECT_ID
        - name: PUB_SUB_TOPIC
          value: "keda-demo-topic"
        - name: PUB_SUB_SUBSCRIPTION
          value: "keda-demo-topic-subscription"
EOF

KEDA Event Scaler bereitstellen

KEDA integriert sich nahtlos mit verschiedenen Scalern (Eventquellen) und nutzt Custom Resources (CRDs), um die nötigen bzw. gewünschten Skalierungsaktionen und -parameter zu definieren. KEDA überwacht die Eventquelle und übergibt die Daten an den Horizontal Pod Autoscaler (HPA), der die schnelle Skalierung der Ressource übernimmt.

Wir nutzen hier den Google Cloud Platform Pub/Sub Event Scaler, um Auto Scaling zu zeigen. Die Skalierungsbeziehung zwischen Eventquelle und konkreter Workload (z. B. Deployment, StatefulSet) konfigurieren Sie über die ScaledObject Custom Resource Definition.

Mit TriggerAuthentication beschreiben Sie Authentifizierungsparameter unabhängig vom ScaledObject und den Deployment-Containern. Außerdem werden so erweiterte Authentifizierungsmethoden wie Pod Identity und die Wiederverwendung von Authentifizierungen möglich.

Deployen Sie die folgenden Ressourcen für das Autoscaling – KEDA skaliert dann auf Basis der Anzahl unbestätigter Nachrichten in der Subscription.

cat <<EOF | kubectl apply -f -
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-demo-trigger-auth-gcp-credentials
spec:
  podIdentity:
    provider: gcp
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: keda-demo-pubsub-scaledobject
spec:
  scaleTargetRef:
    apiVersion: apps/v1 # Optional. Default: apps/v1
    kind: Deployment    # Optional. Default: Deployment
    name: keda-demo     # Mandatory. Must be in the same namespace as the ScaledObject
  pollingInterval: 5    # Optional. Default: 30 seconds
  minReplicaCount: 1    # Optional. Default: 0
  maxReplicaCount: 10   # Optional. Default: 100
  triggers:
  - type: gcp-pubsub
    authenticationRef:
      kind: TriggerAuthentication
      name: keda-demo-trigger-auth-gcp-credentials
    metadata:
      mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge
      value: "5" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge
      subscriptionName: "keda-demo-topic-subscription" # Mandatory
EOF

Werfen Sie einen Blick auf die HPA-Ressource, die KEDA erzeugt hat.

Mit dem folgenden Skript veröffentlichen Sie Testnachrichten im Topic und beobachten, wie der HPA auf Basis der von KEDA gelieferten Metriken skaliert.

#!/bin/bash

project_id=$GCP_PROJECT_ID
topic_name=$TOPIC_NAME

while true; do
    message="Hello, Pub/Sub!"
    gcloud pubsub topics publish ${topic_name} \
    --message "${message}" \
    --project ${project_id}
    sleep 1
done

KEDA-Skalierungsdemo