Fail fast for Shoot/Seed in same region: before creating the Shoot-spec, KIM will evaluate whether a seed exists in the requested region

[tobiscr]

Description

This is an enhancement for the #241:

After an alignment with Gardener (see gardener/gardener#10983 (comment)), we agreed to determine by ourself whether a seed exists in the requested region.

This is possible by requesting all Seed resources on the Gardener API server and checking for their regions. I no Seed could be found in the Shoot's region, we stop the processing and let the cluster creation fail as we cannot fulfil the customer requirement of having Shoot and seed in same region.

Example:

# region information is provided in field "spec.provider.region" or in label "seed.gardener.cloud/region: eu-west-1":

$> kubectl --kubeconfig gardener-dev-kubeconfig.yaml get seeds.core.gardener.cloud -l "seed.gardener.cloud/region=eu-west-1"
NAME         STATUS   LAST OPERATION               PROVIDER   REGION      AGE     VERSION    K8S VERSION
aws-ha-eu1   Ready    Reconcile Succeeded (100%)   aws        eu-west-1   2y58d   v1.109.0   v1.30.5
aws-ha-eu2   Ready    Reconcile Succeeded (100%)   aws        eu-west-1   634d    v1.109.0   v1.30.5
aws-ha-eu3   Ready    Reconcile Succeeded (100%)   aws        eu-west-1   620d    v1.109.0   v1.30.5
aws-ha-eu4   Ready    Reconcile Succeeded (100%)   aws        eu-west-1   578d    v1.109.0   v1.30.5
aws-ha-eu5   Ready    Reconcile Succeeded (100%)   aws        eu-west-1   480d    v1.109.0   v1.30.5
aws-ha-eu6   Ready    Reconcile Succeeded (100%)   aws        eu-west-1   455d    v1.109.0   v1.30.5
aws-ha-eu7   Ready    Reconcile Succeeded (100%)   aws        eu-west-1   397d    v1.109.0   v1.30.5


$> kubectl --kubeconfig gardener-dev-kubeconfig.yaml get seeds.core.gardener.cloud -o yaml
apiVersion: v1
items:
- apiVersion: core.gardener.cloud/v1beta1
  kind: Seed
  metadata:
    labels:
      ...
      seed.gardener.cloud/region: eu-west-1
  spec:
    backup: ...
    dns:...
    ingress: ...
    networks: ...
    provider:
      region: eu-central-1
      type: alicloud
      zones:
      - eu-central-1a
      - eu-central-1b
      - eu-central-1c
    settings: ...
  status: ...

If a seed exists, we continue and create the cluster. A dedicated timeout how long we max. wait until Gardener created the Shoot is not required - we rely on the existing waiting logic.

TBC: As second line of defence, we check also if the replied lastOperation in the shoot-spec indicates a non-existing seed (<< this case should never become true and has to be tracked as an error in KIM logs).

AC:

• Clarify in the team if we should still check for the replied error message to detect if Gardener couldn't schedule the shoot because no matching Seed was found
• The existing logic is enhanced and checks for the existence of a Seed in the Shoot region
  • If shoot exists, we continue and wait for the cluster creation
    • verify if the lastOperation indicates a non-existing seed in this region - if yes, we have to log an error as this indicates a bug in our seed-determination logic.
  • If shoot not exists, fail the shoot creation as we cannot fulfill the requirement to have the Seed and Shoot in the same region