The Service Catalog groups reusable, integrated services from all Service Brokers registered in Kyma. Its purpose is to provide an easy way for Kyma users to access services that the Service Brokers manage and use them in their applications.

Due to the fact that Kyma runs on Kubernetes, you can easily instantiate a service that a third party provides and maintains, such as a database. You can consume it from Kyma without extensive knowledge about the clustering of such a datastore service and the responsibility for its upgrades and maintenance. You can also easily provision an instance of the software offering that a Service Broker registered in Kyma exposes, and bind it to an application running in the Kyma cluster.

You can perform the following operations in the Service Catalog:

• Expose the consumable services by listing them with all the details, including the documentation and the consumption plans.
• Consume the services by provisioning them in a given Namespace.
• Bind the services to the applications through Secrets.

NOTE: Kyma uses the Service Catalog based on the one provided by Kubernetes. Kyma also supports the experimental version of the Service Catalog without api-server and etcd. Read this document for more information.

The diagram and steps describe the Service Catalog workflow and the roles of specific cluster and Namespace-wide resources in this process:

1. The Kyma installation results in the registration of the default Service Brokers in the Kyma cluster. The Kyma administrator can manually register other ClusterServiceBrokers in the Kyma cluster. The Kyma user can also register a Service Broker in a given Namespace.

2. Inside the cluster, each ClusterServiceBroker exposes services that are ClusterServiceClasses in their different variations called ClusterServicePlans. Similarly, the ServiceBroker registered in a given Namespace exposes ServiceClasses and ServicePlans only in this specific Namespace.

3. In the Console UI or CLI, the Kyma user lists all exposed cluster-wide and Namespace-specific services and requests to create instances of those services in the Namespace.

4. The Kyma user creates bindings to the ServiceInstances to allow the given applications to access the provisioned services.

Provisioning a service means creating an instance of a service. When you consume a specific ClusterServiceClass or a ServiceClass, and the system provisions a ServiceInstance, you need credentials for this service. To obtain credentials, create a ServiceBinding resource using the Service Catalog API. One instance can have numerous bindings to use in the application. When you raise a binding request, the system returns the credentials in the form of a Secret. The system creates a Secret in a given Namespace.

NOTE: The security in Kyma relies on the Kubernetes concept of a Namespace which is a security boundary. If the Secret exists in the Namespace, the administrator can inject it to any Deployment. The Service Broker cannot prevent other applications from consuming a created Secret. Therefore, to ensure a stronger level of isolation and security, use a dedicated Namespace and request separate bindings for each Deployment.

The Secret allows you to run the service successfully. However, a problem appears each time you need to change the definition of the yaml file in the Deployment to specify the Secrets' usage. The manual process of editing the file is tedious and time-consuming. Kyma handles it by offering a custom resource called ServiceBindingUsage. This custom resource applies the Kubernetes PodPreset resource and allows you to enforce an automated flow in which the Binding Usage Controller injects ServiceBindings into a given Deployment or Function.

Provisioning and binding flow

The diagram shows an overview of interactions between all resources related to Kyma provisioning and binding, and the reverting, deprovisioning, and unbinding operations.

The process of provisioning and binding invokes the creation of three custom resources:

• ServiceInstance
• ServiceBinding
• ServiceBindingUsage

The system allows you to create these custom resources in any order, but within a timeout period.

When you invoke the deprovisioning and unbinding actions, the system deletes all three custom resources. Similar to the creation process dependencies, the system allows you to delete ServiceInstance and ServiceBinding in any order, but within a timeout period. However, before you delete the ServiceBinding, make sure you remove the ServiceBindingUsage first. For more details, see the section on deleting a ServiceBinding.

Provision a service

To provision a service, create a ServiceInstance custom resource. Generally speaking, provisioning is a process in which the Service Broker creates a new instance of a service. The form and scope of this instance depends on the Service Broker.

Create a ServiceBinding

Kyma binding operation consists of two phases:

1. The system gathers the information necessary to connect to the ServiceInstance and authenticate it. The Service Catalog handles this phase directly, without the use of any additional Kyma custom resources.
2. The system must make the information it collected available to the application. Since the Service Catalog does not provide this functionality, you must create a ServiceBindingUsage custom resource.

TIP: You can create the ServiceBinding and ServiceBindingUsage resources at the same time.

Define other types of resources

