Kubernetes Roadmap: When to Start and What to Learn

Why Kubernetes comes this late

This is the most contested choice on the roadmap, so here is the case against it. Employers ask for Kubernetes a lot. InterviewStack counted it in 56% of 7,523 DevOps postings (June 2026). JobsPipe counted 69.4% (September 2026). Both are job sites with their own samples, so treat the numbers as a rough signal.

Other roadmaps disagree on when to learn it. KodeKloud puts it before CI/CD and cloud. The milanm roadmap puts it right after containers. roadmap.sh's beginner path leaves it out.

We put it late because of how it fails. A pod (one or more containers running together) can fail because of the image, the config, the network, a memory limit or a health check. If you have already handled each of those by hand, the error tells you where to look. If you have not, you may, as one Reddit commenter put it, "just end up memorizing yaml".

This choice has a cost: you will see job posts asking for Kubernetes long before you reach this page. It is still required before you apply for DevOps-titled jobs. If you are in a hurry and can already pass the tests for Docker and networking, you could start here sooner.

What to learn, in order

1. Run a local cluster. Use kind (Kubernetes inside Docker containers) or k3s (a small Kubernetes). A cluster is a group of machines that Kubernetes manages. Local ones cost nothing and are easy to delete.
2. Pods and Deployments. You rarely create pods by hand. A Deployment keeps the number of pods you asked for running, and it replaces them during an update.
3. Services. Pods come and go, and their IP addresses change. A Service gives them one stable name. This is where your networking work pays off.
4. Outside traffic. Ingress and the newer Gateway API both send outside web traffic to a Service. Both need a controller (the program that does the routing). The Kubernetes docs now recommend Gateway and have frozen Ingress, but they have no plans to remove it, so you may still meet it. Learn one, and know that the other exists. Avoid tutorials built on Ingress NGINX, whose maintenance was set to end in March 2026.
5. ConfigMaps and Secrets. These keep settings out of your image. Secrets are only base64 encoded by default, not encrypted. Keep the habits from the security step here too.
6. Requests and limits. These set how much CPU and memory a container is promised and allowed. A container that goes over its memory limit gets killed, which shows up as OOMKilled.
7. Probes. A probe is a health check that Kubernetes runs on your container. It tells Kubernetes when to send traffic and when to restart it.
8. Rolling updates and rollback. Ship a new version one pod at a time, then go back to the old one.
9. Debugging with kubectl. kubectl is the command-line tool for Kubernetes. Start with the official debugging guide and the pod lifecycle page, which explains states such as CrashLoopBackOff.
10. Basic Helm. Helm packages your Kubernetes files so they can be installed with one command. The quickstart is enough. You will use it in CI in the project below.

What to skip for now

• Kubernetes the Hard Way, which builds a cluster piece by piece. It is a good course, but it is about running clusters, not about running apps on them.
• Service meshes, operators and multi-cluster setups. They solve problems your one small app does not have.
• Argo CD beyond a quick look. The idea of deploying from Git is worth knowing, but your CI pipeline already deploys.
• Managed clusters such as EKS, until a job or a project needs one.
• The CKA, until you can pass the test on this page.

Common mistakes

• Using the latest tag on a local cluster. With latest, Kubernetes tries to pull the image from a registry. An image built only on your laptop then gives ImagePullBackOff. Use a version tag, and load the image with kind load docker-image if you use kind.
• Raising memory limits to stop every OOMKilled error. A bigger limit may only delay a memory leak. Check whether memory keeps growing before you pick a number.
• Pointing a liveness probe at the database. The liveness probe decides when to restart a container. If the database has a slow moment, every pod restarts, and a small problem becomes an outage.
• Skipping kubectl logs --previous. In a crash loop, the current container may have no useful logs yet. The reason is usually in the one that just died.
• Copying YAML you cannot explain. If you cannot say what each block does, you cannot debug it. Delete the block and see what breaks.

Your project

Move your app onto a local kind or k3s cluster. Do not rewrite it, because the app is the same one you have used since step 5. Add the database config, probes, and requests and limits. Package it with basic Helm. GitHub's runners cannot reach a cluster on your laptop. So have your CI pipeline start a throwaway kind cluster on each merge and install your chart there. Then break it each way listed in the test on this page, and add the fixes to your runbook.