From OpenShift to another Kubernetes distribution

Private, instructor-led training for engineers who deploy on OpenShift and need to operate applications on another Kubernetes distribution.

Your team already uses Kubernetes through OpenShift. A new distribution brings changes in routing, security, image workflows, and team responsibilities.

LearnKube helps your team map these dependencies to the destination through a sample application. Your engineers will review its requirements, adapt its release configuration, and practice diagnosis.

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.

Keep application behavior clear as the platform changes

  • Prepare the application by separating portable resources from platform-specific dependencies, so the team knows what needs adaptation.
  • Preserve access and data by reviewing routing, permissions, and storage behavior, so the destination meets the application's requirements.
  • Diagnose compatibility failures by inspecting API support, admission errors, and controller events, so engineers identify missing platform capabilities.
  • Define platform ownership by documenting component maintenance and escalation paths, so the team understands its new operating responsibilities.

Kubernetes stays, while platform assumptions change

OpenShift provides Kubernetes with integrated platform capabilities. Applications can depend on Routes, Security Context Constraints, image workflows, and operators as well as standard workload resources. Another distribution can retain familiar Kubernetes APIs while providing different integrations. Engineers need to identify those dependencies before deciding what to retain or replace.

I want teams to explain where TLS terminates and which controls admit their Pods before they choose replacement resources. A successful deployment is not enough evidence that the destination preserves the application's routing and security requirements.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Expose an OpenShift RouteDestination routing and TLSTrace the replacement route
Apply workload security rulesAdmission and runtime controlsInvestigate a rejected Pod
Build and reference imagesDestination image workflowDeploy a versioned image
Use platform-managed storageStorage classes and driversVerify a volume dependency

Case Study: Lockheed Martin

A Lockheed Martin team struggled with a restricted OpenShift instance and wanted to build, maintain, and control its own Kubernetes platform. It had an allocated AWS Gov account, while its application developers had little platform infrastructure experience.

LearnKube delivered private Kubernetes training as the team prepared for those responsibilities. One participant described the value of the practical work:

The labs really helped me make sense of what was going behind the scenes of Kubernetes.

— Nicholas, SW dev, Lockheed Martin.

A recommended four-day workshop for the destination platform

This proposed agenda builds on your team's OpenShift experience. We spend less time on container basics to focus on distribution-specific dependencies and what it means to own the platform.

Day 1

You will review Pods, Deployments, Services, and probes alongside application dependencies on OpenShift features. We explain how image delivery and rollout behavior affect the destination release.

Hands-on exercises

  • Inventory a sample application's portable resources and platform dependencies.
  • Deploy its adapted workload and rehearse a failed release.

Day 2

We compare Helm and Kustomize for platform-specific configuration. You will see how controllers, the control plane, and nodes relate to the components your team will manage.

Hands-on exercises

  • Create configuration variants for the source and destination environments.
  • Simulate a node failure and inspect recovery and controller events.

Day 3

You will compare OpenShift Routes with routing and TLS configuration on the destination. We explain Services, DNS, network policies, service mesh dependencies, and workload placement.

Hands-on exercises

  • Trace a request through the destination's ingress controller to the application.
  • Diagnose a broken route or blocked dependency connection.

Day 4

We review storage classes, secrets, authentication, and RBAC. You will compare admission controls with runtime security and discuss how autoscaling depends on available metrics.

Hands-on exercises

  • Verify a storage dependency and recover data after Pod replacement.
  • Generate application load and inspect the destination's autoscaling behavior.

Your OpenShift dependencies, destination integrations, and platform ownership can shape the agenda. Get in touch to tailor the workshop to your move from OpenShift to another Kubernetes distribution.

Review the behavior behind familiar resources

When an engineer replaces a Route with an ingress manifest, the instructor can ask where TLS terminates and which controller handles traffic. The team can trace the request and find the configuration that preserves the required behavior.

Bring your platform dependencies

Tell us which OpenShift capabilities your applications use, what the destination provides, and who will own its operation. We will recommend exercises around those dependencies and responsibilities.

Discuss your team's training