Kubernetes: Getting Started

A practical, zero-to-running walkthrough: install the tools, spin up a local cluster, deploy your first app, expose and scale it, roll out a new version, and clean up. Every command runs locally — no cloud account needed.

---

Prerequisites

You do not need a cloud account, a registry, or any paid service to follow along.

---

Step 1 — Install kubectl

kubectl is the command-line client that talks to the Kubernetes API. Install it for your OS:

# macOS (Homebrew)
brew install kubectl

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

# Verify
kubectl version --client

---

Step 2 — Start a local cluster with Minikube

Minikube gives you a real single-node cluster on your laptop — perfect for learning and development (but not production, because a single node has no high availability).

# Install (macOS example)
brew install minikube

# Start a cluster, pinning a Kubernetes version close to your target
minikube start --driver=docker --kubernetes-version=v1.30.2 --cpus=4 --memory=6g

# Confirm the cluster is up
kubectl get nodes
kubectl cluster-info

Enable a couple of handy add-ons:

minikube addons enable metrics-server   # powers `kubectl top`
minikube addons enable ingress          # HTTP routing

---

Step 3 — Deploy your first app

Kubernetes is declarative: you describe the desired state and the cluster makes it true. Here is a minimal Deployment.

# web.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests: { cpu: "100m", memory: "64Mi" }
            limits:   { cpu: "250m", memory: "128Mi" }

Apply it and watch the pods come up:

kubectl apply -f web.yaml
kubectl get pods -w        # Ctrl-C once all 3 are Running
kubectl get deploy,rs,pods

Tip: kubectl apply is idempotent — re-running it only changes what differs. Keep your YAML in Git; that becomes your source of truth.

---

Step 4 — Expose the app with a Service

Pod IPs change on every restart, so you never talk to a pod directly. A Service gives a stable virtual IP and load-balances across the pods.

# Create a ClusterIP Service (internal), then reach it from your host
kubectl expose deployment web --port=80 --target-port=80
kubectl get svc web
kubectl get endpoints web    # the pod IPs the Service fans out to

# Open it in a browser via Minikube
minikube service web --url

For real HTTP exposure you would front many Services with a single Ingress instead of one cloud load balancer per app.

---

Step 5 — Scale up and down

Scaling is a one-liner (imperative) or a field change (declarative):

# Imperative
kubectl scale deployment web --replicas=5

# Or edit replicas in web.yaml and re-apply (preferred, keeps Git in sync)
kubectl apply -f web.yaml

Let the cluster scale for you based on CPU:

kubectl autoscale deployment web --cpu-percent=60 --min=3 --max=10
kubectl get hpa web

---

Step 6 — Roll out a new version (and roll back)

Change the image and Kubernetes performs a rolling update — replacing pods gradually with zero downtime. If something is wrong, roll back to the previous revision instantly.

# Roll forward
kubectl set image deployment/web web=nginx:1.27-alpine
kubectl rollout status deployment/web

# Inspect history
kubectl rollout history deployment/web

# Roll back the moment you spot trouble
kubectl rollout undo deployment/web

Rollback is your fastest lever during an incident — practice it before you need it.

---

Essential command cheat-sheet

Keep this within reach while you learn.

A triage order that works

When a pod misbehaves, gather evidence in this order:

1. kubectl describe pod <pod> — read the Events at the bottom.
2. kubectl logs <pod> --previous — the crash that caused the last restart.
3. kubectl top pod <pod> — is it hitting a memory/CPU limit?
4. kubectl get events --sort-by=.lastTimestamp — cluster-wide context.

---

Step 7 — Clean up

# Remove the app
kubectl delete -f web.yaml
kubectl delete svc web

# Tear down the whole local cluster when you're done
minikube stop        # keep it for next time
minikube delete      # remove it entirely

---

Common mistakes to avoid

• No resource requests/limits. Without them the scheduler can't place pods well and one noisy pod starves its neighbors. Set both (as in the Deployment above).
• Talking to pod IPs directly. They change on every restart. Always go through a Service.
• Treating latest as a version. image: nginx:latest makes rollouts non-reproducible and rollbacks meaningless. Pin a tag.
• Ignoring the Events section. kubectl describe pod puts the real reason (ImagePull, scheduling, probe failures) at the bottom. Read it first.
• Reading current logs after a crash. kubectl logs <pod> shows the new container. Use --previous to see what actually crashed.
• No liveness/readiness probes. Without readiness, traffic hits pods that aren't ready; without liveness, wedged pods never restart.
• Editing live objects with kubectl edit and forgetting Git. Your cluster and your YAML drift. Change the manifest and re-apply.

---

Practice: try it yourself

1. Full loop from scratch. Apply web.yaml, expose it, open it via minikube service, then scale to 5 and watch the new pods schedule.
2. Practice a rollback before you need one. Roll out nginx:1.27-alpine, then kubectl rollout undo and confirm with rollout history. Time how fast it is.
3. Break something on purpose. Set the image to nginx:doesnotexist, apply, and diagnose it using only describe → logs --previous → events. What's the pod status?
4. Autoscale it. Add an HPA (--cpu-percent=60 --min=3 --max=10), generate load, and watch kubectl get hpa web change replica count.

Self-check:

• Why do you never talk to a pod IP directly? What gives you a stable address?
• A pod is CrashLoopBackOff. What three commands, in what order, find the cause?
• What does a rolling update do that a "delete then recreate" doesn't?
• What's the difference between a readiness and a liveness probe?

---

Where to go next

• Deepen the fundamentals with the interview questions — they explain the why behind each object.
• Learn failure modes in the production issues section (CrashLoopBackOff, ImagePullBackOff, OOMKilled, node NotReady).
• See real patterns in the use cases (autoscaling, safe rollouts, network isolation).
• Handy tools: scaffold YAML with the Manifest Generator, catch issues with the YAML Validator, and size nodes with the Capacity Calculator.
• Follow the roadmap for a phase-by-phase path from fundamentals to CKA/CKAD/CKS.

You now have the core loop: declare → apply → observe → iterate. Everything else in Kubernetes builds on it.