Nit: Fix a typo in the cluster-autoscaler docs (gardener#9293)

* Fix a typo in the cluster-autoscaler docs

* Fix broken links

docs/development/defaulting.md

@@ -11,7 +11,7 @@ It serves as a common guide that we commit to follow in our project to ensure co
 ## Writing defaulting code
 
 - Every kubernetes type should have a dedicated `defaults_*.go` file. For instance, if you have a [`Shoot`](../../pkg/apis/core/types_shoot.go) type, there should be a corresponding [`defaults_shoot.go`](../../pkg/apis/core/v1beta1/defaults_shoot.go) file containing all defaulting logic for that type.
-- If there is only one type under an api group then we can just have `types.go` and a corresponding `defaults.go`. For instance, `resourcemanager` api has only one [`types.go`]((../../pkg/resourcemanager/apis/config/v1alpha1/types.go)), hence in this case only [`defaults.go`](../../pkg/resourcemanager/apis/config/v1alpha1/defaults.go) file would suffice. 
+- If there is only one type under an api group then we can just have `types.go` and a corresponding `defaults.go`. For instance, `resourcemanager` api has only one [`types.go`](../../pkg/resourcemanager/apis/config/v1alpha1/types.go), hence in this case only [`defaults.go`](../../pkg/resourcemanager/apis/config/v1alpha1/defaults.go) file would suffice. 
 - Aim to segregate each struct type into its own `SetDefaults_*` function. These functions encapsulate the defaulting logic specific to the corresponding struct type, enhancing modularity and maintainability. For example, [`ServerConfiguration`](https://github.com/gardener/gardener/blob/ff5a5be6049777b0695659a50189e461e1b17796/pkg/resourcemanager/apis/config/v1alpha1/types.go#L64-L74) struct in `resourcemanager` api has corresponding [`SetDefaults_ServerConfiguration()`](https://github.com/gardener/gardener/blob/ff5a5be6049777b0695659a50189e461e1b17796/pkg/resourcemanager/apis/config/v1alpha1/defaults.go#L73-L92) function.
 
 :warning: Ensure to run the `make generate WHAT=codegen` command when new `SetDefaults_*` function is added, which generates the `zz_generated.defaults.go` file containing the overall defaulting function.

docs/usage/shoot_autoscaling.md

@@ -25,7 +25,7 @@ The following flags are general options for `cluster-autoscaler`, and these valu
 * `.spec.kubernetes.clusterAutoscaler.scaleDownUtilizationThreshold` defines the threshold under which a node is being removed (default: `0.5`).
 * `.spec.kubernetes.clusterAutoscaler.scanInterval` defines how often cluster is reevaluated for scale up or down (default: `10s`). 
 * `.spec.kubernetes.clusterAutoscaler.ignoreTaints` specifies a list of taint keys to ignore in node templates when considering to scale a node group (default: `nil`). 
-* `.spec.kubernetes.clusterAutoscaler.newPodScaleupDelay` specifies how long CA should ignore newly created pods before they have to be considered for scale-up.
+* `.spec.kubernetes.clusterAutoscaler.newPodScaleUpDelay` specifies how long CA should ignore newly created pods before they have to be considered for scale-up.
 * `.spec.kubernetes.clusterAutoscaler.maxEmptyBulkDelete` specifies the maximum number of empty nodes that can be deleted at the same time (default: 10).
 
 The following flags allow some `cluster-autoscaler` flags to be set per worker pool. They are specified along with the worker and override any general value such as those specified in the flags above

docs/usage/shoot_credentials_rotation.md

@@ -192,7 +192,7 @@ There is no automatic rotation and **it is the responsibility of the end-user to
 The rotation happens in three stages:
 
 - In stage one, a new encryption key is created and added to the bundle (together with the old encryption key).
-- In stage two, all `Secret`s in the cluster and resources configured in the `spec.kubernetes.kubeAPIServer.encryptionConfig` of the Shoot (See [ETCD Encryption Config](./shoot_etcd_encryption_config.md)) are rewritten by the `kube-apiserver` so that they become encrypted with the new encryption key.
+- In stage two, all `Secret`s in the cluster and resources configured in the `spec.kubernetes.kubeAPIServer.encryptionConfig` of the Shoot (see [ETCD Encryption Config](./etcd_encryption_config.md)) are rewritten by the `kube-apiserver` so that they become encrypted with the new encryption key.
 - In stage three, the old encryption is dropped from the bundle.
 
 Technically, the `Preparing` phase indicates the stages one and two.