merge latest master - fix conflits

2026-09-25 04:28:15 +00:00 · 2018-08-13 11:50:51 -05:00
parent 079f44127c ff9af5e1d3
commit b278f9d08b
121 changed files with 3120 additions and 1023 deletions
@@ -9,9 +9,6 @@ enableRobotsTXT = true
 pygmentsCodeFences = true
 pygmentsCodeFencesGuessSyntax = true

-[blackfriday]
-hrefTargetBlank = true
-
 [permalinks]
  inside-pages = "/:filename/"

@@ -93,6 +93,14 @@ Key | Value | Default | Description
 `extra_args` | List of Strings | `[]` | Arbitrary daemon arguments, appended to the generated command
 `environment` | List of Strings (optional) | `[]` |

+_Available as of v1.4_
+
+The docker-sys bridge can be configured with system-docker args, it will take effect after reboot.
+
+```
+$ ros config set rancher.system_docker.bip 172.18.43.1/16
+```
+
 ### Using a pull through registry mirror

 There are 3 Docker engines that can be configured to use the pull-through Docker Hub registry mirror cache:
@@ -32,16 +32,3 @@ write_files:
 ```

 Running Docker commands in this manner is useful when pieces of the `docker run` command are dynamically generated. For services whose configuration is static, [adding a system service]({{< baseurl >}}/os/v1.x/en/installation/system-services/adding-system-services/) is recommended.
-
-## Running Commands Early in the Boot Process
---
-
-The `bootcmd` parameter can be used to run commands earlier in the boot process. In particular, `bootcmd` will be executed while RancherOS is still running from memory and before System Docker and any system services are started.
-
-The syntax for bootcmd is the same as `runcmd`.
-
-```yaml
-#cloud-config
-bootcmd:
- [ mdadm, --assemble, --scan ]
-```
@@ -19,6 +19,8 @@ The Rancher authentication proxy integrates with the following external authenti
 - Microsoft Active Directory
 - Microsoft Azure AD
 - GitHub
+- PingIdentity
+- Microsoft AD FS
 - FreeIPA
 - OpenLDAP

@@ -5,7 +5,9 @@ aliases:
    - /rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/
 ---

-Rancher can be configured to communicate with an existing Microsoft Active Directory server for the purpose user authentication. This allows users to use their AD account credentials for login into the Rancher UI as well as managing access to clusters and projects based on AD user identity or group membership.
+If your organization uses Microsoft Active Directory as central user repository, you can configure Rancher to communicate with an Active Directory server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the Active Directory, while allowing end-users to authenticate with their AD credentials when logging in to the Rancher UI. 
+
+Rancher uses LDAP to communicate with the Active Directory server. The authentication flow for Active Directory is therefore the same as for the [OpenLDAP authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/openldap) integration.

 > **Note:**
 > 
@@ -13,11 +15,11 @@ Rancher can be configured to communicate with an existing Microsoft Active Direc

 ## Prerequisites

-You'll need to create or obtain from your AD administrator a new AD user to use as service account for Rancher. This user must have sufficient permissions to perform searches and read attributes of users and groups under your AD domain.
+You'll need to create or obtain from your AD administrator a new AD user to use as service account for Rancher. This user must have sufficient permissions to perform LDAP searches and read attributes of users and groups under your AD domain.

-Usually a (non-admin) **Domain User** account should be used for this purpose, as by default such user has privileges to view, but not modify other objects in the domain partition. 
+Usually a (non-admin) **Domain User** account should be used for this purpose, as by default such user has read-only privileges for most objects in the domain partition. 

-Note however, that in some locked-down Active Directory configurations this default behaviour may not apply. In such case you will need to ensure that the service account user has both **Read** and **List Content** permissions granted either on the Base OU (enclosing users and groups) or globally for the domain.
+Note however, that in some locked-down Active Directory configurations this default behaviour may not apply. In such case you will need to ensure that the service account user has at least **Read** and **List Content** permissions granted either on the Base OU (enclosing users and groups) or globally for the domain.

 > **Using TLS?**
 >
@@ -46,9 +48,9 @@ In the section titled `1. Configure an Active Directory server`,   complete the
 | Port | Specify the port at which the Active Directory server is listening for connections. Unencrypted LDAP normally uses the standard port of 389, while LDAPS uses port 636.|
 | TLS | Check this box to enable LDAP over SSL/TLS (commonly known as LDAPS).|
 | Server Connection Timeout | 	The duration in number of seconds that Rancher waits before considering the AD server unreachable. |
-| Service Account Username | Enter the username of an AD account with read(-only) access to your domain partition that will be used by Rancher to lookup users and groups (see [Prerequisites](#prerequisites)). You must specify this username in the logon (slashed) format, e.g. "mydomain\rancheruser". |
+| Service Account Username | Enter the username of an AD account with read-only access to your domain partition (see [Prerequisites](#prerequisites)). The username can be entered in NetBIOS format (e.g. "DOMAIN\serviceaccount") or UPN format (e.g. "serviceaccount@domain.com"). |
 | Service Account Password | The password for the service account.  |
-| Default Login Domain | Enter your AD domain, e.g. "acme". |
+| Default Login Domain | When you configure this field with the NetBIOS name of your AD domain, usernames entered without a domain (e.g. "jdoe") will automatically be converted to a slashed,  NetBIOS logon (e.g. "LOGIN_DOMAIN\jdoe") when binding to the AD server. If your users authenticate with the UPN (e.g. "jdoe@acme.com") as username then this field **must** be left empty. |
 | User Search Base | The Distinguished Name of the node in your directory tree from which to start searching for user objects. All users must be descendents of this base DN. For example: "ou=people,dc=acme,dc=com".|
 | Group Search Base | If your groups live under a different node than the one configured under `User Search Base` you will need to provide the Distinguished Name here. Otherwise leave it empty. For example: "ou=groups,dc=acme,dc=com".|

@@ -74,9 +76,9 @@ The table below details the parameters for the user schema section configuration
 |:--|:--|
 | Object Class | The name of the object class used for user objects in your domain. |
 | Username Attribute | The user attribute whose value is suitable as a display name. |
-| Login Attribute | The attribute whose value matches the username part of your users AD credentials, ie. what they would enter when logging in to Rancher. |
+| Login Attribute | The attribute whose value matches the username part of credentials entered by your users when logging in to Rancher. If your users authenticate with their UPN (e.g. "jdoe@acme.com") as username then this field must normally be set to `userPrincipalName`. Otherwise for the old, NetBIOS-style logon names (e.g. "jdoe") it's usually `sAMAccountName`. |
 | User Member Attribute | The attribute containing the groups that a user is a member of. |
-| Search Attribute | When a user enters text to add users or groups, Rancher queries the AD server and attempts to match fields by the attributes provided in this setting. Multiple attributes can be specified by separating them with the pipe ("\|") symbol. As of Rancher v2.0.1, this parameter defaults to: "sAMAccountName\|sn\|givenName".|
+| Search Attribute | When a user enters text to add users or groups in the UI, Rancher queries the AD server and attempts to match users by the attributes provided in this setting. Multiple attributes can be specified by separating them with the pipe ("\|") symbol. To match UPN usernames (e.g. jdoe@acme.com) you should usually set the value of this field to `userPrincipalName`. |
 | User Enabled Attribute | The attribute containing an integer value representing a bitwise enumeration of user account flags. Rancher uses this to determine if a user account is disabled. You should normally leave this set to the AD standard `userAccountControl`. |
 | Disabled Status Bitmask | This is the value of the `User Enabled Attribute` designating a disabled user account. You should normally leave this set to the default value of "2" as specified in the Microsoft Active Directory schema (see [here](https://docs.microsoft.com/en-us/windows/desktop/adschema/a-useraccountcontrol#remarks)). |

@@ -102,23 +104,23 @@ The table below details the parameters for the group schema configuration.

 ### Test Authentication

-When you have completed the configuration, proceed by testing the connection to the AD server with your own AD credentials.
+Once you have completed the configuration, proceed by testing  the connection to the AD server. Authentication with the configured Active Directory will be enabled implicitly if the test is successful.

 > **Note:**
 >
-> On completing this step of the configuration, the AD user pertaining to the credentials entered here will be mapped to the local principal account. You should therefore ensure to specifically enter credentials of an AD account that you want to be assigned the administrative role in Rancher going forward.
+> The AD user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned admin privileges in Rancher. You should therefore make a conscious decision on which AD account you use to perform this step.

-1. Enter the **username** and **password** for your AD account.
-2. Click **Authenticate with Active Directory** to test the Active Directory connection and map this user to the local admin account.
+1. Enter the **username** and **password** for the AD account that should be mapped to the local principal account.
+2. Click **Authenticate with Active Directory** to finalise the setup.

 **Result:**

- AD authentication is configured.
- You are signed into Rancher with your AD account (mapped to the local user assigned the administrator role, ie. the local principal account).
+- Active Directory authentication has been enabled.
+- You have been signed into Rancher as administrator using the provided AD credentials.

 > **Note:**
 >
-> You will still be able to login using the locally configured `admin` account and password in case of a disruption of AD services.
+> You will still be able to login using the locally configured `admin` account and password in case of a disruption of LDAP services.

 ## Annex: Identify Search Base and Schema using ldapsearch

@@ -159,7 +161,11 @@ The output of the above `ldapsearch` query also allows to determine the correct
 - `Login Attribute`: **sAMAccountName** [3]
 - `User Member Attribute`: **memberOf** [4]

-With regards to the `Search Attribute` parameter, it makes sense here to set it to **sAMAccountName|name**. This will allow users to be added in the Rancher UI both by entering their username or full name.
+> **Note:**
+>
+> If the AD users in our organisation were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead.  
+
+We'll also set the `Search Attribute` parameter to **sAMAccountName|name**. That way users can be added to clusters/projects in the Rancher UI either by entering their username or full name.

 ### Identify Group Schema

@@ -188,4 +194,4 @@ In the same way, we can observe that the value in the **memberOf** attribute in

 ## Annex: Troubleshooting

-If you are experiencing issues while testing the connection to the Active Directory server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the issue cause. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation.
+If you are experiencing issues while testing the connection to the Active Directory server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation.
@@ -171,9 +171,9 @@ Enter the values that you copied to your [text file](#tip).

    >**Important:** When entering your Graph Endpoint, remove the tenant ID from the URL, like below.
    >
-    >https://graph.windows.net/<del>abb5adde-bee8-4821-8b03-e63efdc7701c</del>
+    ><code>http<span>s://g</span>raph.windows.net/<del>abb5adde-bee8-4821-8b03-e63efdc7701c</del></code>

-    The following table maps the values you copied in the Azure portal to the fields in Rancher. ~~~~
+    The following table maps the values you copied in the Azure portal to the fields in Rancher. 

    Rancher Field | Azure Value
    ---------|----------
@@ -0,0 +1,52 @@
+---
+title: Configuring Microsoft Active Directory Federation Service (SAML)
+weight: 1205
+---
+_Available as of v2.0.7_
+
+If your organization uses Microsoft Active Directory Federation Services (AD FS) for user authentication, you can configure Rancher to allow your users to log in using their AD FS credentials.
+
+>**Prerequisites:**
+>
+>- You must have a [Microsoft AD FS Server](https://docs.microsoft.com/en-us/windows-server/identity/active-directory-federation-services) configured.
+>- Export a `federationmetadata.xml` file from your AD FS Server. For more information, see the [PingIdentity video](https://docs.pingidentity.com/bundle/ping_sm_videoLibrary/page/p1_IdentityBridgeADFS.html).
+
+1.	From the **Global** view, select **Security > Authentication** from the main menu.
+
+1.	Select **Microsoft Active Directory Federation Services**.
+
+1.	Complete the **Configure AD FS Account** form. Microsoft AD FS lets you specify an existing Active Directory (AD) server. The examples below describe how you can map AD attributes to fields within Rancher.
+	
+    1. **Display Name Field**: Enter the AD attribute that contains the display name of users (example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`).
+
+	1. **User Name Field**: Enter the AD attribute that contains the user name/given name (example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`).
+	
+    1. **UID Field**: Enter an AD attribute that is unique to every user (example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn`).
+	
+    1. **Groups Field**: Make entries for managing group memberships (example: `http://schemas.xmlsoap.org/claims/Group`).
+	
+    1. **Rancher API Host**: Enter the URL for your Rancher Server.
+
+	1. **Private Key** and **Certificate**: This is a key-certificate pair to create a secure shell between Rancher and your AD FS.
+    
+        You can generate one using an openssl command. For example:
+    
+        ```
+        openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
+        ```
+    1. **Metadata XML**: The `federationmetadata.xml` file exported from your AD FS server. You can find this file at `https://your-AD-Server/federationmetadata/2007-06/federationmetadata.xml`.
+
+ 
+1. After you complete the **Configure AD FS Account** form, click **Authenticate with AD FS**, which is at the bottom of the page.
+
+    Rancher redirects you to the AD FS login page. Enter credentials that authenticate with Microsoft AD FS to validate your Rancher AD FS configuration.
+
+    >**Note:** You may have to disable your popup blocker to see the AD FS login page.
+
+**Result:** Rancher is configured to work with MS FS. Your users can now sign into Rancher using their MS FS logins.
+
+>**Active Directory Federation Service Caveats:**
+>
+>- AD FS does not support search or lookup. When adding users to [clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/) or [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/), the exact IDs must be entered correctly.
+>- When adding users to [clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/) or [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/), group IDs are not supported unless the admin who turned on access control is a member of the group.
+>- When adding a group that includes an admin to [clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/) or [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/), add it from the drop-down rather than the search bar. If you add the group using the search bar, the group will not get added.
@@ -7,51 +7,122 @@ aliases:

 _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.
+If your organization uses LDAP for user authentication, you can configure Rancher to communicate with an OpenLDAP server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the organisation's central user repository, while allowing end-users to authenticate with their LDAP credentials when logging in to the Rancher UI. 
+ 
+## OpenLDAP Authentication Flow 
+ 
+1. When a user attempts to login with his LDAP credentials, Rancher creates an initial bind to the LDAP server using a service account with permissions to search the directory and read user/group attributes. 
+2. Rancher then searches the directory for the user by using a search filter based on the provided username and configured attribute mappings. 
+3. Once the user has been found, he is authenticated with another LDAP bind request using the user's DN and provided password. 
+4. Once authentication succeeded, Rancher then resolves the group memberships both from the membership attribute in the user's object and by performing a group search based on the configured user mapping attribute.

->**Prerequisites:**
+> **Note:**
+> 
+> Before you proceed with the configuration, please familiarise yourself with the concepts of [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
+
+## Prerequisites
+
+Rancher must be configured with a LDAP bind account (aka service account) to search and retrieve LDAP entries pertaining to users and groups that should have access. It is recommended to not use an admin account or personal account for this purpose and instead create a dedicated account in OpenLDAP with read-only access to users and groups under the configured search base (see below).
+
+> **Using TLS?**
 >
->- 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).
+> If the certificate used by the OpenLDAP server is self-signed or not from a recognised certificate authority, make sure have at hand the CA certificate (concatenated with any intermediate certificates) in PEM format. You will have to paste in this certificate during the configuration so that Rancher is able to validate the certificate chain.

-1.  Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_).
+## Configuration Steps
+### Open OpenLDAP Configuration

-2.	From the **Global** view, select **Security > Authentication** from the main menu.
+1. Log into the Rancher UI using the initial local `admin` account.
+2. From the **Global** view, navigate to **Security** > **Authentication**
+3. Select **OpenLDAP**. The **Configure an OpenLDAP server** form will be displayed.

-3.	Select **OpenLDAP**.
+### Configure OpenLDAP Server Settings

-4.	Complete the **Configure an OpenLDAP server** form.
+In the section titled `1. Configure an OpenLDAP server`,   complete the fields with the information specific to your server. Please refer to the following table for detailed information on the required values for each parameter.

-	You may need to log in to your domain controller to find the information requested in the form.
+> **Note:**
+>
+> If you are in doubt about the correct values to enter in the user/group Search Base configuration fields, consult your LDAP administrator or refer to the section [Identify Search Base and Schema using ldapsearch]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/ad/#annex-identify-search-base-and-schema-using-ldapsearch) in the Active Directory authentication documentation.

-	>**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.
+**Table 1: OpenLDAP server parameters**

