Keeping It Clean: Organizing Minikube Projects with Kubernetes Namespaces

Keeping It Clean: Organizing Minikube Projects with Kubernetes Namespaces When I first started experimenting with Kubernetes during the COVID shutdown of America, using Minikube on my local Linux laptop, my primary goal was simple: just get it running. I wanted to see containers spin up, web apps load, and monitoring tools like Grafana and Prometheus show colorful dashboards. And it worked—for a while. As a seasoned administrator and developers I knew better but, I wanted to see what I could glean from my own findings, in addition to what I was doing at work. But as my experimentation grew into more complex projects, I started running into a wall: my cluster was messy. The Problem: Everything Was in One Basket Initially, I deployed everything into the default namespace. It seemed convenient at the time—after all, Minikube doesn’t require you to think about namespaces when you’re just getting started. Over time, though, things got tangled: Prometheus components were scattered across namespaces. Web apps, databases, and monitoring tools were stepping on each other. I couldn't tell which resources belonged to what project. Cleaning up and troubleshooting became a nightmare. The Revelation: Namespaces Are Not Optional I realized that clean architecture starts with namespaces. Namespaces allow you to isolate your components logically and operationally: web: for web applications database: for databases monitoring: for tools like Grafana and Prometheus devops: for CI/CD components like Jenkins This organization not only brings clarity but also makes it easier to: Apply RBAC policies Clean up projects without risking unrelated resources Restart or rebuild environments independently Step 1: Cleanup I decided to clean up my Minikube environment completely, retaining only what was essential: Deleted all user-created namespaces: kubectl delete namespace web database prometheus Cleaned up leftover Prometheus and Helm resources in the default namespace: kubectl get configmap,secrets,serviceaccounts -n default | grep prometheus kubectl delete serviceaccount prometheus-grafana prometheus-kube-prometheus-alertmanager \ prometheus-kube-prometheus-operator prometheus-kube-prometheus-prometheus \ prometheus-kube-state-metrics prometheus-prometheus-node-exporter -n default Verified only Minikube system namespaces remained: kubectl get namespaces Output: default kube-node-lease kube-public kube-system kubernetes-dashboard monitoring (for Grafana) Step 2: Planning for the Future Going forward, every component will live in its own namespace: Grafana stays in monitoring Prometheus will be reinstalled in a clean prometheus namespace Future apps like web1, web2, and web3 will get their own namespaces This structure makes it far easier to maintain and scale your Kubernetes environment, even when working locally with Minikube. Final Thoughts What started as a fun experiment quickly turned into a lesson in Kubernetes best practices. If you’re serious about learning Kubernetes and DevOps, you should adopt clean practices early. Start with clear naming conventions, separate namespaces, and regular cleanup. Because the only thing worse than a crashed pod is a cluster where you don’t know why it crashed—or even who it belonged to.

May 4, 2025 - 17:45

Keeping It Clean: Organizing Minikube Projects with Kubernetes Namespaces

When I first started experimenting with Kubernetes during the COVID shutdown of America, using Minikube on my local Linux laptop, my primary goal was simple: just get it running. I wanted to see containers spin up, web apps load, and monitoring tools like Grafana and Prometheus show colorful dashboards. And it worked—for a while. As a seasoned administrator and developers I knew better but, I wanted to see what I could glean from my own findings, in addition to what I was doing at work.

But as my experimentation grew into more complex projects, I started running into a wall: my cluster was messy.

The Problem: Everything Was in One Basket

Initially, I deployed everything into the default namespace. It seemed convenient at the time—after all, Minikube doesn’t require you to think about namespaces when you’re just getting started. Over time, though, things got tangled:

Prometheus components were scattered across namespaces.
Web apps, databases, and monitoring tools were stepping on each other.
I couldn't tell which resources belonged to what project.

Cleaning up and troubleshooting became a nightmare.

The Revelation: Namespaces Are Not Optional

I realized that clean architecture starts with namespaces. Namespaces allow you to isolate your components logically and operationally:

web: for web applications
database: for databases
monitoring: for tools like Grafana and Prometheus
devops: for CI/CD components like Jenkins

This organization not only brings clarity but also makes it easier to:

Apply RBAC policies
Clean up projects without risking unrelated resources
Restart or rebuild environments independently

Step 1: Cleanup

I decided to clean up my Minikube environment completely, retaining only what was essential:

Deleted all user-created namespaces:

   kubectl delete namespace web database prometheus

Cleaned up leftover Prometheus and Helm resources in the default namespace:

   kubectl get configmap,secrets,serviceaccounts -n default | grep prometheus
   kubectl delete serviceaccount prometheus-grafana prometheus-kube-prometheus-alertmanager \
   prometheus-kube-prometheus-operator prometheus-kube-prometheus-prometheus \
   prometheus-kube-state-metrics prometheus-prometheus-node-exporter -n default

Verified only Minikube system namespaces remained:

   kubectl get namespaces

Output:

   default
   kube-node-lease
   kube-public
   kube-system
   kubernetes-dashboard
   monitoring (for Grafana)

Step 2: Planning for the Future

Going forward, every component will live in its own namespace:

Grafana stays in monitoring
Prometheus will be reinstalled in a clean prometheus namespace
Future apps like web1, web2, and web3 will get their own namespaces

This structure makes it far easier to maintain and scale your Kubernetes environment, even when working locally with Minikube.

Final Thoughts

What started as a fun experiment quickly turned into a lesson in Kubernetes best practices. If you’re serious about learning Kubernetes and DevOps, you should adopt clean practices early. Start with clear naming conventions, separate namespaces, and regular cleanup.

Because the only thing worse than a crashed pod is a cluster where you don’t know why it crashed—or even who it belonged to.