Kubernetes Helm and GitOps training for platform engineers

Private, instructor-led training for engineers who already deploy through templates and GitOps but need to explain the live result and recover from configuration failures.

A successful render or sync does not resolve every ownership question. Value precedence, desired-state sources, controller policy, and workload health can disagree during a change.

LearnKube traces an illustrative release from source values to live behavior. Engineers diagnose the difference, select the appropriate correction point, and verify how reconciliation responds.

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.

Identify the source of truth before applying the fix

  • Explain the delivery behavior through rendering, ownership, and reconciliation, so engineers can identify which system controls the intended configuration.
  • Diagnose an unexpected live result using values, manifests, controller status, and workload evidence, so the team can distinguish a rendering problem from drift or application failure.
  • Validate a configuration correction through the actual delivery path, so the change persists and produces the intended workload behavior.
  • Make release reviews repeatable through a source-to-live comparison and recovery record, so another engineer can follow the same ownership decisions.

A chart does not identify the release owner

The team already uses charts and GitOps, but the rendering tool and lifecycle owner can differ. Argo CD uses Helm to render manifests, while its sync policy determines how selected differences are reconciled. Engineers must identify the authoritative source and effective values before choosing a recovery action or assuming a manual cluster edit will remain in place.

I ask which system owns the release before reaching for its history. A chart rendered by Argo CD is not automatically a Helm-managed release, so recovery must follow the actual source of desired state.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Production questionMechanism to understandPractice
Which values were applied?Rendering and value precedenceCompare source and manifests
Who owns the lifecycle?Release and reconciliation ownershipTrace the delivery controller
Why did the fix disappear?Sync and self-healing behaviorObserve a controlled live edit
Is recovery complete?Desired state and workload healthVerify the supported correction

Case Study: BMW

BMW already used Helm and GitOps within an EKS platform and wanted a deeper understanding of its delivery workflow and operating decisions. LearnKube delivered private Kubernetes training for the team.

Asked what he valued most, Xaver identified the conceptual explanations:

Explanation of concepts

— Xaver, VR/AR Developer at BMW.

A proposed four-day workshop on configuration reasoning

Participants need basic workload and Git knowledge. We adapt the existing templating material to the delivery components in use and one representative application change.

Day 1

Explain Deployment behavior, probes, labels, and application responses. Distinguish a successful delivery operation from the workload result it was intended to produce.

Hands-on exercises

  • Establish the application's intended state and health observations.
  • Diagnose a release whose resources apply successfully but behave incorrectly.

Day 2

Inspect rendering inputs, precedence, generated resources, and lifecycle ownership. Compare how the selected delivery controller uses the output.

Hands-on exercises

  • Trace an unexpected value from source configuration to the live resource.
  • Identify which history and source can support the required recovery action.

Day 3

Connect sync policy to network resources, placement, and controller-managed fields. Observe why a manual edit can be corrected or overwritten by another owner.

Hands-on exercises

  • Make a controlled live change with self-healing explicitly configured in the lab.
  • Diagnose a route or placement difference introduced by rendered configuration.

Day 4

Review secrets, persistent effects, permissions, and scaling interactions during correction. Verify both the authoritative configuration and the application result.

Hands-on exercises

  • Apply a supported correction through the intended delivery path.
  • Record values, resource differences, ownership, and recovery observations.

Your delivery tools, configuration questions, and release responsibilities can shape the agenda. Get in touch to tailor the workshop to your team's work.

Ask which controller will act after the manual change

When an engineer proposes a direct edit, the instructor can trace the configured source and reconciliation policy first. The exercise reveals whether the edit is a durable correction or a temporary change that another controller will replace.

Bring the release path and the differences you cannot explain

Tell us which templates and GitOps components you use, where live behavior diverges from your expectations, and which configuration sources your team owns. We will recommend a focused delivery investigation.

Discuss your team's training