Merge pull request #34372 from tengqm/fix-links-1

Batch fixes for links (1)

Author: k8s-ci-robot

content/en/docs/setup/_index.md

@@ -67,4 +67,5 @@ for deploying Kubernetes is [kubeadm](/docs/setup/production-environment/tools/k
 Kubernetes is designed for its {{< glossary_tooltip term_id="control-plane" text="control plane" >}} to
 run on Linux. Within your cluster you can run applications on Linux or other operating systems, including
 Windows.
-- Learn to [set up clusters with Windows nodes](/docs/setup/production-environment/windows/)
+
+- Learn to [set up clusters with Windows nodes](/docs/concepts/windows/)

content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md

@@ -29,7 +29,7 @@ configuration.
 
 These tasks will help you to migrate:
 
-* [Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
+* [Check whether Dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)
 * [Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)
 * [Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)
 

content/en/docs/tasks/configure-pod-container/migrate-from-psp.md

@@ -323,7 +323,7 @@ configuration of the API server:
 
 To verify that the PodSecurityPolicy admission controller is no longer enabled, you can manually run
 a test by impersonating a user without access to any PodSecurityPolicies (see the
-[PodSecurityPolicy example](/docs/concepts/policy/pod-security-policy/#example)), or by verifying in
+[PodSecurityPolicy example](/docs/concepts/security/pod-security-policy/#example)), or by verifying in
 the API server logs. At startup, the API server outputs log lines listing the loaded admission
 controller plugins:
 

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

@@ -36,7 +36,13 @@ kubectl cluster-info dump
 
 ### Example: debugging a down/unreachable node
 
-Sometimes when debugging it can be useful to look at the status of a node -- for example, because you've noticed strange behavior of a Pod that's running on the node, or to find out why a Pod won't schedule onto the node. As with Pods, you can use `kubectl describe node` and `kubectl get node -o yaml` to retrieve detailed information about nodes. For example, here's what you'll see if a node is down (disconnected from the network, or kubelet dies and won't restart, etc.). Notice the events that show the node is NotReady, and also notice that the pods are no longer running (they are evicted after five minutes of NotReady status).
+Sometimes when debugging it can be useful to look at the status of a node -- for example, because
+you've noticed strange behavior of a Pod that's running on the node, or to find out why a Pod
+won't schedule onto the node. As with Pods, you can use `kubectl describe node` and `kubectl get
+node -o yaml` to retrieve detailed information about nodes. For example, here's what you'll see if
+a node is down (disconnected from the network, or kubelet dies and won't restart, etc.). Notice
+the events that show the node is NotReady, and also notice that the pods are no longer running
+(they are evicted after five minutes of NotReady status).
 
 ```shell
 kubectl get nodes
@@ -222,60 +228,63 @@ of the relevant log files.  On systemd-based systems, you may need to use `journ
 
 ### Control Plane nodes
 
-   * `/var/log/kube-apiserver.log` - API Server, responsible for serving the API
-   * `/var/log/kube-scheduler.log` - Scheduler, responsible for making scheduling decisions
-   * `/var/log/kube-controller-manager.log` - a component that runs most Kubernetes built-in {{<glossary_tooltip text="controllers" term_id="controller">}}, with the notable exception of scheduling (the kube-scheduler handles scheduling).
+* `/var/log/kube-apiserver.log` - API Server, responsible for serving the API
+* `/var/log/kube-scheduler.log` - Scheduler, responsible for making scheduling decisions
+* `/var/log/kube-controller-manager.log` - a component that runs most Kubernetes built-in
+  {{<glossary_tooltip text="controllers" term_id="controller">}}, with the notable exception of scheduling
+  (the kube-scheduler handles scheduling).
 
 ### Worker Nodes
 
-   * `/var/log/kubelet.log` - logs from the kubelet, responsible for running containers on the node
-   * `/var/log/kube-proxy.log` - logs from `kube-proxy`, which is responsible for directing traffic to Service endpoints
+* `/var/log/kubelet.log` - logs from the kubelet, responsible for running containers on the node
+* `/var/log/kube-proxy.log` - logs from `kube-proxy`, which is responsible for directing traffic to Service endpoints
 
 ## Cluster failure modes
 
 This is an incomplete list of things that could go wrong, and how to adjust your cluster setup to mitigate the problems.
 
 ### Contributing causes
 
-  - VM(s) shutdown
-  - Network partition within cluster, or between cluster and users
-  - Crashes in Kubernetes software
-  - Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume)
-  - Operator error, for example misconfigured Kubernetes software or application software
+- VM(s) shutdown
+- Network partition within cluster, or between cluster and users
+- Crashes in Kubernetes software
+- Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume)
+- Operator error, for example misconfigured Kubernetes software or application software
 
 ### Specific scenarios
 
-  - API server VM shutdown or apiserver crashing
-    - Results
-      - unable to stop, update, or start new pods, services, replication controller
-      - existing pods and services should continue to work normally, unless they depend on the Kubernetes API
-  - API server backing storage lost
-    - Results
-      - the kube-apiserver component fails to start successfully and become healthy
-      - kubelets will not be able to reach it but will continue to run the same pods and provide the same service proxying
-      - manual recovery or recreation of apiserver state necessary before apiserver is restarted
-  - Supporting services (node controller, replication controller manager, scheduler, etc) VM shutdown or crashes
-    - currently those are colocated with the apiserver, and their unavailability has similar consequences as apiserver
-    - in future, these will be replicated as well and may not be co-located
-    - they do not have their own persistent state
-  - Individual node (VM or physical machine) shuts down
-    - Results
-      - pods on that Node stop running
-  - Network partition
-    - Results
-      - partition A thinks the nodes in partition B are down; partition B thinks the apiserver is down. (Assuming the master VM ends up in partition A.)
-  - Kubelet software fault
-    - Results
-      - crashing kubelet cannot start new pods on the node
-      - kubelet might delete the pods or not
-      - node marked unhealthy
-      - replication controllers start new pods elsewhere
-  - Cluster operator error
-    - Results
-      - loss of pods, services, etc
-      - lost of apiserver backing store
-      - users unable to read API
-      - etc.
+- API server VM shutdown or apiserver crashing
+  - Results
+    - unable to stop, update, or start new pods, services, replication controller
+    - existing pods and services should continue to work normally, unless they depend on the Kubernetes API
+- API server backing storage lost
+  - Results
+    - the kube-apiserver component fails to start successfully and become healthy
+    - kubelets will not be able to reach it but will continue to run the same pods and provide the same service proxying
+    - manual recovery or recreation of apiserver state necessary before apiserver is restarted
+- Supporting services (node controller, replication controller manager, scheduler, etc) VM shutdown or crashes
+  - currently those are colocated with the apiserver, and their unavailability has similar consequences as apiserver
+  - in future, these will be replicated as well and may not be co-located
+  - they do not have their own persistent state
+- Individual node (VM or physical machine) shuts down
+  - Results
+    - pods on that Node stop running
+- Network partition
+  - Results
+    - partition A thinks the nodes in partition B are down; partition B thinks the apiserver is down.
+      (Assuming the master VM ends up in partition A.)
+- Kubelet software fault
+  - Results
+    - crashing kubelet cannot start new pods on the node
+    - kubelet might delete the pods or not
+    - node marked unhealthy
+    - replication controllers start new pods elsewhere
+- Cluster operator error
+  - Results
+    - loss of pods, services, etc
+    - lost of apiserver backing store
+    - users unable to read API
+    - etc.
 
 ### Mitigations
 
@@ -308,9 +317,13 @@ This is an incomplete list of things that could go wrong, and how to adjust your
 
 ## {{% heading "whatsnext" %}}
 
-* Learn about the metrics available in the [Resource Metrics Pipeline](resource-metrics-pipeline)
-* Discover additional tools for [monitoring resource usage](resource-usage-monitoring)
-* Use Node Problem Detector to [monitor node health](monitor-node-health)
-* Use `crictl` to [debug Kubernetes nodes](crictl)
-* Get more information about [Kubernetes auditing](audit)
-* Use `telepresence` to [develop and debug services locally](local-debugging)
+* Learn about the metrics available in the
+  [Resource Metrics Pipeline](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/)
+* Discover additional tools for
+  [monitoring resource usage](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
+* Use Node Problem Detector to
+  [monitor node health](/docs/tasks/debug/debug-cluster/monitor-node-health/)
+* Use `crictl` to [debug Kubernetes nodes](/docs/tasks/debug/debug-cluster/crictl/)
+* Get more information about [Kubernetes auditing](/docs/tasks/debug/debug-cluster/audit/)
+* Use `telepresence` to [develop and debug services locally](/docs/tasks/debug/debug-cluster/local-debugging/)
+

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

@@ -17,7 +17,7 @@ content_type: concept
 1. My Pods are stuck at "Container Creating" or restarting over and over
 
    Ensure that your pause image is compatible with your Windows OS version.
-   See [Pause container](/docs/setup/production-environment/windows/intro-windows-in-kubernetes#pause-container)
+   See [Pause container](/docs/concepts/windows/intro/#pause-container)
    to see the latest / recommended pause image and/or get more information.
 
    {{< note >}}
@@ -32,7 +32,7 @@ content_type: concept
    Windows Node.
 
    More information on how to specify a compatible node for your Pod can be found in
-   [this guide](/docs/setup/production-environment/windows/user-guide-windows-containers/#ensuring-os-specific-workloads-land-on-the-appropriate-container-host).
+   [this guide](/docs/concepts/windows/user-guide/#ensuring-os-specific-workloads-land-on-the-appropriate-container-host).
 
 ## Network troubleshooting {#troubleshooting-network}
 
@@ -102,8 +102,8 @@ content_type: concept
    Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
    ```
 
-   Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) parameter of the `start.ps1` script,
-   in cases where the host's network adapter isn't "Ethernet".
+   Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7)
+   parameter of the `start.ps1` script, in cases where the host's network adapter isn't "Ethernet".
    Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.
 
 1. DNS resolution is not properly working
@@ -112,9 +112,11 @@ content_type: concept
 
 1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found"
 
-   This was implemented in Kubernetes 1.15 by including `wincat.exe` in the pause infrastructure container `mcr.microsoft.com/oss/kubernetes/pause:3.6`.
+   This was implemented in Kubernetes 1.15 by including `wincat.exe` in the pause infrastructure container
+   `mcr.microsoft.com/oss/kubernetes/pause:3.6`.
    Be sure to use a supported version of Kubernetes.
-   If you would like to build your own pause infrastructure container be sure to include [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat).
+   If you would like to build your own pause infrastructure container be sure to include
+   [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat).
 
 1. My Kubernetes installation is failing because my Windows Server node is behind a proxy
 
@@ -170,4 +172,5 @@ If these steps don't resolve your problem, you can get help running Windows cont
 
 * StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic
 * Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/)
-* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows)
+* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows)
+