mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-15 21:44:24 +00:00
Merge pull request #4189 from jtravee/refactoring-notes
Refactoring notes
This commit is contained in:
@@ -9,7 +9,11 @@ After installation, the [system administrator]({{<baseurl>}}/rancher/v2.6/en/adm
|
||||
|
||||
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.
|
||||
:::danger
|
||||
|
||||
After you set the Rancher Server URL, we do not support updating it. Set the URL with extreme care.
|
||||
|
||||
:::
|
||||
|
||||
## Authentication
|
||||
|
||||
|
||||
@@ -7,9 +7,11 @@ If your organization uses Microsoft Active Directory as central user repository,
|
||||
|
||||
Rancher uses LDAP to communicate with the Active Directory server. The authentication flow for Active Directory is therefore the same as for the [OpenLDAP authentication]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/openldap) integration.
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> Before you start, please familiarise yourself with the concepts of [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
|
||||
:::note
|
||||
|
||||
Before you start, please familiarise yourself with the concepts of [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
|
||||
|
||||
:::
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -19,15 +21,17 @@ Usually a (non-admin) **Domain User** account should be used for this purpose, a
|
||||
|
||||
Note however, that in some locked-down Active Directory configurations this default behaviour may not apply. In such case you will need to ensure that the service account user has at least **Read** and **List Content** permissions granted either on the Base OU (enclosing users and groups) or globally for the domain.
|
||||
|
||||
> **Using TLS?**
|
||||
>
|
||||
> - If the certificate used by the AD server is self-signed or not from a recognized certificate authority, make sure have at hand the CA certificate (concatenated with any intermediate certificates) in PEM format. You will have to paste in this certificate during the configuration so that Rancher is able to validate the certificate chain.
|
||||
>
|
||||
> - Upon an upgrade to v2.6.0, authenticating via Rancher against an active directory using TLS can fail if the certificates on the AD server do not support SAN attributes. This is a check enabled by default in Go v1.15.
|
||||
>
|
||||
> - The error received is "Error creating SSL connection: LDAP Result Code 200 "Network Error": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0".
|
||||
>
|
||||
> - To resolve the error, update or replace the certificates on the AD server with new ones that support the SAN attribute. Alternatively, this error can be ignored by setting `GODEBUG=x509ignoreCN=0` as an environment variable to Rancher server container.
|
||||
:::note Using TLS?
|
||||
|
||||
- If the certificate used by the AD server is self-signed or not from a recognized certificate authority, make sure have at hand the CA certificate (concatenated with any intermediate certificates) in PEM format. You will have to paste in this certificate during the configuration so that Rancher is able to validate the certificate chain.
|
||||
|
||||
- Upon an upgrade to v2.6.0, authenticating via Rancher against an active directory using TLS can fail if the certificates on the AD server do not support SAN attributes. This is a check enabled by default in Go v1.15.
|
||||
|
||||
- The error received is "Error creating SSL connection: LDAP Result Code 200 "Network Error": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0".
|
||||
|
||||
- To resolve the error, update or replace the certificates on the AD server with new ones that support the SAN attribute. Alternatively, this error can be ignored by setting `GODEBUG=x509ignoreCN=0` as an environment variable to Rancher server container.
|
||||
|
||||
:::
|
||||
|
||||
## Configuration Steps
|
||||
### Open Active Directory Configuration
|
||||
@@ -43,9 +47,11 @@ Note however, that in some locked-down Active Directory configurations this defa
|
||||
|
||||
In the section titled `1. Configure an Active Directory server`, complete the fields with the information specific to your Active Directory server. Please refer to the following table for detailed information on the required values for each parameter.
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> If you are unsure about the correct values to enter in the user/group Search Base field, please refer to [Identify Search Base and Schema using ldapsearch](#annex-identify-search-base-and-schema-using-ldapsearch).
|
||||
:::note
|
||||
|
||||
If you are unsure about the correct values to enter in the user/group Search Base field, please refer to [Identify Search Base and Schema using ldapsearch](#annex-identify-search-base-and-schema-using-ldapsearch).
|
||||
|
||||
:::
|
||||
|
||||
**Table 1: AD Server parameters**
|
||||
|
||||
@@ -69,9 +75,11 @@ In the section titled `2. Customize Schema` you must provide Rancher with a corr
|
||||
|
||||
Rancher uses LDAP queries to search for and retrieve information about users and groups within the Active Directory. The attribute mappings configured in this section are used to construct search filters and resolve group membership. It is therefore paramount that the provided settings reflect the reality of your AD domain.
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> If you are unfamiliar with the schema used in your Active Directory domain, please refer to [Identify Search Base and Schema using ldapsearch](#annex-identify-search-base-and-schema-using-ldapsearch) to determine the correct configuration values.
|
||||
:::note
|
||||
|
||||
If you are unfamiliar with the schema used in your Active Directory domain, please refer to [Identify Search Base and Schema using ldapsearch](#annex-identify-search-base-and-schema-using-ldapsearch) to determine the correct configuration values.
|
||||
|
||||
:::
|
||||
|
||||
#### User Schema
|
||||
|
||||
@@ -115,9 +123,11 @@ The table below details the parameters for the group schema configuration.
|
||||
|
||||
Once you have completed the configuration, proceed by testing the connection to the AD server **using your AD admin account**. If the test is successful, authentication with the configured Active Directory will be enabled implicitly with the account you test with set as admin.
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> The AD user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned administrator privileges in Rancher. You should therefore make a conscious decision on which AD account you use to perform this step.
|
||||
:::note
|
||||
|
||||
The AD user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned administrator privileges in Rancher. You should therefore make a conscious decision on which AD account you use to perform this step.
|
||||
|
||||
:::
|
||||
|
||||
1. Enter the **username** and **password** for the AD account that should be mapped to the local principal account.
|
||||
2. Click **Authenticate with Active Directory** to finalise the setup.
|
||||
@@ -127,9 +137,11 @@ Once you have completed the configuration, proceed by testing the connection to
|
||||
- Active Directory authentication has been enabled.
|
||||
- You have been signed into Rancher as administrator using the provided AD credentials.
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> You will still be able to login using the locally configured `admin` account and password in case of a disruption of LDAP services.
|
||||
:::note
|
||||
|
||||
You will still be able to login using the locally configured `admin` account and password in case of a disruption of LDAP services.
|
||||
|
||||
:::
|
||||
|
||||
## Annex: Identify Search Base and Schema using ldapsearch
|
||||
|
||||
@@ -170,9 +182,11 @@ The output of the above `ldapsearch` query also allows to determine the correct
|
||||
- `Login Attribute`: **sAMAccountName** [3]
|
||||
- `User Member Attribute`: **memberOf** [4]
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> If the AD users in our organization were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead.
|
||||
:::note
|
||||
|
||||
If the AD users in our organization were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead.
|
||||
|
||||
:::
|
||||
|
||||
We'll also set the `Search Attribute` parameter to **sAMAccountName|name**. That way users can be added to clusters/projects in the Rancher UI either by entering their username or full name.
|
||||
|
||||
|
||||
@@ -35,7 +35,11 @@ In most cases, you should use an external authentication service over local auth
|
||||
|
||||
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.6/en/admin-settings/rbac/).
|
||||
|
||||
> **Note:** Local authentication does not support creating or managing groups.
|
||||
:::note
|
||||
|
||||
Local authentication does not support creating or managing groups.
|
||||
|
||||
:::
|
||||
|
||||
For more information, see [Users and Groups]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/user-groups/)
|
||||
|
||||
|
||||
@@ -5,19 +5,29 @@ weight: 1115
|
||||
|
||||
If you have an instance of Active Directory (AD) hosted in Azure, you can configure Rancher to allow your users to log in using their AD accounts. Configuration of Azure AD external authentication requires you to make configurations in both Azure and Rancher.
|
||||
|
||||
>**Note:** Azure AD integration only supports Service Provider initiated logins.
|
||||
:::note Prerequisite:
|
||||
|
||||
>**Prerequisite:** Have an instance of Azure AD configured.
|
||||
Have an instance of Azure AD configured.
|
||||
|
||||
>**Note:** Most of this procedure takes place from the [Microsoft Azure Portal](https://portal.azure.com/).
|
||||
:::
|
||||
|
||||
:::note Notes
|
||||
|
||||
- Azure AD integration only supports Service Provider initiated logins.
|
||||
|
||||
- Most of this procedure takes place from the [Microsoft Azure Portal](https://portal.azure.com/).
|
||||
|
||||
:::
|
||||
|
||||
## Azure Active Directory Configuration Outline
|
||||
|
||||
Configuring Rancher to allow your users to authenticate with their Azure AD accounts involves multiple procedures. Review the outline below before getting started.
|
||||
|
||||
<a id="tip"></a>
|
||||
:::tip
|
||||
|
||||
>**Tip:** Before you start, we recommend creating an empty text file. You can use this file to copy values from Azure that you'll paste into Rancher later.
|
||||
Before you start, we recommend creating an empty text file. You can use this file to copy values from Azure that you'll paste into Rancher later.
|
||||
|
||||
:::
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
@@ -50,11 +60,19 @@ Before enabling Azure AD within Rancher, you must register Rancher with Azure.
|
||||
|
||||
1. In the **Redirect URI** section, make sure **Web** is selected from the dropdown and enter the URL of your Rancher Server in the text box next to the dropdown. This Rancher server URL should be appended with the verification path: `<MY_RANCHER_URL>/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).
|
||||
:::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 **Register**.
|
||||
|
||||
>**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.
|
||||
:::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.
|
||||
|
||||
:::
|
||||
|
||||
### 2. Create a new client secret
|
||||
|
||||
@@ -110,7 +128,11 @@ Next, set API permissions for Rancher within Azure.
|
||||
|
||||
1. From **API permissions**, click **Grant admin consent**. Then click **Yes**.
|
||||
|
||||
>**Note:** You must be signed in as an Azure administrator to successfully save your permission settings.
|
||||
:::note
|
||||
|
||||
You must be signed in as an Azure administrator to successfully save your permission settings.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
### 4. Add a Reply URL
|
||||
@@ -124,13 +146,21 @@ 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: `<MY_RANCHER_URL>/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).
|
||||
:::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.
|
||||
|
||||
>**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.
|
||||
:::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.
|
||||
|
||||
:::
|
||||
|
||||
### 5. Copy Azure Application Data
|
||||
|
||||
@@ -170,7 +200,11 @@ As your final step in Azure, copy the data that you'll use to configure Rancher
|
||||
- **OAuth 2.0 token endpoint (v1)** (Token Endpoint)
|
||||
- **OAuth 2.0 authorization endpoint (v1)** (Auth Endpoint)
|
||||
|
||||
>**Note:** Copy the v1 version of the endpoints
|
||||
:::note
|
||||
|
||||
Copy the v1 version of the endpoints
|
||||
|
||||
:::
|
||||
|
||||
### 6. Configure Azure AD in Rancher
|
||||
|
||||
@@ -184,9 +218,13 @@ Enter the values that you copied to your [text file](#tip).
|
||||
1. Click **AzureAD**.
|
||||
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.
|
||||
>
|
||||
><code>http<span>s://g</span>raph.windows.net/<del>abb5adde-bee8-4821-8b03-e63efdc7701c</del></code>
|
||||
:::note Important
|
||||
|
||||
When entering your Graph Endpoint, remove the tenant ID from the URL, like below.
|
||||
|
||||
<code>http<span>s://g</span>raph.windows.net/<del>abb5adde-bee8-4821-8b03-e63efdc7701c</del></code>
|
||||
|
||||
:::
|
||||
|
||||
The following table maps the values you copied in the Azure portal to the fields in Rancher.
|
||||
|
||||
|
||||
@@ -5,11 +5,13 @@ weight: 1114
|
||||
|
||||
If your organization uses FreeIPA for user authentication, you can configure Rancher to allow your users to login using their FreeIPA credentials.
|
||||
|
||||
>**Prerequisites:**
|
||||
>
|
||||
>- You must have a [FreeIPA Server](https://www.freeipa.org/) configured.
|
||||
>- Create a service account in FreeIPA with `read-only` access. Rancher uses this account to verify group membership when a user makes a request using an API key.
|
||||
>- Read [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
|
||||
:::note Prerequisites:
|
||||
|
||||
- You must have a [FreeIPA Server](https://www.freeipa.org/) configured.
|
||||
- Create a service account in FreeIPA with `read-only` access. Rancher uses this account to verify group membership when a user makes a request using an API key.
|
||||
- Read [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
|
||||
|
||||
:::
|
||||
|
||||
1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_).
|
||||
1. In the top left corner, click **☰ > Users & Authentication**.
|
||||
@@ -19,28 +21,36 @@ If your organization uses FreeIPA for user authentication, you can configure Ran
|
||||
|
||||
You may need to log in to your domain controller to find the information requested in the form.
|
||||
|
||||
>**Using TLS?**
|
||||
>If the certificate is self-signed or not from a recognized certificate authority, make sure you provide the complete chain. That chain is needed to verify the server's certificate.
|
||||
<br/>
|
||||
<br/>
|
||||
>**User Search Base vs. Group Search Base**
|
||||
>
|
||||
>Search base allows Rancher to search for users and groups that are in your FreeIPA. These fields are only for search bases and not for search filters.
|
||||
>
|
||||
>* If your users and groups are in the same search base, complete only the User Search Base.
|
||||
>* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required.
|
||||
:::note Using TLS?
|
||||
|
||||
If the certificate is self-signed or not from a recognized certificate authority, make sure you provide the complete chain. That chain is needed to verify the server's certificate.
|
||||
|
||||
:::
|
||||
|
||||
:::note User Search Base vs. Group Search Base
|
||||
|
||||
Search base allows Rancher to search for users and groups that are in your FreeIPA. These fields are only for search bases and not for search filters.
|
||||
|
||||
* If your users and groups are in the same search base, complete only the User Search Base.
|
||||
* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required.
|
||||
|
||||
:::
|
||||
|
||||
1. If your FreeIPA deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step.
|
||||
|
||||
>**Search Attribute** The Search Attribute field defaults with three specific values: `uid|sn|givenName`. After FreeIPA is configured, when a user enters text to add users or groups, Rancher automatically queries the FreeIPA server and attempts to match fields by user id, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field.
|
||||
>
|
||||
>The default field value `uid|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields.
|
||||
>
|
||||
> * `uid`: User ID
|
||||
> * `sn`: Last Name
|
||||
> * `givenName`: First Name
|
||||
>
|
||||
> With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field.
|
||||
:::note Search Attribute
|
||||
|
||||
The Search Attribute field defaults with three specific values: `uid|sn|givenName`. After FreeIPA is configured, when a user enters text to add users or groups, Rancher automatically queries the FreeIPA server and attempts to match fields by user id, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field.
|
||||
|
||||
The default field value `uid|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields.
|
||||
|
||||
* `uid`: User ID
|
||||
* `sn`: Last Name
|
||||
* `givenName`: First Name
|
||||
|
||||
With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field.
|
||||
|
||||
:::
|
||||
|
||||
1. Enter your FreeIPA username and password in **Authenticate with FreeIPA** to confirm that Rancher is configured to use FreeIPA authentication.
|
||||
1. Click **Enable**.
|
||||
|
||||
@@ -5,7 +5,11 @@ weight: 1116
|
||||
|
||||
In environments using GitHub, you can configure Rancher to allow sign on using GitHub credentials.
|
||||
|
||||
>**Prerequisites:** Read [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
|
||||
:::note Prerequisites:
|
||||
|
||||
Read [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
|
||||
|
||||
:::
|
||||
|
||||
1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_).
|
||||
1. In the top left corner, click **☰ > Users & Authentication**.
|
||||
@@ -13,17 +17,21 @@ In environments using GitHub, you can configure Rancher to allow sign on using G
|
||||
1. Click **GitHub**.
|
||||
1. Follow the directions displayed to set up a GitHub Application. Rancher redirects you to GitHub to complete registration.
|
||||
|
||||
>**What's an Authorization Callback URL?**
|
||||
>
|
||||
>The Authorization Callback URL is the URL where users go to begin using your application (i.e. the splash screen).
|
||||
:::note What's an Authorization Callback URL?
|
||||
|
||||
The Authorization Callback URL is the URL where users go to begin using your application (i.e. the splash screen).
|
||||
|
||||
>When you use external authentication, authentication does not actually take place in your application. Instead, authentication takes place externally (in this case, GitHub). After this external authentication completes successfully, the Authorization Callback URL is the location where the user re-enters your application.
|
||||
When you use external authentication, authentication does not actually take place in your application. Instead, authentication takes place externally (in this case, GitHub). After this external authentication completes successfully, the Authorization Callback URL is the location where the user re-enters your application.
|
||||
|
||||
:::
|
||||
|
||||
1. From GitHub, copy the **Client ID** and **Client Secret**. Paste them into Rancher.
|
||||
|
||||
>**Where do I find the Client ID and Client Secret?**
|
||||
>
|
||||
>From GitHub, select Settings > Developer Settings > OAuth Apps. The Client ID and Client Secret are displayed prominently.
|
||||
:::note Where do I find the Client ID and Client Secret?
|
||||
|
||||
From GitHub, select Settings > Developer Settings > OAuth Apps. The Client ID and Client Secret are displayed prominently.
|
||||
|
||||
:::
|
||||
|
||||
1. Click **Authenticate with GitHub**.
|
||||
|
||||
|
||||
@@ -64,7 +64,11 @@ If you have an existing configuration using the SAML protocol and want to switch
|
||||
|
||||
Rancher redirects you to the IdP login page. Enter credentials that authenticate with Keycloak IdP to validate your Rancher Keycloak configuration.
|
||||
|
||||
>**Note:** You may need to disable your popup blocker to see the IdP login page.
|
||||
:::note
|
||||
|
||||
You may need to disable your popup blocker to see the IdP login page.
|
||||
|
||||
:::
|
||||
|
||||
**Result:** Rancher is configured to work with Keycloak using the OIDC protocol. Your users can now sign into Rancher using their Keycloak logins.
|
||||
|
||||
@@ -114,7 +118,11 @@ Before configuring Rancher to use Keycloak (OIDC), Keycloak (SAML) must be first
|
||||
|
||||
Configure Rancher to use Keycloak (OIDC) by following the steps in [this section](#configuring-keycloak-in-rancher).
|
||||
|
||||
> **Note:** After configuration is completed, Rancher user permissions will need to be reapplied as they are not automatically migrated.
|
||||
:::note
|
||||
|
||||
After configuration is completed, Rancher user permissions will need to be reapplied as they are not automatically migrated.
|
||||
|
||||
:::
|
||||
|
||||
## Annex: Troubleshooting
|
||||
|
||||
|
||||
@@ -116,7 +116,11 @@ The following is an example process for Firefox, but will vary slightly for othe
|
||||
|
||||
Rancher redirects you to the IdP login page. Enter credentials that authenticate with Keycloak IdP to validate your Rancher Keycloak configuration.
|
||||
|
||||
>**Note:** You may have to disable your popup blocker to see the IdP login page.
|
||||
:::note
|
||||
|
||||
You may have to disable your popup blocker to see the IdP login page.
|
||||
|
||||
:::
|
||||
|
||||
**Result:** Rancher is configured to work with Keycloak. Your users can now sign into Rancher using their Keycloak logins.
|
||||
|
||||
@@ -135,9 +139,13 @@ The following is an example process for Firefox, but will vary slightly for othe
|
||||
| Private Key / Certificate | A key/certificate pair to create a secure shell between Rancher and your IdP. |
|
||||
| IDP-metadata | The `metadata.xml` file that you exported from your IdP server. |
|
||||
|
||||
>**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.cert
|
||||
:::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.cert
|
||||
|
||||
:::
|
||||
|
||||
## Annex: Troubleshooting
|
||||
|
||||
|
||||
+17
-7
@@ -5,11 +5,13 @@ weight: 1205
|
||||
|
||||
After you complete [Configuring Microsoft AD FS for Rancher]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/microsoft-adfs/microsoft-adfs-setup/), enter your AD FS information into Rancher to allow AD FS users to authenticate with Rancher.
|
||||
|
||||
>**Important Notes For Configuring Your ADFS Server:**
|
||||
>
|
||||
>- The SAML 2.0 WebSSO Protocol Service URL is: `https://<RANCHER_SERVER>/v1-saml/adfs/saml/acs`
|
||||
>- The Relying Party Trust identifier URL is: `https://<RANCHER_SERVER>/v1-saml/adfs/saml/metadata`
|
||||
>- You must export the `federationmetadata.xml` file from your AD FS server. This can be found at: `https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml`
|
||||
:::note Important Notes For Configuring Your ADFS Server:
|
||||
|
||||
- The SAML 2.0 WebSSO Protocol Service URL is: `https://<RANCHER_SERVER>/v1-saml/adfs/saml/acs`
|
||||
- The Relying Party Trust identifier URL is: `https://<RANCHER_SERVER>/v1-saml/adfs/saml/metadata`
|
||||
- You must export the `federationmetadata.xml` file from your AD FS server. This can be found at: `https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml`
|
||||
|
||||
:::
|
||||
|
||||
1. In the top left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation menu, click **Auth Provider**.
|
||||
@@ -19,8 +21,12 @@ After you complete [Configuring Microsoft AD FS for Rancher]({{<baseurl>}}/ranch
|
||||
|
||||
Rancher redirects you to the AD FS login page. Enter credentials that authenticate with Microsoft AD FS to validate your Rancher AD FS configuration.
|
||||
|
||||
>**Note:** You may have to disable your popup blocker to see the AD FS login page.
|
||||
:::note
|
||||
|
||||
You may have to disable your popup blocker to see the AD FS login page.
|
||||
|
||||
:::
|
||||
|
||||
**Result:** Rancher is configured to work with MS FS. Your users can now sign into Rancher using their MS FS logins.
|
||||
|
||||
# Configuration
|
||||
@@ -38,8 +44,12 @@ After you complete [Configuring Microsoft AD FS for Rancher]({{<baseurl>}}/ranch
|
||||
|
||||
<a id="cert-command"></a>
|
||||
|
||||
**Tip:** You can generate a certificate using an openssl command. For example:
|
||||
:::tip
|
||||
|
||||
You can generate a 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"
|
||||
```
|
||||
|
||||
:::
|
||||
@@ -5,8 +5,11 @@ weight: 1210
|
||||
|
||||
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.
|
||||
|
||||
>**Note:** Okta integration only supports Service Provider initiated logins.
|
||||
:::note
|
||||
|
||||
Okta integration only supports Service Provider initiated logins.
|
||||
|
||||
:::
|
||||
## 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.
|
||||
@@ -33,18 +36,27 @@ Setting | Value
|
||||
| Private Key / Certificate | A key/certificate pair used for Assertion Encryption. |
|
||||
| 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
|
||||
:::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 **Enable**.
|
||||
|
||||
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.
|
||||
:::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 >}}
|
||||
|
||||
@@ -28,9 +28,11 @@ Configure the settings for the OpenLDAP server, groups and users. For help filli
|
||||
|
||||
Once you have completed the configuration, proceed by testing the connection to the OpenLDAP server. Authentication with OpenLDAP will be enabled implicitly if the test is successful.
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> The OpenLDAP user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned administrator privileges in Rancher. You should therefore make a conscious decision on which LDAP account you use to perform this step.
|
||||
:::note
|
||||
|
||||
The OpenLDAP user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned administrator privileges in Rancher. You should therefore make a conscious decision on which LDAP account you use to perform this step.
|
||||
|
||||
:::
|
||||
|
||||
1. Enter the **username** and **password** for the OpenLDAP account that should be mapped to the local principal account.
|
||||
2. Click **Authenticate With OpenLDAP** to test the OpenLDAP connection and finalise the setup.
|
||||
@@ -40,9 +42,11 @@ Once you have completed the configuration, proceed by testing the connection to
|
||||
- OpenLDAP authentication is configured.
|
||||
- The LDAP user pertaining to the entered credentials is mapped to the local principal (administrative) account.
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> You will still be able to login using the locally configured `admin` account and password in case of a disruption of LDAP services.
|
||||
:::note
|
||||
|
||||
You will still be able to login using the locally configured `admin` account and password in case of a disruption of LDAP services.
|
||||
|
||||
:::
|
||||
|
||||
## Annex: Troubleshooting
|
||||
|
||||
|
||||
@@ -45,8 +45,12 @@ Note that these URLs will not return valid data until the authentication configu
|
||||
|
||||
Rancher redirects you to the IdP login page. Enter credentials that authenticate with Ping IdP to validate your Rancher PingIdentity configuration.
|
||||
|
||||
>**Note:** You may have to disable your popup blocker to see the IdP login page.
|
||||
:::note
|
||||
|
||||
You may have to disable your popup blocker to see the IdP login page.
|
||||
|
||||
:::
|
||||
|
||||
**Result:** Rancher is configured to work with PingIdentity. Your users can now sign into Rancher using their PingIdentity logins.
|
||||
|
||||
{{< saml_caveats >}}
|
||||
|
||||
@@ -65,8 +65,12 @@ If your organization uses Shibboleth for user authentication, you can configure
|
||||
|
||||
Rancher redirects you to the IdP login page. Enter credentials that authenticate with Shibboleth IdP to validate your Rancher Shibboleth configuration.
|
||||
|
||||
>**Note:** You may have to disable your popup blocker to see the IdP login page.
|
||||
:::note
|
||||
|
||||
You may have to disable your popup blocker to see the IdP login page.
|
||||
|
||||
:::
|
||||
|
||||
**Result:** Rancher is configured to work with Shibboleth. Your users can now sign into Rancher using their Shibboleth logins.
|
||||
|
||||
### SAML Provider Caveats
|
||||
|
||||
@@ -40,8 +40,11 @@ To change these settings,
|
||||
1. In the upper left corner, click **☰ > Global Settings**.
|
||||
1. Go to the setting you want to configure and click **⋮ > Edit 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.
|
||||
:::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.
|
||||
@@ -51,8 +54,11 @@ If you are not sure the last time Rancher performed an automatic refresh of user
|
||||
|
||||
**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.
|
||||
:::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.
|
||||
|
||||
:::
|
||||
|
||||
## Session Length
|
||||
|
||||
|
||||
@@ -13,7 +13,11 @@ Rancher v2.6 introduced the ability to customize Rancher’s branding and naviga
|
||||
|
||||
# Changing Brand Settings
|
||||
|
||||
> **Prerequisite:** You will need to have at least cluster member permissions.
|
||||
:::note Prerequisite:
|
||||
|
||||
You will need to have at least cluster member permissions.
|
||||
|
||||
:::
|
||||
|
||||
To configure the brand settings,
|
||||
|
||||
@@ -71,7 +75,11 @@ Links can be created at the top level and multiple links can be grouped together
|
||||
|
||||
### Adding a Custom Navigation Link
|
||||
|
||||
> **Prerequisite:** You will need to have at least cluster member or project member permissions.
|
||||
:::note Prerequisite:
|
||||
|
||||
You will need to have at least cluster member or project member permissions.
|
||||
|
||||
:::
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you would like to add custom navigation links and click **Explore**.
|
||||
|
||||
@@ -36,10 +36,12 @@ The example repository for an RKE2 cluster template is [here](https://github.com
|
||||
|
||||
In this section, you'll learn how to add the cluster template to the `local` cluster's chart repo list. The result is that Rancher will include the cluster template as an option when users install new Kubernetes clusters.
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - You will need permission to install Helm charts on the `local` Kubernetes cluster that Rancher is installed on.
|
||||
> - In order for the chart to appear in the form for creating new clusters, the chart must have the annotation `catalog.cattle.io/type: cluster-template`.
|
||||
:::note Prerequisites:
|
||||
|
||||
- You will need permission to install Helm charts on the `local` Kubernetes cluster that Rancher is installed on.
|
||||
- In order for the chart to appear in the form for creating new clusters, the chart must have the annotation `catalog.cattle.io/type: cluster-template`.
|
||||
|
||||
:::
|
||||
|
||||
1. Go to a cluster template example repository. Rancher's examples are in [this GitHub repository.](https://github.com/rancher/cluster-template-examples) As of Rancher v2.6.0, we provide an RKE2 cluster template and add to more in the future.
|
||||
1. Fork the repository.
|
||||
@@ -56,15 +58,21 @@ In this section, you'll learn how to add the cluster template to the `local` clu
|
||||
|
||||
**Result:** The cluster template available from the **Apps & Marketplace** in Rancher's `local` cluster. It can now be used to deploy clusters.
|
||||
|
||||
> * **Restricted Admin access:** If you are a restricted admin and don’t have access to the `local` cluster, you may still add new RKE2 templates and manage cluster repositories. To navigate to the chart repository, go to the left navigation bar and click **☰ > Cluster Management > Advanced > Repositories**. You will bypass steps 1 - 6 above, then proceed to follow steps 7 - 12 to create the cluster template.
|
||||
:::note Restricted Admin access:
|
||||
|
||||
If you are a restricted admin and don’t have access to the `local` cluster, you may still add new RKE2 templates and manage cluster repositories. To navigate to the chart repository, go to the left navigation bar and click **☰ > Cluster Management > Advanced > Repositories**. You will bypass steps 1 - 6 above, then proceed to follow steps 7 - 12 to create the cluster template.
|
||||
|
||||
:::
|
||||
|
||||
# Creating a Cluster from a Cluster Template
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - You will need permission to provision new Kubernetes clusters.
|
||||
> - You will need cloud credentials for provisioning infrastructure using the template.
|
||||
> - In order to show in the form for creating new clusters, the cluster template's Helm chart must have the `catalog.cattle.io/type: cluster-template` annotation.
|
||||
:::note Prerequisites:
|
||||
|
||||
- You will need permission to provision new Kubernetes clusters.
|
||||
- You will need cloud credentials for provisioning infrastructure using the template.
|
||||
- In order to show in the form for creating new clusters, the cluster template's Helm chart must have the `catalog.cattle.io/type: cluster-template` annotation.
|
||||
|
||||
:::
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create.**
|
||||
@@ -79,14 +87,16 @@ You can update any clusters using a template from the **Apps & Marketplace > Ins
|
||||
|
||||
# Deploying Clusters from a Template with Fleet
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - You will need permission to provision new Kubernetes clusters.
|
||||
> - You will need cloud credentials for provisioning infrastructure using the template.
|
||||
> - In order to show in the form for creating new clusters, the cluster template's Helm chart must have the `catalog.cattle.io/type:cluster-template` annotation.
|
||||
> - In order to use a template as part of continuous delivery/GitOps, the cluster template needs to be deployed in the `fleet-local` namespace of the `local` cluster.
|
||||
> - All values must be set in the `values.yaml` of the template.
|
||||
> - Fleet repositories must follow the guidelines on [this page.](http://fleet.rancher.io/gitrepo-structure/) For RKE2 cluster templates, that means a `fleet.yaml` file must be added to the repository.
|
||||
:::note Prerequisites:
|
||||
|
||||
- You will need permission to provision new Kubernetes clusters.
|
||||
- You will need cloud credentials for provisioning infrastructure using the template.
|
||||
- In order to show in the form for creating new clusters, the cluster template's Helm chart must have the `catalog.cattle.io/type:cluster-template` annotation.
|
||||
- In order to use a template as part of continuous delivery/GitOps, the cluster template needs to be deployed in the `fleet-local` namespace of the `local` cluster.
|
||||
- All values must be set in the `values.yaml` of the template.
|
||||
- Fleet repositories must follow the guidelines on [this page.](http://fleet.rancher.io/gitrepo-structure/) For RKE2 cluster templates, that means a `fleet.yaml` file must be added to the repository.
|
||||
|
||||
:::
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create.**
|
||||
|
||||
@@ -9,7 +9,7 @@ There are two main ways to set up private registries in Rancher: by setting up t
|
||||
|
||||
This section is about configuring the global default private registry, and focuses on how to configure the registry from the Rancher UI after Rancher is installed.
|
||||
|
||||
For instructions on setting up a private registry with command line options during the installation of Rancher, refer to the [air gapped installation guide]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/air-gap).
|
||||
For instructions on setting up a private registry with command line options during the installation of Rancher, refer to the [air-gapped installation guide]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/air-gap).
|
||||
|
||||
If your private registry requires credentials, it cannot be used as the default registry. There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry with credentials, you will have to [pass in the registry credentials through the advanced cluster options](#setting-a-private-registry-with-credentials-when-deploying-a-cluster) every time you create a new cluster.
|
||||
|
||||
|
||||
@@ -9,10 +9,14 @@ If there are specific cluster drivers that you do not want to show your users, y
|
||||
|
||||
### Managing Cluster Drivers
|
||||
|
||||
>**Prerequisites:** To create, edit, or delete cluster drivers, you need _one_ of the following permissions:
|
||||
>
|
||||
>- [Administrator Global Permissions]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/)
|
||||
>- [Custom Global Permissions]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Cluster Drivers]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/) role assigned.
|
||||
:::note Prerequisites:
|
||||
|
||||
To create, edit, or delete cluster drivers, you need _one_ of the following permissions:
|
||||
|
||||
- [Administrator Global Permissions]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/)
|
||||
- [Custom Global Permissions]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Cluster Drivers]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/) role assigned.
|
||||
|
||||
:::
|
||||
|
||||
## Activating/Deactivating Cluster Drivers
|
||||
|
||||
|
||||
@@ -9,10 +9,14 @@ If there are specific node drivers that you don't want to show to your users, yo
|
||||
|
||||
#### Managing Node Drivers
|
||||
|
||||
>**Prerequisites:** To create, edit, or delete drivers, you need _one_ of the following permissions:
|
||||
>
|
||||
>- [Administrator Global Permissions]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/)
|
||||
>- [Custom Global Permissions]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Node Drivers]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/) role assigned.
|
||||
:::note Prerequisites:
|
||||
|
||||
To create, edit, or delete drivers, you need _one_ of the following permissions:
|
||||
|
||||
- [Administrator Global Permissions]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/)
|
||||
- [Custom Global Permissions]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Node Drivers]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/global-permissions/) role assigned.
|
||||
|
||||
:::
|
||||
|
||||
## Activating/Deactivating Node Drivers
|
||||
|
||||
|
||||
@@ -5,13 +5,21 @@ weight: 30
|
||||
|
||||
The RKE metadata feature allows you to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. This feature is useful for taking advantage of patch versions of Kubernetes, for example, if you want to upgrade to Kubernetes v1.14.7 when your Rancher server originally supported v1.14.6.
|
||||
|
||||
> **Note:** The Kubernetes API can change between minor versions. Therefore, we don't support introducing minor Kubernetes versions, such as introducing v1.15 when Rancher currently supports v1.14. You would need to upgrade Rancher to add support for minor Kubernetes versions.
|
||||
:::note
|
||||
|
||||
The Kubernetes API can change between minor versions. Therefore, we don't support introducing minor Kubernetes versions, such as introducing v1.15 when Rancher currently supports v1.14. You would need to upgrade Rancher to add support for minor Kubernetes versions.
|
||||
|
||||
:::
|
||||
|
||||
Rancher's Kubernetes metadata contains information specific to the Kubernetes version that Rancher uses to provision [RKE clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/). Rancher syncs the data periodically and creates custom resource definitions (CRDs) for **system images,** **service options** and **addon templates**. Consequently, when a new Kubernetes version is compatible with the Rancher server version, the Kubernetes metadata makes the new version available to Rancher for provisioning clusters. The metadata gives you an overview of the information that the [Rancher Kubernetes Engine]({{<baseurl>}}/rke/latest/en/) (RKE) uses for deploying various Kubernetes versions.
|
||||
|
||||
This table below describes the CRDs that are affected by the periodic data sync.
|
||||
|
||||
> **Note:** Only administrators can edit metadata CRDs. It is recommended not to update existing objects unless explicitly advised.
|
||||
:::note
|
||||
|
||||
Only administrators can edit metadata CRDs. It is recommended not to update existing objects unless explicitly advised.
|
||||
|
||||
:::
|
||||
|
||||
| Resource | Description | Rancher API URL |
|
||||
|----------|-------------|-----------------|
|
||||
@@ -39,7 +47,11 @@ You can configure Rancher to only refresh metadata when desired by setting `refr
|
||||
|
||||
### Configuring the Metadata Synchronization
|
||||
|
||||
> Only administrators can change these settings.
|
||||
:::caution
|
||||
|
||||
Only administrators can change these settings.
|
||||
|
||||
:::
|
||||
|
||||
The RKE metadata config controls how often Rancher syncs metadata and where it downloads data from. You can configure the metadata from the settings in the Rancher UI, or through the Rancher API at the endpoint `v3/settings/rke-metadata-config`.
|
||||
|
||||
|
||||
@@ -16,7 +16,11 @@ The projects and clusters accessible to non-administrative users is determined b
|
||||
|
||||
When you create a cluster or project, Rancher automatically assigns you as the `Owner` for it. Users assigned the `Owner` role can assign other users roles in the cluster or project.
|
||||
|
||||
> **Note:** Non-administrative users cannot access any existing projects/clusters by default. A user with appropriate permissions (typically the owner) must explicitly assign the project and cluster membership.
|
||||
:::note
|
||||
|
||||
Non-administrative users cannot access any existing projects/clusters by default. A user with appropriate permissions (typically the owner) must explicitly assign the project and cluster membership.
|
||||
|
||||
:::
|
||||
|
||||
### Cluster Roles
|
||||
|
||||
@@ -70,8 +74,11 @@ For details on how each cluster role can access Kubernetes resources, you can lo
|
||||
1. Click the **Cluster** tab.
|
||||
1. Click the name of an individual role. The table shows all of the operations and resources that are permitted by the role.
|
||||
|
||||
> **Note:**
|
||||
>When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes 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.
|
||||
:::note
|
||||
|
||||
When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes 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.
|
||||
|
||||
:::
|
||||
|
||||
### Giving a Custom Cluster Role to a Cluster Member
|
||||
|
||||
@@ -123,17 +130,21 @@ _Project roles_ are roles that can be used to grant users access to a project. T
|
||||
|
||||
These users can manage project-scoped resources like namespaces and workloads, but cannot manage other project members.
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
|
||||
:::note
|
||||
|
||||
By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
|
||||
|
||||
:::
|
||||
|
||||
- **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.
|
||||
:::note danger
|
||||
|
||||
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
|
||||
|
||||
@@ -165,11 +176,13 @@ The following table lists each built-in custom project role available in Rancher
|
||||
| View Volumes | ✓ | ✓ | ✓ |
|
||||
| View Workloads | ✓ | ✓ | ✓ |
|
||||
|
||||
> **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 Kubernetes 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.
|
||||
>- The `Manage Project Members` role allows the project owner to manage any members of the project **and** grant them any project scoped role regardless of their access to the project resources. Be cautious when assigning this role out individually.
|
||||
:::note 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 Kubernetes 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.
|
||||
- The `Manage Project Members` role allows the project owner to manage any members of the project **and** grant them any project scoped role regardless of their access to the project resources. Be cautious when assigning this role out individually.
|
||||
|
||||
:::
|
||||
|
||||
### Defining Custom Roles
|
||||
As previously mentioned, custom roles can be defined for use at the cluster or project level. The context field defines whether the role will appear on the cluster member page, project member page, or both.
|
||||
@@ -188,10 +201,12 @@ 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:**
|
||||
>
|
||||
>- Although you can [lock]({{<baseurl>}}/rancher/v2.6/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.
|
||||
:::note
|
||||
|
||||
- Although you can [lock]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/locked-roles/) a default role, the system still assigns the role to users who create a cluster/project.
|
||||
- Only users that create clusters/projects inherit their roles. Users added to the cluster/project membership afterward must be explicitly assigned their roles.
|
||||
|
||||
:::
|
||||
|
||||
### Configuring Default Roles for Cluster and Project Creators
|
||||
|
||||
|
||||
@@ -7,7 +7,11 @@ Within Rancher, _roles_ determine what actions a user can make within a cluster
|
||||
|
||||
Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access.
|
||||
|
||||
> It is possible for a custom role to enable privilege escalation. For details, see [this section.](#privilege-escalation)
|
||||
:::tip
|
||||
|
||||
It is possible for a custom role to enable privilege escalation. For details, see [this section.](#privilege-escalation)
|
||||
|
||||
:::
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
@@ -99,11 +103,15 @@ When a user in the group logs in, they get the built-in Standard User global rol
|
||||
|
||||
If a user is removed from the external authentication provider group, they would lose their permissions from the custom role that was assigned to the group. They would continue to have their individual Standard User role.
|
||||
|
||||
> **Prerequisites:** You can only assign a global role to a group if:
|
||||
>
|
||||
> * You have set up an [external authentication provider]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-vs-local-authentication)
|
||||
> * The external authentication provider supports [user groups]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/user-groups/)
|
||||
> * You have already set up at least one user group with the authentication provider
|
||||
:::note Prerequisites:
|
||||
|
||||
You can only assign a global role to a group if:
|
||||
|
||||
* You have set up an [external authentication provider]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-vs-local-authentication)
|
||||
* The external authentication provider supports [user groups]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/user-groups/)
|
||||
* You have already set up at least one user group with the authentication provider
|
||||
|
||||
:::
|
||||
|
||||
To assign a custom role to a group, follow these steps:
|
||||
|
||||
|
||||
@@ -177,16 +177,22 @@ For details on which Kubernetes resources correspond to each global permission,
|
||||
1. In the left navigation bar, click **Roles**.
|
||||
1. If you click the name of an individual role, a table shows all of the operations and resources that are permitted by the role.
|
||||
|
||||
> **Notes:**
|
||||
>
|
||||
> - Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalRoles`.
|
||||
> - When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes 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.
|
||||
:::note Notes:
|
||||
|
||||
- Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalRoles`.
|
||||
- When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes 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.
|
||||
|
||||
:::
|
||||
|
||||
### Configuring Default Global Permissions
|
||||
|
||||
If you want to restrict the default permissions for new users, you can remove the `user` permission as default role and then assign multiple individual permissions as default instead. Conversely, you can also add administrative permissions on top of a set of other standard permissions.
|
||||
|
||||
> **Note:** Default roles are only assigned to users added from an external authentication provider. For local users, you must explicitly assign global permissions when adding a user to Rancher. You can customize these global permissions when adding the user.
|
||||
:::note
|
||||
|
||||
Default roles are only assigned to users added from an external authentication provider. For local users, you must explicitly assign global permissions when adding a user to Rancher. You can customize these global permissions when adding the user.
|
||||
|
||||
:::
|
||||
|
||||
To change the default global permissions that are assigned to external users upon their first log in, follow these steps:
|
||||
|
||||
@@ -207,7 +213,7 @@ To configure permission for a user,
|
||||
1. In the **Global Permissions** and **Built-in** sections, check the boxes for each permission you want the user to have. If you have created roles from the **Roles** page, they will appear in the **Custom** section and you can choose from them as well.
|
||||
1. Click **Save**.
|
||||
|
||||
> **Result:** The user's global permissions have been updated.
|
||||
**Result:** The user's global permissions have been updated.
|
||||
|
||||
### Configuring Global Permissions for Groups
|
||||
|
||||
@@ -221,11 +227,15 @@ For new users, the new permissions take effect when the users log in to Rancher
|
||||
|
||||
If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default**. Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,](#refreshing-group-memberships) whichever comes first.
|
||||
|
||||
> **Prerequisites:** You can only assign a global role to a group if:
|
||||
>
|
||||
> * You have set up an [external authentication provider]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-vs-local-authentication)
|
||||
> * The external authentication provider supports [user groups]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/user-groups/)
|
||||
> * You have already set up at least one user group with the authentication provider
|
||||
:::note Prerequisites:
|
||||
|
||||
You can only assign a global role to a group if:
|
||||
|
||||
* You have set up an [external authentication provider]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-vs-local-authentication)
|
||||
* The external authentication provider supports [user groups]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/user-groups/)
|
||||
* You have already set up at least one user group with the authentication provider
|
||||
|
||||
:::
|
||||
|
||||
To assign a custom global role to a group, follow these steps:
|
||||
|
||||
|
||||
@@ -40,7 +40,11 @@ If a cluster was created from an RKE template, you can edit the cluster to updat
|
||||
|
||||
An existing cluster's settings can be [saved as an RKE template.](#converting-an-existing-cluster-to-use-an-rke-template) In that situation, you can also edit the cluster to update the cluster to a new revision of the template.
|
||||
|
||||
> **Note:** You can't change the cluster to use a different RKE template. You can only update the cluster to a new revision of the same template.
|
||||
:::note
|
||||
|
||||
You can't change the cluster to use a different RKE template. You can only update the cluster to a new revision of the same template.
|
||||
|
||||
:::
|
||||
|
||||
### Converting an Existing Cluster to Use an RKE Template
|
||||
|
||||
|
||||
@@ -140,8 +140,13 @@ To permanently delete a revision,
|
||||
|
||||
### Upgrading a Cluster to Use a New Template Revision
|
||||
|
||||
> This section assumes that you already have a cluster that [has an RKE template applied.]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rke-templates/applying-templates)
|
||||
> This section also assumes that you have [updated the template that the cluster is using](#updating-a-template) so that a new template revision is available.
|
||||
:::note
|
||||
|
||||
This section assumes that you already have a cluster that [has an RKE template applied.]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rke-templates/applying-templates)
|
||||
|
||||
This section also assumes that you have [updated the template that the cluster is using](#updating-a-template) so that a new template revision is available.
|
||||
|
||||
:::
|
||||
|
||||
To upgrade a cluster to use a new template revision,
|
||||
|
||||
|
||||
@@ -25,8 +25,12 @@ To require new clusters to use an RKE template, administrators can turn on RKE t
|
||||
1. Go to the `cluster-template-enforcement` setting. Click **⋮ > Edit Setting**.
|
||||
1. Set the value to **True** and click **Save**.
|
||||
|
||||
>**Important:** When the admin sets the `cluster-template-enforcement` to <b>True</b>, they also need to share the `clusterTemplates` with users so that users can select one of these templates to create the cluster.
|
||||
:::note Important:
|
||||
|
||||
When the admin sets the `cluster-template-enforcement` to <b>True</b>, they also need to share the `clusterTemplates` with users so that users can select one of these templates to create the cluster.
|
||||
|
||||
:::
|
||||
|
||||
**Result:** All clusters provisioned by Rancher must use a template, unless the creator is an administrator.
|
||||
|
||||
# Disabling RKE Template Enforcement
|
||||
|
||||
@@ -38,11 +38,19 @@ Go to the global settings and:
|
||||
|
||||
1. Set the `kubeconfig-generate-token` setting to `false`. This setting instructs Rancher to no longer automatically generate a token when a user clicks on download a kubeconfig file. The kubeconfig file will now provide a command to login to Rancher.
|
||||
|
||||
_**Note:**_ Once this setting is deactivated, a generated kubeconfig will reference the [Rancher CLI]({{<baseurl>}}/rancher/v2.6/en/cli) to retrieve a short lived token for the cluster. When you use this kubeconfig in a client, such as `kubectl`, the Rancher CLI needs to be installed as well.
|
||||
:::note
|
||||
|
||||
Once this setting is deactivated, a generated kubeconfig will reference the [Rancher CLI]({{<baseurl>}}/rancher/v2.6/en/cli) to retrieve a short lived token for the cluster. When you use this kubeconfig in a client, such as `kubectl`, the Rancher CLI needs to be installed as well.
|
||||
|
||||
:::
|
||||
|
||||
2. Set the `kubeconfig-token-ttl-minutes` setting to the desired duration in minutes. By default, `kubeconfig-token-ttl-minutes` is 960 (16 hours).
|
||||
|
||||
_**Note:**_ This value cannot exceed max-ttl of API tokens.(`https://<Rancher-Server-IP/v3/settings/auth-token-max-ttl-minutes`). `auth-token-max-ttl-minutes` is set to 1440 (24 hours) by default. `auth-token-max-ttl-minutes would default to 0 allowing tokens to never expire`.
|
||||
:::note
|
||||
|
||||
This value cannot exceed max-ttl of API tokens.(`https://<Rancher-Server-IP/v3/settings/auth-token-max-ttl-minutes`). `auth-token-max-ttl-minutes` is set to 1440 (24 hours) by default. `auth-token-max-ttl-minutes would default to 0 allowing tokens to never expire`.
|
||||
|
||||
:::
|
||||
|
||||
### Token Hashing
|
||||
|
||||
|
||||
@@ -9,7 +9,11 @@ The backup-restore operator needs to be installed in the local cluster, and only
|
||||
|
||||
Note that the rancher-backup operator version 2.x.x is for Rancher v2.6.x.
|
||||
|
||||
> When restoring a backup into a new Rancher setup, the version of the new setup should be the same as the one where the backup is made. The Kubernetes version should also be considered when restoring a backup, since the supported apiVersion in the cluster and in the backup file could be different.
|
||||
::: caution
|
||||
|
||||
When restoring a backup into a new Rancher setup, the version of the new setup should be the same as the one where the backup is made. The Kubernetes version should also be considered when restoring a backup, since the supported apiVersion in the cluster and in the backup file could be different.
|
||||
|
||||
:::
|
||||
|
||||
### Prerequisites
|
||||
|
||||
@@ -31,7 +35,11 @@ Backups are created as .tar.gz files. These files can be pushed to S3 or Minio,
|
||||
1. Configure the default storage location. For help, refer to the [storage configuration section.](../configuration/storage-config)
|
||||
1. Click **Install**.
|
||||
|
||||
>**NOTE:** There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{<baseurl>}}rancher/v2.6/en/deploy-across-clusters/fleet/#troubleshooting) for a workaround.
|
||||
:::note
|
||||
|
||||
There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{<baseurl>}}rancher/v2.6/en/deploy-across-clusters/fleet/#troubleshooting) for a workaround.
|
||||
|
||||
:::
|
||||
|
||||
### 2. Perform a Backup
|
||||
|
||||
@@ -65,11 +73,20 @@ To perform a backup, a custom resource of type Backup must be created.
|
||||
retentionCount: 10
|
||||
```
|
||||
|
||||
> **Note:** When creating the Backup resource using YAML editor, the `resourceSetName` must be set to `rancher-resource-set`
|
||||
:::note
|
||||
|
||||
When creating the Backup resource using YAML editor, the `resourceSetName` must be set to `rancher-resource-set`
|
||||
|
||||
For help configuring the Backup, refer to the [configuration reference](../configuration/backup-config) and to the [examples.](../examples/#backup)
|
||||
:::
|
||||
|
||||
> **Important:** The `rancher-backup` operator doesn't save the EncryptionConfiguration file. The contents of the EncryptionConfiguration file must be saved when an encrypted backup is created, and the same file must be used when restoring from this backup.
|
||||
For help configuring the Backup, refer to the [configuration reference](../configuration/backup-config) and to the [examples.](../examples/#backup)
|
||||
|
||||
:::caution
|
||||
|
||||
The `rancher-backup` operator doesn't save the EncryptionConfiguration file. The contents of the EncryptionConfiguration file must be saved when an encrypted backup is created, and the same file must be used when restoring from this backup.
|
||||
|
||||
:::
|
||||
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** The backup file is created in the storage location configured in the Backup custom resource. The name of this file is used when performing a restore.
|
||||
|
||||
@@ -43,13 +43,21 @@ When a Restore custom resource is created, the operator accesses the backup .tar
|
||||
|
||||
The Backup and Restore custom resources can be created in the Rancher UI, or by using `kubectl apply`.
|
||||
|
||||
>**Note:** Refer [here]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher/#2-restore-from-backup-using-a-restore-custom-resource) for help on restoring an existing backup file into a v1.22 cluster in Rancher v2.6.3.
|
||||
:::note
|
||||
|
||||
Refer [here]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher/#2-restore-from-backup-using-a-restore-custom-resource) for help on restoring an existing backup file into a v1.22 cluster in Rancher v2.6.3.
|
||||
|
||||
:::
|
||||
|
||||
# Installing the rancher-backup Operator
|
||||
|
||||
The `rancher-backup` operator can be installed from the Rancher UI, or with the Helm CLI. In both cases, the `rancher-backup` Helm chart is installed on the Kubernetes cluster running the Rancher server. It is a cluster-admin only feature and available only for the **local** cluster. (*If you do not see `rancher-backup` in the Rancher UI, you may have selected the wrong cluster.*)
|
||||
|
||||
>**NOTE:** There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{<baseurl>}}rancher/v2.6/en/deploy-across-clusters/fleet/#troubleshooting) for a workaround.
|
||||
:::note
|
||||
|
||||
There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{<baseurl>}}rancher/v2.6/en/deploy-across-clusters/fleet/#troubleshooting) for a workaround.
|
||||
|
||||
:::
|
||||
|
||||
### Installing rancher-backup with the Rancher UI
|
||||
|
||||
|
||||
@@ -36,9 +36,13 @@ The rancher-backup gathers resources by making calls to the kube-apiserver. Obje
|
||||
|
||||
To avoid storing them in plaintext, you can use the same encryptionConfig file that was used for at-rest encryption, to encrypt certain resources in your backup.
|
||||
|
||||
> **Important:** You must save the encryptionConfig file, because it won’t be saved by the rancher-backup operator.
|
||||
:::note Important:
|
||||
|
||||
You must save the encryptionConfig file, because it won’t be saved by the rancher-backup operator.
|
||||
The same encryptionFile needs to be used when performing a restore.
|
||||
|
||||
:::
|
||||
|
||||
The operator consumes this encryptionConfig as a Kubernetes Secret, and the Secret must be in the operator’s namespace. Rancher installs the `rancher-backup` operator in the `cattle-resources-system` namespace, so create this encryptionConfig secret in that namespace.
|
||||
|
||||
For the `EncryptionConfiguration`, you can use the [sample file provided in the Kubernetes documentation.](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#understanding-the-encryption-at-rest-configuration)
|
||||
|
||||
@@ -57,9 +57,12 @@ The `Encryption Config Secret` dropdown will filter out and list only those Secr
|
||||
| ---------------- | ---------------- |
|
||||
| `encryptionConfigSecretName` | Provide the name of the Secret from `cattle-resources-system` namespace, that contains the encryption config file. |
|
||||
|
||||
> **Important**
|
||||
:::note Important:
|
||||
|
||||
This field should only be set if the backup was created with encryption enabled. Providing the incorrect encryption config will cause the restore to fail.
|
||||
|
||||
:::
|
||||
|
||||
# Prune During Restore
|
||||
|
||||
* **Prune**: In order to fully restore Rancher from a backup, and to go back to the exact state it was at when the backup was performed, we need to delete any additional resources that were created by Rancher after the backup was taken. The operator does so if the **Prune** flag is enabled. Prune is enabled by default and it is recommended to keep it enabled.
|
||||
|
||||
@@ -40,17 +40,22 @@ Installing the `rancher-backup` chart by selecting the StorageClass option will
|
||||
|
||||
For information about creating storage classes refer to [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/volumes-and-storage/provisioning-new-storage/)
|
||||
|
||||
> **Important**
|
||||
::: note Important:
|
||||
|
||||
It is highly recommended to use a StorageClass with a reclaim policy of "Retain". Otherwise if the PVC created by the `rancher-backup` chart gets deleted (either during app upgrade, or accidentally), the PV will get deleted too, which means all backups saved in it will get deleted.
|
||||
If no such StorageClass is available, after the PV is provisioned, make sure to edit its reclaim policy and set it to "Retain" before storing backups in it.
|
||||
|
||||
:::
|
||||
|
||||
### Existing Persistent Volume
|
||||
|
||||
Select an existing Persistent Volume (PV) that will be used to store your backups. For information about creating PersistentVolumes in Rancher, refer to [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/volumes-and-storage/attaching-existing-storage/#2-add-a-persistent-volume-that-refers-to-the-persistent-storage)
|
||||
|
||||
> **Important**
|
||||
:::note Important:
|
||||
|
||||
It is highly recommended to use a Persistent Volume with a reclaim policy of "Retain". Otherwise if the PVC created by the `rancher-backup` chart gets deleted (either during app upgrade, or accidentally), the PV will get deleted too, which means all backups saved in it will get deleted.
|
||||
|
||||
:::
|
||||
|
||||
# Example values.yaml for the rancher-backup Helm Chart
|
||||
|
||||
|
||||
@@ -50,7 +50,11 @@ Using a [backup]({{<baseurl>}}/rancher/v2.6/en/backups/docker-installs/docker-ba
|
||||
|
||||
1. Enter the following command to delete your current state data and replace it with your backup data, replacing the placeholders. Don't forget to close the quotes.
|
||||
|
||||
>**Warning!** This command deletes all current state data from your Rancher Server container. Any changes saved after your backup tarball was created will be lost.
|
||||
:::danger
|
||||
|
||||
This command deletes all current state data from your Rancher Server container. Any changes saved after your backup tarball was created will be lost.
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
docker run --volumes-from <RANCHER_CONTAINER_NAME> -v $PWD:/backup \
|
||||
|
||||
@@ -9,7 +9,11 @@ If you are migrating Rancher to a new Kubernetes cluster, you don't need to inst
|
||||
|
||||
These instructions assume you have [created a backup](../back-up-rancher) and you have already installed a new Kubernetes cluster where Rancher will be deployed.
|
||||
|
||||
>**Warning:** It is required to use the same hostname that was set as the server URL in the first cluster. If not done, downstream clusters will show as unavailable in the cluster management page of the UI, and you won't be able to click inside the cluster or on the cluster's <b>Explore</b> button.
|
||||
:::caution
|
||||
|
||||
It is required to use the same hostname that was set as the server URL in the first cluster. If not done, downstream clusters will show as unavailable in the cluster management page of the UI, and you won't be able to click inside the cluster or on the cluster's <b>Explore</b> button.
|
||||
|
||||
:::
|
||||
|
||||
Rancher version must be v2.5.0 and up
|
||||
|
||||
@@ -34,16 +38,24 @@ For an **air-gapped environment**, use the option below to pull the `backup-rest
|
||||
|
||||
### 2. Restore from backup using a Restore custom resource
|
||||
|
||||
>**Important:** Kubernetes v1.22, available as an experimental feature of v2.6.3, does not support restoring from backup files containing CRDs with the apiVersion `apiextensions.k8s.io/v1beta1`. In v1.22, the default `resourceSet` in the rancher-backup app is updated to collect only CRDs that use `apiextensions.k8s.io/v1`. There are currently two ways to work around this issue:
|
||||
>
|
||||
:::note Important:
|
||||
|
||||
Kubernetes v1.22, available as an experimental feature of v2.6.3, does not support restoring from backup files containing CRDs with the apiVersion `apiextensions.k8s.io/v1beta1`. In v1.22, the default `resourceSet` in the rancher-backup app is updated to collect only CRDs that use `apiextensions.k8s.io/v1`. There are currently two ways to work around this issue:
|
||||
|
||||
1. Update the default `resourceSet` to collect the CRDs with the apiVersion v1.
|
||||
1. Update the default `resourceSet` and the client to use the new APIs internally, with `apiextensions.k8s.io/v1` as the replacement.
|
||||
>
|
||||
> - Note that when making or restoring backups for v1.22, the Rancher version and the local cluster's Kubernetes version should be the same. The Kubernetes version should be considered when restoring a backup since the supported apiVersion in the cluster and in the backup file could be different.
|
||||
|
||||
- Note that when making or restoring backups for v1.22, the Rancher version and the local cluster's Kubernetes version should be the same. The Kubernetes version should be considered when restoring a backup since the supported apiVersion in the cluster and in the backup file could be different.
|
||||
|
||||
:::
|
||||
|
||||
If you are using an S3 store as the backup source and need to use your S3 credentials for restore, create a secret in this cluster using your S3 credentials. The Secret data must have two keys - `accessKey` and `secretKey` - that contain the S3 credentials.
|
||||
|
||||
**Warning:** The values `accessKey` and `secretKey` in the example below must be base64-encoded first when creating the object directly. If not encoded first, the pasted values will cause errors when you are attempting to backup or restore.
|
||||
:::caution
|
||||
|
||||
The values `accessKey` and `secretKey` in the example below must be base64-encoded first when creating the object directly. If not encoded first, the pasted values will cause errors when you are attempting to backup or restore.
|
||||
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -82,7 +94,11 @@ spec:
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
```
|
||||
|
||||
>**Important:** The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
|
||||
:::note Important:
|
||||
|
||||
The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
|
||||
|
||||
:::
|
||||
|
||||
1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
|
||||
```
|
||||
|
||||
@@ -5,11 +5,13 @@ weight: 2
|
||||
|
||||
This page outlines how to perform a restore with Rancher.
|
||||
|
||||
> **Important**
|
||||
>
|
||||
> * Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher)
|
||||
> * While restoring rancher on the same setup, the operator will scale down the rancher deployment when restore starts, and it will scale back up the deployment once restore completes. So Rancher will be unavailable during the restore.
|
||||
> * If you need to restore Rancher to a previous version after an upgrade, see the [rollback documentation.]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/rollbacks/)
|
||||
:::note Important:
|
||||
|
||||
* Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher)
|
||||
* While restoring rancher on the same setup, the operator will scale down the rancher deployment when restore starts, and it will scale back up the deployment once restore completes. So Rancher will be unavailable during the restore.
|
||||
* If you need to restore Rancher to a previous version after an upgrade, see the [rollback documentation.]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/rollbacks/)
|
||||
|
||||
:::
|
||||
|
||||
### Additional Steps for Rollbacks with Rancher v2.6.4+
|
||||
|
||||
@@ -17,7 +19,11 @@ In Rancher v2.6.4, the cluster-api module has been upgraded from v0.4.4 to v1.0.
|
||||
|
||||
To avoid this, the Rancher resource cleanup scripts should be run **before** the restore or rollback is attempted. Specifically, two scripts have been created to assist you: one to clean up the cluster (`cleanup.sh`), and one to check for any Rancher-related resources in the cluster (`verify.sh`). Details on the cleanup script can be found in the [rancherlabs/support-tools repo](https://github.com/rancherlabs/support-tools/tree/master/rancher-cleanup).
|
||||
|
||||
> **Caution** Rancher will be down as the `cleanup` script runs as it deletes the resources created by rancher.
|
||||
:::caution
|
||||
|
||||
Rancher will be down as the `cleanup` script runs as it deletes the resources created by rancher.
|
||||
|
||||
:::
|
||||
|
||||
The additional preparations:
|
||||
|
||||
|
||||
@@ -39,7 +39,11 @@ The Kubernetes docs have more information on how resource limits can be set at t
|
||||
### Define Resource Requirements
|
||||
You should apply CPU and memory requirements to your pods. This is crucial for informing the scheduler which type of compute node your pod needs to be placed on, and ensuring it does not over-provision that node. In Kubernetes, you can set a resource requirement by defining `resources.requests` in the resource requests field in a pod's container spec. For details, refer to the [Kubernetes docs](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container).
|
||||
|
||||
> **Note:** If you set a resource limit for the namespace that the pod is deployed in, and the container doesn't have a specific resource request, the pod will not be allowed to start. To avoid setting these fields on each and every container during workload creation, a default container resource limit can be specified on the namespace.
|
||||
:::note
|
||||
|
||||
If you set a resource limit for the namespace that the pod is deployed in, and the container doesn't have a specific resource request, the pod will not be allowed to start. To avoid setting these fields on each and every container during workload creation, a default container resource limit can be specified on the namespace.
|
||||
|
||||
:::
|
||||
|
||||
It is recommended to define resource requirements on the container level because otherwise, the scheduler makes assumptions that will likely not be helpful to your application when the cluster experiences load.
|
||||
|
||||
|
||||
@@ -233,11 +233,13 @@ One can download the report from the Scans list or from the scan detail page.
|
||||
|
||||
Alerts can be configured to be sent out for a scan that runs on a schedule.
|
||||
|
||||
> **Prerequisite:**
|
||||
>
|
||||
> Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/configuration)
|
||||
>
|
||||
> While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/configuration/receiver/#example-route-config-for-cis-scan-alerts)
|
||||
:::note Prerequisite:
|
||||
|
||||
Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/configuration)
|
||||
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/configuration/receiver/#example-route-config-for-cis-scan-alerts)
|
||||
|
||||
:::
|
||||
|
||||
While installing or upgrading the `rancher-cis-benchmark` Helm chart, set the following flag to `true` in the `values.yaml`:
|
||||
|
||||
@@ -259,11 +261,13 @@ The CIS Benchmark application supports two types of alerts:
|
||||
- Alert on scan completion: This alert is sent out when the scan run finishes. The alert includes details including the ClusterScan's name and the ClusterScanProfile name.
|
||||
- Alert on scan failure: This alert is sent out if there are some test failures in the scan run or if the scan is in a `Fail` state.
|
||||
|
||||
> **Prerequisite:**
|
||||
>
|
||||
> Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/configuration)
|
||||
>
|
||||
> While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/configuration/receiver/#example-route-config-for-cis-scan-alerts)
|
||||
:::note Prerequisite
|
||||
|
||||
Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/configuration)
|
||||
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/configuration/receiver/#example-route-config-for-cis-scan-alerts)
|
||||
|
||||
:::
|
||||
|
||||
To configure alerts for a scan that runs on a schedule,
|
||||
|
||||
|
||||
@@ -32,7 +32,11 @@ spec:
|
||||
|
||||
A profile contains the configuration for the CIS scan, which includes the benchmark version to use and any specific tests to skip in that benchmark.
|
||||
|
||||
> By default, a few ClusterScanProfiles are installed as part of the `rancher-cis-benchmark` chart. If a user edits these default benchmarks or profiles, the next chart update will reset them back. So it is advisable for users to not edit the default ClusterScanProfiles.
|
||||
:::caution
|
||||
|
||||
By default, a few ClusterScanProfiles are installed as part of the `rancher-cis-benchmark` chart. If a user edits these default benchmarks or profiles, the next chart update will reset them back. So it is advisable for users to not edit the default ClusterScanProfiles.
|
||||
|
||||
:::
|
||||
|
||||
Users can clone the ClusterScanProfiles to create custom profiles.
|
||||
|
||||
@@ -67,7 +71,11 @@ A `ClusterScanBenchmark` defines the CIS `BenchmarkVersion` name and test config
|
||||
|
||||
By default, a few `BenchmarkVersion` names and test configurations are packaged as part of the CIS scan application. When this feature is enabled, these default BenchmarkVersions will be automatically installed and available for users to create a ClusterScanProfile.
|
||||
|
||||
> If the default BenchmarkVersions are edited, the next chart update will reset them back. Therefore we don't recommend editing the default ClusterScanBenchmarks.
|
||||
:::caution
|
||||
|
||||
If the default BenchmarkVersions are edited, the next chart update will reset them back. Therefore we don't recommend editing the default ClusterScanBenchmarks.
|
||||
|
||||
:::
|
||||
|
||||
A ClusterScanBenchmark consists of the fields:
|
||||
|
||||
|
||||
@@ -3,7 +3,11 @@ title: Certificate Rotation
|
||||
weight: 2040
|
||||
---
|
||||
|
||||
> **Warning:** Rotating Kubernetes certificates may result in your cluster being temporarily unavailable as components are restarted. For production environments, it's recommended to perform this action during a maintenance window.
|
||||
:::caution
|
||||
|
||||
Rotating Kubernetes certificates may result in your cluster being temporarily unavailable as components are restarted. For production environments, it's recommended to perform this action during a maintenance window.
|
||||
|
||||
:::
|
||||
|
||||
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.
|
||||
|
||||
@@ -38,8 +42,11 @@ Certificates can be rotated for the following services:
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
> **Note:** For users who didn't rotate their webhook certificates, and they have expired after one year, please see this [page]({{<baseurl>}}/rancher/v2.6/en/troubleshooting/expired-webhook-certificates/) for help.
|
||||
:::note
|
||||
|
||||
For users who didn't rotate their webhook certificates, and they have expired after one year, please see this [page]({{<baseurl>}}/rancher/v2.6/en/troubleshooting/expired-webhook-certificates/) for help.
|
||||
|
||||
:::
|
||||
|
||||
### Certificate Rotation
|
||||
|
||||
|
||||
@@ -47,7 +47,11 @@ $ sudo shutdown -r now
|
||||
|
||||
When a node is unreachable and removed from the cluster, the automatic cleaning process can't be triggered because the node is unreachable. Please follow the steps below to manually remove the Rancher components.
|
||||
|
||||
>**Warning:** The commands listed below will remove data from the node. Make sure you have created a backup of files you want to keep before executing any of the commands as data will be lost.
|
||||
:::danger
|
||||
|
||||
The commands listed below will remove data from the node. Make sure you have created a backup of files you want to keep before executing any of the commands as data will be lost.
|
||||
|
||||
:::
|
||||
|
||||
### Removing Rancher Components from Registered Clusters
|
||||
|
||||
@@ -57,7 +61,11 @@ After the registered cluster is detached from Rancher, the cluster's workloads w
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "By UI / API" %}}
|
||||
>**Warning:** This process will remove data from your cluster. Make sure you have created a backup of files you want to keep before executing the command, as data will be lost.
|
||||
:::danger
|
||||
|
||||
This process will remove data from your cluster. Make sure you have created a backup of files you want to keep before executing the command, as data will be lost.
|
||||
|
||||
:::
|
||||
|
||||
After you initiate the removal of a registered cluster using the Rancher UI (or API), the following events occur.
|
||||
|
||||
@@ -73,9 +81,11 @@ After you initiate the removal of a registered cluster using the Rancher UI (or
|
||||
{{% tab "By Script" %}}
|
||||
Rather than cleaning registered cluster nodes using the Rancher UI, you can run a script instead.
|
||||
|
||||
>**Prerequisite:**
|
||||
>
|
||||
>Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
|
||||
:::note Prerequisite:
|
||||
|
||||
Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
|
||||
|
||||
:::
|
||||
|
||||
1. Open a web browser, navigate to [GitHub](https://github.com/rancher/rancher/blob/master/cleanup/user-cluster.sh), and download `user-cluster.sh`.
|
||||
|
||||
@@ -91,13 +101,15 @@ Rather than cleaning registered cluster nodes using the Rancher UI, you can run
|
||||
|
||||
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. (`<RANCHER_VERSION>`):
|
||||
|
||||
>**Tip:**
|
||||
>
|
||||
>Add the `-dry-run` flag to preview the script's outcome without making changes.
|
||||
:::tip
|
||||
|
||||
Add the `-dry-run` flag to preview the script's outcome without making changes.
|
||||
```
|
||||
./user-cluster.sh rancher/rancher-agent:<RANCHER_VERSION>
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
**Result:** The script runs. All components listed for registered clusters in [What Gets Removed?](#what-gets-removed) are deleted.
|
||||
|
||||
{{% /tab %}}
|
||||
@@ -149,7 +161,11 @@ for mount in $(mount | grep tmpfs | grep '/var/lib/kubelet' | awk '{ print $3 }'
|
||||
|
||||
The following directories are used when adding a node to a cluster, and should be removed. You can remove a directory using `rm -rf /directory_name`.
|
||||
|
||||
>**Note:** Depending on the role you assigned to the node, some of the directories will or won't be present on the node.
|
||||
:::note
|
||||
|
||||
Depending on the role you assigned to the node, some of the directories will or won't be present on the node.
|
||||
|
||||
:::
|
||||
|
||||
Directories |
|
||||
--------|
|
||||
@@ -211,7 +227,11 @@ If you want to know more on (virtual) network interfaces or iptables rules, plea
|
||||
|
||||
### Network Interfaces
|
||||
|
||||
>**Note:** Depending on the network provider configured for the cluster the node was part of, some of the interfaces will or won't be present on the node.
|
||||
:::note
|
||||
|
||||
Depending on the network provider configured for the cluster the node was part of, some of the interfaces will or won't be present on the node.
|
||||
|
||||
:::
|
||||
|
||||
Interfaces |
|
||||
--------|
|
||||
@@ -239,7 +259,11 @@ ip link delete interface_name
|
||||
|
||||
### Iptables
|
||||
|
||||
>**Note:** Depending on the network provider configured for the cluster the node was part of, some of the chains will or won't be present on the node.
|
||||
:::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 its original state.
|
||||
|
||||
|
||||
@@ -14,7 +14,11 @@ Duplication of registered clusters is not supported.
|
||||
| [Custom Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes) | ✓ |
|
||||
| [Registered Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/) | |
|
||||
|
||||
> **Warning:** During the process of duplicating a cluster, you will edit a config file full of cluster settings. However, we recommend editing only values explicitly listed in this document, as cluster duplication is designed for simple cluster copying, _not_ wide scale configuration changes. Editing other values may invalidate the config file, which will lead to cluster deployment failure.
|
||||
:::caution
|
||||
|
||||
During the process of duplicating a cluster, you will edit a config file full of cluster settings. However, we recommend editing only values explicitly listed in this document, as cluster duplication is designed for simple cluster copying, **_not_** wide scale configuration changes. Editing other values may invalidate the config file, which will lead to cluster deployment failure.
|
||||
|
||||
:::
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -49,11 +53,19 @@ Begin by using Rancher CLI to export the configuration for the cluster that you
|
||||
|
||||
Use your favorite text editor to modify the cluster configuration in `cluster-template.yml` for your cloned cluster.
|
||||
|
||||
> **Note:** Cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0)
|
||||
:::note
|
||||
|
||||
Cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0)
|
||||
|
||||
:::
|
||||
|
||||
1. Open `cluster-template.yml` (or whatever you named your config) in your favorite text editor.
|
||||
|
||||
>**Warning:** Only edit the cluster config values explicitly called out below. Many of the values listed in this file are used to provision your cloned cluster, and editing their values may break the provisioning process.
|
||||
:::caution
|
||||
|
||||
Only edit the cluster config values explicitly called out below. Many of the values listed in this file are used to provision your cloned cluster, and editing their values may break the provisioning process.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
1. As depicted in the example below, at the `<CLUSTER_NAME>` placeholder, replace your original cluster's name with a unique name (`<CLUSTER_NAME>`). If your cloned cluster has a duplicate name, the cluster will not provision successfully.
|
||||
|
||||
@@ -5,7 +5,11 @@ weight: 2020
|
||||
|
||||
If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership.
|
||||
|
||||
>**Tip:** Want to provide a user with access to a _specific_ project within a cluster? See [Adding Project Members]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/projects-and-namespaces/project-members/) instead.
|
||||
:::tip
|
||||
|
||||
Want to provide a user with access to a _specific_ project within a cluster? See [Adding Project Members]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/projects-and-namespaces/project-members/) instead.
|
||||
|
||||
:::
|
||||
|
||||
There are two contexts where you can add cluster members:
|
||||
|
||||
@@ -30,21 +34,32 @@ Cluster administrators can edit the membership for a cluster, controlling which
|
||||
|
||||
- Rancher returns users from your [external authentication]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/) source as you type.
|
||||
|
||||
>**Using AD but can't find your users?**
|
||||
>There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/ad/).
|
||||
:::note Using AD but can't find your users?
|
||||
|
||||
There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/ad/).
|
||||
|
||||
:::
|
||||
|
||||
- A drop-down allows you to add groups instead of individual users. The drop-down only lists groups that you, the logged in user, are part of.
|
||||
|
||||
>**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
|
||||
:::note
|
||||
|
||||
If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users).
|
||||
|
||||
:::
|
||||
|
||||
1. Assign the user or group **Cluster** roles.
|
||||
|
||||
[What are Cluster Roles?]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/)
|
||||
|
||||
>**Tip:** For Custom Roles, you can modify the list of individual roles available for assignment.
|
||||
>
|
||||
> - To add roles to the list, [Add a Custom Role]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/default-custom-roles/).
|
||||
> - To remove roles from the list, [Lock/Unlock Roles]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/locked-roles).
|
||||
:::tip
|
||||
|
||||
For Custom Roles, you can modify the list of individual roles available for assignment.
|
||||
|
||||
- To add roles to the list, [Add a Custom Role]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/default-custom-roles/).
|
||||
- To remove roles from the list, [Lock/Unlock Roles]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/locked-roles).
|
||||
|
||||
:::
|
||||
|
||||
**Result:** The chosen users are added to the cluster.
|
||||
|
||||
|
||||
@@ -30,7 +30,11 @@ This section describes how to download your cluster's kubeconfig file, launch ku
|
||||
|
||||
This alternative method of accessing the cluster allows you to authenticate with Rancher and manage your cluster without using the Rancher UI.
|
||||
|
||||
> **Prerequisites:** These instructions assume that you have already created a Kubernetes cluster, and that kubectl is installed on your workstation. For help installing kubectl, refer to the official [Kubernetes documentation.](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
|
||||
:::note Prerequisites:
|
||||
|
||||
These instructions assume that you have already created a Kubernetes cluster, and that kubectl is installed on your workstation. For help installing kubectl, refer to the official [Kubernetes documentation.](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
|
||||
|
||||
:::
|
||||
|
||||
1. Log into Rancher. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you want to access with kubectl and click **Explore**.
|
||||
@@ -54,7 +58,11 @@ This method is only available for RKE clusters that have the [authorized cluster
|
||||
|
||||
We recommend that as a best practice, you should set up this method to access your RKE cluster, so that just in case you can’t connect to Rancher, you can still access the cluster.
|
||||
|
||||
> **Prerequisites:** The following steps assume that you have created a Kubernetes cluster and followed the steps to [connect to your cluster with kubectl from your workstation.](#accessing-clusters-with-kubectl-from-your-workstation)
|
||||
:::note Prerequisites:
|
||||
|
||||
The following steps assume that you have created a Kubernetes cluster and followed the steps to [connect to your cluster with kubectl from your workstation.](#accessing-clusters-with-kubectl-from-your-workstation)
|
||||
|
||||
:::
|
||||
|
||||
To find the name of the context(s) in your downloaded kubeconfig file, run:
|
||||
|
||||
|
||||
@@ -11,7 +11,11 @@ This page covers the following topics:
|
||||
- [Managing clusters in Rancher](#managing-clusters-in-rancher)
|
||||
- [Configuring tools](#configuring-tools)
|
||||
|
||||
> This section assumes a basic familiarity with Docker and Kubernetes. For a brief explanation of how Kubernetes components work together, refer to the [concepts]({{<baseurl>}}/rancher/v2.6/en/overview/concepts) page.
|
||||
:::note
|
||||
|
||||
This section assumes a basic familiarity with Docker and Kubernetes. For a brief explanation of how Kubernetes components work together, refer to the [concepts]({{<baseurl>}}/rancher/v2.6/en/overview/concepts) page.
|
||||
|
||||
:::
|
||||
|
||||
## Managing Clusters in Rancher
|
||||
|
||||
|
||||
@@ -516,7 +516,11 @@ Once the manifest file is prepared, deploy it in the Kubernetes cluster (Rancher
|
||||
kubectl -n kube-system apply -f cluster-autoscaler-deployment.yaml
|
||||
```
|
||||
|
||||
**Note:** Cluster-autoscaler deployment can also be set up using [manual configuration](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/aws#manual-configuration)
|
||||
:::note
|
||||
|
||||
Cluster-autoscaler deployment can also be set up using [manual configuration](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/aws#manual-configuration)
|
||||
|
||||
:::
|
||||
|
||||
# Testing
|
||||
|
||||
|
||||
+10
-2
@@ -19,7 +19,11 @@ Rancher can configure member roles for AKS clusters in the same way as any other
|
||||
|
||||
# Cloud Credentials
|
||||
|
||||
> The configuration information in this section assumes you have already set up a service principal for Rancher. For step-by-step instructions for how to set up the service principal, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/aks/#prerequisites-in-microsoft-azure)
|
||||
:::note
|
||||
|
||||
The configuration information in this section assumes you have already set up a service principal for Rancher. For step-by-step instructions for how to set up the service principal, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/aks/#prerequisites-in-microsoft-azure)
|
||||
|
||||
:::
|
||||
|
||||
### Subscription ID
|
||||
|
||||
@@ -165,7 +169,11 @@ The first way to ensure that Rancher is running on the same [NAT](https://docs.m
|
||||
|
||||
The second way is to run a command to register the cluster with Rancher. Once the cluster is provisioned, you can run the displayed command anywhere you can connect to the cluster’s Kubernetes API. This command is displayed in a pop-up when you provision an AKS cluster with a private API endpoint enabled.
|
||||
|
||||
> **Note:** Please be aware that when registering an existing AKS cluster, the cluster might take some time, possibly hours, to appear in the `Cluster To register` dropdown list. This outcome will be based on region.
|
||||
:::note
|
||||
|
||||
Please be aware that when registering an existing AKS cluster, the cluster might take some time, possibly hours, to appear in the `Cluster To register` dropdown list. This outcome will be based on region.
|
||||
|
||||
:::
|
||||
|
||||
For more information about connecting to an AKS private cluster, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/private-clusters#options-for-connecting-to-the-private-cluster)
|
||||
|
||||
|
||||
+10
-4
@@ -107,15 +107,21 @@ If you specify a custom AMI, whether in a launch template or in Rancher, then th
|
||||
|
||||
If you specify a launch template that does not contain a custom AMI, then Amazon will use the [EKS-optimized AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html) for the Kubernetes version and selected region. You can also select a [GPU enabled instance](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html#gpu-ami) for workloads that would benefit from it.
|
||||
|
||||
>**Note**
|
||||
>The GPU enabled instance setting in Rancher is ignored if a custom AMI is provided, either in the dropdown or in a launch template.
|
||||
:::note
|
||||
|
||||
The GPU enabled instance setting in Rancher is ignored if a custom AMI is provided, either in the dropdown or in a launch template.
|
||||
|
||||
:::
|
||||
|
||||
#### Spot instances
|
||||
|
||||
Spot instances are now [supported by EKS](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html#managed-node-group-capacity-types-spot). If a launch template is specified, Amazon recommends that the template not provide an instance type. Instead, Amazon recommends providing multiple instance types. If the "Request Spot Instances" checkbox is enabled for a node group, then you will have the opportunity to provide multiple instance types.
|
||||
|
||||
>**Note**
|
||||
>Any selection you made in the instance type dropdown will be ignored in this situation and you must specify at least one instance type to the "Spot Instance Types" section. Furthermore, a launch template used with EKS cannot request spot instances. Requesting spot instances must be part of the EKS configuration.
|
||||
:::note
|
||||
|
||||
Any selection you made in the instance type dropdown will be ignored in this situation and you must specify at least one instance type to the "Spot Instance Types" section. Furthermore, a launch template used with EKS cannot request spot instances. Requesting spot instances must be part of the EKS configuration.
|
||||
|
||||
:::
|
||||
|
||||
#### Node Group Settings
|
||||
|
||||
|
||||
+20
-4
@@ -103,13 +103,21 @@ The address range assigned to the services in the cluster. Must be a valid CIDR
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/).
|
||||
:::caution
|
||||
|
||||
Private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/).
|
||||
|
||||
:::
|
||||
|
||||
Assign nodes only internal IP addresses. Private cluster nodes cannot access the public internet unless additional networking steps are taken in GCP.
|
||||
|
||||
### Enable Private Endpoint
|
||||
|
||||
> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/).
|
||||
:::caution
|
||||
|
||||
Private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/).
|
||||
|
||||
:::
|
||||
|
||||
_Mutable: no_
|
||||
|
||||
@@ -192,9 +200,17 @@ _Mutable: yes_
|
||||
|
||||
The node operating system image. For more information for the node image options that GKE offers for each OS, refer to [this page.](https://cloud.google.com/kubernetes-engine/docs/concepts/node-images#available_node_images)
|
||||
|
||||
> Note: the default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/logging) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature]({{<baseurl>}}/rancher/v2.6/en/logging) is compatible with the Container-Optimized OS image.
|
||||
:::note
|
||||
|
||||
> Note: if selecting "Windows Long Term Service Channel" or "Windows Semi-Annual Channel" for the node pool image type, you must also add at least one Container-Optimized OS or Ubuntu node pool.
|
||||
The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/logging) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature]({{<baseurl>}}/rancher/v2.6/en/logging) is compatible with the Container-Optimized OS image.
|
||||
|
||||
:::
|
||||
|
||||
:::note
|
||||
|
||||
If selecting "Windows Long Term Service Channel" or "Windows Semi-Annual Channel" for the node pool image type, you must also add at least one Container-Optimized OS or Ubuntu node pool.
|
||||
|
||||
:::
|
||||
|
||||
### Machine Type
|
||||
|
||||
|
||||
+15
-6
@@ -11,15 +11,21 @@ Because the nodes in a private cluster only have internal IP addresses, they wil
|
||||
|
||||
#### Cloud NAT
|
||||
|
||||
>**Note**
|
||||
>Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).
|
||||
:::caution
|
||||
|
||||
Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).
|
||||
|
||||
:::
|
||||
|
||||
If restricting outgoing internet access is not a concern for your organization, use Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service to allow nodes in the private network to access the internet, enabling them to download the required images from Dockerhub and contact the Rancher management server. This is the simplest solution.
|
||||
|
||||
#### Private registry
|
||||
|
||||
>**Note**
|
||||
>This scenario is not officially supported, but is described for cases in which using the Cloud NAT service is not sufficient.
|
||||
:::caution
|
||||
|
||||
This scenario is not officially supported, but is described for cases in which using the Cloud NAT service is not sufficient.
|
||||
|
||||
:::
|
||||
|
||||
If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](https://rancher.com/docs/rancher/v2.6/en/installation/other-installation-methods/air-gap/) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.
|
||||
|
||||
@@ -29,8 +35,11 @@ If the cluster has a public endpoint exposed, Rancher will be able to reach the
|
||||
|
||||
#### Cloud NAT
|
||||
|
||||
>**Note**
|
||||
>Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).
|
||||
:::caution
|
||||
|
||||
Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).
|
||||
|
||||
:::
|
||||
|
||||
As above, if restricting outgoing internet access to the nodes is not a concern, then Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service can be used to allow the nodes to access the internet. While the cluster is provisioning, Rancher will provide a registration command to run on the cluster. Download the [kubeconfig](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl) for the new cluster and run the provided kubectl command on the cluster. Gaining access
|
||||
to the cluster in order to run this command can be done by creating a temporary node or using an existing node in the VPC, or by logging on to or creating an SSH tunnel through one of the cluster nodes.
|
||||
|
||||
@@ -15,7 +15,11 @@ You can configure the Kubernetes options one of two ways:
|
||||
|
||||
# Configuration Options in the Rancher UI
|
||||
|
||||
> Some advanced configuration options are not exposed in the Rancher UI forms, but they can be enabled by editing the K3s cluster configuration file in YAML. For the complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
|
||||
:::tip
|
||||
|
||||
Some advanced configuration options are not exposed in the Rancher UI forms, but they can be enabled by editing the K3s cluster configuration file in YAML. For the complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
|
||||
|
||||
:::
|
||||
|
||||
### Basics
|
||||
#### Kubernetes Version
|
||||
|
||||
+23
-5
@@ -77,7 +77,11 @@ To edit an RKE config file directly from the Rancher UI,
|
||||
|
||||
# Configuration Options in the Rancher UI
|
||||
|
||||
> Some advanced configuration options are not exposed in the Rancher UI forms, but they can be enabled by editing the RKE cluster configuration file in YAML. For the complete reference of configurable options for RKE Kubernetes clusters in YAML, see the [RKE documentation.]({{<baseurl>}}/rke/latest/en/config-options/)
|
||||
:::tip
|
||||
|
||||
Some advanced configuration options are not exposed in the Rancher UI forms, but they can be enabled by editing the RKE cluster configuration file in YAML. For the complete reference of configurable options for RKE Kubernetes clusters in YAML, see the [RKE documentation.]({{<baseurl>}}/rke/latest/en/config-options/)
|
||||
|
||||
:::
|
||||
|
||||
### Kubernetes Version
|
||||
|
||||
@@ -89,7 +93,11 @@ For more detail, see [Upgrading Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluste
|
||||
|
||||
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.6/en/faq/networking/cni-providers/).
|
||||
|
||||
> 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.
|
||||
:::caution
|
||||
|
||||
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.
|
||||
|
||||
:::
|
||||
|
||||
Out of the box, Rancher is compatible with the following network providers:
|
||||
|
||||
@@ -98,10 +106,12 @@ Out of the box, Rancher is compatible with the following network providers:
|
||||
- [Calico](https://docs.projectcalico.org/v3.11/introduction/)
|
||||
- [Weave](https://github.com/weaveworks/weave)
|
||||
|
||||
**Notes on Weave:**
|
||||
:::note Notes on Weave:
|
||||
|
||||
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.6/en/cluster-provisioning/rke-clusters/options/#cluster-config-file) and the [Weave Network Plug-in Options]({{<baseurl>}}/rke/latest/en/config-options/add-ons/network-plugins/#weave-network-plug-in-options).
|
||||
|
||||
:::
|
||||
|
||||
### Project Network Isolation
|
||||
|
||||
If your network provider allows project network isolation, you can choose whether to enable or disable inter-project communication.
|
||||
@@ -112,7 +122,11 @@ Project network isolation is available if you are using any RKE network plugin t
|
||||
|
||||
You can configure a [Kubernetes cloud provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers). If you want to use dynamically provisioned [volumes and storage]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/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 the cloud provider you want to use is not listed as an option, you will need to use the [config file option](#cluster-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.
|
||||
:::note
|
||||
|
||||
If the cloud provider you want to use is not listed as an option, you will need to use the [config file option](#cluster-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.
|
||||
|
||||
:::
|
||||
|
||||
### Private Registries
|
||||
|
||||
@@ -135,7 +149,11 @@ Rancher v2.6 introduced the ability to configure [ECR registries for RKE cluster
|
||||
|
||||
Authorized Cluster Endpoint can be used to directly access the Kubernetes API server, without requiring communication through Rancher.
|
||||
|
||||
> The authorized cluster endpoint only works on Rancher-launched Kubernetes clusters. In other words, it only works in clusters where Rancher [used RKE]({{<baseurl>}}/rancher/v2.6/en/overview/architecture/#tools-for-provisioning-kubernetes-clusters) to provision the cluster. It is not available for clusters in a hosted Kubernetes provider, such as Amazon's EKS.
|
||||
:::note
|
||||
|
||||
The authorized cluster endpoint only works on Rancher-launched Kubernetes clusters. In other words, it only works in clusters where Rancher [used RKE]({{<baseurl>}}/rancher/v2.6/en/overview/architecture/#tools-for-provisioning-kubernetes-clusters) to provision the cluster. It is not available for clusters in a hosted Kubernetes provider, such as Amazon's EKS.
|
||||
|
||||
:::
|
||||
|
||||
This is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates.
|
||||
|
||||
|
||||
+15
-3
@@ -15,7 +15,11 @@ You can configure the Kubernetes options in one of the two following ways:
|
||||
|
||||
# Configuration Options in the Rancher UI
|
||||
|
||||
> Some advanced configuration options are not exposed in the Rancher UI forms, but they can be enabled by editing the RKE2 cluster configuration file in YAML. For the complete reference of configurable options for RKE2 Kubernetes clusters in YAML, see the [RKE2 documentation.](https://docs.rke2.io/install/install_options/install_options/)
|
||||
:::tip
|
||||
|
||||
Some advanced configuration options are not exposed in the Rancher UI forms, but they can be enabled by editing the RKE2 cluster configuration file in YAML. For the complete reference of configurable options for RKE2 Kubernetes clusters in YAML, see the [RKE2 documentation.](https://docs.rke2.io/install/install_options/install_options/)
|
||||
|
||||
:::
|
||||
|
||||
### Basics
|
||||
#### Kubernetes Version
|
||||
@@ -28,7 +32,11 @@ For more detail, see [Upgrading Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluste
|
||||
|
||||
The [Network Provider](https://kubernetes.io/docs/concepts/cluster-administration/networking/) that the cluster uses.
|
||||
|
||||
> 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 to tear down the entire cluster and all its applications.
|
||||
:::caution
|
||||
|
||||
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 to tear down the entire cluster and all its applications.
|
||||
|
||||
:::
|
||||
|
||||
Out of the box, Rancher is compatible with the following network providers:
|
||||
|
||||
@@ -53,7 +61,11 @@ When using `cilium` or `multus,cilium` as your container network interface provi
|
||||
|
||||
You can configure a [Kubernetes cloud provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers). If you want to use dynamically provisioned [volumes and storage]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/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 the cloud provider you want to use is not listed as an option, you will need to use the [config file option](#cluster-config-file) to configure the cloud provider. Please reference [this documentation]({{<baseurl>}}/rke/latest/en/config-options/cloud-providers/) on how to configure the cloud provider.
|
||||
:::note
|
||||
|
||||
If the cloud provider you want to use is not listed as an option, you will need to use the [config file option](#cluster-config-file) to configure the cloud provider. Please reference [this documentation]({{<baseurl>}}/rke/latest/en/config-options/cloud-providers/) on how to configure the cloud provider.
|
||||
|
||||
:::
|
||||
|
||||
#### Default Pod Security Policy
|
||||
|
||||
|
||||
@@ -5,7 +5,11 @@ weight: 2030
|
||||
|
||||
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.6/en/cluster-provisioning/) to provision the cluster, there are different node options available.
|
||||
|
||||
> If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters]({{< baseurl >}}/rancher/v2.6/en/cluster-admin/editing-clusters).
|
||||
:::note
|
||||
|
||||
If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters]({{< baseurl >}}/rancher/v2.6/en/cluster-admin/editing-clusters).
|
||||
|
||||
:::
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
@@ -88,7 +92,11 @@ Use **Delete** to remove defective nodes from the cloud provider.
|
||||
|
||||
When you the delete a defective node, Rancher can automatically replace it with an identically provisioned node if the node is in a node pool and [node auto-replace is enabled.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#about-node-auto-replace)
|
||||
|
||||
>**Tip:** If your cluster is hosted by an infrastructure provider, and you want to scale your cluster down instead of deleting a defective node, [scale down](#scaling-nodes) rather than delete.
|
||||
:::tip
|
||||
|
||||
If your cluster is hosted by an infrastructure provider, and you want to scale your cluster down instead of deleting a defective node, [scale down](#scaling-nodes) rather than delete.
|
||||
|
||||
:::
|
||||
|
||||
# Scaling Nodes
|
||||
|
||||
@@ -146,7 +154,11 @@ The timeout given to each pod for cleaning things up, so they will have chance t
|
||||
|
||||
The amount of time drain should continue to wait before giving up.
|
||||
|
||||
>**Kubernetes Known Issue:** The [timeout setting](https://github.com/kubernetes/kubernetes/pull/64378) was not enforced while draining a node before Kubernetes 1.12.
|
||||
:::note Kubernetes Known Issue:
|
||||
|
||||
The [timeout setting](https://github.com/kubernetes/kubernetes/pull/64378) was not enforced while draining a node before Kubernetes 1.12.
|
||||
|
||||
:::
|
||||
|
||||
### Drained and Cordoned State
|
||||
|
||||
@@ -156,7 +168,7 @@ If the drain continues without error, the node enters a `draining` state. You'll
|
||||
|
||||
Once drain successfully completes, the node will be in a state of `drained`. You can then power off or delete the node.
|
||||
|
||||
>**Want to know more about cordon and drain?** See the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node).
|
||||
**Want to know more about cordon and drain?** See the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node).
|
||||
|
||||
# Labeling a Node to be Ignored by Rancher
|
||||
|
||||
@@ -168,7 +180,11 @@ In that case, you may want to label the node to be ignored by Rancher so that Ra
|
||||
|
||||
You can label nodes to be ignored by using a setting in the Rancher UI, or by using `kubectl`.
|
||||
|
||||
> **Note:** There is an [open issue](https://github.com/rancher/rancher/issues/24172) in which nodes labeled to be ignored can get stuck in an updating state.
|
||||
:::note
|
||||
|
||||
There is an [open issue](https://github.com/rancher/rancher/issues/24172) in which nodes labeled to be ignored can get stuck in an updating state.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
### Labeling Nodes to be Ignored with kubectl
|
||||
|
||||
@@ -9,10 +9,17 @@ _Pod Security Policies_ are objects that control security-sensitive aspects of p
|
||||
|
||||
When you create a new cluster with RKE, you can configure it to apply a PSP immediately. As you create the cluster, use the **Cluster Options** to enable a PSP. The PSP assigned to the cluster will be the default PSP for projects within the cluster.
|
||||
|
||||
>**Prerequisite:**
|
||||
>Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{<baseurl>}}/rancher/v2.6/en/admin-settings/pod-security-policies/).
|
||||
>**Note:**
|
||||
>For security purposes, we recommend assigning a PSP as you create your clusters.
|
||||
:::Prerequisite:
|
||||
|
||||
Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{<baseurl>}}/rancher/v2.6/en/admin-settings/pod-security-policies/).
|
||||
|
||||
:::
|
||||
|
||||
:::note
|
||||
|
||||
For security purposes, we recommend assigning a PSP as you create your clusters.
|
||||
|
||||
:::
|
||||
|
||||
To enable a default Pod Security Policy, set the **Pod Security Policy Support** option to **Enabled**, and then make a selection from the **Default Pod Security Policy** drop-down.
|
||||
|
||||
|
||||
@@ -3,7 +3,11 @@ title: Adding a Pod Security Policy
|
||||
weight: 80
|
||||
---
|
||||
|
||||
> **Prerequisite:** The options below are available only for clusters that are [launched using RKE.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/)
|
||||
:::note Prerequisite:
|
||||
|
||||
The options below are available only for clusters that are [launched using RKE.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/)
|
||||
|
||||
:::
|
||||
|
||||
When your cluster is running pods with security-sensitive configurations, assign it a [pod security policy]({{<baseurl>}}/rancher/v2.6/en/admin-settings/pod-security-policies/), which is a set of rules that monitors the conditions and settings in your pods. If a pod doesn't meet the rules specified in your policy, the policy stops it from running.
|
||||
|
||||
@@ -13,7 +17,11 @@ You can assign a pod security policy when you provision a cluster. However, if y
|
||||
1. Go to the cluster to which you want to apply a pod security policy and click **⋮ > Edit Config**.
|
||||
1. From **Pod Security Policy Support**, select **Enabled**.
|
||||
|
||||
>**Note:** This option is only available for clusters [provisioned by RKE]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/).
|
||||
:::note
|
||||
|
||||
This option is only available for clusters [provisioned by RKE]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/).
|
||||
|
||||
:::
|
||||
|
||||
4. From the **Default Pod Security Policy** drop-down, select the policy you want to apply to the cluster.
|
||||
|
||||
@@ -23,6 +31,10 @@ You can assign a pod security policy when you provision a cluster. However, if y
|
||||
|
||||
**Result:** The pod security policy is applied to the cluster and any projects within the cluster.
|
||||
|
||||
>**Note:** Workloads already running before assignment of a pod security policy are grandfathered in. Even if they don't meet your pod security policy, workloads running before assignment of the policy continue to run.
|
||||
>
|
||||
>To check if a running workload passes your pod security policy, clone or upgrade it.
|
||||
:::note
|
||||
|
||||
Workloads already running before assignment of a pod security policy are grandfathered in. Even if they don't meet your pod security policy, workloads running before assignment of the policy continue to run.
|
||||
|
||||
To check if a running workload passes your pod security policy, clone or upgrade it.
|
||||
|
||||
:::
|
||||
@@ -8,7 +8,11 @@ A namespace is a Kubernetes concept that allows a virtual cluster within a clust
|
||||
|
||||
A project is a group of namespaces, and it is a concept introduced by Rancher. Projects allow you to manage multiple namespaces as a group and perform Kubernetes operations in them. You can use projects to support multi-tenancy, so that a team can access a project within a cluster without having access to other projects in the same cluster.
|
||||
|
||||
>**Note:** As of Rancher v2.6, projects are de-emphasized on the UI because it is no longer required to create any Kubernetes resources within a project scope. However, resources such as [Secrets]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/secrets/#creating-secrets-in-projects) can still be created in a project scope if the legacy feature flag is enabled.
|
||||
:::note
|
||||
|
||||
As of Rancher v2.6, projects are de-emphasized on the UI because it is no longer required to create any Kubernetes resources within a project scope. However, resources such as [Secrets]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/secrets/#creating-secrets-in-projects) can still be created in a project scope if the legacy feature flag is enabled.
|
||||
|
||||
:::
|
||||
|
||||
This section describes how projects and namespaces work with Rancher. It covers the following topics:
|
||||
|
||||
@@ -25,7 +29,11 @@ This section describes how projects and namespaces work with Rancher. It covers
|
||||
|
||||
A namespace is a concept introduced by Kubernetes. According to the [official Kubernetes documentation on namespaces,](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
|
||||
> Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces. [...] Namespaces are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all.
|
||||
:::note
|
||||
|
||||
Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces. [...] Namespaces are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all.
|
||||
|
||||
:::
|
||||
|
||||
Namespaces provide the following functionality:
|
||||
|
||||
@@ -103,7 +111,11 @@ The `system` project:
|
||||
- Allows you to add more namespaces or move its namespaces to other projects.
|
||||
- Cannot be deleted because it's required for cluster operations.
|
||||
|
||||
>**Note:** In RKE clusters where 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.
|
||||
:::note
|
||||
|
||||
In RKE clusters where 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.
|
||||
|
||||
:::
|
||||
|
||||
# Project Authorization
|
||||
|
||||
@@ -149,13 +161,15 @@ Use the **Members** section to provide other users with project access and roles
|
||||
|
||||
By default, your user is added as the project `Owner`.
|
||||
|
||||
>**Notes on Permissions:**
|
||||
>
|
||||
>- 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.
|
||||
>
|
||||
>- By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
|
||||
>
|
||||
>- Choose `Custom` to create a custom role on the fly: [Custom Project Roles]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/#custom-project-roles).
|
||||
:::note Notes on Permissions:
|
||||
|
||||
- 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.
|
||||
|
||||
- By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
|
||||
|
||||
- Choose `Custom` to create a custom role on the fly: [Custom Project Roles]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/#custom-project-roles).
|
||||
|
||||
:::
|
||||
|
||||
To add members:
|
||||
|
||||
|
||||
@@ -36,7 +36,11 @@ Snapshots are composed of the cluster data in etcd, the Kubernetes version, and
|
||||
|
||||
When rolling back to a prior Kubernetes version, the [upgrade strategy options]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/upgrading-kubernetes/#configuring-the-upgrade-strategy) are ignored. Worker nodes are not cordoned or drained before being reverted to the older Kubernetes version, so that an unhealthy cluster can be more quickly restored to a healthy state.
|
||||
|
||||
> **Prerequisite:** To restore snapshots from S3, the cluster needs to be configured to [take recurring snapshots on S3.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/backing-up-etcd/#configuring-recurring-snapshots)
|
||||
:::note Prerequisite:
|
||||
|
||||
To restore snapshots from S3, the cluster needs to be configured to [take recurring snapshots on S3.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/backing-up-etcd/#configuring-recurring-snapshots)
|
||||
|
||||
:::
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. In the **Clusters** page, go to the cluster where you want to view the snapshots and click the name of the cluster.
|
||||
|
||||
@@ -45,10 +45,12 @@ The restore operation will work on a cluster that is not in a healthy or active
|
||||
|
||||
# Upgrading the Kubernetes Version
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - The options below are available only for [Rancher-launched RKE Kubernetes clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) and [Registered K3s Kubernetes clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/#additional-features-for-registered-k3s-clusters)
|
||||
> - Before upgrading Kubernetes, [back up your cluster.]({{<baseurl>}}/rancher/v2.6/en/backups)
|
||||
:::note Prerequisites:
|
||||
|
||||
- The options below are available only for [Rancher-launched RKE Kubernetes clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) and [Registered K3s Kubernetes clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/#additional-features-for-registered-k3s-clusters)
|
||||
- Before upgrading Kubernetes, [back up your cluster.]({{<baseurl>}}/rancher/v2.6/en/backups)
|
||||
|
||||
:::
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster you want to upgrade and click **⋮ > Edit Config**.
|
||||
@@ -102,7 +104,11 @@ To enable draining each node during a cluster upgrade,
|
||||
|
||||
**Result:** The cluster is updated to use the new upgrade strategy.
|
||||
|
||||
> **Note:** As of Rancher v2.4.0, there is a [known issue](https://github.com/rancher/rancher/issues/25478) in which the Rancher UI doesn't show state of etcd and controlplane as drained, even though they are being drained.
|
||||
:::note
|
||||
|
||||
As of Rancher v2.4.0, there is a [known issue](https://github.com/rancher/rancher/issues/25478) in which the Rancher UI doesn't show state of etcd and controlplane as drained, even though they are being drained.
|
||||
|
||||
:::
|
||||
|
||||
### Maintaining Availability for Applications During Upgrades
|
||||
|
||||
|
||||
+5
-1
@@ -5,7 +5,11 @@ weight: 1
|
||||
|
||||
This section describes how to set up existing persistent storage for workloads in Rancher.
|
||||
|
||||
> This section assumes that you understand the Kubernetes concepts of persistent volumes and persistent volume claims. For more information, refer to the section on [how storage works.](../how-storage-works)
|
||||
:::note
|
||||
|
||||
This section assumes that you understand the Kubernetes concepts of persistent volumes and persistent volume claims. For more information, refer to the section on [how storage works.](../how-storage-works)
|
||||
|
||||
:::
|
||||
|
||||
To set up storage, follow these steps:
|
||||
|
||||
|
||||
@@ -47,7 +47,11 @@ For more information about the `extra_binds` directive, refer to [this section.]
|
||||
|
||||
# Installing the ceph-csi driver on an RKE2 cluster
|
||||
|
||||
> **Note:** These steps are needed for dynamic RBD provisioning only.
|
||||
:::note
|
||||
|
||||
These steps are needed for dynamic RBD provisioning only.
|
||||
|
||||
:::
|
||||
|
||||
For more information about the `ceph-csi-rbd` chart, refer to [this page.](https://github.com/ceph/ceph-csi/blob/devel/charts/ceph-csi-rbd/README.md)
|
||||
|
||||
|
||||
@@ -5,13 +5,19 @@ weight: 3054
|
||||
|
||||
Before you can use the NFS storage volume plug-in with Rancher deployments, you need to provision an NFS server.
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>- If you already have an NFS share, you don't need to provision a new NFS server to use the NFS volume plugin within Rancher. Instead, skip the rest of this procedure and complete [adding storage]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/volumes-and-storage/).
|
||||
>
|
||||
>- This procedure demonstrates how to set up an NFS server using Ubuntu, although you should be able to use these instructions for other Linux distros (e.g. Debian, RHEL, Arch Linux, etc.). For official instruction on how to create an NFS server using another Linux distro, consult the distro's documentation.
|
||||
:::note
|
||||
|
||||
>**Recommended:** To simplify the process of managing firewall rules, use NFSv4.
|
||||
- If you already have an NFS share, you don't need to provision a new NFS server to use the NFS volume plugin within Rancher. Instead, skip the rest of this procedure and complete [adding storage]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/volumes-and-storage/).
|
||||
|
||||
- This procedure demonstrates how to set up an NFS server using Ubuntu, although you should be able to use these instructions for other Linux distros (e.g. Debian, RHEL, Arch Linux, etc.). For official instruction on how to create an NFS server using another Linux distro, consult the distro's documentation.
|
||||
|
||||
:::
|
||||
|
||||
:::note Recommended:
|
||||
|
||||
To simplify the process of managing firewall rules, use NFSv4.
|
||||
|
||||
:::
|
||||
|
||||
1. Using a remote Terminal connection, log into the Ubuntu server that you intend to use for NFS storage.
|
||||
|
||||
@@ -38,8 +44,12 @@ Before you can use the NFS storage volume plug-in with Rancher deployments, you
|
||||
/nfs <IP_ADDRESS1>(rw,sync,no_subtree_check) <IP_ADDRESS2>(rw,sync,no_subtree_check) <IP_ADDRESS3>(rw,sync,no_subtree_check)
|
||||
```
|
||||
|
||||
**Tip:** You can replace the IP addresses with a subnet. For example: `10.212.50.12/24`
|
||||
:::tip
|
||||
|
||||
You can replace the IP addresses with a subnet. For example: `10.212.50.12/24`
|
||||
|
||||
:::
|
||||
|
||||
1. Update the NFS table by entering the following command:
|
||||
|
||||
```
|
||||
|
||||
@@ -19,9 +19,11 @@ In order to provision vSphere volumes in a cluster created with the [Rancher Kub
|
||||
|
||||
### Creating a StorageClass
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> The following steps can also be performed using the `kubectl` command line tool. See [Kubernetes documentation on persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) for details.
|
||||
:::tip
|
||||
|
||||
The following steps can also be performed using the `kubectl` command line tool. See [Kubernetes documentation on persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) for details.
|
||||
|
||||
:::
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where you want to provide vSphere storage.
|
||||
|
||||
@@ -3,7 +3,11 @@ title: GlusterFS Volumes
|
||||
weight: 5000
|
||||
---
|
||||
|
||||
> This section only applies to [RKE clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/)
|
||||
:::note
|
||||
|
||||
This section only applies to [RKE clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/)
|
||||
|
||||
:::
|
||||
|
||||
In clusters that store data on GlusterFS volumes, you may experience an issue where pods fail to mount volumes after restarting the `kubelet`. The logging of the `kubelet` will show: `transport endpoint is not connected`. To prevent this from happening, you can configure your cluster to mount the `systemd-run` binary in the `kubelet` container. There are two requirements before you can change the cluster configuration:
|
||||
|
||||
@@ -14,9 +18,11 @@ In clusters that store data on GlusterFS volumes, you may experience an issue wh
|
||||
docker run -v /usr/bin/systemd-run:/usr/bin/systemd-run --entrypoint /usr/bin/systemd-run rancher/hyperkube:v1.16.2-rancher1 --version
|
||||
```
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>Before updating your Kubernetes YAML to mount the `systemd-run` binary, make sure the `systemd` package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.
|
||||
:::caution
|
||||
|
||||
Before updating your Kubernetes YAML to mount the `systemd-run` binary, make sure the `systemd` package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
services:
|
||||
|
||||
@@ -54,7 +54,11 @@ PVs can represent a physical disk or file system that you host on premise, or a
|
||||
|
||||
Creating a persistent volume in Rancher will not create a storage volume. It only creates a Kubernetes resource that maps to an existing volume. Therefore, before you can create a persistent volume as a Kubernetes resource, you must have storage provisioned.
|
||||
|
||||
> **Important:** PVs are created at the cluster level, which means that in a multi-tenant cluster, teams with access to separate namespaces could have access to the same PV.
|
||||
:::note Important:
|
||||
|
||||
PVs are created at the cluster level, which means that in a multi-tenant cluster, teams with access to separate namespaces could have access to the same PV.
|
||||
|
||||
:::
|
||||
|
||||
### Binding PVs to PVCs
|
||||
|
||||
@@ -62,7 +66,7 @@ When pods are set up to use persistent storage, they mount a persistent volume c
|
||||
|
||||
> Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
|
||||
|
||||
In other words, you can create unlimited PVCs, but they will only be bound to PVs if the Kubernetes master can find a sufficient PVs that has at least the amount of disk space required by the PVC.
|
||||
In other words, you can create unlimited PVCs, but they will only be bound to PVs if the Kubernetes master can find a sufficient PV that has at least the amount of disk space required by the PVC.
|
||||
|
||||
To dynamically provision new storage, the PVC mounted in the pod would have to correspond to a storage class instead of a persistent volume.
|
||||
|
||||
|
||||
@@ -17,12 +17,13 @@ If you encounter this issue, you can work around it by installing the initiator
|
||||
|
||||
After installing the initiator tool on your nodes, edit the YAML for your cluster, editing the kubelet configuration to mount the iSCSI binary and configuration, as shown in the sample below.
|
||||
|
||||
>**Notes:**
|
||||
>
|
||||
>- Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.</br>
|
||||
></br>
|
||||
>
|
||||
>- The example YAML below does not apply to K3s, but only to RKE clusters. Since the K3s kubelet does not run in a container, adding extra binds is not necessary. However, all iSCSI tools must still be installed on your K3s nodes.
|
||||
:::note Notes
|
||||
|
||||
- Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.
|
||||
|
||||
- The example YAML below does not apply to K3s, but only to RKE clusters. Since the K3s kubelet does not run in a container, adding extra binds is not necessary. However, all iSCSI tools must still be installed on your K3s nodes.
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
services:
|
||||
|
||||
@@ -8,8 +8,11 @@ You can use Rancher to create a cluster hosted in Alibaba Cloud Kubernetes (ACK)
|
||||
|
||||
# Prerequisites Outside of Rancher
|
||||
|
||||
>**Note**
|
||||
>Deploying to ACK will incur charges.
|
||||
:::caution
|
||||
|
||||
Deploying to ACK will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
1. In Aliyun, activate the following services in their respective consoles.
|
||||
|
||||
|
||||
@@ -19,8 +19,11 @@ You can use Rancher to create a cluster hosted in Microsoft Azure Kubernetes Ser
|
||||
|
||||
# Prerequisites in Microsoft Azure
|
||||
|
||||
>**Note**
|
||||
>Deploying to AKS will incur charges.
|
||||
:::caution
|
||||
|
||||
Deploying to AKS will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
To interact with Azure APIs, an AKS cluster requires an Azure Active Directory (AD) service principal. The service principal is needed to dynamically create and manage other Azure resources, and it provides credentials for your cluster to communicate with AKS. For more information about the service principal, refer to the [AKS documentation](https://docs.microsoft.com/en-us/azure/aks/kubernetes-service-principal).
|
||||
|
||||
@@ -143,7 +146,11 @@ The first way to ensure that Rancher is running on the same [NAT](https://docs.m
|
||||
|
||||
The second way is to run a command to register the cluster with Rancher. Once the cluster is provisioned, you can run the displayed command anywhere you can connect to the cluster’s Kubernetes API. This command is displayed in a pop-up when you provision an AKS cluster with a private API endpoint enabled.
|
||||
|
||||
> **Note:** Please be aware that when registering an existing AKS cluster, the cluster might take some time, possibly hours, to appear in the `Cluster To register` dropdown list. This outcome will be based on region.
|
||||
:::note
|
||||
|
||||
Please be aware that when registering an existing AKS cluster, the cluster might take some time, possibly hours, to appear in the `Cluster To register` dropdown list. This outcome will be based on region.
|
||||
|
||||
:::
|
||||
|
||||
For more information about connecting to an AKS private cluster, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/private-clusters#options-for-connecting-to-the-private-cluster)
|
||||
|
||||
|
||||
@@ -8,8 +8,11 @@ You can use Rancher to create a cluster hosted in Huawei Cloud Container Engine
|
||||
|
||||
# Prerequisites in Huawei
|
||||
|
||||
>**Note**
|
||||
>Deploying to CCE will incur charges.
|
||||
:::caution
|
||||
|
||||
Deploying to CCE will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
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).
|
||||
|
||||
@@ -67,7 +70,11 @@ You can access your cluster after its state is updated to **Active**.
|
||||
| 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. |
|
||||
|
||||
**Note:** If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0)
|
||||
:::note
|
||||
|
||||
If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0)
|
||||
|
||||
:::
|
||||
|
||||
# Node Configuration
|
||||
|
||||
|
||||
@@ -20,8 +20,11 @@ Amazon EKS provides a managed control plane for your Kubernetes cluster. Amazon
|
||||
- [Programmatically Creating EKS Clusters](#programmatically-creating-eks-clusters)
|
||||
# Prerequisites in Amazon Web Services
|
||||
|
||||
>**Note**
|
||||
>Deploying to Amazon AWS will incur charges. For more information, refer to the [EKS pricing page](https://aws.amazon.com/eks/pricing/).
|
||||
:::caution
|
||||
|
||||
Deploying to Amazon AWS will incur charges. For more information, refer to the [EKS pricing page](https://aws.amazon.com/eks/pricing/).
|
||||
|
||||
:::
|
||||
|
||||
To set up a cluster on EKS, you will need to set up an Amazon VPC (Virtual Private Cloud). You will also need to make sure that the account you will be using to create the EKS cluster has the appropriate [permissions.](#minimum-eks-permissions) For details, refer to the official guide on [Amazon EKS Prerequisites](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html#eks-prereqs).
|
||||
|
||||
@@ -39,7 +42,11 @@ Rancher needs access to your AWS account in order to provision and administer yo
|
||||
|
||||
3. Finally, follow the steps [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) to create an access key and secret key for this user.
|
||||
|
||||
> **Note:** It's important to regularly rotate your access and secret keys. See this [documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#rotating_access_keys_console) for more information.
|
||||
:::note Important:
|
||||
|
||||
It's important to regularly rotate your access and secret keys. See this [documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#rotating_access_keys_console) for more information.
|
||||
|
||||
:::
|
||||
|
||||
For more detailed information on IAM policies for EKS, refer to the official [documentation on Amazon EKS IAM Policies, Roles, and Permissions](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html).
|
||||
|
||||
|
||||
@@ -41,8 +41,11 @@ To get the project ID of an existing project, refer to the Google cloud document
|
||||
|
||||
# Provisioning a GKE Cluster
|
||||
|
||||
>**Note**
|
||||
>Deploying to GKE will incur charges.
|
||||
:::caution
|
||||
|
||||
Deploying to GKE will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
### 1. Create a Cloud Credential
|
||||
|
||||
@@ -90,8 +93,11 @@ For details on configuring GKE clusters in Rancher, see [this page.]({{<baseurl>
|
||||
|
||||
The Kubernetes version of a cluster can be upgraded to any version available in the region or zone fo the GKE cluster. Upgrading the master Kubernetes version does not automatically upgrade worker nodes. Nodes can be upgraded independently.
|
||||
|
||||
>**Note**
|
||||
>GKE has removed basic authentication in 1.19+. In order to upgrade a cluster to 1.19+, basic authentication must be disabled in the Google Cloud. Otherwise, an error will appear in Rancher when an upgrade to 1.19+ is attempted. You can follow the [Google documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/api-server-authentication#disabling_authentication_with_a_static_password). After this, the Kubernetes version can be updated to 1.19+ via Rancher.
|
||||
:::note
|
||||
|
||||
GKE has removed basic authentication in 1.19+. In order to upgrade a cluster to 1.19+, basic authentication must be disabled in the Google Cloud. Otherwise, an error will appear in Rancher when an upgrade to 1.19+ is attempted. You can follow the [Google documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/api-server-authentication#disabling_authentication_with_a_static_password). After this, the Kubernetes version can be updated to 1.19+ via Rancher.
|
||||
|
||||
:::
|
||||
|
||||
# Syncing
|
||||
|
||||
|
||||
@@ -8,8 +8,11 @@ You can use Rancher to create a cluster hosted in Tencent Kubernetes Engine (TKE
|
||||
|
||||
# Prerequisites in Tencent
|
||||
|
||||
>**Note**
|
||||
>Deploying to TKE will incur charges.
|
||||
:::caution
|
||||
|
||||
Deploying to TKE will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
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.
|
||||
|
||||
@@ -56,8 +59,12 @@ When the cluster driver is finished downloading, you will be able to create Tenc
|
||||
| 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. |
|
||||
|
||||
**Note:** If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0)
|
||||
:::note
|
||||
|
||||
If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0)
|
||||
|
||||
:::
|
||||
|
||||
7. Click `Next: Select Instance Type` to choose the instance type that will use for your TKE cluster.
|
||||
|
||||
| Option | Description |
|
||||
|
||||
@@ -5,7 +5,11 @@ weight: 1
|
||||
|
||||
This page describes the requirements for the Rancher managed Kubernetes clusters where your apps and services will be installed. These downstream clusters should be separate from the three-node cluster running Rancher.
|
||||
|
||||
> If Rancher is installed on a high-availability Kubernetes cluster, the Rancher server three-node cluster and downstream clusters have different requirements. For Rancher installation requirements, refer to the node requirements in the [installation section.]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/)
|
||||
:::note
|
||||
|
||||
If Rancher is installed on a high-availability Kubernetes cluster, the Rancher server three-node cluster and downstream clusters have different requirements. For Rancher installation requirements, refer to the node requirements in the [installation section.]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/)
|
||||
|
||||
:::
|
||||
|
||||
Make sure the nodes for the Rancher server fulfill the following requirements:
|
||||
|
||||
@@ -30,13 +34,17 @@ For information on how to install Docker, refer to the official [Docker document
|
||||
|
||||
Some distributions of Linux derived from RHEL, including Oracle Linux, may have default firewall rules that block communication with Helm. We recommend disabling firewalld. For Kubernetes 1.19, firewalld must be turned off.
|
||||
|
||||
>**Note:** In RHEL 8.4, two extra services are included on the NetworkManager: `nm-cloud-setup.service` and `nm-cloud-setup.timer`. These services add a routing table that interferes with the CNI plugin's configuration. If these services are enabled, you must disable them using the command below, and then reboot the node to restore connectivity:
|
||||
>
|
||||
> ```
|
||||
:::note
|
||||
|
||||
In RHEL 8.4, two extra services are included on the NetworkManager: `nm-cloud-setup.service` and `nm-cloud-setup.timer`. These services add a routing table that interferes with the CNI plugin's configuration. If these services are enabled, you must disable them using the command below, and then reboot the node to restore connectivity:
|
||||
|
||||
```
|
||||
systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
|
||||
reboot
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### SUSE Linux Nodes
|
||||
|
||||
SUSE Linux may have a firewall that blocks all ports by default. In that situation, follow [these steps]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/ports/#opening-suse-linux-ports) to open the ports needed for adding a host to a custom cluster.
|
||||
|
||||
@@ -14,13 +14,21 @@ This diagram is applicable to Kubernetes clusters [launched with Rancher using R
|
||||
|
||||
Nodes with the `etcd` role run etcd, which is a consistent and highly available key value store used as Kubernetes’ backing store for all cluster data. etcd replicates the data to each node.
|
||||
|
||||
>**Note:** Nodes with the `etcd` role are shown as `Unschedulable` in the UI, meaning no pods will be scheduled to these nodes by default.
|
||||
:::note
|
||||
|
||||
Nodes with the `etcd` role are shown as `Unschedulable` in the UI, meaning no pods will be scheduled to these nodes by default.
|
||||
|
||||
:::
|
||||
|
||||
# controlplane
|
||||
|
||||
Nodes with the `controlplane` role run the Kubernetes master components (excluding `etcd`, as it's a separate role). See [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components) for a detailed list of components.
|
||||
|
||||
>**Note:** Nodes with the `controlplane` role are shown as `Unschedulable` in the UI, meaning no pods will be scheduled to these nodes by default.
|
||||
:::note
|
||||
|
||||
Nodes with the `controlplane` role are shown as `Unschedulable` in the UI, meaning no pods will be scheduled to these nodes by default.
|
||||
|
||||
:::
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
|
||||
@@ -67,8 +67,11 @@ EKS clusters must have at least one managed node group to be imported into Ranch
|
||||
- **Active** clusters are assigned two Projects: `Default` (containing the namespace `default`) and `System` (containing the namespaces `cattle-system`, `ingress-nginx`, `kube-public` and `kube-system`, if present).
|
||||
|
||||
|
||||
> **Note:**
|
||||
> You can not re-register a cluster that is currently active in a Rancher setup.
|
||||
:::note
|
||||
|
||||
You can not re-register a cluster that is currently active in a Rancher setup.
|
||||
|
||||
:::
|
||||
|
||||
### Configuring a K3s Cluster to Enable Registration in Rancher
|
||||
|
||||
@@ -90,7 +93,11 @@ $ curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -s -
|
||||
|
||||
You should define **only** the minimum fields that Rancher requires when importing an EKS cluster with Terraform. This is important as Rancher will overwrite what was in the EKS cluster with any config that the user has provided.
|
||||
|
||||
>**Warning:** Even a small difference between the current EKS cluster and a user-provided config could have unexpected results.
|
||||
::caution
|
||||
|
||||
Even a small difference between the current EKS cluster and a user-provided config could have unexpected results.
|
||||
|
||||
:::
|
||||
|
||||
The minimum config fields required by Rancher to import EKS clusters with Terraform using `eks_config_v2` are as follows:
|
||||
|
||||
@@ -155,7 +162,11 @@ The capabilities for registered clusters are listed in the table on [this page.]
|
||||
|
||||
# Configuring K3s Cluster Upgrades
|
||||
|
||||
> It is a Kubernetes best practice to back up the cluster before upgrading. When upgrading a high-availability K3s cluster with an external database, back up the database in whichever way is recommended by the relational database provider.
|
||||
:::tip
|
||||
|
||||
It is a Kubernetes best practice to back up the cluster before upgrading. When upgrading a high-availability K3s cluster with an external database, back up the database in whichever way is recommended by the relational database provider.
|
||||
|
||||
:::
|
||||
|
||||
The **concurrency** is the maximum number of nodes that are permitted to be unavailable during an upgrade. If number of unavailable nodes is larger than the **concurrency,** the upgrade will fail. If an upgrade fails, you may need to repair or remove failed nodes before the upgrade can succeed.
|
||||
|
||||
@@ -194,13 +205,15 @@ _Available as of v2.6.3_
|
||||
|
||||
Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and K3s clusters. This support includes manual steps you will perform on the downstream cluster to enable the ACE. For additional information on the authorized cluster endpoint, click [here]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/ace/).
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> - These steps only need to be performed on the control plane nodes of the downstream cluster. You must configure each control plane node individually.
|
||||
>
|
||||
> - The following steps will work on both RKE2 and K3s clusters registered in v2.6.x as well as those registered (or imported) from a previous version of Rancher with an upgrade to v2.6.x.
|
||||
>
|
||||
> - These steps will alter the configuration of the downstream RKE2 and K3s clusters and deploy the `kube-api-authn-webhook`. If a future implementation of the ACE requires an update to the `kube-api-authn-webhook`, then this would also have to be done manually. For more information on this webhook, click [here]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/ace/#about-the-kube-api-auth-authentication-webhook).
|
||||
:::note Notes:
|
||||
|
||||
- These steps only need to be performed on the control plane nodes of the downstream cluster. You must configure each control plane node individually.
|
||||
|
||||
- The following steps will work on both RKE2 and K3s clusters registered in v2.6.x as well as those registered (or imported) from a previous version of Rancher with an upgrade to v2.6.x.
|
||||
|
||||
- These steps will alter the configuration of the downstream RKE2 and K3s clusters and deploy the `kube-api-authn-webhook`. If a future implementation of the ACE requires an update to the `kube-api-authn-webhook`, then this would also have to be done manually. For more information on this webhook, click [here]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/ace/#about-the-kube-api-auth-authentication-webhook).
|
||||
|
||||
:::
|
||||
|
||||
###### **Manual steps to be taken on the control plane of each downstream cluster to enable ACE:**
|
||||
|
||||
@@ -236,7 +249,11 @@ Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and
|
||||
|
||||
1. Finally, you **must** go back to the Rancher UI and edit the imported cluster there to complete the ACE enablement. Click on **⋮ > Edit Config**, then click the **Networking** tab under Cluster Configuration. Finally, click the **Enabled** button for **Authorized Endpoint**. Once the ACE is enabled, you then have the option of entering a fully qualified domain name (FQDN) and certificate information.
|
||||
|
||||
>**Note:** The <b>FQDN</b> field is optional, and if one is entered, it should point to the downstream cluster. Certificate information is only needed if there is a load balancer in front of the downstream cluster that is using an untrusted certificate. If you have a valid certificate, then nothing needs to be added to the <b>CA Certificates</b> field.
|
||||
:::note
|
||||
|
||||
The <b>FQDN</b> field is optional, and if one is entered, it should point to the downstream cluster. Certificate information is only needed if there is a load balancer in front of the downstream cluster that is using an untrusted certificate. If you have a valid certificate, then nothing needs to be added to the <b>CA Certificates</b> field.
|
||||
|
||||
:::
|
||||
|
||||
# Annotating Registered Clusters
|
||||
|
||||
|
||||
@@ -131,7 +131,11 @@ The following resources need to tagged with a `ClusterID`:
|
||||
- **Subnet**: The subnet used for your cluster.
|
||||
- **Security Group**: The security group used for your cluster.
|
||||
|
||||
>**Note:** Do not tag multiple security groups. Tagging multiple groups generates an error when creating an Elastic Load Balancer (ELB).
|
||||
:::note
|
||||
|
||||
Do not tag multiple security groups. Tagging multiple groups generates an error when creating an Elastic Load Balancer (ELB).
|
||||
|
||||
:::
|
||||
|
||||
When you create an [Amazon EC2 Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/ec2/), the `ClusterID` is automatically configured for the created nodes. Other resources still need to be tagged manually.
|
||||
|
||||
|
||||
@@ -7,7 +7,11 @@ In this section, you'll learn how to enable the Google Compute Engine (GCE) clou
|
||||
|
||||
The official Kubernetes documentation for the GCE cloud provider is [here.](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#gce)
|
||||
|
||||
> **Prerequisites:** The service account of `Identity and API` access on GCE needs the `Computer Admin` permission.
|
||||
:::note Prerequisites:
|
||||
|
||||
The service account of `Identity and API` access on GCE needs the `Computer Admin` permission.
|
||||
|
||||
:::
|
||||
|
||||
If you are using Calico,
|
||||
|
||||
|
||||
@@ -13,9 +13,11 @@ This section describes how to set up a custom cluster.
|
||||
|
||||
# Creating a Cluster with Custom Nodes
|
||||
|
||||
>**Want to use Windows hosts as Kubernetes workers?**
|
||||
>
|
||||
>See [Configuring Custom Clusters for Windows]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/) before you start.
|
||||
:::note Want to use Windows hosts as Kubernetes workers?
|
||||
|
||||
See [Configuring Custom Clusters for Windows]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/) before you start.
|
||||
|
||||
:::
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
@@ -47,12 +49,18 @@ If you're using Amazon EC2 as your host and want to use the [dual-stack](https:/
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Use **Cluster Configuration** section to choose the version of Kubernetes, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options**.
|
||||
|
||||
>**Using Windows nodes as Kubernetes workers?**
|
||||
>
|
||||
>- See [Enable the Windows Support Option]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/).
|
||||
>- The only Network Provider available for clusters with Windows support is Flannel.
|
||||
>
|
||||
>**Dual-stack on Amazon EC2:** If you're using Amazon EC2 as your host and want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) when configuring RKE.
|
||||
:::note Using Windows nodes as Kubernetes workers?
|
||||
|
||||
- See [Enable the Windows Support Option]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/).
|
||||
- The only Network Provider available for clusters with Windows support is Flannel.
|
||||
|
||||
:::
|
||||
|
||||
:::note Dual-stack on Amazon EC2:
|
||||
|
||||
If you're using Amazon EC2 as your host and want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) when configuring RKE.
|
||||
|
||||
:::
|
||||
|
||||
6. <a id="step-6"></a>Click **Next**.
|
||||
|
||||
@@ -60,10 +68,12 @@ If you're using Amazon EC2 as your host and want to use the [dual-stack](https:/
|
||||
|
||||
7. From **Node Role**, choose the roles that you want filled by a cluster node. You must provision at least one node for each role: `etcd`, `worker`, and `control plane`. All three roles are required for a custom cluster to finish provisioning. For more information on roles, see [this section.]({{<baseurl>}}/rancher/v2.6/en/overview/concepts/#roles-for-nodes-in-kubernetes-clusters)
|
||||
|
||||
>**Notes:**
|
||||
>
|
||||
>- Using Windows nodes as Kubernetes workers? See [this section]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/).
|
||||
>- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
|
||||
:::note Notes:
|
||||
|
||||
- Using Windows nodes as Kubernetes workers? See [this section]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/).
|
||||
- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
|
||||
|
||||
:::
|
||||
|
||||
8. <a id="step-8"></a>**Optional**: Click **[Show advanced options]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/rancher-agents/)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
|
||||
|
||||
@@ -71,7 +81,11 @@ If you're using Amazon EC2 as your host and want to use the [dual-stack](https:/
|
||||
|
||||
10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
|
||||
|
||||
>**Note:** Repeat steps 7-10 if you want to dedicate specific hosts to specific node roles. Repeat the steps as many times as needed.
|
||||
:::note
|
||||
|
||||
Repeat steps 7-10 if you want to dedicate specific hosts to specific node roles. Repeat the steps as many times as needed.
|
||||
|
||||
:::
|
||||
|
||||
11. When you finish running the command(s) on your Linux host(s), click **Done**.
|
||||
|
||||
@@ -93,8 +107,11 @@ If you have configured your cluster to use Amazon as **Cloud Provider**, tag you
|
||||
|
||||
[Amazon Documentation: Tagging Your Amazon EC2 Resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)
|
||||
|
||||
>**Note:** You can use Amazon EC2 instances without configuring a cloud provider in Kubernetes. You only have to configure the cloud provider if you want to use specific Kubernetes cloud provider functionality. For more information, see [Kubernetes Cloud Providers](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/)
|
||||
:::note
|
||||
|
||||
You can use Amazon EC2 instances without configuring a cloud provider in Kubernetes. You only have to configure the cloud provider if you want to use specific Kubernetes cloud provider functionality. For more information, see [Kubernetes Cloud Providers](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/)
|
||||
|
||||
:::
|
||||
|
||||
The following resources need to be tagged with a `ClusterID`:
|
||||
|
||||
@@ -102,7 +119,11 @@ The following resources need to be tagged with a `ClusterID`:
|
||||
- **Subnet**: The subnet used for your cluster
|
||||
- **Security Group**: The security group used for your cluster.
|
||||
|
||||
>**Note:** Do not tag multiple security groups. Tagging multiple groups generates an error when creating Elastic Load Balancer.
|
||||
:::note
|
||||
|
||||
Do not tag multiple security groups. Tagging multiple groups generates an error when creating Elastic Load Balancer.
|
||||
|
||||
:::
|
||||
|
||||
The tag that should be used is:
|
||||
|
||||
|
||||
@@ -10,12 +10,16 @@ First, you will set up your Azure cloud credentials in Rancher. Then you will us
|
||||
|
||||
Then you will create an Azure cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
>**Warning:** When the Rancher RKE cluster is running in Azure and has an Azure load balancer in front, the outbound flow will fail. The workaround for this problem is as follows:
|
||||
:::caution
|
||||
|
||||
> - Terminate the SSL/TLS on the internal load balancer
|
||||
> - Use the L7 load balancer
|
||||
When the Rancher RKE cluster is running in Azure and has an Azure load balancer in front, the outbound flow will fail. The workaround for this problem is as follows:
|
||||
|
||||
> For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
|
||||
- Terminate the SSL/TLS on the internal load balancer
|
||||
- Use the L7 load balancer
|
||||
|
||||
For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
|
||||
|
||||
:::
|
||||
|
||||
For more information on configuring the Kubernetes cluster that Rancher will install on the Azure nodes, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options)
|
||||
|
||||
|
||||
@@ -53,7 +53,11 @@ Creating a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rk
|
||||
1. Fill out a node template for EC2. For help filling out the form, refer to [EC2 Node Template Configuration.](./ec2-node-template-config)
|
||||
1. Click **Create**.
|
||||
|
||||
>**Note:** If you want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) that must be taken into consideration.
|
||||
:::note
|
||||
|
||||
If you want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) that must be taken into consideration.
|
||||
|
||||
:::
|
||||
|
||||
### 3. Create a cluster with node pools using the node template
|
||||
|
||||
@@ -66,7 +70,12 @@ Add one or more node pools to your cluster. For more information about node pool
|
||||
1. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. Refer to [Selecting Cloud Providers]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/) to configure the Kubernetes Cloud Provider. For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options)
|
||||
|
||||
>**Note:** If you want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) that must be taken into consideration.
|
||||
:::note
|
||||
|
||||
If you want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) that must be taken into consideration.
|
||||
|
||||
:::
|
||||
|
||||
1. Click **Create**.
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
@@ -99,7 +99,11 @@ When there are taints on the node pool and node template, if there is no conflic
|
||||
|
||||
If a node is in a node pool, Rancher can automatically replace unreachable nodes. Rancher will use the existing node template for the given node pool to recreate the node if it becomes inactive for a specified number of minutes.
|
||||
|
||||
> **Important:** Self-healing node pools are designed to help you replace worker nodes for <b>stateless</b> applications. It is not recommended to enable node auto-replace on a node pool of master nodes or nodes with persistent volumes attached, because VMs are treated ephemerally. When a node in a node pool loses connectivity with the cluster, its persistent volumes are destroyed, resulting in data loss for stateful applications.
|
||||
:::caution
|
||||
|
||||
Self-healing node pools are designed to help you replace worker nodes for <b>stateless</b> applications. It is not recommended to enable node auto-replace on a node pool of master nodes or nodes with persistent volumes attached, because VMs are treated ephemerally. When a node in a node pool loses connectivity with the cluster, its persistent volumes are destroyed, resulting in data loss for stateful applications.
|
||||
|
||||
:::
|
||||
|
||||
Node auto-replace works on top of the Kubernetes node controller. The node controller periodically checks the status of all the nodes (configurable via the `--node-monitor-period` flag of the `kube-controller`). When a node is unreachable, the node controller will taint that node. When this occurs, Rancher will begin its deletion countdown. You can configure the amount of time Rancher waits to delete the node. If the taint is not removed before the deletion countdown ends, Rancher will proceed to delete the node object. Rancher will then provision a node in accordance with the set quantity of the node pool.
|
||||
|
||||
@@ -144,7 +148,11 @@ If you don't find the node driver that you want to use, you can see if it is ava
|
||||
|
||||
Rancher v2.6 introduces provisioning for [RKE2](https://docs.rke2.io/) clusters directly from the Rancher UI. RKE2, also known as RKE Government, is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
|
||||
|
||||
> **Note:** For RKE2 cluster templates, please refer to [this page]({{<baseurl>}}/rancher/v2.6/en/admin-settings/cluster-templates/#rke2-cluster-template) for additional information.
|
||||
:::note
|
||||
|
||||
For RKE2 cluster templates, please refer to [this page]({{<baseurl>}}/rancher/v2.6/en/admin-settings/cluster-templates/#rke2-cluster-template) for additional information.
|
||||
|
||||
:::
|
||||
|
||||
### Node Roles
|
||||
|
||||
|
||||
+4
-1
@@ -22,8 +22,11 @@ For details on configuring RKE Kubernetes clusters in Rancher, refer to the [clu
|
||||
|
||||
The following sections describe the requirements for setting up Nutanix AOS so that Rancher can provision VMs and clusters.
|
||||
|
||||
**Note:** The node templates are documented and tested with Nutanix AOS version 5.20.2 and 6.0.1.
|
||||
:::note
|
||||
|
||||
The node templates are documented and tested with Nutanix AOS version 5.20.2 and 6.0.1.
|
||||
|
||||
:::
|
||||
### Create Credentials in Nutanix AOS
|
||||
|
||||
Before proceeding to create a cluster, you must ensure that you have a [Nutanix Prism Central user account](https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v6_0:wc-user-create-wc-t.html) with admin permissions. When you set up a node template, the template will need to use these credentials.
|
||||
|
||||
+9
-2
@@ -18,7 +18,11 @@ In order to leverage the template to create new VMs, Rancher has some [specific
|
||||
|
||||
There is specific tooling required for both Linux and Windows VMs to be usable by the vSphere node driver. The most critical dependency is [cloud-init](https://cloud-init.io/) for Linux and [cloudbase-init](https://cloudbase.it/cloudbase-init/) for Windows. Both of these are used for provisioning the VMs by configuring the hostname and by setting up the SSH access and the default Rancher user. Users can add additional content to these as desired if other configuration is needed. In addition, other requirements are listed below for reference.
|
||||
|
||||
**Note:** If you have any specific firewall rules or configuration, you will need to add this to the VM before creating a template.
|
||||
:::note
|
||||
|
||||
If you have any specific firewall rules or configuration, you will need to add this to the VM before creating a template.
|
||||
|
||||
:::
|
||||
|
||||
## Linux Dependencies
|
||||
|
||||
@@ -48,10 +52,13 @@ The list of packages that need to be installed on the template is as follows:
|
||||
* [cloudbase-init](https://cloudbase.it/cloudbase-init/#download)
|
||||
* [Docker EE](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker) - RKE1 Only
|
||||
|
||||
**Important to note: The configuration for Windows templates varies between RKE1 and RKE2:**
|
||||
:::note About the configuration for Windows templates varies between RKE1 and RKE2:
|
||||
|
||||
- RKE1 leverages Docker, so any RKE1 templates need to have Docker EE pre-installed as well
|
||||
- RKE2 does not require Docker EE, and thus it does not need to be installed
|
||||
|
||||
:::
|
||||
|
||||
# Creating a Template
|
||||
|
||||
You may either manually create your VM or you can utilize [other alternatives](#alternatives-to-manual-creation) to create your VM.
|
||||
|
||||
+5
-1
@@ -78,7 +78,11 @@ For tags, all your vSphere tags will show up as options to select from in your n
|
||||
|
||||
In the custom attributes, Rancher will let you select all the custom attributes you have already set up in vSphere. The custom attributes are keys and you can enter values for each one.
|
||||
|
||||
> **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere.
|
||||
:::note
|
||||
|
||||
Custom attributes are a legacy feature that will eventually be removed from vSphere.
|
||||
|
||||
:::
|
||||
|
||||
# cloud-init
|
||||
|
||||
|
||||
@@ -25,7 +25,11 @@ The vSphere node templates have been updated, allowing you to bring cloud operat
|
||||
|
||||
One of the biggest advantages of provisioning vSphere nodes with Rancher is that it allows you to take advantage of Rancher's self-healing node pools, also called the [node auto-replace feature,]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#about-node-auto-replace) in your on-premises clusters. Self-healing node pools are designed to help you replace worker nodes for stateless applications. When Rancher provisions nodes from a node template, Rancher can automatically replace unreachable nodes.
|
||||
|
||||
> **Important:** It is not recommended to enable node auto-replace on a node pool of master nodes or nodes with persistent volumes attached, because VMs are treated ephemerally. When a node in a node pool loses connectivity with the cluster, its persistent volumes are destroyed, resulting in data loss for stateful applications.
|
||||
:::caution
|
||||
|
||||
It is not recommended to enable node auto-replace on a node pool of master nodes or nodes with persistent volumes attached, because VMs are treated ephemerally. When a node in a node pool loses connectivity with the cluster, its persistent volumes are destroyed, resulting in data loss for stateful applications.
|
||||
|
||||
:::
|
||||
|
||||
### Dynamically Populated Options for Instances and Scheduling
|
||||
|
||||
|
||||
@@ -43,7 +43,11 @@ The RKE2 provisioning feature also includes installing RKE2 on Windows clusters.
|
||||
|
||||
Windows Support for RKE2 Custom Clusters requires choosing Calico as the CNI.
|
||||
|
||||
>**Important:** Rancher will allow Windows workload pods to deploy on both Windows and Linux worker nodes by default. When creating mixed clusters in RKE2, you must edit the `nodeSelector` in the chart to direct the pods to be placed onto a compatible Windows node. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) for more information on how to use `nodeSelector` to assign pods to nodes.
|
||||
:::note
|
||||
|
||||
Rancher will allow Windows workload pods to deploy on both Windows and Linux worker nodes by default. When creating mixed clusters in RKE2, you must edit the `nodeSelector` in the chart to direct the pods to be placed onto a compatible Windows node. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) for more information on how to use `nodeSelector` to assign pods to nodes.
|
||||
|
||||
:::
|
||||
|
||||
# Requirements for Windows Clusters
|
||||
|
||||
@@ -85,7 +89,11 @@ For **VXLAN (Overlay)** networking, the [KB4489899](https://support.microsoft.co
|
||||
|
||||
If you are configuring DHCP options sets for an AWS virtual private cloud, note that in the `domain-name` option field, only one domain name can be specified. According to the DHCP options [documentation:](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)
|
||||
|
||||
> Some Linux operating systems accept multiple domain names separated by spaces. However, other Linux operating systems and Windows treat the value as a single domain, which results in unexpected behavior. If your DHCP options set is associated with a VPC that has instances with multiple operating systems, specify only one domain name.
|
||||
:::note
|
||||
|
||||
Some Linux operating systems accept multiple domain names separated by spaces. However, other Linux operating systems and Windows treat the value as a single domain, which results in unexpected behavior. If your DHCP options set is associated with a VPC that has instances with multiple operating systems, specify only one domain name.
|
||||
|
||||
:::
|
||||
|
||||
### Rancher on vSphere with ESXi 6.7u2 and above
|
||||
|
||||
@@ -196,7 +204,11 @@ The instructions for creating a Windows cluster on existing nodes are very simil
|
||||
1. Optional: After you enable Windows support, you will be able to choose the Flannel backend. There are two network options: [**Host Gateway (L2bridge)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) and [**VXLAN (Overlay)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan). The default option is **VXLAN (Overlay)** mode.
|
||||
1. Click **Next**.
|
||||
|
||||
> **Important:** For <b>Host Gateway (L2bridge)</b> networking, it's best to use the same Layer 2 network for all nodes. Otherwise, you need to configure the route rules for them. For details, refer to the [documentation on configuring cloud-hosted VM routes.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/host-gateway-requirements/#cloud-hosted-vm-routes-configuration) You will also need to [disable private IP address checks]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/host-gateway-requirements/#disabling-private-ip-address-checks) if you are using Amazon EC2, Google GCE, or Azure VM.
|
||||
:::note Important:
|
||||
|
||||
For <b>Host Gateway (L2bridge)</b> networking, it's best to use the same Layer 2 network for all nodes. Otherwise, you need to configure the route rules for them. For details, refer to the [documentation on configuring cloud-hosted VM routes.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/host-gateway-requirements/#cloud-hosted-vm-routes-configuration) You will also need to [disable private IP address checks]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/host-gateway-requirements/#disabling-private-ip-address-checks) if you are using Amazon EC2, Google GCE, or Azure VM.
|
||||
|
||||
:::
|
||||
|
||||
# 3. Add Nodes to the Cluster
|
||||
|
||||
@@ -245,13 +257,17 @@ After the initial provisioning of your cluster, your cluster only has a single L
|
||||
|
||||
**Result:** The **Worker** role is installed on your Linux host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster.
|
||||
|
||||
> **Note:** Taints on Linux Worker Nodes
|
||||
>
|
||||
> For each Linux worker node added into the cluster, the following taints will be added to Linux worker node. By adding this taint to the Linux worker node, any workloads added to the Windows cluster will be automatically scheduled to the Windows worker node. If you want to schedule workloads specifically onto the Linux worker node, you will need to add tolerations to those workloads.
|
||||
:::note
|
||||
|
||||
> | Taint Key | Taint Value | Taint Effect |
|
||||
> | -------------- | ----------- | ------------ |
|
||||
> | `cattle.io/os` | `linux` | `NoSchedule` |
|
||||
Taints on Linux Worker Nodes
|
||||
|
||||
For each Linux worker node added into the cluster, the following taints will be added to Linux worker node. By adding this taint to the Linux worker node, any workloads added to the Windows cluster will be automatically scheduled to the Windows worker node. If you want to schedule workloads specifically onto the Linux worker node, you will need to add tolerations to those workloads.
|
||||
|
||||
| Taint Key | Taint Value | Taint Effect |
|
||||
| -------------- | ----------- | ------------ |
|
||||
| `cattle.io/os` | `linux` | `NoSchedule` |
|
||||
|
||||
:::
|
||||
|
||||
### Add a Windows Worker Node
|
||||
|
||||
|
||||
@@ -55,8 +55,17 @@ If you can't find anything related to your issue, contact us by [filing an issue
|
||||
|
||||
Please follow this checklist when filing an issue which will helps us investigate and fix the issue. More info means more data we can use to determine what is causing the issue or what might be related to the issue.
|
||||
|
||||
>**Note:** For large amounts of data, please use [GitHub Gist](https://gist.github.com/) or similar and link the created resource in the issue.
|
||||
>**Important:** Please remove any sensitive data as it will be publicly viewable.
|
||||
:::note
|
||||
|
||||
For large amounts of data, please use [GitHub Gist](https://gist.github.com/) or similar and link the created resource in the issue.
|
||||
|
||||
:::
|
||||
|
||||
:::note Important:
|
||||
|
||||
Please remove any sensitive data as it will be publicly viewable.
|
||||
|
||||
:::
|
||||
|
||||
- **Resources:** Provide as much as detail as possible on the used resources. As the source of the issue can be many things, including as much of detail as possible helps to determine the root cause. See some examples below:
|
||||
- **Hosts:** What specifications does the host have, like CPU/memory/disk, what cloud does it happen on, what Amazon Machine Image are you using, what DigitalOcean droplet are you using, what image are you provisioning that we can rebuild or use when we try to reproduce
|
||||
@@ -78,7 +87,11 @@ Please follow this checklist when filing an issue which will helps us investigat
|
||||
```
|
||||
- Kubernetes install using `kubectl`
|
||||
|
||||
> **Note:** Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` if Rancher is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI.
|
||||
:::note
|
||||
|
||||
Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` if Rancher is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI.
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
kubectl -n cattle-system \
|
||||
@@ -95,7 +108,11 @@ Please follow this checklist when filing an issue which will helps us investigat
|
||||
```
|
||||
- Kubernetes Install with RKE Add-On
|
||||
|
||||
> **Note:** Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` if the Rancher server is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI.
|
||||
:::note
|
||||
|
||||
Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` if the Rancher server is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI.
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
kubectl -n cattle-system \
|
||||
|
||||
@@ -88,13 +88,21 @@ Rancher will let you select from two options for Roles, **Project** and **Cluste
|
||||
|
||||
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.
|
||||
:::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://helm.sh/docs/intro/using_helm/#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 required to wrap the values with double quotes (i.e., ``"abc, bcd"``).
|
||||
:::note Example
|
||||
|
||||
When entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is required to wrap the values with double quotes (i.e., ``"abc, bcd"``).
|
||||
|
||||
:::
|
||||
|
||||
### Using a questions.yml file
|
||||
|
||||
@@ -118,7 +126,11 @@ By default, multi-cluster applications can only be managed by the user who creat
|
||||
|
||||
- **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.
|
||||
:::caution
|
||||
|
||||
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
|
||||
|
||||
@@ -148,7 +160,11 @@ The creator and any users added with the access-type "owner" to a multi-cluster
|
||||
|
||||
One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of management. Multi-cluster applications can be cloned, upgraded or rolled back.
|
||||
|
||||
> **Prerequisite:** The `legacy` feature flag needs to be enabled.
|
||||
:::note Prerequisite:
|
||||
|
||||
The `legacy` feature flag needs to be enabled.
|
||||
|
||||
:::
|
||||
|
||||
1. In the upper left corner, click **☰ > Multi-cluster Apps**.
|
||||
|
||||
@@ -160,10 +176,18 @@ One of the benefits of using a multi-cluster application as opposed to multiple
|
||||
|
||||
# Deleting a Multi-Cluster Application
|
||||
|
||||
> **Prerequisite:** The `legacy` feature flag needs to be enabled.
|
||||
:::note Prerequisite:
|
||||
|
||||
The `legacy` feature flag needs to be enabled.
|
||||
|
||||
:::
|
||||
|
||||
1. In the upper left corner, click **☰ > Multi-cluster Apps**.
|
||||
|
||||
2. Choose the multi-cluster application you want to delete and click the **⋮ > 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.
|
||||
:::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.
|
||||
|
||||
:::
|
||||
@@ -19,6 +19,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
| [2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) | Dec 21, 2021 |
|
||||
| [2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) | Mar 31, 2022 |
|
||||
| [2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) | May 12, 2022 |
|
||||
| [2.6.6](https://github.com/rancher/rancher/releases/tag/v2.6.6) | Jun 30, 2022 |
|
||||
|
||||
|
||||
### What can I expect when a feature is marked for deprecation?
|
||||
|
||||
@@ -109,11 +109,15 @@ Calico also provides a stateless IP-in-IP or VXLAN encapsulation mode that can b
|
||||
|
||||
Kubernetes workers should open TCP port `179` if using BGP or UDP port `4789` if using VXLAN encapsulation. In addition, TCP port `5473` is needed when using Typha. See [the port requirements for user clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/#networking-requirements) for more details.
|
||||
|
||||
>**Important:** In Rancher v2.6.3, Calico probes fail on Windows nodes upon RKE2 installation. <b>Note that this issue is resolved in v2.6.4.<b>
|
||||
>
|
||||
>- To work around this issue, first navigate to `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`.
|
||||
>
|
||||
>- There, change the current setting: `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` to this new setting: `https://raw.githubusercontent.com/rancher/rke2/master/windows/rke2-install.ps1`.
|
||||
:::note Important:
|
||||
|
||||
In Rancher v2.6.3, Calico probes fail on Windows nodes upon RKE2 installation. <b>Note that this issue is resolved in v2.6.4.<b>
|
||||
|
||||
- To work around this issue, first navigate to `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`.
|
||||
|
||||
- There, change the current setting: `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` to this new setting: `https://raw.githubusercontent.com/rancher/rke2/master/windows/rke2-install.ps1`.
|
||||
|
||||
:::
|
||||
|
||||

|
||||
|
||||
|
||||
@@ -98,7 +98,11 @@ You can add additional arguments/binds/environment variables via the [Config Fil
|
||||
|
||||
Use the `openssl verify` command to validate your certificate chain:
|
||||
|
||||
>**Note:** Configure `SSL_CERT_DIR` and `SSL_CERT_FILE` to a dummy location to make sure the OS installed certificates are not used when verifying manually.
|
||||
:::tip
|
||||
|
||||
Configure `SSL_CERT_DIR` and `SSL_CERT_FILE` to a dummy location to make sure the OS-installed certificates are not used when verifying manually.
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
SSL_CERT_DIR=/dummy SSL_CERT_FILE=/dummy openssl verify -CAfile ca.pem rancher.yourdomain.com.pem
|
||||
|
||||
@@ -5,7 +5,11 @@ weight: 400
|
||||
|
||||
Rancher's App Marketplace is based on Helm Repositories and Helm Charts. You can add HTTP based standard Helm Repositories as well as any Git Repository which contains charts.
|
||||
|
||||
> For a complete walkthrough of developing charts, see the [Chart Template Developer's Guide](https://helm.sh/docs/chart_template_guide/) in the official Helm documentation.
|
||||
:::tip
|
||||
|
||||
For a complete walkthrough of developing charts, see the [Chart Template Developer's Guide](https://helm.sh/docs/chart_template_guide/) in the official Helm documentation.
|
||||
|
||||
:::
|
||||
|
||||
- [Chart types](#chart-types)
|
||||
- [Helm charts](#helm-charts)
|
||||
@@ -94,7 +98,11 @@ Inside the `questions.yml`, most of the content will be around the questions to
|
||||
|
||||
For each chart, you can add the minimum and/or maximum Rancher version, which determines whether or not this chart is available to be deployed from Rancher.
|
||||
|
||||
> **Note:** Even though Rancher release versions are prefixed with a `v`, there is *no* prefix for the release version when using this option.
|
||||
:::note
|
||||
|
||||
Even though Rancher release versions are prefixed with a `v`, there is *no* prefix for the release version when using this option.
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
rancher_min_version: 2.3.0
|
||||
@@ -125,4 +133,8 @@ This reference contains variables that you can use in `questions.yml` nested und
|
||||
| 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.
|
||||
:::note
|
||||
|
||||
`subquestions[]` cannot contain `subquestions` or `show_subquestions_if` keys, but all other keys in the above table are supported.
|
||||
|
||||
:::
|
||||
|
||||
@@ -11,7 +11,11 @@ Starting in Rancher v2.6.0, a new versioning scheme for Rancher feature charts w
|
||||
|
||||
**Major Version:** The major version of the charts is tied to Rancher minor versions. When you upgrade to a new Rancher minor version, you should ensure that all of your **Apps & Marketplace** charts are also upgraded to the correct release line for the chart.
|
||||
|
||||
>**Note:** Any major versions that are less than the ones mentioned in the table below are meant for 2.5 and below only. For example, you are advised to not use <100.x.x versions of Monitoring in 2.6.x+.
|
||||
:::note
|
||||
|
||||
Any major versions that are less than the ones mentioned in the table below are meant for 2.5 and below only. For example, you are advised to not use <100.x.x versions of Monitoring in 2.6.x+.
|
||||
|
||||
:::
|
||||
|
||||
**Feature Charts:**
|
||||
|
||||
@@ -54,7 +58,11 @@ The charts page contains all Rancher, Partner, and Custom Charts.
|
||||
|
||||
All three types are deployed and managed in the same way.
|
||||
|
||||
> Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) should continue to be managed only by the Cluster Manager, and apps managed with <b>Apps & Marketplace</b> in the new UI must be managed only by <b>Apps & Marketplace</b>.
|
||||
:::note
|
||||
|
||||
Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) should continue to be managed only by the Cluster Manager, and apps managed with <b>Apps & Marketplace</b> in the new UI must be managed only by <b>Apps & Marketplace</b>.
|
||||
|
||||
:::
|
||||
|
||||
### Repositories
|
||||
|
||||
@@ -88,19 +96,21 @@ To add a private CA for Helm Chart repositories:
|
||||
```
|
||||
|
||||
|
||||
> **Note:** Helm chart repositories with authentication
|
||||
>
|
||||
> As of Rancher v2.6.3, a new value `disableSameOriginCheck` has been added to the Repo.Spec. This allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
|
||||
>
|
||||
> To use this feature for an existing Helm chart repository, click <b>⋮ > Edit YAML</b>. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
|
||||
>
|
||||
> ```yaml
|
||||
:::note Helm chart repositories with authentication
|
||||
|
||||
As of Rancher v2.6.3, a new value `disableSameOriginCheck` has been added to the Repo.Spec. This allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
|
||||
|
||||
To use this feature for an existing Helm chart repository, click <b>⋮ > Edit YAML</b>. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
spec:
|
||||
disableSameOriginCheck: true
|
||||
[...]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### Helm Compatibility
|
||||
|
||||
Only Helm 3 compatible charts are supported.
|
||||
@@ -116,11 +126,15 @@ After installing a chart, you can find it in the _"Installed Apps"_ tab. In this
|
||||
|
||||
Most Rancher tools have additional pages located in the toolbar below the _"Apps & Marketplace"_ section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.
|
||||
|
||||
> If you are upgrading your chart using _"Customize Helm options before upgrade"_ , please be aware that using the _"--force"_ option may result in errors if your chart has immutable fields. This is because some objects in Kubernetes cannot be changed once they are created. To ensure you do not get this error you can:
|
||||
>
|
||||
> * use the default upgrade option ( i.e do not use _"--force"_ option )
|
||||
> * uninstall the existing chart and install the upgraded chart
|
||||
> * delete the resources with immutable fields from the cluster before performing the _"--force"_ upgrade
|
||||
:::caution
|
||||
|
||||
If you are upgrading your chart using _"Customize Helm options before upgrade"_ , please be aware that using the _"--force"_ option may result in errors if your chart has immutable fields. This is because some objects in Kubernetes cannot be changed once they are created. To ensure you do not get this error you can:
|
||||
|
||||
* use the default upgrade option ( i.e do not use _"--force"_ option )
|
||||
* uninstall the existing chart and install the upgraded chart
|
||||
* delete the resources with immutable fields from the cluster before performing the _"--force"_ upgrade
|
||||
|
||||
:::
|
||||
|
||||
#### Changes in Rancher v2.6.3
|
||||
|
||||
|
||||
@@ -12,8 +12,11 @@ If you already have an AKS Kubernetes cluster, skip to the step about [installin
|
||||
|
||||
# Prerequisites
|
||||
|
||||
>**Note**
|
||||
>Deploying to Microsoft Azure will incur charges.
|
||||
:::caution
|
||||
|
||||
Deploying to Microsoft Azure will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
- [Microsoft Azure Account](https://azure.microsoft.com/en-us/free/): A Microsoft Azure Account is required to create resources for deploying Rancher and Kubernetes.
|
||||
- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
|
||||
|
||||
@@ -45,11 +45,13 @@ Deploying this Quick Start for a new virtual private cloud (VPC) and new Amazon
|
||||
|
||||
In this section, you'll install an EKS cluster with an ingress by using command line tools. This guide may be useful if you want to use fewer resources while trying out Rancher on EKS.
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - You should already have an AWS account.
|
||||
> - It is recommended to use an IAM user instead of the root AWS account. You will need the IAM user's access key and secret key to configure the AWS command line interface.
|
||||
> - The IAM user needs the minimum IAM policies described in the official [eksctl documentation.](https://eksctl.io/usage/minimum-iam-policies/)
|
||||
:::note Prerequisites:
|
||||
|
||||
- You should already have an AWS account.
|
||||
- It is recommended to use an IAM user instead of the root AWS account. You will need the IAM user's access key and secret key to configure the AWS command line interface.
|
||||
- The IAM user needs the minimum IAM policies described in the official [eksctl documentation.](https://eksctl.io/usage/minimum-iam-policies/)
|
||||
|
||||
:::
|
||||
|
||||
### 1. Prepare your Workstation
|
||||
|
||||
|
||||
@@ -120,7 +120,11 @@ See [TLS settings]({{<baseurl>}}/rancher/v2.6/en/installation/resources/tls-sett
|
||||
|
||||
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.
|
||||
|
||||
> **Important:** If you turn addLocal off, most Rancher v2.5 features won't work, including the EKS provisioner.
|
||||
:::caution
|
||||
|
||||
If you turn addLocal off, most Rancher v2.5 features won't work, including the EKS provisioner.
|
||||
|
||||
:::
|
||||
|
||||
If this is a concern in your environment you can set this option to "false" on your initial install.
|
||||
|
||||
@@ -181,7 +185,11 @@ We recommend configuring your load balancer as a Layer 4 balancer, forwarding pl
|
||||
|
||||
You may terminate the SSL/TLS on a L7 load balancer external to the Rancher cluster (ingress). Use the `--set tls=external` option and point your load balancer at port http 80 on all of the Rancher cluster nodes. This will expose the Rancher interface on http port 80. Be aware that clients that are allowed to connect directly to the Rancher cluster will not be encrypted. If you choose to do this we recommend that you restrict direct access at the network level to just your load balancer.
|
||||
|
||||
> **Note:** If you are using a Private CA signed certificate, add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate]({{<baseurl>}}/rancher/v2.6/en/installation/resources/tls-secrets/) to add the CA cert for Rancher.
|
||||
:::note
|
||||
|
||||
If you are using a Private CA signed certificate, add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate]({{<baseurl>}}/rancher/v2.6/en/installation/resources/tls-secrets/) to add the CA cert for Rancher.
|
||||
|
||||
:::
|
||||
|
||||
Your load balancer must support long lived websocket connections and will need to insert proxy headers so Rancher can route links correctly.
|
||||
|
||||
@@ -217,7 +225,11 @@ 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/).
|
||||
:::caution
|
||||
|
||||
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 occurrences of `FQDN` to the DNS name for Rancher.
|
||||
|
||||
@@ -70,7 +70,7 @@ To install `gcloud` and `kubectl`, perform the following steps:
|
||||
- Using gcloud config, to individually set your project ID, zone, and region.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Using gloud init" %}}
|
||||
{{% tab "Using gcloud init" %}}
|
||||
|
||||
1. Run gcloud init and follow the directions:
|
||||
|
||||
|
||||
@@ -53,7 +53,11 @@ To choose a Rancher version to install, refer to [Choosing a Rancher Version.]({
|
||||
|
||||
To choose a version of Helm to install Rancher with, refer to the [Helm version requirements]({{<baseurl>}}/rancher/v2.6/en/installation/resources/helm-version)
|
||||
|
||||
> **Note:** The installation instructions assume you are using Helm 3.
|
||||
:::note
|
||||
|
||||
The installation instructions assume you are using Helm 3.
|
||||
|
||||
:::
|
||||
|
||||
To set up Rancher,
|
||||
|
||||
@@ -87,7 +91,11 @@ kubectl create namespace cattle-system
|
||||
|
||||
The Rancher management server is designed to be secure by default and requires SSL/TLS configuration.
|
||||
|
||||
> **Note:** If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/chart-options/#external-tls-termination).
|
||||
:::note
|
||||
|
||||
If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/chart-options/#external-tls-termination).
|
||||
|
||||
:::
|
||||
|
||||
There are three recommended options for the source of the certificate used for TLS termination at the Rancher server:
|
||||
|
||||
@@ -104,7 +112,11 @@ There are three recommended options for the source of the certificate used for T
|
||||
|
||||
### 4. Install cert-manager
|
||||
|
||||
**Note:** New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommend v1.7.x because v 1.6.x will reach end-of-life on March 30, 2022.
|
||||
:::note
|
||||
|
||||
New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommend v1.7.x because v 1.6.x will reach end-of-life on March 30, 2022.
|
||||
|
||||
:::
|
||||
|
||||
> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/chart-options/#external-tls-termination).
|
||||
|
||||
@@ -112,7 +124,11 @@ This step is only required to use certificates issued by Rancher's generated CA
|
||||
|
||||
{{% accordion id="cert-manager" label="Click to Expand" %}}
|
||||
|
||||
> **Important:** Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation]({{<baseurl>}}/rancher/v2.6/en/installation/resources/upgrading-cert-manager/).
|
||||
:::note Important:
|
||||
|
||||
Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation]({{<baseurl>}}/rancher/v2.6/en/installation/resources/upgrading-cert-manager/).
|
||||
|
||||
:::
|
||||
|
||||
These instructions are adapted from the [official cert-manager documentation](https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm).
|
||||
|
||||
@@ -152,7 +168,11 @@ The exact command to install Rancher differs depending on the certificate config
|
||||
|
||||
However, irrespective of the certificate configuration, the name of the Rancher installation in the `cattle-system` namespace should always be `rancher`.
|
||||
|
||||
> **Tip for testing and development:** This final command to install Rancher requires a domain name that forwards traffic to Rancher. If you are using the Helm CLI to set up a proof-of-concept, you can use a fake domain name when passing the `hostname` option. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`, which would expose Rancher on an IP where it is running. Production installs would require a real domain name.
|
||||
:::tip Testing and Development:
|
||||
|
||||
This final command to install Rancher requires a domain name that forwards traffic to Rancher. If you are using the Helm CLI to set up a proof-of-concept, you can use a fake domain name when passing the `hostname` option. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`, which would expose Rancher on an IP where it is running. Production installs would require a real domain name.
|
||||
|
||||
:::
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher-generated Certificates" %}}
|
||||
@@ -187,7 +207,11 @@ deployment "rancher" successfully rolled out
|
||||
|
||||
This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA.
|
||||
|
||||
>**Note:** You need to have port 80 open as the HTTP-01 challenge can only be done on port 80.
|
||||
:::note
|
||||
|
||||
You need to have port 80 open as the HTTP-01 challenge can only be done on port 80.
|
||||
|
||||
:::
|
||||
|
||||
In the following command,
|
||||
|
||||
@@ -224,7 +248,11 @@ When you run this command, the `hostname` option must match the `Common Name` or
|
||||
|
||||
Although an entry in the `Subject Alternative Names` is technically required, having a matching `Common Name` maximizes compatibility with older browsers and applications.
|
||||
|
||||
> If you want to check if your certificates are correct, see [How do I check Common Name and Subject Alternative Names in my server certificate?]({{<baseurl>}}/rancher/v2.6/en/faq/technical/#how-do-i-check-common-name-and-subject-alternative-names-in-my-server-certificate)
|
||||
:::note
|
||||
|
||||
If you want to check if your certificates are correct, see [How do I check Common Name and Subject Alternative Names in my server certificate?]({{<baseurl>}}/rancher/v2.6/en/faq/technical/#how-do-i-check-common-name-and-subject-alternative-names-in-my-server-certificate)
|
||||
|
||||
:::
|
||||
|
||||
- Set the `hostname`.
|
||||
- Set the `bootstrapPassword` to something unique for the `admin` user.
|
||||
|
||||
@@ -15,10 +15,13 @@ Rancher has to be started with the lower/previous version after a rollback.
|
||||
|
||||
A restore is performed by creating a Restore custom resource.
|
||||
|
||||
> **Important**
|
||||
>
|
||||
> * Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher)
|
||||
> * While restoring Rancher on the same setup, the Rancher deployment is manually scaled down before the restore starts, then the operator will scale it back up once the restore completes. As a result, Rancher and its UI will be unavailable until the restore is complete. While the UI is unavailable, use the original cluster kubeconfig with the restore YAML file: `kubectl create -f restore.yaml`.
|
||||
:::note Important:
|
||||
|
||||
* Follow the instructions from this page for restoring Rancher on the same cluster where it was backed up from. In order to migrate Rancher to a new cluster, follow the steps to [migrate Rancher.]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher)
|
||||
|
||||
* While restoring Rancher on the same setup, the Rancher deployment is manually scaled down before the restore starts, then the operator will scale it back up once the restore completes. As a result, Rancher and its UI will be unavailable until the restore is complete. While the UI is unavailable, use the original cluster kubeconfig with the restore YAML file: `kubectl create -f restore.yaml`.
|
||||
|
||||
:::
|
||||
|
||||
### Scale the Rancher Deployment to 0
|
||||
|
||||
@@ -35,7 +38,12 @@ A restore is performed by creating a Restore custom resource.
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the local cluster and click **Explore**.
|
||||
1. In the left navigation bar, click **Rancher Backups > Restore**.
|
||||
* **Note:** If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps & Marketplace**. Refer [here]({{<baseurl>}}/rancher/v2.6/en/helm-charts/#charts) for more information.
|
||||
:::note
|
||||
|
||||
If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps & Marketplace**. Refer [here]({{<baseurl>}}/rancher/v2.6/en/helm-charts/#charts) for more information.
|
||||
|
||||
:::
|
||||
|
||||
1. Click **Create**.
|
||||
1. Create the Restore with the form or with YAML. For help creating the Restore resource using the online form, refer to the [configuration reference]({{<baseurl>}}/rancher/v2.6/en/backups/configuration/restore-config) and to the [examples.]({{<baseurl>}}/rancher/v2.6/en/backups/examples)
|
||||
1. To use the YAML editor, you can click **Create > Create from YAML.** Enter the Restore YAML. The following is an example Restore custom resource:
|
||||
@@ -100,7 +108,11 @@ To roll back to Rancher before v2.5, follow the procedure detailed here: [Restor
|
||||
|
||||
For information on how to roll back Rancher installed with Docker, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks)
|
||||
|
||||
> Managed clusters are authoritative for their state. This means restoring the rancher server will not revert workload deployments or changes made on managed clusters after the snapshot was taken.
|
||||
:::note
|
||||
|
||||
Managed clusters are authoritative for their state. This means restoring the Rancher server will not revert workload deployments or changes made on managed clusters after the snapshot was taken.
|
||||
|
||||
:::
|
||||
|
||||
# Rolling Back to Rancher v2.0-v2.1
|
||||
|
||||
|
||||
+13
-5
@@ -1,10 +1,14 @@
|
||||
---
|
||||
title: Rendering the Helm Template in an Air Gapped Environment
|
||||
title: Rendering the Helm Template in an Air-Gapped Environment
|
||||
shortTitle: Air Gap Upgrade
|
||||
weight: 1
|
||||
---
|
||||
|
||||
> These instructions assume you have already followed the instructions for a Kubernetes upgrade on [this page,]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/upgrades/) including the prerequisites, up until step 3. Upgrade Rancher.
|
||||
:::note
|
||||
|
||||
These instructions assume you have already followed the instructions for a Kubernetes upgrade on [this page,]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/upgrades/) including the prerequisites, up until step 3. Upgrade Rancher.
|
||||
|
||||
:::
|
||||
|
||||
### Rancher Helm Template Options
|
||||
|
||||
@@ -74,9 +78,13 @@ kubectl -n cattle-system apply -R -f ./rancher
|
||||
|
||||
Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
>**Having network issues following upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/namespace-migration).
|
||||
:::tip
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/namespace-migration).
|
||||
|
||||
:::
|
||||
|
||||
# Known Upgrade Issues
|
||||
|
||||
|
||||
@@ -84,8 +84,11 @@ You'll use the backup as a restore point if something goes wrong during upgrade.
|
||||
rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
> **Note:** If you want to switch to a different Helm chart repository, please follow the [steps on how to switch repositories]({{<baseurl>}}/rancher/v2.6/en/installation/resources/choosing-version/#switching-to-a-different-helm-chart-repository). If you switch repositories, make sure to list the repositories again before continuing onto Step 3 to ensure you have the correct one added.
|
||||
:::note
|
||||
|
||||
If you want to switch to a different Helm chart repository, please follow the [steps on how to switch repositories]({{<baseurl>}}/rancher/v2.6/en/installation/resources/choosing-version/#switching-to-a-different-helm-chart-repository). If you switch repositories, make sure to list the repositories again before continuing onto Step 3 to ensure you have the correct one added.
|
||||
|
||||
:::
|
||||
|
||||
1. Fetch the latest chart to install Rancher from the Helm chart repository.
|
||||
|
||||
@@ -104,7 +107,11 @@ You'll use the backup as a restore point if something goes wrong during upgrade.
|
||||
|
||||
This section describes how to upgrade normal (Internet-connected) or air gap installations of Rancher with Helm.
|
||||
|
||||
> **Air Gap Instructions:** If you are installing Rancher in an air gapped environment, skip the rest of this page and render the Helm template by following the instructions on [this page.](./air-gap-upgrade)
|
||||
:::note Air Gap Instructions:
|
||||
|
||||
If you are installing Rancher in an air gapped environment, skip the rest of this page and render the Helm template by following the instructions on [this page.](./air-gap-upgrade)
|
||||
|
||||
:::
|
||||
|
||||
|
||||
Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
|
||||
@@ -115,7 +122,12 @@ helm get values rancher -n cattle-system
|
||||
hostname: rancher.my.org
|
||||
```
|
||||
|
||||
> **Note:** There will be more values that are listed with this command. This is just an example of one of the values.
|
||||
:::note
|
||||
|
||||
There will be more values that are listed with this command. This is just an example of one of the values.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
If you are also upgrading cert-manager to the latest version from a version older than 0.11.0, follow [Option B: Reinstalling Rancher and cert-manager.](#option-b-reinstalling-rancher-and-cert-manager)
|
||||
|
||||
@@ -133,7 +145,11 @@ helm upgrade rancher rancher-<CHART_REPO>/rancher \
|
||||
--set hostname=rancher.my.org
|
||||
```
|
||||
|
||||
> **Note:** The above is an example, there may be more values from the previous step that need to be appended.
|
||||
:::note
|
||||
|
||||
The above is an example, there may be more values from the previous step that need to be appended.
|
||||
|
||||
:::
|
||||
|
||||
Alternatively, it's possible to export the current values to a file and reference that file during upgrade. For example, to only change the Rancher version:
|
||||
|
||||
@@ -176,9 +192,13 @@ If you are currently running the cert-manager whose version is 1.5 or below, and
|
||||
|
||||
Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
>**Having network issues following upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/namespace-migration).
|
||||
:::tip
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/namespace-migration).
|
||||
|
||||
:::
|
||||
|
||||
# Known Upgrade Issues
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user