Fixed broken links (gardener#4993)

* Fixed broken links

* Resolved comments

docs/development/process.md

@@ -99,7 +99,7 @@ This section explains how to initiate cherry picks on release branches within th
 Before you initiate a cherry pick, make sure that the following prerequisites are accomplished.
 
 - A pull request merged against the `master` branch.
-- The release branch exists (example: [`release-v1.18`](https://github.com/gardener/gardener/tree/release-v1.18))
+- The release branch exists (check in the [branches section](https://github.com/gardener/gardener/branches))
 - Have the `gardener/gardener` repository cloned as follows:
   - the `origin` remote should point to your fork (alternatively this can be overwritten by passing `FORK_REMOTE=<fork-remote>`)
   - the `upstream` remote should point to the Gardener github org (alternatively this can be overwritten by passing `UPSTREAM_REMOTE=<upstream-remote>`)

docs/extensions/backupbucket.md

@@ -46,7 +46,7 @@ In order to support a new infrastructure provider you need to write a controller
 
 ## References and additional resources
 
-* [`BackupBucket` API Reference](https://gardener.cloud/api-reference/extensions/#extensions.gardener.cloud/v1alpha1.BackupBucket)
+* [`BackupBucket` API Reference](../api-reference/extensions.md#backupbucket)
 * [Exemplary implementation for the Azure provider](https://github.com/gardener/gardener-extension-provider-azure/tree/master/pkg/controller/backupbucket)
 * [`BackupEntry` resource documentation](./backupentry.md)
 * [Shared bucket proposal](../proposals/02-backupinfra.md)

docs/extensions/backupentry.md

@@ -40,8 +40,8 @@ In order to support a new infrastructure provider you need to write a controller
 
 ## References and additional resources
 
-* [`BackupEntry` API Reference](https://gardener.cloud/api-reference/extensions/#extensions.gardener.cloud/v1alpha1.BackupBucket)
+* [`BackupEntry` API Reference](../api-reference/extensions.md#backupbucket)
 * [Exemplary implementation for the Azure provider](https://github.com/gardener/gardener-extension-provider-azure/tree/master/pkg/controller/backupentry)
 * [`BackupBucket` resource documentation](./backupbucket.md)
 * [Shared bucket proposal](../proposals/02-backupinfra.md)
-* [Gardener-controller-manager-component-config API specification](https://github.com/gardener/gardener/blob/master/pkg/controllermanager/apis/config/types.go#L101-#L107)
+* [Gardener-controller-manager-component-config API specification](../../pkg/controllermanager/apis/config/types.go#L101-#L107)

docs/extensions/bastion.md

@@ -37,6 +37,6 @@ Your controller is supposed to create a new instance at the given cloud provider
 
 ## References and additional resources
 
-* [`Bastion` API Reference](https://gardener.cloud/api-reference/extensions/#extensions.gardener.cloud/v1alpha1.Bastion)
+* [`Bastion` API Reference](../api-reference/extensions.md#bastion)
 * [Exemplary implementation for the AWS provider](https://github.com/gardener/gardener-extension-provider-aws/tree/master/pkg/controller/bastion)
 * [GEP-15](../proposals/15-manage-bastions-and-ssh-key-pair-rotation.md)

docs/extensions/managedresources.md

@@ -8,4 +8,4 @@ Extension controllers may create these `ManagedResource`s in the shoot namespace
 
 ## Where can I find more examples and more information how to use `ManagedResource`s?
 
-Please take a look at the [respective documentation](../docs/concepts/resource-manager.md).
+Please take a look at the [respective documentation](../concepts/resource-manager.md).

docs/proposals/01-extensibility.md

@@ -229,7 +229,7 @@ spec:
 ### CRD definitions and workflow adaptation
 
 In the following we are outlining the CRD definitions which define the API between Gardener and the dedicated controllers.
-After that we will take a look at the current [reconciliation](https://github.com/gardener/gardener/blob/master/pkg/controller/shoot/shoot_control_reconcile.go)/[deletion](https://github.com/gardener/gardener/blob/master/pkg/controller/shoot/shoot_control_delete.go) flow and describe how it would look like in case we would implement this proposal.
+After that we will take a look at the current [reconciliation](../../pkg/gardenlet/controller/shoot/shoot_control_reconcile.go)/[deletion](../../pkg/gardenlet/controller/shoot/shoot_control_delete.go) flow and describe how it would look like in case we would implement this proposal.
 
 #### Custom resource definitions
 

docs/proposals/09-test-framework.md

@@ -6,7 +6,7 @@ The current testframework already contains a lot of general test functions that
 However there are multiple disadvantages with the current structure of the tests and the testframework:
 1. Every new test is an own testsuite and therefore needs its own `TestDef` (https://github.com/gardener/gardener/tree/master/.test-defs). With this approach there will be hundreds of test definitions, growing with every new test (or at least new test suite).
    But in most cases new tests do not need their own special `TestDef`: it's just the wrong scope for the testmachinery and will result in unnecessary complex testruns and configurations. In addition it would result in additional maintenance for a huge number of `TestDefs`.
-2. The testsuites currently have their own specific interface/configuration that they need in order to be executed correctly see ([Worker test](https://github.com/gardener/gardener/blob/master/.test-defs/WorkerTest.yaml#L14) or [K8s Update test](https://github.com/gardener/gardener/blob/master/.test-defs/ShootKubernetesUpdateTest.yaml#L14)).
+2. The testsuites currently have their own specific interface/configuration that they need in order to be executed correctly (see [K8s Update test](../../.test-defs/ShootKubernetesUpdateTest.yaml#L14)).
   Consequently the configuration has to be defined in the testruns which result in one step per test with their very own configuration which means that the testmachinery cannot simply select testdefinitions by label.
   As the testmachinery cannot make use of its ability to run labeled tests (e.g. run all tests labeled `default`), the testflow size increases with every new tests and the testruns have to be manually adjusted with every new test.
 3. The current gardener test framework contains multiple test operations where some are just used for specific tests (e.g. `plant_operations`) and some are more general (`garden_operation`). Also the functions offered by the operations vary in their specialization as some are really specific to just one test e.g. shoot test operation with `WaitUntilGuestbookAppIsAvailable` whereas others are more general like `WaitUntilPodIsRunning`.<br>

docs/proposals/15-manage-bastions-and-ssh-key-pair-rotation.md

@@ -206,7 +206,7 @@ Currently, the `ssh` key pair for the shoot nodes are created once during shoot
 
 ### Rotation Proposal
 - `gardeneruser` original user data [component](https://github.com/gardener/gardener/tree/master/pkg/operation/botanist/component/extensions/operatingsystemconfig/original/components/gardeneruser):
-    - The `gardeneruser` [create script](https://github.com/gardener/gardener/blob/master/pkg/operation/botanist/component/extensions/operatingsystemconfig/original/components/gardeneruser/templates/scripts/create.tpl.sh) should be changed into a reconcile script script, and renamed accordingly. It needs to be adapted so that the `authorized_keys` file will be updated / overwritten with the current and old `ssh` public key from the cloud-config user data.
+    - The `gardeneruser` create script should be changed into a reconcile script script, and renamed accordingly. It needs to be adapted so that the `authorized_keys` file will be updated / overwritten with the current and old `ssh` public key from the cloud-config user data.
 - Rotation trigger:
     - Once in the maintenance time window
     - On demand, by annotating the shoot with `gardener.cloud/operation: rotate-ssh-keypair`
@@ -216,7 +216,7 @@ Currently, the `ssh` key pair for the shoot nodes are created once during shoot
         - Creates or updates the secret `ssh-keypair.old` with the content of `ssh-keypair` in the seed-shoot namespace. The old private key can be used by clients as fallback, in case the new `ssh` public key is not yet applied on the node
         - Generates new `ssh-keypair` secret
         - The `OperatingSystemConfig` needs to be re-generated and deployed with the new and old `ssh` public key
-    - As usual (more details on https://github.com/gardener/gardener/blob/master/docs/extensions/operatingsystemconfig.md):
+    - As usual (for more details, see [here](../extensions/operatingsystemconfig.md)):
         - Once the `cloud-config-<X>` secret in the `kube-system` namespace of the shoot cluster is updated, it will be picked up by the [`downloader` script](https://github.com/gardener/gardener/blob/master/pkg/operation/botanist/component/extensions/operatingsystemconfig/downloader/templates/scripts/download-cloud-config.tpl.sh) (checks every 30s for updates)
         - The `downloader` runs the ["execution" script](https://github.com/gardener/gardener/blob/master/pkg/operation/botanist/component/extensions/operatingsystemconfig/executor/templates/scripts/execute-cloud-config.tpl.sh) from the `cloud-config-<X>` secret
         - The "execution" script includes also the original user data script, which it writes to `PATH_CLOUDCONFIG`, compares it against the previous cloud config and runs the script in case it has changed

docs/usage/docker-shim-removal.md

@@ -20,7 +20,7 @@ As a shoot owner:
 - [check if you have dependencies to the `docker` container runtime](https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/#find-docker-dependencies). **Note:** This is not only about your actual workload, but also concerns ops tooling as well as logging, monitoring and metric agents installed on the nodes
 - test with `containerd`:
   - create a new Shoot or add a Worker Pool to an existing one
-  - [set `.spec.provider.workers[].cri.name: containerd`](https://gardener.cloud/docs/references/core/#core.gardener.cloud/v1beta1.CRI) for your Shoot
+  - [set `.spec.provider.workers[].cri.name: containerd`](../api-reference/core.md#cri) for your Shoot
 - once testing is successful, switch to `containerd` with your production workload. You don't need to wait for kubernetes v1.22, `containerd` is considered production ready as of today
 - if you find dependencies to `docker`, set `.spec.provider.workers[].cri.name: docker` explicitly to avoid defaulting to `containerd` once you update your Shoot to kubernetes v1.22
 

docs/usage/node-local-dns.md

@@ -33,4 +33,4 @@ It is worth noting that:
 - When migrating from IPVS to IPTables, existing pods will continue to leverage the node-local-dns cache. 
 - When migrating from IPtables to IPVS, only newer pods will be switched to the node-local-dns cache. 
 
-For more information about `node-local-dns` please refer to the [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0030-nodelocal-dns-cache.md) or to the [usage documentation](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/). 
+For more information about `node-local-dns` please refer to the [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/1024-nodelocal-cache-dns/README.md) or to the [usage documentation](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/). 

docs/usage/shoot_status.md

@@ -1,10 +1,10 @@
 # Shoot Status
 
-This document provides an overview of the [ShootStatus](https://gardener.cloud/docs/references/core/#core.gardener.cloud/v1beta1.ShootStatus).
+This document provides an overview of the [ShootStatus](../api-reference/core.md#shootstatus).
 
 ## Conditions
 
-The Shoot status consists of a set of conditions. A [Condition](https://gardener.cloud/docs/references/core/#core.gardener.cloud/v1beta1.Condition) has the following fields:
+The Shoot status consists of a set of conditions. A [Condition](../api-reference/core.md#condition) has the following fields:
 
 | Field name           | Description                                                                                                        |
 | -------------------- | ------------------------------------------------------------------------------------------------------------------ |
@@ -89,7 +89,7 @@ The Shoot status holds information about the last operation that is performed on
 
 ### Last Errors
 
-The Shoot status also contains information about the last occurred error(s) (if any) during an operation. A [LastError](https://gardener.cloud/docs/references/core/#core.gardener.cloud/v1beta1.LastError) consists of identifier of the task returned error, human-readable message of the error and error codes (if any) associated with the error.
+The Shoot status also contains information about the last occurred error(s) (if any) during an operation. A [LastError](../api-reference/core.md#lasterror) consists of identifier of the task returned error, human-readable message of the error and error codes (if any) associated with the error.
 
 ### Error Codes