Platform & DevOps·topic 3 of 9
Placement, resources and the pod lifecycle
Every workload is a request for someone else's CPU and memory, arbitrated by a scheduler that will happily tell you no. This cluster is what those numbers actually mean, why a workload will not start, and how one gets killed.
Read in order · tick what you already know
- 01
you promise the scheduler the workload needs half a core, and that half core is subtracted from the node whether or not you ever use it.
Resource request
- 02
the container went one byte over its memory ceiling and the kernel killed it outright, mid-request.
Resource limit
- 03
the sum of every limit on the node is three times the node, and it works fine until the day everything is busy at once.
Overcommit
- 04
average CPU use is twelve percent and the p99 latency is terrible, because the container is being stopped for milliseconds at a time.
CPU throttling
- 05
the container has no stack trace and no error log, just a restart count going up and exit code 137.
OOM kill
- 06
the workload with no requests set was the first one killed when the node ran out of memory, and nobody had chosen that.
Quality of service class
- 07
a healthy workload was terminated because the node it happened to be on ran out of disk, and it had done nothing wrong.
Eviction
- 08
the cluster is at ninety percent booked and forty percent used, and adding one more workload still needs a whole new node.
Bin packing
- 09
the deploy has been sitting at pending for twenty minutes with no error, because no node satisfies every constraint you set.
Unschedulable workload
- 10
the expensive GPU nodes sat empty because they push away every workload that has not explicitly said it can live there.
Taint
- 11
the workload carries a note saying it can live with the thing that node is marked with, so the scheduler stops excluding it.
Toleration
- 12
you say the workload must land on nodes labelled with the fast disk, and the scheduler filters out everything else.
Node affinity
- 13
all three replicas were on one node and one reboot took the service down, which is exactly what this rule prevents.
Pod anti-affinity
- 14
instead of forbidding two replicas per zone you say the counts must stay within one of each other, and the scheduler balances them.
Topology spread
- 15
a node upgrade rolled through the cluster and stopped, because taking one more replica down would have breached what you declared.
Pod disruption budget
- 16
you mark the machine unschedulable and evict everything on it politely, so the upgrade takes an hour instead of a page.
Node drain
- 17
traffic doubled and the replica count went from four to nine on its own, a minute or two after it needed to.
Horizontal autoscaling
- 18
something watched the workload for a week and rewrote its requests, and traditionally had to restart it to apply them.
Vertical autoscaling
- 19
a workload could not be placed, so a new machine was bought, booted and joined the cluster — three minutes after you needed it.
Cluster autoscaling
- 20
nothing is running and nothing is billed until a request arrives, and that first request waits for a container to start.
Scale to zero
- 21
the application takes ninety seconds to warm up, and this is what stops the health checker killing it at thirty.
Startup probe
- 22
you get thirty seconds after the signal to finish, and at second thirty-one you are killed with no negotiation.
Termination grace period