I've been working in IT for about 10 years and recently became very interested in containers. I'm only about two weeks into learning, so I still look up Git commands and run into plenty of basic issues, but I'm enjoying building and managing containers with Docker Desktop on my laptop and learning through troubleshooting. I'm not sure yet whether this will become a career direction, but I'd like to keep developing the skill.
My next goal is Kubernetes, and I'm unsure whether to start with vendor-neutral Kubernetes material or move directly to a cloud platform such as AWS, Azure, or Google Cloud. I can see the benefit of learning a specific provider, but I'm wondering how much of the Kubernetes knowledge transfers between platforms and whether a neutral foundation would be more useful long term.
What learning path would you recommend? Should I start locally, use a managed Kubernetes service, or combine both? I'd also appreciate suggestions for related topics I should study, such as Linux, networking, infrastructure as code, CI/CD, or observability.
3 Answers
I’d build a vendor-neutral foundation first, then apply it to one cloud. Learn Pods, Deployments, Services, ConfigMaps and Secrets, resource requests and limits, probes, storage, networking, scheduling, RBAC, and troubleshooting. You can run a local cluster with kind or Minikube and deliberately break things to learn how recovery works.
Since you’re only two weeks into containers, don’t rush past the fundamentals. Spend time with images, registries, volumes, container networking, namespaces, cgroups, and what actually happens when a container starts. Kubernetes becomes much easier to understand once containers aren’t a black box.
After that, Linux, networking, Git, one cloud platform, Terraform, CI/CD, and observability are all valuable additions. Also, looking up Git commands is completely normal, even for experienced engineers. Ten years in IT is not starting from scratch at 40—you’re building on experience you already have.
A practical route is to start with a managed service such as EKS, AKS, or GKE and deploy a simple workload so you can see how Kubernetes is used in real life. After that, try a hands-on guide that builds Kubernetes more manually so you understand the underlying plumbing. Once you’ve seen both sides, you’ll probably appreciate why most teams use managed control planes instead of operating that infrastructure themselves.
Choose the cloud provider you’re most likely to encounter at work or in job listings around you. The core Kubernetes skills transfer well: deploying an application, reading events, diagnosing image-pull failures, checking health probes, and rolling back a bad release. The parts that don’t transfer exactly are the provider integrations, including IAM, networking, load balancers, DNS, storage, logging, and node provisioning. Learn one cloud deeply enough to use it, but don’t spend too long trying to keep everything purely vendor-neutral.
Would you choose EKS or AKS based on anything specific? Also, is the manual Kubernetes guide something I should tackle early, or would it be too much for a beginner?