From self-managed to managed Kubernetes: training for platform teams

We offer private, instructor-led training for platform engineers who administer Kubernetes and plan to adopt a managed Kubernetes service.

Your team already understands workload resources and cluster components. The responsibility boundary changes, including node maintenance, provider integrations, upgrades, and the evidence needed during an incident.

LearnKube connects your operating procedures to the selected destination through a representative workload. Your engineers will examine maintenance, recovery, and access decisions against the service'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.

Make the new operating boundary explicit

  • Deploy workloads on the destination by reviewing controller, network, storage, and identity dependencies, so familiar manifests use the integrations they actually require.
  • Preserve workload availability by examining node maintenance, placement, and disruption controls, so planned infrastructure changes have an understood application effect.
  • Diagnose incidents across boundaries by collecting workload, node, and provider evidence, so the team can distinguish its own corrective actions from provider escalation.
  • Assign continuing responsibilities by documenting ownership of nodes, upgrades, credentials, and data recovery, so a managed control plane does not hide unassigned work.

Managed control planes still need an operating model

On a self-managed cluster, the team operates the control plane as well as the surrounding infrastructure. A managed service can take over control-plane operations, node management, or both. The exact boundary depends on the product and configuration. Workload health, permissions, and storage requirements still need explicit owners during the move.

I want the team to describe what happens when a node is replaced. A managed control plane does not decide the application's disruption tolerance or make its data recoverable without an appropriate storage design.

— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirementNew concept or decisionPractice
Operate control-plane componentsProvider responsibility boundaryMap an incident handoff
Maintain worker nodesNode draining and disruption controlsRehearse workload movement
Provision application storageDestination drivers and classesDiagnose a volume dependency
Grant workload accessCloud identity and RBACTrace an authorization failure

How we approach this transition

We propose a workshop that compares your current operating procedures with the selected managed service. The team identifies what the provider operates, what its node option covers, and which duties remain internal.

The exercises use a representative application to examine maintenance and recovery. We keep the recommendation provider-neutral until the destination is known, then adapt identity, networking, and storage examples to its documented capabilities.

A recommended four-day workshop for platform owners

This proposed agenda shortens familiar fundamentals. It focuses on how existing Kubernetes knowledge applies when provider integrations and operating boundaries change.

Day 1

We review the workload's dependencies and compare them with the destination's capabilities. You will connect probes, rolling updates, and rollback to the application's availability requirements.

Hands-on exercises

  • Deploy the representative workload and identify integration-dependent resources.
  • Introduce a failed release and distinguish application rollback from infrastructure recovery.

Day 2

You will use Helm and compare Kustomize for destination-specific configuration. We review control-plane and node responsibilities, including the visibility and access that remain available to your team.

Hands-on exercises

  • Adapt a release to destination configuration without hiding required integrations.
  • Rehearse a node drain and inspect how workload placement and disruption controls affect progress.

Day 3

We trace DNS, Services, ingress, and provider load-balancer behavior. You will discuss network policies, service mesh use cases, affinity, taints, and placement across the selected node capacity.

Hands-on exercises

  • Diagnose a service endpoint that exists but cannot receive external requests.
  • Inspect why replacement Pods cannot fit the available node pools.

Day 4

You will examine storage classes, secrets, and data-recovery responsibilities. We compare workload and node scaling, then separate Kubernetes RBAC from provider identity and permissions.

Hands-on exercises

  • Inspect a storage provisioning failure and identify the responsible integration.
  • Diagnose denied workload access and identify whether the correction belongs in Kubernetes or the provider configuration.

Your managed-service choice, node options, and operational responsibilities can shape the agenda. Get in touch to tailor the workshop to your managed-Kubernetes transition.

Locate the responsibility that did not move

When an engineer expects managed nodes to guarantee application availability, the instructor can rehearse a drain with the workload's current replicas and disruption settings. Your team can see which decisions still belong to the application and platform owners.

Very well prepared trainers! Great and well documented exercises and labs.

— Michael, DevOps Engineer at BMW.

Bring the current procedures and the destination contract

Tell us how you operate Kubernetes today, which managed service and node options you plan to use, and who will retain each responsibility. We will recommend exercises for the operating model that changes.

Discuss your team's training