How to Bring your own Scheduler into OpenShift with the Secondary Scheduler Operator

To understand the Secondary Scheduler Operator, we need to understand the Kubernetes scheduler. The Kubernetes scheduler is an enterprise grade stable component in Kubernetes that decides where to place the incoming pods by a two step operation of filtering and scoring. The Kubernetes scheduler works well for applications that need to schedule pods in a sequence, for example a web application. Now the customer sees the benefits of Kubernetes, like DevOps and portability. They want to transform their specialized workload like HPC, Telco into containers and run it in Kubernetes. The default scheduler that works well for web servers does not work well for these specialized applications because these applications have special needs from the scheduler. For example:

  1. Coscheduling: Start, execute and finish all pods at same time.
  2. Topology Aware Scheduler: Schedule pods based on node topology.
  3. Load Aware Scheduler: Schedule pods based on load of the nodes.

So there is a need for new schedulers to run specialized workloads.

OpenShift is Red Hat’s enterprise Kubernetes distribution. This means OpenShift has the same scheduler as upstream Kubernetes, which is stable and enterprise grade but best suited for applications that need to schedule pods in a sequence. We in Red hat always listen to our customers and partners that there is a need to bring in their own scheduler, which can best run their application.

The Secondary Scheduler Operator allows customers or partners to bring in their own scheduler in OpenShift and run their application with that customized scheduler.OpenShift 4.x has been re-architected to be a self hosted platform which uses the same OpenShift constructs that any workload running on OpenShift uses. In order to safeguard the control components from the custom scheduler that the end user (customer) can bring in, we decided to have a secondary scheduler which does not have any impact on the control plane components.

Architecturally the default scheduler is responsible for schedu ling all the workloads including control plane components; however if the customer chooses to bring their own scheduler, they can leverage secondary scheduler operator to manage the workloads of their choice but the control plane components would still use the default scheduler shipped with OpenShift.

The following diagram explains the overall flow of how to add your scheduler as payload via the Secondary Scheduler Operator provided by Red Hat.

Learn more: https://cloud.redhat.com/blog/how-to-bring-your-own-scheduler-into-openshift-with-the-secondary-scheduler-operator

--

--

--

CLOUD TECHNOLOGY STRATEGY ADVISORY

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

LOOPStarter Airdrop Official Announcement

Uploading Images with Rails API and React

How to be functionally lazy with Monix Coeval?

VelocityX Animated Page View In Flutter

No Sql: Mongo db Misconceptions

Implementing 3D Charts In Angular Application.

Computer Science Engineering : Dear Freshman, from Sophomore

Teach Abstract with Noughts and Crosses

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
cloudstrata GmbH

cloudstrata GmbH

CLOUD TECHNOLOGY STRATEGY ADVISORY

More from Medium

Apache Ignite in Nussknacker environment. Lessons learned

Kafka Authentication with SCRAM

Notes on schema registry/cloudevents in Kafka

What is Apache Kafka And Choosing Right Partition Count & Replication Factor With Cluster…