Private, instructor-led training for engineers who need to explain why existing Kubernetes workloads are placed, delayed, or excluded from particular nodes.
A free resource figure does not establish an eligible placement. Requests, labels, affinity, taints, topology, and the current cluster state can impose different constraints on the same Pod.
LearnKube connects those mechanisms through a representative workload. Engineers inspect the scheduler's evidence, change one requirement, and verify the effect on placement and application behavior.
Hands-on learning and the skills engineers take back to work.
Preview: course-wide figures are not yet available.
The team already sets scheduling fields, but affinity and selectors restrict or prefer nodes in different ways. Tolerations permit matching taints without guaranteeing placement. Resource requests and other constraints still apply. Engineers need to inspect the combined conditions and current cluster state before explaining a Pending Pod or treating a successful scheduling result as evidence of the intended policy.
I ask which rule makes a node eligible and which rule makes it preferred. A toleration does not direct the Pod to that node, so the intended placement needs to be verified against all relevant constraints.
— Daniele Polencic, LearnKube founder and Kubernetes instructor
| Production question | Mechanism to understand | Practice |
|---|---|---|
| Which nodes are eligible? | Required constraints and requests | Inspect scheduler exclusions |
| Which nodes are preferred? | Scoring and soft affinity | Compare suitable placements |
| What does the toleration permit? | Taints and tolerations | Verify remaining constraints |
| Does placement survive change? | Capacity and topology conditions | Repeat after a bounded change |
JPMorgan's private Kubernetes training involved different starting levels. A team lead specifically wanted to understand scheduling mechanisms for possible risk-analytics enhancements, while other engineers needed introductory material.
LearnKube delivered training for the group. The proposed agenda here focuses on placement reasoning and controlled comparisons rather than claiming a completed scheduler implementation or production optimization.
We establish the workload foundations needed by the participants, then concentrate on scheduling evidence. Custom scheduler engineering requires a separately scoped API extension exercise.
Day 1
Explain replicas, resource requests, health checks, and application availability. Identify what the placement policy needs to achieve before writing constraints.
Hands-on exercises
Day 2
Connect templates, admitted Pod specifications, scheduler behavior, and current node state. Inspect the complete effective configuration rather than one field in isolation.
Hands-on exercises
Day 3
Examine required and preferred affinity, tolerations, spreading, and available failure domains. Connect placement with network or storage dependencies where relevant.
Hands-on exercises
Day 4
Review storage locality, resource demand, autoscaling, and access to placement controls. Repeat the decision under a controlled change in available capacity.
Hands-on exercises
Your placement requirements, capacity questions, and workload responsibilities can shape the agenda. Get in touch to tailor the workshop to your team's work.
When an engineer adds a toleration and expects a particular placement, the instructor can inspect the remaining requirements and preferences. Daniel described practical learning in another course:
The labs were great for helping me better commit things to memory.
— Daniel, Senior Backend Engineer at Rebellion Defense.
Tell us which workloads you schedule, which constraints or failures remain unclear, and which node and workload settings you own. We will recommend appropriate mechanisms and comparison exercises.