Merge master into dev-1.21 to keep in sync

2021-02-05 14:03:33 -08:00
parent e260cf84c5 57648a901c
commit 0b69091aff
94 changed files with 1288 additions and 713 deletions
@@ -102,7 +102,7 @@ Other control loops can observe that reported data and take their own actions.
 In the thermostat example, if the room is very cold then a different controller
 might also turn on a frost protection heater. With Kubernetes clusters, the control
 plane indirectly works with IP address management tools, storage services,
-cloud provider APIS, and other services by
+cloud provider APIs, and other services by
 [extending Kubernetes](/docs/concepts/extend-kubernetes/) to implement that.

 ## Desired versus current state {#desired-vs-current}
@@ -11,9 +11,10 @@ weight: 10

 Kubernetes runs your workload by placing containers into Pods to run on _Nodes_.
 A node may be a virtual or physical machine, depending on the cluster. Each node
-contains the services necessary to run
-{{< glossary_tooltip text="Pods" term_id="pod" >}}, managed by the
-{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
+is managed by the
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}}
+and contains the services necessary to run
+{{< glossary_tooltip text="Pods" term_id="pod" >}}

 Typically you have several nodes in a cluster; in a learning or resource-limited
 environment, you might have just one.
@@ -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.
@@ -9,23 +9,22 @@ weight: 60

 <!-- overview -->

-Application logs can help you understand what is happening inside your application. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams.
+Application logs can help you understand what is happening inside your application. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism. Likewise, container engines are designed to support logging. The easiest and most adopted logging method for containerized applications is writing to standard output and standard error streams.

-However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. For example, if a container crashes, a pod is evicted, or a node dies, you'll usually still want to access your application's logs. As such, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_. Cluster-level logging requires a separate backend to store, analyze, and query logs. Kubernetes provides no native storage solution for log data, but you can integrate many existing logging solutions into your Kubernetes cluster.
+However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution.
+For example, you may want access your application's logs if a container crashes; a pod gets evicted; or a node dies.
+In a cluster, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level logging_.

 <!-- body -->

-Cluster-level logging architectures are described in assumption that
-a logging backend is present inside or outside of your cluster. If you're
-not interested in having cluster-level logging, you might still find
-the description of how logs are stored and handled on the node to be useful.
+Cluster-level logging architectures require a separate backend to store, analyze, and query logs. Kubernetes
+does not provide a native storage solution for log data. Instead, there are many logging solutions that
+integrate with Kubernetes. The following sections describe how to handle and store logs on nodes.

 ## Basic logging in Kubernetes

-In this section, you can see an example of basic logging in Kubernetes that
-outputs data to the standard output stream. This demonstration uses
-a pod specification with a container that writes some text to standard output
-once per second.
+This example uses a `Pod` specification with a container
+to write text to the standard output stream once per second.

 {{< codenew file="debug/counter-pod.yaml" >}}

@@ -34,8 +33,10 @@ To run this pod, use the following command:
 ```shell
 kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
 ```
+
 The output is:
-```
+
+```console
 pod/counter created
 ```

@@ -44,73 +45,73 @@ To fetch the logs, use the `kubectl logs` command, as follows:
 ```shell
 kubectl logs counter
 ```
+
 The output is:
-```
+
+```console
 0: Mon Jan  1 00:00:00 UTC 2001
 1: Mon Jan  1 00:00:01 UTC 2001
 2: Mon Jan  1 00:00:02 UTC 2001
 ...
 ```

-You can use `kubectl logs` to retrieve logs from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
+You can use `kubectl logs --previous` to retrieve logs from a previous instantiation of a container. If your pod has multiple containers, specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.

 ## Logging at the node level

 ![Node level logging](/images/docs/user-guide/logging/logging-node-level.png)

