Kubernetes on Your Laptop — No Cloud, No Boring Docs, Just Magic

Scene 1: “What even is Docker?”#

Imagine you’re trying to run an app. It works perfectly for your friend on Windows, but not for you on a Mac. She’s on Windows, you’re on a Mac. It needs a bunch of libraries you don’t have.

🎯 The fix? A container — a self-contained package that already includes everything the app needs.

🧳 A container = a suitcase with code, tools, and everything else bundled in.

Docker is the program that runs those suitcases — right on your machine.

Scene 2: “Download and install Docker”#

📝 Do this:

1. Go to 👉 https://www.docker.com/products/docker-desktop
2. Choose Docker Desktop for macOS (or your OS).
3. Download the installer.
4. Install like any other app: drag the Docker icon into your Applications folder.

📌 Once it’s installed — launch Docker Desktop (via Spotlight or Launchpad).

Quick check: is Docker working?#

🔧 Open Terminal (Cmd + Space, type “Terminal”).

Run this command:

1
bash docker --version

You should see something like:

1
Docker version 24.0.2, build abc123

That means Docker is installed!

Next, run:

1
docker ps

If Docker is running, you’ll see an empty table, like:

1
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

That’s totally fine — it just means no containers are running yet.

😱 If Docker doesn’t start or docker ps throws an error:

Why does this matter?#

We’ll be launching our Kubernetes cluster using Minikube, and Minikube runs containers under the hood.

No Docker = no cluster = no “Hello, Pod.” 😬

✅ TL;DR — You’re ready to move on if:

• You installed Docker Desktop
• docker --version works
• docker ps shows an empty table (and no errors)

If all that’s good — let’s install Kubernetes (via Minikube)!

Scene 1: “What are Minikube and kubectl?”#

🛠 Minikube is like a mini version of Kubernetes you can run right on your laptop.

That means: no server, no cloud, no AWS, no mystical cluster setup — Minikube spins it all up locally.

🎮 kubectl (say “cube control” or “kube cuddle”) is your remote control for that cluster.

You’ll use kubectl to create pods, check logs, update apps — basically, run the show.

Scene 2: Install kubectl and Minikube#

📝 If you’re on a Mac:

Open Terminal and run these one by one:

1
brew install kubectl

Then:

1
brew install minikube

🧘‍♀️ Take a moment, let Homebrew do its magic.

Scene 3: Start the cluster#

Once it’s installed, fire up your mini-cluster:

1
minikube start --driver=docker

💡 What’s happening here:

• Kubernetes is starting inside Docker (which you set up in Step 1).
• Minikube creates a “virtual machine” running your cluster.

⏱ This may take 1-2 minutes, so… deep breath.

Check if everything’s working#

Run this command:

1
kubectl get nodes

📋 You should see something like:

1
NAME STATUS ROLES AGE VERSION
2
minikube Ready control-plane 1m v1.29.0

If you see STATUS: Ready - congrats! 🎉

Your first cluster is up. You literally just spun up your own infrastructure.

NOTE

Minikube runs a single-node cluster - perfect for learning and testing, but not meant for production. And that’s totally fine — we’re here to get hands-on, not deploy Netflix.

If something goes wrong - don’t panic!#

Why did we do this?#

• Kubernetes is how you run and manage container-based apps.
• Minikube lets you explore it without needing cloud servers.
• kubectl is your command center.

Now you’re ready to create pods, deployments, services - everything a true DevOps witch needs.

Scene 1: “What even is a Pod?”#

📦 In Kubernetes, everything revolves around Pods.

Think of a Pod as a little room with one (or more) containers inside that:

• share network and storage
• start together
• live and die together

A Pod usually runs just one container (like our nginx example) - but it can have multiple, like sidecars.

Scene 2: Create a YAML file for your Pod#

📁 Open VS Code or your favorite code editor. Create a new file and name it:

1
pod.yaml

✍️ Paste this inside:

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: my-first-pod
5
spec:
6
  containers:
7
    - name: nginx
8
      image: nginx:alpine
9
      ports:
10
        - containerPort: 80

✨ What’s going on here:

• apiVersion, kind, metadata — just Kubernetes boilerplate: “this is a Pod, name it like this”.
• Inside containers: you’re saying: “Run a container using nginx and open port 80.”

Scene 3: Apply the file and launch the Pod#

In your terminal, while inside the folder with the file:

1
kubectl apply -f pod.yaml

👉 This tells Kubernetes: “Here’s the definition — go make it real!”

Then check:

1
kubectl get pods

You should see something like:

1
NAME READY STATUS RESTARTS AGE
2
my-first-pod 1/1 Running 0 10s

✅ STATUS: Running means your Pod is alive and well! 🎉

Scene 4: Open your app in the browser#

Now let’s actually see nginx in action. Time to forward that port:

1
kubectl port-forward pod/my-first-pod 8080:80

💡 What’s this doing?

• It tunnels port 80 from inside the container to your localhost:8080.
• Meaning: whatever nginx serves, you can see in your browser.

Scene 5: Check if it’s working#

