Kubernetes Namespaces

The logical isolation layer that turns a single cluster into multiple virtual clusters. Namespaces provide scope boundaries for resources, DNS, quotas, and access control — essential for multi-tenancy and team-scale Kubernetes operations. Synthesized from CKA Day 10 — Kubernetes Namespace Explained.

What Is a Namespace?

A Namespace is a Kubernetes abstraction that partitions cluster resources into isolated groups. It is the primary mechanism for:

• Resource scoping: Object names only need to be unique within a Namespace
• Multi-tenancy: Multiple teams, projects, or environments share one cluster without name collisions
• Resource governance: Apply CPU/memory quotas and limit ranges per boundary
• Access control: Bind RBAC Roles to specific Namespaces
• Service discovery boundaries: DNS names naturally include the Namespace

Important: Namespaces do not provide automatic network isolation. By default, a Pod in namespace-a can communicate with a Pod in namespace-b. Network isolation requires NetworkPolicies. Source: CKA Day 10

---

The Four Default Namespaces

Every Kubernetes cluster boots with these system-reserved Namespaces:

Namespace	Purpose	Typical Contents
default	Catch-all for user workloads	User Pods, Deployments, Services that don’t specify a Namespace
kube-system	Control plane and system addons	CoreDNS, kube-proxy, CNI plugins, metrics-server, etcd (if stacked)
kube-public	Publicly readable cluster metadata	cluster-info ConfigMap (consumed by kubeadm and discovery tools)
kube-node-lease	Node heartbeat mechanism	Lease objects per node for lightweight health reporting (since v1.17)

Best Practice: Never deploy application workloads into kube-system. Treat it as read-only system territory. Source: CKA Day 10

---

Namespace-Scoped vs Cluster-Scoped Resources

Understanding this distinction is critical for the CKA exam and RBAC design:

Scope	Resource Types
Namespace-scoped	Pod, Deployment, ReplicaSet, Service, ConfigMap, Secret, Job, CronJob, NetworkPolicy, ResourceQuota, LimitRange, Role, RoleBinding
Cluster-scoped	Node, PersistentVolume, Namespace, ClusterRole, ClusterRoleBinding, StorageClass, CustomResourceDefinition

Implication: You cannot create a Node inside a Namespace, and you cannot nest a Namespace inside another Namespace. When writing RBAC, ClusterRoles grant permissions across all Namespaces, while Roles are bound to a single Namespace. Source: CKA Day 10

---

Creating and Managing Namespaces

Imperative (Exam Speed)

# Create
kubectl create namespace dev
kubectl create ns staging   # Short form
 
# Delete (cascades and deletes all namespace-scoped resources)
kubectl delete namespace dev
 
# List
kubectl get namespaces
kubectl get ns

Declarative (GitOps-Friendly)

apiVersion: v1
kind: Namespace
metadata:
  name: prod
  labels:
    env: production
    team: platform

kubectl apply -f namespace-prod.yaml

Setting a Persistent Default Namespace

Avoid typing -n on every command by setting the Namespace in your current kubeconfig context:

kubectl config set-context --current --namespace=dev
 
# Verify
kubectl config view --minify | grep namespace:

Caveat: This is local to your kubeconfig. CI/CD pipelines, teammates, and new terminals still need explicit -n flags or context management. Source: CKA Day 10

---

Cross-Namespace Service Discovery

Services are automatically assigned a DNS name that includes their Namespace:

<service-name>.<namespace>.svc.cluster.local

This enables clean microservice communication across team boundaries:

# From any Pod in any Namespace
# Reach the "payments" Service in the "backend" Namespace
curl http://payments.backend.svc.cluster.local:8080
 
# Within the same Namespace, the short name resolves automatically
curl http://payments:8080

Design Pattern: Front-end Pods in web Namespace talk to back-end Pods in api Namespace using FQDNs. This decouples deployment cadences and RBAC boundaries while maintaining network connectivity. Source: CKA Day 10

---

Resource Governance: Quotas and Limits

Namespaces are the enforcement boundary for two governance objects:

ResourceQuota

Caps aggregate resource consumption for the entire Namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"
    services: "10"

LimitRange

Sets default, minimum, and maximum resource constraints for individual Pods/Containers:

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limits
  namespace: dev
spec:
  limits:
    - default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      type: Container

Without Namespaces, these controls cannot be applied granularly to teams or environments. Source: CKA Day 10

---

Network Isolation with namespaceSelector

As mentioned, Namespaces alone do not block traffic. Use NetworkPolicy with namespaceSelector to achieve true isolation:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring-only
  namespace: prod
spec:
  podSelector: {}          # Applies to all Pods in prod
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: monitoring

This policy allows ingress only from Pods in the monitoring Namespace. All other cross-namespace traffic is denied (assuming the cluster’s CNI supports NetworkPolicies, e.g., Calico, Cilium, or default on EKS/GKE/AKS). Source: CKA Day 10

---

Common Namespace Patterns

Pattern	Description	Example Names
Environment-based	Isolate dev, staging, and prod on one cluster	dev, staging, prod
Team-based	Each engineering team owns a Namespace with independent RBAC	team-frontend, team-backend, team-data
Project-based	One Namespace per application or service family	webapp, billing-service, analytics-pipeline
Tenant-based	SaaS multi-tenancy with strong quotas per customer	tenant-acme, tenant-globex

Anti-pattern: Creating a Namespace for every single Pod or microservice. This explodes RBAC and quota management overhead without proportional benefit. Group related workloads into a meaningful boundary. Source: CKA Day 10

---

CKA Exam Relevance

Namespaces appear across multiple exam domains:

• Cluster Architecture (~25%): Know the four default Namespaces and what lives in kube-system
• Workloads & Scheduling (~15%): Create Deployments, Pods, and Jobs in specific Namespaces
• Services & Networking (~20%): Understand cross-namespace DNS resolution and FQDNs
• Troubleshooting (~30%): Debug why a Pod can’t reach a Service — check if it’s in the wrong Namespace

Essential Exam Commands

# Create a Namespace and deploy into it
kubectl create ns exam-task-1
kubectl run nginx --image=nginx -n exam-task-1
kubectl expose pod nginx --port=80 -n exam-task-1
 
# Verify resources are in the correct Namespace
kubectl get all -n exam-task-1
 
# Check current context Namespace
kubectl config view --minify --output 'jsonpath={..namespace}'

Trap: The exam provides multiple clusters and contexts. Always verify you are in the right Namespace before creating resources. Use kubectl config set-context --current --namespace=<ns> if the task specifies one. Source: CKA Day 10

---

Sources

• CKA Day 10 — Kubernetes Namespace Explained

Related Pages

• Kubernetes Services — namespace-scoped networking, DNS, and Endpoints
• Kubernetes Service Types — ClusterIP, NodePort, LoadBalancer, ExternalName
• Pod Fundamentals — namespace-scoped smallest deployable unit
• Deployment, ReplicaSet & Replication Controller — namespace-scoped workload controllers
• Kubernetes Architecture — control plane components in kube-system
• CKA Certification — exam structure and domain weightings
• CKA Study Roadmap — Day 10 in the 40-day learning plan
• Why Kubernetes? — multi-tenancy and resource governance benefits
• Tech Tutorials with Piyush — course creator

---

Tags: kubernetes namespace multi-tenancy rbac resource-quota limit-range network-policy cka devops service-discovery