From Mesos and DC/OS to Kubernetes: training for infrastructure teams

We offer private, instructor-led training for infrastructure engineers who operate applications through Mesos or DC/OS and need to move suitable workloads to Kubernetes.

Your team understands resource allocation and its current frameworks. Framework behavior does not map to one Kubernetes resource, especially for health checks, discovery, and task recovery.

LearnKube uses a representative service and bounded task to connect those behaviors to Kubernetes. Your engineers will practice controller selection, deployment, and failure diagnosis.

Discuss your team's training

Learning in practice

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.

Preserve the behavior behind the framework

Deploy suitable workloads by selecting controllers for long-lived services and bounded tasks, so Kubernetes manages each workload according to its execution model.
Preserve placement and recovery by translating resource requirements and examining retry behavior, so replacement work can use appropriate capacity without losing required state.
Diagnose stalled tasks by inspecting scheduling events, workload status, and dependency access, so engineers distinguish insufficient capacity from application failure.
Assign integration ownership by documenting discovery, storage, and framework-specific responsibilities, so teams know which behavior requires additional platform components.

Compare framework behavior before translating definitions

Mesos framework schedulers decide which resource offers to accept and which tasks to run. Kubernetes workload controllers manage Pods according to declared workload types. The move therefore depends on the current framework's behavior, including its health checks, discovery, and recovery rules. A DC/OS application definition is not a universal Deployment template.

I start with what the framework guarantees when a task stops or a machine disappears. Until those rules are explicit, a similar-looking manifest can hide a different retry policy, placement decision, or data lifecycle.
— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirement	New concept or decision	Practice
Keep a service available	Deployments and probes	Replace a failed replica
Complete a bounded task	Jobs and retry behavior	Inspect a failed attempt
Allocate suitable resources	Requests and placement rules	Diagnose a Pending Pod
Discover a task endpoint	Services and cluster DNS	Resolve a stale address

How we approach this transition

We propose a workshop that starts with the behavior of your current framework. If Marathon manages your applications, its service definitions can provide the comparison. Other frameworks need their own review.

Your team traces a service and a bounded task through deployment, failure, and recovery. The proposed exercises identify which behavior comes from Kubernetes and which remains an application or integration responsibility.

A recommended four-day workshop for framework operators

This proposed agenda builds on your resource-management experience. It concentrates on the controller and integration decisions behind a move to Kubernetes.

Day 1

Workload types and release behavior

We compare the source framework's execution model with Pods, Deployments, and Jobs. You will connect probes and rollout controls to the availability requirements of a long-lived service.

Hands-on exercises

Deploy a service and a bounded task with appropriate controllers.
Introduce a failed release and compare rollout recovery with a task retry.

Day 2

Templates, reconciliation, and failures

You will use Helm and compare Kustomize for repeatable workload configuration. We explain the scheduler, controllers, control plane, and kubelet to separate their responsibilities during failure.

Hands-on exercises

Package the service's workload and discovery resources as a release.
Simulate a node failure and track the replacement Pods and task status.

Day 3

Discovery, traffic, and placement

We compare the source platform's discovery behavior with Services and DNS. You will explore ingress, network policies, service mesh use cases, resource requests, affinity, and taints.

Hands-on exercises

Diagnose a Service whose selector does not match its intended Pods.
Inspect a placement failure caused by resource or node constraints.

Day 4

Task state, scaling, and access

You will examine configuration, secrets, and persistent storage for services and tasks. We cover autoscaling metrics and RBAC, with attention to the permissions needed by operators and applications.

Hands-on exercises

Recover a bounded task using durable input and output storage.
Observe how workload metrics affect replicas and available cluster capacity.

Your Mesos frameworks, discovery integrations, and recovery responsibilities can shape the agenda. Get in touch to tailor the workshop to your Mesos-or-DC/OS transition.

Examine the guarantee behind a familiar task definition

When an engineer maps every task to a Deployment, the instructor can ask what successful completion means. A bounded-task exercise makes the difference between continuous availability and completion visible.

Sal started out by asking what we wanted to get out of the course, and followed up with our requests.
— Dave, SW Technical Lead at Bluestaq.

Bring the framework and its operating rules

Tell us which frameworks manage your workloads, which behaviors the destination must preserve, and who owns the surrounding integrations. We will recommend a course focus for those decisions.

Discuss your team's training