We offer private, instructor-led training for operating and engineering groups that need a common understanding of a Kubernetes platform already in use.
The platform can be established while knowledge remains unevenly distributed. More colleagues need to interpret its behavior consistently, without assuming that everyone takes over specialist administration.
LearnKube follows a familiar service through deployment, replacement, and access. Participants compare their explanations and identify the operational questions each role must be able to answer.
Hands-on learning and the skills engineers take back to work.
Preview: course-wide figures are not yet available.
Operating groups can encounter the same service through different tools. A controller maintains desired workload state, while a Service provides access to selected backends. Recognizing those responsibilities gives colleagues a common basis for questions about replacement or reachability. The workshop connects each explanation to the same observable resources and the group's actual responsibilities.
I ask colleagues to explain who creates a replacement and how clients find it. Agreement on those two questions is more useful than everyone memorizing the same command while holding different pictures of the platform.
— Daniele Polencic, LearnKube founder and Kubernetes instructor
| Decision to align | Common basis | Shared exercise |
|---|---|---|
| Explain a replacement | Controller and desired state | Compare lifecycle explanations |
| Interpret service access | Selectors and endpoints | Trace the same connection |
| Gather operating evidence | Status, events, and logs | Build a common observation |
| Ask the right owner | Resource and responsibility scope | Review a support request |
Mehiläinen already ran GKE in production and wanted to expand Kubernetes knowledge inside the organization. Most of the intended learners worked in operations.
LearnKube delivered private training for that learning need. The starting point was broader understanding of an existing platform, with the buyer also interested in applying the learning while it remained fresh.
This proposed agenda uses a familiar workload as a common reference. It connects foundational knowledge to the questions that wider operating groups need to discuss with specialists.
Day 1
We explain containers, Pods, Deployments, Services, and probes using one service. Participants identify familiar behavior and compare what the Kubernetes resources add to their explanation.
Hands-on exercises
Day 2
We use Helm and compare Kustomize to connect a release description to the cluster architecture. The group distinguishes application configuration from controller and node responsibilities.
Hands-on exercises
Day 3
We connect DNS, ingress, Services, network policy, and placement to the reference service. Participants discuss service mesh roles where relevant rather than assume every environment has the same components.
Hands-on exercises
Day 4
We examine storage, secrets, autoscaling metrics, and permissions. Participants relate the controls to their operating duties and review the service together using common evidence.
Hands-on exercises
Your operating groups, shared examples, and specialist boundaries can shape the agenda. Get in touch to tailor the workshop to how your teams work together.
When colleagues use different explanations for the same replacement Pod, the instructor can follow the controller and Service separately. The group can then connect its existing knowledge to one technical model.
The customisation of the course was perfect, the guys managed to learn the theory, its practical use and limitations.
— Mike, Principal SRE Engineer at Bank of England.
Tell us which groups use Kubernetes, which behaviors need a common explanation, and which responsibilities remain with specialists. We will recommend a shared course focus and practical examples.