GKE 疑難排解簡介

本頁面將介紹 Google Kubernetes Engine (GKE) 的基本疑難排解技巧。本頁內容適合剛開始使用 Kubernetes 和 GKE 的使用者，瞭解如何有效排解疑難。

本頁面概述下列工具和技術，可協助您監控、診斷及解決 GKE 問題：

• 在 Google Cloud 控制台中查看叢集和工作負載健康狀態：取得高階總覽，快速找出叢集和應用程式的潛在問題。
• 使用 kubectl 指令列工具調查叢集狀態：使用這些指令查看節點和 Pod 等資源的即時狀態。
• 使用 Cloud Logging 進行歷來分析：查詢歷來記錄資料並檢查事件，找出失敗的根本原因。
• 使用 Cloud Monitoring 進行主動監控：追蹤一段時間內的效能指標、以視覺化方式呈現趨勢，以及建立快訊，以便在問題影響使用者前偵測並解決。
• 運用 Gemini Cloud Assist 加速診斷：分析複雜的錯誤訊息、取得逐步排解問題的指引，以及自動調查問題。
• 整合運用：疑難排解情境範例：透過逐步導覽，瞭解如何整合運用這些工具，診斷及解決常見的實際應用程式故障問題。

瞭解核心概念

如果您是 Kubernetes 和 GKE 的新手，請務必先瞭解叢集架構、Pod 和節點之間的關係等核心概念，再開始排解問題。如要瞭解詳情，請參閱「開始瞭解 GKE」。

此外，瞭解您負責維護的 GKE 部分，以及 Google 負責維護的部分，也很有幫助。 Google Cloud 詳情請參閱「GKE 共同責任」。

在 Google Cloud 控制台中查看叢集和工作負載健康狀態

Google Cloud 控制台是開始排解問題的好地方，因為您可以快速查看叢集和工作負載的健康狀態。叢集健康狀態是指節點和網路等基礎 GKE 基礎架構的健康狀態，而工作負載健康狀態是指叢集上執行的應用程式狀態和效能。

以下各節說明叢集和工作負載頁面。為全面掌握應用程式的健康狀態， Google Cloud 管理中心也提供強大的記錄和監控工具，方便您調查過去的失敗原因，並主動防範日後發生類似問題。如要進一步瞭解這些工具，請參閱「使用 Cloud Logging 進行歷史資料分析」和「使用 Cloud Monitoring 執行主動式監控」一節。

找出叢集問題

「Kubernetes clusters」(Kubernetes 叢集) 頁面會顯示叢集健康狀態總覽。如要找出叢集問題，請從這個頁面開始。

• 如要開始使用，請在 Google Cloud 控制台中前往「Kubernetes clusters」(Kubernetes 叢集) 頁面。

  前往 Kubernetes 叢集

以下列舉幾個例子，說明如何運用這個頁面排解問題：

• 如需改善叢集健康狀態、升級策略和成本最佳化的建議，請按一下「查看建議」。
• 如要找出不良叢集，請查看「狀態」欄。如果叢集沒有綠色勾號，就表示需要處理。
• 如要查看潛在問題，請檢查「通知」欄。按一下任何通知訊息即可查看詳細資訊。

調查特定叢集

發現叢集有問題後，請前往叢集的「詳細資料」頁面，查看深入資訊，協助您排解叢集問題並瞭解叢集設定。

如要前往叢集的「詳細資料」頁面，請按照下列步驟操作：

1. 前往「Kubernetes clusters」(Kubernetes 叢集) 頁面。

   前往 Kubernetes 叢集

2. 查看「名稱」欄，然後按一下要調查的叢集名稱。

以下舉例說明如何使用叢集「詳細資料」頁面排解叢集問題：

• 如要進行一般健康檢查，請嘗試下列選項：

  • 如要查看叢集層級的資訊主頁，請前往「Observability」(可觀測性) 分頁。根據預設，GKE 會在您建立叢集時啟用 Cloud Monitoring。啟用 Cloud Monitoring 後，GKE 會自動設定這個頁面上的資訊主頁。以下是幾個可能對疑難排解最有幫助的檢視畫面：

    • 總覽：查看叢集健康狀態、資源使用率和重要事件的摘要。這個資訊主頁可協助您快速評估叢集的整體狀態，並找出潛在問題。
    • 流量指標：查看以節點為基礎的網路指標，深入瞭解 Kubernetes 工作負載之間的流量。
    • 工作負載狀態：查看 Deployment、Pod 和容器的狀態。找出失敗或健康狀態不良的執行個體，並偵測資源限制。

    • 控制層：查看控制層的健康狀態和效能。 您可以在這個資訊主頁中監控元件的主要指標，例如 kube-apiserver 和 etcd，找出效能瓶頸，並偵測元件故障。

  • 如要查看最近的應用程式錯誤，請前往「應用程式錯誤」分頁。這個分頁的資訊會顯示錯誤發生次數、首次出現時間和上次發生時間，有助您排定錯誤解決優先順序。

    如要進一步調查錯誤，請按一下錯誤訊息，查看詳細錯誤報告，包括相關記錄的連結。

