Kubernetes Namespaces

In Kubernetes, Namespaces provide a logical way to isolate and organize groups of resources within a single cluster. They are especially useful in environments where multiple teams or projects share the same cluster, allowing separation and management of resources independently.

Each resource in a Namespace must have a unique name, but resources across different Namespaces can share the same name without conflict.

Default Kubernetes Namespaces
When you create a Kubernetes cluster, it comes with four built-in Namespaces:

default

kube-node-lease

kube-public

kube-system

To view all available Namespaces, use:

kubectl get namespaces
You’ll see the four default Namespaces listed.

Bonus: Kubernetes Dashboard Namespace (Minikube Specific)
When you install Minikube, an additional Namespace called kubernetes-dashboard is automatically created.
This Namespace is specific to Minikube and not present in standard Kubernetes clusters.

1. kube-system The kube-system Namespace contains core system components and processes managed by Kubernetes itself. It includes system-level Pods like:

kube-dns

kube-proxy

etcd

kube-apiserver

This Namespace is not meant for user-created workloads. Developers should avoid creating or modifying resources in kube-system.

1. kube-public The kube-public Namespace holds publicly accessible cluster information. It contains a ConfigMap that stores details about the cluster, which can be accessed even without authentication.

To view this information:

kubectl cluster-info
This command retrieves data stored in the kube-public Namespace.

1. kube-node-lease The kube-node-lease Namespace was introduced to improve cluster performance and scalability. It maintains Node lease objects, which record the heartbeat and availability status of each Node.

Each Node has its own lease object, helping the Kubernetes control plane efficiently detect Node failures.

1. default The default Namespace is where Kubernetes places all resources if no Namespace is explicitly specified. When you create a Pod, Service, or ConfigMap without assigning a Namespace, it’s automatically placed in default.

Creating Namespaces
You can create new Namespaces in two ways:

1. Using CLI Commands Run the following command to create a Namespace named my-ns:

kubectl create namespace my-ns
To verify:

kubectl get namespaces
You’ll see my-ns listed among the available Namespaces.

1. Using a Configuration File It’s often better to define Namespaces using a YAML configuration file — this provides version control and traceability within your infrastructure code.

Example:

apiVersion: v1
kind: Namespace
metadata:
name: development
labels:
name: development
Apply the file:

kubectl create -f namespace.yaml
Creating Components in the Default Namespace
When no Namespace is specified, Kubernetes automatically creates resources in the default Namespace.

Example ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
data:
db_url: my-service.database
Apply the ConfigMap:

kubectl apply -f my-config-map.yaml
To verify which Namespace it belongs to:

kubectl get configmap -n default
Or to view detailed YAML output:

kubectl get configmap my-configmap -n default -o yaml
You’ll see that the Namespace field is set to default.

Creating Components in a Custom Namespace
You can assign resources to a specific Namespace in two ways:

1. Specifying Namespace via CLI Add the --namespace flag when applying the resource file:

kubectl apply -f my-config-map.yaml --namespace=my-ns
Make sure the Namespace (my-ns) already exists, or you’ll get an error.

1. Specifying Namespace in the YAML File Include the Namespace directly in the metadata section:

apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
namespace: my-ns
data:
db_url: my-service.database
Apply the file:

kubectl apply -f my-config-map.yaml
Then verify:

kubectl get configmap -n my-ns -o yaml
The output will confirm that the ConfigMap now belongs to the my-ns Namespace.

Changing the Active Namespace
By default, your active Namespace is default.
To easily switch between Namespaces, use the kubens tool from kubectx.

Install kubectx and kubens
sudo snap install kubectx --classic
View All Namespaces
kubens
The active Namespace will appear highlighted in green.

Switch to Another Namespace
kubens my-ns
Now, your active Namespace is set to my-ns, meaning any subsequent resource creation (without specifying a Namespace) will default to this Namespace.

Conclusion
Kubernetes Namespaces are essential for managing complex, multi-team, or multi-project environments within a single cluster.
They offer logical separation, resource isolation, and simplified access control — making them a fundamental part of any production-grade Kubernetes architecture.