Résoudre les problèmes liés au module complémentaire de mise à l’échelle automatique pilotée par les événements Kubernetes

Article
04/12/2024

Cet article explique comment résoudre les problèmes liés au module complémentaire KeDA (Kubernetes Event-driven Autoscaling) dans Microsoft Azure Kubernetes Service (AKS). Lorsque vous déployez le module complémentaire AKS KEDA, vous pouvez rencontrer des problèmes associés à la configuration de la mise à l’échelle automatique de l’application. Cet article vous aidera à résoudre les erreurs et à résoudre les problèmes courants qui affectent le module complémentaire, mais qui ne sont pas abordés dans le FAQ et le guide de résolution des problèmes KEDA officiels.

Conditions préalables

Outil Kubernetes kubectl . Pour installer kubectl à l’aide d’Azure CLI, exécutez la commande az aks install-cli .

Prise en charge du module complémentaire KEDA

Le module complémentaire KEDA suit un modèle de prise en charge similaire à celui des autres modules complémentaires AKS. Tous les scalers Azure KEDA sont pris en charge, mais AKS ne prend pas en charge les scalers tiers. Si vous rencontrez des problèmes avec des scalers tiers, ouvrez un problème dans le dépôt GitHub KEDA officiel.

Liste de pour la résolution des problèmes

Vérifiez et résolvez les problèmes des composants KEDA à l’aide des instructions fournies dans les sections suivantes.

Vérifier la version de KEDA disponible

Vous pouvez déterminer la version keda disponible à l’aide de la commande kubectl get :

kubectl get crd/scaledobjects.keda.sh -o custom-columns='APP:.metadata.labels.app\.kubernetes\.io/version'

La sortie de la commande affiche la version installée de KEDA :

APP
2.8.1

Vérifiez que le pare-feu du cluster est correctement configuré

KEDA peut ne pas mettre à l’échelle les applications correctement, car il ne peut pas démarrer.

Lorsque vous case activée les journaux de l’opérateur, vous pouvez trouver des entrées d’erreur qui ressemblent au texte suivant :

1.6545953013458195e+09 ERROR Failed to get API Group-Resources {"error": "Get \"https://10.0.0.1:443/api?timeout=32s\": EOF"}
sigs.k8s.io/controller-runtime/pkg/cluster.New
/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.2/pkg/cluster/cluster.go:160
sigs.k8s.io/controller-runtime/pkg/manager.New
/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.2/pkg/manager/manager.go:313
main.main
/workspace/main.go:87
runtime.main
/usr/local/go/src/runtime/proc.go:255
1.6545953013459463e+09 ERROR setup unable to start manager {"error": "Get \"https://10.0.0.1:443/api?timeout=32s\": EOF"}
main.main
/workspace/main.go:97
runtime.main
/usr/local/go/src/runtime/proc.go:255

Dans la section serveur de métriques, vous pouvez découvrir que KEDA ne peut pas démarrer :

I0607 09:53:05.297924 1 main.go:147] keda_metrics_adapter "msg"="KEDA Version: 2.7.1"
I0607 09:53:05.297979 1 main.go:148] keda_metrics_adapter "msg"="KEDA Commit: "
I0607 09:53:05.297996 1 main.go:149] keda_metrics_adapter "msg"="Go Version: go1.17.9"
I0607 09:53:05.298006 1 main.go:150] keda_metrics_adapter "msg"="Go OS/Arch: linux/amd64"
E0607 09:53:15.344324 1 logr.go:279] keda_metrics_adapter "msg"="Failed to get API Group-Resources" "error"="Get \"https://10.0.0.1:443/api?timeout=32s\": EOF"
E0607 09:53:15.344360 1 main.go:104] keda_metrics_adapter "msg"="failed to setup manager" "error"="Get \"https://10.0.0.1:443/api?timeout=32s\": EOF"
E0607 09:53:15.344378 1 main.go:209] keda_metrics_adapter "msg"="making provider" "error"="Get \"https://10.0.0.1:443/api?timeout=32s\": EOF"
E0607 09:53:15.344399 1 main.go:168] keda_metrics_adapter "msg"="unable to run external metrics adapter" "error"="Get \"https://10.0.0.1:443/api?timeout=32s\": EOF"

Ce scénario signifie probablement que le module complémentaire KEDA ne peut pas démarrer en raison d’un pare-feu mal configuré. Pour vous assurer que KEDA s’exécute correctement, configurez le pare-feu pour qu’il réponde aux règles de réseau requises d’Azure Global.

Activer le module complémentaire pour les clusters avec des installations KEDA open source autogérées

En théorie, vous pouvez installer KEDA plusieurs fois, même si Kubernetes n’autorise qu’un seul serveur de métriques à être installé. Toutefois, nous ne recommandons pas plusieurs installations, car une seule installation fonctionne.

Lorsque le module complémentaire KEDA est installé sur un cluster AKS, l’installation précédente de KEDA open source est remplacée et le module complémentaire prend le relais. Dans ce scénario, la personnalisation et la configuration du déploiement KEDA auto-installé seront perdues et ne seront plus appliquées.

Bien que la mise à l’échelle automatique existante puisse continuer à être opérationnelle, cette situation présente un risque. Le module complémentaire KEDA sera configuré différemment et ne prendra pas en charge les fonctionnalités telles que l’identité managée. Pour éviter les erreurs pendant l’installation, nous vous recommandons de désinstaller les installations KEDA existantes avant d’activer le module complémentaire KEDA.

Pour déterminer l’adaptateur de métriques utilisé par KEDA, exécutez la kubectl get commande :

kubectl get APIService/v1beta1.external.metrics.k8s.io -o custom-columns='NAME:.spec.service.name,NAMESPACE:.spec.service.namespace'

Une vue d’ensemble montre le service et l’espace de noms que Kubernetes utilisera pour obtenir des métriques :

NAME                              NAMESPACE
keda-operator-metrics-apiserver   kube-system

Avertissement

Si l’espace de noms n’est pas kube-system, le module complémentaire AKS est ignoré et un autre serveur de métriques est utilisé.

Comment redémarrer des pods d’opérateur KEDA lorsque l’identité de charge de travail n’est pas injectée correctement

Si vous utilisez ID de charge de travail Microsoft Entra et que vous activez KEDA avant l’utilisation de la ID de charge de travail, vous devez redémarrer les pods de l’opérateur KEDA. Cela garantit que les variables d’environnement correctes sont injectées. Pour cela, procédez comme suit :

Redémarrez les pods en exécutant la commande suivante :

kubectl rollout restart deployment keda-operator -n kube-system

Obtenez des pods d’opérateur KEDA en exécutant la commande suivante, puis recherchez les pods dont le nom commence par « keda-operator ».
```
kubectl get pod -n kube-system
```
Pour vérifier que les variables d’environnement ont été correctement injectées, exécutez la commande suivante :
```
kubectl describe pod <keda-operator-pod-name> -n kube-system
```
Si les variables ont été correctement injectées, vous devez voir les valeurs pour AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILEet AZURE_AUTHORITY_HOST dans la section Environnement .

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.

Partager via