75.1 Project 31: Local cluster with kind or minikube
Friends, every Kubernetes change should be tried on a laptop first. Today we create a local cluster with kind, check nodes are Ready, set kubectl context, and deploy a tiny nginx pod as smoke proof.
मित्रांनो, प्रत्येक Kubernetes change आधी laptop वर try करा. आज kind ने local cluster, nodes Ready, kubectl context, छोटा nginx smoke proof.
दोस्तों, हर Kubernetes change पहले laptop पर try करें. आज kind से local cluster, nodes Ready, kubectl context, छोटा nginx smoke proof.
What you will build in this project
- A kind cluster named shop-lab.
- kubectl context points at the lab.
- All nodes Ready.
- A smoke nginx Deployment proves the API works.
1. Start from a real company story
At Cognizant in Chennai, a junior applied a YAML straight to the shared staging cluster. One typo deleted a Service used by three teams.
Staging was dark for ninety minutes. Rough cost: about ₹12 lakh in delayed QA and overtime.
Meera made every engineer keep a kind cluster on the laptop. Staging only receives reviewed YAML after local proof.
Today we build that kind lab and prove the API with a smoke Deployment.
Ravindra Bagale's Tip
Many students skip the local cluster and learn on shared staging. One wrong apply hurts everyone. Keep a kind cluster on your laptop. Keep that habit.
खूप students local cluster skip करतात आणि shared staging वर शिकतात. चुकीचा apply सर्वांना दुखावतो. Laptop वर kind ठेवा. सवय ठेवा.
बहुत students local cluster skip कर shared staging पर सीखते हैं. गलत apply सबको चोट पहुंचाता है. Laptop पर kind रखें. आदत रखिए.
2. Start and prepare
Step 1: Check Docker is up
Why: kind needs a Docker engine. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: docker info. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 1: docker
Type this:
docker info --format '{{.ServerVersion}}' 2>/dev/null || echo 'start Docker Desktop or dockerd first'
You will see:
24.0.7
What it means: Docker engine is up so kind can create node containers.
Example 2: ps
Type this:
docker ps --format '{{.Names}}' | head -3 || true
You will see:
(empty or other containers)
What it means: The Docker API responds; kind will add control-plane next.
Example 3: disk
Type this:
df -h / | tail -1 | awk '{print $4}'
You will see:
20G
What it means: Enough free space for the kind node image layers.
Step 2: Confirm kubectl binary
Why: kubectl is the client CLI. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: kubectl version. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 4: kubectl
Type this:
kubectl version --client --output=yaml 2>/dev/null | head -5 || echo 'install kubectl from kubernetes.io docs'
You will see:
clientVersion:
major: "1"
What it means: kubectl client is installed and reports a major version.
Example 5: which
Type this:
command -v kubectl
You will see:
/usr/local/bin/kubectl
What it means: kubectl is on PATH for every new shell.
Example 6: help
Type this:
kubectl get --help | head -2
You will see:
Display one or many resources
What it means: Help text proves the binary runs.
Step 3: Confirm kind binary
Why: kind is the cluster tool. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: kind version. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 7: kind
Type this:
kind version 2>/dev/null || echo 'install kind from kind.sigs.k8s.io'
You will see:
kind v0.23.0 go1.21.7 linux/amd64
What it means: kind binary is present for local clusters.
Example 8: which kind
Type this:
command -v kind
You will see:
/usr/local/bin/kind
What it means: kind is on PATH.
Example 9: why kind
Type this:
echo 'kind = Kubernetes IN Docker; great for laptop labs before staging'
You will see:
kind = Kubernetes IN Docker; great for laptop labs before staging
What it means: Why we pick kind for this course.
3. Build the main pieces
Step 4: Create kind cluster
Why: create cluster starts the control plane. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: kind create. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 10: create
Type this:
kind delete cluster --name shop-lab >/dev/null 2>&1; kind create cluster --name shop-lab
You will see:
Creating cluster "shop-lab" ...
Set kubectl context to "kind-shop-lab"
What it means: Cluster shop-lab is created and context is set.
Example 11: clusters
Type this:
kind get clusters
You will see:
shop-lab
What it means: kind lists our lab cluster name.
Example 12: nodes docker
Type this:
docker ps --filter name=shop-lab --format '{{.Names}} {{.Status}}'
You will see:
shop-lab-control-plane Up
What it means: The control-plane container is running inside Docker.
Step 5: List nodes Ready
Why: get nodes shows health. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: kubectl get nodes. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 13: nodes
Type this:
kubectl get nodes
You will see:
NAME STATUS ROLES AGE VERSION
shop-lab-control-plane Ready control-plane 1m v1.30.0
What it means: The only node reports Ready.
Example 14: wide
Type this:
kubectl get nodes -o wide | awk 'NR==1 || NR==2'
You will see:
NAME STATUS ... INTERNAL-IP
What it means: Wide view shows the node IP inside the kind network.
Example 15: ready count
Type this:
kubectl get nodes --no-headers | awk '$2=="Ready"{c++} END{print c+0}'
You will see:
1
What it means: Exactly one Ready node in this single-node lab.
Step 6: Show kubectl context
Why: context avoids the wrong cluster. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: kubectl config. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 16: ctx
Type this:
kubectl config current-context
You will see:
kind-shop-lab
What it means: kubectl talks to the lab, not a cloud cluster.
Example 17: contexts
Type this:
kubectl config get-contexts | awk 'NR==1 || /shop-lab/'
You will see:
CURRENT NAME CLUSTER AUTHINFO
What it means: The shop-lab context row is visible.
Example 18: cluster
Type this:
kubectl config view --minify -o jsonpath='{.clusters[0].name}'; echo
You will see:
kind-shop-lab
What it means: Minified kubeconfig points only at the lab.
4. Automate and verify
Step 7: Write smoke YAML
Why: YAML describes desired state. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: printf YAML. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 19: yaml
Type this:
mkdir -p /tmp/k8s31 && printf '%s\n' 'apiVersion: apps/v1' 'kind: Deployment' 'metadata:' ' name: smoke' 'spec:' ' replicas: 1' ' selector:' ' matchLabels: {app: smoke}' ' template:' ' metadata:' ' labels: {app: smoke}' ' spec:' ' containers:' ' - name: web' ' image: nginx:1.27-alpine' ' ports: [{containerPort: 80}]' > /tmp/k8s31/smoke.yaml && wc -l /tmp/k8s31/smoke.yaml
You will see:
16 /tmp/k8s31/smoke.yaml
What it means: Smoke Deployment YAML written with printf, not a heredoc.
Example 20: cat head
Type this:
head -3 /tmp/k8s31/smoke.yaml
You will see:
apiVersion: apps/v1
kind: Deployment
metadata:
What it means: Header matches apps/v1 Deployment.
Example 21: grep image
Type this:
grep image: /tmp/k8s31/smoke.yaml
You will see:
image: nginx:1.27-alpine
What it means: Pinned nginx Alpine tag for the smoke test.
Step 8: Apply smoke Deploy
Why: apply creates the objects. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: kubectl apply. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 22: apply
Type this:
kubectl apply -f /tmp/k8s31/smoke.yaml
You will see:
deployment.apps/smoke created
What it means: API accepted the Deployment.
Example 23: get deploy
Type this:
kubectl get deploy smoke
You will see:
NAME READY UP-TO-DATE AVAILABLE
smoke 0/1 1 0
What it means: Deployment object exists; pods still starting.
Example 24: get rs
Type this:
kubectl get rs -l app=smoke --no-headers | wc -l
You will see:
1
What it means: Controller created one ReplicaSet.
Step 9: Wait until Available
Why: wait proves the pods. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: kubectl wait. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 25: wait
Type this:
kubectl wait --for=condition=available deploy/smoke --timeout=90s
You will see:
deployment.apps/smoke condition met
What it means: Deployment is Available.
Example 26: pods
Type this:
kubectl get pods -l app=smoke -o wide
You will see:
NAME READY STATUS IP NODE
smoke-... 1/1 Running 10.x shop-lab-control-plane
What it means: Pod is Running on the kind node.
Example 27: phase
Type this:
kubectl get pod -l app=smoke -o jsonpath='{.items[0].status.phase}'; echo
You will see:
Running
What it means: Phase field confirms Running.
5. Harden and accept
Step 10: Port-forward and curl
Why: port-forward reaches the pod. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: kubectl port-forward. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 28: pf
Type this:
kubectl port-forward deploy/smoke 8080:80 >/tmp/k8s31/pf.log 2>&1 & echo $! > /tmp/k8s31/pf.pid; sleep 1; curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8080/
You will see:
200
What it means: Port-forward returns HTTP 200 from nginx.
Example 29: kill pf
Type this:
kill $(cat /tmp/k8s31/pf.pid) 2>/dev/null; echo stopped
You will see:
stopped
What it means: Background port-forward stopped cleanly.
Example 30: logs
Type this:
kubectl logs -l app=smoke --tail=2
You will see:
GET / HTTP/1.1" 200
What it means: Access shows up in container logs.
Step 11: Delete smoke objects
Why: cleanup keeps the laptop clean. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: kubectl delete. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 31: delete
Type this:
kubectl delete -f /tmp/k8s31/smoke.yaml
You will see:
deployment.apps "smoke" deleted
What it means: Smoke objects removed from the lab.
Example 32: empty
Type this:
kubectl get deploy smoke 2>&1 | head -1
You will see:
Error from server (NotFound)
What it means: Deployment is gone as expected.
Example 33: keep
Type this:
echo 'Keep shop-lab for projects 32-39; delete later with kind delete cluster --name shop-lab'
You will see:
Keep shop-lab for projects 32-39; delete later with kind delete cluster --name shop-lab
What it means: Reuse the same cluster for the next projects.
Step 12: Acceptance checklist
Why: Meera signs off when these pass. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: All green. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 34: nodes still
Type this:
kubectl get nodes --no-headers | awk '{print $2}'
You will see:
Ready
What it means: Cluster still healthy after smoke cleanup.
Example 35: ctx still
Type this:
kubectl config current-context
You will see:
kind-shop-lab
What it means: Still pointed at the lab context.
Example 36: Sign-off
Type this:
echo 'Meera: PASS'
You will see:
Meera: PASS
What it means: Project 31 accepted.
Check yourself
Q1. Who fixed Cognizant staging chaos?
Meera
Q2. Cluster name in the lab?
shop-lab
Q3. Tool that runs K8s in Docker?
kind
Q4. Command to list nodes?
kubectl get nodes
Q5. Desired node status?
Ready
Q6. Smoke image?
nginx:1.27-alpine
Friends, you created a kind cluster and proved nodes Ready with a smoke nginx. Did you understand? Let us try it once more. Add a second worker node config and recreate the cluster from a kind config file.
मित्रांनो, तुम्ही kind cluster तयार करून nodes Ready सिद्ध केले. दुसरा worker node config टाका.
दोस्तों, आपने kind cluster बना nodes Ready सिद्ध किए. दूसरा worker node config डालें.
Lab: try at home
- Install or confirm kind and kubectl.
- Create cluster shop-lab.
- Confirm nodes Ready and context.
- Deploy smoke nginx.
- Delete the smoke and keep the cluster for later projects.
Recap
- kind runs Kubernetes inside Docker.
- kubectl talks to the API server.
- Context selects which cluster.
- Nodes must be Ready before apps.
- Always delete lab clusters when the whole chapter is done.