mécanisme de KEDA

Architecture et Fonctionnement de KEDA

KEDA (Kubernetes Event-driven Autoscaling) est un Metrics Adapter. Il sert de pont entre des sources de données externes et les mécanismes de scaling natifs de Kubernetes.

1. L’Architecture (Le Flux)

Le flux de décision suit cette hiérarchie :

Source de données $\to$ KEDA (Scaler) $\to$ HPA $\to$ ReplicaSet $\to$ Pods

---

2. Exemple de Code : Le ScaledObject

C’est ici que tu définis tes règles métier pour l’autoscaling.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: armonik-worker-scaler
spec:
  scaleTargetRef:
    name: armonik-worker-deployment 
  minReplicaCount: 0                # Autorise le "Scale to Zero"
  maxReplicaCount: 100
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus-server.monitoring.svc.cluster.local:9090
      metricName: armonik_tasks_queued
      # --- LE SEUIL (Threshold) ---
      # C'est le nombre de tâches (ou la valeur) cible PAR POD
      threshold: "5" 
      # --- LA REQUÊTE ---
      # C'est la somme totale des tâches dans le système
      query: sum(armonik_tasks_queued{status="Pending"}) 

---

3. Le Processus de Scaling (Exemple Chiffré)

Étape 1 : KEDA récupère le Total

KEDA exécute la query (ex: 200 tâches détectées).

Étape 2 : Le HPA calcule la charge actuelle (currentMetricValue)

Le HPA regarde le nombre de Pods qui tournent (ex: 4 Pods) et calcule la moyenne réelle par Pod :

$\text{currentMetricValue}=\frac{\text{Somme (200)}}{\text{Pods actuels (4)}}=50$

Étape 3 : La Décision (La Formule)

Le HPA applique sa formule pour atteindre le nombre de réplicas désiré :

$\text{desiredReplicas}=\lceil \text{currentReplicas}(4)\times \frac{\text{currentMetricValue}(50)}{\text{targetMetricValue}(5)}\rceil$

1. Le ratio : $50/5=10$. La charge est 10 fois supérieure à la cible par Pod.

2. Le calcul : $4\times 10=40\text{ Pods}$.

---

4. Processus de Terminaison Gracieuse (Scale Down)

Lorsqu’un Pod doit être supprimé pour réduire la voilure, Kubernetes suit un protocole de sécurité :

1. Signal SIGTERM : Envoyé au processus du conteneur. Le worker reçoit l’ordre de s’arrêter proprement (finir le calcul en cours).

2. Grace Period : Le cluster attend (terminationGracePeriodSeconds, défaut 30s).

3. Signal SIGKILL : Si le worker ne s’est pas arrêté après le délai, il est tué de force.

---

Synthèse technique

Terme technique	Ce que c’est concrètement
Threshold	Cible par Pod : Le nombre de tâches qu’un seul Pod doit idéalement traiter.
Query	Somme Totale : Le nombre total de tâches en attente dans tout le système.
CurrentMetricValue	Charge réelle : La moyenne de tâches par Pod à l’instant T.
DesiredReplicas	Objectif : Le nombre final de Pods calculé pour équilibrer la charge.