The UsageKind is a cluster-wide custom resource which allows you to bind a ServiceInstance to any kind of resource. By default, Kyma provides two UsageKinds which enable binding either to a Deployment or Function. You can add more UsageKinds if you want to bind your ServiceInstance to other types of resources. The UsageKind contains information on how the binding to these custom resources is conducted. The ServiceBindingUsage uses this information to inject Secrets to the application.

Delete a ServiceBinding

Kyma unbinding can be achieved in two ways:

• Delete the ServiceBindingUsage. The Service Binding Usage Controller deletes the Secret injection, but the Secret itself still exists in the Namespace.
• Delete the ServiceBinding. It deletes the Secret and triggers the deletion of all related ServiceBindingUsages.

Deprovision a service

To deprovision a given service, delete the ServiceInstance custom resource. As part of this operation, the Service Broker deletes any resource created during the provisioning. When the process completes, the service becomes unavailable.

NOTE: You can deprovision a service only if no corresponding ServiceBinding for a given ServiceInstance exists.

The Service Catalog requires its own instance of api-server and etcd, which increases the complexity of the cluster configuration and maintenance costs. In case of api-server downtime, all Service Catalog resources are unavailable. For this reason, Kyma developers contribute to the Service Catalog project to remove the dependency on these external components and replace them with a native Kubernetes solution - CustomResourceDefinitions (CRDs).

Enable CRDs

To enable the CRDs feature in the Service Catalog, override the global.serviceCatalogApiserver.enabled and global.serviceCatalogCrds.enabled parameters in the installation file:

• For the local installation, modify the installation-config-overrides ConfigMap in the installer-config-local.yaml file:
  Click to copy

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: installation-config-overrides
    namespace: kyma-installer
    labels:
      installer: overrides
      kyma-project.io/installation: ""
  data:
    global.isLocalEnv: "true"
    global.domainName: "kyma.local"
    global.adminPassword: ""
    nginx-ingress.controller.service.loadBalancerIP: ""
    global.serviceCatalogApiserver.enabled: "true"
    global.serviceCatalogCrds.enabled: "false"

• For the cluster installation, add the service-catalog-versions-overrides ConfigMap to the cluster before the installation starts. Run:
  Click to copy

  kubectl create configmap service-catalog-overrides-versions -n kyma-installer --from-literal=global.serviceCatalogApiserver.enabled=false --from-literal=global.serviceCatalogCrds.enabled=true \
  && kubectl label configmap service-catalog-overrides-versions -n kyma-installer installer=overrides

To configure the Catalog sub-chart, override the default values of its values.yaml file. This document describes parameters that you can configure.

TIP: To learn more about how to use overrides in Kyma, see the following documents:

• Helm overrides for Kyma installation
• Sub-charts overrides

Configurable parameters

This table lists the configurable parameters, their descriptions, and default values:

To configure the Catalog CRDs sub-chart, override the default values of its values.yaml file. This document describes parameters that you can configure.

TIP: To learn more about how to use overrides in Kyma, see the following documents:

• Helm overrides for Kyma installation
• Sub-charts overrides

Configurable parameters

This table lists the configurable parameters, their descriptions, and default values:

To configure the Etcd-stateful sub-chart, override the default values of its values.yaml file. This document describes parameters that you can configure.

TIP: To learn more about how to use overrides in Kyma, see the following documents:

• Helm overrides for Kyma installation
• Sub-charts overrides

Configurable parameters

This table lists the configurable parameters, their descriptions, and default values:

To configure the PodPreset sub-chart, override the default values of its values.yaml file. This document describes parameters that you can configure.

TIP: To learn more about how to use overrides in Kyma, see the following documents:

• Helm overrides for Kyma installation
• Sub-charts overrides

Configurable parameters

This table lists the configurable parameters, their descriptions, and default values:

The usagekinds.servicecatalog.kyma-project.io CustomResourceDefinition (CRD) is a detailed description of the kind of data and the format used to define which resources can be bound with the ServiceBinding and how to bind them. To get the up-to-date CRD and show the output in the yaml format, run this command:

kubectl get crd usagekinds.servicecatalog.kyma-project.io -o yaml

Sample custom resource

This is a sample resource that allows you to bind a given resource with the ServiceBinding. This example has a resource section specified as function. You can adjust this section to point to any other kind of resource.

apiVersion: servicecatalog.kyma-project.io/v1alpha1
kind: UsageKind
metadata:
   name: function
