Debug dei nodi di lavoro

Cloud privato virtuale Infrastruttura classica

Rivedi le opzioni per eseguire il debug dei nodi di lavoro e trovare le cause principali degli errori.

Controllare le notifiche del nodo di lavoro e gli aggiornamenti di manutenzione

Controlla il dashboard di integrità e stato IBM Cloud per eventuali notifiche o aggiornamenti di manutenzione che potrebbero essere rilevanti per i tuoi nodi di lavoro. Queste notifiche o aggiornamenti potrebbero aiutare a stabilire la causa degli errori del nodo di lavoro.

  1. Cluster classici Controlla ildashboard di integrità per qualsiasi notifica di manutenzione di emergenza IBM Cloud che potrebbe influire sui nodi di lavoro classici nel tuo account. A seconda della natura della notifica di manutenzione, potresti dover riavviare o ricaricare i tuoi nodi di lavoro.
  2. Controlla il dashboard di stato IBM Cloud per eventuali problemi noti che potrebbero interessare i tuoi nodi di lavoro o cluster. Se uno dei seguenti componenti mostra uno stato di errore, tale componente potrebbe essere la causa delle interruzioni del tuo nodo di lavoro.
    • Per tutti i cluster, controlla Kubernetes Service e Container Registry componenti.
    • Per i cluster Red Hat OpenShift, controllare il componente Red Hat OpenShift on IBM Cloud componente.
    • Per i cluster VPC, controlla i componenti Virtual Private Cloud, Virtual Private Endpoint e Virtual Server for VPC.
    • Per i cluster Classic, controlla i componenti Classic Infrastructure Provisioning e Virtual Servers.

Passi rapidi per risolvere i problemi del nodo di lavoro

Se il tuo nodo di lavoro non funziona come previsto, puoi seguire questa procedura per aggiornare i tuoi strumenti della riga di comando e del cluster o eseguire i test diagnostici. Se il problema persiste, vedi Debug del tuo nodo di lavoro per ulteriori passi.

  1. Aggiorna il tuo cluster e i tuoi nodi di lavoro alla versione più recente.
  2. Aggiornare gli strumenti della riga comandi.

Debug del tuo nodo di lavoro

Passo 1: ottieni lo stato del nodo di lavoro

Se il tuo cluster si trova in uno stato Critico, Eliminazione non riuscita o Avvertenza o rimane bloccato nello stato In sospeso per molto tempo, controlla lo stato dei tuoi nodi di lavoro.

ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID

Passo 2: esamina lo stato del nodo di lavoro

Controlla il campo State e Status per ogni nodo di lavoro nell'output della CLI.

Per ulteriori informazioni, vedi Stati del nodo di lavoro.

Fase 3: Ottenere i dettagli relativi a ciascun nodo di lavoro

Ottieni i dettagli relativi al nodo di lavoro. Se i dettagli includono un messaggio di errore, rivedi l'elenco di messaggi di errore comuni per i nodi di lavoro per imparare come risolvere il problema.

ibmcloud oc worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_NODE_ID

Passo 4: esamina il provider dell'infrastruttura per il nodo di lavoro

Esamina l'ambiente dell'infrastruttura per controllare altri motivi che potrebbero causare problemi al nodo di lavoro.

  1. Verifica con il tuo team di rete per assicurarti che nessuna manutenzione recente, come gli aggiornamenti del firewall o della sottorete, possa influire sulle connessioni del nodo di lavoro.
  2. Esamina IBM Cloud per Red Hat OpenShift on IBM Cloud e il provider dell'infrastruttura sottostante, come Virtual Servers per i componenti classici, correlati a VPC o Satellite.
  3. Se hai accesso all'infrastruttura sottostante, come i classici server virtualiVirtual Servers, esamina i dettagli delle macchine corrispondenti per i nodi di lavoro.

Passo 5: raccogliere i log e altri dettagli sui nodi worker

Esecuzione del comando must-gather

Il comando oc adm must-gather CLI raccoglie le informazioni dal cluster per il debug dei problemi. Questo strumento indispensabile raccoglie le definizioni delle risorse, i log dei servizi e altro ancora. Si noti che i registri di audit non vengono raccolti come parte del set di informazioni predefinito per ridurre le dimensioni dei file.

Quando si esegue oc adm must-gather, viene creato un nuovo pod con un nome casuale in un nuovo progetto del cluster. I dati vengono raccolti su quel pod e salvati in una nuova directory che inizia con must-gather.local.

Esamina i seguenti comandi di esempio.

oc adm must-gather

Per raccogliere i dati relativi a una o più caratteristiche specifiche, utilizzare l'argomento --image con un'immagine specifica.

oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

Esempio di comando per raccogliere i registri di audit.

oc adm must-gather -- /usr/bin/gather_audit_logs

Esempio di comando per eseguire must-gather in uno specifico spazio dei nomi.

oc adm must-gather --run-namespace NAMESPACE \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

Comandi di esempio per raccogliere i log da un determinato momento.

oc adm must-gather --since=24h

oc adm must-gather --since-time=$(date -d '-24 hours' +%Y-%m-%dT%T.%9N%:z )

Esempio di comando per raccogliere i log di rete.

oc adm must-gather -- gather_network_logs

Per ulteriori esempi e argomenti, eseguire il seguente comando

oc adm must-gather -h

Esempio di comando per creare un file compresso dalla directory must-gather.

tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/

Allegare il file compresso al caso di assistenza.

Raccolta di un rapporto SOS

