Skip to main content

Kubernetes Scheduler Challenge

Drag-and-drop Pods onto Nodes while honoring kube scheduling rules: resources, taints/tolerations, selectors, and topology spread.

Category: Kubernetes

What You Will Learn

  • Understand Kubernetes pod scheduling algorithm
  • Configure resource requests and limits
  • Use node affinity, taints, and tolerations
  • Debug scheduling failures

Topics covered: kubernetes, scheduling, interactive

// simulator

Kubernetes Scheduler Challenge

Drag-and-drop Pods onto Nodes while honoring kube scheduling rules: resources, taints/tolerations, selectors, and topology spread.

Supported byBecome a sponsor
BitriseAtomsizedDigitalOceanDevDojoSMTPfastQuizAPI
1/4

Requests & Limits

180s
1 of 3 starsNodes used: 0

Goal: Place all Pods without exceeding node capacity. Learn requests and basic bin-packing.

How to play
  • Select a pod: tap it, or drag it onto a node on desktop.
  • Pick a node: it shows Fits or Does not fit, and bars preview requests.
  • Follow capacity, taints and tolerations, selectors and affinity, anti-affinity, and zone spread.
  • Tap a placed pod to take it off its node.
  • Fewer nodes and a faster finish earn more stars.

Pods to place

5

Colour shows the QoS class: Guaranteed, Burstable, BestEffort.

node-a

zone: us-east-1a

CPU 0m / 2500m

Mem 0Mi / 4096Mi

Placed pods: none yet

node-b

zone: us-east-1b

CPU 0m / 2500m

Mem 0Mi / 4096Mi

Placed pods: none yet

Overview

The Kubernetes scheduler decides which node each pod runs on, and most pods stuck in Pending are there because no node satisfies their constraints. In this simulator you play the scheduler yourself: drag each pod onto a node and the game tells you when a placement breaks a rule. Four levels add one kind of constraint at a time. The first is resource requests: a node can only take pods whose CPU and memory requests fit in what it has left, whatever the pods actually use. The second adds taints and tolerations for dedicated nodes, such as a GPU node that only accepts pods that tolerate its taint, and pod anti-affinity that keeps replicas apart. The third adds node selectors and node affinity, which steer pods toward nodes with particular labels. The fourth spreads replicas evenly across zones with topology spread constraints, so losing one zone does not take every replica with it. Placing pods by hand under a timer makes the filtering and scoring steps that the real scheduler runs feel concrete.

Try this

  1. In "Level 1: Requests & Limits", place the pods and see which node runs out of requested CPU or memory first.
  2. In Level 2, try to drop an ordinary pod on the GPU node and read why the taint rejects it.
  3. In Level 4, spread the api replicas across zones and see what breaks the topology spread rule.

Frequently asked questions

Why is my Kubernetes pod stuck in Pending?
Usually because no node satisfies its constraints: not enough unrequested CPU or memory, a taint the pod does not tolerate, a node selector or affinity that matches no node, or a missing persistent volume. kubectl describe pod shows the scheduler message.
What is the difference between requests and limits?
Requests are what the scheduler reserves when placing a pod. Limits are the ceiling enforced at runtime: exceeding a memory limit gets the container killed, and CPU above the limit is throttled.
What are taints and tolerations?
A taint on a node repels pods, and a toleration on a pod allows it onto nodes with a matching taint. They are used to reserve nodes, such as GPU nodes, for specific workloads.

Try next

Sponsored
Carbon Ads