• 如果在最近升級或變更後排解問題，請查看叢集「詳細資料」分頁中的「叢集基本資訊」部分。確認「版本」欄位中列出的版本是否符合預期。如要進一步調查，請按一下「升級」部分中的「顯示升級記錄」。

• 如果您使用的是標準叢集，且 Pod 停滯在 Pending 狀態，或您懷疑節點過度負載，請檢查「節點」分頁。由於 GKE 會代管節點，因此 Autopilot 叢集無法使用「節點」分頁。

  • 在「節點集區」部分，確認自動調整功能已正確設定，且機器類型適合工作負載。
  • 在「節點」部分中，找出狀態不是 Ready 的節點。NotReady 狀態表示節點本身有問題，例如資源壓力或 kubelet 問題 (kubelet 是在每個節點上執行的代理程式，用於管理容器)。

找出工作負載問題

如果懷疑特定應用程式有問題 (例如部署失敗)，請前往 Google Cloud 控制台的「Workloads」頁面。這個頁面會集中顯示叢集中執行的所有應用程式。

• 如要開始使用，請前往 Google Cloud 控制台的「Workloads」(工作負載) 頁面。

  前往「Workloads」(工作負載)

以下列舉幾個例子，說明如何運用這個頁面排解問題：

• 如要找出不正常的作業負載，請查看「狀態」欄。凡是沒有綠色勾號的工作負載，都需要特別留意。
• 如果應用程式沒有回應，請查看「Pod」欄。舉例來說，如果狀態為 1/3，表示只有一個應用程式副本正在執行，這代表有問題。

調查特定工作負載

從總覽中找出有問題的工作負載後，請探索工作負載的「詳細資料」頁面，開始找出根本原因。

如要前往工作負載的「詳細資料」頁面，請按照下列步驟操作：

1. 前往「Workloads」(工作負載) 頁面。

   前往「Workloads」(工作負載)

2. 查看「Name」(名稱) 欄，然後點選要調查的工作負載名稱。

以下舉例說明如何使用工作負載「詳細資料」頁面排解工作負載問題：

• 如要檢查工作負載的設定，請使用工作負載的「總覽」和「詳細資料」分頁。您可以運用這項資訊驗證事件，例如是否已部署正確的容器映像檔標記，或檢查工作負載的資源要求和限制。

• 如要找出導致當機的特定 Pod 名稱，請前往「Managed Pods」部分。您可能需要這項資訊才能執行 kubectl 指令。這個部分會列出工作負載控管的所有 Pod，以及這些 Pod 的狀態。如要查看工作負載的近期變更記錄，請前往「修訂版本記錄」分頁。如果您在新的部署作業後發現效能問題，請使用本節內容找出目前使用的修訂版本。然後比較目前修訂版本與先前的設定，找出問題來源。如果沒有看到這個分頁，表示工作負載的類型不使用修訂版本，或是尚未更新。

• 如果部署作業似乎失敗，請前往「Events」(事件) 分頁。這個頁面通常是資訊價值最高的來源，因為會顯示 Kubernetes 層級的事件。

• 如要查看應用程式的記錄檔，請按一下「記錄」分頁標籤。本頁面可協助您瞭解叢集內發生的情況。這裡會顯示錯誤訊息和堆疊追蹤記錄，可協助您診斷問題。

• 如要確認部署的內容，請查看「YAML」YAML分頁。這個頁面會顯示叢集上工作負載的即時 YAML 資訊清單。這項資訊有助於找出與來源控制資訊清單的差異。如果您正在查看單一 Pod 的 YAML 資訊清單，這個分頁也會顯示 Pod 的狀態，提供 Pod 層級的失敗深入分析。

使用 kubectl 指令列工具調查叢集狀態

