Your engineers need to explain releases, traffic, storage, and access wherever Kubernetes runs. Those skills must remain useful when the distribution or infrastructure changes.
Choose LearnKube for vendor-neutral instruction. We teach the Kubernetes mechanisms behind workload behavior, so engineers can apply the understanding to Canonical's distributions, OpenShift, managed clusters, and on-prem environments.
Your platform sets the context. Kubernetes provides the technical foundation. We select the depth for the application and platform decisions your engineers own.
Hands-on learning and the skills engineers take back to work.
Canonical Kubernetes Explorer guides participants through Charmed Kubernetes and MicroK8s. LearnKube instead makes Kubernetes itself the foundation of the course.
You learn why readiness changes traffic, how controllers react to desired state, what persists after a Pod replacement, and how scheduling constrains a workload. Those mechanisms remain relevant across Kubernetes distributions.
That gives engineers understanding they can use on Canonical today and another platform later. We also explain where networking, storage, identity, or infrastructure integrations require environment-specific investigation.
Explorer's published objective is distribution enablement and operation. Our private plan can instead specify the application decisions developers own and the deeper mechanisms platform engineers need to understand.
The LearnKube modules connect probes and releases, resource templates, state, application metrics, scheduling, and internal and external traffic. We can select different depth for each role while retaining a common foundation.
A developer can explain the readiness and configuration of a workload. A platform engineer can investigate the network or access boundary around it. The learning plan helps both groups identify the next observation and the required handoff.
Tell us which platforms the group uses and what each role can change. We can propose a three-, four-, or five-day course, onsite or live remotely, with selected technical emphasis.
The course can use your current platform as context and keep the explanations vendor-neutral. We can shorten familiar topics and spend more time on difficult mechanisms.
Our course includes individual cloud workstations for practical work. Participants retain material and slide decks, with private Slack access for later questions.
These mechanisms are the course focus. We select the learning from your team's existing workload responsibilities.
A proposed exercise follows a chart value into a Deployment, readiness condition, and Service endpoint. Participants first diagnose a workload that fails readiness, then compare it with ready endpoints behind an access restriction.
The application and platform viewpoints require different observations. Engineers explain which configuration they own, which evidence they need from the other group, and how to describe the next action without guessing at the failing layer.
LearnKube delivered a private course for Cray/HPE engineers. The instruction covered Kubernetes architecture and networking alongside containers, deployments, security, and the mechanisms around workload operation.
Jonathan, a software developer in the course, described what he liked most:
Great coverage of much of the major infrastructure of Kubernetes.
— Jonathan, Software Developer, Cray/HPE.
The buyer also reported a positive response to the instructors after delivery. That is the learning emphasis we bring to your team: explain the Kubernetes infrastructure so engineers can reason about the workloads above it.
Yes. Share the platform, workload patterns, and access boundaries. We can choose representative exercises and explain the Kubernetes mechanisms that relate to your operating decisions.
Yes. We can agree on shared foundations and role-specific emphasis, including separate cohorts. Tell us what each group needs to deploy, maintain, or investigate.
Yes. Readiness, controllers, Services, state, and scheduling remain Kubernetes mechanisms. We can use your distribution as context and explain which observations depend on its networking, storage, identity, or infrastructure integrations.
Tell us which environments the team operates and where application and platform responsibilities meet. We can propose instruction that connects the workload behavior to the decisions each group needs to make.