As part of Tanzu Application Platform, you can work with backing services such as RabbitMQ, PostgreSQL, and MySQL among others. Binding application workloads to service instances is the most common use of services.
When working with services on Tanzu Application Platform, you must be familiar with service instances, service bindings, and resource claims. This section provides a brief overview of each of these key concepts.
A service instance is a logical grouping of one or more Kubernetes resources that together expose a known capability through a well-defined interface. For example, a theoretical “MySQL” service instance might consist of a
MySQLDatabase and a
MySQLUser resource. When considering compatibility of service instances for Tanzu Application Platform, one of the resources of a service instance must adhere to the Service Binding for Kubernetes specification.
Service binding refers to a mechanism in which connectivity information, such as service instance credentials and connectivity information (host, port, and so on), are automatically communicated to application workloads. Tanzu Application Platform uses a standard named Service Binding for Kubernetes to implement this mechanism. See this standard to fully understand the services aspect of Tanzu Application Platform.
Resource claims are inspired in part by Persistent Volume Claims. For more information, see the Kubernetes documentation. Resource claims provide a mechanism for users to “claim” service instances on a cluster, while also decoupling the life cycle of application workloads and service instances.
The following list of Kubernetes operators expose APIs that integrate well with Tanzu Application Platform:
Compatibility of a service with Tanzu Application Platform ranges on a scale between fully compatible and incompatible. The minimum requirement for compatibility is that there must be a declarative, Kubernetes-based API on which at least one API resource type adheres to the Provisioned Service duck type defined by the Service Binding Specification for Kubernetes in GitHub. This duck type includes any resource type with the following schema:
status: binding: name: # string
The value of
.status.binding.name must point to a
Secret in the same namespace. The
Secret contains required credentials and connectivity information for the resource.
Typically, APIs that include these resource types are installed onto the Tanzu Application Platform cluster as Kubernetes operators. These Kubernetes operators provide custom resource definitions (CRDs) and corresponding controllers to reconcile the resources of the CRDs, as is the case with the three Kubernetes operators listed earlier.
For services that do not provide a resource adhering to the Service Binding Specification for Kubernetes, it may still be possible to provide configurations allowing such services to integrate with Tanzu Application Platform. See the following for examples of how to do this for Amazon AWS RDS.
It is important to understand the user roles for services on Tanzu Application Platform and the responsibilities assumed by each. The following table describes each user role.
|User role||Exists as a default role in Tanzu Application Platform?||Responsibilities|
|Service operator||No (might be introduced in a future release)||
|Application operator||Yes - app-operator||Life cycle management (CRUD) of resource claims|
|Application developer||Yes - app-editor and app-viewer||Binding service instances to application workloads|
Apply what you’ve learned: