From MKE Kubernetes to another Kubernetes distribution

Private, instructor-led training for platform teams that already run Kubernetes workloads through Mirantis MKE and need to transfer them to another distribution.

Your engineers already know the workload API. Next, they need to decide how to handle cluster lifecycle, identity, ingress, storage integrations, and ownership on the destination.

LearnKube uses a sample application to show how familiar manifests relate to platform dependencies. Your team will practice deployment, recovery, and diagnosis with the destination's operating model.

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.

Transfer the platform assumptions with the workloads

  • Prepare portable releases by separating workload manifests from distribution-specific configuration, so engineers can identify each required integration.
  • Preserve application behavior by reviewing ingress, storage, and access controls, so the destination supports the same operational requirements.
  • Diagnose missing integrations by inspecting controller events, volume binding, and permissions, so engineers distinguish workload errors from platform gaps.
  • Assign lifecycle responsibilities by documenting upgrades, component maintenance, and escalation paths, so the destination has clear operational ownership.

Familiar APIs can hide different integrations

Kubernetes workloads on MKE already use Pods, Deployments, and Services. Moving to another distribution changes the platform around those resources. Identity providers, ingress controllers, storage drivers, and cluster lifecycle procedures can differ even when the workload manifests look familiar. Engineers need to identify which behavior depends on those integrations.

An accepted manifest does not prove that the destination provides the same behavior. I compare the provisioner, reclaim policy, and access requirements behind a storage class before I call a stateful workload portable.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Reuse workload manifestsDestination API and controllersInspect deployment dependencies
Authenticate application operatorsIdentity integration and RBACTrace an access denial
Provision application storageDrivers and storage classesDiagnose an unbound claim
Maintain cluster availabilityDestination lifecycle ownershipRehearse a node outage

How we approach this transition

We propose a workshop around one application that represents your MKE Kubernetes dependencies. Your engineers will identify its routing, identity, storage, and lifecycle requirements before adapting the deployment.

During hands-on work, your team will use these requirements to compare source and destination behavior. This comparison helps the team identify questions for the platform design and practice the new operating model.

A recommended four-day workshop for platform teams

This proposed agenda spends less time on familiar Kubernetes concepts and focuses more on integration dependencies and decisions specific to the destination.

Day 1

You will review API resources, probes, and rollout behavior on the destination. We show how image access and controller dependencies affect a repeatable application release.

Hands-on exercises

  • Deploy a sample application with its destination-specific configuration.
  • Introduce a failed release and restore the previous version.

Day 2

We compare Helm and Kustomize for source and destination configuration. You will examine architecture, node recovery, and the components involved in upgrades and maintenance.

Hands-on exercises

  • Separate portable application values from platform-specific values.
  • Simulate a node outage and inspect workload recovery.

Day 3

You will compare how traffic moves through DNS, Services, ingress, and network policies. We discuss service mesh dependencies and placement rules for the destination's node topology.

Hands-on exercises

  • Trace an external request through the destination ingress controller.
  • Diagnose a connection blocked by a network policy or a missing endpoint.

Day 4

We explain how storage drivers, identity integrations, and metrics services support the APIs you already know. You will review secrets, RBAC, persistent storage, and autoscaling on the destination.

Hands-on exercises

  • Diagnose an unbound volume claim and verify data persistence.
  • Apply load and inspect whether the required autoscaling metrics are available.

Your MKE Kubernetes workloads, platform integrations, and maintenance responsibilities can shape the agenda. Get in touch to tailor the workshop to your Kubernetes distribution transition.

Investigate dependencies behind accepted manifests

If a PersistentVolumeClaim stays pending after a move, the instructor can help trace the StorageClass and provisioner. The team can distinguish a familiar resource name from the infrastructure needed to support it.

Greg was just awesome and very knowledgable. I also love that the course material remains available afterwards, and that we keep access to the Slack channel.

— Aaron, DevOps Engineer at RIPE NCC.

Start with the integrations you rely on

Tell us which MKE Kubernetes integrations your workloads require, what the destination provides, and who will maintain it. We will recommend a workshop around the operational differences.

Discuss your team's training