What does "Cloud Run on Google Kubernetes Engine" mean? Is there anything beyond the idea that a plain docker container can run on Cloud Run or on GKE?
Product manager for Cloud Run on GKE here. Cloud Run on GKE brings a managed experience for Knative/serving and Istio that aligns with Cloud Run. We install and manage the Knative version in your cluster and keep it running for you. Above what you get with base Kubernetes ability to deploy a container, Cloud Run on GKE gives you request-based auto-scaling of container instances, network programming with Istio, and St…
Does this mean that by using Cloud Run GKE I can also leverage the primitives provided by Istio and Knative Serving?
Memory is a difficult one, especially in garbage-collected languages which have a habit of filling up the heap even when it's not used, so it's not always obvious how much memory is actually being used without having language/runtime specific signals. The mitigation in Cloud Run is both concurrency, and that you're only billed while a request is active. (Disclosure: Google Cloud PM)
> Memory is a difficult one, especially in garbage-collected languages which have a habit of filling up the heap even when it's not used, so it's not always obvious how much memory is actually being used without having language/runtime specific signals. I'm not sure what do you mean here, Cloud Run uses Docker which runs regular processes in a cgroup, so it's sufficient to check the cgroup memory usage, right? Yes, J…
Cloud Run is built upon Knative so it runs inside k8s (which uses CRI API of a backend, Docker or any other alternative) which handles OOM by inner resource manager, not cgroups.
thanks for all the helpful comments here! we run a rails app. if we want to replace heroku with a google cloud service, would cloud run be the best one?
I'll post the example source code here tomorrow after the talk (still tweaking it).
OK thanks! How about persisting files (which actually isn't possible on Heroku but we would like to persist files on disk for simplicity so are debating about just using AWS)?
Serverless with gRPC would be awesome. There's grpc-gateway, but native support would be even better. Surely it won't take long - the product itself has a gRPC API: https://cloud.google.com/run/docs/reference/rpc/
Depending on your use case, there is a way to proxy gRPC to Cloud Run in a slightly hacky way leveraging the fact that outbound gRPC works.
You can run in GCE a gRPC server that whenever it gets a gRPC request, it temporarily stores the gRPC message and associates it with a session ID. It then sends a HTTP request to Cloud Run with that session ID. Then your Cloud Run instance will take that session ID to make a gRPC connection to your gRPC server in GCE. This GCE instance will then take the session ID, retrieve the gRPC request, and forward it to the Cloud Run instance.
This is admittedly hacky, but depending on your use case, may be good enough.
https://cloud.google.com/run/docs/reference/container-contra... Details the contract your container must meet to run on the service and limitations you might run into Quite a nice document to be fair. Would be interested in hearing what use cases people would use this for, over say Cloud Functions or AWS Lambda. I'd imagine the flexibility of being able to run anything that supports HTTP is quite attractive. One thin…
Oh! It's great documentation, sucint, clear, to the point...
I'll post the example source code here tomorrow after the talk (still tweaking it).
OK thanks! How about persisting files (which actually isn't possible on Heroku but we would like to persist files on disk for simplicity so are debating about just using AWS)?
We provide an in-memory writable filesystem (e.g. you want to do file transformations) but it's not persistent across all instances. We're looking into Filestore integration for a mountable NFS product, though as mentioned in another comment about that, reading is easy but writing is hard.
Check out Cloud Scheduler ( https://cloud.google.com/scheduler/ ) which can target an arbitrary HTTP URL, and will support authenticated push to securely target Cloud Functions and Cloud Run (I think this is going to public beta this week).
Note to Firebase team: I use exactly this (a Cloud Scheduler job that pushes to a pub/sub topic, and then set a Firebase function that runs on a topic trigger) to schedule functions, but would be really nice if I could just create a triggered cron function like this: functions.cron.schedule('0 0 * * *').onSchedule(...) or something like that. Even if it behind the scenes it just did exactly what I'm doing manually no…
We are working on this right now, so stay tuned :)
To Google people, do you have any suggestions for startups how to start using your services for production workloads and: 1) Not having to take the $250 monthly fee per dev that needs to be able to contact you. Just increases the start cost massively for your services. 2) Not having to worry about being hell-banned and not being able to restore your account with Google, such as "guilty-by-association" for devs in Pla…
Hell-banning is by far my biggest fear with Google. The idea that you could be banned for life without any explanation just seems completely insane. It feels dystopian.
Disclosure: Cloud Run Engineer I'd encourage you to test your particular app, but you should expect similar cold start times in Cloud Run. You can set "Maximum Requests per Container" on container deployment so you are in control whether a container has single concurrency (i.e. "Maximum Requests per Container = 1"). If your app is not CPU-bound and you allow multiple concurrent requests (the default) you should see f…
Thanks very much! Could you answer the following questions about cold start times in Cloud Run or point me to a good resource: 1. I think I have a pretty good understanding of what's going on with the lifecycle of Cloud Functions that leads to the cold start times. What happens with Cloud Run? Does it need to download the whole Docker image to a machine to run it? Seems like that would take longer. 2. App Engine has…
1. Both cases grab the image and run it. Better per-layer caching (including very aggressive caching of common layers) is coming soon, so stay tuned.
2. No current equivalent, though there are thoughts on exposing more scaling control knobs (e.g. max-instances, min-instances). Max is easy, min is harder because of the cost implications. GAE was billed on "instance hours" but Run is CPU time, so if you go "min-instances=1" you're paying for a VM. Something like Run on GKE (where you're already paying for the compute) probably makes more sense to expose these controls.
3. Yes, though since Run can be multi-concurrent, for certain (most?) load profiles, you're going to have way fewer cold starts because the instance is already handling requests.
Hey folks, one of the Cloud Run PMs (along with @steren, @ryangregg, @lindydonna, @stewart27, and others). We're super excited to announce Cloud Run and Cloud Run on GKE, both implementing the Knative Serving API. Please let us know if you've got any questions!
I'm a student, mainly using GCP for hobby/hackathon projects, and to teach myself. I am massively excited about Cloud Run's free tier---for someone with a budget of zero, being able to get a project off the ground and functional without paying through the nose if you forget to turn down some service is incredibly useful. Getting an unexpected $40 App Engine bill at the end of the month isn't fun. I'm definitely going…
We're super excited to see what you build :D
Even silly things like https://howdelayedissfo.com (built over the weekend with Cloud Run and Firebase Hosting) are great ways to improve your skills without breaking the bank (projected costs are well within the free tier on both products).