See the documentation about installing the latest release of Services Toolkit to get started.
The ClusterResource CR is a place to store metadata regarding a Service Resource Lifecycle API. The only required field is .spec.resourceRef, which defines the Kubernetes API Group and Kind that a ClusterResource CR describes.
apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ClusterResource
metadata:
name: rabbitmqcluster
labels:
# The following labels will be applied automatically by the ClusterResource controller
# to help with filtering and searching of ClusterResource resources
services.apps.tanzu.vmware.com/api-group: rabbitmq.com
services.apps.tanzu.vmware.com/api-kind: RabbitmqCluster
spec:
# A reference to the Kubernetes API Group and Kind that this ClusterResource is describing
resourceRef:
# The Kubernetes API Group the resource belongs to
group: rabbitmq.com
# The Kubernetes API Kind of the resource
kind: RabbitmqCluster
# Short description of the resource (optional; string)
shortDescription: "It's a RabbitMQ Cluster"
# Long description of the resource (optional; string)
longDescription: "RabbitMQ is an open source ..."
Note: Metadata stored in ClusterResource CRs is not specific to a particular version of the API. Version-specific API metadata is stored in GVKDescriptor CRs.
GVKDescriptor is not a concrete CRD itself, but rather a duck type of the following shape:
apiVersion: group/version
kind: Kind
spec:
# A reference to the Kubernetes API Group/Version/Kind
gvkRef:
# The Kubernetes API Group the resource belongs to
group: rabbitmq.com
# The Kubernetes API Version of the API
version: v1beta1
# The Kubernetes API Kind of the resource
kind: RabbitmqCluster
Any CR that contains .spec.gvkRef with the group, version, and kind fields can be considered a GVKDescriptor.
ClusterExampleUsage CR adheres to the GVKDescriptor duck type and is used to store a YAML document for a Service Resource Lifecycle API.
apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ClusterExampleUsage
metadata:
name: rabbitmqcluster-hello-world
labels:
# The following labels will be applied automatically by the ClusterExampleUsage controller
# to help with filtering and searching of ClusterExampleUsage resources
services.apps.tanzu.vmware.com/api-group: rabbitmq.com
services.apps.tanzu.vmware.com/api-kind: RabbitmqCluster
services.apps.tanzu.vmware.com/api-version: v1beta1
spec:
# Adherence to GVKDescriptor duck type
gvkRef:
group: rabbitmq.com
version: v1beta1
kind: RabbitmqCluster
# Description of the example
description: |
"Hello World" example for the RabbitmqCluster resource
# YAML document for the example
yaml: |
---
apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
name: hello-world
spec:
...
All Service Offering APIs are cluster-scoped. This means that, assuming relevant RBAC is configured, any user can get, list, and watch CRs from these APIs. This configuration helps to support discoverability, in that just as any user can run kubectl api-resources any user can also run kubectl get clusterresources. The former command outputs all API resources on the server, while the latter command outputs only the Service Resource Lifecycle APIs on the server (a subset).
Ability to discover Service Resource Lifecycle APIs does not mean a user has permission to use the APIs. Accessibility of a Service Resource Lifecycle API depends on whether the user has relevant RBAC permissions on the API that is discovered.
By default, the Services Toolkit carvel package allows the system:authenticated Group to get, list, and watch Service Offering resources by using the ClusterRole service-offering-api-discoverability.
