From 49d8df51c3ebb992b0e5392dd76f5b8b87de3ee4 Mon Sep 17 00:00:00 2001
From: Sebastiaan van Steenis <mail@superseb.nl>
Date: Thu, 28 Mar 2019 15:19:37 +0100
Subject: [PATCH 01/14] Add note in HA install on RKE files to save

---
 .../install-kube/_index.md                          | 13 +++++++++++--
 .../en/installation/ha/kubernetes-rke/_index.md     |  9 ++++++++-
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md b/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md
index fd4210029e9..bfb66e89b1d 100644
--- a/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md
@@ -51,8 +51,6 @@ private_registries:
   is_default: true
 ```
 
-
-
 ## B. Run RKE
 
 After configuring `rancher-cluster.yml`, open Terminal and change directories to the RKE binary. Then enter the command below to stand up your high availability cluster.
@@ -61,4 +59,15 @@ After configuring `rancher-cluster.yml`, open Terminal and change directories to
 rke up --config ./rancher-cluster.yml
 ```
 
+## C. Save Your Files
+
+> **Important**
+> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
+
+Save a copy of the following files in a secure location:
+
+- `rancher-cluster.yml`: The RKE cluster configuration file.
+- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/v0.1.x/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
+- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{< baseurl >}}/rke/v0.1.x/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._ 
+
 ### [Next: Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher)
diff --git a/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md
index 5a8d9c65ff0..08e7fd98856 100644
--- a/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md
@@ -112,7 +112,14 @@ kube-system     rke-network-plugin-deploy-job-6pbgj       0/1       Completed
 
 ### Save Your Files
 
-Save a copy of the `kube_config_rancher-cluster.yml` and `rancher-cluster.yml` files. You will need these files to maintain and upgrade your Rancher instance.
+> **Important**
+> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
+
+Save a copy of the following files in a secure location:
+
+- `rancher-cluster.yml`: The RKE cluster configuration file.
+- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/v0.1.x/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
+- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{< baseurl >}}/rke/v0.1.x/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
 
 ### Issues or errors?
 

From db93f87ced1c51c2bd629e1c9be2c8d633256b32 Mon Sep 17 00:00:00 2001
From: dnoland1 <dnoland@rancher.com>
Date: Mon, 1 Apr 2019 09:25:20 -0700
Subject: [PATCH 02/14] Few grammar and re-wording changes

---
 .../cluster-admin/cleaning-cluster-nodes/_index.md   | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md b/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md
index e147062f684..5140e780a9a 100644
--- a/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md
@@ -50,7 +50,7 @@ When a node is unreachable and removed from the cluster, the automatic cleaning
 
 ## Imported Cluster Nodes
 
-For imported clusters, the process for removing Rancher from its nodes is a little different. You can the option of simply deleting the cluster in the Rancher UI, or your can run a script that removes Rancher components from the nodes. Both options make the same deletions.
+For imported clusters, the process for removing Rancher from its nodes is a little different. You have the option of simply deleting the cluster in the Rancher UI, or your can run a script that removes Rancher components from the nodes. Both options make the same deletions.
 
 {{% tabs %}}
 {{% tab "By UI / API" %}}
@@ -82,9 +82,9 @@ Rather than cleaning imported cluster nodes using the Rancher UI, you can run a
     chmod +x user-cluster.sh
     ```
 
-1. **Air Gap Users Only:** Open `user-cluster.sh` and replace `yaml_url` with the URL in `user-cluster.yml`.
+1. **Air Gap Environments Only:** Open `user-cluster.sh` and replace `yaml_url` with the URL in `user-cluster.yml`.
 
-    If you aren't an air gap user, skip this step.
+    If you don't have an air gap environment, skip this step.
 
 1. From the same directory, run the script and provide the `rancher/rancher-agent` image version which should be equal to the version of Rancher used to manage the cluster. (`<RANCHER_VERSION>`):
 
@@ -103,7 +103,7 @@ Rather than cleaning imported cluster nodes using the Rancher UI, you can run a
 
 ### Docker Containers, Images, and Volumes
 
-Based on what role you assigned to the node, Kubernetes components in containers, containers belonging to overlay networking, DNS, ingress controller and Rancher agent. (and pods you created that have been scheduled to this node)
+Based on what role you assigned to the node, there are Kubernetes components in containers, containers belonging to overlay networking, DNS, ingress controller and Rancher agent. (and pods you created that have been scheduled to this node)
 
 **To clean all Docker containers, images and volumes:**
 
@@ -177,9 +177,7 @@ rm -rf /etc/ceph \
 
 ### Network Interfaces and Iptables
 
-The remaining two components that are changed/configured are (virtual) network interfaces and iptables rules. Both are non-persistent to the node, meaning that they will be cleared after a restart of the node.
-
-This is the recommended method.
+The remaining two components that are changed/configured are (virtual) network interfaces and iptables rules. Both are non-persistent to the node, meaning that they will be cleared after a restart of the node. To remove these components, a restart is recommended.
 
 **To restart a node:**
 

From 1b4975c639130aa0dd3de8e6a62115e3837dd32f Mon Sep 17 00:00:00 2001
From: dnoland1 <dnoland@rancher.com>
Date: Mon, 1 Apr 2019 10:25:52 -0700
Subject: [PATCH 03/14] Grammar and cleanup for Project Administrator page

---
 .../rancher/v2.x/en/project-admin/_index.md    | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/content/rancher/v2.x/en/project-admin/_index.md b/content/rancher/v2.x/en/project-admin/_index.md
index 451b9f9c8b9..9d024be480f 100644
--- a/content/rancher/v2.x/en/project-admin/_index.md
+++ b/content/rancher/v2.x/en/project-admin/_index.md
@@ -3,12 +3,12 @@ title: Project Administration
 weight: 2500
 ---
 
-_Projects_ are objects introduced in Rancher that help organize namespaces in your Kubernetes cluster. You can use projects to create multi-tenant clusters, which allows a group of users to share the same underlying resources without interacting with each other's applications. Typically, any
+_Projects_ are objects introduced in Rancher that help organize namespaces in your Kubernetes cluster. You can use projects to create multi-tenant clusters, which allows a group of users to share the same underlying resources without interacting with each other's applications.
 
 In terms of hierarchy:
 
-- Clusters contain projects.
-- Projects contain namespaces.
+- Clusters contain projects
+- Projects contain namespaces
 
 Within Rancher, projects allow you to manage multiple namespaces as a single entity. In native Kubernetes, which does not include projects, features like role-based access rights or cluster resources are assigned to individual namespaces. In clusters where multiple namespaces require the same set of access rights, assigning these rights to each individual namespace can become tedious. Even though all namespaces require the same rights, there's no way to apply those rights to all of your namespaces in a single action. You'd have to repetitively assign these rights to each namespace!
 
@@ -16,12 +16,12 @@ Rancher projects resolve this issue by allowing you to apply resources and acces
 
 You can use projects to perform actions like:
 
-- [Assign users access to a group of namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/project-members).
-- Assign users [specific roles in a project]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/).
+- [Assign users access to a group of namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/project-members)
+- Assign users [specific roles in a project]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/)
 - [Edit project settings]({{< baseurl >}}/rancher/v2.x/en/project-admin/editing-projects/)
-- [Set Resource Quotas]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/)
-- [Manage Namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/)
-- [Configure Tools]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/)
+- [Set resource quotas]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/)
+- [Manage namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/)
+- [Configure tools]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/)
 
 ### Authorization
 
@@ -33,7 +33,7 @@ Whoever creates the project automatically becomes a [project owner]({{< baseurl
 
 To switch between projects, use the drop-down available in the navigation bar. Alternatively, you can switch between projects directly in the navigation bar.
 
-1. From the **Global** view, navigate to the project that you want to configure pipelines.
+1. From the **Global** view, navigate to the project that you want to configure.
 
 1. Select **Projects/Namespaces** from the navigation bar.
 

From 4083ce15cd5fe405e88d2b2c9250914fd6222354 Mon Sep 17 00:00:00 2001
From: Denise Schannon <denise@rancher.com>
Date: Wed, 27 Mar 2019 17:41:09 -0700
Subject: [PATCH 04/14] fixing image/link issues

---
 .../discover-services/_index.md               | 12 -----
 .../en/v1.6-migration/get-started/_index.md   |  6 +--
 .../v1.6-migration/load-balancing/_index.md   | 38 --------------
 .../en/v1.6-migration/monitor-apps/_index.md  | 23 ---------
 .../run-migration-tool/_index.md              | 22 +-------
 .../schedule-workloads/_index.md              | 51 +------------------
 6 files changed, 5 insertions(+), 147 deletions(-)

diff --git a/content/rancher/v2.x/en/v1.6-migration/discover-services/_index.md b/content/rancher/v2.x/en/v1.6-migration/discover-services/_index.md
index 0705c53be87..9c10255eba0 100644
--- a/content/rancher/v2.x/en/v1.6-migration/discover-services/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/discover-services/_index.md
@@ -7,10 +7,6 @@ Service discovery is one of the core functionalities of any container-based envi
 
 This document will also show you how to link the workloads and services that you migrated into Rancher v2.x. When you parsed your services from v1.6 using migration-tools CLI, it output two files for each service: one deployment manifest and one service manifest. You'll have to link these two files together before the deployment works correctly in v2.x.
 
-<figcaption>Resolve the <code>output.txt</code> Link Directive</figcaption>
-
-![Resolve Link Directive]({{< baseurl >}}/img/rancher/resolve-links.png)
-
 ## In This Document
 
 <!-- TOC -->
@@ -62,11 +58,6 @@ When you migrate v1.6 services to v2.x, Rancher does not automatically create a
 
 In the image below, the `web-deployment.yml` and `web-service.yml` files [created after parsing]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/run-migration-tool/#migration-example-file-output) our [migration example services]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/#migration-example-files) are linked together.
 
-<figcaption>Linked Workload and Kubernetes Service</figcaption>
-
-![Linked Workload and Kubernetes Service]({{< baseurl >}}/img/rancher/linked-service-workload.png)
-
-
 ### Service Name Alias Creation
 
 Just as you can create an alias for Rancher v1.6 services, you can do the same for Rancher v2.x workloads. Similarly, you can also create DNS records pointing to services running externally, using either their hostname or IP address. These DNS records are Kubernetes service objects.
@@ -75,9 +66,6 @@ Using the v2.x UI, use the context menu to navigate to the `Project` view and ch
 
 Click **Add Record** to create new DNS records. Then view the various options supported to link to external services or to create aliases for another workload, DNS record, or set of pods.
 
-<figcaption>Add Service Discovery Record</figcaption>
-![Add Service Discovery Record]({{< baseurl >}}/img/rancher/add-record.png)
-
 The following table indicates which alias options are implemented natively by Kubernetes and which options are implemented by Rancher leveraging Kubernetes.
 
 Option | Kubernetes-implemented? | Rancher-implemented?
diff --git a/content/rancher/v2.x/en/v1.6-migration/get-started/_index.md b/content/rancher/v2.x/en/v1.6-migration/get-started/_index.md
index 59704fd3c8b..f5a1b6147d9 100644
--- a/content/rancher/v2.x/en/v1.6-migration/get-started/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/get-started/_index.md
@@ -40,10 +40,6 @@ After provisioning your node(s), install Rancher:
 
 After your Rancher v2.x Server is installed, we recommend configuring external authentication (like Active Directory or GitHub) so that users can log into Rancher using their single sign-on. For a full list of supported authentication providers and instructions on how to configure them, see [Authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication).
 
-<figcaption>Rancher v2.x Authentication</figcaption>
-
-![Rancher v2.x Authentication]({{< baseurl >}}/img/rancher/auth-providers.svg)
-
 ### Local Users
 
 Although we recommend using an external authentication provider, Rancher v1.6 and v2.x both offer support for users local to Rancher. However, these users cannot be migrated from Rancher v1.6 to v2.x. If you used local users in Rancher v1.6 and want to continue this practice in v2.x, you'll need to [manually recreate these user accounts]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) and assign them access rights.
@@ -82,7 +78,7 @@ When you create a cluster, two projects are automatically created:
 - The `System` project, which includes system namespaces where important Kubernetes resources are running (like ingress controllers and cluster dns services)
 - The `Default` project.
 
-However, for production environments, we recommend [creating your own project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#creating-projects) and giving it a descriptive name.
+However, for production environments, we recommend [creating your own project]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/#creating-projects) and giving it a descriptive name.
 
 After provisioning a new cluster and project, you can authorize your users to access and use project resources. Similarly to Rancher v1.6 environments, Rancher v2.x allows you to [assign users to projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/). By assigning users to projects, you can limit what applications and resources a user can access.
 
diff --git a/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md b/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md
index 29b5e2ece62..18a5a5980da 100644
--- a/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md
@@ -9,10 +9,6 @@ As outlined in [its documentation]({{< baseurl >}}/rancher/v1.6/en/cattle/adding
 
 If you encounter the `output.txt` text below after parsing your v1.6 Compose files to Kubernetes manifests, you'll have to resolve it by manually creating a load balancer in v2.x.
 
-<figcaption><code>output.txt</code> Load Balancer Directive</figcaption>
-
-![Resolve Load Balancer Directive]({{< baseurl >}}/img/rancher/resolve-load-balancer.png)
-
 ## In This Document
 
 <!-- TOC -->
@@ -53,17 +49,8 @@ In Rancher v1.6 you could deploy a scalable load balancer service within your st
 
 <!-- add comparison table-->
 
-<figcaption>Rancher v1.6 Load Balancing Architecture</figcaption>
-
-![Rancher v1.6 Load Balancing]({{< baseurl >}}/img/rancher/cattle-load-balancer.svg)
-
 The Rancher v2.x Ingress Controller is a DaemonSet, it is globally deployed on all schedulable nodes to serve your entire Kubernetes Cluster. Therefore, when you program the Ingress rules, you must use a unique hostname and path to point to your workloads, as the load balancer node IP addresses and ports 80 and 443 are common access points for all workloads.
 
-<figcaption>Rancher v2.x Load Balancing Architecture</figcaption>
-
-
-![Rancher v2.x Load Balancing]({{< baseurl >}}/img/rancher/kubernetes-load-balancer.svg)
-
 ## Ingress Caveats
 
 Although Rancher v2.x supports HTTP and HTTPS hostname and path-based load balancing, you must use unique host names and paths when configuring your workloads. This limitation derives from:
@@ -79,14 +66,9 @@ You can launch a new load balancer to replace your load balancer from v1.6. Usin
 
 >**Prerequisite:** Before deploying Ingress, you must have a workload deployed that's running a scale of two or more pods.
 >
->![Workload Scale]({{< baseurl >}}/img/rancher/workload-scale.png)
 
 For balancing between these two pods, you must create a Kubernetes Ingress rule. To create this rule, navigate to your cluster and project, and then select the **Load Balancing** tab. Then click **Add Ingress**. This GIF below depicts how to add Ingress to one of your projects.
 
-<figcaption>Browsing to Load Balancer Tab and Adding Ingress</figcaption>
-
-![Adding Ingress]({{< baseurl >}}/img/rancher/add-ingress.gif)
-
 Similar to a service/port rules in Rancher v1.6, here you can specify rules targeting your workload's container port. The sections below demonstrate how to create Ingress rules.
 
 ### Configuring Host- and Path-Based Routing
@@ -95,18 +77,8 @@ Using Rancher v2.x, you can add Ingress rules that are based on host names or a
 
 For example, let's say you have multiple workloads deployed to a single namespace. You can add an Ingress to route traffic to these two workloads using the same hostname but different paths, as depicted in the image below. URL requests to `foo.com/name.html` will direct users to the `web` workload, and URL requests to `foo.com/login` will direct users to the `chat` workload.
 
-<figcaption>Ingress: Path-Based Routing Configuration</figcaption>
-
-![Ingress: Path-Based Routing Configuration]({{< baseurl >}}/img/rancher/add-ingress-form.png)
-
-
 Rancher v2.x also places a convenient link to the workloads on the Ingress record. If you configure an external DNS to program the DNS records, this hostname can be mapped to the Kubernetes Ingress address.
 
-<figcaption>Workload Links</figcaption>
-
-![Load Balancer Links to Workloads]({{< baseurl >}}/img/rancher/load-balancer-links.png)
-
-
 The Ingress address is the IP address in your cluster that the Ingress Controller allocates for your workload. You can reach your workload by browsing to this IP address. Use `kubectl` command below to see the Ingress address assigned by the controller:
 
 ```
