readiness check for google cloud run - how? - google-cloud-run

Question

I've searched quite extensively in the documentation at https://cloud.google.com/run/docs/how-to. I also found the YAML in the console.cloud.google.com, but I can't edit it. Is there a way to set it up using a command I might have missed?
EDIT:
I couldn't find anything in https://cloud.google.com/sdk/gcloud/reference/beta/container/clusters/create about it either.
EDIT2:
I'm looking for a way to make Google cloud run have a readiness check for my app in a container. The same way that kubernetes does it - example here: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/. The problem is I don't want to have my service down for 30-60 seconds while the app in the container is still spinning up. Google instantly redirects the traffic causing users to wait for a long time when I push a new build.
EDIT3:
Here's the time it takes to make the first initial request after I've deployed a new version.
EDIT4:
The app I'm trying to start is in Python. It's a flask app serving a tensorflow model. I needs to load in several files into memory. This takes only 5-10seconds on my computer, but as you can it takes longer on cloud run.

Answer 1

Cloud Run does not have a readiness check other than confirming your service is listening on the specified port. Once that is done traffic starts routing to the new revision and previous serving revisions are scaled down as they wrap up in-progress requests.
If your goal is to ensure the service is ready ASAP after deployment, you might make a heavier entrypoint that takes care of more setup tasks.
A "heavier" entrypoint like this will help post-deploy responsiveness, at the cost of slower cold-starts.
Examples of things you can front-load in the entrypoint (whether in BASH scripts or in your service before turning on the HTTP server):
Perform all necessary setup tasks such as loading files into memory.
Establish and preserve in global state any clients or connections to backing services.
Perform via your service code any healthchecks that backing services and resources are available.
Warm up in-container caches to minimize the first response.
Again, this optimizes for post-deploy response by penalizing all cold starts.
https://cloud.google.com/run/docs/tips#optimizing_performance

Answer 2

Note: There's been a recent update and things have improved.
https://cloud.google.com/run/docs/configuring/healthchecks
"You can configure HTTP and TCP startup health check probes, along with HTTP liveness probes for new and existing Cloud Run services."
Oddly Cloud Run still doesn't allow readiness probes.
But startup and liveness probes are allowed.
The startup probe acts as a readiness probe for initial startup vs an ongoing readiness probe. That being said startup + liveness probe is probably sufficient in the majority of cases, if it fails it's liveness probe it'll still get removed from load balancing. And startup probe gives replacements enough time to finish booting up before receiving traffic.
Note I like to verify things, CloudRun makes it difficult and unintuitive to verify that the startup probe's initialDelaySeconds works as intended & their APIs are annoyingly limited in terms of being automation friendly.
That being said this will give you an idea of how it works:
# Edit Vars
export CR_SERVICE_NAME=startup-probe-test
export PROJECT=chrism-playground
export REGION=us-central1
# Set defaults
gcloud config set project $PROJECT
gcloud config set run/region $REGION
# Deploy a Hello World App for testing purposes
gcloud run deploy $CR_SERVICE_NAME \
--image=us-docker.pkg.dev/cloudrun/container/hello \
--allow-unauthenticated \
--max-instances=1
# Hacky Automation to workaround CloudRun's lack of good automation
gcloud run services describe $CR_SERVICE_NAME --format export > example.yaml
export TOP=$(cat example.yaml | grep " ports:" -B 1000 | grep -v " ports:")
export BOTTOM=$(cat example.yaml | grep " ports:" -A 1000)
export MIDDLE=$(echo """
startupProbe:
initialDelaySeconds: 60
timeoutSeconds: 2
periodSeconds: 10
failureThreshold: 3
httpGet:
path: /healthy
""" | sed '1d')
export REPLACE_NAME=$(echo "$TOP" | grep "name: $CR_SERVICE_NAME-")
export NEW_TOP=$(echo $TOP | sed s/$REPLACE_NAME/" name: $CR_SERVICE_NAME-new"/)
echo "$NEW_TOP\n$MIDDLE\n$BOTTOM" | tee updated-example1.yaml
export NEW_TOP=$(echo $TOP | sed s/$REPLACE_NAME/" name: $CR_SERVICE_NAME-newest"/)
echo "$NEW_TOP\n$MIDDLE\n$BOTTOM" | tee updated-example2.yaml
# Run these (should take about 3 mins for both to finish)
gcloud beta run services replace updated-example1.yaml
gcloud beta run services replace updated-example2.yaml
After copy pasting that bash you should see something like this:
Click the symbol near 1 in the image, then check the boxes to see Revision URLs & Actions, and press OK.
Create revision URLs original & startup-probe as shown, then click each to test.
When I clicked on the original tagged link the site loaded instantly
https://original---startup-probe-test-pxehf3xjcq-uc.a.run.app/
When I clicked on the startup-probe tagged link the site had a loading circle for 60 seconds, and then it worked as expected, which proves the startup probe worked as expected
https://startup-probe---startup-probe-test-pxehf3xjcq-uc.a.run.app/

Answer 3

they recently also added support for liveness and readiness probes in terraform using beta provider.
see https://cloud.google.com/run/docs/configuring/healthchecks#terraform_3