Pop open your browser and go to:

1
http://localhost:8080

If you see the default nginx page — boom, success!

If it didn’t work: deep breath, let’s fix it#

So far, you’ve:

✅ Started your cluster
✅ Created your very first Pod
✅ Launched nginx
✅ Accessed it through the browser

This was your first real app running in Kubernetes — and that’s a huge milestone 👏👏👏

Scene 1: “What is a Deployment, anyway?”#

In the last step, you manually created a Pod. But here’s the problem:

• If it crashes — nobody restarts it
• You want two Pods for reliability
• You want Kubernetes to watch over them automatically

🎯 Enter the Deployment. It:

✅ creates Pods
✅ scales them (1, 2, 10, 100 — whatever)
✅ restarts them if they crash
✅ makes it easy to update images

Basically — a Pod manager that keeps your app alive and thriving.

Scene 2: Create the Deployment YAML#

📁 Create a new file called:

1
deployment.yaml

✍️ Paste this in:

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: nginx-deployment
5
spec:
6
  replicas: 2
7
  selector:
8
    matchLabels:
9
      app: nginx
10
  template:
11
    metadata:
12
      labels:
13
        app: nginx
14
    spec:
15
      containers:
16
        - name: nginx
17
          image: nginx:alpine
18
          ports:
19
            - containerPort: 80

💡 What’s happening here:

• replicas: 2: we’re saying “Give me 2 identical Pods”
• selector.matchLabels + template.metadata.labels — this connects the Deployment to the Pods via app: nginx
• containers: same as before: launch nginx

Scene 3: Apply the Deployment#

Open your terminal and run this:

1
kubectl apply -f deployment.yaml

🔍 You’re telling Kubernetes: “Here’s the blueprint — build it.”

Now check that it worked:

1
kubectl get deployments

You should see something like:

1
NAME READY UP-TO-DATE AVAILABLE AGE
2
nginx-deployment 2/2 2 2 10s

✅ Which means: 2 Pods are up and running.

Now check the actual Pods:

1
kubectl get pods

You should see two Pods with similar names, like:

1
nginx-deployment-xxx-yyy 1/1 Running
2
nginx-deployment-aaa-bbb 1/1 Running

Scene 4: Let’s test the auto-recovery#

🧪 Tiny experiment: delete one of the Pods

1
kubectl delete pod <one-of-the-pod-names>

A few seconds later:

1
kubectl get pods

You’ll see 2 Pods again.

🤯 Because the Deployment noticed one was gone — and created a new one automatically!

If the Deployment doesn’t launch or Pods don’t appear#

📌 Pro tip: You can always list Pods with:

1
kubectl get pods

Why this matters#

Now you’ve got:

• Two Pods = more reliability
• Self-healing containers
• Easy updates in the future

You just leveled up from “one test container” to a real Kubernetes-managed application.

Scene 1: “What is a Service?”#

You already launched 2 nginx Pods — but right now, they’re hiding behind a wall.

🙅‍♀️ Without a Service, you can’t just open them in the browser. Because:

• Pods have internal IPs
• They’re not accessible from “outside”
• If a Pod restarts, its IP might change

🎯 A Service is like a stable front door to your app.

It knows where your Pods are and routes traffic to them.

Even if a Pod dies, restarts, or moves — the Service still leads to the right place.

Scene 2: Create service.yaml#

📁 Create a new file and name it:

1
service.yaml

✍️ Paste this in:

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: nginx-service
5
spec:
6
  type: NodePort
7
  selector:
8
    app: nginx
9
  ports:
10
    - port: 80
11
      targetPort: 80
12
      nodePort: 30080

💡 What this does:

• type: NodePort: tells Kubernetes: “Expose this to the outside world via a port”
• selector: app: nginx: the Service will forward traffic to Pods with that label
• port: the port the Service listens on (inside the cluster)
• targetPort: where to send traffic inside the Pod (nginx listens on port 80)
• nodePort: the external port you’ll use in your browser

Scene 3: Apply the Service#

In your terminal:

1
kubectl apply -f service.yaml

🎉 Boom — your Service is live!

Now run this:

1
minikube service nginx-service

🪄 That command will automatically open your site in the browser — no need to worry about ports, IPs, or voodoo.

Didn’t open? You can do it manually:

1
minikube ip

👉 You’ll get an IP, like 192.168.49.2

Now go to:

1
http://192.168.49.2:30080

✅ You should see the nginx welcome page!

What did we just do?#

• You created a Service to route traffic to your Pods
• Used NodePort to make it accessible from outside
• Opened a real website running inside Kubernetes — without port-forward

You’re now officially at the “my app runs in K8s and opens in a browser” level —

aka your very first Kubernetes web app prototype!

Scene 1: “Why do we even need ConfigMap?”#

Let’s say you’ve got a website. And now you want to:

• show a different welcome message
• tweak the behavior without rebuilding the image
• keep settings separate from your code

📦 ConfigMap is how you pass variables into your Pods.

Think of it like: “Here’s a YAML with your config — grab it when you start up.”

