Multiple Schedulers

This guide explains how to run multiple schedulers in a Kubernetes cluster, why you might need them, and how to deploy a custom scheduler alongside the default kube-scheduler. Kubernetes includes a default scheduler (usually default-scheduler) that places Pods onto nodes while honoring constraints such as taints/tolerations and node affinity. For specialized placement logic—custom scoring, additional validation, or entirely different scheduling algorithms—you can run one or more additional scheduler processes (or Pods) with unique names. Applications request a specific scheduler by setting the schedulerName field in their Pod spec.

An illustrated infographic using ships and a dock to explain Kubernetes scheduling, showing a Master and Worker Nodes with labeled schedulers (my-scheduler, my-scheduler-2, kube-scheduler) and colorful container stacks. Green callouts and crane icons connect the dock to the containers to represent scheduling and deployment.

How Pods select a scheduler

Set the scheduler to use in the Pod spec with schedulerName:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  schedulerName: my-scheduler

If schedulerName is omitted, the default scheduler (commonly default-scheduler) handles the Pod.

Scheduler configuration: minimal example

Each scheduler process needs a configuration with a unique schedulerName. A minimal kube-scheduler configuration:

# kubescheduler configuration (example)
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: my-scheduler

Each scheduler instance should run with its own config file referencing the chosen schedulerName.

Deployment options

You can run an additional scheduler in several ways:

As a standalone Pod in kube-system (simple, useful for testing).
As a Deployment (recommended for production—pack the scheduler binary into a container image).
As a static Pod or system component if you manage control-plane manifests directly.

Table: Quick comparison

Option	When to use	Notes
Pod (single)	Testing or simple setups	Quick to deploy; not HA unless you run multiple replicas with leader election.
Deployment	Production / HA	Package scheduler into an image, create ServiceAccount and RBAC, enable leader election for multiple replicas.
Custom binary	Specialized scheduling	Build your own scheduler binary or reuse kube-scheduler with custom plugins/configs.

Run as a standalone Pod

Example Pod manifest that runs the upstream kube-scheduler binary and points to a kubeconfig and scheduler config:

apiVersion: v1
kind: Pod
metadata:
  name: my-scheduler
  namespace: kube-system
spec:
  containers:
  - name: kube-scheduler
    image: k8s.gcr.io/kube-scheduler-amd64:v1.22.0
    command:
      - kube-scheduler
      - --address=127.0.0.1
      - --kubeconfig=/etc/kubernetes/scheduler.conf
      - --config=/etc/kubernetes/my-scheduler-config.yaml
    volumeMounts:
      - name: config-volume
        mountPath: /etc/kubernetes
  volumes:
    - name: config-volume
      configMap:
        name: my-scheduler-config

Be sure to create the referenced ConfigMap and kubeconfig before applying the Pod manifest.

Leader election (high availability)

When running multiple replicas of the same scheduler (for HA), enable leader election so only one replica makes scheduling decisions at any time. Configure leader election in the kube-scheduler configuration:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: my-scheduler
leaderElection:
  leaderElect: true
  resourceNamespace: kube-system
  resourceName: lock-object-my-scheduler

If you deploy only a single replica of your custom scheduler, you may set leaderElect: false. For HA deployments with multiple replicas, always enable leader election and give each scheduler deployment a unique resourceName so locks do not conflict.

Run as a Deployment (recommended for production)

Typical steps:

Build or package the scheduler binary into a container image.
Push the image to your registry (GCR, Docker Hub, etc.).
Create a ServiceAccount and ClusterRoleBinding so the scheduler can access the API.
Provide the scheduler configuration via a ConfigMap and mount it into the Deployment.
Enable leader election for HA.

Example build and push (condensed):

# clone kubernetes (if building from upstream)
git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
make

# Dockerfile snippet
# FROM busybox
# build image
docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 .

# authenticate Docker to GCR (example)
gcloud auth configure-docker

# push image to GCR
docker push gcr.io/my-gcp-project/my-kube-scheduler:1.0

Condensed Deployment manifest (key fields):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-scheduler
  namespace: kube-system
  labels:
    component: scheduler
    tier: control-plane
spec:
  replicas: 1
  selector:
    matchLabels:
      component: scheduler
      tier: control-plane
  template:
    metadata:
      labels:
        component: scheduler
        tier: control-plane
        version: second
    spec:
      serviceAccountName: my-scheduler
      containers:
      - name: kube-second-scheduler
        image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
        command:
          - /usr/local/bin/kube-scheduler
          - --config=/etc/kubernetes/my-scheduler/my-scheduler-config.yaml
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10259
            scheme: HTTPS
          initialDelaySeconds: 15
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10259
            scheme: HTTPS
        resources:
          requests:
            cpu: '0.1'
        securityContext:
          privileged: false
        volumeMounts:
        - name: config-volume
          mountPath: /etc/kubernetes/my-scheduler
      volumes:
      - name: config-volume
        configMap:
          name: my-scheduler-config

ConfigMap with the scheduler configuration (example):

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-scheduler-config
  namespace: kube-system
