在問題發生後才採取行動,可能會導致停機。如要在 Google Kubernetes Engine (GKE) 中維持彈性系統,您需要在潛在問題影響使用者之前找出問題。
您可以在這個頁面使用 Cloud Monitoring 追蹤主要成效指標、以圖表呈現趨勢,以及設定快訊來偵測錯誤率上升或資源限制等問題,主動監控 GKE 環境。
這項資訊對平台管理員和作業人員來說非常重要,有助於確保 GKE 環境的健康狀態、可靠性和效率。此外,應用程式開發人員也能藉此瞭解應用程式在實際環境中的效能、偵測部署作業的迴歸情形,並取得最佳化洞察資料。如要進一步瞭解我們在 Google Cloud 內容中提及的常見角色和範例工作,請參閱「常見的 GKE 使用者角色和工作」。
查看實用指標
GKE 會自動將一組指標傳送至 Cloud Monitoring。以下各節列出一些最重要的疑難排解指標:
如需完整的 GKE 指標清單,請參閱 GKE 系統指標。
容器效能和健康狀態指標
懷疑特定應用程式有問題時,請先查看這些指標。這些指標可協助您監控應用程式的健康狀態,包括發現容器是否經常重新啟動、記憶體不足,或因 CPU 限制而受到節流。
指標 | 說明 | 疑難排解重要性 |
---|---|---|
kubernetes.io/container/cpu/limit_utilization |
CPU 限制數量目前於執行個體上使用的比例。這個值可以大於 1,因為容器可能允許超過 CPU 限制。 | 識別 CPU 節流。數值過高可能會導致效能降低。 |
kubernetes.io/container/memory/limit_utilization |
記憶體限制量目前於執行個體上使用的比例。這個值不得超過 1。 | 監控 OutOfMemory (OOM) 錯誤的風險。 |
kubernetes.io/container/memory/used_bytes |
容器實際消耗的記憶體 (以位元組為單位)。 | 追蹤記憶體耗用量,找出潛在的記憶體流失問題或記憶體不足錯誤風險。 |
kubernetes.io/container/memory/page_fault_count |
細分為主要與次要兩種類型的頁面錯誤數。 | 表示記憶體壓力過大。即使未達到記憶體上限,重大分頁錯誤仍表示系統正在從磁碟讀取記憶體 (交換)。 |
kubernetes.io/container/restart_count |
容器已重新啟動的次數。 | 如果應用程式重新啟動次數過多或不斷增加,可能代表有問題,例如應用程式當機、設定錯誤或資源耗盡。 |
kubernetes.io/container/ephemeral_storage/used_bytes |
本機暫存空間用量,以位元組為單位。 | 監控暫時磁碟用量,避免 Pod 因臨時儲存空間已滿而遭到逐出。 |
kubernetes.io/container/cpu/request_utilization |
要求的 CPU 目前於執行個體上使用的比例。這個值可以大於 1,因為用量可以超過要求。 | 找出 CPU 要求是否過度或不足,協助您最佳化資源分配。 |
kubernetes.io/container/memory/request_utilization |
要求的記憶體目前於執行個體上使用的比例。這個值可以大於 1,因為用量可以超過要求。 | 找出過度或佈建不足的記憶體要求,以改善排程並避免 OOM 錯誤。 |
節點效能和健康指標
需要診斷基礎 GKE 基礎架構的問題時,請檢查這些指標。這些指標對於瞭解節點的整體健康狀態和容量至關重要,可協助您調查節點是否不健康或處於壓力下,或是節點是否有足夠的記憶體來排定新 Pod。
指標 | 說明 | 疑難排解重要性 |
---|---|---|
kubernetes.io/node/cpu/allocatable_utilization |
可分配 CPU 目前於執行個體上使用的比例。 | 指出 Pod 用量總和是否已超出節點的可用 CPU 資源。 |
kubernetes.io/node/memory/allocatable_utilization |
可分配記憶體目前於執行個體上使用的比例。這個值不能超過 1,因為用量不能超過可分配的記憶體位元組。 | 表示節點缺少記憶體,無法排定新 Pod 或讓現有 Pod 運作,特別是值偏高時。 |
kubernetes.io/node/status_condition (Beta 版) |
節點狀態條件欄位中的節點條件。 | 回報節點健康狀態,例如 Ready 、MemoryPressure 或 DiskPressure 。 |
kubernetes.io/node/ephemeral_storage/used_bytes |
節點使用的本機暫存空間位元組。 | 提供暫時性儲存空間用量過高的警告,協助避免 Pod 啟動失敗或遭到驅逐。 |
kubernetes.io/node/ephemeral_storage/inodes_free |
本機暫存空間的索引節點 (inode) 數量上限。 | 監控可用 inode 數量。即使有可用磁碟空間,索引節點用盡仍會導致作業停止。 |
kubernetes.io/node/interruption_count (Beta 版) |
中斷是指系統在客戶控管基礎架構時,將基礎架構逐出系統。這項指標是目前按類型和原因計算的中斷次數。 | 說明節點可能因系統逐出而意外消失的原因。 |
Pod 成效和健康指標
這些指標可協助您排解 Pod 與環境互動相關的問題,例如網路和儲存空間。當您需要診斷啟動緩慢的 Pod、調查潛在的網路連線問題,或主動管理儲存空間,以防止磁碟區空間不足導致寫入失敗時,請使用這些指標。
指標 | 說明 | 疑難排解重要性 |
---|---|---|
kubernetes.io/pod/network/received_bytes_count |
Pod 透過網路接收的累計位元組數。 | 找出異常的網路活動 (高或低),這可能表示應用程式或網路有問題。 |
kubernetes.io/pod/network/policy_event_count (Beta 版) |
資料平面中網路政策事件的數量變化。 | 找出網路政策導致的連線問題。 |
kubernetes.io/pod/volume/utilization |
執行個體目前使用的磁碟區占比。這個值不可能超過 1,因為用量不會超過可用磁碟區空間總量。 | 如果用量偏高 (接近 1) 可能導致寫入失敗,系統會發出警告,方便您主動管理磁碟區空間。 |
kubernetes.io/pod/latencies/pod_first_ready (Beta 版) |
Pod 端對端啟動延遲時間 (從 Pod `Created` 到 `Ready`),包括映像檔提取作業。 | 診斷啟動速度緩慢的 Pod。 |
使用 Metrics Explorer 製作指標圖表
如要以圖表呈現 GKE 環境的狀態,請使用 Metrics Explorer 根據指標建立圖表。
如要使用 Metrics Explorer,請完成下列步驟:
前往 Google Cloud 控制台的「Metrics Explorer」頁面。
在「指標」欄位中,選取或輸入要檢查的指標。
查看結果,並觀察長期趨勢。
舉例來說,如要調查特定命名空間中 Pod 的記憶體用量,可以執行下列操作:
- 在「選取指標」清單中選擇指標
kubernetes.io/container/memory/used_bytes
,然後按一下「套用」。 - 按一下「新增篩選器」,然後選取「namespace_name」。
- 在「Value」(值) 清單中,選取要調查的命名空間。
- 在「Aggregation」(匯總) 欄位中,依序選取「Sum」(總和) >「pod_name」,然後按一下「OK」(確定)。這項設定會為每個 Pod 顯示個別的時間序列線。
- 按一下「儲存圖表」。
產生的圖表會顯示每個 Pod 的記憶體用量,協助您找出記憶體用量異常偏高或突然飆升的 Pod。
您可以透過指標探索工具,彈性建構要查看的指標。如要進一步瞭解 Metrics Explorer 進階選項,請參閱 Cloud Monitoring 說明文件的「使用 Metrics Explorer 建立圖表」一文。
建立快訊,主動偵測問題
如要在發生錯誤或指標超出特定門檻時收到通知,請在 Cloud Monitoring 中設定快訊政策。
舉例來說,如要設定快訊政策,在容器 CPU 限制超過 80% 達五分鐘時通知您,請按照下列步驟操作:
前往 Google Cloud 控制台的「Alerting」(警告) 頁面。
按一下「建立政策」。
在「選取指標」方塊中,篩選
CPU limit utilization
,然後選取下列指標: kubernetes.io/container/cpu/limit_utilization。按一下 [套用]。
將「新增篩選器」欄位留空。如有任何叢集違反門檻,這項設定就會觸發快訊。
在「轉換資料」部分,執行下列操作:
- 在「Rolling window」(滾動週期) 清單中,選取「1 minute」(1 分鐘)。這項設定表示 Google Cloud 每分鐘都會計算平均值。
在「Rolling window function」(滾動週期函式) 清單中,選取「mean」(平均值)。
這兩項設定都會每分鐘計算每個容器的平均 CPU 限制使用率。
點選「下一步」。
在「設定快訊」部分,執行下列操作:
- 在「條件類型」部分選取「門檻」。
- 針對「Alert trigger」(快訊觸發條件),選取「Any time series violates」(任何時間序列違反條件時)。
- 在「Threshold position」(門檻位置) 中選取「Above threshold」(高於門檻)。
- 在「Threshold value」(門檻值) 中輸入
0.8
。這個值代表您要監控的 80% 門檻。 - 點選「進階選項」。
- 在「Retest window」(重新測試時間範圍) 清單中,選取「5 min」(5 分鐘)。這項設定表示 CPU 使用率必須連續五分鐘超過 80%,才會觸發快訊,可減少短暫尖峰造成的誤報。
- 在「條件名稱」欄位中,為條件取個清楚易懂的名稱。
- 點選「下一步」。
在「設定通知並完成快訊」部分,執行下列操作:
- 在「Notification channels」(通知管道) 清單中,選取要接收快訊的管道。如果沒有管道,請按一下「管理通知管道」建立管道。
- 在「為快訊政策命名」欄位中,為政策取個清楚易懂的名稱。
- 所有其他欄位則保留預設值。
- 點選「下一步」。
檢查政策,確認一切正確無誤後,按一下「建立政策」。
如要瞭解建立快訊的其他方式,請參閱 Cloud Monitoring 說明文件中的「快訊總覽」。
後續步驟
請參閱「使用 Gemini Cloud Assist 加快診斷速度」(本系列教學課程的下一頁)。
請參閱疑難排解情境示例,瞭解如何應用這些概念。
如需解決特定問題的建議,請參閱 GKE 的疑難排解指南。
如果無法在說明文件中找到問題的解決方法,請參閱「取得支援」一文,尋求進一步的協助, 包括下列主題的建議:
- 與 Cloud 客戶服務聯絡,建立支援案件。
- 在 StackOverflow 上提問,並使用
google-kubernetes-engine
標記搜尋類似問題,向社群尋求支援。你也可以加入#kubernetes-engine
Slack 頻道,取得更多社群支援。 - 使用公開問題追蹤工具回報錯誤或提出功能要求。