Risolvere i problemi relativi alla scalabilità automatica orizzontale dei pod

Quando la scalabilità automatica orizzontale dei pod non funziona come previsto in Google Kubernetes Engine (GKE), i tuoi carichi di lavoro potrebbero non essere scalati correttamente. Questo problema può impedire alle applicazioni di gestire il carico, il che può causare problemi di prestazioni o interruzioni. Potresti notare che i pod non aumentano nonostante l'utilizzo elevato della CPU, i valori delle metriche visualizzati come <unknown> nello stato di HorizontalPodAutoscaler o le operazioni di scalabilità non vengono eseguite.

Utilizza questo documento per diagnosticare e risolvere i problemi comuni relativi alla scalabilità automatica pod orizzontale, dalle configurazioni errate iniziali negli oggetti HorizontalPodAutoscaler a errori più complessi all'interno della pipeline delle metriche. Seguendo questi passaggi per la risoluzione dei problemi, puoi assicurarti che le tue applicazioni scalino in modo efficiente e affidabile in base alla domanda, utilizzando in modo efficace la risorsa HorizontalPodAutoscaler.

Queste informazioni sono importanti per gli sviluppatori di applicazioni che configurano oggetti HorizontalPodAutoscaler e devono assicurarsi che le loro applicazioni vengano scalate correttamente. Aiuta inoltre gli amministratori e gli operatori della piattaforma a risolvere i problemi relativi alla pipeline delle metriche o alla configurazione del cluster che influiscono su tutti i carichi di lavoro con scalabilità automatica. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Prima di iniziare

  • Assicurati di utilizzare gli oggetti HorizontalPodAutoscaler con workload scalabili, come Deployment e StatefulSet. Non puoi utilizzare la scalabilità automatica pod orizzontale con i workload che non possono essere scalati, ad esempio DaemonSet.

  • Per ottenere le autorizzazioni necessarie per risolvere i problemi relativi alla scalabilità automatica orizzontale dei pod in GKE, che include l'ispezione degli oggetti HorizontalPodAutoscaler e la visualizzazione dei log del cluster, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto:

    Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

    Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

  • Configura lo strumento a riga di comando kubectl per comunicare con il tuo cluster GKE:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location LOCATION \
    --project PROJECT_ID

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster.
    • LOCATION: la regione o la zona di Compute Engine (ad esempio us-central1 o us-central1-a) per il cluster.
    • PROJECT_ID: il tuo ID progetto Google Cloud .

Diagnosticare i problemi di HorizontalPodAutoscaler

Per diagnosticare i problemi relativi a un HorizontalPodAutoscaler, esamina lo stato e la configurazione utilizzando i comandi kubectl o la console Google Cloud .

Descrivi l'oggetto HorizontalPodAutoscaler

Per visualizzare i calcoli in tempo reale e le decisioni di scalabilità recenti, utilizza il comando kubectl describe hpa:

kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

Sostituisci quanto segue:

  • HPA_NAME: il nome dell'oggetto HorizontalPodAutoscaler.
  • NAMESPACE_NAME: lo spazio dei nomi dell'oggetto HorizontalPodAutoscaler.

L'output è simile al seguente:

Name:                                                  php-apache-hpa
Namespace:                                             default
Reference:                                             Deployment/php-apache
Metrics: ( current / target )
  resource cpu on pods (as a percentage of request):   1% (1m) / 50%
Min replicas:                                          1
Max replicas:                                          10
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HorizontalPodAutoscaler was able to successfully calculate a replica count
Events:
  Type     Reason              Age   From                       Message
  ----     ------              ----  ----                       -------
  Normal   SuccessfulRescale   39m   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization...
  Normal   SuccessfulRescale   26m   horizontal-pod-autoscaler  New size: 1; reason: cpu resource utilization...

Nell'output, le seguenti tre sezioni ti aiutano a diagnosticare il problema:

  • Metrics: mostra i valori attuali delle metriche rispetto ai relativi target. Un valore della metrica <unknown> indica che HorizontalPodAutoscaler non ha recuperato la metrica o che la pipeline delle metriche è interrotta.
  • Conditions: indica se HorizontalPodAutoscaler può recuperare le metriche (AbleToScale) ed eseguire i calcoli di scalabilità (ScalingActive). Uno stato False in una di queste condizioni indica un errore.
  • Events: registra le azioni di scalabilità, gli avvisi e gli errori recenti del controller HorizontalPodAutoscaler. Spesso è il primo posto in cui trovare messaggi o motivi di errore specifici, ad esempio FailedGetScale o FailedGetResourceMetric.

Controlla il manifest HorizontalPodAutoscaler

Il manifest YAML dell'oggetto HorizontalPodAutoscaler ti consente di visualizzare informazioni sulla sua configurazione e sul suo stato attuale.

Per visualizzare il manifest YAML, seleziona una delle seguenti opzioni:

Console

  1. Nella console Google Cloud , vai alla pagina Visualizzatore oggetti.

    Vai a Esplora oggetti

  2. Nell'elenco Tipi di oggetti, seleziona la casella di controllo HorizontalPodAutoscaler e fai clic su Ok.

  3. Vai al gruppo API autoscaling, quindi fai clic sulla freccia di espansione per HorizontalPodAutoscaler.

  4. Fai clic sul nome dell'oggetto HorizontalPodAutoscaler che vuoi ispezionare.

  5. Esamina la sezione YAML, che mostra la configurazione completa dell'oggetto HorizontalPodAutoscaler.

kubectl

Esegui questo comando:

