Proofread the Deployments section (gardener#7310)

docs/deployment/authentication_gardener_control_plane.md

@@ -1,16 +1,16 @@
-# Authentication of Gardener control plane components against the Garden cluster
+# Authentication of Gardener Control Plane Components Against the Garden Cluster
 
-**Note:** This document refers to Gardener's API server, admission controller, controller manager and scheduler components. Any reference to the term **Gardener control plane component** can be replaced with any of the mentioned above.
+> **Note:** This document refers to Gardener's API server, admission controller, controller manager and scheduler components. Any reference to the term **Gardener control plane component** can be replaced with any of the mentioned above.
 
 There are several authentication possibilities depending on whether or not [the concept of Virtual Garden](https://github.com/gardener/garden-setup#concept-the-virtual-cluster) is used.
 
 ## Virtual Garden is not used, i.e., the `runtime` Garden cluster is also the `target` Garden cluster.
 
-#### Automounted Service Account Token
-The easiest way to deploy a **Gardener control plane component** will be to not provide `kubeconfig` at all. This way in-cluster configuration and an automounted service account token will be used. The drawback of this approach is that the automounted token will not be automatically rotated.
+### Automounted Service Account Token
+The easiest way to deploy a **Gardener control plane component** is to not provide a `kubeconfig` at all. This way in-cluster configuration and an automounted service account token will be used. The drawback of this approach is that the automounted token will not be automatically rotated.
 
-#### Service Account Token Volume Projection
-Another solution will be to use [Service Account Token Volume Projection](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) combined with a `kubeconfig` referencing a token file (see example below).
+### Service Account Token Volume Projection
+Another solution is to use [Service Account Token Volume Projection](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) combined with a `kubeconfig` referencing a token file (see the example below).
 ```yaml
 apiVersion: v1
 kind: Config
@@ -35,28 +35,30 @@ This will allow for automatic rotation of the service account token by the `kube
 
 ## Virtual Garden is used, i.e., the `runtime` Garden cluster is different from the `target` Garden cluster.
 
-#### Service Account
-The easiest way to setup the authentication will be to create a service account and the respective roles will be bound to this service account in the `target` cluster. Then use the generated service account token and craft a `kubeconfig` which will be used by the workload in the `runtime` cluster. This approach does not provide a solution for the rotation of the service account token. However, this setup can be achieved by setting `.Values.global.deployment.virtualGarden.enabled: true` and following these steps:
+### Service Account
+The easiest way to setup the authentication is to create a service account and the respective roles will be bound to this service account in the `target` cluster. Then use the generated service account token and craft a `kubeconfig`, which will be used by the workload in the `runtime` cluster. This approach does not provide a solution for the rotation of the service account token. However, this setup can be achieved by setting `.Values.global.deployment.virtualGarden.enabled: true` and following these steps:
 
 1. Deploy the `application` part of the charts in the `target` cluster.
 2. Get the service account token and craft the `kubeconfig`.
 3. Set the crafted `kubeconfig` and deploy the `runtime` part of the charts in the `runtime` cluster.
 
-#### Client Certificate
-Another solution will be to bind the roles in the `target` cluster to a `User` subject instead of a service account and use a client certificate for authentication. This approach does not provide a solution for the client certificate rotation. However, this setup can be achieved by setting both `.Values.global.deployment.virtualGarden.enabled: true` and `.Values.global.deployment.virtualGarden.<GardenerControlPlaneComponent>.user.name`, then following these steps:
+### Client Certificate
+Another solution is to bind the roles in the `target` cluster to a `User` subject instead of a service account and use a client certificate for authentication. This approach does not provide a solution for the client certificate rotation. However, this setup can be achieved by setting both `.Values.global.deployment.virtualGarden.enabled: true` and `.Values.global.deployment.virtualGarden.<GardenerControlPlaneComponent>.user.name`, then following these steps:
 
 1. Generate a client certificate for the `target` cluster for the respective user.
 2. Deploy the `application` part of the charts in the `target` cluster.
 3. Craft a `kubeconfig` using the already generated client certificate.
 4. Set the crafted `kubeconfig` and deploy the `runtime` part of the charts in the `runtime` cluster.
 
-#### Projected Service Account Token
-This approach requires an already deployed and configured [oidc-webhook-authenticator](https://github.com/gardener/oidc-webhook-authenticator) for the `target` cluster. Also the `runtime` cluster should be registered as a trusted identity provider in the `target` cluster. Then projected service accounts tokens from the `runtime` cluster can be used to authenticate against the `target` cluster. The needed steps are as follows:
+### Projected Service Account Token
+This approach requires an already deployed and configured [oidc-webhook-authenticator](https://github.com/gardener/oidc-webhook-authenticator) for the `target` cluster. Also, the `runtime` cluster should be registered as a trusted identity provider in the `target` cluster. Then, projected service accounts tokens from the `runtime` cluster can be used to authenticate against the `target` cluster. The needed steps are as follows:
 
 1. Deploy [OWA](https://github.com/gardener/oidc-webhook-authenticator) and establish the needed trust.
-2. Set `.Values.global.deployment.virtualGarden.enabled: true` and `.Values.global.deployment.virtualGarden.<GardenerControlPlaneComponent>.user.name`. **Note:** username value will depend on the trust configuration, e.g., `<prefix>:system:serviceaccount:<namespace>:<serviceaccount>`
-3. Set `.Values.global.<GardenerControlPlaneComponent>.serviceAccountTokenVolumeProjection.enabled: true` and `.Values.global.<GardenerControlPlaneComponent>.serviceAccountTokenVolumeProjection.audience`. **Note:** audience value will depend on the trust configuration, e.g., `<cliend-id-from-trust-config>`.
-4. Craft a kubeconfig (see example below).
+2. Set `.Values.global.deployment.virtualGarden.enabled: true` and `.Values.global.deployment.virtualGarden.<GardenerControlPlaneComponent>.user.name`. 
+    > **Note:** username value will depend on the trust configuration, e.g., `<prefix>:system:serviceaccount:<namespace>:<serviceaccount>`
+3. Set `.Values.global.<GardenerControlPlaneComponent>.serviceAccountTokenVolumeProjection.enabled: true` and `.Values.global.<GardenerControlPlaneComponent>.serviceAccountTokenVolumeProjection.audience`. 
+    > **Note:** audience value will depend on the trust configuration, e.g., `<cliend-id-from-trust-config>`.
+4. Craft a kubeconfig (see the example below).
 5. Deploy the `application` part of the charts in the `target` cluster.
 6. Deploy the `runtime` part of the charts in the `runtime` cluster.
 

docs/deployment/configuring_logging.md

@@ -1,18 +1,18 @@
-# Configuring the Logging stack via Gardenlet configurations
+# Configuring the Logging Stack via gardenlet Configurations
 
-# Enable the Logging
+## Enable the Logging
 
-In order to install the Gardener logging stack the `logging.enabled` configuration option has to be enabled in the Gardenlet configuration:
+In order to install the Gardener logging stack, the `logging.enabled` configuration option has to be enabled in the Gardenlet configuration:
 ```yaml
 logging:
   enabled: true
 ```
 
-From now on each Seed is going to have a logging stack which will collect logs from all pods and some systemd services. Logs related to Shoots with `testing` purpose are dropped in the `fluent-bit` output plugin. Shoots with a purpose different than `testing` have the same type of log aggregator (but different instance) as the Seed. The logs can be viewed in the Grafana in the `garden` namespace for the Seed components and in the respective shoot control plane namespaces.
+From now on, each Seed is going to have a logging stack which will collect logs from all pods and some systemd services. Logs related to Shoots with `testing` purpose are dropped in the `fluent-bit` output plugin. Shoots with a purpose different than `testing` have the same type of log aggregator (but different instance) as the Seed. The logs can be viewed in the Grafana in the `garden` namespace for the Seed components and in the respective shoot control plane namespaces.
 
-# Enable logs from the Shoot's node systemd services.
+## Enable Logs from the Shoot's Node systemd Services
 
-The logs from the systemd services on each node can be retrieved by enabling the `logging.shootNodeLogging` option in the Gardenlet configuration:
+The logs from the systemd services on each node can be retrieved by enabling the `logging.shootNodeLogging` option in the gardenlet configuration:
 ```yaml
 logging:
   enabled: true
@@ -22,16 +22,16 @@ logging:
     - "deployment"
 ```
 
-Under the `shootPurpose` section just list all the shoot purposes for which the Shoot node logging feature will be enabled. Specifying the `testing` purpose has no effect because this purpose prevents the logging stack installation.
+Under the `shootPurpose` section, just list all the shoot purposes for which the Shoot node logging feature will be enabled. Specifying the `testing` purpose has no effect because this purpose prevents the logging stack installation.
 Logs can be  viewed in the operator Grafana!
-The dedicated labels are `unit`, `syslog_identifier` and `nodename` in the `Explore` menu.
+The dedicated labels are `unit`, `syslog_identifier`, and `nodename` in the `Explore` menu.
 
-# Configuring the log processor
+## Configuring the Log Processor
 
-Under `logging.fluentBit` there is three optional sections.
-- `input`: This overwrite the input configuration of the fluent-bit log processor.
- - `output`: This overwrite the output configuration of the fluent-bit log processor.
- - `service`: This overwrite the service configuration of the fluent-bit log processor.
+Under `logging.fluentBit` there are three optional sections:
+- `input`: This overwrites the input configuration of the fluent-bit log processor.
+ - `output`: This overwrites the output configuration of the fluent-bit log processor.
+ - `service`: This overwrites the service configuration of the fluent-bit log processor.
 
 ```yaml
 logging:
@@ -48,9 +48,9 @@ logging:
           ...
 ```
 
-# additional egress IPBlock for allow-fluentbit NetworkPolicy
+## Additional egress IPBlock for allow-fluentbit NetworkPolicy
 
-The optional setting under `logging.fluentBit.networkPolicy.additionalEgressIPBlocks` add additional egress IPBlock to `allow-fluentbit` NetworkPolicy to forward logs to a central system.
+The optional setting under `logging.fluentBit.networkPolicy.additionalEgressIPBlocks` adds an additional egress IPBlock to `allow-fluentbit` NetworkPolicy to forward logs to a central system.
 
 ```yaml
 logging:
@@ -60,9 +60,9 @@ logging:
       - 123.123.123.123/32
 ```
 
-# Configure central logging
+## Configure Central Logging
 
-For central logging, the output configuration of the fluent-bit log processor can be overwritten (`logging.fluentBit.output`) and the Loki instances deployments in Garden and Shoot namespace can be enabled/disabled (`logging.loki.enabled`), by default Loki is enabled.
+For central logging, the output configuration of the fluent-bit log processor can be overwritten (`logging.fluentBit.output`) and the Loki instances deployments in the Garden and Shoot namespace can be enabled/disabled (`logging.loki.enabled`), by default Loki is enabled.
 
 ```yaml
 logging:
@@ -75,12 +75,12 @@ logging:
     enabled: false
 ```
 
-# Configuring central Loki storage capacity
+## Configuring Central Loki Storage Capacity
 
 By default, the central Loki has `100Gi` of storage capacity.
 To overwrite the current central Loki storage capacity, the `logging.loki.garden.storage` setting in the gardenlet's component configuration should be altered.
-If you need to increase it you can do so without losing the current data by specifying higher capacity. Doing so, the Loki's `PersistentVolume` capacity will be increased instead of deleting the current PV.
-However, if you specify less capacity then the `PersistentVolume` will be deleted and with it the logs, too.
+If you need to increase it, you can do so without losing the current data by specifying a higher capacity. By doing so, the Loki's `PersistentVolume` capacity will be increased instead of deleting the current PV.
+However, if you specify less capacity, then the `PersistentVolume` will be deleted and with it the logs, too.
 
 ```yaml
 logging:

docs/deployment/deploy_gardenlet.md

@@ -1,17 +1,14 @@
 # Deploying Gardenlets
 
-Gardenlets act as decentral "agents" to manage shoot clusters of a seed cluster.
+Gardenlets act as decentral "agents" to manage the shoot clusters of a seed cluster.
 
-To support scaleability in an automated way, gardenlets are deployed automatically. However, you can still deploy gardenlets manually to be more flexible, for example, when shoot clusters that need to be managed by Gardener are behind a firewall. The gardenlet only requires network connectivity from the gardenlet to the Garden cluster (not the other way round), so it can be used to register Kubernetes clusters with no public endpoint. 
+To support scaleability in an automated way, gardenlets are deployed automatically. However, you can still deploy gardenlets manually to be more flexible, for example, when the shoot clusters that need to be managed by Gardener are behind a firewall. The gardenlet only requires network connectivity from the gardenlet to the Garden cluster (not the other way round), so it can be used to register Kubernetes clusters with no public endpoint. 
 
 ## Procedure
 
 1. First, an initial gardenlet needs to be deployed:
 
-   * Deploy it manually if you have special requirements. More information: [Deploy a Gardenlet Manually](deploy_gardenlet_manually.md)
-   * Let the Gardener installer deploy it automatically otherwise. More information: [Automatic Deployment of Gardenlets](deploy_gardenlet_automatically.md)
-
-1. To add additional seed clusters, it is recommended to use regular shoot clusters. You can do this by creating a `ManagedSeed` resource with a `gardenlet` section as described in [Register Shoot as Seed](../usage/managed_seed.md). 
-
-
+   * Deploy it manually if you have special requirements. For more information, see [Deploy a Gardenlet Manually](deploy_gardenlet_manually.md).
+   * Let the Gardener installer deploy it automatically otherwise.  For more information, see [Automatic Deployment of Gardenlets](deploy_gardenlet_automatically.md).
 
+1. To add additional seed clusters, it is recommended to use regular shoot clusters. You can do this by creating a `ManagedSeed` resource with a `gardenlet` section as described in [Register Shoot as Seed](../usage/managed_seed.md).

docs/deployment/deploy_gardenlet_automatically.md

@@ -1,22 +1,21 @@
-# Automatic Deployment of Gardenlets
+# Automatic Deployment of gardenlets
 
-The gardenlet can automatically deploy itself into shoot clusters, and register this cluster as a seed cluster. 
+The gardenlet can automatically deploy itself into shoot clusters, and register a cluster as a seed cluster. 
 These clusters are called "managed seeds" (aka "shooted seeds"). 
 This procedure is the preferred way to add additional seed clusters, because shoot clusters already come with production-grade qualities that are also demanded for seed clusters.
 
 ## Prerequisites
 
-The only prerequisite is to register an initial cluster as a seed cluster that has already a gardenlet deployed:
+The only prerequisite is to register an initial cluster as a seed cluster that already has a gardenlet deployed in one of the following ways:
 
-* This gardenlet was either deployed as part of a Gardener installation using a setup tool (for example, `gardener/garden-setup`) or
-* the gardenlet was deployed manually 
-  - for a step-by-step manual installation Guide see: [Deploy a Gardenlet Manually](deploy_gardenlet_manually.md))
+* The gardenlet was deployed as part of a Gardener installation using a setup tool (for example, `gardener/garden-setup`).
+* The gardenlet was deployed manually (for a step-by-step manual installation guide, see [Deploy a Gardenlet Manually](deploy_gardenlet_manually.md)).
 
 > The initial cluster can be the garden cluster itself.
 
-## Self-Deployment of Gardenlets in Additional Managed Seed Clusters
+## Self-Deployment of gardenlets in Additional Managed Seed Clusters
 
-For a better scalability, you usually need more seed clusters that you can create as follows:
+For a better scalability, you usually need more seed clusters that you can create, as follows:
 
 1. Use the initial cluster as the seed cluster for other managed seed clusters. It hosts the control planes of the other seed clusters.
 1. The gardenlet deployed in the initial cluster deploys itself automatically into the managed seed clusters.  
@@ -25,7 +24,5 @@ The advantage of this approach is that there’s only one initial gardenlet inst
 
 ## Related Links
 
-[Register Shoot as Seed](../usage/managed_seed.md)
-
-[garden-setup](http://github.com/gardener/garden-setup)
-
+- [Register Shoot as Seed](../usage/managed_seed.md)
+- [garden-setup](http://github.com/gardener/garden-setup)