mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-12 12:07:20 +00:00
Update version labels
This commit is contained in:
Billy Tat
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Rancher 2.5.7-2.5.8+ (Latest)
|
||||
title: Rancher 2.5.7-2.5.9 (Latest)
|
||||
weight: 1
|
||||
showBreadcrumb: false
|
||||
---
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: "Rancher 2.5.7-2.5.8+ (Latest)"
|
||||
shortTitle: "Rancher 2.5.7-2.5.8+ (Latest)"
|
||||
title: "Rancher 2.5.7-2.5.9 (Latest)"
|
||||
shortTitle: "Rancher 2.5.7-2.5.9 (Latest)"
|
||||
description: "Rancher adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
|
||||
metaTitle: "Rancher 2.x Docs: What is New?"
|
||||
metaTitle: "Rancher 2.5.7-2.5.9 Docs: What is New?"
|
||||
metaDescription: "Rancher 2 adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
|
||||
insertOneSix: false
|
||||
weight: 1
|
||||
@@ -18,4 +18,4 @@ Rancher adds significant value on top of Kubernetes, first by centralizing authe
|
||||
|
||||
It then enables detailed monitoring and alerting for clusters and their resources, ships logs to external providers, and integrates directly with Helm via the Application Catalog. If you have an external CI/CD system, you can plug it into Rancher, but if you don't, Rancher even includes [Fleet](http://fleet.rancher.io/) to help you automatically deploy and upgrade workloads.
|
||||
|
||||
Rancher is a _complete_ container management platform for Kubernetes, giving you the tools to successfully run Kubernetes anywhere.
|
||||
Rancher is a _complete_ container management platform for Kubernetes, giving you the tools to successfully run Kubernetes anywhere.
|
||||
|
||||
+1
-1
@@ -5,7 +5,7 @@ weight: 3
|
||||
---
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "v2.5.8" %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
|
||||
# Changes in v2.5.8
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ headless: true
|
||||
---
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8" %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
|
||||
| Action | Rancher Launched Kubernetes Clusters | EKS and GKE Clusters* | Other Hosted Kubernetes Clusters | Non-EKS or GKE Registered Clusters |
|
||||
| --- | --- | ---| ---|----|
|
||||
@@ -30,7 +30,7 @@ headless: true
|
||||
\* \* \* For registered cluster nodes, the Rancher UI exposes the ability to cordon drain, and edit the node.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-v2.5.7" %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
|
||||
| Action | Rancher Launched Kubernetes Clusters | Hosted Kubernetes Clusters | Registered EKS Clusters | All Other Registered Clusters |
|
||||
| --- | --- | ---| ---|----|
|
||||
@@ -56,4 +56,4 @@ headless: true
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
@@ -125,7 +125,7 @@ The capabilities for registered clusters are listed in the table on [this page.]
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-v2.5.8" %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
|
||||
- [Features for All Registered Clusters](#before-2-5-8-features-for-all-registered-clusters)
|
||||
- [Additional Features for Registered K3s Clusters](#before-2-5-8-additional-features-for-registered-k3s-clusters)
|
||||
|
||||
+1
-1
@@ -137,7 +137,7 @@ Placeholder | Description
|
||||
`<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8" %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
```plain
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--no-hooks \ # prevent files for Helm hooks from being generated
|
||||
|
||||
@@ -77,7 +77,7 @@ Here is an example of a command for passing in the feature flag names when rende
|
||||
The Helm 3 command is as follows:
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8" %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
|
||||
```
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
|
||||
@@ -79,13 +79,13 @@ For a list of options that can be configured when the logging application is ins
|
||||
### Windows Support
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8" %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
As of Rancher v2.5.8, logging support for Windows clusters has been added and logs can be collected from Windows nodes.
|
||||
|
||||
For details on how to enable or disable Windows node logging, see [this section.](./helm-chart-options/#enable-disable-windows-node-logging)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-2.5.7" %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
Clusters with Windows workers support exporting logs from Linux nodes, but Windows node logs are currently unable to be exported.
|
||||
Only Linux node logs are able to be exported.
|
||||
|
||||
|
||||
@@ -74,7 +74,7 @@ Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way
|
||||
After `ClusterFlow` selects logs from all namespaces in the cluster, logs from the cluster will be collected and logged to the selected `ClusterOutput`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-v2.5.7" %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
|
||||
- [Flows](#flows-2-5-0)
|
||||
- [Matches](#matches-2-5-0)
|
||||
|
||||
@@ -69,7 +69,7 @@ For example configuration for each logging plugin supported by the logging opera
|
||||
For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "v2.5.0-v2.5.7" %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
|
||||
|
||||
- [Outputs](#outputs-2-5-0)
|
||||
@@ -343,4 +343,4 @@ spec:
|
||||
ignore_network_errors_at_startup: false
|
||||
```
|
||||
|
||||
Let's break down what is happening here. First, we create a deployment of a container that has the additional `syslog` plugin and accepts logs forwarded from another `fluentd`. Next we create an `Output` configured as a forwarder to our deployment. The deployment `fluentd` will then forward all logs to the configured `syslog` destination.
|
||||
Let's break down what is happening here. First, we create a deployment of a container that has the additional `syslog` plugin and accepts logs forwarded from another `fluentd`. Next we create an `Output` configured as a forwarder to our deployment. The deployment `fluentd` will then forward all logs to the configured `syslog` destination.
|
||||
|
||||
@@ -20,13 +20,13 @@ Both provide choice for the what node(s) the pod will run on.
|
||||
### Default Implementation in Rancher's Logging Stack
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8" %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
|
||||
The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
|
||||
Moreover, most logging stack pods run on Linux only and have a `nodeSelector` added to ensure they run on Linux nodes.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-2.5.7" %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
|
||||
The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
|
||||
Moreover, we can populate the `nodeSelector` to ensure that our pods *only* run on Linux nodes.
|
||||
@@ -74,4 +74,4 @@ However, if you would like to add tolerations for *only* the `fluentbit` contain
|
||||
```yaml
|
||||
fluentbit_tolerations:
|
||||
# insert tolerations list for fluentbit containers only...
|
||||
```
|
||||
```
|
||||
|
||||
@@ -63,7 +63,7 @@ As an [administrator]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/global-p
|
||||
> - 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`.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8" %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
|
||||
### Enable Monitoring for use without SSL
|
||||
|
||||
@@ -101,7 +101,7 @@ key.pfx=`base64-content`
|
||||
Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-2.5.7" %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
|
||||
1. In the Rancher UI, go to the cluster where you want to install monitoring and click **Cluster Explorer.**
|
||||
1. Click **Apps.**
|
||||
|
||||
@@ -91,7 +91,7 @@ Rancher v2.5.8 added Microsoft Teams and SMS as configurable receivers in the Ra
|
||||
Rancher v2.5.4 introduced the capability to configure receivers by filling out forms in the Rancher UI.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8" %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
|
||||
The following types of receivers can be configured in the Rancher UI:
|
||||
|
||||
|
||||
@@ -84,7 +84,7 @@ grafana.sidecar.dashboards.searchNamespace=ALL
|
||||
Note that the RBAC roles exposed by the Monitoring chart to add Grafana Dashboards are still restricted to giving permissions for users to add dashboards in the namespace defined in `grafana.dashboards.namespace`, which defaults to `cattle-dashboards`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-v2.5.8" %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - The monitoring application needs to be installed.
|
||||
|
||||
Reference in New Issue
Block a user