From Docker Compose to Kubernetes: training for application teams

We offer private, instructor-led training for developers who use Docker Compose and need to deploy their applications in a shared Kubernetes environment.

Your team already knows images, service definitions, and local volumes. A successful local startup does not explain production recovery, independent releases, or communication across nodes.

LearnKube connects your Compose application to Kubernetes through a web service, worker, and datastore. Your engineers will practice deployment, dependency failures, and data recovery.

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.

Move beyond a successful local startup

  • Deploy the application components by separating workload controllers, configuration, and Services, so each component has an appropriate lifecycle.
  • Preserve dependency access by configuring discovery and readiness and examining application retries, so a temporary dependency failure does not require a manual restart.
  • Diagnose multi-node failures by inspecting Pod events, DNS, endpoints, and volume mounts, so developers can identify the layer that prevents progress.
  • Define shared-cluster responsibilities by documenting namespace permissions and escalation paths, so application and platform engineers know which changes they own.

Startup order is only the first dependency problem

Compose can use depends_on to order services and wait for a declared health check. Kubernetes manages each workload through its own controller, while readiness determines whether Pods receive Service traffic. The application still needs to tolerate dependencies that restart or disappear after startup, especially when its components run on different nodes.

I focus on what happens after a dependency disappears, not only on the first startup. A healthy initial sequence does not tell us whether the application can reconnect when another container or node fails.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Start dependent servicesIndependent workload lifecyclesRecover a lost dependency
Reach another containerServices and cluster DNSTrace a service connection
Retain application dataPersistentVolumeClaims and mountsReplace a stateful Pod
Release one componentProbes and rolling updatesDiagnose an unready release

How we approach this transition

We propose a workshop around one multi-component application. Your team identifies which containers need independent releases, which connections must recover, and which data must outlive a Pod.

The exercises introduce failures that a single successful Compose startup cannot demonstrate. A component becomes unavailable, its replacement receives a different address, and the application must recover without a complete stack restart.

A recommended four-day workshop for Compose users

This proposed agenda keeps familiar container concepts brief. It focuses on the workload and recovery decisions that change in a shared, multi-node environment.

Day 1

We compare Compose services with Pods, Deployments, and Services. You will examine startup, readiness, and liveness probes before you rehearse a release with an unavailable dependency.

Hands-on exercises

  • Deploy the web and worker components with separate workload resources.
  • Interrupt a dependency and distinguish readiness behavior from application recovery.

Day 2

You will use Helm and compare Kustomize for environment-specific configuration. We explain reconciliation, the control plane, and kubelets through the replacement of an application instance.

Hands-on exercises

  • Package the application's resources for two environments.
  • Simulate a node failure and observe which components Kubernetes recreates.

Day 3

We connect familiar service names to Kubernetes DNS and Service endpoints. You will examine ingress, network policies, service mesh use cases, and placement on shared nodes.

Hands-on exercises

  • Trace a request from ingress through a Service to a Pod.
  • Diagnose a dependency connection blocked by a network policy.

Day 4

You will compare local volumes with persistent storage and separate configuration from images. We cover autoscaling metrics, resource requests, authentication, and namespace-scoped RBAC.

Hands-on exercises

  • Replace the datastore Pod and confirm that the application can still read its data.
  • Apply load to the stateless tier and observe metrics-based replica changes.

Your Compose services, data dependencies, and shared-cluster responsibilities can shape the agenda. Get in touch to tailor the workshop to your Compose-to-Kubernetes transition.

Challenge the startup-only recovery model

An engineer can bring a Compose dependency definition and explain its health checks. The instructor can interrupt the dependency after startup and show why client recovery and readiness answer different questions.

The practical application with the labs were challenging and fun

— Brandon, Product Manager of DevSecOps at Sabel Systems.

Start with one application and its dependencies

Tell us which services you run with Compose, what the shared cluster will provide, and who will support application failures. We will recommend exercises for those responsibilities.

Discuss your team's training