diff --git a/.ackrc b/.ackrc
index 29d17e2cb4d..6c11a140dec 100644
--- a/.ackrc
+++ b/.ackrc
@@ -1,3 +1,7 @@
--ignore-dir=public
--ignore-dir=static
--ignore-dir=src/img
+--ignore-dir=src/img
+--type-add=svg:ext:svg
+--no-xml
+--no-svg
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 00000000000..e454a52586f
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,178 @@
+
+ Apache License
+ Version 2.0, January 2004
+ http://www.apache.org/licenses/
+
+ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+ 1. Definitions.
+
+ "License" shall mean the terms and conditions for use, reproduction,
+ and distribution as defined by Sections 1 through 9 of this document.
+
+ "Licensor" shall mean the copyright owner or entity authorized by
+ the copyright owner that is granting the License.
+
+ "Legal Entity" shall mean the union of the acting entity and all
+ other entities that control, are controlled by, or are under common
+ control with that entity. For the purposes of this definition,
+ "control" means (i) the power, direct or indirect, to cause the
+ direction or management of such entity, whether by contract or
+ otherwise, or (ii) ownership of fifty percent (50%) or more of the
+ outstanding shares, or (iii) beneficial ownership of such entity.
+
+ "You" (or "Your") shall mean an individual or Legal Entity
+ exercising permissions granted by this License.
+
+ "Source" form shall mean the preferred form for making modifications,
+ including but not limited to software source code, documentation
+ source, and configuration files.
+
+ "Object" form shall mean any form resulting from mechanical
+ transformation or translation of a Source form, including but
+ not limited to compiled object code, generated documentation,
+ and conversions to other media types.
+
+ "Work" shall mean the work of authorship, whether in Source or
+ Object form, made available under the License, as indicated by a
+ copyright notice that is included in or attached to the work
+ (an example is provided in the Appendix below).
+
+ "Derivative Works" shall mean any work, whether in Source or Object
+ form, that is based on (or derived from) the Work and for which the
+ editorial revisions, annotations, elaborations, or other modifications
+ represent, as a whole, an original work of authorship. For the purposes
+ of this License, Derivative Works shall not include works that remain
+ separable from, or merely link (or bind by name) to the interfaces of,
+ the Work and Derivative Works thereof.
+
+ "Contribution" shall mean any work of authorship, including
+ the original version of the Work and any modifications or additions
+ to that Work or Derivative Works thereof, that is intentionally
+ submitted to Licensor for inclusion in the Work by the copyright owner
+ or by an individual or Legal Entity authorized to submit on behalf of
+ the copyright owner. For the purposes of this definition, "submitted"
+ means any form of electronic, verbal, or written communication sent
+ to the Licensor or its representatives, including but not limited to
+ communication on electronic mailing lists, source code control systems,
+ and issue tracking systems that are managed by, or on behalf of, the
+ Licensor for the purpose of discussing and improving the Work, but
+ excluding communication that is conspicuously marked or otherwise
+ designated in writing by the copyright owner as "Not a Contribution."
+
+ "Contributor" shall mean Licensor and any individual or Legal Entity
+ on behalf of whom a Contribution has been received by Licensor and
+ subsequently incorporated within the Work.
+
+ 2. Grant of Copyright License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ copyright license to reproduce, prepare Derivative Works of,
+ publicly display, publicly perform, sublicense, and distribute the
+ Work and such Derivative Works in Source or Object form.
+
+ 3. Grant of Patent License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ (except as stated in this section) patent license to make, have made,
+ use, offer to sell, sell, import, and otherwise transfer the Work,
+ where such license applies only to those patent claims licensable
+ by such Contributor that are necessarily infringed by their
+ Contribution(s) alone or by combination of their Contribution(s)
+ with the Work to which such Contribution(s) was submitted. If You
+ institute patent litigation against any entity (including a
+ cross-claim or counterclaim in a lawsuit) alleging that the Work
+ or a Contribution incorporated within the Work constitutes direct
+ or contributory patent infringement, then any patent licenses
+ granted to You under this License for that Work shall terminate
+ as of the date such litigation is filed.
+
+ 4. Redistribution. You may reproduce and distribute copies of the
+ Work or Derivative Works thereof in any medium, with or without
+ modifications, and in Source or Object form, provided that You
+ meet the following conditions:
+
+ (a) You must give any other recipients of the Work or
+ Derivative Works a copy of this License; and
+
+ (b) You must cause any modified files to carry prominent notices
+ stating that You changed the files; and
+
+ (c) You must retain, in the Source form of any Derivative Works
+ that You distribute, all copyright, patent, trademark, and
+ attribution notices from the Source form of the Work,
+ excluding those notices that do not pertain to any part of
+ the Derivative Works; and
+
+ (d) If the Work includes a "NOTICE" text file as part of its
+ distribution, then any Derivative Works that You distribute must
+ include a readable copy of the attribution notices contained
+ within such NOTICE file, excluding those notices that do not
+ pertain to any part of the Derivative Works, in at least one
+ of the following places: within a NOTICE text file distributed
+ as part of the Derivative Works; within the Source form or
+ documentation, if provided along with the Derivative Works; or,
+ within a display generated by the Derivative Works, if and
+ wherever such third-party notices normally appear. The contents
+ of the NOTICE file are for informational purposes only and
+ do not modify the License. You may add Your own attribution
+ notices within Derivative Works that You distribute, alongside
+ or as an addendum to the NOTICE text from the Work, provided
+ that such additional attribution notices cannot be construed
+ as modifying the License.
+
+ You may add Your own copyright statement to Your modifications and
+ may provide additional or different license terms and conditions
+ for use, reproduction, or distribution of Your modifications, or
+ for any such Derivative Works as a whole, provided Your use,
+ reproduction, and distribution of the Work otherwise complies with
+ the conditions stated in this License.
+
+ 5. Submission of Contributions. Unless You explicitly state otherwise,
+ any Contribution intentionally submitted for inclusion in the Work
+ by You to the Licensor shall be under the terms and conditions of
+ this License, without any additional terms or conditions.
+ Notwithstanding the above, nothing herein shall supersede or modify
+ the terms of any separate license agreement you may have executed
+ with Licensor regarding such Contributions.
+
+ 6. Trademarks. This License does not grant permission to use the trade
+ names, trademarks, service marks, or product names of the Licensor,
+ except as required for reasonable and customary use in describing the
+ origin of the Work and reproducing the content of the NOTICE file.
+
+ 7. Disclaimer of Warranty. Unless required by applicable law or
+ agreed to in writing, Licensor provides the Work (and each
+ Contributor provides its Contributions) on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ implied, including, without limitation, any warranties or conditions
+ of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+ PARTICULAR PURPOSE. You are solely responsible for determining the
+ appropriateness of using or redistributing the Work and assume any
+ risks associated with Your exercise of permissions under this License.
+
+ 8. Limitation of Liability. In no event and under no legal theory,
+ whether in tort (including negligence), contract, or otherwise,
+ unless required by applicable law (such as deliberate and grossly
+ negligent acts) or agreed to in writing, shall any Contributor be
+ liable to You for damages, including any direct, indirect, special,
+ incidental, or consequential damages of any character arising as a
+ result of this License or out of the use or inability to use the
+ Work (including but not limited to damages for loss of goodwill,
+ work stoppage, computer failure or malfunction, or any and all
+ other commercial damages or losses), even if such Contributor
+ has been advised of the possibility of such damages.
+
+ 9. Accepting Warranty or Additional Liability. While redistributing
+ the Work or Derivative Works thereof, You may choose to offer,
+ and charge a fee for, acceptance of support, warranty, indemnity,
+ or other liability obligations and/or rights consistent with this
+ License. However, in accepting such obligations, You may act only
+ on Your own behalf and on Your sole responsibility, not on behalf
+ of any other Contributor, and only if You agree to indemnify,
+ defend, and hold each Contributor harmless for any liability
+ incurred by, or claims asserted against, such Contributor by reason
+ of your accepting any such warranty or additional liability.
+
+ END OF TERMS AND CONDITIONS
+
diff --git a/README.md b/README.md
index 718b735d447..002b29e77a0 100644
--- a/README.md
+++ b/README.md
@@ -14,3 +14,19 @@ and then navigate to http://localhost:9001/. You can customize the port by pass
```bash
./scripts/dev 8080
```
+
+License
+=======
+Copyright (c) 2014-2019 [Rancher Labs, Inc.](http://rancher.com)
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+[http://www.apache.org/licenses/LICENSE-2.0](http://www.apache.org/licenses/LICENSE-2.0)
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
diff --git a/content/_index.html b/content/_index.html
index 37e3a00796a..19a2a3beaa9 100644
--- a/content/_index.html
+++ b/content/_index.html
@@ -59,7 +59,7 @@ layout: blank
Rancher Kubernetes Engine (RKE) is an extremely simple, lightning fast Kubernetes installer that works everywhere.
diff --git a/content/os/v1.x/en/about/running-rancher-on-rancherOS/_index.md b/content/os/v1.x/en/about/running-rancher-on-rancherOS/_index.md
index 225eed12892..f0fb87544cd 100644
--- a/content/os/v1.x/en/about/running-rancher-on-rancherOS/_index.md
+++ b/content/os/v1.x/en/about/running-rancher-on-rancherOS/_index.md
@@ -37,7 +37,7 @@ rancher:
```
-> **Note:** You can not name the service `rancher-agent` as this will not allow the rancher/agent container to be launched correctly. Please read more about why [you can't name your container as `rancher-agent`](https://rancher.com/docs/rancher/v1.6/en/faqs/agents/#adding-in-name-rancher-agent).
+> **Note:** You can not name the service `rancher-agent` as this will not allow the rancher/agent container to be launched correctly. Please read more about why [you can't name your container as `rancher-agent`]({{< baseurl >}}/rancher/v1.6/en/faqs/agents/#adding-in-name-rancher-agent).
### Adding in Host Labels
diff --git a/content/rancher/v2.x/en/_index.md b/content/rancher/v2.x/en/_index.md
index c6ca60961bb..ac450e030e3 100644
--- a/content/rancher/v2.x/en/_index.md
+++ b/content/rancher/v2.x/en/_index.md
@@ -2,6 +2,7 @@
shortTitle: Rancher 2.x
insertOneSix: true
weight: 1
+ctaBanner: intro-k8s-rancher-online-training
---
## What's New?
diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md
index 2ec2b76e42e..b2589089e8f 100644
--- a/content/rancher/v2.x/en/admin-settings/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/_index.md
@@ -1,9 +1,43 @@
---
-title: Administration
+title: Global Configuration
weight: 1100
aliases:
- /rancher/v2.x/en/concepts/global-configuration/
- /rancher/v2.x/en/tasks/global-configuration/
+ - /rancher/v2.x/en/concepts/global-configuration/server-url/
+ - /rancher/v2.x/en/tasks/global-configuration/server-url/
+ - /rancher/v2.x/en/admin-settings/server-url/
+ - /rancher/v2.x/en/admin-settings/log-in/
---
-After installation, the system administrator should configure Rancher to configure security, default settings, and user access.
+After installation, the [system administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) should configure Rancher to configure authentication, authorization, security, default settings, security policies, drivers and global DNS entries.
+
+## First Log In
+
+After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**.You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.
+
+>**Important!** After you set the Rancher Server URL, we do not support updating it. Set the URL with extreme care.
+
+## Authentication
+
+One of the key features that Rancher adds to Kubernetes is centralized user authentication. This feature allows to set up local users and/or connect to an external authentication provider. By connecting to an external authentication provider, you can leverage that provider's user and groups.
+
+For more information how authentication works and how to configure each provider, see [Authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/).
+
+## Authorization
+
+Within Rancher, each person authenticates as a _user_, which is a login that grants you access to Rancher. Once the user logs in to Rancher, their _authorization_, or their access rights within the system, is determined by the user's role. Rancher provides built-in roles to allow you to easily configure a user's permissions to resources, but Rancher also provides the ability to customize the roles for each Kubernetes resource.
+
+For more information how authorization works and how to customize roles, see [Roles Based Access Control (RBAC)]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/).
+
+## Pod Security Policies
+
+_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification, e.g. root privileges. If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message.
+
+For more information how to create and use PSPs, see [Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/).
+
+## Provisioning Drivers
+
+Drivers in Rancher allow you to manage which providers can be used to provision [hosted Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) or [nodes in an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to allow Rancher to deploy and manage Kubernetes.
+
+For more information, see [Provisioning Drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/).
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/_index.md
index 9f9d8c6063c..061d7734c4b 100644
--- a/content/rancher/v2.x/en/admin-settings/authentication/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/authentication/_index.md
@@ -1,6 +1,6 @@
---
title: Authentication
-weight: 1110
+weight: 1115
aliases:
- /rancher/v2.x/en/concepts/global-configuration/authentication/
- /rancher/v2.x/en/tasks/global-configuration/authentication/
@@ -12,9 +12,9 @@ This centralized user authentication is accomplished using the Rancher authentic
-### External vs. Local Authentication
+## External vs. Local Authentication
-The Rancher authentication proxy integrates with the following external authentication services. The following table lists the first version of Rancher each service debuted.
+The Rancher authentication proxy integrates with the following external authentication services. The following table lists the first version of Rancher each service debuted.
| Auth Service | Available as of |
| ------------------------------------------------------------------------------------------------ | ---------------- |
@@ -26,13 +26,21 @@ The Rancher authentication proxy integrates with the following external authenti
| [Microsoft AD FS]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/) | v2.0.7 |
| [PingIdentity]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/ping-federate/) | v2.0.7 |
| [Keycloak]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/keycloak/) | v2.1.0 |
-
+| [Okta]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/okta/) | v2.2.0 |
-However, Rancher also provides local authentication.
+However, Rancher also provides [local authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/local/).
-In most cases, you should use an external authentication service over local, as external authentication allows user management from a central location. However, you may want a few local authentication users for managing Rancher under rare circumstances, such as if Active Directory is down.
+In most cases, you should use an external authentication service over local authentication, as external authentication allows user management from a central location. However, you may want a few local authentication users for managing Rancher under rare circumstances, such as if Active Directory is down.
-### External Authentication Configuration and Principal Users
+## Users and Groups
+
+Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, multi-cluster apps, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/).
+
+> **Note:** Local authentication does not support creating or managing groups.
+
+For more information, see [Users and Groups]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/user-groups/)
+
+## External Authentication Configuration and Principal Users
Configuration of external authentication requires:
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/azure-ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/azure-ad/_index.md
index be1486ea00a..61f08992a4f 100644
--- a/content/rancher/v2.x/en/admin-settings/authentication/azure-ad/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/authentication/azure-ad/_index.md
@@ -122,12 +122,10 @@ To use Azure AD with Rancher you must whitelist Rancher with Azure. You can comp
1. From the **Reply URLs** blade, enter the URL of your Rancher Server, appended with the verification path: `/verify-auth-azure`.
>**Tip:** You can find your personalized Azure reply URL in Rancher on the Azure AD Authentication page (Global View > Security Authentication > Azure AD).
- >
- > 
1. Click **Save**.
-**Result:** Your reply URL is saved.
+**Result:** Your reply URL is saved.
>**Note:** It can take up to five minutes for this change to take affect, so don't be alarmed if you can't authenticate immediately after Azure AD configuration.
@@ -179,13 +177,13 @@ Enter the values that you copied to your [text file](#tip).
1. Select **Azure AD**.
-1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#4-copy-azure-application-data).
+1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#5-copy-azure-application-data).
>**Important:** When entering your Graph Endpoint, remove the tenant ID from the URL, like below.
>
>https://graph.windows.net/abb5adde-bee8-4821-8b03-e63efdc7701c
- 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 |
| ------------------ | ------------------------------------- |
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md
index 5eab23b0067..6eb4373db2d 100644
--- a/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md
@@ -58,13 +58,7 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati
**Result:** Rancher is configured to work with Keycloak. Your users can now sign into Rancher using their Keycloak logins.
->**Keycloak Identity Provider Caveats:**
->
->- SAML Protocol does not support search or lookup for users or groups. Therefore, there is no validation on users or groups when adding them to Rancher.
->- When adding users, the exact user IDs (i.e. `UID Field`) must be entered correctly. As you type the user ID, there will be no search for other user IDs that may match.
->- When adding groups, you *must* select the group from the drop-down that is next to the text box. Rancher assumes that any input from the text box is a user.
->
-> - The group drop-down shows *only* the groups that you are a member of. You will not be able to add groups that you are not a member of.
+{{< saml_caveats >}}
## Annex: Troubleshooting
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/local/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/local/_index.md
index b84367bb678..a5bde3dec91 100644
--- a/content/rancher/v2.x/en/admin-settings/authentication/local/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/authentication/local/_index.md
@@ -1,12 +1,16 @@
---
-title: Configuring Local Authentication
+title: Local Authentication
weight: 1111
aliases:
- /rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/
---
+Local authentication is the default until you configure an external authentication provider. Local authentication is where Rancher stores the user information, i.e. names and passwords, of who can log in to Ranchehr. By default, the `admin` user that logs in to Rancher for the first time is a local user.
+
+## Adding Local Users
+
Regardless of whether you use external authentication, you should create a few local authentication users so that you can continue using Rancher if your external authentication service encounters issues.
-1. From the **Global** view, select **Users** from the main menu.
+1. From the **Global** view, select **Users** from the navigation bar.
2. Click **Add User**. Then complete the **Add User** form. Click **Create** when you're done.
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/_index.md
index 663c8271757..c79cf3e4087 100644
--- a/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/_index.md
@@ -30,12 +30,7 @@ Setting up Microsoft AD FS with Rancher Server requires configuring AD FS on you
- [1 — Configuring Microsoft AD FS for Rancher]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/microsoft-adfs-setup)
- [2 — Configuring Rancher for Microsoft AD FS]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/rancher-adfs-setup)
->**Active Directory Federation Service Caveats:**
->
->- SAML Protocol does not support search or lookup for users or groups. Therefore, there is no validation on users or groups when adding them to Rancher.
->- When adding users, the exact user IDs (i.e. `UID Field`) must be entered correctly. As you type the user ID, there will be no search for other user IDs that may match.
->- When adding groups, you *must* select the group from the drop-down that is next to the text box. Rancher assumes that any input from the text box is a user.
-> - The group drop-down shows *only* the groups that you are a member of. You will not be able to add groups that you are not a member of.
+{{< saml_caveats >}}
### [Next: Configuring Microsoft AD FS for Rancher]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/microsoft-adfs-setup)
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/okta/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/okta/_index.md
new file mode 100644
index 00000000000..b0af27f7f12
--- /dev/null
+++ b/content/rancher/v2.x/en/admin-settings/authentication/okta/_index.md
@@ -0,0 +1,50 @@
+---
+title: Configuring Okta (SAML)
+weight: 1210
+---
+
+_Available as of v2.2.0_
+
+If your organization uses Okta Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
+
+## Prerequisites
+
+In Okta, create a SAML Application with the settings below. See the [Okta documentation](https://developer.okta.com/standards/SAML/setting_up_a_saml_application_in_okta) for help.
+
+Setting | Value
+------------|------------
+`Single Sign on URL` | `https://yourRancherHostURL/v1-saml/okta/saml/acs`
+`Audience URI (SP Entity ID)` | `https://yourRancherHostURL/v1-saml/okta/saml/metadata`
+
+## Configuring Okta in Rancher
+
+1. From the **Global** view, select **Security > Authentication** from the main menu.
+
+1. Select **Okta**.
+
+1. Complete the **Configure Okta Account** form. The examples below describe how you can map Okta attributes to fields within Rancher.
+
+ | Field | Description |
+ | ------------------------- | ----------------------------------------------------------------------------- |
+ | Display Name Field | The attribute that contains the display name of users. |
+ | User Name Field | The attribute that contains the user name/given name. |
+ | UID Field | An attribute that is unique to every user. |
+ | Groups Field | Make entries for managing group memberships. |
+ | Rancher API Host | The URL for your Rancher Server. |
+ | Private Key / Certificate | A key/certificate pair to create a secure shell between Rancher and your IdP. |
+ | Metadata XML | The `Identity Provider metadata` file that you find in the application `Sign On` section. |
+
+ >**Tip:** You can generate a key/certificate pair using an openssl command. For example:
+ >
+ > openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout myservice.key -out myservice.crt
+
+
+1. After you complete the **Configure Okta Account** form, click **Authenticate with Okta**, which is at the bottom of the page.
+
+ Rancher redirects you to the IdP login page. Enter credentials that authenticate with Okta IdP to validate your Rancher Okta configuration.
+
+ >**Note:** If nothing seems to happen, it's likely because your browser blocked the pop-up. Make sure you disable the pop-up blocker for your rancher domain and whitelist it in any other extensions you might utilize.
+
+**Result:** Rancher is configured to work with Okta. Your users can now sign into Rancher using their Okta logins.
+
+{{< saml_caveats >}}
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md
index b06f098ed9f..a6e8dcd3aa6 100644
--- a/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md
@@ -45,9 +45,4 @@ If your organization uses Ping Identity Provider (IdP) for user authentication,
**Result:** Rancher is configured to work with PingIdentity. Your users can now sign into Rancher using their PingIdentity logins.
->**Ping Identity Provider Caveats:**
->
->- SAML Protocol does not support search or lookup for users or groups. Therefore, there is no validation on users or groups when adding them to Rancher.
->- When adding users, the exact user IDs (i.e. `UID Field`) must be entered correctly. As you type the user ID, there will be no search for other user IDs that may match.
->- When adding groups, you *must* select the group from the drop-down that is next to the text box. Rancher assumes that any input from the text box is a user.
-> - The group drop-down shows *only* the groups that you are a member of. You will not be able to add groups that you are not a member of.
+{{< saml_caveats >}}
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/user-groups/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/user-groups/_index.md
new file mode 100644
index 00000000000..6cc49ad058f
--- /dev/null
+++ b/content/rancher/v2.x/en/admin-settings/authentication/user-groups/_index.md
@@ -0,0 +1,51 @@
+---
+title: Users and Groups
+weight: 1
+---
+
+Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When you configure an external authentication provider, users from that provider will be able to log in to your Rancher server. When a user logs in, the authentication provider will supply your Rancher server with a list of groups to which the user belongs.
+
+Access to clusters, projects, multi-cluster apps, and global DNS providers and entries can be controlled by adding either individual users or groups to these resources. When you add a group to a resource, all users who are members of that group in the authentication provider, will be able to access the resource with the permissions that you've specified for the group. For more information on roles and permissions, see [Role Based Access Control]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/).
+
+## Managing Members
+
+When adding a user or group to a resource, you can search for users or groups by beginning to type their name. The Rancher server will query the authentication provider to find users and groups that match what you've entered. Searching is limited to the authentication provider that you are currently logged in with. For example, if you've enabled GitHub authentication but are logged in using a [local]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/local/) user account, you will not be able to search for GitHub users or groups.
+
+All users, whether they are local users or from an authentication provider, can be viewed and managed. From the **Global** view, click on **Users**.
+
+{{< saml_caveats >}}
+
+## User Information
+
+Rancher maintains information about each user that logs in through an authentication provider. This information includes whether the user is allowed to access your Rancher server and the list of groups that the user belongs to. Rancher keeps this user information so that the CLI, API, and kubectl can accurately reflect the access that the user has based on their group membership in the authentication provider.
+
+Whenever a user logs in to the UI using an authentication provider, Rancher automatically updates this user information.
+
+### Automatically Refreshing User Information
+
+_Available as of v2.2.0_
+
+Rancher will periodically refresh the user information even before a user logs in through the UI. You can control how often Rancher performs this refresh. From the **Global** view, click on **Settings**. Two settings control this behavior:
+
+- **`auth-user-info-max-age-seconds`**
+
+ This setting controls how old a user's information can be before Rancher refreshes it. If a user makes an API call (either directly or by using the Rancher CLI or kubectl) and the time since the user's last refresh is greater than this setting, then Rancher will trigger a refresh. This settting defaults to `3600` seconds, i.e. 1 hour.
+
+- **`auth-user-info-resync-cron`**
+
+ This setting controls a recurring schedule for resyncing authentication provider information for all users. Regardless of whether a user has logged in or used the API recently, this will cause the user to be refreshed at the specified interval. This setting defaults to `0 0 * * *`, i.e. once a day at midnight. See the [Cron documentation](https://en.wikipedia.org/wiki/Cron) for more information on valid values for this setting.
+
+
+> **Note:** Since SAML does not support user lookup, SAML-based authentication providers do not support periodically refreshing user information. User information will only be refreshed when the user logs into the Rancher UI.
+
+### Manually Refreshing User Information
+
+If you are not sure the last time Rancher performed an automatic refresh of user information, you can perform a manual refresh of all users.
+
+1. From the **Global** view, click on **Users** in the navigation bar.
+
+1. Click on **Refresh Group Memberships**.
+
+**Results:** Rancher refreshes the user information for all users. Requesting this refresh will update which users can access Rancher as well as all the groups that each user belongs to.
+
+>**Note:** Since SAML does not support user lookup, SAML-based authentication providers do not support the ability to manually refresh user information. User information will only be refreshed when the user logs into the Rancher UI.
diff --git a/content/rancher/v2.x/en/admin-settings/drivers/_index.md b/content/rancher/v2.x/en/admin-settings/drivers/_index.md
new file mode 100644
index 00000000000..63d202b1fad
--- /dev/null
+++ b/content/rancher/v2.x/en/admin-settings/drivers/_index.md
@@ -0,0 +1,46 @@
+---
+title: Provisioning Drivers
+weight: 1140
+---
+
+Drivers in Rancher allow you to manage which providers can be used to deploy [hosted Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) or [nodes in an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to allow Rancher to deploy and manage Kubernetes.
+
+### Rancher Drivers
+
+With Rancher drivers, you can enable/disable existing built-in drivers that are packaged in Rancher. Alternatively, you can add your own driver if Rancher has not yet implemented it.
+
+There are two types of drivers within Rancher:
+
+* [Cluster Drivers](#cluster-drivers)
+* [Node Drivers](#node-drivers)
+
+## Cluster Drivers
+
+_Available as of v2.2.0_
+
+Cluster drivers are used to provision [hosted Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/), such as GKE, EKS, AKS, etc.. The availability of which cluster driver to display when creating a cluster is defined based on the cluster driver's status. Only `active` cluster drivers will be displayed as an option for creating clusters for hosted Kubernetes clusters. By default, Rancher is packaged with several existing cluster drivers, but you can also create custom cluster drivers to add to Rancher.
+
+By default, Rancher has activated several hosted Kubernetes cloud providers including:
+
+* [Amazon EKS]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/eks/)
+* [Google GKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke/)
+* [Azure AKS]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/aks/)
+
+There are several other hosted Kubernetes cloud providers that are disabled by default, but are packaged in Rancher:
+
+* [Alibaba ACK]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/ack/)
+* [Huawei CCE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/cce/)
+* [Tencent]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/tke/)
+
+## Node Drivers
+
+Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). The availability of which node driver to display when creating node templates is defined based on the node driver's status. Only `active` node drivers will be displayed as an option for creating node templates. By default, Rancher is packaged with many existing Docker Machine drivers, but you can also create custom node drivers to add to Rancher.
+
+If there are specific node drivers that you don't want to show to your users, you would need to de-activate these node drivers.
+
+Rancher supports several major cloud providers, but by default, these node drivers are active and available for deployment:
+
+* [Amazon EC2]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/)
+* [Azure]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/azure/)
+* [Digital Ocean]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/)
+* [vSphere]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/)
diff --git a/content/rancher/v2.x/en/admin-settings/drivers/cluster-drivers/_index.md b/content/rancher/v2.x/en/admin-settings/drivers/cluster-drivers/_index.md
new file mode 100644
index 00000000000..f578774e99f
--- /dev/null
+++ b/content/rancher/v2.x/en/admin-settings/drivers/cluster-drivers/_index.md
@@ -0,0 +1,44 @@
+---
+title: Cluster Drivers
+weight: 1
+---
+
+_Available as of v2.2.0_
+
+Cluster drivers are used to create clusters in a [hosted Kubernetes provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/), such as Google GKE. The availability of which cluster driver to display when creating clusters is defined by the cluster driver's status. Only `active` cluster drivers will be displayed as an option for creating clusters. By default, Rancher is packaged with several existing cloud provider cluster drivers, but you can also add custom cluster drivers to Rancher.
+
+If there are specific cluster drivers that you do not want to show your users, you may deactivate those cluster drivers within Rancher and they will not appear as an option for cluster creation.
+
+### Managing Cluster Drivers
+
+>**Prerequisites:** To create, edit, or delete cluster drivers, you need _one_ of the following permissions:
+>
+>- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/)
+>- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Cluster Drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#global-permissions-reference) role assigned.
+
+## Activating/Deactivating Cluster Drivers
+
+By default, Rancher only activates drivers for the most popular cloud providers, Google GKE, Amazon EKS and Azure AKS. If you want to show or hide any node driver, you can change its status.
+
+1. From the **Global** view, choose **Tools > Drivers** in the navigation bar.
+
+2. From the **Drivers** page, select the **Cluster Drivers** tab.
+
+3. Select the driver that you wish to **Activate** or **Deactivate** and select the appropriate icon.
+
+## Adding Custom Cluster Drivers
+
+If you want to use a cluster driver that Rancher doesn't support out-of-the-box, you can add the provider's driver in order to start using them to create _hosted_ kubernetes clusters.
+
+1. From the **Global** view, choose **Tools > Drivers** in the navigation bar.
+
+2. From the **Drivers** page select the **Cluster Drivers** tab.
+
+3. Click **Add Cluster Driver**.
+
+4. Complete the **Add Cluster Driver** form. Then click **Create**.
+
+
+### Developing your own Cluster Driver
+
+In order to develop cluster driver to add to Rancher, please refer to our [example](https://github.com/rancher-plugins/kontainer-engine-driver-example).
diff --git a/content/rancher/v2.x/en/admin-settings/drivers/node-drivers/_index.md b/content/rancher/v2.x/en/admin-settings/drivers/node-drivers/_index.md
new file mode 100644
index 00000000000..ba310504acc
--- /dev/null
+++ b/content/rancher/v2.x/en/admin-settings/drivers/node-drivers/_index.md
@@ -0,0 +1,40 @@
+---
+title: Node Drivers
+weight: 2
+aliases:
+ - /rancher/v2.x/en/concepts/global-configuration/node-drivers/
+ - /rancher/v2.x/en/tasks/global-configuration/node-drivers/
+---
+
+Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). The availability of which node driver to display when creating node templates is defined based on the node driver's status. Only `active` node drivers will be displayed as an option for creating node templates. By default, Rancher is packaged with many existing Docker Machine drivers, but you can also create custom node drivers to add to Rancher.
+
+If there are specific node drivers that you don't want to show to your users, you would need to de-activate these node drivers.
+
+#### Managing Node Drivers
+
+>**Prerequisites:** To create, edit, or delete drivers, you need _one_ of the following permissions:
+>
+>- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/)
+>- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Node Drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#global-permissions-reference) role assigned.
+
+## Activating/Deactivating Node Drivers
+
+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 its status.
+
+1. From the **Global** view, choose **Tools > Drivers** in the navigation bar. From the **Drivers** page, select the **Node Drivers** tab. In version prior to v2.2.0, you can select **Node Drivers** directly in the navigation bar.
+
+2. Select the driver that you wish to **Activate** or **Deactivate** and select the appropriate icon.
+
+## Adding Custom Node Drivers
+
+If you want to use a node driver that Rancher doesn't support out-of-the-box, you can add that provider's driver in order to start using them to create node templates and eventually node pools for your Kubernetes cluster.
+
+1. From the **Global** view, choose **Tools > Drivers** in the navigation bar. From the **Drivers** page, select the **Node Drivers** tab. In version prior to v2.2.0, you can select **Node Drivers** directly in the navigation bar.
+
+2. Click **Add Node Driver**.
+
+3. Complete the **Add Node Driver** form. Then click **Create**.
+
+### Developing your own node driver
+
+Node drivers are implemented with [Docker Machine](https://docs.docker.com/machine/).
diff --git a/content/rancher/v2.x/en/admin-settings/log-in/_index.md b/content/rancher/v2.x/en/admin-settings/log-in/_index.md
deleted file mode 100644
index 3a61c5404a4..00000000000
--- a/content/rancher/v2.x/en/admin-settings/log-in/_index.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: First Log In
-weight: 50
-aliases:
- - /rancher/v2.x/en/concepts/global-configuration/server-url/
- - /rancher/v2.x/en/tasks/global-configuration/server-url/
- - /rancher/v2.x/en/admin-settings/server-url
----
-
-After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**.You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.
-
->**Important!** After you set the Rancher Server URL, we do not support updating it. Set the URL with extreme care.
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/admin-settings/rbac/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/_index.md
index 27c660aeb46..f3aedf6b0d6 100644
--- a/content/rancher/v2.x/en/admin-settings/rbac/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/rbac/_index.md
@@ -1,6 +1,6 @@
---
-title: Roles in Rancher
-weight: 1125
+title: Roles Based Access Control (RBAC)
+weight: 1120
aliases:
- /rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/
---
diff --git a/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md
index 4388c4d7ecf..dcd2e893f9c 100644
--- a/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md
@@ -36,14 +36,18 @@ The following table lists each built-in custom cluster role available in Rancher
| Custom Cluster Role | Owner | Member |
| ---------------------------------- | ------------- | --------------------------------- |
| Manage Cluster Members | ✓ | |
+| Manage Cluster Catalogs | ✓ |
| Manage Nodes | ✓ | |
+| Manage Snapshots | ✓ ||
| Manage Storage | ✓ | |
| View All Projects | ✓ | |
| Create Project | ✓ | ✓ |
| View Cluster Members | ✓ | ✓ |
+| View Cluster Catalogs | ✓ | ✓ |
| View Nodes | ✓ | ✓ |
+| View Snapshots | ✓ | ✓ |
-> **Notes:**
+> **Notes:**
>
>- Each cluster role listed above, including `Owner` and `Member`, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page.
>- When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
@@ -63,11 +67,11 @@ _Project roles_ are roles that can be used to grant users access to a project. T
- **Read Only:**
These users can view everything in the project but cannot create, update, or delete anything.
-
+
>**Caveat:**
>
>Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `owner` or `member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
-
+
#### Custom Project Roles
@@ -83,6 +87,7 @@ The following table lists each built-in custom project role available in Rancher
| Create Namespaces | ✓ | ✓ | |
| Manage Config Maps | ✓ | ✓ | |
| Manage Ingress | ✓ | ✓ | |
+| Manage Project Catalogs | ✓ | | |
| Manage Secrets | ✓ | ✓ | |
| Manage Service Accounts | ✓ | ✓ | |
| Manage Services | ✓ | ✓ | |
@@ -91,13 +96,14 @@ The following table lists each built-in custom project role available in Rancher
| View Config Maps | ✓ | ✓ | ✓ |
| View Ingress | ✓ | ✓ | ✓ |
| View Project Members | ✓ | ✓ | ✓ |
+| View Project Catalogs | ✓ | ✓ | ✓ |
| View Secrets | ✓ | ✓ | ✓ |
| View Service Accounts | ✓ | ✓ | ✓ |
| View Services | ✓ | ✓ | ✓ |
| View Volumes | ✓ | ✓ | ✓ |
| View Workloads | ✓ | ✓ | ✓ |
-> **Notes:**
+> **Notes:**
>
>- Each project role listed above, including `Owner`, `Member`, and `Read Only`, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page.
>- When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
@@ -119,7 +125,7 @@ There are two methods for changing default cluster/project roles:
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:**
+>**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.
@@ -135,7 +141,7 @@ You can change the cluster or project role(s) that are automatically assigned to
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**.
+1. Click **Save**.
{{% /accordion %}}
{{% accordion id="project" label="For Projects" %}}
1. From **Project Creator Default**, choose **Yes: Default role for new project creation**.
diff --git a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md
index 4322fcd314b..1263a405b79 100644
--- a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md
@@ -43,6 +43,7 @@ The following table lists each custom global permission available and whether it
| ---------------------------------- | ------------- | ------------- |
| Manage Authentication | ✓ | |
| Manage Catalogs | ✓ | |
+| Manage Cluster Drivers | ✓ | |
| Manage Node Drivers | ✓ | |
| Manage PodSecurityPolicy Templates | ✓ | |
| Manage Roles | ✓ | |
diff --git a/content/rancher/v2.x/en/admin-settings/removing-rancher/_index.md b/content/rancher/v2.x/en/admin-settings/removing-rancher/_index.md
deleted file mode 100644
index 22e572b83e0..00000000000
--- a/content/rancher/v2.x/en/admin-settings/removing-rancher/_index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Removing Rancher
-weight: 5000
----
-
-When you deploy Rancher and use it to provision clusters, Rancher installs its components on the nodes you use. This section features instructions on how to remove Rancher's components from your nodes that you no longer want to use with Rancher.
-
-There are two contexts in which you'd remove Rancher from a Kubernetes cluster node.
-
-- [Removing Rancher Components from Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/admin-settings/removing-rancher/user-cluster-nodes/)
-
- In this context, you are removing Rancher components from Kubernetes clusters that you [launched using Rancher]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/).
-
-- [Removing Rancher from Your Rancher Server Nodes]({{< baseurl >}}/rancher/v2.x/en/admin-settings/removing-rancher/rancher-cluster-nodes/)
-
- In this context, you are removing Rancher from the Kubernetes cluster that you configured for your [Rancher installation]({{< baseurl >}}/rancher/v2.x/en/installation/ha/).
diff --git a/content/rancher/v2.x/en/admin-settings/removing-rancher/rancher-cluster-nodes/_index.md b/content/rancher/v2.x/en/admin-settings/removing-rancher/rancher-cluster-nodes/_index.md
deleted file mode 100644
index b9311ebcbf2..00000000000
--- a/content/rancher/v2.x/en/admin-settings/removing-rancher/rancher-cluster-nodes/_index.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Removing Rancher from Your Rancher Server Nodes
-weight: 2000
----
-
-When you want to remove Rancher from your [installation cluster]({{< baseurl >}}/rancher/v2.x/en/installation/ha/) as part of a Rancher reinstall (or uninstall), follow the instructions below to download and run _system-tools_, a utility that removes all Rancher components from Rancher Server nodes provisioned by RKE.
-
-### Download and Configuration
-
-You can download the latest version of Rancher system-tools from its GitHub [releases page](https://github.com/rancher/system-tools/releases). Download the version of system-tools for the OS that you're running the tool from.
-
-Operating System | File
------------------|-----
-MacOS | `system-tools_darwin-amd64`
-Linux | `system-tools_linux-amd64`
-Windows | `system-tools_windows-amd64.exe`
-
-
-
-After you download the tools, complete the following actions:
-
-1. Rename the file to `system-tools`.
-
-1. Give the file executable permissions by running the following command:
-
- ```
- chmod +x system-tools
- ```
-1. Find the kubeconfig file that was generated during your Rancher installation, `kube_config_rancher-cluster.yml`. Move it to the `~/.kube` on your workstation, if it isn't already there. Create this directory if it doesn't exist.
-
- System-tools uses this file to access your installation cluster.
-
-
-### Using the System-Tool
-
-System-tools is a utility for running operational tasks on Rancher clusters. In this use case, it will help you remove the Rancher from your installation nodes.
-
-#### Usage
-
-After you move the `system-tools` and kubeconfig file to your workstation's `~/.kube` directory, you can run system-tools by changing to the `~/.kube` directory and entering the following command.
-
->**Warning:** This command will remove data from your etcd nodes. Make sure you have created a [backup of etcd]({{< baseurl >}}/rancher/v2.x/en/backups/backups) before executing the command.
-
-```
-./system-tools remove --kubeconfig <$KUBECONFIG> --namespace
-```
-
-
-When you run this command, the components listed in [What Gets Removed?](#what-gets-removed) are deleted.
-
-
-##### Options
-
-| Option | Description |
-| ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
-| `--kubeconfig , -c ` | The cluster's kubeconfig file absolute path, usually `~/.kube/kube_config_rancher-cluster.yml`.1 |
-| `--namespace , -n cattle-system` | Rancher 2.x deployment namespace (``). If no namespace is defined, the options defaults to `cattle-system`. |
-| `--force` | Skips the the interactive removal confirmation and removes the Rancher deployment without prompt. |
-
-> 1 If you are working with multiple Kubernetes clusters, you can place `kube_config_rancher-cluster.yml` in another directory path and then set the `KUBECONFIG` environment variable to its path.
->```
->export KUBECONFIG=$(pwd)/kube_config_rancher-cluster.yml
->```
-
-## What Gets Removed?
-
-When removing Rancher from server nodes launched using RKE, the following components are deleted.
-
-
-- The Rancher deployment namespace (`cattle-system` by default).
-- Any `serviceAccount`, `clusterRoles`, and `clusterRoleBindings` that Rancher applied the `cattle.io/creator:norman` label to. Rancher applies this label to any resource that it creates as of v2.1.0.
-- Labels, annotations, and finalizers.
-- Rancher Deployment.
-- Machines, clusters, projects, and user custom resource deployments (CRDs).
-- All resources create under the `management.cattle.io` API Group.
-- All CRDs created by Rancher v2.0.x.
-
-
->**Using 2.0.8 or Earlier?**
->
->These versions of Rancher do not automatically delete the `serviceAccount`, `clusterRole`, and `clusterRoleBindings` resources after the job runs. You'll have to delete them yourself.
diff --git a/content/rancher/v2.x/en/backups/_index.md b/content/rancher/v2.x/en/backups/_index.md
index 64e2cebf6ef..0f2c8b5a106 100644
--- a/content/rancher/v2.x/en/backups/_index.md
+++ b/content/rancher/v2.x/en/backups/_index.md
@@ -3,12 +3,16 @@ title: Backups and Disaster Recovery
weight: 1000
---
-This section is devoted to protecting your Rancher Server data in a disaster scenario.
+This section is devoted to protecting your data in a disaster scenario.
-- [Backups]({{< baseurl >}}/rancher/v2.x/en/backups/backups)
- To protect yourself from a disaster scenario, you should create Rancher backups on a regular basis.
+To protect yourself from a disaster scenario, you should create backups on a regular basis.
-- [Restorations]({{< baseurl >}}/rancher/v2.x/en/backups/restorations)
+ - [Rancher Server Backups]({{< baseurl >}}/rancher/v2.x/en/backups/backups)
+ - [Backing up Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/)
- In a disaster scenario, you can restore your `etcd` database by restoring a backup.
+
+In a disaster scenario, you can restore your `etcd` database by restoring a backup.
+
+ - [Rancher Server Restorations]({{< baseurl >}}/rancher/v2.x/en/backups/restorations)
+ - [Restoring Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/)
diff --git a/content/rancher/v2.x/en/backups/backups/_index.md b/content/rancher/v2.x/en/backups/backups/_index.md
index 750477f8fcb..aaf8226cd97 100644
--- a/content/rancher/v2.x/en/backups/backups/_index.md
+++ b/content/rancher/v2.x/en/backups/backups/_index.md
@@ -9,3 +9,5 @@ This section contains information about how to create backups of your Rancher da
- [Single Node Install Backups](./single-node-backups/)
- [High Availability Install Backups](./ha-backups/)
+
+If you are looking to back up your [Rancher launched Kubernetes cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), please refer [here]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/).
diff --git a/content/rancher/v2.x/en/backups/restorations/_index.md b/content/rancher/v2.x/en/backups/restorations/_index.md
index ccfb75a22e8..7dc3294f1bd 100644
--- a/content/rancher/v2.x/en/backups/restorations/_index.md
+++ b/content/rancher/v2.x/en/backups/restorations/_index.md
@@ -6,3 +6,5 @@ If you lose the data on your Rancher Server, you can restore it if you have back
- [Restoring Backups—Single Node Installs]({{< baseurl >}}/rancher/v2.x/en/backups/restorations/single-node-restoration/)
- [Restoring Backups—High Availability Installs]({{< baseurl >}}/rancher/v2.x/en/backups/restorations/ha-restoration/)
+
+If you are looking to restore your [Rancher launched Kubernetes cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), please refer [here]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/).
diff --git a/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md b/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md
index 0ae9fc9ad89..94093b8a135 100644
--- a/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md
+++ b/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md
@@ -23,7 +23,7 @@ This procedure describes how to use RKE to restore a snapshot of the Rancher Kub
### 1. Preparation
-You will need [RKE]({{< baseurl >}}/rke/v0.1.x/en/installation/) and [kubectl]({{< baseurl >}}/rancher/v2.x/en/faq/kubectl/) CLI utilities installed.
+You will need [RKE]({{< baseurl >}}/rke/latest/en/installation/) and [kubectl]({{< baseurl >}}/rancher/v2.x/en/faq/kubectl/) CLI utilities installed.
Prepare by creating 3 new nodes to be the target for the restored Rancher instance. See [HA Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/) for node requirements.
diff --git a/content/rancher/v2.x/en/catalog/_index.md b/content/rancher/v2.x/en/catalog/_index.md
index 5669d00524f..ec079814f6c 100644
--- a/content/rancher/v2.x/en/catalog/_index.md
+++ b/content/rancher/v2.x/en/catalog/_index.md
@@ -1,29 +1,40 @@
---
-title: Catalogs and Charts
+title: Catalogs and Apps
weight: 4000
aliases:
- /rancher/v2.x/en/concepts/global-configuration/catalog/
- /rancher/v2.x/en/concepts/catalogs/
- /rancher/v2.x/en/tasks/global-configuration/catalog/
- - /rancher/v2.x/en/tasks/global-configuration/catalog/enabling-default-catalogs/
- - /rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs/
---
-Rancher provides a catalog of charts that make it easy to repeatedly deploy any applications.
+## Catalogs
-_Catalogs_ are GitHub repositories filled with applications that are ready-made for deployment. Applications are bundled in objects called _charts_.
+Rancher provides the ability to use a catalog of Helm charts that make it easy to repeatedly deploy applications.
-_Charts_ are a packaging format popularized by [Helm](https://docs.helm.sh/). Think of them as templates for deployments. Per Helm, charts are:
+_Catalogs_ are GitHub repositories or Helm Chart repositories filled with applications that are ready-made for deployment. Applications are bundled in objects called _Helm charts_.
>A collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
Rancher improves on Helm catalogs and charts. All native Helm charts can work within Rancher, but Rancher adds several enhancements to improve their user experience.
+## Catalog Scopes
+
+Catalogs can be added at different scopes of Rancher.
+
+Scope | Description
+--- | ---
+Global | Catalogs added at this scope are available for all clusters and all projects in Rancher.
+Cluster | Catalogs added within a cluster are available for all projects in that cluster.
+Project | Catalogs added within a project are only available for that project.
+
+## Global catalogs
+
## Enabling Built-in Catalogs
Within Rancher, there are default catalogs packaged as part of Rancher. These can be enabled or disabled by an administrator.
-1. From the **Global** view, choose **Catalogs** from the main menu.
+1. From the **Global** view, choose **Tools > Catalogs** in the navigation bar. In versions prior to v2.2.0, you can select **Catalogs** directly in the navigation bar.
+
2. Toggle the default catalogs that you want use to a setting of **Enabled**.
- **Library**
@@ -40,19 +51,31 @@ Within Rancher, there are default catalogs packaged as part of Rancher. These ca
Similar in user experience to Helm Stable, but this catalog is filled with applications in **beta**.
- **Result**: The chosen catalogs are enabled. Wait a few minutes for Rancher to replicate the catalog charts. When replication completes, you'll be able to see them in any of your projects by selecting **Catalog Apps** from the main menu.
+ **Result**: The chosen catalogs are enabled. Wait a few minutes for Rancher to replicate the catalog charts. When replication completes, you'll be able to see them in any of your projects by selecting **Apps** from the main navigation bar. In versions prior to v2.2.0, you can select **Catalog Apps** from the main navigation bar.
## Adding Custom Catalogs
-Adding a catalog is as simple as adding a catalog name, a URL and a branch name. The URL needs to be one that `git clone` [can handle](https://git-scm.com/docs/git-clone#_git_urls_a_id_urls_a) and must end in `.git`. The branch name must be a branch that is in your catalog URL. If no branch name is provided, it will use the `master` branch by default. Whenever you add a catalog to Rancher, it will be available immediately.
+Adding a catalog is as simple as adding a catalog name, a URL and a branch name.
->**Notes:**
->
->- Currently, you can only add custom catalogs to Rancher at the global level. Therefore, any catalog that you add is shared with all clusters and projects.
->
->- Currently, only unauthenticated catalogs are supported.
-
-
+#### Add Custom Git Repositories
+The Git URL needs to be one that `git clone` [can handle](https://git-scm.com/docs/git-clone#_git_urls_a_id_urls_a) and must end in `.git`. The branch name must be a branch that is in your catalog URL. If no branch name is provided, it will use the `master` branch by default. Whenever you add a catalog to Rancher, it will be available immediately.
+
+
+#### Add Custom Helm Chart Repositories
+
+A Helm chart repository is an HTTP server that houses one or more packaged charts. Any HTTP server that can serve YAML files and tar files and can answer GET requests can be used as a repository server.
+
+Helm comes with built-in package server for developer testing (helm serve). The Helm team has tested other servers, including Google Cloud Storage with website mode enabled, S3 with website mode enabled or hosting custom chart repository server using open-source projects like [ChartMuseum](https://github.com/helm/chartmuseum).
+
+In Rancher, you can add the custom Helm chart repository with only a catalog name and the URL address of the chart repository.
+
+#### Add Private Git/Helm Chart Repositories
+_Available as of v2.2.0_
+
+In Rancher v2.2.0, you can add private catalog repositories using credentials like Username and Password. You may also want to use the
+OAuth token if your Git or Helm repository server support that.
+
+[Read More About Adding Private Git/Helm Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/#private-repositories)
- 1. From the **Global** view, choose **Catalogs** from the main menu.
+ 1. From the **Global** view, choose **Tools > Catalogs** in the navigation bar. In versions prior to v2.2.0, you can select **Catalogs** directly in the navigation bar.
2. Click **Add Catalog**.
3. Complete the form and click **Create**.
@@ -69,11 +92,11 @@ NEEDS TO BE FIXED FOR 2.0: Any [users]({{site.baseurl}}/rancher/{{page.version}}
## Launching Catalog Applications
-After you've either enabled the built-in catalogs or added your own custom catalog, you can start launching any catalog application.
+After you've either enabled the built-in catalogs or added your own custom catalog, you can start launching any catalog application.>
1. From the **Global** view, open the project that you want to deploy to.
-2. From the main menu, choose **Catalog Apps**. Then click **Launch**.
+2. From the main navigation bar, choose **Apps**. In versions prior to v2.2.0, choose **Catalog Apps** on the main navigation bar. Click **Launch**.
3. Find the app that you want to launch, and then click **View Now**.
@@ -96,17 +119,36 @@ After you've either enabled the built-in catalogs or added your own custom catal
**Result**: Your application is deployed to your chosen namespace. You can view the application status from the project's:
-- **Workloads** view
-- **Catalog Apps** view
+By creating a customized repository with added files, Rancher improves on Helm repositories and charts. All native Helm charts can work within Rancher, but Rancher adds several enhancements to improve their user experience.
-## Deleting Catalog Application Deployments
+### Catalog Scope
-As a safeguard to prevent you from unintentionally deleting other catalog applications that share a namespace, deleting catalog applications themselves does not delete the namespace they're assigned to. Therefore, when you want to delete a deployed catalog application, assuming that it's the only app in its namespace, delete the namespace rather than the catalog app itself. Deleting the namespace deletes both the namespace and the catalog app, whereas deleting the catalog app only deletes the app but not the namespace.
+Within Rancher, you can manage catalogs at three different scopes. Global catalogs is shared across all clusters and project. There are some use cases where you might not want to share catalogs across between different clusters or even projects in the same cluster. By leveraging cluster and project scoped catalogs, you will be able to provide applications for specific teams without needing to share them with all clusters and/or projects.
-1. From the **Global** view, open the project that contains the catalog application that you want to delete.
+Scope | Description | Available As of |
+--- | --- | --- |
+Global | All clusters and all projects can access the Helm charts in this catalog | v2.0.0 |
+Cluster | All projects in the specific cluster can access the Helm charts in this catalog | v2.2.0 |
+Project | This specific cluster can access the Helm charts in this catalog | v2.2.0 |
-1. From the main menu, choose **Namespaces**.
+### Working with catalogs
-1. Find the namespace running your catalog app. Select it and click **Delete**.
+There are two types of catalogs in Rancher. Learn more about each type:
-**Result:** The catalog application deployment and its namespace are deleted.
+* [Built-in Global Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/built-in/)
+* [Custom Catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/)
+
+## Apps
+
+In Rancher, applications are deployed from the templates in a catalog. Rancher supports two types of applications:
+
+* [Multi-cluster applications]({{< baseurl >}}/rancher/v2.x/en/catalog/multi-cluster-apps/)
+* [Applications deployed in a specific Project]({{< baseurl >}}/rancher/v2.x/en/catalog/apps)
+
+## Global DNS
+
+_Available as v2.2.0_
+
+When creating applications that span multiple Kubernetes clusters, a Global DNS entry can be created to route traffic to the endpoints in all of the different clusters. An external DNS server will need be programmed to assign a fully qualified domain name (a.k.a FQDN) to your application. Rancher will use the FQDN you provide and the IP addresses where your application is running to program the DNS. Rancher will gather endpoints from all the Kubernetes clusters running your application and program the DNS.
+
+For more information on how to use this feature, see [Global DNS]({{< baseurl >}}/rancher/v2.x/en/admin-settings/globaldns/).
diff --git a/content/rancher/v2.x/en/catalog/apps/_index.md b/content/rancher/v2.x/en/catalog/apps/_index.md
new file mode 100644
index 00000000000..9421f3708d2
--- /dev/null
+++ b/content/rancher/v2.x/en/catalog/apps/_index.md
@@ -0,0 +1,159 @@
+---
+title: Apps in a Project
+weight: 5005
+---
+
+Within a project, when you want to deploy applications from catalogs, the applications available in your project will be based on the [scope of the catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/#catalog-scope).
+
+If your application is using ingresses, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry]({{< baseurl >}}/rancher/v2.x/en/catalog/globaldns/).
+
+## Launching Catalog Applications
+
+After you've either enabled the [built-in global catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/built-in/) or [added your own custom catalog]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/adding), you can start launching catalog applications.
+
+1. From the **Global** view, navigate to your project that you want to start deploying applications.
+
+2. From the main navigation bar, choose **Apps**. In versions prior to v2.2.0, choose **Catalog Apps** on the main navigation bar. Click **Launch**.
+
+3. Find the application that you want to launch, and then click **View Details**.
+
+4. (Optional) Review the detailed descriptions, which comes from the Helm chart's `README`.
+
+5. Under **Configuration Options** enter a **Name**. By default, this name is also used to create a Kubernetes namespace for the application.
+
+ * If you would like to change the **Namespace**, click **Customize** and change the name of the namespace.
+ * If you want to use a different namespace that already exists, click **Customize**, and then click **Use an existing namespace**. Choose a namespace from the list.
+
+6. Select a **Template Version**.
+
+7. Complete the rest of the **Configuration Options**. Rancher handles how to [customize your configuration options](#configuration-options) depending on whether or not the custom catalog includes the `questions.yml` file.
+
+8. Review the files in the **Preview** section. When you're satisfied, click **Launch**.
+
+**Result**: Your application is deployed to your chosen namespace. You can view the application status from the project's:
+
+- **Workloads** view
+- **Apps** view. In versions prior to v2.2.0, this is the **Catalog Apps** view.
+
+### Configuration Options
+
+For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://github.com/helm/helm/blob/master/docs/using_helm.md#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm.
+
+> For example, when entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is reuired to wrap the values with double quotes (i.e., ``"abc, bcd"``).
+
+{{% tabs %}}
+{{% tab "UI" %}}
+
+#### Using a `questions.yml` file
+
+If the Helm chart that you are deploying contains a `questions.yml` file, Rancher's UI will translate this file to display an easy to use UI to collect the answers for the questions.
+
+#### Key Value Pairs for Native Helm Charts
+
+For native Helm charts (i.e., charts from the **Helm Stable** or **Helm Incubator** catalogs or a [custom Helm chart repository]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/#custom-helm-chart-repository)), answers are provided as key value pairs in the **Answers** section. These answers are used to override the default values.
+
+{{% /tab %}}
+{{% tab "Editing YAML Files" %}}
+
+_Available as of v2.1.0_
+
+If you do not want to input answers using the UI, you can choose the **Edit as YAML** option.
+
+With this example YAML:
+
+```YAML
+outer:
+ inner: value
+servers:
+- port: 80
+ host: example
+```
+
+#### Kev Value Pairs
+
+You can have a YAML file that translates these fields to match how to [format custom values so that it can be used with `--set`](https://github.com/helm/helm/blob/master/docs/using_helm.md#the-format-and-limitations-of---set).
+
+These values would be translated to:
+
+```
+outer.inner=value
+servers[0].port=80
+servers[0].host=example
+```
+
+#### YAML files
+
+_Available as of v2.2.0_
+
+You can directly paste that YAML formatted structure into the YAML editor. By allowing custom values to be set using a YAML formatted structure, Rancher has the ability to easily customize for more complicated input values (e.g. multi-lines, array and JSON objects).
+{{% /tab %}}
+{{% /tabs %}}
+
+## Application Management
+
+After deploying an application, one of the benefits of using an application versus individual workloads/resources is the ease of being able to manage many workloads/resources applications. Apps can be cloned, upgraded or rolled back.
+
+### Cloning Catalog Applications
+
+After an application is deployed, you can easily clone it to use create another application with almost the same configuration. It saves you the work of manually filling in duplicate information.
+
+### Upgrading Catalog Applications
+
+After an application is deployed, you can easily upgrade to a different template version.
+
+1. From the **Global** view, navigate to the project that contains the catalog application that you want to upgrade.
+
+1. From the main navigation bar, choose **Apps**. In versions prior to v2.2.0, choose **Catalog Apps** on the main navigation bar. Click **Launch**.
+
+3. Find the application that you want to upgrade, and then click the Ellipsis to find **Upgrade**.
+
+4. Select the **Template Version** that you want to deploy.
+
+5. (Optional) Update your **Configuration Options**.
+
+6. (Optional) Select whether or not you want to force the catalog application to be upgraded by checking the box for **Delete and recreate resources if needed during the upgrade**.
+
+ > In Kubernetes, some fields are designed to be immutable or cannot be updated directly. As of v2.2.0, you can now force your catalog application to be updated regardless of these fields. This will cause the catalog apps to be deleted and resources to be re-created if needed during the upgrade.
+
+7. Review the files in the **Preview** section. When you're satisfied, click **Launch**.
+
+**Result**: Your application is updated. You can view the application status from the project's:
+
+- **Workloads** view
+- **Apps** view. In versions prior to v2.2.0, this is the **Catalog Apps** view.
+
+
+### Rolling Back Catalog Applications
+
+After an application has been upgraded, you can easily rollback to a different template version.
+
+1. From the **Global** view, navigate to the project that contains the catalog application that you want to upgrade.
+
+1. From the main navigation bar, choose **Apps**. In versions prior to v2.2.0, choose **Catalog Apps** on the main navigation bar. Click **Launch**.
+
+3. Find the application that you want to rollback, and then click the Ellipsis to find **Rollback**.
+
+4. Select the **Revision** that you want to roll back to. By default, Rancher saves up to the last 10 revisions.
+
+5. (Optional) Select whether or not you want to force the catalog application to be upgraded by checking the box for **Delete and recreate resources if needed during the upgrade**.
+
+ > In Kubernetes, some fields are designed to be immutable or cannot be updated directly. As of v2.2.0, you can now force your catalog application to be updated regardless of these fields. This will cause the catalog apps to be deleted and resources to be re-created if needed during the rollback.
+
+7. Click **Rollback**.
+
+**Result**: Your application is updated. You can view the application status from the project's:
+
+- **Workloads** view
+- **Apps** view. In versions prior to v2.2.0, this is the **Catalog Apps** view.
+
+### Deleting Catalog Application Deployments
+
+As a safeguard to prevent you from unintentionally deleting other catalog applications that share a namespace, deleting catalog applications themselves does not delete the namespace they're assigned to. Therefore, when you want to delete a deployed catalog application, assuming that it's the only app in its namespace, delete the namespace rather than the catalog app itself. Deleting the namespace deletes both the namespace and the catalog app, whereas deleting the catalog app only deletes the app but not the namespace.
+
+1. From the **Global** view, navigate to the project that contains the catalog application that you want to delete.
+
+1. From the main menu, choose **Namespaces**.
+
+1. Find the namespace running your catalog app. Select it and click **Delete**.
+
+**Result:** The catalog application deployment and its namespace are deleted.
diff --git a/content/rancher/v2.x/en/catalog/built-in/_index.md b/content/rancher/v2.x/en/catalog/built-in/_index.md
new file mode 100644
index 00000000000..54a1268c88f
--- /dev/null
+++ b/content/rancher/v2.x/en/catalog/built-in/_index.md
@@ -0,0 +1,35 @@
+---
+title: Built-in Global Catalogs
+weight: 4000
+aliases:
+ - /rancher/v2.x/en/tasks/global-configuration/catalog/enabling-default-catalogs/
+---
+
+There are default [global catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/#global-catalogs) packaged as part of Rancher.
+
+## Managing Built-in Global Catalogs
+
+>**Prerequisites:** In order to manage the built-in catalogs or [manage global catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/adding/#adding-global-catalogs), you need _one_ of the following permissions:
+>
+>- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/)
+>- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Catalogs]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#global-permissions-reference) role assigned.
+
+1. From the **Global** view, choose **Tools > Catalogs** in the navigation bar. In versions prior to v2.2.0, you can select **Catalogs** directly in the navigation bar.
+
+2. Toggle the default catalogs that you want use to a setting of **Enabled**.
+
+ - **Library**
+
+ The Library Catalog includes charts curated by Rancher. Rancher stores charts in a Git repository to expedite the fetch and update of charts. In Rancher 2.x, only global catalogs are supported. Support for cluster-level and project-level charts will be added in the future.
+
+ This catalog features Rancher Charts, which include some [notable advantages]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/#chart-types) over native Helm charts.
+
+ - **Helm Stable**
+
+ This catalog, , which is maintained by the Kubernetes community, includes native [Helm charts](https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/getting_started.md). This catalog features the largest pool of apps.
+
+ - **Helm Incubator**
+
+ Similar in user experience to Helm Stable, but this catalog is filled with applications in **beta**.
+
+ **Result**: The chosen catalogs are enabled. Wait a few minutes for Rancher to replicate the catalog charts. When replication completes, you'll be able to see them in any of your projects by selecting **Apps** from the main navigation bar. In versions prior to v2.2.0, within a project, you can select **Catalog Apps** from the main navigation bar.
diff --git a/content/rancher/v2.x/en/catalog/custom/_index.md b/content/rancher/v2.x/en/catalog/custom/_index.md
index b553ec9d658..771097c6ec6 100644
--- a/content/rancher/v2.x/en/catalog/custom/_index.md
+++ b/content/rancher/v2.x/en/catalog/custom/_index.md
@@ -1,169 +1,64 @@
---
-title: Custom Catalogs and Charts
+title: Custom Catalogs
weight: 4020
aliases:
- - /rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts/
+
---
-Rancher's catalog service requires any custom catalogs to be structured in a specific format for the catalog service to be able to leverage it in Rancher. Any custom catalog must be a public Git repository. The URL needs to be one that `git clone` [can handle](https://git-scm.com/docs/git-clone#_git_urls_a_id_urls_a) and must end in `.git`.
+Any user can [create custom catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/creating/) to add into Rancher. Besides the content of the catalog, users must ensure their catalogs are able to be added into Rancher.
-## Chart Types
+## Types of Repositories
-Rancher supports two different types of charts:
+Rancher supports adding in different types of repositories as a catalog:
-- **Helm Charts**
+* Custom Git Repository
+* Custom Helm Chart Repository
- Native Helm charts include an application along with other software required to run it. When deploying native Helm charts, you'll learn the chart's parameters and then configure them using **Answers**, which are sets of key value pairs.
+### Custom Git Repository
- The Helm Stable and Helm Incubators are populated with native Helm charts. However, you can also use native Helm charts in Custom catalogs (although we recommend Rancher Charts).
+The Git URL needs to be one that `git clone` [can handle](https://git-scm.com/docs/git-clone#_git_urls_a_id_urls_a) and must end in `.git`. The branch name must be a branch that is in your catalog URL. If no branch name is provided, it will default to use the `master` branch. Whenever you add a catalog to Rancher, it will be available almost immediately.
-- **Rancher Charts**
+### Custom Helm Chart Repository
- Rancher charts mirror native helm charts, although they add two files that enhance user experience: `app-readme.md` and `questions.yaml`. Read more about them in [Rancher Chart Additional Files](#rancher-chart-additional-files).
+A Helm chart repository is an HTTP server that contains one or more packaged charts. Any HTTP server that can serve YAML files and tar files and can answer GET requests can be used as a repository server.
- Advantages of Rancher charts include:
+Helm comes with a built-in package server for developer testing (`helm serve`). The Helm team has tested other servers, including Google Cloud Storage with website mode enabled, S3 with website mode enabled or hosting custom chart repository server using open-source projects like [ChartMuseum](https://github.com/helm/chartmuseum).
- - **Enhanced Revision Tracking**
+In Rancher, you can add the custom Helm chart repository with only a catalog name and the URL address of the chart repository.
- While Helm supports versioned deployments, Rancher adds tracking and revision history to display changes between different versions of the chart.
+## Catalog Fields
- - **Streamlined Application Launch**
-
- Rancher charts add simplified chart descriptions and configuration forms to make catalog application deployment easy. Rancher users need not read through the entire list of Helm variables to understand how to launch an application.
-
- - **Application Resource Management**
-
- Rancher tracks all the resources created by a specific application. Users can easily navigate to and troubleshoot on a page listing all the workload objects used to power an application.
-
-## Chart Directory Structure
-
-The following table demonstrates the directory structure for a chart, which can be found in a chart directory: `charts///`. This information is helpful when customizing charts for a custom catalog. Files denoted with **Rancher Specific** are specific to Rancher charts, but are optional for chart customization.
-
-```
-charts///
-|--charts/ # Directory containing dependency charts.
-|--templates/ # Directory containing templates that, when combined with values.yml, generates Kubernetes YAML.
-|--app-readme.md # Text displayed in the charts header within the Rancher UI.*
-|--Chart.yml # Required Helm chart information file.
-|--questions.yml # Form questions displayed within the Rancher UI. Questions display in Configuration Options.*
-|--README.md # Optional: Helm Readme file displayed within Rancher UI. This text displays in Detailed Descriptions.
-|--requirements.yml # Optional: YAML file listing dependencies for the chart.
-|--values.yml # Default configuration values for the chart.
-```
-
-## Rancher Chart Additional Files
-
-Before you create your own custom catalog, you should have a basic understanding about how a Rancher chart differs from a native Helm chart. Rancher charts differ slightly from Helm charts in their directory structures. Rancher charts include two files that Helm charts do not.
-
-- `app-readme.md`
-
- A file that provides descriptive text in the chart's UI header. The following image displays the difference between a Rancher chart (which includes `app-readme.md`) and a native Helm chart (which does not).
-
- Rancher Chart with app-readme.md (left) vs. Helm Chart without (right)
-
- 
-
-- `questions.yml`
-
- A file that contains questions for a form. These form questions simplify deployment of a chart. Without it, you must configure the deployment using key value pairs, which is more difficult. The following image displays the difference between a Rancher chart (which includes `questions.yml`) and a native Helm chart (which does not).
+When [adding your catalog]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/adding/) to Rancher, you'll provide the following information:
- Rancher Chart with questions.yml (left) vs. Helm Chart without (right)
+| Variable | Description |
+| -------------------- | ------------- |
+| Name | Name for your custom catalog to distinguish the repositories in Rancher |
+| Catalog URL | URL of your custom chart repository|
+| Use Private Catalog | Selected if you are using a private repository that requires authentication |
+| Username (Optional) | [Username](#using-username-and-password) or [OAuth Token](#using-an-oauth-token) |
+| Password (Optional) | If you are authenticating using [username](#using-username-and-password), the associated password. If you are using an [OAuth Token](#using-an-oauth-token), use `x-oauth-basic`. |
+| Branch | For a Git repository, the branch name. Default: `master`. For a Helm Chart repository, this field is ignored. |
- 
+## Private Repositories
+_Available as of v2.2.0_
-### Question Variable Reference
+Private Git or Helm chart repositories can be added into Rancher using either credentials, i.e. `Username` and `Password`. Private Git repositories also support authentication using OAuth tokens.
-This reference contains variables that you can use in `questions.yml`.
+### Using Username and Password
-| Variable | Type | Required | Description |
-| ------------- | ------------- | --- |------------- |
-| variable | string | true | Define the variable name specified in the `values.yml` file, using `foo.bar` for nested objects. |
-| label | string | true | Define the UI label. |
-| description | string | false | Specify the description of the variable.|
-| type | string | false | Default to `string` if not specified (current supported types are string, boolean, int, enum, password, storageclass and hostname).|
-| required | bool | false | Define if the variable is required or not (true \| false)|
-| default | string | false | Specify the default value. |
-| group | string | false | Group questions by input value. |
-| min_length | int | false | Min character length.|
-| max_length | int | false | Max character length.|
-| min | int | false | Min integer length. |
-| max | int | false | Max integer length. |
-| options | []string | false | Specify the options when the variable type is `enum`, for example: options: - "ClusterIP" - "NodePort" - "LoadBalancer"|
-| valid_chars | string | false | Regular expression for input chars validation. |
-| invalid_chars | string | false | Regular expression for invalid input chars validation.|
-| subquestions | []subquestion | false| Add an array of subquestions.|
-| show_if | string | false | Show current variable if conditional variable is true. For example `show_if: "serviceType=Nodeport"` |
-| show\_subquestion_if | string | false | Show subquestions if is true or equal to one of the options. for example `show_subquestion_if: "true"`|
+1. When [adding the catalog]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/adding/), select the **Use private catalog** checkbox.
->**Note:** `subquestions[]` cannot contain `subquestions` or `show_subquestions_if` keys, but all other keys in the above table are supported.
+2. Provide the `Username` and `Password` for your Git or Helm repository.
+### Using an OAuth token
-## Example Custom Chart Creation
+Read [using Git over HTTPS and OAuth](https://github.blog/2012-09-21-easier-builds-and-deployments-using-git-over-https-and-oauth/) for more details on how OAuth authentication works.
- You can fill your custom catalogs with either Helm Charts or Rancher Charts, although we recommend Rancher Charts due to their enhanced user experience.
+1. Create an [OAuth token](https://github.com/settings/tokens)
+with `repo` permission selected, and click **Generate token**.
->**Note:** For a complete walkthrough of developing charts, see the upstream Helm chart [developer reference](https://docs.helm.sh/developing_charts/).
+2. When [adding the catalog]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/adding/), select the **Use private catalog** checkbox.
-1. Within the GitHub repo that you're using as your custom catalog, create a directory structure that mirrors the structure listed in [Chart Directory Structure](#chart-directory-structure).
-
- Rancher requires this directory structure, although `app-readme.md` and `questions.yml` are optional.
-
- >**Tip:**
- >
- >- To begin customizing a chart, copy one from either the [Rancher Library](https://github.com/rancher/charts) or the [Helm Stable](https://github.com/kubernetes/charts/tree/master/stable).
- >- For a complete walk through of developing charts, see the upstream Helm chart [developer reference](https://docs.helm.sh/developing_charts/).
-
-2. **Recommended:** Create an `app-readme.md` file.
-
- Use this file to create custom text for your chart's header in the Rancher UI. You can use this text to notify users that the chart is customized for your environment or provide special instruction on how to use it.
-
-
- **Example**:
-
- ```
- $ cat ./app-readme.md
-
- # Wordpress ROCKS!
- ```
-
-3. **Recommended:** Create a `questions.yml` file.
-
- This file creates a form for users to specify deployment parameters when they deploy the custom chart. Without this file, users **must** specify the parameters manually using key value pairs, which isn't user-friendly.
-
-
- The example below creates a form that prompts users for persistent volume size and a storage class.
-
-
- For a list of variables you can use when creating a `questions.yml` file, see [Question Variable Reference](#question-variable-reference).
-
-
-
-4. Check the customized chart into your GitHub repo.
-
-**Result:** Your custom chart is added to the repo. Your Rancher Server will replicate the chart within a few minutes.
+3. For `Username`, provide the Git generated OAuth token. For `Password`, enter `x-oauth-basic`.
diff --git a/content/rancher/v2.x/en/catalog/custom/adding/_index.md b/content/rancher/v2.x/en/catalog/custom/adding/_index.md
new file mode 100644
index 00000000000..f3813c01404
--- /dev/null
+++ b/content/rancher/v2.x/en/catalog/custom/adding/_index.md
@@ -0,0 +1,58 @@
+---
+title: Adding Custom Catalogs
+weight: 4005
+aliases:
+ - /rancher/v2.x/en/tasks/global-configuration/catalog/adding-custom-catalogs/
+---
+
+[Custom catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/) can be added into Rancher at any [scope of Rancher]({{< baseurl >}}/rancher/v2.x/en/catalog/#catalog-scope).
+
+## Adding Global Catalogs
+
+>**Prerequisites:** In order to manage the [built-in catalogs]({{< baseurl >}}/rancher/v2.x/en/catalog/built-in/) or manage global catalogs, you need _one_ of the following permissions:
+>
+>- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/)
+>- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Catalogs]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#global-permissions-reference) role assigned.
+
+ 1. From the **Global** view, choose **Tools > Catalogs** in the navigation bar. In versions prior to v2.2.0, you can select **Catalogs** directly in the navigation bar.
+ 2. Click **Add Catalog**.
+ 3. Complete the form and click **Create**.
+
+ **Result**: Your custom global catalog is added to Rancher. Once it is in `Active` state, it has completed synchronization and you will be able to start deploying [multi-cluster apps]({{< baseurl >}}/rancher/v2.x/en/catalog/multi-cluster-apps/) or [applications in any project]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/) from this catalog.
+
+## Adding Cluster Catalogs
+
+_Available as of v2.2.0_
+
+>**Prerequisites:** In order to manage cluster scoped catalogs, you need _one_ of the following permissions:
+>
+>- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/)
+>- [Cluster Owner Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles)
+>- [Custom Cluster Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) with the [Manage Cluster Catalogs]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-role-reference) role assigned.
+
+1. From the **Global** view, navigate to your cluster that you want to start adding custom catalogs.
+2. Choose the **Tools > Catalogs** in the navigation bar.
+2. Click **Add Catalog**.
+3. Complete the form. By default, the form will provide the ability to select `Scope` of the catalog. When you have added a catalog from the **Cluster** scope, it is defaulted to `Cluster`.
+5. Click **Create**.
+
+**Result**: Your custom cluster catalog is added to Rancher. Once it is in `Active` state, it has completed synchronization and you will be able to start deploying [applications in any project in that cluster]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/) from this catalog.
+
+## Adding Project Level Catalogs
+
+_Available as of v2.2.0_
+
+>**Prerequisites:** In order to manage project scoped catalogs, you need _one_ of the following permissions:
+>
+>- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/)
+>- [Cluster Owner Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles)
+>- [Project Owner Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles)
+>- [Custom Project Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) with the [Manage Project Catalogs]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-role-reference) role assigned.
+
+1. From the **Global** view, navigate to your project that you want to start adding custom catalogs.
+2. Choose the **Tools > Catalogs** in the navigation bar.
+2. Click **Add Catalog**.
+3. Complete the form. By default, the form will provide the ability to select `Scope` of the catalog. When you have added a catalog from the **Project** scope, it is defaulted to `Cluster`.
+5. Click **Create**.
+
+**Result**: Your custom project catalog is added to Rancher. Once it is in `Active` state, it has completed synchronization and you will be able to start deploying [applications in that project]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/) from this catalog.
diff --git a/content/rancher/v2.x/en/catalog/custom/creating/_index.md b/content/rancher/v2.x/en/catalog/custom/creating/_index.md
new file mode 100644
index 00000000000..582cdbce5c0
--- /dev/null
+++ b/content/rancher/v2.x/en/catalog/custom/creating/_index.md
@@ -0,0 +1,169 @@
+---
+title: Creating Custom Catalogs
+weight: 4000
+aliases:
+ - /rancher/v2.x/en/tasks/global-configuration/catalog/customizing-charts/
+---
+
+Rancher's catalog service requires any custom catalogs to be structured in a specific format for the catalog service to be able to leverage it in Rancher.
+
+## Chart Types
+
+Rancher supports two different types of charts:
+
+- **Helm Charts**
+
+ Native Helm charts include an application along with other software required to run it. When deploying native Helm charts, you'll learn the chart's parameters and then configure them using **Answers**, which are sets of key value pairs.
+
+ The Helm Stable and Helm Incubators are populated with native Helm charts. However, you can also use native Helm charts in Custom catalogs (although we recommend Rancher Charts).
+
+- **Rancher Charts**
+
+ Rancher charts mirror native helm charts, although they add two files that enhance user experience: `app-readme.md` and `questions.yaml`. Read more about them in [Rancher Chart Additional Files](#rancher-chart-additional-files).
+
+ Advantages of Rancher charts include:
+
+ - **Enhanced Revision Tracking**
+
+ While Helm supports versioned deployments, Rancher adds tracking and revision history to display changes between different versions of the chart.
+
+ - **Streamlined Application Launch**
+
+ Rancher charts add simplified chart descriptions and configuration forms to make catalog application deployment easy. Rancher users need not read through the entire list of Helm variables to understand how to launch an application.
+
+ - **Application Resource Management**
+
+ Rancher tracks all the resources created by a specific application. Users can easily navigate to and troubleshoot on a page listing all the workload objects used to power an application.
+
+## Chart Directory Structure
+
+The following table demonstrates the directory structure for a chart, which can be found in a chart directory: `charts///`. This information is helpful when customizing charts for a custom catalog. Files denoted with **Rancher Specific** are specific to Rancher charts, but are optional for chart customization.
+
+```
+charts///
+|--charts/ # Directory containing dependency charts.
+|--templates/ # Directory containing templates that, when combined with values.yml, generates Kubernetes YAML.
+|--app-readme.md # Text displayed in the charts header within the Rancher UI.*
+|--Chart.yml # Required Helm chart information file.
+|--questions.yml # Form questions displayed within the Rancher UI. Questions display in Configuration Options.*
+|--README.md # Optional: Helm Readme file displayed within Rancher UI. This text displays in Detailed Descriptions.
+|--requirements.yml # Optional: YAML file listing dependencies for the chart.
+|--values.yml # Default configuration values for the chart.
+```
+
+## Rancher Chart Additional Files
+
+Before you create your own custom catalog, you should have a basic understanding about how a Rancher chart differs from a native Helm chart. Rancher charts differ slightly from Helm charts in their directory structures. Rancher charts include two files that Helm charts do not.
+
+- `app-readme.md`
+
+ A file that provides descriptive text in the chart's UI header. The following image displays the difference between a Rancher chart (which includes `app-readme.md`) and a native Helm chart (which does not).
+
+ Rancher Chart with app-readme.md (left) vs. Helm Chart without (right)
+
+ 
+
+- `questions.yml`
+
+ A file that contains questions for a form. These form questions simplify deployment of a chart. Without it, you must configure the deployment using key value pairs, which is more difficult. The following image displays the difference between a Rancher chart (which includes `questions.yml`) and a native Helm chart (which does not).
+
+
+ Rancher Chart with questions.yml (left) vs. Helm Chart without (right)
+
+ 
+
+
+### Question Variable Reference
+
+This reference contains variables that you can use in `questions.yml`.
+
+| Variable | Type | Required | Description |
+| ------------- | ------------- | --- |------------- |
+| variable | string | true | Define the variable name specified in the `values.yml` file, using `foo.bar` for nested objects. |
+| label | string | true | Define the UI label. |
+| description | string | false | Specify the description of the variable.|
+| type | string | false | Default to `string` if not specified (current supported types are string, boolean, int, enum, password, storageclass and hostname).|
+| required | bool | false | Define if the variable is required or not (true \| false)|
+| default | string | false | Specify the default value. |
+| group | string | false | Group questions by input value. |
+| min_length | int | false | Min character length.|
+| max_length | int | false | Max character length.|
+| min | int | false | Min integer length. |
+| max | int | false | Max integer length. |
+| options | []string | false | Specify the options when the variable type is `enum`, for example: options: - "ClusterIP" - "NodePort" - "LoadBalancer"|
+| valid_chars | string | false | Regular expression for input chars validation. |
+| invalid_chars | string | false | Regular expression for invalid input chars validation.|
+| subquestions | []subquestion | false| Add an array of subquestions.|
+| show_if | string | false | Show current variable if conditional variable is true. For example `show_if: "serviceType=Nodeport"` |
+| show\_subquestion_if | string | false | Show subquestions if is true or equal to one of the options. for example `show_subquestion_if: "true"`|
+
+>**Note:** `subquestions[]` cannot contain `subquestions` or `show_subquestions_if` keys, but all other keys in the above table are supported.
+
+
+## Example Custom Chart Creation
+
+ You can fill your custom catalogs with either Helm Charts or Rancher Charts, although we recommend Rancher Charts due to their enhanced user experience.
+
+>**Note:** For a complete walkthrough of developing charts, see the upstream Helm chart [developer reference](https://docs.helm.sh/developing_charts/).
+
+1. Within the GitHub repo that you're using as your custom catalog, create a directory structure that mirrors the structure listed in [Chart Directory Structure](#chart-directory-structure).
+
+ Rancher requires this directory structure, although `app-readme.md` and `questions.yml` are optional.
+
+ >**Tip:**
+ >
+ >- To begin customizing a chart, copy one from either the [Rancher Library](https://github.com/rancher/charts) or the [Helm Stable](https://github.com/kubernetes/charts/tree/master/stable).
+ >- For a complete walk through of developing charts, see the upstream Helm chart [developer reference](https://docs.helm.sh/developing_charts/).
+
+2. **Recommended:** Create an `app-readme.md` file.
+
+ Use this file to create custom text for your chart's header in the Rancher UI. You can use this text to notify users that the chart is customized for your environment or provide special instruction on how to use it.
+
+
+ **Example**:
+
+ ```
+ $ cat ./app-readme.md
+
+ # Wordpress ROCKS!
+ ```
+
+3. **Recommended:** Create a `questions.yml` file.
+
+ This file creates a form for users to specify deployment parameters when they deploy the custom chart. Without this file, users **must** specify the parameters manually using key value pairs, which isn't user-friendly.
+
+
+ The example below creates a form that prompts users for persistent volume size and a storage class.
+
+
+ For a list of variables you can use when creating a `questions.yml` file, see [Question Variable Reference](#question-variable-reference).
+
+
+
+4. Check the customized chart into your GitHub repo.
+
+**Result:** Your custom chart is added to the repo. Your Rancher Server will replicate the chart within a few minutes.
diff --git a/content/rancher/v2.x/en/catalog/globaldns/_index.md b/content/rancher/v2.x/en/catalog/globaldns/_index.md
new file mode 100644
index 00000000000..21a7b84a57d
--- /dev/null
+++ b/content/rancher/v2.x/en/catalog/globaldns/_index.md
@@ -0,0 +1,118 @@
+---
+title: Global DNS
+weight: 5010
+---
+
+_Available as of v2.2.0_
+
+Rancher's Global DNS feature provides a way to program an external DNS provider to route traffic to your Kubernetes applications. Since the DNS programming supports spanning applications across different Kubernetes clusters, Global DNS is configured at a global level. An application can become highly available as it allows you to have one application run on different Kubernetes clusters. If one of your Kubernetes clusters goes down, the application would still be accessible.
+
+> **Note:** Global DNS is only available in [HA setups]({{< baseurl >}}/rancher/v2.x/en/installation/ha/) with the [`local` cluster enabled]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#import-local-cluster).
+
+## Global DNS Providers
+
+Prior to adding in Global DNS entries, you will need to configure access to an external provider.
+
+The following table lists the first version of Rancher each provider debuted.
+
+| DNS Provider | Available as of |
+| --- | --- |
+| [AWS Route53](https://aws.amazon.com/route53/) | v2.2.0 |
+| [CloudFlare](https://www.cloudflare.com/dns/) | v2.2.0 |
+| [AliDNS](https://www.alibabacloud.com/product/dns) | v2.2.0 |
+
+## Global DNS Entries
+
+For each application that you want to route traffic to, you will need to create a Global DNS Entry. This entry will use a fully qualified domain name (a.k.a FQDN) from a global DNS provider to target applications. The applications can either resolve to a single [multi-cluster application]({{< baseurl >}}/rancher/v2.x/en/catalog/multi-cluster-apps/) or to specific projects. You must [add specific annotation labels](#adding-annotations-to-ingresses-to-program-the-external-dns) to the ingresses in order for traffic to be routed correctly to the applications. Without this annotation, the programming for the DNS entry will not work.
+
+## Permissions for Global DNS Providers/Entries
+
+By default, only [global administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) and the creator of the Global DNS provider or Global DNS entry have access to use, edit and delete them. When creating the provider or entry, the creator can add additional users in order for those users to access and manage them. By default, these members will get `Owner` role to manage them.
+
+## Setting up Global DNS for Applications
+
+### Add a Global DNS Provider
+
+1. From the **Global View**, select **Tools > Global DNS Providers**.
+1. To add a provider, choose from the available provider options and configure the Global DNS Provider with necessary credentials and an optional domain.
+1. (Optional) Add additional users so they could use the provider when creating Globel DNS entries as well as manage the Global DNS provider.
+
+{{% accordion id="route53" label="Route53" %}}
+1. Enter a **Name** for the provider.
+1. (Optional) Enter the **Root Domain** of the hosted zone on AWS Route53. If this is not provided, Rancher's Global DNS Provider will work with all hosted zones that the AWS keys can access.
+1. Enter the AWS **Access Key**.
+1. Enter the AWS **Secret Key**.
+1. Under **Member Access**, search for any users that you want to have the ability to use this provider. By adding this user, they will also be able to manage the Global DNS Provider entry.
+1. Click **Create**.
+{{% /accordion %}}
+{{% accordion id="cloudflare" label="CloudFlare" %}}
+1. Enter a **Name** for the provider.
+1. Enter the **Root Domain**, this field is optional, in case this is not provided, Rancher's Global DNS Provider will work with all domains that the keys can access.
+1. Enter the CloudFlare **API Email**.
+1. Enter the CloudFlare **API Key**.
+1. Under **Member Access**, search for any users that you want to have the ability to use this provider. By adding this user, they will also be able to manage the Global DNS Provider entry.
+1. Click **Create**.
+{{% /accordion %}}
+{{% accordion id="alidns" label="AliDNS" %}}
+1. Enter a **Name** for the provider.
+1. Enter the **Root Domain**, this field is optional, in case this is not provided, Rancher's Global DNS Provider will work with all domains that the keys can access.
+1. Enter the **Access Key**.
+1. Enter the **Secret Key**.
+1. Under **Member Access**, search for any users that you want to have the ability to use this provider. By adding this user, they will also be able to manage the Global DNS Provider entry.
+1. Click **Create**.
+
+>**Notes:**
+>
+>- Alibaba Cloud SDK uses TZ data. It needs to be present on `/usr/share/zoneinfo` path of the nodes running [`local` cluster]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#import-local-cluster), and it is mounted to the external DNS pods. If it is not available on the nodes, please follow the [instruction](https://www.ietf.org/timezones/tzdb-2018f/tz-link.html) to prepare it.
+>- Different versions of AliDNS have different allowable TTL range, where the default TTL for a global DNS entry may not be valid. Please see the [reference](https://www.alibabacloud.com/help/doc-detail/34338.htm) before adding an AliDNS entry.
+{{% /accordion %}}
+
+### Add a Global DNS Entry
+
+1. From the **Global View**, select **Tools > Global DNS Entries**.
+1. Click on **Add DNS Entry**.
+1. Enter the **FQDN** you wish to program on the external DNS.
+1. Select a Global DNS **Provider** from the list.
+1. Select if this DNS entry will be for a [multi-cluster application]({{< baseurl >}}/rancher/v2.x/en/catalog/multi-cluster-apps/) or for workloads in different [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/). You will need to ensure that [annotations are added to any ingresses](#adding-annotations-to-ingresses-to-program-the-external-dns) for the applications that you want to target.
+1. Configure the **DNS TTL** value in seconds. By default, it will be 300 seconds.
+1. Under **Member Access**, search for any users that you want to have the ability to manage this Global DNS entry.
+
+## Adding Annotations to Ingresses to program the External DNS
+
+In order for Global DNS entries to be programmed, you will need to add a specific annotation on an ingress in your application or target project and this ingress needs to use a specific `hostname` and an annotation that should match the FQDN of the Global DNS entry.
+
+1. For any application that you want targetted for your Global DNS entry, find an ingress associated with the application.
+1. In order for the DNS to be programmed, the following requirements must be met:
+ * The ingress routing rule must be set to use a `hostname` that matches the FQDN of the Global DNS entry.
+ * The ingress must have an annotation (`rancher.io/globalDNS.hostname`) and the value of this annotation should match the FQDN of the Global DNS entry.
+1. Once the ingress in your [multi-cluster application]({{< baseurl >}}/rancher/v2.x/en/catalog/multi-cluster-apps/) or in your target projects are in `active` state, the FQDN will be programmed on the external DNS against the Ingress IP addresses.
+
+## Editing a Global DNS Provider
+
+The [global administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), creator of the Global DNS provider and any users added as `members` to a Global DNS provider, have _owner_ access to that provider. Any members can edit the following fields:
+
+- Root Domain
+- Access Key & Secret Key
+- Members
+
+1. From the **Global View**, select **Tools > Global DNS Providers**.
+
+1. For the Global DNS provider that you want to edit, click the **Vertical Ellipsis (...) > Edit**.
+
+## Editing a Global DNS Entry
+
+The [global administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), creator of the Global DNS entry and any users added as `members` to a Global DNS entry, have _owner_ access to that DNS entry. Any members can edit the following fields:
+
+- FQDN
+- Global DNS Provider
+- Target Projects or Multi-Cluster App
+- DNS TTL
+- Members
+
+Any users who can access the Global DNS entry can **only** add target projects that they have access to. However, users can remove **any** target project as there is no check to confirm if that user has access to the target project.
+
+Permission checks are relaxed for removing target projects in order to support situations where the user's permissions might have changed before they were able to delete the target project. Another use case could be that the target project was removed from the cluster before being removed from a target project of the Global DNS entry.
+
+1. From the **Global View**, select **Tools > Global DNS Entries**.
+
+1. For the Global DNS entry that you want to edit, click the **Vertical Ellipsis (...) > Edit**.
diff --git a/content/rancher/v2.x/en/catalog/multi-cluster-apps/_index.md b/content/rancher/v2.x/en/catalog/multi-cluster-apps/_index.md
new file mode 100644
index 00000000000..62936ccb55a
--- /dev/null
+++ b/content/rancher/v2.x/en/catalog/multi-cluster-apps/_index.md
@@ -0,0 +1,139 @@
+---
+title: Multi-Cluster Apps
+weight: 5000
+---
+_Available as of v2.2.0_
+
+Typically, most applications are deployed on a single Kubernetes cluster, but there will be times you might want to deploy multiple copies of the same application across different clusters and/or projects. In Rancher, a _multi-cluster application_, is an application deployed using a Helm chart across multiple clusters. With the ability to deploy the same application across multiple clusters, it avoids the repetition of the same action on each cluster, which could introduce user error during application configuration. With multi-cluster applications, you can customize to have the same configuration across all projects/clusters as well as have the ability to change the configuration based on your target project. Since multi-cluster application is considered a single application, it's easy to manage and maintain this application.
+
+Any Helm charts from a [global catalog]({{< baseurl >}}/rancher/v2.x/en/catalog/#catalog-scope) can be used to deploy and manage multi-cluster applications.
+
+After creating a multi-cluster application, you can program a [Global DNS entry]({{< baseurl >}}/rancher/v2.x/en/catalog/globaldns/) to make it easier to access the application.
+
+## Launching a Multi-Cluster App
+
+1. From the **Global** view, choose **Apps** in the navigation bar. Click **Launch**.
+
+2. Find the application that you want to launch, and then click **View Details**.
+
+3. (Optional) Review the detailed descriptions, which are derived from the Helm chart's `README`.
+
+4. Under **Configuration Options** enter a **Name** for the multi-cluster application. By default, this name is also used to create a Kubernetes namespace in each [target project](#targets) for the multi-cluster application. The namespace is named as `-`.
+
+5. Select a **Template Version**.
+
+6. Complete the [multi-cluster applications specific configuration options](#configuration-options-to-make-a-multi-cluster-app) as well as the [application configuration options](#application-configuration-options).
+
+7. Select the **Members** who can [interact with the multi-cluster application](#members).
+
+8. Add any [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects) that would change the configuration for specific project(s) from the default application configuration answers.
+
+7. Review the files in the **Preview** section. When you're satisfied, click **Launch**.
+
+**Result**: Your application is deployed to your chosen namespace. You can view the application status from the project's:
+
+### Configuration Options to Make a Multi-Cluster App
+
+Rancher has divided the configuration option for the multi-cluster application into several sections.
+
+#### Targets
+
+In the **Targets** section, select the [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects) that you want the application to be deployed in. The list of projects is based on what projects you have access to. For each project that you select, it will be added to the list, which shows the cluster name and project name that were selected. To remove a target project, click on **-**.
+
+#### Upgrades
+
+In the **Upgrades** section, select the upgrade strategy to use, when you decide to upgrade your application.
+
+* **Rolling Update (batched):** When selecting this upgrade strategy, the number of applications upgraded at a time is based on the selected **Batch size** and the **Interval** specifies how many seconds to wait before starting the next batch of updates.
+
+* **Upgrade all apps simultaneously:** When selecting this upgrade strategy, all applications across all projects will be upgraded at the same time.
+
+#### Roles
+
+In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/#launching-catalog-applications), that specific users's permissions are used for creation of all workloads/resources that is required by the app.
+
+For multi-cluster applications, the application is deployed by a _system user_ and is assigned as the creator of all underlying resources. A _system user_ is used instead of the actual user due to the fact that the actual user could be removed from one of the target projects. If the actual user was removed from one of the projects, then that user would no longer be able to manage the application for the other projects.
+
+Rancher will let you select from two options for Roles, **Project** and **Cluster**. Rancher will allow creation using any of these roles based on the user's permissions.
+
+- **Project** - This is the equivalent of a [project member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [project member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) role. While the user might not be explicitly granted the _project member_ role, if the user is an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), a [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or a [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles), then the user is considered to have the appropriate level of permissions.
+
+- **Cluster** - This is the equivalent of a [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) role. While the user might not be explicitly granted the _cluster owner_ role, if the user is an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), then the user is considered to have the appropriate level of permissions.
+
+When launching the application, Rancher will confirm if you have these permissions in the target projects before launching the application.
+
+> **Note:** There are some applications like _Grafana_ or _Datadog_ that require access to specific cluster-scoped resources. These applications will require the _Cluster_ role. If you find out later that the application requires cluster roles, the multi-cluster application can be upgraded to update the roles.
+
+### Application Configuration Options
+
+For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://github.com/helm/helm/blob/master/docs/using_helm.md#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm.
+
+> For example, when entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is reuired to wrap the values with double quotes (i.e., ``"abc, bcd"``).
+
+#### Using a `questions.yml` file
+
+If the Helm chart that you are deploying contains a `questions.yml` file, Rancher's UI will translate this file to display an easy to use UI to collect the answers for the questions.
+
+#### Key Value Pairs for Native Helm Charts
+
+For native Helm charts (i.e., charts from the **Helm Stable** or **Helm Incubator** catalogs or a [custom Helm chart repository]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/#custom-helm-chart-repository)), answers are provided as key value pairs in the **Answers** section. These answers are used to override the default values.
+
+### Members
+
+By default, multi-cluster applications can only be managed by the user who created it. In the **Members** section, other users can be added so that they can also help manage or view the multi-cluster application.
+
+1. Find the user that you want to add by typing in the member's name in the **Member** search box.
+
+2. Select the **Access Type** for that member. There are three access types for a multi-cluster project, but due to how the permissions of a multi-cluster application are launched, please read carefully to understand what these access types mean.
+
+ - **Owner**: This access type can manage any configuration part of the multi-cluster application including the template version, the [multi-cluster applications specific configuration options](#configuration-options-to-make-a-multi-cluster-app), the [application specific configuration options](#application-configuration-options), the [members who can interact with the multi-cluster application](#members) and the [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects). Since a multi-cluster application is created with a different set of permissions from the user, any _owner_ of the multi-cluster application can manage/remove applications in [target projects](#targets) without explicitly having access to these project(s). Only trusted users should be provided with this access type.
+
+ - **Member**: This access type can only modify the template version, the [application specific configuration options](#application-configuration-options) and the [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects). Since a multi-cluster application is created with a different set of permissions from the user, any _member_ of the multi-cluster application can modify the application without explicitly having access to these project(s). Only trusted users should be provided with this access type.
+
+ - **Read-only**: This access type cannot modify any configuration option for the multi-cluster application. Users can only view these applications.
+
+ > **Note:** Please ensure only trusted users are given _Owner_ or _Member_ access as they will automatically be able to manage applications created for this multi-cluster application in target projects they might not have direct access to.
+
+### Overriding Application Configuration Options for Specific Projects
+
+The ability to use the same configuration to deploy the same application across multiple clusters/projects is one of the main benefits of multi-cluster applications. There might be a specific project that requires a slightly different configuration option, but you want to manage that application with all the other matching applications. Instead of creating a brand new application, you can override specific [application specific configuration options](#application-configuration-options) for specific projects.
+
+1. In the **Answer Overrides** section, click **Add Override**.
+
+2. For each override, you can select the following:
+
+ - **Scope**: Select which target projects you want to override the answer in the configuration option.
+
+ - **Question**: Select which question you want to override.
+
+ - **Answer**: Enter the answer that you want to be used instead.
+
+## Upgrading Multi-Cluster App Roles and Projects
+
+- **Changing Roles on an existing Multi-Cluster app**
+The creator and any users added with the access-type "owner" to a multi-cluster app, can upgrade its Roles. When adding a new Role, we check if the user has that exact role in all current target projects. These checks allow the same relaxations for global admins, cluster owners and project-owners as described in the installation section for the field `Roles`.
+
+- **Adding/Removing target projects**
+1. The creator and any users added with access-type "owner" to a multi-cluster app, can add or remove its target projects. When adding a new project, we check if the caller of this request has all Roles defined on multi-cluster app, in the new projects they want to add. The roles checks are again relaxed for global admins, cluster-owners and project-owners.
+2. We do not do these membership checks when removing target projects. This is because the caller's permissions could have with respect to the target project, or the project could have been deleted and hence the caller wants to remove it from targets list.
+
+
+## Multi-Cluster Application Management
+
+One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of manangement.Multi-cluster applications can be cloned, upgraded or rolled back.
+
+1. From the **Global** view, choose **Apps** in the navigation bar.
+
+2. Choose the multi-cluster application you want to take one of these actions on and click the **Vertical Ellipsis (...)**. Select one of the following options:
+
+ * **Clone**: Creates another multi-cluster application with the same configuration. By using this option, you can easily duplicate a multi-cluster application.
+ * **Upgrade**: Upgrade your multi-cluster application to change some part of the configuration. When performing an upgrade for multi-cluster application, the [upgrade strategy](#upgrade-strategy) can be modified if you have the correct [access type](#members).
+ * **Rollback**: Rollback your application to a specific version. If after an upgrade, there are issues for your multi-cluster application for one or more of your [targets](#targets), Rancher has stored up to 10 versions of the multi-cluster application. Rolling back a multi-cluster application reverts the application for **all** target clusters and projects, not just the targets(s) affected by the upgrade issue.
+
+## Deleting a Multi-Cluster Application
+
+1. From the **Global** view, choose **Apps** in the navigation bar.
+
+2. Choose the multi-cluster application you want to delete and click the **Vertical Ellipsis (...) > Delete**. When deleting the multi-cluster application, all applications and namespaces are deleted in all of the target projects.
+
+ > **Note:** The applications in the target projects, that are created for a multi-cluster application, cannot be deleted individually. The applications can only be deleted when the multi-cluster application is deleted.
diff --git a/content/rancher/v2.x/en/cli/_index.md b/content/rancher/v2.x/en/cli/_index.md
index 62aabed313f..de92ac71134 100644
--- a/content/rancher/v2.x/en/cli/_index.md
+++ b/content/rancher/v2.x/en/cli/_index.md
@@ -1,11 +1,11 @@
---
-title: Rancher CLI
+title: CLI
weight: 6000
aliases:
- /rancher/v2.x/en/concepts/cli-configuration/
---
-Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.
+The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.
### Download Rancher CLI
diff --git a/content/rancher/v2.x/en/cluster-admin/_index.md b/content/rancher/v2.x/en/cluster-admin/_index.md
new file mode 100644
index 00000000000..f86a2bc5e84
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/_index.md
@@ -0,0 +1,102 @@
+---
+title: Cluster Administration
+weight: 2005
+---
+
+## What's a Kubernetes Cluster?
+
+A cluster is a group of computers that work together as a single system.
+
+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_. 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 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 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
+
+[Worker nodes](https://kubernetes.io/docs/concepts/architecture/nodes/) run:
+
+- _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 necessary to run your workloads.
+
+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.
+
+## Switching between Clusters
+
+To switch between clusters, use the drop-down available in the navigation bar.
+
+Alternatively, you can switch between projects and clusters directly in the navigation bar. Open the **Global** view and select **Clusters** from the main menu. Then select the name of the cluster you want to open.
+
+## Managing Clusters in Rancher
+
+After clusters have been [provisioned into Rancher]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/), [cluster owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster.
+
+| Action | [Rancher launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) | [Hosted Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) | [Imported Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters) |
+| --- | --- | ---| ---|
+| [Using kubeconfig file to access a Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/kubeconfig/) | * | * | * |
+| [Using kubectl to Access a Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/kubectl/) | * | * | * |
+| [Adding Cluster Members]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/cluster-members/) | * | * | * |
+| [Editing Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) | * | * | * |
+| [Managing Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/nodes) | * | * | * |
+| [Managing Persistent Volumes and Storage Classes]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/) | * | * | * |
+| [Managing Projects and Namespaces]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/projects-and-namespaces/) | * | * | * |
+| [Configuring Tools](#configuring-tools) | * | * | * |
+| [Cloning Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/cloning-clusters/)| | * | * |
+| [Ability to rotate certificates]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/certificate-rotation/) | * | | |
+| [Ability to back up your Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/) | * | | |
+| [Ability to recover and restore etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/) | * | | |
+| [Cleaning Kubernetes components when clusters are no longer reachable from Rancher]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/) | * | | |
+
+## Configuring Tools
+
+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 following categories:
+
+- Alerts
+- Notifiers
+- Logging
+- Monitoring
+
+For more information, see [Tools]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/)
diff --git a/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md b/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md
new file mode 100644
index 00000000000..19eaa115c2b
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md
@@ -0,0 +1,72 @@
+---
+title: Backing up etcd
+weight: 2045
+---
+
+_Available as of v2.2.0_
+
+In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) can be easily performed. Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.
+
+Rancher recommends enabling the ability to set up recurring snapshots, but one-time snapshots can easily be taken as well.
+
+>**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Rancher, you must [edit the cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/).
+
+## Configuring Recurring Snapshots for the Cluster
+
+By default, any [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) are enabled to take recurring snapshots that are saved locally.
+
+During cluster provisioning or editing the cluster, the configuration about snapshots are in the advanced section for **Cluster Options**. Click on **Show advanced options**.
+
+In the **Advanced Cluster Options** section, there are several options available to configure:
+
+| Option | Description | Default Value|
+| --- | ---| --- |
+|[etcd Snapshot Backup Target](#snapshot-backup-targets)| Select where you want the snapshots to be saved. Options are either local or in S3 | local|
+|Recurring etcd Snapshot Enabled| Enable/Disable recurring snapshots | Yes|
+|[Recurring etcd Snapshot Creation Period](#snapshot-creation-period-and-retention-count) | Time in hours between recurring snapshots| 12 hours |
+|[Recurring etcd Snapshot Retention Count](#snapshot-creation-period-and-retention-count)| Number of snapshots to retain| 6 |
+
+### Snapshot Backup Targets
+
+Rancher supports two different backup targets:
+
+* [Local Target](#local-backup-target)
+* [S3 Target](#s3-backup-target)
+
+#### Local Backup Target
+
+By default, the `local` backup target is selected. The benefits of this option is that there is no external configuration. Snapshots are automatically saved locally to the etcd nodes in the [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/). All recurring snapshots are taken at configured intervals. The downside of using the `local` backup target is that if there is a total disaster and _all_ etcd nodes are lost, there is no ability to restore the cluster.
+
+#### S3 Backup Target
+
+The `S3` backup target allows users to configure a S3 compatible backend to store the snapshots. The main benefit of this option is that if the cluster loses all the etcd nodes, the cluster can still be restored as the snapshots are stored externally. The downside of using the `S3` backup target is that additional configuration is required in order to have these snapshots saved remotely.
+
+| Option | Description | Required|
+|---|---|---|
+|S3 Bucket Name| S3 bucket name where backups will be stored| *|
+|S3 Region|S3 region for the backup bucket| |
+|S3 Region Endpoint|S3 regions endpoint for the backup bucket|* |
+|S3 Access Key|S3 access key with permission to access the backup bucket|*|
+|S3 Secret Key|S3 secret key with permission to access the backup bucket|*|
+
+### Snapshot Creation Period and Retention Count
+
+Select how often you want recurring snapshots to be taken as well as how many snapshots to keep. The amount of time is measured in hours. With timestamped snapshots, the user has the ability to do a point-in-time recovery.
+
+## One-Time Snapshots
+
+Besides recurring snapshots, you might want to take a one-time snapshot in specific use cases. For example, if you're about to upgrade the Kubernetes version of your cluster, you might want to take a snapshot right before the upgrade.
+
+1. In the **Global** view, navigate to the cluster that you want to take a one-time snapshot.
+
+2. Click the **Vertical Ellipsis (...) > Snapshot Now**.
+
+**Result:** Based on your [snapshot backup target](#snapshot-backup-targets), a one-time snapshot will be taken and saved in the selected backup target.
+
+## Viewing Available Snapshots
+
+The list of all available snapshots for the cluster is available.
+
+1. In the **Global** view, navigate to the cluster that you want to view snapshots.
+
+2. Click **Tools > Snapshots** from the navigation bar to view the list of saved snapshots. These snapshots include a timestamp of when they were created.
diff --git a/content/rancher/v2.x/en/cluster-admin/certificate-rotation/_index.md b/content/rancher/v2.x/en/cluster-admin/certificate-rotation/_index.md
new file mode 100644
index 00000000000..e45f9fd710f
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/certificate-rotation/_index.md
@@ -0,0 +1,34 @@
+---
+title: Certificate Rotation
+weight: 2040
+---
+
+_Available as of v2.2.0_
+
+By default, Kubernetes clusters require certificates and Rancher launched Kubernetes clusters automatically generate certificates for the Kubernetes components. Rotating these certificates is important before the certificates expire as well as if a certificate is compromised. After the certificates are rotated, the Kubernetes components are automatically restarted.
+
+> **Note:** Even though the RKE CLI can use custom certificates for the Kubernetes cluster components, Rancher currently doesn't allow the ability to upload these in Rancher Launched Kubernetes clusters.
+
+Certificates can be rotated for the following services:
+
+- etcd
+- kubelet
+- kube-apiserver
+- kube-proxy
+- kube-scheduler
+- kube-controller-manager
+
+Rancher launched Kubernetes clusters have the ability to rotate the auto-generated certificates through the UI.
+
+1. In the **Global** view, navigate to the cluster that you want to rotate certificates.
+
+2. Select the **Ellipsis (...) > Rotate Certificates**.
+
+3. Select which certificates that you want to rotate.
+
+ * Rotate all Service certificates (keep the same CA)
+ * Rotate an individual service and choose one of the services from the drop down menu
+
+4. Click **Save**.
+
+**Results:** The selected certificates will be rotated and the related services will be restarted to start using the new certificate.
diff --git a/content/rancher/v2.x/en/admin-settings/removing-rancher/user-cluster-nodes/_index.md b/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md
similarity index 83%
rename from content/rancher/v2.x/en/admin-settings/removing-rancher/user-cluster-nodes/_index.md
rename to content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md
index f9c39f956b3..3d0ede984a5 100644
--- a/content/rancher/v2.x/en/admin-settings/removing-rancher/user-cluster-nodes/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md
@@ -1,14 +1,13 @@
---
-title: Removing Rancher Components from Rancher Launched Kubernetes Nodes
-weight: 375
+title: Cleaning up Clusters
+weight: 2055
aliases:
- - /rancher/v2.x/en/installation/removing-rancher/cleaning-cluster-nodes/
- - /rancher/v2.x/en/installation/removing-rancher/
- /rancher/v2.x/en/faq/cleaning-cluster-nodes/
+ - /rancher/v2.x/en/admin-settings/removing-rancher/user-cluster-nodes/
---
-When you use Rancher to [launch nodes for a cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#cluster-creation-in-rancher), resources (containers/virtual network interfaces) and configuration items (certificates/configuration files) are created.
+When you use Rancher to [launch nodes for a cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#cluster-creation-in-rancher), resources (containers/virtual network interfaces) and configuration items (certificates/configuration files) are created.
-When removing nodes from your Rancher-launched cluster (provided that they are in `Active` state), those resources 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.
+When removing nodes from your Rancher launched Kubernetes cluster (provided that they are in `Active` state), those resources 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.
## What Gets Removed?
@@ -20,16 +19,16 @@ When cleaning nodes provisioned using Rancher, the following components are dele
| `serviceAccount`, `clusterRoles`, and `clusterRoleBindings` labeled by Rancher | ✓ | ✓ | ✓ | ✓ |
| Labels, Annotations, and Finalizers | ✓ | ✓ | ✓ | ✓ |
| Rancher Deployment | ✓ | ✓ | ✓ | |
-| Machines, clusters, projects, and user custom resource deployments (CRDs) | ✓ | ✓ | ✓ | |
+| Machines, clusters, projects, and user custom resource definitions (CRDs) | ✓ | ✓ | ✓ | |
| All resources create under the `management.cattle.io` API Group | ✓ | ✓ | ✓ | |
-| All CRDs created by Rancher v2.0.x | ✓ | ✓ | ✓ | |
+| All CRDs created by Rancher v2.x | ✓ | ✓ | ✓ | |
[1]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/
[2]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/
[3]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/
[4]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/
-## Removing A Node from a Cluster by Rancher UI
+## Removing a Node from a Cluster by Rancher UI
When the node is in `Active` state, removing the node from a cluster will trigger a process to clean up the node. Please restart the node after the automatic cleanup process is done to make sure any non-persistent data is properly removed.
@@ -37,10 +36,10 @@ When the node is in `Active` state, removing the node from a cluster will trigge
```
# using reboot
-reboot
+$ sudo reboot
# using shutdown
-shutdown -r now
+$ sudo shutdown -r now
```
## Cleaning a Node Manually
@@ -51,7 +50,7 @@ When a node is unreachable and removed from the cluster, the automatic cleaning
## Imported Cluster Nodes
-For imported clusters, the process for removing Rancher from its nodes is a little different. You can the option of simply deleting the cluster in the Rancher UI, or your can run a script that removes Rancher components from the nodes. Both options make the same deletions.
+For imported clusters, the process for removing Rancher from its nodes is a little different. You have the option of simply deleting the cluster in the Rancher UI, or your can run a script that removes Rancher components from the nodes. Both options make the same deletions.
{{% tabs %}}
{{% tab "By UI / API" %}}
@@ -59,11 +58,11 @@ For imported clusters, the process for removing Rancher from its nodes is a litt
After you initiate the removal of an [imported cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#import-existing-cluster) using the Rancher UI (or API), the following events occur.
-1. Rancher creates a `serviceAccount` that it uses to remove the cluster. This account is assigned the [clusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole) and [clusterRoleBinding](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) permissions, which are required to remove the cluster.
+1. Rancher creates a `serviceAccount` that it uses to remove the cluster. This account is assigned the [clusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole) and [clusterRoleBinding](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) permissions, which are required to remove the cluster.
-1. Using the `serviceAccount`, Rancher schedules and runs a [job](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) that cleans the Rancher and Kubernetes components off of the node. This job also references the `serviceAccount` and its roles as dependencies, so the job deletes them before its completion.
-
-1. Rancher is removed from the cluster nodes. However, the cluster persists, running the native version of Kubernetes.
+1. Using the `serviceAccount`, Rancher schedules and runs a [job](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) that cleans the Rancher and Kubernetes components off of the node. This job also references the `serviceAccount` and its roles as dependencies, so the job deletes them before its completion.
+
+1. Rancher is removed from the cluster nodes. However, the cluster persists, running the native version of Kubernetes.
**Result:** All components listed for imported clusters in [What Gets Removed?](#what-gets-removed) are deleted.
@@ -83,13 +82,13 @@ Rather than cleaning imported cluster nodes using the Rancher UI, you can run a
chmod +x user-cluster.sh
```
-1. **Air Gap Users Only:** Open `user-cluster.sh` and replace `yaml_url` with the URL in `user-cluster.yml`.
+1. **Air Gap Environments Only:** Open `user-cluster.sh` and replace `yaml_url` with the URL in `user-cluster.yml`.
- If you aren't an air gap user, skip this step.
+ If you don't have an air gap environment, skip this step.
1. From the same directory, run the script and provide the `rancher/rancher-agent` image version which should be equal to the version of Rancher used to manage the cluster. (``):
- >**Tip:**
+ >**Tip:**
>
>Add the `-dry-run` flag to preview the script's outcome without making changes.
```
@@ -97,14 +96,14 @@ Rather than cleaning imported cluster nodes using the Rancher UI, you can run a
```
**Result:** The script runs. All components listed for imported clusters in [What Gets Removed?](#what-gets-removed) are deleted.
-
+
{{% /tab %}}
{{% /tabs %}}
### Docker Containers, Images, and Volumes
-Based on what role you assigned to the node, Kubernetes components in containers, containers belonging to overlay networking, DNS, ingress controller and Rancher agent. (and pods you created that have been scheduled to this node)
+Based on what role you assigned to the node, there are Kubernetes components in containers, containers belonging to overlay networking, DNS, ingress controller and Rancher agent. (and pods you created that have been scheduled to this node)
**To clean all Docker containers, images and volumes:**
@@ -178,18 +177,16 @@ rm -rf /etc/ceph \
### Network Interfaces and Iptables
-The remaining two components that are changed/configured are (virtual) network interfaces and iptables rules. Both are non-persistent to the node, meaning that they will be cleared after a restart of the node.
-
-This is the recommended method.
+The remaining two components that are changed/configured are (virtual) network interfaces and iptables rules. Both are non-persistent to the node, meaning that they will be cleared after a restart of the node. To remove these components, a restart is recommended.
**To restart a node:**
```
# using reboot
-reboot
+$ sudo reboot
# using shutdown
-shutdown -r now
+$ sudo shutdown -r now
```
If you want to know more on (virtual) network interfaces or iptables rules, please see the specific subjects below.
@@ -226,7 +223,7 @@ ip link delete interface_name
>**Note:** Depending on the network provider configured for the cluster the node was part of, some of the chains will or won't be present on the node.
-Iptables rules are used to route traffic from and to containers. The created rules are not persistent, so restarting the node will restore iptables to it's original state.
+Iptables rules are used to route traffic from and to containers. The created rules are not persistent, so restarting the node will restore iptables to its original state.
Chains |
--------|
diff --git a/content/rancher/v2.x/en/cluster-provisioning/cloning-clusters/_index.md b/content/rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md
similarity index 98%
rename from content/rancher/v2.x/en/cluster-provisioning/cloning-clusters/_index.md
rename to content/rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md
index fb4025bc2b5..43c8dc93a5e 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/cloning-clusters/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md
@@ -1,6 +1,8 @@
---
title: Cloning Clusters
-weight: 2400
+weight: 2035
+aliases:
+ - /rancher/v2.x/en/cluster-provisioning/cloning-clusters/
---
If you have a cluster in Rancher that you want to use as a template for creating similar clusters, you can use Rancher CLI to clone the cluster's configuration, edit it, and then use it to quickly launch the cloned cluster.
diff --git a/content/rancher/v2.x/en/cluster-provisioning/cluster-members/_index.md b/content/rancher/v2.x/en/cluster-admin/cluster-members/_index.md
similarity index 87%
rename from content/rancher/v2.x/en/cluster-provisioning/cluster-members/_index.md
rename to content/rancher/v2.x/en/cluster-admin/cluster-members/_index.md
index 3b0c3425578..8f8a197ad77 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/cluster-members/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/cluster-members/_index.md
@@ -1,8 +1,10 @@
---
title: Adding Users to Clusters
-weight: 2500
+weight: 2020
aliases:
- /rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/
+ - /rancher/v2.x/en/cluster-provisioning/cluster-members/
+ - /rancher/v2.x/en/k8s-in-rancher/cluster-members/
---
If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/editing-clusters/_index.md b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md
similarity index 93%
rename from content/rancher/v2.x/en/k8s-in-rancher/editing-clusters/_index.md
rename to content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md
index 3c7717bce77..41b07c02495 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/editing-clusters/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md
@@ -1,6 +1,8 @@
---
title: Editing Clusters
-weight: 3015
+weight: 2025
+aliases:
+ - /rancher/v2.x/en/k8s-in-rancher/editing-clusters/
---
After you provision a Kubernetes cluster using Rancher, you can still edit options and settings for the cluster. To edit your cluster, open the **Global** view, make sure the **Clusters** tab is selected, and then select **Ellipsis (...) > Edit** for the cluster that you want to edit.
@@ -22,13 +24,6 @@ The following table lists the options and settings available for each cluster ty
Cluster administrators can edit the membership for a cluster, controlling which Rancher users can access the cluster and what features they can use.
->**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**.
@@ -66,7 +61,7 @@ When editing clusters, clusters that are [launched using RKE]({{< baseurl >}}/ra
### Upgrading Kubernetes
-Following an upgrade to the latest version of Rancher, you can update your existing clusters to use the latest supported version of Kubernetes. Before a new version of Rancher is released, it's tested with the latest versions of Kubernetes to ensure compatibility.
+Following an upgrade to the latest version of Rancher, you can update your existing clusters to use the latest supported version of Kubernetes. Before a new version of Rancher is released, it's tested with the latest versions of Kubernetes to ensure compatibility.
>**Recommended:** Before upgrading Kubernetes, [backup your cluster]({{< baseurl >}}/rancher/v2.x/en/backups).
@@ -78,7 +73,7 @@ Following an upgrade to the latest version of Rancher, you can update your exist
1. Click **Save**.
-**Result:** Kubernetes begins upgrading for the cluster. During the upgrade, your cluster is unavailable.
+**Result:** Kubernetes begins upgrading for the cluster. During the upgrade, your cluster is unavailable.
### Adding a Pod Security Policy
@@ -96,7 +91,7 @@ You can assign a pod security policy when you provision a cluster. However, if y
4. From the **Default Pod Security Policy** drop-down, select the policy you want to apply to the cluster.
- Rancher ships with [policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/#default-pod-security-policies) of `restricted` and `unrestricted`, although you can [create custom policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/#default-pod-security-policies) as well.
+ Rancher ships with [policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/#default-pod-security-policies) of `restricted` and `unrestricted`, although you can [create custom policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/#default-pod-security-policies) as well.
5. Click **Save**.
@@ -133,14 +128,14 @@ Option | Description |
>**Note:** In Rancher v2.0.5 and v2.0.6, the names of services in the Config File (YAML) should contain underscores only: `kube_api` and `kube_controller`.
-Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/v0.1.x/en/config-options/) in an RKE installation.
+Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/latest/en/config-options/) in an RKE installation.
- To edit an RKE config file directly from the Rancher UI, click **Edit as YAML**.
- To read from an existing RKE file, click **Read from File**.
-For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/).
+For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/latest/en/example-yamls/).
## Managing Node Pools
@@ -149,7 +144,7 @@ In clusters [launched by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioni
- Add new [pools of nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to your cluster. The nodes added to the pool are provisioned according to the [node template]({{< baseurl >}}/rancher/v2.x/en/user-settings/node-templates/) that you use.
- Click **+** and follow the directions on screen to create a new template.
-
+
- You can also reuse existing templates by selecting one from the **Template** drop-down.
- Redistribute Kubernetes roles amongst your node pools by making different checkbox selections
@@ -157,4 +152,3 @@ In clusters [launched by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioni
- Scale the number of nodes in a pool up or down (although, if you simply want to maintain your node scale, we recommend using the cluster's [Nodes tab]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/nodes/#nodes-provisioned-by-node-pool) instead.)
>**Note:** The Node Pools section is not available for imported clusters or clusters hosted by a Kubernetes provider.
-
diff --git a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md
new file mode 100644
index 00000000000..17b63934f43
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md
@@ -0,0 +1,57 @@
+---
+title: Kubeconfig File
+weight: 2010
+aliases:
+ - /rancher/v2.x/en/concepts/clusters/kubeconfig-files/
+ - /rancher/v2.x/en/k8s-in-rancher/kubeconfig/
+---
+
+A _kubeconfig file_ is a file used to configure access to Kubernetes when used in conjunction with the kubectl commandline tool (or other clients).
+
+For more details on how kubeconfig and kubectl work together, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
+
+When you create a cluster using the Rancher GUI, Rancher automatically creates a kubeconfig for your cluster.
+
+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//k8s-in-rancher/kubectl).
+
+>**Note:** By default, kubectl checks `~/.kube/config` for a kubeconfig file, but you can use any directory you want using the `--kubeconfig` flag. For example:
+
+```
+kubectl --kubeconfig /custom/path/kube.config get pods
+```
+
+## Accessing Rancher Launched Kubernetes clusters without Rancher server running
+
+By default, Rancher generates a kubeconfig file that will proxy through the Rancher server to connect to the Kubernetes API server on a cluster.
+
+For [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters) clusters, which have [Authorized Cluster Endpoint]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#authorized-cluster-endpoint) enabled, Rancher generates extra context(s) in the kubeconfig file in order to connect directly to the cluster.
+
+> **Note:** By default, all Rancher Launched Kubernetes clusters have [Authorized Cluster Endpoint]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#authorized-cluster-endpoint) enabled.
+
+To find the name of the context(s), view the kubeconfig file.
+
+### Clusters with FQDN defined as an Authorized Cluster Endpoint
+
+If an FQDN is defined for the cluster, a single context referencing the FQDN will be created. The context will be named `-fqdn`. When you want to use `kubectl` to access this cluster without Rancher, you will need to use this context.
+
+```
+# Assuming the kubeconfig file is located at ~/.kube/config
+kubectl --context -fqdn get nodes
+
+# Directly referencing the location of the kubeconfig file
+kubectl --kubeconfig /custom/path/kube.config --context -fqdn get pods
+```
+
+### Clusters without FQDN defined as an Authorized Cluster Endpoint
+
+If there is no FQDN defined for the cluster, extra contexts will be created referencing the IP address of each node in the control plane. Each context will be named `-`. When you want to use `kubectl` to access this cluster without Rancher, you will need to use this context.
+
+```
+# Assuming the kubeconfig file is located at ~/.kube/config
+kubectl --context - get nodes
+
+# Directly referencing the location of the kubeconfig file
+kubectl --kubeconfig /custom/path/kube.config --context - get pods
+```
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/kubectl/_index.md b/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md
similarity index 89%
rename from content/rancher/v2.x/en/k8s-in-rancher/kubectl/_index.md
rename to content/rancher/v2.x/en/cluster-admin/kubectl/_index.md
index 9064c89c7df..2d332ac495a 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/kubectl/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md
@@ -1,8 +1,9 @@
---
title: Using kubectl to Access a Cluster
-weight: 3005
+weight: 2015
aliases:
- /rancher/v2.x/en/tasks/clusters/using-kubectl-to-access-a-cluster/
+ - /rancher/v2.x/en/k8s-in-rancher/kubectl/
---
You can access and manage your Kubernetes clusters using kubectl in two ways:
@@ -47,4 +48,6 @@ Alternatively, you can access your clusters by installing kubectl on your workst
```
4. From your workstation, launch kubectl. Use it to interact with your kubernetes cluster.
+ If you have launched a [Rancher Launched Kubernetes cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters) and want to use kubectl without using Rancher, see [Kubeconfig Files]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubeconfig/).
+
For more information on using kubectl, see [Kubernetes Documentation: Overview of kubectl](https://kubernetes.io/docs/reference/kubectl/overview/).
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/nodes/_index.md b/content/rancher/v2.x/en/cluster-admin/nodes/_index.md
similarity index 95%
rename from content/rancher/v2.x/en/k8s-in-rancher/nodes/_index.md
rename to content/rancher/v2.x/en/cluster-admin/nodes/_index.md
index 32a960e0831..5267a662c56 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/nodes/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/nodes/_index.md
@@ -1,7 +1,8 @@
---
title: Nodes
-weight:
+weight: 2030
aliases:
+ - /rancher/v2.x/en/k8s-in-rancher/nodes/
---
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.
@@ -22,7 +23,7 @@ The following table lists which node options are available for each [type of clu
| [Edit](#editing-a-node) | ✓ | ✓ | ✓ | | Enter a custom name, description, or label for a node. |
| [View API](#viewing-a-node-api) | ✓ | ✓ | ✓ | | View API data. |
| [Delete](#deleting-a-node) | ✓ | ✓ | | | Deletes defective nodes from the cluster. |
-| [Download Keys](#remoting-into-a-node-pool-node) | ✓ | | | | Download SSH key for remoting into the node. |
+| [Download Keys](#ssh-into-a-node-hosted-by-an-infrastructure-provider) | ✓ | | | | Download SSH key for in order to SSH into the node. |
| [Node Scaling](#scaling-nodes) | ✓ | | | | Scale the number of nodes in the node pool up or down. |
[1]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/
@@ -41,8 +42,8 @@ _Draining_ is the process of first cordoning the node, and then evicting all its
- For pods with a replica set, the pod is replaced by a new pod that will be scheduled to a new node. Additionally, if the pod is part of a service, then clients will automatically be redirected to the new pod.
- For pods with no replica set, you need to bring up a new copy of the pod, and assuming it is not part of a service, redirect clients to it.
-
-You can drain nodes that are in either a `cordoned` or `active` state. When you drain a node, the node is cordoned, the nodes are evaluated for conditions they must meet to be drained, and then (if it meets the conditions) the node evicts its pods.
+
+You can drain nodes that are in either a `cordoned` or `active` state. When you drain a node, the node is cordoned, the nodes are evaluated for conditions they must meet to be drained, and then (if it meets the conditions) the node evicts its pods.
However, you can override the conditions draining when you initiate the drain (see [below](#below)). You're also given an opportunity to set a grace period and timeout value.
@@ -52,7 +53,7 @@ However, you can override the conditions draining when you initiate the drain (s
The following list describes each drain option:
- **Even if there are pods not managed by a ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet**
-
+
These types of pods won't get rescheduled to a new node, since they do not have a controller. Kubernetes expects you to have your own logic that handles the deletion of these pods. Kubernetes forces you to choose this option (which will delete/evict these pods) or drain won't proceed.
- **Even if there are DaemonSet-managed pods**
@@ -60,12 +61,12 @@ The following list describes each drain option:
Similar to above, if you have any daemonsets, drain would proceed only if this option is selected. Even when this option is on, pods won't be deleted since they'll immediately be replaced. On startup, Rancher currently has a few daemonsets running by default in the system, so this option is turned on by default.
- **Even if there are pods using emptyDir**
-
- If a pod uses emptyDir to store local data, you might not be able to safely delete it, since the data in the emptyDir will be deleted once the pod is removed from the node. Similar to the first option, Kubernetes expects the implementation to decide what to do with these pods. Choosing this option will delete these pods.
+
+ If a pod uses emptyDir to store local data, you might not be able to safely delete it, since the data in the emptyDir will be deleted once the pod is removed from the node. Similar to the first option, Kubernetes expects the implementation to decide what to do with these pods. Choosing this option will delete these pods.
- **Grace Period**
- The timeout given to each pod for cleaning things up, so they will have chance to exit gracefully. For example, when pods might need to finish any outstanding requests, roll back transactions or save state to some external storage. If negative, the default value specified in the pod will be used.
+ The timeout given to each pod for cleaning things up, so they will have chance to exit gracefully. For example, when pods might need to finish any outstanding requests, roll back transactions or save state to some external storage. If negative, the default value specified in the pod will be used.
- **Timeout**
@@ -106,7 +107,7 @@ For nodes hosted by an infrastructure provider, you can scale the number of node
-## Remoting into a Node Hosted by an Infrastructure Provider
+## SSH into a Node Hosted by an Infrastructure Provider
For [nodes hosted by an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/), you have the option of downloading its SSH key so that you can connect to it remotely from your desktop.
@@ -128,10 +129,10 @@ For [nodes hosted by an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en
```
## Notes for Node Pool Nodes
-
-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.
-
+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.
+
+
## Notes for 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.
@@ -140,4 +141,3 @@ Options for managing nodes [hosted by a Kubernetes provider]({{< baseurl >}}/ran
## Notes for 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.
-
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/_index.md b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md
similarity index 67%
rename from content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/_index.md
rename to content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md
index 61acf95e4de..592ea784b6b 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md
@@ -1,15 +1,16 @@
---
title: Projects and Namespaces
-weight: 3020
+weight: 2032
aliases:
- /rancher/v2.x/en/concepts/projects/
- /rancher/v2.x/en/tasks/projects/
- /rancher/v2.x/en/tasks/projects/create-project/
+ - /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/
---
## Projects
-_Projects_ are organizational objects introduced in Rancher that ease the administrative burden of your cluster. You can use projects to support multi-tenancy.
+_Projects_ are organizational objects introduced in Rancher that ease the administrative burden of your cluster. You can use projects to support multi-tenancy.
Projects provide an extra level of organization in your Kubernetes clusters beyond [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/). In terms of hierarchy:
@@ -23,7 +24,7 @@ Rancher projects resolve this issue by allowing you to apply resources and acces
You can use projects to perform actions like:
- Assign users access to a group of namespaces (i.e., [project membership]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members)).
-- Assign 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/).
+- Assign 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/).
- Assign resources to the project.
- Assign Pod Security Policies.
@@ -31,7 +32,7 @@ You can use projects to perform actions like:
When you create a cluster, two project are automatically created within it:
- [Default Project](#default-project)
-- [System Project](#system-project)
+- [System Project](#system-project)
### Default Project
@@ -40,11 +41,11 @@ When you provision a cluster, it automatically creates a `default` project for t
### System Project
-_available as of v2.0.7_
+_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.
+To open it, open the **Global** menu, and then select the `system` project for your cluster.
The `system` project:
@@ -58,11 +59,11 @@ The `system` project:
> - 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.
+>The `system` project overrides the Project Network Isolation option so that it can communicate with other projects, collect logs, and check health.
### Authorization
-Non-administrative users are only authorized for project access after an administrator explicitly adds them to the project's **Members** tab.
+Non-administrative users are only authorized for project access after an administrator, cluster owner or cluster member explicitly adds them to the project's **Members** tab.
>**Exception:**
> Non-administrative users can access projects that they create themselves.
@@ -100,9 +101,9 @@ Rancher extends Kubernetes to allow the application of [Pod Security Policies](h
>**Note:** You can only search for groups if external authentication is enabled.
1. From the **Role** drop-down, choose a role.
-
+
[What are Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/)
-
+
>**Notes:**
>
>- Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `Owner` or `Member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
@@ -110,30 +111,33 @@ Rancher extends Kubernetes to allow the application of [Pod Security Policies](h
>- Choose `Custom` to create a custom role on the fly: [Custom Project Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#custom-project-roles).
1. To add more members, repeat substeps a—c.
-
+
1. **Optional:** Add **Resource Quotas**, which limit the resources that a project (and its namespaces) can consume. For more information, see [Resource Quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas).
- >**Note:** This option is only available in v2.1.0 and later.
+ >**Note:** This option is available as of v2.1.0.
1. Click **Add Quota**.
-
+
1. Select a [Resource Type]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types).
-
+
1. Enter values for the **Project Limit** and the **Namespace Default Limit**.
-
+
| Field | Description |
| ----------------------- | -------------------------------------------------------------------------------------------------------- |
| Project Limit | The overall resource limit for the project. |
- | Namespace Default Limit | The default resource limit available for each namespace. This limit is propagated to each namespace in the project. The combined limit of all project namespaces shouldn't exceed the project limit. |
-
+ | Namespace Default Limit | The default resource limit available for each namespace. This limit is propagated to each namespace in the project. The combined limit of all project namespaces shouldn't exceed the project limit. |
+
1. **Optional:** Repeat these substeps to add more quotas.
-
+
+1. **Optional:** Specify **Container Default Resource Limit**, which will be applied to every container started in the project. The parameter is recommended if you have CPU or Memory limits set by the Resource Quota. It can be overridden on per an individual namespace or a container level. For more information, see [Container Default Resource Limit]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#setting-container-default-resource-limit)
+ >**Note:** This option is available as of v2.2.0.
+
1. Click **Create**.
**Result:** Your project is created. You can view it from the cluster's **Projects/Namespaces** view.
-## Switching Clusters/Projects
+## Switching between Clusters/Projects
To switch between clusters and projects, use the **Global** drop-down available in the main menu.
@@ -163,61 +167,4 @@ Resources that you can assign directly to namespaces include:
>**Note:** Although you can assign role-based access to namespaces in the base version of Kubernetes, you cannot assign roles to namespaces in Rancher. Instead, assign role-based access at the project level.
-### Creating Namespaces
-
-Create a new namespace to isolate apps and resources in a project.
-
->**Tip:** When working with project resources that you can assign to a namespace (i.e., [workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/), [certificates]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/), [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/configmaps), etc.) you can create a namespace on the fly.
-
-1. From the **Global** view, open the project where you want to create a namespace.
-
- >**Tip:** As a best practice, we recommend creating namespaces from the project level. However, cluster owners and members can can create them from the cluster level as well.
-
-1. From the main menu, select **Namespace**. The click **Add Namespace**.
-
-1. **Optional:** If your project has [Resource Quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas) in effect, you can override the default resource **Limits** (which places a cap on the resources that the namespace can consume).
-
-1. Enter a **Name** and then click **Create**.
-
-**Result:** Your namespace is added to the project. You can begin assigning cluster resources to the namespace.
-
-### Moving Namespaces to Another Project
-
-Cluster admins and members may occasionally need to move a namespace to another project, such as when you want a different team to start using the application.
-
-1. From the **Global** view, open the cluster that contains the namespace you want to move.
-
-1. From the main menu, select **Projects/Namespaces**.
-
-1. Select the namespace(s) that you want to move to a different project. Then click **Move**. You can move multiple namespaces at one.
-
- >**Notes:**
- >
- >- Don't move the namespaces in the `System` project. Moving these namespaces can adversely affect cluster networking.
- >- You cannot move a namespace into a project that already has a [resource quota]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/) configured.
- >- If you move a namespace from a project that has a quota set to a project with no quota set, the quota is removed from the namespace.
-
-1. Choose a new project for the new namespace and then click **Move**. Alternatively, you can remove the namespace from all projects by selecting **None**.
-
-**Result:** Your namespace is moved to a different project (or is unattached from all projects). If any project resources are attached to the namespace, the namespace releases them and then attached resources from the new project.
-
-### Editing Namespace Resource Quotas
-
-If there is a [resource quota]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas) configured for a project, you can override the namespace default limit to provide a specific namespace with access to more (or less) project resources.
-
-1. From the **Global** view, open the cluster that contains the namespace for which you want to edit the resource quota.
-
-1. From the main menu, select **Projects/Namespaces**.
-
-1. Find the namespace for which you want to edit the resource quota. Select **Ellipsis (...) > Edit**.
-
-1. Edit the Resource Quota **Limits**. These limits determine the resources available to the namespace. The limits must be set within the configured [project limits]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#project-limits).
-
- For more information about each **Resource Type**, see [Resource Quota Types]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types).
-
- >**Note:**
- >
- >- If a resource quota is not configured for the project, these options will not be available.
- >- If you enter limits that exceed the configured project limits, Rancher will not let you save your edits.
-
-**Result:** The namespace's default resource quota is overwritten with your override.
+For more information, see [Namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/).
diff --git a/content/rancher/v2.x/en/cluster-admin/restoring-etcd/_index.md b/content/rancher/v2.x/en/cluster-admin/restoring-etcd/_index.md
new file mode 100644
index 00000000000..e79f9f20478
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/restoring-etcd/_index.md
@@ -0,0 +1,66 @@
+---
+title: Restoring etcd
+weight: 2050
+---
+
+_Available as of v2.2.0_
+
+etcd backup and recovery for [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) can be easily performed. Snapshots of the etcd database are taken and saved either locally onto the etcd nodes or to a S3 compatible target. The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.
+
+Rancher recommends enabling the [ability to set up recurring snapshots of etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/#configuring-recurring-snapshots-for-the-cluster), but [one-time snapshots]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/#one-time-snapshots) can easily be taken as well. Rancher allows restore from [saved snapshots](#restoring-your-cluster-from-a-snapshot) or if you don't have any snapshots, you can still [restore etcd](#recovering-etcd-without-a-snapshot).
+
+>**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Rancher, you must [edit the cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the [updated snapshot features]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/). Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to back up and restore etcd through the UI.
+
+## Viewing Available Snapshots
+
+The list of all available snapshots for the cluster is available.
+
+1. In the **Global** view, navigate to the cluster that you want to view snapshots.
+
+2. Click **Tools > Snapshots** from the navigation bar to view the list of saved snapshots. These snapshots include a timestamp of when they were created.
+
+## Restoring your Cluster from a Snapshot
+
+If your Kubernetes cluster is broken, you can restore the cluster from a snapshot.
+
+1. In the **Global** view, navigate to the cluster that you want to view snapshots.
+
+2. Click the **Vertical Ellipsis (...) > Restore Snapshot**.
+
+3. Select the snapshot that you want to use for restoring your cluster from the dropdown of available snapshots. Click **Save**.
+
+ > **Note:** Snapshots from S3 can only be restored from if the cluster is configured to take recurring snapshots on S3.
+
+**Result:** The cluster will go into `updating` state and the process of restoring the `etcd` nodes from the snapshot will start. The cluster is restored when it returns to an `active` state.
+
+> **Note:** If you are restoring a cluster with unavailable etcd nodes, it's recommended that all etcd nodes are removed from Rancher before attempting to restore. For clusters that were provisioned using [nodes hosted in an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/), new etcd nodes will automatically be created. For [custom clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/), please ensure that you add new etcd nodes to the cluster.
+
+## Recovering etcd without a Snapshot
+
+If the group of etcd nodes loses quorum, the Kubernetes cluster will report a failure because no operations, e.g. deploying workloads, can be executed in the Kubernetes cluster. Please review the best practices for the what the [number of etcd nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/production/#count-of-etcd-nodes) should be in a Kubernetes cluster. If you want to recover your set of etcd nodes, follow these instructions:
+
+1. Keep only one etcd node in the cluster by removing all other etcd nodes.
+
+2. On the single remaining etcd node, run the following command:
+
+ ```
+ $ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock assaflavie/runlike etcd
+ ```
+
+ This command outputs the running command for etcd, save this command to use later.
+
+3. Stop the etcd container that you launched in the previous step and rename it to `etcd-old`.
+
+ ```
+ $ docker stop etcd
+ $ docker rename etcd etcd-old
+ ```
+
+4. Take the saved command from Step 2 and revise it:
+
+ - If you originally had more than 1 etcd node, then you need to change `--initial-cluster` to only contain the node that remains.
+ - Add `--force-new-cluster` to the end of the command.
+
+5. Run the revised command.
+
+6. After the single nodes is up and running, Rancher recommends adding additional etcd nodes to your cluster. If you have a [custom cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/custom-clusters/) and you want to reuse an old node, you are required to [clean up the nodes]({{< baseurl >}}/rancher/v2.x/en/faq/cleaning-cluster-nodes/) before attempting to add them back into a cluster.
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/_index.md
new file mode 100644
index 00000000000..7cec8deaebd
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/_index.md
@@ -0,0 +1,93 @@
+---
+title: Configuring Tools
+weight: 2033
+aliases:
+ - /rancher/v2.x/en/tools/
+ - /rancher/v2.x/en/tools/notifiers-and-alerts/
+---
+
+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 following categories:
+
+
+
+- [Notifiers](#notifiers)
+- [Alerts](#alerts)
+- [Logging](#logging)
+- [Monitoring](#monitoring)
+
+
+
+## Notifiers and Alerts
+
+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
+
+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.
+- WeChat: Send alert notifications to your Enterprise WeChat contacts.
+
+For more information, see [Notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/).
+
+### 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.
+
+You can configure alerts at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/alerts/).
+
+
+## Logging
+
+Rancher can integrate with popular external services used for event streams, telemetry, or search. Rancher can integrate with the following services:
+
+- Elasticsearch
+- splunk
+- kafka
+- syslog
+- fluentd
+
+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.
+
+### Logging Advantages
+
+Setting up a logging service to collect logs from your cluster or project is helpful several ways:
+
+- Logs errors and warnings in your Kubernetes infrastructure to a stream. The stream informs you of events like a container crashing, a pod eviction, or a node dying.
+- Allows you to capture and analyze the state of your cluster and look for trends in your environment using the log stream.
+- Helps you when troubleshooting or debugging.
+- Saves your logs to a safe location outside of your cluster, so that you can still access them even if your cluster encounters issues.
+
+You can configure these services to collect logs at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/logging/).
+
+## Monitoring
+
+_Available as of v2.2.0_
+
+Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. Prometheus provides a _time series_ of your data, which is a stream of timestamped values belonging to the same metric and the same set of labeled dimensions, along with comprehensive statistics and metrics of the monitored cluster.
+
+In other words, Prometheus let's you view metrics from your different Rancher and Kubernetes objects. Using timestamps, you can query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster and project-only Prometheus instances are also supported.
+
+You can configure these services to collect logs at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/).
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/alerts/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/alerts/_index.md
new file mode 100644
index 00000000000..6f2805a315f
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/alerts/_index.md
@@ -0,0 +1,209 @@
+---
+title: Alerts
+weight: 2
+---
+
+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.
+
+Alerts are sets of rules, chosen by you, to monitor for specific events.
+
+## Alerts Scope
+
+The scope for alerts can be set at either the cluster level or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/alerts/).
+
+At the cluster level, Rancher monitors components in your Kubernetes cluster, and sends you alerts related to:
+
+- The state of your nodes.
+- The system services that manage your Kubernetes cluster.
+- The resource events from specific system services.
+- The Prometheus expression cross the thresholds
+
+## Adding Cluster Alerts
+
+As a [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), you can configure Rancher to send you alerts for cluster events.
+
+>**Prerequisite:** Before you can receive cluster alerts, you must [add a notifier]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers).
+
+1. From the **Global** view, navigate to the cluster that you want to configure cluster alerts for. Select **Tools > Alerts**. Then click **Add Alert Group**.
+
+1. Enter a **Name** for the alert that describes its purpose, you could group alert rules for the different purpose.
+
+1. Based on the type of alert you want to create, complete one of the instruction subsets below.
+{{% accordion id="system-service" label="System Service Alerts" %}}
+This alert type monitor 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 alert. The options are:
+
+ - **Critical**: Most urgent
+ - **Warning**: Normal urgency
+ - **Info**: Least urgent
+
+
+ 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.
+
+1. Configure advanced options. By default, the below options will apply to all alert rules within the group. You can disable these advanced options when configuring a specific rule.
+
+ - **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
+ - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
+ - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
+
+{{% /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 alert.
+
+ - **Critical**: Most urgent
+ - **Warning**: Normal urgency
+ - **Info**: Least urgent
+
+
+ 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, it's very likely to impact operations, so select an urgency of **Critical**.
+
+1. Configure advanced options. By default, the below options will apply to all alert rules within the group. You can disable these advanced options when configuring a specific rule.
+
+ - **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
+ - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
+ - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
+
+{{% /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 usage over**: Sends you an alert when the node raises above an entered percentage of its memory allocation.
+
+1. Select the urgency level of the alert.
+
+ - **Critical**: Most urgent
+ - **Warning**: Normal urgency
+ - **Info**: Least urgent
+
+
+ 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 an urgency of **Info**, but a node that is **Not Ready** deems an urgency of **Critical**.
+
+1. Configure advanced options. By default, the below options will apply to all alert rules within the group. You can disable these advanced options when configuring a specific rule.
+
+ - **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
+ - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
+ - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
+
+{{% /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 usage over**: Sends you an alert when selected nodes raise above an entered percentage of memory allocation.
+
+1. Select the urgency level of the alert.
+
+ - **Critical**: Most urgent
+ - **Warning**: Normal urgency
+ - **Info**: Least urgent
+
+
+ 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 an urgency of **Info**, but a node that is **Not Ready** deems an urgency of **Critical**.
+
+1. Configure advanced options. By default, the below options will apply to all alert rules within the group. You can disable these advanced options when configuring a specific rule.
+
+ - **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
+ - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
+ - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
+
+{{% /accordion %}}
+{{% accordion id="cluster-expression" label="Metric Expression Alerts" %}}
+This alert type monitors for the overload from Prometheus expression querying, it would be available after you enable monitoring.
+
+1. Input or select an **Expression**, the drop down shows the original metrics from Prometheus, including:
+
+ - [**Node**](https://github.com/prometheus/node_exporter)
+ - [**Container**](https://github.com/google/cadvisor)
+ - [**ETCD**](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/monitoring.md)
+ - [**Kubernetes Components**](https://github.com/kubernetes/metrics)
+ - [**Kubernetes Resources**](https://github.com/kubernetes/kube-state-metrics)
+ - [**Fluentd**](https://docs.fluentd.org/v1.0/articles/monitoring-prometheus) (supported by [Logging]({{< baseurl >}}/rancher/v2.x/en/tools/logging))
+ - [**Cluster Level Grafana**](http://docs.grafana.org/administration/metrics/)
+ - **Cluster Level Prometheus**
+
+1. Choose a **Comparison**.
+
+ - **Equal**: Trigger alert when expression value equal to the threshold.
+ - **Not Equal**: Trigger alert when expression value not equal to the threshold.
+ - **Greater Than**: Trigger alert when expression value greater than to threshold.
+ - **Less Than**: Trigger alert when expression value equal or less than the threshold.
+ - **Greater or Equal**: Trigger alert when expression value greater to equal to the threshold.
+ - **Less or Equal**: Trigger alert when expression value less or equal to the threshold.
+
+1. Input a **Threshold**, for trigger alert when the value of expression cross the threshold.
+
+1. Choose a **Comparison**.
+
+1. Select a duration, for trigger alert when expression value crosses the threshold longer than the configured duration.
+
+1. Select the urgency level of the alert.
+
+ - **Critical**: Most urgent
+ - **Warning**: Normal urgency
+ - **Info**: Least urgent
+
+
+ Select the urgency level of the alert based on its impact on operations. For example, an alert triggered when a node's load expression ```sum(node_load5) / count(node_cpu_seconds_total{mode="system"})``` raises above 0.6 deems an urgency of **Info**, but 1 deems an urgency of **Critical**.
+
+1. Configure advanced options. By default, the below options will apply to all alert rules within the group. You can disable these advanced options when configuring a specific rule.
+
+ - **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
+ - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
+ - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
+
+{{% /accordion %}}
+
+1. Continue adding more **Alert Rule** to the group.
+
+1. Finally, choose the [notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/) to send the alerts to.
+
+ - 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
+- Mute firing alerts
+- Unmute muted alerts
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md
new file mode 100644
index 00000000000..60618c1b81e
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md
@@ -0,0 +1,107 @@
+---
+title: Logging
+weight: 3
+aliases:
+ - /rancher/v2.x/en/tasks/logging/
+ - /rancher/v2.x/en/tools/logging/
+---
+
+Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
+
+Rancher supports the following services:
+
+- Elasticsearch
+- Splunk
+- Kafka
+- Syslog
+- Fluentd
+
+>**Note:** You can only configure one logging service per cluster or per project.
+
+## Requirements
+
+The Docker daemon on each node in the cluster should be [configured](https://docs.docker.com/config/containers/logging/configure/) with the (default) log-driver: `json-file`. You can check the log-driver by running the following command:
+
+```
+$ docker info | grep 'Logging Driver'
+Logging Driver: json-file
+```
+
+## Advantages
+
+Setting up a logging service to collect logs from your cluster/project has several advantages:
+
+- Logs errors and warnings in your Kubernetes infrastructure to a stream. The stream informs you of events like a container crashing, a pod eviction, or a node dying.
+- Allows you to capture and analyze the state of your cluster and look for trends in your environment using the log stream.
+- Helps you when troubleshooting or debugging.
+- Saves your logs to a safe location outside of your cluster, so that you can still access them even if your cluster encounters issues.
+
+## Logging Scope
+
+You can configure logging at either cluster level or project level.
+
+- Cluster logging writes logs for every pod in the cluster, i.e. in all the projects. For [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters), it also writes logs for all the Kubernetes system components.
+- [Project logging]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/logging/) writes logs for every pod in that particular project.
+
+Logs that are sent to your logging service are from the following locations:
+
+ - Pod logs stored at `/var/log/containers`.
+ - Kubernetes system components logs stored at `/var/lib/rancher/rke/logs/`.
+
+## Enabling Cluster Logging
+
+As an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) or [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), you can configure Rancher to send Kubernetes logs to a logging service.
+
+1. From the **Global** view, navigate to the cluster that you want to configure cluster logging.
+
+1. Select **Tools > Logging** in the navigation bar.
+
+1. Select a logging service and enter the configuration. Refer to the specific service for detailed configuration. Rancher supports the following services:
+
+ - [Elasticsearch]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/elasticsearch/)
+ - [Splunk]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/splunk/)
+ - [Kafka]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/kafka/)
+ - [Syslog]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/syslog/)
+ - [Fluentd]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/fluentd/)
+
+1. (Optional) Instead of using the UI to configure the logging services, you can enter custom advanced configurations by clicking on **Edit as File**, which is located above the logging targets. This link is only visible after you select a logging service.
+
+ - With the file editor, enter raw fluentd configuration for any logging service. Refer to the documentation for each logging service on how to setup the output configuration.
+
+ - [Elasticsearch Documentation](https://github.com/uken/fluent-plugin-elasticsearch)
+ - [Splunk Documentation](https://github.com/fluent/fluent-plugin-splunk)
+ - [Kafka Documentation](https://github.com/fluent/fluent-plugin-kafka)
+ - [Syslog Documentation](https://github.com/dlackty/fluent-plugin-remote_syslog)
+ - [Fluentd Documentation](https://docs.fluentd.org/v1.0/articles/out_forward)
+
+ - If the logging service is using TLS, you also need to complete the **SSL Configuration** form.
+ 1. Provide the **Client Private Key** and **Client Certificate**. You can either copy and paste them or upload them by using the **Read from a file** button.
+
+ - You can use either a self-signed certificate or one provided by a certificate authority.
+
+ - You can generate a self-signed certificate 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"
+ ```
+ 2. If you are using a self-signed certificate, provide the **CA Certificate PEM**.
+
+1. (Optional) Complete the **Additional Logging Configuration** form.
+
+ 1. **Optional:** Use the **Add Field** button to add custom log fields to your logging configuration. These fields are key value pairs (such as `foo=bar`) that you can use to filter the logs from another system.
+
+ 1. Enter a **Flush Interval**. This value determines how often [Fluentd](https://www.fluentd.org/) flushes data to the logging server. Intervals are measured in seconds.
+
+ 1. **Include System Log**. The logs from pods in system project and RKE components will be sent to the target. Uncheck it to exclude the system logs.
+
+1. Click **Test**. Rancher sends a test log to the service.
+
+ > **Note:** This button is replaced with _Dry Run_ if you are using the custom configuration editor. In this case, Rancher calls the fluentd dry run command to validate the configuration.
+
+1. Click **Save**.
+
+**Result:** Rancher is now configured to send logs to the selected service. Log into the logging service so that you can start viewing the logs.
+
+## Related Links
+
+[Logging Architecture](https://kubernetes.io/docs/concepts/cluster-administration/logging/)
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/elasticsearch/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/elasticsearch/_index.md
new file mode 100644
index 00000000000..1b50e42bad0
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/elasticsearch/_index.md
@@ -0,0 +1,43 @@
+---
+title: Elasticsearch
+weight: 200
+aliases:
+ - /rancher/v2.x/en/tools/logging/elasticsearch/
+---
+
+If your organization uses [Elasticsearch](https://www.elastic.co/), either on premise or in the cloud, you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Elasticsearch deployment to view logs.
+
+>**Prerequisites:** Configure an [Elasticsearch deployment](https://www.elastic.co/guide/en/cloud/saas-release/ec-create-deployment.html).
+
+## Elasticsearch Deployment Configuration
+
+1. In the **Endpoint** field, enter the IP address and port of your Elasticsearch instance. You can find this information from the dashboard of your Elasticsearch deployment.
+
+ * Elasticsearch usually uses port `9200` for HTTP and `9243` for HTTPS.
+
+1. If you are using [X-Pack Security](https://www.elastic.co/guide/en/x-pack/current/xpack-introduction.html), enter your Elasticsearch **Username** and **Password** for authentication.
+
+1. Enter an [Index Pattern](https://www.elastic.co/guide/en/kibana/current/index-patterns.html).
+
+## SSL Configuration
+
+If your instance of Elasticsearch uses SSL, your **Endpoint** will need to begin with `https://`. With the correct endpoint, the **SSL Configuration** form is enabled and ready to be completed.
+
+1. Provide the **Client Private Key** and **Client Certificate**. You can either copy and paste them or upload them by using the **Read from a file** button.
+
+ - You can use either a self-signed certificate or one provided by a certificate authority.
+
+ - You can generate a self-signed certificate 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. Enter your **Client Key Password**.
+
+1. Enter your **SSL Version**. The default version is `TLSv1_2`.
+
+1. Select whether or not you want to verify your SSL.
+
+ * If you are using a self-signed certificate, select **Enabled - Input trusted server certificate**, provide the **CA Certificate PEM**. You can copy and paste the certificate or upload it using the **Read from a file** button.
+ * If you are using a certificate from a certificate authority, select **Enabled - Input trusted server certificate**. You do not need to provide a **CA Certificate PEM**.
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/fluentd/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/fluentd/_index.md
new file mode 100644
index 00000000000..42f54794862
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/fluentd/_index.md
@@ -0,0 +1,34 @@
+---
+title: Fluentd
+weight: 600
+---
+
+If your organization uses [Fluentd](https://www.fluentd.org/), you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Fluentd server to view logs.
+
+>**Prerequisites:** Configure Fluentd input forward to receive the event stream.
+>
+>See [Fluentd Documentation](https://docs.fluentd.org/v1.0/articles/in_forward) for details.
+
+## Fluentd Configuration
+
+You can add multiple Fluentd Servers. If you want to add additional Fluentd servers, click **Add Fluentd Server**. For each Fluentd server, complete the configuration information:
+
+1. In the **Endpoint** field, enter the address and port of your Fluentd instance, e.g. `http://Fluentd-server:24224`.
+
+1. Enter the **Shared Key** if your Fluentd Server is using a shared key for authentication.
+
+1. Enter the **Username** and **Password** if your Fluentd Server is using username and password for authentication.
+
+1. **Optional:** Enter the **Hostname** of the Fluentd server.
+
+1. Enter the load balancing **Weight** of the Fluentd server. If the weight of one server is 20 and the other server is 30, events will be sent in a 2:3 ratio. If you do not enter a weight, the default weight is 60.
+
+1. If this server is a standby server, check **Use as Standby Only**. Standby servers are used when all other servers are not available.
+
+After adding all the Fluentd servers, you have the option to select **Enable Gzip Compression**. By default, this is enabled because the transferred payload size will be reduced.
+
+## SSL Configuration
+
+If your Fluentd servers are using TLS, you need to select **Use TLS**. If you are using a self-signed certificate, provide the **CA Certificate PEM**. You can copy and paste the certificate or upload it using the **Read from a file** button.
+
+>**Note:** Fluentd does not support self-signed certificates when client authentication is enabled.
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/kafka/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/kafka/_index.md
new file mode 100644
index 00000000000..bb2b5ac2344
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/kafka/_index.md
@@ -0,0 +1,43 @@
+---
+title: Kafka
+weight: 400
+aliases:
+ - /rancher/v2.x/en/tools/logging/kafka/
+---
+
+If your organization uses [Kafka](https://kafka.apache.org/), you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Kafka server to view logs.
+
+>**Prerequisite:** You must have a Kafka server configured.
+
+## Kafka Server Configuration
+
+1. Select the type of **Endpoint** your Kafka server is using:
+
+ * **Zookeeper**: Enter the IP address and port. By default, Zookeeper uses port `2181`. Please note that a Zookeeper endpoint cannot enable TLS.
+ * **Broker**: Click on **Add Endpoint**. For each Kafka broker, enter the IP address and port. By default, Kafka brokers use port `9092`.
+
+1. In the **Topic** field, enter the name of a Kafka [topic](https://kafka.apache.org/documentation/#basic_ops_add_topic) that your Kubernetes cluster submits logs to.
+
+## **Broker** Endpoint Type
+
+### SSL Configuration
+
+If your Kafka cluster is using SSL for the **Broker**, you need to complete the **SSL Configuration** form.
+
+1. Provide the **Client Private Key** and **Client Certificate**. You can either copy and paste them or upload them by using the **Read from a file** button.
+
+1. Provide the **CA Certificate PEM**. You can either copy and paste the certificate or upload it using the **Read from a file** button.
+
+>**Note:** Kafka does not support self-signed certificates when client authentication is enabled.
+
+### SASL configuration
+
+If your Kafka cluster is using [SASL authentication](https://kafka.apache.org/documentation/#security_sasl) for the Broker, you need to complete the **SASL Configuration** form.
+
+1. Enter the SASL **Username** and **Password**.
+
+1. Select the **SASL Type** that your Kafka cluster is using.
+
+ * If your Kafka is using **Plain**, please ensure your Kafka cluster is using SSL.
+
+ * If your Kafka is using **Scram**, you need to select which **Scram Mechanism** Kafka is using.
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/splunk/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/splunk/_index.md
new file mode 100644
index 00000000000..00002ac3c71
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/splunk/_index.md
@@ -0,0 +1,76 @@
+---
+title: Splunk
+weight: 300
+aliases:
+ - /rancher/v2.x/en/tasks/logging/splunk/
+ - /rancher/v2.x/en/tools/logging/splunk/
+---
+
+If your organization uses [Splunk](https://www.splunk.com/), you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Splunk server to view logs.
+
+>**Prerequisites:**
+>
+>- Configure HTTP event collection for your Splunk Server (Splunk Enterprise or Splunk Cloud).
+>- Either create a new token or copy an existing token.
+>
+>For more information, see [Splunk Documentation](http://docs.splunk.com/Documentation/Splunk/7.1.2/Data/UsetheHTTPEventCollector#About_Event_Collector_tokens).
+
+## Splunk Configuration
+
+1. In the **Endpoint** field, enter the IP address and port for you Splunk instance (i.e. `http://splunk-server:8088`)
+
+ * Splunk usually uses port `8088`. If you're using Splunk Cloud, you'll need to work with [Splunk support](https://www.splunk.com/en_us/support-and-services.html) to get an endpoint URL.
+
+1. Enter the **Token** you obtained while completing the prerequisites (i.e., when you created a token in Splunk).
+
+1. In the **Source** field, enter the name of the token as entered in Splunk.
+
+1. **Optional:** Provide one or more [index](http://docs.splunk.com/Documentation/Splunk/7.1.2/Indexer/Aboutindexesandindexers) that's allowed for your token.
+
+## SSL Configuration
+
+If your instance of Splunk uses SSL, your **Endpoint** will need to begin with `https://`. With the correct endpoint, the **SSL Configuration** form is enabled and ready to be completed.
+
+1. Provide the **Client Private Key** and **Client Certificate**. You can either copy and paste them or upload them by using the **Read from a file** button.
+
+ - You can use either a self-signed certificate or one provided by a certificate authority.
+
+ - You can generate a self-signed certificate 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. Enter your **Client Key Password**.
+
+1. Select whether or not you want to verify your SSL.
+
+ * If you are using a self-signed certificate, select **Enabled - Input trusted server certificate**, provide the **CA Certificate PEM**. You can copy and paste the certificate or upload it using the **Read from a file** button.
+ * If you are using a certificate from a certificate authority, select **Enabled - Input trusted server certificate**. You do not need to provide a **CA Certificate PEM**.
+
+## Viewing Logs
+
+1. Log into your Splunk server.
+
+1. Click on **Search & Reporting**. The number of **Indexed Events** listed should be increasing.
+
+1. Click on Data Summary and select the Sources tab.
+ 
+
+1. To view the actual logs, click on the source that you declared earlier.
+ 
+
+## Troubleshooting
+
+You can use curl to see if **HEC** is listening for HTTP event data.
+
+```
+$ curl http://splunk-server:8088/services/collector/event \
+ -H 'Authorization: Splunk 8da70994-b1b0-4a79-b154-bfaae8f93432' \
+ -d '{"event": "hello world"}'
+```
+
+If Splunk is configured correctly, you should receive **json** data returning `success code 0`. You should be able
+to send logging data to HEC.
+
+If you received an error, check your configuration in Splunk and Rancher.
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/syslog/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/syslog/_index.md
new file mode 100644
index 00000000000..f6f0a6acae1
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/syslog/_index.md
@@ -0,0 +1,41 @@
+---
+title: Syslog
+weight: 500
+aliases:
+ - /rancher/v2.x/en/tools/logging/syslog/
+---
+
+If your organization uses [Syslog](https://tools.ietf.org/html/rfc5424), you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Syslog server to view logs.
+
+>**Prerequisite:** You must have a Syslog server configured.
+
+If you are using rsyslog, please make sure your rsyslog authentication mode is `x509/name`.
+
+## Syslog Server Configuration
+
+1. In the **Endpoint** field, enter the IP address and port for your Syslog server. Additionally, in the dropdown, select the protocol that your Syslog server uses.
+
+1. In the **Program** field, enter the name of the application sending logs to your Syslog server, e.g. `Rancher`.
+
+1. If you are using a cloud logging service, e.g. [Sumologic](https://www.sumologic.com/), enter a **Token** that authenticates with your Syslog server. You will need to create this token in the cloud logging service.
+
+1. Select a **Log Severity** for events that are logged to the Syslog server. For more information on each severity level, see the [Syslog protocol documentation](https://tools.ietf.org/html/rfc5424#page-11).
+
+## Encryption Configuration
+
+If your Syslog server is using **TCP** protocol and uses TLS, you need to select **Use TLS** and complete the **Encryption Configuration** form.
+
+1. Provide the **Client Private Key** and **Client Certificate**. You can either copy and paste them or upload them by using the **Read from a file** button.
+
+ - You can use either a self-signed certificate or one provided by a certificate authority.
+
+ - You can generate a self-signed certificate 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. Select whether or not you want to verify your SSL.
+
+ * If you are using a self-signed certificate, select **Enabled - Input trusted server certificate**, provide the **CA Certificate PEM**. You can copy and paste the certificate or upload it using the **Read from a file** button.
+ * If you are using a certificate from a certificate authority, select **Enabled - Input trusted server certificate**. You do not need to provide a **CA Certificate PEM**.
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md
new file mode 100644
index 00000000000..957bd5a7a23
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md
@@ -0,0 +1,63 @@
+---
+title: Monitoring
+weight: 4
+---
+
+_Available as of v2.2.0_
+
+Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. Prometheus provides a _time series_ of your data, which is, according to [Prometheus documentation](https://prometheus.io/docs/concepts/data_model/):
+
+>A stream of timestamped values belonging to the same metric and the same set of labeled dimensions, along with comprehensive statistics and metrics of the monitored cluster.
+
+In other words, Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Using timestamps, Prometheus lets you query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster and project-only Prometheus instances are also supported.
+
+## Monitoring Scope
+
+Using Prometheus, you can monitor Rancher at both the cluster level and [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/). For each cluster and project that is enabled for monitoring, Rancher deploys a Prometheus server.
+
+- Cluster monitoring allows you to view the health of your Kubernetes cluster. Prometheus collects metrics from the cluster components below, which you can view in graphs and charts.
+
+ - [Kubernetes control plane]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/#kubernetes-components-metrics)
+ - [etcd database]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/#etcd-metrics)
+ - [All nodes (including workers)]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/#cluster-metrics)
+
+- [Project monitoring]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/) allows you to view the state of pods running in a given project. Prometheus collects metrics from the project's deployed HTTP and TCP/UDP workloads.
+
+## Enabling Cluster Monitoring
+
+As an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) or [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), you can configure Rancher to deploy Prometheus to monitor your Kubernetes cluster.
+
+1. From the **Global** view, navigate to the cluster that you want to configure cluster monitoring.
+
+1. Select **Tools > Monitoring** in the navigation bar.
+
+1. Select **Enable** to show the [Prometheus configuration options]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/prometheus/). Review the [resource consumption recommendations](#resource-consumption) to ensure you have enough resources for Prometheus and on your worker nodes to enable monitoring. Enter in your desired configuration options.
+
+1. Click **Save**.
+
+**Result:** The Prometheus server will be deployed as well as two monitoring applications. The two monitoring applications, `cluster-monitoring` and `monitoring-operator`, are added as an [application]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/) to the cluster's `system` project. After the applications are `active`, you can start viewing [cluster metrics]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/) through the [Rancher dashboard]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/viewing-metrics/#rancher-dashboard) or directly from [Grafana]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#grafana).
+
+### Resource Consumption
+
+When enabling cluster monitoring, you need to ensure your worker nodes and Prometheus pod have enough resources. The tables below provides a guide of how much resource consumption will be used.
+
+#### Prometheus Pod Resource Consumption
+
+This table is the resource consumption of the Prometheus pod, which is based on the number of all the nodes in the cluster. The count of nodes includes the worker, control plane and etcd nodes. Total disk space allocation should be approximated by the `rate * retention` period set at the cluster level. When enabling cluster level monitoring, you should adjust the CPU and Memory limits and reservation.
+
+Number of Cluster Nodes | CPU (milli CPU) | Memory | Disk
+------------------------|-----|--------|------
+5 | 500 | 650 MB | ~1 GB/Day
+50| 2000 | 2 GB | ~5 GB/Day
+256| 4000 | 6 GB | ~18 GB/Day
+
+#### Other Pods Resource Consumption
+
+Besides the Prometheus pod, there are components that are deployed that require additional resources on the worker nodes.
+
+Pod | CPU (milli CPU) | Memory (MB)
+----|-----------------|------------
+Node Exporter (Per Node) | 100 | 30
+Kube State Cluster Monitor | 100 | 130
+Grafana | 100 | 150
+Prometheus Cluster Monitoring Nginx | 50 | 50
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/_index.md
new file mode 100644
index 00000000000..256bfa306eb
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/_index.md
@@ -0,0 +1,113 @@
+---
+title: Cluster Metrics
+weight: 3
+---
+
+_Available as of v2.2.0_
+
+Cluster metrics display the hardware utilization for all nodes in your cluster, regardless of its role. They give you a global monitoring insight into the cluster.
+
+Some of the biggest metrics to look out for:
+
+- **CPU Utilization**
+
+ High load either indicates that your cluster is running efficiently or that you're running out of CPU resources.
+
+- **Disk Utilization**
+
+ Be on the lookout for increased read and write rates on nodes nearing their disk capacity. This advice is especially true for etcd nodes, as running out of storage on an etcd node leads to cluster failure.
+
+- **Memory Utilization**
+
+ Deltas in memory utilization usually indicate a memory leak.
+
+- **Load Average**
+
+ Generally, you want your load average to match your number of logical CPUs for the cluster. For example, if your cluster has 8 logical CPUs, the ideal load average would be 8 as well. If you load average is well under the number of logical CPUs for the cluster, you may want to reduce cluster resources. On the other hand, if your average is over 8, your cluster may need more resources.
+
+## Finding Node Metrics
+
+1. From the **Global** view, navigate to the cluster that you want to view metrics.
+
+1. Select **Nodes** in the navigation bar.
+
+1. Select a specific node and click on its name.
+
+1. Click on **Node Metrics**.
+
+[_Get expressions for Cluster Metrics_]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/#cluster-metrics)
+
+### Etcd Metrics
+
+>**Note:** Only supported for [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/).
+
+Etcd metrics display the operations of the etcd database on each of your cluster nodes. After establishing a baseline of normal etcd operational metrics, observe them for abnormal deltas between metric refreshes, which indicate potential issues with etcd. Always address etcd issues immediately!
+
+You should also pay attention to the text at the top of the etcd metrics, which displays leader election statistics. This text indicates if etcd currently has a leader, which is the etcd instance that coordinates the other etcd instances in your cluster. A large increase in leader changes implies etcd is unstable. If you notice a change in leader election statistics, you should investigate them for issues.
+
+Some of the biggest metrics to look out for:
+
+- **Etcd has a leader**
+
+ etcd is usually deployed on multiple nodes and elects a leader to coordinate its operations. If etcd does not have a leader, its operations are not being coordinated.
+
+- **Number of leader changes**
+
+ If this statistic suddenly grows, it usually indicates network communication issues that constantly force the cluster to elect a new leader.
+
+[_Get expressions for Etcd Metrics_]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/#etcd-metrics)
+
+### Kubernetes Components Metrics
+
+Kubernetes components metrics display data about the cluster's individual Kubernetes components. Primarily, it displays information about connections and latency for each component: the API server, controller manager, scheduler, and ingress controller.
+
+>**Note:** The metrics for the controller manager, scheduler and ingress controller are only supported for [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/).
+
+When analyzing Kubernetes component metrics, don't be concerned about any single standalone metric in the charts and graphs that display. Rather, you should establish a baseline for metrics considered normal following a period of observation, e.g. the range of values that your components usually operate within and are considered normal. After you establish this baseline, be on the lookout for large deltas in the charts and graphs, as these big changes usually indicate a problem that you need to investigate.
+
+Some of the more important component metrics to monitor are:
+
+- **API Server Request Latency**
+
+ Increasing API response times indicate there's a generalized problem that requires investigation.
+
+- **API Server Request Rate**
+
+ Rising API request rates usually coincide with increased API response times. Increased request rates also indicate a generalized problem requiring investigation.
+
+- **Scheduler Preemption Attempts**
+
+ If you see a spike in scheduler preemptions, it's an indication that you're running out of hardware resources, as Kubernetes is recognizing it doesn't have enough resources to run all your pods and is prioritizing the more important ones.
+
+- **Scheduling Failed Pods**
+
+ Failed pods can have a variety of causes, such as unbound persistent volume claims, exhausted hardware resources, non-responsive nodes, etc.
+
+- **Ingress Controller Request Process Time**
+
+ How fast ingress is routing connections to your cluster services.
+
+[_Get expressions for Kubernetes Component Metrics_]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/#kubernetes-components-metrics)
+
+## Rancher Logging Metrics
+
+Although the Dashboard for a cluster primarily displays data sourced from Prometheus, it also displays information for cluster logging, provided that you have [configured Rancher to use a logging service]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/).
+
+[_Get expressions for Rancher Logging Metrics_]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/#rancher-logging-metrics)
+
+## Finding Workload Metrics
+
+Workload metrics display the hardware utilization for a Kubernetes workload. You can also view metrics for [deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/), [stateful sets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) and so on.
+
+1. From the **Global** view, navigate to the project that you want to view workload metrics.
+
+1. Select **Workloads > Workloads** in the navigation bar.
+
+1. Select a specific workload and click on its name.
+
+1. In the **Pods** section, select a specific pod and click on its name.
+
+ - **View the Pod Metrics:** Click on **Pod Metrics**.
+ - **View the Container Metrics:** In the **Containers** section, select a specific container and click on its name. Click on **Container Metrics**.
+
+[_Get expressions for Workload Metrics_]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/#workload-metrics)
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/_index.md
new file mode 100644
index 00000000000..4b52c207fae
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/_index.md
@@ -0,0 +1,375 @@
+---
+title: Expression
+weight: 4
+---
+
+## In This Document
+
+
+
+- [Cluster Metrics](#cluster-metrics)
+ + [Node Metrics](#node-metrics)
+- [Etcd Metrics](#etcd-metrics)
+- [Kubernetes Components Metrics](#kubernetes-components-metrics)
+- [Rancher Logging Metrics](#rancher-logging-metrics)
+- [Workload Metrics](#workload-metrics)
+ + [Pod Metrics](#pod-metrics)
+ + [Container Metrics](#container-metrics)
+
+
+
+## Cluster Metrics
+
+- **CPU Utilization**
+
+ | Catalog | Expression |
+ | --- | --- |
+ | Detail | `1 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance))` |
+ | Summary | `1 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])))` |
+
+- **Load Average**
+
+ | Catalog | Expression |
+ | --- | --- |
+ | Detail |
load1
`sum(node_load1) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`
load5
`sum(node_load5) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`
load15
`sum(node_load15) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`
|
+ | Summary |
load1
`sum(node_load1) by (instance) / count(node_cpu_seconds_total{mode="system"})`
load5
`sum(node_load5) by (instance) / count(node_cpu_seconds_total{mode="system"})`
load15
`sum(node_load15) by (instance) / count(node_cpu_seconds_total{mode="system"})`
`sum(grpc_server_started_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) by (instance) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) by (instance)`
watch
`sum(grpc_server_started_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) by (instance) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) by (instance)`
`sum(rate(container_cpu_cfs_throttled_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`
usage seconds
`sum(rate(container_cpu_usage_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`
system seconds
`sum(rate(container_cpu_system_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`
user seconds
`sum(rate(container_cpu_user_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`
|
+
+### Container Metrics
+
+- **CPU Utilization**
+
+ | Catalog | Expression |
+ | --- | --- |
+ | cfs throttled seconds | `sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
+ | usage seconds | `sum(rate(container_cpu_usage_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
+ | system seconds | `sum(rate(container_cpu_system_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
+ | user seconds | `sum(rate(container_cpu_user_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
+
+- **Memory Utilization**
+
+ `sum(container_memory_working_set_bytes{namespace="$namespace",pod_name="$podName",container_name="$containerName"})`
+
+- **Disk IO**
+
+ | Catalog | Expression |
+ | --- | --- |
+ | read | `sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
+ | write | `sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/prometheus/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/prometheus/_index.md
new file mode 100644
index 00000000000..b4fac99a95b
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/prometheus/_index.md
@@ -0,0 +1,37 @@
+---
+title: Prometheus Configuration
+weight: 1
+---
+
+_Available as of v2.2.0_
+
+
+While configuring monitoring at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#enabling-cluster-monitoring) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/#enabling-project-monitoring), there are multiple options that can be configured.
+
+Option | Description
+-------|-------------
+Data Retention | How long your Prometheus instance retains monitoring data scraped from Rancher objects before it's purged.
+[Enable Node Exporter](#node-exporter) | Whether or not to deploy the node exporter.
+Node Exporter Host Port | The host port on which data is exposed, i.e. data that Prometheus collects from your node hardware. Required if you have enabled the node exporter.
+[Enable Persistent Storage](#persistent-storage) for Prometheus | Whether or not to configure storage for Prometheus so that metrics can be retained even if the Prometheus pod fails.
+[Enable Persistent Storage](#persistent-storage) for Grafana | Whether or not to configure storage for Grafana so that the Grafana dashboards and configuration can be retained even if the Grafana pod fails.
+Prometheus [CPU Limit](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu) | CPU resource limit for the Prometheus pod.
+Prometheus [CPU Reservation](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu) | CPU reservation for the Prometheus pod.
+Prometheus [Memory Limit](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-memory) | Memory resource limit for the Prometheus pod.
+Prometheus [Memory Reservation](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-memory) | Memory resource requests for the Prometheus pod.
+Selector | Ability to select the nodes in which Prometheus and Grafana pods are deployed to. To use this option, the nodes must have labels.
+Advanced Options | Since monitoring is an [application](https://github.com/rancher/system-charts/tree/dev/charts/rancher-monitoring) from the [Rancher catalog]({{< baseurl >}}/rancher/v2.x/en/catalog/), it can be [configured like other catalog application]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/#configuration-options). _Warning: Any modification to the application without understanding the entire application can lead to catastrophic errors._
+
+## Node Exporter
+
+The [node exporter](https://github.com/prometheus/node_exporter/blob/master/README.md) is a popular open source exporter, which exposes the metrics for hardware and \*NIX kernels OS. It is designed to monitor the host system. However, there are still issues with namespaces when running it in a container, mostly around filesystem mount spaces. In order to monitor actual network metrics for the container network, the node exporter must be deployed with the `hostNetwork` mode.
+
+When configuring Prometheus and enabling the node exporter, enter a host port in the **Node Exporter Host Port** that will not produce port conflicts with existing applications. The host port chosen must be open to allow internal traffic between Prometheus and the Node Exporter.
+
+## Persistent Storage
+
+>**Prerequisite:** Configure one or more [storage class]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/#adding-storage-classes) to use as [persistent storage]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/) for your Prometheus or Grafana pod.
+
+By default, when you enable Prometheus for either a cluster or project, all monitoring data that Prometheus collects is stored on its own pod. With local storage, if the Prometheus or Grafana pods fail, all the data is lost. Rancher recommends configuring an external persistent storage to the cluster. With the external persistent storage, if the Prometheus or Grafana pods fail, the new pods can recover using data from the persistent storage.
+
+When enabling persistent storage for Prometheus or Grafana, specify the size of the persistent volume and select the [storage class]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/#storage-classes).
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/viewing-metrics/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/viewing-metrics/_index.md
new file mode 100644
index 00000000000..6880c8aec52
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/viewing-metrics/_index.md
@@ -0,0 +1,59 @@
+---
+title: Viewing Metrics
+weight: 2
+---
+
+_Available as of v2.2.0_
+
+After you've enabled monitoring at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#enabling-cluster-monitoring) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/#enabling-project-monitoring), you will want to be start viewing the data being collected. There are multiple ways to view this data.
+
+## Rancher Dashboard
+
+>**Note:** This is only available if you've enabled monitoring at the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#enabling-cluster-monitoring). Project specific analytics must be viewed using the project's Grafana instance.
+
+Rancher's dashboards are available at multiple locations:
+
+- **Cluster Dashboard**: From the **Global** view, navigate to the cluster.
+- **Node Metrics**: From the **Global** view, navigate to the cluster. Select **Nodes**. Find the individual node and click on its name. Click **Node Metrics.**
+- **Workload Metrics**: From the **Global** view, navigate to the project. Select **Workloads > Workloads**. Find the individual workload and click on its name. Click **Workload Metrics.**
+- **Pod Metrics**: From the **Global** view, navigate to the project. Select **Workloads > Workloads**. Find the individual workload and click on its name. Find the individual pod and click on its name. Click **Pod Metrics.**
+- **Container Metrics**: From the **Global** view, navigate to the project. Select **Workloads > Workloads**. Find the individual workload and click on its name. Find the individual pod and click on its name. Find the individual container and click on its name. Click **Container Metrics.**
+
+Prometheus metrics are displayed and are denoted with the Grafana icon. If you click on the icon, the metrics will open a new tab in Grafana.
+
+Within each Prometheus metrics widget, there are several ways to customize your view.
+
+- Toggle between two views:
+ - **Detail**: Displays graphs and charts that let you view each event in a Prometheus time series
+ - **Summary** Displays events in a Prometheus time series that are outside the norm.
+- Change the range of the time series that you're viewing to see a more refined or expansive data sample.
+- Customize the data sample to display data between specific dates and times.
+
+When analyzing these metrics, don't be concerned about any single standalone metric in the charts and graphs. Rather, you should establish a baseline for your metrics over the course of time, e.g. the range of values that your components usually operate within and are considered normal. After you establish the baseline, be on the lookout for any large deltas in the charts and graphs, as these big changes usually indicate a problem that you need to investigate.
+
+## Grafana
+
+If you've enabled monitoring at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#enabling-cluster-monitoring) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/#enabling-project-monitoring), Rancher automatically creates a link to Grafana instance. Use this link to view monitoring data.
+
+Grafana allows you to query, visualize, alert, and ultimately, understand your cluster and workload data. For more information on Grafana and its capabilities, visit the [Grafana website](https://grafana.com/grafana).
+
+### Authentication
+
+Rancher determines which users can access the new Grafana instance, as well as the objects they can view within it, by validating them against the user's [cluster or project roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/). In other words, a user's access in Grafana mirrors their access in Rancher.
+
+### Accessing Grafana from the Grafana Instance
+
+1. From the **Global** view, navigate to the cluster that you want to access Grafana.
+
+1. From the main navigation bar, choose **Apps**. In versions prior to v2.2.0, choose **Catalog Apps** on the main navigation bar.
+
+1. Find the application based on what level of metrics you want to view:
+
+ - **Cluster Level**: Find the `cluster-monitoring` application.
+ - **Project Level**: Find the `project-monitoring` application.
+
+1. Click the `/index.html` link. You will be redirected to a new webpage for Grafana, which shows metrics for either the cluster or project depending on which application you selected.
+
+1. Sign in to Grafana. The default username is `admin` and the default password is `admin`. For security, Rancher recommends changing the default password after logging in.
+
+**Results:** You will be logged into Grafana from the Grafana instance. After logging in, you can view the preset Grafana dashboards, which are imported via the [Grafana provisioning mechanism](http://docs.grafana.org/administration/provisioning/#dashboards), so you cannot modify them directly. For now, if you want to configure your own dashboards, clone the original and modify the new copy.
diff --git a/content/rancher/v2.x/en/cluster-admin/tools/notifiers/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/notifiers/_index.md
new file mode 100644
index 00000000000..aec464ab46e
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-admin/tools/notifiers/_index.md
@@ -0,0 +1,85 @@
+---
+title: Notifiers
+weight: 1
+---
+
+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.
+
+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.
+- **WeChat**: Send alert notifications to your Enterprise WeChat contacts.
+
+## 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.
+
+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: `#`.
+
+ 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 hostname 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 successful, the URL you're configuring as a notifier outputs `Webhook setting validated`.
+{{% /accordion %}}
+{{% accordion id="WeChat" label="WeChat" %}}
+
+_Available as of v2.2.0_
+
+1. Enter a **Name** for the notifier.
+1. In the **Corporation ID** field, enter the "EnterpriseID" of your corporation, you could get it from [Profile page](https://work.weixin.qq.com/wework_admin/frame#profile).
+1. From Enterprise WeChat, create an application in the [Application page](https://work.weixin.qq.com/wework_admin/frame#apps), and then enter the "AgentId" and "Secret" of this application to the **Application Agent ID** and **Application Secret** fields.
+1. Select the **Recipient Type** and then enter a corresponding id to **Default Recipient** field, for example, the party id, tag id or user account that you want to receive the notification. You could get contact information from [Contacts page](https://work.weixin.qq.com/wework_admin/frame#contacts).
+{{% /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]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/).
+- [Project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can set up alerts at the [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/alerts/).
+
+## Managing Notifiers
+
+After you set up notifiers, you can manage them. From the **Global** view, open the cluster that you want to manage your notifiers. Select **Tools > Notifiers**. 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.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md
similarity index 99%
rename from content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/_index.md
rename to content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md
index fd0a3644f5d..90c22786be7 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md
@@ -1,9 +1,10 @@
---
title: Volumes and Storage
-weight: 3050
+weight: 2031
aliases:
- /rancher/v2.x/en/concepts/volumes-and-storage/
- /rancher/v2.x/en/tasks/clusters/adding-storage/
+ - /rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/
---
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.
@@ -165,7 +166,7 @@ _Storage Classes_ allow you to dynamically provision persistent volumes on deman
## iSCSI Volumes With Rancher Launched Kubernetes Clusters
-In [Rancher Launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) that store data on iSCSI volumes, you may experience an issue where kubelets fail to automatically connect with iSCSI volumes. This failure is likely due to an incompatibility issue involving the iSCSI initiator tool. You can resolve this issue by installing the iSCSI initiator tool on each of your cluster nodes.
+In [Rancher Launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) that store data on iSCSI volumes, you may experience an issue where kubelets fail to automatically connect with iSCSI volumes. This failure is likely due to an incompatibility issue involving the iSCSI initiator tool. You can resolve this issue by installing the iSCSI initiator tool on each of your cluster nodes.
Rancher Launched Kubernetes clusters storing data on iSCSI volumes leverage the [iSCSI initiator tool](http://www.open-iscsi.com/), which is embedded in the kubelet's `rancher/hyperkube` Docker image. From each kubelet (i.e., the _initiator_), the tool discovers and launches sessions with an iSCSI volume (i.e., the _target_). However, in some instances, the versions of the iSCSI initiator tool installed on the initiator and the target may not match, resulting in a connection failure.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/_index.md
similarity index 91%
rename from content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/_index.md
rename to content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/_index.md
index 2b054ef2223..895e45a11ef 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/_index.md
@@ -3,6 +3,7 @@ title: Provisioning Storage Examples
weight: 3053
aliases:
- /rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/
+ - /rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/
---
Rancher supports persistent storage with a variety of volume plugins. However, before you use any of these plugins to bind persistent storage to your workloads, you have to configure the storage itself, whether its a cloud-based solution from a service-provider or an on-prem solution that you manage yourself.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/nfs/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/nfs/_index.md
similarity index 97%
rename from content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/nfs/_index.md
rename to content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/nfs/_index.md
index e56839881f9..6383ba367f3 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/nfs/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/nfs/_index.md
@@ -3,6 +3,7 @@ title: NFS Storage
weight: 3054
aliases:
- /rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/nfs/
+ - /rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/nfs/
---
Before you can use the NFS storage volume plug-in with Rancher deployments, you need to provision an NFS server.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md
similarity index 95%
rename from content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md
rename to content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md
index dc1e0a2b180..ee192cf9b17 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md
@@ -3,13 +3,14 @@ title: vSphere Storage
weight: 3055
aliases:
- /rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/vsphere/
+ - /rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/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/).
+In order to provision vSphere volumes in a cluster created with the [Rancher Kubernetes Engine (RKE)]({{< baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the [vSphere cloud provider]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere) must be explicitly enabled in the [cluster options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/).
### Creating A Storage Class
@@ -19,12 +20,12 @@ In order to provision vSphere volumes in a cluster created with the [Rancher Kub
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.
+3. Enter a **Name** for the class.
4. Under **Provisioner**, select **VMWare vSphere Volume**.
-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. 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
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/persistent-volume-claims/_index.md
similarity index 96%
rename from content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/_index.md
rename to content/rancher/v2.x/en/cluster-admin/volumes-and-storage/persistent-volume-claims/_index.md
index 46f28a147e7..23f3a45aabb 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/persistent-volume-claims/_index.md
@@ -3,6 +3,7 @@ title: Persistent Volume Claims
weight: 3052
aliases:
- /rancher/v2.x/en/tasks/workloads/add-persistent-volume-claim
+ - /rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/
---
_Persistent Volume Claims_ (or PVCs) are objects that request storage resources from your cluster. They're similar to a voucher that your deployment can redeem for storage access. When you create a deployment, you should usually attach a PVC so that your application can lay claim to persistent storage. This claim lets your deployment application store its data in an external location, so that if one of the application's containers fails, it can be replaced with a new container and continue accessing its data stored externally, as though an outage never occurred.
diff --git a/content/rancher/v2.x/en/cluster-provisioning/_index.md b/content/rancher/v2.x/en/cluster-provisioning/_index.md
index 332bfaef10f..65e758ab1d9 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/_index.md
@@ -69,7 +69,7 @@ If you use a Kubernetes provider such as Google GKE, Rancher integrates with its
### Rancher Launched Kubernetes
-Alternatively, you can use Rancher to create a cluster on your own nodes, using [Rancher Kubernetes Engine (RKE)]({{< baseurl >}}/rke/v0.1.x/en/). RKE is Rancher’s own lightweight Kubernetes installer. In RKE clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform. These nodes can either:
+Alternatively, you can use Rancher to create a cluster on your own nodes, using [Rancher Kubernetes Engine (RKE)]({{< baseurl >}}/rke/latest/en/). RKE is Rancher’s own lightweight Kubernetes installer. In RKE clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform. These nodes can either:
- Be provisioned through Rancher's UI, which calls [Docker Machine](https://docs.docker.com/machine/) to launch nodes on various cloud providers.
- Be a prior existing node that's brought into the cluster by running a Rancher agent container on it.
diff --git a/content/rancher/v2.x/en/admin-settings/agent-options/_index.md b/content/rancher/v2.x/en/cluster-provisioning/custom-clusters/agent-options/_index.md
similarity index 96%
rename from content/rancher/v2.x/en/admin-settings/agent-options/_index.md
rename to content/rancher/v2.x/en/cluster-provisioning/custom-clusters/agent-options/_index.md
index 8d33d443047..966d4642fae 100644
--- a/content/rancher/v2.x/en/admin-settings/agent-options/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/custom-clusters/agent-options/_index.md
@@ -1,6 +1,9 @@
---
title: Rancher Agent Options
weight: 1140
+aliases:
+ - /rancher/v2.x/en/admin-settings/agent-options/
+
---
Rancher deploys an agent on each node to communicate with the node. This pages describes the options that can be passed to the agent. To use these options, you will need to [Create a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/) and add the options to the generated `docker run` command when adding a node.
@@ -33,7 +36,7 @@ Rancher deploys an agent on each node to communicate with the node. This pages d
### Dynamic IP address options
-For automation purposes, you can't have a specific IP address in a command as it has to be generic to be used for every node. For this, we have dynamic IP address options. They are used as a value to the existing [IP address options](#ip-address-options). This is supported for `--address` and `--internal-address`.
+For automation purposes, you can't have a specific IP address in a command as it has to be generic to be used for every node. For this, we have dynamic IP address options. They are used as a value to the existing IP address options. This is supported for `--address` and `--internal-address`.
| Value | Example | Description |
| ---------- | -------------------- | ----------- |
diff --git a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/_index.md b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/_index.md
index 69c6aeeb8fb..69f0250ac1f 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/_index.md
@@ -9,9 +9,14 @@ In this use case, Rancher sends a request to a hosted provider using the provide
Rancher supports the following Kubernetes providers:
-- Google GKE (Google Container Engine)
-- Amazon EKS (Elastic Container Service)
-- Microsoft AKS (Azure Kubernetes Service)
+Kubernetes Providers | Available as of |
+ --- | --- |
+[Google GKE (Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/) | v2.0.0 |
+[Amazon EKS (Amazon Elastic Container Service for Kubernetes)](https://aws.amazon.com/eks/) | v2.0.0 |
+[Microsoft AKS (Azure Kubernetes Service)](https://azure.microsoft.com/en-us/services/kubernetes-service/) | v2.0.0 |
+[Alibaba ACK (Alibaba Cloud Container Service for Kubernetes)](https://www.alibabacloud.com/product/kubernetes) | v2.2.0 |
+[Tencent TKE (Tencent Kubernetes Engine)](https://intl.cloud.tencent.com/product/tke) | v2.2.0 |
+[Huawei CCE (Huawei Cloud Container Engine)](https://www.huaweicloud.com/en-us/product/cce.html) | v2.2.0 |
## Hosted Kubernetes Provider Authentication
@@ -19,4 +24,7 @@ When using Rancher to create a cluster hosted by a provider, you are prompted fo
- [Creating a GKE Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke)
- [Creating an EKS Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/eks)
-- [Creating an AKS Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/aks)
\ No newline at end of file
+- [Creating an AKS Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/aks)
+- [Creating an ACK Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/ack)
+- [Creating a TKE Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/tke)
+- [Creating a CCE Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/cce)
diff --git a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/ack/_index.md b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/ack/_index.md
new file mode 100644
index 00000000000..6b14326f275
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/ack/_index.md
@@ -0,0 +1,45 @@
+---
+title: Creating an Aliyun ACK Cluster
+shortTitle: Alibaba Cloud Container Service for Kubernetes
+weight: 2120
+---
+
+_Available as of v2.2.0_
+
+You can use Rancher to create a cluster hosted in Alibaba Cloud Kubernetes (ACK). Rancher has already implemented and packaged the [cluster driver]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/cluster-drivers/) for ACK, but by default, this cluster driver is `inactive`. In order to launch ACK clusters, you will need to [enable the ACK cluster driver]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/cluster-drivers/#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning ACK clusters.
+
+## Prerequisites
+
+1. In Aliyun, activate the following services in their respective consoles.
+
+ - [Container Service](https://cs.console.aliyun.com)
+ - [Resource Orchestration Service](https://ros.console.aliyun.com)
+ - [RAM](https://ram.console.aliyun.com)
+
+2. Make sure that the account you will be using to create the ACK cluster has the appropriate permissions. Referring to the official Alibaba Cloud documentation about [Role authorization](https://www.alibabacloud.com/help/doc-detail/86483.htm) and [Use the Container Service console as a RAM user](https://www.alibabacloud.com/help/doc-detail/86484.htm) for details.
+
+3. In Alibaba Cloud, create an [access key](https://www.alibabacloud.com/help/doc-detail/53045.html).
+
+4. In Alibaba Cloud, create an [SSH key pair](https://www.alibabacloud.com/help/doc-detail/51793.html). This key is used to access nodes in the Kubernetes cluster.
+
+## Create an ACK Cluster
+
+1. From the **Clusters** page, click **Add Cluster**.
+
+1. Choose **Alibaba ACK**.
+
+1. Enter a **Cluster Name**.
+
+1. {{< step_create-cluster_member-roles >}}
+
+1. Configure **Account Access** for the ACK cluster. Choose the geographical region in which to build your cluster, and input the access key that was created as part of the prerequisite steps.
+
+1. Click **Next: Configure Cluster**, then choose cluster type, the version of Kubernetes and the availability zone.
+
+1. If you choose **Kubernetes** as the cluster type, Click **Next: Configure Master Nodes**, then complete the **Master Nodes** form.
+
+1. Click **Next: Configure Worker Nodes**, then complete the **Worker Nodes** form.
+
+1. Review your options to confirm they're correct. Then click **Create**.
+
+{{< result_create-cluster >}}
diff --git a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/aks/_index.md b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/aks/_index.md
index d19031d1d1c..ebae39c34f4 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/aks/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/aks/_index.md
@@ -8,17 +8,17 @@ aliases:
You can use Rancher to create a cluster hosted in Microsoft Azure Kubernetes Service (AKS).
-## Prerequisites
+## Prerequisites in the Microsoft Azure Portal
-Obtain the following information from the Microsoft Azure Portal:
+Obtain the following information from the [Microsoft Azure Portal](https://portal.azure.com) by completing how to [Create Service Principal for Azure AD](https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-create-service-principals#create-service-principal-for-azure-ad).
- Your Subscription ID.
- Your Tenant ID.
- A Client ID and Client Secret.
- Complete Create Service Principal for Azure AD to obtain this information.
+## Create the AKS Cluster
-## To Create an AKS Cluster
+Use Rancher to set up and configure your Kubernetes cluster.
1. From the **Clusters** page, click **Add Cluster**.
diff --git a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/cce/_index.md b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/cce/_index.md
new file mode 100644
index 00000000000..db618c01bd0
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/cce/_index.md
@@ -0,0 +1,77 @@
+---
+title: Creating a Huawei CCE Cluster
+shortTitle: Huawei Cloud Kubernetes Service
+weight: 2130
+---
+
+_Available as of v2.2.0_
+
+You can use Rancher to create a cluster hosted in Huawei Cloud Container Engine (CCE). Rancher has already implemented and packaged the [cluster driver]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/cluster-drivers/) for CCE, but by default, this cluster driver is `inactive`. In order to launch CCE clusters, you will need to [enable the CCE cluster driver]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/cluster-drivers/#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning CCE clusters.
+
+## Prerequisites in Huawei
+
+1. Find your project ID in Huawei CCE portal. See the CCE documentation on how to [manage your projects](https://support.huaweicloud.com/en-us/usermanual-iam/en-us_topic_0066738518.html).
+
+2. Create an [Access Key ID and Secret Access Key](https://support.huaweicloud.com/en-us/usermanual-iam/en-us_topic_0079477318.html).
+
+## Limitations
+
+Huawei CCE service doesn't support the ability to create clusters with public access through their API. You are required to run Rancher in the same VPC as the CCE clusters that you want to provision.
+
+## Create the CCE Cluster
+
+1. From the **Clusters** page, click **Add Cluster**.
+
+2. Choose **Huawei CCE**.
+
+3. Enter a **Cluster Name**.
+
+4. {{< step_create-cluster_member-roles >}}
+
+5. Enter **Project Id**, Access Key ID as **Access Key** and Secret Access Key **Secret Key**. Then Click **Next: Configure cluster**.
+
+6. Fill the following cluster configuration:
+
+ |Settings|Description|
+ |---|---|
+ | Cluster Type | Which type or node you want to include into the cluster, `VirtualMachine` or `BareMetal`. |
+ | Description | The description of the cluster. |
+ | Master Version | The Kubernetes version. |
+ | Management Scale Count | The max node count of the cluster. The options are 50, 200 and 1000. The larger of the scale count, the more the cost. |
+ | High Availability | Enable master node high availability. The cluster with high availability enabled will have more cost. |
+ | Container Network Mode | The network mode used in the cluster. `overlay_l2` and `vpc-router` is supported in `VirtualMachine` type and `underlay_ipvlan` is supported in `BareMetal` type |
+ | Container Network CIDR | Network CIDR for the cluster. |
+ | VPC Name | The VPC name which the cluster is going to deploy into. Rancher will create one if it is blank. |
+ | Subnet Name | The Subnet name which the cluster is going to deploy into. Rancher will create one if it is blank. |
+ | External Server | This option is reserved for the future we can enable CCE cluster public access via API. For now, it is always disabled. |
+ | Cluster Label | The labels for the cluster. |
+ | Highway Subnet | This option is only supported in `BareMetal` type. It requires you to select a VPC with high network speed for the bare metal machines. |
+
+7. Fill the following node configuration of the cluster:
+
+ |Settings|Description|
+ |---|---|
+ | Zone | The available zone at where the node(s) of the cluster is deployed. |
+ | Billing Mode | The bill mode for the cluster node(s). In `VirtualMachine` type, only `Pay-per-use` is supported. in `BareMetal`, you can choose `Pay-per-use` or `Yearly/Monthly`. |
+ | Validity Period | This option only shows in `Yearly/Monthly` bill mode. It means how long you want to pay for the cluster node(s). |
+ | Auto Renew | This option only shows in `Yearly/Monthly` bill mode. It means that the cluster node(s) will renew the `Yearly/Monthly` payment automatically or not. |
+ | Data Volume Type | Data volume type for the cluster node(s). `SATA`, `SSD` or `SAS` for this option. |
+ | Data Volume Size | Data volume size for the cluster node(s) |
+ | Root Volume Type | Root volume type for the cluster node(s). `SATA`, `SSD` or `SAS` for this option. |
+ | Root Volume Size | Root volume size for the cluster node(s) |
+ | Node Flavor | The node flavor of the cluster node(s). The flavor list in Rancher UI is fetched from Huawei Cloud. It includes all the supported node flavors. |
+ | Node Count | The node count of the cluster |
+ | Node Operating System | The operating system for the cluster node(s). Only `EulerOS 2.2` and `CentOS 7.4` are supported right now. |
+ | SSH Key Name | The ssh key for the cluster node(s) |
+ | EIP | The public IP options for the cluster node(s). `Disabled` means that the cluster node(s) are not going to bind a public IP. `Create EIP` means that the cluster node(s) will bind one or many newly created Eips after provisioned and more options will be shown in the UI to set the to-create EIP parameters. And `Select Existed EIP` means that the node(s) will bind to the EIPs you select. |
+ | EIP Count | This option will only be shown when `Create EIP` is selected. It means how many EIPs you want to create for the node(s). |
+ | EIP Type | This option will only be shown when `Create EIP` is selected. The options are `5_bgp` and `5_sbgp`. |
+ | EIP Share Type | This option will only be shown when `Create EIP` is selected. The only option is `PER`. |
+ | EIP Charge Mode | This option will only be shown when `Create EIP` is selected. The options are pay by `BandWidth` and pay by `Traffic`. |
+ | EIP Bandwidth Size | This option will only be shown when `Create EIP` is selected. The BandWidth of the EIPs. |
+ | Authentication Mode | It means enabling `RBAC` or also enabling `Authenticating Proxy`. If you select `Authenticating Proxy`, the certificate which is used for authenticating proxy will be also required. |
+ | Node Label | The labels for the cluster node(s). |
+
+8. Click **Create** to create the CCE cluster.
+
+{{< result_create-cluster >}}
diff --git a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/eks/_index.md b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/eks/_index.md
index 5534f6c5f0b..20c313d58d3 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/eks/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/eks/_index.md
@@ -5,28 +5,14 @@ weight: 2110
aliases:
- /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-eks/
---
-## Objectives
-
+## Prerequisites in Amazon Web Services
-- [1. Give Appropriate Permissions](#1-give-appropriate-permissions)
-- [2. Create Access Key and Secret Key](#2-create-access-key-and-secret-key)
-- [3. Create the EKS Cluster](#3-create-the-eks-cluster)
+1. Make sure that the account you will be using to create the EKS cluster has the appropriate permissions. Referring to the official [EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html) for details.
+2. Use AWS to create an [access key and client secret for the IAM account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) used in the previous step.
-
-
-## 1. Give Appropriate Permissions
-
-Make sure that the account you will be using to create the EKS cluster has the appropriate permissions. Referring to the official [EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html) for details.
-
-## 2. Create Access Key and Secret Key
-
-Use AWS to create an access key and client secret for the IAM account used in [1. Give Appropriate Permissions](#1-give-appropriate-permissions).
-
-For instructions on how to create these keys, see the AWS documentation [Managing Access Keys: To create, modify, or delete a user's access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey).
-
-## 3. Create the EKS Cluster
+## Create the EKS Cluster
Use Rancher to set up and configure your Kubernetes cluster.
@@ -38,17 +24,17 @@ Use Rancher to set up and configure your Kubernetes cluster.
1. {{< step_create-cluster_member-roles >}}
-1. Configure **Account Access** for the EKS cluster. Complete each drop-down and field using the information obtained in [2. Create Access Key and Secret Key](#2-create-access-key-and-secret-key).
+1. Configure **Account Access** for the EKS cluster. Complete each drop-down and field using the information obtained in [2. Create Access Key and Secret Key](#prerequisites-in-amazon-web-services).
| Setting | Description |
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
| Region | From the drop-down choose the geographical region in which to build your cluster. |
| Access Key | Enter the access key that you created in [2. Create Access Key and Secret Key](#2-create-access-key-and-secret-key). |
| Secret Key | Enter the secret key that you created in [2. Create Access Key and Secret Key](#2-create-access-key-and-secret-key). |
-
+
1. Click **Next: Select Service Role**. Then choose a [service role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html).
- Service Role | Description
+ Service Role | Description
-------------|---------------------------
Standard: Rancher generated service role | If you choose this role, Rancher automatically adds a service role for use with the cluster.
Custom: Choose from your existing service roles | If you choose this role, Rancher lets you choose from service roles that you're already created within AWS. For more information on creating a custom service role in AWS, see the [Amazon documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role).
@@ -60,11 +46,11 @@ Use Rancher to set up and configure your Kubernetes cluster.
Option | Description
-------|------------
Yes | When your cluster nodes are provisioned, they're assigned a both a private and public IP address.
- No: Private IPs only | When your cluster nodes are provisioned, they're assigned only a private IP address.
If you choose this option, you must also choose a **VPC & Subnet** that allow your instances to access the internet. This access is required so that your worker nodes can connect to the Kubernetes control plane.
+ No: Private IPs only | When your cluster nodes are provisioned, they're assigned only a private IP address.
If you choose this option, you must also choose a **VPC & Subnet** that allow your instances to access the internet. This access is required so that your worker nodes can connect to the Kubernetes control plane.
1. Now choose a **VPC & Subnet**. Follow one of the sets of instructions below based on your selection from the previous step.
- Amazon Documentation:
+ Amazon Documentation:
- [What Is Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
- [VPCs and Subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html)
@@ -74,7 +60,7 @@ If you choose to assign a public IP address to your cluster's worker nodes, you
1. Choose a **VPC and Subnet** option.
- Option | Description
+ Option | Description
-------|------------
Standard: Rancher generated VPC and Subnet | While provisioning your cluster, Rancher generates a new VPC and Subnet.
Custom: Choose from your exiting VPC and Subnets | While provisioning your cluster, Rancher configures your nodes to use a VPC and Subnet that you've already [created in AWS](https://docs.aws.amazon.com/vpc/latest/userguide/getting-started-ipv4.html). If you choose this option, complete the remaining steps below.
@@ -82,11 +68,11 @@ If you choose to assign a public IP address to your cluster's worker nodes, you
1. If you're using **Custom: Choose from your existing VPC and Subnets**:
(If you're using **Standard**, skip to [step 11](#select-instance-options))
-
+
1. Make sure **Custom: Choose from your existing VPC and Subnets** is selected.
-
+
1. From the drop-down that displays, choose a VPC.
-
+
1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
1. Click **Next: Select Security Group**.
@@ -95,9 +81,9 @@ If you choose to assign a public IP address to your cluster's worker nodes, you
If you chose this option, you must also choose a **VPC & Subnet** that allow your instances to access the internet. This access is required so that your worker nodes can connect to the Kubernetes control plane. Follow the steps below.
>**Tip:** When using only private IP addresses, you can provide your nodes internet access by creating a VPC constructed with two subnets, a private set and a public set. The private set should have its route tables configured to point toward a NAT in the public set. For more information on routing traffic from private subnets, please see the [official AWS documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html).
-
+
1. From the drop-down that displays, choose a VPC.
-
+
1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
1. Click **Next: Select Security Group**.
@@ -118,8 +104,8 @@ If you chose this option, you must also choose a **VPC & Subnet** that allow you
Custom AMI Override | If you want to use a custom [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami) (AMI), specify it here.
Minimum ASG Size | The minimum number of instances that your cluster will scale to during low traffic, as controlled by [Amazon Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html).
Maximum ASG Size | The maximum number of instances that your cluster will scale to during high traffic, as controlled by [Amazon Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html).
+ User Data | Custom commands can to be passed to perform automated configuration tasks **WARNING: Modifying this may cause your nodes to be unable to join the cluster.** _Note: Available as of v2.2.0_
1. Click **Create**.
{{< result_create-cluster >}}
-
diff --git a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke/_index.md b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke/_index.md
index e4622c0fc37..92c2f16db04 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke/_index.md
@@ -5,17 +5,8 @@ weight: 2105
aliases:
- /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-gke/
---
-## Objectives
-1. [Create a Service Account](#create-a-service-account)
-
- Begin by logging into Google Cloud Platform and creating a service account to operate your cluster.
-
-2. [Create the Cluster](#create-the-gke-cluster)
-
- Using your service account, create your Google Container Engine (GKE) cluster.
-
-## Create a Service Account
+## Prerequisites in Google Cloud Platform
Create a service account using [Google Cloud Platform](https://console.cloud.google.com/projectselector/iam-admin/serviceaccounts). GKE uses this account to operate your cluster. Creating this account also generates a private key used for authentication.
@@ -43,10 +34,6 @@ Use {{< product >}} to set up and configure your Kubernetes cluster.
>**Note:** After submitting your private key, you may have to enable the Google Kubernetes Engine API. If prompted, browse to the URL displayed in the Rancher UI to enable the API.
-6. {{< step_create-cluster_cluster-options >}}
-
-7. Use **Nodes** to provision each node in your cluster and choose a geographical region.
-
-8. Review your options to confirm they're correct. Then click **Create**.
+6. Select your **Cluster Options**, customize your **Nodes** and customize the **Security** for the GKE cluster. Review your options to confirm they're correct. Then click **Create**.
{{< result_create-cluster >}}
diff --git a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/tke/_index.md b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/tke/_index.md
new file mode 100644
index 00000000000..007316eedba
--- /dev/null
+++ b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/tke/_index.md
@@ -0,0 +1,72 @@
+---
+title: Creating a Tencent TKE Cluster
+shortTitle: Tencent Kubernetes Engine
+weight: 2125
+---
+
+_Available as of v2.2.0_
+
+You can use Rancher to create a cluster hosted in Tencent Kubernetes Engine (TKE). Rancher has already implemented and packaged the [cluster driver]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/cluster-drivers/) for TKE, but by default, this cluster driver is `inactive`. In order to launch TKE clusters, you will need to [enable the TKE cluster driver]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/cluster-drivers/#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning TKE clusters.
+
+## Prerequisites in Tencent
+
+1. Make sure that the account you will be using to create the TKE cluster has the appropriate permissions by referring to the [Cloud Access Management](https://intl.cloud.tencent.com/document/product/598/10600) documentation for details.
+
+2. Create a [Cloud API Secret ID and Secret Key](https://console.cloud.tencent.com/capi).
+
+3. Create a [Private Network and Subnet](https://intl.cloud.tencent.com/document/product/215/4927) in the region that you want to deploy your Kubernetes cluster.
+
+4. Create a [SSH key pair](https://intl.cloud.tencent.com/document/product/213/6092). This key is used to access the nodes in the Kubernetes cluster.
+
+## Create a TKE Cluster
+
+1. From the **Clusters** page, click **Add Cluster**.
+
+2. Choose **Tencent TKE**.
+
+3. Enter a **Cluster Name**.
+
+4. {{< step_create-cluster_member-roles >}}
+
+5. Configure **Account Access** for the TKE cluster. Complete each drop-down and field using the information obtained in [Prerequisites](#prerequisites).
+
+ | Option | Description |
+ | ---------- | -------------------------------------------------------------------------------------------------------------------- |
+ | Region | From the drop-down chooses the geographical region in which to build your cluster. |
+ | Secret ID | Enter the Secret ID that you obtained from the Tencent Cloud Console. |
+ | Secret Key | Enter the Secret key that you obtained from Tencent Cloud Console. |
+
+6. Click `Next: Configure Cluster` to set your TKE cluster configurations.
+
+ | Option | Description |
+ | ---------- | -------------------------------------------------------------------------------------------------------------------- |
+ | Kubernetes Version | The TKE only supports Kubernetes version 1.10.5 now. |
+ | Node Count | Enter the amount of worker node you want to purchase for your Kubernetes cluster, up to 100. |
+ | VPC | Select the VPC name that you have created in the Tencent Cloud Console. |
+ | Container Network CIDR | Enter the CIDR range of your Kubernetes cluster, you may check the available range of the CIDR in the VPC service of the Tencent Cloud Console. Default to 172.16.0.0/16. |
+
+7. Click `Next: Select Instance Type` to choose the instance type that will use for your TKE cluster.
+
+ | Option | Description |
+ | ---------- | -------------------------------------------------------------------------------------------------------------------- |
+ | Availability Zone | Choose the availability zone of the VPC region. |
+ | Subnet | Select the Subnet that you have created within the VPC, and add a new one if you don't have it in the chosen availability zone. |
+ | Instance Type | From the drop-down chooses the VM instance type that you want to use for the TKE cluster, default to S2.MEDIUM4 (CPU 2 Memory 4 GiB). |
+
+8. Click `Next: Configure Instance` to configure the VM instance that will use for your TKE cluster.
+
+ Option | Description
+ -------|------------
+ Operating System | The name of the operating system, currently supports Centos7.2x86_64 or ubuntu16.04.1 LTSx86_64
+ Security Group | Security group ID, default does not bind any security groups.
+ Root Disk Type | System disk type. System disk type restrictions are detailed in the [CVM instance configuration](https://cloud.tencent.com/document/product/213/11518).
+ Root Disk Size | System disk size. Linux system adjustment range is 20 - 50G, step size is 1.
+ Data Disk Type | Data disk type, default value to the SSD cloud drive
+ Data Disk Size | Data disk size (GB), the step size is 10
+ Band Width Type | Type of bandwidth, PayByTraffic or PayByHour
+ Band Width | Public network bandwidth (Mbps)
+ Key Pair | Key id, after associating the key can be used to logging to the VM node
+
+9. Click **Create**.
+
+{{< result_create-cluster >}}
diff --git a/content/rancher/v2.x/en/cluster-provisioning/production/_index.md b/content/rancher/v2.x/en/cluster-provisioning/production/_index.md
index 4c05895ede2..7711b93834d 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/production/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/production/_index.md
@@ -1,6 +1,6 @@
---
title: Production Ready Cluster
-weight: 2510
+weight: 2005
---
While Rancher makes it easy to create Kubernetes clusters, a production ready cluster takes more consideration and planning. There are three roles that can be assigned to nodes: `etcd`, `controlplane` and `worker`. In the next sections each of the roles will be described in more detail.
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md
index f64297f1e8e..417cdf3c295 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md
@@ -3,7 +3,7 @@ title: Rancher Launched Kubernetes
weight: 2200
---
-If you don't want to use a hosted Kubernetes provider, you can have Rancher launch a Kubernetes cluster using any nodes you want. When Rancher deploys Kubernetes onto these nodes, it uses [Rancher Kubernetes Engine]({{< baseurl >}}/rke/v0.1.x/en/) (RKE), which is Rancher's own lightweight Kubernetes installer. It can launch Kubernetes on any computers, including:
+If you don't want to use a hosted Kubernetes provider, you can have Rancher launch a Kubernetes cluster using any nodes you want. When Rancher deploys Kubernetes onto these nodes, it uses [Rancher Kubernetes Engine]({{< baseurl >}}/rke/latest/en/) (RKE), which is Rancher's own lightweight Kubernetes installer. It can launch Kubernetes on any computers, including:
- Bare-metal servers
- On-premise virtual machines
@@ -15,12 +15,16 @@ RKE launched clusters are separated into two categories:
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 hosted by an infrastructure provider 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.
+ As of v2.2.0, [cloud credential]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#cloud-credentials) are created to store credentials for launching nodes in your infrastructure providers. There are two benefits of using a cloud credential:
+ - Credentials are stored as a Kubernetes secret, which is not only more secure, but it also allows you to edit a node template without having to enter your credentials every time.
+ - Multiple node templates can share the same cloud credential to create node pools. If your key is compromised or expired, the cloud credential can be updated in a single place, which allows all node templates that are using it to be updated at once.
+
- [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 already exist in a cloud provider. With this option, you will run a Rancher agent Docker container on the machine.
>**Note:** If you want to reuse a node from a previous custom cluster, [clean the node]({{< baseurl >}}/rancher/v2.x/en/admin-settings/removing-rancher/rancher-cluster-nodes/) before using it in a cluster again. If you reuse a node that hasn't been cleaned, cluster provisioning may fail.
-
+
### Requirements
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/_index.md
index 3ab3fabc935..8e96cf63b2e 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/_index.md
@@ -2,8 +2,6 @@
title: Nodes Hosted in an Infrastructure Provider
weight: 2205
aliases:
- - /rancher/v2.x/en/concepts/global-configuration/node-drivers/
- - /rancher/v2.x/en/tasks/global-configuration/node-drivers/
- /rancher/v2.x/en/concepts/global-configuration/node-templates/
---
@@ -19,33 +17,22 @@ A node template is the saved configuration for the parameters to use when provis
After you create a node template in Rancher, it's saved so that you can use this template again to create other node pools. Node templates are bound to your login. After you add a template, you can remove them from your user profile.
+## Cloud Credentials
+
+_Available as of v2.2.0_
+
+Node templates can use cloud credentials to store credentials for launching nodes in your cloud provider, which has some benefits:
+
+- Cloud credentials are stored as Kubernetes secrets for security. Credentials are no longer needed to be re-entered any time you want to edit a node template.
+
+- After the cloud credential is created, it can be re-used to create additional node templates.
+
+- When access and secret keys are expired or compromised, the cloud credential can be updated with the new information, which will automatically be updated for all the node templates referencing this cloud credential.
+
+> **Note:** As of v2.2.0, the default `active` [node drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/node-drivers/) and any node driver, that has fields marked as `password`, are required to use cloud credentials. If you have upgraded to v2.2.0, existing node templates will continue to work with the previous account access information, but when you edit the node template, you will be required to create a cloud credential and the node template will start using it.
+
+After cloud credentials are created, the user can start [managing the cloud credentials that they created]({{< baseurl >}}/rancher/v2.x/en/user-settings/cloud-credentials/).
+
## Node Drivers
-A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). The availability of which node driver to display when creating node templates is defined based on the node driver's status. Only `active` node drivers will be displayed as an option for creating node templates. By default, Rancher is packaged with many existing Docker Machine drivers, but you can also create custom node drivers to add to Rancher.
-
-If there are specific node drivers that you don't want to show to your users, you would need to de-activate these node drivers.
-
-#### Managing Node Drivers
-
->**Prerequisites:** To create, edit, or delete drivers, you need _one_ of the following permissions:
->
->- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/)
->- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Node Drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#global-permissions-reference) role assigned.
-
-## Adding Custom Node Drivers
-
-If you want to use a node driver that Rancher doesn't support out-of-the-box, you can add the provider's drivers in order to start using them to create node templates and eventually node pools.
-
-1. From the **Global** view, select **Node Drivers** from the main menu.
-
-2. Click **Add Node Driver**.
-
-3. Complete the **Add Node Driver** form. Then click **Create**.
-
-## Activating/Deactivating Node Drivers
-
-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**.
+If you don't find the node driver that you want to use, you can see if it is available in Rancher's built-in [node drivers and activate it]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/node-drivers/#activating-deactivating-node-drivers), or you can [add your own custom node driver]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/node-drivers/#adding-custom-node-drivers).
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/azure/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/azure/_index.md
index dfece5159ba..43bb3b1979c 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/azure/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/azure/_index.md
@@ -24,10 +24,12 @@ Use {{< product >}} to create a Kubernetes cluster in Azure.
2. Complete the **Azure Options** form.
- - **Placement** sets the geographical region where where your cluster is hosted and other location metadata.
-
- **Account Access** stores your account information for authenticating with Azure.
+ {{< step_create-cloud-credential >}}
+
+ - **Placement** sets the geographical region where where your cluster is hosted and other location metadata.
+
- **Network** configures the networking used in your cluster.
- **Instance** customizes your VM configuration.
@@ -37,7 +39,7 @@ Use {{< product >}} to create a Kubernetes cluster in Azure.
4. Click **Create**.
5. **Optional:** Add additional node pools.
-
+
7. Review your options to confirm they're correct. Then click **Create**.
{{< result_create-cluster >}}
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/_index.md
index 479683c182c..811bb6fb8fb 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/_index.md
@@ -21,11 +21,11 @@ Use {{< product >}} to create a Kubernetes cluster using DigitalOcean.
1. Click **Add Node Template**.
- 2. Paste your DigitalOcean Personal Access Token.
+ 2. Complete the **Digital Ocean Options** form.
- [DigitalOcean Instructions: How To Generate a Personal Access Token](https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2#how-to-generate-a-personal-access-token)
+ - **Access Token** stores your DigitalOcean Personal Access Token. Refer to [DigitalOcean Instructions: How To Generate a Personal Access Token](https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2#how-to-generate-a-personal-access-token).
- 3. Complete the **DigitalOcean Options** form.
+ {{< step_create-cloud-credential >}}
- **Droplet Options** provision your cluster's geographical region and specifications.
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md
index 899f4d7d3ac..10adf21a7ea 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md
@@ -19,27 +19,35 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2.
## Create the cluster
1. From the **Clusters** page, click **Add Cluster**.
+
1. Choose **Amazon EC2**.
+
1. Enter a **Cluster Name**.
+
1. {{< step_create-cluster_member-roles >}}
+
1. {{< step_create-cluster_cluster-options >}}Refer to [Selecting Cloud Providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) to configure the Kubernetes Cloud Provider.
+
1. {{< step_create-cluster_node-pools >}}
-1. Click **Add Node Template**.
+ 1. Click **Add Node Template**.
- Complete each of the following forms using information available from the [EC2 Management Console](https://aws.amazon.com/ec2).
+ 1. Complete each of the following forms using information available from the [EC2 Management Console](https://aws.amazon.com/ec2).
- * **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.
+ - **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](#prerequisites) how to create the Access Key and Secret Key and the needed permissions.
- - **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. 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.
+ {{< step_create-cloud-credential >}}
- 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.
+ - **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. 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 IAM policy with PassRole](#example-iam-policy-with-passrole) for an example policy.
1. {{< step_rancher-template >}}
1. Click **Create**.
1. **Optional:** Add additional node pools.
+
1. Review your cluster settings to confirm they are correct. Then click **Create**.
{{< result_create-cluster >}}
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md
index 8eb4e5373cb..c089dec4281 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md
@@ -16,7 +16,7 @@ When creating a vSphere cluster, Rancher first provisions the specified amount o
## Prerequisites
-Before proceeding to create a cluster, you must ensure that you have a vSphere user with sufficient permissions. If you are planning to make use of vSphere volumes for persistent storage in the cluster, there are [additional requirements]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere/) that must be met.
+Before proceeding to create a cluster, you must ensure that you have a vSphere user with sufficient permissions. If you are planning to make use of vSphere volumes for persistent storage in the cluster, there are [additional requirements]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere/) that must be met.
## Provisioning a vSphere Cluster
@@ -61,6 +61,8 @@ To create a cluster, you need to create at least one vSphere [node template]({{<
4. Under [Account Access](#account-access) enter the vCenter FQDN or IP address and the credentials for the vSphere user account (see [Prerequisites](#prerequisites)).
+ {{< step_create-cloud-credential >}}
+
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.
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md
index d858cc4143a..827cbf57002 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md
@@ -3,12 +3,12 @@ title: Cluster Options
weight: 2250
---
-As you configure a new cluster that's provisioned using [RKE]({{< baseurl >}}/rke/v0.1.x/en/), you can choose custom Kubernetes options.
+As you configure a new cluster that's provisioned using [RKE]({{< baseurl >}}/rke/latest/en/), you can choose custom Kubernetes options.
You can configure Kubernetes options one of two ways:
- [Rancher UI](#rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster.
-- [Config File](#config-file): Alternatively, you can create a [RKE config file]({{< baseurl >}}/rke/v0.1.x/en/config-options/) to customize any option offered by Kubernetes.
+- [Config File](#config-file): Alternatively, you can create a [RKE config file]({{< baseurl >}}/rke/latest/en/config-options/) to customize any option offered by Kubernetes.
## Rancher UI
@@ -16,11 +16,9 @@ When creating a cluster using one of the options described in [Rancher Launched
From this section you can choose:
-- The version of Kubernetes installed on your cluster nodes. Rancher uses its own version of Kubernetes based on [hyperkube](https://hub.docker.com/r/kubernetesonarm/hyperkube/), but packaged with more utilities.
+- The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
-- 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. For more details on the different networking providers, please view our [newtorking faqs]({{< baseurl >}}/rancher/v2.x/en/faq/networking/cni-providers/).
+- The [Network Provider](https://kubernetes.io/docs/concepts/cluster-administration/networking/) that the cluster uses. For more details on the different networking providers, please view our [Networking FAQ]({{< baseurl >}}/rancher/v2.x/en/faq/networking/cni-providers/).
>**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.
@@ -30,7 +28,7 @@ From this section you can choose:
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/).
+ As of 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**
>
@@ -42,27 +40,102 @@ From this section you can choose:
In v2.0.5, this was the default option, which did not prevent any network isolation between projects.
- - [Calico](https://docs.projectcalico.org/v3.1/introduction/)
+ - [Calico](https://docs.projectcalico.org/)
+ - [Weave](https://github.com/weaveworks/weave) (_Available as of v2.2.0_)
+
+ When Weave is selected as network provider, Rancher will automatically enable encryption by generating a random password. If you want to specify the password manually, please see how to configure your cluster using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) and the [Weave Network Plug-in Options]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/#weave-network-plug-in-options).
- Another network provider option.
-- 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.
+- If you want to configure a [Kubernetes cloud provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers). If you want to use [volumes and storage]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider.
- >**Note:** If 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.
+ >**Note:** If the cloud provider you want to use is not listed as an option, you will need to use the [config file option](#config-file) to configure the cloud provider. Please reference the [RKE cloud provider documentation]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/) on how to configure the cloud provider.
-- 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.
+If you want to see all the configuration options for a cluster, please click **Show advanced options** on the bottom right. The advanced options are described below:
+
+### Private registries
+
+_Available as of v2.2.0_
+
+If you are using a private registry with authentication for your Docker images, please configure the registry in this section to allow the nodes to pull images from this registry. See [Private Registries]({{< baseurl >}}/rke/latest/en/config-options/private-registries/) for more information.
+
+### Authorized Cluster Endpoint
+
+_Available as of v2.2.0_
+
+Authorized Cluster Endpoint can be used to directly access the Kubernetes API server, without requiring communication through Rancher. This is enabled by default, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates. It is recommended to create an FQDN pointing to a load balancer which load balances across your nodes with the `controlplane` role. If you are using private CA signed certificates on the load balancer, you have to supply the CA certificate which will be included in the generated kubeconfig to validate the certificate chain. See the [Kubeconfig Files]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubeconfig/) for more information.
+
+### Advanced Cluster Options
+
+#### Nginx Ingress
+
+Option to enable or disable the [NGINX ingress controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/).
+
+#### Node Port Range
+
+Option to change the range of ports that can be used for [NodePort services](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport). Default is `30000-32767`.
+
+#### Metrics Server Monitoring
+
+Option to enable or disable [Metrics Server]({{< baseurl >}}/rke/latest/en/config-options/add-ons/metrics-server/).
+
+#### Pod Security Policy Support
+
+Option to enable and select a default [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.
+
+#### Docker version on nodes
+
+Option to require [a supported Docker version]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/) installed on the cluster nodes that are added to the cluster, or to allow unsupported Docker versions installed on the cluster nodes.
+
+#### Docker Root Directory
+
+If the nodes you are adding to the cluster have Docker configured with a non-default Docker Root Directory (default is `/var/lib/docker`), please specify the correct Docker Root Directory in this option.
+
+#### Recurring etcd Snapshots
+
+Option to enable or disable [recurring etcd snaphots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots).
## Config File
>**Note:** In Rancher v2.0.5 and v2.0.6, the names of services in the Config File (YAML) should contain underscores only: `kube_api` and `kube_controller`.
-Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/v0.1.x/en/config-options/) in an RKE installation.
+Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/latest/en/config-options/) in an RKE installation.
- To edit an RKE config file directly from the Rancher UI, click **Edit as YAML**.
-- To read from an existing RKE file, click **Read from File**.
+- To read from an existing RKE file, click **Read from a file**.
-For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/).
+For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/latest/en/example-yamls/).
+
+### Rancher specific parameters
+
+_Available as of v2.2.0_
+
+Besides the RKE config file options, there are also Rancher specific settings that can be configured in the Config File (YAML):
+
+#### docker_root_dir
+
+See [Docker Root Directory](#docker-root-directory).
+
+#### enable_cluster_monitoring
+
+Option to enable or disable [Cluster Monitoring]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/).
+
+#### enable_network_policy
+
+Option to enable or disable Project Network Isolation.
+
+#### local_cluster_auth_endpoint
+
+See [Authorized Cluster Endpoint](#authorized-cluster-endpoint).
+
+Example:
+
+```yaml
+local_cluster_auth_endpoint:
+ enabled: true
+ fqdn: "FQDN"
+ ca_certs: "BASE64_CACERT"
+```
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md
index 13a52e873d2..96088b6c645 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/_index.md
@@ -13,10 +13,10 @@ By default, the **Cloud Provider** option is set to `None`. Supported cloud prov
The `Custom` cloud provider is available if you want to configure any [Kubernetes cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/).
-For the custom cloud provider option, you can refer to the [RKE docs]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) on how to edit the yaml file for your specific cloud provider. There are specific cloud providers that have more detailed configuration :
+For the custom cloud provider option, you can refer to the [RKE docs]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/) on how to edit the yaml file for your specific cloud provider. There are specific cloud providers that have more detailed configuration :
-* [vSphere]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere/)
-* [Openstack]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/openstack/)
+* [vSphere]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere/)
+* [Openstack]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/openstack/)
> **Warning:** Your cluster will not provision correctly if you configure a cloud provider cluster of nodes that do not meet the prerequisites. Prerequisites for supported cloud providers are listed below.
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md
index b4648183f8c..c0f110517da 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md
@@ -15,7 +15,7 @@ This guide walks you through create of a custom cluster that includes 3 nodes: a
>**Notes:**
>
->- For a summary of Kubernetes features supported in Windows, see [Using Windows Server Containers in Kubernetes](https://kubernetes.io/docs/getting-started-guides/windows/#supported-features).
+>- For a summary of Kubernetes features supported in Windows, see [Using Windows in Kubernetes](https://kubernetes.io/docs/setup/windows/intro-windows-in-kubernetes/).
>- Windows containers must run on Windows Server 1803 nodes. Windows Server 1709 and earlier versions do not support Kubernetes properly.
>- Containers built for Windows Server 1709 or earlier do not run on Windows Server 1803. You must build containers on Windows Server 1803 to run these containers on Windows Server 1803.
@@ -28,12 +28,11 @@ When setting up a custom cluster with support for Windows nodes and containers,
- [1. Provision Hosts](#1-provision-hosts)
-- [2. Cloud-host VM Networking Configuration](#2-cloud-host-vm-networking-configuration)
+- [2. Cloud-host VM Networking Configuration](#2-cloud-hosted-vm-networking-configuration)
- [3. Create the Custom Cluster](#3-create-the-custom-cluster)
- [4. Add Linux Host for Ingress Support](#4-add-linux-host-for-ingress-support)
- [5. Adding Windows Workers](#5-adding-windows-workers)
-- [6. Cloud-host VM Routes Configuration](#6-cloud-host-vm-routes-configuration)
-- [Troubleshooting](#troubleshooting)
+- [6. Cloud-host VM Routes Configuration](#6-cloud-hosted-vm-routes-configuration)
@@ -43,14 +42,14 @@ To begin provisioning a custom cluster with Windows support, prepare your host s
- Cloud-hosted VMs
- VMs from virtualization clusters
-- Bare-metal servers
+- Bare-metal servers
The table below lists the [Kubernetes roles]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) you'll assign to each host, although you won't enable these roles until further along in the configuration process—we're just informing you of each node's purpose. The first node, a Linux host, is primarily responsible for managing the Kubernetes control plane, although, in this use case, we're installing all three roles on this node. Node 2 is also a Linux worker, which is responsible for Ingress support. Finally, the third node is your Windows worker, which will run your Windows applications.
Node | Operating System | Future Cluster Role(s)
--------|------------------|------
Node 1 | Linux (Ubuntu Server 16.04 recommended) | [Control Plane]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#control-plane-nodes), [etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#etcd), [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
-Node 2 | Linux (Ubuntu Server 16.04 recommended) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes) (This node is used for Ingress support)
+Node 2 | Linux (Ubuntu Server 16.04 recommended) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes) (This node is used for Ingress support)
Node 3 | Windows (*Windows Server 1803 required*) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
### Requirements
@@ -115,7 +114,7 @@ After the initial provisioning of your custom cluster, your cluster only has a s
1. Using the content menu, open the custom cluster your created in [2. Create the Custom Cluster](#2-create-the-custom-cluster).
-1. From the main menu, select **Nodes**.
+1. From the main menu, select **Nodes**.
1. Click **Edit Cluster**.
@@ -127,7 +126,7 @@ After the initial provisioning of your custom cluster, your cluster only has a s
1. Log in to your Linux host using a remote Terminal connection. Run the command copied to your clipboard.
-1. From **Rancher**, click **Save**.
+1. From **Rancher**, click **Save**.
**Result:** The worker role is installed on your Linux host, and the node registers with Rancher.
@@ -135,7 +134,7 @@ After the initial provisioning of your custom cluster, your cluster only has a s
You can add Windows hosts to a custom cluster by editing the cluster and choosing the **Windows** option.
-1. From the main menu, select **Nodes**.
+1. From the main menu, select **Nodes**.
1. Click **Edit Cluster**.
@@ -147,7 +146,7 @@ You can add Windows hosts to a custom cluster by editing the cluster and choosin
1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **Command Prompt (CMD)**.
-1. From Rancher, click **Save**.
+1. From Rancher, click **Save**.
1. **Optional:** Repeat these instruction if you want to add more Windows nodes to your cluster.
@@ -157,11 +156,11 @@ You can add Windows hosts to a custom cluster by editing the cluster and choosin
In Windows clusters, containers communicate with each other using the `host-gw` mode of Flannel. In `host-gw` mode, all containers on the same node belong to a private subnet, and traffic routes from a subnet on one node to a subnet on another node through the host network.
-- When worker nodes are provisioned on AWS, virtualization clusters, or bare metal servers, make sure they belong to the same layer 2 subnet. If the nodes don't belong to the same layer 2 subnet, `host-gw` networking will not work. Please contact [Rancher support](https://rancher.com/support/) if your worker nodes on AWS, virtualization clusters, or bare metal servers don't belong to the same layer 2 network.
+- When worker nodes are provisioned on AWS, virtualization clusters, or bare metal servers, make sure they belong to the same layer 2 subnet. If the nodes don't belong to the same layer 2 subnet, `host-gw` networking will not work.
- When worker nodes are provisioned on GCE or Azure, they are not on the same layer 2 subnet. Nodes on GCE and Azure belong to a routable layer 3 network. Follow the instructions below to configure GCE and Azure so that the cloud network knows how to route the host subnets on each node.
-To configure host subnet routing on GCE or Azure, first run the following command to find out the host subnets on each worker node:
+To configure host subnet routing on GCE or Azure, first run the following command to find out the host subnets on each worker node:
```bash
kubectl get nodes -o custom-columns=nodeName:.metadata.name,nodeIP:status.addresses[0].address,routeDestination:.spec.podCIDR
@@ -176,4 +175,3 @@ Azure VM | For Azure, create a routing table: [Custom Routes: User-defined](http
` `
-
diff --git a/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md b/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md
index 448c819b7ac..0344d47c4b5 100644
--- a/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md
+++ b/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md
@@ -15,7 +15,7 @@ For more information visit [CNI GitHub project](https://github.com/containernetw
### What Network Models are Used in CNI?
-CNI providers implement their network fabric using either an encapsulated network model such as Virtual Extensible Lan ([VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)) or an unencapsulated network model such as Border Gateway Protocol ([BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)).
+CNI network providers implement their network fabric using either an encapsulated network model such as Virtual Extensible Lan ([VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)) or an unencapsulated network model such as Border Gateway Protocol ([BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)).
#### What is an Encapsulated Network?
@@ -23,11 +23,11 @@ This network model provides a logical Layer 2 (L2) network encapsulated over the
In simple terms, this network model generates a kind of network bridge extended between Kubernetes workers, where pods are connected.
-This network model is used when an extended L2 bridge is preferred. This network model is sensible for L3 network latencies of the Kubernetes workers. If datacenters are in distinct geolocations, be sure to have low latencies between them to avoid eventual network segmentation.
+This network model is used when an extended L2 bridge is preferred. This network model is sensitive to L3 network latencies of the Kubernetes workers. If datacenters are in distinct geolocations, be sure to have low latencies between them to avoid eventual network segmentation.
-CNI providers using this network model include Flannel, Canal, and Weave.
+CNI network providers using this network model include Flannel, Canal, and Weave.
-
+
#### What is an Unencapsulated Network?
@@ -35,23 +35,23 @@ This network model provides an L3 network to route packets between containers. T
In simple terms, this network model generates a kind of network router extended between Kubernetes workers, which provides information about how to reach pods.
-This network model is used when a routed L3 network is preferred. This mode dynamically updates routes at the OS level for Kubernetes workers. It's less sensible to latency.
+This network model is used when a routed L3 network is preferred. This mode dynamically updates routes at the OS level for Kubernetes workers. It's less sensitive to latency.
-CNI providers using this network model include Calico and Romana.
+CNI network providers using this network model include Calico and Romana.
-
+
### What CNI Providers are Provided by Rancher?
-Out-of-the-box, Rancher provides three different CNI providers for Kubernetes clusters: Canal, Flannel, and Calico. You can choose your CNI when you create new Kubernetes clusters from Rancher.
+Out-of-the-box, Rancher provides the following CNI network providers for Kubernetes clusters: Canal, Flannel, Calico and Weave (Weave is available as of v2.2.0). You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
#### Canal
-Canal is a CNI provider that gives you the best of Flannel and Calico. It allows users to easily deploy Calico and Flannel networking together as a unified networking solution, combining Calico’s network policy enforcement with the rich superset of Calico (unencapsulated) and/or Flannel (encapsulated) network connectivity options.
+Canal is a CNI network provider that gives you the best of Flannel and Calico. It allows users to easily deploy Calico and Flannel networking together as a unified networking solution, combining Calico’s network policy enforcement with the rich superset of Calico (unencapsulated) and/or Flannel (encapsulated) network connectivity options.
-In Rancher, Canal is the default CNI provider combined with Flannel and VXLAN encapsulation.
+In Rancher, Canal is the default CNI network provider combined with Flannel and VXLAN encapsulation.
Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (healthcheck). See [Port Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/references/) for more details.
@@ -65,7 +65,7 @@ For more information, see the [Canal GitHub Page](https://github.com/projectcali
Flannel is a simple and easy way to configure L3 network fabric designed for Kubernetes. Flannel runs a single binary agent named flanneld on each host, which is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host's public IP). Packets are forwarded using one of several backend mechanisms, with the default encapsulation being [VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan).
-Encapsulated traffic is unencrypted by default. Threfore, flannel provides an experimental backend for encryption, [IPSec](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#ipsec), which makes use of [strongSwan](https://www.strongswan.org/) to establish encrypted IPSec tunnels between Kubernetes workers.
+Encapsulated traffic is unencrypted by default. Therefore, flannel provides an experimental backend for encryption, [IPSec](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#ipsec), which makes use of [strongSwan](https://www.strongswan.org/) to establish encrypted IPSec tunnels between Kubernetes workers.
Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (healthcheck). See [Port Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/references/) for more details.
@@ -81,7 +81,7 @@ Calico enables networking and network policy in Kubernetes clusters across the c
Calico also provides a stateless IP-in-IP encapsulation mode that can be used, if necessary. Calico also offers policy isolation, allowing you to secure and govern your Kubernetes workloads using advanced ingress and egress policies.
-Kubernetes workers should open TCP port `179` (BGP).
+Kubernetes workers should open TCP port `179` (BGP). See [Port Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/references/) for more details.
@@ -91,26 +91,40 @@ For more information, see the following pages:
- [Project Calico GitHub Page](https://github.com/projectcalico/calico)
+#### Weave
+
+
+
+_Available as of v2.2.0_
+
+Weave enables networking and network policy in Kubernetes clusters across the cloud. Additionally, it support encrypting traffic between the peers.
+
+Kubernetes workers should open TCP port `6783` (control port), UDP port `6783` and UDP port `6784` (data ports). See [Port Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/references/) for more details.
+
+For more information, see the following pages:
+
+- [Weave Net Official Site](https://www.weave.works/)
+
### CNI Features by Provider
-The following table summarizes the different features available for each CNI provider provided by Rancher.
+The following table summarizes the different features available for each CNI network provider provided by Rancher.
| Provider | Network Model | Route Distribution | Network Policies | Mesh | External Datastore | Encryption | Ingress/Egress Policies |
-| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
+| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| Canal | Encapsulated (VXLAN) | No | Yes | No | K8S API | No | Yes |
| Flannel | Encapsulated (VXLAN) | No | No | No | K8S API | No | No |
| Calico | Unencapsulated | Yes | Yes | Yes | Etcd | Yes | Yes |
-
+| Weave | Encapsulated | Yes | Yes | Yes | No | Yes | Yes |
- Network Model: Encapsulated or unencapsulated. For more information, see [What Network Models are Used in CNI?](#what-network-models-are-used-in-cni)
-- Route Distribution: An exterior gateway protocol designed to exchange routing and reachability information on the Internet. BGP can assist with pod-to-pod networking between clusters. This feature is a must on unencapsulated CNI providers, and it is typically done by BGP. If you plan to build clusters split across network segments, route distribution is a feature that's nice-to-have.
+- Route Distribution: An exterior gateway protocol designed to exchange routing and reachability information on the Internet. BGP can assist with pod-to-pod networking between clusters. This feature is a must on unencapsulated CNI network providers, and it is typically done by BGP. If you plan to build clusters split across network segments, route distribution is a feature that's nice-to-have.
- Network Policies: Kubernetes offers functionality to enforce rules about which services can communicate with each other using network policies. This feature is stable as of Kubernetes v1.7 and is ready to use with certain networking plugins.
- Mesh: This feature allows service-to-service networking communication between distinct Kubernetes clusters.
-- External Datastore: CNI providers with this feature need an external datastore for its data.
+- External Datastore: CNI network providers with this feature need an external datastore for its data.
- Encyption: This feature allows cyphered and secure network control and data planes.
@@ -122,14 +136,18 @@ The following table summarizes different GitHub metrics to give you an idea of e
| Provider | Project | Stars | Forks | Contributors |
| ---- | ---- | ---- | ---- | ---- |
-| Canal | https://github.com/projectcalico/canal | 536 | 75 | 19 |
-| flannel | https://github.com/coreos/flannel | 3.279 | 774 | 107 |
-| Calico | https://github.com/projectcalico/calico | 572 | 225 | 82 |
+| Canal | https://github.com/projectcalico/canal | 580 | 84 | 20 |
+| flannel | https://github.com/coreos/flannel | 3980 | 987 | 123 |
+| Calico | https://github.com/projectcalico/calico | 953 | 305 | 101 |
+| Weave | https://github.com/weaveworks/weave/ | 5457 | 501 | 63 |
+
### Which CNI Provider Should I Use?
-It depends on your project needs. There are many different providers, which each have various features and options. There isn't one provider that meets everyone's needs. At the moment, Rancher v2.0 provides the 3 most versatile CNI providers.
+It depends on your project needs. There are many different providers, which each have various features and options. There isn't one provider that meets everyone's needs.
-As of Rancher v2.0.7, Canal is the default CNI provider. We recommend it for most use cases. It provides encapsulated networking for containers with Flannel, while adding Calico network policies that can provide project/namespace isolation in terms of networking.
+As of Rancher v2.0.7, Canal is the default CNI network provider. We recommend it for most use cases. It provides encapsulated networking for containers with Flannel, while adding Calico network policies that can provide project/namespace isolation in terms of networking.
-All of 3 solutions are capable CNI providers and will likely suit your needs.
+### How can I configure a CNI network provider?
+
+Please see [Cluster Options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/) on how to configure a network provider for your cluster. For more advanced configuration options, please see how to configure your cluster using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) and the options for [Network Plug-ins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/).
diff --git a/content/rancher/v2.x/en/faq/technical/_index.md b/content/rancher/v2.x/en/faq/technical/_index.md
index 466f0e9ac70..da0b2063fbc 100644
--- a/content/rancher/v2.x/en/faq/technical/_index.md
+++ b/content/rancher/v2.x/en/faq/technical/_index.md
@@ -156,7 +156,7 @@ When the node is removed from the cluster, and the node is cleaned, you can read
### How can I add additional arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
-You can add additional arguments/binds/environment variables via the [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/).
+You can add additional arguments/binds/environment variables via the [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables]({{< baseurl >}}/rke/latest/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls]({{< baseurl >}}/rke/latest/en/example-yamls/).
### How do I check if my certificate chain is valid?
@@ -226,6 +226,11 @@ This is due to a combination of the following default Kubernetes settings:
See [Kubernetes: kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) and [Kubernetes: kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) for more information on these settings.
+In Kubernetes v1.13, the `TaintBasedEvictions` feature is enabled by default. See [Kubernetes: Taint based Evictions](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint-based-evictions) for more information.
+
+* kube-apiserver (Kubernetes v1.13 and up)
+ * `default-not-ready-toleration-seconds`: Indicates the tolerationSeconds of the toleration for notReady:NoExecute that is added by default to every pod that does not already have such a toleration.
+ * `default-unreachable-toleration-seconds`: Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration.
### Can I use keyboard shortcuts in the UI?
diff --git a/content/rancher/v2.x/en/installation/air-gap-high-availability/_index.md b/content/rancher/v2.x/en/installation/air-gap-high-availability/_index.md
index 5ccf9b0fa9d..6cc0ee32a10 100644
--- a/content/rancher/v2.x/en/installation/air-gap-high-availability/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-high-availability/_index.md
@@ -12,7 +12,7 @@ Rancher supports air gap installs using a private registry. You must have your o
The following CLI tools are required for this install. Make sure these tools are installed on your workstation and available in your `$PATH`.
* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
-* [rke]({{< baseurl >}}/rke/v0.1.x/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
+* [rke]({{< baseurl >}}/rke/latest/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
* [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes.
>**Note:** If you install Rancher in an HA configuration in an air gap environment, you cannot transition to a single-node setup during future upgrades.
@@ -24,6 +24,6 @@ The following CLI tools are required for this install. Make sure these tools are
- [3. Install Kubernetes with RKE]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/)
- [4. Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher/)
- [5. Configure Rancher for the Private Registry]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-for-private-reg/)
-
+- [6. Configure Rancher System Charts]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-system-charts/)
### [Next: Create Nodes and Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/provision-hosts/)
diff --git a/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-for-private-reg/_index.md b/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-for-private-reg/_index.md
index b5d0a5cc75f..ef20c1718c9 100644
--- a/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-for-private-reg/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-for-private-reg/_index.md
@@ -1,6 +1,6 @@
---
title: "5. Configure Rancher for the Private Registry"
-weight:
+weight: 500
aliases:
---
@@ -21,4 +21,6 @@ Rancher needs to be configured to use the private registry in order to provision
1. Change the value to your registry (e.g. `registry.yourdomain.com:port`). Do not prefix the registry with `http://` or `https://`.
- 
\ No newline at end of file
+ 
+
+### [Next: Configure Rancher System Charts]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-system-charts/)
diff --git a/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-system-charts/_index.md b/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-system-charts/_index.md
new file mode 100644
index 00000000000..f3743ba2f49
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-system-charts/_index.md
@@ -0,0 +1,27 @@
+---
+title: "6. Configure Rancher System Charts"
+weight: 600
+aliases:
+---
+
+## A. Prepare System Charts
+
+The [System Charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as moniotring, logging, alerting and global DNS. To be able to use these features in an air gap install, you will need to mirror the `system-charts` repository to a location in your network that Rancher can reach and configure Rancher to use that repository.
+
+## B. Configure System Charts
+
+Rancher needs to be configured to use the Git mirror of the `system-charts` repository.
+
+1. Log into Rancher.
+
+1. Open `https:///v3/catalogs/system-library` in your browser.
+
+ 
+
+1. Click **Edit** on the upper right corner and update the value for **url** to the location of the Git mirror of the `system-charts` repository.
+
+ 
+
+1. Click **Show Request**
+
+1. Click **Send Request**
diff --git a/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md b/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md
index fd4210029e9..cbd37612477 100644
--- a/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-high-availability/install-kube/_index.md
@@ -11,7 +11,7 @@ From a system that can access ports 22/tcp and 6443/tcp on your host nodes, use
Replace values in the code sample below with help of the _RKE Options_ table. Use the IP address or DNS names of the [3 nodes]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/provision-hosts) you created.
->**Tip:** For more details on the options available, see the RKE [Config Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/).
+>**Tip:** For more details on the options available, see the RKE [Config Options]({{< baseurl >}}/rke/latest/en/config-options/).
RKE Options
@@ -51,8 +51,6 @@ private_registries:
is_default: true
```
-
-
## B. Run RKE
After configuring `rancher-cluster.yml`, open Terminal and change directories to the RKE binary. Then enter the command below to stand up your high availability cluster.
@@ -61,4 +59,15 @@ After configuring `rancher-cluster.yml`, open Terminal and change directories to
rke up --config ./rancher-cluster.yml
```
+## C. Save Your Files
+
+> **Important**
+> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
+
+Save a copy of the following files in a secure location:
+
+- `rancher-cluster.yml`: The RKE cluster configuration file.
+- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
+- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.
_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
+
### [Next: Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher)
diff --git a/content/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher/_index.md b/content/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher/_index.md
index 61f989cca0a..7c1c84b1972 100644
--- a/content/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-high-availability/install-rancher/_index.md
@@ -55,13 +55,13 @@ By default, Rancher generates a CA and uses cert manger to issue the certificate
1. From a system connected to the internet, fetch the latest cert-manager chart available from the [official Helm chart repository](https://github.com/helm/charts/tree/master/stable).
```plain
- helm fetch stable/cert-manager
+ helm fetch stable/cert-manager --version 0.5.2
```
1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.
```plain
- helm template ./cert-manager-.tgz --output-dir . \
+ helm template ./cert-manager-v0.5.2.tgz --output-dir . \
--name cert-manager --namespace kube-system \
--set image.repository=/quay.io/jetstack/cert-manager-controller
```
diff --git a/content/rancher/v2.x/en/installation/air-gap-single-node/_index.md b/content/rancher/v2.x/en/installation/air-gap-single-node/_index.md
index 3f7fd9e6302..ee1286bad76 100644
--- a/content/rancher/v2.x/en/installation/air-gap-single-node/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-single-node/_index.md
@@ -15,6 +15,6 @@ Rancher supports air gap installs using a private registry. You must have your o
- [2. Prepare Private Registry]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/prepare-private-registry/)
- [3. Choose an SSL Option and Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/install-rancher/)
- [4. Configure Rancher for Private Registry]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-for-private-reg/)
-
+- [5. Configure Rancher System Charts]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-system-charts/)
### [Next: Provision Linux Host]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/provision-host/)
diff --git a/content/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-for-private-reg/_index.md b/content/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-for-private-reg/_index.md
index 4d9a28bbfc4..cbb98837736 100644
--- a/content/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-for-private-reg/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-for-private-reg/_index.md
@@ -20,4 +20,6 @@ Rancher needs to be configured to use the private registry in order to provision
->**Note:** If you want to configure the setting when starting the rancher/rancher container, you can use the environment variable `CATTLE_SYSTEM_DEFAULT_REGISTRY`.
\ No newline at end of file
+>**Note:** If you want to configure the setting when starting the rancher/rancher container, you can use the environment variable `CATTLE_SYSTEM_DEFAULT_REGISTRY`.
+
+### [Next: Configure Rancher System Charts]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-system-charts/)
diff --git a/content/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-system-charts/_index.md b/content/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-system-charts/_index.md
new file mode 100644
index 00000000000..6317c915e3c
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-system-charts/_index.md
@@ -0,0 +1,27 @@
+---
+title: "5. Configure Rancher System Charts"
+weight: 500
+aliases:
+---
+
+## A. Prepare System Charts
+
+The [System Charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as moniotring, logging, alerting and global DNS. To be able to use these features in an air gap install, you will need to mirror the `system-charts` repository to a location in your network that Rancher can reach and configure Rancher to use that repository.
+
+## B. Configure System Charts
+
+Rancher needs to be configured to use the Git mirror of the `system-charts` repository.
+
+1. Log into Rancher.
+
+1. Open `https:///v3/catalogs/system-library` in your browser.
+
+ 
+
+1. Click **Edit** on the upper right corner and update the value for **url** to the location of the Git mirror of the `system-charts` repository.
+
+ 
+
+1. Click **Show Request**
+
+1. Click **Send Request**
diff --git a/content/rancher/v2.x/en/installation/air-gap-single-node/install-rancher/_index.md b/content/rancher/v2.x/en/installation/air-gap-single-node/install-rancher/_index.md
index 4b550200634..bf50909cc44 100644
--- a/content/rancher/v2.x/en/installation/air-gap-single-node/install-rancher/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-single-node/install-rancher/_index.md
@@ -11,7 +11,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
>**Do you want to...**
>
>- Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/).
->- Record all transactions with the Rancher API? See [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/#enable-api-audit-log).
+>- Record all transactions with the Rancher API? See [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/#api-audit-log).
Choose from the following options:
@@ -91,4 +91,4 @@ docker run -d --restart=unless-stopped \
{{% /accordion %}}
-### [Next: Configure Rancher for the Private Registry]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-for-private-reg/)
\ No newline at end of file
+### [Next: Configure Rancher for the Private Registry]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-for-private-reg/)
diff --git a/content/rancher/v2.x/en/installation/arm64-platform/_index.md b/content/rancher/v2.x/en/installation/arm64-platform/_index.md
new file mode 100644
index 00000000000..02fd9660303
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/arm64-platform/_index.md
@@ -0,0 +1,27 @@
+---
+title: Running on ARM64 (Experimental)
+weight: 7600
+---
+
+_Available as of v2.2.0_
+
+> **Important:**
+>
+> Running on an ARM64 platform is currently an experimental feature and is not yet officially supported in Rancher. Therefore, we do not recommend using ARM64 based nodes in a production environment.
+
+The following options are available when using an ARM64 platform:
+
+- Running Rancher on ARM64 based node(s)
+ - Only [Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/)
+- Create custom cluster and adding ARM64 based node(s)
+ - Kubernetes cluster version must be 1.12 or higher
+ - CNI Network Provider must be [Flannel]({{< baseurl >}}/rancher/v2.x/en/faq/networking/cni-providers/#flannel)
+- Importing clusters that contain ARM64 based nodes
+ - Kubernetes cluster version must be 1.12 or higher
+
+Please see [Cluster Options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/) how to configure the cluster options.
+
+The following features are not tested:
+
+* Monitoring, alerts, notifiers, pipelines and logging
+* Launching apps from the catalog
diff --git a/content/rancher/v2.x/en/installation/ha/_index.md b/content/rancher/v2.x/en/installation/ha/_index.md
index ec556849030..fe82897b89e 100644
--- a/content/rancher/v2.x/en/installation/ha/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/_index.md
@@ -25,7 +25,7 @@ This procedure walks you through setting up a 3-node cluster with RKE and instal
The following CLI tools are required for this install. Please make sure these tools are installed and available in your `$PATH`
* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
-* [rke]({{< baseurl >}}/rke/v0.1.x/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
+* [rke]({{< baseurl >}}/rke/latest/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
* [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes.
> **Important:** Due to an issue with Helm v2.12.0 and cert-manager, please use Helm v2.12.1 or higher.
diff --git a/content/rancher/v2.x/en/installation/ha/create-nodes-lb/_index.md b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/_index.md
index 3d4815151a8..ade47ce26fe 100644
--- a/content/rancher/v2.x/en/installation/ha/create-nodes-lb/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/_index.md
@@ -11,7 +11,7 @@ Use your provider of choice to provision 3 nodes and a Load Balancer endpoint fo
View the supported operating systems and hardware/software/networking requirements for nodes running Rancher at [Node Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements).
-View the OS requirements for RKE at [RKE Requirements]({{< baseurl >}}/rke/v0.1.x/en/os/)
+View the OS requirements for RKE at [RKE Requirements]({{< baseurl >}}/rke/latest/en/os/)
### Load Balancer
diff --git a/content/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/_index.md b/content/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/_index.md
index 08bb6752101..6bdea73a478 100644
--- a/content/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/_index.md
@@ -27,7 +27,9 @@ weight: 276
| `auditLog.maxAge` | 1 | `int` - maximum number of days to retain old audit log files |
| `auditLog.maxBackups` | 1 | `int` - maximum number of audit log files to retain |
| `auditLog.maxSize` | 100 | `int` - maximum size in megabytes of the audit log file before it gets rotated |
+| `busyboxImage` | "busybox" | `string` - Image location for busybox image used to collect audit logs _Note: Available as of v2.2.0_ |
| `debug` | false | `bool` - set debug flag on rancher server |
+| `extraEnv` | [] | `list` - set additional environment variables for Rancher _Note: Available as of v2.2.0_ |
| `imagePullSecrets` | [] | `list` - list of names of Secret resource containing private registry credentials |
| `ingress.extraAnnotations` | {} | `map` - additional annotations to customize the ingress |
| `proxy` | "" | `string` - HTTP[S] proxy server for Rancher |
@@ -41,18 +43,42 @@ weight: 276
### API Audit Log
-Enabling the [API Audit Log](https://rancher.com/docs/rancher/v2.x/en/installation/api-auditing/).
+Enabling the [API Audit Log]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing/).
-You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools](https://rancher.com/docs/rancher/v2.x/en/tools/logging/) for the `System` Project on the Rancher server cluster.
+You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools]({{< baseurl >}}/rancher/v2.x/en/tools/logging/) for the `System` Project on the Rancher server cluster.
```plain
--set auditLog.level=1
```
-By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`. You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools](https://rancher.com/docs/rancher/v2.x/en/tools/logging/) for the Rancher server cluster or System Project.
+By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`. You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools]({{< baseurl >}}/rancher/v2.x/en/tools/logging/) for the Rancher server cluster or System Project.
Set the `auditLog.destination` to `hostPath` to forward logs to volume shared with the host system instead of streaming to a sidecar container. When setting the destination to `hostPath` you may want to adjust the other auditLog parameters for log rotation.
+### Setting Extra Environment Variables
+
+_Available as of v2.2.0_
+
+You can set extra environment variables for Rancher server using `extraEnv`. This list uses the same `name` and `value` keys as the container manifest definitions. Remember to quote the values.
+
+```plain
+--set 'extraEnv[0].name=CATTLE_SYSTEM_DEFAULT_REGISTRY'
+--set 'extraEnv[0].value=http://registry.example.com/'
+```
+
+### TLS settings
+
+_Available as of v2.2.0_
+
+To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` and `CATTLE_TLS_CIPHERS` environment variables. For example, to configure TLS 1.0 as minimum accepted TLS version:
+
+```plain
+--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
+--set 'extraEnv[0].value=1.0'
+```
+
+See [TLS settings]({{< baseurl >}}/rancher/v2.x/en/admin-settings/tls-settings) for more information and options.
+
### Import `local` Cluster
By default Rancher server will detect and import the `local` cluster it's running on. User with access to the `local` cluster will essentially have "root" access to all the clusters managed by Rancher server.
@@ -104,8 +130,8 @@ kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-
For details on installing Rancher with a private registry, see:
-- [Air Gap: Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/)
-- [Air Gap: High Availability Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/)
+- [Air Gap: Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/)
+- [Air Gap: High Availability Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/)
### External TLS Termination
@@ -140,7 +166,7 @@ Rancher will respond `200` to health checks on the `/healthz` endpoint.
This NGINX configuration is tested on NGINX 1.14.
- >**Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
+ >**Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
* Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster.
* Replace both occurences of `FQDN` to the DNS name for Rancher.
diff --git a/content/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md b/content/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md
index 8b1c8b11f3a..98d8199aee6 100644
--- a/content/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md
@@ -15,6 +15,8 @@ kubectl -n cattle-system create secret tls tls-rancher-ingress \
--key=tls.key
```
+> **Note:** If you want to replace the certificate, you can delete the `tls-rancher-ingress` secret using `kubectl -n cattle-system delete secret tls-rancher-ingress` and add a new one using the command shown above. Replacing the certificate is only supported if the new certificate is signed by the same CA as the certificate currently in use.
+
### Using a Private CA Signed Certificate
If you are using a private CA, Rancher requires a copy of the CA certificate which is used by the Rancher Agent to validate the connection to the server.
diff --git a/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md
index 5a8d9c65ff0..88dbcb7e8f9 100644
--- a/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md
@@ -50,7 +50,7 @@ services:
RKE has many configuration options for customizing the install to suit your specific environment.
-Please see the [RKE Documentation]({{< baseurl >}}/rke/v0.1.x/en/config-options/) for the full list of options and capabilities.
+Please see the [RKE Documentation]({{< baseurl >}}/rke/latest/en/config-options/) for the full list of options and capabilities.
### Run RKE
@@ -78,9 +78,9 @@ Test your connectivity with `kubectl` and see if all your nodes are in `Ready` s
kubectl get nodes
NAME STATUS ROLES AGE VERSION
-165.227.114.63 Ready controlplane,etcd,worker 11m v1.10.1
-165.227.116.167 Ready controlplane,etcd,worker 11m v1.10.1
-165.227.127.226 Ready controlplane,etcd,worker 11m v1.10.1
+165.227.114.63 Ready controlplane,etcd,worker 11m v1.13.5
+165.227.116.167 Ready controlplane,etcd,worker 11m v1.13.5
+165.227.127.226 Ready controlplane,etcd,worker 11m v1.13.5
```
### Check the Health of Your Cluster Pods
@@ -112,7 +112,14 @@ kube-system rke-network-plugin-deploy-job-6pbgj 0/1 Completed
### Save Your Files
-Save a copy of the `kube_config_rancher-cluster.yml` and `rancher-cluster.yml` files. You will need these files to maintain and upgrade your Rancher instance.
+> **Important**
+> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
+
+Save a copy of the following files in a secure location:
+
+- `rancher-cluster.yml`: The RKE cluster configuration file.
+- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
+- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.
_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
### Issues or errors?
diff --git a/content/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/_index.md
index 20dd6a9a417..36dc7198bf2 100644
--- a/content/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/_index.md
@@ -2,7 +2,7 @@
title: Enable API Auditing
weight: 300
aliases:
- - /rke/v0.1.x/en/config-options/add-ons/api-auditing/
+ - /rke/latest/en/config-options/add-ons/api-auditing/
---
>**Important: RKE add-on install is only supported up to Rancher v2.0.8**
diff --git a/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/_index.md
index b192803568f..70a5558a7d3 100644
--- a/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/_index.md
@@ -150,7 +150,7 @@ Choose a fully qualified domain name (FQDN) that you want to use to access Ranch
RKE (Rancher Kubernetes Engine) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. We will use RKE to setup our cluster and run Rancher.
-1. Follow the [RKE Install]({{< baseurl >}}/rke/v0.1.x/en/installation) instructions.
+1. Follow the [RKE Install]({{< baseurl >}}/rke/latest/en/installation) instructions.
2. Confirm that RKE is now executable by running the following command:
@@ -170,7 +170,7 @@ RKE uses a `.yml` config file to install and configure your Kubernetes cluster.
>**Advanced Config Options:**
>
>- Want records of all transactions with the Rancher API? Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/).
- >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/).
+ >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/latest/en/config-options/).
2. Rename the file to `rancher-cluster.yml`.
@@ -186,7 +186,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec
For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`.
>**Note:**
- > When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) >for RHEL/CentOS specific requirements.
+ > When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) >for RHEL/CentOS specific requirements.
nodes:
# The IP address or hostname of the node
diff --git a/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/_index.md
index 75f8b9ea423..93a1b4fb16b 100644
--- a/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/_index.md
@@ -98,7 +98,7 @@ Choose a fully qualified domain name (FQDN) that you want to use to access Ranch
RKE (Rancher Kubernetes Engine) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. We will use RKE to setup our cluster and run Rancher.
-1. Follow the [RKE Install]({{< baseurl >}}/rke/v0.1.x/en/installation) instructions.
+1. Follow the [RKE Install]({{< baseurl >}}/rke/latest/en/installation) instructions.
2. Confirm that RKE is now executable by running the following command:
@@ -118,7 +118,7 @@ RKE uses a YAML config file to install and configure your Kubernetes cluster. Th
>**Advanced Config Options:**
>
>- Want records of all transactions with the Rancher API? Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/).
- >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/).
+ >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/latest/en/config-options/).
2. Rename the file to `rancher-cluster.yml`.
@@ -135,7 +135,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec
>**Note:**
>
- >When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
+ >When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
nodes:
# The IP address or hostname of the node
diff --git a/content/rancher/v2.x/en/installation/options/_index.md b/content/rancher/v2.x/en/installation/options/_index.md
new file mode 100644
index 00000000000..410c5f6bc95
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/options/_index.md
@@ -0,0 +1,12 @@
+---
+title: Advanced Options
+weight: 350
+---
+
+When installing Rancher, there are several advanced options that can be enabled during installation. Within each install guide, these options are presented. Learn more about these options:
+
+| Advanced Option | Available as of |
+| --- | ---|
+| [Custom CA Certificate]({{< baseurl >}}/rancher/v2.x/en/installation/options/custom-ca-root-certificate/) | v2.0.0 |
+| [API Audit Log]({{< baseurl >}}/rancher/v2.x/en/installation/options/api-audit-log/) | v2.0.0 |
+| [TLS Settings]({{< baseurl >}}/rancher/v2.x/en/installation/options/tls-settings/) | v2.1.7 |
diff --git a/content/rancher/v2.x/en/admin-settings/api-audit-log/_index.md b/content/rancher/v2.x/en/installation/options/api-audit-log/_index.md
similarity index 98%
rename from content/rancher/v2.x/en/admin-settings/api-audit-log/_index.md
rename to content/rancher/v2.x/en/installation/options/api-audit-log/_index.md
index 48876644434..147153aea90 100644
--- a/content/rancher/v2.x/en/admin-settings/api-audit-log/_index.md
+++ b/content/rancher/v2.x/en/installation/options/api-audit-log/_index.md
@@ -2,7 +2,9 @@
title: API Audit Log
weight: 10000
aliases:
-- /rancher/v2.x/en/installation/api-auditing
+ - /rancher/v2.x/en/installation/api-auditing/
+ - /rancher/v2.x/en/admin-settings/api-auditing/
+ - /rancher/v2.x/en/admin-settings/api-audit-log/
---
You can enable the API audit log to record the sequence of system events initiated by individual users. You can know what happened, when it happened, who initiated it, and what cluster it affected. When you enable this feature, all requests to the Rancher API and all responses from it are written to a log.
@@ -13,9 +15,9 @@ You can enable API Auditing during Rancher installation or upgrade.
The Audit Log is enabled and configured by passing environment variables to the Rancher server container. See the following to enable on your installation.
-- [Single Node Install - Enable API Audit Log]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/#enable-api-audit-log)
+- [Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/#api-audit-log)
-- [HA Install - Enable API Audit Log]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#enable-api-audit-log)
+- [HA Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#api-audit-log)
## API Audit Log Options
@@ -23,7 +25,7 @@ The usage below defines rules about what the audit log should record and what da
Parameter | Description |
---------|----------|
- `AUDIT_LEVEL` | `0` - Disable audit log (default setting). `1` - Log event metadata. `2` - Log event metadata and request body.`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.
See [Audit Level Logging](#audit-level-logging) for a table that displays what each setting logs. |
+ `AUDIT_LEVEL` | `0` - Disable audit log (default setting). `1` - Log event metadata. `2` - Log event metadata and request body.`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.
See [Audit Level Logging](#audit-log-levels) for a table that displays what each setting logs. |
`AUDIT_LOG_PATH` | Log path for Rancher Server API. Default path is `/var/log/auditlog/rancher-api-audit.log`. You can mount the log directory to host.
Usage Example: `AUDIT_LOG_PATH=/my/custom/path/` |
`AUDIT_LOG_MAXAGE` | Defined the maximum number of days to retain old audit log files. Default is 10 days. |
`AUDIT_LOG_MAXBACKUP` | Defines the maximum number of audit log files to retain. Default is 10.
@@ -594,4 +596,4 @@ The code sample below depicts an API response, with both its metadata header and
}
}
}
-```
\ No newline at end of file
+```
diff --git a/content/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/_index.md b/content/rancher/v2.x/en/installation/options/custom-ca-root-certificate/_index.md
similarity index 52%
rename from content/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/_index.md
rename to content/rancher/v2.x/en/installation/options/custom-ca-root-certificate/_index.md
index e56364d1691..b4eb5525056 100644
--- a/content/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/_index.md
+++ b/content/rancher/v2.x/en/installation/options/custom-ca-root-certificate/_index.md
@@ -1,8 +1,9 @@
---
title: Custom CA root certificate
-weight: 252
+weight: 1110
aliases:
- /rancher/v2.x/en/installation/custom-ca-root-certificate/
+ - /rancher/v2.x/en/admin-settings/custom-ca-root-certificate/
---
If you're using Rancher in an internal production environment where you aren't exposing apps publicly, use a certificate from a private certificate authority (CA).
@@ -16,19 +17,10 @@ Examples of services that Rancher can access:
* Authentication providers
* Accessing hosting/cloud API when using Node Drivers
-Use the command example to start a Rancher container with your private CA certificates mounted.
+## Installing with the custom CA Certificate
-- The volume option (`-v`) should specify the host directory containing the CA root certificates.
-- The `e` flag in combination with `SSL_CERT_DIR` declares an environment variable that specifies 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 Audit Log is enabled and configured by passing environment variables to the Rancher server container. See the following to enable on your installation.
-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.
+- [Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/#custom-ca-certificate)
-```
-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
-```
+- [HA Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#additional-trusted-cas)
diff --git a/content/rancher/v2.x/en/installation/options/tls-settings/_index.md b/content/rancher/v2.x/en/installation/options/tls-settings/_index.md
new file mode 100644
index 00000000000..589af788f27
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/options/tls-settings/_index.md
@@ -0,0 +1,36 @@
+---
+title: TLS settings
+weight: 11000
+aliases:
+ - /rancher/v2.x/en/admin-settings/tls-settings/
+---
+
+_Available as of v2.1.7_
+
+In Rancher v2.1.7, the default TLS configuration changed to only accept TLS 1.2 and secure TLS cipher suites. TLS 1.3 and TLS 1.3 exclusive cipher suites are not supported.
+
+## Configuring TLS settings
+
+The Audit Log is enabled and configured by passing environment variables to the Rancher server container. See the following to enable on your installation.
+
+- [Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/#tls-settings)
+
+- [HA Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#tls-settings)
+
+## TLS settings
+
+| Parameter | Description | Default | Available options |
+|-----|-----|-----|-----|
+| `CATTLE_TLS_MIN_VERSION` | Minimum TLS version | `1.2` | `1.0`, `1.1`, `1.2` |
+| `CATTLE_TLS_CIPHERS` | Allowed TLS cipher suites | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,` `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,` `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,` `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | See [Golang tls constants](https://golang.org/pkg/crypto/tls/#pkg-constants) |
+
+
+## Legacy configuration
+
+If you need to configure TLS the same way as it was before Rancher v2.1.7, please use the following settings:
+
+
+| Parameter | Legacy value |
+|-----|-----|
+| `CATTLE_TLS_MIN_VERSION` | `1.0` |
+| `CATTLE_TLS_CIPHERS` | `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,` `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,` `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,` `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,` `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,` `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,` `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,` `TLS_RSA_WITH_AES_128_GCM_SHA256,` `TLS_RSA_WITH_AES_256_GCM_SHA384,` `TLS_RSA_WITH_AES_128_CBC_SHA,` `TLS_RSA_WITH_AES_256_CBC_SHA,` `TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,` `TLS_RSA_WITH_3DES_EDE_CBC_SHA`
diff --git a/content/rancher/v2.x/en/installation/references/_index.md b/content/rancher/v2.x/en/installation/references/_index.md
index 1b90dc6694b..f84bb00b71c 100644
--- a/content/rancher/v2.x/en/installation/references/_index.md
+++ b/content/rancher/v2.x/en/installation/references/_index.md
@@ -17,7 +17,7 @@ The following table lists the ports that need to be open to and from nodes that
The ports required to be open for cluster nodes changes depending on how the cluster was launched. Each of the tabs below list the ports that need to be opened for different [cluster creation options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#cluster-creation-options).
->**Tip:**
+>**Tip:**
>
>If security isn't a large concern and you're okay with opening a few additional ports, you can use the table in [Commonly Used Ports](#commonly-used-ports) as your port reference instead of the comprehensive tables below.
@@ -44,7 +44,7 @@ The following table depicts the port requirements for [Rancher Launched Kubernet
{{% tab "Hosted Clusters" %}}
-The following table depicts the port requirements for [hosted clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters).
+The following table depicts the port requirements for [hosted clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters).
{{< ports-imported-hosted >}}
@@ -75,6 +75,8 @@ These ports are typically opened on your Kubernetes nodes, regardless of what ty
| TCP | 2380 | etcd peer communication |
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
+| TCP | 6783 | Weave Port |
+| UDP | 6783-6784 | Weave UDP Ports |
| TCP | 10250 | kubelet API |
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
| TCP/UDP | 30000-32767 | NodePort port range |
@@ -84,13 +86,13 @@ These ports are typically opened on your Kubernetes nodes, regardless of what ty
### Local Node Traffic
Ports marked as `local traffic` (i.e., `9099 TCP`) in the above requirements are used for Kubernetes healthchecks (`livenessProbe` and`readinessProbe`).
-These healthchecks are executed on the node itself. In most cloud environments, this local traffic is allowed by default.
+These healthchecks are executed on the node itself. In most cloud environments, this local traffic is allowed by default.
However, this traffic may be blocked when:
- You have applied strict host firewall policies on the node.
- You are using nodes that have multiple interfaces (multihomed).
-
+
In these cases, you have to explicitly allow this traffic in your host firewall, or in case of public/private cloud hosted machines (i.e. AWS or OpenStack), in your security group configuration. Keep in mind that when using a security group as source or destination in your security group, explicitly opening ports only applies to the private interface of the nodes / instances.
### Rancher AWS EC2 security group
diff --git a/content/rancher/v2.x/en/installation/requirements/_index.md b/content/rancher/v2.x/en/installation/requirements/_index.md
index c7be7a3b0ea..0a79919978e 100644
--- a/content/rancher/v2.x/en/installation/requirements/_index.md
+++ b/content/rancher/v2.x/en/installation/requirements/_index.md
@@ -8,67 +8,70 @@ Whether you're configuring Rancher to run in a single-node or high-availability
{{% tabs %}}
{{% tab "Operating Systems and Docker" %}}
-Rancher is supported on the following operating systems and their subsequent non-major releases with a supported version of [Docker](https://www.docker.com/).
-
+
+Rancher is tested on the following operating systems and their subsequent non-major releases with a supported version of [Docker](https://www.docker.com/).
* Ubuntu 16.04 (64-bit)
- * Docker 17.03.2, 18.06.2, 18.09.2
-* Red Hat Enterprise Linux (RHEL)/CentOS 7.5 (64-bit)
+ * Docker 17.03.x, 18.06.x, 18.09.x
+* Ubuntu 18.04 (64-bit)
+ * Docker 18.06.x, 18.09.x
+* Red Hat Enterprise Linux (RHEL)/CentOS 7.6 (64-bit)
* RHEL Docker 1.13
- * Docker 17.03.2, 18.06.2, 18.09.2
+ * Docker 17.03.x, 18.06.x, 18.09.x
* RancherOS 1.5.1 (64-bit)
- * Docker 17.03.2, 18.06.2, 18.09.2
+ * Docker 17.03.x, 18.06.x, 18.09.x
* Windows Server version 1803 (64-bit)
* Docker 17.06
+ * _Experimental, see [Configuring Custom Clusters for Windows]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/)_
If you are using RancherOS, make sure you switch the Docker engine to a supported version using:
-`sudo ros engine switch docker-17.03.2-ce`
+```
+# Look up available versions
+sudo ros engine list
+
+# Switch to a supported version
+sudo ros engine switch docker-18.09.2
+```
[Docker Documentation: Installation Instructions](https://docs.docker.com/)
-
+
+
{{% /tab %}}
{{% tab "Hardware" %}}
+
Hardware requirements scale based on the size of your Rancher deployment. Provision each individual node according to the requirements.
-
+
+**[HA Node]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/) Requirements**
+
+Deployment Size | Clusters | Nodes | vCPUs | RAM |
+--- | --- | --- | --- | --- |
+Small | Up to 5 | Up to 50 | 2 | 8 GB |
+Medium | Up to 15 | Up to 200 | 4 | 16 GB |
+Large | Up to 50 | Up to 500 | 8 | 32 GB |
+X-Large | Up to 100 | Up to 1000 | 32 | 128 GB |
+XX-Large | 100+ | 1000+ | [Contact Rancher](https://rancher.com/contact/) | [Contact Rancher](https://rancher.com/contact/) |
+
+
+
+**[Single Node]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/) Requirements**
+
+Deployment Size | Clusters | Nodes | vCPUs | RAM |
+--- | --- | --- | --- | --- |
+Small | Up to 5 | Up to 50 | 1 | 4 GB |
+Medium | Up to 15 | Up to 200 | 2 | 8 GB |
+
{{% /tab %}}
{{% tab "Networking" %}}
+
-
Node IP address
+### Node IP Address
Each node used (either for the Single Node Install, High Availability (HA) Install or nodes that are used in clusters) should have a static IP configured. In case of DHCP, the nodes should have a DHCP reservation to make sure the node gets the same IP allocated.
-
Port requirements
+### Port Requirements
When deploying Rancher in an HA cluster, certain ports on your nodes must be open to allow communication with Rancher. The ports that must be open change according to the type of machines hosting your cluster nodes. For example, if your are deploying Rancher on nodes hosted by an infrastructure, port `22` must be open for SSH. The following diagram depicts the ports that are opened for each [cluster type]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning).
@@ -76,7 +79,6 @@ When deploying Rancher in an HA cluster, certain ports on your nodes must be ope
-
{{< requirements_ports_rancher >}}
{{< requirements_ports_rke >}}
{{< ports_aws_securitygroup_nodedriver >}}
diff --git a/content/rancher/v2.x/en/installation/server-tags/_index.md b/content/rancher/v2.x/en/installation/server-tags/_index.md
index 785e95f2861..2b5a412831a 100644
--- a/content/rancher/v2.x/en/installation/server-tags/_index.md
+++ b/content/rancher/v2.x/en/installation/server-tags/_index.md
@@ -1,5 +1,5 @@
---
-title: Choosing a Version of Rancher
+title: Choosing a Version
weight: 230
---
@@ -20,7 +20,7 @@ Tag | Description
->**Notes:**
+>**Notes:**
>
>- The `master` tag or any tag with `-rc` or another suffix is meant for the Rancher testing team to validate. You should not use these tags, as these builds are not officially supported.
>- Want to install an alpha review for preview? Install using one of the alpha tags listed on our [announcements page](https://forums.rancher.com/c/announcements) (e.g., `v2.2.0-alpha1`).
@@ -49,16 +49,9 @@ Instructions on when to select these repos are available below in [Switching to
### Helm Chart Versions
-Up until the initial release of the Helm chart for Rancher v2.1.0, the version of the Helm chart matched the Rancher version (i.e `appVersion`).
+Rancher Helm chart versions match the Rancher version (i.e `appVersion`).
-Since there are times where the Helm chart will require changes without any changes to the Rancher version, we have moved to a versioning scheme using `yyyy.mm.` for the Helm charts.
-
-Run `helm search rancher` to view which Rancher version will be launched for the your Helm chart.
-
-```
-NAME CHART VERSION APP VERSION DESCRIPTION
-rancher-latest/rancher 2018.10.1 v2.1.0 Install Rancher Server to manage Kubernetes clusters acro...
-```
+For the Rancher v2.1.x versions, there were some Helm charts, that were using a version that was a build number, i.e. `yyyy.mm.`. These charts have been replaced with the equivalent Rancher version and are no longer available.
### Switching to a Different Helm Chart Repository
diff --git a/content/rancher/v2.x/en/installation/single-node/_index.md b/content/rancher/v2.x/en/installation/single-node/_index.md
index 62ed302c57e..da42b4201b9 100644
--- a/content/rancher/v2.x/en/installation/single-node/_index.md
+++ b/content/rancher/v2.x/en/installation/single-node/_index.md
@@ -22,7 +22,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
>- Use a proxy? See [HTTP Proxy Configuration]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/proxy/)
>- Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/)
>- Complete an Air Gap Installation? See [Air Gap: Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/)
->- Record all transactions with the Rancher API? See [API Auditing](#api-auditing)
+>- Record all transactions with the Rancher API? See [API Auditing](#api-audit-log)
>
Choose from the following options:
@@ -114,13 +114,32 @@ After you fulfill the prerequisites, you can install Rancher using a Let's Encry
-## FAQ and Troubleshooting
-
-{{< ssl_faq_single >}}
-
## Advanced Options
-### Enable API Audit Log
+When installing Rancher, there are several [advanced options]({{< baseurl >}}/rancher/v2.x/en/installation/options/) that can be enabled.
+
+### Custom CA Certificate
+
+If you want to configure Rancher to use a CA root certificate to be used when validating services, you would start the Rancher container sharing the directory that contains the CA root certificate.
+
+Use the command example to start a Rancher container with your private CA certificates mounted.
+
+- The volume option (`-v`) should specify the host directory containing the CA root certificates.
+- The `e` flag in combination with `SSL_CERT_DIR` declares an environment variable that specifies 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
+```
+
+### API Audit Log
The API Audit Log records all the user and system transactions made through Rancher server.
@@ -136,6 +155,20 @@ docker run -d --restart=unless-stopped \
rancher/rancher:latest
```
+### TLS settings
+
+_Available as of v2.1.7_
+
+To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` and `CATTLE_TLS_CIPHERS` environment variables. For example, to configure TLS 1.0 as minimum accepted TLS version:
+
+```
+docker run -d --restart=unless-stopped \
+ -p 80:80 -p 443:443 \
+ -e CATTLE_TLS_MIN_VERSION="1.0" \
+ rancher/rancher:latest
+```
+
+See [TLS settings]({{< baseurl >}}/rancher/v2.x/en/admin-settings/tls-settings) for more information and options.
### Air Gap
@@ -164,3 +197,7 @@ docker run -d --restart=unless-stopped \
-p 8080:80 -p 8443:443 \
rancher/rancher:latest
```
+
+## FAQ and Troubleshooting
+
+{{< ssl_faq_single >}}
diff --git a/content/rancher/v2.x/en/installation/single-node/single-node-install-external-lb/_index.md b/content/rancher/v2.x/en/installation/single-node/single-node-install-external-lb/_index.md
index af469c22940..93623d655b1 100644
--- a/content/rancher/v2.x/en/installation/single-node/single-node-install-external-lb/_index.md
+++ b/content/rancher/v2.x/en/installation/single-node/single-node-install-external-lb/_index.md
@@ -53,7 +53,7 @@ If you elect to use a self-signed certificate to encrypt communication, you must
-v /etc/your_certificate_directory/cacerts.pem:/etc/rancher/ssl/cacerts.pem \
rancher/rancher:latest
```
-
+
{{% /accordion %}}
{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Signed by Recognized CA" %}}
If your cluster is public facing, it's best to use a certificate signed by a recognized CA.
@@ -72,7 +72,7 @@ If you use a certificate signed by a recognized CA, installing your certificate
docker run -d --restart=unless-stopped \
-p 80:80 -p 443:443 \
rancher/rancher:latest --no-cacerts
- ```
+ ```
{{% /accordion %}}
## 3. Configure Load Balancer
@@ -181,7 +181,86 @@ If you want to record all transactions with the Rancher API, enable the [API Aud
If you are visiting this page to complete an [Air Gap Installation]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/), you must pre-pend your private registry URL to the server tag when running the installation command in the option that you choose. Add `` with your private registry URL in front of `rancher/rancher:latest`.
**Example:**
-
+
+ /rancher/rancher:latest
+
+### Persistent Data
+
+{{< persistentdata >}}
+
+This layer 7 Nginx configuration is tested on Nginx version 1.13 (mainline) and 1.14 (stable).
+
+ >**Note:** This Nginx configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/).
+
+```
+upstream rancher {
+ server rancher-server:80;
+}
+
+map $http_upgrade $connection_upgrade {
+ default Upgrade;
+ '' close;
+}
+
+server {
+ listen 443 ssl http2;
+ server_name rancher.yourdomain.com;
+ ssl_certificate /etc/your_certificate_directory/fullchain.pem;
+ ssl_certificate_key /etc/your_certificate_directory/privkey.pem;
+
+ location / {
+ proxy_set_header Host $host;
+ proxy_set_header X-Forwarded-Proto $scheme;
+ proxy_set_header X-Forwarded-Port $server_port;
+ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+ proxy_pass http://rancher;
+ proxy_http_version 1.1;
+ proxy_set_header Upgrade $http_upgrade;
+ proxy_set_header Connection $connection_upgrade;
+ # This allows the ability for the execute shell window to remain open for up to 15 minutes. Without this parameter, the default is 1 minute and will automatically close.
+ proxy_read_timeout 900s;
+ proxy_buffering off;
+ }
+}
+
+server {
+ listen 80;
+ server_name rancher.yourdomain.com;
+ return 301 https://$server_name$request_uri;
+}
+```
+
+
+
+## What's Next?
+
+- **Recommended:** Review [Single Node Backup and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/single-node-backup-and-restoration/). Although you don't have any data you need to back up right now, we recommend creating backups after regular Rancher use.
+- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).
+
+
+
+## FAQ and Troubleshooting
+
+{{< ssl_faq_single >}}
+
+## Advanced Options
+
+### API Auditing
+
+If you want to record all transactions with the Rancher API, enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by adding the flags below into your install command.
+
+ -e AUDIT_LEVEL=1 \
+ -e AUDIT_LOG_PATH=/var/log/auditlog/rancher-api-audit.log \
+ -e AUDIT_LOG_MAXAGE=20 \
+ -e AUDIT_LOG_MAXBACKUP=20 \
+ -e AUDIT_LOG_MAXSIZE=100 \
+
+### Air Gap
+
+If you are visiting this page to complete an [Air Gap Installation]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/), you must pre-pend your private registry URL to the server tag when running the installation command in the option that you choose. Add `` with your private registry URL in front of `rancher/rancher:latest`.
+
+**Example:**
+
/rancher/rancher:latest
### Persistent Data
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/_index.md
index 6a7b31e6dbd..1d79b6056fe 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/_index.md
@@ -1,5 +1,5 @@
---
-title: Kubernetes in Rancher
+title: Working in Projects
weight: 3000
aliases:
- /rancher/v2.x/en/concepts/
@@ -7,72 +7,7 @@ aliases:
- /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/)
+When your project is set up, [project members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can start managing their applications and all the components that comprise it.
## Workloads
@@ -109,27 +44,27 @@ Ingress is a set or rules that act as a load balancer. Ingress works in conjunct
For more information, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress).
+When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.
+
+For more information, see [Global DNS]({{< baseurl >}}/rancher/v2.x/en/catalog/globaldns/).
+
## 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 labelled pods to a specific hostname.
For more information, see [Service Discovery]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/service-discovery).
-## Volumes and Storage
+## Pipelines
-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.
+After your project has been [configured to a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), you can add the repositories and start configuring a pipeline for each repository.
-Within Rancher, you can create persistent storage using one of two methods:
+For more information, see [Pipelines]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/).
-- [Persistent Volumes]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#persistent-volumes)
+## Applications
- Persistent volumes are pre-provisioned storage volumes that you can bind to pods later using persistent volume claims.
+Besides launching individual components of an application, you can use the Rancher catalog to start launching applications, which are Helm charts.
-- [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.
+For more information, see [Applications in a Project]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/).
## Kubernetes Resources
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md
index 67bde0843af..4831c0d9b86 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md
@@ -12,7 +12,7 @@ ConfigMaps accept key value pairs in common string formats, like config files or
>**Note:** ConfigMaps are only available within [namespaces]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) and not [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects).
({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces)
-ConfigMaps store general configuration information for an application, such as configuration files, command-line arguments, environment variables, etc. ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. Add ConfigMaps to your Rancher workspaces so that you can add them to your workloads later. For more information on ConfigMaps, see the official [Kubernetes Documentation: Using ConfigMap](https://kubernetes-v1-4.github.io/docs/user-guide/configmap/).
+ConfigMaps store general configuration information for an application, such as configuration files, command-line arguments, environment variables, etc. ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. Add ConfigMaps to your Rancher workspaces so that you can add them to your workloads later.
>**Note:** ConfigMaps can only be applied to namespaces and not projects.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/_index.md
index 8b6bd0d4c78..422bf82e033 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/_index.md
@@ -1,6 +1,6 @@
---
title: Horizontal Pod Autoscaler
-weight: 2300
+weight: 3026
---
Using the Kubernetes [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) feature (HPA), you can configure your cluster to automatically scale the services it's running up or down.
@@ -91,7 +91,7 @@ spec:
Directive | Description
---------|----------|
- `apiVersion: autoscaling/v2beta1` | The version of the Kubernetes `autoscaling` API group in use. This example manifest uses the beta version, so scaling by CPU and memory is enabled. |
+ `apiVersion: autoscaling/v2beta1` | The version of the Kubernetes `autoscaling` API group in use. This example manifest uses the beta version, so scaling by CPU and memory is enabled. |
`name: hello-world` | Indicates that HPA is performing autoscaling for the `hello-word` deployment. |
`minReplicas: 1` | Indicates that the minimum number of replicas running can't go below 1. |
`maxReplicas: 10` | Indicates the maximum number of replicas in the deployment can't go above 10.
@@ -165,7 +165,7 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
```
1. Check that `prometheus-adapter` is running properly. Check the service pod and logs in the `kube-system` namespace.
-
+
1. Check that the service pod is `Running`. Enter the following command.
```
# kubectl get pods -n kube-system
@@ -196,8 +196,8 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
I0724 10:18:51.727845 1 request.go:836] Request Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"nonResourceAttributes":{"path":"/","verb":"get"},"user":"system:anonymous","group":["system:unauthenticated"]},"status":{"allowed":false}}
...
{{% /accordion %}}
-
-
+
+
1. Check that the metrics API is accessible from kubectl.
@@ -209,16 +209,16 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
{{% accordion id="custom-metrics-api-response" label="API Response" %}}
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
{{% /accordion %}}
-
+
- If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https:///k8s/clusters/`. Add the suffix `/k8s/clusters/` to API path.
```
# kubectl get --raw /k8s/clusters//apis/custom.metrics.k8s.io/v1beta1
```
If the API is accessible, you should receive output that's similar to what follows.
{{% accordion id="custom-metrics-api-response-rancher" label="API Response" %}}
- {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
+ {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
{{% /accordion %}}
-
+
### Testing HPAs with a Service Deployment
@@ -279,7 +279,7 @@ spec:
app: hello-world
```
{{% /accordion %}}
-
+
1. Deploy it to your cluster.
```
@@ -341,7 +341,7 @@ spec:
targetAverageValue: 20m
```
{{% /accordion %}}
-
+
1. View the HPA info and description. Confirm that metric data is shown.
{{% accordion id="hpa-info-resource-metrics" label="Resource Metrics" %}}
1. Enter the following commands.
@@ -399,14 +399,14 @@ spec:
```
{{% /accordion %}}
-
+
1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
1. Test that pod autoscaling works as intended.
**To Test Autoscaling Using Resource Metrics:**
{{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to to scale up to two pods based on CPU Usage.
-
+
1. View your HPA.
```
# kubectl describe hpa
@@ -613,7 +613,7 @@ Use your load testing tool to scale up to three pods when the cpu_system usage l
hello-world-54764dfbf8-5pfdr 1/1 Running 0 3m
hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
- ```
+ ```
{{% /accordion %}}
{{% accordion id="observe-upscale-4-pods" label="Upscale to 4 Pods: CPU Usage Up to Target" %}}
Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
@@ -869,7 +869,7 @@ To do it, follow these steps:
name: system:anonymous
{{% /accordion %}}
{{% accordion id="cluster-role-custom-resources" label="Custom Metrics: ApiGroups custom.metrics.k8s.io" %}}
-
+
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
@@ -904,4 +904,3 @@ To do it, follow these steps:
# kubectl create -f
# kubectl create -f
```
-
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/kubeconfig/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/kubeconfig/_index.md
deleted file mode 100644
index 98bd87d241e..00000000000
--- a/content/rancher/v2.x/en/k8s-in-rancher/kubeconfig/_index.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Kubeconfig Files
-weight: 3010
-aliases:
- - /rancher/v2.x/en/concepts/clusters/kubeconfig-files/
----
-
-A _kubeconfig file_ is a file used to configure access to Kubernetes when used in conjunction with the kubectl commandline tool (or other clients).
-
-For more details on how kubeconfig and kubectl work together, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
-
-When you create a cluster using the Rancher GUI, Rancher automatically creates a kubeconfig for your cluster.
-
-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//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:
->```
-kubectl --kubeconfig /custom/path/kube.config get pods
-```
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md
index d7daae72068..08a4077a03e 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md
@@ -47,3 +47,4 @@ Ingress can provide other functionality as well, such as SSL termination, name-b
- 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/)
+- When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry, see [Global DNS]({{< baseurl >}}/rancher/v2.x/en/catalog/globaldns/).
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md
index b7f03267f10..efa6b5d13f1 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md
@@ -5,7 +5,7 @@ aliases:
- /rancher/v2.x/en/tasks/workloads/add-ingress/
---
-Ingress can be added for workloads to provide load balancing, SSL termination and host/path based routing.
+Ingress can be added for workloads to provide load balancing, SSL termination and host/path based routing. When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry]({{< baseurl >}}/rancher/v2.x/en/catalog/globaldns/).
1. From the **Global** view, open the project that you want to add ingress to.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md
new file mode 100644
index 00000000000..1adea803734
--- /dev/null
+++ b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md
@@ -0,0 +1,746 @@
+---
+title: Pipelines
+weight: 3047
+aliases:
+ - /rancher/v2.x/en/tools/pipelines/concepts/
+
+---
+
+>**Notes:**
+>
+>- Pipelines are new and improved for Rancher v2.1! Therefore, if you configured pipelines while using v2.0.x, you'll have to reconfigure them after upgrading to v2.1.
+>- Still using v2.0.x? See the pipeline documentation for [previous versions]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x).
+
+Before setting up any pipelines, review the [pipeline overview]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/) and ensure that the project has [configured authentication to your version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), e.g. GitHub, GitLab, Bitucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/) to view some common pipeline deployments.
+
+If you can access a project, you can enable repositories to start building pipelines. Only an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can authorize version control providers.
+
+## Concepts
+
+When setting up a pipeline, it's helpful to know a few related terms.
+
+- **Pipeline:**
+
+ A pipeline consists of stages and steps. It is based on a specific repository. It defines the process to build, test, and deploy your code. Rancher uses the [pipeline as code](https://jenkins.io/doc/book/pipeline-as-code/) model. Pipeline configuration is represented as a pipeline file in the source code repository, using the file name `.rancher-pipeline.yml` or `.rancher-pipeline.yaml`.
+
+- **Stages:**
+
+ A pipeline stage consists of multiple steps. Stages are executed in the order defined in the pipeline file. The steps in a stage are executed concurrently. A stage starts when all steps in the former stage finish without failure.
+
+- **Steps:**
+
+ A pipeline step is executed inside a specified stage. A step fails if it exits with a code other than `0`. If a step exits with this failure code, the entire pipeline fails and terminates.
+
+- **Workspace:**
+
+ The workspace is the working directory shared by all pipeline steps. In the beginning of a pipeline, source code is checked out to the workspace. The command for every step bootstraps in the workspace. During a pipeline execution, the artifacts from a previous step will be available in future steps. The working directory is an ephemeral volume and will be cleaned out with the executor pod when a pipeline execution is finished.
+
+## Configuring Repositories
+
+After the version control provider is authorized, you are automatically re-directed to start configuring which repositories that you want start using pipelines with. Even if someone else has set up the version control provider, you will see their repositories and can build a pipeline.
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab.
+
+1. Click on **Configure Repositories**.
+
+1. A list of repositories are displayed. If you are configuring repositories the first time, click on **Authorize & Fetch Your Own Repositories** to fetch your repository list.
+
+1. For each repository that you want to set up a pipeline, click on **Enable**.
+
+1. When you're done enabling all your repositories, click on **Done**.
+
+**Results:** You have a list of repositories that you can start configuring pipelines for.
+
+## Pipeline Configuration
+
+Now that repositories are added to your project, you can start configuring the pipeline by adding automated stages and steps. For your convenience, there are multiple built-in [step types](#step-types) for dedicated tasks.
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab.
+
+1. Find the repository that you want to set up a pipeline for. Pipelines can be configured either through the UI or using a yaml file in the repository, i.e. `.rancher-pipeline.yml` or `.rancher-pipeline.yaml`. Throughout the next couple of steps, we'll provide the options of how to do pipeline configuration through the UI or the YAML file.
+
+ * If you are going to use the UI, select the vertical **Ellipsis (...) > Edit Config** to configure the pipeline using the UI. After the pipeline is configured, you must view the YAML file and push it to the repository.
+ * If you are going to use the YAML file, select the vertical **Ellipsis (...) **View/Edit YAML** to configure the pipeline. If you choose to use a YAML file, you need to push it to the repository after any changes in order for it to be updated in the repository.
+
+ >**Note:** When editing the pipeline configuration, it takes a few moments for Rancher to check for an existing pipeline configuration.
+
+1. Select which `branch` to use from the list of branches.
+
+1. Pipeline configuration is split into stages and [steps](#step-types). Remember that stages must fully complete before moving onto the next stage, but steps in a stage run concurrently.
+
+ For each stage, you can add different step types. Learn more about how to configure each step type:
+
+ - [Run Script](#run-script)
+ - [Build and Publish Images](#build-and-publish-images)
+ - [Publish Catalog Template](#publish-catalog-template)
+ - [Deploy YAML](#deploy-yaml)
+ - [Deploy Catalog App](#deploy-catalog-app)
+
+ >**Note:** As you build out each step, there are different [advanced options](#advanced-options) based on the step type.
+
+ {{% accordion id="stages-and-steps" label="Adding Stages and Steps" %}}
+{{% tabs %}}
+{{% tab "By UI" %}}
+
+If you haven't added any stages, click **Configure pipeline for this branch** to configure the pipeline through the UI.
+
+1. Add stages to your pipeline execution by clicking **Add Stage**.
+
+ 1. Enter a **Name** for each stage of your pipeline.
+ 1. For each stage, you can configure [trigger rules](#trigger-rules) by clicking on **Show Advanced Options**. Note: this can always be updated at a later time.
+
+1. After you've created a stage, start [adding steps](#step-types) by clicking **Add a Step**. You can add multiple steps to each stage.
+
+
+{{% /tab %}}
+{{% tab "By YAML" %}}
+
+For each stage, you can add multiple steps. Read more about each [step type](#step-types) and the [advanced options](#advanced-options) to get all thhe details on how to configure the YAML. This is only a small example of how to have multiple stages with a singular step in each stage.
+
+```yaml
+# example
+stages:
+ - name: Build something
+ # Conditions for stages
+ when:
+ branch: master
+ event: [ push, pull_request ]
+ # Multiple steps run concurrently
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: date -R
+ - name: Publish my image
+ steps:
+ - publishImageConfig:
+ dockerfilePath: ./Dockerfile
+ buildContext: .
+ tag: rancher/rancher:v2.0.0
+ # Optionally push to remote registry
+ pushRemote: true
+ registry: reg.example.com
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+ {{% /accordion %}}
+
+1. _Available as of v2.2.0_
+
+ **Notifications:** Decide if you want to set up notifications for your pipeline. You can enable notifications to any [notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/) based on the build status of a pipeline. Before enabling notifications, Rancher recommends [setting up notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers) so it will be easy to add recipients immediately.
+
+ {{% accordion id="notification" label="Configuring Notifications" %}}
+
+
+{{% tabs %}}
+{{% tab "By UI" %}}
+
+_Available as of v2.2.0_
+
+1. Within the **Notification** section, turn on notifications by clicking **Enable**.
+
+1. Select the conditions for the notification. You can select to get a notification for the following statuses: `Failed`, `Success`, `Changed`. For example, if you want to receive notifications when an execution fails, select **Failed**.
+
+1. If you don't have any existing [notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers), Rancher will provide a warning that no notifers are set up and provide a link to be able to go to the notifiers page. Follow the [instructions]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers) to add a notifier. If you already have notifiers, you can add them to the notification by clicking the **Add Recipient** button.
+
+ > **Note:** Notifiers are configured at a cluster level and require a different level of permissions.
+
+1. For each recipient, select which notifier type from the dropdown. Based on the type of notifier, you can use the default recipient or override the recipient with a different one. For example, if you have a notifier for _Slack_, you can update which channel to send the notification to. You can add additional notifiers by clicking **Add Recipient**.
+
+
+{{% /tab %}}
+{{% tab "By YAML" %}}
+
+_Available as of v2.2.0_
+
+In the `notification` section, you will provide the following information:
+
+* **Recipients:** This will be the list of notifiers/recipients that will receive the notification.
+ * **Notifier:** The ID of the notifier. This can be found by finding the notifier and selecting **View in API** to get the ID.
+ * **Recipient:** Depending on the type of the notifier, the "default recipient" can be used or you can override this with a different recipient. For example, when configuring a slack notifier, you select a channel as your default recipient, but if you wanted to send notifications to a different channel, you can select a different recipient.
+* **Condition:** Select which conditions of when you want the notification to be sent.
+* **Message (Optional):** If you want to change the default notification message, you can edit this in the yaml. Note: This option is not available in the UI.
+
+```yaml
+# Example
+stages:
+ - name: Build something
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: ls
+notification:
+ recipients:
+ - # Recipient
+ recipient: "#mychannel"
+ # ID of Notifier
+ notifier: "c-wdcsr:n-c9pg7"
+ - recipient: "test@example.com"
+ notifier: "c-wdcsr:n-lkrhd"
+ # Select which statuses you want the notification to be sent
+ condition: ["Failed", "Success", "Changed"]
+ # Ability to override the default message (Optional)
+ message: "my-message"
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+ {{% /accordion %}}
+
+1. Set up the **[Trigger Rules](#trigger-rules)** for the pipeline.
+
+1. Enter a **Timeout** for the pipeline. By default, each pipeline execution has a timeout of 60 minutes. If the pipeline execution cannot complete within its timeout period, the pipeline is aborted.
+
+ {{% accordion id="timeout" label="Setting up Timeout" %}}
+
+{{% tabs %}}
+{{% tab "By UI" %}}
+
+Enter a new value in the **Timeout** field.
+
+
+{{% /tab %}}
+{{% tab "By YAML" %}}
+
+In the `timeout` section, enter the timeout value in minutes.
+```yaml
+# example
+stages:
+ - name: Build something
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: ls
+# timeout in minutes
+timeout: 30
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+ {{% /accordion %}}
+
+1. When all the stages and steps are configured, click **Done**.
+
+**Results:** Your pipeline is now configured and ready to be run.
+
+## Running your Pipelines
+
+Run your pipeline for the first time. From the **Pipeline** tab, find your pipeline and select the vertical **Ellipsis (...) > Run**.
+
+During this initial run, your pipeline is tested, and the following [pipeline components]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#how-pipelines-work) are deployed to your project as workloads in a new namespace dedicated to the pipeline:
+
+- `docker-registry`
+- `jenkins`
+- `minio`
+
+This process takes several minutes. When it completes, you can view each pipeline component from the project **Workloads** tab.
+
+## Pipeline Setting
+
+When a repository is enabled, a webhook is automatically set in the version control provider. By default, the pipeline is triggered by a **push** event to a repository, but you can modify the event(s) that trigger running the pipeline.
+
+Available Events:
+
+* **Push**: Whenever a commit is pushed to the branch in the repository, the pipeline is triggered.
+* **Pull Request**: Whenever a pull request is made to the repository, the pipeline is triggered.
+* **Tag**: When a tag is created in the repository, the pipeline is triggered.
+
+> **Note:** This option doesn't exist for Rancher's [example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/).
+
+### Modifying the Event Triggers for the Repository
+
+1. From the **Global** view, navigate to the project that you want to modify the event trigger for the pipeline.
+
+1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab.
+
+1. Find the repository that you want to modify the event triggers. Select the vertical **Ellipsis (...) > Setting**.
+
+1. Select which event triggers (**Push**, **Pull Request** or **Tag**) you want for the repository.
+
+1. Click **Save**.
+
+## Step Types
+
+Within each stage, you can add as many steps as you'd like. When there are multiple steps in one stage, they run concurrently.
+
+- [Run Script](#run-script)
+- [Build and Publish Images](#build-and-publish-images)
+- [Publish Catalog Template](#publish-catalog-template)
+- [Deploy YAML](#deploy-yaml)
+- [Deploy Catalog App](#deploy-catalog-app)
+
+
+
+### Run Script
+
+The **Run Script** step executes arbitrary commands in the workspace inside a specified container. You can use it to build, test and do more, given whatever utilities the base image provides. For your convenience, you can use variables to refer to metadata of a pipeline execution. Please refer to the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) for the list of available variables.
+
+{{% tabs %}}
+
+{{% tab "By UI" %}}
+
+1. From the **Step Type** drop-down, choose **Run Script** and fill in the form.
+
+1. Click **Add**.
+
+{{% /tab %}}
+
+{{% tab "By YAML" %}}
+
+```yaml
+# example
+stages:
+- name: Build something
+ steps:
+ - runScriptConfig:
+ image: golang
+ shellScript: go build
+```
+
+{{% /tab %}}
+
+{{% /tabs %}}
+
+### Build and Publish Images
+
+The **Build and Publish Image** step builds and publishes a Docker image. This process requires a Dockerfile in your source code's repository to complete successfully.
+
+{{% tabs %}}
+
+{{% tab "By UI" %}}
+1. From the **Step Type** drop-down, choose **Build and Publish**.
+
+1. Fill in the rest of the form. Descriptions for each field are listed below. When you're done, click **Add**.
+
+ Field | Description |
+ ---------|----------|
+ Dockerfile Path | The relative path to the Dockerfile in the source code repo. By default, this path is `./Dockerfile`, which assumes the Dockerfile is in the root directory. You can set it to other paths in different use cases (`./path/to/myDockerfile` for example). |
+ Image Name | The image name in `name:tag` format. The registry address is not required. For example, to build `example.com/repo/my-image:dev`, enter `repo/my-image:dev`. |
+ Push image to remote repository | An option to set the registry that publishes the image that's built. To use this option, enable it and choose a registry from the drop-down. If this option is disabled, the image is pushed to the internal registry. |
+ Build Context
(**Show advanced options**)| By default, the root directory of the source code (`.`). For more details, see the Docker [build command documentation](https://docs.docker.com/engine/reference/commandline/build/).
+
+{{% /tab %}}
+
+{{% tab "By YAML" %}}
+
+```yaml
+# example
+stages:
+- name: Publish Image
+ steps:
+ - publishImageConfig:
+ dockerfilePath: ./Dockerfile
+ buildContext: .
+ tag: repo/app:v1
+ pushRemote: true
+ registry: example.com
+```
+
+You can use specific arguments for Docker daemon and the build. They are not exposed in the UI, but they are available in pipeline YAML format, as indicated in the example above. Available variables includes:
+
+Variable Name | Description
+------------------------|------------------------------------------------------------
+PLUGIN_DRY_RUN | Disable docker push
+PLUGIN_DEBUG | Docker daemon executes in debug mode
+PLUGIN_MIRROR | Docker daemon registry mirror
+PLUGIN_INSECURE | Docker daemon allows insecure registries
+PLUGIN_BUILD_ARGS | Docker build args, a comma separated list
+
+{{% /tab %}}
+
+{{% /tabs %}}
+
+### Publish Catalog Template
+
+_Available as of v2.2.0_
+
+The **Publish Catalog Template** step publishes a version of a catalog app template (i.e. Helm chart) to a [git hosted chart repository]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/). It generates a git commit and pushes it to your chart repository. This process requires a chart folder in your source code's repository and a pre-configured secret in the dedicated pipeline namespace to complete successfully. Any variables in the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) is supported for any file in the chart folder.
+
+{{% tabs %}}
+
+{{% tab "By UI" %}}
+
+
+1. From the **Step Type** drop-down, choose **Publish Catalog Template**.
+
+1. Fill in the rest of the form. Descriptions for each field are listed below. When you're done, click **Add**.
+
+ Field | Description |
+ ---------|----------|
+ Chart Folder | The relative path to the chart folder in the source code repo, where the `Chart.yaml` file is located. |
+ Catalog Template Name | The name of the template. For example, wordpress. |
+ Catalog Template Version | The version of the template you want to publish, it should be consistent with the version defined in the `Chart.yaml` file. |
+ Protocol | You can choose to publish via HTTP(S) or SSH protocol. |
+ Secret | The secret that stores your Git credentials. You need to create a secret in dedicated pipeline namespace in the project before adding this step. If you use HTTP(S) protocol, store Git username and password in `USERNAME` and `PASSWORD` key of the secret. If you use SSH protocol, store Git deploy key in `DEPLOY_KEY` key of the secret. After the secret is created, select it in this option. |
+ Git URL | The Git URL of the chart repository that the template will be published to. |
+ Git Branch | The Git branch of the chart repository that the template will be published to. |
+ Author Name | The author name used in the commit message. |
+ Author Email | The author email used in the commit message. |
+
+
+{{% /tab %}}
+
+{{% tab "By YAML" %}}
+
+You can add **Publish Catalog Template** steps directly in the `.rancher-pipeline.yml` file.
+
+Under the `steps` section, add a step with `publishCatalogConfig`. You will provide the following information:
+
+* Path: The relative path to the chart folder in the source code repo, where the `Chart.yaml` file is located.
+* CatalogTemplate: The name of the template.
+* Version: The version of the template you want to publish, it should be consistent with the version defined in the `Chart.yaml` file.
+* GitUrl: The git URL of the chart repository that the template will be published to.
+* GitBranch: The git branch of the chart repository that the template will be published to.
+* GitAuthor: The author name used in the commit message.
+* GitEmail: The author email used in the commit message.
+* Credentials: You should provide Git credentials by referencing secrets in dedicated pipeline namespace. If you publish via SSH protocol, inject your deploy key to the `DEPLOY_KEY` environment variable. If you publish via HTTP(S) protolcol, inject your username and password to `USERNAME` and `PASSWORD` environment variables.
+
+```yaml
+# example
+stages:
+- name: Publish Wordpress Template
+ steps:
+ - publishCatalogConfig:
+ path: ./charts/wordpress/latest
+ catalogTemplate: wordpress
+ version: ${CICD_GIT_TAG}
+ gitUrl: git@github.com:myrepo/charts.git
+ gitBranch: master
+ gitAuthor: example-user
+ gitEmail: user@example.com
+ envFrom:
+ - sourceName: publish-keys
+ sourceKey: DEPLOY_KEY
+```
+
+
+{{% /tab %}}
+
+{{% /tabs %}}
+
+### Deploy YAML
+
+This step deploys arbitrary Kubernetes resources to the project. This deployment requires a Kubernetes manifest file to be present in the source code repository. Pipeline variable substitution is supported in the manifest file. You can view an example file at [GitHub](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml). Please refer to the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) for the list of available variables.
+
+{{% tabs %}}
+
+{{% tab "By UI" %}}
+
+1. From the **Step Type** drop-down, choose **Deploy YAML** and fill in the form.
+
+1. Enter the **YAML Path**, which is the path to the manifest file in the source code.
+
+1. Click **Add**.
+
+{{% /tab %}}
+
+{{% tab "By YAML" %}}
+
+```yaml
+# example
+stages:
+- name: Deploy
+ steps:
+ - applyYamlConfig:
+ path: ./deployment.yaml
+```
+
+{{% /tab %}}
+
+{{% /tabs %}}
+
+### Deploy Catalog App
+
+_Available as of v2.2.0_
+
+The **Deploy Catalog App** step deploys a catalog app in the project. It will install a new app if it is not present, or upgrade an existing one.
+
+{{% tabs %}}
+
+{{% tab "By UI" %}}
+
+1. From the **Step Type** drop-down, choose **Deploy Catalog App**.
+
+1. Fill in the rest of the form. Descriptions for each field are listed below. When you're done, click **Add**.
+
+ Field | Description |
+ ---------|----------|
+ Catalog | The catalog from which the app template will be used. |
+ Template Name | The name of the app template. For example, wordpress. |
+ Template Version | The version of the app template you want to deploy. |
+ Namespace | The target namespace where you want to deploy the app. |
+ App Name | The name of the app you want to deploy. |
+ Answers | Key-value pairs of answers used to deploy the app. |
+
+
+{{% /tab %}}
+
+{{% tab "By YAML" %}}
+
+You can add **Deploy Catalog App** steps directly in the `.rancher-pipeline.yml` file.
+
+Under the `steps` section, add a step with `applyAppConfig`. You will provide the following information:
+
+* CatalogTemplate: The ID of the template. This can be found by clicking `Launch app` and selecting `View details` for the app. It is the last part of the URL.
+* Version: The version of the template you want to deploy.
+* Answers: Key-value pairs of answers used to deploy the app.
+* Name: The name of the app you want to deploy.
+* TargetNamespace: The target namespace where you want to deploy the app.
+
+```yaml
+# example
+stages:
+- name: Deploy App
+ steps:
+ - applyAppConfig:
+ catalogTemplate: cattle-global-data:library-mysql
+ version: 0.3.8
+ answers:
+ persistence.enabled: "false"
+ name: testmysql
+ targetNamespace: test
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+## Advanced Options
+
+Within a pipeline, there are multiple advanced options for different parts of the pipeline.
+
+- [Trigger Rules](#trigger-rules)
+- [Environment Variables](#environment-variables)
+- [Secrets](#secrets)
+
+### Trigger Rules
+
+Trigger rules can be created to have fine-grained control of pipeline executions in your pipeline configuration. Trigger rules come in two types:
+
+- **Run this when:**
+
+ This type of rule starts the pipeline, stage, or step when a trigger explicitly occurs.
+
+- **Do Not Run this when:**
+
+ This type of rule skips the pipeline, stage, or step when a trigger explicitly occurs.
+
+If all conditions evaluate to `true`, then the pipeline/stage/step is executed. Otherwise it is skipped. When a pipeline is skipped, none of the pipeline is executed. When a stage/step is skipped, it is considered successful and follow-up stages/steps continue to run.
+
+Wildcard character (`*`) expansion is supported in `branch` conditions.
+
+{{% tabs %}}
+{{% tab "Pipeline Trigger" %}}
+
+1. From the **Global** view, navigate to the project that you want to configure a pipeline trigger rule.
+
+1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab.
+
+1. From the repository for which you want to manage trigger rules, select the vertical **Ellipsis (...) > Edit Config**.
+
+1. Click on **Show Advanced Options**.
+
+1. In the **Trigger Rules** section, configure rules to run or skip the pipeline.
+
+ 1. Click **Add Rule**. In the **Value** field, enter the name of the branch that triggers the pipeline.
+
+ 1. **Optional:** Add more branches that trigger a build.
+
+1. Click **Done.**
+
+{{% /tab %}}
+{{% tab "Stage Trigger" %}}
+1. From the **Global** view, navigate to the project that you want to configure a stage trigger rule.
+
+1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab.
+
+1. From the repository for which you want to manage trigger rules, select the vertical **Ellipsis (...) > Edit Config**.
+
+1. Find the **stage** that you want to manage trigger rules, click the **Edit** icon for that stage.
+
+1. Click **Show advanced options**.
+
+1. In the **Trigger Rules** section, configure rules to run or skip the stage.
+
+ 1. Click **Add Rule**.
+
+ 1. Choose the **Type** that triggers the stage and enter a value.
+
+ | Type | Value |
+ | ------ | -------------------------------------------------------------------- |
+ | Branch | The name of the branch that triggers the stage. |
+ | Event | The type of event that triggers the stage. Values are: `Push`, `Pull Request`, `Tag` |
+
+1. Click **Save**.
+
+{{% /tab %}}
+{{% tab "Step Trigger" %}}
+1. From the **Global** view, navigate to the project that you want to configure a stage trigger rule.
+
+1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab.
+
+1. From the repository for which you want to manage trigger rules, select the vertical **Ellipsis (...) > Edit Config**.
+
+1. Find the **step** that you want to manage trigger rules, click the **Edit** icon for that step.
+
+1. Click **Show advanced options**.
+
+1. In the **Trigger Rules** section, configure rules to run or skip the step.
+
+ 1. Click **Add Rule**.
+
+ 1. Choose the **Type** that triggers the step and enter a value.
+
+ | Type | Value |
+ | ------ | -------------------------------------------------------------------- |
+ | Branch | The name of the branch that triggers the step. |
+ | Event | The type of event that triggers the step. Values are: `Push`, `Pull Request`, `Tag` |
+
+1. Click **Save**.
+
+{{% /tab %}}
+{{% tab "By YAML" %}}
+
+```yaml
+# example
+stages:
+ - name: Build something
+ # Conditions for stages
+ when:
+ branch: master
+ event: [ push, pull_request ]
+ # Multiple steps run concurrently
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: date -R
+ # Conditions for steps
+ when:
+ branch: [ master, dev ]
+ event: push
+# branch conditions for the pipeline
+branch:
+ include: [ master, feature/*]
+ exclude: [ dev ]
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+### Environment Variables
+
+When configuring a pipeline, certain [step types](#step-types) allow you to use environment variables to configure the step's script.
+
+{{% tabs %}}
+{{% tab "By UI" %}}
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab.
+
+1. From the pipeline for which you want to edit build triggers, select **Ellipsis (...) > Edit Config**.
+
+1. Within one of the stages, find the **step** that you want to add an environment variable for, click the **Edit** icon.
+
+1. Click **Show advanced options**.
+
+1. Click **Add Variable**, and then enter a key and value in the fields that appear. Add more variables if needed.
+
+1. Add your environment variable(s) into either the script or file.
+
+1. Click **Save**.
+
+{{% /tab %}}
+
+{{% tab "By YAML" %}}
+
+```yaml
+# example
+stages:
+ - name: Build something
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: echo ${FIRST_KEY} && echo ${SECOND_KEY}
+ env:
+ FIRST_KEY: VALUE
+ SECOND_KEY: VALUE2
+```
+
+{{% /tab %}}
+
+{{% /tabs %}}
+
+### Secrets
+
+If you need to use security-sensitive information in your pipeline scripts (like a password), you can pass them in using Kubernetes [secrets]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/secrets/).
+
+#### Prerequisite
+Create a secret in the same project as your pipeline, or explicitly in the namespace where pipeline build pods run.
+
+
+>**Note:** Secret injection is disabled on [pull request events](#pipeline-setting).
+
+{{% tabs %}}
+{{% tab "By UI" %}}
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab.
+
+1. From the pipeline for which you want to edit build triggers, select **Ellipsis (...) > Edit Config**.
+
+1. Within one of the stages, find the **step** that you want to use a secret for, click the **Edit** icon.
+
+1. Click **Show advanced options**.
+
+1. Click **Add From Secret**. Select the secret file that you want to use. Then choose a key. Optionally, you can enter an alias for the key.
+
+1. Click **Save**.
+
+{{% /tab %}}
+{{% tab "By YAML" %}}
+
+```yaml
+# example
+stages:
+ - name: Build something
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: echo ${ALIAS_ENV}
+ # environment variables from project secrets
+ envFrom:
+ - sourceName: my-secret
+ sourceKey: secret-key
+ targetKey: ALIAS_ENV
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+## Pipeline Variable Substitution Reference
+
+For your convenience, the following variables are available for your pipeline configuration scripts. During pipeline executions, these variables are replaced by metadata. You can reference them in the form of `${VAR_NAME}`.
+
+Variable Name | Description
+------------------------|------------------------------------------------------------
+`CICD_GIT_REPO_NAME` | Repository name (Github organization omitted).
+`CICD_GIT_URL` | URL of the Git repository.
+`CICD_GIT_COMMIT` | Git commit ID being executed.
+`CICD_GIT_BRANCH` | Git branch of this event.
+`CICD_GIT_REF` | Git reference specification of this event.
+`CICD_GIT_TAG` | Git tag name, set on tag event.
+`CICD_EVENT` | Event that triggered the build (`push`, `pull_request` or `tag`).
+`CICD_PIPELINE_ID` | Rancher ID for the pipeline.
+`CICD_EXECUTION_SEQUENCE` | Build number of the pipeline.
+`CICD_EXECUTION_ID` | Combination of `{CICD_PIPELINE_ID}-{CICD_EXECUTION_SEQUENCE}`.
+`CICD_REGISTRY` | Address for the Docker registry for the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step.
+`CICD_IMAGE` | Name of the image built from the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step. It does not contain the image tag.
[Example](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml)
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/example-repos/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/example-repos/_index.md
new file mode 100644
index 00000000000..7889b6deddc
--- /dev/null
+++ b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/example-repos/_index.md
@@ -0,0 +1,70 @@
+---
+title: Example Repositories
+weight: 500
+aliases:
+ - /rancher/v2.x/en/tools/pipelines/quick-start-guide/
+---
+
+Rancher ships with several example repositories that you can use to familiarize yourself with pipelines. We recommend configuring and testing the example repository that most resembles your environment before using pipelines with your own repositories in a production environment. Use this example repository as a sandbox for repo configuration, build demonstration, etc. Rancher includes example repositories for:
+
+- Go
+- Maven
+- php
+
+> **Note**: The example repositories are only available if you have not [configured a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines).
+
+## Configure Repositories
+
+By default, the example pipeline repositories are disabled. Enable one (or more) to test out the pipeline feature and see how it works.
+
+1. From the **Global** view, navigate to the project that you want to test out pipelines.
+
+1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab.
+
+1. Click **Configure Repositories**.
+
+ **Step Result:** A list of example repositories displays.
+
+ >**Note:** Example repositories only display if you haven't fetched your own repos.
+
+1. Click **Enable** for one of the example repos (e.g., `https://github.com/rancher/pipeline-example-go.git`). Then click **Done**.
+
+**Results:**
+
+- The example repository is enabled to work with a pipeline is available in the **Pipeline** tab.
+
+- The following workloads are deployed to a new namespace:
+
+ - `docker-registry`
+ - `jenkins`
+ - `minio`
+
+## View the Example Pipeline
+
+After enabling an example repository, review the pipeline to see how it is set up.
+
+1. From the **Global** view, navigate to the project that you want to test out pipelines.
+
+1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab.
+
+1. Find the example repository, select the vertical **Ellipsis (...)**. There are two ways to view the pipeline:
+ * **Rancher UI**: Click on **Edit Config** to view the stages and steps of the pipeline.
+ * **YAML**: Click on View/Edit YAML to view the `./rancher-pipeline.yml` file.
+
+## Run the Example Pipeline
+
+After enabling an example repository, run the pipeline to see how it works.
+
+1. From the **Global** view, navigate to the project that you want to test out pipelines.
+
+1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab.
+
+1. Find the example repository, select the vertical **Ellipsis (...) > Run**.
+
+ >**Note:** When you run a pipeline the first time, it takes a few minutes to pull relevant images and provision necessary pipeline components.
+
+**Result:** The pipeline runs. You can see the results in the logs.
+
+## What's Next?
+
+For detailed information about setting up your own pipeline for your repository, [configure a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines), [enable a repository](#configure-repositories) and finally [configure your pipeline]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancer/pipelines/#pipeline-configuration).
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/example/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/example/_index.md
new file mode 100644
index 00000000000..2134780953a
--- /dev/null
+++ b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/example/_index.md
@@ -0,0 +1,72 @@
+---
+title: Example YAML File
+weight: 501
+aliases:
+ - /rancher/v2.x/en/tools/pipelines/reference/
+---
+
+Pipelines can be configured either through the UI or using a yaml file in the repository, i.e. `.rancher-pipeline.yml` or `.rancher-pipeline.yaml`.
+
+In the [pipeline configuration docs](), we provide examples of each available feature within pipelines. Here is a full example for those who want to jump rigt in.
+
+```yaml
+# example
+stages:
+ - name: Build something
+ # Conditions for stages
+ when:
+ branch: master
+ event: [ push, pull_request ]
+ # Multiple steps run concurrently
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: echo ${FIRST_KEY} && echo ${ALIAS_ENV}
+ # Set environment variables in container for the step
+ env:
+ FIRST_KEY: VALUE
+ SECOND_KEY: VALUE2
+ # Set environment variables from project secrets
+ envFrom:
+ - sourceName: my-secret
+ sourceKey: secret-key
+ targetKey: ALIAS_ENV
+ - runScriptConfig:
+ image: busybox
+ shellScript: date -R
+ # Conditions for steps
+ when:
+ branch: [ master, dev ]
+ event: push
+ - name: Publish my image
+ steps:
+ - publishImageConfig:
+ dockerfilePath: ./Dockerfile
+ buildContext: .
+ tag: rancher/rancher:v2.0.0
+ # Optionally push to remote registry
+ pushRemote: true
+ registry: reg.example.com
+ - name: Deploy some workloads
+ steps:
+ - applyYamlConfig:
+ path: ./deployment.yaml
+# branch conditions for the pipeline
+branch:
+ include: [ master, feature/*]
+ exclude: [ dev ]
+# timeout in minutes
+timeout: 30
+notification:
+ recipients:
+ - # Recipient
+ recipient: "#mychannel"
+ # ID of Notifier
+ notifier: "c-wdcsr:n-c9pg7"
+ - recipient: "test@example.com"
+ notifier: "c-wdcsr:n-lkrhd"
+ # Select which statuses you want the notification to be sent
+ condition: ["Failed", "Success", "Changed"]
+ # Ability to override the default message (Optional)
+ message: "my-message"
+```
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/_index.md
index b02a218e569..ab046ce7d06 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/_index.md
@@ -33,6 +33,8 @@ Deploy a workload to run an application in one or more containers.
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/).
+ When you are deploying a Stateful Set, you should use a Volume Claim Template when using Persistent Volumes. This will ensure that Persistent Volumes are created dynamically when you scale your Stateful Set. This option is available in the UI as of Rancher v2.2.0.
+
- **Scaling/Upgrade Policy**
>**Amazon Note for Volumes:**
diff --git a/content/rancher/v2.x/en/project-admin/_index.md b/content/rancher/v2.x/en/project-admin/_index.md
new file mode 100644
index 00000000000..9d024be480f
--- /dev/null
+++ b/content/rancher/v2.x/en/project-admin/_index.md
@@ -0,0 +1,40 @@
+---
+title: Project Administration
+weight: 2500
+---
+
+_Projects_ are objects introduced in Rancher that help organize namespaces in your Kubernetes cluster. You can use projects to create multi-tenant clusters, which allows a group of users to share the same underlying resources without interacting with each other's applications.
+
+In terms of hierarchy:
+
+- Clusters contain projects
+- Projects contain namespaces
+
+Within Rancher, projects allow you to manage multiple namespaces as a single entity. In native Kubernetes, which does not include projects, features like role-based access rights or cluster resources are assigned to individual namespaces. In clusters where multiple namespaces require the same set of access rights, assigning these rights to each individual namespace can become tedious. Even though all namespaces require the same rights, there's no way to apply those rights to all of your namespaces in a single action. You'd have to repetitively assign these rights to each namespace!
+
+Rancher projects resolve this issue by allowing you to apply resources and access rights at the project level. Each namespace in the project then inherits these resources and policies, so you only have to assign them to the project once, rather than assigning them to each individual namespace.
+
+You can use projects to perform actions like:
+
+- [Assign users access to a group of namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/project-members)
+- Assign users [specific roles in a project]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/)
+- [Edit project settings]({{< baseurl >}}/rancher/v2.x/en/project-admin/editing-projects/)
+- [Set resource quotas]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/)
+- [Manage namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/)
+- [Configure tools]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/)
+
+### Authorization
+
+Non-administrative users are only authorized for project access after an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) adds them to the project's **Members** tab.
+
+Whoever creates the project automatically becomes a [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles).
+
+## Switching between Projects
+
+To switch between projects, use the drop-down available in the navigation bar. Alternatively, you can switch between projects directly in the navigation bar.
+
+1. From the **Global** view, navigate to the project that you want to configure.
+
+1. Select **Projects/Namespaces** from the navigation bar.
+
+1. Select the link for the project that you want to open.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/_index.md b/content/rancher/v2.x/en/project-admin/editing-projects/_index.md
similarity index 84%
rename from content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/_index.md
rename to content/rancher/v2.x/en/project-admin/editing-projects/_index.md
index 20391af00e9..86129458b8f 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/_index.md
+++ b/content/rancher/v2.x/en/project-admin/editing-projects/_index.md
@@ -1,8 +1,9 @@
---
title: Editing Projects
-weight: 3021
+weight: 2510
aliases:
- /rancher/v2.x/en/tasks/projects/create-project/
+ - /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/
---
After projects are created, there are certain aspects that can be changed later.
@@ -11,12 +12,6 @@ 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, Keycloak, 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**.
@@ -43,7 +38,7 @@ Following project creation, you can add users as project members so that they ca
>
> - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles).
> - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/locked-roles/).
-
+
**Result:** The chosen users are added to the project.
- To revoke project membership, select the user and click **Delete**. This action deletes membership, not the user.
@@ -93,20 +88,38 @@ Edit [resource quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-a
1. From the main menu, select **Projects/Namespaces**.
1. Find the project that you want to add a resource quota to. From that project, select **Ellipsis (...) > Edit**.
-
+
1. Expand **Resource Quotas** and click **Add Quota**. Alternatively, you can edit existing quotas.
-
-1. Select a [Resource Type]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types).
-
+
+1. Select a [Resource Type]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/#resource-quota-types).
+
1. Enter values for the **Project Limit** and the **Namespace Default Limit**.
-
+
| Field | Description |
| ----------------------- | -------------------------------------------------------------------------------------------------------- |
| Project Limit | The overall resource limit for the project. |
- | Namespace Default Limit | The default resource limit available for each namespace. This limit is propagated to each namespace in the project. The combined limit of all project namespaces shouldn't exceed the project limit. |
-
+ | Namespace Default Limit | The default resource limit available for each namespace. This limit is propagated to each namespace in the project. The combined limit of all project namespaces shouldn't exceed the project limit. |
+
1. **Optional:** Add more quotas.
1. Click **Create**.
-
-**Result:** The resource quota is applied to your project and namespaces. When you add more namespaces in the future, Rancher validates that the project can accommodate the namespace. If the project can't allocate the resources, Rancher won't let you save your changes.
\ No newline at end of file
+
+**Result:** The resource quota is applied to your project and namespaces. When you add more namespaces in the future, Rancher validates that the project can accommodate the namespace. If the project can't allocate the resources, Rancher won't let you save your changes.
+
+
+## Editing Container Default Resource Limit
+
+_Available as of v2.2.0_
+
+Edit [container default resource limit]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#setting-container-default-resource-limit) when:
+
+- You have a CPU or Memory resource quota set on a project, and want to supply the corresponding default values for a container.
+- You want to edit the default container resource limit.
+
+1. From the **Global** view, open the cluster containing the project to which you want to edit the container default resource limit.
+
+1. From the main menu, select **Projects/Namespaces**.
+
+1. Find the project that you want to edit the container default resource limit. From that project, select **Ellipsis (...) > Edit**.
+
+1. Expand **Container Default Resource Limit** and edit the values.
diff --git a/content/rancher/v2.x/en/project-admin/namespaces/_index.md b/content/rancher/v2.x/en/project-admin/namespaces/_index.md
new file mode 100644
index 00000000000..ba3b9cf7dc2
--- /dev/null
+++ b/content/rancher/v2.x/en/project-admin/namespaces/_index.md
@@ -0,0 +1,80 @@
+---
+title: Namespaces
+weight: 2520
+---
+
+Within Rancher, you can further divide projects into different [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/), which are virtual clusters within a project backed by a physical cluster. Should you require another level of organization beyond projects and the `default` namespace, you can use multiple namespaces to isolate applications and resources.
+
+Although you assign resources at the project level so that each namespace can in the project can use them, you can override this inheritance by assigning resources explicitly to a namespace.
+
+Resources that you can assign directly to namespaces include:
+
+- [Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/)
+- [Load Balancers/Ingress]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/)
+- [Service Discovery Records]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/service-discovery/)
+- [Persistent Volume Claims]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/)
+- [Certificates]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/)
+- [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/configmaps/)
+- [Registries]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/registries/)
+- [Secrets]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/secrets/)
+
+>**Note:** Although you can assign role-based access to namespaces in the base version of Kubernetes, you cannot assign roles to namespaces in Rancher. Instead, assign role-based access at the project level.
+
+### Creating Namespaces
+
+Create a new namespace to isolate apps and resources in a project.
+
+>**Tip:** When working with project resources that you can assign to a namespace (i.e., [workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/), [certificates]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/), [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/configmaps), etc.) you can create a namespace on the fly.
+
+1. From the **Global** view, open the project where you want to create a namespace.
+
+ >**Tip:** As a best practice, we recommend creating namespaces from the project level. However, cluster owners and members can can create them from the cluster level as well.
+
+1. From the main menu, select **Namespace**. The click **Add Namespace**.
+
+1. **Optional:** If your project has [Resource Quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas) in effect, you can override the default resource **Limits** (which places a cap on the resources that the namespace can consume).
+
+1. Enter a **Name** and then click **Create**.
+
+**Result:** Your namespace is added to the project. You can begin assigning cluster resources to the namespace.
+
+### Moving Namespaces to Another Project
+
+Cluster admins and members may occasionally need to move a namespace to another project, such as when you want a different team to start using the application.
+
+1. From the **Global** view, open the cluster that contains the namespace you want to move.
+
+1. From the main menu, select **Projects/Namespaces**.
+
+1. Select the namespace(s) that you want to move to a different project. Then click **Move**. You can move multiple namespaces at one.
+
+ >**Notes:**
+ >
+ >- Don't move the namespaces in the `System` project. Moving these namespaces can adversely affect cluster networking.
+ >- You cannot move a namespace into a project that already has a [resource quota]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/) configured.
+ >- If you move a namespace from a project that has a quota set to a project with no quota set, the quota is removed from the namespace.
+
+1. Choose a new project for the new namespace and then click **Move**. Alternatively, you can remove the namespace from all projects by selecting **None**.
+
+**Result:** Your namespace is moved to a different project (or is unattached from all projects). If any project resources are attached to the namespace, the namespace releases them and then attached resources from the new project.
+
+### Editing Namespace Resource Quotas
+
+If there is a [resource quota]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas) configured for a project, you can override the namespace default limit to provide a specific namespace with access to more (or less) project resources.
+
+1. From the **Global** view, open the cluster that contains the namespace for which you want to edit the resource quota.
+
+1. From the main menu, select **Projects/Namespaces**.
+
+1. Find the namespace for which you want to edit the resource quota. Select **Ellipsis (...) > Edit**.
+
+1. Edit the Resource Quota **Limits**. These limits determine the resources available to the namespace. The limits must be set within the configured project limits.
+
+ For more information about each **Resource Type**, see [Resource Quota Types]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types).
+
+ >**Note:**
+ >
+ >- If a resource quota is not configured for the project, these options will not be available.
+ >- If you enter limits that exceed the configured project limits, Rancher will not let you save your edits.
+
+**Result:** The namespace's default resource quota is overwritten with your override.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members/_index.md b/content/rancher/v2.x/en/project-admin/project-members/_index.md
similarity index 90%
rename from content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members/_index.md
rename to content/rancher/v2.x/en/project-admin/project-members/_index.md
index 0be8fca75d5..386d5b80025 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members/_index.md
+++ b/content/rancher/v2.x/en/project-admin/project-members/_index.md
@@ -1,8 +1,9 @@
---
title: Adding Users to Projects
-weight: 3022
+weight: 2505
aliases:
- /rancher/v2.x/en/tasks/projects/add-project-members/
+ - /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members/
---
If you want to provide a user with access and permissions to _specific_ projects and resources within a cluster, assign the user a project membership.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/_index.md b/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md
similarity index 63%
rename from content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/_index.md
rename to content/rancher/v2.x/en/project-admin/resource-quotas/_index.md
index d07cd9c68a6..150463f4a8c 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/_index.md
+++ b/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md
@@ -1,6 +1,8 @@
---
title: Resource Quotas
-weight: 5000
+weight: 2515
+aliases:
+ - /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/
---
_Available as of v2.1.0_
@@ -11,28 +13,27 @@ In situations where several teams share a cluster, one team may overconsume the
Resource quotas in Rancher include the same functionality as the [native version of Kubernetes](https://kubernetes.io/docs/concepts/policy/resource-quotas/). However, in Rancher, resource quotas have been extended so that you can apply them to [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects).
-In a standard Kubernetes deployment, resource quotas are applied to individual namespaces. However, you cannot apply the quota to your namespaces simultaneously with a single action. Instead, the resource quota must be applied multiple times.
+In a standard Kubernetes deployment, resource quotas are applied to individual namespaces. However, you cannot apply the quota to your namespaces simultaneously with a single action. Instead, the resource quota must be applied multiple times.
In the following diagram, a Kubernetes admin is trying to enforce a resource quota without Rancher. The admin wants to apply a resource quota that sets the same CPU and memory limit to every namespace in his cluster (`Namespace 1-4`) . However, in the base version of Kubernetes, each namespace requires a unique resource quota. The admin has to create four different resource quotas that have the same specs configured (`Resource Quota 1-4`) and apply them individually.
Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace
-Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), and then the quota propagates to each namespace, whereafter Kubernetes enforces you limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can [override it](#namespace-default-limit-overrides).
+Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), and then the quota propagates to each namespace, whereafter Kubernetes enforces your limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can [override it](#overriding-the-default-limit-for-a-namespace).
The resource quota includes two limits, which you set while creating or editing a project:
- **Project Limits:**
- This set of values configures an overall resource limit for the project. If you try to add a new namespace to the project, Rancher uses the limits you've set to validate that the project has enough resources to accommodate the namespace. In other words, if you try to add a namespace to a project near its resource quota, Rancher blocks you from adding the namespace.
+ This set of values configures an overall resource limit for the project. If you try to add a new namespace to the project, Rancher uses the limits you've set to validate that the project has enough resources to accommodate the namespace. In other words, if you try to move a namespace into a project near its resource quota, Rancher blocks you from moving the namespace.
- **Namespace Default Limits:**
- This value is the default resource limit available for each namespace. The project propagates the limit to each namespace. Each namespace is bound to this default limit unless you [override it](#namespace-default-limit-overrides).
+ This value is the default resource limit available for each namespace. When the resource quota is set on the project level, this limit is automatically propagated to each namespace in the project. Each namespace is bound to this default limit unless you [override it](#namespace-default-limit-overrides).
-
-In the following diagram, a Rancher admin wants to apply a resource quota that sets the same CPU and memory limit for every namespace in their project (`Namespace 1-4`). However, in Rancher, the admin can set a resource quota for the project (`Project Resource Quota`) rather than individual namespaces. This quota includes resource limits for both the entire project (`Project Limit`) and individual namespaces (`Namespace Default Limit`). Rancher then propagates this quota to each namespace (`Namespace Resource Quota`).
+In the following diagram, a Rancher admin wants to apply a resource quota that sets the same CPU and memory limit for every namespace in their project (`Namespace 1-4`). However, in Rancher, the admin can set a resource quota for the project (`Project Resource Quota`) rather than individual namespaces. This quota includes resource limits for both the entire project (`Project Limit`) and individual namespaces (`Namespace Default Limit`). Rancher then propagates the `Namespace Default Limit` quotas to each namespace (`Namespace Resource Quota`).
Rancher: Resource Quotas Propagating to Each Namespace
@@ -48,21 +49,21 @@ The following table explains the key differences between the two quota types.
## Creating Resource Quotas
-You can create resource quotas in the following contexts:
+You can create resource quotas in the following contexts:
- [While creating projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#creating-projects)
- [While editing projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/#editing-resource-quotas)
## Resource Quota Types
-When you create a resource quota, you are configuring the pool of resources available to the project. You can set the following resource limits for the following resource types.
+When you create a resource quota, you are configuring the pool of resources available to the project. You can set the following resource limits for the following resource types.
| Resource Type | Description |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| CPU Limit | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the project/namespace.1 |
-| CPU Reservation | The minimum amount of CPU (in millicores) guaranteed to the project/namespace.1 |
-| Memory Limit | The maximum amount of memory (in bytes) allocated to the project/namespace.1 |
-| Memory Reservation | The minimum amount of memory (in bytes) guaranteed to the project/namespace.1 |
+| CPU Limit* | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the project/namespace.1 |
+| CPU Reservation* | The minimum amount of CPU (in millicores) guaranteed to the project/namespace.1 |
+| Memory Limit* | The maximum amount of memory (in bytes) allocated to the project/namespace.1 |
+| Memory Reservation* | The minimum amount of memory (in bytes) guaranteed to the project/namespace.1 |
| Storage Reservation | The minimum amount of storage (in gigabytes) guaranteed to the project/namespace. |
| Services Load Balancers | The maximum number of load balancers services that can exist in the project/namespace. |
| Services Node Ports | The maximum number of node port services that can exist in the project/namespace. |
@@ -73,16 +74,42 @@ When you create a resource quota, you are configuring the pool of resources avai
| Replications Controllers | The maximum number of replication controllers that can exist in the project/namespace. |
| Secrets | The maximum number of secrets that can exist in the project/namespace. |
->**1** In the quota, if you set CPU or Memory limits, all containers you create in the project / namespace must explicitly satisfy the quota. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details.
+>***** When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project / namespace, all containers will require a respective CPU or Memory field set during creation. As of v2.2.0, a [container default resource limit](#setting-container-default-resource-limit) can be set at the same time to avoid the need to explicitly set these limits for every workload. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details on why this is required.
-
-### Overriding the Default Limit for a Namespace
+## Overriding the Default Limit for a Namespace
-Although the **Namespace Default Limit** propagates from the project to each namespace, in some cases, you may need to increase (or decrease) the performance for a specific namespace. In this situation, you can override the default limits by editing the namespace.
+Although the **Namespace Default Limit** propagates from the project to each namespace, in some cases, you may need to increase (or decrease) the performance for a specific namespace. In this situation, you can override the default limits by editing the namespace.
In the diagram below, the Rancher admin has a resource quota in effect for their project. However, the admin wants to override the namespace limits for `Namespace 3` so that it performs better. Therefore, the admin [raises the namespace limits]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas) for `Namespace 3` so that the namespace can access more resources.
Namespace Default Limit Override
-How to: [Editing Namespace Resource Quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas)
\ No newline at end of file
+How to: [Editing Namespace Resource Quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas)
+
+### Editing Namespace Resource Quotas
+
+You can always override the namespace default limit to provide a specific namespace with access to more (or less) project resources.
+
+For more information, see how to [edit namespace resource quotas]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/#editing-namespace-resource-quota/).
+
+## Setting Container Default Resource Limit
+
+_Available as of v2.2.0_
+
+When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project / namespace, all containers will require a respective CPU or Memory field set during creation. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details on why this is required.
+
+To avoid setting these limits on each and every container during workload creation, a default container resource limit can be specified on the namespace.
+
+When the default container resource limit is set at a project level, the parameter will be propagated to any namespace created in the project after the limit has been set. For any existing namespace in a project, this limit will not be automatically propagated. You will need to manually set the default container resource limit for any existing namespaces in the project in order for it to be used when creating any containers.
+
+> **Note:** Prior to v2.2.0, you could not launch catalog applications that did not have any limits set. With v2.2.0, you will be able to set a default container resource limit on a project and launch any catalog applications.
+
+Once a container default resource limit is configured on a namespace, the default will be pre-populated for any containers created in that namespace. These limits/reservations can always be overridden during workload creation.
+
+| Resource Type | Description |
+| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| CPU Limit | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the container.|
+| CPU Reservation | The minimum amount of CPU (in millicores) guaranteed to the container. |
+| Memory Limit | The maximum amount of memory (in bytes) allocated to the container. |
+| Memory Reservation | The minimum amount of memory (in bytes) guaranteed to the container.
diff --git a/content/rancher/v2.x/en/tools/_index.md b/content/rancher/v2.x/en/project-admin/tools/_index.md
similarity index 60%
rename from content/rancher/v2.x/en/tools/_index.md
rename to content/rancher/v2.x/en/project-admin/tools/_index.md
index 1f54dfa41bd..94e0c446564 100644
--- a/content/rancher/v2.x/en/tools/_index.md
+++ b/content/rancher/v2.x/en/project-admin/tools/_index.md
@@ -1,16 +1,16 @@
---
-title: Rancher Tools
-weight: 5000
+title: Configuring Tools
+weight: 2525
---
-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:
+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 following categories:
- [Alerts](#alerts)
-- [Notifiers](#notifiers)
- [Logging](#logging)
- [Pipelines](#pipelines)
+- [Monitoring](#monitoring)
@@ -31,39 +31,23 @@ When an event occurs, your alert is triggered, and you are sent a notification.
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).
+You can configure alerts at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/alerts/).
## 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
+- fluentd
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.
+You can configure these services to collect logs at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/logging/).
## Pipelines
@@ -78,3 +62,15 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins
- Deploy your build images to your cluster.
- Run unit tests.
- Run regression tests.
+
+For more information, see [Pipelines]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/).
+
+## Monitoring
+
+_Available as of v2.2.0_
+
+Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. Prometheus provides a _time series_ of your data, which is a stream of timestamped values belonging to the same metric and the same set of labeled dimensions, along with comprehensive statistics and metrics of the monitored cluster.
+
+In other words, Prometheus let's you view metrics from your different Rancher and Kubernetes objects. Using timestamps, you can query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster and project-only Prometheus instances are also supported.
+
+You can configure these services to collect logs at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/).
diff --git a/content/rancher/v2.x/en/project-admin/tools/alerts/_index.md b/content/rancher/v2.x/en/project-admin/tools/alerts/_index.md
new file mode 100644
index 00000000000..d8b7b2c5ab0
--- /dev/null
+++ b/content/rancher/v2.x/en/project-admin/tools/alerts/_index.md
@@ -0,0 +1,164 @@
+---
+title: Alerts
+weight: 2526
+---
+
+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.
+
+Alerts are sets of rules, chosen by you, to monitor for specific events.
+
+Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can manage project alerts.
+
+## Alerts Scope
+
+ The scope for alerts can be set at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/) or project level.
+
+At the project level, Rancher monitors specific deployments and sends alerts for:
+
+* Deployment availability
+* Workloads status
+* Pod status
+* The Prometheus expression cross the thresholds
+
+## Adding Project Alerts
+
+>**Prerequisite:** Before you can receive project alerts, you must [add a notifier]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers).
+
+1. From the **Global** view, navigate to the project that you want to configure project alerts for. Select **Tools > Alerts**. In versions prior to v2.2.0, you can choose **Resources > Alerts**.
+
+1. Click **Add Alert Group**.
+
+1. Enter a **Name** for the alert that describes its purpose, you could group alert rules for the different purpose.
+
+1. Based on the type of alert you want to create, 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 an alert:
+
+ - **Not Running**
+ - **Not Scheduled**
+ - **Restarted `` times with the last `` Minutes**
+
+1. Select the urgency level of the alert. The options are:
+
+ - **Critical**: Most urgent
+ - **Warning**: Normal urgency
+ - **Info**: Least urgent
+
+ Select the urgency level of the alert based on pod state. For example, select **Info** for Job pod which stop running after job finished. However, if an important pod isn't scheduled, it may affect operations, so choose **Critical**.
+
+1. Configure advanced options. By default, the below options will apply to all alert rules within the group. You can disable these advanced options when configuring a specific rule.
+
+ - **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
+ - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
+ - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
+
+{{% /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 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.
+
+1. Configure advanced options. By default, the below options will apply to all alert rules within the group. You can disable these advanced options when configuring a specific rule.
+
+ - **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
+ - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
+ - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
+
+{{% /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 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.
+
+1. Configure advanced options. By default, the below options will apply to all alert rules within the group. You can disable these advanced options when configuring a specific rule.
+
+ - **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
+ - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
+ - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
+
+{{% /accordion %}}
+{{% accordion id="project-expression" label="Metric Expression Alerts" %}}
+
+_Available as of v2.2.0_
+
+If you enable [project monitoring]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/#monitoring), this alert type monitors for the overload from Prometheus expression querying.
+
+1. Input or select an **Expression**, the drop down shows the original metrics from Prometheus, including:
+
+ - [**Container**](https://github.com/google/cadvisor)
+ - [**Kubernetes Resources**](https://github.com/kubernetes/kube-state-metrics)
+ - [**Customize**]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/#project-metrics)
+ - [**Project Level Grafana**](http://docs.grafana.org/administration/metrics/)
+ - **Project Level Prometheus**
+
+1. Choose a comparison.
+
+ - **Equal**: Trigger alert when expression value equal to the threshold.
+ - **Not Equal**: Trigger alert when expression value not equal to the threshold.
+ - **Greater Than**: Trigger alert when expression value greater than to threshold.
+ - **Less Than**: Trigger alert when expression value equal or less than the threshold.
+ - **Greater or Equal**: Trigger alert when expression value greater to equal to the threshold.
+ - **Less or Equal**: Trigger alert when expression value less or equal to the threshold.
+
+1. Input a **Threshold**, for trigger alert when the value of expression cross the threshold.
+
+1. Choose a **Comparison**.
+
+1. Select a **Duration**, for trigger alert when expression value crosses the threshold longer than the configured duration.
+
+1. Select the urgency level of the alert.
+
+ - **Critical**: Most urgent
+ - **Warning**: Normal urgency
+ - **Info**: Least urgent
+
+
+ Select the urgency level of the alert based on its impact on operations. For example, an alert triggered when a expression for container memory close to the limit raises above 60% deems an urgency of **Info**, but raised about 95% deems an urgency of **Critical**.
+
+1. Configure advanced options. By default, the below options will apply to all alert rules within the group. You can disable these advanced options when configuring a specific rule.
+
+ - **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
+ - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
+ - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
+
+{{% /accordion %}}
+
+1. Continue adding more **Alert Rule** to the group.
+
+1. Finally, choose the [notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/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 **Tools > Alerts**. In versions prior to v2.2.0, you can choose **Resources > Alerts**. You can:
+
+- Deactivate/Reactive alerts
+- Edit alert settings
+- Delete unnecessary alerts
+- Mute firing alerts
+- Unmute muted alerts
diff --git a/content/rancher/v2.x/en/project-admin/tools/logging/_index.md b/content/rancher/v2.x/en/project-admin/tools/logging/_index.md
new file mode 100644
index 00000000000..680f9aa2e86
--- /dev/null
+++ b/content/rancher/v2.x/en/project-admin/tools/logging/_index.md
@@ -0,0 +1,106 @@
+---
+title: Logging
+weight: 2527
+---
+
+Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
+
+Rancher supports the following services:
+
+- Elasticsearch
+- Splunk
+- Kafka
+- Syslog
+- Fluentd
+
+>**Note:** You can only configure one logging service per cluster or per project.
+
+Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can configure Rancher to send Kubernetes logs to a logging service.
+
+## Requirements
+
+The Docker daemon on each node in the cluster should be [configured](https://docs.docker.com/config/containers/logging/configure/) with the (default) log-driver: `json-file`. You can check the log-driver by running the following command:
+
+```
+$ docker info | grep 'Logging Driver'
+Logging Driver: json-file
+```
+
+## Advantages
+
+Setting up a logging service to collect logs from your cluster/project has several advantages:
+
+- Logs errors and warnings in your Kubernetes infrastructure to a stream. The stream informs you of events like a container crashing, a pod eviction, or a node dying.
+- Allows you to capture and analyze the state of your cluster and look for trends in your environment using the log stream.
+- Helps you when troubleshooting or debugging.
+- Saves your logs to a safe location outside of your cluster, so that you can still access them even if your cluster encounters issues.
+
+## Logging Scope
+
+You can configure logging at either cluster level or project level.
+
+- [Cluster logging]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/) writes logs for every pod in the cluster, i.e. in all the projects. For [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters), it also writes logs for all the Kubernetes system components.
+
+- Project logging writes logs for every pod in that particular project.
+
+Logs that are sent to your logging service are from the following locations:
+
+ - Pod logs stored at `/var/log/containers`.
+
+ - Kubernetes system components logs stored at `/var/lib/rancher/rke/logs/`.
+
+## Enabling Project Logging
+
+1. From the **Global** view, navigate to the project that you want to configure project logging.
+
+1. Select **Tools > Logging** in the navigation bar. In versions prior to v2.2.0, you can choose **Resources > Logging**.
+
+1. Select a logging service and enter the configuration. Refer to the specific service for detailed configuration. Rancher supports the following services:
+
+ - [Elasticsearch]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/elasticsearch/)
+ - [Splunk]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/splunk/)
+ - [Kafka]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/kafka/)
+ - [Syslog]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/syslog/)
+ - [Fluentd]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/fluentd/)
+
+1. (Optional) Instead of using the UI to configure the logging services, you can enter custom advanced configurations by clicking on **Edit as File**, which is located above the logging targets. This link is only visible after you select a logging service.
+
+ - With the file editor, enter raw fluentd configuration for any logging service. Refer to the documentation for each logging service on how to setup the output configuration.
+
+ - [Elasticsearch Documentation](https://github.com/uken/fluent-plugin-elasticsearch)
+ - [Splunk Documentation](https://github.com/fluent/fluent-plugin-splunk)
+ - [Kafka Documentation](https://github.com/fluent/fluent-plugin-kafka)
+ - [Syslog Documentation](https://github.com/dlackty/fluent-plugin-remote_syslog)
+ - [Fluentd Documentation](https://docs.fluentd.org/v1.0/articles/out_forward)
+
+ - If the logging service is using TLS, you also need to complete the **SSL Configuration** form.
+ 1. Provide the **Client Private Key** and **Client Certificate**. You can either copy and paste them or upload them by using the **Read from a file** button.
+
+ - You can use either a self-signed certificate or one provided by a certificate authority.
+
+ - You can generate a self-signed certificate 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"
+ ```
+ 2. If you are using a self-signed certificate, provide the **CA Certificate PEM**.
+
+1. (Optional) Complete the **Additional Logging Configuration** form.
+
+ 1. **Optional:** Use the **Add Field** button to add custom log fields to your logging configuration. These fields are key value pairs (such as `foo=bar`) that you can use to filter the logs from another system.
+
+ 1. Enter a **Flush Interval**. This value determines how often [Fluentd](https://www.fluentd.org/) flushes data to the logging server. Intervals are measured in seconds.
+
+ 1. **Include System Log**. The logs from pods in system project and RKE components will be sent to the target. Uncheck it to exclude the system logs.
+
+1. Click **Test**. Rancher sends a test log to the service.
+
+ > **Note:** This button is replaced with _Dry Run_ if you are using the custom configuration editor. In this case, Rancher calls the fluentd dry run command to validate the configuration.
+
+1. Click **Save**.
+
+**Result:** Rancher is now configured to send logs to the selected service. Log into the logging service so that you can start viewing the logs.
+
+## Related Links
+
+[Logging Architecture](https://kubernetes.io/docs/concepts/cluster-administration/logging/)
diff --git a/content/rancher/v2.x/en/project-admin/tools/monitoring/_index.md b/content/rancher/v2.x/en/project-admin/tools/monitoring/_index.md
new file mode 100644
index 00000000000..c675ca29658
--- /dev/null
+++ b/content/rancher/v2.x/en/project-admin/tools/monitoring/_index.md
@@ -0,0 +1,50 @@
+---
+title: Monitoring
+weight: 2528
+---
+
+_Available as of v2.2.0_
+
+Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. Prometheus provides a _time series_ of your data, which is, according to [Prometheus documentation](https://prometheus.io/docs/concepts/data_model/):
+
+>A stream of timestamped values belonging to the same metric and the same set of labeled dimensions, along with comprehensive statistics and metrics of the monitored cluster.
+
+In other words, Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Using timestamps, Prometheus lets you query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster and project-only Prometheus instances are also supported.
+
+Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can configure project level monitoring. Project members can only view monitoring metrics.
+
+## Monitoring Scope
+
+Using Prometheus, you can monitor Rancher at both the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) and project level. For each cluster and project that is enabled for monitoring, Rancher deploys a Prometheus server.
+
+- [Cluster monitoring]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) allows you to view the health of your Kubernetes cluster. Prometheus collects metrics from the cluster components below, which you can view in graphs and charts.
+
+ - [Kubernetes control plane]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/#kubernetes-components-metrics)
+ - [etcd database]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/#etcd-metrics)
+ - [All nodes (including workers)]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/#cluster-metrics)
+
+- Project monitoring allows you to view the state of pods running in a given project. Prometheus collects metrics from the project's deployed HTTP and TCP/UDP workloads.
+
+## Configuring Project Monitoring
+
+1. From the **Global** view, navigate to the project that you want to configure project monitoring.
+
+1. Select **Tools > Monitoring** in the navigation bar.
+
+1. Select **Enable** to show the [Prometheus configuration options]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/prometheus/). Enter in your desired configuration options.
+
+1. Click **Save**.
+
+**Result:** A single application,`project-monitoring`, is added as an [application]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/) to the project. After the application is `active`, you can start viewing [project metrics](#project-metrics) through the [Rancher dashboard]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#rancher-dashboard) or directly from [Grafana]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#grafana).
+
+## Project Metrics
+
+If [cluster monitoring]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) is also enabled for the project, [workload metrics]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/#workload-metrics) are available for the project.
+
+If only project monitoring is enabled, you can monitor custom metrics from any [exporters](https://prometheus.io/docs/instrumenting/exporters/). You can expose some endpoints on deployments without needing to configure Prometheus for your project.
+
+### Example
+
+A [Redis](https://redis.io/) application is deployed in the namespace `redis-app` in the project `Datacenter`. It is monitored via [Redis exporter](https://github.com/oliver006/redis_exporter).
+
+After enabling project monitoring, you can edit the application to configure the **Advanced Options -> Custom Metrics** section. Enter the `Container Port` and `Path` and select the `Protocol`.
diff --git a/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md b/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md
new file mode 100644
index 00000000000..8b7cc985f05
--- /dev/null
+++ b/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md
@@ -0,0 +1,347 @@
+---
+title: Pipelines
+weight: 2529
+aliases:
+ - /rancher/v2.x/en/concepts/ci-cd-pipelines/
+ - /rancher/v2.x/en/tasks/pipelines/
+ - /rancher/v2.x/en/tools/pipelines/
+ - /rancher/v2.x/en/tools/pipelines/configurations/
+---
+>**Notes:**
+>
+>- Pipelines are new and improved for Rancher v2.1! Therefore, if you configured pipelines while using v2.0.x, you'll have to reconfigure them after upgrading to v2.1.
+>- Still using v2.0.x? See the pipeline documentation for [previous versions]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x).
+
+A _pipeline_ is a software delivery process that is broken into different stages and steps. Setting up a pipeline can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects.
+
+Typically, pipeline stages include:
+
+- **Build:**
+
+ Each time code is checked into your repository, the pipeline automatically clones the repo and builds a new iteration of your software. Throughout this process, the software is typically reviewed by automated tests.
+
+- **Publish:**
+
+ After the build is completed, either a Docker image is built and published to a Docker registry or a catalog template is published.
+
+- **Deploy:**
+
+ After the artifacts are published, you would release your application so users could start using the updated product.
+
+Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can [configure version control providers](#version-control-providers) and [manage global pipeline execution settings](#managing-global-pipeline-execution-settings). Project members can only configure [repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/#configuring-repositories) and [pipelines]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/#pipeline-configuration).
+
+## Overview
+
+Rancher's pipeline provides a simple CI/CD experience. Use it to automatically checkout code, run builds or scripts, publish Docker images or catalog applications, and deploy the updated software to users.
+
+After enabling the ability to use pipelines in a project, you can configure multiple pipelines in each project. Each pipeline is unique and can be configured independently.
+
+A pipeline is configured off of a group of files that are checked into source code repositories. Users can configure their pipelines either through the Rancher UI or by adding a `.rancher-pipeline.yml` into the repository.
+
+>**Note:** Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses.
+
+
+## How Pipelines Work
+
+When you configure a pipeline in one of your projects, a namespace specifically for the pipeline is automatically created. The following components are deployed to it:
+
+ - **Jenkins:**
+
+ The pipeline's build engine. Because project users do not directly interact with Jenkins, it's managed and locked.
+
+ >**Note:** There is no option to use existing Jenkins deployments as the pipeline engine.
+
+ - **Docker Registry:**
+
+ Out-of-the-box, the default target for your build-publish step is an internal Docker Registry. However, you can make configurations to push to a remote registry instead. The internal Docker Registry is only accessible from cluster nodes and cannot be directly accessed by users. Images are not persisted beyond the lifetime of the pipeline and should only be used in pipeline runs. If you need to access your images outside of pipeline runs, please push to an external registry.
+
+ - **Minio:**
+
+ Minio storage is used to store the logs for pipeline executions.
+
+ >**Note:** The managed Jenkins instance works statelessly, so don't worry about its data persistency. The Docker Registry and Minio instances use ephemeral volumes by default, which is fine for most use cases. If you want to make sure pipeline logs can survive node failures, you can configure persistent volumes for them, as described in [data persistency for pipeline components](#configuring-persistent-data-for-pipeline-components).
+
+## Pipeline Triggers
+
+After you configure a pipeline, you can trigger it using different methods:
+
+
+- **Manually:**
+
+ After you configure a pipeline, you can trigger a build using the latest CI definition from Rancher UI. When a pipeline execution is triggered, Rancher dynamically provisions a Kubernetes pod to run your CI tasks and then remove it upon completion.
+
+- **Automatically:**
+
+ When you enable a repository for a pipeline, webhooks are automatically added to the version control system. When project users interact with the repo—push code, open pull requests, or create a tag—the version control system sends a webhook to Rancher Server, triggering a pipeline execution.
+
+ To use this automation, webhook management permission is required for the repository. Therefore, when users authenticate and fetch their repositories, only those on which they have webhook management permission will be shown.
+
+## Version Control Providers
+
+Before you can start [configuring a pipeline]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/) for your repository, you must configure and authorize a version control provider.
+
+| Provider | Available as of |
+| --- | --- |
+| GitHub | v2.0.0 |
+| GitLab | v2.1.0 |
+| Bitbucket | v2.2.0 |
+
+Select your provider's tab below and follow the directions.
+
+{{% tabs %}}
+{{% tab "GitHub" %}}
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Tools > Pipelines** in the navigation bar. In versions prior to v2.2.0, you can select **Resources > Pipelines**.
+
+1. Follow the directions displayed to **Setup a Github application**. Rancher redirects you to Github to setup an OAuth App in Github.
+
+1. From GitHub, copy the **Client ID** and **Client Secret**. Paste them into Rancher.
+
+1. If you're using GitHub for enterprise, select **Use a private github enterprise installation**. Enter the host address of your GitHub installation.
+
+1. Click **Authenticate**.
+
+{{% /tab %}}
+{{% tab "GitLab" %}}
+
+_Available as of v2.1.0_
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Tools > Pipelines** in the navigation bar. In versions prior to v2.2.0, you can select **Resources > Pipelines**.
+
+1. Follow the directions displayed to **Setup a GitLab application**. Rancher redirects you to GitLab.
+
+1. From GitLab, copy the **Application ID** and **Secret**. Paste them into Rancher.
+
+1. If you're using GitLab for enterprise setup, select **Use a private gitlab enterprise installation**. Enter the host address of your GitLab installation.
+
+1. Click **Authenticate**.
+
+>**Note:**
+> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
+> 2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
+{{% /tab %}}
+{{% tab "Bitbucket Cloud" %}}
+
+_Available as of v2.2.0_
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Tools > Pipelines** in the navigation bar.
+
+1. Choose the **Use public Bitbucket Cloud** option.
+
+1. Follow the directions displayed to **Setup a Bitbucket Cloud application**. Rancher redirects you to Bitbucket to setup an OAuth consumer in Bitbucket.
+
+1. From Bitbucket, copy the consumer **Key** and **Secret**. Paste them into Rancher.
+
+1. Click **Authenticate**.
+
+{{% /tab %}}
+{{% tab "Bitbucket Server" %}}
+
+_Available as of v2.2.0_
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Tools > Pipelines** in the navigation bar.
+
+1. Choose the **Use private Bitbucket Server setup** option.
+
+1. Follow the directions displayed to **Setup a Bitbucket Server application**.
+
+1. Enter the host address of your Bitbucket server installation.
+
+1. Click **Authenticate**.
+
+>**Note:**
+> Bitbucket server needs to do SSL verification when sending webhooks to Rancher. Please ensure that Rancher server's certificate is trusted by the Bitbucket server. There are two options:
+>
+> 1. Setup Rancher server with a certificate from a trusted CA.
+> 1. If you're using self-signed certificates, import Rancher server's certificate to the Bitbucket server. For instructions, see the Bitbucket server documentation for [configuring self-signed certificates](https://confluence.atlassian.com/bitbucketserver/if-you-use-self-signed-certificates-938028692.html).
+>
+{{% /tab %}}
+{{% /tabs %}}
+
+**Result:** After the version control provider is authenticated, you will be automatically re-directed to start [configuring which repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/#configuring-repositories) that you want start using with a pipeline. Once a repository is enabled, you can start to [configure the pipeline]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/#pipeline-configuration).
+
+## Managing Global Pipeline Execution Settings
+
+After configuring a version control provider, there are several options that can be configured globally on how [pipelines]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/) are executed in Rancher.
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Tools > Pipelines** in the navigation bar. In versions prior to v2.2.0, you can select **Resources > Pipelines**.
+
+1. Edit the different settings:
+
+ {{% accordion id="executor-quota" label="Executor Quota" %}}
+
+Select the maximum number of pipeline executors. The _executor quota_ decides how many builds can run simultaneously in the project. If the number of triggered builds exceeds the quota, subsequent builds will queue until a vacancy opens. By default, the quota is `2`. A value of `0` or less removes the quota limit.
+ {{% /accordion %}}
+
+ {{% accordion id="resource-quota" label="Resource Quota for Executors" %}}
+
+_Available as of v2.2.0_
+
+Configure compute resources for Jenkins agent containers. When a pipeline execution is triggered, a build pod is dynamically provisioned to run your CI tasks. Under the hood, A build pod consists of one Jenkins agent container and one container for each pipeline step. You can [manage compute resources](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) for every containers in the pod.
+
+Edit the **Memory Reservation**, **Memory Limit**, **CPU Reservation** or **CPU Limit**, then click **Update Limit and Reservation**.
+
+To configure compute resources for pipeline-step containers:
+{{% tabs %}}
+{{% tab "By YAML" %}}
+
+You can configure compute resources for pipeline-step containers in the `.rancher-pipeline.yml` file.
+
+In a [step type]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/#step-types), you will provide the following information:
+
+* **CPU Reservation (`CpuRequest`)**: CPU request for the container of a pipeline step.
+* **CPU Limit (`CpuLimit`)**: CPU limit for the container of a pipeline step.
+* **Memory Reservation (`MemoryRequest`)**: Memory request for the container of a pipeline step.
+* **Memory Limit (`MemoryLimit`)**: Memory limit for the container of a pipeline step.
+
+```yaml
+# example
+stages:
+ - name: Build something
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: ls
+ cpuRequest: 100m
+ cpuLimit: 1
+ memoryRequest:100Mi
+ memoryLimit: 1Gi
+ - publishImageConfig:
+ dockerfilePath: ./Dockerfile
+ buildContext: .
+ tag: repo/app:v1
+ cpuRequest: 100m
+ cpuLimit: 1
+ memoryRequest:100Mi
+ memoryLimit: 1Gi
+```
+
+>**Note:** Rancher sets default compute resources for pipeline steps except for `Build and Publish Images` and `Run Script` steps. You can override the default value by specifying compute resources in the same way.
+{{% /tab %}}
+{{% /tabs %}}
+
+ {{% /accordion %}}
+ {{% accordion id="cacerts" label="Custom CA" %}}
+
+_Available as of v2.2.0_
+
+If you want to use a version control provider with a certificate from a custom/internal CA root, the CA root certificates need to be added as part of the version control provider configuration in order for the pipeline build pods to succeed.
+
+1. Click **Edit cacerts**.
+
+1. Paste in the CA root certificates and click **Save cacerts**.
+
+**Result:** Pipelines can be used and new pods will be able to work with the self-signed-certificate.
+
+ {{% /accordion %}}
+
+## Configuring Persistent Data for Pipeline Components
+
+The internal [Docker registry](#how-pipelines-work) and the [Minio](#how-pipelines-work) workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.
+
+>**Prerequisites (for both parts A and B):**
+>
+>[Persistent volumes]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#persistent-volumes) must be available for the cluster.
+
+### A. Configuring Persistent Data for Docker Registry
+
+1. From the project that you're configuring a pipeline for, select the **Workloads** tab.
+
+1. Find the `docker-registry` workload and select **Ellipsis (...) > Edit**.
+
+1. Scroll to the **Volumes** section and expand it. Make one of the following selections from the **Add Volume** menu, which is near the bottom of the section:
+
+ - **Add Volume > Add a new persistent volume (claim)**
+ - **Add Volume > Use an existing persistent volume (claim)**
+
+1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
+{{% tabs %}}
+
+{{% tab "Add a new persistent volume" %}}
+
+1. Enter a **Name** for the volume claim.
+
+1. Select a volume claim **Source**:
+
+ - If you select **Use a Storage Class to provision a new persistent volume**, select a [Storage Class]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#storage-classes) and enter a **Capacity**.
+
+ - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
+1. From the **Customize** section, choose the read/write access for the volume.
+
+1. Click **Define**.
+
+{{% /tab %}}
+
+{{% tab "Use an existing persistent volume" %}}
+
+1. Enter a **Name** for the volume claim.
+
+1. Choose a **Persistent Volume Claim** from the drop-down.
+
+1. From the **Customize** section, choose the read/write access for the volume.
+
+1. Click **Define**.
+
+{{% /tab %}}
+
+{{% /tabs %}}
+
+1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container.
+
+1. Click **Upgrade**.
+
+### B. Configuring Persistent Data for Minio
+
+1. From the **Workloads** tab, find the `minio` workload and select **Ellipsis (...) > Edit**.
+
+1. Scroll to the **Volumes** section and expand it. Make one of the following selections from the **Add Volume** menu, which is near the bottom of the section:
+
+ - **Add Volume > Add a new persistent volume (claim)**
+ - **Add Volume > Use an existing persistent volume (claim)**
+
+1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
+{{% tabs %}}
+
+{{% tab "Add a new persistent volume" %}}
+
+1. Enter a **Name** for the volume claim.
+
+1. Select a volume claim **Source**:
+
+ - If you select **Use a Storage Class to provision a new persistent volume**, select a [Storage Class]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#storage-classes) and enter a **Capacity**.
+
+ - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
+1. From the **Customize** section, choose the read/write access for the volume.
+
+1. Click **Define**.
+
+{{% /tab %}}
+
+{{% tab "Use an existing persistent volume" %}}
+
+1. Enter a **Name** for the volume claim.
+
+1. Choose a **Persistent Volume Claim** from the drop-down.
+
+1. From the **Customize** section, choose the read/write access for the volume.
+
+1. Click **Define**.
+
+{{% /tab %}}
+
+{{% /tabs %}}
+
+1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container.
+
+1. Click **Upgrade**.
+
+**Result:** Persistent storage is configured for your pipeline components.
diff --git a/content/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x/_index.md b/content/rancher/v2.x/en/project-admin/tools/pipelines/docs-for-v2.0.x/_index.md
similarity index 98%
rename from content/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x/_index.md
rename to content/rancher/v2.x/en/project-admin/tools/pipelines/docs-for-v2.0.x/_index.md
index adf02862bde..0afe3b45e5f 100644
--- a/content/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x/_index.md
+++ b/content/rancher/v2.x/en/project-admin/tools/pipelines/docs-for-v2.0.x/_index.md
@@ -1,6 +1,8 @@
---
title: v2.0.x Pipeline Documentation
weight: 9000
+aliases:
+ - /rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x
---
>**Note:** This section describes the pipeline feature as implemented in Rancher v2.0.x. If you are using Rancher v2.1 or later, where pipelines have been significantly improved, please refer to the new documentation for [v2.1 or later]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines).
diff --git a/content/rancher/v2.x/en/removing-rancher/_index.md b/content/rancher/v2.x/en/removing-rancher/_index.md
new file mode 100644
index 00000000000..e7f11cc45a4
--- /dev/null
+++ b/content/rancher/v2.x/en/removing-rancher/_index.md
@@ -0,0 +1,14 @@
+---
+title: Removing Rancher Server
+weight: 7501
+aliases:
+ - /rancher/v2.x/en/installation/removing-rancher/cleaning-cluster-nodes/
+ - /rancher/v2.x/en/installation/removing-rancher/
+ - /rancher/v2.x/en/admin-settings/removing-rancher/
+ - /rancher/v2.x/en/admin-settings/removing-rancher/rancher-cluster-nodes/
+---
+
+When you deploy Rancher and use it to provision clusters, Rancher installs its components on the nodes you use. There are two contexts in which you'd remove Rancher from a Kubernetes cluster node.
+
+- **[Removing Rancher from Your Rancher Server Nodes]({{< baseurl >}}/rancher/v2.x/en/system-tools/#remove)**: In this context, you are removing Rancher from the Kubernetes cluster that you configured for your [Rancher installation]({{< baseurl >}}/rancher/v2.x/en/installation/ha/). This can be done using [System Tools]({{< baseurl >}}/rancher/v2.x/en/system-tools/).
+- **[Removing Rancher Components from Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/admin-settings/removing-rancher/user-cluster-nodes/)**: In this context, you are removing Rancher components from Kubernetes clusters that you [launched using Rancher]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/).
diff --git a/content/rancher/v2.x/en/security/_index.md b/content/rancher/v2.x/en/security/_index.md
index ff9b88d6447..1524ce23a26 100644
--- a/content/rancher/v2.x/en/security/_index.md
+++ b/content/rancher/v2.x/en/security/_index.md
@@ -1,5 +1,5 @@
---
-title: Rancher Security
+title: Security
weight: 7505
---
diff --git a/content/rancher/v2.x/en/system-tools/_index.md b/content/rancher/v2.x/en/system-tools/_index.md
new file mode 100644
index 00000000000..2856637d961
--- /dev/null
+++ b/content/rancher/v2.x/en/system-tools/_index.md
@@ -0,0 +1,118 @@
+---
+title: System Tools
+weight: 6001
+---
+
+System Tools is a tool to perform operational tasks on [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) clusters or [RKE cluster as used for Rancher HA]({{< baseurl >}}/rancher/v2.x/en/installation/ha/kubernetes-rke/). The tasks include:
+
+* Collect logging and system metrics from nodes.
+* Remove Kubernetes resources created by Rancher.
+
+### Download System Tools
+
+You can download the latest version of System Tools from the [GitHub releases page](https://github.com/rancher/system-tools/releases/latest). Download the version of `system-tools` for the OS that you are using to interact with the cluster.
+
+Operating System | Filename
+-----------------|-----
+MacOS | `system-tools_darwin-amd64`
+Linux | `system-tools_linux-amd64`
+Windows | `system-tools_windows-amd64.exe`
+
+After you download the tools, complete the following actions:
+
+1. Rename the file to `system-tools`.
+
+1. Give the file executable permissions by running the following command:
+
+ > **Using Windows?**
+ The file is already an executable, you can skip this step.
+
+ ```
+ chmod +x system-tools
+ ```
+
+### Using System Tools
+
+The following subcommands are available:
+
+| Command | Description
+|---|---
+| [logs](#logs) | Collect Kubernetes cluster component logs from nodes.
+| [stats](#stats) | Stream system metrics from nodes.
+| [remove](#remove) | Remove Kubernetes resources created by Rancher.
+
+### Logs
+
+The logs subcommand will collect log files of core Kubernetes cluster components from nodes in [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) clusters or [RKE cluster as used for Rancher HA]({{< baseurl >}}/rancher/v2.x/en/installation/ha/kubernetes-rke/). See [Troubleshooting]({{< baseurl >}}//rancher/v2.x/en/troubleshooting/) for a list of core Kubernetes cluster components.
+
+System Tools will use the provided kubeconfig file to deploy a DaemonSet, that will copy all the logfiles from the core Kubernetes cluster components and add them to a single tar file (`cluster-logs.tar` by default). If you only want to collect logging from a single node, you can specify the node by using `--node NODENAME` or `-n NODENAME`.
+
+#### Usage
+
+```
+./system-tools_darwin-amd64 logs --kubeconfig
+```
+
+#### Options
+
+| Option | Description
+| ------------------------------------------------------ | ------------------------------------------------------
+| `--kubeconfig , -c ` | The cluster's kubeconfig file.
+| `--output , -o cluster-logs.tar` | Name of the created tarball containing the logs. If no output filename is defined, the options defaults to `cluster-logs.tar`.
+| `--node , -n node1` | Specify the nodes to collect the logs from. If no node is specified, logs from all nodes in the cluster will be collected.
+
+### Stats
+
+The stats subcommand will display system metrics from nodes in [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) clusters or [RKE cluster as used for Rancher HA]({{< baseurl >}}/rancher/v2.x/en/installation/ha/kubernetes-rke/).
+
+System Tools will deploy a DaemonSet, and run a predefined command based on `sar` (System Activity Report) to show system metrics.
+
+#### Usage
+
+```
+./system-tools_darwin-amd64 stats --kubeconfig
+```
+
+#### Options
+
+| Option | Description
+| ------------------------------------------------------ | ------------------------------
+| `--kubeconfig , -c ` | The cluster's kubeconfig file.
+| `--node , -n node1` | Specify the nodes to display the system metrics from. If no node is specified, logs from all nodes in the cluster will be displayed.
+| `--stats-command value, -s value` | The command to run to display the system metrics. If no command is defined, the options defaults to `/usr/bin/sar -u -r -F 1 1`.
+
+### Remove
+
+When you install Rancher on a Kubernetes cluster, it will create Kubernetes resources to run and to store configuration data. If you want to remove Rancher from your cluster, you can use the remove subcommand to remove the Kubernetes resources. When you use the remove subcommand, the following resources will be removed:
+
+>**Warning:** This command will remove data from your etcd nodes. Make sure you have created a [backup of etcd]({{< baseurl >}}/rancher/v2.x/en/backups/backups) before executing the command.
+
+- The Rancher deployment namespace (`cattle-system` by default).
+- Any `serviceAccount`, `clusterRoles`, and `clusterRoleBindings` that Rancher applied the `cattle.io/creator:norman` label to. Rancher applies this label to any resource that it creates as of v2.1.0.
+- Labels, annotations, and finalizers.
+- Rancher Deployment.
+- Machines, clusters, projects, and user custom resource deployments (CRDs).
+- All resources create under the `management.cattle.io` API Group.
+- All CRDs created by Rancher v2.x.
+
+>**Using 2.0.8 or Earlier?**
+>
+>These versions of Rancher do not automatically delete the `serviceAccount`, `clusterRole`, and `clusterRoleBindings` resources after the job runs. You'll have to delete them yourself.
+
+#### Usage
+
+When you run the command below, all the resources listed [above](#remove) will be removed from the cluster.
+
+>**Warning:** This command will remove data from your etcd nodes. Make sure you have created a [backup of etcd]({{< baseurl >}}/rancher/v2.x/en/backups/backups) before executing the command.
+
+```
+./system-tools remove --kubeconfig --namespace
+```
+
+#### Options
+
+| Option | Description
+| ---------------------------------------------- | ------------
+| `--kubeconfig , -c ` | The cluster's kubeconfig file
+| `--namespace , -n cattle-system` | Rancher 2.x deployment namespace (``). If no namespace is defined, the options defaults to `cattle-system`.
+| `--force` | Skips the the interactive removal confirmation and removes the Rancher deployment without prompt.
diff --git a/content/rancher/v2.x/en/tools/logging/_index.md b/content/rancher/v2.x/en/tools/logging/_index.md
deleted file mode 100644
index a49890cb44e..00000000000
--- a/content/rancher/v2.x/en/tools/logging/_index.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Logging
-weight: 5015
-aliases:
- - /rancher/v2.x/en/tasks/logging/
----
-
-Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
-
-Rancher supports the following services:
-
-- [Elasticsearch]({{< baseurl >}}/rancher/v2.x/en/tools/logging/elasticsearch)
-- [Splunk]({{< baseurl >}}/rancher/v2.x/en/tools/logging/splunk)
-- [Kafka]({{< baseurl >}}/rancher/v2.x/en/tools/logging/kafka)
-- [Syslog]({{< baseurl >}}/rancher/v2.x/en/tools/logging/syslog)
-
-## Requirements
-
-Docker daemon should be [configured](https://docs.docker.com/config/containers/logging/configure/) with the (default) log-driver: `json-file`. You can check the log-driver by running the following command:
-
-```
-$ docker info | grep 'Logging Driver'
-Logging Driver: json-file
-```
-
-## Advantages
-
-Setting up a logging service to collect logs from your cluster/project is helpful several ways:
-
-- Logs errors and warnings in your Kubernetes infrastructure to a stream. The stream informs you of events like a container crashing, a pod eviction, or a node dying.
-- Allows you to capture and analyze the state of your cluster and look for trends in your environment using the log stream.
-- Helps you when troubleshooting or debugging.
-- Saves your logs to a safe location outside of your cluster, so that you can still access them even if your cluster encounters issues.
-
-## Logging Scope
-
-You can configure logging at either cluster or project level.
-
->**Note:** You can only configure one logging service per cluster or project.
-
-- If you're a [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) who works in operations or security, configure cluster logging.
-
- Cluster logging writes logs for every pod in the cluster and, in [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters), Kubernetes system components. Logs from the following locations are sent to your logging service:
-
-
- - The `/var/log/containers` path for pod logging.
-
- - The `/var/lib/rancher/rke/logs/` path for Kubernetes system components.
-
-- If you're a [project owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) who works on an application, configure project logging.
-
- Project logging writes logs for every pod in the project (`/var/log/containers`).
-
-After collection, all logs are stored by your logging service. Log into your service to view them.
-
-## Related Links
-
-[Logging Architecture](https://kubernetes.io/docs/concepts/cluster-administration/logging/)
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/tools/logging/elasticsearch/_index.md b/content/rancher/v2.x/en/tools/logging/elasticsearch/_index.md
deleted file mode 100644
index 9511a7321ce..00000000000
--- a/content/rancher/v2.x/en/tools/logging/elasticsearch/_index.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: Elasticsearch
-weight: 200
----
-
-If your organization uses [Elasticsearch](https://www.elastic.co/), either on premise or in the cloud, you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Elasticsearch deployment to view logs for your cluster or container.
-
-## Configuring Elasticsearch Logging
-
-You can configure Rancher to send logs from your cluster or project to your instance of Elasticsearch.
-
->**Prerequisites:** Configure an [Elasticsearch deployment](https://www.elastic.co/guide/en/cloud/saas-release/ec-create-deployment.html).
-
-1. Browse to the cluster or project that you want to log.
-{{% accordion id="cluster" label="To Configure Cluster Logging:" %}}
-If you're a [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) who works in operations or security, configure cluster logging.
-
-1. From the **Global** view, open the cluster that you want to configure logging for.
-
-1. From the main menu, select **Tools > Logging**.
-{{% /accordion %}}
-{{% accordion id="project" label="To Configure Project Logging:" %}}
-If you're a [project owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) who works on an application, configure project logging.
-
-1. From the **Global** view, open the project that you want to configure logging for.
-
-1. From the main menu, select **Resources > Logging**.
-{{% /accordion %}}
-
-1. Select **Elasticsearch**.
-
-1. Complete the **Elasticsearch Configuration** form.
-
- 1. From the **Endpoint** field, enter the IP address and port for your Elasticsearch instance. You can copy this information from the dashboard of your Elasticsearch deployment. Elasticsearch usually uses port `9200` for HTTP and `9243` for HTTPS.
-
- 1. If you are using [X-Pack Security](https://www.elastic.co/guide/en/x-pack/current/xpack-introduction.html), enter your Elasticsearch **Username** and **Password** for authentication.
-
- 1. Enter an [Index Pattern](https://www.elastic.co/guide/en/kibana/current/index-patterns.html).
-
-1. If your instance of Elasticsearch uses SSL, complete the **SSL Configuration** form.
-
- 1. Enter a private key and client certificate. Either copy and paste them or browse to them using **Read from a file**. This certificate will be installed on your logging server.
-
- You can use either a self-signed certificate or one provided by a certificate authority.
-
- You can generate a self-signed certificate 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. Enter your private key password.
-
- 1. If you are using a certificate from a certificate authority (and not a self-signed certificate), select the **Enabled - Input trusted server certificate** option and then enter your **Trusted Server Certificate**.
-
-1. Complete the **Additional Logging Configuration** form.
-
- 1. **Optional:** Use the **Add Field** button to add custom log fields to your logging configuration. These fields are key value pairs (such as `foo=bar`) that you can use to filter the logs from another system.
-
- 1. Enter a **Flush Interval**. This value determines how often [Fluentd](https://www.fluentd.org/) flushes data to the logging server. Intervals are measured in seconds.
-
-1. Click **Save**.
-
-**Result:** Rancher is now configured to send cluster and container logs to Elasticsearch. Log into Elasticsearch or Kibana to view your cluster/project logs.
diff --git a/content/rancher/v2.x/en/tools/logging/kafka/_index.md b/content/rancher/v2.x/en/tools/logging/kafka/_index.md
deleted file mode 100644
index eb062b4fa37..00000000000
--- a/content/rancher/v2.x/en/tools/logging/kafka/_index.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Kafka
-weight: 400
----
-
-You can configure Rancher to send cluster or project logs to a [Kafka](https://kafka.apache.org/) server.
-
-## Configuring Kafka Logging
-
->**Prerequisite:** You must have a Kafka server configured.
-
-1. Browse to the cluster or project that you want to log.
-{{% accordion id="cluster" label="To Configure Cluster Logging:" %}}
-If you're a [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) who works in operations or security, configure cluster logging.
-
-1. From the **Global** view, open the cluster that you want to configure logging for.
-
-1. From the main menu, select **Tools > Logging**.
-{{% /accordion %}}
-{{% accordion id="project" label="To Configure Project Logging:" %}}
-If you're a [project owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) who works on an application, configure project logging.
-
-1. From the **Global** view, open the project that you want to configure logging for.
-
-1. From the main menu, select **Resources > Logging**.
-{{% /accordion %}}
-
-1. Select **Kafka**.
-
-1. Complete the **Kafka Configuration** form.
-
- 1. From **Endpoint Type**, select the type of Kafka server you are using: **Zookeeper** or **Broker**.
-
- 1. From the **Endpoint** field, enter the IP address and port for your Kafka server.
-
- By default, Kafka uses port `9092`.
-
- 1. From the **Topic** field, enter the name of a Kafka [topic](https://kafka.apache.org/documentation/#basic_ops_add_topic) that your Kubernetes cluster submits logs to.
-
-1. Complete the **Additional Logging Configuration** form.
-
- 1. **Optional:** Use the **Add Field** button to add custom log fields to your logging configuration. These fields are key value pairs (such as `foo=bar`) that you can use to filter the logs from another system.
-
- 1. Enter a **Flush Interval**. This value determines how often [Fluentd](https://www.fluentd.org/) flushes logs to the logging server. Intervals are measured in seconds.
-
-1. Click **Save**.
-
-**Result:** Rancher is now configured to send logs to Kafka. View your Kafka stream to view logs for your cluster and containers.
diff --git a/content/rancher/v2.x/en/tools/logging/splunk/_index.md b/content/rancher/v2.x/en/tools/logging/splunk/_index.md
deleted file mode 100755
index 42976bb3134..00000000000
--- a/content/rancher/v2.x/en/tools/logging/splunk/_index.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: Splunk
-weight: 300
-aliases:
- - /rancher/v2.x/en/tasks/logging/splunk/
----
-
-If your organization uses [Splunk](https://www.splunk.com/), you can configure Rancher to send it cluster or project logs. Afterwards logs are sent, you can use Splunk to view them.
-
-## Configuring Splunk Logging
-
-You can configure Rancher to send Kubernetes logs to your instance of Splunk.
-
->**Prerequisites:**
->
->- Configure HTTP event collection for your Splunk Server (Splunk Enterprise or Splunk Cloud).
->- Enable all tokens, and then create a new token.
->
->For more information, see [Splunk Documentation](http://docs.splunk.com/Documentation/Splunk/7.1.2/Data/UsetheHTTPEventCollector#About_Event_Collector_tokens).
-
-1. Browse to the cluster or project that you want to log.
-{{% accordion id="cluster" label="To Configure Cluster Logging:" %}}
-If you're a [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) who works in operations or security, configure cluster logging.
-
-1. From the **Global** view, open the cluster that you want to configure logging for.
-
-1. From the main menu, select **Tools > Logging**.
-{{% /accordion %}}
-{{% accordion id="project" label="To Configure Project Logging:" %}}
-If you're a [project owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) who works on an application, configure project logging.
-
-1. From the **Global** view, open the project that you want to configure logging for.
-
-1. From the main menu, select **Resources > Logging**.
-{{% /accordion %}}
-
-1. Select **Splunk**.
-
-1. Complete the **Splunk HTTP Event Collector Configuration** form.
-
- 1. From the **Endpoint** field, enter the IP address and port for you Splunk instance (i.e. `http://splunk-server:8088`)
-
- Splunk usually uses port `8088`. If you're using Splunk Cloud, you'll need to work with [Splunk support](https://www.splunk.com/en_us/support-and-services.html) to get an endpoint URL.
-
- 1. Enter the **Token** you obtained while completing the prerequisites (i.e., when you created a token in Splunk).
-
- 1. From the **Source** field, enter the name of the token as entered in Splunk.
-
- 1. **Optional:** Enter one or more [index](http://docs.splunk.com/Documentation/Splunk/7.1.2/Indexer/Aboutindexesandindexers) that's allowed for your token.
-
-1. Complete the **Additional Logging Configuration** form.
-
- 1. **Optional:** Use the **Add Field** button to add custom log fields to your logging configuration. These fields are key value pairs (such as `foo=bar`) that you can use to filter the logs from another system.
-
- 1. Enter a **Flush Interval**. This value determines how often [Fluentd](https://www.fluentd.org/) flushes event data to the logging server. Intervals are measured in seconds.
-
-1. Click **Save**.
-
-**Result:** Rancher is now configured to send logs to Splunk. Log into your Spunk instance to view events for your cluster and containers.
-
-## Viewing Logs
-
-1. Log into your Splunk server.
-
-1. Click on **Search & Reporting**. The number of **Indexed Events** listed should be increasing.
-
-1. Click on Data Summary and select the Sources tab.
- 
-
-1. To view the actual logs, click on the source that you declared earlier.
- 
-
-## Troubleshooting
-
-You can use curl to see if **HEC** is listening for HTTP event data.
-
-```
-$ curl http://splunk-server:8088/services/collector/event \
- -H 'Authorization: Splunk 8da70994-b1b0-4a79-b154-bfaae8f93432' \
- -d '{"event": "hello world"}'
-```
-
-If Splunk is configured correctly, you should receive **json** data returning `success code 0`. You should be able
-to send logging data to HEC.
-
-If you received an error, check your configuration in Splunk and Rancher.
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/tools/logging/syslog/_index.md b/content/rancher/v2.x/en/tools/logging/syslog/_index.md
deleted file mode 100644
index 9bea75a6451..00000000000
--- a/content/rancher/v2.x/en/tools/logging/syslog/_index.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Syslog
-weight: 500
----
-
-You can configure Rancher to send Kubernetes logs to a [Syslog](https://tools.ietf.org/html/rfc5424) server.
-
-## Configuring Syslog
-
-You can configure Rancher to send cluster or project logs to Syslog.
-
->**Prerequisite:** You must have a Syslog server configured.
-
-1. Browse to the cluster or project that you want to log.
-{{% accordion id="cluster" label="To Configure Cluster Logging:" %}}
-If you're a [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) who works in operations or security, configure cluster logging.
-
-1. From the **Global** view, open the cluster that you want to configure logging for.
-
-1. From the main menu, select **Tools > Logging**.
-
-{{% /accordion %}}
-{{% accordion id="project" label="To Configure Project Logging:" %}}
-If you're a [project owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) who works on an application, configure project logging.
-
-1. From the **Global** view, open the project that you want to configure logging for.
-
-1. From the main menu, select **Resources > Logging**.
-
-{{% /accordion %}}
-
-1. Select **Syslog**.
-
-1. Complete the **Syslog Configuration** form.
-
- 1. From the **Endpoint** field, enter the IP address and port for your Syslog server. Additionally, select the protocol that your Syslog server uses from the drop-down.
-
- 1. From the **Program** field, enter the name of the application sending logs to your Syslog server (i.e., Rancher).
-
- 1. If you are using a cloud logging service (i.e., [Sumologic](https://www.sumologic.com/)), enter a **Token** that authenticates with your Syslog server. Use the cloud logging service to create this token.
-
- 1. Select a **Log Severity** for events that are logged to the Syslog server. For more information on each severity level, see the [Syslog protocol documentation](https://tools.ietf.org/html/rfc5424#page-11).
-
-1. If your Syslog server uses **TCP** protocol, complete the **SSL Configuration** form.
-
- 1. Enter a private key and client certificate. Either copy and paste them or browse to them using **Read from a file**. This certificate will be installed on your logging server.
-
- You can use either a self-signed certificate or one provided by a certificate authority.
-
- You can generate a self-signed certificate 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. If you are using a certificate from a certificate authority (and not a self-signed certificate), select the **Enabled - Input trusted server certificate** option and then enter your **Trusted Server Certificate**.
-
-1. Complete the **Additional Logging Configuration** form.
-
- 1. **Optional:** Use the **Add Field** button to add custom log fields to your logging configuration. These fields are key value pairs (such as `foo=bar`) that you can use to filter the logs from another system.
-
- 1. Enter a **Flush Interval**. This value determines how often [Fluentd](https://www.fluentd.org/) flushes data to the logging server. Intervals are measured in seconds.
-
-1. Click **Save**.
-
-**Result:** Rancher is now configured to send logs to your Syslog server. View your Syslog stream to view logs for your cluster and containers.
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md b/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md
deleted file mode 100644
index 6734957bb7f..00000000000
--- a/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md
+++ /dev/null
@@ -1,300 +0,0 @@
----
-title: Alerts and Notifiers
-weight: 5010
----
-
-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
-
-Before you can receive [alerts](#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.
-
-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.
-
-
-
-### 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: `#`.
-
- 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 successful, 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).
-
-
-
-### 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
-
-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.
-
-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.
-
-### Cluster Alerts vs. Project Alerts
-
-At the [cluster level](#adding-cluster-alerts), Rancher monitors components in your Kubernetes cluster, and sends you alerts related to:
-
-- 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 status
-* Pod status
-
-
-
-#### 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
-
-
- 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
-
-
- 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
-
-
- 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
-
-
- 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 `` times with the last `` 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
diff --git a/content/rancher/v2.x/en/tools/pipelines/_index.md b/content/rancher/v2.x/en/tools/pipelines/_index.md
deleted file mode 100644
index ef9e83664ae..00000000000
--- a/content/rancher/v2.x/en/tools/pipelines/_index.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: Pipelines
-weight: 5005
-aliases:
- - /rancher/v2.x/en/concepts/ci-cd-pipelines/
- - /rancher/v2.x/en/tasks/pipelines/
----
->**Notes:**
->
->- Pipelines are new and improved for Rancher v2.1! Therefore, if you configured pipelines while using v2.0.x, you'll have to reconfigure them after upgrading to v2.1.
->- Still using v2.0.x? See the pipeline documentation for [previous versions]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x).
-
-A _pipeline_ is a software delivery process that is broken into different stages, allowing developers to deliver new software as quickly and efficiently as possible. Within Rancher, you can configure a pipeline for each of your Rancher projects.
-
-The pipeline stages are:
-
-- **Build:**
-
- Each time code is checked into your repository, the pipeline automatically clones the repo and builds a new iteration of your software. Throughout this process, the software is typically reviewed by automated tests.
-
-- **Publish:**
-
- After each build is completed, it's automatically published to a Docker registry, where it can be pulled for manual testing.
-
-- **Deploy:**
-
- A natural extension of the publish stage, the deploy stage lets you release your software to customers with the click of a button.
-
-
-## Overview
-
-Rancher Pipeline provides a simple CI/CD experience. Use it to automatically checkout code, run builds, perform tests, publish docker images, and deploy Kubernetes resources to your clusters.
-
-You can configure a pipeline for each project in Rancher. Every project can have individual configurations and setups.
-
-Pipelines are represented as pipeline files that are checked into source code repositories. Users can read and edit the pipeline configuration by either:
-
-- Using the Rancher UI.
-- Updating the configuration in the repository, using tools like Git CLI to trigger a build with the latest CI definition.
-
->**Note:** Rancher Pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses.
-
-## Supported Version Control Platforms
-
-Rancher pipelines currently supports GitHub and GitLab (available as of Rancher v2.1.0).
-
->**Note:** Additions to pipelines are scoped for future releases of Rancher, such as:
->
->- Additional version control systems such as BitBucket
->- Deployment via Helm charts
->- Deployment via Rancher catalog
-
-
-## How Pipelines Work
-
-When you configure a pipeline in one of your projects, a namespace specifically for the pipeline is automatically created. The following components are deployed to it:
-
- - **Jenkins:**
-
- The pipeline's build engine. Because project users do not directly interact with Jenkins, it's managed and locked.
-
- >**Note:** There is no option to use existing Jenkins deployments as the pipeline engine.
-
-
-
- - **Docker Registry:**
-
- Out-of-the-box, the default target for your build-publish step is an internal Docker Registry. However, you can make configurations to push to a remote registry instead. The internal Docker Registry is only accessible from cluster nodes and cannot be directly accessed by users. Images are not persisted beyond the lifetime of the pipeline and should only be used in pipeline runs. If you need to access your images outside of pipeline runs, please push to an external registry.
-
-
-
- - **Minio:**
-
- Minio storage is used to store the logs for pipeline executions.
-
- >**Note:** The managed Jenkins instance works statelessly, so don't worry about its data persistency. The Docker Registry and Minio instances use ephemeral volumes by default, which is fine for most use cases. If you want to make sure pipeline logs can survive node failures, you can configure persistent volumes for them, as described in [data persistency for pipeline components]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/configurations/#data-persistency-for-pipeline-components).
-
-
-## Pipeline Triggers
-
-After you configure a pipeline, you can trigger it using different methods:
-
-
-- **Manually:**
-
- After you configure a pipeline, you can trigger a build using the latest CI definition from either Rancher UI or Git CLI. When a pipeline execution is triggered, Rancher dynamically provisions a Kubernetes pod to run your CI tasks and then remove it upon completion.
-
-- **Automatically:**
-
- When you enable a repository for a pipeline, webhooks are automatically added to the version control system. When project users interact with the repo—push code, open pull requests, or create a tag—the version control system sends a webhook to Rancher Server, triggering a pipeline execution.
-
- To use this automation, webhook management permission is required for the repo. Therefore, when users authenticate and fetch their repositories, only those on which they have admin permission will be shown.
diff --git a/content/rancher/v2.x/en/tools/pipelines/concepts/_index.md b/content/rancher/v2.x/en/tools/pipelines/concepts/_index.md
deleted file mode 100644
index 4c2d65e3c23..00000000000
--- a/content/rancher/v2.x/en/tools/pipelines/concepts/_index.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Pipeline Terminology
-weight: 1000
----
-
-When setting up a pipeline, it's helpful to know a few related terms.
-
-- **Pipeline:**
-
- A pipeline consists of stages and steps. It defines the process to build, test, and deploy your code. Rancher pipeline uses the [pipeline as code](https://jenkins.io/doc/book/pipeline-as-code/) model—pipeline configuration is represented as a pipeline file in the source code repository, using the file name `.rancher-pipeline.yml` or `.rancher-pipeline.yaml`.
-
-- **Stages:**
-
- A pipeline stage consists of multiple steps. Stages are executed in the order defined in the pipeline file. The steps in a stage are executed concurrently. A stage starts when all steps in the former stage finish without failure.
-
-- **Steps:**
-
- A pipeline step is executed inside a specified stage. A step fails if it exits with a code other than `0`. If a step exits with this failure code, the entire pipeline fails and terminates.
-
-- **Workspace:**
-
- The workspace is the working directory shared by all pipeline steps. In the beginning of a pipeline, source code is checked out to the workspace. The command for every step bootstraps in the workspace. During a pipeline execution, the artifacts from a previous step will be available in future steps. The working directory is an ephemeral volume and will be cleaned out with the executor pod when a pipeline execution is finished.
diff --git a/content/rancher/v2.x/en/tools/pipelines/configurations/_index.md b/content/rancher/v2.x/en/tools/pipelines/configurations/_index.md
deleted file mode 100644
index 5b0fe697b1d..00000000000
--- a/content/rancher/v2.x/en/tools/pipelines/configurations/_index.md
+++ /dev/null
@@ -1,595 +0,0 @@
----
-title: Configuring Pipelines
-weight: 3725
----
-
-Configuring a pipeline automates the process of triggering and publishing builds. This section describes how to set up a pipeline in a production environment.
-
-- The [Basic Configuration](#basic-configuration) section provides sequential instruction on how to configure a functional pipeline.
-- The [Advanced Configuration](#advanced-configuration) section provides instructions for configuring pipeline options.
-
-## Basic Configuration
-
-To configure a functional pipeline for your project, begin by completing the mandatory basic configuration steps.
-
-### Pipeline Configuration Outline
-
-Initial configuration of a pipeline in a production environment involves completion of several mandatory procedures.
-
->**Note:** Before setting up a pipeline for a production environment, we recommend trying the [Pipeline Quick Start Guide]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/quick-start-guide).
-
-
-
-- [1. Configuring Version Control Providers](#1-configuring-version-control-providers)
-- [2. Configuring Pipeline Stages and Steps](#2-configuring-pipeline-stages-and-steps)
-- [3. Running the Pipeline](#3-running-the-pipeline)
-- [4. Configuring Persistent Data for Pipeline Components](#4-configuring-persistent-data-for-pipeline-components)
-- [Advanced Configuration](#advanced-configuration)
-
-
-
-
-### 1. Configuring Version Control Providers
-
-Begin configuration of your pipeline by enabling authentication with your version control provider. Rancher Pipeline supports integration with GitHub and GitLab.
-
-Select your provider's tab below and follow the directions.
-
-{{% tabs %}}
-{{% tab "GitHub" %}}
-1. From the context menu, open the project for which you're configuring a pipeline.
-
-1. From the main menu, select **Resources > Pipelines**.
-
-1. Follow the directions displayed to setup an OAuth application in GitHub.
-
- 
-
-1. From GitHub, copy the **Client ID** and **Client Secret**. Paste them into Rancher.
-
-1. If you're using GitHub for enterprise, select **Use a private github enterprise installation**. Enter the host address of your GitHub installation.
-
-1. Click **Authenticate**.
-
-1. Enable the repository for which you want to run a pipeline. Then click **Done**.
-
-{{% /tab %}}
-{{% tab "GitLab" %}}
-1. From the context menu, open the project for which you're configuring a pipeline.
-
-1. From the main menu, select **Resources > Pipelines**.
-
-1. Follow the directions displayed to setup a GitLab application.
-
- 
-
-1. From GitLab, copy the **Application ID** and **Secret**. Paste them into Rancher.
-
-1. If you're using GitLab for enterprise setup, select **Use a private gitlab enterprise installation**. Enter the host address of your GitLab installation.
-
-1. Click **Authenticate**.
-
-1. Enable the repository for which you want to run a pipeline. Then click **Done**.
-
->**Note:**
-> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
-> 2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
-{{% /tab %}}
-{{% /tabs %}}
-
-**Result:** A pipeline is added to the project.
-
-
-
-
-
-
-
-### 2. Configuring Pipeline Stages and Steps
-
-Now that the pipeline is added to your project, you need to configure its automated stages and steps. For your convenience, there are multiple built-in step types for dedicated tasks.
-
-1. From your project's **Pipeline** tab, find your new pipeline, and select **Ellipsis (...) > Edit Config**.
-
- >**Note:** When configuring a pipeline, it takes a few moments for Rancher to check for an existing pipeline configuration.
-
-1. Click **Configure pipeline for this branch**.
-
-1. Add stages to your pipeline execution by clicking **Add Stage**.
-
-1. Add steps to each stage by clicking **Add a Step**. You can add multiple steps to each stage.
-
- >**Note:** As you build out each stage and step, click `Show advanced options` to make [Advanced Configurations](#advanced-configuration), such as rules to trigger or skip pipeline actions, add environment variables, or inject environment variables using secrets. Advanced options are available the pipeline, each stage, and each individual step.
-
- **Step types available include:**
-
- {{% accordion id="clone" label="Clone" %}}
-
-The first stage is preserved to be a cloning step that checks out source code from your repo. Rancher handles the cloning of the git repository. This action is equivalent to `git clone `.
-
- {{% /accordion %}}
- {{% accordion id="run-script" label="Run Script" %}}
-
-The **Run Script** step executes arbitrary commands in the workspace inside a specified container. You can use it to build, test and do more, given whatever utilities the base image provides. For your convenience you can use variables to refer to metadata of a pipeline execution. Please go to the [Pipeline Variable Reference]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/reference/#variable-substitution) for the list of available variables.
-
-{{% tabs %}}
-
-{{% tab "By UI" %}}
-
-
-1. From the **Step Type** drop-down, choose **Run Script** and fill in the form.
-
-1. Click **Add**.
-
-{{% /tab %}}
-
-{{% tab "By YAML" %}}
-
-```yaml
-# example
-stages:
-- name: Build something
- steps:
- - runScriptConfig:
- image: golang
- shellScript: go build
-```
-{{% /tab %}}
-
-{{% /tabs %}}
-
-{{% /accordion %}}
-{{% accordion id="build-publish-image" label="Build and Publish Images" %}}
-
-The **Build and Publish Image** step builds and publishes a Docker image. This process requires a Dockerfile in your source code's repository to complete successfully.
-
-{{% tabs %}}
-
-{{% tab "By UI" %}}
-1. From the **Step Type** drop-down, choose **Build and Publish**.
-
-1. Fill in the rest of the form. Descriptions for each field are listed below. When you're done, click **Add**.
-
- Field | Description |
- ---------|----------|
- Dockerfile Path | The relative path to the Dockerfile in the source code repo. By default, this path is `./Dockerfile`, which assumes the Dockerfile is in the root directory. You can set it to other paths in different use cases (`./path/to/myDockerfile` for example). |
- Image Name | The image name in `name:tag` format. The registry address is not required. For example, to build `example.com/repo/my-image:dev`, enter `repo/my-image:dev`. |
- Push image to remote repository | An option to set the registry that publishes the image that's built. To use this option, enable it and choose a registry from the drop-down. If this option is disabled, the image is pushed to the internal registry. |
- Build Context
(**Show advanced options**)| By default, the root directory of the source code (`.`). For more details, see the Docker [build command documentation](https://docs.docker.com/engine/reference/commandline/build/).
-
-{{% /tab %}}
-
-{{% tab "By YAML" %}}
-```yaml
-# example
-stages:
-- name: Publish Image
- steps:
- - publishImageConfig:
- dockerfilePath: ./Dockerfile
- buildContext: .
- tag: repo/app:v1
- pushRemote: true
- registry: example.com
-```
-
-You can use specific arguments for Docker daemon and the build. They are not exposed in the UI, but they are available in pipeline YAML format, as indicated in the example above. Available variables includes:
-
-Variable Name | Description
-------------------------|------------------------------------------------------------
-PLUGIN_DRY_RUN | Disable docker push
-PLUGIN_DEBUG | Docker daemon executes in debug mode
-PLUGIN_MIRROR | Docker daemon registry mirror
-PLUGIN_INSECURE | Docker daemon allows insecure registries
-PLUGIN_BUILD_ARGS | Docker build args, a comma separated list
-
-{{% /tab %}}
-
-{{% /tabs %}}
-
-{{% /accordion %}}
-{{% accordion id="deploy-yaml" label="Deploy YAML" %}}
-
-This step deploys arbitrary Kubernetes resources to the project. This deployment requires a Kubernetes manifest file to be present in the source code repository. Pipeline variable substitution is supported in the manifest file. You can view an example file at [GitHub](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml). For available variables, refer to [Pipeline Variable Reference]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/reference/).
-
-{{% tabs %}}
-
-{{% tab "By UI" %}}
-
-1. From the **Step Type** drop-down, choose **Deploy YAML** and fill in the form.
-
-1. Enter the **YAML Path**, which is the path to the manifest file in the source code.
-
-1. Click **Add**.
-
-{{% /tab %}}
-
-{{% tab "By YAML" %}}
-
-```yaml
-# example
-stages:
-- name: Deploy
- steps:
- - applyYamlConfig:
- path: ./deployment.yaml
-```
-
-{{% /tab %}}
-
-{{% /tabs %}}
-
-{{% /accordion %}}
-
-1. When you're finished adding stages and steps, click **Done.**
-
-### 3. Running the Pipeline
-
-Run your pipeline for the first time. From the **Pipeline** tab, find your pipeline and select **Ellipsis (...) > Run**.
-
-During this initial run, your pipeline is tested, and the following [pipeline components]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/) are deployed to your project as workloads in a new namespace dedicated to the pipeline:
-
-- `docker-registry`
-- `jenkins`
-- `minio`
-
-This process takes several minutes. When it completes, you can view each pipeline component from the project **Workloads** tab.
-
-### 4. Configuring Persistent Data for Pipeline Components
-
-The internal [Docker registry]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#reg) and the [Minio]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#minio) workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.
-
-Complete both [A—Configuring Persistent Data for Docker Registry](#a—configuring-persistent-data-for-docker-registry) _and_ [B—Configuring Persistent Data for Minio](#b—configuring-persistent-data-for-minio).
-
->**Prerequisites (for both parts A and B):**
->
->[Persistent volumes]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#persistent-volumes) must be available for the cluster.
-
-#### A. Configuring Persistent Data for Docker Registry
-
-
-1. From the project that you're configuring a pipeline for, select the **Workloads** tab.
-
-1. Find the `docker-registry` workload and select **Ellipsis (...) > Edit**.
-
-1. Scroll to the **Volumes** section and expand it. Make one of the following selections from the **Add Volume** menu, which is near the bottom of the section:
-
- - **Add Volume > Add a new persistent volume (claim)**
- - **Add Volume > Use an existing persistent volume (claim)**
-
-1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
-{{% tabs %}}
-
-{{% tab "Add a new persistent volume" %}}
-
-1. Enter a **Name** for the volume claim.
-
-1. Select a volume claim **Source**:
-
- - If you select **Use a Storage Class to provision a new persistent volume**, select a [Storage Class]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#storage-classes) and enter a **Capacity**.
-
- - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
-1. From the **Customize** section, choose the read/write access for the volume.
-
-1. Click **Define**.
-
-{{% /tab %}}
-
-{{% tab "Use an existing persistent volume" %}}
-
-1. Enter a **Name** for the volume claim.
-
-1. Choose a **Persistent Volume Claim** from the drop-down.
-
-1. From the **Customize** section, choose the read/write access for the volume.
-
-1. Click **Define**.
-
-{{% /tab %}}
-
-{{% /tabs %}}
-
-1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container.
-
-1. Click **Upgrade**.
-
-#### B. Configuring Persistent Data for Minio
-
-
-1. From the **Workloads** tab, find the `minio` workload and select **Ellipsis (...) > Edit**.
-
-1. Scroll to the **Volumes** section and expand it. Make one of the following selections from the **Add Volume** menu, which is near the bottom of the section:
-
- - **Add Volume > Add a new persistent volume (claim)**
- - **Add Volume > Use an existing persistent volume (claim)**
-
-1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
-{{% tabs %}}
-
-{{% tab "Add a new persistent volume" %}}
-
-1. Enter a **Name** for the volume claim.
-
-1. Select a volume claim **Source**:
-
- - If you select **Use a Storage Class to provision a new persistent volume**, select a [Storage Class]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#storage-classes) and enter a **Capacity**.
-
- - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
-1. From the **Customize** section, choose the read/write access for the volume.
-
-1. Click **Define**.
-
-{{% /tab %}}
-
-{{% tab "Use an existing persistent volume" %}}
-
-1. Enter a **Name** for the volume claim.
-
-1. Choose a **Persistent Volume Claim** from the drop-down.
-
-1. From the **Customize** section, choose the read/write access for the volume.
-
-1. Click **Define**.
-
-{{% /tab %}}
-
-{{% /tabs %}}
-
-1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container.
-
-1. Click **Upgrade**.
-
-**Result:** Persistent storage is configured for your pipeline components.
-
-
-## Advanced Configuration
-
-During the process of configuring a pipeline, you can configure advanced options for triggering the pipeline or configuring environment variables.
-
-- [Configuring Pipeline Trigger Rules](#configuring-pipeline-trigger-rules)
-- [Configuring Timeouts](#configuring-timeouts)
-- [Configuring Environment Variables](#configuring-environment-variables)
-- [Configuring Pipeline Secrets](#configuring-pipeline-secrets)
-- [Configuring the Executor Quota](#configuring-the-executor-quota)
-
-### Configuring Pipeline Trigger Rules
-
-When a repository is enabled, a webhook for it is automatically set in the version control system. By default, the project pipeline is triggered by a push event to a specific repository, but you can add (or change) events that trigger a build, such as a pull request or a tagging.
-
-Trigger rules come in two types:
-
-- **Run this when:**
-
- This type of rule starts the pipeline, stage, or step when a trigger explicitly occurs.
-
-- **Do Not Run this when:**
-
- If all conditions evaluate to true, then the pipeline/stage/step is executed. Otherwise it is skipped. When a stage/step is skipped, it is considered successful and follow-up stages/steps continue to run. Wildcard character (`*`) expansion is supported in conditions.
-
-
-{{% tabs %}}
-{{% tab "Pipeline Trigger" %}}
-
-You can configure trigger rules for the entire pipeline in two different contexts:
-
-{{% accordion id="pipeline-creation" label="During Initial Pipeline Configuration" %}}
-
-
-1. From the context menu, open the project for which you've configured a pipeline. Then select the **Pipelines** tab.
-
-1. From the pipeline for which you want to edit build triggers, select **Ellipsis (...) > Edit Config**.
-
-1. Click **Show advanced options**.
-
-1. From **Trigger Rules**, configure rules to run or skip the pipeline.
-
- 1. Click **Add Rule**. In the **Value** field, enter the name of the branch that triggers the pipeline.
-
- 1. **Optional:** Add more branches that trigger a build.
-{{% /accordion %}}
-
-{{% accordion id="pipeline-settings" label="While Editing Pipeline Settings" %}}
-
-After you've configured a pipeline, you can go back and choose the events that trigger a pipeline execution.
-
->**Note:** This option is not available for example repositories.
-
-1. From the context menu, open the project for which you've configured a pipeline. Then select the **Pipelines** tab.
-
-1. From the pipeline for which you want to edit build triggers, select **Ellipsis (...) > Setting**.
-
-1. Select (or clear) the events that you want to trigger a pipeline execution.
-
-1. Click **Save**.
-{{% /accordion %}}
-
-{{% /tab %}}
-{{% tab "Stage Trigger" %}}
-1. From the context menu, open the project for which you've configured a pipeline. Then select the **Pipelines** tab.
-
-1. From the pipeline for which you want to edit triggers, select **Ellipsis (...) > Edit Config**.
-
-1. From the pipeline stage that you want to configure a trigger for, click the **Edit** icon.
-
-1. Click **Show advanced options**.
-
-1. Add one or more trigger rules.
-
- 1. Click **Add Rule**.
-
- 1. Choose the **Type** that triggers the stage.
-
- | Type | Value |
- | ------ | -------------------------------------------------------------------- |
- | Branch | The name of the branch that triggers the stage. |
- | Event | The type of event that triggers the stage (Push, Pull Request, Tag). |
-
-1. Click **Save**.
-{{% /tab %}}
-{{% tab "Step Trigger" %}}
-1. From the context menu, open the project for which you've configured a pipeline. Then select the **Pipelines** tab.
-
-1. From the pipeline for which you want to edit triggers, select **Ellipsis (...) > Edit Config**.
-
-1. From the pipeline step that you want to configure a trigger for, click the **Edit** icon.
-
-1. Click **Show advanced options**.
-
-1. Add one or more trigger rules.
-
- 1. Click **Add Rule**.
-
- 1. Choose the **Type** that triggers the step.
-
- | Type | Value |
- | ------ | -------------------------------------------------------------------- |
- | Branch | The name of the branch that triggers the stage. |
- | Event | The type of event that triggers the stage (Push, Pull Request, Tag). |
-
-1. Click **Save**.
-{{% /tab %}}
-{{% tab "Do Not Run YAML" %}}
-```yaml
-# example
-stages:
- - name: Build something
- # Conditions for stages
- when:
- branch: master
- event: [ push, pull_request ]
- # Multiple steps run concurrently
- steps:
- - runScriptConfig:
- image: busybox
- shellScript: date -R
- # Conditions for steps
- when:
- branch: [ master, dev ]
- event: push
-# branch conditions for the pipeline
-branch:
- include: [ master, feature/*]
- exlclude: [ dev ]
-```
-{{% /tab %}}
-{{% /tabs %}}
-
-### Configuring Timeouts
-
-Each pipeline execution has a default timeout of 60 minutes. If the pipeline execution cannot complete within its timeout period, the pipeline is aborted. If a pipeline has more executions than can be completed in 60 minutes,
-
-{{% tabs %}}
-{{% tab "By UI" %}}
-1. From the context menu, open the project for which you've configured a pipeline. Then select the **Pipelines** tab.
-
-1. From the pipeline for which you want to edit the timeout, select **Ellipsis (...) > Edit Config**.
-
-1. Click **Show advanced options**.
-
-1. Enter a new value in the **Timeout** field.
-
-{{% /tab %}}
-{{% tab "By YAML" %}}
-```yaml
-# example
-stages:
- - name: Build something
- steps:
- - runScriptConfig:
- image: busybox
- shellScript: ls
-timeout: 30
-```
-{{% /tab %}}
-{{% /tabs %}}
-
-
-### Configuring Environment Variables
-
-When configuring a pipeline, you can use environment variables to configure the step's script.
-
-{{% tabs %}}
-{{% tab "By UI" %}}
-1. From the context menu, open the project for which you've configured a pipeline. Then select the **Pipelines** tab.
-
-1. From the pipeline in which you want to use environment variables, select **Ellipsis (...) > Edit Config**.
-
-1. Click the **Edit** icon for the step in which you want to use environment variables.
-
-1. Click **Show advanced options**.
-
-1. Click **Add Variable**, and then enter a key and value in the fields that appear. Add more variables if needed.
-
-1. Edit the script, adding your environment variable(s).
-
-1. Click **Save**.
-
-{{% /tab %}}
-
-{{% tab "By YAML" %}}
-```yaml
-# example
-stages:
- - name: Build something
- steps:
- - runScriptConfig:
- image: busybox
- shellScript: echo ${FIRST_KEY} && echo ${SECOND_KEY}
- env:
- FIRST_KEY: VALUE
- SECOND_KEY: VALUE2
-```
-{{% /tab %}}
-
-{{% /tabs %}}
-
-### Configuring Pipeline Secrets
-
-If you need to use security-sensitive information in your pipeline scripts (like a password), you can pass them in using Kubernetes [secrets]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/secrets/).
-
->**Prerequisite:** Create a secret for your project for use in pipelines.
-
->**Note:** Secret injection is disabled on pull request events.
-
-{{% tabs %}}
-{{% tab "By UI" %}}
-1. From the context menu, open the project for which you've configured a pipeline. Then select the **Pipelines** tab.
-
-1. From the pipeline in which you want to use environment variables, select **Ellipsis (...) > Edit Config**.
-
-1. Click the **Edit** icon for the step in which you want to use environment variables.
-
-1. Click **Show advanced options**.
-
-1. Click **Add From Secret**. Select the secret file that you want to use. Then choose a key. Optionally, you can enter an alias for the key.
-
-1. Click **Save**.
-
-{{% /tab %}}
-{{% tab "By YAML" %}}
-```yaml
-# example
-stages:
- - name: Build something
- steps:
- - runScriptConfig:
- image: busybox
- shellScript: echo ${ALIAS_ENV}
- # environment variables from project secrets
- envFrom:
- - sourceName: my-secret
- sourceKey: secret-key
- targetKey: ALIAS_ENV
-```
-{{% /tab %}}
-{{% /tabs %}}
-
-### Configuring the Executor Quota
-
-The _executor quota_ decides how many builds can run simultaneously in the project. If the number of triggered builds exceeds the quota, subsequent builds will queue until a vacancy opens. By default, the quota is `2`, but you can change it.
-
-1. From the context menu, open the project for which you've configured a pipeline.
-
-1. From the main menu, select **Resources > Pipelines**.
-
-1. From `The maximum number of pipeline executors` increment the **Scale** up or down to change the quota. A value of `0` or less removes the quota limit.
diff --git a/content/rancher/v2.x/en/tools/pipelines/quick-start-guide/_index.md b/content/rancher/v2.x/en/tools/pipelines/quick-start-guide/_index.md
deleted file mode 100644
index c23356ac307..00000000000
--- a/content/rancher/v2.x/en/tools/pipelines/quick-start-guide/_index.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Pipelines Quick Start Guide
-weight: 500
----
-
-Rancher ships with several example repositories that you can use to familiarize yourself with pipelines. We recommend configuring and testing the example repository that most resembles your environment before using pipelines with your own repositories in a production environment. Use this example repository as a sandbox for repo configuration, build demonstration, etc. Rancher includes example repositories for:
-
-- Go
-- Maven
-- php
-
-## 1. Configure Repositories
-
-By default, the example pipeline repositories are disabled. Enable one (or more) to test out the pipeline feature and see how it works.
-
-1. From the context menu, open the project for which you want to run a pipeline.
-
-1. From the main menu, select **Workloads**. Then select the **Pipelines** tab.
-
-1. Click **Configure Repositories**.
-
- **Step Result:** A list of example repositories displays.
-
- >**Note:** Example repositories only display if you haven't fetched your own repos.
-
-1. Click **Enable** for one of the example repos (e.g., `https://github.com/rancher/pipeline-example-go.git`). Then click **Done**.
-
-**Results:**
-
-- A pipeline is configured for the example repository, and it's added to the **Pipeline** tab.
-- The following workloads are deployed to a new namespace:
-
- - `docker-registry`
- - `jenkins`
- - `minio`
-
-## 2. Run Example Pipeline
-
-After configuring an example repository, run the pipeline to see how it works.
-
-1. From the **Pipelines** tab, select **Ellipsis (...) > Run**.
-
- >**Note:** When you run a pipeline the first time, it takes a few minutes to pull relevant images and provision necessary pipeline components.
- To understand what the example pipeline is doing, select `Ellipsis (...) > Edit Config` for your repo. Alternatively, view the `.rancher-pipeline.yml` file in the example repositories.
-
-**Result:** The pipeline runs. You can see the results in the logs.
-
-## What's Next?
-
-For detailed information about setting up a pipeline in production, see the [Configuring Pipelines]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/configurations/).
diff --git a/content/rancher/v2.x/en/tools/pipelines/reference/_index.md b/content/rancher/v2.x/en/tools/pipelines/reference/_index.md
deleted file mode 100644
index 54fb70dd065..00000000000
--- a/content/rancher/v2.x/en/tools/pipelines/reference/_index.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: Pipeline Variable Reference
-weight: 8000
----
-
-For your convenience, the following variables are available for your pipeline configuration scripts. During pipeline executions, these variables are replaced by metadata. You can reference them in the form of `${VAR_NAME}`.
-
-Variable Name | Description
-------------------------|------------------------------------------------------------
-`CICD_GIT_REPO_NAME` | Repository name (Github organization omitted).
-`CICD_GIT_URL` | URL of the Git repository.
-`CICD_GIT_COMMIT` | Git commit ID being executed.
-`CICD_GIT_BRANCH` | Git branch of this event.
-`CICD_GIT_REF` | Git reference specification of this event.
-`CICD_GIT_TAG` | Git tag name, set on tag event.
-`CICD_EVENT` | Event that triggered the build (`push`, `pull_request` or `tag`).
-`CICD_PIPELINE_ID` | Rancher ID for the pipeline.
-`CICD_EXECUTION_SEQUENCE` | Build number of the pipeline.
-`CICD_EXECUTION_ID` | Combination of `{CICD_PIPELINE_ID}-{CICD_EXECUTION_SEQUENCE}`.
-`CICD_REGISTRY` | Address for the Docker registry for the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step.
-`CICD_IMAGE` | Name of the image built from the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step. It does not contain the image tag.
[Example](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml)
-
-## Full `.rancher-pipeline.yml` Example
-
-```yaml
-# example
-stages:
- - name: Build something
- # Conditions for stages
- when:
- branch: master
- event: [ push, pull_request ]
- # Multiple steps run concurrently
- steps:
- - runScriptConfig:
- image: busybox
- shellScript: echo ${FIRST_KEY} && echo ${ALIAS_ENV}
- # Set environment variables in container for the step
- env:
- FIRST_KEY: VALUE
- SECOND_KEY: VALUE2
- # Set environment variables from project secrets
- envFrom:
- - sourceName: my-secret
- sourceKey: secret-key
- targetKey: ALIAS_ENV
- - runScriptConfig:
- image: busybox
- shellScript: date -R
- # Conditions for steps
- when:
- branch: [ master, dev ]
- event: push
- - name: Publish my image
- steps:
- - publishImageConfig:
- dockerfilePath: ./Dockerfile
- buildContext: .
- tag: rancher/rancher:v2.0.0
- # Optionally push to remote registry
- pushRemote: true
- registry: reg.example.com
- - name: Deploy some workloads
- steps:
- - applyYamlConfig:
- path: ./deployment.yaml
-# branch conditions for the pipeline
-branch:
- include: [ master, feature/*]
- exclude: [ dev ]
-
-```
diff --git a/content/rancher/v2.x/en/troubleshooting/dns/_index.md b/content/rancher/v2.x/en/troubleshooting/dns/_index.md
index 06c298d626c..431942c9a44 100644
--- a/content/rancher/v2.x/en/troubleshooting/dns/_index.md
+++ b/content/rancher/v2.x/en/troubleshooting/dns/_index.md
@@ -139,3 +139,37 @@ Pod kube-dns-667c7cb9dd-z4dsf on host x.x.x.x
nameserver 1.1.1.1
nameserver 8.8.4.4
```
+
+If the output shows an address in the loopback range (`127.0.0.0/8`), you can correct this in two ways:
+
+* Make sure the correct nameservers are listed in `/etc/resolv.conf` on your nodes in the cluster, please consult your operating system documentation on how to do this. Make sure you execute this before provisioning a cluster, or reboot the nodes after making the modification.
+* Configure the `kubelet` to use a different file for resolving names, by using `extra_args` as shown below (where `/run/resolvconf/resolv.conf` is the file with the correct nameservers):
+
+```
+services:
+ kubelet:
+ extra_args:
+ resolv-conf: "/run/resolvconf/resolv.conf"
+```
+
+> **Note:** As the `kubelet` is running inside a container, the path for files located in `/etc` and `/usr` are in `/host/etc` and `/host/usr` inside the `kubelet` container.
+
+See [Editing Cluster as YAML]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/#editing-cluster-as-yaml) how to apply this change. When the provisioning of the cluster has finished, you have to remove the kube-dns pod to activate the new setting in the pod:
+
+```
+kubectl delete pods -n kube-system -l k8s-app=kube-dns
+pod "kube-dns-5fd74c7488-6pwsf" deleted
+```
+
+Try to resolve name again using [Check if domain names are resolving](#check-if-domain-names-are-resolving).
+
+If you want to check the kube-dns configuration in your cluster (for example, to check if there are different upstream nameservers configured), you can run the following command to list the kube-dns configuration:
+
+```
+kubectl -n kube-system get configmap kube-dns -o go-template='{{range $key, $value := .data}}{{ $key }}{{":"}}{{ $value }}{{"\n"}}{{end}}'
+```
+
+Example output:
+```
+upstreamNameservers:["1.1.1.1"]
+```
diff --git a/content/rancher/v2.x/en/troubleshooting/networking/_index.md b/content/rancher/v2.x/en/troubleshooting/networking/_index.md
index 53e0c0737fe..75173ccd167 100644
--- a/content/rancher/v2.x/en/troubleshooting/networking/_index.md
+++ b/content/rancher/v2.x/en/troubleshooting/networking/_index.md
@@ -77,6 +77,16 @@ NODE1 cannot reach NODE3
Cleanup the alpine DaemonSet by running `kubectl delete ds/overlaytest`.
+### Check if MTU is correctly configured on hosts and on peering/tunnel appliances/devices
+
+When the MTU is incorrectly configured (either on hosts running Rancher, nodes in created/imported clusters or on appliances/devices in between), error messages will be logged in Rancher and in the agents, similar to:
+
+* `websocket: bad handshake`
+* `Failed to connect to proxy`
+* `read tcp: i/o timeout`
+
+See [Google Cloud VPN: MTU Considerations](https://cloud.google.com/vpn/docs/concepts/mtu-considerations#gateway_mtu_vs_system_mtu) for an example how to configure MTU correctly when using Google Cloud VPN between Rancher and cluster nodes.
+
### Resolved issues
#### Overlay network broken when using Canal/Flannel due to missing node annotations
diff --git a/content/rancher/v2.x/en/troubleshooting/rancherha/_index.md b/content/rancher/v2.x/en/troubleshooting/rancherha/_index.md
index 9ef9d9e0d99..5a90616e985 100644
--- a/content/rancher/v2.x/en/troubleshooting/rancherha/_index.md
+++ b/content/rancher/v2.x/en/troubleshooting/rancherha/_index.md
@@ -68,3 +68,13 @@ When accessing your configured Rancher FQDN does not show you the UI, check the
```
kubectl -n ingress-nginx logs -l app=ingress-nginx
```
+
+### Leader election
+
+The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` ConfigMap (in this example, `rancher-7dbd7875f7-qbj5k`).
+
+```
+kubectl -n kube-system get configmap cattle-controllers -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
+{"holderIdentity":"rancher-7dbd7875f7-qbj5k","leaseDurationSeconds":45,"acquireTime":"2019-04-04T11:53:12Z","renewTime":"2019-04-04T12:24:08Z","leaderTransitions":0}
+```
+
diff --git a/content/rancher/v2.x/en/upgrades/rollbacks/_index.md b/content/rancher/v2.x/en/upgrades/rollbacks/_index.md
index d259883a270..19192f8e093 100644
--- a/content/rancher/v2.x/en/upgrades/rollbacks/_index.md
+++ b/content/rancher/v2.x/en/upgrades/rollbacks/_index.md
@@ -32,7 +32,7 @@ Because of the changes necessary to address [CVE-2018-20321](https://cve.mitre.o
2. After executing the command a `tokens.json` file will be created. Important! Back up this file in a safe place.** You will need it to restore functionality to your clusters after rolling back Rancher. **If you lose this file, you may lose access to your clusters.**
-3. Rollback Rancher following the [normal instructions](https://rancher.com/docs/rancher/v2.x/en/upgrades/rollbacks/).
+3. Rollback Rancher following the [normal instructions]({{< baseurl >}}/rancher/v2.x/en/upgrades/rollbacks/).
4. Once Rancher comes back up, every cluster managed by Rancher (except for Imported clusters) will be in an `Unavailable` state.
diff --git a/content/rancher/v2.x/en/upgrades/upgrades/ha-server-upgrade-helm-airgap/_index.md b/content/rancher/v2.x/en/upgrades/upgrades/ha-server-upgrade-helm-airgap/_index.md
index 78c210d6708..9681ef22fed 100644
--- a/content/rancher/v2.x/en/upgrades/upgrades/ha-server-upgrade-helm-airgap/_index.md
+++ b/content/rancher/v2.x/en/upgrades/upgrades/ha-server-upgrade-helm-airgap/_index.md
@@ -24,9 +24,12 @@ The following instructions will guide you through upgrading a high-availability
[Install or update](https://docs.helm.sh/using_helm/#installing-helm) Helm to the latest version.
-- **Upgrades to v2.0.7+ only: check system namespace locations**
+- **Upgrades to v2.0.7+ only: check system namespace locations**
Starting in v2.0.7, Rancher introduced the `system` project, which is a project that's automatically created to store important namespaces that Kubernetes needs to operate. During upgrade to v2.0.7+, Rancher expects these namespaces to be unassigned from all projects. Before beginning upgrade, check your system namespaces to make sure that they're unassigned to [prevent cluster networking issues]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/namespace-migration/#preventing-cluster-networking-issues).
+- **Upgrades to v2.2.0 only: mirror system-charts repository and configure Rancher**
+ Starting in v2.2.0, Rancher introduced the [System Charts](https://github.com/rancher/system-charts) repository which contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. To be able to use these features in an air gap install, you will need to mirror the `system-charts` repository locally and configure Rancher to use that repository. Please follow the instructions to [configure Rancher system charts]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-high-availability/config-rancher-system-charts/).
+
## Caveats
Upgrades _to_ or _from_ any chart in the [rancher-alpha repository]({{< baseurl >}}/rancher/v2.x/en/installation/server-tags/#helm-chart-repositories/) aren't supported.
diff --git a/content/rancher/v2.x/en/upgrades/upgrades/single-node-air-gap-upgrade/_index.md b/content/rancher/v2.x/en/upgrades/upgrades/single-node-air-gap-upgrade/_index.md
index a2cf879b84a..56a210ad6e1 100644
--- a/content/rancher/v2.x/en/upgrades/upgrades/single-node-air-gap-upgrade/_index.md
+++ b/content/rancher/v2.x/en/upgrades/upgrades/single-node-air-gap-upgrade/_index.md
@@ -9,6 +9,8 @@ To upgrade an air gapped Rancher Server, update your private registry with the l
## Prerequisites
**Upgrades to v2.0.7+ only:** Starting in v2.0.7, Rancher introduced the `system` project, which is a project that's automatically created to store important namespaces that Kubernetes needs to operate. During upgrade to v2.0.7+, Rancher expects these namespaces to be unassigned from all projects. Before beginning upgrade, check your system namespaces to make sure that they're unassigned to [prevent cluster networking issues]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/namespace-migration/#preventing-cluster-networking-issues).
+**Upgrades to v2.2.0 only: mirror system-charts repository and configure Rancher**
+Starting in v2.2.0, Rancher introduced the [System Charts](https://github.com/rancher/system-charts) repository which contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. To be able to use these features in an air gap install, you will need to mirror the `system-charts` repository locally and configure Rancher to use that repository. Please follow the instructions to [configure Rancher system charts]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/config-rancher-system-charts/).
## Caveats
Upgrades _to_ or _from_ any tag containing [alpha]({{< baseurl >}}/rancher/v2.x/en/installation/server-tags/#server-tags) aren't supported.
diff --git a/content/rancher/v2.x/en/user-settings/_index.md b/content/rancher/v2.x/en/user-settings/_index.md
index 7c71f6f01cf..4fea8416f2c 100644
--- a/content/rancher/v2.x/en/user-settings/_index.md
+++ b/content/rancher/v2.x/en/user-settings/_index.md
@@ -11,7 +11,8 @@ Within Rancher, each user has a number of settings associated with their login:
The available user settings are:
-- [API & Keys]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/): If you want to interact with Rancher programmatically, you need an API key. Follow the directions in this section to obtain a key.
+- [API & Keys]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/): If you want to interact with Rancher programmatically, you need an API key. Follow the directions in this section to obtain a key.gferfgre
+- [Cloud Credentials]({{< baseurl >}}/rancher/v2.x/en/user-settings/cloud-credentials/): Manage cloud credentials [used by node templates]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) to [provision nodes for clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters). Note: Available as of v2.2.0.
- [Node Templates]({{< baseurl >}}/rancher/v2.x/en/user-settings/node-templates): Manage templates [used by Rancher to provision nodes for clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters).
- [Preferences]({{< baseurl >}}/rancher/v2.x/en/user-settings/preferences): Sets superficial preferences for the Rancher UI.
- Log Out: Ends your user session.
diff --git a/content/rancher/v2.x/en/user-settings/cloud-credentials/_index.md b/content/rancher/v2.x/en/user-settings/cloud-credentials/_index.md
new file mode 100644
index 00000000000..57884ad24d5
--- /dev/null
+++ b/content/rancher/v2.x/en/user-settings/cloud-credentials/_index.md
@@ -0,0 +1,51 @@
+---
+title: Managing Cloud Credentials
+weight: 7011
+---
+
+_Available as of v2.2.0_
+
+When you create a cluster [hosted by an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools), [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 configuration options to define an operating system image and settings/parameters for the node.
+
+Node templates can use cloud credentials to access the credential information required to provision nodes in the infrastructure providers. The same cloud credential can be used by multiple node templates. By using a cloud credential, you do not have to re-enter access keys for the same cloud provider. Cloud credentials are stored as Kubernetes secrets.
+
+Cloud credentials are only used by node templates if there are fields marked as `password`. The default `active` node drivers have their account access fields marked as `password`, but there may be some `inactive` node drivers, which are not using them yet. These node drivers will not use cloud credentials.
+
+You can create cloud credentials in two contexts:
+
+- [During creation of a node template]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) for a cluster.
+- In the **User Settings**
+
+All cloud credentials are bound to the user profile of who created it. They **cannot** be shared across users.
+
+## Creating a Cloud Credential from User Settings
+
+1. From your user settings, select **User Avatar > Cloud Credentials**.
+1. Click **Add Cloud Credential**.
+1. Enter a name for the cloud credential.
+1. Select a **Cloud Credential Type** from the drop down. The values of this dropdown is based on the `active` [node drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/node-drivers/) in Rancher.
+1. Based on the selected cloud credential type, enter the required values to authenticate with the infrastructure provider.
+1. Click **Create**.
+
+**Result:** The cloud credential is created and can immediately be used to [create node templates]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-templates).
+
+## Updating a Cloud Credential
+
+When access credentials are changed or compromised, updating a cloud credential allows you to rotate those credentials while keeping the same node template.
+
+1. From your user settings, select **User Avatar > Cloud Credentials**.
+1. Choose the cloud credential you want to edit and click the **Vertical Ellipsis (...) > Edit**.
+1. Update the credential information and click **Save**.
+
+**Result:** The cloud credential is updated with the new access credentials. All existing node templates using this cloud credential will automatically use the updated information whenever [new nodes are added]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/).
+
+## Deleting a Cloud Credential
+
+In order to delete cloud credentials, there must not be any node template associated with it. If you are unable to delete the cloud credential, [delete any node templates]({{< baseurl >}}/rancher/v2.x/en/user-settings/node-templates/#deleting-a-node-template) that are still associated to that cloud credential.
+
+1. From your user settings, select **User Avatar > Cloud Credentials**.
+1. You can either individually delete a cloud credential or bulk delete.
+
+ - To individually delete one, choose the cloud credential you want to edit and click the **Vertical Ellipsis (...) > Delete**.
+ - To bulk delete cloud credentials, select one or more cloud credentials from the list. Click **Delete**.
+1. Confirm that you want to delete these cloud credentials.
diff --git a/content/rancher/v2.x/en/user-settings/node-templates/_index.md b/content/rancher/v2.x/en/user-settings/node-templates/_index.md
index 24d0d604602..2ebd89b0bd7 100644
--- a/content/rancher/v2.x/en/user-settings/node-templates/_index.md
+++ b/content/rancher/v2.x/en/user-settings/node-templates/_index.md
@@ -18,6 +18,17 @@ When you create a node template, it is bound to your user profile. Node 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).
+## Updating a Node Template
+
+1. From your user settings, select **User Avatar > Node Templates**.
+1. Choose the node template that you want to edit and click the **Vertical Ellipsis (...) > Edit**.
+
+ > **Note:** As of v2.2.0, the default `active` [node drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/node-drivers/) and any node driver, that has fields marked as `password`, are required to use [cloud credentials]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#cloud-credentials). If you have upgraded to v2.2.0, existing node templates will continue to work with the previous account access information, but when you edit the node template, you will be required to create a cloud credential and the node template will start using it.
+
+1. Edit the required information and click **Save**.
+
+**Result:** The node template is updated. All node pools using this node template will automatically use the updated information when new nodes are added.
+
## 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.
@@ -33,4 +44,4 @@ When creating new node templates from your user settings, you can clone an exist
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.
\ No newline at end of file
+1. Select one or more template from the list. Then click **Delete**. Confirm the delete when prompted.
diff --git a/content/rancher/v2.x/en/user-settings/preferences/_index.md b/content/rancher/v2.x/en/user-settings/preferences/_index.md
index a3ae0523edd..fc2fe8c1f2b 100644
--- a/content/rancher/v2.x/en/user-settings/preferences/_index.md
+++ b/content/rancher/v2.x/en/user-settings/preferences/_index.md
@@ -1,6 +1,6 @@
---
title: User Preferences
-weight: 7010
+weight: 7012
---
Each user can choose preferences to personalize their Rancher experience. To change preference settings, open the **User Settings** menu and then select **Preferences**.
diff --git a/content/rancher/v2.x/en/v1.6-migration/_index.md b/content/rancher/v2.x/en/v1.6-migration/_index.md
index 3a8a0c463a2..8d065e00458 100644
--- a/content/rancher/v2.x/en/v1.6-migration/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/_index.md
@@ -1,5 +1,5 @@
---
-title: Migrating from Rancher v1.6 to v2.x
+title: Migrating from v1.6 to v2.x
weight: 10000
---
@@ -31,11 +31,11 @@ This video demonstrates a complete walk through of migration from Rancher v1.6 t
## Migration Example Files
-Throughout this migration guide, we will reference several example services from Rancher v1.6 that we're migrating to v2.x. These services are:
+Throughout this migration guide, we will reference several example services from Rancher v1.6 that we're migrating to v2.x. These services are:
- A service named `web`, which runs [Let's Chat](http://sdelements.github.io/lets-chat/), a self-hosted chat for small teams.
- A service named `database`, which runs [Mongo DB](https://www.mongodb.com/), an open source document database.
-- A service named `webLB`, which runs [HAProxy](http://www.haproxy.org/), an open source load balancer used in Rancher v1.6.
+- A service named `webLB`, which runs [HAProxy](http://www.haproxy.org/), an open source load balancer used in Rancher v1.6.
During migration, we'll export these services from Rancher v1.6. The export generates a unique directory for each Rancher v1.6 environment and stack, and two files are output into each stack's directory:
@@ -48,4 +48,4 @@ During migration, we'll export these services from Rancher v1.6. The export gen
A file for Rancher-specific functionality such as health checks and load balancers. These files cannot be read by Rancher v2.x, so don't worry about their contents—we're discarding them and recreating them using the v2.x UI.
-### [Next: Get Started]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/get-started)
\ No newline at end of file
+### [Next: Get Started]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/get-started)
diff --git a/content/rancher/v2.x/en/v1.6-migration/discover-services/_index.md b/content/rancher/v2.x/en/v1.6-migration/discover-services/_index.md
index 297647972e7..9c10255eba0 100644
--- a/content/rancher/v2.x/en/v1.6-migration/discover-services/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/discover-services/_index.md
@@ -3,14 +3,10 @@ title: "6. Service Discovery"
weight: 600
---
-Service discovery is one of the core functionalities of any container-based environment. Once you have packaged and launched your application, the next step is making it discoverable to other containers in your environment or the external world. This document will describe how to use the service discovery support provided by Rancher v2.x so that you can find them by name.
+Service discovery is one of the core functionalities of any container-based environment. Once you have packaged and launched your application, the next step is making it discoverable to other containers in your environment or the external world. This document will describe how to use the service discovery support provided by Rancher v2.x so that you can find them by name.
This document will also show you how to link the workloads and services that you migrated into Rancher v2.x. When you parsed your services from v1.6 using migration-tools CLI, it output two files for each service: one deployment manifest and one service manifest. You'll have to link these two files together before the deployment works correctly in v2.x.
-Resolve the output.txt Link Directive
-
-
-
## In This Document
@@ -27,7 +23,7 @@ This document will also show you how to link the workloads and services that you
For Rancher v2.x, we've replaced the Rancher DNS microservice used in v1.6 with native [Kubernetes DNS support](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/), which provides equivalent service discovery for Kubernetes workloads and pods. Former Cattle users can replicate all the service discovery features from Rancher v1.6 in v2.x. There's no loss of functionality.
-Kubernetes schedules a DNS pod and service in the cluster, which is similar to the [Rancher v1.6 DNS microservice](https://rancher.com/docs/rancher/v1.6/en/cattle/internal-dns-service/#internal-dns-service-in-cattle-environments). Kubernetes then configures its kubelets to route all DNS lookups to this DNS service, which is skyDNS, a flavor of the default Kube-DNS implementation.
+Kubernetes schedules a DNS pod and service in the cluster, which is similar to the [Rancher v1.6 DNS microservice]({{< baseurl >}}/rancher/v1.6/en/cattle/internal-dns-service/#internal-dns-service-in-cattle-environments). Kubernetes then configures its kubelets to route all DNS lookups to this DNS service, which is skyDNS, a flavor of the default Kube-DNS implementation.
The following table displays each service discovery feature available in the two Rancher releases.
@@ -62,11 +58,6 @@ When you migrate v1.6 services to v2.x, Rancher does not automatically create a
In the image below, the `web-deployment.yml` and `web-service.yml` files [created after parsing]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/run-migration-tool/#migration-example-file-output) our [migration example services]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/#migration-example-files) are linked together.
-Linked Workload and Kubernetes Service
-
-
-
-
### Service Name Alias Creation
Just as you can create an alias for Rancher v1.6 services, you can do the same for Rancher v2.x workloads. Similarly, you can also create DNS records pointing to services running externally, using either their hostname or IP address. These DNS records are Kubernetes service objects.
@@ -75,9 +66,6 @@ Using the v2.x UI, use the context menu to navigate to the `Project` view and ch
Click **Add Record** to create new DNS records. Then view the various options supported to link to external services or to create aliases for another workload, DNS record, or set of pods.
-Add Service Discovery Record
-
-
The following table indicates which alias options are implemented natively by Kubernetes and which options are implemented by Rancher leveraging Kubernetes.
Option | Kubernetes-implemented? | Rancher-implemented?
diff --git a/content/rancher/v2.x/en/v1.6-migration/get-started/_index.md b/content/rancher/v2.x/en/v1.6-migration/get-started/_index.md
index 5722d34fd5d..f5a1b6147d9 100644
--- a/content/rancher/v2.x/en/v1.6-migration/get-started/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/get-started/_index.md
@@ -34,16 +34,12 @@ After provisioning your node(s), install Rancher:
For production environments where your user base requires constant access to your cluster, we recommend installing Rancher in a high availability (HA) configuration. This installation procedure provisions a three-node cluster and installs Rancher on each node using a Helm chart.
- >**Important Difference:** Although you could install Rancher v1.6 in an HA configuration using an external database and a Docker command on each node, Rancher v2.x in an HA configuration requires an existing Kubernetes cluster. Review [High Availability (HA) Install](https://rancher.com/docs/rancher/v2.x/en/installation/ha/) for full requirements.
+ >**Important Difference:** Although you could install Rancher v1.6 in an HA configuration using an external database and a Docker command on each node, Rancher v2.x in an HA configuration requires an existing Kubernetes cluster. Review [High Availability (HA) Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/) for full requirements.
## B. Configure Authentication
After your Rancher v2.x Server is installed, we recommend configuring external authentication (like Active Directory or GitHub) so that users can log into Rancher using their single sign-on. For a full list of supported authentication providers and instructions on how to configure them, see [Authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication).
-Rancher v2.x Authentication
-
-
-
### Local Users
Although we recommend using an external authentication provider, Rancher v1.6 and v2.x both offer support for users local to Rancher. However, these users cannot be migrated from Rancher v1.6 to v2.x. If you used local users in Rancher v1.6 and want to continue this practice in v2.x, you'll need to [manually recreate these user accounts]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) and assign them access rights.
@@ -70,8 +66,8 @@ In Rancher v1.6, compute nodes were added to an _environment_. Rancher v2.x esch
Rancher v2.x lets you launch a Kubernetes cluster anywhere. Host your cluster using:
- A [hosted Kubernetes provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/).
-- A [pool of nodes from an infrastructure provider]({{< baseurl >}}rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/). Rancher launches Kubernetes on the nodes.
-- Any [custom node(s)]({{< baseurl >}}rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/). Rancher can launch Kubernetes on the nodes, be they bare metal servers, virtual machines, or cloud hosts on a less popular infrastructure provider.
+- A [pool of nodes from an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/). Rancher launches Kubernetes on the nodes.
+- Any [custom node(s)]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/). Rancher can launch Kubernetes on the nodes, be they bare metal servers, virtual machines, or cloud hosts on a less popular infrastructure provider.
### Projects
@@ -82,13 +78,13 @@ When you create a cluster, two projects are automatically created:
- The `System` project, which includes system namespaces where important Kubernetes resources are running (like ingress controllers and cluster dns services)
- The `Default` project.
-However, for production environments, we recommend [creating your own project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#creating-projects) and giving it a descriptive name.
+However, for production environments, we recommend [creating your own project]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/#creating-projects) and giving it a descriptive name.
After provisioning a new cluster and project, you can authorize your users to access and use project resources. Similarly to Rancher v1.6 environments, Rancher v2.x allows you to [assign users to projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/). By assigning users to projects, you can limit what applications and resources a user can access.
## D. Create Stacks
-In Rancher v1.6, _stacks_ were used to group together the services that belong to your application. In v2.x, you need to [create namespaces]({{< baseurl >}}rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#creating-namespaces), which are the v2.x equivalent of stacks, for the same purpose.
+In Rancher v1.6, _stacks_ were used to group together the services that belong to your application. In v2.x, you need to [create namespaces]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#creating-namespaces), which are the v2.x equivalent of stacks, for the same purpose.
In Rancher v2.x, namespaces are child objects to projects. When you create a project, a `default` namespace is added to the project, but you can create your own to parallel your stacks from v1.6.
diff --git a/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md b/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md
index df299c696eb..c34f46f1cca 100644
--- a/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md
@@ -5,14 +5,10 @@ weight: 700
If your applications are public-facing and consume significant traffic, you should place a load balancer in front of your cluster so that users can always access their apps without service interruption. Typically, you can fulfill a high volume of service requests by [horizontally scaling](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) your deployment, which spins up additional application containers as traffic ramps up. However, this technique requires routing that distributes traffic across your nodes efficiently. In cases where you need to accommodate public traffic that scales up and down, you'll need a load balancer.
-As outlined in [its documentation](https://rancher.com/docs/rancher/v1.6/en/cattle/adding-load-balancers/), Rancher v1.6 provided rich support for load balancing using its own microservice powered by HAProxy, which supports HTTP, HTTPS, TCP hostname, and path-based routing. Most of these same features are available in v2.x. However, load balancers that you used with v1.6 cannot be migrated to v2.x. You'll have to manually recreate your v1.6 load balancer in v2.x.
+As outlined in [its documentation]({{< baseurl >}}/rancher/v1.6/en/cattle/adding-load-balancers/), Rancher v1.6 provided rich support for load balancing using its own microservice powered by HAProxy, which supports HTTP, HTTPS, TCP hostname, and path-based routing. Most of these same features are available in v2.x. However, load balancers that you used with v1.6 cannot be migrated to v2.x. You'll have to manually recreate your v1.6 load balancer in v2.x.
If you encounter the `output.txt` text below after parsing your v1.6 Compose files to Kubernetes manifests, you'll have to resolve it by manually creating a load balancer in v2.x.
-output.txt Load Balancer Directive
-
-
-
## In This Document
@@ -41,9 +37,9 @@ Rancher v2.x offers similar functionality, but load balancing is instead handled
By default, Rancher v2.x deploys NGINX Ingress Controller on clusters provisioned using RKE (Rancher's own Kubernetes installer) to process the Kubernetes Ingress rules. The NGINX Ingress Controller is installed by default only in clusters provisioned by RKE. Clusters provisioned by cloud providers like GKE have their own Ingress Controllers that configure the load balancer. For this document, our scope is limited to the RKE-installed NGINX Ingress Controller only, but you can read about cloud providers in [our documentation]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/).
-RKE deploys NGINX Ingress Controller as a [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), meaning that an NGINX instance is deployed on every node in the cluster. NGINX acts like an Ingress Controller listening to Ingress creation within your entire cluster, and it also configures itself as the load balancer to satisfy the Ingress rules. The DaemonSet is configured with hostNetwork to expose two ports: 80 and 443.
+RKE deploys NGINX Ingress Controller as a [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), meaning that an NGINX instance is deployed on every node in the cluster. NGINX acts like an Ingress Controller listening to Ingress creation within your entire cluster, and it also configures itself as the load balancer to satisfy the Ingress rules. The DaemonSet is configured with hostNetwork to expose two ports: 80 and 443.
-For more information NGINX Ingress Controller, their deployment as DaemonSets, deployment configuration options, see the [RKE documentation](https://rancher.com/docs/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/).
+For more information NGINX Ingress Controller, their deployment as DaemonSets, deployment configuration options, see the [RKE documentation]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/).
## Load Balancing Architecture
@@ -53,17 +49,8 @@ In Rancher v1.6 you could deploy a scalable load balancer service within your st
-Rancher v1.6 Load Balancing Architecture
-
-
-
The Rancher v2.x Ingress Controller is a DaemonSet, it is globally deployed on all schedulable nodes to serve your entire Kubernetes Cluster. Therefore, when you program the Ingress rules, you must use a unique hostname and path to point to your workloads, as the load balancer node IP addresses and ports 80 and 443 are common access points for all workloads.
-Rancher v2.x Load Balancing Architecture
-
-
-
-
## Ingress Caveats
Although Rancher v2.x supports HTTP and HTTPS hostname and path-based load balancing, you must use unique host names and paths when configuring your workloads. This limitation derives from:
@@ -79,14 +66,9 @@ You can launch a new load balancer to replace your load balancer from v1.6. Usin
>**Prerequisite:** Before deploying Ingress, you must have a workload deployed that's running a scale of two or more pods.
>
->
For balancing between these two pods, you must create a Kubernetes Ingress rule. To create this rule, navigate to your cluster and project, and then select the **Load Balancing** tab. Then click **Add Ingress**. This GIF below depicts how to add Ingress to one of your projects.
-Browsing to Load Balancer Tab and Adding Ingress
-
-
-
Similar to a service/port rules in Rancher v1.6, here you can specify rules targeting your workload's container port. The sections below demonstrate how to create Ingress rules.
### Configuring Host- and Path-Based Routing
@@ -95,18 +77,8 @@ Using Rancher v2.x, you can add Ingress rules that are based on host names or a
For example, let's say you have multiple workloads deployed to a single namespace. You can add an Ingress to route traffic to these two workloads using the same hostname but different paths, as depicted in the image below. URL requests to `foo.com/name.html` will direct users to the `web` workload, and URL requests to `foo.com/login` will direct users to the `chat` workload.
-Ingress: Path-Based Routing Configuration
-
-
-
-
Rancher v2.x also places a convenient link to the workloads on the Ingress record. If you configure an external DNS to program the DNS records, this hostname can be mapped to the Kubernetes Ingress address.
-Workload Links
-
-
-
-
The Ingress address is the IP address in your cluster that the Ingress Controller allocates for your workload. You can reach your workload by browsing to this IP address. Use `kubectl` command below to see the Ingress address assigned by the controller:
```
@@ -118,24 +90,16 @@ kubectl get ingress
Rancher v2.x Ingress functionality supports the HTTPS protocol, but if you want to use it, you need to use a valid SSL/TLS certificate. While configuring Ingress rules, use the **SSL/TLS Certificates** section to configure a certificate.
- We recommend [uploading a certificate]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/) from a known certificate authority (you'll have to do this before configuring Ingress). Then, while configuring your load balancer, use the **Choose a certificate** option and select the uploaded certificate that you want to use.
-- If you have configured [NGINX default certificate]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/#configuring-an-nginx-default-certificate), you can select **Use default ingress controller certificate**.
-
-Load Balancer Configuration: SSL/TLS Certificate Section
-
-
+- If you have configured [NGINX default certificate]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/#configuring-an-nginx-default-certificate), you can select **Use default ingress controller certificate**.
### TCP Load Balancing Options
#### Layer-4 Load Balancer
-For the TCP protocol, Rancher v2.x supports configuring a Layer 4 load balancer using the cloud provider in which your Kubernetes cluster is deployed. Once this load balancer appliance is configured for your cluster, when you choose the option of a `Layer-4 Load Balancer` for port-mapping during workload deployment, Rancher automatically creates a corresponding load balancer service. This service will call the corresponding cloud provider and configure the load balancer appliance to route requests to the appropriate pods. See [Cloud Providers](https://rancher.com/docs/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) for information on how to configure LoadBalancer services for your cloud provider.
+For the TCP protocol, Rancher v2.x supports configuring a Layer 4 load balancer using the cloud provider in which your Kubernetes cluster is deployed. Once this load balancer appliance is configured for your cluster, when you choose the option of a `Layer-4 Load Balancer` for port-mapping during workload deployment, Rancher automatically creates a corresponding load balancer service. This service will call the corresponding cloud provider and configure the load balancer appliance to route requests to the appropriate pods. See [Cloud Providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) for information on how to configure LoadBalancer services for your cloud provider.
For example, if we create a deployment named `myapp` and specify a Layer 4 load balancer in the **Port Mapping** section, Rancher will automatically add an entry to the **Load Balancer** tab named `myapp-loadbalancer`.
-Workload Deployment: Layer 4 Load Balancer Creation
-
-
-
Once configuration of the load balancer succeeds, the Rancher UI provides a link to your workload's public endpoint.
#### NGINX Ingress Controller TCP Support by ConfigMaps
@@ -146,13 +110,11 @@ However, there is a workaround to use NGINX's TCP balancing by creating a Kubern
To configure NGINX to expose your services via TCP, you can add the ConfigMap `tcp-services` that should exist in the `ingress-nginx` namespace. This namespace also contains the NGINX Ingress Controller pods.
-
-
The key in the ConfigMap entry should be the TCP port that you want to expose for public access: `:`. As shown above, two workloads are listed in the `Default` namespace. For example, the first entry in the ConfigMap above instructs NGINX to expose the `myapp` workload (the one in the `default` namespace that's listening on private port 80) over external port `6790`. Adding these entries to the ConfigMap automatically updates the NGINX pods to configure these workloads for TCP balancing. The workloads exposed should be available at `:`. If they are not accessible, you might have to expose the TCP port explicitly using a NodePort service.
## Rancher v2.x Load Balancing Limitations
-Cattle provided feature-rich load balancer support that is [well documented](https://rancher.com/docs/rancher/v1.6/en/cattle/adding-load-balancers/#load-balancers). Some of these features do not have equivalents in Rancher v2.x. This is the list of such features:
+Cattle provided feature-rich load balancer support that is [well documented]({{< baseurl >}}/rancher/v1.6/en/cattle/adding-load-balancers/#load-balancers). Some of these features do not have equivalents in Rancher v2.x. This is the list of such features:
- No support for SNI in current NGINX Ingress Controller.
- TCP load balancing requires a load balancer appliance enabled by cloud provider within the cluster. There is no Ingress support for TCP on Kubernetes.
diff --git a/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md b/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md
index 4a909f91451..ad16e2cac2c 100644
--- a/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md
@@ -9,12 +9,7 @@ For Rancher v2.x, we've replaced the health check microservice, leveraging inste
Use this document to correct Rancher v2.x workloads and services that list `health_check` in `output.txt`. You can correct them by configuring a liveness probe (i.e., a health check).
-For example, for the image below, we would configure liveness probes for the `web` and `weblb` workloads (i.e., the Kubernetes manifests output by migration-tools CLI).
-
-Resolve health_check for the web and webLB Workloads
-
-
-
+For example, for the image below, we would configure liveness probes for the `web` and `weblb` workloads (i.e., the Kubernetes manifests output by migration-tools CLI).
## In This Document
@@ -34,7 +29,7 @@ The health check microservice features two types of health checks, which have a
- **TCP health checks**:
- These health checks check if a TCP connection opens at the specified port for the monitored service. For full details, see the [Rancher v1.6 documentation](https://rancher.com/docs/rancher/v1.6/en/cattle/health-checks/).
+ These health checks check if a TCP connection opens at the specified port for the monitored service. For full details, see the [Rancher v1.6 documentation]({{< baseurl >}}/rancher/v1.6/en/cattle/health-checks/).
- **HTTP health checks**:
@@ -42,9 +37,6 @@ The health check microservice features two types of health checks, which have a
The following diagram displays the health check microservice evaluating a container running Nginx. Notice that the microservice is making its check across nodes.
-
-
-
## Rancher v2.x Health Checks
In Rancher v2.x, the health check microservice is replaced with Kubernete's native health check mechanisms, called _probes_. These probes, similar to the Rancher v1.6 health check microservice, monitor the health of pods over TCP and HTTP.
@@ -71,8 +63,6 @@ Kubernetes includes two different _types_ of probes: liveness checks and readine
The following diagram displays kubelets running probes on containers they are monitoring ([kubelets](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) are the primary "agent" running on each node). The node on the left is running a liveness probe, while the one of the right is running a readiness check. Notice that the kubelet is scanning containers on its host node rather than across nodes, as in Rancher v1.6.
-
-
## Configuring Probes in Rancher v2.x
The [migration-tool CLI]({{< baseurl >}}/rancher/v2.x/en/v1.6-migration/run-migration-tool/) cannot parse health checks from Compose files to Kubernetes manifest. Therefore, if want you to add health checks to your Rancher v2.x workloads, you'll have to add them manually.
@@ -83,13 +73,9 @@ If the probe fails, the container is restarted per the restartPolicy defined in
Configure probes by using the **Health Check** section while editing deployments called out in `output.txt`.
-Edit Deployment: Health Check Section
-
-
-
### Configuring Checks
-While you create a workload using Rancher v2.x, we recommend configuring a check that monitors the health of the deployment's pods.
+While you create a workload using Rancher v2.x, we recommend configuring a check that monitors the health of the deployment's pods.
{{% tabs %}}
@@ -99,8 +85,6 @@ TCP checks monitor your deployment's health by attempting to open a connection t
You can configure the probe along with values for specifying its behavior by selecting the **TCP connection opens successfully** option in the **Health Check** section. For more information, see [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/). For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#health-check-parameter-mappings).
-
-
When you configure a readiness check using Rancher v2.x, the `readinessProbe` directive and the values you've set are added to the deployment's Kubernetes manifest. Configuring a readiness check also automatically adds a liveness check (`livenessProbe`) to the deployment.
-[7]:{{< baseurl >}}/rancher/v2.x/en/v1.6-migration/schedule-workloads/#scheduling-using-labels
+[7]:{{< baseurl >}}/rancher/v2.x/en/v1.6-migration/schedule-workloads/#scheduling-using-labels
[8]:{{< baseurl >}}/rancher/v2.x/en/v1.6-migration/schedule-workloads/#scheduling-global-services
[9]:{{< baseurl >}}/rancher/v2.x/en/v1.6-migration/schedule-workloads/#label-affinity-antiaffinity
diff --git a/content/rancher/v2.x/en/v1.6-migration/schedule-workloads/_index.md b/content/rancher/v2.x/en/v1.6-migration/schedule-workloads/_index.md
index 96853ac5036..826dd06bfee 100644
--- a/content/rancher/v2.x/en/v1.6-migration/schedule-workloads/_index.md
+++ b/content/rancher/v2.x/en/v1.6-migration/schedule-workloads/_index.md
@@ -13,8 +13,6 @@ You can schedule your migrated v1.6 services while editing a deployment. Schedul
Editing Workloads: Workload Type and Node Scheduling Sections
-
-
## In This Document
@@ -31,20 +29,19 @@ You can schedule your migrated v1.6 services while editing a deployment. Schedul
- [Scheduling Global Services](#scheduling-global-services)
-
+
## What's Different for Scheduling Services?
-Rancher v2.x retains _all_ methods available in v1.6 for scheduling your services. However, because the default container orchestration system has changed from Cattle to Kubernetes, the terminology and implementation for each scheduling option has changed.
+Rancher v2.x retains _all_ methods available in v1.6 for scheduling your services. However, because the default container orchestration system has changed from Cattle to Kubernetes, the terminology and implementation for each scheduling option has changed.
In v1.6, you would schedule a service to a host while adding a service to a Stack. In Rancher v2.x., the equivalent action is to schedule a workload for deployment. The following composite image shows a comparison of the UI used for scheduling in Rancher v2.x versus v1.6.
-
## Node Scheduling Options
-Rancher offers a variety of options when scheduling nodes to host workload pods (i.e., scheduling hosts for containers in Rancher v1.6).
+Rancher offers a variety of options when scheduling nodes to host workload pods (i.e., scheduling hosts for containers in Rancher v1.6).
You can choose a scheduling option as you deploy a workload. The term _workload_ is synonymous with adding a service to a Stack in Rancher v1.6). You can deploy a workload by using the context menu to browse to a cluster project (` > > Workloads`).
@@ -52,29 +49,20 @@ The sections that follow provide information on using each scheduling options, a
Option | v1.6 Feature | v2.x Feature
-------|------|------
-[Schedule a certain number of pods?](#schedule-a-certain-number-of-pods) | ✓ | ✓
+[Schedule a certain number of pods?](#schedule-a-certain-number-of-pods) | ✓ | ✓
[Schedule pods to specific node?](#scheduling-pods-to-a-specific-node) | ✓ | ✓
-[Schedule to nodes using labels?](#scheduling-pods-using-labels) | ✓ | ✓
-[Schedule to nodes using label affinity/anti-affinity rules?](#scheduling-pods-using-affinityanti-affinity-label) | ✓ | ✓
+[Schedule to nodes using labels?](#applying-labels-to-nodes-and-pods) | ✓ | ✓
+[Schedule to nodes using label affinity/anti-affinity rules?](#label-affinity-antiaffinity) | ✓ | ✓
[Schedule based on resource constraints?](#scheduling-pods-using-resource-constraints) | ✓ | ✓
[Preventing scheduling specific services to specific hosts?](#preventing-scheduling-specific-services-to-specific-nodes) | ✓ | ✓
-[Schedule services globally?](#scheduling-global-services) | ✓ | ✓
+[Schedule services globally?](#scheduling-global-services) | ✓ | ✓
### Schedule a certain number of pods
-In v1.6, you could control the number of container replicas deployed for a service. You can schedule pods the same way in v2.x, but you'll have to set the scale manually while editing a workload.
-
-
-
-
-During migration, you can resolve `scale` entries in `output.txt` by setting a value for the **Workload Type** option **Scalable deployment** depicted below.
-
-Scalable Deployment Option
-
-
-
+In v1.6, you could control the number of container replicas deployed for a service. You can schedule pods the same way in v2.x, but you'll have to set the scale manually while editing a workload.
+During migration, you can resolve `scale` entries in `output.txt` by setting a value for the **Workload Type** option **Scalable deployment** depicted below.
### Scheduling Pods to a Specific Node
@@ -83,21 +71,15 @@ Just as you could schedule containers to a single host in Rancher v1.6, you can
As you deploy a workload, use the **Node Scheduling** section to choose a node to run your pods on. The workload below is being scheduled to deploy an Nginx image with a scale of two pods on a specific node.
-Rancher v2.x: Workload Deployment
-
-
-
-Rancher schedules pods to the node you select if 1) there are compute resource available for the node and 2) you've configured port mapping to use the HostPort option, that there are no port conflicts.
+Rancher schedules pods to the node you select if 1) there are compute resource available for the node and 2) you've configured port mapping to use the HostPort option, that there are no port conflicts.
If you expose the workload using a NodePort that conflicts with another workload, the deployment gets created successfully, but no NodePort service is created. Therefore, the workload isn't exposed outside of the cluster.
After the workload is created, you can confirm that the pods are scheduled to your chosen node. From the **Workloads** tab, click the **Group by Node** icon to sort your workloads by node. Note that both Nginx pods are scheduled to the same node.
-
-
). A _DaemonSet_ functions exactly like a Rancher v1.6 global service. The Kubernetes scheduler deploys a pod on each node of the cluster, and as new nodes are added, the scheduler will start new pods on them provided they match the scheduling requirements of the workload. Additionally, in v2.x, you can also limit a DaemonSet to be deployed to nodes that have a specific label.
-To create a daemonset while configuring a workload, choose **Run one pod on each node** from the the **Workload Type** options.
-
-Workload Configuration: Choose run one pod on each node to configure daemonset
-
-
+To create a daemonset while configuring a workload, choose **Run one pod on each node** from the the **Workload Type** options.
### Scheduling Pods Using Resource Constraints
-While creating a service in the Rancher v1.6 UI, you could schedule its containers to hosts based on hardware requirements that you choose. The containers are then scheduled to hosts based on which ones have bandwidth, memory, and CPU capacity.
+While creating a service in the Rancher v1.6 UI, you could schedule its containers to hosts based on hardware requirements that you choose. The containers are then scheduled to hosts based on which ones have bandwidth, memory, and CPU capacity.
In Rancher v2.x, you can still specify the resources required by your pods. However, these options are unavailable in the UI. Instead, you must edit your workload's manifest file to declare these resource constraints.
-To declare resource constraints, edit your migrated workloads, editing the **Security & Host** sections.
+To declare resource constraints, edit your migrated workloads, editing the **Security & Host** sections.
- To reserve a minimum hardware reservation available for your pod(s), edit the following sections:
- Memory Reservation
- CPU Reservation
- - NVIDIA GPU Reservation
+ - NVIDIA GPU Reservation
- To set a maximum hardware limit for your pods, edit:
- - Memory Limit
- - CPU Limit
-
-Scheduling: Resource Constraint Settings
-
-
+ - Memory Limit
+ - CPU Limit
You can find more detail about these specs and how to use them in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container).
diff --git a/content/rke/v0.1.x/_index.md b/content/rke/latest/_index.md
similarity index 68%
rename from content/rke/v0.1.x/_index.md
rename to content/rke/latest/_index.md
index 1e02f1cc36b..f0de8adf0bf 100644
--- a/content/rke/v0.1.x/_index.md
+++ b/content/rke/latest/_index.md
@@ -1,4 +1,4 @@
---
-title: v0.1.x
+title: RKE
showBreadcrumb: false
---
diff --git a/content/rke/v0.1.x/en/_index.md b/content/rke/latest/en/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/_index.md
rename to content/rke/latest/en/_index.md
diff --git a/content/rke/latest/en/cert-mgmt/_index.md b/content/rke/latest/en/cert-mgmt/_index.md
new file mode 100644
index 00000000000..765826121bc
--- /dev/null
+++ b/content/rke/latest/en/cert-mgmt/_index.md
@@ -0,0 +1,109 @@
+---
+title: Certificate Management
+weight: 150
+---
+
+_Available as of v0.2.0_
+
+Certificates are an important part of Kubernetes clusters and are used for all Kubernetes cluster components. RKE has a `rke cert` command to help work with certificates.
+
+* [Ability to generate certificate sign requests for the Kubernetes components](#generating-certificate-signing-requests-csrs-and-keys)
+* [Rotate Auto-Generated Certificates](#certificate-rotation)
+
+## Generating Certificate Signing Requests (CSRs) and Keys
+
+If you want to create and sign the certificates by a real Certificate Authority (CA), you can use RKE to [generate a set of Certificate Signing Requests (CSRs) and keys]({{< baseurl >}}/rke/latest/en/installation/certs/#generating-certificate-signing-requests-csrs-and-keys).
+
+You can use the CSRs and keys to sign the certificates by a real CA. After the certificates are signed, these custom certificates can be used by RKE to as [custom certificates]({{< baseurl >}}/rke/latest/en/installation/certs/) for the Kubernetes cluster.
+
+## Certificate Rotation
+
+By default, Kubernetes clusters require certificates and RKE will automatically generate certificates for the clusters. Rotating these certificates are important before the certificates expire as well as if a certificate is compromised.
+
+After the certificates are rotated, the Kubernetes components are automatically restarted. Certificates can be rotated for the following services:
+
+- etcd
+- kubelet
+- kube-apiserver
+- kube-proxy
+- kube-scheduler
+- kube-controller-manager
+
+RKE has the ability to rotate the auto-generated certificates with some simple commands:
+
+* Rotating all service certificates while using the same CA
+* Rotating a certificate on an individual service while using the same CA
+* Rotating the CA and all service certificates
+
+Whenever you're trying to rotate certificates, the `cluster.yml` that was used to deploy the Kubernetes cluster is required. You can reference a different location for this file by using the `--config` option when running `rke cert rotate`.
+
+### Rotating all Service Certificates while using the same CA
+
+To rotate the service certificates for all the Kubernetes services, run the following command, i.e. `rke cert rotate`. After all the service certificates are rotated, these services will automatically be restarted to start using the new certificate.
+
+```
+$ rke cert rotate
+INFO[0000] Initiating Kubernetes cluster
+INFO[0000] Rotating Kubernetes cluster certificates
+INFO[0000] [certificates] Generating Kubernetes API server certificates
+INFO[0000] [certificates] Generating Kube Controller certificates
+INFO[0000] [certificates] Generating Kube Scheduler certificates
+INFO[0001] [certificates] Generating Kube Proxy certificates
+INFO[0001] [certificates] Generating Node certificate
+INFO[0001] [certificates] Generating admin certificates and kubeconfig
+INFO[0001] [certificates] Generating Kubernetes API server proxy client certificates
+INFO[0001] [certificates] Generating etcd-xxxxx certificate and key
+INFO[0001] [certificates] Generating etcd-yyyyy certificate and key
+INFO[0002] [certificates] Generating etcd-zzzzz certificate and key
+INFO[0002] Successfully Deployed state file at [./cluster.rkestate]
+INFO[0002] Rebuilding Kubernetes cluster with rotated certificates
+.....
+INFO[0050] [worker] Successfully restarted Worker Plane..
+```
+
+### Rotating a Certificate on an Individual Service while using the same CA
+
+To rotate the certificate for an individual Kubernetes service, use the `--service` option when rotating certificates to specify the service. After the specified Kubernetes service has had its certificate rotated, it is automatically restarted to start using the new certificate.
+
+Example of rotating the certificate for only the `kubelet`:
+
+```
+$ rke cert rotate --service kubelet
+INFO[0000] Initiating Kubernetes cluster
+INFO[0000] Rotating Kubernetes cluster certificates
+INFO[0000] [certificates] Generating Node certificate
+INFO[0000] Successfully Deployed state file at [./cluster.rkestate]
+INFO[0000] Rebuilding Kubernetes cluster with rotated certificates
+.....
+INFO[0033] [worker] Successfully restarted Worker Plane..
+```
+
+### Rotating the CA and all service certificates
+
+If the CA certificate needs to be rotated, you are required to rotate all the services certificates as they need to be signed with the newly rotated CA certificate. To include rotating the CA with the service certificates, add the `--rotate-ca` option. After the the CA and all the service certificates are rotated, these services will automatically be restarted to start using the new certificate.
+
+Rotating the CA certificate will result in restarting other system pods, that will also use the new CA certificate. This includes:
+
+- Networking pods (canal, calico, flannel, and weave)
+- Ingress Controller pods
+- KubeDNS pods
+
+```
+$ rke cert rotate --rotate-ca
+INFO[0000] Initiating Kubernetes cluster
+INFO[0000] Rotating Kubernetes cluster certificates
+INFO[0000] [certificates] Generating CA kubernetes certificates
+INFO[0000] [certificates] Generating Kubernetes API server aggregation layer requestheader client CA certificates
+INFO[0000] [certificates] Generating Kubernetes API server certificates
+INFO[0000] [certificates] Generating Kube Controller certificates
+INFO[0000] [certificates] Generating Kube Scheduler certificates
+INFO[0000] [certificates] Generating Kube Proxy certificates
+INFO[0000] [certificates] Generating Node certificate
+INFO[0001] [certificates] Generating admin certificates and kubeconfig
+INFO[0001] [certificates] Generating Kubernetes API server proxy client certificates
+INFO[0001] [certificates] Generating etcd-xxxxx certificate and key
+INFO[0001] [certificates] Generating etcd-yyyyy certificate and key
+INFO[0001] [certificates] Generating etcd-zzzzz certificate and key
+INFO[0001] Successfully Deployed state file at [./cluster.rkestate]
+INFO[0001] Rebuilding Kubernetes cluster with rotated certificates
+```
diff --git a/content/rke/v0.1.x/en/config-options/_index.md b/content/rke/latest/en/config-options/_index.md
similarity index 55%
rename from content/rke/v0.1.x/en/config-options/_index.md
rename to content/rke/latest/en/config-options/_index.md
index 00b170a844e..e47133db2c7 100644
--- a/content/rke/v0.1.x/en/config-options/_index.md
+++ b/content/rke/latest/en/config-options/_index.md
@@ -5,31 +5,31 @@ weight: 200
When setting up your `cluster.yml` for RKE, there are a lot of different options that can be configured to control the behavior of how RKE launches Kubernetes.
-There are several options that can be configured in cluster configuration option. There are several [example yamls]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/) that contain all the options.
+There are several options that can be configured in cluster configuration option. There are several [example yamls]({{< baseurl >}}/rke/latest/en/example-yamls/) that contain all the options.
### Configuring Nodes
-* [Nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/)
+* [Nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/)
* [Ignoring unsupported Docker versions](#supported-docker-versions)
-* [Private Registries]({{< baseurl >}}/rke/v0.1.x/en/config-options/private-registries/)
+* [Private Registries]({{< baseurl >}}/rke/latest/en/config-options/private-registries/)
* [Cluster Level SSH Key Path](#cluster-level-ssh-key-path)
* [SSH Agent](#ssh-agent)
-* [Bastion Host]({{< baseurl >}}/rke/v0.1.x/en/config-options/bastion-host/)
+* [Bastion Host]({{< baseurl >}}/rke/latest/en/config-options/bastion-host/)
### Configuring Kubernetes Cluster
* [Cluster Name](#cluster-name)
* [Kubernetes Version](#kubernetes-version)
-* [System Images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/)
-* [Services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/)
-* [Extra Args and Binds and Environment Variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/)
-* [External Etcd]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/external-etcd/)
-* [Authentication]({{< baseurl >}}/rke/v0.1.x/en/config-options/authentication/)
-* [Authorization]({{< baseurl >}}/rke/v0.1.x/en/config-options/authorization/)
-* [Cloud Providers]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/)
-* [Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/)
+* [System Images]({{< baseurl >}}/rke/latest/en/config-options/system-images/)
+* [Services]({{< baseurl >}}/rke/latest/en/config-options/services/)
+* [Extra Args and Binds and Environment Variables]({{< baseurl >}}/rke/latest/en/config-options/services/services-extras/)
+* [External Etcd]({{< baseurl >}}/rke/latest/en/config-options/services/external-etcd/)
+* [Authentication]({{< baseurl >}}/rke/latest/en/config-options/authentication/)
+* [Authorization]({{< baseurl >}}/rke/latest/en/config-options/authorization/)
+* [Cloud Providers]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/)
+* [Add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/)
* [Add-ons Jobs Timeout](#add-ons-jobs-timeout)
- * [Network Plugins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/)
- * [Ingress Controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/)
- * [User-Defined-Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/)
+ * [Network Plugins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/)
+ * [Ingress Controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/)
+ * [User-Defined-Add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/user-defined-add-ons/)
## Cluster Level Options
@@ -54,9 +54,7 @@ ignore_docker_version: true
### Kubernetes Version
-You can select which version of Kubernetes to install for your cluster. Each version of RKE has a specific list of supported Kubernetes versions. If a version is defined in `kubernetes_version` and is not found in this list, the default version is used. If you want to use a different version than listed below, please use the [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) option.
-
-To find out what the list of supported Kubernetes versions are for your version of RKE, please refer to the [release notes](https://github.com/rancher/rke/releases) of the RKE version that you are running.
+By default, RKE is defaulted to launch with a specific Kubernetes version. You can also select a different version of Kubernetes to install for your cluster. Each version of RKE has a specific list of supported Kubernetes versions.
You can set the Kubernetes version as follows:
@@ -64,11 +62,36 @@ You can set the Kubernetes version as follows:
kubernetes_version: "v1.11.6-rancher1-1"
```
-In case both `kubernetes_version` and [system images](#rke-system-images) are defined, the system images configuration will take precedence over `kubernetes_version`.
+In case both `kubernetes_version` and [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) are defined, the system images configuration will take precedence over `kubernetes_version`.
+
+#### Listing Supported Kubernetes Versions
+
+Please refer to the [release notes](https://github.com/rancher/rke/releases) of the RKE version that you are running, to find the list of supported Kubernetes versions as well as the default Kubernetes version.
+
+You can also list the supported versions and system images of specific version of RKE release with a quick command.
+
+```
+$ rke config --system-images --all
+
+INFO[0000] Generating images list for version [v1.13.4-rancher1-2]:
+.......
+INFO[0000] Generating images list for version [v1.11.8-rancher1-1]:
+.......
+INFO[0000] Generating images list for version [v1.12.6-rancher1-2]:
+.......
+```
+
+#### Using an unsupported Kubernetes version
+
+As of v0.2.0, if a version is defined in `kubernetes_version` and is not found in the specific list of supported Kubernetes versions, then RKE will error out.
+
+Prior to v0.2.0, if a version is defined in `kubernetes_version` and is not found in the specific list of supported Kubernetes versions, the default version from the supported list is used.
+
+If you want to use a different version from the supported list, please use the [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) option.
### Cluster Level SSH Key Path
-RKE connects to host(s) using `ssh`. Typically, each node will have an independent path for each ssh key, i.e. `ssh_key_path`, in the `nodes` section, but if you have a SSH key that is able to access **all** hosts in your cluster configuration file, you can set the path to that ssh key at the top level. Otherwise, you would set the ssh key path in the [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/).
+RKE connects to host(s) using `ssh`. Typically, each node will have an independent path for each ssh key, i.e. `ssh_key_path`, in the `nodes` section, but if you have a SSH key that is able to access **all** hosts in your cluster configuration file, you can set the path to that ssh key at the top level. Otherwise, you would set the ssh key path in the [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/).
If ssh key paths are defined at the cluster level and at the node level, the node-level key will take precedence.
@@ -98,8 +121,6 @@ $ echo $SSH_AUTH_SOCK
### Add-ons Job Timeout
-You can define [add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/) to be deployed after the Kubernetes cluster comes up, which uses Kubernetes [jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). RKE will stop attempting to retrieve the job status after the timeout, which is in seconds. The default timeout value is `30` seconds.
+You can define [add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/) to be deployed after the Kubernetes cluster comes up, which uses Kubernetes [jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). RKE will stop attempting to retrieve the job status after the timeout, which is in seconds. The default timeout value is `30` seconds.
```yaml
-addon_job_timeout: 30
-```
diff --git a/content/rke/v0.1.x/en/config-options/add-ons/_index.md b/content/rke/latest/en/config-options/add-ons/_index.md
similarity index 75%
rename from content/rke/v0.1.x/en/config-options/add-ons/_index.md
rename to content/rke/latest/en/config-options/add-ons/_index.md
index 64914d11ab4..b15e5346947 100644
--- a/content/rke/v0.1.x/en/config-options/add-ons/_index.md
+++ b/content/rke/latest/en/config-options/add-ons/_index.md
@@ -5,11 +5,12 @@ weight: 260
RKE supports pluggable add-ons. Add-ons are used to deploy several cluster components including:
-* [Network plug-ins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/)
-* [Ingress controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/)
-* KubeDNS
+* [Network plug-ins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/)
+* [Ingress controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/)
+* [DNS provider]({{< baseurl >}}/rke/latest/en/config-options/add-ons/dns/)
+* [Metrics Server]({{< baseurl >}}/rke/latest/en/config-options/add-ons/metrics-server/)
-The images used for these add-ons under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each add-on, but these can be overridden by changing the image tag in `system_images`.
+The images used for these add-ons under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each add-on, but these can be overridden by changing the image tag in `system_images`.
In addition to these pluggable add-ons, you can specify an add-on that you want deployed after the cluster deployment is complete.
@@ -27,7 +28,7 @@ As of version v0.1.7, add-ons are split into two categories:
- **Critical add-ons:** If these add-ons fail to deploy for any reason, RKE will error out.
- **Non-critical add-ons:** If these add-ons fail to deploy, RKE will only log a warning and continue deploying any other add-ons.
-Currently, only the [network plug-in]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/) is considered critical. KubeDNS, [ingress controllers]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/) and [user-defined add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/) are considered non-critical.
+Currently, only the [network plug-in]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/) is considered critical. KubeDNS, [ingress controllers]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/) and [user-defined add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/user-defined-add-ons/) are considered non-critical.
## Add-on deployment jobs
diff --git a/content/rke/latest/en/config-options/add-ons/dns/_index.md b/content/rke/latest/en/config-options/add-ons/dns/_index.md
new file mode 100644
index 00000000000..193690140b9
--- /dev/null
+++ b/content/rke/latest/en/config-options/add-ons/dns/_index.md
@@ -0,0 +1,70 @@
+---
+title: DNS provider
+weight: 262
+---
+
+By default, RKE deploys [kube-dns](https://github.com/kubernetes/dns) as DNS provider for your cluster.
+
+RKE will deploy kube-dns as a Deployment with the default replica count of 1. The pod consists of 3 containers: `kubedns`, `dnsmasq` and `sidecar`. RKE will also deploy kube-dns-autoscaler as a Deployment, which will scale the kube-dns Deployment by using the number of cores and nodes. Please see [Linear Mode](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler#linear-mode) for more information about this logic.
+
+The images used for kube-dns are under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with kube-dns, but these can be overridden by changing the image tag in `system_images`.
+
+## Scheduling kube-dns
+
+_Available as of v0.2.0_
+
+If you only want the kube-dns pod to be deployed on specific nodes, you can set a `node_selector` in the `dns` section. The label in the `node_selector` would need to match the label on the nodes for the kube-dns pod to be deployed.
+
+```yaml
+nodes:
+ - address: 1.1.1.1
+ role: [controlplane,worker,etcd]
+ user: root
+ labels:
+ app: dns
+
+dns:
+ provider: kube-dns
+ node_selector:
+ app: dns
+```
+
+## Disabling kube-dns
+
+_Available as of v0.2.0_
+
+You can disable the default DNS provider by specifying `none` to the dns `provider` directive in the cluster configuration. Be aware that this will prevent your pods from doing name resolution in your cluster.
+
+```yaml
+dns:
+ provider: none
+```
+## Configuring kube-dns
+
+### Upstream nameservers
+
+_Available as of v0.2.0_
+
+By default, kube-dns will use the host configured nameservers (usually residing at `/etc/resolv.conf`) to resolve external queries. If you want to configure specific upstream nameservers to be used by kube-dns, you can use the `upstreamnameservers` directive.
+
+```yaml
+dns:
+ provider: kube-dns
+ upstreamnameservers:
+ - 1.1.1.1
+ - 8.8.4.4
+```
+
+## CoreDNS (Experimental)
+
+_Available as of v0.2.0_
+
+If you want to use CoreDNS, you can set the `provider` directive to `coredns`. Both the `node_selector` and `upstreamnameservers` directive is also supported for CoreDNS.
+
+```yaml
+dns:
+ provider: coredns
+ upstreamnameservers:
+ - 1.1.1.1
+ - 8.8.4.4
+```
diff --git a/content/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/_index.md b/content/rke/latest/en/config-options/add-ons/ingress-controllers/_index.md
similarity index 98%
rename from content/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/_index.md
rename to content/rke/latest/en/config-options/add-ons/ingress-controllers/_index.md
index 32a2e0cbe9b..8044305eb63 100644
--- a/content/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/_index.md
+++ b/content/rke/latest/en/config-options/add-ons/ingress-controllers/_index.md
@@ -9,7 +9,7 @@ By default, RKE deploys the NGINX ingress controller on all schedulable nodes.
RKE will deploy the ingress controller as a DaemonSet with `hostnetwork: true`, so ports `80`, and `443` will be opened on each node where the controller is deployed.
-The images used for ingress controller is under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with the ingress controller, but these can be overridden by changing the image tag in `system_images`.
+The images used for ingress controller is under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with the ingress controller, but these can be overridden by changing the image tag in `system_images`.
## Scheduling Ingress Controllers
diff --git a/content/rke/latest/en/config-options/add-ons/metrics-server/_index.md b/content/rke/latest/en/config-options/add-ons/metrics-server/_index.md
new file mode 100644
index 00000000000..88775ac5577
--- /dev/null
+++ b/content/rke/latest/en/config-options/add-ons/metrics-server/_index.md
@@ -0,0 +1,21 @@
+---
+title: Metrics Server
+weight: 263
+---
+
+By default, RKE deploys [Metrics Server](https://github.com/kubernetes-incubator/metrics-server) to provide metrics on resources in your cluster.
+
+RKE will deploy Metrics Server as a Deployment.
+
+The image used for Metrics Server is under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there is a default image associated with the Metrics Server, but these can be overridden by changing the image tag in `system_images`.
+
+## Disabling the Metrics Server
+
+_Available as of v0.2.0_
+
+You can disable the default controller by specifying `none` to the monitoring `provider` directive in the cluster configuration.
+
+```yaml
+monitoring:
+ provider: none
+```
diff --git a/content/rke/v0.1.x/en/config-options/add-ons/network-plugins/_index.md b/content/rke/latest/en/config-options/add-ons/network-plugins/_index.md
similarity index 74%
rename from content/rke/v0.1.x/en/config-options/add-ons/network-plugins/_index.md
rename to content/rke/latest/en/config-options/add-ons/network-plugins/_index.md
index c013773bebb..b8f7a26ab82 100644
--- a/content/rke/v0.1.x/en/config-options/add-ons/network-plugins/_index.md
+++ b/content/rke/latest/en/config-options/add-ons/network-plugins/_index.md
@@ -18,7 +18,16 @@ network:
plugin: flannel
```
-The images used for network plug-ins are under the [`system_images` directive]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each network plug-in, but these can be overridden by changing the image tag in `system_images`.
+The images used for network plug-ins are under the [`system_images` directive]({{< baseurl >}}/rke/latest/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each network plug-in, but these can be overridden by changing the image tag in `system_images`.
+
+## Disabling deployment of a network plug-in
+
+You can disable deploying a network plug-in by specifying `none` to the network `plugin` directive in the cluster configuration.
+
+```yaml
+network:
+ plugin: none
+```
## Network Plug-in Options
@@ -45,8 +54,8 @@ The `canal_flannel_backend_type` option allows you to specify the type of [flann
network:
plugin: flannel
options:
- flannel_iface: eth1
- flannel_backend_type: vxlan
+ flannel_iface: eth1
+ flannel_backend_type: vxlan
```
#### Flannel Interface
@@ -59,10 +68,10 @@ The `flannel_backend_type` option allows you to specify the type of [flannel bac
```yaml
network:
plugin: calico
- calico_cloud_provider: aws
+ options:
+ calico_cloud_provider: aws
```
-
-#### Cloud Provider
+#### Calico Cloud Provider
Calico currently only supports 2 cloud providers, AWS or GCE, which can be set using `calico_cloud_provider`.
@@ -70,3 +79,16 @@ Calico currently only supports 2 cloud providers, AWS or GCE, which can be set u
- `aws`
- `gce`
+
+### Weave Network Plug-in Options
+
+```yaml
+network:
+ plugin: weave
+ weave_network_provider:
+ password: "Q]SZOQ5wp@n$oijz"
+```
+
+#### Weave encryption
+
+Weave encryption can be enabled by passing a string password to the network provider config.
diff --git a/content/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/_index.md b/content/rke/latest/en/config-options/add-ons/user-defined-add-ons/_index.md
similarity index 93%
rename from content/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/_index.md
rename to content/rke/latest/en/config-options/add-ons/user-defined-add-ons/_index.md
index b838ebcaf1f..6a03f9f418d 100644
--- a/content/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/_index.md
+++ b/content/rke/latest/en/config-options/add-ons/user-defined-add-ons/_index.md
@@ -3,7 +3,7 @@ title: User-Defined Add-Ons
weight: 263
---
-Besides the [network plug-in]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins) and [ingress controllers]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/), you can define any add-on that you want deployed after the Kubernetes cluster is deployed.
+Besides the [network plug-in]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins) and [ingress controllers]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/), you can define any add-on that you want deployed after the Kubernetes cluster is deployed.
There are two ways that you can specify an add-on.
diff --git a/content/rke/latest/en/config-options/authentication/_index.md b/content/rke/latest/en/config-options/authentication/_index.md
new file mode 100644
index 00000000000..efc2817a391
--- /dev/null
+++ b/content/rke/latest/en/config-options/authentication/_index.md
@@ -0,0 +1,24 @@
+---
+title: Authentication
+weight: 235
+---
+
+RKE supports x509 authentication strategy. You can additionally define a list of SANs (Subject Alternative Names) to add to the Kubernetes API Server PKI certificates. As an example, this allows you to connect to your Kubernetes cluster API Server through a load balancer instead of a single node.
+
+```yaml
+authentication:
+ strategy: x509
+ sans:
+ - "10.18.160.10"
+ - "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
+```
+
+RKE also supports the webhook authentication strategy. You can enable both x509 and webhook strategies by using a `|` separator in the configuration. Contents of the webhook config file should be provided, see [Kubernetes webhook documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) for information on the file format. Additionally, a cache timeout for webhook authentication responses can be set.
+
+```yaml
+authentication:
+ strategy: x509|webhook
+ webhook:
+ config_file: "...."
+ cache_timeout: 5s
+```
diff --git a/content/rke/v0.1.x/en/config-options/authorization/_index.md b/content/rke/latest/en/config-options/authorization/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/authorization/_index.md
rename to content/rke/latest/en/config-options/authorization/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/bastion-host/_index.md b/content/rke/latest/en/config-options/bastion-host/_index.md
similarity index 59%
rename from content/rke/v0.1.x/en/config-options/bastion-host/_index.md
rename to content/rke/latest/en/config-options/bastion-host/_index.md
index 29115478bab..bade5d19232 100644
--- a/content/rke/v0.1.x/en/config-options/bastion-host/_index.md
+++ b/content/rke/latest/en/config-options/bastion-host/_index.md
@@ -3,7 +3,7 @@ title: Bastion/Jump Host Configuration
weight: 220
---
-Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/), you can configure to use a bastion host. Keep in mind that the [port requirements]({{< baseurl >}}/rke/v0.1.x/en/os/#ports) for the RKE node move to the configured bastion host.
+Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/), you can configure to use a bastion host. Keep in mind that the [port requirements]({{< baseurl >}}/rke/latest/en/os/#ports) for the RKE node move to the configured bastion host.
```yaml
bastion_host:
@@ -16,6 +16,11 @@ bastion_host:
# -----BEGIN RSA PRIVATE KEY-----
#
# -----END RSA PRIVATE KEY-----
+ # Optionally using SSH certificates
+ # ssh_cert_path: /home/user/.ssh/id_rsa-cert.pub
+ # or
+ # ssh_cert: |-
+ # ssh-rsa-cert-v01@openssh.com AAAAHHNza...
```
## Bastion Host Options
@@ -39,3 +44,11 @@ You specify the path, i.e. `ssh_key_path`, for the SSH private key to be used wh
### SSH Key
Instead of setting the path to the SSH key, you can specify the actual key, i.e. `ssh_key`, to be used to connect to the bastion host.
+
+### SSH Certificate Path
+
+You specify the path, i.e. `ssh_cert_path`, for the signed SSH certificate to be used when connecting to the bastion host.
+
+### SSH Certificate
+
+Instead of setting the path to the signed SSH certificate, you can specify the actual certificate, i.e. `ssh_cert`, to be used to connect to the bastion host.
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/_index.md b/content/rke/latest/en/config-options/cloud-providers/_index.md
similarity index 65%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/_index.md
index aeced55a22d..27881c437e2 100644
--- a/content/rke/v0.1.x/en/config-options/cloud-providers/_index.md
+++ b/content/rke/latest/en/config-options/cloud-providers/_index.md
@@ -6,9 +6,9 @@ weight: 250
RKE supports the ability to set your specific [cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/) for your Kubernetes cluster. There are specific cloud configurations for these cloud providers.
To enable a cloud provider its name as well as any required configuration options must be provided under the `cloud_provider` directive in the cluster YML.
-* [AWS]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/aws)
-* [Azure]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/azure)
-* [OpenStack]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/openstack)
-* [vSphere]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere)
+* [AWS]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/aws)
+* [Azure]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/azure)
+* [OpenStack]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/openstack)
+* [vSphere]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/vsphere)
-Outside of this list, RKE also supports the ability to handle any [custom cloud provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/custom).
+Outside of this list, RKE also supports the ability to handle any [custom cloud provider]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/custom).
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/aws/_index.md b/content/rke/latest/en/config-options/cloud-providers/aws/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/aws/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/aws/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/azure/_index.md b/content/rke/latest/en/config-options/cloud-providers/azure/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/azure/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/azure/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/custom/_index.md b/content/rke/latest/en/config-options/cloud-providers/custom/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/custom/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/custom/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/openstack/_index.md b/content/rke/latest/en/config-options/cloud-providers/openstack/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/openstack/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/openstack/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/cloud-providers/vsphere/_index.md b/content/rke/latest/en/config-options/cloud-providers/vsphere/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/cloud-providers/vsphere/_index.md
rename to content/rke/latest/en/config-options/cloud-providers/vsphere/_index.md
diff --git a/content/rke/v0.1.x/en/config-options/nodes/_index.md b/content/rke/latest/en/config-options/nodes/_index.md
similarity index 85%
rename from content/rke/v0.1.x/en/config-options/nodes/_index.md
rename to content/rke/latest/en/config-options/nodes/_index.md
index d06152d1931..84208496786 100644
--- a/content/rke/v0.1.x/en/config-options/nodes/_index.md
+++ b/content/rke/latest/en/config-options/nodes/_index.md
@@ -23,6 +23,19 @@ nodes:
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
+ - address: 3.3.3.3
+ user: ubuntu
+ role:
+ - worker
+ ssh_key_path: /home/user/.ssh/id_rsa
+ ssh_cert_path: /home/user/.ssh/id_rsa-cert.pub
+ - address: 4.4.4.4
+ user: ubuntu
+ role:
+ - worker
+ ssh_key_path: /home/user/.ssh/id_rsa
+ ssh_cert: |-
+ ssh-rsa-cert-v01@openssh.com AAAAHHNza...
- address: example.com
user: ubuntu
role:
@@ -49,7 +62,7 @@ The `internal_address` provides the ability to have nodes with multiple addresse
The `hostname_override` is used to be able to provide a friendly name for RKE to use when registering the node in Kubernetes. This hostname doesn't need to be a routable address, but it must be a valid [Kubernetes resource name](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). If the `hostname_override` isn't set, then the `address` directive is used when registering the node in Kubernetes.
-> **Note:** When [cloud providers]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/) are configured, you may need to override the hostname in order to use the cloud provider correctly. There is an exception for the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws), where the `hostname_override` field will be explicitly ignored.
+> **Note:** When [cloud providers]({{< baseurl >}}/rke/latest/en/config-options/cloud-providers/) are configured, you may need to override the hostname in order to use the cloud provider correctly. There is an exception for the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws), where the `hostname_override` field will be explicitly ignored.
### SSH Port
@@ -63,12 +76,20 @@ For each node, you specify the `user` to be used when connecting to this node. T
For each node, you specify the path, i.e. `ssh_key_path`, for the SSH private key to be used when connecting to this node. The default key path for each node is `~/.ssh/id_rsa`.
-> **Note:** If you have a private key that can be used across all nodes, you can set the [SSH key path at the cluster level]({{< baseurl >}}/rke/v0.1.x/en/config-options/#cluster-level-ssh-key-path). The SSH key path set in each node will always take precedence.
+> **Note:** If you have a private key that can be used across all nodes, you can set the [SSH key path at the cluster level]({{< baseurl >}}/rke/latest/en/config-options/#cluster-level-ssh-key-path). The SSH key path set in each node will always take precedence.
### SSH Key
Instead of setting the path to the SSH key, you can alternatively specify the actual key, i.e. `ssh_key`, to be used to connect to the node.
+### SSH Certificate Path
+
+For each node, you can specify the path, i.e. `ssh_cert_path`, for the signed SSH certificate to be used when connecting to this node.
+
+### SSH Certificate
+
+Instead of setting the path to the signed SSH certificate, you can alternatively specify the actual certificate, i.e. `ssh_cert`, to be used to connect to the node.
+
### Kubernetes Roles
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.
@@ -101,4 +122,4 @@ If the Docker socket is different than the default, you can set the `docker_sock
### Labels
-You have the ability to add an arbitrary map of labels for each node. It can be used when using the [ingress controller's]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/) `node_selector` option.
+You have the ability to add an arbitrary map of labels for each node. It can be used when using the [ingress controller's]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/) `node_selector` option.
diff --git a/content/rke/v0.1.x/en/config-options/private-registries/_index.md b/content/rke/latest/en/config-options/private-registries/_index.md
similarity index 87%
rename from content/rke/v0.1.x/en/config-options/private-registries/_index.md
rename to content/rke/latest/en/config-options/private-registries/_index.md
index b28e51f7388..b835a3480a2 100644
--- a/content/rke/v0.1.x/en/config-options/private-registries/_index.md
+++ b/content/rke/latest/en/config-options/private-registries/_index.md
@@ -19,7 +19,7 @@ private_registries:
### Default Registry
-As of v0.1.10, RKE supports specifying a default registry from the list of private registries to be used with all [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) . In this example .RKE will use `registry.com` as the default registry for all system images, e.g. `rancher/rke-tools:v0.1.14` will become `registry.com/rancher/rke-tools:v0.1.14`.
+As of v0.1.10, RKE supports specifying a default registry from the list of private registries to be used with all [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) . In this example .RKE will use `registry.com` as the default registry for all system images, e.g. `rancher/rke-tools:v0.1.14` will become `registry.com/rancher/rke-tools:v0.1.14`.
```yaml
private_registries:
@@ -31,9 +31,9 @@ private_registries:
### Air-gapped Setups
-By default, all system images are being pulled from DockerHub. If you are on a system that does not have access to DockerHub, you will need to create a private registry that is populated with all the required [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/).
+By default, all system images are being pulled from DockerHub. If you are on a system that does not have access to DockerHub, you will need to create a private registry that is populated with all the required [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/).
-As of v0.1.10, you have to configure your private registry credentials, but you can specify this registry as a default registry so that all [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) are pulled from the designated private registry. You can use the command `rke config --system-images` to get the list of default system images to populate your private registry.
+As of v0.1.10, you have to configure your private registry credentials, but you can specify this registry as a default registry so that all [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) are pulled from the designated private registry. You can use the command `rke config --system-images` to get the list of default system images to populate your private registry.
-Prior to v0.1.10, you had to configure your private registry credentials **and** update the names of all the [system images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/) in the `cluster.yml` so that the image names would have the private registry URL appended before each image name.
+Prior to v0.1.10, you had to configure your private registry credentials **and** update the names of all the [system images]({{< baseurl >}}/rke/latest/en/config-options/system-images/) in the `cluster.yml` so that the image names would have the private registry URL appended before each image name.
diff --git a/content/rke/v0.1.x/en/config-options/services/_index.md b/content/rke/latest/en/config-options/services/_index.md
similarity index 86%
rename from content/rke/v0.1.x/en/config-options/services/_index.md
rename to content/rke/latest/en/config-options/services/_index.md
index eb16e86019a..6fb743534f6 100644
--- a/content/rke/v0.1.x/en/config-options/services/_index.md
+++ b/content/rke/latest/en/config-options/services/_index.md
@@ -5,7 +5,7 @@ weight: 230
To deploy Kubernetes, RKE deploys several core components or services in Docker containers on the nodes. Based on the roles of the node, the containers deployed may be different.
-**All services support additional [custom arguments, Docker mount binds and extra environment variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/).**
+**All services support additional [custom arguments, Docker mount binds and extra environment variables]({{< baseurl >}}/rke/latest/en/config-options/services/services-extras/).**
## etcd
@@ -13,7 +13,9 @@ Kubernetes uses [etcd](https://github.com/coreos/etcd/blob/master/Documentation/
RKE supports running etcd in a single node mode or in HA cluster mode. It also supports adding and removing etcd nodes to the cluster.
-By default, RKE will deploy a new etcd service, but you can also run Kubernetes with an [external etcd service]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/external-etcd/).
+You can enable etcd to [take recurring snapshots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#recurring-snapshots). These snapshots can be used to [restore etcd]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-disaster-recovery).
+
+By default, RKE will deploy a new etcd service, but you can also run Kubernetes with an [external etcd service]({{< baseurl >}}/rke/latest/en/config-options/services/external-etcd/).
## Kubernetes API Server
@@ -28,8 +30,11 @@ services:
# This must match the service_cluster_ip_range in kube-controller
service_cluster_ip_range: 10.43.0.0/16
# Expose a different port range for NodePort services
- service_node_port_range: 30000-32767
+ service_node_port_range: 30000-32767
pod_security_policy: false
+ # Enable AlwaysPullImages Admission controller plugin
+ # Available as of v0.2.0
+ always_pull_images: false
```
### Kubernetes API Server Options
@@ -39,8 +44,8 @@ RKE supports the following options for the `kube-api` service :
- **Service Cluster IP Range** (`service_cluster_ip_range`) - This is the virtual IP address that will be assigned to services created on Kubernetes. By default, the service cluster IP range is `10.43.0.0/16`. If you change this value, then it must also be set with the same value on the Kubernetes Controller Manager (`kube-controller`).
- **Node Port Range** (`service_node_port_range`) - The port range to be used for Kubernetes services created with the [type](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types) `NodePort`. By default, the port range is `30000-32767`.
- **Pod Security Policy** (`pod_security_policy`) - An option to enable the [Kubernetes Pod Security Policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). By default, we do not enable pod security policies as it is set to `false`.
-
> **Note:** If you set `pod_security_policy` value to `true`, RKE will configure an open policy to allow any pods to work on the cluster. You will need to configure your own policies to fully utilize PSP.
+- **Always Pull Images** (`always_pull_images`) - Enable `AlwaysPullImages` Admission controller plugin. Enabling `AlwaysPullImages` is a security best practice. It forces Kubernetes to validate the image and pull credentials with the remote image registry. Local image layer cache will still be used, but it does add a small bit of overhead when launching containers to pull and compare image hashes. _Note: Available as of v0.2.0_
## Kubernetes Controller Manager
@@ -60,7 +65,7 @@ services:
### Kubernetes Controller Manager Options
-RKE support the following options for the `kube-controller` service:
+RKE supports the following options for the `kube-controller` service:
- **Cluster CIDR** (`cluster_cidr`) - The CIDR pool used to assign IP addresses to pods in the cluster. By default, each node in the cluster is assigned a `/24` network from this pool for pod IP assignments. The default value for this option is `10.42.0.0/16`.
- **Service Cluster IP Range** (`service_cluster_ip_range`) - This is the virtual IP address that will be assigned to services created on Kubernetes. By default, the service cluster IP range is `10.43.0.0/16`. If you change this value, then it must also be set with the same value on the Kubernetes API server (`kube-api`).
diff --git a/content/rke/v0.1.x/en/config-options/services/external-etcd/_index.md b/content/rke/latest/en/config-options/services/external-etcd/_index.md
similarity index 94%
rename from content/rke/v0.1.x/en/config-options/services/external-etcd/_index.md
rename to content/rke/latest/en/config-options/services/external-etcd/_index.md
index aa7280eb3ca..173fa826972 100644
--- a/content/rke/v0.1.x/en/config-options/services/external-etcd/_index.md
+++ b/content/rke/latest/en/config-options/services/external-etcd/_index.md
@@ -5,7 +5,7 @@ weight: 232
By default, RKE will launch etcd servers, but RKE also supports being able to use an external etcd. RKE only supports connecting to a TLS enabled etcd setup.
-> **Note:** RKE will not accept having external etcd servers in conjunction with [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/) with the `etcd` role.
+> **Note:** RKE will not accept having external etcd servers in conjunction with [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/) with the `etcd` role.
```yaml
services:
diff --git a/content/rke/v0.1.x/en/config-options/services/services-extras/_index.md b/content/rke/latest/en/config-options/services/services-extras/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/config-options/services/services-extras/_index.md
rename to content/rke/latest/en/config-options/services/services-extras/_index.md
diff --git a/content/rke/latest/en/config-options/system-images/_index.md b/content/rke/latest/en/config-options/system-images/_index.md
new file mode 100644
index 00000000000..3fbcaff40e0
--- /dev/null
+++ b/content/rke/latest/en/config-options/system-images/_index.md
@@ -0,0 +1,74 @@
+---
+title: System Images
+weight: 225
+---
+When RKE is deploying Kubernetes, there are several images that are pulled. These images are used as Kubernetes system components as well as helping to deploy these system components.
+
+As of `v0.1.6`, the functionality of a couple of the system images were consolidated into a single `rancher/rke-tools` image to simplify and speed the deployment process.
+
+You can configure the [network plug-ins]({{< baseurl >}}/rke/latest/en/config-options/add-ons/network-plugins/), [ingress controller]({{< baseurl >}}/rke/latest/en/config-options/add-ons/ingress-controllers/) and [dns provider]({{< baseurl >}}/rke/latest/en/config-options/add-ons/dns/) as well as the options for these add-ons separately.
+
+This is the example of the full list of system images used to deploy Kubernetes through RKE. The image tags are dependent on the [Kubernetes image/version used](https://github.com/rancher/types/blob/master/apis/management.cattle.io/v3/k8s_defaults.go).
+
+> **Note:** As versions of RKE are released, the tags on these images will no longer be up to date. This list is specific for `v1.10.3-rancher2`.
+
+```yaml
+system_images:
+ etcd: rancher/coreos-etcd:v3.2.24
+ alpine: rancher/rke-tools:v0.1.24
+ nginx_proxy: rancher/rke-tools:v0.1.24
+ cert_downloader: rancher/rke-tools:v0.1.24
+ kubernetes: rancher/hyperkube:v1.13.1-rancher1
+ kubernetes_services_sidecar: rancher/rke-tools:v0.1.24
+ pod_infra_container: rancher/pause-amd64:3.1
+
+ # kube-dns images
+ kubedns: rancher/k8s-dns-kube-dns-amd64:1.15.0
+ dnsmasq: rancher/k8s-dns-dnsmasq-nanny-amd64:1.15.0
+ kubedns_sidecar: rancher/k8s-dns-sidecar-amd64:1.15.0
+ kubedns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
+
+ # CoreDNS images
+ coredns: coredns/coredns:1.2.6
+ coredns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
+
+ # Flannel images
+ flannel: rancher/coreos-flannel:v0.10.0
+ flannel_cni: rancher/coreos-flannel-cni:v0.3.0
+
+ # Calico images
+ calico_node: rancher/calico-node:v3.4.0
+ calico_cni: rancher/calico-cni:v3.4.0
+ calico_controllers: ""
+ calico_ctl: rancher/calico-ctl:v2.0.0
+
+ # Canal images
+ canal_node: rancher/calico-node:v3.4.0
+ canal_cni: rancher/calico-cni:v3.4.0
+ canal_flannel: rancher/coreos-flannel:v0.10.0
+
+ # Weave images
+ weave_node: weaveworks/weave-kube:2.5.0
+ weave_cni: weaveworks/weave-npc:2.5.0
+
+ # Ingress controller images
+ ingress: rancher/nginx-ingress-controller:0.21.0-rancher1
+ ingress_backend: rancher/nginx-ingress-controller-defaultbackend:1.4
+
+ # Metrics server image
+ metrics_server: rancher/metrics-server-amd64:v0.3.1
+```
+
+Prior to `v0.1.6`, instead of using the `rancher/rke-tools` image, we used the following images:
+
+```yaml
+system_images:
+ alpine: alpine:latest
+ nginx_proxy: rancher/rke-nginx-proxy:v0.1.1
+ cert_downloader: rancher/rke-cert-deployer:v0.1.1
+ kubernetes_services_sidecar: rancher/rke-service-sidekick:v0.1.0
+```
+
+### Air-gapped Setups
+
+If you have an air-gapped setup and cannot access `docker.io`, you will need to set up your [private registry]({{< baseurl >}}/rke/latest/en/config-options/private-registries/) in your cluster configuration file. After you set up private registry, you will need to update these images to pull from your private registry.
diff --git a/content/rke/latest/en/etcd-snapshots/_index.md b/content/rke/latest/en/etcd-snapshots/_index.md
new file mode 100644
index 00000000000..f17de91087c
--- /dev/null
+++ b/content/rke/latest/en/etcd-snapshots/_index.md
@@ -0,0 +1,296 @@
+---
+title: Backups and Disaster Recovery
+weight: 150
+aliases:
+ - /rke/latest/en/installation/etcd-snapshots/
+---
+
+_Available as of v0.1.7_
+
+RKE clusters can be configured to automatically take snapshots of etcd. In a disaster scenario, you can restore these snapshots, which are stored on other nodes in the cluster. Snapshots are always saved locally in `/opt/rke/etcd-snapshots`.
+
+_Available as of v0.2.0_
+
+RKE can also upload your snapshots to a S3 compatible backend. Additionally, the **pki.bundle.tar.gz** file usage is no longer required as v0.2.0 has changed how the [Kubernetes cluster state is stored]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state).
+
+## One-Time Snapshots
+
+The `rke etcd snapshot-save` command will save a snapshot of etcd from each etcd node in the cluster config file. The snapshot is saved in `/opt/rke/etcd-snapshots`. When running the command, an additional container is created to take the snapshot. When the snapshot is completed, the container is automatically removed.
+
+Prior to v0.2.0, along with the individual snapshot, RKE saves a backup of the certificates, i.e. a file named `pki.bundle.tar.gz`, in the same location. The snapshot and pki bundle file are required for the restore process in versions prior to v0.2.0.
+
+As of v0.2.0, the one-time snapshot can be uploaded to a S3 compatible backend by using the additional options to specify the S3 backend.
+
+### Options for `rke etcd snapshot-save`
+
+| Option | Description | S3 Specific |
+| --- | --- | --- |
+| `--name` value | Specify snapshot name | |
+| `--config` value | Specify an alternate cluster YAML file (default: "cluster.yml") [$RKE_CONFIG] | |
+| `--s3` | Enabled backup to s3 | * |
+| `--s3-endpoint` value | Specify s3 endpoint url (default: "s3.amazonaws.com") | * |
+| `--access-key` value | Specify s3 accessKey | * |
+| `--secret-key` value | Specify s3 secretKey | * |
+| `--bucket-name` value | Specify s3 bucket name | * |
+| `--region` value | Specify the s3 bucket location (optional) | * |
+| `--ssh-agent-auth` | [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{< baseurl >}}/rke/latest/en/config-options/#ssh-agent) | |
+| `--ignore-docker-version` | [Disable Docker version check]({{< baseurl >}}/rke/latest/en/config-options/#supported-docker-versions) |
+
+### Local One-Time Snapshot Example
+
+```
+$ rke etcd snapshot-save --config cluster.yml --name snapshot-name
+```
+
+The snapshot is saved in `/opt/rke/etcd-snapshots`
+
+### One-Time Snapshots uploaded to S3 Example
+
+_Available as of v0.2.0_
+
+```
+$ rke etcd snapshot-save --config cluster.yml --name snapshot-name \
+--s3 --access-key S3_ACCESS_KEY --secret-key S3_SECRET_KEY \
+--bucket-name s3-bucket-name --s3-endpoint s3.amazonaws.com
+```
+
+The snapshot is saved in `/opt/rke/etcd-snapshots` as well as uploaded to the S3 backend.
+
+## Recurring Snapshots
+
+To schedule automatic recurring etcd snapshots, you can enable the `etcd-snapshot` service with [extra configuration options the etcd service](#options-for-the-etcd-snapshot-service). `etcd-snapshot` runs in a service container alongside the `etcd` container. By default, the `etcd-snapshot` service takes a snapshot for every node that has the `etcd` role and stores them to local disk in `/opt/rke/etcd-snapshots`. If you set up the [options for S3](#options-for-the-etcd-snapshot-service), the snapshot will also be uploaded to the S3 backend.
+
+Prior to v0.2.0, along with the snapshots, RKE saves a backup of the certificates, i.e. a file named `pki.bundle.tar.gz`, in the same location. The snapshot and pki bundle file are required for the restore process in versions prior to v0.2.0.
+
+When a cluster is launched with the `etcd-snapshot` service enabled, you can view the `etcd-rolling-snapshots` logs to confirm backups are being created automatically.
+
+```
+$ docker logs etcd-rolling-snapshots
+
+time="2018-05-04T18:39:16Z" level=info msg="Initializing Rolling Backups" creation=1m0s retention=24h0m0s
+time="2018-05-04T18:40:16Z" level=info msg="Created backup" name="2018-05-04T18:40:16Z_etcd" runtime=108.332814ms
+time="2018-05-04T18:41:16Z" level=info msg="Created backup" name="2018-05-04T18:41:16Z_etcd" runtime=92.880112ms
+time="2018-05-04T18:42:16Z" level=info msg="Created backup" name="2018-05-04T18:42:16Z_etcd" runtime=83.67642ms
+time="2018-05-04T18:43:16Z" level=info msg="Created backup" name="2018-05-04T18:43:16Z_etcd" runtime=86.298499ms
+```
+
+### Options for the `Etcd-Snapshot` Service
+
+Depending on your version of RKE, the options used to configure recurring snapshots may be different.
+
+_Available as of v0.2.0_
+
+|Option|Description| S3 Specific |
+|---|---| --- |
+|**interval_hours**| The duration in hours between recurring backups. This supercedes the `creation` option and will override it if both are specified.| |
+|**retention**| The number of snapshots to retain before rotation. This supercedes the `retention` option and will override it if both are specified.| |
+|**bucket_name**| S3 bucket name where backups will be stored| * |
+|**access_key**| S3 access key with permission to access the backup bucket.| * |
+|**secret_key** |S3 secret key with permission to access the backup bucket.| * |
+|**region** |S3 region for the backup bucket. This is optional.| * |
+|**endpoint** |S3 regions endpoint for the backup bucket.| * |
+
+
+
+
+```yaml
+services:
+ etcd:
+ backup_config:
+ interval_hours: 12
+ retention: 6
+ s3backupconfig:
+ access_key: S3_ACCESS_KEY
+ secret_key: S3_SECRET_KEY
+ bucket_name: s3-bucket-name
+ region: ""
+ endpoint: s3.amazonaws.com
+```
+
+#### Prior to v0.2.0
+
+|Option|Description|
+|---|---|
+|**Snapshot**|By default, the recurring snapshot service is disabled. To enable the service, you need to define it as part of `etcd` and set it to `true`.|
+|**Creation**|By default, the snapshot service will take snapshots every 5 minutes (`5m0s`). You can change the time between snapshots as part of the `creation` directive for the `etcd` service.|
+|**Retention**|By default, all snapshots are saved for 24 hours (`24h`) before being deleted and purged. You can change how long to store a snapshot as part of the `retention` directive for the `etcd` service.|
+
+```yaml
+services:
+ etcd:
+ snapshot: true
+ creation: 5m0s
+ retention: 24h
+```
+
+## Etcd Disaster Recovery
+
+If there is a disaster with your Kubernetes cluster, you can use `rke etcd snapshot-restore` to recover your etcd. This command reverts etcd to a specific snapshot. RKE also removes the old `etcd` container before creating a new `etcd` cluster using the snapshot that you have chosen.
+
+>**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, you should back up any important data in your cluster.
+
+The snapshot used to restore your etcd cluster can either be stored locally in `/opt/rke/etcd-snapshots` or from a S3 compatible backend. The S3 backend option is available as of v0.2.0.
+
+### Options for `rke etcd snapshot-restore`
+
+| Option | Description | S3 Specific |
+| --- | --- | ---|
+| `--name` value | Specify snapshot name | |
+| `--config` value | Specify an alternate cluster YAML file (default: "cluster.yml") [$RKE_CONFIG] | |
+| `--s3` | Enabled backup to s3 |* |
+| `--s3-endpoint` value | Specify s3 endpoint url (default: "s3.amazonaws.com") | * |
+| `--access-key` value | Specify s3 accessKey | *|
+| `--secret-key` value | Specify s3 secretKey | *|
+| `--bucket-name` value | Specify s3 bucket name | *|
+| `--region` value | Specify the s3 bucket location (optional) | *|
+| `--ssh-agent-auth` | [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{< baseurl >}}/rke/latest/en/config-options/#ssh-agent) | |
+| `--ignore-docker-version` | [Disable Docker version check]({{< baseurl >}}/rke/latest/en/config-options/#supported-docker-versions) |
+
+### Example of Restoring from a Local Snapshot
+
+When restoring etcd from a local snapshot, the snapshot is assumed to be located in `/opt/rke/etcd-snapshots`. In versions prior to v0.2.0, the `pki.bundle.tar.gz` file is also expected to be in the same location. As of v0.2.0, this file is no longer needed as v0.2.0 has changed how the [Kubernetes cluster state is stored]({{< baseurl >}}/rke/latest/en/installation/#kubernetes-cluster-state).
+
+```
+$ rke etcd snapshot-restore --config cluster.yml --name mysnapshot
+```
+
+### Example of Restoring from a Snapshot in S3
+
+_Available as of v0.2.0_
+
+When restoring etcd from a snapshot located in S3, the command needs the S3 information in order to connect to the S3 backend and retrieve the snapshot.
+
+```
+$ rke etcd snapshot-restore --config cluster.yml --name snapshot-name \
+--s3 --access-key S3_ACCESS_KEY --secret-key S3_SECRET_KEY \
+--bucket-name s3-bucket-name --s3-endpoint s3.amazonaws.com
+```
+## Example
+
+In this example, the Kubernetes cluster was deployed on two AWS nodes.
+
+| Name | IP | Role |
+|:-----:|:--------:|:----------------------:|
+| node1 | 10.0.0.1 | [controlplane, worker] |
+| node2 | 10.0.0.2 | [etcd] |
+
+### Back up the `etcd` cluster
+
+Take a local snapshot of the Kubernetes cluster. As of v0.2.0, you can also upload this snapshot directly to a S3 backend with the [S3 options](#options-for-rke-etcd-snapshot-save).
+
+```
+$ rke etcd snapshot-save --name snapshot.db --config cluster.yml
+```
+
+
+
+
+### Store the Snapshot Externally to S3
+
+As of v0.2.0, this step is no longer required, as RKE can upload and download snapshots automatically from S3 by adding in [S3 options](#options-for-rke-etcd-snapshot-save) when running the `rke etcd snapshot-save` command.
+
+After taking the etcd snapshot on `node2`, we recommend saving this backup in a persistence place. One of the options is to save the backup and `pki.bundle.tar.gz` file on a S3 bucket or tape backup.
+
+> **Note:** As of v0.2.0, the file **pki.bundle.tar.gz** is no longer required for the restore process.
+
+```
+# If you're using an AWS host and have the ability to connect to S3
+root@node2:~# s3cmd mb s3://rke-etcd-backup
+root@node2:~# s3cmd /opt/rke/etcd-snapshots/snapshot.db /opt/rke/etcd-snapshots/pki.bundle.tar.gz s3://rke-etcd-backup/
+```
+
+### Place the backup on a new node
+
+To simulate the failure, let's power down `node2`.
+
+```
+root@node2:~# poweroff
+```
+
+| Name | IP | Role |
+|:-----:|:--------:|:----------------------:|
+| node1 | 10.0.0.1 | [controlplane, worker] |
+| ~~node2~~ | ~~10.0.0.2~~ | ~~[etcd]~~ |
+| node3 | 10.0.0.3 | [etcd] |
+| | | |
+
+
+Before restoring etcd and running `rke up`, we need to retrieve the backup saved on S3 to a new node, e.g. `node3`. As of v0.2.0, you can directly retrieve the snapshot from S3 when running the restore command, so this step is for users who stored the snapshot externally without using the integrated S3 options.
+
+```
+# Make a Directory
+root@node3:~# mkdir -p /opt/rke/etcdbackup
+# Get the Backup from S3
+root@node3:~# s3cmd get s3://rke-etcd-backup/snapshot.db /opt/rke/etcd-snapshots/snapshot.db
+# Get the pki bundle from S3, only needed prior to v0.2.0
+root@node3:~# s3cmd get s3://rke-etcd-backup/pki.bundle.tar.gz /opt/rke/etcd-snapshots/pki.bundle.tar.gz
+```
+
+### Restore `etcd` on the new node from the backup
+
+Before updating and restoring etcd, you will need to add the new node into the Kubernetes cluster with the `etcd` role. In the `cluster.yml`, comment out the old node and add in the new node. `
+
+```yaml
+nodes:
+ - address: 10.0.0.1
+ hostname_override: node1
+ user: ubuntu
+ role:
+ - controlplane
+ - worker
+# - address: 10.0.0.2
+# hostname_override: node2
+# user: ubuntu
+# role:
+# - etcd
+ - address: 10.0.0.3
+ hostname_override: node3
+ user: ubuntu
+ role:
+ - etcd
+```
+
+After the new node is added to the `cluster.yml`, run `rke etcd snapshot-restore` to launch `etcd` from the backup. The snapshot and `pki.bundle.tar.gz` file are expected to be saved at `/opt/rke/etcd-snapshots`.
+As of v0.2.0, if you want to directly retrieve the snapshot from S3, add in the [S3 options](#options-for-rke-etcd-snapshot-restore).
+
+> **Note:** As of v0.2.0, the file **pki.bundle.tar.gz** is no longer required for the restore process.
+
+```
+$ rke etcd snapshot-restore --name snapshot.db --config cluster.yml
+```
+
+Finally, we need to restore the operations on the cluster by making the Kubernetes API point to the new `etcd` by running `rke up` again using the new `cluster.yml`.
+
+```
+$ rke up --config cluster.yml
+```
+
+Confirm that your Kubernetes cluster is functional by checking the pods on your cluster.
+
+```
+> kubectl get pods
+NAME READY STATUS RESTARTS AGE
+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.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.
+
+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**.
diff --git a/content/rke/v0.1.x/en/example-yamls/_index.md b/content/rke/latest/en/example-yamls/_index.md
similarity index 98%
rename from content/rke/v0.1.x/en/example-yamls/_index.md
rename to content/rke/latest/en/example-yamls/_index.md
index 311e6241816..1fa897d4571 100644
--- a/content/rke/v0.1.x/en/example-yamls/_index.md
+++ b/content/rke/latest/en/example-yamls/_index.md
@@ -2,10 +2,10 @@
title: Example Cluster.ymls
weight: 300
aliases:
- - /rke/v0.1.x/en/config-options/example-yamls/
+ - /rke/latest/en/config-options/example-yamls/
---
-There are lots of different [configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) that can be set in the cluster configuration file for RKE. Here are some examples of files:
+There are lots of different [configuration options]({{< baseurl >}}/rke/latest/en/config-options/) that can be set in the cluster configuration file for RKE. Here are some examples of files:
> **Note for Rancher 2 users** If you are configuring Cluster Options using a [Config File]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file) when creating [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), the names of services should contain underscores only: `kube_api` and `kube_controller`. This only applies to Rancher v2.0.5 and v2.0.6.
diff --git a/content/rke/v0.1.x/en/installation/_index.md b/content/rke/latest/en/installation/_index.md
similarity index 52%
rename from content/rke/v0.1.x/en/installation/_index.md
rename to content/rke/latest/en/installation/_index.md
index 268520409b8..738f294a5ab 100644
--- a/content/rke/v0.1.x/en/installation/_index.md
+++ b/content/rke/latest/en/installation/_index.md
@@ -6,18 +6,23 @@ weight: 50
RKE is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. You can get started in a couple of quick and easy steps:
1. [Download the RKE Binary](#download-the-rke-binary)
-2. [Prepare the Nodes for the Kubernetes Cluster](#prepare-the-nodes-for-the-kubernetes-cluster)
-3. [Creating the Cluster Configuration File](#creating-the-cluster-configuration-file)
-4. [Deploying Kubernetes with RKE](#deploying-kubernetes-with-rke)
-5. [Interacting with your Kubernetes Cluster](#interacting-with-your-kubernetes-cluster)
+ 1. [Alternative RKE MacOS X Install - Homebrew](#alternative-rke-macos-x-install---homebrew)
+1. [Prepare the Nodes for the Kubernetes Cluster](#prepare-the-nodes-for-the-kubernetes-cluster)
+1. [Creating the Cluster Configuration File](#creating-the-cluster-configuration-file)
+1. [Deploying Kubernetes with RKE](#deploying-kubernetes-with-rke)
+1. [Save your Files](#save-your-files)
+1. [Interacting with your Kubernetes Cluster](#interacting-with-your-kubernetes-cluster)
## Download the RKE binary
-1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases/latest) page. Download the latest RKE installer applicable to your Operating System:
+1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases/latest) page. Download the latest RKE installer applicable to your Operating System and Architecture:
- **MacOS**: `rke_darwin-amd64`
- - **Linux**: `rke_linux-amd64`
- - **Windows**: `rke_windows-amd64.exe`
+ - **Linux (Intel/AMD)**: `rke_linux-amd64`
+ - **Linux (ARM 32-bit)**: `rke_linux-arm`
+ - **Linux (ARM 64-bit)**: `rke_linux-arm64`
+ - **Windows (32-bit)**: `rke_windows-386.exe`
+ - **Windows (64-bit)**: `rke_windows-amd64.exe`
2. Copy the RKE binary to a folder in your `$PATH` and rename it `rke` (or `rke.exe` for Windows)
@@ -45,24 +50,43 @@ RKE is a fast, versatile Kubernetes installer that you can use to install Kubern
$ rke --version
```
+
+### Alternative RKE MacOS X Install - Homebrew
+
+RKE can also be installed and updated using Homebrew, a package manager for MacOS X.
+
+1. Install Homebrew. See https://brew.sh/ for instructions.
+
+2. Using `brew`, install RKE by running the following command in a Terminal window:
+
+ ```
+ $ brew install rke
+ ```
+
+If you have already installed RKE using `brew`, you can upgrade RKE by running:
+
+```
+$ brew upgrade rke
+```
+
## Prepare the Nodes for the Kubernetes cluster
The Kubernetes cluster components are launched using Docker on a Linux distro. You can use any Linux you want, as long as you can install Docker on it.
-Review the [OS requirements]({{< baseurl >}}/rke/v0.1.x/en/installation/os/) and configure each node appropriately.
+Review the [OS requirements]({{< baseurl >}}/rke/latest/en/installation/os/) and configure each node appropriately.
## Creating the Cluster Configuration File
-RKE uses a cluster configuration file, referred to as `cluster.yml` to determine what nodes will be in the cluster and how to deploy Kubernetes. There are [many configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) that can be set in the `cluster.yml`. In our example, we will be assuming the minimum of one [node]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes) for your Kubernetes cluster.
+RKE uses a cluster configuration file, referred to as `cluster.yml` to determine what nodes will be in the cluster and how to deploy Kubernetes. There are [many configuration options]({{< baseurl >}}/rke/latest/en/config-options/) that can be set in the `cluster.yml`. In our example, we will be assuming the minimum of one [node]({{< baseurl >}}/rke/latest/en/config-options/nodes) for your Kubernetes cluster.
There are two easy ways to create a `cluster.yml`:
-- Using our [minimal `cluster.yml`]({{< baseurl >}}/rke/v0.1.x/en/example-yamls/#minimal-cluster-yml-example) and updating it based on the node that you will be using.
+- Using our [minimal `cluster.yml`]({{< baseurl >}}/rke/latest/en/example-yamls/#minimal-cluster-yml-example) and updating it based on the node that you will be using.
- Using `rke config` to query for all the information needed.
### Using `rke config`
-Run `rke config` to create a new `cluster.yml` in the current directory. This command will prompt you for all the information needed to build a cluster. See [cluster configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) for details on the various options.
+Run `rke config` to create a new `cluster.yml` in the current directory. This command will prompt you for all the information needed to build a cluster. See [cluster configuration options]({{< baseurl >}}/rke/latest/en/config-options/) for details on the various options.
```
rke config --name cluster.yml
@@ -90,6 +114,12 @@ RKE is HA ready, you can specify more than one `controlplane` node in the `clust
To create an HA cluster, specify more than one host with role `controlplane`.
+### Certificates
+
+_Available as of v0.2.0_
+
+By default, Kubernetes clusters require certificates and RKE auto-generates the certificates for all cluster components. You can also use [custom certificates]({{< baseurl >}}/rke/latest/en/installation/certs/). After the Kubernetes cluster is deployed, you can [manage these auto-generated certificates]({{< baseurl >}}/rke/latest/en/cert-mgmt/#certificate-rotation).
+
## Deploying Kubernetes with RKE
After you've created your `cluster.yml`, you can deploy your cluster with a simple command. This command assumes the `cluster.yml` file is in the same directory as where you are running the command.
@@ -109,23 +139,30 @@ The last line should read `Finished building Kubernetes cluster successfully` to
> **Note:** If you have used a different file name from `cluster.yml`, then the kube config file will be named `kube_config_.yml`.
-### Interacting with your Kubernetes cluster
+## Save Your Files
-In order to start interacting with your Kubernetes cluster, you will use a different binary called `kubectl`. You will need to [install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on your local machine. You can connect to the RKE created cluster by using the `kube_config_cluster.yml` that was generated when you deployed Kubernetes.
+> **Important**
+> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
-Confirm that kubectl is working by checking the version of your Kubernetes cluster
+Save a copy of the following files in a secure location:
-```
-kubectl --kubeconfig kube_config_cluster.yml version
+- `cluster.yml`: The RKE cluster configuration file.
+- `kube_config_cluster.yml`: The [Kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
+- `cluster.rkestate`: The [Kubernetes Cluster State file](#kubernetes-cluster-state), this file contains credentials for full access to the cluster.
_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
-Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-27T00:13:02Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"}
-Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.9-rancher1", GitCommit:"68595e18f25e24125244e9966b1e5468a98c1cd4", GitTreeState:"clean", BuildDate:"2018-03-13T04:37:53Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
-```
+### Kubernetes Cluster State
-The client and server version are reported, indicating that you have a local `kubectl` client and are able to request the server version from the newly built cluster. Now, you can issue [any kubectl command](https://kubernetes.io/docs/reference/kubectl/kubectl/) to your cluster, like requesting the nodes that are in the cluster.
+The Kubernetes cluster state, which consists of the cluster configuration file `cluster.yml` and components certificates in Kubernetes cluster, is saved by RKE, but depending on your RKE version, the cluster state is saved differently.
-```
-kubectl --kubeconfig kube_config_cluster.yml get nodes
-NAME STATUS ROLES AGE VERSION
-10.0.0.1 Ready controlplane,etcd,worker 35m v1.10.3-rancher1
-```
+As of v0.2.0, RKE creates a `.rkestate` file in the same directory that has the cluster configuration file `cluster.yml`. The `.rkestate` file contains the current state of the cluster including the RKE configuration and the certificates. It is required to keep this file in order to update the cluster or perform any operation on it through RKE.
+
+Prior to v0.2.0, RKE saved the Kubernetes cluster state as a secret. When updating the state, RKE pulls the secret, updates/changes the state and saves a new secret.
+
+## Interacting with your Kubernetes cluster
+
+After your cluster is up and running, you can start using the [generated kubeconfig file]({{< baseurl >}}/rke/latest/en/kubeconfig) to start interacting with your Kubernetes cluster using `kubectl`.
+
+After installation, there are several maintenance items that might arise:
+
+* [Certificate Management]({{< baseurl >}}/rke/latest/en/cert-mgmt/)
+* [Adding and Removing Nodes in the cluster]({{< baseurl >}}/rke/latest/en/managing-clusters)
diff --git a/content/rke/latest/en/installation/certs/_index.md b/content/rke/latest/en/installation/certs/_index.md
new file mode 100644
index 00000000000..6b702c468d2
--- /dev/null
+++ b/content/rke/latest/en/installation/certs/_index.md
@@ -0,0 +1,91 @@
+---
+title: Custom Certificates
+weight: 150
+---
+
+_Available as of v0.2.0_
+
+By default, Kubernetes clusters require certificates and RKE auto-generates the certificates for all the Kubernetes services. RKE can also use custom certificates for these Kubernetes services.
+
+When [deploying Kubernetes with RKE]({{< baseurl >}}/rke/latest/en/installation/#deploying-kubernetes-with-rke), there are two additional options that can be used with `rke up` so that RKE uses custom certificates.
+
+| Option | Description |
+| --- | --- |
+| `--custom-certs` | Use custom certificates from a cert dir. The default directory is `/cluster_certs`. |
+| `--cert-dir` value | Specify a certificate dir path |
+
+## Using Custom Certificates
+
+```
+# Use certificates located in the default directory `/cluster_certs`
+$ rke up --custom-certs
+
+# Use certificates located in your own directory
+$ rke up --custom-certs --cert-dir ~/my/own/certs
+```
+
+## Certificates
+
+The following certificates must exist in the certificate directory.
+
+| Name | Certificate | Key | Required |
+|---|---|---|---|
+| Master CA | kube-ca.pem | - | * |
+| Kube API | kube-apiserver.pem | kube-apiserver-key.pem | * |
+| Kube Controller Manager | kube-controller-manager.pem | kube-controller-manager-key.pem | * |
+| Kube Scheduler | kube-scheduler.pem | kube-scheduler-key.pem | * |
+| Kube Proxy | kube-proxy.pem | kube-proxy-key.pem | * |
+| Kube Admin | kube-admin.pem | kube-admin-key.pem | * |
+| Apiserver Proxy Client | kube-apiserver-proxy-client.pem | kube-apiserver-proxy-client-key.pem | * |
+| Etcd Nodes | kube-etcd-x-x-x-x.pem | kube-etcd-x-x-x-x-key.pem | * |
+| Kube Api Request Header CA | kube-apiserver-requestheader-ca.pem | kube-apiserver-requestheader-ca-key.pem | |
+| Service Account Token | - | kube-service-account-token-key.pem | |
+
+## Generating Certificate Signing Requests (CSRs) and Keys
+
+If you want to create and sign the certificates by a real Certificate Authority (CA), you can use RKE to generate a set of Certificate Signing Requests (CSRs) and keys. Using the `rke cert generate-csr` command, you can generate the CSRs and keys.
+
+1. Set up your `cluster.yml` with the [node information]({{< baseurl >}}/rke/latest/en/config-options/nodes/).
+
+2. Run `rke cert generate-csr` to generate certificates for the node(s) in the `cluster.yml`. By default, the CSRs and keys will be saved in `./cluster_certs`. To have them saved in a different directory, use `--cert-dir` to define what directory to have them saved in.
+
+ ```
+ $ rke cert generate-csr
+ INFO[0000] Generating Kubernetes cluster CSR certificates
+ INFO[0000] [certificates] Generating Kubernetes API server csr
+ INFO[0000] [certificates] Generating Kube Controller csr
+ INFO[0000] [certificates] Generating Kube Scheduler csr
+ INFO[0000] [certificates] Generating Kube Proxy csr
+ INFO[0001] [certificates] Generating Node csr and key
+ INFO[0001] [certificates] Generating admin csr and kubeconfig
+ INFO[0001] [certificates] Generating Kubernetes API server proxy client csr
+ INFO[0001] [certificates] Generating etcd-x.x.x.x csr and key
+ INFO[0001] Successfully Deployed certificates at [./cluster_certs]
+ ```
+
+**Result:** The CSRs and keys will be deployed in `./cluster_certs` directory, assuming you didn't specify a `--cert-dir`. The CSR files will contain the right Alternative DNS and IP Names for the certificates. You can use them to sign the certificates by a real CA. After the certificates are signed, those certificates can be used by RKE as custom certificates.
+
+```
+$ tree cluster_certs
+
+cluster_certs
+├── kube-admin-csr.pem
+├── kube-admin-key.pem
+├── kube-apiserver-csr.pem
+├── kube-apiserver-key.pem
+├── kube-apiserver-proxy-client-csr.pem
+├── kube-apiserver-proxy-client-key.pem
+├── kube-controller-manager-csr.pem
+├── kube-controller-manager-key.pem
+├── kube-etcd-x-x-x-x-csr.pem
+├── kube-etcd-x-x-x-x-key.pem
+├── kube-node-csr.pem
+├── kube-node-key.pem
+├── kube-proxy-csr.pem
+├── kube-proxy-key.pem
+├── kube-scheduler-csr.pem
+└── kube-scheduler-key.pem
+
+0 directories, 16 files
+
+```
diff --git a/content/rke/latest/en/kubeconfig/_index.md b/content/rke/latest/en/kubeconfig/_index.md
new file mode 100644
index 00000000000..27c596ba377
--- /dev/null
+++ b/content/rke/latest/en/kubeconfig/_index.md
@@ -0,0 +1,35 @@
+---
+title: Kubeconfig File
+weight: 145
+---
+
+In order to start interacting with your Kubernetes cluster, you will use a different binary called `kubectl`. You will need to [install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on your local machine.
+
+A _kubeconfig file_ is a file used to configure access to Kubernetes when used in conjunction with the kubectl commandline tool (or other clients).
+
+For more details on how kubeconfig and kubectl work together, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
+
+When you deployed Kubernetes, a kubeconfig is automatically generated for your RKE cluster. This file is created and saved as `kube_config_cluster.yml`.
+
+>**Note:** By default, kubectl checks `~/.kube/config` for a kubeconfig file, but you can use any directory you want using the `--kubeconfig` flag. For example:
+>
+>```
+kubectl --kubeconfig /custom/path/kube.config get pods
+```
+
+Confirm that kubectl is working by checking the version of your Kubernetes cluster
+
+```
+kubectl --kubeconfig kube_config_cluster.yml version
+
+Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-27T00:13:02Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"}
+Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.9-rancher1", GitCommit:"68595e18f25e24125244e9966b1e5468a98c1cd4", GitTreeState:"clean", BuildDate:"2018-03-13T04:37:53Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
+```
+
+The client and server version are reported, indicating that you have a local `kubectl` client and are able to request the server version from the newly built cluster. Now, you can issue [any kubectl command](https://kubernetes.io/docs/reference/kubectl/kubectl/) to your cluster, like requesting the nodes that are in the cluster.
+
+```
+kubectl --kubeconfig kube_config_cluster.yml get nodes
+NAME STATUS ROLES AGE VERSION
+10.0.0.1 Ready controlplane,etcd,worker 35m v1.10.3-rancher1
+```
diff --git a/content/rke/v0.1.x/en/managing-clusters/_index.md b/content/rke/latest/en/managing-clusters/_index.md
similarity index 89%
rename from content/rke/v0.1.x/en/managing-clusters/_index.md
rename to content/rke/latest/en/managing-clusters/_index.md
index dae9101a846..c43049d0fce 100644
--- a/content/rke/v0.1.x/en/managing-clusters/_index.md
+++ b/content/rke/latest/en/managing-clusters/_index.md
@@ -1,13 +1,13 @@
---
-title: Adding and Removing Nodes in RKE Clusters
+title: Adding and Removing Nodes
weight: 175
aliases:
- - /rke/v0.1.x/en/installation/managing-clusters/
+ - /rke/latest/en/installation/managing-clusters/
---
### Adding/Removing Nodes
-RKE supports adding/removing [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/) for worker and controlplane hosts.
+RKE supports adding/removing [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/) for worker and controlplane hosts.
In order to add additional nodes, you update the original `cluster.yml` file with any additional nodes and specify their role in the Kubernetes cluster.
diff --git a/content/rke/v0.1.x/en/os/_index.md b/content/rke/latest/en/os/_index.md
similarity index 86%
rename from content/rke/v0.1.x/en/os/_index.md
rename to content/rke/latest/en/os/_index.md
index d14ffbd0b25..56df0dea9c6 100644
--- a/content/rke/v0.1.x/en/os/_index.md
+++ b/content/rke/latest/en/os/_index.md
@@ -2,7 +2,7 @@
title: Requirements
weight: 5
aliases:
- - /rke/v0.1.x/en/installation/os
+ - /rke/latest/en/installation/os
---
**In this section:**
@@ -30,7 +30,7 @@ aliases:
RKE runs on almost any Linux OS with Docker installed. Most of the development and testing of RKE occurred on Ubuntu 16.04. However, some OS's have restrictions and specific requirements.
-- [SSH user]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/#ssh-user) - The SSH user used for node access must be a member of the `docker` group on the node:
+- [SSH user]({{< baseurl >}}/rke/latest/en/config-options/nodes/#ssh-user) - The SSH user used for node access must be a member of the `docker` group on the node:
```
usermod -aG docker
@@ -87,7 +87,7 @@ net.bridge.bridge-nf-call-iptables=1
### Red Hat Enterprise Linux (RHEL) / Oracle Enterprise Linux (OEL) / CentOS
-If using Red Hat Enterprise Linux, Oracle Enterprise Linux or CentOS, you cannot use the `root` user as [SSH user]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/#ssh-user) due to [Bugzilla 1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). Please follow the instructions below how to setup Docker correctly, based on the way you installed Docker on the node.
+If using Red Hat Enterprise Linux, Oracle Enterprise Linux or CentOS, you cannot use the `root` user as [SSH user]({{< baseurl >}}/rke/latest/en/config-options/nodes/#ssh-user) due to [Bugzilla 1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). Please follow the instructions below how to setup Docker correctly, based on the way you installed Docker on the node.
#### Using upstream Docker
If you are using upstream Docker, the package name is `docker-ce` or `docker-ee`. You can check the installed package by executing:
@@ -153,40 +153,25 @@ By default, Atomic hosts do not come with a Docker group. You can update the own
- Docker - Each Kubernetes version supports different Docker versions.
-Kubernetes Version | Docker 1.12.6 | Docker 1.13.1 | Docker 17.03.2 |
-----|----|----|----|
-v1.11.x | X | X | X |
-v1.10.x | X | X | X |
-v1.9.x | X | X | X |
+Kubernetes Version | Supported Docker version(s) |
+----|----|
+v1.13.x | RHEL Docker 1.13, 17.03.2, 18.06.2, 18.09.2 |
+v1.12.x | RHEL Docker 1.13, 17.03.2, 18.06.2, 18.09.2 |
+v1.11.x | RHEL Docker 1.13, 17.03.2, 18.06.2, 18.09.2 |
-You can either follow the [Docker installation](https://docs.docker.com/install/) instructions or use one of Rancher's [install scripts](https://github.com/rancher/install-docker) to install Docker.
+You can either follow the [Docker installation](https://docs.docker.com/install/) instructions or use one of Rancher's [install scripts](https://github.com/rancher/install-docker) to install Docker. For RHEL, please see [How to install Docker on Red Hat Enterprise Linux 7](https://access.redhat.com/solutions/3727511).
Docker Version | Install Script |
----------|------------------
-17.03.2 | curl https://releases.rancher.com/install-docker/17.03.sh | sh |
-1.13.1 | curl https://releases.rancher.com/install-docker/1.13.sh | sh |
-1.12.6 | curl https://releases.rancher.com/install-docker/1.12.sh | sh |
+18.09.2 | curl https://releases.rancher.com/install-docker/18.09.2.sh | sh |
+18.06.2 | curl https://releases.rancher.com/install-docker/18.06.2.sh | sh |
+17.03.2 | curl https://releases.rancher.com/install-docker/17.03.2.sh | sh |
-Confirm that a Kubernetes supported version of Docker is installed on your machine, by running `docker version`.
+Confirm that a Kubernetes supported version of Docker is installed on your machine, by running `docker version --format '{{.Server.Version}}'`.
```
-$ docker version
-Client:
- Version: 17.03.2-ce
- API version: 1.27
- Go version: go1.7.5
- Git commit: f5ec1e2
- Built: Tue Jun 27 03:35:14 2017
- OS/Arch: linux/amd64
-
-Server:
- Version: 17.03.2-ce
- API version: 1.27 (minimum version 1.12)
- Go version: go1.7.5
- Git commit: f5ec1e2
- Built: Tue Jun 27 03:35:14 2017
- OS/Arch: linux/amd64
- Experimental: false
+docker version --format '{{.Server.Version}}'
+17.03.2-ce
```
- OpenSSH 7.0+ - In order to SSH into each node, OpenSSH must be installed on each node.
diff --git a/content/rke/v0.1.x/en/troubleshooting/_index.md b/content/rke/latest/en/troubleshooting/_index.md
similarity index 55%
rename from content/rke/v0.1.x/en/troubleshooting/_index.md
rename to content/rke/latest/en/troubleshooting/_index.md
index e47db3d5079..53668e8aff4 100644
--- a/content/rke/v0.1.x/en/troubleshooting/_index.md
+++ b/content/rke/latest/en/troubleshooting/_index.md
@@ -3,4 +3,4 @@ title: Troubleshooting
weight: 400
---
-* [SSH Connectivity Errors]({{< baseurl >}}/rke/v0.1.x/en/troubleshooting/ssh-connectivity-errors/)
+* [SSH Connectivity Errors]({{< baseurl >}}/rke/latest/en/troubleshooting/ssh-connectivity-errors/)
diff --git a/content/rke/v0.1.x/en/troubleshooting/ssh-connectivity-errors/_index.md b/content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md
similarity index 100%
rename from content/rke/v0.1.x/en/troubleshooting/ssh-connectivity-errors/_index.md
rename to content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md
diff --git a/content/rke/v0.1.x/en/upgrades/_index.md b/content/rke/latest/en/upgrades/_index.md
similarity index 83%
rename from content/rke/v0.1.x/en/upgrades/_index.md
rename to content/rke/latest/en/upgrades/_index.md
index 871217a5134..8c5ffc2d0ba 100644
--- a/content/rke/v0.1.x/en/upgrades/_index.md
+++ b/content/rke/latest/en/upgrades/_index.md
@@ -3,11 +3,11 @@ title: Upgrades
weight: 100
---
-After RKE has deployed Kubernetes, you can upgrade the versions of the components in your Kubernetes cluster, [definition of the Kubernetes services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/) or [add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/).
+After RKE has deployed Kubernetes, you can upgrade the versions of the components in your Kubernetes cluster, [definition of the Kubernetes services]({{< baseurl >}}/rke/latest/en/config-options/services/) or [add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/).
## Version Upgrades
-RKE supports version upgrades by changing the image tags of the [system-images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/).
+RKE supports version upgrades by changing the image tags of the [system-images]({{< baseurl >}}/rke/latest/en/config-options/system-images/).
For example, to change the deployed Kubernetes version, you update the `rancher/hyperkube` tag from `v1.9.7` to `v1.10.3` in the `cluster.yml` that was originally used to deploy your Kubernetes cluster.
@@ -37,7 +37,7 @@ First, RKE will use the local `kube_config_cluster.yml` to confirm the versions
## Service Upgrades
-[Services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/) can be upgraded by changing any of the services arguments or `extra_args` and running `rke up` again with the updated configuration file.
+[Services]({{< baseurl >}}/rke/latest/en/config-options/services/) can be upgraded by changing any of the services arguments or `extra_args` and running `rke up` again with the updated configuration file.
> **Note:** The following arguments, `service_cluster_ip_range` or `cluster_cidr`, cannot be changed as any changes to these arguments will result in a broken cluster. Currently, network pods are not automatically upgraded.
@@ -45,4 +45,4 @@ First, RKE will use the local `kube_config_cluster.yml` to confirm the versions
As of v0.1.8, upgrades to add-ons are supported.
-[Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/) can also be upgraded by changing any of the add-ons and running `rke up` again with the updated configuration file.
+[Add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/) can also be upgraded by changing any of the add-ons and running `rke up` again with the updated configuration file.
diff --git a/content/rke/v0.1.x/en/config-options/authentication/_index.md b/content/rke/v0.1.x/en/config-options/authentication/_index.md
deleted file mode 100644
index dd9bedff5ef..00000000000
--- a/content/rke/v0.1.x/en/config-options/authentication/_index.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Authentication
-weight: 235
----
-
-RKE supports x509 authentication strategy. You can additionally define a list of SANs (Subject Alternative Names) to add to the Kubernetes API Server PKI certificates. As an example, this allows you to connect to your Kubernetes cluster API Server through a load balancer instead of a single node.
-
-```yaml
-authentication:
- strategy: x509
- sans:
- - "10.18.160.10"
- - "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
-```
diff --git a/content/rke/v0.1.x/en/config-options/system-images/_index.md b/content/rke/v0.1.x/en/config-options/system-images/_index.md
deleted file mode 100644
index 060a1dd7faa..00000000000
--- a/content/rke/v0.1.x/en/config-options/system-images/_index.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: System Images
-weight: 225
----
-When RKE is deploying Kubernetes, there are several images that are pulled. These images are used as Kubernetes system components as well as helping to deploy these system components.
-
-As of `v0.1.6`, the functionality of a couple of the system images were consolidated into a single `rancher/rke-tools` image to simplify and speed the deployment process.
-
-You can configure the [network plug-ins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/) and [ingress controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/) as well as the options for these add-ons separately.
-
-This is the example of the full list of system images used to deploy Kubernetes through RKE. The image tags are dependent on the [Kubernetes image/version used](https://github.com/rancher/types/blob/master/apis/management.cattle.io/v3/k8s_defaults.go).
-
-> **Note:** As versions of RKE are released, the tags on these images will no longer be up to date. This list is specific for `v1.10.3-rancher2`.
-
-```yaml
-system_images:
- kubernetes: rancher/hyperkube:v1.10.3-rancher2
- etcd: rancher/coreos-etcd:v3.1.12
- alpine: rancher/rke-tools:v0.1.9
- nginx_proxy: rancher/rke-tools:v0.1.9
- cert_downloader: rancher/rke-tools:v0.1.9
- kubernetes_services_sidecar: rancher/rke-tools:v0.1.9
- kubedns: rancher/k8s-dns-kube-dns-amd64:1.14.8
- dnsmasq: rancher/k8s-dns-dnsmasq-nanny-amd64:1.14.8
- kubedns_sidecar: rancher/k8s-dns-sidecar-amd64:1.14.8
- kubedns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
- pod_infra_container: rancher/pause-amd64:3.1
-
- # Flannel Networking Options
- flannel: rancher/coreos-flannel:v0.9.1
- flannel_cni: rancher/coreos-flannel-cni:v0.2.0
-
- # Calico Networking Options
- calico_node: rancher/calico-node:v3.1.1
- calico_cni: rancher/calico-cni:v3.1.1
- calico_ctl: rancher/calico-ctl:v2.0.0
-
- # Canal Networking Options
- canal_node: rancher/calico-node:v3.1.1
- canal_cni: rancher/calico-cni:v3.1.1
- canal_flannel: rancher/coreos-flannel:v0.9.1
-
- # Weave Networking Options
- weave_node: weaveworks/weave-kube:2.1.2
- weave_cni: weaveworks/weave-npc:2.1.2
-
- # Ingress Options
- ingress: rancher/nginx-ingress-controller:0.10.2-rancher3
- ingress_backend: rancher/nginx-ingress-controller-defaultbackend:1.4
-```
-
-Prior to `v0.1.6`, instead of using the `rancher/rke-tools` image, we used the following images:
-
-```yaml
-system_images:
- alpine: alpine:latest
- nginx_proxy: rancher/rke-nginx-proxy:v0.1.1
- cert_downloader: rancher/rke-cert-deployer:v0.1.1
- kubernetes_services_sidecar: rancher/rke-service-sidekick:v0.1.0
-```
-
-### Air-gapped Setups
-
-If you have an air-gapped setup and cannot access `docker.io`, you will need to set up your [private registry]({{< baseurl >}}/rke/v0.1.x/en/config-options/private-registries/) in your cluster configuration file. After you set up private registry, you will need to update these images to pull from your private registry.
diff --git a/content/rke/v0.1.x/en/etcd-snapshots/_index.md b/content/rke/v0.1.x/en/etcd-snapshots/_index.md
deleted file mode 100644
index cea49ba1d39..00000000000
--- a/content/rke/v0.1.x/en/etcd-snapshots/_index.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-title: Backups and Disaster Recovery
-weight: 150
-aliases:
- - /rke/v0.1.x/en/installation/etcd-snapshots/
----
-
-As of v0.1.7, you can configure a RKE cluster to automatically take snapshots of etcd. In a disaster scenario, you can restore these snapshots, which are stored on other nodes in the cluster.
-
-## One-Time Snapshots
-
-RKE can take a one-time snapshot of a running etcd node in a RKE cluster. The snapshot is automatically saved in `/opt/rke/etcd-snapshots`.
-
-```
-$ rke etcd snapshot-save --config cluster.yml
-
-WARN[0000] Name of the snapshot is not specified using [rke_etcd_snapshot_2018-05-17T23:32:08+02:00]
-INFO[0000] Starting saving snapshot on etcd hosts
-INFO[0000] [dialer] Setup tunnel for host [x.x.x.x]
-INFO[0001] [dialer] Setup tunnel for host [y.y.y.y]
-INFO[0002] [dialer] Setup tunnel for host [z.z.z.z]
-INFO[0003] [etcd] Saving snapshot [rke_etcd_snapshot_2018-05-17T23:32:08+02:00] on host [x.x.x.x]
-INFO[0004] [etcd] Successfully started [etcd-snapshot-once] container on host [x.x.x.x]
-INFO[0004] [etcd] Saving snapshot [rke_etcd_snapshot_2018-05-17T23:32:08+02:00] on host [y.y.y.y]
-INFO[0005] [etcd] Successfully started [etcd-snapshot-once] container on host [y.y.y.y]
-INFO[0005] [etcd] Saving snapshot [rke_etcd_snapshot_2018-05-17T23:32:08+02:00] on host [z.z.z.z]
-INFO[0006] [etcd] Successfully started [etcd-snapshot-once] container on host [z.z.z.z]
-INFO[0006] Finished saving snapshot [rke_etcd_snapshot_2018-05-17T23:32:08+02:00] on all etcd hosts
-```
-
-The command will save a snapshot of etcd from each etcd node in the cluster config file and will save it in `/opt/rke/etcd-snapshots`. When running the command, an additional container is created to take the snapshot. When the snapshot is completed, the container is automatically removed.
-
-## Etcd Recurring Snapshots
-
-To schedule a recurring automatic etcd snapshot save, you can enable the `etcd-snapshot` service. `etcd-snapshot` runs in a service container alongside the `etcd` container. `etcd-snapshot` automatically takes a snapshot of etcd and stores them to its local disk in `/opt/rke/etcd-snapshots`.
-
-
-In the `cluster.yml`, you need to turn enable `snapshot` as part of the `etcd service`. Additionally, you want to specify `creation` and `retention` for the snapshot service.
-
-```yaml
-services:
- etcd:
- snapshot: true
- creation: 5m0s
- retention: 24h
-```
-
-
-When a cluster is launched with the etcd snapshot service enabled, you can view the `etcd-rolling-snapshots` logs to confirm backups are being created automatically.
-
-```
-$ docker logs etcd-rolling-snapshots
-
-time="2018-05-04T18:39:16Z" level=info msg="Initializing Rolling Backups" creation=1m0s retention=24h0m0s
-time="2018-05-04T18:40:16Z" level=info msg="Created backup" name="2018-05-04T18:40:16Z_etcd" runtime=108.332814ms
-time="2018-05-04T18:41:16Z" level=info msg="Created backup" name="2018-05-04T18:41:16Z_etcd" runtime=92.880112ms
-time="2018-05-04T18:42:16Z" level=info msg="Created backup" name="2018-05-04T18:42:16Z_etcd" runtime=83.67642ms
-time="2018-05-04T18:43:16Z" level=info msg="Created backup" name="2018-05-04T18:43:16Z_etcd" runtime=86.298499ms
-```
-
-For every node that has the `etcd` role, these `backups` are saved to `/opt/rke/etcd-snapshots/`.
-
-### Snapshot Options
-
-**Snapshot**
-
-By default, the recurring snapshot service is disabled. To enable the service, you need to define it as part of `etcd` and set it to `true`.
-
-**Creation**
-
-By default, the snapshot service will take snapshots every 5 minutes (`5m0s`). You can change the time between snapshots as part of the `creation` directive for the `etcd` service.
-
-**Retention**
-
-By default, all snapshots are saved for 24 hours (`24h`) before being deleted and purged. You can change how long to store a snapshot as part of the `retention` directive for the `etcd` service.
-
-## Etcd Disaster recovery
-
-If there is a disaster with your Kubernetes cluster, you can use `rke etcd snapshot-restore` to recover your etcd. This command will revert to a specific snapshot stored in `/opt/rke/etcd-snapshots` that you explicitly define. During the restore process, RKE also removes the old `etcd` container before creating a new `etcd` cluster using the snapshot that you have chosen.
-
->**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, you should back up any important data in your cluster.
-
-```
-$ rke etcd snapshot-restore --name mysnapshot --config cluster.yml
-INFO[0000] Starting restore on etcd hosts
-INFO[0000] [dialer] Setup tunnel for host [x.x.x.x]
-INFO[0002] [dialer] Setup tunnel for host [y.y.y.y]
-INFO[0005] [dialer] Setup tunnel for host [z.z.z.z]
-INFO[0007] [hosts] Cleaning up host [x.x.x.x]
-INFO[0007] [hosts] Running cleaner container on host [x.x.x.x]
-INFO[0008] [kube-cleaner] Successfully started [kube-cleaner] container on host [x.x.x.x]
-INFO[0008] [hosts] Removing cleaner container on host [x.x.x.x]
-INFO[0008] [hosts] Successfully cleaned up host [x.x.x.x]
-INFO[0009] [hosts] Cleaning up host [y.y.y.y]
-INFO[0009] [hosts] Running cleaner container on host [y.y.y.y]
-INFO[0010] [kube-cleaner] Successfully started [kube-cleaner] container on host [y.y.y.y]
-INFO[0010] [hosts] Removing cleaner container on host [y.y.y.y]
-INFO[0010] [hosts] Successfully cleaned up host [y.y.y.y]
-INFO[0011] [hosts] Cleaning up host [z.z.z.z]
-INFO[0011] [hosts] Running cleaner container on host [z.z.z.z]
-INFO[0012] [kube-cleaner] Successfully started [kube-cleaner] container on host [z.z.z.z]
-INFO[0012] [hosts] Removing cleaner container on host [z.z.z.z]
-INFO[0012] [hosts] Successfully cleaned up host [z.z.z.z]
-INFO[0012] [etcd] Restoring [snapshot] snapshot on etcd host [x.x.x.x]
-INFO[0013] [etcd] Successfully started [etcd-restore] container on host [x.x.x.x]
-INFO[0014] [etcd] Restoring [snapshot] snapshot on etcd host [y.y.y.y]
-INFO[0015] [etcd] Successfully started [etcd-restore] container on host [y.y.y.y]
-INFO[0015] [etcd] Restoring [snapshot] snapshot on etcd host [z.z.z.z]
-INFO[0016] [etcd] Successfully started [etcd-restore] container on host [z.z.z.z]
-INFO[0017] [etcd] Building up etcd plane..
-INFO[0018] [etcd] Successfully started [etcd] container on host [x.x.x.x]
-INFO[0020] [etcd] Successfully started [rke-log-linker] container on host [x.x.x.x]
-INFO[0021] [remove/rke-log-linker] Successfully removed container on host [x.x.x.x]
-INFO[0022] [etcd] Successfully started [etcd] container on host [y.y.y.y]
-INFO[0023] [etcd] Successfully started [rke-log-linker] container on host [y.y.y.y]
-INFO[0025] [remove/rke-log-linker] Successfully removed container on host [y.y.y.y]
-INFO[0025] [etcd] Successfully started [etcd] container on host [z.z.z.z]
-INFO[0027] [etcd] Successfully started [rke-log-linker] container on host [z.z.z.z]
-INFO[0027] [remove/rke-log-linker] Successfully removed container on host [z.z.z.z]
-INFO[0027] [etcd] Successfully started etcd plane..
-INFO[0027] Finished restoring on all etcd hosts
-```
-
-## Example
-
-In this example, the Kubernetes cluster was deployed on two AWS nodes.
-
-| Name | IP | Role |
-|:-----:|:--------:|:----------------------:|
-| node1 | 10.0.0.1 | [controlplane, worker] |
-| node2 | 10.0.0.2 | [etcd] |
-
-### Back up the `etcd` cluster
-
-Take a snapshot of the Kubernetes cluster.
-
-```
-$ rke etcd snapshot-save --name snapshot.db --config cluster.yml
-```
-
-
-
-### Store the snapshot externally
-
-After taking the etcd snapshot on `node2`, we recommend saving this backup in a persistence place. One of the options is to save the backup on a S3 bucket or tape backup.
-
-```
-# If you're using an AWS host and have the ability to connect to S3
-root@node2:~# s3cmd mb s3://rke-etcd-backup
-root@node2:~# s3cmd /opt/rke/etcdbackup/snapshot.db s3://rke-etcd-backup/
-```
-
-### Place the backup on a new node
-
-To simulate the failure, let's power down `node2`.
-
-```
-root@node2:~# poweroff
-```
-
-Before restoring etcd and running `rke up`, we need to retrieve the backup saved on S3 to a new node, e.g. `node3`.
-
-
-| Name | IP | Role |
-|:-----:|:--------:|:----------------------:|
-| node1 | 10.0.0.1 | [controlplane, worker] |
-| ~~node2~~ | ~~10.0.0.2~~ | ~~[etcd]~~ |
-| node3 | 10.0.0.3 | [etcd] |
-| | | |
-
-```
-# Make a Directory
-root@node3:~# mkdir -p /opt/rke/etcdbackup
-$ Get the Backup from S3
-root@node3:~# s3cmd get s3://rke-etcd-backup/snapshot.db /opt/rke/etcdbackup/snapshot.db
-```
-
-### Restore `etcd` on the new node from the backup
-
-Before updating and restoring etcd, you will need to add the new node into the Kubernetes cluster with the `etcd` role. In the `cluster.yml`, comment out the old node and add in the new node. `
-
-```yaml
-nodes:
- - address: 10.0.0.1
- hostname_override: node1
- user: ubuntu
- role:
- - controlplane
- - worker
-# - address: 10.0.0.2
-# hostname_override: node2
-# user: ubuntu
-# role:
-# - etcd
- - address: 10.0.0.3
- hostname_override: node3
- user: ubuntu
- role:
- - etcd
-```
-
-After the new node is added to the `cluster.yml`, run `rke etcd snapshot-restore` to launch `etcd` from the backup. ]
-
-```
-$ rke etcd snapshot-restore --name snapshot.db --config cluster.yml
-```
-
-Finally, we need to restore the operations on the cluster by making the Kubernetes API point to the new `etcd` by running `rke up` again using the new `cluster.yml`.
-
-```
-$ rke up --config cluster.yml
-```
-
-Confirm that your Kubernetes cluster is functional by checking the pods on your cluster.
-
-```
-> kubectl get pods
-NAME READY STATUS RESTARTS AGE
-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.
diff --git a/data/cta/intro-k8s-rancher-online-training.toml b/data/cta/intro-k8s-rancher-online-training.toml
new file mode 100644
index 00000000000..689b834bcf7
--- /dev/null
+++ b/data/cta/intro-k8s-rancher-online-training.toml
@@ -0,0 +1,7 @@
+header = "Get free weekly training on Kubernetes and Rancher"
+copy = ""
+button = "Join here"
+link = "https://info.rancher.com/rancher-kubernetes-online-training"
+
+
+form-id = ""
diff --git a/layouts/_default/list.html b/layouts/_default/list.html
index 7c6adabfd3c..fe85f2c755f 100644
--- a/layouts/_default/list.html
+++ b/layouts/_default/list.html
@@ -21,11 +21,19 @@
{{end}}
+ {{ if .Params.ctaBanner }}
+ {{ with index .Site.Data.cta .Params.ctaBanner }}
+
SAML Protocol does not support search or lookup for users or groups. Therefore, there is no validation on users or groups when adding them to Rancher.
+
When adding users, the exact user IDs (i.e. UID Field) must be entered correctly. As you type the user ID, there will be no search for other user IDs that may match.
+
+
When adding groups, you must select the group from the drop-down that is next to the text box. Rancher assumes that any input from the text box is a user.
+
+
+
The group drop-down shows only the groups that you are a member of. You will not be able to add groups that you are not a member of.
+
+
+
diff --git a/layouts/shortcodes/step_create-cloud-credential.html b/layouts/shortcodes/step_create-cloud-credential.html
new file mode 100644
index 00000000000..1cc2891c0b5
--- /dev/null
+++ b/layouts/shortcodes/step_create-cloud-credential.html
@@ -0,0 +1,6 @@
+
+As of v2.2.0, account access information will be stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets.
+
+Since multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one. To create a new cloud credential, enter Name and Account Access data, then click Create.
+
+
diff --git a/layouts/shortcodes/step_rancher-template.html b/layouts/shortcodes/step_rancher-template.html
index 859cff143f0..0323edb2d58 100644
--- a/layouts/shortcodes/step_rancher-template.html
+++ b/layouts/shortcodes/step_rancher-template.html
@@ -9,11 +9,11 @@
Engine Options customize the configuration of the Docker daemon. Important configuration options might include:
-
Docker Engine Install URL: Determines what Docker version will be installed on the instance.
+
Docker Engine Install URL: Determines what Docker version will be installed on the instance.
When using RancherOS, please check what Docker versions are available using sudo ros engine list on the RancherOS version you want to use, as the default Docker version configured might not be available. If you experience issues installing Docker on other operating systems, please try to install Docker manually using the configured Docker Engine Install URL to troubleshoot.
Registry mirrors: Docker Registry mirror to be used by the Docker daemon