From vSphere applications to Kubernetes: training for infrastructure teams

We offer private, instructor-led training for infrastructure and application engineers who need to containerize suitable services from vSphere virtual machines.

Your team understands guest operating systems, virtual disks, and machine recovery. An application image has a different lifecycle from a VM, including its configuration, state, and release process.

LearnKube uses a representative service to separate application requirements from guest-machine configuration. Your engineers will build an image, deploy it, and investigate replacement and storage behavior.

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.

Separate application requirements from the machine

  • Package the application by identifying its process, runtime dependencies, and image contents, so the deployment does not depend on manual changes to a guest.
  • Preserve required data by separating configuration and persistent storage from the image, so replacement Pods can recover the state they need.
  • Diagnose deployment failures by inspecting image startup, probes, mounts, and network paths, so engineers distinguish application problems from node or infrastructure faults.
  • Define the operating boundary by documenting application, Kubernetes-node, and vSphere responsibilities, so remaining infrastructure has a clear support owner.

An image replaces packaging, not every machine responsibility

A vSphere VM includes a guest operating system and the services installed inside it. A container packages a process and its dependencies while sharing the host kernel. Kubernetes then manages that workload through controllers. Configuration and persistent storage need explicit lifecycles instead of depending on a long-lived guest or its virtual disks.

I ask which changes disappear when the application is rebuilt from its image. If a manual repair inside the old VM remains necessary, the team has not yet captured the application's complete runtime requirements.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Install the applicationImage contents and startupBuild a repeatable image
Retain service configurationConfigMaps and SecretsReplace a configured Pod
Keep application filesPersistentVolumeClaims and mountsRecover durable data
Restore a failed instanceControllers and health probesObserve replica replacement

How we approach this transition

We propose a workshop around the process and dependencies inside one VM. The team identifies a suitable application and separates its image, configuration, and persistent data requirements.

The exercises focus on application containerization. Existing VMs can still provide Kubernetes nodes or host services that remain outside the cluster. We make those boundaries explicit rather than assume that the hypervisor disappears.

A recommended four-day workshop for VM-based application teams

This proposed agenda gives containers more attention on the first day. It connects familiar infrastructure concerns to the application lifecycle on Kubernetes.

Day 1

We compare containers with VMs, then build an image for a selected service. You will connect its startup behavior to Pods, Deployments, Services, and release health checks.

Hands-on exercises

  • Build and deploy an application without manual changes inside the running container.
  • Introduce a startup failure and inspect the rollout before restoring the previous version.

Day 2

You will use Helm and compare Kustomize to separate reusable resources from environment values. We explain the control plane, nodes, and reconciliation through application replacement.

Hands-on exercises

  • Create a repeatable release with separate environment configuration.
  • Simulate a node failure and trace how the controller restores replicas.

Day 3

We compare familiar machine addresses and ports with Pod networking, Services, DNS, and ingress. You will examine network policies, service mesh use cases, and placement requirements.

Hands-on exercises

  • Trace a request from an external endpoint to the application process.
  • Diagnose a workload that cannot reach an external service.

Day 4

You will examine persistent storage and distinguish data recovery from image replacement. We cover autoscaling, resource requests, authentication, and RBAC for application and infrastructure teams.

Hands-on exercises

  • Replace an application Pod and verify that its durable files remain available.
  • Scale a stateless tier under load and inspect the resulting resource demand.

Your application runtimes, storage requirements, and vSphere support responsibilities can shape the agenda. Get in touch to tailor the workshop to your application-containerization initiative.

Expose a dependency hidden inside the guest

An engineer can describe the steps used to repair an application inside its VM. The instructor can rebuild its container image and identify which package, file, or startup assumption the deployment still lacks.

Really good documentation! The Labs are perfect, even for "beginners"! I learned a lot, espacially hands on stuff, and I never used Kubernetes before.

— Johannes, Game Engine Developer at BMW.

Start with a service that can become a container

Tell us which applications run in vSphere VMs, what they require from the guest, and who will support the Kubernetes destination. We will recommend suitable examples and exercises.

Discuss your team's training