data:
  my-scheduler-config.yaml: |
    apiVersion: kubescheduler.config.k8s.io/v1
    kind: KubeSchedulerConfiguration
    leaderElection:
      leaderElect: false
    profiles:
    - schedulerName: my-scheduler

RBAC essentials (ServiceAccount + ClusterRoleBinding):

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-scheduler
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-scheduler-as-kube-scheduler
subjects:
- kind: ServiceAccount
  name: my-scheduler
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: system:kube-scheduler
  apiGroup: rbac.authorization.k8s.io

Notes:

Mount the ConfigMap into the Deployment and pass --config to the scheduler command.
Use a ServiceAccount and ClusterRoleBinding so the scheduler can authenticate and perform scheduling operations.

Apply and verify

Create the Deployment/Pod and supporting resources:

kubectl apply -f my-scheduler-resources.yaml
kubectl get pods --namespace=kube-system

You should see your custom scheduler Pod(s) running in kube-system (names will vary based on whether you used a Pod or Deployment manifest).

Scheduling a Pod with the custom scheduler

Create a Pod that requests your scheduler:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  schedulerName: my-scheduler

Apply:

kubectl apply -f nginx-with-custom-scheduler.yaml

If the Pod stays in Pending, inspect it:

kubectl describe pod nginx

Look for scheduling events and reasons in the Events section.

Confirm which scheduler scheduled the Pod

Events show the scheduler that assigned the Pod. Example:

kubectl get events -o wide

Sample output:

LAST SEEN   COUNT   NAME        KIND  TYPE    REASON      SOURCE                 MESSAGE
9s          1       nginx.15    Pod   Normal  Scheduled   my-scheduler           Successfully assigned default/nginx to node01
8s          1       nginx.15    Pod   Normal  Pulling     kubelet, node01        pulling image "nginx"
2s          1       nginx.15    Pod   Normal  Pulled      kubelet, node01        Successfully pulled image "nginx"
2s          1       nginx.15    Pod   Normal  Created     kubelet, node01        Created container
2s          1       nginx.15    Pod   Normal  Started     kubelet, node01        Started container

The SOURCE column shows the scheduler that created the Scheduled event.

Inspect scheduler logs

If scheduling does not behave as expected, view the scheduler Pod logs:

kubectl logs my-scheduler --namespace=kube-system

Example log snippet:

I0204 09:42:25.819338        1 server.go:126] Version: v1.22.0
W0204 09:42:25.822720        1 authorization.go:47] Authorization is disabled
W0204 09:42:25.822745        1 authentication.go:55] Authentication is disabled
I0204 09:42:25.822801        1 insecure_serving.go:47] Serving healthz insecurely on 127.0.0.1:10251
I0204 09:45:14.725407        1 controller_utils.go:1025] Waiting for caches to sync for scheduler controller
I0204 09:45:14.825634        1 controller_utils.go:1032] Caches are synced for scheduler controller
I0204 09:45:14.825814        1 leaderelection.go:185] attempting to acquire leader lease kube-system/my-scheduler...
I0204 09:45:14.834953        1 leaderelection.go:194] successfully acquired lease kube-system/my-scheduler

Logs will show version, leader election, cache syncs, and any scheduling errors or plugin messages.

Troubleshooting tips

If your Pod never leaves Pending, check kubectl describe pod <pod> and events for reasons.
Confirm the scheduler Pod is healthy (readiness/liveness probes) and has the correct --config and --kubeconfig flags.
Verify RBAC (the scheduler’s ServiceAccount must have system:kube-scheduler privileges or equivalent).
Ensure leader election settings use unique resourceName values if you run multiple distinct scheduler deployments.

Summary

Kubernetes supports multiple schedulers; each must have a unique schedulerName.
Run additional schedulers by starting kube-scheduler (or a custom scheduler) with its own configuration and kubeconfig.
Request a specific scheduler in a Pod spec with schedulerName.
For HA, enable leader election and use unique lock names per scheduler deployment.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Multiple Schedulers

How Pods select a scheduler

Scheduler configuration: minimal example

Deployment options

Run as a standalone Pod

Leader election (high availability)

Run as a Deployment (recommended for production)

Apply and verify

Scheduling a Pod with the custom scheduler

Confirm which scheduler scheduled the Pod

Inspect scheduler logs

Troubleshooting tips

Summary

Links and references

Watch Video

Practice Lab

​How Pods select a scheduler

​Scheduler configuration: minimal example

​Deployment options

​Run as a standalone Pod

​Leader election (high availability)

​Run as a Deployment (recommended for production)

​Apply and verify

​Scheduling a Pod with the custom scheduler

​Confirm which scheduler scheduled the Pod

​Inspect scheduler logs

​Troubleshooting tips

​Summary

​Links and references

Watch Video

Practice Lab

How Pods select a scheduler

Scheduler configuration: minimal example

Deployment options

Run as a standalone Pod

Leader election (high availability)

Run as a Deployment (recommended for production)

Apply and verify

Scheduling a Pod with the custom scheduler

Confirm which scheduler scheduled the Pod

Inspect scheduler logs

Troubleshooting tips

Summary

Links and references