kubectl get hpa HPA_NAME -n NAMESPACE_NAME -o yaml

Sostituisci quanto segue:

  • HPA_NAME: il nome dell'oggetto HorizontalPodAutoscaler.
  • NAMESPACE_NAME: lo spazio dei nomi dell'oggetto HorizontalPodAutoscaler.

Dopo aver recuperato il manifest, cerca queste sezioni chiave:

  • spec (la tua configurazione):
    • scaleTargetRef: il workload (ad esempio un deployment) per cui è configurato lo scale di HorizontalPodAutoscaler.
    • minReplicas e maxReplicas: le impostazioni minime e massime delle repliche.
    • metrics: le metriche configurate per lo scaling (ad esempio, utilizzo della CPU o metriche personalizzate).
  • status (lo stato live di HorizontalPodAutoscaler):
    • currentMetrics: i valori delle metriche più recenti che HorizontalPodAutoscaler ha osservato.
    • currentReplicas e desiredReplicas: il numero attuale di pod e il numero a cui HorizontalPodAutoscaler vuole scalare.
    • conditions: mostra lo stato di integrità di HorizontalPodAutoscaler:
      • AbleToScale: indica se HorizontalPodAutoscaler può trovare la destinazione e le metriche.
      • ScalingActive: indica se HorizontalPodAutoscaler può calcolare ed eseguire lo scaling.
      • ScalingLimited: indica se HorizontalPodAutoscaler vuole scalare, ma è limitato dalle impostazioni di minReplicas o maxReplicas.

Visualizzare i log eventi

Per ottenere informazioni più approfondite sull'oggetto HorizontalPodAutoscaler, utilizza i seguenti tipi di log:

  • Visualizza gli eventi HorizontalPodAutoscaler in Cloud Logging: utilizza un filtro log per trovare tutti gli eventi HorizontalPodAutoscaler per un cluster specifico. Ad esempio:

    1. Nella console Google Cloud , vai alla pagina Esplora log.

      Vai a Esplora log

    2. Nel riquadro della query, inserisci la seguente query:

      resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
logName="projects/PROJECT_ID/logs/events"
jsonPayload.involvedObject.kind="HorizontalPodAutoscaler"

      Sostituisci quanto segue:

      • CLUSTER_NAME: il nome del cluster a cui appartiene HorizontalPodAutoscaler.
      • LOCATION: la regione o la zona di Compute Engine (ad esempio, us-central1 o us-central1-a) per il cluster.
      • PROJECT_ID: il tuo ID progetto.

    3. Fai clic su Esegui query e rivedi l'output.

  • Visualizza gli eventi di scalabilità automatica orizzontale dei pod: questi log forniscono log strutturati e leggibili che spiegano come HorizontalPodAutoscaler calcola un consiglio, offrendo informazioni dettagliate sul suo processo decisionale.

Risolvere gli errori di configurazione di HorizontalPodAutoscaler

Le sezioni seguenti riguardano le configurazioni errate nel manifest HorizontalPodAutoscaler, come campi digitati in modo errato, target delle metriche non validi o configurazioni in conflitto.

Carico di lavoro di destinazione non trovato

Sintomi

La sezione Events ha una condizione FailedGetScale con un messaggio simile al seguente:

the HorizontalPodAutoscaler controller was unable to get the target's current scale: WORKLOAD_TYPE.apps "TARGET_WORKLOAD" not found

Questo output include i seguenti valori:

  • WORKLOAD_TYPE: il tipo di workload, ad esempio Deployment o StatefulSet.
  • TARGET_WORKLOAD: il nome del workload.

Causa

Il controller HorizontalPodAutoscaler non riesce a trovare il workload (ad esempio un deployment o uno StatefulSet) che è configurato per gestire. Questo problema si verifica a causa di una configurazione errata nel campo scaleTargetRef all'interno del manifest di HorizontalPodAutoscaler. La risorsa specificata potrebbe non esistere, essere stata eliminata o contenere un errore di ortografia.

Risoluzione

Prova le seguenti soluzioni:

  1. Verifica il campo scaleTargetRef del manifest HorizontalPodAutoscaler: assicurati che i valori di name, kind e apiVersion nel campo scaleTargetRef corrispondano esattamente ai metadati corrispondenti del tuo workload di destinazione. Se il nome del workload non è corretto, aggiorna il campo scaleTargetRef di HorizontalPodAutoscaler in modo che punti al nome corretto.
  2. Verifica che il workload esista: verifica che il workload di destinazione esista nello stesso spazio dei nomi di HorizontalPodAutoscaler. Puoi verificarlo con un comando come kubectl get deployment DEPLOYMENT_NAME. Se hai eliminato intenzionalmente il workload, elimina l'oggetto HorizontalPodAutoscaler corrispondente per pulire il cluster. Se devi ricreare il workload, HorizontalPodAutoscaler lo trova automaticamente dopo che è disponibile e l'errore viene risolto.
  3. Verifica che HorizontalPodAutoscaler e il workload si trovino nello stesso spazio dei nomi: HorizontalPodAutoscaler e il relativo workload di destinazione devono trovarsi nello stesso spazio dei nomi. Se dimentichi di specificare uno spazio dei nomi quando crei un oggetto con i comandi kubectl, Kubernetes inserisce l'oggetto nello spazio dei nomi default. Questo comportamento può causare una mancata corrispondenza se l'oggetto HorizontalPodAutoscaler si trova nello spazio dei nomi default e il workload si trova in un altro spazio dei nomi o viceversa. Controlla lo spazio dei nomi per entrambi gli oggetti e verifica che corrispondano.

