Remove some extra Spaces (#10949)

content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md

@@ -137,7 +137,7 @@ However, this design is prone to the classic time-of-check-to-time-of-use ([TOCT
 
 We went a bit wild with this idea:
 
-* Create a working directory under the kubelet’s pod directory. Let’s  call it `dir1`.
+* Create a working directory under the kubelet’s pod directory. Let’s call it `dir1`.
 * Bind mount the base volume to under the working directory, `dir1/volume`.
 * Chroot to the working directory `dir1`.
 * Inside the chroot, bind mount `volume/subpath` to `subpath`.  This ensures that any symlinks get resolved to inside the chroot environment.

content/en/docs/concepts/storage/volumes.md

@@ -1191,16 +1191,16 @@ persistent volume:
 - `controllerPublishSecretRef`: A reference to the secret object containing
   sensitive information to pass to the CSI driver to complete the CSI
   `ControllerPublishVolume` and `ControllerUnpublishVolume` calls. This field is
-  optional, and  may be empty if no secret is required. If the secret object
+  optional, and may be empty if no secret is required. If the secret object
   contains more than one secret, all secrets are passed.
 - `nodeStageSecretRef`: A reference to the secret object containing
   sensitive information to pass to the CSI driver to complete the CSI
-  `NodeStageVolume` call. This field is optional, and  may be empty if no secret
+  `NodeStageVolume` call. This field is optional, and may be empty if no secret
   is required. If the secret object contains more than one secret, all secrets
   are passed.
 - `nodePublishSecretRef`: A reference to the secret object containing
   sensitive information to pass to the CSI driver to complete the CSI
-  `NodePublishVolume` call. This field is optional, and  may be empty if no
+  `NodePublishVolume` call. This field is optional, and may be empty if no
   secret is required. If the secret object contains more than one secret, all
   secrets are passed.
 

content/en/docs/concepts/workloads/controllers/deployment.md

@@ -74,7 +74,7 @@ In this example:
 To create this Deployment, run the following command:
 
 ```shell
-kubectl create -f  https://k8s.io/examples/controllers/nginx-deployment.yaml
+kubectl create -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 ```
 
 {{< note >}}

content/en/docs/getting-started-guides/windows/_index.md

@@ -365,7 +365,7 @@ Some of these limitations will be addressed by the community in future releases
 - Under the networking models of L3 or Host GW, Kubernetes Services are inaccessible to Windows nodes due to a Windows issue. This is not an issue if using OVN/OVS for networking.
 - Windows kubelet.exe may fail to start when running on Windows Server under VMware Fusion [issue 57110](https://github.com/kubernetes/kubernetes/pull/57124)
 - Flannel and Weavenet are not yet supported
-- Some .Net Core applications expect environment variables with a colon (`:`) in the name.  Kubernetes currently does not allow this.  Replace colon (`:`) with  double underscore (`__`) as documented [here](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration#configuration-by-environment).
+- Some .Net Core applications expect environment variables with a colon (`:`) in the name. Kubernetes currently does not allow this.  Replace colon (`:`) with  double underscore (`__`) as documented [here](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration#configuration-by-environment).
 - As cgroups are not supported on windows, kubelet.exe should be started with the following additional arguments `--cgroups-per-qos=false --enforce-node-allocatable=""` [issue 61716](https://github.com/kubernetes/kubernetes/issues/61716)
 
 ## Next steps and resources

content/en/docs/reference/access-authn-authz/service-accounts-admin.md

@@ -23,14 +23,14 @@ incomplete features are referred to in order to better describe service accounts
 Kubernetes distinguishes between the concept of a user account and a service account
 for a number of reasons:
 
-  - User accounts are for humans.  Service accounts are for processes, which
+  - User accounts are for humans. Service accounts are for processes, which
     run in pods.
   - User accounts are intended to be global. Names must be unique across all
     namespaces of a cluster, future user resource will not be namespaced.
     Service accounts are namespaced.
   - Typically, a cluster's User accounts might be synced from a corporate
     database, where new user account creation requires special privileges and
-    is tied to complex business  processes.  Service account creation is intended
+    is tied to complex business processes. Service account creation is intended
     to be more lightweight, allowing cluster users to create service accounts for
     specific tasks (i.e. principle of least privilege).
   - Auditing considerations for humans and service accounts may differ.

content/en/docs/reference/glossary/cloud-controller-manager.md

@@ -16,5 +16,5 @@ tags:
 
 <!--more--> 
 
-Kubernetes v1.6 contains a new binary called cloud-controller-manager. cloud-controller-manager is a daemon that embeds cloud-specific control loops.  These cloud-specific control loops were originally in the kube-controller-manager. Since cloud providers develop and release at a different pace compared to the Kubernetes  project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code.
+Kubernetes v1.6 contains a new binary called cloud-controller-manager. cloud-controller-manager is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the kube-controller-manager. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code.
 

content/en/docs/reference/setup-tools/kubeadm/implementation-details.md

@@ -86,7 +86,7 @@ In any case the user can skip specific preflight checks (or eventually all prefl
     - [error] if not Kernel 3.10+ or 4+ with specific KernelSpec
     - [error] if required cgroups subsystem aren't in set up
   - if using docker:
-    - [warning/error] if Docker service does not  exist, if it is disabled, if it is not active.
+    - [warning/error] if Docker service does not exist, if it is disabled, if it is not active.
     - [error] if Docker endpoint does not exist or does not work
     - [warning] if docker version >17.03
   - If using other cri engine:
@@ -200,7 +200,7 @@ Static Pod manifest share a set of common properties:
   of using Pod Priority and Preemption when ready)
 - `hostNetwork: true` is set on all static Pods to allow control plane startup before a network is configured; as a consequence:
   * The `address` that the controller-manager and the scheduler use to refer the API server is `127.0.0.1`
-  * If using a local etcd server, `etcd-servers` address  will be set to `127.0.0.1:2379`
+  * If using a local etcd server, `etcd-servers` address will be set to `127.0.0.1:2379`
 - Leader election is enabled for both the controller-manager and the scheduler
 - Controller-manager and the scheduler will reference kubeconfig files with their respective, unique identities
 - All static Pods gets any extra flags specified by the user as described in [passing custom arguments to control plane components](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-args)
@@ -224,7 +224,7 @@ The static Pod manifest for the API server is affected by following parameters p
  - The `service-cluster-ip-range` to use for services
  - If an external etcd server is specified, the `etcd-servers` address and related TLS settings (`etcd-cafile`, `etcd-certfile`, `etcd-keyfile`);
    if an external etcd server is not be provided, a local etcd will be used (via host network)
- - If a cloud provider is specified, the corresponding `--cloud-provider` is configured, together with  the  `--cloud-config` path
+ - If a cloud provider is specified, the corresponding `--cloud-provider` is configured, together with the  `--cloud-config` path
    if such file exists (this is experimental, alpha and will be removed in a future version)
  - If kubeadm is invoked with `--feature-gates=HighAvailability`, the flag `--endpoint-reconciler-type=lease` is set, thus enabling
    automatic reconciliation of endpoints for the internal API server VIP
@@ -277,7 +277,7 @@ The static Pod manifest for the API server is affected by following parameters p
    setting:
    - `--allocate-node-cidrs=true`
    - `--cluster-cidr` and `--node-cidr-mask-size` flags according to the given CIDR
- - If a cloud provider is specified, the corresponding `--cloud-provider` is specified, together with  the  `--cloud-config` path
+ - If a cloud provider is specified, the corresponding `--cloud-provider` is specified, together with the  `--cloud-config` path
    if such configuration file exists (this is experimental, alpha and will be removed in a future version)
 
 Other flags that are set unconditionally are: