Update reference to kubectl commands using redirects (concepts) (#7988)

docs/concepts/cluster-administration/logging.md

@@ -43,7 +43,7 @@ $ kubectl logs counter
 ...
 ```
 
-You can use `kubectl logs` to retrieve logs from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#logs) for more details.
+You can use `kubectl logs` to retrieve logs from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/user-guide/kubectl/{{page.version}}/#logs) for more details.
 
 ## Logging at the node level
 
@@ -71,7 +71,7 @@ As an example, you can find detailed information about how `kube-up.sh` sets
 up logging for COS image on GCP in the corresponding [script]
 [cosConfigureHelper].
 
-When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#logs) as in
+When you run [`kubectl logs`](/docs/user-guide/kubectl/{{page.version}}/#logs) as in
 the basic logging example, the kubelet on the node handles the request and
 reads directly from the log file, returning the contents in the response.
 

docs/concepts/services-networking/service.md

@@ -7,7 +7,7 @@ title: Services
 Kubernetes [`Pods`](/docs/concepts/workloads/pods/pod/) are mortal. They are born and when they die, they
 are not resurrected.  [`ReplicationControllers`](/docs/concepts/workloads/controllers/replicationcontroller/) in
 particular create and destroy `Pods` dynamically (e.g. when scaling up or down
-or when doing [rolling updates](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#rolling-update)).  While each `Pod` gets its own IP address, even
+or when doing [rolling updates](/docs/user-guide/kubectl/{{page.version}}/#rolling-update)).  While each `Pod` gets its own IP address, even
 those IP addresses cannot be relied upon to be stable over time. This leads to
 a problem: if some set of `Pods` (let's call them backends) provides
 functionality to other `Pods` (let's call them frontends) inside the Kubernetes

docs/concepts/workloads/controllers/deployment.md

@@ -964,7 +964,7 @@ it is created.
 
 ### kubectl rolling update
 
-[Kubectl rolling update](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#rolling-update) updates Pods and ReplicationControllers
+[Kubectl rolling update](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) updates Pods and ReplicationControllers
 in a similar fashion. But Deployments are recommended, since they are declarative, server side, and have
 additional features, such as rolling back to any previous revision even after the rolling update is done.
 

docs/concepts/workloads/controllers/replicaset.md

@@ -23,12 +23,12 @@ whereas a Replication Controller only supports equality-based selector requireme
 
 Most [`kubectl`](/docs/user-guide/kubectl/) commands that support
 Replication Controllers also support ReplicaSets. One exception is the
-[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#rolling-update) command. If
+[`rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) command. If
 you want the rolling update functionality please consider using Deployments
 instead. Also, the
-[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#rolling-update) command is
+[`rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) command is
 imperative whereas Deployments are declarative, so we recommend using Deployments
-through the [`rollout`](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#rollout) command.
+through the [`rollout`](/docs/user-guide/kubectl/{{page.version}}/#rollout) command.
 
 While ReplicaSets can be used independently, today it's mainly used by
 [Deployments](/docs/concepts/workloads/controllers/deployment/) as a mechanism to orchestrate pod
@@ -154,7 +154,7 @@ If you do not specify `.spec.replicas`, then it defaults to 1.
 ### Deleting a ReplicaSet and its Pods
 
 To delete a ReplicaSet and all its pods, use [`kubectl
-delete`](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#delete). Kubectl will scale the ReplicaSet to zero and wait
+delete`](/docs/user-guide/kubectl/{{page.version}}/#delete). Kubectl will scale the ReplicaSet to zero and wait
 for it to delete each pod before deleting the ReplicaSet itself. If this kubectl command is interrupted, it can
 be restarted.
 
@@ -163,7 +163,7 @@ When using the REST API or go client library, you need to do the steps explicitl
 
 ### Deleting just a ReplicaSet
 
-You can delete a ReplicaSet without affecting any of its pods, using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#delete) with the `--cascade=false` option.
+You can delete a ReplicaSet without affecting any of its pods, using [`kubectl delete`](/docs/user-guide/kubectl/{{page.version}}/#delete) with the `--cascade=false` option.
 
 When using the REST API or go client library, simply delete the ReplicaSet object.
 

docs/concepts/workloads/controllers/replicationcontroller.md

@@ -160,7 +160,7 @@ If you do not specify `.spec.replicas`, then it defaults to 1.
 ### Deleting a ReplicationController and its Pods
 
 To delete a ReplicationController and all its pods, use [`kubectl
-delete`](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#delete).  Kubectl will scale the ReplicationController to zero and wait
+delete`](/docs/user-guide/kubectl/{{page.version}}/#delete).  Kubectl will scale the ReplicationController to zero and wait
 for it to delete each pod before deleting the ReplicationController itself.  If this kubectl
 command is interrupted, it can be restarted.
 
@@ -171,7 +171,7 @@ When using the REST API or go client library, you need to do the steps explicitl
 
 You can delete a ReplicationController without affecting any of its pods.
 
-Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#delete).
+Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/user-guide/kubectl/{{page.version}}/#delete).
 
 When using the REST API or go client library, simply delete the ReplicationController object.
 
@@ -205,7 +205,7 @@ Ideally, the rolling update controller would take application readiness into acc
 The two ReplicationControllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates.
 
 Rolling update is implemented in the client tool
-[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands/{{page.version}}/#rolling-update). Visit [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) for more concrete examples.
+[`kubectl rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update). Visit [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) for more concrete examples.
 
 ### Multiple release tracks