sosreport è uno strumento che raccoglie dettagli di configurazione, informazioni di sistema e dati diagnostici dai sistemi Red Hat Enterprise Linux (RHEL) e Red Hat Enterprise Linux CoreOS (RHCOS). Fornisce un modo standardizzato per raccogliere informazioni diagnostiche relative a un nodo, che possono poi essere fornite al supporto per la diagnosi dei problemi.

In alcune interazioni di supporto, l'assistenza potrebbe chiedere di raccogliere un archivio sosreport per un nodo OpenShift Container Platform specifico. Ad esempio, potrebbe essere necessario esaminare i log di sistema o altri dati specifici del nodo che non sono inclusi nell'output di oc adm must-gather.

La procedura per l'acquisizione di un " sosreport " varia a seconda del sistema operativo del nodo di lavoro. I nodi RHCOS utilizzano il comando toolbox . I nodi RHEL 8 e RHEL 9 non supportano il comando toolbox``; utilizzare invece lo script sosreport disponibile all'indirizzo Red Hat.

Il modo consigliato per generare un sosreport per un nodo del cluster OpenShift Container Platform è attraverso un pod di debug.

Accedi al tuo cluster Red Hat OpenShift.

  1. Elenca i tuoi nodi di lavoro per identificare il nodo di destinazione e il relativo sistema operativo.

    oc get nodes -o wide

    Prendi nota del nome del nodo di lavoro da cui desideri raccogliere l' sosreport. La colonna OS-IMAGE indica se sul nodo è in esecuzione RHCOS o RHEL.

  2. Avvia una sessione di debug sul nodo di destinazione.

    oc debug node/node_name

    Per entrare in una sessione di debug sul nodo di destinazione che è contaminato dall'effetto NoExecute, aggiungere una tolleranza a uno spazio dei nomi temporaneo e avviare il pod di debug nello spazio dei nomi temporaneo.

    oc new-project temp oc patch namespace temp --type=merge -p '{"metadata": {"annotations": { "scheduler.alpha.kubernetes.io/defaultTolerations": "[{\"operator\": \"Exists\"}]"}}}'

    oc debug node/my-cluster-node

  3. Impostare /host come directory principale della shell di debug. Il pod di debug monta il file system root dell'host in /host all'interno del pod. Modificando la directory principale in /host, è possibile eseguire i file binari presenti nei percorsi degli eseguibili dell'host.

    chroot /host

    OpenShift Container Platform I nodi cluster che eseguono Red Hat Enterprise Linux CoreOS (RHCOS) sono immutabili e si affidano agli operatori per applicare le modifiche al cluster. L'accesso ai nodi del cluster tramite SSH non è consigliato. Tuttavia, se l'API OpenShift Container Platform non è disponibile o il kubelet non funziona correttamente sul nodo di destinazione, le operazioni oc potrebbero risentirne. In queste situazioni, è possibile accedere ai nodi utilizzando ssh core@NODE.CLUSTER_NAME.BASE_DOMAIN.

  4. Raccogli i file di log di " sosreport " utilizzando il metodo compatibile con il sistema operativo del nodo di lavoro.

    • Nodi RHCOS : utilizzare il comando toolbox .

      1. Avviare un contenitore di toolbox, che include i binari e i plug-in necessari per l'esecuzione di sosreport. Il comando toolbox è supportato solo sui nodi RHCOS.

        toolbox

        Se è già in esecuzione un pod toolbox esistente, il comando toolbox restituisce 'toolbox-' already exists. Trying to start…. Rimuovere il contenitore toolbox in esecuzione con podman rm toolbox- e avviare un nuovo contenitore toolbox.

      2. Eseguire il comando sos report e seguire le istruzioni per raccogliere i dati di risoluzione dei problemi.

        sos report -k crio.all=on -k crio.logs=on -k podman.all=on -k podman.logs=on

        Esempio di comando per includere nel report informazioni sulle configurazioni di rete OVN- Kubernetes di un nodo.

        sos report --all-logs

        L'output di sosreport fornisce il percorso dell'archivio e il checksum. Il seguente esempio di output fa riferimento all'ID del caso di supporto 01234567. Il percorso del file si trova al di fuori dell'ambiente chroot poiché il container del toolbox monta la directory root dell'host all'indirizzo /host.

        Your sosreport has been generated and saved in:
/host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
The checksum is: 382ffc167510fd71b4f12a4f40b97a4e

    • Nodi RHEL 8 e RHEL 9 : il comando toolbox non è supportato sui nodi RHEL. Utilizza invece lo script di raccolta dei rapporti SOS " Red Hat ".

      1. Scarica ed esegui lo script sosreport disponibile all'indirizzo Red Hat seguendo le istruzioni riportate nell'articolo della knowledge base all'indirizzo Red Hat.

      2. Segui le istruzioni riportate nello script per raccogliere i dati necessari alla risoluzione dei problemi. Prendere nota della posizione del file di archivio generato dall'output dello script.

  5. Invia il sito sosreport a un file.

    Il container di debug monta la directory root dell'host all'indirizzo /host. Quando si specificano i file di destinazione per la concatenazione, indicare il percorso assoluto a partire dalla directory principale del contenitore di debug, includendo /host.

    oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz' > /tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz

    OpenShift Container Platform I nodi cluster che eseguono Red Hat Enterprise Linux CoreOS (RHCOS) sono immutabili e si affidano agli operatori per applicare le modifiche al cluster. Il trasferimento di un archivio sosreport da un nodo del cluster utilizzando scp non è consigliato. Tuttavia, se l'API OpenShift Container Platform non è disponibile o il kubelet non funziona correttamente sul nodo di destinazione, oc le operazioni potrebbero subire delle ripercussioni. In queste situazioni, è possibile copiare un archivio sosreport da un nodo eseguendo scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>.

  6. Caricate il file nel vostro caso di assistenza.