Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.8

* 'master' of https://github.com/kubernetes/kubernetes.github.io: (33 commits) Added a prerequisite to using CoreDNS provider in federation (#5159) Edits "Creating a Deployment" section (#5195) Updating vSphere Cloud Provider Documentation (#5241) Update disruptions.md update OWNERS file Cilium network policy, update link: configure-pod-container -> administer-cluster Update volumes.md (#5214) Update images.md (#5212) fix resource quota redirect Fix link to Pod overview from concepts index fix the command output fix the command output Improve taint and toleration documentation Update deployment.md Update deployment.md Fix invalid internal links in federation doc Update images.md (#5034) Update docker-cli-to-kubectl.md (#5040) Update parallel-processing-expansion.md (#5060) Update cluster-management.md (#5130) ...
2017-09-01 14:49:44 -07:00
parent 895a6074e2 d15b138d2e
commit 5edcbfd1f1
40 changed files with 502 additions and 391 deletions
@@ -1,8 +1,3 @@
 reviewers:
 - a-mccarthy
 - abiogenesis-now
 - bradamant3
 - chenopis
 - cody-clark
 - steveperry-53
 - zacharysarah
@@ -58,6 +58,7 @@ toc:
  - docs/concepts/configuration/overview.md
  - docs/concepts/configuration/manage-compute-resources-container.md
  - docs/concepts/configuration/assign-pod-node.md
  - docs/concepts/configuration/taint-and-toleration.md
  - docs/concepts/configuration/secret.md
  - docs/concepts/configuration/organize-cluster-access-kubeconfig.md
@@ -33,7 +33,7 @@
 /docs/admin/out-of-resource										/docs/tasks/administer-cluster/out-of-resource		301
 /docs/admin/rescheduler											/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods		301
 /docs/admin/resourcequota/limitstorageconsumption				/docs/tasks/administer-cluster/limit-storage-consumption		301
-/docs/admin/resourcequota/walkthrough							/docs/tasks/administer-cluster/apply-resource-quota-limit		301
+/docs/admin/resourcequota/walkthrough							/docs/tasks/administer-cluster/quota-api-object		301
 /docs/admin/static-pods											/docs/tasks/administer-cluster/static-pod		301
 /docs/admin/sysctls												/docs/concepts/cluster-administration/sysctl-cluster		301
 /docs/admin/upgrade-1-6											/docs/tasks/administer-cluster/upgrade-1-6		301
@@ -86,6 +86,7 @@
 /docs/															/docs/home/		301
 /docs/samples													/docs/tutorials/		301
 /docs/tasks/administer-cluster/apply-resource-quota-limit		/docs/tasks/administer-cluster/quota-api-object		301
 /docs/tasks/administer-cluster/assign-pods-nodes				/docs/tasks/configure-pod-container/assign-pods-nodes		301
 /docs/tasks/administer-cluster/overview							/docs/concepts/cluster-administration/cluster-administration-overview		301
 /docs/tasks/administer-cluster/cpu-memory-limit					/docs/tasks/administer-cluster/memory-default-namespace		301
@@ -85,7 +85,7 @@ css: /css/style_buffer.css
    <br><br>
    Plus, unlike with their old system, they could scale things horizontally with one command. "As we rolled it out," Farrelly says, "we could anticipate and just click a button. This allowed us to deal with the demand that our users were placing on the system and easily scale it to handle it."
    <br><br>
-    Another thing they weren’t able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of ‘fingers crossed.’ And this is something that gets run 800,000 times a day, the core of our business. If it doesn’t work, our business doesn’t work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn’t working. This has leveled up our ability to deploy and roll out new changes quickly while reduce&nbsp;risk."
+    Another thing they weren’t able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of ‘fingers crossed.’ And this is something that gets run 800,000 times a day, the core of our business. If it doesn’t work, our business doesn’t work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn’t working. This has leveled up our ability to deploy and roll out new changes quickly while reducing&nbsp;risk."
 </div>
 </section>
@@ -7868,7 +7868,7 @@ Appears In <a href="#pod-v1-core">Pod</a> <a href="#podtemplatespec-v1-core">Pod
 </tr>
 <tr>
 <td>tolerations <br /> <em><a href="#toleration-v1-core">Toleration</a> array</em></td>
-<td>If specified, the pod&#39;s tolerations.</td>
+<td>If specified, the pod&#39;s tolerations. More info: <a href="https://kubernetes.io/docs/concepts/configuration/taint-and-toleration">https://kubernetes.io/docs/concepts/configuration/taint-and-toleration</a></td>
 </tr>
 <tr>
 <td>volumes <br /> <em><a href="#volume-v1-core">Volume</a> array</em></td>
@@ -7964,7 +7964,7 @@ Appears In:
 </tr>
 <tr>
 <td>tolerations <br /> <em><a href="#toleration-v1-core">Toleration</a> array</em></td>
-<td>If specified, the pod&#39;s tolerations.</td>
+<td>If specified, the pod&#39;s tolerations. More info: <a href="https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/">https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/</a></td>
 </tr>
 <tr>
 <td>volumes <br /> <em><a href="#volume-v1-core">Volume</a> array</em>  <br /> <strong>patch type</strong>: <em>merge</em>  <br /> <strong>patch merge key</strong>: <em>name</em></td>
@@ -171,7 +171,7 @@ Starting in Kubernetes 1.6, the NodeController is also responsible for evicting
 pods that are running on nodes with `NoExecute` taints, when the pods do not tolerate
 the taints. Additionally, as an alpha feature that is disabled by default, the
 NodeController is responsible for adding taints corresponding to node problems like
-node unreachable or not ready. See [this documentation](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)
+node unreachable or not ready. See [this documentation](/docs/concepts/configuration/taint-and-toleration)
 for details about `NoExecute` taints and the alpha feature.
 ### Self-Registration of Nodes
