DevOps

Exploring Cloud SQL Connectivity Options For Google Cloud Kubernetes (GKE)

Rehman Syed
Rehman Syed

Simplifying Connection Setup

Seamless connectivity is the quintessential ingredient in building scalable and reliable applications.

As organizations embrace containerized environments, it’s critical to streamline connectivity between Google Kubernetes Engine (GKE) clusters and Cloud SQL databases.

Streamlined connectivity offers several advantages, like reliable load balancing, enhanced security, and seamless scaling.

This article explores three powerful methods to simplify the GKE to Cloud SQL connection.

Method 1: Setup Database connections to Cloud SQL from local machine

This method is a popular choice for DEV environments, especially during the development and debugging phases. You can directly connect from a local environment to the Cloud SQL instance. As a result, you can view database tables and perform updates to leverage greater control using database clients like mysql, pgsql etc.

The setup involves running the cloud sql proxy binary executable on the local machine. Here’s how you can get started:

Download the Cloud SQL Proxy binary executable.
Authenticate your local machine with your GCP account using ‘gcloud auth login.’
Launch the Cloud SQL Proxy from the terminal, specifying the instance connection name with a command like cloud_sql_proxy -instances=INSTANCE_CONNECTION_NAME=tcp:5432.
With the proxy running, connect to the Cloud SQL instance from your local environment using a database client (e.g., mysql, pgsql) via 127.0.0.1:5432. Consequently, you can interact with the database as if it was local.

Method 2: Self Managed connections to Cloud SQL (Life before connectors)

This method gives complete control to the Developer. However, it comes with a cost of huge overheads involved in setting up TLS certificates.

Traditionally, self-managed connections process all security transactions (like encrypted TLS, etc.) on the App Side – which is a massive overhead.

While establishing secure access to a database, you must:

  • Provision SSL certificates
  • Enable secure certificate access for your application
  • Regularly rotate the SSL certificates
  • Manage database users & associated passwords
  • Initialize firewall rules to restrict database access

Well, the bottom line is that security is of paramount importance. However, can you employ a simplified approach?

Method 3: Using Cloud SQL connectors

Cloud SQL connectors refer to utilities that help establish a secure database connection. These utilities are available in both the binary and library forms.

Method 3a: Use Cloud SQL Language specific connectors
You can use Cloud SQL libraries for Java, Node, Go and Python to control everything from the application side.
However, what if your application isn’t based on any of the programming languages mentioned above?

Method-3b: Use Cloud SQL Auth Proxy in binary form
When a language-specific connector isn’t available, the Cloud SQL Auth Proxy is your best course of action.

The Auth Proxy is a binary that can be executed as a sidecar or background process, and works for any language that connects over a TCP or Unix Domain socket.

Method 3b-1: Sidecar Pattern
In the mechanical world, a sidecar gives the “parent” vehicle more power. A sidecar pattern in the Kubernetes domain serves a similar purpose.

This pattern lets the main Kube application container focus on its primary functionality while offloading database connectivity tasks to a sidecar container (Cloud SQL proxy runs as a sidecar in this case)

The sidecar approach shields your application container from the complexities of database connectivity. Consequently, you can decouple the two containers and ensure that scaling any one component doesn’t affect the performance of the other.

Implementation

The sidecar pattern involves deploying a sidecar container alongside the application container within the same pod.

Note: This approach involves configuring a Cloud SQL Proxy as a sidecar.

Here’s how to go about it:

Configure a secret with your database configuration.

2. To set up your Cloud SQL proxy:

a. Get the name of your instance connection.

b. Enable the Cloud SQL Admin API.

c. Get the JSON file of your service account with the necessary permissions.

3. Generate a Service account.

a. Create a credential key file:

b. Create a k8 secret from your credential file:

c. Configure the secret as a volume in your proxy container:

Configure the sidecar proxy container within your application pod.

Let’s evaluate the pros and cons of this approach:

Pros

✅ Simplified configuration

✅ Enhanced scalability

✅ Improved resilience

✅ Improved security

Cons

❌ Increased resource utilization

❌ Dependency on sidecar container

Contact us for a free consultation on leveraging the sidecar pattern for your Cloud SQL-GKE connectivity.

Method 3b-2: Cloud SQL Proxy Operator Pattern (in preview)

Google is working on a Cloud SQL Proxy Operator Pattern to incorporate more scalability and flexibility for connecting GKE and Cloud SQL.

This pattern features a dedicated Cloud SQL proxy operator deployed within the GKE cluster. The proxy operator is an effective intermediary for establishing secure connectivity between your GKE applications and Cloud SQL instances.

The Proxy Operator automates connection pooling, load balancing and encryption. Consequently, your GKE applications can interact with Cloud SQL databases without exposing sensitive credentials.

Implementation

To set up a Proxy Operator, follow these steps:

1.Install the Proxy Operator.

a. Use this code if you are using the Operator Framework:

b. If you are on Helm, use this code instead:

2. Define a Customer Resource (CR) YAML file for your Proxy Operator:

3. Configure parameters like the Cloud SQL Instance ID and Kubernetes Secret name (containing your database credentials)

4. Finally, leverage the Operator’s lifecycle management capabilities by using this command:

Let’s evaluate the pros and cons of this approach:

Pros

✅Simplified connectivity setup

✅Enhanced security

✅Improved performance

Cons

❌Currently in Preview (beta) status

❌Dependency on operator updates

Check out this alternative approach of using the auth proxy operator for connecting GKE to Cloud SQL.

Are you wondering which connectivity method would suit you best? Contact us for a free consultation.

Best Practices for Secure Cloud SQL Connectivity

Here are some critical things to consider to establish reliable GKE-Cloud SQL connections:

  • Use private IP connectivity for establishing all connections.
  • Consider using VPC peering or shared VPC for more direct and private communication.
  • Set up firewall rules to restrict incoming and outgoing traffic.
  • Assign appropriate IAM roles to your GKE nodes and Cloud SQL service accounts.
  • Regularly rotate credentials and secrets used for authentication.

Check out Google’s take on the best practices for Cloud SQL.

Wrapping Up

This article delved into the diverse Cloud SQL connectivity options tailored for GKE applications. The sidecar pattern, Cloud SQL operators and the Proxy Operator are all viable options for simplifying your GKE-Cloud SQL connectivity.

If you’re looking for ways to streamline your cloud application deployment, contact us for a free assessment of your cloud landscape.

Are you an AGENCY owner?

Become a white-label partner with us!

Please enable JavaScript in your browser to complete this form.