CKA Day 10 — Kubernetes Namespace Explained

Day 10/40 of the Certified Kubernetes Administrator (CKA) Full Course by Tech Tutorials with Piyush. This video explains Kubernetes Namespaces — the logical isolation mechanism that enables multi-tenancy, resource organization, and access control within a single cluster.

Key Takeaways

What Is a Namespace?

A Namespace is a logical boundary inside a Kubernetes cluster that partitions resources into isolated groups. Think of it as a virtual cluster inside a physical cluster. Namespaces do not provide network isolation by default — Pods in different namespaces can still communicate — but they do provide:

• Scope isolation: Resource names only need to be unique within a Namespace (e.g., two teams can each have a frontend Deployment)
• Resource quotas: Enforce CPU/memory limits per team or environment
• Access control: RBAC policies can be scoped to a Namespace
• Service discovery boundaries: DNS names include the Namespace, enabling clean cross-namespace references

The Four Default Namespaces

Kubernetes creates these automatically on cluster bootstrap:

Namespace	Purpose	Contents
default	The catch-all Namespace for user workloads	User-created Pods, Deployments, Services that don’t specify a Namespace
kube-system	System-level control plane components	CoreDNS, kube-proxy, CNI pods, metrics-server, DNS addons
kube-public	Publicly readable cluster info	cluster-info ConfigMap (used by kubeadm)
kube-node-lease	Node heartbeat leases	Lease objects for node health detection (lightweight alternative to full Node status updates)

Exam Tip: Never deploy application workloads into kube-system. It is reserved for Kubernetes internal components. Source: CKA Day 10

Namespace-Scoped vs Cluster-Scoped Resources

Most day-to-day objects live inside a Namespace, but some are global:

Scope	Examples
Namespace-scoped	Pod, Deployment, Service, ConfigMap, Secret, ReplicaSet, Job, NetworkPolicy, ResourceQuota, LimitRange
Cluster-scoped	Node, PersistentVolume, ClusterRole, ClusterRoleBinding, Namespace itself, StorageClass

This distinction is critical for RBAC and the CKA exam: you cannot create a Node inside a Namespace, and you cannot create a Namespace inside another Namespace.

Creating and Managing Namespaces

Imperative (fastest for the exam):

kubectl create namespace dev
kubectl delete namespace dev

Declarative (YAML):

apiVersion: v1
kind: Namespace
metadata:
  name: dev
  labels:
    env: development

Essential kubectl commands:

kubectl get namespaces                    # List all namespaces
kubectl get ns                            # Short form
kubectl get pods -n dev                   # List pods in dev namespace
kubectl get pods --namespace=dev          # Long form
kubectl describe namespace dev            # Details including ResourceQuotas

Switching Namespaces Persistently

Instead of typing -n dev on every command, set the default Namespace in your current context:

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

Warning: This only affects your local kubeconfig. CI/CD pipelines and teammates still need explicit -n flags or context switching.

Cross-Namespace Service Discovery

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

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

From any Pod in any Namespace, you can reach a Service in another Namespace by using its fully qualified domain name (FQDN):

# Service "backend" in "prod" namespace, accessed from "frontend" namespace
curl http://backend.prod.svc.cluster.local:8080
 
# Short form works if both are in the same Namespace
curl http://backend:8080

This pattern is essential for microservices architectures where different teams own different Namespaces. Source: CKA Day 10

Resource Quotas and Limits (Introduction)

While deep coverage comes later (Day 15 in the roadmap), Namespaces are the enforcement boundary for two key objects:

• ResourceQuota: Caps total CPU, memory, and object count (e.g., “dev Namespace can use max 10 CPUs and 20 GiB memory”)
• LimitRange: Sets default/min/max resource requests and limits for every Pod/Container created in the Namespace

Without a Namespace, these controls cannot be applied granularly.

NetworkPolicy and namespaceSelector

NetworkPolicies can filter traffic based on the source or destination Namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-monitoring
  namespace: prod
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: monitoring

This allows the monitoring stack (in the monitoring Namespace) to scrape metrics from Pods in prod, while blocking other Namespaces. Source: CKA Day 10

Namespace Best Practices

Pattern	Use Case
Environment per Namespace	dev, staging, prod for the same application
Team per Namespace	team-alpha, team-beta with independent RBAC
Project per Namespace	webapp-frontend, webapp-backend, data-pipeline
Customer per Namespace	SaaS multi-tenancy with strong ResourceQuotas

Anti-pattern: Creating a Namespace for every single Pod or Deployment. This creates management overhead without added benefit.

CKA Exam Speed Patterns

# Create a Namespace quickly
kubectl create ns exam-ns
 
# Run a Pod directly into a Namespace
kubectl run nginx --image=nginx -n exam-ns
 
# Get all resources in a Namespace
kubectl get all -n exam-ns
 
# Check which Namespace you are currently in
kubectl config view --minify --output 'jsonpath={..namespace}'

The exam may ask you to create objects in a specific Namespace. Always verify with kubectl get <resource> -n <namespace> after applying manifests.

See Also

Wiki Concepts

• Kubernetes Namespaces — comprehensive concept page with YAML patterns and exam notes
• Kubernetes Services — namespace-scoped networking and DNS resolution
• Kubernetes Service Types — ClusterIP, NodePort, LoadBalancer, and ExternalName
• Pod Fundamentals — namespace-scoped smallest deployable unit
• Deployment, ReplicaSet & Replication Controller — namespace-scoped workload controllers
• Kubernetes Architecture — default namespaces and control plane isolation
• CKA Certification — exam domains where Namespaces appear
• CKA Study Roadmap — Day 10 in the 40-day plan
• Why Kubernetes? — multi-tenancy as a core orchestration benefit

Related Sources

• CKA Day 9 — Kubernetes Services Explained — prerequisite: stable networking for Pods
• CKA Day 8 — Deployments, ReplicaSets & Replication Controllers — prerequisite workload controllers
• CKA Day 7 — Pod Explained — foundational Pod concepts

Creator / Entity

• Tech Tutorials with Piyush — CKA 40-day challenge series