Master Real Kubernetes Scheduling on Windows: Ditch Single‑Node “Fake” Labs

1. Why a single node can’t teach scheduling

In a single‑node environment many classic scheduling scenarios cannot occur, so features like nodeSelector, Affinity and Taints appear to work but the scheduler actually has no choice—it merely places the pod on the only available node.

Affinity/Anti‑Affinity: no other node to compare, rules are invisible.

Taints & Tolerations: tainting the sole node can cripple the whole cluster.

Topology spread: without a topology there is no balanced distribution.

Consequently tutorials that look lively on a single node feel “off” when you run them.

2. Why I recommend Kind

If you are learning Kubernetes on Windows, especially with WSL2 and Docker Desktop, Kind is an ideal choice because it treats Docker containers as Kubernetes nodes.

Use Docker containers as K8s nodes.

Kind is widely used in the community for testing and CI/CD, and it offers clear benefits for learning scheduling:

Quickly spins up a real multi‑node cluster.

Allows verification of labels, taints, affinity, and anti‑affinity.

Shows the scheduler’s filtering and scoring results.

Low cost and works on Windows.

3. What the scheduler actually does

The Kubernetes scheduler follows a two‑step process: filtering and scoring.

1) Filtering

Nodes that do not satisfy the pod’s requirements are excluded.

Insufficient resources.

Label mismatch.

Pod lacks a toleration for a node’s taint.

Affinity rules not met.

2) Scoring

Among the remaining candidates, each node receives a score; the highest‑scoring node wins.

Which node is more idle.

Which node better matches the pod’s image.

Which node provides a more balanced resource distribution.

First filter out the unsuitable, then pick the most suitable.

4. Valuable scheduling experiments

Running hands‑on experiments cements the concepts.

1. nodeSelector : direct node targeting

Label a node: kubectl label nodes worker disktype=ssd Specify the selector in the pod:

nodeSelector:
  disktype: ssd

If the label does not exist, the pod stays Pending. This demonstrates that scheduling is about “can I go?” rather than “where do I want to go?”.

2. Node Affinity: flexible node selection

nodeSelector

is rigid (“must satisfy”). Node Affinity behaves like “prefer to satisfy”. It has two common modes: requiredDuringSchedulingIgnoredDuringExecution: hard requirement. preferredDuringSchedulingIgnoredDuringExecution: best‑effort preference.

This flexibility is why many production workloads prefer Node Affinity.

3. Pod Affinity / Anti‑Affinity: pod‑to‑pod relationships

Instead of only pod‑to‑node rules, these features let you co‑locate or separate pods.

Keep replicas of the same service away from each other to avoid single‑point failures.

Improve disaster‑recovery by spreading pods across nodes.

Seeing a replica become Pending instantly shows that the rule, not resource shortage, blocks placement.

4. Taints & Tolerations

Taints are applied to nodes; tolerations are added to pods. The relationship is “Node refuses Pod unless the pod presents a pass”.

“Ordinary Pods stay away unless they have a pass.”

A toleration does not pull a pod onto a node; it merely prevents the pod from being rejected. The final placement still depends on the scoring phase.

5. Requests / Limits / QoS

Scheduling looks at requests because the scheduler cares about the amount of resources a pod reserves.

Runtime enforcement uses limits , which cap the maximum resources a container can consume.

Scheduling → requests.

Runtime → limits.

When the node is tight, pods with different QoS classes receive different treatment.

Remember: requests are reservations, limits are caps.

6. PriorityClass / Preemption

If the cluster is out of resources, low‑priority pods may be evicted so higher‑priority pods can run—this is preemption.

Core services get higher priority.

Batch jobs yield to online workloads.

Critical monitoring components are protected.

Thus scheduling is not “first‑come, first‑served” but “who is more important gets priority”.

5. Why you should run it yourself

Understanding the “why” behind results requires observing real scheduler behavior: why a pod stays Pending, why a node rejects a pod despite tolerations, why affinity splits replicas, and why requests saturation stops new placements.

6. Suggested learning path

Use Kind to create a multi‑node cluster.

Perform the scheduling experiments in order.

Inspect pods with kubectl describe pod and watch Events.

Read scheduler logs and, if curious, the source code.

This moves you from merely writing YAML to truly grasping the design of the rules.

7. Final note

Many learners get stuck on the environment, not the concepts. A single node shows YAML syntax; a multi‑node cluster reveals the scheduler’s decision‑making.

If you are learning Kubernetes on Windows, switch to a multi‑node setup as soon as possible—you’ll avoid many detours.