merge master and resolve conflicts

2026-09-24 03:58:06 +00:00 · 2018-07-17 16:08:22 +10:00
parent e9363c7a65 7f34bbd3e5
commit 3ccff9007a
146 changed files with 2092 additions and 572 deletions
@@ -7,10 +7,22 @@ pipeline:
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    commands:
-      - docker build -f Dockerfile.prod .
+      - docker build --pull -f Dockerfile.prod .
    when:
      event: [pull_request]

+  docker-publish-algolia:
+    group: publish
+    image: plugins/docker
+    dockerfile: Dockerfile.algolia
+    repo: rancher/docs
+    context: .
+    tag: algolia
+    secrets: [docker_username, docker_password]
+    when:
+      branch: master
+      event: push
+
  docker-publish-dev:
    group: publish
    image: plugins/docker
@@ -0,0 +1,9 @@
+FROM rancher/docs:build
+
+VOLUME /usr/share/nginx/html/docs
+WORKDIR /run
+
+COPY gulpfile.babel.js /run/
+
+ENTRYPOINT ["gulp"]
+CMD ["publish:search-index"]
@@ -1,7 +1,6 @@
 FROM rancher/docs:build as build

 WORKDIR /run
-
 COPY gulpfile.babel.js /run/
 COPY .eslintrc.js /run/
 COPY config.toml /run/
@@ -17,11 +16,13 @@ ENV HUGO_ENV production

 ADD https://github.com/rancherlabs/website-theme/archive/master.tar.gz master.tar.gz
 RUN tar -xzf master.tar.gz --strip 1 -C /run/node_modules/rancher-website-theme && rm master.tar.gz
+
 RUN gulp build

 # Make sure something got built
 RUN stat /run/public/index.html

 FROM nginx
+VOLUME /usr/share/nginx/html/docs
 COPY --from=build /run/public /usr/share/nginx/html/docs/
 COPY nginx.conf /etc/nginx/conf.d/default.conf
@@ -1,7 +1,6 @@
 FROM rancher/docs:build as build

 WORKDIR /run
-
 COPY gulpfile.babel.js /run/
 COPY .eslintrc.js /run/
 COPY config.toml /run/
@@ -17,11 +16,13 @@ ENV HUGO_ENV production

 ADD https://github.com/rancherlabs/website-theme/archive/master.tar.gz master.tar.gz
 RUN tar -xzf master.tar.gz --strip 1 -C /run/node_modules/rancher-website-theme && rm master.tar.gz
+
 RUN gulp build-staging

 # Make sure something got built
 RUN stat /run/public/index.html

 FROM nginx
+VOLUME /usr/share/nginx/html/docs
 COPY --from=build /run/public /usr/share/nginx/html/docs/
 COPY nginx.conf /etc/nginx/conf.d/default.conf
@@ -14,7 +14,3 @@ and then navigate to http://localhost:9001/.  You can customize the port by pass
 ```bash
  ./scripts/dev 8080
 ```
-
-## Building distribution image
-
-
@@ -18,19 +18,19 @@ pygmentsCodeFencesGuessSyntax=true
  ### Edit content repo (set to automatically enter "edit" mode; this is good for "improve this page" links)
  ghdocsrepo = "https://github.com/rancher/docs"

-[outputFormats.Search]
-baseName = "search"
+[outputFormats.Algolia]
+baseName = "algolia"
 isPlaintext = true
 mediaType = "application/json"
 notAlternative = true

 [outputs]
-home = ["HTML", "RSS", "Search"]
-page = ["HTML", "Search"]
+home = ["HTML", "RSS", "Algolia"]
+# page = ["HTML", "Algolia"]

-[params.search]
-vars = ["title","summary","date","publishdate","expirydate","permalink"]
-params = ["categories","tags"]
+[params.algolia]
+vars = ["title", "summary", "date", "publishdate", "expirydate", "permalink"]
+params = ["categories", "tags"]

 [[menu.main]]
 identifier = "what-is-rancher"
@@ -14,7 +14,7 @@ Once you've installed your AWS CLI, use this command to launch an EC2 instance w
 > **Note:** Check the RancherOS [README](https://github.com/rancher/os/blob/master/README.md) for AMI names for each region. We support PV and HVM types of AMIs.

 ```
-$ aws ec2 run-instances --image-id ami-ID# --count 1 --instance-type t2.micro --key-name MySSHKeyName --security-groups sg-name
+$ aws ec2 run-instances --image-id ami-ID# --count 1 --instance-type t2.small --key-name MySSHKeyName --security-groups sg-name
 ```

 Your EC2 instance is now running RancherOS!
@@ -87,7 +87,7 @@ To run this container in System Docker use the following command:
 ```
 $ sudo system-docker run -d --net=host --name busydash husseingalal/busydash
 ```
-In the commad, we used `--net=host` to tell System Docker not to containerize the container's networking, and use the host’s networking instead. After running the container, you can see the monitoring server by accessing `http://<IP_OF_MACHINE>`.
+In the command, we used `--net=host` to tell System Docker not to containerize the container's networking, and use the host’s networking instead. After running the container, you can see the monitoring server by accessing `http://<IP_OF_MACHINE>`.

 ![System Docker Container]({{< baseurl >}}/img/os/Rancher_busydash.png)

@@ -104,7 +104,7 @@ $ sudo chmod 755 /opt/rancher/bin/start.sh
 Another useful command that can be used with RancherOS is `ros` which can be used to control and configure the system.

 ```
-$ ros -v
+$ sudo ros -v
 ros version 0.0.1
 ```

@@ -0,0 +1,15 @@
+---
+title: Admin Settings
+weight: 1100
+aliases:
+  - /rancher/v2.x/en/concepts/global-configuration/
+  - /rancher/v2.x/en/tasks/global-configuration/
+---
+
+After installing Rancher 2.0, you should
+
+1. Set a Rancher Server URL, which your cluster nodes will use to resolve with Rancher. You'll be prompted to set this URL upon your first log in.
+
+2. Set up external user authentication and permissions so that your organization can log into Rancher.
+
+After making these initial configurations, you might also want to configure one or more _pod security policies_, which are sets of conditions that your pods must meet for Kubernetes to allow them to run.
@@ -1,7 +1,11 @@
 ---
 title: Authentication
-weight: 10
+weight: 50
+aliases:
+    -/rancher/v2.x/en/concepts/global-configuration/authentication/
+    -/rancher/v2.x/en/tasks/global-configuration/authentication/
 ---
+
 One of the key features that Rancher adds to Kubernetes is centralized user authentication. This feature allows your users to use one set of credentials to authenticate with any of your Kubernetes clusters.

 This centralized user authentication is accomplished using the Rancher authentication proxy, which is installed along with the rest of Rancher. This proxy authenticates your users and forwards their requests to your Kubernetes clusters using a service account.
@@ -13,12 +17,17 @@ This centralized user authentication is accomplished using the Rancher authentic
 The Rancher authentication proxy integrates with the following external authentication services.

 - Microsoft Active Directory
+- Microsoft Azure AD
 - GitHub
+- FreeIPA
+- OpenLDAP

 However, Rancher also provides local authentication.

 In most cases, you should use an external authentication service over local, as external authentication allows user management from a central location. However, you may want a few local authentication users for managing Rancher under rare circumstances, such as if Active Directory is down.

+For more information on how to configure external authentication or local authentication, see [Authentication](../../../tasks/global-configuration/authentication/). 
+
 ### External Authentication Configuration and Principal Users

 Configuration of external authentication requires:
@@ -0,0 +1,54 @@
+---
+title: Configuring Active Directory (AD)
+weight: 50
+aliases:
+    -/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/
+---
+
+In environments using Microsoft AD, you can configure Rancher to allow sign on using AD credentials.
+
+>**Prerequisites:**
+>
+>- Have an AD server configured.
+>- Create a service account in AD with `read-only` access. Rancher uses this account to verify group membership when a user makes a request using an API key.
+>- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
+
+1.  Sign into Rancher using a local user assigned `administrator` global permissions (i.e., the _local principal_).
+
+2.	From the **Global** view, select **Security > Authentication** from the main menu.
+
+3.	Select **AD**.
+
+4.	Complete the **Configure an AD server** form.
+
+	You may need to log in to your domain controller to find the information requested in the form.
+
+	>**Using TLS?**
+ 	>If the certificate is self-signed or not from a recognized certificate authority, make sure you provide the complete chain. That chain is needed to verify the server's certificate.
+	<br/>
+	<br/>
+	>**User Search Base vs. Group Search Base**
+	>
+	>Search base allows Rancher to search for users and groups that are in your AD.  These fields are only for search bases and not for search filters.
+	>
+	>* If your users and groups are in the same search base, complete only the User Search Base.
+	>* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required.
+
+5.	If your AD deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step.
+
+	>**Search Attribute** As of Rancher v2.0.1, the Search Attribute field defaults with three specific values: `sAMAccountName|sn|givenName`. After AD is configured, when a user enters text to add users or groups, Rancher automatically queries the AD server and attempts to match fields by sAMAccountName, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field.
+	>
+	>The default field value `sAMAccountName|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields.
+	>
+	> * `sAMAccountName`: Username
+	> * `sn`: Last Name
+	> * `givenName`: First Name
+	>
+	> With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field.
+
+6.	Enter your AD username and password in **Authenticate with AD** to confirm that Rancher is configured to use AD authentication.
+
+**Result:**
+
+- AD authentication is configured.
+- You are signed into Rancher with your AD account (i.e., the _external principal_).
@@ -1,10 +1,16 @@
 ---
-title: Configuring Azure Active Directory
-weight: 3075
+title: Configuring Azure AD
+weight: 75
+aliases:
+    -/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/
 ---

+_Available as of v2.0.3_
+
 If you have an instance of Active Directory (AD) hosted in Azure, you can configure Rancher to allow your users to log in using their AD accounts. Configuration of Azure AD external authentication requires you to make configurations in both Azure and Rancher.

+>**Prerequisite:** Have an instance of Azure AD configured.
+
 >**Note:** Most of this procedure, with the exception of [Configure Azure AD in Rancher](#configure-azure-ad-in-rancher), takes place from the [Microsoft Azure Portal](https://portal.azure.com/).

 ## Azure Active Directory Configuration Outline
@@ -13,7 +19,7 @@ Configuring Rancher to allow your users to authenticate with their Azure AD acco

 <a id="tip"></a>

->**Tip:** Before you start, we recommend creating an empty text file. You can use this file to copy values from Azure that you'll paste into Rancher later. 
+>**Tip:** Before you start, we recommend creating an empty text file. You can use this file to copy values from Azure that you'll paste into Rancher later.

 1. [Register Rancher with Azure](#1-register-rancher-with-azure)

@@ -54,7 +60,7 @@ Before enabling Azure AD within Rancher, you must register Rancher with Azure.
    1. From **Application type**, make sure that **Web app / API** is selected.

    1. In the **Sign-on URL** field, enter the URL of your Rancher Server.
-    
+
    1. Click **Create**.

 ### 2. Create an Azure API Key
@@ -122,29 +128,29 @@ As your final step in Azure, copy the data that you'll use to configure Rancher
    1. Use search to open the **Azure Active Directory** service.

         ![Open Azure Active Directory]({{< baseurl >}}/img/rancher/search-azure-ad.png)
-    
+
    1. From the **Azure Active Directory** menu, open **Properties**.
-    
+
    2. Copy the **Directory ID** and paste it into your [text file](#tip).
-    
+
        You'll paste this value into Rancher as your **Tenant ID**.

 1. Obtain your Rancher **Application ID**.
-    
+
    1. Use search to open **App registrations**.

         ![Open App Registrations]({{< baseurl >}}/img/rancher/search-app-registrations.png)
-    
+
    1. Find the entry you created for Rancher.
-    
+
    1. Copy the **Application ID** and paste it to your [text file](#tip).

 1. Obtain your Rancher **Graph Endpoint**, **Token Endpoint**, and **Auth Endpoint**.
-    
+
    1. From **App registrations**, click **Endpoints**.

        ![Click Endpoints]({{< baseurl >}}/img/rancher/click-endpoints.png)
-    
+
    2. Copy the following endpoints to your clipboard and paste them into your [text file](#tip) (these values will be your Rancher endpoint values).

        - **Microsoft Azure AD Graph API Endpoint** (Graph Endpoint)
@@ -0,0 +1,56 @@
+---
+title: Configuring FreeIPA
+weight: 150
+aliases:
+    -/rancher/v2.x/en/tasks/global-configuration/authentication/freeipa/
+---
+
+_Available as of v2.0.5_
+
+If your organization uses FreeIPA for user authentication, you can configure Rancher to allow your users to login using their FreeIPA credentials.
+
+>**Prerequisites:**
+>
+>- You must have a [FreeIPA Server](https://www.freeipa.org/) configured.
+>- Create a service account in FreeIPA with `read-only` access. Rancher uses this account to verify group membership when a user makes a request using an API key.
+>- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
+
+1.  Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_).
+
+2.	From the **Global** view, select **Security > Authentication** from the main menu.
+
+3.	Select **FreeIPA**.
+
+4.	Complete the **Configure an FreeIPA server** form.
+
+	You may need to log in to your domain controller to find the information requested in the form.
+
+	>**Using TLS?**
+ 	>If the certificate is self-signed or not from a recognized certificate authority, make sure you provide the complete chain. That chain is needed to verify the server's certificate.
+	<br/>
+	<br/>
+	>**User Search Base vs. Group Search Base**
+	>
+	>Search base allows Rancher to search for users and groups that are in your FreeIPA.  These fields are only for search bases and not for search filters.
+	>
+	>* If your users and groups are in the same search base, complete only the User Search Base.
+	>* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required.
+
+5.	If your FreeIPA deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step.
+
+	>**Search Attribute** The Search Attribute field defaults with three specific values: `uid|sn|givenName`. After FreeIPA is configured, when a user enters text to add users or groups, Rancher automatically queries the FreeIPA server and attempts to match fields by user id, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field.
+	>
+	>The default field value `uid|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields.
+	>
+	> * `uid`: User ID
+	> * `sn`: Last Name
+	> * `givenName`: First Name
+	>
+	> With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field.
+
+6.	Enter your FreeIPA username and password in **Authenticate with FreeIPA** to confirm that Rancher is configured to use FreeIPA authentication.
+
+**Result:**
+
+- FreeIPA authentication is configured.
+- You are signed into Rancher with your FreeIPA account (i.e., the _external principal_).
@@ -1,11 +1,13 @@
 ---
-title: Configuring GitHub Authentication
-weight: 3075
+title: Configuring GitHub
+weight: 100
+aliases:
+    -/rancher/v2.x/en/tasks/global-configuration/authentication/github/
 ---

 In environments using GitHub, you can configure Rancher to allow sign on using GitHub credentials.

->**Prerequisites:** Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users).
+>**Prerequisites:** Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).

 1.  Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_).

