問(wèn)題描述

今天下午運(yùn)維反饋說(shuō)我們這一個(gè)pod一天重啟了8次，需要排查下原因。一看Kiban日志，jvm沒(méi)有拋出過(guò)任何錯(cuò)誤，服務(wù)就直接重啟了。顯然是進(jìn)程被直接殺了，初步判斷是pod達(dá)到內(nèi)存上限被K8s oomkill了。

因?yàn)槲覀儀mx和xsx設(shè)置的都是3G，而pod的內(nèi)存上限設(shè)置的是6G，所以出現(xiàn)這種情況還挺詭異的。

排查過(guò)程

初步定位

先找運(yùn)維拉了一下pod的描述，關(guān)鍵信息在這里

Containers:
  container-prod--:
    Container ID:   --
    Image:          --
    Image ID:       docker-pullable://--
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Fri, 05 Jan 2024 1101 +0800
    Last State:     Terminated
      Reason:       Error
      Exit Code:    137
      Started:      Fri, 05 Jan 2024 1138 +0800
      Finished:     Fri, 05 Jan 2024 1158 +0800
    Ready:          True
    Restart Count:  8
    Limits:
      cpu:     8
      memory:  6Gi
    Requests:
      cpu:        100m
      memory:     512Mi

可以看到Last State：Terminated，Exit Code: 137。這個(gè)錯(cuò)誤碼表示的是pod進(jìn)程被SIGKILL給殺掉了。一般情況下是因?yàn)閜od達(dá)到內(nèi)存上限被k8s殺了。

因此得出結(jié)論是生產(chǎn)環(huán)境暫時(shí)先擴(kuò)大下pod的內(nèi)存限制，讓服務(wù)穩(wěn)住。然后再排查為啥pod里會(huì)有這么多的堆外內(nèi)存占用。

進(jìn)一步分析

但是運(yùn)維反饋說(shuō)無(wú)法再擴(kuò)大pod的內(nèi)存限制，因?yàn)樗拗鳈C(jī)的內(nèi)存已經(jīng)占到了99%了。

然后結(jié)合pod的內(nèi)存監(jiān)控，發(fā)現(xiàn)pod被殺前的內(nèi)存占用只到4G左右，沒(méi)有達(dá)到上限的6G，pod就被kill掉了。

于是問(wèn)題就來(lái)了，為啥pod沒(méi)有達(dá)到內(nèi)存上限就被kill了呢。

帶著疑問(wèn)，我開(kāi)始在google里尋找答案，也發(fā)現(xiàn)了一些端倪：

如果是pod內(nèi)存達(dá)到上限被kill，pod的描述里會(huì)寫(xiě)Exit Code: 137，但是Reason不是Error，而是OOMKilled

宿主機(jī)內(nèi)存已經(jīng)吃滿，會(huì)觸發(fā)k8s的保護(hù)機(jī)制，開(kāi)始evict一些pod來(lái)釋放資源

但是為什么整個(gè)集群里，只有這個(gè)pod被反復(fù)evict，其他服務(wù)沒(méi)有影響？

謎題解開(kāi)

最終還是google給出了答案：

Why my pod gets OOMKill (exit code 137) without reaching threshold of requested memory

鏈接里的作者遇到了和我一樣的情況，pod還沒(méi)吃到內(nèi)存上限就被殺了，而且也是：

  Last State:     Terminated
      Reason:       Error
      Exit Code:    137

作者最終定位的原因是因?yàn)閗8s的QoS機(jī)制，在宿主機(jī)資源耗盡的時(shí)候，會(huì)按照QoS機(jī)制的優(yōu)先級(jí)，去殺掉pod來(lái)釋放資源。

什么是k8s的QoS？

QoS，指的是Quality of Service，也就是k8s用來(lái)標(biāo)記各個(gè)pod對(duì)于資源使用情況的質(zhì)量,QoS會(huì)直接影響當(dāng)節(jié)點(diǎn)資源耗盡的時(shí)候k8s對(duì)pod進(jìn)行evict的決策。官方的描述在這里.

