diff --git a/README.md b/README.md
index 002b29e77a0..5756258b737 100644
--- a/README.md
+++ b/README.md
@@ -5,16 +5,28 @@ Rancher Docs
 
 The `rancher/docs:dev` docker image runs a live-updating server.  To run on your workstation, run:
 
+Linux
 ```bash
   ./scripts/dev
 ```
 
+Windows
+```powershell
+./scripts/dev-windows.ps1
+```
+
 and then navigate to http://localhost:9001/.  You can customize the port by passing it as an argument:
 
+Linux
 ```bash
   ./scripts/dev 8080
 ```
 
+Windows
+```powershell
+./scripts/dev-windows.ps1 -port 8080
+```
+
 License
 =======
 Copyright (c) 2014-2019 [Rancher Labs, Inc.](http://rancher.com)
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/_index.md
index 061d7734c4b..0dc19a78a1b 100644
--- a/content/rancher/v2.x/en/admin-settings/authentication/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/authentication/_index.md
@@ -30,7 +30,7 @@ The Rancher authentication proxy integrates with the following external authenti
 <br/>
 However, Rancher also provides [local authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/local/).
 
-In most cases, you should use an external authentication service over local authentication, as external authentication allows user management from a central location. However, you may want a few local authentication users for managing Rancher under rare circumstances, such as if Active Directory is down.
+In most cases, you should use an external authentication service over local authentication, as external authentication allows user management from a central location. However, you may want a few local authentication users for managing Rancher under rare circumstances, such as if your external authentication provider is unavailable or undergoing maintenance.
 
 ## Users and Groups
 
diff --git a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md
index 1263a405b79..51da015a34e 100644
--- a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md
@@ -49,7 +49,7 @@ The following table lists each custom global permission available and whether it
 | Manage Roles                       | ✓             |               |
 | Manage Users                       | ✓             |               |
 | Create Clusters                    | ✓             | ✓             |
-| User Catalog Templates             | ✓             | ✓             |
+| Use Catalog Templates             | ✓             | ✓             |
 | Login Access                       | ✓             | ✓             |
 
 > **Notes:** 
diff --git a/content/rancher/v2.x/en/catalog/_index.md b/content/rancher/v2.x/en/catalog/_index.md
index 57d577713a2..ec079814f6c 100644
--- a/content/rancher/v2.x/en/catalog/_index.md
+++ b/content/rancher/v2.x/en/catalog/_index.md
@@ -75,7 +75,7 @@ _Available as of v2.2.0_
 In Rancher v2.2.0, you can add private catalog repositories using credentials like Username and Password. You may also want to use the
 OAuth token if your Git or Helm repository server support that.
 
-[Read More About Adding Private Git/Helm Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/private/)
+[Read More About Adding Private Git/Helm Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/#private-repositories)
 
 <!--There are two types of catalogs that can be added into Rancher. There are global catalogs and project catalogs. In a global catalog, the catalog templates are available in *all* projects. In a project catalog, the catalog charts are only available in the project that the catalog is added to.
 
diff --git a/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md b/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md
index 4b598cf59cf..eeb685b96cf 100644
--- a/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md
@@ -7,15 +7,15 @@ _Available as of v2.2.0_
 
 In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) can be easily performed. Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.
 
-Rancher recommends enabling the ability to set up recurring snapshots, but one-time snapshots can easily be taken as well.  
+Rancher recommends configuring recurrent `etcd` snapshots for all production clusters. Additonally, one-time snapshots can easily be taken as well.
 
->**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Ranchher, you must [edit the cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/).
+>**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Rancher, you must [edit the cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/).
 
 ## Configuring Recurring Snapshots for the Cluster
 
-By default, any [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) are enabled to take recurring snapshots that are saved locally.
+By default, [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) are configured to take recurring snapshots (saved to local disk). To protect against local disk failure, using the [S3 Target](#s3-backup-target) or replicating the path on disk is advised.
 
-During cluster provisioning or editing the cluster, the configuration about snapshots are in the advanced section for **Cluster Options**. Click on **Show advanced options**.
+During cluster provisioning or editing the cluster, the configuration for snapshots can be found in the advanced section for **Cluster Options**. Click on **Show advanced options**.
 
 In the **Advanced Cluster Options** section, there are several options available to configure:
 
@@ -39,7 +39,7 @@ By default, the `local` backup target is selected. The benefits of this option i
 
 #### S3 Backup Target
 
-The `S3` backup target allows users to configure a S3 compatible backend to store the snapshots. The main benefit of this option is that if the cluster loses all the etcd nodes, the cluster can still be restored as the snapshots are stored externally. The downside of using the `S3` backup target is that additional configuration is required in order to have these snapshots saved remotely.
+The `S3` backup target allows users to configure a S3 compatible backend to store the snapshots. The primary benefit of this option is that if the cluster loses all the etcd nodes, the cluster can still be restored as the snapshots are stored externally. Rancher recommends external targets like `S3` backup, however its configuration reuqirements do require additional effort that should be considered. 
 
 | Option | Description | Required|
 |---|---|---|
@@ -55,7 +55,7 @@ Select how often you want recurring snapshots to be taken as well as how many sn
 
 ## One-Time Snapshots
 
-Besides recurring snapshots, you might want to take a one-time snapshot in specific use cases. For example, if you're about to upgrade the Kubernetes version of your cluster, you might want to take a snapshot right before the upgrade.
+In addition to recurring snapshots, you may want to take a "one-time" snapshot. For example, before upgrading the Kubernetes version of a cluster it's best to backup the state of the cluster to protect against upgrade failure. 
 
 1. In the **Global** view, navigate to the cluster that you want to take a one-time snapshot.
 
diff --git a/content/rancher/v2.x/en/cluster-admin/certificate-rotation/_index.md b/content/rancher/v2.x/en/cluster-admin/certificate-rotation/_index.md
index e45f9fd710f..aa817ecd9f0 100644
--- a/content/rancher/v2.x/en/cluster-admin/certificate-rotation/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/certificate-rotation/_index.md
@@ -3,12 +3,8 @@ title: Certificate Rotation
 weight: 2040
 ---
 
-_Available as of v2.2.0_
-
 By default, Kubernetes clusters require certificates and Rancher launched Kubernetes clusters automatically generate  certificates for the Kubernetes components. Rotating these certificates is important before the certificates expire as well as if a certificate is compromised. After the certificates are rotated, the Kubernetes components are automatically restarted.
 
-> **Note:** Even though the RKE CLI can use custom certificates for the Kubernetes cluster components, Rancher currently doesn't allow the ability to upload these in Rancher Launched Kubernetes clusters.
-
 Certificates can be rotated for the following services:
 
 - etcd
@@ -18,6 +14,11 @@ Certificates can be rotated for the following services:
 - kube-scheduler
 - kube-controller-manager
 
+
+### Certificate Rotation in Rancher v2.2.x
+
+_Available as of v2.2.0_
+
 Rancher launched Kubernetes clusters have the ability to rotate the auto-generated certificates through the UI.
 
 1. In the **Global** view, navigate to the cluster that you want to rotate certificates.
@@ -32,3 +33,24 @@ Rancher launched Kubernetes clusters have the ability to rotate the auto-generat
 4. Click **Save**.
 
 **Results:** The selected certificates will be rotated and the related services will be restarted to start using the new certificate.
+
+> **Note:** Even though the RKE CLI can use custom certificates for the Kubernetes cluster components, Rancher currently doesn't allow the ability to upload these in Rancher Launched Kubernetes clusters.
+
+
+### Certificate Rotation in Rancher v2.1.x and v2.0.x
+
+_Available as of v2.1.14 and v2.0.9_
+
+Rancher launched Kubernetes clusters have the ability to rotate the auto-generated certificates through the API.
+
+1. In the **Global** view, navigate to the cluster that you want to rotate certificates.
+
+2. Select the **Ellipsis (...) > View in API**.
+
+3. Click on **RotateCertificates**.
+
+4. Click on **Show Request**.
+
+5. Click on **Send Request**.
+
+**Results:** All kubernetes certificates will be rotated.
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 5140e780a9a..3d0ede984a5 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
@@ -19,16 +19,16 @@ When cleaning nodes provisioned using Rancher, the following components are dele
 | `serviceAccount`, `clusterRoles`, and `clusterRoleBindings` labeled by Rancher | ✓               | ✓                 | ✓                   | ✓                   |
 | Labels, Annotations, and Finalizers                                            | ✓               | ✓                 | ✓                   | ✓                   |
 | Rancher Deployment                                                             | ✓               | ✓                 | ✓                   |                     |
-| Machines, clusters, projects, and user custom resource deployments (CRDs)      | ✓               | ✓                 | ✓                   |                     |
+| Machines, clusters, projects, and user custom resource definitions (CRDs)      | ✓               | ✓                 | ✓                   |                     |
 | All resources create under the `management.cattle.io` API Group                | ✓               | ✓                 | ✓                   |                     |
-| All CRDs created by Rancher v2.0.x                                             | ✓               | ✓                 | ✓                   |                     |
+| All CRDs created by Rancher v2.x                                               | ✓               | ✓                 | ✓                   |                     |
 
 [1]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/
 [2]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/
 [3]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/
 [4]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/
 
-## Removing A Node from a Cluster by Rancher UI
+## Removing a Node from a Cluster by Rancher UI
 
 When the node is in `Active` state, removing the node from a cluster will trigger a process to clean up the node. Please restart the node after the automatic cleanup process is done to make sure any non-persistent data is properly removed.
 
@@ -36,10 +36,10 @@ When the node is in `Active` state, removing the node from a cluster will trigge
 
 ```
 # using reboot
-reboot
+$ sudo reboot
 
 # using shutdown
-shutdown -r now
+$ sudo shutdown -r now
 ```
 
 ## Cleaning a Node Manually
@@ -183,10 +183,10 @@ The remaining two components that are changed/configured are (virtual) network i
 
 ```
 # using reboot
-reboot
+$ sudo reboot
 
 # using shutdown
-shutdown -r now
+$ sudo shutdown -r now
 ```
 
 If you want to know more on (virtual) network interfaces or iptables rules, please see the specific subjects below.
@@ -223,7 +223,7 @@ ip link delete interface_name
 
 >**Note:** Depending on the network provider configured for the cluster the node was part of, some of the chains will or won't be present on the node.
 
-Iptables rules are used to route traffic from and to containers. The created rules are not persistent, so restarting the node will restore iptables to it's original state.
+Iptables rules are used to route traffic from and to containers. The created rules are not persistent, so restarting the node will restore iptables to its original state.
 
 Chains |
 --------|
diff --git a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md
index 17b63934f43..32843651a65 100644
--- a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md
@@ -30,7 +30,14 @@ For [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provis
 
 > **Note:** By default, all Rancher Launched Kubernetes clusters have [Authorized Cluster Endpoint]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#authorized-cluster-endpoint) enabled.
 
-To find the name of the context(s), view the kubeconfig file.
+To find the name of the context(s), run:
+
+```
+kubectl config get-contexts --kubeconfig /custom/path/kube.config
+CURRENT   NAME                        CLUSTER                     AUTHINFO     NAMESPACE
+*         my-cluster                  my-cluster                  user-46tmn
+          my-cluster-controlplane-1   my-cluster-controlplane-1   user-46tmn
+```
 
 ### Clusters with FQDN defined as an Authorized Cluster Endpoint
 
diff --git a/content/rancher/v2.x/en/cluster-admin/restoring-etcd/_index.md b/content/rancher/v2.x/en/cluster-admin/restoring-etcd/_index.md
index 95146d16814..e79f9f20478 100644
--- a/content/rancher/v2.x/en/cluster-admin/restoring-etcd/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/restoring-etcd/_index.md
@@ -9,7 +9,7 @@ etcd backup and recovery for [Rancher launched Kubernetes clusters]({{< baseurl
 
 Rancher recommends enabling the [ability to set up recurring snapshots of etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/#configuring-recurring-snapshots-for-the-cluster), but [one-time snapshots]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/#one-time-snapshots) can easily be taken as well. Rancher allows restore from [saved snapshots](#restoring-your-cluster-from-a-snapshot) or if you don't have any snapshots, you can still [restore etcd](#recovering-etcd-without-a-snapshot).
 
->**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Ranchher, you must [edit the cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the [updated snapshot features]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/). Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to back up and restore etcd through the UI.
+>**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Rancher, you must [edit the cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the [updated snapshot features]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/). Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to back up and restore etcd through the UI.
 
 ## Viewing Available Snapshots
 
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md
index 60618c1b81e..2bf5aba5ca3 100644
--- a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md
@@ -8,7 +8,7 @@ aliases:
 
 Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
 
-Rancher supports the following services:
+Rancher supports integration with the following services:
 
 - Elasticsearch
 - Splunk
@@ -56,7 +56,7 @@ As an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global
 
 1. Select **Tools > Logging** in the navigation bar.
 
-1. Select a logging service and enter the configuration. Refer to the specific service for detailed configuration. Rancher supports the following services:
+1. Select a logging service and enter the configuration. Refer to the specific service for detailed configuration. Rancher supports integration with the following services:
 
    - [Elasticsearch]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/elasticsearch/)
    - [Splunk]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/splunk/)
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md
index 957bd5a7a23..cfb1aba7009 100644
--- a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md
@@ -39,7 +39,7 @@ As an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global
 
 ### Resource Consumption
 
-When enabling cluster monitoring, you need to ensure your worker nodes and Prometheus pod have enough resources. The tables below provides a guide of how much resource consumption will be used.
+When enabling cluster monitoring, you need to ensure your worker nodes and Prometheus pod have enough resources. The tables below provides a guide of how much resource consumption will be used. In larger deployments, it is strongly advised that the monitoring infrastructure be placed on dedicated nodes in the cluster.
 
 #### Prometheus Pod Resource Consumption
 
@@ -51,6 +51,24 @@ Number of Cluster Nodes | CPU (milli CPU) | Memory | Disk
 50| 2000 | 2 GB | ~5 GB/Day
 256| 4000 | 6 GB | ~18 GB/Day
 
+Additional pod resource requirements for cluster level monitoring.
+
+Workload | Container | CPU - Request | Mem - Request | CPU - Limit | Mem - Limit | Configurable
+---------|-----------|---------------|---------------|-------------|-------------|-------------
+Prometheus|Prometheus| 750m | 750Mi| 1000m | 1000Mi| Y
+ ||Prometheus-proxy| 50m | 50Mi | 100m | 100Mi| Y
+ ||Prometheus-auth| 100m | 100Mi | 500m | 200Mi | Y
+ ||Prometheus-config-reloader| - | - | 50m | 50Mi | N
+ ||rules-configmap-reloader | - | - | 100m | 25Mi | N
+Grafana | grafana-init-plugin-json-copy | 50m |50Mi|50m|50Mi|Y
+ ||grafana-init-plugin-json-modify|50m|50Mi|50m|50Mi|Y
+ ||grafana |100m|100Mi|200m|200Mi|Y
+ ||grafana-proxy|50m|50Mi|100m|100Mi|Y
+Kube-State Exporter|kube-state |100m|130Mi|100m|200Mi|Y
+Node Exporter | exporter-node | 200m | 200Mi | 200m | 200Mi|Y
+Operator | prometheus-operator | 100m | 50Mi | 200m | 100Mi | Y
+
+
 #### Other Pods Resource Consumption
 
 Besides the Prometheus pod, there are components that are deployed that require additional resources on the worker nodes.
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/prometheus/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/prometheus/_index.md
index b4fac99a95b..0f667bcd1a6 100644
--- a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/prometheus/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/prometheus/_index.md
@@ -28,6 +28,8 @@ The [node exporter](https://github.com/prometheus/node_exporter/blob/master/READ
 
 When configuring Prometheus and enabling the node exporter, enter a host port in the **Node Exporter Host Port** that will not produce port conflicts with existing applications. The host port chosen must be open to allow internal traffic between Prometheus and the Node Exporter.
 
+>**Warning:** In order for Prometheus to collect the metrics of the node exporter, after enabling cluster monitoring, you must open the **Node Exporter Host Port** in the host firewall rules to allow intranet access. By default, `9796` is used as that host port.
+
 ## Persistent Storage
 
 >**Prerequisite:** Configure one or more [storage class]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/#adding-storage-classes) to use as [persistent storage]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/) for your Prometheus or Grafana pod.
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md
index 10adf21a7ea..5722a01b0a6 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md
@@ -140,7 +140,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2.
                 "arn:aws:ec2:REGION:AWS_ACCOUNT_ID:key-pair/*",
                 "arn:aws:ec2:REGION:AWS_ACCOUNT_ID:network-interface/*",
                 "arn:aws:ec2:REGION:AWS_ACCOUNT_ID:security-group/*",
-                "arn:aws:iam::AWS_ACCOUNT_ID:role/your-role-name"
+                "arn:aws:iam::AWS_ACCOUNT_ID:role/YOUR_ROLE_NAME"
             ]
         },
         {
diff --git a/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-for-private-reg/_index.md b/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-for-private-reg/_index.md
index ef20c1718c9..9dc14874cd3 100644
--- a/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-for-private-reg/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-for-private-reg/_index.md
@@ -7,7 +7,7 @@ aliases:
 
 Rancher needs to be configured to use the private registry in order to provision any [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) or [Rancher tools]({{< baseurl >}}/rancher/v2.x/en/tools/).
 
->**Note:** If you want to configure Rancher for your private registry when when starting the rancher/rancher container, you can use the environment variable `CATTLE_SYSTEM_DEFAULT_REGISTRY`.
+>**Note:** If you want to configure Rancher to use your private registry when starting the rancher/rancher container, you can use the environment variable `CATTLE_SYSTEM_DEFAULT_REGISTRY`.
 
 1. Log into Rancher and configure the default admin password.
 
diff --git a/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-system-charts/_index.md b/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-system-charts/_index.md
index f3743ba2f49..fd1ae176f70 100644
--- a/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-system-charts/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-system-charts/_index.md
@@ -6,7 +6,7 @@ aliases:
 
 ## A. Prepare System Charts
 
-The [System Charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as moniotring, logging, alerting and global DNS. To be able to use these features in an air gap install, you will need to mirror the `system-charts` repository to a location in your network that Rancher can reach and configure Rancher to use that repository.
+The [System Charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. To be able to use these features in an air gap install, you will need to mirror the `system-charts` repository to a location in your network that Rancher can reach and configure Rancher to use that repository.
 
 ## B. Configure System Charts
 
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 98d8199aee6..2866ca911e5 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,7 +15,7 @@ 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.
+> **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. If you are using a private CA signed certificate, replacing the certificate is only possible if the new certificate is signed by the same CA as the certificate currently in use.
 
 ### Using a Private CA Signed Certificate
 
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 05f5ed1e839..88dbcb7e8f9 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
@@ -78,9 +78,9 @@ Test your connectivity with `kubectl` and see if all your nodes are in `Ready` s
 kubectl get nodes
 
 NAME                          STATUS    ROLES                      AGE       VERSION
-165.227.114.63                Ready     controlplane,etcd,worker   11m       v1.10.1
-165.227.116.167               Ready     controlplane,etcd,worker   11m       v1.10.1
-165.227.127.226               Ready     controlplane,etcd,worker   11m       v1.10.1
+165.227.114.63                Ready     controlplane,etcd,worker   11m       v1.13.5
+165.227.116.167               Ready     controlplane,etcd,worker   11m       v1.13.5
+165.227.127.226               Ready     controlplane,etcd,worker   11m       v1.13.5
 ```
 
 ### Check the Health of Your Cluster Pods
diff --git a/content/rancher/v2.x/en/installation/requirements/_index.md b/content/rancher/v2.x/en/installation/requirements/_index.md
index 109ca0ee078..9b046959f1f 100644
--- a/content/rancher/v2.x/en/installation/requirements/_index.md
+++ b/content/rancher/v2.x/en/installation/requirements/_index.md
@@ -11,16 +11,16 @@ Whether you're configuring Rancher to run in a single-node or high-availability
 <br>
 Rancher is tested on the following operating systems and their subsequent non-major releases with a supported version of [Docker](https://www.docker.com/).
 
-*   Ubuntu 16.04 (64-bit)
+*   Ubuntu 16.04 (64-bit x86)
   * Docker 17.03.x, 18.06.x, 18.09.x
-*   Ubuntu 18.04 (64-bit)
+*   Ubuntu 18.04 (64-bit x86)
   * Docker 18.06.x, 18.09.x
-*   Red Hat Enterprise Linux (RHEL)/CentOS 7.6 (64-bit)
+*   Red Hat Enterprise Linux (RHEL)/CentOS 7.6 (64-bit x86)
   * RHEL Docker 1.13
   * Docker 17.03.x, 18.06.x, 18.09.x
-*   RancherOS 1.5.1 (64-bit)
+*   RancherOS 1.5.1 (64-bit x86)
   * Docker 17.03.x, 18.06.x, 18.09.x
-*   Windows Server 2019 (64-bit)
+*   Windows Server 2019 (64-bit x86)
   * Docker 18.09 
   * _Experimental, see [Configuring Custom Clusters for Windows]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/)_
 
@@ -32,7 +32,9 @@ sudo ros engine list
 # Switch to a supported version
 sudo ros engine switch docker-18.09.2
 ```
-
+See [Running on ARM64 (Experimental)]({{< baseurl >}}/rancher/v2.x/en/installation/arm64-platform/) if you plan to run Rancher on ARM64.
+<br>
+<br>
 [Docker Documentation: Installation Instructions](https://docs.docker.com/)
 <br>
 <br>
diff --git a/content/rancher/v2.x/en/installation/single-node/_index.md b/content/rancher/v2.x/en/installation/single-node/_index.md
index da42b4201b9..dabf756c793 100644
--- a/content/rancher/v2.x/en/installation/single-node/_index.md
+++ b/content/rancher/v2.x/en/installation/single-node/_index.md
@@ -88,7 +88,7 @@ docker run -d --restart=unless-stopped \
 {{% /accordion %}}
 {{% accordion id="option-d" label="Option D-Let's Encrypt Certificate" %}}
 
-For production environments, you also have the options of using [Let's Encrypt](https://letsencrypt.org/) certificates. Let's Encrypt uses an http-01 challenge to verify that you have control over your domain. You can confirm that you control the domain by pointing the hostname that you want to use for Rancher access (for example, `rancher.mydomain.com`) to the IP of the machine it is running on. You can bind the hostname to the IP address by creating an A record in DNS.
+For production environments, you also have the option of using [Let's Encrypt](https://letsencrypt.org/) certificates. Let's Encrypt uses an http-01 challenge to verify that you have control over your domain. You can confirm that you control the domain by pointing the hostname that you want to use for Rancher access (for example, `rancher.mydomain.com`) to the IP of the machine it is running on. You can bind the hostname to the IP address by creating an A record in DNS.
 
 >**Prerequisites:**
 >
@@ -186,7 +186,7 @@ If you are visiting this page to complete an air gap installation, you must pre-
 
 In the situation where you want to use a single node to run Rancher and to be able to add the same node to a cluster, you have to adjust the host ports mapped for the `rancher/rancher` container.
 
-If a node is added to a cluster, it deploys the nginx ingress controller which will use port 80 and 443. This will conflict with the default ports we advice to expose for the `rancher/rancher` container.
+If a node is added to a cluster, it deploys the nginx ingress controller which will use port 80 and 443. This will conflict with the default ports we advise to expose for the `rancher/rancher` container.
 
 Please note that this setup is not recommended for production use, but can be convenient for development/demo purposes.
 
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md
index 08a4077a03e..c2821d5c62a 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md
@@ -24,7 +24,7 @@ Load Balancers have a couple of limitations you should be aware of:
 
 - Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive.
 
-- If you want to use a load balancer with a Hosted Kubernetes cluster (i.e., clusters hosted in GKE, EKS, or AKS), you must host your load balancer with the same cloud provider. Please review the compatibility tables regarding support for load balancers based on how you've provisioned your clusters:
+- If you want to use a load balancer with a Hosted Kubernetes cluster (i.e., clusters hosted in GKE, EKS, or AKS), the load balancer must be running within that cloud provider's infrastructure. Please review the compatibility tables regarding support for load balancers based on how you've provisioned your clusters:
 
 
     - [Support for Layer-4 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#support-for-layer-4-load-balancing)
diff --git a/content/rancher/v2.x/en/project-admin/namespaces/_index.md b/content/rancher/v2.x/en/project-admin/namespaces/_index.md
index ba3b9cf7dc2..e56bfd6bc1c 100644
--- a/content/rancher/v2.x/en/project-admin/namespaces/_index.md
+++ b/content/rancher/v2.x/en/project-admin/namespaces/_index.md
@@ -5,7 +5,7 @@ weight: 2520
 
 Within Rancher, you can further divide projects into different [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/), which are virtual clusters within a project backed by a physical cluster. Should you require another level of organization beyond projects and the `default` namespace, you can use multiple namespaces to isolate applications and resources.
 
-Although you assign resources at the project level so that each namespace can in the project can use them, you can override this inheritance by assigning resources explicitly to a namespace.
+Although you assign resources at the project level so that each namespace in the project can use them, you can override this inheritance by assigning resources explicitly to a namespace.
 
 Resources that you can assign directly to namespaces include:
 
diff --git a/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md b/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md
index b2f98bc7065..150463f4a8c 100644
--- a/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md
+++ b/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md
@@ -20,7 +20,7 @@ In the following diagram, a Kubernetes admin is trying to enforce a resource quo
 <sup>Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace</sup>
 ![Native Kubernetes Resource Quota Implementation]({{< baseurl >}}/img/rancher/kubernetes-resource-quota.svg)
 
-Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), and then the quota propagates to each namespace, whereafter Kubernetes enforces you limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can [override it](#overriding-the-default-limit-for-a-namespace).
+Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), and then the quota propagates to each namespace, whereafter Kubernetes enforces your limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can [override it](#overriding-the-default-limit-for-a-namespace).
 
 The resource quota includes two limits, which you set while creating or editing a project:
 <a id="project-limits"></a>
diff --git a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/_index.md b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/_index.md
index e5c87ab8e39..e224efc44ce 100644
--- a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/_index.md
+++ b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/_index.md
@@ -58,16 +58,22 @@ The cluster state (`/var/lib/etcd`) contains wrong information to join the clust
 
 ### etcd cluster and connectivity checks
 
-If any of the commands respond with `Error:  context deadline exceeded`, the etcd instance is unhealthy (either quorum is lost or the instance is not correctly joined in the cluster)
+The address where etcd is listening depends on the address configuration of the host etcd is running on. If an internal address is configured for the host etcd is running on, the endpoint for `etcdctl` needs to be specified explicitly. If any of the commands respond with `Error:  context deadline exceeded`, the etcd instance is unhealthy (either quorum is lost or the instance is not correctly joined in the cluster)
 
 * Check etcd members on all nodes
 
 Output should contain all the nodes with the `etcd` role and the output should be identical on all nodes.
 
+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl member list
 ```
 
+Command when internal address is configured on the host:
+```
+docker exec etcd sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list"
+```
+
 Example output:
 ```
 xxx, started, etcd-xxx, https://IP:2380, https://IP:2379,https://IP:4001
@@ -79,10 +85,16 @@ xxx, started, etcd-xxx, https://IP:2380, https://IP:2379,https://IP:4001
 
 The values for `RAFT TERM` should be equal and `RAFT INDEX` should be not be too far apart from each other.
 
+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl endpoint status --endpoints=$(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','") --write-out table
 ```
 
+Command when internal address is configured on the host:
+```
+docker exec etcd etcdctl endpoint status --endpoints=$(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','") --write-out table
+```
+
 Example output:
 ```
 +-----------------+------------------+---------+---------+-----------+-----------+------------+
@@ -96,10 +108,16 @@ Example output:
 
 * Check endpoint health
 
+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl endpoint health --endpoints=$(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','")
 ```
 
+Command when internal address is configured on the host:
+```
+docker exec etcd etcdctl endpoint health --endpoints=$(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','")
+```
+
 Example output:
 ```
 https://IP:2379 is healthy: successfully committed proposal: took = 2.113189ms
@@ -109,6 +127,7 @@ https://IP:2379 is healthy: successfully committed proposal: took = 2.451201ms
 
 * Check connectivity on port TCP/2379
 
+Command when no internal address is configured on the host:
 ```
 for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5"); do
   echo "Validating connection to ${endpoint}/health";
@@ -116,8 +135,17 @@ for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5
 done
 ```
 
+Command when internal address is configured on the host:
+```
+for endpoint in $(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5"); do
+  echo "Validating connection to ${endpoint}/health";
+  curl -w "\n" --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) "${endpoint}/health";
+done
+```
+
 If you are running on an operating system without `curl` (for example, RancherOS), you can use the following command which uses a Docker container to run the `curl` command.
 
+Command when no internal address is configured on the host:
 ```
 for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5"); do
   echo "Validating connection to ${endpoint}/health";
@@ -125,6 +153,14 @@ for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5
 done
 ```
 
+Command when internal address is configured on the host:
+```
+for endpoint in $(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5"); do
+  echo "Validating connection to ${endpoint}/health";
+  docker run --net=host -v /opt/rke/etc/kubernetes/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -w "\n" --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) "${endpoint}/health"
+done
+```
+
 Example output:
 ```
 Validating connection to https://IP:2379/health
@@ -137,6 +173,7 @@ Validating connection to https://IP:2379/health
 
 * Check connectivity on port TCP/2380
 
+Command when no internal address is configured on the host:
 ```
 for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f4"); do
   echo "Validating connection to ${endpoint}/version";
@@ -144,8 +181,17 @@ for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f4
 done
 ```
 
+Command when internal address is configured on the host:
+```
+for endpoint in $(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f4"); do
+  echo "Validating connection to ${endpoint}/version";
+  curl -w "\n" --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) "${endpoint}/version";
+done
+```
+
 If you are running on an operating system without `curl` (for example, RancherOS), you can use the following command which uses a Docker container to run the `curl` command.
 
+Command when no internal address is configured on the host:
 ```
 for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f4"); do
   echo "Validating connection to ${endpoint}/version";
@@ -153,6 +199,14 @@ for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f4
 done
 ```
 
+Command when internal address is configured on the host:
+```
+for endpoint in $(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f4"); do
+  echo "Validating connection to ${endpoint}/version";
+  docker run --net=host -v /opt/rke/etc/kubernetes/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -w "\n" --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) "${endpoint}/version"
+done
+```
+
 Example output:
 ```
 Validating connection to https://IP:2380/version
@@ -167,10 +221,16 @@ Validating connection to https://IP:2380/version
 
 etcd will trigger alarms, for instance when it runs out of space.
 
+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl alarm list
 ```
 
+Command when internal address is configured on the host:
+```
+docker exec etcd sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT alarm list"
+```
+
 Example output when NOSPACE alarm is triggered:
 ```
 memberID:x alarm:NOSPACE
@@ -186,11 +246,18 @@ Resolution:
 
 * Compact the keyspace
 
+Command when no internal address is configured on the host:
 ```
 rev=$(docker exec etcd etcdctl endpoint status --write-out json | egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*')
 docker exec etcd etcdctl compact "$rev"
 ```
 
+Command when internal address is configured on the host:
+```
+rev=$(docker exec etcd sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT endpoint status --write-out json | egrep -o '\"revision\":[0-9]*' | egrep -o '[0-9]*'")
+docker exec etcd sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT compact \"$rev\""
+```
+
 Example output:
 ```
 compacted revision xxx
@@ -198,10 +265,16 @@ compacted revision xxx
 
 * Defrag all etcd members
 
+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl defrag --endpoints=$(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','")
 ```
 
+Command when internal address is configured on the host:
+```
+docker exec etcd sh -c "etcdctl defrag --endpoints=$(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','")"
+```
+
 Example output:
 ```
 Finished defragmenting etcd member[https://IP:2379]
@@ -211,10 +284,16 @@ Finished defragmenting etcd member[https://IP:2379]
 
 * Check endpoint status
 
+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl endpoint status --endpoints=$(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','") --write-out table
 ```
 
+Command when internal address is configured on the host:
+```
+docker exec etcd sh -c "etcdctl endpoint status --endpoints=$(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','") --write-out table"
+```
+
 Example output:
 ```
 +-----------------+------------------+---------+---------+-----------+-----------+------------+
@@ -226,6 +305,32 @@ Example output:
 +-----------------+------------------+---------+---------+-----------+-----------+------------+
 ```
 
+### Log level
+
+The log level of etcd can be changed dynamically via the API. You can configure debug logging using the commands below.
+
+Command when no internal address is configured on the host:
+```
+curl -XPUT -d '{"Level":"DEBUG"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) https://localhost:2379/config/local/log
+```
+
+Command when internal address is configured on the host:
+```
+curl -XPUT -d '{"Level":"DEBUG"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) $(docker exec etcd printenv $ETCDCTL_ENDPOINT)/config/local/log
+```
+
+To reset the log level back to the default (`INFO`), you can use the following command.
+
+Command when no internal address is configured on the host:
+```
+curl -XPUT -d '{"Level":"INFO"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) https://localhost:2379/config/local/log
+```
+
+Command when internal address is configured on the host:
+```
+curl -XPUT -d '{"Level":"INFO"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) $(docker exec etcd printenv $ETCDCTL_ENDPOINT)/config/local/log
+```
+
 ## controlplane
 
 This section applies to nodes with the `controlplane` role.
diff --git a/content/rancher/v2.x/en/troubleshooting/kubernetes-resources/_index.md b/content/rancher/v2.x/en/troubleshooting/kubernetes-resources/_index.md
index fb4575d0b6a..06d63135786 100644
--- a/content/rancher/v2.x/en/troubleshooting/kubernetes-resources/_index.md
+++ b/content/rancher/v2.x/en/troubleshooting/kubernetes-resources/_index.md
@@ -20,28 +20,30 @@ Run the command below and check the following:
 
 
 ```
-kubectl get nodes
+kubectl get nodes -o wide
 ``` 
 
 Example output:
 
 ```
-NAME                              STATUS    ROLES          AGE       VERSION   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
-etcd-0                            Ready     etcd           2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-etcd-1                            Ready     etcd           2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-etcd-2                            Ready     etcd           2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-controlplane-0                    Ready     controlplane   2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-controlplane-1                    Ready     controlplane   1m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-worker-0                          Ready     worker         2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-worker-1                          Ready     worker         2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
+NAME             STATUS   ROLES          AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
+controlplane-0   Ready    controlplane   31m   v1.13.5   138.68.188.91    <none>        Ubuntu 18.04.2 LTS   4.15.0-47-generic   docker://18.9.5
+etcd-0           Ready    etcd           31m   v1.13.5   138.68.180.33    <none>        Ubuntu 18.04.2 LTS   4.15.0-47-generic   docker://18.9.5
+worker-0         Ready    worker         30m   v1.13.5   139.59.179.88    <none>        Ubuntu 18.04.2 LTS   4.15.0-47-generic   docker://18.9.5
 ```
 
 #### Get node conditions
 
+Run the command below to list nodes with [Node Conditions](https://kubernetes.io/docs/concepts/architecture/nodes/#condition)
+
+```
+kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{end}}'
+```
+
 Run the command below to list nodes with [Node Conditions](https://kubernetes.io/docs/concepts/architecture/nodes/#condition) that are active that could prevent normal operation.
 
 ```
-kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{if ne .type "Ready"}}{{if eq .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{end}}{{end}}{{end}}'
+kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{if ne .type "Ready"}}{{if eq .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{else}}{{if ne .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{": "}}{{.status}}{{"\n"}}{{end}}{{end}}{{end}}{{end}}'
 ```
 
 Example output:
diff --git a/content/rancher/v2.x/en/troubleshooting/rancherha/_index.md b/content/rancher/v2.x/en/troubleshooting/rancherha/_index.md
index 9ef9d9e0d99..5a90616e985 100644
--- a/content/rancher/v2.x/en/troubleshooting/rancherha/_index.md
+++ b/content/rancher/v2.x/en/troubleshooting/rancherha/_index.md
@@ -68,3 +68,13 @@ When accessing your configured Rancher FQDN does not show you the UI, check the
 ```
 kubectl -n ingress-nginx logs -l app=ingress-nginx
 ```
+
+### Leader election
+
+The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` ConfigMap (in this example, `rancher-7dbd7875f7-qbj5k`).
+
+```
+kubectl -n kube-system get configmap cattle-controllers -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
+{"holderIdentity":"rancher-7dbd7875f7-qbj5k","leaseDurationSeconds":45,"acquireTime":"2019-04-04T11:53:12Z","renewTime":"2019-04-04T12:24:08Z","leaderTransitions":0}
+```
+
diff --git a/content/rke/latest/en/config-options/_index.md b/content/rke/latest/en/config-options/_index.md
index e47133db2c7..0df26d39165 100644
--- a/content/rke/latest/en/config-options/_index.md
+++ b/content/rke/latest/en/config-options/_index.md
@@ -122,5 +122,3 @@ $ echo $SSH_AUTH_SOCK
 ### Add-ons Job Timeout
 
 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/latest/en/config-options/services/_index.md b/content/rke/latest/en/config-options/services/_index.md
index 3094ce25381..6fb743534f6 100644
--- a/content/rke/latest/en/config-options/services/_index.md
+++ b/content/rke/latest/en/config-options/services/_index.md
@@ -65,7 +65,7 @@ services:
 
 ### Kubernetes Controller Manager Options
 
-RKE support the following options for the `kube-controller` service:
+RKE supports the following options for the `kube-controller` service:
 
 - **Cluster CIDR** (`cluster_cidr`) - The CIDR pool used to assign IP addresses to pods in the cluster. By default, each node in the cluster is assigned a `/24` network from this pool for pod IP assignments. The default value for this option is `10.42.0.0/16`.
 - **Service Cluster IP Range** (`service_cluster_ip_range`) - This is the virtual IP address that will be assigned to services created on Kubernetes. By default, the service cluster IP range is `10.43.0.0/16`. If you change this value, then it must also be set with the same value on the Kubernetes API server (`kube-api`).
diff --git a/content/rke/latest/en/installation/_index.md b/content/rke/latest/en/installation/_index.md
index 5fd20634b65..738f294a5ab 100644
--- a/content/rke/latest/en/installation/_index.md
+++ b/content/rke/latest/en/installation/_index.md
@@ -6,6 +6,7 @@ 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)
+    1. [Alternative RKE MacOS X Install - Homebrew](#alternative-rke-macos-x-install---homebrew)
 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)
@@ -49,6 +50,25 @@ RKE is a fast, versatile Kubernetes installer that you can use to install Kubern
     $ rke --version
     ```
 
+
+### Alternative RKE MacOS X Install - Homebrew
+
+RKE can also be installed and updated using Homebrew, a package manager for MacOS X.
+
+1. Install Homebrew. See https://brew.sh/ for instructions.
+
+2. Using `brew`, install RKE by running the following command in a Terminal window:
+
+    ```
+    $ brew install rke
+    ```
+
+If you have already installed RKE using `brew`, you can upgrade RKE by running:
+
+```
+$ brew upgrade rke
+```
+
 ## Prepare the Nodes for the Kubernetes cluster
 
 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.
diff --git a/scripts/dev-windows.ps1 b/scripts/dev-windows.ps1
new file mode 100755
index 00000000000..72350371c7e
--- /dev/null
+++ b/scripts/dev-windows.ps1
@@ -0,0 +1,74 @@
+#Requires -Version 5.0
+
+param (
+    [parameter(Mandatory = $false,HelpMessage="Build the build & dev images instead of pulling from the registry")] [switch]$buildBuild,
+    [parameter(Mandatory = $false,HelpMessage="Build the dev image instead of pulling from the registry")] [switch]$buildDev,
+    [parameter(Mandatory = $false,HelpMessage="Port to listen on")] [string]$port,
+    [parameter(Mandatory = $false,HelpMessage="Skip pulling build/dev images")] [switch]$skipPull,
+    [parameter(Mandatory = $false,HelpMessage="Use DIR to for the theme, to devlop the theme at the same time")] [string]$theme,
+    [parameter(Mandatory = $false,HelpMessage="Upload/push the build image after building")] [switch]$upload
+)
+
+$DefaultPort = 9001
+$ListenPort = $DefaultPort
+$Image = "rancher/docs"
+$Tag = "dev"
+$twitterConsumer = $env:TWITTER_CONSUMER
+$twitterSecret = $env:TWITTER_SECRET
+
+$dirPath = Split-Path -Parent $MyInvocation.MyCommand.Definition
+$baseDirPath = Get-Location
+if ($dirPath -eq $baseDirPath) {
+  $baseDirPath = (Resolve-Path "$dirPath\..").Path
+}
+pushd $baseDirPath
+
+if ($port) {
+    $ListenPort = $port
+}
+
+$ThemeVolume = ""
+if ($theme) {
+    Write-Host "Using theme from $theme"
+    $ThemeVolume = "-v ${baseDirPath}/${theme}:/run/node_modules/rancher-website-theme"
+}
+
+if ($buildBuild) {
+    Write-Host "Building ${Image}:build"
+    docker build --no-cache -f Dockerfile.build --build-arg TWITTER_CONSUMER=$twitterConsumer --build-arg TWITTER_SECRET=$twitterSecret -t ${Image}:build .
+    if ($upload) {
+        docker push ${Image}:build
+    }
+    $buildDev = $true
+} elseif ($skipPull) {
+    Write-Host "Skipping pull of ${Image}:build"
+} else {
+    Write-Host "Pulling ${Image}:build"
+    docker pull ${Image}:build
+}
+
+if ($buildDev) {
+    $Tag = "local"
+    Write-Host "Building ${Image}:${Tag}"
+    docker build -f Dockerfile.dev -t ${Image}:${Tag} .
+} elseif ($skipPull) {
+    Write-Host "Skipping pull of ${Image}:${Tag}"
+} else {
+    Write-Host "Pulling ${Image}:${Tag}"
+    docker pull ${Image}:${Tag}
+}
+
+Write-Host "Starting server on http://localhost:${ListenPORT}"
+docker run --rm -p ${ListenPort}:${ListenPort} -it `
+  -v ${baseDirPath}/archetypes:/run/archetypes `
+  -v ${baseDirPath}/assets:/run/assets `
+  -v ${baseDirPath}/content:/run/content `
+  -v ${baseDirPath}/data:/run/data `
+  -v ${baseDirPath}/layouts:/run/layouts `
+  -v ${baseDirPath}/scripts:/run/scripts `
+  -v ${baseDirPath}/static:/run/static `
+  -v ${baseDirPath}/.git:/run/.git `
+  -v ${baseDirPath}/config.toml:/run/config.toml `
+  ${ThemeVolume} ${Image}:${Tag} --port=${ListenPort}
+
+popd