SRJahirTech

Working Within a Namespace

# Run a pod in the development namespace
kubectl run nginx --image=nginx -n development

# List pods in development namespace
kubectl get pods -n development

# List pods in ALL namespaces
kubectl get pods --all-namespaces
# Or shorter:
kubectl get pods -A

Typing -n namespace-name for every command gets old quickly. You can set a default namespace for your current context so you do not have to keep specifying it.

# Set development as your default namespace
kubectl config set-context --current --namespace=development

# Verify
kubectl config view --minify | grep namespace

# Now kubectl commands work in development namespace by default
kubectl get pods   # Same as kubectl get pods -n development

# Switch back to default
kubectl config set-context --current --namespace=default

ResourceQuotas — Limiting Total Namespace Usage

Without ResourceQuotas, one team can deploy hundreds of pods and consume all the cluster's CPU and memory, starving every other team. ResourceQuotas set hard limits on total resources consumed within a namespace.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: development
spec:
  hard:
    # Compute resources
    requests.cpu: "4"          # Total CPU requests cannot exceed 4 cores
    requests.memory: 8Gi       # Total memory requests cannot exceed 8GB
    limits.cpu: "8"            # Total CPU limits cannot exceed 8 cores
    limits.memory: 16Gi        # Total memory limits cannot exceed 16GB
    # Object counts
    pods: "20"                 # Maximum 20 pods in this namespace
    services: "10"             # Maximum 10 services
    persistentvolumeclaims: "5" # Maximum 5 PVCs
    secrets: "20"
    configmaps: "20"

kubectl apply -f development-quota.yaml

# Check current quota usage
kubectl describe resourcequota dev-quota -n development

# Try to exceed the quota - Kubernetes will reject the request
kubectl run test-pod --image=nginx -n development  # Works until pod limit is reached

LimitRanges — Default Limits Per Container

ResourceQuotas set limits for the entire namespace. LimitRanges set limits per individual container. The most important use of LimitRanges is setting defaults — because if you have a ResourceQuota that requires every pod to specify resource requests, pods without requests will be rejected. A LimitRange automatically assigns default resource requests and limits so your deployments work even if developers forget to specify them.

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limits
  namespace: development
spec:
  limits:
  - type: Container
    default:           # Applied if container doesn't specify limits
      cpu: "500m"
      memory: "256Mi"
    defaultRequest:    # Applied if container doesn't specify requests
      cpu: "100m"
      memory: "128Mi"
    max:               # Hard maximum any container can request
      cpu: "2"
      memory: "2Gi"
    min:               # Hard minimum (prevents zero-resource pods)
      cpu: "50m"
      memory: "64Mi"

kubectl apply -f development-limits.yaml

kubectl describe limitrange dev-limits -n development

# Now any pod deployed without resource specs gets the defaults automatically
kubectl run auto-limited --image=nginx -n development
kubectl get pod auto-limited -n development -o jsonpath='{.spec.containers[0].resources}'

Cross-Namespace Service Communication

By default, pods in different namespaces can communicate with each other. The DNS name format for cross-namespace communication is: service-name.namespace.svc.cluster.local

# Run a service in the development namespace
kubectl run backend --image=nginx -n development
kubectl expose pod backend --port=80 -n development

# From a pod in the default namespace, reach the development backend
kubectl run test --image=busybox --rm -it -- sh
# Inside the pod:
wget -qO- http://backend.development.svc.cluster.local
# exit

Namespace Best Practices for Teams

In my experience working on real clusters, here is how teams typically organise namespaces. One common pattern is environment-based: dev, staging, and production namespaces, each with tighter ResourceQuotas as you go up. Another pattern is team-based: team-frontend, team-backend, team-data — useful when multiple teams share a cluster and you want to charge back costs per team.

Whatever pattern you choose, always set ResourceQuotas and LimitRanges in every namespace. A single runaway batch job without limits can take down an entire cluster.

Deleting Namespaces Safely

# WARNING: This deletes EVERYTHING in the namespace
kubectl delete namespace development

# Watch the deletion progress
kubectl get ns development -w
# Status will show "Terminating" until all resources are cleaned up

What is Next

Your cluster is now well-organised with namespaces and protected by resource quotas. The next big piece is exposing your applications to the internet in a production-grade way. In Part 8, we cover Ingress Controllers — the proper way to route external HTTP traffic to multiple services, with path-based routing, SSL termination, and virtual hosts, all through a single load balancer.

Frequently Asked Questions

Written by

Suraj Ahir

Cloud & DevOps engineer running four live production services on my own AWS infrastructure. I write everything on this site myself — no ghostwriters, no AI filler.

More about me → GitHub LinkedIn