Autoscaling événementiel dans Kubernetes : tout le potentiel de KEDA

Kubernetes Event-driven Autoscaling ( KEDA) est un composant open-source pour Kubernetes qui enrichit les capacités d'autoscaling grâce à une mise à l'échelle événementielle, fondée sur des métriques personnalisées et des déclencheurs externes. Il étend le Horizontal Pod Autoscaler ( HPA) standard de Kubernetes pour offrir un autoscaling plus souple et plus granulaire.

Voici quelques-unes des fonctionnalités de KEDA :

• Autoscaling événementiel : KEDA met à l'échelle les applications à partir d'événements externes, comme le nombre de messages dans un topic Kafka ou le nombre d'événements dans un Azure Event Hub. Vos applications s'adaptent ainsi en temps réel à la demande.
• Scalers intégrés : KEDA est livré avec un catalogue de scalers prêts à l'emploi pour de nombreuses plateformes cloud, bases de données, systèmes de messagerie, systèmes de télémétrie, outils CI/CD et bien d'autres. Démarrer avec l'autoscaling événementiel devient ainsi très simple.
• Prise en charge de plusieurs types de workloads : KEDA gère divers types de workloads, comme les Deployments, les Jobs et les ressources personnalisées dotées de la sous-ressource /scale. Une solution flexible, adaptée à un large éventail d'applications.
• Extensible : avec KEDA, vous pouvez apporter vos propres scalers ou utiliser ceux maintenus par la communauté. De quoi répondre précisément aux besoins de chacune de vos applications.
• Réduction des coûts : KEDA permet de réduire vos coûts cloud en mettant vos applications à l'échelle zéro lorsqu'elles ne sont pas sollicitées. Les économies peuvent être substantielles, en particulier pour des applications dont la charge varie fortement.
• Indépendant du fournisseur : KEDA fonctionne avec n'importe quel cluster Kubernetes, quel que soit le fournisseur cloud. Un excellent choix pour les organisations qui souhaitent utiliser Kubernetes on-premises, dans le cloud ou en edge.
• Configuration et gestion simplifiées : KEDA propose une approche déclarative via les manifestes Kubernetes. Vous définissez vos règles d'autoscaling et vos déclencheurs dans des fichiers YAML ou JSON, ce qui rend la configuration et la gestion du comportement d'autoscaling particulièrement simples.

Voyons comment utiliser KEDA dans GKE pour autoscaler en s'appuyant sur les métriques de messages pub/sub. L'application d'exemple et les manifestes Kubernetes sont disponibles sur ce repo GitHub.

Prérequis

• Un cluster GKE avec workload identity activé
• Helm et Kubectl

Exécutez les commandes ci-dessous pour créer un topic et une souscription pub/sub.

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

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

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

GCP Workload Identity permet aux workloads exécutés dans des clusters GKE d'emprunter l'identité de comptes de service Identity and Access Management ( IAM) pour accéder aux services Google Cloud. C'est la méthode recommandée pour que les workloads tournant sur GKE accèdent aux services Google Cloud de manière sécurisée et facile à administrer.

Exécutez les commandes ci-dessous pour configurer workload identity pour KEDA.

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

#Create GCP service account
gcloud iam service-accounts create $KEDA_GCP_SERVICE_ACCOUNT \
--project=$GCP_PROJECT_ID

#Create IAM role bindings
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"

#Allow kubernetes service account to impersonate GCP service account
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]"

Plusieurs options s'offrent à vous pour installer KEDA sur un cluster Kubernetes :

• Helm charts
• Operator Hub
• Déclarations YAML

Nous allons utiliser le Helm Chart pour déployer KEDA dans le cluster GKE.

• Ajoutez et mettez à jour le repo Helm.

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

• Installez la dernière version du Helm chart KEDA.

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

Vérifiez les logs des pods keda et assurez-vous que l'application tourne sans erreur.

Les appels au webhook KEDA passent par le port 9443. Veillez donc à ce qu'une règle de pare-feu autorise le trafic du control plane vers les nœuds sur ce port. Sur GKE, les règles de pare-feu auto-générées n'ouvrent que les ports 443 et 10250 ; il faut donc créer une nouvelle règle pour le port 9443.

Exemple de commande gcloud pour la règle de pare-feu :

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

Configurez workload identity pour permettre à l'application d'exemple de consommer les messages de la souscription pub/sub.

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

#Create GCP service account
gcloud iam service-accounts create $SAMPLE_APP_GCP_SERVICE_ACCOUNT \
--project=$GCP_PROJECT_ID

#Create IAM role bindings
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"

#Allow kubernetes service account to impersonate GCP service account
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]"

Déployez l'application d'exemple sur le cluster GKE.

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

Déployer le KEDA Event Scaler

KEDA s'intègre nativement avec différents Scalers (sources d'événements) et s'appuie sur des Custom Resources ( CRDs) pour décrire les actions et paramètres de scaling souhaités. KEDA surveille la source d'événements et transmet ces données au Horizontal Pod Autoscaler ( HPA) afin de piloter une mise à l'échelle rapide des ressources.

Nous allons ici utiliser le scaler d'événements Google Cloud Platform Pub/Sub pour illustrer l'autoscaling. La relation de scaling entre une source d'événements et un workload donné (Deployment, StatefulSet, etc.) se configure via la Custom Resource Definition ScaledObject.

TriggerAuthentication permet de décrire les paramètres d'authentification indépendamment du ScaledObject et des conteneurs déployés. Il ouvre aussi la voie à des méthodes d'authentification plus avancées, comme la pod identity et la réutilisation des authentifications.

Déployez les ressources ci-dessous pour activer l'autoscaling : KEDA effectuera la mise à l'échelle en fonction du nombre de messages non acquittés dans la souscription.

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

Examinez la ressource HPA créée par KEDA.

Utilisez le script ci-dessous pour publier des messages de test sur le topic et observer les actions de scaling déclenchées par le HPA à partir des métriques fournies par KEDA.

#!/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

Démo de scaling avec KEDA