作者：炎尋

大家好，我是阿里云云原生應(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ù)載的異常》、Vol.3《系統(tǒng)架構(gòu)面臨的三大挑戰(zhàn)，看 Kubernetes 監(jiān)控如何解決》、Vol.4《如何使用 Kubernetes 監(jiān)測(cè)定位慢調(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 種典型場(chǎng)景，以及如何使用 Kubernetes 監(jiān)控來處理這些場(chǎng)景，快速定位發(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)鍵觀測(cè)數(shù)據(jù)，包括 Pod Status 字段、相關(guān)事件、日志、性能指標(biāo)、請(qǐng)求鏈路。
那么，接下來我們來盤點(diǎn)一下相關(guān)常見的問題場(chǎng)景。

01

常見問題場(chǎng)景

Cloud Native

問題場(chǎng)景 1：就緒失敗，即 Pod 一直無法到達(dá) Ready 狀態(tài)，無法接收請(qǐng)求進(jìn)行業(yè)務(wù)處理。

常見的根因如下：

• 資源不足，無法調(diào)度（Pending），即集群的 Node 沒有預(yù)留資源能夠滿足 Pod 的 Request 資源；

• 鏡像拉取失?。?ImagePullBackoff ），鏡像的倉(cāng)庫(kù)地址，tag 出現(xiàn)問題；

• 磁盤掛載失敗（Pending），容器掛載的 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）。

問題場(chǎng)景 2：容器頻繁重啟，即 Pod 過去 24 小時(shí)重啟次數(shù) >=2。
雖然 Kubernetes 提供了很多自愈的能力，但是頻繁重啟依舊是不容忽視的問題。

常見的根因如下：

• 程序異常退出，比如非法地址訪問，比如進(jìn)入了程序需要退出的條件等；

• 容器內(nèi)存使用量超過內(nèi)存 Limit 量，被 OOMKilled。

問題場(chǎng)景 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)求處理失敗。

問題場(chǎ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)求處理慢；

問題場(chǎ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)；

問題場(chǎng)景 6：Pod 容器出現(xiàn)內(nèi)存 OOM，Pod 頻繁重啟，查看原因是 OOMKilled。

常見的根因如下：

• 自身代碼內(nèi)存泄露；

• Pod 內(nèi)存 Limit 值偏低，容器內(nèi)存使用量超過 Limit 值會(huì)被 OOMKilled 掉；

問題場(chǎng)景 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)；

問題場(chǎng)景 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；

問題場(chǎng)景 9：Pod IO 高
比如 Pod 內(nèi)存飆高，文件讀寫很慢，導(dǎo)致業(yè)務(wù)處理慢。

常見的根因如下：

• 自身代碼文件讀寫過于頻繁，可以考慮批量化讀寫；

• 節(jié)點(diǎn)本身的 IO 高影響 Pod，節(jié)點(diǎn)的 IO 是共享資源，部分高 IO 的 Pod 可能影響其他 Pod；

面對(duì)以上 9 個(gè)常見異常場(chǎng)景，在表象相似的情況戲，我們?cè)撊绾芜M(jìn)行根因分析？下面我們來看看最佳實(shí)踐，如何使用 Kubernetes 監(jiān)控來發(fā)現(xiàn)定位對(duì)應(yīng)異常場(chǎng)景的根因。

02

最佳實(shí)踐

Cloud Native

最佳實(shí)踐一：Pod 的 Kubernetes 狀態(tài)異常定位

Kubernetes 監(jiān)控的 Pod 詳情頁(yè)包含了 Pod 相關(guān)的 Kubernetes 信息，比如事件、Conditions、獲取 YAML 能力，日志界面以及終端能力，能夠快速幫你定位異常場(chǎng)景 1 和異常場(chǎng)景 2 的根因。 最佳實(shí)踐二：Pod 的錯(cuò)慢請(qǐng)求分析

Kubernetes 監(jiān)控的 Pod 詳情頁(yè)包含了該 Pod 作為服務(wù)端的性能監(jiān)控，可以快速發(fā)現(xiàn)錯(cuò)慢趨勢(shì)。對(duì)于錯(cuò)慢請(qǐng)求，我們存儲(chǔ)了明細(xì)，包含了請(qǐng)求和響應(yīng)信息、整體耗時(shí)，以及請(qǐng)求接收，請(qǐng)求處理和請(qǐng)求響應(yīng)的分段耗時(shí)，能夠幫助您快速定位錯(cuò)在哪，慢在哪，能夠快速幫你定位異常場(chǎng)景 3 和異常場(chǎng)景 4 的根因。 最佳實(shí)踐三：Pod 的資源消耗分析

 

Kubernetes 監(jiān)控的 Pod 詳情頁(yè)包含了該 Pod 的資源消耗以及特定容器的資源申請(qǐng)失敗監(jiān)控，可以看到哪些容器資源消耗得多，后續(xù)我們將會(huì)加上 profiling 能力，回答哪個(gè)方法占用 CPU 比較多，哪個(gè)對(duì)象占用內(nèi)存比較多，與此同時(shí)詳情頁(yè)還包含了關(guān)聯(lián) Node 的資源消耗情況，能夠快速幫你定位異常場(chǎng)景 5-9 的根因。 

最佳實(shí)踐四：Pod 到外部服務(wù)的請(qǐng)求性能分析

Kubernetes 監(jiān)控的拓?fù)漤?yè)面會(huì)展示集群節(jié)點(diǎn)到外部服務(wù)以及集群節(jié)點(diǎn)之間的請(qǐng)求關(guān)系，點(diǎn)擊請(qǐng)求關(guān)系，可以快速查看特定節(jié)點(diǎn)到特定外部服務(wù)的請(qǐng)求性能，可以快速定位下游問題。幫助解決場(chǎng)景 3，4 的根因。 最佳實(shí)踐五：Pod 到外部服務(wù)的網(wǎng)絡(luò)性能分析

Kubernetes 監(jiān)控的拓?fù)漤?yè)面會(huì)展示集群節(jié)點(diǎn)到外部服務(wù)以及集群節(jié)點(diǎn)之間的網(wǎng)絡(luò)關(guān)系，點(diǎn)擊網(wǎng)絡(luò)關(guān)系，可以快速查看特定節(jié)點(diǎn)到特定外部服務(wù)的網(wǎng)絡(luò)，可以快速定位網(wǎng)絡(luò)和下游問題。幫助解決場(chǎng)景 3，4 的根因。 目前，Kubernetes 監(jiān)控免費(fèi)使用中