Merge branch 'main' into fix-high-availability

docs/contributor/03-10-hyperscaler-account-pool.md

@@ -2,16 +2,16 @@
 
 To provision clusters through Gardener using Runtime Provisioner, Kyma Environment Broker (KEB) requires a hyperscaler (GCP, Azure, AWS, etc.) account/subscription. Managing the available hyperscaler accounts is not in the scope of KEB. Instead, the available accounts are handled by Hyperscaler Account Pool (HAP).
 
-HAP stores credentials for the hyperscaler accounts that have been set up in advance in Kubernetes Secrets. The credentials are stored separately for each provider and tenant. The content of the credentials Secrets may vary for different use cases. The Secrets are labeled with the **hyperscaler-type** and **tenant-name** labels to manage pools of credentials for use by the provisioning process. This way, the in-use credentials and unassigned credentials available for use are tracked. Only the **hyperscaler-type** label is added during Secret creation, and the **tenant-name** label is added when the account respective for a given Secret is claimed. The content of the Secrets is opaque to HAP.
+HAP stores credentials for the hyperscaler accounts that have been set up in advance in Kubernetes Secrets. The credentials are stored separately for each provider and tenant. The content of the credentials Secrets may vary for different use cases. The Secrets are labeled with the **hyperscalerType** and **tenantName** labels to manage pools of credentials for use by the provisioning process. This way, the in-use credentials and unassigned credentials available for use are tracked. Only the **hyperscalerType** label is added during Secret creation, and the **tenantName** label is added when the account respective for a given Secret is claimed. The content of the Secrets is opaque to HAP.
 
 The Secrets are stored in a Gardener seed cluster pointed to by HAP. They are available within a given Gardener project specified in the KEB and Runtime Provisioner configuration. This configuration uses a `kubeconfig` that gives KEB and Runtime Provisioner access to a specific Gardener seed cluster, which, in turn, enables access to those Secrets.
 
 This diagram shows the HAP workflow:
 
 ![hap-workflow](../assets/hap-flow.drawio.svg)
 
-Before a new cluster is provisioned, KEB queries for a Secret based on the **tenant-name** and **hyperscaler-type** labels.
-If a Secret is found, KEB uses the credentials stored in this Secret. If a matching Secret is not found, KEB queries again for an unassigned Secret for a given hyperscaler and adds the **tenant-name** label to claim the account and use the credentials for provisioning.
+Before a new cluster is provisioned, KEB queries for a Secret based on the **tenantName** and **hyperscalerType** labels.
+If a Secret is found, KEB uses the credentials stored in this Secret. If a matching Secret is not found, KEB queries again for an unassigned Secret for a given hyperscaler and adds the **tenantName** label to claim the account and use the credentials for provisioning.
 
 One tenant can use only one account per given hyperscaler type.
 
@@ -23,9 +23,9 @@ kind: Secret
 metadata:
   name: {SECRET_NAME}
   labels:
-    # tenant-name is omitted for new, not yet claimed account credentials
-    tenant-name: {TENANT_NAME}
-    hyperscaler-type: {HYPERSCALER_TYPE}
+    # tenantName is omitted for new, not yet claimed account credentials
+    tenantName: {TENANT_NAME}
+    hyperscalerType: {HYPERSCALER_TYPE}
 ```
 
 ## Shared Credentials
@@ -43,7 +43,7 @@ kind: Secret
 metadata:
   name: {SECRET_NAME}
   labels:
-    hyperscaler-type: {HYPERSCALER_TYPE}
+    hyperscalerType: {HYPERSCALER_TYPE}
     shared: "true"
 ```
 
@@ -61,24 +61,24 @@ kind: Secret
 metadata:
   name: {SECRET_NAME}
   labels:
-    # tenant-name is omitted for new, not yet claimed account credentials
-    tenant-name: {TENANT_NAME}
-    hyperscaler-type: {HYPERSCALER_TYPE}
+    # tenantName is omitted for new, not yet claimed account credentials
+    tenantName: {TENANT_NAME}
+    hyperscalerType: {HYPERSCALER_TYPE}
     euAccess: "true"
 ```
 
 ## Assured Workloads
 
 SAP BTP, Kyma runtime supports the BTP cf-sa30 GCP subaccount region. This region uses the Assured Workloads Kingdom of Saudi Arabia (KSA) control package. Kyma Control Plane manages cf-sa30 Kyma runtimes in a separate
-Google Cloud hyperscaler account pool. The Secret contains the label **hyperscaler-type** set to `gcp_cf-sa30`. The following is an example of a Secret that uses the Assured Workloads KSA control package:
+Google Cloud hyperscaler account pool. The Secret contains the label **hyperscalerType** set to `gcp_cf-sa30`. The following is an example of a Secret that uses the Assured Workloads KSA control package:
 
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
   name: {SECRET_NAME}
   labels:
-    # tenant-name is omitted for new, not yet claimed account credentials
-    tenant-name: {TENANT_NAME}
-    hyperscaler-type: "gcp_cf-sa30"
+    # tenantName is omitted for new, not yet claimed account credentials
+    tenantName: {TENANT_NAME}
+    hyperscalerType: "gcp_cf-sa30"
 ```