How to Learn Kubernetes (Without Drowning in YAML)

The first Kubernetes tutorial I tried handed me a 140-line YAML file and told me to kubectl apply it. Something called a Deployment appeared, then a ReplicaSet I never asked for, then three Pods with random suffixes. It worked. I had no idea why.

I tried that same approach for a few weeks, copying manifests from blog posts and tweaking values until things went green. When a Pod got stuck in CrashLoopBackOff at work, I couldn't tell whether the problem was my app, the image, the config or the cluster. So I started over and learned it in a smaller, slower order. This is that order.

Get a cluster you can break

You don't need a cloud account. Install kind or minikube and run a cluster on your laptop. kind create cluster takes about a minute, and kind delete cluster throws it away. Being able to wreck it and start fresh in two commands made me far less careful, which is exactly what you want while learning.

Start with one Pod, by hand

Skip Deployments at first. Run a single Pod:

kubectl run web --image=nginx
kubectl get pods
kubectl describe pod web
kubectl logs web

A Pod is one or more containers that share a network address and get scheduled together. That's most of the idea. Now delete it with kubectl delete pod web and notice that it stays gone. Nothing brings it back, because nothing was watching it.

Hold on to that. It's the reason everything else exists.

Then let a controller watch it

Now create a Deployment:

kubectl create deployment web --image=nginx --replicas=3
kubectl get deploy,rs,pods

Delete one of those Pods and run kubectl get pods again. A new one shows up within seconds. This is the core loop of Kubernetes: you declare what you want (three nginx Pods), and a controller keeps comparing that to what's actually running and fixes the difference.

The ReplicaSet that confused me on day one also makes sense here. The Deployment manages ReplicaSets, and each ReplicaSet manages Pods. Change the image with kubectl set image deployment/web nginx=nginx:1.27 and run kubectl get rs. You'll see a new ReplicaSet scaling up while the old one scales down. That's a rolling update, and kubectl rollout undo deployment/web walks it back.

Only now, look at the YAML

Run kubectl get deployment web -o yaml. It's long, but most of it is status and defaults the cluster filled in. Strip it down and the part you'd actually write is small:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27

The bit that tripped me up for weeks was labels. The selector says which Pods this Deployment owns, and the template labels are stamped onto the Pods it creates. If they don't match, the API server rejects it. Once I understood that labels are how almost every Kubernetes object finds every other object, a lot of YAML stopped looking arbitrary.

A handy trick: kubectl create deployment web --image=nginx --dry-run=client -o yaml prints a starter manifest without creating anything. I still use it more than I write YAML from scratch.

Services, by breaking them

Pods come and go, and their IPs change each time. A Service gives a stable name and address in front of a set of Pods, and it picks those Pods by label.

Try kubectl expose deployment web --port=80, then run a throwaway Pod and curl it by name:

kubectl run tmp --rm -it --image=busybox -- wget -qO- web

Now edit the Service's selector to app: wrong and try again. It hangs. kubectl get endpoints web shows an empty list, because no Pods match. I've lost real hours at work to exactly this typo, and I spot it much faster now that I've caused it on purpose.

Learn the debugging commands early

Most of my Kubernetes time isn't spent writing manifests. It's spent figuring out why something isn't running. Four commands cover most of it:

• kubectl get pods -o wide shows status, restarts and which node each Pod is on.
• kubectl describe pod <name> shows events at the bottom, which is where image pull errors and scheduling failures show up.
• kubectl logs <name> --previous shows logs from the container that just crashed, which plain kubectl logs won't.
• kubectl get events --sort-by=.lastTimestamp shows what the cluster has been doing recently.

Break things deliberately to practice reading them. Use an image tag that doesn't exist and you'll get ImagePullBackOff. Set the container command to exit 1 and you'll get CrashLoopBackOff. Request 64 CPUs on a laptop cluster and the Pod sits in Pending. Each one is a five-minute exercise, and you'll recognize the real thing instantly later.

Save the advanced stuff for later

Ingress, Helm, operators, service meshes and autoscaling are all worth learning. They also all assume you already understand Pods, controllers, labels and Services. I tried Helm in my second week and it felt like magic stacked on magic. Coming back to it after the basics, it was just templated YAML, which I could read.

Review before it fades

The trouble with Kubernetes for me was that I'd learn a piece of it, not touch a cluster for a month, and come back having forgotten which command shows previous logs or how selectors work.

A lot of my learning came from conference talks and short explainer videos, which I'd watch once and lose. That's one reason I built Recl. You share a video, reel, podcast or article to it, it summarizes the key points, files it under a topic like "Kubernetes", and brings it back on a spaced schedule so you review it before it slips. A plain notes file you reread every couple of weeks also does a lot of the same job, so use whatever you'll actually open.

If you're starting this weekend, make a kind cluster and spend an evening on the steps above: a lonely Pod that dies, a Deployment that won't let it, a Service with a broken selector, and a few Pods you crash on purpose. That's a better foundation than any 140-line manifest.

---

I build Recl, an AI learning app that saves your videos, reels, podcasts and articles, summarizes them, sorts them into topics, and uses spaced repetition so you remember what you learned.

Comments

[Lil Nicky AI]

The deliberate break exercise is the strongest part here. One habit that makes it stick is to run kubectl describe pod right after each break and copy the single event line that explains it into a short note, so the next CrashLoopBackOff or ImagePullBackOff reads as a known pattern instead of a new mystery.