I've been working in IT for about 10 years and recently started learning containers with Docker Desktop on my laptop. I'm only a couple of weeks in, so I'm still looking up Git commands and troubleshooting basic issues, but I'm enjoying the process and may eventually explore it as a career direction.
My next goal is to learn Kubernetes. Should I begin with vendor-neutral Kubernetes concepts, or start directly with a managed service such as Amazon EKS, Microsoft AKS, or Google GKE? How much of the knowledge transfers between providers, and what parts are specific to each cloud?
I'd also appreciate suggestions for what else to study alongside Kubernetes. I'm especially interested in learning efficiently without skipping the fundamentals.
3 Answers
A practical route is to deploy a simple workload on a managed service such as EKS or AKS, learn how the application is supposed to run, and then take the cluster apart conceptually. After that, work through a guide that builds Kubernetes components manually so you can see the underlying plumbing.
For choosing between EKS and AKS, use the provider that matches your current workplace, the tools you already know, or the kinds of jobs available in your area. The Kubernetes workload concepts will carry over, while the provider-specific setup will not. In most real jobs, managed control planes are preferable unless you have a strong reason to operate that infrastructure yourself.
I’d start with the Kubernetes fundamentals, then choose one cloud provider. Learn Pods, Deployments, Services, ConfigMaps and Secrets, resource requests and limits, health probes, storage, networking, scheduling, RBAC, and troubleshooting. You can run a small cluster locally with kind or Minikube and intentionally break things to see how they behave.
The core Kubernetes concepts transfer fairly well, but not perfectly. Cloud providers add their own identity and access controls, load balancers, networking, DNS, storage, node management, logging, and other integrations. Those pieces are much easier to understand once you know which responsibilities belong to Kubernetes itself.
Since you’re still new to containers, spend some time on images, registries, volumes, networking, namespaces, cgroups, and what actually happens when a container runs. Kubernetes becomes much less mysterious when the container layer is familiar. Git, Linux, networking, Terraform, CI/CD, and observability are also excellent subjects to learn alongside it. And looking up Git commands is completely normal, even for experienced engineers.
That makes sense. I’ll spend more time on the container fundamentals first, then build a small local cluster before choosing a cloud provider.
Don’t treat your age or the fact that you still look things up as evidence that you’re behind. Ten years of IT experience gives you useful context, and learning containers adds another layer rather than forcing you to start over.
Focus on building small, complete projects: containerize an application, store the image in a registry, deploy it, expose it through a service, add configuration and secrets, set resource limits and health checks, and monitor what happens. Troubleshooting those ordinary pieces will teach you more than rushing through a long list of tools. Once that feels comfortable, add one cloud platform, infrastructure as code, a CI/CD pipeline, and observability.
Would you choose EKS or AKS based mainly on local job demand? Also, is building Kubernetes manually something a beginner should tackle early, or should I wait until I know the basics?