Kubernetes training for your next engineering group

We provide private, instructor-led Kubernetes training for organizations that want to extend useful initial learning to more engineers.

The first group benefited from the course, but each new group has its own background and needs. A repeat course needs the right starting level, even if the technical basics remain the same.

LearnKube connects that foundation to a sample release for the new group. Guided practice and clear explanations help each learner identify what they understand and where they need more support.

Discuss your team's training

Hands-on learning and the skills engineers take back to work.

Preview: course-wide figures are not yet available.

  • Hands-on learning
    60%
    Of instruction time spent on labs and challenges.
  • Troubleshooting confidence
    86%
    Of respondents report greater confidence diagnosing Kubernetes problems.
  • Relevant to your work
    92%
    Of respondents say the course addressed their engineering responsibilities.
  • Skills put into practice
    95%
    Of respondents applied their new skills at work within 90 days.

Preserve the useful foundation and adapt the practice

  • Orient the next group through its current tasks and knowledge, so the course begins at the right technical level.
  • Practice a sample release with guidance on controllers and service access, so learners can explain the application's behavior.
  • Demonstrate the same concepts differently through a changed workload example, so the next group can identify what it still needs to learn.
  • Keep explanations for later use with annotated examples and references, so future practice connects to this group's work.

The same resource needs an explanation for this group

Different engineering groups can use the same Deployment but make different changes. One developer changes application behavior, while another investigates Service access. Both need to connect selectors, replicas, and readiness to their observations. A sample release establishes that foundation. A variation then reveals which explanation each learner still needs.

I keep the mechanism consistent, but ask the next group to explain it through its own task. Repeating the earlier group's exercise unchanged can hide a prerequisite or responsibility that deserves more time.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Role milestoneRequired knowledgePractice/check
Join the next courseExisting knowledge and tasksExplain a relevant workload
Complete guided practiceReplicas, selectors, and healthRelease a reference service
Apply the foundationBehavior under changed conditionsInvestigate a task variation
Continue after the courseRole-specific questions and referencesRecord the next exercise

Case Study: Baillie Gifford

After engineers gave positive feedback about LearnKube training, Baillie Gifford asked for a private course for more of their team. They also wanted the content tailored to their needs.

LearnKube provided private training. Rick, who took the Baillie Gifford course, shared what he liked most:

The first part and the interactivity

— Rick, Software Developer at Baillie Gifford.

A recommended four-day path for the next cohort

This proposed agenda keeps the technical basics but adapts examples and pace to the new group's work. Each day, learners explain a task before the next step.

Day 1

We build on what the group already knows about containers, connecting it to Pods, Deployments, Services, and probes. The group completes a guided release and explains how the resources relate to the application's response.

Hands-on exercises

  • Deploy a reference service and explain the resources relevant to each learner's task.
  • Compare rollout progress with readiness and identify any prerequisite that needs more time.

Day 2

We use Helm and compare it with Kustomize to show how to separate shared resources from environment-specific settings. We also discuss architecture to link the group's actions to controllers, nodes, and replacing workloads.

Hands-on exercises

  • Change a supplied value and explain which generated resource differs.
  • Repeat a replacement exercise with fewer prompts and identify the responsible components.

Day 3

We follow DNS, Services, ingress, policy, and placement through the reference service. If the group needs it, we add a discussion about service mesh for extra depth.

Hands-on exercises

  • Diagnose a connectivity variation and explain the evidence rather than repeat the earlier example's steps.
  • Identify a scheduling constraint and describe the assistance required from the platform team.

Day 4

We link state, secrets, scaling metrics, authentication, and RBAC to the application. Learners work through a variation that fits their role and come up with questions for further practice.

Hands-on exercises

  • Explain a change that combines workload configuration with data or access requirements.
  • Record a useful follow-up exercise and the references that support its explanation.

Your next group's skills, responsibilities, and feedback from previous sessions can shape the agenda. Get in touch to tailor the workshop to your next engineering cohort.

Keep the foundation while adapting the example

If the new group sees a ready Pod as proof of service access, the instructor can change a selector. This helps learners tell the difference between application health and the network path their task needs.

Start with who needs the next course

Tell us what the previous group found useful, what the next group already knows, and which tasks it needs to perform. We will recommend a starting point, examples, and continued practice for those engineers.

Discuss your team's training