Create proposal for Cluster CR we expect from KEB

[tobiscr]

Description

The technical contract between the KEB and the KIM will be based on Cluster CR. As consumer of this resource, we have to come up with a proposal of the mandatory data which are required for this CR.

Consider also coming features and coming new requirements. We should be able to extend the model in a way that new features can be easily introduced into the structure without having a need to change already exiting fields.

Fields which are not dynamic and can be determined by the KIM should not be part of the CRD but instead land in the KIM configuration and be handled by KIM's logic.

Planned new features are:

• General flexibility for customers to adjust VMs, network etc. (see EPIC Enable consumption and configuration of specific hyperscaler resources [EPIC] kyma#18195)
• Configurable Auditlog for customers (# 3968)
• Adjust configuration of particular Gardener features (Configurable networking filter for ingress traffic (geo-blocking) [EPIC] #136)
• Custom OIDC configurations (Support additional OIDC configuration with shoot-oidc-service extension kyma#18305)
• Multiple worker groups [KIM/feature] #46
• Ensure shoot/seed region is equal (#4261)
• Limited cluster infrastructure control to Gardener based Kyma clusters for end users [EPIC] kyma#13153

AC:

• Review a generated Gardener Shoot-Spec and extract all mandatory values we have to receive from KEB
• Define an initial draft for a Cluster CRD
  • Present the draft in the team and gather their feedback
  • Show how this model could be extended in the future if new features (see list above) will later be introduced
  • KIM has to track the status of each cluster. This should be tracked in the conditions field of the CR (also lerror should be listed there) as also KLM is following this approach for Kyma CRs. - extracted to Valid CRs statuses should be set when KIM's operations succeed or fail #193
  • It could happen that Gardener shoot is not fully in-sync with latest updates from KEB because the last update failed (e.g. list of Administrators was invalid and got rejected). The contract has to include a field / status which is reflecting such cases. - separate issue KIM has to adjust the ClusterRoleBindings if the adminstrators change when clusters are created or updated #198
• Share the CRD with Gophers in a call and explain what the purpose of the different fields is (only if they are not already self-explaining)

Relates to
#127

[PK85]

example what KEB sends/gets from provisioner:

"gardenerConfig": {
					"name": "c-77ac5ef",
					"kubernetesVersion": "1.27",
					"targetSecret": "gcp-skr-dev-cust-00001-e2e-test",
					"provider": "gcp",
					"region": "europe-west3",
					"seed": "gcp-ha-eu1",
					"machineType": "n2-standard-4",
					"machineImage": null,
					"machineImageVersion": null,
					"diskType": "pd-standard",
					"volumeSizeGB": 50,
					"workerCidr": "10.250.0.0/22",
					"podsCidr": null,
					"servicesCidr": null,
					"autoScalerMin": 3,
					"autoScalerMax": 20,
					"maxSurge": 3,
					"maxUnavailable": 0,
					"purpose": null,
					"licenceType": null,
					"enableKubernetesVersionAutoUpdate": null,
					"enableMachineImageVersionAutoUpdate": null,
					"providerSpecificConfig": {
						"zones": [
							"europe-west3-a",
							"europe-west3-b",
							"europe-west3-c"
						]
					},
					"dnsConfig": null,
					"oidcConfig": {
						"clientID": "9bd05ed7-a930-44e6-8c79-e6defeb7dec9",
						"groupsClaim": "groups",
						"issuerURL": "https://kymatest.accounts400.ondemand.com/",
						"signingAlgs": [
							"RS256"
						],
						"usernameClaim": "sub",
						"usernamePrefix": "-"
					},
					"exposureClassName": null,
					"shootNetworkingFilterDisabled": null,
					"controlPlaneFailureTolerance": null,
					"euAccess": null
				}

[Disper]

Closing, as the ADR was merged.