雖然 Google Cloud 控制台可協助您瞭解是否發生問題，但 kubectl 命令行工具對於找出原因至關重要。kubectl 指令列工具可直接與 Kubernetes 控制層通訊，讓您收集所需詳細資訊，排解 GKE 環境問題。

下列各節將介紹一些重要指令，這些指令是 GKE 疑難排解的強大起點。

事前準備

開始之前，請先執行下列工作：

• 安裝 kubectl。

• 設定 kubectl 指令列工具，與叢集通訊：

  gcloud container clusters get-credentials CLUSTER_NAME \
      --location=LOCATION
  

  更改下列內容：

  • CLUSTER_NAME：叢集名稱。
  • LOCATION：叢集控制層的 Compute Engine位置。為區域叢集提供區域，或為區域叢集提供可用區。

• 檢查權限。如要查看您是否具備執行 kubectl 指令的必要權限，請使用 kubectl auth can-i 指令。舉例來說，如要查看您是否有權執行 kubectl get nodes，請執行 kubectl auth can-i get nodes 指令。

  如果您具備必要權限，指令會傳回 yes；否則，指令會傳回 no。

  如果沒有執行 kubectl 指令的權限，可能會看到類似下列內容的錯誤訊息：

  Error from server (Forbidden): pods "POD_NAME" is forbidden: User
  "USERNAME@DOMAIN.com" cannot list resource "pods" in API group "" in the
  namespace "default"
  

  如果您沒有必要權限，請要求叢集管理員指派必要角色。

查看目前執行的項目

kubectl get 指令可協助您查看叢集中的整體動態。使用下列指令查看兩個最重要的叢集元件 (節點和 Pod) 的狀態：

1. 如要檢查節點是否正常運作，請查看所有節點及其狀態的詳細資料：

   kubectl get nodes
   

   輸出結果會與下列內容相似：

   NAME                                        STATUS   ROLES    AGE     VERSION
   
   gke-cs-cluster-default-pool-8b8a777f-224a   Ready    <none>   4d23h   v1.32.3-gke.1785003
   gke-cs-cluster-default-pool-8b8a777f-egb2   Ready    <none>   4d22h   v1.32.3-gke.1785003
   gke-cs-cluster-default-pool-8b8a777f-p5bn   Ready    <none>   4d22h   v1.32.3-gke.1785003
   

   如果狀態不是 Ready，則需要進一步調查。

2. 如要檢查 Pod 是否正常運作，請查看所有 Pod 的詳細資料和狀態：

   kubectl get pods --all-namespaces
   

   輸出結果會與下列內容相似：

   NAMESPACE   NAME       READY   STATUS      RESTARTS   AGE
   kube-system netd-6nbsq 3/3     Running     0          4d23h
   kube-system netd-g7tpl 3/3     Running     0          4d23h
   

   如果狀態不是 Running，則需要進一步調查。以下列出常見的狀態：

   • Running：正常運作狀態。
   • Pending：Pod 正在等待排程到節點上。
   • CrashLoopBackOff：Pod 中的容器不斷在迴圈中當機，因為應用程式啟動後會因錯誤而結束，然後由 Kubernetes 重新啟動。
   • ImagePullBackOff：Pod 無法提取容器映像檔。

上述指令只是使用 kubectl get 指令的兩個範例。您也可以使用這項指令，進一步瞭解許多類型的 Kubernetes 資源。如需可探索的資源完整清單，請參閱 Kubernetes 說明文件中的 kubectl get。

進一步瞭解特定資源

找出問題後，您需要取得更多詳細資料。舉例來說，如果 Pod 的狀態不是 Running，就可能發生問題。如要取得更多詳細資料，請使用 kubectl describe 指令。

舉例來說，如要說明特定 Pod，請執行下列指令：

kubectl describe pod POD_NAME -n NAMESPACE_NAME

更改下列內容：

• POD_NAME：發生問題的 Pod 名稱。
• NAMESPACE_NAME：Pod 所在的命名空間。如果不確定命名空間為何，請查看 kubectl get pods 指令輸出內容中的 Namespace 欄。

kubectl describe 指令的輸出內容包含資源的詳細資訊。以下是排解 Pod 問題時，最實用的幾個部分：

