<p>normally I think it's a best practice for an incorrectly configured application to simply die on startup with a detailed error message describing the problem.</p>

<p>For example, if an expected environment variable is missing, meaning the application can't run properly, instead of letting it run in a zombie state where it will never function, I advocate for failing loudly and killing the application with an error message:  </p>

<p><code>Critical Error:  Environment variable [REDIS_HOST] not set.</code></p>

<p>In kubernetes, this ends up in a constant <code>CrashLoop Backoff</code> loop.  This isn't great as it's hard to get to that error message as the pod keeps getting restarted and the logs disappear.</p>

<p>Any thoughts or suggestions on the proper way to handle this?</p>

<p>thanks</p>

phil swenson
<p>You can customise a container's termination message by writing to <code>/dev/termination-log</code> by default. When your container terminates you can use <code>kubectl get pods &lt;podName&gt; -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"</code> to retrieve the message. More information about this can be found <a href="https://kubernetes.io/docs/tasks/debug-application-cluster/determine-reason-pod-failure#customizing-the-termination-message" rel="nofollow noreferrer">here</a>.</p>

<p>You can also use <code>kubectl logs &lt;podName&gt; -c &lt;containerName&gt; --previous</code> to view the output of the previous instance of a particular container in a Pod - this may be more useful for you as you won't have to change your application to write error messages to <code>/dev/termination-log</code>.</p>
