Day 30 of 90 Days of DevOps Challenge: Kubernetes Namespace

Yesterday, I explored Kubernetes Service types beyond cloud LoadBalancers. I learned how NodePort exposes an app on a fixed port for on-prem clusters and how ClusterIP provides internal-only communication with a stable virtual IP. Writing real YAML, opening firewall ports, and comparing Service use-cases gave me a clearer picture of Kubernetes networking.

Today I’ll explore Namespaces. They often look simple at first glance, but they underpin multi-tenant, multi-environment clusters. I spent the day creating, querying, and deleting namespaces and deploying resources inside them to see how isolation works.

1. What Exactly Is a Namespace?

Think of a namespace as a virtual cluster inside the physical cluster:

frontend-app-pods   -> frontend namespace
backend-app-pods    -> backend namespace
database-pods       -> database namespace

• Resource grouping: Pods, Services, ConfigMaps, and even RBAC rules live in their own namespace.

• Isolation: Actions in one namespace don’t affect resources in another.

• Garbage-collection safety: Deleting a namespace wipes everything inside it handy for clean tear-downs, but dangerous in production if misused.

2. Listing and Inspecting Namespaces

kubectl get ns                      # list all namespaces
kubectl get pods -n kube-system     # list system pods
# Omitting -n defaults to the 'default' namespace

NOTE: Keep kube-system and kube-public separate—never delete them.

3. Creating Namespaces: Two Approaches

A. CLI — Quick

kubectl create ns zerotoroot-ns

B. YAML — Declarative and Repeatable

Version: v1
kind: Namespace
metadata:
  name: zerotoroot-ns-2

kubectl apply -f namespace.yaml

4. Deploying Resources Inside a Namespace

Below is a single manifest that defines a Namespace, a Pod, and a Service scoped to that namespace:

---
apiVersion: v1
kind: Namespace
metadata:
  name: zerotoroot-ns
---
apiVersion: v1
kind: Pod
metadata:
  name: javawebapp-pod
  namespace: zerotoroot-ns      # ← scoping happens here
  labels:
    app: javawebapp
spec:
  containers:
    - name: javawebapp-container
      image: zerotoroot/javawebapp
      ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: javawebapp-svc
  namespace: zerotoroot-ns
spec:
  type: LoadBalancer
  selector:
    app: javawebapp
  ports:
    - port: 80
      targetPort: 8080

Apply and explore:

kubectl apply -f full-stack.yaml
kubectl get ns
kubectl get pods -n zerotoroot-ns
kubectl get svc  -n zerotoroot-ns
kubectl get all  -n zerotoroot-ns

5. Cleaning Up Safely

kubectl delete ns ashokit-ns

NOTE: that single command deletes every object in the namespace. Pods, Services, ConfigMaps, even Secrets. Always double-check the name before you hit Enter!

Final Thoughts

Namespaces turned out to be more than just labels. they’re hard boundaries that keep teams and environments from stepping on each other. By automating namespace creation and scoping resources via YAML, I can spin up or tear down isolated stacks in minutes. Layered with yesterday’s knowledge of Service types, I’m starting to see how large organizations safely run dev, staging, and prod workloads side-by-side in the same cluster. Tomorrow, I’ll move on to Deployments and rolling updates to make application lifecycles rock-solid. Stay tuned!