Namespaces

Isolate workloads into virtual clusters for teams, environments, and access control.

beginner45 minRead → Lab → Quiz → Practice

🧠 Brain Warm-Up

🧠 Brain Warm-Up: If two teams in a Kubernetes cluster create a Deployment with the same name (e.g. api), how does the cluster prevent name collisions, and does this separation also block network communication between them by default?

What Are Namespaces?

A namespace is a logical partition inside a physical Kubernetes cluster. It provides a scope for names of resources. Resource names must be unique within a namespace, but can be duplicated across different namespaces.

Under the hood, namespaces do not represent physical isolation. They partition API resources logically by prefixing key paths in etcd (e.g., /registry/pods/production/api-pod vs /registry/pods/staging/api-pod).

Namespaces vs Linux Namespaces

It is crucial to distinguish Kubernetes Namespaces from Linux Kernel Namespaces (such as net, mnt, pid, ipc, and uts):

Linux Namespaces are a kernel feature that isolates system resources (processes, mount points, network interfaces) for containers on a single host.
Kubernetes Namespaces are a control plane construct in the API server designed for multi-tenancy, access control, and quota management.

Visualizing Namespaces

+---------------------------------------------------------------------------------+
|                                 PHYSICAL CLUSTER                                |
|                                                                                 |
|  +---------------------------+  +---------------------------+  +-------------+  |
|  |   Namespace: production   |  |     Namespace: staging    |  | Cluster-    |  |
|  |                           |  |                           |  | Scoped      |  |
|  |  +---------------------+  |  |  +---------------------+  |  | Resources   |  |
|  |  |   Deployment: api   |  |  |  |   Deployment: api   |  |  |             |  |
|  |  +---------------------+  |  |  +---------------------+  |  |  +-------+  |  |
|  |                           |  |                           |  |  | Nodes |  |  |
|  |  +---------------------+  |  |  +---------------------+  |  |  +-------+  |  |
|  |  |  NetworkPolicy (X)  |  |  |  |  NetworkPolicy (X)  |  |  |             |  |
|  |  +---------------------+  |  |  +---------------------+  |  |  +-------+  |  |
|  |                           |  |                           |  |  | PVs   |  |  |
|  +---------------------------+  +---------------------------+  +-------+  |  |
|               |                               |                                 |
|               +---(Allowed by default unless)-+                                 |
|                   (blocked by NetworkPolicy)                                    |
+---------------------------------------------------------------------------------+

Default Namespaces

Kubernetes creates four default namespaces on bootstrap:

Namespace	Purpose
`default`	The default target for API requests when no namespace is specified.
`kube-system`	Reserved for infrastructure components managed by the control plane (e.g., `kube-apiserver`, `etcd`, `kube-scheduler`, `coredns`, `kube-proxy`).
`kube-public`	Created automatically and readable by all users (including unauthenticated ones). Used for cluster bootstrap discovery info.
`kube-node-lease`	Houses `Lease` objects associated with each node. Kubelet sends heartbeats by updating these leases, reducing API load compared to updating the full Node status.

Logical vs Physical Boundary

By default, namespaces are NOT secure network boundaries.

DNS Resolution: CoreDNS resolves services using the Fully Qualified Domain Name (FQDN) format: ..svc.cluster.local. A Pod in the staging namespace can resolve and route traffic to a Service in the production namespace simply by using its FQDN.
Network Isolation: To enforce physical network isolation between namespaces, you must define NetworkPolicies targeting the namespaces via namespaceSelector. This instructs the Container Network Interface (CNI) plugin (e.g., Calico, Cilium) to configure packet filtering (e.g., using iptables rules or eBPF programs) to drop unauthorized cross-namespace traffic.

Resource Allocation and RBAC

Namespaces are the primary boundary for resource quotas and access control:

ResourceQuota: Scopes total compute allocation. When a ResourceQuota is applied, the admission controller rejects Pod creation requests that do not specify CPU/Memory requests or limits, or that exceed the namespace quota ceiling.
Role-Based Access Control (RBAC): Role and RoleBinding resources are namespaced, granting privileges restricted to that namespace. Cluster-wide privileges require ClusterRole and ClusterRoleBinding objects.

Setting a Default Namespace

Instead of typing -n staging on every command, switch your active namespace once:

kubectl config set-context --current --namespace=staging

All subsequent kubectl commands will target staging until you switch again. Switch back with:

kubectl config set-context --current --namespace=default

←

Container Images — Build, Tag & Load

Labels & Selectors

→