Merge branch 'main' into release/v2.7.2

2026-09-25 20:48:11 +00:00 · 2023-04-10 16:17:10 -04:00
parent 401caeaa80 a5e3b54e32
commit ee9379eace
46 changed files with 7177 additions and 1124 deletions
@@ -32,7 +32,8 @@ The restore operation will work on a cluster that is not in a healthy or active

 :::note Prerequisites:

- The options below are available only for [Rancher-launched RKE Kubernetes clusters](../../pages-for-subheaders/launch-kubernetes-with-rancher.md) and [Registered K3s Kubernetes clusters.](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#additional-features-for-registered-k3s-clusters)
+- The options below are available for [Rancher-launched Kubernetes clusters](../../pages-for-subheaders/launch-kubernetes-with-rancher.md) and [Registered K3s Kubernetes clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#additional-features-for-registered-k3s-clusters).
+- The following options also apply to imported RKE2 clusters that you have registered. If you import a cluster from an external cloud platform but don't register it, you won't be able to upgrade the Kubernetes version from Rancher.
 - Before upgrading Kubernetes, [back up your cluster.](../../pages-for-subheaders/backup-restore-and-disaster-recovery.md)

 :::
@@ -15,14 +15,14 @@ The full installation requirements are [here](../../../pages-for-subheaders/inst

 ## Install K3s on Linux

+Rancher needs to be installed on a supported Kubernetes version. To specify the K3s version, use the INSTALL_K3S_VERSION (e.g., `INSTALL_K3S_VERSION="v1.24.10+k3s1"`) environment variable when running the K3s installation script. Refer to the [support maintenance terms](https://rancher.com/support-maintenance-terms/).
+
 Install a K3s cluster by running this command on the Linux machine:

 ```
-curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="***" sh -s - server --cluster-init
+curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> sh -s - server --cluster-init
 ```

-Rancher needs to be installed on a supported Kubernetes version. To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script. Refer to the [support maintenance terms](https://rancher.com/support-maintenance-terms/).
-
 Using `--cluster-init` allows K3s to use embedded etcd as the datastore and has the ability to convert to an HA setup. Refer to [High Availability with Embedded DB](https://rancher.com/docs/k3s/latest/en/installation/ha-embedded/).

 Save the IP of the Linux machine.
@@ -38,6 +38,8 @@ The kubeconfig file is important for accessing the Kubernetes cluster. Copy the
 scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml ~/.kube/config
 ```

+In some cases it may need to make sure that your shell has the environment variable `KUBECONFIG=~/.kube/config` defined, for instance, it can be exported in your profile or rc files.
+
 </TabItem>
 <TabItem value="Windows">

@@ -18,7 +18,7 @@ For this workload, you'll be deploying the application Rancher Hello-World.
 1. Click **Create**.
 1. Click **Deployment**.
 1. Enter a **Name** for your workload.
-1. From the **Docker Image** field, enter `rancher/hello-world`. This field is case-sensitive.
+1. From the **Container Image** field, enter `rancher/hello-world`. This field is case-sensitive.
 1. Click **Add Port** and enter `80` in the **Private Container Port** field. Adding a port enables access to the application inside and outside of the cluster. For more information, see [Services](../../../pages-for-subheaders/workloads-and-pods.md#services).
 1. Click **Create**.

@@ -10,10 +10,11 @@ You can enable monitoring with or without SSL.

 ## Requirements

- Make sure that you are allowing traffic on port 9796 for each of your nodes because Prometheus will scrape metrics from here.
- Make sure your cluster fulfills the resource requirements. The cluster should have at least 1950Mi memory available, 2700m CPU, and 50Gi storage. A breakdown of the resource limits and requests is [here.](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests)
- When installing monitoring on an RKE cluster using RancherOS or Flatcar Linux nodes, change the etcd node certificate directory to `/opt/rke/etc/kubernetes/ssl`.
- For clusters provisioned with the RKE CLI and the address is set to a hostname instead of an IP address, set `rkeEtcd.clients.useLocalhost` to `true` during the Values configuration step of the installation. The YAML snippet will look like the following:
+- Allow traffic on port 9796 for each of your nodes. Prometheus scrapes metrics from these ports.
+  - You may also need to allow traffic on port 10254 for each of your nodes, if [PushProx](../../../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#pushprox) is disabled (`ingressNginx.enabled` set to `false`), or you've upgraded from a previous Rancher version that had v1 monitoring already installed.
+- Make sure that your cluster fulfills the resource requirements. The cluster should have at least 1950Mi memory available, 2700m CPU, and 50Gi storage. See [Configuring Resource Limits and Requests](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests) for a breakdown of the resource limits and requests.
+- When you install monitoring on an RKE cluster that uses RancherOS or Flatcar Linux nodes, change the etcd node certificate directory to `/opt/rke/etc/kubernetes/ssl`.
+- For clusters that have been provisioned with the RKE CLI and that have the address set to a hostname instead of an IP address, set `rkeEtcd.clients.useLocalhost` to `true` when you configure the Values during installation. For example:

 ```yaml
 rkeEtcd:
@@ -27,7 +28,7 @@ If you want to set up Alertmanager, Grafana or Ingress, it has to be done with t

 :::

-#Setting Resource Limits and Requests
+## Setting Resource Limits and Requests

 The resource requests and limits can be configured when installing `rancher-monitoring`.  To configure Prometheus resources from the Rancher UI, click **Apps > Monitoring** in the upper left corner.

@@ -276,6 +276,7 @@ If you upgrade to Rancher v2.7.0+ with an existing Azure AD setup, and choose to

 :::

+
 #### Global:

 Rancher Field    | Deprecated Endpoints
@@ -2,36 +2,56 @@
 title: Configuring a Global Default Private Registry
 ---

-You might want to use a private container image registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the container images that are used in your clusters.
+:::note
+This page describes how to configure a global default private registry from the Rancher UI, after Rancher is already installed. 

-There are two main ways to set up private registries in Rancher: by setting up the global default registry through the **Settings** tab in the global view, and by setting up a private registry in the advanced options in the cluster-level settings. The global default registry is intended to be used for air-gapped setups, for registries that do not require credentials. The cluster-level private registry is intended to be used in all setups in which the private registry requires credentials.
+For instructions on how to set up a private registry during Rancher installation, refer to the [air-gapped installation guide](../../../pages-for-subheaders/air-gapped-helm-cli-install.md).

-This section is about configuring the global default private registry, and focuses on how to configure the registry from the Rancher UI after Rancher is installed.
+:::

-For instructions on setting up a private registry with command line options during the installation of Rancher, refer to the [air-gapped installation guide](../../../pages-for-subheaders/air-gapped-helm-cli-install.md).
+A private registry is a private, consistent, and centralized source of truth for the container images in your clusters. You can use a private container image registry to share custom base images within your organization.

-If your private registry requires credentials, it cannot be used as the default registry. There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry with credentials, you will have to [pass in the registry credentials through the advanced cluster options](#setting-a-private-registry-with-credentials-when-deploying-a-cluster) every time you create a new cluster.
+There are two main ways to set up a private registry in Rancher:

-## Setting a Private Registry with No Credentials as the Default Registry
+* Set up a global default registry through the **Settings** tab in the global view.
+* Set up a private registry in the advanced options under cluster-level settings. 
+
+The global default registry is intended to be used in air-gapped setups, for registries that don't require credentials. The cluster-level private registry is intended to be used in setups where the private registry requires credentials.
+
+## Set a Private Registry with No Credentials as the Default Registry

 1. Log into Rancher and configure the default administrator password.
-1. Click **☰ > Global Settings**.
-1. Go to the setting called `system-default-registry` and choose **⋮ > Edit Setting**.
-1. Change the value to your registry (e.g. `registry.yourdomain.com:port`). Do not prefix the registry with `http://` or `https://`.
+1. Select **☰ > Global Settings**.
+1. Go to `system-default-registry` and choose **⋮ > Edit Setting**.
+1. Enter your registry's hostname and port (e.g. `registry.yourdomain.com:port`). Do not prefix the text with `http://` or `https://`.

-**Result:** Rancher will use your private registry to pull system images.
+**Result:** Rancher pulls system images from your private registry.

-## Setting a Private Registry with Credentials when Deploying a Cluster
+### Namespaced Private Registry with RKE2 Downstream Clusters

-You can follow these steps to configure a private registry when you create a cluster:
+Most private registries should work, by default, with RKE2 downstream clusters.

-1. Click **☰ > Cluster Management**.
+However, you'll need to do some additional steps if you're trying to set a namespaced private registry whose URL is formated like this: `website/subdomain:portnumber`.
+
+1. Select **☰ > Cluster Management**.
+1. Find the RKE2 cluster in the list and click **⋮ >Edit Config**.
+1. From the **Cluster config** menu, select **Registries**.
+1. In the **Registries** pane, select the **Configure advanced containerd mirroring and registry authentication options** option.
+1. In the text fields under **Mirrors**, enter the **Registry Hostname** and **Mirror Endpoints**.
+1. Click **Save**.
+1. Repeat as necessary for each downstream RKE2 cluster.
+
+## Configure a Private Registry with Credentials when Creating a Cluster
+
+There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry that requires credentials, you'll have to pass the registry credentials through the advanced cluster options every time you create a new cluster. 
+
+Since the private registry cannot be configured after the cluster is created, you'll need to perform these steps during initial cluster setup.
+
+1. Select **☰ > Cluster Management**.
 1. On the **Clusters** page, click **Create**.
 1. Choose a cluster type.
-1. In the **Cluster Configuration** go to the **Registries** tab and click **Pull images for Rancher from a private registry**.
+1. In the **Cluster Configuration** go to the **Registries** tab and select **Pull images for Rancher from a private registry**.
 1. Enter the registry hostname and credentials.
 1. Click **Create**.

-**Result:** The new cluster will be able to pull images from the private registry.
-
-The private registry cannot be configured after the cluster is created.
+**Result:** The new cluster pulls images from the private registry.
@@ -17,9 +17,7 @@ For more information on RKE node roles, see the [best practices.](../../../pages

 ### Permissions

-If your existing Kubernetes cluster already has a `cluster-admin` role defined, you must have this `cluster-admin` privilege to register the cluster in Rancher.
-
-In order to apply the privilege, you need to run:
+To register a cluster in Rancher, you must have `cluster-admin` privileges within that cluster. If you don't, grant these privileges to your user by running:

 ```plain
 kubectl create clusterrolebinding cluster-admin-binding \
@@ -27,13 +25,11 @@ kubectl create clusterrolebinding cluster-admin-binding \
  --user [USER_ACCOUNT]
 ```

-before running the `kubectl` command to register the cluster.
-
-By default, GKE users are not given this privilege, so you will need to run the command before registering GKE clusters. To learn more about role-based access control for GKE, please click [here](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control).
+Since, by default, Google Kubernetes Engine (GKE) doesn't grant the `cluster-admin` role, you must run these commands on GKE clusters before you can register them. To learn more about role-based access control for GKE, please see [the official Google documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control).

 ### EKS, AKS and GKE Clusters

-EKS, AKS and GKE clusters must have at least one managed node group to be imported into Rancher or provisioned from Rancher successfully.
+To successfully import them into or provision them from Rancher, Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE) clusters must have at least one managed node group.

 ## Registering a Cluster

@@ -126,15 +122,13 @@ When an RKE2 or K3s cluster is registered in Rancher, Rancher will recognize it.
 - The ability to configure the maximum number of nodes that will be upgraded concurrently
 - The ability to see a read-only version of the cluster's configuration arguments and environment variables used to launch each node in the cluster

-### Additional Features for Registered EKS, AKS and GKE Clusters
+### Additional Features for Registered EKS, AKS, and GKE Clusters

-Registering an Amazon EKS, Azure AKS or GKE cluster allows Rancher to treat it as though it were created in Rancher.
+Rancher handles registered EKS, AKS, or GKE clusters similarly to clusters created in Rancher. However, Rancher doesn't destroy registered clusters when you delete them through the Rancher UI.

-Amazon EKS, Azure AKS and GKE clusters can now be registered in Rancher. For the most part, these registered clusters are treated the same way as clusters created in the Rancher UI, except for deletion.
+When you create an EKS, AKS, or GKE cluster in Rancher, then delete it, Rancher destroys the cluster. When you delete a registered cluster through Rancher, the Rancher server _disconnects_ from the cluster. The cluster remains live, although it's no longer in Rancher. You can still access the deregistered cluster in the same way you did before you registered it.

-When you delete an EKS, AKS or GKE cluster that was created in Rancher, the cluster is destroyed. When you delete a cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists, and you can still access it in the same way you did before it was registered in Rancher.
-
-The capabilities for registered clusters are listed in the table on [this page.](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)
+See [Cluster Management Capabilities by Cluster Type](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) for more information about what features are available for managing registered clusters.

 ## Configuring RKE2 and K3s Cluster Upgrades

@@ -1,5 +1,5 @@
 ---
-title: Additional Steps for Installing Istio on an RKE2 Cluster
+title: Additional Steps for Installing Istio on RKE2 and K3s Clusters
 ---

 When installing or upgrading the Istio Helm chart through **Apps,**
@@ -8,30 +8,53 @@ When installing or upgrading the Istio Helm chart through **Apps,**
 1. You will see options for configuring the Istio Helm chart. On the **Components** tab, check the box next to **Enabled CNI**.
 1. Add a custom overlay file specifying `cniBinDir` and `cniConfDir`. For more information on these options, refer to the [Istio documentation.](https://istio.io/latest/docs/setup/additional-setup/cni/#helm-chart-parameters) An example is below:

-    ```yaml
-    apiVersion: install.istio.io/v1alpha1
-    kind: IstioOperator
-    spec:
-      components:
-        cni:
-          enabled: true
-          k8s:
-            overlays:
-            - apiVersion: "apps/v1"
-              kind: "DaemonSet"
-              name: "istio-cni-node"
-              patches:
-              - path: spec.template.spec.containers.[name:install-cni].securityContext.privileged
-                value: true
-      values:
-        cni:
-          image: rancher/mirrored-istio-install-cni:1.9.3
-          excludeNamespaces:
-            - istio-system
-            - kube-system
-          logLevel: info
-          cniBinDir: /opt/cni/bin
-          cniConfDir: /etc/cni/net.d
-    ```
+<Tabs>
+<TabItem value="RKE2">
+
+```yaml
+apiVersion: install.istio.io/v1alpha1
+kind: IstioOperator
+spec:
+  components:
+    cni:
+      enabled: true
+      k8s:
+        overlays:
+        - apiVersion: "apps/v1"
+          kind: "DaemonSet"
+          name: "istio-cni-node"
+          patches:
+          - path: spec.template.spec.containers.[name:install-cni].securityContext.privileged
+            value: true
+  values:
+    cni:
+      cniBinDir: /opt/cni/bin
+      cniConfDir: /etc/cni/net.d
+```
+</TabItem>
+<TabItem value="K3s">
+
+```yaml
+apiVersion: install.istio.io/v1alpha1
+kind: IstioOperator
+spec:
+  components:
+    cni:
+      enabled: true
+      k8s:
+        overlays:
+        - apiVersion: "apps/v1"
+          kind: "DaemonSet"
+          name: "istio-cni-node"
+          patches:
+          - path: spec.template.spec.containers.[name:install-cni].securityContext.privileged
+            value: true
+  values:
+    cni:
+      cniBinDir: /var/lib/rancher/k3s/data/current/bin
+      cniConfDir: /var/lib/rancher/k3s/agent/etc/cni/net.d
+```
+</TabItem>
+</Tabs>

 **Result:** Now you should be able to utilize Istio as desired, including sidecar injection and monitoring via Kiali.
@@ -31,7 +31,7 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:

 1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.

-1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-structure/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
+1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.

 1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.

@@ -41,7 +41,7 @@ For details on support for clusters with Windows nodes, see [this page](../integ

 ## GitHub Repository

-The Fleet Helm charts are available [here](https://github.com/rancher/fleet/releases/tag/v0.3.10).
+The Fleet Helm charts are available [here](https://github.com/rancher/fleet/releases).

 ## Using Fleet Behind a Proxy

@@ -17,13 +17,13 @@ See our page on [best practices](../reference-guides/best-practices/rancher-serv

 ## Kubernetes Compatibility with Rancher

-Rancher needs to be installed on a supported Kubernetes version. Consult the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix) to ensure that your intended version of Kubernetes is supported.
+Rancher needs to be installed on a supported Kubernetes version. Consult the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions) to ensure that your intended version of Kubernetes is supported.

 ## Operating Systems and Container Runtime Requirements

 All supported operating systems are 64-bit x86. Rancher should work with any modern Linux distribution.

-The [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix) lists which OS and Docker versions were tested for each Rancher version.
+The [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions) lists which OS and Docker versions were tested for each Rancher version.

 Docker is required for nodes that will run RKE clusters. It is not required for RKE2 or K3s clusters.

@@ -45,7 +45,7 @@ For more information see [Installing Docker,](../getting-started/installation-an

 For the container runtime, K3s bundles its own containerd by default. Alternatively, you can configure K3s to use an already installed Docker runtime. For more information on using K3s with Docker see the [K3s documentation.](https://docs.k3s.io/advanced#using-docker-as-the-container-runtime)

-Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix). To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script.
+Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions). To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script.

 If you are installing Rancher on a K3s cluster with **Raspbian Buster**, follow [these steps](https://rancher.com/docs/k3s/latest/en/advanced/#enabling-legacy-iptables-on-raspbian-buster) to switch to legacy iptables.

@@ -55,7 +55,7 @@ If you are installing Rancher on a K3s cluster with Alpine Linux, follow [these

 For the container runtime, RKE2 bundles its own containerd. Docker is not required for RKE2 installs.

-For details on which OS versions were tested with RKE2, refer to the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix).
+For details on which OS versions were tested with RKE2, refer to the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions).

 ## Hardware Requirements

@@ -14,18 +14,16 @@ By viewing data that Prometheus scrapes from your cluster control plane, nodes,

 The `rancher-monitoring` operator, introduced in Rancher v2.5, is powered by [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/grafana/),  [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/), the [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator), and the [Prometheus adapter.](https://github.com/DirectXMan12/k8s-prometheus-adapter)

-The monitoring application allows you to:
+The monitoring application:

- Monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments
- Define alerts based on metrics collected via Prometheus
- Create custom Grafana dashboards
- Configure alert-based notifications via Email, Slack, PagerDuty, etc. using Prometheus Alertmanager
- Defines precomputed, frequently needed or computationally expensive expressions as new time series based on metrics collected via Prometheus
- Expose collected metrics from Prometheus to the Kubernetes Custom Metrics API via Prometheus Adapter for use in HPA
+- Monitors the state and processes of your cluster nodes, Kubernetes components, and software deployments.
+- Defines alerts based on metrics collected via Prometheus.
+- Creates custom Grafana dashboards.
+- Configures alert-based notifications via email, Slack, PagerDuty, etc. using Prometheus Alertmanager.
+- Defines precomputed, frequently needed or computationally expensive expressions as new time series based on metrics collected via Prometheus.
+- Exposes collected metrics from Prometheus to the Kubernetes Custom Metrics API via Prometheus Adapter for use in HPA.

-## How Monitoring Works
-
-For an explanation of how the monitoring components work together, see [this page.](../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)
+See [How Monitoring Works](../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md) for an explanation of how the monitoring components work together.

 ## Default Components and Deployments

@@ -65,7 +63,7 @@ For information on configuring access to monitoring, see [this page.](../integra

 ### Configuring Monitoring Resources in Rancher

-> The configuration reference assumes familiarity with how monitoring components work together. For more information, see [How Monitoring Works.](../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)
+The configuration reference assumes familiarity with how monitoring components work together. For more information, see [How Monitoring Works.](../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)

 - [ServiceMonitor and PodMonitor](../reference-guides/monitoring-v2-configuration/servicemonitors-and-podmonitors.md)
 - [Receiver](../reference-guides/monitoring-v2-configuration/receivers.md)
@@ -76,7 +74,7 @@ For information on configuring access to monitoring, see [this page.](../integra

 ### Configuring Helm Chart Options

-For more information on `rancher-monitoring` chart options, including options to set resource limits and requests, see [this page.](../reference-guides/monitoring-v2-configuration/helm-chart-options.md)
+For more information on `rancher-monitoring` chart options, including options to set resource limits and requests, see [Helm Chart Options](../reference-guides/monitoring-v2-configuration/helm-chart-options.md).

 ## Windows Cluster Support

@@ -84,11 +82,11 @@ When deployed onto an RKE1 Windows cluster, Monitoring V2 will now automatically

 To be able to fully deploy Monitoring V2 for Windows, all of your Windows hosts must have a minimum [wins](https://github.com/rancher/wins) version of v0.1.0.

-For more details on how to upgrade wins on existing Windows hosts, refer to the section on [Windows cluster support for Monitoring V2.](../integrations-in-rancher/monitoring-and-alerting/windows-support.md)
+For more details on how to upgrade wins on existing Windows hosts, see [Windows cluster support for Monitoring V2.](../integrations-in-rancher/monitoring-and-alerting/windows-support.md).


 ## Known Issues

-There is a [known issue](https://github.com/rancher/rancher/issues/28787#issuecomment-693611821) that K3s clusters require more default memory. If you are enabling monitoring on a K3s cluster, we recommend to setting `prometheus.prometheusSpec.resources.memory.limit` to 2500 Mi and `prometheus.prometheusSpec.resources.memory.request` to 1750 Mi.
+There is a [known issue](https://github.com/rancher/rancher/issues/28787#issuecomment-693611821) that K3s clusters require more than the allotted default memory. If you enable monitoring on a K3s cluster, set `prometheus.prometheusSpec.resources.memory.limit` to 2500 Mi and `prometheus.prometheusSpec.resources.memory.request` to 1750 Mi.

-For tips on debugging high memory usage, see [this page.](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/debug-high-memory-usage.md)
+See [Debugging High Memory Usage](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/debug-high-memory-usage.md) for advice and recommendations.
@@ -54,7 +54,7 @@ We provide two RPMs (Red Hat packages) that enable Rancher products to function

 The Rancher Hardening Guide is based on controls and best practices found in the <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a> from the Center for Internet Security.

-The hardening guides provide prescriptive guidance for hardening a production installation of Rancher. See Rancher's guides for [Self Assessment of the CIS Kubernetes Benchmark](#the-cis-benchmark-and-self-sssessment) for the full list of security controls.
+The hardening guides provide prescriptive guidance for hardening a production installation of Rancher. See Rancher's guides for [Self Assessment of the CIS Kubernetes Benchmark](#the-cis-benchmark-and-self-assessment) for the full list of security controls.

 > The hardening guides describe how to secure the nodes in your cluster, and it is recommended to follow a hardening guide before installing Kubernetes.

@@ -72,7 +72,7 @@ By default, Rancher tries to run the Docker Install script when provisioning RKE

 #### Node Pool Taints

-If you haven't defined [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) on your node template, you can add taints for each node pool. The benefit of adding taints at a node pool is beneficial over adding it at a node template is that you can swap out the node templates without worrying if the taint is on the node template.
+If you haven't defined [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) on your node template, you can add taints for each node pool. The benefit of adding taints to a node pool is that you can change the node template without having to first ensure that the taint exists in the new template.

 For each taint, they will automatically be added to any created node in the node pool. Therefore, if you add taints to a node pool that have existing nodes, the taints won't apply to existing nodes in the node pool, but any new node added into the node pool will get the taint.

@@ -149,4 +149,4 @@ In our [recommended cluster architecture](../how-to-guides/new-user-guides/kuber

 - At least three nodes with the role etcd to survive losing one node
 - At least two nodes with the role controlplane for master component high availability
- At least two nodes with the role worker for workload rescheduling upon node failure
+- At least two nodes with the role worker for workload rescheduling upon node failure