Risoluzione dei problemi dell'add-on di scalabilità automatica guidata da eventi di Kubernetes

Sommario

Questo articolo illustra come risolvere i problemi legati al componente aggiuntivo Kubernetes Event-driven Autoscaling (KEDA) per il Microsoft Azure Kubernetes Service (AKS). Quando si distribuisce il componente aggiuntivo KEDA per AKS, è possibile che si verifichino problemi associati alla configurazione del componente di scalabilità automatica dell'applicazione. Questo articolo consente di risolvere gli errori e risolvere i problemi comuni che influiscono sul componente aggiuntivo, ma non sono trattati nella guida ufficiale KEDA di domande frequenti e risoluzione dei problemi.

Prerequisiti

Supporto dei componenti aggiuntivi KEDA

Il componente aggiuntivo KEDA segue un modello di supporto simile ad altri componenti aggiuntivi AKS. Tutti i scaler KEDA di Azure sono supportati, ma AKS non supporta i scaler di terze parti. Se si verificano problemi con i scaler di terze parti, aprire un problema nel repository GitHub KEDA ufficiale.

Elenco di controllo per la risoluzione dei problemi

Verificare e risolvere i problemi dei componenti KEDA seguendo le istruzioni riportate nelle sezioni seguenti.

Controllare la versione KEDA disponibile

È possibile determinare la versione keda disponibile usando il comando kubectl get :

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

L'output del comando visualizza la versione installata di KEDA:

APP
2.8.1

Assicurarsi che il firewall del cluster sia configurato correttamente

KEDA potrebbe non ridimensionare correttamente le applicazioni perché non riesce ad avviarsi.

Quando si controllano i log degli operatori, è possibile trovare voci di errore simili al testo seguente:

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

Nella sezione server delle metriche è possibile scoprire che KEDA non può iniziare:

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"

Questo scenario significa probabilmente che il componente aggiuntivo KEDA non è in grado di avviare a causa di un firewall non configurato correttamente. Per assicurarsi che KEDA venga eseguito correttamente, configurare il firewall in modo che soddisfi le regole di rete richieste a livello globale di Azure.

Abilitare il componente aggiuntivo per i cluster con installazioni KEDA open source autogestte

In teoria, è possibile installare KEDA più volte, anche se Kubernetes consente l'installazione di un solo server metrico. Tuttavia, non è consigliabile più installazioni perché solo un'installazione funzionerebbe.

Quando il componente aggiuntivo KEDA viene installato in un cluster del servizio Azure Kubernetes, l'installazione precedente di KEDA open source verrà sostituita e il componente aggiuntivo assumerà il controllo. In questo scenario, la personalizzazione e la configurazione della distribuzione KEDA installata automaticamente andranno perse e non verranno più applicate.

Anche se la scalabilità automatica esistente potrebbe continuare a essere operativa, questa situazione comporta un rischio. Il componente aggiuntivo KEDA verrà configurato in modo diverso e non supporterà funzionalità come l'identità gestita. Per evitare errori durante l'installazione, è consigliabile disinstallare le installazioni KEDA esistenti prima di abilitare il componente aggiuntivo KEDA.

Per determinare quale adattatore metriche viene usato da KEDA, eseguire il kubectl get comando :

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

Una panoramica mostra il servizio e lo spazio dei nomi che Kubernetes userà per ottenere le metriche:

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

Avviso

Se lo spazio dei nomi non è kube-system, il componente aggiuntivo AKS viene ignorato e viene usato un altro server di metriche.

Come riavviare i pod dell'operatore KEDA quando la workload identity non viene inserita correttamente

Se si usa ID dei carichi di lavoro di Microsoft Entra e si abilita KEDA prima che venga usato il ID dei carichi di lavoro, è necessario riavviare i pod dell'operatore KEDA. In questo modo si garantisce che vengano inserite le variabili di ambiente corrette. A tale scopo, effettuare i passaggi seguenti:

  1. Riavviare i pod eseguendo il comando seguente:

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

  2. Ottenere i pod dell'operatore KEDA eseguendo il comando seguente e quindi individuare i pod con nomi che iniziano con "keda-operator".

    kubectl get pod -n kube-system

  3. Per verificare che le variabili di ambiente siano state inserite correttamente, eseguire il comando seguente:

    kubectl describe pod <keda-operator-pod-name> -n kube-system

    Se le variabili sono state inserite correttamente, verranno visualizzati i valori per AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILEe AZURE_AUTHORITY_HOST nella sezione Ambiente .

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

  • Last updated on