Vorbereitende Schritte

Bevor Sie die Observability-Dienste zur Fehlerbehebung in Ihrem Cluster nutzen können, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind.

• Ihr Cluster ist mit einer IBM Cloud Monitoring-Instanz verbunden. Informationen zum Verbinden Ihres Clusters finden Sie unter Aktivieren von Metriken für das Red Hat OpenShift on IBM Cloud.
• Ihr Cluster ist mit einer IBM Cloud Logs-Instanz verbunden. Informationen zum Verbinden Ihres Clusters finden Sie unter Protokollierung aktivieren.
• Sie verfügen mindestens über Viewer-Zugriff auf die Service-Instanzen IBM Cloud Monitoring und IBM Cloud Logs in Ihrem Konto.

Überprüfen Sie die Ressourcenauslastung der Worker-Knoten mit IBM Cloud Monitoring

Wenn Worker-Knoten in den Zustand NotReady oder Critical übergehen, ist eine hohe CPU- oder Speicherauslastung eine häufige Ursache. Nutzen Sie die vorgefertigten Dashboards von IBM Cloud Monitoring, um Ressourcenengpässe schnell zu erkennen.

1. Öffnen Sie das IBM Cloud Monitoring-Dashboard für Ihren Cluster.

   1. Navigieren Sie in der IBM Cloud-Konsole zur Seite mit Ihren Cluster-Ressourcen und klicken Sie auf den entsprechenden Cluster.
   2. Suchen Sie unter Integrationen die Option Überwachung und klicken Sie auf Starten. Die Benutzeroberfläche von IBM Cloud Monitoring wird in einem neuen Fenster geöffnet.

2. Navigieren Sie zum vordefinierten Dashboard Kubernetes > Nodes, um die CPU- und Speicherauslastung pro Knoten anzuzeigen.

   • Suchen Sie nach Knoten, bei denen der CPU- oder Speicherauslastungsprozentsatz 80 % übersteigt. Knoten, die diesen Schwellenwert erreichen oder überschreiten, laufen Gefahr, überlastet zu werden, und können möglicherweise keine neuen Pods mehr einplanen.
   • Suchen Sie nach Knoten, bei denen die CPU- oder Speicherauslastung einen plötzlichen Anstieg aufweist oder in der letzten Stunde oder am letzten Tag durchgehend erhöht war. So können Sie feststellen, ob es sich um ein vorübergehendes oder ein andauerndes Problem handelt.

3. Um einen bestimmten Knoten zu untersuchen, klicken Sie im Dashboard auf den Namen des Knotens, um alle Diagramme auf diesen Knoten zu filtern. Bitte überprüfen Sie die folgenden Kennzahlen:

   • CPU-Auslastung in % – ein anhaltender Wert über 90 % deutet auf eine CPU-Auslastung hin.
   • Speicherauslastung in % – ein Wert, der konstant über 85 % liegt, erhöht das Risiko von Out-of-Memory-Ereignissen (OOM).
   • Eingehende/ausgehende Netzwerkbytes – ein unerwarteter Anstieg des Datenverkehrs kann auf eine außer Kontrolle geratene Arbeitslast oder einen Netzwerkangriff hindeuten.

4. Um zu überprüfen, welche Pods auf einem Knoten die meisten Ressourcen verbrauchen, navigieren Sie zum Dashboard Kubernetes > Pods und filtern Sie nach dem betroffenen Knoten. Notieren Sie sich die Namen aller Pods, die durchgehend eine hohe CPU- oder Speicherauslastung aufweisen, da diese wahrscheinlich für die Instabilität des Worker-Knotens verantwortlich sind.

Überprüfen Sie den Zustand der Pods und die Anzahl der Neustarts mit IBM Cloud Monitoring

Pods, die in eine Crash-Schleife geraten oder häufig neu starten, sind ein häufiges Anzeichen für Probleme auf Anwendungsebene, wie z. B. OOM-Kills oder falsch konfigurierte Bereitschaftsprüfungen. Verwenden Sie IBM Cloud Monitoring, um diese Pods zu identifizieren, ohne den Befehl wiederholt oc get pods ausführen zu müssen.

1. Navigieren Sie in der Benutzeroberfläche von IBM Cloud Monitoring zum vorgefertigten Dashboard Kubernetes > Pods.

2. Sehen Sie sich das Fenster Container-Neustarts an. Suchen Sie nach Pods, bei denen die Anzahl der Neustarts in den letzten 15 Minuten größer als null ist oder die über einen längeren Zeitraum einen raschen Anstieg aufweisen.

   • Eine sich wiederholt erhöhende Neustartzahl deutet auf eine Absturzschleife hin. Notieren Sie sich den Pod-Namen und den Namespace für die nachfolgenden Schritte zur Protokollanalyse.
   • Eine Neustartanzahl von Null bei einem Status Pending oder Unknown deutet eher auf ein Problem bei der Planung oder der Knotenverbindung hin als auf einen Anwendungsfehler.

3. Um eine Benachrichtigung für zukünftige Pod-Neustart-Ereignisse einzurichten, klicken Sie in der Benutzeroberfläche von IBM Cloud Monitoring auf das Symbol Alerts und erstellen Sie eine Metrik-Benachrichtigung für die betreffende Metrik kubernetes.pod.restart.count. Legen Sie den Schwellenwert so fest, dass eine Auslösung erfolgt, wenn die Anzahl der Neustarts für einen beliebigen Pod innerhalb von fünf Minuten zwei überschreitet. Dies dient als Frühwarnung, bevor eine Absturzschleife zu Störungen führt. Weitere Informationen zum Konfigurieren von Benachrichtigungen finden Sie unter IBM Cloud® Monitoring-Benachrichtigungen einrichten

Untersuchen Sie Container-Protokolle mit IBM Cloud Logs

Wenn ein Pod neu gestartet wurde oder bei einem Knoten Probleme auftreten, ist die Überprüfung der Containerprotokolle unerlässlich, um die Ursache zu ermitteln. IBM Cloud Logs speichert historische Protokolldaten, die nach oc logs dem Neustart eines Containers nicht mehr über [...], verfügbar sind.

1. IBM Cloud Logs-Dashboard öffnen

   1. Navigieren Sie in der IBM Cloud-Konsole zur Seite mit Ihren Cluster-Ressourcen und klicken Sie auf den entsprechenden Cluster.
   2. Suchen Sie unter Integrationen die Option Protokollierung und klicken Sie auf Starten. Die Benutzeroberfläche von IBM Cloud Logs wird in einem neuen Fenster geöffnet.

2. Stellen Sie den Zeitbereich so ein, dass er den Zeitraum abdeckt, in dem das Problem aufgetreten ist. Wenn das Problem weiterhin besteht, stellen Sie den Zeitraum auf die letzte Stunde ein. Wenn Sie ein vergangenes Ereignis untersuchen, geben Sie die genaue Start- und Endzeit an, um die Ergebnisse einzugrenzen.

3. Suchen Sie nach dem betroffenen Pod oder Namespace. Verwenden Sie die Suchleiste oben in der Benutzeroberfläche, um Protokolle zu filtern. Um beispielsweise Protokolle aller Pods im Namespace default anzuzeigen, geben Sie die folgende Abfrage ein:

   kubernetes.namespace_name:"default"
   

   Um die Ergebnisse nach dem Namen eines bestimmten Pods einzugrenzen, verwenden Sie:

   kubernetes.pod_name:"MY_POD_NAME"
   

4. Überprüfen Sie die Protokolleinträge auf Einträge der Fehlerstufe. Achten Sie auf folgende Muster, die auf häufige Fehlerursachen hinweisen:

   • OOMKilled oder out of memory — Der Container hat sein Speicherlimit überschritten und wurde vom Kernel beendet.
   • CrashLoopBackOff — Der Container wird wiederholt neu gestartet, häufig aufgrund eines Anwendungsfehlers beim Start.
   • failed to pull image oder ImagePullBackOff — Der Knoten kann das Container-Image nicht aus der Registry abrufen.
   • Connection refused oder context deadline exceeded — Die Anwendung kann keinen abhängigen Dienst oder den Kubernetes-API-Server erreichen.

5. Wenn Sie einen OOM-bezogenen Protokolleintrag finden, notieren Sie sich den Zeitstempel und überprüfen Sie das Dashboard Pods unter IBM Cloud MonitoringKubernetes für denselben Zeitrahmen, um zu bestätigen, dass die Speicherauslastung des Pods unmittelbar vor dem Neustart ihr Limit erreicht hatte.

