Kubernetes namespaces: What they are and how to use them

Namespaces provide logical separation within a Kubernetes cluster. They allow multiple teams or environments to share the same physical cluster while keeping their resources isolated from each other. You can apply resource quotas and access policies per namespace, making it practical to run dev, staging, and production workloads in the same cluster without them interfering with each other.

What are Kubernetes namespaces?

A namespace is a virtual cluster within a physical cluster. Resources inside one namespace are invisible to resources in another unless you explicitly reference them by their full DNS name. Every Kubernetes cluster starts with four namespaces:

• default : where your resources go if you do not specify a namespace
• kube-system : cluster components like the API server, scheduler, and CoreDNS
• kube-public : publicly readable resources, rarely used directly
• kube-node-lease : node heartbeat objects used for availability detection

Viewing and creating namespaces

List all namespaces in the cluster:

1kubectl get ns

Expected output:

1NAME              STATUS   AGE
2default           Active   5d
3kube-node-lease   Active   5d
4kube-public       Active   5d
5kube-system       Active   5d

Create a new namespace:

1kubectl create namespace dev

Verify it was created:

1kubectl get ns dev

Expected output:

1NAME   STATUS   AGE
2dev    Active   5s

Running resources in a specific namespace

Create a pod in the default namespace:

1kubectl run nginx --image=nginx

Create a pod with the same name in the dev namespace:

1kubectl run nginx --image=nginx -n dev

Verify the pod is running in the dev namespace:

1kubectl get pods -n dev

Expected output:

1NAME    READY   STATUS    RESTARTS   AGE
2nginx   1/1     Running   0          10s

Both pods can exist simultaneously because they are in different namespaces. This is useful when running different versions of the same application in separate environments.

Namespace-per-environment pattern

The most common real-world use of namespaces is separating environments within the same cluster. Rather than running separate clusters for dev, staging, and production, teams create one namespace per environment:

1kubectl create namespace dev
2kubectl create namespace staging
3kubectl create namespace production

This approach keeps infrastructure costs low while still maintaining separation. The key is combining namespaces with ResourceQuotas to prevent one environment from consuming all cluster resources.

Limiting resources with ResourceQuota

A ResourceQuota sets hard limits on how much CPU, memory, and how many objects a namespace can use. Without quotas, a runaway process in dev could starve production of resources.

Apply a ResourceQuota to the dev namespace:

1apiVersion: v1
2kind: ResourceQuota
3metadata:
4  name: dev-quota
5  namespace: dev
6spec:
7  hard:
8    requests.cpu: "2"
9    requests.memory: 4Gi
10    limits.cpu: "4"
11    limits.memory: 8Gi
12    pods: "20"

1kubectl apply -f dev-quota.yaml

Verify the quota is applied:

1kubectl get resourcequota -n dev

Expected output:

1NAME        AGE   REQUEST                                      LIMIT
2dev-quota   5s    pods: 0/20, requests.cpu: 0/2, ...          limits.cpu: 0/4, ...

Switching namespace context

By default, kubectl commands operate on the default namespace. Specifying -n <namespace> every time gets repetitive. Set a default namespace for your current context:

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

Confirm the change:

1kubectl config view --minify | grep namespace

Expected output:

1    namespace: dev

Now kubectl get pods will show pods from the dev namespace without needing -n dev.

Deleting a namespace

Check what is in a namespace before deleting:

1kubectl get all -n dev

Delete the namespace:

1kubectl delete namespace dev