@@ -120,10 +92,6 @@ Rancher v2.x Ingress functionality supports the HTTPS protocol, but if you want
 - We recommend [uploading a certificate]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/) from a known certificate authority (you'll have to do this before configuring Ingress). Then, while configuring your load balancer, use the **Choose a certificate** option and select the uploaded certificate that you want to use.
 - If you have configured [NGINX default certificate]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/#configuring-an-nginx-default-certificate), you can select **Use default ingress controller certificate**.
 
-<figcaption>Load Balancer Configuration: SSL/TLS Certificate Section</figcaption>
-
-![SSL/TLS Certificates Section]({{< baseurl >}}/img/rancher/load-balancer-ssl-certs.png)
-
 ### TCP Load Balancing Options
 
 #### Layer-4 Load Balancer
@@ -132,10 +100,6 @@ For the TCP protocol, Rancher v2.x supports configuring a Layer 4 load balancer
 
 For example, if we create a deployment named `myapp` and specify a Layer 4 load balancer in the **Port Mapping** section, Rancher will automatically add an entry to the **Load Balancer** tab named `myapp-loadbalancer`.
 
-<figcaption>Workload Deployment: Layer 4 Load Balancer Creation</figcaption>
-
-![Deploy Layer-4 Load Balancer]({{< baseurl >}}/img/rancher/deploy-workload-load-balancer.png)
-
 Once configuration of the load balancer succeeds, the Rancher UI provides a link to your workload's public endpoint.
 
 #### NGINX Ingress Controller TCP Support by ConfigMaps
@@ -146,8 +110,6 @@ However, there is a workaround to use NGINX's TCP balancing by creating a Kubern
 
 To configure NGINX to expose your services via TCP, you can add the ConfigMap `tcp-services` that should exist in the `ingress-nginx` namespace. This namespace also contains the NGINX Ingress Controller pods.
 
-![Layer-4 Load Balancer: ConfigMap Workaround]({{< baseurl >}}/img/rancher/layer-4-lb-config-map.png)
-
 The key in the ConfigMap entry should be the TCP port that you want to expose for public access: `<namespace/service name>:<service port>`. As shown above, two workloads are listed in the `Default` namespace. For example, the first entry in the ConfigMap above instructs NGINX to expose the `myapp` workload (the one in the `default` namespace that's listening on private port 80) over external port `6790`. Adding these entries to the ConfigMap automatically updates the NGINX pods to configure these workloads for TCP balancing. The workloads exposed should be available at `<NodeIP>:<TCP Port>`. If they are not accessible, you might have to expose the TCP port explicitly using a NodePort service.
 
 ## Rancher v2.x Load Balancing Limitations
diff --git a/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md b/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md
index 29338416f72..ad16e2cac2c 100644
--- a/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md
@@ -11,11 +11,6 @@ Use this document to correct Rancher v2.x workloads and services that list `heal
 
 For example, for the image below, we would configure liveness probes for the `web` and `weblb` workloads (i.e., the Kubernetes manifests output by migration-tools CLI).
 
-<figcaption>Resolve <code>health_check</code> for the <code>web</code> and <code>webLB</code> Workloads</figcaption>
-
-
-![Resolve health_check]({{< baseurl >}}/img/rancher/resolve-health-checks.png)
-
 ## In This Document
 
 <!-- TOC -->
@@ -42,9 +37,6 @@ The health check microservice features two types of health checks, which have a
 
 The following diagram displays the health check microservice evaluating a container running Nginx. Notice that the microservice is making its check across nodes.
 
-![Rancher v1.6 Health Checks]({{< baseurl >}}/img/rancher/healthcheck.svg)
-
-
 ## Rancher v2.x Health Checks
 
 In Rancher v2.x, the health check microservice is replaced with Kubernete's native health check mechanisms, called _probes_. These probes, similar to the Rancher v1.6 health check microservice, monitor the health of pods over TCP and HTTP.
@@ -71,8 +63,6 @@ Kubernetes includes two different _types_ of probes: liveness checks and readine
 
 The following diagram displays kubelets running probes on containers they are monitoring ([kubelets](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) are the primary "agent" running on each node). The node on the left is running a liveness probe, while the one of the right is running a readiness check. Notice that the kubelet is scanning containers on its host node rather than across nodes, as in Rancher v1.6.
 
-![Rancher v2.x Probes]({{< baseurl >}}/img/rancher/probes.svg)
-
 ## Configuring Probes in Rancher v2.x
 
 The [migration-tool CLI]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/run-migration-tool/) cannot parse health checks from Compose files to Kubernetes manifest. Therefore, if want you to add health checks to your Rancher v2.x workloads, you'll have to add them manually.
@@ -83,10 +73,6 @@ If the probe fails, the container is restarted per the restartPolicy defined in
 
 Configure probes by using the **Health Check** section while editing deployments called out in `output.txt`.
 
-<figcaption>Edit Deployment: Health Check Section</figcaption>
-
-![Health Check Section]({{< baseurl >}}/img/rancher/health-check-section.png)
-
 ### Configuring Checks
 
 While you create a workload using Rancher v2.x, we recommend configuring a check that monitors the health of the deployment's pods.
@@ -99,8 +85,6 @@ TCP checks monitor your deployment's health by attempting to open a connection t
 
 You can configure the probe along with values for specifying its behavior by selecting the **TCP connection opens successfully** option in the **Health Check** section. For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/). For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#health-check-parameter-mappings).
 
-![TCP Check]({{< baseurl >}}/img/rancher/readiness-check-tcp.png)
-
 When you configure a readiness check using Rancher v2.x, the `readinessProbe` directive and the values you've set are added to the deployment's Kubernetes manifest. Configuring a readiness check also automatically adds a liveness check (`livenessProbe`) to the deployment.
 
 <!--
@@ -137,8 +121,6 @@ HTTP checks monitor your deployment's health by sending an HTTP GET request to a
 
 You can configure the probe along with values for specifying its behavior by selecting the **HTTP returns successful status** or **HTTPS returns successful status**. For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).  For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#healthcheck-parameter-mappings).
 
-![HTTP Check]({{< baseurl >}}/img/rancher/readiness-check-http.png)
-
 When you configure a readiness check using Rancher v2.x, the `readinessProbe` directive and the values you've set are added to the deployment's Kubernetes manifest. Configuring a readiness check also automatically adds a liveness check (`livenessProbe`) to the deployment.
 
 {{% /tab %}}
@@ -149,17 +131,12 @@ When you configure a readiness check using Rancher v2.x, the `readinessProbe` di
 
 While configuring a readiness check for either the TCP or HTTP protocol, you can configure a separate liveness check by clicking the **Define a separate liveness check**. For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#health-check-parameter-mappings).
 
-![Separate Liveness Check]({{< baseurl >}}/img/rancher/separate-check.png)
-
 ### Additional Probing Options
 
 Rancher v2.x, like v1.6, lets you perform health checks using the TCP and HTTP protocols. However, Rancher v2.x also lets you check the health of a pod by running a command inside of it. If the container exits with a code of `0` after running the command, the pod is considered healthy.
 
 You can configure a liveness or readiness check that executes a command that you specify by selecting the `Command run inside the container exits with status 0` option from **Health Checks** while [deploying a workload]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).
 
-![Healthcheck Execute Command]({{< baseurl >}}/img/rancher/healthcheck-cmd-exec.png)
-
-
 #### Health Check Parameter Mappings
 
 While configuring readiness checks and liveness checks, Rancher prompts you to fill in various timeout and threshold values that determine whether the probe is a success or failure. The reference table below shows you the equivalent health check values from Rancher v1.6.
diff --git a/content/rancher/v2.x/en/v1.6-migration/run-migration-tool/_index.md b/content/rancher/v2.x/en/v1.6-migration/run-migration-tool/_index.md
index b192c7c12a3..c701b1e284a 100644
--- a/content/rancher/v2.x/en/v1.6-migration/run-migration-tool/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/run-migration-tool/_index.md
@@ -20,7 +20,7 @@ This command line interface tool will:
 - [A. Download the migration-tools CLI](#a-download-the-migration-tools-cli)
 - [B. Configure the migration-tools CLI](#b-configure-the-migration-tools-cli)
 - [C. Run the migration-tools CLI](#c-run-the-migration-tools-cli)
-- [D. Deploy Services Using Rancher CLI](#d-deploy-services-using-rancher-cli)
+- [D. Deploy Services Using Rancher CLI](#d-re-deploy-services-as-kubernetes-manifests)
 - [What Now?](#what-now)
 
 
@@ -85,7 +85,7 @@ Next, use the migration-tools CLI to export all stacks in all of the Cattle envi
 
     >**Note:** If you omit the `--docker-file` and `--rancher-file` options from your command, migration-tools uses the current working directory to find Compose files.
 
->**Want full usage and options for the migration-tools CLI?** See the [Migration Tools CLI Reference]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/migration-tools-ref/).
+>**Want full usage and options for the migration-tools CLI?** See the [Migration Tools CLI Reference]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/run-migration-tool/migration-tools-ref/).
 
 ### migration-tools CLI Output
 
@@ -238,15 +238,10 @@ status: {}
 
 You can deploy the Kubernetes manifests created by migration-tools by importing them into Rancher v2.x.
 
-<figcaption>Deploy Services: Import Kubernetes Manifest</figcaption>
-
 >**Receiving an `ImportYaml Error`?**
 >
 >Delete the YAML directive listed in the error message. These are YAML directives from your v1.6 services that Kubernetes can't read.
 
-
-![Deploy Services]({{< baseurl >}}/img/rancher/deploy-service.gif)
-
 {{% /tab %}}
 {{% tab "Rancher CLI" %}}
 
@@ -266,27 +261,14 @@ Use the following Rancher CLI commands to deploy your application using Rancher
 
 Following importation, you can view your v1.6 services in the v2.x UI as Kubernetes manifests by using the context menu to select `<CLUSTER> > <PROJECT>` that contains your services. The imported manifests will display on the **Workloads** and **Service Discovery** tabs.
 
-<figcaption>Imported Services</figcaption>
-
-![Imported Services]({{< baseurl >}}/img/rancher/imported-workloads.png)
-
-
 ## What Now?
 
 Although the migration-tool CLI parses your Rancher v1.6 Compose files to Kubernetes manifests, there are discrepancies between v1.6 and v2.x that you must address by manually editing your parsed [Kubernetes manifests](#output). In other words, you need to edit each workload and service imported into Rancher v2.x, as displayed below.
 
-<figcaption>Edit Migrated Services</figcaption>
-
-![Edit Migrated Workload]({{< baseurl >}}/img/rancher/edit-migration-workload.gif)
-
 As mentioned in [Migration Tools CLI Output](#migration-tools-cli-output), the `output.txt` files generated during parsing lists the manual steps you must make for each deployment. Review the upcoming topics for more information on manually editing your Kubernetes specs.
 
 Open your `output.txt` file and take a look at its contents. When you parsed your Compose files into Kubernetes manifests, migration-tools CLI output a manifest for each workload that it creates for Kubernetes. For example, our when our [Migration Example Files]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/#migration-example-files) are parsed into Kubernetes manifests, `output.txt` lists each resultant parsed [Kubernetes manifest file](#migration-example-file-output) (i.e., workloads). Each workload features a list of action items to restore operations for the workload in v2.x.
 
-<figcaption>Output.txt Example</figcaption>
-
-![output.txt]({{< baseurl >}}/img/rancher/output-dot-text.png)
-
 The following table lists possible directives that may appear in `output.txt`, what they mean, and links on how to resolve them.
 
 Directive | Instructions
diff --git a/content/rancher/v2.x/en/v1.6-migration/schedule-workloads/_index.md b/content/rancher/v2.x/en/v1.6-migration/schedule-workloads/_index.md
index 185a1cca47f..826dd06bfee 100644
--- a/content/rancher/v2.x/en/v1.6-migration/schedule-workloads/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/schedule-workloads/_index.md
@@ -13,8 +13,6 @@ You can schedule your migrated v1.6 services while editing a deployment. Schedul
 
 <figcaption>Editing Workloads: Workload Type and Node Scheduling Sections</figcaption>
 
-![Workload Type and Node Scheduling Sections]({{< baseurl >}}/img/rancher/migrate-schedule-workloads.png)
-
 
 ## In This Document
 
@@ -40,7 +38,6 @@ Rancher v2.x retains _all_ methods available in v1.6 for scheduling your service
 
 In v1.6, you would schedule a service to a host while adding a service to a Stack. In Rancher v2.x., the equivalent action is to schedule a workload for deployment. The following composite image shows a comparison of the UI used for scheduling in Rancher v2.x versus v1.6.
 
-![Node Scheduling: Rancher v2.x vs v1.6]({{< baseurl >}}/img/rancher/node-scheduling.png)
 
 ## Node Scheduling Options
 
@@ -54,8 +51,8 @@ Option | v1.6 Feature | v2.x Feature
 -------|------|------
 [Schedule a certain number of pods?](#schedule-a-certain-number-of-pods) | ✓ | ✓
 [Schedule pods to specific node?](#scheduling-pods-to-a-specific-node) | ✓ | ✓
-[Schedule to nodes using labels?](#scheduling-pods-using-labels) | ✓ | ✓
-[Schedule to nodes using label affinity/anti-affinity rules?](#scheduling-pods-using-affinityanti-affinity-label) | ✓ | ✓
+[Schedule to nodes using labels?](#applying-labels-to-nodes-and-pods) | ✓ | ✓
+[Schedule to nodes using label affinity/anti-affinity rules?](#label-affinity-antiaffinity) | ✓ | ✓
 [Schedule based on resource constraints?](#scheduling-pods-using-resource-constraints) | ✓ | ✓
 [Preventing scheduling specific services to specific hosts?](#preventing-scheduling-specific-services-to-specific-nodes) | ✓ | ✓
 [Schedule services globally?](#scheduling-global-services) | ✓ | ✓
@@ -65,17 +62,8 @@ Option | v1.6 Feature | v2.x Feature
 
 In v1.6, you could control the number of container replicas deployed for a service. You can schedule pods the same way in v2.x, but you'll have to set the scale manually while editing a workload.
 
-
-![Resolve Scale]({{< baseurl >}}/img/rancher/resolve-scale.png)
-
 During migration, you can resolve `scale` entries in `output.txt` by setting a value for the **Workload Type** option **Scalable deployment** depicted below.
 
-<figcaption>Scalable Deployment Option</figcaption>
-
-![Workload Scale]({{< baseurl >}}/img/rancher/workload-type-option.png)
-
-
-
 ### Scheduling Pods to a Specific Node
 
 Just as you could schedule containers to a single host in Rancher v1.6, you can schedule pods to single node in Rancher v2.x
@@ -83,18 +71,12 @@ Just as you could schedule containers to a single host in Rancher v1.6, you can
 As you deploy a workload, use the **Node Scheduling** section to choose a node to run your pods on. The workload below is being scheduled to deploy an Nginx image with a scale of two pods on a specific node.
 <!-- Question: What would be a good use case for use of a scheduling pods on the same node?-->
 
-<figcaption>Rancher v2.x: Workload Deployment</figcaption>
-
-![Workload Tab and Group by Node Icon]({{< baseurl >}}/img/rancher/schedule-specific-node.png)
-
 Rancher schedules pods to the node you select if 1) there are compute resource available for the node and 2) you've configured port mapping to use the HostPort option, that there are no port conflicts.
 
 If you expose the workload using a NodePort that conflicts with another workload, the deployment gets created successfully, but no NodePort service is created. Therefore, the workload isn't exposed outside of the cluster.
 
 After the workload is created, you can confirm that the pods are scheduled to your chosen node. From the **Workloads** tab, click the **Group by Node** icon to sort your workloads by node. Note that both Nginx pods are scheduled to the same node.
 
-![Pods Scheduled to Same Node]({{< baseurl >}}/img/rancher/scheduled-nodes.png)
-
 <!--
 
 If you export the workload's manifest for Rancher v2.x, you can see in the pod spec that the workload is scheduled to the node that you selected (`nodeName: mark-do1`).
@@ -159,10 +141,6 @@ To apply labels to pods, make additions to the **Labels and Annotations** sectio
 
 Some of the most-used scheduling features in v1.6 were affinity and anti-affinity rules.
 
-<figcaption><code>output.txt</code> Affinity Label</figcaption>
-
-![Affinity Label]({{< baseurl >}}/img/rancher/resolve-affinity.png)
-
 - **Affinity**
 
     Any pods that share the same label are scheduled to the same node. Affinity can be configured in one of two ways:
@@ -174,10 +152,6 @@ Some of the most-used scheduling features in v1.6 were affinity and anti-affinit
 
     <br/>
 
-    <figcaption>Affinity Rules: Hard and Soft</figcaption>
-
-    ![Affinity Rules]({{< baseurl >}}/img/rancher/node-scheduling-affinity.png)
-
 
 - **AntiAffinity**
 
@@ -187,10 +161,6 @@ Some of the most-used scheduling features in v1.6 were affinity and anti-affinit
 
     For anti-affinity rules, we recommend using labels with phrases like `NotIn` and `DoesNotExist`, as these terms are more intuitive when users are applying anti-affinity rules.
 
-    <figcaption>AntiAffinity Operators</figcaption>
-
-    ![AntiAffinity ]({{< baseurl >}}/img/rancher/node-schedule-antiaffinity.png)
-
 
 
 Detailed documentation for affinity/anti-affinity is available in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
@@ -204,9 +174,6 @@ In Rancher v1.6 setups, you could prevent services from being scheduled to speci
 
 In Rancher v2.x, you can prevent pods from being scheduled to specific nodes by applying _taints_ to a node. Pods will not be scheduled to a tainted node unless it has special permission, called a _toleration_. A toleration is a special label that allows a pod to be deployed to a tainted node. While editing a workload, you can apply tolerations using the **Node Scheduling** section. Click **Show advanced options**.
 
-<figcaption>Applying Tolerations</figcaption>
-
-![Tolerations]({{< baseurl >}}/img/rancher/node-schedule-advanced-options.png)
 
 For more information, see the Kubernetes documentation on [taints and tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/).
 
@@ -214,20 +181,10 @@ For more information, see the Kubernetes documentation on [taints and toleration
 
 Rancher v1.6 included the ability to deploy [global services]({{< baseurl >}}/rancher/v1.6/en/cattle/scheduling/#global-service), which are services that deploy duplicate containers to each host in the environment (i.e.,  nodes in your cluster using Rancher v2.x terms). If a service has the `io.rancher.scheduler.global: 'true'` label declared, then Rancher v1.6 schedules a service container on each host in the environment.
 
-
-<figcaption><code>output.txt</code> Global Service Label</figcaption>
-
-![Global Service Label]({{< baseurl >}}/img/rancher/resolve-global.png)
-
-
 In Rancher v2.x, you can schedule a pod to each node using a [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), which is a specific type of workload <!-- link -->). A _DaemonSet_ functions exactly like a Rancher v1.6 global service. The Kubernetes scheduler deploys a pod on each node of the cluster, and as new nodes are added, the scheduler will start new pods on them provided they match the scheduling requirements of the workload. Additionally, in v2.x, you can also limit a DaemonSet to be deployed to nodes that have a specific label.
 
 To create a daemonset while configuring a workload, choose **Run one pod on each node** from the the **Workload Type** options.
 
-<figcaption>Workload Configuration: Choose run one pod on each node to configure daemonset</figcaption>
-
-![choose Run one pod on each node]({{< baseurl >}}/img/rancher/workload-type.png)
-
 ### Scheduling Pods Using Resource Constraints
 
 While creating a service in the Rancher v1.6 UI, you could schedule its containers to hosts based on hardware requirements that you choose. The containers are then scheduled to hosts based on which ones have bandwidth, memory, and CPU capacity.
@@ -247,10 +204,6 @@ To declare resource constraints, edit your migrated workloads, editing the **Sec
     - Memory Limit
     - CPU Limit
 
-<figcaption>Scheduling: Resource Constraint Settings</figcaption>
-
-![Resource Constraint Settings]({{< baseurl >}}/img/rancher/resource-constraint-settings.png)
-
 You can find more detail about these specs and how to use them in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container).
 
 ### [Next: Service Discovery]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/discover-services/)

From f2018a65253bda5587782cb26ba927052b154115 Mon Sep 17 00:00:00 2001
From: dnoland1 <dnoland@rancher.com>
Date: Mon, 1 Apr 2019 17:32:17 -0700
Subject: [PATCH 05/14] Update _index.md

---
 content/rke/v0.1.x/en/installation/_index.md | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/content/rke/v0.1.x/en/installation/_index.md b/content/rke/v0.1.x/en/installation/_index.md
index 0051424f6be..999b6425832 100644
--- a/content/rke/v0.1.x/en/installation/_index.md
+++ b/content/rke/v0.1.x/en/installation/_index.md
@@ -13,11 +13,14 @@ RKE is a fast, versatile Kubernetes installer that you can use to install Kubern
 
 ## Download the RKE binary
 
-1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases/latest) page. Download the latest RKE installer applicable to your Operating System:
+1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases/latest) page. Download the latest RKE installer applicable to your Operating System and Architecture:
 
     - **MacOS**: `rke_darwin-amd64`
-    - **Linux**: `rke_linux-amd64`
-    - **Windows**: `rke_windows-amd64.exe`
+    - **Linux (Intel/AMD)**: `rke_linux-amd64`
+    - **Linux (ARM 32-bit)**: `rke_linux-arm`
+    - **Linux (ARM 64-bix)**: `rke_linux-arm64`
+    - **Windows (32-bit)**: `rke_windows-386.exe`
+    - **Windows (64-bit)**: `rke_windows-amd64.exe`
 
 2. Copy the RKE binary to a folder in your `$PATH` and rename it `rke` (or `rke.exe` for Windows)
 

From 696e6eeeb227bac7915fc5ab73b7050184a286d3 Mon Sep 17 00:00:00 2001
From: David Noland <dnoland@rancher.com>
Date: Mon, 1 Apr 2019 17:35:23 -0700
Subject: [PATCH 06/14] Fixed typo

---
 content/rke/v0.1.x/en/installation/_index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/rke/v0.1.x/en/installation/_index.md b/content/rke/v0.1.x/en/installation/_index.md
index 999b6425832..54bb7efde18 100644
--- a/content/rke/v0.1.x/en/installation/_index.md
+++ b/content/rke/v0.1.x/en/installation/_index.md
@@ -18,7 +18,7 @@ RKE is a fast, versatile Kubernetes installer that you can use to install Kubern
     - **MacOS**: `rke_darwin-amd64`
     - **Linux (Intel/AMD)**: `rke_linux-amd64`
     - **Linux (ARM 32-bit)**: `rke_linux-arm`
-    - **Linux (ARM 64-bix)**: `rke_linux-arm64`
+    - **Linux (ARM 64-bit)**: `rke_linux-arm64`
     - **Windows (32-bit)**: `rke_windows-386.exe`
     - **Windows (64-bit)**: `rke_windows-amd64.exe`
 

From 7abebaf09564f67e309bf7d2bc849cec53f10526 Mon Sep 17 00:00:00 2001
From: dnoland1 <dnoland@rancher.com>
Date: Mon, 1 Apr 2019 17:54:07 -0700
Subject: [PATCH 07/14] Update _index.md

---
 content/rke/v0.1.x/en/config-options/add-ons/dns/_index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/rke/v0.1.x/en/config-options/add-ons/dns/_index.md b/content/rke/v0.1.x/en/config-options/add-ons/dns/_index.md
index 88a854c5741..ae19e2a4dde 100644
--- a/content/rke/v0.1.x/en/config-options/add-ons/dns/_index.md
+++ b/content/rke/v0.1.x/en/config-options/add-ons/dns/_index.md
@@ -13,7 +13,7 @@ The images used for kube-dns are under the [`system_images` directive]({{< baseu
 
 _Available as of v0.2.0_
 
-If you only wanted ingress controllers to be deployed on specific nodes, you can set a `node_selector` for the ingress. The label in the `node_selector` would need to match the label on the nodes for the ingress controller to be deployed.
+If you only want the kube-dns pod to be deployed on specific nodes, you can set a `node_selector` in the `dns` section. The label in the `node_selector` would need to match the label on the nodes for the kube-dns pod to be deployed.
 
 ```yaml
 nodes:

From 968e1922243d1b33d80ce03dd00f0147dfd648ae Mon Sep 17 00:00:00 2001
From: Jan B <jan@rancher.com>
Date: Tue, 2 Apr 2019 17:10:55 +0200
Subject: [PATCH 08/14] Fix external link for Kubernetes webhook authentication

---
 content/rke/v0.1.x/en/config-options/authentication/_index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/rke/v0.1.x/en/config-options/authentication/_index.md b/content/rke/v0.1.x/en/config-options/authentication/_index.md
index 391e4eaa240..efc2817a391 100644
--- a/content/rke/v0.1.x/en/config-options/authentication/_index.md
+++ b/content/rke/v0.1.x/en/config-options/authentication/_index.md
@@ -13,7 +13,7 @@ authentication:
       - "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
 ```
 
-RKE also supports the webhook authentication strategy. You can enable both x509 and webhook strategies by using a `|` separator in the configuration. Contents of the webhook config file should be provided, see [Kubernetes webhook documentation](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) for information on the file format. Additionally, a cache timeout for webhook authentication responses can be set.
+RKE also supports the webhook authentication strategy. You can enable both x509 and webhook strategies by using a `|` separator in the configuration. Contents of the webhook config file should be provided, see [Kubernetes webhook documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) for information on the file format. Additionally, a cache timeout for webhook authentication responses can be set.
 
 ```yaml
 authentication:

From e492452ae3076ccf3c7b2924d53f2a4c99f99937 Mon Sep 17 00:00:00 2001
From: Sebastiaan van Steenis <mail@superseb.nl>
Date: Wed, 3 Apr 2019 00:01:36 +0200
Subject: [PATCH 09/14] Pin cert-manager version on HA air gap installs

---
 .../air-gap-high-availability/install-rancher/_index.md       | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/content/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher/_index.md b/content/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher/_index.md
index 61f989cca0a..7c1c84b1972 100644
--- a/content/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher/_index.md
@@ -55,13 +55,13 @@ By default, Rancher generates a CA and uses cert manger to issue the certificate
 1. From a system connected to the internet, fetch the latest cert-manager chart available from the [official Helm chart repository](https://github.com/helm/charts/tree/master/stable). 
 
     ```plain
-    helm fetch stable/cert-manager
+    helm fetch stable/cert-manager --version 0.5.2
     ```
 
 1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.
 
     ```plain
-    helm template ./cert-manager-<version>.tgz --output-dir . \
+    helm template ./cert-manager-v0.5.2.tgz --output-dir . \
     --name cert-manager --namespace kube-system \
     --set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller
     ```

From 8a1bf7c9af947d6607251188690c2b7c243391ec Mon Sep 17 00:00:00 2001
From: Sebastiaan van Steenis <mail@superseb.nl>
Date: Wed, 3 Apr 2019 16:18:12 +0200
Subject: [PATCH 10/14] Add note on available Docker versions when using node
 templates

---
 layouts/shortcodes/step_rancher-template.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/layouts/shortcodes/step_rancher-template.html b/layouts/shortcodes/step_rancher-template.html
index 859cff143f0..0323edb2d58 100644
--- a/layouts/shortcodes/step_rancher-template.html
+++ b/layouts/shortcodes/step_rancher-template.html
@@ -9,11 +9,11 @@
 			<!-- TODO: Improve the engine options -->
 			<p><strong>Engine Options</strong> customize the configuration of the <a href="https://docs.docker.com/engine/docker-overview/#the-docker-daemon">Docker daemon</a>. Important configuration options might include:
 			<ul>
-			<li><strong>Docker Engine Install URL:</strong> Determines what Docker version will be installed on the instance.</li>
+			<li><strong>Docker Engine Install URL:</strong> Determines what Docker version will be installed on the instance.<br/><br/>When using RancherOS, please check what Docker versions are available using <code>sudo ros engine list</code> on the RancherOS version you want to use, as the default Docker version configured might not be available. If you experience issues installing Docker on other operating systems, please try to install Docker manually using the configured Docker Engine Install URL to troubleshoot.</li>
 			<li><strong>Registry mirrors:</strong> Docker Registry mirror to be used by the Docker daemon</li>
 			</ul>
 			</p>
 
-			<p><a href="https://docs.docker.com/engine/reference/commandline/dockerd/">daemon option reference</a></p>
+			<p><a href="https://docs.docker.com/engine/reference/commandline/dockerd/">Docker daemon option reference</a></p>
 		</li>
 	</ul>

From 8f25346de2b279ecb9358e7fc38ce448daccc002 Mon Sep 17 00:00:00 2001
From: Sebastiaan van Steenis <mail@superseb.nl>
Date: Wed, 3 Apr 2019 14:38:44 +0200
Subject: [PATCH 11/14] Add note on MTU in network troubleshooting

---
 .../v2.x/en/troubleshooting/networking/_index.md       | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/content/rancher/v2.x/en/troubleshooting/networking/_index.md b/content/rancher/v2.x/en/troubleshooting/networking/_index.md
index 53e0c0737fe..75173ccd167 100644
--- a/content/rancher/v2.x/en/troubleshooting/networking/_index.md
+++ b/content/rancher/v2.x/en/troubleshooting/networking/_index.md
@@ -77,6 +77,16 @@ NODE1 cannot reach NODE3
 
 Cleanup the alpine DaemonSet by running `kubectl delete ds/overlaytest`.
 
+### Check if MTU is correctly configured on hosts and on peering/tunnel appliances/devices
+
+When the MTU is incorrectly configured (either on hosts running Rancher, nodes in created/imported clusters or on appliances/devices in between), error messages will be logged in Rancher and in the agents, similar to:
+
+* `websocket: bad handshake`
+* `Failed to connect to proxy`
+* `read tcp: i/o timeout`
+
+See [Google Cloud VPN: MTU Considerations](https://cloud.google.com/vpn/docs/concepts/mtu-considerations#gateway_mtu_vs_system_mtu) for an example how to configure MTU correctly when using Google Cloud VPN between Rancher and cluster nodes.
+
 ### Resolved issues
 
 #### Overlay network broken when using Canal/Flannel due to missing node annotations

From 7defa1cb0a59f1893ebf507aefbc813eb307b14b Mon Sep 17 00:00:00 2001
From: Sebastiaan van Steenis <mail@superseb.nl>
Date: Wed, 3 Apr 2019 14:15:22 +0200
Subject: [PATCH 12/14] Add note on replacing certificates for HA

---
 .../v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md  | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/content/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md b/content/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md
index 8b1c8b11f3a..98d8199aee6 100644
--- a/content/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md
@@ -15,6 +15,8 @@ kubectl -n cattle-system create secret tls tls-rancher-ingress \
   --key=tls.key
 ```
 
+> **Note:** If you want to replace the certificate, you can delete the `tls-rancher-ingress` secret using `kubectl -n cattle-system delete secret tls-rancher-ingress` and add a new one using the command shown above. Replacing the certificate is only supported if the new certificate is signed by the same CA as the certificate currently in use.
+
 ### Using a Private CA Signed Certificate
 
 If you are using a private CA, Rancher requires a copy of the CA certificate which is used by the Rancher Agent to validate the connection to the server.

From 27b520d7fd9677b81ec185a5d8388f9aa29c1d6f Mon Sep 17 00:00:00 2001
From: Sebastiaan van Steenis <mail@superseb.nl>
Date: Wed, 3 Apr 2019 12:00:23 +0200
Subject: [PATCH 13/14] Add note on saving files when creating cluster using
 RKE

---
 content/rke/v0.1.x/en/installation/_index.md | 34 +++++++++++---------
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/content/rke/v0.1.x/en/installation/_index.md b/content/rke/v0.1.x/en/installation/_index.md
index 54bb7efde18..b2f38a08b1c 100644
--- a/content/rke/v0.1.x/en/installation/_index.md
+++ b/content/rke/v0.1.x/en/installation/_index.md
@@ -6,10 +6,11 @@ weight: 50
 RKE is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. You can get started in a couple of quick and easy steps:
 
 1. [Download the RKE Binary](#download-the-rke-binary)
-2. [Prepare the Nodes for the Kubernetes Cluster](#prepare-the-nodes-for-the-kubernetes-cluster)
-3. [Creating the Cluster Configuration File](#creating-the-cluster-configuration-file)
-4. [Deploying Kubernetes with RKE](#deploying-kubernetes-with-rke)
-5. [Interacting with your Kubernetes Cluster](#interacting-with-your-kubernetes-cluster)
+1. [Prepare the Nodes for the Kubernetes Cluster](#prepare-the-nodes-for-the-kubernetes-cluster)
+1. [Creating the Cluster Configuration File](#creating-the-cluster-configuration-file)
+1. [Deploying Kubernetes with RKE](#deploying-kubernetes-with-rke)
+1. [Save your Files](#save-your-files)
+1. [Interacting with your Kubernetes Cluster](#interacting-with-your-kubernetes-cluster)
 
 ## Download the RKE binary
 
@@ -93,6 +94,12 @@ RKE is HA ready, you can specify more than one `controlplane` node in the `clust
 
 To create an HA cluster, specify more than one host with role `controlplane`.
 
+### Certificates
+
+_Available as of v0.2.0_
+
+By default, Kubernetes clusters require certificates and RKE auto-generates the certificates for all cluster components. You can also use [custom certificates]({{< baseurl >}}/rke/v0.1.x/en/installation/certs/). After the Kubernetes cluster is deployed, you can [manage these auto-generated certificates]({{< baseurl >}}/rke/v0.1.x/en/cert-mgmt/#certificate-rotation).
+
 ## Deploying Kubernetes with RKE
 
 After you've created your `cluster.yml`, you can deploy your cluster with a simple command. This command assumes the `cluster.yml` file is in the same directory as where you are running the command.
@@ -112,11 +119,16 @@ The last line should read `Finished building Kubernetes cluster successfully` to
 
 > **Note:** If you have used a different file name from `cluster.yml`, then the kube config file will be named `kube_config_<FILE_NAME>.yml`.
 
-### Certificates
+## Save Your Files
 
-_Available as of v0.2.0_
+> **Important**
+> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
 
-By default, Kubernetes clusters require certificates and RKE auto-generates the certificates for all cluster components. You can also use [custom certificates]({{< baseurl >}}/rke/v0.1.x/en/installation/certs/). After the Kubernetes cluster is deployed, you can [manage these auto-generated certificates]({{< baseurl >}}/rke/v0.1.x/en/cert-mgmt/#certifcate-rotation).
+Save a copy of the following files in a secure location:
+
+- `cluster.yml`: The RKE cluster configuration file.
+- `kube_config_cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/v0.1.x/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
+- `cluster.rkestate`: The [Kubernetes Cluster State file](#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
 
 ### Kubernetes Cluster State
 
@@ -124,14 +136,6 @@ The Kubernetes cluster state, which consists of the cluster configuration file `
 
 As of v0.2.0, RKE creates a `.rkestate` file in the same directory that has the cluster configuration file `cluster.yml`. The `.rkestate` file contains the current state of the cluster including the RKE configuration and the certificates. It is required to keep this file in order to update the cluster or perform any operation on it through RKE.
 
-```
-$ tree -L 1
-.
-├── cluster.rkestate
-├── cluster.yml
-├── kube_config_cluster.yml
-```
-
 Prior to v0.2.0, RKE saved the Kubernetes cluster state as a secret. When updating the state, RKE pulls the secret, updates/changes the state and saves a new secret.   
 
 ## Interacting with your Kubernetes cluster

From dd8e5f6294fcc45f48fae6e643993c410f96608f Mon Sep 17 00:00:00 2001
From: Vincent Fiduccia <vincent@rancher.com>
Date: Wed, 3 Apr 2019 13:19:39 -0700
Subject: [PATCH 14/14] RKE v0.1.x -> latest

---
 .ackrc                                        |  4 ++
 content/_index.html                           |  2 +-
 .../restorations/ha-restoration/_index.md     |  2 +-
 .../cluster-admin/editing-clusters/_index.md  |  4 +-
 .../examples/vsphere/_index.md                |  2 +-
 .../v2.x/en/cluster-provisioning/_index.md    |  2 +-
 .../rke-clusters/_index.md                    |  2 +-
 .../rke-clusters/node-pools/vsphere/_index.md |  2 +-
 .../rke-clusters/options/_index.md            | 20 +++++-----
 .../options/cloud-providers/_index.md         |  6 +--
 .../en/faq/networking/cni-providers/_index.md |  2 +-
 .../rancher/v2.x/en/faq/technical/_index.md   |  2 +-
 .../air-gap-high-availability/_index.md       |  2 +-
 .../install-kube/_index.md                    |  6 +--
 .../rancher/v2.x/en/installation/ha/_index.md |  2 +-
 .../installation/ha/create-nodes-lb/_index.md |  2 +-
 .../installation/ha/kubernetes-rke/_index.md  |  6 +--
 .../ha/rke-add-on/api-auditing/_index.md      |  2 +-
 .../ha/rke-add-on/layer-4-lb/_index.md        |  6 +--
 .../ha/rke-add-on/layer-7-lb/_index.md        |  6 +--
 .../v1.6-migration/load-balancing/_index.md   |  4 +-
 content/rke/{v0.1.x => latest}/_index.md      |  2 +-
 content/rke/{v0.1.x => latest}/en/_index.md   |  0
 .../{v0.1.x => latest}/en/cert-mgmt/_index.md |  4 +-
 .../en/config-options/_index.md               | 38 +++++++++----------
 .../en/config-options/add-ons/_index.md       | 12 +++---
 .../en/config-options/add-ons/dns/_index.md   |  2 +-
 .../add-ons/ingress-controllers/_index.md     |  2 +-
 .../add-ons/metrics-server/_index.md          |  2 +-
 .../add-ons/network-plugins/_index.md         |  2 +-
 .../add-ons/user-defined-add-ons/_index.md    |  2 +-
 .../config-options/authentication/_index.md   |  0
 .../en/config-options/authorization/_index.md |  0
 .../en/config-options/bastion-host/_index.md  |  2 +-
 .../config-options/cloud-providers/_index.md  | 10 ++---
 .../cloud-providers/aws/_index.md             |  0
 .../cloud-providers/azure/_index.md           |  0
 .../cloud-providers/custom/_index.md          |  0
 .../cloud-providers/openstack/_index.md       |  0
 .../cloud-providers/vsphere/_index.md         |  0
 .../en/config-options/nodes/_index.md         |  6 +--
 .../private-registries/_index.md              |  8 ++--
 .../en/config-options/services/_index.md      |  6 +--
 .../services/external-etcd/_index.md          |  2 +-
 .../services/services-extras/_index.md        |  0
 .../en/config-options/system-images/_index.md |  4 +-
 .../en/etcd-snapshots/_index.md               | 14 +++----
 .../en/example-yamls/_index.md                |  4 +-
 .../en/installation/_index.md                 | 18 ++++-----
 .../en/installation/certs/_index.md           |  4 +-
 .../en/kubeconfig/_index.md                   |  0
 .../en/managing-clusters/_index.md            |  4 +-
 .../rke/{v0.1.x => latest}/en/os/_index.md    |  6 +--
 .../en/troubleshooting/_index.md              |  2 +-
 .../ssh-connectivity-errors/_index.md         |  0
 .../{v0.1.x => latest}/en/upgrades/_index.md  |  8 ++--
 nginx.conf                                    |  1 +
 57 files changed, 128 insertions(+), 123 deletions(-)
 rename content/rke/{v0.1.x => latest}/_index.md (68%)
 rename content/rke/{v0.1.x => latest}/en/_index.md (100%)
 rename content/rke/{v0.1.x => latest}/en/cert-mgmt/_index.md (96%)
 rename content/rke/{v0.1.x => latest}/en/config-options/_index.md (79%)
 rename content/rke/{v0.1.x => latest}/en/config-options/add-ons/_index.md (76%)
 rename content/rke/{v0.1.x => latest}/en/config-options/add-ons/dns/_index.md (97%)
 rename content/rke/{v0.1.x => latest}/en/config-options/add-ons/ingress-controllers/_index.md (98%)
 rename content/rke/{v0.1.x => latest}/en/config-options/add-ons/metrics-server/_index.md (91%)
 rename content/rke/{v0.1.x => latest}/en/config-options/add-ons/network-plugins/_index.md (97%)
 rename content/rke/{v0.1.x => latest}/en/config-options/add-ons/user-defined-add-ons/_index.md (93%)
 rename content/rke/{v0.1.x => latest}/en/config-options/authentication/_index.md (100%)
 rename content/rke/{v0.1.x => latest}/en/config-options/authorization/_index.md (100%)
 rename content/rke/{v0.1.x => latest}/en/config-options/bastion-host/_index.md (88%)
 rename content/rke/{v0.1.x => latest}/en/config-options/cloud-providers/_index.md (65%)
 rename content/rke/{v0.1.x => latest}/en/config-options/cloud-providers/aws/_index.md (100%)
 rename content/rke/{v0.1.x => latest}/en/config-options/cloud-providers/azure/_index.md (100%)
 rename content/rke/{v0.1.x => latest}/en/config-options/cloud-providers/custom/_index.md (100%)
 rename content/rke/{v0.1.x => latest}/en/config-options/cloud-providers/openstack/_index.md (100%)
 rename content/rke/{v0.1.x => latest}/en/config-options/cloud-providers/vsphere/_index.md (100%)
 rename content/rke/{v0.1.x => latest}/en/config-options/nodes/_index.md (96%)
 rename content/rke/{v0.1.x => latest}/en/config-options/private-registries/_index.md (87%)
 rename content/rke/{v0.1.x => latest}/en/config-options/services/_index.md (96%)
 rename content/rke/{v0.1.x => latest}/en/config-options/services/external-etcd/_index.md (94%)
 rename content/rke/{v0.1.x => latest}/en/config-options/services/services-extras/_index.md (100%)
 rename content/rke/{v0.1.x => latest}/en/config-options/system-images/_index.md (90%)
 rename content/rke/{v0.1.x => latest}/en/etcd-snapshots/_index.md (96%)
 rename content/rke/{v0.1.x => latest}/en/example-yamls/_index.md (98%)
 rename content/rke/{v0.1.x => latest}/en/installation/_index.md (91%)
 rename content/rke/{v0.1.x => latest}/en/installation/certs/_index.md (97%)
 rename content/rke/{v0.1.x => latest}/en/kubeconfig/_index.md (100%)
 rename content/rke/{v0.1.x => latest}/en/managing-clusters/_index.md (92%)
 rename content/rke/{v0.1.x => latest}/en/os/_index.md (97%)
 rename content/rke/{v0.1.x => latest}/en/troubleshooting/_index.md (55%)
 rename content/rke/{v0.1.x => latest}/en/troubleshooting/ssh-connectivity-errors/_index.md (100%)
 rename content/rke/{v0.1.x => latest}/en/upgrades/_index.md (83%)

diff --git a/.ackrc b/.ackrc
index 29d17e2cb4d..6c11a140dec 100644
--- a/.ackrc
+++ b/.ackrc
@@ -1,3 +1,7 @@
 --ignore-dir=public
 --ignore-dir=static
 --ignore-dir=src/img
+--ignore-dir=src/img
+--type-add=svg:ext:svg
+--no-xml
+--no-svg
diff --git a/content/_index.html b/content/_index.html
index 37e3a00796a..19a2a3beaa9 100644
--- a/content/_index.html
+++ b/content/_index.html
@@ -59,7 +59,7 @@ layout: blank
               <p>Rancher Kubernetes Engine (RKE) is an extremely simple, lightning fast Kubernetes installer that works everywhere.</p>
             </div>
             <div class="border-top p-t-xs m-t-sm">
-            <a href="{{< baseurl >}}/rke/v0.1.x/en" class="btn bg-link">Read the Docs</a>
+            <a href="{{< baseurl >}}/rke/latest/en" class="btn bg-link">Read the Docs</a>
             </div>
             </div>
         </div>
diff --git a/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md b/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md
index 0ae9fc9ad89..94093b8a135 100644
--- a/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md
+++ b/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md
@@ -23,7 +23,7 @@ This procedure describes how to use RKE to restore a snapshot of the Rancher Kub
 
 ### 1. Preparation
 
-You will need [RKE]({{< baseurl >}}/rke/v0.1.x/en/installation/) and [kubectl]({{< baseurl >}}/rancher/v2.x/en/faq/kubectl/) CLI utilities installed.
+You will need [RKE]({{< baseurl >}}/rke/latest/en/installation/) and [kubectl]({{< baseurl >}}/rancher/v2.x/en/faq/kubectl/) CLI utilities installed.
 
 Prepare by creating 3 new nodes to be the target for the restored Rancher instance.  See [HA Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/) for node requirements.
 
diff --git a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md
index 3c4c968df5b..41b07c02495 100644
--- a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md
@@ -128,14 +128,14 @@ Option | Description |
 
 >**Note:** In Rancher v2.0.5 and v2.0.6, the names of services in the Config File (YAML) should contain underscores only: `kube_api` and `kube_controller`.
 
-Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/v0.1.x/en/config-options/) in an RKE installation.
+Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/latest/en/config-options/) in an RKE installation.
 
 - To edit an RKE config file directly from the Rancher UI, click **Edit as YAML**.
 - To read from an existing RKE file, click **Read from File**.
 
 ![image]({{< baseurl >}}/img/rancher/cluster-options-yaml.png)
 
-For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/).  
+For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/latest/en/example-yamls/).  
 
 ## Managing Node Pools
 
diff --git a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md
index 1337546d274..ee192cf9b17 100644
--- a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md
@@ -10,7 +10,7 @@ To provide stateful workloads with vSphere storage, we recommend creating a vSph
 
 ### Prerequisites
 
-In order to provision vSphere volumes in a cluster created with the [Rancher Kubernetes Engine (RKE)]({{< baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the [vSphere cloud provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere) must be explicitly enabled in the [cluster options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/).
+In order to provision vSphere volumes in a cluster created with the [Rancher Kubernetes Engine (RKE)]({{< baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the [vSphere cloud provider]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere) must be explicitly enabled in the [cluster options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/).
 
 ### Creating A Storage Class
 
diff --git a/content/rancher/v2.x/en/cluster-provisioning/_index.md b/content/rancher/v2.x/en/cluster-provisioning/_index.md
index 332bfaef10f..65e758ab1d9 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/_index.md
@@ -69,7 +69,7 @@ If you use a Kubernetes provider such as Google GKE, Rancher integrates with its
 
 ### Rancher Launched Kubernetes
 
-Alternatively, you can use Rancher to create a cluster on your own nodes, using [Rancher Kubernetes Engine (RKE)]({{< baseurl >}}/rke/v0.1.x/en/). RKE is Rancher’s own lightweight Kubernetes installer. In RKE clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform. These nodes can either:
+Alternatively, you can use Rancher to create a cluster on your own nodes, using [Rancher Kubernetes Engine (RKE)]({{< baseurl >}}/rke/latest/en/). RKE is Rancher’s own lightweight Kubernetes installer. In RKE clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform. These nodes can either:
 
 - Be provisioned through Rancher's UI, which calls [Docker Machine](https://docs.docker.com/machine/) to launch nodes on various cloud providers.
 - Be a prior existing node that's brought into the cluster by running a Rancher agent container on it.
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md
index 2b1d9a27950..417cdf3c295 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md
@@ -3,7 +3,7 @@ title: Rancher Launched Kubernetes
 weight: 2200
 ---
 
-If you don't want to use a hosted Kubernetes provider, you can have Rancher launch a Kubernetes cluster using any nodes you want. When Rancher deploys Kubernetes onto these nodes, it uses [Rancher Kubernetes Engine]({{< baseurl >}}/rke/v0.1.x/en/) (RKE), which is Rancher's own lightweight Kubernetes installer. It can launch Kubernetes on any computers, including:
+If you don't want to use a hosted Kubernetes provider, you can have Rancher launch a Kubernetes cluster using any nodes you want. When Rancher deploys Kubernetes onto these nodes, it uses [Rancher Kubernetes Engine]({{< baseurl >}}/rke/latest/en/) (RKE), which is Rancher's own lightweight Kubernetes installer. It can launch Kubernetes on any computers, including:
 
 - Bare-metal servers
 - On-premise virtual machines
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md
index a4dfe1bb8af..c089dec4281 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md
@@ -16,7 +16,7 @@ When creating a vSphere cluster, Rancher first provisions the specified amount o
 
 ## Prerequisites
 
-Before proceeding to create a cluster, you must ensure that you have a vSphere user with sufficient permissions. If you are planning to make use of vSphere volumes for persistent storage in the cluster, there are [additional requirements]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere/) that must be met.
+Before proceeding to create a cluster, you must ensure that you have a vSphere user with sufficient permissions. If you are planning to make use of vSphere volumes for persistent storage in the cluster, there are [additional requirements]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere/) that must be met.
 
 ## Provisioning a vSphere Cluster
 
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md
index 591a36acdc0..827cbf57002 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md
@@ -3,12 +3,12 @@ title: Cluster Options
 weight: 2250
 ---
 
-As you configure a new cluster that's provisioned using [RKE]({{< baseurl >}}/rke/v0.1.x/en/), you can choose custom Kubernetes options.
+As you configure a new cluster that's provisioned using [RKE]({{< baseurl >}}/rke/latest/en/), you can choose custom Kubernetes options.
 
 You can configure Kubernetes options one of two ways:
 
 - [Rancher UI](#rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster.
-- [Config File](#config-file): Alternatively, you can create a [RKE config file]({{< baseurl >}}/rke/v0.1.x/en/config-options/) to customize any option offered by Kubernetes.
+- [Config File](#config-file): Alternatively, you can create a [RKE config file]({{< baseurl >}}/rke/latest/en/config-options/) to customize any option offered by Kubernetes.
 
 ## Rancher UI
 
@@ -43,14 +43,14 @@ From this section you can choose:
     - [Calico](https://docs.projectcalico.org/)
     - [Weave](https://github.com/weaveworks/weave) (_Available as of v2.2.0_)
 
-         When Weave is selected as network provider, Rancher will automatically enable encryption by generating a random password. If you want to specify the password manually, please see how to configure your cluster using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) and the [Weave Network Plug-in Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/#weave-network-plug-in-options).
+         When Weave is selected as network provider, Rancher will automatically enable encryption by generating a random password. If you want to specify the password manually, please see how to configure your cluster using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) and the [Weave Network Plug-in Options]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/#weave-network-plug-in-options).
 
 
 <br/>
 
 - If you want to configure a [Kubernetes cloud provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers). If you want to use [volumes and storage]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider.
 
-    >**Note:** If the cloud provider you want to use is not listed as an option, you will need to use the [config file option](#config-file) to configure the cloud provider. Please reference the [RKE cloud provider documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) on how to configure the cloud provider.
+    >**Note:** If the cloud provider you want to use is not listed as an option, you will need to use the [config file option](#config-file) to configure the cloud provider. Please reference the [RKE cloud provider documentation]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/) on how to configure the cloud provider.
 
 If you want to see all the configuration options for a cluster, please click **Show advanced options** on the bottom right. The advanced options are described below:
 
@@ -58,7 +58,7 @@ If you want to see all the configuration options for a cluster, please click **S
 
 _Available as of v2.2.0_
 
-If you are using a private registry with authentication for your Docker images, please configure the registry in this section to allow the nodes to pull images from this registry. See [Private Registries]({{< baseurl >}}/rke/v0.1.x/en/config-options/private-registries/) for more information.
+If you are using a private registry with authentication for your Docker images, please configure the registry in this section to allow the nodes to pull images from this registry. See [Private Registries]({{< baseurl >}}/rke/latest/en/config-options/private-registries/) for more information.
 
 ### Authorized Cluster Endpoint
 
@@ -70,7 +70,7 @@ Authorized Cluster Endpoint can be used to directly access the Kubernetes API se
 
 #### Nginx Ingress
 
-Option to enable or disable the [NGINX ingress controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/).
+Option to enable or disable the [NGINX ingress controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/).
 
 #### Node Port Range
 
@@ -78,7 +78,7 @@ Option to change the range of ports that can be used for [NodePort services](htt
 
 #### Metrics Server Monitoring
 
-Option to enable or disable [Metrics Server]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/metrics-server/).
+Option to enable or disable [Metrics Server]({{< baseurl >}}/rke/latest/en/config-options/add-ons/metrics-server/).
 
 #### Pod Security Policy Support
 
@@ -94,20 +94,20 @@ If the nodes you are adding to the cluster have Docker configured with a non-def
 
 #### Recurring etcd Snapshots
 
-Option to enable or disable [recurring etcd snaphots]({{< baseurl >}}/rke/v0.1.x/en/etcd-snapshots/#etcd-recurring-snapshots).
+Option to enable or disable [recurring etcd snaphots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots).
 
 ## Config File
 
 >**Note:** In Rancher v2.0.5 and v2.0.6, the names of services in the Config File (YAML) should contain underscores only: `kube_api` and `kube_controller`.
 
-Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/v0.1.x/en/config-options/) in an RKE installation.
+Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/latest/en/config-options/) in an RKE installation.
 
 - To edit an RKE config file directly from the Rancher UI, click **Edit as YAML**.
 - To read from an existing RKE file, click **Read from a file**.
 
 ![image]({{< baseurl >}}/img/rancher/cluster-options-yaml.png)
 
-For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/).  
+For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/latest/en/example-yamls/).  
 
 ### Rancher specific parameters
 
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md
index 13a52e873d2..96088b6c645 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md
@@ -13,10 +13,10 @@ By default, the **Cloud Provider** option is set to `None`. Supported cloud prov
 
 The `Custom` cloud provider is available if you want to configure any [Kubernetes cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/).
 
-For the custom cloud provider option, you can refer to the [RKE docs]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) on how to edit the yaml file for your specific cloud provider. There are specific cloud providers that have more detailed configuration :
+For the custom cloud provider option, you can refer to the [RKE docs]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/) on how to edit the yaml file for your specific cloud provider. There are specific cloud providers that have more detailed configuration :
 
-* [vSphere]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere/)
-* [Openstack]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/openstack/)
+* [vSphere]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere/)
+* [Openstack]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/openstack/)
 
 > **Warning:** Your cluster will not provision correctly if you configure a cloud provider cluster of nodes that do not meet the prerequisites. Prerequisites for supported cloud providers are listed below.
 
diff --git a/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md b/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md
index eb509660bcd..0344d47c4b5 100644
--- a/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md
+++ b/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md
@@ -150,4 +150,4 @@ As of Rancher v2.0.7, Canal is the default CNI network provider. We recommend it
 
 ### How can I configure a CNI network provider?
 
-Please see [Cluster Options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/) on how to configure a network provider for your cluster. For more advanced configuration options, please see how to configure your cluster using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) and the options for [Network Plug-ins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/).
+Please see [Cluster Options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/) on how to configure a network provider for your cluster. For more advanced configuration options, please see how to configure your cluster using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) and the options for [Network Plug-ins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/).
diff --git a/content/rancher/v2.x/en/faq/technical/_index.md b/content/rancher/v2.x/en/faq/technical/_index.md
index 30c8e260fb0..da0b2063fbc 100644
--- a/content/rancher/v2.x/en/faq/technical/_index.md
+++ b/content/rancher/v2.x/en/faq/technical/_index.md
@@ -156,7 +156,7 @@ When the node is removed from the cluster, and the node is cleaned, you can read
 
 ### How can I add additional arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
 
