I have about five years of experience across DevOps, cloud, and backend engineering. I've worked with Kubernetes, EKS, AKS, Helm, CI/CD, Docker, Terraform, Argo CD, AWS, Azure, and some Java and Spring Boot.
My experience is fairly broad but uneven. I'm comfortable deploying applications, writing manifests, using kubectl, building pipelines, and working with cloud networking and IAM. However, I'm less confident with Kubernetes internals, Linux networking, storage and CSI, the control plane, scheduling, CRDs and operators, upgrades, observability, and deep production troubleshooting.
I'm considering taking one comprehensive Kubernetes course first to build a solid mental map, then spending several months going deeper through hands-on labs, troubleshooting exercises, Linux and networking fundamentals, and production-style projects.
For people who became genuinely strong in Kubernetes or platform engineering, does that sequence make sense? What would you change, and which activities made the biggest difference in developing real depth? I'm mainly looking for advice on the learning sequence rather than a huge list of tools.
2 Answers
Since you’re already working as a senior DevOps engineer, you probably don’t need to start over or chase every internal detail at once. Use the course to organize the gaps in your mental model, then choose a few areas that directly improve reliability for the teams and systems you support.
A strong approach would be to build or operate a small cluster, perform upgrades, break networking and scheduling, investigate failed deployments, and document what happened. Pair that with focused study of Linux internals and Kubernetes architecture. Real production-style failure analysis will expose the shallow areas much faster than collecting more tool knowledge.
That sequence is reasonable, but make the course only the starting point. The biggest jump in understanding usually comes from learning the Linux mechanisms underneath Kubernetes.
Spend time with cgroups, namespaces, processes, mounts, and networking. Recreate simple container isolation from the command line so you can see what the runtime is doing instead of treating containers as magic. Then trace how pod interfaces connect to host interfaces and how traffic moves through the cluster.
Do the same with storage: read the CSI and CNI documentation, inspect the components running in those pods, and experiment with mounts and mount points on Linux. Building small failure scenarios and troubleshooting them will be more valuable than passively completing several courses.
This is exactly the kind of actionable direction I was looking for. I’ll make the Linux, networking, and storage experiments part of the plan rather than treating them as optional background.
That’s a helpful distinction. I’m already employed, so the goal is to make my existing experience more rigorous and dependable rather than simply add another certification or tool to my resume.