Kubernetes Pod Creation Lifecycle

Kubernetes Pod Creation Lifecycle is the ordered sequence of events that occurs from the moment a Pod manifest is submitted to the API server until its containers begin executing on a node. This sequence spans several distinct subsystems, the API server's admission pipeline, the scheduler, and the kubelet, each of which performs a discrete stage of work before the Pod can be considered running.

Submission and Admission

API Server Validation

When a Pod manifest is submitted, either directly or generated by a controller from a Pod template, the API server first validates it against the OpenAPI schema for the Pod resource, rejecting malformed requests before they are persisted.

Admission Controllers

The request then passes through mutating and validating admission webhooks and built-in admission plugins, which can inject default values (such as a default service account or resource limits), enforce policy (such as disallowing privileged containers), or reject the request outright.

kubectl apply -f pod-creation-example.yaml

Once admission succeeds, the Pod object is persisted to etcd with status.phase set to Pending and no nodeName assigned.

Scheduling

Predicate and Priority Evaluation

The scheduler watches for unscheduled Pods and evaluates each candidate node through a filter phase (removing nodes that cannot satisfy resource requests, taints, or affinity rules) followed by a scoring phase that ranks the remaining eligible nodes.

Binding

The scheduler commits its decision through a Binding object, which sets spec.nodeName on the Pod. This is the event that transitions Pod scheduling out of the queue and hands responsibility to the kubelet on the chosen node.

status:
  conditions:
    - type: PodScheduled
      status: "True"

Kubelet Admission and Sandbox Creation

Kubelet-Level Admission

The kubelet on the target node independently re-validates that the Pod fits within local resource limits before accepting it, since cluster state may have shifted between the scheduler's decision and the kubelet's observation.

Pod Sandbox

The kubelet instructs the container runtime, through the Container Runtime Interface, to create a Pod sandbox, an isolated network namespace shared by all containers in the Pod, which is what gives every container in a Pod a common localhost and a single Pod IP.

Volume Attachment and Image Pulling

Volume Mounting

Before containers start, any referenced volumes, ConfigMaps, Secrets, or PersistentVolumeClaims, must be attached and mounted into the sandbox's filesystem namespace.

Image Pull

The kubelet pulls each required container image according to the Pod's imagePullPolicy, caching layers locally to speed up subsequent pulls of the same image on that node.

containers:
  - name: app
    image: registry.example.com/app:1.0.0
    imagePullPolicy: IfNotPresent

Init and Application Container Startup

Sequential Init Containers

Init containers, if declared, run one at a time to completion before any application container starts, each one gating the start of the next.

Parallel Application Container Start

Once all init containers have succeeded, application containers start, typically in parallel, and the kubelet begins evaluating their startup, liveness, and readiness probes.

initContainers:
  - name: setup
    image: registry.example.com/setup:1.0.0
containers:
  - name: app
    image: registry.example.com/app:1.0.0

Creation Lifecycle Diagram

Only once this full sequence completes does the Pod's status.phase transition to Running, and even then, readiness probes must succeed independently before the Pod is considered eligible to receive traffic from a Service.