Kubernetes-Veranstaltungen finden Sie unter IBM Cloud Logs

Kubernetes Ereignisse erfassen wichtige Clusteraktivitäten wie Fehler bei der Pod-Planung, Knotenzustände und Fehler beim Einbinden von Volumes. IBM Cloud Logs nimmt diese Ereignisse automatisch auf und ermöglicht es Ihnen, sie historisch zu durchsuchen und zu filtern – im Gegensatz zu [...] oc get events, das nur aktuelle Ereignisse aus der laufenden Sitzung anzeigt.

1. Verwenden Sie in der Benutzeroberfläche von IBM Cloud Logs die folgende Abfrage, um alle Kubernetes-Warnereignisse im gesamten Cluster anzuzeigen:

   kubernetes.event.type:"Warning"
   

2. Um Ereignisse auf einen bestimmten Worker-Knoten zu filtern, fügen Sie den Knotennamen zur Abfrage hinzu. Ersetzen Sie NODE_NAME durch den Namen des betroffenen Knotens:

   kubernetes.event.type:"Warning" AND kubernetes.event.involvedObject.name:"NODE_NAME"
   

3. Überprüfen Sie das Feld Grund in den Einträgen des Ereignisprotokolls. Die folgenden Gründe sind für die Fehlerbehebung bei Problemen mit Worker-Knoten und Workloads am relevantesten:

NodeNotReady

Der Knoten meldet einen Zustand NotReady. Dieses Ereignis geht häufig dem Eintritt eines Worker-Knotens in einen bestimmten Zustand Critical voraus oder erfolgt gleichzeitig damit.

OOMKilling

Der Kernel hat einen Prozess auf dem Knoten aufgrund von Speichermangel beendet.

FailedScheduling

Der Scheduler konnte keinen Pod auf einem der verfügbaren Knoten platzieren. Im Meldungsfeld wird in der Regel der Grund angegeben, z. B. unzureichende CPU-Leistung, zu wenig Arbeitsspeicher oder eine Nichtübereinstimmung des Knotenselektors.

BackOff

Ein Container befindet sich in einer Absturzschleife. Das Ereignis wird jedes Mal ausgelöst, wenn der Container vor dem Neustart eine Wartezeit kubelet einlegt.

FailedMount oder FailedAttachVolume

Ein persistenter Datenträger konnte nicht in einen Pod eingebunden oder diesem zugeordnet werden, wodurch der Start des Pods verhindert wird.

1. Notieren Sie sich bei jedem Ereignis, das relevant erscheint, die Werte involvedObject.namespace und involvedObject.name und nutzen Sie diese, um eine Zuordnung zu den Protokoll- und Metrikdaten herzustellen, die Sie in den vorherigen Abschnitten erfasst haben.

Nächste Schritte

• Wenn Sie einen Worker-Knoten identifiziert haben, der unter Ressourcenbelastung steht, sollten Sie in Erwägung ziehen, den Worker-Knoten neu zu laden oder zu ersetzen oder die Ressourcenanforderungen und -beschränkungen für die auf diesem Knoten ausgeführten Pods anzupassen.
• Wenn Pods aufgrund von OOM-Kills in eine Crash-Schleife geraten, erhöhen Sie die Speichergrenzen für die betroffenen Container oder verlagern Sie speicherintensive Workloads in einen Worker-Pool mit größeren Knoten.
• Wenn die Protokolle Fehler beim Abrufen von Images anzeigen, überprüfen Sie Ihre Geheimnisse für das Abrufen von Images und stellen Sie sicher, dass der Worker-Knoten die Container-Registry erreichen kann.
• Bei Problemen, die sich mit den hier zusammengestellten Informationen nicht lösen lassen, lesen Sie den Abschnitt Daten für einen Supportfall sammeln, um die für die Eröffnung eines Support-Tickets erforderlichen Informationen zu erfassen.

Zugehörige Links

• Clusterzustand überwachen
• Erste Schritte mit IBM Cloud Monitoring
• Erste Schritte mit IBM Cloud Logs
• Fehlerbehebung bei Worker-Knoten im Critical oder Zustand NotReady
• IBM Cloud® Monitoring-Alerts einrichten