The Kubernetes scheduler is the brain of the cluster, deciding which node runs each Pod. This is the second post in a series where I explore advanced scheduling mechanisms in Kubernetes. In this one, I give an overview of the current state of the Kubernetes scheduling framework. I explain how Kubernetes scheduling works as a batch-oriented process that handles one Pod at a time. I walk through the evolution from the older predicates and priorities model to the modern Scheduling Framework, where each step in the scheduling cycle is an extension point for plugins. I also cover extenders, PreEnqueue plugins, and SchedulingGates, which enable more flexible and complex scheduling workflows. Finally, I highlight projects like Kueue and the Multiarch Tuning Operator that build on these features to support AI, HPC, and multi-architecture workloads.

The Kubernetes scheduler is the brain of the cluster, deciding which node runs each Pod. This post is part of a series where I explore advanced scheduling mechanisms in Kubernetes. In this part, I focus on the current state of the default scheduler. I walk through how the default scheduler works under the hood, breaking it down into queueing, filtering, scoring, binding, and preemption. I explain how Pods move through different queues, how the scheduler picks viable nodes, and how it scores and selects the best one. I also touch on newer features like QueueingHint and PreEnqueue plugins, and discuss how the scheduler balances performance and fairness at scale. If you’re curious about how Kubernetes makes scheduling decisions, this post offers a detailed look at the mechanisms behind it.

Embed MicroShift into Fedora CoreOS, through OSTree Native Containerization. Let’s delve into how I managed to run the initial setup of MicroShift, including CoreOS dex as an OAuth identity provider backed by GitHub, the OpenShift console, ArgoCD for GitOps, and the cert-manager operator for the automatic provisioning of the SSL certificates for the Openshift Routes.