搞 Kubernetes 的誰(shuí)還沒(méi)被 Pod 重啟折磨過(guò)尤其是在線(xiàn)上環(huán)境上一小時(shí)告警還風(fēng)平浪靜下一秒突然彈出通知Pod 頻繁重啟、服務(wù)間歇性不可用甚至直接 CrashLoopBackOff。十次有八次大家第一反應(yīng)是趕緊看日志結(jié)果日志一片正常越查越懵最后只能重啟大法把 Pod 刪了讓 Deployment 重新拉一個(gè)看似好了但過(guò)幾個(gè)小時(shí)又復(fù)發(fā)。以我排查過(guò)幾十個(gè) Pod 重啟問(wèn)題的經(jīng)驗(yàn)來(lái)看這類(lèi)問(wèn)題真正難的地方不是“查不到”而是“查的先后順序不對(duì)”。狀態(tài)、事件、日志、節(jié)點(diǎn)這四層信息必須按順序看順序一亂很容易被表象帶偏。這篇文章就把我平時(shí)排查 POD 重啟問(wèn)題的一套完整流程拆開(kāi)講清楚包括怎么看狀態(tài)、怎么讀事件、什么時(shí)候才輪到日志以及最常見(jiàn)的幾個(gè)根因和那些容易誤判的干擾項(xiàng)。不管你是剛?cè)腴T(mén) Kubernetes 的運(yùn)維還是天天跟 Deployment、ConfigMap、探針打交道的開(kāi)發(fā)這套思路應(yīng)該都能幫你少走不少?gòu)澛贰?. 先從現(xiàn)象說(shuō)起Pod 重啟并不都是 CrashLoopBackOff很多人一看到 Pod 重啟腦子里自動(dòng)就蹦出“CrashLoopBackOff”這個(gè)詞但實(shí)際上“重啟”這兩個(gè)字在 Kubernetes 里對(duì)應(yīng)著好幾種完全不同的現(xiàn)象每種現(xiàn)象的排查入口完全不一樣。如果連現(xiàn)象都沒(méi)分清楚就開(kāi)始查日志大概率會(huì)被帶進(jìn)死胡同。1.1 Pod “重啟”的三個(gè)層面先別混為一談第一層是容器內(nèi)進(jìn)程退出后被殺掉重啟。這個(gè)層面下Pod 本身沒(méi)有消失Running 狀態(tài)還在但容器里的主進(jìn)程曾經(jīng)退出過(guò)Kubelet 按照重啟策略把它重新拉起來(lái)了。表現(xiàn)是RESTARTS這個(gè)字段在漲但 Pod 的名字、UID 都沒(méi)變。第二層是 Pod 被刪除后重建。這種情況常見(jiàn)于 Deployment 滾動(dòng)更新、節(jié)點(diǎn)故障、Pod 被驅(qū)逐Evicted。表現(xiàn)是 Pod 的名字變了比如帶了一串-xxxxx的 hash 后綴或者 AGE 突然變成幾秒鐘。這其實(shí)不是“容器重啟”而是“整個(gè) Pod 生命周期重建”。第三層是節(jié)點(diǎn)重啟導(dǎo)致所有 Pod 重新調(diào)度。節(jié)點(diǎn)宕機(jī)、系統(tǒng)維護(hù)、硬件故障等情況上面所有 Pod 都會(huì)被迫遷移到其他節(jié)點(diǎn)甚至直接失聯(lián)后重建。這時(shí)候你會(huì)看到一批 Pod 的 AGE 幾乎在同一時(shí)間重置而且分布在不同節(jié)點(diǎn)上。這三層我習(xí)慣用一個(gè)生活類(lèi)比來(lái)理解容器重啟等于餐廳廚房里某個(gè)廚師干得好好的突然被換掉餐廳本身還在營(yíng)業(yè)Pod 重建等于整個(gè)店重新裝修了桌子和菜單全部換新節(jié)點(diǎn)重啟等于整棟樓斷電里面所有店鋪都得重新開(kāi)張。排查入口完全不同所以開(kāi)工第一步一定是先確認(rèn)“你遇到的到底是哪一層”。實(shí)際操作中用一條kubectl get pods -n namespace -o wide就能看出不少信息如果 Pod NAME 后綴變了說(shuō)明 Pod 被重建過(guò)如果 NAME 沒(méi)變但 RESTARTS 在漲說(shuō)明是容器反復(fù)重啟再配合 NODE 字段和 AGE節(jié)點(diǎn)層面的干擾也有跡可循。1.2 STATUS 和 RESTARTS 里藏著最直接的線(xiàn)索kubectl get pods的結(jié)果里有幾個(gè)字段非常容易被忽略但其實(shí)信息量很大。STATUS 是你最先應(yīng)該看的它告訴你 Pod 處于什么階段RESTARTS 告訴你當(dāng)前容器重啟了多少次AGE 告訴你這個(gè) Pod 已經(jīng)存活了多久。這里有個(gè)很關(guān)鍵的細(xì)節(jié)如果 Pod 曾經(jīng)被刪除重建RESTARTS 會(huì)歸零因?yàn)樾碌?Pod 里容器是全新啟動(dòng)的。所以你如果看到一個(gè) Pod 的 AGE 只有幾分鐘但 RESTARTS 顯示 10 次說(shuō)明這個(gè) Pod 很穩(wěn)定地“活著”但沒(méi)有“活得健康”容器一直在被殺又重啟卻沒(méi)觸發(fā) Pod 重建——這種通常和探針有關(guān)。反過(guò)來(lái)如果看到一批 Pod 的 AGE 都只有幾秒RESTARTS 也是 0那大概率是 Deployment 滾動(dòng)更新或者節(jié)點(diǎn)故障觸發(fā)了整體重建根本不是“某個(gè)應(yīng)用崩了”而是上層動(dòng)作導(dǎo)致的。STATUS 的值也分好幾種CrashLoopBackOff表示容器啟動(dòng)后反復(fù)退出Kubelet 用了指數(shù)退避策略重啟間隔會(huì)越來(lái)越長(zhǎng)Running表示容器正在運(yùn)行但如果 RESTARTS 一直在漲說(shuō)明有探針在殺它Error通常是容器執(zhí)行完但退出時(shí)出錯(cuò)Completed是正常執(zhí)行完就退出常用于一次性任務(wù)Evicted則是被節(jié)點(diǎn)驅(qū)逐這個(gè)后面會(huì)專(zhuān)門(mén)說(shuō)。先把這個(gè)表格刻在腦子里看到什么狀態(tài)就知道往哪個(gè)方向查。STATUS含義優(yōu)先排查方向CrashLoopBackOff容器反復(fù)啟動(dòng)即退出退避重啟退出碼、啟動(dòng)命令、配置掛載Running RESTARTS 漲容器活著但被健康檢查殺掉Liveness/Readiness 探針配置OOMKilled容器內(nèi)存超過(guò) limits 被內(nèi)核殺死內(nèi)存配額、應(yīng)用內(nèi)存占用EvictedPod 被節(jié)點(diǎn)驅(qū)逐節(jié)點(diǎn)磁盤(pán)/內(nèi)存壓力Error容器異常退出退出碼、應(yīng)用日志Completed正常退出一次性任務(wù)一般無(wú)需處理2. 排查第一件事先分清是誰(shuí)在重啟當(dāng)你確定 “Pod 確實(shí)在重啟” 之后第一件事不是抓日志而是用kubectl describe看清楚這輪重啟的“案發(fā)現(xiàn)場(chǎng)”。我會(huì)把這步叫作“看尸檢報(bào)告”因?yàn)槿萜鞅恢貑⒑笊弦惠嗊M(jìn)程的狀態(tài)、退出時(shí)間、退出碼、被誰(shuí)殺掉的這些都記錄在 Pod 的狀態(tài)里不先看這些就直接翻日志等于跳過(guò)報(bào)告去猜死因非常容易漏掉關(guān)鍵信息。2.1 用 kubectl describe pod 讀重啟的“尸檢報(bào)告”kubectl describe pod pod-name -n namespace輸出的內(nèi)容很長(zhǎng)但核心就幾個(gè)區(qū)域。最上面是 Pod 基本信息包括 Node、IP、QoS 等級(jí)中間的 Conditions 反映 Ready、PodScheduled、Initialized 等狀態(tài)再往下是容器列表每個(gè)容器下面有 State、Last State、Exit Code、Reason 和 Started/Finished 時(shí)間最后是滾動(dòng)的 Events 時(shí)間線(xiàn)。我重點(diǎn)看的是 Last State 那一塊。Last State 里會(huì)記錄上一個(gè)容器的終止時(shí)間和退出碼如果顯示 TerminatedReason 是 Completed 還是 ErrorExit Code 是多少這決定了排查方向。舉個(gè)例子如果 Exit Code 是 0說(shuō)明上一個(gè)進(jìn)程是被“正常結(jié)束”的通常意味著有人刪 Pod、滾動(dòng)更新觸發(fā)優(yōu)雅終止或者探針之外的機(jī)制主動(dòng)殺了它如果 Exit Code 是 137對(duì)應(yīng) 128 9也就是 SIGKILL這往往是被 OOM Killer 或者外部 kill 命令強(qiáng)殺的如果是 143對(duì)應(yīng) 128 15也就是 SIGTERM通常是收到了優(yōu)雅終止信號(hào)但沒(méi)處理完如果是 1、2 這種就是應(yīng)用自身啟動(dòng)失敗或運(yùn)行錯(cuò)誤。這里面的坑是137 并不完全等同于內(nèi)存超限。Kubelet 主動(dòng)殺掉容器時(shí)Exit Code 也可能被標(biāo)記為 137尤其是探針失敗、節(jié)點(diǎn)驅(qū)逐、手動(dòng)刪除容器這些場(chǎng)景也會(huì)走 SIGKILL。所以看到 137 先別急著下“肯定是 OOM”的結(jié)論得繼續(xù)看 Reason 字段。如果 Reason 寫(xiě)的是 OOMKilled那才是內(nèi)存原因如果 Reason 是 ContainerCannotRun 或者空那就要再往 Events 里找。2.2 一份退出碼速查表排查時(shí)對(duì)照著看我整理過(guò)一份簡(jiǎn)化版的退出碼速查表排查時(shí)貼在終端旁邊非常實(shí)用Exit Code含義常見(jiàn)場(chǎng)景0正常退出任務(wù)執(zhí)行完、主動(dòng)退出、優(yōu)雅終止1通用應(yīng)用錯(cuò)誤啟動(dòng)失敗、配置錯(cuò)誤、運(yùn)行時(shí)異常2參數(shù)/環(huán)境錯(cuò)誤啟動(dòng)腳本參數(shù)不對(duì)、依賴(lài)缺失126命令不可執(zhí)行權(quán)限問(wèn)題、或動(dòng)態(tài)鏈接庫(kù)缺失127命令不存在entrypoint/command 寫(xiě)錯(cuò)、鏡像缺少命令137SIGKILL內(nèi)存 OOM、被強(qiáng)殺、節(jié)點(diǎn)壓力143SIGTERM優(yōu)雅終止超時(shí)后被 SIGKILL 跟進(jìn)有一次我排查一個(gè) Java 應(yīng)用頻繁重啟describe 里顯示 Exit Code 是 137Reason 是 OOMKilled但看應(yīng)用日志根本沒(méi)打印任何 JVM 內(nèi)存溢出異常。后來(lái)才發(fā)現(xiàn)OOM 發(fā)生在容器總內(nèi)存層面應(yīng)用層根本來(lái)不及報(bào)錯(cuò)內(nèi)核直接把進(jìn)程殺了。這類(lèi)問(wèn)題如果只查日志永遠(yuǎn)找不到原因必須結(jié)合 describe 和節(jié)點(diǎn)層的內(nèi)存監(jiān)控一起看。2.3 一個(gè)很常見(jiàn)的誤判RESTARTS 高但 STATUS 是 Running很多新手看到 STATUS 是 Running 就覺(jué)得“沒(méi)問(wèn)題”實(shí)際上這是最容易被坑的場(chǎng)景之一。如果容器狀態(tài)是 Running但 RESTARTS 一直在漲最常見(jiàn)的原因是 Liveness 探針失敗——Kubelet 判斷容器不健康殺掉了它然后又按策略拉起來(lái)。這時(shí)候日志往往非?！罢！币?yàn)閼?yīng)用啟動(dòng)后確實(shí)能跑只是探針訪(fǎng)問(wèn)的端口或路徑在特定時(shí)刻響應(yīng)超時(shí)觸發(fā)了 kill。所以我的排查習(xí)慣是先看 STATUS 能排除掉很多方向再看 RESTARTS 的漲勢(shì)判斷是持續(xù)還是偶爾然后立刻kubectl describe看 Last State 和 Reason。如果這些都看完還不能定位才考慮日志。這個(gè)順序能幫你過(guò)濾掉至少一半的無(wú)效信息。3. 三個(gè)最常見(jiàn)的重啟根因與定位方法根據(jù)我這些年的經(jīng)驗(yàn)線(xiàn)上 Pod 重啟 80% 以上逃不出這三個(gè)方向健康檢查探針配置不合理、內(nèi)存資源限制導(dǎo)致 OOM、配置或鏡像問(wèn)題導(dǎo)致啟動(dòng)即退出。每一個(gè)都有比較典型的特征掌握一套對(duì)應(yīng)的定位方法排查效率能提升一大截。3.1 Liveness 探針配置不當(dāng)容器“死于”健康檢查這是我見(jiàn)過(guò)最多的一個(gè)坑也是最“玄學(xué)”的一類(lèi)問(wèn)題。容器明明進(jìn)程還在、端口也在監(jiān)聽(tīng)但 Kubelet 通過(guò) Liveness 探針檢查時(shí)發(fā)現(xiàn)不健康于是按照策略把容器殺了重啟。表現(xiàn)非常典型STATUS 是 RunningRESTARTS 持續(xù)上漲describe 里能看到 “Liveness probe failed” 和 “Killing container” 的事件但應(yīng)用側(cè)日志往往沒(méi)有致命報(bào)錯(cuò)。Liveness 探針有幾個(gè)參數(shù)會(huì)直接影響重啟行為initialDelaySeconds是容器啟動(dòng)后等待多久才開(kāi)始探測(cè)設(shè)短了會(huì)導(dǎo)致應(yīng)用還沒(méi)完全初始化就被探針判定失敗periodSeconds是探測(cè)頻率默認(rèn) 10 秒太頻繁會(huì)放大瞬時(shí)波動(dòng)timeoutSeconds是單次探測(cè)的超時(shí)時(shí)間默認(rèn)只有 1 秒這個(gè)非常容易踩雷——很多應(yīng)用的 HTTP 接口在 GC 停頓、慢查詢(xún)或瞬時(shí)高負(fù)載時(shí)響應(yīng)時(shí)間超過(guò) 1 秒很正常但探針等不了直接就失敗failureThreshold是連續(xù)失敗多少次才觸發(fā)重啟默認(rèn) 3 次。我踩過(guò)最慘的一次是一個(gè) Java 服務(wù)啟動(dòng)需要大概 40 秒但 YAML 里initialDelaySeconds配的是 10periodSeconds是 10failureThreshold是 3。等于說(shuō)應(yīng)用還在啟動(dòng)階段探針已經(jīng)開(kāi)始探測(cè)三次失敗后 Kubelet 直接殺容器重啟然后又是 40 秒啟動(dòng)又是 30 秒后被探針殺掉形成了一個(gè)永遠(yuǎn)起不來(lái)的循環(huán)。表面上看是 CrashLoopBackOff實(shí)際根因就是探針配置和實(shí)際啟動(dòng)時(shí)間不匹配。解決辦法很簡(jiǎn)單把initialDelaySeconds調(diào)大到 60讓?xiě)?yīng)用先完成啟動(dòng)再開(kāi)始健康檢查。這里要特別強(qiáng)調(diào)一個(gè)概念Readiness 探針和 Liveness 探針職責(zé)不同。Readiness 失敗只代表“這個(gè)容器暫時(shí)不能接收流量”Kubelet 會(huì)把它的 Endpoint 摘掉不會(huì)殺容器只有 Liveness 失敗才會(huì)觸發(fā)重啟。很多團(tuán)隊(duì)圖省事把 Readiness 和 Liveness 配成一模一樣結(jié)果一個(gè)接口偶發(fā)慢查詢(xún)集群里一堆副本進(jìn)入 NotReady 狀態(tài)甚至容器反復(fù)重啟流量反復(fù)轉(zhuǎn)移。如果你遇到 Pod “又重啟又看起來(lái)正?！钡那闆r先搞清楚到底是哪個(gè)探針在報(bào)錯(cuò)describe 的 Events 里會(huì)明確寫(xiě)。3.2 資源限制導(dǎo)致 OOMKilled進(jìn)程“安靜的”消失了容器重啟的第二個(gè)高頻根因是內(nèi)存超限。每個(gè)容器可以設(shè)置requests和limits其中 limits 是硬上限一旦容器內(nèi)存用量超過(guò)這個(gè)值內(nèi)核 OOM Killer 就會(huì)介入直接發(fā)送 SIGKILL 殺掉容器里最耗內(nèi)存的進(jìn)程。表現(xiàn)是 Pod STATUS 一度是 OOMKilled然后被 Kubelet 重啟RESTARTS 加一一段時(shí)間后又重復(fù)。describe 里會(huì)看到 Reason: OOMKilledExit Code: 137。定位 OOM 問(wèn)題有個(gè)很關(guān)鍵的坑容器被殺的時(shí)候應(yīng)用本身可能根本來(lái)不及打印任何錯(cuò)誤日志所以你在kubectl logs里看不到“OutOfMemory”之類(lèi)的字樣。正確做法是看kubectl describe的 Reason以及節(jié)點(diǎn)層面的dmesg輸出里面會(huì)出現(xiàn)oom-killer和對(duì)應(yīng)的進(jìn)程 PID。另外監(jiān)控曲線(xiàn)非常重要要看容器內(nèi)存是緩慢爬坡最終觸頂還是瞬間突刺。緩慢爬坡大概率是內(nèi)存泄漏瞬間突刺往往是業(yè)務(wù)高峰或某個(gè)大請(qǐng)求導(dǎo)致的那就需要從應(yīng)用層去限流或優(yōu)化。JVM 應(yīng)用是 OOM 重災(zāi)區(qū)中的重災(zāi)區(qū)。很多團(tuán)隊(duì)把容器 limits 設(shè)成 4Gi但在 JVM 啟動(dòng)參數(shù)里把堆設(shè)成-Xmx3g看著好像沒(méi)問(wèn)題實(shí)際上 JVM 除了堆還有元空間、線(xiàn)程棧、JIT 編譯緩存、堆外內(nèi)存等一大堆開(kāi)銷(xiāo)加起來(lái)輕松超過(guò) 4Gi。換句話(huà)說(shuō)容器 limits 不足堆還沒(méi)到上限整個(gè)容器先被殺了。經(jīng)驗(yàn)做法是-Xmx不要超過(guò)容器 limits 的 60%—70%預(yù)留出堆外和系統(tǒng)層面的緩沖。這個(gè)問(wèn)題如果不用 describe 和內(nèi)存監(jiān)控一起看很容易誤判成“Java 進(jìn)程崩了”實(shí)際上容器層面先你一步動(dòng)了手。3.3 配置或鏡像問(wèn)題導(dǎo)致進(jìn)程啟動(dòng)即退出CrashLoopBackOff 的老熟人第三種常見(jiàn)根因就是容器啟動(dòng)起來(lái)之后立刻崩潰導(dǎo)致 Kubelet 反復(fù)拉起進(jìn)入 CrashLoopBackOff。這種問(wèn)題的特征最明顯STATUS 直接是 CrashLoopBackOff退出碼往往非 0。但“啟動(dòng)即退出”的誘因很多我把它拆成幾類(lèi)逐步排查。第一類(lèi)是啟動(dòng)命令或入口配置錯(cuò)誤。Deployment 里command和args寫(xiě)錯(cuò)比如指向了一個(gè)不存在的文件鏡像沒(méi)有那個(gè)二進(jìn)制就會(huì)報(bào) Exit Code 127command not found如果二進(jìn)制存在但沒(méi)有執(zhí)行權(quán)限Exit Code 是 126。這類(lèi)問(wèn)題查起來(lái)最直接kubectl logs看一下就會(huì)看到 “exec: ...: not found” 或者權(quán)限錯(cuò)誤。第二類(lèi)是 ConfigMap 掛載問(wèn)題。Deployment 通過(guò) volume 掛載 ConfigMap 時(shí)如果 key 不存在、路徑寫(xiě)錯(cuò)了、或者掛載的配置文件名和應(yīng)用預(yù)期不一致應(yīng)用啟動(dòng)時(shí)找不到配置文件就直接退出。這類(lèi)問(wèn)題的坑在于它可能不是每次都會(huì)失敗因?yàn)槟承?yīng)用會(huì)根據(jù)環(huán)境變量或默認(rèn)值兜底只在特定條件下才讀某個(gè) key。我遇到過(guò)一個(gè)典型場(chǎng)景項(xiàng)目里把一個(gè) ConfigMap 的 key 從APP_CONF改成了app.confDeployment 里的掛載路徑也改了但新版本鏡像里的啟動(dòng)腳本讀的還是舊路徑線(xiàn)上直接 CrashLoopBackOffdescribe 里只看到MountVolume.SetUp failed的 events應(yīng)用日志基本為空或者只有一行 “file not found”。第三類(lèi)是啟動(dòng)腳本依賴(lài)外部依賴(lài)。比如應(yīng)用啟動(dòng)時(shí)要連接數(shù)據(jù)庫(kù)、Redis、或者注冊(cè)中心如果這些依賴(lài)沒(méi)就緒或者地址配錯(cuò)應(yīng)用會(huì)連接失敗后直接退出。這種在微服務(wù)架構(gòu)里特別常見(jiàn)癥狀和“代碼有問(wèn)題”非常像。排查時(shí)先看啟動(dòng)日志里的報(bào)錯(cuò)信息是connect refused還是unknown host前者查網(wǎng)絡(luò)和端口后者查 DNS 解析和 Service 配置。這里也順帶提醒一句不要一看到 CrashLoopBackOff 就懷疑代碼質(zhì)量先檢查配置聲明、環(huán)境變量、掛載卷再往深處挖。4. 從事件到日志一層層剝開(kāi)真相當(dāng)狀態(tài)、事件都看完了還沒(méi)有鎖定根因下一步才是日志。但日志的打開(kāi)方式也有講究很多人一頭扎進(jìn)kubectl logs猛翻結(jié)果看到的是重啟之后的“新”進(jìn)程日志上一輪進(jìn)程退出前寫(xiě)的“遺言”根本沒(méi)看見(jiàn)。4.1 kubectl logs --previous 才能看到上一輪的“遺言”在容器被重啟之后kubectl logs默認(rèn)顯示的是當(dāng)前容器進(jìn)程的輸出。如果當(dāng)前進(jìn)程又活了但上一輪是崩潰退出的你真正需要的是上一個(gè)進(jìn)程留下的日志。這時(shí)候必須加--previous參數(shù)kubectl logs pod-name -n namespace --previous --tail50這個(gè)命令會(huì)返回上一次容器實(shí)例的日志也就是崩潰前打印的最后 50 行。很多 CrashLoopBackOff 的真相就藏在這幾十行里。比如啟動(dòng)腳本報(bào)Caused by: java.lang.IllegalArgumentException: ...或者 Python 直接 traceback一目了然。有個(gè)需要注意的細(xì)節(jié)如果容器狀態(tài)已經(jīng)是 CrashLoopBackOffKubelet 會(huì)按退避策略等待一段時(shí)間才重啟下一次但--previous日志只在容器被重建之前有效。如果 Pod 已經(jīng)被刪除重建歷史容器日志就沒(méi)了。所以要趁重啟間隙趕緊抓或者用-f持續(xù)跟蹤當(dāng)前日志等到下一次崩潰瞬間的尾部輸出。我自己還會(huì)把日志推到 stdout 的同時(shí)寫(xiě)到本地文件萬(wàn)一崩潰太頻繁至少本地文件能留底。4.2 kubectl get events 是重建時(shí)間線(xiàn)的最好工具事件Events是 Kubernetes 的審計(jì)日志記錄了 Pod 生命周期里的每一個(gè)關(guān)鍵動(dòng)作。排查重啟問(wèn)題時(shí)我會(huì)把 Events 按時(shí)間排好序看一遍基本能把“誰(shuí)在什么時(shí)候干了什么”還原出來(lái)kubectl get events -n namespace --sort-by.lastTimestamp如果 Pod 很多可以加--field-selector只看目標(biāo) Podkubectl get events -n namespace --field-selector involvedObject.namepod-name --sort-by.lastTimestampEvents 里最有價(jià)值的幾類(lèi)信息Scheduled說(shuō)明 Pod 被調(diào)度到哪個(gè)節(jié)點(diǎn)Created/Started是容器創(chuàng)建的節(jié)點(diǎn)Killing或者Unhealthy往往是觸發(fā)重啟的直接原因Evicted則說(shuō)明是節(jié)點(diǎn)壓力導(dǎo)致驅(qū)逐。有一次我排查一個(gè) Pod 頻繁重啟應(yīng)用日志干凈得不行但 Events 里反復(fù)出現(xiàn)Liveness probe failed: HTTP probe failed with statuscode: 500緊接著又是Killing container。這一下就把嫌疑集中到了探針和它后面的應(yīng)用路徑上再往應(yīng)用層查探針接口為什么偶發(fā) 500就順理成章了。我在團(tuán)隊(duì)里常說(shuō)一句話(huà)Events 是案發(fā)現(xiàn)場(chǎng)的監(jiān)控錄像日志只是兇手臨走前留下的字條。先看錄像再讀字條順序不要反。很多人在kubectl logs里耗兩小時(shí)回頭一看 Events 里早就寫(xiě)得明明白白。4.3 別忽略節(jié)點(diǎn)層面kubelet 日志和節(jié)點(diǎn)健康狀況如果是節(jié)點(diǎn)層面的問(wèn)題比如 kubelet 崩潰、磁盤(pán)滿(mǎn)了、節(jié)點(diǎn)內(nèi)存不足光看 Pod 內(nèi)部的信息是看不出來(lái)的。這時(shí)候需要把視野從 Pod 提升到 Node 層。一條比較有用的命令是journalctl -u kubelet -n 200 --no-pagerkubelet 日志里能看到它對(duì)某個(gè)容器的SyncLoop判斷、探針失敗記錄、驅(qū)逐決策等信息。節(jié)點(diǎn)磁盤(pán)滿(mǎn)會(huì)導(dǎo)致鏡像拉取失敗、容器日志寫(xiě)不進(jìn)去甚至觸發(fā) Pod 驅(qū)逐節(jié)點(diǎn)內(nèi)存壓力觸發(fā)系統(tǒng) OOM 或者 Eviction Manager 介入Pod 會(huì)被標(biāo)記為Evicted。這些在 Pod 的 Events 里能看到但根因在節(jié)點(diǎn)上不結(jié)合起來(lái)看就容易誤判成應(yīng)用問(wèn)題。另外DNS 和網(wǎng)絡(luò)配置也經(jīng)常背鍋。有些應(yīng)用啟動(dòng)時(shí)需要解析外部的服務(wù)域名如果節(jié)點(diǎn)上的 DNS 配置有問(wèn)題Pod 里解析一直失敗應(yīng)用就反復(fù)啟動(dòng)退出。這種問(wèn)題我們?cè)?K8s 里排查時(shí)也可以借鑒一個(gè)思路系統(tǒng)層面“重啟能恢復(fù)”的怪毛病往往和某個(gè)服務(wù)狀態(tài)異常有關(guān)比如 DNS 緩存、網(wǎng)絡(luò)棧狀態(tài)先在事件里把時(shí)間點(diǎn)對(duì)齊再判斷到底是哪一層出了問(wèn)題。4.4 實(shí)操?gòu)?fù)盤(pán)一次 Java 服務(wù)頻繁重啟的完整排查說(shuō)一個(gè)我印象很深的實(shí)際案例。當(dāng)時(shí)線(xiàn)上有個(gè) Java 服務(wù)告警顯示 Pod RESTARTS 每隔 10 分鐘左右漲一次STATUS 一直是 Running。團(tuán)隊(duì)里有人說(shuō)“狀態(tài)正?？赡苁钦`報(bào)”但我看 RESTARTS 在漲就知道肯定有東西在殺容器。我執(zhí)行的第一條命令是kubectl describe pod看到 Last State 顯示 Exit Code 137但 Reason 并不是 OOMKilled而是空。這說(shuō)明不是內(nèi)存問(wèn)題那就有可能是探針失敗后 Kubelet 主動(dòng) SIGKILL。然后我用kubectl get events --sort-by.lastTimestamp看了一下時(shí)間線(xiàn)里面清楚地寫(xiě)著Unhealthy和Liveness probe failed: HTTP probe failed with statuscode: 500。再往前幾條 Events是/healthz返回 500 后探針連續(xù)失敗。接下來(lái)我沒(méi)有繼續(xù)翻業(yè)務(wù)日志而是先看探針配置timeoutSeconds默認(rèn)是 1 秒但服務(wù)的/healthz接口在 GC 發(fā)生時(shí)會(huì)偶爾慢過(guò) 1 秒。FS 小哥也確認(rèn)服務(wù)堆內(nèi)存較大Full GC 時(shí)停頓能達(dá)到好幾秒。于是我把探針的timeoutSeconds調(diào)到了 5periodSeconds保持 10 秒同時(shí)讓?xiě)?yīng)用團(tuán)隊(duì)優(yōu)化 GC 參數(shù)問(wèn)題很快就不再出現(xiàn)。四步定位先看狀態(tài)排掉分支再看 describe 鎖定退出碼再用 Events 找到直接觸發(fā)原因最后結(jié)合探針配置和應(yīng)用行為制定修復(fù)方案。全程沒(méi)靠猜這就是順序的力量。5. 還要小心“看似 Pod 重啟”的干擾項(xiàng)排查 Pod 重啟問(wèn)題最怕的不是根因復(fù)雜而是被干擾項(xiàng)帶偏方向。有幾種情況和“Pod 重啟”非常像但實(shí)際上完全是另一碼事。如果在第一步?jīng)]識(shí)別出來(lái)后面所有精力都白費(fèi)。5.1 節(jié)點(diǎn)重啟導(dǎo)致一批 Pod 同時(shí)“重啟”節(jié)點(diǎn)宕機(jī)、系統(tǒng)升級(jí)、硬件被重啟會(huì)導(dǎo)致節(jié)點(diǎn)上的所有 Pod 突然消失隨后重新調(diào)度到其他節(jié)點(diǎn)甚至同一個(gè)節(jié)點(diǎn)重啟回來(lái)。這種時(shí)候你在kubectl get pods里看到一堆 Pod 的 AGE 都?xì)w零RESTARTS 也可能歸零第一反應(yīng)可能是“某個(gè)應(yīng)用掛了”實(shí)際上你看到的是一整批 Pod 被重建。怎么判斷先看kubectl get nodes里節(jié)點(diǎn)的 AGE 和 CONDITIONS。如果節(jié)點(diǎn) Uptime 只有幾分鐘再看 kubelet 的啟動(dòng)時(shí)間基本能確認(rèn)是不是節(jié)點(diǎn)層重啟。另外看 Pod 是不是分布在同一個(gè)節(jié)點(diǎn)上特別關(guān)鍵。如果重啟的 Pod 集中在同一個(gè) Node 上那問(wèn)題大概率不在應(yīng)用而在節(jié)點(diǎn)生命周期。這就像 Windows 系統(tǒng)重啟后開(kāi)機(jī)黑屏、拔掉網(wǎng)線(xiàn)就正常的那種“硬故障”你得先查系統(tǒng)底層和驅(qū)動(dòng)而不是在應(yīng)用層摳日志。5.2 Evicted 和搶占Pod 被驅(qū)逐而非崩潰節(jié)點(diǎn)有磁盤(pán)壓力、內(nèi)存壓力、PID 壓力時(shí)kubelet 會(huì)執(zhí)行驅(qū)逐策略把一部分 Pod 標(biāo)記為Evicted隨后刪除。被驅(qū)逐的 Pod 通常不是“崩潰”了而是“被請(qǐng)走”了。它們的 STATUS 會(huì)顯示Evicteddescribe 里能看到類(lèi)似node.kubernetes.io/disk-pressure的污點(diǎn)和事件。這種情況如果你只盯著應(yīng)用日志會(huì)發(fā)現(xiàn)什么異常都沒(méi)有因?yàn)閼?yīng)用可能是被 SIGTERM 優(yōu)雅停掉的甚至日志里只有 graceful shutdown 的記錄。真正要查的是節(jié)點(diǎn)層面的監(jiān)控磁盤(pán)使用率、內(nèi)存水位、inode 數(shù)量。如果節(jié)點(diǎn)磁盤(pán)滿(mǎn)了鏡像拉取、日志寫(xiě)入都會(huì)出問(wèn)題Pod 也會(huì)被優(yōu)先驅(qū)逐。另外如果集群里有搶占式 PodPriorityClass 很高低優(yōu)先級(jí)的 Pod 可能會(huì)被搶占刪除這在 Events 里能看到Preempting相關(guān)條目。5.3 滾動(dòng)更新和配置變更造成的“假重啟”Deployment 升級(jí)鏡像、修改副本參數(shù)、或者觸發(fā)rollout restart都會(huì)創(chuàng)建新的 ReplicaSet然后滾動(dòng)替換舊 Pod。這時(shí)候你會(huì)看到舊 Pod 被刪、新 Pod 被創(chuàng)建表面上也是“Pod 重啟”但這是一個(gè)期望中的發(fā)布動(dòng)作不是故障。判斷方法很簡(jiǎn)單看 ReplicaSet。kubectl get rs -n namespace如果出現(xiàn)了新的 ReplicaSet且新舊并行那就說(shuō)明是發(fā)布不是故障。還有kubectl rollout status deployment/name能直接看到當(dāng)前部署狀態(tài)。這里有個(gè)工程上的常見(jiàn)坑修改 ConfigMap 并不會(huì)自動(dòng)觸發(fā) Deployment 滾動(dòng)更新很多人改了配置后手動(dòng)刪除 Pod 讓它重建如果 ConfigMap 名稱(chēng)沒(méi)變很多場(chǎng)景下 kubelet 不會(huì)重新拉取最新的配置掛載雖然新版 K8s 有了更細(xì)的優(yōu)化但很多情況下還是需要顯式觸發(fā)。規(guī)范做法是配置變更后執(zhí)行kubectl rollout restart deployment/name讓它走一遍新 ReplicaSet 的滾動(dòng)邏輯而不是手動(dòng)隨機(jī)刪 Pod。5.4 云廠(chǎng)商底層故障與基礎(chǔ)設(shè)施漂移最后一個(gè)干擾項(xiàng)來(lái)自基礎(chǔ)設(shè)施層。節(jié)點(diǎn)出現(xiàn) NotReady、被云平臺(tái)自動(dòng)重啟、或者底層網(wǎng)絡(luò)設(shè)備故障也可能導(dǎo)致 Pod 重啟。這種情況下Pod 層面能看到的只有“節(jié)點(diǎn)失聯(lián)”“容器重建”之類(lèi)的結(jié)果根因在集群之外。排查時(shí)要結(jié)合云平臺(tái)的控制臺(tái)事件和節(jié)點(diǎn)監(jiān)控把時(shí)間線(xiàn)對(duì)齊。很多 SRE 在這類(lèi)問(wèn)題上有過(guò)慘痛教訓(xùn)排查一整天應(yīng)用側(cè)毫無(wú)頭緒最后發(fā)現(xiàn)是底層虛擬機(jī)漂移。6. 如何減少 Pod 重啟探針與資源的工程化實(shí)踐排查問(wèn)題很重要但更值得花時(shí)間的是讓這些問(wèn)題少發(fā)生。Pod 重啟這件事尤其是探針 OOM 和配置不當(dāng)引發(fā)的重啟大部分是可以在架構(gòu)和配置層面提前規(guī)避的。這一節(jié)我把它沉淀成幾個(gè)工程化建議。6.1 探針配置的量化建議和模板探針不是越嚴(yán)格越好而是要符合應(yīng)用的實(shí)際啟動(dòng)時(shí)間和對(duì)瞬時(shí)故障的容忍度。我通常按下面這個(gè)模板來(lái)配置livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 60 periodSeconds: 10 timeoutSeconds: 3 failureThreshold: 3 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 60 periodSeconds: 5 timeoutSeconds: 2 failureThreshold: 2解釋一下幾個(gè)關(guān)鍵參數(shù)的思路。initialDelaySeconds要覆蓋應(yīng)用最慢啟動(dòng)時(shí)間寧大勿小至少要在“實(shí)測(cè)從容器創(chuàng)建到接口可響應(yīng)”的時(shí)間基礎(chǔ)上再加 20 秒冗余。timeoutSeconds別用默認(rèn)的 1 秒除非你確認(rèn)應(yīng)用接口響應(yīng)永遠(yuǎn)在毫秒級(jí)否則至少給 3 秒。failureThreshold不建議堆到幾十次那等于把探針變成了擺設(shè)合理區(qū)間是 2—5 次既能容忍偶發(fā)抖動(dòng)又不至于讓不健康容器長(zhǎng)期留在服務(wù)里。還有一條很重要的原則探針路徑必須輕量。不要把數(shù)據(jù)庫(kù)連接檢查、下游依賴(lài)檢查都塞進(jìn)/healthz里否則數(shù)據(jù)庫(kù)抖動(dòng)一次所有 Pod 一起重啟這是典型的故障放大。健康檢查應(yīng)該只反映本進(jìn)程的存活狀態(tài)下游依賴(lài)的狀態(tài)交給業(yè)務(wù)層的熔斷和報(bào)告機(jī)制。6.2 資源配額與 JVM/內(nèi)存優(yōu)化內(nèi)存類(lèi)應(yīng)用最容易因 OOM 和重啟糾纏不清所以資源配額不能拍腦袋。我的建議是requests必須設(shè)不要只給limits。只給 limits 不給 requests會(huì)導(dǎo)致調(diào)度器以為節(jié)點(diǎn)資源很寬裕實(shí)際運(yùn)行時(shí)卻在高水位很容易觸發(fā)節(jié)點(diǎn)級(jí)壓力。盡量讓 requests 等于實(shí)際穩(wěn)態(tài)占用limits 比 requests 高出一定冗余比如 1.2 到 1.5 倍但不要差距過(guò)大否則會(huì)削弱 QoS 保障。JVM 應(yīng)用有一個(gè)鐵律-Xmx必須小于容器 limits而且要留足堆外空間。粗略估算時(shí)容器 limits 可以按“堆內(nèi)存的 1.5 倍”起步比如-Xmx2g的容器limits 至少給 3Gi。如果有大量線(xiàn)程、堆外緩存或者 NIO 緩沖還要再上調(diào)。要不然你總會(huì)遇到那種“明明堆內(nèi)存還有一半容器卻被 OOM 殺掉”的詭異問(wèn)題實(shí)際上元空間和堆外早就爆了。集群層還可以用 LimitRanger 和 ResourceQuota 兜底避免某個(gè)團(tuán)隊(duì)隨手寫(xiě)一個(gè)巨大的 limits。這些策略看起來(lái)是約束實(shí)際上是在保護(hù)整個(gè)集群的穩(wěn)定性也保護(hù)你自己的服務(wù)不會(huì)互相踩踏。6.3 配置變更與發(fā)布策略ConfigMap 和 Deployment 是結(jié)對(duì)出現(xiàn)的但配置變了不會(huì)自動(dòng)滾動(dòng)更新這是很多人栽過(guò)跟頭的地方。工程化的做法是ConfigMap 一旦創(chuàng)建不要原地修改而是新版本命名空間下重建一個(gè) ConfigMap比如帶 v2 后綴然后通過(guò)修改 Deployment 里的 configMap 引用并執(zhí)行kubectl rollout restart。這樣既保留歷史版本又能回滾。K8s 1.20 還支持 ConfigMap 的immutable: true選項(xiàng)直接禁止原地修改避免誤操作。滾動(dòng)發(fā)布的參數(shù)也值得精確控制。Deployment 里的maxSurge和maxUnavailable決定滾動(dòng)的節(jié)奏。舉例strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0這個(gè)配置的意思是滾動(dòng)過(guò)程中最多額外創(chuàng)建一個(gè)新 Pod并且不允許服務(wù)實(shí)例數(shù)降到期望值以下。適合在線(xiàn)服務(wù)能最大程度保證容量。缺點(diǎn)是發(fā)布速度慢一些但換來(lái)的安全感非常值。尤其是你的服務(wù)有流量突刺maxUnavailable: 0能避免發(fā)布瞬間大量請(qǐng)求 503。另外給容器加preStophook 是減少“被 SIGKILL”的有效手段lifecycle: preStop: exec: command: [/bin/sh, -c, sleep 5]Kubelet 在收到停止信號(hào)時(shí)先執(zhí)行 preStop 的 sleep再發(fā) SIGTERM 給主進(jìn)程。這幾秒時(shí)間能讓?xiě)?yīng)用把進(jìn)行中的請(qǐng)求處理完把連接優(yōu)雅關(guān)閉。對(duì)很多服務(wù)端應(yīng)用來(lái)說(shuō)少了這 5 秒后面省下的排障時(shí)間可能是幾個(gè)小時(shí)的量級(jí)。6.4 建立“重啟即告警”的可觀(guān)測(cè)性與其等用戶(hù)反饋“服務(wù)掛了一會(huì)兒”不如在重啟剛開(kāi)始時(shí)就收到告警。Prometheus 生態(tài)里kube-state-metrics 會(huì)暴露一個(gè)指標(biāo)kube_pod_container_status_restarts_total記錄容器累計(jì)重啟次數(shù)。可以用它做一條簡(jiǎn)單的告警規(guī)則- alert: ContainerRestarting expr: increase(kube_pod_container_status_restarts_total[5m]) 2 for: 5m labels: severity: warning annotations: summary: Pod {{ $labels.namespace }}/{{ $labels.pod }} container {{ $labels.container }} restarting意思是“5 分鐘內(nèi)某個(gè)容器重啟超過(guò) 2 次并且持續(xù) 5 分鐘”就觸發(fā)告警。這個(gè)閾值比 CrashLoopBackOff 出現(xiàn)早得多往往在探針開(kāi)始反復(fù)殺容器、但還沒(méi)進(jìn)入退避階段的時(shí)候就能報(bào)警。事后分析時(shí)事件和日志也應(yīng)該盡量留存到外部系統(tǒng)比如 Loki、Elasticsearch否則 Pod 被重建之后很多現(xiàn)場(chǎng)證據(jù)就瞬間蒸發(fā)了。6.5 一個(gè)小技巧臨時(shí)容器調(diào)試啟動(dòng)即退出的問(wèn)題最后分享一個(gè)挺實(shí)用的技巧。如果你遇到容器啟動(dòng)即退出、日志也沒(méi)留下什么有效信息又來(lái)不及把鏡像拉出來(lái)手動(dòng)跑可以借助臨時(shí)容器ephemeral container進(jìn)到 Pod 里“圍觀(guān)”。前提是 Kubernetes 版本在 1.23 以上并且集群?jiǎn)⒂昧讼嚓P(guān)特性。命令類(lèi)似kubectl debug -it pod-name -n namespace --imagebusybox --targetcontainer-name臨時(shí)容器會(huì)共享目標(biāo)容器的命名空間你可以在里面看文件、查網(wǎng)絡(luò)、檢查掛載內(nèi)容甚至手工執(zhí)行目標(biāo)命令親眼看到它到底報(bào)什么錯(cuò)。如果臨時(shí)容器一時(shí)半會(huì)兒進(jìn)不去還有個(gè)土辦法先把 Deployment 的啟動(dòng)命令臨時(shí)改成command: [sleep, 9999]讓容器穩(wěn)定跑起來(lái)再kubectl exec進(jìn)入容器手動(dòng)執(zhí)行原來(lái)的啟動(dòng)命令看完整報(bào)錯(cuò)。這個(gè)辦法唯一的代價(jià)是業(yè)務(wù)暫時(shí)不提供服務(wù)但在測(cè)試環(huán)境或者低峰期效率遠(yuǎn)超來(lái)回翻日志。排查了這么多 Pod 重啟問(wèn)題我自己最深的一個(gè)體會(huì)是流程比經(jīng)驗(yàn)靠譜。第一次遇到 CrashLoopBackOff 我也慌日志翻到頭大后來(lái)發(fā)現(xiàn)只要按“狀態(tài) → 事件 → 日志 → 節(jié)點(diǎn)”這個(gè)順序查80% 的問(wèn)題十分鐘內(nèi)都能定位。最后再分享一個(gè)小習(xí)慣每次排查完把 describe 輸出和 events 存一份到本地筆記里。很多問(wèn)題過(guò)兩個(gè)月會(huì)以非常相似的形態(tài)再出現(xiàn)翻舊案比從零開(kāi)始排查快得多而且你會(huì)慢慢發(fā)現(xiàn)Kubernetes 的故障雖然花樣多但底層邏輯永遠(yuǎn)是那幾板斧。