SHART.CLOUD | DESKTOP | LABROULETTE | KUBERNETES-NAMESPACE-QUOTAS.YAML
Stop One Namespace from Eating the Whole Cluster - Labroulette — shart.cloud
01 - Labroulette - Stop One Namespace from Eating the Whole Cluster
| shart.cloud / labroulette / kubernetes-namespace-quotas |
MULTI *OO ~50 min $0-2 reviewed 6/30/2026

Stop One Namespace from Eating the Whole Cluster

Add namespace-level quotas, default resource limits, and a deny-by-default posture so each team gets a fair slice of the cluster instead of a buffet with root access.

#containers#cost#reliability
Lab Podsnack Academy, a training cluster where one student's "tiny test" spun up enough memory requests to make everyone else's labs fall over like wet cardboard. all labs
02 - Actions
score -- - -- votes
-- completed
State loading
03 - Scenario

Podsnack Academy, a training cluster where one student's "tiny test" spun up enough memory requests to make everyone else's labs fall over like wet cardboard.

Add namespace-level quotas, default resource limits, and a deny-by-default posture so each team gets a fair slice of the cluster instead of a buffet with root access.

Constraints

  • Every workload namespace has a ResourceQuota
  • Pods without explicit requests and limits receive sane defaults
  • Quota denial is demonstrated with a deliberately oversized deployment
  • The pattern is cluster-agnostic and works on managed Kubernetes or kind
Scenario MULTI - beginner
05 - Steps
  1. STEP_01

    Create the team namespace

    Create a namespace for one training team and label it with owner and cost metadata. The namespace is the accounting boundary for the rest of the lab.

    Terraform docs

  2. STEP_02

    Cap the namespace with ResourceQuota

    Add a ResourceQuota that limits total CPU, memory, pod count, and selected object counts. Pick small lab values so you can hit the ceiling on purpose.

    Terraform docs

  3. STEP_03

    Set default requests and limits

    Add a LimitRange that gives containers sane default CPU and memory requests/limits when developers forget them. Forgotten limits should not turn into accidental cluster-wide performance art.

    Terraform docs

  4. STEP_04

    Deploy a normal workload

    Create a small deployment that fits inside the quota. Confirm Kubernetes admits it and that the defaulted resource settings appear on the pods.

    Terraform docs

  5. STEP_05

    Try to exceed the quota

    Apply a deliberately oversized deployment or scale the normal one past the namespace limit. Capture the admission or scheduling failure that proves the quota works.

    Hint: A failure here is success. The cluster saying "no" is the sound of other students still being able to use it.

Steps 5 tasks
06 - Deliverables
  • Terraform for the namespace, ResourceQuota, LimitRange, and test deployment
  • Output showing default requests/limits were applied to a pod
  • Output showing an oversized workload was rejected or could not be scheduled under quota
Deliverables 3 required
07 - Rubric
ResourceQuota caps CPU, memory, pods, and at least one object count 30%
LimitRange applies defaults to pods that omit requests and limits 30%
A normal workload runs successfully under quota 15%
An oversized workload is denied or constrained with captured proof 25%
Rubric self-assessed