• Status：Pod 的目前狀態。
• Conditions：Pod 的整體健康狀態和完備程度。
• Restart Count：Pod 中的容器重新啟動次數。如果數字偏高，可能需要留意。
• Events：記錄這個 Pod 發生過的重要事項，例如排定至節點、提取容器映像檔，以及是否發生任何錯誤。通常可以在 Events 專區中，直接找到 Pod 失敗的原因。

與 kubectl get 指令類似，您可以使用 kubectl describe 指令進一步瞭解多種資源。如需可探索的資源完整清單，請參閱 Kubernetes 說明文件中的 kubectl describe。

使用 Cloud Logging 進行歷史分析

雖然 kubectl 指令列工具對於檢查 Kubernetes 物件的即時狀態非常寶貴，但其檢視畫面通常僅限於當下。如要瞭解問題的根本原因，通常需要調查一段時間內發生的情況。如需這類歷史記錄，請使用 Cloud Logging。

Cloud Logging 會匯總來自 GKE 叢集、容器化應用程式和其他 Google Cloud 服務的記錄。

瞭解用於疑難排解的主要記錄類型

Cloud Logging 會自動收集多種 GKE 記錄，協助您排解問題：

• 節點和執行階段記錄 (kubelet、containerd)：來自基礎節點服務的記錄。由於 kubelet 會管理節點上所有 Pod 的生命週期，因此其記錄檔對於排解容器啟動、記憶體不足 (OOM) 事件、探測失敗和磁碟區掛接錯誤等問題至關重要。這些記錄檔對於診斷節點層級問題 (例如狀態為 NotReady 的節點) 也至關重要。

  由於 containerd 會管理容器的生命週期 (包括提取映像檔)，因此在 kubelet 啟動容器前發生的問題，都必須透過 containerd 記錄進行疑難排解。containerd 記錄會記錄容器執行階段的特定活動和潛在錯誤，有助於診斷 GKE 中的節點層級問題。

• 應用程式記錄 (stdout、stderr)：來自容器化程序的標準輸出和錯誤串流。這些記錄檔對於偵錯應用程式專屬問題 (例如當機、錯誤或非預期行為) 至關重要。

• 稽核記錄：這些記錄會回答叢集「人事時地物」的問題。這些記錄會追蹤對 Kubernetes API 伺服器執行的管理動作和 API 呼叫，有助於診斷因設定變更或未經授權存取而造成的問題。

常見的疑難排解情境

找出問題後，您可以查詢這些記錄，瞭解發生了什麼事。為協助您開始使用，查看記錄可幫助您解決下列問題：

• 如果節點的狀態為 NotReady，請查看節點記錄。kubelet 和 containerd 記錄通常會揭露根本原因，例如網路問題或資源限制。
• 如果新節點無法佈建及加入叢集，請查看節點的序列埠記錄。這些記錄檔會擷取節點記錄代理程式完全啟動前的早期啟動和 kubelet 啟動活動。
• 如果 Pod 過去無法啟動，請查看該 Pod 的應用程式記錄檔，確認是否發生當機。如果記錄檔為空白或無法排定 Pod，請檢查稽核記錄檔是否有相關事件，或檢查目標節點上的節點記錄檔，找出資源壓力或映像檔提取錯誤的線索。
• 如果刪除了重要部署作業，但無人知道原因，請查詢管理員活動稽核記錄。這些記錄可協助您找出發出刪除 API 呼叫的使用者或服務帳戶，為調查作業提供明確的起點。

如何存取記錄檔

使用記錄檔探索工具，在 Google Cloud 控制台中查詢、查看及分析 GKE 記錄。Logs Explorer 提供強大的篩選選項，可協助您找出問題。

如要存取及使用 Logs Explorer，請完成下列步驟：

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

   前往記錄檔探索工具

2. 在查詢窗格中輸入查詢。使用 Logging 查詢語言撰寫指定查詢。以下是一些常見的篩選器，可協助你快速上手：

   篩選器類型	說明	範例值
   resource.type	Kubernetes 資源類型。	k8s_cluster、k8s_node、k8s_pod、k8s_container
   log_id	資源的記錄串流。	stdout、stderr
   resource.labels.RESOURCE_TYPE.name	篩選特定名稱的資源。 將 RESOURCE_TYPE 替換為要查詢的資源名稱。例如 namespace 或 pod。	example-namespace-name、example-pod-name
   severity	記錄嚴重性等級。	DEFAULT、INFO、WARNING、ERROR、CRITICAL
   jsonPayload.message=~	在記錄訊息中搜尋文字的規則運算式。	scale.down.error.failed.to.delete.node.min.size.reached

   舉例來說，如要排解特定 Pod 的問題，您可能需要隔離其錯誤記錄。如要只查看該 Pod 的 ERROR 嚴重性記錄，請使用下列查詢：

   resource.type="k8s_container"
   resource.labels.pod_name="POD_NAME"
   resource.labels.namespace_name="NAMESPACE_NAME"
   severity=ERROR
   

   更改下列內容：

   • POD_NAME：發生問題的 Pod 名稱。
   • NAMESPACE_NAME：Pod 所在的命名空間。如果不確定命名空間為何，請查看 kubectl get pods 指令輸出內容中的 Namespace 欄。

   如需更多範例，請參閱 Google Cloud Observability 說明文件中的「Kubernetes 相關查詢」。

