Taints repel; tolerations are permission slips
Taints, tolerations and the three taint effects.
Study notes
- A taint is a key, value and effect attached to a node that repels Pods. A toleration on a Pod says it is allowed to ignore a matching taint. The default is closed: a tainted node accepts only Pods that tolerate it. Unlike affinity, which is the Pod choosing nodes, a taint is the node choosing which Pods it accepts.
- There are three effects. NoSchedule blocks new Pods that lack the toleration but leaves running Pods alone. PreferNoSchedule is a soft version the scheduler tries to honour. NoExecute also evicts running Pods without the toleration, which is how not-ready nodes and kubectl drain clear a node.
- The most common use is dedicating hardware: taint GPU nodes so that ordinary web Pods do not waste them, and give the GPU workloads the matching toleration. Note the subtlety shown on the slide: a toleration only permits scheduling, it does not attract. To make the GPU Pods land only on those nodes, combine the toleration with node affinity or a nodeSelector.
- On managed platforms you set taints on node pools: GKE node pool taints, EKS managed node group taints and Karpenter NodePool taints. Spot and preemptible pools are often tainted so that only interruption-tolerant workloads run there.
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