spec:
   displayName: Function
   resource:
     group: kubeless.io
     kind: function
     version: v1beta1
   labelsPath: spec.deployment.spec.template.metadata.labels

Custom resource parameters

This table lists all the possible parameters of a given resource together with their descriptions:

Related resources and components

These are the resources related to this CR:

These components use this CR:

Management of the Service Catalog is based on Kubernetes resources and the custom resources specifically defined for Kyma. Manage all of these resources through kubectl.

Details

This section describes the resource names to use in the kubectl command line, the command syntax, and examples of use.

Resource types

Service Catalog operations use the following resources:

Syntax

Follow the kubectl syntax, kubectl {command} {type} {name} {flags}, where:

• {command} is any command, such as describe.
• {type} is a resource type, such as clusterserviceclass.
• {name} is the name of a given resource type. Use {name} to make the command return the details of a given resource.
• {flags} specifies the scope of the information. For example, use flags to define the Namespace from which to get the information.

Examples

The following examples show how to create a ServiceInstance, how to get a list of ClusterServiceClasses and a list of ClusterServiceClasses with human-readable names, a list of ClusterServicePlans, and a list of all ServiceInstances.

• Create a ServiceInstance using the example of the Redis ServiceInstance for the 0.1.40 version of the Service Catalog:

cat <<EOF | kubectl create -f -
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
  name: my-instance
  namespace: stage
spec:
  clusterServiceClassExternalName: redis
  clusterServicePlanExternalName: micro
  parameters:
     "imagePullPolicy": "Always"
EOF

• Get the list of all ClusterServiceClasses:

kubectl get clusterserviceclasses

• Get the list of all ClusterServiceClasses and their human-readable names:

kubectl get clusterserviceclasses -o=custom-columns=NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName

• Get the list of all ClusterServicePlans and associated ClusterServiceClasses:

kubectl get clusterserviceplans -o=custom-columns=NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName,EXTERNAL\ SERVICE\ CLASS:.spec.clusterServiceClassRef

• Get the list of all ServiceInstances from all Namespaces:

kubectl get serviceinstances --all-namespaces

This document describes the mapping of OSBA service objects, plan objects, and conventions in the Kyma Console Catalog view.

Catalog page

These are the OSBA fields used in the main Catalog page:

*Fields with an asterisk are required OSBA attributes.

**metadata.labels is the custom object that is not defined in the OSBA metadata convention.

Catalog Details page

These are the OSBA fields used in the detailed Service Class view:

*Fields with an asterisk are required OSBA attributes.

Add to Namespace

These are the OSBA fields used in the Add to Namespace window:

*Fields with an asterisk are required OSBA attributes.

Plan schema

A plan object in the OSBA can have the schemas field. Schema is used to generate a form which enables provisioning of the Service Class.

See the sample schema:

{
          "$schema": "http://json-schema.org/draft-04/schema#",
          "properties": {
            "imagePullPolicy": {
              "default": "IfNotPresent",
              "enum": [
                "Always",
                "IfNotPresent",
                "Never"
              ],
              "title": "Image pull policy",
              "type": "string"
            },
            "redisPassword": {
              "default": "",
              "format": "password",
              "description": "Redis password. Defaults to a random 10-character alphanumeric string.",
              "title": "Password (Defaults to a random 10-character alphanumeric string)",
              "type": "string"
            }
          },
          "type": "object"
        }

This sample renders in the following way:

Follow these rules when you design schema objects:

• If the field has limited possible values, use the enum field. It renders as a dropdown menu, so it prevents the user from making mistakes.
• If the field is required for the Service Class, mark it as required. UI blocks provisioning if you do not fill in the required fields.
• Fill the default value for a field whenever possible, it makes the provisioning faster.
• If the field, such as the password field, must be starred, use the format key with the password value.

This document describes the mapping of OSBA service objects, plan objects, and conventions in the Kyma Console Instances view.

Service Instances page

These are the OSBA fields used in the main Instances page:

*Fields with an asterisk are required OSBA attributes.

Service Instance Details page

These are the OSBA fields used in the detailed Service Instance view:

*Fields with an asterisk are required OSBA attributes.

NOTE: This addon is in the preview mode and is not available in Kyma by default. To enable it, add a proper AddonsConfiguration as described here.

The Google Cloud Platform (GCP) Service Broker is an open-source, Open Service Broker-compatible API server that provisions managed services in the Google Cloud Platform public cloud. Kyma provides Namespace-scoped GCP Service Broker. In each Namespace, you can configure the GCP Service Broker against different subscriptions. Install the GCP Service Broker by provisioning the Google Cloud Platform Service Broker class provided by the Helm Broker.

