Components and Stages Involved in Pod Scheduling

Step-by-step Pod scheduling

Let’s discuss some of the details of Kubernetes components and understand how Pod scheduling works.

Three major components are involved in the process:

1. API server

The API server is the central component of a Kubernetes cluster, and it runs on the primary node. Since we are using k3d, both primary and worker nodes are baked into the same virtual machine. However, a more serious Kubernetes cluster should separate the two on different hosts.

All other components interact with the API server and keep watch for changes. Most of the coordination in Kubernetes consists of a component writing to the API Server resource that another component is watching. The second component will then react to changes almost immediately.

2. Scheduler

The scheduler is also running on the primary node. Its job is to watch for unassigned Pods and assign them to a node with available resources (CPU and memory) matching Pod requirements. Since we’re running a single-node cluster, specifying resources would not provide much insight into their usage, so we’ll leave them for later.

3. Kubelet

Kubelet runs on each node. Its primary function is to make sure that assigned Pods are running on the node. It watches for any new Pod assignments for the node. If a Pod is assigned to the node that Kubelet is running on, it will pull the Pod definition and use it to create containers through Docker or any other supported container engine.

Sequential breakdown of events

The sequence of events with the kubectl create -f db.yml command is as follows:

1. The Kubernetes client (kubectl) sends a request to the API server, requesting creation of a Pod defined in the db.yml file.

2. Since the scheduler is watching the API server for new events, it detects that there is an unassigned Pod.

3. The scheduler decides which node to assign the Pod to and sends that information to the API server.

4. Kubelet also checks the API server. It detects that the Pod was assigned to the node it is running on.

5. Kubelet sends a request to Docker requesting the creation of the containers that form the Pod. In our case, the Pod defines a single container based on the mongo image.

6. Finally, Kubelet sends a request to the API server, notifying it that the Pod is created successfully.

The process might not make much sense right now because we’re running a single-node cluster. If we had more VMs, scheduling might have happened somewhere else, and the complexity of the process would be easier to grasp. We’ll get there in due time.

The following illustration shows a Pod scheduling sequence.