This page lists known issues for Cloud Run and Cloud Run on GKE.
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
Cloud Run currently does not show the container memory limit via
Thus, the JVM will not be automatically configured with Cloud Run's
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
256mto 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
-Xmxflag or using the parameter
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:
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:
- On the far right side of the logs panel, click the expand button to open the Stackdriver console.
- 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 >= DEFAULTclause:
OR (labels.destination_workload:"hello" AND labels.destination_namespace:"default")
"hello"with the name of the service, and
"default"with the namespace the service is deployed in.
- 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/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.