9.2 Kubernetes Pod Creation Lifecycle

Kubernetes Pod Creation Lifecycle is the ordered sequence of steps that occur from the moment a Pod specification is submitted to the API server through to the point at which its containers begin executing on an assigned node. This process involves coordination between the API server, the scheduler, the kubelet, and the container runtime, each contributing a distinct phase before the Pod becomes a functioning, running workload.

Admission and Persistence

API Server Validation

When a Pod manifest is submitted, whether directly or generated by a controller, the API server first validates the object against the Pod schema and runs it through any configured admission controllers, which may mutate the object, such as injecting default resource requests, or reject it outright, such as when it violates a Pod Security Standard enforced on the namespace.

Persisting to etcd

Once admission succeeds, the Pod object is persisted to etcd with a Pending phase and no node assignment. At this point the Pod exists as a cluster object but has not yet been placed anywhere, and it remains visible to any component watching the API server, including the scheduler.

Scheduling Phase

Scheduler Queue and Filtering

The scheduler continuously watches for Pods lacking a nodeName and adds them to its internal scheduling queue. For each such Pod, it runs a filtering step across all nodes, eliminating any that cannot satisfy the Pod's resource requests, node selectors, affinity rules, or tolerations for existing taints.

Scoring and Binding

Among the nodes that pass filtering, the scheduler applies a scoring step to rank candidates based on factors such as resource balance and affinity preferences, selects the highest-scoring node, and then binds the Pod to that node by updating the Pod object's nodeName field through a binding request to the API server.

Kubelet Acknowledgment and Container Preparation

Kubelet Pickup

The kubelet on the selected node watches for Pods bound to it and, upon observing the new assignment, begins its own local processing of the Pod. This marks the transition from cluster-level scheduling concerns to node-level execution concerns.

Volume Mounting

Before any container starts, the kubelet ensures that all volumes referenced in the Pod specification are properly mounted, which may involve attaching persistent volumes, creating emptyDir directories, or projecting ConfigMap and Secret data into the filesystem locations the containers expect.

Image Pulling

The kubelet instructs the container runtime to pull each required container image if it is not already present locally, governed by the Pod's imagePullPolicy. During this step, a Pod's container status reflects a Waiting state with a reason such as ContainerCreating or, if the pull fails, ImagePullBackOff.

Init Container Execution

Sequential Initialization

If the Pod specifies init containers, the kubelet executes them one at a time, in the order listed, waiting for each to exit successfully before starting the next. Only after every init container completes does the kubelet proceed to start the Pod's regular application containers.

Failure Handling During Initialization

If an init container fails and the Pod's restartPolicy permits retries, the kubelet restarts that init container according to policy; if the restart policy is Never or retries are exhausted, the Pod as a whole is marked Failed, since the application containers can never be reached without successful initialization.

Application Container Startup

Container Runtime Invocation

Once initialization is complete, the kubelet instructs the container runtime, via the Container Runtime Interface, to create and start each application container concurrently, applying the security context, resource limits, and environment configuration specified for each.

Transition to Running State

As each container's process begins executing, its status transitions from Waiting to Running, and once postStart hooks, if defined, have been invoked, the container is considered to have started. The Pod's overall phase transitions to Running once at least one container has reached this state.

Readiness Before Traffic Admission

Startup and Readiness Probe Sequencing

If a startup probe is configured, liveness and readiness probes are held off until it succeeds, accommodating slow-starting applications. Once readiness probes begin passing, the container's ready status becomes true, and only then does the Pod become eligible for inclusion as an endpoint behind any Services that select it, completing the creation lifecycle from submission to serving live traffic.