This topic provides descriptions of the terms and user roles used in the Services Toolkit documentation.
The following terms are used in the Services Toolkit documentation.
Service is broad, high-level term that describes something used in either the development of, or running of application workloads. Often, but not exclusively, synonymous with the concept of a backing service as defined by the Twelve Factor App:
“… any service the app consumes over the network as part of its normal operation”
For example:
A service resource is a Kubernetes resource that provides some of the functions related to a Service.
For example:
PostgreSQL
FirewallRule
RabbitmqUser
ClientRegistration
that provides access to an App SSO serviceSecret
containing credentials and connectivity information for a Service that may or may not be running on the cluster itself.A provisioned service is any service resource that defines a .status.binding.name
which points to a secret in the same namespace that contains credentials and connectivity information for the resource.
This term is defined in the Service Binding Specification for Kubernetes. For the full definition, see the Service Binding Specification in GitHub.
A service binding is a mechanism in which service instance credentials and other related connectivity information are automatically communicated to application workloads.
For example:
ServiceBinding
service resource provided by servicebinding in GitHub.A service instance is an abstraction over one or a group of interrelated service resources that together provide the functions for a particular service.
One of the service resources that make up an instance must either adhere to the definition of provisioned service, or be a secret conforming to the service binding specification for Kubernetes. This guarantees that you can claim a service and subsequently bind service instances to application workloads.
You make service instances discoverable through service instance classes.
For example:
The RabbitmqCluster
service resource provided by the RabbitMQ Cluster Kubernetes operator. This service resource adheres to provisioned service. Therefore, you can consider any RabbitmqCluster
resource on a Kubernetes cluster to be a service instance.
A logical grouping of the following service resources form a single AWS RDS service instance:
DBInstance
DBSubnetGroup
SecretTemplate
configured to produce a secret conforming to the Service Binding Specification for KubernetesRole
, RoleBinding
, and ServiceAccount
A Kubernetes Secret
conforming to the Service Binding Specification for Kubernetes containing credentials for a Service running external to the cluster.
A service instance class is more commonly called a class. Service instance classes provide a way to describe categories of service instances.
A service instance class enables service instances belonging to the class to be discovered. They come in one of two varieties: pool-based or provisioner-based.
Different classes might map to different services or to different configurations of the same service.
For example:
A ClusterInstanceClass
named “rabbitmq-dev” pointing to all RabbitmqCluster
service resources configured with .spec.replicas=1
identified by label class: rmq-dev
.
A ClusterInstanceClass
named “rabbitmq-prod” pointing to all RabbitmqCluster
service resources configured with .spec.replicas=3
identified by label class: rmq-prod
.
A ClusterInstanceClass
named “aws-rds-postgresql” pointing to secrets that conform with the Binding Specification and identified by label class: aws-rds
.
A ClusterInstanceClass
named “mysql-on-demand” which provisions MySQL service instances.
A claim is a mechanism in which requests for service instances can be declared and fulfilled without requiring detailed knowledge of the service instances themselves.
Claims come in one of two varieties - resource claim and class claim:
For example:
A resource claim pointing to a RabbitmqCluster
service instance named rmq-1
in the namespace service-instances
.
A class claim pointing to a class named on-demand-rabbitmq
.
A claimable service instance is any service instance that you are permitted to claim using a resource claim from a namespace, taking into consideration:
For example:
A RabbitmqCluster
service resource located in the same namespace as a resource claim and that has not already been claimed by another resource claim is a claimable service instance.
A RabbitmqCluster
service resource located in a different namespace to a resource claim, for which a matching resource claim policy exists, and has not already been claimed by another resource claim is a claimable service instance.
A RabbitmqCluster
service resource located in the same namespace as a resource claim that has already been claimed is not a claimable service instance due to the exclusive nature of Resource Claims.
Dynamic provisioning is a capability of Services Toolkit in which class claims that refer to provisioner-based classes are fulfilled automatically through the provisioning of new service instances.
A service resource life cycle API is any Kubernetes API that you can use to manage the life cycle—create, read, update and delete (CRUD)—of a service resource.
For example:
rabbitmqclusters.rabbitmq.com/v1beta1
A service cluster is applicable within the context of Service API Projection and Service Resource Replication. It is a Kubernetes cluster that has Service Resource Lifecycle APIs installed and a corresponding controller managing their life cycle.
A workload cluster is applicable within the context of Service API Projection and Service Resource Replication. It is a Kubernetes cluster that has developer-created applications running on it.
Services Toolkit caters to the following user roles.
These user roles are not user personas. It is possible, and even expected, that one person can be associated with many user roles at any given time. The user roles align to Tanzu Application Platform’s user roles. Services Toolkit is primarily responsible for defining the service operator role. For more information about the user roles, see Role descriptions.
The user roles listed in this section consist of a short description and the tasks required. For detailed information about the corresponding Role-Based Access Control (RBAC) associated with each role, see Detailed role permissions breakdown.
The application developer role encompasses both app-editor and app-viewer roles as defined by Tanzu Application Platform. For more information about the app-editor and app-viewer roles, see Role descriptions.
Application developers do the following:
Encompasses the app-operator role as defined by Tanzu Application Platform. For more information about the app-operator role, see Role descriptions.
Application operators do the following:
Service operators do the following: