Deployments and Services are portable; the plumbing around them is not.

The left column is stable Kubernetes. The three right columns are what each platform plugs in.

Concern	GKE	EKS	On-prem RKE2 / k3s
type: LoadBalancer	Google Cloud load balancer	AWS load balancer through the AWS Load Balancer Controller	MetalLB (layer 2 or BGP) or kube-vip
Default StorageClass	Persistent Disk or Hyperdisk CSI	EBS CSI (gp3)	Longhorn, Rook-Ceph or NFS: you install it
Gateway or Ingress	GKE Gateway controller	AWS Load Balancer Controller, VPC Lattice	Envoy Gateway, NGINX, Traefik
Workload to cloud identity	Workload Identity Federation	IRSA or EKS Pod Identity	OIDC, Vault, SPIFFE: you design it
Node scaling	Autopilot or cluster autoscaler	Karpenter, managed node groups, Auto Mode	Rancher or Cluster API machine pools
Control-plane upgrade	Release channels, automatic	You trigger it, AWS performs it	You run it: kubeadm, RKE2 upgrade plan

Keep portable

Deployment, Service, ConfigMap, HPA, NetworkPolicy, PDB, probes and requests are identical everywhere.

Isolate in overlays

Annotations for load balancers, StorageClass names and identity bindings. Use Kustomize overlays or Helm values per platform.

Verify per platform

Product names and defaults evolve quickly. Check the current docs of each provider before committing a design.

Same manifest, three platforms: what actually changes

The core objects you have learned in this deck are identical on every conformant Kubernetes cluster. A Deployment, a Service, a ConfigMap, a probe, a resource request and a NetworkPolicy are the same YAML on GKE, EKS and RKE2. This portability is the reason Kubernetes won.

What changes is everything around the cluster, supplied through the same plugin interfaces you met in earlier modules. type LoadBalancer is realised by a cloud controller on GKE and EKS and by MetalLB on bare metal. The default StorageClass is a CSI driver for the platform's block storage, or something you install yourself on-prem. Workload identity (how a Pod gets cloud credentials without static keys) is a first-class product on both clouds, and a design decision on-prem.

Upgrades illustrate the ownership difference most clearly: GKE can upgrade the control plane automatically on a release channel, EKS requires you to initiate control-plane and node upgrades, and on-prem you run the whole sequence yourself with kubeadm, RKE2 upgrade plans or Rancher. Deck 6 covers upgrade strategy in depth.

The practical advice is the third card: assume details have changed since this was written. Product names, defaults and limits evolve quickly, so verify in current documentation. Deck 2 and Deck 3 do this for GKE and EKS respectively.