k8s會(huì)以pod的描述文件里的資源限制，對(duì)pod進(jìn)行分級(jí)：

當(dāng)節(jié)點(diǎn)資源耗盡的時(shí)候，k8s會(huì)按照BestEffort->Burstable->Guaranteed這樣的優(yōu)先級(jí)去選擇殺死pod去釋放資源。

從上面運(yùn)維給我們的pod描述可以看到，這個(gè)pod的資源限制是這樣的:

    Limits:
      cpu:     8
      memory:  6Gi
    Requests:
      cpu:        100m
      memory:     512Mi

顯然符合的是Burstable的標(biāo)準(zhǔn)，所以宿主機(jī)內(nèi)存耗盡的情況下，如果其他服務(wù)都是Guaranteed，那自然會(huì)一直殺死這個(gè)pod來(lái)釋放資源，哪怕pod本身并沒(méi)有達(dá)到6G的內(nèi)存上限。

QoS相同的情況下，按照什么優(yōu)先級(jí)去Evict？

但是和運(yùn)維溝通了一下，我們集群內(nèi)所有pod的配置，limit和request都是不一樣的，也就是說(shuō)，大家都是Burstable。所以為什么其他pod沒(méi)有被evict，只有這個(gè)pod被反復(fù)evict呢？

QoS相同的情況，肯定還是會(huì)有evict的優(yōu)先級(jí)的，只是需要我們?cè)偃ふ蚁鹿俜轿臋n。

關(guān)于Node資源耗盡時(shí)候的Evict機(jī)制，官方文檔有很詳細(xì)的描述。

其中最關(guān)鍵的一段是這個(gè):

If the kubelet can't reclaim memory before a node experiences OOM, theoom_killercalculates anoom_scorebased on the percentage of memory it's using on the node, and then adds theoom_score_adjto get an effectiveoom_scorefor each container. It then kills the container with the highest score.

This means that containers in low QoS pods that consume a large amount of memory relative to their scheduling requests are killed first.

簡(jiǎn)單來(lái)說(shuō)就是pod evict的標(biāo)準(zhǔn)來(lái)自oom_score，每個(gè)pod都會(huì)被計(jì)算出來(lái)一個(gè)oom_score，而oom_score的計(jì)算方式是：pod使用的內(nèi)存占總內(nèi)存的比例加上pod的oom_score_adj值。

oom_score_adj的值是k8s基于QoS計(jì)算出來(lái)的一個(gè)偏移值，計(jì)算方法：

從這個(gè)表格可以看出：
首先是BestEffort->Burstable->Guaranteed這樣的一個(gè)整體的優(yōu)先級(jí)
然后都是Burstable的時(shí)候，pod實(shí)際占用內(nèi)存/pod的request內(nèi)存比例最高的，會(huì)被優(yōu)先Evict

總結(jié)

至此已經(jīng)可以基本上定位出Pod被反復(fù)重啟的原因了：

k8s節(jié)點(diǎn)宿主機(jī)內(nèi)存占用滿了，觸發(fā)了Node-pressure Eviction
按照Node-pressure Eviction的優(yōu)先級(jí)，k8s選擇了oom_score最高的pod去evict
由于所有pod都是Burstable，并且設(shè)置的request memery都是一樣的512M，因此內(nèi)存占用最多的pod計(jì)算出來(lái)的oom_score就是最高的
所有pod中，這個(gè)服務(wù)的內(nèi)存占用一直都是最高的，所以每次計(jì)算出來(lái)，最后都是殺死這個(gè)pod

那么如何解決呢？

宿主機(jī)內(nèi)存擴(kuò)容，不然殺死pod這樣的事情無(wú)法避免，無(wú)非就是殺哪個(gè)的問(wèn)題

對(duì)于關(guān)鍵服務(wù)的pod，要把request和limit設(shè)置為完全一致，讓pod的QoS置為Guaranteed，盡可能降低pod被殺的幾率。

審核編輯：劉清