Warrior, now that you understand Pods → Deployments → Services, the next important concept is Namespaces.
Namespaces become extremely useful when your Kubernetes cluster starts containing many applications, teams, or environments.
A Namespace is a logical partition inside a Kubernetes cluster.
Think of your Kubernetes cluster as a large apartment building:
Kubernetes Cluster
│
┌────────────────┼────────────────┐
│ │ │
dev staging prod
│ │ │
┌───┴───┐ ┌───┴───┐ ┌───┴───┐
│ │ │ │ │ │
Pods Services Pods Services Pods ServicesInstead of putting everything into one giant pool, you can organize resources into namespaces.
For example:
Cluster
│
├── development
│ ├── frontend
│ ├── backend
│ └── redis
│
├── staging
│ ├── frontend
│ ├── backend
│ └── redis
│
└── production
├── frontend
├── backend
└── redisImagine your company has:
100 applications
20 teams
3 environmentsWithout namespaces:
cluster
├── frontend
├── backend
├── api
├── redis
├── postgres
├── frontend
├── backend
├── api
...Things quickly become difficult to manage.
With namespaces:
dev
├── frontend
├── backend
└── redis
staging
├── frontend
├── backend
└── redis
production
├── frontend
├── backend
└── redisMuch easier.
Namespaces help with:
This is very important.
Suppose:
Kubernetes Cluster
│
├── dev namespace
├── staging namespace
└── production namespaceThey are still inside the same Kubernetes cluster.
It is NOT:
Cluster 1 → Dev
Cluster 2 → Staging
Cluster 3 → ProductionNamespaces are logical boundaries.
For stronger isolation, organizations may use separate clusters, cloud accounts/projects/subscriptions, or other infrastructure boundaries.
Run:
kubectl get namespacesor:
kubectl get nsYou'll commonly see namespaces such as:
NAME STATUS
default Active
kube-system Active
kube-public Active
kube-node-lease ActiveLet's understand them.
default#This is where resources go if you don't specify a namespace.
For example:
kubectl create deployment nginx --image=nginxwill normally create the Deployment in:
defaultkube-system#Contains Kubernetes/system components.
For example:
kubectl get pods -n kube-systemYou may see things such as:
coredns
kube-proxydepending on your Kubernetes distribution.
Don't randomly delete things from kube-system.
kube-public#A namespace intended for resources that should be publicly readable across the cluster.
It's not commonly where application workloads are deployed.
kube-node-lease#Used for node heartbeat/lease information.
You generally don't interact with this directly during normal application development.
You can create one imperatively:
kubectl create namespace developmentCheck:
kubectl get namespacesYou should see:
development ActiveKubernetes is fundamentally declarative, so YAML is often preferred.
Create:
apiVersion: v1
kind: Namespace
metadata:
name: developmentSave as:
namespace.yamlThen:
kubectl apply -f namespace.yamlCheck:
kubectl get nsSuppose we create:
developmentNow create a Deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: development
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80Notice:
namespace: developmentThis tells Kubernetes:
Create this Deployment inside the development namespace.
Apply:
kubectl apply -f deployment.yamlNow:
kubectl get deployments -n developmentOutput:
NAME READY UP-TO-DATE AVAILABLE
nginx 2/2 2 2And:
kubectl get pods -n development-n Means Namespace#This command:
kubectl get podsmeans:
Get Pods from the current/default namespaceUsually:
defaultBut:
kubectl get pods -n developmentmeans:
Get Pods from development namespaceSimilarly:
kubectl get services -n developmentkubectl get deployments -n developmentkubectl get all -n developmentUse:
kubectl get pods -A-A means:
--all-namespacesFor example:
NAMESPACE NAME READY
default nginx 1/1
development backend-xxx 1/1
development frontend-xxx 1/1
kube-system coredns-xxx 1/1
kube-system kube-proxy-xxx 1/1This is a very useful troubleshooting command.
Many Kubernetes resources belong to a namespace.
For example:
Pod
Deployment
ReplicaSet
Service
ConfigMap
Secret
JobSo you can have:
development
└── backend
production
└── backendBoth can have the same name:
backendbecause their full identity is effectively:
development/backend
production/backendThis is allowed:
development
└── api
staging
└── api
production
└── apiYou can run:
kubectl get deployment api -n developmentand:
kubectl get deployment api -n productionThese are different resources.
This is extremely useful for environments.
Typing:
-n developmentevery time can become annoying.
You can change your current context's default namespace:
kubectl config set-context --current --namespace=developmentNow:
kubectl get podswill look in:
developmentinstead of:
defaultCheck your context:
kubectl config current-contextYou can also inspect:
kubectl config get-contextsThis is where Namespaces become especially interesting.
Suppose we have:
development
│
├── backend
│
└── backend-serviceThe Service DNS name can be:
backend-service.development.svc.cluster.localInside the same namespace, you can usually simply use:
http://backend-serviceFrom another namespace, you can use:
http://backend-service.developmentor the full DNS name:
http://backend-service.development.svc.cluster.localSuppose:
development
└── frontend
production
└── backend
└── backend-serviceThe frontend could communicate with:
backend-service.production.svc.cluster.localConceptually:
development
┌──────────────┐
│ frontend │
└──────┬───────┘
│
│ DNS
▼
production
┌──────────────────┐
│ backend-service │
└────────┬─────────┘
│
▼
backend PodsHowever, whether traffic is actually allowed can depend on NetworkPolicies.
We'll cover that later.
This is a common interview trap.
❌ Incorrect:
Namespace completely isolates applications from each other.
Better:
Namespace provides logical organization and a scope for many Kubernetes resources, but it is not by itself a strong security boundary.
Security can involve:
Namespace
+
RBAC
+
NetworkPolicy
+
ResourceQuota
+
LimitRange
+
Cluster/infrastructure isolationWe'll learn RBAC and NetworkPolicy later.
Suppose you have:
development
productionYou could configure RBAC so that:
Developer
↓
Can access developmentbut:
Developer
X
Cannot modify productionConceptually:
Kubernetes
│
┌──────────┴──────────┐
│ │
development production
│ │
Developer Admin
access accessThis is one of the major reasons namespaces are useful.
Namespaces can also have resource quotas.
Imagine:
developmentshouldn't consume the entire cluster.
You could configure something like:
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: development
spec:
pods: "10"
requests.cpu: "2"
requests.memory: 4GiConceptually:
development namespace
Maximum:
-------------------
Pods = 10
CPU = 2 cores
Memory = 4 GB
-------------------This prevents one namespace from consuming unlimited resources.
We'll study resource management in detail in Chapter 13.
LimitRange can define default or allowed resource requests/limits for containers within a namespace.
For example:
Every container:
CPU request = default 100m
Memory request = default 128MiThis helps enforce sensible resource usage.
Again, we'll cover this properly in the resource-management chapter.
Imagine your application:
Next.js
Node.js
Redis
PostgreSQLYou could organize:
Kubernetes Cluster
│
├── development
│ ├── nextjs
│ ├── node-api
│ └── redis
│
├── staging
│ ├── nextjs
│ ├── node-api
│ └── redis
│
└── production
├── nextjs
├── node-api
└── redisThen:
development/node-api
staging/node-api
production/node-apican all have the same resource name.
A typical organization might have:
Kubernetes Cluster
│
┌─────────────────────┼─────────────────────┐
│ │ │
DEV STAGING PROD
│ │ │
┌────┼────┐ ┌────┼────┐ ┌────┼────┐
│ │ │ │ │ │ │ │ │
FE API Redis FE API Redis FE API RedisBut in larger production systems, you may instead see:
Dev Cluster
│
└── dev namespaces
Staging Cluster
│
└── staging namespaces
Production Cluster
│
└── production namespacesThe second approach gives stronger isolation, at the cost of more infrastructure and management complexity.
Let's practice.
kubectl create namespace devkubectl create deployment nginx \
--image=nginx \
-n devkubectl get deployments -n devkubectl get pods -n devkubectl describe deployment nginx -n devkubectl get pods -Akubectl config set-context --current --namespace=devNow:
kubectl get podsshould show the Pod from dev.
| Command | Purpose |
|---|---|
kubectl get ns |
List namespaces |
kubectl create ns dev |
Create namespace |
kubectl get pods -n dev |
Pods in namespace |
kubectl get all -n dev |
Resources in namespace |
kubectl get pods -A |
Pods across all namespaces |
kubectl delete ns dev |
Delete namespace |
kubectl config set-context --current --namespace=dev |
Set default namespace |
kubectl config current-context |
Show current context |
⚠️ Be careful with:
kubectl delete namespace devDeleting a namespace deletes the namespaced resources inside it.
Answer:
A Namespace is a logical partition within a Kubernetes cluster used to organize and scope resources, support access control, resource quotas, and environment or team separation.
For:
No.
Multiple namespaces can exist inside the same cluster.
Yes.
For example:
dev/backend
prod/backendare different resources.
kubectl get pods -n productionkubectl get pods -ANo.
RBAC, NetworkPolicy, quotas, infrastructure isolation, and other controls may be required.
You've now learned:
Kubernetes Cluster
│
├── Namespace
│ │
│ ├── Deployment
│ │ │
│ │ └── ReplicaSet
│ │ │
│ │ └── Pods
│ │ │
│ │ └── Containers
│ │
│ └── Service
│ │
│ └── Routes traffic → PodsAnd environments can be organized as:
Cluster
│
├── dev
│ ├── frontend
│ ├── backend
│ └── redis
│
├── staging
│ ├── frontend
│ ├── backend
│ └── redis
│
└── production
├── frontend
├── backend
└── redisNamespace = logical folder for Kubernetes resources.
This is where Kubernetes starts becoming much more useful for real applications.
We'll learn how to handle things like:
DATABASE_URL
API_URL
NODE_ENV
REDIS_HOST
JWT_SECRET
API_KEYwithout hardcoding them inside your application or Docker image.
Mark it as complete to track your mastery.