The Shopwave estate: three platforms, one Git repository
Shopwave's platform team keeps a single Git repository of Kubernetes manifests and Helm charts and applies them with a GitOps tool to every cluster. The storefront runs on GKE Autopilot in europe-west1 so that Google handles nodes, scaling and most hardening. An acquired brand's workloads stay on EKS in eu-west-1, using Karpenter for node provisioning and the AWS Load Balancer Controller for ingress. The on-prem estate has a three-node RKE2 control plane in the data centre for the payments core, and three warehouse sites running small k3s clusters.
Reveal the four groups with the right arrow. The point is not that this is the ideal architecture but that it is realistic, and that each platform changes who carries which operational burden. On GKE and EKS the provider runs and backs up the control plane; in the data centre the team owns etcd backups, certificate rotation and upgrades; at the warehouses connectivity is intermittent, so clusters pull their desired state from Git rather than receiving pushes.
Rancher sits over the self-managed clusters (and can also import the managed ones) to give one place for authentication, RBAC, policy and upgrades. We look at it next. The cloud decks will return to GKE and EKS with this same scenario so that you see real decisions: Autopilot versus Standard, Karpenter versus managed node groups, and how identity works on each.
A caution about mixing estates: avoid features that exist on only one platform in the shared manifests, or isolate them in overlays. Provider-specific annotations, StorageClass names and identity bindings are the usual lock-in points.