Dopo che HorizontalPodAutoscaler individua correttamente il target, la condizione AbleToScale diventa True e il messaggio cambia in: the HorizontalPodAutoscaler controller was able to get the target's current scale.

Metriche non valide

Sintomi

Se HorizontalPodAutoscaler non riesce a calcolare le repliche richieste a causa di un problema di configurazione, la sezione Events mostra il motivo FailedComputeMetricsReplicas con un messaggio simile al seguente:

invalid metrics (1 invalid out of 1)

Causa

Questo errore di solito indica una mancata corrispondenza tra la metrica type e il valore target definito nel manifest HorizontalPodAutoscaler. Ad esempio, potresti aver specificato un type di Utilization, ma aver fornito un valore target di averageValue anziché averageUtilization.

Risoluzione

Correggi il manifest di HorizontalPodAutoscaler in modo che il valore del campo target sia allineato alla metrica type:

  • Se type è Utilization, il valore nel campo target deve essere averageUtilization.
  • Se type è AverageValue, il valore nel campo target deve essere averageValue.

Etichetta della metrica non consentita

Sintomi

Viene visualizzato il seguente errore:

unable to fetch metrics from external metrics API: googleapi: Error 400: Metric label: 'LABEL_NAME' is not allowed

In questo output, LABEL_NAME è il nome dell'etichetta non corretta.

Causa

Il manifest HorizontalPodAutoscaler specifica una chiave di etichetta non valida nella sezione metric.selector.matchLabels e Cloud Monitoring non riconosce o non consente questa chiave per la metrica.

Risoluzione

Per risolvere il problema, segui questi passaggi:

  1. Identifica il nome dell'etichetta non consentita dal messaggio di errore.
  2. Rimuovi o correggi questa chiave di etichetta nella sezione metric.selector.matchLabels del manifest HorizontalPodAutoscaler.
  3. Trova una chiave di etichetta valida e filtrabile consultando la documentazione di Cloud Monitoring per quella metrica.

Più HorizontalPodAutoscaler hanno come target lo stesso workload

Sintomi

Non esiste un Condition o un Reason specifico nello stato di HorizontalPodAutoscaler che indichi direttamente questo conflitto. Potresti invece osservare i seguenti sintomi:

  • Il numero di repliche del workload può variare in modo imprevisto.
  • Le decisioni di scalabilità potrebbero non sembrare corrispondenti alle metriche definite in un singolo HorizontalPodAutoscaler.
  • Quando visualizzi gli eventi, potresti vedere eventi SuccessfulRescale alternati o contraddittori provenienti da diversi oggetti HorizontalPodAutoscaler.

Causa

Questo problema si verifica perché più di un oggetto HorizontalPodAutoscaler all'interno dello stesso spazio dei nomi specifica esattamente lo stesso carico di lavoro nel campo spec.scaleTargetRef. Ogni HorizontalPodAutoscaler calcola in modo indipendente i conteggi delle repliche e tenta di scalare il workload in base al proprio insieme di metriche e target. Kubernetes non blocca questa configurazione, ma porta ad aggiustamenti di scalabilità irregolari perché gli HorizontalPodAutoscaler competono tra loro.

Risoluzione

Per evitare conflitti, definisci tutte le metriche di scalabilità in un unico oggetto HorizontalPodAutoscaler. Ogni HorizontalPodAutoscaler calcola le esigenze di scalabilità dal proprio campo spec.metrics, quindi l'unione consente all'oggetto HorizontalPodAutoscaler scelto di considerare tutti i fattori, come CPU e richieste al secondo, insieme:

  1. Per identificare gli oggetti HorizontalPodAutoscaler che hanno come target lo stesso workload, recupera il manifest YAML per ogni oggetto HorizontalPodAutoscaler. Presta molta attenzione al campo spec.scaleTargetRef nell'output.

    kubectl get hpa -n NAMESPACE_NAME -o yaml

    Sostituisci NAMESPACE_NAME con lo spazio dei nomi dell'oggetto HorizontalPodAutoscaler.

    Cerca le istanze in cui diverse risorse HorizontalPodAutoscaler hanno gli stessi valori per apiVersion, kind e name nel campo scaleTargetRef.

  2. Consolida le metriche in un unico oggetto HorizontalPodAutoscaler:

    1. Scegli un oggetto HorizontalPodAutoscaler da conservare. Questo HorizontalPodAutoscaler sarà quello che modificherai.
    2. Esamina la sezione spec.metrics nel manifest di ciascuno degli altri oggetti HorizontalPodAutoscaler che hanno come target lo stesso workload.
    3. Copia le definizioni delle metriche che vuoi conservare dalle sezioni spec.metrics degli oggetti HorizontalPodAutoscaler duplicati.
    4. Incolla queste definizioni di metriche copiate nell'array spec.metrics di HorizontalPodAutoscaler che hai deciso di conservare.

  3. Applica le modifiche:

    kubectl apply -f MANIFEST_NAME

    Sostituisci MANIFEST_NAME con il nome del manifest HorizontalPodAutoscaler che hai deciso di conservare.

  4. Elimina gli altri oggetti HorizontalPodAutoscaler che avevano come target lo stesso carico di lavoro:

    kubectl delete hpa DUPLICATE_MANIFEST_NAME -n NAMESPACE_NAME

    Sostituisci DUPLICATE_MANIFEST_NAME con il nome dell'oggetto HorizontalPodAutoscaler ridondante che vuoi eliminare.

