GCP容器中可能的OOM - 如何調試？

我把芹菜放在GCP的碼頭集裝箱上，並裝上Kubernetes。它的工作人員最近開始獲得kill -9'd - 這看起來與OOMKiller有關。有沒有OOM事件kubectl get events，這是如果這些事件只出現在一個吊艙已經擅自闖入resources.limits.memory值可以預期的東西。GCP容器中可能的OOM - 如何調試？

所以，我的理論是被殺芹菜過程Linux的自己OOMKiller的工作。然而這並沒有任何意義：如果OOMKiller進入舞臺會消耗太多的內存，那麼這個吊艙怎麼可能安排在第一位呢？（假設如果resources.limits.memory的總和超過系統可用內存量，Kubernetes不允許調度新的豆莢）。

不過，我不知道有任何其他合理的原因，這些SIGKILLs比OOMKiller。

芹菜錯誤的一個例子（有一個用於每個工人）：

[2017-08-12 07:00:12,124: ERROR/MainProcess] Process 'ForkPoolWorker-7' pid:16 exited with 'signal 9 (SIGKILL)' 
[2017-08-12 07:00:12,208: ERROR/MainProcess] Task handler raised error: WorkerLostError('Worker exited prematurely: signal 9 (SIGKILL).',)

來源

2017-08-12 Pavel Vlasov

這是否引發任何光線'grep的-i「殺進程」的/ var /日誌/ messages' –

@TarunLalwani容器內和節點本身沒有這樣的路徑。 –

您正在使用哪個主機操作系統？ –

容器可以OOMKilled有兩個原因。

如果它們超過了設置的內存限制。限制是以每個容器爲基礎指定的，如果容器使用的內存超過了限制，它將被OOMKilled。從流程的角度來看，這與系統內存不足相同。
如果系統內存用完。 Kubernetes中有兩種資源規範：requests and limits。限制指定容器在OOMKilled之前可以使用的最大內存量。如果未指定，請求用於安排Pod並默認爲限制。請求必須小於或等於容器限制。這意味着如果多個容器同時使用比它們各自的請求更多的內存，那麼容器可能會在節點上過載並被OOMKilled。

例如，如果兩個處理A和處理B具有1GB的請求和2GB的限制，它們可以同時具有2GB的內存，因爲請求是什麼是用於調度的節點上調度。請求低於限制通常意味着容器可以突破2GB，但通常使用小於1GB。現在，如果兩者都同時突破1GB以上，則系統可能會耗盡內存，並且一個容器將獲得OOMKilled，同時仍低於容器上設置的限制。

可以調試是否容器被通過檢查在盤上的containerStatuses場OOMKilled。

$ kubectl get pod X -o json | jq '.status.containerStatuses'

如果莢OOMKilled它通常會說些什麼，在lastState字段的效果。在你的情況下，它看起來可能是基於針對芹菜提出的問題的OOM錯誤（如this one）。

來源

2017-08-14 05:57:55

GCP容器中可能的OOM - 如何調試？

回答

相關問題