Why Kubernetes exists?

Containers became the default unit for shipping software, but the real challenge is not running one container. The challenge is running thousands safely and predictably. We need strong security boundaries, smart placement, rapid scaling, and self-healing when something breaks. Kubernetes (K8s) delivers that by automating deployment, scaling, and lifecycle management for containerized workloads. A cluster is made up of worker nodes that run applications and a control plane that makes decisions and manages cluster state. In high availability setups, control plane components run across multiple machines, and control plane nodes are usually tainted so user workloads do not land there by default.

In this blog we shall take a walk into journey that leads to creation of a pod in the Kubernetes cluster.

Step 1: The API server receives the request

When you create a pod using kubectl, the request lands at the kube-apiserver. This is the front door of the cluster. The API server authenticates the caller (who is making the request) and authorizes the action (whether that identity can create a pod in the target namespace). If the request passes validation and admission checks, the API server persists the pod object into etcd.

Step 2: etcd records the source of truth

etcd is the distributed key value store backing Kubernetes. It stores Kubernetes API objects, which represent the desired configuration and the last known status reported by nodes and controllers. Because the control plane reads and writes cluster state through the API server, etcd becomes the system of record for what the cluster believes should exist. At this point, the API server returns success, but the pod is not running yet. It exists as an object, typically in a Pending state, because it has not been assigned to a node.

Step 3: The scheduler picks a node

That is where the kube-scheduler comes in. The scheduler watches the API server for pods without an assigned node, then evaluates available worker nodes based on the pod spec and cluster constraints. Common scheduling signals include:

• CPU , memory requests and available capacity
• Affinity and anti-affinity rules and topology constraints
• Taints and toleration
• Node selectors, node affinity, and special resources (for example GPUs)

Once the scheduler selects a node, say w1, it records that decision back through the API server by binding the pod to the node. Practically, you will see this as the pod’s spec.nodeName being set. That update is stored in etcd like any other API write.

Step 4: Kubelet starts the pod

Now the kubelet on node w1 takes over. The kubelet watches for pods assigned to its node. When it sees the new pod, it pulls the pod spec, instructs the container runtime via the Container Runtime Interface (CRI) to pull images and start containers, and ensures runtime requirements are satisfied.

That includes attaching volumes, applying security context settings, and configuring networking through the CNI plugin so the pod gets an IP and can communicate. Once the pod starts, kubelet continuously reports status back to the API server, including readiness, liveness results, restarts, and condition updates.

Step 5: Controllers keep the system honest

To keep desired state aligned with observed state, Kubernetes relies on controllers running inside the kube-controller-manager. This includes controllers for Deployments, ReplicaSets, DaemonSets, and more. Their job is reconciliation. They constantly compare what you declared with what is currently reported, then create or update resources until the gap closes.

A simple example is a ReplicaSet. If a pod crashes or gets deleted and the replica count drops below the desired number, the ReplicaSet controller creates a replacement pod. That new pod goes through the same API server, scheduler, and kubelet flow again. This reconciliation loop is what gives Kubernetes its self-healing behavior, and it is also why writing custom controllers is such a powerful pattern for platform teams.

One more component that matters: kube-proxy

Finally, kube-proxy plays a critical role in networking. It is not part of the pod creation sequence, but it is essential once pods are running. kube-proxy programs traffic rules so Service IPs can route and load balance to the correct pod endpoints, typically using iptables or IPVS. In some clusters, an eBPF-based CNI such as Cilium can take over Service load balancing, so kube-proxy may not be needed.

Finally, the pod gets created.