How to Use a Homelab for Kubernetes Practice (Free Setup Guide)

Raphael Ben Hamo — Thu, 23 Apr 2026 20:04:51 +0000

Cloud-based Kubernetes — EKS, AKS, GKE — is expensive to learn on. Every minute a managed cluster runs costs money, and experimenting means breaking things. A homelab eliminates that entirely: run Kubernetes on your own machine, destroy and rebuild clusters without a billing meter, and see every layer of the stack that managed services hide.

Tool Comparison

Feature	Minikube	K3s	Kind
Best for	Beginners	Multi-node / edge	Fast testing / CI
Setup speed	Moderate	Fast	Very fast
Multi-node	Limited	Native	Native via config
Resource usage	Medium	Low	Low
Offline support	Yes	Yes	Yes

Start with Minikube if you're new. It's the official Kubernetes tool, has built-in add-ons, and mirrors a standard cluster closely.

Quick Setup With Minikube

Install on macOS:

brew install minikube

Install on Linux:

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

Start your cluster:

minikube start

Verify it's running:

kubectl get nodes
# NAME       STATUS   ROLES           AGE   VERSION
# minikube   Ready    control-plane   30s   v1.31.0

Three Exercises to Build Real Skills

1. Deployments and Scaling

kubectl create deployment nginx --image=nginx --replicas=3
kubectl scale deployment nginx --replicas=5

Delete a pod manually — Kubernetes recreates it automatically. This is the Deployment controller maintaining desired state.

kubectl delete pod <pod-name>
kubectl get pods --watch

2. ConfigMaps

kubectl create configmap app-config \
  --from-literal=ENV=staging \
  --from-literal=LOG_LEVEL=debug

Mount it into a pod:

# pod-with-config.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: nginx
    envFrom:
    - configMapRef:
        name: app-config

kubectl apply -f pod-with-config.yaml
kubectl exec app-pod -- env | grep -E 'ENV|LOG_LEVEL'

3. Services and Networking

# ClusterIP — cluster-internal only
kubectl expose deployment nginx --port=80 --type=ClusterIP --name=nginx-clusterip

# NodePort — accessible from your machine
kubectl expose deployment nginx --port=80 --type=NodePort --name=nginx-nodeport

# Open in browser via Minikube
minikube service nginx-nodeport

Understanding how traffic moves through ClusterIP → NodePort → LoadBalancer is one of the most valuable Kubernetes networking skills you can build.

Want all 6 exercises — including RBAC, Helm charts, and multi-node K3s configs? Get the full free guide on korpro.io →

From Homelab to Production Thinking

The homelab is where instinct forms. Before you move to production, practice the questions that always come up: How do you monitor workloads? (Install Prometheus + Grafana.) How do you handle persistent data? (Test PersistentVolumeClaims and pod rescheduling.) How do you manage secrets securely? (Try Sealed Secrets or External Secrets Operator.)

Every hour spent breaking and rebuilding a local cluster translates directly to faster debugging and better decisions in production.

Running Kubernetes in Production?

Cost and waste become real problems at scale. KorPro automatically finds orphaned resources, unused ConfigMaps, over-provisioned workloads, and idle services across all your clusters — before they become surprise invoices.

Start free on KorPro →

Stop Paying for Kubernetes Leftovers (Without Risking Production)

Raphael Ben Hamo — Thu, 05 Feb 2026 22:02:27 +0000

Kubernetes waste usually isn’t a dramatic “bug.” It’s the slow accumulation of leftovers: volumes, services, configs, and credentials that were needed once, but no longer have a living workload attached to them.
Teams keep paying for these resources because deleting the wrong thing in production is risky — and manual checks don’t scale across namespaces and clusters.

The 3 kinds of Kubernetes waste
When people say “Kubernetes cost optimization,” they often jump straight to right-sizing CPU/memory. That’s real, but it’s only one category.
In practice, Kubernetes waste usually falls into three buckets: orphaned resources, over-provisioned resources, and idle resources.

This post focuses on the one that’s the most frustrating to deal with manually: orphaned resources — things that still exist, still cost money (or create risk), but are no longer referenced by any active workload.

What “orphaned” looks like in real clusters
Orphaned resources show up in multiple places, especially after migrations, incident fixes, Helm churn, and “temporary” environments that became permanent.
Common examples include:

PersistentVolumes / PVCs that are no longer attached to running workloads.
Services with no active endpoints (nothing behind them anymore).
Secrets and ConfigMaps that have no live consumer, but still sit in the API and increase audit/attack surface.

The hard part isn’t understanding the list — it’s proving “unused” safely, because Kubernetes references can be indirect and spread across many objects.

Why unused Secrets are so hard to clean up
Secrets don’t expire just because an app was removed. Over time, clusters quietly accumulate credentials with no clear owner.
That creates a larger attack surface, harder audits, and operational uncertainty — because nobody wants to delete a Secret and discover it was still referenced somewhere obscure.

Become a member
This is why simple heuristics (labels, naming conventions, “last applied,” or “created date”) don’t hold up in production. Kor (the open-source project behind KorPro) approaches it differently by building a reference graph across workloads and Kubernetes objects to determine whether a Secret is truly in use.

A practical “audit-first” approach (what good looks like)
In production, the safest cleanup workflow is audit-first:

Scan clusters for unused/orphaned objects across namespaces.
Enrich each finding with context (cost, health, risk) so humans can prioritize.
Generate a “safe-to-prune” review list — then decide what to delete and when (during a change window, with approvals). That last step matters: a tool should help teams delete with confidence, but it shouldn’t auto-delete in production by default.

How KorPro helps (without installing anything in the cluster)
KorPro is built to discover and analyze unused Kubernetes resources across AWS (EKS), GCP (GKE), and Azure (AKS), with a “zero-installation” architecture that runs outside the cluster using read-only permissions.
It scans for unused resources (ConfigMaps, Secrets, Services, Deployments, PVCs, and more), then enriches findings with cost estimates (monthly/yearly), health/efficiency metrics, and security risk assessments.

Most importantly for real-world teams, KorPro follows an audit-first approach: it provides recommendations and a safe-to-prune checklist, but does not automatically delete resources — you keep control of production changes.

Try it on your cluster (free)
If you’re spending meaningful money on Kubernetes, it’s worth running a quick audit just to see what you’re still paying for from old environments, removed apps, and past migrations.
KorPro offers a free trial (up to 5 reports/month): https://app.korpro.io/signup
If you want to see the output format first, there’s an interactive demo here: https://korpro.io/demo

DEV Community: Raphael Ben Hamo