@@ -48,4 +50,4 @@ In environments using GitHub, you can configure Rancher to allow sign on using G
 **Result:**

 - GitHub authentication is configured.
- You are signed into Rancher with your GitHub account (i.e., the _external principal_).
+- You are signed into Rancher with your GitHub account (i.e., the _external principal_).
@@ -1,9 +1,11 @@
 ---
 title: Configuring Local Authentication
-weight: 3075
+weight: 25
+aliases:
+    -/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/
 ---

-Regardless of whether you use external authentication, you should create a few local authentication users so that you can continue using Rancher if you your external authentication service encounters issues. 
+Regardless of whether you use external authentication, you should create a few local authentication users so that you can continue using Rancher if you your external authentication service encounters issues.

 1.	From the **Global** view, select **Users** from the main menu.

@@ -0,0 +1,57 @@
+---
+title: Configuring OpenLDAP
+weight: 125
+aliases:
+    -/rancher/v2.x/en/tasks/global-configuration/authentication/openLDAP/
+---
+
+_Available as of v2.0.5_
+
+If your organization uses OpenLDAP for user authentication, you can configure Rancher to allow your users to login using their OpenLDAP credentials.
+
+>**Prerequisites:**
+>
+>- You must have an [OpenLDAP Server](https://www.openldap.org/) configured.
+>- Create a service account in OpenLDAP with `read-only` access. Rancher uses this account to verify group membership when a user makes a request using an API key.
+>- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
+
+1.  Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_).
+
+2.	From the **Global** view, select **Security > Authentication** from the main menu.
+
+3.	Select **OpenLDAP**.
+
+4.	Complete the **Configure an OpenLDAP server** form.
+
+	You may need to log in to your domain controller to find the information requested in the form.
+
+	>**Using TLS?**
+ 	>If the certificate is self-signed or not from a recognized certificate authority, make sure you provide the complete chain. That chain is needed to verify the server's certificate.
+	<br/>
+	<br/>
+	>**User Search Base vs. Group Search Base**
+	>
+	>Search base allows Rancher to search for users and groups that are in your openLDAP.  These fields are only for search bases and not for search filters.
+	>
+	>* If your users and groups are in the same search base, complete only the User Search Base.
+	>* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required.
+
+
+5.	If your OpenLDAP deviates from the standard OpenLDAP schema, complete the **Customize Schema** form to match it. Otherwise, skip this step.
+
+	>**Search Attribute** The Search Attribute field defaults with three specific values: `uid|sn|givenName`. After openLDAP is configured, when a user enters text to add users or groups, Rancher automatically queries the openLDAP server and attempts to match fields by user id, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field.
+	>
+	>The default field value `uid|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields.
+	>
+	> * `uid`: User ID
+	> * `sn`: Last Name
+	> * `givenName`: First Name
+	>
+	> With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field.
+
+6.	Enter your OpenLDAP username and password in **Authenticate with OpenLDAP** to confirm that Rancher is configured to use OpenLDAP authentication.
+
+**Result:**
+
+- OpenLDAP authentication is configured.
+- You are signed into Rancher with your OpenLDAP account (i.e., the _external principal_).
@@ -1,7 +1,26 @@
 ---
 title: Pod Security Policies
-weight: 125
+weight: 100
+aliases:
+    -/rancher/v2.x/en/concepts/global-configuration/pod-security-policies
+    -/rancher/v2.x/en/tasks/global-configuration/pod-security-policies
 ---
+
+_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification (like root privileges). If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message of `Pod <NAME> is forbidden: unable to validate...`.
+
+- You can assign PSPs at the cluster or project level.
+- PSPs work through inheritance.
+
+    - By default, PSPs assigned to a cluster are inherited by its projects, as well as any namespaces added to those projects.
+    - **Exception:** Namespaces that are not assigned to projects do not inherit PSPs, regardless of whether the PSP is assigned to a cluster or project. Because these namespaces have no PSPs, workload deployments to these namespaces will fail, which is the default Kubernetes behavior.
+    - You can override the default PSP by assigning a different PSP directly to the project.
+- Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked if it complies with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP.
+
+Read more about Pod Security Policies in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
+
+>**Best Practice:**
+>Set Pod Security at the cluster level.
+
 Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file.

 ## Creating Pod Security Policies
@@ -1,8 +1,16 @@
 ---
 title: Rancher Server URL
 weight: 25
+aliases:
+    -/rancher/v2.x/en/concepts/global-configuration/server-url
+    -/rancher/v2.x/en/tasks/global-configuration/server-url
 ---

+This is the URL of your Rancher Server. All nodes in your cluster must resolve to this URL.
+
+- You are prompted for this URL upon the very first Rancher login.
+- You can edit this URL later by selecting **Settings**.
+
 The first time that you log into {{< product >}}, the system prompts you for the Rancher Server URL, which is the IP address or host name that your Kubernetes nodes register with.

 If you need to update this URL, select **Settings** from the **Global** view.
@@ -1,9 +1,11 @@
 ---
-title: Users, Global Permissions, and Roles
-weight: 15
+title: RBAC
+weight: 75
+aliases:
+    -/rancher/v2.x/en/admin-settings/rbac/
 ---

-Within Rancher, each user authenticates as a _user_, which is a login that grants you access to Rancher. As mentioned in [Authenitcation]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication), users can either be local or external.
+Within Rancher, each person authenticates as a _user_, which is a login that grants you access to Rancher. As mentioned in [Authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication), users can either be local or external.

 After you configure external authentication, the users that display on the **Users** page changes.

@@ -1,7 +1,10 @@
 ---
-title: Roles
-weight: 100
+title: Creating Roles
+weight: 25
+aliases:
+    -/rancher/v2.x/en/tasks/global-configuration/roles/
 ---
+
 Within Rancher, _roles_ determine what actions a user can make within a cluster or project.

 Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access.
@@ -10,8 +13,8 @@ Note that _roles_ are different from _permissions_, which determine what cluster
 >
 >To complete the tasks on this page, the following permissions are required:
 >
->- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#global-permissions).
->- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#custom-global-permissions) with the [Manage Roles]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#global-permissions-reference) role assigned.
+>- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#global-permissions).
+>- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#custom-global-permissions) with the [Manage Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#global-permissions-reference) role assigned.

 ## Adding A Custom Role

@@ -23,7 +26,7 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als

 3.	**Name** the role.

-4.	Choose whether to set the role to a status of [locked]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#locked-roles).
+4.	Choose whether to set the role to a status of [locked]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#locked-roles).

 	Locked roles cannot be assigned to users.

@@ -51,7 +54,7 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als

 ## Locking/Unlocking Roles

-If you want to prevent a role from being assigned to users, you can set it to a status of `locked`. For more information about what this status means, see [Locked Roles]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#locked-roles).
+If you want to prevent a role from being assigned to users, you can set it to a status of `locked`. For more information about what this status means, see [Locked Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#locked-roles).

 You can lock roles in two contexts:

@@ -1,10 +1,10 @@
 ---
-title: Restoring Backups—High Availablity Installs
+title: Restoring Backups—High Availability Installs
 weight: 370
 aliases:
  - /rancher/v2.x/en/installation/after-installation/ha-backup-and-restoration/
 ---
-This procedure describes how to restore your a snapshot of  `etcd` if you lose your Rancher data in a disaster scenario.
+This procedure describes how to restore your a snapshot of `etcd` if you lose your Rancher data in a disaster scenario.

 ## Restoration Outline

@@ -56,9 +56,9 @@ docker ps | grep calico | cut -f 1 -d " " | xargs docker restart

 To restore the most recent `etcd` snapshot on your new node, run RKE the command `rke etcd snapshot-restore`. This command reverts to any snapshot stored in `/opt/rke/etcd-snapshots` that you explicitly define. When you run `rke etcd snapshot-restore`, RKE removes the old `etcd` container if it still exists. To restore operations, RKE creates a new `etcd` cluster using the snapshot you choose.

->**Important:** When restoring the etcd database, you must restore each `etcd` to the _same_ snapshot, this means the exact same copy, so to restore you have to copy the snapshot from one of the nodes to the others before doing the `etcd snapshot-restore`.
-
 >**Warning:** Restoring an `etcd` snapshot deletes your current `etcd` cluster and replaces it with a new one. Before you run the `rke etcd snapshot-restore` command, backup any important data in your current cluster.
+>
+>**Prerequisites:** {{< requirements_rollback >}}


 1. From your workstation, open `rancher-cluster.yml` in your favorite text editor.
@@ -1,6 +1,8 @@
 ---
 title: Rolling Back—High Availability Installs
 weight: 50
+aliases:
+  - /rancher/v2.x/en/upgrades/rollbacks/ha-server-rollbacks/
 ---

 If you upgrade Rancher, but the upgrade does not complete successfully, you may need to roll back your Rancher Server to its last healthy state before upgrade. To restore Rancher:
@@ -11,6 +13,7 @@ If you upgrade Rancher, but the upgrade does not complete successfully, you may
 >**Warning!**
 >
 > Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
+
 >
 >**Prerequisites:** {{< requirements_rollback >}}

@@ -1,8 +1,18 @@
 ---
 title: Catalogs and Charts
-weight: 2250
+weight: 4000
+aliases:
+  - /rancher/v2.x/en/concepts/global-configuration/catalog/
+  - /rancher/v2.x/en/tasks/global-configuration/catalog/
 ---

+This section includes step-by-step instruction on how to configure default and custom catalogs.
+
+- [Enabling Default Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/enabling-default-catalogs)
+- [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/adding-custom-catalogs)
+- [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/customizing-charts)
+
+
 _Catalogs_ are GitHub repositories filled with applications that are ready-made for deployment. Applications are bundled in objects called _charts_.

 _Charts_ are a packaging format popularized by [Helm](https://docs.helm.sh/). Think of them as templates for deployments. Per Helm, charts are:
@@ -18,7 +28,7 @@ Within Rancher, you can access several different catalogs either by default or t
 - **Library**

 	The Library Catalog includes charts curated by Rancher. Rancher stores charts in a Git repository to expedite the fetch and update of charts. In Rancher 2.0, only global catalogs are supported. Support for cluster-level and project-level charts will be added in the future.
-	
+
 	This catalog features Rancher Charts, which include some [notable advantages](#chart-types) over native Helm charts.

 - **Helm Stable**
@@ -32,9 +42,9 @@ Within Rancher, you can access several different catalogs either by default or t
 - **Custom**

 	Finally, you have the option of building your own catalogs. Custom catalogs are useful when you have a handful of apps that you deploy regularly in a specific configuration.
- 
+
 ### Custom Catalog Creation
-	
+
 Creating a custom catalog for Rancher is straightforward. Create a Git repo and then direct Rancher toward the repo.

 Custom catalog requirements include:
@@ -42,7 +52,7 @@ Custom catalog requirements include:
 - A unique name.
 - A URL that `git clone` can handle.

-For step-by-step directions, see [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs).
+For step-by-step directions, see [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/adding-custom-catalogs).

 When you're done creating the catalog, populate it with charts. Custom catalogs can support both native Helm charts and Rancher charts. See [Custom Chart Creation](#custom-chart-creation).

@@ -132,15 +142,15 @@ The following table demonstrates the directory structure for a chart, which can
 Before you create your own custom catalog, you should have a basic understanding about how a Rancher chart differs from a native Helm chart. Rancher charts differ slightly from Helm charts in their directory structures. Rancher charts include two files that Helm charts do not.

 - `app-readme.md`
-      
+
    A file that provides descriptive text in the chart's UI header. The following image displays the difference between a Rancher chart (which includes `app-readme.md`) and a native Helm chart (which does not).

 	<small>Rancher Chart with <code>app-readme.md</code> (left) vs. Helm Chart without (right)</small>

 	![app-readme.md]({{< baseurl >}}/img/rancher/app-readme.png)
-      
+
 - `questions.yml`
-    
+
    A file that contains questions for a form. These form questions simplify deployment of a chart. Without it, you must configure the deployment using key value pairs, which is more difficult. The following image displays the difference between a Rancher chart (which includes `questions.yml`) and a native Helm chart (which does not).


@@ -153,6 +163,6 @@ Before you create your own custom catalog, you should have a basic understanding

 You can fill your custom catalogs with either Helm Charts or Rancher Charts, although we recommend Rancher Charts due to their enhanced user experience.

- For information on how to add and customize charts for a custom catalog, see [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts).
+ For information on how to add and customize charts for a custom catalog, see [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/customizing-charts).

 >**Note:** For a complete walkthrough of developing charts, see the upstream Helm chart [developer reference](https://docs.helm.sh/developing_charts/).
@@ -1,6 +1,8 @@
 ---
 title: Adding Custom Catalogs
-weight: 50
+weight: 4015
+aliases:
+  - /rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs/
 ---

 You can create custom catalogs of charts for use in Rancher. Custom catalogs are helpful for fast deployment of applications unique to your environment.
@@ -23,8 +25,8 @@ You can create custom catalogs of charts for use in Rancher. Custom catalogs are
 2. Click **Add Catalog**.
 3. Complete the form and click **Create**.

-**Result**: Your catalog is added to Rancher. 
+**Result**: Your catalog is added to Rancher.

 ## What's Next?

-Add native Helm charts, Rancher charts, or both to your repository. For more information, see [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts/).
+Add native Helm charts, Rancher charts, or both to your repository. For more information, see [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/customizing-charts/).
@@ -1,6 +1,8 @@
 ---
 title: Customizing Charts
-weight: 75
+weight: 4020
+aliases:
+  - /rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts/
 ---

 Before you can deploy customized catalog apps using Rancher, you must add charts to the GitHub repository serving as your custom catalog.
@@ -11,7 +13,7 @@ The custom catalog can contain native Helm charts, Rancher charts, or a combinat

 >- Recommended: Read [Catalogs and Charts]({{< baseurl >}}/rancher/v2.x/en/concepts/catalogs).
 >- Create a GitHub repository to serve as your custom catalog.
->- Complete [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs).
+>- Complete [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/adding-custom-catalogs).

 >**Note:** Customization of Helm charts takes place outside of the Rancher UI.

@@ -19,7 +21,7 @@ The custom catalog can contain native Helm charts, Rancher charts, or a combinat

    Rancher requires this directory structure, although `app-readme.md` and `questions.yml` are optional.

-    >**Tip:** 
+    >**Tip:**
    >
    >- To begin customizing a chart, copy one from either the [Rancher Library](https://github.com/rancher/charts) or the [Helm Stable](https://github.com/kubernetes/charts/tree/master/stable).
    >- For a complete walk through of developing charts, see the upstream Helm chart [developer reference](https://docs.helm.sh/developing_charts/).
@@ -1,21 +1,23 @@
 ---
 title: Enabling Default Catalogs
-weight: 25
+weight: 4005
+aliases:
+  - /rancher/v2.x/en/tasks/global-configuration/catalog/enabling-default-catalogs/
 ---

-Out-of-the-box, you can enable several different catalog repositories to simplify deployment of applications. 
+Out-of-the-box, you can enable several different catalog repositories to simplify deployment of applications.

 1. From the **Global** view, choose **Catalogs** from the main menu.
 2. Toggle the default catalogs that you want use to a setting of **Enabled**. The [default catalogs]({{< baseurl >}}/rancher/v2.x/en/concepts/catalogs/#catalog-types) are:
-    
+
    - **Library**
    - **Helm Stable**
    - **Helm Incubator**

-    >**Note:** If you want to use a custom catalog, see [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs) instead of this topic.
+    >**Note:** If you want to use a custom catalog, see [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog-and-charts/adding-custom-catalogs) instead of this topic.

 **Result:** The chosen catalogs are enabled. Wait a few minutes for Rancher to replicate the catalog charts. When replication completes, you'll be able to see them in any of your projects by selecting **Catalog Apps** from the main menu.

 ## What's Next?

-Deploy catalog applications to your cluster nodes. For more information, see [Launching a Catalog App]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/launch-a-catalog-app).
+Deploy catalog applications to your cluster nodes. For more information, see [Launching a Catalog App]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/launch-a-catalog-app).
@@ -0,0 +1,4 @@
+---
+title: Launching Catalog Applications
+weight: 4010
+---
@@ -1,6 +1,8 @@
 ---
 title: Rancher CLI
-weight: 1
+weight: 6000
+aliases:
+  - /rancher/v2.x/en/concepts/cli-configuration/
 ---

 Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.
@@ -14,7 +16,7 @@ The binary can be downloaded directly from the UI. The link can be found in the
 After you download the Rancher CLI, you need to make a few configurations. Rancher CLI requires:

 - Your [Rancher Server URL]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/server-url), which is used to connect to Rancher Server.
- An API Bearer Token, which is used to authenticate with Rancher. For more information about obtaining a Bearer Token, see [Creating an API Key]({{< baseurl >}}/rancher/v2.x/en/tasks/user-settings/api-keys/_index.md).
+- An API Bearer Token, which is used to authenticate with Rancher. For more information about obtaining a Bearer Token, see [Creating an API Key]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/).

 ### CLI Authentication

@@ -62,7 +64,7 @@ The following commands are available for use in Rancher CLI.

 - `clusters, [cluster]`

-    Performs operations on your [clusters]({{< baseurl >}}/rancher/v2.x/en/concepts/clusters).
+    Performs operations on your [clusters]({{< baseurl >}}/rancher/v2.x/en/clusters/).

 - `context`

@@ -0,0 +1,72 @@
+---
+title: Creating Kubernetes Clusters
+weight: 2000
+aliases:
+  - /rancher/v2.x/en/concepts/clusters/
+  - /rancher/v2.x/en/concepts/clusters/cluster-providers/
+  - /rancher/v2.x/en/tasks/clusters/
+  - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/
+---
+
+## What's a Kubernetes Cluster?
+
+A cluster is a group of computing resources that work as a team to accomplish a goal. Each individual computer in a cluster is called a _node_.
+
+## Cluster Creation
+
+Rancher simplifies creation of Kubernetes clusters by allowing you to create them with the Rancher UI rather than a config file.
+
+### Node Components
+
+A Kubernetes cluster contains 3 types of nodes: etcd nodes, control plane nodes, and worker nodes.
+
+#### etcd Nodes
+
+The etcd nodes are used to run the etcd database. etcd is a key value store used as Kubernetes’ backing store for all cluster data. Even though you can run etcd on a single node, you need 3, 5, or 7 nodes for redundancy.
+
+#### Control Plane Nodes
+
+The control plane nodes are used to run the Kubernetes API server, scheduler, and controller manager. Control plane nodes are stateless since all cluster data are stored on etcd nodes. You can run control plane on 1 node, although 2 or more nodes are required for redundancy. You can also run control plane on etcd nodes.
+
+#### Worker Nodes
+
+Worker nodes are used to run the kubelet and the workload. It also runs the storage and networking drivers and ingress controllers when required. You create as many worker nodes as needed for your workload needs.
+
+
+Using Rancher, you can create Kubernetes clusters using a variety of options. Use the option that best fits your use case.
+
+## Hosted Kubernetes Providers
+
+By integrating with cloud APIs, Rancher lets you create new Kubernetes clusters through hosted providers, all within the Rancher UI. You can create clusters using either:
+
+- A hosted Kubernetes provider, such as Google GKE, Amazon EKS, or Microsoft AKS.
+- An IaaS provider, using nodes provided from Amazon EC2, Microsoft Azure, or DigitalOcean.
+
+## Rancher-Launched Kubernetes
+
+Alternatively, you can use Rancher to create a cluster from your own existing nodes, using RKE. RKE is Rancher’s own lightweight Kubernetes installer. It works with any bare metal server, cloud provider, or virtualization platform. It integrates with node drivers to automatically provision nodes on AWS, Azure, DigitalOcean, vSphere, OpenStack, etc. Users can add custom nodes to the cluster by running the Rancher agent on these nodes.
+
+## Kubernetes Importation
+
+Finally, you also have the option of importing an existing Kubernetes cluster that you're already using into Rancher.
+
+
+Using Rancher, you can create Kubernetes clusters using a variety of options. Use the option that best fits your use case.
+
+## Hosted Kubernetes Providers
+
+If you already have a cluster hosted by a Kubernetes provider such as Google GKE, Rancher can integrate with its cloud APIs, allowing you to manage your hosted cluster from the Rancher UI.
+
+## Infrastructure Providers
+
+Using Rancher, you can leverage APIs from major IaaS providers to create nodes and provision a new Kubernetes cluster.
+
+## From Existing Nodes
+
+Use Rancher to create a Kubernetes cluster on your on-premise bare metal servers. This option creates a cluster using RKE, which is Rancher's own lightweight Kubernetes installer.
+
+In addition to bare metal servers, RKE can also create clusters on less popular IaaS providers by integrating with node drivers.
+
+## Import Existing Clusters
+
+Users can import an existing Kubernetes cluster into Rancher. Rancher does not automate the provisioning, scaling, and upgrade of imported Kubernetes clusters. All other cluster management, policy management, and workload management capabilities of Rancher apply to imported clusters.
@@ -0,0 +1,6 @@
+---
+title: Creating a Custom Cluster
+shortTitle: Custom Cluster
+weight: 2400
+
+---
@@ -0,0 +1,54 @@
+---
+title: Hosted Kubernetes Providers
+weight: 2100
+---
+
+If you already have a cluster hosted by a Kubernetes provider, Rancher can integrate with its cloud APIs, allowing you to manage your hosted cluster from the Rancher UI.
+
+Rancher supports the following Kubernetes providers:
+
+<!-- TOC -->
+
+- [Google GKE (Google Container Engine)](#google-gke-google-container-engine)
+- [Amazon EKS (Elastic Container Service)](#amazon-eks-elastic-container-service)
+- [Microsoft AKS (Azure Container Service)](#microsoft-aks-azure-container-service)
+
+<!-- /TOC -->
+
+When setting up management of your hosted Kubernetes cluster in the Rancher UI, you are prompted for parameters required in all cluster creation scenarios: cluster name, user membership, how many nodes to create, and so on. However, each provider also requires information unique to the vendor. See more information about the information required for each provider below.
+
+## Google GKE (Google Container Engine)
+
+Before Rancher can manage a Google GKE cluster, you must create a service account with Google. This account also requires you to assign it the appropriate roles.
+
+Create a service account using [Google Cloud Platform](https://console.cloud.google.com/projectselector/iam-admin/serviceaccounts). GKE uses this account to operate your cluster. Creating this account also generates a private key used for authentication.
+
+The service account requires the following roles:
+
+-	`project/viewer`
+-	`kubernetes-engine/admin`
+-	`service-account/user`
+
+For full instructions on how to complete these actions, see [Creating and Enabling Service Accounts](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances).
+
+After you create a service account, enter your service account private key into Rancher.
+
+## Amazon EKS (Elastic Container Service)
+
+Before Rancher can manage an Amazon EKS cluster, you must provide it with an Amazon access key that has the appropriate permissions assigned to it.
+
+Log into the [Amazon AWS Management Console](https://aws.amazon.com/console/) to assign yourself the appropriate IAM permissions and create an access key. Complete the actions below.
+
+- Assign the account you're using the IAM permissions to create clusters, modify clusters, and use the required API actions. For more information, see the official [EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html).
+
+- Create an Amazon access key and secret key. For more information, see [Managing Access Keys for IAM Users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)
+
+After you complete the two actions above, enter your access key and secret key in Rancher.
+
+## Microsoft AKS (Azure Container Service)
+
+Before Rancher can manage a Microsoft AKS cluster, you must provide it with information from your Azure Active Directory Service Principal (here after, _service principal_). Rancher uses this service principal to interact with the Azure API.
+
+For instruction on how to create a service principal, see [Service Principals with Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/kubernetes-service-principal).
+
+After you complete the action above, enter the information from your service principal in Rancher.
@@ -1,7 +1,9 @@
 ---
 title: Creating an AKS Cluster
 shortTitle: Azure Container Service
-weight: 3350
+weight: 2115
+aliases:
+  - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-azure-container-service/_index.md
 ---

 You can use Rancher to create a cluster using Microsoft Azure Container Service.
@@ -1,7 +1,9 @@
 ---
 title: Creating an EKS Cluster
 shortTitle: Amazon EKS
-weight: 3325
+weight: 2110
+aliases:
+  - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-eks/_index.md
 ---
 ## Objectives

@@ -1,7 +1,9 @@
 ---
 title: Creating a GKE Cluster
 shortTitle: Google Container Engine
-weight: 3325
+weight: 2105
+aliases:
+  - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-gke/_index.md
 ---
 ## Objectives

@@ -1,6 +1,8 @@
 ---
-title: Importing a Cluster
-weight: 3400
+title: Importing Kubernetes Clusters
+weight: 2300
+aliases:
+  - /rancher/v2.x/en/tasks/clusters/import-cluster/
 ---

 You can import an existing Kubernetes cluster and then manage it using Rancher.
@@ -31,4 +33,4 @@ You can import an existing Kubernetes cluster and then manage it using Rancher.
 {{< result_create-cluster >}}

 > **Note:**
-> You can not re-import a cluster that is currently active in a Rancher setup. 
+> You can not re-import a cluster that is currently active in a Rancher setup.
@@ -0,0 +1,55 @@
+---
+title: Adding Users to Clusters
+weight: 2500
+aliases:
+  - /rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/
+---
+
+If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership.
+
+>**Tip:** Want to provide a user with access to a _specific_ project within a cluster? See [Adding Project Members]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-project-members/) instead.
+
+There are two contexts where you can add cluster members:
+
+- [Adding Members to a New Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster)
+
+    You can add members to a cluster as you create it (recommended if possible).
+
+- [Adding Members to an Existing Cluster](#adding-members-to-an-existing-cluster)
+
+    You can always add members to a cluster later. See below.
+
+### Adding Members to an Existing Cluster
+
+Following cluster creation, you can add users as cluster members so that they can access its resources.
+
+1. From the **Global** view, open the cluster that you want to add members to.
+
+2. From the main menu, select **Members**. Then click **Add Member**.
+
+3. Search for the user or group that you want to add to the cluster.
+
+ 	If external authentication is configured:
+
+	-  Rancher returns users from your [external authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/) source as you type.
+
+		>**Using AD but can't find your users?**
+		>There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/).
+
+	- A drop-down allows you to add groups instead of individual users. The drop-down only lists groups that you, the logged in user, are part of.
+
+		>**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users).
+
+4. Assign the user or group **Cluster** roles.  
+
+	[What are Cluster Roles?]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#cluster-roles)
+
+	>**Tip:** For Custom Roles, you can modify the list of individual roles available for assignment.
+	>
+	> - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#adding-a-custom-role).
+	> - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#locking-unlocking-roles).
+
+**Result:** The chosen users are added to the cluster.
+
+- To revoke cluster membership, select the user and click **Delete**. This action deletes membership, not the user.
+- To modify a user's roles in the cluster, delete them from the cluster, and then re-add them with modified roles.
@@ -0,0 +1,25 @@
+---
+title: Rancher Launched Kubernetes
+weight: 2200
+---
+
+## Infrastructure Providers
+
+Using Rancher, you can leverage APIs from major IaaS providers to create nodes and provision a new Kubernetes cluster, all from the Rancher UI. There's no need to log directly into your infrastructure providers's portal.
+
+You can create provider-hosted nodes from the Rancher UI by creating a node template. After providing Rancher with an access token from the vendor you're using, Rancher prompts you for specifications that it will send to your provider by API. The provider than provisions your nodes based on the template.
+
+Out-of-the-box, Rancher supports the following infrastructure providers:
+
+- Amazon EC2
+- Microsoft Azure
+- DigitalOcean
+- VMWare Vsphere
+
+Each vendor requires specific information that's used to authenticate with the provider API. Read more below to learn about the information required for each provider.
+
+## From Existing Nodes
+
+Use Rancher to create a Kubernetes cluster on your on-premise bare metal servers. This option creates a cluster using RKE, which is Rancher's own lightweight Kubernetes installer. In addition to bare metal servers, RKE can also create clusters on _any_ IaaS providers by integrating with node drivers.
+
+To use this option you'll need access to servers you intend to use as your Kubernetes cluster. Provision each server according to Rancher requirements, which includes some hardware specifications and Docker. After you install Docker on each server, run the command provided in the Rancher UI to turn each server into a Kubernetes node. 
@@ -1,7 +1,9 @@
 ---
-title: Creating a Custom Cluster
-shortTitle: Custom Cluster
-weight: 3225
+title: Creating a Cluster with Custom Nodes
+shortTitle: Custom Nodes
+weight: 2225
+aliases:
+  - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-custom/
 ---

 ## Objectives
@@ -1,8 +1,21 @@
 ---
-title: Node Drivers
-weight: 150
+title: Nodes hosted in an Infrastructure Provider
+weight: 2205
+aliases:
+  - /rancher/v2.x/en/concepts/global-configuration/node-drivers/
+  - /rancher/v2.x/en/tasks/global-configuration/node-drivers/
+  - /rancher/v2.x/en/concepts/global-configuration/node-templates/
 ---

+### Node Drivers
+
+
+Out-of-the-box, Rancher provides support for creating clusters using many popular cloud providers: Amazon EC2, Azure, DigitalOcean, and so on. However, you may want to create a cluster using another cloud provider. In these scenarios, you can create a custom node driver for the cloud provider and point Rancher toward it.
+
+For more information on creating node drivers, see [https://github.com/rancher/ui-driver-skel](https://github.com/rancher/ui-driver-skel).
+
+#### Managing Node Drivers
+
 >**Prerequisites:** To create, edit, or delete drivers, you need _one_ of the following permissions:
 >
 >- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#global-permissions)
@@ -25,3 +38,10 @@ Using the **Custom** option, you can create a cluster using virtually any cloud
 1.	From the **Global** view, select **Node Drivers** from the main menu.

 2.	Select the inactive drivers that you want to use. Then click **Add Node Driver**.
+
+
+### Node templates
+
+You can create new clusters within Rancher using _node templates_. A node template is a virtual machine image used to create a Kubernetes cluster. While creating a cluster, Rancher will prompt you for an image to use as a template. Follow the directions on screen to create the template. During cluster creation, Rancher clones the template and installs different Kubernetes components.
+
+After you add a node template to Rancher, its stored by the system so that you can use it when creating another cluster later. Node templates are bound to your login. After you add a template, you can remove them from your user profile.
@@ -1,7 +1,9 @@
 ---
 title: Creating an Azure Cluster
 shortTitle: Azure
-weight: 3300
+weight: 2220
+aliases:
+  - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-azure/
 ---

 Use {{< product >}} to create a Kubernetes cluster in Azure.
@@ -1,7 +1,9 @@
 ---
-title: Creating a DigitalOcean Clusters
+title: Creating a DigitalOcean Cluster
 shortTitle: DigitalOcean
-weight: 3275
+weight: 2215
+aliases:
+  - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-digital-ocean/
 ---
 Use {{< product >}} to create a Kubernetes cluster using DigitalOcean.

@@ -1,7 +1,9 @@
 ---
 title: Creating an Amazon EC2 Cluster
 shortTitle: Amazon EC2
-weight: 3250
+weight: 2210
+aliases:
+  - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/
 ---
 Use {{< product >}} to create a Kubernetes cluster in Amazon EC2.

@@ -1,7 +1,9 @@
 ---
 title: Creating a vSphere Cluster
 shortTitle: vSphere
-weight: 3375
+weight: 2225
+aliases:
+  - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/
 ---
 Use {{< product >}} to create a Kubernetes cluster in vSphere.

@@ -0,0 +1,4 @@
+---
+title: Cluster Options
+weight: 2250
+---
@@ -1,6 +1,8 @@
 ---
-title: Cloud Providers
-weight: 2110
+title: Selecting Cloud Providers
+weight: 2255
+aliases:
+  - /rancher/v2.x/en/concepts/clusters/cloud-providers/
 ---
 A _cloud provider_ is a module in Kubernetes that provides an interface for managing nodes, load balancers, and networking routes. You can configure a cloud provider to automatically provision load balancers or persistent storage devices when launching Kubernetes definitions, provided that the cloud provider you're using supports such automation.

@@ -25,7 +27,7 @@ When using the `Amazon` cloud provider, you can leverage the following capabilit
 - Create/configure an IAM role
 - Configuring the ClusterID

-> **Note:** When you create an [Amazon EC2 Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/#create-the-amazon-ec2-cluster), the `ClusterID` is automatically configured.
+> **Note:** When you create an [Amazon EC2 Cluster]({{< baseurl >}}/rancher/v2.x/en/clusters/rke-clusters/node-pools/ec2/#create-the-amazon-ec2-cluster), the `ClusterID` is automatically configured.

 #### Create/Configure an IAM Role

@@ -33,8 +35,8 @@ All nodes added to the cluster must be able to interact with EC2 so that they ca

 [EC2 documentation: Creating an IAM Role](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#create-iam-role)

- While creating an [Amazon EC2 cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/#create-the-amazon-ec2-cluster), you must insert the name of the IAM role when creating the **Node Template**.
- While creating a [Custom cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-custom/), you must  manually attach the IAM role to the instance(s).
+- While creating an [Amazon EC2 cluster]({{< baseurl >}}/rancher/v2.x/en/clusters/rke-clusters/node-pools/ec2/#create-the-amazon-ec2-cluster), you must insert the name of the IAM role when creating the **Node Template**.
+- While creating a [Custom cluster]({{< baseurl >}}/rancher/v2.x/en/clusters/custom-clusters/), you must  manually attach the IAM role to the instance(s).

 The following IAM role can be created:

@@ -156,3 +158,13 @@ Last thing you will need to do, is assign the appropriate permissions to your Ap
 Custom Azure Network Security Group needed to allow Azure Load Balancers to work. If you provision hosts using Rancher Machine Azure driver, you will need to edit them manually to assign them to this Network Security Group. You should already assign custom hosts to this Network Security Group during provisioning.

 Only hosts expected to be Load Balancer backends need to be in this group.
+
+## Related Links
+
+### External Links
+
+- [Cloud Providers](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/)
+
+### Tutorials
+
+- [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/)
@@ -0,0 +1,4 @@
+---
+title: Pod Security Policies
+weight: 2260
+---
@@ -1,5 +0,0 @@
---
-title: Alerts and Notifiers
-weight: 2300
-draft: true
---
@@ -1,14 +0,0 @@
---
-title: API Keys
-weight: 2400
---
-
-Some users may want to access their Rancher clusters and projects through the Rancher API. Before you can access Rancher through the API, you must generate API keys so that you can authenticate with Rancher externally.
-
-Before you can use the Rancher CLI or write a program that calls the Rancher API, you must obtain API keys using the Rancher UI.
-
-### API Keys and User Authentication
-
-After logging into Rancher, you can generate API keys for accessing Rancher externally using your user settings. If you need to revoke access to the Rancher API, you can delete the API key.
-
-For instructions on how to create an API key, see [Creating an API Key]({{< baseurl >}}/rancher/v2.x/en/tasks/user-settings/api-keys/).
@@ -1,17 +0,0 @@
---
-title: Pipelines
-weight: 2350
---
-
-Pipelines help you automate the software delivery process. You can integrate Rancher with GitHub to create a pipeline.
-
-You can set up your pipeline to run a series of stages and steps to test your code and deploy it.
-
-<dl>
-	<dt>Pipelines</dt>
-	<dd>Contain a series of stages and steps. Out-of-the-box, the pipelines feature supports fan out and in capabilities.</dd>
-	<dt>Stages</dt>
-	<dd>Executed sequentially. The next stage will not execute until all of the steps within the stage execute.</dd>
-	<dt>Steps</dt>
-	<dd>Are executed in parallel within a stage. </dd>
-</dl>
@@ -1,28 +0,0 @@
---
-title: Clusters
-weight: 2100
---
-
-## What's a Cluster?
-
-A cluster is a group of computing resources that work as a team to accomplish a goal. Each individual computer in a cluster is called a _node_.
-
-## Cluster Creation
-
-Rancher simplifies creation of Kubernetes clusters by allowing you to create them with the Rancher UI rather than a config file.
-
-### Node Components
-
-A Kubernetes cluster contains 3 types of nodes: etcd nodes, control plane nodes, and worker nodes.
-
-#### etcd Nodes
-
-The etcd nodes are used to run the etcd database. etcd is a key value store used as Kubernetes’ backing store for all cluster data. Even though you can run etcd on a single node, you need 3, 5, or 7 nodes for redundancy.
-
-#### Control Plane Nodes
-
-The control plane nodes are used to run the Kubernetes API server, scheduler, and controller manager. Control plane nodes are stateless since all cluster data are stored on etcd nodes. You can run control plane on 1 node, although 2 or more nodes are required for redundancy. You can also run control plane on etcd nodes.
-
-#### Worker Nodes
-
-Worker nodes are used to run the kubelet and the workload. It also runs the storage and networking drivers and ingress controllers when required. You create as many worker nodes as needed for your workload needs.
@@ -1,22 +0,0 @@
---
-title: Cluster Providers
-weight: 2105
---
-
-## Rancher Kubernetes Engine (RKE)
-
-RKE is Rancher’s own lightweight Kubernetes installer. It works with any cloud providers, virtualization platforms, or bare metal servers. It integrates with node drivers to automatically provision nodes on AWS, Azure, DigitalOcean, vSphere, OpenStack, etc. Users can add custom nodes to the cluster by running the Rancher agent on these nodes.
-
-<!-- ### RKE Clusters and Kubeconfig Files 
-
-Craig! Fill me in!
-
-->
-
-## Cloud-Managed Kubernetes Clusters
-
-Rancher integrates with cloud APIs so users can provision GKE, EKS, and AKS clusters directly from Rancher. New cloud managed Kubernetes clusters will be added as they become available.
-
-## Imported Clusters
-
-Users can import an existing Kubernetes cluster into Rancher. Rancher does not automate the provisioning, scaling, and upgrade of imported Kubernetes clusters. All other cluster management, policy management, and workload management capabilities of Rancher apply to imported clustered.
@@ -1,13 +0,0 @@
---
-title: Global Configuration
-weight: 1
---
-After installing Rancher 2.0, you should configure it to support your users and environment. This section describes the global configurations you should make after installation.
-
- [Rancher Server URL]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/server-url)
- [Authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/)
- [Users, Roles, and Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-roles-permissions)
- [Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/pod-security-policies)
- [Node Drivers]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/node-drivers)
- [Node Templates]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/node-templates)
-
@@ -1,10 +0,0 @@
---
-title: Node Drivers
-weight: 100
---
-
-Out-of-the-box, Rancher provides support for creating clusters using many popular cloud providers: Amazon EC2, Azure, DigitalOcean, and so on. However, you may want to create a cluster using another cloud provider. In these scenarios, you can create a custom node driver for the cloud provider and point Rancher toward it.
-
-For more information on creating node drivers, see [https://github.com/rancher/ui-driver-skel](https://github.com/rancher/ui-driver-skel).
-
-
@@ -1,9 +0,0 @@
---
-title: Node Templates
-weight: 125
---
-
-You can create new clusters within Rancher using _node templates_. A node template is a virtual machine image used to create a Kubernetes cluster. While creating a cluster, Rancher will prompt you for an image to use as a template. Follow the directions on screen to create the template. During cluster creation, Rancher clones the template and installs different Kubernetes components.
-
-After you add a node template to Rancher, its stored by the system so that you can use it when creating another cluster later. Node templates are bound to your login. After you add a template, you can remove them from your user profile.
-
@@ -1,19 +0,0 @@
---
-title: Pod Security Policies
-weight: 75
---
-
-_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification (like root privileges). If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message of `Pod <NAME> is forbidden: unable to validate...`.
-
- You can assign PSPs at the cluster or project level.
- PSPs work through inheritance.
-
-    - By default, PSPs assigned to a cluster are inherited by its projects, as well as any namespaces added to those projects.
-    - **Exception:** Namespaces that are not assigned to projects do not inherit PSPs, regardless of whether the PSP is assigned to a cluster or project. Because these namespaces have no PSPs, workload deployments to these namespaces will fail, which is the default Kubernetes behavior.
-    - You can override the default PSP by assigning a different PSP directly to the project.
- Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked if it complies with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP.
-
-Read more about Pod Security Policies in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
-
->**Best Practice:**
->Set Pod Security at the cluster level.
@@ -1,9 +0,0 @@
---
-title: Rancher Server URL
-weight: 5
---
-
-This is the URL of your Rancher Server. All nodes in your cluster must resolve to this URL.
-
- You are prompted for this URL upon the very first Rancher login.
- You can edit this URL later by selecting **Settings**.
@@ -50,3 +50,22 @@ Other layer-7 load balancers, such as the Google Load Balancer or Nginx Ingress
 2.	Ask Rancher to generate an xip.io host name for your ingress rule. Rancher will take one of your exposed IPs, say a.b.c.d, and generate a host name <ingressname>.<namespace>.a.b.c.d.xip.io.

 The benefit of using xip.io is that you obtain a working entrypoint URL immediately after you create the ingress rule. Setting up your own domain name, on the other hand, requires you to configure DNS servers and wait for DNS to propagate.
+
+## Related Links
+
+### External Load Balancers
+
+#### External Links
+
+- [Create an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)
+
+#### Tutorials
+
+- [High Availability Installation with External Load Balancer (HTTPS/Layer 7)]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install-external-lb)
+- [High Availability Installation with External Load Balancer (TCP/Layer 4)]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install)
+- [Single Node Installation with External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install-external-lb)
+
+### Ingress Controller
+
+- [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/#what-is-ingress)
+<!--  [Adding Ingress]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/add-ingress) -->
@@ -1,5 +0,0 @@
---
-title: Logging
-weight: 2325
-draft: true
---
@@ -3,7 +3,7 @@ title: Projects
 weight: 2150
 ---

-_Projects_ are a new concept introduced by Rancher. They are not a native Kubernetes construct. A project captures a set of policies for a set of namespaces. A user can be assigned a specific role in a project. A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#adding-a-custom-role). Policies include Kubernetes Role-Based Access Control (RBAC) policies and pod security policies. Rancher 2.0 also implements a canned network policy that isolates containers in different projects. Future versions of Rancher will implement more flexible network policies.
+_Projects_ are a new concept introduced by Rancher. They are not a native Kubernetes construct. A project captures a set of policies for a set of namespaces. A user can be assigned a specific role in a project. A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#adding-a-custom-role). Policies include Kubernetes Role-Based Access Control (RBAC) policies and pod security policies. Rancher 2.0 also implements a canned network policy that isolates containers in different projects. Future versions of Rancher will implement more flexible network policies.

 ### Authorization

@@ -21,3 +21,7 @@ Rancher extends Kubernetes to allow the application of [Pod Security Policies](h
 Kubernetes resources belong to specific namespaces. Rancher 2.0 relies on namespaces to isolate resources among users and apps. When the user deploys an app from the catalog, for example, he can choose to deploy that app into its own namespace, so that resource names in one app will not conflict with resource names in another. Namespaces must be globally unique. It is often difficult for users to pick unique namespace names. Rancher therefore encourages the pattern where users work with projects, and the system generates unique namespace names automatically.

 For more information, see the [Kubernetes Namespaces Documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).
+
+## Related Links
+
+- [Project Tutorials]({{< baseurl >}}/rancher/v2.x/en/tasks/projects)
@@ -10,7 +10,7 @@ Within the context of a Rancher project or namespace, _resources_ are files and
 - [Secrets](#secrets)
 - [Registries](#registries)

-Rancher extends the application of the Kubernetes namespace resources listed above to [projects](../projects), which are Rancher-specific constructs. In the hierarchy of Rancher objects, projects contain namespaces. Therefore, any resources available within a project are available for all namespaces within that project.
+Rancher extends the application of the Kubernetes namespace resources listed above to [projects]({{< baseurl >}}/rancher/v2.x/en/concepts/projects/), which are Rancher-specific constructs. In the hierarchy of Rancher objects, projects contain namespaces. Therefore, any resources available within a project are available for all namespaces within that project.

 Within Kubernetes, certificates, registries, and secrets are all considered [secrets](https://kubernetes.io/docs/concepts/configuration/secret/). Therefore, within a single project or namespace, these resources must have unique names to avoid conflicts. Although secrets are primarily used to carry sensitive information, they have other uses as well. Read on below.

@@ -37,4 +37,11 @@ When configuring a workload, you'll be able to choose which secrets to include.

 Registries are secrets containing credentials used to authenticate with [private registries](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/). Deployments use these secrets to authenticate with a private registry and then pull a Docker image hosted on it.

->**Note:** Currently, credentials are pulled automatically only if the workload is created in the Rancher UI and not kubectl.
+>**Note:** Currently, credentials are pulled automatically only if the workload is created in the Rancher UI and not kubectl.
+
+## Related Links
+
+- [Adding SSL Certificates]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-ssl-certificates)
+- [Adding ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-configmaps)
+- [Adding Secrets]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-a-secret)
+- [Adding Registries]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-registries)
@@ -3,3 +3,14 @@ title: Service Discovery
 weight: 2200
 draft: true
 ---
+
+## Related Links
+
+### Tutorials
+
+- [Adding a DNS Record]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/add-a-dns-record)
+
+### External Links
+
+- [Services](https://kubernetes.io/docs/concepts/services-networking/service/)
+- [Adding entries to Pod /etc/hosts with HostAliases](https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/)
@@ -6,7 +6,7 @@ There are two ways to create volumes on Kubernetes: Persistent Volumes (PVs) and

 ## Persistent Volumes

-_Persistent Volumes_ are pre-provisioned storage volumes that you can bind to specific pods later. For example, in Amazon EC2, you might want to create a number of Elastic Block Store (EBS) volumes before you start running your application. Each pre-provisioned EBS volume corresponds to a Kubernetes persistent volume. When the application starts, it creates Persistent Volume Claims (PVCs) that bind to persistent volumes. A PVC corresponds to a Docker volume. Each PVC binds to one PV that includes the minimimum resources that the PVC requires. The following figure illustrates the relationship between pods, PVCs, PVs, and the underlying cloud storage.
+_Persistent Volumes_ are pre-provisioned storage volumes that you can bind to specific pods later. For example, in Amazon EC2, you might want to create a number of Elastic Block Store (EBS) volumes before you start running your application. Each pre-provisioned EBS volume corresponds to a Kubernetes persistent volume. When the application starts, it creates Persistent Volume Claims (PVCs) that bind to persistent volumes. A PVC corresponds to a Docker volume. Each PVC binds to one PV that includes the minimum resources that the PVC requires. The following figure illustrates the relationship between pods, PVCs, PVs, and the underlying cloud storage.

 ![Persistent Volumes]({{< baseurl >}}/img/rancher/persistent-volume.png)

@@ -14,8 +14,46 @@ Rancher allows you to create PVs at cluster level and bind them to PVCs later. V

 ## Storage Classes

-Storage classes allow you to create PVCs dynamically without having to create PVs first. For example, an EBS Storage Class will dynamically create EBS volumes and bind them to PVCs. A storage class is similar to the notion of a “storage driver.” The following figure illustrates how a PVC creation triggers the dynamic provisioning of an underlying EBS volume.
+Storage Classes allow you to create PVCs dynamically without having to create PVs first. For example, an Amazon EBS Storage Class will dynamically create EBS volumes and bind them to PVCs. A Storage Class is similar to the notion of a _storage driver_. The following figure illustrates how a PVC creation triggers the dynamic provisioning of an underlying EBS volume.

 ![Storage Classes]({{< baseurl >}}/img/rancher/storage-classes.png)

-<!-- Storage and Cloud Providers -->
+### Storage and Cloud Providers
+
+Each storage class contains the fields `provisioner`, `parameters`, and `reclaimPolicy`, which are used when a persistent volume that belongs to the class needs to be dynamically provisioned.
+
+The `provisioner` determines which volume plugin is used to provision the persistent volumes. You can define storage classes for the following provisioners:
+
+- Amazon EBS Disk
+- AzureFile
+- AzureDisk
+- Ceph RBD
+- Gluster Volume
+- Google Persistent Disk
+- Longhorn
+- Openstack Cinder Volume
+- Portworx Volume
+- Quobyte Volume
+- ScaleIO Volume
+- StorageOS
+- Vmware vSphere Volume
+
+In addition to customizing each provisioner's options for the storage class, you can also define the volume `reclaimPolicy`. There are two options available:
+
+- Delete volumes and underlying device when released by workloads.
+- Retain the volume for manual cleanup.
+
+Finally, you can define custom `MountOptions` for the persistent volume created.
+
+`parameters` are specific to each cloud storage provisioner. For full information about the storage classes provisioner parameters, refer to the official [Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters).
+
+## Related Links
+
+### External Docs
+
+- [Storage](https://kubernetes.io/docs/concepts/storage/)
+
+### Tutorials
+
+- [Adding Storage]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage)
+- [Adding Persistent Volume Claims]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/add-persistent-volume-claim)
@@ -11,7 +11,7 @@ You can build any complex containerized application in Kubernetes using two basi
 ### Workloads

 _Workloads_ are objects that set deployment rules for pods. Based on these rules, Kubernetes performs the deployment and updates the workload with the current state of the application.
-Workloads lets you define the rules for application scheduling, scaling, and upgrade.
+Workloads let you define the rules for application scheduling, scaling, and upgrade.

 #### Workload Types

@@ -27,7 +27,7 @@ Kubernetes divides workloads into different types. The most popular types suppor

 - [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)

-    _Daemonsets_ ensures that every node in the cluster runs a copy of pod. For use cases where where you're collecting logs or monitoring node performance, this daemon-like workload works best.
+    _Daemonsets_ ensures that every node in the cluster runs a copy of pod. For use cases where you're collecting logs or monitoring node performance, this daemon-like workload works best.

 - [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/)

@@ -60,4 +60,14 @@ There are several types of services available in Rancher. The descriptions below

 - **LoadBalancer**

-    >Exposes the service externally using a cloud provider’s load balancer. `NodePort` and `ClusterIP` services, to which the external load balancer will route, are automatically created.
+    >Exposes the service externally using a cloud provider’s load balancer. `NodePort` and `ClusterIP` services, to which the external load balancer will route, are automatically created.
+
+## Related Links
+
+### External Links
+
+- [Services](https://kubernetes.io/docs/concepts/services-networking/service/)
+
+### Tutorials
+
+- [Workloads]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/)
@@ -1,6 +1,8 @@
 ---
-  title: Contributing to Rancher
-  weight: 5001
+title: Contributing to Rancher
+weight: 9000
+aliases:
+  - /rancher/v2.x/en/faq/contributing/
 ---

 ### Repositories
@@ -1,12 +1,14 @@
 ---
 title: FAQ
-weight: 5000
+weight: 8000
 aliases:
  - /rancher/v2.x/en/about/
 ---

 This FAQ is a work in progress designed to answers the questions our users most frequently ask about Rancher v2.0.

+See [Technical FAQ]({{< baseurl >}}/rancher/v2.x/en/faq/technical/), for frequently asked technical questions.
+
 ### Kubernetes

 #### What does it mean when you say Rancher v2.0 is built on Kubernetes?
@@ -15,7 +17,7 @@ Rancher v2.0 is a complete container management platform built on 100% on Kubern

 #### Do you plan to implement upstream Kubernetes, or continue to work on your own fork?

-We're still going to provide our distribution when you select the default option of having us create your Kubernetes cluster, but it will be very close to upstream. 
+We're still going to provide our distribution when you select the default option of having us create your Kubernetes cluster, but it will be very close to upstream.

 #### Does this release mean that we need to re-train our support staff in Kubernetes?

@@ -1,9 +1,9 @@
 ---
  title: Technical
-  weight: 5000
+  weight: 8005
 ---

-#### How can I reset the admin password?
+### How can I reset the admin password?

 Single node install:
 ```
