Cloud Run Known Issues

This page lists known issues for Cloud Run and Cloud Run on GKE.

Cloud Run

The following are known Cloud Run issues:

.Net is not supported

Cloud Run does not yet support .Net due to container sandbox limitations. Use Cloud Run on GKE to run .Net services.

Java JVM memory

The system information inside container instances of a Cloud Run revision always shows that the available memory is 2GB, even after you set the memory limit to a different value. Cloud Run currently does not show the container memory limit via /proc/cgroup/memory/lab1/memory.limit_in_bytes. Thus, the JVM will not be automatically configured with Cloud Run's memory limit.

Thus, the JVM will assume that the available memory is 2GB, and automatically adjusts to consume more memory than the assigned limit, which causes the container instance to be shut down for exceeding the available memory.

Accordingly, when you run applications in the JVM, you must configure and restrict the JVM memory usage as follows:

  • Use the parameter -XX:MaxRAM=256m, changing the value 256m to the memory limit value you set on the Cloud Run revision).

  • Change the default JVM Max Heap size from its default of 1/4 of the MaxRAM. You can change the Max Heap size using the -Xmx flag or using the parameter -XX:MaxRAMFraction.

The best way to set these parameters is to set an environment variable on the revision when you deploy to Cloud Run. The default environment variable to use with JVM is JAVA_TOOL_OPTIONS. For example:

JAVA_TOOL_OPTIONS="-XX:MaxRAM=256m"

gRPC and WebSocket support

WebSockets and gRPC are not currently supported for Cloud Run.

Cloud Run on GKE

The following are known Cloud Run on GKE issues:

Cannot enable Cloud Run on GKE through the Cloud Console

When you try to create a cluster with Cloud Run on GKE enabled, you receive an error stating:

Horizontal pod autoscaling must be enabled in order to enable the Cloud Run addon.

You can still create a cluster using the gcloud command line. For more information on creating a cluster from the command line, see Setting up Cloud Run on GKE.

Request logs are missing from the logs panel

Request logs are not displayed in the logs panel for services deployed to Cloud Run on GKE. These logs are available through Stackdriver.

To access the logs from Stackdriver:

  1. On the far right side of the logs panel, click the expand button to open the Stackdriver console.
  2. In the advanced query editor box at the top of the page, append the following text near the end of the query, before the severity >= DEFAULT clause:
OR  (labels.destination_workload:"hello" AND labels.destination_namespace:"default")
  1. Replace "hello" with the name of the service, and "default" with the namespace the service is deployed in.
  2. Click Submit Filter to refresh the displayed logs. Request logs will now be included in the logs display.

Default memory limit is not enforced through command line

When deploying using the command line, unless the --memory argument is used the deployed service will not have a memory limit. This allows the service to consume as much memory as available on the node where the pod is running, and may have unexpected side effects.

When deploying through the UI, the default value of 256M is used unless the value is overridden.

You can workaround this by defining a default memory limit for the namespace where you are deploying services with Cloud Run on GKE. For more information see Configuring default memory limits in the Kubernetes documentation.

Default CPU limit is not enabled

When deploying using the command line or Console, the amount of CPU a service can use is not defined. This allows the service to consume all available CPU in the node where it is running, which may have unexpected side effects.

You can workaround this by defining a default CPU limit for the namespace where you are deploying services with Cloud Run on GKE. For more information see Configuring default CPU limits in the Kubernetes documentation.

Note: By default, services deployed with Cloud Run on GKE request 400m CPU, which is used to schedule instances of a service on the cluster nodes.

Istio 1.0 limitations

Cloud Run on GKE uses Istio 1.0 for networking, which limits the number of services and revisions that can exist in a cluster. For more information on these limitations, see Istio 1.0 performance and scalability.

Cloud Run on GKE should not be used to deploy more than 150 services or 300 active revisions in the same cluster.

Contents of read/write points in the container are always empty

If you have a container creates files or folders in /var/log, for example, /var/log/nginx, when you run that container in Cloud Run on GKE, those files or folders will not be visible because an empty read/write volume has been mounted on /var/log, which hides the contents of the underlying container.

If your service needs to write to a subdirectory of /var/log, the service must ensure that the folder exists at runtime before writing into the folder. It cannot assume that the folder exists from the container image.

Was this page helpful? Let us know how we did:

Send feedback about...