Merge branch 'master' into master

Author: king-julien

docs/admin/daemons.md

@@ -7,7 +7,7 @@ title: Daemon Sets
 * TOC
 {:toc}
 
-## What is a _Daemon Set_?
+## What is a Daemon Set?
 
 A _Daemon Set_ ensures that all (or some) nodes run a copy of a pod.  As nodes are added to the
 cluster, pods are added to them.  As nodes are removed from the cluster, those pods are garbage

docs/admin/static-pods.md

@@ -16,7 +16,7 @@ Static pod can be created in two ways: either by using configuration file(s) or
 
 ### Configuration files
 
-The configuration files are just standard pod definition in json or yaml format in specific directory. Use `kubelet --config=<the directory>` to start kubelet daemon, which periodically scans the directory and creates/deletes static pods as yaml/json files appear/disappear there.
+The configuration files are just standard pod definition in json or yaml format in specific directory. Use `kubelet --pod-manifest-path=<the directory>` to start kubelet daemon, which periodically scans the directory and creates/deletes static pods as yaml/json files appear/disappear there.
 
 For example, this is how to start a simple web server as a static pod:
 
@@ -48,10 +48,10 @@ For example, this is how to start a simple web server as a static pod:
     EOF
     ```
 
-2. Configure your kubelet daemon on the node to use this directory by running it with `--config=/etc/kubelet.d/` argument.  On Fedora edit `/etc/kubernetes/kubelet` to include this line:
+2. Configure your kubelet daemon on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument.  On Fedora edit `/etc/kubernetes/kubelet` to include this line:
 
     ```conf
-    KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --config=/etc/kubelet.d/"
+    KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
     ```
 
     Instructions for other distributions or Kubernetes installations may vary.
@@ -64,11 +64,11 @@ For example, this is how to start a simple web server as a static pod:
 
 ## Pods created via HTTP
 
-Kubelet periodically downloads a file specified by `--manifest-url=<URL>` argument and interprets it as a json/yaml file with a pod definition. It works the same as `--config=<directory>`, i.e. it's reloaded every now and then and changes are applied to running static pods (see below).
+Kubelet periodically downloads a file specified by `--manifest-url=<URL>` argument and interprets it as a json/yaml file with a pod definition. It works the same as `--pod-manifest-path=<directory>`, i.e. it's reloaded every now and then and changes are applied to running static pods (see below).
 
 ## Behavior of static pods
 
-When kubelet starts, it automatically starts all pods defined in directory specified in `--config=` or `--manifest-url=` arguments, i.e. our static-web.  (It may take some time to pull nginx image, be patient…):
+When kubelet starts, it automatically starts all pods defined in directory specified in `--pod-manifest-path=` or `--manifest-url=` arguments, i.e. our static-web.  (It may take some time to pull nginx image, be patient…):
 
 ```shell
 [joe@my-node1 ~] $ docker ps

docs/concepts/abstractions/controllers/statefulsets.md

@@ -32,12 +32,12 @@ following.
 * Ordered, graceful deployment and scaling.
 * Ordered, graceful deletion and termination.
 
-In the above, stable is synonymous with persistent across Pod (re) schedulings.
+In the above, stable is synonymous with persistence across Pod (re)schedulings.
 If an application doesn't require any stable identifiers or ordered deployment, 
 deletion, or scaling, you should deploy your application with a controller that 
-provides a set of stateless replicas. Such controllers, such as 
+provides a set of stateless replicas. Controllers such as 
 [Deployment](/docs/user-guide/deployments/) or 
-[ReplicaSet](/docs/user-guide/replicasets/) may be better suited to your needs.
+[ReplicaSet](/docs/user-guide/replicasets/) may be better suited to your stateless needs.
 
 ### Limitations
 * StatefulSet is a beta resource, not available in any Kubernetes release prior to 1.5.
@@ -52,7 +52,7 @@ The example below demonstrates the components of a StatefulSet.
 
 * A Headless Service, named nginx, is used to control the network domain. 
 * The StatefulSet, named web, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
-* The volumeClaimTemplates, will provide stable storage using [PersistentVolumes](/docs/user-guide/volumes/) provisioned by a 
+* The volumeClaimTemplates will provide stable storage using [PersistentVolumes](/docs/user-guide/volumes/) provisioned by a 
  PersistentVolume Provisioner.
 
 ```yaml
@@ -106,7 +106,7 @@ spec:
 ### Pod Identity
 StatefulSet Pods have a unique identity that is comprised of an ordinal, a 
 stable network identity, and stable storage. The identity sticks to the Pod, 
-regardless of which node it's (re) scheduled on.
+regardless of which node it's (re)scheduled on.
 
 __Ordinal Index__
 
@@ -141,13 +141,12 @@ Note that Cluster Domain will be set to `cluster.local` unless
 
 __Stable Storage__
 
-Kubernetes creates one [PersistentVolumes](/docs/user-guide/volumes/) for each 
-VolumeClaimTemplate, as specified in the StatefulSet's volumeClaimTemplates field
-In the example above, each Pod will receive a single PersistentVolume with a storage 
-class of `anything` and 1 Gib of provisioned storage. When a Pod is (re) scheduled onto
-a node, its `volumeMounts` mount the PersistentVolumes associated with its 
+Kubernetes creates one [PersistentVolume](/docs/user-guide/volumes/) for each 
+VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume 
+with a storage class of `anything` and 1 Gib of provisioned storage. When a Pod is (re)scheduled 
+onto a node, its `volumeMounts` mount the PersistentVolumes associated with its 
 PersistentVolume Claims. Note that, the PersistentVolumes associated with the 
-Pods' PersistentVolume  Claims are not deleted when the Pods, or StatefulSet are deleted. 
+Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted. 
 This must be done manually.
 
 ### Deployment and Scaling Guarantee
@@ -157,9 +156,9 @@ This must be done manually.
 * Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready. 
 * Before a Pod is terminated, all of its successors must be completely shutdown.
 
-The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged. For further explanation, please refer to [force deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/#deleting-pods).
+The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. This practice is unsafe and strongly discouraged. For further explanation, please refer to [force deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/#deleting-pods).
 
-When the web example above is created, three Pods will be deployed in the order 
+When the nginx example above is created, three Pods will be deployed in the order 
 web-0, web-1, web-2. web-1 will not be deployed before web-0 is 
 [Running and Ready](/docs/user-guide/pod-states), and web-2 will not be deployed until 
 web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Ready, but before