GKE Autopilot is an operating mode of GKE where Google manages the cluster. The significant advantage of this over normal GKE is that you only pay for the CPU, memory, and storage used when running on GKE Autopilot. For development, you only pay when your container runs, which will likely be a considerable saving to running a standard GKE cluster with idle capacity. You will get a chance to try GKE Autopilot in Chapter 14.
Cloud Run
The final option is Cloud Run. This is an easier way of running a container than using Kubernetes. In Google Cloud, Cloud Run is a managed service built on Borg. However, in Google’s on-prem Anthos offering, Cloud Run runs on Kubernetes. Cloud Run should be suitable for running nearly all containerized microservices and pay-per-use services, just like GKE Autopilot. Out of all the Google-hosted services, it is likely the most accessible and cheapest option for testing your container in development. You have already used Cloud Run a lot in this book, and hopefully, you understand its flexibility and why it is worth considering for most services.
Comparison of Development Container Runtimes
Table 10-3 summarizes the difference between the container runtime options.
| Table 10-3. A comparison of development container runtimes Runtime | Cost | Local overhead | Speed to redeploy |
| Local Kubernetes | Low | Yes | High |
| Shared GKE | High | No | Medium |
| GKE Autopilot | Medium | No | Medium |
| Cloud Run | Medium | No | Medium |
Choosing a Container Repository
If you are working with a local Kubernetes cluster like Minikube, there is no need to push your container to a registry, as it is available on your machine after building. However, if you are using a separate GKE cluster, GKE Autopilot, or Cloud Run, you will need to push it to a container registry. As you are in Google Cloud, it makes sense to use the provided Artifact Registry, but there are other options.
Artifact Registry or Container Registry?
In Google Cloud, Artifact Registry is currently the recommended service for container image storage. You may see references to Container Registry, which is Artifact Registry’s predecessor. There is no real reason to use Container Registry, as Artifact Registry has all the features of Container Registry, with extra features such as being able to store other types of artifacts and supporting both regional and multiregional hosts.
External Registry
You could alternatively use an external container registry such as docker.io; however, this will require extra configuration for authentication. It will also be slower both for pushing containers and pulling containers for deployment, so it is one of those things where it only makes sense to use an external registry if you have a good reason.
