Posting this answer as community wiki as the answer for this question could be opinionated.
Based on its github page, it is recommended to be set up as a sidecar container as opposed to a cluster service.
Not only the site you mentioned but also the official documentation of CloudSQL
:
To access a Cloud SQL instance from an application running in Google Kubernetes Engine, you can use either the Cloud SQL Proxy (with public or private IP), or connect directly using a private IP address.
The Cloud SQL Proxy is the recommended way to connect to Cloud SQL, even when using private IP. This is because the proxy provides strong encryption and authentication using IAM, which can help keep your database secure.
Cloud.google.com: SQL: Docs: MySQL: Connect Kubernetes Engine: Introduction
It seems reasonable to create a service instead.
You can read why using proxy is more advised instead of spawning a service:
We recommend this over running as a separate service for several reasons:
- Prevents your SQL traffic from being exposed locally; the proxy provides encryption on outgoing connections, but you need to limit exposure for incoming connections
- Prevents a single point of failure; each application's access to your database is independent from the others, making it more resilient.
- Limits access to the proxy, allowing you to use IAM permissions per application rather than exposing the database to the entire cluster
- Allows you to scope resource requests more accurately; because the proxy consumes resources linearly to usage, this pattern allows you to more accurately scope and request resources to match your applications as it scales
Cloud.google.com: SQL: Docs: MySQL: Connect Kubernetes Engine: Run the CloudSQL proxy as a sidecar
As for the number of active connections (it's different depending on used solution):
Also it could be beneficiary to add (effective management of connections to a database):
Additional resources: