Kubernetes Tutorial for Beginners (2026 Practical Guide)

Kubernetes basics in plain English: pods, deployments, services, ingress. Spin up a real cluster on your laptop with kind, deploy nginx, scale, roll out, and clean up — all in under 30 minutes.

Published: 2026-06-04

Kubernetes (usually shortened to K8s) is an orchestrator for containerized applications. Containers are great at running one thing in isolation. Kubernetes is great at running thousands of containers across many machines, restarting them when they crash, scaling them up under load, and replacing dead nodes without dropping traffic.

You write a YAML file that says "I want three copies of this container running." Kubernetes figures out which machines to run them on, watches them, and brings them back up if any one dies. You change the YAML to say "now I want five copies." Kubernetes adds the extra two. You change the container image to a newer version. Kubernetes does a rolling deploy, swapping pods one at a time so your service stays online.

It exists because manually wrangling containers across many servers became a full-time job by 2014. Google had been running their own internal version (Borg) for a decade and open-sourced its successor as Kubernetes. You probably want Kubernetes if you have more than a handful of services, traffic that changes over time, or a real uptime requirement. You probably do not want Kubernetes for a side project, a small SaaS, or anything that fits comfortably on a single VM.

This guide walks you through the five core objects, gets a real cluster running on your laptop in 10 minutes, and ships an actual nginx workload behind a real Ingress. By the end you will know what every piece does and where to go next.

Five core objects in five paragraphs

A Pod is the smallest deployable unit. It wraps one or more containers that share networking and storage. Most pods have one container; the rare exception is a sidecar (a logging or proxy container running alongside your main app). Pods are mortal: they get scheduled, they run, they die, they get replaced. You almost never create a pod directly.

A Deployment describes a desired state ("I want N copies of this pod template, running this image"), and Kubernetes makes it true. When you change the image, the Deployment runs a rolling update, swapping pods one at a time. When a pod dies, the Deployment creates a replacement. Deployments are how you actually run apps.

A Service gives a stable network endpoint to a set of pods that come and go. Three types: ClusterIP (internal-only, the default), NodePort (exposes a port on every node), LoadBalancer (asks the cloud for a real load balancer). The Service watches a label selector and routes traffic to whichever pods match.

An Ingress is HTTP routing on top of Services. "Send traffic for app.example.com to this Service. Send /api/* to that one. Terminate TLS here." It requires an Ingress controller (nginx-ingress, Traefik, HAProxy) to actually do the routing. Ingress without a controller does nothing.

A Namespace is a folder for everything above. You group related resources together (one namespace per app, per team, per environment), and Kubernetes RBAC works at the namespace boundary. That covers 80% of what you use day to day. ConfigMaps, Secrets, Volumes, Jobs, CronJobs, and StatefulSets fill in the rest.

Run your first cluster in 10 minutes

You need three things on your machine:

Install kubectl and kind:

# macOS
brew install kubectl kind

# Linux (kubectl)
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

# Linux (kind)
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.24.0/kind-linux-amd64
chmod +x kind && sudo mv kind /usr/local/bin/kind

# Windows (PowerShell with Chocolatey)
choco install kubernetes-cli kind

Spin up a single-node cluster:

kind create cluster --name k8s-tutorial
kubectl cluster-info --context kind-k8s-tutorial

The first command pulls a Docker image and starts a Kubernetes control plane inside it. Done in about 30 seconds. You now have a real, working cluster on your laptop, talking the same API as a 10,000-node production cluster.

Deploy your first app

Save this as nginx.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-nginx
  template:
    metadata:
      labels:
        app: hello-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80

Apply it:

kubectl apply -f nginx.yaml
kubectl get pods

You should see two pods running. That is the "I want N copies" promise being kept by the Deployment. Kill one with kubectl delete pod <name> and watch a replacement appear within seconds.

Add a Service

Pods get random IPs and die randomly. To talk to them reliably, you put a Service in front. Append this to nginx.yaml or save as a second file:

---
apiVersion: v1
kind: Service
metadata:
  name: hello-nginx
spec:
  selector:
    app: hello-nginx
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

kubectl apply -f nginx.yaml
kubectl get svc

ClusterIP means the Service is reachable only from inside the cluster. Test it from a debug pod:

kubectl run debug --rm -it --image=alpine -- sh
# inside the pod:
wget -qO- hello-nginx

You should see the default nginx HTML.

Service types in plain English:

Add an Ingress

To reach your app from a browser, you need an Ingress controller. Install nginx-ingress on your kind cluster:

kubectl apply -f https://kind.sigs.k8s.io/examples/ingress/deploy-ingress-nginx.yaml

kubectl wait --namespace ingress-nginx \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=120s

Then create an Ingress object. Save as ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-nginx
spec:
  ingressClassName: nginx
  rules:
  - host: hello.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hello-nginx
            port:
              number: 80

Add a hosts entry so your browser knows where to send hello.local. On macOS or Linux: edit /etc/hosts. On Windows: C:\Windows\System32\drivers\etc\hosts.

127.0.0.1 hello.local

Apply and test:

kubectl apply -f ingress.yaml
curl http://hello.local

You should see the nginx welcome page. That is real Layer-7 HTTP routing inside Kubernetes, on your laptop, with the same Ingress object you would use in production.

Scale and roll out

Scale up:

kubectl scale deploy/hello-nginx --replicas=5
kubectl get pods

Three new pods spin up immediately. Scale back down with --replicas=1.

Roll out a new version. Edit the image in your YAML to nginx:1.28, then:

kubectl apply -f nginx.yaml
kubectl rollout status deploy/hello-nginx

Kubernetes does the rolling update one pod at a time. Watch with kubectl get pods -w. If something goes wrong:

kubectl rollout undo deploy/hello-nginx

Back to the previous image, no downtime. This is the single biggest reason engineers reach for Kubernetes.

Clean up

kind delete cluster --name k8s-tutorial

Everything gone. Your laptop is exactly as before.

The five kubectl commands you actually use

Memorize these. They cover roughly 80% of day-to-day work.

Where to go next

You have done the equivalent of "Hello World" in Kubernetes. From here, in rough order of priority:

FAQ

Do I need Docker first?

Not strictly. You need to understand what a container is, but you can learn that as part of Kubernetes. Most beginners do learn Docker first because container images are the unit of deploy.

kind vs Minikube vs k3d?

kind is fastest, simplest, and what most teams use for local CI. Minikube is friendlier for absolute beginners (built-in dashboard, addons, GUI). k3d is the lightest and what you reach for after using kind for a while. All three give you a real cluster.

Is Kubernetes overkill for small projects?

Yes. A single VM with Docker Compose or a $5 Hetzner box runs most side projects fine. Reach for Kubernetes when you outgrow that or need real high availability and rolling deploys.

K3s for a hobby setup?

Great pick. K3s runs in under 512 MB, single binary, production-grade. A $20 VPS hosts a homelab cluster cleanly with room to spare.

Where do beginners get stuck?

Three places: networking (why can my pod not reach this thing?), permissions (RBAC and ServiceAccounts), and ingress (controller vs rule). Spend explicit time on each.

Should I learn Kubernetes in 2026 if I am a backend developer?

Yes for senior roles, optional for junior. Most teams expect you can read a Deployment manifest and deploy a service. Going deeper (operators, custom controllers, RBAC design) is platform engineering territory.

Where to go from here

For the broader career path, the DevOps roadmap and cloud engineer roadmap cover the surrounding skills (CI/CD, infrastructure as code, observability, networking) that make Kubernetes useful in production. The AWS roadmap and Azure roadmap walk through the managed-Kubernetes services (EKS, AKS) most teams ship on.

For utilities that pair well with Kubernetes work, the YAML formatter, JSON tool, and JSON ⇄ YAML converter in the tools catalog save real time when authoring manifests. The system design roadmap covers when not to reach for Kubernetes.

Last updated: April 2026.

Last updated: 2026-06-04

Explore more on Talos.tools