From VMware Tanzu to another Kubernetes distribution: training for platform teams

We offer private, instructor-led training for teams that operate Kubernetes through a Tanzu environment and need to transfer workloads and operations to another distribution.

Your engineers know Kubernetes resources. The exact Tanzu product and integrations matter, because familiar manifests can depend on provisioning APIs, controllers, storage drivers, or identity services.

LearnKube uses a representative application and its dependencies to make that comparison concrete. Your team will practice deployment and diagnosis against the destination's actual capabilities.

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 dependencies behind familiar manifests

  • Deploy a representative workload by separating built-in resources from platform-specific dependencies, so the team can identify what the destination must provide.
  • Preserve application behavior by comparing traffic, storage, and identity integrations, so a resource accepted by the API has the services it needs.
  • Diagnose missing integrations by inspecting custom resources, controller status, and workload events, so engineers distinguish absent platform behavior from application failure.
  • Assign lifecycle responsibilities by documenting provisioning, upgrades, and support procedures, so the new distribution has clear operational ownership.

Compare the product's integrations, not only Kubernetes versions

A Tanzu environment combines Kubernetes with product-specific lifecycle and infrastructure integrations. The destination can support familiar workload APIs while lacking required custom resources and controllers or a compatible storage provisioner. The team needs an inventory of the actual product, version, and dependencies before deciding which resources and operating procedures can transfer.

I want to know which controller acts on a resource, not only whether its YAML looks familiar. A Tanzu transition needs a dependency inventory before the team can judge what the destination must replace.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Provision application resourcesAPIs and controller dependenciesIdentify unsupported resource kinds
Supply persistent storageProvisioners and storage classesDiagnose an unbound claim
Expose a serviceDestination traffic controllersTrace the application route
Maintain cluster lifecycleDistribution-specific operating proceduresMap an upgrade handoff

How we approach this transition

We propose a workshop based on your exact Tanzu product, version, and deployment model. Your team examines one application and the infrastructure services on which it depends.

The comparison separates workload changes from cluster-management changes. We adapt the proposed exercises to the destination rather than assume that every Tanzu installation has the same components or operating procedures.

A recommended four-day workshop for a distribution transition

This proposed agenda builds on existing Kubernetes knowledge. It emphasizes dependency identification and the behaviors that the destination needs to preserve.

Day 1

We review the application's resources, probes, and release behavior. You will distinguish built-in workload APIs from extensions and compare rollout expectations on the selected destination.

Hands-on exercises

  • Deploy the application's portable resources and identify unresolved dependencies.
  • Introduce an unready release and inspect the available rollback path.

Day 2

You will use Helm and compare Kustomize for destination configuration. We review control-plane and node responsibilities, with attention to custom controllers and cluster lifecycle operations.

Hands-on exercises

  • Separate common workload configuration from platform-specific resources.
  • Diagnose a custom resource whose controller is unavailable in the lab.

Day 3

We compare DNS, Services, ingress, network policies, and service mesh requirements. You will inspect affinity, taints, and topology constraints against the destination's available nodes.

Hands-on exercises

  • Trace a request through the selected ingress and Service configuration.
  • Inspect a placement rule that depends on labels absent from the destination.

Day 4

You will compare storage classes, credential delivery, and data-recovery responsibilities. We connect autoscaling metrics, authentication, and RBAC to the destination's integrations and operating model.

Hands-on exercises

  • Diagnose a persistent-volume request that references an unavailable provisioner.
  • Verify the application's identity and access to a required external service.

Your Tanzu product, destination distribution, and operational dependencies can shape the agenda. Get in touch to tailor the workshop to your Tanzu distribution transition.

Find the controller behind a portable-looking resource

When an engineer assumes that copying a custom resource restores its behavior, the instructor can inspect the API and controller separately. Your team can see why a stored object alone does not implement the platform function it describes.

Fantastic and Knowlegable instructor, easy to follow labs, and fruitful disscussions

— Jason, Principal Consultant at F5.

Start with the exact Tanzu environment

Tell us which Tanzu product and version you operate, which distribution you plan to adopt, and who owns the current integrations. We will recommend exercises for that specific transition.

Discuss your team's training