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 and CKA Day 25 — Kubernetes Service Account.

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. Contains a default ServiceAccount with minimal permissions.
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. A RoleBinding can also reference a ClusterRole to grant cluster-level permissions scoped to a single Namespace — a common pattern for granting admin, edit, or view access within a team boundary. Source: CKA Day 10 Source: CKA Day 22

The RoleBinding + ClusterRole Pattern in Practice

Instead of creating a separate Role in every Namespace, define permissions once in a ClusterRole and bind them per-Namespace with RoleBindings:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-backend-edit
  namespace: backend
subjects:
- kind: Group
  name: backend-developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

This gives the backend-developers group full edit access — but only inside the backend Namespace. The same ClusterRole can be bound in other Namespaces for other teams, keeping RBAC definitions DRY and maintainable. Source: CKA Day 24

---

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

Day 16 demonstrates the Pod-level half of this governance story: container requests and limits determine how individual Pods reserve and cap CPU/memory, while ResourceQuota and LimitRange apply those expectations across a Namespace. A demo Namespace such as mem-example is useful for safely stress-testing memory requests, memory limits, OOMKilled, and Pending resource failures. Source: CKA Day 16

Policy-based governance: ResourceQuota and LimitRange are reactive guardrails — they don’t stop a team from creating a Namespace without a quota. Policy engines like Kyverno close that loop at the admission layer: a ClusterPolicy can require every new Namespace to carry a ResourceQuota, or block Pods missing requests/limits in specific Namespaces. In large multi-tenant clusters (one Namespace per microservice team), this is how governance rules are enforced organization-wide instead of by convention. Source: Enforce Kubernetes Security with Kyverno

---

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 Source: CKA Day 26

---

Helm Releases and Namespace Scoping

Helm releases are Namespace-scoped — the same release name can exist in multiple Namespaces without collision. This enables clean multi-environment deployment patterns:

# Install the same chart into three Namespaces
helm install frontend ./webapp -n dev
helm install frontend ./webapp -n staging
helm install frontend ./webapp -n prod -f values-prod.yaml

Best practices for Helm + Namespace combinations:

• Include the environment in release names for cluster-wide uniqueness: myapp-prod, myapp-dev
• Use --create-namespace during CI/CD to auto-provision Namespaces
• Apply Namespace-scoped RBAC so dev engineers cannot helm install into production Namespaces

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

Practical Practice

Exam-style hands-on tasks for this topic. Complete each task before reviewing the solution. Time yourself — CKA tasks average 5–7 minutes.

Task 1: Create a Namespace with Resource Quotas Create namespace team-alpha with resource quotas: 10 Pods, 20Gi memory limit. Requirements: Use declarative YAML. Verify quota is enforced. Verification: kubectl get resourcequota -n team-alpha Solution:

kubectl create namespace team-alpha
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    pods: "10"
    limits.memory: "20Gi"
EOF
kubectl get resourcequota -n team-alpha
kubectl describe resourcequota team-alpha-quota -n team-alpha

Task 2: Troubleshoot Namespace Access A user cannot create a Deployment in namespace restricted — verify the RoleBinding and ResourceQuota. Requirements: Check RBAC and quota status. Verification: kubectl auth can-i create deployments -n restricted --as=dev-user Solution:

kubectl get rolebinding -n restricted
kubectl describe rolebinding <binding> -n restricted
kubectl get resourcequota -n restricted
kubectl describe resourcequota -n restricted
kubectl auth can-i create deployments -n restricted --as=dev-user
# If forbidden, create or fix Role/RoleBinding granting deployment create permission.

Related Pages

• Kubernetes Services — namespace-scoped networking, DNS, and Endpoints
• CoreDNS — Cluster DNS that powers cross-namespace service discovery
• Kubernetes Service Types — ClusterIP, NodePort, LoadBalancer, ExternalName
• Pod Fundamentals — namespace-scoped smallest deployable unit
• Multi-Container Pods — namespace-scoped multi-container workloads
• 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
• Kubernetes Authentication & Authorization — RBAC scope boundaries and namespace isolation
• Kubernetes RBAC — Roles, RoleBindings, and namespace-scoped permissions
• Why Kubernetes? — multi-tenancy and resource governance benefits
• Kubernetes Labels and Selectors — namespaceSelector and cross-namespace label queries
• Kubernetes Resource Requests and Limits — Pod-level requests/limits that quotas and LimitRanges govern
• Kubernetes Service Account — Every Namespace has a default ServiceAccount; custom ServiceAccounts are namespace-scoped identities
• Kubernetes Storage — PVCs are namespace-scoped; PVs and StorageClasses are cluster-scoped
• Kubernetes Autoscaling — HPA and VPA objects are namespace-scoped
• Horizontal Pod Autoscaler (HPA) — namespace-scoped autoscaling controller
• Helm — Namespace-scoped release management and multi-environment deployments
• Helm Release Management — Release isolation per Namespace
• Tech Tutorials with Piyush — course creator

---

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