Resolving merge conflicts with master

docs/concepts/architecture/nodes.md

@@ -12,7 +12,7 @@ title: Nodes
 
 A `node` is a worker machine in Kubernetes, previously known as a `minion`. A node
 may be a VM or physical machine, depending on the cluster. Each node has
-the services necessary to run [pods](/docs/user-guide/pods) and is managed by the master
+the services necessary to run [pods](/docs/concepts/workloads/pods/pod/) and is managed by the master
 components. The services on a node include Docker, kubelet and kube-proxy. See
 [The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) section in the
 architecture design doc for more details.
@@ -21,11 +21,11 @@ architecture design doc for more details.
 
 A node's status contains the following information:
 
-* [Addresses](#Addresses)
-* ~~[Phase](#Phase)~~ **deprecated**
-* [Condition](#Condition)
-* [Capacity](#Capacity)
-* [Info](#Info)
+* [Addresses](#addresses)
+* ~~[Phase](#phase)~~ **deprecated**
+* [Condition](#condition)
+* [Capacity](#capacity)
+* [Info](#info)
 
 Each section is described in detail below.
 
@@ -64,7 +64,7 @@ The node condition is represented as a JSON object. For example, the following r
 ]
 ```
 
-If the Status of the Ready condition is "Unknown" or "False" for longer than the `pod-eviction-timeout`, an argument is passed to the [kube-controller-manager](/docs/admin/kube-controller-manager) and all of the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on it. The decision to delete the pods cannot be communicated to the kubelet until it re-establishes communication with the apiserver. In the meantime, the pods which are scheduled for deletion may continue to run on the partitioned node.
+If the Status of the Ready condition is "Unknown" or "False" for longer than the `pod-eviction-timeout`, an argument is passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/) and all of the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on it. The decision to delete the pods cannot be communicated to the kubelet until it re-establishes communication with the apiserver. In the meantime, the pods which are scheduled for deletion may continue to run on the partitioned node.
 
 In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
 these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is
@@ -74,14 +74,14 @@ permanently left a cluster, the cluster administrator may need to delete the nod
 Kubernetes causes all the Pod objects running on it to be deleted from the apiserver, freeing up their names.
 
 Version 1.8 introduces an alpha feature that automatically creates
-[taints](/docs/concepts/configuration/taint-and-toleration) that represent conditions.
+[taints](/docs/concepts/configuration/taint-and-toleration/) that represent conditions.
 To enable this behavior, pass an additional feature gate flag `--feature-gates=...,TaintNodesByCondition=true`
 to the API server, controller manager, and scheduler.
 When `TaintNodesByCondition` is enabled, the scheduler ignores conditions when considering a Node; instead
 it looks at the Node's taints and a Pod's tolerations.
 
 Now users can choose between the old scheduling model and a new, more flexible scheduling model.
-A Pod that does not have any tolerations gets scheduled according to the old model. But a Pod that 
+A Pod that does not have any tolerations gets scheduled according to the old model. But a Pod that
 tolerates the taints of a particular Node can be scheduled on that Node.
 
 Note that because of small delay, usually less than one second, between time when condition is observed and a taint
@@ -101,7 +101,7 @@ The information is gathered by Kubelet from the node.
 
 ## Management
 
-Unlike [pods](/docs/user-guide/pods) and [services](/docs/user-guide/services),
+Unlike [pods](/docs/concepts/workloads/pods/pod/) and [services](/docs/concepts/workloads/pods/pod/),
 a node is not inherently created by Kubernetes: it is created externally by cloud
 providers like Google Compute Engine, or exists in your pool of physical or virtual
 machines. What this means is that when Kubernetes creates a node, it is really
@@ -192,7 +192,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/taint-and-toleration)
+node unreachable or not ready. See [this documentation](/docs/concepts/configuration/taint-and-toleration/)
 for details about `NoExecute` taints and the alpha feature.
 
 Starting in version 1.8, the node controller can be made responsible for creating taints that represent
@@ -209,7 +209,7 @@ For self-registration, the kubelet is started with the following options:
   - `--cloud-provider` - How to talk to a cloud provider to read metadata about itself.
   - `--register-node` - Automatically register with the API server.
   - `--register-with-taints` - Register the node with the given list of taints (comma separated `<key>=<value>:<effect>`). No-op if `register-node` is false.
-  - `--node-ip`   IP address of the node.
+  - `--node-ip` - IP address of the node.
   - `--node-labels` - Labels to add when registering the node in the cluster.
   - `--node-status-update-frequency` - Specifies how often kubelet posts node status to master.