Rancher: one control point for many clusters
Rancher's management server, provisioned and imported downstream clusters, and Fleet GitOps.
Study notes
- Rancher is a management plane for Kubernetes fleets. A Rancher server runs in its own cluster and provides a UI and API, central authentication and RBAC, and lifecycle management. It can provision RKE2 or k3s clusters on your infrastructure, and it can import existing clusters such as GKE and EKS so that access and policy are managed in one place while the cloud provider continues to run the control plane.
- Downstream clusters connect to Rancher through an agent that makes an outbound connection to the management server. That matters for locations such as the warehouse sites: they only need outbound connectivity, with no inbound ports exposed. Reveal the downstream clusters with the right arrow.
- Fleet, Rancher's GitOps engine, applies Git repositories to groups of clusters. Combined with labels (for example region=eu, role=warehouse), a single repository can deliver different configuration to different clusters. Other GitOps tools such as Argo CD are also common; the right choice depends on your team.
- Important property: downstream clusters are ordinary Kubernetes clusters. kubectl works against them directly and removing Rancher does not delete them, although you lose central management. Deck 4 covers Rancher provisioning, RKE2 and k3s architecture, MetalLB and air-gapped installs in depth.
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