mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Merge pull request #859 from rancher/main
merge main into release branch to make reviewing certain PRs easier
This commit is contained in:
Billy Tat
@@ -4,13 +4,23 @@ about: For requesting new feature(s) to be added to the docs.
|
||||
title: ''
|
||||
labels: ''
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
**Summary:**
|
||||
## Related Issues
|
||||
|
||||
<!--
|
||||
List any issues or tickets on other platforms that are associated with the request. For example, include a link to the issue tracking that feature in the Rancher repo, or list the Jira ticket number for the request.
|
||||
-->
|
||||
|
||||
## Summary
|
||||
|
||||
<!--
|
||||
Describe the new feature. If QA has not yet tested the new feature/process, please also file a ticket with QA for their review.
|
||||
-->
|
||||
|
||||
## Details
|
||||
|
||||
**Details:**
|
||||
<!--
|
||||
- Include all pertinent information, e.g., screenshots, resource requirements, workarounds, links, etc.
|
||||
- List page link(s) in the current docs where the new feature applies, if applicable.
|
||||
- List page link(s) in the current docs where the new feature applies, if applicable.
|
||||
-->
|
||||
|
||||
@@ -4,8 +4,15 @@ about: For fixing docs errors/typos, adding needed/missing information, updating
|
||||
title: ''
|
||||
labels: ''
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
**Summary:**
|
||||
Describe the requested update giving as much detail as possible. Please also list page link(s) in the current docs where the update applies.
|
||||
## Related Issues
|
||||
<!--
|
||||
List any issues or tickets on other platforms that are associated with the request. For example, include a link to the issue tracking that feature in the Rancher repo, or list the Jira ticket number for the request.
|
||||
-->
|
||||
|
||||
## Summary
|
||||
|
||||
<!--
|
||||
Describe the requested update giving as much detail as possible. Please also list page link(s) in the current docs where the update applies.
|
||||
-->
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
<!--
|
||||
Check the Rancher docs issues to see if there is an existing issue for this pull request. If there is, enter the issue number below.
|
||||
-->
|
||||
|
||||
Fixes #[issue_number]
|
||||
|
||||
## Reminders
|
||||
|
||||
- See the [README](../README.md) for more details on how to work with the Rancher docs.
|
||||
|
||||
- Verify if changes pertain to other versions of Rancher. If they do, finalize the edits on one version of the page, then apply the edits to the other versions.
|
||||
|
||||
- If the pull request is dependent on an upcoming release, make sure to target the release branch instead of `main`.
|
||||
|
||||
## Description
|
||||
|
||||
<!--
|
||||
- What is the goal of this pull request?
|
||||
- What did you change?
|
||||
- Are there any other pull requests, tickets, or issues associated with this pull request?
|
||||
-->
|
||||
|
||||
## Comments
|
||||
|
||||
<!--
|
||||
Any additional notes a reviewer should know before we review.
|
||||
-->
|
||||
@@ -1,16 +1,31 @@
|
||||
# Edit The Docs
|
||||
# Contribute to Rancher Docs
|
||||
|
||||
To get started, fork and clone the rancher-docs repository.
|
||||
Welcome to the [Rancher docs](https://ranchermanager.docs.rancher.com/) repository. See the [Rancher software](https://github.com/rancher/rancher) repository if you have questions or requests for the Rancher platform.
|
||||
|
||||
## Make a Suggestion
|
||||
|
||||
You can suggest changes to the Rancher docs in two ways:
|
||||
|
||||
1. [Open an issue](https://github.com/rancher/rancher-docs/issues/new/choose).
|
||||
1. Edit the docs in the way you see fit and open a pull request.
|
||||
|
||||
## Edit the Docs
|
||||
|
||||
To get started, [fork](https://github.com/rancher/rancher-docs/fork) and clone the rancher-docs repository.
|
||||
|
||||
Our repository doesn't allow you to make changes directly to the `main` branch. Create a working branch and make pull requests from your fork to [rancher/rancher-docs](https://github.com/rancher/rancher-docs).
|
||||
|
||||
For most updates, you'll need to edit a file in `/docs`, and the corresponding file in `/versioned_docs/version-2.7`. If a change affects older versions, you can find files documenting Rancher v2.0 and later in the `/versioned_docs` directory.
|
||||
|
||||
If a file is moved or renamed, you'll also need to edit the `sidebars.js` files for each version, and the list of redirects in `docusaurus.config.js`.
|
||||
If a file is moved or renamed, you'll also need to edit the `sidebars.js` files for each version, and the list of redirects in `docusaurus.config.js`. See [Moving or Renaming Docs](./moving-or-renaming-docs.md).
|
||||
|
||||
## Style & Formatting
|
||||
### Navigate the Repo
|
||||
|
||||
The docs are written in [Markdown](https://www.markdownguide.org/getting-started/). We refer to the Microsoft [style guide](https://learn.microsoft.com/en-us/style-guide/welcome/) and generally use standard American English. Many pages are also available in Simplified Chinese.
|
||||
The file paths in the repo correspond to the URLs for pages on the docs website. The docs for the latest version of Rancher are located in `/docs`. Most index pages are found within the `/pages-for-subheaders` directory in `/docs`. All images are in `/static/img` in the top level of the repo. Older docs are found within `/versioned_docs` and generally follow the same structure as the files in `/docs`.
|
||||
|
||||
### Style & Formatting
|
||||
|
||||
The docs are written in [Markdown](https://www.markdownguide.org/getting-started/). We refer to the Microsoft [style guide](https://learn.microsoft.com/en-us/style-guide/welcome/) and use standard American English. Many pages are also available in Simplified Chinese.
|
||||
|
||||
Every docs page contain metadata in the first few lines:
|
||||
|
||||
@@ -22,7 +37,7 @@ title: Some Title
|
||||
|
||||
The `title` is rendered as the page's headline. The site renderer wraps the `title` value in `H1` tags, which are equivalent to `#` in Markdown syntax. This means that all subsequent headers on the page should be second level (`##`) or more.
|
||||
|
||||
## Docs Website
|
||||
## Run the Docs Website
|
||||
|
||||
The Rancher Docs website is built with [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
|
||||
|
||||
|
||||
@@ -2,4 +2,8 @@
|
||||
title: RKE Cluster Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration"/>
|
||||
</head>
|
||||
|
||||
This page has moved [here.](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Contributing to Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/contribute-to-rancher"/>
|
||||
</head>
|
||||
|
||||
Learn about the repositories used for Rancher and Rancher docs, how to build Rancher repositories, and what information to include when you file an issue.
|
||||
|
||||
For more detailed information on how to contribute to the development of Rancher projects, refer to the [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki). The wiki has resources on many topics, including the following:
|
||||
|
||||
@@ -3,6 +3,10 @@ title: Container Network Interface (CNI) Providers
|
||||
description: Learn about Container Network Interface (CNI), the CNI providers Rancher provides, the features they offer, and how to choose a provider for you
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/container-network-interface-providers"/>
|
||||
</head>
|
||||
|
||||
## What is CNI?
|
||||
|
||||
CNI (Container Network Interface), a [Cloud Native Computing Foundation project](https://cncf.io/), consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of plugins. CNI concerns itself only with network connectivity of containers and removing allocated resources when the container is deleted.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Deprecated Features in Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features-in-v2.5"/>
|
||||
</head>
|
||||
|
||||
### What is Rancher's Deprecation policy?
|
||||
|
||||
We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Dockershim
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/dockershim"/>
|
||||
</head>
|
||||
|
||||
The Dockershim is the CRI compliant layer between the Kubelet and the Docker daemon. As part of the Kubernetes 1.20 release, the [deprecation of the in-tree Dockershim was announced](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/). Removal is currently scheduled for Kubernetes 1.24. For more information on the deprecation and its timelines, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
|
||||
|
||||
RKE clusters, starting with Kubernetes 1.21, now support the external Dockershim to continue leveraging Docker as the CRI runtime. We now implement the upstream open source community Dockershim announced by [Mirantis and Docker](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) to ensure RKE clusters can continue to leverage Docker.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: General FAQ
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/general-faq"/>
|
||||
</head>
|
||||
|
||||
This FAQ is a work in progress designed to answers the questions our users most frequently ask about Rancher v2.x.
|
||||
|
||||
See [Technical FAQ](technical-items.md), for frequently asked technical questions.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Installing and Configuring kubectl
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/install-and-configure-kubectl"/>
|
||||
</head>
|
||||
|
||||
`kubectl` is a CLI utility for running commands against Kubernetes clusters. It's required for many maintenance and administrative tasks in Rancher 2.x.
|
||||
|
||||
### Installation
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Rancher is No Longer Needed
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/rancher-is-no-longer-needed"/>
|
||||
</head>
|
||||
|
||||
This page is intended to answer questions about what happens if you don't want Rancher anymore, if you don't want a cluster to be managed by Rancher anymore, or if the Rancher server is deleted.
|
||||
|
||||
|
||||
|
||||
@@ -3,6 +3,10 @@ title: Security
|
||||
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/security"/>
|
||||
</head>
|
||||
|
||||
**Is there a Hardening Guide?**
|
||||
|
||||
The Hardening Guide is now located in the main [Security](../pages-for-subheaders/rancher-security.md) section.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Technical
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/technical-items"/>
|
||||
</head>
|
||||
|
||||
### How can I reset the administrator password?
|
||||
|
||||
Docker Install:
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Telemetry
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/telemetry"/>
|
||||
</head>
|
||||
|
||||
### What is Telemetry?
|
||||
|
||||
Telemetry collects aggregate information about the size of Rancher installations, versions of components used, and which features are used. This information is used by Rancher Labs to help make the product better and is not shared with third-parties.
|
||||
|
||||
+6
-19
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Rendering the Helm Template in an Air-Gapped Environment
|
||||
title: Upgrading in an Air-Gapped Environment
|
||||
---
|
||||
|
||||
<head>
|
||||
@@ -12,9 +12,9 @@ These instructions assume you have already followed the instructions for a Kuber
|
||||
|
||||
:::
|
||||
|
||||
### Rancher Helm Template Options
|
||||
### Rancher Helm Upgrade Options
|
||||
|
||||
Render the Rancher template using the same chosen options that were used when installing Rancher. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
|
||||
To upgrade with Helm, apply the same options that you used when installing Rancher. Refer to the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
|
||||
|
||||
Based on the choice you made during installation, complete one of the procedures below.
|
||||
|
||||
@@ -29,8 +29,7 @@ Placeholder | Description
|
||||
### Option A: Default Self-signed Certificate
|
||||
|
||||
```
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--no-hooks \ # prevent files for Helm hooks from being generated
|
||||
helm upgrade rancher ./rancher-<VERSION>.tgz \
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set certmanager.version=<CERTMANAGER_VERSION> \
|
||||
@@ -42,8 +41,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
### Option B: Certificates from Files using Kubernetes Secrets
|
||||
|
||||
```plain
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--no-hooks \ # prevent files for Helm hooks from being generated
|
||||
helm upgrade rancher ./rancher-<VERSION>.tgz \
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
@@ -55,8 +53,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
If you are using a Private CA signed cert, add `--set privateCA=true` following `--set ingress.tls.source=secret`:
|
||||
|
||||
```plain
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--no-hooks \ # prevent files for Helm hooks from being generated
|
||||
helm upgrade rancher ./rancher-<VERSION>.tgz \
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
@@ -66,16 +63,6 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
### Apply the Rendered Templates
|
||||
|
||||
Copy the rendered manifest directories to a system with access to the Rancher server cluster and apply the rendered templates.
|
||||
|
||||
Use `kubectl` to apply the rendered manifests.
|
||||
|
||||
```plain
|
||||
kubectl -n cattle-system apply -R -f ./rancher
|
||||
```
|
||||
|
||||
## Verify the Upgrade
|
||||
|
||||
Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
+1
-1
@@ -26,7 +26,7 @@ See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanu
|
||||
### Rolling back from v2.6.4+ to lower versions of v2.6.x
|
||||
|
||||
1. Follow these [instructions](https://github.com/rancher/rancher-cleanup/blob/main/README.md) to run the scripts.
|
||||
1. Follow these [instructions](https://rancher.com/docs/rancher/v2.6/en/backups/migrating-rancher/) to install the rancher-backup Helm chart on the existing cluster and restore the previous state.
|
||||
1. Follow these [instructions](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) to install the rancher-backup Helm chart on the existing cluster and restore the previous state.
|
||||
1. Omit Step 3.
|
||||
1. When you reach Step 4, install the Rancher v2.6.x version on the local cluster you intend to roll back to.
|
||||
|
||||
|
||||
+2
-2
@@ -122,7 +122,7 @@ Copy the fetched charts to a system that has access to the Rancher server cluste
|
||||
|
||||
##### 1. Install Cert-Manager
|
||||
|
||||
Install cert-manager with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.
|
||||
Install cert-manager with the same options you would use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry.
|
||||
|
||||
:::note
|
||||
|
||||
@@ -144,7 +144,7 @@ If you are using self-signed certificates, install cert-manager:
|
||||
2. Create the cert-manager CustomResourceDefinitions (CRDs).
|
||||
|
||||
```plain
|
||||
kubectl apply -f cert-manager/cert-manager-crd.yaml
|
||||
kubectl apply -f cert-manager-crd.yaml
|
||||
```
|
||||
|
||||
3. Install cert-manager.
|
||||
|
||||
+4
-1
@@ -84,7 +84,10 @@ To sync Rancher with a local mirror of the RKE metadata, an administrator would
|
||||
|
||||
After new Kubernetes versions are loaded into the Rancher setup, additional steps would be required in order to use them for launching clusters. Rancher needs access to updated system images. While the metadata settings can only be changed by administrators, any user can download the Rancher system images and prepare a private container image registry for them.
|
||||
|
||||
1. To download the system images for the private registry, click the Rancher server version at the bottom left corner of the Rancher UI.
|
||||
To download the system images for the private registry:
|
||||
|
||||
1. Click **☰** in the top left corner.
|
||||
1. Click **About** at the bottom of the left navigation.
|
||||
1. Download the OS specific image lists for Linux or Windows.
|
||||
1. Download `rancher-images.txt`.
|
||||
1. Prepare the private registry using the same steps during the [air gap install](other-installation-methods/air-gapped-helm-cli-install/publish-images.md), but instead of using the `rancher-images.txt` from the releases page, use the one obtained from the previous steps.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Configure Alerts for Periodic Scan on a Schedule
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/configure-alerts-for-periodic-scan-on-a-schedule"/>
|
||||
</head>
|
||||
|
||||
It is possible to run a ClusterScan on a schedule.
|
||||
|
||||
A scheduled scan can also specify if you should receive alerts when the scan completes.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Create a Custom Benchmark Version for Running a Cluster Scan
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/create-a-custom-benchmark-version-to-run"/>
|
||||
</head>
|
||||
|
||||
There could be some Kubernetes cluster setups that require custom configurations of the Benchmark tests. For example, the path to the Kubernetes config files or certs might be different than the standard location where the upstream CIS Benchmarks look for them.
|
||||
|
||||
It is now possible to create a custom Benchmark Version for running a cluster scan using the `rancher-cis-benchmark` application.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Enable Alerting for Rancher CIS Benchmark
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/enable-alerting-for-rancher-cis-benchmark"/>
|
||||
</head>
|
||||
|
||||
Alerts can be configured to be sent out for a scan that runs on a schedule.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Install Rancher CIS Benchmark
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/install-rancher-cis-benchmark"/>
|
||||
</head>
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to install CIS Benchmark and click **Explore**.
|
||||
1. In the left navigation bar, click **Apps > Charts**.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Run a Scan Periodically on a Schedule
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/run-a-scan-periodically-on-a-schedule"/>
|
||||
</head>
|
||||
|
||||
To run a ClusterScan on a schedule,
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Run a Scan
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/run-a-scan"/>
|
||||
</head>
|
||||
|
||||
When a ClusterScan custom resource is created, it launches a new CIS scan on the cluster for the chosen ClusterScanProfile.
|
||||
|
||||
:::note
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Skip Tests
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/skip-tests"/>
|
||||
</head>
|
||||
|
||||
CIS scans can be run using test profiles with user-defined skips.
|
||||
|
||||
To skip tests, you will create a custom CIS scan profile. A profile contains the configuration for the CIS scan, which includes the benchmark versions to use and any specific tests to skip in that benchmark.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Uninstall Rancher CIS Benchmark
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/uninstall-rancher-cis-benchmark"/>
|
||||
</head>
|
||||
|
||||
1. From the **Cluster Dashboard,** go to the left navigation bar and click **Apps > Installed Apps**.
|
||||
1. Go to the `cis-operator-system` namespace and check the boxes next to `rancher-cis-benchmark-crd` and `rancher-cis-benchmark`.
|
||||
1. Click **Delete** and confirm **Delete**.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: View Reports
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides/view-reports"/>
|
||||
</head>
|
||||
|
||||
To view the generated CIS scan reports,
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Docker Install with TLS Termination at Layer-7 NGINX Load Balancer
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/configure-layer-7-nginx-load-balancer"/>
|
||||
</head>
|
||||
|
||||
For development and testing environments that have a special requirement to terminate TLS/SSL at a load balancer instead of your Rancher Server container, deploy Rancher and configure a load balancer to work with it conjunction.
|
||||
|
||||
A layer-7 load balancer can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with.
|
||||
|
||||
+142
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: Enabling the API Audit Log in Downstream Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log-in-downstream-clusters"/>
|
||||
</head>
|
||||
|
||||
Kubernetes auditing provides a security-relevant chronological set of records about a cluster. Kube-apiserver performs auditing. Requests generate an event at each stage of its execution, which is then preprocessed according to a certain policy and written to a backend. The policy determines what’s recorded and the backend persists the records.
|
||||
|
||||
You might want to configure the audit log as part of compliance with the Center for Internet Security (CIS) Kubernetes Benchmark controls.
|
||||
|
||||
For configuration details, refer to the [official Kubernetes documentation](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/).
|
||||
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2/K3s" default>
|
||||
|
||||
:::note
|
||||
|
||||
This feature is available in Rancher v2.7.2 and above.
|
||||
|
||||
:::
|
||||
|
||||
As a prerequisite, you need to create a secret or configmap which will be the source of the audit policy.
|
||||
|
||||
The secret or configmap must meet the following two requirements:
|
||||
|
||||
1. It must be in the `fleet-default` namespace where the Cluster object exists.
|
||||
2. It must have the annotation `rke.cattle.io/object-authorized-for-clusters: cluster-name1,cluster-name2` which permits the target clusters to use it.
|
||||
|
||||
:::tip
|
||||
|
||||
Rancher Dashboard provides an easy-to-use form for creating the secret or configmap.
|
||||
|
||||
:::
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
audit-policy: >-
|
||||
IyBMb2cgYWxsIHJlcXVlc3RzIGF0IHRoZSBNZXRhZGF0YSBsZXZlbC4KYXBpVmVyc2lvbjogYXVkaXQuazhzLmlvL3YxCmtpbmQ6IFBvbGljeQpydWxlczoKLSBsZXZlbDogTWV0YWRhdGE=
|
||||
kind: Secret
|
||||
metadata:
|
||||
annotations:
|
||||
rke.cattle.io/object-authorized-for-clusters: cluster1
|
||||
name: name1
|
||||
namespace: fleet-default
|
||||
```
|
||||
|
||||
The audit log can be enabled and configured by editing the cluster in YAML and utilizing the `machineSelectorFiles` and `machineGlobalConfig` directives.
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- audit-policy-file=<customized-path>/dev-audit-policy.yaml
|
||||
- audit-log-path=<customized-path>/dev-audit.logs
|
||||
machineSelectorFiles:
|
||||
- fileSources:
|
||||
- configMap:
|
||||
name: ''
|
||||
secret:
|
||||
items:
|
||||
- key: audit-policy
|
||||
path: <customized-path>/dev-audit-policy.yaml
|
||||
name: dev-audit-policy
|
||||
machineLabelSelector:
|
||||
matchLabels:
|
||||
rke.cattle.io/control-plane-role: 'true'
|
||||
```
|
||||
|
||||
For more information about cluster configuration, refer to the REK2 or K3s cluster configuration reference pages.
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="RKE1">
|
||||
|
||||
The audit log can be enabled and configured by editing the cluster with YAML.
|
||||
|
||||
When the audit log is enabled, RKE1 default values will be applied.
|
||||
|
||||
```yaml
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
services:
|
||||
kube-api:
|
||||
audit_log:
|
||||
enabled: true
|
||||
```
|
||||
|
||||
You can customize the audit log by using the configuration directive.
|
||||
|
||||
```yaml
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
services:
|
||||
kube-api:
|
||||
audit_log:
|
||||
enabled: true
|
||||
configuration:
|
||||
max_age: 6
|
||||
max_backup: 6
|
||||
max_size: 110
|
||||
path: /var/log/kube-audit/audit-log.json
|
||||
format: json
|
||||
policy:
|
||||
apiVersion: audit.k8s.io/v1 # This is required.
|
||||
kind: Policy
|
||||
omitStages:
|
||||
- "RequestReceived"
|
||||
rules:
|
||||
# Log pod changes at RequestResponse level
|
||||
- level: RequestResponse
|
||||
resources:
|
||||
- group: ""
|
||||
# Resource "pods" doesn't match requests to any subresource of pods,
|
||||
# which is consistent with the RBAC policy.
|
||||
resources: ["pods"]
|
||||
# Log "pods/log", "pods/status" at Metadata level
|
||||
- level: Metadata
|
||||
resources:
|
||||
- group: ""
|
||||
resources: ["pods/log", "pods/status"]
|
||||
```
|
||||
|
||||
For configuration details, refer to the official [RKE1 documentation](https://rke.docs.rancher.com/config-options/audit-log).
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Enabling the API Audit Log to Record System Events
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log"/>
|
||||
</head>
|
||||
|
||||
You can enable the API audit log to record the sequence of system events initiated by individual users. You can know what happened, when it happened, who initiated it, and what cluster it affected. When you enable this feature, all requests to the Rancher API and all responses from it are written to a log.
|
||||
|
||||
You can enable API Auditing during Rancher installation or upgrade.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Continuous Delivery
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery"/>
|
||||
</head>
|
||||
|
||||
[Fleet](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) comes preinstalled in Rancher can't be fully disabled. However, the Fleet feature for GitOps continuous delivery may be disabled using the `continuous-delivery` feature flag.
|
||||
|
||||
To enable or disable this feature, refer to the instructions on [the main page about enabling experimental features.](../../../pages-for-subheaders/enable-experimental-features.md)
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: UI for Istio Virtual Services and Destination Rules
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features"/>
|
||||
</head>
|
||||
|
||||
This feature enables a UI that lets you create, read, update and delete virtual services and destination rules, which are traffic management features of Istio.
|
||||
|
||||
> **Prerequisite:** Turning on this feature does not enable Istio. A cluster administrator needs to [enable Istio for the cluster](../../../pages-for-subheaders/istio-setup-guide.md) in order to use the feature.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: "Running on ARM64 (Experimental)"
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/rancher-on-arm64"/>
|
||||
</head>
|
||||
|
||||
:::caution
|
||||
|
||||
Running on an ARM64 platform is currently an experimental feature and is not yet officially supported in Rancher. Therefore, we do not recommend using ARM64 based nodes in a production environment.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Allow Unsupported Storage Drivers
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers"/>
|
||||
</head>
|
||||
|
||||
This feature allows you to use types for storage providers and provisioners that are not enabled by default.
|
||||
|
||||
To enable or disable this feature, refer to the instructions on [the main page about enabling experimental features.](../../../pages-for-subheaders/enable-experimental-features.md)
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: 1. Enable Istio in the Cluster
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/enable-istio-in-cluster"/>
|
||||
</head>
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
- Only a user with the `cluster-admin` [Kubernetes default role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) assigned can configure and install Istio in a Kubernetes cluster.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: 2. Enable Istio in a Namespace
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/enable-istio-in-namespace"/>
|
||||
</head>
|
||||
|
||||
You will need to manually enable Istio in each namespace that you want to be tracked or controlled by Istio. When Istio is enabled in a namespace, the Envoy sidecar proxy will be automatically injected into all new workloads that are deployed in the namespace.
|
||||
|
||||
This namespace setting will only affect new workloads in the namespace. Any preexisting workloads will need to be re-deployed to leverage the sidecar auto injection.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: 6. Generate and View Traffic
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/generate-and-view-traffic"/>
|
||||
</head>
|
||||
|
||||
This section describes how to view the traffic that is being managed by Istio.
|
||||
|
||||
## The Kiali Traffic Graph
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: 4. Set up the Istio Gateway
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/set-up-istio-gateway"/>
|
||||
</head>
|
||||
|
||||
The gateway to each cluster can have its own port or load balancer, which is unrelated to a service mesh. By default, each Rancher-provisioned cluster has one NGINX ingress controller allowing traffic into the cluster.
|
||||
|
||||
You can use the Nginx Ingress controller with or without Istio installed. If this is the only gateway to your cluster, Istio will be able to route traffic from service to service, but Istio will not be able to receive traffic from outside the cluster.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: 5. Set up Istio's Components for Traffic Management
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/set-up-traffic-management"/>
|
||||
</head>
|
||||
|
||||
A central advantage of traffic management in Istio is that it allows dynamic request routing. Some common applications for dynamic request routing include canary deployments and blue/green deployments. The two key resources in Istio traffic management are *virtual services* and *destination rules*.
|
||||
|
||||
- [Virtual services](https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service/) intercept and direct traffic to your Kubernetes services, allowing you to divide percentages of traffic from a request to different services. You can use them to define a set of routing rules to apply when a host is addressed.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: 3. Add Deployments and Services with the Istio Sidecar
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/use-istio-sidecar"/>
|
||||
</head>
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
To enable Istio for a workload, the cluster and namespace must have the Istio app installed.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Pod Security Policies
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-pod-security-policies"/>
|
||||
</head>
|
||||
|
||||
:::note
|
||||
|
||||
These cluster options are only available for [clusters in which Rancher has launched Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md).
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: How Resource Quotas Work in Rancher Projects
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/about-project-resource-quotas"/>
|
||||
</head>
|
||||
|
||||
Resource quotas in Rancher include the same functionality as the [native version of Kubernetes](https://kubernetes.io/docs/concepts/policy/resource-quotas/). However, in Rancher, resource quotas have been extended so that you can apply them to projects.
|
||||
|
||||
In a standard Kubernetes deployment, resource quotas are applied to individual namespaces. However, you cannot apply the quota to your namespaces simultaneously with a single action. Instead, the resource quota must be applied multiple times.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Overriding the Default Limit for a Namespace
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/override-default-limit-in-namespaces"/>
|
||||
</head>
|
||||
|
||||
Although the **Namespace Default Limit** propagates from the project to each namespace when created, in some cases, you may need to increase (or decrease) the quotas for a specific namespace. In this situation, you can override the default limits by editing the namespace.
|
||||
|
||||
In the diagram below, the Rancher administrator has a resource quota in effect for their project. However, the administrator wants to override the namespace limits for `Namespace 3` so that it has more resources available. Therefore, the administrator [raises the namespace limits](../../../new-user-guides/manage-clusters/projects-and-namespaces.md) for `Namespace 3` so that the namespace can access more resources.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Resource Quota Type Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/resource-quota-types"/>
|
||||
</head>
|
||||
|
||||
When you create a resource quota, you are configuring the pool of resources available to the project. You can set the following resource limits for the following resource types.
|
||||
|
||||
| Resource Type | Description |
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Setting Container Default Resource Limits
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/set-container-default-resource-limits"/>
|
||||
</head>
|
||||
|
||||
When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project / namespace, all containers will require a respective CPU or Memory field set during creation. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details on why this is required.
|
||||
|
||||
To avoid setting these limits on each and every container during workload creation, a default container resource limit can be specified on the namespace.
|
||||
|
||||
+2
-2
@@ -8,7 +8,7 @@ title: Enable Prometheus Federator
|
||||
|
||||
## Requirements
|
||||
|
||||
By default, Prometheus Federator is configured and intended to be deployed alongside [rancher-monitoring](https://rancher.com/docs/rancher/v2.6/en/monitoring-alerting/), which deploys Prometheus Operator alongside a Cluster Prometheus that each Project Monitoring Stack is configured to federate namespace-scoped metrics from by default.
|
||||
By default, Prometheus Federator is configured and intended to be deployed alongside [rancher-monitoring](../../../../pages-for-subheaders/monitoring-and-alerting.md), which deploys Prometheus Operator alongside a Cluster Prometheus that each Project Monitoring Stack is configured to federate namespace-scoped metrics from by default.
|
||||
|
||||
For instructions on installing rancher-monitoring, refer to [this page](../enable-monitoring.md).
|
||||
|
||||
@@ -79,7 +79,7 @@ There are no specific recommendations on how much memory the Cluster Prometheus
|
||||
1. Click the **Prometheus Federator** chart.
|
||||
1. Click **Install**.
|
||||
1. On the **Metadata** page, click **Next**.
|
||||
1. In the **Project Release Namespace Project ID** field, the `System Project` is used as the default but can be overridden with another project with similarly [limited access](#ensure-the-cattle-monitoring-system-namespace-is-placed-into-the-system-project-or-a-similarly-locked-down-project-that-has-access-to-other-projects-in-the-cluster). Project IDs can be found with the following command run in the local upstream cluster:
|
||||
1. In the **Namespaces** > **Project Release Namespace Project ID** field, the `System Project` is used as the default but can be overridden with another project with similarly [limited access](#ensure-the-cattle-monitoring-system-namespace-is-placed-into-the-system-project-or-a-similarly-locked-down-project-that-has-access-to-other-projects-in-the-cluster). Project IDs can be found with the following command run in the local upstream cluster:
|
||||
|
||||
```plain
|
||||
kubectl get projects -A -o custom-columns="NAMESPACE":.metadata.namespace,"ID":.metadata.name,"NAME":.spec.displayName
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ The steps for setting up monitoring for workloads depend on whether you want bas
|
||||
|
||||
If you only need CPU and memory time series for the workload, you don't need to deploy a ServiceMonitor or PodMonitor because the monitoring application already collects metrics data on resource usage by default. The resource usage time series data is in Prometheus's local time series database.
|
||||
|
||||
Grafana shows the data in aggregate, but you can see the data for the individual workload by using a PromQL query that extracts the data for that workload. Once you have the PromQL query, you can execute the query individually in the Prometheus UI and see the time series visualized there, or you can use the query to customize a Grafana dashboard to display the workload metrics. For examples of PromQL queries for workload metrics, see [this section.](https://rancher.com/docs/rancher/v2.6/en/monitoring-alerting/expression/#workload-metrics)
|
||||
Grafana shows the data in aggregate, but you can see the data for the individual workload by using a PromQL query that extracts the data for that workload. Once you have the PromQL query, you can execute the query individually in the Prometheus UI and see the time series visualized there, or you can use the query to customize a Grafana dashboard to display the workload metrics. For examples of PromQL queries for workload metrics, see [this section.](../../../integrations-in-rancher/monitoring-and-alerting/promql-expressions.md#workload-metrics)
|
||||
|
||||
To set up custom metrics for your workload, you will need to set up an exporter and create a new ServiceMonitor custom resource to configure Prometheus to scrape metrics from your exporter.
|
||||
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Opening Ports with firewalld
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/open-ports-with-firewalld"/>
|
||||
</head>
|
||||
|
||||
> We recommend disabling firewalld. For Kubernetes 1.19.x and higher, firewalld must be turned off.
|
||||
|
||||
Some distributions of Linux [derived from RHEL,](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds) including Oracle Linux, may have default firewall rules that block communication with Helm.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Tuning etcd for Large Installations
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/tune-etcd-for-large-installs"/>
|
||||
</head>
|
||||
|
||||
When running larger Rancher installations with 15 or more clusters it is recommended to increase the default keyspace for etcd from the default 2GB. The maximum setting is 8GB and the host should have enough RAM to keep the entire dataset in memory. When increasing this value you should also increase the size of the host. The keyspace size can also be adjusted in smaller installations if you anticipate a high rate of change of pods during the garbage collection interval.
|
||||
|
||||
The etcd data set is automatically cleaned up on a five minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota) setting on the etcd servers.
|
||||
|
||||
+10
-2
@@ -260,11 +260,19 @@ By default, the `local` backup target is selected. The benefits of this option i
|
||||
|
||||
### S3 Backup Target
|
||||
|
||||
The `S3` backup target allows users to configure a S3 compatible backend to store the snapshots. The primary benefit of this option is that if the cluster loses all the etcd nodes, the cluster can still be restored as the snapshots are stored externally. Rancher recommends external targets like `S3` backup, however its configuration requirements do require additional effort that should be considered. Additionally, it is recommended to ensure that every cluster has a unique bucket and/or folder, as Rancher will populate snapshot information for any available snapshot that is listed in the S3 bucket/folder that is configured for the cluster.
|
||||
We recommend that you use the `S3` backup target. It lets you store snapshots externally, on an S3 compatible backend. Since the snapshots aren't stored locally, you can still restore the cluster even if you lose all etcd nodes.
|
||||
|
||||
Although the `S3` target offers advantages over local backup, it does require extra configuration.
|
||||
|
||||
:::caution
|
||||
|
||||
If you use an S3 backup target, make sure that every cluster has its own bucket or folder. Rancher populates snapshot information from any available snapshot listed in the S3 bucket or folder configured for that cluster.
|
||||
|
||||
:::
|
||||
|
||||
| Option | Description | Required|
|
||||
|---|---|---|
|
||||
|S3 Bucket Name| S3 bucket name where backups will be stored| *|
|
||||
|S3 Bucket Name| Name of S3 bucket to store backups| *|
|
||||
|S3 Region|S3 region for the backup bucket| |
|
||||
|S3 Region Endpoint|S3 regions endpoint for the backup bucket|* |
|
||||
|S3 Access Key|S3 access key with permission to access the backup bucket|*|
|
||||
|
||||
+1
-1
@@ -101,7 +101,7 @@ Below are some examples of some **incorrect** uses or expectations of Rancher Ba
|
||||
|
||||
### Upgrades
|
||||
|
||||
- Using Rancher backups for upgrading Rancher versions is not a valid use case. The recommended procedure is to take a backup of the current version, then upgrade your Rancher instance using [these instructions](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades), and then taking **another** backup after the upgrade is complete. This way if the upgrade fails you have a backup to restore to, and the second backup will be valid to restore to the upgraded Rancher version.
|
||||
- Using Rancher backups for upgrading Rancher versions is not a valid use case. The recommended procedure is to take a backup of the current version, then upgrade your Rancher instance using [these instructions](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md), and then taking **another** backup after the upgrade is complete. This way if the upgrade fails you have a backup to restore to, and the second backup will be valid to restore to the upgraded Rancher version.
|
||||
- Using Rancher backups for upgrading Kubernetes versions is not a valid use case either. Because the Kubernetes API and available resources are tied to the version, upgrading using backup restore can lead to issues with misaligned sets of resources which may be deprecated, unsupported, or updated. How to upgrade your cluster version will depend on how it was provisioned however the same format as above is recommended (backup, upgrade, backup).
|
||||
|
||||
### ResourceSet
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ title: Restoring a Cluster from Backup
|
||||
|
||||
Etcd backup and recovery for [Rancher launched Kubernetes clusters](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) can be easily performed. Snapshots of the etcd database are taken and saved either locally onto the etcd nodes or to a S3 compatible target. The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.
|
||||
|
||||
Rancher recommends enabling the [ability to set up recurring snapshots of etcd](back-up-rancher-launched-kubernetes-clusters.md#configuring-recurring-snapshots), but [one-time snapshots](back-up-rancher-launched-kubernetes-clusters.md#one-time-snapshots) can easily be taken as well. Rancher allows restore from [saved snapshots](#restoring-a-cluster-from-a-snapshot) or if you don't have any snapshots, you can still [restore etcd](#recovering-etcd-without-a-snapshot).
|
||||
Rancher recommends enabling the [ability to set up recurring snapshots of etcd](back-up-rancher-launched-kubernetes-clusters.md#configuring-recurring-snapshots), but [one-time snapshots](back-up-rancher-launched-kubernetes-clusters.md#one-time-snapshots) can easily be taken as well. Rancher allows restore from [saved snapshots](#restoring-a-cluster-from-a-snapshot) or if you don't have any snapshots, you can still [restore etcd](#recovering-etcd-without-a-snapshot-rke).
|
||||
|
||||
Clusters can also be restored to a prior Kubernetes version and cluster configuration.
|
||||
|
||||
|
||||
+1
-1
@@ -36,7 +36,7 @@ See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanu
|
||||
### Rolling back from v2.6.4+ to lower versions of v2.6.x
|
||||
|
||||
1. Follow these [instructions](https://github.com/rancher/rancher-cleanup/blob/main/README.md) to run the scripts.
|
||||
1. Follow these [instructions](https://rancher.com/docs/rancher/v2.6/en/backups/migrating-rancher/) to install the rancher-backup Helm chart on the existing cluster and restore the previous state.
|
||||
1. Follow these [instructions](../backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) to install the rancher-backup Helm chart on the existing cluster and restore the previous state.
|
||||
1. Omit Step 3.
|
||||
1. When you reach Step 4, install the Rancher v2.6.x version on the local cluster you intend to roll back to.
|
||||
|
||||
|
||||
@@ -6,16 +6,12 @@ title: Creating Apps
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher/create-apps"/>
|
||||
</head>
|
||||
|
||||
Rancher's App Marketplace is based on Helm Repositories and Helm Charts. You can add HTTP based standard Helm Repositories as well as any Git Repository which contains charts.
|
||||
|
||||
:::tip
|
||||
|
||||
For a complete walkthrough of developing charts, see the [Chart Template Developer's Guide](https://helm.sh/docs/chart_template_guide/) in the official Helm documentation.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
|
||||
## Chart Types
|
||||
|
||||
Rancher supports two different types of charts: Helm charts and Rancher charts.
|
||||
|
||||
+10
-3
@@ -8,11 +8,18 @@ title: How the Authorized Cluster Endpoint Works
|
||||
|
||||
This section describes how the kubectl CLI, the kubeconfig file, and the authorized cluster endpoint work together to allow you to access a downstream Kubernetes cluster directly, without authenticating through the Rancher server. It is intended to provide background information and context to the instructions for [how to set up kubectl to directly access a cluster.](use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster)
|
||||
|
||||
### About the kubeconfig File
|
||||
### About the Kubeconfig File
|
||||
|
||||
The _kubeconfig file_ is a file used to configure access to Kubernetes when used in conjunction with the kubectl command line tool (or other clients).
|
||||
The kubeconfig file is used to configure access to Kubernetes when used in conjunction with the kubectl command line tool (or other clients).
|
||||
|
||||
This kubeconfig file and its contents are specific to the cluster you are viewing. It can be downloaded from the cluster view in Rancher. You will need a separate kubeconfig file for each cluster that you have access to in Rancher.
|
||||
The kubeconfig file and its contents are specific to each cluster. It can be downloaded from the **Clusters** page in Rancher:
|
||||
|
||||
1. Click **☰** in the top left corner.
|
||||
1. Select **Cluster Management**.
|
||||
1. Find the cluster whose kubeconfig you want to download, and select **⁝** at the end of the row.
|
||||
1. Select **Download KubeConfig** from the submenu.
|
||||
|
||||
You will need a separate kubeconfig file for each cluster that you have access to in Rancher.
|
||||
|
||||
After you download the kubeconfig file, you will be able to use the kubeconfig file and its Kubernetes [contexts](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-context-and-configuration) to access your downstream cluster.
|
||||
|
||||
|
||||
+4
-3
@@ -31,9 +31,10 @@ These instructions assume that you have already created a Kubernetes cluster, an
|
||||
|
||||
:::
|
||||
|
||||
1. Log into Rancher. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you want to access with kubectl and click **Explore**.
|
||||
1. In the top navigation bar, click **Download KubeConfig** button.
|
||||
1. Click **☰** in the top left corner.
|
||||
1. Select **Cluster Management**.
|
||||
1. Find the cluster whose kubeconfig you want to download, and select **⁝** at the end of the row.
|
||||
1. Select **Download KubeConfig** from the submenu.
|
||||
1. Save the YAML file on your local computer. Move the file to `~/.kube/config`. Note: The default location that kubectl uses for the kubeconfig file is `~/.kube/config`, but you can use any directory and specify it using the `--kubeconfig` flag, as in this command:
|
||||
```
|
||||
kubectl --kubeconfig /custom/path/kube.config get pods
|
||||
|
||||
@@ -32,8 +32,8 @@ In this section, you'll learn how to add the cluster template to the `local` clu
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
- You will need permission to install Helm charts on the `local` Kubernetes cluster that Rancher is installed on.
|
||||
- In order for the chart to appear in the form for creating new clusters, the chart must have the annotation `catalog.cattle.io/type: cluster-template`.
|
||||
- You will need permission to install Helm charts on the `local` Rancher cluster.
|
||||
- To make the chart viewable in the cluster creation form, both the chart and the index.yaml file must have the annotation, `catalog.cattle.io/type: cluster-template`.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@@ -6,7 +6,14 @@ title: Nodes and Node Pools
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools"/>
|
||||
</head>
|
||||
|
||||
After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab. Depending on the [option used](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) to provision the cluster, there are different node options available.
|
||||
After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab.
|
||||
|
||||
1. Click **☰** in the top left corner.
|
||||
1. Select **Cluster Management**.
|
||||
1. Find the cluster whose nodes you want to manage, and click the **Explore** button at the end of the row.
|
||||
1. Select **Nodes** from the left navigation.
|
||||
|
||||
Depending on the [option used](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) to provision the cluster, there are different node options available.
|
||||
|
||||
:::note
|
||||
|
||||
|
||||
@@ -110,4 +110,8 @@ You can also see the rules in the Prometheus UI:
|
||||
|
||||
|
||||
|
||||
For more information on configuring PrometheusRules in Rancher, see [this page.](../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheusrules.md)
|
||||
For more information on configuring PrometheusRules in Rancher, see [this page.](../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheusrules.md)
|
||||
|
||||
## Legacy UI
|
||||
|
||||
For information on the dashboards available in v2.2 to v2.4 of Rancher, before the introduction of the `rancher-monitoring` application, see the [Rancher v2.0—v2.4 docs](../../../versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md).
|
||||
|
||||
@@ -14,22 +14,52 @@ For more information on roles-based access control, see [this section.](manage-r
|
||||
|
||||
For information on how to set up an authentication system, see [this section.](authentication-config.md)
|
||||
|
||||
## Clusters in Rancher UI
|
||||
|
||||
### Rancher UI
|
||||
There are several paths to view and manage clusters through the Rancher UI.
|
||||
|
||||
Rancher provides an intuitive user interface for interacting with your clusters. All options available in the UI use the Rancher API. Therefore any action possible in the UI is also possible in the Rancher CLI or Rancher API.
|
||||
### Clusters Page
|
||||
|
||||
### kubectl
|
||||
You can access the **Clusters** page from the **☰** menu:
|
||||
|
||||
1. Click **☰**.
|
||||
1. Select **Cluster Management**.
|
||||
|
||||
You can also access the **Clusters** page by clicking the **Manage** button above the clusters table on the Rancher UI **Home** page.
|
||||
|
||||
On the **Clusters** page, select **⁝** at the end of each row to view a submenu with the following options:
|
||||
|
||||
* [Kubectl Shell](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md)
|
||||
* Download KubeConfig
|
||||
* Copy KubeConfig to Clipboard
|
||||
* Edit Config
|
||||
* View YAML
|
||||
* Download YAML
|
||||
|
||||
### Cluster Dashboard
|
||||
|
||||
On the **Clusters** page, select the **Explore** button at the end of each row to view that cluster's **Cluster Dashboard**. You can also view the dashboard by clicking the name of a cluster in the table, then clicking the **Explore** buttton on the **Cluster** page.
|
||||
|
||||
The **Cluster Dashboard** is also accessible from the Rancher UI **Home** page, by clicking on the name of a cluster.
|
||||
|
||||
You can also access the **Cluster Dashboard** from the **☰** in the top navigation bar:
|
||||
|
||||
1. Click **☰**.
|
||||
1. Select the name of a cluster from the **Explore Cluster** menu option.
|
||||
|
||||
The **Cluster Dashboard** lists information about a specific cluster, such as number of nodes, memory usage, events, and resources.
|
||||
|
||||
## kubectl
|
||||
|
||||
You can use the Kubernetes command-line tool, [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), to manage your clusters. You have two options for using kubectl:
|
||||
|
||||
- **Rancher kubectl shell:** Interact with your clusters by launching a kubectl shell available in the Rancher UI. This option requires no configuration actions on your part. For more information, see [Accessing Clusters with kubectl Shell](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md).
|
||||
- **Terminal remote connection:** You can also interact with your clusters by installing [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on your local desktop and then copying the cluster's kubeconfig file to your local `~/.kube/config` directory. For more information, see [Accessing Clusters with kubectl and a kubeconfig File](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md).
|
||||
|
||||
### Rancher CLI
|
||||
## Rancher CLI
|
||||
|
||||
You can control your clusters by downloading Rancher's own command-line interface, [Rancher CLI](cli-with-rancher.md). This CLI tool can interact directly with different clusters and projects or pass them `kubectl` commands.
|
||||
|
||||
### Rancher API
|
||||
## Rancher API
|
||||
|
||||
Finally, you can interact with your clusters over the Rancher API. Before you use the API, you must obtain an [API key](../reference-guides/user-settings/api-keys.md). To view the different resource fields and actions for an API object, open the API UI, which can be accessed by clicking on **View in API** for any Rancher UI object.
|
||||
Finally, you can interact with your clusters over the Rancher API. Before you use the API, you must obtain an [API key](../reference-guides/user-settings/api-keys.md). To view the different resource fields and actions for an API object, open the API UI, which can be accessed by clicking on **View in API** for any Rancher UI object.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Authentication, Permissions and Global Configuration
|
||||
title: Authentication, Permissions and Global Settings
|
||||
---
|
||||
|
||||
<head>
|
||||
@@ -52,6 +52,34 @@ Rancher Kubernetes Metadata contains Kubernetes version information which Ranche
|
||||
|
||||
For more information on how metadata works and how to configure metadata config, see [Rancher Kubernetes Metadata](../getting-started/installation-and-upgrade/upgrade-kubernetes-without-upgrading-rancher.md).
|
||||
|
||||
## Enabling Experimental Features
|
||||
## Global Settings
|
||||
|
||||
Rancher includes some features that are experimental and disabled by default. Feature flags were introduced to allow you to try these features. For more information, refer to the section about [feature flags.](enable-experimental-features.md)
|
||||
Options that control certain global-level Rancher settings are available from the top navigation bar.
|
||||
|
||||
Click **☰** in the top left corner, then select **Global Settings**, to view and configure the following settings:
|
||||
|
||||
- **Settings**: Various Rancher defaults, such as the minimum length for a user's password (`password-min-length`). You should be cautious when modifying these settings, as invalid values may break your Rancher installation.
|
||||
- **Feature Flags**: Rancher features that can be toggled on or off. Some of these flags are for [experimental features](#enabling-experimental-features).
|
||||
- **Banners**: Elements you can add to fixed locations on the portal. For example, you can use these options to [set a custom banner](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/custom-branding.md#fixed-banners) for users when they login to Rancher.
|
||||
- **Branding**: Rancher UI design elements that you can [customize](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/custom-branding.md). You can add a custom logo or favicon, and modify UI colors.
|
||||
- **Performance**: Performance settings for the Rancher UI, such as incremental resource loading.
|
||||
- **Home Links**: Links displayed on the Rancher UI **Home** page. You can modify visibility for the default links or add your own links.
|
||||
|
||||
### Enabling Experimental Features
|
||||
|
||||
Rancher includes some features that are experimental and/or disabled by default. Feature flags allow you to enable these features. For more information, refer to the section about [feature flags.](enable-experimental-features.md)
|
||||
|
||||
### Global Configuration
|
||||
|
||||
**Global Configuration** options aren't visible unless you activate the **legacy** [feature flag](enable-experimental-features.md). The **legacy** flag is disabled by default on fresh Rancher installs of v2.6 and later. If you upgrade from an earlier Rancher version, or activate the **legacy** feature flag on Rancher v2.6 and later, **Global Configuration** is available from the top navigation menu:
|
||||
|
||||
1. Click **☰** in the top left corner.
|
||||
1. Select **Global Configuration** from the **Legacy Apps**.
|
||||
|
||||
The following features are available under **Global Configuration**:
|
||||
|
||||
- **Catalogs**
|
||||
- **Global DNS Entries**
|
||||
- **Global DNS Providers**
|
||||
|
||||
As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](../../versioned_docs/version-2.0-2.4/pages-for-subheaders/helm-charts-in-rancher.md), [global DNS entries](../../versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](../../versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details.
|
||||
@@ -55,17 +55,14 @@ If you are installing an alpha version, Helm requires adding the `--devel` optio
|
||||
|
||||
:::
|
||||
|
||||
### Rendering the Helm Chart for Air Gap Installations
|
||||
### Enabling Features for Air Gap Installs
|
||||
|
||||
For an air gap installation of Rancher, you need to add a Helm chart repository and render a Helm template before installing Rancher with Helm. For details, refer to the [air gap installation documentation.](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md)
|
||||
To perform an [air gap installation of Rancher](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md), add a Helm chart repository and download a Helm chart, then install Rancher with Helm.
|
||||
|
||||
Here is an example of a command for passing in the feature flag names when rendering the Helm template. In the below example, two features are enabled by passing the feature flag names in a comma separated list.
|
||||
|
||||
The Helm command is as follows:
|
||||
When you install the Helm chart, you should pass in feature flag names in a comma separated list, as in the following example:
|
||||
|
||||
```
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--no-hooks \ # prevent files for Helm hooks from being generated
|
||||
helm install rancher ./rancher-<VERSION>.tgz \
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
|
||||
@@ -16,10 +16,12 @@ This hardening guide is intended to be used for K3s clusters and is associated w
|
||||
|
||||
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 up to v1.25 |
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
| Rancher v2.7 | Benchmark v1.24 | Kubernetes v1.24 |
|
||||
| Rancher v2.7 | Benchmark v1.7 | Kubernetes v1.25 up to v1.26 |
|
||||
|
||||
:::note
|
||||
At the time of writing, the upstream CIS Kubernetes v1.25 benchmark is not yet available in Rancher. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters.
|
||||
In Benchmark v1.7, the `--protect-kernel-defaults` (4.2.6) parameter isn't required anymore, and was removed by CIS.
|
||||
:::
|
||||
|
||||
For more details on how to evaluate a hardened K3s cluster against the official CIS benchmark, refer to the K3s self-assessment guides for specific Kubernetes and CIS benchmark versions.
|
||||
@@ -37,6 +39,14 @@ The first section (1.1) of the CIS Benchmark primarily focuses on pod manifest
|
||||
|
||||
### Ensure `protect-kernel-defaults` is set
|
||||
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 and Newer" default>
|
||||
|
||||
The `protect-kernel-defaults` is no longer required since CIS benchmark 1.7.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
|
||||
|
||||
The `protect-kernel-defaults` flag can be set in the cluster configuration in Rancher.
|
||||
@@ -49,6 +59,9 @@ spec:
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Set kernel parameters
|
||||
|
||||
The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
|
||||
@@ -689,7 +702,6 @@ spec:
|
||||
- config:
|
||||
kubelet-arg:
|
||||
- make-iptables-util-chains=true # CIS 4.2.7
|
||||
protect-kernel-defaults: true # CIS 4.2.6
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
|
||||
@@ -7,8 +7,13 @@ description: Prometheus lets you view metrics from your different Rancher and Ku
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/monitoring-and-alerting"/>
|
||||
</head>
|
||||
|
||||
Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster.
|
||||
The `rancher-monitoring` application can quickly deploy leading open-source monitoring and alerting solutions onto your cluster.
|
||||
|
||||
Introduced in Rancher v2.5, the application 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)
|
||||
|
||||
For information on V1 monitoring and alerting, available in Rancher v2.2 up to v2.4, please see the Rancher v2.0—v2.4 docs on [cluster monitoring](../../versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-monitoring.md), [alerting](../../versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-alerts.md), [notifiers](../../versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](../../versioned_docs/version-2.0-2.4/pages-for-subheaders/project-tools.md).
|
||||
|
||||
Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster.
|
||||
|
||||
### Features
|
||||
|
||||
@@ -16,8 +21,6 @@ Prometheus lets you view metrics from your Rancher and Kubernetes objects. Using
|
||||
|
||||
By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, or restore crashed servers.
|
||||
|
||||
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:
|
||||
|
||||
- Monitors the state and processes of your cluster nodes, Kubernetes components, and software deployments.
|
||||
|
||||
@@ -16,10 +16,13 @@ This hardening guide is intended to be used for RKE clusters and is associated w
|
||||
|
||||
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 up to v1.25 |
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
| Rancher v2.7 | Benchmark v1.24 | Kubernetes v1.24 |
|
||||
| Rancher v2.7 | Benchmark v1.7 | Kubernetes v1.25 up to v1.26 |
|
||||
|
||||
:::note
|
||||
At the time of writing, the upstream CIS Kubernetes v1.25 benchmark is not yet available in Rancher. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters. Due to that, the CIS checks 5.2.3, 5.2.4, 5.2.5 and 5.2.6 might fail.
|
||||
- In Benchmark v1.24 and later, check id `4.1.7 Ensure that the certificate authorities file permissions are set to 600 or more restrictive (Automated)` might fail, as `/etc/kubernetes/ssl/kube-ca.pem` is set to 644 by default.
|
||||
- In Benchmark v1.7, the `--protect-kernel-defaults` (`4.2.6`) parameter isn't required anymore, and was removed by CIS.
|
||||
:::
|
||||
|
||||
For more details on how to evaluate a hardened RKE cluster against the official CIS benchmark, refer to the RKE self-assessment guides for specific Kubernetes and CIS benchmark versions.
|
||||
@@ -247,7 +250,6 @@ services:
|
||||
kubelet:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
protect-kernel-defaults: "true"
|
||||
generate_serving_certificate: true
|
||||
addons: |
|
||||
apiVersion: networking.k8s.io/v1
|
||||
@@ -444,7 +446,6 @@ rancher_kubernetes_engine_config:
|
||||
kubelet:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
protect-kernel-defaults: true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
generate_serving_certificate: true
|
||||
scheduler:
|
||||
|
||||
@@ -16,10 +16,13 @@ This hardening guide is intended to be used for RKE2 clusters and is associated
|
||||
|
||||
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 up to v1.25 |
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
| Rancher v2.7 | Benchmark v1.24 | Kubernetes v1.24 |
|
||||
| Rancher v2.7 | Benchmark v1.7 | Kubernetes v1.25 up to v1.26 |
|
||||
|
||||
:::note
|
||||
At the time of writing, the upstream CIS Kubernetes v1.25 benchmark is not yet available in Rancher. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters. Due to that, the CIS checks 5.2.2, 5.2.3, 5.2.5, 5.2.6, 5.2.7 and 5.2.8 might fail.
|
||||
- In Benchmark v1.24 and later, some check ids might fail due to new file permission requirements (600 instead of 644). Impacted check ids: `1.1.1`, `1.1.3`, `1.1.5`, `1.1.7`, `1.1.13`, `1.1.15`, `1.1.17`, `4.1.3`, `4.1.5` and `4.1.9`.
|
||||
- In Benchmark v1.7, the `--protect-kernel-defaults` (4.2.6) parameter is not required anymore, and was removed by CIS.
|
||||
:::
|
||||
|
||||
For more details on how to evaluate a hardened RKE2 cluster against the official CIS benchmark, refer to the RKE2 self-assessment guides for specific Kubernetes and CIS benchmark versions.
|
||||
@@ -33,6 +36,31 @@ RKE2 passes a number of the Kubernetes CIS controls without modification, as it
|
||||
|
||||
There are two areas of host-level requirements: kernel parameters and etcd process/directory configuration. These are outlined in this section.
|
||||
|
||||
### Ensure `protect-kernel-defaults` is set
|
||||
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 and Newer" default>
|
||||
|
||||
The `protect-kernel-defaults` is no longer required since CIS benchmark 1.7.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
|
||||
|
||||
The `protect-kernel-defaults` flag can be set in the cluster configuration in Rancher.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Set kernel parameters
|
||||
|
||||
The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
|
||||
@@ -68,22 +96,6 @@ sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U
|
||||
|
||||
The runtime requirements to pass the CIS Benchmark are centered around pod security, network policies and kernel parameters. Most of this is automatically handled by RKE2 when using a valid `cis-1.xx` profile, but some additional operator intervention is required. These are outlined in this section.
|
||||
|
||||
### Ensure `protect-kernel-defaults` is set
|
||||
|
||||
This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
|
||||
|
||||
Both `protect-kernel-defaults` and `profile` flags can be set in the RKE2 template configuration file.
|
||||
When the `profile` flag is set, RKE2 will set the flag to `true` if it is unset.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: # use cis-1.23 or cis-1.6
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
### PodSecurity
|
||||
|
||||
RKE2 always runs with some amount of pod security.
|
||||
@@ -93,7 +105,7 @@ RKE2 always runs with some amount of pod security.
|
||||
|
||||
On v1.25 and newer, [Pod Security Admissions (PSAs)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) are used for pod security.
|
||||
|
||||
Below is the minimum necessary configuration needed for hardening RKE2 to pass CIS v1.23 hardened profile `rke2-cis-1.23-hardened` available in Rancher.
|
||||
Below is the minimum necessary configuration needed for hardening RKE2 to pass CIS v1.23 hardened profile `rke2-cis-1.7-hardened` available in Rancher.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
@@ -234,7 +246,6 @@ spec:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.23
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
|
||||
@@ -4,6 +4,11 @@ title: "What is Rancher?"
|
||||
sidebar_label: What is Rancher?
|
||||
description: "Rancher adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com"/>
|
||||
</head>
|
||||
|
||||
Rancher is a Kubernetes management tool to deploy and run clusters anywhere and on any provider.
|
||||
|
||||
Rancher can provision Kubernetes from a hosted provider, provision compute nodes and then install Kubernetes onto them, or import existing Kubernetes clusters running anywhere.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: API Tokens
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/about-the-api/api-tokens"/>
|
||||
</head>
|
||||
|
||||
By default, some cluster-level API tokens are generated with infinite time-to-live (`ttl=0`). In other words, API tokens with `ttl=0` never expire unless you invalidate them. Tokens are not invalidated by changing a password.
|
||||
|
||||
You can deactivate API tokens by deleting them or by deactivating the user account.
|
||||
|
||||
@@ -2,8 +2,14 @@
|
||||
title: Backup Configuration
|
||||
---
|
||||
|
||||
The Backup Create page lets you configure a schedule, enable encryption and specify the storage location for your backups.
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/backup-configuration"/>
|
||||
</head>
|
||||
|
||||
The **Backup: Create** page lets you configure a schedule, enable encryption and specify the storage location for your backups.
|
||||
|
||||
|
||||
You must first [install](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) the `rancher-backup` operator. After you do so, you can access the **Backup: Create** page:
|
||||
|
||||
## Schedule
|
||||
|
||||
@@ -68,9 +74,15 @@ Selecting the first option stores this backup in the storage location configured
|
||||
|
||||
### S3
|
||||
|
||||
:::caution
|
||||
|
||||
If you use an S3 backup target, make sure that every cluster has its own bucket or folder. Rancher populates snapshot information from any available snapshot listed in the S3 bucket or folder configured for that cluster.
|
||||
|
||||
:::
|
||||
|
||||
The S3 storage location contains the following configuration fields:
|
||||
|
||||
1. **Credential Secret** (optional): If you need to use the AWS Access keys Secret keys to access s3 bucket, create a secret with your credentials with keys and the directives `accessKey` and `secretKey`. It can be in any namespace. An example secret is [here.](#example-credentialsecret) This directive is unnecessary if the nodes running your operator are in EC2 and set up with IAM permissions that allow them to access S3, as described in [this section.](#iam-permissions-for-ec2-nodes-to-access-s3) The Credential Secret dropdown lists the secrets in all namespaces.
|
||||
1. **Credential Secret** (optional): If you need an AWS access key or secret key to access an S3 bucket, [create a secret](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md) using your credentials, with keys and directives named `accessKey` and `secretKey`. The secret can be in any namespace. An example secret is [here](#example-credentialsecret). This directive is unnecessary if the nodes running your operator are in EC2 and assigned [IAM permissions to access S3](#iam-permissions-for-ec2-nodes-to-access-s3). The **Credential Secret** dropdown lists secrets in all namespaces.
|
||||
1. **Bucket Name**: The name of the S3 bucket where backup files will be stored.
|
||||
1. **Region** (optional): The AWS [region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) where the S3 bucket is located. This field isn't needed for configuring MinIO.
|
||||
1. **Folder** (optional): The name of the folder in the S3 bucket where backup files will be stored. Nested folders (e.g., `rancher/cluster1`) are not supported. If this field is left empty, the default behavior is to store the backup files in the root folder of the S3 bucket.
|
||||
@@ -79,9 +91,11 @@ The S3 storage location contains the following configuration fields:
|
||||
1. **Skip TLS Verifications** (optional): Set to true if you are not using TLS.
|
||||
|
||||
|
||||
#### YAML Directive Fields
|
||||
|
||||
| YAML Directive Name | Description | Required |
|
||||
| ---------------- | ---------------- | ------------ |
|
||||
| `credentialSecretName` | If you need to use the AWS Access keys Secret keys to access s3 bucket, create a secret with your credentials with keys and the directives `accessKey` and `secretKey`. It can be in any namespace as long as you provide that namespace in `credentialSecretNamespace`. An example secret is [here.](#example-credentialsecret) This directive is unnecessary if the nodes running your operator are in EC2 and set up with IAM permissions that allow them to access S3, as described in [this section.](#iam-permissions-for-ec2-nodes-to-access-s3) | |
|
||||
| `credentialSecretName` | If you need an AWS access key or secret key to access an S3 bucket, [create a secret](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md) using your credentials, with keys and directives named `accessKey` and `secretKey`. The secret can be in any namespace. An example secret is [here](#example-credentialsecret). This directive is unnecessary if the nodes running your operator are in EC2 and assigned [IAM permissions to access S3](#iam-permissions-for-ec2-nodes-to-access-s3). | |
|
||||
| `credentialSecretNamespace` | The namespace of the secret containing the credentials to access S3. This directive is unnecessary if the nodes running your operator are in EC2 and set up with IAM permissions that allow them to access S3, as described in [this section.](#iam-permissions-for-ec2-nodes-to-access-s3) | |
|
||||
| `bucketName` | The name of the S3 bucket where backup files will be stored. | ✓ |
|
||||
| `folder` | The name of the folder in the S3 bucket where backup files will be stored. Nested folders (e.g., `rancher/cluster1`) are not supported. If this field is left empty, the default behavior is to store the backup files in the root folder of the S3 bucket. | |
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Examples
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/examples"/>
|
||||
</head>
|
||||
|
||||
This section contains examples of Backup and Restore custom resources.
|
||||
|
||||
The default backup storage location is configured when the `rancher-backup` operator is installed or upgraded.
|
||||
@@ -242,19 +246,6 @@ spec:
|
||||
encryptionConfigSecretName: test-encryptionconfig
|
||||
```
|
||||
|
||||
## Example Credential Secret for Storing Backups in S3
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: creds
|
||||
type: Opaque
|
||||
data:
|
||||
accessKey: <Enter your base64-encoded access key>
|
||||
secretKey: <Enter your base64-encoded secret key>
|
||||
```
|
||||
|
||||
## Example EncryptionConfiguration
|
||||
|
||||
The snippet below demonstrates two different types of secrets and their relevance with respect to Backup and Restore of custom resources.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Restore Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/restore-configuration"/>
|
||||
</head>
|
||||
|
||||
The Restore Create page lets you provide details of the backup to restore from
|
||||
|
||||
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Backup Storage Location Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/storage-configuration"/>
|
||||
</head>
|
||||
|
||||
Configure a storage location where all backups are saved by default. You will have the option to override this with each backup, but will be limited to using an S3-compatible object store.
|
||||
|
||||
Only one storage location can be configured at the operator level.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Logging Best Practices
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/logging-best-practices"/>
|
||||
</head>
|
||||
|
||||
In this guide, we recommend best practices for cluster-level logging and application logging.
|
||||
|
||||
- [Cluster-level Logging](#cluster-level-logging)
|
||||
|
||||
+5
-1
@@ -2,6 +2,10 @@
|
||||
title: Monitoring Best Practices
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices"/>
|
||||
</head>
|
||||
|
||||
Configuring sensible monitoring and alerting rules is vital for running any production workloads securely and reliably. This is not different when using Kubernetes and Rancher. Fortunately the integrated monitoring and alerting functionality makes this whole process a lot easier.
|
||||
|
||||
The [Rancher monitoring documentation](../../../pages-for-subheaders/monitoring-and-alerting.md) describes how you can set up a complete Prometheus and Grafana stack. Out of the box this will scrape monitoring data from all system and Kubernetes components in your cluster and provide sensible dashboards and alerts for them to get started. But for a reliable setup, you also need to monitor your own workloads and adapt Prometheus and Grafana to your own specific use cases and cluster sizes. This document aims to give you best practices for this.
|
||||
@@ -86,7 +90,7 @@ Sometimes it is useful to monitor workloads from the outside. For this, you can
|
||||
|
||||
If you have a (micro)service architecture where multiple individual workloads within your cluster are communicating with each other, it is really important to have detailed metrics and traces about this traffic to understand how all these workloads are communicating with each other and where a problem or bottleneck may be.
|
||||
|
||||
Of course you can monitor all this internal traffic in all your workloads and expose these metrics to Prometheus. But this can quickly become quite work intensive. Service Meshes like Istio, which can be installed with [a click](https://rancher.com/docs/rancher/v2.6/en/istio/) in Rancher, can do this automatically and provide rich telemetry about the traffic between all services.
|
||||
Of course you can monitor all this internal traffic in all your workloads and expose these metrics to Prometheus. But this can quickly become quite work intensive. Service Meshes like Istio, which can be installed with [a click](../../../pages-for-subheaders/istio.md) in Rancher, can do this automatically and provide rich telemetry about the traffic between all services.
|
||||
|
||||
## Real User Monitoring
|
||||
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Best Practices for Rancher Managed vSphere Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/rancher-managed-clusters-in-vsphere"/>
|
||||
</head>
|
||||
|
||||
This guide outlines a reference architecture for provisioning downstream Rancher clusters in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
|
||||
|
||||
- [1. VM Considerations](#1-vm-considerations)
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Tips for Setting Up Containers
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers"/>
|
||||
</head>
|
||||
|
||||
Running well-built containers can greatly impact the overall performance and security of your environment.
|
||||
|
||||
Below are a few tips for setting up your containers.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Installing Rancher in a vSphere Environment
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere"/>
|
||||
</head>
|
||||
|
||||
This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
|
||||
|
||||
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Rancher Deployment Strategy
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/rancher-deployment-strategy"/>
|
||||
</head>
|
||||
|
||||
There are two recommended deployment strategies for a Rancher instance that manages downstream Kubernetes clusters. Each one has its own pros and cons. Read more about which one would fit best for your use case.
|
||||
|
||||
## Hub & Spoke Strategy
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Tips for Running Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/tips-for-running-rancher"/>
|
||||
</head>
|
||||
|
||||
This guide is geared toward use cases where Rancher is used to manage downstream Kubernetes clusters. The high-availability setup is intended to prevent losing access to downstream clusters if the Rancher server is not available.
|
||||
|
||||
A high-availability Kubernetes installation, defined as an installation of Rancher on a Kubernetes cluster with at least three nodes, should be used in any production installation of Rancher, as well as any installation deemed "important." Multiple Rancher instances running on multiple nodes ensure high availability that cannot be accomplished with a single node environment.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Tips for Scaling Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/tips-for-scaling-rancher"/>
|
||||
</head>
|
||||
|
||||
This guide aims to introduce the approaches that should be considered to scale Rancher setups, and associated challenges with doing so. As systems grow performance will naturally reduce, but there are steps we can take to minimize the load put on Rancher, as well as optimize Rancher's ability to handle these larger setups.
|
||||
|
||||
## General Tips on Optimizing Rancher's Performance
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: kubectl Utility
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cli-with-rancher/kubectl-utility"/>
|
||||
</head>
|
||||
|
||||
## kubectl
|
||||
|
||||
Interact with Rancher using kubectl.
|
||||
|
||||
@@ -3,6 +3,10 @@ title: Rancher CLI
|
||||
description: Interact with Rancher using command line interface (CLI) tools from your workstation.
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cli-with-rancher/rancher-cli"/>
|
||||
</head>
|
||||
|
||||
The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.
|
||||
|
||||
### Download Rancher CLI
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: EC2 Machine Configuration Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/amazon-ec2"/>
|
||||
</head>
|
||||
|
||||
For more details about EC2 nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
|
||||
|
||||
### Region
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Azure Machine Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/azure"/>
|
||||
</head>
|
||||
|
||||
For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)
|
||||
|
||||
### Environment
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: DigitalOcean Machine Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/digitalocean"/>
|
||||
</head>
|
||||
|
||||
For more details about DigitalOcean, Droplets, refer to the [official documentation](https://docs.digitalocean.com/products/compute/).
|
||||
|
||||
### Region
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: EC2 Node Template Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/amazon-ec2"/>
|
||||
</head>
|
||||
|
||||
For more details about EC2, nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
|
||||
|
||||
### Region
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Azure Node Template Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/azure"/>
|
||||
</head>
|
||||
|
||||
For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)
|
||||
|
||||
Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: DigitalOcean Node Template Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/digitalocean"/>
|
||||
</head>
|
||||
|
||||
Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
|
||||
|
||||
### Droplet Options
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Nutanix Node Template Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix"/>
|
||||
</head>
|
||||
|
||||
## Account Access
|
||||
|
||||
| Parameter | Required | Description | Default
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: VSphere Node Template Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere"/>
|
||||
</head>
|
||||
|
||||
## Account Access
|
||||
|
||||
| Parameter | Required | Description |
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: AKS Cluster Configuration Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration"/>
|
||||
</head>
|
||||
|
||||
## Changes in Rancher v2.6
|
||||
|
||||
- Support for adding more than one node pool
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: EKS Cluster Configuration Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/eks-cluster-configuration"/>
|
||||
</head>
|
||||
|
||||
### Account Access
|
||||
|
||||
Complete each drop-down and field using the information obtained for your IAM policy.
|
||||
|
||||
+5
-1
@@ -2,6 +2,10 @@
|
||||
title: Private Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-private-clusters"/>
|
||||
</head>
|
||||
|
||||
In GKE, [private clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/private-cluster-concept) are clusters whose nodes are isolated from inbound and outbound traffic by assigning them internal IP addresses only. Private clusters in GKE have the option of exposing the control plane endpoint as a publicly accessible address or as a private address. This is different from other Kubernetes providers, which may refer to clusters with private control plane endpoints as "private clusters" but still allow traffic to and from nodes. You may want to create a cluster with private nodes, with or without a public control plane endpoint, depending on your organization's networking and security requirements. A GKE cluster provisioned from Rancher can use isolated nodes by selecting "Private Cluster" in the Cluster Options (under "Show advanced options"). The control plane endpoint can optionally be made private by selecting "Enable Private Endpoint".
|
||||
|
||||
### Private Nodes
|
||||
@@ -26,7 +30,7 @@ This scenario is not officially supported, but is described for cases in which u
|
||||
|
||||
:::
|
||||
|
||||
If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](https://rancher.com/docs/rancher/v2.6/en/installation/other-installation-methods/air-gap/) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.
|
||||
If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.
|
||||
|
||||
### Private Control Plane Endpoint
|
||||
|
||||
|
||||
+316
-37
@@ -15,94 +15,158 @@ You can configure the Kubernetes options one of two ways:
|
||||
- [Rancher UI](#configuration-options-in-the-rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster.
|
||||
- [Cluster Config File](#cluster-config-file): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create a K3s config file. Using a config file allows you to set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available in an K3s installation.
|
||||
|
||||
## Editing Clusters in the Rancher UI
|
||||
|
||||
The Rancher UI provides two ways to edit a cluster:
|
||||
1. With a form.
|
||||
1. With YAML.
|
||||
|
||||
### Editing Clusters with a Form
|
||||
|
||||
The form covers the most frequently needed options for clusters.
|
||||
|
||||
To edit your cluster,
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster you want to configure and click **⋮ > Edit Config**.
|
||||
|
||||
### Editing Clusters in YAML
|
||||
|
||||
For a complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
|
||||
|
||||
To edit your cluster with YAML:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster you want to configure and click **⋮ > Edit as YAML**.
|
||||
1. Edit the RKE options under the `rkeConfig` directive.
|
||||
|
||||
## Configuration Options in the Rancher UI
|
||||
|
||||
:::tip
|
||||
### Machine Pool Configuration
|
||||
|
||||
Some advanced configuration options are not exposed in the Rancher UI forms, but they can be enabled by editing the K3s cluster configuration file in YAML. For the complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
|
||||
This subsection covers generic machine pool configurations. For specific infrastructure provider configurations, refer to the following:
|
||||
|
||||
:::
|
||||
- [Azure](../downstream-cluster-configuration/machine-configuration/azure.md)
|
||||
- [DigitalOcean](../downstream-cluster-configuration/machine-configuration/digitalocean.md)
|
||||
- [EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
|
||||
|
||||
### Basics
|
||||
#### Kubernetes Version
|
||||
##### Pool Name
|
||||
|
||||
The name of the machine pool.
|
||||
|
||||
##### Machine Count
|
||||
|
||||
The number of machines in the pool.
|
||||
|
||||
##### Roles
|
||||
|
||||
Option to assign etcd, control plane, and worker roles to nodes.
|
||||
|
||||
#### Advanced
|
||||
|
||||
##### Auto Replace
|
||||
|
||||
The amount of time nodes can be unreachable before they are automatically deleted and replaced.
|
||||
|
||||
##### Drain Before Delete
|
||||
|
||||
Enables draining nodes by evicting all pods before the node is deleted.
|
||||
|
||||
##### Kubernetes Node Labels
|
||||
|
||||
Add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to nodes to help with organization and object selection.
|
||||
|
||||
For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)
|
||||
|
||||
##### Taints
|
||||
|
||||
Add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to nodes, to prevent pods from being scheduled to or executed on the nodes, unless the pods have matching tolerations.
|
||||
|
||||
### Cluster Configuration
|
||||
#### Basics
|
||||
##### Kubernetes Version
|
||||
|
||||
The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
|
||||
|
||||
For more detail, see [Upgrading Kubernetes](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).
|
||||
|
||||
#### Encrypt Secrets
|
||||
##### Pod Security Admission Configuration Template
|
||||
|
||||
The default [pod security admission configuration template](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) for the cluster.
|
||||
|
||||
##### Encrypt Secrets
|
||||
|
||||
Option to enable or disable secrets encryption. When enabled, secrets will be encrypted using a AES-CBC key. If disabled, any previously secrets will not be readable until encryption is enabled again. Refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/advanced/#secrets-encryption-config-experimental) for details.
|
||||
|
||||
#### Project Network Isolation
|
||||
##### Project Network Isolation
|
||||
|
||||
If your network provider allows project network isolation, you can choose whether to enable or disable inter-project communication.
|
||||
|
||||
#### SELinux
|
||||
##### SELinux
|
||||
|
||||
Option to enable or disable [SELinux](https://rancher.com/docs/k3s/latest/en/advanced/#selinux-support) support.
|
||||
|
||||
#### CoreDNS
|
||||
##### CoreDNS
|
||||
|
||||
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/networking/#coredns) for details..
|
||||
|
||||
#### Klipper Service LB
|
||||
##### Klipper Service LB
|
||||
|
||||
Option to enable or disable the [Klipper](https://github.com/rancher/klipper-lb) service load balancer. Refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/networking/#service-load-balancer) for details.
|
||||
|
||||
#### Traefik Ingress
|
||||
##### Traefik Ingress
|
||||
|
||||
Option to enable or disable the [Traefik](https://traefik.io/) HTTP reverse proxy and load balancer. For more details and configuration options, see the [K3s documentation](https://rancher.com/docs/k3s/latest/en/networking/#traefik-ingress-controller).
|
||||
|
||||
#### Local Storage
|
||||
##### Local Storage
|
||||
|
||||
Option to enable or disable [local storage](https://rancher.com/docs/k3s/latest/en/storage/) on the node(s).
|
||||
|
||||
#### Metrics Server
|
||||
##### Metrics Server
|
||||
|
||||
Option to enable or disable the [metrics server](https://github.com/kubernetes-incubator/metrics-server). If enabled, ensure port 10250 is opened for inbound TCP traffic.
|
||||
|
||||
### Add-On Config
|
||||
#### Add-On Config
|
||||
|
||||
Additional Kubernetes manifests, managed as a [Add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/), to apply to the cluster on startup. Refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/helm/#automatically-deploying-manifests-and-helm-charts) for details.
|
||||
|
||||
### Agent Environment Vars
|
||||
#### Agent Environment Vars
|
||||
|
||||
Option to set environment variables for [K3s agents](https://rancher.com/docs/k3s/latest/en/architecture/). The environment variables can be set using key value pairs. Refer to the [K3 documentation](https://rancher.com/docs/k3s/latest/en/installation/install-options/agent-config/) for more details.
|
||||
|
||||
### etcd
|
||||
#### etcd
|
||||
|
||||
#### Automatic Snapshots
|
||||
##### Automatic Snapshots
|
||||
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/backup-restore/#creating-snapshots).
|
||||
|
||||
#### Metrics
|
||||
##### Metrics
|
||||
|
||||
Option to choose whether to expose etcd metrics to the public or only within the cluster.
|
||||
|
||||
### Networking
|
||||
#### Networking
|
||||
|
||||
#### Cluster CIDR
|
||||
##### Cluster CIDR
|
||||
|
||||
IPv4/IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
|
||||
|
||||
#### Service CIDR
|
||||
##### Service CIDR
|
||||
|
||||
IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
|
||||
|
||||
#### Cluster DNS
|
||||
##### Cluster DNS
|
||||
|
||||
IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: 10.43.0.10).
|
||||
|
||||
#### Cluster Domain
|
||||
##### Cluster Domain
|
||||
|
||||
Select the domain for the cluster. The default is `cluster.local`.
|
||||
|
||||
#### NodePort Service Port Range
|
||||
##### NodePort Service Port Range
|
||||
|
||||
Option to change the range of ports that can be used for [NodePort services](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport). The default is `30000-32767`.
|
||||
|
||||
#### Truncate Hostnames
|
||||
##### Truncate Hostnames
|
||||
|
||||
Option to truncate hostnames to 15 characters or less. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15 character limit after cluster creation.
|
||||
|
||||
@@ -110,11 +174,11 @@ This setting only affects machine-provisioned clusters. Since custom clusters se
|
||||
|
||||
Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or less.
|
||||
|
||||
#### TLS Alternate Names
|
||||
##### TLS Alternate Names
|
||||
|
||||
Add additional hostnames or IPv4/IPv6 addresses as Subject Alternative Names on the server TLS cert.
|
||||
|
||||
#### Authorized Cluster Endpoint
|
||||
##### Authorized Cluster Endpoint
|
||||
|
||||
Authorized Cluster Endpoint can be used to directly access the Kubernetes API server, without requiring communication through Rancher.
|
||||
|
||||
@@ -122,34 +186,249 @@ For more detail on how an authorized cluster endpoint works and why it is used,
|
||||
|
||||
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint-ace)
|
||||
|
||||
### Registries
|
||||
#### Registries
|
||||
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [K3s documentation](https://rancher.com/docs/k3s/latest/en/installation/private-registry/).
|
||||
|
||||
### Upgrade Strategy
|
||||
#### Upgrade Strategy
|
||||
|
||||
#### Controle Plane Concurrency
|
||||
##### Control Plane Concurrency
|
||||
|
||||
Select how many nodes can be upgraded at the same time. Can be a fixed number or percentage.
|
||||
|
||||
#### Worker Concurrency
|
||||
##### Worker Concurrency
|
||||
|
||||
Select how many nodes can be upgraded at the same time. Can be a fixed number or percentage.
|
||||
|
||||
#### Drain Nodes (Control Plane)
|
||||
##### Drain Nodes (Control Plane)
|
||||
|
||||
Option to remove all pods from the node prior to upgrading.
|
||||
|
||||
#### Drain Nodes (Worker Nodes)
|
||||
##### Drain Nodes (Worker Nodes)
|
||||
|
||||
Option to remove all pods from the node prior to upgrading.
|
||||
|
||||
### Advanced
|
||||
#### Advanced
|
||||
|
||||
Option to set kubelet options for different nodes. For available options, refer to the [Kubernetes documentation](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/).
|
||||
|
||||
## Cluster Config File
|
||||
## Cluster Config File Reference
|
||||
|
||||
Instead of using the Rancher UI forms to choose Kubernetes options for the cluster, advanced users can create an K3s config file. Using a config file allows you to set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available in an K3s installation.
|
||||
Editing clusters in YAML allows you to set configurations that are already listed in [Configuration Options in the Rancher UI](#configuration-options-in-the-rancher-ui), as well as set Rancher-specific parameters.
|
||||
|
||||
To edit an K3s config file directly from the Rancher UI, click **Edit as YAML**.
|
||||
<details>
|
||||
<summary>
|
||||
<b>Example Cluster Config File Snippet</b>
|
||||
</summary>
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
spec:
|
||||
cloudCredentialSecretName: cattle-global-data:cc-fllv6
|
||||
clusterAgentDeploymentCustomization: {}
|
||||
fleetAgentDeploymentCustomization: {}
|
||||
kubernetesVersion: v1.26.7+k3s1
|
||||
localClusterAuthEndpoint: {}
|
||||
rkeConfig:
|
||||
chartValues: {}
|
||||
etcd:
|
||||
snapshotRetention: 5
|
||||
snapshotScheduleCron: 0 */5 * * *
|
||||
machineGlobalConfig:
|
||||
disable-apiserver: false
|
||||
disable-cloud-controller: false
|
||||
disable-controller-manager: false
|
||||
disable-etcd: false
|
||||
disable-kube-proxy: false
|
||||
disable-network-policy: false
|
||||
disable-scheduler: false
|
||||
etcd-expose-metrics: false
|
||||
kube-apiserver-arg:
|
||||
- audit-policy-file=/etc/rancher/k3s/user-audit-policy.yaml
|
||||
- audit-log-path=/etc/rancher/k3s/user-audit.logs
|
||||
profile: null
|
||||
secrets-encryption: false
|
||||
machinePools:
|
||||
- controlPlaneRole: true
|
||||
etcdRole: true
|
||||
machineConfigRef:
|
||||
kind: Amazonec2Config
|
||||
name: nc-test-pool1-pwl5h
|
||||
name: pool1
|
||||
quantity: 1
|
||||
unhealthyNodeTimeout: 0s
|
||||
workerRole: true
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
docker: false
|
||||
protect-kernel-defaults: false
|
||||
selinux: false
|
||||
machineSelectorFiles:
|
||||
- fileSources:
|
||||
- configMap:
|
||||
name: ''
|
||||
secret:
|
||||
name: audit-policy
|
||||
items:
|
||||
- key: audit-policy
|
||||
path: /etc/rancher/k3s/user-audit-policy.yaml
|
||||
machineLabelSelector:
|
||||
matchLabels:
|
||||
rke.cattle.io/control-plane-role: 'true'
|
||||
registries: {}
|
||||
upgradeStrategy:
|
||||
controlPlaneConcurrency: '1'
|
||||
controlPlaneDrainOptions:
|
||||
deleteEmptyDirData: true
|
||||
disableEviction: false
|
||||
enabled: false
|
||||
force: false
|
||||
gracePeriod: -1
|
||||
ignoreDaemonSets: true
|
||||
ignoreErrors: false
|
||||
postDrainHooks: null
|
||||
preDrainHooks: null
|
||||
skipWaitForDeleteTimeoutSeconds: 0
|
||||
timeout: 120
|
||||
workerConcurrency: '1'
|
||||
workerDrainOptions:
|
||||
deleteEmptyDirData: true
|
||||
disableEviction: false
|
||||
enabled: false
|
||||
force: false
|
||||
gracePeriod: -1
|
||||
ignoreDaemonSets: true
|
||||
ignoreErrors: false
|
||||
postDrainHooks: null
|
||||
preDrainHooks: null
|
||||
skipWaitForDeleteTimeoutSeconds: 0
|
||||
timeout: 120
|
||||
```
|
||||
</details>
|
||||
|
||||
### chartValues
|
||||
|
||||
Specify the values for the system charts installed by K3s.
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
chartValues:
|
||||
chart-name:
|
||||
key: value
|
||||
```
|
||||
### machineGlobalConfig
|
||||
|
||||
Specify K3s configurations. Any configuration change made here will apply to every node. The configuration options available in the [standalone version of k3s](https://docs.k3s.io/cli/server) can be applied here.
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
machineGlobalConfig:
|
||||
etcd-arg:
|
||||
- key1=value1
|
||||
- key2=value2
|
||||
```
|
||||
|
||||
### machineSelectorConfig
|
||||
|
||||
`machineSelectorConfig` is the same as [`machineGlobalConfig`](#machineglobalconfig) except that a [label](#kubernetes-node-labels) selector can be specified with the configuration. The configuration will only be applied to nodes that match the provided label selector.
|
||||
|
||||
Multiple `config` entries are allowed, each specifying their own `machineLabelSelector`. A user can specify `matchExpressions`, `matchLabels`, both, or neither. Omitting the `machineLabelSelector` section of this field has the same effect as putting the config in the `machineGlobalConfig` section.
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
machineSelectorConfig
|
||||
- config:
|
||||
config-key: config-value
|
||||
machineLabelSelector:
|
||||
matchExpressions:
|
||||
- key: example-key
|
||||
operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
|
||||
values:
|
||||
- example-value1
|
||||
- example-value2
|
||||
matchLabels:
|
||||
key1: value1
|
||||
key2: value2
|
||||
```
|
||||
### machineSelectorFiles
|
||||
|
||||
:::note
|
||||
|
||||
This feature is available in Rancher v2.7.2 and later.
|
||||
|
||||
:::
|
||||
|
||||
Deliver files to nodes, so that the files can be in place before initiating K3s server or agent processes.
|
||||
The content of the file is retrieved from either a secret or a configmap. The target nodes are filtered by the `machineLabelSelector`.
|
||||
|
||||
Example :
|
||||
|
||||
```yaml
|
||||
machineSelectorFiles:
|
||||
- fileSources:
|
||||
- secret:
|
||||
items:
|
||||
- key: example-key
|
||||
path: path-to-put-the-file-on-nodes
|
||||
permissions: 644 (optional)
|
||||
hash: base64-encoded-hash-of-the-content (optional)
|
||||
name: example-secret-name
|
||||
machineLabelSelector:
|
||||
matchExpressions:
|
||||
- key: example-key
|
||||
operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
|
||||
values:
|
||||
- example-value1
|
||||
- example-value2
|
||||
matchLabels:
|
||||
key1: value1
|
||||
key2: value2
|
||||
- fileSources:
|
||||
- configMap:
|
||||
items:
|
||||
- key: example-key
|
||||
path: path-to-put-the-file-on-nodes
|
||||
permissions: 644 (optional)
|
||||
hash: base64-encoded-hash-of-the-content (optional)
|
||||
name: example-configmap-name
|
||||
machineLabelSelector:
|
||||
matchExpressions:
|
||||
- key: example-key
|
||||
operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
|
||||
values:
|
||||
- example-value1
|
||||
- example-value2
|
||||
matchLabels:
|
||||
key1: value1
|
||||
key2: value2
|
||||
```
|
||||
|
||||
The secret or configmap must meet the following requirements:
|
||||
|
||||
1. It must be in the `fleet-default` namespace where the Cluster object exists.
|
||||
2. It must have the annotation `rke.cattle.io/object-authorized-for-clusters: cluster-name1,cluster-name2`, which permits the target clusters to use it.
|
||||
|
||||
:::tip
|
||||
|
||||
Rancher Dashboard provides an easy-to-use form for creating the secret or configmap.
|
||||
|
||||
:::
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
audit-policy: >-
|
||||
IyBMb2cgYWxsIHJlcXVlc3RzIGF0IHRoZSBNZXRhZGF0YSBsZXZlbC4KYXBpVmVyc2lvbjogYXVkaXQuazhzLmlvL3YxCmtpbmQ6IFBvbGljeQpydWxlczoKLSBsZXZlbDogTWV0YWRhdGE=
|
||||
kind: Secret
|
||||
metadata:
|
||||
annotations:
|
||||
rke.cattle.io/object-authorized-for-clusters: cluster1
|
||||
name: name1
|
||||
namespace: fleet-default
|
||||
```
|
||||
|
||||
+3
-3
@@ -119,15 +119,15 @@ Rancher v2.6 introduced the ability to configure [ECR registries for RKE cluster
|
||||
|
||||
### Authorized Cluster Endpoint
|
||||
|
||||
Authorized Cluster Endpoint can be used to directly access the Kubernetes API server, without requiring communication through Rancher.
|
||||
Authorized Cluster Endpoint (ACE) can be used to directly access the Kubernetes API server, without requiring communication through Rancher.
|
||||
|
||||
:::note
|
||||
|
||||
The authorized cluster endpoint only works on Rancher-launched Kubernetes clusters. In other words, it only works in clusters where Rancher [used RKE](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#tools-for-provisioning-kubernetes-clusters) to provision the cluster. It is not available for clusters in a hosted Kubernetes provider, such as Amazon's EKS.
|
||||
ACE is available on RKE, RKE2, and K3s clusters that are provisioned or registered with Rancher. It's not available on clusters in a hosted Kubernetes provider, such as Amazon's EKS.
|
||||
|
||||
:::
|
||||
|
||||
This is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates.
|
||||
ACE must be set up [manually](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters.md) on RKE2 and K3s clusters. In RKE, ACE is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self-signed certificates.
|
||||
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint)
|
||||
|
||||
|
||||
+167
-67
@@ -15,18 +15,26 @@ You can configure the Kubernetes options in one of the two following ways:
|
||||
- [Rancher UI](#configuration-options-in-the-rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster.
|
||||
- [Cluster Config File](#cluster-config-file-reference): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE2 config file. Using a config file allows you to set many additional [options](https://docs.rke2.io/install/configuration) available for an RKE2 installation.
|
||||
|
||||
## Editing Clusters with a Form in the Rancher UI
|
||||
## Editing Clusters in the Rancher UI
|
||||
|
||||
The Rancher UI provides two ways to edit a cluster:
|
||||
1. With a form.
|
||||
1. With YAML.
|
||||
|
||||
### Editing Clusters with a Form
|
||||
|
||||
The form covers the most frequently needed options for clusters.
|
||||
|
||||
To edit your cluster,
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster you want to configure and click **⋮ > Edit Config**.
|
||||
|
||||
## Editing Clusters with YAML
|
||||
### Editing Clusters in YAML
|
||||
|
||||
Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE2 config file. Using a config file allows you to set any of the options available in an RKE2 installation by specifying them in YAML.
|
||||
For a complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
|
||||
|
||||
To edit an RKE2 config file directly from the Rancher UI,
|
||||
To edit your cluster in YAML:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster you want to configure and click **⋮ > Edit as YAML**.
|
||||
@@ -34,62 +42,55 @@ To edit an RKE2 config file directly from the Rancher UI,
|
||||
|
||||
## Configuration Options in the Rancher UI
|
||||
|
||||
:::tip
|
||||
### Machine Pool Configuration
|
||||
|
||||
Some advanced configuration options are not exposed in the Rancher UI forms, but they can be enabled by editing the RKE2 cluster configuration file in YAML. For the complete reference of configurable options for RKE2 Kubernetes clusters in YAML, see the [RKE2 documentation.](https://docs.rke2.io/install/configuration)
|
||||
|
||||
:::
|
||||
|
||||
## Machine Pool
|
||||
|
||||
This subsection covers the generic machine pool configurations. For infrastructure provider specific, configurations refer to the following pages:
|
||||
This subsection covers generic machine pool configurations. For specific infrastructure provider configurations, refer to the following:
|
||||
|
||||
- [Azure](../downstream-cluster-configuration/machine-configuration/azure.md)
|
||||
- [DigitalOcean](../downstream-cluster-configuration/machine-configuration/digitalocean.md)
|
||||
- [EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
|
||||
|
||||
### Pool Name
|
||||
##### Pool Name
|
||||
|
||||
The name of the machine pool.
|
||||
|
||||
### Machine Count
|
||||
##### Machine Count
|
||||
|
||||
The number of machines in the pool.
|
||||
|
||||
### Roles
|
||||
##### Roles
|
||||
|
||||
Option to assign etcd, control plane, and worker roles to nodes.
|
||||
|
||||
### Advanced
|
||||
#### Advanced
|
||||
|
||||
#### Auto Replace
|
||||
##### Auto Replace
|
||||
|
||||
The duration nodes can be unreachable before they are automatically deleted and replaced.
|
||||
The amount of time nodes can be unreachable before they are automatically deleted and replaced.
|
||||
|
||||
#### Drain Before Delete
|
||||
##### Drain Before Delete
|
||||
|
||||
Enables draining nodes by evicting all pods before the node is deleted.
|
||||
|
||||
#### Kubernetes Node Labels
|
||||
##### Kubernetes Node Labels
|
||||
|
||||
Add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to nodes to help with organization and object selection.
|
||||
|
||||
For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)
|
||||
|
||||
#### Taints
|
||||
##### Taints
|
||||
|
||||
Add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to nodes, which can be used to prevent pods from being scheduled to or executed on nodes, unless the pods have matching tolerations.
|
||||
Add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to nodes, to prevent pods from being scheduled to or executed on the nodes, unless the pods have matching tolerations.
|
||||
|
||||
## Cluster Configuration
|
||||
|
||||
### Basics
|
||||
#### Kubernetes Version
|
||||
### Cluster Configuration
|
||||
#### Basics
|
||||
##### Kubernetes Version
|
||||
|
||||
The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
|
||||
|
||||
For more detail, see [Upgrading Kubernetes](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).
|
||||
|
||||
#### Container Network Provider
|
||||
##### Container Network Provider
|
||||
|
||||
The [Network Provider](https://kubernetes.io/docs/concepts/cluster-administration/networking/) that the cluster uses.
|
||||
|
||||
@@ -110,7 +111,7 @@ Out of the box, Rancher is compatible with the following network providers:
|
||||
|
||||
For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/install/network_options).
|
||||
|
||||
##### Dual-stack Networking
|
||||
###### Dual-stack Networking
|
||||
|
||||
[Dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) networking is supported for all CNI providers. To configure RKE2 in dual-stack mode, set valid IPv4/IPv6 CIDRs for your [Cluster CIDR](#cluster-cidr) and/or [Service CIDR](#service-cidr).
|
||||
|
||||
@@ -118,7 +119,7 @@ For more details on the different networking providers and how to configure them
|
||||
|
||||
When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.
|
||||
|
||||
#### Cloud Provider
|
||||
##### Cloud Provider
|
||||
|
||||
You can configure a [Kubernetes cloud provider](../../../pages-for-subheaders/set-up-cloud-providers.md). If you want to use dynamically provisioned [volumes and storage](../../../pages-for-subheaders/create-kubernetes-persistent-storage.md) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider.
|
||||
|
||||
@@ -128,89 +129,93 @@ If the cloud provider you want to use is not listed as an option, you will need
|
||||
|
||||
:::
|
||||
|
||||
#### Default Pod Security Policy
|
||||
##### Default Pod Security Policy
|
||||
|
||||
Choose the default [pod security policy](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) for the cluster. Please refer to the [RKE2 documentation](https://docs.rke2.io/security/pod_security_policies) on the specifications of each available policy.
|
||||
The default [pod security policy](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) for the cluster. Please refer to the [RKE2 documentation](https://docs.rke2.io/security/pod_security_policies) on the specifications of each available policy.
|
||||
|
||||
#### Worker CIS Profile
|
||||
##### Pod Security Admission Configuration Template
|
||||
|
||||
The default [pod security admission configuration template](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) for the cluster.
|
||||
|
||||
##### Worker CIS Profile
|
||||
|
||||
Select a [CIS benchmark](../../../pages-for-subheaders/cis-scan-guides.md) to validate the system configuration against.
|
||||
|
||||
#### Project Network Isolation
|
||||
##### Project Network Isolation
|
||||
|
||||
If your network provider allows project network isolation, you can choose whether to enable or disable inter-project communication.
|
||||
|
||||
Project network isolation is available if you are using any RKE2 network plugin that supports the enforcement of Kubernetes network policies, such as Canal.
|
||||
|
||||
#### CoreDNS
|
||||
##### CoreDNS
|
||||
|
||||
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#coredns) for additional CoreDNS configurations.
|
||||
|
||||
#### NGINX Ingress
|
||||
##### NGINX Ingress
|
||||
|
||||
If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
|
||||
|
||||
Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
|
||||
|
||||
#### Metrics Server
|
||||
##### Metrics Server
|
||||
|
||||
Option to enable or disable [Metrics Server](https://rancher.com/docs/rke/latest/en/config-options/add-ons/metrics-server/).
|
||||
|
||||
Each cloud provider capable of launching a cluster using RKE2 can collect metrics and monitor for your cluster nodes. Enable this option to view your node metrics from your cloud provider's portal.
|
||||
|
||||
### Add-On Config
|
||||
#### Add-On Config
|
||||
|
||||
Additional Kubernetes manifests, managed as an [Add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/), to apply to the cluster on startup. Refer to the [RKE2 documentation](https://docs.rke2.io/helm#automatically-deploying-manifests-and-helm-charts) for details.
|
||||
|
||||
### Agent Environment Vars
|
||||
#### Agent Environment Vars
|
||||
|
||||
Option to set environment variables for [Rancher agents](https://rancher.com/docs/rancher/v2.6/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. Refer to the [RKE2 documentation](https://docs.rke2.io/reference/linux_agent_config) for more details.
|
||||
Option to set environment variables for [Rancher agents](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md). The environment variables can be set using key value pairs. Refer to the [RKE2 documentation](https://docs.rke2.io/reference/linux_agent_config) for more details.
|
||||
|
||||
### etcd
|
||||
#### etcd
|
||||
|
||||
#### Automatic Snapshots
|
||||
##### Automatic Snapshots
|
||||
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
|
||||
#### Metrics
|
||||
##### Metrics
|
||||
|
||||
Option to choose whether to expose etcd metrics to the public or only within the cluster.
|
||||
|
||||
### Networking
|
||||
#### Networking
|
||||
|
||||
#### Cluster CIDR
|
||||
##### Cluster CIDR
|
||||
|
||||
IPv4 and/or IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
|
||||
|
||||
##### Dual-stack Networking
|
||||
###### Dual-stack Networking
|
||||
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
|
||||
[Additional configuration](#dual-stack-additional-config) is required when using `cilium` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
|
||||
|
||||
#### Service CIDR
|
||||
##### Service CIDR
|
||||
|
||||
IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
|
||||
|
||||
##### Dual-stack Networking
|
||||
###### Dual-stack Networking
|
||||
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
|
||||
[Additional configuration](#dual-stack-additional-config) is required when using `cilium ` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
|
||||
|
||||
#### Cluster DNS
|
||||
##### Cluster DNS
|
||||
|
||||
IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: 10.43.0.10).
|
||||
|
||||
#### Cluster Domain
|
||||
##### Cluster Domain
|
||||
|
||||
Select the domain for the cluster. The default is `cluster.local`.
|
||||
|
||||
#### NodePort Service Port Range
|
||||
##### NodePort Service Port Range
|
||||
|
||||
Option to change the range of ports that can be used for [NodePort services](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport). The default is `30000-32767`.
|
||||
|
||||
#### Truncate Hostnames
|
||||
##### Truncate Hostnames
|
||||
|
||||
Option to truncate hostnames to 15 characters or less. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15 character limit after cluster creation.
|
||||
|
||||
@@ -218,11 +223,11 @@ This setting only affects machine-provisioned clusters. Since custom clusters se
|
||||
|
||||
Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or less.
|
||||
|
||||
#### TLS Alternate Names
|
||||
##### TLS Alternate Names
|
||||
|
||||
Add additional hostnames or IPv4/IPv6 addresses as Subject Alternative Names on the server TLS cert.
|
||||
|
||||
#### Authorized Cluster Endpoint
|
||||
##### Authorized Cluster Endpoint
|
||||
|
||||
Authorized Cluster Endpoint can be used to directly access the Kubernetes API server, without requiring communication through Rancher.
|
||||
|
||||
@@ -232,35 +237,35 @@ For more detail on how an authorized cluster endpoint works and why it is used,
|
||||
|
||||
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint-ace)
|
||||
|
||||
### Registries
|
||||
#### Registries
|
||||
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/containerd_registry_configuration).
|
||||
|
||||
### Upgrade Strategy
|
||||
#### Upgrade Strategy
|
||||
|
||||
#### Control Plane Concurrency
|
||||
##### Control Plane Concurrency
|
||||
|
||||
Select how many nodes can be upgraded at the same time. Can be a fixed number or percentage.
|
||||
|
||||
#### Worker Concurrency
|
||||
##### Worker Concurrency
|
||||
|
||||
Select how many nodes can be upgraded at the same time. Can be a fixed number or percentage.
|
||||
|
||||
#### Drain Nodes (Control Plane)
|
||||
##### Drain Nodes (Control Plane)
|
||||
|
||||
Option to remove all pods from the node prior to upgrading.
|
||||
|
||||
#### Drain Nodes (Worker Nodes)
|
||||
##### Drain Nodes (Worker Nodes)
|
||||
|
||||
Option to remove all pods from the node prior to upgrading.
|
||||
|
||||
### Advanced
|
||||
#### Advanced
|
||||
|
||||
Option to set kubelet options for different nodes. For available options, refer to the [Kubernetes documentation](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/).
|
||||
|
||||
## Cluster Config File Reference
|
||||
|
||||
Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create a config file. Using a config file allows you to set the [options available](https://docs.rke2.io/install/configuration) in an RKE2 installation, including those already listed in [Configuration Options in the Rancher UI](#configuration-options-in-the-rancher-ui), as well as Rancher-specific parameters.
|
||||
Editing clusters in YAML allows you to set the [options available](https://docs.rke2.io/install/configuration) in an RKE2 installation, including those already listed in [Configuration Options in the Rancher UI](#configuration-options-in-the-rancher-ui), as well as set Rancher-specific parameters.
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
@@ -268,9 +273,11 @@ Instead of using the Rancher UI to choose Kubernetes options for the cluster, ad
|
||||
</summary>
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
spec:
|
||||
cloudCredentialSecretName: cattle-global-data:cc-s879v
|
||||
kubernetesVersion: v1.23.6+rke2r2
|
||||
kubernetesVersion: v1.25.12+rke2r1
|
||||
localClusterAuthEndpoint: {}
|
||||
rkeConfig:
|
||||
chartValues:
|
||||
@@ -283,6 +290,9 @@ spec:
|
||||
disable-kube-proxy: false
|
||||
etcd-expose-metrics: false
|
||||
profile: null
|
||||
kube-apiserver-arg:
|
||||
- audit-policy-file=/etc/rancher/rke2/user-audit-policy.yaml
|
||||
- audit-log-path=/etc/rancher/rke2/user-audit.logs
|
||||
machinePools:
|
||||
- controlPlaneRole: true
|
||||
etcdRole: true
|
||||
@@ -296,6 +306,18 @@ spec:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
protect-kernel-defaults: false
|
||||
machineSelectorFiles:
|
||||
- fileSources:
|
||||
- configMap:
|
||||
name: ''
|
||||
secret:
|
||||
name: audit-policy
|
||||
items:
|
||||
- key: audit-policy
|
||||
path: /etc/rancher/rke2/user-audit-policy.yaml
|
||||
machineLabelSelector:
|
||||
matchLabels:
|
||||
rke.cattle.io/control-plane-role: 'true'
|
||||
registries: {}
|
||||
upgradeStrategy:
|
||||
controlPlaneConcurrency: "1"
|
||||
@@ -317,7 +339,7 @@ spec:
|
||||
|
||||
### chartValues
|
||||
|
||||
Option to specify the values for the system charts installed by RKE2/k3s.
|
||||
Specify the values for the system charts installed by RKE2.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -328,7 +350,7 @@ chartValues:
|
||||
```
|
||||
### machineGlobalConfig
|
||||
|
||||
The RKE2/K3s configurations are nested under the `machineGlobalConfig` directive. Any configuration change made here will apply to every node. The configuration options available in the [standalone version of RKE2](https://docs.rke2.io/reference/server_config) can be applied here.
|
||||
Specify RKE2 configurations. Any configuration change made here will apply to every node. The configuration options available in the [standalone version of RKE2](https://docs.rke2.io/reference/server_config) can be applied here.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -341,9 +363,9 @@ machineGlobalConfig:
|
||||
|
||||
### machineSelectorConfig
|
||||
|
||||
This is the same as [`machineGlobalConfig`](#machineglobalconfig) except that a [label](#kubernetes-node-labels) selector can be specified with the configuration. The configuration will only be applied to nodes that match the provided label selector.
|
||||
`machineSelectorConfig` is the same as [`machineGlobalConfig`](#machineglobalconfig) except that a [label](#kubernetes-node-labels) selector can be specified with the configuration. The configuration will only be applied to nodes that match the provided label selector.
|
||||
|
||||
Multiple `config` entries are allowed, each specifying their own `machineLabelSelector`. A user can specify `matchExpressions`, `matchLabels`, both, or neither. Omitting the `machineLabelSelector` section of this has the same effect as putting the config in the `machineGlobalConfig` section.
|
||||
Multiple `config` entries are allowed, each specifying their own `machineLabelSelector`. A user can specify `matchExpressions`, `matchLabels`, both, or neither. Omitting the `machineLabelSelector` section of this field has the same effect as putting the config in the `machineGlobalConfig` section.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -362,3 +384,81 @@ machineSelectorConfig
|
||||
key1: value1
|
||||
key2: value2
|
||||
```
|
||||
### machineSelectorFiles
|
||||
|
||||
:::note
|
||||
|
||||
This feature is available in Rancher v2.7.2 and later.
|
||||
|
||||
:::
|
||||
|
||||
Deliver files to nodes, so that the files can be in place before initiating RKE2 server or agent processes.
|
||||
The content of the file is retrieved from either a secret or a configmap. The target nodes are filtered by the `machineLabelSelector`.
|
||||
|
||||
Example :
|
||||
|
||||
```yaml
|
||||
machineSelectorFiles:
|
||||
- fileSources:
|
||||
- secret:
|
||||
items:
|
||||
- key: example-key
|
||||
path: path-to-put-the-file-on-nodes
|
||||
permissions: 644 (optional)
|
||||
hash: base64-encoded-hash-of-the-content (optional)
|
||||
name: example-secret-name
|
||||
machineLabelSelector:
|
||||
matchExpressions:
|
||||
- key: example-key
|
||||
operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
|
||||
values:
|
||||
- example-value1
|
||||
- example-value2
|
||||
matchLabels:
|
||||
key1: value1
|
||||
key2: value2
|
||||
- fileSources:
|
||||
- configMap:
|
||||
items:
|
||||
- key: example-key
|
||||
path: path-to-put-the-file-on-nodes
|
||||
permissions: 644 (optional)
|
||||
hash: base64-encoded-hash-of-the-content (optional)
|
||||
name: example-configmap-name
|
||||
machineLabelSelector:
|
||||
matchExpressions:
|
||||
- key: example-key
|
||||
operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
|
||||
values:
|
||||
- example-value1
|
||||
- example-value2
|
||||
matchLabels:
|
||||
key1: value1
|
||||
key2: value2
|
||||
```
|
||||
|
||||
The secret or configmap must meet the following requirements:
|
||||
|
||||
1. It must be in the `fleet-default` namespace where the Cluster object exists.
|
||||
2. It must have the annotation `rke.cattle.io/object-authorized-for-clusters: cluster-name1,cluster-name2`, which permits the target clusters to use it.
|
||||
|
||||
:::tip
|
||||
|
||||
Rancher Dashboard provides an easy-to-use form for creating the secret or configmap.
|
||||
|
||||
:::
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
audit-policy: >-
|
||||
IyBMb2cgYWxsIHJlcXVlc3RzIGF0IHRoZSBNZXRhZGF0YSBsZXZlbC4KYXBpVmVyc2lvbjogYXVkaXQuazhzLmlvL3YxCmtpbmQ6IFBvbGljeQpydWxlczoKLSBsZXZlbDogTWV0YWRhdGE=
|
||||
kind: Secret
|
||||
metadata:
|
||||
annotations:
|
||||
rke.cattle.io/object-authorized-for-clusters: cluster1
|
||||
name: name1
|
||||
namespace: fleet-default
|
||||
```
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Syncing
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters"/>
|
||||
</head>
|
||||
|
||||
Syncing allows Rancher to update cluster values so that they're up to date with the corresponding cluster object hosted in AKS, EKS or GKE. This enables sources other than Rancher to own a hosted cluster’s state.
|
||||
|
||||
:::warning
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Rancher Agent Options
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options"/>
|
||||
</head>
|
||||
|
||||
Rancher deploys an agent on each node to communicate with the node. This pages describes the options that can be passed to the agent. To use these options, you will need to [create a cluster with custom nodes](../../../../pages-for-subheaders/use-existing-nodes.md) and add the options to the generated `docker run` command when adding a node.
|
||||
|
||||
For an overview of how Rancher communicates with downstream clusters using node agents, refer to the [architecture section.](../../../rancher-manager-architecture/communicating-with-downstream-user-clusters.md#3-node-agents)
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Examples
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/monitoring-v2-configuration/examples"/>
|
||||
</head>
|
||||
|
||||
### ServiceMonitor
|
||||
|
||||
An example ServiceMonitor custom resource can be found [here.](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml)
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user