+| Parameter | Description |
+|:--|:--|
+| Hostname | Specify the hostname or IP address of the OpenLDAP server |
+| Port | Specify the port at which the OpenLDAP server is listening for connections. Unencrypted LDAP normally uses the standard port of 389, while LDAPS uses port 636.|
+| TLS | Check this box to enable LDAP over SSL/TLS (commonly known as LDAPS). You will also need to paste in the CA certificate if the server uses a self-signed/enterprise-signed certificate. |
+| Server Connection Timeout | 	The duration in number of seconds that Rancher waits before considering the server unreachable. |
+| Service Account Distinguished Name | Enter the Distinguished Name (DN) of the user that should be used to bind, search and retrieve LDAP entries. (see [Prerequisites](#prerequisites)). |
+| Service Account Password | The password for the service account.  |
+| User Search Base | Enter the Distinguished Name of the node in your directory tree from which to start searching for user objects. All users must be descendents of this base DN. For example: "ou=people,dc=acme,dc=com".|
+| Group Search Base | If your groups live under a different node than the one configured under `User Search Base` you will need to provide the Distinguished Name here. Otherwise leave this field empty. For example: "ou=groups,dc=acme,dc=com".|

-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.
+### Configure User/Group Schema

-6.	Enter your OpenLDAP username and password in **Authenticate with OpenLDAP** to confirm that Rancher is configured to use OpenLDAP authentication.
+If your OpenLDAP directory deviates from the standard OpenLDAP schema, you must complete the **Customize Schema** section to match it.
+Note that the attribute mappings configured in this section are used by Rancher to construct search filters and resolve group membership. It is therefore always recommended to verify that the configuration here matches the schema used in your OpenLDAP.
+
+> **Note:**
+>
+> If you are unfamiliar with the user/group schema used in the OpenLDAP server, consult your LDAP administrator or refer to the section [Identify Search Base and Schema using ldapsearch]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/ad/#annex-identify-search-base-and-schema-using-ldapsearch) in the Active Directory authentication documentation.
+
+#### User Schema
+
+The table below details the parameters for the user schema configuration.
+
+**Table 2: User schema configuration parameters**
+
+| Parameter | Description |
+|:--|:--|
+| Object Class | The name of the object class used for user objects in your domain. |
+| Username Attribute | The user attribute whose value is suitable as a display name. |
+| Login Attribute | The attribute whose value matches the username part of credentials entered by your users when logging in to Rancher. This is typically `uid`. |
+| User Member Attribute | The user attribute containing the Distinguished Name of groups a user is member of. Usually this is one of `memberOf` or `isMemberOf`. |
+| Search Attribute | When a user enters text to add users or groups in the UI, Rancher queries the LDAP server and attempts to match users by the attributes provided in this setting. Multiple attributes can be specified by separating them with the pipe ("\|") symbol. |
+| User Enabled Attribute | If the schema of your OpenLDAP server supports a user attribute whose value can be evaluated to determine if the account is disabled or locked, enter the name of that attribute. The default OpenLDAP schema does not support this and the field should usually be left empty. |
+| Disabled Status Bitmask | This is the value for a disabled/locked user account. The parameter is ignored if `User Enabled Attribute` is empty. |
+
+---
+
+#### Group Schema
+
+The table below details the parameters for the group schema configuration.
+
+**Table 3: Group schema configuration parameters**
+
+| Parameter | Description |
+|:--|:--|
+| Object Class | The name of the object class used for group entries in your domain. |
+| Name Attribute | The group attribute whose value is suitable for a display name. |
+| Group Member User Attribute | The name of the **user attribute** whose format matches the group members in the `Group Member Mapping Attribute`. |
+| Group Member Mapping Attribute | The name of the group attribute containing the members of a group. |
+| Search Attribute | Attribute used to construct search filters when adding groups to clusters or projects in the UI. See description of user schema `Search Attribute`. |
+| Group DN Attribute | The name of the group attribute whose format matches the values in the user's group membership attribute. See  `User Member Attribute`. |
+| Nested Group Membership | This settings defines whether Rancher should resolve nested group memberships. Use only if your organisation makes use of these nested memberships (ie. you have groups that contain other groups as members). |
+
+---
+
+### Test Authentication
+
+Once you have completed the configuration, proceed by testing  the connection to the OpenLDAP server. Authentication with OpenLDAP will be enabled implicitly if the test is successful.
+
+> **Note:**
+>
+> The OpenLDAP user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned admin privileges in Rancher. You should therefore make a conscious decision on which LDAP account you use to perform this step.
+
+1. Enter the **username** and **password** for the OpenLDAP account that should be mapped to the local principal account.
+2. Click **Authenticate With OpenLDAP** to test the OpenLDAP connection and finalise the setup.

 **Result:**

 - OpenLDAP authentication is configured.
- You are signed into Rancher with your OpenLDAP account (i.e., the _external principal_).
+- The LDAP user pertaining to the entered credentials is mapped to the local principal (administrative) account.
+
+> **Note:**
+>
+> You will still be able to login using the locally configured `admin` account and password in case of a disruption of LDAP services.
+
+## Annex: Troubleshooting
+
+If you are experiencing issues while testing the connection to the OpenLDAP server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation.
@@ -0,0 +1,52 @@
+---
+title: Configuring PingIdentity (SAML)
+weight: 1200
+---
+_Available as of v2.0.7_
+
+If your organization uses Ping Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
+
+>**Prerequisites:**
+>
+>- You must have a [Ping IdP Server](https://www.pingidentity.com/) configured.
+>- Export a `metadata.xml` file from your IdP Server. For more information, see the [PingIdentity documentation](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html).
+
+1.	From the **Global** view, select **Security > Authentication** from the main menu.
+
+1.	Select **PingIdentity**.
+
+1.	Complete the **Configure Ping Account** form. Ping IdP lets you specify what data store you want to use. You can either add a database or use an existing ldap server. For example, if you select your Active Directory (AD) server, the examples below describe how you can map AD attributes to fields within Rancher.
+	
+    1. **Display Name Field**: Enter the AD attribute that contains the display name of users (example: `displayName`).
+
+	1. **User Name Field**: Enter the AD attribute that contains the user name/given name (example: `givenName`).
+	
+    1. **UID Field**: Enter an AD attribute that is unique to every user (example: `sAMAccountName`, `distinguishedName`).
+	
+    1. **Groups Field**: Make entries for managing group memberships (example: `memberOf`).
+	
+    1. **Rancher API Host**: Enter the URL for your Rancher Server.
+
+	1. **Private Key** and **Certificate**: This is a key-certificate pair to create a secure shell between Rancher and your IdP. 
+    
+        You can generate one using an openssl command. For example:
+    
+        ```
+        openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
+        ```
+    1. **IDP-metadata**: The `metadata.xml` file that you [exported from your IdP server](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html).
+
+ 
+1. After you complete the **Configure Ping Account** form, click **Authenticate with Ping**, which is at the bottom of the page. 
+
+    Rancher redirects you to the IdP login page. Enter credentials that authenticate with Ping IdP to validate your Rancher PingIdentity configuration.
+
+    >**Note:** You may have to disable your popup blocker to see the IdP login page.
+
+**Result:** Rancher is configured to work with PingIdentity. Your users can now sign into Rancher using their PingIdentity logins.
+
+>**Ping Identity Provider Caveats:** 
+>
+>- IdP does not support search or lookup. When adding users to [clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/) or [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/), the exact IDs must be entered correctly.
+>- When adding users to [clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/) or [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/), group IDs are not supported unless the admin who turned on access control is a member of the group.
+>- When adding a group that includes an admin to clusters or projects, add it from the drop-down rather than the search bar. If you add the group using the search bar, the group will not get added.
@@ -19,11 +19,27 @@ _Pod Security Policies_ (or PSPs) are objects that control security-sensitive as

 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.
+>**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.

+## Default Pod Security Policies
+
+_Available as of v2.0.7_
+
+Rancher ships with two default Pod Security Policies (PSPs): the `restricted` and `unrestricted` policies.
+
+- `restricted`
+
+	This policy is equivilent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project.
+
+- `unrestricted`
+
+	This policy is based on the Kubernetes [example restricted policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#example-policies). It significantly restricts what types of pods can be deployed to a cluster or project. This policy:
+	
+	- Prevents pods from running as a privileged user and prevents escalation of privileges.
+	- Validates that server-required security mechanisms are in place (such as restricting what volumes can be mounted to only the core volume types and preventing root supplemental groups from being added). 
+
 ## Creating Pod Security Policies

 1.	From the **Global** view, select **Security** > **Pod Security Policies** from the main menu. Then click **Add Policy**.
@@ -44,7 +60,6 @@ Using Rancher, you can create a Pod Security Policy using our GUI rather than cr
 	- [Volume Policy][1]
 	- [Allowed Host Paths Policy][1]
 	- [FS Group Policy][1]
-	- [Run As User Policy][1]
 	- [Host Ports Policy][2]
 	- [Run As User Policy][3]
 	- [SELinux Policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#selinux)
@@ -55,9 +70,9 @@ Using Rancher, you can create a Pod Security Policy using our GUI rather than cr
 You can add a Pod Security Policy (PSPs hereafter) in the following contexts:

 - [When creating a cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/pod-security-policies/)
- [When editing an existing cluster]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/editing-clusters/)
- [When creating a project]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/#creating-a-project/)
- [When editing an existing project]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/editing-projects/)
+- [When editing an existing cluster]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/)
+- [When creating a project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#creating-a-project/)
+- [When editing an existing project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/)

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

@@ -17,11 +17,11 @@ After you configure external authentication, the users that display on the **Use

 Once the user logs in to Rancher, their _authorization_, or their access rights within the system, is determined by _global permissions_, and _cluster and project roles_.  

- **[Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/):**
+- [Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/):

    Define user authorization outside the scope of any particular cluster.

- **[Cluster and Project Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/):**
+- [Cluster and Project Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/):

    Define user authorization inside the specific cluster or project where they are assigned the role.

@@ -17,11 +17,11 @@ When you create a cluster or project, Rancher automatically assigns you as the `

 _Cluster roles_ are roles that you can assign to users, granting them access to a cluster. There are two primary cluster roles: `Owner` and `Member`.

- **Owner:**
+- **Cluster Owner:**

    These users have full control over the cluster and all resources in it.

- **Member:**
+- **Cluster Member:**

    These users can view most cluster level resources and create new projects.

@@ -49,11 +49,11 @@ The following table lists each built-in custom cluster role available in Rancher

 _Project roles_ are roles that can be used to grant users access to a project. There are three primary project roles: `Owner`, `Member`, and `Read Only`.

- **Owner:**
+- **Project Owner:**

    These users have full control over the project and all resources in it.

- **Member:**
+- **Project Member:**

    These users can manage project-scoped resources like namespaces and workloads, but cannot manage other project members.

@@ -95,3 +95,42 @@ The following table lists each built-in custom project role available in Rancher
 As previously mentioned, custom roles can be defined for use at the cluster or project level. The context field defines whether the role will appear on the cluster member page, project member page, or both.

 When defining a custom role, you can grant access to specific resources or specify roles from which the custom role should inherit. A custom role can be made up of a combination of specific grants and inherited roles. All grants are additive. This means that defining a narrower grant for a specific resource **will not** override a broader grant defined in a role that the custom role is inheriting from.
+
+### Default Cluster and Project Roles
+
+By default, when a user creates a new cluster or project, they are automatically assigned an ownership role: either [cluster owner](#cluster-roles) or [project owner](#project-roles). However, in some organizations, these roles may overextend administrative access. In this use case, you can change the default role to something more restrictive, such as a set of individual roles or a custom role.
+
+There are two methods for changing default cluster/project roles:
+
+- **Assign Custom Roles**: Create a [custom role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles) for either your [cluster](#custom-cluster-roles) or [project](#custom-project-roles), and then set the custom role as default.
+
+- **Assign Individual Roles**: Configure multiple [cluster](#cluster-role-reference)/[project](#project-role-reference) roles as default for assignment to the creating user.
+
+    For example, instead of assigning a role that inherits other roles (such as `cluster owner`), you can choose a mix of individual roles (such as `manage nodes` and `manage storage`).
+
+>**Note:** 
+>
+>- Although you can [lock]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/locked-roles/) a default role, the system still assigns the role to users who create a cluster/project.
+>- Only users that create clusters/projects inherit their roles. Users added to the cluster/project membership afterward must be explicitly assigned their roles.
+
+### Configuring Default Roles
+
+You can change the cluster or project role(s) that are automatically assigned to the creating user.
+
+1. From the **Global** view, select **Security > Roles** from the main menu. Select either the **Cluster** or **Project** tab.
+
+1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **Ellipsis > Edit**.
+
+1. Enable the role as default.
+{{% accordion id="cluster" label="For Clusters" %}}
+1. From **Clustor Creator Default**, choose **Yes: Default role for new cluster creation**.
+1. Click **Save**. 
+{{% /accordion %}}
+{{% accordion id="project" label="For Projects" %}}
+1. From **Project Creator Default**, choose **Yes: Default role for new project creation**.
+1. Click **Save**.  
+{{% /accordion %}}
+
+1. If you want to remove a default role, edit the permission and select **No** from the default roles option.
+
+**Result:** The default roles are configured based on your changes. Roles assigned to cluster/project creators display a check in the **Cluster/Project Creator Default** column.
@@ -3,13 +3,13 @@ title: Global Permissions
 weight: 1126
 ---

-Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are two default global permissions: `Administrator` and `Standard User`.
+Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are two default global permissions: `Administrator` and `User`.

 - **Administrator:**

    These users have full control over the entire Rancher system and all clusters within it.

- **Standard User:**
+- <a id="user"></a>**User:**

    These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters.

@@ -52,3 +52,25 @@ The following table lists each custom global permission available and whether it
 | Login Access                       | ✓             | ✓             |

 > **Note:** Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalroles`.
+
+### Default Global Permissions for New Users
+
+When a user from an [external authentication source]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) signs into Rancher for the first time, they're automatically assigned a set of global permissions (hereafter, permissions). By default, new users are assigned the [user](#user) permissions. However, in some organizations, these permissions may extend too much access. In this use case, you can change the default permissions to something more restrictive, such as a set of individual permissions.
+
+You can assign one or more default permissions. For example, the `user` permission assigns new users a [set of individual global permissions](#global-permissions-reference). If you want to restrict the default permissions for new users, you can remove the `user` permission as default role and then assign multiple individual permissions as default instead. Conversely, you can also add administrative permissions on top of a set of other standard permissions.
+
+>**Note:** Default roles are only assigned to external users. For local users, you must explicitly assign global permissions.
+
+### Configuring Default Global Permissions
+
+You can change the default global permissions that are assigned to external users upon their first log in.
+
+1. From the **Global** view, select **Security > Roles** from the main menu. Make sure the **Global** tab is selected.
+
+1. Find the permissions set that you want to use as default. Then edit the permission by selecting **Ellipsis > Edit**.
+
+1. Select **Yes: Default role for new users** and then click **Save**.
+
+1. If you want to remove a default permission, edit the permission and select **No** from **New User Default**.
+
+**Result:** The default global permissions are configured based on your changes. Permissions assigned to new users display a check in the **New User Default** column.
@@ -1,18 +1,14 @@
 ---
-title: Backups and Rollbacks
+title: Backups and Disaster Recovery
 weight: 1000
 ---

 This section is devoted to protecting your Rancher Server data in a disaster scenario.

- [Backups](./backups/)
+- [Backups]({{< baseurl >}}/rancher/v2.x/en/backups/backups)

    To protect yourself from a disaster scenario, you should create Rancher backups on a regular basis.

- [Restorations](./restorations/)
+- [Restorations]({{< baseurl >}}/rancher/v2.x/en/backups/restorations)

    In a disaster scenario, you can restore your `etcd` database by restoring a backup.
-
- [Rollbacks](./rollbacks/)
-
-    If an upgrade does not complete successfully, you can revert you Rancher Server to its previous version along with its data prior to upgrade.
@@ -3,10 +3,10 @@ title: Creating Backups—Single Node Installs
 weight: 25
 aliases:
  - /rancher/v2.x/en/installation/after-installation/single-node-backup-and-restoration/
-  - /rancher/v2.x/en/installation/backups-and-restoration/single-node-backup-and-restoration/ 
+  - /rancher/v2.x/en/installation/backups-and-restoration/single-node-backup-and-restoration/
 ---

-After completing your single node installation of Rancher create a backup of your current installation. Use this backup as a restoration point in disaster scenarios.
+After completing your single node installation of Rancher, you can create a backup of your current installation at any time. We recommend making a backup before [upgrading]({{< baseurl >}}/rancher/v2.x/en/upgrades/single-node-upgrade/). Use this backup as a restoration point in disaster scenarios or when you need to [rollback]({{< baseurl >}}/rancher/v2.x/en/backups/rollbacks/single-node-rollbacks/) to an older version.

 >**Prerequisite:** Open Rancher and write down the version number displayed in the lower-left of the browser (example: `v2.0.0`). You'll need this number during the backup process.

@@ -18,20 +18,29 @@ docker stop <RANCHER_CONTAINER_ID>

    >**Tip:** You can obtain the ID for your Rancher container by entering the following command: `docker ps`.

-2. <a id="backup"></a>Create a backup container. This container backs up the data from your current Rancher Server, which you can use as a recovery point.
+2. <a id="backup"></a>Create a data container. This container contains the data from your current Rancher Server, and can be used to start Rancher Server.

    - Replace `<RANCHER_CONTAINER_ID>` with the same ID from the previous step.
    - Replace `<RANCHER_VERSION>` and `<RANCHER_CONTAINER_TAG>` with the version of Rancher that you are currently running, as mentioned in the  **Prerequisite** above.

    ```
 docker create --volumes-from <RANCHER_CONTAINER_ID> \
--name rancher-backup-<RANCHER_VERSION> rancher/rancher:<RANCHER_CONTAINER_TAG>
+--name rancher-data-<RANCHER_VERSION> rancher/rancher:<RANCHER_CONTAINER_TAG>
    ```

-3. Restart Rancher Server. Replace `<RANCHER_CONTAINER_ID>` with the ID of your Rancher container.
+3. During upgrade, you point to a Rancher server to the same Rancher data container and the Rancher data in the data container will continue to be updated/changed. Therefore, you need to get a snapshot of the data to be used for disaster recovery or in case you need to rollback the upgrade.

    ```
+docker run  --volumes-from rancher-data-<RANCHER_VERSION> \
+-v $PWD:/backup alpine tar zcvf \
+/backup/rancher-data-backup-<RANCHER_VERSION>.tar.gz /var/lib/rancher
+    ```
+
+3. After you've created your backup, you can either restart Rancher server or [upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/single-node-upgrade/). Replace `<RANCHER_CONTAINER_ID>` with the ID of your Rancher container.
+
+    ```
+# Restart Rancher server
 docker start <RANCHER_CONTAINER_ID>
    ```

-**Result:** A backup of your Rancher Server is created. If you ever need to restore your backup, see [Restoring Backups: Single Node Installs]({{< baseurl >}}/rancher/v2.x/en/upgrades/restorations/single-node-restoration).
+**Result:** A backup of your Rancher Server is created. If you ever need to restore your backup, see [Restoring Backups: Single Node Installs]({{< baseurl >}}/rancher/v2.x/en/upgrades/restorations/single-node-restoration).
@@ -10,33 +10,46 @@ This procedure describes how to restore your a snapshot of `etcd` if you lose yo

 Following a disaster scenario, restoration of your HA Rancher installation requires you to pull your snapshot from your chosen external location and then restore it.

-1. [Create New Node and Pull Snapshot](#1-create-new-node-and-pull-snapshot)
+1. [Create New Nodes and Pull Snapshot and Certificates Bundle](#1-create-new-nodes-and-pull-snapshot-and-certificate-bundle)

-	If one of your `etcd` nodes goes down, create a new node, and then pull the most recent `etcd` snapshot to that node.
+  If `etcd` nodes failed or quorum lost for any reason, you can create new nodes and restore the etcd snapshot and certificate bundle to it, first create the new nodes and then pull the most recent `etcd` snapshot to that node, and the most recent certificates pki bundle `pki.bundle.tar.gz`

 2. [Restore etcd Database](#2-restore-etcd-database)

-	After you pull the snapshot, run the RKE command to restore the `etcd` database.
+	After you pull the snapshot and the certificates bundle, run the RKE command to restore the `etcd` database.

 <br/>
-### 1. Create New Node and Pull Snapshot
+### 1. Pull Snapshot and Certificates Bundle On New Nodes

-If one of your `etcd` nodes go down, you need to replace it with a new node, and then pull the most recent working `etcd` snapshot to that node.
+If `etcd` nodes failed, you can either:

-**To Create a New Node and Pull the Latest Snapshot:**
+- Create a new nodes of your choice—baremetal, on-prem virtual machine, cloud-based virtual machine, and so on. Provision it according to our [requirements]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install/#host-requirements).

-1. Create a new node of your choice—baremetal, on-prem virtual machine, cloud-based virtual machine, and so on. Provision it according to our [requirements]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install/#host-requirements).
+- Use the existing nodes, but you should be make sure to clean each node using the following commands:

-2.  Log in to your new node using a remote Terminal connection.
+```
+docker rm -fv $(docker ps -qa)
+docker volume ls -q | xargs docker volume rm
+rm -rf /etc/kubernetes/ssl
+rm -rf /etc/kubernetes/.tmp
+rm -rf /var/lib/etcd
+rm -rf /etc/cni
+rm -rf /etc/kube-flannel/
+```

+in both cases you will need to pull the most recent working `etcd` snapshot and the certificates bundle to these nodes.

-3.  Create a directory that mirrors your other nodes' snapshot directories:
+**To Pull the Latest Snapshot and Certificates Bundle:**
+
+1.  Log in to each new node using a remote Terminal connection.
+
+2.  Create a directory that mirrors your other nodes' snapshot directories:

 	```
 	root@newnode:~# mkdir -p /opt/rke/etcd-snapshots
 	```

-4. Pull your most recent snapshot onto the node. Replace `<SNAPSHOT.db>` with the name of the snapshot you're restoring to.
+3. On each node, pull your most recent snapshot onto the node. Replace `<SNAPSHOT.db>` with the name of the snapshot you're restoring to.

 	```
 	root@newnode:~# s3cmd get s3://rke-etcd-snapshots/<SNAPSHOT.db> /opt/rke/etcd-snapshots/<SNAPSHOT.db>
@@ -44,17 +57,15 @@ If one of your `etcd` nodes go down, you need to replace it with a new node, and

 	>**Remember:** Our use of Amazon S3 is an example used for this documentation. The command for pulling your snapshot may vary.

+4. On each node, pull the most recent certificates pki bundle to the `/opt/rke/etcd-snapshots`:

-After restoring the cluster you have to restart the kubernetes components on all nodes, otherwise there will be some conflicts with resource versions of objects stored in `etcd`, this will include restart to kubernetes components and the network components, for more information please refer to [kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#etcd-upgrade-requirements), to do that you can run the following on each node:
-```
-docker restart kube-apiserver kubelet kube-controller-manager kube-scheduler kube-proxy
-docker ps | grep flannel | cut -f 1 -d " " | xargs docker restart
-docker ps | grep calico | cut -f 1 -d " " | xargs docker restart
-```
+  ```
+  root@newnode:~# s3cmd get s3://rke-etcd-snapshots/pki.bundle.tar.gz /opt/rke/etcd-snapshots/pki.bundle.tar.gz
+  ```

 ### 2. Restore `etcd` Database

-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.
+To restore the most recent `etcd` snapshot on your new nodes, 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, and extracts the certificate bundle to be used on the next `rke up` run.

 >**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.
 >
@@ -63,17 +74,17 @@ To restore the most recent `etcd` snapshot on your new node, run RKE the command

 1. From your workstation, open `rancher-cluster.yml` in your favorite text editor.

-2. Replace the unresponsive node (`3.3.3.3` in this example) with your new one (`4.4.4.4`). You IP addresses will be different obviously:
-
+2. Replace the unresponsive nodes (`1.1.1.1`, `2.2.2.2`, `3.3.3.3` in this example) with your new one (`4.4.4.4`, `5.5.5.5`, and `6.6.6.6`). You IP addresses will be different obviously:
+```
 		nodes:
-			- address: 1.1.1.1
-			  user: root
-			  role: [controlplane,etcd,worker]
-			  ssh_key_path: ~/.ssh/id_rsa
-			- address: 2.2.2.2
-			  user: root
-			  role: [controlplane,etcd,worker]
-			  ssh_key_path: ~/.ssh/id_rsa
+		#	- address: 1.1.1.1  # UNRESPONSIVE NODE
+		#	  user: root
+		#	  role: [controlplane,etcd,worker]
+		#	  ssh_key_path: ~/.ssh/id_rsa
+		#	- address: 2.2.2.2  # UNRESPONSIVE NODE
+		#	  user: root
+		#	  role: [controlplane,etcd,worker]
+		#	  ssh_key_path: ~/.ssh/id_rsa
 		#	- address: 3.3.3.3  # UNRESPONSIVE NODE
 		#	  user: root
 		#	  role: [controlplane,etcd,worker]
@@ -82,6 +93,15 @@ To restore the most recent `etcd` snapshot on your new node, run RKE the command
 			  user: root
 			  role: [controlplane,etcd,worker]
 			  ssh_key_path: ~/.ssh/id_rsa
+      - address: 5.5.5.5  # NEW NODE
+			  user: root
+			  role: [controlplane,etcd,worker]
+			  ssh_key_path: ~/.ssh/id_rsa
+      - address: 6.6.6.6  # NEW NODE
+			  user: root
+			  role: [controlplane,etcd,worker]
+			  ssh_key_path: ~/.ssh/id_rsa  
+```

 3. Save and close `rancher-cluster.yml`.

@@ -106,7 +126,7 @@ To restore the most recent `etcd` snapshot on your new node, run RKE the command
 	./rke_linux-amd64 up --config rancher-cluster.yml
 	```

-7. Lastly, restart the Kubernetes components on all cluster nodes to prevent potential `etcd` conflicts. Run this command on each of your nodes.
+7. After restoring the cluster you have to restart the kubernetes components on all nodes, otherwise there will be some conflicts with resource versions of objects stored in `etcd`, this will include restart to kubernetes components and the network components, for more information please refer to [kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#etcd-upgrade-requirements), to do that you can run the following on each node:

    ```
    docker restart kube-apiserver kubelet kube-controller-manager kube-scheduler kube-proxy
@@ -6,7 +6,7 @@ aliases:
  - /rancher/v2.x/en/installation/after-installation/single-node-backup-and-restoration/
 ---

-Backup to a restoration point for your Rancher install if you encounter issues when upgrading.
+Restoring to a backup for your Rancher install if you encounter issues in your Rancher setup.

 1. Stop the container currently running Rancher Server. Replace `<RANCHER_CONTAINER_ID>` with the ID of your Rancher container.

@@ -14,11 +14,18 @@ Backup to a restoration point for your Rancher install if you encounter issues w
 docker stop <RANCHER_CONTAINER_ID>
    ```

-1. Launch a new Rancher Server container using the most recent `rancher-backup-<RANCHER_VERSION>` container that you backed up.
- 
-    For more information on obtaining this container name, see [Creating Backups—Single Node Installs](/Users/markbishop/Documents/GitHub/docs/content/rancher/v2.x/en/upgrades/backups/single-node-backups/#backup).
+2. Go to the location where you saved your [backup tar balls]({{< baseurl >}}/rancher/v2.x/en/backups/backups/single-node-backups/#backup). Run the following command to delete your current state data and start your backup data:

-	```
-docker run -d --volumes-from rancher-backup-<RANCHER_VERSION> --restart=unless-stopped \
-p 80:80 -p 443:443 rancher/rancher:<CURRENT_RANCHER_VERSION>
+    ```
+docker run  --volumes-from <RANCHER_CONTAINER_ID> -v $PWD:/backup \
+alpine sh -c "rm /var/lib/rancher/* -rf  && \
+tar zxvf /backup/<BACKUP_FILENAME>.tar.gz"
+    ```
+
+    >**Warning!** Running this command will delete ALL current state data from your Rancher Server container. Any changes that happened after the backup point you are restoring will be lost.
+
+3. Start you rancher server container back. The container will start with the data from the restored backup.
+
+    ```
+docker start <RANCHER_CONTAINER_ID>
    ```
@@ -1,10 +0,0 @@
---
-title: Rollbacks
-shortTitle: Rollbacks
-weight: 1010
---
-
-If you upgrade your Rancher Server and the upgrade is unsuccessful, you can use the backup you created during the upgrade process to restore the previous version of Rancher, along with its data.
-
- [Rolling Back—Single Node Installs](./single-node-rollbacks/)
- [Rolling Back—High Availablity Installs](./ha-server-rollbacks/)
@@ -1,27 +0,0 @@
---
-title: Rolling Back—Single Node Installs
-weight: 25
---
-
-Rolling back an unsuccessful Rancher upgrade requires you to run the upgrade command again, with a couple of modifications:
-
- Run the upgrade command using the server tag for your prior Rancher install.
- Run the upgrade command while pointing toward the backup container you created while completing [Single Node Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrade-scenarios/single-node-upgrade/).
-
->**Warning!** Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
-
-1. Pull the version of Rancher that you were running prior to upgrade.
-
-    ```
-docker pull rancher/rancher:<PRIOR_VERSION>
-    ```
-
-1. Launch a Rancher Server container that you created while completing [Step 3 of Single Node Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrade-scenarios/single-node-upgrade/#backup).
-
-    Replace the `<PRIOR_VERSION>` placeholders with the version number of Rancher that you're rolling back to before upgrade.
-
-    ```
-docker run -d --volumes-from rancher-data-snapshot-<PRIOR_VERSION> --restart=unless-stopped \
-p 80:80 -p 443:443 rancher/rancher:<PRIOR_VERSION>
-    ```
-    >**Note:** _Do not_ stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
@@ -30,7 +30,7 @@ If Rancher Server uses a self-signed certificate, Rancher CLI prompts you to con

 ### Project Selection

-Before you can perform any commands, you must select a Rancher project to perform those commands against. To select a [project]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/) to work on, use the command `./rancher context switch`. When you enter this command, a list of available projects displays. Enter a number to choose your project.
+Before you can perform any commands, you must select a Rancher project to perform those commands against. To select a [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/) to work on, use the command `./rancher context switch`. When you enter this command, a list of available projects displays. Enter a number to choose your project.

 **Example: `./rancher context switch` Output**
 ```
@@ -68,11 +68,11 @@ The following commands are available for use in Rancher CLI.

 - `context`

-    Switches between Rancher [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/). For an example, see [Project Selection](#project-selection).
+    Switches between Rancher [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/). For an example, see [Project Selection](#project-selection).

 - `inspect [OPTIONS] [RESOURCEID RESOURCENAME]`

-    Displays details about [Kubernetes resources](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types) or Rancher resources (i.e.: [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/) and [workloads]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/)). Specify resources by name or ID.
+    Displays details about [Kubernetes resources](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types) or Rancher resources (i.e.: [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/) and [workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/)). Specify resources by name or ID.

 - `kubectl`

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

 - `namespaces, [namespace]`

-    Performs operations on [namespaces]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/#namespaces).
+    Performs operations on [namespaces]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces).

 - `nodes, [node]`

@@ -92,11 +92,11 @@ The following commands are available for use in Rancher CLI.

 - `projects, [project]`

-    Performs operations on [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/).
+    Performs operations on [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/).

 - `ps`

-    Displays [workloads]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads) in a project.
+    Displays [workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads) in a project.

 - `settings, [setting]`

@@ -12,21 +12,21 @@ aliases:

 In the IT world, a cluster is a group of computing resources that work as a team to accomplish a goal.

-A _Kubernetes Cluster_ is a cluster that uses the [Kubernetes container-orchestration system](https://kubernetes.io/) to deploy, maintain, and scale Docker containers, allowing your organization to automate application operations. Kubernetes reduces the manual processes of maintaining organization operations.
+A _Kubernetes Cluster_ is a cluster that uses the [Kubernetes container-orchestration system](https://kubernetes.io/) to deploy, maintain, and scale Docker containers, allowing your organization to automate application operations.

 ### Kubernetes Cluster Node Components

-Each computing resource in a Kubernetes Cluster is called a _node_. Node can be either bare-metal servers or virtual machines. Kubernetes classifies nodes into three distinct types: _etcd_ nodes, _control plane_ nodes, and _worker_ nodes. Understanding the role of each node will help you create your own Kubernetes cluster.
+Each computing resource in a Kubernetes Cluster is called a _node_. Nodes can be either bare-metal servers or virtual machines. Kubernetes classifies nodes into three types: _etcd_ nodes, _control plane_ nodes, and _worker_ nodes.

 #### etcd Nodes

-[etcd](https://kubernetes.io/docs/concepts/overview/components/#etcd) nodes run the `etcd` database. The `etcd` database component is a key value store used as Kubernetes storage for all cluster data, such as cluster coordination and state management.
+[etcd](https://kubernetes.io/docs/concepts/overview/components/#etcd) nodes run the etcd database. The etcd database component is a key value store used as Kubernetes storage for all cluster data, such as cluster coordination and state management.

-`etcd` is a distributed key value store, meaning it runs on multiple nodes so that there's always a backup available for fail over. Even though you can run `etcd` on a single node, you should run it on multiple nodes. We recommend 3, 5, or 7 nodes for redundancy.
+etcd is a distributed key value store, meaning it runs on multiple nodes so that there's always a backup available for fail over. Even though you can run etcd on a single node, you should run it on multiple nodes. We recommend 3, 5, or 7 etcd nodes for redundancy.

 #### Control Plane Nodes

-[Control plane](https://kubernetes.io/docs/concepts/#kubernetes-control-plane) nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your Kubernetes cluster is running according to your configuration. Because all cluster data is stored on your `etcd` nodes, control plane nodes are stateless. You can run control plane on a single node, although two or more nodes are recommended for redundancy. Additionally, you can a single node can share the control plane and `etcd` roles.
+[Control plane](https://kubernetes.io/docs/concepts/#kubernetes-control-plane) nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although two or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles.

 #### Worker Nodes

@@ -35,13 +35,13 @@ Each computing resource in a Kubernetes Cluster is called a _node_. Node can be
 - _Kubelets_: An agent that monitors the state of the node, ensuring your containers are healthy.
 - _Workloads_: The containers and pods that hold your apps, as well as other types of deployments.

-Worker nodes also run storage and networking drivers, and ingress controllers when required. You create as many worker nodes as needed for your workload needs.
+Worker nodes also run storage and networking drivers, and ingress controllers when required. You create as many worker nodes as necessary to run your workloads.

 ## Cluster Creation in Rancher

 Now that you know what a Kubernetes Cluster is, how does Rancher fit in?

-Rancher simplifies creation of Kubernetes clusters by allowing you to create them through the Rancher UI rather than more complex alternatives. Rancher provides multiple options for launching a Kubernetes cluster. Use the option that best fits you use case.
+Rancher simplifies creation of clusters by allowing you to create them through the Rancher UI rather than more complex alternatives. Rancher provides multiple options for launching a cluster. Use the option that best fits your use case.

 ## Cluster Creation Options

@@ -60,30 +60,33 @@ Options include:

 ### Hosted Kubernetes Cluster

-If you already use a Kubernetes provider such as Google GKE, Rancher can integrate with its cloud APIs, allowing you to create and manage your hosted cluster from the Rancher UI.
+If you use a Kubernetes provider such as Google GKE, Rancher integrates with its cloud APIs, allowing you to create and manage a hosted cluster from the Rancher UI.

 [Hosted Kubernetes Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters)

 ### Rancher Launched Kubernetes

-Alternatively, you can use Rancher to create the Kubernetes cluster on your own nodes, using [Rancher Kubernetes Engine (RKE)]({{< baseurl >}}/rke/v0.1.x/en/). RKE is Rancher’s own lightweight Kubernetes installer. With these clusters, Rancher manages the deployment of Kubernetes. These Kubernetes clusters can be deployed on any bare metal server, cloud provider, or virtualization platform. These nodes can either be provisioned through Rancher's UI, which calls [Docker Machine](https://docs.docker.com/machine/) to launch nodes on various cloud providers or they can be existing nodes that users bring and run a Rancher agent container onto.
+Alternatively, you can use Rancher to create a cluster on your own nodes, using [Rancher Kubernetes Engine (RKE)]({{< baseurl >}}/rke/v0.1.x/en/). RKE is Rancher’s own lightweight Kubernetes installer. In RKE clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform. These nodes can either:
+
+- Be provisioned through Rancher's UI, which calls [Docker Machine](https://docs.docker.com/machine/) to launch nodes on various cloud providers.
+- Be a prior existing node that's brought into the cluster by running a Rancher agent container on it.

 [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/)

 #### Node Pools

-Using Rancher, you can create pools of nodes based on a [node template]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates). This node template defines the parameters you want to use to launch nodes in your cloud providers. The available cloud providers to create a node template are decided based on active [node drivers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-drivers). The benefit of using a node pool is that if a node loses connectivity with the cluster, Rancher will automatically create another node to join the cluster to ensure that the count of the node pool is as expected.
+Using Rancher, you can create pools of nodes based on a [node template]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates). This template defines the parameters used to launch nodes in your cloud providers. The cloud providers available for creating a node template are decided based on the [node drivers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-drivers) active in the Rancher UI. The benefit of using a node pool is that if a node loses connectivity with the cluster, Rancher automatically replaces it, thus maintaining the expected cluster configuration.

 [Node Pools]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/)

 #### Custom Nodes

-You can bring any nodes you want to Rancher and have Rancher create the Kubernetes cluster. These nodes can include on-premise bare metal servers, nodes existing in a cloud provider or virtual machines.
+You can bring any nodes you want to Rancher and use them to create a cluster. These nodes include on-premise bare metal servers, cloud-hosted virtual machines, or on-premise virtual machines.

 [Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/)

 ### Import Existing Cluster

-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.
+Users can import an existing Kubernetes cluster into Rancher. Note that Rancher does not automate the provisioning, scaling, or upgrade of imported clusters. All other Rancher features, including management of cluster, policy, and workloads, are available for imported clusters.

 [Importing Existing Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/)
@@ -7,7 +7,7 @@ aliases:

 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/kubernetes-in-rancher/projects-and-namespaces/project-members/) instead.
+>**Tip:** Want to provide a user with access to a _specific_ project within a cluster? See [Adding Project Members]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members/) instead.

 There are two contexts where you can add cluster members:

@@ -15,6 +15,6 @@ There are two contexts where you can add cluster members:

    You can add members to a cluster as you create it (recommended if possible).

- [Adding Members to an Existing Cluster]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/editing-clusters/)
+- [Adding Members to an Existing Cluster]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/)

    You can always add members to a cluster after a cluster is provisioned.
@@ -3,7 +3,7 @@ title: Rancher Launched Kubernetes
 weight: 2200
 ---

-If you don't want to use a hosted Kubernetes provider, you can have Rancher launch a Kubernetes cluster using any nodes you want. When Rancher deploys Kubernetes onto these nodes, it uses Rancher Kubernetes Engine]({{< baseurl >}}/rke/v0.1.x/en/) (RKE), which is Rancher's own lightweight Kubernetes installer. It can launch Kubernetes on any computers, including:
+If you don't want to use a hosted Kubernetes provider, you can have Rancher launch a Kubernetes cluster using any nodes you want. When Rancher deploys Kubernetes onto these nodes, it uses [Rancher Kubernetes Engine]({{< baseurl >}}/rke/v0.1.x/en/) (RKE), which is Rancher's own lightweight Kubernetes installer. It can launch Kubernetes on any computers, including:

 - Bare-metal servers
 - On-premise virtual machines
@@ -18,3 +18,25 @@ RKE launched clusters are separated into two categories:
 - [Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/):

    For use cases where you want to provision bare-metal servers, on-premise virtual machines, or bring virtual machines that are already exist in a cloud provider. With this option, you will run a Rancher agent Docker container on the machine.
+    
+<br/>
+
+### Requirements
+
+If you use RKE to set up a cluster, your cluster nodes must meet the following requirements.
+
+{{< accordion id="os" label="Operating System" >}}
+	{{< requirements_os >}}
+{{< /accordion >}}
+{{< accordion id="hardware" label="Hardware" >}}
+	{{< requirements_hardware >}}
+{{< /accordion >}}
+{{< accordion id="software" label="Software" >}}
+	{{< requirements_software >}}
+{{< /accordion >}}
+{{< accordion id="ports-rancher" label="Ports for Rancher" >}}
+	{{< requirements_ports_rancher >}}
+{{< /accordion >}}
+{{< accordion id="ports-rke" label="Ports for RKE" >}}
+	{{< requirements_ports_rke >}}
+{{< /accordion >}}
@@ -13,7 +13,7 @@ Using Rancher, you can create pools of nodes based on a [node template](#node-te

 Each node pool is assigned with a [node component]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#node-components) to specify how these nodes should be configured for the Kubernetes cluster.

-## Node templates
+## Node Templates

 A node template is the saved configuration for the parameters to use when provisioning nodes in a specific cloud provider. Rancher provides a nice UI to be able to launch these nodes and uses [Docker Machine](https://docs.docker.com/machine/) to provision these nodes. The available cloud providers to create node templates are based on the active node drivers in Rancher.

@@ -44,8 +44,8 @@ If you want to use a node driver that Rancher doesn't support out-of-the-box, yo

 ## Activating/Deactivating Node Drivers

-By default, Rancher only activates drivers for the most popular cloud providers, Amazon EC2, Azure, Digital Ocean and vSphere. If you want to show or hide any node driver, you can change it's status.
+By default, Rancher only activates drivers for the most popular cloud providers, Amazon EC2, Azure, DigitalOcean and vSphere. If you want to show or hide any node driver, you can change it's status.

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

-2.	Find the driver that you want to activate or deactivate and select **Vertical Elipsis (... ) > Edit**. Choose either **Activate** or **Deactivate**.
+2.	Find the driver that you want to activate or deactivate and select **Vertical Elipsis (...) > Edit**. Choose either **Activate** or **Deactivate**.
@@ -9,7 +9,7 @@ Use {{< product >}} to create a Kubernetes cluster using DigitalOcean.

 1. From the **Clusters** page, click **Add Cluster**.

-2. Choose **Digital Ocean**.
+2. Choose **DigitalOcean**.

 3. Enter a **Cluster Name**.

@@ -7,6 +7,16 @@ aliases:
 ---
 Use {{< product >}} to create a Kubernetes cluster in Amazon EC2.

+## Prerequisites
+
+- AWS EC2 Access Key and Secret key that will be used to create the instances. See [Amazon Documentation: Creating Access Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) how to create an Access Key and Secret Key.
+- IAM Policy created to add to the user of the Access Key And Secret Key. See [Amazon Documentation: Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) how to create an IAM policy. See our two example JSON policies below:
+  - [Example IAM Policy](#example-iam-policy)
+  - [Example IAM Policy with PassRole](#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers) or want to pass an IAM Profile to an instance)
+- IAM Policy added as Permission to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to an user.
+
+## Create the cluster
+
 1. From the **Clusters** page, click **Add Cluster**.
 1. Choose **Amazon EC2**.
 1. Enter a **Cluster Name**.
@@ -18,16 +28,13 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2.

      Complete each of the following forms using information available from the [EC2 Management Console](https://aws.amazon.com/ec2).

-      * **Account Access** is there you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine.
+      * **Account Access** is where you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine. See [Prerequisistes](#prerequisistes) how to create the Access Key and Secret Key and the needed permissions.

-        [Amazon Documentation: Creating Access Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey).
-
-        See [Example Node IAM policy](#example-node-iam-policy) for an example policy that can be applied to these credentials.
 	- **Zone and Network** configures the availability zone and network settings for your cluster.
-    - **Security Groups** creates or configures the security groups applied to your nodes.
+    - **Security Groups** creates or configures the Security Groups applied to your nodes. Please refer to [Amazon EC2 security group when using Node Driver]({{< baseurl >}}/rancher/v2.x/en/installation/references/#amazonec2-securitygroup-nodedriver) to see what rules are created in the `rancher-nodes` Security Group.
    - **Instance** configures the instances that will be created. Make sure you configure the correct **SSH User** for the configured AMI.

-    If you need to pass an **IAM Instance Profile Name** (not ARN), for example, when you want to use a [Kubernetes Cloud Provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers), you will need an additional permission in your policy. See [Example Node IAM policy with PassRole](#example-node-iam-policy-with-passrole) for an example policy.
+    If you need to pass an **IAM Instance Profile Name** (not ARN), for example, when you want to use a [Kubernetes Cloud Provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers), you will need an additional permission in your policy. See [Example IAM policy with PassRole](#example-iam-policy-with-passrole) for an example policy.

 	1. {{< step_rancher-template >}}
 	1. Click **Create**.
@@ -36,7 +43,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2.

 {{< result_create-cluster >}}

-### Example Node IAM Policy
+### Example IAM Policy

 ```json
 {
@@ -88,7 +95,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2.
 }
 ```

-### Example Node IAM Policy with PassRole
+### Example IAM Policy with PassRole

 ```json
 {
@@ -7,40 +7,84 @@ aliases:
 ---
 Use {{< product >}} to create a Kubernetes cluster in vSphere.

-### Prerequisites
+## Introduction

-Before setting up a cluster in vSphere, you must ensure that you have a user in vSphere with sufficient permissions to create a Rancher cluster.
+When creating a vSphere cluster, Rancher first provisions the specified amount of virtual machines by communicating with the vCenter API. Then it installs Kubernetes on top of them. A vSphere cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for the data, control, and worker plane respectively.
+
+>**Note:**
+>The vSphere node driver included in Rancher currently only supports the provisioning of VMs with [RancherOS]({{< baseurl >}}/os/v1.x/en/) as the guest operating system.
+
+## Prerequisites
+
+Before proceeding to create a cluster, you must ensure that you have a vSphere user with sufficient permissions. If you are planning to make use of vSphere volumes for persistent storage in the cluster, there are [additional requirements]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere/) that must be met.
+The following steps create a role with the required privileges and then assign it to a new user in the vSphere console:

 1. From the **vSphere** console, go to the **Administration** page.

 2. Go to the **Roles** tab.

-3. Create a new *Role*.  Give it a name and select the **Datastore**, **Network**, **Resource**, and **Virtual machine** *privileges*.
+3. Create a new role.  Give it a name and select the privileges listed in the [permissions table](#annex-vsphere-permissions).

-![image](./rancherroles1.png)
-![image](./rancherroles2.png)
+	![image]({{< baseurl >}}/img/rancher/rancherroles1.png)

 4. Go to the **Users and Groups** tab.

-5. Create a new *User*. Fill out the form and then click **ok**. Make sure to note the username and password as you will need it when creating a cluster in Rancher.
+5. Create a new user. Fill out the form and then click **OK**. Make sure to note the username and password, as you will need it when configuring node templates in Rancher.

-![image](./rancheruser.png)
+	![image]({{< baseurl >}}/img/rancher/rancheruser.png)

 6. Go to the **Global Permissions** tab.

-7. Create a new *Global Permission*.  Add the *User* you created earlier and assign it the Role you created earlier. Click **ok**.
+7. Create a new Global Permission.  Add the user you created earlier and assign it the role you created earlier. Click **OK**.

-![image](./globalpermissionuser.png)
-![image](./globalpermissionrole.png)
-![image](./globalpermissionfinal.png)
+	![image]({{< baseurl >}}/img/rancher/globalpermissionuser.png)

-Now you have a user that is able to successfully create and manager Rancher clusters in vSphere.
+	![image]({{< baseurl >}}/img/rancher/globalpermissionrole.png)

-### Creating vSphere Clusters
+## Creating vSphere Clusters

-To create the cluster.
+### Create a vSphere Node Template

-1. From the **Clusters** page, click **Add Cluster**.
+To create a cluster, you need to create at least one vSphere [node template]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates)  that specifies how VMs are created in vSphere.
+
+>**Note:**
+>Once you create a node template, it is saved, and you can re-use it whenever you create additional vSphere clusters.
+
+1. Log in with an admin account to the Rancher UI.
+
+2. From the user settings menu, select **Node Templates**.
+
+3. Click **Add Template** and then click on the **vSphere** icon.
+
+4. Under [Account Access](#account-access) enter the vCenter FQDN or IP address and the credentials for the vSphere user account (see [Prerequisites](#prerequisites)).
+
+5. Under [Instance Options](#instance-options), configure the number of vCPUs, memory, and disk size for the VMs created by this template.
+
+6. **Optional:** Enter the URL pointing to a [RancherOS]({{< baseurl >}}/os/v1.x/en/) cloud-config file in the [Cloud Init](#instance-options) field.
+
+7. Ensure that the [OS ISO URL](#instance-options) contains the URL of a VMware ISO release for RancherOS (`rancheros-vmware.iso`).
+
+	![image]({{< baseurl >}}/img/rancher/vsphere-node-template-1.png)
+
+8. **Optional:** Provide a set of [Configuration Parameters](#instance-options) for the VMs.
+
+9. Under **Scheduling**, enter the name/path of the **Data Center** to create the VMs in, the name of the **VM Network** to attach to, and the name/path of the **Datastore** to store the disks in.
+
+	![image]({{< baseurl >}}/img/rancher/vsphere-node-template-2.png)
+
+10. **Optional:** Assign labels to the VMs that can be used as a base for scheduling rules in the cluster.
+
+11. **Optional:** Customize the configuration of the Docker daemon on the VMs that will be created.
+
+10. Assign a descriptive **Name** for this template and click **Create**.
+
+___
+
+### Create a vSphere Cluster
+
+After you've created a template, you can use it stand up the vSphere cluster itself.
+
+1. From the **Global** view, click **Add Cluster**.

 2. Choose **vSphere**.

@@ -52,23 +96,64 @@ To create the cluster.

 6. {{< step_create-cluster_node-pools >}}

-	1.	Click **Add Node Template**.
+	![image]({{< baseurl >}}/img/rancher/vsphere-cluster-create-1.png)

-	2.	Use the **vSphere Options** to authenticate with vSphere and provision your cluster.
+7. Review your configuration, then click **Create**.

-		- **Account Access** holds the host name for your vCenter host and your credentials for authentication.
-
-		- **Instance Options** are used to provision your cluster's VMs.
-
-		- **Scheduling** is used to choose the hypervisor your virtual machines will be scheduled to.
-
-	3. {{< step_rancher-template >}}
-
-	4. Click **Create**.
-
-	5. **Optional:** Add additional node pools.
-
-<br/>
-7. Review your options to confirm they're correct. Then click **Create**.
+> **Note:**
+> 
+> If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html) is recommended. These rules allow VMs  assigned the etcd and control-plane roles to operate on separate ESXi hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes.

 {{< result_create-cluster >}}
+
+## Annex - Node Template Configuration Reference
+
+The tables below describe the configuration options available in the vSphere node template.
+
+### Account Access
+
+| Parameter                | Required | Description |
+|:------------------------:|:--------:|:------------------------------------------------------------:|
+| vCenter or ESXi Server   |   *      | IP or FQDN of the vCenter or ESXi server used for managing VMs. |
+| Port                     |   *      | Port to use when connecting to the server. Defaults to `443`.  |
+| Username                 |   *      | vCenter/ESXi user to authenticate with the server. |
+| Password                 |   *      | User's password. |
+
+___
+
+### Instance Options
+
+| Parameter                | Required | Description |
+|:------------------------:|:--------:|:------------------------------------------------------------:|
+| CPUs                     |   *      | Number of vCPUS to assign to VMs. |
+| Memory                   |   *      | Amount of memory to assign to VMs.  |
+| Disk                     |   *      | Size of the disk (in MB) to attach to the VMs. |
+| Cloud Init               |          | URL of a [RancherOS cloud-config]({{< baseurl >}}/os/v1.x/en/installation/configuration/) file to provision VMs with. This file allows further customization of the RancherOS operating system, such as network configuration, DNS servers, or system daemons.|
+| OS ISO URL               |   *      | URL of a RancherOS vSphere ISO file to boot the VMs from. You can find URLs for specific versions in the [Rancher OS GitHub Repo](https://github.com/rancher/os). |
+| Configuration Parameters |          | Additional configuration parameters for the VMs. These correspond to the [Advanced Settings](https://kb.vmware.com/s/article/1016098) in the vSphere console. Example use cases include providing RancherOS [guestinfo]({{< baseurl >}}/os/v1.x/en/installation/running-rancheros/cloud/vmware-esxi/#vmware-guestinfo) parameters or enabling disk UUIDs for the VMs (`disk.EnableUUID=TRUE`). |
+
+___
+
+### Scheduling Options
+
+| Parameter                | Required | Description |
+|:------------------------:|:--------:|:------------------------------------------------------------:|
+| Data Center              |   *      | Name/path of the datacenter to create VMs in.          |
+| Pool                     |          | Name/path of the resource pool to schedule the VMs in. If not specified, the default resource pool is used.  |
+| Host                     |          | Name/path of the host system to schedule VMs in. If specified, the host system's pool will be used and the *Pool* parameter will be ignored. |
+| Network                  |   *      | Name of the VM network to attach VMs to. |
+| Data Store               |   *      | Datastore to store the VM disks. |
+| Folder                   |          | Name/path of folder in the datastore to create the VMs in. Must already exist. |
+
+___
+
+## Annex - vSphere Permissions
+
+The following table lists the permissions required for the vSphere user account configured in the node templates:
+
+| Privilege Group       | Operations  |
+|:----------------------|:-----------------------------------------------------------------------|
+| Datastore             | AllocateSpace </br> Browse </br> FileManagement </br> UpdateVirtualMachineFiles </br> UpdateVirtualMachineMetadata |
+| Network               | Assign |
+| Resource              | AssignVMToPool |
+| Virtual Machine       | Config (All) </br> GuestOperations (All) </br> Interact (All) </br> Inventory (All) </br> Provisioning (All) |
@@ -20,27 +20,49 @@ From this section you can choose:

 - Whether Rancher should check if the nodes are running a supported or unsupported version of Docker. If you only allow supported versions, the cluster automatically fails to launch if you have an unsupported version of Docker. Each Kubernetes version is tied to specific Docker versions based on what Kubernetes tests against.

- The [Network Provider](https://kubernetes.io/docs/concepts/cluster-administration/networking/) that the cluster uses. Out of the box, Rancher supports:
+- The [Network Provider](https://kubernetes.io/docs/concepts/cluster-administration/networking/) that the cluster uses. 

-    - **[Canal](https://github.com/projectcalico/canal)**: In v2.0.0 - v2.0.4 and v2.0.6, this was the default option for these clusters was Canal with network isolation. With the network isolation automatically enabled, it prevented any pod communication between [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/).
+    >**Note:** After you launch the cluster, you cannot change your network provider. Therefore, choose which network provider you want to use carefully, as Kubernetes doesn't allow switching between network providers. Once a cluster is created with a network provider, changing network providers would require you  tear down the entire cluster and all its applications.

-    - **[Flannel](https://github.com/coreos/flannel#flannel)**: In v2.0.5, this was the default option, which did not prevent any network isolation between projects.
+    Out of the box, Rancher supports the following network providers:

-    - **[Calico](https://docs.projectcalico.org/v3.1/introduction/)**
+    - <a id="canal"></a>[Canal](https://github.com/projectcalico/canal)
+    
+        In v2.0.0 - v2.0.4 and v2.0.6, this was the default option for these clusters was Canal with network isolation. With the network isolation automatically enabled, it prevented any pod communication between [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/).
+          
+        As of release v2.0.7, if you use Canal, you also have the option of using **Project Network Isolation**, which will enable or disable communication between pods in different [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/).
+    
+        >**Attention Rancher v2.0.0 - v2.0.6 Users**
+        >
+        >- In previous Rancher releases, Canal isolates project network communications with no option to disable it. If you are using any of these Rancher releases, be aware that using Canal prevents all communication between pods in different projects.
+        >- If you are have clusters using Canal and are upgrading to v2.0.7, those clusters enable Project Network Isolation by default. If you want to disable Project Network Isolation, edit the cluster and disable the option. 
+        

-    > **Note:** Please carefully select which network provider you want to use as Kubernetes doesn't allow switching between network providers. Once a cluster is created with a network provider, you would need to tear down the entire cluster and all applications to be able to switch to a different one.
+    - [Flannel](https://github.com/coreos/flannel#flannel)
+    
+         In v2.0.5, this was the default option, which did not prevent any network isolation between projects.

- Whether or not to use a [cloud provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers). If you want to use [volumes and storage]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider.
+    - [Calico](https://docs.projectcalico.org/v3.1/introduction/)

-   > **Note:** If your cloud provider is not listed as an option, you will need to use the [config file option](#config-file) to use that cloud provider. Please reference the [RKE's cloud provider documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) on how to configure these other cloud providers.
+        Another network provider option.
+
+<br/>
+
+- Whether or not to use a [cloud provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers). If you want to use [volumes and storage]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider.
+
+    >**Note:** If your cloud provider is not listed as an option, you will need to use the [config file option](#config-file) to use that cloud provider. Please reference the [RKE's cloud provider documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) on how to configure these other cloud providers.

 - Whether or not to use a [pod security policy]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies). You must have an existing pod security policy configured before you can use this option.

 ## Config File

+>**Note:** In Rancher v2.0.5 and v2.0.6, the names of services in the Config File (YAML) should contain underscores only: `kube_api` and `kube_controller`.
+
 Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/v0.1.x/en/config-options/) in an RKE installation.

 - To edit an RKE config file directly from the Rancher UI, click **Edit as YAML**.
 - To read from an existing RKE file, click **Read from File**.

+![image]({{< baseurl >}}/img/rancher/cluster-options-yaml.png)
+
 For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/).  
@@ -24,19 +24,14 @@ When using the `Amazon` cloud provider, you can leverage the following capabilit

 ### Prerequisites

- Create/configure an IAM role
+- Create an IAM role and attach to the instances
 - Configuring the ClusterID

-> **Note:** When you create an [Amazon EC2 Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/#create-the-amazon-ec2-cluster), the `ClusterID` is automatically configured.
+> **Note:** When you create an [Amazon EC2 Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/#create-the-amazon-ec2-cluster), the `ClusterID` is automatically configured for the created nodes. Other resources still need to be tagged manually.

-#### Create/Configure an IAM Role
+#### Create an IAM Role and attach to the instances

-All nodes added to the cluster must be able to interact with EC2 so that they can create and remove resources. You can enable this interaction by using an IAM role attached to the instance.
-
-[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/cluster-provisioning/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/cluster-provisioning/custom-clusters/), you must  manually attach the IAM role to the instance(s).
+All nodes added to the cluster must be able to interact with EC2 so that they can create and remove resources. You can enable this interaction by using an IAM role attached to the instance. See [Amazon documentation: Creating an IAM Role](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#create-iam-role) how to create an IAM role.

 The following IAM role can be created:

@@ -73,6 +68,9 @@ The following IAM role can be created:
 }
 ```

+- While creating an [Amazon EC2 cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/#create-the-amazon-ec2-cluster), you must fill in the **IAM Instance Profile Name** (not ARN) of the created IAM role when creating the **Node Template**. This requires an additional IAM permission, see [Example IAM Policy with PassRole]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/#example-iam-policy-with-passrole).
+- While creating a [Custom cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/custom-clusters/), you must manually attach the IAM role to the instance(s).
+
 #### Configuring the ClusterID

 The following resources need to tagged with a `ClusterID`:
@@ -0,0 +1,32 @@
+---
+title: Telemetry
+weight: 8006
+---
+
+### What is Telemetry?
+
+Telemetry collects aggregate information about the size of Rancher installations, versions of components used, and which features are used.  This information is used by Rancher Labs to help make the product better and is not shared with third-parties.
+
+### What information is collected?
+
+No specific identifying information like usernames, passwords, or the names or addresses of user resources will ever be collected.
+
+The primary things collected include:
+
+  - Aggregate counts (smallest, average, largest, total) of nodes per-cluster and their size (e.g. CPU cores & RAM).
+  - Aggregate counts of logical resources like Clusters, Projects, Namespaces, and Pods.
+  - Counts of what driver was used to deploy clusters and nodes (e.g. GKE vs EC2 vs Imported vs Custom).
+  - Versions of Kubernetes components, Operating Systems and Docker that are deployed on nodes.
+  - Whether some optional components are enabled or not (e.g. which auth providers are used).
+  - The image name & version of Rancher that is running.
+  - A unique randomly-generated identifier for this installation.
+
+### Can I see the information that is being sent?
+
+If Telemetry is enabled, you can go to `https://<your rancher server>/v1-telemetry` in your installation to see the current data.
+
+If Telemetry is not enabled, the process that collects the data is not running, so there is nothing being collected to look at.
+
+### How do I turn it on or off?
+
+After initial setup, an admin user can go to the `Settings` page in the `Global` section of the UI and click Edit to change the `telemetry-opt` setting to either `in` or `out`.
@@ -0,0 +1,32 @@
+---
+title: Adding custom CA root certificates
+weight: 365
+---
+Services that Rancher needs to access are sometimes configured with a certificate from an custom/internal Certificate Authority (CA) root, also known as self signed certificate. If the presented certificate from the service cannot be validated by Rancher, the following error will appear: `x509: certificate signed by unknown authority`.
+
+To validate the certificate, the CA root certificates need to be added to Rancher. As Rancher is written in Go, we can use the environment variable `SSL_CERT_DIR` to point to the directory where the CA root certificates are located in the container. The CA root certificates directory can be mounted using the Docker volume option (`-v host-source-directory:container-destination-directory`) when starting the Rancher container.
+
+Examples of services that Rancher can access:
+
+* Catalogs
+* Authentication providers
+* Accessing hosting/cloud API when using Node Drivers
+
+## Start Rancher Container with custom CA root certificates
+
+The requirements are:
+
+* Mount the host directory containing the CA root certificates in the container using the volume option.
+* Add the environment variable `SSL_CERT_DIR` with as value the mounted CA root certificates directory location inside the container.
+
+Passing environment variables to the Rancher container can be done using `-e KEY=VALUE` or `--env KEY=VALUE`, mounting a host directory inside the container can be done using `-v host-source-directory:container-destination-directory` or `--volume host-source-directory:container-destination-directory`.
+
+The example below is based on having the CA root certificates in the `/host/certs` directory on the host and mounting this directory on `/container/certs` inside the Rancher container.
+
+```
+docker run -d --restart=unless-stopped \
+  -p 80:80 -p 443:443 \
+  -v /host/certs:/container/certs \
+  -e SSL_CERT_DIR="/container/certs" \
+  rancher/rancher:latest
+```
@@ -31,7 +31,7 @@ Installation of Rancher in a high-availability configuration involves multiple p

 	[RKE](https://github.com/rancher/rke/releases) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts.

-5. [Download RKE Config File Template](#5-download-config-file-template)
+5. [Download RKE Config File Template](#5-download-rke-config-file-template)

 	RKE uses a YAML config file to install and configure your Kubernetes cluster. Download one of our RKE config file templates to get started.

@@ -238,7 +238,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec

 1. Open `rancher-cluster.yml` in your favorite text editor.

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

    For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`.

@@ -329,9 +329,9 @@ Choose from the following options:
 ### Option B—Bring Your Own Certificate: Signed by Recognized CA

 >**Note:**
-> If you are using Self Signed Certificate, [click here](#option-a-self-signed-certificate) to proceed.
+> If you are using Self Signed Certificate, [click here](#option-a-bring-your-own-certificate-self-signed) to proceed.

-If you are using a Certificate Signed By A Recognized Certificate Authority, you will need to generate a base64 encoded string for the Certificate file and the Certificate Key file. Make sure that your certificate file includes all the [intermediate certificates](#ssl-faq-troubleshooting) in the chain, the order of certificates in this case is first your own certificate, followed by the intermediates. Please refer to the documentation of your CSP (Certificate Service Provider) to see what intermediate certificate(s) need to be included.
+If you are using a Certificate Signed By A Recognized Certificate Authority, you will need to generate a base64 encoded string for the Certificate file and the Certificate Key file. Make sure that your certificate file includes all the [intermediate certificates](#cert-order) in the chain, the order of certificates in this case is first your own certificate, followed by the intermediates. Please refer to the documentation of your CSP (Certificate Service Provider) to see what intermediate certificate(s) need to be included.

 In the `kind: Secret` with `name: cattle-keys-ingress`:

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

 You have a couple of options:

- 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/).
+- 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-and-restoration/ha-backup-and-restoration).
+- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).

 <br/>

@@ -31,7 +31,7 @@ Installation of Rancher in a high-availability configuration involves multiple p

 	[RKE](https://github.com/rancher/rke/releases) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts.

-5. [Download RKE Config File Template](#5-download-config-file-template)
+5. [Download RKE Config File Template](#5-download-rke-config-file-template)

 	RKE uses a YAML config file to install and configure your Kubernetes cluster. Download one of our RKE config file templates to get started.

@@ -147,7 +147,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 RKE Config File Template](#5-download-rke-config-file-template).

    ```
    # MacOS
@@ -187,7 +187,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec

 1. Open `rancher-cluster.yml` in your favorite text editor.

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

    For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`.

@@ -260,7 +260,7 @@ If you are using a Certificate Signed By A Recognized Certificate Authority, you

 ## 8. Configure FQDN

-There is one reference to `<FQDN>` in the RKE config file. Replace this reference with the FQDN you chose in in [3. Configure DNS](#part-3-configure-dns).
+There is one reference to `<FQDN>` in the RKE config file. Replace this reference with the FQDN you chose in in [3. Configure DNS](#3-configure-dns).

 1. Open `rancher-cluster.yml`.

@@ -13,3 +13,4 @@ The following diagram displays the basic port requirements for Rancher. If you n

 {{< requirements_ports_rancher >}}
 {{< requirements_ports_rke >}}
+{{< ports_aws_securitygroup_nodedriver >}}
@@ -0,0 +1,12 @@
+---
+title: Removing Rancher
+weight: 375
+---
+
+This section contains instructions on how to remove Rancher or nodes added to clusters.
+
+Choose from the following options:
+
+- [Cleaning cluster nodes]({{< baseurl >}}/rancher/v2.x/en/installation/removing-rancher/cleaning-cluster-nodes)
+
+	In this section, you can find steps to clean nodes that have been added to clusters created in Rancher.
@@ -0,0 +1,186 @@
+---
+title: Cleaning cluster nodes
+weight: 375
+---
+When adding a node to a cluster, resources (containers/(virtual) network interfaces) and configuration items (certificates/configuration files) are created. When removing a node from a cluster (if it is in `Active` state), those resources will be automatically cleaned and the only action needed is to restart the node. When a node has become unreachable and the automatic cleanup process cannot be used, we describe the steps that need to be executed before the node can be added to a cluster again.
+
+## Removing a node from a cluster via Rancher UI
+
+When the node is in `Active` state, removing the node from a cluster will trigger a process to clean up the node. Please restart the node after the automatic cleanup process is done to make sure any non-persistent data is properly removed.
+
+* How to restart a node
+
+```
+# using reboot
+reboot
+
+# using shutdown
+shutdown -r now
+```
+
+## Cleaning a node manually
+
+When a node is unreachable and removed from the cluster, the automatic cleaning process can't be triggered because the node is unreachable. Please follow the steps below to manually clean the node.
+
+>**Warning:** The commands listed below will remove data from the node. Make sure you have created a backup of files you want to keep before executing any of the commands as data will be lost.
+
+### Docker containers, images and volumes
+
+Based on what role you assigned to the node, Kubernetes components in containers, containers belonging to overlay networking, DNS, ingress controller and Rancher agent. (and pods you created that have been scheduled to this node)
+
+* How to clean all Docker containers, images and volumes:
+
+```
+docker rm -f $(docker ps -qa)
+docker rmi -f $(docker images -q)
+docker volume rm $(docker volume ls -q)
+```
+
+### Mounts
+
+Kubernetes components and secrets leave behind mounts on the system that need to be unmounted.
+
+Mounts |
+--------|
+`/var/lib/kubelet/pods/XXX` (miscellaneous mounts)  |
+`/var/lib/kubelet` |
+`/var/lib/rancher` |
+
+* How to unmount all mounts:
+
+```
+for mount in $(mount | grep tmpfs | grep '/var/lib/kubelet' | awk '{ print $3 }') /var/lib/kubelet /var/lib/rancher; do umount $mount; done
+```
+
+### Directories and files
+
+The following directories are used when adding a node to a cluster, and should be removed. You can remove a directory using `rm -rf /directory_name`.
+
+>**Note:** Depending on the role you assigned to the node, some of the directories will or won't be present on the node.
+
+Directories |
+--------|
+`/etc/ceph` |
+`/etc/cni` |
+`/etc/kubernetes` |
+`/opt/cni` |
+`/opt/rke` |
+`/run/secrets/kubernetes.io` |
+`/run/calico` |
+`/run/flannel` |
+`/var/lib/calico` |
+`/var/lib/etcd` |
+`/var/lib/cni` |
+`/var/lib/kubelet` |
+`/var/lib/rancher` |
+`/var/log/containers` |
+`/var/log/pods` |
+`/var/run/calico` |
+
+* How to clean the directories:
+
+```
+rm -rf /etc/ceph \
+       /etc/cni \
+       /etc/kubernetes \
+       /opt/cni \
+       /opt/rke \
+       /run/secrets/kubernetes.io \
+       /run/calico \
+       /run/flannel \
+       /var/lib/calico \
+       /var/lib/etcd \
+       /var/lib/cni \
+       /var/lib/kubelet \
+       /var/lib/rancher \
+       /var/log/containers \
+       /var/log/pods \
+       /var/run/calico
+```
+
+### Network interfaces and iptables
+
+The remaining two components that are changed/configured are (virtual) network interfaces and iptables rules. Both are non-persistent to the node, meaning that they will be cleared after a restart of the node. 
+
+This is the recommended method. 
+
+* How to restart a node
+
+```
+# using reboot
+reboot
+
+# using shutdown
+shutdown -r now
+```
+
+If you want to know more on (virtual) network interfaces or iptables rules, please see the specific subjects below.
+
+### Network interfaces
+
+>**Note:** Depending on the network provider configured for the cluster the node was part of, some of the interfaces will or won't be present on the node.
+
+Interfaces |
+--------|
+`flannel.1` |
+`cni0` |
+`tunl0` |
+`caliXXXXXXXXXXX` (random interface names)  |
+`vethXXXXXXXX` (random interface names)  |
+
+* How to list all interfaces:
+
+```
+# Using ip
+ip address show
+
+# Using ifconfig
+ifconfig -a
+```
+
+* How to remove an interface:
+
+```
+ip link delete interface_name
+```
+
+### Iptables
+
+>**Note:** Depending on the network provider configured for the cluster the node was part of, some of the chains will or won't be present on the node.
+
+Iptables rules are used to route traffic from and to containers. The created rules are not persistent, so restarting the node will restore iptables to it's original state.
+
+Chains |
+--------|
+`cali-failsafe-in` |
+`cali-failsafe-out` |
+`cali-fip-dnat` |
+`cali-fip-snat` |
+`cali-from-hep-forward` |
+`cali-from-host-endpoint` |
+`cali-from-wl-dispatch` |
+`cali-fw-caliXXXXXXXXXXX` (random chain names) |
+`cali-nat-outgoing` |
+`cali-pri-kns.NAMESPACE` (chain per namespace) |
+`cali-pro-kns.NAMESPACE` (chain per namespace) |
+`cali-to-hep-forward` |
+`cali-to-host-endpoint` |
+`cali-to-wl-dispatch` |
+`cali-tw-caliXXXXXXXXXXX` (random chain names) |
+`cali-wl-to-host` |
+`KUBE-EXTERNAL-SERVICES` |
+`KUBE-FIREWALL` |
+`KUBE-MARK-DROP` |
+`KUBE-MARK-MASQ` |
+`KUBE-NODEPORTS` |
+`KUBE-SEP-XXXXXXXXXXXXXXXX` (random chain names) |
+`KUBE-SERVICES` |
+`KUBE-SVC-XXXXXXXXXXXXXXXX` (random chain names) |
+
+* How to list all iptables rules
+
+```
+iptables -L -t nat
+iptables -L -t mangle
+iptables -L
+```
@@ -112,6 +112,7 @@ If you're publishing your app publicly, you should ideally be using a certificat
 >
 >- The certificate files must be in [PEM format](#pem).
 >- Make sure that the container includes your certificate file and the key file. Because your certificate is signed by a recognized CA, mounting an additional CA certificate file is unnecessary.
+>- Add `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher.

 **To Install Rancher Using a Certificate Signed by a Recognized CA:**

@@ -122,17 +123,9 @@ If you're publishing your app publicly, you should ideally be using a certificat
 	  -p 80:80 -p 443:443 \
 	  -v /etc/your_certificate_directory/fullchain.pem:/etc/rancher/ssl/cert.pem \
 	  -v /etc/your_certificate_directory/privkey.pem:/etc/rancher/ssl/key.pem \
-	  rancher/rancher:latest
+	  rancher/rancher:latest --no-cacerts
 	```

-By default, Rancher automatically generates self-signed certificates for itself after installation. However, since you've provided your own certificates, you must disable the certificates that Rancher generated for itself.
-
-**To Remove the Default Certificates:**
-
-1. Log into Rancher.
-2. Select  **Settings** > **cacerts**.
-3. Choose `Edit` and remove the contents. Then click `Save`.
-
 ### 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.
@@ -165,7 +158,7 @@ Run the following commands from your Linux host.
 You have a couple of options:

 - Create a backup of your Rancher Server in case of a disaster scenario: [Single Node Backup and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/single-node-backup-and-restoration/).
- Create a Kubernetes cluster: [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).
+- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).

 <br/>

@@ -1,32 +1,83 @@
 ---
-title: Rancher HTTP Proxy Configuration
+title: HTTP Proxy Configuration
 weight: 360
 aliases:
 - /rancher/v2.x/en/installation/proxy-configuration/
 ---
-If you operate Rancher behind a proxy and you need to reach the Internet to perform tasks (such as using Helm catalogs), you must provide Rancher information about your proxy.
+If you operate Rancher behind a proxy and you want to access services through the proxy (such as retrieving catalogs), you must provide Rancher information about your proxy. As Rancher is written in Go, it uses the common proxy environment variables as shown below.

-### Setting the `http_proxy` Environment Variable 
+Make sure `NO_PROXY` contains the network addresses, network address ranges and domains that should be excluded from using the proxy.

-#### Ubuntu
+Environment variable      | Purpose
+--------------------------|---------
+HTTP_PROXY                | Proxy address to use when initiating HTTP connection(s)
+HTTPS_PROXY               | Proxy address to use when initiating HTTPS connection(s)
+NO_PROXY                  | Network address(es), network address range(s) and domains to exclude from using the proxy when initiating connection(s)

-1. Check if `http_proxy` is still defined:
+> **Note** NO_PROXY must be in uppercase to use network range (CIDR) notation.

-    ```
-echo $http_proxy
-    ```
+## Single Node Installation

-    If it is empty, set the variable and store it in your account's environment using the following command:
+Passing environment variables to the Rancher container can be done using `-e KEY=VALUE` or `--env KEY=VALUE`. Required values for `NO_PROXY` in a [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install/) are:

-    ```
-echo "export http_proxy=http://<username>:<password>@<proxy url>:<proxy port>/" >> .profile
-    ```
-2. Logout and then log back in to activate your changes.
+* `localhost`
+* `127.0.0.1`
+* `0.0.0.0`

-### Start Rancher Container with Proxy Information 
-
-Ensure that your `http_proxy` environment variable is visible inside of Rancher's Docker container:
+The example below is based on a proxy server accessible at `http://192.168.0.1:3128`, and excluding usage the proxy when accessing network range `192.168.10.0/24` and every hostname under the domain `example.com`.

 ```
-sudo docker run -d --restart=unless-stopped --volumes-from rancher-data -p 80:80 -p 443:443 -e HTTP_PROXY=$http_proxy -e HTTPS_PROXY=$http_proxy -e http_proxy=$http_proxy -e https_proxy=$http_proxy -e NO_PROXY="localhost,127.0.0.1" -e no_proxy="localhost,127.0.0.1" rancher/rancher
+docker run -d --restart=unless-stopped \
+  -p 80:80 -p 443:443 \
+  -e HTTP_PROXY="http://192.168.10.1:3128" \
+  -e HTTPS_PROXY="http://192.168.10.1:3128" \
+  -e NO_PROXY="localhost,127.0.0.1,0.0.0.0,192.168.10.0/24,example.com" \
+  rancher/rancher:latest
+```
+
+## High Availability Installation
+
+When using High Availability Installation, the environment variables need to be added to the RKE Config File template.
+
+* [High Availability Installation with External Load Balancer (TCP/Layer 4) RKE Config File Template]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install/#5-download-rke-config-file-template)
+* [High Availability Installation with External Load Balancer (HTTPS/Layer 7) RKE Config File Template]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install-external-lb/#5-download-rke-config-file-template)
+
+The environment variables should be defined in the `Deployment` inside the RKE Config File Template. You only have to add the the part starting with `env:` to (but not including) `ports:`. Make sure the indentation is identical to the preceding `name:`. Required values for `NO_PROXY` are:
+
+* `localhost`
+* `127.0.0.1`
+* `0.0.0.0`
+* Configured `service_cluster_ip_range` (default: `10.43.0.0/16`)
+
+The example below is based on a proxy server accessible at `http://192.168.0.1:3128`, and excluding usage of the proxy when accessing network range `192.168.10.0/24`, the configured `service_cluster_ip_range` (`10.43.0.0/16`) and every hostname under the domain `example.com`. If you have changed the `service_cluster_ip_range`, you have to update the value below accordingly.
+
+```yaml
+...
+---
+  kind: Deployment
+  apiVersion: extensions/v1beta1
+  metadata:
+    namespace: cattle-system
+    name: cattle
+  spec:
+    replicas: 1
+    template:
+      metadata:
+        labels:
+          app: cattle
+      spec:
+        serviceAccountName: cattle-admin
+        containers:
+        - image: rancher/rancher:latest
+          imagePullPolicy: Always
+          name: cattle-server
+          env:
+          - name: HTTP_PROXY
+            value: "http://192.168.10.1:3128"
+          - name: HTTPS_PROXY
+            value: "http://192.168.10.1:3128"
+          - name: NO_PROXY
+            value: "localhost,127.0.0.1,0.0.0.0,10.43.0.0/16,192.168.10.0/24,example.com"
+          ports:
+...
 ```
@@ -77,7 +77,7 @@ If you elect to use a self-signed certificate to encrypt communication, you must
 >**Prerequisites:**
 >Create a self-signed certificate.
 >
->- The certificate files must be in [PEM format](#ssl-faq-troubleshooting).
+>- The certificate files must be in [PEM format](#pem).

 **To Install Rancher Using a Self-Signed Cert:**

@@ -177,8 +177,8 @@ server {
 ## What's Next?
 You have a couple of options:

- Create a backup of your Rancher Server in case of a disaster scenario: [Single Node Backup and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups/single-node-backups/).
- Create a Kubernetes cluster: [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).
+- Create a backup of your Rancher Server in case of a disaster scenario: [Single Node Backup and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/single-node-backup-and-restoration/).
+- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).

 <br/>

@@ -0,0 +1,143 @@
+---
+title: Kubernetes in Rancher
+weight: 3000
+aliases:
+  - /rancher/v2.x/en/concepts/
+  - /rancher/v2.x/en/tasks/
+  - /rancher/v2.x/en/concepts/resources/
+---
+
+After you provision a cluster in Rancher, you can begin using powerful Kubernetes features to deploy and scale your containerized applications in development, testing, or production environments.
+
+## Interacting with Clusters
+
+- **Rancher UI**
+
+    Rancher provides an intuitive user interface for interacting with your clusters. All options available in the UI use the Rancher API. Therefore any action possible in the UI is also possible in the Rancher CLI or Rancher API.
+
+- **kubectl**
+
+    You can use the Kubernetes command-line tool, [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), to manage   your clusters. You have two options for using kubectl:
+
+    - **Rancher kubectl shell**
+
+        Interact with your clusters by launching a kubectl shell available in the Rancher UI. This option requires no configuration actions on your part.
+
+        For more information, see [Accessing Clusters with kubectl Shell]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubectl/#accessing-clusters-with-kubectl-shell).
+
+    - **Terminal remote connection**
+
+        You can also interact with your clusters by installing [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on your local desktop and then copying the cluster's kubeconfig file to your local `~/.kube/config` directory.
+
+        For more information, see [Accessing Clusters with kubectl and a kubeconfig File]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubectl/#accessing-clusters-with-kubectl-and-a-kubeconfig-file).
+
+- **Rancher CLI**
+
+    You can control your clusters by downloading Rancher's own command-line interface, [Rancher CLI]({{< baseurl >}}/rancher/v2.x/en/cli/). This CLI tool can interact directly with different clusters and projects or pass them `kubectl` commands.
+
+- **Rancher API**
+
+    Finally, you can interact with your clusters over the Rancher API. Before you use the API, you must obtain an [API key]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/). To view the different resource fields and actions for an API object, open the API UI, which can be accessed by clicking on **View in API** for any Rancher UI object.
+
+## Editing Clusters
+
+After you launch a cluster, you can edit many of its settings configured during its initial launch. All clusters allow you to edit the cluster membership, which is a pool of users that can access the cluster, along with their roles within the cluster. For more information, see [members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#membership-and-role-assignment) and [roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles).
+
+Depending on how you provisioned your clusters, different settings are available for editing their size and options.
+
+- For clusters provisioned in a [hosted kubernetes provider]({{< baseurl>}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/), you can edit the options chosen during cluster provisioning. These options are dependent on your hosted Kubernetes provider.
+
+- For [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) clusters, you can edit the following options.
+
+    - [Kubernetes options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/), including:
+
+       - The version of Kubernetes installed.
+       - Whether the cluster allows unsupported versions of Docker to run.
+       - Whether the cluster uses a cloud provider.
+       - Whether the cluster applies a pod security policy.
+
+       >**Note:** You cannot edit the cluster's network provider after its initial launch.
+
+   - **[Node pool]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) or [custom node]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/) clusters only:** the scale and [roles of your nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components).
+
+       - For node pools, you can add/remove/edit cluster node pools. Node pools are set to a specific scale, so removing nodes individually does not change the size of the cluster unless you change the scale of the pool.
+       - For custom nodes, you are provided the Docker command to add nodes, but the command can also be used to edit the roles of existing nodes. To remove nodes, browse to the cluster's **Nodes** page and delete the unnecessary nodes.
+
+To view the settings available for your cluster, see [Editing Clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters).
+
+## Projects and Namespaces
+
+To support multi-tenancy on a cluster, create different [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/). Projects allow you to group several [namespaces]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) into a single object. You can set user access and pod security policies for each project, which allows groups of users to access different sets of namespaces while using the same cluster. Projects are a feature available in Rancher, but not the base version of Kubernetes.
+
+For more information on how to manage projects, see:
+
+- [Projects and Namespaces]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/)
+- [Project Members]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members/)
+
+## Workloads
+
+Deploy applications to your cluster nodes using [workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/), which are objects that contain pods that run your apps, along with metadata that set rules for the deployment's behavior. Workloads can be deployed within the scope of the entire clusters or within a namespace.
+
+When deploying a workload, you can deploy from any image. There are a variety of [workload types]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/#workload-types) to choose from which determine how your application should run.
+
+Following a workload deployment, you can continue working with it. You can:
+
+- [Upgrade]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads) the workload to a newer version of the application it's running.
+- [Roll back]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads) a workload to a previous version, if an issue occurs during upgrade.
+- [Add a sidecar]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/add-a-sidecar), which is a workload that supports a primary workload.
+
+## Load Balancing and Ingress
+
+### Load Balancers
+
+After you launch an application, it's only available within the cluster. It can't be reached externally.
+
+If you want your applications to be externally accessible, you must add a load balancer to your cluster. Load balancers create a gateway for external connections to access your cluster, provided that the user knows the load balancer's IP address and the application's port number.
+
+Rancher supports two types of load balancers:
+
+- [Layer-4 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#layer-4-load-balancer)
+- [Layer-7 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#layer-7-load-balancer)
+
+For more information, see [load balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers).
+
+#### Ingress
+
+Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. You can get around this issue by using an ingress.
+
+Ingress is a set or rules that act as a load balancer. Ingress works in conjunction with one or more ingress controllers to dynamically route service requests. When the ingress receives a request, the ingress controller(s) in your cluster program the load balancer to direct the request to the correct service based on service subdomains or path rules that you've configured.
+
+For more information, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress).
+
+## Service Discovery
+
+After you expose your cluster to external requests using a load balancer and/or ingress, it's only available by IP address. To create a resolveable hostname, you must create a service record, which is a record that maps an IP address, external hostname, DNS record alias, workload(s), or labled pods to a specific hostname.
+
+For more information, see [Service Discovery]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/service-discovery).
+
+## Volumes and Storage
+
+For workloads that need to retain their state, you must add external storage for the workload. Storage volumes are locations outside of your pods where applications can store their data. Because the storage is external to the workload, if a container fails, the container that replaces it can restore the external data, making recovery appear seamless.
+
+Within Rancher, you can create persistent storage using one of two methods:
+
+- [Persistent Volumes]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#persistent-volumes)
+
+    Persistent volumes are pre-provisioned storage volumes that you can bind to pods later using persistent volume claims.
+
+- [Storage Classes]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#storage-classes)
+
+    Storage classes are objects that provision storage volumes upon request. When a pod submits a persistent volume claim to the storage class, the class creates a storage volume for the pod.
+
+After you deploy a workload, it requests storage using a [persistent volume claim]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims), which is like a voucher used to claim storage space available within the cluster.
+
+## Kubernetes Resources
+
+Within the context of a Rancher project or namespace, _resources_ are files and data that support operation of your pods. Within Rancher, certificates, registries, and secrets are all considered resources. However, Kubernetes classifies resources as different types of [secrets](https://kubernetes.io/docs/concepts/configuration/secret/). Therefore, within a single project or namespace, individual resources must have unique names to avoid conflicts. Although resources are primarily used to carry sensitive information, they have other uses as well.
+
+Resources include:
+
+- [Certificates]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/): Files used to encrypt/decrypt data entering or leaving the cluster.
+- [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/configmaps/): Files that store general configuration information, such as a group of config files.
+- [Secrets]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/secrets/): Files that store sensitive data like passwords, tokens, or keys.
+- [Registries]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/registries/): Files that carry credentials used to authenticate with private registries.
@@ -41,4 +41,4 @@ Add SSL certificates to either projects, namespaces, or both. A project scoped c

 ## What's Next?

-Now you can add the certificate when launching an ingress within the current project or namespace. For more information, see [Adding Ingress]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/ingress/).
+Now you can add the certificate when launching an ingress within the current project or namespace. For more information, see [Adding Ingress]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/).
@@ -30,7 +30,7 @@ ConfigMaps store general configuration information for an application, such as c

 1. Click **Save**.

-	>**Note:** Don't use ConfigMaps to store sensitive data [use a secret]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/secrets/).
+	>**Note:** Don't use ConfigMaps to store sensitive data [use a secret]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/secrets/).
 	>
 	>**Tip:** You can add multiple key value pairs to the ConfigMap by copying and pasting.
 	>
@@ -45,4 +45,4 @@ Now that you have a ConfigMap added to a namespace, you can add it to a workload
 - 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/kubernetes-in-rancher/workloads/deploy-workloads/).
+For more information on adding ConfigMaps to a workload, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).
@@ -7,6 +7,13 @@ weight: 3015

 Following cluster creation, you can add users as cluster members so that they can access its resources.

+>**Ping and MS FS Caveats:**
+>
+>- IdP does not support search or lookup. When adding users to clusters, the exact IDs must be entered correctly.
+>- When adding users to a cluster, group IDs are not supported unless the admin who turned on access control is a member of the group.
+>- When adding a group that includes an admin to clusters, add it from the drop-down rather than the search bar. If you add the group using the search bar, the group will not get added.
+
+
 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**.
@@ -13,7 +13,7 @@ When you create a cluster using the Rancher GUI, Rancher automatically creates a

 This kubeconfig file and its contents are specific to the cluster you are viewing. You will need a separate kubeconfig file for each cluster that you have access to in Rancher.

-For more information, see [Using kubectl to Access a Cluster]({{< baseurl >}}/rancher/v2.x/en//kubernetes-in-rancher/kubectl).
+For more information, see [Using kubectl to Access a Cluster]({{< baseurl >}}/rancher/v2.x/en//k8s-in-rancher/kubectl).

 >**Note:** By default, kubectl checks `~/.kube/config` for kubeconfig files, but you can use any directory you want using the `--kubeconfig` flag. For example:
 >```
@@ -7,7 +7,7 @@ aliases:
 You can access and manage your Kubernetes clusters using kubectl in two ways:

 - [Accessing Clusters with kubectl Shell](#accessing-clusters-with-kubectl-shell)
- [Accessing Clusters with kubectl CLI and a kubeconfig File]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/kubeconfig/)
+- [Accessing Clusters with kubectl CLI and a kubeconfig File]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubeconfig/)

 ## Accessing Clusters with kubectl Shell

@@ -0,0 +1,45 @@
+---
+title: Load Balancing and Ingresses
+weight: 3040
+---
+
+Within Rancher, you can setup load balancers and ingress controllers to redirect service requests.
+
+## Load Balancers
+
+After you launch an application, the app is only available within the cluster. It can't be reached from outside the cluster.
+
+If you want your applications to be externally accessible, you must add a load balancer to your cluster. Load balancers create a gateway for external connections to access your cluster, provided that the user knows the load balancer's IP address and the application's port number.
+
+Rancher supports two types of load balancers:
+
+- [Layer-4 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#layer-4-load-balancer)
+- [Layer-7 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#layer-7-load-balancer)
+
+For more information, see [load balancers]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers).
+
+### Load Balancer Limitations
+
+Load Balancers have a couple of limitations you should be aware of:
+
+- Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive.
+
+- If you want to use a load balancer with a Hosted Kubernetes cluster (i.e., clusters hosted in GKE, EKS, or AKS), you must host your load balancer with the same cloud provider. Please review the compatibility tables regarding support for load balancers based on how you've provisioned your clusters:
+
+
+    - [Support for Layer-4 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#support-for-layer-4-load-balancing)
+
+    - [Support for Layer-7 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#support-for-layer-7-load-balancing)
+
+## Ingress
+
+As mentioned in the limitations above, using a load balancer per service can be expensive. You can get around this issue using an ingress.
+
+Ingress is a set or rules that act as a load balancer. Ingress works in conjunction with one or more ingress controllers to dynamically route service requests. When the ingress receives a request, the ingress controller(s) in your cluster program the load balancer to direct the request to the correct service based on service subdomains or path rules that you've configured.
+
+Your load balancer can either reside within your cluster or externally. Ingress and ingress controllers residing in RKE-launcher clusters are powered by [Nginx](https://www.nginx.com/).
+
+Ingress can provide other functionality as well, such as SSL termination, name-based virtual hosting, and more.
+
+- For more information on how to setup ingress in Rancher, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress).
+- For complete information about ingress and ingress controllers, see the [Kubernetes Ingress Documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/)
@@ -64,7 +64,7 @@ Ingress can be added for workloads to provide load balancing, SSL termination an

 1. If any of your ingress rules handle requests for encrypted ports, add a certificate to encrpyt/decrypt communications.

-    >**Note:** You must have an SSL certificate that the ingress can use to encrypt/decrypt communications. For more information see [Adding SSL Certificates]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/certificates/).
+    >**Note:** You must have an SSL certificate that the ingress can use to encrypt/decrypt communications. For more information see [Adding SSL Certificates]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/).

    1. Click **Add Certificate**.

@@ -10,7 +10,7 @@ Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer

 Layer-4 load balancer (or the external load balancer) forwards traffic to Nodeports. Layer-4 load balancer allows you to forward both HTTP and TCP traffic. Layer-4 load balancer is supported by the underlying cloud provider. As a result, when you deploy RKE clusters on bare metal servers and vSphere clusters, layer-4 load balancer is not supported.

-### Cloud Support for Layer-4 Load Balancing
+### Support for Layer-4 Load Balancing

 Support for layer-4 load balancer varies based on the underlying cloud provider.

@@ -28,7 +28,7 @@ RKE on Custom Hosts<br/>(e.g. bare-metal servers) | Not Supported

 Layer-7 load balancer (or the ingress controller) supports host and path-based load balancing and SSL termination. Layer-7 load balancer only forwards HTTP and HTTPS traffic and therefore they listen on ports 80 and 443 only. Cloud providers such as Amazon and Google support layer-7 load balancer. In addition, RKE clusters deploys the Nginx Ingress Controller.

-### Cloud Support for Layer-7 Load Balancing
+### Support for Layer-7 Load Balancing

 Support for layer-7 load balancer varies based on the underlying cloud provider.

@@ -55,8 +55,6 @@ The benefit of using xip.io is that you obtain a working entrypoint URL immediat

 ## Related Links

-### External Load Balancers
-
 #### External Links

 - [Create an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)
@@ -67,6 +65,4 @@ The benefit of using xip.io is that you obtain a working entrypoint URL immediat
 - [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)
@@ -0,0 +1,72 @@
+---
+title: Nodes
+weight:
+aliases:
+---
+
+After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab. Depending on the [option used]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#cluster-creation-in-rancher) to provision the cluster, there are different node options available.
+
+>**Note:** If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters).
+
+To manage individual nodes, browse to the cluster that you want to manage and then select **Nodes** from the main menu. The following sections list what node management options are available for each cluster type.
+
+<!-- TOC -->
+
+- [Nodes Provisioned by Node Pool](#nodes-provisioned-by-node-pool)
+- [Nodes Provisioned with the Custom Nodes Option](#nodes-provisioned-with-the-custom-nodes-option)
+- [Nodes Provisioned by Hosted Kubernetes Providers](#nodes-provisioned-by-hosted-kubernetes-providers)
+- [Imported Nodes](#imported-nodes)
+
+<!-- /TOC -->
+
+
+## Nodes Provisioned by Node Pool
+ 
+Clusters provisioned using [one of the node pool options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) automatically maintain the node scale that's set during the initial cluster provisioning. This scale determines the number of active nodes that Rancher maintains for the cluster. 
+
+- Mark nodes as unschedulable (i.e., **Cordon**). When a node is cordoned, no new pods are scheduled for the node, but the existing pods continue to run.
+- Delete defective nodes from the cloud provider. When you the delete a defective node, Rancher automatically replaces it with an identically provisioned node.
+    
+    >**Note:** If you want to scale down the number of nodes, use the scaling controls rather than deleting the node.
+- Scale the number of nodes in the cluster up or down.
+- Enter a **Custom Name**, **Description**, or **Label** for a node.
+- Download the SSH key pair for a node. You can use this key pair to remote into the node using an SSH connection from your workstation. For more instructions on how to remote into the node, see [Remoting into a Node Pool Node](#remoting-into-a-node-pool-node).
+- View API Data.
+
+### Remoting into a Node Pool Node
+
+1. From the Node Pool cluster, select **Nodes** from the main menu.
+1. Find the node that you want to remote into. Select **Ellipsis (...) > Download Keys**.
+
+    **Step Result:** A ZIP file containing files used for SSH is downloaded.
+
+1. Extract the ZIP file to any location.
+1. Open Terminal. Change your location to the extracted ZIP file.
+1. Enter the following command:
+
+    ```
+    ssh -i id_rsa root@<IP_OF_HOST>
+    ```
+
+## Nodes Provisioned with the Custom Nodes Option
+
+For nodes provisioned using the [custom nodes option]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#custom-nodes), you can use the following options from the Rancher UI:
+
+- Mark nodes as unschedulable (i.e., **Cordon**). When a node is cordoned, no new pods are scheduled for the node, but the existing pods continue to run.
+- Delete node objects from the **Nodes** ist. When you the delete a custom node, you still have to delete it from the node itself.
+- Enter a **Custom Name**, **Description**, or **Label** for a node.
+- View API Data.
+ 
+## Nodes Provisioned by Hosted Kubernetes Providers
+
+Options for managing nodes [hosted by a Kubernetes provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) are somewhat limited in Rancher. Rather than using the Rancher UI to make edits such as scaling the number of nodes up or down, edit the cluster directly.
+
+From the Rancher UI, you can:
+
+- Mark nodes as unschedulable (i.e., **Cordon**). When a node is cordoned, no new pods are scheduled for the node, but the existing pods continue to run.
+- Enter a **Custom Name**, **Description**, or **Label** for a node.
+- View node API Data.
+
+## Imported Nodes
+
+Although you can deploy workloads to an [imported cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/) using Rancher, you cannot manage individual cluster nodes. All management of imported cluster nodes must take place outside of Rancher.
@@ -7,7 +7,46 @@ aliases:
  - /rancher/v2.x/en/tasks/projects/create-project/
 ---

-_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/default-custom-roles/). 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
+
+_Projects_ are objects that captures a set of policies for a set of namespaces. They are a new concept introduced by Rancher, and they are not a native Kubernetes construct.
+
+You can use projects to perform actions like:
+
+- Assigning users to access to a group of namespaces (i.e., [project membership]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members))
+- Assigning users specific roles in a project. A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/). Policies include Kubernetes Role-Based Access Control (RBAC) policies.
+- Assigning Pod Security Policies.
+
+When you create a cluster, two project are automatically created within it:
+
+- [Default Project](#default-project)
+- [System Project](#system-project) 
+
+### Default Project
+
+When you provision a cluster, it automatically creates a `default` project for the cluster. This is a project you can use to get started with your cluster, but you can always delete it and replace it with projects that have more descriptive names.
+
+### System Project
+
+_available as of v2.0.7_
+
+When troubleshooting, you can view the `system` project to check if important namespaces in the Kubernetes system are working properly. This easily accessible project saves you from troubleshooting individual system namespace containers.
+
+To open it, open the **Global** menu, and then select the `system` project for your cluster. 
+
+The `system` project:
+
+- Is automatically created when you provision a cluster.
+- Lists all namespaces that exist in `v3/settings/system-namespaces`, if they exist.
+- Allows you to add more namespaces or move its namespaces to other projects.
+- Cannot be deleted because it's required for cluster operations.
+
+>**Note:** In clusters where both:
+>
+> - The [Canal network plug-in]({{< baseurl >}}\rancher\v2.x\en\cluster-provisioning\rke-clusters\options\#canal) is in use.
+> - The Project Network Isolation option is enabled.
+>
+>The `system` project overrides the Project Network Isolation option so that it can communicate with other projects, collect logs, and check health. 

 ## Authorization

@@ -11,6 +11,12 @@ After projects are created, there are certain aspects that can be changed later.

 Following project creation, you can add users as project members so that they can access its resources.

+>**Ping and MS FS Caveats:**
+>
+>- IdP does not support search or lookup. When adding users to projects, the exact IDs must be entered correctly.
+>- When adding users to a project, group IDs are not supported unless the admin who turned on access control is a member of the group.
+>- When adding a group that includes an admin to projects, add it from the drop-down rather than the search bar. If you add the group using the search bar, the group will not get added.
+
 1. From the **Global** view, open the project that you want to add members to.

 2. From the main menu, select **Members**. Then click **Add Member**.
@@ -48,7 +54,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/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]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/editing-clusters/#adding-changing-a-pod-security-policy).
+> - 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]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/#adding-changing-a-pod-security-policy).

 1. From the **Global** view, find the cluster containing the project you want to apply a PSP to.

@@ -11,10 +11,10 @@ If you want to provide a user with access and permissions to _specific_ projects

 There are two contexts where you can add project members:

- [Adding Members when Creating New Projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/)
+- [Adding Members when Creating New Projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/)

    You can add members to a project as you create it (recommended if possible).

- [Adding Members to an Existing Project]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/editing-projects/)
+- [Adding Members to an Existing Project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/)

 	You can always add members to a project later.
@@ -35,4 +35,4 @@ Registries are secrets containing credentials used to authenticate with [private

 Now that you have a registry added to the project or namespace, you can add it to a workload that's deploying an image from your private registry.

-For more information on adding a registry to a workload, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/deploy-workloads/).
+For more information on adding a registry to a workload, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).
@@ -38,4 +38,4 @@ When creating a secret, you can make it available for any deployment within a pr

 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/kubernetes-in-rancher/workloads/deploy-workloads/).
+For more information on adding secret to a workload, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).
@@ -5,29 +5,28 @@ aliases:
  - /rancher/v2.x/en/concepts/volumes-and-storage/
  - /rancher/v2.x/en/tasks/clusters/adding-storage/
 ---
-There are two ways to create volumes on Kubernetes: Persistent Volumes (PVs) and Storage Classes.
+When deploying an application that needs to retain data, you'll need to create persistent storage. Persistent storage allows you to store application data external from the pod running your application. This storage practice allows you to maintain application data, even if the application's pod fails. 
+
+There are two ways to create persistent storage in Kubernetes: Persistent Volumes (PVs) and Storage Classes.

 ## 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 minimum 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 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)

-Rancher allows you to create PVs at cluster level and bind them to PVCs later. Volumes are managed on a per-project basis.
+Rancher allows you to create PVs at the cluster level and bind them to PVCs later. Volumes are managed on a per-project basis.

 ### Adding a Persistent Volume

->**Prerequisites:**
->
->- Working with storage requires the `Manage Volumes` [role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-role-reference).
->- You must have a storage medium provisioned. For more information, see [Provisioning Storage]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/examples/).
-
 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:**
+>**Prerequisites:**
 >
+>- Working with storage requires the `Manage Volumes` [role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-role-reference).
+>- You must have a storage medium provisioned. For more information, see [Provisioning Storage]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/).
 >- 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.

@@ -41,10 +40,10 @@ Persistent volumes can either be a disk or file system that you host on premise,

 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.
+    >**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:
+    >
+    >   - You must enable the `cloud provider` option for the EC2 cluster.
+    >   - You must use the `Amazon EBS Disk` volume plugin.

 1. Enter the **Capacity** of your volume in gigabytes.

@@ -80,8 +79,9 @@ Storage Classes allow you to create PVCs dynamically without having to create PV

 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:
+The `provisioner` determines which volume plugin is used to provision the persistent volumes.

+{{% accordion id="provisioners" label="Supported Storage Class Provisioners" %}}
 - Amazon EBS Disk
 - AzureFile
 - AzureDisk
@@ -95,6 +95,8 @@ The `provisioner` determines which volume plugin is used to provision the persis
 - ScaleIO Volume
 - StorageOS
 - Vmware vSphere Volume
+{{% /accordion %}}
+<br/>

 In addition to customizing each provisioner's options for the storage class, you can also define the volume `reclaimPolicy`. There are two options available:

@@ -117,11 +119,10 @@ _Storage Classes_ allow you to dynamically provision persistent volumes on deman

 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.
-
+    >**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:
+    >
+    >   - You must enable the `cloud provider` option for the EC2 cluster.
+    >   - 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.

@@ -133,11 +134,9 @@ Mount Persistent Volumes to workloads so that your applications can store their

 You can mount Persistent Volumes in one of two contexts:

- During deployment of a workload (recommended if possible). For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/deploy-workloads/).
- Following workload creation. For more information, see [Adding Persistent Volume Claims]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/persistent-volume-claims/).
+- During deployment of a workload (recommended if possible). For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).
+- Following workload creation. For more information, see [Adding Persistent Volume Claims]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/).

 ## Related Links

-### External Docs
-
- [Storage](https://kubernetes.io/docs/concepts/storage/)
+- [Kubernetes Documentation: Storage](https://kubernetes.io/docs/concepts/storage/)
@@ -9,4 +9,5 @@ Rancher supports persistent storage with a variety of volume plugins. However, b

 For your convenience, Rancher offers documentation on how to configure some of the popular storage methods:

- [NFS Share](nfs)
+- [NFS]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/nfs/)
+- [vSphere]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/)
@@ -9,7 +9,7 @@ Before you can use the NFS storage volume plug-in with Rancher deployments, you

 >**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/kubernetes-in-rancher/volumes-and-storage/).
+>- 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/k8s-in-rancher/volumes-and-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.

@@ -65,4 +65,4 @@ Before you can use the NFS storage volume plug-in with Rancher deployments, you

 ## What's Next?

-Within Rancher, add the NFS server as a [storage volume]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/#adding-a-persistent-volume) and/or [storage class]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/#adding-storage-classes). After adding the server, you can use it for storage for your deployments.
+Within Rancher, add the NFS server as a [storage volume]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#adding-a-persistent-volume) and/or [storage class]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#adding-storage-classes). After adding the server, you can use it for storage for your deployments.
@@ -0,0 +1,70 @@
+---
+title: vSphere Storage
+weight: 3055
+aliases:
+  - /rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/vsphere/
+---
+
+To provide stateful workloads with vSphere storage, we recommend creating a vSphereVolume [storage class]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#storage-classes). This practice dynamically provisions vSphere storage when workloads request volumes through a [persistent volume claim]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/).
+
+### Prerequisites
+
+In order to provision vSphere volumes in a cluster created with the [Rancher Kubernetes Engine (RKE)]({{< baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the [vSphere cloud provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere) must be explicitly enabled in the [cluster options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/).
+
+### Creating A Storage Class
+
+> **Note:**
+>
+> The following steps can also be performed using the `kubectl` command line tool. See [Kubernetes documentation on persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) for details.
+
+1. From the Global view, open the cluster where you want to provide vSphere storage.
+2. From the main menu, select **Storage > Storage Classes**. Then click **Add Class**.
+3. Enter a **Name** for the class. 
+4. Under **Provisioner**, select **VMWare vSphere Volume**.
+
+	![vsphere-storage-class]({{< baseurl >}}/img/rancher/vsphere-storage-class.png)
+
+5. Optionally, specify additional properties for this storage class under **Parameters**. Refer to the [vSphere storage documentation](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/storageclass.html) for details. 
+5. Click **Save**.
+
+### Creating a Workload with a vSphere Volume
+
+1. From the cluster where you configured vSphere storage, begin creating a workload as you would in [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).
+2. For **Workload Type**, select **Stateful set of 1 pod**.
+3. Expand the **Volumes** section and click **Add Volume**.
+4. Choose **Add a new persistent volume (claim)**. This option will implicitly create the claim once you deploy the workload.
+5. Assign a **Name** for the claim, ie. `test-volume` and select the vSphere storage class created in the previous step.
+6. Enter the required **Capacity** for the volume. Then click **Define**.
+
+    ![workload-add-volume]({{< baseurl >}}/img/rancher/workload-add-volume.png)
+
+7. Assign a path in the **Mount Point** field. This is the full path where the volume will be mounted in the container file system, e.g. `/persistent`.
+8. Click **Launch** to create the workload.
+
+### Verifing Persistence of the Volume
+
+1. From the context menu of the workload you just created, click **Execute Shell**.
+2. Note the directory at root where the volume has been mounted to (in this case `/persistent`).
+3. Create a file in the volume by executing the command `touch /<volumeMountPoint>/data.txt`.
+4. **Close** the shell window.
+5. Click on the name of the workload to reveal detail information.
+6. Open the context menu next to the Pod in the *Running* state.
+7. Delete the Pod by selecting **Delete**.  
+8. Observe that the pod is deleted. Then a new pod is scheduled to replace it so that the workload maintains its configured scale of a single stateful pod.
+9. Once the replacement pod is running, click **Execute Shell**.
+10. Inspect the contents of the directory where the volume is mounted by entering `ls -l /<volumeMountPoint>`. Note that the file you created earlier is still present.
+
+    ![workload-persistent-data]({{< baseurl >}}/img/rancher/workload-persistent-data.png)
+
+## Why to Use StatefulSets Instead of Deployments
+
+You should always use [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) for workloads consuming vSphere storage, as this resource type is designed to address a VMDK block storage caveat.
+
+Since vSphere volumes are backed by VMDK block storage, they only support an [access mode](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) of `ReadWriteOnce`. This setting restricts the volume so that it can only be mounted to a single pod at a time, unless all pods consuming that volume are co-located on the same node. This behavior makes a deployment resource unusable for scaling beyond a single replica if it consumes vSphere volumes.
+
+Even using a deployment resource with just a single replica may result in a deadlock situation while updating the deployment. If the updated pod is scheduled to a node different from where the existing pod lives, it will fail to start because the VMDK is still attached to the other node.
+
+## Related Links
+
+- [vSphere Storage for Kubernetes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)
+- [Kubernetes Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
@@ -12,7 +12,7 @@ _Persistent Volume Claims_ (or PVCs) are objects that request storage resources
 - Each Rancher project contains a list of PVCs that you've created, available from the **Volumes** tab. You can reuse these PVCs when creating deployments in the future.

 >**Prerequisite:**
-> You must have a pre-provisioned [persistent volume]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/#adding-a-persistent-volume) available for use, or you must have a [storage class created]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/#adding-storage-classes) that dynamically creates a volume upon request from the workload.
+> You must have a pre-provisioned [persistent volume]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#adding-a-persistent-volume) available for use, or you must have a [storage class created]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#adding-storage-classes) that dynamically creates a volume upon request from the workload.

 1. From the **Global** view, open the project containing a workload that you want to add a PVC to.

@@ -70,9 +70,9 @@ There are several types of services available in Rancher. The descriptions below

 This section of the documentation contains instructions for deploying workloads and using workload options.

-    - [Deploy Workloads]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/deploy-workloads/)
-    - [Upgrade Workloads]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/upgrade-workloads/)
-    - [Rollback Workloads]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/rollback-workloads/)
+    - [Deploy Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/)
+    - [Upgrade Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads/)
+    - [Rollback Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads/)

 ## Related Links

@@ -13,25 +13,25 @@ Deploy a workload to run an application in one or more containers.

 1. Enter a **Name** for the workload.

-1. Select a [workload type]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/). The workload defaults to a scalable deployment, by can change the workload type by clicking **More options.**
+1. Select a [workload type]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/). The workload defaults to a scalable deployment, by can change the workload type by clicking **More options.**

 1. From the **Docker Image** field, enter the name of the Docker image that you want to deploy to the project. During deployment, Rancher pulls this image from [Docker Hub](https://hub.docker.com/explore/). Enter the name exactly as it appears on Docker Hub.

 1. Either select an existing [namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/), or click **Add to a new namespace** and enter a new namespace.

-1. Click **Add Port** to enter a port mapping, which enables access to the application inside and outside of the cluster . For more information, see [Services]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/#services).
+1. Click **Add Port** to enter a port mapping, which enables access to the application inside and outside of the cluster . For more information, see [Services]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/#services).

 1. Configure the remaining options:

    - **Environment Variables**

-        Use this section to either specify environment variables for your workload to consume on the fly, or to pull them from another source, such as a secret or [ConfigMap]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/configmaps/).
+        Use this section to either specify environment variables for your workload to consume on the fly, or to pull them from another source, such as a secret or [ConfigMap]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/configmaps/).

    - **Node Scheduling**
    - **Health Check**
    - **Volumes**

-        Use this section to add storage for your workload. You can manually specify the volume that you want to add, use a persistent volume claim to dynamically create a volume for the workload, or read data for a volume to use from a file such as a [ConfigMap]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/configmaps/).
+        Use this section to add storage for your workload. You can manually specify the volume that you want to add, use a persistent volume claim to dynamically create a volume for the workload, or read data for a volume to use from a file such as a [ConfigMap]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/configmaps/).

    - **Scaling/Upgrade Policy**

@@ -1,21 +0,0 @@
---
-title: Kubernetes in Rancher
-weight: 3000
-aliases:
-  - /rancher/v2.x/en/concepts/
-  - /rancher/v2.x/en/tasks/
-  - /rancher/v2.x/en/concepts/resources/
---
-
-
-
-Within the context of a Rancher project or namespace, _resources_ are files and data that support operation of your pods. Within this scope, resources include:
-
- [Certificates]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/certificates/)
- [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/configmaps/)
- [Secrets]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/secrets/)
- [Registries]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/registries/)
-
-Rancher extends the application of the Kubernetes namespace resources listed above to [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/), 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.
@@ -1,4 +0,0 @@
---
-title: Load Balancing and Ingresses
-weight: 3040
---
@@ -1,222 +1,14 @@
 ---
-title: Quick Start Guide
-short title: Quick Start
+title: Quick Start Guides
+short title: Quick Start Index
 weight: 25
 ---
->**Note:** This Quick Start Guide's intent is to get you up and running in a sandbox environment. It is not intended for a production environment. For more comprehensive instructions, see [Installation]({{< baseurl >}}/rancher/v2.x/en/installation/).
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{< baseurl >}}/rancher/v2.x/en/installation/).

-Howdy Partner! This tutorial walks you through:
-    
- Installation of {{< product >}} {{< version >}}
- Creation of your first cluster
- Deployment of an application, Nginx
+Howdy buckaroos! Use this section of the docs to jump start your deployment and testing of Rancher 2.0! It contains instructions for a simple Rancher setup and some common use cases. We plan on adding more content to this section in the future.

-## Quick Start Outline
+We have Quick Start Guides for:

-This Quick Start Guide is divided into different tasks for easier consumption.
+- [Deploying Rancher Server]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/): Get started running Rancher using the method most convenient for you.

-1.  [Provision a Linux Host](#provision-a-linux-host)
-
-    Begin by provisioning a Linux host.
-
-2.  [Install Rancher](#install-rancher)
-
-    From your Linux host, run the Docker command for installing Rancher.
-
-3.  [Log In](#log-in)
-
-    Browse to your Linux host to access the Rancher UI.
-
-4.  [Create the Cluster](#create-the-cluster)
-
-    Use the versatile **Custom** option to add your Linux host into a new Kubernetes cluster.
-
-5.  [Deploy a Workload](#deploy-a-workload)
-
-    Create a workload so that Kubernetes can distribute Nginx among your cluster nodes.
-
-6.  [View Your Application](#view-your-application)
-
-    When your workload finishes deployment, browse to your node IP to make sure Nginx is running.
-
-### Provision a Linux Host
-
- Begin creation of a custom cluster by provisioning a Linux host. Your host can be:
-
- A cloud-host virtual machine (VM)
- An on-premise VM
- A bare-metal server
-
-  >**Note:**
-  > When using a cloud-hosted virtual machine you need to allow inbound TCP communication to ports 80 and 443.  Please see your cloud-host's documentation for information regarding port configuration.
-  >
-  > For a full list of port requirements, refer to [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install/#port-requirements).
-
- Provision the host according to the requirements below.
-
-{{< requirements_os >}}
-
-**Hardware Requirements**
-
- Memory: 4GB
-
-**Software Requirements**
-
- Software: Docker
-
-  <a name="node-requirements"></a>**Supported Docker versions:**
-
-  - `1.12.6`
-  - `1.13.1`
-  - `17.03.2`
-
-  >**Notes:**
-  >
-  > - For Docker installation instructions, visit their [documentation](https://docs.docker.com/install/).
-  > - Docker requirements apply to both your Linux host and your cluster nodes.
-
-### Install Rancher
-
-To install Rancher on your host, connect to it and then use a shell to install.
-
-1.  Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection.
-
-2.  From your shell, enter the following command:
-
-	```
-	$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher
-	```
-
-**Result:** Rancher is installed.
-
-### Log In
-
-Log in to Rancher to begin using the application. After you log in, you'll make some one-time configurations.
-
-1.  Open a web browser and enter the IP address of your host: `https://<SERVER_IP>`.<br/><br/>
-    Replace `<SERVER_IP>` with your host IP address.
-
-2.  When prompted, create a password for the default `admin` account there cowpoke!
-
-3. Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node added to your cluster must be able to connect to this URL.<br/><br/>If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster.
-
-### Create the Cluster
-
-Welcome to Rancher! You are now able to create your first Kubernetes cluster.
-
-In this task, you can use the versatile **Custom** option. This option lets you add _any_ Linux host (cloud-hosted VM, on-premise VM, or bare-metal) to be used in a cluster.
-
-1. From the **Clusters** page, click **Add Cluster**.
-
-2. Choose **Custom**.
-
-3. Enter a **Cluster Name**.
-
-4. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later.
-
-5. Click **Next**.
-
-6. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**.
-
-7. **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section.
-
-8. Skip the **Labels** stuff. It's not important for now.
-
-9. Copy the command displayed on screen to your clipboard.
-
-10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
-
-11. When you finish running the command on your Linux host, click **Done**.
-
-{{< result_create-cluster >}}
-
-### Deploy a Workload
-
-You're ready to create your first _workload_. A workload is an object that includes pods along with other files and info needed to deploy your application.
-
-For this workload, you'll be deploying the application Nginx.
-
-1.  From the **Clusters** page, open the cluster that you just created.
-
-2.  From the main menu of the **Dashboard**, select **Projects**.
-
-3.  Open the **Default** project.
-
-4.  Click **+ Deploy**.
-
-	**Step Result:** The **Deploy Workload** page opens.
-
-5.  Enter a **Name** for your workload.
-
-6.  From the **Docker Image** field, enter `nginx`. This field is case-sensitive.
-
-7.  From **Port Mapping**, click **Add Port**.
-
-8.  From the **As a** drop-down, make sure that **NodePort (On every node)** is selected.
-
-	![As a dropdown, NodePort (On every node selected)]({{< baseurl >}}/img/rancher/nodeport-dropdown.png)
-
-9.  From the **On Listening Port** field, leave the **Random** value in place.
-
-	![On Listening Port, Random selected]({{< baseurl >}}/img/rancher/listening-port-field.png)
-
-10. From the **Publish the container port** field, enter port `80`.
-
-	![Publish the container port, 80 entered]({{< baseurl >}}/img/rancher/container-port-field.png)
-
-11. Leave the remaining options on their default setting. We'll tell you about them later.
-
-12. Click **Launch**.
-
-**Result:**
-
-* Your workload is deployed. This process might take a few minutes to complete.
-* When your workload completes deployment, it's assigned a state of **Active**. You can view this status from the project's **Workloads** page.
-
-### View Your Application
-
-When your workload completes deployment, browse to its IP to confirm that your application is working.
-
-From the **Workloads** page, click the link underneath your workload. If your deployment succeeded, your application opens.
-
->**Note**
-> When using a cloud-hosted virtual machine, you may not have access to the port running the container. In this event, you can test Nginx in an ssh session on the local machine. Use the port number after the `:` in the link under your workload, which is 31568 in this example.
->
->```sh
-
-gettingstarted@rancher:~$ curl http://localhost:31568
-<!DOCTYPE html>
-<html>
-<head>
-<title>Welcome to Nginx!</title>
-<style>
-    body {
-        width: 35em;
-        margin: 0 auto;
-        font-family: Tahoma, Verdana, Arial, sans-serif;
-    }
-</style>
-</head>
-<body>
-<h1>Welcome to Nginx!</h1>
-<p>If you see this page, the Nginx web server is successfully installed and
-working. Further configuration is required.</p>
-
-<p>For online documentation and support please refer to
-<a href="http://Nginx.org/">Nginx.org</a>.<br/>
-Commercial support is available at
-<a href="http://nginx.com/">nginx.com</a>.</p>
-
-<p><em>Thank you for using Nginx.</em></p>
-</body>
-</html>
-gettingstarted@rancher:~$
-
-```
-
-## Finished
-
-Congratulations! You have:
-
- Created your first cluster.
- Deployed Nginx to your cluster using a workload.
+- [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide//workload/): Deploy a simple workload and expose it, letting you access it from outside the cluster.
@@ -0,0 +1,12 @@
+---
+title: Deploying Rancher Server
+weight: 100
+---
+
+The following are the current guides for provisioning Rancher Server and a cluster:
+
+- [DigitalOcean Quick Start](./digital-ocean-qs) - We provide you with a Terraform configuration file that completely automates the set up of the Rancher Server and registers a cluster for you to get started with.
+
+- [Vagrant Quick Start](./quickstart-vagrant) - We provide you with a Vagrant configuration that again completely automates the set up of the Rancher Server and registers a cluster for you to get started with.
+
+- [Manual Quick Start](./quickstart-manual-setup) - This will guide you through the process and requirements of manually setting up Rancher in any environment.
@@ -0,0 +1,56 @@
+---
+title: DigitalOcean Quick Start
+weight: 100
+---
+The following steps will quickly deploy a Rancher Server with a single node cluster attached.
+
+## Prerequisites
+
+>**Note**
+>Deploying to DigitalOcean will incur charges.
+
+- [DigitalOcean Account](https://www.digitalocean.com): You will require an account on DigitalOcean as this is where the server and cluster will run.
+- [DigitalOcean Access Key](https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key): Use this link to create a DigitalOcean Access Key if you don't have one.
+- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to DigitalOcean.
+
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the DigitalOcean folder containing the terraform file by executing `cd quickstart/do`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` to include your DigitalOcean Access Key.
+
+5. **Optional:** Edit `terraform.tfvars` to:
+
+    - Change the number of nodes. (`count_agent_all_nodes`)
+    - Change the password of the `admin` user for logging into Rancher. (`admin_password`)
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply`. Then wait for the the following output:
+
+	```
+	Apply complete! Resources: 2 added, 0 changed, 0 destroyed. 
+	  Outputs: 
+	  rancher-url = [ 
+              https://xxx.xxx.xxx.xxx 
+      ]
+	```
+
+8. Paste the `rancher-url` from the output above into the browser. Log in when prompted (default password is `admin`).
+
+**Result:** Rancher Server and your Kubernetes cluster is installed on DigitalOcean.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/workload).
+
+## Destroying the Environment
+
+1. From the `quickstart/do` folder, execute `terraform destroy --force`.
+
+2. Wait for confirmation that all resources have been destroyed.
@@ -0,0 +1,129 @@
+---
+title: Manual Quick Start
+weight: 300
+---
+Howdy Partner! This tutorial walks you through:
+    
+- Installation of {{< product >}} {{< version >}}
+- Creation of your first cluster
+- Deployment of an application, Nginx
+
+## Quick Start Outline
+
+This Quick Start Guide is divided into different tasks for easier consumption.
+
+<!-- TOC -->
+
+
+1. [Provision a Linux Host](#1-provision-a-linux-host)
+
+1. [Install Rancher](#2-install-rancher)
+
+1. [Log In](#3-log-in)
+
+1. [Create the Cluster](#4-create-the-cluster)
+
+<!-- /TOC -->
+<br/>
+### 1. Provision a Linux Host
+
+ Begin creation of a custom cluster by provisioning a Linux host. Your host can be:
+
+- A cloud-host virtual machine (VM)
+- An on-premise VM
+- A bare-metal server
+
+  >**Note:**
+  > When using a cloud-hosted virtual machine you need to allow inbound TCP communication to ports 80 and 443.  Please see your cloud-host's documentation for information regarding port configuration.
+  >
+  > For a full list of port requirements, refer to [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/references).
+
+ Provision the host according to the requirements below.
+
+{{% accordion id="os" label="Operating System" %}}
+{{< requirements_os >}}
+{{% /accordion %}}
+{{% accordion id="hardware" label="Hardware" %}}
+Memory: 4GB 
+{{% /accordion %}}
+{{% accordion id="software" label="Software" %}}
+Docker
+
+  <a name="node-requirements"></a>**Supported Docker versions:**
+
+  - `1.12.6`
+  - `1.13.1`
+  - `17.03.2`
+
+  >**Notes:**
+  >
+  > - For Docker installation instructions, visit their [documentation](https://docs.docker.com/install/).
+  > - Docker requirements apply to both your Linux host and your cluster nodes. 
+{{% /accordion %}}
+<br/>
+### 2. Install Rancher
+
+To install Rancher on your host, connect to it and then use a shell to install.
+
+1.  Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection.
+
+2.  From your shell, enter the following command:
+
+	```
+	$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher
+	```
+
+**Result:** Rancher is installed.
+
+### 3. Log In
+
+Log in to Rancher to begin using the application. After you log in, you'll make some one-time configurations.
+
+1.  Open a web browser and enter the IP address of your host: `https://<SERVER_IP>`.
+
+    Replace `<SERVER_IP>` with your host IP address.
+
+2.  When prompted, create a password for the default `admin` account there cowpoke!
+
+3. Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node added to your cluster must be able to connect to this URL.<br/><br/>If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster.
+
+<br/>
+
+### 4. Create the Cluster
+
+Welcome to Rancher! You are now able to create your first Kubernetes cluster.
+
+In this task, you can use the versatile **Custom** option. This option lets you add _any_ Linux host (cloud-hosted VM, on-premise VM, or bare-metal) to be used in a cluster.
+
+1. From the **Clusters** page, click **Add Cluster**.
+
+2. Choose **Custom**.
+
+3. Enter a **Cluster Name**.
+
+4. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later.
+
+5. Click **Next**.
+
+6. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**.
+
+7. **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section.
+
+8. Skip the **Labels** stuff. It's not important for now.
+
+9. Copy the command displayed on screen to your clipboard.
+
+10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
+
+11. When you finish running the command on your Linux host, click **Done**.
+
+{{< result_create-cluster >}}
+<br/>
+<br/>
+#### Finished
+
+Congratulations! You have created your first cluster.
+
+#### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/workload).
@@ -0,0 +1,38 @@
+---
+title: Vagrant Quick Start
+weight: 200
+---
+The following steps quickly deploy a Rancher Server with a single node cluster attached.
+
+## Prerequisites
+
+- [Vagrant](https://www.vagrantup.com): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
+- [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
+- At least 4GB of free RAM.
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the folder containing the terraform file by executing `cd quickstart/vagrant`.
+
+3. **Optional:** Edit `config.yaml` to:
+
+    - Change the number of nodes and the memory allocations, if required. (`node.count`, `node.cpus`, `node.memory`)
+    - Change the password of the `admin` user for logging into Rancher. (`default_password`)
+
+4. To initiate the creation of the environment run, `vagrant up`.
+
+5. Once provisioning finishes, go to `https://172.22.101.101` in the browser. The default user/password is `admin/admin`.
+
+**Result:** Rancher Server and your Kubernetes cluster is installed on VirtualBox.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/workload).
+
+## Destroying the Environment
+
+1. From the `quickstart/vagrant` folder execute `vagrant destroy -f`.
+
+2. Wait for the confirmation that all resources have been destroyed.
@@ -0,0 +1,10 @@
+---
+title: Deploying Workloads
+weight: 200
+---
+
+These Quick Start Guides will walk you through deployment of an application. Then they will show you how to expose the application so that you can access it from outside the cluster.
+
+- [Workload with Ingress Quick Start](./quickstart-deploy-workload-ingress): Create a workload and then expose it using an Ingress.
+
+- [Workload with NodePort Quick Start](./quickstart-deploy-workload-nodeport): Create a workload and then expose it using a Nodeport.
@@ -0,0 +1,79 @@
+---
+title: Workload with Ingress Quick Start
+weight: 100
+---
+
+### Prerequisite
+
+You have a running cluster with at least 1 node.
+
+### 1. Deploying a Workload
+
+You're ready to create your first _workload_. A workload is an object that includes pods along with other files and info needed to deploy your application.
+
+For this workload, you'll be deploying the application Rancher Hello-World.
+
+1.  From the **Clusters** page, open the cluster that you just created.
+
+2.  From the main menu of the **Dashboard**, select **Projects**.
+
+3.  Open the **Project: Default** project.
+
+4.  Click **Deploy**.
+
+	**Step Result:** The **Deploy Workload** page opens.
+
+5.  Enter a **Name** for your workload.
+
+6.  From the **Docker Image** field, enter `rancher/hello-world`. This field is case-sensitive.
+
+7. Leave the remaining options on their default setting. We'll tell you about them later.
+
+8. Click **Launch**.
+
+**Result:**
+
+* Your workload is deployed. This process might take a few minutes to complete.
+* When your workload completes deployment, it's assigned a state of **Active**. You can view this status from the project's **Workloads** page.
+
+<br/>
+### 2. Expose The Application Via An Ingress
+
+Now that the application is up and running it needs to be exposed so that other services can connect.
+
+1.  From the **Clusters** page, open the cluster that you just created.
+
+2.  From the main menu of the **Dashboard**, select **Projects**.
+
+3.  Open the **Default** project.
+
+4.  Click on the **Load Balancing** tab.
+
+5.  Click **Add Ingress**.
+
+6.  Enter a name i.e. **hello**.
+
+7.  In the **Target** field, drop down the list and choose the name that you set for your service.
+
+8.  Enter `80` in the **Port** field.
+
+9.  Leave everything else as default and click **Save**.
+
+**Result:**  The application is assigned a `xip.io` address and exposed. It may take a minute or two to populate.
+
+### View Your Application
+
+From the **Load Balancing** page, click the target link, which will look something like `hello.default.xxx.xxx.xxx.xxx.xip.io > hello-world`.
+
+Your application will open in a separate window.
+
+#### Finished
+
+Congratulations! You have successfully deployed a workload exposed via an ingress.
+
+#### What's Next?
+
+When you're done using your sandbox, destroy the Rancher Server and your cluster. See one of the following:
+
+- [DigitalOcean: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/digital-ocean-qs/#destroying-the-environment)
+- [Vagrant: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/#destroying-the-environment)
@@ -0,0 +1,153 @@
+---
+title: Workload with NodePort Quick Start
+weight: 200
+---
+
+### Prerequisite
+
+You have a running cluster with at least 1 node.
+
+### 1. Deploying a Workload
+
+You're ready to create your first _workload_. A workload is an object that includes pods along with other files and info needed to deploy your application.
+
+For this workload, you'll be deploying the application Rancher Hello-World.
+
+1.  From the **Clusters** page, open the cluster that you just created.
+
+2.  From the main menu of the **Dashboard**, select **Projects**.
+
+3.  Open the **Project: Default** project.
+
+4.  Click **Deploy**.
+
+	**Step Result:** The **Deploy Workload** page opens.
+
+5.  Enter a **Name** for your workload.
+
+6.  From the **Docker Image** field, enter `rancher/hello-world`. This field is case-sensitive.
+
+7.  From **Port Mapping**, click **Add Port**.
+
+8.  From the **As a** drop-down, make sure that **NodePort (On every node)** is selected.
+
+	![As a dropdown, NodePort (On every node selected)]({{< baseurl >}}/img/rancher/nodeport-dropdown.png)
+
+9.  From the **On Listening Port** field, leave the **Random** value in place.
+
+	![On Listening Port, Random selected]({{< baseurl >}}/img/rancher/listening-port-field.png)
+
+10. From the **Publish the container port** field, enter port `80`.
+
+	![Publish the container port, 80 entered]({{< baseurl >}}/img/rancher/container-port-field.png)
+
+11. Leave the remaining options on their default setting. We'll tell you about them later.
+
+12. Click **Launch**.
+
+**Result:**
+
+* Your workload is deployed. This process might take a few minutes to complete.
+* When your workload completes deployment, it's assigned a state of **Active**. You can view this status from the project's **Workloads** page.
+
+<br/>
+
+### 2. Viewing Your Application
+
+From the **Workloads** page, click the link underneath your workload. If your deployment succeeded, your application opens.
+
+### Attention: Cloud-Hosted Sandboxes
+
+When using a cloud-hosted virtual machine, you may not have access to the port running the container. In this event, you can test Nginx in an ssh session on the local machine. Use the port number after the `:` in the link under your workload, which is `31568` in this example.
+
+```sh
+gettingstarted@rancher:~$ curl http://localhost:31568
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Rancher</title>
+    <link rel="icon" href="img/favicon.png">
+    <style>
+      body {
+        background-color: white;
+        text-align: center;
+        padding: 50px;
+        font-family: "Open Sans","Helvetica Neue",Helvetica,Arial,sans-serif;
+      }
+      button {
+          background-color: #0075a8;
+          border: none;
+          color: white;
+          padding: 15px 32px;
+          text-align: center;
+          text-decoration: none;
+          display: inline-block;
+          font-size: 16px;
+      }
+
+      #logo {
+        margin-bottom: 40px;
+      }
+    </style>
+  </head>
+  <body>
+    <img id="logo" src="img/rancher-logo.svg" alt="Rancher logo" width=400 />
+    <h1>Hello world!</h1>
+    <h3>My hostname is hello-world-66b4b9d88b-78bhx</h3>
+    <div id='Services'>
+      <h3>k8s services found 2</h3>
+
+      <b>INGRESS_D1E1A394F61C108633C4BD37AEDDE757</b> tcp://10.43.203.31:80<br />
+
+      <b>KUBERNETES</b> tcp://10.43.0.1:443<br />
+
+    </div>
+    <br />
+
+    <div id='rancherLinks' class="row social">
+      <a class="p-a-xs" href="https://rancher.com/docs"><img src="img/favicon.png" alt="Docs" height="25" width="25"></a>
+      <a class="p-a-xs" href="https://slack.rancher.io/"><img src="img/icon-slack.svg" alt="slack" height="25" width="25"></a>
+      <a class="p-a-xs" href="https://github.com/rancher/rancher"><img src="img/icon-github.svg" alt="github" height="25" width="25"></a>
+      <a class="p-a-xs" href="https://twitter.com/Rancher_Labs"><img src="img/icon-twitter.svg" alt="twitter" height="25" width="25"></a>
+      <a class="p-a-xs" href="https://www.facebook.com/rancherlabs/"><img src="img/icon-facebook.svg" alt="facebook" height="25" width="25"></a>
+      <a class="p-a-xs" href="https://www.linkedin.com/groups/6977008/profile"><img src="img/icon-linkedin.svg" height="25" alt="linkedin" width="25"></a>
+    </div>
+    <br />
+    <button class='button' onclick='myFunction()'>Show request details</button>
+    <div id="reqInfo" style='display:none'>
+      <h3>Request info</h3>
+      <b>Host:</b> 172.22.101.111:31411 <br />
+      <b>Pod:</b> hello-world-66b4b9d88b-78bhx </b><br />
+
+      <b>Accept:</b> [*/*]<br />
+
+      <b>User-Agent:</b> [curl/7.47.0]<br />
+
+    </div>
+    <br />
+    <script>
+      function myFunction() {
+          var x = document.getElementById("reqInfo");
+          if (x.style.display === "none") {
+              x.style.display = "block";
+          } else {
+              x.style.display = "none";
+          }
+      }
+    </script>
+  </body>
+</html>
+gettingstarted@rancher:~$
+
+```
+
+### Finished
+
+Congratulations! You have successfully deployed a workload exposed via a NodePort.
+
+#### What's Next?
+
+When you're done using your sandbox, destroy the Rancher Server and your cluster. See one of the following:
+
+- [DigitalOcean: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/digital-ocean-qs/#destroying-the-environment)
+- [Vagrant: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/#destroying-the-environment)
@@ -2,3 +2,79 @@
 title: Rancher Tools
 weight: 5000
 ---
+
+Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into four categories:
+
+<!-- TOC -->
+
+- [Alerts](#alerts)
+- [Notifiers](#notifiers)
+- [Logging](#logging)
+- [Pipelines](#pipelines)
+
+<!-- /TOC -->
+
+## Alerts
+
+To keep your clusters and applications healthy and driving your organizational productivity forward, you need stay informed of events occurring in your clusters, both planned and unplanned. To help you stay informed of these events, Rancher allows you to configure alerts.
+
+_Alerts_ are sets of rules, chosen by you, to monitor for specific events. The scope for alerts can be set at either the cluster or project level.
+
+Some examples of alert events are:
+
+- A Kubernetes [master component]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) entering an unhealthy state.
+- A node or [workload]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/) error occurring.
+- A scheduled deployment taking place as planned.
+- A node's hardware resources becoming overstressed.
+
+When an event occurs, your alert is triggered, and you are sent a notification. You can then, if necessary, follow up with corrective actions.
+
+Additionally, you can set an urgency level for each alert. This urgency appears in the notification you receive, helping you to prioritize your response actions. For example, if you have an alert configured to inform you of a routine deployment, no action is required. These alerts can be assigned a low priority level. However, if a deployment fails, it can critically impact your organization, and you need to react quickly. Assign these alerts a high priority level.
+
+For more information, see [Alerts]({{< baseurl >}}/rancher/v2.x/en/tools/notifiers-and-alerts/#alerts).
+
+## Notifiers
+
+Before you can receive alerts, you must configure one or more notifier in Rancher.
+
+_Notifiers_ are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action. Rancher integrates with a variety of popular IT services, including:
+
+- Slack: Send alert notifications to your Slack channels.
+- Email: Choose email recipients for alert notifications.
+- PagerDuty: Route notifications to staff by phone, SMS, or personal email.
+- Webhooks: Update a webpage with alert notifications.
+
+For more information, see [Notifiers]({{< baseurl >}}/rancher/v2.x/en/tools/notifiers-and-alerts/#notifiers).
+
+## Logging
+
+Rancher can integrate with popular external services used for event streams, telemetry, or search. Rancher can integrate with the following services:
+
+- Embedded Elasticsearch (experimental)
+    
+    >**Note:** This option is available only at the cluster level.
+
+- Elasticsearch
+- splunk
+- kafka
+- syslog
+
+These services collect container log events, which are saved to the `/var/log/containers` directory on each of your nodes. The service collects both standard and error events. You can then log into your services to review the events collected, leveraging each service's unique features.
+
+When configuring Rancher to integrate with these services, you'll have to point Rancher toward the service's endpoint and provide authentication information. Additionally, you'll have the opportunity to enter key value pairs to filter the log events collected. The service will only collect events for containers marked with your configured key value pairs.
+
+You can configure these services to collect logs at either the cluster or project level.
+
+## Pipelines
+
+Using Rancher, you can integrate with a GitHub repository to setup a continuous integration (CI) pipeline.
+
+To set up a pipeline, you'll first need to authorize Rancher using your GitHub settings. Directions are provided in the Rancher UI. After authorizing Rancher in GitHub, provide Rancher with a client ID and secret to authenticate.
+
+After configuring Rancher and GitHub, you can deploy containers running Jenkins to automate a pipeline execution:
+
+- Build your application from code to image.
+- Validate your builds.
+- Deploy your build images to your cluster.
+- Run unit tests.  
+- Run regression tests.
@@ -1,35 +1,300 @@
 ---
-title:  Notifiers and Alerts
+title:  Alerts and Notifiers
 weight: 5010
 ---

-Alerts and notifications are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher is able to provide the first step in notifications for events operators and application owners need to know about.
+Notifiers and alerts are two features that work together to inform you of events in the Rancher system. Notifiers are objects that you configure to leverage popular IT services, which send you notification of Rancher events. Alerts are rule sets that trigger when those notifications are sent.
+
+Notifiers and alerts are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher can notify [cluster owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) and [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) of events they need to address.

 ## Notifiers

-In Rancher 2.x, a user can configure `Notifiers` for each cluster that can receive alerts for various events. By configuring the notifiers at the cluster level, project owners do not need to know SMTP settings or have access to cloud accounts. At a project level, users can configure alerts and add recipients scoped to the relevant alerts.
+Before you can receive [alerts](#alerts), you must configure one or more notifier in Rancher.

-Available Notifiers:
+Notifiers are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action.

-* Email
-* Slack
-* PagerDuty
-* Webhooks
+Notifiers are configured at the cluster level. This model ensures that only cluster owners need to configure notifiers, leaving project owners to simply configure alerts in the scope of their projects. You don't need to dispense privileges like SMTP server access or cloud account access.
+
+Rancher integrates with a variety of popular IT services, including:
+
+- **Slack**: Send alert notifications to your Slack channels.
+- **Email**: Choose email recipients for alert notifications.
+- **PagerDuty**: Route notifications to staff by phone, SMS, or personal email.
+- **WebHooks**: Update a webpage with alert notifications.
+<br/>
+<br/>
+
+### Adding Notifiers
+
+Set up a notifier so that you can begin configuring and sending alerts.
+
+1. From the **Global View**, open the cluster that you want to add a notifier to.
+
+1. From the main menu, select **Tools > Notifiers**. Then click **Add Notifier**.
+
+1. Select the service you want to use as your notifier, and then fill out the form.
+{{% accordion id="slack" label="Slack" %}}
+1. Enter a **Name** for the notifier.
+1. From Slack, create a webhook. For instructions, see the [Slack Documentation](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack).
+1. From Rancher, enter your Slack webhook **URL**.
+1. Enter the name of the channel that you want to send alert notifications in the following format: `#<channelname>`.
+
+    Both public and private channels are supported.
+1. Click **Test**. If the test is successful, the Slack channel you're configuring for the notifier outputs `Slack setting validated`.
+{{% /accordion %}}
+{{% accordion id="email" label="Email" %}}
+1. Enter a **Name** for the notifier.
+1. In the **Sender** field, enter an email address available on your mail server that you want to send the notification.
+1. In the **Host** field, enter the IP address or host name for your SMTP server. Example: `smtp.email.com`
+1. In the **Port** field, enter the port used for email. Typically, TLS uses `587` and SSL uses `465`. If you're using TLS, make sure **Use TLS** is selected.
+1. Enter a **Username** and **Password** that authenticate with the SMTP server. 
+1. In the **Default Recipient** field, enter the email address that you want to receive the notification. 
+1. Click **Test**. If the test is successful, Rancher prints `settings validated` and you receive a test notification email.
+{{% /accordion %}}
+{{% accordion id="pagerduty" label="PagerDuty" %}}
+1. Enter a **Name** for the notifier.
+1. From PagerDuty, create a webhook. For instructions, see the [PagerDuty Documentation](https://support.pagerduty.com/docs/webhooks).
+1. From PagerDuty, copy the webhook's **Integration Key**.
+1. From Rancher, enter the key in the **Service Key** field.
+1. Click **Test**. If the test is successful, your PagerDuty endpoint outputs `PageDuty setting validated`.
+{{% /accordion %}}
+{{% accordion id="webhook" label="WebHook" %}}
+1. Enter a **Name** for the notifier.
+1. Using the app of your choice, create a webhook URL.
+1. Enter your webhook **URL**.
+1. Click **Test**. If the test is successfull, the URL you're configuring as a notifier outputs `Webhook setting validated`.
+{{% /accordion %}}
+
+1. Click **Add** to complete adding the notifier.
+
+**Result:** Your notifier is added to Rancher.
+
+#### What's Next?
+
+After creating a notifier, set up alerts to receive notifications of Rancher system events.
+
+- [Cluster owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) can set up alerts at the [cluster level](#cluster-alerts).
+- [Project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can set up alerts at the [project level](#project-alerts).
+<br/>
+<br/>
+
+### Managing Notifiers
+
+After you set up notifiers, you can manage them by selecting **Tools > Notifiers** from the **Global** view. You can:
+
+- **Edit** their settings that you configured during their initial setup.
+- **Clone** them, to quickly setup slightly different notifiers.
+- **Delete** them when they're no longer necessary.

 ## Alerts

-Rancher supports alerting on a cluster level or project level.
+To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. To help you stay informed of these events, you can configure alerts.

-On a cluster level, Rancher can monitor and alert on components that manage your Kubernetes cluster including:
+Alerts are sets of rules, chosen by you, to monitor for specific events. The scope for alerts can be set at either the cluster or project level.

-* System Services
-* Resource Events
-* Node conditions
+### Cluster Alerts vs. Project Alerts

-Operators of Kubernetes clusters can get alerts on the health of nodes and other system level components.
+At the [cluster level](#adding-cluster-alerts), Rancher monitors components in your Kubernetes cluster, and sends you alerts related to:

-On a project level, Rancher can monitor and alert on status on specific deployments including:
+- The state of your nodes.
+- The system services that manage your Kubernetes cluster.
+- The resource events from specific system services.
+
+At the [project level](#adding-project-alerts), Rancher monitors specific deployments and sends alerts for:

 * Deployment availability
-* Workloads
-* Pods
+* Workloads status
+* Pod status
+<br/>
+<br/>
+
+#### Adding Cluster Alerts
+
+As a cluster owner, you can configure Rancher to send you alerts for cluster events.
+
+>**Prerequisite:** Before you can receive cluster alerts, you must [add a notifier](#adding-notifiers).
+
+1. From the **Global** view, open the cluster that you want to configure alerts for.
+
+1. From the main menu, select **Tools > Alerts**. Then click **Add Alert**.
+
+1. Enter a **Name** for the alert that describes its purpose.
+
+1. Based on the type of alert you want to create, complete one of the instruction subsets below.
+{{% accordion id="system-service" label="System Service Alerts" %}}
+This alert type monitors for events that affect one of the Kubernetes master components, regardless of the node it occurs on.
+
+1. Select the **System Services** option, and then select an option from the drop-down.
+
+  - [controller-manager](https://kubernetes.io/docs/concepts/overview/components/#kube-controller-manager)
+  - [etcd](https://kubernetes.io/docs/concepts/overview/components/#etcd)
+  - [scheduler](https://kubernetes.io/docs/concepts/overview/components/#kube-scheduler)
+
+1. Select the urgency level of the of alert. The options are:
+
+    - **Critical**: Most urgent
+    - **Warning**: Normal urgency
+    - **Info**: Least urgent
+    <br/>
+    <br/>
+    Select the urgency level based on the importance of the service and how many nodes fill the role within your cluster. For example, if you're making an alert for the `etcd` service, select **Critical**. If you're making an alert for redundant schedulers, **Warning** is more appropriate.
+{{% /accordion %}}
+{{% accordion id="resource-event" label="Resource Event Alerts" %}}
+This alert type monitors for specific events that are thrown from a resource type.
+
+1. Choose the type of resource event that triggers an alert. The options are:
+
+  - **Normal**: triggers an alert when any standard resource event occurs.
+  - **Warning**: triggers an alert when unexpected resource events occur.
+
+1. Select a resource type from the **Choose a Resource** drop-down that you want to trigger an alert.
+
+  - [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
+  - [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
+  - [Node](https://kubernetes.io/docs/concepts/architecture/nodes/)
+  - [Pod](https://kubernetes.io/docs/concepts/workloads/pods/pod/)
+  - [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
+
+1. Select the urgency level of the of alert.
+
+    - **Critical**: Most urgent
+    - **Warning**: Normal urgency
+    - **Info**: Least urgent
+    <br/>
+    <br/>
+    Select the urgency level of the alert by considering factors such as how often the event occurs or its importance. For example:
+
+    - If you set a normal alert for pods, you're likely to receive alerts often, and individual pods usually self-heal, so select an urgency of **Info**.
+    - If you set a warning alert for StatefulSets, its very likely to impact operations, so select an urgency of **Critical**.
+
+
+{{% /accordion %}}
+{{% accordion id="node" label="Node Alerts" %}}
+This alert type monitors for events that occur on a specific node.
+
+1. Select the **Node** option, and then make a selection from the **Choose a Node** drop-down.
+
+1. Choose an event to trigger the alert.
+
+  - **Not Ready**: Sends you an alert when the node is unresponsive.
+  - **CPU usage over**: Sends you an alert when the node raises above an entered percentage of its processing allocation.
+  - **Mem usuage over**: Sends you an alert when the node raises above an entered percentage of its memory allocation.
+
+1. Select the urgency level of the of alert.
+
+    - **Critical**: Most urgent
+    - **Warning**: Normal urgency
+    - **Info**: Least urgent
+    <br/>
+    <br/>
+    Select the urgency level of the alert based on its impact on operations. For example, an alert triggered when a node's CPU raises above 60% deems a urgency of **Info**, but a node that is **Not Ready** deems an urgency of **Critical**.
+{{% /accordion %}}
+{{% accordion id="node-selector" label="Node Selector Alerts" %}}
+This alert type monitors for events that occur on any node on marked with a label. For more information, see the Kubernetes documentation for [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
+
+1. Select the **Node Selector** option, and then click **Add Selector** to enter a key value pair for a label. This label should be applied to one or more of your nodes. Add as many selectors as you'd like.
+
+1. Choose an event to trigger the alert.
+
+  - **Not Ready**: Sends you an alert when selected nodes are unresponsive.
+  - **CPU usage over**: Sends you an alert when selected nodes raise above an entered percentage of processing allocation.
+  - **Mem usuage over**: Sends you an alert when selected nodes raise above an entered percentage of memory allocation.
+
+1. Select the urgency level of the of alert.
+
+    - **Critical**: Most urgent
+    - **Warning**: Normal urgency
+    - **Info**: Least urgent
+    <br/>
+    <br/>
+      Select the urgency level of the alert based on its impact on operations. For example, an alert triggered when a node's CPU raises above 60% deems a urgency of **Info**, but a node that is **Not Ready** deems an urgency of **Critical**.
+{{% /accordion %}}
+1. Finally, choose the notifiers that send you alerts. 
+
+    - You can set up multiple notifiers.
+    - You can change notifier recipients on the fly.
+
+**Result:** Your alert is configured. A notification is sent when the alert is triggered.
+
+#### Managing Cluster Alerts
+
+After you set up cluster alerts, you can manage each alert object. To manage alerts, browse to the cluster containing the alerts, and then select **Tools > Alerts** that you want to manage. You can:
+
+- Deactivate/Reactive alerts
+- Edit alert settings
+- Delete unnecessary alerts
+
+#### Adding Project Alerts
+
+>**Prerequisite:** Before you can receive project alerts, you must [add a notifier](#adding-notifiers).
+
+1. From the **Global** view, open the project that you want to configure alerts for.
+
+1. From the main menu, select **Resources > Alerts**. Then click **Add Alert**.
+
+1. Enter a **Name** for the alert that describes its purpose.
+
+1. Based on the type of alert you want to create, complete one of the instruction subsets below.
+{{% accordion id="pod" label="Pod Alerts" %}}
+This alert type monitors for the status of a specific pod.
+
+1. Select the **Pod** option, and then select a pod from the drop-down.
+1. Select a pod status that triggers and alert:
+
+    - **Not Running**
+    - **Not Scheduled**
+    - **Restarted `<x>` times with the last `<x>` Minutes**
+
+1. Select the urgency level of the of alert. The options are:
+
+    - **Critical**: Most urgent
+    - **Warning**: Normal urgency
+    - **Info**: Least urgent
+
+    Select the urgency level of the alert based on pod state and expendability. For example, an stateless pod that's not can be easily replaced, so select **Info**. However, if an important pod isn't scheduled, it may affect operations, so choose **Critical**.
+{{% /accordion %}}
+{{% accordion id="workload" label="Workload Alerts" %}}
+This alert type monitors for the availability of a workload.
+
+1. Choose the **Workload** option. Then choose a workload from the drop-down.
+
+1. Choose an availability percentage using the slider. The alert is triggered when the workload's availability on your cluster nodes drops below the set percentage.
+
+1. Select the urgency level of the of alert.
+
+    - **Critical**: Most urgent
+    - **Warning**: Normal urgency
+    - **Info**: Least urgent
+
+    Select the urgency level of the alert based on the percentage you choose and the importance of the workload.
+
+{{% /accordion %}}
+{{% accordion id="workload-selector" label="Workload Selector Alerts" %}}
+This alert type monitors for the availability of all workloads marked with tags that you've specified.
+
+1. Select the **Workload Selector** option, and then click **Add Selector** to enter the key value pair for a label. If one of the workloads drops below your specifications, an alert is triggered. This label should be applied to one or more of your workloads.
+
+1. Select the urgency level of the of alert.
+
+    - **Critical**: Most urgent
+    - **Warning**: Normal urgency
+    - **Info**: Least urgent
+
+    Select the urgency level of the alert based on the percentage you choose and the importance of the workload.
+    
+{{% /accordion %}}
+
+1. Finally, choose the notifiers that send you alerts.
+
+    - You can set up multiple notifiers.
+    - You can change notifier recipients on the fly.
+
+**Result:** Your alert is configured. A notification is sent when the alert is triggered.
+
+#### Managing Project Alerts
+
+To manage project alerts, browse to the project that alerts you want to manage. Then select **Resources > Alerts**. You can:
+
+- Deactivate/Reactive alerts
+- Edit alert settings
+- Delete unnecessary alerts
@@ -1,6 +1,8 @@
 ---
-title: Upgrades
+title: Upgrades and Rollbacks
 weight: 150
+aliases:
+  - /rancher/v2.x/en/backups/rollbacks/
 ---

 ### Upgrading from Rancher 2.x.x
@@ -9,9 +11,16 @@ Each new version of Rancher 2.x.x supports upgrades from previous versions of Ra

 Complete one of the upgrade procedures below based on your Rancher installation:

- [Single Node Upgrade](./single-node-upgrade/)
- [High Availability Upgrade](./ha-server-upgrade/)
- [Air Gap Upgrade](./air-gap-upgrade/)
+- [Single Node Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/single-node-upgrade)
+- [High Availability Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/ha-server-upgrade)
+- [Air Gap Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/air-gap-upgrade)
+
+### Rolling Back Unsuccessful Upgrades
+
+In the event that your Rancher Server does not upgrade successfully, you can rollback to your installation prior to upgrade:
+
+- [Single-Node Rollbacks]({{< baseurl >}}/rancher/v2.x/en/upgrades/single-node-rollbacks)
+- [High-Availability Rollbacks]({{< baseurl >}}/rancher/v2.x/en/upgrades/ha-server-rollbacks)

 ### Migrating from Rancher 1.6.x

@@ -1,8 +1,8 @@
 ---
-title: Rolling Back—High Availability Installs
-weight: 50
+title: High Availability Rollback
+weight: 1025
 aliases:
-  - /rancher/v2.x/en/upgrades/rollbacks/ha-server-rollbacks/
+  - /rancher/v2.x/en/backups/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:
@@ -47,10 +47,32 @@ If you upgrade Rancher, but the upgrade does not complete successfully, you may
 1. Enter the following command:

    ```
-kubectl --kubeconfig=kube_config-rancher-cluster.yml set image deployment/cattle cattle-server=rancher/rancher:<PRIOR_VERSION> -n cattle-system
+kubectl --kubeconfig=kube_config_rancher-cluster.yml set image deployment/cattle cattle-server=rancher/rancher:<PRIOR_VERSION> -n cattle-system
    ```
    Replace `<VERSION_TAG>` with the version that you were running before upgrade. For a list of tags available, see the [Rancher Forum Announcements](https://forums.rancher.com/c/announcements).

    **Step Result:** The rollback begins. Rancher Server may be unavailable for a few minutes.

-1. Log into Rancher. Confirm that the rollback succeeded by checking the version displayed in the bottom-left corner of the browser window.
+1. Log into Rancher. Confirm that the rollback succeeded by checking the version displayed in the bottom-left corner of the browser window.
+
+## Troubleshooting
+
+With **RKE v0.1.8** and below, the **rke-bundle-cert** container is left over from a failed etcd restore. If you are having an issue with restoring an **etcd snapshot** then you can do the following on each etcd nodes before attempting to do another restore:
+
+```
+docker container rm --force rke-bundle-cert
+```
+
+The rke-bundle-cert container is usually removed when a backup or restore of **etcd** succeeds.
+Whenever something goes wrong, the **rke-bundle-cert** container will be left over. You can look
+at the logs or inspect the container to see what the issue is.
+
+```
+docker container logs --follow rke-bundle-cert
+docker container inspect rke-bundle-cert
+```
+
+The important thing to note is the mounts of the container and location of the **pki.bundle.tar.gz**.
+
+As of **RKE v0.1.9**, the **rke-bundle-cert** container is removed on both success and
+failure of a restore. To debug any issues, you will need to look at the **logs** generated from rke. 
@@ -0,0 +1,38 @@
+---
+title: Single Node Rollback
+weight: 1015
+aliases:
+  - /rancher/v2.x/en/backups/rollbacks/single-node-rollbacks
+---
+
+Rolling back an unsuccessful Rancher upgrade requires you to
+restore the backup you created while completing [Single Node Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrade-scenarios/single-node-upgrade/).
+
+>**Warning!** Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
+
+1. Pull the version of Rancher that you were running prior to upgrade.
+
+    ```
+docker pull rancher/rancher:<PRIOR_VERSION>
+    ```
+
+2. Stop the container currently running Rancher Server. Replace `<RANCHER_CONTAINER_ID>` with the ID of your Rancher container.
+
+    ```
+docker stop <RANCHER_CONTAINER_ID>
+    ```
+
+3. Go to the location where you saved your [backup tar balls]({{< baseurl>}}/rancher/v2.x/en/upgrades/single-node-upgrade/#backup). Run the following command to create a data container from the backup tar ball.
+
+     ```
+docker run  --volumes-from rancher-data-<PRIOR_VERSION> \
+   -v $PWD:/backup alpine sh -c "rm /var/lib/rancher/* -rf  \
+   && tar zxvf /backup/<BACKUP_FILENAME>.tar.gz"
+     ```
+
+4. Start a new Rancher Server container with the `<PRIOR_VERSION>` tag pointing to the data container.
+    ```
+docker run -d --volumes-from rancher-data-<PRIOR_VERSION> \
+  --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher:<PRIOR_VERSION>
+    ```
+    >**Note:** _Do not_ stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
@@ -25,15 +25,14 @@ docker create --volumes-from <RANCHER_CONTAINER_ID> \
 --name rancher-data rancher/rancher:<RANCHER_CONTAINER_TAG>
    ```

-1. <a id="backup"></a>Create another container of your current Rancher data. However, this container is a backup for restoring your Rancher Server if your upgrade is unsuccessful. Name the container `rancher-data-snapshot-<CURRENT_VERSION>`.
+1. <a id="backup"></a>Create a backup tar ball of your current Rancher data. If you need to rollback, use this backup tar ball.

-    - Replace `<RANCHER_CONTAINER_ID>` with the same ID from the previous step.
-    - Replace `<CURRENT_VERSION>` with the tag for the version of Rancher currently installed.
-    - Replace `<RANCHER_CONTAINER_TAG>` with the version of Rancher that you are currently running, as mentioned in the  [prerequisite](#prereq).
+    - Replace `<RANCHER_VERSION>` with the tag for the version of Rancher currently installed.

    ```
-docker create --volumes-from <RANCHER_CONTAINER_ID> \
--name rancher-data-snapshot-<CURRENT_VERSION> rancher/rancher:<RANCHER_CONTAINER_TAG>
+docker run  --volumes-from rancher-data -v $PWD:/backup \
+alpine tar zcvf /backup/rancher-data-backup-<RANCHER_VERSION>.tar.gz \
+/var/lib/rancher
    ```

 1. Pull the most recent image of Rancher.
@@ -43,7 +42,7 @@ docker pull rancher/rancher:latest
    ```

    >**Attention Air Gap Users:**
-    > If you are visiting this page to complete [Air Gap Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrade-scenarios/air-gap-upgrade/), prepend your private registry URL to the image when running the `docker run` command.
+    > If you are visiting this page to complete [Air Gap Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/air-gap-upgrade), prepend your private registry URL to the image when running the `docker run` command.
    >
    > Example: `<registry.yourdomain.com:port>/rancher/rancher:latest`
    >
@@ -67,4 +66,4 @@ docker run -d --volumes-from rancher-data --restart=unless-stopped \

 **Result:** Rancher Server is upgraded to the latest version.

->**Note:** If your upgrade does not complete successfully, you can roll Rancher Server and its data back to its last healthy state. For more information, see [Restoring Backups—Single Node Installs]({{< baseurl >}}/rancher/v2.x/en/upgrades/restorations/single-node-restoration/).
+>**Note:** If your upgrade does not complete successfully, you can roll Rancher Server and its data back to its last healthy state. For more information, see [Restoring Backups—Single Node Installs]({{< baseurl >}}/rancher/v2.x/en/backups/restorations/single-node-restoration/).
@@ -6,18 +6,22 @@ aliases:
  - /rancher/v2.x/en/tasks/user-settings/api-keys/
 ---

-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.
+## API Keys and User Authentication

-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.
+If you want to access your Rancher clusters, projects, or other objects using external applications, you can do so using the Rancher API. However, before your application can access the API, you must provide the app with a key used to authenticate with Rancher. You can obtain a key using the Rancher UI.

-### API Keys and User Authentication
+An API key is also required for using Rancher CLI.

-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.
+API Keys are composed of four components:

-### Creating an API Key
-Create a Rancher API key so that other applications can make requests to the Rancher API. You can create API keys using the Rancher UI.
+- **Endpoint:** This is the IP address and path that other applications use to send requests to the Rancher API.
+- **Access Key:** The token's username.
+- **Secret Key:** The token's password. For applications that prompt you for two different strings for API authentication, you usually enter the two keys together.
+- **Bearer Token:** The token username and password concatenated together. Use this string for applications that prompt you for one authentication string.

-1. From any Rancher view, select **User Avatar** > **API & Keys** from the menu on the upper-right.
+## Creating an API Key
+
+1. Select **User Avatar** > **API & Keys** from the **User Settings** menu in the upper-right.

 2. Click **Add Key**.

@@ -27,15 +31,21 @@ Create a Rancher API key so that other applications can make requests to the Ran

 4. Click **Create**.

-    **Step Result:** Your API Key is created. Your API **Endpoint**, **Access Key**, **Secret Key**, and **Bearer Token** are displayed. The **Bearer Token** is your **Access Key** and **Secret Key** concatenated together.
+    **Step Result:** Your API Key is created. Your API **Endpoint**, **Access Key**, **Secret Key**, and **Bearer Token** are displayed.

    Use the **Bearer Token** to authenticate with Rancher CLI.

 5. Copy the information displayed to a secure location. This information is only displayed once, so if you lose your key, you'll have to make a new one.

-### Deleting API Keys
+## What's Next?

-You should delete API keys:
+- Enter your API key information into the application that will send requests to the Rancher API.
+- Learn more about the Rancher endpoints and parameters by selecting **View in API** for an object in the Rancher UI.
+- API keys are used for API calls and [Rancher CLI]({{< baseurl >}}/rancher/v2.x/en/cli).
+
+## Deleting API Keys
+
+If you need to revoke an API key, delete it. You should delete API keys:

 - That may have been compromised.
 - That have expired.
@@ -1,5 +1,36 @@
 ---
 title: Managing Node Templates
 weight: 7010
-draft: true
 ---
+
+when you provision a [node pool]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools) cluster, [node templates]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) are used to provision the cluster nodes. These templates use Docker Machine commands to configure an operating system image and setting/parameters for the node. You can create node templates in two contexts:
+
+- While [provisioning a node pool cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools).
+- At any time, from your [user settings](#creating-a-node-template-from-user-settings).
+
+When you create a node template, it is bound to your user profile. Node templates cannot be shared among users. You can delete stale node templates that you no longer user from your user settings.
+
+## Creating a Node Template from User Settings
+
+1. From your user settings, select **User Avatar > Node Templates**.
+1. Click **Add Template**.
+1. Select one of the cloud providers available. Then follow the instructions on screen to configure the template.
+
+**Result:** The template is configured. You can use the template later when you [provision a node pool cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools).
+
+## Cloning Node Templates
+
+When creating new node templates from your user settings, you can clone an existing template and quickly update its settings rather than creating a new one from scratch. Cloning templates saves you the hassle of re-entering access keys for the cloud provider.
+
+1. From your user settings, select **User Avatar > Node Templates**.
+1. Find the template you want to clone. Then select **Ellipsis > Clone**.
+1. Complete the rest of the form.
+
+**Result:** The template is cloned and configured. You can use the template later when you [provision a node pool cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools).
+
+## Deleting a Node Template
+
+When you no longer use a node template, you can delete it from your user settings.
+
+1. From your user settings, select **User Avatar > Node Templates**.
+1. Select one or more template from the list. Then click **Delete**. Confirm the delete when prompted.
@@ -1,6 +1,6 @@
 ---
 title: Add-Ons
-weight: 250
+weight: 260
 ---

 RKE supports pluggable add-ons. Add-ons are used to deploy several cluster components including:
@@ -1,6 +1,6 @@
 ---
 title: Ingress Controllers
-weight: 252
+weight: 262
 ---

 By default, RKE deploys the nginx ingress controller on all schedulable nodes.
@@ -1,6 +1,6 @@
 ---
 title: Network Plug-ins
-weight: 251
+weight: 261
 ---

 RKE supports the following network plug-ins that are deployed as add-ons:
@@ -1,6 +1,6 @@
 ---
 title: User-Defined Add-Ons
-weight: 253
+weight: 263
 ---

 Besides the [network plug-in]({{< baseurl >}}/rke/v0.1.x/en/config-options/network-plugins/) and [ingress controllers]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controllers/), you can define any add-on that you want deployed after the Kubernetes cluster is deployed.
@@ -1,385 +1,14 @@
 ---
 title: Cloud Providers
-weight: 245
+weight: 250
 ---

-RKE supports the ability to set your specific [cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/) for your Kubernetes cluster. There are specific cloud configurations  for these cloud providers:
+RKE supports the ability to set your specific [cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/) for your Kubernetes cluster. There are specific cloud configurations for these cloud providers.
+To enable a cloud provider its name as well as any required configuration options must be provided under the `cloud_provider` directive in the cluster YML.

-* [AWS](#aws)
-* [Azure](#azure)
-* [OpenStack](#openstack)
-* [vSphere](#vsphere)
+* [AWS]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/aws)
+* [Azure]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/azure)
+* [OpenStack]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/openstack)
+* [vSphere]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere)

-Outside of this list, RKE also supports the ability to handle any [custom cloud provider](#custom-cloud-provider).
-
-The `cloud_provider` directive must be filled out with minimally a name. For each cloud provider, there are different configuration options to enable the cloud provider in Kubernetes.
-
-### AWS
-
-To enable the AWS cloud provider, there are no configuration options. You only need to set the name as `aws`. In order to use the AWS cloud provider, all cluster nodes must have already been configured with an appropriate IAM role.
-
-```yaml
-cloud_provider:
-    name: aws
-```
-
-#### IAM Requirements
-
-The nodes used in RKE that will be running the AWS cloud provider must have at least the following IAM policy.
-
-```json
-{
-  "Effect": "Allow",
-  "Action": "ec2:Describe*",
-  "Resource": "*"
-}
-```
-
-In order to use Elastic Load Balancers (ELBs) and EBS with Kubernetes, the node(s) will need to have the an IAM role with appropriate access.
-
-##### Example Policy for IAM Role:
-
-```json
-{
-  "Version": "2012-10-17",
-  "Statement": [
-    {
-      "Effect": "Allow",
-      "Action": "ec2:Describe*",
-      "Resource": "*"
-    },
-    {
-      "Effect": "Allow",
-      "Action": "ec2:AttachVolume",
-      "Resource": "*"
-    },
-    {
-      "Effect": "Allow",
-      "Action": "ec2:DetachVolume",
-      "Resource": "*"
-    },
-    {
-      "Effect": "Allow",
-      "Action": ["elasticloadbalancing:*"],
-      "Resource": ["*"]
-    }
-  ]
-}
-```
-
-### Azure
-
-To enable the Azure cloud provider, besides setting the name as `azure`, there are specific configuration options that must be set. Additionally, the Azure node name must also match the Kubernetes node name.
-
-```yaml
-cloud_provider:
-    name: azure
-    azureCloudProvider:
-      aadClientId: xxxxxxxxx
-      aadClientSecret: xxxxxxxxx
-      location: xxxxxxxxx
-      resourceGroup: xxxxxxxxx
-      subnetName: xxxxxxxxx
-      subscriptionId: xxxxxxxxx
-      vnetName: xxxxxxxxx
-      tenantId: xxxxxxxxx
-      securityGroupName: xxxxxxxxx
-```
-
-#### Overriding the hostname
-
-Since the Azure node name must match the Kubernetes node name, you override the Kubernetes name on the node by setting the `hostname_override` for each node. If you do not set the `hostname_override`, the Kubernetes node name will be set as the `address`, which will cause the Azure cloud provider to fail.
-
-```yaml
-nodes:
-    - address: x.x.x.x
-      hostname_override: azure-rke1
-      user: ubuntu
-      role:
-        - controlplane
-        - etcd
-        - worker
-```
-
-#### Azure Configuration Options
-
-Besides the minimum set of options, there are many other options that are supported in RKE:
-
-|   Azure Configuration Options |  Type  	| Required  |
-|:----------------------------:	|:------:	|:---------:|
-|           tenantId           	| string 	|   *    |
-|        subscriptionId        	| string 	|   *    |
-|          aadClientId         	| string 	|   *    |
-|        aadClientSecret       	| string 	|   *    |
-|             cloud            	| string 	|      |
-|         resourceGroup        	| string 	|      |
-|           location           	| string 	|      |
-|           vnetName           	| string 	|      |
-|       vnetResourceGroup      	| string 	|      |
-|          subnetName          	| string 	|      |
-|       securityGroupName      	| string 	|      |
-|        routeTableName        	| string 	|      |
-|  primaryAvailabilitySetName  	| string 	|      |
-|            vmType            	| string 	|      |
-|      primaryScaleSetName     	| string 	|      |
-|       aadClientCertPath      	| string 	|      |
-|     aadClientCertPassword    	| string 	|      |
-|     cloudProviderBackoff     	|  bool  	|      |
-|  cloudProviderBackoffRetries 	|   int  	|      |
-| cloudProviderBackoffExponent 	|   int  	|      |
-| cloudProviderBackoffDuration 	|   int  	|      |
-|  cloudProviderBackoffJitter  	|   int  	|      |
-|    cloudProviderRateLimit    	|  bool  	|      |
-|   cloudProviderRateLimitQPS  	|   int  	|      |
-| cloudProviderRateLimitBucket 	|   int  	|      |
-|      useInstanceMetadata     	|  bool  	|      |
-|  useManagedIdentityExtension 	|  bool  	|      |
-| maximumLoadBalancerRuleCount 	|   int  	|      |
-
-### Openstack
-
-To enable the Openstack cloud provider, besides setting the name as `openstack`, there are specific configuration options that must be set. The Openstack configuration options are grouped into different sections.
-
-```yaml
-cloud_provider:
-    name: openstack
-    openstackCloudProvider:
-      global:
-        username: xxxxxxxxxxxxxx
-        password: xxxxxxxxxxxxxx
-        auth-url: https://1.2.3.4/identity/v3
-        tenant-id: xxxxxxxxxxxxxx
-        domain-id: xxxxxxxxxxxxxx
-      load_balancer:
-        subnet-id: xxxxxxxxxxxxxx
-      block_storage:
-        ignore-volume-az: true
-      route:
-        router-id: xxxxxxxxxxxxxx
-      metadata:
-        search-order: xxxxxxxxxxxxxx
-```
-
-#### Overriding the hostname
-
-The OpenStack cloud provider uses the instance name (as determined from OpenStack metadata) as the name of the Kubernetes Node object, you must override the Kubernetes name on the node by setting the `hostname_override` for each node. If you do not set the `hostname_override`, the Kubernetes node name will be set as the `address`, which will cause the Openstack cloud provider to fail.
-
-#### Openstack Configuration Options
-
-The Openstack configuration options are divided into 5 groups.
-
-* Global
-* Load Balancer
-* Block Storage
-* Route
-* Metadata
-
-##### Global
-
-These are the options that are available under the `global` directive.
-
-| OpenStack's Global Configuration Options 	|  Type  	| Required  |
-|:--------------------:	|:------:	|:---------:|
-|       auth_url       	| string 	|   *   |
-|       username       	| string 	|   *   |
-|        user-id       	| string 	|   *   |
-|       password       	| string 	|   *   |
-|       tenant-id      	| string 	|   *   |
-|      tenant-name     	| string 	|      |
-|       trust-id       	| string 	|      |
-|       domain-id      	| string 	|      |
-|      domain-name     	| string 	|      |
-|        region        	| string 	|      |
-|        ca-file       	| string 	|      |
-
-##### Load Balancer
-
-These are the options that are available under the `load_balancer` directive.
-
-|  OpenStack's Load Balancer Configuration Options  	|  Type  	| Required |
-|:----------------------:	|:------:	|:---------:|
-|       lb-version       	| string 	|      |
-|       use-octavia      	|  bool  	|      |
-|        subnet-id       	| string 	|      |
-|   floating-network-id  	| string 	|      |
-|        lb-method       	| string 	|      |
-|       lb-provider      	| string 	|      |
-| manage-security-groups 	|  bool  	|      |
-|     create-monitor     	|  bool  	|      |
-|      monitor-delay     	|   int  	|   * if `create-monitor` is true   |
-|     monitor-timeout    	|   int  	|   * if `create-monitor` is true    |
-|   monitor-max-retries  	|   int  	|   * if `create-monitor` is true   |
-
-
-##### Block Storage
-
-These are the options that are available under the `block_storage` directive.
-
-| OpenStack's Block Storage Configuration Options 	|  Type  	| Required |
-|:--------------------:	|:------:	|:---------:|
-|      bs-version      	| string 	|      |
-|   trust-device-path  	|  bool  	|      |
-|   ignore-volume-az   	|  bool  	|      |
-
-##### Route
-
-This is the option that is available under the `route` directive.
-
-| OpenStack's Route Configuration Option 	|  Type  	| Required |
-|:--------------------:	|:------:	|:---------:|
-|       router-id      	| string 	|      |
-
-##### Metadata
-
-These are the options that are available under the `metadata` directive.
-
-| OpenStack's Metadata Configuration Options 	|  Type  	| Required |
-|:--------------------:	|:------:	|:---------:|
-|     search-order     	| string 	|      |
-|    request-timeout   	|   int  	|      |
-
-For more information of Openstack configurations options please refer to the official Kubernetes [documentation](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#openstack).
-
-### vSphere
-
-To enable the vSphere cloud provider, besides setting the name as `vsphere`, there are specific configuration options that must be set. The vSphere configuration options are grouped into different sections.
-
-```yaml
-cloud_provider:
-    name: vsphere
-    vsphereCloudProvider:
-      global:
-        user: user
-        password: pass
-        server: 1.2.3.4
-        port: 22
-      virtual_center:
-        1.2.3.4:
-          user: test
-          password: test
-          port: test
-        5.6.7.8:
-          user: test
-          password: test
-          port: test
-      workspace:
-        server: test.test.com
-        datacenter: test
-        folder: test
-        default-datastore: test
-        resourcepool-path: test
-      network:
-        public-network: xxxxxxxxxxxxxx
-      disk:
-        scsicontrollertype: xxxxxxxxxxxxxx
-```
-
-#### vSphere Configuration Options
-
-The vSphere configuration options are divided into 5 groups.
-
-* Global
-* Virtual Center
-* Workspace
-* Network
-* Disk
-
-##### Global
-
-These are the options that are available under the `global` directive.
-
-| vSphere's Global Configuration Options 	|  Type  	| Required |
-|:--------------------:	|:------:	|:---------:|
-|       user       	| string 	|      |
-|       password       	| string 	|      |
-|        server       	| string 	|      |
-|       port       	| string 	|      |
-|       insecure-flag      	| bool 	|      |
-|      datacenter     	| string 	|      |
-|       datacenters       	| string 	|      |
-|       datastore      	| string 	|      |
-|      working-dir    	| string 	|      |
-|        soap-roundtrip-count        	| int 	|      |
-|        vm-uuid       	| string 	|      |
-|vm-name   |string   |      |
-
-
-##### Virtual Center
-
-These are the options that are available under `virtual_center`, which is a dictionary of vCenters. Each vCenter is defined individually.
-
-```yaml
-virtual_center:
-    <vcenter1-ip>:
-      user: test
-      password: test
-      port: test
-    <vcenter2-ip>:
-      user: test
-      password: test
-      port: test
-```
-
-For each `virtual_center`, these are the available configuration options to be used under the each virtual center. The virtual center's are separated from each other based on their IP.
-
-| vSphere's Virtual Center Configuration Options 	|  Type  	| Required |
-|:--------------------:	|:------:	|:---------:|
-|       user       	| string 	|   * if `global` `user` is not set   |
-|       password       	| string 	| * if `global` `password` is not set  |
-|       port       	| string 	|      |
-|       datacenters       	| string 	|      |
-|        soap-roundtrip-count        	| int 	|      |
-
-##### Workspace
-
-These are the options that are available under the `workspace` directive.
-
-| vSphere's Workspace Configuration Options 	|  Type  	| Required |
-|:--------------------:	|:------:	|:---------:|
-|     server    	| string 	|   *   |
-|    datacenter  	|   string  	|   *   |
-| folder  | string  |   *   |
-| default-datastore | string  |   *   |
-|  resourcepool-path | string  |   *   |
-
-##### Network
-
-This is the option that is available under the `network` directive.
-
-| vSphere's Network Configuration Option	|  Type  	| Required |
-|:--------------------:	|:------:	|:---------:|
-|      public-network     	| string 	|      |
-
-##### Disk
-
-This is the option that is available under the `disk` directive.
-
-| vSphere's Disk Configuration Option 	|  Type  	| Required |
-|:--------------------:	|:------:	|:---------:|
-|       scsicontrollertype      	| string 	|      |
-
-### Custom Cloud Provider
-
-If you want to enable a different cloud provider, RKE allows for custom cloud provider options. A name must be provided and the custom Cloud Provider options can be passed in as a multiline string in `customCloudProvider`.
-
-For example, in order to use the oVirt cloud provider with Kubernetes, here's the following cloud provider information:
-
-```
-[connection]
-uri = https://localhost:8443/ovirt-engine/api
-username = admin@internal
-password = admin
-```
-
-To add this cloud config file to RKE, the `cloud_provider` would be need to be set.
-
-```yaml
-cloud_provider:
-    name: ovirt
-    # Note the pipe as this is what indicates a multiline string
-    customCloudProvider: |-
-      [connection]
-      uri = https://localhost:8443/ovirt-engine/api
-      username = admin@internal
-      password = admin
-```
+Outside of this list, RKE also supports the ability to handle any [custom cloud provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/custom).
@@ -0,0 +1,55 @@
+---
+title: AWS Cloud Provider
+weight: 251
+---
+
+To enable the AWS cloud provider, there are no configuration options. You only need to set the name as `aws`. In order to use the AWS cloud provider, all cluster nodes must have already been configured with an appropriate IAM role.
+
+```yaml
+cloud_provider:
+    name: aws
+```
+
+## IAM Requirements
+
+The nodes used in RKE that will be running the AWS cloud provider must have at least the following IAM policy.
+
+```json
+{
+  "Effect": "Allow",
+  "Action": "ec2:Describe*",
+  "Resource": "*"
+}
+```
+
+In order to use Elastic Load Balancers (ELBs) and EBS with Kubernetes, the node(s) will need to have the an IAM role with appropriate access.
+
+## Example Policy for IAM Role:
+
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Effect": "Allow",
+      "Action": "ec2:Describe*",
+      "Resource": "*"
+    },
+    {
+      "Effect": "Allow",
+      "Action": "ec2:AttachVolume",
+      "Resource": "*"
+    },
+    {
+      "Effect": "Allow",
+      "Action": "ec2:DetachVolume",
+      "Resource": "*"
+    },
+    {
+      "Effect": "Allow",
+      "Action": ["elasticloadbalancing:*"],
+      "Resource": ["*"]
+    }
+  ]
+}
+```
@@ -0,0 +1,71 @@
+---
+title: Azure Cloud Provider
+weight: 252
+---
+
+To enable the Azure cloud provider, besides setting the name as `azure`, there are specific configuration options that must be set. Additionally, the Azure node name must also match the Kubernetes node name.
+
+```yaml
+cloud_provider:
+    name: azure
+    azureCloudProvider:
+      aadClientId: xxxxxxxxx
+      aadClientSecret: xxxxxxxxx
+      location: xxxxxxxxx
+      resourceGroup: xxxxxxxxx
+      subnetName: xxxxxxxxx
+      subscriptionId: xxxxxxxxx
+      vnetName: xxxxxxxxx
+      tenantId: xxxxxxxxx
+      securityGroupName: xxxxxxxxx
+```
+
+## Overriding the hostname
+
+Since the Azure node name must match the Kubernetes node name, you override the Kubernetes name on the node by setting the `hostname_override` for each node. If you do not set the `hostname_override`, the Kubernetes node name will be set as the `address`, which will cause the Azure cloud provider to fail.
+
+```yaml
+nodes:
+    - address: x.x.x.x
+      hostname_override: azure-rke1
+      user: ubuntu
+      role:
+        - controlplane
+        - etcd
+        - worker
+```
+
+## Azure Configuration Options
+
+Besides the minimum set of options, there are many other options that are supported in RKE:
+
+|   Azure Configuration Options |  Type  	| Required  |
+|:----------------------------:	|:------:	|:---------:|
+|           tenantId           	| string 	|   *    |
+|        subscriptionId        	| string 	|   *    |
+|          aadClientId         	| string 	|   *    |
+|        aadClientSecret       	| string 	|   *    |
+|             cloud            	| string 	|      |
+|         resourceGroup        	| string 	|      |
+|           location           	| string 	|      |
+|           vnetName           	| string 	|      |
+|       vnetResourceGroup      	| string 	|      |
+|          subnetName          	| string 	|      |
+|       securityGroupName      	| string 	|      |
+|        routeTableName        	| string 	|      |
+|  primaryAvailabilitySetName  	| string 	|      |
+|            vmType            	| string 	|      |
+|      primaryScaleSetName     	| string 	|      |
+|       aadClientCertPath      	| string 	|      |
+|     aadClientCertPassword    	| string 	|      |
+|     cloudProviderBackoff     	|  bool  	|      |
+|  cloudProviderBackoffRetries 	|   int  	|      |
+| cloudProviderBackoffExponent 	|   int  	|      |
+| cloudProviderBackoffDuration 	|   int  	|      |
+|  cloudProviderBackoffJitter  	|   int  	|      |
+|    cloudProviderRateLimit    	|  bool  	|      |
+|   cloudProviderRateLimitQPS  	|   int  	|      |
+| cloudProviderRateLimitBucket 	|   int  	|      |
+|      useInstanceMetadata     	|  bool  	|      |
+|  useManagedIdentityExtension 	|  bool  	|      |
+| maximumLoadBalancerRuleCount 	|   int  	|      |
@@ -0,0 +1,28 @@
+---
+title: Custom Cloud Provider
+weight: 255
+---
+
+If you want to enable a different cloud provider, RKE allows for custom cloud provider options. A name must be provided and the custom Cloud Provider options can be passed in as a multiline string in `customCloudProvider`.
+
+For example, in order to use the oVirt cloud provider with Kubernetes, here's the following cloud provider information:
+
+```
+[connection]
+uri = https://localhost:8443/ovirt-engine/api
+username = admin@internal
+password = admin
+```
+
+To add this cloud config file to RKE, the `cloud_provider` would be need to be set.
+
+```yaml
+cloud_provider:
+    name: ovirt
+    # Note the pipe as this is what indicates a multiline string
+    customCloudProvider: |-
+      [connection]
+      uri = https://localhost:8443/ovirt-engine/api
+      username = admin@internal
+      password = admin
+```
@@ -0,0 +1,106 @@
+---
+title: Openstack Cloud Provider
+weight: 253
+---
+
+To enable the Openstack cloud provider, besides setting the name as `openstack`, there are specific configuration options that must be set. The Openstack configuration options are grouped into different sections.
+
+```yaml
+cloud_provider:
+    name: openstack
+    openstackCloudProvider:
+      global:
+        username: xxxxxxxxxxxxxx
+        password: xxxxxxxxxxxxxx
+        auth-url: https://1.2.3.4/identity/v3
+        tenant-id: xxxxxxxxxxxxxx
+        domain-id: xxxxxxxxxxxxxx
+      load_balancer:
+        subnet-id: xxxxxxxxxxxxxx
+      block_storage:
+        ignore-volume-az: true
+      route:
+        router-id: xxxxxxxxxxxxxx
+      metadata:
+        search-order: xxxxxxxxxxxxxx
+```
+
+## Overriding the hostname
+
+The OpenStack cloud provider uses the instance name (as determined from OpenStack metadata) as the name of the Kubernetes Node object, you must override the Kubernetes name on the node by setting the `hostname_override` for each node. If you do not set the `hostname_override`, the Kubernetes node name will be set as the `address`, which will cause the Openstack cloud provider to fail.
+
+## Openstack Configuration Options
+
+The Openstack configuration options are divided into 5 groups.
+
+* Global
+* Load Balancer
+* Block Storage
+* Route
+* Metadata
+
+### Global
+
+These are the options that are available under the `global` directive.
+
+| OpenStack's Global Configuration Options 	|  Type  	| Required  |
+|:--------------------:	|:------:	|:---------:|
+|       auth_url       	| string 	|   *   |
+|       username       	| string 	|   *   |
+|        user-id       	| string 	|   *   |
+|       password       	| string 	|   *   |
+|       tenant-id      	| string 	|   *   |
+|      tenant-name     	| string 	|      |
+|       trust-id       	| string 	|      |
+|       domain-id      	| string 	|      |
+|      domain-name     	| string 	|      |
+|        region        	| string 	|      |
+|        ca-file       	| string 	|      |
+
+### Load Balancer
+
+These are the options that are available under the `load_balancer` directive.
+
+|  OpenStack's Load Balancer Configuration Options  	|  Type  	| Required |
+|:----------------------:	|:------:	|:---------:|
+|       lb-version       	| string 	|      |
+|       use-octavia      	|  bool  	|      |
+|        subnet-id       	| string 	|      |
+|   floating-network-id  	| string 	|      |
+|        lb-method       	| string 	|      |
+|       lb-provider      	| string 	|      |
+| manage-security-groups 	|  bool  	|      |
+|     create-monitor     	|  bool  	|      |
+|      monitor-delay     	|   int  	|   * if `create-monitor` is true   |
+|     monitor-timeout    	|   int  	|   * if `create-monitor` is true    |
+|   monitor-max-retries  	|   int  	|   * if `create-monitor` is true   |
+
+
+### Block Storage
+
+These are the options that are available under the `block_storage` directive.
+
+| OpenStack's Block Storage Configuration Options 	|  Type  	| Required |
+|:--------------------:	|:------:	|:---------:|
+|      bs-version      	| string 	|      |
+|   trust-device-path  	|  bool  	|      |
+|   ignore-volume-az   	|  bool  	|      |
+
+### Route
+
+This is the option that is available under the `route` directive.
+
+| OpenStack's Route Configuration Option 	|  Type  	| Required |
+|:--------------------:	|:------:	|:---------:|
+|       router-id      	| string 	|      |
+
+### Metadata
+
+These are the options that are available under the `metadata` directive.
+
+| OpenStack's Metadata Configuration Options 	|  Type  	| Required |
+|:--------------------:	|:------:	|:---------:|
+|     search-order     	| string 	|      |
+|    request-timeout   	|   int  	|      |
+
+For more information of Openstack configurations options please refer to the official Kubernetes [documentation](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#openstack).
@@ -0,0 +1,258 @@
+---
+title: vSphere Cloud Provider
+weight: 254
+---
+
+The [vSphere Cloud Provider](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/) interacts with VMware infrastructure (vCenter or standalone ESXi server) to provision and manage storage for persistent volumes in a Kubernetes cluster.
+
+When provisioning Kubernetes using RKE CLI or using [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) in Rancher, the vSphere Cloud Provider can be enabled by configuring the `cloud_provider` directive in the cluster YAML file.
+
+### Prerequisites
+
+1. You'll need to have credentials of a vCenter/ESXi user account with privileges allowing the cloud provider to interact with the vSphere infrastructure to provision storage. Refer to [this document](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/vcp-roles.html) to create and assign a role with the required permissions in vCenter.
+2. VMware Tools must be running in the Guest OS for all nodes in the cluster.
+3. All nodes must be configured with disk UUIDs. This is required so that attached VMDKs present a consistent UUID to the VM, allowing the disk to be mounted properly. See [Enabling Disk UUIDs](#enabling-disk-uuids-for-vsphere-vms).
+
+## Clusters provisioned with RKE CLI
+
+To enable the vSphere Cloud Provider in the cluster, you must add the top-level `cloud_provider` directive to the cluster configuration file, set the `name` property to `vsphere` and add the `vsphereCloudProvider` directive containing the configuration matching your infrastructure. See the [configuration reference](#configuration-reference) for the gory details.
+
+## Clusters provisioned with Rancher
+
+When provisioning clusters in Rancher using the [vSphere node driver]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/) or on pre-created [custom nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/) the cluster YAML file must be modified in order to enable the cloud provider.
+
+1. Log in to the Rancher UI as admin user.
+2. Navigate to **Clusters** in the **Global** view.
+3. Click **Add Cluster** and select the **vSphere** infrastructure provider.
+4. Assign a **Cluster Name**.
+5. Assign **Member Roles** as required.
+6. Expand **Cluster Options** and configure as required.
+7. Set **Cloud Provider** option to `Custom`.
+    
+    ![vsphere-node-driver-cloudprovider]({{< baseurl >}}/img/rancher/vsphere-node-driver-cloudprovider.png)
+
+8. Click on **Edit as YAML**
+9. Insert the following top-level structure to the pre-populated cluster YAML. Note that the `name` *must* be set to `vsphere`. Refer to the [configuration reference](#configuration-reference) to learn about the properties of the `vsphereCloudProvider` directive.
+
+    ```yaml
+    cloud_provider:
+        name: vsphere
+        vsphereCloudProvider:
+            [Insert provider configuration]
+    ```
+
+10. Configure the **Node Pools** per your requirements while ensuring to use a node template that enables disk UUIDs for the VMs (See [Annex - Enable disk UUIDs for vSphere VMs]).
+11. Click on **Create** to start provisioning the VMs and Kubernetes services.
+
+## Configuration Reference
+
+>  **Note:** This documentation reflects the new vSphere Cloud Provider configuration schema introduced in Kubernetes v1.9 which differs from previous versions.
+
+The vSphere configuration options are divided into 5 groups:
+
+* global
+* virtual_center
+* workspace
+* disk
+* network
+
+### global
+
+The main purpose of global options is to be able to define a common set of configuration parameters that will be inherited by all vCenters defined under the `virtual_center` directive unless explicitely defined there.
+
+Accordingly, the `global` directive accepts the same configuration options that are available under the `virtual_center` directive. Additionally it accepts a single parameter that can only be specified here:
+
+| global Options  |  Type   | Required  | Description |
+|:---------------:|:-------:|:---------:|:-----------------------------------------------------------------------------:|
+| insecure-flag   | boolean |           | Set to **true** if the vCenter/ESXi uses a self-signed certificate.           |
+
+___
+
+**Example:**
+
+```yaml
+(...)
+    global:
+      insecure-flag: true
+```
+
+### virtual_center
+
+This configuration directive specifies the vCenters that are managing the nodes in the cluster. You must define at least one vCenter/ESXi server. If the nodes span multiple vCenters then all must be defined.
+
+Each vCenter is defined by adding a new entry under the `virtual_center` directive with the vCenter IP or FQDN as the name. All required parameters must be provided for each vCenter unless they are already defined under the `global` directive.
+
+| virtual_center Options |  Type    | Required  | Description |
+|:----------------------:|:--------:|:---------:|:-----------------------------------------------------------------------------:|
+| user                   | string	  |   *       | vCenter/ESXi user used to authenticate with this server. |
+| password               | string	  |   *       | User's password. |
+| port                   | string	  |           | Port to use to connect to this server. Defaults to 443.  |
+| datacenters            | string	  |   *       | Comma-separated list of all datacenters in which cluster nodes are running in.|
+| soap-roundtrip-count   | uint     |           | Round tripper count for API requests to the vCenter (num retries = value - 1).|
+
+
+> The following additional options (introduced in Kubernetes v1.11) are not yet supported in RKE.
+
+| virtual_center Options |  Type    | Required  | Description |
+|:----------------------:|:--------:|:---------:|:-----------------------------------------------------------------------------:|
+| secret-name            | string   |           | Name of secret resource containing credential key/value pairs. Can be specified in lieu of user/password parameters.|
+| secret-namespace       | string   |           | Namespace in which the secret resource was created in. |
+| ca-file                | string   |           | Path to CA cert file used to verify the vCenter certificate. |
+
+___
+
+**Example:**
+
+```yaml
+(...)
+    virtual_center:
+      172.158.111.1: {}  # This vCenter inherits all it's properties from global options
+      172.158.110.2:     # All required options are set explicitly
+        user: vc-user
+        password: othersecret
+        datacenters: eu-west-2
+```
+
+### workspace
+
+This configuration group specifies how storage for volumes is created in vSphere.
+The following configuration options are available:
+
+| workspace Options      |  Type    | Required  | Description |
+|:----------------------:|:--------:|:---------:|:-----------------------------------------------------------------------------:|
+| server                 | string   |   *       | IP or FQDN of the vCenter/ESXi that should be used for creating the volumes. Must match one of the vCenters defined under the `virtual_center` directive.|
+| datacenter             | string   |   *       | Name of the datacenter that should be used for creating volumes. For ESXi enter *ha-datacenter*.|
+| folder                 | string   |   *       | Path of folder in which to create dummy VMs used for volume provisioning (relative from the root of the datastore), e.g. "kubernetes".|
+| default-datastore      | string   |           | Name of default datastore to place VMDKs if neither datastore or storage policy are specified in the volume options of a PVC. If datastore is located in a storage folder or is a member of a datastore cluster, specify the full path. |
+| resourcepool-path      | string   |           | Absolute or relative path to the resource pool where the dummy VMs for [Storage policy based provisioning](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html) should be created. If a relative path is specified, it is resolved with respect to the datacenter's *host* folder. Examples: `/<dataCenter>/host/<hostOrClusterName>/Resources/<poolName>`, `Resources/<poolName>`. For standalone ESXi specify `Resources`.|
+
+___
+
+**Example:**
+
+```yaml
+(...)
+    workspace:
+      server: 172.158.111.1 # matches IP of vCenter defined in the virtual_center block
+      datacenter: eu-west-1
+      folder: k8s-dummy
+      default-datastore: ds-1
+```
+
+### disk
+
+The following configuration options are available under the disk directive:
+
+| disk Options         |  Type    | Required  | Description |
+|:--------------------:|:--------:|:---------:|:-----------------------------------------------------------------------------:|
+| scsicontrollertype   | string   |           | SCSI controller type to use when attaching block storage to VMs. Must be one of: *lsilogic-sas* or *pvscsi*. Default: *pvscsi*.|
+
+___
+
+### network 
+
+The following configuration options are available under the network directive:
+
+| network Options     |  Type    | Required  | Description |
+|:-------------------:|:--------:|:---------:|:-----------------------------------------------------------------------------:|
+| public-network      | string   |           | Name of public **VM Network** to which the VMs in the cluster are connected. Used to determine public IP addresses of VMs.|
+
+
+##  Configuration Example
+
+Given the following:
+
+- VMs in the cluster are running in the same datacenter `eu-west-1` managed by the vCenter `vc.example.com`.
+- The vCenter has a user `provisioner` with password `secret` with the required roles assigned, see [Prerequisites](#prerequisites).
+- The vCenter has a datastore named `ds-1` which should be used to store the VMDKs for volumes.
+- A `k8s-dummy` folder exists in the root of the datastore.
+
+The corresponding configuration for the provider would then be as follows:
+
+```yaml
+(...)
+cloud_provider:
+  name: vsphere
+  vsphereCloudProvider:
+    virtual_center:
+      vc.example.com:
+        user: provisioner
+        password: secret
+        datacenters: eu-west-1
+    workspace:
+      server: vc.example.com
+      folder: k8s-dummy
+      default-datastore: ds-1
+      datacenter: eu-west-1
+    
+```
+
+## Annex
+
+### Enabling disk UUIDs for vSphere VMs
+
+Depending on whether you are provisioning the VMs using the [vSphere node driver]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere) in Rancher or using your own scripts or third-party tools, there are different methods available to enable disk UUIDs for VMs.
+
+#### Using the Vsphere Console
+
+The required property can be set while creating or modifying VMs in the vSphere Console:
+
+1. For each VM navigate to the tab **VM Options** and click on **Edit Configuration**.
+2. Add the parameter `disk.EnableUUID` with a value of **TRUE**.
+
+    ![vsphere-advanced-parameters]({{< baseurl >}}/img/rke/vsphere-advanced-parameters.png)
+
+#### Using the GOVC CLI tool
+
+You can also modify properties of VMs with the [govc](https://github.com/vmware/govmomi/tree/master/govc) command-line tool to enable disk UUIDs:
+
+```sh
+$ govc vm.change -vm <vm-path> -e disk.enableUUID=TRUE
+```
+
+#### Using Rancher node template
+
+When creating new clusters in Rancher using vSphere node templates, you can configure the template to automatically enable disk UUIDs for all VMs created for a cluster:
+
+1. Navigate to the **Node Templates** in the Rancher UI while logged in as admin user.
+
+2. Add or edit an existing vSphere node template.
+
+3. Under **Instance Options** click on **Add Parameter**.
+
+4. Enter `disk.enableUUID` as key with a value of **TRUE**.
+
+    ![vsphere-nodedriver-enable-uuid]({{< baseurl >}}/img/rke/vsphere-nodedriver-enable-uuid.png)
+
+5. Click **Create** or **Save**.
+
+### Troubleshooting
+
+If you are experiencing issues while provisioning a cluster with enabled vSphere Cloud Provider or while creating vSphere volumes for your workloads, you should inspect the logs of the following K8s services:
+
+- controller-manager (Manages volumes in vCenter)
+- kubelet: (Mounts vSphere volumes to pods)
+
+If your cluster is not configured with external [Cluster Logging]({{< baseurl >}}/rancher/v2.x/en/tools/logging/), you will need to SSH into nodes to get the logs of the `kube-controller-manager` (running on one of the control plane nodes) and the `kubelet` (pertaining to the node where the stateful pod has been scheduled).
+
+The easiest way to create a SSH session with a node is the Rancher CLI tool.
+
+1. [Configure the Rancher CLI]({{< baseurl >}}/rancher/v2.x/en/cli/) for your cluster.
+2. Run the following command to get a shell to the corresponding nodes:
+
+    ```sh
+$ rancher ssh <nodeName>
+    ```
+
+3. Inspect the logs of the controller-manager and kubelet containers looking for errors related to the vSphere cloud provider:
+    
+    ```sh
+    $ docker logs --since 15m kube-controller-manager
+    $ docker logs --since 15m kubelet
+    ```
+
+
+### Related Links
+
+- [vSphere Storage for Kubernetes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)
+- [Kubernetes Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
@@ -73,20 +73,28 @@ Instead of setting the path to the SSH key, you can alternatively specify the ac

 You can specify the list of roles that you want the node to be as part of the Kubernetes cluster. Three roles are supported: `controlplane`, `etcd` and `worker`. Node roles are not mutually exclusive. It's possible to assign any combination of roles to any node. It's also possible to change a node's role using the upgrade process.

+> **Note:** Prior to v0.1.8, workloads/pods might have run on any nodes with `worker` or `controlplane` roles, but as of v0.1.8, they will only be deployed to any `worker` nodes.
+
 * **etcd**

-With this role, the `etcd` container will be run on these nodes.  Etcd keeps the state of your cluster and is the most important component in your cluster, single source of truth of your cluster. Although you can run etcd on just one node, it typically takes 3, 5 or more nodes to create an HA configuration. Etcd is a distributed reliable key-value store which stores all Kubernetes state.
+With this role, the `etcd` container will be run on these nodes.  Etcd keeps the state of your cluster and is the most important component in your cluster, single source of truth of your cluster. Although you can run etcd on just one node, it typically takes 3, 5 or more nodes to create an HA configuration. Etcd is a distributed reliable key-value store which stores all Kubernetes state. [Taint set on nodes](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) with the **etcd** role is shown below:
+
+Taint Key                              | Taint Value  | Taint Effect
+---------------------------------------|--------------|--------------
+`node-role.kubernetes.io/etcd`         | `true`       | `NoExecute`

 * **controlplane**

-With this role, the stateless components that are used to deploy Kubernetes will run on these nodes. These components are used to run the API server, scheduler, and controllers.
+With this role, the stateless components that are used to deploy Kubernetes will run on these nodes. These components are used to run the API server, scheduler, and controllers. [Taint set on nodes](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) with the **controlplane** role is shown below:
+
+Taint Key                              | Taint Value  | Taint Effect
+---------------------------------------|--------------|--------------
+`node-role.kubernetes.io/controlplane` | `true`       | `NoSchedule`

 * **worker**

 With this role, any workloads or pods that are deployed will land on these nodes.

-> **Note:** Prior to v0.1.8, workloads/pods might have run on any nodes with `worker` or `controlplane` roles, but as of v0.1.8, they will only be deployed to any `worker` nodes.
-
 ### Docker Socket

 If the Docker socket is different than the default, you can set the `docker_socket`. The default is `/var/run/docker.sock`
@@ -5,7 +5,7 @@ weight: 230

 To deploy Kubernetes, RKE deploys several core components or services in Docker containers on the nodes. Based on the roles of the node, the containers deployed may be different.

-**All services support additional [custom arguments, Docker mount binds and extra environment variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services-extra).**
+**All services support additional [custom arguments, Docker mount binds and extra environment variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/).**

 ## etcd

@@ -17,6 +17,8 @@ By default, RKE will deploy a new etcd service, but you can also run Kubernetes

 ## Kubernetes API Server

+> **Note for Rancher 2 users** If you are configuring Cluster Options using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) when creating [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the names of services should contain underscores only: `kube_api`. This only applies to Rancher v2.0.5 and v2.0.6.
+
 The [Kubernetes API](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) REST service, which handles requests and data for all Kubernetes objects and provide shared state for all the other Kubernetes components.

 ```yaml
@@ -42,7 +44,7 @@ RKE supports the following options for the `kube-api` service :

 ## Kubernetes Controller Manager

- kube-controller
+> **Note for Rancher 2 users** If you are configuring Cluster Options using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) when creating [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the names of services should contain underscores only: `kube_controller`. This only applies to Rancher v2.0.5 and v2.0.6.

 The [Kubernetes Controller Manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) service is the component responsible for running Kubernetes main control loops. The controller manager monitors the cluster desired state through the Kubernetes API server and makes the necessary changes to the current state to reach the desired state.

@@ -7,6 +7,8 @@ aliases:

 There are lots of different [configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) that can be set in the cluster configuration file for RKE. Here are some examples of files:

+> **Note for Rancher 2 users** If you are configuring Cluster Options using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) when creating [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the names of services should contain underscores only: `kube_api` and `kube_controller`. This only applies to Rancher v2.0.5 and v2.0.6.
+
 ## Minimal `cluster.yml` example

 ```yaml
@@ -118,6 +120,7 @@ services:
      #   -----BEGIN PRIVATE KEY-----
      #   xxxxxxxxxx
      #   -----END PRIVATE KEY-----
+    # Note for Rancher 2 users: If you are configuring Cluster Options using a Config File when creating Rancher Launched Kubernetes, the names of services should contain underscores only: `kube_api`. This only applies to Rancher v2.0.5 and v2.0.6.
    kube-api:
      # IP range for any services created on Kubernetes
      # This must match the service_cluster_ip_range in kube-controller
@@ -134,6 +137,7 @@ services:
        delete-collection-workers: 3
        # Set the level of log output to debug-level
        v: 4
+    # Note for Rancher 2 users: If you are configuring Cluster Options using a Config File when creating Rancher Launched Kubernetes, the names of services should contain underscores only: `kube_controller`. This only applies to Rancher v2.0.5 and v2.0.6.
    kube-controller:
      # CIDR pool used to assign IP addresses to pods in the cluster
      cluster_cidr: 10.42.0.0/16
@@ -218,3 +218,25 @@ nginx-65899c769f-kcdpr   1/1       Running   0          17s
 nginx-65899c769f-pc45c   1/1       Running   0          17s
 nginx-65899c769f-qkhml   1/1       Running   0          17s
 ```
+
+## Troubleshooting
+
+As of **v0.1.8** and below, the **rke-bundle-cert** container is left over from a failed etcd restore. If you are having an issue with restoring an **etcd snapshot** then you can do the following on each etcd nodes before attempting to do another restore:
+
+```
+docker container rm --force rke-bundle-cert
+```
+
+The rke-bundle-cert container is usually removed when a backup or restore of **etcd** succeeds.
+Whenever something goes wrong, the **rke-bundle-cert** container will be left over. You can look
+at the logs or inspect the container to see what the issue is.
+
+```
+docker container logs --follow rke-bundle-cert
+docker container inspect rke-bundle-cert
+```
+
+The important thing to note is the mounts of the container and location of the **pki.bundle.tar.gz**.
+
+As of **v0.1.9**, the **rke-bundle-cert** container is removed on both success and
+failure of a restore. To debug any issues, you will need to look at the **logs** generated from rke.
@@ -25,8 +25,16 @@ In order to remove the Kubernetes components from nodes, you use the `rke remove

 This command does the following to each node in the `cluster.yml`:

+- Remove the Kubernetes component deployed on it
+  - `etcd`
+  - `kube-apiserver`
+  - `kube-controller-manager`
+  - `kubelet`
+  - `kube-proxy`
+  - `nginx-proxy`
+
+> **Note:** Pods are not removed from the nodes. If the node is re-used, the pods will automatically be removed when the new Kubernetes cluster is created.

- Remove the Kubernetes services deployed on it
 - Clean each host from the directories left by the services:
  - /etc/kubernetes/ssl
  - /var/lib/etcd
@@ -15,9 +15,51 @@ RKE runs on almost any Linux OS with Docker installed. Most of the development a

 - Swap should be disabled on any worker nodes

-### RedHat Enterprise Linux (RHEL) / CentOS
+- Following kernel modules should be present

-If using RedHat Enterprise Linux or CentOS, you cannot use the `root` user as [SSH user]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/#ssh-user) due to [Bugzilla 1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). Please follow the instructions below how to setup Docker correctly, based on the way you installed Docker on the node.
+Module name |
+------------|
+br_netfilter |
+ip6_udp_tunnel |
+ip_set |
+ip_set_hash_ip |
+ip_set_hash_net |
+iptable_filter |
+iptable_nat |
+iptable_mangle |
+iptable_raw |
+nf_conntrack_netlink |
+nf_conntrack |
+nf_conntrack_ipv4 |
+nf_defrag_ipv4 |
+nf_nat |
+nf_nat_ipv4 |
+nf_nat_masquerade_ipv4 |
+nfnetlink |
+udp_tunnel |
+veth |
+vxlan |
+x_tables |
+xt_addrtype |
+xt_conntrack |
+xt_comment |
+xt_mark |
+xt_multiport |
+xt_nat |
+xt_recent |
+xt_set |
+xt_statistic |
+xt_tcpudp |
+
+- Following sysctl settings must be applied
+
+```
+net.bridge.bridge-nf-call-iptables=1
+```
+
+### RedHat Enterprise Linux (RHEL) / Oracle Enterprise Linux (OEL) / CentOS
+
+If using RedHat Enterprise Linux, Oracle Enterprise Linux or CentOS, you cannot use the `root` user as [SSH user]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/#ssh-user) due to [Bugzilla 1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). Please follow the instructions below how to setup Docker correctly, based on the way you installed Docker on the node.

 #### Using upstream Docker
 If you are using upstream Docker, the package name is `docker-ce` or `docker-ee`. You can check the installed package by executing:
@@ -1,8 +1,8 @@
 <blockquote>
 	<p><strong>Note:</strong></p>

-		<p>The <code>rancher/rancher</code> container is hosted on <a href="https://hub.docker.com/r/rancher/rancher/tags/">DockerHub</a>. If you don't have access to DockerHub, or you are installing Rancher without an Internet connection, refer to <a href="/rancher/v2.x/en/installation/air-gap-installation/">Air Gap Installation</a>.</p>
+		<p>The <code>rancher/rancher</code> container is hosted on <a href="https://hub.docker.com/r/rancher/rancher/tags/">DockerHub</a>. If you don't have access to DockerHub, or you are installing Rancher without an Internet connection, refer to <a href="/docs/rancher/v2.x/en/installation/air-gap-installation/">Air Gap Installation</a>.</p>
 		<p><strong>Note:</strong></p>
-		<p>For a list of other Rancher Server tags available, refer to <a href="/rancher/v2.x/en/installation/server-tags/">Rancher Server Tags</a>.</p>
+		<p>For a list of other Rancher Server tags available, refer to <a href="/docs/rancher/v2.x/en/installation/server-tags/">Rancher Server Tags</a>.</p>

 </blockquote>
--- a/Show More
+++ b/Show More