Multiple schedulers & profiles
Running and targeting custom scheduling logic.
In plain terms
Running a second scheduler is hiring a specialist host for one section of the restaurant, and telling certain guests to “ask for them by name” when they arrive.
The default scheduler is not the only option — you can run additional schedulers with different logic and tell specific pods to use one via schedulerName. It is useful when a class of workload needs placement rules the default scheduler does not model, like gang-scheduling a batch job.
pod-spec.yaml
spec:schedulerName: my-scheduler # wait for a scheduler that claims this namecontainers: [{ name: app, image: nginx }]
A pod naming a schedulerName that no running scheduler claims stays Pending forever — the same failure mode as no scheduler at all. Custom schedulers usually run as a Deployment in the cluster and watch for pods that name them. Scheduler profiles are the lighter-weight alternative: several named profiles inside the one default scheduler binary.
Name mismatches strand pods
If a pod names a scheduler that is not running, nothing ever places it. Check kubectl get events for the pod, and confirm the scheduler Deployment is healthy.