diff --git a/cn/docs/getting-started-guides/coreos/bare_metal_offline.md b/cn/docs/getting-started-guides/coreos/bare_metal_offline.md
index 389428c439..023fa35ce1 100644
--- a/cn/docs/getting-started-guides/coreos/bare_metal_offline.md
+++ b/cn/docs/getting-started-guides/coreos/bare_metal_offline.md
@@ -92,11 +92,11 @@ LABEL local
         LOCALBOOT 0
 ```
 
-至此，您应当已经配置好一个可用的PXELINUX环境用来运行CoreOS节点了，您可以通过在本地运行VirtualBox或者物理裸机来验证这一点。
+至此，您应当已经配置好一个可用的PXELINUX环境用来运行CoreOS节点了。您可以使用VirtualBox或者在物理裸机上对PXELINUX环境所提供的服务进行验证。
 
 ## 添加CoreOS至PXE
 
-本节将介绍如何在一个现有的PXELINUX环境上设置CoreOS镜像。
+本节描述在已有PXELINUX环境的前提下，如何配置CoreOS镜像与之并存。
 
 1. 查找或者创建TFTP根目录，后续所有步骤都将基于此目录。
     * 本文中我们假设`/tftpboot`是根目录。
@@ -199,13 +199,13 @@ subnet 10.20.30.0 netmask 255.255.255.0 {
 1. 第一种方式是将云配置文件模版化，然后通过编程的方式为不同的集群提供不同的配置。
 2. 第二种方式是运行一个服务发现协议从而可以在云环境中做服务的自动发现。
 
-在本demo中，我们仅简单地创建一个静态的单一`etcd`服务器来运行Kubernetes并提供`etcd`的主要服务。
+在本示例中，我们将通过静态方式创建一个etcd服务器，用于运行Kubernetes主控组件，并用作etcd主节点。
 
-由于我们的集群处于一个离线的环境中，所以大部分的CoreOS和Kubernetes帮助进程是受限的。为了完成部署，我们需要下载Kubernetes的各种可执行文件到本地然后再启动运行。
+由于我们的集群处于一个离线的环境中，所以大部分的CoreOS和Kubernetes帮助进程是受限的。为了完成部署，我们需要下载Kubernetes的各个可执行文件到本地然后再启动运行。
 
-一种简单的方案是在DHCP/TFTP主机上搭建一个简易的web服务器，从而环境中的CoreOS PXE机器可以从其上下载各种可执行文件。
+一种简单的方案是在DHCP/TFTP主机上搭建一个简易的web服务器，从而环境中的CoreOS PXE机器可以从其上下载各个可执行文件。
 
-为了达到这一目标，我们将启动一个`apache`服务器并提供运行Kuberetes所需要的各种可执行文件。
+为了达到这一目标，我们将启动一个`apache`服务器并提供运行Kubernetes所需要的各个可执行文件。
 
 以下脚本运行在上文中准备好的PXE服务器上：
 
diff --git a/docs/admin/authorization/rbac.md b/docs/admin/authorization/rbac.md
index d3883b1712..0b974dc012 100644
--- a/docs/admin/authorization/rbac.md
+++ b/docs/admin/authorization/rbac.md
@@ -755,7 +755,7 @@ Here are two approaches for managing this transition:
 Run both the RBAC and ABAC authorizers, and include the legacy ABAC policy:
 
 ```
---authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.jsonl
+--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json
 ```
 
 The RBAC authorizer will attempt to authorize requests first. If it denies an API request,
diff --git a/docs/admin/cluster-large.md b/docs/admin/cluster-large.md
index e8c1dbe2c6..630a9f4fb7 100644
--- a/docs/admin/cluster-large.md
+++ b/docs/admin/cluster-large.md
@@ -7,11 +7,11 @@ title: Building Large Clusters
 
 ## Support
 
-At {{page.version}}, Kubernetes supports clusters with up to 1000 nodes. More specifically, we support configurations that meet *all* of the following criteria:
+At {{page.version}}, Kubernetes supports clusters with up to 5000 nodes. More specifically, we support configurations that meet *all* of the following criteria:
 
-* No more than 2000 nodes
-* No more than 60000 total pods
-* No more than 120000 total containers
+* No more than 5000 nodes
+* No more than 150000 total pods
+* No more than 300000 total containers
 * No more than 100 pods per node
 
 <br>
diff --git a/docs/admin/kube-apiserver.md b/docs/admin/kube-apiserver.md
index fa3b3338c9..d77b83a22d 100644
--- a/docs/admin/kube-apiserver.md
+++ b/docs/admin/kube-apiserver.md
@@ -129,7 +129,7 @@ TaintBasedEvictions=true|false (ALPHA - default=false)
       --storage-media-type string                               The media type to use to store objects in storage. Some resources or storage backends may only support a specific media type and will ignore this setting. (default "application/vnd.kubernetes.protobuf")
       --storage-versions string                                 The per-group version to store resources in. Specified in the format "group1/version1,group2/version2,...". In the case where objects are moved from one group to the other, you may specify the format "group1=group2/v1beta1,group3/v1beta1,...". You only need to pass the groups you wish to change from the defaults. It defaults to a list of preferred versions of all registered groups, which is derived from the KUBE_API_VERSIONS environment variable. (default "admission.k8s.io/v1alpha1,admissionregistration.k8s.io/v1alpha1,apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,imagepolicy.k8s.io/v1alpha1,networking.k8s.io/v1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1,v1")
       --target-ram-mb int                                       Memory limit for apiserver in MB (used to configure sizes of caches, etc.)
-      --tls-ca-file string                                      If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle. Altneratively, the certificate authority can be appended to the certificate provided by --tls-cert-file.
+      --tls-ca-file string                                      If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle. Alternatively, the certificate authority can be appended to the certificate provided by --tls-cert-file.
       --tls-cert-file string                                    File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes.
       --tls-private-key-file string                             File containing the default x509 private key matching --tls-cert-file.
       --tls-sni-cert-key namedCertKey                           A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". (default [])
diff --git a/docs/concepts/overview/what-is-kubernetes.md b/docs/concepts/overview/what-is-kubernetes.md
index b2246d22ef..24fff49e9c 100644
--- a/docs/concepts/overview/what-is-kubernetes.md
+++ b/docs/concepts/overview/what-is-kubernetes.md
@@ -10,7 +10,7 @@ This page is an overview of Kubernetes.
 {% endcapture %}
 
 {% capture body %}
-Kubernetes is an [open-source platform for automating deployment, scaling, and operations of application containers](http://www.slideshare.net/BrianGrant11/wso2con-us-2015-kubernetes-a-platform-for-automating-deployment-scaling-and-operations) across clusters of hosts, providing container-centric infrastructure.
+Kubernetes is an [open-source platform designed to automate deploying, scaling, and operating application containers](http://www.slideshare.net/BrianGrant11/wso2con-us-2015-kubernetes-a-platform-for-automating-deployment-scaling-and-operations).
 
 With Kubernetes, you are able to quickly and efficiently respond to customer demand:
 
diff --git a/docs/concepts/services-networking/ingress.md b/docs/concepts/services-networking/ingress.md
index eddb9cc08d..dbeea67b61 100644
--- a/docs/concepts/services-networking/ingress.md
+++ b/docs/concepts/services-networking/ingress.md
@@ -79,7 +79,7 @@ __Lines 10-11__: Each http rule contains the following information: A host (e.g.
 
 __Lines 12-14__: A backend is a service:port combination as described in the [services doc](/docs/concepts/services-networking/service/). Ingress traffic is typically sent directly to the endpoints matching a backend.
 
-__Global Parameters__: For the sake of simplicity the example Ingress has no global parameters, see the [api-reference](https://releases.k8s.io/{{page.githubbranch}}/pkg/apis/extensions/v1beta1/types.go) for a full definition of the resource. One can specify a global default backend in the absence of which requests that don't match a path in the spec are sent to the default backend of the Ingress controller.
+__Global Parameters__: For the sake of simplicity the example Ingress has no global parameters, see the [API reference](https://releases.k8s.io/{{page.githubbranch}}/staging/src/k8s.io/api/extensions/v1beta1/types.go) for a full definition of the resource. One can specify a global default backend in the absence of which requests that don't match a path in the spec are sent to the default backend of the Ingress controller.
 
 ## Ingress controllers
 
diff --git a/docs/concepts/services-networking/service.md b/docs/concepts/services-networking/service.md
index 24a91dd366..751c2f0770 100644
--- a/docs/concepts/services-networking/service.md
+++ b/docs/concepts/services-networking/service.md
@@ -338,9 +338,9 @@ For headless services that do not define selectors, the endpoints controller doe
 not create `Endpoints` records. However, the DNS system looks for and configures
 either:
 
-  * CNAME records for `ExternalName`-type services
+  * CNAME records for `ExternalName`-type services.
   * A records for any `Endpoints` that share a name with the service, for all
-    other types
+    other types.
 
 ## Publishing services - service types
 
diff --git a/docs/concepts/storage/volumes.md b/docs/concepts/storage/volumes.md
index 153a22f5bf..295345f5c7 100644
--- a/docs/concepts/storage/volumes.md
+++ b/docs/concepts/storage/volumes.md
@@ -289,10 +289,10 @@ spec:
 
 ### nfs
 
-An `nfs` volume allows an existing NFS (Network File System) share to be
+A `nfs` volume allows an existing NFS (Network File System) share to be
 mounted into your pod. Unlike `emptyDir`, which is erased when a Pod is
 removed, the contents of an `nfs` volume are preserved and the volume is merely
-unmounted.  This means that an NFS volume can be pre-populated with data, and
+unmounted.  This means that a NFS volume can be pre-populated with data, and
 that data can be "handed off" between pods.  NFS can be mounted by multiple
 writers simultaneously.
 
@@ -322,7 +322,7 @@ See the [iSCSI example](https://github.com/kubernetes/kubernetes/tree/{{page.git
 
 ### fc (fibre channel)
 
-An `fc` volume allows an existing fibre channel volume to be mounted into your pod.
+A `fc` volume allows an existing fibre channel volume to be mounted into your pod.
 You can specify single or multiple target World Wide Names to the parameter
 targetWWNs in your volume configuration. If multiple WWNs are specified,
 targetWWNs expects that those WWNs form multipath connection.
@@ -365,7 +365,7 @@ See the [GlusterFS example](https://github.com/kubernetes/kubernetes/tree/{{page
 
 ### rbd
 
-An `rbd` volume allows a [Rados Block
+A `rbd` volume allows a [Rados Block
 Device](http://ceph.com/docs/master/rbd/rbd/) volume to be mounted into your
 pod.  Unlike `emptyDir`, which is erased when a Pod is removed, the contents of
 a `rbd` volume are preserved and the volume is merely unmounted.  This
diff --git a/docs/concepts/workloads/controllers/deployment.md b/docs/concepts/workloads/controllers/deployment.md
index c9961cd911..ac8c528200 100644
--- a/docs/concepts/workloads/controllers/deployment.md
+++ b/docs/concepts/workloads/controllers/deployment.md
@@ -510,7 +510,7 @@ nginx-deployment-618515232    11        11        11        7m
 ## Pausing and Resuming a Deployment
 
 You can pause a Deployment before triggering one or more updates and then resume it. This will allow you to
-apply multiple fixes in between pausing and resuming without triggering unnecesarry rollouts.
+apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
 
 For example, with a Deployment that was just created:
 ```shell
