Chapter 08: Resource Management & QoS
Learning Objectives
By the end of this chapter, you will be able to:
- Explain what a request and a limit each do - for the scheduler, the quota and the kernel - and why CPU and memory behave differently at the limit
- Name who stopped a container - the kernel’s OOM killer, the kubelet’s eviction, CPU throttling, the quota or the LimitRange - and where each one leaves its trace
- Say what a QoS class decides and what it does not
- Read the platform’s budget: the LimitRange and quota of each namespace, and the worst case
check-app-resources.shchecks before a merge
Recall Check
Before continuing, quickly recall:
- What does Flux do with a change made by hand in the cluster? (Chapter 03)
- Which check runs every hook again on every pull request? (Chapter 05)
- Pod Security refused a root pod - on the Deployment or on its pods, and where was the refusal visible? (Chapter 07)
If you can’t answer these, revisit the corresponding chapter before proceeding.
Context
Chapter 07 limited what a container may do. This chapter limits how much it may use.
Every pod on a node shares the same CPU and memory. Without numbers, the scheduler cannot know whether a pod fits, a node can be promised more than it has, and one container that keeps allocating takes memory from every pod next to it. Kubernetes asks two numbers of every container: a request - what the scheduler reserves for it on a node - and a limit - the ceiling the kernel holds it to. Each namespace adds two more rules: a LimitRange for each container and a ResourceQuota for the namespace’s total.
The numbers are not bureaucracy. They decide where a pod runs, which pod dies first when a node runs short, and whether a release with a memory leak takes down one pod - or the node. They also hide a trap: when something goes wrong, the quickest fix is always a bigger number. A higher limit, a bigger quota, a larger node - each makes the symptom go away for a while, and none of them asks why the container needed more.
The platform gives every app container explicit requests and limits, every namespace a LimitRange and a quota, and checks before each merge that the worst case still fits. This chapter shows what each of these does, where each refusal appears, and how to read the evidence before reaching for a bigger number.
Work through each lesson section; the chapter video, once it is published, gives the concept overview.
From the Pull Request to the Kernel
