開始之前

在您使用可觀察性服務來除錯叢集之前，請確保已滿足以下要求。

• 您的叢集已連線至一個 IBM Cloud Monitoring 實例。 若要連線至您的叢集，請參閱《 為 Red Hat OpenShift on IBM Cloud 啟用指標 》。
• 您的叢集已連線至一個 IBM Cloud Logs 實例。 若要連線至您的叢集，請參閱「啟用記錄功能」。
• 您對帳戶中的 IBM Cloud Monitoring 及 IBM Cloud Logs 服務實例，至少擁有「檢視者」權限。

使用以下指令檢查工作節點的資源使用狀況：IBM Cloud Monitoring

當工作節點進入「Critical」或「NotReady」狀態時，CPU 或記憶體使用率過高通常是主要原因。 使用 IBM Cloud Monitoring 上的預建儀表板，快速識別資源壓力。

1. 開啟您所屬叢集的 IBM Cloud Monitoring 儀表板。

   1. 在 IBM Cloud 控制台中，導航至您的叢集資源頁面，並點擊相關的叢集。
   2. 在「整合」下，找到「監控」選項，然後點擊「啟動」。 IBM Cloud Monitoring 的使用者介面將在新視窗中開啟。

2. 導覽至 Kubernetes >「節點」預建儀表板，以查看各節點的 CPU 和記憶體使用狀況。

   • 請尋找那些「CPU %」或「記憶體 %」超過 80% 的節點。 達到或超過此閾值的節點有過載的風險，並可能開始無法排程新的 Pod。
   • 請尋找那些在過去一小時或一天內，CPU 或記憶體使用率出現突然飆升，或持續處於高位的節點。 這有助於您判斷問題是暫時的，還是持續存在的。

3. 若要檢視特定節點，請在儀表板上點擊該節點名稱，以將所有圖表篩選為該節點的資料。 請檢查以下指標：

   • CPU 使用率 % — 若持續高於 90%，即表示 CPU 已達飽和狀態。
   • 記憶體使用率 % — 若此數值持續高於 85%，將增加發生記憶體不足 (OOM) 事件的風險。
   • 網路進/出位元組 — 流量出現意外激增，可能表示工作負載失控或遭受網路攻擊。

4. 若要查看哪些 Pod 在某個節點上消耗最多資源，請導航至 Kubernetes >「Pods」儀表板，並根據受影響的節點進行篩選。 請記錄任何 CPU 或記憶體使用率持續偏高的 Pod 名稱，因為這些很可能是導致工作節點不穩定的主因。

使用以下指令檢查 Pod 狀態及重新啟動次數：IBM Cloud Monitoring

頻繁發生崩潰循環或重啟的 Pod，通常是應用程式層級問題的徵兆，例如因記憶體不足（OOM）而遭終止，或是就緒探針設定錯誤。 請使用 IBM Cloud Monitoring 來識別這些 Pod，而無需反覆執行 oc get pods 。

1. 在 IBM Cloud Monitoring 使用者介面中，請導航至 Kubernetes >「預建 Pod」儀表板。

2. 檢視「容器重新啟動」面板。 請尋找在過去 15 分鐘內重啟次數大於零，或在較長期間內重啟次數急遽增加的 Pod。

   • 若重啟次數持續增加，則表示系統陷入死循環。 請記下 Pod 名稱與命名空間，以便在後續的日誌調查步驟中使用。
   • 若重新啟動次數為零，但狀態顯示為「待處理」或「未知」，則表示這是排程或節點連線問題，而非應用程式故障。

3. 若要針對未來的 Pod 重新啟動事件設定警示，請點選「IBM Cloud Monitoring」使用者介面中的「警示」圖示，並針對「kubernetes.pod.restart.count」指標建立指標警示。 將閾值設定為：當任何 Pod 在五分鐘內重啟次數超過兩次時，即觸發此閾值。 這能在崩潰迴圈造成干擾之前提供預警。 如需有關設定警示的更多資訊，請參閱 《設定 IBM Cloud® Monitoring 警示》

使用 來檢視容器日誌 IBM Cloud Logs

當 Pod 重新啟動或節點發生問題時，檢視容器日誌對於釐清根本原因至關重要。IBM Cloud Logs 會保留歷史日誌資料，而這些資料在容器重新啟動後，將無法透過 oc logs 取得。

