From existing orchestration to Kubernetes-native workflows

Private, instructor-led training for platform and workflow engineers who need to move engineering workflows to a different Kubernetes-native execution model.

Your team already knows the current pipeline. The new model must preserve dependencies, retries, data access, and completion behavior across different workload lifecycles.

LearnKube connects these needs to Kubernetes through a sample workflow. Your engineers will practice task execution and recovery, then identify which responsibilities need a workflow controller.

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 workflow behavior through the change

Run workflow tasks by configuring Jobs and completion conditions, so each task has an explicit execution lifecycle.
Preserve data and dependencies by defining artifact storage and retry behavior, so replacement Pods can resume useful work without corrupting outputs.
Diagnose stalled execution by inspecting Job status, Pod events, and storage access, so engineers distinguish scheduler problems from task failures.
Define controller responsibilities by documenting dependency and recovery requirements, so platform and workflow teams agree on the execution model.

A Job runs work, while a workflow coordinates it

An existing workflow system can coordinate dependencies, retries, and artifacts across several tasks. Kubernetes Jobs manage task execution toward completion, while CronJobs create Jobs on a schedule. Neither resource alone provides a complete dependency graph or artifact management system. Engineers must identify which responsibilities remain with a workflow controller.

A completed Job tells me its completion condition was met, not that the task ran exactly once. I want retries to protect existing outputs, especially when a task writes to an external system.
— Daniele Polencic, LearnKube founder and Kubernetes instructor

Current task or requirement	New concept or decision	Practice
Run a pipeline task	Job completion and backoff	Inspect a failed task
Order dependent tasks	Workflow dependency graph	Map a dependency graph
Transfer task outputs	Artifact and volume lifecycles	Recover a persisted output
Schedule recurring execution	CronJob concurrency policy	Observe overlapping runs

Your team is not alone in workflow migration

Ciena's engineering workflow initiative includes analysis of existing Kubeflow workflows and evaluation of Kubernetes Jobs, CronJobs, Argo Workflows, and Tekton. The work covers retries, lifecycle, data transfer, artifacts, and tests of functional equivalence.

Engineers in this situation need to compare execution behavior before choosing a replacement. We recommend a four-day workshop focused on task lifecycle, data persistence, and the boundary between Kubernetes resources and workflow controllers.

A recommended four-day workshop for workflow teams

This proposed agenda adapts our core Kubernetes course for workflow execution. We spend less time on deployment strategies and service mesh topics to focus on Jobs, CronJobs, and controller requirements.

Day 1

Task execution and completion

We show how containers and Pods relate to Jobs, retries, and completion conditions. You will compare single-run tasks with long-lived services and scheduled work.

Hands-on exercises

Run a task as a Job and inspect a failed attempt.
Configure a CronJob and observe its concurrency policy during overlapping schedules.

Day 2

Repeatable workflows and cluster behavior

You will use Helm or Kustomize to configure tasks. We explain controllers, nodes, and reconciliation, then identify what is needed for tasks that depend on each other.

Hands-on exercises

Template a task with environment-specific inputs.
Simulate a node failure and inspect Job recovery and repeated execution.

Day 3

Data paths and workload placement

We explain DNS, network policies, and access to artifact services. You will discuss ingress for workflow interfaces and placement rules for tasks that need specific resources.

Hands-on exercises

Trace a task's connection to an artifact endpoint.
Diagnose a task that cannot reach its required data service.

Day 4

Outputs, credentials, and resource demand

You will compare persistent volumes with external artifact storage, then review secrets and RBAC. We explain the difference between service autoscaling, task parallelism, and concurrency controls.

Hands-on exercises

Preserve an output across Pod replacement and rerun the task safely.
Compare parallel task execution with the cluster's available capacity.

Your workflow graphs, artifact systems, and recovery responsibilities can shape the agenda. Get in touch to tailor the workshop to your Kubernetes-native workflow transition.

Examine what a retry actually repeats

When an engineer assumes that a successful Job means a task ran exactly once, the instructor can demonstrate repeated execution after failure. Your team can discuss idempotent writes and the evidence needed to accept an output.

He did a great job helping us understand and probing our knowledge with good questions and discussions.
— Matthew, Senior Technical Expert at Walmart.

Start with one workflow and its outputs

Tell us how your workflows run, which execution model you want to evaluate, and who owns task recovery and data integrity. We will recommend exercises around those requirements.

Discuss your team's training