@@ -20,7 +20,7 @@ New password for default admin user (user-xxxxx):
 <new_password>
 ```

-#### How can I enable debug logging?
+### How can I enable debug logging?

 * Single node install
 * Enable
@@ -54,28 +54,28 @@ OK
 ```


-#### My ClusterIP does not respond to ping
+### 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?
+### 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?
+### 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]({{< baseurl >}}/rancher/v2.x/en/concepts/clusters/cloud-providers/) or [Create External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)

-#### Where is the state of Rancher stored?
+### Where is the state of Rancher stored?

 - Single node install: in the embedded etcd of the `rancher/rancher` container, located at `/var/lib/rancher`.
 - High Availability install: in the etcd of the RKE cluster created to run Rancher.

-#### How are the supported Docker versions determined?
+### 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-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.

-#### How can I access nodes created by Rancher?
+### 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 ellipsis button at the end of the row, and choose **Download Keys** as shown in the picture below.

@@ -86,3 +86,10 @@ Unzip the downloaded zip file, and use the file `id_rsa` to connect to you host.
 ```
 $ 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)
@@ -21,7 +21,7 @@ Configuring an Amazon NLB is a multistage process. We've broken it down into mul

 ## Create Target Groups

-Your first NLB configuration step is to create two target groups. Technically, only port 443 is needed to access Rancher, but its convenient to add a listener for port 80 which will be redirected to port 443 automatically. The NGINX controller on the nodes will make sure that port 80 gets redirected to port 443.
+Your first NLB configuration step is to create two target groups. Technically, only port 443 is needed to access Rancher, but its convenient to add a listener for port 80 which will be redirected to port 443 automatically. The NGINX ingress controller on the nodes will make sure that port 80 gets redirected to port 443.

 Log into the [Amazon AWS Console](https://console.aws.amazon.com/ec2/) to get started, make sure to select the **Region** where your EC2 instances (Linux nodes) are created.

@@ -7,7 +7,7 @@ aliases:
 This set of instructions creates a new Kubernetes cluster that's dedicated to running Rancher in a high-availability (HA) configuration. 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)
+- [NGINX Ingress controller (HTTP)](https://kubernetes.github.io/ingress-nginx/)

 ![Rancher HA]({{< baseurl >}}/img/rancher/ha/rancher2ha-l7.svg)

@@ -66,15 +66,15 @@ Before you install Rancher, confirm you meet the host requirements. Provision 3

 ### Requirements

-#### Operating System 
+#### Operating System

 {{< requirements_os >}}

-#### Hardware 
+#### Hardware

 {{< requirements_hardware >}}

-#### Software 
+#### Software

 {{< requirements_software >}}

@@ -189,18 +189,22 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec

 2. Update the `nodes` section with the information of your [Linux hosts](#provision-linux-hosts).

-    For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`.
+    For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`.
+
+    >**Note:**
+    > When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
+

 ```
 nodes:
