Merge pull request #1330 from deniseschannon/404s

fixing broken links

Author: Denise

content/os/v1.x/en/about/running-rancher-on-rancherOS/_index.md

@@ -37,7 +37,7 @@ rancher:
 ```
 <br>
 
-> **Note:** You can not name the service `rancher-agent` as this will not allow the rancher/agent container to be launched correctly. Please read more about why [you can't name your container as `rancher-agent`](https://rancher.com/docs/rancher/v1.6/en/faqs/agents/#adding-in-name-rancher-agent).
+> **Note:** You can not name the service `rancher-agent` as this will not allow the rancher/agent container to be launched correctly. Please read more about why [you can't name your container as `rancher-agent`]({{< baseurl >}}/rancher/v1.6/en/faqs/agents/#adding-in-name-rancher-agent).
 
 ### Adding in Host Labels
 

content/rancher/v2.x/en/admin-settings/_index.md

@@ -38,6 +38,6 @@ For more information how to create and use PSPs, see [Pod Security Policies]({{<
 
 ## Provisioning Drivers
 
-Drivers in Rancher allow you to manage which providers can be used to provision [hosted Kubernetes clusters]({{< baseurl >}}rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) or [nodes in an infrastructure provider]({{< baseurl >}}rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to allow Rancher to deploy and manage Kubernetes.
+Drivers in Rancher allow you to manage which providers can be used to provision [hosted Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) or [nodes in an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to allow Rancher to deploy and manage Kubernetes.
 
 For more information, see [Provisioning Drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/).

content/rancher/v2.x/en/admin-settings/authentication/azure-ad/_index.md

@@ -122,12 +122,10 @@ To use Azure AD with Rancher you must whitelist Rancher with Azure. You can comp
 1. From the **Reply URLs** blade, enter the URL of your Rancher Server, appended with the verification path: `<MY_RANCHER_URL>/verify-auth-azure`.
 
        >**Tip:** You can find your personalized Azure reply URL in Rancher on the Azure AD Authentication page (Global View > Security Authentication > Azure AD).
-       >
-       > ![Reply URL Example]({{< baseurl >}}/img/rancher/azure-reply-url.png)
 
 1. Click **Save**.
 
-**Result:** Your reply URL is saved. 
+**Result:** Your reply URL is saved.
 
 >**Note:** It can take up to five minutes for this change to take affect, so don't be alarmed if you can't authenticate immediately after Azure AD configuration.
 
@@ -173,19 +171,19 @@ As your final step in Azure, copy the data that you'll use to configure Rancher
 
 From the Rancher UI, enter information about your AD instance hosted in Azure to complete configuration.
 
-Enter the values that you copied to your [text file](#tip).
+Enter the values that you copied to your [text file]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/azure-ad/#tip).
 
 1. Log into Rancher. From the **Global** view, select **Security > Authentication**.
 
 1. Select **Azure AD**.
 
-1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#4-copy-azure-application-data).
+1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#5-copy-azure-application-data).
 
     >**Important:** When entering your Graph Endpoint, remove the tenant ID from the URL, like below.
     >
     ><code>http<span>s://g</span>raph.windows.net/<del>abb5adde-bee8-4821-8b03-e63efdc7701c</del></code>
 
-    The following table maps the values you copied in the Azure portal to the fields in Rancher. 
+    The following table maps the values you copied in the Azure portal to the fields in Rancher.
 
     | Rancher Field      | Azure Value                           |
     | ------------------ | ------------------------------------- |

content/rancher/v2.x/en/backups/_index.md

@@ -9,10 +9,10 @@ This section is devoted to protecting your data in a disaster scenario.
 To protect yourself from a disaster scenario, you should create backups on a regular basis.
 
   - [Rancher Server Backups]({{< baseurl >}}/rancher/v2.x/en/backups/backups)
-  - [Backing up Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/rancher/v2.x/en/cluster-admin/backing-up-etcd/)
+  - [Backing up Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/)
 
 
 In a disaster scenario, you can restore your `etcd` database by restoring a backup.
 
    - [Rancher Server Restorations]({{< baseurl >}}/rancher/v2.x/en/backups/restorations)
-   - [Restoring Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/rancher/v2.x/en/cluster-admin/restoring-etcd/)
+   - [Restoring Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/)

content/rancher/v2.x/en/cluster-provisioning/custom-clusters/agent-options/_index.md

@@ -36,7 +36,7 @@ Rancher deploys an agent on each node to communicate with the node. This pages d
 
 ### Dynamic IP address options
 
-For automation purposes, you can't have a specific IP address in a command as it has to be generic to be used for every node. For this, we have dynamic IP address options. They are used as a value to the existing [IP address options](#ip-address-options). This is supported for `--address` and `--internal-address`.
+For automation purposes, you can't have a specific IP address in a command as it has to be generic to be used for every node. For this, we have dynamic IP address options. They are used as a value to the existing IP address options. This is supported for `--address` and `--internal-address`.
 
 | Value  | Example | Description |
 | ---------- | -------------------- | ----------- |

content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/ack/_index.md

@@ -1,5 +1,5 @@
 ---
-title: Creating an Alibaba ACK Cluster
+title: Creating an Aliyun ACK Cluster
 shortTitle: Alibaba Cloud Container Service for Kubernetes
 weight: 2120
 ---

content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/eks/_index.md

@@ -24,7 +24,7 @@ Use Rancher to set up and configure your Kubernetes cluster.
 
 1. {{< step_create-cluster_member-roles >}}
 
-1. Configure **Account Access** for the EKS cluster. Complete each drop-down and field using the information obtained in [2. Create Access Key and Secret Key](#2-create-access-key-and-secret-key).
+1. Configure **Account Access** for the EKS cluster. Complete each drop-down and field using the information obtained in [2. Create Access Key and Secret Key](#prerequisites-in-amazon-web-services).
 
     | Setting    | Description                                                                                                          |
     | ---------- | -------------------------------------------------------------------------------------------------------------------- |

content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md

@@ -34,7 +34,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2.
 
   1. Complete each of the following forms using information available from the [EC2 Management Console](https://aws.amazon.com/ec2).
 
-		- **Account Access** is where you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine. See [Prerequisistes](#prerequisistes) how to create the Access Key and Secret Key and the needed permissions.
+		- **Account Access** is where you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine. See [Prerequisistes](#prerequisites) how to create the Access Key and Secret Key and the needed permissions.
 
 		{{< step_create-cloud-credential >}}
 

content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md

@@ -121,7 +121,7 @@ See [Docker Root Directory](#docker-root-directory).
 
 #### enable_cluster_monitoring
 
-Option to enable or disable [Cluster Monitoring]({{< baseurl >}}/rancher/v2.x/en/tools/monitoring/).
+Option to enable or disable [Cluster Monitoring]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/).
 
 #### enable_network_policy
 

content/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md

@@ -15,7 +15,7 @@ This guide walks you through create of a custom cluster that includes 3 nodes: a
 
 >**Notes:**
 >
->- For a summary of Kubernetes features supported in Windows, see [Using Windows Server Containers in Kubernetes](https://kubernetes.io/docs/getting-started-guides/windows/#supported-features).
+>- For a summary of Kubernetes features supported in Windows, see [Using Windows in Kubernetes](https://kubernetes.io/docs/setup/windows/intro-windows-in-kubernetes/).
 >- Windows containers must run on Windows Server 1803 nodes. Windows Server 1709 and earlier versions do not support Kubernetes properly.
 >- Containers built for Windows Server 1709 or earlier do not run on Windows Server 1803. You must build containers on Windows Server 1803 to run these containers on Windows Server 1803.
 
@@ -28,12 +28,11 @@ When setting up a custom cluster with support for Windows nodes and containers,
 <!-- TOC -->
 
 - [1. Provision Hosts](#1-provision-hosts)
-- [2. Cloud-host VM Networking Configuration](#2-cloud-host-vm-networking-configuration)
+- [2. Cloud-host VM Networking Configuration](#2-cloud-hosted-vm-networking-configuration)
 - [3. Create the Custom Cluster](#3-create-the-custom-cluster)
 - [4. Add Linux Host for Ingress Support](#4-add-linux-host-for-ingress-support)
 - [5. Adding Windows Workers](#5-adding-windows-workers)
-- [6. Cloud-host VM Routes Configuration](#6-cloud-host-vm-routes-configuration)
-- [Troubleshooting](#troubleshooting)
+- [6. Cloud-host VM Routes Configuration](#6-cloud-hosted-vm-routes-configuration)
 
 <!-- /TOC -->
 
@@ -43,14 +42,14 @@ To begin provisioning a custom cluster with Windows support, prepare your host s
 
 - Cloud-hosted VMs
 - VMs from virtualization clusters
-- Bare-metal servers 
+- Bare-metal servers
 
 The table below lists the [Kubernetes roles]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) you'll assign to each host, although you won't enable these roles until further along in the configuration process—we're just informing you of each node's purpose. The first node, a Linux host, is primarily responsible for managing the Kubernetes control plane, although, in this use case, we're installing all three roles on this node. Node 2 is also a Linux worker, which is responsible for Ingress support. Finally, the third node is your Windows worker, which will run your Windows applications.
 
 Node    | Operating System | Future Cluster Role(s)
 --------|------------------|------
 Node 1  | Linux (Ubuntu Server 16.04 recommended)           | [Control Plane]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#control-plane-nodes), [etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#etcd), [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
-Node 2  | Linux (Ubuntu Server 16.04 recommended)           | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes) (This node is used for Ingress support) 
+Node 2  | Linux (Ubuntu Server 16.04 recommended)           | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes) (This node is used for Ingress support)
 Node 3  | Windows (*Windows Server 1803 required*)          | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
 
 ### Requirements
@@ -115,7 +114,7 @@ After the initial provisioning of your custom cluster, your cluster only has a s
 
 1. Using the content menu, open the custom cluster your created in [2. Create the Custom Cluster](#2-create-the-custom-cluster).
 
-1. From the main menu, select **Nodes**. 
+1. From the main menu, select **Nodes**.
 
 1. Click **Edit Cluster**.
 
@@ -127,15 +126,15 @@ After the initial provisioning of your custom cluster, your cluster only has a s
 
 1. Log in to your Linux host using a remote Terminal connection. Run the command copied to your clipboard.
 
-1. From **Rancher**, click **Save**. 
+1. From **Rancher**, click **Save**.
 
 **Result:** The worker role is installed on your Linux host, and the node registers with Rancher.
 
 ## 5. Adding Windows Workers
 
 You can add Windows hosts to a custom cluster by editing the cluster and choosing the **Windows** option.
 
-1. From the main menu, select **Nodes**. 
+1. From the main menu, select **Nodes**.
 
 1. Click **Edit Cluster**.
 
@@ -147,7 +146,7 @@ You can add Windows hosts to a custom cluster by editing the cluster and choosin
 
 1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **Command Prompt (CMD)**.
 
-1. From Rancher, click **Save**. 
+1. From Rancher, click **Save**.
 
 1. **Optional:** Repeat these instruction if you want to add more Windows nodes to your cluster.
 
@@ -157,11 +156,11 @@ You can add Windows hosts to a custom cluster by editing the cluster and choosin
 
 In Windows clusters, containers communicate with each other using the `host-gw` mode of Flannel. In `host-gw` mode, all containers on the same node belong to a private subnet, and traffic routes from a subnet on one node to a subnet on another node through the host network.
 
-- When worker nodes are provisioned on AWS, virtualization clusters, or bare metal servers, make sure they belong to the same layer 2 subnet. If the nodes don't belong to the same layer 2 subnet, `host-gw` networking will not work. Please contact [Rancher support](https://rancher.com/support/) if your worker nodes on AWS, virtualization clusters, or bare metal servers don't belong to the same layer 2 network.
+- When worker nodes are provisioned on AWS, virtualization clusters, or bare metal servers, make sure they belong to the same layer 2 subnet. If the nodes don't belong to the same layer 2 subnet, `host-gw` networking will not work.
 
 - When worker nodes are provisioned on GCE or Azure, they are not on the same layer 2 subnet. Nodes on GCE and Azure belong to a routable layer 3 network. Follow the instructions below to configure GCE and Azure so that the cloud network knows how to route the host subnets on each node.
 
-To configure host subnet routing on GCE or Azure, first run the following command to find out the host subnets on each worker node: 
+To configure host subnet routing on GCE or Azure, first run the following command to find out the host subnets on each worker node:
 
 ```bash
 kubectl get nodes -o custom-columns=nodeName:.metadata.name,nodeIP:status.addresses[0].address,routeDestination:.spec.podCIDR
@@ -176,4 +175,3 @@ Azure VM | For Azure, create a routing table: [Custom Routes: User-defined](http
 
 
 ` `
-