PoC - Migrate Service Catalog from api-server to CRD

[PK85]

Description

When the Service Catalog project was started, Kubernetes didn’t have the concept of Custom Resource Definitions (CRDs), which is a way to extend the Kubernetes API without having to write your own API server.

The Service Catalog, instead, implements an aggregated API server, which requires writing an API server from scratch and maintaining its code. Using CRDs would allow the Service Catalog to only own the Controller implementation and to benefit from the implementation improvements of the general API machinery and the CRDs tools.

As the service catalog roadmap towards 1.0.0 includes a point about using CRDs instead of api-server we'd like to implement that change and remove custom api-server and etcd.

Reasons

• We and other entities using Service Catalog facing issues with crashing often api-server, controller components also caused by etcd default configuration which doesn't fit a requested usage from controller. When etcd is down, api-server is down, all service catalog CRD and CR instances disappear. Then for example, we are able to delete a given namespace and when api-server is back we see have a state where for example service instances are assigned to not existing namespace (previously deleted)
• As the k8s community going towards CRDs only as a way to expose k8s APIs

Acceptance Criteria

• familiarise with tickets from SC: Implement Custom Resource Definitions storage backend kubernetes-retired/service-catalog#1088, TPRs and Custom Resource Definitions (CRDs) kubernetes-retired/service-catalog#987, Plan and document how to migrate clusters to some form of CRD kubernetes-retired/service-catalog#2059
• draw the plan and scope of the contribution
  • check all customisation and requirements in api-server and if CRD could fulfil them
• implement PoC and run regression tests
• document a CRD feature (refactoring)
• document what has changed before and after, for example:
  • etcd is gone, migrate your data by your own or just use new storage
  • maybe version of the APIs should will change
  • etc

Attachments

• the service catalog roadmap towards 1.0.0 - CRDs
• https://www.infoq.com/articles/service-catalog-kubernetes

[adamwalach]

Status update:

• draw the plan and scope of the contribution
  We still wait for a meeting with SC team to go into details. What we already know

  • their plan is to release v1.0 of SC in the current form (they will not wait for CRDs implementation)
  • demos that we did on SIG service catalog went pretty well. You can find it here: https://www.youtube.com/watch?v=asXvqNsmNZs&list=PL69nYSiGNLP2k9ZXx9E1MvRSotFDoHUWs
    our demo from 18.02 is not yet released.

• check all customisation and requirements in api-server and if CRD could fulfil them
  List of api-server features that need to be reimplemented in CRDs can be found here: Create list of all ServiceCatalog api-server custom features #2703 (comment)
  Based on this list we created issues under this epic. Looks like its possible to reimplement every one of them using CRDs and admission webhooks.

• implement PoC and run regression tests
  PoC can be found here: https://github.com/kyma-incubator/service-catalog/tree/crds-on-v0.1.40
  We prepared a testing scenario: https://github.com/kyma-incubator/service-catalog/tree/crds-on-v0.1.40/contrib/hack/crd#testing-scenario
  Tests are not yet finished, investigation can be tracked here: Investigate tests for ServiceCatalog #2731

• document a CRD feature (refactoring)
  TODO

• document what has changed before and after, for example:
  TODO

  • etcd is gone, migrate your data by your own or just use new storage
  • maybe version of the APIs should will change