With the SAP BTP service operator, you can consume SAP BTP services from your Kubernetes cluster using Kubernetes-native tools.
SAP BTP service operator allows you to provision and manage service instances and service bindings of SAP BTP services so that your Kubernetes-native applications can access and use needed services from the cluster.
The SAP BTP service operator is based on the Kubernetes Operator pattern.
This feature is still under development, review, and testing.
- Prerequisites
- Setup Operator
- SAP BTP kubectl extension
- Using the SAP BTP Service Operator
- Reference Documentation
- SAP BTP Global Account and Subaccount
- Service Management Control (SMCTL) command line interface. See Using the SMCTL.
- Kubernetes cluster running version 1.17 or higher
- kubectl v1.17 or higher
- helm v3.0 or higher
-
Install cert-manager
- for releases v0.1.18 or higher use cert manager v1.6.0 or higher
- for releases v0.1.17 or lower use cert manager lower then v1.6.0
-
Obtain the access credentials for the SAP BTP service operator:
a. Using the SAP BTP cockpit or CLI, create an instance of the SAP Service Manager service (technical name:
service-manager
) with the plan:service-operator-access
Note
If you can't see the needed plan, you need to entitle your subaccount to use SAP Service Manager service.For more information about how to entitle a service to a subaccount, see:
For more information about creating service instances, see:b. Create a binding to the created service instance.
For more information about creating service bindings, see:
c. Retrieve the generated access credentials from the created binding:
The example of the default binding object used if no credentials type is specified:
{ "clientid": "xxxxxxx", "clientsecret": "xxxxxxx", "url": "https://mysubaccount.authentication.eu10.hana.ondemand.com", "xsappname": "b15166|service-manager!b1234", "sm_url": "https://service-manager.cfapps.eu10.hana.ondemand.com" }
The example of the binding object with the specified X.509 credentials type:
{ "clientid": "xxxxxxx", "certificate": "-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----..-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----\n", "key": "-----BEGIN RSA PRIVATE KEY-----...-----END RSA PRIVATE KEY-----\n", "certurl": "https://mysubaccount.authentication.cert.eu10.hana.ondemand.com", "xsappname": "b15166|service-manager!b1234", "sm_url": "https://service-manager.cfapps.eu10.hana.ondemand.com" }
-
Add SAP BTP service operator chart repository
helm repo add sap-btp-operator https://sap.github.io/sap-btp-service-operator
-
Deploy the the SAP BTP service operator in the cluster using the obtained access credentials:
Note:
If you are deploying the SAP BTP service operator in the registered cluster based on the Service Catalog (svcat) and Service Manager agent so that you can migrate svcat-based content to service operator-based content, add--set cluster.id=<clusterID>
to your deployment script.
For more information, see the step 2 of the Setup section of Migration to SAP BTP service operator.The example of the deployment that uses the default access credentials type:
helm upgrade --install <release-name> sap-btp-operator/sap-btp-operator \ --create-namespace \ --namespace=sap-btp-operator \ --version=<release> \ --set manager.secret.clientid=<clientid> \ --set manager.secret.clientsecret=<clientsecret> \ --set manager.secret.url=<sm_url> \ --set manager.secret.tokenurl=<url>
The example of the deployment that uses the X.509 access credentials type:
helm upgrade --install <release-name> sap-btp-operator/sap-btp-operator \ --create-namespace \ --namespace=sap-btp-operator \ --version=<release> \ --set manager.secret.clientid=<clientid> \ --set manager.secret.tls.crt="$(cat /path/to/cert)" \ --set manager.secret.tls.key="$(cat /path/to/key)" \ --set manager.secret.url=<sm_url> \ --set manager.secret.tokenurl=<certurl>
The list of available releases: sapbtp-operator releases
- To create an instance of a service offered by SAP BTP, first create a
ServiceInstance
custom-resource file:
apiVersion: services.cloud.sap.com/v1alpha1
kind: ServiceInstance
metadata:
name: my-service-instance
spec:
serviceOfferingName: sample-service
servicePlanName: sample-plan
externalName: my-service-instance-external
parameters:
key1: val1
key2: val2
-
<offering>
- The name of the SAP BTP service that you want to create. To learn more about viewing and managing the available services for your subaccount in the SAP BTP cockpit, see Service Marketplace.Tip: Use the Environment filter to get all offerings that are relevant for Kubernetes.
-
<plan>
- The plan of the selected service offering that you want to create.
-
Apply the custom-resource file in your cluster to create the instance.
kubectl apply -f path/to/my-service-instance.yaml
-
Check that the status of the service in your cluster is Created.
kubectl get serviceinstances NAME OFFERING PLAN STATUS AGE my-service-instance <offering> <plan> Created 44s
-
To get access credentials to your service instance and make it available in the cluster so that your applications can use it, create a
ServiceBinding
custom resource, and set theserviceInstanceName
field to the name of theServiceInstance
resource you created.The credentials are stored in a secret created in your cluster.
apiVersion: services.cloud.sap.com/v1alpha1
kind: ServiceBinding
metadata:
name: my-binding
spec:
serviceInstanceName: my-service-instance
externalName: my-binding-external
secretName: mySecret
parameters:
key1: val1
key2: val2
-
Apply the custom resource file in your cluster to create the binding.
kubectl apply -f path/to/my-binding.yaml
-
Check that your binding status is Created.
kubectl get servicebindings NAME INSTANCE STATUS AGE my-binding my-service-instance Created 16s
-
Check that a secret with the same name as the name of your binding is created. The secret contains the service credentials that apps in your cluster can use to access the service.
kubectl get secrets NAME TYPE DATA AGE my-binding Opaque 5 32s
See Using Secrets to learn about different options on how to use the credentials from your application running in the Kubernetes cluster,
Parameter | Type | Description |
---|---|---|
serviceOfferingName* |
string |
The name of the SAP BTP service offering. |
servicePlanName* |
string |
The plan to use for the service instance. |
servicePlanID | string |
The plan ID in case service offering and plan name are ambiguous. |
externalName | string |
The name for the service instance in SAP BTP, defaults to the instance metadata.name if not specified. |
parameters | []object |
Some services support the provisioning of additional configuration parameters during the instance creation. For the list of supported parameters, check the documentation of the particular service offering. |
parametersFrom | []object |
List of sources to populate parameters. |
customTags | []string |
List of custom tags describing the ServiceInstance, will be copied to ServiceBinding secret in the key called tags . |
userInfo | object |
Contains information about the user that last modified this service instance. |
Parameter | Type | Description |
---|---|---|
instanceID | string |
The service instance ID in SAP Service Manager service. |
operationURL | string |
The URL of the current operation performed on the service instance. |
operationType | string |
The type of the current operation. Possible values are CREATE, UPDATE, or DELETE. |
conditions | []condition |
An array of conditions describing the status of the service instance. The possible condition types are: - Ready : set to true if the instance is ready and usable- Failed : set to true when an operation on the service instance fails.In the case of failure, the details about the error are available in the condition message. - Succeeded : set to true when an operation on the service instance succeeded. In case of false operation considered as in progress unless Failed condition exists. |
tags | []string |
Tags describing the ServiceInstance as provided in service catalog, will be copied to ServiceBinding secret in the key called tags . |
Parameter | Type | Description |
---|---|---|
serviceInstanceName* |
string |
The Kubernetes name of the service instance to bind, should be in the namespace of the binding. |
externalName | string |
The name for the service binding in SAP BTP, defaults to the binding metadata.name if not specified. |
secretName | string |
The name of the secret where the credentials are stored, defaults to the binding metadata.name if not specified. |
secretKey | string |
The key inside the binding secret to store the credentials returned by the broker encoded as json to support complex data structures. |
secretRootKey | string |
The key inside the secret to store all binding data including credentials returned by the broker and additional info under single key. Convenient way to store whole binding data in single file when using volumeMounts . |
parameters | []object |
Some services support the provisioning of additional configuration parameters during the bind request. For the list of supported parameters, check the documentation of the particular service offering. |
parametersFrom | []object |
List of sources to populate parameters. |
userInfo | object |
Contains information about the user that last modified this service binding. |
Parameter | Type | Description |
---|---|---|
instanceID | string |
The ID of the bound instance in the SAP Service Manager service. |
bindingID | string |
The service binding ID in SAP Service Manager service. |
operationURL | string |
The URL of the current operation performed on the service binding. |
operationType | string |
The type of the current operation. Possible values are CREATE, UPDATE, or DELETE. |
conditions | []condition |
An array of conditions describing the status of the service instance. The possible conditions types are: - Ready : set to true if the binding is ready and usable- Failed : set to true when an operation on the service binding fails.In the case of failure, the details about the error are available in the condition message. - Succeeded : set to true when an operation on the service binding succeeded. In case of false operation considered as in progress unless Failed condition exists. |
To set input parameters, you may use the parameters
and parametersFrom
fields in the spec
field of the ServiceInstance
or ServiceBinding
resource:
parameters
: can be used to specify a set of properties to be sent to the broker. The data specified will be passed "as-is" to the broker without any modifications - aside from converting it to JSON for transmission to the broker in the case of thespec
field being specified asYAML
. Any validYAML
orJSON
constructs are supported. Only one parameters field may be specified perspec
.parametersFrom
: can be used to specify which secret, and key in that secret, which contains astring
that represents the json to include in the set of parameters to be sent to the broker. TheparametersFrom
field is a list which supports multiple sources referenced perspec
.
You may use either, or both, of these fields as needed.
If multiple sources in parameters
and parametersFrom
blocks are specified,
the final payload is a result of merging all of them at the top level.
If there are any duplicate properties defined at the top level, the specification
is considered to be invalid, the further processing of the ServiceInstance
/ServiceBinding
resource stops and its status
is marked with error condition.
The format of the spec
will be (in YAML format):
spec:
...
parameters:
name: value
parametersFrom:
- secretKeyRef:
name: my-secret
key: secret-parameter
or, in JSON format
"spec": {
"parameters": {
"name": "value"
},
"parametersFrom": {
"secretKeyRef": {
"name": "my-secret",
"key": "secret-parameter"
}
}
}
and the secret would need to have a key named secret-parameter:
apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: Opaque
stringData:
secret-parameter:
'{
"password": "letmein"
}'
The final JSON payload to be sent to the broker would then look like:
{
"name": "value",
"password": "letmein"
}
Multiple parameters could be listed in the secret - simply separate key/value pairs with a comma as in this example:
secret-parameter:
'{
"password": "letmein",
"key2": "value2",
"key3": "value3"
}'
You're welcome to raise issues related to feature requests, bugs, or give us general feedback on this project's GitHub Issues page. The SAP BTP service operator project maintainers will respond to the best of their abilities.
We currently do not accept community contributions.
The SAP BTP kubectl plugin extends kubectl with commands for getting the available services in your SAP BTP account by using the access credentials stored in the cluster.
- The SAP BTP kubectl plugin is currently based on
bash
. If you're using Windows, you should utilize the SAP BTP plugin commands from a linux shell (e.g. Cygwin).
- Download https://github.com/SAP/sap-btp-service-operator/releases/download/v0.1.6/kubectl-sapbtp
- Move the executable file to any location in your
PATH
kubectl sapbtp marketplace -n <namespace>
kubectl sapbtp plans -n <namespace>
kubectl sapbtp services -n <namespace>
Use the namespace
parameter to specify the location of the secret containing the SAP BTP access credentials.
Usually it is the namespace in which you installed the operator.
If not specified, the default
namespace is used.
This project is licensed under Apache 2.0 except as noted otherwise in the license file.