Topic 11

Namespaces

OrganizationTenancy

A Namespace is a virtual cluster inside a cluster: a scope for object names, resource quotas, and access control. It is how you divide one physical cluster among teams, environments, or applications without giving everyone the run of the whole thing.

Namespaces are the first tool you reach for in multi-tenancy, and the first one people overestimate. They scope and organize; they do not, by themselves, isolate the network or guarantee security. Knowing exactly what they do and do not do prevents a class of dangerous assumptions.

What a Namespace Scopes

Within a namespace, object names must be unique; across namespaces they can repeat — two web Deployments in team-a and team-b coexist fine. A namespace is also the unit that ResourceQuotas, LimitRanges, and most RBAC rules apply to. It is the natural boundary for "this team's stuff" or "the staging environment."

Kubernetes ships with a few namespaces: default (where objects land if you don't specify one), kube-system (control-plane components — leave it alone), and kube-public. Putting real workloads in default is a smell; create purposeful namespaces instead.

Namespaced vs Cluster-Scoped

Not everything lives in a namespace. Namespaced resources — Pods, Services, Deployments, ConfigMaps — belong to one. Cluster-scoped resources — Nodes, PersistentVolumes, StorageClasses, ClusterRoles, and the Namespaces themselves — do not. This distinction matters when you reason about RBAC and about what a namespace boundary actually contains: deleting a namespace deletes its namespaced objects, but cluster-scoped objects are unaffected.

DNS and Cross-Namespace Access

A Service is reachable within its namespace by its short name (orders) and from anywhere in the cluster by its fully qualified name (orders.team-a.svc.cluster.local). So a namespace does not wall off network traffic — a Pod in team-b can reach a Service in team-a by FQDN unless a NetworkPolicy forbids it. The organizational boundary is not a network boundary.

The Limits of Soft Multi-Tenancy

Namespaces give soft multi-tenancy: good enough for cooperating teams inside one organization, with quotas to prevent noisy neighbors and RBAC to scope access. They do not give hard multi-tenancy for mutually untrusted tenants — the shared kernel, shared control plane, and default-open network mean a determined or hostile tenant can affect others. For that you reach for separate node pools, strict policy, virtual clusters, or simply separate clusters (Topic 52).

A ResourceQuota scoping a namespace

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    pods: "50"

Soft vs hard multi-tenancy

Soft (namespaces) — cooperating teams in one org; quotas and RBAC keep them tidy. The common case.

Hard (separate clusters / strong isolation) — mutually untrusted tenants; requires node isolation, strict policy, or separate clusters. Namespaces alone are not enough.

Common Mistakes

Assuming a namespace isolates network traffic — cross-namespace access works by FQDN unless a NetworkPolicy blocks it.
Running real workloads in default instead of purpose-named namespaces.
Treating soft multi-tenancy as sufficient isolation for hostile or untrusted tenants.
Forgetting that cluster-scoped objects (PVs, ClusterRoles, Nodes) are not bounded by a namespace.
Skipping ResourceQuotas, so one team's runaway workload starves the rest of the cluster.

Best Practices

Create deliberate namespaces per team or environment; keep default empty.
Apply a ResourceQuota and LimitRange to every tenant namespace to prevent noisy neighbors.
Scope RBAC to namespaces so each team can manage only its own objects.
Add default-deny NetworkPolicies if you need the namespace boundary to also restrict traffic.
When tenants are untrusted, escalate to separate node pools or clusters rather than relying on namespaces.

RelatedResourceQuota / LimitRange — enforcing fairness within a namespaceNetworkPolicy — turning a namespace into a network boundary (Topic 23)Cloud projects / accounts — the heavier isolation boundary in the clouds

Knowledge Check

Does putting two teams in separate namespaces isolate their network traffic?

No — a Pod can reach another namespace's Service by its FQDN unless a NetworkPolicy forbids it
Yes — namespaces automatically firewall off all cross-namespace traffic by default, with no NetworkPolicy needed
Only when the Services are exposed using the ClusterIP type
Only for traffic that crosses the control-plane network

Which of these is a cluster-scoped (not namespaced) resource?

A PersistentVolume backing storage
A Deployment that runs a stateless app
A ConfigMap of settings
A Service fronting Pods

Namespaces provide which kind of multi-tenancy?

Soft — suitable for cooperating teams, not for mutually untrusted tenants
Hard — full isolation equivalent to giving each separate tenant its own dedicated cluster
None — they are a purely cosmetic label with no real effect
Full network-level isolation enforced automatically by default

You got correct