Résoudre les problèmes liés au module complémentaire Kubernetes Event-driven Autoscaling

Article
08/13/2024

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

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 des modules complémentaires KEDA

Le module complémentaire KEDA suit un modèle de prise en charge similaire à d’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 contrôle pour la résolution des problèmes

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

Vérifier la version 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 commande affiche la version installée de KEDA :

APP
2.8.1

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

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

Lorsque vous vérifiez les journaux des opérateurs, 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 n’est pas en mesure de démarrer en raison d’un pare-feu mal configuré. Pour vous assurer que KEDA s’exécute correctement, configurez le pare-feu pour répondre aux règles réseau requises Azure Global.

Activer le module complémentaire pour les clusters avec des installations KEDA open source auto-managées

En théorie, vous pouvez installer KEDA plusieurs fois, même si Kubernetes autorise l’installation d’un seul serveur de métriques. 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 sera remplacée et le module complémentaire prendra le relais. Dans ce scénario, la personnalisation et la configuration du déploiement KEDA autoinstallé seront perdues et ne seront plus appliquées.

Bien que la mise à l’échelle automatique existante continue d’ê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 les 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 du ID de charge de travail, vous devez redémarrer les pods d’opérateur KEDA. Cela garantit que les variables d’environnement appropriées sont injectées. Pour ce faire, 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 localisez les pods avec des noms commençant 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é injectées avec succès, 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