kubernetes中不可見的OOM

最近看了一篇文章:Tracking Down “Invisible” OOM Kills in Kubernetes,其講述的是由於內存不足導致Pod中的進程被killed,但Pod並沒有重啓,也沒有任何日誌或kubernetes事件,只有一個"Exit Code: 137"的信息,導致難以進一步定位問題。最後還是通過查看節點系統日誌才發現如下信息:

kernel: Memory cgroup out of memory: Killed process 18661 (helm) total-vm:748664kB, anon-rss:41748kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:244kB oom_score_adj:992

kernel: oom_reaper: reaped process 18661 (helm), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

在上述文章中,作者做了個總結:

When the Linux OOM Killer activated, it selected a process within the container to be killed. Apparently only when OOM selects the container’s init process PID 1 will the container itself be killed and have a status of OOMKilled. If that container was marked as restartable, then Kubernetes would restart the container and then you would see an increase in restart count.

As I’ve seen, when PID 1 is not selected then some other process inside the container is killed. This makes it “invisible” to Kubernetes. If you are not watching the tty console device or scanning kernel logs, you may not know that part of your containers are being killed. Something to consider when you enable container memory limits.

大意就是隻有Pod中的PID 1被OOM kill時纔會出現OOMKilled狀態,並重啓容器,此時我們可以清除地看到OOM信息。

但在出現問題的場景中,被kill的並不是PID 1,這就導致容器或kubernetes無法記錄相關信息,且不會重啓容器。這種情況下只能通過查看系統日誌才能發現相關信息。

文中也提出了一種解決該問題的方式:VPA

PS

我之前也遇到過類似的問題,當問題出現時,也只是有個"Exit Code: 137"信息,Pod正常運行,沒有任何錯誤日誌和事件,但其實Pod內的某個進程已經被killed,無法執行正常功能。

出現"被隱藏的OOM"的原因可能是Pod中單獨啓動了多個獨立的進程(進程間無父子關係),在我的場景中就是單獨啓動了一個腳本進程,當內存不足的時候會導致kill腳本進程。因此還有一種解決思路就是,如果要啓動多個獨立的進程,還可以將其作爲sidecar方式,避免出現這種問題。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章