mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 04:58:07 +00:00
Merge branch 'main' into release/v2.7.2
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user