Advanced Use Cases

This page contains a number of use cases for Tanzu Application Platform powered by the Services Toolkit. It is highly recommended to have first completed the Getting Started Walkthrough in the Tanzu Application Platform Getting Started Guide as this covers the most common day-to-day use cases.

Direct Secret References

This use case leverages direct references to Kubernetes Secret resources to enable developers to connect their application workloads to almost any backing service, including backing services that:

  • are running external to Tanzu Application Platform
  • do not adhere to the ProvisionedService of the Service Binding Specification for Kubernetes.

The following example demonstrates a procedure to bind a new application on Tanzu Application Platform to an existing PostgreSQL database that exists in Azure.

  1. Create a Kubernetes Secret resource similar to the following example:

    # external-azure-db-binding-compatible.yaml
    apiVersion: v1
    kind: Secret
      name: external-azure-db-binding-compatible
    type: Opaque
      type: postgresql
      provider: azure
      port: "5432"
      database: "EXAMPLE-DB-NAME"
      username: "USER@EXAMPLE"
      password: "PASSWORD"

    Note: Kubernetes Secret resources must abide by the Well-known Secret Entries specifications. Note: If you are planning to bind this Secret to a Spring-based Application Workload and want to take advantage of the auto-wiring feature, this Secret must also contain the properties required by Spring Cloud Bindings.

  2. Apply the YAML file by running:

    kubectl apply -f external-azure-db-binding-compatible.yaml
  3. Create a claim for the newly created secret by running:

    tanzu service claim create external-azure-db-claim \
      --resource-name external-azure-db-binding-compatible \
      --resource-kind Secret \
      --resource-api-version v1
  4. 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
    external-azure-db-claim  True 
  5. Create an Application Workload by running:


    tanzu apps workload create <WORKLOAD-NAME> \
      --git-repo \
      --git-branch main \
      --git-tag tap-1.0 \
      --type web \
      --service-ref db=<REFERENCE>


    • <WORKLOAD-NAME> is the name of the Application Workload. For example, pet-clinic.
    • <REFERENCE> is the value of the CLAIM REF for the newly created claim in the output of the last step.

Dedicated Service Clusters (using experimental Projection and Replication APIs)

Note: This Use Case make use of experimental APIs and is not recommended for use in production environments.

This use case make use of the experimental API Projection and Resource Replication APIs in order to separate Application Workloads and Service Instances onto separate Kubernetes clusters. There are several reasons as to why you may want to do this.

  • Dedicated cluster requirements for Workload or Service clusters: service clusters, for instance, might need access to more powerful SSDs.
  • Different cluster life cycle management: upgrades to Service clusters can occur more cautiously.
  • Unique compliance requirements: data is stored on a Service cluster, which might have different compliance needs.
  • Separation of permissions and access: application teams can only access the clusters where their applications are running.

The benefits of implementing this use case include:

  • The experience for Application Developers and Application Operators working on their Tanzu Application Platform cluster is unaltered.
  • All complexity in the setup and management of backing infrastructure is abstracted away from application developers, which gives them more time to focus on developing their applications.

For information about network requirements and possible topology setups, see Topology.


Please note the following assumptions / pre-requisites for completing this use case walkthrough:

  1. You have access to a cluster with Tanzu Application Platform installed (henceforth referred to as the “Application Workload Cluster”)
  2. You have access to a second, separate cluster with the Services Toolkit package installed (henceforth referred to as the “Service Cluster”)
  3. You have downloaded and installed the tanzu CLI along with the corresponding plug-ins
  4. You have downloaded and installed the experimental kubectl-scp plug-in (see Install the kubectl-scp plug-in)
  5. You have setup the default namespace on the Application Workload Cluster to use installed packages (see Set up developer namespaces to use installed packages) and will use it as your “developer namespace”
  6. The Application Workload Cluster is able to pull source code from GitHub
  7. The Service Cluster is able to pull the images required by the RabbitMQ Cluster Kubernetes Operator
  8. The Service Cluster is able to create LoadBalancer services

Important: If you have previously installed the RabbitMQ Cluster Operator to the Application Workload Cluster (i.e. as part of running through the Getting Started Walkthrough), you must first uninstall it from that cluster. This is due to a known limitation with the experimental API Projection APIs. Further information regarding this limitation can be found in Limitations.

kapp delete -a rmq-operator -y


Follow these steps to bind an application to a service instance running on a different Kubernetes cluster:

Important: Some of the commands listed in the following steps have placeholder values WORKLOAD-CONTEXT and SERVICE-CONTEXT. Change these values before running the commands.

  1. As the Service Operator, run the following command to link the Workload Cluster and Service Cluster together by using the kubectl scp plug-in:

    kubectl scp link --workload-kubeconfig-context=<WORKLOAD-CONTEXT> --service-kubeconfig-context=<SERVICE-CONTEXT>
  2. Install the RabbitMQ Kubernetes Operator in the Services Cluster using kapp.

    Note: This Operator is installed in the Service Cluster, but RabbitmqCluster service instances can still have their lifecycles managed (CRUD) from the Workload Cluster.

    Note: Use the exact deploy.yml specified in the command as this RabbitMQ Operator deployment includes specific changes to enable cross-cluster service binding.

     kapp -y deploy --app rmq-operator \
        --file  \
        --kubeconfig-context <SERVICE-CONTEXT>
  3. Verify that the Operator is installed by running:

    kubectl --context <SERVICE-CONTEXT> get crds

    The following steps federate the API group, which is available in the Service Cluster, into the Workload Cluster. This occurs in two parts: projection and replication.

    • Projection applies to custom API groups.
    • Replication applies to core Kubernetes resources, such as Secrets.
  4. Create service-instance namespace in both clusters.

    API Projection ocurrs between clusters using namespaces with the same name and that are said to have a quality of “namespace sameness”.

    For example:

    kubectl --context <WORKLOAD-CONTEXT> create namespace service-instances
    kubectl --context <SERVICE-CONTEXT> create namespace service-instances
  5. Federate using the kubectl-scp plug-in by running:

     kubectl scp federate \
      --workload-kubeconfig-context=<WORKLOAD-CONTEXT> \
      --service-kubeconfig-context=<SERVICE-CONTEXT> \
      --namespace=service-instances \ \
      --api-version=v1beta1 \
  6. After federation, verify the API is also available in the Workload Cluster by running:

    kubectl --context <WORKLOAD-CONTEXT> api-resources
  7. Discover the new service and provision an instance from the Workload cluster by running:

    Note: Ensure the tanzu CLI is configured to target the Workload cluster.

    tanzu service types list

    The following output appears:

    Warning: This is an ALPHA command and may change without notice.
    NAME      DESCRIPTION               APIVERSION            KIND
    rabbitmq  It's a RabbitMQ cluster!  RabbitmqCluster
  8. Provision a service instance on the Tanzu Application Platform cluster.

    For example:

    # rabbitmq-cluster.yaml
    kind: RabbitmqCluster
      name: projected-rmq
        type: LoadBalancer
  9. Apply the YAML file by running:

    kubectl --context <WORKLOAD-CONTEXT> -n service-instances apply -f rabbitmq-cluster.yaml
  10. Confirm that the RabbitmqCluster resource reconciles successfully from the Workload Cluster by running:

    kubectl --context <WORKLOAD-CONTEXT> -n service-instances get -f rabbitmq-cluster.yaml
  11. Confirm that RabbitMQ Pods are running in the Service Cluster, but not in the Workload Cluster by running:

    kubectl --context <WORKLOAD-CONTEXT> -n service-instances get pods
    kubectl --context <SERVICE-CONTEXT> -n service-instances get pods
  12. Create a claim for the projected service instance by running:

    tanzu service claim create projected-rmq-claim \
      --resource-name projected-rmq \
      --resource-kind RabbitmqCluster \
      --resource-api-version \
      --resource-namespace service-instances
  13. Create the application workload by running:

    tanzu apps workload create multi-cluster-binding-sample \
      --git-repo \
      --git-branch main \
      --git-tag tap-1.0 \
      --type web \
      --service-ref ""
  14. Get the web-app URL by running:

    tanzu apps workload get multi-cluster-binding-sample
  15. Visit the URL and refresh the page to confirm the app is running by checking the new message IDs.

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