Partager via

Mise à l’échelle automatique des applications simplifiée avec le module complémentaire KEDA (Kubernetes Event-driven Autoscaling)

Important

Le module complémentaire KEDA pour AKS ne prend actuellement pas en charge la modification des demandes ou limites de CPU et d'autres valeurs Helm, pour le Metrics Server ou l'Operator. Gardez cette limitation à l’esprit lors de l’utilisation du module complémentaire. Si vous avez des questions, n’hésitez pas à contacter ici.

La mise à l’échelle automatique basée sur les événements Kubernetes (KEDA) est un composant léger et à usage unique qui s’efforce de simplifier l'autoscaling des applications et est un projet diplômé de la Cloud Native Computing Foundation (CNCF).

Elle applique la mise à l’échelle automatique basée sur les événements pour mettre à l’échelle votre application afin qu’elle réponde à la demande de manière durable et rentable avec une mise à l’échelle à zéro.

Le module complémentaire KEDA facilite le déploiement d’une installation KEDA managée, ce qui vous fournit un catalogue complet d’utilitaires de mise à l’échelle KEDA Azure pour mettre à l’échelle vos applications sur votre cluster Azure Kubernetes Services (AKS).

Remarque

La version 2.15+ de KEDA introduit un changement cassant qui supprime la prise en charge de l’identité de pod. Nous vous recommandons de passer à l’identité de la charge de travail à des fins d’authentification si vous utilisez l’identité de pod. Bien que le module complémentaire managé KEDA n’exécute actuellement pas KEDA version 2.15+, il commence à l’exécuter dans la préversion AKS version 1.32.

Pour plus d’informations sur la mise à l’échelle sécurisée de vos applications avec l’identité de charge de travail, lisez notre tutoriel. Pour voir la stratégie de changement/dépréciation de KEDA, lisez leur documentation officielle.

Architecture

KEDA fournit deux composants principaux :

  • L’opérateur KEDA permet aux utilisateurs finaux d'ajuster l'échelle des charges de travail de 0 à N instances avec prise en charge des Déploiements Kubernetes, des Travaux, StatefulSets, et de toute ressource personnalisée qui définit une /scale sous-ressource.
  • Le serveur de métriques expose des métriques externes à HPA (Horizontal Pod Autoscaler) dans Kubernetes à des fins de mise à l’échelle automatique, telles que des messages dans une rubrique Kafka ou un nombre d’événements dans un Event Hub Azure. En raison des limitations en amont, KEDA doit être le seul adaptateur de métriques externe installé.

Diagramme montrant l’architecture de KEDA et la façon dont elle étend Kubernetes.

En savoir plus sur le fonctionnement de KEDA dans la documentation officielle de KEDA.

Installation

KEDA peut être ajouté à votre cluster Azure Kubernetes Service (AKS) en activant le module complémentaire KEDA à l’aide d’un modèle ARM ou Azure CLI.

Le module complémentaire KEDA fournit une installation entièrement prise en charge de KEDA qui est intégrée à AKS.

Capacités et fonctionnalités

KEDA fournit les fonctionnalités suivantes :

  • Créer des applications durables et rentables avec mise à l’échelle à zéro
  • Mettre à l’échelle les charges de travail d’application pour répondre à la demande en utilisant un catalogue complet d’utilitaires de mise l’échelle KEDA
  • Mettre à l’échelle automatiquement des applications avec ScaledObjects, telles que les déploiements, les StatefulSetsou toute ressource personnalisée qui définit /scale sous-ressource
  • Mettre à l’échelle automatiquement des charges de travail avec ScaledJobs
  • Utiliser la sécurité de niveau production en découplant l’authentification de mise à l’échelle automatique à partir de charges de travail
  • Apporter son propre scaler externe pour utiliser des décisions de mise à l’échelle automatique personnalisées
  • Intégrer l’ID de charge de travail Microsoft Entra pour l’authentification

Remarque

Si vous envisagez d’utiliser l’identité de charge de travail, activez le module complémentaire d’identité de charge de travail avant d’activer le module complémentaire KEDA.

Limitations relatives aux modules complémentaires

Le module complémentaire KEDA AKS présente les limitations suivantes :

  • Le module complémentaire HTTP (préversion) de KEDA pour mettre à l’échelle les charges de travail HTTP n’est pas installé avec l’extension, mais peut être déployé séparément.
  • Le scaler externe pour Azure Cosmos DB de KEDA pour mettre à l’échelle en fonction du flux de modification Azure Cosmos DB n’est pas installé avec l’extension, mais peut être déployé séparément.
  • Un seul serveur de métriques externe est autorisé dans le cluster Kubernetes. Pour cela, le module complémentaire KEDA doit être le seul serveur de métriques externe à l’intérieur du cluster.
    • Plusieurs installations KEDA ne sont pas prises en charge
  • Il n’est pas recommandé de combiner KEDA ScaledObject avec un HPA (Horizontal Pod Autoscaler) pour mettre à l’échelle la même charge de travail. Ils sont en concurrence les uns avec les autres, car KEDA utilise l’autoscaler de pod horizontal (HPA) en arrière-plan et entraîne un comportement de mise à l’échelle impair.
    • Si un HPA est créé en premier, un KEDA ScaledObject est créé et le KEDA ScaledObject ne sera pas créé.
    • Si un KEDA ScaledObject est créé en premier, puis qu’un HPA est créé, la création HPA n’est pas bloquée.

Pour des questions générales sur KEDA, nous vous recommandons de consulter la vue d’ensemble de la FAQ.

Remarque

Si vous utilisez l’ID de charge de travail Microsoft Entra et que vous activez KEDA avant l’ID de charge de travail, vous devez redémarrer les pods d’opérateur KEDA afin que les variables d’environnement appropriées puissent être injectées :

  1. Redémarrez les pods en exécutant kubectl rollout restart deployment keda-operator -n kube-system.

  2. Obtenez des pods d’opérateur KEDA en utilisant kubectl get pod -n kube-system et en recherchant les pods commençant par keda-operator.

  3. Vérifiez que l’injection des variables d’environnement a réussi en exécutant kubectl describe pod <keda-operator-pod> -n kube-system. Sous Environment, vous devez voir les valeurs de AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE et AZURE_AUTHORITY_HOST.

Versions Kubernetes et KEDA prises en charge

Votre version kubernetes de cluster détermine la version KEDA installée sur votre cluster AKS. Pour voir la version KEDA mappée à chaque version AKS, consultez la colonne Modules complémentaires gérés par AKS du tableau des versions de composant Kubernetes.

Pour les versions Kubernetes GA, AKS offre une prise en charge complète de la version mineure KEDA correspondante dans le tableau. Les préversions de Kubernetes et le dernier patch KEDA sont partiellement couverts par le service client, dans la mesure du possible. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

Étapes suivantes