1
私は、Kubernetesのドッカーコンテナに展開されたSpringブートアプリケーションを持っています。アプリケーションはしばらくの間うまく動作しますが、ある時点でCrashLoopBackOffエラー状態を示す狂ったような再起動を開始します。KubernetesにデプロイされたSpringブートアプリケーションでCrashLoopBackOffエラーの原因を特定する方法
これは私が死んポッドから取得する情報をされています
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まで増やし続けましたが、エラーは引き続き表示されています。 それは別のものかもしれませんか？
一つ奇妙な事実：私は、アプリケーションがうまく実行方法来る見つける必要があり、いくつかの時間後にポッドが殺された後、再起動のたびに実行するだけで数秒後に殺されます。
あなたのノードでは、終了したコンテナを見てログに何が入っているかを見る 'docker ps -a'を実行します。また、コンテナ内でメモリの制限を与えるだけで、あなたはまた、コンテナにそれを適用する必要があります。また、ディスク容量に問題がないかどうかを確認してください。我々はTomcatがコアダンプをしてダンプが巨大で、10GBのコンテナの内部にスペースがないのと同様の問題を抱えていた –
遠隔測定がなければ、ほとんど言うことはできません。あなたが知っている、OOMedを取得することがあります： あなたはシステムとあなたの容器を監視するために何を使用していますか？ –
ちょうどいいことです：はい、コード137はDockerエンジンからOOM killを示していますが、根本的な原因が必要ですか？ –