diff --git a/docs/tasks/access-application-cluster/access-cluster.md b/docs/tasks/access-application-cluster/access-cluster.md
index 5d7d0a7275..c664fd79fc 100644
--- a/docs/tasks/access-application-cluster/access-cluster.md
+++ b/docs/tasks/access-application-cluster/access-cluster.md
@@ -174,7 +174,7 @@ From within a pod the recommended ways to connect to API are:
     in any container of the pod can access it.  See this [example of using kubectl proxy
     in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/).
   - use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
-    They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster/main.go)
+    They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
 
 In each case, the credentials of the pod are used to communicate securely with the apiserver.
 
diff --git a/docs/tasks/configure-pod-container/configure-volume-storage.md b/docs/tasks/configure-pod-container/configure-volume-storage.md
index 7fad341494..d2f945097b 100644
--- a/docs/tasks/configure-pod-container/configure-volume-storage.md
+++ b/docs/tasks/configure-pod-container/configure-volume-storage.md
@@ -35,50 +35,50 @@ restarts. Here is the configuration file for the Pod:
 
 1. Create the Pod:
 
-        kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml
+       kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml
 
 1. Verify that the Pod's Container is running, and then watch for changes to
 the Pod:
 
-        kubectl get --watch pod redis
+       kubectl get --watch pod redis
 
     The output looks like this:
 