-You can add additional arguments/binds/environment variables via the [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/).
+You can add additional arguments/binds/environment variables via the [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables]({{< baseurl >}}/rke/latest/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls]({{< baseurl >}}/rke/latest/en/example-yamls/).
 
 ### How do I check if my certificate chain is valid?
 
diff --git a/content/rancher/v2.x/en/installation/air-gap-high-availability/_index.md b/content/rancher/v2.x/en/installation/air-gap-high-availability/_index.md
index 3afce1a2f39..6cc0ee32a10 100644
--- a/content/rancher/v2.x/en/installation/air-gap-high-availability/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-high-availability/_index.md
@@ -12,7 +12,7 @@ Rancher supports air gap installs using a private registry. You must have your o
 The following CLI tools are required for this install. Make sure these tools are installed on your workstation and available in your `$PATH`.
 
 * [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
-* [rke]({{< baseurl >}}/rke/v0.1.x/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
+* [rke]({{< baseurl >}}/rke/latest/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
 * [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes.
 
 >**Note:** If you install Rancher in an HA configuration in an air gap environment, you cannot transition to a single-node setup during future upgrades.
diff --git a/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md b/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md
index bfb66e89b1d..cbd37612477 100644
--- a/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md
@@ -11,7 +11,7 @@ From a system that can access ports 22/tcp and 6443/tcp on your host nodes, use
 
 Replace values in the code sample below with help of the _RKE Options_ table. Use the IP address or DNS names of the [3 nodes]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/provision-hosts) you created.
 
->**Tip:** For more details on the options available, see the RKE [Config Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/).
+>**Tip:** For more details on the options available, see the RKE [Config Options]({{< baseurl >}}/rke/latest/en/config-options/).
 
 <figcaption>RKE Options</figcaption>
 
@@ -67,7 +67,7 @@ rke up --config ./rancher-cluster.yml
 Save a copy of the following files in a secure location:
 
 - `rancher-cluster.yml`: The RKE cluster configuration file.
-- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/v0.1.x/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
-- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{< baseurl >}}/rke/v0.1.x/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._ 
+- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
+- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._ 
 
 ### [Next: Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher)
diff --git a/content/rancher/v2.x/en/installation/ha/_index.md b/content/rancher/v2.x/en/installation/ha/_index.md
index ec556849030..fe82897b89e 100644
--- a/content/rancher/v2.x/en/installation/ha/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/_index.md
@@ -25,7 +25,7 @@ This procedure walks you through setting up a 3-node cluster with RKE and instal
 The following CLI tools are required for this install. Please make sure these tools are installed and available in your `$PATH`
 
 * [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
-* [rke]({{< baseurl >}}/rke/v0.1.x/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
+* [rke]({{< baseurl >}}/rke/latest/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
 * [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes.
 
 > **Important:** Due to an issue with Helm v2.12.0 and cert-manager, please use Helm v2.12.1 or higher.
diff --git a/content/rancher/v2.x/en/installation/ha/create-nodes-lb/_index.md b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/_index.md
index 3d4815151a8..ade47ce26fe 100644
--- a/content/rancher/v2.x/en/installation/ha/create-nodes-lb/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/_index.md
@@ -11,7 +11,7 @@ Use your provider of choice to provision 3 nodes and a Load Balancer endpoint fo
 
 View the supported operating systems and hardware/software/networking requirements for nodes running Rancher at [Node Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements).
 
-View the OS requirements for RKE at [RKE Requirements]({{< baseurl >}}/rke/v0.1.x/en/os/)
+View the OS requirements for RKE at [RKE Requirements]({{< baseurl >}}/rke/latest/en/os/)
 
 ### Load Balancer
 
diff --git a/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md
index 08e7fd98856..05f5ed1e839 100644
--- a/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md
@@ -50,7 +50,7 @@ services:
 
 RKE has many configuration options for customizing the install to suit your specific environment.
 
-Please see the [RKE Documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/) for the full list of options and capabilities.
+Please see the [RKE Documentation]({{< baseurl >}}/rke/latest/en/config-options/) for the full list of options and capabilities.
 
 ### Run RKE
 
@@ -118,8 +118,8 @@ kube-system     rke-network-plugin-deploy-job-6pbgj       0/1       Completed
 Save a copy of the following files in a secure location:
 
 - `rancher-cluster.yml`: The RKE cluster configuration file.
-- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/v0.1.x/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
-- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{< baseurl >}}/rke/v0.1.x/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
+- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
+- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
 
 ### Issues or errors?
 
diff --git a/content/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/_index.md
index 20dd6a9a417..36dc7198bf2 100644
--- a/content/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/_index.md
@@ -2,7 +2,7 @@
 title: Enable API Auditing
 weight: 300
 aliases:
-  - /rke/v0.1.x/en/config-options/add-ons/api-auditing/
+  - /rke/latest/en/config-options/add-ons/api-auditing/
 ---
 
 >**Important: RKE add-on install is only supported up to Rancher v2.0.8**
diff --git a/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/_index.md
index b192803568f..70a5558a7d3 100644
--- a/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/_index.md
@@ -150,7 +150,7 @@ Choose a fully qualified domain name (FQDN) that you want to use to access Ranch
 
 RKE (Rancher Kubernetes Engine) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. We will use RKE to setup our cluster and run Rancher.
 
-1. Follow the [RKE Install]({{< baseurl >}}/rke/v0.1.x/en/installation) instructions.
+1. Follow the [RKE Install]({{< baseurl >}}/rke/latest/en/installation) instructions.
 
 2. Confirm that RKE is now executable by running the following command:
 
@@ -170,7 +170,7 @@ RKE uses a `.yml` config file to install and configure your Kubernetes cluster.
     >**Advanced Config Options:**
     >
     >- Want records of all transactions with the Rancher API? Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/).
-    >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/).
+    >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/latest/en/config-options/).
 
 
 2. Rename the file to `rancher-cluster.yml`.
@@ -186,7 +186,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec
     For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`.
 
     >**Note:**
-    > When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) >for RHEL/CentOS specific requirements.
+    > When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) >for RHEL/CentOS specific requirements.
 
         nodes:
             # The IP address or hostname of the node
diff --git a/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/_index.md
index 75f8b9ea423..93a1b4fb16b 100644
--- a/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/_index.md
@@ -98,7 +98,7 @@ Choose a fully qualified domain name (FQDN) that you want to use to access Ranch
 
 RKE (Rancher Kubernetes Engine) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. We will use RKE to setup our cluster and run Rancher.
 
-1. Follow the [RKE Install]({{< baseurl >}}/rke/v0.1.x/en/installation) instructions.
+1. Follow the [RKE Install]({{< baseurl >}}/rke/latest/en/installation) instructions.
 
 2. Confirm that RKE is now executable by running the following command:
 
@@ -118,7 +118,7 @@ RKE uses a YAML config file to install and configure your Kubernetes cluster. Th
     >**Advanced Config Options:**
     >
     >- Want records of all transactions with the Rancher API? Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/).
-    >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/).
+    >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/latest/en/config-options/).
 
 
 2. Rename the file to `rancher-cluster.yml`.
@@ -135,7 +135,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec
 
     >**Note:**
     >  
-    >When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
+    >When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
 
         nodes:
             # The IP address or hostname of the node
diff --git a/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md b/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md
index 18a5a5980da..c34f46f1cca 100644
--- a/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md
@@ -39,7 +39,7 @@ By default, Rancher v2.x deploys NGINX Ingress Controller on clusters provisione
 
 RKE deploys NGINX Ingress Controller as a [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), meaning that an NGINX instance is deployed on every node in the cluster. NGINX acts like an Ingress Controller listening to Ingress creation within your entire cluster, and it also configures itself as the load balancer to satisfy the Ingress rules. The DaemonSet is configured with hostNetwork to expose two ports: 80 and 443.
 
-For more information NGINX Ingress Controller, their deployment as DaemonSets, deployment configuration options, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/).
+For more information NGINX Ingress Controller, their deployment as DaemonSets, deployment configuration options, see the [RKE documentation]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/).
 
 ## Load Balancing Architecture
 
@@ -90,7 +90,7 @@ kubectl get ingress
 Rancher v2.x Ingress functionality supports the HTTPS protocol, but if you want to use it, you need to use a valid SSL/TLS certificate. While configuring Ingress rules, use the **SSL/TLS Certificates** section to configure a certificate.
 
 - We recommend [uploading a certificate]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/) from a known certificate authority (you'll have to do this before configuring Ingress). Then, while configuring your load balancer, use the **Choose a certificate** option and select the uploaded certificate that you want to use.
-- If you have configured [NGINX default certificate]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/#configuring-an-nginx-default-certificate), you can select **Use default ingress controller certificate**.
+- If you have configured [NGINX default certificate]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/#configuring-an-nginx-default-certificate), you can select **Use default ingress controller certificate**.
 
 ### TCP Load Balancing Options
 
diff --git a/content/rke/v0.1.x/_index.md b/content/rke/latest/_index.md
similarity index 68%
rename from content/rke/v0.1.x/_index.md
rename to content/rke/latest/_index.md
index 1e02f1cc36b..f0de8adf0bf 100644
--- a/content/rke/v0.1.x/_index.md
+++ b/content/rke/latest/_index.md
@@ -1,4 +1,4 @@
 ---
-title: v0.1.x
+title: RKE
 showBreadcrumb: false
 ---
diff --git a/content/rke/v0.1.x/en/_index.md b/content/rke/latest/en/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/_index.md
rename to content/rke/latest/en/_index.md
diff --git a/content/rke/v0.1.x/en/cert-mgmt/_index.md b/content/rke/latest/en/cert-mgmt/_index.md
similarity index 96%
rename from content/rke/v0.1.x/en/cert-mgmt/_index.md
rename to content/rke/latest/en/cert-mgmt/_index.md
index 8b429b18083..765826121bc 100644
--- a/content/rke/v0.1.x/en/cert-mgmt/_index.md
+++ b/content/rke/latest/en/cert-mgmt/_index.md
@@ -12,9 +12,9 @@ Certificates are an important part of Kubernetes clusters and are used for all K
 
 ## Generating Certificate Signing Requests (CSRs) and Keys
 
-If you want to create and sign the certificates by a real Certificate Authority (CA), you can use RKE to [generate a set of Certificate Signing Requests (CSRs) and keys]({{< baseurl >}}/rke/v0.1.x/en/installation/certs/#generating-certificate-signing-requests-csrs-and-keys).
+If you want to create and sign the certificates by a real Certificate Authority (CA), you can use RKE to [generate a set of Certificate Signing Requests (CSRs) and keys]({{< baseurl >}}/rke/latest/en/installation/certs/#generating-certificate-signing-requests-csrs-and-keys).
 
-You can use the CSRs and keys to sign the certificates by a real CA. After the certificates are signed, these custom certificates can be used by RKE to as [custom certificates]({{< baseurl >}}/rke/v0.1.x/en/installation/certs/) for the Kubernetes cluster.
+You can use the CSRs and keys to sign the certificates by a real CA. After the certificates are signed, these custom certificates can be used by RKE to as [custom certificates]({{< baseurl >}}/rke/latest/en/installation/certs/) for the Kubernetes cluster.
 
 ## Certificate Rotation
 
diff --git a/content/rke/v0.1.x/en/config-options/_index.md b/content/rke/latest/en/config-options/_index.md
similarity index 79%
rename from content/rke/v0.1.x/en/config-options/_index.md
rename to content/rke/latest/en/config-options/_index.md
index 40bb64b0a71..e47133db2c7 100644
--- a/content/rke/v0.1.x/en/config-options/_index.md
+++ b/content/rke/latest/en/config-options/_index.md
@@ -5,31 +5,31 @@ weight: 200
 
 When setting up your `cluster.yml` for RKE, there are a lot of different options that can be configured to control the behavior of how RKE launches Kubernetes.
 
-There are several options that can be configured in cluster configuration option. There are several [example yamls]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/) that contain all the options.
+There are several options that can be configured in cluster configuration option. There are several [example yamls]({{< baseurl >}}/rke/latest/en/example-yamls/) that contain all the options.
 
 ### Configuring Nodes
-* [Nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/)
+* [Nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/)
 * [Ignoring unsupported Docker versions](#supported-docker-versions)
-* [Private Registries]({{< baseurl >}}/rke/v0.1.x/en/config-options/private-registries/)
+* [Private Registries]({{< baseurl >}}/rke/latest/en/config-options/private-registries/)
 * [Cluster Level SSH Key Path](#cluster-level-ssh-key-path)
 * [SSH Agent](#ssh-agent)
-* [Bastion Host]({{< baseurl >}}/rke/v0.1.x/en/config-options/bastion-host/)
+* [Bastion Host]({{< baseurl >}}/rke/latest/en/config-options/bastion-host/)
 
 ### Configuring Kubernetes Cluster
 * [Cluster Name](#cluster-name)
 * [Kubernetes Version](#kubernetes-version)
-* [System Images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/)
-* [Services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/)
-* [Extra Args and Binds and Environment Variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/)
-* [External Etcd]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/external-etcd/)
-* [Authentication]({{< baseurl >}}/rke/v0.1.x/en/config-options/authentication/)
-* [Authorization]({{< baseurl >}}/rke/v0.1.x/en/config-options/authorization/)
-* [Cloud Providers]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/)
-* [Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/)
+* [System Images]({{< baseurl >}}/rke/latest/en/config-options/system-images/)
+* [Services]({{< baseurl >}}/rke/latest/en/config-options/services/)
+* [Extra Args and Binds and Environment Variables]({{< baseurl >}}/rke/latest/en/config-options/services/services-extras/)
+* [External Etcd]({{< baseurl >}}/rke/latest/en/config-options/services/external-etcd/)
+* [Authentication]({{< baseurl >}}/rke/latest/en/config-options/authentication/)
+* [Authorization]({{< baseurl >}}/rke/latest/en/config-options/authorization/)
+* [Cloud Providers]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/)
+* [Add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/)
   * [Add-ons Jobs Timeout](#add-ons-jobs-timeout)
-  * [Network Plugins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/)
-  * [Ingress Controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/)
-  * [User-Defined-Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/)
+  * [Network Plugins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/)
+  * [Ingress Controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/)
+  * [User-Defined-Add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/user-defined-add-ons/)
 
 
 ## Cluster Level Options
@@ -62,7 +62,7 @@ You can set the Kubernetes version as follows:
 kubernetes_version: "v1.11.6-rancher1-1"
 ```
 
-In case both `kubernetes_version` and [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) are defined, the system images configuration will take precedence over `kubernetes_version`.
+In case both `kubernetes_version` and [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) are defined, the system images configuration will take precedence over `kubernetes_version`.
 
 #### Listing Supported Kubernetes Versions
 
@@ -87,11 +87,11 @@ As of v0.2.0, if a version is defined in `kubernetes_version` and is not found i
 
 Prior to v0.2.0, if a version is defined in `kubernetes_version` and is not found in the specific list of supported Kubernetes versions,  the default version from the supported list is used. 
 
-If you want to use a different version from the supported list, please use the [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) option.
+If you want to use a different version from the supported list, please use the [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) option.
 
 ### Cluster Level SSH Key Path
 
-RKE connects to host(s) using `ssh`. Typically, each node will have an independent path for each ssh key, i.e. `ssh_key_path`, in the `nodes` section, but if you have a SSH key that is able to access **all** hosts in your cluster configuration file, you can set the path to that ssh key at the top level. Otherwise, you would set the ssh key path in the [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/).
+RKE connects to host(s) using `ssh`. Typically, each node will have an independent path for each ssh key, i.e. `ssh_key_path`, in the `nodes` section, but if you have a SSH key that is able to access **all** hosts in your cluster configuration file, you can set the path to that ssh key at the top level. Otherwise, you would set the ssh key path in the [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/).
 
 If ssh key paths are defined at the cluster level and at the node level, the node-level key will take precedence.
 
@@ -121,6 +121,6 @@ $ echo $SSH_AUTH_SOCK
 
 ### Add-ons Job Timeout
 
-You can define [add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/) to be deployed after the Kubernetes cluster comes up, which uses Kubernetes [jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). RKE will stop attempting to retrieve the job status after the timeout, which is in seconds. The default timeout value is `30` seconds.
+You can define [add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/) to be deployed after the Kubernetes cluster comes up, which uses Kubernetes [jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). RKE will stop attempting to retrieve the job status after the timeout, which is in seconds. The default timeout value is `30` seconds.
 
 ```yaml
diff --git a/content/rke/v0.1.x/en/config-options/add-ons/_index.md b/content/rke/latest/en/config-options/add-ons/_index.md
similarity index 76%
rename from content/rke/v0.1.x/en/config-options/add-ons/_index.md
rename to content/rke/latest/en/config-options/add-ons/_index.md
index e3c912b9f3e..b15e5346947 100644
--- a/content/rke/v0.1.x/en/config-options/add-ons/_index.md
+++ b/content/rke/latest/en/config-options/add-ons/_index.md
@@ -5,12 +5,12 @@ weight: 260
 
 RKE supports pluggable add-ons. Add-ons are used to deploy several cluster components including:
 
-* [Network plug-ins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/)
-* [Ingress controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/)
-* [DNS provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/dns/)
-* [Metrics Server]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/metrics-server/)
+* [Network plug-ins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/)
+* [Ingress controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/)
+* [DNS provider]({{< baseurl >}}/rke/latest/en/config-options/add-ons/dns/)
+* [Metrics Server]({{< baseurl >}}/rke/latest/en/config-options/add-ons/metrics-server/)
 
-The images used for these add-ons under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each add-on, but these can be overridden by changing the image tag in `system_images`.
+The images used for these add-ons under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each add-on, but these can be overridden by changing the image tag in `system_images`.
 
 In addition to these pluggable add-ons, you can specify an add-on that you want deployed after the cluster deployment is complete.
 
@@ -28,7 +28,7 @@ As of version v0.1.7, add-ons are split into two categories:
 - **Critical add-ons:** If these add-ons fail to deploy for any reason, RKE will error out.
 - **Non-critical add-ons:** If these add-ons fail to deploy, RKE will only log a warning and continue deploying any other add-ons.
 
-Currently, only the [network plug-in]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/) is considered critical. KubeDNS, [ingress controllers]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/) and [user-defined add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/) are considered non-critical.
+Currently, only the [network plug-in]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/) is considered critical. KubeDNS, [ingress controllers]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/) and [user-defined add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/user-defined-add-ons/) are considered non-critical.
 
 ## Add-on deployment jobs
 
diff --git a/content/rke/v0.1.x/en/config-options/add-ons/dns/_index.md b/content/rke/latest/en/config-options/add-ons/dns/_index.md
similarity index 97%
rename from content/rke/v0.1.x/en/config-options/add-ons/dns/_index.md
rename to content/rke/latest/en/config-options/add-ons/dns/_index.md
index ae19e2a4dde..193690140b9 100644
--- a/content/rke/v0.1.x/en/config-options/add-ons/dns/_index.md
+++ b/content/rke/latest/en/config-options/add-ons/dns/_index.md
@@ -7,7 +7,7 @@ By default, RKE deploys [kube-dns](https://github.com/kubernetes/dns) as DNS pro
 
 RKE will deploy kube-dns as a Deployment with the default replica count of 1. The pod consists of 3 containers: `kubedns`, `dnsmasq` and `sidecar`. RKE will also deploy kube-dns-autoscaler as a Deployment, which will scale the kube-dns Deployment by using the number of cores and nodes. Please see [Linear Mode](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler#linear-mode) for more information about this logic.
 
-The images used for kube-dns are under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with kube-dns, but these can be overridden by changing the image tag in `system_images`.
+The images used for kube-dns are under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with kube-dns, but these can be overridden by changing the image tag in `system_images`.
 
 ## Scheduling kube-dns
 
diff --git a/content/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/_index.md b/content/rke/latest/en/config-options/add-ons/ingress-controllers/_index.md
similarity index 98%
rename from content/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/_index.md
rename to content/rke/latest/en/config-options/add-ons/ingress-controllers/_index.md
index 32a2e0cbe9b..8044305eb63 100644
--- a/content/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/_index.md
+++ b/content/rke/latest/en/config-options/add-ons/ingress-controllers/_index.md
@@ -9,7 +9,7 @@ By default, RKE deploys the NGINX ingress controller on all schedulable nodes.
 
 RKE will deploy the ingress controller as a DaemonSet with `hostnetwork: true`, so ports `80`, and `443` will be opened on each node where the controller is deployed.
 
-The images used for ingress controller is under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with the ingress controller, but these can be overridden by changing the image tag in `system_images`.
+The images used for ingress controller is under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with the ingress controller, but these can be overridden by changing the image tag in `system_images`.
 
 ## Scheduling Ingress Controllers
 
diff --git a/content/rke/v0.1.x/en/config-options/add-ons/metrics-server/_index.md b/content/rke/latest/en/config-options/add-ons/metrics-server/_index.md
similarity index 91%
rename from content/rke/v0.1.x/en/config-options/add-ons/metrics-server/_index.md
rename to content/rke/latest/en/config-options/add-ons/metrics-server/_index.md
index 80212e590c1..88775ac5577 100644
--- a/content/rke/v0.1.x/en/config-options/add-ons/metrics-server/_index.md
+++ b/content/rke/latest/en/config-options/add-ons/metrics-server/_index.md
@@ -7,7 +7,7 @@ By default, RKE deploys [Metrics Server](https://github.com/kubernetes-incubator
 
 RKE will deploy Metrics Server as a Deployment.
 
-The image used for Metrics Server is under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there is a default image associated with the Metrics Server, but these can be overridden by changing the image tag in `system_images`.
+The image used for Metrics Server is under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there is a default image associated with the Metrics Server, but these can be overridden by changing the image tag in `system_images`.
 
 ## Disabling the Metrics Server
 
diff --git a/content/rke/v0.1.x/en/config-options/add-ons/network-plugins/_index.md b/content/rke/latest/en/config-options/add-ons/network-plugins/_index.md
similarity index 97%
rename from content/rke/v0.1.x/en/config-options/add-ons/network-plugins/_index.md
rename to content/rke/latest/en/config-options/add-ons/network-plugins/_index.md
index 2e66d0079f4..b8f7a26ab82 100644
--- a/content/rke/v0.1.x/en/config-options/add-ons/network-plugins/_index.md
+++ b/content/rke/latest/en/config-options/add-ons/network-plugins/_index.md
@@ -18,7 +18,7 @@ network:
     plugin: flannel
 ```
 
-The images used for network plug-ins are under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each network plug-in, but these can be overridden by changing the image tag in `system_images`.
+The images used for network plug-ins are under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each network plug-in, but these can be overridden by changing the image tag in `system_images`.
 
 ## Disabling deployment of a network plug-in
 
diff --git a/content/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/_index.md b/content/rke/latest/en/config-options/add-ons/user-defined-add-ons/_index.md
similarity index 93%
rename from content/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/_index.md
rename to content/rke/latest/en/config-options/add-ons/user-defined-add-ons/_index.md
index b838ebcaf1f..6a03f9f418d 100644
--- a/content/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/_index.md
+++ b/content/rke/latest/en/config-options/add-ons/user-defined-add-ons/_index.md
@@ -3,7 +3,7 @@ title: User-Defined Add-Ons
 weight: 263
 ---
 
-Besides the [network plug-in]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins) and [ingress controllers]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/), you can define any add-on that you want deployed after the Kubernetes cluster is deployed.
+Besides the [network plug-in]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins) and [ingress controllers]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/), you can define any add-on that you want deployed after the Kubernetes cluster is deployed.
 
 There are two ways that you can specify an add-on.
 
