Docker and Kubernetes foundations for software engineers

We offer private, instructor-led training for software engineers preparing to contribute to Kubernetes workloads and releases.

The group can bring established application-development experience but uneven knowledge of images, containers, and orchestration. A job title does not establish the prerequisites for the next exercise.

LearnKube connects familiar application behavior to packaging, configuration, and workload resources. Learners progress from a supported deployment toward a change whose result they can explain and revisit.

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.

Build the foundation for a first workload contribution

  • Orient to the application runtime by connecting source code and dependencies to images, containers, and Pods, so the learner understands where the program executes.
  • Practice a supported deployment with explicit configuration and health checks, so the learner can explain what the resources ask Kubernetes to do.
  • Demonstrate a small release change through a new version or setting and its observed behavior, so the learner can identify gaps before a broader task.
  • Retain the deployment reasoning through a repeatable example and selected references, so the engineer can revisit the relevant foundation during later work.

Connect application behavior to its execution environment

Software engineers already reason about code, dependencies, and settings. Kubernetes work adds a distinction between an immutable container image and configuration supplied to a Pod. Before a first release, learners need to identify which change belongs in each place. The course makes that distinction visible through a small application whose response changes with its image or settings.

I ask an engineer which file belongs in the image and which value belongs in configuration. Those choices expose gaps that a successful copied deployment can leave hidden, especially when the next environment needs different settings.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Role milestoneRequired knowledgePractice/check
Describe the runtimeImages and container processesIdentify code and dependencies
Supply an environment valueConfiguration and Pod specificationExplain the observed setting
Change an application versionWorkloads and release healthInspect a supported rollout
Repeat the learning taskPrerequisites and referencesExplain a changed example

Case Study: L3Harris

L3Harris software engineers completed Docker and Kubernetes training with LearnKube. A later learning request again sought beginner-to-intermediate instruction, with the starting knowledge and course depth considered together.

William described the practical element of a completed course:

I like how interactive the class was with the lab assignments.

— William, Software Engineer at L3Harris.

A recommended four-day path from code to workload changes

This proposed agenda makes entry assumptions visible before later exercises. Where learners already understand containers or basic resources, the instructor can move that time into role-relevant practice.

Day 1

We connect container processes, images, ports, and environment variables to Pods, Deployments, Services, and probes. Learners complete a supported deployment and explain what runs and how it becomes reachable.

Hands-on exercises

  • Package a sample application and distinguish image contents from supplied configuration.
  • Deploy it with guidance and explain its startup, readiness, and request path.

Day 2

We use Helm and compare Kustomize to express environment differences. Architecture examples show how the API, controllers, and kubelet connect the submitted resources to the application process.

Hands-on exercises

  • Prepare a second configuration and explain what changes without rebuilding the image.
  • Repeat a small release task with fewer prompts and identify its controller and resulting Pods.

Day 3

We trace DNS, Services, ingress, and network policy through the application. Scheduling and service mesh examples distinguish a problem in the workload from one that requires platform knowledge.

Hands-on exercises

  • Investigate a supplied port or selector mismatch and explain why the request fails.
  • Identify whether an unavailable instance is waiting for resources or failing during application startup.

Day 4

We connect persistent state, secrets, autoscaling metrics, and access to the sample workload. Learners combine the relevant concepts and explain the boundaries of the task they can now demonstrate.

Hands-on exercises

  • Make a supported change that uses separate configuration and persistent data.
  • Explain the final workload, note unresolved questions, and select a repeat exercise for the next learning step.

Your learners' application knowledge, next workload responsibilities, and preparation plans can shape the agenda. Get in touch to tailor the learning path to your team.

Establish the prerequisite before adding another resource

When a learner changes a running container and expects a new Pod to keep that change, the instructor can compare the image and runtime filesystem. That explanation gives the engineer a foundation for the next release exercise.

Start with the engineers and their next application task

Tell us what the group knows about containers, what Kubernetes work it needs to begin, and how learners will practice afterward. We will recommend the starting depth and exercises for that progression.

Discuss your team's training