-Everything a containerized application writes to `stdout` and `stderr` is handled and redirected somewhere by a container engine. For example, the Docker container engine redirects those two streams to [a logging driver](https://docs.docker.com/engine/admin/logging/overview), which is configured in Kubernetes to write to a file in json format.
+A container engine handles and redirects any output generated to a containerized application's `stdout` and `stderr` streams.
+For example, the Docker container engine redirects those two streams to [a logging driver](https://docs.docker.com/engine/admin/logging/overview), which is configured in Kubernetes to write to a file in JSON format.

 {{< note >}}
-The Docker json logging driver treats each line as a separate message. When using the Docker logging driver, there is no direct support for multi-line messages. You need to handle multi-line messages at the logging agent level or higher.
+The Docker JSON logging driver treats each line as a separate message. When using the Docker logging driver, there is no direct support for multi-line messages. You need to handle multi-line messages at the logging agent level or higher.
 {{< /note >}}

 By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs.

 An important consideration in node-level logging is implementing log rotation,
 so that logs don't consume all available storage on the node. Kubernetes
-currently is not responsible for rotating logs, but rather a deployment tool
+is not responsible for rotating logs, but rather a deployment tool
 should set up a solution to address that.
 For example, in Kubernetes clusters, deployed by the `kube-up.sh` script,
 there is a [`logrotate`](https://linux.die.net/man/8/logrotate)
 tool configured to run each hour. You can also set up a container runtime to
-rotate application's logs automatically, for example by using Docker's `log-opt`.
-In the `kube-up.sh` script, the latter approach is used for COS image on GCP,
-and the former approach is used in any other environment. In both cases, by
-default rotation is configured to take place when log file exceeds 10MB.
+rotate an application's logs automatically.

 As an example, you can find detailed information about how `kube-up.sh` sets
 up logging for COS image on GCP in the corresponding
-[script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh).
+[`configure-helper` script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh).

 When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in
 the basic logging example, the kubelet on the node handles the request and
-reads directly from the log file, returning the contents in the response.
+reads directly from the log file. The kubelet returns the content of the log file.

 {{< note >}}
-Currently, if some external system has performed the rotation,
+If an external system has performed the rotation,
 only the contents of the latest log file will be available through
-`kubectl logs`. E.g. if there's a 10MB file, `logrotate` performs
-the rotation and there are two files, one 10MB in size and one empty,
-`kubectl logs` will return an empty response.
+`kubectl logs`. For example, if there's a 10MB file, `logrotate` performs
+the rotation and there are two files: one file that is 10MB in size and a second file that is empty.
+`kubectl logs` returns the latest log file which in this example is an empty response.
 {{< /note >}}

-[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
 ### System component logs

 There are two types of system components: those that run in a container and those
 that do not run in a container. For example:

 * The Kubernetes scheduler and kube-proxy run in a container.
-* The kubelet and container runtime, for example Docker, do not run in containers.
+* The kubelet and container runtime do not run in containers.

 On machines with systemd, the kubelet and container runtime write to journald. If
-systemd is not present, they write to `.log` files in the `/var/log` directory.
-System components inside containers always write to the `/var/log` directory,
-bypassing the default logging mechanism. They use the [klog](https://github.com/kubernetes/klog)
+systemd is not present, the kubelet and container runtime write to `.log` files
+in the `/var/log` directory. System components inside containers always write
+to the `/var/log` directory, bypassing the default logging mechanism.
+They use the [`klog`](https://github.com/kubernetes/klog)
 logging library. You can find the conventions for logging severity for those
 components in the [development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).

-Similarly to the container logs, system component logs in the `/var/log`
+Similar to the container logs, system component logs in the `/var/log`
 directory should be rotated. In Kubernetes clusters brought up by
 the `kube-up.sh` script, those logs are configured to be rotated by
 the `logrotate` tool daily or once the size exceeds 100MB.
@@ -129,13 +130,14 @@ While Kubernetes does not provide a native solution for cluster-level logging, t

 You can implement cluster-level logging by including a _node-level logging agent_ on each node. The logging agent is a dedicated tool that exposes logs or pushes logs to a backend. Commonly, the logging agent is a container that has access to a directory with log files from all of the application containers on that node.

-Because the logging agent must run on every node, it's common to implement it as either a DaemonSet replica, a manifest pod, or a dedicated native process on the node. However the latter two approaches are deprecated and highly discouraged.
+Because the logging agent must run on every node, it is recommended to run the agent
+as a `DaemonSet`.

-Using a node-level logging agent is the most common and encouraged approach for a Kubernetes cluster, because it creates only one agent per node, and it doesn't require any changes to the applications running on the node. However, node-level logging _only works for applications' standard output and standard error_.
+Node-level logging creates only one agent per node and doesn't require any changes to the applications running on the node.

-Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/tasks/debug-application-cluster/logging-stackdriver/) for use with Google Cloud Platform, and [Elasticsearch](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/). You can find more information and instructions in the dedicated documents. Both use [fluentd](https://www.fluentd.org/) with custom configuration as an agent on the node.
+Containers write stdout and stderr, but with no agreed format. A node-level agent collects these logs and forwards them for aggregation.

-### Using a sidecar container with the logging agent
+### Using a sidecar container with the logging agent {#sidecar-container-with-logging-agent}

 You can use a sidecar container in one of the following ways:

@@ -146,28 +148,27 @@ You can use a sidecar container in one of the following ways:

 ![Sidecar container with a streaming container](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png)

-By having your sidecar containers stream to their own `stdout` and `stderr`
+By having your sidecar containers write to their own `stdout` and `stderr`
 streams, you can take advantage of the kubelet and the logging agent that
 already run on each node. The sidecar containers read logs from a file, a socket,
-or the journald. Each individual sidecar container prints log to its own `stdout`
-or `stderr` stream.
+or journald. Each sidecar container prints a log to its own `stdout` or `stderr` stream.

 This approach allows you to separate several log streams from different
 parts of your application, some of which can lack support
 for writing to `stdout` or `stderr`. The logic behind redirecting logs
-is minimal, so it's hardly a significant overhead. Additionally, because
+is minimal, so it's not a significant overhead. Additionally, because
 `stdout` and `stderr` are handled by the kubelet, you can use built-in tools
 like `kubectl logs`.

-Consider the following example. A pod runs a single container, and the container
-writes to two different log files, using two different formats. Here's a
+For example, a pod runs a single container, and the container
+writes to two different log files using two different formats. Here's a
 configuration file for the Pod:

 {{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}

-It would be a mess to have log entries of different formats in the same log
+It is not recommended to write log entries with different formats to the same log
 stream, even if you managed to redirect both components to the `stdout` stream of
-the container. Instead, you could introduce two sidecar containers. Each sidecar
+the container. Instead, you can create two sidecar containers. Each sidecar
 container could tail a particular log file from a shared volume and then redirect
 the logs to its own `stdout` stream.

@@ -181,7 +182,10 @@ running the following commands:
 ```shell
 kubectl logs counter count-log-1
 ```
-```
+
+The output is:
+
+```console
 0: Mon Jan  1 00:00:00 UTC 2001
 1: Mon Jan  1 00:00:01 UTC 2001
 2: Mon Jan  1 00:00:02 UTC 2001
@@ -191,7 +195,10 @@ kubectl logs counter count-log-1
 ```shell
 kubectl logs counter count-log-2
 ```
-```
+
+The output is:
+
+```console
 Mon Jan  1 00:00:00 UTC 2001 INFO 0
 Mon Jan  1 00:00:01 UTC 2001 INFO 1
 Mon Jan  1 00:00:02 UTC 2001 INFO 2
@@ -202,16 +209,15 @@ The node-level agent installed in your cluster picks up those log streams
 automatically without any further configuration. If you like, you can configure
 the agent to parse log lines depending on the source container.

-Note, that despite low CPU and memory usage (order of couple of millicores
+Note, that despite low CPU and memory usage (order of a couple of millicores
 for cpu and order of several megabytes for memory), writing logs to a file and
 then streaming them to `stdout` can double disk usage. If you have
-an application that writes to a single file, it's generally better to set
-`/dev/stdout` as destination rather than implementing the streaming sidecar
+an application that writes to a single file, it's recommended to set
+`/dev/stdout` as the destination rather than implement the streaming sidecar
 container approach.

 Sidecar containers can also be used to rotate log files that cannot be
-rotated by the application itself. An example
-of this approach is a small container running logrotate periodically.
+rotated by the application itself. An example of this approach is a small container running `logrotate` periodically.
 However, it's recommended to use `stdout` and `stderr` directly and leave rotation
 and retention policies to the kubelet.

@@ -226,21 +232,17 @@ configured specifically to run with your application.
 {{< note >}}
 Using a logging agent in a sidecar container can lead
 to significant resource consumption. Moreover, you won't be able to access
-those logs using `kubectl logs` command, because they are not controlled
+those logs using `kubectl logs` because they are not controlled
 by the kubelet.
 {{< /note >}}

-As an example, you could use [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),
-which uses fluentd as a logging agent. Here are two configuration files that
-you can use to implement this approach. The first file contains
-a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd.
+Here are two configuration files that you can use to implement a sidecar container with a logging agent. The first file contains
+a [`ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd.

 {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}

 {{< note >}}
-The configuration of fluentd is beyond the scope of this article. For
-information about configuring fluentd, see the
-[official fluentd documentation](https://docs.fluentd.org/).
+For information about configuring fluentd, see the [fluentd documentation](https://docs.fluentd.org/).
 {{< /note >}}

 The second file describes a pod that has a sidecar container running fluentd.
@@ -248,18 +250,10 @@ The pod mounts a volume where fluentd can pick up its configuration data.

 {{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}

-After some time you can find log messages in the Stackdriver interface.
-
-Remember, that this is just an example and you can actually replace fluentd
-with any logging agent, reading from any source inside an application
-container.
+In the sample configurations, you can replace fluentd with any logging agent, reading from any source inside an application container.

 ### Exposing logs directly from the application

 ![Exposing logs directly from the application](/images/docs/user-guide/logging/logging-from-application.png)

-You can implement cluster-level logging by exposing or pushing logs directly from
-every application; however, the implementation for such a logging mechanism
-is outside the scope of Kubernetes.
-
-
+Cluster-logging that exposes or pushes logs directly from every application is outside the scope of Kubernetes.
@@ -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,10 +87,11 @@ 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)
+kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service | xargs -i kubectl get {}
 ```

 ```shell
@@ -301,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
@@ -314,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
 ```
@@ -328,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
@@ -338,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
 ```
@@ -411,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
@@ -427,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
 ```
@@ -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"
 ```

@@ -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.

@@ -116,7 +116,7 @@ In this case, `0` means we have just created an empty Secret.
 A `kubernetes.io/service-account-token` type of Secret is used to store a
 token that identifies a service account. When using this Secret type, you need
 to ensure that the `kubernetes.io/service-account.name` annotation is set to an
-existing service account name. An Kubernetes controller fills in some other
+existing service account name. A Kubernetes controller fills in some other
 fields such as the `kubernetes.io/service-account.uid` annotation and the
 `token` key in the `data` field set to actual token content.

@@ -801,11 +801,6 @@ field set to that of the service account.
 See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
 for a detailed explanation of that process.

-### Automatic mounting of manually created Secrets
-
-Manually created secrets (for example, one containing a token for accessing a GitHub account)
-can be automatically attached to pods based on their service account.
-
 ## Details

 ### Restrictions
@@ -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.
@@ -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

@@ -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:
@@ -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.

@@ -74,7 +74,7 @@ An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but

 If your cluster has dual-stack enabled, you can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both. 

-The address family of a Service defaults to the address family of the first service cluster IP range (configured via the `--service-cluster-ip-range` flag to the kube-controller-manager).
+The address family of a Service defaults to the address family of the first service cluster IP range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver).

 When you define a Service you can optionally configure it as dual stack. To specify the behavior you want, you
 set the `.spec.ipFamilyPolicy` field to one of the following values:
@@ -31,14 +31,15 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
 * The [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme) works with
  Citrix Application Delivery Controller.
 * [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller.
+* [EnRoute](https://getenroute.io/) is an [Envoy](https://www.envoyproxy.io) based API gateway that can run as an ingress controller.
 * F5 BIG-IP [Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)
  lets you use an Ingress to configure F5 BIG-IP virtual servers.
 * [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io),
  which offers API gateway functionality.
 * [HAProxy Ingress](https://haproxy-ingress.github.io/) is an ingress controller for
-  [HAProxy](http://www.haproxy.org/#desc).
+  [HAProxy](https://www.haproxy.org/#desc).
 * The [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress#readme)
-  is also an ingress controller for [HAProxy](http://www.haproxy.org/#desc).
+  is also an ingress controller for [HAProxy](https://www.haproxy.org/#desc).
 * [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)
  is an [Istio](https://istio.io/) based ingress controller.
 * The [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme)
@@ -49,7 +50,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
 * The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an
  ingress controller for the [Traefik](https://traefik.io/traefik/) proxy.
 * [Voyager](https://appscode.com/products/voyager) is an ingress controller for
-  [HAProxy](http://www.haproxy.org/#desc).
+  [HAProxy](https://www.haproxy.org/#desc).

 ## Using multiple Ingress controllers

@@ -151,9 +151,9 @@ spec:
      targetPort: 9376
 ```

-Because this Service has no selector, the corresponding Endpoint object is not
+Because this Service has no selector, the corresponding Endpoints object is not
 created automatically. You can manually map the Service to the network address and port
-where it's running, by adding an Endpoint object manually:
+where it's running, by adding an Endpoints object manually:

 ```yaml
 apiVersion: v1
@@ -629,6 +629,11 @@ spec:

 PersistentVolumes binds are exclusive, and since PersistentVolumeClaims are namespaced objects, mounting claims with "Many" modes (`ROX`, `RWX`) is only possible within one namespace.

+### PersistentVolumes typed `hostPath`
+
+A `hostPath` PersistentVolume uses a file or directory on the Node to emulate network-attached storage.
+See [an example of `hostPath` typed volume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
+
 ## Raw Block Volume Support

 {{< feature-state for_k8s_version="v1.18" state="stable" >}}
@@ -210,8 +210,8 @@ spec:

 The `CSIMigration` feature for Cinder, when enabled, redirects all plugin operations
 from the existing in-tree plugin to the `cinder.csi.openstack.org` Container
-Storage Interface (CSI) Driver. In order to use this feature, the [Openstack Cinder CSI
-Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md)
+Storage Interface (CSI) Driver. In order to use this feature, the [OpenStack Cinder CSI
+Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)
 must be installed on the cluster and the `CSIMigration` and `CSIMigrationOpenStack`
 beta features must be enabled.

@@ -147,8 +147,8 @@ the related features.
 | ---------------------------------------- | ---------- | ------- | ----------- |
 | `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
 | `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
-| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | |
-| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | |
+| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | DaemonSet pods tolerate disk-pressure attributes by default scheduler. |
+| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | DaemonSet pods tolerate memory-pressure attributes by default scheduler. |
 | `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSet pods tolerate unschedulable attributes by default scheduler. |
 | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |

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

@@ -78,7 +78,7 @@ sharing](/docs/tasks/configure-pod-container/share-process-namespace/) so
 you can view processes in other containers.

 See [Debugging with Ephemeral Debug Container](
-/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)
+/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)
 for examples of troubleshooting using ephemeral containers.

 ## Ephemeral containers API
@@ -462,8 +462,6 @@ and the [example of Limit Range](/docs/tasks/administer-cluster/manage-resources

 ### MutatingAdmissionWebhook {#mutatingadmissionwebhook}

-{{< feature-state for_k8s_version="v1.13" state="beta" >}}
-
 This admission controller calls any mutating webhooks which match the request. Matching
 webhooks are called in serial; each one may modify the object if it desires.

@@ -474,7 +472,7 @@ If a webhook called by this has side effects (for example, decrementing quota) i
 webhooks or validating admission controllers will permit the request to finish.

 If you disable the MutatingAdmissionWebhook, you must also disable the
-`MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1`
+`MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1`
 group/version via the `--runtime-config` flag (both are on by default in
 versions >= 1.9).

@@ -486,8 +484,6 @@ versions >= 1.9).
   different when read back.
   * Setting originally unset fields is less likely to cause problems than
     overwriting fields set in the original request. Avoid doing the latter.
- * This is a beta feature. Future versions of Kubernetes may restrict the types of
-   mutations these webhooks can make.
 * Future changes to control loops for built-in resources or third-party resources
   may break webhooks that work well today. Even when the webhook installation API
   is finalized, not all possible webhook behaviors will be guaranteed to be supported
@@ -766,8 +762,6 @@ This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}}

 ### ValidatingAdmissionWebhook {#validatingadmissionwebhook}

-{{< feature-state for_k8s_version="v1.13" state="beta" >}}
-
 This admission controller calls any validating webhooks which match the request. Matching
 webhooks are called in parallel; if any of them rejects the request, the request
 fails. This admission controller only runs in the validation phase; the webhooks it calls may not
@@ -778,7 +772,7 @@ If a webhook called by this has side effects (for example, decrementing quota) i
 webhooks or other validating admission controllers will permit the request to finish.

 If you disable the ValidatingAdmissionWebhook, you must also disable the
-`ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1`
+`ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1`
 group/version via the `--runtime-config` flag (both are on by default in
 versions 1.9 and later).

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

@@ -1004,14 +1002,12 @@ RFC3339 timestamp. Presence or absence of an expiry has the following impact:
  }
 }
 ```
-
-The plugin can optionally be called with an environment variable, `KUBERNETES_EXEC_INFO`,
-that contains information about the cluster for which this plugin is obtaining
-credentials. This information can be used to perform cluster-specific credential
-acquisition logic. In order to enable this behavior, the `provideClusterInfo` field must
-be set on the exec user field in the
-[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Here is an
-example of the aforementioned `KUBERNETES_EXEC_INFO` environment variable.
+To enable the exec plugin to obtain cluster-specific information, set `provideClusterInfo` on the `user.exec`
+field in the [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/).
+The plugin will then be supplied with an environment variable, `KUBERNETES_EXEC_INFO`.
+Information from this environment variable can be used to perform cluster-specific
+credential acquisition logic.
+The following `ExecCredential` manifest describes a cluster information sample.

 ```json
 {
@@ -104,6 +104,9 @@ a given action, and works regardless of the authorization mode used.
 ```bash
 kubectl auth can-i create deployments --namespace dev
 ```
+
+The output is similar to this:
+
 ```
 yes
 ```
@@ -111,6 +114,9 @@ yes
 ```shell
 kubectl auth can-i create deployments --namespace prod
 ```
+
+The output is similar to this:
+
 ```
 no
 ```
@@ -121,6 +127,9 @@ to determine what action other users can perform.
 ```bash
 kubectl auth can-i list secrets --namespace dev --as dave
 ```
+
+The output is similar to this:
+
 ```
 no
 ```
@@ -150,7 +159,7 @@ EOF
 ```

 The generated `SelfSubjectAccessReview` is:
-```
+```yaml
 apiVersion: authorization.k8s.io/v1
 kind: SelfSubjectAccessReview
 metadata:
@@ -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://".

@@ -2,7 +2,7 @@
 title: API Group
 id: api-group
 date: 2019-09-02
-full_link: /docs/concepts/overview/kubernetes-api/#api-groups
+full_link: /docs/concepts/overview/kubernetes-api/#api-groups-and-versioning
 short_description: >
  A set of related paths in the Kubernetes API.

@@ -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).
-
@@ -195,7 +195,7 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"

 # Output decoded secrets without external tools
-kubectl get secret ${secret_name} -o go-template='{{range $k,$v := .data}}{{$k}}={{$v|base64decode}}{{"\n"}}{{end}}'
+kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'

 # List all Secrets currently in use by a pod
 kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
@@ -337,7 +337,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule

 ### Resource types

-List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
+List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):

 ```bash
 kubectl api-resources
@@ -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)
@@ -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
@@ -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
@@ -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>`
@@ -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:**

@@ -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
-easy to run a single-node Kubernetes cluster locally on your workstation for
+[`minikube`](https://minikube.sigs.k8s.io/docs/) is a tool that
+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/)
-
@@ -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.

@@ -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`
@@ -8,7 +8,7 @@ weight: 30

 <!-- overview -->

-<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Creating a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
+<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Using `kubeadm`, you can create a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
 `kubeadm` also supports other cluster
 lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades.

@@ -236,8 +236,8 @@ curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_
 Define the directory to download command files  

 {{< note >}}
-The DOWNLOAD_DIR variable must be set to a writable directory.
-If you are running Flatcar Container Linux, set DOWNLOAD_DIR=/opt/bin.
+The `DOWNLOAD_DIR` variable must be set to a writable directory.
+If you are running Flatcar Container Linux, set `DOWNLOAD_DIR=/opt/bin`.
 {{< /note >}}

 ```bash
@@ -363,7 +363,7 @@ kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule-

 ## `/usr` is mounted read-only on nodes {#usr-mounted-read-only}

-On Linux distributions such as Fedora CoreOS, the directory `/usr` is mounted as a read-only filesystem.
+On Linux distributions such as Fedora CoreOS or Flatcar Container Linux, the directory `/usr` is mounted as a read-only filesystem.
 For [flex-volume support](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md),
 Kubernetes components like the kubelet and kube-controller-manager use the default path of
 `/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`, yet the flex-volume directory _must be writeable_
@@ -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).

@@ -92,7 +92,7 @@ We expect this implementation to progress from alpha to beta and GA in coming re

 ### go1.15.5

-go1.15.5 has been integrated to Kubernets project as of this release, [including other infrastructure related updates on this effort](https://github.com/kubernetes/kubernetes/pull/95776).
+go1.15.5 has been integrated to Kubernetes project as of this release, [including other infrastructure related updates on this effort](https://github.com/kubernetes/kubernetes/pull/95776).

 ### CSI Volume Snapshot graduates to General Availability

@@ -190,7 +190,7 @@ Currently, cadvisor_stats_provider provides AcceleratorStats but cri_stats_provi
  PodSubnet validates against the corresponding cluster "--node-cidr-mask-size" of the kube-controller-manager, it fail if the values are not compatible.
  kubeadm no longer sets the node-mask automatically on IPv6 deployments, you must check that your IPv6 service subnet mask is compatible with the default node mask /64 or set it accordenly. 
  Previously, for IPv6, if the podSubnet had a mask lower than /112, kubeadm calculated a node-mask to be multiple of eight and splitting the available bits to maximise the number used for nodes. ([#95723](https://github.com/kubernetes/kubernetes/pull/95723), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle]
- The deprecated flag --experimental-kustomize is now removed from kubeadm commands. Use --experimental-patches instead, which was introduced in 1.19. Migration infromation available in --help description for --exprimental-patches. ([#94871](https://github.com/kubernetes/kubernetes/pull/94871), [@neolit123](https://github.com/neolit123))
+- The deprecated flag --experimental-kustomize is now removed from kubeadm commands. Use --experimental-patches instead, which was introduced in 1.19. Migration information available in --help description for --experimental-patches. ([#94871](https://github.com/kubernetes/kubernetes/pull/94871), [@neolit123](https://github.com/neolit123))
 - Windows hyper-v container featuregate is deprecated in 1.20 and will be removed in 1.21 ([#95505](https://github.com/kubernetes/kubernetes/pull/95505), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows]
 - The kube-apiserver ability to serve on an insecure port, deprecated since v1.10, has been removed. The insecure address flags `--address` and `--insecure-bind-address` have no effect in kube-apiserver and will be removed in v1.24. The insecure port flags `--port` and `--insecure-port` may only be set to 0 and will be removed in v1.24. ([#95856](https://github.com/kubernetes/kubernetes/pull/95856), [@knight42](https://github.com/knight42), [SIG API Machinery, Node, Testing])
 - Add dual-stack Services (alpha).  This is a BREAKING CHANGE to an alpha API.
@@ -2138,4 +2138,4 @@ filename | sha512 hash
 - github.com/godbus/dbus: [ade71ed](https://github.com/godbus/dbus/tree/ade71ed)
 - github.com/xlab/handysort: [fb3537e](https://github.com/xlab/handysort/tree/fb3537e)
 - sigs.k8s.io/structured-merge-diff/v3: v3.0.0
- vbom.ml/util: db5cfe1
+- vbom.ml/util: db5cfe1
@@ -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`:

@@ -72,7 +72,7 @@ Once you have a Linux-based Kubernetes control-plane node you are ready to choos
          "Network": "10.244.0.0/16",
          "Backend": {
            "Type": "vxlan",
-            "VNI" : 4096,
+            "VNI": 4096,
            "Port": 4789
          }
        }
@@ -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/),
@@ -117,9 +117,10 @@ The `kubelet` has the following default hard eviction threshold:

 * `memory.available<100Mi`
 * `nodefs.available<10%`
-* `nodefs.inodesFree<5%`
 * `imagefs.available<15%`

+On a Linux node, the default value also includes `nodefs.inodesFree<5%`.
+
 ### Eviction Monitoring Interval

 The `kubelet` evaluates eviction thresholds per its configured housekeeping interval.
@@ -140,6 +141,7 @@ The following node conditions are defined that correspond to the specified evict
 |-------------------|---------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------|
 | `MemoryPressure`  | `memory.available`                                                                    | Available memory on the node has satisfied an eviction threshold                                                             |
 | `DiskPressure`    | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, or `imagefs.inodesFree` | Available disk space and inodes on either the node's root filesystem or image filesystem has satisfied an eviction threshold |
+| `PIDPressure`     | `pid.available`                                                                       | Available processes identifiers on the (Linux) node has fallen below an eviction threshold                                   |                                                         |

 The `kubelet` continues to report node status updates at the frequency specified by
 `--node-status-update-frequency` which defaults to `10s`.
@@ -23,7 +23,7 @@ dynamically, you need a strong understanding of how that change will affect your
 cluster's behavior. Always carefully test configuration changes on a small set
 of nodes before rolling them out cluster-wide. Advice on configuring specific
 fields is available in the inline `KubeletConfiguration`
-[type documentation](https://github.com/kubernetes/kubernetes/blob/release-1.11/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go).
+[type documentation (for v1.20)](https://github.com/kubernetes/kubernetes/blob/release-1.20/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
 {{< /warning >}}


@@ -187,7 +187,7 @@ Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`.
 To delete the Secret you have just created:

 ```shell
-kubectl delete secret db-user-pass
+kubectl delete secret mysecret
 ```

 ## {{% heading "whatsnext" %}}
@@ -22,6 +22,7 @@ The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Po
 on the Kubernetes API server for each static Pod.
 This means that the Pods running on a node are visible on the API server,
 but cannot be controlled from there.
+The Pod names will suffixed with the node hostname with a leading hyphen

 {{< note >}}
 If you are running clustered Kubernetes and are using static
@@ -237,4 +238,3 @@ CONTAINER ID        IMAGE         COMMAND                CREATED           ...
 e7a62e3427f1        nginx:latest  "nginx -g 'daemon of   27 seconds ago
 ```

-
@@ -1,94 +0,0 @@
---
-reviewers:
- piosz
- x13n
-content_type: concept
-title: Events in Stackdriver
---
-
-<!-- overview -->
-
-Kubernetes events are objects that provide insight into what is happening
-inside a cluster, such as what decisions were made by scheduler or why some
-pods were evicted from the node. You can read more about using events
-for debugging your application in the [Application Introspection and Debugging
-](/docs/tasks/debug-application-cluster/debug-application-introspection/)
-section.
-
-Since events are API objects, they are stored in the apiserver on master. To
-avoid filling up master's disk, a retention policy is enforced: events are
-removed one hour after the last occurrence. To provide longer history
-and aggregation capabilities, a third party solution should be installed
-to capture events.
-
-This article describes a solution that exports Kubernetes events to
-Stackdriver Logging, where they can be processed and analyzed.
-
-{{< note >}}
-It is not guaranteed that all events happening in a cluster will be
-exported to Stackdriver. One possible scenario when events will not be
-exported is when event exporter is not running (e.g. during restart or
-upgrade). In most cases it's fine to use events for purposes like setting up
-[metrics](https://cloud.google.com/logging/docs/logs-based-metrics/) and [alerts](https://cloud.google.com/logging/docs/logs-based-metrics/charts-and-alerts), but you should be aware
-of the potential inaccuracy.
-{{< /note >}}
-
-
-
-
-
-<!-- body -->
-
-## Deployment
-
-### Google Kubernetes Engine
-
-In Google Kubernetes Engine, if cloud logging is enabled, event exporter
-is deployed by default to the clusters with master running version 1.7 and
-higher. To prevent disturbing your workloads, event exporter does not have
-resources set and is in the best effort QOS class, which means that it will
-be the first to be killed in the case of resource starvation. If you want
-your events to be exported, make sure you have enough resources to facilitate
-the event exporter pod. This may vary depending on the workload, but on
-average, approximately 100Mb RAM and 100m CPU is needed.
-
-### Deploying to the Existing Cluster
-
-Deploy event exporter to your cluster using the following command:
-
-```shell
-kubectl apply -f https://k8s.io/examples/debug/event-exporter.yaml
-```
-
-Since event exporter accesses the Kubernetes API, it requires permissions to
-do so. The following deployment is configured to work with RBAC
-authorization. It sets up a service account and a cluster role binding
-to allow event exporter to read events. To make sure that event exporter
-pod will not be evicted from the node, you can additionally set up resource
-requests. As mentioned earlier, 100Mb RAM and 100m CPU should be enough.
-
-{{< codenew file="debug/event-exporter.yaml" >}}
-
-## User Guide
-
-Events are exported to the `GKE Cluster` resource in Stackdriver Logging.
-You can find them by selecting an appropriate option from a drop-down menu
-of available resources:
-
-<img src="/images/docs/stackdriver-event-exporter-resource.png" alt="Events location in the Stackdriver Logging interface" width="500">
-
-You can filter based on the event object fields using Stackdriver Logging
-[filtering mechanism](https://cloud.google.com/logging/docs/view/advanced_filters).
-For example, the following query will show events from the scheduler
-about pods from deployment `nginx-deployment`:
-
-```
-resource.type="gke_cluster"
-jsonPayload.kind="Event"
-jsonPayload.source.component="default-scheduler"
-jsonPayload.involvedObject.name:"nginx-deployment"
-```
-
-{{< figure src="/images/docs/stackdriver-event-exporter-filter.png" alt="Filtered events in the Stackdriver Logging interface" width="500" >}}
-
-
@@ -1,126 +0,0 @@
---
-reviewers:
- piosz
- x13n
-content_type: concept
-title: Logging Using Elasticsearch and Kibana
---
-
-<!-- overview -->
-
-On the Google Compute Engine (GCE) platform, the default logging support targets
-[Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail
-in the [Logging With Stackdriver Logging](/docs/tasks/debug-application-cluster/logging-stackdriver).
-
-This article describes how to set up a cluster to ingest logs into
-[Elasticsearch](https://www.elastic.co/products/elasticsearch) and view
-them using [Kibana](https://www.elastic.co/products/kibana), as an alternative to
-Stackdriver Logging when running on GCE. 
-
-{{< note >}}
-You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
-{{< /note >}}
-
-
-
-<!-- body -->
-
-To use Elasticsearch and Kibana for cluster logging, you should set the
-following environment variable as shown below when creating your cluster with
-kube-up.sh:
-
-```shell
-KUBE_LOGGING_DESTINATION=elasticsearch
-```
-
-You should also ensure that `KUBE_ENABLE_NODE_LOGGING=true` (which is the default for the GCE platform).
-
-Now, when you create a cluster, a message will indicate that the Fluentd log
-collection daemons that run on each node will target Elasticsearch:
-
-```shell
-cluster/kube-up.sh
-```
-```
-...
-Project: kubernetes-satnam
-Zone: us-central1-b
-... calling kube-up
-Project: kubernetes-satnam
-Zone: us-central1-b
-+++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel
-+++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d)
-+++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0)
-Looking for already existing resources
-Starting master and configuring firewalls
-Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd].
-NAME                 ZONE          SIZE_GB TYPE   STATUS
-kubernetes-master-pd us-central1-b 20      pd-ssd READY
-Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip].
-+++ Logging using Fluentd to elasticsearch
-```
-
-The per-node Fluentd pods, the Elasticsearch pods, and the Kibana pods should
-all be running in the kube-system namespace soon after the cluster comes to
-life.
-
-```shell
-kubectl get pods --namespace=kube-system
-```
-```
-NAME                                           READY     STATUS    RESTARTS   AGE
-elasticsearch-logging-v1-78nog                 1/1       Running   0          2h
-elasticsearch-logging-v1-nj2nb                 1/1       Running   0          2h
-fluentd-elasticsearch-kubernetes-node-5oq0     1/1       Running   0          2h
-fluentd-elasticsearch-kubernetes-node-6896     1/1       Running   0          2h
-fluentd-elasticsearch-kubernetes-node-l1ds     1/1       Running   0          2h
-fluentd-elasticsearch-kubernetes-node-lz9j     1/1       Running   0          2h
-kibana-logging-v1-bhpo8                        1/1       Running   0          2h
-kube-dns-v3-7r1l9                              3/3       Running   0          2h
-monitoring-heapster-v4-yl332                   1/1       Running   1          2h
-monitoring-influx-grafana-v1-o79xf             2/2       Running   0          2h
-```
-
-The `fluentd-elasticsearch` pods gather logs from each node and send them to
-the `elasticsearch-logging` pods, which are part of a
-[service](/docs/concepts/services-networking/service/) named `elasticsearch-logging`. These
-Elasticsearch pods store the logs and expose them via a REST API.
-The `kibana-logging` pod provides a web UI for reading the logs stored in
-Elasticsearch, and is part of a service named `kibana-logging`.
-
-The Elasticsearch and Kibana services are both in the `kube-system` namespace
-and are not directly exposed via a publicly reachable IP address. To reach them,
-follow the instructions for
-[Accessing services running in a cluster](/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster).
-
-If you try accessing the `elasticsearch-logging` service in your browser, you'll
-see a status page that looks something like this:
-
-![Elasticsearch Status](/images/docs/es-browser.png)
-
-You can now type Elasticsearch queries directly into the browser, if you'd
-like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)
-for more details on how to do so.
-
-Alternatively, you can view your cluster's logs using Kibana (again using the
-[instructions for accessing a service running in the cluster](/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)).
-The first time you visit the Kibana URL you will be presented with a page that
-asks you to configure your view of the ingested logs. Select the option for
-timeseries values and select `@timestamp`. On the following page select the
-`Discover` tab and then you should be able to see the ingested logs.
-You can set the refresh interval to 5 seconds to have the logs
-regularly refreshed.
-
-Here is a typical view of ingested logs from the Kibana viewer:
-
-![Kibana logs](/images/docs/kibana-logs.png)
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-Kibana opens up all sorts of powerful options for exploring your logs! For some
-ideas on how to dig into it, check out [Kibana's documentation](https://www.elastic.co/guide/en/kibana/current/discover.html).
-
-
@@ -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
-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://".

@@ -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.
@@ -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.
@@ -221,9 +221,9 @@ the global HPA settings exposed as flags for the `kube-controller-manager` compo
 Starting from v1.12, a new algorithmic update removes the need for the
 upscale delay.

- `--horizontal-pod-autoscaler-downscale-stabilization`: The value for this option is a
-  duration that specifies how long the autoscaler has to wait before another
-  downscale operation can be performed after the current one has completed.
+- `--horizontal-pod-autoscaler-downscale-stabilization`: Specifies the duration of the
+  downscale stabilization time window. Horizontal Pod Autoscaler remembers
+  the historical recommended sizes and only acts on the largest size within this time window.
  The default value is 5 minutes (`5m0s`).

 {{< note >}}
@@ -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>

@@ -552,7 +552,7 @@ In another terminal, watch the Pods in the StatefulSet:
 ```shell
 kubectl get pod -l app=nginx -w
 ```
-The output is simular to:
+The output is similar to:
 ```
 NAME      READY     STATUS    RESTARTS   AGE
 web-0     1/1       Running   0          7m
@@ -21,39 +21,37 @@ and [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affini
 ## {{% heading "prerequisites" %}}

 Before starting this tutorial, you should be familiar with the following
-Kubernetes concepts.
+Kubernetes concepts:

-   [Pods](/docs/concepts/workloads/pods/)
-   [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
-   [Headless Services](/docs/concepts/services-networking/service/#headless-services)
-   [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
-   [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
-   [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
-   [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)
-   [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
-   [kubectl CLI](/docs/reference/kubectl/kubectl/)
+- [Pods](/docs/concepts/workloads/pods/)
+- [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
+- [Headless Services](/docs/concepts/services-networking/service/#headless-services)
+- [PersistentVolumes](/docs/concepts/storage/volumes/)
+- [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
+- [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
+- [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)
+- [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
+- [kubectl CLI](/docs/reference/kubectl/kubectl/)

-You will require a cluster with at least four nodes, and each node requires at least 2 CPUs and 4 GiB of memory. In this tutorial you will cordon and drain the cluster's nodes. **This means that the cluster will terminate and evict all Pods on its nodes, and the nodes will temporarily become unschedulable.** You should use a dedicated cluster for this tutorial, or you should ensure that the disruption you cause will not interfere with other tenants.
+You must have a cluster with at least four nodes, and each node requires at least 2 CPUs and 4 GiB of memory. In this tutorial you will cordon and drain the cluster's nodes. **This means that the cluster will terminate and evict all Pods on its nodes, and the nodes will temporarily become unschedulable.** You should use a dedicated cluster for this tutorial, or you should ensure that the disruption you cause will not interfere with other tenants.

 This tutorial assumes that you have configured your cluster to dynamically provision
 PersistentVolumes. If your cluster is not configured to do so, you
 will have to manually provision three 20 GiB volumes before starting this
 tutorial.

-
 ## {{% heading "objectives" %}}

 After this tutorial, you will know the following.

-   How to deploy a ZooKeeper ensemble using StatefulSet.
-   How to consistently configure the ensemble.
-   How to spread the deployment of ZooKeeper servers in the ensemble.
-   How to use PodDisruptionBudgets to ensure service availability during planned maintenance.
-
+- How to deploy a ZooKeeper ensemble using StatefulSet.
+- How to consistently configure the ensemble.
+- How to spread the deployment of ZooKeeper servers in the ensemble.
+- How to use PodDisruptionBudgets to ensure service availability during planned maintenance.

 <!-- lessoncontent -->

-### ZooKeeper Basics
+### ZooKeeper

 [Apache ZooKeeper](https://zookeeper.apache.org/doc/current/) is a
 distributed, open-source coordination service for distributed applications.
@@ -68,7 +66,7 @@ The ensemble uses the Zab protocol to elect a leader, and the ensemble cannot wr

 ZooKeeper servers keep their entire state machine in memory, and write every mutation to a durable WAL (Write Ahead Log) on storage media. When a server crashes, it can recover its previous state by replaying the WAL. To prevent the WAL from growing without bound, ZooKeeper servers will periodically snapshot them in memory state to storage media. These snapshots can be loaded directly into memory, and all WAL entries that preceded the snapshot may be discarded.

-## Creating a ZooKeeper Ensemble
+## Creating a ZooKeeper ensemble

 The manifest below contains a
 [Headless Service](/docs/concepts/services-networking/service/#headless-services),
@@ -127,7 +125,7 @@ zk-2      1/1       Running   0         40s
 The StatefulSet controller creates three Pods, and each Pod has a container with
 a [ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) server.

-### Facilitating Leader Election
+### Facilitating leader election

 Because there is no terminating algorithm for electing a leader in an anonymous network, Zab requires explicit membership configuration to perform leader election. Each server in the ensemble needs to have a unique identifier, all servers need to know the global set of identifiers, and each identifier needs to be associated with a network address.

@@ -211,7 +209,7 @@ server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888
 server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888
 ```

-### Achieving Consensus
+### Achieving consensus

 Consensus protocols require that the identifiers of each participant be unique. No two participants in the Zab protocol should claim the same unique identifier. This is necessary to allow the processes in the system to agree on which processes have committed which data. If two Pods are launched with the same ordinal, two ZooKeeper servers would both identify themselves as the same server.

@@ -260,7 +258,7 @@ server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888

 When the servers use the Zab protocol to attempt to commit a value, they will either achieve consensus and commit the value (if leader election has succeeded and at least two of the Pods are Running and Ready), or they will fail to do so (if either of the conditions are not met). No state will arise where one server acknowledges a write on behalf of another.

-### Sanity Testing the Ensemble
+### Sanity testing the ensemble

 The most basic sanity test is to write data to one ZooKeeper server and
 to read the data from another.
@@ -270,6 +268,7 @@ The command below executes the `zkCli.sh` script to write `world` to the path `/
 ```shell
 kubectl exec zk-0 zkCli.sh create /hello world
 ```
+
 ```
 WATCHER::

@@ -304,7 +303,7 @@ dataLength = 5
 numChildren = 0
 ```

-### Providing Durable Storage
+### Providing durable storage

 As mentioned in the [ZooKeeper Basics](#zookeeper-basics) section,
 ZooKeeper commits all entries to a durable WAL, and periodically writes snapshots
@@ -445,8 +444,8 @@ The `volumeMounts` section of the `StatefulSet`'s container `template` mounts th

 ```shell
 volumeMounts:
-        - name: datadir
-          mountPath: /var/lib/zookeeper
+- name: datadir
+  mountPath: /var/lib/zookeeper
 ```

 When a Pod in the `zk` `StatefulSet` is (re)scheduled, it will always have the
@@ -454,7 +453,7 @@ same `PersistentVolume` mounted to the ZooKeeper server's data directory.
 Even when the Pods are rescheduled, all the writes made to the ZooKeeper
 servers' WALs, and all their snapshots, remain durable.

-## Ensuring Consistent Configuration
+## Ensuring consistent configuration

 As noted in the [Facilitating Leader Election](#facilitating-leader-election) and
 [Achieving Consensus](#achieving-consensus) sections, the servers in a
@@ -469,6 +468,7 @@ Get the `zk` StatefulSet.
 ```shell
 kubectl get sts zk -o yaml
 ```
+
 ```
 …
 command:
@@ -497,7 +497,7 @@ command:

 The command used to start the ZooKeeper servers passed the configuration as command line parameter. You can also use environment variables to pass configuration to the ensemble.

-### Configuring Logging
+### Configuring logging

 One of the files generated by the `zkGenConfig.sh` script controls ZooKeeper's logging.
 ZooKeeper uses [Log4j](https://logging.apache.org/log4j/2.x/), and, by default,
@@ -558,13 +558,11 @@ You can view application logs written to standard out or standard error using `k
 2016-12-06 19:34:46,230 [myid:1] - INFO  [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client)
 ```

-Kubernetes supports more powerful, but more complex, logging integrations
-with [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)
-and [Elasticsearch and Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/).
-For cluster level log shipping and aggregation, consider deploying a [sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
-container to rotate and ship your logs.
+Kubernetes integrates with many logging solutions. You can choose a logging solution
+that best fits your cluster and applications. For cluster-level logging and aggregation,
+consider deploying a [sidecar container](/docs/concepts/cluster-administration/logging#sidecar-container-with-logging-agent) to rotate and ship your logs.

-### Configuring a Non-Privileged User
+### Configuring a non-privileged user

 The best practices to allow an application to run as a privileged
 user inside of a container are a matter of debate. If your organization requires
@@ -612,7 +610,7 @@ Because the `fsGroup` field of the `securityContext` object is set to 1000, the
 drwxr-sr-x 3 zookeeper zookeeper 4096 Dec  5 20:45 /var/lib/zookeeper/data
 ```

-## Managing the ZooKeeper Process
+## Managing the ZooKeeper process

 The [ZooKeeper documentation](https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supervision)
 mentions that "You will want to have a supervisory process that
@@ -622,7 +620,7 @@ common pattern. When deploying an application in Kubernetes, rather than using
 an external utility as a supervisory process, you should use Kubernetes as the
 watchdog for your application.

-### Updating the Ensemble
+### Updating the ensemble

 The `zk` `StatefulSet` is configured to use the `RollingUpdate` update strategy.

@@ -631,6 +629,7 @@ You can use `kubectl patch` to update the number of `cpus` allocated to the serv
 ```shell
 kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]'
 ```
+
 ```
 statefulset.apps/zk patched
 ```
@@ -640,6 +639,7 @@ Use `kubectl rollout status` to watch the status of the update.
 ```shell
 kubectl rollout status sts/zk
 ```
+
 ```
 waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664...
 Waiting for 1 pods to be ready...
@@ -678,7 +678,7 @@ kubectl rollout undo sts/zk
 statefulset.apps/zk rolled back
 ```

-### Handling Process Failure
+### Handling process failure

 [Restart Policies](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) control how
 Kubernetes handles process failures for the entry point of the container in a Pod.
@@ -731,7 +731,7 @@ that implements the application's business logic, the script must terminate with
 child process. This ensures that Kubernetes will restart the application's
 container when the process implementing the application's business logic fails.

-### Testing for Liveness
+### Testing for liveness

 Configuring your application to restart failed processes is not enough to
 keep a distributed system healthy. There are scenarios where
@@ -795,7 +795,7 @@ zk-0      0/1       Running   1         1h
 zk-0      1/1       Running   1         1h
 ```

-### Testing for Readiness
+### Testing for readiness

 Readiness is not the same as liveness. If a process is alive, it is scheduled
 and healthy. If a process is ready, it is able to process input. Liveness is
@@ -824,7 +824,7 @@ Even though the liveness and readiness probes are identical, it is important
 to specify both. This ensures that only healthy servers in the ZooKeeper
 ensemble receive network traffic.

-## Tolerating Node Failure
+## Tolerating Node failure

 ZooKeeper needs a quorum of servers to successfully commit mutations
 to data. For a three server ensemble, two servers must be healthy for
@@ -879,10 +879,10 @@ as `zk` in the domain defined by the `topologyKey`. The `topologyKey`
 different rules, labels, and selectors, you can extend this technique to spread
 your ensemble across physical, network, and power failure domains.

-## Surviving Maintenance
+## Surviving maintenance

-**In this section you will cordon and drain nodes. If you are using this tutorial
-on a shared cluster, be sure that this will not adversely affect other tenants.**
+In this section you will cordon and drain nodes. If you are using this tutorial
+on a shared cluster, be sure that this will not adversely affect other tenants.

 The previous section showed you how to spread your Pods across nodes to survive
 unplanned node failures, but you also need to plan for temporary node failures
@@ -1017,6 +1017,7 @@ Continue to watch the Pods of the stateful set, and drain the node on which
 ```shell
 kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
 ```
+
 ```
 node "kubernetes-node-i4c4" cordoned

@@ -1059,6 +1060,7 @@ Use [`kubectl uncordon`](/docs/reference/generated/kubectl/kubectl-commands/#unc
 ```shell
 kubectl uncordon kubernetes-node-pb41
 ```
+
 ```
 node "kubernetes-node-pb41" uncordoned
 ```
@@ -1068,6 +1070,7 @@ node "kubernetes-node-pb41" uncordoned
 ```shell
 kubectl get pods -w -l app=zk
 ```
+
 ```
 NAME      READY     STATUS    RESTARTS   AGE
 zk-0      1/1       Running   2          1h
@@ -1130,9 +1133,7 @@ You should always allocate additional capacity for critical services so that the

 ## {{% heading "cleanup" %}}

-
 - Use `kubectl uncordon` to uncordon all the nodes in your cluster.
- You will need to delete the persistent storage media for the PersistentVolumes
-  used in this tutorial. Follow the necessary steps, based on your environment,
-  storage configuration, and provisioning method, to ensure that all storage is
-  reclaimed.
+- You must delete the persistent storage media for the PersistentVolumes used in this tutorial.
+  Follow the necessary steps, based on your environment, storage configuration,
+  and provisioning method, to ensure that all storage is reclaimed.
@@ -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)
-