Risolvi i problemi relativi agli errori di workload e servizio

Le sezioni seguenti trattano gli errori causati dal carico di lavoro di destinazione o dai relativi servizi associati, anziché dall'oggetto HorizontalPodAutoscaler stesso.

Richieste di risorse mancanti per il calcolo dello scaling

Sintomi

La condizione ScalingActive è False con un Reason di FailedGetResourceMetric. In genere viene visualizzato anche un messaggio simile al seguente:

the HorizontalPodAutoscaler was unable to compute the replica count

Causa

HorizontalPodAutoscaler deve calcolare l'utilizzo delle risorse come percentuale per scalare il workload, ma non può eseguire questo calcolo perché almeno un container all'interno della specifica del pod non ha una definizione resources.requests per la risorsa corrispondente (cpu o memory).

Risoluzione

Per risolvere il problema, aggiorna il manifest del pod all'interno del deployment, di StatefulSet o di un altro controller in modo da includere un campo resources.requests per la risorsa (cpu o memory) su cui HorizontalPodAutoscaler sta tentando di scalare per tutti i container nel pod. Ad esempio:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
# Multiple lines are omitted here
spec:
  containers:
  - name: example-container
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

Impossibile recuperare le metriche dei pod

Sintomi

Viene visualizzato un messaggio persistente simile al seguente:

unable to fetch pod metrics for pod

È normale visualizzare temporaneamente questo messaggio all'avvio del server delle metriche.

Causa

Per scalare in base alla percentuale di utilizzo delle risorse (ad esempio cpu o memory), ogni container all'interno dei pod scelti come target dall'oggetto HorizontalPodAutoscaler deve avere il campo resources.requests definito per quella risorsa specifica. In caso contrario, HorizontalPodAutoscaler non può eseguire i calcoli necessari e non esegue alcuna azione correlata a questa metrica.

Risoluzione

Se questi messaggi di errore persistono e noti che i pod non vengono scalati per il tuo workload, verifica di aver specificato le richieste di risorse per ogni container nel tuo workload.

Più servizi selezionano la stessa destinazione

Sintomi

Viene visualizzato il seguente errore:

multiple services selecting the same target of HPA_NAME: SERVICE_NAME

Questo output include i seguenti valori:

  • HPA_NAME: il nome di HorizontalPodAutoscaler.
  • SERVICE_NAME: il nome di un servizio.

Causa

La scalabilità automatica basata sul traffico è configurata, ma più di un servizio Kubernetes ha come target il campo scaleTargetRef di HorizontalPodAutoscaler. La scalabilità automatica basata sul traffico supporta solo una relazione uno a uno tra il servizio e il workload sottoposto a scalabilità automatica.

Risoluzione

Per risolvere il problema, assicurati che solo il selettore etichetta di un servizio corrisponda ai pod del tuo workload:

  1. Trova le etichette dei pod del tuo workload:

    kubectl get deployment HPA_TARGET_DEPLOYMENT \
    -n NAMESPACE \
    -o jsonpath='{.spec.template.metadata.labels}'

    Sostituisci quanto segue:

    • HPA_TARGET_DEPLOYMENT: il nome del deployment scelto come target da HorizontalPodAutoscaler.
    • NAMESPACE: lo spazio dei nomi del deployment.

    L'output è simile al seguente:

    {"app":"my-app", "env":"prod"}

  2. Trova tutti i servizi che corrispondono a queste etichette esaminando il campo spec.selector per tutti i servizi nello spazio dei nomi.

    kubectl get services -n NAMESPACE -o yaml

    Identifica ogni servizio il cui selettore corrisponde alle etichette del passaggio precedente. Ad esempio, sia {"app": "my-app"} sia {"app": "my-app", "env": "prod"} corrispondono alle etichette dei pod di esempio.

  3. Risolvi il conflitto scegliendo una delle seguenti opzioni:

    • Rendi univoco il selettore del servizio previsto aggiungendo una nuova etichetta univoca al campo spec.template.metadata.labels del tuo deployment. Poi, aggiorna il campo spec.selector del singolo servizio previsto in modo da includere questa nuova etichetta.
    • Rendi più restrittivi gli altri selettori di servizio modificando il campo spec.selector di tutti gli altri servizi in conflitto in modo che siano più restrittivi e non corrispondano più ai pod del tuo carico di lavoro.

  4. Applica le modifiche:

    kubectl apply -f MANIFEST_NAME

    Sostituisci MANIFEST_NAME con il nome del file YAML contenente il manifest aggiornato del servizio o del deployment.

Risolvi i problemi relativi all'API Metrics e alla disponibilità dei dati

Le sezioni seguenti ti aiutano a risolvere gli errori che si verificano quando HorizontalPodAutoscaler tenta di comunicare con un'API Metrics o di eseguire query su un backend delle metriche.

Risolvi i problemi relativi alle metriche personalizzate ed esterne

Quando HorizontalPodAutoscaler si basa su metriche provenienti da fonti diverse da CPU o memoria predefinite, possono verificarsi problemi nella pipeline delle metriche personalizzate o esterne. Questa pipeline è costituita dal controller HorizontalPodAutoscaler, dal server API delle metriche di Kubernetes, dall'adattatore delle metriche e dall'origine delle metriche (ad esempio Cloud Monitoring o Prometheus), come mostrato nel seguente diagramma:

Pipeline delle metriche HPA che mostra i componenti: controller HPA, server API Kubernetes, adattatore delle metriche e origine delle metriche.

