diff --git a/content/k3s/latest/en/installation/ha/_index.md b/content/k3s/latest/en/installation/ha/_index.md index 81adf97d1a7..ca6897ae48a 100644 --- a/content/k3s/latest/en/installation/ha/_index.md +++ b/content/k3s/latest/en/installation/ha/_index.md @@ -16,7 +16,7 @@ The following diagram illustrates the above configuration: In this architecture a server node is defined as a machine (bare-metal or virtual) running the `k3s server` command. A worker node is defined as a machine running the `k3s agent` command. -Workers register through the fixed registration address, but after registration they establish a connection directly to one of the sever nodes. This is a websocket connection initiated by the `k3s agent` process and it is maintained by a client-side load balancer running as part of the agent process. +Workers register through the fixed registration address, but after registration they establish a connection directly to one of the server nodes. This is a websocket connection initiated by the `k3s agent` process and it is maintained by a client-side load balancer running as part of the agent process. Installation Outline -------------------- diff --git a/content/k3s/latest/en/installation/network-options/_index.md b/content/k3s/latest/en/installation/network-options/_index.md index 2894215706c..b981d8775cf 100644 --- a/content/k3s/latest/en/installation/network-options/_index.md +++ b/content/k3s/latest/en/installation/network-options/_index.md @@ -34,7 +34,7 @@ Visit the [Project Calico Docs](https://docs.projectcalico.org/) website. Follow } ``` -Applyl the Canal YAML. +Apply the Canal YAML. Ensure the settings were applied by running the following command on the host: @@ -68,4 +68,3 @@ You should see that IP forwarding is set to true. {{% /tab %}} {{% /tabs %}} - diff --git a/content/os/v1.x/en/about/security/_index.md b/content/os/v1.x/en/about/security/_index.md index a7cc30096dc..00286cf1a53 100644 --- a/content/os/v1.x/en/about/security/_index.md +++ b/content/os/v1.x/en/about/security/_index.md @@ -14,7 +14,7 @@ weight: 303

Please submit possible security issues by emailing security@rancher.com

-

Announcments

+

Announcements

Subscribe to the Rancher announcements forum for release updates.

diff --git a/content/os/v1.x/en/installation/configuration/adding-kernel-parameters/_index.md b/content/os/v1.x/en/installation/configuration/adding-kernel-parameters/_index.md index 49d4242bb19..cafa5232098 100644 --- a/content/os/v1.x/en/installation/configuration/adding-kernel-parameters/_index.md +++ b/content/os/v1.x/en/installation/configuration/adding-kernel-parameters/_index.md @@ -49,7 +49,7 @@ On desktop systems the Syslinux boot menu can be switched to graphical mode by a #### Recovery console -`rancher.recovery=true` will start a single user `root` bash session as easily in the boot process, with no network, or persitent filesystem mounted. This can be used to fix disk problems, or to debug your system. +`rancher.recovery=true` will start a single user `root` bash session as easily in the boot process, with no network, or persistent filesystem mounted. This can be used to fix disk problems, or to debug your system. #### Enable/Disable sshd @@ -61,7 +61,7 @@ On desktop systems the Syslinux boot menu can be switched to graphical mode by a #### Autologin console -`rancher.autologin=` will automatically log in the sepcified console - common values are `tty1`, `ttyS0` and `ttyAMA0` - depending on your platform. +`rancher.autologin=` will automatically log in the specified console - common values are `tty1`, `ttyS0` and `ttyAMA0` - depending on your platform. #### Enable/Disable hypervisor service auto-enable diff --git a/content/os/v1.x/en/installation/configuration/docker/_index.md b/content/os/v1.x/en/installation/configuration/docker/_index.md index ef670d9ef93..0620f6ecd6d 100644 --- a/content/os/v1.x/en/installation/configuration/docker/_index.md +++ b/content/os/v1.x/en/installation/configuration/docker/_index.md @@ -119,7 +119,7 @@ $ ros config set rancher.system_docker.bip 172.19.0.0/16 _Available as of v1.4.x_ -The default path of system-docker logs is `/var/log/system-docker.log`. If you want to write the system-docker logs to a separate partition, +The default path of system-docker logs is `/var/log/system-docker.log`. If you want to write the system-docker logs to a separate partition, e.g. [RANCHER_OEM partition]({{< baseurl >}}/os/v1.x/en/about/custom-partition-layout/#use-rancher-oem-partition), you can try `rancher.defaults.system_docker_logs`: ``` @@ -170,11 +170,11 @@ Status: Downloaded newer image for alpine:latest _Available as of v1.5.0_ -When RancherOS is booted, you start with a User Docker service that is running in System Docker. With v1.5.0, RancherOS has the ability to create additional User Docker services that can run at the same time. +When RancherOS is booted, you start with a User Docker service that is running in System Docker. With v1.5.0, RancherOS has the ability to create additional User Docker services that can run at the same time. #### Terminology -Throughout the rest of this documentation, we may simplify to use these terms when describing Docker. +Throughout the rest of this documentation, we may simplify to use these terms when describing Docker. | Terminology | Definition | |-----------------------|--------------------------------------------------| @@ -184,13 +184,13 @@ Throughout the rest of this documentation, we may simplify to use these terms wh #### Pre-Requisites -User Docker must be set as Docker 17.12.1 or earlier. If it's a later Docker version, it will produce errors when creating a user defined network in System Docker. +User Docker must be set as Docker 17.12.1 or earlier. If it's a later Docker version, it will produce errors when creating a user defined network in System Docker. ``` $ ros engine switch docker-17.12.1-ce ``` -You will need to create a user-defined network, which will be used when creating the Other User Docker. +You will need to create a user-defined network, which will be used when creating the Other User Docker. ``` $ system-docker network create --subnet=172.20.0.0/16 dind @@ -204,7 +204,7 @@ In order to create another User Docker, you will use `ros engine create`. Curren $ ros engine create otheruserdockername --network=dind --fixed-ip=172.20.0.2 ``` -After the Other User Docker service is created, users can query this service like other services. +After the Other User Docker service is created, users can query this service like other services. ``` $ ros service list @@ -215,13 +215,13 @@ disabled volume-nfs enabled otheruserdockername ``` -You can use `ros service up` to start the Other User Docker service. +You can use `ros service up` to start the Other User Docker service. ``` $ ros service up otheruserdockername ``` -After the Other User Docker service is running, you can interact with it just like you can use the built-in User Docker. You would need to append `-` to `docker`. +After the Other User Docker service is running, you can interact with it just like you can use the built-in User Docker. You would need to append `-` to `docker`. ``` $ docker-otheruserdockername ps -a @@ -229,7 +229,7 @@ $ docker-otheruserdockername ps -a #### SSH into the Other User Docker container -When creating the Other User Docker, you can set an external SSH port so you can SSH into the Other User Docker container in System Docker. By using `--ssh-port` and adding ssh keys with `--authorized-keys`, you can set up this optional SSH port. +When creating the Other User Docker, you can set an external SSH port so you can SSH into the Other User Docker container in System Docker. By using `--ssh-port` and adding ssh keys with `--authorized-keys`, you can set up this optional SSH port. ``` $ ros engine create --help @@ -248,7 +248,7 @@ When using `--authorized-keys`, you will need to put the key file in one of the /home/ ``` -RancherOS will generate a random password for each Other User Docker container, which can be viewed in the container logs. If you do not set any SSH keys, the password can be used. +RancherOS will generate a random password for each Other User Docker container, which can be viewed in the container logs. If you do not set any SSH keys, the password can be used. ``` $ system-docker logs otheruserdockername @@ -259,7 +259,7 @@ password: xCrw6fEG ====================================== ``` -In System Docker, you can SSH into any Other Uesr Docker Container using `ssh`. +In System Docker, you can SSH into any Other User Docker Container using `ssh`. ``` $ system-docker ps @@ -274,7 +274,7 @@ $ ssh root@ #### Removing any Other User Docker Service -We recommend using `ros engine rm` to remove any Other User Docker service. +We recommend using `ros engine rm` to remove any Other User Docker service. ``` $ ros engine rm otheruserdockername diff --git a/content/os/v1.x/en/installation/networking/interfaces/_index.md b/content/os/v1.x/en/installation/networking/interfaces/_index.md index f33ac9f7de9..f93384e4e53 100644 --- a/content/os/v1.x/en/installation/networking/interfaces/_index.md +++ b/content/os/v1.x/en/installation/networking/interfaces/_index.md @@ -232,7 +232,7 @@ rancher: scan_ssid: 1 ``` -When adding in WiFi access, you do not need a system reboot, you only need to restart the `network` service in System Docker. +When adding in WiFi access, you do not need a system reboot, you only need to restart the `network` service in System Docker. ``` $ sudo system-docker restart network @@ -244,13 +244,13 @@ $ sudo system-docker restart network _Available as of v1.5_ -In order to support 4G-LTE, 4G-LTE module will need to be connected to the motherboard and to get a good signal, an external atenna will need to be added. You can assemble such a device, which supports USB interface and SIM cards slot: +In order to support 4G-LTE, 4G-LTE module will need to be connected to the motherboard and to get a good signal, an external antenna will need to be added. You can assemble such a device, which supports USB interface and SIM cards slot: ![](https://ws1.sinaimg.cn/bmiddle/006tNc79ly1fzcuvhu6zpj30k80qwag1.jpg) -In order to use RancherOS, you will need to use the ISO built for 4G-LTE support. This ISO has a built-in `modem-manager` service and is available with each release. +In order to use RancherOS, you will need to use the ISO built for 4G-LTE support. This ISO has a built-in `modem-manager` service and is available with each release. -After booting the ISO, there will be a 4G NIC, such as `wwan0`. Use the following `cloud-config` to set the APN parameter. +After booting the ISO, there will be a 4G NIC, such as `wwan0`. Use the following `cloud-config` to set the APN parameter. ```yaml rancher: @@ -266,4 +266,4 @@ After any configuration changes, restart the `modem-manager` service to apply th $ sudo system-docker restart modem-manager ``` -> **Note:** Currently, RancherOS has some built-in rules in `udev` rules to allow RancherOS to recognize specific 4G devices, but there are additional vendors that may be missing. If you need to add these in, please file an issue. +> **Note:** Currently, RancherOS has some built-in rules in `udev` rules to allow RancherOS to recognize specific 4G devices, but there are additional vendors that may be missing. If you need to add these in, please file an issue. diff --git a/content/os/v1.x/en/installation/running-rancheros/cloud/do/_index.md b/content/os/v1.x/en/installation/running-rancheros/cloud/do/_index.md index 9390b0092f4..d644822ded6 100644 --- a/content/os/v1.x/en/installation/running-rancheros/cloud/do/_index.md +++ b/content/os/v1.x/en/installation/running-rancheros/cloud/do/_index.md @@ -3,7 +3,7 @@ title: Digital Ocean weight: 107 --- -RancherOS is avaliable in the Digital Ocean portal. RancherOS is a member of container distributions and you can find it easily. +RancherOS is available in the Digital Ocean portal. RancherOS is a member of container distributions and you can find it easily. >**Note** >Deploying to Digital Ocean will incur charges. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md index fbe444f333c..f74e1e8b0ce 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md @@ -5,19 +5,19 @@ aliases: - /rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/ --- -If your organization uses Microsoft Active Directory as central user repository, you can configure Rancher to communicate with an Active Directory server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the Active Directory, while allowing end-users to authenticate with their AD credentials when logging in to the Rancher UI. +If your organization uses Microsoft Active Directory as central user repository, you can configure Rancher to communicate with an Active Directory server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the Active Directory, while allowing end-users to authenticate with their AD credentials when logging in to the Rancher UI. Rancher uses LDAP to communicate with the Active Directory server. The authentication flow for Active Directory is therefore the same as for the [OpenLDAP authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/openldap) integration. > **Note:** -> +> > Before you start, please familiarise yourself with the concepts of [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). ## Prerequisites You'll need to create or obtain from your AD administrator a new AD user to use as service account for Rancher. This user must have sufficient permissions to perform LDAP searches and read attributes of users and groups under your AD domain. -Usually a (non-admin) **Domain User** account should be used for this purpose, as by default such user has read-only privileges for most objects in the domain partition. +Usually a (non-admin) **Domain User** account should be used for this purpose, as by default such user has read-only privileges for most objects in the domain partition. Note however, that in some locked-down Active Directory configurations this default behaviour may not apply. In such case you will need to ensure that the service account user has at least **Read** and **List Content** permissions granted either on the Base OU (enclosing users and groups) or globally for the domain. @@ -126,7 +126,7 @@ Once you have completed the configuration, proceed by testing the connection to ## Annex: Identify Search Base and Schema using ldapsearch -In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hirarchy and schema of your AD server. +In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hierarchy and schema of your AD server. The [`ldapsearch`](http://manpages.ubuntu.com/manpages/artful/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects. @@ -165,7 +165,7 @@ The output of the above `ldapsearch` query also allows to determine the correct > **Note:** > -> If the AD users in our organisation were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead. +> If the AD users in our organisation were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead. We'll also set the `Search Attribute` parameter to **sAMAccountName|name**. That way users can be added to clusters/projects in the Rancher UI either by entering their username or full name. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/google/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/google/_index.md index f29f6520b21..5266e219d7e 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/google/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/google/_index.md @@ -15,7 +15,7 @@ Within Rancher, only administrators or users with the **Manage Authentication** - You must have the Admin SDK API enabled for your G Suite domain. You can enable it using the steps on [this page.](https://support.google.com/a/answer/60757?hl=en) After the Admin SDK API is enabled, your G Suite domain's API screen should look like this: -![Enable Admin APIs]({{}}/img/rancher/Google-Enable-APIs-Screen.png) +![Enable Admin APIs]({{}}/img/rancher/Google-Enable-APIs-Screen.png) # Setting up G Suite for OAuth with Rancher Before you can set up Google OAuth in Rancher, you need to log in to your G Suite account and do the following: @@ -27,8 +27,8 @@ Before you can set up Google OAuth in Rancher, you need to log in to your G Suit ### 1. Adding Rancher as an Authorized Domain 1. Click [here](https://console.developers.google.com/apis/credentials) to go to credentials page of your Google domain. -1. Select your project and click **OAuth consent screen.** -![OAuth Consent Screen]({{}}/img/rancher/Google-OAuth-consent-screen-tab.png) +1. Select your project and click **OAuth consent screen.** +![OAuth Consent Screen]({{}}/img/rancher/Google-OAuth-consent-screen-tab.png) 1. Go to **Authorized Domains** and enter the top private domain of your Rancher server URL in the list. The top private domain is the rightmost superdomain. So for example, www.foo.co.uk a top private domain of foo.co.uk. For more information on top-level domains, refer to [this article.](https://github.com/google/guava/wiki/InternetDomainNameExplained#public-suffixes-and-private-domains) 1. Go to **Scopes for Google APIs** and make sure **email,** **profile** and **openid** are enabled. @@ -36,14 +36,14 @@ Before you can set up Google OAuth in Rancher, you need to log in to your G Suit ### 2. Creating OAuth2 Credentials for the Rancher Server 1. Go to the Google API console, select your project, and go to the [credentials page.](https://console.developers.google.com/apis/credentials) -![Credentials]({{}}/img/rancher/Google-Credentials-tab.png) -1. On the **Create Credentials** dropdown, select **OAuth client ID.** +![Credentials]({{}}/img/rancher/Google-Credentials-tab.png) +1. On the **Create Credentials** dropdown, select **OAuth client ID.** 1. Click **Web application.** -1. Provide a name. -1. Fill out the **Authorized JavaScript origins** and **Authorized redirect URIs.** Note: The Rancher UI page for setting up Google OAuth (available from the Global view under **Security > Authentication > Google**) provides you the exact links to enter for this step. - - Under **Authorized JavaScript origins,** enter your Rancher server URL. - - Under **Authorized redirect URIs,** enter your Rancher server URL appended with the path `verify-auth`. For example, if your URI is `https://rancherServer`, you will enter `https://rancherServer/verify-auth`. -1. Click on **Create.** +1. Provide a name. +1. Fill out the **Authorized JavaScript origins** and **Authorized redirect URIs.** Note: The Rancher UI page for setting up Google OAuth (available from the Global view under **Security > Authentication > Google**) provides you the exact links to enter for this step. + - Under **Authorized JavaScript origins,** enter your Rancher server URL. + - Under **Authorized redirect URIs,** enter your Rancher server URL appended with the path `verify-auth`. For example, if your URI is `https://rancherServer`, you will enter `https://rancherServer/verify-auth`. +1. Click on **Create.** 1. After the credential is created, you will see a screen with a list of your credentials. Choose the credential you just created, and in that row on rightmost side, click **Download JSON.** Save the file so that you can provide these credentials to Rancher. **Result:** Your OAuth credentials have been successfully created. @@ -58,16 +58,16 @@ As a workaround to get this capability, G Suite recommends creating a service ac This section describes how to: - Create a service account -- Create a key for the service account and download the credenials as JSON +- Create a key for the service account and download the credentials as JSON 1. Click [here](https://console.developers.google.com/iam-admin/serviceaccounts) and select your project for which you generated OAuth credentials. -1. Click on **Create Service Account.** -1. Enter a name and click **Create.** -![Service account creation Step 1]({{}}/img/rancher/Google-svc-acc-step1.png) -1. Don't provide any roles on the **Service account permissions** page and click **Continue** -![Service account creation Step 2]({{}}/img/rancher/Google-svc-acc-step2.png) +1. Click on **Create Service Account.** +1. Enter a name and click **Create.** +![Service account creation Step 1]({{}}/img/rancher/Google-svc-acc-step1.png) +1. Don't provide any roles on the **Service account permissions** page and click **Continue** +![Service account creation Step 2]({{}}/img/rancher/Google-svc-acc-step2.png) 1. Click on **Create Key** and select the JSON option. Download the JSON file and save it so that you can provide it as the service account credentials to Rancher. -![Service account creation Step 3]({{}}/img/rancher/Google-svc-acc-step3-key-creation.png) +![Service account creation Step 3]({{}}/img/rancher/Google-svc-acc-step3-key-creation.png) **Result:** Your service account is created. @@ -79,13 +79,13 @@ Using the Unique ID of the service account key, register it as an Oauth Client u 1. Get the Unique ID of the key you just created. If it's not displayed in the list of keys right next to the one you created, you will have to enable it. To enable it, click **Unique ID** and click **OK.** This will add a **Unique ID** column to the list of service account keys. Save the one listed for the service account you created. NOTE: This is a numeric key, not to be confused with the alphanumeric field **Key ID.** - ![Service account Unique ID]({{}}/img/rancher/Google-Select-UniqueID-column.png) -1. Go to the [**Manage OAuth Client Access** page.](https://admin.google.com/AdminHome?chromeless=1#OGX:ManageOauthClients) + ![Service account Unique ID]({{}}/img/rancher/Google-Select-UniqueID-column.png) +1. Go to the [**Manage OAuth Client Access** page.](https://admin.google.com/AdminHome?chromeless=1#OGX:ManageOauthClients) 1. Add the Unique ID obtained in the previous step in the **Client Name** field. -1. In the **One or More API Scopes** field, add the following scopes: +1. In the **One or More API Scopes** field, add the following scopes: ``` openid,profile,email,https://www.googleapis.com/auth/admin.directory.user.readonly,https://www.googleapis.com/auth/admin.directory.group.readonly - ``` + ``` 1. Click **Authorize.** **Result:** The service account is registered as an OAuth client in your G Suite account. @@ -101,6 +101,6 @@ Using the Unique ID of the service account key, register it as an Oauth Client u - For **Step Two,** provide the OAuth credentials JSON that you downloaded after completing [this section.](#2-creating-oauth2-credentials-for-the-rancher-server) You can upload the file or paste the contents into the **OAuth Credentials** field. - For **Step Three,** provide the service account credentials JSON that downloaded at the end of [this section.](#3-creating-service-account-credentials) The credentials will only work if you successfully [registered the service account key](#4-register-the-service-account-key-as-an-oauth-client) as an OAuth client in your G Suite account. 1. Click **Authenticate with Google**. -1. Click **Save**. +1. Click **Save**. **Result:** Google authentication is successfully configured. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md index 9da68a94c75..e7350e6c96d 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md @@ -1,6 +1,6 @@ --- title: Configuring Keycloak (SAML) -description: Create a Keycloack SAML client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins +description: Create a Keycloak SAML client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins weight: 1200 --- _Available as of v2.1.0_ @@ -12,7 +12,7 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati - You must have a [Keycloak IdP Server](https://www.keycloak.org/docs/latest/server_installation/) configured. - In Keycloak, create a [new SAML client](https://www.keycloak.org/docs/latest/server_admin/#saml-clients), with the settings below. See the [Keycloak documentation](https://www.keycloak.org/docs/latest/server_admin/#saml-clients) for help. - Setting | Value + Setting | Value ------------|------------ `Sign Documents` | `ON` 1 `Sign Assertions` | `ON` 1 @@ -23,7 +23,7 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati `Valid Redirect URI` | `https://yourRancherHostURL/v1-saml/keycloak/saml/acs` >1: Optionally, you can enable either one or both of these settings. -- Export a `metadata.xml` file from your Keycloak client: +- Export a `metadata.xml` file from your Keycloak client: From the `Installation` tab, choose the `SAML Metadata IDPSSODescriptor` format option and download your file. @@ -48,7 +48,7 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati | 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 @@ -64,7 +64,7 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati ## Annex: Troubleshooting -If you are experiencing issues while testing the connection to the Keycloak server, first double-check the confiuration option of your SAML client. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation. +If you are experiencing issues while testing the connection to the Keycloak server, first double-check the configuration option of your SAML client. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation. ### You are not redirected to Keycloak @@ -90,10 +90,10 @@ You are correctly redirected to your IdP login page and you are able to enter yo * Check your Keycloak log. * If the log displays `request validation failed: org.keycloak.common.VerificationException: SigAlg was null`, set `Client Signature Required` to `OFF` in your Keycloak client. - + ### Keycloak 6.0.0+: IDPSSODescriptor missing from options -Keycloak versions 6.0.0 and up no longer provide the IDP metadata under the `Installation` tab. +Keycloak versions 6.0.0 and up no longer provide the IDP metadata under the `Installation` tab. You can still get the XML from the following url: `https://{KEYCLOAK-URL}/auth/realms/{REALM-NAME}/protocol/saml/descriptor` @@ -112,4 +112,3 @@ You are left with something similar as the example below: ``` - diff --git a/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md index cc6a3b75791..8cb2508c681 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md @@ -9,9 +9,9 @@ If your organization uses Ping Identity Provider (IdP) for user authentication, >**Prerequisites:** > >- You must have a [Ping IdP Server](https://www.pingidentity.com/) configured. ->- Following are the Rancher Service Provider URLs needed for configuration: -Metadata URL: `https:///v1-saml/ping/saml/metadata` -Assertion Consure Service (ACS) URL: `https:///v1-saml/ping/saml/acs` +>- Following are the Rancher Service Provider URLs needed for configuration: +Metadata URL: `https:///v1-saml/ping/saml/metadata` +Assertion Consumer Service (ACS) URL: `https:///v1-saml/ping/saml/acs` >- Export a `metadata.xml` file from your IdP Server. For more information, see the [PingIdentity documentation](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html). 1. From the **Global** view, select **Security > Authentication** from the main menu. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/user-groups/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/user-groups/_index.md index b4261c097cf..722452e5f63 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/user-groups/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/user-groups/_index.md @@ -29,7 +29,7 @@ Rancher will periodically refresh the user information even before a user logs i - **`auth-user-info-max-age-seconds`** - This setting controls how old a user's information can be before Rancher refreshes it. If a user makes an API call (either directly or by using the Rancher CLI or kubectl) and the time since the user's last refresh is greater than this setting, then Rancher will trigger a refresh. This settting defaults to `3600` seconds, i.e. 1 hour. + This setting controls how old a user's information can be before Rancher refreshes it. If a user makes an API call (either directly or by using the Rancher CLI or kubectl) and the time since the user's last refresh is greater than this setting, then Rancher will trigger a refresh. This setting defaults to `3600` seconds, i.e. 1 hour. - **`auth-user-info-resync-cron`** diff --git a/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md index 92292af2ab0..bd7867b8f55 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md @@ -89,7 +89,7 @@ _Project roles_ are roles that can be used to grant users access to a project. T 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. @@ -126,7 +126,7 @@ The following table lists each built-in custom project role available in Rancher > **Notes:** > >- Each project role listed above, including `Owner`, `Member`, and `Read Only`, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page. ->- When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. +>- 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 @@ -161,12 +161,12 @@ You can change the cluster or project role(s) that are automatically assigned to 1. Enable the role as default. {{% accordion id="cluster" label="For Clusters" %}} -1. From **Clustor Creator Default**, choose **Yes: Default role for new cluster creation**. +1. From **Cluster Creator Default**, choose **Yes: Default role for new cluster creation**. 1. Click **Save**. {{% /accordion %}} {{% accordion id="project" label="For Projects" %}} 1. From **Project Creator Default**, choose **Yes: Default role for new project creation**. -1. Click **Save**. +1. Click **Save**. {{% /accordion %}} 1. If you want to remove a default role, edit the permission and select **No** from the default roles option. @@ -181,4 +181,3 @@ When you revoke the cluster membership for a standard user that's explicitly ass - Exercise any [individual project roles](#project-role-reference) they are assigned. If you want to completely revoke a user's access within a cluster, revoke both their cluster and project memberships. - diff --git a/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md index 8bfc1edf915..f17db7645a7 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md @@ -150,9 +150,9 @@ 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 global 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]({{}}/rancher/v2.x/en/admin-settings/authentication/#external-vs-local-authentication) -> * The external authentication provider suppports [user groups]({{}}/rancher/v2.x/en/admin-settings/authentication/user-groups/) +> * The external authentication provider supports [user groups]({{}}/rancher/v2.x/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: diff --git a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md index f66580a89f4..c181c5dee43 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md @@ -141,9 +141,9 @@ 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]({{}}/rancher/v2.x/en/admin-settings/authentication/#external-vs-local-authentication) -> * The external authentication provider suppports [user groups]({{}}/rancher/v2.x/en/admin-settings/authentication/user-groups/) +> * The external authentication provider supports [user groups]({{}}/rancher/v2.x/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: diff --git a/content/rancher/v2.x/en/admin-settings/rke-templates/_index.md b/content/rancher/v2.x/en/admin-settings/rke-templates/_index.md index 34ac570d8e1..3c0d8cbcdc5 100644 --- a/content/rancher/v2.x/en/admin-settings/rke-templates/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rke-templates/_index.md @@ -47,7 +47,7 @@ The [add-on section](#add-ons) of an RKE template is especially powerful because # Scope of RKE Templates RKE templates are supported for Rancher-provisioned clusters. The templates can be used to provision custom clusters or clusters that are launched by an infrastructure provider. - + RKE templates are for defining Kubernetes and Rancher settings. Node templates are responsible for configuring nodes. For tips on how to use RKE templates in conjunction with hardware, refer to [RKE Templates and Hardware]({{}}/rancher/v2.x/en/admin-settings/rke-templates/rke-templates-and-hardware). RKE templates can be created from scratch to pre-define cluster configuration. They can be applied to launch new clusters, or templates can also be exported from existing running clusters. @@ -102,7 +102,7 @@ As of Rancher v2.3.3, you can [save the configuration of an existing cluster as # Standardizing Hardware -RKE templates are designed to standardize Kubernetes and Rancher settings. If you want to standardize your infrastructure as well, you use RKE templates [in conjuction with other tools]({{}}/rancher/v2.x/en/admin-settings/rke-templates/rke-templates-and-hardware). +RKE templates are designed to standardize Kubernetes and Rancher settings. If you want to standardize your infrastructure as well, you use RKE templates [in conjunction with other tools]({{}}/rancher/v2.x/en/admin-settings/rke-templates/rke-templates-and-hardware). # YAML Customization diff --git a/content/rancher/v2.x/en/admin-settings/rke-templates/example-scenarios/_index.md b/content/rancher/v2.x/en/admin-settings/rke-templates/example-scenarios/_index.md index cbc398d7424..4e93e102c62 100644 --- a/content/rancher/v2.x/en/admin-settings/rke-templates/example-scenarios/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rke-templates/example-scenarios/_index.md @@ -15,11 +15,11 @@ These example scenarios describe how an organization could use templates to stan Let's say there is an organization in which the administrators decide that all new clusters should be created with Kubernetes version 1.14. -1. First, an administrator creates a template which specifies the Kubernetes version as 1.14 and marks all other settings as **Allow User Override**. +1. First, an administrator creates a template which specifies the Kubernetes version as 1.14 and marks all other settings as **Allow User Override**. 1. The administrator makes the template public. 1. The administrator turns on template enforcement. -**Results:** +**Results:** - All Rancher users in the organization have access to the template. - All new clusters created by [standard users]({{}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) with this template will use Kubernetes 1.14 and they are unable to use a different Kubernetes version. By default, standard users don't have permission to create templates, so this template will be the only template they can use unless more templates are shared with them. @@ -29,10 +29,10 @@ In this way, the administrators enforce the Kubernetes version across the organi # Templates for Basic and Advanced Users -Let's say an organization has both basic and advanced users. Adminstrators want the basic users to be required to use a template, while the advanced users and administrators create their clusters however they want. +Let's say an organization has both basic and advanced users. Administrators want the basic users to be required to use a template, while the advanced users and administrators create their clusters however they want. 1. First, an administrator turns on [RKE template enforcement.]({{}}/rancher/v2.x/en/admin-settings/rke-templates/enforcement/#requiring-new-clusters-to-use-a-cluster-template) This means that every [standard user]({{}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) in Rancher will need to use an RKE template when they create a cluster. -1. The administrator then creates two templates: +1. The administrator then creates two templates: - One template for basic users, with almost every option specified except for access keys - One template for advanced users, which has most or all options has **Allow User Override** turned on @@ -44,7 +44,7 @@ Let's say an organization has both basic and advanced users. Adminstrators want # Updating Templates and Clusters Created with Them -Let's say an organization has a template that requires clusters to use Kubernetes v1.14. However, as time goes on, the adminstrators change their minds. They decide they want users to be able to upgrade their clusters to use newer versions of Kubernetes. +Let's say an organization has a template that requires clusters to use Kubernetes v1.14. However, as time goes on, the administrators change their minds. They decide they want users to be able to upgrade their clusters to use newer versions of Kubernetes. In this organization, many clusters were created with a template that requires Kubernetes v1.14. Because the template does not allow that setting to be overridden, the users who created the cluster cannot directly edit that setting. diff --git a/content/rancher/v2.x/en/best-practices/management/_index.md b/content/rancher/v2.x/en/best-practices/management/_index.md index 70168c3e2ad..fe7f5f75bf4 100644 --- a/content/rancher/v2.x/en/best-practices/management/_index.md +++ b/content/rancher/v2.x/en/best-practices/management/_index.md @@ -15,7 +15,7 @@ Rancher is container-based and can potentially run on any Linux-based operating ### Upgrade Your Kubernetes Version Keep your Kubernetes cluster up to date with a recent and supported version. Typically the Kubernetes community will support the current version and previous three minor releases (for example, 1.14.x, 1.13.x, 1.12.x, and 1.11.x). After a new version is released, the third-oldest supported version reaches EOL (End of Life) status. Running on an EOL release can be a risk if a security issues are found and patches are not available. The community typically makes minor releases every quarter (every three months). -Rancher’s SLA’s are not community dependent, but as Kubernetes is a community-driven software, the quality of experience will degrade as you get farther away from the community's supported target. +Rancher’s SLAs are not community dependent, but as Kubernetes is a community-driven software, the quality of experience will degrade as you get farther away from the community's supported target. ### Kill Pods Randomly During Testing Run chaoskube or a similar mechanism to randomly kill pods in your test environment. This will test the resiliency of your infrastructure and the ability of Kubernetes to self-heal. It's not recommended to run this in your production environment. @@ -26,7 +26,7 @@ Rancher's "Add Cluster" UI is preferable for getting started with Kubernetes clu Rancher [maintains a Terraform provider](https://rancher.com/blog/2019/rancher-2-terraform-provider/) for working with Rancher 2.0 Kubernetes. It is called the [Rancher2 Provider.](https://www.terraform.io/docs/providers/rancher2/index.html) ### Upgrade Rancher in a Staging Environment -All upgrades, both patch and feature upgrades, should be first tested on a staging environment before production is upgraded. The more closely the staging environment mirrors production, the higher chance your production upgrade will be successful. +All upgrades, both patch and feature upgrades, should be first tested on a staging environment before production is upgraded. The more closely the staging environment mirrors production, the higher chance your production upgrade will be successful. ### Renew Certificates Before they Expire Multiple people in your organization should set up calendar reminders for certificate renewal. Consider renewing the certificate two weeks to one month in advance. If you have multiple certificates to track, consider using [monitoring and alerting mechanisms]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/) to track certificate expiration. @@ -48,7 +48,7 @@ When installing or upgrading a non-production environment to an early release, a Make sure the feature version you are upgrading to is considered "stable" as determined by Rancher. Use the beta, release candidate, and "latest" versions in a testing, development, or demo environment to try out new features. Feature version upgrades, for example 2.1.x to 2.2.x, should be considered as and when they are released. Some bug fixes and most features are not back ported into older versions. -Keep in mind that Rancher does End of Life support for old versions, so you will eventually want to upgrade if you want to continue to receive patches. +Keep in mind that Rancher does End of Life support for old versions, so you will eventually want to upgrade if you want to continue to receive patches. For more detail on what happens during the Rancher product lifecycle, refer to the [Support Maintenance Terms](https://rancher.com/support-maintenance-terms/). @@ -99,7 +99,7 @@ In addition to Rancher software updates, closely monitor security fixes for rela # Tips for Multi-Tenant Clusters ### Namespaces -Each tenant should have their own unique namespaces within the cluster. This avoids naming conflicts and allows resources to be only visible to their owner through use of RBAC policy +Each tenant should have their own unique namespaces within the cluster. This avoids naming conflicts and allows resources to be only visible to their owner through use of RBAC policy ### Project Isolation Use Rancher's Project Isolation to automatically generate Network Policy between Projects (sets of Namespaces). This further protects workloads from interference @@ -108,18 +108,18 @@ Use Rancher's Project Isolation to automatically generate Network Policy between Enforce use of sane resource limit definitions for every deployment in your cluster. This not only protects the owners of the deployment, but the neighboring resources from other tenants as well. Remember, namespaces do not isolate at the node level, so over-consumption of resources on a node affects other namespace deployments. Admission controllers can be written to require resource limit definitions ### Resource Requirements -Enforce use of resource requirement definitions for each deployment in your cluster. This enables the scheduler to appropriately schedule workloads. Otherwise you will eventually end up with over-provisioned nodes. +Enforce use of resource requirement definitions for each deployment in your cluster. This enables the scheduler to appropriately schedule workloads. Otherwise you will eventually end up with over-provisioned nodes. # Class of Service and Kubernetes Clusters A class of service describes the expectations around cluster uptime, durability, and duration of maintenance windows. Typically organizations group these characteristics into labels such as "dev" or "prod" ### Consider fault domains -Kubernetes clusters can span multiple classes of service, however it is important to consider the ability for one workload to affect another. Without proper deployment practices such as resource limits, requirements, etc, a deployment that is not behaving well has the potential to impact the health of the cluster. In a "dev" environment it is common for end-users to exercise less caution with deployments, thus increasing the chance of such behavior. Sharing this behavior with your production workload increases risk. +Kubernetes clusters can span multiple classes of service, however it is important to consider the ability for one workload to affect another. Without proper deployment practices such as resource limits, requirements, etc, a deployment that is not behaving well has the potential to impact the health of the cluster. In a "dev" environment it is common for end-users to exercise less caution with deployments, thus increasing the chance of such behavior. Sharing this behavior with your production workload increases risk. ### Upgrade risks -Upgrades of Kuberentes are not without risk, the best way to predict the outcome of an upgrade is try it on a cluster of similar load and use case as your production cluster. This is where having non-prod class of service clusters can be advantageous. +Upgrades of Kubernetes are not without risk, the best way to predict the outcome of an upgrade is try it on a cluster of similar load and use case as your production cluster. This is where having non-prod class of service clusters can be advantageous. -### Resource Efficiency +### Resource Efficiency Clusters can be built with varying degrees of redundancy. In a class of service with low expectations for uptime, resources and cost can be conserved by building clusters without redundant Kubernetes control components. This approach may also free up more budget/resources to increase the redundancy at the production level # Network Security diff --git a/content/rancher/v2.x/en/catalog/globaldns/_index.md b/content/rancher/v2.x/en/catalog/globaldns/_index.md index 21a7b84a57d..783a1dcf843 100644 --- a/content/rancher/v2.x/en/catalog/globaldns/_index.md +++ b/content/rancher/v2.x/en/catalog/globaldns/_index.md @@ -35,7 +35,7 @@ By default, only [global administrators]({{< baseurl >}}/rancher/v2.x/en/admin-s 1. From the **Global View**, select **Tools > Global DNS Providers**. 1. To add a provider, choose from the available provider options and configure the Global DNS Provider with necessary credentials and an optional domain. -1. (Optional) Add additional users so they could use the provider when creating Globel DNS entries as well as manage the Global DNS provider. +1. (Optional) Add additional users so they could use the provider when creating Global DNS entries as well as manage the Global DNS provider. {{% accordion id="route53" label="Route53" %}} 1. Enter a **Name** for the provider. @@ -81,7 +81,7 @@ By default, only [global administrators]({{< baseurl >}}/rancher/v2.x/en/admin-s In order for Global DNS entries to be programmed, you will need to add a specific annotation on an ingress in your application or target project and this ingress needs to use a specific `hostname` and an annotation that should match the FQDN of the Global DNS entry. -1. For any application that you want targetted for your Global DNS entry, find an ingress associated with the application. +1. For any application that you want targeted for your Global DNS entry, find an ingress associated with the application. 1. In order for the DNS to be programmed, the following requirements must be met: * The ingress routing rule must be set to use a `hostname` that matches the FQDN of the Global DNS entry. * The ingress must have an annotation (`rancher.io/globalDNS.hostname`) and the value of this annotation should match the FQDN of the Global DNS entry. diff --git a/content/rancher/v2.x/en/catalog/multi-cluster-apps/_index.md b/content/rancher/v2.x/en/catalog/multi-cluster-apps/_index.md index 62936ccb55a..f40b0e593c7 100644 --- a/content/rancher/v2.x/en/catalog/multi-cluster-apps/_index.md +++ b/content/rancher/v2.x/en/catalog/multi-cluster-apps/_index.md @@ -18,7 +18,7 @@ After creating a multi-cluster application, you can program a [Global DNS entry] 3. (Optional) Review the detailed descriptions, which are derived from the Helm chart's `README`. -4. Under **Configuration Options** enter a **Name** for the multi-cluster application. By default, this name is also used to create a Kubernetes namespace in each [target project](#targets) for the multi-cluster application. The namespace is named as `-`. +4. Under **Configuration Options** enter a **Name** for the multi-cluster application. By default, this name is also used to create a Kubernetes namespace in each [target project](#targets) for the multi-cluster application. The namespace is named as `-`. 5. Select a **Template Version**. @@ -50,13 +50,13 @@ In the **Upgrades** section, select the upgrade strategy to use, when you decide #### Roles -In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/#launching-catalog-applications), that specific users's permissions are used for creation of all workloads/resources that is required by the app. +In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/#launching-catalog-applications), that specific user's permissions are used for creation of all workloads/resources that is required by the app. For multi-cluster applications, the application is deployed by a _system user_ and is assigned as the creator of all underlying resources. A _system user_ is used instead of the actual user due to the fact that the actual user could be removed from one of the target projects. If the actual user was removed from one of the projects, then that user would no longer be able to manage the application for the other projects. Rancher will let you select from two options for Roles, **Project** and **Cluster**. Rancher will allow creation using any of these roles based on the user's permissions. -- **Project** - This is the equivalent of a [project member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [project member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) role. While the user might not be explicitly granted the _project member_ role, if the user is an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), a [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or a [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles), then the user is considered to have the appropriate level of permissions. +- **Project** - This is the equivalent of a [project member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [project member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) role. While the user might not be explicitly granted the _project member_ role, if the user is an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), a [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or a [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles), then the user is considered to have the appropriate level of permissions. - **Cluster** - This is the equivalent of a [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) role. While the user might not be explicitly granted the _cluster owner_ role, if the user is an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), then the user is considered to have the appropriate level of permissions. @@ -68,7 +68,7 @@ When launching the application, Rancher will confirm if you have these permissio For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://github.com/helm/helm/blob/master/docs/using_helm.md#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm. -> For example, when entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is reuired to wrap the values with double quotes (i.e., ``"abc, bcd"``). +> 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"``). #### Using a `questions.yml` file @@ -84,7 +84,7 @@ By default, multi-cluster applications can only be managed by the user who creat 1. Find the user that you want to add by typing in the member's name in the **Member** search box. -2. Select the **Access Type** for that member. There are three access types for a multi-cluster project, but due to how the permissions of a multi-cluster application are launched, please read carefully to understand what these access types mean. +2. Select the **Access Type** for that member. There are three access types for a multi-cluster project, but due to how the permissions of a multi-cluster application are launched, please read carefully to understand what these access types mean. - **Owner**: This access type can manage any configuration part of the multi-cluster application including the template version, the [multi-cluster applications specific configuration options](#configuration-options-to-make-a-multi-cluster-app), the [application specific configuration options](#application-configuration-options), the [members who can interact with the multi-cluster application](#members) and the [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects). Since a multi-cluster application is created with a different set of permissions from the user, any _owner_ of the multi-cluster application can manage/remove applications in [target projects](#targets) without explicitly having access to these project(s). Only trusted users should be provided with this access type. @@ -108,7 +108,7 @@ The ability to use the same configuration to deploy the same application across - **Answer**: Enter the answer that you want to be used instead. -## Upgrading Multi-Cluster App Roles and Projects +## Upgrading Multi-Cluster App Roles and Projects - **Changing Roles on an existing Multi-Cluster app** The creator and any users added with the access-type "owner" to a multi-cluster app, can upgrade its Roles. When adding a new Role, we check if the user has that exact role in all current target projects. These checks allow the same relaxations for global admins, cluster owners and project-owners as described in the installation section for the field `Roles`. @@ -120,7 +120,7 @@ The creator and any users added with the access-type "owner" to a multi-cluster ## Multi-Cluster Application Management -One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of manangement.Multi-cluster applications can be cloned, upgraded or rolled back. +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. 1. From the **Global** view, choose **Apps** in the navigation bar. diff --git a/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md b/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md index 02f7324204d..e4aa716ccbb 100644 --- a/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md @@ -7,7 +7,7 @@ _Available as of v2.2.0_ In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) can be easily performed. Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster. -Rancher recommends configuring recurrent `etcd` snapshots for all production clusters. Additonally, one-time snapshots can easily be taken as well. +Rancher recommends configuring recurrent `etcd` snapshots for all production clusters. Additionally, one-time snapshots can easily be taken as well. >**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Rancher, you must [edit the cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/). @@ -55,7 +55,7 @@ By default, the `local` backup target is selected. The benefits of this option i _Available as of v2.3.0_ -As of v2.2.6, snapshot files are timestamped to simplify processing the files using external tools and scripts, but in some S3 compatible backends, these timestamps were unusable. As of Rancher v2.3.0, the option `safe_timestamp` is added to support compatiable file names. When this flag is set to `true`, all special characters in the snapshot filename timestamp are replaced. +As of v2.2.6, snapshot files are timestamped to simplify processing the files using external tools and scripts, but in some S3 compatible backends, these timestamps were unusable. As of Rancher v2.3.0, the option `safe_timestamp` is added to support compatible file names. When this flag is set to `true`, all special characters in the snapshot filename timestamp are replaced. >>**Note:** This option is not available directly in the UI, and is only available through the `Edit as Yaml` interface. diff --git a/content/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/_index.md b/content/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/_index.md index b8deacf998d..249ec5baa6f 100644 --- a/content/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/_index.md @@ -1,6 +1,6 @@ --- title: "Access a Cluster with Kubectl Shell or Kubectl CLI" -description: "Lean how you can access and manage your Kubernetes clusters using kubectl in two ways: with kubectl Shell or with kubectl CLI and kuberconfig file" +description: "Lean how you can access and manage your Kubernetes clusters using kubectl in two ways: with kubectl Shell or with kubectl CLI and kubeconfig file" weight: 2015 aliases: - /rancher/v2.x/en/tasks/clusters/using-kubectl-to-access-a-cluster/ diff --git a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md index a47f7349041..371303c96c9 100644 --- a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md @@ -20,7 +20,7 @@ In terms of hierarchy: 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. -In the base version of Kubernetes, features like role-based access rights or cluster resources are assigned to individual namespaces. A project allows you to save time by giving an individual or a team acess to multiple namespaces simultaneously. +In the base version of Kubernetes, features like role-based access rights or cluster resources are assigned to individual namespaces. A project allows you to save time by giving an individual or a team access to multiple namespaces simultaneously. You can use projects to perform actions like: diff --git a/content/rancher/v2.x/en/cluster-admin/tools/istio/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/istio/_index.md index 78a59a98735..71313bc816f 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/istio/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/istio/_index.md @@ -30,7 +30,7 @@ Rancher's Istio integration comes with comprehensive visualization aids: - **Trace the root cause of errors with Jaeger.** [Jaeger](https://www.jaegertracing.io/) is an open-source tool that provides a UI for a distributed tracing system, which is useful for root cause analysis and for determining what causes poor performance. Distributed tracing allows you to view an entire chain of calls, which might originate with a user request and traverse dozens of microservices. - **Get the full picture of your microservice architecture with Kiali.** [Kiali](https://www.kiali.io/) provides a diagram that shows the services within a service mesh and how they are connected, including the traffic rates and latencies between them. You can check the health of the service mesh, or drill down to see the incoming and outgoing requests to a single component. - **Gain insights from time series analytics with Grafana dashboards.** [Grafana](https://grafana.com/) is an analytics platform that allows you to query, visualize, alert on and understand the data gathered by Prometheus. -- **Write custom queries for time series data with the Promethus UI.** [Prometheus](https://prometheus.io/) is a systems monitoring and alerting toolkit. Prometheus scrapes data from your cluster, which is then used by Grafana. A Prometheus UI is also integrated into Rancher, and lets you write custom queries for time series data and see the results in the UI. +- **Write custom queries for time series data with the Prometheus UI.** [Prometheus](https://prometheus.io/) is a systems monitoring and alerting toolkit. Prometheus scrapes data from your cluster, which is then used by Grafana. A Prometheus UI is also integrated into Rancher, and lets you write custom queries for time series data and see the results in the UI. # Prerequisites @@ -42,7 +42,7 @@ Refer to the [setup guide]({{}}/rancher/v2.x/en/cluster-admin/tools/ist # Disabling Istio -To remove Istio components from a cluster, namepace, or workload, refer to the section on [disabling Istio.]({{}}/rancher/v2.x/en/cluster-admin/tools/istio/disabling-istio) +To remove Istio components from a cluster, namespace, or workload, refer to the section on [disabling Istio.]({{}}/rancher/v2.x/en/cluster-admin/tools/istio/disabling-istio) # Accessing Visualizations diff --git a/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md index 69d8aabeb78..eb6f3c20fa7 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md @@ -7,7 +7,7 @@ This section describes the permissions required to access Istio features and how # Cluster-level Access -By default, only cluster adminstrators can: +By default, only cluster administrators can: - Enable Istio for the cluster - Configure resource allocations for Istio @@ -33,7 +33,7 @@ By default, the Kiali and Jaeger visualizations are restricted to the cluster o Rancher supports giving groups permission to access Kiali and Jaeger, but not individuals. -To configure who has permission to access the Kiali and Jaeger UI, +To configure who has permission to access the Kiali and Jaeger UI, 1. Go to the cluster view and click **Tools > Istio.** 1. Then go to the **Member Access** section. If you want to restrict access to certain groups, choose **Allow cluster owner and specified members to access Kiali and Jaeger UI.** Search for the groups that you want to have access to Kiali and Jaeger. If you want all members to have access to the tools, click **Allow all members to access Kiali and Jaeger UI.** diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md index e2c8b9f5054..b3d85b3b438 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md @@ -14,7 +14,7 @@ Logging is helpful because it allows you to: - Look for trends in your environment - Save your logs to a safe location outside of your cluster - Stay informed of events like a container crashing, a pod eviction, or a node dying -- More easily debugg and troubleshoot problems +- More easily debug and troubleshoot problems Rancher supports integration with the following services: @@ -100,7 +100,7 @@ As an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global ``` openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com" ``` - 2. If you are using a self-signed certificate, provide the **CA Certificate PEM**. + 2. If you are using a self-signed certificate, provide the **CA Certificate PEM**. 1. (Optional) Complete the **Additional Logging Configuration** form. diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md index 4eb7a29e020..ede960e2578 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md @@ -1,6 +1,6 @@ --- title: Integrating Rancher and Prometheus for Cluster Monitoring -description: Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Lern about the scope of monitoring and how to enable cluster monitoring +description: Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Learn about the scope of monitoring and how to enable cluster monitoring weight: 4 --- @@ -27,7 +27,7 @@ You can configure these services to collect logs at either the cluster level or In other words, Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Using timestamps, Prometheus lets you query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. -By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. +By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster-only and project-only Prometheus instances are also supported. diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/_index.md index 4b52c207fae..a667264c69c 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/_index.md @@ -238,8 +238,8 @@ weight: 4 | Catalog | Expression | | --- | --- | - | Detail |
reading`sum(nginx_ingress_controller_nginx_process_connections{state="reading"}) by (instance)`
waiting`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"}) by (instance)`
writing`sum(nginx_ingress_controller_nginx_process_connections{state="writing"}) by (instance)`
accpeted`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m]))) by (instance)`
active`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m]))) by (instance)`
handled`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m]))) by (instance)`
| - | Summary |
reading`sum(nginx_ingress_controller_nginx_process_connections{state="reading"})`
waiting`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"})`
writing`sum(nginx_ingress_controller_nginx_process_connections{state="writing"})`
accpeted`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m])))`
active`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m])))`
handled`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m])))`
| + | Detail |
reading`sum(nginx_ingress_controller_nginx_process_connections{state="reading"}) by (instance)`
waiting`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"}) by (instance)`
writing`sum(nginx_ingress_controller_nginx_process_connections{state="writing"}) by (instance)`
accepted`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m]))) by (instance)`
active`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m]))) by (instance)`
handled`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m]))) by (instance)`
| + | Summary |
reading`sum(nginx_ingress_controller_nginx_process_connections{state="reading"})`
waiting`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"})`
writing`sum(nginx_ingress_controller_nginx_process_connections{state="writing"})`
accepted`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m])))`
active`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m])))`
handled`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m])))`
| - **Ingress Controller Request Process Time** diff --git a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md index f37822b1eb9..59de651d0e6 100644 --- a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md @@ -1,6 +1,6 @@ --- title: "Kubernetes Persistent Storage: Volumes and Storage Classes" -description: "Learn about the two ways with which you can creat persistent storage in Kubernetes: persistent volumes and storage classes" +description: "Learn about the two ways with which you can create persistent storage in Kubernetes: persistent volumes and storage classes" weight: 2031 aliases: - /rancher/v2.x/en/concepts/volumes-and-storage/ diff --git a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md index 4f811564629..54a0fdf1d8b 100644 --- a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md @@ -42,7 +42,7 @@ In order to provision vSphere volumes in a cluster created with the [Rancher Kub 7. Assign a path in the **Mount Point** field. This is the full path where the volume will be mounted in the container file system, e.g. `/persistent`. 8. Click **Launch** to create the workload. -### Verifing Persistence of the Volume +### Verifying Persistence of the Volume 1. From the context menu of the workload you just created, click **Execute Shell**. 2. Note the directory at root where the volume has been mounted to (in this case `/persistent`). @@ -50,7 +50,7 @@ In order to provision vSphere volumes in a cluster created with the [Rancher Kub 4. **Close** the shell window. 5. Click on the name of the workload to reveal detail information. 6. Open the context menu next to the Pod in the *Running* state. -7. Delete the Pod by selecting **Delete**. +7. Delete the Pod by selecting **Delete**. 8. Observe that the pod is deleted. Then a new pod is scheduled to replace it so that the workload maintains its configured scale of a single stateful pod. 9. Once the replacement pod is running, click **Execute Shell**. 10. Inspect the contents of the directory where the volume is mounted by entering `ls -l /`. Note that the file you created earlier is still present. diff --git a/content/rancher/v2.x/en/cluster-provisioning/node-requirements/_index.md b/content/rancher/v2.x/en/cluster-provisioning/node-requirements/_index.md index 05099d44c3d..4b9ddbd3c50 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/node-requirements/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/node-requirements/_index.md @@ -23,9 +23,9 @@ Rancher works has been tested and is supported with downstream clusters running All supported operating systems are 64-bit x86. -If you plan to use ARM64, see [Running on ARM64 (Experimental).]({{}}/rancher/v2.x/en/installation/options/arm64-platform/) +If you plan to use ARM64, see [Running on ARM64 (Experimental).]({{}}/rancher/v2.x/en/installation/options/arm64-platform/) -For information on how to install Docker, refer to the offical [Docker documentation.](https://docs.docker.com/) +For information on how to install Docker, refer to the official [Docker documentation.](https://docs.docker.com/) > **Note:** Some distributions of Linux derived from RHEL, including Oracle Linux, may have default firewall rules that block communication with Helm. This [how-to guide]({{}}/rancher/v2.x/en/installation/options/firewall) shows how to check the default firewall rules and how to open the ports with `firewalld` if necessary. @@ -41,7 +41,7 @@ Windows nodes can be used for worker nodes only. See [Configuring Custom Cluster The hardware requirements for nodes with the `worker` role mostly depend on your workloads. The minimum to run the Kubernetes node components is 1 CPU (core) and 1GB of memory. -Regarding CPU and memory, it is recommended that the different planes of Kubernetes clusters (etcd, controplane, and workers) should be hosted on different nodes so that they can scale separately from each other. +Regarding CPU and memory, it is recommended that the different planes of Kubernetes clusters (etcd, controlplane, and workers) should be hosted on different nodes so that they can scale separately from each other. For hardware recommendations for large Kubernetes clusters, refer to the official Kubernetes documentation on [building large clusters.](https://kubernetes.io/docs/setup/best-practices/cluster-large/) @@ -106,7 +106,7 @@ The following table depicts the port requirements for [Rancher Launched Kubernet ### Port Requirements for Clusters Hosted by an Infrastructure Provider -If you are launching a Kubernetes cluster on nodes that are in an infastructure provider such as Amazon EC2, Google Container Engine, DigitalOcean, Azure, or vSphere, these port requirements apply. +If you are launching a Kubernetes cluster on nodes that are in an infrastructure provider such as Amazon EC2, Google Container Engine, DigitalOcean, Azure, or vSphere, these port requirements apply. These required ports are automatically opened by Rancher during creation of clusters using cloud providers. diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md index 1f32b1e6bd9..c702095a959 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md @@ -14,7 +14,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2. - IAM Policy created to add to the user of the Access Key And Secret Key. See [Amazon Documentation: Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) how to create an IAM policy. See our three example JSON policies below: - [Example IAM Policy](#example-iam-policy) - [Example IAM Policy with PassRole](#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers) or want to pass an IAM Profile to an instance) - - [Example IAM Policy to allow encrypted EBS volumes](#example-iam-policy-to-allow-encrypted-ebs-volumes) + - [Example IAM Policy to allow encrypted EBS volumes](#example-iam-policy-to-allow-encrypted-ebs-volumes) - IAM Policy added as Permission to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to an user. @@ -36,7 +36,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2. 1. Complete each of the following forms using information available from the [EC2 Management Console](https://aws.amazon.com/ec2). - - **Account Access** is where you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine. See [Prerequisistes](#prerequisites) how to create the Access Key and Secret Key and the needed permissions. + - **Account Access** is where you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine. See [Prerequisites](#prerequisites) how to create the Access Key and Secret Key and the needed permissions. {{< step_create-cloud-credential >}} diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md index 89629d989da..cbe4677d4d3 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md @@ -1,7 +1,7 @@ --- title: Cluster Options weight: 2250 ---- +--- As you configure a new cluster that's provisioned using [RKE]({{< baseurl >}}/rke/latest/en/), you can choose custom Kubernetes options. @@ -60,7 +60,7 @@ _Available as of v2.2.0_ The registry configuration here is applied during the provisioning of the cluster. This option tells Rancher where to pull the [system images]({{}}/rke/latest/en/config-options/system-images/) or [addon images.]({{}}/rke/latest/en/config-options/add-ons/) -- **System images** are components needed to maintain the Kubernetes cluster. +- **System images** are components needed to maintain the Kubernetes cluster. - **Add-ons** are used to deploy several cluster components, including network plug-ins, the ingress controller, the DNS provider, or the metrics server. To deploy workloads that pull images from a private registry, you will need to set up your own Kubernetes registry for your project. @@ -109,7 +109,7 @@ If the nodes you are adding to the cluster have Docker configured with a non-def #### Recurring etcd Snapshots -Option to enable or disable [recurring etcd snaphots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots). +Option to enable or disable [recurring etcd snapshots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots). ## Config File @@ -131,63 +131,63 @@ RKE (Rancher Kubernetes Engine) is the tool that Rancher uses to provision Kuber {{% accordion id="v2.3.0-cluster-config-file" label="Example Cluster Config File for Rancher v2.3.0+" %}} ```yaml -# +# # Cluster Config -# +# docker_root_dir: /var/lib/docker enable_cluster_alerting: false enable_cluster_monitoring: false enable_network_policy: false local_cluster_auth_endpoint: enabled: true -# +# # Rancher Config -# +# rancher_kubernetes_engine_config: # Your RKE template config goes here. addon_job_timeout: 30 authentication: strategy: x509 ignore_docker_version: true -# +# # # Currently only nginx ingress provider is supported. # # To disable ingress controller, set `provider: none` # # To enable ingress on specific nodes, use the node_selector, eg: # provider: nginx # node_selector: # app: ingress -# +# ingress: provider: nginx kubernetes_version: v1.15.3-rancher3-1 monitoring: provider: metrics-server -# +# # If you are using calico on AWS -# +# # network: # plugin: calico # calico_network_provider: # cloud_provider: aws -# +# # # To specify flannel interface -# +# # network: # plugin: flannel # flannel_network_provider: # iface: eth1 -# +# # # To specify flannel interface for canal plugin -# +# # network: # plugin: canal # canal_network_provider: # iface: eth1 -# +# network: options: flannel_backend_type: vxlan plugin: canal -# +# # services: # kube-api: # service_cluster_ip_range: 10.43.0.0/16 @@ -197,7 +197,7 @@ rancher_kubernetes_engine_config: # Your RKE template config goes here. # kubelet: # cluster_domain: cluster.local # cluster_dns_server: 10.43.0.10 -# +# services: etcd: backup_config: @@ -232,46 +232,46 @@ addon_job_timeout: 30 authentication: strategy: x509 ignore_docker_version: true -# +# # # Currently only nginx ingress provider is supported. # # To disable ingress controller, set `provider: none` # # To enable ingress on specific nodes, use the node_selector, eg: # provider: nginx # node_selector: # app: ingress -# +# ingress: provider: nginx kubernetes_version: v1.15.3-rancher3-1 monitoring: provider: metrics-server -# +# # If you are using calico on AWS -# +# # network: # plugin: calico # calico_network_provider: # cloud_provider: aws -# +# # # To specify flannel interface -# +# # network: # plugin: flannel # flannel_network_provider: # iface: eth1 -# +# # # To specify flannel interface for canal plugin -# +# # network: # plugin: canal # canal_network_provider: # iface: eth1 -# +# network: options: flannel_backend_type: vxlan plugin: canal -# +# # services: # kube-api: # service_cluster_ip_range: 10.43.0.0/16 @@ -281,7 +281,7 @@ network: # kubelet: # cluster_domain: cluster.local # cluster_dns_server: 10.43.0.10 -# +# services: etcd: backup_config: diff --git a/content/rancher/v2.x/en/contributing/_index.md b/content/rancher/v2.x/en/contributing/_index.md index 857f81ef92c..ea8273a830b 100644 --- a/content/rancher/v2.x/en/contributing/_index.md +++ b/content/rancher/v2.x/en/contributing/_index.md @@ -5,7 +5,7 @@ aliases: - /rancher/v2.x/en/faq/contributing/ --- -This section explains the respositories used for Rancher, how to build the repositories, and what information to include when you file an issue. +This section explains the repositories used for Rancher, how to build the repositories, and what information to include when you file an issue. For more detailed information on how to contribute to the development of Rancher projects, refer to the [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki). The wiki has resources on many topics, including the following: diff --git a/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md b/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md index 28b7f587576..76b489cb64f 100644 --- a/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md +++ b/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md @@ -127,7 +127,7 @@ The following table summarizes the different features available for each CNI net - External Datastore: CNI network providers with this feature need an external datastore for its data. -- Encyption: This feature allows cyphered and secure network control and data planes. +- Encryption: This feature allows cyphered and secure network control and data planes. - Ingress/Egress Policies: This feature allows you to manage routing control for both Kubernetes and non-Kubernetes communications. diff --git a/content/rancher/v2.x/en/installation/ha/create-nodes-lb/nginx/_index.md b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/nginx/_index.md index 928b4a8fc57..8fbca33a814 100644 --- a/content/rancher/v2.x/en/installation/ha/create-nodes-lb/nginx/_index.md +++ b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/nginx/_index.md @@ -22,7 +22,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx. 1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`. -2. From `nginx.conf`, replace both occurences (port 80 and port 443) of ``, ``, and `` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/). +2. From `nginx.conf`, replace both occurrences (port 80 and port 443) of ``, ``, and `` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/). > **Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options. diff --git a/content/rancher/v2.x/en/installation/how-ha-works/_index.md b/content/rancher/v2.x/en/installation/how-ha-works/_index.md index 739506c6404..f88defc3682 100644 --- a/content/rancher/v2.x/en/installation/how-ha-works/_index.md +++ b/content/rancher/v2.x/en/installation/how-ha-works/_index.md @@ -3,7 +3,7 @@ title: About High-availability Installations weight: 2 --- -We recommend using [Helm,]({{}}/rancher/v2.x/en/overview/architecture/concepts/#about-helm) a Kubernetes package manager, to install Rancher on a dedicated Kubernetes cluster. This is called a high-availability (HA) installation because increased avaialability is achieved by running Rancher on multiple nodes. +We recommend using [Helm,]({{}}/rancher/v2.x/en/overview/architecture/concepts/#about-helm) a Kubernetes package manager, to install Rancher on a dedicated Kubernetes cluster. This is called a high-availability (HA) installation because increased availability is achieved by running Rancher on multiple nodes. In a typical HA Rancher installation, Kubernetes is first installed on three nodes that are hosted in an infrastructure provider such as Amazon's EC2 or Google Compute Engine. diff --git a/content/rancher/v2.x/en/installation/options/chart-options/_index.md b/content/rancher/v2.x/en/installation/options/chart-options/_index.md index db92df57800..3e3e477a56e 100644 --- a/content/rancher/v2.x/en/installation/options/chart-options/_index.md +++ b/content/rancher/v2.x/en/installation/options/chart-options/_index.md @@ -192,7 +192,7 @@ This NGINX configuration is tested on NGINX 1.14. > **Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/). - Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster. -- Replace both occurences of `FQDN` to the DNS name for Rancher. +- Replace both occurrences of `FQDN` to the DNS name for Rancher. - Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively. ``` diff --git a/content/rancher/v2.x/en/installation/options/etcd/_index.md b/content/rancher/v2.x/en/installation/options/etcd/_index.md index 3746064e844..dfe02cabb98 100644 --- a/content/rancher/v2.x/en/installation/options/etcd/_index.md +++ b/content/rancher/v2.x/en/installation/options/etcd/_index.md @@ -25,7 +25,7 @@ You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3. Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use stripping RAID configurations to increase available IOPS. -To implement this solution in an RKE cluster, the `/var/lib/etcd/data` and `/var/lib/etc/wal` directories will need to have disks mounted and formmated on the underlying host. In the `extra_args` directive of the `etcd` service, you must include the `wal_dir` directory. Without specifying the `wal_dir`, etcd process will try to manipulate the underlying `wal` mount with insufficient permissions. +To implement this solution in an RKE cluster, the `/var/lib/etcd/data` and `/var/lib/etc/wal` directories will need to have disks mounted and formatted on the underlying host. In the `extra_args` directive of the `etcd` service, you must include the `wal_dir` directory. Without specifying the `wal_dir`, etcd process will try to manipulate the underlying `wal` mount with insufficient permissions. ```yaml # RKE cluster.yml diff --git a/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md b/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md index ad5b37792c3..631dc196339 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md @@ -21,7 +21,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx. 1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`. -2. From `nginx.conf`, replace both occurences (port 80 and port 443) of ``, ``, and `` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/). +2. From `nginx.conf`, replace both occurrences (port 80 and port 443) of ``, ``, and `` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/). >**Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options. diff --git a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md index ae2c449dcb3..b7aed0238dc 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md @@ -192,7 +192,7 @@ This NGINX configuration is tested on NGINX 1.14. >**Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/). * Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster. -* Replace both occurences of `FQDN` to the DNS name for Rancher. +* Replace both occurrences of `FQDN` to the DNS name for Rancher. * Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively. ``` diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md index 66c0f330213..9eeb325d616 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md @@ -210,7 +210,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec services: etcd: - backup: false + backup: false ## 7. Configure Certificates @@ -392,7 +392,7 @@ During installation, RKE automatically generates a config file named `kube_confi You have a couple of options: -- Create a backup of your Rancher Server in case of a disaster scenario: [High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration). +- Create a backup of your Rancher Server in case of a disaster scenario: [High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration). - Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).
diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md index dca03867288..1ada737e358 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md @@ -134,7 +134,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`. >**Note:** - > + > >When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements. nodes: @@ -159,7 +159,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec services: etcd: - backup: false + backup: false ## 7. Configure Certificates @@ -278,7 +278,7 @@ During installation, RKE automatically generates a config file named `kube_confi ## What's Next? -- **Recommended:** Review [Creating Backups—High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario. +- **Recommended:** Review [Creating Backups—High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario. - Create a Kubernetes cluster: [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).
diff --git a/content/rancher/v2.x/en/installation/options/rke-add-on/layer-4-lb/_index.md b/content/rancher/v2.x/en/installation/options/rke-add-on/layer-4-lb/_index.md index 290be87b9e9..222ee65542e 100644 --- a/content/rancher/v2.x/en/installation/options/rke-add-on/layer-4-lb/_index.md +++ b/content/rancher/v2.x/en/installation/options/rke-add-on/layer-4-lb/_index.md @@ -211,7 +211,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec services: etcd: - backup: false + backup: false ## 7. Configure Certificates @@ -393,7 +393,7 @@ During installation, RKE automatically generates a config file named `kube_confi You have a couple of options: -- Create a backup of your Rancher Server in case of a disaster scenario: [High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration). +- Create a backup of your Rancher Server in case of a disaster scenario: [High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration). - Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).
diff --git a/content/rancher/v2.x/en/installation/options/rke-add-on/layer-7-lb/_index.md b/content/rancher/v2.x/en/installation/options/rke-add-on/layer-7-lb/_index.md index 7502a60584f..1d53224c6df 100644 --- a/content/rancher/v2.x/en/installation/options/rke-add-on/layer-7-lb/_index.md +++ b/content/rancher/v2.x/en/installation/options/rke-add-on/layer-7-lb/_index.md @@ -135,7 +135,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`. >**Note:** - > + > >When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements. nodes: @@ -160,7 +160,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec services: etcd: - backup: false + backup: false ## 7. Configure Certificates @@ -279,7 +279,7 @@ During installation, RKE automatically generates a config file named `kube_confi ## What's Next? -- **Recommended:** Review [Creating Backups—High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario. +- **Recommended:** Review [Creating Backups—High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario. - Create a Kubernetes cluster: [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).
diff --git a/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md b/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md index 69ad051a38e..622eea8c319 100644 --- a/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md +++ b/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md @@ -11,7 +11,7 @@ Rancher uses cert-manager to automatically generate and renew TLS certificates f To address these changes, this guide will do two things: 1. Document the procedure for upgrading cert-manager -1. Explain the cert-manager API changes and link to cert-manager's offficial documentation for migrating your data +1. Explain the cert-manager API changes and link to cert-manager's official documentation for migrating your data ## Performing the upgrade diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/single-node-install-external-lb/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/single-node-install-external-lb/_index.md index 76fca429f83..bc79b50ad59 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/single-node-install-external-lb/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/single-node-install-external-lb/_index.md @@ -106,7 +106,7 @@ This NGINX configuration is tested on NGINX 1.14. > **Note:** This Nginx configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/). - Replace `rancher-server` with the IP address or hostname of the node running the Rancher container. -- Replace both occurences of `FQDN` to the DNS name for Rancher. +- Replace both occurrences of `FQDN` to the DNS name for Rancher. - Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively. ``` diff --git a/content/rancher/v2.x/en/installation/requirements/_index.md b/content/rancher/v2.x/en/installation/requirements/_index.md index 64c9043fca7..9cc63f86b67 100644 --- a/content/rancher/v2.x/en/installation/requirements/_index.md +++ b/content/rancher/v2.x/en/installation/requirements/_index.md @@ -40,7 +40,7 @@ If you plan to run Rancher on ARM64, see [Running on ARM64 (Experimental).]({{}}/rancher/v2.x/en/installation/requirements/installing-docker) to install Docker with one command. +Docker can be installed by following the steps in the official [Docker documentation.](https://docs.docker.com/) Rancher also provides [scripts]({{}}/rancher/v2.x/en/installation/requirements/installing-docker) to install Docker with one command. # Hardware Requirements diff --git a/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md index b2d81be4bd7..8e3670d145f 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md @@ -32,7 +32,7 @@ Add SSL certificates to either projects, namespaces, or both. A project scoped c 1. From **Certificate**, either copy and paste your certificate into the text box (include the header and footer), or click **Read from a file** to browse to the certificate on your file system. If possible, we recommend using **Read from a file** to reduce likelihood of error. - Certifcate files end with an extension of `.crt`. + Certificate files end with an extension of `.crt`. **Result:** Your certificate is added to the project or namespace. You can now add it to deployments. diff --git a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-rancher-ui/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-rancher-ui/_index.md index d0c7e6cdb9e..5a3af016138 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-rancher-ui/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-rancher-ui/_index.md @@ -50,6 +50,6 @@ If you want to create HPAs that scale based on other metrics than CPU and memory 1. Click **Ellipsis (...) > Delete**. -1. Click **Delete** to confim. +1. Click **Delete** to confirm. > **Result:** The HPA is deleted from the current cluster. \ No newline at end of file diff --git a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/_index.md index 70e11daac47..cb49344658d 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/_index.md @@ -60,7 +60,7 @@ spec: selector: app: hello-world ``` -{{% /accordion %}} +{{% /accordion %}} 1. Deploy it to your cluster. @@ -222,14 +222,14 @@ Use your load testing tool to scale up to two pods based on CPU Usage. # kubectl get pods ``` You should receive output similar to what follows: - ``` + ``` NAME READY STATUS RESTARTS AGE hello-world-54764dfbf8-k8ph2 1/1 Running 0 1m hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h ``` {{% /accordion %}} {{% accordion id="observe-upscale-3-pods-cpu-cooldown" label="Upscale to 3 pods: CPU Usage Up to Target" %}} -Use your load testing tool to upspace to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes. +Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes. 1. Enter the following command. ``` @@ -312,7 +312,7 @@ Use your load testing to scale down to 1 pod when all metrics are below target f Use your load testing tool to upscale two pods based on CPU usage. 1. Enter the following command. - ``` + ``` # kubectl describe hpa ``` You should receive output similar to what follows. @@ -345,7 +345,7 @@ Use your load testing tool to upscale two pods based on CPU usage. # kubectl get pods ``` You should receive output similar to what follows. - ``` + ``` NAME READY STATUS RESTARTS AGE hello-world-54764dfbf8-5pfdr 1/1 Running 0 3s hello-world-54764dfbf8-q6l82 1/1 Running 0 6h @@ -387,7 +387,7 @@ Use your load testing tool to scale up to three pods when the cpu_system usage l 1. Enter the following command to confirm three pods are running. ``` # kubectl get pods - ``` + ``` You should receive output similar to what follows: ``` # kubectl get pods @@ -443,7 +443,7 @@ Use your load testing tool to upscale to four pods based on CPU usage. `horizont hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s hello-world-54764dfbf8-q6l82 1/1 Running 0 6h ``` -{{% /accordion %}} +{{% /accordion %}} {{% accordion id="custom-metrics-observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}} Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`. @@ -484,8 +484,8 @@ Use your load testing tool to scale down to one pod when all metrics below targe # kubectl get pods ``` You should receive output similar to what follows. - ``` + ``` NAME READY STATUS RESTARTS AGE hello-world-54764dfbf8-q6l82 1/1 Running 0 6h - ``` + ``` {{% /accordion %}} \ No newline at end of file diff --git a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md index 409d2b64b60..d90fc336f02 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md @@ -73,7 +73,7 @@ Ingress can be added for workloads to provide load balancing, SSL termination an 1. Enter the **Host** using encrypted communication. - 1. To add additional hosts that use the certitificate, click **Add Hosts**. + 1. To add additional hosts that use the certificate, click **Add Hosts**. 1. **Optional:** Add [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) and/or [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to provide metadata for your ingress. diff --git a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md index 0efcd6c9095..7c6071500ed 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md @@ -11,7 +11,7 @@ aliases: >- Pipelines are new and improved for Rancher v2.1! Therefore, if you configured pipelines while using v2.0.x, you'll have to reconfigure them after upgrading to v2.1. >- Still using v2.0.x? See the pipeline documentation for [previous versions]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x). -Before setting up any pipelines, review the [pipeline overview]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/) and ensure that the project has [configured authentication to your version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), e.g. GitHub, GitLab, Bitucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/) to view some common pipeline deployments. +Before setting up any pipelines, review the [pipeline overview]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/) and ensure that the project has [configured authentication to your version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), e.g. GitHub, GitLab, Bitbucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/) to view some common pipeline deployments. If you can access a project, you can enable repositories to start building pipelines. Only an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can authorize version control providers. @@ -99,7 +99,7 @@ If you haven't added any stages, click **Configure pipeline for this branch** to {{% /tab %}} {{% tab "By YAML" %}}
-For each stage, you can add multiple steps. Read more about each [step type](#step-types) and the [advanced options](#advanced-options) to get all thhe details on how to configure the YAML. This is only a small example of how to have multiple stages with a singular step in each stage. +For each stage, you can add multiple steps. Read more about each [step type](#step-types) and the [advanced options](#advanced-options) to get all the details on how to configure the YAML. This is only a small example of how to have multiple stages with a singular step in each stage. ```yaml # example @@ -145,7 +145,7 @@ _Available as of v2.2.0_ 1. Select the conditions for the notification. You can select to get a notification for the following statuses: `Failed`, `Success`, `Changed`. For example, if you want to receive notifications when an execution fails, select **Failed**. -1. If you don't have any existing [notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers), Rancher will provide a warning that no notifers are set up and provide a link to be able to go to the notifiers page. Follow the [instructions]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers) to add a notifier. If you already have notifiers, you can add them to the notification by clicking the **Add Recipient** button. +1. If you don't have any existing [notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers), Rancher will provide a warning that no notifiers are set up and provide a link to be able to go to the notifiers page. Follow the [instructions]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers) to add a notifier. If you already have notifiers, you can add them to the notification by clicking the **Add Recipient** button. > **Note:** Notifiers are configured at a cluster level and require a different level of permissions. @@ -163,7 +163,7 @@ In the `notification` section, you will provide the following information: * **Notifier:** The ID of the notifier. This can be found by finding the notifier and selecting **View in API** to get the ID. * **Recipient:** Depending on the type of the notifier, the "default recipient" can be used or you can override this with a different recipient. For example, when configuring a slack notifier, you select a channel as your default recipient, but if you wanted to send notifications to a different channel, you can select a different recipient. * **Condition:** Select which conditions of when you want the notification to be sent. -* **Message (Optional):** If you want to change the default notification message, you can edit this in the yaml. Note: This option is not available in the UI. +* **Message (Optional):** If you want to change the default notification message, you can edit this in the yaml. Note: This option is not available in the UI. ```yaml # Example @@ -181,7 +181,7 @@ notification: notifier: "c-wdcsr:n-c9pg7" - recipient: "test@example.com" notifier: "c-wdcsr:n-lkrhd" - # Select which statuses you want the notification to be sent + # Select which statuses you want the notification to be sent condition: ["Failed", "Success", "Changed"] # Ability to override the default message (Optional) message: "my-message" @@ -309,7 +309,7 @@ stages:
{{% /tab %}} -{{% /tabs %}} +{{% /tabs %}} ### Build and Publish Images @@ -413,7 +413,7 @@ Under the `steps` section, add a step with `publishCatalogConfig`. You will prov * GitBranch: The git branch of the chart repository that the template will be published to. * GitAuthor: The author name used in the commit message. * GitEmail: The author email used in the commit message. -* Credentials: You should provide Git credentials by referencing secrets in dedicated pipeline namespace. If you publish via SSH protocol, inject your deploy key to the `DEPLOY_KEY` environment variable. If you publish via HTTP(S) protolcol, inject your username and password to `USERNAME` and `PASSWORD` environment variables. +* Credentials: You should provide Git credentials by referencing secrets in dedicated pipeline namespace. If you publish via SSH protocol, inject your deploy key to the `DEPLOY_KEY` environment variable. If you publish via HTTP(S) protocol, inject your username and password to `USERNAME` and `PASSWORD` environment variables. ```yaml # example @@ -467,7 +467,7 @@ stages:
{{% /tab %}} -{{% /tabs %}} +{{% /tabs %}} ### Deploy Catalog App @@ -563,7 +563,7 @@ Wildcard character (`*`) expansion is supported in `branch` conditions. 1. Click **Add Rule**. In the **Value** field, enter the name of the branch that triggers the pipeline. - 1. **Optional:** Add more branches that trigger a build. + 1. **Optional:** Add more branches that trigger a build. 1. Click **Done.** @@ -581,7 +581,7 @@ Wildcard character (`*`) expansion is supported in `branch` conditions. 1. In the **Trigger Rules** section, configure rules to run or skip the stage. - 1. Click **Add Rule**. + 1. Click **Add Rule**. 1. Choose the **Type** that triggers the stage and enter a value. @@ -606,7 +606,7 @@ Wildcard character (`*`) expansion is supported in `branch` conditions. 1. In the **Trigger Rules** section, configure rules to run or skip the step. - 1. Click **Add Rule**. + 1. Click **Add Rule**. 1. Choose the **Type** that triggers the step and enter a value. @@ -660,7 +660,7 @@ When configuring a pipeline, certain [step types](#step-types) allow you to use 1. Within one of the stages, find the **step** that you want to add an environment variable for, click the **Edit** icon. -1. Click **Show advanced options**. +1. Click **Show advanced options**. 1. Click **Add Variable**, and then enter a key and value in the fields that appear. Add more variables if needed. @@ -709,7 +709,7 @@ Create a secret in the same project as your pipeline, or explicitly in the names 1. Within one of the stages, find the **step** that you want to use a secret for, click the **Edit** icon. -1. Click **Show advanced options**. +1. Click **Show advanced options**. 1. Click **Add From Secret**. Select the secret file that you want to use. Then choose a key. Optionally, you can enter an alias for the key. diff --git a/content/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads/_index.md index a10bcea6ebd..4be9cd00eaf 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads/_index.md @@ -9,7 +9,7 @@ Sometimes there is a need to rollback to the previous version of the application 1. From the **Global** view, open the project running the workload you want to rollback. -1. Find the workload that you want to rollback and select **Vertical Elipsis (... ) > Rollback**. +1. Find the workload that you want to rollback and select **Vertical Ellipsis (... ) > Rollback**. 1. Choose the revision that you want to roll back to. Click **Rollback**. diff --git a/content/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads/_index.md index c00c15e0a97..5d47c733ed4 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads/_index.md @@ -8,7 +8,7 @@ When a new version of an application image is released on Docker Hub, you can up 1. From the **Global** view, open the project running the workload you want to upgrade. -1. Find the workload that you want to upgrade and select **Vertical Elipsis (... ) > Edit**. +1. Find the workload that you want to upgrade and select **Vertical Ellipsis (... ) > Edit**. 1. Update the **Docker Image** to the updated version of the application image on Docker Hub. diff --git a/content/rancher/v2.x/en/security/benchmark-2.1/_index.md b/content/rancher/v2.x/en/security/benchmark-2.1/_index.md index caa0cb60459..d5e2c74968f 100644 --- a/content/rancher/v2.x/en/security/benchmark-2.1/_index.md +++ b/content/rancher/v2.x/en/security/benchmark-2.1/_index.md @@ -1190,7 +1190,7 @@ docker inspect etcd | jq -e '.[0].Args[] | match("--peer-auto-tls(?:(?!=false).* **Notes** -RKE does not currently implement a seperate CA for etcd certificates. +RKE does not currently implement a separate CA for etcd certificates. `--trusted-ca-file` is set and different from the `--client-ca-file` used by `kube-apiserver`. diff --git a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/controlplane/_index.md b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/controlplane/_index.md index e3451e421ef..a94b1a04ee7 100644 --- a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/controlplane/_index.md +++ b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/controlplane/_index.md @@ -7,7 +7,7 @@ This section applies to nodes with the `controlplane` role. # Check if the Controlplane Containers are Running -There are three specific containers launched on nodes with the `controlpane` role: +There are three specific containers launched on nodes with the `controlplane` role: * `kube-apiserver` * `kube-controller-manager` diff --git a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/worker-and-generic/_index.md b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/worker-and-generic/_index.md index 2f92ed8b9b2..d102694fe45 100644 --- a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/worker-and-generic/_index.md +++ b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/worker-and-generic/_index.md @@ -7,7 +7,7 @@ This section applies to every node as it includes components that run on nodes w # Check if the Containers are Running -There are three specific containers launched on nodes with the `controlpane` role: +There are three specific containers launched on nodes with the `controlplane` role: * kubelet * kube-proxy diff --git a/content/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/_index.md b/content/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/_index.md index f0304c2eb44..bc7d2301915 100644 --- a/content/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/_index.md +++ b/content/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/_index.md @@ -38,7 +38,7 @@ You can obtain `` and `` by loggi ## Rolling Back Rancher -If you have issues upgrading Rancher, roll it back to its lastest known healthy state by pulling the last version you used and then restoring the backup you made before upgrade. +If you have issues upgrading Rancher, roll it back to its latest known healthy state by pulling the last version you used and then restoring the backup you made before upgrade. >**Warning!** Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur. @@ -51,7 +51,7 @@ If you have issues upgrading Rancher, roll it back to its lastest known healthy ``` docker pull rancher/rancher: ``` - + 1. Stop the container currently running Rancher Server. Replace `` with the name of your Rancher container. ``` diff --git a/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md b/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md index aa76e842de3..6885d6794a1 100644 --- a/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md +++ b/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md @@ -157,6 +157,6 @@ Cattle provided feature-rich load balancer support that is [well documented]({{< - Only ports 80 and 443 can be configured for HTTP/HTTPS routing via Ingress. Also Ingress Controller is deployed globally as a DaemonSet and not launched as a scalable service. Also, users cannot assign random external ports to be used for balancing. Therefore, users need to ensure that they configure unique hostname/path combinations to avoid routing conflicts using the same two ports. - There is no way to specify port rule priority and ordering. - Rancher v1.6 added support for draining backend connections and specifying a drain timeout. This is not supported in Rancher v2.x. -- There is no support for specifying a custom stickiness policy and a custom load balancer config to be appended to the default config as of now in Rancher v2.x. There is some support, however, available in native Kubernetes for customizing the NGINX configuration as noted in the [NGINX Ingress Controller Custom Conguration Documentation](https://kubernetes.github.io/ingress-nginx/examples/customization/custom-configuration/). +- There is no support for specifying a custom stickiness policy and a custom load balancer config to be appended to the default config as of now in Rancher v2.x. There is some support, however, available in native Kubernetes for customizing the NGINX configuration as noted in the [NGINX Ingress Controller Custom Configuration Documentation](https://kubernetes.github.io/ingress-nginx/examples/customization/custom-configuration/). ### Finished! diff --git a/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md b/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md index d018c49e4e4..c9ea17668c4 100644 --- a/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md +++ b/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md @@ -45,7 +45,7 @@ The following diagram displays the health check microservice evaluating a contai ## Rancher v2.x Health Checks -In Rancher v2.x, the health check microservice is replaced with Kubernete's native health check mechanisms, called _probes_. These probes, similar to the Rancher v1.6 health check microservice, monitor the health of pods over TCP and HTTP. +In Rancher v2.x, the health check microservice is replaced with Kubernetes's native health check mechanisms, called _probes_. These probes, similar to the Rancher v1.6 health check microservice, monitor the health of pods over TCP and HTTP. However, probes in Rancher v2.x have some important differences, which are described below. For full details about probes, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes). diff --git a/content/rke/latest/en/config-options/secrets-encryption/_index.md b/content/rke/latest/en/config-options/secrets-encryption/_index.md index 9d447592c0a..c4dc378a249 100644 --- a/content/rke/latest/en/config-options/secrets-encryption/_index.md +++ b/content/rke/latest/en/config-options/secrets-encryption/_index.md @@ -18,7 +18,7 @@ RKE provides users with two paths of configuration to enable at-rest data encryp - Managed at-rest data encryption - Custom configuration for at-rest data encryption -Both configuration options can be added during initial cluster provisioning or by updating an exsiting cluster. +Both configuration options can be added during initial cluster provisioning or by updating an existing cluster. To utilize this feature, a new field `secrets_encryption_config` is added to the [Kubernetes API service configuration]({{}}//rke/latest/en/config-options/services/#kubernetes-api-server). A full custom configuration looks like this: diff --git a/content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md b/content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md index f8cee4cc5e4..81240247b68 100644 --- a/content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md +++ b/content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md @@ -20,7 +20,7 @@ CONTAINER ID IMAGE COMMAND CREATED See [Manage Docker as a non-root user](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user) how to set this up properly. -* When using RedHat/CentOS as operating system, you cannot use the user `root` to connect to the nodes because of [Bugzilla #1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). You will need to add a separate user and configure it to access the Docker socket. See [RKE OS Requirements](https://rancher.com/docs/rke/latest/en/os/#red-hat-enterprise-linux-rhel-oracle-enterprise-linux-oel-centos) for more on how to set this up. +* When using RedHat/CentOS as operating system, you cannot use the user `root` to connect to the nodes because of [Bugzilla #1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). You will need to add a separate user and configure it to access the Docker socket. See [RKE OS Requirements](https://rancher.com/docs/rke/latest/en/os/#red-hat-enterprise-linux-rhel-oracle-enterprise-linux-oel-centos) for more on how to set this up. * SSH server version is not version 6.7 or higher. This is needed for socket forwarding to work, which is used to connect to the Docker socket over SSH. This can be checked using `sshd -V` on the host you are connecting to, or using netcat: ``` @@ -35,7 +35,7 @@ SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10 #### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain -* The key file specified as `ssh_key_path` is not correct for accesing the node. Double-check if you specified the correct `ssh_key_path` for the node and if you specified the correct user to connect with. +* The key file specified as `ssh_key_path` is not correct for accessing the node. Double-check if you specified the correct `ssh_key_path` for the node and if you specified the correct user to connect with. #### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: cannot decode encrypted private keys