Scene 2: Create the ConfigMap#

📁 Create a file called:

1
configmap.yaml

✍️ Paste this:

1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: nginx-config
5
data:
6
  WELCOME_MSG: "Hello from ConfigMap!"

✨ What’s going on here:

• data: is just a key-value map
• WELCOME_MSG is an example string (but it could be a URL, a mode, a path — anything)

Scene 3: Update your deployment.yaml#

Open your deployment.yaml and inside the container block, add this under spec.containers[0]:

1
env:
2
  - name: WELCOME_MSG
3
    valueFrom:
4
      configMapKeyRef:
5
        name: nginx-config
6
        key: WELCOME_MSG

📌 This tells Kubernetes: “When launching the container, pass it this environment variable from the ConfigMap.”

Scene 4: Apply it all#

In your terminal, run:

1
kubectl apply -f configmap.yaml
2
kubectl apply -f deployment.yaml

🔄 This updates both the ConfigMap and the Deployment so everything is hooked up.

Scene 5: Check if the variable is inside the container#

First, get the name of one of the Pods:

1
kubectl get pods

Copy a name (like nginx-deployment-xxx-yyy) and jump inside:

1
kubectl exec -it nginx-deployment-xxx-yyy -- /bin/sh

Now run:

1
echo $WELCOME_MSG

✅ You should see:

1
Hello from ConfigMap!

🎉 It worked! The variable made it all the way into your container from Kubernetes.

If the variable didn’t show up#

📌 Pro tip: For the new config to appear, the Pod usually has to be recreated.

kubectl apply updates the Deployment, but won’t restart running Pods.

What did you just do?#

• Created a config variable in Kubernetes
• Passed it into a Pod via Deployment
• Saw the variable live inside your container

This is key when your app needs to be flexible — change config without rebuilding the Docker image.

Scene 1: “ConfigMap vs Secret: what’s the difference?”#

💡 ConfigMap — for regular settings: modes, messages, URLs.

🔐 Secret — for anything you don’t want exposed to the world:

• passwords
• access tokens
• API keys

❗ Heads up: Secret values are automatically base64-encoded.

That’s not encryption — just a way to hide them from curious eyes.

Scene 2: Create a secret file#

📁 Create a new file:

1
secret.yaml

✍️ Paste this:

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: nginx-secret
5
type: Opaque
6
data:
7
  SECRET_MSG: SGVsbG8sIGZyb20gU2VjcmV0IQ==

✨ What’s going on:

• type: Opaque: standard type of Secret
• data:: key-value pairs (in base64)

📌 Example:

1
echo -n "Hello, from Secret!" | base64

Which gives you: SGVsbG8sIGZyb20gU2VjcmV0IQ==

Scene 3: Link the Secret to your container#

Open your deployment.yaml.

Inside containers > env, add:

1
- name: SECRET_MSG
2
  valueFrom:
3
    secretKeyRef:
4
      name: nginx-secret
5
      key: SECRET_MSG

📌 Works exactly like ConfigMap — just a different data source: a Secret.

Scene 4: Apply the changes#

In your terminal:

1
kubectl apply -f secret.yaml
2
kubectl apply -f deployment.yaml

📦 Kubernetes will update the Secret and roll out the changes.

Scene 5: Check the container#

First, get your Pod’s name:

1
kubectl get pods

Then hop inside one:

1
kubectl exec -it <pod_name> -- /bin/sh

Now check the variable:

1
echo $SECRET_MSG

✅ You should see:

1
Hello, from Secret!

🎉 That means your Secret was passed into the container successfully!

If the Secret variable didn’t show up#

📌 Pro tip: If the variable doesn’t show up after apply, manually deleting the Pod usually helps.

Why does this matter?#

🔐 Secret is the standard way to safely pass sensitive data into your app — no hardcoding, no YAML leaks.

You just:

• created a Kubernetes Secret
• passed it into a container
• verified it from the inside

Magic. Secure magic. 💫

⏸️ Now pause for a second.

Do you realize what you’ve just done?

You installed a cluster. Deployed an app. Passed it configs and secrets — the full DevOps starter pack.

🤯 No clouds. No five tabs of Stack Overflow. No fear of hitting Enter.

Let’s wrap it all up in a beautiful summary:

Want to take a break and return later?#

1. Stop the cluster:

1
minikube stop

1. Optionally quit Docker Desktop:

   Click the 🐳 icon in the top bar → Quit Docker Desktop

🛑 That’s like hitting “pause.”

Nothing will be deleted — everything stays just as it is.

👉 When you want to come back:

• Start Docker Desktop
• Then run:

1
minikube start

💡 And boom — your Pods, Services, Configs, Secrets… all back in action.

Not planning to return?#

If you want to fully clean up everything we built:

1
minikube delete

This removes the cluster, all Pods, configs, and secrets — clean slate.

You can leave Docker installed — you’ll probably use it again (a lot).

Even if you never touch Kubernetes again — know this:

You started it. You understood it. You owned it. That’s already a huge step into the DevOps world.