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 scalare 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 questa pagina 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. Se segui questi passaggi per la risoluzione dei problemi, puoi contribuire a garantire che le tue applicazioni vengano scalate in modo efficiente e affidabile in base alla domanda, utilizzando in modo efficace la risorsa di Horizontal Pod Autoscaler.

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 maggiori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE.

Se hai già riscontrato sintomi o visualizzato un messaggio di errore, utilizza la tabella seguente per trovare le indicazioni giuste:

Sintomo Possibile risoluzione
Nessuna scalabilità, ma le condizioni di HorizontalPodAutoscaler sono True Risolvere i problemi relativi a un HorizontalPodAutoscaler integro ma che non risponde
Visualizzi un messaggio di errore specifico negli eventi HorizontalPodAutoscaler Risolvi gli errori comuni di Horizontal Pod Autoscaler
Metrica <unknown> Risolvere i problemi relativi alle metriche personalizzate ed esterne
Non viene eseguito lo scale down Risolvere i problemi relativi al mancato scale down di Horizontal Pod Autoscaler

Prima di iniziare

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

  • Per ottenere le autorizzazioni necessarie per risolvere i problemi di 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 ulteriori informazioni 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 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 .

Verifica lo stato e la configurazione di Horizontal Pod Autoscaler

Inizia la risoluzione dei problemi esaminando lo stato e la configurazione dell'oggetto HorizontalPodAutoscaler. Questo controllo iniziale ti aiuta a identificare e risolvere errori di configurazione di base, che sono una causa principale comune dei problemi di scalabilità.

Descrivi HorizontalPodAutoscaler

Per visualizzare i calcoli in tempo reale e le recenti decisioni di scalabilità di HorizontalPodAutoscaler, utilizza il comando kubectl describe hpa. Questo comando fornisce un riepilogo dell'oggetto HorizontalPodAutoscaler e un log Events utile per diagnosticare i problemi:

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
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: questa sezione mostra i valori attuali delle metriche rispetto ai relativi target. Controlla qui per vedere se HorizontalPodAutoscaler riceve dati. Un valore della metrica <unknown> indica che HorizontalPodAutoscaler non ha recuperato la metrica o che la pipeline delle metriche è interrotta.
  • Conditions: questo controllo di integrità di alto livello mostra se HorizontalPodAutoscaler può recuperare le metriche (AbleToScale) ed eseguire i calcoli di scalabilità (ScalingActive). Lo stato False in una di queste condizioni indica un errore.
  • Events: questa sezione registra le azioni di scalabilità recenti, gli avvisi e gli errori del controller HorizontalPodAutoscaler. Spesso è il primo posto in cui trovare messaggi di errore o motivi specifici, come FailedGetScale o FailedGetResourceMetric, che ti aiutano a scoprire l'origine del problema.

Controlla lo stato di HorizontalPodAutoscaler nei deployment

Per controllare lo stato degli oggetti HorizontalPodAutoscaler utilizzati con i tuoi Deployment, utilizza la console Google Cloud :

  1. Nella console Google Cloud , vai alla pagina Workload.

    Vai a Carichi di lavoro

  2. Fai clic sul nome del deployment.

  3. Vai alla scheda Dettagli e individua la sezione Scalabilità automatica.

  4. Controlla il valore nella riga Stato:

    • Un segno di spunta verde indica che HorizontalPodAutoscaler è configurato e può leggere le sue metriche.
    • Un triangolo giallo indica che HorizontalPodAutoscaler è configurato, ma ha difficoltà a leggere le metriche. Si tratta di un problema comune con le metriche personalizzate o esterne. Per risolvere il problema, diagnostica perché le metriche non sono disponibili. Per maggiori informazioni, consulta la sezione Risoluzione dei problemi relativi a metriche personalizzate ed esterne.

Per altri tipi di carichi di lavoro come StatefulSet o per maggiori dettagli, controlla il manifest dell'oggetto HorizontalPodAutoscaler.

