綜合應用範例：疑難排解情境

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

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

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

應用情境

您是值班工程師，負責維護在 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」狀態欄。您會看到值穩定顯示不良狀態：2/3，而非良好的 3/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 區段會顯示 Warning: BackOff 事件，並附上 Back-off restarting failed container 訊息。這則訊息確認容器處於失敗迴圈，這也是您先前看到 CrashLoopBackOff 狀態的直接原因。

透過指標呈現行為

kubectl describe 指令會顯示發生的事件，但 Cloud Monitoring 可顯示環境在一段時間內的行為。

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

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

在記錄中找出根本原因

您現在知道容器記憶體不足，但仍不清楚確切原因。如要找出根本原因，請使用 Logs Explorer。

  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 值)。

後續步驟