1. 開啟 IBM Cloud Logs 儀表板。

   1. 在 IBM Cloud 控制台中，導航至您的叢集資源頁面，並點擊相關的叢集。
   2. 在「整合」下，找到「記錄」選項，然後點擊「啟動」。 IBM Cloud Logs 的使用者介面將在新視窗中開啟。

2. 請將時間範圍設定為涵蓋問題發生時的期間。 如果問題仍在持續，請將範圍設定為過去一小時。 若您正在調查過去發生的事件，請設定具體的開始與結束時間，以縮小搜尋結果範圍。

3. 搜尋受影響的 Pod 或命名空間。 請使用介面頂端的查詢欄來篩選日誌。 例如，若要顯示 default 命名空間中所有 Pod 的日誌，請輸入以下查詢：

   kubernetes.namespace_name:"default"
   

   若要根據名稱將結果篩選至特定 Pod，請使用：

   kubernetes.pod_name:"MY_POD_NAME"
   

4. 檢視日誌條目中是否含有錯誤級別的記錄。 請留意以下任何一種模式，這些模式通常預示著常見的故障模式：

   • OOMKilled 或 out of memory — 容器超出記憶體限制，並被核心終止。
   • CrashLoopBackOff — 容器不斷重新啟動，通常是因啟動時發生應用程式錯誤所致。
   • failed to pull image 或 ImagePullBackOff — 節點無法從註冊表拉取容器映像。
   • Connection refused 或 context deadline exceeded — 應用程式無法連線至依賴的服務或 Kubernetes API 伺服器。

5. 若發現與 OOM 相關的日誌條目，請記錄其時間戳記，並查看 IBM Cloud Monitoring Kubernetes > Pods 儀表板中同一時間區間的資料，以確認該 Pod 在重新啟動前夕是否已達到記憶體使用上限。

請透過以下連結查看 Kubernetes 的活動：IBM Cloud Logs

Kubernetes 這些事件會記錄重要的叢集活動，例如 Pod 排程失敗、節點狀態以及儲存卷掛載錯誤。IBM Cloud Logs 會自動擷取這些事件，並讓您針對歷史紀錄進行搜尋和篩選——這與 oc get events 不同，後者僅顯示當前會話中的近期事件。

1. 在 IBM Cloud Logs 使用者介面中，請使用以下查詢來顯示整個叢集中的所有 Kubernetes 警示事件：

   kubernetes.event.type:"Warning"
   

2. 若要將事件篩選至特定的工作節點，請將該節點名稱加入查詢中。 請將 NODE_NAME 替換為受影響節點的名稱：

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

3. 請檢視事件日誌條目中的「原因」欄位。 以下原因對於除錯工作節點和工作負載問題最為相關：

NodeNotReady

該節點回報發生「NotReady」狀態。 此事件通常發生在工作節點進入「Critical」狀態之前，或與之同時發生。

OOMKilling

由於記憶體耗盡，核心終止了該節點上的某個程序。

FailedScheduling

排程器無法將該 Pod 配置到任何可用的節點上。 訊息欄位通常會說明原因，例如 CPU 資源不足、記憶體不足，或是節點選擇器不匹配。

BackOff

某個容器陷入了死循環。 每當 kubelet 在重新啟動容器之前進行回退時，都會觸發此事件。

FailedMount 或 FailedAttachVolume

無法將持久性卷掛載或附加至 Pod，導致該 Pod 無法啟動。

1. 對於任何看似相關的事件，請記錄 involvedObject.name 和 involvedObject.namespace 的數值，並將其與您在前幾節中收集的日誌和指標資料進行關聯分析。

下一步

• 若您發現某個工作節點面臨資源壓力，請考慮 重新載入或更換該工作節點，或是調整該節點上所運行之 Pod 的資源請求與限制。
• 如果因 OOM 終止導致 pod 陷入崩潰循環，請提高受影響容器的記憶體限制，或將記憶體密集型工作負載移至具有更大節點的工作者彙集。
• 如果日誌顯示映像檔拉取失敗，請檢查您的 映像檔拉取密鑰，並確認工作節點能否連接到容器註冊表。
• 若遇到無法透過此處蒐集的資訊解決的問題，請參閱 《 為支援案件蒐集資料 》，以收集開啟支援單所需的資訊。

相關鏈結

• 監控叢集狀態
• 開始使用 IBM Cloud Monitoring
• 開始使用 IBM Cloud Logs
• 針對處於「Critical」或「NotReady」狀態的工作節點進行疑難排解
• 設定 IBM Cloud® Monitoring 通知