Each team gets a namespace with a ResourceQuota: team-a may request 2 CPUs and 2 GiB in total. worker already runs two Pods that request 500m and 256Mi each.
About this scenario
Each team gets a namespace with a ResourceQuota: team-a may request 2 CPUs and 2 GiB in total. worker already runs two Pods that request 500m and 256Mi each.
api was deployed without any resources, and its ReplicaSet can't create a Pod. Don't change the quota or worker; make api fit with a LimitRange.
Objectives
- Find out why api has no Pods
- Add a LimitRange that gives containers default requests
- api runs 4 replicas next to worker's 2
- The quota and worker's requests are unchanged
What you'll practice
- A ResourceQuota on requests makes every Pod in the namespace state its requests; without them the API server refuses the Pod, and the ReplicaSet reports FailedCreate.
- A LimitRange fills in default requests and limits for containers that don't set them, and can cap them with
minandmax. It only acts when a Pod is created. - The scheduler and the quota both work from requests. Size them from what the app needs, and the quota tells you how many replicas fit.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Flux, Argo CD) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.