Kubernetes operations training for teams inheriting EKS

Private, instructor-led training for application engineers responsible for a running EKS environment whose configuration and operating decisions they cannot yet fully explain.

The application already works, but that does not reveal how to maintain it. Resource ownership, delivery sources, node choices, and data dependencies must be understood before a change is reliable.

LearnKube connects the live resource model to a representative service and maintenance question. Engineers identify dependencies, investigate uncertainty, and record the operating knowledge they need to retain.

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.

Understand the running system before changing it

  • Explain the environment through workload ownership and infrastructure dependencies, so the team can identify the system responsible for each resource.
  • Diagnose an operating problem using deployment, node, storage, and access evidence, so engineers can distinguish configuration gaps from application failures.
  • Validate a bounded change against a recorded baseline, so the team can identify whether the intended service behavior is preserved.
  • Make ownership knowledge repeatable through an operating map and checked procedure, so future maintenance does not depend on one person's recollection.

A running resource does not explain who maintains it

The team already has live workloads, but their ownership relationships do not describe every delivery or infrastructure dependency. For example, EBS storage also depends on its driver, permissions, and supported compute. Engineers need to connect these relationships to configuration sources and recovery procedures before deciding which change belongs at the application or platform layer.

I start by asking what would recreate the resource after it disappears. A working Pod is useful evidence, but it is not a substitute for knowing the configuration, controller, credentials, and data that make it reproducible.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Production questionMechanism to understandPractice
What recreates this resource?Ownership and delivery sourcesTrace a workload dependency
Which data survives replacement?Volumes and storage integrationInspect recovery requirements
Who can perform the change?Kubernetes and AWS permissionsLocate an access boundary
Is the operating map correct?Observed change behaviorVerify a bounded procedure

Case Study: COBB

COBB needed a clearer operating model for an existing EKS environment. LearnKube combined self-paced material with guided work on the running system and its maintenance questions.

Nathan reported progress while identifying knowledge the team still needed:

I haven't actually talked to Andy yet, so I can't fully speak for him but I do think we're making progress. Overall I think we get the gist of how to interact with it, we just need to spend some time brushing up on AWS node management and volumes.

— Nathan, Software Engineer at COBB.

A proposed four-day workshop on operational ownership

We establish the foundations the team actually needs and work from an illustrative dependency map. The proposed agenda remains separate from COBB's combination of material and guided sessions.

Day 1

Explain Pods, controllers, Services, and probes through a service that already runs. Identify the resources and observations that describe its release and health.

Hands-on exercises

  • Trace a running Pod to its controller and configuration source.
  • Record a service baseline before changing its release configuration.

Day 2

Connect Helm or Kustomize output to controllers, node groups, and control-plane responsibilities. Identify assumptions hidden in a working installation.

Hands-on exercises

  • Compare delivered manifests with the resources actually in use.
  • Map the component and permission dependencies of a maintenance task.

Day 3

Trace DNS, Services, ingress, AWS integrations, and workload placement. Separate an application path from the infrastructure and permissions that support it.

Hands-on exercises

  • Explain how a request reaches the service from its client.
  • Diagnose a replacement workload that cannot obtain suitable capacity.

Day 4

Examine volume ownership, credentials, scaling signals, and RBAC. Validate the operating map through one bounded maintenance or recovery procedure.

Hands-on exercises

  • Verify the sample application's data and access requirements after replacement.
  • Document the procedure, observed result, and unresolved dependencies.

Your existing EKS configuration, operating questions, and team responsibilities can shape the agenda. Get in touch to tailor the workshop to your team's work.

Ask what makes the service reproducible

When an engineer identifies a running container as the complete application, the instructor can trace the objects, configuration sources, and external dependencies around it. The resulting map makes the next maintenance question more precise.

Start with the system you need to maintain

Tell us what your team operates on EKS, which parts it cannot confidently explain or change, and which services it owns. We will recommend foundations and guided operating exercises.

Discuss your team's training