Kubernetes uses namespaces to isolate resources. They partition the cluster for teams, environments or apps. You can attach quotas, security policies and network controls per namespace. This article explains Namespace API v1 at a glance.
TL;DR
- Namespaces isolate objects and avoid name collisions across teams and environments.
- The Namespace API v1 supports CRUD, watch and status phases via REST endpoints.
- You can apply resource quotas, network policies and security contexts per namespace.
PersistentVolumeClaims, CSI drivers and snapshots operate inside namespaces.- Event-driven controllers can watch namespace events for automated workflows.
Namespace Scope Explained
A namespace provides a scope for names within a cluster . It adds a virtual cluster layer on top of a physical cluster. Namespaced objects include pods, services, config maps and persistent volume claims. The API object looks like this:
apiVersion: v1
kind: Namespace
metadata:
name: dev-team
labels:
team: dev
The spec.phase field stays empty on creation. The status.phase field moves through Active, Terminating phases.
Namespace Scope API
The Namespace API lives under /api/v1/namespaces. It supports:
GET /api/v1/namespaces– list all namespaces.POST /api/v1/namespaces– create a new namespace.GET /api/v1/namespaces/{name}– fetch a namespace.PUT /api/v1/namespaces/{name}/status– update status phase.DELETE /api/v1/namespaces/{name}– remove a namespace.WATCH /api/v1/watch/namespaces– stream events.
All calls return JSON with metadata, spec, status sections.
Namespace Scope Code Examples
Create and manage namespaces with kubectl:
kubectl create namespace prod
kubectl get namespaces
kubectl delete namespace testYAML manifest to define a namespace:
apiVersion: v1
kind: Namespace
metadata:
name: qa-environment
annotations:
owner: qa-team
Resource Quotas in Namespace
ResourceQuota objects limit compute and storage per namespace. You can cap pods, CPU, memory, PVC count and more:
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-quota
namespace: dev-team
spec:
hard:
pods: "10"
requests.cpu: "4"
requests.memory: 8Gi
persistentvolumeclaims: "5"
The quota controller enforces these limits automatically on object creation.
Security Contexts per Namespace
Namespaces carry default service accounts and role bindings. You can enforce PodSecurity standards via admission controllers.
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
namespace: dev-team
spec:
securityContext:
runAsUser: 1000
fsGroup: 2000
containers:
- name: app
image: nginxNetworkPolicy objects scoped to a namespace control traffic flow among pods.
Persistent Volumes and PVC Lifecycle
PersistentVolumeClaims and PersistentVolumes follow a lifecycle inside a namespace. A PVC binds to a PV via storageClassName and accessModes. CSI drivers handle dynamic provisioning.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: data-pvc
namespace: dev-team
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: fast-ssd
You can manage snapshots per PVC using VolumeSnapshot CRDs provided by CSI drivers.
Event-driven Flows within Namespace
Controllers can watch namespace events to trigger automation. For example, an operator can create default quotas when a new namespace appears. You can run message brokers inside a namespace to handle events scoped to that team.
References
- Namespace API v1 documentation
- Resource Quotas concept guide
- Pod Security Standards
- API Controllers and events
Suggested Reading
PostHashID: 9c96a200c6e2f1a1a67ceb707345056e3428d89b823d734ea0c791efe000df8f
