Kubernetes Scheduler Profile Usage

Kubernetes Scheduler Profile Usage is the practice of configuring and selecting among multiple named scheduling behaviors — scheduler profiles — within a single kube-scheduler process, each defining its own set of enabled plugins, weights, and extension-point configuration, and each addressable by Pods through the spec.schedulerName field. Profiles allow a cluster to run several distinct scheduling policies simultaneously without deploying entirely separate scheduler binaries, making them the standard mechanism for tailoring scheduling behavior to different workload classes within one cluster.

A single kube-scheduler configuration can define multiple profiles, each identified by a unique schedulerName, and every Pod is scheduled by exactly one profile — whichever one its schedulerName field names, defaulting to default-scheduler if left unspecified.

Defining Multiple Profiles

Basic Structure

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
    plugins:
      score:
        enabled:
          - name: NodeResourcesFit
            weight: 1
  - schedulerName: codartium-batch-scheduler
    plugins:
      score:
        enabled:
          - name: NodeResourcesFit
            weight: 5
        disabled:
          - name: InterPodAffinity

Each profile can enable, disable, and reweight plugins independently, giving genuinely different scheduling priorities to different classes of workload processed by the same scheduler process.

Referencing a Profile from a Pod

spec:
  schedulerName: codartium-batch-scheduler
  containers:
    - name: batch-worker
      image: codartium/batch-worker:latest

A Pod with no schedulerName set implicitly uses default-scheduler; explicitly naming a different profile routes that Pod's scheduling decisions through the alternate plugin configuration instead.

Why Use Multiple Profiles Instead of Multiple Schedulers

Shared Process, Shared Cache

Profiles within a single kube-scheduler process share the same underlying node and Pod cache and the same scheduling queue infrastructure, avoiding the operational overhead, resource duplication, and potential state-consistency complications of running multiple entirely separate scheduler binaries against the same cluster.

Simpler Operational Footprint

A single scheduler process with multiple profiles is simpler to deploy, monitor, and upgrade than several independent scheduler deployments, each requiring its own leader election, metrics endpoint, and lifecycle management — profiles achieve differentiated behavior without multiplying the operational surface area.

Common Profile Use Cases

Bin-Packing for Batch Workloads

A profile favoring MostAllocated resource scoring (packing Pods tightly onto fewer, more heavily utilized nodes) suits cost-sensitive batch workloads where consolidating onto fewer nodes allows unused nodes to be reclaimed by a cluster autoscaler, in contrast to a LeastAllocated-favoring default profile spreading application workloads for resilience.

Extension Points for Specialized Coordination

Custom scheduler frameworks with additional plugins (implementing gang scheduling, for instance, coordinating placement of multiple related Pods as an atomic unit) are commonly exposed as a separate named profile, letting workloads needing that specialized coordination opt in via schedulerName while ordinary Pods continue using the standard default profile unaffected.

Testing New Scheduling Policies Safely

A new or experimental scoring configuration can be rolled out as an additional profile alongside the existing default, allowing a subset of workloads to be migrated to schedulerName: experimental-scheduler and evaluated before committing the change to the cluster's default scheduling behavior for everyone.

Profiles vs. Fully Separate Custom Schedulers

When a Separate Scheduler Binary Is Still Needed

Profiles share the same kube-scheduler binary and framework; a workload needing an entirely different scheduling algorithm not expressible through the standard plugin framework at all (a bespoke, external scheduling system with its own decision logic) still requires a genuinely separate scheduler deployment, registered under its own schedulerName, running as an independent process rather than a profile within kube-scheduler.

Choosing Based on the Nature of the Customization

If the needed customization can be expressed as a different combination or weighting of existing (or custom-written, but framework-compatible) plugins, a profile is the simpler and preferred approach; if it requires fundamentally different decision-making logic outside the plugin framework's model entirely, a standalone custom scheduler is necessary instead.

Verifying Which Profile Scheduled a Pod

kubectl get pod codartium-batch-worker -o jsonpath='{.spec.schedulerName}'
kubectl get events --field-selector involvedObject.name=codartium-batch-worker,reason=Scheduled

The Scheduled event's reporting component reflects which scheduler (and implicitly, which profile, if using the multi-profile single-binary approach) performed the placement, useful for confirming a Pod was actually routed through the intended profile.

Example

apiVersion: v1
kind: Pod
metadata:
  name: codartium-profile-example
spec:
  schedulerName: codartium-batch-scheduler
  containers:
    - name: worker
      image: codartium/batch-worker:latest
      resources:
        requests:
          cpu: "500m"
          memory: "512Mi"