From 45722c4c59e558cc4eed9e4d77fdfba1bc43c9ae Mon Sep 17 00:00:00 2001 From: Kai Chen Date: Thu, 5 Apr 2018 19:15:09 -0700 Subject: [PATCH] Update reference to kubectl commands using redirects (concepts) (#7988) --- docs/concepts/cluster-administration/logging.md | 4 ++-- docs/concepts/services-networking/service.md | 2 +- docs/concepts/workloads/controllers/deployment.md | 2 +- docs/concepts/workloads/controllers/replicaset.md | 10 +++++----- .../workloads/controllers/replicationcontroller.md | 6 +++--- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/concepts/cluster-administration/logging.md b/docs/concepts/cluster-administration/logging.md index 51b070ffd9..e13092a1f3 100644 --- a/docs/concepts/cluster-administration/logging.md +++ b/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. diff --git a/docs/concepts/services-networking/service.md b/docs/concepts/services-networking/service.md index b5be551217..555c485ec9 100644 --- a/docs/concepts/services-networking/service.md +++ b/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 diff --git a/docs/concepts/workloads/controllers/deployment.md b/docs/concepts/workloads/controllers/deployment.md index 0ef8ba9c0d..bf0dd2eb19 100644 --- a/docs/concepts/workloads/controllers/deployment.md +++ b/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. diff --git a/docs/concepts/workloads/controllers/replicaset.md b/docs/concepts/workloads/controllers/replicaset.md index 80892006fb..72c59b7abc 100644 --- a/docs/concepts/workloads/controllers/replicaset.md +++ b/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. diff --git a/docs/concepts/workloads/controllers/replicationcontroller.md b/docs/concepts/workloads/controllers/replicationcontroller.md index 60c6da00d3..019178f9c6 100644 --- a/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/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