Debug del cluster autoscaler

Rivedi le opzioni di cui disponi per il debug del tuo cluster autoscaler e per trovare le cause principali degli errori.

Prima di iniziare: accedi al tuo cluster Red Hat OpenShift.

Passaggio 1: Verificare la versione

  1. Verificare che il componente aggiuntivo del cluster autoscaler sia installato e pronto.
    ibmcloud oc cluster addon ls --cluster CLUSTER_NAME
    Output di esempio
    Name                 Version   Health State   Health Status   
cluster-autoscaler   1.0.4     normal         Addon Ready
  2. Confronta la versione eseguita nel tuo cluster con l'ultima versione nel componente aggiuntivo Cluster autoscaler change log.
  3. Se la tua versione non è aggiornata, installa sul tuo cluster l'ultima versione di Cluster Autoscaler.

Passo 2: controllare la configurazione

Verifica che il cluster autoscaler sia configurato correttamente.

  1. Ottieni il file di configurazione YAML della mappa di configurazione del cluster autoscaler.

    oc get cm iks-ca-configmap -n kube-system -o yaml > iks-ca-configmap.yaml

  2. Nel campo data.workerPoolsConfig.json, verifica che i pool di lavoro corretti siano abilitati con la dimensione minima e massima per ogni pool di lavoro.

    • "name": "<worker_pool_name>": Il nome del pool di worker nell' ConfigMap e deve corrispondere esattamente al nome del pool di worker nel proprio cluster. Più pool di lavoro devono essere separati da una virgola. Per verificare il nome dei pool di worker del proprio cluster, eseguire il comando ibmcloud oc worker-pool ls -c <cluster_name_or_ID>``.
    • "minSize": 2: in generale, il valore minSize deve 2 o superiore.
    • "maxSize": 3: il valore maxSize deve essere uguale o maggiore del valore minSize.
    • "enabled": true: imposta il valore su true per abilitare il ridimensionamento automatico del pool di lavoro.
    data:
    workerPoolsConfig.json: |
        [{"name": "default", "minSize": 2, "maxSize": 3, "enabled": true }]

  3. Nel campo metadata.annotations.workerPoolsConfigStatus, controlla se è presente un messaggio di errore FAILED CODE. Segui tutte le istruzioni per il ripristino riportate nel messaggio di errore. Ad esempio, potresti ricevere un messaggio simile al seguente, in cui devi disporre delle autorizzazioni corrette per il gruppo di risorse in cui si trova il cluster.

    annotations:
    workerPoolsConfigStatus: '{"1:3:default":"FAILED CODE: 400
    ...
    \"description\":\"Unable
    to validate the request with resource group manager.\",\"type\":\"Authentication\\"recoveryCLI\":\"To
    list available resource groups, run ''ibmcloud resource groups''. Make sure
    that your cluster and the other IBM Cloud resources that you are trying to use
    are in the same resource group. Verify that you have permissions to work with
    the resource group. If you think that the resource group is set up correctly
    and you still can't use it, contact IBM Cloud support.\"}"}'

Passo 3: esamina lo stato del cluster autoscaler

Esamina lo stato del cluster autoscaler.

oc describe cm -n kube-system cluster-autoscaler-status
  • status: esamina il messaggio di stato per ulteriori informazioni sulla risoluzione dei problemi, se presenti.
  • Health: esamina lo stato generale del cluster autoscaler per eventuali errori o guasti.
  • ScaleUp: Verificare lo stato di avanzamento delle attività di espansione. In generale, se il numero di nodi di lavoro pronti e registrati coincide, lo scale-up non ha un NoActivity e, poiché il pool di nodi di lavoro dispone di un numero sufficiente di nodi di lavoro.
  • ScaleDown: Verificare lo stato di avanzamento delle attività di ridimensionamento. Se il cluster autoscaler identifica NoCandidates, il tuo pool di lavoro non viene ridotto poiché nessuno dei nodi di lavoro può essere rimosso senza rimuovere le risorse richieste dai tuoi carichi di lavoro.
  • Events: esamina gli eventi per ulteriori informazioni sulla risoluzione dei problemi, se presenti.

Esempio di stato di un autoscaler di cluster in condizioni ottimali

Data
====
status:
----
Cluster-autoscaler status at 2020-02-04 19:51:50.326683568 +0000 UTC:
Cluster-wide:
Health:      Healthy (ready=2 unready=0 notStarted=0 longNotStarted=0 registered=2longUnregistered=0)
            LastProbeTime:      2020-02-04 19:51:50.324437686 +0000 UTC m=+9022588.836540262
            LastTransitionTime: 2019-10-23 09:36:25.741087445 +0000 UTC m=+64.253190008