Once you provision the Google Cloud Platform Service Broker class, the GCP Service Broker classes are available in the Service Catalog view in a given Namespace. The GCP Service Broker provides these Service Classes to use with the Service Catalog:

• Google BigQuery
• Google BigTable
• Google Cloud Storage
• Google CloudSQL for MySQL
• Google CloudSQL for PostgreSQL
• Google Cloud Dataflow
• Google Cloud Datastore
• Google Cloud Dialogflow
• Google Cloud Firestore
• Google Machine Learning APIs
• Google Cloud Memorystore for Redis API
• Google PubSub
• Google Spanner
• Stackdriver Debugger
• Stackdriver Monitoring
• Stackdriver Profiler
• Stackdriver Trace

See the details of each Service Class and its specification in the Service Catalog UI. For more information about the Service Brokers, see this document.

Enable GCP Service Broker

The GCP Service Broker is a preview implementation and should not be used in a production environment. To enable the GCP Service Broker, create the following AddonsConfiguration:

apiVersion: addons.kyma-project.io/v1alpha1
kind: AddonsConfiguration
metadata:
  name: gcp-broker
  namespace: working-namespace
spec:
  reprocessRequest: 0
  repositories:
    - url: https://github.com/kyma-project/addons/releases/download/0.7.0/index-gcp.yaml

NOTE: If you register this addons repository URL as cluster-wide, there will be a conflict with the next release, after the GCP Service Broker is enabled by default.

The Microsoft Azure Service Broker is an open-source, Open Service Broker-compatible API server that provisions managed services in the Microsoft Azure public cloud. Kyma provides Namespace-scoped Azure Service Broker. In each Namespace, you can configure the Azure Service Broker against different subscriptions. Install the Azure Service Broker by provisioning the Azure Service Broker class provided by the Helm Broker.

Once you provision the Azure Service Broker class, the Azure Service Broker classes are available in the Service Catalog view in a given Namespace. The Azure Service Broker provides these Service Classes to use with the Service Catalog:

• Azure SQL Database
• Azure Database for MySQL
• Azure Redis Cache
• Azure Application Insights
• Azure CosmosDB
• Azure Event Hubs
• Azure IoT Hub
• Azure Key Vault
• Azure SQL Database
• Azure SQL Database Failover Group
• Azure Service Bus
• Azure Storage
• Azure Text Analytics

See the details of each Service Class and its specification in the Service Catalog UI. For more information about the Service Brokers, see this document.

NOTE: Kyma uses the Microsoft Azure Service Broker open source project. To ensure the best performance and stability of the product, Kyma uses a version of the Azure Service Broker that precedes the newest version released by Microsoft.

The AWS Service Broker is an open-source, Open Service Broker-compatible API server that provisions managed services in the AWS public cloud. Kyma provides the Namespace-scoped AWS Service Broker. In each Namespace, you can configure the AWS Service Broker against different subscriptions. Install the AWS Service Broker by provisioning the AWS Service Broker class provided by the Helm Broker.

Once you provision the AWS Service Broker class, the AWS Service Broker classes are available in the Service Catalog view in a given Namespace. The AWS Service Broker provides these Service Classes to use with the Service Catalog:

• Amazon Athena
• Amazon EMR
• Amazon Kinesis
• Amazon RDS for MariaDB
• Amazon RDS for PostgreSQL
• Amazon Translate
• Amazon KMS
• Amazon Rekognition
• Amazon SNS
• Amazon DynamoDB
• Amazon Redshift
• Amazon SQS
• Amazon Polly
• Amazon RDS for MySQL
• Amazon S3
• Amazon Lex
• Amazon Route53
• Amazon ElasticCache
• Amazon ElasticSearch
• Amazon DocumentDB
• Amazon RDS for PostgreSQL
• Amazon RDS for Oracle
• Amazon RDS for Mssql
• Amazon Aurora PostgreSQL
• Amazon Aurora MySQL

Find the documentation for each Service Class here. You can also see the details and specification of each Service Class in the Service Catalog UI, after provisioning a given class.

For more information about the Service Brokers, see this document.

NOTE: Kyma uses the AWS Service Broker open-source project. To ensure the best performance and stability of the product, Kyma uses a version of the AWS Service Broker that precedes the newest version released by Amazon.