Controlla il manifest di 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 Browser 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, in cui viene visualizzata 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) che HorizontalPodAutoscaler deve scalare.
    • minReplicas e maxReplicas: le impostazioni minime e massime delle repliche.
    • metrics: le metriche che hai configurato per la scalabilità (ad esempio, utilizzo della CPU o metriche personalizzate).
  • status (lo stato live di HorizontalPodAutoscaler):
    • currentMetrics: i valori delle metriche più recenti osservati da HorizontalPodAutoscaler.
    • currentReplicas e desiredReplicas: il numero attuale di pod e il numero a cui HorizontalPodAutoscaler vuole scalare.
    • conditions: la sezione più utile per la risoluzione dei problemi. Questa sezione mostra lo stato 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.

Utilizzare le funzionalità di logging avanzate

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

  • Visualizza gli eventi di scalabilità automatica pod orizzontale in Cloud Logging: utilizza un filtro dei log per trovare tutti gli eventi di Horizontal Pod Autoscaler 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 Horizontal Pod Autoscaler: questi log forniscono log strutturati e leggibili che spiegano come HorizontalPodAutoscaler calcola un consiglio, offrendo informazioni dettagliate sul suo processo decisionale.

Risolvere i problemi relativi a un HorizontalPodAutoscaler integro ma che non risponde

Questa sezione ti aiuta a diagnosticare il motivo per cui HorizontalPodAutoscaler potrebbe non attivare alcuna azione di scalabilità, anche quando sembra integro e non segnala errori nel suo stato o nei suoi eventi.

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 ha già raggiunto il 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% della CPU e l'utilizzo attuale è del 93%, il rapporto è circa 1,094 (93/85≈1,094). Poiché questo valore è inferiore a 1,1, la scalabilità Horizontal Pod Autoscaler non viene eseguita.
  • Pod non pronti: Horizontal Pod Autoscaler include solo i pod con stato Ready nei suoi calcoli di scalabilità. I pod bloccati con lo 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.
  • Latenza della nuova 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, Horizontal Pod Autoscaler 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 di richieste al secondo calcola la necessità di 15, Horizontal Pod Autoscaler esegue lo scaling del 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 lo scaling necessario.
  • Finestra di tolleranza: se è necessario lo scaling all'interno della tolleranza predefinita, configura un valore di tolleranza diverso. In caso contrario, attendi che la metrica esca dal rapporto compreso tra 0,9 e 1,1.
  • Pod non pronti: analizza perché i pod sono Pending o non Ready e risolvi i problemi sottostanti (ad esempio, vincoli delle risorse, probe di readiness non riusciti). Per suggerimenti per la risoluzione dei problemi, consulta Debug Pods 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 correttamente l'override del calcolo inferiore di un'altra metrica (ad esempio la CPU).

Risolvere i problemi comuni di Horizontal Pod Autoscaler

Le sezioni seguenti forniscono soluzioni per messaggi di errore specifici e motivi dell'evento che potresti riscontrare quando esamini lo stato di HorizontalPodAutoscaler. In genere, questi messaggi si trovano nella sezione Events dell'output del comando kubectl describe hpa.

Risolvere gli errori di configurazione di Horizontal Pod Autoscaler

Una configurazione errata nel manifest HorizontalPodAutoscaler, ad esempio un campo digitato in modo errato o configurazioni in conflitto, causa gli errori in questa sezione.

Errore: metriche non valide

Potresti visualizzare questo errore quando la configurazione di una metrica all'interno di un HorizontalPodAutoscaler non è sintatticamente corretta o è incoerente.

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 target che hai 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.

Errore: più servizi selezionano la stessa destinazione

Potresti visualizzare questo errore quando utilizzi la scalabilità automatica basata sul traffico che ha una configurazione del servizio errata per HorizontalPodAutoscaler.

Sintomi:

Visualizzi 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 carico di lavoro sottoposto a scalabilità automatica.

Risoluzione:

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

  1. Trova le etichette dei pod del carico di lavoro:

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

    Sostituisci quanto segue:

    • HPA_TARGET_DEPLOYMENT: il nome del deployment a cui è destinato 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"} che {"app": "my-app", "env": "prod"} corrisponderebbero 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 deployment. Poi, aggiorna il campo spec.selector del servizio previsto per includere questa nuova etichetta.
    • Rendi più restrittivi gli altri selettori di servizi 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 workload.

  4. Applica le modifiche:

    kubectl apply -f MANIFEST_NAME

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

Errore: l'etichetta non è consentita

Sintomi:

Visualizzi 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 errata.

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 consentito dal messaggio di errore.
  2. Rimuovi o correggi questa chiave dell'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.

Problema: più HorizontalPodAutoscaler che hanno come target lo stesso carico di lavoro

La configurazione di più oggetti HorizontalPodAutoscaler per gestire lo stesso carico di lavoro causa un comportamento di scalabilità in conflitto e imprevedibile.

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 conteggio delle repliche del workload può variare in modo imprevisto.
  • Le decisioni di scalabilità potrebbero non corrispondere alle metriche definite in un singolo HorizontalPodAutoscaler.
  • Quando visualizzi gli eventi, potresti vedere eventi SuccessfulRescale alternati o contraddittori 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 workload 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 comporta aggiustamenti di scalabilità irregolari perché gli HorizontalPodAutoscaler sono in competizione 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 quali HorizontalPodAutoscaler hanno come target lo stesso carico di lavoro, 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 all'interno del 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 dell'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.

Risolvere i problemi relativi al workload e al target

Gli errori in questa sezione sono causati dallo scaling di Deployment, StatefulSet o Pod, non dall'oggetto HorizontalPodAutoscaler stesso.

Errore: impossibile ottenere la scala attuale della destinazione

Potresti visualizzare questo errore quando HorizontalPodAutoscaler non riesce a trovare o accedere al workload che dovrebbe scalare.

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 un StatefulSet) che è configurato per gestire. Questo problema è causato da un problema nel campo scaleTargetRef all'interno del manifest di HorizontalPodAutoscaler. La risorsa specificata potrebbe non esistere, potrebbe essere stata eliminata o potrebbe contenere un errore ortografico.

Risoluzione:

Prova le seguenti soluzioni:

  1. Verifica il campo scaleTargetRef del manifest di HorizontalPodAutoscaler: assicurati che il valore di name, kind e apiVersion nel campo scaleTargetRef corrisponda esattamente ai metadati corrispondenti del tuo carico di lavoro di destinazione. Se il nome del carico di lavoro non è corretto, aggiorna il campo scaleTargetRef di HorizontalPodAutoscaler in modo che punti al nome corretto.
  2. Verifica che il workload esista: assicurati 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 carico di lavoro, elimina l'oggetto HorizontalPodAutoscaler corrispondente per pulire il cluster. Se devi ricreare il carico di lavoro, 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 HorizontalPodAutoscaler si trova nello spazio dei nomi default mentre il workload si trova in un altro spazio dei nomi o viceversa. Controlla lo spazio dei nomi di entrambi gli oggetti e assicurati che corrispondano.

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

Errore: impossibile calcolare il conteggio delle repliche

Potresti visualizzare questo errore quando HorizontalPodAutoscaler deve calcolare lo scaling in base all'utilizzo delle risorse, ma non dispone delle informazioni di base necessarie dai pod.

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:

Horizontal Pod Autoscaler 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, 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
spec:
  containers:
  - name: example-container
...
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

Errore: impossibile recuperare le metriche del pod per il pod

Potresti visualizzare questo errore quando si verifica un problema durante il recupero delle metriche necessarie per consentire a HorizontalPodAutoscaler di prendere decisioni di scalabilità. Spesso è correlato alle definizioni delle risorse 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 di destinazione dell'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, assicurati di aver specificato le richieste di risorse per ogni container nel tuo workload.

Risolvi i problemi relativi all'API Metrics e agli errori di disponibilità dei dati

Le seguenti sezioni ti aiutano a risolvere gli errori che si verificano quando HorizontalPodAutoscaler tenta di recuperare i dati da un'API di metriche. Questi problemi possono variare da errori di comunicazione del cluster interno, in cui l'API Metrics non è disponibile, a query non valide rifiutate dal fornitore di metriche (spesso visualizzate come errori HTTP di livello 400).

Errore: nessuna versione della metrica disponibile trovata

Sintomi:

Visualizzi 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). Le cause più comuni includono quanto segue:

  • Il server API Kubernetes non è temporaneamente 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 ai cluster Kubernetes

      2. Controlla le colonne Stato e Notifiche per il tuo cluster.

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

    2. Esamina Cloud Audit Logs per eventuali errori relativi ai componenti del control plane. Per informazioni su come visualizzare questi log, vedi 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, consulta Debug Pods nella documentazione di Kubernetes.

  3. Verifica che le API delle metriche siano registrate e disponibili:

    kubectl get apiservice | grep metrics.k8s.io

    Se le API delle metriche 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 il valore False, la colonna Message nel manifest APIService completo potrebbe fornire maggiori 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.

