Support the rollout of the provisioner in a restricted market

[tobiscr]

Description

As first steps in a restricted market environment, we will deploy the provisioner and verify it's correct behaviour. The "upgrade" to KIM happens later in a separate step.

The installation of the provisioner will happen in collaboration with SREs. Frogs will support the SRE team in any provisioner related deployment tasks.

Goal is to:

• Deploy the provisioner in the restricted market environment (e.g. CN Cluster)
• Deploy a DB and populate the Provisioner DB-schema
• Configure the provisioner to use the create DB and to interact properly with KEB
• Execute a test-run by deploying a cluster via KEB + provisioner within the restricted market
• Most important: Identify technical gaps and missing features which have be solved in Provisioner and KIM to support restricted markets

AC:

• [x] Provisioner is deployed in a restricted market cluster (using a new deployed DB)
• [x] Provisioner is tested and was able to create via Gardener a cluster within the restricted market
• [x] Verify if we have technical gaps / challenges Provisioner when running it in CN. Check if these gaps also exist in KIM and, if yes, create issues for KIM to solve them.

Reasons

Extend our Kyma offering to extended markets (e.g. CN or NS2).

Attachments

[tobiscr]

Efforts to support KIM (we don't focus on Provisioner for restricted market as KIM will be the replacement for Provisioner at end of August):

Permission adjustments for engineers Scope: Hyperscaler-IAM adjustments, CAM-profiles requests, clarify questions etc. Assumption: 0,5d of pure working effort without waiting time for approvals etc. Effort: 0,5d - 2d

Support new hyperscalers in KIM Scope: Hyperscaler supported by Gardener and KIM will be adjusted to support this Hyperscaler in Shoot-Specs Assumption: only Shoot-spec adjustments required (e.g. CIDR) Effort: 3 - 5d (for standard cases)

Deploy subscription-cleanup-job Scope: cleanup job supports Hyperscaler in restricted market and remove "orphan" resources after cluster deletion Assumption: hyperscaler offers supported API, cleanup considers only 5-10 calls, well documented API in English Effort: 3 - 5d