?在之前的記一次k8s pod頻繁重啟的優(yōu)化之旅中分享過對于pod頻繁重啟的一些案例，最近又遇到一例，繼續(xù)分享出來希望能給大家?guī)硇┰S收獲。
問題現(xiàn)象
報警群里突然顯示某pod頻繁重啟，我隨即上去查看日志，主要分這么幾步：??
1.查看pod重啟的原因，kubectl descirbe pod
Last State: Terminated
Reason: Error
Exit Code: 137
上面的Reason：Error太寬泛了，不能直觀的知道原因，Exit code：137一般表示程序被?SIGKILL?中斷信號殺死，異常原因可能為：
?https://cloud.tencent.com/document/product/457/42945
首先排除OOMKilled情況，剩余的就是livenessProbe（存活檢查）失敗。
2.查看pod事件，kubectl descirbe pod，重點(diǎn)關(guān)注輸出的Events部分
Warning Unhealthy 2m56s (x8 over 7m16s) kubelet Liveness probe failed: Get http://10.244.11.136:8080/jc_actuator_1/health: net/http: request canceled (Client.Timeout exceeded while awaiting headers) Normal Killing 2m56s kubelet Container enterprise-service failed liveness probe, will be restarted
熟悉的健康檢查失?。ǔ瑫r），是什么導(dǎo)致超時呢，繼續(xù)找日志。
3.結(jié)合之前的排查經(jīng)驗(yàn)，我認(rèn)為gc的嫌疑最大，所以查看gc日志
貼一部分日志，可以看到Full GC很繁忙，而且每次結(jié)束后內(nèi)存幾乎沒有釋放，應(yīng)用已經(jīng)是處于停擺狀態(tài)，接下來要做的就是找出Full GC的兇手。
2023-04-22T14:30:58.772+0000: 574.764: [Full GC (Allocation Failure) 2023-04-22T14:30:58.772+0000: 574.764: [Tenured: 2097151K->2097151K(2097152K), 3.6358812 secs] 2569023K->2568977K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.6359987 secs] [Times: user=3.64 sys=0.00, real=3.63 secs] 2023-04-22T14:31:02.410+0000: 578.402: [Full GC (Allocation Failure) 2023-04-22T14:31:02.410+0000: 578.402: [Tenured: 2097151K->2097151K(2097152K), 3.5875116 secs] 2569023K->2568980K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.5876388 secs] [Times: user=3.59 sys=0.00, real=3.59 secs] 2023-04-22T14:31:05.999+0000: 581.991: [Full GC (Allocation Failure) 2023-04-22T14:31:05.999+0000: 581.991: [Tenured: 2097152K->2097151K(2097152K), 3.5950824 secs] 2569024K->2568987K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.5951774 secs] [Times: user=3.59 sys=0.00, real=3.60 secs] 2023-04-22T14:31:09.596+0000: 585.587: [Full GC (Allocation Failure) 2023-04-22T14:31:09.596+0000: 585.587: [Tenured: 2097151K->2097151K(2097152K), 3.5822343 secs] 2569023K->2568849K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.5823244 secs] [Times: user=3.58 sys=0.00, real=3.58 secs] 2023-04-22T14:31:13.180+0000: 589.172: [Full GC (Allocation Failure) 2023-04-22T14:31:13.180+0000: 589.172: [Tenured: 2097151K->2097151K(2097152K), 3.6316461 secs] 2569020K->2568910K(2569024K), [Metaspace: 119380K->119380K(1163264K)], 3.6317393 secs] [Times: user=3.63 sys=0.00, real=3.64 secs] 2023-04-22T14:31:16.813+0000: 592.805: [Full GC (Allocation Failure) 2023-04-22T14:31:16.813+0000: 592.805: [Tenured: 2097151K->2097151K(2097152K), 3.6070671 secs] 2569021K->2568907K(2569024K), [Metaspace: 119380K->119380K(1163264K)], 3.6071998 secs] [Times: user=3.60 sys=0.00, real=3.60 secs] 2023-04-22T14:31:20.425+0000: 596.417: [Full GC (Allocation Failure) 2023-04-22T14:31:20.425+0000: 596.417: [Tenured: 2097151K->2097151K(2097152K), 4.7111087 secs] 2569020K->2568899K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 4.7112440 secs] [Times: user=4.71 sys=0.00, real=4.71 secs] 2023-04-22T14:31:25.142+0000: 601.133: [Full GC (Allocation Failure) 2023-04-22T14:31:25.142+0000: 601.133: [Tenured: 2097151K->2097151K(2097152K), 3.8752248 secs] 2569023K->2568899K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 3.8753506 secs] [Times: user=3.88 sys=0.01, real=3.87 secs] 2023-04-22T14:31:29.021+0000: 605.012: [Full GC (Allocation Failure) 2023-04-22T14:31:29.021+0000: 605.012: [Tenured: 2097151K->2097151K(2097152K), 3.5892311 secs] 2569023K->2568910K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 3.5893335 secs] [Times: user=3.59 sys=0.00, real=3.59 secs] 2023-04-22T14:31:32.612+0000: 608.604: [Full GC (Allocation Failure) 2023-04-22T14:31:32.612+0000: 608.604: [Tenured: 2097151K->2097151K(2097152K), 3.5236182 secs] 2569023K->2568915K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 3.5237085 secs] [Times: user=3.52 sys=0.00, real=3.52 secs]
背景知識
我們的服務(wù)部署在k8s中，k8s可以對容器執(zhí)行定期的診斷，要執(zhí)行診斷，kubelet 調(diào)用由容器實(shí)現(xiàn)的 Handler （處理程序）。有三種類型的處理程序：
-
ExecAction：在容器內(nèi)執(zhí)行指定命令。如果命令退出時返回碼為 0 則認(rèn)為診斷成功。
-
TCPSocketAction：對容器的 IP 地址上的指定端口執(zhí)行 TCP 檢查。如果端口打開，則診斷被認(rèn)為是成功的。
-
HTTPGetAction：對容器的 IP 地址上指定端口和路徑執(zhí)行 HTTP Get 請求。如果響應(yīng)的狀態(tài)碼大于等于 200 且小于 400，則診斷被認(rèn)為是成功的。
每次探測都將獲得以下三種結(jié)果之一：
-
Success（成功）：容器通過了診斷。
-
Failure（失?。喝萜魑赐ㄟ^診斷。
-
Unknown（未知）：診斷失敗，因此不會采取任何行動。
針對運(yùn)行中的容器，kubelet 可以選擇是否執(zhí)行以下三種探針，以及如何針對探測結(jié)果作出反應(yīng)：
-
livenessProbe：指示容器是否正在運(yùn)行。如果存活態(tài)探測失敗，則 kubelet 會殺死容器， 并且容器將根據(jù)其重啟策略決定未來。如果容器不提供存活探針， 則默認(rèn)狀態(tài)為 Success。
-
readinessProbe：指示容器是否準(zhǔn)備好為請求提供服務(wù)。如果就緒態(tài)探測失敗， 端點(diǎn)控制器將從與 Pod 匹配的所有服務(wù)的端點(diǎn)列表中刪除該 Pod 的 IP 地址。初始延遲之前的就緒態(tài)的狀態(tài)值默認(rèn)為 Failure。如果容器不提供就緒態(tài)探針，則默認(rèn)狀態(tài)為 Success。
-
startupProbe: 指示容器中的應(yīng)用是否已經(jīng)啟動。如果提供了啟動探針，則所有其他探針都會被 禁用，直到此探針成功為止。如果啟動探測失敗，kubelet 將殺死容器，而容器依其?重啟策略進(jìn)行重啟。如果容器沒有提供啟動探測，則默認(rèn)狀態(tài)為 Success。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
以上探針介紹內(nèi)容來源于https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
尋找原因
前面提到是由于Full GC STW導(dǎo)致jvm無法提供服務(wù)，那我們就看看是什么導(dǎo)致Full GC，具體的手段就是獲取heap? dump文件，然后分析，什么時機(jī)去獲取呢？
這里采用的辦法是守株待兔，開兩個窗口，一個盯著gc日志，當(dāng)看到有大量Full GC產(chǎn)生時在另一個窗口生成heap dump文件。
接下來通過Eclipse MAT工具分析dump文件
?原因一目了然，是導(dǎo)出excel導(dǎo)致，涉及的數(shù)據(jù)接近10w條，且列比較多。
分析代碼
大概看了一下導(dǎo)出的代碼，問題集中在以下四點(diǎn):
1.查詢數(shù)據(jù)沒有使用分頁；
2.使用的Apache poi工具本身性能不好，內(nèi)存占用過高；
3.導(dǎo)出沒有限流，對于極度消耗資源的操作必須要控制并發(fā)，保護(hù)系統(tǒng)；
4.同步導(dǎo)出，用戶等待時間過長時會選擇重試，對系統(tǒng)來講是雪上加霜。
改進(jìn)措施
1.查詢分頁，保證往excel寫數(shù)據(jù)時內(nèi)存中只會有一頁數(shù)據(jù)；
2.使用性能更好的工具，如easyexcel;
3.異步導(dǎo)出，控制同時導(dǎo)出的并發(fā)數(shù)；
經(jīng)過這三步改造以后，導(dǎo)出導(dǎo)致的Full GC問題得以改善，上線一周再沒有發(fā)現(xiàn)由于大數(shù)據(jù)量的導(dǎo)出導(dǎo)致的pod重啟問題。
推薦閱讀
1.容器服務(wù)pod異常排查
https://cloud.tencent.com/document/product/457/42945
2.通過Exit Code定位 Pod 異常退出原因
https://cloud.tencent.com/document/product/457/43125
3.pod異常問題排查
https://help.aliyun.com/document_detail/412618.html#6
4. easyexcel
http://easyexcel.opensource.alibaba.com/
文章來源：http://www.zghlxwxcb.cn/news/detail-433170.html
?文章來源地址http://www.zghlxwxcb.cn/news/detail-433170.html
?
到了這里，關(guān)于案例分享-full gc導(dǎo)致k8s pod重啟的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
