Esamina lo stato di IBM Cloud

1. Per vedere se IBM Cloud è disponibile, controlla la pagina di stato IBM Cloud.
2. Filtra per il componente Kubernetes Service.
3. Riesamina la documentazione sulle limitazioni e sui problemi noti.
4. Per quanto riguarda i problemi relativi ai progetti open source utilizzati da IBM Cloud, consultare la politica “ IBM ” in materia di open source e terze parti. Ad esempio, potresti controllare i problemi aperti Kubernetes.

Ottieni lo stato e lo stato del tuo cluster ed esamina i problemi comuni

1. Elenca il tuo cluster e trova lo State del cluster.

   ibmcloud ks cluster ls
   

2. Esamina lo State del cluster. Se il cluster si trova in uno stato "Critico ", "Eliminazione non riuscita " o "Avviso", oppure rimane bloccato nello stato "In sospeso " per un lungo periodo di tempo. Per ulteriori informazioni, consulta stati del cluster.

3. Esamina lo stato di ciascun nodo di lavoro. Per ulteriori informazioni, consultare la sezione dedicata agli stati dei nodi di lavoro.

   ibmcloud ks worker ls -c CLUSTER
   

4. Esaminare le seguenti informazioni per eseguire il debug o la risoluzione dei problemi del nodo worker.

   • Problemi comuni dei nodi worker
   • Guida al debug dei problemi del nodo worker
   • Trovare i nodi worker in stato Critical o NotReady

Raccogliere i dettagli e documentare il problema

Quando si documentano i dettagli sul problema, essere il più specifici possibile. Ad esempio, Our app occasionally gets 502 Gateway errors when trying to retrieve transaction logs non è utile perché non è specifico. Assicuratevi di restringere il più possibile il problema prima di documentarlo. Quando si documenta il problema, provare a includere quanto segue.

Architettura dell'ambiente

Assicuratevi di aver documentato l'architettura dell'ambiente in modo da comprendere i componenti coinvolti. Per ulteriori informazioni, consultare Documentazione dell'architettura dell'ambiente.

Messaggi di errore e dettagli del componente.

Fornire il messaggio di errore completo e includere i dettagli su quale componente sta producendo l'errore. Ad esempio, "Tutti e tre i pod delle applicazioni in clusterID ABCDEF occasionalmente falliscono su HTTPS chiamate a GET /transaction-logs dal bilanciatore di carico globale con l'errore HTTP 502 Gateway Error: Web server received an invalid response while acting as a gateway or proxy server...".

IP di origine, IP di destinazione, porta e protocollo della connessione.

Ad esempio, " Tutti e tre i pod dell'applicazione nel cluster Kubernetes con clusterID ABCDEF. Occasionalmente, le chiamate a HTTPS falliscono quando si tenta di inviare GET /transaction-logs al GLB con l'errore L'IP del pod di origine è 172.22.5.10 e l'IP di destinazione è 150.40.40.35 porta 433. Il protocollo è HTTPS. Altri pod utilizzano questo indirizzo IP come gli altri due IP GLB 150.40.40.55 e 150.40.40.75".

Data di inizio, ora e frequenza del problema.

Esamina i seguenti esempi di messaggi.

• Questo problema riguarda circa il 2% di tutti i tentativi di collegamento.
• Questo problema si verifica solo tra le 19:00 e le 21:00 UTC, e durante tali orari interessa circa il 5% di tutti i tentativi di collegamento.
• Questo problema si verifica durante la connessione dall'ID pod XYZ. Il problema è iniziato il 10/25/2023 alle 05:30 UTC circa.

Risoluzione dei problemi già intrapresi.

Documentare ciò che è stato provato finora e i risultati di tali tentativi per aiutare a restringere ulteriormente il problema.

Esecuzione di test per eseguire o escludere ogni componente

1. Provare a ricreare il problema al di fuori del flusso completo dell'app. Ciò potrebbe comportare quanto segue.
   • Utilizzare curl su un sistema separato o in un pod di test in un cluster per connettersi all'endpoint di backend o al servizio per stabilire o meno che il client potrebbe essere l'origine del problema.
   • Tentativo di connessione a un endpoint noto come www.ibm.com dal client o da un pod di test nel cluster. Se l'endpoint noto funziona in modo coerente, ma l'endpoint dell'applicazione reale non funziona, questo aiuta a restringere il problema.
2. Provare a ricreare il problema in un ambiente di verifica utilizzando un cluster di test.
   • Se non puoi ricreare il problema in un cluster di test, puoi concentrarti sulle differenze tra il cluster di test e il cluster reale come possibili origini del problema.
   • Se è possibile ricrearlo in un cluster di test, è probabile che non sia un problema con il cluster stesso. Inoltre, si dispone di un ambiente in cui è possibile eseguire test per restringere ulteriormente il problema senza influire sull'ambiente di produzione.

Raccolta di più dati

Una volta che conosci il flusso dell'applicazione, l'errore specifico che stai vedendo e da dove proviene quell' errore, puoi raccogliere dati più dettagliati dai componenti coinvolti. Ciò potrebbe includere i seguenti log.

• Log di processo e pod sui componenti interessati.
• Log del nodo cluster come syslog o /var/log/messages. Per IBM Cloud Kubernetes Service, è possibile ottenere syslog e altri log direttamente dai nodi.
  • Accesso nodo cluster
• Informazioni di traccia pacchetto. L'esecuzione tcpdump è un modo comune per ottenere informazioni sulla traccia dei pacchetti.

Passi successivi

Se il problema persiste, contattare il supporto. Apri un caso di supporto. Nei dettagli del caso, assicurarsi di includere i file di log, i messaggi di errore o gli output dei comandi pertinenti.