Same Kubernetes API, very different operational ownership.

This course follows Shopwave through two realities: managed clusters on GKE and EKS, and a self-managed on-prem estate run with Rancher.

Layer	GKE	EKS	Rancher / kubeadm
Control plane (API, etcd)	Google	AWS	You
Control-plane upgrades	Google (channels)	You trigger	You
Worker nodes	Autopilot: Google	You, or Karpenter	You
CNI, CSI, ingress	Mostly built in	Add-ons you pick	You choose all
etcd backup	Not your job	Not your job	Your job
Your workloads	You	You	You

green provider-owned amber you own it

Shopwave: cloud estate

checkout and catalog on GKE Autopilot in europe-west1, a second copy on EKS in eu-west-1 for the acquired brand.

Shopwave: on-prem estate

Three warehouses run k3s edge clusters. Rancher manages the fleet; core data-centre clusters use RKE2 with MetalLB.

Rule of thumb: the more the provider owns, the less you tune and the more you must trust their defaults.

Managed or self-managed: who owns which layer

Kubernetes is one API, but who runs the control plane changes your job. On GKE and EKS the provider operates the API servers and etcd across multiple zones, patches them and backs them up. You decide what runs on the nodes and, depending on the product, how nodes are provisioned and upgraded.

On self-managed clusters (kubeadm, RKE2, k3s, Talos) you own everything: certificates, etcd backups, version skew and upgrades, load balancers (MetalLB), and storage. Rancher sits on top as a management plane that can provision RKE2/k3s clusters or import existing ones, giving you one UI, one RBAC model and fleet-wide policy.

Decks 2 and 3 go deep on GKE and EKS. Deck 4 covers AKS briefly and the on-prem toolchain properly. In this deck we stay at the level where all of them behave the same, then flag where the platforms differ.

Shopwave is our recurring example: a retailer whose cloud estate is split across GKE and EKS and whose warehouses run small k3s clusters, with Rancher as the fleet manager. Provider facts in the table are the general shape and should be checked against current documentation for your version.