3. 點選「執行查詢」

4. 如要查看完整記錄訊息，包括 JSON 酬載、中繼資料和時間戳記，請按一下記錄項目。

如要進一步瞭解 GKE 記錄檔，請參閱「關於 GKE 記錄檔」。

使用 Cloud Monitoring 執行主動監控

發生問題後，查看記錄是排解問題的重要步驟。 不過，要打造真正具備復原能力的系統，也需要採取主動式做法，在問題導致服務中斷前找出問題。

如要主動找出未來問題，並追蹤重要成效指標的變化，請使用 Cloud Monitoring。Cloud Monitoring 提供資訊主頁、指標和警告功能。這些工具可協助您找出錯誤率上升、延遲時間增加或資源限制等問題，以便在使用者受到影響前採取行動。

查看實用指標

GKE 會自動將一組指標傳送至 Cloud Monitoring。以下各節列出一些最重要的疑難排解指標：

• 容器成效和健康指標
• 節點效能和健康狀態指標
• Pod 成效和健康指標

如需完整的 GKE 指標清單，請參閱 GKE 系統指標。

容器效能和健康狀態指標

懷疑特定應用程式有問題時，請先查看這些指標。這些指標可協助您監控應用程式的健康狀態，包括發現容器是否經常重新啟動、記憶體不足，或因 CPU 限制而受到節流。

節點效能和健康指標

需要診斷基礎 GKE 基礎架構的問題時，請檢查這些指標。這些指標對於瞭解節點的整體健康狀態和容量至關重要，可協助您調查節點是否不健康或處於壓力狀態，或是節點是否有足夠的記憶體來排定新 Pod 的時間。

Pod 成效和健康指標

這些指標可協助您排解 Pod 與環境互動相關的問題，例如網路和儲存空間。當您需要診斷啟動緩慢的 Pod、調查潛在的網路連線問題，或主動管理儲存空間，以防止磁碟區空間不足導致寫入失敗時，請使用這些指標。

使用 Metrics Explorer 製作指標圖表

如要以圖表呈現 GKE 環境的狀態，請使用 Metrics Explorer 根據指標建立圖表。

如要使用 Metrics Explorer，請完成下列步驟：

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

   前往 Metrics Explorer

2. 在「指標」欄位中，選取或輸入要檢查的指標。

3. 查看結果，並觀察長期趨勢。

舉例來說，如要調查特定命名空間中 Pod 的記憶體用量，可以執行下列操作：

1. 在「選取指標」清單中，選擇指標 kubernetes.io/container/memory/used_bytes，然後按一下「套用」。
2. 按一下「新增篩選器」，然後選取「namespace_name」。
3. 在「Value」(值) 清單中，選取要調查的命名空間。
4. 在「Aggregation」(匯總) 欄位中，依序選取「Sum」(總和) >「pod_name」(Pod 名稱)，然後按一下「OK」(確定)。這項設定會為每個 Pod 顯示個別的時間序列線。
5. 按一下「儲存圖表」。

產生的圖表會顯示每個 Pod 的記憶體用量，協助您找出記憶體用量異常偏高或突然飆升的 Pod。

您可以透過 Metrics Explorer，彈性建構要查看的指標。如要進一步瞭解 Metrics Explorer 進階選項，請參閱 Cloud Monitoring 說明文件的「使用 Metrics Explorer 建立圖表」一文。

建立快訊，主動偵測問題

如要在發生錯誤或指標超出特定門檻時收到通知，請在 Cloud Monitoring 中設定快訊政策。

舉例來說，如要設定快訊政策，在容器 CPU 限制超過 80% 達五分鐘時通知您，請按照下列步驟操作：

