9.9 Kubernetes Application Container Lifecycle

Kubernetes Application Container Lifecycle is the ongoing execution pattern followed by a Pod's primary workload containers, spanning their initial start, continuous operation under health monitoring, potential in-place restarts, and eventual graceful shutdown, distinguished from init containers by running concurrently with one another for the sustained duration of the Pod rather than executing once to completion.

Concurrent Startup Among Application Containers

Simultaneous Start After Initialization

Once all init containers, if any, have completed successfully, every application container in the Pod begins starting at the same time rather than in sequence. This reflects the assumption that application containers within a Pod typically represent cooperating processes meant to run together, such as a main service and its sidecar, rather than steps in a dependency chain.

postStart Hook Execution

If a container defines a postStart lifecycle hook, it executes concurrently with the container's main process immediately after creation. The container is not considered fully started until this hook completes, and a failing postStart hook results in the container being treated as failed, triggering the same restart handling applied to any other container failure.

Steady-State Health Monitoring

Continuous Probe Evaluation

Throughout the container's running lifetime, the kubelet periodically evaluates any configured liveness and readiness probes according to their defined intervals. Unlike the startup phase, which is a one-time gate, this monitoring persists for as long as the container remains in the Running state, forming the ongoing health signal that governs both restart and traffic-routing decisions.

Liveness Probe Failure Response

A failing liveness probe, once it exceeds the configured failure threshold, causes the kubelet to kill the container and, depending on restartPolicy, restart it, operating on the assumption that a container failing its liveness check is in an unrecoverable state, such as a deadlock, that only a fresh process start can resolve.

Readiness Probe Failure Response

A failing readiness probe does not cause a restart; instead, it removes the container's Pod from the set of endpoints backing any Services that select it, allowing the application to signal temporary unavailability, such as during a heavy garbage collection pause or a downstream dependency outage, without being killed and restarted unnecessarily.

In-Place Restart Behavior

restartPolicy Governance

When an application container's process exits, whether cleanly or due to a crash, the kubelet's response is dictated by the Pod's restartPolicy. Under Always, the container is restarted regardless of exit code; under OnFailure, it is restarted only if the exit code indicates failure; under Never, it is left terminated permanently.

Exponential Backoff Between Restarts

Repeated restarts are subject to an exponential backoff delay, starting small and doubling with each successive failure up to a capped maximum, which prevents a persistently crashing container from consuming excessive node resources through rapid, repeated restart attempts, and is externally visible as the CrashLoopBackOff reason.

Graceful Shutdown

preStop Hook Execution

When a container is being terminated deliberately, such as during Pod deletion or a rolling update, any configured preStop hook executes first, before the termination signal is delivered to the container's main process, allowing the application an opportunity to complete in-flight work or deregister itself from external systems.

Termination Signal and Grace Period

After the preStop hook completes, the container runtime sends a termination signal to the main process, and the kubelet waits up to the Pod's terminationGracePeriodSeconds for the process to exit voluntarily before forcibly killing it, balancing clean shutdown against the need to eventually reclaim resources.

Long-Running Nature as a Defining Trait

Contrast With Run-to-Completion Containers

Unlike init containers or containers within Job-managed Pods, application containers in typical long-running workloads are not expected to exit on their own; an unexpected exit is generally treated as a failure condition to be corrected through restart, reflecting the underlying assumption that these containers represent persistent services rather than finite tasks.