@@ -38,7 +38,7 @@ why you might want multiple clusters are:
 * Scalability: There are scalability limits to a single kubernetes cluster (this
  should not be the case for most users. For more details:
  [Kubernetes Scaling and Performance Goals](https://git.k8s.io/community/sig-scalability/goals.md)).
-* [Hybrid cloud](###hybrid-cloud-capabilities): You can have multiple clusters on different cloud providers or
+* [Hybrid cloud](#hybrid-cloud-capabilities): You can have multiple clusters on different cloud providers or
  on-premises data centers.
 ### Caveats
@@ -70,7 +70,7 @@ register each cluster's API endpoint and credentials with your
 Federation API Server (See the
 [federation admin guide](/docs/admin/federation/) for details).
-Thereafter, your [API resources](##api-resources) can span different clusters
+Thereafter, your [API resources](#api-resources) can span different clusters
 and cloud providers.
 ## Setting up federation
@@ -118,4 +118,5 @@ spec:
 **Note**: a pod with the _unsafe_ sysctls specified above will fail to launch on
 any node which has not enabled those two _unsafe_ sysctls explicitly. As with
 _node-level_ sysctls it is recommended to use [_taints and toleration_
-feature](/docs/user-guide/kubectl/v1.6/#taint) or [labels on nodes](/docs/concepts/configuration/assign-pod-node/) to schedule those pods onto the right nodes.
+feature](/docs/user-guide/kubectl/v1.6/#taint) or [taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
 to schedule those pods onto the right nodes.
@@ -298,231 +298,5 @@ Highly Available database statefulset has one master and three replicas, one may
 For more information on inter-pod affinity/anti-affinity, see the design doc
 [here](https://git.k8s.io/community/contributors/design-proposals/podaffinity.md).
-## Taints and tolerations (beta feature)
+You may want to check [Taints](/docs/concepts/configuration/taint-and-toleration/)
-
+as well, which allow a *node* to *repel* a set of pods.
 Node affinity, described earlier, is a property of *pods* that *attracts* them to a set
 of nodes (either as a preference or a hard requirement). Taints are the opposite --
 they allow a *node* to *repel* a set of pods.
 Taints and tolerations work together to ensure that pods are not scheduled
 onto inappropriate nodes. One or more taints are applied to a node; this
 marks that the node should not accept any pods that do not tolerate the taints.
 Tolerations are applied to pods, and allow (but do not require) the pods to schedule
 onto nodes with matching taints.
 You add a taint to a node using [kubectl taint](/docs/user-guide/kubectl/v1.7/#taint).
 For example,
 ```shell
 kubectl taint nodes node1 key=value:NoSchedule
 ```
 places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`.
 This means that no pod will be able to schedule onto `node1` unless it has a matching toleration.
 You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the
 taint created by the `kubectl taint` line above, and thus a pod with either toleration would be able
 to schedule onto `node1`:
 ```yaml
 tolerations:
 - key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"
 ```
 ```yaml
 tolerations:
 - key: "key"
  operator: "Exists"
  effect: "NoSchedule"
 ```
 A toleration "matches" a taint if the keys are the same and the effects are the same, and:
 * the `operator` is `Exists` (in which case no `value` should be specified), or
 * the `operator` is `Equal` and the `value`s are equal
 `Operator` defaults to `Equal` if not specified.
 **NOTE:** There are two special cases:
 * An empty `key` with operator `Exists` matches all keys, values and effects which means this
 will tolerate everything.
 ```yaml
 tolerations:
 - operator: "Exists"
 ```
 * An empty `effect` matches all effects with key `key`.
 ```yaml
 tolerations:
 - key: "key"
  operator: "Exists"
 ```
 The above example used `effect` of `NoSchedule`. Alternatively, you can use `effect` of `PreferNoSchedule`.
 This is a "preference" or "soft" version of `NoSchedule` -- the system will *try* to avoid placing a
 pod that does not tolerate the taint on the node, but it is not required. The third kind of `effect` is
 `NoExecute`, described later.
 You can put multiple taints on the same node and multiple tolerations on the same pod.
 The way Kubernetes processes multiple taints and tolerations is like a filter: start
 with all of a node's taints, then ignore the ones for which the pod has a matching toleration; the
 remaining un-ignored taints have the indicated effects on the pod. In particular,
 * if there is at least one un-ignored taint with effect `NoSchedule` then Kubernetes will not schedule
 the pod onto that node
 * if there is no un-ignored taint with effect `NoSchedule` but there is at least one un-ignored taint with
 effect `PreferNoSchedule` then Kubernetes will *try* to not schedule the pod onto the node
 * if there is at least one un-ignored taint with effect `NoExecute` then the pod will be evicted from
 the node (if it is already running on the node), and will not be
 scheduled onto the node (if it is not yet running on the node).
 For example, imagine you taint a node like this
 ```shell
 kubectl taint nodes node1 key1=value1:NoSchedule
 kubectl taint nodes node1 key1=value1:NoExecute
 kubectl taint nodes node1 key2=value2:NoSchedule
 ```
 And a pod has two tolerations:
 ```yaml
 tolerations:
 - key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
 - key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
 ```
 In this case, the pod will not be able to schedule onto the node, because there is no
 toleration matching the third taint. But it will be able to continue running if it is
 already running on the node when the taint is added, because the third taint is the only
 one of the three that is not tolerated by the pod.
 Normally, if a taint with effect `NoExecute` is added to a node, then any pods that do
 not tolerate the taint will be evicted immediately, and any pods that do tolerate the
 taint will never be evicted. However, a toleration with `NoExecute` effect can specify
 an optional `tolerationSeconds` field that dictates how long the pod will stay bound
 to the node after the taint is added. For example,
 ```yaml
 tolerations:
 - key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600
 ```
 means that if this pod is running and a matching taint is added to the node, then
 the pod will stay bound to the node for 3600 seconds, and then be evicted. If the
 taint is removed before that time, the pod will not be evicted.
 ### Example use cases
 Taints and tolerations are a flexible way to steer pods away from nodes or evict
 pods that shouldn't be running. A few of the use cases are
 * **dedicated nodes**: If you want to dedicate a set of nodes for exclusive use by
 a particular set of users, you can add a taint to those nodes (say,
 `kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding
 toleration to their pods (this would be done most easily by writing a custom
 [admission controller](/docs/admin/admission-controllers/)).
 The pods with the tolerations will then be allowed to use the tainted (dedicated) nodes as
 well as any other nodes in the cluster. If you want to dedicate the nodes to them *and*
 ensure they *only* use the dedicated nodes, then you should additionally add a label similar
 to the taint to the same set of nodes (e.g. `dedicated=groupName`), and the admission
 controller should additionally add a node affinity to require that the pods can only schedule
 onto nodes labeled with `dedicated=groupName`.
 * **nodes with special hardware**: In a cluster where a small subset of nodes have specialized
 hardware (for example GPUs), it is desirable to keep pods that don't need the specialized
 hardware off of those nodes, thus leaving room for later-arriving pods that do need the
 specialized hardware. This can be done by tainting the nodes that have the specialized
 hardware (e.g. `kubectl taint nodes nodename special=true:NoSchedule` or
 `kubectl taint nodes nodename special=true:PreferNoSchedule`) and adding a corresponding
 toleration to pods that use the special hardware. As in the dedicated nodes use case,
 it is probably easiest to apply the tolerations using a custom
 [admission controller](/docs/admin/admission-controllers/)).
 For example, the admission controller could use
 some characteristic(s) of the pod to determine that the pod should be allowed to use
 the special nodes and hence the admission controller should add the toleration.
 To ensure that the pods that need
 the special hardware *only* schedule onto the nodes that have the special hardware, you will need some
 additional mechanism, e.g. you could represent the special resource using
 [opaque integer resources](/docs/concepts/configuration/manage-compute-resources-container/#opaque-integer-resources-alpha-feature)
 and request it as a resource in the PodSpec, or you could label the nodes that have
 the special hardware and use node affinity on the pods that need the hardware.
 * **per-pod-configurable eviction behavior when there are node problems (alpha feature)**,
 which is described in the next section.
 ### Per-pod-configurable eviction behavior when there are node problems (alpha feature)
 Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already
 running on the node as follows
 * pods that do not tolerate the taint are evicted immediately
 * pods that tolerate the taint without specifying `tolerationSeconds` in
   their toleration specification remain bound forever
 * pods that tolerate the taint with a specified `tolerationSeconds` remain
   bound for the specified amount of time
 The above behavior is a beta feature. In addition, Kubernetes 1.6 has alpha
 support for representing node problems (currently only "node unreachable" and
 "node not ready", corresponding to the NodeCondition "Ready" being "Unknown" or
 "False" respectively) as taints. When the `TaintBasedEvictions` alpha feature
 is enabled (you can do this by including `TaintBasedEvictions=true` in `--feature-gates`, such as
 `--feature-gates=FooBar=true,TaintBasedEvictions=true`), the taints are automatically
 added by the NodeController and the normal logic for evicting pods from nodes
 based on the Ready NodeCondition is disabled.
 (Note: To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
 behavior of pod evictions due to node problems, the system actually adds the taints
 in a rate-limited way. This prevents massive pod evictions in scenarios such
 as the master becoming partitioned from the nodes.)
 This alpha feature, in combination with `tolerationSeconds`, allows a pod
 to specify how long it should stay bound to a node that has one or both of these problems.
 For example, an application with a lot of local state might want to stay
 bound to node for a long time in the event of network partition, in the hope
 that the partition will recover and thus the pod eviction can be avoided.
 The toleration the pod would use in that case would look like
 ```yaml
 tolerations:
 - key: "node.alpha.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 6000
 ```
 (For the node not ready case, change the key to `node.alpha.kubernetes.io/notReady`.)
 Note that Kubernetes automatically adds a toleration for
 `node.alpha.kubernetes.io/notReady` with `tolerationSeconds=300`
 unless the pod configuration provided
 by the user already has a toleration for `node.alpha.kubernetes.io/notReady`.
 Likewise it adds a toleration for
 `node.alpha.kubernetes.io/unreachable` with `tolerationSeconds=300`
 unless the pod configuration provided
 by the user already has a toleration for `node.alpha.kubernetes.io/unreachable`.
 These automatically-added tolerations ensure that
 the default pod behavior of remaining bound for 5 minutes after one of these
 problems is detected is maintained.
 The two default tolerations are added by the [DefaultTolerationSeconds
 admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds).
 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pods are created with
 `NoExecute` tolerations for `node.alpha.kubernetes.io/unreachable` and `node.alpha.kubernetes.io/notReady`
 with no `tolerationSeconds`. This ensures that DaemonSet pods are never evicted due
 to these problems, which matches the behavior when this feature is disabled.
@@ -137,7 +137,7 @@ the option `-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if
 #### Decoding a Secret
-Get back the secret created in the previous section:
+Secrets can be retrieved via the `kubectl get secret` command. For example, to retrieve the secret created in the previous section:
 ```shell
 $ kubectl get secret mysecret -o yaml
@@ -0,0 +1,257 @@
 ---
 approvers:
 - davidopp
 - kevin-wangzefeng
 - bsalamat
 title: Taints and Tolerations
 ---
 Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
 is a property of *pods* that *attracts* them to a set of nodes (either as a
 preference or a hard requirement). Taints are the opposite -- they allow a
 *node* to *repel* a set of pods.
 Taints and tolerations work together to ensure that pods are not scheduled
 onto inappropriate nodes. One or more taints are applied to a node; this
 marks that the node should not accept any pods that do not tolerate the taints.
 Tolerations are applied to pods, and allow (but do not require) the pods to schedule
 onto nodes with matching taints.
 ## Concepts
 You add a taint to a node using [kubectl taint](/docs/user-guide/kubectl/v1.7/#taint).
 For example,
 ```shell
 kubectl taint nodes node1 key=value:NoSchedule
 ```
 places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`.
 This means that no pod will be able to schedule onto `node1` unless it has a matching toleration.
 You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the
 taint created by the `kubectl taint` line above, and thus a pod with either toleration would be able
 to schedule onto `node1`:
 ```yaml
 tolerations:
 - key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"
 ```
 ```yaml
 tolerations:
 - key: "key"
  operator: "Exists"
  effect: "NoSchedule"
 ```
 A toleration "matches" a taint if the keys are the same and the effects are the same, and:
 * the `operator` is `Exists` (in which case no `value` should be specified), or
 * the `operator` is `Equal` and the `value`s are equal
 `Operator` defaults to `Equal` if not specified.
 **NOTE:** There are two special cases:
 * An empty `key` with operator `Exists` matches all keys, values and effects which means this
 will tolerate everything.
 ```yaml
 tolerations:
 - operator: "Exists"
 ```
 * An empty `effect` matches all effects with key `key`.
 ```yaml
 tolerations:
 - key: "key"
  operator: "Exists"
 ```
 The above example used `effect` of `NoSchedule`. Alternatively, you can use `effect` of `PreferNoSchedule`.
 This is a "preference" or "soft" version of `NoSchedule` -- the system will *try* to avoid placing a
 pod that does not tolerate the taint on the node, but it is not required. The third kind of `effect` is
 `NoExecute`, described later.
 You can put multiple taints on the same node and multiple tolerations on the same pod.
 The way Kubernetes processes multiple taints and tolerations is like a filter: start
 with all of a node's taints, then ignore the ones for which the pod has a matching toleration; the
 remaining un-ignored taints have the indicated effects on the pod. In particular,
 * if there is at least one un-ignored taint with effect `NoSchedule` then Kubernetes will not schedule
 the pod onto that node
 * if there is no un-ignored taint with effect `NoSchedule` but there is at least one un-ignored taint with
 effect `PreferNoSchedule` then Kubernetes will *try* to not schedule the pod onto the node
 * if there is at least one un-ignored taint with effect `NoExecute` then the pod will be evicted from
 the node (if it is already running on the node), and will not be
 scheduled onto the node (if it is not yet running on the node).
 For example, imagine you taint a node like this
 ```shell
 kubectl taint nodes node1 key1=value1:NoSchedule
 kubectl taint nodes node1 key1=value1:NoExecute
 kubectl taint nodes node1 key2=value2:NoSchedule
 ```
 And a pod has two tolerations:
 ```yaml
 tolerations:
 - key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
 - key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
 ```
 In this case, the pod will not be able to schedule onto the node, because there is no
 toleration matching the third taint. But it will be able to continue running if it is
 already running on the node when the taint is added, because the third taint is the only
 one of the three that is not tolerated by the pod.
 Normally, if a taint with effect `NoExecute` is added to a node, then any pods that do
 not tolerate the taint will be evicted immediately, and any pods that do tolerate the
 taint will never be evicted. However, a toleration with `NoExecute` effect can specify
 an optional `tolerationSeconds` field that dictates how long the pod will stay bound
 to the node after the taint is added. For example,
 ```yaml
 tolerations:
 - key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600
 ```
 means that if this pod is running and a matching taint is added to the node, then
 the pod will stay bound to the node for 3600 seconds, and then be evicted. If the
 taint is removed before that time, the pod will not be evicted.
 ## Example Use Cases
 Taints and tolerations are a flexible way to steer pods *away* from nodes or evict
 pods that shouldn't be running. A few of the use cases are
 * **Dedicated Nodes**: If you want to dedicate a set of nodes for exclusive use by
 a particular set of users, you can add a taint to those nodes (say,
 `kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding
 toleration to their pods (this would be done most easily by writing a custom
 [admission controller](/docs/admin/admission-controllers/)).
 The pods with the tolerations will then be allowed to use the tainted (dedicated) nodes as
 well as any other nodes in the cluster. If you want to dedicate the nodes to them *and*
 ensure they *only* use the dedicated nodes, then you should additionally add a label similar
 to the taint to the same set of nodes (e.g. `dedicated=groupName`), and the admission
 controller should additionally add a node affinity to require that the pods can only schedule
 onto nodes labeled with `dedicated=groupName`.
 * **Nodes with Special Hardware**: In a cluster where a small subset of nodes have specialized
 hardware (for example GPUs), it is desirable to keep pods that don't need the specialized
 hardware off of those nodes, thus leaving room for later-arriving pods that do need the
 specialized hardware. This can be done by tainting the nodes that have the specialized
 hardware (e.g. `kubectl taint nodes nodename special=true:NoSchedule` or
 `kubectl taint nodes nodename special=true:PreferNoSchedule`) and adding a corresponding
 toleration to pods that use the special hardware. As in the dedicated nodes use case,
 it is probably easiest to apply the tolerations using a custom
 [admission controller](/docs/admin/admission-controllers/)).
 For example, the admission controller could use
 some characteristic(s) of the pod to determine that the pod should be allowed to use
 the special nodes and hence the admission controller should add the toleration.
 To ensure that the pods that need
 the special hardware *only* schedule onto the nodes that have the special hardware, you will need some
 additional mechanism, e.g. you could represent the special resource using
 [opaque integer resources](/docs/concepts/configuration/manage-compute-resources-container/#opaque-integer-resources-alpha-feature)
 and request it as a resource in the PodSpec, or you could label the nodes that have
 the special hardware and use node affinity on the pods that need the hardware.
 * **Taint based Evictions (alpha feature)**: A per-pod-configurable eviction behavior
 when there are node problems, which is described in the next section.
 ## Taint based Evictions
 Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already
 running on the node as follows
 * pods that do not tolerate the taint are evicted immediately
 * pods that tolerate the taint without specifying `tolerationSeconds` in
   their toleration specification remain bound forever
 * pods that tolerate the taint with a specified `tolerationSeconds` remain
   bound for the specified amount of time
 The above behavior is a beta feature. In addition, Kubernetes 1.6 has alpha
 support for representing node problems. In other words, the node controller
 automatically taints a node when certain condition is true. The builtin taints
 currently include:
 * `node.alpha.kubernetes.io/notReady`: Node is not ready. This corresponds to
   the NodeCondition `Ready` being "`False`".
 * `node.alpha.kubernetes.io/unreachable`: Node is unreachable from the node
   controller. This corresponds to the NodeCondition `Ready` being "`Unknown`".
 * `node.kubernetes.io/outOfDisk`: Node becomes out of disk.
 * `node.kubernetes.io/memoryPressure`: Node has memory pressure.
 * `node.kubernetes.io/diskPressure`: Node has disk pressure.
 * `node.kubernetes.io/networkUnavailable`: Node's network is unavailable.
 * `node.cloudprovider.kubernetes.io/uninitialized`: When kubelet is started
   with "external" cloud provider, it sets this taint on a node to mark it
   as unusable. When a controller from the cloud-controller-manager initializes
   this node, kubelet removes this taint.
 When the `TaintBasedEvictions` alpha feature is enabled (you can do this by
 including `TaintBasedEvictions=true` in `--feature-gates`, such as
 `--feature-gates=FooBar=true,TaintBasedEvictions=true`), the taints are automatically
 added by the NodeController (or kubelet) and the normal logic for evicting pods from nodes
 based on the Ready NodeCondition is disabled.
 (Note: To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
 behavior of pod evictions due to node problems, the system actually adds the taints
 in a rate-limited way. This prevents massive pod evictions in scenarios such
 as the master becoming partitioned from the nodes.)
 This alpha feature, in combination with `tolerationSeconds`, allows a pod
 to specify how long it should stay bound to a node that has one or both of these problems.
 For example, an application with a lot of local state might want to stay
 bound to node for a long time in the event of network partition, in the hope
 that the partition will recover and thus the pod eviction can be avoided.
 The toleration the pod would use in that case would look like
 ```yaml
 tolerations:
 - key: "node.alpha.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 6000
 ```
 Note that Kubernetes automatically adds a toleration for
 `node.alpha.kubernetes.io/notReady` with `tolerationSeconds=300`
 unless the pod configuration provided
 by the user already has a toleration for `node.alpha.kubernetes.io/notReady`.
 Likewise it adds a toleration for
 `node.alpha.kubernetes.io/unreachable` with `tolerationSeconds=300`
 unless the pod configuration provided
 by the user already has a toleration for `node.alpha.kubernetes.io/unreachable`.
 These automatically-added tolerations ensure that
 the default pod behavior of remaining bound for 5 minutes after one of these
 problems is detected is maintained.
 The two default tolerations are added by the [DefaultTolerationSeconds
 admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds).
 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pods are created with
 `NoExecute` tolerations for the following taints with no `tolerationSeconds`:
  * `node.alpha.kubernetes.io/unreachable`
  * `node.alpha.kubernetes.io/notReady`
  * `node.kubernetes.io/memoryPressure`
  * `node.kubernetes.io/diskPressure`
  * `node.kubernetes.io/outOfDisk` (*only for critical pods*)
 This ensures that DaemonSet pods are never evicted due to these problems,
 which matches the behavior when this feature is disabled.
@@ -113,6 +113,7 @@ You first need to create a registry and generate credentials, complete documenta
 the [Azure container registry documentation](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli).
 Once you have created your container registry, you will use the following credentials to login:
   * `DOCKER_USER` : service principal, or admin username
   * `DOCKER_PASSWORD`: service principal password, or admin user password
   * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io`
@@ -263,7 +264,7 @@ type: kubernetes.io/dockerconfigjson
 ```
 If you get the error message `error: no objects passed to create`, it may mean the base64 encoded string is invalid.
-If you get an error message like `Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...` it means
+If you get an error message like `Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`, it means
 the data was successfully un-base64 encoded, but could not be parsed as a `.docker/config.json` file.
 #### Referring to an imagePullSecrets on a Pod
@@ -300,26 +301,26 @@ common use cases and suggested solutions.
 1. Cluster running only non-proprietary (e.g. open-source) images.  No need to hide images.
   - Use public images on the Docker hub.
-     - no configuration required
+     - No configuration required.
-     - on GCE/GKE, a local mirror is automatically used for improved speed and availability
+     - On GCE/GKE, a local mirror is automatically used for improved speed and availability.
 1. Cluster running some proprietary images which should be hidden to those outside the company, but
   visible to all cluster users.
-   - Use a hosted private [Docker registry](https://docs.docker.com/registry/)
+   - Use a hosted private [Docker registry](https://docs.docker.com/registry/).
-     - may be hosted on the [Docker Hub](https://hub.docker.com/account/signup/), or elsewhere.
+     - It may be hosted on the [Docker Hub](https://hub.docker.com/account/signup/), or elsewhere.
-     - manually configure .docker/config.json on each node as described above
+     - Manually configure .docker/config.json on each node as described above.
   - Or, run an internal private registry behind your firewall with open read access.
-     - no Kubernetes configuration required
+     - No Kubernetes configuration is required.
   - Or, when on GCE/GKE, use the project's Google Container Registry.
-     - will work better with cluster autoscaling than manual node configuration
+     - It will work better with cluster autoscaling than manual node configuration.
   - Or, on a cluster where changing the node configuration is inconvenient, use `imagePullSecrets`.
-1. Cluster with a proprietary images, a few of which require stricter access control
+1. Cluster with a proprietary images, a few of which require stricter access control.
-   - ensure [AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages) is active, otherwise, all Pods potentially have access to all images
+   - Ensure [AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages) is active. Otherwise, all Pods potentially have access to all images.
   - Move sensitive data into a "Secret" resource, instead of packaging it in an image.
-1. A multi-tenant cluster where each tenant needs own private registry
+1. A multi-tenant cluster where each tenant needs own private registry.
-   - ensure [AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages) is active, otherwise, all Pods of all tenants potentially have access to all images
+   - Ensure [AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages) is active. Otherwise, all Pods of all tenants potentially have access to all images.
-   - run a private registry with authorization required.
+   - Run a private registry with authorization required.
-   - generate registry credential for each tenant, put into secret, and populate secret to each tenant namespace.
+   - Generate registry credential for each tenant, put into secret, and populate secret to each tenant namespace.
-   - tenant adds that secret to imagePullSecrets of each namespace.
+   - The tenant adds that secret to imagePullSecrets of each namespace.
 {% endcapture %}
@@ -21,18 +21,18 @@ Kubernetes contains a number of abstractions that represent the state of your sy
 The basic Kubernetes objects include:
-* [Pod](/docs/concepts/abstractions/pod/)
+* [Pod](/docs/concepts/workloads/pods/pod-overview/)
-* Service
+* [Service](/docs/concepts/services-networking/service/)
-* Volume
+* [Volume](/docs/concepts/storage/volumes/)
-* Namespace
+* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
 In addition, Kubernetes contains a number of higher-level abstractions called Controllers. Controllers build upon the basic objects, and provide additional functionality and convenience features. They include:
-* ReplicaSet
+* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
-* Deployment
+* [Deployment](/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/)
+* [StatefulSet](/docs/concepts/workloads/controllers/statefulsets/)
-* DaemonSet
+* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
-* Job
+* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
 ## Kubernetes Control Plane
@@ -99,9 +99,10 @@ exists as long as that Pod is running on that node.  As the name says, it is
 initially empty.  Containers in the pod can all read and write the same
 files in the `emptyDir` volume, though that volume can be mounted at the same
 or different paths in each container.  When a Pod is removed from a node for
-any reason, the data in the `emptyDir` is deleted forever.  NOTE: a container
+any reason, the data in the `emptyDir` is deleted forever.  
-crashing does *NOT* remove a pod from a node, so the data in an `emptyDir`
+
-volume is safe across container crashes.
+**Note:** a container crashing does *NOT* remove a pod from a node, so the data in an `emptyDir` volume is safe across container crashes.
 {: .note}
 Some uses for an `emptyDir` are:
@@ -189,8 +190,8 @@ Disk](http://cloud.google.com/compute/docs/disks) into your pod.  Unlike
 preserved and the volume is merely unmounted.  This means that a PD can be
 pre-populated with data, and that data can be "handed off" between pods.
-__Important: You must create a PD using `gcloud` or the GCE API or UI
+**Important:** You must create a PD using `gcloud` or the GCE API or UI before you can use it.
-before you can use it__
+{: .caution}
 There are some restrictions when using a `gcePersistentDisk`:
@@ -245,8 +246,8 @@ volume are preserved and the volume is merely unmounted.  This means that an
 EBS volume can be pre-populated with data, and that data can be "handed off"
 between pods.
-__Important: You must create an EBS volume using `aws ec2 create-volume` or
+**Important:** You must create an EBS volume using `aws ec2 create-volume` or the AWS API before you can use it.
-the AWS API before you can use it__
+{: .caution}
 There are some restrictions when using an awsElasticBlockStore volume:
@@ -259,7 +260,7 @@ There are some restrictions when using an awsElasticBlockStore volume:
 Before you can use an EBS volume with a pod, you need to create it.
 ```shell
-aws ec2 create-volume --availability-zone eu-west-1a --size 10 --volume-type gp2
+aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2
 ```
 Make sure the zone matches the zone you brought up your cluster in.  (And also check that the size and EBS volume
@@ -296,8 +297,8 @@ unmounted.  This means that an 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.
-__Important: You must have your own NFS server running with the share exported
+**Important:** You must have your own NFS server running with the share exported before you can use it.
-before you can use it__
+{: .caution}
 See the [NFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/nfs) for more details.
@@ -309,8 +310,8 @@ contents of an `iscsi` volume are preserved and the volume is merely
 unmounted.  This means that an iscsi volume can be pre-populated with data, and
 that data can be "handed off" between pods.
-__Important: You must have your own iSCSI server running with the volume
+**Important:** You must have your own iSCSI server running with the volume created before you can use it.
-created before you can use it__
+{: .caution}
 A feature of iSCSI is that it can be mounted as read-only by multiple consumers
 simultaneously.  This means that you can pre-populate a volume with your dataset
@@ -327,9 +328,8 @@ You can specify single or multiple target World Wide Names using the parameter
 `targetWWNs` in your volume configuration. If multiple WWNs are specified,
 targetWWNs expect that those WWNs are from multi-path connections.
-__Important: You must configure FC SAN Zoning to allocate and mask those
+**Important:** You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts can access them.
-LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts
+{: .caution}
 can access them__
 See the [FC example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/fibre_channel) for more details.
@@ -344,7 +344,8 @@ CLI or by using the Flocker API. If the dataset already exists it will be
 reattached by Flocker to the node that the pod is scheduled. This means data
 can be "handed off" between pods as required.
-__Important: You must have your own Flocker installation running before you can use it__
+**Important:** You must have your own Flocker installation running before you can use it.
 {: .caution}
 See the [Flocker example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/flocker) for more details.
@@ -358,8 +359,8 @@ means that a glusterfs volume can be pre-populated with data, and that data can
 be "handed off" between pods.  GlusterFS can be mounted by multiple writers
 simultaneously.
-__Important: You must have your own GlusterFS installation running before you
+**Important:** You must have your own GlusterFS installation running before you can use it.
-can use it__
+{: .caution}
 See the [GlusterFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/glusterfs) for more details.
@@ -372,8 +373,8 @@ a `rbd` volume are preserved and the volume is merely unmounted.  This
 means that a RBD volume can be pre-populated with data, and that data can
 be "handed off" between pods.
-__Important: You must have your own Ceph installation running before you
+**Important:** You must have your own Ceph installation running before you can use RBD.
-can use RBD__
+{: .caution}
 A feature of RBD is that it can be mounted as read-only by multiple consumers
 simultaneously.  This means that you can pre-populate a volume with your dataset
@@ -392,8 +393,8 @@ unmounted.  This means that a CephFS volume can be pre-populated with data, and
 that data can be "handed off" between pods.  CephFS can be mounted by multiple
 writers simultaneously.
-__Important: You must have your own Ceph server running with the share exported
+**Important:** You must have your own Ceph server running with the share exported before you can use it.
-before you can use it__
+{: .caution}
 See the [CephFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/cephfs/) for more details.
@@ -433,8 +434,8 @@ use by pods without coupling to Kubernetes directly.  `secret` volumes are
 backed by tmpfs (a RAM-backed filesystem) so they are never written to
 non-volatile storage.
-__Important: You must create a secret in the Kubernetes API before you can use
+**Important:** You must create a secret in the Kubernetes API before you can use it.
-it__
+{: .caution}
 Secrets are described in more detail [here](/docs/user-guide/secrets).
@@ -467,7 +468,7 @@ Currently, the following types of volume sources can be projected:
 All sources are required to be in the same namespace as the pod. For more details, see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/all-in-one-volume.md).
-#### Example pod with a secret, a downward API, and a configmap
+#### Example pod with a secret, a downward API, and a configmap.
 ```yaml
 apiVersion: v1
@@ -507,7 +508,7 @@ spec:
              path: my-group/my-config
 ```
-#### Example pod with multiple secrets with a non-default permission mode set
+#### Example pod with multiple secrets with a non-default permission mode set.
 ```yaml
 apiVersion: v1
@@ -554,30 +555,31 @@ A `FlexVolume` enables users to mount vendor volumes into a pod. It expects vend
 drivers are installed in the volume plugin path on each kubelet node. This is
 an alpha feature and may change in future.
-More details are in [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/flexvolume/README.md)
+More details are in [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/flexvolume/README.md).
 ### AzureFileVolume
 A `AzureFileVolume` is used to mount a Microsoft Azure File Volume (SMB 2.1 and 3.0)
 into a Pod.
-More details can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/azure_file/README.md)
+More details can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/azure_file/README.md).
 ### AzureDiskVolume
 A `AzureDiskVolume` is used to mount a Microsoft Azure [Data Disk](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/) into a Pod.
-More details can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/azure_disk/README.md)
+More details can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/azure_disk/README.md).
 ### vsphereVolume
-__Prerequisite: Kubernetes with vSphere Cloud Provider configured.
+**Prerequisite:** Kubernetes with vSphere Cloud Provider configured. For cloudprovider configuration please refer [vSphere getting started guide](/docs/getting-started-guides/vsphere/).
-For cloudprovider configuration please refer [vSphere getting started guide](/docs/getting-started-guides/vsphere/).__
+{: .note}
 A `vsphereVolume` is used to mount a vSphere VMDK Volume into your Pod.  The contents
 of a volume are preserved when it is unmounted. It supports both VMFS and VSAN datastore.
-__Important: You must create VMDK using one of the following method before using with POD.__
+**Important:** You must create VMDK using one of the following method before using with POD.
 {: .caution}
 #### Creating a VMDK volume
@@ -631,8 +633,8 @@ More examples can be found [here](https://git.k8s.io/kubernetes/examples/volumes
 A `Quobyte` volume allows an existing [Quobyte](http://www.quobyte.com) volume to be mounted into your pod.
-__Important: You must have your own Quobyte setup running with the volumes created
+**Important:** You must have your own Quobyte setup running with the volumes created before you can use it.
-before you can use it__
+{: .caution}
 See the [Quobyte example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/quobyte) for more details.
@@ -664,9 +666,10 @@ spec:
      fsType: "<fs-type>"
 ```
-__Important: Make sure you have an existing PortworxVolume with name `pxvol` before using it in the pod__
+**Important:** Make sure you have an existing PortworxVolume with name `pxvol` before using it in the pod.
 {: .caution}
-More details and examples can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/portworx/README.md)
+More details and examples can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/portworx/README.md).
 ### ScaleIO
 ScaleIO is a software-based storage platform that can use existing hardware to create clusters of scalable
@@ -674,8 +677,8 @@ shared block networked storage.  The ScaleIO volume plugin allows deployed pods
 volumes (or it can dynamically provision new volumes for persistent volume claims, see
 [ScaleIO Persistent Volumes](/docs/user-guide/persistent-volumes/#scaleio)).
-__Important: You must have an existing ScaleIO cluster already setup and running with the volumes created
+**Important:** You must have an existing ScaleIO cluster already setup and running with the volumes created before you can use them.
-before you can use them__
+{: .caution}
 The following is an example pod configuration with ScaleIO:
@@ -713,7 +716,8 @@ At its core, StorageOS provides block storage to containers, accessible via a fi
 The StorageOS container requires 64-bit Linux and has no additional dependencies.  A free developer licence is available.
-__Important: You must run the StorageOS container on each node that wants to access StorageOS volumes or that will contribute storage capacity to the pool.  For installation instructions, consult the [StorageOS documentation](https://docs.storageos.com)__
+**Important:** You must run the StorageOS container on each node that wants to access StorageOS volumes or that will contribute storage capacity to the pool.  For installation instructions, consult the [StorageOS documentation](https://docs.storageos.com).
 {: .caution}
 ```yaml
 apiVersion: v1
@@ -791,11 +795,11 @@ spec:
      path: /mnt/disks/ssd1
 ```
-Note that local PersistentVolume cleanup and deletion requires manual
+**Note:** The local PersistentVolume cleanup and deletion requires manual intervention without the external provisioner.
-intervention without the external provisioner.
+{: .note}
 For details on the `local` volume type, see the [Local Persistent Storage
-user guide](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume)
+user guide](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume).
 ## Using subPath
@@ -27,84 +27,106 @@ The following are typical use cases for Deployments:
 * [Create a Deployment to rollout a ReplicaSet](#creating-a-deployment). The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
 * [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
 * [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
-* [Scale up the Deployment to facilitate more load.](#scaling-a-deployment)
+* [Scale up the Deployment to facilitate more load](#scaling-a-deployment).
 * [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
-* [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck
+* [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck.
-* [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore
+* [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore.
 ## Creating a Deployment
-Here is an example Deployment. It creates a ReplicaSet to bring up three nginx Pods.
+The following is an example of a Deployment. It creates a ReplicaSet to bring up three `nginx` Pods:
 {% include code.html language="yaml" file="nginx-deployment.yaml" ghlink="/docs/concepts/workloads/controllers/nginx-deployment.yaml" %}
-Run the example by downloading the example file and then running this command:
+In this example:
 * A Deployment named `nginx` is created.
 * The `nginx` Deployment creates three replicated Pods.
 * The Pods are created from the `template` field.
 The `template` field contains the following instructions:
 * Create one container in each Pod.
 * Label the container `app: nginx`.
 * Run the [Docker Hub](https://hub.docker.com) image `nginx` at version `1.7.9`.
 * Open port `80` so that the container can send and accept traffic.
 To create this Deployment, run the following command:
 ```shell
-$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
+kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master/docs/concepts/workloads/controllers/nginx-deployment.yaml
 deployment "nginx-deployment" created
 ```
-Setting the kubectl flag `--record` to `true` allows you to record current command in the annotations of
+Note: You can append `--record` to this command to record the current command in the annotations of
-the resources being created or updated. It is useful for future introspection: for example, to see the
+the created or updated resource. This is useful for future review, such as investigating which
-commands executed in each Deployment revision.
+commands were executed in each Deployment revision.
-Then running `get` immediately will give:
+Next, run `kubectl get deployments`. The output is similar to the following:
 ```shell
 $ kubectl get deployments
 NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
 nginx-deployment   3         0         0            0           1s
 ```
-This indicates that the Deployment's number of desired replicas is 3 (according to deployment's `.spec.replicas`),
+When you inspect the Deployments in your cluster, the following fields are displayed:
 the number of current replicas (`.status.replicas`) is 0, the number of up-to-date replicas (`.status.updatedReplicas`)
 is 0, and the number of available replicas (`.status.availableReplicas`) is also 0.
-To see the Deployment rollout status, run:
+* `NAME` lists the names of the Deployments in the cluster.
 * `DESIRED` displays the desired number of _replicas_ of the application, which
   you define when you create the Deployment. This is the _desired state_.
 * `CURRENT` displays how many replicas are currently running.
 * `UP-TO-DATE` displays the number of replicas that have been updated to achieve
   the desired state.
 * `AVAILABLE` displays how many replicas of the application are available to
   your users.
 * `AGE` displays the amount of time that the application has been running.
 Notice how the values in each field correspond to the values in the Deployment specification:
 * The number of desired replicas is 3 according to `spec: replicas` field.
 * The number of current replicas is 0 according to the `.status.replicas` field.
 * The number of up-to-date replicas is 0 accoridng to the `.status.updatedReplicas` field.
 * The number of available replicas is 0 according to the `.status.availableReplicas` field.
 To see the Deployment rollout status, run `kubectl rollout status deployment/nginx-deployment`. This command returns the following output:
 ```shell
 $ kubectl rollout status deployment/nginx-deployment
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 deployment "nginx-deployment" successfully rolled out
 ```
-Running the `get` again a few seconds later should give:
+Run the `kubectl get deployments` again a few seconds later:
 ```shell
 $ kubectl get deployments
 NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
 nginx-deployment   3         3         3            3           18s
 ```
-This indicates that the Deployment has created all three replicas, and all replicas are up-to-date (contains the
+Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the
-latest pod template) and available (pod status is ready for at least Deployment's `.spec.minReadySeconds`). Running
+latest Pod template) and available (the Pod status is Ready for at least the value of the Deployment's `.spec.minReadySeconds` field).
-`kubectl get rs` and `kubectl get pods` will show the ReplicaSet (RS) and Pods created.
+
 To see the ReplicaSet (`rs`) created by the deployment, run `kubectl get rs`:
 ```shell
 $ kubectl get rs
 NAME                          DESIRED   CURRENT   READY   AGE
 nginx-deployment-2035384211   3         3         3       18s
 ```
-You may notice that the name of the ReplicaSet is always `<the name of the Deployment>-<hash value of the pod template>`.
+Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[POD-TEMPALTE-HASH-VALUE]`. The hash value is automatically generated when the Deployemnt is created.
 To see the labels automatically generated for each pod, run `kubectl get pods --show-labels`. The following output is returned:
 ```shell
 $ kubectl get pods --show-labels
 NAME                                READY     STATUS    RESTARTS   AGE       LABELS
 nginx-deployment-2035384211-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
 nginx-deployment-2035384211-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
 nginx-deployment-2035384211-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
 ```
-The created ReplicaSet ensures that there are three nginx Pods at all times.
+The created ReplicaSet ensures that there are three `nginx` Pods running at all times.
-**Note:** You must specify an appropriate selector and pod template labels in a Deployment (in this case,
+**Note:** You must specify an appropriate selector and Pod template labels in a Deployment (in this case,
-`app = nginx`). That is, don't overlap with other controllers (including other Deployments, ReplicaSets,
+`app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.
 StatefulSets, etc.). Kubernetes doesn't stop you from overlapping, and if multiple
 controllers have overlapping selectors, those controllers may fight with each other and won't behave
 correctly.
 {: .note}
 ### Pod-template-hash label
@@ -112,11 +134,10 @@ correctly.
 **Note:** Do not change this label.
 {: .note}
-Note the pod-template-hash label in the example output in the pod labels above. This label is added by the
+The `pod-template-hash label` is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts. 
-Deployment controller to every ReplicaSet that a Deployment creates or adopts. Its purpose is to make sure that child
+
-ReplicaSets of a Deployment do not overlap. It is computed by hashing the PodTemplate of the ReplicaSet
+This label ensures that child ReplicaSets of a Deployment do not overlap. It is generated by hashing the `PodTemplate` of the ReplicaSet and using the resulting hash as the label value that is added to the ReplicaSet selector, Pod template labels,
-and using the resulting hash as the label value that will be added in the ReplicaSet selector, pod template labels,
+and in any existing Pods that the ReplicaSet might have.
 and in any existing Pods that the ReplicaSet may have.
 ## Updating a Deployment
@@ -262,9 +283,9 @@ removed label still exists in any existing Pods and ReplicaSets.
 Sometimes you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping.
 By default, all of the Deployment's rollout history is kept in the system so that you can rollback anytime you want
-(you can change that by modifying revision history limit]).
+(you can change that by modifying revision history limit).
-**Note:** a Deployment's revision is created when a Deployment's rollout is triggered. This means that the
+**Note:** A Deployment's revision is created when a Deployment's rollout is triggered. This means that the
 new revision is created if and only if the Deployment's pod template (`.spec.template`) is changed,
 for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment,
 do not create a Deployment revision, so that we can facilitate simultaneous manual- or auto-scaling.
@@ -141,7 +141,7 @@ will have to manage the deletion yourself (see [below](#working-with-replication
 You can specify how many pods should run concurrently by setting `.spec.replicas` to the number
 of pods you would like to have running concurrently.  The number running at any time may be higher
-or lower, such as if the replicas was just increased or decreased, or if a pod is gracefully
+or lower, such as if the replicas were just increased or decreased, or if a pod is gracefully
 shutdown, and a replacement starts early.
 If you do not specify `.spec.replicas`, then it defaults to 1.
@@ -32,7 +32,7 @@ an application.  Examples are:
 - cluster administrator deletes VM (instance) by mistake
 - cloud provider or hypervisor failure makes VM disappear
 - a kernel panic
- if the node to disappears from the cluster due to cluster network partition
+- the node disappears from the cluster due to cluster network partition
 - eviction of a pod due to the node being [out-of-resources](/docs/tasks/administer-cluster/out-of-resource/).
 Except for the out-of-resources condition, all these conditions
@@ -145,7 +145,7 @@ Initially, the pods are laid out as follows:
 | pod-a  *available*   | pod-b *available*   | pod-c *available*  |
 | pod-x  *available*   |                     |                    |
-All 3 pods are part of an deployment, and they collectively have a PDB which requires
+All 3 pods are part of a deployment, and they collectively have a PDB which requires
 there be at least 2 of the 3 pods to be available at all times.
 For example, assume the cluster administrator wants to reboot into a new kernel version to fix a bug in the kernel.
@@ -174,7 +174,7 @@ Now the cluster is in this state:
 | pod-a  *terminating* | pod-b *available*   | pod-c *available*  |
 | pod-x  *terminating* | pod-d *starting*    | pod-y              |
-At some point, the pods terminate, and the cluster look like this:
+At some point, the pods terminate, and the cluster looks like this:
 |    node-1 *drained*  |       node-2        |       node-3       |
 |:--------------------:|:-------------------:|:------------------:|
@@ -186,19 +186,19 @@ Kubernetes Cluster. We hope to add a scripted option to do this soon.
 Create a cluster with name of k8s_1, 1 master node and 3 worker minions (on physical machines), in VA1
 ```shell
- bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1
+bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1
 ```
 Create a cluster with name of k8s_2, an ha etcd cluster on 3 VMs and 6 worker minions (on VMs), in VA1
 ```shell
- bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes
+bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes
 ```
 Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VMs) with higher mem/cpu, in UC1:
 ```shell
-  bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4
+bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4
 ```
@@ -143,6 +143,23 @@ Unfortunately just setting the environment variables will not work.
 Minikube will also create a "minikube" context, and set it to default in kubectl.
 To switch back to this context later, run this command: `kubectl config use-context minikube`.
 #### Specifying the Kubernetes version
 Minikube supports running multiple different versions of Kubernetes. You can
 access a list of all available versions via
 ```
 minikube get-k8s-versions
 ```
 You can specify the specific version of Kubernetes for Minikube to use by
 adding the `--kubernetes-version` string to the `minikube start` command. For
 example, to run version `v1.7.3`, you would run the following:
 ```
 minikube start --kubernetes-version v1.7.3
 ```
 ### Configuring Kubernetes
 Minikube has a "configurator" feature that allows users to configure the Kubernetes components with arbitrary values.
@@ -12,24 +12,23 @@ This page covers how to get started with deploying Kubernetes on vSphere and det
 ### Getting started with the vSphere Cloud Provider
-Kubernetes comes with a cloud provider for vSphere. A quick and easy way to try out the cloud provider is to deploy Kubernetes using [Kubernetes-Anywhere](https://github.com/kubernetes/kubernetes-anywhere).
+Kubernetes comes with *vSphere Cloud Provider*, a cloud provider for vSphere that allows Kubernetes Pods to use enterprise grade vSphere Storage.
 This page also describes how to configure and get started with the cloud provider if deploying using custom install scripts.
 ### Deploy Kubernetes on vSphere
-To start using Kubernetes on top of vSphere and use the vSphere Cloud Provider use Kubernetes-Anywhere. Kubernetes-Anywhere will deploy and configure a cluster from scratch.
+To deploy Kubernetes on vSphere and use the vSphere Cloud Provider, see [Kubernetes-Anywhere](https://github.com/kubernetes/kubernetes-anywhere). 
 Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/README.md) page.
 ### vSphere Cloud Provider
-vSphere Cloud Provider allows using vSphere managed storage within Kubernetes. It supports:
+vSphere Cloud Provider allows Kubernetes to use vSphere managed enterprise grade storage. It supports:
-1. Volumes
+- Enterprise class services such as de-duplication and encryption with vSAN, QoS, high availability and data reliability.
-2. Persistent Volumes
+- Policy based management at granularity of container volumes.
-3. Storage Classes and provisioning of volumes.
+- Volumes, Persistent Volumes, Storage Classes, dynamic provisioning of volumes, and scalable deployment of Stateful Apps with StatefulSets.
-4. vSphere Storage Policy Based Management for Containers orchestrated by Kubernetes.
+
 For more detail visit [vSphere Storage for Kubernetes Documentation](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/index.html).
 Documentation for how to use vSphere managed storage can be found in the [persistent volumes user guide](/docs/concepts/storage/persistent-volumes/#vsphere) and the [volumes user guide](/docs/concepts/storage/volumes/#vspherevolume).
@@ -184,7 +183,7 @@ Below is summary of supported parameters in the `vsphere.conf` file
 --cloud-config=<Path of the vsphere.conf file>
 ```
-Manifest files for API server and controller-manager are generally located at `/etc/kubernetes`.
+Manifest files for API server and controller-manager are generally located at `/etc/kubernetes/manifests`.
 **Step-7** Restart Kubelet on all nodes.
@@ -194,11 +193,11 @@ Manifest files for API server and controller-manager are generally located at `/
 Note: After enabling the vSphere Cloud Provider, Node names will be set to the VM names from the vCenter Inventory.
 #### Known issues
-[vmware#220](https://github.com/vmware/kubernetes/issues/220) :
+Please visit [known issues](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/known-issues.html) for the list of major known issues with Kubernetes vSphere Cloud Provider.
 vSphere Cloud Provider can not be used on the Kubernetes Cluster when vCenter port is configured other than the default port 443. Fix for this issue is already out (Kubernetes PR# [49689](https://github.com/kubernetes/kubernetes/pull/49689)). We will make sure that, PR 49689 is cherry picked to 1.7, 1.6 and 1.5 branches. 
 ## Support Level
 For quick support please join VMware Code Slack ([#kubernetes](https://vmwarecode.slack.com/messages/kubernetes/)) and post your question.
 IaaS Provider        | Config. Mgmt | OS     | Networking | Docs                                          | Conforms  | Support Level
 -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | --------- | ----------------------------
@@ -206,4 +205,5 @@ Vmware vSphere       | Kube-anywhere    | Photon OS | Flannel         | [docs](/
 If you identify any issues/problems using the vSphere cloud provider, you can create an issue in our repo - [VMware Kubernetes](https://github.com/vmware/kubernetes).
 For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart.
@@ -4152,7 +4152,7 @@ When an object is created, the system will populate this list with the current s
 </tr>
 <tr>
 <td class="tableblock halign-left valign-top"><p class="tableblock">tolerations</p></td>
-<td class="tableblock halign-left valign-top"><p class="tableblock">If specified, the pod&#8217;s tolerations.</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">If specified, the pod&#8217;s tolerations. More info: <a href="https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/">https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/</a></p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#_v1_toleration">v1.Toleration</a> array</p></td>
 <td class="tableblock halign-left valign-top"></td>
@@ -1167,7 +1167,7 @@ Appears In <a href="#pod-v1-core">Pod</a> <a href="#podtemplatespec-v1-core">Pod
 </tr>
 <tr>
 <td>tolerations <br /> <em><a href="#toleration-v1-core">Toleration</a> array</em></td>
-<td>If specified, the pod&#39;s tolerations.</td>
+<td>If specified, the pod&#39;s tolerations. More info: <a href="http://kubernetes.io/docs/concepts/configuration/taint-and-toleration">http://kubernetes.io/docs/concepts/configuration/taint-and-toleration/</a></td>
 </tr>
 <tr>
 <td>volumes <br /> <em><a href="#volume-v1-core">Volume</a> array</em></td>
@@ -1261,7 +1261,7 @@ Appears In:
 </tr>
 <tr>
 <td>tolerations <br /> <em><a href="#toleration-v1-core">Toleration</a> array</em></td>
-<td>If specified, the pod&#39;s tolerations.</td>
+<td>If specified, the pod&#39;s tolerations. More info: <a href="https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/">https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/</a></td>
 </tr>
 <tr>
 <td>volumes <br /> <em><a href="#volume-v1-core">Volume</a> array</em>  <br /> <strong>patch type</strong>: <em>merge</em>  <br /> <strong>patch merge key</strong>: <em>name</em></td>
@@ -249,6 +249,16 @@ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documen
 ```
 {% endcapture %}
 {% capture kube-router %}
 Kube-router relies on kube-controll-manager to allocate pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag.
 Kube-router provides pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy.
 For information on setting up Kubernetes cluster with Kube-router using kubeadm please see official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/Documentation/kubeadm.md).
 {% endcapture %}
 {% capture romana %}
 The official Romana set-up guide is [here](https://github.com/romana/romana/tree/master/containerize#using-kubeadm).
@@ -272,8 +282,8 @@ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"
 ```
 {% endcapture %}
-{% assign tab_names = "Choose one...,Calico,Canal,Flannel,Romana,Weave Net" | split: ',' | compact %}
+{% assign tab_names = "Choose one...,Calico,Canal,Flannel,Kube-router,Romana,Weave Net" | split: ',' | compact %}
-{% assign tab_contents = site.emptyArray | push: choose | push: calico | push: canal | push: flannel | push: romana | push: weave_net %}
+{% assign tab_contents = site.emptyArray | push: choose | push: calico | push: canal | push: flannel | push: kube-router | push: romana | push: weave_net %}
 {% include tabs.md %}
@@ -64,11 +64,28 @@ CreationTimestamp:              Mon, 24 Oct 2016 14:21:02 -0700
 Labels:                         app=hello
                                tier=backend
                                track=stable
 Annotations:                    deployment.kubernetes.io/revision=1
 Selector:                       app=hello,tier=backend,track=stable
-Replicas:                       7 updated | 7 total | 7 available | 0 unavailable
+Replicas:                       7 desired | 7 updated | 7 total | 7 available | 0 unavailable
 StrategyType:                   RollingUpdate
 MinReadySeconds:                0
 RollingUpdateStrategy:          1 max unavailable, 1 max surge
 Pod Template:
  Labels:       app=hello
                tier=backend
                track=stable
  Containers:
   hello:
    Image:              "gcr.io/google-samples/hello-go-gke:1.0"
    Port:               80/TCP
    Environment:        <none>
    Mounts:             <none>
  Volumes:              <none>
 Conditions:
  Type          Status  Reason
  ----          ------  ------
  Available     True    MinimumReplicasAvailable
  Progressing   True    NewReplicaSetAvailable
 OldReplicaSets:                 <none>
 NewReplicaSet:                  hello-3621623197 (7/7 replicas created)
 Events:
@@ -71,7 +71,7 @@ If your cluster runs short on resources you can easily add more machines to it i
 If you're using GCE or GKE it's done by resizing Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
 ```shell
-gcloud compute instance-groups managed resize kubernetes-minion-group --size 42 --zone $ZONE
+gcloud compute instance-groups managed resize kubernetes-minion-group --size=42 --zone=$ZONE
 ```
 Instance Group will take care of putting appropriate image on new machines and start them, while Kubelet will register its Node with API server to make it available for scheduling. If you scale the instance group down, system will randomly choose Nodes to kill.
@@ -12,7 +12,7 @@ This document helps you get started using the Kubernetes [NetworkPolicy API](/do
 You'll need to have a Kubernetes cluster in place, with network policy support. There are a number of network providers that support NetworkPolicy, including:
 * [Calico](/docs/tasks/configure-pod-container/calico-network-policy/)
-* [Cilium](/docs/tasks/configure-pod-container/cilium-network-policy/)
+* [Cilium](/docs/tasks/administer-cluster/cilium-network-policy/)
 * [Romana](/docs/tasks/configure-pod-container/romana-network-policy/)
 * [Weave Net](/docs/tasks/configure-pod-container/weave-network-policy/)
@@ -162,7 +162,7 @@ Error from server (Forbidden): error when creating "docs/tasks/administer-cluste
 pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container is 500Mi, but request is 100Mi.
 ```
-## Create a Pod that does not specify any CPU request or limit
+## Create a Pod that does not specify any memory request or limit
@@ -123,6 +123,7 @@ prevent cross talk, or advanced networking policy.
 By default, there are no restrictions on which nodes may run a pod.  Kubernetes offers a 
 [rich set of policies for controlling placement of pods onto nodes](/docs/concepts/configuration/assign-pod-node/)
 and the [taint based pod placement and eviction](/docs/concepts/configuration/taint-and-toleration)
 that are available to end users. For many clusters use of these policies to separate workloads
 can be a convention that authors adopt or enforce via tooling.
@@ -129,7 +129,7 @@ kubectl delete pod memory-demo --namespace=mem-example
 A Container can exceed its memory request if the Node has memory available. But a Container
 is not allowed to use more than its memory limit. If a Container allocates more memory than
 its limit, the Container becomes a candidate for termination. If the Container continues to
-to consume memory beyond its limit, the Container is terminated. If a terminated Container is
+consume memory beyond its limit, the Container is terminated. If a terminated Container is
 restartable, the kubelet will restart it, as with any other type of runtime failure.
 In this exercise, you create a Pod that attempts to allocate more memory than its limit.
@@ -100,7 +100,7 @@ This page provides a series of usage examples demonstrating how to configure Pod
             valueFrom:
               configMapKeyRef:
                 name: env-config
-                 key: special.type
+                 key: log_level
     restartPolicy: Never
   ```
@@ -21,10 +21,12 @@ DNS provider for Cluster Federation.
 {% capture prerequisites %}
-You need to have a running Kubernetes cluster (which is
+* You need to have a running Kubernetes cluster (which is
 referenced as host cluster). Please see one of the
 [getting started](/docs/getting-started-guides/) guides for
 installation instructions for your platform.
 * Support for `LoadBalancer` services in member clusters of federation is
 mandatory to enable `CoreDNS` for service discovery across federated clusters.
 {% endcapture %}
@@ -133,6 +133,7 @@ metadata:
    jobgroup: jobexample
 spec:
  template:
    metadata:
      name: jobexample
      labels:
        jobgroup: jobexample
@@ -192,6 +192,8 @@ $ kubectl get poddisruptionbudgets zk-pdb -o yaml
 apiVersion: policy/v1beta1
 kind: PodDisruptionBudget
 metadata:
  creationTimestamp: 2017-08-28T02:38:26Z
  generation: 1
  name: zk-pdb
 ...
 status:
@@ -130,8 +130,8 @@ creation. This is done by piping the output of the `create` command to the
 kubectl create service clusterip <myservicename> -o yaml --dry-run | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -
 ```
-1. The `create service -o yaml --dry-run` command creates the configuration for the Service, but prints it to stdout as YAML instead of sending it to the Kubernetes API server.
+1. The `kubectl create service -o yaml --dry-run` command creates the configuration for the Service, but prints it to stdout as YAML instead of sending it to the Kubernetes API server.
-1. The `set --local -f - -o yaml` command reads the configuration from stdin, and writes the updated configuration to stdout as YAML.
+1. The `kubectl set --local -f - -o yaml` command reads the configuration from stdin, and writes the updated configuration to stdout as YAML.
 1. The `kubectl create -f -` command creates the object using the configuration provided via stdin.
 ## Using `--edit` to modify objects before creation
@@ -144,8 +144,8 @@ kubectl create service clusterip my-svc -o yaml --dry-run > /tmp/srv.yaml
 kubectl create --edit -f /tmp/srv.yaml
 ```
-1. The `create service` command creates the configuration for the Service and saves it to `/tmp/srv.yaml`.
+1. The `kubectl create service` command creates the configuration for the Service and saves it to `/tmp/srv.yaml`.
-1. The `create --edit` command opens the configuration file for editing before it creates the object.
+1. The `kubectl create --edit` command opens the configuration file for editing before it creates the object.
 {% endcapture %}
@@ -7,7 +7,7 @@ assignees:
 {% capture overview %}
 This tutorial shows you how to deploy a WordPress site and a MySQL database using Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data. 
-A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been provisioned by an administrator, and a [PeristentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a set amout of storage in a PV. PersistentVolumes and PeristentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods. 
+A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been provisioned by an administrator, and a [PeristentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a set amount of storage in a PV. PersistentVolumes and PeristentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods. 
 **Warning:**  This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress) to deploy WordPress in production.
 {: .warning}
@@ -20,10 +20,13 @@ spec:
        env:
        - name: GET_HOSTS_FROM
          value: dns
-          # If your cluster config does not include a dns service, then to
+          # Using `GET_HOSTS_FROM=dns` requires your cluster to
-          # instead access environment variables to find service host
+          # provide a dns service. As of Kubernetes 1.3, DNS is a built-in
-          # info, comment out the 'value: dns' line above, and uncomment the
+          # service launched automatically. However, if the cluster you are using
-          # line below:
+          # does not have a built-in DNS service, you can instead
          # instead access an environment variable to find the master
          # service's host. To do so, comment out the 'value: dns' line above, and
          # uncomment the line below:
          # value: env
        ports:
        - containerPort: 80
@@ -21,9 +21,12 @@ spec:
        env:
        - name: GET_HOSTS_FROM
          value: dns
-          # If your cluster config does not include a dns service, then to
+          # Using `GET_HOSTS_FROM=dns` requires your cluster to
          # provide a dns service. As of Kubernetes 1.3, DNS is a built-in
          # service launched automatically. However, if the cluster you are using
          # does not have a built-in DNS service, you can instead
          # instead access an environment variable to find the master
-          # service's host, comment out the 'value: dns' line above, and
+          # service's host. To do so, comment out the 'value: dns' line above, and
          # uncomment the line below:
          # value: env
        ports:
@@ -164,7 +164,7 @@ $ kubectl logs -f nginx-app-zibvs
 10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
 ```
-Now's a good time to mention slight difference between pods and containers; by default pods will not terminate if their processes exit. Instead it will restart the process. This is similar to the docker run option `--restart=always` with one major difference. In docker, the output for each invocation of the process is concatenated but for Kubernetes, each invocation is separate. To see the output from a previous run in Kubernetes, do this:
+Now's a good time to mention slight difference between pods and containers; by default pods will not terminate if their processes exit. Instead it will restart the process. This is similar to the docker run option `--restart=always` with one major difference. In docker, the output for each invocation of the process is concatenated, but for Kubernetes, each invocation is separate. To see the output from a previous run in Kubernetes, do this:
 ```shell
 $ kubectl logs --previous nginx-app-zibvs