Kubernetes Pod狀態(tài)異常九大場景盤點
大家好，我是阿里云云原生應用平臺的炎尋，很高興能和大家在 Kubernetes 監(jiān)控系列公開課上進行交流。
前四期公開課我們講到了 Vol.1《通過 Kubernetes 監(jiān)控探索應用架構，發(fā)現(xiàn)預期外的流量》、Vol.2《如何發(fā)現(xiàn) Kubernetes 中服務和工作負載的異常》、Vol.3《系統(tǒng)架構面臨的三大挑戰(zhàn)，看 Kubernetes 監(jiān)控如何解決》、Vol.4《如何使用 Kubernetes 監(jiān)測定位慢調(diào)用》。今天我們將進行第五講，使用 Kubernetes 定位 Pod 狀態(tài)異常的根因。
Kubernetes Pod 作為 Kubernetes 核心資源對象，不僅 Service、Controller、Workload 都是圍繞它展開工作。作為最小調(diào)度單元的它，還擔任著傳統(tǒng) IT 環(huán)境主機的職責，包含了調(diào)度，網(wǎng)絡，存儲，安全等能力。 正是因為 Pod 具有復雜的生命周期和依賴，絕大多數(shù) Kubernetes 問題最終都會在 Pod 上表現(xiàn)出來。因此，我們介紹在實際工作實踐中會遇到的 9 種典型場景，以及如何使用 Kubernetes 監(jiān)控來處理這些場景，快速定位發(fā)現(xiàn)問題。
容器是用戶進程，Pod 就像是機器，所以調(diào)度，網(wǎng)絡，存儲，安全等機器級別的異常以及進程運行的異常都會在 Pod 上面體現(xiàn)出來。圍繞著 Pod 來說，有以下幾個關鍵的點非常容易出現(xiàn)問題：
-
調(diào)度
-
鏡像拉取
-
磁盤掛載
-
Liveless/Readiness probe
-
postStart/preStop handler
-
配置
-
運行時
Kubernetes 提供相應的關鍵觀測數(shù)據(jù)，包括 Pod Status 字段、相關事件、日志、性能指標、請求鏈路。
那么，接下來我們來盤點一下相關常見的問題場景。
常見問題場景
Cloud Native
問題場景 1：就緒失敗，即 Pod 一直無法到達 Ready 狀態(tài)，無法接收請求進行業(yè)務處理。
常見的根因如下：
-
資源不足，無法調(diào)度（Pending），即集群的 Node 沒有預留資源能夠滿足 Pod 的 Request 資源；
-
鏡像拉取失?。?ImagePullBackoff ），鏡像的倉庫地址，tag 出現(xiàn)問題；
-
磁盤掛載失?。≒ending），容器掛載的 PVC 沒有 bound；
-
Liveless probe 探針失敗，頻繁重啟；
-
Readiness probe 探針失敗，無法達到 Ready 狀態(tài)；
-
postStart 執(zhí)行失敗，一直無法進入運行狀態(tài)；
-
運行時程序崩潰（ CrashLoopBackOff ），頻繁重啟；
-
配置錯誤，比如掛載的 Volume 不存在（RunContainerError）。
問題場景 2：容器頻繁重啟，即 Pod 過去 24 小時重啟次數(shù) >=2。
雖然 Kubernetes 提供了很多自愈的能力，但是頻繁重啟依舊是不容忽視的問題。
常見的根因如下：
-
程序異常退出，比如非法地址訪問，比如進入了程序需要退出的條件等；
-
容器內(nèi)存使用量超過內(nèi)存 Limit 量，被 OOMKilled。
問題場景 3：Pod 服務的請求錯誤率變高
比如 Pod 過去 1s 的請求錯誤率 >=20%，這個問題就比較嚴重了。
常見的根因如下：
-
請求量突增，程序自身可能觸發(fā)流控或者其他異常處理，導致請求處理失敗率提升；
-
自身代碼處理錯誤，請求量沒有變化，可能是上線新的功能有 bug；
-
不可壓縮資源不足（磁盤，內(nèi)存），請求處理包含磁盤的寫操作，資源不足出現(xiàn)失??；外部依賴服務報錯，請求處理需要調(diào)用下游服務，他們報錯引發(fā)請求處理失敗。
問題場景 4：請求處理 P95 響應時間高
比如過去 30 分鐘，有 5% 的請求耗時都超過了 3s，這個問題會影響使用該接口相當一部分客戶的體驗。
常見的根因如下：
-
請求量突增，程序自身處理不過來，導致超時；
-
自身代碼池化資源不足，因為 bug 導致的線程池或者隊列滿，請求處理不過來，導致超時；
-
Pod 運行資源不足，請求處理包含 cpu/memory/io 資源的申請，但是資源不足導致處理慢；
-
外部依賴服務響應時間高，請求處理需要調(diào)用下游服務，他們的響應時間高會導致請求處理慢；
問題場景 5：Pod 內(nèi)存使用率高
比如超過 80%，這個時候就有 OOMKilled 的風險，也有被驅(qū)逐的風險。
常見的根因如下：
-
自身代碼內(nèi)存泄露；
-
Pod 內(nèi)存 Request 值偏低，如果該值偏低的情況下配置 HPA，會頻繁觸發(fā)擴容，同時具有被驅(qū)逐的風險；
問題場景 6：Pod 容器出現(xiàn)內(nèi)存 OOM，Pod 頻繁重啟，查看原因是 OOMKilled。
常見的根因如下：
-
自身代碼內(nèi)存泄露；
-
Pod 內(nèi)存 Limit 值偏低，容器內(nèi)存使用量超過 Limit 值會被 OOMKilled 掉；
問題場景 7：Pod CPU 使用率高。
比如 Pod 的整體 CPU 使用率超過 80%，常見的根因如下：
-
自身代碼效率不足，業(yè)務處理的時間復雜度太高，需要找到熱點方法進行優(yōu)化；
-
Pod CPU Request 值偏低，如果該值偏低的情況下配置 HPA，會頻發(fā)觸發(fā)擴容，同時具有被驅(qū)逐的風險；
問題場景 8：Pod CPU Throttled。
比如 Pod 的需求是要用 1c，一直只能用到 0.8 core，導致業(yè)務處理慢。
常見的根因如下：
-
自身代碼效率不足，業(yè)務處理的時間復雜度太高，需要找到熱點方法進行優(yōu)化；
-
Pod CPU Limit 值設置太低，CPU 使用量超過該值，對應容器的 CPU 會被 Throttled；
-
容器運行時自身問題，更具體來說個別內(nèi)核版本即使在 CPU 沒有超過 Limit 的時候也會對容器進行 CPU Throttled；
問題場景 9：Pod IO 高
比如 Pod 內(nèi)存飆高，文件讀寫很慢，導致業(yè)務處理慢。
常見的根因如下：
-
自身代碼文件讀寫過于頻繁，可以考慮批量化讀寫；
-
節(jié)點本身的 IO 高影響 Pod，節(jié)點的 IO 是共享資源，部分高 IO 的 Pod 可能影響其他 Pod；
02
最佳實踐
Cloud Native
最佳實踐一：Pod 的 Kubernetes 狀態(tài)異常定位
Kubernetes 監(jiān)控的 Pod 詳情頁包含了 Pod 相關的 Kubernetes 信息，比如事件、Conditions、獲取 YAML 能力，日志界面以及終端能力，能夠快速幫你定位異常場景 1 和異常場景 2 的根因。 最佳實踐二：Pod 的錯慢請求分析
Kubernetes 監(jiān)控的 Pod 詳情頁包含了該 Pod 作為服務端的性能監(jiān)控，可以快速發(fā)現(xiàn)錯慢趨勢。對于錯慢請求，我們存儲了明細，包含了請求和響應信息、整體耗時，以及請求接收，請求處理和請求響應的分段耗時，能夠幫助您快速定位錯在哪，慢在哪，能夠快速幫你定位異常場景 3 和異常場景 4 的根因。 最佳實踐三：Pod 的資源消耗分析
最佳實踐四：Pod 到外部服務的請求性能分析
Kubernetes 監(jiān)控的拓撲頁面會展示集群節(jié)點到外部服務以及集群節(jié)點之間的請求關系，點擊請求關系，可以快速查看特定節(jié)點到特定外部服務的請求性能，可以快速定位下游問題。幫助解決場景 3，4 的根因。 最佳實踐五：Pod 到外部服務的網(wǎng)絡性能分析