Slide 45 of 82Ivory & CobaltOpen full tutorial

Priority, preemption and disruption budgets

Preemption flow and PodDisruptionBudget semantics.

Raw HTML

Study notes

  • PriorityClass gives Pods a numeric importance. When a high-priority Pod cannot be scheduled because the cluster is full, the scheduler's PostFilter step checks whether evicting lower-priority Pods on some node would make room, and if so it evicts them (they get their normal graceful termination) and schedules the high-priority Pod there. Reveal the four steps with the right arrow.
  • A PodDisruptionBudget solves a different problem: voluntary disruptions such as kubectl drain, node upgrades and autoscaler scale-down. It states how many Pods of an application must remain available (minAvailable) or may be unavailable (maxUnavailable). The eviction API refuses to remove a Pod if that would violate the budget, so rolling node upgrades proceed at a safe pace.
  • The precise interaction to remember: the scheduler's preemption tries to honour PDBs when choosing victims, but PDB protection is not absolute against preemption. If there is no victim set that respects the budgets, preemption can still proceed to place a more important Pod. PDBs guarantee safety during voluntary operations; they are not a shield from priority.
  • Gotchas: a PDB that sets minAvailable equal to the replica count blocks all drains and stalls node upgrades; and a PDB on a single-replica Deployment means that Pod can never be evicted. Review PDBs before every upgrade, which Deck 6 covers in detail.

Deck map

01
Kubernetes, from zero to operator
02
Seven decks, one continuous path
03
Five questions you would otherwise answer by hand
04
From Borg to a universal control plane
05
Declare the state; controllers close the gap
06
Brain and muscle: control plane and worker nodes
07
Managed or self-managed: who owns which layer
08
Orientation on one page: five questions, five automatic answers
09
Core objects: the vocabulary of every manifest
10
A Pod is the smallest thing Kubernetes runs
11
Every manifest has the same five-part shape
12
Labels are the glue between objects
13
Namespaces partition one cluster; contexts choose where kubectl points
14
kubectl: get, describe, events first
15
Keep configuration out of the image
16
Probes tell Kubernetes when to restart and when to send traffic
17
Core objects on one page
18
The control plane: the brain that decides and records
19
Everything talks to one front door
20
Every request passes three gates before it is stored
21
Admission webhooks: mutate first, then validate
22
etcd is the cluster's entire memory
23
Raft: a majority must agree before any write commits
24
etcd needs housekeeping: compact, then defragment
25
Controllers compare desired with actual, forever
26
Only one controller manager acts: leader election with a Lease
27
The API server scales out because it is stateless
28
CRDs and aggregated APIs extend the API in two different ways
29
Versions, ports and health checks you will actually use
30
The control plane on one page
31
Worker nodes: where containers actually run
32
The kubelet is the node's local agent
33
Nodes report in; silence is tolerated, then acted on
34
kube-proxy builds Service routing; the runtime runs containers
35
The full journey from kubectl apply to a running container
36
From kubectl apply to a running Pod on one page
37
Scheduling: deciding where every Pod runs
38
Two phases: rule out, then rank
39
The scheduler is a pipeline of plugins
40
Requests decide placement; limits decide enforcement
41
Namespaces get budgets and defaults
42
Taints repel; tolerations are permission slips
43
Node affinity: Pods choosing their nodes
44
Spread replicas across failure domains
45
Priority, preemption and disruption budgets
46
Scheduling on one page
47
Workloads: the objects that create and manage Pods
48
Deployment owns a ReplicaSet, which owns the Pods
49
A rolling update replaces Pods gradually and waits for readiness
50
StatefulSet: stable identity and storage
51
DaemonSets run everywhere; Jobs run to completion
52
Init containers run first; native sidecars live alongside
53
Choosing the right workload object
54
Workloads on one page
55
Networking: flat Pod IPs, stable Services, controlled traffic
56
Every Pod gets its own IP, reachable without NAT
57
A Service is a stable address for changing Pods
58
Headless Services and the EndpointSlice behind every Service
59
CoreDNS turns names into Service IPs
60
NetworkPolicy: from default-open to default-deny
61
Ingress and Gateway API bring HTTP traffic in
62
A request from the internet to a Pod
63
Networking on one page
64
Storage: data that outlives Pods
65
A claim asks, a class provisions, a driver delivers
66
Zones and access modes decide whether a volume can attach
67
CSI adds snapshots, clones and online expansion
68
Storage on one page
69
Real-world platforms: GKE, EKS and an on-prem Rancher fleet
70
The Shopwave estate: three platforms, one Git repository
71
Same manifest, three platforms: what actually changes
72
Rancher: one control point for many clusters
73
Three foundations-level incidents, one cause each
74
kubectl cheat sheet for this deck
75
Who owns what on one page
76
What you should be able to explain now
77
Quiz 1 of 5: Architecture and control plane
78
Quiz 2 of 5: Control plane, scheduling and failures
79
Quiz 3 of 5: Scheduling, workloads and platforms
80
Quiz 4 of 5: Workloads, probes and Services
81
Quiz 5 of 5: Networking and storage
82
Your score and what to review