Website Cleanup Part 6 - Proposals (Part 2) (gardener#7488)

* Proofread files

* Update docs/proposals/20-ha-control-planes.md

Co-authored-by: Ismail Alidzhikov <i.alidjikov@gmail.com>

* Update docs/proposals/20-ha-control-planes.md

Co-authored-by: Ismail Alidzhikov <i.alidjikov@gmail.com>

* Apply suggestions from code review

Co-authored-by: Sonu Kumar Singh <sonu.kumar.singh02@sap.com>

---------

Co-authored-by: Ismail Alidzhikov <i.alidjikov@gmail.com>
Co-authored-by: Sonu Kumar Singh <sonu.kumar.singh02@sap.com>

docs/proposals/01-extensibility.md

@@ -45,7 +45,7 @@ This proposal aims to move out the cloud-specific implementations (called "(clou
 
 Currently, it is too hard to support additional cloud providers or operation systems/distributions as everything must be done in-tree, which might affect the implementation of other cloud providers as well.
 The various conditions and branches make the code hard to maintain and hard to test.
-Every change must be done centrally, requires to completely rebuild Gardener, and cannot be deployed individually. Similar to the motivation for Kubernetes to extract their cloud-specifics into dedicated cloud-controller-managers or to extract the container/storage/network/... specifics into CRI/CSI/CNI/..., we aim to do the same right now.
+Every change must be done centrally, requires to completely rebuild Gardener, and cannot be deployed individually. Similarly to the motivation for Kubernetes to extract their cloud-specifics into dedicated cloud-controller-managers or to extract the container/storage/network/... specifics into CRI/CSI/CNI/..., we aim to do the same right now.
 
 ### Goals
 

docs/proposals/03-networking-extensibility.md

@@ -17,7 +17,7 @@ Finally, every provider is different, and thus the network always needs to adapt
 
 ## Gardener Network Extension
 
-The goal of the Gardener Network Extensions is to support different network plugin, therefore, the specification for the network resource won't be fixed and will be customized based on the underlying network plugin. To do so, a `NetworkConfig` field in the spec will be provided where each plugin will be defined. Below is an example for deploying Calico as the cluster network plugin.
+The goal of the Gardener Network Extensions is to support different network plugins, therefore the specification for the network resource won't be fixed and will be customized based on the underlying network plugin. To do so, a `NetworkConfig` field in the spec will be provided where each plugin will be defined. Below is an example of deploying Calico as the cluster network plugin.
 
 
 ### Long Term Spec

docs/proposals/07-shoot-control-plane-migration.md

@@ -173,7 +173,7 @@ status:
 
 Extensions which do not require state migration should set `status.state=nil` in their Custom Resources and trigger a normal reconciliation operation if the CR contains the `core.gardener.cloud/operation=restore` annotation.
 
-Similar to the contract for the [reconcile operation](https://github.com/gardener/gardener/blob/master/docs/extensions/reconcile-trigger.md), the extension controller has to remove the `restore` annotation after the restoration operation has finished.
+Similarly to the contract for the [reconcile operation](https://github.com/gardener/gardener/blob/master/docs/extensions/reconcile-trigger.md), the extension controller has to remove the `restore` annotation after the restoration operation has finished.
 
 An additional annotation `gardener.cloud/operation=migrate` is added to the Custom Resources. It is used to tell the extension controllers in the **Source Seed** that they must stop reconciling resources (in case they are requeued due to errors) and should perform cleanup activities in the Shoot's control plane. These cleanup activities involve removing the finalizers on Custom Resources and deleting them without actually deleting any infrastructure resources.
 

docs/proposals/10-shoot-additional-container-runtimes.md

@@ -97,7 +97,7 @@ Each extension will need to address the following concerns:
         2. Apply the relevant RuntimeClass to the cluster.
 
     2. The installation above should be done by a new kind of extension: ContainerRuntime resource. For each container runtime type (Kata-container/gvisor), a dedicate extension controller will be created.
-        1. A label for each container runtime support will be added to every node that belongs to the worker pool. This should be done similar to the way labels created today for each node, through kubelet execution parameters (`_kubelet.flags: --node-labels`). When creating the OperatingSystemConfig (original) for the worker, each container runtime support should be mapped to a label on the node.
+        1. A label for each container runtime support will be added to every node that belongs to the worker pool. This should be done similarly to the way labels are created today for each node, through kubelet execution parameters (`_kubelet.flags: --node-labels`). When creating the OperatingSystemConfig (original) for the worker, each container runtime support should be mapped to a label on the node.
            For Example:
            label: `container.runtime.kata-containers=true` (shoot.spec.cloud.<IAAS>.worker.containerRuntimes.kata-container)
            label: `container.runtime.gvisor=true` (shoot.spec.cloud.<IAAS>.worker.containerRuntimes.gvisor)