mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 04:58:07 +00:00
Merge branch 'main' into landing-page-longhorn
This commit is contained in:
Billy Tat
+3
-1
@@ -17,6 +17,7 @@ plugins:
|
||||
- cattle-system
|
||||
- cattle-epinio-system
|
||||
- cattle-fleet-system
|
||||
- cattle-fleet-local-system
|
||||
- longhorn-system
|
||||
- cattle-neuvector-system
|
||||
- cattle-monitoring-system
|
||||
@@ -32,6 +33,7 @@ plugins:
|
||||
- cattle-sriov-system
|
||||
- cattle-ui-plugin-system
|
||||
- tigera-operator
|
||||
- cattle-provisioning-capi-system
|
||||
kind: PodSecurityConfiguration
|
||||
name: PodSecurity
|
||||
path: ""
|
||||
path: ""
|
||||
|
||||
+43
-18
@@ -6,29 +6,54 @@ title: Rollbacks
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks"/>
|
||||
</head>
|
||||
|
||||
## Additional Steps for Rollbacks with Rancher v2.6.4+
|
||||
This page outlines how to rollback Rancher to a previous version after an upgrade.
|
||||
|
||||
Rancher v2.6.4 upgrades the cluster-api module from v0.4.4 to v1.0.2. Version v1.0.2 of the cluster-api, in turn, upgrades the Cluster API's Custom Resource Definitions (CRDs) from `cluster.x-k8s.io/v1alpha4` to `cluster.x-k8s.io/v1beta1`. The CRDs upgrade to v1beta1 causes rollbacks to fail when you attempt to move from Rancher v2.6.4 to any previous version of Rancher v2.6.x. This is because CRDs that use the older apiVersion (v1alpha4) are incompatible with v1beta1.
|
||||
Follow the instructions from this page when:
|
||||
- The running Rancher instance has been upgraded to a newer version after the backup was made.
|
||||
- The upstream (local) cluster is the same as where the backup was made.
|
||||
|
||||
To avoid rollback failure, the following Rancher scripts should be run **before** you attempt a restore operation or rollback:
|
||||
:::tip
|
||||
|
||||
* `verify.sh`: Checks for any Rancher-related resources in the cluster.
|
||||
* `cleanup.sh`: Cleans up the cluster.
|
||||
|
||||
See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup) for more details and source code.
|
||||
|
||||
:::caution
|
||||
|
||||
There will be downtime while `cleanup.sh` runs, since the script deletes resources created by Rancher.
|
||||
* Follow these steps to [migrate Rancher](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md).
|
||||
* If you need to restore Rancher to its previous state at the same Rancher version, see the [restore documentation]( ../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher.md).
|
||||
|
||||
:::
|
||||
|
||||
### Rolling back from v2.6.4+ to lower versions of v2.6.x
|
||||
## Alternative Steps for Special Scenarios
|
||||
|
||||
1. Follow these [instructions](https://github.com/rancher/rancher-cleanup/blob/main/README.md) to run the scripts.
|
||||
1. Follow these [instructions](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) to install the rancher-backup Helm chart on the existing cluster and restore the previous state.
|
||||
1. Omit Step 3.
|
||||
1. When you reach Step 4, install the Rancher v2.6.x version on the local cluster you intend to roll back to.
|
||||
Alternative steps need to be performed for rollbacks in the following scenarios:
|
||||
- Rolling back from v2.6.4 and later to an earlier version of v2.6.x.
|
||||
- Rolling back from v2.7.7 and later to an earlier version of v2.7.x.
|
||||
|
||||
In Rancher v2.6.4, the cluster-api module is upgraded from v0.4.4 to v1.0.2. The cluster-api v1.0.2, in turn, upgrades the apiVersions of its Custom Resource Definitions (CRDs) from `cluster.x-k8s.io/v1alpha4` to `cluster.x-k8s.io/v1beta1`. Custom Resources (CRs) that use the older apiVersion (v1alpha4) are incompatible with v1beta1, which causes rollbacks to fail when you attempt to move from Rancher v2.6.4 to any previous version of Rancher v2.6.x.
|
||||
|
||||
In Rancher v2.7.7, the app `rancher-provisioning-capi` is installed on the upstream (local) cluster automatically as a replacement for the embedded cluster-api controllers. Conflicts and unexpected errors will occur if the upstream cluster contains both the app, and Rancher v2.7.6 and earlier. Therefore, alternative steps are needed if you attempt to move from Rancher v2.7.7 to any previous version of Rancher v2.7.x.
|
||||
|
||||
### Step 1: Clean Up the Upstream (Local) Cluster
|
||||
|
||||
To avoid rollback failure, follow these [instructions](https://github.com/rancher/rancher-cleanup/blob/main/README.md) to run the scripts **before** you attempt a restore operation or rollback:
|
||||
|
||||
* `cleanup.sh`: Cleans up the cluster.
|
||||
* `verify.sh`: Checks for any Rancher-related resources in the cluster.
|
||||
|
||||
:::caution
|
||||
|
||||
There will be downtime while `cleanup.sh` runs, since the script deletes resources created by Rancher.
|
||||
|
||||
:::
|
||||
|
||||
**Result:** all Rancher-related resources should be cleaned up on the upstream (local) cluster.
|
||||
|
||||
See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup) for more details and source code.
|
||||
|
||||
### Step 2: Restore the Backup and Bring Up Rancher
|
||||
|
||||
At this point, there should be no Rancher-related resources on the upstream cluster. Therefore, the next step will be the same as if you were migrating Rancher to a new cluster that contains no Rancher resources.
|
||||
|
||||
Follow these [instructions](./migrate-rancher-to-new-cluster.md) to install the Rancher-Backup Helm chart and restore Rancher to its previous state.
|
||||
Please keep in mind that:
|
||||
1. Step 3 can be skipped, because the Cert-Manager app should still exist on the upstream (local) cluster if it was installed before.
|
||||
2. At Step 4, install the Rancher version you intend to roll back to.
|
||||
|
||||
## Rolling Back to Rancher v2.5.0+
|
||||
|
||||
@@ -46,7 +71,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
|
||||
:::
|
||||
|
||||
### Create the Restore Custom Resource
|
||||
### Step 1: Create the Restore Custom Resource
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the local cluster and click **Explore**.
|
||||
@@ -95,7 +120,7 @@ kubectl get pods -n cattle-resources-system
|
||||
kubectl logs -n cattle-resources-system -f
|
||||
```
|
||||
|
||||
### Roll back to a previous Rancher version
|
||||
### Step 2: Roll Back to a Previous Rancher Version
|
||||
|
||||
Rancher can be rolled back using the Helm CLI. To roll back to the previous version:
|
||||
|
||||
|
||||
+2
-2
@@ -71,7 +71,7 @@ In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
@@ -250,7 +250,7 @@ The workstation must have Docker 18.02+ in order to support manifests, which are
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
|
||||
+2
-2
@@ -35,7 +35,7 @@ kubectl create namespace cert-manager
|
||||
Install the CustomResourceDefinitions of cert-manager:
|
||||
|
||||
```
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
```
|
||||
|
||||
And install it with Helm. Note that cert-manager also needs your proxy configured in case it needs to communicate with Let's Encrypt or other external certificate issuers:
|
||||
@@ -48,7 +48,7 @@ To see options on how to customize the cert-manager install (including for cases
|
||||
|
||||
```
|
||||
helm upgrade --install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager --version v1.11.0 \
|
||||
--namespace cert-manager \
|
||||
--set http_proxy=http://${proxy_host} \
|
||||
--set https_proxy=http://${proxy_host} \
|
||||
--set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
|
||||
|
||||
@@ -6,6 +6,8 @@ title: Upgrading Cert-Manager
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/upgrade-cert-manager"/>
|
||||
</head>
|
||||
|
||||
Rancher is compatible with the API version cert-manager.io/v1 and was last tested with cert-manager version v1.13.1.
|
||||
|
||||
Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, three important changes to cert-manager are set to occur that you need to take action on if you have an HA deployment of Rancher:
|
||||
|
||||
1. [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
|
||||
@@ -96,8 +98,7 @@ In order to upgrade cert-manager, follow these instructions:
|
||||
```plain
|
||||
helm install \
|
||||
cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--version v1.11.0
|
||||
--namespace cert-manager
|
||||
```
|
||||
|
||||
1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
|
||||
@@ -129,7 +130,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
|
||||
1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).
|
||||
|
||||
```plain
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
```
|
||||
|
||||
1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.
|
||||
|
||||
@@ -108,7 +108,7 @@ helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
|
||||
kubectl create namespace cattle-system
|
||||
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
|
||||
@@ -116,14 +116,12 @@ helm repo update
|
||||
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
|
||||
# Windows Powershell
|
||||
helm install cert-manager jetstack/cert-manager `
|
||||
--namespace cert-manager `
|
||||
--create-namespace `
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
The final command to install Rancher is below. The command requires a domain name that forwards traffic to the Linux machine. For the sake of simplicity in this tutorial, you can use a fake domain name to create your proof-of-concept. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`.
|
||||
|
||||
+4
-1
@@ -85,12 +85,13 @@ Any user that is bound to the above permission will be able to change the restri
|
||||
|
||||
## Exempting Required Rancher Namespaces
|
||||
|
||||
When you run Rancher on a Kubernetes cluster that enforces a restrictive security policy by default, you'll need to [exempt the following namespaces](#exempting-namespaces), otherwise the policy might prevent Rancher system pods from running properly.
|
||||
When you run Rancher on a Kubernetes cluster that enforces a restrictive security policy by default, you'll need to [exempt the following namespaces](#exempting-namespaces), otherwise the policy might prevent Rancher system pods from running properly.
|
||||
|
||||
- `calico-apiserver`
|
||||
- `calico-system`
|
||||
- `cattle-alerting`
|
||||
- `cattle-csp-adapter-system`
|
||||
- `cattle-elemental-system`
|
||||
- `cattle-epinio-system`
|
||||
- `cattle-externalip-system`
|
||||
- `cattle-fleet-local-system`
|
||||
@@ -106,6 +107,8 @@ When you run Rancher on a Kubernetes cluster that enforces a restrictive securit
|
||||
- `cattle-monitoring-system`
|
||||
- `cattle-neuvector-system`
|
||||
- `cattle-prometheus`
|
||||
- `cattle-provisioning-capi-system`
|
||||
- `cattle-resources-system`
|
||||
- `cattle-sriov-system`
|
||||
- `cattle-system`
|
||||
- `cattle-ui-plugin-system`
|
||||
|
||||
+13
-28
@@ -8,39 +8,24 @@ title: Restoring Rancher
|
||||
|
||||
This page outlines how to perform a restore with Rancher.
|
||||
|
||||
:::note Important:
|
||||
Follow the instructions from this page when:
|
||||
- The running Rancher instance is at the same version as when the backup was made.
|
||||
- The upstream (local) cluster is the same as where the backup was made.
|
||||
|
||||
* Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.](migrate-rancher-to-new-cluster.md)
|
||||
* While restoring rancher on the same setup, the operator will scale down the rancher deployment when restore starts, and it will scale back up the deployment once restore completes. So Rancher will be unavailable during the restore.
|
||||
* If you need to restore Rancher to a previous version after an upgrade, see the [rollback documentation.](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md)
|
||||
:::note Important
|
||||
|
||||
While restoring Rancher on the same setup, the operator will scale down the Rancher deployment when restore starts, and it will scale back up the deployment once restore completes. Rancher will be unavailable during the restore.
|
||||
|
||||
:::
|
||||
|
||||
## Additional Steps for Rollbacks with Rancher v2.6.4+
|
||||
:::tip
|
||||
|
||||
Rancher v2.6.4 upgrades the cluster-api module from v0.4.4 to v1.0.2. Version v1.0.2 of the cluster-api, in turn, upgrades the Cluster API's Custom Resource Definitions (CRDs) from `cluster.x-k8s.io/v1alpha4` to `cluster.x-k8s.io/v1beta1`. The CRDs upgrade to v1beta1 causes rollbacks to fail when you attempt to move from Rancher v2.6.4 to any previous version of Rancher v2.6.x. This is because CRDs that use the older apiVersion (v1alpha4) are incompatible with v1beta1.
|
||||
|
||||
To avoid rollback failure, the following Rancher scripts should be run **before** you attempt a restore operation or rollback:
|
||||
|
||||
* `verify.sh`: Checks for any Rancher-related resources in the cluster.
|
||||
* `cleanup.sh`: Cleans up the cluster.
|
||||
|
||||
See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup) for more details and source code.
|
||||
|
||||
:::caution
|
||||
|
||||
There will be downtime while `cleanup.sh` runs, since the script deletes resources created by Rancher.
|
||||
* Follow those steps to [migrate Rancher](migrate-rancher-to-new-cluster.md).
|
||||
* If you need to restore Rancher to a previous version after an upgrade, see the [rollback documentation](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md).
|
||||
|
||||
:::
|
||||
|
||||
### Rolling back from v2.6.4+ to lower versions of v2.6.x
|
||||
|
||||
1. Follow these [instructions](https://github.com/rancher/rancher-cleanup/blob/main/README.md) to run the scripts.
|
||||
1. Follow these [instructions](./migrate-rancher-to-new-cluster.md) to install the rancher-backup Helm chart on the existing cluster and restore the previous state.
|
||||
1. Omit Step 3.
|
||||
1. When you reach Step 4, install the Rancher v2.6.x version on the local cluster you intend to roll back to.
|
||||
|
||||
### Create the Restore Custom Resource
|
||||
## Create the Restore Custom Resource
|
||||
|
||||
A restore is performed by creating a Restore custom resource.
|
||||
|
||||
@@ -79,7 +64,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
2. Cluster-scoped resources
|
||||
3. Namespaced resources
|
||||
|
||||
### Logs
|
||||
## Logs
|
||||
|
||||
To check how the restore is progressing, you can check the logs of the operator. Run this command to follow the logs:
|
||||
|
||||
@@ -87,11 +72,11 @@ To check how the restore is progressing, you can check the logs of the operator.
|
||||
kubectl logs -n cattle-resources-system -l app.kubernetes.io/name=rancher-backup -f
|
||||
```
|
||||
|
||||
### Cleanup
|
||||
## Cleanup
|
||||
|
||||
If you created the restore resource with kubectl, remove the resource to prevent a naming conflict with future restores.
|
||||
|
||||
### Known Issues
|
||||
## Known Issues
|
||||
In some cases, after restoring the backup, Rancher logs will show errors similar to the following:
|
||||
```
|
||||
2021/10/05 21:30:45 [ERROR] error syncing 'c-89d82/m-4067aa68dd78': handler rke-worker-upgrader: clusters.management.cattle.io "c-89d82" not found, requeuing
|
||||
|
||||
@@ -149,7 +149,7 @@ To see options on how to customize the cert-manager install (including for cases
|
||||
|
||||
```
|
||||
# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
# Add the Jetstack Helm repository
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
@@ -160,8 +160,7 @@ helm repo update
|
||||
# Install the cert-manager Helm chart
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
|
||||
|
||||
@@ -23,6 +23,10 @@ See our page on [best practices](../reference-guides/best-practices/rancher-serv
|
||||
|
||||
Rancher needs to be installed on a supported Kubernetes version. Consult the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions) to ensure that your intended version of Kubernetes is supported.
|
||||
|
||||
### Install Rancher on a Hardened Kubernetes cluster
|
||||
|
||||
If you install Rancher on a hardened Kubernetes cluster, check the [Exempting Required Rancher Namespaces](../../../docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#exempting-required-rancher-namespaces) section for detailed requirements.
|
||||
|
||||
## Operating Systems and Container Runtime Requirements
|
||||
|
||||
All supported operating systems are 64-bit x86. Rancher should work with any modern Linux distribution.
|
||||
|
||||
@@ -209,41 +209,44 @@ services:
|
||||
exemptions:
|
||||
usernames: []
|
||||
runtimeClasses: []
|
||||
namespaces: [ calico-apiserver,
|
||||
calico-system,
|
||||
cattle-alerting,
|
||||
cattle-csp-adapter-system,
|
||||
cattle-epinio-system,
|
||||
cattle-externalip-system,
|
||||
cattle-fleet-local-system,
|
||||
cattle-fleet-system,
|
||||
cattle-gatekeeper-system,
|
||||
cattle-global-data,
|
||||
cattle-global-nt,
|
||||
cattle-impersonation-system,
|
||||
cattle-istio,
|
||||
cattle-istio-system,
|
||||
cattle-logging,
|
||||
cattle-logging-system,
|
||||
cattle-monitoring-system,
|
||||
cattle-neuvector-system,
|
||||
cattle-prometheus,
|
||||
cattle-sriov-system,
|
||||
cattle-system,
|
||||
cattle-ui-plugin-system,
|
||||
cattle-windows-gmsa-system,
|
||||
cert-manager,
|
||||
cis-operator-system,
|
||||
fleet-default,
|
||||
ingress-nginx,
|
||||
istio-system,
|
||||
kube-node-lease,
|
||||
kube-public,
|
||||
kube-system,
|
||||
longhorn-system,
|
||||
rancher-alerting-drivers,
|
||||
security-scan,
|
||||
tigera-operator ]
|
||||
namespaces: [calico-apiserver,
|
||||
calico-system,
|
||||
cattle-alerting,
|
||||
cattle-csp-adapter-system,
|
||||
cattle-elemental-system,
|
||||
cattle-epinio-system,
|
||||
cattle-externalip-system,
|
||||
cattle-fleet-local-system,
|
||||
cattle-fleet-system,
|
||||
cattle-gatekeeper-system,
|
||||
cattle-global-data,
|
||||
cattle-global-nt,
|
||||
cattle-impersonation-system,
|
||||
cattle-istio,
|
||||
cattle-istio-system,
|
||||
cattle-logging,
|
||||
cattle-logging-system,
|
||||
cattle-monitoring-system,
|
||||
cattle-neuvector-system,
|
||||
cattle-prometheus,
|
||||
cattle-provisioning-capi-system,
|
||||
cattle-resources-system,
|
||||
cattle-sriov-system,
|
||||
cattle-system,
|
||||
cattle-ui-plugin-system,
|
||||
cattle-windows-gmsa-system,
|
||||
cert-manager,
|
||||
cis-operator-system,
|
||||
fleet-default,
|
||||
ingress-nginx,
|
||||
istio-system,
|
||||
kube-node-lease,
|
||||
kube-public,
|
||||
kube-system,
|
||||
longhorn-system,
|
||||
rancher-alerting-drivers,
|
||||
security-scan,
|
||||
tigera-operator]
|
||||
kube-controller:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
|
||||
@@ -46,6 +46,7 @@ plugins:
|
||||
cattle-monitoring-system,
|
||||
cattle-neuvector-system,
|
||||
cattle-prometheus,
|
||||
cattle-provisioning-capi-system,
|
||||
cattle-resources-system,
|
||||
cattle-sriov-system,
|
||||
cattle-system,
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
|
||||
/** @type {import('@docusaurus/types').DocusaurusConfig} */
|
||||
const tailwindPlugin = require('./plugins/tailwind-plugin.cjs');
|
||||
|
||||
module.exports = {
|
||||
title: 'Rancher',
|
||||
tagline: '',
|
||||
@@ -184,6 +186,7 @@ module.exports = {
|
||||
],
|
||||
],
|
||||
plugins: [
|
||||
tailwindPlugin,
|
||||
[
|
||||
'@docusaurus/plugin-client-redirects',
|
||||
{
|
||||
|
||||
+3
-3
@@ -102,14 +102,14 @@ helm repo update
|
||||
从 [Helm Chart 仓库](https://artifacthub.io/packages/helm/cert-manager/cert-manager)中获取最新可用的 cert-manager Chart：
|
||||
|
||||
```plain
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
```
|
||||
|
||||
##### 3. 检索 Cert-Manager CRD
|
||||
|
||||
为 cert-manager 下载所需的 CRD 文件：
|
||||
```plain
|
||||
curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
```
|
||||
|
||||
### 4. 安装 Rancher
|
||||
@@ -146,7 +146,7 @@ curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/re
|
||||
3. 安装 cert-manager。
|
||||
|
||||
```plain
|
||||
helm install cert-manager ./cert-manager-v1.11.0.tgz \
|
||||
helm install cert-manager ./cert-manager-<VERSION>.tgz \
|
||||
--namespace cert-manager \
|
||||
--set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller \
|
||||
--set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook \
|
||||
|
||||
+2
-2
@@ -67,7 +67,7 @@ title: '2. 收集镜像并发布到私有仓库'
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
@@ -246,7 +246,7 @@ Linux 镜像需要在 Linux 主机上收集和推送，但是你必须先将 Win
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
|
||||
+2
-2
@@ -31,7 +31,7 @@ kubectl create namespace cert-manager
|
||||
安装 cert-manager 的 CustomResourceDefinitions：
|
||||
|
||||
```
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
```
|
||||
|
||||
使用 Helm 安装 cert-manager。请注意，cert-manager 还需要你配置代理，以防它需要与 Let's Encrypt 或其他外部证书颁发商进行通信：
|
||||
@@ -44,7 +44,7 @@ kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/
|
||||
|
||||
```
|
||||
helm upgrade --install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager --version v1.11.0 \
|
||||
--namespace cert-manager \
|
||||
--set http_proxy=http://${proxy_host} \
|
||||
--set https_proxy=http://${proxy_host} \
|
||||
--set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
|
||||
|
||||
+2
-3
@@ -92,8 +92,7 @@ Rancher 使用 cert-manager 为 Rancher 高可用部署自动生成和续期 TLS
|
||||
```plain
|
||||
helm install \
|
||||
cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--version v1.11.0
|
||||
--namespace cert-manager
|
||||
```
|
||||
|
||||
1. [恢复备份资源](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)：
|
||||
@@ -125,7 +124,7 @@ Rancher 使用 cert-manager 为 Rancher 高可用部署自动生成和续期 TLS
|
||||
1. 从 [Helm Chart 仓库](https://artifacthub.io/packages/helm/cert-manager/cert-manager)中获取最新可用的 cert-manager Chart：
|
||||
|
||||
```plain
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
```
|
||||
|
||||
1. 使用安装 Chart 的选项来渲染 cert-manager 模板。记住要设置 `image.repository` 选项，以从你的私有镜像仓库拉取镜像。此操作会创建一个包含 Kubernetes manifest 文件的 `cert-manager` 目录。
|
||||
|
||||
+3
-5
@@ -104,7 +104,7 @@ helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
|
||||
kubectl create namespace cattle-system
|
||||
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
|
||||
@@ -112,14 +112,12 @@ helm repo update
|
||||
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
|
||||
# Windows Powershell
|
||||
helm install cert-manager jetstack/cert-manager `
|
||||
--namespace cert-manager `
|
||||
--create-namespace `
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
安装 Rancher 的最终命令如下。该命令需要一个将流量转发到 Linux 主机的域名。为了简化本教程，你可以使用假域名。`<IP_OF_LINUX_NODE>.sslip.io` 是一个假域名的例子。
|
||||
|
||||
+2
-3
@@ -145,7 +145,7 @@ Rancher Management Server 默认需要 SSL/TLS 配置来保证访问的安全性
|
||||
|
||||
```
|
||||
# 如果你手动安装了CRD，而不是在 Helm 安装命令中添加了 `--set installCRDs=true` 选项，你应该在升级 Helm Chart 之前升级 CRD 资源。
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
# 添加 Jetstack Helm 仓库
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
@@ -156,8 +156,7 @@ helm repo update
|
||||
# 安装 cert-manager Helm Chart
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
安装完 cert-manager 后，你可以通过检查 cert-manager 命名空间中正在运行的 Pod 来验证它是否已正确部署：
|
||||
|
||||
+8
-2
@@ -17,17 +17,23 @@
|
||||
"@docusaurus/core": "^2.3.1",
|
||||
"@docusaurus/plugin-client-redirects": "^2.3.1",
|
||||
"@docusaurus/preset-classic": "^2.3.1",
|
||||
"@fluentui/react-icons": "^2.0.204",
|
||||
"@mdx-js/react": "^1.6.22",
|
||||
"@swc/core": "^1.3.62",
|
||||
"clsx": "^1.1.1",
|
||||
"autoprefixer": "^10.4.15",
|
||||
"clsx": "^1.2.1",
|
||||
"postcss": "^8.4.28",
|
||||
"param-case": "^3.0.4",
|
||||
"prism-react-renderer": "^1.3.3",
|
||||
"react": "^17.0.2",
|
||||
"react-dom": "^17.0.2",
|
||||
"react-icons": "^4.10.1",
|
||||
"redocusaurus": "^1.6.3",
|
||||
"remark-cli": "^11.0.0",
|
||||
"remark-lint-no-dead-urls": "^1.1.0",
|
||||
"remark-validate-links": "^12.1.0",
|
||||
"swc-loader": "^0.2.3"
|
||||
"swc-loader": "^0.2.3",
|
||||
"tailwindcss": "^3.3.3"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@docusaurus/module-type-aliases": "^2.3.1"
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
function tailwindPlugin(context, options) {
|
||||
return {
|
||||
name: 'tailwind-plugin',
|
||||
configurePostCss(postcssOptions) {
|
||||
postcssOptions.plugins = [
|
||||
require('postcss-import'),
|
||||
require('tailwindcss'),
|
||||
require('autoprefixer'),
|
||||
];
|
||||
return postcssOptions;
|
||||
},
|
||||
};
|
||||
}
|
||||
|
||||
module.exports = tailwindPlugin;
|
||||
+1
-1
@@ -57,7 +57,7 @@ const sidebars = {
|
||||
"getting-started/quick-start-guides/deploy-rancher-manager/prime",
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Deploy Rancher Workloads',
|
||||
label: 'Deploy Workloads',
|
||||
link: {
|
||||
type: 'doc',
|
||||
id: "pages-for-subheaders/deploy-rancher-workloads",
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
import React, { ReactNode } from 'react';
|
||||
import { paramCase } from 'param-case';
|
||||
import Link from '@docusaurus/Link';
|
||||
import clsx from 'clsx';
|
||||
|
||||
export function CardSection({
|
||||
id,
|
||||
title,
|
||||
icon,
|
||||
children,
|
||||
description,
|
||||
className,
|
||||
hasSubSections = false,
|
||||
HeadingTag = 'h1',
|
||||
}: {
|
||||
id?: string;
|
||||
title?: string;
|
||||
icon?: JSX.Element;
|
||||
children: ReactNode;
|
||||
description?: ReactNode;
|
||||
hasSubSections?: boolean;
|
||||
HeadingTag?: any;
|
||||
className?: string;
|
||||
}) {
|
||||
return (
|
||||
<div
|
||||
className={clsx(
|
||||
'homepage-section',
|
||||
hasSubSections && 'has-sub-sections',
|
||||
className
|
||||
)}
|
||||
>
|
||||
{title && <span><HeadingTag id={id ?? paramCase(title)}>{title}</HeadingTag></span>}
|
||||
{description && <p className="section-description">{description}</p>}
|
||||
<div className="section-content">{children}</div>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
export function Card({
|
||||
id,
|
||||
icon,
|
||||
title,
|
||||
description,
|
||||
to,
|
||||
}: {
|
||||
id?: string;
|
||||
icon?: JSX.Element;
|
||||
title?: string;
|
||||
description?: string;
|
||||
to: string;
|
||||
}) {
|
||||
return (
|
||||
<Link to={to} className="homepage-card">
|
||||
{icon && <div className="icon">{icon}</div>}
|
||||
<div className="card-content">
|
||||
<div className="title" id={id && paramCase(title)}>
|
||||
{title}
|
||||
</div>
|
||||
{description && <div className="description">{description}</div>}
|
||||
</div>
|
||||
</Link>
|
||||
);
|
||||
}
|
||||
@@ -0,0 +1,79 @@
|
||||
import React from 'react';
|
||||
import clsx from 'clsx';
|
||||
import styles from './styles.module.css';
|
||||
import {Card, CardSection} from '../CardComponents';
|
||||
import {
|
||||
ReadingModeMobileRegular,
|
||||
QuestionRegular,
|
||||
ArrowUpRegular,
|
||||
PlayRegular,
|
||||
FlowchartRegular,
|
||||
RocketRegular
|
||||
} from '@fluentui/react-icons';
|
||||
import { FaAws, FaGoogle, FaCloud } from "react-icons/fa";
|
||||
|
||||
export default function HomepageFeatures(): JSX.Element {
|
||||
return (
|
||||
<section className={styles.features}>
|
||||
<div className="container">
|
||||
<br></br>
|
||||
<CardSection
|
||||
id="Gettingstarted"
|
||||
icon={<RocketRegular />}
|
||||
title="Getting Started"
|
||||
>
|
||||
<Card
|
||||
title="What is Rancher?"
|
||||
icon={<QuestionRegular />}
|
||||
to="/intro"
|
||||
description="Understand what Rancher is and is not"
|
||||
/>
|
||||
<Card
|
||||
title="Overview"
|
||||
icon={<ReadingModeMobileRegular />}
|
||||
to="/getting-started/overview"
|
||||
description="Learn about the core capabilities"
|
||||
/>
|
||||
<Card
|
||||
title="Rancher Concepts"
|
||||
icon={<FlowchartRegular />}
|
||||
to="/pages-for-subheaders/rancher-manager-architecture"
|
||||
description="Learn about high level concepts, architectural elements of Rancher"
|
||||
/>
|
||||
<Card
|
||||
title="Install Rancher"
|
||||
icon={<ArrowUpRegular />}
|
||||
to="/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli"
|
||||
description="Quick way to helm install Rancher in a Kubernetes cluster"
|
||||
/>
|
||||
<Card
|
||||
title="Deploy Workloads"
|
||||
icon={<PlayRegular />}
|
||||
to="/pages-for-subheaders/deploy-rancher-workloads"
|
||||
description="Deploy a sample workload"
|
||||
/>
|
||||
</CardSection>
|
||||
<CardSection
|
||||
id="CloudDeployments"
|
||||
title="Cloud Deployment"
|
||||
>
|
||||
<Card
|
||||
icon={<FaAws />}
|
||||
to="/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks"
|
||||
description="Deploy Rancher on an Amazon EKS cluster"
|
||||
/>
|
||||
<Card
|
||||
icon={<FaCloud />}
|
||||
to="/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks"
|
||||
description="Deploy Rancher on Microsoft's Azure Kubernetes Service (AKS)"
|
||||
/>
|
||||
<Card
|
||||
icon={<FaGoogle />}
|
||||
to="/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke"
|
||||
description="Deploy Rancher on Google Kubernetes Engine"
|
||||
/>
|
||||
</CardSection>
|
||||
</div>
|
||||
</section>
|
||||
);
|
||||
}
|
||||
@@ -0,0 +1,11 @@
|
||||
.features {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
padding: 2rem 0;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
.featureSvg {
|
||||
height: 200px;
|
||||
width: 200px;
|
||||
}
|
||||
+228
-2
@@ -35,7 +35,61 @@
|
||||
url('../fonts/lato/lato-regular.woff') format('woff2'), /* Super Modern Browsers */
|
||||
url('../fonts/lato/lato-regular.woff2') format('woff'), /* Modern Browsers */
|
||||
}
|
||||
/* You can override the default Infima variables here. */
|
||||
|
||||
@tailwind base;
|
||||
|
||||
@layer base {
|
||||
:root {
|
||||
--docs-color-primary-100: 26 144 255;
|
||||
--docs-color-primary-200: 33 96 253;
|
||||
|
||||
--docs-color-secondary-700: 232 232 236;
|
||||
--docs-color-secondary-800: 245 245 247;
|
||||
--docs-color-secondary-900: 251 251 251;
|
||||
--docs-color-secondary-1000: 255 255 255;
|
||||
|
||||
--docs-color-text-400: 71 71 71;
|
||||
}
|
||||
|
||||
html[data-theme='dark'] {
|
||||
--docs-color-text-400: 153 153 153;
|
||||
|
||||
--docs-color-secondary-700: 71 71 71;
|
||||
--docs-color-secondary-800: 38 38 38;
|
||||
--docs-color-secondary-900: 25 25 25;
|
||||
--docs-color-secondary-1000: 0 0 0;
|
||||
}
|
||||
|
||||
body {
|
||||
@apply font-sans antialiased;
|
||||
}
|
||||
|
||||
.homepage a {
|
||||
--ifm-link-hover-color: currentColor;
|
||||
}
|
||||
|
||||
.no-underline-links {
|
||||
--ifm-link-hover-decoration: none;
|
||||
}
|
||||
|
||||
a {
|
||||
@apply cursor-pointer;
|
||||
}
|
||||
|
||||
h1,
|
||||
h2,
|
||||
h3,
|
||||
h4,
|
||||
h5 {
|
||||
@apply font-jakarta;
|
||||
}
|
||||
|
||||
.homepage section,
|
||||
.homepage section * {
|
||||
@apply box-border;
|
||||
}
|
||||
}
|
||||
|
||||
:root {
|
||||
--ifm-color-primary-lightest: #80bbe2;
|
||||
--ifm-color-primary-lighter: #5eaadb;
|
||||
@@ -45,7 +99,18 @@
|
||||
--ifm-color-primary-darker: #2b83bc;
|
||||
--ifm-color-primary-darkest: #236c9b;
|
||||
--ifm-code-font-size: 95%;
|
||||
|
||||
--docs-color-border: #dadde1;
|
||||
|
||||
--docs-color-text: #000000;
|
||||
--docs-color-text-100: #646464;
|
||||
|
||||
--docs-color-background: #ffffff;
|
||||
--docs-color-background-100: #f8f8f8;
|
||||
--docs-color-background-200: #efefef;
|
||||
--docs-color-background-300: #dcdcdc;
|
||||
}
|
||||
|
||||
@media (max-width: 768px) {
|
||||
#theme-main h1 {
|
||||
font-size: 50px !important;
|
||||
@@ -160,4 +225,165 @@ a.btn.navbar__github::before {
|
||||
height: 100%;
|
||||
width: 100%;
|
||||
position: absolute;
|
||||
}
|
||||
}
|
||||
|
||||
img[src$='#terminal'] {
|
||||
display: block;
|
||||
max-width: 720px;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
}
|
||||
|
||||
.pad {
|
||||
padding: 0 1rem;
|
||||
}
|
||||
|
||||
.center {
|
||||
width: 100%;
|
||||
max-width: 1080px;
|
||||
margin: 1rem auto;
|
||||
min-height: 400px;
|
||||
}
|
||||
|
||||
.homepage-content {
|
||||
padding-bottom: 6rem;
|
||||
}
|
||||
|
||||
#hero {
|
||||
padding: 2rem 0 1.5rem 0;
|
||||
margin-bottom: 4rem;
|
||||
border-bottom: 1px solid var(--docs-color-border);
|
||||
}
|
||||
|
||||
#hero h2 {
|
||||
font-size: 36px;
|
||||
}
|
||||
|
||||
#hero p {
|
||||
color: var(--docs-color-text-100);
|
||||
}
|
||||
|
||||
.section-content {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(2, minmax(0, 1fr));
|
||||
gap: 12px;
|
||||
}
|
||||
|
||||
.two-cols .section-content {
|
||||
grid-template-columns: repeat(2, minmax(0, 1fr));
|
||||
}
|
||||
|
||||
.has-sub-sections > h3 {
|
||||
margin-bottom: 1.5rem;
|
||||
}
|
||||
|
||||
.has-sub-sections > .section-content {
|
||||
grid-template-columns: repeat(1, minmax(0, 1fr));
|
||||
}
|
||||
.has-sub-sections > .section-content > .homepage-section {
|
||||
margin-bottom: 1rem;
|
||||
grid-template-columns: repeat(1, minmax(0, 1fr));
|
||||
}
|
||||
|
||||
.homepage-section {
|
||||
margin-bottom: 3rem;
|
||||
}
|
||||
|
||||
.homepage-section h3 {
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.section-description {
|
||||
color: var(--docs-color-text-100);
|
||||
margin: 0rem 0 1.25rem 0;
|
||||
margin-top: -0.5rem;
|
||||
}
|
||||
|
||||
.has-sub-sections > .section-content .section-description {
|
||||
font-size: 14px;
|
||||
}
|
||||
|
||||
.homepage-card {
|
||||
align-items: flex-start;
|
||||
gap: 10px;
|
||||
padding: 0.75rem;
|
||||
text-decoration: none;
|
||||
color: var(--docs-color-text);
|
||||
|
||||
--ifm-link-hover-decoration: none;
|
||||
--ifm-link-hover-color: inherit;
|
||||
cursor: pointer;
|
||||
@apply flex flex-row items-center;
|
||||
@apply border-secondary-800 bg-secondary-900 hover:bg-secondary-800;
|
||||
border-width: 1px;
|
||||
transition-property: background-color, color;
|
||||
|
||||
border-radius: 8px;
|
||||
}
|
||||
|
||||
.homepage-card.row {
|
||||
flex-direction: row;
|
||||
}
|
||||
|
||||
.icon svg {
|
||||
width: auto;
|
||||
height: 100%;
|
||||
}
|
||||
|
||||
.homepage-card .icon {
|
||||
width: 48px;
|
||||
height: 48px;
|
||||
@apply mx-1;
|
||||
/* background-color: #262626;
|
||||
border-radius: 8px; */
|
||||
}
|
||||
|
||||
.card-content {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 4px;
|
||||
}
|
||||
|
||||
.card-content .title {
|
||||
font-size: 16px;
|
||||
letter-spacing: -0.5px;
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.card-content .description {
|
||||
font-size: 14px;
|
||||
color: var(--docs-color-text-100);
|
||||
line-height: 1.5;
|
||||
}
|
||||
|
||||
.homepage-card details {
|
||||
font-size: 14px;
|
||||
font-weight: 500;
|
||||
color: var(--docs-color-text-100) !important;
|
||||
background: var(--docs-color-background-100) !important;
|
||||
border: solid 2px var(--docs-color-code-background) !important;
|
||||
}
|
||||
|
||||
details code {
|
||||
background-color: var(--docs-color-background);
|
||||
}
|
||||
|
||||
details p {
|
||||
font-weight: 300;
|
||||
}
|
||||
|
||||
@media screen and (max-width: 1160px) {
|
||||
/* Hide icons when header UI breaks */
|
||||
.pseudo-icon {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
@media screen and (max-width: 768px) {
|
||||
.section-content {
|
||||
grid-template-columns: repeat(1, minmax(0, 1fr));
|
||||
}
|
||||
.two-cols .section-content {
|
||||
grid-template-columns: repeat(1, minmax(0, 1fr));
|
||||
}
|
||||
}
|
||||
|
||||
@@ -0,0 +1,23 @@
|
||||
/**
|
||||
* CSS files with the .module.css suffix will be treated as CSS modules
|
||||
* and scoped locally.
|
||||
*/
|
||||
|
||||
.heroBanner {
|
||||
padding: 4rem 0;
|
||||
text-align: center;
|
||||
position: relative;
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
@media screen and (max-width: 996px) {
|
||||
.heroBanner {
|
||||
padding: 2rem;
|
||||
}
|
||||
}
|
||||
|
||||
.buttons {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
}
|
||||
@@ -0,0 +1,41 @@
|
||||
import React from 'react';
|
||||
import clsx from 'clsx';
|
||||
import Link from '@docusaurus/Link';
|
||||
import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
|
||||
import Layout from '@theme/Layout';
|
||||
// import HomepageFeatures from '@site/src/components/HomepageFeatures';
|
||||
|
||||
import styles from './index.module.css';
|
||||
|
||||
function HomepageHeader() {
|
||||
const {siteConfig} = useDocusaurusContext();
|
||||
return (
|
||||
<header className={clsx('hero hero--primary', styles.heroBanner)}>
|
||||
<div className="container">
|
||||
<h1 className="hero__title">{siteConfig.title}</h1>
|
||||
<p className="hero__subtitle">{siteConfig.tagline}</p>
|
||||
<div className={styles.buttons}>
|
||||
<Link
|
||||
className="button button--secondary button--lg"
|
||||
to="/intro">
|
||||
Full Documentation 📖
|
||||
</Link>
|
||||
</div>
|
||||
</div>
|
||||
</header>
|
||||
);
|
||||
}
|
||||
|
||||
export default function Home(): JSX.Element {
|
||||
const {siteConfig} = useDocusaurusContext();
|
||||
return (
|
||||
<Layout
|
||||
title={`Rancher Docs`}
|
||||
description="Guides, Tutorials, References about Rancher Kubernetes Management Platform">
|
||||
<HomepageHeader />
|
||||
<main>
|
||||
<HomepageFeatures />
|
||||
</main>
|
||||
</Layout>
|
||||
);
|
||||
}
|
||||
@@ -0,0 +1,18 @@
|
||||
// Import the original mapper
|
||||
import MDXComponents from '@theme-original/MDXComponents';
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
import { CardSection, Card } from '../components/CardComponents';
|
||||
|
||||
export default {
|
||||
// Re-use the default mapping
|
||||
...MDXComponents,
|
||||
|
||||
Tabs,
|
||||
TabItem,
|
||||
|
||||
CardSection,
|
||||
Card,
|
||||
};
|
||||
@@ -0,0 +1,47 @@
|
||||
const { fontFamily } = require('tailwindcss/defaultTheme');
|
||||
|
||||
/** @type {import('tailwindcss').Config} */
|
||||
module.exports = {
|
||||
corePlugins: {
|
||||
preflight: false,
|
||||
container: false,
|
||||
},
|
||||
darkMode: ['class', '[data-theme="dark"]'],
|
||||
content: ['./src/**/*.{jsx,tsx,html}'],
|
||||
theme: {
|
||||
extend: {
|
||||
fontFamily: {
|
||||
sans: ['"Inter"', ...fontFamily.sans],
|
||||
jakarta: ['"Plus Jakarta Sans"', ...fontFamily.sans],
|
||||
mono: ['"Fira Code"', ...fontFamily.mono],
|
||||
},
|
||||
borderRadius: {
|
||||
sm: '4px',
|
||||
},
|
||||
screens: {
|
||||
sm: '0px',
|
||||
lg: '997px',
|
||||
},
|
||||
colors: {
|
||||
primary: {
|
||||
DEFAULT:
|
||||
'rgb(var(--docs-color-primary-200, 33 96 253) / <alpha-value>)',
|
||||
100: 'rgb(var(--docs-color-primary-100, 26 144 255) / <alpha-value>)',
|
||||
200: 'rgb(var(--docs-color-primary-200, 33 96 253) / <alpha-value>)',
|
||||
},
|
||||
secondary: {
|
||||
DEFAULT:
|
||||
'rgb(var(--docs-color-secondary-1000, 0 0 0) / <alpha-value>)',
|
||||
1000: 'rgb(var(--docs-color-secondary-1000, 0 0 0) / <alpha-value>)',
|
||||
900: 'rgb(var(--docs-color-secondary-900, 25 25 25) / <alpha-value>)',
|
||||
800: 'rgb(var(--docs-color-secondary-800, 38 38 38) / <alpha-value>)',
|
||||
700: 'rgb(var(--docs-color-secondary-700, 71 71 71) / <alpha-value>)',
|
||||
},
|
||||
text: {
|
||||
400: 'rgb(var(--docs-color-text-400, 153 153 153) / <alpha-value>)',
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
plugins: [],
|
||||
};
|
||||
+3
-1
@@ -17,6 +17,7 @@ plugins:
|
||||
- cattle-system
|
||||
- cattle-epinio-system
|
||||
- cattle-fleet-system
|
||||
- cattle-fleet-local-system
|
||||
- longhorn-system
|
||||
- cattle-neuvector-system
|
||||
- cattle-monitoring-system
|
||||
@@ -32,6 +33,7 @@ plugins:
|
||||
- cattle-sriov-system
|
||||
- cattle-ui-plugin-system
|
||||
- tigera-operator
|
||||
- cattle-provisioning-capi-system
|
||||
kind: PodSecurityConfiguration
|
||||
name: PodSecurity
|
||||
path: ""
|
||||
path: ""
|
||||
|
||||
+43
-18
@@ -6,29 +6,54 @@ title: Rollbacks
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks"/>
|
||||
</head>
|
||||
|
||||
## Additional Steps for Rollbacks with Rancher v2.6.4+
|
||||
This page outlines how to rollback Rancher to a previous version after an upgrade.
|
||||
|
||||
Rancher v2.6.4 upgrades the cluster-api module from v0.4.4 to v1.0.2. Version v1.0.2 of the cluster-api, in turn, upgrades the Cluster API's Custom Resource Definitions (CRDs) from `cluster.x-k8s.io/v1alpha4` to `cluster.x-k8s.io/v1beta1`. The CRDs upgrade to v1beta1 causes rollbacks to fail when you attempt to move from Rancher v2.6.4 to any previous version of Rancher v2.6.x. This is because CRDs that use the older apiVersion (v1alpha4) are incompatible with v1beta1.
|
||||
Follow the instructions from this page when:
|
||||
- The running Rancher instance has been upgraded to a newer version after the backup was made.
|
||||
- The upstream (local) cluster is the same as where the backup was made.
|
||||
|
||||
To avoid rollback failure, the following Rancher scripts should be run **before** you attempt a restore operation or rollback:
|
||||
:::tip
|
||||
|
||||
* `verify.sh`: Checks for any Rancher-related resources in the cluster.
|
||||
* `cleanup.sh`: Cleans up the cluster.
|
||||
|
||||
See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup) for more details and source code.
|
||||
|
||||
:::caution
|
||||
|
||||
There will be downtime while `cleanup.sh` runs, since the script deletes resources created by Rancher.
|
||||
* Follow these steps to [migrate Rancher](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md).
|
||||
* If you need to restore Rancher to its previous state at the same Rancher version, see the [restore documentation]( ../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher.md).
|
||||
|
||||
:::
|
||||
|
||||
### Rolling back from v2.6.4+ to lower versions of v2.6.x
|
||||
## Alternative Steps for Special Scenarios
|
||||
|
||||
1. Follow these [instructions](https://github.com/rancher/rancher-cleanup/blob/main/README.md) to run the scripts.
|
||||
1. Follow these [instructions](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) to install the rancher-backup Helm chart on the existing cluster and restore the previous state.
|
||||
1. Omit Step 3.
|
||||
1. When you reach Step 4, install the Rancher v2.6.x version on the local cluster you intend to roll back to.
|
||||
Alternative steps need to be performed for rollbacks in the following scenarios:
|
||||
- Rolling back from v2.6.4 and later to an earlier version of v2.6.x.
|
||||
- Rolling back from v2.7.7 and later to an earlier version of v2.7.x.
|
||||
|
||||
In Rancher v2.6.4, the cluster-api module is upgraded from v0.4.4 to v1.0.2. The cluster-api v1.0.2, in turn, upgrades the apiVersions of its Custom Resource Definitions (CRDs) from `cluster.x-k8s.io/v1alpha4` to `cluster.x-k8s.io/v1beta1`. Custom Resources (CRs) that use the older apiVersion (v1alpha4) are incompatible with v1beta1, which causes rollbacks to fail when you attempt to move from Rancher v2.6.4 to any previous version of Rancher v2.6.x.
|
||||
|
||||
In Rancher v2.7.7, the app `rancher-provisioning-capi` is installed on the upstream (local) cluster automatically as a replacement for the embedded cluster-api controllers. Conflicts and unexpected errors will occur if the upstream cluster contains both the app, and Rancher v2.7.6 and earlier. Therefore, alternative steps are needed if you attempt to move from Rancher v2.7.7 to any previous version of Rancher v2.7.x.
|
||||
|
||||
### Step 1: Clean Up the Upstream (Local) Cluster
|
||||
|
||||
To avoid rollback failure, follow these [instructions](https://github.com/rancher/rancher-cleanup/blob/main/README.md) to run the scripts **before** you attempt a restore operation or rollback:
|
||||
|
||||
* `cleanup.sh`: Cleans up the cluster.
|
||||
* `verify.sh`: Checks for any Rancher-related resources in the cluster.
|
||||
|
||||
:::caution
|
||||
|
||||
There will be downtime while `cleanup.sh` runs, since the script deletes resources created by Rancher.
|
||||
|
||||
:::
|
||||
|
||||
**Result:** all Rancher-related resources should be cleaned up on the upstream (local) cluster.
|
||||
|
||||
See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup) for more details and source code.
|
||||
|
||||
### Step 2: Restore the Backup and Bring Up Rancher
|
||||
|
||||
At this point, there should be no Rancher-related resources on the upstream cluster. Therefore, the next step will be the same as if you were migrating Rancher to a new cluster that contains no Rancher resources.
|
||||
|
||||
Follow these [instructions](./migrate-rancher-to-new-cluster.md) to install the Rancher-Backup Helm chart and restore Rancher to its previous state.
|
||||
Please keep in mind that:
|
||||
1. Step 3 can be skipped, because the Cert-Manager app should still exist on the upstream (local) cluster if it was installed before.
|
||||
2. At Step 4, install the Rancher version you intend to roll back to.
|
||||
|
||||
## Rolling Back to Rancher v2.5.0+
|
||||
|
||||
@@ -46,7 +71,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
|
||||
:::
|
||||
|
||||
### Create the Restore Custom Resource
|
||||
### Step 1: Create the Restore Custom Resource
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the local cluster and click **Explore**.
|
||||
@@ -95,7 +120,7 @@ kubectl get pods -n cattle-resources-system
|
||||
kubectl logs -n cattle-resources-system -f
|
||||
```
|
||||
|
||||
### Roll back to a previous Rancher version
|
||||
### Step 2: Roll Back to a Previous Rancher Version
|
||||
|
||||
Rancher can be rolled back using the Helm CLI. To roll back to the previous version:
|
||||
|
||||
|
||||
+2
-2
@@ -71,7 +71,7 @@ In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
@@ -250,7 +250,7 @@ The workstation must have Docker 18.02+ in order to support manifests, which are
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
|
||||
+2
-2
@@ -35,7 +35,7 @@ kubectl create namespace cert-manager
|
||||
Install the CustomResourceDefinitions of cert-manager:
|
||||
|
||||
```
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
```
|
||||
|
||||
And install it with Helm. Note that cert-manager also needs your proxy configured in case it needs to communicate with Let's Encrypt or other external certificate issuers:
|
||||
@@ -48,7 +48,7 @@ To see options on how to customize the cert-manager install (including for cases
|
||||
|
||||
```
|
||||
helm upgrade --install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager --version v1.11.0 \
|
||||
--namespace cert-manager \
|
||||
--set http_proxy=http://${proxy_host} \
|
||||
--set https_proxy=http://${proxy_host} \
|
||||
--set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
|
||||
|
||||
+4
-3
@@ -6,6 +6,8 @@ title: Upgrading Cert-Manager
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/upgrade-cert-manager"/>
|
||||
</head>
|
||||
|
||||
Rancher is compatible with the API version cert-manager.io/v1 and was last tested with cert-manager version v1.13.1.
|
||||
|
||||
Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, three important changes to cert-manager are set to occur that you need to take action on if you have an HA deployment of Rancher:
|
||||
|
||||
1. [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
|
||||
@@ -96,8 +98,7 @@ In order to upgrade cert-manager, follow these instructions:
|
||||
```plain
|
||||
helm install \
|
||||
cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--version v1.11.0
|
||||
--namespace cert-manager
|
||||
```
|
||||
|
||||
1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
|
||||
@@ -129,7 +130,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
|
||||
1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).
|
||||
|
||||
```plain
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
```
|
||||
|
||||
1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.
|
||||
|
||||
+3
-5
@@ -108,7 +108,7 @@ helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
|
||||
kubectl create namespace cattle-system
|
||||
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
|
||||
@@ -116,14 +116,12 @@ helm repo update
|
||||
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
|
||||
# Windows Powershell
|
||||
helm install cert-manager jetstack/cert-manager `
|
||||
--namespace cert-manager `
|
||||
--create-namespace `
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
The final command to install Rancher is below. The command requires a domain name that forwards traffic to the Linux machine. For the sake of simplicity in this tutorial, you can use a fake domain name to create your proof-of-concept. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`.
|
||||
|
||||
+4
-1
@@ -85,12 +85,13 @@ Any user that is bound to the above permission will be able to change the restri
|
||||
|
||||
## Exempting Required Rancher Namespaces
|
||||
|
||||
When you run Rancher on a Kubernetes cluster that enforces a restrictive security policy by default, you'll need to [exempt the following namespaces](#exempting-namespaces), otherwise the policy might prevent Rancher system pods from running properly.
|
||||
When you run Rancher on a Kubernetes cluster that enforces a restrictive security policy by default, you'll need to [exempt the following namespaces](#exempting-namespaces), otherwise the policy might prevent Rancher system pods from running properly.
|
||||
|
||||
- `calico-apiserver`
|
||||
- `calico-system`
|
||||
- `cattle-alerting`
|
||||
- `cattle-csp-adapter-system`
|
||||
- `cattle-elemental-system`
|
||||
- `cattle-epinio-system`
|
||||
- `cattle-externalip-system`
|
||||
- `cattle-fleet-local-system`
|
||||
@@ -106,6 +107,8 @@ When you run Rancher on a Kubernetes cluster that enforces a restrictive securit
|
||||
- `cattle-monitoring-system`
|
||||
- `cattle-neuvector-system`
|
||||
- `cattle-prometheus`
|
||||
- `cattle-provisioning-capi-system`
|
||||
- `cattle-resources-system`
|
||||
- `cattle-sriov-system`
|
||||
- `cattle-system`
|
||||
- `cattle-ui-plugin-system`
|
||||
|
||||
+13
-28
@@ -8,39 +8,24 @@ title: Restoring Rancher
|
||||
|
||||
This page outlines how to perform a restore with Rancher.
|
||||
|
||||
:::note Important:
|
||||
Follow the instructions from this page when:
|
||||
- The running Rancher instance is at the same version as when the backup was made.
|
||||
- The upstream (local) cluster is the same as where the backup was made.
|
||||
|
||||
* Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.](migrate-rancher-to-new-cluster.md)
|
||||
* While restoring rancher on the same setup, the operator will scale down the rancher deployment when restore starts, and it will scale back up the deployment once restore completes. So Rancher will be unavailable during the restore.
|
||||
* If you need to restore Rancher to a previous version after an upgrade, see the [rollback documentation.](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md)
|
||||
:::note Important
|
||||
|
||||
While restoring Rancher on the same setup, the operator will scale down the Rancher deployment when restore starts, and it will scale back up the deployment once restore completes. Rancher will be unavailable during the restore.
|
||||
|
||||
:::
|
||||
|
||||
## Additional Steps for Rollbacks with Rancher v2.6.4+
|
||||
:::tip
|
||||
|
||||
Rancher v2.6.4 upgrades the cluster-api module from v0.4.4 to v1.0.2. Version v1.0.2 of the cluster-api, in turn, upgrades the Cluster API's Custom Resource Definitions (CRDs) from `cluster.x-k8s.io/v1alpha4` to `cluster.x-k8s.io/v1beta1`. The CRDs upgrade to v1beta1 causes rollbacks to fail when you attempt to move from Rancher v2.6.4 to any previous version of Rancher v2.6.x. This is because CRDs that use the older apiVersion (v1alpha4) are incompatible with v1beta1.
|
||||
|
||||
To avoid rollback failure, the following Rancher scripts should be run **before** you attempt a restore operation or rollback:
|
||||
|
||||
* `verify.sh`: Checks for any Rancher-related resources in the cluster.
|
||||
* `cleanup.sh`: Cleans up the cluster.
|
||||
|
||||
See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup) for more details and source code.
|
||||
|
||||
:::caution
|
||||
|
||||
There will be downtime while `cleanup.sh` runs, since the script deletes resources created by Rancher.
|
||||
* Follow those steps to [migrate Rancher](migrate-rancher-to-new-cluster.md).
|
||||
* If you need to restore Rancher to a previous version after an upgrade, see the [rollback documentation](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md).
|
||||
|
||||
:::
|
||||
|
||||
### Rolling back from v2.6.4+ to lower versions of v2.6.x
|
||||
|
||||
1. Follow these [instructions](https://github.com/rancher/rancher-cleanup/blob/main/README.md) to run the scripts.
|
||||
1. Follow these [instructions](./migrate-rancher-to-new-cluster.md) to install the rancher-backup Helm chart on the existing cluster and restore the previous state.
|
||||
1. Omit Step 3.
|
||||
1. When you reach Step 4, install the Rancher v2.6.x version on the local cluster you intend to roll back to.
|
||||
|
||||
### Create the Restore Custom Resource
|
||||
## Create the Restore Custom Resource
|
||||
|
||||
A restore is performed by creating a Restore custom resource.
|
||||
|
||||
@@ -79,7 +64,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
2. Cluster-scoped resources
|
||||
3. Namespaced resources
|
||||
|
||||
### Logs
|
||||
## Logs
|
||||
|
||||
To check how the restore is progressing, you can check the logs of the operator. Run this command to follow the logs:
|
||||
|
||||
@@ -87,11 +72,11 @@ To check how the restore is progressing, you can check the logs of the operator.
|
||||
kubectl logs -n cattle-resources-system -l app.kubernetes.io/name=rancher-backup -f
|
||||
```
|
||||
|
||||
### Cleanup
|
||||
## Cleanup
|
||||
|
||||
If you created the restore resource with kubectl, remove the resource to prevent a naming conflict with future restores.
|
||||
|
||||
### Known Issues
|
||||
## Known Issues
|
||||
In some cases, after restoring the backup, Rancher logs will show errors similar to the following:
|
||||
```
|
||||
2021/10/05 21:30:45 [ERROR] error syncing 'c-89d82/m-4067aa68dd78': handler rke-worker-upgrader: clusters.management.cattle.io "c-89d82" not found, requeuing
|
||||
|
||||
+2
-3
@@ -149,7 +149,7 @@ To see options on how to customize the cert-manager install (including for cases
|
||||
|
||||
```
|
||||
# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
# Add the Jetstack Helm repository
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
@@ -160,8 +160,7 @@ helm repo update
|
||||
# Install the cert-manager Helm chart
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
|
||||
|
||||
@@ -23,6 +23,10 @@ See our page on [best practices](../reference-guides/best-practices/rancher-serv
|
||||
|
||||
Rancher needs to be installed on a supported Kubernetes version. Consult the [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions) to ensure that your intended version of Kubernetes is supported.
|
||||
|
||||
### Install Rancher on a Hardened Kubernetes cluster
|
||||
|
||||
If you install Rancher on a hardened Kubernetes cluster, check the [Exempting Required Rancher Namespaces](../../../docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#exempting-required-rancher-namespaces) section for detailed requirements.
|
||||
|
||||
## Operating Systems and Container Runtime Requirements
|
||||
|
||||
All supported operating systems are 64-bit x86. Rancher should work with any modern Linux distribution.
|
||||
|
||||
@@ -209,41 +209,44 @@ services:
|
||||
exemptions:
|
||||
usernames: []
|
||||
runtimeClasses: []
|
||||
namespaces: [ calico-apiserver,
|
||||
calico-system,
|
||||
cattle-alerting,
|
||||
cattle-csp-adapter-system,
|
||||
cattle-epinio-system,
|
||||
cattle-externalip-system,
|
||||
cattle-fleet-local-system,
|
||||
cattle-fleet-system,
|
||||
cattle-gatekeeper-system,
|
||||
cattle-global-data,
|
||||
cattle-global-nt,
|
||||
cattle-impersonation-system,
|
||||
cattle-istio,
|
||||
cattle-istio-system,
|
||||
cattle-logging,
|
||||
cattle-logging-system,
|
||||
cattle-monitoring-system,
|
||||
cattle-neuvector-system,
|
||||
cattle-prometheus,
|
||||
cattle-sriov-system,
|
||||
cattle-system,
|
||||
cattle-ui-plugin-system,
|
||||
cattle-windows-gmsa-system,
|
||||
cert-manager,
|
||||
cis-operator-system,
|
||||
fleet-default,
|
||||
ingress-nginx,
|
||||
istio-system,
|
||||
kube-node-lease,
|
||||
kube-public,
|
||||
kube-system,
|
||||
longhorn-system,
|
||||
rancher-alerting-drivers,
|
||||
security-scan,
|
||||
tigera-operator ]
|
||||
namespaces: [calico-apiserver,
|
||||
calico-system,
|
||||
cattle-alerting,
|
||||
cattle-csp-adapter-system,
|
||||
cattle-elemental-system,
|
||||
cattle-epinio-system,
|
||||
cattle-externalip-system,
|
||||
cattle-fleet-local-system,
|
||||
cattle-fleet-system,
|
||||
cattle-gatekeeper-system,
|
||||
cattle-global-data,
|
||||
cattle-global-nt,
|
||||
cattle-impersonation-system,
|
||||
cattle-istio,
|
||||
cattle-istio-system,
|
||||
cattle-logging,
|
||||
cattle-logging-system,
|
||||
cattle-monitoring-system,
|
||||
cattle-neuvector-system,
|
||||
cattle-prometheus,
|
||||
cattle-provisioning-capi-system,
|
||||
cattle-resources-system,
|
||||
cattle-sriov-system,
|
||||
cattle-system,
|
||||
cattle-ui-plugin-system,
|
||||
cattle-windows-gmsa-system,
|
||||
cert-manager,
|
||||
cis-operator-system,
|
||||
fleet-default,
|
||||
ingress-nginx,
|
||||
istio-system,
|
||||
kube-node-lease,
|
||||
kube-public,
|
||||
kube-system,
|
||||
longhorn-system,
|
||||
rancher-alerting-drivers,
|
||||
security-scan,
|
||||
tigera-operator]
|
||||
kube-controller:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
|
||||
+1
@@ -46,6 +46,7 @@ plugins:
|
||||
cattle-monitoring-system,
|
||||
cattle-neuvector-system,
|
||||
cattle-prometheus,
|
||||
cattle-provisioning-capi-system,
|
||||
cattle-resources-system,
|
||||
cattle-sriov-system,
|
||||
cattle-system,
|
||||
|
||||
+1
-1
@@ -20,7 +20,7 @@ The following is a list of feature flags available in Rancher. If you've upgrade
|
||||
|
||||
- `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
|
||||
- `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Fleet - GitOps at Scale](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) for more information.
|
||||
- `harvester`: Manages access to the Virtualization Management page, where users can navigate directly to Harvester clusters and access the Harvester UI. See [Harvester Integration](../../../integrations-in-rancher/harvester.md) for more information.
|
||||
- `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.
|
||||
- `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.
|
||||
|
||||
+1
-1
@@ -196,7 +196,7 @@ If security isn't a large concern and you're okay with opening a few additional
|
||||
|
||||
### Ports for Harvester Clusters
|
||||
|
||||
Refer [here](../../../integrations-in-rancher/harvester.md#port-requirements) for more information on Harvester port requirements.
|
||||
Refer to the [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md#port-requirements) for more information on Harvester port requirements.
|
||||
|
||||
|
||||
### Ports for Rancher Launched Kubernetes Clusters using Node Pools
|
||||
|
||||
+2
-2
@@ -71,7 +71,7 @@ In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
@@ -250,7 +250,7 @@ The workstation must have Docker 18.02+ in order to support manifests, which are
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
|
||||
+2
-2
@@ -35,7 +35,7 @@ kubectl create namespace cert-manager
|
||||
Install the CustomResourceDefinitions of cert-manager:
|
||||
|
||||
```
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
```
|
||||
|
||||
And install it with Helm. Note that cert-manager also needs your proxy configured in case it needs to communicate with Let's Encrypt or other external certificate issuers:
|
||||
@@ -48,7 +48,7 @@ To see options on how to customize the cert-manager install (including for cases
|
||||
|
||||
```
|
||||
helm upgrade --install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager --version v1.11.0 \
|
||||
--namespace cert-manager \
|
||||
--set http_proxy=http://${proxy_host} \
|
||||
--set https_proxy=http://${proxy_host} \
|
||||
--set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
|
||||
|
||||
+4
-3
@@ -6,6 +6,8 @@ title: Upgrading Cert-Manager
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/upgrade-cert-manager"/>
|
||||
</head>
|
||||
|
||||
Rancher is compatible with the API version cert-manager.io/v1 and was last tested with cert-manager version v1.13.1.
|
||||
|
||||
Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, three important changes to cert-manager are set to occur that you need to take action on if you have an HA deployment of Rancher:
|
||||
|
||||
1. [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
|
||||
@@ -96,8 +98,7 @@ In order to upgrade cert-manager, follow these instructions:
|
||||
```plain
|
||||
helm install \
|
||||
cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--version v1.11.0
|
||||
--namespace cert-manager
|
||||
```
|
||||
|
||||
1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
|
||||
@@ -129,7 +130,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
|
||||
1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).
|
||||
|
||||
```plain
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm fetch jetstack/cert-manager
|
||||
```
|
||||
|
||||
1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.
|
||||
|
||||
+3
-5
@@ -108,7 +108,7 @@ helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
|
||||
kubectl create namespace cattle-system
|
||||
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
|
||||
@@ -116,14 +116,12 @@ helm repo update
|
||||
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
|
||||
# Windows Powershell
|
||||
helm install cert-manager jetstack/cert-manager `
|
||||
--namespace cert-manager `
|
||||
--create-namespace `
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
The final command to install Rancher is below. The command requires a domain name that forwards traffic to the Linux machine. For the sake of simplicity in this tutorial, you can use a fake domain name to create your proof-of-concept. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`.
|
||||
|
||||
+4
-2
@@ -2,6 +2,8 @@
|
||||
title: Rancher Prime
|
||||
---
|
||||
|
||||
Rancher v2.7 introduces Rancher Prime, an evolution of the Rancher enterprise offering. Rancher Prime is a new edition of the commercial, enterprise offering built on the the same source code. Rancher’s product will therefore continue to be 100% open source with additional value coming in from 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.
|
||||
Prime is the Rancher ecosystem’s enterprise offering, with additional security, extended lifecycles, and access to Prime-exclusive documentation. Rancher Prime installation assets are hosted on a trusted SUSE registry, owned and managed by Rancher. The trusted Prime registry includes only stable releases that have been community-tested.
|
||||
|
||||
To get started with Rancher Prime, [go to this page](https://www.rancher.com/quick-start) and fill out the form.
|
||||
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).
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: Virtualization on Kubernetes with Harvester
|
||||
---
|
||||
|
||||
## Harvester
|
||||
|
||||
Introduced in Rancher v2.6.1, Harvester is an open-source hyper-converged infrastructure (HCI) software built on Kubernetes. Harvester installs on bare metal servers and provides integrated virtualization and distributed storage capabilities. Although Harvester operates using Kubernetes, it does not require users to know Kubernetes concepts, making it a more user-friendly application.
|
||||
|
||||
## Harvester with Rancher
|
||||
|
||||
With Rancher Prime and Harvester, IT operators now have access to an enterprise-ready, simple-to-use infrastructure platform that cohesively manages their virtual machines and Kubernetes clusters alongside one another. For more information on the support offering, see the [Support Matrix](https://www.suse.com/suse-harvester/support-matrix/all-supported-versions/harvester-v1-2-0/). With the Rancher Virtualization Management feature, users can import and manage multiple Harvester clusters. Leveraging the Rancher's authentication feature and RBAC control for multi-tenancy support.
|
||||
+1
-11
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Harvester Integration
|
||||
title: Overview
|
||||
---
|
||||
|
||||
Introduced in Rancher v2.6.1, [Harvester](https://docs.harvesterhci.io/) is an open-source hyper-converged infrastructure (HCI) software built on Kubernetes. Harvester installs on bare metal servers and provides integrated virtualization and distributed storage capabilities. Although Harvester operates using Kubernetes, it does not require users to know Kubernetes concepts, making it a more user-friendly application.
|
||||
@@ -36,13 +36,3 @@ In addition, other networking considerations are as follows:
|
||||
- Follow the networking setup guidance [here](https://docs.harvesterhci.io/v1.1/networking/clusternetwork).
|
||||
|
||||
For other port requirements for other guest clusters, such as K3s and RKE1, please see [these docs](https://docs.harvesterhci.io/v1.1/install/requirements/#guest-clusters).
|
||||
|
||||
### Limitations
|
||||
|
||||
---
|
||||
**Applicable to Rancher v2.6.1 and v2.6.2 only:**
|
||||
|
||||
- Harvester v0.3.0 doesn’t support air-gapped environment installation.
|
||||
- Harvester v0.3.0 doesn’t support upgrade from v0.2.0 nor upgrade to v1.0.0.
|
||||
|
||||
---
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: Integrations in Rancher
|
||||
---
|
||||
import {Card, CardSection} from '@site/src/components/CardComponents';
|
||||
import {
|
||||
ReadingModeMobileRegular,
|
||||
QuestionRegular,
|
||||
ArrowUpRegular,
|
||||
PlayRegular,
|
||||
FlowchartRegular,
|
||||
RocketRegular
|
||||
} from '@fluentui/react-icons';
|
||||
import { FaAws, FaGoogle, FaCloud, FaServer, faGear } from "react-icons/fa6";
|
||||
import HarvesterIcon from '@site/static/img/harvester_logo_horizontal.svg';
|
||||
|
||||
Prime is the Rancher ecosystem’s enterprise offering, with additional security, extended lifecycles, and access to Prime-exclusive documentation. Rancher Prime installation assets are hosted on a trusted SUSE registry, owned and managed by Rancher. The trusted Prime registry includes only stable releases that have been community-tested.
|
||||
|
||||
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).
|
||||
|
||||
<CardSection
|
||||
id="Gettingstarted"
|
||||
icon={<RocketRegular />}
|
||||
>
|
||||
<Card
|
||||
title="Virtualization on Kubernetes with Harvester"
|
||||
to="/integrations-in-rancher/harvester"
|
||||
/>
|
||||
<Card
|
||||
title="Cloud Native Storage with Longhorn"
|
||||
to="/integrations-in-rancher/longhorn"
|
||||
/>
|
||||
<Card
|
||||
title="Container Security with NeuVector"
|
||||
to="/integrations-in-rancher/neuvector"
|
||||
/>
|
||||
<Card
|
||||
title="Advanced Policy Management with Kubewarden"
|
||||
to="/integrations-in-rancher/kubewarden"
|
||||
/>
|
||||
<Card
|
||||
title="Operating System Management with Elemental"
|
||||
to="/integrations-in-rancher/elemental"
|
||||
/>
|
||||
<Card
|
||||
title="Observability with Opni"
|
||||
to="/integrations-in-rancher/opni"
|
||||
/>
|
||||
<Card
|
||||
title="Continuous Delivery with Fleet"
|
||||
to="/integrations-in-rancher/fleet"
|
||||
/>
|
||||
<Card
|
||||
title="Kubernetes on the Desktop"
|
||||
to="/integrations-in-rancher/rancher-desktop"
|
||||
/>
|
||||
<Card
|
||||
title="Application Development Engine with Epinio"
|
||||
to="/integrations-in-rancher/epinio"
|
||||
/>
|
||||
</CardSection>
|
||||
@@ -48,4 +48,4 @@ Rancher supports several major cloud providers, but by default, these node drive
|
||||
|
||||
There are several other node drivers that are disabled by default, but are packaged in Rancher:
|
||||
|
||||
* [Harvester](../integrations-in-rancher/harvester.md#harvester-node-driver/), available in Rancher v2.6.1
|
||||
* [Harvester](../integrations-in-rancher/harvester/overview.md#harvester-node-driver/), available as of Rancher v2.6.1
|
||||
|
||||
+2
-3
@@ -149,7 +149,7 @@ To see options on how to customize the cert-manager install (including for cases
|
||||
|
||||
```
|
||||
# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
# Add the Jetstack Helm repository
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
@@ -160,8 +160,7 @@ helm repo update
|
||||
# Install the cert-manager Helm chart
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--version v1.11.0
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
|
||||
|
||||
-100
@@ -1,100 +0,0 @@
|
||||
---
|
||||
title: Tuning and Best Practices for Rancher at Scale
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale"/>
|
||||
</head>
|
||||
|
||||
|
||||
This guide describes the best practices and tuning approaches to scale Rancher setups and the associated challenges with doing so. As systems grow, performance will naturally reduce, but there are steps that can minimize the load put on Rancher and optimize Rancher's ability to manage larger infrastructures.
|
||||
|
||||
## Optimizing Rancher Performance
|
||||
|
||||
* Keep Rancher up to date with patch releases. We are continuously improving Rancher with performance enhancements and bug fixes. The latest Rancher release contains all accumulated improvements to performance and stability, plus updates based on developer experience and user feedback.
|
||||
|
||||
* Always scale up gradually, and monitor and observe any changes in behavior while doing do. It is usually easier to resolve performance problems as soon as they surface, before other problems obscure the root cause.
|
||||
|
||||
* Reduce network latency between the upstream Rancher cluster and downstream clusters to the extent possible. Note that latency is, among other factors, a function of geographic distance - if you require clusters or nodes spread across the world, consider multiple Rancher installations.
|
||||
|
||||
## Minimizing Load on the Upstream Cluster
|
||||
|
||||
When scaling up Rancher, one typical bottleneck is resource growth in the upstream (local) Kubernetes cluster. The upstream cluster contains information for all downstream clusters. Many operations that apply to downstream clusters create new objects in the upstream cluster and require computation from handlers running in the upstream cluster.
|
||||
|
||||
### Managing Your Object Counts
|
||||
|
||||
Etcd is the backing database for Kubernetes and for Rancher. The database may eventually encounter limitations to the number of a single Kubernetes resource type it can store. Exact limits vary and depend on a number of factors. However, experience indicates that performance issues frequently arise once a single resource type's object count exceeds 60,000. Often that type is `RoleBinding`.
|
||||
|
||||
This is typical in Rancher, as many operations create new `RoleBinding` objects in the upstream cluster as a side effect.
|
||||
|
||||
You can reduce the number of `RoleBindings` in the upstream cluster in the following ways:
|
||||
* Limit the use of the [Restricted Admin](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions#restricted-admin) role. Apply other roles wherever possible.
|
||||
* If you use [external authentication](../../../pages-for-subheaders/authentication-config), use groups to assign roles.
|
||||
* Only add users to clusters and projects when necessary.
|
||||
* Remove clusters and projects when they are no longer needed.
|
||||
* Only use custom roles if necessary.
|
||||
* Use as few rules as possible in custom roles.
|
||||
* Consider whether adding a role to a user is redundant.
|
||||
* Consider using less, but more powerful, clusters.
|
||||
* Kubernetes permissions are always "additive" (allow-list) rather than "subtractive" (deny-list). Try to minimize configurations that gives access to all but one aspect of a cluster, project, or namespace, as that will result in the creation of a high number of `RoleBinding` objects.
|
||||
* Experiment to see if creating new projects or clusters manifests in fewer `RoleBindings` for your specific use case.
|
||||
|
||||
### RoleBinding Count Estimation
|
||||
|
||||
Predicting how many `RoleBinding` objects a given configuration will create is complicated. However, the following considerations can offer a rough estimate:
|
||||
* For a minimum estimate, use the formula `32C + U + 2UaC + 8P + 5Pa`.
|
||||
* `C` is the total number of clusters.
|
||||
* `U` is the total number of users.
|
||||
* `Ua` is the average number of users with a membership on a cluster.
|
||||
* `P` is the total number of projects.
|
||||
* `Pa` is the average number of users with a membership on a project.
|
||||
* The Restricted Admin role follows a different formula, as every user with this role results in at least `7C + 2P + 2` additional `RoleBinding` objects.
|
||||
* The number of `RoleBindings` increases linearly with the number of clusters, projects, and users.
|
||||
|
||||
### Using New Apps Over Legacy Apps
|
||||
|
||||
Rancher uses two Kubernetes app resources: `apps.projects.cattle.io` and `apps.cattle.cattle.io`. Legacy apps, represented by `apps.projects.cattle.io`, were introduced with the former Cluster Manager UI and are now outdated. Current apps, represented by `apps.catalog.cattle.io`, are found in the Cluster Explorer UI for their respective cluster. `Apps.cattle.cattle.io` apps are preferable because their data resides in downstream clusters, which frees up resources in the upstream cluster.
|
||||
|
||||
You should remove any remaining legacy apps that appear in the Cluster Manager UI, and replace them with apps in the Cluster Explorer UI. Create any new apps only in the Cluster Explorer UI.
|
||||
|
||||
### Using the Authorized Cluster Endpoint (ACE)
|
||||
|
||||
An [Authorized Cluster Endpoint](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters#4-authorized-cluster-endpoint) (ACE) provides access to the Kubernetes API of Rancher-provisioned RKE, RKE2, and K3s clusters. When enabled, the ACE adds a context to kubeconfig files generated for the cluster. The context uses a direct endpoint to the cluster, thereby bypassing Rancher. This reduces load on Rancher for cases where unmediated API access is acceptable or preferable. See [Authorized Cluster Endpoint](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters#4-authorized-cluster-endpoint) for more information and configuration instructions.
|
||||
|
||||
### Reducing Event Handler Executions
|
||||
|
||||
The bulk of Rancher's logic occurs on event handlers. These event handlers run on an object whenever the object is updated, and when Rancher is started. Additionally, they run every 15 hours when Rancher syncs caches. In scaled setups these scheduled runs come with huge performance costs because every handler is being run on every applicable object. However, the scheduled handler execution can be disabled with the `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` environment variable. If resource allocation spikes are seen every 15 hours, this setting can help.
|
||||
|
||||
The value for `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` can be a comma separated list of the following options. The values refer to types of handlers and controllers (the structures that contain and run handlers). Adding the controller types to the variable disables that set of controllers from running their handlers as part of cache resyncing.
|
||||
|
||||
* `mgmt` refers to management controllers which only run on one Rancher node.
|
||||
* `user` refers to user controllers which run for every cluster. Some of these run on the same node as management controllers, while others run in the downstream cluster. This option targets the former.
|
||||
* `scaled` refers to scaled controllers which run on every Rancher node. You should avoid setting this value, as the scaled handlers are responsible for critical functions and changes may disrupt cluster stability.
|
||||
|
||||
In short, if you notice CPU usage peaks every 15 hours, add the `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` environment variable to your Rancher deployment (in the `spec.containers.env` list) with the value `mgmt,user`
|
||||
|
||||
## Optimizations Outside of Rancher
|
||||
|
||||
Important influencing factors are the underlying cluster's own performance and configuration. The upstream cluster, if misconfigured, can introduce a bottleneck Rancher software has no chance to resolve.
|
||||
|
||||
### Manage Upstream Cluster Nodes Directly with RKE2
|
||||
|
||||
As Rancher can be very demanding on the upstream cluster, especially at scale, you should have full administrative control of the cluster's configuration and nodes. To identify the root cause of excess resource consumption, use standard Linux troubleshooting techniques and tools. This can aid in distinguishing between whether Rancher, Kubernetes, or operating system components are causing issues.
|
||||
|
||||
Although managed Kubernetes services make it easier to deploy and run Kubernetes clusters, they are discouraged for the upstream cluster in high scale scenarios. Managed Kubernetes services typically limit access to configuration and insights on individual nodes and services.
|
||||
|
||||
Use RKE2 for large scale use cases.
|
||||
|
||||
### Keeping Kubernetes Versions Up to Date
|
||||
|
||||
You should keep the local Kubernetes cluster up to date. This will ensure that your cluster has all available performance enhancements and bug fixes.
|
||||
|
||||
### Optimizing etcd
|
||||
|
||||
Etcd is the backend database for Kubernetes and for Rancher. It plays a very important role in Rancher performance.
|
||||
|
||||
The two main bottlenecks to [etcd performance](https://etcd.io/docs/v3.4/op-guide/performance/) are disk and network speed. Etcd should run on dedicated nodes with a fast network setup and with SSDs that have high input/output operations per second (IOPS). For more information regarding etcd performance, see [Slow etcd performance (performance testing and optimization)](https://www.suse.com/support/kb/doc/?id=000020100) and [Tuning etcd for Large Installations](../../../how-to-guides/advanced-user-guides/tune-etcd-for-large-installs). Information on disks can also be found in the [Installation Requirements](../../../pages-for-subheaders/installation-requirements#disks).
|
||||
|
||||
It's best to run etcd on exactly three nodes, as adding more nodes will reduce operation speed. This may be counter-intuitive to common scaling approaches, but it's due to etcd's [replication mechanisms](https://etcd.io/docs/v3.5/faq/#what-is-maximum-cluster-size).
|
||||
|
||||
Etcd performance will also be negatively affected by network latency between nodes as that will slow down network communication. Etcd nodes should be located together with Rancher nodes.
|
||||
@@ -37,7 +37,7 @@
|
||||
"getting-started/quick-start-guides/deploy-rancher-manager/prime",
|
||||
{
|
||||
"type": "category",
|
||||
"label": "Deploy Rancher Workloads",
|
||||
"label": "Deploy Workloads",
|
||||
"link": {
|
||||
"type": "doc",
|
||||
"id": "pages-for-subheaders/deploy-rancher-workloads"
|
||||
|
||||
@@ -1085,7 +1085,21 @@
|
||||
{
|
||||
"type": "category",
|
||||
"label": "Integrations in Rancher",
|
||||
"link": {
|
||||
"type": "doc",
|
||||
"id": "integrations-in-rancher/integrations-in-rancher"
|
||||
},
|
||||
"items": [
|
||||
{
|
||||
"label": "Virtualization on Kubernetes with Harvester",
|
||||
"link": {
|
||||
"type": "doc",
|
||||
"id": "integrations-in-rancher/harvester/harvester"
|
||||
},
|
||||
"items": [
|
||||
"integrations-in-rancher/harvester/overview"
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "category",
|
||||
"label": "Cloud Native Storage with Longhorn",
|
||||
@@ -1095,7 +1109,6 @@
|
||||
},
|
||||
"items": [
|
||||
"integrations-in-rancher/longhorn/overview"
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "category",
|
||||
@@ -1149,7 +1162,6 @@
|
||||
"integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy"
|
||||
]
|
||||
},
|
||||
"integrations-in-rancher/harvester",
|
||||
{
|
||||
"type": "category",
|
||||
"label": "Istio",
|
||||
|
||||
Reference in New Issue
Block a user