diff --git a/content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md b/content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md
index 9dd1a4759c..b7a25e7473 100644
--- a/content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md
+++ b/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.
diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md
index 7ce8c092db..3820394deb 100644
--- a/content/en/docs/concepts/storage/volumes.md
+++ b/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.
diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md
index c738991a8c..3a2455c930 100644
--- a/content/en/docs/concepts/workloads/controllers/deployment.md
+++ b/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 >}}
diff --git a/content/en/docs/getting-started-guides/windows/_index.md b/content/en/docs/getting-started-guides/windows/_index.md
index 022e86fda3..5243a6ccfb 100644
--- a/content/en/docs/getting-started-guides/windows/_index.md
+++ b/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
diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md
index 932f9fb225..7e030903bc 100644
--- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md
+++ b/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.
diff --git a/content/en/docs/reference/glossary/cloud-controller-manager.md b/content/en/docs/reference/glossary/cloud-controller-manager.md
index 0962c0c359..9a818ff93e 100755
--- a/content/en/docs/reference/glossary/cloud-controller-manager.md
+++ b/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.
diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
index 8d846acbc7..867c17691e 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
+++ b/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: