About Services Toolkit

Services Toolkit (“STK”) is a collection of Kubernetes native components supporting the discoverability, lifecycle management (CRUD) and connectivity of Service Resources (databases, message queues, DNS records, etc.) on Kubernetes.

The toolkit is currently comprised of the following components:

  1. Resource Claims
  2. Service Offering
  3. Service API Projection (experimental)
  4. Resource Replication (experimental)
  5. Resource Classes (coming soon)

Each component has value independent of the others, however the most powerful and valuable use cases are unlocked by combining them together in unique and interesting ways.

High-level diagram of workflow that Services Toolkit facilitates. Asterisks on ClusterServiceOffering, ClusterResourceClass, ResourceClassAccessBinding, and ClusterResourceProvisionTemplate signal that no concrete designs for these items exist as yet. * indicates item is on the roadmap. No concrete design available yet. Early prototype and/or proposal might exist.

Motivation

Application teams need supporting Service Resources (e.g. databases, message queues, DNS records, etc.) to develop and run their applications. They do not want the burden of having to run these services themselves, so often organizations provide ticketing systems that allow Application teams to make manual 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 can be provisioned with simple API calls, for example RDS. Services Toolkit aims to provide a set of modular tools that can be used to provide a similar self-service experience to that of the cloud for Service Resources running on Tanzu.

Component Overview

Following is a brief overview of the components comprising Services Toolkit.

Resource Claims

Resource Claims allows 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, e.g. type, protocol, provider, version. The claim is then fulfilled against an existing (or in the future automatically created) Service Resource using rules decided by the Service Operator. This allows Application teams to focus on their application and its dependencies.

To learn more about Resource Claims, see Resource Claims.

Service Offering

In order 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 do already define some metadata, however, this only consists of Kubernetes level API descriptions, e.g. name, field descriptions. While this metadata is useful, Application Operators require more holistic information covering details such as service level management capabilities, QoS guarantees, relationships between different resource types the API exposes, as well as other information that aids discovery by Application Operators and higher-level tooling aimed at that role (e.g. keywords, icons, etc).

It is worth noting that some metadata surfaced by Service Description and Offering relate not only to the Service Resource Lifecycle API itself, but also 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. As an example, a Service Resource that is concerned with 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, we consider it the responsibility of the Service Operator to make sure that the right level of accurate metadata has been specified for a given Service Resource. Service Description and Offering enables associating metadata with Service Resources and surfacing it to Application Operators. This metadata can be provided by Service Operator or, for infrastructure agnostic metadata (e.g. data that describes the relationships between different API resource types), by Service Authors.

To learn more about Service Offering, see Service Offering.

Service API Projection & Resource Replication (experimental)

We also believe Application and Service infrastructure should be separated, and we have observed customers doing this in production environments. A few examples of the benefits of this segmentation of infrastructure are:

  • Dedicated cluster requirements for workload or service clusters. For example, Service clusters may need access to SSDs.
  • Different cluster lifecycle management. Upgrades to Service clusters may occur more cautiously.
  • Unique Compliance requirements. As data is stored on a Service cluster it may have different compliance needs.
  • Separation of permissions and access. Application teams can only access the clusters where their applications are running.

One way to address these needs in a Kubernetes multi-cluster world is to split clusters into Application Workload clusters and Service clusters, 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.

Resource Classes

Coming soon.

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