Module 8

Real-world platforms

The Kubernetes API is the same everywhere, but who runs each layer, and what the platform adds around it, changes your daily job. Shopwave runs all three kinds.

Why it matters. Platform choice decides which incidents you can have. On managed clusters you will never lose etcd; on-prem you must plan for it. Knowing the difference lets you choose and operate deliberately.

After this module you can answer

Which parts of a cluster does each platform own?
What changes between GKE, EKS and on-prem for the same manifest?
What does Rancher add for a fleet of clusters?
How do foundations-level failures look in practice?

What is inside

1The Shopwave estate

2Same manifest, three platforms

3Rancher fleet management

4Three incidents

5kubectl cheat sheet

6Module infographic

7Recap checklist

Real-world platforms: GKE, EKS and an on-prem Rancher fleet

Module 8 applies everything to real platforms. Decks 2 and 3 go deep on GKE and EKS, and Deck 4 covers on-prem and Rancher in depth. Here we establish the map: what stays identical, and what each platform changes.

The Shopwave estate is deliberately mixed, because most organisations end up with more than one cluster type through acquisition, regulation or latency needs: a GKE Autopilot cluster for the main storefront, an EKS cluster inherited with an acquired brand, and on-prem clusters in warehouses where connectivity is unreliable.

Use this module as the bridge to the cloud-specific decks. Everything you learned in modules 1 to 7 applies unchanged; the differences are in provisioning, identity, load balancing, storage classes and upgrades.