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