Cloud Run or GKE: the four questions that decide it
Most teams running GKE would be better served by Cloud Run, and a few running Cloud Run are fighting it. The decision is not about scale — it is about four specific requirements.
"We need Kubernetes because we will scale" is the most expensive sentence in cloud architecture. Cloud Run scales to thousands of instances and down to zero, so scale is not the axis. The axis is what your workload needs that a request-scoped container cannot give it.
Four questions decide it, and you can answer all four this afternoon.
1. Do you need something running when no request is arriving?
Background consumers, long-lived connections, leader election, in-memory caches that must stay warm, cron that must not overlap. Cloud Run has answers to some of these now — jobs for batch, a minimum instance count for warmth, and CPU allocated during the whole instance lifetime rather than only during requests — but each answer costs a bit of the simplicity you came for.
If the honest answer is "yes, a lot", you are describing a deployment, not a service, and GKE is the better fit.
2. Is your unit of deployment one container or a pod of several?
Sidecars are the quiet deciding factor. Service mesh proxies, log shippers, credential refreshers, a Cloud SQL proxy. Cloud Run supports multiple containers per service, which covers the common cases. But if your platform team has built an opinionated pod template with four sidecars and a set of admission webhooks that enforce it, you have already built a platform on Kubernetes, and moving to Cloud Run means rebuilding it.
3. Do you need cluster-level primitives?
StatefulSets with persistent volumes, DaemonSets, custom operators, CRDs, node affinity for licensed software, GPUs with specific driver requirements. These are genuine Kubernetes features with no Cloud Run equivalent. If you use them, the decision is made.
Be honest about whether you use them or merely have them. A cluster whose only StatefulSet is a Redis you could replace with Memorystore is not a StatefulSet requirement.
4. What is your team's operational budget?
Cloud Run has no nodes, no upgrades, no autoscaler tuning, no CNI, no ingress controller to patch. GKE Autopilot removes some of that but not the cluster concept, the manifests or the Kubernetes learning curve. For a team of five shipping web services and APIs, Cloud Run is often a quarter of the operational surface for the same outcome — and the Autopilot versus Standard question only becomes relevant once you have decided you need a cluster at all.
The cost comparison, done properly
Cloud Run bills per request-second of allocated CPU and memory, with generous scaling to zero. GKE bills for nodes continuously.
- Spiky traffic with quiet nights: Cloud Run wins clearly, often by a lot, because your staging environments cost nothing overnight.
- Steady high traffic, 24/7: GKE with committed use discounts and Spot nodes wins, and the gap widens with volume.
- Many small services: Cloud Run wins, because on GKE each service still needs at least a pod's worth of requested capacity, and the packing loss adds up.
Cloud Run's committed use discounts narrow the gap for steady load, so price both with real traffic numbers rather than assuming.
What we usually recommend
Start on Cloud Run. Web services, APIs, webhooks, scheduled jobs and event consumers all fit, and you can move to GKE later because the artefact is the same container image. That portability is the real argument: the migration cost from Cloud Run to GKE is manifests and a pipeline, not a rewrite.
Move a workload to GKE when it earns it — when it needs the primitives from question three, or when steady-state cost analysis says so with real numbers.
Run both, deliberately. The common shape we deploy is Cloud Run for the request-serving tier and internal tools, GKE for the stateful and background platform. One VPC, one service mesh boundary if you need it, and Cloud Run's direct VPC egress so services reach private databases without a connector.
The mistake to avoid is the default assumption in either direction: adopting Kubernetes because it is what serious companies use, or refusing it when you are visibly fighting Cloud Run's model. Both are expensive, and the second is rarer but more painful. We make this call early in most cloud engagements because everything else follows from it.
What to do this week
List your services and answer question one for each: does it need to be running when no request is arriving? The ones where the answer is no are Cloud Run candidates today, and they are usually the majority.