<p>Following this K8s page <a href="https://kubernetes.io/docs/tasks/extend-kubernetes/configure-multiple-schedulers/" rel="nofollow noreferrer">here</a> on how to use multiple schedulers,and <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/" rel="nofollow noreferrer">this</a>, all I could see is that the <code>schedulerName</code> is taking place under <strong>the pod's spec</strong> , though I don't understand if this is explained particularly to single pods (as Pod is the smallest k8s deployable object), or even when a pod is attached to deployment or other deployable resources. In my case, I have a custom scheduler, &amp; I want it to handle scheduling a Daemonset object. I have tried two options:</p>
<p>a. Put the <code>spec.schedulerName: custom-scheduler</code> under the daemonset pod's specs.</p>
<p>b. Put the <code>spec.schedulerName: custom-scheduler</code> under the daemonset specs.</p>
<p>And the results are:</p>
<p>a. The pods of the daemonset were scheduled by the custom-scheduler as can be seen by the pods events.</p>
<p>b. The pods of the daemonset were scheduled by the default scheduler of kube-system.</p>
<p>My question is:</p>
<p>Can the user determine the scheduler for deployable k8s objects other than Pods, for example daemonset/ deployment/replicas? if not, please explain why &amp; how this works internally. Your insights are very appreciated.</p>

<ul>
<li>when i check documentation for daemonset.spec i do not see a <code>schedulerName</code> at all as following :</li>
</ul>
<pre><code>kubectl explain daemonset.spec
KIND:     DaemonSet
VERSION:  apps/v1

RESOURCE: spec &lt;Object&gt;

DESCRIPTION:
     The desired behavior of this daemon set. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

     DaemonSetSpec is the specification of a daemon set.

FIELDS:
   minReadySeconds      &lt;integer&gt;
     The minimum number of seconds for which a newly created DaemonSet pod
     should be ready without any of its container crashing, for it to be
     considered available. Defaults to 0 (pod will be considered available as
     soon as it is ready).

   revisionHistoryLimit &lt;integer&gt;
     The number of old history to retain to allow rollback. This is a pointer to
     distinguish between explicit zero and not specified. Defaults to 10.

   selector     &lt;Object&gt; -required-
     A label query over pods that are managed by the daemon set. Must match in
     order to be controlled. It must match the pod template's labels. More info:
     https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

   template     &lt;Object&gt; -required-
     An object that describes the pod that will be created. The DaemonSet will
     create exactly one copy of this pod on every node that matches the
     template's node selector (or on every node if no node selector is
     specified). More info:
     https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template

   updateStrategy       &lt;Object&gt;
     An update strategy to replace existing DaemonSet pods with new pods.
</code></pre>
<ul>
<li>it is available only for pod.spec ( my kubernetes version is 19.4 )</li>
</ul>
