Consuming Google Cloud SQL on Tanzu Application Platform (TAP) with Config Connector


This topic demonstrates how to use Services Toolkit to allow TAP Workloads to consume Google Cloud SQL for PostgreSQL databases. This particular guide makes use of Config Connector to manage PostgreSQL instances in GCP.

This is describing the procedures to produce similar outcomes as in “Consuming AWS RDS on Tanzu Application Platform (TAP) with AWS Controllers for Kubernetes (ACK)”. The same points discussed in “Creating Service Instances that are compatible with Tanzu Application Platform” apply here too:

  • Neither of the resources discussed below adhere to the Service Binding Specification
  • We need to manage the lifecycle of multiple resources which together form a usable database instance

Note Please ensure you have met all prerequisites before reading on.

Note This usecase is not currently compatible with TAP air-gapped installations.

Creating Service Instances that are compatible with Tanzu Application Platform

The installation of the Config Connector Addon results in the availability of new Kubernetes APIs for interacting with Google Cloud resources, specifically Cloud SQL resources, from within the TAP cluster.

$ kubectl api-resources --api-group

NAME           SHORTNAMES                       APIVERSION                          NAMESPACED   KIND
sqldatabases   gcpsqldatabase,gcpsqldatabases   true         SQLDatabase
sqlinstances   gcpsqlinstance,gcpsqlinstances   true         SQLInstance
sqlsslcerts    gcpsqlsslcert,gcpsqlsslcerts   true         SQLSSLCert
sqlusers       gcpsqluser,gcpsqlusers    true         SQLUser

To create a CloudSQL service instance for consumption by Tanzu Application Platform, you can use a ready-made, reference Carvel Package. This step is typically performed by the role of the Service Operator. Follow the steps in Creating an CloudSQL service instance by using a Carvel Package.

Alternatively, if you are interested in authoring your own Reference Package and want to learn about the underlying APIs and how they come together to produce a useable service instance for Tanzu Application Platform, you can achieve the same outcome by using the more advanced Creating an CloudSQL service instance manually.

Once you have completed either of these steps and have a running CloudSQL service instance, please return here to continue with the rest of the use case.

Creating a Service Instance Class for Cloud SQL

We can now make the Cloud SQL Service Instance discoverable to Application Operators. This step is typically performed by the role of the Service Operator.

You can use Services Toolkit’s ClusterInstanceClass API to create a “Service Instance Class” to represent Cloud SQL Service Instances within the cluster. The existence of such classes make these logical Service Instances discoverable to Application Operators, thus allowing them to create Resource Claims for such instances and to then bind them to Application Workloads.

Create the following Kubernetes resource::

kind: ClusterInstanceClass
  name: cloudsql-postgres
    short: Google Cloud SQL with a postgresql engine
    kind: Secret
      matchLabels: cloudsql-postgres

In this particular example, the class states that claimable instances of Cloud SQL Postgresql are represented by Secret objects with label set to cloudsql-postgres. A Secret with this label was created earlier when you created the CloudSQL service instance.

Although this example uses, there is no special meaning to that key. The Service Operator persona can choose arbitrary label names and values. They might also decide to select on multiple labels or combine a label selector with a field selector when defining the ClusterInstanceClass.

Now that you have created a ClusterInstanceClass, you need to grant sufficient RBAC permissions to enable Services Toolkit to read the resources that match the pool definition of the instance class. For this example, create the following aggregated ClusterRole in your cluster:

kind: ClusterRole
  name: stk-secret-reader
  labels: "true"
- apiGroups: [ "" ]
  resources: [ "secrets" ]
  verbs:     [ "get", "list", "watch" ]

If you want to claim resources across namespace boundaries, you will have to create a corresponding ResourceClaimPolicy. For example, if the provisioned Cloud SQL instances exist in namespace service-instances and you want to allow App Operators to claim them for workloads residing in the default namespace, you would have to create the following ResourceClaimPolicy:

#! optional, when workload and services are in different namespaces
kind: ResourceClaimPolicy
  name: default-can-claim-cloudsql-postgres
  namespace: service-instances
    kind: Secret
    group: ""
      matchLabels: cloudsql-postgres
  consumingNamespaces: [ "default" ]

Discover, Claim and Bind to a Google Cloud SQL Postgresql Instance

The act of creating the ClusterInstanceClass and the corresponding RBAC essentially advertises to Application Operators that Cloud SQL Instances are available to use with their Application Workloads on Tanzu Application Platform. In this step you will learn how to discover, claim and bind to the Cloud SQL Service Instance previously created. Discovery and claiming of Service Instances is typically the role of the Application Operator while binding is typically a step for Application Developers.

To discover what Service Instances are available to them, Application Operators can use the tanzu services classes list command.

tanzu services classes list

  NAME                  DESCRIPTION
  cloudsql-postgres     Google Cloud SQL with a postgresql engine

Here you can see information about the ClusterInstanceClass created in the previous step. Each ClusterInstanceClass created will be added to the list of classes returned here.

The next step is to “claim” an instance of the desired class, but in order to do that, Application Operators must first discover the list of currently claimable instances for the class. Claimability of instances is affected by many variables (including namespace boundaries, claim policies and the exclusivity of claims) and so Services Toolkit provides a CLI command to help inform Application Operators of the instances that will result in successful claims. This command is the tanzu service claimable list command.

tanzu services claimable list --class cloudsql-postgres

  NAME                    NAMESPACE          KIND    APIVERSION
  sql-instance-claimable  service-instances  Secret  v1

Due to the setup done as part of creating a claimable class for Cloud SQL instances, the Secrets created from the SecretTemplate now appears as “claimable” to the Application Operator. From here on it is simply a case of creating a resource claim for the instance and then binding the claim to an Application Workload.

Create a claim for the newly created secret by running:

tanzu service resource-claim create cloudsql-postgres-claim \
  --resource-name sql-instance-claimable \
  --resource-namespace service-instances \
  --resource-kind Secret \
  --resource-api-version v1

Obtain the claim reference of the claim by running:

tanzu service resource-claim list -o wide

Expect to see the following output:

NAME                     READY  REASON  CLAIM REF
cloudsql-postgres-claim  True   Ready

Create an Application Workload that consumes the claimed Cloud SQL Postgresql Database by running:


tanzu apps workload create my-workload \
  --git-repo \
  --git-branch main \
  --git-tag tap-1.2 \
  --type web \
  --label \
  --annotation \
  --env SPRING_PROFILES_ACTIVE=postgres \

--service-ref is set to the claim reference obtained previously.

Congratulations - your Application Workload will now start up and will connect automatically to the Cloud SQL Service Instance. This can be verified by visiting the app in the browser and, for example, creating a new “Owner” through the GUI.

check-circle-line exclamation-circle-line close-line
Scroll to top icon