ScaleUp:     NoActivity (ready=2 registered=2)
            LastProbeTime:      2020-02-04 19:51:50.324437686 +0000 UTC m=+9022588.836540262
            LastTransitionTime: 2019-10-23 09:36:25.741087445 +0000 UTC m=+64.253190008
ScaleDown:   NoCandidates (candidates=0)
            LastProbeTime:      2020-02-04 19:51:50.324437686 +0000 UTC m=+9022588.836540262
            LastTransitionTime: 2019-10-23 09:36:25.741087445 +0000 UTC m=+64.253190008
Events:  none

Passo 4: controlla il pod del cluster autoscaler

Controlla l'integrità del pod del cluster autoscaler.

  1. Richiama il pod del cluster autoscaler. Se lo stato non è Running, descrivi il pod.

    oc get pods -n kube-system | grep ibm-iks-cluster-autoscaler

  2. Descrivi il pod del cluster autoscaler. Esamina la sezione Events per ulteriori informazioni sulla risoluzione dei problemi.

    oc describe pod -n kube-system <pod_name>

  3. Controlla la sezione "Comandi" per verificare che la configurazione personalizzata dell'autoscaler del cluster corrisponda a quanto previsto, ad esempio il valore "scale-down-delay-after-add ".

    Command:
    ./cluster-autoscaler
    --v=4
    --balance-similar-node-groups=true
    --alsologtostderr=true
    --stderrthreshold=info
    --cloud-provider=IKS
    --skip-nodes-with-local-storage=true
    --skip-nodes-with-system-pods=true
    --scale-down-unneeded-time=10m
    --scale-down-delay-after-add=10m
    --scale-down-delay-after-delete=10m
    --scale-down-utilization-threshold=0.5
    --scan-interval=1m
    --expander=random
    --leader-elect=false
    --max-node-provision-time=120m

Passo 5: cerca i log del pod

Cerca nei log del pod dell'autoscaler del cluster i messaggi rilevanti, come i messaggi di errore del tipo “ lastScaleDownFailTime ”, “ Final scale-up plan ” o gli eventi relativi all'autoscaler del cluster.

Se il pod dell'autoscaler del cluster non è operativo e non è in grado di trasmettere i log, controlla i log del pod nell'istanza di IBM Cloud Logs. Nota che se il tuo amministratore del cluster non ha abilitato IBM Cloud Logs per il tuo cluster, potresti non avere alcun log da esaminare.

oc logs -n kube-system <pod_name> -c ibm-iks-cluster-autoscaler > logs.txt

Passo 6: riavviare il pod

Se non riscontri alcun malfunzionamento o messaggio di errore e hai già abilitato la registrazione, riavvia il pod dell'autoscaler del cluster. La distribuzione ricrea il pod.

oc delete pod -n kube-system <pod_name>

Passo 6: disabilita e riabilita

Facoltativo: se hai completato i passi di debug e il tuo cluster non viene ancora ridimensionato, puoi disabilitare e riabilitare l'autoscaler modificando la mappa di configurazione.

  1. Modifica la iks-ca-configmap.

    oc edit cm iks-ca-configmap -n kube-system

    Output di esempio:

    apiVersion: v1
data:
workerPoolsConfig.json: |
    [{"name": "default", "minSize": 2, "maxSize": 5, "enabled": true }]
kind: ConfigMap
metadata:
annotations:
    workerPoolsConfigStatus: '{"2:5:default":"SUCCESS"}'
creationTimestamp: "2020-03-24T17:44:35Z"
name: iks-ca-configmap
namespace: kube-system
resourceVersion: "40964517"
selfLink: /api/v1/namespaces/kube-system/configmaps/iks-ca-configmap
uid: 11a1111a-aaaa-1a11-aaa1-aa1aaaa11111

  2. Imposta il parametro enabled su false e salva le modifiche.

  3. Modifica di nuovo la iks-ca-configmap. Imposta il parametro enabled su true e salva le modifiche.

    oc edit cm iks-ca-configmap -n kube-system

  4. Se il cluster continua a non scalare dopo aver disabilitato e riabilitato l'autoscaler del cluster, è possibile modificare i parametri minSize o maxSize nel file iks-ca-configmap``. A volte, la modifica dei parametri del nodo di lavoro minSize e maxSize riavvia correttamente il cluster autoscaler.

    oc edit cm iks-ca-configmap -n kube-system

  5. Modifica i parametri minSize o maxSize e salva le modifiche.

Fase 7: Verificare se il problema è stato risolto

Monitora le attività del cluster autoscaler nel tuo cluster per vedere se il problema viene risolto. Se continui a riscontrare problemi, vedi Feedback, domande e supporto.