8th Week :- What Are Namespaces and ClusterIP & Why They Matter

📌 What is a Namespace?

A namespace in Kubernetes is like a virtual cluster inside a physical cluster. It allows you to divide cluster resources between multiple users, teams, or environments.

Analogy: Think of a single Kubernetes cluster as a building. Each namespace is a separate room. The rooms share the building, but what's inside them is separate.

---

🎯 Why Use Namespaces?

Here’s why namespaces are extremely useful:

---

🛠️ How Namespaces Work in Kubernetes

When you create a namespace, it becomes a logical boundary. Any resource created inside it will only interact with other resources in the same namespace unless explicitly configured otherwise.

For example:

• A Service in namespace dev won't find a Pod in namespace prod.

• You can have the same name for different resources as long as they're in different namespaces.

---

📂 Default Namespaces in Kubernetes

Kubernetes comes with a few namespaces by default:

---

🧪 Example Use Cases

• dev, staging, prod → isolate environments.

• team-a, team-b → assign different namespaces for each team.

• qa-namespace → for testing automation tools without interfering with production.

---

🧾 Common Namespace Commands (with Examples)

Let’s walk through practical kubectl commands:

---

✅ 1. View All Namespaces

kubectl get namespaces

---

🏗️ 2. Create a Namespace

kubectl create namespace dev

---

🚀 3. Deploy in a Specific Namespace

kubectl apply -f app.yaml -n dev

If your manifest doesn't specify a namespace, it defaults to default.

---

🔍 4. View Resources in a Namespace

kubectl get pods -n dev
kubectl get services -n staging

---

🧹 5. Delete a Namespace (⚠️ This deletes all resources in it!)

kubectl delete namespace dev

---

📌 6. Set a Default Namespace for kubectl (Optional)

kubectl config set-context --current --namespace=dev

Now you don’t need -n dev in every command.

---

📋 7. View YAML of a Namespace

kubectl get namespace dev -o yaml

---

📦 8. Create Namespace via YAML

# dev-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: dev

kubectl apply -f dev-namespace.yaml

---

⚖️ Namespaces vs. Labels – What’s the Difference?

---

🚧 Limitations of Namespaces

• Not all resources are namespaced (e.g., nodes, persistentvolumes).

• Cross-namespace communication requires explicit configuration.

• Namespace doesn’t provide network isolation by default (needs additional tools like NetworkPolicies).

---

📦 Why Use ClusterIP?

• You have a backend (like a database or an API service) that should only be accessed by other services or pods.

• You want a stable DNS name and IP to reach your Pods (which might die/restart).

• It load balances traffic internally to healthy Pod endpoints.

---

🛠️ How ClusterIP Works (Step-by-Step)

1. You create a Deployment (e.g., a Node.js app).

2. You expose it using a Service of type ClusterIP.

3. Kubernetes assigns a stable virtual IP address (ClusterIP) to that service.

4. DNS is auto-generated (e.g., my-service.default.svc.cluster.local).

5. Other Pods can access the service using:

   • the ClusterIP (e.g., 10.96.182.1)

   • the DNS name (recommended)

⚠️ The ClusterIP is only reachable from within the cluster. You can’t curl it from your local machine directly.

---

📄 Sample Deployment + ClusterIP Service

Here’s a simple example using an NGINX deployment.

1. nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80

2. nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80

Apply both:

kubectl apply -f nginx-deployment.yaml
kubectl apply -f nginx-service.yaml

---

🔍 How to Find ClusterIP

Once applied, use this command:

kubectl get service nginx-service

Output:

NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
nginx-service    ClusterIP   10.96.182.1     <none>        80/TCP    5m

🟢 10.96.182.1 is the ClusterIP — accessible only from inside the cluster.

---

🌐 What is the URL for ClusterIP?

The URL follows this DNS format inside Kubernetes:

<service-name>.<namespace>.svc.cluster.local

So in our case:

http://nginx-service.default.svc.cluster.local

✅ This URL will resolve to the ClusterIP and forward traffic to your NGINX pods (load-balanced).

You can test it from another pod inside the cluster:

kubectl run test-pod --rm -i -t --image=busybox -- /bin/sh

Then:

wget -qO- nginx-service.default.svc.cluster.local

If you see HTML, it means it worked!

---

🔄 How ClusterIP is Resolved Behind the Scenes

1. Kube-DNS/CoreDNS maintains records like:

    nginx-service.default.svc.cluster.local → 10.96.182.1
   

2. When your app sends a request to the service DNS, Kubernetes resolves it to the ClusterIP.

3. The ClusterIP is then routed via iptables or IPVS rules to the correct backend pods.

---

🔥 Bonus: Port Forward for Local Access

Since ClusterIP is internal, you can't access it from your PC. But you can port-forward like this:

kubectl port-forward service/nginx-service 8080:80

Now you can open:

http://localhost:8080

✅ This is useful for debugging internal services locally.

---

❗ Key Points Summary

---

🧠 Real-World Use Cases