Kubernetes Application Container Lifecycle

Kubernetes Application Container Lifecycle is the execution model governing the containers declared under a Pod's spec.containers, the primary workload processes that begin only after all init containers have completed, and that continue running, restarting, and reporting health for the operational lifetime of the Pod. Unlike init containers, application containers are expected to run continuously (or until legitimate completion for batch workloads) and are the containers actually responsible for serving traffic or performing ongoing work.

Parallel Startup

No Inherent Ordering

Once init containers have finished, application containers are started without a guaranteed sequential order between them; the kubelet typically starts them concurrently. Any ordering dependency between application containers must be handled by the application itself, for example through retry logic or readiness checks against a sidecar.

apiVersion: v1
kind: Pod
metadata:
  name: app-lifecycle-example
spec:
  containers:
    - name: app
      image: registry.example.com/app:1.0.0
    - name: cache
      image: registry.example.com/cache:1.0.0

Startup, Liveness, and Readiness Probes

Startup Probe as a Gate

If defined, a startupProbe suppresses liveness and readiness checks until it succeeds, protecting slow-initializing containers from being killed prematurely by a liveness probe still in its early, aggressive checking window.

Liveness Probe Driving Restarts

A livenessProbe failure that exceeds failureThreshold causes the kubelet to kill the container and, subject to restartPolicy, restart it, incrementing restartCount. This is the mechanism by which the container lifecycle self-heals from deadlocks the application cannot recover from internally.

containers:
  - name: app
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      periodSeconds: 10
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      periodSeconds: 5

Readiness Probe Governing Traffic Only

A readinessProbe failure never restarts the container; it only flips the container's ready field to false, which removes the Pod from Service endpoints without disturbing the running process.

restartPolicy and the Restart Loop

Automatic Recovery Within the Same Pod

restartPolicy: Always (the default for most workload types) causes the kubelet to restart a terminated application container automatically, applying exponential backoff on repeated failures and surfacing CrashLoopBackOff as the waiting reason during that backoff window.

spec:
  restartPolicy: Always

Completion-Oriented Policies

OnFailure restarts only on non-zero exit, allowing a container to reach a terminal Succeeded state on clean exit, while Never disables automatic restarts entirely, both patterns used primarily for Jobs rather than long-running services.

Lifecycle Hooks

postStart and preStop

Application containers support two lifecycle hooks executed by the kubelet outside the container's main process: postStart, fired immediately after container creation without any ordering guarantee relative to the container's entrypoint, and preStop, fired before the kubelet sends the termination signal, commonly used to drain in-flight connections.

containers:
  - name: app
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "sleep 5 && /app/drain.sh"]

Graceful Termination

SIGTERM, Grace Period, SIGKILL

When an application container is being stopped, the kubelet sends SIGTERM, runs any preStop hook, and waits up to terminationGracePeriodSeconds before force-killing with SIGKILL if the process has not exited on its own.

spec:
  terminationGracePeriodSeconds: 30

Application Container Lifecycle Diagram

Because probes, restart policy, and lifecycle hooks all act on this specific container type, tuning the application container lifecycle is the primary lever operators use to balance fast failure recovery against unnecessary restart churn.