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:
Note Please ensure you have met all prerequisites before reading on.
Note This usecase is not currently compatible with TAP air-gapped installations.
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 sql.cnrm.cloud.google.com
NAME SHORTNAMES APIVERSION NAMESPACED KIND
sqldatabases gcpsqldatabase,gcpsqldatabases sql.cnrm.cloud.google.com/v1beta1 true SQLDatabase
sqlinstances gcpsqlinstance,gcpsqlinstances sql.cnrm.cloud.google.com/v1beta1 true SQLInstance
sqlsslcerts gcpsqlsslcert,gcpsqlsslcerts sql.cnrm.cloud.google.com/v1beta1 true SQLSSLCert
sqlusers gcpsqluser,gcpsqlusers sql.cnrm.cloud.google.com/v1beta1 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.
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::
apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ClusterInstanceClass
metadata:
name: cloudsql-postgres
spec:
description:
short: Google Cloud SQL with a postgresql engine
pool:
kind: Secret
labelSelector:
matchLabels:
services.apps.tanzu.vmware.com/class: cloudsql-postgres
In this particular example, the class states that claimable instances of Cloud SQL Postgresql are represented by Secret objects with label services.apps.tanzu.vmware.com/class set to cloudsql-postgres. A Secret with this label was created earlier when you created the CloudSQL service instance.
Although this example uses services.apps.tanzu.vmware.com/class, 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:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: stk-secret-reader
labels:
servicebinding.io/controller: "true"
rules:
- 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
apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ResourceClaimPolicy
metadata:
name: default-can-claim-cloudsql-postgres
namespace: service-instances
spec:
subject:
kind: Secret
group: ""
selector:
matchLabels:
services.apps.tanzu.vmware.com/class: cloudsql-postgres
consumingNamespaces: [ "default" ]
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 services.apps.tanzu.vmware.com/v1alpha1:ResourceClaim:cloudsql-postgres-claim
Create an Application Workload that consumes the claimed Cloud SQL Postgresql Database by running:
Example:
tanzu apps workload create my-workload \
--git-repo https://github.com/sample-accelerators/spring-petclinic \
--git-branch main \
--git-tag tap-1.2 \
--type web \
--label app.kubernetes.io/part-of=spring-petclinic \
--annotation autoscaling.knative.dev/minScale=1 \
--env SPRING_PROFILES_ACTIVE=postgres \
--service-ref db=services.apps.tanzu.vmware.com/v1alpha1:ResourceClaim:cloudsql-postgres-claim
--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.
