Come ottenere assistenza e supporto per il proprio cluster

Scopri le opzioni di assistenza, le risorse per la risoluzione dei problemi e i modi per ottenere aiuto per il tuo cluster.

Prima di aprire un caso di supporto, raccogli informazioni pertinenti sul tuo ambiente cluster.

Cercate lo strumento di diagnostica e debug? Questo componente aggiuntivo non è più supportato. IBM Cloud Monitoring è consigliato per monitorare e diagnosticare i problemi del cluster. Altri link per la risoluzione dei problemi che potrebbero essere rilevanti includono Risoluzione dei problemi dei nodi worker in stato critico o NotReady e Risoluzione dei problemi delle app in IBM Cloud Kubernetes Service.

Ottenere i dettagli del cluster

  1. Ottieni i dettagli del tuo cluster.

    ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
    
  2. Se il tuo problema riguarda i nodi di lavoro, ottieni i dettagli del nodo di lavoro.

    1. Elenca tutti i nodi nel cluster e prendi nota dell'ID dei nodi di lavoro che presentano uno State o Status non integro.
        ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
        ```
    2. Ottieni i dettagli del nodo di lavoro non integro.
    
    ```sh {: pre}
        ibmcloud oc worker get -w WORKER_ID -c CLUSTER_NAME_OR_ID
        ```
    
  3. Per problemi con le risorse all'interno del tuo cluster come i pod o i servizi, accedi al cluster e utilizza l'API Kubernetes per ottenere maggiori informazioni.

Raccogliere i log degli errori e altre informazioni

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 suo 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 contenitore 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 risentirne. 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.

Apri un caso di supporto

  1. Contatta il supporto IBM aprendo un caso.

  2. Per il Tipo di problema, cercare o selezionare Red Hat OpenShift on IBM Cloud.

  3. Per i dettagli del caso, fornire un titolo descrittivo e includere i dettagli precedentemente raccolti. Da Risorse, puoi anche selezionare il cluster a cui è correlato il problema.

  4. Essere il più specifici possibile e includere diagrammi di architettura o materiali supplementari che si ritiene possano aiutare il supporto IBM a risolvere il problema.