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
Secret with this label will have been created in the previous step when you provisioned the
SecretTemplate which references the Config Connector’s objects.
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
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
#! 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 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 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:
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.