What Happens Inside Kubernetes When You Create a Deployment?

Brief Overview of Kubernetes Architecture

Before examining the end‑to‑end process of turning a Deployment into a running Pod, it helps to understand the overall Kubernetes cluster architecture.

The diagram above shows that a Kubernetes cluster consists of a control plane and one or more node machines.

The control plane (also called the master) hosts several core components:

kube-apiserver : Handles all API requests from clients and internal components.

etcd : Distributed persistent store and event notification system; only the kube-apiserver writes directly to it.

scheduler : Assigns Pods to suitable Nodes based on scheduling policies.

controller manager : Runs various controllers that manage resource objects.

cloud controller manager : Integrates cloud‑provider specific controllers.

Each node runs the workloads isolated from the control plane and includes:

kubelet : Manages Pods on the node, performs health checks, and reports status.

kube-proxy : Implements network routing for Services using iptables or IPVS.

CRI : Container Runtime Interface that abstracts the underlying container runtime.

From Deployment to Pod

The full lifecycle from a Deployment object to a running Pod is illustrated below:

1. Request Sent to kube‑apiserver

The request reaches the kube-apiserver, which performs authentication, authorization, mutation, and validation. The Deployment definition is then persisted in etcd. During this phase, a mutating admission webhook can modify the object (e.g., inject a sidecar).

2. controller‑manager Processing

The controller manager contains separate controllers for different resources. For a Deployment, the deployment controller watches Deployment creation events and creates a corresponding ReplicaSet. The replicaset controller then watches ReplicaSet events and creates the actual Pods.

deployment controller

replicaset controller

Step (1): The deployment controller detects the new Deployment and creates a ReplicaSet. Step (2): The replicaset controller detects the new ReplicaSet and creates the Pod.

3. Scheduler Assigns the Pod

When the Pod object appears, the scheduler evaluates scheduling constraints (node affinity, taints/tolerations, resource requests, priorities, etc.) and selects an appropriate Node, updating the Pod's nodeName field.

The scheduling algorithm is complex; detailed policies are omitted for brevity.

4. Node kubelet Creates the Pod

After the Pod is bound to a Node, the node's kubelet receives the event via the kube-apiserver. The kubelet then invokes the CRI, CNI, and CSI plugins to pull the container image, set up networking, and attach storage before launching the container. CRI (Container Runtime Interface): Executes image pull, container creation, and deletion. Common implementations are containerd, CRI‑O, and Docker Engine. CNI (Container Network Interface): Assigns an IP address to the Pod and ensures network connectivity. Popular plugins include Cilium and Calico. CSI (Container Storage Interface): Communicates with external storage providers to attach and mount volumes.

These interfaces define communication protocols (typically gRPC); the actual implementations are provided by the respective plugins.

At this point, the Kubernetes workflow from creating a Deployment to having a running Pod is complete.

References

https://kubernetes.io/docs/concepts/architecture/

https://kubernetes.io/docs/concepts/scheduling-eviction/

https://kubernetes.io/docs/setup/production-environment/container-runtimes/

https://kubernetes.io/docs/tasks/administer-cluster/network-policy-provider/