Skip to main content
Welcome to this lesson on deploying multiple schedulers in a Kubernetes cluster. In this guide, you will learn how to deploy custom schedulers alongside the default scheduler, configure them correctly, and validate their operation. Kubernetes’ default scheduler distributes pods across nodes evenly while considering factors such as taints, tolerations, and node affinity. However, certain use cases may require a custom scheduling algorithm. For instance, when an application needs to perform extra verification before placing its components on specific nodes, a custom scheduler becomes essential. By writing your own scheduler, packaging it, and deploying it alongside the default scheduler, you can tailor pod placement to your specific needs.
Ensure that every additional scheduler has a unique name. The default scheduler is conventionally named “default-scheduler,” and any custom scheduler must be registered with its own distinct name in the configuration files.

Configuring Schedulers with YAML

Below are examples of configuration files for both the default and a custom scheduler. Each YAML file uses a profiles list to define the scheduler’s name.

Deploying an Additional Scheduler

You can deploy an additional scheduler using the existing kube-scheduler binary, tailoring its configuration through specific service files.

Step 1: Download the kube-scheduler Binary

Begin by downloading the kube-scheduler binary:

Step 2: Create Service Files

Create separate service files for each scheduler. For example, consider the following definitions:

Step 3: Define Scheduler Configuration Files

Reference the scheduler names in the associated configuration files:
Several code blocks might look similar or repeated. The examples above represent a consolidated view for clarity.

Deploying the Custom Scheduler as a Pod

In addition to running the scheduler as a service, you can deploy it as a pod inside the Kubernetes cluster. This method involves creating a pod definition that references the scheduler’s configuration file.

Example Pod Definition

The corresponding custom scheduler configuration file might look like:
Leader election is an important configuration for high-availability environments. It ensures that while multiple scheduler instances are running, only one actively schedules the pods.

Deploying the Custom Scheduler as a Deployment

In many modern Kubernetes setups—especially those using kubeadm—control plane components run as pods or deployments. Below is an example of deploying a custom scheduler as a Deployment.

Step 1: Build and Push a Custom Scheduler Image

Create a Dockerfile for your custom scheduler:
Build and push the Docker image:

Step 2: Create ServiceAccount and RBAC Configurations

Prepare the following YAML to create a service account and set appropriate RBAC permissions:

Step 3: Create a ConfigMap for Scheduler Configuration

Define a ConfigMap that includes your custom scheduler configuration:

Step 4: Define the Deployment

Deploy the custom scheduler as a Deployment with the following YAML:
Also, ensure a proper ClusterRole exists for the scheduler. For example:

Configuring Workloads to Use the Custom Scheduler

To have specific pods or deployments use your custom scheduler, add the “schedulerName” field in the pod’s specification. For example:
Deploy this pod with:
If the custom scheduler configuration is incorrect, the pod may remain in the Pending state. Conversely, a properly scheduled pod will transition to the Running state.

Verifying Scheduler Operation

To confirm which scheduler assigned a pod, review the events in your namespace:
A sample output might appear as follows:
Notice that the event source is “my-custom-scheduler,” confirming that the pod was scheduled by your custom scheduler. If you encounter issues, view the scheduler logs with:
A sample log output might include messages like:
This confirms that the custom scheduler is up and functioning as expected.

Conclusion

By following these techniques, you can run both the default Kubernetes scheduler and one or more custom schedulers concurrently. This flexibility allows you to assign specific workloads to the most appropriate scheduler based on your cluster’s requirements. Happy scheduling!

Watch Video

Practice Lab