Proofread files (gardener#7394)

-fixed etc. usage
-fixed absolute links

docs/concepts/cluster-api.md

@@ -4,7 +4,7 @@ title: Cluster API
 
 # Relation Between Gardener API and Cluster API (SIG Cluster Lifecycle)
 
-In essence, the Cluster API harmonizes how to get to clusters, while Gardener goes one step further and also harmonizes the clusters themselves. The Cluster API delegates the specifics to so-called providers for infrastructures or control planes via specific CR(D)s, while Gardener only has one cluster CR(D). Different Cluster API providers, e.g. for AWS, Azure, GCP, etc. give you vastly different Kubernetes clusters. In contrast, Gardener gives you the exact same clusters with the exact same K8s version, operating system, control plane configuration like for API server or kubelet, add-ons like overlay network, HPA/VPA, DNS and certificate controllers, ingress and network policy controllers, control plane monitoring and logging stacks, down to the behavior of update procedures, auto-scaling, self-healing, etc. on all supported infrastructures. These homogeneous clusters are an essential goal for Gardener, as its main purpose is to simplify operations for teams that need to develop and ship software on Kubernetes clusters on a plethora of infrastructures (a.k.a. multi-cloud).
+In essence, the Cluster API harmonizes how to get to clusters, while Gardener goes one step further and also harmonizes the clusters themselves. The Cluster API delegates the specifics to so-called providers for infrastructures or control planes via specific CR(D)s, while Gardener only has one cluster CR(D). Different Cluster API providers, e.g. for AWS, Azure, GCP, etc., give you vastly different Kubernetes clusters. In contrast, Gardener gives you the exact same clusters with the exact same K8s version, operating system, control plane configuration like for API server or kubelet, add-ons like overlay network, HPA/VPA, DNS and certificate controllers, ingress and network policy controllers, control plane monitoring and logging stacks, down to the behavior of update procedures, auto-scaling, self-healing, etc., on all supported infrastructures. These homogeneous clusters are an essential goal for Gardener, as its main purpose is to simplify operations for teams that need to develop and ship software on Kubernetes clusters on a plethora of infrastructures (a.k.a. multi-cloud).
 
 Incidentally, Gardener influenced the Machine API in the Cluster API with its [Machine Controller Manager](https://github.com/gardener/machine-controller-manager) and was the [first to adopt it](https://github.com/kubernetes-sigs/cluster-api/commit/00b1ead264aea6f88585559056c180771cce3815). You can find more information on that in the [joint SIG Cluster Lifecycle KubeCon talk](https://www.youtube.com/watch?v=Mtg8jygK3Hs) where @hardikdr from our Gardener team in India spoke.
 

docs/concepts/etcd.md

@@ -5,7 +5,7 @@ title: etcd
 # etcd - Key-Value Store for Kubernetes
 
 [etcd](https://etcd.io/) is a strongly consistent key-value store and the most prevalent choice for the Kubernetes
-persistence layer. All API cluster objects like `Pod`s, `Deployment`s, `Secret`s, etc. are stored in `etcd`, which
+persistence layer. All API cluster objects like `Pod`s, `Deployment`s, `Secret`s, etc., are stored in `etcd`, which
 makes it an essential part of a [Kubernetes control plane](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components).
 
 ## Garden or Shoot Cluster Persistence

docs/concepts/network_policies.md

@@ -14,4 +14,4 @@ The aforementioned namespaces in the Seed contain a `deny-all` network policy th
 This [secure by default](https://en.wikipedia.org/wiki/Secure_by_default) setting requires pods to allow network traffic.
 This is done by pods having [labels matching to the selectors of the network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource) deployed by Gardener.
 
-More details on the deployed network policies can be found in the [development](https://github.com/gardener/gardener/tree/master/docs/development/seed_network_policies.md) and [usage](https://github.com/gardener/gardener/tree/master/docs/usage/shoot_network_policies.md) sections.
+More details on the deployed network policies can be found in the [development](../development/seed_network_policies.md) and [usage](../usage/shoot_network_policies.md) sections.

docs/concepts/operator.md

@@ -1,7 +1,7 @@
 # Gardener Operator
 
 The `gardener-operator` is meant to be responsible for the garden cluster environment.
-Without this component, users must deploy ETCD, the Gardener control plane, etc. manually and with separate mechanisms (not maintained in this repository).
+Without this component, users must deploy ETCD, the Gardener control plane, etc., manually and with separate mechanisms (not maintained in this repository).
 This is quite unfortunate since this requires separate tooling, processes, etc.
 A lot of production- and enterprise-grade features were built into Gardener for managing the seed and shoot clusters, so it makes sense to re-use them as much as possible also for the garden cluster.
 

docs/concepts/resource-manager.md

@@ -203,8 +203,8 @@ This can be done from the components that create the managed resource secrets, f
 
 The objects which are part of the `ManagedResource` can be annotated with:
 
-- `resources.gardener.cloud/preserve-replicas=true` in case the `.spec.replicas` field of workload resources like `Deployment`s, `StatefulSet`s, etc. shall be preserved during updates.
-- `resources.gardener.cloud/preserve-resources=true` in case the `.spec.containers[*].resources` fields of all containers of workload resources like `Deployment`s, `StatefulSet`s, etc. shall be preserved during updates.
+- `resources.gardener.cloud/preserve-replicas=true` in case the `.spec.replicas` field of workload resources like `Deployment`s, `StatefulSet`s, etc., shall be preserved during updates.
+- `resources.gardener.cloud/preserve-resources=true` in case the `.spec.containers[*].resources` fields of all containers of workload resources like `Deployment`s, `StatefulSet`s, etc., shall be preserved during updates.
 
 > This can be useful if there are non-standard horizontal/vertical auto-scaling mechanisms in place.
 Standard mechanisms like `HorizontalPodAutoscaler` or `VerticalPodAutoscaler` will be auto-recognized by `gardener-resource-manager`, i.e., in such cases the annotations are not needed.

docs/deployment/getting_started_locally_with_extensions.md

@@ -156,7 +156,7 @@ Please ensure that your KinD and Seed clusters are online (not paused or hiberna
 make gardener-extensions-down
 ```
 
-This will delete all `Shoots` first (this could take a couple of minutes), then uninstall `gardenlet` from the Seed and the gardener components from the KinD. Finally, the additional components like container registry, etc. are deleted from both clusters.
+This will delete all `Shoots` first (this could take a couple of minutes), then uninstall `gardenlet` from the Seed and the gardener components from the KinD. Finally, the additional components like container registry, etc., are deleted from both clusters.
 
 When this is done, you can securely delete your local KinD cluster by running:
 

docs/development/high-availability.md

@@ -1,6 +1,6 @@
 # High Availability of Deployed Components
 
-`gardenlet`s and extension controllers are deploying components via `Deployment`s, `StatefulSet`s, etc. as part of the shoot control plane, or the seed or shoot system components.
+`gardenlet`s and extension controllers are deploying components via `Deployment`s, `StatefulSet`s, etc., as part of the shoot control plane, or the seed or shoot system components.
 
 Some of the above component deployments must be further tuned to improve fault tolerance / resilience of the service. This document outlines what needs to be done to achieve this goal.
 
@@ -21,7 +21,7 @@ spec:
     - europe-1c
 ```
 
-Independent of the number of zones, seed system components like the `gardenlet` or the extension controllers themselves, or others like `etcd-druid`, `dependency-watchdog`, etc. should always be running with multiple replicas.
+Independent of the number of zones, seed system components like the `gardenlet` or the extension controllers themselves, or others like `etcd-druid`, `dependency-watchdog`, etc., should always be running with multiple replicas.
 
 Concretely, all seed system components should respect the following conventions:
 

docs/development/kubernetes-clients.md

@@ -43,7 +43,7 @@ _Important characteristics of client-go clients:_
 ### Generated Client Sets for Gardener APIs
 
 Gardener's APIs extend the Kubernetes API by registering an extension API server (in the garden cluster) and `CustomResourceDefinition`s (on Seed clusters), meaning that the Kubernetes API will expose additional REST endpoints to manage Gardener resources in addition to the built-in API resources.
-In order to talk to these extended APIs in our controllers and components, client-gen is used to generate client-go-style clients to [`pkg/client/{core,extensions,seedmanagement,...}`](https://github.com/gardener/gardener/tree/master/pkg/client).
+In order to talk to these extended APIs in our controllers and components, client-gen is used to generate client-go-style clients to [`pkg/client/{core,extensions,seedmanagement,...}`](../../pkg/client).
 
 Usage of these clients is equivalent to `client-go` clients, and the same characteristics apply. For example:
 

docs/development/local_setup.md

@@ -96,7 +96,7 @@ When running on macOS, install the GNU core utilities and friends:
 brew install coreutils gnu-sed gnu-tar grep
 ```
 
-This will create symbolic links for the GNU utilities with `g` prefix in `/usr/local/bin`, e.g., `gsed` or `gbase64`. To allow using them without the `g` prefix please put `/usr/local/opt/coreutils/libexec/gnubin` etc. at the beginning of your `PATH` environment variable, e.g., `export PATH=/usr/local/opt/coreutils/libexec/gnubin:$PATH` (`brew` will print out instructions for each installed formula).
+This will create symbolic links for the GNU utilities with `g` prefix in `/usr/local/bin`, e.g., `gsed` or `gbase64`. To allow using them without the `g` prefix please put `/usr/local/opt/coreutils/libexec/gnubin` etc., at the beginning of your `PATH` environment variable, e.g., `export PATH=/usr/local/opt/coreutils/libexec/gnubin:$PATH` (`brew` will print out instructions for each installed formula).
 
 ```bash
 export PATH=/usr/local/opt/coreutils/libexec/gnubin:$PATH

docs/development/priority-classes.md

@@ -4,7 +4,7 @@ Gardener makes use of [`PriorityClass`es](https://kubernetes.io/docs/concepts/sc
 In order to benefit from the full potential of `PriorityClass`es, the gardenlet manages a set of well-known `PriorityClass`es with fine-granular priority values.
 
 All components of the system should use these well-known `PriorityClass`es instead of creating and using separate ones with arbitrary values, which would compromise the overall goal of using `PriorityClass`es in the first place.
-Gardenlet manages the well-known `PriorityClass`es listed in this document, so that third parties (e.g., Gardener extensions) can rely on them to be present when deploying components to Seed and Shoot clusters.
+The gardenlet manages the well-known `PriorityClass`es listed in this document, so that third parties (e.g., Gardener extensions) can rely on them to be present when deploying components to Seed and Shoot clusters.
 
 The listed well-known `PriorityClass`es follow this rough concept:
 

docs/development/testmachinery_tests.md

@@ -171,7 +171,7 @@ It also contains functions to interact with gardener like `Waiting for a shoot t
 It expects a running shoot cluster defined by the shoot's name and namespace (project namespace).
 This framework contains functions to directly interact with the specific shoot.
 
-The whole framework also includes commonly used checks, ginkgo wrapper, etc. as well as commonly used tests.
+The whole framework also includes commonly used checks, ginkgo wrapper, etc., as well as commonly used tests.
 Theses common application tests (like the guestbook test) can be used within multiple tests to have a default application (with ingress, deployment, stateful backend) to test external factors.
 
 

docs/extensions/admission.md

@@ -1,5 +1,5 @@
 # Extension Admission
 
-The extensions are expected to validate their respective resources for their extension specific configurations, when the resources are newly created or updated. For example, [provider extensions](../../extensions/README.md#infrastructure-provider) would validate `spec.provider.infrastructureConfig` and `spec.provider.controlPlaneConfig` in the `Shoot` resource and `spec.providerConfig` in the `CloudProfile` resource, [networking extensions](../../extensions/README.md#network-plugin) would validate `spec.networking.providerConfig` in the `Shoot` resource. As best practice, the validation should be performed only if there is a change in the `spec` of the resource. Please find an exemplary implementation [here](https://github.com/gardener/gardener-extension-provider-aws/tree/master/pkg/admission/validator).
+The extensions are expected to validate their respective resources for their extension specific configurations, when the resources are newly created or updated. For example, [provider extensions](../../extensions/README.md#infrastructure-provider) would validate `spec.provider.infrastructureConfig` and `spec.provider.controlPlaneConfig` in the `Shoot` resource and `spec.providerConfig` in the `CloudProfile` resource, [networking extensions](../../extensions/README.md#network-plugin) would validate `spec.networking.providerConfig` in the `Shoot` resource. As best practice, the validation should be performed only if there is a change in the `spec` of the resource. Please find an exemplary implementation in the [gardener/gardener-extension-provider-aws](https://github.com/gardener/gardener-extension-provider-aws/tree/master/pkg/admission/validator) repository.
 
-When a resource is newly created or updated, Gardener adds an extension label for all the extension types referenced in the `spec` of the resource. This label is of the form `<extension-type>.extensions.gardener.cloud/<extension-name> : "true"`. For example, an extension label for provider extension type `aws`, looks like `provider.extensions.gardener.cloud/aws : "true"`. The extensions should add object selectors in their admission webhooks for these labels, to filter out the objects they are responsible for. At present, these labels are added to `BackupEntry`s, `BackupBucket`s, `CloudProfile`s, `Seed`s, `SecretBinding`s and `Shoot`s. Please see [this](https://github.com/gardener/gardener/tree/master/pkg/apis/core/v1beta1/constants/types_constants.go) for the full list of extension labels.
+When a resource is newly created or updated, Gardener adds an extension label for all the extension types referenced in the `spec` of the resource. This label is of the form `<extension-type>.extensions.gardener.cloud/<extension-name> : "true"`. For example, an extension label for a provider extension type `aws` looks like `provider.extensions.gardener.cloud/aws : "true"`. The extensions should add object selectors in their admission webhooks for these labels, to filter out the objects they are responsible for. At present, these labels are added to `BackupEntry`s, `BackupBucket`s, `CloudProfile`s, `Seed`s, `SecretBinding`s and `Shoot`s. Please see the [types_constants.go](../../pkg/apis/core/v1beta1/constants/types_constants.go) file for the full list of extension labels.

docs/extensions/backupbucket.md

@@ -7,20 +7,20 @@ title: BackupBucket
 The Gardener project features a sub-project called [etcd-backup-restore](https://github.com/gardener/etcd-backup-restore) to take periodic backups of etcd backing Shoot clusters. It demands the bucket (or its equivalent in different object store providers) to be created and configured externally with appropriate credentials. The `BackupBucket` resource takes this responsibility in Gardener.
 
 Before introducing the `BackupBucket` extension resource, Gardener was using Terraform in order to create and manage these provider-specific resources (e.g., see [AWS Backup](https://github.com/gardener/gardener/tree/0.27.0/charts/seed-terraformer/charts/aws-backup)).
-Now, Gardener commissions an external, provider-specific controller to take over this task. You can also refer to [backupInfra proposal documentation](../proposals/02-backupinfra.md) to get idea about how the transition was done and understand the resource in broader scope.
+Now, Gardener commissions an external, provider-specific controller to take over this task. You can also refer to [backupInfra proposal documentation](../proposals/02-backupinfra.md) to get an idea about how the transition was done and understand the resource in a broader scope.
 
-## What is the Scope of Bucket?
+## What Is the Scope of a Bucket?
 
 A bucket will be provisioned per `Seed`. So, a backup of every `Shoot` created on that `Seed` will be stored under a different shoot specific prefix under the bucket.
 For the backup of the `Shoot` rescheduled on different `Seed`, it will continue to use the same bucket.
 
-## What is the Lifespan of `BackupBucket`?
+## What Is the Lifespan of a `BackupBucket`?
 
 The bucket associated with `BackupBucket` will be created at the creation of the `Seed`. And as per current implementation, it will also be deleted on deletion of the `Seed`, if there isn't any `BackupEntry` resource associated with it.
 
-In the future, we plan to introduce a schedule for `BackupBucket` - the deletion logic for the `BackupBucket` resource, which will reschedule  it on different available `Seed`s on deletion or failure of a health check for the currently associated `seed`. In that case, the `BackupBucket` will be deleted only if there isn't any schedulable `Seed` available and there isn't any associated `BackupEntry` resource.
+In the future, we plan to introduce a schedule for `BackupBucket` - the deletion logic for the `BackupBucket` resource, which will reschedule it on different available `Seed`s on deletion or failure of a health check for the currently associated `seed`. In that case, the `BackupBucket` will be deleted only if there isn't any schedulable `Seed` available and there isn't any associated `BackupEntry` resource.
 
-## What Needs to be Implemented to Support a New Infrastructure Provider?
+## What Needs to Be Implemented to Support a New Infrastructure Provider?
 
 As part of the seed flow, Gardener will create a special CRD in the seed cluster that needs to be reconciled by an extension controller, for example:
 
@@ -42,13 +42,13 @@ spec:
 
 The `.spec.secretRef` contains a reference to the provider secret pointing to the account that shall be used to create the needed resources. This provider secret will be configured by the Gardener operator in the `Seed` resource and propagated over there by the seed controller.
 
-After your controller has created the required bucket, if required, it generates the secret to access the objects in the bucket and put a reference to it in `status`. This secret is supposed to be used by Gardener or eventually a `BackupEntry` resource and etcd-backup-restore component to backup the etcd.
+After your controller has created the required bucket, if required, it generates the secret to access the objects in the bucket and put a reference to it in `status`. This secret is supposed to be used by Gardener, or eventually a `BackupEntry` resource and etcd-backup-restore component, to backup the etcd.
 
 In order to support a new infrastructure provider, you need to write a controller that watches all `BackupBucket`s with `.spec.type=<my-provider-name>`. You can take a look at the below referenced example implementation for the Azure provider.
 
 ## References and Additional Resources
 
 * [`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)
+* [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)