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
Level 1: Requests & Limits

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

Time
180s
Score
Nodes used: 0
Remaining Pods
5
Tap a pod to see constraints and node compatibility.
node-a
zone: us-east-1a
CPU 0m / 2500m
Mem 0Mi / 4096Mi
Placed Pods
node-b
zone: us-east-1b
CPU 0m / 2500m
Mem 0Mi / 4096Mi
Placed Pods

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
$ cd /games
// share