The most detailed free FDE + DevOps library: 140+ lessons, 70+ labs and 80 long-form articles, in English and Turkish. Start learning →

DevOps Professional · Module 1: Platform design and tenancy

Quotas and Policy: Fair Shares with Teeth

Fair shares need enforcement, not goodwill. Quotas cap what each tenant may reserve, limit ranges keep individual pods sane, and admission policy rejects what the platform forbids, before it runs.

10 min reading

Objectives

  • Explain what quotas bound: aggregate requests, limits, object counts per tenant
  • Set quota and limit ranges from measured use, not from guesses
  • Enforce policy (allowed images, required labels, denied hosts) at admission
  • Handle quota exhaustion as a capacity conversation, not as an error to bypass

Why this matters

Team A reserves ten times the cluster for a load test nobody approved, and team B's deploys pend for a day. The reservation was legal because nothing bounded it; the argument afterward is about etiquette because no policy existed to cite. Quotas move the argument from etiquette to arithmetic before the incident: this namespace may reserve this much, the request above it fails at admission with the number quoted, and the capacity conversation happens with data instead of blame.

Concepts

ResourceQuotas bound aggregates per namespace: total CPU and memory requests, total limits, object counts, storage claims. LimitRanges bound individuals: every container gets defaults and min-max envelopes, so a pod without requests cannot reserve invisibly and a pod with absurd requests fails fast with a number. Set both from measured profiles (M05's measuring habit at platform scale): quota near the team's demonstrated need plus growth headroom, reviewed quarterly, never copied from another team.

Admission policy enforces the platform's non-negotiables: images from approved registries only, required labels for cost and ownership, no privileged pods outside the exempt namespace, no latest tags. The policy engine (whatever the local setup supports) evaluates before persistence; rejection messages name the rule and the fix. Policy that rejects without explaining teaches evasion; policy that explains teaches compliance.

Exhaustion is a process, not an error. A quota rejection routes to the capacity conversation: is the need real (raise with data), is it waste (right-size with profiles), is it timing (schedule the spike). Bypass paths (raising your own quota, borrowing namespaces) must not exist; if they do, quotas are theater. The L50 lab verifies quota behavior with small namespace tasks and records the rejection path working.

Worked example

A demo namespace gets a quota near its measured use plus headroom, with limit ranges enveloping sane pods. The learner deploys inside quota (accepted), stages an oversized reservation (rejected with the quoted number), and triggers a policy rejection with a forbidden image. Three rejections, three quoted reasons, zero running violations.

Common wrong move

Setting quotas from hierarchy instead of measurement: production gets a big number, dev gets a small one, and nobody checks either against use. Big quotas hide waste, small quotas throttle real work, and both teach teams that numbers are fiction. Measure, then bound.

Quick check

An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.

Lesson feedback

No published feedback yet.

Log in and complete the lesson to leave feedback.

Exercise

On a local cluster, set quota and limits from a measured profile for a demo namespace, stage an oversized reservation and a forbidden image, and quote all three admission decisions.

Pass criteria

The record shows the measured profile, the quota and range objects, and three quoted admission outcomes with their reasons.

Sources

Log in to track progressFree account: stores only your lesson progress and quiz results.