diff --git a/content/rke/v0.1.x/en/config-options/authentication/_index.md b/content/rke/latest/en/config-options/authentication/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/authentication/_index.md
rename to content/rke/latest/en/config-options/authentication/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/authorization/_index.md b/content/rke/latest/en/config-options/authorization/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/authorization/_index.md
rename to content/rke/latest/en/config-options/authorization/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/bastion-host/_index.md b/content/rke/latest/en/config-options/bastion-host/_index.md
similarity index 88%
rename from content/rke/v0.1.x/en/config-options/bastion-host/_index.md
rename to content/rke/latest/en/config-options/bastion-host/_index.md
index cf29acb5b10..bade5d19232 100644
--- a/content/rke/v0.1.x/en/config-options/bastion-host/_index.md
+++ b/content/rke/latest/en/config-options/bastion-host/_index.md
@@ -3,7 +3,7 @@ title: Bastion/Jump Host Configuration
 weight: 220
 ---
 
-Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/), you can configure to use a bastion host. Keep in mind that the [port requirements]({{< baseurl >}}/rke/v0.1.x/en/os/#ports) for the RKE node move to the configured bastion host.
+Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/), you can configure to use a bastion host. Keep in mind that the [port requirements]({{< baseurl >}}/rke/latest/en/os/#ports) for the RKE node move to the configured bastion host.
 
 ```yaml
 bastion_host:
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/_index.md b/content/rke/latest/en/config-options/cloud-providers/_index.md
similarity index 65%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/_index.md
index aeced55a22d..27881c437e2 100644
--- a/content/rke/v0.1.x/en/config-options/cloud-providers/_index.md
+++ b/content/rke/latest/en/config-options/cloud-providers/_index.md
@@ -6,9 +6,9 @@ weight: 250
 RKE supports the ability to set your specific [cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/) for your Kubernetes cluster. There are specific cloud configurations for these cloud providers.
 To enable a cloud provider its name as well as any required configuration options must be provided under the `cloud_provider` directive in the cluster YML.
 
-* [AWS]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/aws)
-* [Azure]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/azure)
-* [OpenStack]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/openstack)
-* [vSphere]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere)
+* [AWS]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/aws)
+* [Azure]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/azure)
+* [OpenStack]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/openstack)
+* [vSphere]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere)
 
-Outside of this list, RKE also supports the ability to handle any [custom cloud provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/custom).
+Outside of this list, RKE also supports the ability to handle any [custom cloud provider]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/custom).
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/aws/_index.md b/content/rke/latest/en/config-options/cloud-providers/aws/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/aws/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/aws/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/azure/_index.md b/content/rke/latest/en/config-options/cloud-providers/azure/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/azure/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/azure/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/custom/_index.md b/content/rke/latest/en/config-options/cloud-providers/custom/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/custom/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/custom/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/openstack/_index.md b/content/rke/latest/en/config-options/cloud-providers/openstack/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/openstack/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/openstack/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/vsphere/_index.md b/content/rke/latest/en/config-options/cloud-providers/vsphere/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/vsphere/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/vsphere/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/nodes/_index.md b/content/rke/latest/en/config-options/nodes/_index.md
similarity index 96%
rename from content/rke/v0.1.x/en/config-options/nodes/_index.md
rename to content/rke/latest/en/config-options/nodes/_index.md
index a204565f1a9..84208496786 100644
--- a/content/rke/v0.1.x/en/config-options/nodes/_index.md
+++ b/content/rke/latest/en/config-options/nodes/_index.md
@@ -62,7 +62,7 @@ The `internal_address` provides the ability to have nodes with multiple addresse
 
 The `hostname_override` is used to be able to provide a friendly name for RKE to use when registering the node in Kubernetes. This hostname doesn't need to be a routable address, but it must be a valid [Kubernetes resource name](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). If the `hostname_override` isn't set, then the `address` directive is used when registering the node in Kubernetes.
 
-> **Note:** When [cloud providers]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) are configured, you may need to override the hostname in order to use the cloud provider correctly. There is an exception for the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws), where the `hostname_override` field will be explicitly ignored.
+> **Note:** When [cloud providers]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/) are configured, you may need to override the hostname in order to use the cloud provider correctly. There is an exception for the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws), where the `hostname_override` field will be explicitly ignored.
 
 ### SSH Port
 
@@ -76,7 +76,7 @@ For each node, you specify the `user` to be used when connecting to this node. T
 
 For each node, you specify the path, i.e. `ssh_key_path`, for the SSH private key to be used when connecting to this node. The default key path for each node is `~/.ssh/id_rsa`.
 
-> **Note:** If you have a private key that can be used across all nodes, you can set the [SSH key path at the cluster level]({{< baseurl >}}/rke/v0.1.x/en/config-options/#cluster-level-ssh-key-path). The SSH key path set in each node will always take precedence.
+> **Note:** If you have a private key that can be used across all nodes, you can set the [SSH key path at the cluster level]({{< baseurl >}}/rke/latest/en/config-options/#cluster-level-ssh-key-path). The SSH key path set in each node will always take precedence.
 
 ### SSH Key
 
@@ -122,4 +122,4 @@ If the Docker socket is different than the default, you can set the `docker_sock
 
 ### Labels
 
-You have the ability to add an arbitrary map of labels for each node. It can be used when using the [ingress controller's]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/) `node_selector` option.
+You have the ability to add an arbitrary map of labels for each node. It can be used when using the [ingress controller's]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/) `node_selector` option.
diff --git a/content/rke/v0.1.x/en/config-options/private-registries/_index.md b/content/rke/latest/en/config-options/private-registries/_index.md
similarity index 87%
rename from content/rke/v0.1.x/en/config-options/private-registries/_index.md
rename to content/rke/latest/en/config-options/private-registries/_index.md
index b28e51f7388..b835a3480a2 100644
--- a/content/rke/v0.1.x/en/config-options/private-registries/_index.md
+++ b/content/rke/latest/en/config-options/private-registries/_index.md
@@ -19,7 +19,7 @@ private_registries:
 
 ### Default Registry
 
-As of v0.1.10, RKE supports specifying a default registry from the list of private registries to be used with all [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) . In this example .RKE will use `registry.com` as the default registry for all system images, e.g. `rancher/rke-tools:v0.1.14` will become `registry.com/rancher/rke-tools:v0.1.14`.
+As of v0.1.10, RKE supports specifying a default registry from the list of private registries to be used with all [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) . In this example .RKE will use `registry.com` as the default registry for all system images, e.g. `rancher/rke-tools:v0.1.14` will become `registry.com/rancher/rke-tools:v0.1.14`.
 
 ```yaml
 private_registries:
@@ -31,9 +31,9 @@ private_registries:
 
 ### Air-gapped Setups
 
-By default, all system images are being pulled from DockerHub. If you are on a system that does not have access to DockerHub, you will need to create a private registry that is populated with all the required [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). 
+By default, all system images are being pulled from DockerHub. If you are on a system that does not have access to DockerHub, you will need to create a private registry that is populated with all the required [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/). 
 
-As of v0.1.10, you have to configure your private registry credentials, but you can specify this registry as a default registry so that all [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) are pulled from the designated private registry. You can use the command `rke config --system-images` to get the list of default system images to populate your private registry. 
+As of v0.1.10, you have to configure your private registry credentials, but you can specify this registry as a default registry so that all [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) are pulled from the designated private registry. You can use the command `rke config --system-images` to get the list of default system images to populate your private registry. 
 
-Prior to v0.1.10, you had to configure your private registry credentials **and** update the names of all the [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) in the `cluster.yml` so that the image names would have the private registry URL appended before each image name. 
+Prior to v0.1.10, you had to configure your private registry credentials **and** update the names of all the [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) in the `cluster.yml` so that the image names would have the private registry URL appended before each image name. 
 
diff --git a/content/rke/v0.1.x/en/config-options/services/_index.md b/content/rke/latest/en/config-options/services/_index.md
similarity index 96%
rename from content/rke/v0.1.x/en/config-options/services/_index.md
rename to content/rke/latest/en/config-options/services/_index.md
index 38562538683..3094ce25381 100644
--- a/content/rke/v0.1.x/en/config-options/services/_index.md
+++ b/content/rke/latest/en/config-options/services/_index.md
@@ -5,7 +5,7 @@ weight: 230
 
 To deploy Kubernetes, RKE deploys several core components or services in Docker containers on the nodes. Based on the roles of the node, the containers deployed may be different.
 
-**All services support additional [custom arguments, Docker mount binds and extra environment variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/).**
+**All services support additional [custom arguments, Docker mount binds and extra environment variables]({{< baseurl >}}/rke/latest/en/config-options/services/services-extras/).**
 
 ## etcd
 
@@ -13,9 +13,9 @@ Kubernetes uses [etcd](https://github.com/coreos/etcd/blob/master/Documentation/
 
 RKE supports running etcd in a single node mode or in HA cluster mode. It also supports adding and removing etcd nodes to the cluster.
 
-You can enable etcd to [take recurring snapshots]({{< baseurl >}}/rke/v0.1.x/en/etcd-snapshots/#recurring-snapshots). These snapshots can be used to [restore etcd]({{< baseurl >}}/rke/v0.1.x/en/etcd-snapshots/#etcd-disaster-recovery). 
+You can enable etcd to [take recurring snapshots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#recurring-snapshots). These snapshots can be used to [restore etcd]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-disaster-recovery). 
 
-By default, RKE will deploy a new etcd service, but you can also run Kubernetes with an [external etcd service]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/external-etcd/).
+By default, RKE will deploy a new etcd service, but you can also run Kubernetes with an [external etcd service]({{< baseurl >}}/rke/latest/en/config-options/services/external-etcd/).
 
 ## Kubernetes API Server
 
diff --git a/content/rke/v0.1.x/en/config-options/services/external-etcd/_index.md b/content/rke/latest/en/config-options/services/external-etcd/_index.md
similarity index 94%
rename from content/rke/v0.1.x/en/config-options/services/external-etcd/_index.md
rename to content/rke/latest/en/config-options/services/external-etcd/_index.md
index aa7280eb3ca..173fa826972 100644
--- a/content/rke/v0.1.x/en/config-options/services/external-etcd/_index.md
+++ b/content/rke/latest/en/config-options/services/external-etcd/_index.md
@@ -5,7 +5,7 @@ weight: 232
 
 By default, RKE will launch etcd servers, but RKE also supports being able to use an external etcd. RKE only supports connecting to a TLS enabled etcd setup.
 
-> **Note:** RKE will not accept having external etcd servers in conjunction with [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/) with the `etcd` role.
+> **Note:** RKE will not accept having external etcd servers in conjunction with [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/) with the `etcd` role.
 
 ```yaml
 services:
diff --git a/content/rke/v0.1.x/en/config-options/services/services-extras/_index.md b/content/rke/latest/en/config-options/services/services-extras/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/services/services-extras/_index.md
rename to content/rke/latest/en/config-options/services/services-extras/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/system-images/_index.md b/content/rke/latest/en/config-options/system-images/_index.md
similarity index 90%
rename from content/rke/v0.1.x/en/config-options/system-images/_index.md
rename to content/rke/latest/en/config-options/system-images/_index.md
index a8e3f786049..3fbcaff40e0 100644
--- a/content/rke/v0.1.x/en/config-options/system-images/_index.md
+++ b/content/rke/latest/en/config-options/system-images/_index.md
@@ -6,7 +6,7 @@ When RKE is deploying Kubernetes, there are several images that are pulled. Thes
 
 As of `v0.1.6`, the functionality of a couple of the system images were consolidated into a single `rancher/rke-tools` image to simplify and speed the deployment process.
 
-You can configure the [network plug-ins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/), [ingress controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/) and [dns provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/dns/) as well as the options for these add-ons separately.
+You can configure the [network plug-ins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/), [ingress controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/) and [dns provider]({{< baseurl >}}/rke/latest/en/config-options/add-ons/dns/) as well as the options for these add-ons separately.
 
 This is the example of the full list of system images used to deploy Kubernetes through RKE. The image tags are dependent on the [Kubernetes image/version used](https://github.com/rancher/types/blob/master/apis/management.cattle.io/v3/k8s_defaults.go).
 
@@ -71,4 +71,4 @@ system_images:
 
 ### Air-gapped Setups
 
-If you have an air-gapped setup and cannot access `docker.io`, you will need to set up your [private registry]({{< baseurl >}}/rke/v0.1.x/en/config-options/private-registries/) in your cluster configuration file. After you set up private registry, you will need to update these images to pull from your private registry.
+If you have an air-gapped setup and cannot access `docker.io`, you will need to set up your [private registry]({{< baseurl >}}/rke/latest/en/config-options/private-registries/) in your cluster configuration file. After you set up private registry, you will need to update these images to pull from your private registry.
diff --git a/content/rke/v0.1.x/en/etcd-snapshots/_index.md b/content/rke/latest/en/etcd-snapshots/_index.md
similarity index 96%
rename from content/rke/v0.1.x/en/etcd-snapshots/_index.md
rename to content/rke/latest/en/etcd-snapshots/_index.md
index 32c78437ded..f17de91087c 100644
--- a/content/rke/v0.1.x/en/etcd-snapshots/_index.md
+++ b/content/rke/latest/en/etcd-snapshots/_index.md
@@ -2,7 +2,7 @@
 title: Backups and Disaster Recovery
 weight: 150
 aliases:
-  - /rke/v0.1.x/en/installation/etcd-snapshots/
+  - /rke/latest/en/installation/etcd-snapshots/
 ---
 
 _Available as of v0.1.7_
@@ -11,7 +11,7 @@ RKE clusters can be configured to automatically take snapshots of etcd. In a dis
 
 _Available as of v0.2.0_
 
-RKE can also upload your snapshots to a S3 compatible backend. Additionally, the **pki.bundle.tar.gz** file usage is no longer required as v0.2.0 has changed how the [Kubernetes cluster state is stored]({{< baseurl >}}/rke/v0.1.x/en/installation/#kubernetes-cluster-state).
+RKE can also upload your snapshots to a S3 compatible backend. Additionally, the **pki.bundle.tar.gz** file usage is no longer required as v0.2.0 has changed how the [Kubernetes cluster state is stored]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state).
 
 ## One-Time Snapshots
 
@@ -33,8 +33,8 @@ As of v0.2.0, the one-time snapshot can be uploaded to a S3 compatible backend b
 |   `--secret-key` value   |    Specify s3 secretKey |  * |
 |   `--bucket-name` value  |    Specify s3 bucket name |   * |
 |   `--region` value       |    Specify the s3 bucket location (optional) |   * |
-| `--ssh-agent-auth`      |   [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{< baseurl >}}/rke/v0.1.x/en/config-options/#ssh-agent) | |
-| `--ignore-docker-version`  | [Disable Docker version check]({{< baseurl >}}/rke/v0.1.x/en/config-options/#supported-docker-versions) |
+| `--ssh-agent-auth`      |   [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{< baseurl >}}/rke/latest/en/config-options/#ssh-agent) | |
+| `--ignore-docker-version`  | [Disable Docker version check]({{< baseurl >}}/rke/latest/en/config-options/#supported-docker-versions) |
 
 ### Local One-Time Snapshot Example
 
@@ -143,12 +143,12 @@ The snapshot used to restore your etcd cluster can either be stored locally in `
 | `--secret-key` value      |  Specify s3 secretKey | *|
 | `--bucket-name` value     |  Specify s3 bucket name | *|
 | `--region` value          |  Specify the s3 bucket location (optional) | *|
-| `--ssh-agent-auth`      |   [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{< baseurl >}}/rke/v0.1.x/en/config-options/#ssh-agent) | |
-| `--ignore-docker-version`  | [Disable Docker version check]({{< baseurl >}}/rke/v0.1.x/en/config-options/#supported-docker-versions) |
+| `--ssh-agent-auth`      |   [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{< baseurl >}}/rke/latest/en/config-options/#ssh-agent) | |
+| `--ignore-docker-version`  | [Disable Docker version check]({{< baseurl >}}/rke/latest/en/config-options/#supported-docker-versions) |
 
 ### Example of Restoring from a Local Snapshot
 
-When restoring etcd from a local snapshot, the snapshot is assumed to be located in `/opt/rke/etcd-snapshots`. In versions prior to v0.2.0, the `pki.bundle.tar.gz` file is also expected to be in the same location. As of v0.2.0, this file is no longer needed as v0.2.0 has changed how the [Kubernetes cluster state is stored]({{< baseurl >}}/rke/v0.1.x/en/installation/#kubernetes-cluster-state).
+When restoring etcd from a local snapshot, the snapshot is assumed to be located in `/opt/rke/etcd-snapshots`. In versions prior to v0.2.0, the `pki.bundle.tar.gz` file is also expected to be in the same location. As of v0.2.0, this file is no longer needed as v0.2.0 has changed how the [Kubernetes cluster state is stored]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state).
 
 ```
 $ rke etcd snapshot-restore --config cluster.yml --name mysnapshot
diff --git a/content/rke/v0.1.x/en/example-yamls/_index.md b/content/rke/latest/en/example-yamls/_index.md
similarity index 98%
rename from content/rke/v0.1.x/en/example-yamls/_index.md
rename to content/rke/latest/en/example-yamls/_index.md
index 311e6241816..1fa897d4571 100644
--- a/content/rke/v0.1.x/en/example-yamls/_index.md
+++ b/content/rke/latest/en/example-yamls/_index.md
@@ -2,10 +2,10 @@
 title: Example Cluster.ymls
 weight: 300
 aliases:
-  - /rke/v0.1.x/en/config-options/example-yamls/
+  - /rke/latest/en/config-options/example-yamls/
 ---
 
-There are lots of different [configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) that can be set in the cluster configuration file for RKE. Here are some examples of files:
+There are lots of different [configuration options]({{< baseurl >}}/rke/latest/en/config-options/) that can be set in the cluster configuration file for RKE. Here are some examples of files:
 
 > **Note for Rancher 2 users** If you are configuring Cluster Options using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) when creating [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the names of services should contain underscores only: `kube_api` and `kube_controller`. This only applies to Rancher v2.0.5 and v2.0.6.
 
diff --git a/content/rke/v0.1.x/en/installation/_index.md b/content/rke/latest/en/installation/_index.md
similarity index 91%
rename from content/rke/v0.1.x/en/installation/_index.md
rename to content/rke/latest/en/installation/_index.md
index b2f38a08b1c..5fd20634b65 100644
--- a/content/rke/v0.1.x/en/installation/_index.md
+++ b/content/rke/latest/en/installation/_index.md
@@ -53,20 +53,20 @@ RKE is a fast, versatile Kubernetes installer that you can use to install Kubern
 
 The Kubernetes cluster components are launched using Docker on a Linux distro. You can use any Linux you want, as long as you can install Docker on it.
 
-Review the [OS requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os/) and configure each node appropriately.
+Review the [OS requirements]({{< baseurl >}}/rke/latest/en/installation/os/) and configure each node appropriately.
 
 ## Creating the Cluster Configuration File
 
-RKE uses a cluster configuration file, referred to as `cluster.yml` to determine what nodes will be in the cluster and how to deploy Kubernetes. There are [many configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) that can be set in the `cluster.yml`. In our example, we will be assuming the minimum of one [node]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes) for your Kubernetes cluster.
+RKE uses a cluster configuration file, referred to as `cluster.yml` to determine what nodes will be in the cluster and how to deploy Kubernetes. There are [many configuration options]({{< baseurl >}}/rke/latest/en/config-options/) that can be set in the `cluster.yml`. In our example, we will be assuming the minimum of one [node]({{< baseurl >}}/rke/latest/en/config-options/nodes) for your Kubernetes cluster.
 
 There are two easy ways to create a `cluster.yml`:
 
-- Using our [minimal `cluster.yml`]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/#minimal-cluster-yml-example) and updating it based on the node that you will be using.
+- Using our [minimal `cluster.yml`]({{< baseurl >}}/rke/latest/en/example-yamls/#minimal-cluster-yml-example) and updating it based on the node that you will be using.
 - Using `rke config` to query for all the information needed.
 
 ### Using `rke config`
 
-Run `rke config` to create a new `cluster.yml` in the current directory. This command will prompt you for all the information needed to build a cluster. See [cluster configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) for details on the various options.
+Run `rke config` to create a new `cluster.yml` in the current directory. This command will prompt you for all the information needed to build a cluster. See [cluster configuration options]({{< baseurl >}}/rke/latest/en/config-options/) for details on the various options.
 
 ```
 rke config --name cluster.yml
@@ -98,7 +98,7 @@ To create an HA cluster, specify more than one host with role `controlplane`.
 
 _Available as of v0.2.0_
 
-By default, Kubernetes clusters require certificates and RKE auto-generates the certificates for all cluster components. You can also use [custom certificates]({{< baseurl >}}/rke/v0.1.x/en/installation/certs/). After the Kubernetes cluster is deployed, you can [manage these auto-generated certificates]({{< baseurl >}}/rke/v0.1.x/en/cert-mgmt/#certificate-rotation).
+By default, Kubernetes clusters require certificates and RKE auto-generates the certificates for all cluster components. You can also use [custom certificates]({{< baseurl >}}/rke/latest/en/installation/certs/). After the Kubernetes cluster is deployed, you can [manage these auto-generated certificates]({{< baseurl >}}/rke/latest/en/cert-mgmt/#certificate-rotation).
 
 ## Deploying Kubernetes with RKE
 
@@ -127,7 +127,7 @@ The last line should read `Finished building Kubernetes cluster successfully` to
 Save a copy of the following files in a secure location:
 
 - `cluster.yml`: The RKE cluster configuration file.
-- `kube_config_cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/v0.1.x/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
+- `kube_config_cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
 - `cluster.rkestate`: The [Kubernetes Cluster State file](#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
 
 ### Kubernetes Cluster State
@@ -140,9 +140,9 @@ Prior to v0.2.0, RKE saved the Kubernetes cluster state as a secret. When updati
 
 ## Interacting with your Kubernetes cluster
 
-After your cluster is up and running, you can start using the [generated kubeconfig file]({{< baseurl >}}/rke/v0.1.x/en/kubeconfig) to start interacting with your Kubernetes cluster using `kubectl`.
+After your cluster is up and running, you can start using the [generated kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig) to start interacting with your Kubernetes cluster using `kubectl`.
 
 After installation, there are several maintenance items that might arise:
 
-* [Certificate Management]({{< baseurl >}}/rke/v0.1.x/en/cert-mgmt/)
-* [Adding and Removing Nodes in the cluster]({{< baseurl >}}/rke/v0.1.x/en/managing-clusters)
+* [Certificate Management]({{< baseurl >}}/rke/latest/en/cert-mgmt/)
+* [Adding and Removing Nodes in the cluster]({{< baseurl >}}/rke/latest/en/managing-clusters)
diff --git a/content/rke/v0.1.x/en/installation/certs/_index.md b/content/rke/latest/en/installation/certs/_index.md
similarity index 97%
rename from content/rke/v0.1.x/en/installation/certs/_index.md
rename to content/rke/latest/en/installation/certs/_index.md
index 915926aaf04..6b702c468d2 100644
--- a/content/rke/v0.1.x/en/installation/certs/_index.md
+++ b/content/rke/latest/en/installation/certs/_index.md
@@ -7,7 +7,7 @@ _Available as of v0.2.0_
 
 By default, Kubernetes clusters require certificates and RKE auto-generates the certificates for all the Kubernetes services. RKE can also use custom certificates for these Kubernetes services.
 
-When [deploying Kubernetes with RKE]({{< baseurl >}}/rke/v0.1.x/en/installation/#deploying-kubernetes-with-rke), there are two additional options that can be used with `rke up` so that RKE uses custom certificates.
+When [deploying Kubernetes with RKE]({{< baseurl >}}/rke/latest/en/installation/#deploying-kubernetes-with-rke), there are two additional options that can be used with `rke up` so that RKE uses custom certificates.
 
 | Option | Description |
 | --- | --- |
@@ -45,7 +45,7 @@ The following certificates must exist in the certificate directory.
 
 If you want to create and sign the certificates by a real Certificate Authority (CA), you can use RKE to generate a set of Certificate Signing Requests (CSRs) and keys. Using the `rke cert generate-csr` command, you can generate the CSRs and keys.
 
-1. Set up your `cluster.yml` with the [node information]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/).
+1. Set up your `cluster.yml` with the [node information]({{< baseurl >}}/rke/latest/en/config-options/nodes/).
 
 2. Run `rke cert generate-csr` to generate certificates for the node(s) in the `cluster.yml`. By default, the CSRs and keys will be saved in `./cluster_certs`. To have them saved in a different directory, use `--cert-dir` to define what directory to have them saved in.
 
diff --git a/content/rke/v0.1.x/en/kubeconfig/_index.md b/content/rke/latest/en/kubeconfig/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/kubeconfig/_index.md
rename to content/rke/latest/en/kubeconfig/_index.md
diff --git a/content/rke/v0.1.x/en/managing-clusters/_index.md b/content/rke/latest/en/managing-clusters/_index.md
similarity index 92%
rename from content/rke/v0.1.x/en/managing-clusters/_index.md
rename to content/rke/latest/en/managing-clusters/_index.md
index 2268838fff9..c43049d0fce 100644
--- a/content/rke/v0.1.x/en/managing-clusters/_index.md
+++ b/content/rke/latest/en/managing-clusters/_index.md
@@ -2,12 +2,12 @@
 title: Adding and Removing Nodes
 weight: 175
 aliases:
-  - /rke/v0.1.x/en/installation/managing-clusters/
+  - /rke/latest/en/installation/managing-clusters/
 ---
 
 ### Adding/Removing Nodes
 
-RKE supports adding/removing [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/) for worker and controlplane hosts.
+RKE supports adding/removing [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/) for worker and controlplane hosts.
 
 In order to add additional nodes, you update the original `cluster.yml` file with any additional nodes and specify their role in the Kubernetes cluster.
 
diff --git a/content/rke/v0.1.x/en/os/_index.md b/content/rke/latest/en/os/_index.md
similarity index 97%
rename from content/rke/v0.1.x/en/os/_index.md
rename to content/rke/latest/en/os/_index.md
index 404f71afb29..56df0dea9c6 100644
--- a/content/rke/v0.1.x/en/os/_index.md
+++ b/content/rke/latest/en/os/_index.md
@@ -2,7 +2,7 @@
 title: Requirements
 weight: 5
 aliases:
-  - /rke/v0.1.x/en/installation/os
+  - /rke/latest/en/installation/os
 ---
 **In this section:** 
 
@@ -30,7 +30,7 @@ aliases:
 
 RKE runs on almost any Linux OS with Docker installed. Most of the development and testing of RKE occurred on Ubuntu 16.04. However, some OS's have restrictions and specific requirements.
 
-- [SSH user]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/#ssh-user) - The SSH user used for node access must be a member of the `docker` group on the node:
+- [SSH user]({{< baseurl >}}/rke/latest/en/config-options/nodes/#ssh-user) - The SSH user used for node access must be a member of the `docker` group on the node:
 
    ```
    usermod -aG docker <user_name>
@@ -87,7 +87,7 @@ net.bridge.bridge-nf-call-iptables=1
 
 ### Red Hat Enterprise Linux (RHEL) / Oracle Enterprise Linux (OEL) / CentOS
 
-If using Red Hat Enterprise Linux, Oracle Enterprise Linux or CentOS, you cannot use the `root` user as [SSH user]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/#ssh-user) due to [Bugzilla 1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). Please follow the instructions below how to setup Docker correctly, based on the way you installed Docker on the node.
+If using Red Hat Enterprise Linux, Oracle Enterprise Linux or CentOS, you cannot use the `root` user as [SSH user]({{< baseurl >}}/rke/latest/en/config-options/nodes/#ssh-user) due to [Bugzilla 1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). Please follow the instructions below how to setup Docker correctly, based on the way you installed Docker on the node.
 
 #### Using upstream Docker
 If you are using upstream Docker, the package name is `docker-ce` or `docker-ee`. You can check the installed package by executing:
diff --git a/content/rke/v0.1.x/en/troubleshooting/_index.md b/content/rke/latest/en/troubleshooting/_index.md
similarity index 55%
rename from content/rke/v0.1.x/en/troubleshooting/_index.md
rename to content/rke/latest/en/troubleshooting/_index.md
index e47db3d5079..53668e8aff4 100644
--- a/content/rke/v0.1.x/en/troubleshooting/_index.md
+++ b/content/rke/latest/en/troubleshooting/_index.md
@@ -3,4 +3,4 @@ title: Troubleshooting
 weight: 400
 ---
 
-* [SSH Connectivity Errors]({{< baseurl >}}/rke/v0.1.x/en/troubleshooting/ssh-connectivity-errors/)
+* [SSH Connectivity Errors]({{< baseurl >}}/rke/latest/en/troubleshooting/ssh-connectivity-errors/)
diff --git a/content/rke/v0.1.x/en/troubleshooting/ssh-connectivity-errors/_index.md b/content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/troubleshooting/ssh-connectivity-errors/_index.md
rename to content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md
diff --git a/content/rke/v0.1.x/en/upgrades/_index.md b/content/rke/latest/en/upgrades/_index.md
similarity index 83%
rename from content/rke/v0.1.x/en/upgrades/_index.md
rename to content/rke/latest/en/upgrades/_index.md
index 871217a5134..8c5ffc2d0ba 100644
--- a/content/rke/v0.1.x/en/upgrades/_index.md
+++ b/content/rke/latest/en/upgrades/_index.md
@@ -3,11 +3,11 @@ title: Upgrades
 weight: 100
 ---
 
-After RKE has deployed Kubernetes, you can upgrade the versions of the components in your Kubernetes cluster, [definition of the Kubernetes services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/) or [add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/).
+After RKE has deployed Kubernetes, you can upgrade the versions of the components in your Kubernetes cluster, [definition of the Kubernetes services]({{< baseurl >}}/rke/latest/en/config-options/services/) or [add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/).
 
 ## Version Upgrades
 
-RKE supports version upgrades by changing the image tags of the [system-images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/).
+RKE supports version upgrades by changing the image tags of the [system-images]({{< baseurl >}}/rke/latest/en/config-options/system-images/).
 
 For example, to change the deployed Kubernetes version, you update the `rancher/hyperkube` tag from `v1.9.7` to `v1.10.3` in the `cluster.yml` that was originally used to deploy your Kubernetes cluster.
 
@@ -37,7 +37,7 @@ First, RKE will use the local `kube_config_cluster.yml` to confirm the versions
 
 ## Service Upgrades
 
-[Services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/) can be upgraded by changing any of the services arguments or `extra_args` and running `rke up` again with the updated configuration file.
+[Services]({{< baseurl >}}/rke/latest/en/config-options/services/) can be upgraded by changing any of the services arguments or `extra_args` and running `rke up` again with the updated configuration file.
 
 > **Note:** The following arguments, `service_cluster_ip_range` or `cluster_cidr`, cannot be changed as any changes to these arguments will result in a broken cluster. Currently, network pods are not automatically upgraded.
 
@@ -45,4 +45,4 @@ First, RKE will use the local `kube_config_cluster.yml` to confirm the versions
 
 As of v0.1.8, upgrades to add-ons are supported.
 
-[Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/) can also be upgraded by changing any of the add-ons and running `rke up` again with the updated configuration file.
+[Add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/) can also be upgraded by changing any of the add-ons and running `rke up` again with the updated configuration file.
diff --git a/nginx.conf b/nginx.conf
index b606b942919..d9bf2807047 100644
--- a/nginx.conf
+++ b/nginx.conf
@@ -1,6 +1,7 @@
 map_hash_bucket_size 256;
 map $request_uri $redirect_uri {
   ~^/docs/rancher/v2.0(/?.*)$   /docs/rancher/v2.x$1;
+  ~^/docs/rke/v0.1.x(/?.*)$   /docs/rke/latest$1;
 }
 
 server {