SAP BTP service operator provides the ability to provision and consume SAP Cloud Platform from Kubernetes cluster in a Kubernetes-native way, based on the K8s Operator pattern.
This document describes the process to migrate a registered Kubernetes platform, based on the Service Catalog (svcat) and Service Manager agent, together with its content, to a SAP BTP service operator-based platform.
- Service Management Control (SMCTL) command line Interface. See Using the SMCTL.
- You must be a SAP BTP subaccount admin
-
Perform steps 1 and 2 of the Setup section of SAP BTP Service Operator for Kubernetes.
-
Deploy the SAP BTP service operator by executing the following command:
helm repo add sap-btp-operator https://sap.github.io/sap-btp-service-operator
helm upgrade --install <release-name> sap-btp-operator/sap-btp-operator \ --create-namespace \ --namespace=sap-btp-operator \ --set manager.secret.clientid=<clientid> \ --set manager.secret.clientsecret=<clientsecret> \ --set manager.secret.sm_url=<sm_url> \ --set manager.secret.tokenurl=<url> \ --set cluster.id=<clusterID>
Note:
-
<clusterID>
- specify the ID of the cluster. To find it, run:kubectl get configmap -n catalog cluster-info -o yaml
and extract id from the output.Output example:
apiVersion: v1 data: **id: ab7fa5e9-5cc3-468f-ab4d-143458785d07** kind: ConfigMap metadata: . .
-
-
Download and install the CLI needed to perform the migration in one of the two following ways:
-
Get the service operator migration CLI:
go get github.com/SAP/sap-btp-service-operator-migration
Install the CLI:
go install github.com/SAP/sap-btp-service-operator-migration
Rename the CLI binary:
mv $GOPATH/bin/sap-btp-service-operator-migration $GOPATH/bin/migrate
-
You can install the CLI by simply downloading the latest release.
Migration tool from SVCAT to SAP BTP Service Operator. Usage: migrate [flags] migrate [command] Available Commands: dry-run Run migration in dry run mode help Help about any command run Run migration process version Prints migrate version Flags: -c, --config string config file (default is $HOME/.migrate/config.json) -h, --help help for migrate -k, --kubeconfig string absolute path to the kubeconfig file (default $HOME/.kube/config) -n, --namespace string namespace to find operator secret (default sap-btp-operator)
-
-
Prepare your platform for migration by executing the following command:
smctl curl -X PUT -d '{"sourcePlatformID": ":platformID"}' /v1/migrate/service_operator/:instanceID
Where the parameter values are as following:
platformID is the ID that was generated when you registered a subaccount-scoped cluster in the step 1 of Cluster Configuration.
instanceID is the ID of theservice-operator-access
instance created in the step 1 of the Setup. -
At this point, you have two options at your disposal:
- Execute the actual migration by running the following command:
migrate run
. - Perform a dry run before you execute the migration by running:
migrate dry-run
.
Dry run is useful if you wish to execute the scan and validation steps described in the migration script example below without performing the actual migration.
At the end of the run, summary including all encountered errors is shown.
This way, you can decide whether to continue with the migration or first fix the issues.Once the actual migration process has been initiated, the platform is suspended, and you cannot create, update, or delete its service instances and service bindings.
The process is reversible for as long as the actual migration of the resources does not start (described below in the part 3 of the migration script example).To cancel the migration, execute the following command:
smctl curl -X DELETE -d '{"sourcePlatformID": ":platformID"}' /v1/migrate/service_operator/:instanceID
- Execute the actual migration by running the following command:
- The script first scans all service instances and service bindings that are managed in your cluster by SVCAT, and verifies whether they are also maintained in SAP BTP.
Migration won't be performed on those instances and bindings that aren't found in SAP BTP:
migrate run
Fetched 2 instances from SM
*** Fetched 1 bindings from SM
*** Fetched 5 svcat instances from cluster
*** Fetched 2 svcat bindings from cluster
*** Preparing resources
svcat instance name 'some_instance_name_1' id 'XXX-6134-4c89-bff5-YYY' (some_instance_name_1) not found in SM, skipping it...
svcat instance name 'some_instance_name_2' id 'XXX-cae6-4e23-9e8a-YYY' (some_instance_name_2) not found in SM, skipping it...
svcat instance name 'some_instance_name_3' id 'XXX-dc1d-49d1-86c0-YYY' (some_instance_name_3) not found in SM, skipping it...
svcat binding name 'some_binding_name_1' id 'XXX-5226-42cc-81e5-YYY' (some_binding_name_1) not found in SM, skipping it...
*** found 2 instances and 1 bindings to migrate
- Before the actual migration starts, the script also validates whether all the resources are migratable.
Note that if there is an issue with one or more resources, the process stops.
svcat instance 'some_instance_name_4' in namespace 'namespace_name' was validated successfully
svcat instance 'some_instance_name_5' in namespace 'namespace_name' was validated successfully
svcat binding 'some_binding_name_2' in namespace 'namespace_name' was validated successfully
*** Validation completed successfully
- After all of the sources were validated successfully, the actual migration starts.
Each service instance and binding is removed from the Service Catalog (SVCAT) and added to the SAP BTP service operator:
migrating service instance 'some_instance_name_4' in namespace 'namespace_name' (smID: 'XXX-3d1f-40db-8cac-YYY')
deleting svcat resource type 'serviceinstances' named 'some_instance_name_4' in namespace 'namespace_name'
migrating service instance 'some_instance_name_5' in namespace 'namespace_name' (smID: 'XXX-0f94-4fde-b524-YYY')
deleting svcat resource type 'serviceinstances' named 'some_instance_name_5' in namespace 'namespace_name'
migrating service binding 'some_binding_name_2' in namespace 'namespace_name' (smID: 'XXX-fc36-4d50-a925-YYY')
deleting svcat resource type 'servicebindings' named 'some_binding_name_2' in namespace 'namespace_name'
*** Migration completed successfully
Once the migration process has been completed, the SVCAT-based platform is no longer usable.
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.
This project is licensed under Apache 2.0 except as noted otherwise in the license file.