# Configure Scheduler

## Build scheduler image
In this demo, I use the default scheduler (kube-scheduler) as our second scheduler just for testing purpose.

Clone the Kubernetes source code from GitHub and build the source:

git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
make

Create a container image containing the `kube-scheduler` binary:

FROM busybox
ADD ./_output/local/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler

Save the file as Dockerfile, build the image and push it to a registry

docker build -t wxr031/myscheduler:latest
docker push wxr031/myscheduler:latest

## Deploy scheduler

Now that we have our scheduler in a container image, we can just create a deployment configuration file and deploy it into our Kubernetes cluster.

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
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-scheduler-as-volume-scheduler
subjects:
- kind: ServiceAccount
  name: my-scheduler
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: system:volume-scheduler
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    component: scheduler
    tier: control-plane
  name: my-scheduler
  namespace: kube-system
spec:
  selector:
    matchLabels:
      component: scheduler
      tier: control-plane
  replicas: 1
  template:
    metadata:
      labels:
        component: scheduler
        tier: control-plane
        version: second
    spec:
      serviceAccountName: my-scheduler
      containers:
      - command:
        - /usr/local/bin/kube-scheduler
        - --address=0.0.0.0
        - --leader-elect=false
        - --scheduler-name=my-scheduler
        image: wxr031/myscheduler:latest
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10251
          initialDelaySeconds: 15
        name: kube-second-scheduler
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10251
        resources:
          requests:
            cpu: '0.1'
        securityContext:
          privileged: false
        volumeMounts: []
      hostNetwork: false
      hostPID: false
      volumes: []

:::info
The name of the scheduler specified as an argument to the scheduler in your configuration file should be `spec.schedulerName`
:::

Now, deploy the scheduler using `kubectl`

kubectl create -f my-scheduler.yaml

Validate that the pod is running

kubectl get pods -n kube-system

## Check that the pod is using your scheduler

In order to schedule a given pod using a specific scheduler, we specify the name of the scheduler in that pod spec. Let's look at two examples:

1. Pod without any scheduler name

apiVersion: v1
kind: Pod
metadata:
  name: no-annotation
  labels:
    name: multischeduler-example
spec:
  containers:
  - name: pod-with-no-annotation-container
    image: k8s.gcr.io/pause:2.0

When no scheduler name is supplied, the pod is automatically scheduled using the *default-scheduler*.

2. Pod without any scheduler name

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-my-scheduler
  labels:
    name: multischeduler-example
  namespace: kube-system
spec:
  schedulerName: my-scheduler
  containers:
  - name: pod-with-my-scheduler-container
    image: k8s.gcr.io/pause:2.0

To verify that the pods were actually scheduled using the desired schedulers, we can verify that by changing the order of pod and scheduler submissions. If we deploy pod first before submitting scheduler, we should that the pod `pod-with-my-scheduler-container` remains in `Pending` state forever.

$ kubectl apply -f pod.yaml
$ kubectl get pods -n kube-system
annotation-second-scheduler           0/1     Pending             0          47s
calico-node-2pnlr                     1/1     Running   1496       88d
calico-node-4tz8c                     1/1     Running   804        88d
calico-node-dvzld                     1/1     Running   804        88d
...

$ kubectl apply -f pod1.yaml
$ kubectl get pods -n kube-system
Once we submit the scheduler deployment configuration, our new scheduler starts running, and the annotation-second-scheduler pod gets scheduled as well.

$ kubectl apply -f myscheduler.yaml
$ kubectl apply -f pod.yaml
$ kubectl get pods -n kube-system
annotation-second-scheduler           1/1     Running   0          12s
calico-node-2pnlr                     1/1     Running   1496       88d
calico-node-4tz8c                     1/1     Running   804        88d
calico-node-dvzld                     1/1     Running   804        88d                    1/1
...
my-scheduler-754f9d4bf6-8xr7f         1/1     Running   0          59s