整合所有項目：排解問題情境範例

自動駕駛 標準

---

瞭解 Google Kubernetes Engine (GKE) 的個別疑難排解工具很有幫助，但如果能看到這些工具如何共同解決實際問題，將有助於鞏固您的知識。

按照導覽範例操作，瞭解如何同時使用 Google Cloud 控制台、kubectl 指令列工具、Cloud Logging 和 Cloud Monitoring，找出 OutOfMemory (OOMKilled) 錯誤的根本原因。

這個範例適合想瞭解本系列文章所述疑難排解技術實際應用方式的讀者，尤其是平台管理員和營運人員，以及應用程式開發人員。如要進一步瞭解我們在Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。

情境

您是負責在 GKE 中執行的網頁應用程式「product-catalog」的待命工程師。

當您收到 Cloud Monitoring 的自動快訊時，調查就會開始：

Alert: High memory utilization for container 'product-catalog' in 'prod' cluster.

這則快訊表示發生問題，且問題與 product-catalog 工作負載有關。

在 Google Cloud 控制台中確認問題

首先，您會查看工作負載的高層級檢視畫面，確認問題。

1. 在 Google Cloud 控制台中，前往「Workloads」(工作負載) 頁面，然後篩選 product-catalog 工作負載。
2. 查看「Pod」狀態欄。而不是正常的 3/3， 而是持續顯示不良狀態：2/3。這個值表示應用程式的其中一個 Pod 狀態不是 Ready。
3. 您想進一步調查，因此按一下工作負載的名稱 product-catalog，前往詳細資料頁面。
4. 在詳細資料頁面中，查看「受管理 Pod」部分。您立即發現問題：Pod 的 Restarts 欄顯示 14，這個數字異常高。

如果重新啟動次數過多，表示問題導致應用程式不穩定，且容器健康狀態檢查失敗或當機。

使用 kubectl 指令找出原因

現在您知道應用程式會不斷重新啟動，因此需要找出原因。kubectl describe 指令是這項作業的實用工具。

1. 您會取得不穩定 Pod 的確切名稱：

   kubectl get pods -n prod
   

   輸出內容如下：

   NAME                             READY  STATUS            RESTARTS  AGE
   product-catalog-d84857dcf-g7v2x  0/1    CrashLoopBackOff  14        25m
   product-catalog-d84857dcf-lq8m4  1/1    Running           0         2h30m
   product-catalog-d84857dcf-wz9p1  1/1    Running           0         2h30m
   

2. 您描述不穩定的 Pod，即可取得詳細的事件記錄：

   kubectl describe pod product-catalog-d84857dcf-g7v2x -n prod
   

3. 您查看輸出內容，並在 Last State 和 Events 區段中找到線索：

   Containers:
     product-catalog-api:
       ...
       State:          Waiting
         Reason:       CrashLoopBackOff
       Last State:     Terminated
         Reason:       OOMKilled
         Exit Code:    137
         Started:      Mon, 23 Jun 2025 10:50:15 -0700
         Finished:     Mon, 23 Jun 2025 10:54:58 -0700
       Ready:          False
       Restart Count:  14
   ...
   Events:
     Type     Reason     Age                           From                Message
     ----     ------     ----                          ----                -------
     Normal   Scheduled  25m                           default-scheduler   Successfully assigned prod/product-catalog-d84857dcf-g7v2x to gke-cs-cluster-default-pool-8b8a777f-224a
     Normal   Pulled     8m (x14 over 25m)             kubelet             Container image "us-central1-docker.pkg.dev/my-project/product-catalog/api:v1.2" already present on machine
     Normal   Created    8m (x14 over 25m)             kubelet             Created container product-catalog-api
     Normal   Started    8m (x14 over 25m)             kubelet             Started container product-catalog-api
     Warning  BackOff    3m (x68 over 22m)             kubelet             Back-off restarting failed container
   

   輸出內容會提供兩項重要線索：

   • 首先，Last State 部分顯示容器已終止，並出現 Reason: OOMKilled，表示記憶體不足。Exit Code: 137 是標準的 Linux 結束代碼，表示程序因記憶體用量過高而遭終止，因此可確認這個原因。
   • 其次，Events 區段會顯示含有訊息 Back-off restarting failed container 的 Warning: BackOff 事件。這則訊息確認容器處於失敗迴圈，這也是您先前看到 CrashLoopBackOff 狀態的直接原因。

使用指標將行為視覺化

kubectl describe 指令會告訴您發生了什麼事，但 Cloud Monitoring 可以顯示環境在一段時間內的行為。

1. 前往 Google Cloud 控制台的「Metrics Explorer」。
2. 選取 container/memory/used_bytes 指標。
3. 將輸出內容篩選至特定叢集、命名空間和 Pod 名稱。

圖表顯示明顯的模式：記憶體用量穩定攀升，然後在容器因記憶體不足而遭終止並重新啟動時，突然降至零。這項視覺證據可確認是記憶體外洩或記憶體限制不足。

在記錄中找出根本原因

您現在知道容器的記憶體即將用盡，但仍不清楚確切原因。如要找出根本原因，請使用記錄檔探索工具。

1. 前往 Google Cloud 控制台的「Logs Explorer」頁面。

2. 您編寫查詢，從上次當機時間 (您在 kubectl describe 指令的輸出內容中看到) 之前，篩選特定容器的記錄：

   resource.type="k8s_container"
   resource.labels.cluster_name="example-cluster"
   resource.labels.namespace_name="prod"
   resource.labels.pod_name="product-catalog-d84857dcf-g7v2x"
   timestamp >= "2025-06-23T17:50:00Z"
   timestamp < "2025-06-23T17:55:00Z"
   

3. 在記錄中，您會發現每次發生當機前，都會出現重複的訊息模式：

   {
     "message": "Processing large image file product-image-large.jpg",
     "severity": "INFO"
   },
   {
     "message": "WARN: Memory cache size now at 248MB, nearing limit.",
     "severity": "WARNING"
   }
   

這些記錄項目表示應用程式嘗試將大型圖片檔案完整載入記憶體，導致容器的記憶體用盡。

調查結果

結合使用這些工具，即可全面瞭解問題：

• 監控快訊通知你發生問題。
• 控制台顯示問題影響使用者 (重新啟動)。 Google Cloud
• kubectl 指令找出重新啟動的確切原因 (OOMKilled)。
• Metrics Explorer 會以視覺化方式呈現一段時間內的記憶體洩漏模式。
• Logs Explorer 顯示造成記憶體問題的特定行為。

您現在可以開始導入解決方案。您可以選擇最佳化應用程式程式碼，更有效率地處理大型檔案，也可以暫時提高工作負載 YAML 資訊清單中容器的記憶體上限 (具體來說，就是 spec.containers.resources.limits.memory 值)。

後續步驟

• 如需解決特定問題的建議，請參閱 GKE 的疑難排解指南。

• 如果無法在說明文件中找到問題的解決方法，請參閱「取得支援」一文，尋求進一步的協助， 包括下列主題的建議：

  • 與 Cloud 客戶服務聯絡，建立支援案件。
  • 在 StackOverflow 上提問，並使用 google-kubernetes-engine 標記搜尋類似問題，向社群尋求支援。你也可以加入 #kubernetes-engine Slack 頻道，取得更多社群支援。
  • 使用公開問題追蹤工具回報錯誤或提出功能要求。