What’s new in Cloud Run 2022
Top 5 problems that Cloud Run solved for me in 2022.
Since the year started Cloud Run has been enabled for 6 new regions and implemented a lot of new features.
Problem 1: How to start my container faster without adding more CPU cores?
Considering the cost-saving measure, it is recommended to assign only the necessary CPU cores for the Cloud Run container. But it would be great if we can start the container faster without adding more CPU permanently.
Now there is a new feature in Cloud Run, Startup CPU Boost. This feature allows you to start your container with more CPU cores during the startup time. Once your container starts listening for requests, the number of cores gets reduced to a defined limit. Requests will be sent to the container instance as soon as it is listening on the configured port.
You are charged for the allocated boosted CPU for the duration of the container startup time. For example, if your container startup time is 10 seconds and you allocate 2 CPU cores, AND you enable startup boost, you’ll be charged for 4 CPU cores during the 10 seconds startup time.
Existing Services:
gcloud beta run services update SERVICE --cpu-boostDuring Deployment:
gcloud beta run deploy --image IMAGE_URL --cpu-boost
Problem 2: How do I configure a health check for my containers inside Cloud Run?
Cloud Run provides 2 types of health checks.
- Startup Checks
Startup checks use an HTTP startup probe to check whether a container has started properly and is healthy.
After the startup probe is configured, Cloud Run makes an HTTP GET request to the service health check endpoint (for example, /ready). Any response between 200 and 400 is a success, everything else indicates failure. If a startup probe does not succeed within the specified time, which cannot exceed 240 seconds, the container will be shut down.
- Liveness Checks
Once we have started our application, we need to ensure our application is healthy and responds fairly all the time. The startup check can only determine whether we start successfully launched the application or not.
We can use liveness checks over regular intervals. After the liveness probe is configured, and any startup probe is successful, Cloud Run makes an HTTP GET request to the service health check endpoint (for example, /health). Any response between 200 and 400 is a success, everything else indicates failure. If a startup probe does not succeed within the specified time, which cannot exceed 240 seconds, the container will be shut down.
Note: Currently we can only configure health checks via the YAML files. Any changes to the file create a revision of the container instances
Problem 3: Can I deploy containers based on OCI standards?
At a very high level, an image consists of several components including an Image Manifest, Image Index, Artifact Manifest, Image Layout, and Filesystem along with bundle config and descriptor.
Unlike the image index, which contains information about a set of images that can span a variety of architectures and operating systems, an image manifest provides a configuration and set of layers for a single container image for a specific architecture and operating system.
Recently Cloud Run adopted the OCI standard of the images. This ensures Cloud Run is more compatible with the open standards.
"mediaType": "application/vnd.oci.image.manifest.v1+json"Problem 4: Is it possible to redirect the sequential requests to the same revision container instance from a given client?
Ideally, we need to consider instances such as stateless machines and requests can be processed in any instance of our application. But there are situations where we would like to get the sequential requests to the same container for various reasons, like optimizing performance, caching, reusing existing connections, etc.
Now we can use the Session Affinity feature in Cloud Run for this same use case. Cloud Run uses a session affinity cookie with a TTL of 30 days and inspects its value to identify multiple requests by the same client and directs all these requests to the same instance.
gcloud beta run services update SERVICE --session-affinityHowever, note that the container instance can receive requests from different clients. Session affinity does not mean that the container instance is dedicated only to one client.
Problem 5: Is it possible to configure Cloud Run Instance with less than 1 CPU?
Recently Cloud Run updated the minimum CPU limit as 0.08. In other words, we can configure a Cloud Run Instance with a power of 8% of a single core CPU.
If you want to use less than 1 CPU, you can select any value between 0.08 and 1, in increments of 0.01. Any value above 1 must be an integer value.
References:
