What are Services and Service Bindings

Tanzu Platform for Kubernetes uses Services and Service Bindings to bind your applications to different types of data services such as databases, messaging, or caching services.

Services can be pre-provisioned or dynamically provisioned.

Pre-Provisioned Services - Pre-Provisioned Services are typically used for production use cases. Using a Pre-Provision Service allows you to curate the Service off-platform and attach to your Space.
Dynamically Provisioned Services - Dynamically Provisioned Services are targeted for development environment use cases. Tanzu Platform for Kubernetes supports a range of development services backed by Bitnami Helm charts. These services include MySQL, PostgreSQL, RabbitMQ, and Redis.

Pre-Provisioned Services

PreProvisionedServices are primarily intended for use in production environments. They enable applications within a Space to access services that have been pre-provisioned outside of that Space. This includes resources managed off-platform, such as cloud-managed services. A PreProvisionedService specifies everything required for an application to access the corresponding service. Typically, this includes connectivity details and credentials.

Binding Connectors

A Binding Connector is a part of the PreProvisionedService API and allows it to have many different endpoints which serve different purposes. A PreProvisionedService has a list of bindingConnectors defined in its spec.

An application can be bound to any one of those connectors. When an application is bound to a connector, the Tanzu Platform for Kubernetes provides the application with the binding details specified for that connector. The application can then use that information to connect to the corresponding service. The binding details for a given connector are stored in a Kubernetes Secret and must be provided at the time the PreProvisionedService is defined inside a Space.

Specifying multiple Binding Connectors

While most PreProvisionedServices specify a single Binding Connector, there are use cases for PreProvisionedServices with multiple connectors. For example, a database that provides dedicated endpoints for read-write and read-only access. A PreProvisionedService representing the database might have two Binding Connectors, one named read-write and another named read-only. Each Binding Connector specifies a dedicated endpoint and set of user credentials.

Binding details and Availability Targets

Typically, the binding details specified by a connector are identical across all Availability Targets for a given Space. This means that an application replica running in Availability Target A uses the exact same information to connect to the service as an application replica running in Availability Target B. Services that support true global scale such as AWS Aurora or Google Cloud Spanner often provide region-specific endpoints to minimize latencies and network costs for applications connecting to the service from within a specific region. To support these cases, a Binding Connector for a PreProvisionedService can, optionally, specify different binding details for each of the Availability Targets of a given Space.

Example YAML of a `PreProvisionedService`:

apiVersion: services.tanzu.vmware.com/v1
kind: PreProvisionedService
metadata:
  name: prod-aurora
spec:

  description: Aurora Global Database spanning us-east and eu-west
  contact:
    email: [email protected]

  bindingConnectors:
    - name: read-write
      description: Read-write available in all availability targets
      type: mysql
      availabilityTargets:
        us-east:
          secretRef:
            name: secret-aurora-rw-us-east
        eu-west:
          secretRef:
            name: secret-aurora-rw-eu-west

    - name: read-only
      description: Read-only available in all availability targets
      type: mysql
      # For use-cases in which the secret is the same for all ATs, this shorthand notation can be used.
      secretRef:
        name: secret-aurora-ro

Bitnami services

Tanzu Platform for Kubernetes includes a suite of services that can be provisioned within a space. Each of these services is backed by a corresponding Helm chart from the Bitnami catalog which provisions compute and storage resources inside the Space.

Bitnami services are designed primarily for development use cases, where a Space user can quickly obtain a specific service instance for rapid application development and testing. As such, these services are optimized for self-service and quick turnaround times.

Example YAML of a `PostgreSQLInstance`:

apiVersion: bitnami.database.tanzu.vmware.com/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: dev-postgres
spec:
  storageGB: 1

Limitations

Provisioning Bitnami services in multi-replica Spaces results in multiple, independent copies of the service, one for each replica of the Space. This may lead to unexpected behavior, such as split-brain scenarios, where different replicas of an application may see different data.
Moving or rescheduling the Space can result in data loss for these services.
Bitnami services are intended to be relatively short-lived, as they may not be easily upgraded after being provisioned.

Service Bindings

A ServiceBinding connects a given Service to an “application”, e.g. a ContainerApp or directly to a Kubernetes Deployment. The end result is that the Secret which contains the connectivity details will be mounted as a volume in the corresponding Kubernetes Pods.

In the case of the service being a PreProvisionedService, the Binding Connector needs to also be specified in order to know which one to bind against.

An optional alias can be used to provide the directory name of the target volume mount that is going to contain the binding details. If not set, the directory name of the volume mount will be the .metadata.name of the ServiceBinding.

Example YAML of a `ServiceBinding`:

apiVersion: services.tanzu.vmware.com/v1
kind: ServiceBinding
metadata:
  name: prod-aurora-my-app
spec:
  targetRef:
    apiGroup: apps.tanzu.vmware.com
    kind: ContainerApp
    name: my-app
  serviceRef:
    apiGroup: services.tanzu.vmware.com
    kind: PreProvisionedService
    name: prod-aurora
    # This is only required when binding to PreProvisionedService
    connectorName: read-write
  alias: configdb