1. 前往 Google Cloud 控制台的「Alerting」(警告) 頁面。

   前往「Alerting」(快訊)

2. 按一下「建立政策」。

3. 在「選取指標」方塊中，篩選 CPU limit utilization，然後選取下列指標： kubernetes.io/container/cpu/limit_utilization。

4. 按一下 [套用]。

5. 將「新增篩選器」欄位留空。如有任何叢集違反門檻，這項設定就會觸發快訊。

6. 在「轉換資料」部分執行下列操作：

   1. 在「Rolling window」(滾動週期) 清單中，選取「1 minute」(1 分鐘)。這項設定表示 Google Cloud 每分鐘會計算平均值。

   2. 在「Rolling window function」(滾動週期函式) 清單中，選取「mean」(平均值)。

      這兩項設定都會每分鐘計算每個容器的平均 CPU 限制使用率。

7. 點選「下一步」。

8. 在「設定快訊」部分，執行下列操作：

   1. 在「條件類型」部分選取「門檻」。
   2. 針對「Alert trigger」(快訊觸發條件)，選取「Any time series violates」(任何時間序列違反條件時)。
   3. 在「Threshold position」(門檻位置) 中選取「Above threshold」(高於門檻)。
   4. 在「Threshold value」(門檻值) 中輸入 0.8。這個值代表您要監控的 80% 門檻。
   5. 點選「進階選項」。
   6. 在「Retest window」(重新測試時間範圍) 清單中，選取「5 min」(5 分鐘)。這項設定表示 CPU 使用率必須連續五分鐘超過 80%，才會觸發快訊，可減少短暫尖峰造成的誤報。
   7. 在「條件名稱」欄位中，為條件取個清楚易懂的名稱。
   8. 點選「下一步」。

9. 在「設定通知並完成快訊」部分，執行下列操作：

   1. 在「Notification channels」(通知管道) 清單中，選取要接收快訊的管道。如果沒有管道，請按一下「管理通知管道」建立管道。
   2. 在「為快訊政策命名」欄位中，為政策取個清楚易懂的名稱。
   3. 所有其他欄位則保留預設值。
   4. 點選「下一步」。

10. 檢查政策，確認一切正確無誤後，按一下「建立政策」。

如要瞭解建立快訊的其他方式，請參閱 Cloud Monitoring 說明文件中的「快訊總覽」。

透過 Gemini Cloud Assist 加速診斷

有時即使使用前幾節討論的工具，問題原因也不會立即顯現。調查複雜案件可能需要耗費大量時間，且需要深入的專業知識。在這種情況下，Gemini Cloud Assist 就能派上用場。這項功能可自動偵測隱藏模式、找出異常狀況，並提供摘要，協助您快速找出可能原因。

存取 Gemini Cloud Assist

如要存取 Gemini Cloud Assist，請完成下列步驟：

1. 前往 Google Cloud 控制台的任何頁面。

2. 在 Google Cloud 控制台工具列，點選 spark「Open or close Gemini Cloud Assist chat」。

   「Cloud Assist」面板隨即開啟。如果系統顯示範例提示，您可以點選，也可以在「輸入提示」欄位中輸入提示。

查看範例提示

如要瞭解 Gemini Cloud Assist 如何提供協助，請參考下列提示範例：

詳情請參閱下列資源：

• 瞭解如何撰寫更優質的提示。
• 瞭解如何使用 Gemini Cloud Assist 面板。
• 閱讀 Gemini for Google Cloud 總覽。
• 瞭解 Gemini for Google Cloud 如何使用您的資料。

使用 Gemini Cloud Assist Investigations

除了互動式對話，Gemini Cloud Assist 還能透過 Gemini Cloud Assist Investigations 執行更深入的自動分析。這項功能直接整合至記錄檔總管等工作流程，是強大的根本原因分析工具。

從錯誤或特定資源啟動調查時，Gemini Cloud Assist 會分析記錄、設定和指標。系統會使用這項資料，產生可能根本原因的排序觀察結果和假設，然後提供建議的後續步驟。您也可以將這些結果轉移至 Google Cloud 支援案件，提供有價值的背景資訊，協助您更快解決問題。

詳情請參閱 Gemini 說明文件中的「Gemini Cloud Assist Investigations」。

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

本範例說明如何使用 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 控制台的「指標探索器」。
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 頻道，取得更多社群支援。
  • 使用公開問題追蹤工具回報錯誤或提出功能要求。