+    # The IP address or hostname of the node
  - address: IP_ADDRESS_1
-    # THE IP ADDRESS OR HOSTNAME OF THE NODE
+    # 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
-    # USER WITH ADMIN ACCESS. USUALLY `root`
 	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
-    # PATH TO SSH KEY THAT AUTHENTICATES ON YOUR WORKSTATION
-    # USUALLY THE VALUE ABOVE
  - address: IP_ADDRESS_2
 	user: USER
 	role: [controlplane,etcd,worker]
@@ -14,6 +14,8 @@ For help installing NGINX, refer to their [install documentation](https://www.ng

 After installing NGINX, you need to create the NGINX config file, `/etc/nginx/conf.d/rancher.conf`, with the IP addresses for your Linux nodes, chosen FQDN and location of the certificate file and certificate key file.

+>**Note:** The example configuration below does not include all available Nginx options and may not be suitable for your production environment. For full configuration documentation, see [NGINX Load Balancing - HTTP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
+
 1. Copy and paste the code sample below into your favorite text editor. Save it as `/etc/nginx/conf.d/rancher.conf`.

    **Example NGINX config:**
@@ -23,18 +25,18 @@ After installing NGINX, you need to create the NGINX config file, `/etc/nginx/co
        server IP_NODE_2:80;
        server IP_NODE_3: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;
@@ -48,7 +50,7 @@ After installing NGINX, you need to create the NGINX config file, `/etc/nginx/co
            proxy_read_timeout 900s;
        }
    }
