What is multi-tenancy in Kubernetes, and what mechanisms support it?

Why multi-tenancy is a spectrum, not a single feature

"Multiple teams share a cluster" can mean anything from "trusted internal teams, mostly worried about accidentally stepping on each other's resources" to "mutually untrusted third-party customers running arbitrary code, where a security breach of one tenant must never affect another" — Kubernetes provides building blocks at several different strength levels, and choosing the right combination depends entirely on how much you actually trust the tenants sharing the cluster.

Layer 1: Namespaces — logical separation

Covered in the fundamentals topic — namespaces scope object names and are the boundary RBAC and quotas attach to. This alone provides organizational separation (Team A's web Deployment doesn't collide with Team B's web Deployment) but, critically, no network or security isolation by default — Pods in different namespaces can freely reach each other unless NetworkPolicies say otherwise.

Layer 2: ResourceQuotas and LimitRanges — preventing resource monopolization

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

A ResourceQuota caps the total resources (or object counts) a namespace can consume — without this, one tenant's namespace could, in principle, consume so much of the shared cluster's capacity that other tenants' workloads can't be scheduled at all (a "noisy neighbor" problem). A LimitRange complements this by setting default and min/max per-container resource requests/limits within a namespace, so individual Pods can't be created with unreasonably large (or entirely unset) resource requests even before the aggregate quota is hit.

Layer 3: NetworkPolicies — restricting cross-tenant traffic

As covered in the networking topic, a default-deny NetworkPolicy posture per tenant namespace, with explicit allow rules only for legitimate cross-namespace traffic, prevents one tenant's compromised or misbehaving workload from freely reaching another tenant's Pods over the network — closing the gap that plain namespace separation alone leaves wide open.

Layer 4: RBAC — restricting cross-tenant API access

Namespace-scoped Roles and RoleBindings (see the security topic) ensure Team A's credentials/ServiceAccounts have no permission to read or modify Team B's objects at the API level, even though both share the same cluster and API server.

Layer 5: stronger isolation for genuinely untrusted tenants

For scenarios where tenants are truly mutually distrustful (a SaaS platform running arbitrary customer workloads, or strict regulatory/compliance separation requirements), namespace-level isolation alone is generally considered insufficient — the Linux kernel underlying every container on a node is still shared, and container escape vulnerabilities, while not routine, do exist. Stronger options include:

• Dedicated node pools per tenant (via taints/tolerations and node affinity — see that question), ensuring no two tenants' Pods ever share the same physical/virtual machine.
• Sandboxed container runtimes (gVisor, Kata Containers) that provide a stronger isolation boundary than a standard container runtime, at some performance cost.
• Separate clusters per tenant — the strongest isolation available, at the cost of significantly higher operational overhead (managing many clusters instead of one) and losing the resource-pooling efficiency of a shared cluster.

Match the isolation strategy to the actual trust level between tenants: internal teams within one organization, generally trusting each other but wanting organizational and resource separation, are usually well served by namespaces + quotas + RBAC + NetworkPolicies on a shared cluster. Genuinely untrusted external tenants, or workloads with strict compliance/regulatory separation requirements, usually warrant node-level or cluster-level isolation instead — treating namespace-only separation as sufficient for that case is a common, real security misjudgment.