Run an agency on one cluster and every client lives in its own namespace. Each of those namespaces needs two things: pods that are well-formed even when the developer who deployed them forgot to set resources, and a hard ceiling so no single client can starve the others of cluster resources. Kubernetes has one admission controller for each half of that problem, and on Syself Autopilot both are on by default. A LimitRange or ResourceQuota you apply to a namespace takes effect on the next pod that lands there.

## What each tool owns

- **LimitRange shapes each pod**: Fills in a default request and limit for any container that omits one, and caps how large a single container may ask to be. It corrects the [request-less pod](/docs/hetzner/apalla/workloads/production/resource-requests-and-limits) for the whole namespace at once, before a scheduler ever sees the pod.
- **ResourceQuota fences the total**: Caps what the namespace can consume in aggregate: `requests.cpu`, `requests.memory`, `limits.memory`, and object counts like `pods`, `persistentvolumeclaims`, or `services.loadbalancers`, the last of which stops one tenant from quietly creating a hundred load balancers.

## The catch that ties them together

Set a quota on `requests.cpu` or `requests.memory` and Kubernetes changes the rules: every pod in that namespace must now declare those requests, or the API server rejects it outright. "Please set requests" becomes a hard requirement.

That would break every developer who forgets, except the LimitRange in the same namespace is exactly what saves them. It defaults the missing request in before admission, so the quota only ever sees a fully-specified pod. The two work as a pair: the quota makes requests mandatory, the LimitRange makes forgetting them harmless. Size both to what the client pays for, then add [network policy](/docs/hetzner/apalla/security/segment-with-network-policies) and per-namespace RBAC for real isolation.

## Read what a client has left

Ask a namespace how close it is to its ceiling with `describe quota`:

```console
$ kubectl describe quota client-acme-quota -n client-acme
Name:            client-acme-quota
Namespace:       client-acme
Resource         Used   Hard
--------         ----   ----
pods             12     50
requests.cpu     2500m  8
requests.memory  6Gi    16Gi
```

`Used` against `Hard` is the headroom a client has before pods start getting rejected. A deploy that fails with a `must specify` or `exceeded quota` error is the guardrail doing its job. Fix the pod's requests, or raise the ceiling.