Remove Service Catalog area from Kyma opensource

[PK85]

Description

With Kyma 2.2 release we plan to remove Service Catalog area from this project.

Reasons

• hyperscaler cloud providers discontinued work on their Service Brokers. They support operators which will allow to provision services.
• k8s Service Catalog is dead, no active development.
• service binding usage feature causes issues when prod-preset controller is down and end-application pod is restarting. Result: application has no environment variables injected.

AC

• [x] 1) remove all related charts and components. See what sc-migrator reconciler is cleaning up from Kyma cluster after migration, link: https://github.com/kyma-incubator/reconciler/pull/722
• [x] 2) double check documentation to not mention service catalog
• [x] 3) double check if all the test are adjusted and green
• [x] 4) Final release note about SC removal, that it's really gone now

[klaudiagrz]

Please remember to include the note about SC removal in the release notes 🙂

[wozniakjan]

TODO: check how much less resources (CPU and memory) Kyma will use after the service catalog removal.

@PK85, here are some statistics from an idle freshly provisioned cluster

$ k top pod service-catalog-catalog-controller-manager-7d96d47bbb-p9lxm
NAME                                                          CPU(cores)   MEMORY(bytes)
service-catalog-catalog-controller-manager-7d96d47bbb-p9lxm   3m           81Mi

$ k top pod service-catalog-catalog-webhook-5d7487cb95-zfvmk
NAME                                               CPU(cores)   MEMORY(bytes)
service-catalog-catalog-webhook-5d7487cb95-zfvmk   1m           11Mi

$ k top pod service-catalog-addons-service-binding-usage-controller-5cnw7ch
NAME                                                              CPU(cores)   MEMORY(bytes)
service-catalog-addons-service-binding-usage-controller-5cnw7ch   3m           87Mi

we also set some requests and limits on these

$ k get deployment service-catalog-addons-service-binding-usage-controller service-catalog-catalog-controller-manager service-catalog-catalog-webhook -o json | jq -c '.items[].spec.template.spec.containers[] | {"name":.name,"resources":.resources}'
{"name":"service-binding-usage-controller","resources":{"limits":{"cpu":"100m","memory":"96Mi"},"requests":{"cpu":"50m","memory":"48Mi"}}}
{"name":"controller-manager","resources":{"limits":{"cpu":"100m","memory":"128Mi"},"requests":{"cpu":"50m","memory":"48Mi"}}}
{"name":"svr","resources":{"limits":{"cpu":"100m","memory":"48Mi"},"requests":{"cpu":"50m","memory":"30Mi"}}}

[vlerenc]

Can you please give an estimate when you can mitigate this? Kyma clusters burn through 32+ cores, because API servers request up to 12 cores to process these requests. That's burning money on our/SAP side. That it is rooted in a Kubernetes issue (https://github.com/kubernetes/kubernetes/issues/109099) is not helping and we would ask you to please increase the priority and provide a fix.

[wozniakjan]

please increase the priority and provide a fix.

there is not going to be any fix, service catalog has been deprecated in kyma for a long time, this ticket is about forcefully removing it and for managed kyma instances there is a managed migration as well. Non-managed kymas will need to migrate on their own using https://github.com/SAP/sap-btp-service-operator-migration

Can you please give an estimate when you can mitigate this?

anyone is free to "mitigate" already, the team around Service Management platform has implemented a migration procedure and you can use https://github.com/SAP/sap-btp-service-operator-migration from them to migrate and then delete/disable service catalog at any point since October. For managed kymas the managed migration is already in progress, but exact dates depend on customers, BTP platform, their availability and individual contracts.

[vlerenc]

@wozniakjan I don't know what you are trying to say. Kyma clusters burn through 32+ cores, because API servers request up to 12 cores to process requests. What is your plan to change that - better yesterday than tomorrow?

Can you not help SAP and conceive a solution to get rid or sufficiently cut down the culprit? I believe, it's this one here from our investigation: data-privacy-integration-service-application (cc @dguendisch @ialidzhikov). It's a 178 kB service plan "toasting" the API server (see https://github.com/kubernetes/kubernetes/issues/109099 for more details what triggers the effect, CRD definition, nesting depth,... maybe you can help with/influence the service plan itself).

This creates high costs for SAP for no good reason and passively waiting for people to migrate away (or not), if that's what you said above, seems wrong.

[wozniakjan]

as far as I know, https://github.com/kubernetes/kubernetes/issues/109099 is not the only issue and by far not even the biggest that SAP has with service catalog. The migration is in progress for managed kymas, there is not going to be a service catalog in kyma anymore. This path was selected a little more than a year ago, currently being finally carried out.

Can you not help SAP and conceive a solution to get rid or sufficiently cut down the culprit?

I am an external contractor from kubermatic, on a temporary part-time contract at SAP, I have not been involved in setting the roadmap for kyma. On the other hand, judging from your title here at github as Tech Lead and Product Owner for Kubernetes/Gardener, Central Engineering, SAP SE, you should have a better and more direct path to the correct stakeholders at SAP internally.

[vlerenc]

you should have a better and more direct path to the correct stakeholders at SAP internally

@wozniakjan Nice one. :-)

Sometimes, I can only try to ask other departments/orgs. I am not responsible for all things Kubernetes at SAP, just working in/for Gardener, not Kyma or HANA or any other stakeholder.