jargon

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

  1. 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

  2. 02

    the container went one byte over its memory ceiling and the kernel killed it outright, mid-request.

    Resource limit

  3. 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

  4. 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

  5. 05

    the container has no stack trace and no error log, just a restart count going up and exit code 137.

    OOM kill

  6. 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

  7. 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

  8. 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

  9. 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. 10

    the expensive GPU nodes sat empty because they push away every workload that has not explicitly said it can live there.

    Taint

  11. 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. 12

    you say the workload must land on nodes labelled with the fast disk, and the scheduler filters out everything else.

    Node affinity

  13. 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. 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. 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. 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. 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. 18

    something watched the workload for a week and rewrote its requests, and traditionally had to restart it to apply them.

    Vertical autoscaling

  19. 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. 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. 21

    the application takes ninety seconds to warm up, and this is what stops the health checker killing it at thirty.

    Startup probe

  22. 22

    you get thirty seconds after the signal to finish, and at second thirty-one you are killed with no negotiation.

    Termination grace period