Tune links in tasks section (1/2)

Author: tengqm

content/en/docs/tasks/_index.md

@@ -12,4 +12,4 @@ show how to do individual tasks. A task page shows how to do a
 single thing, typically by giving a short sequence of steps.
 
 If you would like to write a task page, see
-[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/).
+[Creating a Documentation Pull Request](/docs/contribute/new-content/open-a-pr/).

content/en/docs/tasks/debug-application-cluster/audit.md

@@ -375,7 +375,7 @@ different audit policies.
 
 ### Use fluentd to collect and distribute audit events from log file
 
-[Fluentd](http://www.fluentd.org/) is an open source data collector for unified logging layer.
+[Fluentd](https://www.fluentd.org/) is an open source data collector for unified logging layer.
 In this example, we will use fluentd to split audit events by different namespaces.
 
 {{< note >}}
@@ -503,7 +503,7 @@ different users into different files.
     bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
     ```
 
-1. create a [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for kube-apiserver webhook audit backend
+1. create a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) for kube-apiserver webhook audit backend
 
         cat < /etc/kubernetes/audit-webhook-kubeconfig
         apiVersion: v1
@@ -537,9 +537,5 @@ plugin which supports full-text search and analytics.
 
 ## {{% heading "whatsnext" %}}
 
-
-Visit [Auditing with Falco](/docs/tasks/debug-application-cluster/falco).
-
 Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
 
-

content/en/docs/tasks/debug-application-cluster/debug-application.md

@@ -10,10 +10,7 @@ content_type: concept
 
 This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly.
 This is *not* a guide for people who want to debug their cluster.  For that you should check out
-[this guide](/docs/admin/cluster-troubleshooting).
-
-
-
+[this guide](/docs/tasks/debug-application-cluster/debug-cluster).
 
 
 
@@ -46,7 +43,8 @@ there are insufficient resources of one type or another that prevent scheduling.
 your pod.  Reasons include:
 
 * **You don't have enough resources**:  You may have exhausted the supply of CPU or Memory in your cluster, in this case
-you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See [Compute Resources document](/docs/user-guide/compute-resources/#my-pods-are-pending-with-event-message-failedscheduling) for more information.
+you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See
+[Compute Resources document](/docs/concepts/configuration/manage-resources-containers/) for more information.
 
 * **You are using `hostPort`**:  When you bind a Pod to a `hostPort` there are a limited number of places that pod can be
 scheduled.  In most cases, `hostPort` is unnecessary, try using a Service object to expose your Pod.  If you do require
@@ -161,13 +159,13 @@ check:
    * Can you connect to your pods directly?  Get the IP address for the Pod, and try to connect directly to that IP.
    * Is your application serving on the port that you configured?  Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080.
 
-
-
 ## {{% heading "whatsnext" %}}
 
+If none of the above solves your problem, follow the instructions in
+[Debugging Service document](/docs/tasks/debug-application-cluster/debug-service/)
+to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are
+actually serving; you have DNS working, iptables rules installed, and kube-proxy
+does not seem to be misbehaving.
 
-If none of the above solves your problem, follow the instructions in [Debugging Service document](/docs/user-guide/debugging-services) to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving.
-
-You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
-
+You may also visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/) for more information.
 

content/en/docs/tasks/debug-application-cluster/debug-cluster.md

@@ -10,10 +10,7 @@ content_type: concept
 This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
 problem you are experiencing. See
 the [application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application) for tips on application debugging.
-You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
-
-
-
+You may also visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/) for more information.
 
 
 

content/en/docs/tasks/debug-application-cluster/debug-init-containers.md

@@ -15,22 +15,18 @@ content_type: task
 
 This page shows how to investigate problems related to the execution of
 Init Containers. The example command lines below refer to the Pod as
-  `` and the Init Containers as `` and
-  ``.
-
-
+`` and the Init Containers as `` and
+``.
 
 ## {{% heading "prerequisites" %}}
 
 
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
 * You should be familiar with the basics of
-  [Init Containers](/docs/concepts/abstractions/init-containers/).
+  [Init Containers](/docs/concepts/workloads/pods/init-containers/).
 * You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
 
-
-
 
 
 ## Checking the status of Init Containers

content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md

@@ -9,8 +9,6 @@ content_type: task
 
 This page shows how to debug Pods and ReplicationControllers.
 
-
-
 ## {{% heading "prerequisites" %}}
 
 
@@ -20,8 +18,6 @@ This page shows how to debug Pods and ReplicationControllers.
   {{< glossary_tooltip text="Pods" term_id="pod" >}} and with 
   Pods' [lifecycles](/docs/concepts/workloads/pods/pod-lifecycle/).
 
-
-
 
 
 ## Debugging Pods
@@ -51,9 +47,9 @@ can not schedule your pod. Reasons include:
 You may have exhausted the supply of CPU or Memory in your cluster. In this
 case you can try several things:
 
-* [Add more nodes](/docs/admin/cluster-management/#resizing-a-cluster) to the cluster.
+* [Add more nodes](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster) to the cluster.
 
-* [Terminate unneeded pods](/docs/user-guide/pods/single-container/#deleting_a_pod)
+* [Terminate unneeded pods](/docs/concepts/workloads/pods/#pod-termination)
   to make room for pending pods.
 
 * Check that the pod is not larger than your nodes. For example, if all

content/en/docs/tasks/debug-application-cluster/debug-service.md

@@ -13,9 +13,6 @@ Deployment (or other workload controller) and created a Service, but you
 get no response when you try to access it.  This document will hopefully help
 you to figure out what's going wrong.
 
-
-
-
 
 
 ## Running commands in a Pod
@@ -658,7 +655,7 @@ This might sound unlikely, but it does happen and it is supposed to work.
 This can happen when the network is not properly configured for "hairpin"
 traffic, usually when `kube-proxy` is running in `iptables` mode and Pods
 are connected with bridge network. The `Kubelet` exposes a `hairpin-mode`
-[flag](/docs/admin/kubelet/) that allows endpoints of a Service to loadbalance
+[flag](/docs/reference/command-line-tools-reference/kubelet/) that allows endpoints of a Service to loadbalance
 back to themselves if they try to access their own Service VIP. The
 `hairpin-mode` flag must either be set to `hairpin-veth` or
 `promiscuous-bridge`.
@@ -724,15 +721,13 @@ Service is not working.  Please let us know what is going on, so we can help
 investigate!
 
 Contact us on
-[Slack](/docs/troubleshooting/#slack) or
+[Slack](/docs/tasks/debug-application-cluster/troubleshooting/#slack) or
 [Forum](https://discuss.kubernetes.io) or
 [GitHub](https://github.com/kubernetes/kubernetes).
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
-Visit [troubleshooting document](/docs/troubleshooting/) for more information.
+Visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/)
+for more information.
 
 

content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md

@@ -12,19 +12,13 @@ content_type: task
 ---
 
 
-
 This task shows you how to debug a StatefulSet.
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
 * You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.
 * You should have a StatefulSet running that you want to investigate.
 
-
-
 
 
 ## Debugging a StatefulSet
@@ -37,18 +31,12 @@ kubectl get pods -l app=myapp
 ```
 
 If you find that any Pods listed are in `Unknown` or `Terminating` state for an extended period of time,
-refer to the [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) task for
+refer to the [Deleting StatefulSet Pods](/docs/tasks/run-application/delete-stateful-set/) task for
 instructions on how to deal with them.
 You can debug individual Pods in a StatefulSet using the
 [Debugging Pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) guide.
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 Learn more about [debugging an init-container](/docs/tasks/debug-application-cluster/debug-init-containers/).
 
-
-
-

content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md

@@ -10,7 +10,7 @@ title: Logging Using Elasticsearch and Kibana
 
 On the Google Compute Engine (GCE) platform, the default logging support targets
 [Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail
-in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
+in the [Logging With Stackdriver Logging](/docs/tasks/debug-application-cluster/logging-stackdriver).
 
 This article describes how to set up a cluster to ingest logs into
 [Elasticsearch](https://www.elastic.co/products/elasticsearch) and view
@@ -90,7 +90,8 @@ Elasticsearch, and is part of a service named `kibana-logging`.
 
 The Elasticsearch and Kibana services are both in the `kube-system` namespace
 and are not directly exposed via a publicly reachable IP address. To reach them,
-follow the instructions for [Accessing services running in a cluster](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster).
+follow the instructions for
+[Accessing services running in a cluster](/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster).
 
 If you try accessing the `elasticsearch-logging` service in your browser, you'll
 see a status page that looks something like this:
@@ -102,7 +103,7 @@ like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasti
 for more details on how to do so.
 
 Alternatively, you can view your cluster's logs using Kibana (again using the
-[instructions for accessing a service running in the cluster](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)).
+[instructions for accessing a service running in the cluster](/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)).
 The first time you visit the Kibana URL you will be presented with a page that
 asks you to configure your view of the ingested logs. Select the option for
 timeseries values and select `@timestamp`. On the following page select the

content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md

@@ -317,8 +317,8 @@ After some time, Stackdriver Logging agent pods will be restarted with the new c
 ### Changing fluentd parameters
 
 Fluentd configuration is stored in the `ConfigMap` object. It is effectively a set of configuration
-files that are merged together. You can learn about fluentd configuration on the [official
-site](http://docs.fluentd.org).
+files that are merged together. You can learn about fluentd configuration on the
+[official site](https://docs.fluentd.org).
 
 Imagine you want to add a new parsing logic to the configuration, so that fluentd can understand
 default Python logging format. An appropriate fluentd filter looks similar to this:
@@ -356,7 +356,7 @@ using [guide above](#changing-daemonset-parameters).
 ### Adding fluentd plugins
 
 Fluentd is written in Ruby and allows to extend its capabilities using
-[plugins](http://www.fluentd.org/plugins). If you want to use a plugin, which is not included
+[plugins](https://www.fluentd.org/plugins). If you want to use a plugin, which is not included
 in the default Stackdriver Logging container image, you have to build a custom image. Imagine
 you want to add Kafka sink for messages from a particular container for additional processing.
 You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)

content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md

@@ -13,9 +13,6 @@ are available in Kubernetes through the Metrics API. These metrics can be either
 by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g.
 Horizontal Pod Autoscaler, to make decisions.
 
-
-
-
 
 
 ## The Metrics API
@@ -41,11 +38,19 @@ The API requires metrics server to be deployed in the cluster. Otherwise it will
 
 ### CPU
 
-CPU is reported as the average usage, in [CPU cores](/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window  for the rate calculation.
+CPU is reported as the average usage, in
+[CPU cores](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu),
+over a period of time. This value is derived by taking a rate over a cumulative CPU counter
+provided by the kernel (in both Linux and Windows kernels).
+The kubelet chooses the window for the rate calculation.
 
 ### Memory
 
-Memory is reported as the working set, in bytes, at the instant the metric was collected. In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under memory pressure.  However, calculation of the working set varies by host OS, and generally makes heavy use of heuristics to produce an estimate.  It includes all anonymous (non-file-backed) memory since kubernetes does not support swap. The metric typically also includes some cached (file-backed) memory, because the host OS cannot always reclaim such pages.
+Memory is reported as the working set, in bytes, at the instant the metric was collected.
+In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under memory pressure.
+However, calculation of the working set varies by host OS, and generally makes heavy use of heuristics to produce an estimate.
+It includes all anonymous (non-file-backed) memory since kubernetes does not support swap.
+The metric typically also includes some cached (file-backed) memory, because the host OS cannot always reclaim such pages.
 
 ## Metrics Server
 
@@ -54,9 +59,12 @@ It is deployed by default in clusters created by `kube-up.sh` script
 as a Deployment object. If you use a different Kubernetes setup mechanism you can deploy it using the provided
 [deployment components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) file.
 
-Metric server collects metrics from the Summary API, exposed by [Kubelet](/docs/admin/kubelet/) on each node.
+Metric server collects metrics from the Summary API, exposed by
+[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) on each node.
 
 Metrics Server is registered with the main API server through
-[Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/).
+[Kubernetes aggregator](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
+
+Learn more about the metrics server in
+[the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
 
-Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).

content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md

@@ -10,29 +10,32 @@ title: Tools for Monitoring Resources
 To scale an application and provide a reliable service, you need to
 understand how the application behaves when it is deployed. You can examine
 application performance in a Kubernetes cluster by examining the containers,
-[pods](/docs/user-guide/pods), [services](/docs/user-guide/services), and
+[pods](/docs/concepts/workloads/pods/),
+[services](/docs/concepts/services-networking/service/), and
 the characteristics of the overall cluster. Kubernetes provides detailed
 information about an application's resource usage at each of these levels.
 This information allows you to evaluate your application's performance and
 where bottlenecks can be removed to improve overall performance.
 
-
-
 
 
-In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
+In Kubernetes, application monitoring does not depend on a single monitoring solution.
+On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or
+[full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
 
 ## Resource metrics pipeline
 
 The resource metrics pipeline provides a limited set of metrics related to
-cluster components such as the [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) controller, as well as the `kubectl top` utility.
+cluster components such as the
+[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)
+controller, as well as the `kubectl top` utility.
 These  metrics are collected by the lightweight, short-term, in-memory 
 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) and
  are exposed via the `metrics.k8s.io` API. 
 
 metrics-server discovers all nodes on the cluster and 
 queries each node's 
-[kubelet](/docs/reference/command-line-tools-reference/kubelet) for CPU and 
+[kubelet](/docs/reference/command-line-tools-reference/kubelet/) for CPU and 
 memory usage. The kubelet acts as a bridge between the Kubernetes master and 
 the nodes, managing the pods and containers running on a machine. The kubelet 
 translates each pod into its constituent containers and fetches individual