<p>A fairly common setup I see for docker is to have a container spin up perform a task and then exit.
This is something I do quite often with docker-compose where I have a node container that performs a build process and doesn't need to stay up once the static files have been built.
In these cases if I look at the <code>docker-compose ps</code> output, while my other containers are up and exposed on a port, the node containers state will be "Exit 0".
Although otherwise dormant if I need to access this container it's available to be spun up.</p>

<p>What's a good practice for translating this setup to Kubernetes?</p>

<p>My initial approach was to place everything in one pod but the container exiting causes a CrashLoopBackOff and due to the pod restart policy the pod keeps restarting.
If I were to keep this setup I'd only want the pod to restart if one of the other containers were to fail. It already moves the build static files into a volume that is accessible by the other containers.</p>

<p>Should this container be moved into another pod that does not restart? Seems like this would unnecessarily complicate the deployment.</p>

Luke Vincent
<p>Generally, to prevent POD from restating use <code>restartPolicy: Never</code> (<a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy" rel="noreferrer">more on Restart Policy</a>).</p>

<p>Also, for the thing which you want to run "to completion" use k8s component called <code>Job</code> (<a href="https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/" rel="noreferrer">more on Job</a>):</p>

<pre><code>apiVersion: batch/v1
kind: Job
metadata:
  name: &lt;job_name&gt;
spec:
  template:
    spec:
      containers:
      &lt;...&gt;
</code></pre>

<p>To run Job till the first success (which is <code>exit code 0</code>) set <code>restartPolicy: OnFailure</code>.</p>
