Add nodeName to pod node selection (kubernetes#12194)

The "Assigning Pods to Nodes" page did not mention nodeName, which, if
specified, takes priority over the methods discussed in the page.  Add
description of nodeName and an example using it.

Address reviewer comments from @bsalamat and @liggitt, thanks!

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

@@ -12,7 +12,7 @@ weight: 30
 {{% capture overview %}}
 
 You can constrain a [pod](/docs/concepts/workloads/pods/pod/) to only be able to run on particular [nodes](/docs/concepts/architecture/nodes/) or to prefer to
-run on particular nodes. There are several ways to do this, and they all use
+run on particular nodes. There are several ways to do this, and the recommended approaches all use
 [label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection.
 Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
 (e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.)
@@ -29,7 +29,7 @@ repo here](https://github.com/kubernetes/website/tree/{{< param "docsbranch" >}}
 
 ## nodeSelector
 
-`nodeSelector` is the simplest form of constraint.
+`nodeSelector` is the simplest recommended form of node selection constraint.
 `nodeSelector` is a field of PodSpec. It specifies a map of key-value pairs. For the pod to be eligible
 to run on a node, the node must have each of the indicated key-value pairs as labels (it can have
 additional labels as well). The most common usage is one key-value pair.
@@ -362,6 +362,41 @@ For more information on inter-pod affinity/anti-affinity, see the
 You may want to check [Taints](/docs/concepts/configuration/taint-and-toleration/)
 as well, which allow a *node* to *repel* a set of pods.
 
+## nodeName
+
+`nodeName` is the simplest form of node selection constraint, but due
+to its limitations it is typically not used.  `nodeName` is a field of
+PodSpec.  If it is non-empty, the scheduler ignores the pod and the
+kubelet running on the named node tries to run the pod.  Thus, if
+`nodeName` is provided in the PodSpec, it takes precedence over the
+above methods for node selection.
+
+Some of the limitations of using `nodeName` to select nodes are:
+
+-   If the named node does not exist, the pod will not be run, and in
+    some cases may be automatically deleted.
+-   If the named node does not have the resources to accommodate the
+    pod, the pod will fail and its reason will indicate why,
+    e.g. OutOfmemory or OutOfcpu.
+-   Node names in cloud environments are not always predictable or
+    stable.
+
+Here is an example of a pod config file using the `nodeName` field:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  containers:
+  - name: nginx
+    image: nginx
+  nodeName: kube-01
+```
+
+The above pod will run on the node kube-01.
+
 {{% /capture %}}
 
 {{% capture whatsnext %}}