Skip to main content
< All Topics

Kubernetes Namespace

Posted
Updated
Author -Rajkumar Aute
Views49

Namespace

Think of a Kubernetes Namespace as a way to divide a single big cluster into multiple smaller, virtual clusters. It helps you organize your resources (like pods, services, and deployments) so that different teams or projects don’t mess with each other. It provides scope for names meaning, you can have a “database” service in the Dev namespace and another “database” service in the Prod namespace, and they won’t clash.

Imagine a Large Office Building (The Kubernetes Cluster). Inside this building, you have different Departments like HR, IT, and Finance (The Namespaces).

  • Isolation: People in the HR department (Pods in HR namespace) work in their own cabin. The noise they make doesn’t disturb the IT team.
  • Resource Sharing: Everyone shares the same building electricity and water (Node Resources: CPU/RAM), but you can set rules so the IT team doesn’t use up all the coffee (ResourceQuotas).
  • Naming: Both HR and IT can have a manager named “Ramesh” (Service Name). If you call “Ramesh” inside the HR cabin, the HR manager responds. If you call “Ramesh” in IT, the IT manager responds.

Quick Reference
  • Virtual Clusters: Namespaces act as virtual clusters backed by the same physical hardware.
  • Unique Naming: Names must be unique within a namespace but can repeat across different namespaces.
  • Global Resources: Not all resources exist in a namespace. Nodes and PersistentVolumes are global cluster resources.
  • DNS Resolution: DNS for a service follows this pattern: <service-name>.<namespace-name>.svc.cluster.local.
  • Logical Isolation: Provides a strict boundary for your environments.
  • Multi-tenancy: Allows multiple users, teams, or clients to safely share one cluster.
FeatureDescriptionSimple Trick to Remember
IsolationSeparates resources logically.Like separate folders on a laptop.
QuotaLimits total CPU/Memory for the namespace.Like a monthly pocket money limit.
RBACControls who can access what inside.Like an ID card for a specific lab.
DNSautomatic naming for discovery.<service-name>.<namespace-name>.svc.cluster.local.

The “Built-in” Namespaces

When you first set up Kubernetes, it comes with default namespaces. You should know them:

  1. default: Where your stuff goes if you don’t specify a namespace.
  2. kube-system: For Kubernetes’ own components (like the scheduler, kube-dns). Warning: Don’t touch this unless you know exactly what you are doing!
  3. kube-public: Strictly for public data (rarely used by users).
  4. kube-node-lease: Used by nodes to send “heartbeats” to the master (to say “I am alive”).
How to Work with Namespaces (Practical Commands)

As a practitioner, you will interact with namespaces daily. Here are the essential kubectl commands:

  • List all namespaces: kubectl get namespaces (or kubectl get ns)
  • Create a new namespace: kubectl create namespace dev-env
  • Create a pod in a specific namespace: kubectl run my-nginx --image=nginx -n dev-env
  • View pods in a specific namespace: kubectl get pods -n dev-env
  • Change your default namespace: kubectl config set-context --current --namespace=dev-env (Saves you from typing -n every time!)
  • Delete a namespace: kubectl delete namespace dev-env (Warning: This deletes the namespace AND every resource inside it!)

The Architect’s Corner: Governing Namespaces

As an Architect, namespaces are your first line of defense and organization. You don’t just “create” them; you govern them.

Contents
Scroll to Top