Services Toolkit is a collection of Kubernetes-native components supporting the discoverability, life-cycle management (CRUD), and connectivity of service resources (databases, message queues, DNS records, and so on) on Kubernetes.
The toolkit is currently comprised of the following components:
Each component has value independent of the others, however the most powerful and valuable use cases can be unlocked by combining them together in unique and interesting ways. For a use case with examples of what can be done with the toolkit, see Getting Started.
For an example of how to consume AWS services with Services Toolkit, see either Consuming AWS RDS on Tanzu Application Platform (TAP) with AWS Controllers for Kubernetes (ACK) or Consuming AWS RDS on Tanzu Application Platform (TAP) with Crossplane.
Application teams need supporting service resources (databases, message queues, DNS records, and so on) to develop and run their applications. They do not want the burden of running these services themselves, so many organizations provide ticketing systems that allow application teams to manually make requests for new service resources to be created and managed for them. This process often takes weeks.
In the cloud, application teams have self-service access to create new managed resources that you can provision with API calls, such as RDS. Services Toolkit aims to provide a set of modular tools that you can use to provide a similar self-service experience to that of the cloud for service resources running on Tanzu.
Here is a brief overview of the components comprising Services Toolkit.
Resource claims enable application teams to express which service resources their applications require without having to know the intricacies of the service resource fulfilling the request. This replaces the traditional ticketing system previously mentioned with a model of application teams claiming resources and service operators providing resources to be claimed. This provides a self-service experience for the developer, but gives the service operators ultimate control of the service resources.
This also means application teams can request a service resource without having to know the exact name or namespace of the pre-provisioned service resource. Instead they express requirements using more meaningful metadata. For example, type, protocol, provider, and version. The claim is then fulfilled against an existing service resource using rules chosen by the service operator. This enables application teams to focus on their application and its dependencies.
To learn more about claims, see Resource claims. § To learn more about whether to use ResourceClaims or ClassClaims, see When to use ClassClaim vs ResourceClaim.
To discover service resources and understand how to use them, application operators need access to a rich set of metadata that describes the semantics and management capabilities of the corresponding Service Resource Lifecycle APIs.
The fundamental building blocks of Service Resource Lifecycle APIs are aggregated APIs or CRDs, and these already define some metadata. However, this only consists of Kubernetes-level API descriptions, such as name and field.
Although this metadata is useful, application operators require more holistic information that covers details such as service-level management capabilities, QoS guarantees, and relationships between different resource types the API exposes. Application operators also require other information that aids discovery by application operators and higher-level tooling aimed at that role, such as keywords, icons, and so on.
Some metadata surfaced by service description and offering relate not only to the Service Resource Lifecycle API itself, but also to the specifics of the underlying infrastructure, such as the number and the topology of worker nodes in the Service Cluster, or the particular CSI and CNI implementations configured for the cluster.
For example, a service resource that is relevant to MySQL cannot claim high-availability for the provisioned databases if the service cluster in which the individual MySQL pods run consists of only a single worker node.
Because of this, the service operator is deemed responsible for ensuring that the correct level of accurate metadata is specified for a service resource. Service description and offering enables the association of metadata with service resources and surfacing it to application operators. The service operator can provide this metadata, and service authors can provide infrastructure-agnostic metadata, such as data that describes the relationships between different API resource types.
To learn more about service offering, see Service offering.
VMware recommends that customers separate application and service infrastructure, which is done in their production environments. Benefits of this segmentation of infrastructure include:
One way to address these needs in a Kubernetes multicluster world is to split clusters into application workload clusters and service clusters, and then allow application teams to consume service resource APIs from their application workload cluster, with reconciliation of resources occurring on services clusters.
To learn more about service API projection and resource replication, see Service API projection and service resource replication.
