abla.adem

Recent Notes

Solution probable

2 min read

Analyse de la configuration problématique

1. Scaling très agressif

behavior:
  scaleDown:
    policies:
      - periodSeconds: 15 # ⚠️ TROP RAPIDE
        type: Percent
        value: 20          # ⚠️ 20% toutes les 15s = très agressif
    stabilizationWindowSeconds: 30 # ⚠️ TROP COURT
 
cooldownPeriod: 30  # ⚠️ TROP COURT
pollingInterval: 15 # ⚠️ TROP FRÉQUENT

2. Impact sur les tâches

  • KEDA évalue les métriques toutes les 15 secondes.
  • Si les tâches diminuent, il peut supprimer 20% des pods toutes les 15 secondes.
  • Seulement 30 secondes de stabilisation avant un nouveau scale-down.

3. Scénario typique de vos erreurs

10:20:05 - Cancellation triggered (scale-down)
 10:44:22 - Error while executing task (échec de resoumission)

Métriques actuelles dans le HPA :

currentMetrics:
  - external:
    Current:
      averageValue: '0' # Pas de tâches en attente
currentReplicas: 10 # Minimum maintenu
desiredReplicas: 10

Solution recommandée

1. Configuration KEDA plus conservatrice

spec:
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          policies:
            - periodSeconds: 60      # 4x plus lent
              type: Percent
              value: 10              # 2x moins agressif
          stabilizationWindowSeconds: 300 # 10x plus stable
        scaleUp:
          stabilizationWindowSeconds: 30  # Scale up rapide OK
  cooldownPeriod: 300  # 10x plus long
  pollingInterval: 30  # 2x moins fréquent

2. Pourquoi cette configuration cause des problèmes

  • Tâches longues : Si une tâche prend plus de 15-30 secondes, elle risque d’être interrompue.
  • Latence de redémarrage : Le temps de créer un nouveau pod et reprendre la tâche.
  • Contention : Plusieurs tâches annulées simultanément surchargent le système de resoumission.

3. Configuration recommandée pour votre workload

# Pour des tâches ArmoniK qui peuvent être longues
pollingInterval: 60
cooldownPeriod: 600
advanced:
  horizontalPodAutoscalerConfig:
    behavior:
      scaleDown:
        policies:
          - periodSeconds: 120
            type: Percent
            value: 10
        stabilizationWindowSeconds: 600 # 10 minutes

Monitoring pour valider le changement

#Surveiller la fréquence des scaling events :
   kubectl get events --field-selector reason=SuccessfulRescale --sort-by='.firstTimestamp'
 #Surveiller les échecs de resoumission ArmoniK :
   #(logs avec NbError > 1)

Conclusion : Vos cancellations sont causées par un scaling KEDA trop agressif. Le système n’a pas le temps de terminer proprement les tâches avant d’être scalé down.

Graph View

Backlinks