Pod Lifecycle

Pods are designed to be mortal and immutable.

Mortal means we create a Pod, it executes a task, and then it terminates. As soon as it completes, it gets deleted and cannot be restarted. The same is true if it fails — it gets deleted and cannot be restarted.

Immutable means we cannot modify them after they’re deployed. This can be a huge mindset change if we're from a traditional background where we regularly patched live servers and logged on to them to make fixes and configuration changes. If we need to change a Pod, we create a new one with the changes, delete the old one and replace it with the new one. If a Pod needs to store data, we should attach a volume and store the data in the volume so its not lost when the Pod is deleted.

Let’s look at a typical Pod lifecycle.

We define a Pod in a declarative YAML object that we post to the API server. It goes into the pending phase while the scheduler finds a node to run it on. Assuming it finds a node, the Pod gets scheduled, and the local kubelet instructs the runtime to start its containers. Once all of its containers are running, the Pod enters the running phase. It remains in the running phase indefinitely if it’s a long-lived Pod, such as a web server. If it’s a short-lived Pod, such as a batch job, it enters the succeeded state as soon as all containers complete their tasks. This is shown in the following figure.