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.

Esaminate i seguenti esempi di comandi.

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 di un determinato periodo di tempo.

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.

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.

   oc get nodes
   

2. Avviare 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. Cambiando la directory principale in /host, è possibile eseguire i binari contenuti nei percorsi eseguibili dell'host.

   chroot /host
   

   OpenShift Container Platform i nodi del 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 se il kubelet non funziona correttamente sul nodo di destinazione, le operazioni oc potrebbero essere compromesse. In queste situazioni, è possibile accedere ai nodi utilizzando ssh core@<node>.<cluster_name>.<base_domain>.

4. Avviare un contenitore di toolbox, che include i binari e i plugin necessari per l'esecuzione di sosreport.

   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.

5. 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 la posizione e il checksum dell'archivio. Il seguente esempio di output fa riferimento all'ID del caso di supporto 01234567. Il percorso del file è al di fuori dell'ambiente chroot perché il contenitore toolbox monta la directory principale dell'host su /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
   

6. Invia il sito sosreport a un file.

   Il contenitore di debug monta la directory principale dell'host all'indirizzo /host. Fa riferimento al percorso assoluto della cartella principale del contenitore di debug, incluso /host, quando si specificano i file di destinazione per la concatenazione.

   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 del 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 se il kubelet non funziona correttamente sul nodo di destinazione, le operazioni di oc potrebbero essere compromesse. In queste situazioni, è possibile copiare un archivio sosreport da un nodo eseguendo scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>.

7. Caricate il file nel vostro caso di assistenza.