mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Merge pull request #815 from btat/broken-links-2023-08
Fix broken links across versions
This commit is contained in:
+57
-73
@@ -6,40 +6,38 @@ See the [Logging operator documentation](https://kube-logging.github.io/docs/con
|
||||
|
||||
See [Rancher Integration with Logging Services: Troubleshooting](../../../../pages-for-subheaders/logging.md#The-Logging-Buffer-Overloads-Pods) for how to resolve memory problems with the logging buffer.
|
||||
|
||||
- [Configuration](#configuration)
|
||||
- [YAML Example](#yaml-example)
|
||||
|
||||
## Configuration
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
- [Flows](#flows-2-5-8)
|
||||
- [Matches](#matches-2-5-8)
|
||||
- [Filters](#filters-2-5-8)
|
||||
- [Outputs](#outputs-2-5-8)
|
||||
- [ClusterFlows](#clusterflows-2-5-8)
|
||||
|
||||
## Changes in v2.5.8
|
||||
|
||||
The `Flows` and `ClusterFlows` can now be configured by filling out forms in the Rancher UI.
|
||||
|
||||
|
||||
<a id="flows-2-5-8"></a>
|
||||
|
||||
## Flows
|
||||
|
||||
A `Flow` defines which logs to collect and filter and which output to send the logs to.
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.
|
||||
A `Flow` defines which logs to collect and filter and which `Output` to send the logs to. The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.
|
||||
|
||||
For more details about the `Flow` custom resource, see [FlowSpec.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/flow_types/)
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
<a id="matches-2-5-8"></a>
|
||||
A `Flow` defines which logs to collect and filter and which `Output` to send the logs to. The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.
|
||||
|
||||
`Flows` need to be defined in YAML.
|
||||
|
||||
For more details about the `Flow` custom resource, see [FlowSpec.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/flow_types/)
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Matches
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
Match statements are used to select which containers to pull logs from.
|
||||
|
||||
You can specify match statements to select or exclude logs according to Kubernetes labels, container and host names. Match statements are evaluated in the order they are defined and processed only until the first matching select or exclude rule applies.
|
||||
@@ -48,84 +46,70 @@ Matches can be configured by filling out the `Flow` or `ClusterFlow` forms in th
|
||||
|
||||
For detailed examples on using the match statement, see the [official documentation on log routing.](https://kube-logging.github.io/docs/configuration/log-routing/)
|
||||
|
||||
<a id="filters-2-5-8"></a>
|
||||
|
||||
### Filters
|
||||
|
||||
You can define one or more filters within a `Flow`. Filters can perform various actions on the logs, for example, add additional data, transform the logs, or parse values from the records. The filters in the `Flow` are applied in the order in the definition.
|
||||
|
||||
For a list of filters supported by the Logging operator, see [the official documentation on Fluentd filters](https://kube-logging.github.io/docs/configuration/plugins/filters/).
|
||||
|
||||
Filters need to be configured in YAML.
|
||||
|
||||
<a id="outputs-2-5-8"></a>
|
||||
|
||||
### Outputs
|
||||
|
||||
This `Output` will receive logs from the `Flow`. Because the `Flow` is a namespaced resource, the `Output` must reside in same namespace as the `Flow`.
|
||||
|
||||
`Outputs` can be referenced when filling out the `Flow` or `ClusterFlow` forms in the Rancher UI.
|
||||
|
||||
<a id="clusterflows-2-5-8"></a>
|
||||
|
||||
## ClusterFlows
|
||||
|
||||
Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way that they are configured for `Flows`. The key difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces.
|
||||
|
||||
After `ClusterFlow` selects logs from all namespaces in the cluster, logs from the cluster will be collected and logged to the selected `ClusterOutput`.
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
- [Flows](#flows-2-5-0)
|
||||
- [Matches](#matches-2-5-0)
|
||||
- [Filters](#filters-2-5-0)
|
||||
- [Outputs](#outputs-2-5-0)
|
||||
- [ClusterFlows](#clusterflows-2-5-0)
|
||||
|
||||
|
||||
<a id="flows-2-5-0"></a>
|
||||
|
||||
## Flows
|
||||
|
||||
A `Flow` defines which logs to collect and filter and which `Output` to send the logs to. The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.
|
||||
|
||||
`Flows` need to be defined in YAML.
|
||||
|
||||
For more details about the `Flow` custom resource, see [FlowSpec.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/flow_types/)
|
||||
|
||||
|
||||
<a id="matches-2-5-0"></a>
|
||||
|
||||
### Matches
|
||||
|
||||
Match statements are used to select which containers to pull logs from.
|
||||
|
||||
You can specify match statements to select or exclude logs according to Kubernetes labels, container and host names. Match statements are evaluated in the order they are defined and processed only until the first matching select or exclude rule applies.
|
||||
|
||||
For detailed examples on using the match statement, see the [official documentation on log routing.](https://kube-logging.github.io/docs/configuration/log-routing/)
|
||||
|
||||
<a id="filters-2-5-0"></a>
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Filters
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
You can define one or more filters within a `Flow`. Filters can perform various actions on the logs, for example, add additional data, transform the logs, or parse values from the records. The filters in the `Flow` are applied in the order in the definition.
|
||||
|
||||
For a list of filters supported by the Logging operator, see [the official documentation on Fluentd filters](https://kube-logging.github.io/docs/configuration/plugins/filters/).
|
||||
|
||||
Filters need to be configured in YAML.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
### Filters
|
||||
|
||||
You can define one or more filters within a `Flow`. Filters can perform various actions on the logs, for example, add additional data, transform the logs, or parse values from the records. The filters in the `Flow` are applied in the order in the definition.
|
||||
|
||||
For a list of filters supported by the Logging operator, see [this page.](https://kube-logging.github.io/docs/configuration/plugins/filters/)
|
||||
For a list of filters supported by the Logging operator, see [the official documentation on Fluentd filters](https://kube-logging.github.io/docs/configuration/plugins/filters/).
|
||||
|
||||
<a id="outputs-2-5-0"></a>
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Outputs
|
||||
|
||||
This `Output` will receive logs from the `Flow`.
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
Because the `Flow` is a namespaced resource, the `Output` must reside in same namespace as the `Flow`.
|
||||
This `Output` will receive logs from the `Flow`. Because the `Flow` is a namespaced resource, the `Output` must reside in same namespace as the `Flow`.
|
||||
|
||||
<a id="clusterflows-2-5-0"></a>
|
||||
`Outputs` can be referenced when filling out the `Flow` or `ClusterFlow` forms in the Rancher UI.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
This `Output` will receive logs from the `Flow`. Because the `Flow` is a namespaced resource, the `Output` must reside in same namespace as the `Flow`.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## ClusterFlows
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way that they are configured for `Flows`. The key difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces.
|
||||
|
||||
After `ClusterFlow` selects logs from all namespaces in the cluster, logs from the cluster will be collected and logged to the selected `ClusterOutput`.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
Matches, filters and `Outputs` are also configured for `ClusterFlows`. The only difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces.
|
||||
|
||||
`ClusterFlow` selects logs from all namespaces in the cluster. Logs from the cluster will be collected and logged to the selected `ClusterOutput`.
|
||||
|
||||
+17
-39
@@ -6,23 +6,13 @@ See the [Logging operator documentation](https://kube-logging.github.io/docs/con
|
||||
|
||||
See [Rancher Integration with Logging Services: Troubleshooting](../../../../pages-for-subheaders/logging.md#The-Logging-Buffer-Overloads-Pods) for how to resolve memory problems with the logging buffer.
|
||||
|
||||
## Configuration
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v2.5.8+">
|
||||
|
||||
- [Outputs](#outputs-2-5-8)
|
||||
- [ClusterOutputs](#clusteroutputs-2-5-8)
|
||||
|
||||
## Changes in v2.5.8
|
||||
|
||||
The `Outputs` and `ClusterOutputs` can now be configured by filling out forms in the Rancher UI.
|
||||
|
||||
|
||||
<a id="outputs-2-5-8"></a>
|
||||
|
||||
## Outputs
|
||||
|
||||
As of Rancher v2.5.8, the `Outputs` and `ClusterOutputs` can now be configured by filling out forms in the Rancher UI.
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.
|
||||
|
||||
The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.
|
||||
@@ -55,25 +45,9 @@ The Rancher UI provides forms for configuring the `Output` type, target, and acc
|
||||
|
||||
For example configuration for each logging plugin supported by the logging operator, see the [Logging operator documentation](https://kube-logging.github.io/docs/configuration/plugins/outputs/).
|
||||
|
||||
<a id="clusteroutputs-2-5-8"></a>
|
||||
|
||||
## ClusterOutputs
|
||||
|
||||
`ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator.
|
||||
|
||||
For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/clusteroutput_types/)
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
- [Outputs](#outputs-2-5-0)
|
||||
- [ClusterOutputs](#clusteroutputs-2-5-0)
|
||||
|
||||
|
||||
<a id="outputs-2-5-0"></a>
|
||||
|
||||
## Outputs
|
||||
|
||||
The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.
|
||||
|
||||
The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.
|
||||
@@ -84,10 +58,21 @@ You can use secrets in these definitions, but they must also be in the same name
|
||||
|
||||
For examples of configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://kube-logging.github.io/docs/configuration/plugins/outputs/)
|
||||
|
||||
<a id="clusteroutputs-2-5-0"></a>
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## ClusterOutputs
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
`ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator.
|
||||
|
||||
For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/clusteroutput_types/)
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
`ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator.
|
||||
|
||||
The Rancher UI provides forms for configuring the `ClusterOutput` type, target, and access credentials if applicable.
|
||||
@@ -99,16 +84,10 @@ For example configuration for each logging plugin supported by the logging opera
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## YAML Examples
|
||||
|
||||
Once logging is installed, you can use these examples to help craft your own logging pipeline.
|
||||
|
||||
- [Cluster Output to ElasticSearch](#cluster-output-to-elasticsearch)
|
||||
- [Output to Splunk](#output-to-splunk)
|
||||
- [Output to Syslog](#output-to-syslog)
|
||||
- [Unsupported Outputs](#unsupported-outputs)
|
||||
|
||||
### Cluster Output to ElasticSearch
|
||||
|
||||
Let's say you wanted to send all logs in your cluster to an `elasticsearch` cluster. First, we create a cluster `Output`.
|
||||
@@ -143,7 +122,6 @@ spec:
|
||||
|
||||
We should now see our configured index with logs in it.
|
||||
|
||||
|
||||
### Output to Splunk
|
||||
|
||||
What if we have an application team who only wants logs from a specific namespaces sent to a `splunk` server? For this case, we can use namespaced `Outputs` and `Flows`.
|
||||
|
||||
@@ -35,11 +35,11 @@ These instructions assume you are using Rancher v2.5, but Longhorn can be instal
|
||||
|
||||
### Installing Longhorn with Rancher
|
||||
|
||||
1. Fulfill all [Installation Requirements.](https://longhorn.io/docs/1.1.0/deploy/install/#installation-requirements)
|
||||
1. Fulfill all [Installation Requirements.](https://github.com/longhorn/website/blob/master/content/docs/archives/1.1.0/deploy/install/_index.md#installation-requirements)
|
||||
1. Go to the **Cluster Explorer** in the Rancher UI.
|
||||
1. Click **Apps.**
|
||||
1. Click `longhorn`.
|
||||
1. Optional: To customize the initial settings, click **Longhorn Default Settings** and edit the configuration. For help customizing the settings, refer to the [Longhorn documentation.](https://longhorn.io/docs/1.0.2/references/settings/)
|
||||
1. Optional: To customize the initial settings, click **Longhorn Default Settings** and edit the configuration. For help customizing the settings, refer to the [Longhorn documentation.](https://github.com/longhorn/website/blob/master/content/docs/archives/1.0.2/references/settings.md)
|
||||
1. Click **Install.**
|
||||
|
||||
**Result:** Longhorn is deployed in the Kubernetes cluster.
|
||||
|
||||
-4
@@ -6,10 +6,6 @@ _Available as of v2.5.8_
|
||||
|
||||
Starting at Monitoring V2 14.5.100 (used by default in Rancher 2.5.8), Monitoring V2 can now be deployed on a Windows cluster and will scrape metrics from Windows nodes using [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter) (previously named `wmi_exporter`).
|
||||
|
||||
- [Comparison to Monitoring V1](#comparison-to-monitoring-v1)
|
||||
- [Cluster Requirements](#cluster-requirements)
|
||||
- [Upgrading Existing Clusters to wins v0.1.0](#upgrading-existing-clusters-to-wins-v0-1-0)
|
||||
|
||||
## Comparison to Monitoring V1
|
||||
|
||||
Unlike Monitoring V1 for Windows, metrics collected by `windows_exporter` will be labeled as `windows_` instead of `wmi_` in accordance to a naming change from upstream from `wmi_exporter` to `windows_exporter`.
|
||||
|
||||
+1
-1
@@ -198,7 +198,7 @@ docker run -d --restart=unless-stopped \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
This layer 7 NGINX configuration is tested on NGINX version 1.13 (mainline) and 1.14 (stable).
|
||||
|
||||
|
||||
-4
@@ -6,10 +6,6 @@ title: Rollbacks
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks"/>
|
||||
</head>
|
||||
|
||||
- [Rolling Back to Rancher v2.5.0+](#rolling-back-to-rancher-v2-5-0)
|
||||
- [Rolling Back to Rancher v2.2-v2.4+](#rolling-back-to-rancher-v2-2-v2-4)
|
||||
- [Rolling Back to Rancher v2.0-v2.1](#rolling-back-to-rancher-v2-0-v2-1)
|
||||
|
||||
## Rolling Back to Rancher v2.5.0+
|
||||
|
||||
To roll back to Rancher v2.5.0+, use the **Rancher Backups** application and restore Rancher from backup.
|
||||
|
||||
-5
@@ -14,11 +14,6 @@ For the instructions to upgrade Rancher installed with Docker, refer to [this pa
|
||||
|
||||
To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Upgrade Outline](#upgrade-outline)
|
||||
- [Known Upgrade Issues](#known-upgrade-issues)
|
||||
- [RKE Add-on Installs](#rke-add-on-installs)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### Access to kubeconfig
|
||||
|
||||
+3
-3
@@ -40,7 +40,7 @@ Log into your Linux host, and then run the installation command below. When ente
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port. |
|
||||
| `<RANCHER_VERSION_TAG>` | The release tag of the [Rancher version](../../../../reference-guides/installation-references/helm-chart-options.md) that you want to install. |
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -77,7 +77,7 @@ After creating your certificate, log into your Linux host, and then run the inst
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port. |
|
||||
| `<RANCHER_VERSION_TAG>` | The release tag of the [Rancher version](../../../../reference-guides/installation-references/helm-chart-options.md) that you want to install. |
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -114,7 +114,7 @@ After obtaining your certificate, log into your Linux host, and then run the ins
|
||||
|
||||
> **Note:** Use the `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher.
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
|
||||
+1
-1
@@ -269,7 +269,7 @@ Copy the rendered manifest directories to a system that has access to the Ranche
|
||||
|
||||
Use `kubectl` to create namespaces and apply the rendered manifests.
|
||||
|
||||
If you choose to use self-signed certificates in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), install cert-manager.
|
||||
If you choose to use self-signed certificates in [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration), install cert-manager.
|
||||
|
||||
### For Self-Signed Certificate Installs, Install Cert-manager
|
||||
|
||||
|
||||
+1
-1
@@ -78,7 +78,7 @@ If you have issues upgrading Rancher, roll it back to its latest known healthy s
|
||||
--privileged \
|
||||
rancher/rancher:<PRIOR_RANCHER_VERSION>
|
||||
```
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
>**Note:** _Do not_ stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
|
||||
|
||||
|
||||
+8
-8
@@ -10,7 +10,7 @@ The following instructions will guide you through upgrading a Rancher server tha
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#known-upgrade-issues) in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12) Note that upgrades to or from any chart in the [rancher-alpha repository](../../../../reference-guides/installation-references/helm-chart-options.md#helm-chart-repositories/) aren’t supported.
|
||||
- **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#known-upgrade-issues) in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12) Note that upgrades to or from any chart in the [rancher-alpha repository](../../resources/choose-a-rancher-version.md#helm-chart-repositories) aren’t supported.
|
||||
- **For [air gap installs only,](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version.** Follow the guide to [populate your private registry](../air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
|
||||
|
||||
## Placeholder Review
|
||||
@@ -151,7 +151,7 @@ docker run -d --volumes-from rancher-data \
|
||||
rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
</details>
|
||||
|
||||
@@ -183,7 +183,7 @@ docker run -d --volumes-from rancher-data \
|
||||
rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
</details>
|
||||
|
||||
@@ -214,7 +214,7 @@ docker run -d --volumes-from rancher-data \
|
||||
--no-cacerts
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
</details>
|
||||
|
||||
### Option D: Let's Encrypt Certificate
|
||||
@@ -245,7 +245,7 @@ docker run -d --volumes-from rancher-data \
|
||||
--acme-domain <YOUR.DNS.NAME>
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
</details>
|
||||
|
||||
@@ -278,7 +278,7 @@ Placeholder | Description
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
</details>
|
||||
|
||||
### Option B: Bring Your Own Certificate: Self-Signed
|
||||
@@ -310,7 +310,7 @@ docker run -d --restart=unless-stopped \
|
||||
--privileged \
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
</details>
|
||||
|
||||
### Option C: Bring Your Own Certificate: Signed by Recognized CA
|
||||
@@ -344,7 +344,7 @@ docker run -d --volumes-from rancher-data \
|
||||
--privileged
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
</details>
|
||||
|
||||
</TabItem>
|
||||
|
||||
+6
-6
@@ -9,8 +9,8 @@ title: Upgrading Cert-Manager with Helm 2
|
||||
Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, three important changes to cert-manager are set to occur that you need to take action on if you have an HA deployment of Rancher:
|
||||
|
||||
1. [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
|
||||
1. [Cert-manager is deprecating and replacing the certificate.spec.acme.solvers field](https://docs.cert-manager.io/en/latest/tasks/upgrading/upgrading-0.7-0.8.html#upgrading-from-v0-7-to-v0-8). This change has no exact deadline.
|
||||
1. [Cert-manager is deprecating `v1alpha1` API and replacing its API group](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/)
|
||||
1. [Cert-manager is deprecating and replacing the certificate.spec.acme.solvers field](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8). This change has no exact deadline.
|
||||
1. [Cert-manager is deprecating `v1alpha1` API and replacing its API group](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11)
|
||||
|
||||
To address these changes, this guide will do two things:
|
||||
|
||||
@@ -157,12 +157,12 @@ cert-manager-webhook-5b5dd6999-kst4x 1/1 Running 0 3
|
||||
cert-manager-cainjector-3ba5cd2bcd-de332x 1/1 Running 0 3m
|
||||
```
|
||||
|
||||
If the ‘webhook’ pod (2nd line) is in a ContainerCreating state, it may still be waiting for the Secret to be mounted into the pod. Wait a couple of minutes for this to happen but if you experience problems, please check cert-manager's [troubleshooting](https://docs.cert-manager.io/en/latest/getting-started/troubleshooting.html) guide.
|
||||
If the ‘webhook’ pod (2nd line) is in a ContainerCreating state, it may still be waiting for the Secret to be mounted into the pod. Wait a couple of minutes for this to happen but if you experience problems, please check cert-manager's [troubleshooting](https://cert-manager.io/docs/troubleshooting/) guide.
|
||||
|
||||
> **Note:** The above instructions ask you to add the disable-validation label to the kube-system namespace. Here are additional resources that explain why this is necessary:
|
||||
>
|
||||
> - [Information on the disable-validation label](https://docs.cert-manager.io/en/latest/tasks/upgrading/upgrading-0.4-0.5.html?highlight=certmanager.k8s.io%2Fdisable-validation#disabling-resource-validation-on-the-cert-manager-namespace)
|
||||
> - [Information on webhook validation for certificates](https://docs.cert-manager.io/en/latest/getting-started/webhook.html)
|
||||
> - [Information on the disable-validation label](https://cert-manager.io/docs/installation/upgrading/upgrading-0.4-0.5#disabling-resource-validation-on-the-cert-manager-namespace)
|
||||
> - [Information on webhook validation for certificates](https://cert-manager.io/docs/concepts/webhook/)
|
||||
|
||||
## Cert-Manager API change and data migration
|
||||
|
||||
@@ -178,4 +178,4 @@ We have also removed support for the old configuration format that was deprecate
|
||||
|
||||
Details about the change and migration instructions can be found in the [cert-manager v0.10 to v0.11 upgrade instructions](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/).
|
||||
|
||||
For information on upgrading from all other versions of cert-manager, refer to the [official documentation](https://cert-manager.io/docs/installation/upgrading/).
|
||||
For information on upgrading from all other versions of cert-manager, refer to the [official documentation](https://cert-manager.io/docs/installation/upgrade/).
|
||||
|
||||
+1
-1
@@ -242,4 +242,4 @@ We have also removed support for the old configuration format that was deprecate
|
||||
|
||||
Details about the change and migration instructions can be found in the [cert-manager v0.10 to v0.11 upgrade instructions](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/).
|
||||
|
||||
More info about [cert-manager upgrade information](https://cert-manager.io/docs/installation/upgrading/).
|
||||
More info about [cert-manager upgrade information](https://cert-manager.io/docs/installation/upgrade/).
|
||||
|
||||
+2
-2
@@ -2,7 +2,7 @@
|
||||
title: Global Permissions
|
||||
---
|
||||
|
||||
<head>
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions"/>
|
||||
</head>
|
||||
|
||||
@@ -93,7 +93,7 @@ When a user logs into Rancher using an external authentication provider for the
|
||||
|
||||
To see the default permissions for new users, go to the **Global** view and click **Security > Roles.** On the **Global** tab, there is a column named **New User Default.** When adding a new local user, the user receives all default global permissions that are marked as checked in this column, and you can [change them to meet your needs.](#configuring-default-global-permissions)
|
||||
|
||||
Permissions can be assigned to an individual user with [these steps.](#configuring-global-permissions-for-existing-individual-users)
|
||||
Permissions can be assigned to an individual user with [these steps.](#configuring-global-permissions-for-individual-users)
|
||||
|
||||
You can [assign a role to everyone in the group at the same time](#configuring-global-permissions-for-groups) if the external authentication provider supports groups.
|
||||
|
||||
|
||||
+1
-1
@@ -21,7 +21,7 @@ The CIS Benchmark application supports two types of alerts:
|
||||
|
||||
Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../explanations/integrations-in-rancher/cis-scans/configuration-reference.md)
|
||||
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers/#example-route-config-for-cis-scan-alerts)
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-cis-scan-alerts)
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+2
-2
@@ -8,10 +8,10 @@ title: Enable Alerting for Rancher CIS Benchmark
|
||||
|
||||
Alerts can be configured to be sent out for a scan that runs on a schedule.
|
||||
|
||||
:::note Prerequisite:
|
||||
:::note Prerequisite:
|
||||
|
||||
Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../explanations/integrations-in-rancher/cis-scans/configuration-reference.md)
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers/#example-route-config-for-cis-scan-alerts)
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-cis-scan-alerts)
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -32,7 +32,7 @@ This second method, the capability to connect directly to the cluster's Kubernet
|
||||
|
||||
To use the authorized cluster endpoint, you will need to configure kubectl to use the extra kubectl context in the kubeconfig file that Rancher generates for you when the RKE cluster is created. This file can be downloaded from the cluster view in the Rancher UI, and the instructions for configuring kubectl are on [this page.](use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster)
|
||||
|
||||
These methods of communicating with downstream Kubernetes clusters are also explained in the [architecture page](../../../../pages-for-subheaders/rancher-manager-architecture.md#communicating-with-downstream-user-clusters) in the larger context of explaining how Rancher works and how Rancher communicates with downstream clusters.
|
||||
These methods of communicating with downstream Kubernetes clusters are also explained in the [architecture page](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md) in the larger context of explaining how Rancher works and how Rancher communicates with downstream clusters.
|
||||
|
||||
### About the kube-api-auth Authentication Webhook
|
||||
|
||||
|
||||
+1
-1
@@ -22,7 +22,7 @@ You can assign a pod security policy when you provision a cluster. However, if y
|
||||
|
||||
4. From the **Default Pod Security Policy** drop-down, select the policy you want to apply to the cluster.
|
||||
|
||||
Rancher ships with [policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#default-pod-security-policies) of `restricted` and `unrestricted`, although you can [create custom policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#default-pod-security-policies) as well.
|
||||
Rancher ships with [policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#default-psps) of `restricted` and `unrestricted`, although you can [create custom policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#creating-psps) as well.
|
||||
|
||||
5. Click **Save**.
|
||||
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ This section describes how to set up existing persistent storage for workloads i
|
||||
To set up storage, follow these steps:
|
||||
|
||||
1. [Set up persistent storage.](#1-set-up-persistent-storage)
|
||||
2. [Add a persistent volume that refers to the persistent storage.](#2-add-a-persistent-volume-that-refers-to-the-persistent-storage)
|
||||
2. [Add a persistent volume that refers to the persistent storage.](#2-add-a-persistentvolume-that-refers-to-the-persistent-storage)
|
||||
3. [Add a persistent volume claim that refers to the persistent volume.](#3-add-a-persistent-volume-claim-that-refers-to-the-persistent-volume)
|
||||
4. [Mount the persistent volume claim as a volume in your workload.](#4-mount-the-persistent-volume-claim-as-a-volume-in-your-workload)
|
||||
|
||||
|
||||
+1
-1
@@ -106,7 +106,7 @@ Standard users are only authorized for project access in two situations:
|
||||
|
||||
## Pod Security Policies
|
||||
|
||||
Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policluster-admin/pod-security-policy/) at the [project level](../manage-projects/manage-pod-security-policies.md) in addition to the [cluster level.](./add-a-pod-security-policy.md) However, as a best practice, we recommend applying Pod Security Policies at the cluster level.
|
||||
Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) at the [project level](../manage-projects/manage-pod-security-policies.md) in addition to the [cluster level.](./add-a-pod-security-policy.md) However, as a best practice, we recommend applying Pod Security Policies at the cluster level.
|
||||
|
||||
## Creating Projects
|
||||
|
||||
|
||||
+3
-4
@@ -8,7 +8,7 @@ If you previously enabled Monitoring, Alerting, or Notifiers in Rancher before v
|
||||
|
||||
As of v2.2.0, Rancher's Cluster Manager allowed users to enable Monitoring & Alerting V1 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) independently within a cluster.
|
||||
|
||||
When Monitoring is enabled, Monitoring V1 deploys [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/docs/grafana/latest/getting-started/what-is-grafana/) onto a cluster to monitor the state of processes of your cluster nodes, Kubernetes components, and software deployments and create custom dashboards to make it easy to visualize collected metrics.
|
||||
When Monitoring is enabled, Monitoring V1 deploys [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/docs/grafana/latest/introduction/) onto a cluster to monitor the state of processes of your cluster nodes, Kubernetes components, and software deployments and create custom dashboards to make it easy to visualize collected metrics.
|
||||
|
||||
Monitoring V1 could be configured on both a cluster-level and on a project-level and would automatically scrape certain workloads deployed as Apps on the Rancher cluster.
|
||||
|
||||
@@ -116,12 +116,11 @@ or add the Prometheus Rule through the Cluster Explorer
|
||||
|
||||

|
||||
|
||||
For more details on how to configure PrometheusRules in Monitoring V2 see [Monitoring Configuration](../../../pages-for-subheaders/monitoring-v2-configuration-guides.md#prometheusrules).
|
||||
For more details on how to configure PrometheusRules in Monitoring V2 see [Monitoring Configuration](../../advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheusrules.md).
|
||||
|
||||
### Migrating Notifiers
|
||||
|
||||
There is no direct equivalent for how notifiers work in Monitoring V1. Instead you have to replicate the desired setup with [Routes and Receivers](../../../pages-for-subheaders/monitoring-v2-configuration-guides.md#alertmanager-config) in Monitoring V2.
|
||||
|
||||
There is no direct equivalent for how notifiers work in Monitoring V1. Instead you have to replicate the desired setup with [Routes and Receivers](../../advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md) in Monitoring V2.
|
||||
|
||||
### Migrating for RKE Template Users
|
||||
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ It is usually not necessary to directly edit the Alertmanager custom resource. F
|
||||
|
||||
When Receivers and Routes are updated, the monitoring application will automatically update the Alertmanager custom resource to be consistent with those changes.
|
||||
|
||||
> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../../../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#how-alertmanager-works)
|
||||
> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../../../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#3-how-alertmanager-works)
|
||||
|
||||
## About the Alertmanager Custom Resource
|
||||
|
||||
|
||||
+1
-1
@@ -93,7 +93,7 @@ spec:
|
||||
|
||||
### 3. Install cert-manager
|
||||
|
||||
Follow the steps to [install cert-manager](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#5-install-cert-manager) in the documentation about installing cert-manager on Kubernetes.
|
||||
Follow the steps to [install cert-manager](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#4-install-cert-manager) in the documentation about installing cert-manager on Kubernetes.
|
||||
|
||||
### 4. Bring up Rancher with Helm
|
||||
|
||||
|
||||
+1
-1
@@ -4,7 +4,7 @@ title: Setting up the Google Compute Engine Cloud Provider
|
||||
|
||||
In this section, you'll learn how to enable the Google Compute Engine (GCE) cloud provider for custom clusters in Rancher. A custom cluster is one in which Rancher installs Kubernetes on existing nodes.
|
||||
|
||||
The official Kubernetes documentation for the GCE cloud provider is [here.](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#gce)
|
||||
The official Kubernetes documentation for the GCE cloud provider is [here.](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md#gce)
|
||||
|
||||
> **Prerequisites:** The service account of `Identity and API` access on GCE needs the `Computer Admin` permission.
|
||||
|
||||
|
||||
+3
-36
@@ -151,19 +151,10 @@ resource "rancher2_cluster" "my-eks-to-import" {
|
||||
|
||||
The control that Rancher has to manage a registered cluster depends on the type of cluster.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
- [Changes in v2.5.8](#changes-in-v2-5-8)
|
||||
- [Features for All Registered Clusters](#2-5-8-features-for-all-registered-clusters)
|
||||
- [Additional Features for Registered K3s Clusters](#2-5-8-additional-features-for-registered-k3s-clusters)
|
||||
- [Additional Features for Registered EKS and GKE Clusters](#additional-features-for-registered-eks-and-gke-clusters)
|
||||
|
||||
### Changes in v2.5.8
|
||||
|
||||
Greater management capabilities are now available for [registered GKE clusters.](#additional-features-for-registered-eks-and-gke-clusters) The same configuration options are available for registered GKE clusters as for the GKE clusters created through the Rancher UI.
|
||||
|
||||
<a id="2-5-8-features-for-all-registered-clusters"></a>
|
||||
### Features for All Registered Clusters
|
||||
|
||||
After registering a cluster, the cluster owner can:
|
||||
@@ -174,7 +165,6 @@ After registering a cluster, the cluster owner can:
|
||||
- Enable [Istio](../../../pages-for-subheaders/istio.md)
|
||||
- Manage projects and workloads
|
||||
|
||||
<a id="2-5-8-additional-features-for-registered-k3s-clusters"></a>
|
||||
### Additional Features for Registered K3s Clusters
|
||||
|
||||
[K3s](https://rancher.com/docs/k3s/latest/en/) is a lightweight, fully compliant Kubernetes distribution.
|
||||
@@ -185,6 +175,9 @@ When a K3s cluster is registered in Rancher, Rancher will recognize it as K3s. T
|
||||
- The ability to configure the maximum number of nodes that will be upgraded concurrently
|
||||
- The ability to see a read-only version of the K3s cluster's configuration arguments and environment variables used to launch each node in the cluster
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
### Additional Features for Registered EKS and GKE Clusters
|
||||
|
||||
Registering an Amazon EKS cluster or GKE cluster allows Rancher to treat it as though it were created in Rancher.
|
||||
@@ -198,32 +191,6 @@ The capabilities for registered clusters are listed in the table on [this page.]
|
||||
</TabItem>
|
||||
<TabItem value="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)
|
||||
- [Additional Features for Registered EKS Clusters](#additional-features-for-registered-eks-clusters)
|
||||
|
||||
<a id="before-2-5-8-features-for-all-registered-clusters"></a>
|
||||
### Features for All Registered Clusters
|
||||
|
||||
After registering a cluster, the cluster owner can:
|
||||
|
||||
- [Manage cluster access](../../advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md) through role-based access control
|
||||
- Enable [monitoring, alerts and notifiers](../../../pages-for-subheaders/monitoring-and-alerting.md)
|
||||
- Enable [logging](../../../pages-for-subheaders/logging.md)
|
||||
- Enable [Istio](../../../pages-for-subheaders/istio.md)
|
||||
- Manage projects and workloads
|
||||
|
||||
<a id="before-2-5-8-additional-features-for-registered-k3s-clusters"></a>
|
||||
### Additional Features for Registered K3s Clusters
|
||||
|
||||
[K3s](https://rancher.com/docs/k3s/latest/en/) is a lightweight, fully compliant Kubernetes distribution.
|
||||
|
||||
When a K3s cluster is registered in Rancher, Rancher will recognize it as K3s. The Rancher UI will expose the features for [all registered clusters,](#features-for-all-registered-clusters) in addition to the following features for editing and upgrading the cluster:
|
||||
|
||||
- The ability to [upgrade the K3s version](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)
|
||||
- The ability to configure the maximum number of nodes that will be upgraded concurrently
|
||||
- The ability to see a read-only version of the K3s cluster's configuration arguments and environment variables used to launch each node in the cluster
|
||||
|
||||
### Additional Features for Registered EKS Clusters
|
||||
|
||||
Registering an Amazon EKS cluster allows Rancher to treat it as though it were created in Rancher.
|
||||
|
||||
+1
-1
@@ -136,7 +136,7 @@ Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
>**Note:** After submitting your private key, you may have to enable the Google Kubernetes Engine API. If prompted, browse to the URL displayed in the Rancher UI to enable the API.
|
||||
|
||||
6. Select your cluster options, node options and security options. For help, refer to the [GKE Cluster Configuration Reference.](#gke-before-v2-5-8)
|
||||
6. Select your cluster options, node options and security options. For help, refer to the [GKE Cluster Configuration Reference.](../../../../pages-for-subheaders/gke-cluster-configuration.md)
|
||||
9. Review your options to confirm they're correct. Then click **Create**.
|
||||
|
||||
**Result:** You have successfully deployed a GKE cluster.
|
||||
|
||||
+1
-1
@@ -21,7 +21,7 @@ Ingress can be added for workloads to provide load balancing, SSL termination an
|
||||
|
||||
## Ingress Rule Configuration
|
||||
|
||||
- [Automatically generate a sslip.io hostname](#automatically-generate-a-sslip-io-hostname)
|
||||
- [Automatically generate a sslip.io hostname](#automatically-generate-a-sslipio-hostname)
|
||||
- [Specify a hostname to use](#specify-a-hostname-to-use)
|
||||
- [Use as the default backend](#use-as-the-default-backend)
|
||||
- [Certificates](#certificates)
|
||||
|
||||
+1
-1
@@ -45,7 +45,7 @@ Deploy a workload to run an application in one or more containers.
|
||||
>
|
||||
>- In [Amazon AWS](https://aws.amazon.com/), the nodes must be in the same Availability Zone and possess IAM permissions to attach/unattach volumes.
|
||||
>
|
||||
>- The cluster must be using the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws) option. For more information on enabling this option see [Creating an Amazon EC2 Cluster](../../kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) or [Creating a Custom Cluster](../../../../pages-for-subheaders/use-existing-nodes.md).
|
||||
>- The cluster must be using the [AWS cloud provider](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md#aws) option. For more information on enabling this option see [Creating an Amazon EC2 Cluster](../../kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) or [Creating a Custom Cluster](../../../../pages-for-subheaders/use-existing-nodes.md).
|
||||
|
||||
|
||||
1. Click **Show Advanced Options** and configure:
|
||||
|
||||
@@ -15,9 +15,7 @@ Use the navigation bar on the left to find the current best practices for managi
|
||||
For more guidance on best practices, you can consult these resources:
|
||||
|
||||
- [Security](rancher-security.md)
|
||||
- [Rancher Blog](https://rancher.com/blog/)
|
||||
- [Articles about best practices on the Rancher blog](https://rancher.com/tags/best-practices/)
|
||||
- [101 More Security Best Practices for Kubernetes](https://rancher.com/blog/2019/2019-01-17-101-more-kubernetes-security-best-practices/)
|
||||
- [Rancher Blog](https://www.suse.com/c/rancherblog/)
|
||||
- [Rancher Forum](https://forums.rancher.com/)
|
||||
- [Rancher Users Slack](https://slack.rancher.io/)
|
||||
- [Rancher Labs YouTube Channel - Online Meetups, Demos, Training, and Webinars](https://www.youtube.com/channel/UCh5Xtp82q8wjijP8npkVTBA/featured)
|
||||
|
||||
+2
-2
@@ -108,8 +108,8 @@ There are three recommended options for the source of the certificate used for T
|
||||
|
||||
| Configuration | Helm Chart Option | Requires cert-manager |
|
||||
| ------------------------------ | ----------------------- | ------------------------------------- |
|
||||
| Rancher Generated Certificates (Default) | `ingress.tls.source=rancher` | [yes](#5-install-cert-manager) |
|
||||
| Let’s Encrypt | `ingress.tls.source=letsEncrypt` | [yes](#5-install-cert-manager) |
|
||||
| Rancher Generated Certificates (Default) | `ingress.tls.source=rancher` | [yes](#4-install-cert-manager) |
|
||||
| Let’s Encrypt | `ingress.tls.source=letsEncrypt` | [yes](#4-install-cert-manager) |
|
||||
| Certificates from Files | `ingress.tls.source=secret` | no |
|
||||
|
||||
### 4. Install cert-manager
|
||||
|
||||
+4
-4
@@ -54,7 +54,7 @@ If you are installing Rancher in a development or testing environment where iden
|
||||
|
||||
Log into your Linux host, and then run the minimum installation command below.
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v25)
|
||||
|
||||
```bash
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -81,7 +81,7 @@ After creating your certificate, run the Docker command below to install Rancher
|
||||
| `<PRIVATE_KEY.pem>` | The path to the private key for your certificate. |
|
||||
| `<CA_CERTS.pem>` | The path to the certificate authority's certificate. |
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v25)
|
||||
|
||||
```bash
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -113,7 +113,7 @@ After obtaining your certificate, run the Docker command below.
|
||||
| `<FULL_CHAIN.pem>` | The path to your full certificate chain. |
|
||||
| `<PRIVATE_KEY.pem>` | The path to the private key for your certificate. |
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v25)
|
||||
|
||||
```bash
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -143,7 +143,7 @@ After you fulfill the prerequisites, you can install Rancher using a Let's Encry
|
||||
| ----------------- | ------------------- |
|
||||
| `<YOUR.DNS.NAME>` | Your domain address |
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v25)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
|
||||
@@ -29,8 +29,8 @@ Kubernetes v1.18+ | CIS v1.6 | [Link](../reference-guides/rancher-security/ranch
|
||||
|
||||
Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides
|
||||
---|---|---|---
|
||||
Kubernetes v1.18 | CIS v1.5 | [Link](https://docs.rke2.io/security/cis_self_assessment15/) | [Link](https://docs.rke2.io/security/hardening_guide/)
|
||||
Kubernetes v1.20 | CIS v1.6 | [Link](https://docs.rke2.io/security/cis_self_assessment16/) | [Link](https://docs.rke2.io/security/hardening_guide/)
|
||||
Kubernetes v1.18 | CIS v1.5 | [Link](https://github.com/rancher/rke2-docs/blob/f36b47ae8de3d859ae2db8ddf26beeb26c3e80b1/docs/security/cis_self_assessment15.md) | [Link](https://docs.rke2.io/security/hardening_guide)
|
||||
Kubernetes v1.20 | CIS v1.6 | [Link](https://docs.rke2.io/security/cis_self_assessment16) | [Link](https://docs.rke2.io/security/hardening_guide)
|
||||
|
||||
### K3s Guides
|
||||
|
||||
|
||||
@@ -59,7 +59,7 @@ Clusters won't begin provisioning until all three node roles (worker, etcd and c
|
||||
>- Using Windows nodes as Kubernetes workers? See [this section](use-windows-clusters.md).
|
||||
>- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
|
||||
|
||||
8. <a id="step-8"></a>**Optional**: Click **[Show advanced options](admin-settings/agent-options/)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
|
||||
8. <a id="step-8"></a>**Optional**: Click **[Show advanced options](../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
|
||||
|
||||
9. Copy the command displayed on screen to your clipboard.
|
||||
|
||||
@@ -87,7 +87,7 @@ If you have configured your cluster to use Amazon as **Cloud Provider**, tag you
|
||||
|
||||
[Amazon Documentation: Tagging Your Amazon EC2 Resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)
|
||||
|
||||
>**Note:** You can use Amazon EC2 instances without configuring a cloud provider in Kubernetes. You only have to configure the cloud provider if you want to use specific Kubernetes cloud provider functionality. For more information, see [Kubernetes Cloud Providers](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/)
|
||||
>**Note:** You can use Amazon EC2 instances without configuring a cloud provider in Kubernetes. You only have to configure the cloud provider if you want to use specific Kubernetes cloud provider functionality. For more information, see [Kubernetes Cloud Providers](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md)
|
||||
|
||||
|
||||
The following resources need to be tagged with a `ClusterID`:
|
||||
|
||||
@@ -15,7 +15,7 @@ Rancher can provision nodes in vSphere and install Kubernetes on them. When crea
|
||||
|
||||
A vSphere cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role.
|
||||
|
||||
- [vSphere Enhancements in Rancher v2.3](#vsphere-enhancements-in-rancher-v2-3)
|
||||
- [vSphere Enhancements in Rancher v2.3](#vsphere-enhancements-in-rancher-v23)
|
||||
- [Creating a vSphere Cluster](#creating-a-vsphere-cluster)
|
||||
- [Provisioning Storage](#provisioning-storage)
|
||||
- [Enabling the vSphere Cloud Provider](#enabling-the-vsphere-cloud-provider)
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ title: Logging Best Practices
|
||||
|
||||
In this guide, we recommend best practices for cluster-level logging and application logging.
|
||||
|
||||
- [Changes in Logging in Rancher v2.5](#changes-in-logging-in-rancher-v2-5)
|
||||
- [Changes in Logging in Rancher v2.5](#changes-in-logging-in-rancher-v25)
|
||||
- [Cluster-level Logging](#cluster-level-logging)
|
||||
- [Application Logging](#application-logging)
|
||||
- [General Best Practices](#general-best-practices)
|
||||
|
||||
@@ -33,4 +33,4 @@ This feature enables kubectl to authenticate with the Rancher server and get a n
|
||||
4. OpenLDAP
|
||||
5. SAML providers: Ping, Okta, ADFS, Keycloak, Shibboleth
|
||||
|
||||
When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server. The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../../reference-guides/about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens-period), or [gets deleted from the Rancher server](../../reference-guides/about-the-api/api-tokens.md#deleting-tokens). Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
|
||||
When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server. The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../../reference-guides/about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens), or [gets deleted from the Rancher server](../../reference-guides/about-the-api/api-tokens.md#deleting-tokens). Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
|
||||
+1
-1
@@ -39,7 +39,7 @@ node-taint:
|
||||
|
||||
## Customizing the RancherD Helm Chart
|
||||
|
||||
Rancher is launched as a [Helm](https://helm.sh/) chart using the cluster’s [Helm integration.](https://docs.rke2.io/helm/) This means that you can easily customize the application through a manifest file describing your custom parameters.
|
||||
Rancher is launched as a [Helm](https://helm.sh/) chart using the cluster’s [Helm integration.](https://docs.rke2.io/helm) This means that you can easily customize the application through a manifest file describing your custom parameters.
|
||||
|
||||
The RancherD chart provisions Rancher in a daemonset. It exposes hostport `8080/8443` down to the container port (`80/443`), and uses hostpath to mount certs if needed.
|
||||
|
||||
|
||||
+2
-2
@@ -2,7 +2,7 @@
|
||||
title: OpenLDAP Configuration Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-openldap/openldap-config-reference"/>
|
||||
</head>
|
||||
|
||||
@@ -12,7 +12,7 @@ For further details on configuring OpenLDAP authentication, refer to the [offici
|
||||
|
||||
- [Background: OpenLDAP Authentication Flow](#background-openldap-authentication-flow)
|
||||
- [OpenLDAP server configuration](#openldap-server-configuration)
|
||||
- [User/group schema configuration](#user-group-schema-configuration)
|
||||
- [User/group schema configuration](#usergroup-schema-configuration)
|
||||
- [User schema configuration](#user-schema-configuration)
|
||||
- [Group schema configuration](#group-schema-configuration)
|
||||
|
||||
|
||||
+1
-1
@@ -133,4 +133,4 @@ The GitHub repositories for Rancher can be found at the following links:
|
||||
- [Rancher CLI](https://github.com/rancher/cli)
|
||||
- [Catalog applications](https://github.com/rancher/helm)
|
||||
|
||||
This is a partial list of the most important Rancher repositories. For more details about Rancher source code, refer to the section on [contributing to Rancher.](../../contribute-to-rancher.md#rancher-repositories) To see all libraries and projects used in Rancher, see the [`go.mod` file](https://github.com/rancher/rancher/blob/master/go.mod) in the `rancher/rancher` repository.
|
||||
This is a partial list of the most important Rancher repositories. For more details about Rancher source code, refer to the section on [contributing to Rancher.](../../contribute-to-rancher.md#rancher-repositories) To see all libraries and projects used in Rancher, see the [`go.mod` file](https://github.com/rancher/rancher/blob/master/go.mod) in the `rancher/rancher` repository.
|
||||
|
||||
+6
-6
@@ -9,7 +9,7 @@ When installing Rancher, there are several [advanced options](../../pages-for-su
|
||||
- [TLS Settings](#tls-settings)
|
||||
- [Air Gap](#air-gap)
|
||||
- [Persistent Data](#persistent-data)
|
||||
- [Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node](#running-rancher-rancher-and-rancher-rancher-agent-on-the-same-node)
|
||||
- [Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node](#running-rancherrancher-and-rancherrancher-agent-on-the-same-node)
|
||||
|
||||
### Custom CA Certificate
|
||||
|
||||
@@ -24,7 +24,7 @@ Use the command example to start a Rancher container with your private CA certif
|
||||
|
||||
The example below is based on having the CA root certificates in the `/host/certs` directory on the host and mounting this directory on `/container/certs` inside the Rancher container.
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -43,7 +43,7 @@ The API Audit Log writes to `/var/log/auditlog` inside the rancher container by
|
||||
|
||||
See [API Audit Log](../../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/enable-api-audit-log.md) for more information and options.
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -66,7 +66,7 @@ docker run -d --restart=unless-stopped \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
See [TLS settings](../installation-references/tls-settings.md) for more information and options.
|
||||
|
||||
@@ -92,7 +92,7 @@ docker run -d --restart=unless-stopped \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
### Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node
|
||||
|
||||
@@ -111,4 +111,4 @@ docker run -d --restart=unless-stopped \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
+1
-1
@@ -38,4 +38,4 @@ docker run -d --restart=unless-stopped \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
@@ -41,7 +41,7 @@
|
||||
| [Managing Projects, Namespaces and Workloads](../how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Using App Catalogs](../pages-for-subheaders/helm-charts-in-rancher.md) | ✓ | ✓ | ✓ | ✓ |
|
||||
| Configuring Tools (Alerts, Notifiers, Logging, Monitoring, Istio) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Running Security Scans](security/security-scan/) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Running Security Scans](../pages-for-subheaders/cis-scans.md) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Use existing configuration to create additional clusters](../how-to-guides/advanced-user-guides/manage-clusters/clone-cluster-configuration.md)| ✓ | ✓ |✓ | |
|
||||
| [Ability to rotate certificates](../how-to-guides/advanced-user-guides/manage-clusters/rotate-certificates.md) | ✓ | | ✓ | |
|
||||
| Ability to [backup](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md) and [restore](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Rancher-launched clusters | ✓ | ✓ | | ✓<sup>3</sup> |
|
||||
|
||||
Reference in New Issue
Block a user