The complete flow of scheduling a POD in Kubernetes – short note

Demystifying Kubernetes Pod Scheduling: A Comprehensive Flow


Embarking on a journey into Kubernetes pod scheduling is not merely about grasping the surface concepts but delving into the intricate internals that make the orchestration magic happen. In this article, we will explore the Kubernetes pod scheduling flow, uncovering the details behind each step. This knowledge is not just theoretical; it’s a valuable asset for anyone eyeing a transition to DevOps roles, where understanding the internals is often a critical interview requirement.

You can check more details from the official documentation



Every interaction with a Kubernetes cluster begins with authentication. Users or applications authenticate themselves using various mechanisms such as client certificates or bearer tokens. This step ensures that only authorized entities can interact with the cluster.


Once authenticated, Kubernetes checks if the entity has the necessary permissions for the requested operation. Role-Based Access Control (RBAC) plays a crucial role here, defining what actions are allowed on which resources. Authorization ensures the security and integrity of the cluster.

API Server

The authenticated and authorized request is then sent to the Kubernetes API server, the central component exposing the Kubernetes API. The API server validates and processes the request, interacting with the etcd datastore, and coordinating actions across the cluster.

Controller Manager and Scheduler

The Controller Manager and Scheduler are key components in maintaining the cluster’s desired state. The Controller Manager manages controllers, correcting deviations from the desired state. The Scheduler, on the other hand, is responsible for selecting an appropriate node for a pod based on various factors.

Pod Scheduling

When a user creates a pod, the Scheduler is triggered to find a suitable node. It considers factors such as resource requirements, node capacity, affinity/anti-affinity rules, and constraints. The Scheduler then updates the pod’s configuration to include the chosen node.

Node Controller and Kubelet

The Node Controller on the selected node monitors the API server for assigned pods and ensures the node runs the desired containers. Simultaneously, the Kubelet interacts with the container runtime (e.g., Docker) to start and manage containers based on the pod specification.

Container Runtime

The container runtime pulls the container image from the registry and starts the container according to the pod specifications. This step brings the pod one step closer to running successfully on the cluster.

Pod Running

Once the container is successfully started, the pod is considered running, and its status is updated in the API server. The application within the pod is now actively serving its purpose, contributing to the overall functionality of the Kubernetes cluster.


In this blog post, we’ve journeyed through the Kubernetes pod scheduling flow, demystifying the process from authentication to the pod running on a node. Understanding these intricacies empowers Kubernetes users and administrators to effectively manage their containerized workloads, ensuring optimal performance and resource utilization across the cluster. As Kubernetes continues to evolve, a solid grasp of its core scheduling principles remains paramount for successfully deploying and orchestrating containerized applications.



Post navigation

Arunlal A

Senior System Developer at Zeta. Linux lover. Traveller. Let's connect! Whether you're a seasoned DevOps pro or just starting your journey, I'm always eager to engage with like-minded individuals. Follow my blog for regular updates, connect on social media, and let's embark on this DevOps adventure together! Happy coding and deploying!

Leave a Reply

Your email address will not be published. Required fields are marked *