12

I'm new to GCP and trying to make heads and tails of it. So far, I've experienced with GKE and Cloud Run.

In GKE, I can create a Workload (deployment) for a service of any kind under any port I like and allocate resources to it. Then I can create a load balancer and open the ports from the pods to the Internet. The load balancer has an IP that I can use to access the underlying pods.

On the other hand, when I create a Could Run service, I'll give it a docker image and a port and once the service is up and running, it exposes an HTTPS URL! The port that I specify in Cloud Run is the docker's internal port and if I want to access the URL, I have to do that through port 80.

Does this mean that Cloud Run is designed only for HTTP services under port 80? Or maybe I'm missing something?

Mehran
  • 15,593
  • 27
  • 122
  • 221

2 Answers2

9

Technically "no", Cloud Run cannot be used for non-HTTP services. See Cloud Run's container runtime contract.

But also "sort of":

  1. The URL of a Cloud Run service can be kept "private" (and they are by default), this means that nobody but some specific identities are allowed to invoked the Cloud Run service. See this page to learn more)
  2. The container must listen for requests on a certain port, and it does not have CPU outside of request processing. However, it is very easy to wrap your binary into a lightweight HTTP server. See for example the Shell sample that Uses a very small Go HTTP sevrer to invoke an arbitrary shell script.
Steren
  • 7,311
  • 3
  • 31
  • 51
  • 2
    Thanks, but just to be clear, Cloud Run only accepts HTTP requests. Right? I'm a little skeptical about this because I thought Cloud Run is a managed version of GKE and as such, I was expecting it to support any protocol. Now that you say Cloud Run does not have CPU outside of request processing, that shatters all my understanding. – Mehran Jul 26 '20 at 23:54
  • 1
    I mean what's the use case for Cloud Run then? I would rather use Cloud Functions! – Mehran Jul 26 '20 at 23:55
  • @Mehran Read this link to get a better understanding of Cloud Run: https://cloud.google.com/run/docs/reference/container-contract – John Hanley Jul 27 '20 at 00:45
  • Thanks, I understand the use case for Cloud Run now. To me, it seems only a valid tool when you want to migrate your existing code to GCP. If I'm developing a brand new project, I don't see why I should use Cloud Run over Cloud Function. One last question, is there any managed version of GKE? For instance, AWS has Fargate as a managed version of Kubernetes. Does GCP have a comparable product? I could not find any! – Mehran Jul 27 '20 at 00:55
  • 1
    Cloud Run vs Cloud Functions: Coud Run allows you to use any language and or add any binaries, you can have more than one request at a time per instance (concurrency), you can add your own custom domains. – Steren Jul 27 '20 at 01:59
  • 1
    Cloud Run is not a managed version of GKE. GKE is a managed version of Kubernetes. Cloud Run is a fully managed version of Knative. – Steren Jul 27 '20 at 02:02
  • The reason why I confused Cloud Run as a managed GKE is because in this [page](https://cloud.google.com/docs/compare/aws) they've put it in front of Fargate. Someone needs to change that page. – Mehran Jul 27 '20 at 16:11
1

To keep this question relevant, I would like to add some updates since the accepted answer was posted. In the end of 2021 Google announced new CPU allocation controls. As mentioned on Use Cloud Run "always-on" CPU allocation for background work:

With this release, users can now alter this behavior so the CPU is always allocated and available even when there are no incoming requests (so long as the container instance is up). Setting the CPU to be always allocated can be useful for running background tasks and other asynchronous processing tasks.

Along with this, you also have the option to not allow public incoming traffic, if that's what you are interested in.

m.spyratos
  • 3,823
  • 2
  • 31
  • 40