Merge pull request kubernetes#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
-that makes scheduler customizations easy. 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
-scheduling "core" simple and maintainable. Refer to the [design proposal of the
+The scheduling framework is a pluggable architecture for the Kubernetes scheduler.
+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
+scheduling "core" lightweight 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
- - at least one other method for user authentication.
+- service account tokens for service accounts
+- 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
-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`.
+"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:
 
+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
-to turn up in a new cluster.
+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://".
 

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>`