Merge v2.10.2 release branch into main (#1617 )

* [2.10.2] versions update Signed-off-by: Sunil Singh <sunil.singh@suse.com> * [2.10.2] webhook table update Signed-off-by: Sunil Singh <sunil.singh@suse.com> * [2.10.2] csp table update Signed-off-by: Sunil Singh <sunil.singh@suse.com> * [2.10.2] deprecated features table update Signed-off-by: Sunil Singh <sunil.singh@suse.com> * [2.10.2] CNI update Signed-off-by: Sunil Singh <sunil.singh@suse.com> * [2.10.2] webhook update after review Signed-off-by: Sunil Singh <sunil.singh@suse.com> --------- Signed-off-by: Sunil Singh <sunil.singh@suse.com> Co-authored-by: Sunil Singh <sunil.singh@suse.com>
Merge v2.9.6 release branch into main (#1616 )
2026-09-29 06:29:34 +00:00 · 2025-01-29 10:51:45 -08:00 · 2025-01-29 10:51:30 -08:00 · 2025-01-29 10:51:00 -08:00 · 2025-01-22 15:28:21 -08:00 · 2025-01-22 13:10:03 -04:00
5095 changed files with 425474 additions and 103232 deletions
@@ -0,0 +1,8 @@
+version: 2
+
+updates:
+  - package-ecosystem: gitsubmodule
+    schedule:
+        interval: "daily"
+    directory: /
+    
@@ -10,7 +10,7 @@ Fixes #[issue_number]

 - Verify if changes pertain to other versions of Rancher. If they do, finalize the edits on one version of the page, then apply the edits to the other versions.

- If the pull request is dependent on an upcoming release, make sure to target the release branch instead of `main`.
+- If the pull request is dependent on an upcoming release, remember to add a "MERGE ON RELEASE" label and set the proper milestone.

 ## Description

@@ -24,4 +24,4 @@ Fixes #[issue_number]

 <!--
 Any additional notes a reviewer should know before we review.
-->
+-->
@@ -4,16 +4,18 @@ on:
  push:
    branches:
      - main
+    paths-ignore:
+      - '**/README.md'

 jobs:
-  deploy:
-    name: Deploy to GitHub Pages
+  build:
+    name: Build Docusaurus
    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
-      - uses: actions/setup-node@v3
+      - uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: yarn
@@ -22,21 +24,28 @@ jobs:
        run: yarn install --frozen-lockfile
      - name: Build website
        env:
-          NODE_OPTIONS: "--max_old_space_size=5120"
+          NODE_OPTIONS: "--max_old_space_size=7168"
        run: yarn build --no-minify

-      # Popular action to deploy to GitHub Pages:
-      # Docs: https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-docusaurus
-      - name: Deploy to GitHub Pages
-        uses: peaceiris/actions-gh-pages@v3
+      - name: Upload Build Artifact
+        uses: actions/upload-pages-artifact@v3
        with:
-          github_token: ${{ secrets.GITHUB_TOKEN }}
-          # Build output to publish to the `gh-pages` branch:
-          publish_dir: ./build
-          # The following lines assign commit authorship to the official
-          # GH-Actions bot for deploys to `gh-pages` branch:
-          # https://github.com/actions/checkout/issues/13#issuecomment-724415212
-          # The GH actions bot is used by default if you didn't specify the two fields.
-          # You can swap them out with your own user credentials.
-          user_name: github-actions[bot]
-          user_email: 41898282+github-actions[bot]@users.noreply.github.com
+          path: build
+
+  deploy:
+    name: Deploy to GitHub Pages
+    needs: build
+
+    permissions:
+      pages: write
+      id-token: write
+    
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+
+    runs-on: ubuntu-latest
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4
@@ -2,16 +2,18 @@ name: Test deployment

 on:
  pull_request:
-    branches:
-      - main
+    paths-ignore:
+      - '**/README.md'

 jobs:
  test-deploy:
    name: Test deployment
    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@v3
-      - uses: actions/setup-node@v3
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: yarn
@@ -19,10 +21,10 @@ jobs:
      - name: Install dependencies
        run: yarn install --frozen-lockfile
      - name: Check Markdown links
-        run: yarn run remark --quiet --use remark-validate-links ./docs
+        run: yarn run remark --quiet --frail --use remark-validate-links ./docs
      - name: Check External links
        run: yarn run remark --quiet --use remark-lint-no-dead-urls ./docs
      - name: Test build website
        env:
-          NODE_OPTIONS: "--max_old_space_size=5120"
+          NODE_OPTIONS: "--max_old_space_size=7168"
        run: yarn build --no-minify
@@ -0,0 +1,3 @@
+[submodule ".github/styles/suse-vale-styleguide"]
+	path = .github/styles/suse-vale-styleguide
+	url = https://github.com/openSUSE/suse-vale-styleguide
@@ -0,0 +1,7 @@
+StylesPath = .github/styles/suse-vale-styleguide
+
+[formtats]
+mdx = md
+
+[*.md]
+BasedOnStyles = common
@@ -0,0 +1 @@
+* @btat @LucasSaintarbor @sunilarjun
@@ -15,19 +15,29 @@ To get started, [fork](https://github.com/rancher/rancher-docs/fork) and clone t

 Our repository doesn't allow you to make changes directly to the `main` branch. Create a working branch and make pull requests from your fork to [rancher/rancher-docs](https://github.com/rancher/rancher-docs).

-For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of December 2023, the most recently released version of Rancher is 2.8.
+For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of August 2024, the most recently released version of Rancher is 2.9.

-Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.8`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.
+Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.9`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.

 If a file is moved or renamed, you'll also need to edit the `sidebars.js` files for each affected version, as well as the list of redirects in `docusaurus.config.js`. See [Moving or Renaming Docs](./moving-or-renaming-docs.md).

 ### Navigate the Repo

-The file paths in the repo correspond to the URLs for pages on the docs website. The docs for the latest version of Rancher are located in `/docs`. Most index pages are found within the `/pages-for-subheaders` directory in `/docs`. All images are in `/static/img` in the top level of the repo. Older docs are found within `/versioned_docs` and generally follow the same structure as the files in `/docs`.
+The file paths in the repo correspond to the URLs for pages on the docs website. The docs for the latest version of Rancher are located in `/docs`. All images are in `/static/img` in the top level of the repo. Older docs are found within `/versioned_docs` and generally follow the same structure as the files in `/docs`.

 ### Style & Formatting

-The docs are written in [Markdown](https://www.markdownguide.org/getting-started/). We refer to the Microsoft [style guide](https://learn.microsoft.com/en-us/style-guide/welcome/) and use standard American English. Many pages are also available in Simplified Chinese.
+The docs are written in [Markdown](https://www.markdownguide.org/getting-started/). We use standard American English and many pages are also available in Simplified Chinese.
+
+Moving forward, we are referring to the SUSE [style guide](https://documentation.suse.com/style/current/pdf/style-guide_en.pdf). The **Style check / runner / vale (pull_request)** check used [Vale](https://vale.sh/) to make style and grammar suggestions for new or updated documentation based on the SUSE style guide. To review these suggestions when working on a PR:
+
+1. Select the details of the **Style check / runner / vale (pull_request)** check.
+1. In the logs, go to **Run errata-ai/vale-action@v2.1.0** and select **Running vale with reviewdog 🐶 ...** to view the suggestions.
+1. New or updated files are checked against the SUSE style guide. Suggestions have the following format: '{"message": "[suse-vale-styleguide.Rule] Rule description", "location": {"path": "file-path", "range": {"start": {"line": , "column": }}}, "severity": " "}'
+
+    For example: '{"message": "[suse-vale-styleguide.Usage] Use 'certain' instead of 'some'", "location": {"path": "docs/contribute-to-rancher.md", "range": {"start": {"line": 3, "column": 132}}}, "severity": "WARNING"}'
+
+1. Incorporate the suggestions when possible and appropriate.

 Every docs page contain metadata in the first few lines:

@@ -0,0 +1,26 @@
+---
+title: CIS Scans
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cis-scans"/>
+</head>
+
+_Available as of v2.4.0_
+
+- [Prerequisites](#prerequisites)
+- [How-to Guides](#how-to-guides)
+
+## Prerequisites
+
+To run security scans on a cluster and access the generated reports, you must be an [Administrator](../../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md) or [Cluster Owner.](../../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)
+
+Rancher can only run security scans on clusters that were created with RKE, which includes custom clusters and clusters that Rancher created in an infrastructure provider such as Amazon EC2 or GCE. Imported clusters and clusters in hosted Kubernetes providers can't be scanned by Rancher.
+
+The security scan cannot run in a cluster that has Windows nodes.
+
+You will only be able to see the CIS scan reports for clusters that you have access to.
+
+## How-to Guides
+
+Please refer [here](../../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md) for how-to guides on CIS scans.
@@ -11,13 +11,13 @@ To keep your clusters and applications healthy and driving your organizational p

 ## About Alerts

-Notifiers and alerts are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher can notify [cluster owners](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles) and [project owners](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) of events they need to address.
+Notifiers and alerts are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher can notify [cluster owners](../../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles) and [project owners](../../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) of events they need to address.

 Before you can receive alerts, you must configure one or more notifier in Rancher.

-When you create a cluster, some alert rules are predefined. You can receive these alerts if you configure a [notifier](../explanations/integrations-in-rancher/notifiers.md) for them.
+When you create a cluster, some alert rules are predefined. You can receive these alerts if you configure a [notifier](../notifiers.md) for them.

-For details about what triggers the predefined alerts, refer to the [documentation on default alerts.](../explanations/integrations-in-rancher/cluster-alerts/default-alerts.md)
+For details about what triggers the predefined alerts, refer to the [documentation on default alerts.](default-alerts.md)

 ### Alert Event Examples

@@ -30,9 +30,9 @@ Some examples of alert events are:

 ### Alerts Triggered by Prometheus Queries

-When you edit an alert rule, you will have the opportunity to configure the alert to be triggered based on a Prometheus expression. For examples of expressions, refer to [this page.](../explanations/integrations-in-rancher/cluster-monitoring/expression.md)
+When you edit an alert rule, you will have the opportunity to configure the alert to be triggered based on a Prometheus expression. For examples of expressions, refer to [this page.](../cluster-monitoring/expression.md)

-Monitoring must be [enabled](./cluster-monitoring.md) before you can trigger alerts with custom Prometheus queries or expressions.
+Monitoring must be [enabled](../cluster-monitoring/cluster-monitoring.md) before you can trigger alerts with custom Prometheus queries or expressions.

 ### Urgency Levels

@@ -40,7 +40,7 @@ You can set an urgency level for each alert. This urgency appears in the notific

 ### Scope of Alerts

-The scope for alerts can be set at either the cluster level or [project level](../reference-guides/rancher-project-tools/project-alerts.md).
+The scope for alerts can be set at either the cluster level or [project level](../../../reference-guides/rancher-project-tools/project-alerts.md).

 At the cluster level, Rancher monitors components in your Kubernetes cluster, and sends you alerts related to:

@@ -61,15 +61,15 @@ After you set up cluster alerts, you can manage each alert object. To manage ale

 ## Adding Cluster Alerts

-As a [cluster owner](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), you can configure Rancher to send you alerts for cluster events.
+As a [cluster owner](../../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), you can configure Rancher to send you alerts for cluster events.

->**Prerequisite:** Before you can receive cluster alerts, you must [add a notifier](../explanations/integrations-in-rancher/notifiers.md).
+>**Prerequisite:** Before you can receive cluster alerts, you must [add a notifier](../notifiers.md).

 1. From the **Global** view, navigate to the cluster that you want to configure cluster alerts for. Select **Tools > Alerts**. Then click **Add Alert Group**.
 1. Enter a **Name** for the alert that describes its purpose, you could group alert rules for the different purpose.
 1. Based on the type of alert you want to create, refer to the [cluster alert configuration section.](#cluster-alert-configuration)
 1. Continue adding more **Alert Rule** to the group.
-1. Finally, choose the [notifiers](../explanations/integrations-in-rancher/notifiers.md) to send the alerts to.
+1. Finally, choose the [notifiers](../notifiers.md) to send the alerts to.

    - You can set up multiple notifiers.
    - You can change notifier recipients on the fly.
@@ -285,10 +285,10 @@ Input or select an **Expression**, the dropdown shows the original metrics from

 - [**Node**](https://github.com/prometheus/node_exporter)
 - [**Container**](https://github.com/google/cadvisor)
- [**ETCD**](https://etcd.io/docs/v3.4.0/op-guide/monitoring/)
+- [**ETCD**](https://etcd.io/docs/v3.3/op-guide/monitoring/)
 - [**Kubernetes Components**](https://github.com/kubernetes/metrics)
 - [**Kubernetes Resources**](https://github.com/kubernetes/kube-state-metrics)
- [**Fluentd**](https://docs.fluentd.org/v1.0/articles/monitoring-prometheus) (supported by [Logging](./cluster-logging.md))
+- [**Fluentd**](https://docs.fluentd.org/v1.0/articles/monitoring-prometheus) (supported by [Logging](../cluster-logging/cluster-logging.md))
 - [**Cluster Level Grafana**](https://grafana.com/docs/grafana/latest/setup-grafana/set-up-grafana-monitoring/)
 - **Cluster Level Prometheus**

@@ -48,8 +48,8 @@ Logging Driver: json-file

 You can configure logging at either cluster level or project level.

- Cluster logging writes logs for every pod in the cluster, i.e. in all the projects. For [RKE clusters](launch-kubernetes-with-rancher.md), it also writes logs for all the Kubernetes system components.
- [Project logging](../reference-guides/rancher-project-tools/project-logging.md) writes logs for every pod in that particular project.
+- Cluster logging writes logs for every pod in the cluster, i.e. in all the projects. For [RKE clusters](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md), it also writes logs for all the Kubernetes system components.
+- [Project logging](../../../reference-guides/rancher-project-tools/project-logging.md) writes logs for every pod in that particular project.

 Logs that are sent to your logging service are from the following locations:

@@ -58,7 +58,7 @@ Logs that are sent to your logging service are from the following locations:

 ## Enabling Cluster Logging

-As an [administrator](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md) or [cluster owner](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), you can configure Rancher to send Kubernetes logs to a logging service.
+As an [administrator](../../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md) or [cluster owner](../../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), you can configure Rancher to send Kubernetes logs to a logging service.

 1. From the **Global** view, navigate to the cluster that you want to configure cluster logging.

@@ -66,11 +66,11 @@ As an [administrator](../how-to-guides/advanced-user-guides/authentication-permi

 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](../explanations/integrations-in-rancher/cluster-logging/elasticsearch.md)
-   - [Splunk](../explanations/integrations-in-rancher/cluster-logging/splunk.md)
-   - [Kafka](../explanations/integrations-in-rancher/cluster-logging/kafka.md)
-   - [Syslog](../explanations/integrations-in-rancher/cluster-logging/syslog.md)
-   - [Fluentd](../explanations/integrations-in-rancher/cluster-logging/fluentd.md)
+   - [Elasticsearch](elasticsearch.md)
+   - [Splunk](splunk.md)
+   - [Kafka](kafka.md)
+   - [Syslog](syslog.md)
+   - [Fluentd](fluentd.md)

 1. (Optional) Instead of using the UI to configure the logging services, you can enter custom advanced configurations by clicking on **Edit as File**, which is located above the logging targets. This link is only visible after you select a logging service.

@@ -38,7 +38,7 @@ Some of the biggest metrics to look out for:

 ### Etcd Metrics

->**Note:** Only supported for [Rancher launched Kubernetes clusters](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md).
+>**Note:** Only supported for [Rancher launched Kubernetes clusters](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).

 Etcd metrics display the operations of the etcd database on each of your cluster nodes. After establishing a baseline of normal etcd operational metrics, observe them for abnormal deltas between metric refreshes, which indicate potential issues with etcd. Always address etcd issues immediately!

@@ -60,7 +60,7 @@ Some of the biggest metrics to look out for:

 Kubernetes components metrics display data about the cluster's individual Kubernetes components. Primarily, it displays information about connections and latency for each component: the API server, controller manager, scheduler, and ingress controller.

->**Note:** The metrics for the controller manager, scheduler and ingress controller are only supported for [Rancher launched Kubernetes clusters](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md).
+>**Note:** The metrics for the controller manager, scheduler and ingress controller are only supported for [Rancher launched Kubernetes clusters](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).

 When analyzing Kubernetes component metrics, don't be concerned about any single standalone metric in the charts and graphs that display. Rather, you should establish a baseline for metrics considered normal following a period of observation, e.g. the range of values that your components usually operate within and are considered normal. After you establish this baseline, be on the lookout for large deltas in the charts and graphs, as these big changes usually indicate a problem that you need to investigate.

@@ -90,7 +90,7 @@ Some of the more important component metrics to monitor are:

 ## Rancher Logging Metrics

-Although the Dashboard for a cluster primarily displays data sourced from Prometheus, it also displays information for cluster logging, provided that you have [configured Rancher to use a logging service](../../../pages-for-subheaders/cluster-logging.md).
+Although the Dashboard for a cluster primarily displays data sourced from Prometheus, it also displays information for cluster logging, provided that you have [configured Rancher to use a logging service](../cluster-logging/cluster-logging.md).

 [_Get expressions for Rancher Logging Metrics_](./expression.md#rancher-logging-metrics)

@@ -15,7 +15,7 @@ Using Rancher, you can monitor the state and processes of your cluster nodes, Ku

 Prometheus provides a _time series_ of your data, which is, according to [Prometheus documentation](https://prometheus.io/docs/concepts/data_model/):

-You can configure these services to collect logs at either the cluster level or the project level. This page describes how to enable monitoring for a cluster. For details on enabling monitoring for a project, refer to the [project administration section](../explanations/integrations-in-rancher/cluster-monitoring/project-monitoring.md).
+You can configure these services to collect logs at either the cluster level or the project level. This page describes how to enable monitoring for a cluster. For details on enabling monitoring for a project, refer to the [project administration section](project-monitoring.md).

 >A stream of timestamped values belonging to the same metric and the same set of labeled dimensions, along with comprehensive statistics and metrics of the monitored cluster.

@@ -27,7 +27,7 @@ Multi-tenancy support in terms of cluster-only and project-only Prometheus insta

 ## Monitoring Scope

-Using Prometheus, you can monitor Rancher at both the cluster level and [project level](../explanations/integrations-in-rancher/cluster-monitoring/project-monitoring.md). For each cluster and project that is enabled for monitoring, Rancher deploys a Prometheus server.
+Using Prometheus, you can monitor Rancher at both the cluster level and [project level](project-monitoring.md). For each cluster and project that is enabled for monitoring, Rancher deploys a Prometheus server.

 - Cluster monitoring allows you to view the health of your Kubernetes cluster. Prometheus collects metrics from the cluster components below, which you can view in graphs and charts.

@@ -35,11 +35,11 @@ Using Prometheus, you can monitor Rancher at both the cluster level and [project
    - etcd database
    - All nodes (including workers)

- [Project monitoring](../explanations/integrations-in-rancher/cluster-monitoring/project-monitoring.md) allows you to view the state of pods running in a given project. Prometheus collects metrics from the project's deployed HTTP and TCP/UDP workloads.
+- [Project monitoring](project-monitoring.md) allows you to view the state of pods running in a given project. Prometheus collects metrics from the project's deployed HTTP and TCP/UDP workloads.

 ## Enabling Cluster Monitoring

-As an [administrator](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md) or [cluster owner](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), you can configure Rancher to deploy Prometheus to monitor your Kubernetes cluster.
+As an [administrator](../../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md) or [cluster owner](../../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), you can configure Rancher to deploy Prometheus to monitor your Kubernetes cluster.

 > **Prerequisites:** The following TCP ports need to be opened for metrics scraping:
 >
@@ -52,17 +52,17 @@ As an [administrator](../how-to-guides/advanced-user-guides/authentication-permi
 > | 10252 | Controlplane | Kube controller manager |
 > | 2379 | Etcd | Etcd server |

-> Monitoring V1 requires a Kubernetes verison less than or equal to v1.20.x. To install monitoring on Kubernetes v1.21+, you will need to [migrate to Monitoring V2.](../../version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5%2B-monitoring.md)
+> Monitoring V1 requires a Kubernetes verison less than or equal to v1.20.x. To install monitoring on Kubernetes v1.21+, you will need to [migrate to Monitoring V2.](/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5%2B-monitoring.md)

 1. From the **Global** view, navigate to the cluster that you want to configure cluster monitoring.

 1. Select **Tools > Monitoring** in the navigation bar.

-1. Select **Enable** to show the [Prometheus configuration options](../explanations/integrations-in-rancher/cluster-monitoring/prometheus.md). Review the [resource consumption recommendations](#resource-consumption) to ensure you have enough resources for Prometheus and on your worker nodes to enable monitoring. Enter in your desired configuration options.
+1. Select **Enable** to show the [Prometheus configuration options](prometheus.md). Review the [resource consumption recommendations](#resource-consumption) to ensure you have enough resources for Prometheus and on your worker nodes to enable monitoring. Enter in your desired configuration options.

 1. Click **Save**.

-**Result:** The Prometheus server will be deployed as well as two monitoring applications. The two monitoring applications, `cluster-monitoring` and `monitoring-operator`, are added as an [application](./helm-charts-in-rancher.md) to the cluster's `system` project. After the applications are `active`, you can start viewing [cluster metrics](../explanations/integrations-in-rancher/cluster-monitoring/cluster-metrics.md) through the Rancher dashboard or directly from Grafana.
+**Result:** The Prometheus server will be deployed as well as two monitoring applications. The two monitoring applications, `cluster-monitoring` and `monitoring-operator`, are added as an [application](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md) to the cluster's `system` project. After the applications are `active`, you can start viewing [cluster metrics](cluster-metrics.md) through the Rancher dashboard or directly from Grafana.

 > The default username and password for the Grafana instance will be `admin/admin`. However, Grafana dashboards are served via the Rancher authentication proxy, so only users who are currently authenticated into the Rancher server have access to the Grafana dashboard.

@@ -2,7 +2,7 @@
 title: Prometheus Custom Metrics Adapter
 ---

-After you've enabled [cluster level monitoring](../../../pages-for-subheaders/cluster-monitoring.md), You can view the metrics data from Rancher. You can also deploy the Prometheus custom metrics adapter then you can use the HPA with metrics stored in cluster monitoring.
+After you've enabled [cluster level monitoring](cluster-monitoring.md), You can view the metrics data from Rancher. You can also deploy the Prometheus custom metrics adapter then you can use the HPA with metrics stored in cluster monitoring.

 ## Deploy Prometheus Custom Metrics Adapter

@@ -2,9 +2,9 @@
 title: Prometheus Expressions
 ---

-The PromQL expressions in this doc can be used to configure [alerts.](../../../pages-for-subheaders/cluster-alerts.md)
+The PromQL expressions in this doc can be used to configure [alerts.](../cluster-alerts/cluster-alerts.md)

-> Before expressions can be used in alerts, monitoring must be enabled. For more information, refer to the documentation on enabling monitoring [at the cluster level](../../../pages-for-subheaders/cluster-monitoring.md) or [at the project level.](./project-monitoring.md)
+> Before expressions can be used in alerts, monitoring must be enabled. For more information, refer to the documentation on enabling monitoring [at the cluster level](cluster-monitoring.md) or [at the project level.](./project-monitoring.md)

 For more information about querying Prometheus, refer to the official [Prometheus documentation.](https://prometheus.io/docs/prometheus/latest/querying/basics/)

@@ -9,9 +9,9 @@ Using Rancher, you can monitor the state and processes of your cluster nodes, Ku

 ### Monitoring Scope

-Using Prometheus, you can monitor Rancher at both the [cluster level](../../../pages-for-subheaders/cluster-monitoring.md) and project level. For each cluster and project that is enabled for monitoring, Rancher deploys a Prometheus server.
+Using Prometheus, you can monitor Rancher at both the [cluster level](cluster-monitoring.md) and project level. For each cluster and project that is enabled for monitoring, Rancher deploys a Prometheus server.

- [Cluster monitoring](../../../pages-for-subheaders/cluster-monitoring.md/) allows you to view the health of your Kubernetes cluster. Prometheus collects metrics from the cluster components below, which you can view in graphs and charts.
+- [Cluster monitoring](cluster-monitoring.md/) allows you to view the health of your Kubernetes cluster. Prometheus collects metrics from the cluster components below, which you can view in graphs and charts.

    - Kubernetes control plane
    - etcd database
@@ -25,7 +25,7 @@ Only [administrators](../../../how-to-guides/advanced-user-guides/authentication

 ### Enabling Project Monitoring

-> **Prerequisite:** Cluster monitoring must be [enabled.](../../../pages-for-subheaders/cluster-monitoring.md)
+> **Prerequisite:** Cluster monitoring must be [enabled.](cluster-monitoring.md)

 1. Go to the project where monitoring should be enabled. Note: When cluster monitoring is enabled, monitoring is also enabled by default in the **System** project.

@@ -43,12 +43,12 @@ Prometheus|750m| 750Mi | 1000m | 1000Mi | Yes
 Grafana | 100m | 100Mi | 200m | 200Mi | No


-**Result:** A single application,`project-monitoring`, is added as an [application](../../../pages-for-subheaders/helm-charts-in-rancher.md) to the project. After the application is `active`, you can start viewing project metrics through the [Rancher dashboard](../../../pages-for-subheaders/cluster-monitoring.md/) or directly from Grafana.
+**Result:** A single application,`project-monitoring`, is added as an [application](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md) to the project. After the application is `active`, you can start viewing project metrics through the [Rancher dashboard](cluster-monitoring.md/) or directly from Grafana.

 > The default username and password for the Grafana instance will be `admin/admin`. However, Grafana dashboards are served via the Rancher authentication proxy, so only users who are currently authenticated into the Rancher server have access to the Grafana dashboard.

 ### Project Metrics
-[Workload metrics](./expression.md#workload-metrics) are available for the project if monitoring is enabled at the [cluster level](../../../pages-for-subheaders/cluster-monitoring.md/) and at the [project level.](#enabling-project-monitoring)
+[Workload metrics](./expression.md#workload-metrics) are available for the project if monitoring is enabled at the [cluster level](cluster-monitoring.md/) and at the [project level.](#enabling-project-monitoring)

 You can monitor custom metrics from any [exporters.](https://prometheus.io/docs/instrumenting/exporters/) You can also expose some custom endpoints on deployments without needing to configure Prometheus for your project.

@@ -0,0 +1,105 @@
+---
+title: Prometheus Configuration
+---
+
+_Available as of v2.2.0_
+
+While configuring monitoring at either the [cluster level](cluster-monitoring.md) or [project level](./project-monitoring.md), there are multiple options that can be configured.
+
+- [Basic Configuration](#basic-configuration)
+- [Advanced Options](#advanced-options)
+- [Node Exporter](#node-exporter)
+- [Persistent Storage](#persistent-storage)
+- [Remote Storage](#remote-storage)
+
+## Basic Configuration
+
+Option | Description
+-------|-------------
+Data Retention | How long your Prometheus instance retains monitoring data scraped from Rancher objects before it's purged.
+[Enable Node Exporter](#node-exporter) | Whether or not to deploy the node exporter.
+Node Exporter Host Port | The host port on which data is exposed, i.e. data that Prometheus collects from your node hardware. Required if you have enabled the node exporter.
+[Enable Persistent Storage](#persistent-storage) for Prometheus | Whether or not to configure storage for Prometheus so that metrics can be retained even if the Prometheus pod fails.
+[Enable Persistent Storage](#persistent-storage) for Grafana | Whether or not to configure storage for Grafana so that the Grafana dashboards and configuration  can be retained even if the Grafana pod fails.
+Prometheus [CPU Limit](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu) |  CPU resource limit for the Prometheus pod.
+Prometheus [CPU Reservation](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu) | CPU reservation for the Prometheus pod.
+Prometheus [Memory Limit](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-memory) | Memory resource limit for the Prometheus pod.
+Prometheus [Memory Reservation](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-memory) | Memory resource requests for the Prometheus pod.
+Selector | Ability to select the nodes in which Prometheus and Grafana pods are deployed to. To use this option, the nodes must have labels.
+
+## Advanced Options
+
+Since monitoring is an [application](https://github.com/rancher/system-charts/tree/dev/charts/rancher-monitoring) from the [Rancher catalog](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), it can be configured like any other catalog application, by passing in values to Helm.
+
+> **Warning:** Any modification to the application without understanding the entire application can lead to catastrophic errors.
+
+### Prometheus RemoteRead and RemoteWrite
+
+_Available as of v2.4.0_
+
+Prometheus RemoteRead and RemoteWrite can be configured as custom answers in the **Advanced Options** section.
+
+For more information on remote endpoints and storage, refer to the [Prometheus documentation.](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage)
+
+The Prometheus operator documentation contains the full [RemoteReadSpec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#remotereadspec) and [RemoteWriteSpec.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#remotewritespec)
+
+An example configuration would be:
+
+| Variable | Value |
+|--------------|------------|
+|  `prometheus.remoteWrite[0].url` | `http://mytarget.com` |
+
+### LivenessProbe and ReadinessProbe
+
+_Available as of v2.4.0_
+
+Prometheus LivenessProbe and ReadinessProbe can be configured as custom answers in the **Advanced Options** section.
+
+The Kubernetes probe spec is [here.](https://v1-17.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/#probe-v1-core)
+
+Some example key-value pairs are:
+
+| Variable | Value |
+|--------------|------------|
+| `prometheus.livenessProbe.timeoutSeconds` | 60 |
+| `prometheus.readinessProbe.timeoutSeconds` | 60 |
+
+## Node Exporter
+
+The [node exporter](https://github.com/prometheus/node_exporter/blob/master/README.md) is a popular open source exporter, which exposes the metrics for hardware and \*NIX kernels OS. It is designed to monitor the host system. However, there are still issues with namespaces when running it in a container, mostly around filesystem mount spaces. In order to monitor actual network metrics for the container network, the node exporter must be deployed with the `hostNetwork` mode.
+
+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 <b>Node Exporter Host Port</b> 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 StorageClasses to use as [persistent storage](../../../how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) for your Prometheus or Grafana pod.
+
+By default, when you enable Prometheus for either a cluster or project, all monitoring data that Prometheus collects is stored on its own pod. With local storage, if the Prometheus or Grafana pods fail, all the data is lost. Rancher recommends configuring an external persistent storage to the cluster. With the external persistent storage, if the Prometheus or Grafana pods fail, the new pods can recover using data from the persistent storage.
+
+When enabling persistent storage for Prometheus or Grafana, specify the size of the persistent volume and select the StorageClass.
+
+## Remote Storage
+
+>**Prerequisite:** Need a remote storage endpoint to be available. The possible list of integrations is available [here](https://prometheus.io/docs/operating/integrations/)
+
+Using advanced options, remote storage integration for the Prometheus installation can be configured as follows:
+
+```
+prometheus.remoteWrite[0].url = http://remote1/push
+prometheus.remoteWrite[0].remoteTimeout = 33s
+
+prometheus.remoteWrite[1].url = http://remote2/push
+
+
+prometheus.remoteRead[0].url = http://remote1/read
+prometheus.remoteRead[0].proxyUrl = http://proxy.url
+prometheus.remoteRead[0].bearerToken = token-value
+
+prometheus.remoteRead[1].url = http://remote2/read
+prometheus.remoteRead[1].remoteTimeout = 33s
+prometheus.remoteRead[1].readRecent = true
+```
+
+Additional fields can be set up based on the [ReadSpec](https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#remotereadspec) and [RemoteWriteSpec](https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#remotewritespec)
@@ -4,11 +4,11 @@ title: Viewing Metrics

 _Available as of v2.2.0_

-After you've enabled monitoring at either the [cluster level](../../../pages-for-subheaders/cluster-monitoring.md) or [project level](./project-monitoring.md), you will want to be start viewing the data being collected. There are multiple ways to view this data.
+After you've enabled monitoring at either the [cluster level](cluster-monitoring.md) or [project level](./project-monitoring.md), you will want to be start viewing the data being collected. There are multiple ways to view this data.

 ## Rancher Dashboard

->**Note:** This is only available if you've enabled monitoring at the [cluster level](../../../pages-for-subheaders/cluster-monitoring.md). Project specific analytics must be viewed using the project's Grafana instance.
+>**Note:** This is only available if you've enabled monitoring at the [cluster level](cluster-monitoring.md). Project specific analytics must be viewed using the project's Grafana instance.

 Rancher's dashboards are available at multiple locations:

@@ -32,7 +32,7 @@ When analyzing these metrics, don't be concerned about any single standalone met

 ## Grafana

-If you've enabled monitoring at either the [cluster level](../../../pages-for-subheaders/cluster-monitoring.md) or [project level](./project-monitoring.md), Rancher automatically creates a link to Grafana instance. Use this link to view monitoring data.
+If you've enabled monitoring at either the [cluster level](cluster-monitoring.md) or [project level](./project-monitoring.md), Rancher automatically creates a link to Grafana instance. Use this link to view monitoring data.

 Grafana allows you to query, visualize, alert, and ultimately, understand your cluster and workload data. For more information on Grafana and its capabilities, visit the [Grafana website](https://grafana.com/grafana).

@@ -0,0 +1,11 @@
+---
+title: Integrations in Rancher
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/cloud-marketplace"/>
+</head>
+
+Over time, Rancher has accrued several products and projects that have been integrated into the Rancher UI.
+
+Examples of some of these integrations are [Istio](istio/istio.md) and [CIS Scans](cis-scans/cis-scans.md).
@@ -0,0 +1,90 @@
+---
+title: Istio
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/istio"/>
+</head>
+
+_Available as of v2.3.0_
+
+[Istio](https://istio.io/) is an open-source tool that makes it easier for DevOps teams to observe, control, troubleshoot, and secure the traffic within a complex network of microservices.
+
+As a network of microservices changes and grows, the interactions between them can become more difficult to manage and understand. In such a situation, it is useful to have a service mesh as a separate infrastructure layer. Istio's service mesh lets you manipulate traffic between microservices without changing the microservices directly.
+
+Our integration of Istio is designed so that a Rancher operator, such as an administrator or cluster owner, can deliver Istio to developers. Then developers can use Istio to enforce security policies, troubleshoot problems, or manage traffic for green/blue deployments, canary deployments, or A/B testing.
+
+This service mesh provides features that include but are not limited to the following:
+
+- Traffic management features
+- Enhanced monitoring and tracing
+- Service discovery and routing
+- Secure connections and service-to-service authentication with mutual TLS
+- Load balancing
+- Automatic retries, backoff, and circuit breaking
+
+After Istio is enabled in a cluster, you can leverage Istio's control plane functionality with `kubectl`.
+
+Rancher's Istio integration comes with comprehensive visualization aids:
+
+- **Trace the root cause of errors with Jaeger.** [Jaeger](https://www.jaegertracing.io/) is an open-source tool that provides a UI for a distributed tracing system, which is useful for root cause analysis and for determining what causes poor performance. Distributed tracing allows you to view an entire chain of calls, which might originate with a user request and traverse dozens of microservices.
+- **Get the full picture of your microservice architecture with Kiali.** [Kiali](https://www.kiali.io/) provides a diagram that shows the services within a service mesh and how they are connected, including the traffic rates and latencies between them. You can check the health of the service mesh, or drill down to see the incoming and outgoing requests to a single component.
+- **Gain insights from time series analytics with Grafana dashboards.** [Grafana](https://grafana.com/) is an analytics platform that allows you to query, visualize, alert on and understand the data gathered by Prometheus.
+- **Write custom queries for time series data with the Prometheus UI.** [Prometheus](https://prometheus.io/) is a systems monitoring and alerting toolkit. Prometheus scrapes data from your cluster, which is then used by Grafana. A Prometheus UI is also integrated into Rancher, and lets you write custom queries for time series data and see the results in the UI.
+
+
+Istio needs to be set up by a Rancher administrator or cluster administrator before it can be used in a project.
+
+## Prerequisites
+
+Before enabling Istio, we recommend that you confirm that your Rancher worker nodes have enough [CPU and memory](cpu-and-memory-allocations.md) to run all of the components of Istio.
+
+## Setup Guide
+
+Refer to the [setup guide](../../../how-to-guides/advanced-user-guides/istio-setup-guide/istio-setup-guide.md) for instructions on how to set up Istio and use it in a project.
+
+## Disabling Istio
+
+To remove Istio components from a cluster, namespace, or workload, refer to the section on [disabling Istio.](disable-istio.md)
+
+## Accessing Visualizations
+
+> By default, only cluster owners have access to Jaeger and Kiali. For instructions on how to allow project members to access them, see [this section.](rbac-for-istio.md)
+
+After Istio is set up in a cluster, Grafana, Prometheus, Jaeger, and Kiali are available in the Rancher UI.
+
+Your access to the visualizations depend on your role. Grafana and Prometheus are only available for cluster owners. The Kiali and Jaeger UIs are available only to cluster owners by default, but cluster owners can allow project members to access them by editing the Istio settings. When you go to your project and click **Resources > Istio,** you can go to each UI for Kiali, Jaeger, Grafana, and Prometheus by clicking their icons in the top right corner of the page.
+
+To see the visualizations, go to the cluster where Istio is set up and click **Tools > Istio.** You should see links to each UI at the top of the page.
+
+You can also get to the visualization tools from the project view.
+
+## Viewing the Kiali Traffic Graph
+
+1. From the project view in Rancher, click **Resources > Istio.**
+1. If you are a cluster owner, you can go to the **Traffic Graph** tab. This tab has the Kiali network visualization integrated into the UI.
+
+## Viewing Traffic Metrics
+
+Istio’s monitoring features provide visibility into the performance of all your services.
+
+1. From the project view in Rancher, click **Resources > Istio.**
+1. Go to the **Traffic Metrics** tab. After traffic is generated in your cluster, you should be able to see metrics for **Success Rate, Request Volume, 4xx Response Count, Project 5xx Response Count** and **Request Duration.** Cluster owners can see all of the metrics, while project members can see a subset of the metrics.
+
+## Architecture
+
+Istio installs a service mesh that uses [Envoy](https://www.envoyproxy.io) sidecar proxies to intercept traffic to each workload. These sidecars intercept and manage service-to-service communication, allowing fine-grained observation and control over traffic within the cluster.
+
+Only workloads that have the Istio sidecar injected can be tracked and controlled by Istio.
+
+Enabling Istio in Rancher enables monitoring in the cluster, and enables Istio in all new namespaces that are created in a cluster. You need to manually enable Istio in preexisting namespaces.
+
+When a namespace has Istio enabled, new workloads deployed in the namespace will automatically have the Istio sidecar. You need to manually enable Istio in preexisting workloads.
+
+For more information on the Istio sidecar, refer to the [Istio docs](https://istio.io/docs/setup/kubernetes/additional-setup/sidecar-injection/).
+
+### Two Ingresses
+
+By default, each Rancher-provisioned cluster has one NGINX ingress controller allowing traffic into the cluster. To allow Istio to receive external traffic, you need to enable the Istio ingress gateway for the cluster. The result is that your cluster will have two ingresses.
+
+![In an Istio-enabled cluster, you can have two ingresses: the default Nginx ingress, and the default Istio controller.](/img/istio-ingress.svg)
@@ -189,5 +189,5 @@ After you set up notifiers, you can manage them. From the **Global** view, open

 After creating a notifier, set up alerts to receive notifications of Rancher system events.

- [Cluster owners](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles) can set up alerts at the [cluster level](../../pages-for-subheaders/cluster-alerts.md).
+- [Cluster owners](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles) can set up alerts at the [cluster level](cluster-alerts/cluster-alerts.md).
 - [Project owners](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) can set up alerts at the [project level](../../reference-guides/rancher-project-tools/project-alerts.md).
@@ -0,0 +1,99 @@
+---
+title: OPA Gatekeeper
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/opa-gatekeeper"/>
+</head>
+
+_Available as of v2.4.0_
+
+To ensure consistency and compliance, every organization needs the ability to define and enforce policies in its environment in an automated way. [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) is a policy engine that facilitates policy-based control for cloud native environments. Rancher provides the ability to enable OPA Gatekeeper in Kubernetes clusters, and also installs a couple of built-in policy definitions, which are also called constraint templates.
+
+OPA provides a high-level declarative language that lets you specify policy as code and ability to extend simple APIs to offload policy decision-making.
+
+[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is a project that provides integration between OPA and Kubernetes. OPA Gatekeeper provides:
+
+- An extensible, parameterized policy library.
+- Native Kubernetes CRDs for instantiating the policy library, also called “constraints."
+- Native Kubernetes CRDs for extending the policy library, also called "constraint templates."
+- Audit functionality.
+
+To read more about OPA, please refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/)
+
+## How the OPA Gatekeeper Integration Works
+
+Kubernetes provides the ability to extend API server functionality via admission controller webhooks, which are invoked whenever a resource is created, updated or deleted. Gatekeeper is installed as a validating webhook and enforces policies defined by Kubernetes custom resource definitions. In addition to the admission control usage, Gatekeeper provides the capability to audit existing resources in Kubernetes clusters and mark current violations of enabled policies.
+
+OPA Gatekeeper is made available via Rancher's Helm system chart, and it is installed in a namespace named `gatekeeper-system.`
+
+## Enabling OPA Gatekeeper in a Cluster
+
+> **Prerequisites:**
+>
+> - Only administrators and cluster owners can enable OPA Gatekeeper.
+> - The dashboard needs to be enabled using the `dashboard` feature flag. For more information, refer to the [section on enabling experimental features.](../../getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/enable-experimental-features.md)
+
+1. Navigate to the cluster's **Dashboard** view.
+1. On the left side menu, expand the cluster menu and click on **OPA Gatekeeper.**
+1. To install Gatekeeper with the default configuration, click on **Enable Gatekeeper (v0.1.0) with defaults.**
+1. To change any default configuration, click on **Customize Gatekeeper yaml configuration.**
+
+## Constraint Templates
+
+[Constraint templates](https://github.com/open-policy-agent/gatekeeper#constraint-templates) are Kubernetes custom resources that define the schema and Rego logic of the OPA policy to be applied by Gatekeeper. For more information on the Rego policy language, refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/policy-language/)
+
+When OPA Gatekeeper is enabled, Rancher installs some templates by default.
+
+To list the constraint templates installed in the cluster, go to the left side menu under OPA Gatekeeper and click on **Templates.**
+
+Rancher also provides the ability to create your own constraint templates by importing YAML definitions.
+
+## Creating and Configuring Constraints
+
+[Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together.
+
+> **Prerequisites:** OPA Gatekeeper must be enabled in the cluster.
+
+To list the constraints installed, go to the left side menu under OPA Gatekeeper, and click on **Constraints.**
+
+New constraints can be created from a constraint template.
+
+Rancher provides the ability to create a constraint by using a convenient form that lets you input the various constraint fields.
+
+The **Edit as yaml** option is also available to configure the the constraint's yaml definition.
+
+### Exempting Rancher's System Namespaces from Constraints
+
+When a constraint is created, ensure that it does not apply to any Rancher or Kubernetes system namespaces. If the system namespaces are not excluded, then it is possible to see many resources under them marked as violations of the constraint.
+
+To limit the scope of the constraint only to user namespaces, always specify these namespaces under the **Match** field of the constraint.
+
+Also, the constraint may interfere with other Rancher functionality and deny system workloads from being deployed. To avoid this, exclude all Rancher-specific namespaces from your constraints.
+
+## Enforcing Constraints in your Cluster
+
+When the **Enforcement Action** is **Deny,** the constraint is immediately enabled and will deny any requests that violate the policy defined. By default, the enforcement value is **Deny.**
+
+When the **Enforcement Action** is **Dryrun,** then any resources that violate the policy are only recorded under the constraint's status field.
+
+To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny.**
+
+## Audit and Violations in your Cluster
+
+OPA Gatekeeper runs a periodic audit to check if any existing resource violates any enforced constraint. The audit-interval (default 300s) can be configured while installing Gatekeeper.
+
+On the Gatekeeper page, any violations of the defined constraints are listed.
+
+Also under **Constraints,** the number of violations of the constraint can be found.
+
+The detail view of each constraint lists information about the resource that violated the constraint.
+
+## Disabling Gatekeeper
+
+1. Navigate to the cluster's Dashboard view
+1. On the left side menu, expand the cluster menu and click on **OPA Gatekeeper.**
+1. Click the **&#8942; > Disable**.
+
+**Result:** Upon disabling OPA Gatekeeper, all constraint templates and constraints will also be deleted.
+
@@ -26,13 +26,13 @@ Yes.

 **Does Rancher support Windows?**

-As of Rancher 2.3.0, we support Windows Server 1809 containers. For details on how to set up a cluster with Windows worker nodes, refer to the section on [configuring custom clusters for Windows.](pages-for-subheaders/use-windows-clusters.md)
+As of Rancher 2.3.0, we support Windows Server 1809 containers. For details on how to set up a cluster with Windows worker nodes, refer to the section on [configuring custom clusters for Windows.](how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/use-windows-clusters.md)

 <br/>

 **Does Rancher support Istio?**

-As of Rancher 2.3.0, we support [Istio.](pages-for-subheaders/istio.md)
+As of Rancher 2.3.0, we support [Istio.](explanations/integrations-in-rancher/istio/istio.md)

 Furthermore, Istio is implemented in our micro-PaaS "Rio", which works on Rancher 2.x along with any CNCF compliant Kubernetes cluster. You can read more about it [here](https://rio.io/)

@@ -0,0 +1,149 @@
+---
+title: Container Network Interface (CNI) Providers
+description: Learn about Container Network Interface (CNI), the CNI providers Rancher provides, the features they offer, and how to choose a provider for you
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/container-network-interface-providers"/>
+</head>
+
+## What is CNI?
+
+CNI (Container Network Interface), a [Cloud Native Computing Foundation project](https://cncf.io/), consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of  plugins. CNI concerns itself only with network connectivity of containers and removing allocated resources when the container is deleted.
+
+Kubernetes uses CNI as an interface between network providers and Kubernetes pod networking.
+
+![CNI Logo](/img/cni-logo.png)
+
+For more information visit [CNI GitHub project](https://github.com/containernetworking/cni).
+
+### What Network Models are Used in CNI?
+
+CNI network providers implement their network fabric using either an encapsulated network model such as Virtual Extensible Lan ([VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)) or an unencapsulated network model such as Border Gateway Protocol ([BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)).
+
+#### What is an Encapsulated Network?
+
+This network model provides a logical Layer 2 (L2) network encapsulated over the existing Layer 3 (L3) network topology that spans the Kubernetes cluster nodes. With this model you have an isolated L2 network for containers without needing routing distribution, all at the cost of minimal overhead in terms of processing and increased IP package size, which comes from an IP header generated by overlay encapsulation. Encapsulation information is distributed by UDP ports between Kubernetes workers, interchanging network control plane information about how MAC addresses can be reached. Common encapsulation used in this kind of network model is VXLAN, Internet Protocol Security (IPSec), and IP-in-IP.
+
+In simple terms, this network model generates a kind of network bridge extended between Kubernetes workers, where pods are connected.
+
+This network model is used when an extended L2 bridge is preferred. This network model is sensitive to L3 network latencies of the Kubernetes workers. If datacenters are in distinct geolocations, be sure to have low latencies between them to avoid eventual network segmentation.
+
+CNI network providers using this network model include Flannel, Canal, and Weave.
+
+![Encapsulated Network](/img/encapsulated-network.png)
+
+#### What is an Unencapsulated Network?
+
+This network model provides an L3 network to route packets between containers. This model doesn't generate an isolated l2 network, nor generates overhead. These benefits come at the cost of Kubernetes workers having to manage any route distribution that's needed. Instead of using IP headers for encapsulation, this network model uses a network protocol between Kubernetes workers to distribute routing information to reach pods, such as [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol).
+
+In simple terms, this network model generates a kind of network router extended between Kubernetes workers, which provides information about how to reach pods.
+
+This network model is used when a routed L3 network is preferred. This mode dynamically updates routes at the OS level for Kubernetes workers. It's less sensitive to latency.
+
+CNI network providers using this network model include Calico and Romana.
+
+![Unencapsulated Network](/img/unencapsulated-network.png)
+
+### What CNI Providers are Provided by Rancher?
+
+Out-of-the-box, Rancher provides the following CNI network providers for Kubernetes clusters: Canal, Flannel, Calico and Weave (Weave is available as of v2.2.0). You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
+
+#### Canal
+
+![Canal Logo](/img/canal-logo.png)
+
+Canal is a CNI network provider that gives you the best of Flannel and Calico. It allows users to easily deploy Calico and Flannel networking together as a unified networking solution, combining Calico’s network policy enforcement with the rich superset of Calico (unencapsulated) and/or Flannel (encapsulated) network connectivity options.
+
+In Rancher, Canal is the default CNI network provider combined with Flannel and VXLAN encapsulation.
+
+Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (healthcheck). For details, refer to [the port requirements for user clusters.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)
+
+![](/img/canal-diagram.png)
+
+For more information, see the [Canal GitHub Page.](https://github.com/projectcalico/canal)
+
+#### Flannel
+
+![Flannel Logo](/img/flannel-logo.png)
+
+Flannel is a simple and easy way to configure L3 network fabric designed for Kubernetes. Flannel runs a single binary agent named flanneld on each host, which is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host's public IP). Packets are forwarded using one of several backend mechanisms, with the default encapsulation being [VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan).
+
+Encapsulated traffic is unencrypted by default. Therefore, flannel provides an experimental backend for encryption, [IPSec](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#ipsec), which makes use of [strongSwan](https://www.strongswan.org/) to establish encrypted IPSec tunnels between Kubernetes workers.
+
+Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (healthcheck). See [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
+
+![Flannel Diagram](/img/flannel-diagram.png)
+
+For more information, see the [Flannel GitHub Page](https://github.com/coreos/flannel).
+
+#### Calico
+
+![Calico Logo](/img/calico-logo.png)
+
+Calico enables networking and network policy in Kubernetes clusters across the cloud. Calico uses a pure, unencapsulated IP network fabric and policy engine to provide networking for your Kubernetes workloads. Workloads are able to communicate over both cloud infrastructure and on-prem using BGP.
+
+Calico also provides a stateless IP-in-IP encapsulation mode that can be used, if necessary. Calico also offers policy isolation, allowing you to secure and govern your Kubernetes workloads using advanced ingress and egress policies.
+
+Kubernetes workers should open TCP port `179` (BGP). See [the port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
+
+![Calico Diagram](/img/calico-diagram.svg)
+
+For more information, see the following pages:
+
+- [Project Calico Official Site](https://www.projectcalico.org/)
+- [Project Calico GitHub Page](https://github.com/projectcalico/calico)
+
+
+#### Weave
+
+![Weave Logo](/img/weave-logo.png)
+
+_Available as of v2.2.0_
+
+Weave enables networking and network policy in Kubernetes clusters across the cloud. Additionally, it support encrypting traffic between the peers.
+
+Kubernetes workers should open TCP port `6783` (control port), UDP port `6783` and UDP port `6784` (data ports). See the [port requirements for user clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for more details.
+
+For more information, see the following pages:
+
+- [Weave Net Official Site](https://github.com/weaveworks/weave/blob/master/site/overview.md)
+
+### CNI Features by Provider
+
+The following table summarizes the different features available for each CNI network provider provided by Rancher.
+
+| Provider | Network Model | Route Distribution | Network Policies | Mesh | External Datastore | Encryption | Ingress/Egress Policies |
+| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
+| Canal | Encapsulated (VXLAN) | No | Yes | No | K8S API | No | Yes |
+| Flannel | Encapsulated (VXLAN) | No | No | No | K8S API | No | No |
+| Calico | Encapsulated (VXLAN,IPIP) OR Unencapsulated | Yes | Yes | Yes | Etcd and K8S API | No | Yes |
+| Weave | Encapsulated | Yes | Yes | Yes | No | Yes | Yes |
+
+- Network Model: Encapsulated or unencapsulated. For more information, see [What Network Models are Used in CNI?](#what-network-models-are-used-in-cni)
+
+- Route Distribution: An exterior gateway protocol designed to exchange routing and reachability information on the Internet. BGP can assist with pod-to-pod networking between clusters. This feature is a must on unencapsulated CNI network providers, and it is typically done by BGP. If you plan to build clusters split across network segments, route distribution is a feature that's nice-to-have.
+
+- Network Policies: Kubernetes offers functionality to enforce rules about which services can communicate with each other using network policies. This feature is stable as of Kubernetes v1.7 and is ready to use with certain networking plugins.
+
+- Mesh: This feature allows service-to-service networking communication between distinct Kubernetes clusters.
+
+- External Datastore: CNI network providers with this feature need an external datastore for its data.
+
+- Encryption: This feature allows cyphered and secure network control and data planes.
+
+- Ingress/Egress Policies: This feature allows you to manage routing control for both Kubernetes and non-Kubernetes communications.
+
+### CNI Community Popularity
+
+<CNIPopularityTable />
+
+### Which CNI Provider Should I Use?
+
+It depends on your project needs. There are many different providers, which each have various features and options. There isn't one provider that meets everyone's needs.
+
+As of Rancher v2.0.7, Canal is the default CNI network provider. We recommend it for most use cases. It provides encapsulated networking for containers with Flannel, while adding Calico network policies that can provide project/namespace isolation in terms of networking.
+
+### How can I configure a CNI network provider?
+
+Please see [Cluster Options](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md) 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](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#cluster-config-file) and the options for [Network Plug-ins](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/).
@@ -0,0 +1,33 @@
+---
+title: Installing and Configuring kubectl
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/install-and-configure-kubectl"/>
+</head>
+
+`kubectl` is a CLI utility for running commands against Kubernetes clusters. It's required for many maintenance and administrative tasks in Rancher 2.x.
+
+## Installation
+
+See [kubectl Installation](https://kubernetes.io/docs/tasks/tools/install-kubectl/) for installation on your operating system.
+
+## Configuration
+
+When you create a Kubernetes cluster with RKE, RKE creates a `kube_config_rancher-cluster.yml` in the local directory that contains credentials to connect to your new cluster with tools like `kubectl` or `helm`.
+
+You can copy this file to `$HOME/.kube/config` or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_rancher-cluster.yml`.
+
+```
+export KUBECONFIG=$(pwd)/kube_config_rancher-cluster.yml
+```
+
+Test your connectivity with `kubectl` and see if you can get the list of nodes back.
+
+```
+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
+```
@@ -0,0 +1,50 @@
+---
+title: Rancher is No Longer Needed
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/rancher-is-no-longer-needed"/>
+</head>
+
+This page is intended to answer questions about what happens if you don't want Rancher anymore, if you don't want a cluster to be managed by Rancher anymore, or if the Rancher server is deleted.
+
+
+## If the Rancher server is deleted, what happens to the workloads in my downstream clusters?
+
+If Rancher is ever deleted or unrecoverable, all workloads in the downstream Kubernetes clusters managed by Rancher will continue to function as normal.
+
+## If the Rancher server is deleted, how do I access my downstream clusters?
+
+The capability to access a downstream cluster without Rancher depends on the type of cluster and the way that the cluster was created. To summarize:
+
+- **Imported clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was imported into Rancher.
+- **Hosted Kubernetes clusters:** If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider's cloud credentials.
+- **RKE clusters:** To access an [RKE cluster,](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
+
+## What if I don't want Rancher anymore?
+
+If you [installed Rancher on a Kubernetes cluster,](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) remove Rancher by using the [System Tools](../reference-guides/system-tools.md) with the `remove` subcommand.
+
+If you installed Rancher with Docker, you can uninstall Rancher by removing the single Docker container that it runs in.
+
+Imported clusters will not be affected by Rancher being removed. For other types of clusters, refer to the section on [accessing downstream clusters when Rancher is removed.](#if-the-rancher-server-is-deleted-how-do-i-access-my-downstream-clusters)
+
+## What if I don't want my imported cluster managed by Rancher?
+
+If an imported cluster is deleted from the Rancher UI, the cluster is detached from Rancher, leaving it intact and accessible by the same methods that were used to access it before it was imported into Rancher.
+
+To detach the cluster,
+
+1. From the **Global** view in Rancher, go to the **Clusters** tab.
+2. Go to the imported cluster that should be detached from Rancher and click **&#8942; > Delete.**
+3. Click **Delete.**
+
+**Result:** The imported cluster is detached from Rancher and functions normally outside of Rancher.
+
+## What if I don't want my RKE cluster or hosted Kubernetes cluster managed by Rancher?
+
+At this time, there is no functionality to detach these clusters from Rancher. In this context, "detach" is defined as the ability to remove Rancher components from the cluster and manage access to the cluster independently of Rancher.
+
+The capability to manage these clusters without Rancher is being tracked in this [issue.](https://github.com/rancher/rancher/issues/25234)
+
+For information about how to access clusters if the Rancher server is deleted, refer to [this section.](#if-the-rancher-server-is-deleted-how-do-i-access-my-downstream-clusters)
@@ -0,0 +1,15 @@
+---
+title: Security FAQ
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/security"/>
+</head>
+
+## Is there a Hardening Guide?
+
+The Hardening Guide is now located in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.
+
+## What are the results of Rancher's Kubernetes cluster when it is CIS benchmarked?
+
+We have run the CIS Kubernetes benchmark against a hardened Rancher Kubernetes cluster.  The results of that assessment can be found in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.
@@ -0,0 +1,196 @@
+---
+title: Technical FAQ
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/technical-items"/>
+</head>
+
+## How can I reset the administrator password?
+
+Docker install:
+
+```
+$ docker exec -ti <container_id> reset-password
+New password for default administrator (user-xxxxx):
+<new_password>
+```
+
+Kubernetes install (Helm):
+
+```
+$ KUBECONFIG=./kube_config_rancher-cluster.yml
+$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- reset-password
+New password for default administrator (user-xxxxx):
+<new_password>
+```
+
+### RKE add-on install (only supported up to Rancher v2.0.8)
+
+:::tip
+> If you are currently using the RKE add-on install method, see [Migrating from a Kubernetes Install with an RKE Add-on](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/migrating-from-rke-add-on.md) for details on how to start using the Helm chart.
+:::
+
+Kubernetes install (RKE add-on):
+
+```
+$ KUBECONFIG=./kube_config_rancher-cluster.yml
+$ kubectl --kubeconfig $KUBECONFIG exec -n cattle-system $(kubectl --kubeconfig $KUBECONFIG get pods -n cattle-system -o json | jq -r '.items[] | select(.spec.containers[].name=="cattle-server") | .metadata.name') -- reset-password
+New password for default administrator (user-xxxxx):
+<new_password>
+```
+
+## I deleted/deactivated the last admin, how can I fix it?
+
+Docker install:
+
+```
+$ docker exec -ti <container_id> ensure-default-admin
+New default administrator (user-xxxxx)
+New password for default administrator (user-xxxxx):
+<new_password>
+```
+
+Kubernetes install (Helm):
+```
+$ KUBECONFIG=./kube_config_rancher-cluster.yml
+$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin
+New password for default administrator (user-xxxxx):
+<new_password>
+```
+
+## How can I enable debug logging?
+
+See [Troubleshooting: Logging](../troubleshooting/other-troubleshooting-tips/logging.md)
+
+## My ClusterIP does not respond to ping
+
+ClusterIP is a virtual IP, which will not respond to ping. Best way to test if the ClusterIP is configured correctly, is by using `curl` to access the IP and port to see if it responds.
+
+## Where can I manage Node Templates?
+
+Node Templates can be accessed by opening your account menu (top right) and selecting `Node Templates`.
+
+## Why is my Layer-4 Load Balancer in `Pending` state?
+
+The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, this needs a cloud provider or controller that can satisfy these requests, otherwise these will be in `Pending` state forever. More information can be found on [Cloud Providers](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/set-up-cloud-providers.md) or [Create External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)
+
+## Where is the state of Rancher stored?
+
+- Docker Install: in the embedded etcd of the `rancher/rancher` container, located at `/var/lib/rancher`.
+- Kubernetes install: in the etcd of the RKE cluster created to run Rancher.
+
+## How are the supported Docker versions determined?
+
+We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
+
+## How can I access nodes created by Rancher?
+
+SSH keys to access the nodes created by Rancher can be downloaded via the **Nodes** view. Choose the node which you want to access and click on the vertical &#8942; button at the end of the row, and choose **Download Keys** as shown in the picture below.
+
+![Download Keys](/img/downloadsshkeys.png)
+
+Unzip the downloaded zip file, and use the file `id_rsa` to connect to you host. Be sure to use the correct username (`rancher` or `docker` for RancherOS, `ubuntu` for Ubuntu, `ec2-user` for Amazon Linux)
+
+```
+$ ssh -i id_rsa user@ip_of_node
+```
+
+## How can I automate task X in Rancher?
+
+The UI consists of static files, and works based on responses of the API. That means every action/task that you can execute in the UI, can be automated via the API. There are 2 ways to do this:
+
+* Visit `https://your_rancher_ip/v3` and browse the API options.
+* Capture the API calls when using the UI (Most commonly used for this is [Chrome Developer Tools](https://developers.google.com/web/tools/chrome-devtools/#network) but you can use anything you like)
+
+## The IP address of a node changed, how can I recover?
+
+A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and readd it. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.
+
+When the IP address of the node changed, Rancher lost connection to the node, so it will be unable to clean the node properly. See [Cleaning cluster nodes](../how-to-guides/advanced-user-guides/manage-clusters/clean-cluster-nodes.md) to clean the node.
+
+When the node is removed from the cluster, and the node is cleaned, you can readd the node to the cluster.
+
+## How can I add more arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
+
+You can add more arguments/binds/environment variables via the [Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#cluster-config-file) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls](https://rancher.com/docs/rke/latest/en/example-yamls/).
+
+## How do I check if my certificate chain is valid?
+
+Use the `openssl verify` command to validate your certificate chain:
+
+:::tip
+Configure `SSL_CERT_DIR` and `SSL_CERT_FILE` to a dummy location to make sure the OS installed certificates are not used when verifying manually.
+:::
+
+```
+SSL_CERT_DIR=/dummy SSL_CERT_FILE=/dummy openssl verify -CAfile ca.pem rancher.yourdomain.com.pem
+rancher.yourdomain.com.pem: OK
+```
+
+If you receive the error `unable to get local issuer certificate`, the chain is incomplete. This usually means that there is an intermediate CA certificate that issued your server certificate. If you already have this certificate, you can use it in the verification of the certificate like shown below:
+
+```
+SSL_CERT_DIR=/dummy SSL_CERT_FILE=/dummy openssl verify -CAfile ca.pem -untrusted intermediate.pem rancher.yourdomain.com.pem
+rancher.yourdomain.com.pem: OK
+```
+
+If you have successfully verified your certificate chain, you should include needed intermediate CA certificates in the server certificate to complete the certificate chain for any connection made to Rancher (for example, by the Rancher agent). The order of the certificates in the server certificate file should be first the server certificate itself (contents of `rancher.yourdomain.com.pem`), followed by intermediate CA certificate(s) (contents of `intermediate.pem`).
+
+```
+-----BEGIN CERTIFICATE-----
+%YOUR_CERTIFICATE%
+-----END CERTIFICATE-----
+-----BEGIN CERTIFICATE-----
+%YOUR_INTERMEDIATE_CERTIFICATE%
+-----END CERTIFICATE-----
+```
+
+If you still get errors during verification, you can retrieve the subject and the issuer of the server certificate using the following command:
+
+```
+openssl x509 -noout -subject -issuer -in rancher.yourdomain.com.pem
+subject= /C=GB/ST=England/O=Alice Ltd/CN=rancher.yourdomain.com
+issuer= /C=GB/ST=England/O=Alice Ltd/CN=Alice Intermediate CA
+```
+
+## How do I check `Common Name` and `Subject Alternative Names` in my server certificate?
+
+Although technically an entry in `Subject Alternative Names` is required, having the hostname in both `Common Name` and as entry in `Subject Alternative Names` gives you maximum compatibility with older browser/applications.
+
+Check `Common Name`:
+
+```
+openssl x509 -noout -subject -in cert.pem
+subject= /CN=rancher.my.org
+```
+
+Check `Subject Alternative Names`:
+
+```
+openssl x509 -noout -in cert.pem -text | grep DNS
+                DNS:rancher.my.org
+```
+
+## Why does it take 5+ minutes for a pod to be rescheduled when a node has failed?
+
+This is due to a combination of the following default Kubernetes settings:
+
+* kubelet
+  * `node-status-update-frequency`: Specifies how often kubelet posts node status to master (default 10s)
+* kube-controller-manager
+  * `node-monitor-period`: The period for syncing NodeStatus in NodeController (default 5s)
+  * `node-monitor-grace-period`: Amount of time which we allow running Node to be unresponsive before marking it unhealthy (default 40s)
+  * `pod-eviction-timeout`: The grace period for deleting pods on failed nodes (default 5m0s)
+
+See [Kubernetes: kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) and [Kubernetes: kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) for more information on these settings.
+
+In Kubernetes v1.13, the `TaintBasedEvictions` feature is enabled by default. See [Kubernetes: Taint based Evictions](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint-based-evictions) for more information.
+
+* kube-apiserver (Kubernetes v1.13 and up)
+  * `default-not-ready-toleration-seconds`: Indicates the tolerationSeconds of the toleration for notReady:NoExecute that is added by default to every pod that does not already have such a toleration.
+  * `default-unreachable-toleration-seconds`: Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration.
+
+## Can I use keyboard shortcuts in the UI?
+
+Yes, most parts of the UI can be reached using keyboard shortcuts. For an overview of the available shortcuts, press `?` anywhere in the UI.
@@ -0,0 +1,35 @@
+---
+title: Telemetry FAQ
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/telemetry"/>
+</head>
+
+## What is Telemetry?
+
+Telemetry collects aggregate information about the size of Rancher installations, versions of components used, and which features are used.  This information is used by Rancher Labs to help make the product better and is not shared with third-parties.
+
+## What information is collected?
+
+No specific identifying information like usernames, passwords, or the names or addresses of user resources will ever be collected.
+
+The primary things collected include:
+
+  - Aggregate counts (smallest, average, largest, total) of nodes per-cluster and their size (e.g. CPU cores & RAM).
+  - Aggregate counts of logical resources like Clusters, Projects, Namespaces, and Pods.
+  - Counts of what driver was used to deploy clusters and nodes (e.g. GKE vs EC2 vs Imported vs Custom).
+  - Versions of Kubernetes components, Operating Systems and Docker that are deployed on nodes.
+  - Whether some optional components are enabled or not (e.g. which auth providers are used).
+  - The image name & version of Rancher that is running.
+  - A unique randomly-generated identifier for this installation.
+
+## Can I see the information that is being sent?
+
+If Telemetry is enabled, you can go to `https://<your rancher server>/v1-telemetry` in your installation to see the current data.
+
+If Telemetry is not enabled, the process that collects the data is not running, so there is nothing being collected to look at.
+
+## How do I turn it on or off?
+
+After initial setup, an administrator can go to the `Settings` page in the `Global` section of the UI and click Edit to change the `telemetry-opt` setting to either `in` or `out`.
@@ -0,0 +1,9 @@
+---
+title: Getting Started
+---
+
+To get up and running with Rancher quickly, we have included a **Getting Started** section.
+
+The goal of this section is to be able to assist users in deploying Rancher and workloads and to install or upgrade Rancher quickly and effectively.
+
+Please see the [introduction](getting-started/introduction/introduction.md), [quick start guides](getting-started/quick-start-guides/quick-start-guides.md), and the [installation and upgrade](getting-started/installation-and-upgrade/installation-and-upgrade.md) sections for more.
@@ -0,0 +1,38 @@
+---
+title: Installing Rancher in an Air Gapped Environment with Helm 2
+---
+
+> After Helm 3 was released, the Rancher installation instructions were updated to use Helm 3.
+>
+> If you are using Helm 2, we recommend [migrating to Helm 3](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) because it is simpler to use and more secure than Helm 2.
+>
+> This section provides a copy of the older instructions for installing Rancher on a Kubernetes cluster using Helm 2 in an air air gap environment, and it is intended to be used if upgrading to Helm 3 is not feasible.
+
+This section is about installations of Rancher server in an air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy.
+
+Throughout the installations instructions, there will be _tabs_ for either a high availability Kubernetes installation or a single-node Docker installation.
+
+### Air Gapped Kubernetes Installations
+
+This section covers how to install Rancher on a Kubernetes cluster in an air gapped environment.
+
+A Kubernetes installation is comprised of three nodes running the Rancher server components on a Kubernetes cluster. The persistence layer (etcd) is also replicated on these three nodes, providing redundancy and data duplication in case one of the nodes fails.
+
+### Air Gapped Docker Installations
+
+These instructions also cover how to install Rancher on a single node in an air gapped environment.
+
+The Docker installation is for Rancher users that are wanting to test out Rancher. Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
+
+> **Important:** If you install Rancher following the Docker installation guide, there is no upgrade path to transition your Docker Installation to a Kubernetes Installation.
+
+Instead of running the Docker installation, you have the option to follow the Kubernetes Install guide, but only use one node to install Rancher. Afterwards, you can scale up the etcd nodes in your Kubernetes cluster to make it a Kubernetes Installation.
+
+## Installation Outline
+
+- [1. Prepare your Node(s)](../../../other-installation-methods/air-gapped-helm-cli-install/infrastructure-private-registry.md)
+- [2. Collect and Publish Images to your Private Registry](../../../other-installation-methods/air-gapped-helm-cli-install/publish-images.md)
+- [3. Launch a Kubernetes Cluster with RKE](../../../other-installation-methods/air-gapped-helm-cli-install/install-kubernetes.md)
+- [4. Install Rancher](../../../other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md)
+
+### [Next: Prepare your Node(s)](../../../other-installation-methods/air-gapped-helm-cli-install/infrastructure-private-registry.md)
@@ -0,0 +1,340 @@
+---
+title: 4. Install Rancher
+---
+
+This section is about how to deploy Rancher for your air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy. There are _tabs_ for either a high availability (recommended) or a Docker installation.
+
+<Tabs>
+<TabItem value="Kubernetes Install (Recommended)">
+
+Rancher recommends installing Rancher on a Kubernetes cluster. A highly available Kubernetes Installation is comprised of three nodes running the Rancher server components on a Kubernetes cluster. The persistence layer (etcd) is also replicated on these three nodes, providing redundancy and data duplication in case one of the nodes fails.
+
+### A. Add the Helm Chart Repository
+
+From a system that has access to the internet, fetch the latest Helm chart and copy the resulting manifests to a system that has access to the Rancher server cluster.
+
+1. If you haven't already, initialize Helm locally on a workstation that has internet access. 
+
+:::note
+
+Refer to the [Helm version requirements](../../../resources/choose-a-rancher-version.md) to choose a version of Helm to install Rancher.
+
+:::
+
+    ```plain
+    helm init -c
+    ```
+
+2. Use the `helm repo add` command to add the Helm chart repository that contains charts to install Rancher. For more information about the repository choices and which is best for your use case, see [Choosing a Version of Rancher](../../../resources/choose-a-rancher-version.md).
+    - Latest: Recommended for trying out the newest features
+        ```
+        helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+        ```
+    - Stable: Recommended for production environments
+        ```
+        helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+        ```
+    - Alpha: Experimental preview of upcoming releases.
+        ```
+        helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+        ```
+        Note: Upgrades are not supported to, from, or between Alphas.
+
+3. Fetch the latest Rancher chart. This will pull down the chart and save it in the current directory as a `.tgz` file.
+```plain
+helm fetch rancher-<CHART_REPO>/rancher
+```
+
+> Want additional options? See the Rancher [Helm chart options](../../../../../reference-guides/installation-references/helm-chart-options.md).
+
+### B. Choose your SSL Configuration
+
+Rancher Server is designed to be secure by default and requires SSL/TLS configuration.
+
+When Rancher is installed on an air gapped Kubernetes cluster, there are two recommended options for the source of the certificate.
+
+> **Note:** If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer](../../../../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination).
+
+| Configuration                              | Chart option                 | Description                                                                                                                                                 | Requires cert-manager |
+| ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
+| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br/> This is the **default** and does not need to be added when rendering the Helm template. | yes                   |
+| Certificates from Files                    | `ingress.tls.source=secret`  | Use your own certificate files by creating Kubernetes Secret(s). <br/> This option must be passed when rendering the Rancher Helm template.                  | no                    |
+
+### C. Render the Rancher Helm Template
+
+When setting up the Rancher Helm template, there are several options in the Helm chart that are designed specifically for air gap installations.
+
+| Chart Option            | Chart Value                      | Description   |
+| ----------------------- | -------------------------------- | ---- |
+| `certmanager.version` | `<version>` | Configure proper Rancher TLS issuer depending of running cert-manager version. |
+| `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters.  |
+| `useBundledSystemChart` | `true`                           | Configure Rancher server to use the packaged copy of Helm system charts. 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. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. _Available as of v2.3.0_ |
+
+Based on the choice your made in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), complete one of the procedures below.
+
+<details id="self-signed">
+  <summary>Option A-Default Self-Signed Certificate</summary>
+
+By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface.
+
+> **Note:**
+> Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade cert-manager documentation](../../../resources/upgrade-cert-manager.md).
+
+1. From a system connected to the internet, add the cert-manager repo to Helm.
+    ```plain
+    helm repo add jetstack https://charts.jetstack.io
+    helm repo update
+    ```
+
+1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://hub.helm.sh/charts/jetstack/cert-manager).
+
+   ```plain
+   helm fetch jetstack/cert-manager --version v0.14.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-v0.14.2.tgz --output-dir . \
+       --name cert-manager --namespace cert-manager \
+       --set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller
+       --set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook
+       --set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
+   ```
+
+1. Download the required CRD file for cert-manager
+   ```plain
+   curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.14/deploy/manifests/00-crds.yaml
+   ```
+1. Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
+
+
+    Placeholder | Description
+    ------------|-------------
+    `<VERSION>` | The version number of the output tarball.
+    `<RANCHER.YOURDOMAIN.COM>` | The DNS name you pointed at your load balancer.
+    `<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.
+    `<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.
+
+     ```plain
+    helm template ./rancher-<VERSION>.tgz --output-dir . \
+     --name rancher \
+     --namespace cattle-system \
+     --set hostname=<RANCHER.YOURDOMAIN.COM> \
+     --set certmanager.version=<CERTMANAGER_VERSION> \
+     --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+     --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Available as of v2.2.0, set a default private registry to be used in Rancher
+     --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
+```
+
+</details>
+
+<details id="secret">
+  <summary>Option B: Certificates From Files using Kubernetes Secrets</summary>
+
+Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher.
+
+Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
+
+| Placeholder                      | Description                                     |
+| -------------------------------- | ----------------------------------------------- |
+| `<VERSION>`                      | The version number of the output tarball.       |
+| `<RANCHER.YOURDOMAIN.COM>`       | The DNS name you pointed at your load balancer. |
+| `<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.         |
+
+```plain
+   helm template ./rancher-<VERSION>.tgz --output-dir . \
+    --name rancher \
+    --namespace cattle-system \
+    --set hostname=<RANCHER.YOURDOMAIN.COM> \
+    --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+    --set ingress.tls.source=secret \
+    --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Available as of v2.2.0, set a default private registry to be used in Rancher
+    --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
+```
+
+If you are using a Private CA signed cert, add `--set privateCA=true` following `--set ingress.tls.source=secret`:
+
+```plain
+   helm template ./rancher-<VERSION>.tgz --output-dir . \
+    --name rancher \
+    --namespace cattle-system \
+    --set hostname=<RANCHER.YOURDOMAIN.COM> \
+    --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+    --set ingress.tls.source=secret \
+    --set privateCA=true \
+    --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Available as of v2.2.0, set a default private registry to be used in Rancher
+    --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
+```
+
+Then refer to [Adding TLS Secrets](../../../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them.
+
+</details>
+
+### D. Install Rancher
+
+Copy the rendered manifest directories to a system that has access to the Rancher server cluster to complete installation.
+
+Use `kubectl` to create namespaces and apply the rendered manifests.
+
+If you choose to use self-signed certificates in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), install cert-manager.
+
+<details id="install-cert-manager">
+  <summary>Self-Signed Certificate Installs - Install Cert-manager</summary>
+
+If you are using self-signed certificates, install cert-manager:
+
+1. Create the namespace for cert-manager.
+```plain
+kubectl create namespace cert-manager
+```
+
+1. Create the cert-manager CustomResourceDefinitions (CRDs).
+```plain
+kubectl apply -f cert-manager/cert-manager-crd.yaml
+```
+
+> **Important:**
+> If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false flag to your kubectl apply command above else you will receive a validation error relating to the x-kubernetes-preserve-unknown-fields field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation.
+
+1. Launch cert-manager.
+```plain
+kubectl apply -R -f ./cert-manager
+```
+
+</details>
+
+Install Rancher:
+
+```plain
+kubectl create namespace cattle-system
+kubectl -n cattle-system apply -R -f ./rancher
+```
+
+**Step Result:** If you are installing Rancher v2.3.0+, the installation is complete.
+
+### E. For Rancher versions before v2.3.0, Configure System Charts
+
+If you are installing Rancher versions before v2.3.0, you will not be able to use the packaged system charts. Since the Rancher system charts are hosted in GitHub, an air gapped installation will not be able to access these charts. Therefore, you must [configure the Rancher system charts](../../../resources/local-system-charts.md).
+
+### Additional Resources
+
+These resources could be helpful when installing Rancher:
+
+- [Rancher Helm chart options](../../../../../reference-guides/installation-references/helm-chart-options.md)
+- [Adding TLS secrets](../../../resources/add-tls-secrets.md)
+- [Troubleshooting Rancher Kubernetes Installations](../../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)
+
+</TabItem>
+<TabItem value="Docker Install">
+
+The Docker installation is for Rancher users that are wanting to **test** out Rancher. Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server. **Important: If you install Rancher following the Docker installation guide, there is no upgrade path to transition your Docker installation to a Kubernetes Installation.** Instead of running the single node installation, you have the option to follow the Kubernetes Install guide, but only use one node to install Rancher. Afterwards, you can scale up the etcd nodes in your Kubernetes cluster to make it a Kubernetes Installation.
+
+For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
+
+| Environment Variable Key         | Environment Variable Value       | Description     |
+| -------------------------------- | -------------------------------- | ---- |
+| `CATTLE_SYSTEM_DEFAULT_REGISTRY` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters.  |
+| `CATTLE_SYSTEM_CATALOG`          | `bundled`                        | Configure Rancher server to use the packaged copy of Helm system charts. 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. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. _Available as of v2.3.0_ |
+
+> **Do you want to...**
+>
+> - Configure custom CA root certificate to access your services? See [Custom CA root certificate](../../../../../reference-guides/installation-references/helm-chart-options.md#additional-trusted-cas).
+> - Record all transactions with the Rancher API? See [API Auditing](../../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-audit-log).
+
+- For Rancher before v2.3.0, you will need to mirror the `system-charts` repository to a location in your network that Rancher can reach. Then, after Rancher is installed, you will need to configure Rancher to use that repository. For details, refer to the documentation on [setting up the system charts for Rancher before v2.3.0.](../../../resources/local-system-charts.md)
+
+Choose from the following options:
+
+<details id="option-a">
+  <summary>Option A-Default Self-Signed Certificate</summary>
+
+If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself.
+
+Log into your Linux host, and then run the installation command below. When entering the command, use the table below to replace each placeholder.
+
+| Placeholder                      | Description                                                                                                                   |
+| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
+| `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port.                                                                                           |
+| `<RANCHER_VERSION_TAG>`          | The release tag of the [Rancher version](../../../resources/choose-a-rancher-version.md) that you want to install. |
+
+```
+docker run -d --restart=unless-stopped \
+    -p 80:80 -p 443:443 \
+    -e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+    -e CATTLE_SYSTEM_CATALOG=bundled \ #Available as of v2.3.0, use the packaged Rancher system charts
+    <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
+```
+
+</details>
+<details id="option-b">
+  <summary>Option B-Bring Your Own Certificate: Self-Signed</summary>
+
+In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.
+
+> **Prerequisites:**
+> From a computer with an internet connection, create a self-signed certificate using [OpenSSL](https://www.openssl.org/) or another method of your choice.
+>
+> - The certificate files must be in PEM format.
+> - In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.](../../../other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)
+
+After creating your certificate, log into your Linux host, and then run the installation command below. When entering the command, use the table below to replace each placeholder. Use the `-v` flag and provide the path to your certificates to mount them in your container.
+
+| Placeholder                      | Description                                                                                                                   |
+| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
+| `<CERT_DIRECTORY>`               | The path to the directory containing your certificate files.                                                                  |
+| `<FULL_CHAIN.pem>`               | The path to your full certificate chain.                                                                                      |
+| `<PRIVATE_KEY.pem>`              | The path to the private key for your certificate.                                                                             |
+| `<CA_CERTS>`                     | The path to the certificate authority's certificate.                                                                          |
+| `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port.                                                                                           |
+| `<RANCHER_VERSION_TAG>`          | The release tag of the [Rancher version](../../../resources/choose-a-rancher-version.md) that you want to install. |
+
+```
+docker run -d --restart=unless-stopped \
+    -p 80:80 -p 443:443 \
+    -v /<CERT_DIRECTORY>/<FULL_CHAIN.pem>:/etc/rancher/ssl/cert.pem \
+    -v /<CERT_DIRECTORY>/<PRIVATE_KEY.pem>:/etc/rancher/ssl/key.pem \
+    -v /<CERT_DIRECTORY>/<CA_CERTS.pem>:/etc/rancher/ssl/cacerts.pem \
+    -e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+    -e CATTLE_SYSTEM_CATALOG=bundled \ #Available as of v2.3.0, use the packaged Rancher system charts
+    <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
+```
+
+</details>
+<details id="option-c">
+  <summary>Option C-Bring Your Own Certificate: Signed by Recognized CA</summary>
+
+In development or testing environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings.
+
+> **Prerequisite:** The certificate files must be in PEM format.
+
+After obtaining your certificate, log into your Linux host, and then run the installation command below. When entering the command, use the table below to replace each placeholder. Because your certificate is signed by a recognized CA, mounting an additional CA certificate file is unnecessary.
+
+| Placeholder                      | Description                                                                                                                   |
+| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
+| `<CERT_DIRECTORY>`               | The path to the directory containing your certificate files.                                                                  |
+| `<FULL_CHAIN.pem>`               | The path to your full certificate chain.                                                                                      |
+| `<PRIVATE_KEY.pem>`              | The path to the private key for your certificate.                                                                             |
+| `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port.                                                                                           |
+| `<RANCHER_VERSION_TAG>`          | The release tag of the [Rancher version](../../../resources/choose-a-rancher-version.md) that you want to install. |
+
+> **Note:** Use the `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher.
+
+```
+docker run -d --restart=unless-stopped \
+    -p 80:80 -p 443:443 \
+    --no-cacerts \
+    -v /<CERT_DIRECTORY>/<FULL_CHAIN.pem>:/etc/rancher/ssl/cert.pem \
+    -v /<CERT_DIRECTORY>/<PRIVATE_KEY.pem>:/etc/rancher/ssl/key.pem \
+    -e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+    -e CATTLE_SYSTEM_CATALOG=bundled \ #Available as of v2.3.0, use the packaged Rancher system charts
+    <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
+```
+
+</details>
+
+If you are installing Rancher v2.3.0+, the installation is complete.
+
+If you are installing Rancher versions before v2.3.0, you will not be able to use the packaged system charts. Since the Rancher system charts are hosted in GitHub, an air gapped installation will not be able to access these charts. Therefore, you must [configure the Rancher system charts](../../../resources/local-system-charts.md).
+
+</TabItem>
+</Tabs>
@@ -10,11 +10,11 @@ title: '2. Collect and Publish Images to your Private Registry'
 >
 > **Note:** Populating the private registry with images is the same process for HA and Docker installations, the differences in this section is based on whether or not you are planning to provision a Windows cluster or not.

-By default, all images used to [provision Kubernetes clusters](../../../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) or launch any [tools](../../../../../reference-guides/rancher-cluster-tools.md) in Rancher, e.g. monitoring, pipelines, alerts, are pulled from Docker Hub. In an air gap installation of Rancher, you will need a private registry that is located somewhere accessible by your Rancher server. Then, you will load the registry with all the images.
+By default, all images used to [provision Kubernetes clusters](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md) or launch any [tools](../../../../../reference-guides/rancher-cluster-tools.md) in Rancher, e.g. monitoring, pipelines, alerts, are pulled from Docker Hub. In an air gap installation of Rancher, you will need a private registry that is located somewhere accessible by your Rancher server. Then, you will load the registry with all the images.

 This section describes how to set up your private registry so that when you install Rancher, Rancher will pull all the required images from this registry.

-By default, we provide the steps of how to populate your private registry assuming you are provisioning Linux only clusters, but if you plan on provisioning any [Windows clusters](../../../../../pages-for-subheaders/use-windows-clusters.md), there are separate instructions to support the images needed for a Windows cluster.
+By default, we provide the steps of how to populate your private registry assuming you are provisioning Linux only clusters, but if you plan on provisioning any [Windows clusters](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/use-windows-clusters.md), there are separate instructions to support the images needed for a Windows cluster.

 <Tabs>
 <TabItem value="Linux Only Clusters">
@@ -15,7 +15,7 @@ This section is about how to prepare your node(s) to install Rancher for your ai

 ### OS, Docker, Hardware, and Networking

-Make sure that your node(s) fulfill the general [installation requirements.](../../../../../pages-for-subheaders/installation-requirements.md)
+Make sure that your node(s) fulfill the general [installation requirements.](../../../installation-requirements/installation-requirements.md)

 ### Private Registry

@@ -37,7 +37,7 @@ The following CLI tools are required for the Kubernetes Install. Make sure these

 ### OS, Docker, Hardware, and Networking

-Make sure that your node(s) fulfill the general [installation requirements.](../../../../../pages-for-subheaders/installation-requirements.md)
+Make sure that your node(s) fulfill the general [installation requirements.](../../../installation-requirements/installation-requirements.md)

 ### Private Registry

@@ -70,7 +70,7 @@ Rancher recommends installing Rancher on a Kubernetes cluster. A highly availabl

 These hosts will be disconnected from the internet, but require being able to connect with your private registry.

-View hardware and software requirements for each of your cluster nodes in [Requirements](../../../../../pages-for-subheaders/installation-requirements.md).
+View hardware and software requirements for each of your cluster nodes in [Requirements](../../../installation-requirements/installation-requirements.md).

 ### B. Set up your Load Balancer

@@ -99,7 +99,7 @@ Instead of running the Docker installation, you have the option to follow the Ku

 These hosts will be disconnected from the internet, but require being able to connect with your private registry.

-View hardware and software requirements for each of your cluster nodes in [Requirements](../../../../../pages-for-subheaders/installation-requirements.md).
+View hardware and software requirements for each of your cluster nodes in [Requirements](../../../installation-requirements/installation-requirements.md).

 </TabItem>
 </Tabs>
@@ -0,0 +1,244 @@
+---
+title: Docker Install with TLS Termination at Layer-7 NGINX Load Balancer
+---
+
+For development and testing environments that have a special requirement to terminate TLS/SSL at a load balancer instead of your Rancher Server container, deploy Rancher and configure a load balancer to work with it conjunction.
+
+A layer-7 load balancer can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with.
+
+This install procedure walks you through deployment of Rancher using a single container, and then provides a sample configuration for a layer-7 NGINX load balancer.
+
+> **Want to skip the external load balancer?**
+> See [Docker Installation](../../other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md) instead.
+
+## Requirements for OS, Docker, Hardware, and Networking
+
+Make sure that your node fulfills the general [installation requirements.](../../installation-requirements/installation-requirements.md)
+
+## Installation Outline
+
+
+## 1. Provision Linux Host
+
+Provision a single Linux host according to our [Requirements](../../installation-requirements/installation-requirements.md) to launch your Rancher Server.
+
+## 2. Choose an SSL Option and Install Rancher
+
+For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
+
+> **Do you want to...**
+>
+> - Complete an Air Gap Installation?
+> - Record all transactions with the Rancher API?
+>
+> See [Advanced Options](#advanced-options) below before continuing.
+
+Choose from the following options:
+
+<details id="option-a">
+  <summary>Option A-Bring Your Own Certificate: Self-Signed</summary>
+
+If you elect to use a self-signed certificate to encrypt communication, you must install the certificate on your load balancer (which you'll do later) and your Rancher container. Run the Docker command to deploy Rancher, pointing it toward your certificate.
+
+> **Prerequisites:**
+> Create a self-signed certificate.
+>
+> - The certificate files must be in PEM format.
+
+**To Install Rancher Using a Self-Signed Cert:**
+
+1. While running the Docker command to deploy Rancher, point Docker toward your CA certificate file.
+
+   ```
+   docker run -d --restart=unless-stopped \
+     -p 80:80 -p 443:443 \
+     -v /etc/your_certificate_directory/cacerts.pem:/etc/rancher/ssl/cacerts.pem \
+     rancher/rancher:latest
+   ```
+
+</details>
+<details id="option-b">
+  <summary>Option B-Bring Your Own Certificate: Signed by Recognized CA</summary>
+If your cluster is public facing, it's best to use a certificate signed by a recognized CA.
+
+> **Prerequisites:**
+>
+> - The certificate files must be in PEM format.
+
+**To Install Rancher Using a Cert Signed by a Recognized CA:**
+
+If you use a certificate signed by a recognized CA, installing your certificate in the Rancher container isn't necessary. We do have to make sure there is no default CA certificate generated and stored, you can do this by passing the `--no-cacerts` parameter to the container.
+
+1.  Enter the following command.
+
+        ```
+        docker run -d --restart=unless-stopped \
+        -p 80:80 -p 443:443 \
+        rancher/rancher:latest --no-cacerts
+        ```
+
+</details>
+
+## 3. Configure Load Balancer
+
+When using a load balancer in front of your Rancher container, there's no need for the container to redirect port communication from port 80 or port 443. By passing the header `X-Forwarded-Proto: https` header, this redirect is disabled.
+
+The load balancer or proxy has to be configured to support the following:
+
+- **WebSocket** connections
+- **SPDY** / **HTTP/2** protocols
+- Passing / setting the following headers:
+
+    | Header | Value | Description |
+    |--------|-------|-------------|
+    | `Host`                | Hostname used to reach Rancher.          | To identify the server requested by the client.
+    | `X-Forwarded-Proto`   | `https`                                  | To identify the protocol that a client used to connect to the load balancer or proxy.<br /><br/>**Note:** If this header is present, `rancher/rancher` does not redirect HTTP to HTTPS.
+    | `X-Forwarded-Port`    | Port used to reach Rancher.              | To identify the protocol that client used to connect to the load balancer or proxy.
+    | `X-Forwarded-For`     | IP of the client connection.             | To identify the originating IP address of a client.
+### Example NGINX configuration
+
+This NGINX configuration is tested on NGINX 1.14.
+
+> **Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
+
+- Replace `rancher-server` with the IP address or hostname of the node running the Rancher container.
+- Replace both occurrences of `FQDN` to the DNS name for Rancher.
+- Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively.
+
+```
+worker_processes 4;
+worker_rlimit_nofile 40000;
+
+events {
+    worker_connections 8192;
+}
+
+http {
+    upstream rancher {
+        server rancher-server:80;
+    }
+
+    map $http_upgrade $connection_upgrade {
+        default Upgrade;
+        ''      close;
+    }
+
+    server {
+        listen 443 ssl http2;
+        server_name FQDN;
+        ssl_certificate /certs/fullchain.pem;
+        ssl_certificate_key /certs/privkey.pem;
+
+        location / {
+            proxy_set_header Host $host;
+            proxy_set_header X-Forwarded-Proto $scheme;
+            proxy_set_header X-Forwarded-Port $server_port;
+            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+            proxy_pass http://rancher;
+            proxy_http_version 1.1;
+            proxy_set_header Upgrade $http_upgrade;
+            proxy_set_header Connection $connection_upgrade;
+            # This allows the ability for the execute shell window to remain open for up to 15 minutes. Without this parameter, the default is 1 minute and will automatically close.
+            proxy_read_timeout 900s;
+            proxy_buffering off;
+        }
+    }
+
+    server {
+        listen 80;
+        server_name FQDN;
+        return 301 https://$server_name$request_uri;
+    }
+}
+```
+
+<br/>
+
+## What's Next?
+
+- **Recommended:** Review [Single Node Backup and Restore](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md). Although you don't have any data you need to back up right now, we recommend creating backups after regular Rancher use.
+- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md).
+
+<br/>
+
+## FAQ and Troubleshooting
+
+For help troubleshooting certificates, see [this section.](../../other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)
+
+## Advanced Options
+
+### API Auditing
+
+If you want to record all transactions with the Rancher API, enable the [API Auditing](../../../installation-and-upgrade/advanced-options/advanced-use-cases/enable-api-audit-log.md) feature by adding the flags below into your install command.
+
+    -e AUDIT_LEVEL=1 \
+    -e AUDIT_LOG_PATH=/var/log/auditlog/rancher-api-audit.log \
+    -e AUDIT_LOG_MAXAGE=20 \
+    -e AUDIT_LOG_MAXBACKUP=20 \
+    -e AUDIT_LOG_MAXSIZE=100 \
+
+### Air Gap
+
+If you are visiting this page to complete an [Air Gap Installation](air-gap-helm2/air-gap-helm2.md), you must pre-pend your private registry URL to the server tag when running the installation command in the option that you choose. Add `<REGISTRY.DOMAIN.COM:PORT>` with your private registry URL in front of `rancher/rancher:latest`.
+
+**Example:**
+
+     <REGISTRY.DOMAIN.COM:PORT>/rancher/rancher:latest
+
+### Persistent Data
+
+Rancher uses etcd as a datastore. When Rancher is installed with Docker, the embedded etcd is being used. The persistent data is at the following path in the container: `/var/lib/rancher`.
+
+You can bind mount a host volume to this location to preserve data on the host it is running on:
+
+```
+docker run -d --restart=unless-stopped \
+  -p 80:80 -p 443:443 \
+  -v /opt/rancher:/var/lib/rancher \
+  rancher/rancher:latest
+```
+
+This layer 7 NGINX configuration is tested on NGINX version 1.13 (mainline) and 1.14 (stable).
+
+> **Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/).
+
+```
+upstream rancher {
+    server rancher-server:80;
+}
+
+map $http_upgrade $connection_upgrade {
+    default Upgrade;
+    ''      close;
+}
+
+server {
+    listen 443 ssl http2;
+    server_name rancher.yourdomain.com;
+    ssl_certificate /etc/your_certificate_directory/fullchain.pem;
+    ssl_certificate_key /etc/your_certificate_directory/privkey.pem;
+
+    location / {
+        proxy_set_header Host $host;
+        proxy_set_header X-Forwarded-Proto $scheme;
+        proxy_set_header X-Forwarded-Port $server_port;
+        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_pass http://rancher;
+        proxy_http_version 1.1;
+        proxy_set_header Upgrade $http_upgrade;
+        proxy_set_header Connection $connection_upgrade;
+        # This allows the ability for the execute shell window to remain open for up to 15 minutes. Without this parameter, the default is 1 minute and will automatically close.
+        proxy_read_timeout 900s;
+        proxy_buffering off;
+    }
+}
+
+server {
+    listen 80;
+    server_name rancher.yourdomain.com;
+    return 301 https://$server_name$request_uri;
+}
+```
+
+<br/>
+
@@ -0,0 +1,565 @@
+---
+title: Enabling the API Audit Log to Record System Events
+---
+
+You can enable the API audit log to record the sequence of system events initiated by individual users. You can know what happened, when it happened, who initiated it, and what cluster it affected. When you enable this feature, all requests to the Rancher API and all responses from it are written to a log.
+
+You can enable API Auditing during Rancher installation or upgrade.
+
+## Enabling API Audit Log
+
+The Audit Log is enabled and configured by passing environment variables to the Rancher server container. See the following to enable on your installation.
+
+- [Docker Install](../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-audit-log)
+
+- [Kubernetes Install](../../../../reference-guides/installation-references/helm-chart-options.md#api-audit-log)
+
+## API Audit Log Options
+
+The usage below defines rules about what the audit log should record and what data it should include:
+
+| Parameter                             | Description                                                                                                                                                                                                                                                                                                                                                                    |
+| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `AUDIT_LEVEL` | `0` - Disable audit log (default setting).<br/>`1` - Log event metadata.<br/>`2` - Log event metadata and request body.<br/>`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.<br/><br/>See [Audit Level Logging](#audit-log-levels) for a table that displays what each setting logs. |
+| `AUDIT_LOG_PATH`                      | Log path for Rancher Server API. Default path is `/var/log/auditlog/rancher-api-audit.log`. You can mount the log directory to host. <br/><br/>Usage Example: `AUDIT_LOG_PATH=/my/custom/path/`<br/>                                                                                                                                                                           |
+| `AUDIT_LOG_MAXAGE`                    | Defined the maximum number of days to retain old audit log files. Default is 10 days.                                                                                                                                                                                                                                                                                          |
+| `AUDIT_LOG_MAXBACKUP`                 | Defines the maximum number of audit log files to retain. Default is 10.                                                                                                                                                                                                                                                                                                        |
+| `AUDIT_LOG_MAXSIZE`                   | Defines the maximum size in megabytes of the audit log file before it gets rotated. Default size is 100M.                                                                                                                                                                                                                                                                      |
+
+<br/>
+
+### Audit Log Levels
+
+The following table displays what parts of API transactions are logged for each [`AUDIT_LEVEL`](#api-audit-log-options) setting.
+
+| `AUDIT_LEVEL` Setting | Metadata | Request Body | Response Body |
+| --------------------- | -------- | ------------ | ------------- |
+| `0`                   |          |              |               |
+| `1`                   | ✓        |              |               |
+| `2`                   | ✓        | ✓            |               |
+| `3`                   | ✓        | ✓            | ✓             |
+
+## Viewing API Audit Logs
+
+### Docker Install
+
+Share the `AUDIT_LOG_PATH` directory (Default: `/var/log/auditlog`) with the host system. The log can be parsed by standard CLI tools or forwarded on to a log collection tool like Fluentd, Filebeat, Logstash, etc.
+
+### Kubernetes Install
+
+Enabling the API Audit Log with the Helm chart install will create a `rancher-audit-log` sidecar container in the Rancher pod. This container will stream the log to standard output (stdout). You can view the log as you would any container log.
+
+The `rancher-audit-log` container is part of the `rancher` pod in the `cattle-system` namespace.
+
+#### CLI
+
+```bash
+kubectl -n cattle-system logs -f rancher-84d886bdbb-s4s69 rancher-audit-log
+```
+
+#### Rancher Web GUI
+
+1. From the context menu, select **Cluster: local > System**.
+1. From the main navigation bar, choose **Resources > Workloads.** (In versions before v2.3.0, choose **Workloads** on the main navigation bar.) Find the `cattle-system` namespace. Open the `rancher` workload by clicking its link.
+1. Pick one of the `rancher` pods and select **&#8942; > View Logs**.
+1. From the **Logs** drop-down, select `rancher-audit-log`.
+
+#### Shipping the Audit Log
+
+You can enable Rancher's built in log collection and shipping for the cluster to ship the audit and other services logs to a supported collection endpoint. See [Rancher Tools - Logging](../../../../explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) for details.
+
+## Audit Log Samples
+
+After you enable auditing, each API request or response is logged by Rancher in the form of JSON. Each of the following code samples provide examples of how to identify each API transaction.
+
+### Metadata Level
+
+If you set your `AUDIT_LEVEL` to `1`, Rancher logs the metadata header for every API request, but not the body. The header provides basic information about the API transaction, such as the transaction's ID, who initiated the transaction, the time it occurred, etc.
+
+```json
+{
+  "auditID": "30022177-9e2e-43d1-b0d0-06ef9d3db183",
+  "requestURI": "/v3/schemas",
+  "sourceIPs": ["::1"],
+  "user": {
+    "name": "user-f4tt2",
+    "group": ["system:authenticated"]
+  },
+  "verb": "GET",
+  "stage": "RequestReceived",
+  "stageTimestamp": "2018-07-20 10:22:43 +0800"
+}
+```
+
+### Metadata and Request Body Level
+
+If you set your `AUDIT_LEVEL` to `2`, Rancher logs the metadata header and body for every API request.
+
+The code sample below depicts an API request, with both its metadata header and body.
+
+```json
+{
+  "auditID": "ef1d249e-bfac-4fd0-a61f-cbdcad53b9bb",
+  "requestURI": "/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
+  "sourceIPs": ["::1"],
+  "user": {
+    "name": "user-f4tt2",
+    "group": ["system:authenticated"]
+  },
+  "verb": "PUT",
+  "stage": "RequestReceived",
+  "stageTimestamp": "2018-07-20 10:28:08 +0800",
+  "requestBody": {
+    "hostIPC": false,
+    "hostNetwork": false,
+    "hostPID": false,
+    "paused": false,
+    "annotations": {},
+    "baseType": "workload",
+    "containers": [
+      {
+        "allowPrivilegeEscalation": false,
+        "image": "nginx",
+        "imagePullPolicy": "Always",
+        "initContainer": false,
+        "name": "nginx",
+        "ports": [
+          {
+            "containerPort": 80,
+            "dnsName": "nginx-nodeport",
+            "kind": "NodePort",
+            "name": "80tcp01",
+            "protocol": "TCP",
+            "sourcePort": 0,
+            "type": "/v3/project/schemas/containerPort"
+          }
+        ],
+        "privileged": false,
+        "readOnly": false,
+        "resources": {
+          "type": "/v3/project/schemas/resourceRequirements",
+          "requests": {},
+          "limits": {}
+        },
+        "restartCount": 0,
+        "runAsNonRoot": false,
+        "stdin": true,
+        "stdinOnce": false,
+        "terminationMessagePath": "/dev/termination-log",
+        "terminationMessagePolicy": "File",
+        "tty": true,
+        "type": "/v3/project/schemas/container",
+        "environmentFrom": [],
+        "capAdd": [],
+        "capDrop": [],
+        "livenessProbe": null,
+        "volumeMounts": []
+      }
+    ],
+    "created": "2018-07-18T07:34:16Z",
+    "createdTS": 1531899256000,
+    "creatorId": null,
+    "deploymentConfig": {
+      "maxSurge": 1,
+      "maxUnavailable": 0,
+      "minReadySeconds": 0,
+      "progressDeadlineSeconds": 600,
+      "revisionHistoryLimit": 10,
+      "strategy": "RollingUpdate"
+    },
+    "deploymentStatus": {
+      "availableReplicas": 1,
+      "conditions": [
+        {
+          "lastTransitionTime": "2018-07-18T07:34:38Z",
+          "lastTransitionTimeTS": 1531899278000,
+          "lastUpdateTime": "2018-07-18T07:34:38Z",
+          "lastUpdateTimeTS": 1531899278000,
+          "message": "Deployment has minimum availability.",
+          "reason": "MinimumReplicasAvailable",
+          "status": "True",
+          "type": "Available"
+        },
+        {
+          "lastTransitionTime": "2018-07-18T07:34:16Z",
+          "lastTransitionTimeTS": 1531899256000,
+          "lastUpdateTime": "2018-07-18T07:34:38Z",
+          "lastUpdateTimeTS": 1531899278000,
+          "message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
+          "reason": "NewReplicaSetAvailable",
+          "status": "True",
+          "type": "Progressing"
+        }
+      ],
+      "observedGeneration": 2,
+      "readyReplicas": 1,
+      "replicas": 1,
+      "type": "/v3/project/schemas/deploymentStatus",
+      "unavailableReplicas": 0,
+      "updatedReplicas": 1
+    },
+    "dnsPolicy": "ClusterFirst",
+    "id": "deployment:default:nginx",
+    "labels": {
+      "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+    },
+    "name": "nginx",
+    "namespaceId": "default",
+    "projectId": "c-bcz5t:p-fdr4s",
+    "publicEndpoints": [
+      {
+        "addresses": ["10.64.3.58"],
+        "allNodes": true,
+        "ingressId": null,
+        "nodeId": null,
+        "podId": null,
+        "port": 30917,
+        "protocol": "TCP",
+        "serviceId": "default:nginx-nodeport",
+        "type": "publicEndpoint"
+      }
+    ],
+    "restartPolicy": "Always",
+    "scale": 1,
+    "schedulerName": "default-scheduler",
+    "selector": {
+      "matchLabels": {
+        "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+      },
+      "type": "/v3/project/schemas/labelSelector"
+    },
+    "state": "active",
+    "terminationGracePeriodSeconds": 30,
+    "transitioning": "no",
+    "transitioningMessage": "",
+    "type": "deployment",
+    "uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
+    "workloadAnnotations": {
+      "deployment.kubernetes.io/revision": "1",
+      "field.cattle.io/creatorId": "user-f4tt2"
+    },
+    "workloadLabels": {
+      "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+    },
+    "scheduling": {
+      "node": {}
+    },
+    "description": "my description",
+    "volumes": []
+  }
+}
+```
+
+### Metadata, Request Body, and Response Body Level
+
+If you set your `AUDIT_LEVEL` to `3`, Rancher logs:
+
+- The metadata header and body for every API request.
+- The metadata header and body for every API response.
+
+#### Request
+
+The code sample below depicts an API request, with both its metadata header and body.
+
+```json
+{
+  "auditID": "a886fd9f-5d6b-4ae3-9a10-5bff8f3d68af",
+  "requestURI": "/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
+  "sourceIPs": ["::1"],
+  "user": {
+    "name": "user-f4tt2",
+    "group": ["system:authenticated"]
+  },
+  "verb": "PUT",
+  "stage": "RequestReceived",
+  "stageTimestamp": "2018-07-20 10:33:06 +0800",
+  "requestBody": {
+    "hostIPC": false,
+    "hostNetwork": false,
+    "hostPID": false,
+    "paused": false,
+    "annotations": {},
+    "baseType": "workload",
+    "containers": [
+      {
+        "allowPrivilegeEscalation": false,
+        "image": "nginx",
+        "imagePullPolicy": "Always",
+        "initContainer": false,
+        "name": "nginx",
+        "ports": [
+          {
+            "containerPort": 80,
+            "dnsName": "nginx-nodeport",
+            "kind": "NodePort",
+            "name": "80tcp01",
+            "protocol": "TCP",
+            "sourcePort": 0,
+            "type": "/v3/project/schemas/containerPort"
+          }
+        ],
+        "privileged": false,
+        "readOnly": false,
+        "resources": {
+          "type": "/v3/project/schemas/resourceRequirements",
+          "requests": {},
+          "limits": {}
+        },
+        "restartCount": 0,
+        "runAsNonRoot": false,
+        "stdin": true,
+        "stdinOnce": false,
+        "terminationMessagePath": "/dev/termination-log",
+        "terminationMessagePolicy": "File",
+        "tty": true,
+        "type": "/v3/project/schemas/container",
+        "environmentFrom": [],
+        "capAdd": [],
+        "capDrop": [],
+        "livenessProbe": null,
+        "volumeMounts": []
+      }
+    ],
+    "created": "2018-07-18T07:34:16Z",
+    "createdTS": 1531899256000,
+    "creatorId": null,
+    "deploymentConfig": {
+      "maxSurge": 1,
+      "maxUnavailable": 0,
+      "minReadySeconds": 0,
+      "progressDeadlineSeconds": 600,
+      "revisionHistoryLimit": 10,
+      "strategy": "RollingUpdate"
+    },
+    "deploymentStatus": {
+      "availableReplicas": 1,
+      "conditions": [
+        {
+          "lastTransitionTime": "2018-07-18T07:34:38Z",
+          "lastTransitionTimeTS": 1531899278000,
+          "lastUpdateTime": "2018-07-18T07:34:38Z",
+          "lastUpdateTimeTS": 1531899278000,
+          "message": "Deployment has minimum availability.",
+          "reason": "MinimumReplicasAvailable",
+          "status": "True",
+          "type": "Available"
+        },
+        {
+          "lastTransitionTime": "2018-07-18T07:34:16Z",
+          "lastTransitionTimeTS": 1531899256000,
+          "lastUpdateTime": "2018-07-18T07:34:38Z",
+          "lastUpdateTimeTS": 1531899278000,
+          "message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
+          "reason": "NewReplicaSetAvailable",
+          "status": "True",
+          "type": "Progressing"
+        }
+      ],
+      "observedGeneration": 2,
+      "readyReplicas": 1,
+      "replicas": 1,
+      "type": "/v3/project/schemas/deploymentStatus",
+      "unavailableReplicas": 0,
+      "updatedReplicas": 1
+    },
+    "dnsPolicy": "ClusterFirst",
+    "id": "deployment:default:nginx",
+    "labels": {
+      "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+    },
+    "name": "nginx",
+    "namespaceId": "default",
+    "projectId": "c-bcz5t:p-fdr4s",
+    "publicEndpoints": [
+      {
+        "addresses": ["10.64.3.58"],
+        "allNodes": true,
+        "ingressId": null,
+        "nodeId": null,
+        "podId": null,
+        "port": 30917,
+        "protocol": "TCP",
+        "serviceId": "default:nginx-nodeport",
+        "type": "publicEndpoint"
+      }
+    ],
+    "restartPolicy": "Always",
+    "scale": 1,
+    "schedulerName": "default-scheduler",
+    "selector": {
+      "matchLabels": {
+        "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+      },
+      "type": "/v3/project/schemas/labelSelector"
+    },
+    "state": "active",
+    "terminationGracePeriodSeconds": 30,
+    "transitioning": "no",
+    "transitioningMessage": "",
+    "type": "deployment",
+    "uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
+    "workloadAnnotations": {
+      "deployment.kubernetes.io/revision": "1",
+      "field.cattle.io/creatorId": "user-f4tt2"
+    },
+    "workloadLabels": {
+      "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+    },
+    "scheduling": {
+      "node": {}
+    },
+    "description": "my decript",
+    "volumes": []
+  }
+}
+```
+
+#### Response
+
+The code sample below depicts an API response, with both its metadata header and body.
+
+```json
+{
+  "auditID": "a886fd9f-5d6b-4ae3-9a10-5bff8f3d68af",
+  "responseStatus": "200",
+  "stage": "ResponseComplete",
+  "stageTimestamp": "2018-07-20 10:33:06 +0800",
+  "responseBody": {
+    "actionLinks": {
+      "pause": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=pause",
+      "resume": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=resume",
+      "rollback": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=rollback"
+    },
+    "annotations": {},
+    "baseType": "workload",
+    "containers": [
+      {
+        "allowPrivilegeEscalation": false,
+        "image": "nginx",
+        "imagePullPolicy": "Always",
+        "initContainer": false,
+        "name": "nginx",
+        "ports": [
+          {
+            "containerPort": 80,
+            "dnsName": "nginx-nodeport",
+            "kind": "NodePort",
+            "name": "80tcp01",
+            "protocol": "TCP",
+            "sourcePort": 0,
+            "type": "/v3/project/schemas/containerPort"
+          }
+        ],
+        "privileged": false,
+        "readOnly": false,
+        "resources": {
+          "type": "/v3/project/schemas/resourceRequirements"
+        },
+        "restartCount": 0,
+        "runAsNonRoot": false,
+        "stdin": true,
+        "stdinOnce": false,
+        "terminationMessagePath": "/dev/termination-log",
+        "terminationMessagePolicy": "File",
+        "tty": true,
+        "type": "/v3/project/schemas/container"
+      }
+    ],
+    "created": "2018-07-18T07:34:16Z",
+    "createdTS": 1531899256000,
+    "creatorId": null,
+    "deploymentConfig": {
+      "maxSurge": 1,
+      "maxUnavailable": 0,
+      "minReadySeconds": 0,
+      "progressDeadlineSeconds": 600,
+      "revisionHistoryLimit": 10,
+      "strategy": "RollingUpdate"
+    },
+    "deploymentStatus": {
+      "availableReplicas": 1,
+      "conditions": [
+        {
+          "lastTransitionTime": "2018-07-18T07:34:38Z",
+          "lastTransitionTimeTS": 1531899278000,
+          "lastUpdateTime": "2018-07-18T07:34:38Z",
+          "lastUpdateTimeTS": 1531899278000,
+          "message": "Deployment has minimum availability.",
+          "reason": "MinimumReplicasAvailable",
+          "status": "True",
+          "type": "Available"
+        },
+        {
+          "lastTransitionTime": "2018-07-18T07:34:16Z",
+          "lastTransitionTimeTS": 1531899256000,
+          "lastUpdateTime": "2018-07-18T07:34:38Z",
+          "lastUpdateTimeTS": 1531899278000,
+          "message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
+          "reason": "NewReplicaSetAvailable",
+          "status": "True",
+          "type": "Progressing"
+        }
+      ],
+      "observedGeneration": 2,
+      "readyReplicas": 1,
+      "replicas": 1,
+      "type": "/v3/project/schemas/deploymentStatus",
+      "unavailableReplicas": 0,
+      "updatedReplicas": 1
+    },
+    "dnsPolicy": "ClusterFirst",
+    "hostIPC": false,
+    "hostNetwork": false,
+    "hostPID": false,
+    "id": "deployment:default:nginx",
+    "labels": {
+      "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+    },
+    "links": {
+      "remove": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
+      "revisions": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx/revisions",
+      "self": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
+      "update": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
+      "yaml": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx/yaml"
+    },
+    "name": "nginx",
+    "namespaceId": "default",
+    "paused": false,
+    "projectId": "c-bcz5t:p-fdr4s",
+    "publicEndpoints": [
+      {
+        "addresses": ["10.64.3.58"],
+        "allNodes": true,
+        "ingressId": null,
+        "nodeId": null,
+        "podId": null,
+        "port": 30917,
+        "protocol": "TCP",
+        "serviceId": "default:nginx-nodeport"
+      }
+    ],
+    "restartPolicy": "Always",
+    "scale": 1,
+    "schedulerName": "default-scheduler",
+    "selector": {
+      "matchLabels": {
+        "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+      },
+      "type": "/v3/project/schemas/labelSelector"
+    },
+    "state": "active",
+    "terminationGracePeriodSeconds": 30,
+    "transitioning": "no",
+    "transitioningMessage": "",
+    "type": "deployment",
+    "uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
+    "workloadAnnotations": {
+      "deployment.kubernetes.io/revision": "1",
+      "field.cattle.io/creatorId": "user-f4tt2"
+    },
+    "workloadLabels": {
+      "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+    }
+  }
+}
+```
@@ -0,0 +1,29 @@
+---
+title: "1. Create Nodes and Load Balancer"
+---
+
+Use your provider of choice to provision 3 nodes and a Load Balancer endpoint for your RKE install.
+
+> **Note:** These nodes must be in the same region/datacenter.  You may place these servers in separate availability zones.
+
+### Node Requirements
+
+View the supported operating systems and hardware/software/networking requirements for nodes running Rancher at [Node Requirements](../../../../installation-requirements/installation-requirements.md).
+
+View the OS requirements for RKE at [RKE Requirements](https://rancher.com/docs/rke/latest/en/os/)
+
+### Load Balancer
+
+RKE will configure an Ingress controller pod, on each of your nodes. The Ingress controller pods are bound to ports TCP/80 and TCP/443 on the host network and are the entry point for HTTPS traffic to the Rancher server.
+
+Configure a load balancer as a basic Layer 4 TCP forwarder. The exact configuration will vary depending on your environment.
+
+>**Important:**
+>Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
+
+#### Examples
+
+* [Nginx](nginx.md)
+* [Amazon NLB](nlb.md)
+
+### [Next: Install Kubernetes with RKE](../kubernetes-rke/kubernetes-rke.md)
@@ -21,7 +21,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx.

 1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`.

-2. From `nginx.conf`, replace both occurrences (port 80 and port 443) of `<IP_NODE_1>`, `<IP_NODE_2>`, and `<IP_NODE_3>` with the IPs of your [nodes](../../../../../../pages-for-subheaders/helm2-create-nodes-lb.md).
+2. From `nginx.conf`, replace both occurrences (port 80 and port 443) of `<IP_NODE_1>`, `<IP_NODE_2>`, and `<IP_NODE_3>` with the IPs of your [nodes](create-nodes-lb.md).

    >**Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options.

@@ -0,0 +1,65 @@
+---
+title: "Initialize Helm: Install the Tiller Service"
+description: "With Helm, you can create configurable deployments instead of using static files. In order to use Helm, the Tiller service needs to be installed on your cluster."
+---
+
+Helm is the package management tool of choice for Kubernetes. Helm "charts" provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at [https://helm.sh/](https://helm.sh/). To be able to use Helm, the server-side component `tiller` needs to be installed on your cluster.
+
+For systems without direct internet access, see [Helm - Air Gap](../../../../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) for install details.
+
+Refer to the [Helm version requirements](../../../../resources/helm-version-requirements.md) to choose a version of Helm to install Rancher.
+
+> **Note:** The installation instructions assume you are using Helm 2. The instructions will be updated for Helm 3 soon. In the meantime, if you want to use Helm 3, refer to [these instructions.](https://github.com/ibrokethecloud/rancher-helm3)
+
+### Install Tiller on the Cluster
+
+> **Important:** Due to an issue with Helm v2.12.0 and cert-manager, please use Helm v2.12.1 or higher.
+
+Helm installs the `tiller` service on your cluster to manage charts. Since RKE enables RBAC by default we will need to use `kubectl` to create a `serviceaccount` and `clusterrolebinding` so `tiller` has permission to deploy to the cluster.
+
+* Create the `ServiceAccount` in the `kube-system` namespace.
+* Create the `ClusterRoleBinding` to give the `tiller` account access to the cluster.
+* Finally use `helm` to install the `tiller` service
+
+```plain
+kubectl -n kube-system create serviceaccount tiller
+
+kubectl create clusterrolebinding tiller \
+  --clusterrole=cluster-admin \
+  --serviceaccount=kube-system:tiller
+
+helm init --service-account tiller
+
+# Users in China: You will need to specify a specific tiller-image in order to initialize tiller.
+# The list of tiller image tags are available here: https://dev.aliyun.com/detail.html?spm=5176.1972343.2.18.ErFNgC&repoId=62085.
+# When initializing tiller, you'll need to pass in --tiller-image
+
+helm init --service-account tiller \
+--tiller-image registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:<tag>
+```
+
+> **Note:** This`tiller`install has full cluster access, which should be acceptable if the cluster is dedicated to Rancher server. See the [Helm docs](https://docs.helm.sh/using_helm/#role-based-access-control) for instructions on restricting `tiller` access to suit your security requirements.
+
+### Test your Tiller installation
+
+Run the following command to verify the installation of `tiller` on your cluster:
+
+```
+kubectl -n kube-system  rollout status deploy/tiller-deploy
+Waiting for deployment "tiller-deploy" rollout to finish: 0 of 1 updated replicas are available...
+deployment "tiller-deploy" successfully rolled out
+```
+
+And run the following command to validate Helm can talk to the `tiller` service:
+
+```
+helm version
+Client: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
+Server: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
+```
+
+### Issues or errors?
+
+See the [Troubleshooting](troubleshooting.md) page.
+
+### [Next: Install Rancher](../helm-rancher/helm-rancher.md)
@@ -0,0 +1,22 @@
+---
+title: Troubleshooting
+---
+
+### Helm commands show forbidden
+
+When Helm is initiated in the cluster without specifying the correct `ServiceAccount`, the command `helm init` will succeed but you won't be able to execute most of the other `helm` commands. The following error will be shown:
+
+```
+Error: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "kube-system"
+```
+
+To resolve this, the server component (`tiller`) needs to be removed and added with the correct `ServiceAccount`. You can use `helm reset --force` to remove the `tiller` from the cluster. Please check if it is removed using `helm version --server`.
+
+```
+helm reset --force
+Tiller (the Helm server-side component) has been uninstalled from your Kubernetes Cluster.
+helm version --server
+Error: could not find tiller
+```
+
+When you have confirmed that `tiller` has been removed, please follow the steps provided in [Initialize Helm (Install tiller)](helm-init.md) to install `tiller` with the correct `ServiceAccount`.
@@ -48,13 +48,13 @@ title: Chart Options

 Enabling the [API Audit Log](../../enable-api-audit-log.md).

-You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools](../../../../../../pages-for-subheaders/cluster-logging.md) for the `System` Project on the Rancher server cluster.
+You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools](../../../../../../explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) for the `System` Project on the Rancher server cluster.

 ```plain
 --set auditLog.level=1
 ```

-By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`.  You can collect this log as you would any container log. When using the sidecar as the audit log destination, the `hostPath`, `maxAge`, `maxBackups`, and `maxSize` options do not apply. It's advised to use your OS or Docker daemon's log rotation features to control disk space use. Enable the [Logging service under Rancher Tools](../../../../../../pages-for-subheaders/cluster-logging.md/) for the Rancher server cluster or System Project.
+By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`.  You can collect this log as you would any container log. When using the sidecar as the audit log destination, the `hostPath`, `maxAge`, `maxBackups`, and `maxSize` options do not apply. It's advised to use your OS or Docker daemon's log rotation features to control disk space use. Enable the [Logging service under Rancher Tools](../../../../../../explanations/integrations-in-rancher/cluster-logging/cluster-logging.md/) for the Rancher server cluster or System Project.

 Set the `auditLog.destination` to `hostPath` to forward logs to volume shared with the host system instead of streaming to a sidecar container. When setting the destination to `hostPath` you may want to adjust the other auditLog parameters for log rotation.

@@ -142,7 +142,7 @@ kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-
 For details on installing Rancher with a private registry, see:

 - [Air Gap: Docker Install](../../../../../../reference-guides/installation-references/tls-settings.md)
- [Air Gap: Kubernetes Install](../../../../../../pages-for-subheaders/air-gap-helm2.md)
+- [Air Gap: Kubernetes Install](../../air-gap-helm2/air-gap-helm2.md)


 ### External TLS Termination
@@ -4,15 +4,15 @@ title: "4.  Install Rancher"

 Rancher installation is managed using the Helm package manager for Kubernetes.  Use `helm` to install the prerequisite and charts to install Rancher.

-For systems without direct internet access, see [Air Gap: Kubernetes install](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/air-gap-helm2/install-rancher.md).
+For systems without direct internet access, see [Air Gap: Kubernetes install](../../air-gap-helm2/install-rancher.md).

-Refer to the [Helm version requirements](../getting-started/installation-and-upgrade/resources/helm-version-requirements.md) to choose a version of Helm to install Rancher.
+Refer to the [Helm version requirements](../../../../resources/helm-version-requirements.md) to choose a version of Helm to install Rancher.

 > **Note:** The installation instructions assume you are using Helm 2. The instructions will be updated for Helm 3 soon. In the meantime, if you want to use Helm 3, refer to [these instructions.](https://github.com/ibrokethecloud/rancher-helm3)

 ### Add the Helm Chart Repository

-Use `helm repo add` command to add the Helm chart repository that contains charts to install Rancher. For more information about the repository choices and which is best for your use case, see [Choosing a Version of Rancher](../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md).
+Use `helm repo add` command to add the Helm chart repository that contains charts to install Rancher. For more information about the repository choices and which is best for your use case, see [Choosing a Version of Rancher](../../../../resources/choose-a-rancher-version.md).

 - Latest: Recommended for trying out the newest features
    ```
@@ -34,7 +34,7 @@ Rancher Server is designed to be secure by default and requires SSL/TLS configur

 There are three recommended options for the source of the certificate.

-> **Note:** If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm-rancher/chart-options.md#external-tls-termination).
+> **Note:** If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer](chart-options.md#external-tls-termination).

 | Configuration | Chart option | Description | Requires cert-manager |
 |-----|-----|-----|-----|
@@ -44,12 +44,12 @@ There are three recommended options for the source of the certificate.

 ### Optional: Install cert-manager

-**Note:** cert-manager is only required for certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) and Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`). You should skip this step if you are using your own certificate files (option `ingress.tls.source=secret`) or if you use [TLS termination on an External Load Balancer](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm-rancher/chart-options.md#external-tls-termination).
+**Note:** cert-manager is only required for certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) and Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`). You should skip this step if you are using your own certificate files (option `ingress.tls.source=secret`) or if you use [TLS termination on an External Load Balancer](chart-options.md#external-tls-termination).

 > **Important:**
 > Due to an issue with Helm v2.12.0 and cert-manager, please use Helm v2.12.1 or higher.

-> Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.12.0, please see our [upgrade documentation](../getting-started/installation-and-upgrade/resources/upgrade-cert-manager.md).
+> Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.12.0, please see our [upgrade documentation](../../../../resources/upgrade-cert-manager.md).

 Rancher relies on [cert-manager](https://github.com/jetstack/cert-manager) to issue certificates from Rancher's own generated CA or to request Let's Encrypt certificates.

@@ -166,7 +166,7 @@ deployment "rancher" successfully rolled out
 Create Kubernetes secrets from your own certificates for Rancher to use.


-> **Note:** The `Common Name` or a `Subject Alternative Names` entry in the server certificate must match the `hostname` option, or the ingress controller will fail to configure correctly. Although an entry in the `Subject Alternative Names` is technically required, having a matching `Common Name` maximizes compatibility with older browsers/applications. If you want to check if your certificates are correct, see [How do I check Common Name and Subject Alternative Names in my server certificate?](../faq/technical-items.md#how-do-i-check-common-name-and-subject-alternative-names-in-my-server-certificate)
+> **Note:** The `Common Name` or a `Subject Alternative Names` entry in the server certificate must match the `hostname` option, or the ingress controller will fail to configure correctly. Although an entry in the `Subject Alternative Names` is technically required, having a matching `Common Name` maximizes compatibility with older browsers/applications. If you want to check if your certificates are correct, see [How do I check Common Name and Subject Alternative Names in my server certificate?](../../../../../../faq/technical-items.md#how-do-i-check-common-name-and-subject-alternative-names-in-my-server-certificate)

 - Set `hostname` and set `ingress.tls.source` to `secret`.
 - If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
@@ -190,7 +190,7 @@ helm install rancher-<CHART_REPO>/rancher \
  --set privateCA=true
 ```

-Now that Rancher is deployed, see [Adding TLS Secrets](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm-rancher/tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them.
+Now that Rancher is deployed, see [Adding TLS Secrets](tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them.

 After adding the secrets, check if Rancher was rolled out successfully:

@@ -214,11 +214,11 @@ It should show the same count for `DESIRED` and `AVAILABLE`.

 The Rancher chart configuration has many options for customizing the install to suit your specific environment. Here are some common advanced scenarios.

-* [HTTP Proxy](../reference-guides/installation-references/helm-chart-options.md)
-* [Private Docker Image Registry](../reference-guides/installation-references/helm-chart-options.md#private-registry-and-air-gap-installs)
-* [TLS Termination on an External Load Balancer](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm-rancher/chart-options.md#external-tls-termination)
+* [HTTP Proxy](../../../../../../reference-guides/installation-references/helm-chart-options.md)
+* [Private Docker Image Registry](../../../../../../reference-guides/installation-references/helm-chart-options.md#private-registry-and-air-gap-installs)
+* [TLS Termination on an External Load Balancer](chart-options.md#external-tls-termination)

-See the [Chart Options](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm-rancher/chart-options.md) for the full list of options.
+See the [Chart Options](chart-options.md) for the full list of options.

 ### Save your options

@@ -228,4 +228,4 @@ Make sure you save the `--set` options you used. You will need to use the same o

 That's it you should have a functional Rancher server. Point a browser at the hostname you picked and you should be greeted by the colorful login page.

-Doesn't work? Take a look at the [Troubleshooting](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm-rancher/troubleshooting.md) Page
+Doesn't work? Take a look at the [Troubleshooting](troubleshooting.md) Page
@@ -0,0 +1,58 @@
+---
+title: Kubernetes Installation Using Helm 2
+---
+
+> After Helm 3 was released, the Rancher installation instructions were updated to use Helm 3.
+>
+> If you are using Helm 2, we recommend [migrating to Helm 3](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) because it is simpler to use and more secure than Helm 2.
+>
+> This section provides a copy of the older high-availability Kubernetes Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+
+For production environments, we recommend installing Rancher in a high-availability configuration so that your user base can always access Rancher Server. When installed in a Kubernetes cluster, Rancher will integrate with the cluster's etcd database and take advantage of Kubernetes scheduling for high-availability.
+
+This procedure walks you through setting up a 3-node cluster with Rancher Kubernetes Engine (RKE) and installing the Rancher chart with the Helm package manager.
+
+> **Important:** The Rancher management server can only be run on an RKE-managed Kubernetes cluster. Use of Rancher on hosted Kubernetes or other providers is not supported.
+
+> **Important:** For the best performance, we recommend a dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md) for running your workloads.
+
+## Recommended Architecture
+
+- DNS for Rancher should resolve to a Layer 4 load balancer (TCP)
+- The Load Balancer should forward port TCP/80 and TCP/443 to all 3 nodes in the Kubernetes cluster.
+- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
+- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
+
+<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
+
+![High-availability Kubernetes Install](/img/ha/rancher2ha.svg)
+<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
+
+## Required Tools
+
+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](https://rancher.com/docs/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. Refer to the [Helm version requirements](../../../resources/helm-version-requirements.md) to choose a version of Helm to install Rancher.
+
+## Installation Outline
+
+- [Create Nodes and Load Balancer](create-nodes-lb/create-nodes-lb.md)
+- [Install Kubernetes with RKE](kubernetes-rke/kubernetes-rke.md)
+- [Initialize Helm (tiller)](helm-init/helm-init.md)
+- [Install Rancher](helm-rancher/helm-rancher.md)
+
+## Additional Install Options
+
+- [Migrating from a Kubernetes Install with an RKE Add-on](../../../install-upgrade-on-a-kubernetes-cluster/upgrades/migrating-from-rke-add-on.md)
+
+## Previous Methods
+
+[RKE add-on install](rke-add-on/rke-add-on.md)
+
+> **Important: RKE add-on install is only supported up to Rancher v2.0.8**
+>
+> Please use the Rancher Helm chart to install Rancher on a Kubernetes cluster. For details, see the [Kubernetes Install ](../../../resources/helm-version-requirements.md).
+>
+> If you are currently using the RKE add-on install method, see [Migrating from a Kubernetes Install with an RKE Add-on](../../../install-upgrade-on-a-kubernetes-cluster/upgrades/migrating-from-rke-add-on.md) for details on how to move to using the Helm chart.
@@ -0,0 +1,131 @@
+---
+title: "2. Install Kubernetes with RKE"
+---
+
+Use RKE to install Kubernetes with a high availability etcd configuration.
+
+>**Note:** For systems without direct internet access see [Air Gap: Kubernetes install](../../air-gap-helm2/air-gap-helm2.md) for install details.
+
+### Create the `rancher-cluster.yml` File
+
+Using the sample below create the `rancher-cluster.yml` file. Replace the IP Addresses in the `nodes` list with the IP address or DNS names of the 3 nodes you created.
+
+> **Note:**  If your node has public and internal addresses, it is recommended to set the `internal_address:` so Kubernetes will use it for intra-cluster communication.  Some services like AWS EC2 require setting the `internal_address:` if you want to use self-referencing security groups or firewalls.
+
+
+```yaml
+nodes:
+  - address: 165.227.114.63
+    internal_address: 172.16.22.12
+    user: ubuntu
+    role: [controlplane,worker,etcd]
+  - address: 165.227.116.167
+    internal_address: 172.16.32.37
+    user: ubuntu
+    role: [controlplane,worker,etcd]
+  - address: 165.227.127.226
+    internal_address: 172.16.42.73
+    user: ubuntu
+    role: [controlplane,worker,etcd]
+
+services:
+  etcd:
+    snapshot: true
+    creation: 6h
+    retention: 24h
+```
+
+#### Common RKE Nodes Options
+
+| Option | Required | Description |
+| --- | --- | --- |
+| `address` | yes | The public DNS or IP address |
+| `user` | yes | A user that can run docker commands |
+| `role` | yes | List of Kubernetes roles assigned to the node |
+| `internal_address` | no | The private DNS or IP address for internal cluster traffic |
+| `ssh_key_path` | no | Path to SSH private key used to authenticate to the node (defaults to `~/.ssh/id_rsa`) |
+
+#### Advanced Configurations
+
+RKE has many configuration options for customizing the install to suit your specific environment.
+
+Please see the [RKE Documentation](https://rancher.com/docs/rke/latest/en/config-options/) for the full list of options and capabilities.
+
+For tuning your etcd cluster for larger Rancher installations see the [etcd settings guide](../../tune-etcd-for-large-installs.md).
+
+### Run RKE
+
+```
+rke up --config ./rancher-cluster.yml
+```
+
+When finished, it should end with the line: `Finished building Kubernetes cluster successfully`.
+
+### Testing Your Cluster
+
+RKE should have created a file `kube_config_rancher-cluster.yml`. This file has the credentials for `kubectl` and `helm`.
+
+> **Note:** If you have used a different file name from `rancher-cluster.yml`, then the kube config file will be named `kube_config_<FILE_NAME>.yml`.
+
+You can copy this file to `$HOME/.kube/config` or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_rancher-cluster.yml`.
+
+```
+export KUBECONFIG=$(pwd)/kube_config_rancher-cluster.yml
+```
+
+Test your connectivity with `kubectl` and see if all your nodes are in `Ready` state.
+
+```
+kubectl get nodes
+
+NAME                          STATUS    ROLES                      AGE       VERSION
+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
+
+Check that all the required pods and containers are healthy are ready to continue.
+
+* Pods are in `Running` or `Completed` state.
+* `READY` column shows all the containers are running (i.e. `3/3`) for pods with `STATUS` `Running`
+* Pods with `STATUS` `Completed` are run-once Jobs. For these pods `READY` should be `0/1`.
+
+```
+kubectl get pods --all-namespaces
+
+NAMESPACE       NAME                                      READY     STATUS      RESTARTS   AGE
+ingress-nginx   nginx-ingress-controller-tnsn4            1/1       Running     0          30s
+ingress-nginx   nginx-ingress-controller-tw2ht            1/1       Running     0          30s
+ingress-nginx   nginx-ingress-controller-v874b            1/1       Running     0          30s
+kube-system     canal-jp4hz                               3/3       Running     0          30s
+kube-system     canal-z2hg8                               3/3       Running     0          30s
+kube-system     canal-z6kpw                               3/3       Running     0          30s
+kube-system     kube-dns-7588d5b5f5-sf4vh                 3/3       Running     0          30s
+kube-system     kube-dns-autoscaler-5db9bbb766-jz2k6      1/1       Running     0          30s
+kube-system     metrics-server-97bc649d5-4rl2q            1/1       Running     0          30s
+kube-system     rke-ingress-controller-deploy-job-bhzgm   0/1       Completed   0          30s
+kube-system     rke-kubedns-addon-deploy-job-gl7t4        0/1       Completed   0          30s
+kube-system     rke-metrics-addon-deploy-job-7ljkc        0/1       Completed   0          30s
+kube-system     rke-network-plugin-deploy-job-6pbgj       0/1       Completed   0          30s
+```
+
+### 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](https://rancher.com/docs/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](https://rancher.com/docs/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._
+
+> **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
+
+### Issues or errors?
+
+See the [Troubleshooting](troubleshooting.md) page.
+
+### [Next: Initialize Helm (Install tiller)](../helm-init/helm-init.md)
@@ -0,0 +1,380 @@
+---
+title: Kubernetes Install with External Load Balancer (TCP/Layer 4)
+---
+import SslFaqHa from '@site/src/components/SslFaqHa'
+
+> #### **Important: RKE add-on install is only supported up to Rancher v2.0.8**
+>
+>Please use the Rancher Helm chart to install Rancher on a Kubernetes cluster. For details, see the [Kubernetes Install ](../../../../../resources/helm-version-requirements.md).
+>
+>If you are currently using the RKE add-on install method, see [Migrating from a High-availability Kubernetes install with an RKE add-on](../../../../../install-upgrade-on-a-kubernetes-cluster/upgrades/migrating-from-rke-add-on.md) for details on how to move to using the Helm chart.
+
+This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on:
+
+- Layer 4 load balancer (TCP)
+- [NGINX ingress controller with SSL termination (HTTPS)](https://kubernetes.github.io/ingress-nginx/)
+
+In a Kubernetes setup that uses a layer 4 load balancer, the load balancer accepts Rancher client connections over the TCP/UDP protocols (i.e., the transport level). The load balancer then forwards these connections to individual cluster nodes without reading the request itself. Because the load balancer cannot read the packets it's forwarding, the routing decisions it can make are limited.
+
+<sup>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</sup>
+
+![High-availability Kubernetes installation of Rancher](/img/ha/rancher2ha.svg)
+
+<br/>
+
+## 1. Provision Linux Hosts
+
+Provision three Linux hosts according to our [Requirements](../../../../../installation-requirements/installation-requirements.md).
+
+## 2. Configure Load Balancer
+
+We will be using NGINX as our Layer 4 Load Balancer (TCP). NGINX will forward all connections to one of your Rancher nodes. If you want to use Amazon NLB, you can skip this step and use [Amazon NLB configuration](nlb.md)
+
+>**Note:**
+> In this configuration, the load balancer is positioned in front of your Linux hosts. The load balancer can be any host that you have available that's capable of running NGINX.
+>
+>One caveat: do not use one of your Rancher nodes as the load balancer.
+
+### A. Install NGINX
+
+Start by installing NGINX on your load balancer host. NGINX has packages available for all known operating systems. For help installing NGINX, refer to their [install documentation](https://www.nginx.com/resources/wiki/start/topics/tutorials/install/).
+
+The `stream` module is required, which is present when using the official NGINX packages. Please refer to your OS documentation how to install and enable the NGINX `stream` module on your operating system.
+
+### B. Create NGINX Configuration
+
+After installing NGINX, you need to update the NGINX config file, `nginx.conf`, with the IP addresses for your nodes.
+
+1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`.
+
+2. From `nginx.conf`, replace `IP_NODE_1`, `IP_NODE_2`, and `IP_NODE_3` with the IPs of your [Linux hosts](#1-provision-linux-hosts).
+
+    >**Note:** This Nginx configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/).
+
+    **Example NGINX config:**
+    ```
+    worker_processes 4;
+    worker_rlimit_nofile 40000;
+
+    events {
+        worker_connections 8192;
+    }
+
+    http {
+        server {
+            listen         80;
+            return 301 https://$host$request_uri;
+        }
+    }
+
+    stream {
+        upstream rancher_servers {
+            least_conn;
+            server IP_NODE_1:443 max_fails=3 fail_timeout=5s;
+            server IP_NODE_2:443 max_fails=3 fail_timeout=5s;
+            server IP_NODE_3:443 max_fails=3 fail_timeout=5s;
+        }
+        server {
+            listen     443;
+            proxy_pass rancher_servers;
+        }
+    }
+    ```
+
+3. Save `nginx.conf` to your load balancer at the following path: `/etc/nginx/nginx.conf`.
+
+4. Load the updates to your NGINX configuration by running the following command:
+
+    ```
+    # nginx -s reload
+    ```
+
+### Option - Run NGINX as Docker container
+
+Instead of installing NGINX as a package on the operating system, you can rather run it as a Docker container. Save the edited **Example NGINX config** as `/etc/nginx.conf` and run the following command to launch the NGINX container:
+
+```
+docker run -d --restart=unless-stopped \
+  -p 80:80 -p 443:443 \
+  -v /etc/nginx.conf:/etc/nginx/nginx.conf \
+  nginx:1.14
+```
+
+## 3. Configure DNS
+
+Choose a fully qualified domain name (FQDN) that you want to use to access Rancher (e.g., `rancher.yourdomain.com`).<br/><br/>
+
+1. Log into your DNS server a create a `DNS A` record that points to the IP address of your [load balancer](#2-configure-load-balancer).
+
+2. Validate that the `DNS A` is working correctly. Run the following command from any terminal, replacing `HOSTNAME.DOMAIN.COM` with your chosen FQDN:
+
+    `nslookup HOSTNAME.DOMAIN.COM`
+
+    **Step Result:** Terminal displays output similar to the following:
+
+    ```
+    $ nslookup rancher.yourdomain.com
+    Server:         YOUR_HOSTNAME_IP_ADDRESS
+    Address:        YOUR_HOSTNAME_IP_ADDRESS#53
+
+    Non-authoritative answer:
+    Name:   rancher.yourdomain.com
+    Address: HOSTNAME.DOMAIN.COM
+    ```
+
+<br/>
+
+## 4. Install RKE
+
+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](https://rancher.com/docs/rke/latest/en/installation) instructions.
+
+2. Confirm that RKE is now executable by running the following command:
+
+    ```
+    rke --version
+    ```
+
+## 5. Download RKE Config File Template
+
+RKE uses a `.yml` config file to install and configure your Kubernetes cluster. There are 2 templates to choose from, depending on the SSL certificate you want to use.
+
+1. Download one of following templates, depending on the SSL certificate you're using.
+
+    - [Template for self-signed certificate<br/> `3-node-certificate.yml`](../../../cluster-yml-templates/node-certificate.md)
+    - [Template for certificate signed by recognized CA<br/> `3-node-certificate-recognizedca.yml`](../../../cluster-yml-templates/node-certificate-recognizedca.md)
+
+    >**Advanced Config Options:**
+    >
+    >- Want records of all transactions with the Rancher API? Enable the [API Auditing](../../../enable-api-audit-log.md) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file](../api-auditing.md).
+    >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options](https://rancher.com/docs/rke/latest/en/config-options/).
+
+
+2. Rename the file to `rancher-cluster.yml`.
+
+## 6. Configure Nodes
+
+Once you have the `rancher-cluster.yml` config file template, edit the nodes section to point toward your Linux hosts.
+
+1. Open `rancher-cluster.yml` in your favorite text editor.
+
+1. Update the `nodes` section with the information of your [Linux hosts](#1-provision-linux-hosts).
+
+    For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docker 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](https://rancher.com/docs/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) >for RHEL/CentOS specific requirements.
+
+        nodes:
+            # The IP address or hostname of the node
+        - address: IP_ADDRESS_1
+            # User that can login to the node and has access to the Docker socket (i.e. can execute `docker ps` on the node)
+            # When using RHEL/CentOS, this can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565
+            user: USER
+            role: [controlplane,etcd,worker]
+            # Path the SSH key that can be used to access to node with the specified user
+            ssh_key_path: ~/.ssh/id_rsa
+        - address: IP_ADDRESS_2
+            user: USER
+            role: [controlplane,etcd,worker]
+            ssh_key_path: ~/.ssh/id_rsa
+        - address: IP_ADDRESS_3
+            user: USER
+            role: [controlplane,etcd,worker]
+            ssh_key_path: ~/.ssh/id_rsa
+
+1. **Optional:** By default, `rancher-cluster.yml` is configured to take backup snapshots of your data. To disable these snapshots, change the `backup` directive setting to `false`, as depicted below.
+
+        services:
+          etcd:
+            backup: false
+
+
+## 7. Configure Certificates
+
+For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
+
+Choose from the following options:
+
+<details id="option-a">
+  <summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
+
+>**Prerequisites:**
+>Create a self-signed certificate.
+>
+>- The certificate files must be in PEM format.
+>- The certificate files must be encoded in [base64](#base64).
+>- In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates.
+
+1. In `kind: Secret` with `name: cattle-keys-ingress`:
+
+    * Replace `<BASE64_CRT>` with the base64 encoded string of the Certificate file (usually called `cert.pem` or `domain.crt`)
+    * Replace `<BASE64_KEY>` with the base64 encoded string of the Certificate Key file (usually called `key.pem` or `domain.key`)
+
+    >**Note:**
+    > The base64 encoded string should be on the same line as `tls.crt` or `tls.key`, without any newline at the beginning, in between or at the end.
+
+    **Step Result:** After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
+
+    ```yaml
+    ---
+    apiVersion: v1
+    kind: Secret
+    metadata:
+        name: cattle-keys-ingress
+        namespace: cattle-system
+    type: Opaque
+    data:
+        tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1RENDQWN5Z0F3SUJBZ0lKQUlHc25NeG1LeGxLTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NVGd3TlRBMk1qRXdOREE1V2hjTk1UZ3dOekExTWpFd05EQTVXakFXTVJRdwpFZ1lEVlFRRERBdG9ZUzV5Ym1Ob2NpNXViRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DCmdnRUJBTFJlMXdzekZSb2Rib2pZV05DSHA3UkdJaUVIMENDZ1F2MmdMRXNkUUNKZlcrUFEvVjM0NnQ3bSs3TFEKZXJaV3ZZMWpuY2VuWU5JSGRBU0VnU0ducWExYnhUSU9FaE0zQXpib3B0WDhjSW1OSGZoQlZETGdiTEYzUk0xaQpPM1JLTGdIS2tYSTMxZndjbU9zWGUwaElYQnpUbmxnM20vUzlXL3NTc0l1dDVwNENDUWV3TWlpWFhuUElKb21lCmpkS3VjSHFnMTlzd0YvcGVUalZrcVpuMkJHazZRaWFpMU41bldRV0pjcThTenZxTTViZElDaWlwYU9hWWQ3RFEKYWRTejV5dlF0YkxQNW4wTXpnOU43S3pGcEpvUys5QWdkWDI5cmZqV2JSekp3RzM5R3dRemN6VWtLcnZEb05JaQo0UFJHc01yclFNVXFSYjRSajNQOEJodEMxWXNDQXdFQUFhTTVNRGN3Q1FZRFZSMFRCQUl3QURBTEJnTlZIUThFCkJBTUNCZUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdJR0NDc0dBUVVGQndNQk1BMEdDU3FHU0liM0RRRUIKQ3dVQUE0SUJBUUNKZm5PWlFLWkowTFliOGNWUW5Vdi9NZkRZVEJIQ0pZcGM4MmgzUGlXWElMQk1jWDhQRC93MgpoOUExNkE4NGNxODJuQXEvaFZYYy9JNG9yaFY5WW9jSEg5UlcvbGthTUQ2VEJVR0Q1U1k4S292MHpHQ1ROaDZ6Ci9wZTNqTC9uU0pYSjRtQm51czJheHFtWnIvM3hhaWpYZG9kMmd3eGVhTklvRjNLbHB2aGU3ZjRBNmpsQTM0MmkKVVlCZ09iN1F5KytRZWd4U1diSmdoSzg1MmUvUUhnU2FVSkN6NW1sNGc1WndnNnBTUXhySUhCNkcvREc4dElSYwprZDMxSk1qY25Fb1Rhc1Jyc1NwVmNGdXZyQXlXN2liakZyYzhienBNcE1obDVwYUZRcEZzMnIwaXpZekhwakFsCk5ZR2I2OHJHcjBwQkp3YU5DS2ErbCtLRTk4M3A3NDYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
+        tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
+    ```
+
+2. In `kind: Secret` with `name: cattle-keys-server`, replace `<BASE64_CA>` with the base64 encoded string of the CA Certificate file (usually called `ca.pem` or `ca.crt`).
+
+    >**Note:**
+    > The base64 encoded string should be on the same line as `cacerts.pem`, without any newline at the beginning, in between or at the end.
+
+
+    **Step Result:** The file should look like the example below (the base64 encoded string should be different):
+
+    ```yaml
+    ---
+    apiVersion: v1
+    kind: Secret
+    metadata:
+      name: cattle-keys-server
+      namespace: cattle-system
+    type: Opaque
+    data:
+      cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
+    ```
+
+</details>
+
+<details id="option-b">
+  <summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
+
+If you are using a Certificate Signed By A Recognized Certificate Authority, you will need to generate a base64 encoded string for the Certificate file and the Certificate Key file. Make sure that your certificate file includes all the intermediate certificates in the chain, the order of certificates in this case is first your own certificate, followed by the intermediates. Please refer to the documentation of your CSP (Certificate Service Provider) to see what intermediate certificate(s) need to be included.
+
+In the `kind: Secret` with `name: cattle-keys-ingress`:
+
+* Replace `<BASE64_CRT>` with the base64 encoded string of the Certificate file (usually called `cert.pem` or `domain.crt`)
+* Replace `<BASE64_KEY>` with the base64 encoded string of the Certificate Key file (usually called `key.pem` or `domain.key`)
+
+After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
+
+>**Note:**
+> The base64 encoded string should be on the same line as `tls.crt` or `tls.key`, without any newline at the beginning, in between or at the end.
+
+```yaml
+---
+apiVersion: v1
+kind: Secret
+metadata:
+  name: cattle-keys-ingress
+  namespace: cattle-system
+type: Opaque
+data:
+  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1RENDQWN5Z0F3SUJBZ0lKQUlHc25NeG1LeGxLTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NVGd3TlRBMk1qRXdOREE1V2hjTk1UZ3dOekExTWpFd05EQTVXakFXTVJRdwpFZ1lEVlFRRERBdG9ZUzV5Ym1Ob2NpNXViRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DCmdnRUJBTFJlMXdzekZSb2Rib2pZV05DSHA3UkdJaUVIMENDZ1F2MmdMRXNkUUNKZlcrUFEvVjM0NnQ3bSs3TFEKZXJaV3ZZMWpuY2VuWU5JSGRBU0VnU0ducWExYnhUSU9FaE0zQXpib3B0WDhjSW1OSGZoQlZETGdiTEYzUk0xaQpPM1JLTGdIS2tYSTMxZndjbU9zWGUwaElYQnpUbmxnM20vUzlXL3NTc0l1dDVwNENDUWV3TWlpWFhuUElKb21lCmpkS3VjSHFnMTlzd0YvcGVUalZrcVpuMkJHazZRaWFpMU41bldRV0pjcThTenZxTTViZElDaWlwYU9hWWQ3RFEKYWRTejV5dlF0YkxQNW4wTXpnOU43S3pGcEpvUys5QWdkWDI5cmZqV2JSekp3RzM5R3dRemN6VWtLcnZEb05JaQo0UFJHc01yclFNVXFSYjRSajNQOEJodEMxWXNDQXdFQUFhTTVNRGN3Q1FZRFZSMFRCQUl3QURBTEJnTlZIUThFCkJBTUNCZUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdJR0NDc0dBUVVGQndNQk1BMEdDU3FHU0liM0RRRUIKQ3dVQUE0SUJBUUNKZm5PWlFLWkowTFliOGNWUW5Vdi9NZkRZVEJIQ0pZcGM4MmgzUGlXWElMQk1jWDhQRC93MgpoOUExNkE4NGNxODJuQXEvaFZYYy9JNG9yaFY5WW9jSEg5UlcvbGthTUQ2VEJVR0Q1U1k4S292MHpHQ1ROaDZ6Ci9wZTNqTC9uU0pYSjRtQm51czJheHFtWnIvM3hhaWpYZG9kMmd3eGVhTklvRjNLbHB2aGU3ZjRBNmpsQTM0MmkKVVlCZ09iN1F5KytRZWd4U1diSmdoSzg1MmUvUUhnU2FVSkN6NW1sNGc1WndnNnBTUXhySUhCNkcvREc4dElSYwprZDMxSk1qY25Fb1Rhc1Jyc1NwVmNGdXZyQXlXN2liakZyYzhienBNcE1obDVwYUZRcEZzMnIwaXpZekhwakFsCk5ZR2I2OHJHcjBwQkp3YU5DS2ErbCtLRTk4M3A3NDYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
+  tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
+```
+
+</details>
+
+
+
+## 8. Configure FQDN
+
+There are two references to `<FQDN>` in the config file (one in this step and one in the next). Both need to be replaced with the FQDN chosen in [Configure DNS](#3-configure-dns).
+
+In the `kind: Ingress` with `name: cattle-ingress-http`:
+
+* Replace `<FQDN>` with the FQDN chosen in [Configure DNS](#3-configure-dns).
+
+After replacing `<FQDN>` with the FQDN chosen in [Configure DNS](#3-configure-dns), the file should look like the example below (`rancher.yourdomain.com` is the FQDN used in this example):
+
+```yaml
+ ---
+  apiVersion: extensions/v1beta1
+  kind: Ingress
+  metadata:
+    namespace: cattle-system
+    name: cattle-ingress-http
+    annotations:
+      nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
+      nginx.ingress.kubernetes.io/proxy-read-timeout: "1800"   # Max time in seconds for ws to remain shell window open
+      nginx.ingress.kubernetes.io/proxy-send-timeout: "1800"   # Max time in seconds for ws to remain shell window open
+  spec:
+    rules:
+    - host: rancher.yourdomain.com
+      http:
+        paths:
+        - backend:
+            serviceName: cattle-service
+            servicePort: 80
+    tls:
+    - secretName: cattle-keys-ingress
+      hosts:
+      - rancher.yourdomain.com
+```
+
+Save the `.yml` file and close it.
+
+## 9. Configure Rancher version
+
+The last reference that needs to be replaced is `<RANCHER_VERSION>`. This needs to be replaced with a Rancher version which is marked as stable. The latest stable release of Rancher can be found in the [GitHub README](https://github.com/rancher/rancher/blob/master/README.md). Make sure the version is an actual version number, and not a named tag like `stable` or `latest`. The example below shows the version configured to `v2.0.6`.
+
+```
+      spec:
+        serviceAccountName: cattle-admin
+        containers:
+        - image: rancher/rancher:v2.0.6
+          imagePullPolicy: Always
+```
+
+## 10. Back Up Your RKE Config File
+
+After you close your `.yml` file, back it up to a secure location. You can use this file again when it's time to upgrade Rancher.
+
+## 11. Run RKE
+
+With all configuration in place, use RKE to launch Rancher. You can complete this action by running the `rke up` command and using the `--config` parameter to point toward your config file.
+
+1. From your workstation, make sure `rancher-cluster.yml` and the downloaded `rke` binary are in the same directory.
+
+2. Open a Terminal instance. Change to the directory that contains your config file and `rke`.
+
+3. Enter one of the `rke up` commands listen below.
+
+```
+rke up --config rancher-cluster.yml
+```
+
+**Step Result:** The output should be similar to the snippet below:
+
+```
+INFO[0000] Building Kubernetes cluster
+INFO[0000] [dialer] Setup tunnel for host [1.1.1.1]
+INFO[0000] [network] Deploying port listener containers
+INFO[0000] [network] Pulling image [alpine:latest] on host [1.1.1.1]
+...
+INFO[0101] Finished building Kubernetes cluster successfully
+```
+
+## 12. Back Up Auto-Generated Config File
+
+During installation, RKE automatically generates a config file named `kube_config_rancher-cluster.yml` in the same directory as the RKE binary. Copy this file and back it up to a safe location. You'll use this file later when upgrading Rancher Server.
+
+## What's Next?
+
+You have a couple of options:
+
+- Create a backup of your Rancher Server in case of a disaster scenario: [High Availability Back Up and Restore](../../../../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/backup-restore-and-disaster-recovery.md).
+- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters](../../../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md).
+
+<br/>
+
+## FAQ and Troubleshooting
+
+<SslFaqHa/>
@@ -0,0 +1,270 @@
+---
+title: Kubernetes Install with External Load Balancer (HTTPS/Layer 7)
+---
+import SslFaqHa from '@site/src/components/SslFaqHa'
+
+> #### **Important: RKE add-on install is only supported up to Rancher v2.0.8**
+>
+>Please use the Rancher Helm chart to install Rancher on a Kubernetes cluster. For details, see the [Kubernetes Install ](../../../../../resources/helm-version-requirements.md).
+>
+>If you are currently using the RKE add-on install method, see [Migrating from a Kubernetes Install with an RKE Add-on](../../../../../install-upgrade-on-a-kubernetes-cluster/upgrades/migrating-from-rke-add-on.md) for details on how to move to using the Helm chart.
+
+This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on:
+
+- Layer 7 Loadbalancer with SSL termination (HTTPS)
+- [NGINX Ingress controller (HTTP)](https://kubernetes.github.io/ingress-nginx/)
+
+In an Kubernetes setup that uses a layer 7 load balancer, the load balancer accepts Rancher client connections over the HTTP protocol (i.e., the application level). This application-level access allows the load balancer to read client requests and then redirect to them to cluster nodes using logic that optimally distributes load.
+
+<sup>Kubernetes Rancher install with layer 7 load balancer, depicting SSL termination at load balancer</sup>
+
+![Rancher HA](/img/ha/rancher2ha-l7.svg)
+
+## 1. Provision Linux Hosts
+
+Provision three Linux hosts according to our [Requirements](../../../../../installation-requirements/installation-requirements.md).
+
+## 2. Configure Load Balancer
+
+When using a load balancer in front of Rancher, there's no need for the container to redirect port communication from port 80 or port 443. By passing the header `X-Forwarded-Proto: https`, this redirect is disabled. This is the expected configuration when terminating SSL externally.
+
+The load balancer has to be configured to support the following:
+
+* **WebSocket** connections
+* **SPDY** / **HTTP/2** protocols
+* Passing / setting the following headers:
+
+| Header              | Value                                  | Description                                                                                                                                                              |
+|---------------------|----------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `Host`              | FQDN used to reach Rancher. | To identify the server requested by the client.                                                                                                                           |
+| `X-Forwarded-Proto` | `https`                                | To identify the protocol that a client used to connect to the load balancer.<br /><br/>**Note:** If this header is present, `rancher/rancher` does not redirect HTTP to HTTPS. |
+| `X-Forwarded-Port`  | Port used to reach Rancher.             | To identify the protocol that client used to connect to the load balancer.                                                                                       |
+| `X-Forwarded-For`   | IP of the client connection.            | To identify the originating IP address of a client.                                                                                                                       |
+
+Health checks can be executed on the `/healthz` endpoint of the node, this will return HTTP 200.
+
+We have example configurations for the following load balancers:
+
+* [Amazon ALB configuration](alb.md)
+* [NGINX configuration](nginx.md)
+
+## 3. Configure DNS
+
+Choose a fully qualified domain name (FQDN) that you want to use to access Rancher (e.g., `rancher.yourdomain.com`).<br/><br/>
+
+1. Log into your DNS server a create a `DNS A` record that points to the IP address of your [load balancer](#2-configure-load-balancer).
+
+2. Validate that the `DNS A` is working correctly. Run the following command from any terminal, replacing `HOSTNAME.DOMAIN.COM` with your chosen FQDN:
+
+    `nslookup HOSTNAME.DOMAIN.COM`
+
+    **Step Result:** Terminal displays output similar to the following:
+
+    ```
+    $ nslookup rancher.yourdomain.com
+    Server:         YOUR_HOSTNAME_IP_ADDRESS
+    Address:        YOUR_HOSTNAME_IP_ADDRESS#53
+
+    Non-authoritative answer:
+    Name:   rancher.yourdomain.com
+    Address: HOSTNAME.DOMAIN.COM
+    ```
+
+<br/>
+
+## 4. Install RKE
+
+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](https://rancher.com/docs/rke/latest/en/installation) instructions.
+
+2. Confirm that RKE is now executable by running the following command:
+
+    ```
+    rke --version
+    ```
+
+## 5. Download RKE Config File Template
+
+RKE uses a YAML config file to install and configure your Kubernetes cluster. There are 2 templates to choose from, depending on the SSL certificate you want to use.
+
+1. Download one of following templates, depending on the SSL certificate you're using.
+
+    - [Template for self-signed certificate<br/> `3-node-externalssl-certificate.yml`](../../../cluster-yml-templates/node-externalssl-certificate.md)
+    - [Template for certificate signed by recognized CA<br/> `3-node-externalssl-recognizedca.yml`](../../../cluster-yml-templates/node-externalssl-recognizedca.md)
+
+    >**Advanced Config Options:**
+    >
+    >- Want records of all transactions with the Rancher API? Enable the [API Auditing](../../../enable-api-audit-log.md) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file](../api-auditing.md).
+    >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options](https://rancher.com/docs/rke/latest/en/config-options/).
+
+
+2. Rename the file to `rancher-cluster.yml`.
+
+## 6. Configure Nodes
+
+Once you have the `rancher-cluster.yml` config file template, edit the nodes section to point toward your Linux hosts.
+
+1. Open `rancher-cluster.yml` in your favorite text editor.
+
+1. Update the `nodes` section with the information of your [Linux hosts](#1-provision-linux-hosts).
+
+    For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docker 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](https://rancher.com/docs/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
+
+        nodes:
+            # The IP address or hostname of the node
+        - address: IP_ADDRESS_1
+            # User that can login to the node and has access to the Docker socket (i.e. can execute `docker ps` on the node)
+            # When using RHEL/CentOS, this can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565
+            user: USER
+            role: [controlplane,etcd,worker]
+            # Path the SSH key that can be used to access to node with the specified user
+            ssh_key_path: ~/.ssh/id_rsa
+        - address: IP_ADDRESS_2
+            user: USER
+            role: [controlplane,etcd,worker]
+            ssh_key_path: ~/.ssh/id_rsa
+        - address: IP_ADDRESS_3
+            user: USER
+            role: [controlplane,etcd,worker]
+            ssh_key_path: ~/.ssh/id_rsa
+
+1. **Optional:** By default, `rancher-cluster.yml` is configured to take backup snapshots of your data. To disable these snapshots, change the `backup` directive setting to `false`, as depicted below.
+
+        services:
+          etcd:
+            backup: false
+
+## 7. Configure Certificates
+
+For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
+
+Choose from the following options:
+
+<details id="option-a">
+  <summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
+
+>**Prerequisites:**
+>Create a self-signed certificate.
+>
+>- The certificate files must be in PEM format.
+>- The certificate files must be encoded in base64.
+>- In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.](../../../../../other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)
+
+In `kind: Secret` with `name: cattle-keys-ingress`, replace `<BASE64_CA>` with the base64 encoded string of the CA Certificate file (usually called `ca.pem` or `ca.crt`)
+
+>**Note:** The base64 encoded string should be on the same line as `cacerts.pem`, without any newline at the beginning, in between or at the end.
+
+After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
+
+        ---
+        apiVersion: v1
+        kind: Secret
+        metadata:
+            name: cattle-keys-server
+            namespace: cattle-system
+        type: Opaque
+        data:
+            cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
+
+</details>
+<details id="option-b">
+  <summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
+
+If you are using a Certificate Signed By A Recognized Certificate Authority, you don't need to perform any step in this part.
+</details>
+
+## 8. Configure FQDN
+
+There is one reference to `<FQDN>` in the RKE config file. Replace this reference with the FQDN you chose in [3. Configure DNS](#3-configure-dns).
+
+1. Open `rancher-cluster.yml`.
+
+2. In the `kind: Ingress` with `name: cattle-ingress-http:`
+
+    Replace `<FQDN>` with the FQDN chosen in [3. Configure DNS](#3-configure-dns).
+
+    **Step Result:** After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
+
+    ```
+    apiVersion: extensions/v1beta1
+      kind: Ingress
+      metadata:
+        namespace: cattle-system
+        name: cattle-ingress-http
+        annotations:
+          nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
+          nginx.ingress.kubernetes.io/proxy-read-timeout: "1800"   # Max time in seconds for ws to remain shell window open
+          nginx.ingress.kubernetes.io/proxy-send-timeout: "1800"   # Max time in seconds for ws to remain shell window open
+      spec:
+        rules:
+        - host: rancher.yourdomain.com
+          http:
+            paths:
+            - backend:
+                serviceName: cattle-service
+                servicePort: 80
+    ```
+
+
+3. Save the file and close it.
+
+## 9. Configure Rancher version
+
+The last reference that needs to be replaced is `<RANCHER_VERSION>`. This needs to be replaced with a Rancher version which is marked as stable. The latest stable release of Rancher can be found in the [GitHub README](https://github.com/rancher/rancher/blob/master/README.md). Make sure the version is an actual version number, and not a named tag like `stable` or `latest`. The example below shows the version configured to `v2.0.6`.
+
+```
+      spec:
+        serviceAccountName: cattle-admin
+        containers:
+        - image: rancher/rancher:v2.0.6
+          imagePullPolicy: Always
+```
+
+## 10. Back Up Your RKE Config File
+
+After you close your RKE config file, `rancher-cluster.yml`, back it up to a secure location. You can use this file again when it's time to upgrade Rancher.
+
+## 11. Run RKE
+
+With all configuration in place, use RKE to launch Rancher. You can complete this action by running the `rke up` command and using the `--config` parameter to point toward your config file.
+
+1. From your workstation, make sure `rancher-cluster.yml` and the downloaded `rke` binary are in the same directory.
+
+2. Open a Terminal instance. Change to the directory that contains your config file and `rke`.
+
+3. Enter one of the `rke up` commands listen below.
+
+    ```
+    rke up --config rancher-cluster.yml
+    ```
+
+    **Step Result:** The output should be similar to the snippet below:
+
+    ```
+    INFO[0000] Building Kubernetes cluster
+    INFO[0000] [dialer] Setup tunnel for host [1.1.1.1]
+    INFO[0000] [network] Deploying port listener containers
+    INFO[0000] [network] Pulling image [alpine:latest] on host [1.1.1.1]
+    ...
+    INFO[0101] Finished building Kubernetes cluster successfully
+    ```
+
+## 12. Back Up Auto-Generated Config File
+
+During installation, RKE automatically generates a config file named `kube_config_rancher-cluster.yml` in the same directory as the `rancher-cluster.yml` file. Copy this file and back it up to a safe location. You'll use this file later when upgrading Rancher Server.
+
+## What's Next?
+
+- **Recommended:** Review [Creating Backups—High Availability Back Up and Restore](../../../../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md) to learn how to backup your Rancher Server in case of a disaster scenario.
+- Create a Kubernetes cluster: [Creating a Cluster](../../../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md).
+
+<br/>
+
+## FAQ and Troubleshooting
+
+<SslFaqHa/>
@@ -24,8 +24,8 @@ NO_PROXY                  | Network address(es), network address range(s) and do

 When using Kubernetes installation, the environment variables need to be added to the RKE Config File template.

-* [Kubernetes Installation with External Load Balancer (TCP/Layer 4) RKE Config File Template](../../../../../../pages-for-subheaders/helm2-rke-add-on-layer-4-lb.md#5-download-rke-config-file-template)
-* [Kubernetes Installation with External Load Balancer (HTTPS/Layer 7) RKE Config File Template](../../../../../../pages-for-subheaders/helm2-rke-add-on-layer-7-lb.md#5-download-rke-config-file-template)
+* [Kubernetes Installation with External Load Balancer (TCP/Layer 4) RKE Config File Template](layer-4-lb/layer-4-lb.md#5-download-rke-config-file-template)
+* [Kubernetes Installation with External Load Balancer (HTTPS/Layer 7) RKE Config File Template](layer-7-lb/layer-7-lb.md#5-download-rke-config-file-template)

 The environment variables should be defined in the `Deployment` inside the RKE Config File Template. You only have to add the part starting with `env:` to (but not including) `ports:`. Make sure the indentation is identical to the preceding `name:`. Required values for `NO_PROXY` are:

@@ -0,0 +1,15 @@
+---
+title: RKE Add-On Install
+---
+
+> #### **Important: RKE add-on install is only supported up to Rancher v2.0.8**
+>
+>Please use the Rancher Helm chart to install Rancher on a Kubernetes cluster. For details, see the [Kubernetes Install ](../../../../resources/helm-version-requirements.md).
+>
+>If you are currently using the RKE add-on install method, see [Migrating from a Kubernetes Install with an RKE Add-on](../../../../install-upgrade-on-a-kubernetes-cluster/upgrades/migrating-from-rke-add-on.md) for details on how to start using the Helm chart.
+
+
+* [Kubernetes installation with External Load Balancer (TCP/Layer 4)](../../rke-add-on/layer-4-lb.md)
+* [Kubernetes installation with External Load Balancer (HTTPS/Layer 7)](../../rke-add-on/layer-7-lb.md)
+* [HTTP Proxy Configuration for a Kubernetes installation](proxy.md)
+* [Troubleshooting RKE Add-on Installs](troubleshooting/troubleshooting.md)
@@ -0,0 +1,29 @@
+---
+title: Troubleshooting HA RKE Add-On Install
+---
+
+> #### **Important: RKE add-on install is only supported up to Rancher v2.0.8**
+>
+>Please use the Rancher Helm chart to install Rancher on a Kubernetes cluster. For details, see the [Kubernetes Install ](../../../../../resources/helm-version-requirements.md).
+>
+>If you are currently using the RKE add-on install method, see [Migrating from a Kubernetes Install with an RKE Add-on](../../../../../install-upgrade-on-a-kubernetes-cluster/upgrades/migrating-from-rke-add-on.md) for details on how to start using the Helm chart.
+
+This section contains common errors seen when setting up a Kubernetes installation.
+
+Choose from the following options:
+
+- [Generic troubleshooting](generic-troubleshooting.md)
+
+    In this section, you can find generic ways to debug your Kubernetes cluster.
+
+- [Failed to set up SSH tunneling for host](https://rancher.com/docs/rke/latest/en/troubleshooting/ssh-connectivity-errors/)
+
+    In this section, you can find errors related to SSH tunneling when you run the `rke` command to setup your nodes.
+
+- [Failed to get job complete status](job-complete-status.md)
+
+    In this section, you can find errors related to deploying addons.
+
+- [404 - default backend](404-default-backend.md)
+
+    In this section, you can find errors related to the `404 - default backend` page that is shown when trying to access Rancher.
@@ -0,0 +1,113 @@
+---
+title: Opening Ports with firewalld
+---
+
+:::danger
+
+Enabling firewalld can cause serious network communication problems. 
+
+CNIs in Kubernetes dynamically update iptables and networking rules independently of any external firewalls, such as firewalld. This can cause unexpected behavior when the CNI and the external firewall conflict.
+
+:::
+
+Some distributions of Linux [derived from RHEL,](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds) including Oracle Linux, may have default firewall rules that block communication with Helm.
+
+For example, one Oracle Linux image in AWS has REJECT rules that stop Helm from communicating with Tiller:
+
+```
+Chain INPUT (policy ACCEPT)
+target     prot opt source               destination
+ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
+ACCEPT     icmp --  anywhere             anywhere
+ACCEPT     all  --  anywhere             anywhere
+ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh
+REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited
+
+Chain FORWARD (policy ACCEPT)
+target     prot opt source               destination
+REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited
+
+Chain OUTPUT (policy ACCEPT)
+target     prot opt source               destination
+```
+
+You can check the default firewall rules with this command:
+
+```
+sudo iptables --list
+```
+
+This section describes how to use `firewalld` to apply the [firewall port rules](../../installation-requirements/port-requirements.md) for nodes in a high-availability Rancher server cluster.
+
+## Prerequisite
+
+Install v7.x or later ofv`firewalld`:
+
+```
+yum install firewalld
+systemctl start firewalld
+systemctl enable firewalld
+```
+
+## Applying Firewall Port Rules
+
+In the Rancher high-availability installation instructions, the Rancher server is set up on three nodes that have all three Kubernetes roles: etcd, controlplane, and worker. If your Rancher server nodes have all three roles, run the following commands on each node:
+
+```
+firewall-cmd --permanent --add-port=22/tcp
+firewall-cmd --permanent --add-port=80/tcp
+firewall-cmd --permanent --add-port=443/tcp
+firewall-cmd --permanent --add-port=2376/tcp
+firewall-cmd --permanent --add-port=2379/tcp
+firewall-cmd --permanent --add-port=2380/tcp
+firewall-cmd --permanent --add-port=6443/tcp
+firewall-cmd --permanent --add-port=8472/udp
+firewall-cmd --permanent --add-port=9099/tcp
+firewall-cmd --permanent --add-port=10250/tcp
+firewall-cmd --permanent --add-port=10254/tcp
+firewall-cmd --permanent --add-port=30000-32767/tcp
+firewall-cmd --permanent --add-port=30000-32767/udp
+```
+If your Rancher server nodes have separate roles, use the following commands based on the role of the node:
+
+```
+# For etcd nodes, run the following commands:
+firewall-cmd --permanent --add-port=2376/tcp
+firewall-cmd --permanent --add-port=2379/tcp
+firewall-cmd --permanent --add-port=2380/tcp
+firewall-cmd --permanent --add-port=8472/udp
+firewall-cmd --permanent --add-port=9099/tcp
+firewall-cmd --permanent --add-port=10250/tcp
+
+# For control plane nodes, run the following commands:
+firewall-cmd --permanent --add-port=80/tcp
+firewall-cmd --permanent --add-port=443/tcp
+firewall-cmd --permanent --add-port=2376/tcp
+firewall-cmd --permanent --add-port=6443/tcp
+firewall-cmd --permanent --add-port=8472/udp
+firewall-cmd --permanent --add-port=9099/tcp
+firewall-cmd --permanent --add-port=10250/tcp
+firewall-cmd --permanent --add-port=10254/tcp
+firewall-cmd --permanent --add-port=30000-32767/tcp
+firewall-cmd --permanent --add-port=30000-32767/udp
+
+# For worker nodes, run the following commands:
+firewall-cmd --permanent --add-port=22/tcp
+firewall-cmd --permanent --add-port=80/tcp
+firewall-cmd --permanent --add-port=443/tcp
+firewall-cmd --permanent --add-port=2376/tcp
+firewall-cmd --permanent --add-port=8472/udp
+firewall-cmd --permanent --add-port=9099/tcp
+firewall-cmd --permanent --add-port=10250/tcp
+firewall-cmd --permanent --add-port=10254/tcp
+firewall-cmd --permanent --add-port=30000-32767/tcp
+firewall-cmd --permanent --add-port=30000-32767/udp
+```
+
+After the `firewall-cmd` commands have been run on a node, use the following command to enable the firewall rules:
+
+```
+firewall-cmd --reload
+```
+
+**Result:** The firewall is updated so that Helm can communicate with the Rancher server nodes.
@@ -0,0 +1,381 @@
+---
+title: Kubernetes Install with External Load Balancer (TCP/Layer 4)
+---
+import SSlFaqHa from '@site/src/components/SslFaqHa'
+
+> #### **Important: RKE add-on install is only supported up to Rancher v2.0.8**
+>
+>Please use the Rancher Helm chart to install Rancher on a Kubernetes cluster. For details, see the [Kubernetes Install](../../../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md).
+>
+>If you are currently using the RKE add-on install method, see [Migrating from a Kubernetes Install with an RKE Add-on](../../../install-upgrade-on-a-kubernetes-cluster/upgrades/migrating-from-rke-add-on.md) for details on how to start using the Helm chart.
+
+This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on:
+
+- Layer 4 load balancer (TCP)
+- [NGINX ingress controller with SSL termination (HTTPS)](https://kubernetes.github.io/ingress-nginx/)
+
+In an HA setup that uses a layer 4 load balancer, the load balancer accepts Rancher client connections over the TCP/UDP protocols (i.e., the transport level). The load balancer then forwards these connections to individual cluster nodes without reading the request itself. Because the load balancer cannot read the packets it's forwarding, the routing decisions it can make are limited.
+
+<sup>Rancher installed on a Kubernetes cluster with layer 4 load balancer, depicting SSL termination at ingress controllers</sup>
+
+![Rancher HA](/img/ha/rancher2ha.svg)
+
+## Installation Outline
+
+Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete.
+
+
+<br/>
+
+## 1. Provision Linux Hosts
+
+Provision three Linux hosts according to our [Requirements](../../../installation-requirements/installation-requirements.md).
+
+## 2. Configure Load Balancer
+
+We will be using NGINX as our Layer 4 Load Balancer (TCP). NGINX will forward all connections to one of your Rancher nodes. If you want to use Amazon NLB, you can skip this step and use [Amazon NLB configuration](../../../../../how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md)
+
+>**Note:**
+> In this configuration, the load balancer is positioned in front of your Linux hosts. The load balancer can be any host that you have available that's capable of running NGINX.
+>
+>One caveat: do not use one of your Rancher nodes as the load balancer.
+
+### A. Install NGINX
+
+Start by installing NGINX on your load balancer host. NGINX has packages available for all known operating systems. For help installing NGINX, refer to their [install documentation](https://www.nginx.com/resources/wiki/start/topics/tutorials/install/).
+
+The `stream` module is required, which is present when using the official NGINX packages. Please refer to your OS documentation how to install and enable the NGINX `stream` module on your operating system.
+
+### B. Create NGINX Configuration
+
+After installing NGINX, you need to update the NGINX config file, `nginx.conf`, with the IP addresses for your nodes.
+
+1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`.
+
+2. From `nginx.conf`, replace `IP_NODE_1`, `IP_NODE_2`, and `IP_NODE_3` with the IPs of your [Linux hosts](#1-provision-linux-hosts).
+
+    >**Note:** This Nginx configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/).
+
+    **Example NGINX config:**
+    ```
+    worker_processes 4;
+    worker_rlimit_nofile 40000;
+
+    events {
+        worker_connections 8192;
+    }
+
+    http {
+        server {
+            listen         80;
+            return 301 https://$host$request_uri;
+        }
+    }
+
+    stream {
+        upstream rancher_servers {
+            least_conn;
+            server IP_NODE_1:443 max_fails=3 fail_timeout=5s;
+            server IP_NODE_2:443 max_fails=3 fail_timeout=5s;
+            server IP_NODE_3:443 max_fails=3 fail_timeout=5s;
+        }
+        server {
+            listen     443;
+            proxy_pass rancher_servers;
+        }
+    }
+    ```
+
+3. Save `nginx.conf` to your load balancer at the following path: `/etc/nginx/nginx.conf`.
+
+4. Load the updates to your NGINX configuration by running the following command:
+
+    ```
+    # nginx -s reload
+    ```
+
+### Option - Run NGINX as Docker container
+
+Instead of installing NGINX as a package on the operating system, you can rather run it as a Docker container. Save the edited **Example NGINX config** as `/etc/nginx.conf` and run the following command to launch the NGINX container:
+
+```
+docker run -d --restart=unless-stopped \
+  -p 80:80 -p 443:443 \
+  -v /etc/nginx.conf:/etc/nginx/nginx.conf \
+  nginx:1.14
+```
+
+## 3. Configure DNS
+
+Choose a fully qualified domain name (FQDN) that you want to use to access Rancher (e.g., `rancher.yourdomain.com`).<br/><br/>
+
+1. Log into your DNS server a create a `DNS A` record that points to the IP address of your [load balancer](#2-configure-load-balancer).
+
+2. Validate that the `DNS A` is working correctly. Run the following command from any terminal, replacing `HOSTNAME.DOMAIN.COM` with your chosen FQDN:
+
+    `nslookup HOSTNAME.DOMAIN.COM`
+
+    **Step Result:** Terminal displays output similar to the following:
+
+    ```
+    $ nslookup rancher.yourdomain.com
+    Server:         YOUR_HOSTNAME_IP_ADDRESS
+    Address:        YOUR_HOSTNAME_IP_ADDRESS#53
+
+    Non-authoritative answer:
+    Name:   rancher.yourdomain.com
+    Address: HOSTNAME.DOMAIN.COM
+    ```
+
+<br/>
+
+## 4. Install RKE
+
+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](https://rancher.com/docs/rke/latest/en/installation) instructions.
+
+2. Confirm that RKE is now executable by running the following command:
+
+    ```
+    rke --version
+    ```
+
+## 5. Download RKE Config File Template
+
+RKE uses a `.yml` config file to install and configure your Kubernetes cluster. There are 2 templates to choose from, depending on the SSL certificate you want to use.
+
+1. Download one of following templates, depending on the SSL certificate you're using.
+
+    - [Template for self-signed certificate<br/>](../cluster-yml-templates/node-certificate.md)
+    - [Template for certificate signed by recognized CA<br/> ](../cluster-yml-templates/node-certificate-recognizedca.md)
+
+
+
+2. Rename the file to `rancher-cluster.yml`.
+
+## 6. Configure Nodes
+
+Once you have the `rancher-cluster.yml` config file template, edit the nodes section to point toward your Linux hosts.
+
+1. Open `rancher-cluster.yml` in your favorite text editor.
+
+1. Update the `nodes` section with the information of your [Linux hosts](#1-provision-linux-hosts).
+
+    For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docker 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](https://rancher.com/docs/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) >for RHEL/CentOS specific requirements.
+
+        nodes:
+            # The IP address or hostname of the node
+        - address: IP_ADDRESS_1
+            # User that can login to the node and has access to the Docker socket (i.e. can execute `docker ps` on the node)
+            # When using RHEL/CentOS, this can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565
+            user: USER
+            role: [controlplane,etcd,worker]
+            # Path the SSH key that can be used to access to node with the specified user
+            ssh_key_path: ~/.ssh/id_rsa
+        - address: IP_ADDRESS_2
+            user: USER
+            role: [controlplane,etcd,worker]
+            ssh_key_path: ~/.ssh/id_rsa
+        - address: IP_ADDRESS_3
+            user: USER
+            role: [controlplane,etcd,worker]
+            ssh_key_path: ~/.ssh/id_rsa
+
+1. **Optional:** By default, `rancher-cluster.yml` is configured to take backup snapshots of your data. To disable these snapshots, change the `backup` directive setting to `false`, as depicted below.
+
+        services:
+          etcd:
+            backup: false
+
+
+## 7. Configure Certificates
+
+For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
+
+Choose from the following options:
+
+<details id="option-a">
+  <summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
+
+>**Prerequisites:**
+>Create a self-signed certificate.
+>
+>- The certificate files must be in PEM format.
+>- The certificate files must be encoded in base64.
+>- In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.](../../../other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)
+
+1. In `kind: Secret` with `name: cattle-keys-ingress`:
+
+    * Replace `<BASE64_CRT>` with the base64 encoded string of the Certificate file (usually called `cert.pem` or `domain.crt`)
+    * Replace `<BASE64_KEY>` with the base64 encoded string of the Certificate Key file (usually called `key.pem` or `domain.key`)
+
+    >**Note:**
+    > The base64 encoded string should be on the same line as `tls.crt` or `tls.key`, without any newline at the beginning, in between or at the end.
+
+    **Step Result:** After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
+
+    ```yaml
+    ---
+    apiVersion: v1
+    kind: Secret
+    metadata:
+        name: cattle-keys-ingress
+        namespace: cattle-system
+    type: Opaque
+    data:
+        tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1RENDQWN5Z0F3SUJBZ0lKQUlHc25NeG1LeGxLTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NVGd3TlRBMk1qRXdOREE1V2hjTk1UZ3dOekExTWpFd05EQTVXakFXTVJRdwpFZ1lEVlFRRERBdG9ZUzV5Ym1Ob2NpNXViRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DCmdnRUJBTFJlMXdzekZSb2Rib2pZV05DSHA3UkdJaUVIMENDZ1F2MmdMRXNkUUNKZlcrUFEvVjM0NnQ3bSs3TFEKZXJaV3ZZMWpuY2VuWU5JSGRBU0VnU0ducWExYnhUSU9FaE0zQXpib3B0WDhjSW1OSGZoQlZETGdiTEYzUk0xaQpPM1JLTGdIS2tYSTMxZndjbU9zWGUwaElYQnpUbmxnM20vUzlXL3NTc0l1dDVwNENDUWV3TWlpWFhuUElKb21lCmpkS3VjSHFnMTlzd0YvcGVUalZrcVpuMkJHazZRaWFpMU41bldRV0pjcThTenZxTTViZElDaWlwYU9hWWQ3RFEKYWRTejV5dlF0YkxQNW4wTXpnOU43S3pGcEpvUys5QWdkWDI5cmZqV2JSekp3RzM5R3dRemN6VWtLcnZEb05JaQo0UFJHc01yclFNVXFSYjRSajNQOEJodEMxWXNDQXdFQUFhTTVNRGN3Q1FZRFZSMFRCQUl3QURBTEJnTlZIUThFCkJBTUNCZUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdJR0NDc0dBUVVGQndNQk1BMEdDU3FHU0liM0RRRUIKQ3dVQUE0SUJBUUNKZm5PWlFLWkowTFliOGNWUW5Vdi9NZkRZVEJIQ0pZcGM4MmgzUGlXWElMQk1jWDhQRC93MgpoOUExNkE4NGNxODJuQXEvaFZYYy9JNG9yaFY5WW9jSEg5UlcvbGthTUQ2VEJVR0Q1U1k4S292MHpHQ1ROaDZ6Ci9wZTNqTC9uU0pYSjRtQm51czJheHFtWnIvM3hhaWpYZG9kMmd3eGVhTklvRjNLbHB2aGU3ZjRBNmpsQTM0MmkKVVlCZ09iN1F5KytRZWd4U1diSmdoSzg1MmUvUUhnU2FVSkN6NW1sNGc1WndnNnBTUXhySUhCNkcvREc4dElSYwprZDMxSk1qY25Fb1Rhc1Jyc1NwVmNGdXZyQXlXN2liakZyYzhienBNcE1obDVwYUZRcEZzMnIwaXpZekhwakFsCk5ZR2I2OHJHcjBwQkp3YU5DS2ErbCtLRTk4M3A3NDYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
+        tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
+    ```
+
+2. In `kind: Secret` with `name: cattle-keys-server`, replace `<BASE64_CA>` with the base64 encoded string of the CA Certificate file (usually called `ca.pem` or `ca.crt`).
+
+    >**Note:**
+    > The base64 encoded string should be on the same line as `cacerts.pem`, without any newline at the beginning, in between or at the end.
+
+
+    **Step Result:** The file should look like the example below (the base64 encoded string should be different):
+
+    ```yaml
+    ---
+    apiVersion: v1
+    kind: Secret
+    metadata:
+      name: cattle-keys-server
+      namespace: cattle-system
+    type: Opaque
+    data:
+      cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
+    ```
+
+</details>
+
+<details id="option-b">
+  <summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
+
+If you are using a Certificate Signed By A Recognized Certificate Authority, you will need to generate a base64 encoded string for the Certificate file and the Certificate Key file. Make sure that your certificate file includes all the intermediate certificates in the chain, the order of certificates in this case is first your own certificate, followed by the intermediates. Please refer to the documentation of your CSP (Certificate Service Provider) to see what intermediate certificate(s) need to be included.
+
+In the `kind: Secret` with `name: cattle-keys-ingress`:
+
+* Replace `<BASE64_CRT>` with the base64 encoded string of the Certificate file (usually called `cert.pem` or `domain.crt`)
+* Replace `<BASE64_KEY>` with the base64 encoded string of the Certificate Key file (usually called `key.pem` or `domain.key`)
+
+After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
+
+>**Note:**
+> The base64 encoded string should be on the same line as `tls.crt` or `tls.key`, without any newline at the beginning, in between or at the end.
+
+```yaml
+---
+apiVersion: v1
+kind: Secret
+metadata:
+  name: cattle-keys-ingress
+  namespace: cattle-system
+type: Opaque
+data:
+  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1RENDQWN5Z0F3SUJBZ0lKQUlHc25NeG1LeGxLTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NVGd3TlRBMk1qRXdOREE1V2hjTk1UZ3dOekExTWpFd05EQTVXakFXTVJRdwpFZ1lEVlFRRERBdG9ZUzV5Ym1Ob2NpNXViRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DCmdnRUJBTFJlMXdzekZSb2Rib2pZV05DSHA3UkdJaUVIMENDZ1F2MmdMRXNkUUNKZlcrUFEvVjM0NnQ3bSs3TFEKZXJaV3ZZMWpuY2VuWU5JSGRBU0VnU0ducWExYnhUSU9FaE0zQXpib3B0WDhjSW1OSGZoQlZETGdiTEYzUk0xaQpPM1JLTGdIS2tYSTMxZndjbU9zWGUwaElYQnpUbmxnM20vUzlXL3NTc0l1dDVwNENDUWV3TWlpWFhuUElKb21lCmpkS3VjSHFnMTlzd0YvcGVUalZrcVpuMkJHazZRaWFpMU41bldRV0pjcThTenZxTTViZElDaWlwYU9hWWQ3RFEKYWRTejV5dlF0YkxQNW4wTXpnOU43S3pGcEpvUys5QWdkWDI5cmZqV2JSekp3RzM5R3dRemN6VWtLcnZEb05JaQo0UFJHc01yclFNVXFSYjRSajNQOEJodEMxWXNDQXdFQUFhTTVNRGN3Q1FZRFZSMFRCQUl3QURBTEJnTlZIUThFCkJBTUNCZUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdJR0NDc0dBUVVGQndNQk1BMEdDU3FHU0liM0RRRUIKQ3dVQUE0SUJBUUNKZm5PWlFLWkowTFliOGNWUW5Vdi9NZkRZVEJIQ0pZcGM4MmgzUGlXWElMQk1jWDhQRC93MgpoOUExNkE4NGNxODJuQXEvaFZYYy9JNG9yaFY5WW9jSEg5UlcvbGthTUQ2VEJVR0Q1U1k4S292MHpHQ1ROaDZ6Ci9wZTNqTC9uU0pYSjRtQm51czJheHFtWnIvM3hhaWpYZG9kMmd3eGVhTklvRjNLbHB2aGU3ZjRBNmpsQTM0MmkKVVlCZ09iN1F5KytRZWd4U1diSmdoSzg1MmUvUUhnU2FVSkN6NW1sNGc1WndnNnBTUXhySUhCNkcvREc4dElSYwprZDMxSk1qY25Fb1Rhc1Jyc1NwVmNGdXZyQXlXN2liakZyYzhienBNcE1obDVwYUZRcEZzMnIwaXpZekhwakFsCk5ZR2I2OHJHcjBwQkp3YU5DS2ErbCtLRTk4M3A3NDYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
+  tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
+```
+
+</details>
+
+
+
+## 8. Configure FQDN
+
+There are two references to `<FQDN>` in the config file (one in this step and one in the next). Both need to be replaced with the FQDN chosen in [Configure DNS](#3-configure-dns).
+
+In the `kind: Ingress` with `name: cattle-ingress-http`:
+
+* Replace `<FQDN>` with the FQDN chosen in [Configure DNS](#3-configure-dns).
+
+After replacing `<FQDN>` with the FQDN chosen in [Configure DNS](#3-configure-dns), the file should look like the example below (`rancher.yourdomain.com` is the FQDN used in this example):
+
+```yaml
+ ---
+  apiVersion: extensions/v1beta1
+  kind: Ingress
+  metadata:
+    namespace: cattle-system
+    name: cattle-ingress-http
+    annotations:
+      nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
+      nginx.ingress.kubernetes.io/proxy-read-timeout: "1800"   # Max time in seconds for ws to remain shell window open
+      nginx.ingress.kubernetes.io/proxy-send-timeout: "1800"   # Max time in seconds for ws to remain shell window open
+  spec:
+    rules:
+    - host: rancher.yourdomain.com
+      http:
+        paths:
+        - backend:
+            serviceName: cattle-service
+            servicePort: 80
+    tls:
+    - secretName: cattle-keys-ingress
+      hosts:
+      - rancher.yourdomain.com
+```
+
+Save the `.yml` file and close it.
+
+## 9. Configure Rancher version
+
+The last reference that needs to be replaced is `<RANCHER_VERSION>`. This needs to be replaced with a Rancher version which is marked as stable. The latest stable release of Rancher can be found in the [GitHub README](https://github.com/rancher/rancher/blob/master/README.md). Make sure the version is an actual version number, and not a named tag like `stable` or `latest`. The example below shows the version configured to `v2.0.6`.
+
+```
+      spec:
+        serviceAccountName: cattle-admin
+        containers:
+        - image: rancher/rancher:v2.0.6
+          imagePullPolicy: Always
+```
+
+## 10. Back Up Your RKE Config File
+
+After you close your `.yml` file, back it up to a secure location. You can use this file again when it's time to upgrade Rancher.
+
+## 11. Run RKE
+
+With all configuration in place, use RKE to launch Rancher. You can complete this action by running the `rke up` command and using the `--config` parameter to point toward your config file.
+
+1. From your workstation, make sure `rancher-cluster.yml` and the downloaded `rke` binary are in the same directory.
+
+2. Open a Terminal instance. Change to the directory that contains your config file and `rke`.
+
+3. Enter one of the `rke up` commands listen below.
+
+```
+rke up --config rancher-cluster.yml
+```
+
+**Step Result:** The output should be similar to the snippet below:
+
+```
+INFO[0000] Building Kubernetes cluster
+INFO[0000] [dialer] Setup tunnel for host [1.1.1.1]
+INFO[0000] [network] Deploying port listener containers
+INFO[0000] [network] Pulling image [alpine:latest] on host [1.1.1.1]
+...
+INFO[0101] Finished building Kubernetes cluster successfully
+```
+
+## 12. Back Up Auto-Generated Config File
+
+During installation, RKE automatically generates a config file named `kube_config_rancher-cluster.yml` in the same directory as the RKE binary. Copy this file and back it up to a safe location. You'll use this file later when upgrading Rancher Server.
+
+## What's Next?
+
+You have a couple of options:
+
+- Create a backup of your Rancher Server in case of a disaster scenario: [High Availability Back Up and Restore](../../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md).
+- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md).
+
+<br/>
+
+## FAQ and Troubleshooting
+
+<SslFaqHa/>
@@ -0,0 +1,271 @@
+---
+title: Kubernetes Install with External Load Balancer (HTTPS/Layer 7)
+---
+import SslFaqHa from '@site/src/components/SslFaqHa'
+
+> #### **Important: RKE add-on install is only supported up to Rancher v2.0.8**
+>
+>Please use the Rancher Helm chart to install Rancher on a Kubernetes cluster. For details, see the [Kubernetes Install](../../../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md).
+>
+>If you are currently using the RKE add-on install method, see [Migrating from a Kubernetes Install with an RKE Add-on](../../../install-upgrade-on-a-kubernetes-cluster/upgrades/migrating-from-rke-add-on.md) for details on how to start using the Helm chart.
+
+This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on:
+
+- Layer 7 load balancer with SSL termination (HTTPS)
+- [NGINX Ingress controller (HTTP)](https://kubernetes.github.io/ingress-nginx/)
+
+In an HA setup that uses a layer 7 load balancer, the load balancer accepts Rancher client connections over the HTTP protocol (i.e., the application level). This application-level access allows the load balancer to read client requests and then redirect to them to cluster nodes using logic that optimally distributes load.
+
+<sup>Rancher installed on a Kubernetes cluster with layer 7 load balancer, depicting SSL termination at load balancer</sup>
+
+![Rancher HA](/img/ha/rancher2ha-l7.svg)
+
+## Installation Outline
+
+Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete.
+
+## 1. Provision Linux Hosts
+
+Provision three Linux hosts according to our [Requirements](../../../installation-requirements/installation-requirements.md).
+
+## 2. Configure Load Balancer
+
+When using a load balancer in front of Rancher, there's no need for the container to redirect port communication from port 80 or port 443. By passing the header `X-Forwarded-Proto: https`, this redirect is disabled. This is the expected configuration when terminating SSL externally.
+
+The load balancer has to be configured to support the following:
+
+* **WebSocket** connections
+* **SPDY** / **HTTP/2** protocols
+* Passing / setting the following headers:
+
+| Header              | Value                                  | Description                                                                                                                                                              |
+|---------------------|----------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `Host`              | FQDN used to reach Rancher. | To identify the server requested by the client.                                                                                                                           |
+| `X-Forwarded-Proto` | `https`                                | To identify the protocol that a client used to connect to the load balancer.<br /><br/>**Note:** If this header is present, `rancher/rancher` does not redirect HTTP to HTTPS. |
+| `X-Forwarded-Port`  | Port used to reach Rancher.             | To identify the protocol that client used to connect to the load balancer.                                                                                       |
+| `X-Forwarded-For`   | IP of the client connection.            | To identify the originating IP address of a client.                                                                                                                       |
+
+Health checks can be executed on the `/healthz` endpoint of the node, this will return HTTP 200.
+
+We have example configurations for the following load balancers:
+
+* [Amazon ELB configuration](../../../../../how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md)
+* [NGINX configuration](../../../../../how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md)
+
+## 3. Configure DNS
+
+Choose a fully qualified domain name (FQDN) that you want to use to access Rancher (e.g., `rancher.yourdomain.com`).<br/><br/>
+
+1. Log into your DNS server a create a `DNS A` record that points to the IP address of your [load balancer](#2-configure-load-balancer).
+
+2. Validate that the `DNS A` is working correctly. Run the following command from any terminal, replacing `HOSTNAME.DOMAIN.COM` with your chosen FQDN:
+
+    `nslookup HOSTNAME.DOMAIN.COM`
+
+    **Step Result:** Terminal displays output similar to the following:
+
+    ```
+    $ nslookup rancher.yourdomain.com
+    Server:         YOUR_HOSTNAME_IP_ADDRESS
+    Address:        YOUR_HOSTNAME_IP_ADDRESS#53
+
+    Non-authoritative answer:
+    Name:   rancher.yourdomain.com
+    Address: HOSTNAME.DOMAIN.COM
+    ```
+
+<br/>
+
+## 4. Install RKE
+
+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](https://rancher.com/docs/rke/latest/en/installation) instructions.
+
+2. Confirm that RKE is now executable by running the following command:
+
+    ```
+    rke --version
+    ```
+
+## 5. Download RKE Config File Template
+
+RKE uses a YAML config file to install and configure your Kubernetes cluster. There are 2 templates to choose from, depending on the SSL certificate you want to use.
+
+1. Download one of following templates, depending on the SSL certificate you're using.
+
+    - [Template for self-signed certificate<br/> `3-node-externalssl-certificate.yml`](../cluster-yml-templates/node-externalssl-certificate.md)installation/options/cluster-yml-templates/3-node-externalssl-certificate)
+    - [Template for certificate signed by recognized CA<br/> `3-node-externalssl-recognizedca.yml`](../cluster-yml-templates/node-externalssl-recognizedca.md)
+
+
+
+2. Rename the file to `rancher-cluster.yml`.
+
+## 6. Configure Nodes
+
+Once you have the `rancher-cluster.yml` config file template, edit the nodes section to point toward your Linux hosts.
+
+1. Open `rancher-cluster.yml` in your favorite text editor.
+
+1. Update the `nodes` section with the information of your [Linux hosts](#1-provision-linux-hosts).
+
+    For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docker 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](https://rancher.com/docs/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
+
+        nodes:
+            # The IP address or hostname of the node
+        - address: IP_ADDRESS_1
+            # User that can login to the node and has access to the Docker socket (i.e. can execute `docker ps` on the node)
+            # When using RHEL/CentOS, this can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565
+            user: USER
+            role: [controlplane,etcd,worker]
+            # Path the SSH key that can be used to access to node with the specified user
+            ssh_key_path: ~/.ssh/id_rsa
+        - address: IP_ADDRESS_2
+            user: USER
+            role: [controlplane,etcd,worker]
+            ssh_key_path: ~/.ssh/id_rsa
+        - address: IP_ADDRESS_3
+            user: USER
+            role: [controlplane,etcd,worker]
+            ssh_key_path: ~/.ssh/id_rsa
+
+1. **Optional:** By default, `rancher-cluster.yml` is configured to take backup snapshots of your data. To disable these snapshots, change the `backup` directive setting to `false`, as depicted below.
+
+        services:
+          etcd:
+            backup: false
+
+## 7. Configure Certificates
+
+For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
+
+Choose from the following options:
+
+<details id="option-a">
+  <summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
+
+>**Prerequisites:**
+>Create a self-signed certificate.
+>
+>- The certificate files must be in PEM format.
+>- The certificate files must be encoded in base64.
+>- In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.](../../../other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)
+
+In `kind: Secret` with `name: cattle-keys-ingress`, replace `<BASE64_CA>` with the base64 encoded string of the CA Certificate file (usually called `ca.pem` or `ca.crt`)
+
+>**Note:** The base64 encoded string should be on the same line as `cacerts.pem`, without any newline at the beginning, in between or at the end.
+
+After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
+
+        ---
+        apiVersion: v1
+        kind: Secret
+        metadata:
+            name: cattle-keys-server
+            namespace: cattle-system
+        type: Opaque
+        data:
+            cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
+
+</details>
+<details id="option-b">
+  <summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
+
+If you are using a Certificate Signed By A Recognized Certificate Authority, you don't need to perform any step in this part.
+
+</details>
+
+## 8. Configure FQDN
+
+There is one reference to `<FQDN>` in the RKE config file. Replace this reference with the FQDN you chose in [3. Configure DNS](#3-configure-dns).
+
+1. Open `rancher-cluster.yml`.
+
+2. In the `kind: Ingress` with `name: cattle-ingress-http:`
+
+    Replace `<FQDN>` with the FQDN chosen in [3. Configure DNS](#3-configure-dns).
+
+    **Step Result:** After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
+
+    ```
+    apiVersion: extensions/v1beta1
+      kind: Ingress
+      metadata:
+        namespace: cattle-system
+        name: cattle-ingress-http
+        annotations:
+          nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
+          nginx.ingress.kubernetes.io/proxy-read-timeout: "1800"   # Max time in seconds for ws to remain shell window open
+          nginx.ingress.kubernetes.io/proxy-send-timeout: "1800"   # Max time in seconds for ws to remain shell window open
+      spec:
+        rules:
+        - host: rancher.yourdomain.com
+          http:
+            paths:
+            - backend:
+                serviceName: cattle-service
+                servicePort: 80
+    ```
+
+
+3. Save the file and close it.
+
+## 9. Configure Rancher version
+
+The last reference that needs to be replaced is `<RANCHER_VERSION>`. This needs to be replaced with a Rancher version which is marked as stable. The latest stable release of Rancher can be found in the [GitHub README](https://github.com/rancher/rancher/blob/master/README.md). Make sure the version is an actual version number, and not a named tag like `stable` or `latest`. The example below shows the version configured to `v2.0.6`.
+
+```
+      spec:
+        serviceAccountName: cattle-admin
+        containers:
+        - image: rancher/rancher:v2.0.6
+          imagePullPolicy: Always
+```
+
+## 10. Back Up Your RKE Config File
+
+After you close your RKE config file, `rancher-cluster.yml`, back it up to a secure location. You can use this file again when it's time to upgrade Rancher.
+
+## 11. Run RKE
+
+With all configuration in place, use RKE to launch Rancher. You can complete this action by running the `rke up` command and using the `--config` parameter to point toward your config file.
+
+1. From your workstation, make sure `rancher-cluster.yml` and the downloaded `rke` binary are in the same directory.
+
+2. Open a Terminal instance. Change to the directory that contains your config file and `rke`.
+
+3. Enter one of the `rke up` commands listen below.
+
+    ```
+    rke up --config rancher-cluster.yml
+    ```
+
+    **Step Result:** The output should be similar to the snippet below:
+
+    ```
+    INFO[0000] Building Kubernetes cluster
+    INFO[0000] [dialer] Setup tunnel for host [1.1.1.1]
+    INFO[0000] [network] Deploying port listener containers
+    INFO[0000] [network] Pulling image [alpine:latest] on host [1.1.1.1]
+    ...
+    INFO[0101] Finished building Kubernetes cluster successfully
+    ```
+
+## 12. Back Up Auto-Generated Config File
+
+During installation, RKE automatically generates a config file named `kube_config_rancher-cluster.yml` in the same directory as the `rancher-cluster.yml` file. Copy this file and back it up to a safe location. You'll use this file later when upgrading Rancher Server.
+
+## What's Next?
+
+- **Recommended:** Review [Creating Backups—High Availability Back Up and Restoration](../../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md) to learn how to backup your Rancher Server in case of a disaster scenario.
+- Create a Kubernetes cluster: [Creating a Cluster](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md).
+
+<br/>
+
+## FAQ and Troubleshooting
+
+<SslFaqHa/>
@@ -0,0 +1,6 @@
+---
+title: RKE Add-On Install
+---
+
+- [Kubernetes Install with External Load Balancer (TCP/Layer 4)](layer-4-lb.md)
+- [Kubernetes Install with External Load Balancer (HTTPS/Layer 7)](layer-7-lb.md)
@@ -0,0 +1,39 @@
+---
+title: Tuning etcd for Large Installations
+---
+
+When running larger Rancher installations with 15 or more clusters it is recommended to increase the default keyspace for etcd from the default 2GB. The maximum setting is 8GB and the host should have enough RAM to keep the entire dataset in memory. When increasing this value you should also increase the size of the host. The keyspace size can also be adjusted in smaller installations if you anticipate a high rate of change of pods during the garbage collection interval.
+
+The etcd data set is automatically cleaned up on a five minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.3/op-guide/maintenance/#space-quota) setting on the etcd servers.
+
+## Example: This Snippet of the RKE Cluster.yml file Increases the Keyspace Size to 5GB
+
+```yaml
+# RKE cluster.yml
+---
+services:
+  etcd:
+    extra_args:
+      quota-backend-bytes: 5368709120
+```
+
+## Scaling etcd Disk Performance
+
+You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.3/tuning/#disk) on how to tune the disk priority on the host.
+
+Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use striping RAID configurations to increase available IOPS.
+
+To implement this solution in an RKE cluster, the `/var/lib/etcd/data` and `/var/lib/etcd/wal` directories will need to have disks mounted and formatted on the underlying host. In the `extra_args` directive of the `etcd` service, you must include the `wal_dir` directory. Without specifying the `wal_dir`, etcd process will try to manipulate the underlying `wal` mount with insufficient permissions.
+
+```yaml
+# RKE cluster.yml
+---
+services:
+  etcd:
+    extra_args:
+      data-dir: '/var/lib/rancher/etcd/data/'
+      wal-dir: '/var/lib/rancher/etcd/wal/wal_dir'
+    extra_binds:
+      - '/var/lib/etcd/data:/var/lib/rancher/etcd/data'
+      - '/var/lib/etcd/wal:/var/lib/rancher/etcd/wal'
+```
@@ -0,0 +1,139 @@
+---
+title: Enabling Experimental Features
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/enable-experimental-features"/>
+</head>
+
+Rancher includes some features that are experimental and disabled by default. You might want to enable these features, for example, if you decide that the benefits of using an [unsupported storage type](unsupported-storage-drivers.md) outweighs the risk of using an untested feature. Feature flags were introduced to allow you to try these features that are not enabled by default.
+
+The features can be enabled in three ways:
+
+- [Enable features when starting Rancher.](#enabling-features-when-starting-rancher) When installing Rancher with a CLI, you can use a feature flag to enable a feature by default.
+- [Enable features from the Rancher UI](#enabling-features-with-the-rancher-ui) in Rancher v2.3.3+ by going to the **Settings** page.
+- [Enable features with the Rancher API](#enabling-features-with-the-rancher-api) after installing Rancher.
+
+Each feature has two values:
+
+- A default value, which can be configured with a flag or environment variable from the command line
+- A set value, which can be configured with the Rancher API or UI
+
+If no value has been set, Rancher uses the default value.
+
+Because the API sets the actual value and the command line sets the default value, that means that if you enable or disable a feature with the API or UI, it will override any value set with the command line.
+
+For example, if you install Rancher, then set a feature flag to true with the Rancher API, then upgrade Rancher with a command that sets the feature flag to false, the default value will still be false, but the feature will still be enabled because it was set with the Rancher API. If you then deleted the set value (true) with the Rancher API, setting it to NULL, the default value (false) would take effect. See the [feature flags page](../../../../reference-guides/installation-references/feature-flags.md) for more information.
+
+## Enabling Features when Starting Rancher
+
+When you install Rancher, enable the feature you want with a feature flag. The command is different depending on whether you are installing Rancher on a single node or if you are doing a Kubernetes Installation of Rancher.
+
+> **Note:** Values set from the Rancher API will override the value passed in through the command line.
+
+<Tabs>
+<TabItem value="Kubernetes Install">
+
+When installing Rancher with a Helm chart, use the `--features` option. In the below example, two features are enabled by passing the feature flag names names in a comma separated list:
+
+```
+helm install rancher-latest/rancher \
+  --name rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set 'extraEnv[0].name=CATTLE_FEATURES' # Available as of v2.3.0
+  --set 'extraEnv[0].value=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true' # Available as of v2.3.0
+```
+
+Note: If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
+
+### Rendering the Helm Chart for Air Gap Installations
+
+For an air gap installation of Rancher, you need to add a Helm chart repository and render a Helm template before installing Rancher with Helm. For details, refer to the [air gap installation documentation.](../../other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md)
+
+Here is an example of a command for passing in the feature flag names when rendering the Helm template. In the below example, two features are enabled by passing the feature flag names in a comma separated list.
+
+The Helm 3 command is as follows:
+
+```
+helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
+  --namespace cattle-system \
+  --set hostname=<RANCHER.YOURDOMAIN.COM> \
+  --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+  --set ingress.tls.source=secret \
+  --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Available as of v2.2.0, set a default private registry to be used in Rancher
+  --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
+  --set 'extraEnv[0].name=CATTLE_FEATURES' # Available as of v2.3.0
+  --set 'extraEnv[0].value=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true' # Available as of v2.3.0
+```
+
+The Helm 2 command is as follows:
+
+```
+helm template ./rancher-<VERSION>.tgz --output-dir . \
+  --name rancher \
+  --namespace cattle-system \
+  --set hostname=<RANCHER.YOURDOMAIN.COM> \
+  --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+  --set ingress.tls.source=secret \
+  --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Available as of v2.2.0, set a default private registry to be used in Rancher
+  --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
+  --set 'extraEnv[0].name=CATTLE_FEATURES' # Available as of v2.3.0
+  --set 'extraEnv[0].value=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true' # Available as of v2.3.0
+```
+
+
+</TabItem>
+<TabItem value="Docker Install">
+
+When installing Rancher with Docker, use the `--features` option. In the below example, two features are enabled by passing the feature flag names in a comma separated list:
+
+```
+docker run -d -p 80:80 -p 443:443 \
+  --restart=unless-stopped \
+  rancher/rancher:rancher-latest \
+  --features=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true # Available as of v2.3.0
+```
+
+</TabItem>
+</Tabs>
+
+## Enabling Features with the Rancher UI
+
+1. Go to the **Global** view and click **Settings.**
+1. Click the **Feature Flags** tab. You will see a list of experimental features.
+1. To enable a feature, go to the disabled feature you want to enable and click **&#8942; > Activate.**
+
+**Result:** The feature is enabled.
+
+### Disabling Features with the Rancher UI
+
+1. Go to the **Global** view and click **Settings.**
+1. Click the **Feature Flags** tab. You will see a list of experimental features.
+1. To disable a feature, go to the enabled feature you want to disable and click **&#8942; > Deactivate.**
+
+**Result:** The feature is disabled.
+
+## Enabling Features with the Rancher API
+
+1. Go to `<RANCHER-SERVER-URL>/v3/features`.
+1. In the `data` section, you will see an array containing all of the features that can be turned on with feature flags. The name of the feature is in the `id` field. Click the name of the feature you want to enable.
+1. In the upper left corner of the screen, under **Operations,** click **Edit.**
+1. In the **Value** drop-down menu, click **True.**
+1. Click **Show Request.**
+1. Click **Send Request.**
+1. Click **Close.**
+
+**Result:** The feature is enabled.
+
+### Disabling Features with the Rancher API
+
+1. Go to `<RANCHER-SERVER-URL>/v3/features`.
+1. In the `data` section, you will see an array containing all of the features that can be turned on with feature flags. The name of the feature is in the `id` field. Click the name of the feature you want to enable.
+1. In the upper left corner of the screen, under **Operations,** click **Edit.**
+1. In the **Value** drop-down menu, click **False.**
+1. Click **Show Request.**
+1. Click **Send Request.**
+1. Click **Close.**
+
+**Result:** The feature is disabled.
@@ -0,0 +1,30 @@
+---
+title: UI for Istio Virtual Services and Destination Rules
+---
+
+This feature enables a UI that lets you create, read, update and delete virtual services and destination rules, which are traffic management features of Istio.
+
+> **Prerequisite:** Turning on this feature does not enable Istio. A cluster administrator needs to [enable Istio for the cluster](../../../../how-to-guides/advanced-user-guides/istio-setup-guide/istio-setup-guide.md) in order to use the feature.
+
+To enable or disable this feature, refer to the instructions on [the main page about enabling experimental features.](../../../../reference-guides/installation-references/feature-flags.md)
+
+Environment Variable Key | Default Value | Status | Available as of
+---|---|---|---
+`istio-virtual-service-ui` |`false` |  Experimental | v2.3.0
+`istio-virtual-service-ui` | `true` | GA                    | v2.3.2
+
+## About this Feature
+
+A central advantage of Istio's traffic management features is that they allow dynamic request routing, which is useful for canary deployments, blue/green deployments, or A/B testing.
+
+When enabled, this feature turns on a page that lets you configure some traffic management features of Istio using the Rancher UI. Without this feature, you need to use `kubectl` to manage traffic with Istio.
+
+The feature enables two UI tabs: one tab for **Virtual Services** and another for **Destination Rules.**
+
+- **Virtual services** intercept and direct traffic to your Kubernetes services, allowing you to direct percentages of traffic from a request to different services. You can use them to define a set of routing rules to apply when a host is addressed. For details, refer to the [Istio documentation.](https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service/)
+- **Destination rules** serve as the single source of truth about which service versions are available to receive traffic from virtual services. You can use these resources to define policies that apply to traffic that is intended for a service after routing has occurred. For details, refer to the [Istio documentation.](https://istio.io/docs/reference/config/networking/v1alpha3/destination-rule)
+
+To see these tabs,
+
+1. Go to the project view in Rancher and click **Resources > Istio.**
+1. You will see tabs for **Traffic Graph,** which has the Kiali network visualization integrated into the UI, and **Traffic Metrics,** which shows metrics for the success rate and request volume of traffic to your services, among other metrics. Next to these tabs, you should see the tabs for **Virtual Services** and **Destination Rules.**
@@ -0,0 +1,40 @@
+---
+title: "Running on ARM64 (Experimental)"
+---
+
+> **Important:**
+>
+> Running on an ARM64 platform is currently an experimental feature and is not yet officially supported in Rancher. Therefore, we do not recommend using ARM64 based nodes in a production environment.
+
+The following options are available when using an ARM64 platform:
+
+- Running Rancher on ARM64 based node(s)
+  - Only for Docker Install. Please note that the following installation command replaces the examples found in the [Docker Install](../../other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md) link:
+
+  ```
+  # In the last line `rancher/rancher:vX.Y.Z`, be certain to replace "X.Y.Z" with a released version in which ARM64 builds exist. For  example, if your matching version is v2.5.8, you would fill in this line with `rancher/rancher:v2.5.8`.
+  docker run -d --restart=unless-stopped \
+    -p 80:80 -p 443:443 \
+    --privileged \
+    rancher/rancher:vX.Y.Z
+  ```
+> **Note:** To check if your specific released version is compatible with the ARM64 architecture, you may navigate to your
+> version's release notes in the following two ways:
+>
+> - Manually find your version using https://github.com/rancher/rancher/releases.
+> - Go directly to your version using the tag and the specific version number. If you plan to use v2.5.8, for example, you may
+>   navigate to https://github.com/rancher/rancher/releases/tag/v2.5.8.
+
+- Create custom cluster and adding ARM64 based node(s)
+  - Kubernetes cluster version must be 1.12 or higher
+  - CNI Network Provider must be [Flannel](../../../../faq/container-network-interface-providers.md#flannel)
+
+- Importing clusters that contain ARM64 based nodes
+  - Kubernetes cluster version must be 1.12 or higher
+
+Please see [Cluster Options](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md) for information on how to configure the cluster options.
+
+The following features are not tested:
+
+- Monitoring, alerts, notifiers, pipelines and logging
+- Launching apps from the catalog
@@ -0,0 +1,296 @@
+---
+title: Install Rancher on a Kubernetes Cluster
+description: Learn how to install Rancher in development and production environments. Read about single node and high availability installation
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster"/>
+</head>
+
+## Prerequisite
+
+Set up the Rancher server's local Kubernetes cluster.
+
+The cluster requirements depend on the Rancher version:
+
+- **In Rancher v2.4.x,** Rancher needs to be installed on a K3s Kubernetes cluster or an RKE Kubernetes cluster.
+- **In Rancher before v2.4,** Rancher needs to be installed on an RKE Kubernetes cluster.
+
+For the tutorial to install an RKE Kubernetes cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/rke1-for-rancher.md) For help setting up the infrastructure for a high-availability RKE cluster, refer to [this page.](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-rke1-kubernetes-cluster.md)
+
+For the tutorial to install a K3s Kubernetes cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/k3s-for-rancher.md) For help setting up the infrastructure for a high-availability K3s cluster, refer to [this page.](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-k3s-kubernetes-cluster.md)
+
+## Install the Rancher Helm Chart
+
+Rancher is installed using the Helm package manager for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents.
+
+With Helm, we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at https://helm.sh/.
+
+For systems without direct internet access, see [Air Gap: Kubernetes install](../advanced-options/advanced-use-cases/air-gap-helm2/install-rancher.md).
+
+To choose a Rancher version to install, refer to [Choosing a Rancher Version.](../resources/choose-a-rancher-version.md)
+
+To choose a version of Helm to install Rancher with, refer to the [Helm version requirements](../resources/helm-version-requirements.md)
+
+> **Note:** The installation instructions assume you are using Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) This [section](../resources/helm-version-requirements.md) provides a copy of the older installation instructions for Rancher installed on an RKE Kubernetes cluster with Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+
+To set up Rancher,
+
+1. [Install the required CLI tools](#1-install-the-required-cli-tools)
+2. [Add the Helm chart repository](#2-add-the-helm-chart-repository)
+3. [Create a namespace for Rancher](#3-create-a-namespace-for-rancher)
+4. [Choose your SSL configuration](#4-choose-your-ssl-configuration)
+5. [Install cert-manager](#5-install-cert-manager) (unless you are bringing your own certificates, or TLS will be terminated on a load balancer)
+6. [Install Rancher with Helm and your chosen certificate option](#6-install-rancher-with-helm-and-your-chosen-certificate-option)
+7. [Verify that the Rancher server is successfully deployed](#7-verify-that-the-rancher-server-is-successfully-deployed)
+8. [Save your options](#8-save-your-options)
+
+### 1. Install the Required CLI Tools
+
+The following CLI tools are required for setting up the Kubernetes cluster. Please make sure these tools are installed and available in your `$PATH`.
+
+Refer to the [instructions provided by the Helm project](https://helm.sh/docs/intro/install/) for your specific platform.
+
+- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
+- [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes. Refer to the [Helm version requirements](../resources/helm-version-requirements.md) to choose a version of Helm to install Rancher.
+
+### 2. Add the Helm Chart Repository
+
+Use `helm repo add` command to add the Helm chart repository that contains charts to install Rancher. For more information about the repository choices and which is best for your use case, see [Choosing a Rancher Version](../resources/choose-a-rancher-version.md).
+
+- Latest: Recommended for trying out the newest features
+    ```
+    helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+    ```
+- Stable: Recommended for production environments
+    ```
+    helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+    ```
+- Alpha: Experimental preview of upcoming releases.
+    ```
+    helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+    ```
+    Note: Upgrades are not supported to, from, or between Alphas.
+
+### 3. Create a Namespace for Rancher
+
+We'll need to define a Kubernetes namespace where the resources created by the Chart should be installed. This should always be `cattle-system`:
+
+```
+kubectl create namespace cattle-system
+```
+
+### 4. Choose your SSL Configuration
+
+The Rancher management server is designed to be secure by default and requires SSL/TLS configuration.
+
+> **Note:** If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer](../../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination).
+
+There are three recommended options for the source of the certificate used for TLS termination at the Rancher server:
+
+- **Rancher-generated TLS certificate:** In this case, you will need to install `cert-manager` into the cluster. Rancher utilizes `cert-manager` to issue and maintain its certificates. Rancher will generate a CA certificate of its own, and sign a cert using that CA. `cert-manager` is then responsible for managing that certificate.
+- **Let's Encrypt:** The Let's Encrypt option also uses `cert-manager`. However, in this case, cert-manager is combined with a special Issuer for Let's Encrypt that performs all actions (including request and validation) necessary for getting a Let's Encrypt issued cert. This configuration uses HTTP validation (`HTTP-01`), so the load balancer must have a public DNS record and be accessible from the internet.
+- **Bring your own certificate:** This option allows you to bring your own public- or private-CA signed certificate. Rancher will use that certificate to secure websocket and HTTPS traffic. In this case, you must upload this certificate (and associated key) as PEM-encoded files with the name `tls.crt` and `tls.key`. If you are using a private CA, you must also upload that certificate. This is due to the fact that this private CA may not be trusted by your nodes. Rancher will take that CA certificate, and generate a checksum from it, which the various Rancher components will use to validate their connection to Rancher.
+
+
+| Configuration                  | Helm Chart Option           | Requires cert-manager                 |
+| ------------------------------ | ----------------------- | ------------------------------------- |
+| Rancher Generated Certificates (Default) | `ingress.tls.source=rancher`  | [yes](#5-install-cert-manager) |
+| Let’s Encrypt                  | `ingress.tls.source=letsEncrypt`  | [yes](#5-install-cert-manager) |
+| Certificates from Files        | `ingress.tls.source=secret`        | no               |
+
+### 5. Install cert-manager
+
+> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer](../../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination).
+
+This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
+
+<details id="cert-manager">
+  <summary>Click to Expand</summary>
+
+> **Important:** Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation](../resources/upgrade-cert-manager.md).
+
+These instructions are adapted from the [official cert-manager documentation](https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm).
+
+```
+# Install the CustomResourceDefinition resources separately
+kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.0.4/cert-manager.crds.yaml
+
+# **Important:**
+# If you are running Kubernetes v1.15 or below, you
+# will need to add the `--validate=false` flag to your
+# kubectl apply command, or else you will receive a
+# validation error relating to the
+# x-kubernetes-preserve-unknown-fields field in
+# cert-manager’s CustomResourceDefinition resources.
+# This is a benign error and occurs due to the way kubectl
+# performs resource validation.
+
+# Create the namespace for cert-manager
+kubectl create namespace cert-manager
+
+# Add the Jetstack Helm repository
+helm repo add jetstack https://charts.jetstack.io
+
+# Update your local Helm chart repository cache
+helm repo update
+
+# Install the cert-manager Helm chart
+helm install \
+  cert-manager jetstack/cert-manager \
+  --namespace cert-manager \
+  --version v1.0.4
+```
+
+Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
+
+```
+kubectl get pods --namespace cert-manager
+
+NAME                                       READY   STATUS    RESTARTS   AGE
+cert-manager-5c6866597-zw7kh               1/1     Running   0          2m
+cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
+cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m
+```
+
+</details>
+
+### 6. Install Rancher with Helm and Your Chosen Certificate Option
+
+The exact command to install Rancher differs depending on the certificate configuration.
+
+<Tabs>
+<TabItem value="Rancher-generated Certificates">
+
+The default is for Rancher to generate a CA and uses `cert-manager` to issue the certificate for access to the Rancher server interface.
+
+Because `rancher` is the default option for `ingress.tls.source`, we are not specifying `ingress.tls.source` when running the `helm install` command.
+
+- Set the `hostname` to the DNS name you pointed at your load balancer.
+- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
+- To install a specific Rancher version, use the `--version` flag, example: `--version 2.3.6`
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org
+```
+
+Wait for Rancher to be rolled out:
+
+```
+kubectl -n cattle-system rollout status deploy/rancher
+Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
+deployment "rancher" successfully rolled out
+```
+
+</TabItem>
+<TabItem value="Let's Encrypt">
+
+This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA.
+
+In the following command,
+
+- `hostname` is set to the public DNS record,
+- `ingress.tls.source` is set to `letsEncrypt`
+- `letsEncrypt.email` is set to the email address used for communication about your certificate (for example, expiry notices)
+- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set ingress.tls.source=letsEncrypt \
+  --set letsEncrypt.email=me@example.org \
+```
+
+Wait for Rancher to be rolled out:
+
+```
+kubectl -n cattle-system rollout status deploy/rancher
+Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
+deployment "rancher" successfully rolled out
+```
+
+</TabItem>
+<TabItem value="Certificates from Files">
+
+In this option, Kubernetes secrets are created from your own certificates for Rancher to use.
+
+When you run this command, the `hostname` option must match the `Common Name` or a `Subject Alternative Names` entry in the server certificate or the Ingress controller will fail to configure correctly.
+
+Although an entry in the `Subject Alternative Names` is technically required, having a matching `Common Name` maximizes compatibility with older browsers and applications.
+
+> If you want to check if your certificates are correct, see [How do I check Common Name and Subject Alternative Names in my server certificate?](../../../faq/technical-items.md#how-do-i-check-common-name-and-subject-alternative-names-in-my-server-certificate)
+
+- Set the `hostname`.
+- Set `ingress.tls.source` to `secret`.
+- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set ingress.tls.source=secret
+```
+
+If you are using a Private CA signed certificate , add `--set privateCA=true` to the command:
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set ingress.tls.source=secret \
+  --set privateCA=true
+```
+
+Now that Rancher is deployed, see [Adding TLS Secrets](../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the Ingress controller can use them.
+
+</TabItem>
+</Tabs>
+
+The Rancher chart configuration has many options for customizing the installation to suit your specific environment. Here are some common advanced scenarios.
+
+- [HTTP Proxy](../../../reference-guides/installation-references/helm-chart-options.md#http-proxy)
+- [Private Docker Image Registry](../../../reference-guides/installation-references/helm-chart-options.md#private-registry-and-air-gap-installs)
+- [TLS Termination on an External Load Balancer](../../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination)
+
+See the [Chart Options](../../../reference-guides/installation-references/helm-chart-options.md) for the full list of options.
+
+
+### 7. Verify that the Rancher Server is Successfully Deployed
+
+After adding the secrets, check if Rancher was rolled out successfully:
+
+```
+kubectl -n cattle-system rollout status deploy/rancher
+Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
+deployment "rancher" successfully rolled out
+```
+
+If you see the following error: `error: deployment "rancher" exceeded its progress deadline`, you can check the status of the deployment by running the following command:
+
+```
+kubectl -n cattle-system get deploy rancher
+NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+rancher   3         3         3            3           3m
+```
+
+It should show the same count for `DESIRED` and `AVAILABLE`.
+
+### 8. Save Your Options
+
+Make sure you save the `--set` options you used. You will need to use the same options when you upgrade Rancher to new versions with Helm.
+
+### Finishing Up
+
+That's it. You should have a functional Rancher server.
+
+In a web browser, go to the DNS name that forwards traffic to your load balancer. Then you should be greeted by the colorful login page.
+
+Doesn't work? Take a look at the [Troubleshooting](troubleshooting.md) Page
+
+
+### Optional Next Steps
+
+Enable the Enterprise Cluster Manager.
@@ -0,0 +1,229 @@
+---
+title: Upgrading Rancher Installed on Kubernetes with Helm 2
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades"/>
+</head>
+
+> Helm 3 has been released.  If you are using Helm 2, we recommend [migrating to Helm 3](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) because it is simpler to use and more secure than Helm 2.
+>
+> The [current instructions for Upgrading Rancher Installed on Kubernetes](upgrades.md) use Helm 3.
+>
+> This section provides a copy of the older instructions for upgrading Rancher with Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+
+The following instructions will guide you through using Helm to upgrade a Rancher server that is installed on a Kubernetes cluster.
+
+To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
+
+If you installed Rancher using the RKE Add-on yaml, follow the directions to [migrate or upgrade](./migrating-from-rke-add-on.md).
+
+>**Notes:**
+>
+> - [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753) Upgrade cert-manager to the latest version by following [these instructions.](../../resources/upgrade-cert-manager.md)
+> - If you are upgrading Rancher from v2.x to v2.3+, and you are using external TLS termination, you will need to edit the cluster.yml to [enable using forwarded host headers.](../../../../reference-guides/installation-references/helm-chart-options.md#configuring-ingress-for-external-tls-when-using-nginx-v025)
+> - The upgrade instructions assume you are using Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) This [section](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+
+## Prerequisites
+
+- **Review the [known upgrade issues](upgrades.md)** in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
+- **For [air gap installs only,](../../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version.** Follow the guide to [populate your private registry](../../other-installation-methods/air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
+
+## Upgrade Outline
+
+Follow the steps to upgrade Rancher server:
+
+- [A. Back up your Kubernetes cluster that is running Rancher server](#a-back-up-your-kubernetes-cluster-that-is-running-rancher-server)
+- [B. Update the Helm chart repository](#b-update-the-helm-chart-repository)
+- [C. Upgrade Rancher](#c-upgrade-rancher)
+- [D. Verify the Upgrade](#d-verify-the-upgrade)
+
+### A. Back up Your Kubernetes Cluster that is Running Rancher Server
+
+[Take a one-time snapshot](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md#option-b-one-time-snapshots)
+of your Kubernetes cluster running Rancher server. You'll use the snapshot as a restore point if something goes wrong during upgrade.
+
+### B. Update the Helm chart repository
+
+1. Update your local Helm repo cache.
+
+    ```
+    helm repo update
+    ```
+
+1. Get the repository name that you used to install Rancher.
+
+    For information about the repos and their differences, see [Helm Chart Repositories](../../resources/choose-a-rancher-version.md#helm-chart-repositories).
+
+    - Latest: Recommended for trying out the newest features
+        ```
+        helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+        ```
+    - Stable: Recommended for production environments
+        ```
+        helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+        ```
+    - Alpha: Experimental preview of upcoming releases.
+        ```
+        helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+        ```
+        Note: Upgrades are not supported to, from, or between Alphas.
+
+    ```
+    helm repo list
+
+    NAME          	       URL
+    stable        	       https://charts.helm.sh/stable
+    rancher-<CHART_REPO>	 https://releases.rancher.com/server-charts/<CHART_REPO>
+    ```
+
+    > **Note:** If you want to switch to a different Helm chart repository, please follow the [steps on how to switch repositories](../../resources/choose-a-rancher-version.md#switching-to-a-different-helm-chart-repository). If you switch repositories, make sure to list the repositories again before continuing onto Step 3 to ensure you have the correct one added.
+
+
+1. Fetch the latest chart to install Rancher from the Helm chart repository.
+
+    This command will pull down the latest charts and save it in the current directory as a `.tgz` file.
+
+    ```plain
+    helm fetch rancher-<CHART_REPO>/rancher
+    ```
+
+### C. Upgrade Rancher
+
+This section describes how to upgrade normal (Internet-connected) or air gap installations of Rancher with Helm.
+
+<Tabs>
+<TabItem value="Kubernetes Upgrade">
+
+Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
+
+```
+helm get values rancher
+
+hostname: rancher.my.org
+```
+
+> **Note:** There will be more values that are listed with this command. This is just an example of one of the values.
+
+If you are also upgrading cert-manager to the latest version from a version older than 0.11.0, follow `Option B: Reinstalling Rancher`. Otherwise, follow `Option A: Upgrading Rancher`.
+
+<details>
+  <summary>Option A: Upgrading Rancher</summary>
+
+Upgrade Rancher to the latest version with all your settings.
+
+Take all the values from the previous step and append them to the command using `--set key=value`. Note: There will be many more options from the previous step that need to be appended.
+
+```
+helm upgrade --install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org
+```
+</details>
+
+<details>
+  <summary>Option B: Reinstalling Rancher chart</summary>
+
+If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
+
+1. Uninstall Rancher
+
+    ```
+    helm delete rancher
+    ```
+    In case this results in an error that the release "rancher" was not found, make sure you are using the correct deployment name. Use `helm list` to list the helm-deployed releases.
+
+2. Uninstall and reinstall `cert-manager` according to the instructions on the [Upgrading Cert-Manager](../../resources/upgrade-cert-manager-helm-2.md) page.
+
+3. Reinstall Rancher to the latest version with all your settings. Take all the values from the step 1 and append them to the command using `--set key=value`. Note: There will be many more options from the step 1 that need to be appended.
+
+    ```
+    helm install rancher-<CHART_REPO>/rancher \
+    --name rancher \
+    --namespace cattle-system \
+    --set hostname=rancher.my.org
+    ```
+
+</details>
+
+</TabItem>
+<TabItem value="Kubernetes Air Gap Upgrade">
+
+1. Render the Rancher template using the same chosen options that were used when installing Rancher. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
+
+    Based on the choice you made during installation, complete one of the procedures below.
+
+    Placeholder | Description
+    ------------|-------------
+    `<VERSION>` | The version number of the output tarball.
+    `<RANCHER.YOURDOMAIN.COM>` | The DNS name you pointed at your load balancer.
+    `<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.
+    `<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.
+
+<details id="self-signed">
+  <summary>Option A-Default Self-Signed Certificate</summary>
+
+ ```plain
+helm template ./rancher-<VERSION>.tgz --output-dir . \
+ --name rancher \
+ --namespace cattle-system \
+ --set hostname=<RANCHER.YOURDOMAIN.COM> \
+ --set certmanager.version=<CERTMANAGER_VERSION> \
+ --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+ --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Available as of v2.2.0, set a default private registry to be used in Rancher
+ --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
+```
+
+</details>
+<details id="secret">
+  <summary>Option B: Certificates From Files using Kubernetes Secrets</summary>
+
+```plain
+helm template ./rancher-<VERSION>.tgz --output-dir . \
+--name rancher \
+--namespace cattle-system \
+--set hostname=<RANCHER.YOURDOMAIN.COM> \
+--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+--set ingress.tls.source=secret \
+--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Available as of v2.2.0, set a default private registry to be used in Rancher
+--set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
+```
+
+If you are using a Private CA signed cert, add `--set privateCA=true` following `--set ingress.tls.source=secret`:
+
+```plain
+helm template ./rancher-<VERSION>.tgz --output-dir . \
+--name rancher \
+--namespace cattle-system \
+--set hostname=<RANCHER.YOURDOMAIN.COM> \
+--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+--set ingress.tls.source=secret \
+--set privateCA=true \
+--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Available as of v2.2.0, set a default private registry to be used in Rancher
+--set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
+```
+
+</details>
+
+2. Copy the rendered manifest directories to a system with access to the Rancher server cluster and apply the rendered templates.
+
+    Use `kubectl` to apply the rendered manifests.
+
+    ```plain
+    kubectl -n cattle-system apply -R -f ./rancher
+    ```
+
+</TabItem>
+</Tabs>
+
+### D. Verify the Upgrade
+
+Log into Rancher to confirm that the upgrade succeeded.
+
+>**Having network issues following upgrade?**
+>
+> See [Restoring Cluster Networking](namespace-migration.md#restoring-cluster-networking).
+
+## Rolling Back
+
+Should something go wrong, follow the [roll back](../rollbacks.md) instructions to restore the snapshot you took before you preformed the upgrade.
@@ -101,5 +101,5 @@ addons: |-

 From here follow the standard install steps.

-* [3 - Initialize Helm](../../../../pages-for-subheaders/helm2-helm-init.md)
-* [4 - Install Rancher](../../../../pages-for-subheaders/helm-rancher.md)
+* [3 - Initialize Helm](../../advanced-options/advanced-use-cases/helm2/helm-init/helm-init.md)
+* [4 - Install Rancher](../../advanced-options/advanced-use-cases/helm2/helm-rancher/helm-rancher.md)
@@ -56,7 +56,7 @@ You can prevent cluster networking issues from occurring during your upgrade to

 1. Repeat these steps for each cluster where you've assigned system namespaces to projects.

-**Result:** All system namespaces are moved out of Rancher projects. You can now safely begin the [upgrade](../../../../pages-for-subheaders/upgrades.md).
+**Result:** All system namespaces are moved out of Rancher projects. You can now safely begin the [upgrade](upgrades.md).

 ## Restoring Cluster Networking

@@ -172,8 +172,8 @@ Reset the cluster nodes' network policies to restore connectivity.

 If you can access Rancher, but one or more of the clusters that you launched using Rancher has no networking, you can repair them by moving them:

- Using the cluster's [embedded kubectl shell](../../../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md).
- By [downloading the cluster kubeconfig file and running it](../../../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) from your workstation.
+- Using the cluster's [embedded kubectl shell](../../../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-shell-in-the-rancher-ui).
+- By [downloading the cluster kubeconfig file and running it](../../../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-from-your-workstation) from your workstation.

    ```
    for namespace in $(kubectl --kubeconfig kube_config_rancher-cluster.yml get ns -o custom-columns=NAME:.metadata.name --no-headers); do
@@ -0,0 +1,283 @@
+---
+title: Upgrades
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades"/>
+</head>
+
+The following instructions will guide you through upgrading a Rancher server that was installed on a Kubernetes cluster with Helm. These steps also apply to air gap installs with Helm.
+
+For the instructions to upgrade Rancher installed with Docker, refer to [this page.](../../other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md)
+
+To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
+
+If you installed Rancher using the RKE Add-on yaml, follow the directions to [migrate or upgrade](migrating-from-rke-add-on.md).
+
+- [Prerequisites](#prerequisites)
+- [Upgrade Outline](#upgrade-outline)
+- [Known Upgrade Issues](#known-upgrade-issues)
+- [RKE Add-on Installs](#rke-add-on-installs)
+
+## Prerequisites
+
+### Access to kubeconfig
+
+Helm should be run from the same location as your kubeconfig file, or the same location where you run your kubectl commands from.
+
+If you installed Kubernetes with RKE, the config will have been created in the directory you ran `rke up` in.
+
+The kubeconfig can also be manually targeted for the intended cluster with the `--kubeconfig` tag (see: https://helm.sh/docs/helm/helm/)
+
+### Review Known Issues
+
+Review the [known upgrade issues](#known-upgrade-issues) in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher.
+
+A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
+
+Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](../../resources/choose-a-rancher-version.md#helm-chart-repositories) aren't supported.
+
+### Helm Version
+
+The upgrade instructions assume you are using Helm 3.
+
+For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+
+### For air gap installs: Populate private registry
+
+-For [air gap installs only,](../../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version. Follow the guide to [populate your private registry](../../other-installation-methods/air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
+
+### For upgrades from v2.0-v2.2 with external TLS termination
+
+If you are upgrading Rancher from v2.x to v2.3+, and you are using external TLS termination, you will need to edit the cluster.yml to [enable using forwarded host headers.](../../../../reference-guides/installation-references/helm-chart-options.md#configuring-ingress-for-external-tls-when-using-nginx-v025)
+
+### For upgrades with cert-manager older than 0.8.0
+
+[Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753) Upgrade cert-manager to the latest version by following [these instructions.](../../resources/upgrade-cert-manager.md)
+
+## Upgrade Outline
+
+Follow the steps to upgrade Rancher server:
+
+- [1. Back up your Kubernetes cluster that is running Rancher server](#1-back-up-your-kubernetes-cluster-that-is-running-rancher-server)
+- [2. Update the Helm chart repository](#2-update-the-helm-chart-repository)
+- [3. Upgrade Rancher](#3-upgrade-rancher)
+- [4. Verify the Upgrade](#4-verify-the-upgrade)
+
+## 1. Back up Your Kubernetes Cluster that is Running Rancher Server
+
+
+[Take a one-time snapshot](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md#option-b-one-time-snapshots)
+of your Kubernetes cluster running Rancher server.
+
+You'll use the backup as a restoration point if something goes wrong during upgrade.
+
+## 2. Update the Helm chart repository
+
+1. Update your local Helm repo cache:
+
+    ```
+    helm repo update
+    ```
+
+1. Get the repository name that you used to install Rancher.
+
+    For information about the repos and their differences, see [Helm Chart Repositories](../../resources/choose-a-rancher-version.md#helm-chart-repositories).
+
+    - Latest: Recommended for trying out the newest features
+        ```
+        helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+        ```
+    - Stable: Recommended for production environments
+        ```
+        helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+        ```
+    - Alpha: Experimental preview of upcoming releases.
+        ```
+        helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+        ```
+        Note: Upgrades are not supported to, from, or between Alphas.
+
+    ```
+    helm repo list
+
+    NAME          	       URL
+    stable        	       https://charts.helm.sh/stable
+    rancher-<CHART_REPO>	 https://releases.rancher.com/server-charts/<CHART_REPO>
+    ```
+
+    > **Note:** If you want to switch to a different Helm chart repository, please follow the [steps on how to switch repositories](../../resources/choose-a-rancher-version.md#switching-to-a-different-helm-chart-repository). If you switch repositories, make sure to list the repositories again before continuing onto Step 3 to ensure you have the correct one added.
+
+1. Fetch the latest chart to install Rancher from the Helm chart repository.
+
+    This command will pull down the latest charts and save it in the current directory as a `.tgz` file.
+
+    ```plain
+    helm fetch rancher-<CHART_REPO>/rancher
+    ```
+    You can fetch the chart for the specific version you are upgrading to by adding in the `--version=` tag.  For example:
+
+    ```plain
+    helm fetch rancher-<CHART_REPO>/rancher --version=v2.4.11
+    ```
+
+## 3. Upgrade Rancher
+
+This section describes how to upgrade normal (Internet-connected) or air gap installations of Rancher with Helm.
+
+<Tabs>
+<TabItem value="Kubernetes Upgrade">
+
+Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
+
+```
+helm get values rancher -n cattle-system
+
+hostname: rancher.my.org
+```
+
+> **Note:** There will be more values that are listed with this command. This is just an example of one of the values.
+
+If you are also upgrading cert-manager to the latest version from a version older than 0.11.0, follow [Option B: Reinstalling Rancher and cert-manager.](#option-b-reinstalling-rancher-and-cert-manager)
+
+Otherwise, follow [Option A: Upgrading Rancher.](#option-a-upgrading-rancher)
+
+### Option A: Upgrading Rancher
+
+Upgrade Rancher to the latest version with all your settings.
+
+Take all the values from the previous step and append them to the command using `--set key=value`:
+
+```
+helm upgrade rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org
+```
+
+> **Note:** The above is an example, there may be more values from the previous step that need to be appended.
+
+Alternatively, it's possible to export the current values to a file and reference that file during upgrade. For example, to only change the Rancher version:
+
+```
+helm get values rancher -n cattle-system -o yaml > values.yaml
+
+helm upgrade rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  -f values.yaml \
+  --version=2.4.5
+```
+
+### Option B: Reinstalling Rancher and cert-manager
+
+If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
+
+1. Uninstall Rancher
+
+    ```
+    helm delete rancher -n cattle-system
+    ```
+
+2. Uninstall and reinstall `cert-manager` according to the instructions on the [Upgrading Cert-Manager](../../resources/upgrade-cert-manager-helm-2.md) page.
+
+3. Reinstall Rancher to the latest version with all your settings. Take all the values from the step 1 and append them to the command using `--set key=value`. Note: There will be many more options from the step 1 that need to be appended.
+
+    ```
+    helm install rancher rancher-<CHART_REPO>/rancher \
+    --namespace cattle-system \
+    --set hostname=rancher.my.org
+    ```
+
+</TabItem>
+<TabItem value="Kubernetes Air Gap Upgrade">
+
+Render the Rancher template using the same chosen options that were used when installing Rancher. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
+
+Based on the choice you made during installation, complete one of the procedures below.
+
+Placeholder | Description
+------------|-------------
+`<VERSION>` | The version number of the output tarball.
+`<RANCHER.YOURDOMAIN.COM>` | The DNS name you pointed at your load balancer.
+`<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.
+`<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.
+
+### Option A: Default Self-signed Certificate
+
+ ```plain
+helm template ./rancher-<VERSION>.tgz --output-dir . \
+ --name rancher \
+ --namespace cattle-system \
+ --set hostname=<RANCHER.YOURDOMAIN.COM> \
+ --set certmanager.version=<CERTMANAGER_VERSION> \
+ --set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+ --set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Available as of v2.2.0, set a default private registry to be used in Rancher
+ --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
+```
+
+### Option B: Certificates from Files using Kubernetes Secrets
+
+```plain
+helm template ./rancher-<VERSION>.tgz --output-dir . \
+--name rancher \
+--namespace cattle-system \
+--set hostname=<RANCHER.YOURDOMAIN.COM> \
+--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+--set ingress.tls.source=secret \
+--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Available as of v2.2.0, set a default private registry to be used in Rancher
+--set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
+```
+
+If you are using a Private CA signed cert, add `--set privateCA=true` following `--set ingress.tls.source=secret`:
+
+```plain
+helm template ./rancher-<VERSION>.tgz --output-dir . \
+--name rancher \
+--namespace cattle-system \
+--set hostname=<RANCHER.YOURDOMAIN.COM> \
+--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+--set ingress.tls.source=secret \
+--set privateCA=true \
+--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Available as of v2.2.0, set a default private registry to be used in Rancher
+--set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
+```
+
+### Apply the Rendered Templates
+
+Copy the rendered manifest directories to a system with access to the Rancher server cluster and apply the rendered templates.
+
+Use `kubectl` to apply the rendered manifests.
+
+```plain
+kubectl -n cattle-system apply -R -f ./rancher
+```
+
+</TabItem>
+</Tabs>
+
+## 4. Verify the Upgrade
+
+Log into Rancher to confirm that the upgrade succeeded.
+
+>**Having network issues following upgrade?**
+>
+> See [Restoring Cluster Networking](namespace-migration.md#restoring-cluster-networking).
+
+## Known Upgrade Issues
+
+The following table lists some of the most noteworthy issues to be considered when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
+
+Upgrade Scenario | Issue
+---|---
+Upgrading to v2.4.6 or v2.4.7 | These Rancher versions had an issue where the `kms:ListKeys` permission was required to create, edit, or clone Amazon EC2 node templates. This requirement was removed in v2.4.8.
+Upgrading to v2.3.0+ | Any user provisioned cluster will be automatically updated upon any edit as tolerations were added to the images used for Kubernetes provisioning.
+Upgrading to v2.2.0-v2.2.x | Rancher introduced the [system charts](https://github.com/rancher/system-charts) repository which 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 locally and configure Rancher to use that repository. Please follow the instructions to [configure Rancher system charts](../../resources/local-system-charts.md).
+Upgrading from v2.0.13 or earlier  | If your cluster's certificates have expired, you will need to perform [additional steps](../../../../how-to-guides/advanced-user-guides/manage-clusters/rotate-certificates.md#rotating-expired-certificates-after-upgrading-older-rancher-versions) to rotate the certificates.
+Upgrading from v2.0.7 or earlier | Rancher introduced the `system` project, which is a project that's automatically created to store important namespaces that Kubernetes needs to operate. During upgrade to v2.0.7+, Rancher expects these namespaces to be unassigned from all projects. Before beginning upgrade, check your system namespaces to make sure that they're unassigned to [prevent cluster networking issues.](namespace-migration.md)
+
+## RKE Add-on Installs
+
+**Important: RKE add-on install is only supported up to Rancher v2.0.8**
+
+Please use the Rancher Helm chart to install Rancher on a Kubernetes cluster. For details, see the [Kubernetes Install](../install-upgrade-on-a-kubernetes-cluster.md).
+
+If you are currently using the RKE add-on install method, see [Migrating from a RKE add-on install](migrating-from-rke-add-on.md) for details on how to start using the Helm chart.
@@ -0,0 +1,96 @@
+---
+title: Installing/Upgrading Rancher
+description: Learn how to install Rancher in development and production environments. Read about single node and high availability installation
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade"/>
+</head>
+
+This section provides an overview of the architecture options of installing Rancher, describing advantages of each option.
+
+## Terminology
+
+In this section,
+
+- **The Rancher server** manages and provisions Kubernetes clusters. You can interact with downstream Kubernetes clusters through the Rancher server's user interface.
+- **RKE (Rancher Kubernetes Engine)** is a certified Kubernetes distribution and CLI/library which creates and manages a Kubernetes cluster.
+- **K3s (Lightweight Kubernetes)** is also a fully compliant Kubernetes distribution. It is newer than RKE, easier to use, and more lightweight, with a binary size of less than 100 MB. As of Rancher v2.4, Rancher can be installed on a K3s cluster.
+
+## Overview of Installation Options
+
+Rancher can be installed on these main architectures:
+
+### High-availability Kubernetes Install with the Helm CLI
+
+We recommend using Helm, a Kubernetes package manager, to install Rancher on multiple nodes on a dedicated Kubernetes cluster. For RKE clusters, three nodes are required to achieve a high-availability cluster. For K3s clusters, only two nodes are required.
+
+### Single-node Kubernetes Install
+
+Rancher can be installed on a single-node Kubernetes cluster. In this case, the Rancher server doesn't have high availability, which is important for running Rancher in production.
+
+However, this option is useful if you want to save resources by using a single node in the short term, while preserving a high-availability migration path. In the future, you can add nodes to the cluster to get a high-availability Rancher server.
+
+### Docker Install
+
+For test and demonstration purposes, Rancher can be installed with Docker on a single node.
+
+For Rancher v2.0-v2.4, there is no migration path from a Docker installation to a high-availability installation. Therefore, you may want to use a Kubernetes installation from the start.
+
+### Other Options
+
+There are also separate instructions for installing Rancher in an air gap environment or behind an HTTP proxy:
+
+| Level of Internet Access           | Kubernetes Installation - Strongly Recommended                | Docker Installation                             |
+| ---------------------------------- | ------------------------------ | ---------- |
+| With direct access to the Internet | [Docs](install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) | [Docs](other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md)                                                                                     |
+| Behind an HTTP proxy                | These [docs,](install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) plus this [configuration](../../reference-guides/installation-references/helm-chart-options.md#http-proxy) |  These [docs,](other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md) plus this [configuration](../../reference-guides/single-node-rancher-in-docker/http-proxy-configuration.md) |
+| In an air gap environment          | [Docs](other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md)                                                                                                                               | [Docs](other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md)                                                                                         |
+
+We recommend installing Rancher on a Kubernetes cluster, because in a multi-node cluster, the Rancher management server becomes highly available. This high-availability configuration helps maintain consistent access to the downstream Kubernetes clusters that Rancher will manage.
+
+For that reason, we recommend that for a production-grade architecture, you should set up a high-availability Kubernetes cluster, then install Rancher on it. After Rancher is installed, you can use Rancher to deploy and manage Kubernetes clusters.
+
+> The type of cluster that Rancher needs to be installed on depends on the Rancher version.
+>
+> For Rancher v2.4.x, either an RKE Kubernetes cluster or K3s Kubernetes cluster can be used.
+> For Rancher before v2.4, an RKE cluster must be used.
+
+For testing or demonstration purposes, you can install Rancher in single Docker container. In this Docker install, you can use Rancher to set up Kubernetes clusters out-of-the-box. The Docker install allows you to explore the Rancher server functionality, but it is intended to be used for development and testing purposes only.
+
+Our [instructions for installing Rancher on Kubernetes](install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) describe how to first use K3s or RKE to create and manage a Kubernetes cluster, then install Rancher onto that cluster.
+
+When the nodes in your Kubernetes cluster are running and fulfill the [node requirements,](installation-requirements/installation-requirements.md) you will use Helm to deploy Rancher onto Kubernetes. Helm uses Rancher's Helm chart to install a replica of Rancher on each node in the Kubernetes cluster. We recommend using a load balancer to direct traffic to each replica of Rancher in the cluster.
+
+For a longer discussion of Rancher architecture, refer to the [architecture overview,](../../reference-guides/rancher-manager-architecture/rancher-manager-architecture.md) [recommendations for production-grade architecture,](../../reference-guides/rancher-manager-architecture/architecture-recommendations.md) or our [best practices guide.](../../reference-guides/best-practices/deployment-types.md)
+
+## Prerequisites
+
+Before installing Rancher, make sure that your nodes fulfill all of the [installation requirements.](installation-requirements/installation-requirements.md)
+
+## Architecture Tip
+
+For the best performance and greater security, we recommend a separate, dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md) for running your workloads.
+
+For more architecture recommendations, refer to [this page.](../../reference-guides/rancher-manager-architecture/architecture-recommendations.md)
+
+### More Options for Installations on a Kubernetes Cluster
+
+Refer to the [Helm chart options](../../reference-guides/installation-references/helm-chart-options.md) for details on installing Rancher on a Kubernetes cluster with other configurations, including:
+
+- With [API auditing to record all transactions](../../reference-guides/installation-references/helm-chart-options.md#api-audit-log)
+- With [TLS termination on a load balancer](../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination)
+- With a [custom Ingress](../../reference-guides/installation-references/helm-chart-options.md#customizing-your-ingress)
+
+In the Rancher installation instructions, we recommend using K3s or RKE to set up a Kubernetes cluster before installing Rancher on the cluster. Both K3s and RKE have many configuration options for customizing the Kubernetes cluster to suit your specific environment. For the full list of their capabilities, refer to their documentation:
+
+- [RKE configuration options](https://rancher.com/docs/rke/latest/en/config-options/)
+- [K3s configuration options](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
+
+### More Options for Installations with Docker
+
+Refer to the [docs about options for Docker installs](other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md) for details about other configurations including:
+
+- With [API auditing to record all transactions](../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-audit-log)
+- With an [external load balancer](advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md)
+- With a [persistent data store](../../reference-guides/single-node-rancher-in-docker/advanced-options.md#persistent-data)
--- a/Show More
+++ b/Show More