The k8s custom scheduler disables a certain scoring plug-in. Does it have any impact on the default scheduler?

Translation wujiuye 143 0 2024-03-14

This article is a translation of the original text, which can be found at the following link: https://www.wujiuye.com/article/a04a27905a0a4e04a9c9d98073c29d84

Author: wujiuye
Link: https://www.wujiuye.com/article/a04a27905a0a4e04a9c9d98073c29d84
Source: 吴就业的网络日记
This article is an original work by the blogger and is not allowed to be reproduced without the blogger's permission.

Due to the fact that Kubernetes’ default scheduler does not meet our requirements, we need to implement target load scheduling, which is a second development based on the scheduler-plugins scheduler.

Through the official documentation, we understand that Kubernetes supports retaining the default scheduler while also installing a custom scheduler, and supports running multiple schedulers simultaneously. You can specify which scheduler to use for pod scheduling; if not specified, the default scheduler is used.

From the documentation of scheduler-plugins, we learn that the load-aware scheduling plugin of scheduler-plugins requires us to disable the two default scoring plugins, NodeResourcesLeastAllocation and NodeResourcesBalancedAllocation (default plugins at the Scoring extension point). Hence, the question arises: when a custom scheduler in Kubernetes disables a certain scoring plugin, does it affect the default scheduler, and will the default scheduler also disable this scoring plugin?

    apiVersion: kubescheduler.config.k8s.io/v1
    kind: KubeSchedulerConfiguration
    leaderElection:
      leaderElect: false
    profiles:
    - schedulerName: scheduler-plugins
      plugins:
        multiPoint:
          enabled:
          - name: TargetLoadPacking
          disabled:
          - name: NodeResourcesLeastAllocated
          - name: NodeResourcesBalancedAllocation
      pluginConfig: 
        - name: TargetLoadPacking
           ......

Let’s start with the conclusion: It will not affect the default scheduler; it will only affect the scheduler-plugins scheduler itself. The default scheduler will not change due to the configuration of the custom scheduler.

The order of plugin invocation is as follows:

The default plugins for default extension points are always called first, followed by the custom scheduler (KubeSchedulerConfiguration) configuring and activating (enabled) plugins for the extension point, and then calling the activated (enabled) plugins in order.

If necessary, we can change the order in which the default plugin is called by first disabling (disabled) the default plugin and then adding the default plugin at a certain position in the activation (enabled) list.