Blog post

Cloud Run vs GKE: Which container abstraction is right for your startup?

2022-09-015 minute read

Google Cloud Platform (GCP) offers three container abstractions (or managed container services) to deploy and manage your applications:

Each of the above offers different features and is “managed” to varying degrees. Making them suitable for different applications and teams. This post lists all the differences between them to help you decide which of the three is the most suitable for your application.

A quick introduction

Cloud RunGKE StandardGKE Autopilot
Fully managed
All you need to give Cloud Run is a container, and it will take care of deploying, securing, autoscaling and monitoring.
Managed Kubernetes Control Plane
You manage the nodes yourself.
Fully-managed Kubernetes
Both the Kubernetes Control Plane and the node.

Feature comparison

Deployment

FeaturesCloud RunGKE StandardGKE Autopilot
Automated deploymentsManagedSelf-managedSelf-managed
HTTP load balancingSelf-managedSelf-managedManaged
Language supportAllAllAll
Operating systemList of supported imagesList of supported imagesOnly supports in-house Linux with Containerd (Can’t use Red Hat Enterprise Linux (RHEL), Linux with Docker, or Windows Server)
Stateful appsNot supportedSupportedSupported
Daemon workload type in KubernetesNASupportedSupported
Altering or adding new resources in the namespaceNASupportedNot supported

Nodes and node pools

FeaturesCloud RunGKE StandardGKE Autopilot
Node provisioning, node pools & setting cluster size:
1. Calculating what compute capacity your workload required

2. Choosing the size (CPU + RAM) of your nodes basis the required compute capacity for your workload

3. Choosing the size of your cluster which will house these nodes
ManagedSelf-managed:
You manually provision additional resources and set the overall cluster size.
Managed:
Dynamically provisions resources based on your Pod specification
Resource requestsLimited granularity of CPU and memoryFlexible CPU and memory sizesCPU resources must use increments of 0.25 CPUs. Autopilot automatically adjusts your requests to round up to the nearest 250m. For example, if you request 800m CPU, Autopilot adjusts the request to 1000m (1 vCPU).

The ratio of pod vCPU and memory should be in the range of 1:1 to 1:6.5. If this ratio is outside the allowed range for your selected compute class, Autopilot automatically increases the smaller resource. This impacts small services that will likely be overscaled to match this ratio.

Limits are set to the same values as requests
Pod bursting:
Ability to configure pods to burst into unused capacity on the node
Not supportedSupportedNot supported.
Since all Pods have limits set on requests, resource bursting is not possible. It is important to ensure that your Pod specification defines adequate resources for the resource requests and does not rely on bursting.
Pod affinity and anti-affinityNot supportedSupportedLimited support
Changing nodes:
Such as changes to the underlying machine type if your workloads have specific compute requirements
Not supportedSupportedNot supported 
Node auto-repair:Liveness and Readiness health checksManagedSelf-managedManaged
Node auto-upgradeManagedSelf-managedManaged
Maintenance windowsManagedSelf-managedManaged
Surge upgradesManagedSelf-managedManaged

Auto scaling

FeaturesCloud RunGKE StandardGKE Autopilot
Scale to 0SupportedNot supportedSupported
Cloud Run automatically scales to the number of container instances needed to handle all incoming requests.
Node auto-provisioningNASelf-managedManaged
Cluster autoscalingNASelf-managedManaged
Horizontal pod autoscaling (HPA)NASelf-managedSelf-managed
Vertical Pod autoscaling (VPA)NASelf-managedSelf-managed

Networking

FeaturesCloud RunGKE StandardGKE Autopilot
VPC networksManagedSelf-managed:
VPC-native traffic routing for public and private clusters
Managed:
VPC-native traffic routing for public and private clusters
Intranode visibilityNASelf-managedManaged
Private networkingSelf-managedSelf-managedSelf-managed
Cloud NATSelf-managedSelf-managedSelf-managed
Authorized networksNo supportedSelf-managedSelf-managed

Integrations & add-ons

FeaturesCloud RunGKE StandardGKE Autopilot
Helm chartsNot supportedSupportedNot supported
Support for Calico network policyNASupportedNot supported
Cloud Build integrationSupportedSupportedNot supported
LoggingManagedManagedManaged
MonitoringManagedManagedManaged
External monitoring toolsSupportedSupportedNot supported
Since most external monitoring tools require access that is restricted
Configuring 3rd party storage platformsNot supportedSupportedNot supported
Configuring 3rd party network policiesNot supportedSupportedNot supported

Security

FeaturesCloud RunGKE StandardGKE Autopilot
Shielded nodes, Workload Identity, Secure bootNASelf-managedManaged
Customer-managed encryption keys (CMEK)Self-managedSelf-managedSelf-managed
Access ControlSelf-managed: IAMSelf-managed: RBAC & IAMSelf-Managed: RBAC & IAM
Application-layer secrets encryptionSelf-managedSelf-managedSelf-managed
Container threat detectionNot supported: Container Threat Detection supports only Container-Optimized OS node images.Self-managedNot supported
Binary authorizationSelf-managedNot supportedSupported
SLAService SLAControl plane SLAControl plane and pod SLA 

Other features

FeaturesCloud RunGKE StandardGKE Autopilot
BillingPay per usePay per node (CPU, memory, boot disk)Users pay the assigned amount regardless of the node resources used.Pay per use (CPU, memory, and ephemeral storage)Users pay only for the CPU, memory, and storage used.
InteroperabilityYou can use GKE Standard with or without Cloud RunYou can use GKE Standard with or without Cloud RunYou cannot convert from Standard clusters to Autopilot clusters or vice versa

What should you choose?

Go with Cloud Run when:

  1. You don’t want to use Kubernetes
  2. AND you want to run stateless containerized microservices
  3. AND app devs are going to manage the build and deploys of your microservices (No ops)
  4. AND there are minimal third party dependencies like clickhouse or grafana etc.

Go with GKE Standard when:

  1. You need to run your services on Kubernetes
  2. AND you need advanced scalability and configuration flexibility to orchestrate your containers, such as
    1. Number of containers
    2. CPU and memory
    3. Networking
    4. Observability
    5. Security
  3. Highly compute-intensive workloads that require high-performance compute platforms
  4. Stateful applications, cronjobs etc.
  5. AND you have a dedicated devops expertise to set up and manage your GKE.

Go with GKE Autopilot when:

  1. You do not need the flexibility offered by GKE Standard
  2. AND if your workloads meet Autopilot constraints
  3. AND you have a dedicated devops expertise to set up and manage your GKE.

In general, use the highest level of abstraction when you're starting out. This enables you to use the most optimal technologies without having to learn them in detail. Over time, as you build your knowledge and as your use-cases become more complex, you can start moving to less abtracted offerings.


Argonaut is an orchestration layer above your own cloud account (AWS/GCP). Its developer-experience helps you get started with GKE (standard) deployments offering full flexibility yet simple to use, in minutes. It's fully customizable and quickly integrates with a large ecosystem of third-party tools like Helm-charts, Datadog, Redis, and CloudSQL. Get started with Argonaut now.

Last post

Top 20 Observability Tools Every Startup Should Know About in 2022

16 September 2022
observabilityresource
Next post

Argonaut launches GCP Support

30 August 2022
product-updatesgcp