Update User Guide and Admin links to point to new resources. (#3438)

* Update links to outdated user-guide and admin docs

* Add script for updating outdated links.

* Update regex to include init-containers file.

* Pull upstream, rewrite links in and to namespaces walkthrough.

docs/concepts/workloads/pods/pod-lifecycle.md

@@ -158,18 +158,18 @@ duration (determined by the master) will expire and be automatically destroyed.
 
 Three types of controllers are available:
 
-- Use a [Job](/docs/user-guide/jobs/) for Pods that are expected to terminate,
+- Use a [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) for Pods that are expected to terminate,
   for example, batch computations. Jobs are appropriate only for Pods with
   `restartPolicy` equal to OnFailure or Never.
 
-- Use a [ReplicationController](/docs/user-guide/replication-controller/),
-  [ReplicaSet](/docs/user-guide/replicasets/), or
-  [Deployment](/docs/user-guide/deployments/)
+- Use a [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/),
+  [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), or
+  [Deployment](/docs/concepts/workloads/controllers/deployment/)
   for Pods that are not expected to terminate, for example, web servers.
   ReplicationControllers are appropriate only for Pods with a `restartPolicy` of
   Always.
 
-- Use a [DaemonSet](/docs/admin/daemons/) for Pods that need to run one per
+- Use a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) for Pods that need to run one per
   machine, because they provide a machine-specific system service.
 
 All three types of controllers contain a PodTemplate. It

docs/concepts/workloads/pods/pod-overview.md

@@ -75,8 +75,8 @@ In general, Controllers use a Pod Template that you provide to create the Pods f
 ## Pod Templates
 
 Pod templates are pod specifications which are included in other objects, such as
-[Replication Controllers](/docs/user-guide/replication-controller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
-[DaemonSets](/docs/admin/daemons/).  Controllers use Pod Templates to make actual pods.
+[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and
+[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).  Controllers use Pod Templates to make actual pods.
 
 Rather than specifying the current desired state of all replicas, pod templates are like cookie cutters. Once a cookie has been cut, the cookie has no relationship to the cutter. There is no quantum entanglement. Subsequent changes to the template or even switching to a new template has no direct effect on the pods already created. Similarly, pods created by a replication controller may subsequently be updated directly. This is in deliberate contrast to pods, which do specify the current desired state of all containers belonging to the pod. This approach radically simplifies system semantics and increases the flexibility of the primitive.
 

docs/concepts/workloads/pods/pod.md

@@ -44,13 +44,13 @@ a group of Docker containers with shared namespaces and shared
 
 Like individual application containers, pods are considered to be relatively
 ephemeral (rather than durable) entities. As discussed in [life of a
-pod](/docs/user-guide/pod-states/), pods are created, assigned a unique ID (UID), and
+pod](/docs/concepts/workloads/pods/pod-lifecycle/), pods are created, assigned a unique ID (UID), and
 scheduled to nodes where they remain until termination (according to restart
 policy) or deletion. If a node dies, the pods scheduled to that node are
 scheduled for deletion, after a timeout period. A given pod (as defined by a UID) is not
 "rescheduled" to a new node; instead, it can be replaced by an identical pod,
 with even the same name if desired, but with a new UID (see [replication
-controller](/docs/user-guide/replication-controller/) for more details). (In the future, a
+controller](/docs/concepts/workloads/controllers/replicationcontroller/) for more details). (In the future, a
 higher-level API may support pod migration.)
 
 When something is said to have the same lifetime as a pod, such as a volume,
@@ -86,7 +86,7 @@ Each pod has an IP address in a flat shared networking space that has full
 communication with other physical computers and pods across the network.
 
 The hostname is set to the pod's Name for the application containers within the
-pod. [More details on networking](/docs/admin/networking/).
+pod. [More details on networking](/docs/concepts/cluster-administration/networking/).
 
 In addition to defining the application containers that run in the pod, the pod
 specifies a set of shared storage volumes. Volumes enable data to survive
@@ -137,7 +137,7 @@ simplified management.
 
 Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance.
 
-In general, users shouldn't need to create pods directly. They should almost always use controllers (e.g., [Deployments](/docs/user-guide/deployments/)), even for singletons.  Controllers provide self-healing with a cluster scope, as well as replication and rollout management.
+In general, users shouldn't need to create pods directly. They should almost always use controllers (e.g., [Deployments](/docs/concepts/workloads/controllers/deployment/)), even for singletons.  Controllers provide self-healing with a cluster scope, as well as replication and rollout management.
 
 The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/configuration-reference/#job-schema), and [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).
 
@@ -150,7 +150,7 @@ Pod is exposed as a primitive in order to facilitate:
 * clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller"
 * high-availability applications, which will expect pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions, image prefetching, or live pod migration [#3949](http://issue.k8s.io/3949)
 
-There is new first-class support for stateful pods with the [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) controller (currently in beta). The feature was alpha in 1.4 and was called [PetSet](/docs/user-guide/petset/). For prior versions of Kubernetes, best practice for having stateful pods is to create a replication controller with `replicas` equal to `1` and a corresponding service, see [this MySQL deployment example](/docs/tutorials/stateful-application/run-stateful-application/). 
+There is new first-class support for stateful pods with the [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) controller (currently in beta). The feature was alpha in 1.4 and was called [PetSet](/docs/concepts/workloads/controllers/petset/). For prior versions of Kubernetes, best practice for having stateful pods is to create a replication controller with `replicas` equal to `1` and a corresponding service, see [this MySQL deployment example](/docs/tutorials/stateful-application/run-stateful-application/). 
 
 ## Termination of Pods