We offer private, instructor-led training for platform engineers who release applications through EC2 machine images and Auto Scaling groups and need Kubernetes deployment skills.
Your team knows instance replacement and machine configuration. Application releases and infrastructure capacity become separate decisions, with their own images, health checks, scaling behavior, and recovery paths.
LearnKube connects those responsibilities through a representative service. Your engineers will package the application, control its release, and distinguish Pod recovery from the availability of suitable nodes.
Hands-on learning and the skills engineers take back to work.
Preview: course-wide figures are not yet available.
An AMI supplies the software and block-device configuration used to launch an EC2 instance. A Kubernetes Deployment rollout changes the application's Pod template and replaces replicas. The application image, configuration, and persistent data therefore need explicit boundaries. Pod replica counts also differ from the node capacity available to run those replicas.
I separate the application release from the machine that supplies its capacity. A new application version does not automatically need new nodes, and more Pods do not automatically provide more node resources.
— Daniele Polencic, LearnKube founder and Kubernetes instructor
| Current task or requirement | New concept or decision | Practice |
|---|---|---|
| Build an application AMI | Container image and configuration | Package a repeatable release |
| Replace application instances | Deployments and rollout controls | Rehearse an unready update |
| Add execution capacity | Pod replicas and nodes | Inspect a Pending replica |
| Restore application state | Storage outside the image | Recover data after replacement |
Digital Surgery's platform team began moving away from EC2 deployments based on AMIs and Auto Scaling groups toward Kubernetes. LearnKube delivered a private three-day course covering Kubernetes foundations and practical deployment concepts.
After the course, Hansel shared the team's feedback:
I’ve debriefed the team on the training. They were very complimentary on your as a trainer and have certainly learned a lot. Mostly they have a lot of questions and new areas of inquiry. They had some constructive feedback on the structure as well.
— Hansel, Digital Surgery.
A later update from Andrew said that the stack ran mostly on Kubernetes. The team's next questions concerned tooling, deployment across teams, and managed access.
We recommend this four-day agenda for your team. It extends the learning time beyond the historical three-day course and focuses on the boundaries between releases, workloads, and infrastructure.
Day 1
We compare machine images with container images, then connect the application to Pods, Deployments, and Services. You will examine health probes, rolling updates, and rollback without treating every release as node replacement.
Hands-on exercises
Day 2
You will use Helm and compare Kustomize for reusable deployment resources. We explain the control plane, controllers, and kubelet through the difference between application recovery and infrastructure recovery.
Hands-on exercises
Day 3
We connect familiar load-balancer expectations to Services, ingress, DNS, and the chosen AWS integrations. You will examine network policies, service mesh use cases, resource requests, and placement constraints.
Hands-on exercises
Day 4
You will distinguish application configuration and persistent data from image contents. We cover HPA metrics, node-capacity responsibilities, secrets, authentication, RBAC, and access to external AWS services.
Hands-on exercises
Your AMI release process, AWS integrations, and platform responsibilities can shape the agenda. Get in touch to tailor the workshop to your EC2-to-Kubernetes application transition.
When an engineer proposes new nodes for an application update, the instructor can separate the image change from the capacity requirement. Your team can then rehearse a workload rollout and observe which infrastructure remains in place.
Tell us how you build AMIs and replace instances, what your applications need to retain, and who will operate Kubernetes. We will recommend exercises for those changes.