Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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é.
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, lesStatefulSets
ou 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 KEDAScaledObject
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.
- Si un HPA est créé en premier, un KEDA
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 :
Redémarrez les pods en exécutant
kubectl rollout restart deployment keda-operator -n kube-system
.Obtenez des pods d’opérateur KEDA en utilisant
kubectl get pod -n kube-system
et en recherchant les pods commençant parkeda-operator
.Vérifiez que l’injection des variables d’environnement a réussi en exécutant
kubectl describe pod <keda-operator-pod> -n kube-system
. SousEnvironment
, vous devez voir les valeurs deAZURE_TENANT_ID
,AZURE_FEDERATED_TOKEN_FILE
etAZURE_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
- Activer le module complémentaire KEDA avec un modèle ARM
- Activer le module complémentaire KEDA avec Azure CLI
- Résoudre les problèmes du module complémentaire KEDA
- Mettre à l’échelle automatiquement un Worker .NET Core traitant les messages de file d’attente Azure Service Bus
- Consultez la documentation KEDA en amont
Azure Kubernetes Service