如何確定CrashLoopBackOff誤差的部署在Kubernetes

我有一個春天啓動應用程序，部署上Kubernetes泊塢窗容器春季啓動應用程序的原因。該應用程序運行良好一段時間（小時），但在某個時刻它開始像瘋了一樣重新啓動，顯示CrashLoopBackOff錯誤狀態。如何確定CrashLoopBackOff誤差的部署在Kubernetes

這是信息，我從死亡莢得到：

Port:  8080/TCP 
State:  Waiting 
    Reason:  CrashLoopBackOff 
Last State:  Terminated 
    Reason:  Error 
    Exit Code: 137 
    Started:  Fri, 11 Aug 2017 10:15:03 +0200 
    Finished:  Fri, 11 Aug 2017 10:16:22 +0200 
Ready:  False 
Restart Count: 7 
... 
    Volume Mounts: 
     /var/run/secrets/kubernetes.io/serviceaccount from default-token-bhk8f (ro) 
    Environment Variables: 
     JAVA_OPTS:  -Xms512m -Xmx1792m 
Conditions: 
    Type  Status 
    Initialized True 
    Ready  False 
    PodScheduled True 
... 
QoS Class: BestEffort 
Tolerations: <none> 
No events.

有什麼辦法來獲取有關崩潰的原因的更多詳細信息？

爲137錯誤代碼的內存不足的錯誤？我一直將Java進程的內存從-Xmx768m增加到1792m，但錯誤不斷顯現。 難道是別的嗎？

一個奇怪的事實：我需要找出如何來應用運行良好，幾個小時後，莢被殺，然後每次重新啓動時僅幾秒鐘後，執行殺害。

來源

2017-08-11 codependent

所以你的節點做了'泊塢窗PS -a'看到退出的容器，看看你在日誌中得到什麼。此外只是在容器內部限制內存不會幫助，你也需要將其應用到容器。同時檢查是否有磁盤空間問題。我們有一個類似的問題，tomcat將核心轉儲和轉儲巨大導致10GB容器內沒有空間 –

沒有遙測幾乎不可能說。可能是泄漏，你會得到OOMed，誰知道:)你在使用監視系統和您的容器？ –

只是要清楚：是的，代碼137來自Docker引擎，指示OOM殺死，但我們需要一個根本原因，對吧？ –

kubectl logs podName containerName將爲您提供容器日誌應該給你錯誤的原因的其他信息。

來源

2017-08-11 11:21:27

kubectl日誌顯示應用程序日誌，並有一切似乎確定。有沒有辦法獲得關於墜毀容器的更具體信息？ – codependent

我不這麼認爲。除了使用其他潛在指標。日誌中是否提供退出代碼？什麼是退出代碼（當進程終止時）？ –

如何確定CrashLoopBackOff誤差的部署在Kubernetes

回答

相關問題