Private, instructor-led training for engineers who already configure workload resources and need to explain their effects on placement, scaling, and application behavior.
Copied defaults and average utilization do not establish appropriate settings. Requests influence scheduling and some scaling calculations, while limits interact with runtime enforcement and application demand.
LearnKube uses a representative workload under defined conditions. Engineers compare observations, change one assumption, and determine whether the resource configuration better serves the application.
Hands-on learning and the skills engineers take back to work.
Preview: course-wide figures are not yet available.
The team already sets CPU and memory values, but requests and limits influence different scheduling and runtime mechanisms. CPU requests can also affect the utilization used by the HPA. Engineers must compare application demand, placement, enforcement, and scaling behavior before interpreting a smaller allocation as an improvement or applying one setting across unrelated workloads.
I want the workload held comparable while the setting changes. A lower request can alter placement and the autoscaler's utilization calculation, so the resulting replica count is not independent evidence that the application needs less capacity.
— Daniele Polencic, LearnKube founder and Kubernetes instructor
| Production question | Mechanism to understand | Practice |
|---|---|---|
| Why will the Pod not fit? | Requests and scheduler accounting | Inspect a placement rejection |
| Why is processing constrained? | Runtime resource enforcement | Compare application and container signals |
| Why did replicas change? | Utilization and request values | Trace an HPA calculation |
| Is the new setting better? | Comparable workload measurements | Evaluate a bounded adjustment |
Grab's Kubernetes platform work includes resource right-sizing, node-pool optimization, placement, observability, and support for experienced engineers. Those duties require an explanation of both workload and infrastructure behavior.
For that responsibility, we recommend a four-day workshop focused on resource mechanisms and controlled comparisons, without assuming a universal allocation or savings percentage.
We shorten familiar deployment tasks and examine a representative workload across its relevant demand conditions. Each change needs application evidence as well as resource measurements.
Day 1
Explain container resource settings, probes, and application responses. Distinguish workload failure from a process that remains running but cannot meet its intended behavior.
Hands-on exercises
Day 2
Connect Helm or Kustomize values to admitted resources and scaling configuration. Inspect defaults and calculations that can change the meaning of the submitted manifest.
Hands-on exercises
Day 3
Examine scheduler accounting, node resources, topology, and competing workloads. Relate a placement decision to the actual constraints rather than available memory alone.
Hands-on exercises
Day 4
Connect resource changes to state, scaling, and operational permissions. Define the service checks and recovery conditions required to accept a new setting.
Hands-on exercises
Your workload profiles, resource questions, and platform responsibilities can shape the agenda. Get in touch to tailor the workshop to your team's work.
When an engineer reports improvement from a smaller allocation, the instructor can compare demand, replica count, and placement between runs. Asked what he valued most in a separate course, Muhammad answered:
Labs and quiz
— Muhammad, Senior Software Engineer at Matillion.
Tell us which workloads you tune, which resource or scaling decisions remain uncertain, and which settings your team controls. We will recommend mechanisms and a defensible comparison exercise.