-    
+
    server {
        listen 80;
        server_name FQDN;
@@ -61,6 +63,8 @@ After installing NGINX, you need to create the NGINX config file, `/etc/nginx/co
 4. In `/etc/nginx/conf.d/rancher.conf`, replace `/certs/fullchain.pem` with the path to your certificate. If there are intermediates required for you certificate, they should be included in this file.
 5. In `/etc/nginx/conf.d/rancher.conf`, replace `/certs/privkey.pem` with the path to your certificate key.

+
+
 ## Run NGINX

 * Reload or restart NGINX
@@ -7,7 +7,7 @@ aliases:
 This set of instructions creates a new Kubernetes cluster that's dedicated to running Rancher in a high-availability (HA) configuration. 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)
+- [NGINX ingress controller with SSL termination (HTTPS)](https://kubernetes.github.io/ingress-nginx/)

 ![Rancher HA]({{< baseurl >}}/img/rancher/ha/rancher2ha.svg)

@@ -98,9 +98,9 @@ We will be using NGINX as our Layer 4 Load Balancer (TCP). NGINX will forward al

 ### A. Install NGINX

-Start by installing NGINX on your load balancer host. NGINX has packages available for all known operating systems.
+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/).

-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

@@ -110,6 +110,8 @@ After installing NGINX, you need to update the NGINX config file, `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;
@@ -196,7 +198,7 @@ RKE is a fast, versatile Kubernetes installer that you can use to install Kubern
 2. Make the RKE binary that you just downloaded executable. Open Terminal, change directory to the location of the RKE binary, and then run one of the commands below.

    >**Using Windows?**
-    >The file is already an executable. Skip to [Download Config File Template](#5-download-config-file-template).
+    >The file is already an executable. Skip to [Download Config File Template](#5-download-rke-config-file-template).

    ```
    # MacOS
@@ -238,18 +240,22 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec

 2. Update the `nodes` section with the information of your [Linux hosts](#provision-linux-hosts).

-    For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`.
+    For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`.
+
+    >**Note:**
+    > When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
+

 ```
 nodes:
+    # The IP address or hostname of the node
  - address: IP_ADDRESS_1
-    # THE IP ADDRESS OR HOSTNAME OF THE NODE
+    # 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
-    # USER WITH ADMIN ACCESS. USUALLY `root`
 	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
-    # PATH TO SSH KEY THAT AUTHENTICATES ON YOUR WORKSTATION
-    # USUALLY THE VALUE ABOVE
  - address: IP_ADDRESS_2
 	user: USER
 	role: [controlplane,etcd,worker]
@@ -389,7 +395,7 @@ Save the `.yml` file and close it.

 ## 9. 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. 
+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.

 ## 10. Run RKE

@@ -427,7 +433,7 @@ During installation, RKE automatically generates a config file named `kube_confi

 You have a couple of options:

- Create a backup of your Rancher Server in case of a disaster scenario: [High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups/restorations/ha-restoration).
+- Create a backup of your Rancher server cluster: [High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups/restorations/ha-restoration).
 - Create a Kubernetes cluster: [Creating a Cluster]({{ <baseurl> }}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).

 <br/>
@@ -7,11 +7,11 @@ aliases:

 Below are steps that you can follow to determine what is wrong in your cluster.

-* Double check if all the required ports are opened in your (host) firewall
+### Double check if all the required ports are opened in your (host) firewall

 Double check if all the [required ports]({{< baseurl >}}/rancher/v2.x/en/installation/references/) are opened in your (host) firewall.

-* All nodes should be present and in **Ready** state
+### All nodes should be present and in **Ready** state

 To check, run the command:

@@ -21,7 +21,7 @@ kubectl --kubeconfig kube_config_rancher-cluster.yml get nodes

 If a node is not shown in this output or a node is not in **Ready** state, you can check the logging of the `kubelet` container. Login to the node and run `docker logs kubelet`.

-* All pods/jobs should be in **Running**/**Completed** state
+### All pods/jobs should be in **Running**/**Completed** state

 To check, run the command:

@@ -31,13 +31,13 @@ kubectl --kubeconfig kube_config_rancher-cluster.yml get pods --all-namespaces

 If a pod is not in **Running** state, you can dig into the root cause by running:

-<h3>Describe pod</h3>
+#### Describe pod

 ```
 kubectl --kubeconfig kube_config_rancher-cluster.yml describe pod POD_NAME -n NAMESPACE
 ```

-<h3>Pod container logs</h3>
+#### Pod container logs</h3>

 ```
 kubectl --kubeconfig kube_config_rancher-cluster.yml logs POD_NAME -n NAMESPACE
@@ -45,19 +45,27 @@ kubectl --kubeconfig kube_config_rancher-cluster.yml logs POD_NAME -n NAMESPACE

 If a job is not in **Completed** state, you can dig into the root cause by running:

-<h3>Describe job</h3>
+#### Describe job

 ```
 kubectl --kubeconfig kube_config_rancher-cluster.yml describe job JOB_NAME -n NAMESPACE
 ```

-<h3>Logs from the containers of pods of the job</h3>
+#### Logs from the containers of pods of the job

 ```
 kubectl --kubeconfig kube_config_rancher-cluster.yml logs -l job-name=JOB_NAME -n NAMESPACE
 ```

-* List all Kubernetes cluster events
+### Check ingress
+
+Ingress should have the correct `HOSTS` (showing the configured FQDN) and `ADDRESS` (address(es) it will be routed to).
+
+```
+kubectl --kubeconfig kube_config_rancher-cluster.yml get ingress --all-namespaces
+```
+
+### List all Kubernetes cluster events

 Kubernetes cluster events are stored, and can be retrieved by running:

@@ -65,19 +73,19 @@ Kubernetes cluster events are stored, and can be retrieved by running:
 kubectl --kubeconfig kube_config_rancher-cluster.yml get events --all-namespaces
 ```

-* Check Rancher container logging
+### Check Rancher container logging

 ```
 kubectl --kubeconfig kube_config_rancher-cluster.yml logs -l app=cattle -n cattle-system
 ```

-* Check NGINX ingress controller logging
+### Check NGINX ingress controller logging

 ```
 kubectl --kubeconfig kube_config_rancher-cluster.yml logs -l app=ingress-nginx -n ingress-nginx
 ```

-* Check if overlay network is functioning correctly
+### Check if overlay network is functioning correctly

 The pod can be scheduled to any of the hosts you used for your cluster, but that means that the NGINX ingress controller needs to be able to route the request from `NODE_1` to `NODE_2`. This happens over the overlay network. If the overlay network is not functioning, you will experience intermittent TCP/HTTP connection failures due to the NGINX ingress controller not being able to route to the pod.

@@ -59,10 +59,10 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher

 Choose from the following options:

- [Option A—Default Self-Signed Certificate](#option-adefault-self-signed-certificate)
- [Option B—Bring Your Own Certificate: Self-Signed](#option-bbring-your-own-certificate--self-signed)
- [Option C—Bring Your Own Certificate: Signed by Recognized CA](#option-cbring-your-own-certificate--signed-by-recognized-ca)
- [Option D-Let's Encrypt Certificate](#option-d-lets-encrypt-certificate)
+- [Option A—Default Self-Signed Certificate](#option-a-default-self-signed-certificate)
+- [Option B—Bring Your Own Certificate: Self-Signed](#option-b-bring-your-own-certificate-self-signed)
+- [Option C—Bring Your Own Certificate: Signed by Recognized CA](#option-c-bring-your-own-certificate-signed-by-recognized-ca)
+- [Option D—Let's Encrypt Certificate](#option-d-let-s-encrypt-certificate)

 ### Option A—Default Self-Signed Certificate

@@ -133,7 +133,7 @@ By default, Rancher automatically generates self-signed certificates for itself
 2. Select  **Settings** > **cacerts**.
 3. Choose `Edit` and remove the contents. Then click `Save`.

-### Option D-Let's Encrypt Certificate
+### Option D—Let's Encrypt Certificate

 Rancher supports Let's Encrypt certificates. Let's Encrypt uses an `http-01 challenge` to verify that you have control over your domain. You can confirm that you control the domain by pointing the hostname that you want to use for Rancher access (for example, `rancher.mydomain.com`) to the IP of the machine it is running on. You can bind the hostname to the IP address by creating an A record in DNS.

@@ -133,6 +133,8 @@ The load balancer or proxy has to be configured to support the following:

 This 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;
@@ -7,7 +7,7 @@ This section explains how Rancher interacts with the two fundamental technologie

 ## Docker

-Docker is the container packaging and runtime standard. Developers build container images from Dockerfiles and distribute container images from Docker registries. [Docker Hub](http://hub.docker.com) is the most popular public registry. Many organizations also setup private Docker registries. Docker is primarily used to manage containers on individual nodes.
+Docker is the container packaging and runtime standard. Developers build container images from Dockerfiles and distribute container images from Docker registries. [Docker Hub](https://hub.docker.com) is the most popular public registry. Many organizations also setup private Docker registries. Docker is primarily used to manage containers on individual nodes.

 >**Note:** Although Rancher 1.6 supported Docker Swarm clustering technology, it is no longer supported in Rancher 2.0 due to the success of Kubernetes.

@@ -1,4 +0,0 @@
---
-title: Clusters
-weight: 3175
---
@@ -14,14 +14,14 @@ You can add a Pod Security Policy (PSPs hereafter) in the following contexts:

 > **Note:** We recommend adding PSPs during cluster and project creation instead of adding it to an existing one.

-For more information about PSPs, refer to [Pod Security Policy]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/pod-security-policies).
+For more information about PSPs, refer to [Pod Security Policy]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies).

 ## Cluster Creation: Adding a Default Pod Security Policy

 When you create a new cluster, you can configure it to apply a PSP immediately. As you create the cluster, use the **Cluster Options** to enable a PSP. The PSP assigned to the cluster will be the default PSP for projects within the cluster.

 >**Prerequisite:**
->Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/).
+>Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/).
 >**Note:**
 >For security purposes, we recommend assigning a PSP as you create your clusters.

@@ -36,7 +36,7 @@ For detailed instruction about assigning a PSP to a new cluster, see [Creating a
 If you don't apply a PSP as you create your cluster, you can always add one later.

 >**Prerequisite:**
->Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/).
+>Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/).

 1. From the **Global** view, find the cluster that you want to apply your PSP to. Select **Vertical Ellipsis (...) > Edit** for the cluster you want to enable PSPs for.

@@ -66,7 +66,7 @@ When you create a new project, you can assign a PSP directly to the project. Ass

 >**Prerequisites:**
 >
-> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/).
+> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/).
 > - Assign a default Pod Security Policy to the project's cluster. You can't assign a PSP to a project until one is already applied to the cluster. For more information, see [Existing Cluster: Adding a Pod Security Policy](#existing-cluster--adding-a-pod-security-policy).

 As you create the project, make a selection from the **Pod Security Policy** drop-down to assign a PSP.
@@ -79,7 +79,7 @@ You can always assign a PSP to an existing project if you didn't assign one duri

 >**Prerequisites:**
 >
-> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/).
+> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/).
 > - Assign a default Pod Security Policy to the project's cluster. You can't assign a PSP to a project until one is already applied to the cluster. For more information, see [Existing Cluster: Adding a Pod Security Policy](#existing-cluster--adding-a-pod-security-policy).

 1. From the **Global** view, find the cluster containing the project you want to apply a PSP to.
@@ -1,9 +0,0 @@
---
-title: Adding and Managing Alerts
-weight: 3575
-draft: true
---
-
-## Adding Alerts
-
-## Managing Alerts
@@ -29,23 +29,23 @@ Following cluster creation, you can add users as cluster members so that they ca

 	If external authentication is configured:
 	
-	-  Rancher returns users from your [external authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/) source as you type.
+	-  Rancher returns users from your [external authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) source as you type.

 		>**Using AD but can't find your users?**
-		>There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/).
+		>There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/configuring-ad/).
 	
 	- A drop-down allows you to add groups instead of individual users. The drop-down only lists groups that you, the logged in user, are part of.

-		>**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users).
+		>**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).

 4. Assign the user or group **Cluster** roles.  

-	[What are Cluster Roles?]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#cluster-roles)
+	[What are Cluster Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#cluster-roles)

 	>**Tip:** For Custom Roles, you can modify the list of individual roles available for assignment.
 	>
-	> - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#adding-a-custom-role).
-	> - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#locking-unlocking-roles).
+	> - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#adding-a-custom-role).
+	> - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#locking-unlocking-roles).

 **Result:** The chosen users are added to the cluster. 

@@ -1,11 +0,0 @@
---
-title: Adding and Managing Notifiers
-weight: 3550
-draft: true
---
-
-
-## Adding Notifiers
-
-## Managing Notifiers
-
@@ -1,14 +1,90 @@
 ---
 title: Adding Storage
 weight: 3500
-draft: true
 ---
-Coming Soon

-## Adding Persistent Volumes
+>**Prerequisites:** 
+>
+>- Working with storage requires the `Manage Volumes` [role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#project-role-reference).
+>- You must have a storage medium provisioned. For more information, see [Provisioning Storage](provisioning-storage).

-Coming Soon
+## Adding a Persistent Volume
+
+Your containers can store data on themselves, but if a container fails, that data is lost. To solve this issue, Kubernetes offers _persistent volumes_, which are external storage disks or file systems that your containers can access. If a container crashes, its replacement container can access the data in a persistent volume without any data loss.
+
+Persistent volumes can either be a disk or file system that you host on premise, or they can be hosted by a vendor, such as Amazon EBS or Azure Disk.
+
+>**Prerequisite:**
+>
+>- Create a storage volume either on premise or in the cloud, using one of the vendor services listed in [Types of Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes).
+>- Gather metadata about your storage volume after you create it. You'll need to enter this information into Rancher.
+
+1. From the **Global** view, open the cluster running the containers that you want to add persistent volume storage to.
+
+1. From the main menu, select **Storage > Persistent Volumes**.
+
+1. Click **Add Volume**.
+
+1. Enter a **Name** for the persistent volume.
+
+1. Select the **Volume Plugin** for the disk type or service that you're using.
+
+  >**Note:** If the cluster you are adding storage for is a cloud service that also offers cloud storage, you must enable the `cloud provider` option for the cluster, and you must use the service's plug-in to use cloud storage. For example, if you have a Amazon EC2 cluster and you want to use cloud storage for it:
+  
+      1. You must enable the `cloud provider` option for the EC2 cluster.
+      2. You must use the `Amazon EBS Disk` volume plugin.
+
+1. Enter the **Capacity** of your volume in gigabytes.
+
+1. Complete the **Plugin Configuration** form. Each plugin type requires information specific to the vendor of disk type. For help regarding each plugin's form and the information that's required, refer to the plug-in's vendor documentation.
+
+1. **Optional:** Complete the **Customize** form. This form features:
+
+    - [Access Modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes):
+
+         This options sets how many nodes can access the volume, along with the node read/write permissions. The [Kubernetes Documentation](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) includes a table that lists which access modes are supported by the plugins available.
+
+    - [Mount Options](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options):
+
+         Each volume plugin allows you to specify additional command line options during the mounting process. You can enter these options in the **Mount Option** fields. Consult each plugin's vendor documentation for the mount options available.
+
+    - **Assign to Storage Class:**
+
+         If you later want to automatically provision persistent volumes identical to the volume that you've specified here, assign it a storage class. Later, when you create a workload, you can assign it a persistent volume claim that references the storage class, which will provision a persistent volume identical to the volume you've specified here.
+
+         >**Note:** You must [add a storage class](#adding-storage-classes) before you can assign it to a persistent volume.
+
+1. Click **Save**.
+
+**Result:** Your new persistent volume is created.

 ## Adding Storage Classes

-Coming Soon
+_Storage Classes_ allow you to dynamically provision persistent volumes on demand. Think of storage classes as storage profiles that are created automatically upon a request (which is known as a _persistent volume claim_). 
+
+1. From the **Global** view, open the cluster for which you want to dynamically provision persistent storage volumes.
+
+1. From the main menu, select `Storage > Storage Classes`. Click `Add Class`.
+
+1. Enter a `Name` for your storage class.
+
+1. From the `Provisioner` drop-down, select the service that you want to use to dynamically provision storage volumes.
+
+  >**Note:** If the cluster you are adding a storage class for is a cloud service that also offers cloud storage, you must enable the `cloud provider` option for the cluster, and you must use the service's plug-in to use cloud storage. For example, if you have a Amazon EC2 cluster and you want to use cloud storage for it:
+  
+      1. You must enable the `cloud provider` option for the EC2 cluster.
+      2. You must use the `Amazon EBS Disk` provisioner.
+
+
+1. From the `Parameters` section, fill out the information required for the service to dynamically provision storage volumes. Each provisioner requires different information to dynamically provision storage volumes. Consult the service's documentation for help on how to obtain this information.
+
+1. Click `Save`.
+
+## What's Next?
+
+Mount Persistent Volumes to workloads so that your applications can store their data. You can mount a either a manually created Persistent Volumes or a dynamically created Persistent Volume, which is created from a a Storage Class.
+
+You can mount Persistent Volumes in one of two contexts:
+
+- During deployment of a workload (recommended if possible). For more information, see [Deploying Workloads](../../workloads/deploy-workloads/).
+- Following workload creation. For more information, see [Adding Persistent Volume Claims](../../workloads/add-persistent-volume-claim/).
@@ -0,0 +1,10 @@
+---
+title: Provisioning Storage
+weight: 3500
+---
+
+Rancher supports persistent storage with a variety of volume plugins. However, before you use any of these plugins to bind persistent storage to your workloads, you have to configure the storage itself, whether its a cloud-based solution from a service-provider or an on-prem solution that you manage yourself.
+
+For your convenience, Rancher offers documentation on how to configure some of the popular storage methods:
+
+- [NFS Share](nfs)
@@ -0,0 +1,66 @@
+---
+title: Provisioning NFS Storage
+weight: 3500
+---
+
+Before you can use the NFS storage volume plug-in with Rancher deployments, you need to provision an NFS server.
+
+>**Note:**
+>
+>- If you already have an NFS share, you don't need to provision a new NFS server to use the NFS volume plugin within Rancher. Instead, skip the rest of this procedure and complete [adding storage]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-storage/).
+>
+>- This procedure demonstrates how to setup an NFS server using Ubuntu, although you should be able to use these instructions for other Linux distros (e.g. Debian, RHEL, Arch Linux, etc.). For official instruction on how to create an NFS server using another Linux distro, consult the distro's documentation.
+
+>**Recommended:** To simplify the process of managing firewall rules, use NFSv4.
+
+1. Using a remote Terminal connection, log into the Ubuntu server that you intend to use for NFS storage.
+
+1. Enter the following command:
+
+    ```
+    sudo apt-get install nfs-kernel-server
+    ```
+
+1. Enter the command below, which sets the directory used for storage, along with user access rights. Modify the command if you'd like to keep storage at a different directory.
+
+    ```
+    mkdir -p /nfs && chown nobody:nogroup /nfs
+    ```
+    - The `-p /nfs` parameter creates a directory named `nfs` at root.
+    - The `chown nobody:nogroup /nfs` parameter allows all access to the storage directory.
+
+1. Create an NFS exports table. This table sets the directory paths on your NFS server that are exposed to the nodes that will use the server for storage.
+
+    1. Open `/etc/exports` using your text editor of choice.
+    1. Add the path of the `/nfs` folder that you created in step 3, along with the IP addresses of your cluster nodes. Add an entry for each IP address in your cluster. Follow each address and its accompanying parameters with a single space that is a delimiter.
+
+        ```
+        /nfs <IP_ADDRESS1>(rw,sync,no_subtree_check) <IP_ADDRESS2>(rw,sync,no_subtree_check) <IP_ADDRESS3>(rw,sync,no_subtree_check)
+        ```
+
+        **Tip:**  You can replace the IP addresses with a subnet. For example: `10.212.50.12&#47;24`
+
+    1. Update the NFS table by entering the following command:
+
+        ```
+        exportfs -ra
+        ```
+
+1. Open the ports used by NFS.
+
+    1. To find out what ports NFS is using, enter the following command:
+
+        ```
+        rpcinfo -p | grep nfs
+        ```
+    2. [Open the ports](https://help.ubuntu.com/lts/serverguide/firewall.html.en) that the previous command outputs. For example, the following command opens port 2049:
+
+        ```
+        sudo ufw allow 2049
+        ```
+
+**Result:** Your NFS server is configured to be used for storage with your Rancher nodes.
+
+## What's Next?
+
+Within Rancher, add the NFS server as a [storage volume]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-storage/#adding-a-persistent-volume) and/or [storage class]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-storage/#adding-storage-classes). After adding the server, you can use it for storage for your deployments.
@@ -1,6 +0,0 @@
---
-title: Adding Users to a Cluster
-weight: 3425
-draft: true
---
-Coming Soon
@@ -1,5 +0,0 @@
---
-title: Creating a Cluster
-weight: 3200
---
-Rancher includes a variety of options for getting a Kubernetes cluster up and running using a single Linux node as a temple. Choose from one of the options below to get started!
@@ -1,5 +0,0 @@
---
-title: Cluster Options—Edit as YAML 
-weight: 5000
-draft: true
---
@@ -1,9 +0,0 @@
---
-title: Enabling and Managing Cluster Logging
-weight: 3600
-draft: true
---
-
-## Enabling Cluster Logging
-
-## Managing Cluster Logging
@@ -1,9 +0,0 @@
---
-title: Enabling and Managing Pipelines for Projects
-weight: 3625
-draft: true
---
-
-## Enabling Pipelines for Projects
-
-## Managing Pipelines for Projects
@@ -1,5 +0,0 @@
---
-title: Global Configuration
-weight: 3025
---
-This section contains step-by-step instruction for configuring Rancher to work in your environment.
@@ -1,26 +0,0 @@
---
-title: Authentication
-weight: 50
---
-You have three options for user authentication in Rancher:
-
-	[Active Directory]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/)
-	
-	Enterprises can use Active Directory (AD) for authentication, allowing users to sign in using their corporate credentials.
-
-	[GitHub]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/github/)
-
-	Open source projects or organizations that use GitHub for source control may prefer that users sign in using their GitHub accounts.
-
-<!-- - **SAML**:
-
- **OpenLDAP**:-->
-
-
- [Azure AD]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/)
-
-	If you have an instance of Active Directory (AD) hosted in Azure, you can configure Rancher to allow your users to log in using their AD accounts. Configuration of Azure AD external authentication requires you to make configurations in both Azure and Rancher.
-
-	[Local Authentication]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/)
-
-	If you don't want to use external authentication, you can always add users directly to Rancher. We recommend using external authentication over local authentication.
@@ -1,54 +0,0 @@
---
-title: Configuring Active Directory Authentication
-weight: 3075
---
-
-In environments using Microsoft Active Directory (AD), you can configure Rancher to allow sign on using AD credentials.
-
->**Prerequisites:**
->
->- Create a service account in Active Directory with `read-only` access. {{< product >}} uses this account to verify group membership when a user makes a request using an API key.
->- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users).
-
-1.  Sign into Rancher using a local user assigned `administrator` global permissions (i.e., the _local principal_).
-
-2.	From the **Global** view, select **Security > Authentication** from the main menu.
-
-3.	Select **Active Directory**.
-
-4.	Complete the **Configure an Active Directory server** form.
-
-	You may need to log in to your domain controller to find the information requested in the form.
-	
-	>**Using TLS?**
- 	>Make sure you have an LDAP certificate installed.
-	<br/>
-	<br/>
-	>**User Search Base vs. Group Search Base**
-	>
-	>When configuring AD authentication, you must enter a search base for your users. This search base allows Rancher to search for users that are in your Active Directory.
-    <br/>
-	<br/>
-  	> **Note:** This field is only for search bases and not for search filters.
-	>
-	>- If your users and groups are in the search base, complete only the User Search Base.
-	>- If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required.
-
-5.	If your Active Directory deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step.
-
-	>**Search Attribute** As of Rancher v2.0.1, the Search Attribute field defaults with three specific values by default: `sAMAccountName|sn|givenName`. After AD is configured, when a user enters text to add users or groups, Rancher automatically queries the AD server and attempts to match fields by sAMAccountName, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field.
-	>
-	>The default field value `sAMAccountName|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields.
-	>
-	> * `sAMAccountName`: Username
-	> * `sn`: Last Name
-	> * `givenName`: First Name
-	>
-	> With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field.
-
-6.	Enter your AD username and password in **Test and enable authentication** to confirm that Rancher is configured to use AD authentication.
-
-**Result:**
-
- Active Directory authentication is configured.
- You are signed into Rancher with your Active Directory account (i.e., the _external principal_).
@@ -1,10 +0,0 @@
---
-title: Catalogs and Charts
-weight: 3026
---
-
-This section includes step-by-step instruction on how to configure default and custom catalogs.
-
- [Enabling Default Catalogs]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/enabling-default-catalogs)
- [Adding Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs)
- [Customizing Charts]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts)
@@ -1,7 +0,0 @@
---
-title: Password Reset
-weight: 75
-draft: true
---
-
-Content here.
@@ -1,6 +1,34 @@
 ---
 title: Adding a Secret
 weight: 
-draft: true
 ---
-Coming Soon
+
+[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets) store sensitive data like passwords, tokens, or keys. They may contain one or more key value pairs.
+
+When creating a secret, you can make it available for any deployment within a project, or you can limit it to a single namespace.
+
+1. From the **Global** view, select the project containing the namespace(s) where you want to add a secret.
+
+1. From the main menu, select **Resources > Secrets**. Click **Add Secret**.
+
+1. Enter a **Name** for the secret.
+
+    >**Note:** Kubernetes classifies secrets, certificates, ConfigMaps, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your secret must have a unique name among all secrets within your workspace.
+
+1. Select a **Scope** for the secret.
+
+1. From **Secret Values**, click **Add Secret Value** to add a key value pair. Add as many values as you need.
+
+	>**Tip:** You can add multiple key value pairs to the secret by copying and pasting.
+	>
+	> ![Bulk Key Value Pair Copy/Paste]({{< baseurl >}}/img/rancher/bulk-key-values.gif)
+
+1. Click **Save**.
+	
+**Result:** Your secret is added to the project or namespace, depending on the scope you chose. You can view the secret in the Rancher UI from the **Resources > Secrets** view.
+
+## What's Next?
+
+Now that you have a secret added to the project or namespace, you can add it to a workload that you deploy.
+
+For more information on adding secret to a workload, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/deploy-workloads/).
@@ -0,0 +1,39 @@
+---
+title: Adding ConfigMaps
+weight: 
+---
+
+ConfigMaps store general configuration information for an application, such as configuration files, command-line arguments, environment variables, etc. ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. Add ConfigMaps to your Rancher workspaces so that you can add them to your workloads later. For more information on ConfigMaps, see the official [Kubernetes Documentation: Using ConfigMap](https://kubernetes-v1-4.github.io/docs/user-guide/configmap/).
+
+>**Note:** ConfigMaps can only be applied to namespaces and not projects.
+
+1. From the **Global** view, select the project containing the namespace that you want to add a ConfigMap to.
+
+1. From the main menu, select **Resources > Config Maps**. Click **Add Config Map**.
+
+1. Enter a **Name** for the Config Map.
+
+    >**Note:** Kubernetes classifies ConfigMaps as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your ConfigMaps must have a unique name among the other certificates, ConfigMaps, registries, and secrets within your workspace.
+
+1. Select the **Namespace** you want to add Config Map to. You can also add a new namespace on the fly by clicking **Add to a new namespace**.
+
+1. From **Config Map Values**, click **Add Config Map Value** to add a key value pair to your ConfigMap. Add as many values as you need.
+
+1. Click **Save**.
+
+	>**Note:** Don't use ConfigMaps to store sensitive data [use a secret](../add-a-secret).
+	>
+	>**Tip:** You can add multiple key value pairs to the ConfigMap by copying and pasting.
+	>
+	> ![Bulk Key Value Pair Copy/Paste]({{< baseurl >}}/img/rancher/bulk-key-values.gif)
+
+**Result:** Your ConfigMap is added to the namespace. You can view it in the Rancher UI from the **Resources > Config Maps** view.
+
+## What's Next?
+
+Now that you have a ConfigMap added to a namespace, you can add it to a workload that you deploy from the namespace of origin. You can use the ConfigMap to specify information for you application to consume, such as:
+
+- Application environment variables.
+- Specifying parameters for a Volume mounted to the workload.
+
+For more information on adding ConfigMaps to a workload, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/tasks/workloads/deploy-workloads/).
--- a/Show More
+++ b/Show More