public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-05-19 11:25:15 +00:00
Code Issues Packages Projects Releases Wiki Activity

Delete RancherD docs

Browse Source
This commit is contained in:
Catherine Luse
2021-06-29 15:15:59 -07:00
parent c86b2d31b0
commit 7886f8a680
4 changed files with 0 additions and 642 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/rancher/v2.6/en/installation/other-installation-methods/install-rancher-on-linux/_index.md
-240
View File
@@ -1,240 +0,0 @@
---
title: Install/Upgrade Rancher with RancherD
weight: 3
aliases:
- /rancher/v2.6/en/installation/install-rancher-on-linux
---
> This is an experimental feature.
We are excited to introduce a new, simpler way to install Rancher called RancherD.
RancherD is a single binary that first launches an RKE2 Kubernetes cluster, then installs the Rancher server Helm chart on the cluster.
- [About RancherD Installs](#about-rancherd-installs)
- [Prerequisites](#prerequisites)
- [Part I: Installing Rancher](#part-i-installing-rancher)
- [Part II: High Availability](#part-ii-high-availability)
- [Upgrades](#upgrades)
- [Configuration](#configuration)
- [Uninstall](#uninstall)
- [RKE2 Documentation](#rke2-documentation)
# About RancherD Installs
When RancherD is launched on a host, it first installs an RKE2 Kubernetes cluster, then deploys Rancher on the cluster as a Kubernetes daemonset.
In both the RancherD install and the Helm CLI install, Rancher is installed as a Helm chart on a Kubernetes cluster.
Configuration and upgrading are also simplified with RancherD. When you upgrade the RancherD binary, both the Kubernetes cluster and the Rancher Helm chart are upgraded.
In Part I of these instructions, you'll learn how to launch RancherD on a single node. The result of following the steps in Part I is a single-node [RKE2](https://docs.rke2.io/) Kubernetes cluster with the Rancher server installed. This cluster can easily become high availability later. If Rancher only needs to manage the local Kubernetes cluster, the installation is complete.
Part II explains how to convert the single-node Rancher installation into a high-availability installation. If the Rancher server will manage downstream Kubernetes clusters, it is important to follow these steps. A discussion of recommended architecture for highly available Rancher deployments can be found in our [Best Practices Guide.]({{<baseurl>}}/rancher/v2.6/en/best-practices/v2.5/rancher-server)
# Prerequisites
### Node Requirements
RancherD must be launched on a Linux OS. At this time, only OSes that leverage systemd are supported.
The Linux node needs to fulfill the [installation requirements]({{<baseurl>}}/rancher/v2.6/en/installation/requirements) for hardware and networking. Docker is not required for RancherD installs.
To install RancherD on SELinux Enforcing CentOS 8 nodes or RHEL 8 nodes, some [additional steps]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/#rancherd-on-selinux-enforcing-centos-8-or-rhel-8-nodes) are required.
### Root Access
Before running the installation commands, you will need to log in as root:
```
sudo -s
```
### Fixed Registration Address
A fixed registration address is recommended for single-node installs and required for high-availability installs with RancherD.
The fixed registration address is an endpoint that is used for two purposes:
- To access the Kubernetes API. So you can, for example, modify your [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file to point to it instead of a specific node.
- To add new nodes to the Kubernetes cluster. To add nodes to the cluster later, you will run a command on the node that will specify the fixed registration address of the cluster.
If you are installing Rancher on a single node, the fixed registration address makes it possible to add more nodes to the cluster so that you can convert the single-node install to a high-availability install without causing downtime to the cluster. If you don't set up this address when installing the single-node Kubernetes cluster, you would need to re-run the installation script with a fixed registration address in order to add new nodes to the cluster.
The fixed registration can be the IP or hostname of any of the server nodes, but in many cases those may change over time as nodes are created and destroyed. Therefore, you should have a stable endpoint in front of the server nodes.
This endpoint can be set up using any number of approaches, such as:
* A layer 4 (TCP) load balancer
* Round-robin DNS
* Virtual or elastic IP addresses
The following should be taken into consideration when configuring the load balancer or other endpoint:
- The RancherD server process listens on port 9345 for new nodes to register.
- The Kubernetes API is served on port 6443, as normal.
- In RancherD installs, the Rancher UI is served on port 8443 by default. (This is different from Helm chart installs, where port 443 is used by default.)
# Part I: Installing Rancher
### 1. Set up Configurations
To avoid certificate errors with the fixed registration address, you should launch the server with the `tls-san` parameter set. This parameter should refer to your fixed registration address.
This option adds an additional hostname or IP as a Subject Alternative Name in the server's TLS cert, and it can be specified as a list if you would like to access the Kubernetes cluster via both the IP and the hostname.
Create the RancherD config file at `/etc/rancher/rke2/config.yaml`:
```yaml
token: my-shared-secret
tls-san:
- my-fixed-registration-address.com
- another-kubernetes-domain.com
```
The first server node establishes the secret token that other nodes would register with if they are added to the cluster.
If you do not specify a pre-shared secret, RancherD will generate one and place it at `/var/lib/rancher/rke2/server/node-token`.
To specify your own pre-shared secret as the token, set the `token` argument on startup.
Installing Rancher this way will use Rancher-generated certificates. To use your own self-signed or trusted certificates, refer to the [configuration guide.]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-linux/rancherd-configuration/#certificates-for-the-rancher-server)
For information on customizing the RancherD Helm chart values.yaml, refer to [this section.]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-linux/rancherd-configuration/#customizing-the-rancherd-helm-chart)
### 2. Launch the first server node
Run the RancherD installer:
```
curl -sfL https://get.rancher.io | sh -
```
The RancherD version can be specified using the `INSTALL_RANCHERD_VERSION` environment variable:
```
curl -sfL https://get.rancher.io | INSTALL_RANCHERD_VERSION=v2.5.4-rc6 sh -
```
Once installed, the `rancherd` binary will be on your PATH. You can check out its help text like this:
```
rancherd --help
NAME:
rancherd - Rancher Kubernetes Engine 2
...
```
Next, launch RancherD:
```
systemctl enable rancherd-server.service
systemctl start rancherd-server.service
```
When RancherD launches, it installs an RKE2 Kubernetes cluster. Use the following command to see the logs of the Kubernetes cluster as it comes up:
```
journalctl -eu rancherd-server -f
```
### 3. Set up the kubeconfig file with kubectl
Once the Kubernetes cluster is up, set up RancherD’s kubeconfig file and `kubectl`:
```
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml PATH=$PATH:/var/lib/rancher/rke2/bin
```
### 4. Verify that Rancher is installed on the Kubernetes cluster
Now, you can start issuing `kubectl` commands. Use the following commands to verify that Rancher is deployed as a daemonset on the cluster:
```
kubectl get daemonset rancher -n cattle-system
kubectl get pod -n cattle-system
```
If you watch the pods, you will see the following pods installed:
- `helm-operation` pods in the `cattle-system` namespace
- a `rancher` pod and `rancher-webhook` pod in the `cattle-system` namespace
- a `fleet-agent`, `fleet-controller`, and `gitjob` pod in the `fleet-system` namespace
- a `rancher-operator` pod in the `rancher-operator-system` namespace
### 5. Set the initial Rancher password
Once the `rancher` pod is up and running, run the following:
```
rancherd reset-admin
```
This will give you the URL, username and password needed to log into Rancher. Follow that URL, plug in the credentials, and you’re up and running with Rancher!
If Rancher will only manage the local Kubernetes cluster, the installation is complete.
# Part II: High Availability
If you plan to use the Rancher server to manage downstream Kubernetes clusters, Rancher needs to be highly available. In these steps, you will add more nodes to achieve a high-availability cluster. Since Rancher is running as a daemonset, it will automatically launch on the nodes you add.
An odd number of nodes is required because the etcd cluster, which contains the cluster data, needs a majority of live nodes to avoid losing quorum. A loss of quorum could require the cluster to be restored from backup. Therefore, we recommend using three nodes.
When following these steps, you should still be logged in as root.
### 1. Configure the fixed registration address on a new node
Additional server nodes are launched much like the first, except that you must specify the `server` and `token` parameters so that they can successfully connect to the initial server node.
Here is an example of what the RancherD config file would look like for additional server nodes. By default, this config file is expected to be located at `/etc/rancher/rke2/config.yaml`.
```yaml
server: https://my-fixed-registration-address.com:9345
token: my-shared-secret
tls-san:
- my-fixed-registration-address.com
- another-kubernetes-domain.com
```
### 2. Launch an additional server node
Run the installer on the new node:
```
curl -sfL https://get.rancher.io | sh -
```
This will download RancherD and install it as a systemd unit on your host.
Next, launch RancherD:
```
systemctl enable rancherd-server.service
systemctl start rancherd-server.service
```
### 3. Repeat
Repeat steps one and two for another Linux node, bringing the number of nodes in the cluster to three.
**Result:** Rancher is highly available and the installation is complete.
# Upgrades
For information on upgrades and rollbacks, refer to [this page.](./upgrades)
# Configuration
For information on how to configure certificates, node taints, Rancher Helm chart options, or RancherD CLI options, refer to the [configuration reference.](./rancherd-configuration)
# Uninstall
To uninstall RancherD from your system, run the command below. This will shut down the process, remove the RancherD binary, and clean up files used by RancherD.
```
rancherd-uninstall.sh
```
# RKE2 Documentation
For more information on RKE2, the Kubernetes distribution used to provision the underlying cluster, refer to the documentation [here.](https://docs.rke2.io/)
content/rancher/v2.6/en/installation/other-installation-methods/install-rancher-on-linux/rancherd-configuration/_index.md
-320
View File
@@ -1,320 +0,0 @@
---
title: RancherD Configuration Reference
weight: 1
aliases:
- /rancher/v2.6/en/installation/install-rancher-on-linux/rancherd-configuration
---
> RancherD is an experimental feature.
In RancherD, a server node is defined as a machine (bare-metal or virtual) running the `rancherd server` command. The server runs the Kubernetes API as well as Kubernetes workloads.
An agent node is defined as a machine running the `rancherd agent` command. They don't run the Kubernetes API. To add nodes designated to run your apps and services, join agent nodes to your cluster.
In the RancherD installation instructions, we recommend running three server nodes in the Rancher server cluster. Agent nodes are not required.
- [Certificates for the Rancher Server](#certificates-for-the-rancher-server)
- [Node Taints](#node-taints)
- [Customizing the RancherD Helm Chart](#customizing-the-rancherd-helm-chart)
- [RancherD Server CLI Options](#rancherd-server-cli-options)
- [RancherD Agent CLI Options](#rancherd-agent-cli-options)
# Certificates for the Rancher Server
Rancherd does not use cert-manger to provision certs. Instead RancherD allows you to bring your own self-signed or trusted certs by storing the .pem files in `/etc/rancher/ssl/`. When doing this you should also set the `publicCA` parameter to `true` in your HelmChartConfig. For more information on the HelmChartConfig, refer to the section about [customizing the RancherD Helm chart.](#customizing-the-rancherd-helm-chart)
Private key: `/etc/rancher/ssl/key.pem`
Certificate: `/etc/rancher/ssl/cert.pem`
CA Certificate(self-signed): `/etc/rancher/ssl/cacerts.pem`
Additional CA Certificate: `/etc/ssl/certs/ca-additional.pem`
# Node Taints
By default, server nodes will be schedulable and thus your workloads can get launched on them. If you wish to have a dedicated control plane where no user workloads will run, you can use taints. The node-taint parameter will allow you to configure nodes with taints. Here is an example of adding a node taint to the `config.yaml`:
```
node-taint:
- "CriticalAddonsOnly=true:NoExecute"
```
# Customizing the RancherD Helm Chart
Rancher is launched as a [Helm](https://helm.sh/) chart using the cluster’s [Helm integration.](https://docs.rke2.io/helm/) This means that you can easily customize the application through a manifest file describing your custom parameters.
The RancherD chart provisions Rancher in a daemonset. It exposes hostport `8080/8443` down to the container port (`80/443`), and uses hostpath to mount certs if needed.
RancherD uses `helm-controller` to bootstrap the RancherD chart. To provide a customized `values.yaml` file, the configuration options must be passed in through the `helm-controller` custom resource definition.
Here is an example of the manifest:
```yaml
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
name: rancher
namespace: kube-system
spec:
valuesContent: |
publicCA: true
```
Put this manifest on your host in `/var/lib/rancher/rke2/server/manifests` before running RancherD.
### Common Options
| Parameter | Default Value | Description |
| ------------------------------ | ----------------------------------------------------- | -------------------------------------------- |
| `addLocal` | "auto" | ***string*** - Have Rancher detect and import the local Rancher server cluster |
| `auditLog.destination` | "sidecar" | ***string*** - Stream to sidecar container console or hostPath volume - *"sidecar, hostPath"* |
| `auditLog.hostPath` | "/var/log/rancher/audit" | ***string*** - log file destination on host (only applies when **auditLog.destination** is set to **hostPath**) |
| `auditLog.level` | 0 | ***int*** - set the [API Audit Log level](https://rancher.com/docs/rancher/v2.6/en/installation/api-auditing). 0 is off. [0-3] |
| `auditLog.maxAge` | 1 | ***int*** - maximum number of days to retain old audit log files (only applies when **auditLog.destination** is set to **hostPath**) |
| `auditLog.maxBackups` | 1 | int - maximum number of audit log files to retain (only applies when **auditLog.destination** is set to **hostPath**) |
| `auditLog.maxSize` | 100 | ***int*** - maximum size in megabytes of the audit log file before it gets rotated (only applies when **auditLog.destination** is set to **hostPath**) |
| `debug` | false | ***bool*** - set debug flag on rancher server |
| `extraEnv` | [] | ***list*** - set additional environment variables for Rancher |
| `imagePullSecrets` | [] | ***list*** - list of names of Secret resource containing private registry credentials |
| `proxy` | " " | ***string** - HTTP[S] proxy server for Rancher |
| `noProxy` | "127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16" | ***string*** - comma separated list of hostnames or ip address not to use the proxy |
| `resources` | {} | ***map*** - rancher pod resource requests & limits |
| `rancherImage` | "rancher/rancher" | ***string*** - rancher image source |
| `rancherImageTag` | same as chart version | ***string*** - rancher/rancher image tag |
| `rancherImagePullPolicy` | "IfNotPresent" | ***string*** - Override imagePullPolicy for rancher server images - *"Always", "Never", "IfNotPresent"* |
| `systemDefaultRegistry` | "" | ***string*** - private registry to be used for all system Docker images, e.g., [http://registry.example.com/] |
| `useBundledSystemChart` | false | ***bool*** - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations. |
| `publicCA` | false | ***bool*** - Set to true if your cert is signed by a public CA |
# RancherD Server CLI Options
The command to run the Rancher management server is:
```
rancherd server [OPTIONS]
```
It can be run with the following options:
### Config
| Option | Description |
|--------|-------------|
| `--config FILE, -c FILE` | Load configuration from FILE (default: "/etc/rancher/rke2/config.yaml") |
### Logging
| Option | Description |
|--------|-------------|
| `--debug` | Turn on debug logs |
### Listener
| Option | Description |
|--------|-------------|
| `--bind-address value` | RancherD bind address (default: 0.0.0.0) |
| `--advertise-address value` | IP address that apiserver uses to advertise to members of the cluster (default: node-external-ip/node-ip) |
| `--tls-san value` | Add additional hostname or IP as a Subject Alternative Name in the TLS cert |
### Data
| Option | Description |
|--------|-------------|
| `--data-dir value, -d value` | Folder to hold state (default: "/var/lib/rancher/rancherd") |
### Networking
| Option | Description |
|--------|-------------|
| `--cluster-cidr value` | Network CIDR to use for pod IPs (default: "10.42.0.0/16") |
| `--service-cidr value` | Network CIDR to use for services IPs (default: "10.43.0.0/16") |
| `--cluster-dns value` | Cluster IP for coredns service. Should be in your service-cidr range (default: 10.43.0.10) |
| `--cluster-domain value` | Cluster Domain (default: "cluster.local") |
### Cluster
| Option | Description |
|--------|-------------|
| `--token value, -t value` | Shared secret used to join a server or agent to a cluster |
| `--token-file value` | File containing the cluster-secret/token |
### Client
| Option | Description |
|--------|-------------|
| `--write-kubeconfig value, -o value` | Write kubeconfig for admin client to this file |
| `--write-kubeconfig-mode value` | Write kubeconfig with this mode |
### Flags
| Option | Description |
|--------|-------------|
| `--kube-apiserver-arg value` | Customized flag for kube-apiserver process |
| `--kube-scheduler-arg value` | Customized flag for kube-scheduler process |
| `--kube-controller-manager-arg value` | Customized flag for kube-controller-manager process |
### Database
| Option | Description |
|--------|-------------|
| `--etcd-disable-snapshots` | Disable automatic etcd snapshots |
| `--etcd-snapshot-schedule-cron value` | Snapshot interval time in cron spec. eg. every 5 hours '* */5 * * *' (default: "0 */12 * * *") |
| `--etcd-snapshot-retention value` | Number of snapshots to retain (default: 5) |
| `--etcd-snapshot-dir value` | Directory to save db snapshots. (Default location: ${data-dir}/db/snapshots) |
| `--cluster-reset-restore-path value` | Path to snapshot file to be restored |
### System Images Registry
| Option | Description |
|--------|-------------|
| `--system-default-registry value` | Private registry to be used for all system Docker images |
### Components
| Option | Description |
|--------|-------------|
| `--disable value` | Do not deploy packaged components and delete any deployed components (valid items: rancherd-canal, rancherd-coredns, rancherd-ingress, rancherd-kube-proxy, rancherd-metrics-server) |
### Cloud Provider
| Option | Description |
|--------|-------------|
| `--cloud-provider-name value` | Cloud provider name |
| `--cloud-provider-config value` | Cloud provider configuration file path |
### Security
| Option | Description |
|--------|-------------|
| `--profile value` | Validate system configuration against the selected benchmark (valid items: cis-1.5) |
### Agent Node
| Option | Description |
|--------|-------------|
| `--node-name value` | Node name |
| `--node-label value` | Registering and starting kubelet with set of labels |
| `--node-taint value` | Registering kubelet with set of taints |
| `--protect-kernel-defaults` | Kernel tuning behavior. If set, error if kernel tunables are different than kubelet defaults. |
| `--selinux` | Enable SELinux in containerd |
### Agent Runtime
| Option | Description |
|--------|-------------|
| `--container-runtime-endpoint value` | Disable embedded containerd and use alternative CRI implementation |
| `--snapshotter value` | Override default containerd snapshotter (default: "overlayfs") |
| `--private-registry value` | Private registry configuration file (default: "/etc/rancher/rke2/registries.yaml") |
### Agent Networking
| Option | Description |
|--------|-------------|
| `--node-ip value, -i value` | IP address to advertise for node |
| `--resolv-conf value` | Kubelet resolv.conf file |
### Agent Flags
| Option | Description |
|--------|-------------|
| `--kubelet-arg value` | Customized flag for kubelet process |
| `--kube-proxy-arg value` | Customized flag for kube-proxy process |
### Experimental
| Option | Description |
|--------|-------------|
| `--agent-token value` | Shared secret used to join agents to the cluster, but not servers |
| `--agent-token-file value` | File containing the agent secret |
| `--server value, -s value` | Server to connect to, used to join a cluster |
| `--cluster-reset` | Forget all peers and become sole member of a new cluster |
| `--secrets-encryption` | Enable Secret encryption at rest |
# RancherD Agent CLI Options
The following command is used to run the RancherD agent:
```
rancherd agent [OPTIONS]
```
The following options are available.
### Config
| Option | Description |
|--------|-------------|
| `--config FILE, -c FILE` | Load configuration from FILE (default: "/etc/rancher/rke2/config.yaml") |
### Data
| Option | Description |
|--------|-------------|
| `--data-dir value, -d value` | Folder to hold state (default: "/var/lib/rancher/rancherd") |
### Logging
| Option | Description |
|--------|-------------|
| `--debug` | Turn on debug logs |
### Cluster
| Option | Description |
|--------|-------------|
| `--token value, -t value` | Token to use for authentication |
| `--token-file value` | Token file to use for authentication |
| `--server value, -s value` | Server to connect to |
### Agent Node
| Option | Description |
|--------|-------------|
| `--node-name value` | Node name |
| `--node-label value` | Registering and starting kubelet with set of labels |
| `--node-taint value` | Registering kubelet with set of taints |
| `--selinux` | Enable SELinux in containerd |
| `--protect-kernel-defaults` | Kernel tuning behavior. If set, error if kernel tunables are different than kubelet defaults. |
### Agent Runtime
| Option | Description |
|--------|-------------|
| `--container-runtime-endpoint value` | Disable embedded containerd and use alternative CRI implementation |
| `--snapshotter value` | Override default containerd snapshotter (default: "overlayfs") |
| `--private-registry value` | Private registry configuration file (default: "/etc/rancher/rke2/registries.yaml") |
### Agent Networking
| Option | Description |
|--------|-------------|
| `--node-ip value, -i value` | IP address to advertise for node |
| `--resolv-conf value` | Kubelet resolv.conf file |
### Agent Flags
| Option | Description |
|--------|-------------|
| `--kubelet-arg value` | Customized flag for kubelet process |
| `--kube-proxy-arg value` | Customized flag for kube-proxy process |
### System Images Registry
| Option | Description |
|--------|-------------|
| `--system-default-registry value` | Private registry to be used for all system Docker images |
### Cloud Provider
| Option | Description |
|--------|-------------|
| `--cloud-provider-name value` | Cloud provider name |
| `--cloud-provider-config value` | Cloud provider configuration file path |
### Security
| Option | Description |
|--------|-------------|
| `--profile value` | Validate system configuration against the selected benchmark (valid items: cis-1.5) |
content/rancher/v2.6/en/installation/other-installation-methods/install-rancher-on-linux/rollbacks/_index.md
-10
View File
@@ -1,10 +0,0 @@
---
title: Rollbacks
weight: 3
aliases:
- /rancher/v2.6/en/installation/install-rancher-on-linux/rollbacks
---
> RancherD is an experimental feature.
To roll back Rancher to a previous version, re-run the installation script with the previous version specified in the `INSTALL_RANCHERD_VERSION` environment variable.
content/rancher/v2.6/en/installation/other-installation-methods/install-rancher-on-linux/upgrades/_index.md
-72
View File
@@ -1,72 +0,0 @@
---
title: Upgrades
weight: 2
aliases:
- /rancher/v2.6/en/installation/install-rancher-on-linux/upgrades
---
> RancherD is an experimental feature.
When RancherD is upgraded, the Rancher Helm controller and the Fleet pods are upgraded.
During a RancherD upgrade, there is very little downtime, but it is possible that RKE2 may be down for a minute, during which you could lose access to Rancher.
When Rancher is installed with RancherD, the underlying Kubernetes cluster can't be upgraded from the Rancher UI. It needs to be upgraded using the RancherD CLI.
### Upgrading the Rancher Helm Chart without Upgrading the Underlying Cluster
To upgrade Rancher without upgrading the underlying Kubernetes cluster, follow these steps.
> Before upgrading, we recommend that you should:
>
> - Create a backup of the Rancher server using the [backup application.]({{<baseurl>}}/rancher/v2.6/en/backups/v2.5/back-up-rancher/)
> - Review the known issues for the Rancher version you are upgrading to. The known issues are listed in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
1. Uninstall the chart with Helm:
```
helm uninstall rancher
```
2. Reinstall the Rancher chart with Helm. To install a specific Rancher version, use the `--version` flag. For example:
```
helm install rancher rancher-latest/rancher \
--namespace cattle-system \
--set hostname=rancher.my.org \
--version 2.5.1
```
**Result:** Rancher is upgraded to the new version.
If necessary, restore Rancher from backup by following [these steps.]({{<baseurl>}}/rancher/v2.6/en/backups/restoring-rancher/)
### Upgrading Both Rancher and the Underlying Cluster
Upgrade both RancherD and the underlying Kubernetes cluster by re-running the RancherD installation script.
> Before upgrading, we recommend that you should:
>
> - Create a backup of the Rancher server using the [backup application.]({{<baseurl>}}/rancher/v2.6/en/backups/v2.5/back-up-rancher/)
> - Review the known issues for the Rancher version you are upgrading to. The known issues are listed in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
```
sudo curl -sfL https://get.rancher.io | sudo sh -
```
To specify a specific version to upgrade to, use `INSTALL_RANCHERD_VERSION` environment variable:
```
curl -sfL https://get.rancher.io | INSTALL_RANCHERD_VERSION=v2.5.1 sh -
```
Then launch the server:
```
systemctl enable rancherd-server
systemctl start rancherd-server
```
The upgrade can also be performed by manually installing the binary of the desired version.