Merge pull request #26352 from kbhawkey/fixup-remove-word-easy

clean up use of word: easy

content/en/docs/concepts/cluster-administration/_index.md

@@ -26,12 +26,12 @@ See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and
 
 Before choosing a guide, here are some considerations:
 
- - Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
+ - Do you want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
  - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
  - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
  - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
  - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
- - Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
+ - Do you **want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
    latter, choose an actively-developed distro. Some distros only use binary releases, but
    offer a greater variety of choices.
  - Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster.

content/en/docs/concepts/cluster-administration/manage-deployment.md

@@ -70,7 +70,7 @@ deployment.apps "my-nginx" deleted
 service "my-nginx-svc" deleted
 ```
 
-In the case of just two resources, it's also easy to specify both on the command line using the resource/name syntax:
+In the case of two resources, you can specify both resources on the command line using the resource/name syntax:
 
 ```shell
 kubectl delete deployments/my-nginx services/my-nginx-svc
@@ -87,7 +87,7 @@ deployment.apps "my-nginx" deleted
 service "my-nginx-svc" deleted
 ```
 
-Because `kubectl` outputs resource names in the same syntax it accepts, it's easy to chain operations using `$()` or `xargs`:
+Because `kubectl` outputs resource names in the same syntax it accepts, you can chain operations using `$()` or `xargs`:
 
 ```shell
 kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service)
@@ -302,6 +302,7 @@ Sometimes you would want to attach annotations to resources. Annotations are arb
 kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'
 kubectl get pods my-nginx-v4-9gw19 -o yaml
 ```
+
 ```shell
 apiVersion: v1
 kind: pod
