Merge branch 'master' into master

docs/user-guide/ingress.md

@@ -53,18 +53,18 @@ Make sure you review the [beta limitations](https://github.com/kubernetes/contri
 A minimal Ingress might look like:
 
 ```yaml
-01. apiVersion: extensions/v1beta1
-02. kind: Ingress
-03. metadata:
-04.  name: test-ingress
-05. spec:
-06.  rules:
-07.  - http:
-08.      paths:
-09.      - path: /testpath
-10.        backend:
-11.          serviceName: test
-12.          servicePort: 80
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  name: test-ingress
+spec:
+  rules:
+  - http:
+      paths:
+      - path: /testpath
+        backend:
+          serviceName: test
+          servicePort: 80
 ```
 
 *POSTing this to the API server will have no effect if you have not configured an [Ingress controller](#ingress-controllers).*

docs/user-guide/persistent-volumes/volumes/local-01.yaml

@@ -10,4 +10,4 @@ spec:
   accessModes:
     - ReadWriteOnce
   hostPath:
-    path: "/somepath/data01"
+    path: "/tmp/data01"

docs/user-guide/persistent-volumes/walkthrough.md

@@ -27,7 +27,7 @@ for ease of development and testing.  You'll create a local `HostPath` for this
 support local storage on the host at this time.  There is no guarantee your pod ends up on the correct node where the `HostPath` resides.
 
 ```shell
-# This will be nginx's webroot
+# This will be nginx's webroot; execute this on the node where your pod will run.
 $ mkdir /tmp/data01
 $ echo 'I love Kubernetes storage!' > /tmp/data01/index.html
 ```
@@ -125,4 +125,4 @@ I love Kubernetes storage!
 
 Hopefully this simple guide is enough to get you started with PersistentVolumes.  If you have any questions, join the team on [Slack](/docs/troubleshooting/#slack) and ask!
 
-Enjoy!
+Enjoy!

docs/user-guide/production-pods.md

@@ -220,7 +220,7 @@ The specification of a pre-stop hook is similar to that of probes, but without t
 
 ## Termination message
 
-In order to achieve a reasonably high level of availability, especially for actively developed applications, it's important to debug failures quickly. Kubernetes can speed debugging by surfacing causes of fatal errors in a way that can be display using [`kubectl`](/docs/user-guide/kubectl/kubectl) or the [UI](/docs/user-guide/ui), in addition to general [log collection](/docs/user-guide/logging). It is possible to specify a `terminationMessagePath` where a container will write its 'death rattle'?, such as assertion failure messages, stack traces, exceptions, and so on. The default path is `/dev/termination-log`.
+In order to achieve a reasonably high level of availability, especially for actively developed applications, it's important to debug failures quickly. Kubernetes can speed debugging by surfacing causes of fatal errors in a way that can be display using [`kubectl`](/docs/user-guide/kubectl/) or the [UI](/docs/user-guide/ui), in addition to general [log collection](/docs/user-guide/logging). It is possible to specify a `terminationMessagePath` where a container will write its 'death rattle'?, such as assertion failure messages, stack traces, exceptions, and so on. The default path is `/dev/termination-log`.
 
 Here is a toy example:
 

docs/user-guide/service-accounts.md

@@ -31,8 +31,8 @@ you get the raw json or yaml for a pod you have created (e.g. `kubectl get
 pods/podname -o yaml`), you can see the `spec.serviceAccount` field has been
 [automatically set](/docs/user-guide/working-with-resources/#resources-are-automatically-modified).
 
-You can access the API using a proxy or with a client library, as described in
-[Accessing the Cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).
+With service accounts, you can access the API inside the pod using a proxy or with a client library,
+as described in [Accessing the Cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).
 
 ## Using Multiple Service Accounts.
 

docs/user-guide/sharing-clusters.md

@@ -115,12 +115,12 @@ make all four clusters available on both hosts by running
 # on host2, copy host1's default kubeconfig, and merge it from env
 $ scp host1:/path/to/home1/.kube/config /path/to/other/.kube/config
 
-$ export $KUBECONFIG=/path/to/other/.kube/config
+$ export KUBECONFIG=/path/to/other/.kube/config
 
 # on host1, copy host2's default kubeconfig and merge it from env
 $ scp host2:/path/to/home2/.kube/config /path/to/other/.kube/config
 
-$ export $KUBECONFIG=/path/to/other/.kube/config
+$ export KUBECONFIG=/path/to/other/.kube/config
 ```
 
 Detailed examples and explanation of `kubeconfig` loading/merging rules can be found in [kubeconfig-file](/docs/user-guide/kubeconfig-file).

docs/user-guide/thirdpartyresources.md

@@ -22,7 +22,7 @@ Each `ThirdPartyResource` has the following:
    * `description` - A free text description of the resource.
    * `versions` - A list of the versions of the resource.
 
-The `kind` for a `ThirdPartyResource` takes the form `<kind name>.<domain>`. You are expected to provide a unique kind and domain name in order to avoid conflicts with other `ThirdPartyResource` objects. Kind names will be converted to CamelCase when creating instances of the `ThirdPartyResource`. Hypens in the `kind` are assumed to be word breaks. For instance the kind `camel-case` would be converted to `CamelCase` but `camelcase` would be converted to `Camelcase`.
+The `kind` for a `ThirdPartyResource` takes the form `<kind name>.<domain>`. You are expected to provide a unique kind and domain name in order to avoid conflicts with other `ThirdPartyResource` objects. Kind names will be converted to CamelCase when creating instances of the `ThirdPartyResource`. Hyphens in the `kind` are assumed to be word breaks. For instance the kind `camel-case` would be converted to `CamelCase` but `camelcase` would be converted to `Camelcase`.
 
 Other fields on the `ThirdPartyResource` are treated as custom data fields. These fields can hold arbitrary JSON data and have any structure.