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.

Service Operators must ensure that workloads running inside the Kubernetes clusters hosting the Space can access a given Pre-Provisioned Service over the network. The method to achieve this varies depending on the environments of the Kubernetes clusters and the specific Service. For example, if the Space is scheduled on an AWS EKS cluster and the apps in the Space need access to an AWS RDS database, see Tutorial: Connect an Amazon EC2 instance to an Amazon RDS database in AWS documentation.

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 instance running in Availability Target A uses the exact same information to connect to the service as an application instance 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.

Egress configuration

To enable workloads to connect to the external services specified through PreProvisionedService, you must configure egress in the Space. You can do this by creating EgressPoint resources for each service binding, but maintaining additional resources adds complexity.

For this reason, you can specify EgressPoint templates when configuring a PreProvisionedService. When that PreProvisionedService is bound to a workload, the system automatically creates EgressPoint resources in the Space, based on the template, and manages the life cycle of these resources.

The egressPointTemplate field is optional. You can add it either in the configuration for each Availability Target under the availabilityTargets section, or you can specify one template for all Availability Targets in the Space when there is no availabilityTargets section.

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
          egressPointTemplate:
            targets:
              - hosts: ["aurora-rw.us-east.amazonaws.com"]
                port:
                  number: 3306
                  protocol: TCP
        eu-west:
          secretRef:
            name: secret-aurora-rw-eu-west
          egressPointTemplate:
            targets:
              - hosts: ["aurora-rw.eu-west.amazonaws.com"]
                port:
                  number: 3306
                  protocol: TCP

    - 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
      egressPointTemplate:
        targets:
          - hosts: ["aurora-ro.us-west.amazonaws.com"]
            port:
              number: 3306
              protocol: TCP

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 instances 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