Merge branch 'master' into release-1.8

docs/concepts/cluster-administration/federation.md

@@ -123,7 +123,7 @@ On IaaS providers such as Google Compute Engine or Amazon Web Services, a VM exi
 zone](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).
 We suggest that all the VMs in a Kubernetes cluster should be in the same availability zone, because:
 
-  - compared to having a single global Kubernetes cluster, there are fewer single-points of failure
+  - compared to having a single global Kubernetes cluster, there are fewer single-points of failure.
   - compared to a cluster that spans availability zones, it is easier to reason about the availability properties of a
     single-zone cluster.
   - when the Kubernetes developers are designing the system (e.g. making assumptions about latency, bandwidth, or
@@ -132,8 +132,8 @@ We suggest that all the VMs in a Kubernetes cluster should be in the same availa
 It is okay to have multiple clusters per availability zone, though on balance we think fewer is better.
 Reasons to prefer fewer clusters are:
 
-  - improved bin packing of Pods in some cases with more nodes in one cluster (less resource fragmentation)
-  - reduced operational overhead (though the advantage is diminished as ops tooling and processes matures)
+  - improved bin packing of Pods in some cases with more nodes in one cluster (less resource fragmentation).
+  - reduced operational overhead (though the advantage is diminished as ops tooling and processes matures).
   - reduced costs for per-cluster fixed resource costs, e.g. apiserver VMs (but small as a percentage
     of overall cluster cost for medium to large clusters).
 

docs/concepts/configuration/assign-pod-node.md

@@ -69,7 +69,7 @@ When you then run `kubectl create -f pod.yaml`, the pod will get scheduled on th
 
 ## Interlude: built-in node labels
 
-In addition to labels you [attach yourself](#step-one-attach-label-to-the-node), nodes come pre-populated
+In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes come pre-populated
 with a standard set of labels. As of Kubernetes v1.4 these labels are
 
 * `kubernetes.io/hostname`
@@ -147,7 +147,7 @@ For more information on node affinity, see the design doc
 ### Inter-pod affinity and anti-affinity (beta feature)
 
 Inter-pod affinity and anti-affinity were introduced in Kubernetes 1.4.
-Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to schedule on *based on
+Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled *based on
 labels on pods that are already running on the node* rather than based on labels on nodes. The rules are of the form "this pod should (or, in the case of
 anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y." Y is expressed
 as a LabelSelector with an associated list of namespaces (or "all" namespaces); unlike nodes, because pods are namespaced
@@ -214,7 +214,7 @@ be co-located in the same defined topology, eg., the same node.
 
 ##### Always co-located in the same node
 
-In a three node cluster, a web application has in-memory cache such as redis, we want the web-servers to be co-located with the cache as much as possible. 
+In a three node cluster, a web application has in-memory cache such as redis. We want the web-servers to be co-located with the cache as much as possible. 
 Here is the yaml snippet of a simple redis deployment with three replicas and selector label `app=store`
 
 ```yaml

docs/concepts/configuration/secret.md

@@ -509,7 +509,7 @@ Create a secret containing some ssh keys:
 $ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub
 ```
 
-**Security Note:** think carefully before sending your own ssh keys: other users of the cluster may have access to the secret.  Use a service account which you want to have accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
+**Security Note:** think carefully before sending your own ssh keys: other users of the cluster may have access to the secret.  Use a service account which you want to be accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
 
 
 Now we can create a pod which references the secret with the ssh key and

docs/concepts/policy/pod-security-policy.md

@@ -45,7 +45,7 @@ into three categories:
 - *Controlled by a boolean*: Fields of this type default to the most
 restrictive value.
 - *Controlled by an allowable set*: Fields of this type are checked
-against the set to ensure their value is allowed.
+against the set to ensure their values are allowed.
 - *Controlled by a strategy*: Items that have a strategy to provide
 a mechanism to generate the value and a mechanism to ensure that a
 specified value falls into the set of allowable values.

docs/concepts/policy/resource-quotas.md

@@ -233,7 +233,7 @@ restrictions around nodes: pods from several namespaces may run on the same node
 
 ## Example
 
-See a [detailed example for how to use resource quota](/docs/tasks/configure-pod-container/apply-resource-quota-limit/).
+See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
 
 ## Read More
 

docs/concepts/workloads/controllers/deployment.md

@@ -513,6 +513,7 @@ You can pause a Deployment before triggering one or more updates and then resume
 apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
 
 For example, with a Deployment that was just created:
+
 ```shell
 $ kubectl get deploy
 NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
@@ -523,18 +524,21 @@ nginx-2142116321   3         3         3         1m
 ```
 
 Pause by running the following command:
+
 ```shell
 $ kubectl rollout pause deployment/nginx-deployment
 deployment "nginx-deployment" paused
 ```
 
 Then update the image of the Deployment:
+
 ```shell
 $ kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1
 deployment "nginx-deployment" image updated
 ```
 
 Notice that no new rollout started:
+
 ```shell
 $ kubectl rollout history deploy/nginx-deployment
 deployments "nginx"
@@ -547,6 +551,7 @@ nginx-2142116321   3         3         3         2m
 ```
 
 You can make as many updates as you wish, for example, update the resources that will be used:
+
 ```shell
 $ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
 deployment "nginx" resource requirements updated
@@ -556,6 +561,7 @@ The initial state of the Deployment prior to pausing it will continue its functi
 the Deployment will not have any effect as long as the Deployment is paused.
 
 Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
+
 ```shell
 $ kubectl rollout resume deploy/nginx-deployment
 deployment "nginx" resumed

docs/concepts/workloads/controllers/jobs-run-to-completion.md

@@ -291,7 +291,7 @@ unique to the pods of that job, and which matches unrelated pods, then pods of t
 job may be deleted, or this job may count other pods as completing it, or one or both
 of the jobs may refuse to create pods or run to completion.  If a non-unique selector is
 chosen, then other controllers (e.g. ReplicationController) and their pods may behave
-in unpredicatable ways too.  Kubernetes will not stop you from making a mistake when
+in unpredictable ways too.  Kubernetes will not stop you from making a mistake when
 specifying `spec.selector`.
 
 Here is an example of a case when you might want to use this feature.

docs/concepts/workloads/pods/pod-overview.md

@@ -19,7 +19,7 @@ A Pod encapsulates an application container (or, in some cases, multiple contain
 
 > [Docker](https://www.docker.com) is the most common container runtime used in a Kubernetes Pod, but Pods support other container runtimes as well.
 
-Pods are employed in a number of ways in a Kubernetes cluster, including:
+Pods in a Kubernetes cluster can be used in two main ways:
 
 * **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
 * **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
@@ -63,9 +63,9 @@ A Controller can create and manage multiple Pods for you, handling replication a
 
 Some examples of Controllers that contain one or more pods include:
 
-* Deployment
+* [Deployment](/docs/concepts/workloads/controllers/deployment/)
 * [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/)
-* DaemonSet
+* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
 
 In general, Controllers use a Pod Template that you provide to create the Pods for which it is responsible.
 
@@ -81,7 +81,7 @@ Rather than specifying the current desired state of all replicas, pod templates
 
 {% capture whatsnext %}
 * Learn more about Pod behavior:
-  * Pod Termination
+  * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
   * Other Pod Topics
 {% endcapture %}