What Are Kubernetes Namespaces?

Detailed Answer

Namespaces are a way to divide a single physical Kubernetes cluster into multiple virtual clusters. They provide a scope for resource names, allowing different teams, environments, or applications to coexist without naming conflicts.

Why Namespaces Exist

In a shared cluster, namespaces solve several problems:

• Name isolation: Two teams can each have a Service named "api" in their own namespaces
• Access control: RBAC can restrict users to specific namespaces
• Resource management: ResourceQuotas limit how much CPU, memory, and objects a namespace can consume
• Network isolation: Network policies can restrict traffic between namespaces

Default Namespaces

Every cluster starts with four namespaces:

| Namespace | Purpose | |---|---| | default | Resources created without specifying a namespace | | kube-system | Control plane components (API server, scheduler, CoreDNS) | | kube-public | Publicly readable data (e.g., cluster-info ConfigMap) | | kube-node-lease | Node heartbeat Lease objects for node health detection |

Creating and Using Namespaces

apiVersion: v1
kind: Namespace
metadata:
  name: team-frontend
  labels:
    team: frontend
    environment: production

# Create a namespace
kubectl create namespace team-frontend

# Deploy resources in a specific namespace
kubectl apply -f deployment.yaml -n team-frontend

# Set a default namespace for your context
kubectl config set-context --current --namespace=team-frontend

# List resources in a namespace
kubectl get pods -n team-frontend

# List resources across all namespaces
kubectl get pods -A

Namespace-Scoped vs Cluster-Scoped Resources

# See which resources are namespace-scoped
kubectl api-resources --namespaced=true

# See which resources are cluster-scoped
kubectl api-resources --namespaced=false

| Namespace-Scoped | Cluster-Scoped | |---|---| | Pods | Nodes | | Services | PersistentVolumes | | Deployments | ClusterRoles | | ConfigMaps | ClusterRoleBindings | | Secrets | Namespaces | | Roles | StorageClasses | | RoleBindings | IngressClasses | | PersistentVolumeClaims | CustomResourceDefinitions |

Organizing Namespaces

Common strategies:

By team:

team-frontend
team-backend
team-data
team-platform

By environment:

development
staging
production

By application:

app-payments
app-orders
app-notifications

Hybrid (team + environment):

frontend-dev
frontend-staging
frontend-prod

What Namespaces Do NOT Provide

Namespaces are not a security boundary by default:

1. No network isolation: Pods can reach any Pod in any namespace unless Network Policies restrict it
2. No resource isolation: A namespace without quotas can consume all cluster resources
3. No workload isolation: Pods from different namespaces can run on the same node
4. No API access control: Without RBAC, users can access all namespaces

To achieve true isolation, combine namespaces with:

• RBAC (restrict API access per namespace)
• ResourceQuotas (limit resource consumption)
• Network Policies (restrict network traffic)
• Pod Security Standards (enforce security policies)

Deleting a Namespace

Deleting a namespace deletes all resources within it:

kubectl delete namespace team-frontend
# WARNING: This deletes all Pods, Services, Deployments, ConfigMaps, Secrets, etc. in the namespace

This is a cascading delete and cannot be undone. Use RBAC to prevent unauthorized namespace deletion.