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