Sintomi

I sintomi più comuni di un problema nella pipeline delle metriche sono i seguenti:

  • Il valore della metrica viene visualizzato come <unknown>.
  • Gli eventi HorizontalPodAutoscaler mostrano errori come FailedGetExternalMetric o FailedGetCustomMetric.

Causa

Esiste un problema nella pipeline delle metriche personalizzate o esterne.

Risoluzione

Per eseguire il debug della pipeline:

  1. Verifica se l'adattatore delle metriche è registrato e disponibile: l'adattatore delle metriche deve registrarsi presso il server API Kubernetes principale per fornire le metriche. Questa azione è il modo più diretto per verificare se l'adattatore è in esecuzione e raggiungibile dal server API:

    kubectl get apiservice | grep -E 'NAME|metrics.k8s.io'

    Nell'output dovresti vedere le voci v1beta1.custom.metrics.k8s.io o v1beta1.external.metrics.k8s.io e un valore di True nella colonna Available. Ad esempio:

    NAME                   SERVICE                      AVAILABLE   AGE
v1beta1.metrics.k8s.io kube-system/metrics-server   True        18d

    • Se il valore nella colonna Available è False o mancante, è probabile che l'adattatore si sia arrestato in modo anomalo o sia configurato in modo errato. Controlla i log del pod dell'adattatore nello spazio dei nomi kube-system o custom-metrics per errori relativi a autorizzazioni, connettività di rete all'origine metrica o messaggi che indicano che la metrica non è stata trovata.

    • Se il valore è True, vai al passaggio successivo.

  2. Interroga direttamente l'API Metrics: se l'adattatore è disponibile, ignora HorizontalPodAutoscaler e chiedi direttamente all'API Kubernetes la metrica. Questo comando testa l'intera pipeline, dal server API all'adattatore delle metriche fino all'origine dati.

    Per eseguire query sulle metriche esterne, esegui questo comando:

    kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/METRIC_NAME" | jq .

    Per eseguire query sulle metriche dei pod personalizzati, esegui questo comando:

    kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/pods/*/METRIC_NAME" | jq .

    Sostituisci quanto segue:

    • NAMESPACE_NAME: lo spazio dei nomi in cui sono in esecuzione i tuoi pod.
    • METRIC_NAME: il nome della metrica personalizzata o esterna che stai tentando di interrogare. Ad esempio, requests_per_second o queue_depth.

  3. Analizza l'output del comando: il risultato dei comandi precedenti indica dove si trova il problema. Scegli lo scenario che corrisponde al tuo output:

    • Risposta JSON riuscita con un valore: la pipeline delle metriche funziona correttamente. Il problema è probabilmente dovuto a un problema di configurazione nel manifest HorizontalPodAutoscaler. Controlla la presenza di errori ortografici nel nome della metrica o di matchLabels errati.

    • Error: Error from server (Service Unavailable): questo errore in genere indica un problema di connettività di rete, spesso un problema del firewall nei cluster che utilizzano l'isolamento di rete.

      1. Identifica il servizio dell'adattatore delle metriche. Di solito si trova nello spazio dei nomi custom-metrics o kube-system:

        kubectl get service -n custom-metrics,kube-system | grep -E 'adapter|metrics'

      2. Trova la porta su cui è in ascolto l'adattatore:

        kubectl get service ADAPTER_SERVICE -n ADAPTER_NAMESPACE -o yaml

        Sostituisci quanto segue:

        • ADAPTER_SERVICE: il nome del servizio Kubernetes associato all'adattatore delle metriche che hai eseguito il deployment. Questo servizio è quello che hai trovato nel passaggio precedente. Questo servizio espone la funzionalità dell'adattatore ad altre parti del cluster, incluso il server API Kubernetes.
        • ADAPTER_NAMESPACE: lo spazio dei nomi in cui si trova il servizio dell'adattatore (ad esempio, custom-metrics o kube-system).

      3. Trova le regole firewall in entrata per il control plane del cluster:

        gcloud compute firewall-rules list \
    --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master"

        Sostituisci CLUSTER_NAME con il nome del tuo cluster.

      4. Aggiungi targetPort dell'adattatore alla regola:

        1. Descrivi la regola attuale per visualizzare le porte consentite esistenti:

          gcloud compute firewall-rules describe FIREWALL_RULE_NAME

          Sostituisci FIREWALL_RULE_NAME con il nome della regola firewall che regola il traffico di rete verso il control plane del tuo cluster Kubernetes.

        2. Aggiorna la regola per aggiungere la porta dell'adattatore all'elenco:

          gcloud compute firewall-rules update FIREWALL_RULE_NAME \
    --allow tcp:443,tcp:10250,tcp:ADAPTER_PORT

          Sostituisci ADAPTER_PORT con la porta di rete su cui è in ascolto l'adattatore delle metriche.

      5. Assicurati che le policy di rete di Kubernetes non blocchino il traffico verso i pod dell'adattatore delle metriche:

        kubectl get networkpolicy -n custom-metrics,kube-system

        Esamina le policy per verificare che consentano il traffico in entrata dal control plane o dal server API a ADAPTER_SERVICE su ADAPTER_PORT.

    • Un elenco vuoto []: questo output indica che l'adattatore è in esecuzione, ma non riesce a recuperare la metrica specifica, il che indica un problema con la configurazione dell'adattatore o con l'origine della metrica stessa.

      • Problemi relativi ai pod dell'adattatore: controlla i log del pod o dei pod dell'adattatore di metriche per individuare errori relativi alle chiamate API, all'autenticazione o al recupero delle metriche. Per esaminare i log:

        1. Trova il nome del pod dell'adattatore:

          kubectl get pods -n ADAPTER_NAMESPACE

        2. Visualizza i relativi log:

          kubectl logs ADAPTER_POD_NAME \
    -n ADAPTER_NAMESPACE

          Sostituisci quanto segue:

          • ADAPTER_POD_NAME: il nome del pod dell'adattatore che hai identificato nel passaggio precedente.
          • ADAPTER_NAMESPACE: lo spazio dei nomi in cui si trova il pod dell'adattatore (ad esempio, custom-metrics o kube-system).

      • Nessun dato nell'origine: la metrica potrebbe non esistere nel sistema di origine. Utilizza uno strumento di monitoraggio, come Metrics Explorer, per verificare che la metrica esista e abbia il nome e le etichette corretti.

Versioni della metrica non trovate o adattatore non disponibile

Sintomi

Viene visualizzato il seguente errore:

unable to fetch metrics from custom metrics API: no known available metric versions found

Causa

Questo errore indica un'interruzione della comunicazione all'interno del cluster, non un problema con l'origine delle metriche (ad esempio Cloud Monitoring). Di seguito sono elencate alcune delle possibili cause:

  • Il server API Kubernetes è temporaneamente non disponibile (ad esempio, durante un upgrade del cluster o una riparazione del control plane).
  • I pod dell'adattatore delle metriche (ad esempio custom-metrics-stackdriver-adapter) non sono integri, non sono in esecuzione o non sono registrati correttamente con il server API.

Risoluzione

Questo problema è spesso temporaneo. Se il problema persiste, prova le seguenti soluzioni:

  1. Controlla lo stato del control plane Kubernetes:

    1. Nella console Google Cloud , visualizza l'integrità e lo stato del cluster.

      1. Vai alla pagina Cluster Kubernetes.

        Vai a Cluster Kubernetes

    2. Controlla le colonne Stato e Notifiche del tuo cluster.

    3. Fai clic su Notifiche per cercare operazioni in corso come upgrade o riparazioni. Il server API potrebbe non essere disponibile per un breve periodo durante questi orari.

    4. Esamina Cloud Audit Logs per verificare la presenza di errori relativi ai componenti del control plane. Per informazioni su come visualizzare questi log, consulta Informazioni sui log di controllo di GKE.

  2. Controlla lo stato e i log dei pod dell'adattatore delle metriche: assicurati che i pod dell'adattatore delle metriche siano nello stato Running e non abbiano riavvii recenti:

    kubectl get pods -n custom-metrics,kube-system -o wide

    Se lo stato di un pod è diverso da Running o se ha un numero elevato di riavvii, esamina il pod per trovare la causa principale. Per suggerimenti per la risoluzione dei problemi, vedi Debug dei pod nella documentazione di Kubernetes.

  3. Verifica che le API Metrics siano registrate e disponibili:

    kubectl get apiservice | grep metrics.k8s.io

    Se le API Metrics sono integre, l'output è simile al seguente:

    NAME                            SERVICE                                             AVAILABLE   AGE
v1beta1.custom.metrics.k8s.io   custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.external.metrics.k8s.io custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.metrics.k8s.io          kube-system/metrics-server                          True        18d

    Se la colonna AVAILABLE ha un valore False, la colonna Message nel manifest APIService completo potrebbe fornire ulteriori dettagli.

    Puoi visualizzare il manifest completo con il seguente comando:

    kubectl get apiservice API_SERVICE_NAME -o yaml

    Sostituisci API_SERVICE_NAME con il nome dell'oggetto APIService, ad esempio v1beta1.custom.metrics.k8s.io.

La query della metrica non restituisce serie temporali

Sintomi

Viene visualizzato il seguente errore:

unable to fetch metrics from custom or external metrics API: googleapi: Error
400: The supplied filter [...] query will not return any time series

Causa

La query inviata a Cloud Monitoring era valida, ma non ha restituito dati. Ciò significa che non esistono punti dati che corrispondono al filtro (che è diverso dalla ricerca di una metrica con un valore pari a 0). Il motivo più probabile di questo problema è che l'applicazione o il workload responsabile della generazione della metrica personalizzata non scriveva dati in Cloud Monitoring durante il periodo in cui sono stati segnalati gli errori.

Risoluzione

Prova le seguenti soluzioni:

  1. Verifica della configurazione: assicurati che i nomi e le etichette delle metriche nell'oggetto HorizontalPodAutoscaler corrispondano esattamente a quelli emessi dall'applicazione.
  2. Controlla le autorizzazioni: verifica che l'applicazione sia configurata correttamente con le autorizzazioni e gli endpoint API necessari per pubblicare le metriche in Cloud Monitoring.
  3. Conferma l'attività dell'applicazione: verifica che l'applicazione responsabile della metrica fosse operativa e tentasse di inviare dati a Cloud Monitoring durante il periodo di tempo in cui si sono verificati gli avvisi di HorizontalPodAutoscaler.
  4. Verifica la presenza di errori: controlla i log dell'applicazione nello stesso periodo di tempo per verificare la presenza di errori espliciti relativi all'emissione di metriche, ad esempio errori di connessione, credenziali non valide o problemi di formattazione.

Risolvi i problemi relativi a comportamenti di scalabilità integri, ma imprevisti

Le sezioni seguenti descrivono gli scenari in cui la configurazione di HorizontalPodAutoscaler è valida e le metriche sono disponibili, ma le azioni di scalabilità non si verificano come previsto.

HorizontalPodAutoscaler è integro, ma non esegue lo scale

Sintomi

HorizontalPodAutoscaler sembra integro, le sue condizioni riportano True e non mostra errori nei suoi eventi. Tuttavia, non esegue ancora alcuna azione di scalabilità.

Causa

Diversi fattori possono causare questo comportamento previsto:

  • Limiti di replica: il numero attuale di repliche si trova già al limite impostato dal campo minReplicas o maxReplicas nella configurazione HorizontalPodAutoscaler.
  • Finestra di tolleranza: Kubernetes utilizza una finestra di tolleranza predefinita del 10% per impedire lo scaling in caso di piccole fluttuazioni delle metriche. Lo scaling si verifica solo se il rapporto tra la metrica attuale e la metrica target non rientra nell'intervallo compreso tra 0,9 e 1,1. Ad esempio, se il target è l'85% di CPU e l'utilizzo attuale è del 93%, il rapporto è circa 1,094 (93/85≈1,094). Poiché questo valore è inferiore a 1,1, HorizontalPodAutoscaler non esegue lo scale up.
  • Pod non pronti: HorizontalPodAutoscaler include solo i pod con stato Ready nei calcoli di scalabilità. I pod bloccati con uno stato Pending o che non diventano Ready (a causa di controlli di integrità non riusciti o problemi di risorse) vengono ignorati e possono impedire lo scaling.
  • Ritardo del periodo di sincronizzazione: il controller HorizontalPodAutoscaler controlla le metriche periodicamente. Un ritardo di 15-30 secondi tra il superamento della soglia da parte di una metrica e l'avvio di un'azione di scalabilità è normale.
  • Nuova latenza metrica: quando un HorizontalPodAutoscaler utilizza una nuova metrica personalizzata per la prima volta, potresti notare una latenza una tantum di diversi minuti. Questo ritardo si verifica perché il sistema di monitoraggio (ad esempio Cloud Monitoring) deve creare la nuova serie temporale quando viene scritto il primo punto dati.
  • Calcolo di più metriche: quando configuri più metriche, HorizontalPodAutoscaler calcola il numero di repliche richiesto per ogni metrica in modo indipendente e poi sceglie il valore calcolato più alto come numero finale di repliche. A causa di questo comportamento, il tuo workload viene scalato per soddisfare le esigenze della metrica con i requisiti più elevati. Ad esempio, se le metriche della CPU calcolano la necessità di 9 repliche, ma una metrica delle richieste al secondo calcola la necessità di 15, HorizontalPodAutoscaler scala il deployment a 15 repliche.

Risoluzione

Prova le seguenti soluzioni:

  • Limiti delle repliche: controlla i valori minReplicas e maxReplicas nel manifest HorizontalPodAutoscaler o nell'output del comando kubectl describe. Modifica questi limiti se impediscono la scalabilità necessaria.
  • Finestra di tolleranza: se è richiesta la scalabilità all'interno della tolleranza predefinita, configura un valore di tolleranza diverso. In caso contrario, attendi che la metrica esca dall'intervallo compreso tra 0,9 e 1,1.
  • Pod non pronti: indaga sul motivo per cui i pod sono Pending o non Ready e risolvi i problemi di fondo (ad esempio, vincoli delle risorse, probe di idoneità non riusciti). Per suggerimenti sulla risoluzione dei problemi, consulta Debug dei pod nella documentazione di Kubernetes.
  • Ritardo del periodo di sincronizzazione e latenza della nuova metrica: queste latenze sono normali. Attendi il completamento del periodo di sincronizzazione o la creazione della nuova serie temporale della metrica personalizzata.
  • Calcolo di più metriche: questo è il comportamento previsto. Se lo scale up si verifica in base a una metrica (ad esempio le richieste al secondo), esegue l'override corretto del calcolo inferiore di un'altra metrica (ad esempio la CPU).

HorizontalPodAutoscaler non riesce a eseguire fare lo scale down

Sintomi

HorizontalPodAutoscaler esegue lo scale up del workload, ma non riesce a eseguire lo scale down anche quando le metriche come l'utilizzo della CPU sono basse.

Causa

Questo comportamento è progettato per impedire lo scale up e lo scale down rapidi o lo scale down in base a informazioni incomplete. I motivi principali sono i seguenti:

  • Utilizzo di più metriche: HorizontalPodAutoscaler scala in base alla metrica che richiede il maggior numero di repliche. Se hai più metriche, il carico di lavoro non farà fare lo scale down a meno che tutte le metriche non indichino che sono necessarie meno repliche. Una metrica che richiede un numero elevato di repliche impedisce di fare lo scale down, anche se le altre sono basse.
  • Metriche non disponibili: se una metrica non è disponibile (spesso viene visualizzata come <unknown>), HorizontalPodAutoscaler rifiuta in modo conservativo di fare lo scale down del workload. Non è in grado di determinare se la metrica non è presente perché l'utilizzo è effettivamente pari a zero o perché la pipeline delle metriche non funziona. Questo problema è comune con le metriche personalizzate basate sulla frequenza (ad esempio messages_per_second), che possono interrompere la generazione di report sui dati quando non è presente alcuna attività, facendo sì che HorizontalPodAutoscaler consideri la metrica come non disponibile e interrompa le operazioni di scale down.
  • Ritardo di scale down dalla policy di scalabilità: il campo behavior di HorizontalPodAutoscaler consente di configurare le policy di scalabilità. La policy predefinita per fare lo scale down include una finestra di stabilizzazione di 300 secondi (cinque minuti). Durante questa finestra, HorizontalPodAutoscaler non ridurrà il numero di repliche, anche quando i valori delle metriche sono scesi al di sotto della soglia target. Questa finestra impedisce fluttuazioni rapide, ma può rendere la riduzione delle risorse più lenta del previsto.

Risoluzione

Prova le seguenti soluzioni:

  1. Per più metriche e metriche non disponibili, diagnostica la metrica che causa problemi:

    kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

    Nell'output, cerca nella sezione Metrics eventuali metriche con stato <unknown> e nella sezione Events avvisi come FailedGetCustomMetric o FailedGetExternalMetric. Per il debug dettagliato della pipeline, consulta la sezione Risolvere i problemi relativi alle metriche personalizzate ed esterne.

  2. Per le metriche non disponibili, se una metrica non è disponibile durante i periodi di traffico ridotto (comune con le metriche basate sulla frequenza), prova una delle seguenti soluzioni:

    • Se possibile, utilizza metriche basate su indicatori anziché su frequenze. Una metrica di tipo indicatore, ad esempio il numero totale di messaggi in una coda (ad esempio, subscription o num_undelivered_messages), segnala in modo coerente un valore, anche se questo è 0, consentendo a HorizontalPodAutoscaler di prendere decisioni di scalabilità in modo affidabile.
    • Assicurati che l'origine della metrica restituisca valori pari a zero. Se controlli la metrica personalizzata, configurala in modo che pubblichi un 0 durante i periodi di inattività anziché non inviare alcun dato.

  3. Per i ritardi di scale down della policy di scalabilità, se il periodo di stabilizzazione predefinito di cinque minuti per lo scale down è troppo lungo, personalizzalo. Analizza la sezione spec.behavior.scaleDown del manifest HorizontalPodAutoscaler. Puoi abbassare il valore di stabilizationWindowSeconds per consentire al gestore della scalabilità automatica di fare lo scale down più rapidamente dopo la diminuzione delle metriche. Per ulteriori informazioni sulla configurazione di queste policy, consulta Policy di scalabilità nella documentazione di Kubernetes.

Risolvi i problemi di scalabilità dei workload GKE da e verso zero utilizzando HPA

Questa sezione ti aiuta a diagnosticare i problemi durante la configurazione dei workload per scalare da e verso zero utilizzando HPA (minReplicas: 0) in GKE 1.37 o versioni successive.

Il workload non viene scalato a zero

Se il tuo workload rimane a una o più repliche quando la domanda scende a zero, controlla quanto segue:

  1. Controlla minReplicas: assicurati che la coppia campo-valore minReplicas: 0 sia impostata nel manifest HorizontalPodAutoscaler.
  2. Controlla i tipi di metriche: l'HPA non può scalare a zero se utilizza solo metriche relative alla CPU o alla memoria (Resource). Devi configurare almeno una metrica External o Object.
  3. Controlla più metriche: HPA esegue lo scale in base alla metrica che richiede il conteggio di repliche più elevato. Se configuri più metriche, il workload non viene scalato a zero a meno che ogni metrica monitorata non restituisca zero.
  4. Attendi la finestra di stabilizzazione della riduzione delle risorse: per impostazione predefinita, GKE attende cinque minuti (scaleDown.stabilizationWindowSeconds: 300) di domanda continua pari a zero prima di scalare da una a zero repliche.
  5. Controlla le metriche non disponibili: se il valore di una metrica viene visualizzato come <unknown>, HPA mette in pausa le operazioni di fare lo scale down per evitare una riduzione prematura. Per saperne di più, consulta Risolvi i problemi relativi alla mancata riduzione della scalabilità automatica orizzontale dei pod.

Il workload non viene scalato da zero

Se il tuo workload rimane a zero repliche quando la domanda aumenta, controlla quanto segue:

  1. Ispeziona HorizontalPodAutoscaler: esegui il comando kubectl describe hpa HPA_NAME e controlla le seguenti sezioni nell'output:

    • Sezione Metriche: verifica che il valore della metrica sia maggiore di zero e non venga visualizzato come <unknown>. Se la metrica non è presente o non viene aggiornata, verifica che l'origine esterna (ad esempio Pub/Sub) stia pubblicando eventi e che Cloud Monitoring li stia ricevendo.
    • Sezione Condizioni:
      • Stato integro con zero repliche: verifica che le condizioni mostrino AbleToScale: True, ScalingActive: True e ScaledToZero: True (con motivo ScaledToZero). In questo stato, GKE scala automaticamente il workload quando la domanda aumenta.
      • Override esterno rilevato: verifica se il valore della condizione ScalingActive è False con il motivo ScalingDisabledExternalScaleToZero o ScalingDisabledReplicaCountZero, il che indica che il workload è stato scalato manualmente a zero. Ad esempio, il workload è stato scalato manualmente con il comando kubectl scale, che mette in pausa la scalabilità automatica per evitare modifiche in conflitto.

    • Risoluzione: per riprendere la scalabilità automatica, ridimensiona manualmente il deployment a una o più repliche:

      kubectl scale deployment DEPLOYMENT_NAME --replicas=1

  2. Verifica la latenza di avvio a freddo: se il workload si avvia lentamente, il provisioning dei nodi potrebbe aggiungere ritardi. Per assicurarti che la capacità di calcolo di standby sia pronta durante lo scale da zero, valuta la possibilità di utilizzare i buffer di capacità.

Passaggi successivi