Namespaces - Kubernetes

What is a Namespace?

A Namespace is a virtual cluster within a single physical Kubernetes cluster. It provides:

Logical isolation of resources
Multi-tenancy on a single cluster
Resource quotas per team or environment
Network policies to control traffic
Different RBAC policies per namespace

Think of namespaces as folders in a filing system:

Kubernetes Cluster
├── default (default namespace)
├── kube-system (Kubernetes system components)
├── kube-public (publicly readable data)
├── development
├── staging
├── production
└── monitoring

Common Namespace Patterns

By Environment

dev/
  ├── web-deployment
  ├── db-service
  └── cache-service

staging/
  ├── web-deployment
  ├── db-service
  └── cache-service

production/
  ├── web-deployment
  ├── db-service
  └── cache-service

By Team

frontend-team/
  ├── web-app
  ├── admin-dashboard
  └── documentation-site

backend-team/
  ├── api-service
  ├── worker-service
  └── scheduler

data-team/
  ├── analytics-engine
  ├── data-pipeline
  └── reporting-service

By Function

appplications/
  ├── web-app
  ├── mobile-api
  └── batch-processor

infrastructure/
  ├── monitoring
  ├── logging
  └── ingress-controller

system/
  ├── CoreDNS
  ├── kube-proxy
  └── storage-provisioner

Creating and Managing Namespaces

Create a Namespace

Imperative:

kubectl create namespace development
kubectl create namespace staging
kubectl create namespace production

Declarative:

apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    environment: dev
 
---
 
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    environment: prod
    backup: daily

List Namespaces

kubectl get namespaces
kubectl get ns

Output:

NAME              STATUS   AGE
default           Active   10d
kube-system       Active   10d
kube-public       Active   10d
kube-node-lease   Active   10d
development       Active   2d
production        Active   1d

Set Default Namespace

Temporarily:

kubectl set-context --current --namespace=development
# Now all commands default to development namespace
 
kubectl get pods  # Shows pods in development

Permanently in kubeconfig:

kubectl config set-context $(kubectl config current-context) --namespace=development

Or use alias:

alias kdev='kubectl -n development'
alias kprod='kubectl -n production'
 
kdev get pods    # development namespace
kprod get pods   # production namespace

Delete a Namespace

kubectl delete namespace development
# This deletes ALL resources in the namespace!

Namespaced vs Cluster-Scoped Resources

Namespaced Resources

Exist within a namespace (most resources):

Pods
Services
Deployments
ConfigMaps
Secrets
Ingress
PersistentVolumeClaims

kubectl api-resources --namespaced=true

Cluster-Scoped Resources

Exist across the entire cluster:

Nodes
PersistentVolumes
Namespaces
ClusterRoles
ClusterRoleBindings
StorageClasses

kubectl api-resources --namespaced=false

DNS with Namespaces

Services across namespaces have different DNS names:

# Same namespace
kubectl run -it myclient --image=ubuntu --namespace=default
 
# Inside pod
curl http://my-service       # Works in default namespace
curl http://my-service.default.svc.cluster.local  # Fully qualified
 
# Cross-namespace
curl http://my-service.production.svc.cluster.local  # Access prod service

Resource Quotas

Limit resource consumption per namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: development
 
---
 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: development
spec:
  hard:
    requests.cpu: "10"          # Max total CPU requests
    requests.memory: "20Gi"     # Max total memory requests
    limits.cpu: "20"            # Max total CPU limits
    limits.memory: "40Gi"       # Max total memory limits
    pods: "100"                 # Max number of Pods
    services.loadbalancers: "2" # Max LoadBalancer services
    services.nodeports: "5"     # Max NodePort services

Check quota usage:

kubectl describe quota -n development

Output:

Namespace       : development
Resource        : requests.cpu
Used            : 2500m
Hard            : 10
---
Resource        : requests.memory
Used            : 5Gi
Hard            : 20Gi

Network Policies

Control traffic between namespaces:

# Allow traffic only from frontend namespace to backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      tier: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend    # Only pods in frontend namespace
    ports:
    - protocol: TCP
      port: 8080

Label a namespace:

kubectl label namespace frontend name=frontend
kubectl label namespace backend name=backend

Multi-Tenant Example

Setup

# Create namespaces for each team
kubectl create namespace team-alpha
kubectl create namespace team-beta
kubectl create namespace team-gamma
 
# Label them
kubectl label namespace team-alpha team=alpha
kubectl label namespace team-beta team=beta
kubectl label namespace team-gamma team=gamma

Resource Quotas per Team

# team-alpha-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "5"
    requests.memory: "10Gi"
    pods: "50"
 
---
 
# team-beta-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-beta
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "16Gi"
    pods: "100"

RBAC per Team

# Each team can only manage their own namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: team-admin
  namespace: team-alpha
rules:
- apiGroups: ["", "apps", "batch"]
  resources: ["*"]
  verbs: ["*"]
 
---
 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-admin
  namespace: team-alpha
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: team-admin
subjects:
- kind: Group
  name: team-alpha@company.com
  apiGroup: rbac.authorization.k8s.io

Best Practices

✅ Separate environments

dev/ → rapid iteration
staging/ → QA testing
production/ → customer-facing

✅ Use meaningful names

metadata:
  name: production
  labels:
    environment: prod
    tier: critical
    team: platform

✅ Set resource quotas

Prevents runaway resource consumption
Ensures fair resource allocation

✅ Use Network Policies

Default deny all traffic
Explicitly allow what you need

✅ Automate namespace creation Use GitOps tools (ArgoCD, Flux) to manage namespaces

❌ Don't put everything in default namespace

Makes organization difficult
Harder to manage permissions

❌ Don't create too many namespaces

Creates management overhead
Limits resource sharing efficiency