POST /api/v1/namespaces/{namespace}/pods/{name}/eviction
diff --git a/docs/admin/addons.md b/docs/admin/addons.md
index f45aebeb09..aeee68cc30 100644
--- a/docs/admin/addons.md
+++ b/docs/admin/addons.md
@@ -14,7 +14,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
* [Calico](http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/) is a secure L3 networking and network policy provider.
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install/kubeadm) unites Flannel and Calico, providing networking and network policy.
-* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is a overlay network provider that can be used with Kubernetes.
+* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is an overlay network provider that can be used with Kubernetes.
* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/user-guide/networkpolicies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
diff --git a/docs/admin/kubelet.md b/docs/admin/kubelet.md
index 342189ba94..e593cda77b 100644
--- a/docs/admin/kubelet.md
+++ b/docs/admin/kubelet.md
@@ -79,7 +79,7 @@ kubelet
--experimental-bootstrap-kubeconfig string
Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by --kubeconfig. The certificate and key file will be stored in the directory pointed by --cert-dir.
--experimental-cgroups-per-qos Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created.
--experimental-check-node-capabilities-before-mount [Experimental] if set true, the kubelet will check the underlying node for required componenets (binaries, etc.) before performing the mount
- --experimental-cri [Experimental] Enable the Container Runtime Interface (CRI) integration. If --container-runtime is set to "remote", Kubelet will communicate with the runtime/image CRI server listening on the endpoint specified by --remote-runtime-endpoint/--remote-image-endpoint. If --container-runtime is set to "docker", Kubelet will launch a in-process CRI server on behalf of docker, and communicate over a default endpoint.
+ --experimental-cri [Experimental] Enable the Container Runtime Interface (CRI) integration. If --container-runtime is set to "remote", Kubelet will communicate with the runtime/image CRI server listening on the endpoint specified by --remote-runtime-endpoint/--remote-image-endpoint. If --container-runtime is set to "docker", Kubelet will launch an in-process CRI server on behalf of docker, and communicate over a default endpoint.
--experimental-fail-swap-on Makes the Kubelet fail to start if swap is enabled on the node. This is a temporary opton to maintain legacy behavior, failing due to swap enabled will happen by default in v1.6.
--experimental-kernel-memcg-notification If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling.
--experimental-mounter-path string [Experimental] Path of mounter binary. Leave empty to use the default mount.
diff --git a/docs/getting-started-guides/libvirt-coreos.md b/docs/getting-started-guides/libvirt-coreos.md
index 73be7e4261..e5668dbf53 100644
--- a/docs/getting-started-guides/libvirt-coreos.md
+++ b/docs/getting-started-guides/libvirt-coreos.md
@@ -30,7 +30,7 @@ Another difference is that no security is enforced on `libvirt-coreos` at all. F
* Kubernetes secrets are not protected as securely as they are on production environments;
* etc.
-So, an k8s application developer should not validate its interaction with Kubernetes on `libvirt-coreos` because he might technically succeed in doing things that are prohibited on a production environment like:
+So, a k8s application developer should not validate its interaction with Kubernetes on `libvirt-coreos` because he might technically succeed in doing things that are prohibited on a production environment like:
* un-authenticated access to Kube API server;
* Access to Kubernetes private data structures inside etcd;
diff --git a/docs/getting-started-guides/mesos/index.md b/docs/getting-started-guides/mesos/index.md
index 948eae1a41..499ff0ba51 100644
--- a/docs/getting-started-guides/mesos/index.md
+++ b/docs/getting-started-guides/mesos/index.md
@@ -229,7 +229,7 @@ We assume that kube-dns will use
Note that we have passed these two values already as parameter to the apiserver above.
-A template for an replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/skydns-rc.yaml.in][11] in the repository. The following steps are necessary in order to get a valid replication controller yaml file:
+A template for a replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/skydns-rc.yaml.in][11] in the repository. The following steps are necessary in order to get a valid replication controller yaml file:
- replace `{% raw %}{{ pillar['dns_replicas'] }}{% endraw %}` with `1`
- replace `{% raw %}{{ pillar['dns_domain'] }}{% endraw %}` with `cluster.local.`
diff --git a/docs/getting-started-guides/rackspace.md b/docs/getting-started-guides/rackspace.md
index 00c73a8e59..ff59f4d31b 100644
--- a/docs/getting-started-guides/rackspace.md
+++ b/docs/getting-started-guides/rackspace.md
@@ -45,7 +45,7 @@ There is a specific `cluster/rackspace` directory with the scripts for the follo
1. A cloud network will be created and all instances will be attached to this network.
- flanneld uses this network for next hop routing. These routes allow the containers running on each node to communicate with one another on this private network.
-2. A SSH key will be created and uploaded if needed. This key must be used to ssh into the machines (we do not capture the password).
+2. An SSH key will be created and uploaded if needed. This key must be used to ssh into the machines (we do not capture the password).
3. The master server and additional nodes will be created via the `nova` CLI. A `cloud-config.yaml` is generated and provided as user-data with the entire configuration for the systems.
4. We then boot as many nodes as defined via `$NUM_NODES`.
diff --git a/docs/tutorials/services/source-ip.md b/docs/tutorials/services/source-ip.md
index 6657e42720..76548e68ad 100644
--- a/docs/tutorials/services/source-ip.md
+++ b/docs/tutorials/services/source-ip.md
@@ -29,7 +29,7 @@ This document makes use of the following terms:
You must have a working Kubernetes 1.5 cluster to run the examples in this
document. The examples use a small nginx webserver that echoes back the source
-IP of requests it receives through a HTTP header. You can create it as follows:
+IP of requests it receives through an HTTP header. You can create it as follows:
```console
$ kubectl run source-ip-app --image=gcr.io/google_containers/echoserver:1.4
diff --git a/docs/user-guide/connecting-applications.md b/docs/user-guide/connecting-applications.md
index 95d365bdb1..c4ca8d20f0 100644
--- a/docs/user-guide/connecting-applications.md
+++ b/docs/user-guide/connecting-applications.md
@@ -181,7 +181,7 @@ default-token-il9rc kubernetes.io/service-account-token 1
nginxsecret Opaque 2
```
-Now modify your nginx replicas to start a https server using the certificate in the secret, and the Service, to expose both ports (80 and 443):
+Now modify your nginx replicas to start an https server using the certificate in the secret, and the Service, to expose both ports (80 and 443):
{% include code.html language="yaml" file="nginx-secure-app.yaml" ghlink="/docs/user-guide/nginx-secure-app" %}
diff --git a/docs/user-guide/jobs/work-queue-2/rediswq.py b/docs/user-guide/jobs/work-queue-2/rediswq.py
index ebefa64311..ceda8bd1e3 100644
--- a/docs/user-guide/jobs/work-queue-2/rediswq.py
+++ b/docs/user-guide/jobs/work-queue-2/rediswq.py
@@ -95,7 +95,7 @@ class RedisWQ(object):
# Record that we (this session id) are working on a key. Expire that
# note after the lease timeout.
# Note: if we crash at this line of the program, then GC will see no lease
- # for this item an later return it to the main queue.
+ # for this item a later return it to the main queue.
itemkey = self._itemkey(item)
self._db.setex(self._lease_key_prefix + itemkey, lease_secs, self._session)
return item
diff --git a/docs/user-guide/load-balancer.md b/docs/user-guide/load-balancer.md
index d8540d98e5..fadeb38d5f 100644
--- a/docs/user-guide/load-balancer.md
+++ b/docs/user-guide/load-balancer.md
@@ -93,7 +93,7 @@ Due to the implementation of this feature, the source IP for sessions as seen in
that will preserve the client Source IP for GCE/GKE environments. This feature will be phased in for other cloud providers in subsequent releases.
## Annotation to modify the LoadBalancer behavior for preservation of Source IP
-In 1.5, an Beta feature has been added that changes the behavior of the external LoadBalancer feature.
+In 1.5, a Beta feature has been added that changes the behavior of the external LoadBalancer feature.
This feature can be activated by adding the beta annotation below to the metadata section of the Service Configuration file.
diff --git a/docs/user-guide/petset.md b/docs/user-guide/petset.md
index 3cba1fb31e..07934774b4 100644
--- a/docs/user-guide/petset.md
+++ b/docs/user-guide/petset.md
@@ -88,7 +88,7 @@ Only use PetSet if your application requires some or all of these properties. Ma
Example workloads for PetSet:
-* Databases like MySQL or PostgreSQL that require a single instance attached to a NFS persistent volume at any time
+* Databases like MySQL or PostgreSQL that require a single instance attached to an NFS persistent volume at any time
* Clustered software like Zookeeper, Etcd, or Elasticsearch that require stable membership.
## Alpha limitations
diff --git a/docs/user-guide/pods/init-container.md b/docs/user-guide/pods/init-container.md
index 75b6efcac3..c9266baf67 100644
--- a/docs/user-guide/pods/init-container.md
+++ b/docs/user-guide/pods/init-container.md
@@ -105,7 +105,7 @@ If the pod is [restarted](#pod-restart-reasons) all init containers must
execute again.
Changes to the init container spec are limited to the container image field.
-Altering a init container image field is equivalent to restarting the pod.
+Altering an init container image field is equivalent to restarting the pod.
Because init containers can be restarted, retried, or reexecuted, init container
code should be idempotent. In particular, code that writes to files on EmptyDirs