-        NAME      READY     STATUS    RESTARTS   AGE
-        redis     1/1       Running   0          13s
+       NAME      READY     STATUS    RESTARTS   AGE
+       redis     1/1       Running   0          13s
 
 1. In another terminal, get a shell to the running Container:
 
-        kubectl exec -it redis -- /bin/bash
+       kubectl exec -it redis -- /bin/bash
 
 1. In your shell, go to `/data/redis`, and create a file:
 
-        root@redis:/data/redis# echo Hello > test-file
+       root@redis:/data/redis# echo Hello > test-file
 
 1. In your shell, list the running processes:
 
-        root@redis:/data/redis# ps aux
+       root@redis:/data/redis# ps aux
 
     The output is similar to this:
 
-        USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
-        redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379
-        root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash
-        root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux
+       USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
+       redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379
+       root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash
+       root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux
 
 1. In your shell, kill the redis process:
 
-        root@redis:/data/redis# kill <pid>
+       root@redis:/data/redis# kill <pid>
 
     where `<pid>` is the redis process ID (PID).
 
 1. In your original terminal, watch for changes to the redis Pod. Eventually,
 you will see something like this:
 
-        NAME      READY     STATUS     RESTARTS   AGE
-        redis     1/1       Running    0          13s
-        redis     0/1       Completed  0         6m
-        redis     1/1       Running    1         6m
+       NAME      READY     STATUS     RESTARTS   AGE
+       redis     1/1       Running    0          13s
+       redis     0/1       Completed  0         6m
+       redis     1/1       Running    1         6m
 
 At this point, the Container has terminated and restarted. This is because the
 redis Pod has a
@@ -87,7 +87,7 @@ of `Always`.
 
 1. Get a shell into the restarted Container:
 
-        kubectl exec -it redis -- /bin/bash
+       kubectl exec -it redis -- /bin/bash
 
 1. In your shell, goto `/data/redis`, and verify that `test-file` is still there.
 
diff --git a/docs/tasks/federation/set-up-cluster-federation-kubefed.md b/docs/tasks/federation/set-up-cluster-federation-kubefed.md
index 114d54b735..1c379b198a 100644
--- a/docs/tasks/federation/set-up-cluster-federation-kubefed.md
+++ b/docs/tasks/federation/set-up-cluster-federation-kubefed.md
@@ -61,6 +61,15 @@ sudo cp kubernetes/client/bin/kubectl /usr/local/bin
 sudo chmod +x /usr/local/bin/kubectl
 ```
 
+### Install with snap on Ubuntu
+
+kubefed is available as a [snap](https://snapcraft.io/) application.
+
+1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with:
+
+        sudo snap install kubefed --classic
+
+2. Run `kubefed version` to verify that the verison you've installed is sufficiently up-to-date.
 
 ## Choosing a host cluster.
 
diff --git a/docs/tasks/manage-gpus/scheduling-gpus.md b/docs/tasks/manage-gpus/scheduling-gpus.md
index 76a5b3fe02..ee7af6b8ca 100644
--- a/docs/tasks/manage-gpus/scheduling-gpus.md
+++ b/docs/tasks/manage-gpus/scheduling-gpus.md
@@ -143,7 +143,7 @@ spec:
 
 ## Future
 
-- Support for hardware accelerators is in it's early stages in Kubernetes.
+- Support for hardware accelerators is in its early stages in Kubernetes.
 - GPUs and other accelerators will soon be a native compute resource across the system.
 - Better APIs will be introduced to provision and consume accelerators in a scalable manner.
 - Kubernetes will automatically ensure that applications consuming GPUs gets the best possible performance.
diff --git a/docs/tutorials/stateful-application/basic-stateful-set.md b/docs/tutorials/stateful-application/basic-stateful-set.md
index a25e7d3fb1..09ab1028a3 100644
--- a/docs/tutorials/stateful-application/basic-stateful-set.md
+++ b/docs/tutorials/stateful-application/basic-stateful-set.md
@@ -1006,7 +1006,7 @@ above.
 ### Parallel Pod Management
 
 `Parallel` pod management tells the StatefulSet controller to launch or 
-terminate all Pods in parallel, and to not wait for Pods to becoming Running 
+terminate all Pods in parallel, and not to wait for Pods to become Running 
 and Ready or completely terminated prior to launching or terminating another 
 Pod.