Update Links to kubectl docs (#7927)

* Fix deployment.md

* Fix replicaset.md

* Fix tain-and-toleration

* Update concepts/configuration

* Update documentation

* Fix based on comments

* Update quick comments

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/user-guide/kubectl/{{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/reference/generated/kubectl/kubectl-commands#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/user-guide/kubectl/{{page.version}}/#logs) as in
+When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#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/configuration/organize-cluster-access-kubeconfig.md

@@ -17,7 +17,7 @@ It does not mean that there is a file named `kubeconfig`.
 By default, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory.
 You can specify other kubeconfig files by setting the `KUBECONFIG` environment
 variable or by setting the
-[`--kubeconfig`](/docs/user-guide/kubectl/{{page.version}}/) flag.
+[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) flag.
 
 For step-by-step instructions on creating and specifying kubeconfig files, see
 [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
@@ -146,7 +146,7 @@ are stored absolutely.
 {% capture whatsnext %}
 
 * [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
-* [kubectl config](/docs/user-guide/kubectl/{{page.version}}/)
+* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
 
 {% endcapture %}
 

docs/concepts/configuration/secret.md

@@ -119,7 +119,7 @@ data:
 
 The data field is a map.  Its keys must consist of alphanumeric characters, '-', '_' or '.'.  The values are arbitrary data, encoded using base64.
 
-Create the secret using [`kubectl create`](/docs/user-guide/kubectl/{{page.version}}/#create):
+Create the secret using [`kubectl create`](/docs/reference/generated/kubectl/kubectl-commands#create):
 
 ```shell
 $ kubectl create -f ./secret.yaml

docs/concepts/configuration/taint-and-toleration.md

@@ -22,7 +22,7 @@ onto nodes with matching taints.
 
 ## Concepts
 
-You add a taint to a node using [kubectl taint](/docs/user-guide/kubectl/{{page.version}}/#taint).
+You add a taint to a node using [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint).
 For example,
 
 ```shell

docs/concepts/overview/object-management-kubectl/declarative-config.md

@@ -975,7 +975,7 @@ template:
 {% capture whatsnext %}
 - [Managing Kubernetes Objects Using Imperative Commands](/docs/concepts/overview/object-management-kubectl/imperative-command/)
 - [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/concepts/overview/object-management-kubectl/imperative-config/)
-- [Kubectl Command Reference](/docs/user-guide/kubectl/{{page.version}}/)
+- [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
 - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{page.version}}/)
 {% endcapture %}
 

docs/concepts/overview/object-management-kubectl/imperative-command.md

@@ -154,7 +154,7 @@ kubectl create --edit -f /tmp/srv.yaml
 {% capture whatsnext %}
 - [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/concepts/overview/object-management-kubectl/imperative-config/)
 - [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
-- [Kubectl Command Reference](/docs/user-guide/kubectl/{{page.version}}/)
+- [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
 - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{page.version}}/)
 {% endcapture %}
 

docs/concepts/overview/object-management-kubectl/imperative-config.md

@@ -130,7 +130,7 @@ template:
 {% capture whatsnext %}
 - [Managing Kubernetes Objects Using Imperative Commands](/docs/concepts/overview/object-management-kubectl/imperative-command/)
 - [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
-- [Kubectl Command Reference](/docs/user-guide/kubectl/{{page.version}}/)
+- [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
 - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{page.version}}/)
 {% endcapture %}
 

docs/concepts/overview/object-management-kubectl/overview.md

@@ -170,7 +170,7 @@ Disadvantages compared to imperative object configuration:
 - [Managing Kubernetes Objects Using Imperative Commands](/docs/concepts/overview/object-management-kubectl/imperative-command/)
 - [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/concepts/overview/object-management-kubectl/imperative-config/)
 - [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
-- [Kubectl Command Reference](/docs/user-guide/kubectl/{{page.version}}/)
+- [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
 - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{page.version}}/)
 
 {% comment %}

docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -36,7 +36,7 @@ Here's an example `.yaml` file that shows the required fields and object spec fo
 
 {% include code.html language="yaml" file="nginx-deployment.yaml" ghlink="/docs/concepts/overview/working-with-objects/nginx-deployment.yaml" %}
 
-One way to create a Deployment using a `.yaml` file like the one above is to use the [`kubectl create`](/docs/user-guide/kubectl/{{page.version}}/#create) command in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example:
+One way to create a Deployment using a `.yaml` file like the one above is to use the [`kubectl create`](/docs/reference/generated/kubectl/kubectl-commands#create) command in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example:
 
 ```shell
 $ kubectl create -f https://k8s.io/docs/user-guide/nginx-deployment.yaml --record

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/user-guide/kubectl/{{page.version}}/#rolling-update)).  While each `Pod` gets its own IP address, even
+or when doing [rolling updates](/docs/reference/generated/kubectl/kubectl-commands#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/user-guide/kubectl/{{page.version}}/#rolling-update) updates Pods and ReplicationControllers
+[`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#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/user-guide/kubectl/{{page.version}}/#rolling-update) command. If
+[`rolling-update`](docs/reference/generated/kubectl/kubectl-commands#rolling-update) command. If
 you want the rolling update functionality please consider using Deployments
 instead. Also, the
-[`rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) command is
+[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) command is
 imperative whereas Deployments are declarative, so we recommend using Deployments
-through the [`rollout`](/docs/user-guide/kubectl/{{page.version}}/#rollout) command.
+through the [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#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/user-guide/kubectl/{{page.version}}/#delete). Kubectl will scale the ReplicaSet to zero and wait
+delete`](/docs/reference/generated/kubectl/kubectl-commands#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/user-guide/kubectl/{{page.version}}/#delete) with the `--cascade=false` option.
+You can delete a ReplicaSet without affecting any of its pods, using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#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/user-guide/kubectl/{{page.version}}/#delete).  Kubectl will scale the ReplicationController to zero and wait
+delete`](/docs/reference/generated/kubectl/kubectl-commands#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/user-guide/kubectl/{{page.version}}/#delete).
+Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#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/user-guide/kubectl/{{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/reference/generated/kubectl/kubectl-commands#rolling-update). Visit [`kubectl rolling-update` task](/docs/tasks/run-application/rolling-update-replication-controller/) for more concrete examples.
 
 ### Multiple release tracks