Errore: la query non restituirà alcuna serie temporale

Sintomi:

Visualizzi 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 (il che è diverso dal trovare una metrica con un valore di 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 Horizontal Pod Autoscaler.
  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.

Risolvere 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.

Questa sezione descrive in dettaglio come eseguire il debug di questa pipeline, dall'adattatore delle metriche all'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, segui questi passaggi:

  1. Verifica che l'adattatore delle metriche sia registrato e disponibile: l'adattatore delle metriche deve registrarsi con il server dell'API Kubernetes principale per pubblicare 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 visualizzare 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 non è presente, è probabile che l'adattatore si sia arrestato in modo anomalo o sia configurato in modo errato. Controlla i log dei pod dell'adattatore nello spazio dei nomi kube-system o custom-metrics per errori relativi a permessi, connettività di rete all'origine della 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 la metrica all'API Kubernetes. Questo comando testa l'intera pipeline, dal server API all'adattatore delle metriche 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 personalizzate dei pod, 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 vengono eseguiti i 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 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 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 l'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 i criteri 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 norme per assicurarti che consentano il traffico in entrata dal control plane o dal server API al ADAPTER_SERVICE sul 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 al pod dell'adattatore: esamina i log del pod dell'adattatore delle metriche o dei pod per individuare errori relativi a chiamate API, autenticazione o recupero delle metriche. Per controllare 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 risiede 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, ad esempio Metrics Explorer, per verificare che la metrica esista e abbia il nome e le etichette corretti.

Risolvere i problemi relativi al mancato fare lo scale down di Horizontal Pod Autoscaler

Questa sezione ti aiuta a capire perché un HorizontalPodAutoscaler potrebbe non ridurre il tuo workload come previsto.

Sintomi:

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

Causa:

Questo comportamento è progettato per impedire l'aumento e la riduzione rapida o la riduzione in base a informazioni incomplete. I due motivi principali sono i seguenti:

  • Utilizzo di più metriche: Horizontal Pod Autoscaler esegue lo scale up in base alla metrica che richiede il maggior numero di repliche. Se hai più metriche, il carico di lavoro non verràfare lo scale downo a meno che tutte le metriche indichino che sono necessarie meno repliche. Una metrica che richiede un numero elevato di repliche impedisce la riduzione della scalabilità, anche se le altre sono basse.
  • Metriche non disponibili: se una metrica non è più disponibile (spesso visualizzata come <unknown>), Horizontal Pod Autoscaler si rifiuta in modo conservativo di ridurre il workload. Non è in grado di determinare se la metrica è mancante perché l'utilizzo è effettivamente pari a zero o perché la pipeline delle metriche è interrotta. Questo problema è comune con le metriche personalizzate basate sulla frequenza (ad esempio messages_per_second), che possono interrompere la generazione di report sui dati in assenza di attività, facendo sì che Horizontal Pod Autoscaler consideri la metrica non disponibile e interrompa le operazioni di scale down.
  • Ritardo di riduzione della scalabilità dal criterio di scalabilità: il campo behavior di HorizontalPodAutoscaler consente di configurare i criteri di scalabilità. Il criterio predefinito per lo scale down include una finestra di stabilizzazione di 300 secondi (5 minuti). Durante questa finestra, HorizontalPodAutoscaler non riduce il conteggio delle 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 della scalabilità 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 le metriche basate sul misuratore anziché quelle basate sulla frequenza. Una metrica di tipo indicatore, ad esempio il numero totale di messaggi in una coda (ad esempio, subscription o num_undelivered_messages), riporta costantemente un valore, anche se questo valore è 0, consentendo all'Horizontal Pod Autoscaler di prendere decisioni di scalabilità in modo affidabile.
    • Assicurati che l'origine della metrica riporti 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 riduzione della scalabilità della policy di scalabilità, se la finestra di stabilizzazione predefinita di cinque minuti per le riduzioni della scalabilità è troppo lunga, personalizzala. 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 il calo delle metriche. Per ulteriori informazioni sulla configurazione di queste policy, consulta Policy di scalabilità nella documentazione di Kubernetes.

Passaggi successivi