mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Merge branch 'main' into v2.9.4
This commit is contained in:
Lucas Saintarbor
@@ -7,4 +7,4 @@ slug: /
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com"/>
|
||||
</head>
|
||||
|
||||
This version of the documentation has been archived and is no longer published. You can still view the documentation source directly on our [GitHub repository](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4).
|
||||
This version of the documentation has been archived and is no longer published. You can still view the documentation source directly on our [GitHub repository](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4).
|
||||
|
||||
@@ -49,6 +49,10 @@ EOF
|
||||
|
||||
Setting the `field.cattle.io/creatorId` field allows the cluster member account to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
|
||||
|
||||
Setting the `field.cattle.io/creator-principal-name` annotation to the user's principal preserves it in a projectroletemplatebinding automatically created for the project owner.
|
||||
|
||||
If you don't want the creator to be added as the owner member (e.g. if the creator is a cluster administrator) to the project you may set the `field.cattle.io/no-creator-rbac` annotation to `true`, which will prevent the corresponding projectroletemplatebinding from being created.
|
||||
|
||||
### Creating a Project With a Resource Quota
|
||||
|
||||
Refer to [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/).
|
||||
@@ -91,6 +95,77 @@ spec:
|
||||
limitsMemory: 100Mi
|
||||
requestsCpu: 50m
|
||||
requestsMemory: 50Mi
|
||||
EOF
|
||||
```
|
||||
|
||||
## Adding a Member to a Project
|
||||
|
||||
Look up the project ID to specify the `metadata.namespace` field and `projectName` field values.
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
Look up the role template ID to specify the `roleTemplateName` field value (e.g. `project-member` or `project-owner`).
|
||||
|
||||
```bash
|
||||
kubectl get roletemplates
|
||||
```
|
||||
|
||||
When adding a user member specify the `userPrincipalName` field:
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: ProjectRoleTemplateBinding
|
||||
metadata:
|
||||
generateName: prtb-
|
||||
namespace: p-vwxyz
|
||||
projectName: c-m-abcde:p-vwxyz
|
||||
roleTemplateName: project-member
|
||||
userPrincipalName: keycloak_user://user
|
||||
EOF
|
||||
```
|
||||
|
||||
When adding a group member specify the `groupPrincipalName` field instead:
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: ProjectRoleTemplateBinding
|
||||
metadata:
|
||||
generateName: prtb-
|
||||
namespace: p-vwxyz
|
||||
projectName: c-m-abcde:p-vwxyz
|
||||
roleTemplateName: project-member
|
||||
groupPrincipalName: keycloak_group://group
|
||||
EOF
|
||||
```
|
||||
|
||||
Create a projectroletemplatebinding for each role you want to assign to the project member.
|
||||
|
||||
## Listing Project Members
|
||||
|
||||
Look up the project ID:
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
to list projectroletemplatebindings in the project's namespace:
|
||||
|
||||
```bash
|
||||
kubectl --namespace p-vwxyz get projectroletemplatebindings
|
||||
```
|
||||
|
||||
## Deleting a Member From a Project
|
||||
|
||||
Lookup the projectroletemplatebinding IDs containing the member in the project's namespace as decribed in the [Listing Project Members](#listing-project-members) section.
|
||||
|
||||
Delete the projectroletemplatebinding from the project's namespace:
|
||||
|
||||
```bash
|
||||
kubectl --namespace p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
|
||||
```
|
||||
|
||||
## Creating a Namespace in a Project
|
||||
@@ -132,4 +207,4 @@ Delete the project under the cluster namespace:
|
||||
kubectl --namespace c-m-abcde delete project p-vwxyz
|
||||
```
|
||||
|
||||
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
|
||||
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
|
||||
|
||||
@@ -16,9 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2) | Sep 19, 2024 |
|
||||
| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 |
|
||||
| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 |
|
||||
| [2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | Nov 18, 2024 |
|
||||
|
||||
## What can I expect when a feature is marked for deprecation?
|
||||
|
||||
|
||||
@@ -24,6 +24,8 @@ Yes. Rancher supports [Istio](../integrations-in-rancher/istio/istio.md).
|
||||
|
||||
## Will Rancher v2.x support Hashicorp's Vault for storing secrets?
|
||||
|
||||
As of Rancher v2.9, Rancher [supports authentication with service account tokens](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/jwt-authentication.md), which is used by Vault and other integrations.
|
||||
|
||||
Secrets management is on our roadmap but we haven't assigned it to a specific release yet.
|
||||
|
||||
## Does Rancher v2.x support RKT containers as well?
|
||||
|
||||
+4
-2
@@ -23,6 +23,7 @@ The following is a list of feature flags available in Rancher. If you've upgrade
|
||||
- `harvester`: Manages access to the Virtualization Management page, where users can navigate directly to Harvester clusters and access the Harvester UI. See [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md) for more information.
|
||||
- `istio-virtual-service-ui`: Enables a [visual interface](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md) to create, read, update, and delete Istio virtual services and destination rules, which are Istio traffic management features.
|
||||
- `legacy`: Enables a set of features from 2.5.x and earlier, that are slowly being phased out in favor of newer implementations. These are a mix of deprecated features as well as features that will eventually be available to newer versions. This flag is disabled by default on new Rancher installations. If you're upgrading from a previous version of Rancher, this flag is enabled.
|
||||
- `managed-system-upgrade-controller`: Enables the installation of the system-upgrade-controller app in downstream RKE2/K3s clusters, currently limited to imported clusters and the local cluster, with plans to expand support to node-driver clusters.
|
||||
- `multi-cluster-management`: Allows multi-cluster provisioning and management of Kubernetes clusters. This flag can only be set at install time. It can't be enabled or disabled later.
|
||||
- `rke1-custom-node-cleanup`: Enables cleanup of deleted RKE1 custom nodes. We recommend that you keep this flag enabled, to prevent removed nodes from attempting to rejoin the cluster.
|
||||
- `rke2`: Enables provisioning RKE2 clusters. This flag is enabled by default.
|
||||
@@ -42,8 +43,9 @@ The following table shows the availability and default values for some feature f
|
||||
| `fleet` | `true` | GA | v2.5.0 | |
|
||||
| `harvester` | `true` | Experimental | v2.6.1 | |
|
||||
| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
|
||||
| `managed-system-upgrade-controller` | `true` | GA | v2.10.0 | |
|
||||
| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 | |
|
||||
| `rke2` | `true` | Experimental | v2.6.0 | |
|
||||
| `token-hashing` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
|
||||
| `uiextension` | `true` | GA | v2.9.0 |
|
||||
| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 |
|
||||
| `uiextension` | `true` | GA | v2.9.0 | |
|
||||
| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 | |
|
||||
|
||||
+2
@@ -9,3 +9,5 @@ title: Rancher Prime
|
||||
SUSE Rancher introduces Rancher Prime – an evolution of Rancher – from version v2.7. Rancher Prime is the new commercially available enterprise offering of Rancher, built on the same open source code. The Rancher project will continue to be 100% open source. Prime introduces additional value with greater security assurances, extended lifecycles, access to focused architectures and Kubernetes advisories. Rancher Prime will also offer options to get production support for innovative Rancher projects. With Rancher Prime, installation assets are hosted on a trusted registry owned and managed by Rancher.
|
||||
|
||||
To get started with Rancher Prime, [go to this page](https://www.rancher.com/quick-start) and fill out the form.
|
||||
|
||||
At a minimum, users are expected to have a working knowledge of Kubernetes and peripheral functions such as Permissions, Roles and RBAC.
|
||||
|
||||
+8
-1
@@ -13,4 +13,11 @@ To view the generated CIS scan reports,
|
||||
1. Click **CIS Benchmark > Scan**.
|
||||
1. The **Scans** page will show the generated reports. To see a detailed report, go to a scan report and click the name.
|
||||
|
||||
One can download the report from the Scans list or from the scan detail page.
|
||||
One can download the report from the Scans list or from the scan detail page.
|
||||
|
||||
To get the verbose version of the CIS scan results, run the following command on the cluster that was scanned. Note that the scan must be completed before this can be done.
|
||||
|
||||
```console
|
||||
export REPORT="scan-report-name"
|
||||
kubectl get clusterscanreport $REPORT -o json |jq ".spec.reportJSON | fromjson" | jq -r ".actual_value_map_data" | base64 -d | gunzip | jq .
|
||||
```
|
||||
|
||||
+4
@@ -192,3 +192,7 @@ Try configuring and saving keycloak as your SAML provider and then accessing the
|
||||
|
||||
* Check your Keycloak log.
|
||||
* If the log displays `request validation failed: org.keycloak.common.VerificationException: SigAlg was null`, set `Client Signature Required` to `OFF` in your Keycloak client.
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+5
-1
@@ -107,4 +107,8 @@ The OpenLDAP service account is used for all searches. Rancher users will see us
|
||||
1. Click **Okta** or, if SAML is already configured, **Edit Config**
|
||||
1. Under **User and Group Search**, check **Configure an OpenLDAP server**
|
||||
|
||||
If you experience issues when you test the connection to the OpenLDAP server, ensure that you entered the credentials for the service account and configured the search base correctly. Inspecting the Rancher logs can help pinpoint the root cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) for more information.
|
||||
If you experience issues when you test the connection to the OpenLDAP server, ensure that you entered the credentials for the service account and configured the search base correctly. Inspecting the Rancher logs can help pinpoint the root cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) for more information.
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -64,3 +64,7 @@ Note that these URLs will not return valid data until the authentication configu
|
||||
- The group drop-down shows only the groups that you are a member of. You will not be able to add groups that you are not a member of.
|
||||
|
||||
:::
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -51,3 +51,7 @@ You can generate a certificate using an openssl command. For example:
|
||||
```
|
||||
openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
|
||||
```
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -77,6 +77,10 @@ If you configure Shibboleth without OpenLDAP, the following caveats apply due to
|
||||
|
||||
To enable searching for groups when assigning permissions in Rancher, you will need to configure a back end for the SAML provider that supports groups, such as OpenLDAP.
|
||||
|
||||
### Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
## Setting up OpenLDAP in Rancher
|
||||
|
||||
If you also configure OpenLDAP as the back end to Shibboleth, it will return a SAML assertion to Rancher with user attributes that include groups. Then authenticated users will be able to access resources in Rancher that their groups have permissions for.
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ PSS define security levels for workloads. PSAs describe requirements for pod sec
|
||||
|
||||
## Upgrade to Pod Security Standards (PSS)
|
||||
|
||||
Ensure that you migrate all PSPs to another workload security mechanism. This includes mapping your current PSPs to Pod Security Standards for enforcement with the [PSA controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/). If the PSA controller won't meet all of your organization's needs, we recommend that you use a policy engine, such as [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper), [Kubewarden](https://www.kubewarden.io/), [Kyverno](https://kyverno.io/), or [NeuVector](https://neuvector.com/). Refer to the documentation of your policy engine of choice for more information on how to migrate from PSPs.
|
||||
Ensure that you migrate all PSPs to another workload security mechanism. This includes mapping your current PSPs to Pod Security Standards for enforcement with the [PSA controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/). If the PSA controller won't meet all of your organization's needs, we recommend that you use a policy engine, such as [Kubewarden](https://www.kubewarden.io/), [Kyverno](https://kyverno.io/), or [NeuVector](https://neuvector.com/). Refer to the documentation of your policy engine of choice for more information on how to migrate from PSPs.
|
||||
|
||||
:::caution
|
||||
You must add your new policy enforcement mechanisms _before_ you remove the PodSecurityPolicy objects. If you don't, you may create an opportunity for privilege escalation attacks within the cluster.
|
||||
|
||||
+38
-3
@@ -53,8 +53,7 @@ To display prerelease versions:
|
||||
| rancher-alerting-drivers | 100.0.0 | 100.0.2 |
|
||||
| rancher-backup | 2.0.1 | 2.1.2 |
|
||||
| rancher-cis-benchmark | 2.0.1 | 2.0.4 |
|
||||
| rancher-gatekeeper | 100.0.0+up3.6.0 | 100.1.0+up3.7.1 |
|
||||
| rancher-istio | 100.0.0+up1.10.4 | 100.3.0+up1.13.3 |
|
||||
| rancher-istio | 105.0.0+up1.19.6 | 105.4.0+up1.23.2 |
|
||||
| rancher-logging | 100.0.0+up3.12.0 | 100.1.2+up3.17.4 |
|
||||
| rancher-longhorn | 100.0.0+up1.1.2 | 100.1.2+up1.2.4 |
|
||||
| rancher-monitoring | 100.0.0+up16.6.0 | 100.1.2+up19.0.3 |
|
||||
@@ -194,6 +193,42 @@ Non-Airgap Rancher installations upon refresh will reflect any chart repository
|
||||
|
||||
Airgap installations where Rancher is configured to use the packaged copy of Helm system charts ([`useBundledSystemChart=true`](../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md#helm-chart-options-for-air-gap-installations)) will only refer to the [system-chart](https://github.com/rancher/system-charts) repository that comes bundled and will not be able to be refreshed or synced.
|
||||
|
||||
#### Refresh Interval
|
||||
|
||||
Rancher v2.10.0 adds the `refreshInterval` field to the `ClusterRepo` CRD. The default value is 3600 seconds, meaning that Rancher syncs each Helm repository every 3600 seconds.
|
||||
|
||||
To modify the refresh interval of a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to modify, and click **⋮ > Edit YAML**.
|
||||
1. Set the **refreshInterval** field under **Spec** to the desired value in seconds.
|
||||
1. Click **Save**.
|
||||
|
||||
### Enable/Disable Helm Chart Repositories
|
||||
|
||||
Rancher v2.10.0 adds the ability to enable and disable Helm repositories. Helm repositories are enabled by default.
|
||||
|
||||
To disable a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to disable, and click **⋮ > Edit YAML**.
|
||||
1. Set the **Enabled** field under **Spec** to **false**.
|
||||
1. Click **Save**.
|
||||
1. When you disable a repository, updates are disabled and new changes to the clusterRepo are not applied.
|
||||
|
||||
To enable a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to disable, and click **⋮ > Edit YAML**.
|
||||
1. Set the **Enabled** field under **Spec** to **true**.
|
||||
1. Click **Save**.
|
||||
|
||||
## Deploy and Upgrade Charts
|
||||
|
||||
To install and deploy a chart:
|
||||
@@ -201,7 +236,7 @@ To install and deploy a chart:
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
|
||||
1. Select a chart, and click **Install**.
|
||||
1. Select a chart, and click **Install**.
|
||||
|
||||
Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files. However, all chart installations can modify the values.yaml and other basic settings. After you click **Install**, a Helm operation job is deployed, and the console for the job is displayed.
|
||||
|
||||
|
||||
-1
@@ -31,6 +31,5 @@ Rancher contains a variety of tools that aren't included in Kubernetes to assist
|
||||
- Logging
|
||||
- Monitoring
|
||||
- Istio Service Mesh
|
||||
- OPA Gatekeeper
|
||||
|
||||
Tools can be installed through **Apps.**
|
||||
|
||||
+4
@@ -10,6 +10,10 @@ title: AWS Marketplace Integration
|
||||
|
||||
Rancher offers an integration with the AWS Marketplace which allows users to purchase a support contract with SUSE. This integration allows you easily adjust your support needs as you start to support more clusters.
|
||||
|
||||
## Required Skills
|
||||
|
||||
At a minimum, users are expected to have a working knowledge of EKS and peripheral functions such as IAM Policies and Roles, Route 53 DNS, and the use of awscli and Helm commands.
|
||||
|
||||
## Limitations
|
||||
|
||||
- You must be running Rancher v2.6.7 or higher
|
||||
|
||||
+1
-3
@@ -19,9 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.9.2 | v104.0.0+up4.0.0 |
|
||||
| v2.9.1 | v104.0.0+up4.0.0 |
|
||||
| v2.9.0 | v104.0.0+up4.0.0 |
|
||||
| v2.10.0 | v105.0.0+up5.0.1 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
|
||||
@@ -1,117 +0,0 @@
|
||||
---
|
||||
title: OPA Gatekeeper
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/opa-gatekeeper"/>
|
||||
</head>
|
||||
|
||||
<DeprecationOPAGatekeeper link="kubewarden" />
|
||||
|
||||
To ensure consistency and compliance, every organization needs the ability to define and enforce policies in its environment in an automated way. [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) is a policy engine that facilitates policy-based control for cloud native environments. Rancher provides the ability to enable OPA Gatekeeper in Kubernetes clusters, and also installs a couple of built-in policy definitions, which are also called constraint templates.
|
||||
|
||||
OPA provides a high-level declarative language that lets you specify policy as code and ability to extend simple APIs to offload policy decision-making.
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is a project that provides integration between OPA and Kubernetes. OPA Gatekeeper provides:
|
||||
|
||||
- An extensible, parameterized policy library.
|
||||
- Native Kubernetes CRDs for instantiating the policy library, also called “constraints."
|
||||
- Native Kubernetes CRDs for extending the policy library, also called "constraint templates."
|
||||
- Audit functionality.
|
||||
|
||||
To read more about OPA, please refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/)
|
||||
|
||||
## How the OPA Gatekeeper Integration Works
|
||||
|
||||
Kubernetes provides the ability to extend API server functionality via admission controller webhooks, which are invoked whenever a resource is created, updated or deleted. Gatekeeper is installed as a validating webhook and enforces policies defined by Kubernetes custom resource definitions. In addition to the admission control usage, Gatekeeper provides the capability to audit existing resources in Kubernetes clusters and mark current violations of enabled policies.
|
||||
|
||||
OPA Gatekeeper is made available via Rancher's Helm system chart, and it is installed in a namespace named `gatekeeper-system.`
|
||||
|
||||
## Enabling OPA Gatekeeper in a Cluster
|
||||
|
||||
:::note
|
||||
|
||||
In Rancher v2.5, the OPA Gatekeeper application was improved. The Rancher v2.4 feature can't be upgraded to the new version in Rancher v2.5. If you installed OPA Gatekeeper in Rancher v2.4, you will need to uninstall OPA Gatekeeper and its CRDs from the old UI, then reinstall it in Rancher v2.5. To uninstall the CRDs run the following command in the kubectl console `kubectl delete crd configs.config.gatekeeper.sh constrainttemplates.templates.gatekeeper.sh`.
|
||||
|
||||
:::
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
Only administrators and cluster owners can enable OPA Gatekeeper.
|
||||
|
||||
:::
|
||||
|
||||
The OPA Gatekeeper Helm chart can be installed from **Apps**.
|
||||
|
||||
### Enabling OPA Gatekeeper
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. In the **Clusters** page, go to the cluster where you want to enable OPA Gatekeeper and click **Explore**.
|
||||
1. In the left navigation bar, click **Apps**.
|
||||
1. Click **Charts** and click **OPA Gatekeeper**.
|
||||
1. Click **Install**.
|
||||
|
||||
**Result:** OPA Gatekeeper is deployed in your Kubernetes cluster.
|
||||
|
||||
## Constraint Templates
|
||||
|
||||
[Constraint templates](https://github.com/open-policy-agent/gatekeeper#constraint-templates) are Kubernetes custom resources that define the schema and Rego logic of the OPA policy to be applied by Gatekeeper. For more information on the Rego policy language, refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/policy-language/)
|
||||
|
||||
When OPA Gatekeeper is enabled, Rancher installs some templates by default.
|
||||
|
||||
To list the constraint templates installed in the cluster, go to the left side menu under OPA Gatekeeper and click on **Templates**.
|
||||
|
||||
Rancher also provides the ability to create your own constraint templates by importing YAML definitions.
|
||||
|
||||
## Creating and Configuring Constraints
|
||||
|
||||
[Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
OPA Gatekeeper must be enabled in the cluster.
|
||||
|
||||
:::
|
||||
|
||||
To list the constraints installed, go to the left side menu under OPA Gatekeeper, and click on **Constraints**.
|
||||
|
||||
New constraints can be created from a constraint template.
|
||||
|
||||
Rancher provides the ability to create a constraint by using a convenient form that lets you input the various constraint fields.
|
||||
|
||||
The **Edit as yaml** option is also available to configure the the constraint's yaml definition.
|
||||
|
||||
### Exempting Rancher's System Namespaces from Constraints
|
||||
|
||||
When a constraint is created, ensure that it does not apply to any Rancher or Kubernetes system namespaces. If the system namespaces are not excluded, then it is possible to see many resources under them marked as violations of the constraint.
|
||||
|
||||
To limit the scope of the constraint only to user namespaces, always specify these namespaces under the **Match** field of the constraint.
|
||||
|
||||
Also, the constraint may interfere with other Rancher functionality and deny system workloads from being deployed. To avoid this, exclude all Rancher-specific namespaces from your constraints.
|
||||
|
||||
## Enforcing Constraints in your Cluster
|
||||
|
||||
When the **Enforcement Action** is **Deny,** the constraint is immediately enabled and will deny any requests that violate the policy defined. By default, the enforcement value is **Deny**.
|
||||
|
||||
When the **Enforcement Action** is **Dryrun,** then any resources that violate the policy are only recorded under the constraint's status field.
|
||||
|
||||
To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny**.
|
||||
|
||||
## Audit and Violations in your Cluster
|
||||
|
||||
OPA Gatekeeper runs a periodic audit to check if any existing resource violates any enforced constraint. The audit-interval (default 300s) can be configured while installing Gatekeeper.
|
||||
|
||||
On the Gatekeeper page, any violations of the defined constraints are listed.
|
||||
|
||||
Also under **Constraints,** the number of violations of the constraint can be found.
|
||||
|
||||
The detail view of each constraint lists information about the resource that violated the constraint.
|
||||
|
||||
## Disabling Gatekeeper
|
||||
|
||||
1. Navigate to the cluster's Dashboard view
|
||||
1. On the left side menu, expand the cluster menu and click on **OPA Gatekeeper**.
|
||||
1. Click the **⋮ > Disable**.
|
||||
|
||||
**Result:** Upon disabling OPA Gatekeeper, all constraint templates and constraints will also be deleted.
|
||||
|
||||
+19
-6
@@ -248,12 +248,28 @@ spec:
|
||||
|
||||
## Example EncryptionConfiguration
|
||||
|
||||
The snippet below demonstrates two different types of secrets and their relevance with respect to Backup and Restore of custom resources.
|
||||
The snippets below demonstrate two different types of secrets and their relevance with respect to Backup and Restore of custom resources. Creating the secret can be done with the following command:
|
||||
|
||||
The first example is that of a secret that is used to encrypt the backup files. The backup operator, in this case, will not be able to read the secrets encryption file. It only uses the contents of the secret.
|
||||
```plain
|
||||
kubectl create secret generic example-encryptionconfig \
|
||||
--from-file=./encryption-provider-config.yaml \
|
||||
-n cattle-resources-system
|
||||
```
|
||||
|
||||
The second example is that of a Kubernetes secrets encryption config file that is used to encrypt secrets when stored in etcd. **When backing up the etcd datastore, be sure to also back up the EncryptionConfiguration.** Failure to do so will result in an inability to use the restored data if secrets encryption was in use at the time the data was backed up.
|
||||
The first example is that of a secret used to encrypt the backup files. The backup operator will read the contents of the **encryption-provider-config.yaml** key, which contains the definition of an EncryptionConfiguration resource encoded as Base64.
|
||||
|
||||
The second example is that of the Kubernetes EncryptionConfiguration resource itself, being the plain-text form of the Base64-encoded content from the first example. This resource is also used to encrypt secrets when stored in etcd and general cases of Encryption at Rest in Kubernetes. More information on that can be found in the [upstream documentation](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). The keys defined in this resource are essential for accessing the contents of encrypted Backups, particularly during the Restore process. For that reason, these must be kept secure, confidential and easily retrievable.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
encryption-provider-config.yaml: YXBpVmVyc2lvbjogYXBpc2VydmVyLmNvbmZpZy5rOHMuaW8vdjEKa2luZDogRW5jcnlwdGlvbkNvbmZpZ3VyYXRpb24KcmVzb3VyY2VzOgogIC0gcmVzb3VyY2VzOgogICAgICAtIHNlY3JldHMKICAgIHByb3ZpZGVyczoKICAgICAgLSBhZXNnY206CiAgICAgICAgICBrZXlzOgogICAgICAgICAgICAtIG5hbWU6IGtleTEKICAgICAgICAgICAgICBzZWNyZXQ6IGMyVmpjbVYwSUdseklITmxZM1Z5WlE9PQogICAgICAgICAgICAtIG5hbWU6IGtleTIKICAgICAgICAgICAgICBzZWNyZXQ6IGRHaHBjeUJwY3lCd1lYTnpkMjl5WkE9PQogICAgICAtIGFlc2NiYzoKICAgICAgICAgIGtleXM6CiAgICAgICAgICAgIC0gbmFtZToga2V5MQogICAgICAgICAgICAgIHNlY3JldDogYzJWamNtVjBJR2x6SUhObFkzVnlaUT09CiAgICAgICAgICAgIC0gbmFtZToga2V5MgogICAgICAgICAgICAgIHNlY3JldDogZEdocGN5QnBjeUJ3WVhOemQyOXlaQT09CiAgICAgIC0gc2VjcmV0Ym94OgogICAgICAgICAga2V5czoKICAgICAgICAgICAgLSBuYW1lOiBrZXkxCiAgICAgICAgICAgICAgc2VjcmV0OiBZV0pqWkdWbVoyaHBhbXRzYlc1dmNIRnljM1IxZG5kNGVYb3hNak0wTlRZPQ==
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: example-encryptionconfig
|
||||
namespace: cattle-resources-system
|
||||
type: Opaque
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
@@ -279,6 +295,3 @@ resources:
|
||||
- name: key1
|
||||
secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Best Practices for Disconnected Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/disconnected-clusters"/>
|
||||
</head>
|
||||
|
||||
Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. At the moment there are no known issues with disconnected clusters in the latest released Rancher version.
|
||||
|
||||
While a managed cluster is disconnected from Rancher, management operations will be unavailable, and the Rancher UI will not allow navigation to the cluster. However, once the connection is reestablished, functionality is fully restored.
|
||||
|
||||
### Best Practices for Managing Disconnected Clusters
|
||||
|
||||
- **Cluster Availability During Rancher Upgrades**: It is recommended to have all, or at least most, managed clusters online during a Rancher upgrade. The reason is that upgrading Rancher automatically upgrades the Rancher agent software running on managed clusters. Keeping the agent and Rancher versions aligned ensures consistent functionality. Any clusters that are disconnected during the upgrade will have their agents updated as soon as they reconnect.
|
||||
|
||||
- **Cleaning Up Disconnected Clusters**: Regularly remove clusters that will no longer reconnect to Rancher (e.g., clusters that have been decommissioned or destroyed). Keeping such clusters in the Rancher management system consumes unnecessary resources, which could impact Rancher's performance over time.
|
||||
|
||||
- **Certificate Rotation Considerations**: When designing processes that involve regularly shutting down clusters, whether connected to Rancher or not, take into account certificate rotation policies. For example, RKE/RKE2/K3s clusters may rotate certificates on startup if they exceeded their lifetime.
|
||||
+4
@@ -14,6 +14,10 @@ Refer to [this guide](logging-best-practices.md) for our recommendations for clu
|
||||
|
||||
Configuring sensible monitoring and alerting rules is vital for running any production workloads securely and reliably. Refer to this [guide](monitoring-best-practices.md) for our recommendations.
|
||||
|
||||
### Disconnected clusters
|
||||
|
||||
Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. Refer to this [guide](disconnected-clusters.md) for our recommendations.
|
||||
|
||||
### Tips for Setting Up Containers
|
||||
|
||||
Running well-built containers can greatly impact the overall performance and security of your environment. Refer to this [guide](tips-to-set-up-containers.md) for tips.
|
||||
|
||||
@@ -42,12 +42,6 @@ Rancher's integration with Istio was improved in Rancher v2.5.
|
||||
|
||||
For more information, refer to the Istio documentation [here.](../integrations-in-rancher/istio/istio.md)
|
||||
|
||||
## OPA Gatekeeper
|
||||
|
||||
<DeprecationOPAGatekeeper link="../integrations-in-rancher/kubewarden" />
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is an open-source project that provides integration between OPA and Kubernetes to provide policy control via admission controller webhooks. For details on how to enable Gatekeeper in Rancher, refer to the [OPA Gatekeeper section.](../integrations-in-rancher/opa-gatekeeper.md)
|
||||
|
||||
## CIS Scans
|
||||
|
||||
Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark.
|
||||
|
||||
@@ -20,9 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.9.2 | v0.5.2 | ✓ | ✓ |
|
||||
| v2.9.1 | v0.5.1 | ✓ | ✓ |
|
||||
| v2.9.0 | v0.5.0 | ✗ | ✓ |
|
||||
| v2.10.0 | v0.6.1 | ✗ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
|
||||
+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>
|
||||
|
||||
> **Important:**
|
||||
>
|
||||
> 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.
|
||||
|
||||
+1
-1
@@ -128,7 +128,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
>**Having network issues following upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
> See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
## Known Upgrade Issues
|
||||
|
||||
|
||||
+2
-2
@@ -83,7 +83,7 @@ helm rollback rancher 3 -n cattle-system
|
||||
|
||||
## Rolling Back to Rancher v2.2-v2.4+
|
||||
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
|
||||
For information on how to roll back Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)
|
||||
|
||||
@@ -91,4 +91,4 @@ For information on how to roll back Rancher installed with Docker, refer to [thi
|
||||
|
||||
## Rolling Back to Rancher v2.0-v2.1
|
||||
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
|
||||
+2
-2
@@ -34,7 +34,7 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..
|
||||
|
||||
The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
### For air gap installs: Populate private registry
|
||||
|
||||
@@ -185,7 +185,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
>**Having network issues following upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
> See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
## Known Upgrade Issues
|
||||
|
||||
|
||||
+1
-1
@@ -360,7 +360,7 @@ Log into Rancher. Confirm that the upgrade succeeded by checking the version dis
|
||||
|
||||
>**Having network issues in your user clusters following upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
> See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
|
||||
## 6. Clean up Your Old Rancher Server Container
|
||||
|
||||
+1
-1
@@ -199,7 +199,7 @@ _Mutable: yes_
|
||||
|
||||
The node operating system image. For more information for the node image options that GKE offers for each OS, refer to [this page.](https://cloud.google.com/kubernetes-engine/docs/concepts/node-images#available_node_images)
|
||||
|
||||
> Note: the default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [logging feature as of v2.5](../../../../explanations/integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
|
||||
> Note: the default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [logging feature as of v2.5](../../../../explanations/integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
|
||||
|
||||
> Note: if selecting "Windows Long Term Service Channel" or "Windows Semi-Annual Channel" for the node pool image type, you must also add at least one Container-Optimized OS or Ubuntu node pool.
|
||||
|
||||
|
||||
+1
-1
@@ -92,7 +92,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+2
-2
@@ -93,7 +93,7 @@ helm rollback rancher 3 -n cattle-system
|
||||
|
||||
## Rolling Back to Rancher v2.2-v2.4+
|
||||
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
|
||||
For information on how to roll back Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)
|
||||
|
||||
@@ -105,4 +105,4 @@ Managed clusters are authoritative for their state. This means restoring the Ran
|
||||
|
||||
## Rolling Back to Rancher v2.0-v2.1
|
||||
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
|
||||
+2
-2
@@ -31,7 +31,7 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..
|
||||
|
||||
The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
### For air-gapped installs: Populate private registry
|
||||
|
||||
@@ -188,7 +188,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -380,7 +380,7 @@ Log into Rancher. Confirm that the upgrade succeeded by checking the version dis
|
||||
|
||||
:::note Having network issues in your user clusters following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ title: Helm Version Requirements
|
||||
|
||||
This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.
|
||||
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
- Helm v3.2.x or higher is required to install or upgrade Rancher v2.5.
|
||||
- Helm v2.16.0 or higher is required for Kubernetes v1.16. For the default Kubernetes version, refer to the [release notes](https://github.com/rancher/rke/releases) for the version of RKE that you are using.
|
||||
|
||||
+1
-1
@@ -14,7 +14,7 @@ Rancher uses a catalog-like system to import bundles of charts from repositories
|
||||
|
||||
### Catalogs, Apps, and the Rancher UI
|
||||
|
||||
[Rancher v2.4 and earlier](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI.
|
||||
[Rancher v2.4 and earlier](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI.
|
||||
|
||||
Helm chart repositories are now managed using **Apps & Marketplace** (before Rancher v2.6.5) or **Apps** (Rancher v2.6.5 and later).
|
||||
|
||||
|
||||
+1
-1
@@ -204,7 +204,7 @@ The node operating system image. For more information for the node image options
|
||||
|
||||
:::note
|
||||
|
||||
The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
|
||||
The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@@ -291,7 +291,7 @@ You can enable notifications to any notifiers based on the build status of a pip
|
||||
|
||||
1. Select the conditions for the notification. You can select to get a notification for the following statuses: `Failed`, `Success`, `Changed`. For example, if you want to receive notifications when an execution fails, select **Failed**.
|
||||
|
||||
1. If you don't have any existing notifiers, Rancher will provide a warning that no notifiers are set up and provide a link to be able to go to the notifiers page. Follow the [instructions](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) to add a notifier. If you already have notifiers, you can add them to the notification by clicking the **Add Recipient** button.
|
||||
1. If you don't have any existing notifiers, Rancher will provide a warning that no notifiers are set up and provide a link to be able to go to the notifiers page. Follow the [instructions](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) to add a notifier. If you already have notifiers, you can add them to the notification by clicking the **Add Recipient** button.
|
||||
|
||||
:::note
|
||||
|
||||
|
||||
@@ -16,7 +16,9 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | Oct 24, 2024 |
|
||||
| [2.7.18](https://github.com/rancher/rancher/releases/tag/v2.7.18) | Nov 14, 2024 |
|
||||
| [2.7.17](https://github.com/rancher/rancher/releases/tag/v2.7.17) | Nov 5, 2024 |
|
||||
| [2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) | Oct 24, 2024 |
|
||||
| [2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) | July 31, 2024 |
|
||||
| [2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) | June 17, 2024 |
|
||||
| [2.7.13](https://github.com/rancher/rancher/releases/tag/v2.7.13) | May 16, 2024 |
|
||||
|
||||
+1
-1
@@ -92,7 +92,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+2
-2
@@ -142,7 +142,7 @@ helm rollback rancher 3 -n cattle-system
|
||||
|
||||
## Rolling Back to Rancher v2.2-v2.4+
|
||||
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
|
||||
For information on how to roll back Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)
|
||||
|
||||
@@ -154,4 +154,4 @@ Managed clusters are authoritative for their state. This means restoring the Ran
|
||||
|
||||
## Rolling Back to Rancher v2.0-v2.1
|
||||
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
|
||||
+2
-2
@@ -34,7 +34,7 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..
|
||||
|
||||
The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
### For air-gapped installs: Populate private registry
|
||||
|
||||
@@ -198,7 +198,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -380,7 +380,7 @@ Log into Rancher. Confirm that the upgrade succeeded by checking the version dis
|
||||
|
||||
:::note Having network issues in your user clusters following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ title: Helm Version Requirements
|
||||
|
||||
This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.
|
||||
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
|
||||
+2
@@ -9,3 +9,5 @@ title: Rancher Prime
|
||||
SUSE Rancher introduces Rancher Prime – an evolution of Rancher – from version v2.7. Rancher Prime is the new commercially available enterprise offering of Rancher, built on the same open source code. The Rancher project will continue to be 100% open source. Prime introduces additional value with greater security assurances, extended lifecycles, access to focused architectures and Kubernetes advisories. Rancher Prime will also offer options to get production support for innovative Rancher projects. With Rancher Prime, installation assets are hosted on a trusted registry owned and managed by Rancher.
|
||||
|
||||
To get started with Rancher Prime, [go to this page](https://www.rancher.com/quick-start) and fill out the form.
|
||||
|
||||
At a minimum, users are expected to have a working knowledge of Kubernetes and peripheral functions such as Permissions, Roles and RBAC.
|
||||
|
||||
+1
-1
@@ -90,4 +90,4 @@ The following features are available under **Global Configuration**:
|
||||
- **Global DNS Entries**
|
||||
- **Global DNS Providers**
|
||||
|
||||
As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](https://github.com/rancher/rancher-docs/tree/main/archived_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](https://github.com/rancher/rancher-docs/tree/main/archived_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.
|
||||
As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/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.
|
||||
+1
-1
@@ -16,7 +16,7 @@ Rancher uses a catalog-like system to import bundles of charts from repositories
|
||||
|
||||
### Catalogs, Apps, and the Rancher UI
|
||||
|
||||
[Rancher v2.4 and earlier](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI.
|
||||
[Rancher v2.4 and earlier](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI.
|
||||
|
||||
Rancher v2.5 replaced the former catalog system with a new **Apps & Marketplace** feature.
|
||||
|
||||
|
||||
+4
@@ -10,6 +10,10 @@ title: AWS Marketplace Integration
|
||||
|
||||
Rancher offers an integration with the AWS Marketplace which allows users to purchase a support contract with SUSE. This integration allows you easily adjust your support needs as you start to support more clusters.
|
||||
|
||||
## Required Skills
|
||||
|
||||
At a minimum, users are expected to have a working knowledge of EKS and peripheral functions such as IAM Policies and Roles, Route 53 DNS, and the use of awscli and Helm commands.
|
||||
|
||||
## Limitations
|
||||
|
||||
- You must be running Rancher v2.6.7 or higher
|
||||
|
||||
+2
@@ -19,6 +19,8 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|:---------------:|
|
||||
| v2.7.18 | v2.0.4 |
|
||||
| v2.7.17 | v2.0.4 |
|
||||
| v2.7.16 | v2.0.4 |
|
||||
| v2.7.15 | v2.0.4 |
|
||||
| v2.7.14 | v2.0.4 |
|
||||
|
||||
+1
-1
@@ -118,4 +118,4 @@ For more information on configuring PrometheusRules in Rancher, see [this page.]
|
||||
|
||||
## 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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md).
|
||||
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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md).
|
||||
+1
-1
@@ -11,7 +11,7 @@ The `rancher-monitoring` application can quickly deploy leading open-source moni
|
||||
|
||||
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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md), [alerting](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md), [notifiers](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md).
|
||||
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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md), [alerting](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md), [notifiers](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md).
|
||||
|
||||
Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster.
|
||||
|
||||
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Best Practices for Disconnected Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/disconnected-clusters"/>
|
||||
</head>
|
||||
|
||||
Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. At the moment there are no known issues with disconnected clusters in the latest released Rancher version.
|
||||
|
||||
While a managed cluster is disconnected from Rancher, management operations will be unavailable, and the Rancher UI will not allow navigation to the cluster. However, once the connection is reestablished, functionality is fully restored.
|
||||
|
||||
### Best Practices for Managing Disconnected Clusters
|
||||
|
||||
- **Cluster Availability During Rancher Upgrades**: It is recommended to have all, or at least most, managed clusters online during a Rancher upgrade. The reason is that upgrading Rancher automatically upgrades the Rancher agent software running on managed clusters. Keeping the agent and Rancher versions aligned ensures consistent functionality. Any clusters that are disconnected during the upgrade will have their agents updated as soon as they reconnect.
|
||||
|
||||
- **Cleaning Up Disconnected Clusters**: Regularly remove clusters that will no longer reconnect to Rancher (e.g., clusters that have been decommissioned or destroyed). Keeping such clusters in the Rancher management system consumes unnecessary resources, which could impact Rancher's performance over time.
|
||||
|
||||
- **Certificate Rotation Considerations**: When designing processes that involve regularly shutting down clusters, whether connected to Rancher or not, take into account certificate rotation policies. For example, RKE/RKE2/K3s clusters may rotate certificates on startup if they exceeded their lifetime.
|
||||
+4
@@ -14,6 +14,10 @@ Refer to [this guide](logging-best-practices.md) for our recommendations for clu
|
||||
|
||||
Configuring sensible monitoring and alerting rules is vital for running any production workloads securely and reliably. Refer to this [guide](monitoring-best-practices.md) for our recommendations.
|
||||
|
||||
### Disconnected clusters
|
||||
|
||||
Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. Refer to this [guide](disconnected-clusters.md) for our recommendations.
|
||||
|
||||
### Tips for Setting Up Containers
|
||||
|
||||
Running well-built containers can greatly impact the overall performance and security of your environment. Refer to this [guide](tips-to-set-up-containers.md) for tips.
|
||||
|
||||
+1
-1
@@ -198,7 +198,7 @@ The node operating system image. For more information for the node image options
|
||||
|
||||
:::note
|
||||
|
||||
The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
|
||||
The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@@ -20,6 +20,8 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.7.18 | v0.3.13 | ✓ | N/A |
|
||||
| v2.7.17 | v0.3.13 | ✓ | N/A |
|
||||
| v2.7.16 | v0.3.12 | ✓ | N/A |
|
||||
| v2.7.15 | v0.3.11 | ✓ | N/A |
|
||||
| v2.7.14 | v0.3.11 | ✓ | N/A |
|
||||
|
||||
@@ -91,6 +91,77 @@ spec:
|
||||
limitsMemory: 100Mi
|
||||
requestsCpu: 50m
|
||||
requestsMemory: 50Mi
|
||||
EOF
|
||||
```
|
||||
|
||||
## Adding a Member to a Project
|
||||
|
||||
Look up the project ID to specify the `metadata.namespace` field and `projectName` field values.
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
Look up the role template ID to specify the `roleTemplateName` field value (e.g. `project-member` or `project-owner`).
|
||||
|
||||
```bash
|
||||
kubectl get roletemplates
|
||||
```
|
||||
|
||||
When adding a user member specify the `userPrincipalName` field:
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: ProjectRoleTemplateBinding
|
||||
metadata:
|
||||
generateName: prtb-
|
||||
namespace: p-vwxyz
|
||||
projectName: c-m-abcde:p-vwxyz
|
||||
roleTemplateName: project-member
|
||||
userPrincipalName: keycloak_user://user
|
||||
EOF
|
||||
```
|
||||
|
||||
When adding a group member specify the `groupPrincipalName` field instead:
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: ProjectRoleTemplateBinding
|
||||
metadata:
|
||||
generateName: prtb-
|
||||
namespace: p-vwxyz
|
||||
projectName: c-m-abcde:p-vwxyz
|
||||
roleTemplateName: project-member
|
||||
groupPrincipalName: keycloak_group://group
|
||||
EOF
|
||||
```
|
||||
|
||||
Create a projectroletemplatebinding for each role you want to assign to the project member.
|
||||
|
||||
## Listing Project Members
|
||||
|
||||
Look up the project ID:
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
to list projectroletemplatebindings in the project's namespace:
|
||||
|
||||
```bash
|
||||
kubectl --namespace p-vwxyz get projectroletemplatebindings
|
||||
```
|
||||
|
||||
## Deleting a Member From a Project
|
||||
|
||||
Lookup the projectroletemplatebinding IDs containing the member in the project's namespace as decribed in the [Listing Project Members](#listing-project-members) section.
|
||||
|
||||
Delete the projectroletemplatebinding from the project's namespace:
|
||||
|
||||
```bash
|
||||
kubectl --namespace p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
|
||||
```
|
||||
|
||||
## Creating a Namespace in a Project
|
||||
|
||||
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10) | Nov 18, 2024 |
|
||||
| [2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) | Oct 24, 2024 |
|
||||
| [2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) | Sep 19, 2024 |
|
||||
| [2.8.7](https://github.com/rancher/rancher/releases/tag/v2.8.7) | Aug 26, 2024 |
|
||||
|
||||
+1
-1
@@ -92,7 +92,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+2
-2
@@ -117,7 +117,7 @@ helm rollback rancher 3 -n cattle-system
|
||||
|
||||
## Rolling Back to Rancher v2.2-v2.4+
|
||||
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
|
||||
For information on how to roll back Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)
|
||||
|
||||
@@ -129,4 +129,4 @@ Managed clusters are authoritative for their state. This means restoring the Ran
|
||||
|
||||
## Rolling Back to Rancher v2.0-v2.1
|
||||
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
|
||||
+2
-2
@@ -34,7 +34,7 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..
|
||||
|
||||
The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
### For air-gapped installs: Populate private registry
|
||||
|
||||
@@ -203,7 +203,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -380,7 +380,7 @@ Log into Rancher. Confirm that the upgrade succeeded by checking the version dis
|
||||
|
||||
:::note Having network issues in your user clusters following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ title: Helm Version Requirements
|
||||
|
||||
This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.
|
||||
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
|
||||
+2
@@ -11,3 +11,5 @@ SUSE Rancher introduces Rancher Prime – an evolution of Rancher – from versi
|
||||
Prime also offers options for production support, as well as add-ons to your subscription that tailor to your commercial needs.
|
||||
|
||||
To learn more and get started with Rancher Prime, please visit [this page](https://www.rancher.com/quick-start).
|
||||
|
||||
At a minimum, users are expected to have a working knowledge of Kubernetes and peripheral functions such as Permissions, Roles and RBAC.
|
||||
|
||||
+1
-1
@@ -90,4 +90,4 @@ The following features are available under **Global Configuration**:
|
||||
- **Global DNS Entries**
|
||||
- **Global DNS Providers**
|
||||
|
||||
As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](https://github.com/rancher/rancher-docs/tree/main/archived_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](https://github.com/rancher/rancher-docs/tree/main/archived_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.
|
||||
As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/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.
|
||||
+1
-1
@@ -16,7 +16,7 @@ Rancher uses a catalog-like system to import bundles of charts from repositories
|
||||
|
||||
### Catalogs, Apps, and the Rancher UI
|
||||
|
||||
[Rancher v2.4 and earlier](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI.
|
||||
[Rancher v2.4 and earlier](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI.
|
||||
|
||||
Rancher v2.5 replaced the former catalog system with a new **Apps & Marketplace** feature.
|
||||
|
||||
|
||||
+4
@@ -10,6 +10,10 @@ title: AWS Marketplace Integration
|
||||
|
||||
Rancher offers an integration with the AWS Marketplace which allows users to purchase a support contract with SUSE. This integration allows you easily adjust your support needs as you start to support more clusters.
|
||||
|
||||
## Required Skills
|
||||
|
||||
At a minimum, users are expected to have a working knowledge of EKS and peripheral functions such as IAM Policies and Roles, Route 53 DNS, and the use of awscli and Helm commands.
|
||||
|
||||
## Limitations
|
||||
|
||||
- You must be running Rancher v2.6.7 or higher
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.8.10 | v103.0.1+up3.0.1 |
|
||||
| v2.8.9 | v103.0.1+up3.0.1 |
|
||||
| v2.8.8 | v103.0.1+up3.0.1 |
|
||||
| v2.8.7 | v103.0.1+up3.0.1 |
|
||||
|
||||
+1
-1
@@ -118,4 +118,4 @@ For more information on configuring PrometheusRules in Rancher, see [this page.]
|
||||
|
||||
## 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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md).
|
||||
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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md).
|
||||
|
||||
+1
-1
@@ -11,7 +11,7 @@ The `rancher-monitoring` application can quickly deploy leading open-source moni
|
||||
|
||||
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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md), [alerting](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md), [notifiers](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md).
|
||||
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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md), [alerting](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md), [notifiers](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md).
|
||||
|
||||
Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster.
|
||||
|
||||
|
||||
+19
-6
@@ -248,12 +248,28 @@ spec:
|
||||
|
||||
## Example EncryptionConfiguration
|
||||
|
||||
The snippet below demonstrates two different types of secrets and their relevance with respect to Backup and Restore of custom resources.
|
||||
The snippets below demonstrate two different types of secrets and their relevance with respect to Backup and Restore of custom resources. Creating the secret can be done with the following command:
|
||||
|
||||
The first example is that of a secret that is used to encrypt the backup files. The backup operator, in this case, will not be able to read the secrets encryption file. It only uses the contents of the secret.
|
||||
```plain
|
||||
kubectl create secret generic example-encryptionconfig \
|
||||
--from-file=./encryption-provider-config.yaml \
|
||||
-n cattle-resources-system
|
||||
```
|
||||
|
||||
The second example is that of a Kubernetes secrets encryption config file that is used to encrypt secrets when stored in etcd. **When backing up the etcd datastore, be sure to also back up the EncryptionConfiguration.** Failure to do so will result in an inability to use the restored data if secrets encryption was in use at the time the data was backed up.
|
||||
The first example is that of a secret used to encrypt the backup files. The backup operator will read the contents of the **encryption-provider-config.yaml** key, which contains the definition of an EncryptionConfiguration resource encoded as Base64.
|
||||
|
||||
The second example is that of the Kubernetes EncryptionConfiguration resource itself, being the plain-text form of the Base64-encoded content from the first example. This resource is also used to encrypt secrets when stored in etcd and general cases of Encryption at Rest in Kubernetes. More information on that can be found in the [upstream documentation](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). The keys defined in this resource are essential for accessing the contents of encrypted Backups, particularly during the Restore process. For that reason, these must be kept secure, confidential and easily retrievable.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
encryption-provider-config.yaml: YXBpVmVyc2lvbjogYXBpc2VydmVyLmNvbmZpZy5rOHMuaW8vdjEKa2luZDogRW5jcnlwdGlvbkNvbmZpZ3VyYXRpb24KcmVzb3VyY2VzOgogIC0gcmVzb3VyY2VzOgogICAgICAtIHNlY3JldHMKICAgIHByb3ZpZGVyczoKICAgICAgLSBhZXNnY206CiAgICAgICAgICBrZXlzOgogICAgICAgICAgICAtIG5hbWU6IGtleTEKICAgICAgICAgICAgICBzZWNyZXQ6IGMyVmpjbVYwSUdseklITmxZM1Z5WlE9PQogICAgICAgICAgICAtIG5hbWU6IGtleTIKICAgICAgICAgICAgICBzZWNyZXQ6IGRHaHBjeUJwY3lCd1lYTnpkMjl5WkE9PQogICAgICAtIGFlc2NiYzoKICAgICAgICAgIGtleXM6CiAgICAgICAgICAgIC0gbmFtZToga2V5MQogICAgICAgICAgICAgIHNlY3JldDogYzJWamNtVjBJR2x6SUhObFkzVnlaUT09CiAgICAgICAgICAgIC0gbmFtZToga2V5MgogICAgICAgICAgICAgIHNlY3JldDogZEdocGN5QnBjeUJ3WVhOemQyOXlaQT09CiAgICAgIC0gc2VjcmV0Ym94OgogICAgICAgICAga2V5czoKICAgICAgICAgICAgLSBuYW1lOiBrZXkxCiAgICAgICAgICAgICAgc2VjcmV0OiBZV0pqWkdWbVoyaHBhbXRzYlc1dmNIRnljM1IxZG5kNGVYb3hNak0wTlRZPQ==
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: example-encryptionconfig
|
||||
namespace: cattle-resources-system
|
||||
type: Opaque
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
@@ -279,6 +295,3 @@ resources:
|
||||
- name: key1
|
||||
secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Best Practices for Disconnected Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/disconnected-clusters"/>
|
||||
</head>
|
||||
|
||||
Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. At the moment there are no known issues with disconnected clusters in the latest released Rancher version.
|
||||
|
||||
While a managed cluster is disconnected from Rancher, management operations will be unavailable, and the Rancher UI will not allow navigation to the cluster. However, once the connection is reestablished, functionality is fully restored.
|
||||
|
||||
### Best Practices for Managing Disconnected Clusters
|
||||
|
||||
- **Cluster Availability During Rancher Upgrades**: It is recommended to have all, or at least most, managed clusters online during a Rancher upgrade. The reason is that upgrading Rancher automatically upgrades the Rancher agent software running on managed clusters. Keeping the agent and Rancher versions aligned ensures consistent functionality. Any clusters that are disconnected during the upgrade will have their agents updated as soon as they reconnect.
|
||||
|
||||
- **Cleaning Up Disconnected Clusters**: Regularly remove clusters that will no longer reconnect to Rancher (e.g., clusters that have been decommissioned or destroyed). Keeping such clusters in the Rancher management system consumes unnecessary resources, which could impact Rancher's performance over time.
|
||||
|
||||
- **Certificate Rotation Considerations**: When designing processes that involve regularly shutting down clusters, whether connected to Rancher or not, take into account certificate rotation policies. For example, RKE/RKE2/K3s clusters may rotate certificates on startup if they exceeded their lifetime.
|
||||
+4
@@ -14,6 +14,10 @@ Refer to [this guide](logging-best-practices.md) for our recommendations for clu
|
||||
|
||||
Configuring sensible monitoring and alerting rules is vital for running any production workloads securely and reliably. Refer to this [guide](monitoring-best-practices.md) for our recommendations.
|
||||
|
||||
### Disconnected clusters
|
||||
|
||||
Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. Refer to this [guide](disconnected-clusters.md) for our recommendations.
|
||||
|
||||
### Tips for Setting Up Containers
|
||||
|
||||
Running well-built containers can greatly impact the overall performance and security of your environment. Refer to this [guide](tips-to-set-up-containers.md) for tips.
|
||||
|
||||
+1
-1
@@ -198,7 +198,7 @@ The node operating system image. For more information for the node image options
|
||||
|
||||
:::note
|
||||
|
||||
The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
|
||||
The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.8.10 | v0.4.13 | ✓ | ✗ |
|
||||
| v2.8.9 | v0.4.12 | ✓ | ✗ |
|
||||
| v2.8.8 | v0.4.11 | ✓ | ✗ |
|
||||
| v2.8.7 | v0.4.10 | ✓ | ✗ |
|
||||
|
||||
@@ -91,6 +91,77 @@ spec:
|
||||
limitsMemory: 100Mi
|
||||
requestsCpu: 50m
|
||||
requestsMemory: 50Mi
|
||||
EOF
|
||||
```
|
||||
|
||||
## Adding a Member to a Project
|
||||
|
||||
Look up the project ID to specify the `metadata.namespace` field and `projectName` field values.
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
Look up the role template ID to specify the `roleTemplateName` field value (e.g. `project-member` or `project-owner`).
|
||||
|
||||
```bash
|
||||
kubectl get roletemplates
|
||||
```
|
||||
|
||||
When adding a user member specify the `userPrincipalName` field:
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: ProjectRoleTemplateBinding
|
||||
metadata:
|
||||
generateName: prtb-
|
||||
namespace: p-vwxyz
|
||||
projectName: c-m-abcde:p-vwxyz
|
||||
roleTemplateName: project-member
|
||||
userPrincipalName: keycloak_user://user
|
||||
EOF
|
||||
```
|
||||
|
||||
When adding a group member specify the `groupPrincipalName` field instead:
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: ProjectRoleTemplateBinding
|
||||
metadata:
|
||||
generateName: prtb-
|
||||
namespace: p-vwxyz
|
||||
projectName: c-m-abcde:p-vwxyz
|
||||
roleTemplateName: project-member
|
||||
groupPrincipalName: keycloak_group://group
|
||||
EOF
|
||||
```
|
||||
|
||||
Create a projectroletemplatebinding for each role you want to assign to the project member.
|
||||
|
||||
## Listing Project Members
|
||||
|
||||
Look up the project ID:
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
to list projectroletemplatebindings in the project's namespace:
|
||||
|
||||
```bash
|
||||
kubectl --namespace p-vwxyz get projectroletemplatebindings
|
||||
```
|
||||
|
||||
## Deleting a Member From a Project
|
||||
|
||||
Lookup the projectroletemplatebinding IDs containing the member in the project's namespace as decribed in the [Listing Project Members](#listing-project-members) section.
|
||||
|
||||
Delete the projectroletemplatebinding from the project's namespace:
|
||||
|
||||
```bash
|
||||
kubectl --namespace p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
|
||||
```
|
||||
|
||||
## Creating a Namespace in a Project
|
||||
@@ -132,4 +203,4 @@ Delete the project under the cluster namespace:
|
||||
kubectl --namespace c-m-abcde delete project p-vwxyz
|
||||
```
|
||||
|
||||
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
|
||||
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
|
||||
|
||||
@@ -24,7 +24,7 @@ Yes. Rancher supports [Istio](../integrations-in-rancher/istio/istio.md).
|
||||
|
||||
## Will Rancher v2.x support Hashicorp's Vault for storing secrets?
|
||||
|
||||
Secrets management is on our roadmap but we haven't assigned it to a specific release yet.
|
||||
As of Rancher v2.9, Rancher [supports authentication with service account tokens](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/jwt-authentication.md), which is used by Vault and other integrations.
|
||||
|
||||
## Does Rancher v2.x support RKT containers as well?
|
||||
|
||||
|
||||
+1
-1
@@ -92,7 +92,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+2
-2
@@ -142,7 +142,7 @@ helm rollback rancher 3 -n cattle-system
|
||||
|
||||
## Rolling Back to Rancher v2.2-v2.4+
|
||||
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
|
||||
For information on how to roll back Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)
|
||||
|
||||
@@ -154,4 +154,4 @@ Managed clusters are authoritative for their state. This means restoring the Ran
|
||||
|
||||
## Rolling Back to Rancher v2.0-v2.1
|
||||
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
|
||||
+2
-2
@@ -34,7 +34,7 @@ The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
### For air-gapped installs: Populate private registry
|
||||
|
||||
@@ -202,7 +202,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -380,7 +380,7 @@ Log into Rancher. Confirm that the upgrade succeeded by checking the version dis
|
||||
|
||||
:::note Having network issues in your user clusters following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ title: Helm Version Requirements
|
||||
|
||||
This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.
|
||||
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
|
||||
+2
@@ -9,3 +9,5 @@ title: Rancher Prime
|
||||
SUSE Rancher introduces Rancher Prime – an evolution of Rancher – from version v2.7. Rancher Prime is the new commercially available enterprise offering of Rancher, built on the same open source code. The Rancher project will continue to be 100% open source. Prime introduces additional value with greater security assurances, extended lifecycles, access to focused architectures and Kubernetes advisories. Rancher Prime will also offer options to get production support for innovative Rancher projects. With Rancher Prime, installation assets are hosted on a trusted registry owned and managed by Rancher.
|
||||
|
||||
To get started with Rancher Prime, [go to this page](https://www.rancher.com/quick-start) and fill out the form.
|
||||
|
||||
At a minimum, users are expected to have a working knowledge of Kubernetes and peripheral functions such as Permissions, Roles and RBAC.
|
||||
|
||||
+1
-1
@@ -90,4 +90,4 @@ The following features are available under **Global Configuration**:
|
||||
- **Global DNS Entries**
|
||||
- **Global DNS Providers**
|
||||
|
||||
As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](https://github.com/rancher/rancher-docs/tree/main/archived_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](https://github.com/rancher/rancher-docs/tree/main/archived_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.
|
||||
As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/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.
|
||||
+1
-1
@@ -16,7 +16,7 @@ Rancher uses a catalog-like system to import bundles of charts from repositories
|
||||
|
||||
### Catalogs, Apps, and the Rancher UI
|
||||
|
||||
[Rancher v2.4 and earlier](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI.
|
||||
[Rancher v2.4 and earlier](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI.
|
||||
|
||||
Rancher v2.5 replaced the former catalog system with a new **Apps & Marketplace** feature.
|
||||
|
||||
|
||||
+4
@@ -10,6 +10,10 @@ title: AWS Marketplace Integration
|
||||
|
||||
Rancher offers an integration with the AWS Marketplace which allows users to purchase a support contract with SUSE. This integration allows you easily adjust your support needs as you start to support more clusters.
|
||||
|
||||
## Required Skills
|
||||
|
||||
At a minimum, users are expected to have a working knowledge of EKS and peripheral functions such as IAM Policies and Roles, Route 53 DNS, and the use of awscli and Helm commands.
|
||||
|
||||
## Limitations
|
||||
|
||||
- You must be running Rancher v2.6.7 or higher
|
||||
|
||||
+1
-1
@@ -118,4 +118,4 @@ For more information on configuring PrometheusRules in Rancher, see [this page.]
|
||||
|
||||
## 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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md).
|
||||
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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md).
|
||||
|
||||
+1
-1
@@ -11,7 +11,7 @@ The `rancher-monitoring` application can quickly deploy leading open-source moni
|
||||
|
||||
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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md), [alerting](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md), [notifiers](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md).
|
||||
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](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md), [alerting](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md), [notifiers](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md) and other [tools](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md).
|
||||
|
||||
Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster.
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ When you enable extension support for the first time, it creates resources, such
|
||||
|
||||
By default, Rancher caches every extension file in the file system. You can change that behavior by setting `plugin.noCache` to `true`.
|
||||
|
||||
Rancher does have a cached file size limit of 20MB. If an extension has a file bigger than that, the cache is disabled and `plugin.noCache` is set to `true`, regardless of user input.
|
||||
Rancher does have a cached file size limit of 30MB. If an extension has a file bigger than that, the cache is disabled and `plugin.noCache` is set to `true`, regardless of user input.
|
||||
|
||||
|
||||
## Installing Extensions
|
||||
|
||||
+19
-6
@@ -248,12 +248,28 @@ spec:
|
||||
|
||||
## Example EncryptionConfiguration
|
||||
|
||||
The snippet below demonstrates two different types of secrets and their relevance with respect to Backup and Restore of custom resources.
|
||||
The snippets below demonstrate two different types of secrets and their relevance with respect to Backup and Restore of custom resources. Creating the secret can be done with the following command:
|
||||
|
||||
The first example is that of a secret that is used to encrypt the backup files. The backup operator, in this case, will not be able to read the secrets encryption file. It only uses the contents of the secret.
|
||||
```plain
|
||||
kubectl create secret generic example-encryptionconfig \
|
||||
--from-file=./encryption-provider-config.yaml \
|
||||
-n cattle-resources-system
|
||||
```
|
||||
|
||||
The second example is that of a Kubernetes secrets encryption config file that is used to encrypt secrets when stored in etcd. **When backing up the etcd datastore, be sure to also back up the EncryptionConfiguration.** Failure to do so will result in an inability to use the restored data if secrets encryption was in use at the time the data was backed up.
|
||||
The first example is that of a secret used to encrypt the backup files. The backup operator will read the contents of the **encryption-provider-config.yaml** key, which contains the definition of an EncryptionConfiguration resource encoded as Base64.
|
||||
|
||||
The second example is that of the Kubernetes EncryptionConfiguration resource itself, being the plain-text form of the Base64-encoded content from the first example. This resource is also used to encrypt secrets when stored in etcd and general cases of Encryption at Rest in Kubernetes. More information on that can be found in the [upstream documentation](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). The keys defined in this resource are essential for accessing the contents of encrypted Backups, particularly during the Restore process. For that reason, these must be kept secure, confidential and easily retrievable.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
encryption-provider-config.yaml: YXBpVmVyc2lvbjogYXBpc2VydmVyLmNvbmZpZy5rOHMuaW8vdjEKa2luZDogRW5jcnlwdGlvbkNvbmZpZ3VyYXRpb24KcmVzb3VyY2VzOgogIC0gcmVzb3VyY2VzOgogICAgICAtIHNlY3JldHMKICAgIHByb3ZpZGVyczoKICAgICAgLSBhZXNnY206CiAgICAgICAgICBrZXlzOgogICAgICAgICAgICAtIG5hbWU6IGtleTEKICAgICAgICAgICAgICBzZWNyZXQ6IGMyVmpjbVYwSUdseklITmxZM1Z5WlE9PQogICAgICAgICAgICAtIG5hbWU6IGtleTIKICAgICAgICAgICAgICBzZWNyZXQ6IGRHaHBjeUJwY3lCd1lYTnpkMjl5WkE9PQogICAgICAtIGFlc2NiYzoKICAgICAgICAgIGtleXM6CiAgICAgICAgICAgIC0gbmFtZToga2V5MQogICAgICAgICAgICAgIHNlY3JldDogYzJWamNtVjBJR2x6SUhObFkzVnlaUT09CiAgICAgICAgICAgIC0gbmFtZToga2V5MgogICAgICAgICAgICAgIHNlY3JldDogZEdocGN5QnBjeUJ3WVhOemQyOXlaQT09CiAgICAgIC0gc2VjcmV0Ym94OgogICAgICAgICAga2V5czoKICAgICAgICAgICAgLSBuYW1lOiBrZXkxCiAgICAgICAgICAgICAgc2VjcmV0OiBZV0pqWkdWbVoyaHBhbXRzYlc1dmNIRnljM1IxZG5kNGVYb3hNak0wTlRZPQ==
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: example-encryptionconfig
|
||||
namespace: cattle-resources-system
|
||||
type: Opaque
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
@@ -279,6 +295,3 @@ resources:
|
||||
- name: key1
|
||||
secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Best Practices for Disconnected Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/disconnected-clusters"/>
|
||||
</head>
|
||||
|
||||
Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. At the moment there are no known issues with disconnected clusters in the latest released Rancher version.
|
||||
|
||||
While a managed cluster is disconnected from Rancher, management operations will be unavailable, and the Rancher UI will not allow navigation to the cluster. However, once the connection is reestablished, functionality is fully restored.
|
||||
|
||||
### Best Practices for Managing Disconnected Clusters
|
||||
|
||||
- **Cluster Availability During Rancher Upgrades**: It is recommended to have all, or at least most, managed clusters online during a Rancher upgrade. The reason is that upgrading Rancher automatically upgrades the Rancher agent software running on managed clusters. Keeping the agent and Rancher versions aligned ensures consistent functionality. Any clusters that are disconnected during the upgrade will have their agents updated as soon as they reconnect.
|
||||
|
||||
- **Cleaning Up Disconnected Clusters**: Regularly remove clusters that will no longer reconnect to Rancher (e.g., clusters that have been decommissioned or destroyed). Keeping such clusters in the Rancher management system consumes unnecessary resources, which could impact Rancher's performance over time.
|
||||
|
||||
- **Certificate Rotation Considerations**: When designing processes that involve regularly shutting down clusters, whether connected to Rancher or not, take into account certificate rotation policies. For example, RKE/RKE2/K3s clusters may rotate certificates on startup if they exceeded their lifetime.
|
||||
+4
@@ -14,6 +14,10 @@ Refer to [this guide](logging-best-practices.md) for our recommendations for clu
|
||||
|
||||
Configuring sensible monitoring and alerting rules is vital for running any production workloads securely and reliably. Refer to this [guide](monitoring-best-practices.md) for our recommendations.
|
||||
|
||||
### Disconnected clusters
|
||||
|
||||
Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. Refer to this [guide](disconnected-clusters.md) for our recommendations.
|
||||
|
||||
### Tips for Setting Up Containers
|
||||
|
||||
Running well-built containers can greatly impact the overall performance and security of your environment. Refer to this [guide](tips-to-set-up-containers.md) for tips.
|
||||
|
||||
+1
-1
@@ -198,7 +198,7 @@ The node operating system image. For more information for the node image options
|
||||
|
||||
:::note
|
||||
|
||||
The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
|
||||
The default option is "Container-Optimized OS with Docker". The read-only filesystem on GCP's Container-Optimized OS is not compatible with the [legacy logging](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) implementation in Rancher. If you need to use the legacy logging feature, select "Ubuntu with Docker" or "Ubuntu with Containerd". The [current logging feature](../../../../integrations-in-rancher/logging/logging.md) is compatible with the Container-Optimized OS image.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
Reference in New Issue
Block a user