@@ -315,11 +316,12 @@ For more information, please see [annotations](/docs/concepts/overview/working-w
 
 ## Scaling your application
 
-When load on your application grows or shrinks, it's easy to scale with `kubectl`. For instance, to decrease the number of nginx replicas from 3 to 1, do:
+When load on your application grows or shrinks, use `kubectl` to scale your application. For instance, to decrease the number of nginx replicas from 3 to 1, do:
 
 ```shell
 kubectl scale deployment/my-nginx --replicas=1
 ```
+
 ```shell
 deployment.apps/my-nginx scaled
 ```
@@ -329,6 +331,7 @@ Now you only have one pod managed by the deployment.
 ```shell
 kubectl get pods -l app=nginx
 ```
+
 ```shell
 NAME                        READY     STATUS    RESTARTS   AGE
 my-nginx-2035384211-j5fhi   1/1       Running   0          30m
@@ -339,6 +342,7 @@ To have the system automatically choose the number of nginx replicas as needed,
 ```shell
 kubectl autoscale deployment/my-nginx --min=1 --max=3
 ```
+
 ```shell
 horizontalpodautoscaler.autoscaling/my-nginx autoscaled
 ```
@@ -412,6 +416,7 @@ In some cases, you may need to update resource fields that cannot be updated onc
 ```shell
 kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
 ```
+
 ```shell
 deployment.apps/my-nginx deleted
 deployment.apps/my-nginx replaced
@@ -428,14 +433,17 @@ Let's say you were running version 1.14.2 of nginx:
 ```shell
 kubectl create deployment my-nginx --image=nginx:1.14.2
 ```
+
 ```shell
 deployment.apps/my-nginx created
 ```
 
 with 3 replicas (so the old and new revisions can coexist):
+
 ```shell
 kubectl scale deployment my-nginx --current-replicas=1 --replicas=3
 ```
+
 ```
 deployment.apps/my-nginx scaled
 ```

content/en/docs/concepts/cluster-administration/system-logs.md

@@ -31,22 +31,24 @@ I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/
 
 {{< feature-state for_k8s_version="v1.19" state="alpha" >}}
 
-{{<warning>}}
+{{< warning >}}
 Migration to structured log messages is an ongoing process. Not all log messages are structured in this version. When parsing log files, you must also handle unstructured log messages.
 
 Log formatting and value serialization are subject to change.
 {{< /warning>}}
 
-Structured logging is a effort to introduce a uniform structure in log messages allowing for easy extraction of information, making logs easier and cheaper to store and process.
+Structured logging introduces a uniform structure in log messages allowing for programmatic extraction of information. You can store and process structured logs with less effort and cost.
 New message format is backward compatible and enabled by default.
 
 Format of structured logs:
-```
+
+```ini
 <klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
 ```
 
 Example:
-```
+
+```ini
 I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
 ```
 

content/en/docs/concepts/configuration/overview.md

@@ -59,13 +59,13 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
 
 - Avoid using `hostNetwork`, for the same reasons as `hostPort`.
 
-- Use [headless Services](/docs/concepts/services-networking/service/#headless-services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing.
+- Use [headless Services](/docs/concepts/services-networking/service/#headless-services) (which have a `ClusterIP` of `None`) for service discovery when you don't need `kube-proxy` load balancing.
 
 ## Using Labels
 
 - Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) app for examples of this approach.
 
-A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. [Deployments](/docs/concepts/workloads/controllers/deployment/) make it easy to update a running service without downtime.
+A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. When you need to update a running service without downtime, use a [Deployment](/docs/concepts/workloads/controllers/deployment/).
 
 A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate.
 

content/en/docs/concepts/overview/what-is-kubernetes.md

@@ -43,7 +43,7 @@ Each VM is a full machine running all the components, including its own operatin
 Containers have become popular because they provide extra benefits, such as:
 
 * Agile application creation and deployment: increased ease and efficiency of container image creation compared to VM image use.
-* Continuous development, integration, and deployment: provides for reliable and frequent container image build and deployment with quick and easy rollbacks (due to image immutability).
+* Continuous development, integration, and deployment: provides for reliable and frequent container image build and deployment with quick and efficient rollbacks (due to image immutability).
 * Dev and Ops separation of concerns: create application container images at build/release time rather than deployment time, thereby decoupling applications from infrastructure.
 * Observability not only surfaces OS-level information and metrics, but also application health and other signals.
 * Environmental consistency across development, testing, and production: Runs the same on a laptop as it does in the cloud.

content/en/docs/concepts/overview/working-with-objects/labels.md

@@ -42,7 +42,7 @@ Example labels:
    * `"partition" : "customerA"`, `"partition" : "customerB"`
    * `"track" : "daily"`, `"track" : "weekly"`
 
-These are just examples of commonly used labels; you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object.
+These are examples of commonly used labels; you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object.
 
 ## Syntax and character set
 

content/en/docs/concepts/overview/working-with-objects/object-management.md

@@ -31,7 +31,7 @@ When using imperative commands, a user operates directly on live objects
 in a cluster. The user provides operations to
 the `kubectl` command as arguments or flags.
 
-This is the simplest way to get started or to run a one-off task in
+This is the recommended way to get started or to run a one-off task in
 a cluster. Because this technique operates directly on live
 objects, it provides no history of previous configurations.
 
@@ -47,7 +47,7 @@ kubectl create deployment nginx --image nginx
 
 Advantages compared to object configuration:
 
-- Commands are simple, easy to learn and easy to remember.
+- Commands are expressed as a single action word.
 - Commands require only a single step to make changes to the cluster.
 
 Disadvantages compared to object configuration:

content/en/docs/concepts/scheduling-eviction/scheduling-framework.md

@@ -10,11 +10,9 @@ weight: 70
 
 {{< feature-state for_k8s_version="v1.15" state="alpha" >}}
 
-The scheduling framework is a pluggable architecture for Kubernetes Scheduler
+The scheduling framework is a pluggable architecture for the Kubernetes scheduler.
-that makes scheduler customizations easy. It adds a new set of "plugin" APIs to
+It adds a new set of "plugin" APIs to the existing scheduler. Plugins are compiled into the scheduler. The APIs allow most scheduling features to be implemented as plugins, while keeping the
-the existing scheduler. Plugins are compiled into the scheduler. The APIs
+scheduling "core" lightweight and maintainable. Refer to the [design proposal of the
-allow most scheduling features to be implemented as plugins, while keeping the
-scheduling "core" simple and maintainable. Refer to the [design proposal of the
 scheduling framework][kep] for more technical information on the design of the
 framework.
 

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

@@ -208,7 +208,8 @@ As mentioned above, whether you have 1 pod you want to keep running, or 1000, a
 
 ### Scaling
 
-The ReplicationController makes it easy to scale the number of replicas up or down, either manually or by an auto-scaling control agent, by simply updating the `replicas` field.
+The ReplicationController scales the number of replicas up or down by setting the `replicas` field.
+You can configure the ReplicationController to manage the replicas manually or by an auto-scaling control agent.
 
 ### Rolling updates
 

content/en/docs/reference/access-authn-authz/authentication.md

@@ -68,8 +68,8 @@ when interpreted by an [authorizer](/docs/reference/access-authn-authz/authoriza
 
 You can enable multiple authentication methods at once. You should usually use at least two methods:
 
- - service account tokens for service accounts
+- service account tokens for service accounts
- - at least one other method for user authentication.
+- at least one other method for user authentication.
 
 When multiple authenticator modules are enabled, the first module
 to successfully authenticate the request short-circuits evaluation.
@@ -321,13 +321,11 @@ sequenceDiagram
 9.  `kubectl` provides feedback to the user
 
 Since all of the data needed to validate who you are is in the `id_token`, Kubernetes doesn't need to
-"phone home" to the identity provider.  In a model where every request is stateless this provides a very scalable
+"phone home" to the identity provider.  In a model where every request is stateless this provides a very scalable solution for authentication.  It does offer a few challenges:
-solution for authentication.  It does offer a few challenges:
-
-1.  Kubernetes has no "web interface" to trigger the authentication process.  There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first.
-2.  The `id_token` can't be revoked, it's like a certificate so it should be short-lived (only a few minutes) so it can be very annoying to have to get a new token every few minutes.
-3.  There's no easy way to authenticate to the Kubernetes dashboard without using the `kubectl proxy` command or a reverse proxy that injects the `id_token`.
 
+1. Kubernetes has no "web interface" to trigger the authentication process.  There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first.
+2. The `id_token` can't be revoked, it's like a certificate so it should be short-lived (only a few minutes) so it can be very annoying to have to get a new token every few minutes.
+3. To authenticate to the Kubernetes dashboard, you must the `kubectl proxy` command or a reverse proxy that injects the `id_token`.
 
 #### Configuring the API Server
 

content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md

@@ -1093,8 +1093,8 @@ be a layering violation). `host` may also be an IP address.
 Please note that using `localhost` or `127.0.0.1` as a `host` is
 risky unless you take great care to run this webhook on all hosts
 which run an apiserver which might need to make calls to this
-webhook. Such installs are likely to be non-portable, i.e., not easy
+webhook. Such installations are likely to be non-portable or not readily
-to turn up in a new cluster.
+run in a new cluster.
 
 The scheme must be "https"; the URL must begin with "https://".
 

content/en/docs/reference/glossary/wg.md

@@ -12,9 +12,8 @@ tags:
 ---
  Facilitates the discussion and/or implementation of a short-lived, narrow, or decoupled project for a committee, {{< glossary_tooltip text="SIG" term_id="sig" >}}, or cross-SIG effort.
 
-<!--more--> 
+<!--more-->
 
-Working groups are a way of organizing people to accomplish a discrete task, and are relatively easy to create and deprecate when inactive.
+Working groups are a way of organizing people to accomplish a discrete task.
 
 For more information, see the [kubernetes/community](https://github.com/kubernetes/community) repo and the current list of [SIGs and working groups](https://github.com/kubernetes/community/blob/master/sig-list.md).
-

content/en/docs/reference/kubernetes-api/extend-resources/custom-resource-definition-v1.md

@@ -250,15 +250,15 @@ CustomResourceDefinitionSpec describes how a user wants their resource to appear
   - **conversion.webhook.clientConfig.url** (string)
 
     url gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.
-    
+
     The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
-    
+
-    Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster.
+    Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installations are likely to be non-portable or not readily run in a new cluster.
-    
+
     The scheme must be "https"; the URL must begin with "https://".
-    
+
     A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier.
-    
+
     Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either.
 
 - **preserveUnknownFields** (boolean)

content/en/docs/reference/kubernetes-api/extend-resources/mutating-webhook-configuration-v1.md

@@ -82,15 +82,15 @@ MutatingWebhookConfiguration describes the configuration of and admission webhoo
   - **webhooks.clientConfig.url** (string)
 
     `url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.
-    
+
     The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
-    
+
-    Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster.
+    Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installations are likely to be non-portable or not readily run in a new cluster.
-    
+
     The scheme must be "https"; the URL must begin with "https://".
-    
+
     A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier.
-    
+
     Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either.
 
   - **webhooks.name** (string), required

content/en/docs/reference/kubernetes-api/extend-resources/validating-webhook-configuration-v1.md

@@ -82,15 +82,15 @@ ValidatingWebhookConfiguration describes the configuration of and admission webh
   - **webhooks.clientConfig.url** (string)
 
     `url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.
-    
+
     The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
-    
+
-    Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster.
+    Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installations are likely to be non-portable or not readily run in a new cluster.
-    
+
     The scheme must be "https"; the URL must begin with "https://".
-    
+
     A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier.
-    
+
     Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either.
 
   - **webhooks.name** (string), required

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

@@ -28,7 +28,7 @@ The cluster that `kubeadm init` and `kubeadm join` set up should be:
    - lock-down the kubelet API
    - locking down access to the API for system components like the kube-proxy and CoreDNS
    - locking down what a Bootstrap Token can access
- - **Easy to use**: The user should not have to run anything more than a couple of commands:
+ - **User-friendly**: The user should not have to run anything more than a couple of commands:
    - `kubeadm init`
    - `export KUBECONFIG=/etc/kubernetes/admin.conf`
    - `kubectl apply -f <network-of-choice.yaml>`

content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md

@@ -108,7 +108,7 @@ if the `kubeadm init` command was called with `--upload-certs`.
   control-plane node even if other worker nodes or the network are compromised.
 
 - Convenient to execute manually since all of the information required fits
-  into a single `kubeadm join` command that is easy to copy and paste.
+  into a single `kubeadm join` command.
 
 **Disadvantages:**
 

content/en/docs/reference/tools.md

@@ -20,8 +20,8 @@ Kubernetes contains several built-in tools to help you work with the Kubernetes
 
 ## Minikube
 
-[`minikube`](https://minikube.sigs.k8s.io/docs/) is a tool that makes it
+[`minikube`](https://minikube.sigs.k8s.io/docs/) is a tool that
-easy to run a single-node Kubernetes cluster locally on your workstation for
+runs a single-node Kubernetes cluster locally on your workstation for
 development and testing purposes.
 
 ## Dashboard
@@ -51,4 +51,3 @@ Use Kompose to:
 * Translate a Docker Compose file into Kubernetes objects
 * Go from local Docker development to managing your application via Kubernetes
 * Convert v1 or v2 Docker Compose `yaml` files or [Distributed Application Bundles](https://docs.docker.com/compose/bundles/)
-

content/en/docs/reference/using-api/server-side-apply.md

@@ -297,7 +297,7 @@ is not what the user wants to happen, even temporarily.
 
 There are two solutions:
 
-- (easy) Leave `replicas` in the configuration; when HPA eventually writes to that
+- (basic) Leave `replicas` in the configuration; when HPA eventually writes to that
   field, the system gives the user a conflict over it. At that point, it is safe
   to remove from the configuration.
 

content/en/docs/setup/production-environment/tools/kops.md

@@ -39,7 +39,7 @@ kops is an automated provisioning system:
 
 #### Installation
 
-Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also easy to build from source):
+Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also convenient to build from source):
 
 {{< tabs name="kops_installation" >}}
 {{% tab name="macOS" %}}
@@ -147,7 +147,7 @@ You must then set up your NS records in the parent domain, so that records in th
 you would create NS records in `example.com` for `dev`.  If it is a root domain name you would configure the NS
 records at your domain registrar (e.g. `example.com` would need to be configured where you bought `example.com`).
 
-This step is easy to mess up (it is the #1 cause of problems!)  You can double-check that
+Verify your route53 domain setup (it is the #1 cause of problems!). You can double-check that
 your cluster is configured correctly if you have the dig tool by running:
 
 `dig NS dev.example.com`

content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md

@@ -15,7 +15,7 @@ Windows applications constitute a large portion of the services and applications
 
 ## Windows containers in Kubernetes
 
-To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in {{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is as simple and easy as scheduling Linux-based containers.
+To enable the orchestration of Windows containers in Kubernetes, include Windows nodes in your existing Linux cluster. Scheduling Windows containers in {{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is similar to scheduling Linux-based containers.
 
 In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
 

content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md

@@ -163,7 +163,7 @@ Backing up an etcd cluster can be accomplished in two ways: etcd built-in snapsh
 
 ### Built-in snapshot
 
-etcd supports built-in snapshot, so backing up an etcd cluster is easy. A snapshot may either be taken from a live member with the `etcdctl snapshot save` command or by copying the `member/snap/db` file from an etcd [data directory](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/configuration.md#--data-dir) that is not currently used by an etcd process. Taking the snapshot will normally not affect the performance of the member.
+etcd supports built-in snapshot. A snapshot may either be taken from a live member with the `etcdctl snapshot save` command or by copying the `member/snap/db` file from an etcd [data directory](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/configuration.md#--data-dir) that is not currently used by an etcd process. Taking the snapshot will normally not affect the performance of the member.
 
 Below is an example for taking a snapshot of the keyspace served by `$ENDPOINT` to the file `snapshotdb`:
 

content/en/docs/tasks/administer-cluster/limit-storage-consumption.md

@@ -5,7 +5,7 @@ content_type: task
 
 <!-- overview -->
 
-This example demonstrates an easy way to limit the amount of storage consumed in a namespace.
+This example demonstrates how to limit the amount of storage consumed in a namespace.
 
 The following resources are used in the demonstration: [ResourceQuota](/docs/concepts/policy/resource-quotas/),
 [LimitRange](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/),

content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md

@@ -583,14 +583,13 @@ and can optionally include a custom CA bundle to use to verify the TLS connectio
 The `host` should not refer to a service running in the cluster; use
 a service reference by specifying the `service` field instead.
 The host might be resolved via external DNS in some apiservers
-(i.e., `kube-apiserver` cannot resolve in-cluster DNS as that would 
+(i.e., `kube-apiserver` cannot resolve in-cluster DNS as that would
 be a layering violation). `host` may also be an IP address.
 
 Please note that using `localhost` or `127.0.0.1` as a `host` is
 risky unless you take great care to run this webhook on all hosts
 which run an apiserver which might need to make calls to this
-webhook. Such installs are likely to be non-portable, i.e., not easy
+webhook. Such installations are likely to be non-portable or not readily run in a new cluster.
-to turn up in a new cluster.
 
 The scheme must be "https"; the URL must begin with "https://".
 

content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md

@@ -35,7 +35,7 @@ non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).
 
 ## Starting a message queue service
 
-This example uses RabbitMQ, but it should be easy to adapt to another AMQP-type message service.
+This example uses RabbitMQ, however, you can adapt the example to use another AMQP-type message service.
 
 In practice you could set up a message queue service once in a
 cluster and reuse it for many jobs, as well as for long-running services.

content/en/docs/tasks/run-application/horizontal-pod-autoscale.md

@@ -191,7 +191,7 @@ We can create a new autoscaler using `kubectl create` command.
 We can list autoscalers by `kubectl get hpa` and get detailed description by `kubectl describe hpa`.
 Finally, we can delete an autoscaler using `kubectl delete hpa`.
 
-In addition, there is a special `kubectl autoscale` command for easy creation of a Horizontal Pod Autoscaler.
+In addition, there is a special `kubectl autoscale` command for creating a HorizontalPodAutoscaler object.
 For instance, executing `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`
 will create an autoscaler for replication set *foo*, with target CPU utilization set to `80%`
 and the number of replicas between 2 and 5.

content/en/docs/tutorials/kubernetes-basics/_index.html

@@ -41,7 +41,7 @@ card:
     <div class="row">
       <div class="col-md-9">
         <h2>What can Kubernetes do for you?</h2>
-        <p>With modern web services, users expect applications to be available 24/7, and developers expect to deploy new versions of those applications several times a day. Containerization helps package software to serve these goals, enabling applications to be released and updated in an easy and fast way without downtime. Kubernetes helps you make sure those containerized applications run where and when you want, and helps them find the resources and tools they need to work. Kubernetes is a production-ready, open source platform designed with Google's accumulated experience in container orchestration, combined with best-of-breed ideas from the community.</p>
+        <p>With modern web services, users expect applications to be available 24/7, and developers expect to deploy new versions of those applications several times a day. Containerization helps package software to serve these goals, enabling applications to be released and updated without downtime. Kubernetes helps you make sure those containerized applications run where and when you want, and helps them find the resources and tools they need to work. Kubernetes is a production-ready, open source platform designed with Google's accumulated experience in container orchestration, combined with best-of-breed ideas from the community.</p>
       </div>
     </div>
 

content/en/docs/tutorials/stateless-application/guestbook.md

@@ -272,7 +272,7 @@ If you deployed the `frontend-service.yaml` manifest with type: `LoadBalancer` y
 
 ## Scale the Web Frontend
 
-Scaling up or down is easy because your servers are defined as a Service that uses a Deployment controller.
+You can scale up or down as needed because your servers are defined as a Service that uses a Deployment controller.
 
 1. Run the following command to scale up the number of frontend Pods:
 
@@ -370,4 +370,3 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels
 * Use Kubernetes to create a blog using [Persistent Volumes for MySQL and Wordpress](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)
 * Read more about [connecting applications](/docs/concepts/services-networking/connect-applications-service/)
 * Read more about [Managing Resources](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)
-