Multi-tenancy and Quotas

Sharing one cluster among many teams or workloads is multi-tenancy, and how far you can safely share depends on how much you trust the tenants. The tools are namespaces, ResourceQuotas, LimitRanges, RBAC, and NetworkPolicies — and the key judgment is where soft tenancy stops being enough.

This is the operational side of Namespaces (Topic 11): the controls that keep tenants from starving or interfering with each other, and the honest limits of those controls.

Soft vs Hard Multi-tenancy

Soft multi-tenancy assumes cooperating, non-hostile tenants — different teams in one organization. Namespaces plus quotas and RBAC are enough to keep them tidy and fair. Hard multi-tenancy assumes mutually untrusted tenants who might actively attack each other or the platform; the shared kernel, shared control plane, and shared network mean namespaces alone cannot guarantee isolation. Knowing which you have is the first decision, because it dictates everything else.

ResourceQuota and LimitRange

A ResourceQuota caps a namespace's total consumption — aggregate CPU/memory requests and limits, and counts of objects like Pods or Services — so one tenant cannot consume the whole cluster. A LimitRange sets per-Pod/container defaults and bounds within a namespace, so individual workloads can't request absurd amounts and nothing ships as BestEffort by accident. The two work together: LimitRange shapes individual Pods, ResourceQuota caps the namespace total.

apiVersion: v1
kind: LimitRange
metadata:
  name: defaults
  namespace: team-a
spec:
  limits:
    - type: Container
      default:           # default limit if unset
        cpu: 500m
        memory: 512Mi
      defaultRequest:    # default request if unset
        cpu: 100m
        memory: 128Mi

Per-Tenant Isolation

Beyond fairness, soft tenancy needs boundaries: scope RBAC so each team manages only its own namespaces, and add default-deny NetworkPolicies (Topic 23) so one tenant's Pods cannot freely reach another's. Together — namespace + quota + RBAC + NetworkPolicy — these give a reasonable boundary for cooperating teams. They do not, however, contain a determined attacker who escapes a container or exploits the shared control plane.

When Soft Isn't Enough

For untrusted tenants, escalate the isolation. Options range from dedicated node pools per tenant (with taints, so workloads don't share machines), to a stronger sandboxed runtime (gVisor/Kata, Topic 02), to virtual clusters (vcluster) that give each tenant an apparent control plane, to the strongest answer: separate clusters. Each step adds isolation and cost. The recurring mistake is treating namespace-based soft tenancy as if it were hard isolation for hostile tenants — it is not.