mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-24 20:18:18 +00:00
Fix tables of contents, headers and formatting
This commit is contained in:
Catherine Luse
-7
@@ -15,13 +15,6 @@ Make sure that your node fulfills the general [installation requirements.](../..
|
||||
|
||||
## Installation Outline
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
- [1. Provision Linux Host](#1-provision-linux-host)
|
||||
- [2. Choose an SSL Option and Install Rancher](#2-choose-an-ssl-option-and-install-rancher)
|
||||
- [3. Configure Load Balancer](#3-configure-load-balancer)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
## 1. Provision Linux Host
|
||||
|
||||
|
||||
+2
-2
@@ -34,7 +34,7 @@ sudo iptables --list
|
||||
|
||||
This section describes how to use `firewalld` to apply the [firewall port rules](../../installation-requirements/port-requirements.md) for nodes in a high-availability Rancher server cluster.
|
||||
|
||||
# Prerequisite
|
||||
## Prerequisite
|
||||
|
||||
Install v7.x or later ofv`firewalld`:
|
||||
|
||||
@@ -44,7 +44,7 @@ systemctl start firewalld
|
||||
systemctl enable firewalld
|
||||
```
|
||||
|
||||
# Applying Firewall Port Rules
|
||||
## Applying Firewall Port Rules
|
||||
|
||||
In the Rancher high-availability installation instructions, the Rancher server is set up on three nodes that have all three Kubernetes roles: etcd, controlplane, and worker. If your Rancher server nodes have all three roles, run the following commands on each node:
|
||||
|
||||
|
||||
+1
-1
@@ -14,7 +14,7 @@ Environment Variable Key | Default Value | Status | Available as of
|
||||
`istio-virtual-service-ui` |`false` | Experimental | v2.3.0
|
||||
`istio-virtual-service-ui` | `true` | GA | v2.3.2
|
||||
|
||||
# About this Feature
|
||||
## About this Feature
|
||||
|
||||
A central advantage of Istio's traffic management features is that they allow dynamic request routing, which is useful for canary deployments, blue/green deployments, or A/B testing.
|
||||
|
||||
|
||||
+2
-1
@@ -3,7 +3,7 @@ title: "Running on ARM64 (Experimental)"
|
||||
weight: 3
|
||||
---
|
||||
|
||||
:::caution:
|
||||
:::caution
|
||||
|
||||
Running on an ARM64 platform is currently an experimental feature and is not yet officially supported in Rancher. Therefore, we do not recommend using ARM64 based nodes in a production environment.
|
||||
|
||||
@@ -21,6 +21,7 @@ The following options are available when using an ARM64 platform:
|
||||
--privileged \
|
||||
rancher/rancher:vX.Y.Z
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
To check if your specific released version is compatible with the ARM64 architecture, you may navigate to your
|
||||
|
||||
+9
-9
@@ -10,7 +10,7 @@ The guide uses command line tools to provision an AKS cluster with an ingress. I
|
||||
|
||||
If you already have an AKS Kubernetes cluster, skip to the step about [installing an ingress.](#5-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)
|
||||
|
||||
# Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
:::caution
|
||||
|
||||
@@ -24,7 +24,7 @@ Deploying to Microsoft Azure will incur charges.
|
||||
- Your subscription has sufficient quota for at least 2 vCPUs. For details on Rancher server resource requirements, refer to [this section](../../../pages-for-subheaders/installation-requirements.md#rke-and-hosted-kubernetes)
|
||||
- When installing Rancher with Helm in Azure, use the L7 load balancer to avoid networking issues. For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
|
||||
|
||||
# 1. Prepare your Workstation
|
||||
## 1. Prepare your Workstation
|
||||
|
||||
Install the following command line tools on your workstation:
|
||||
|
||||
@@ -32,7 +32,7 @@ Install the following command line tools on your workstation:
|
||||
- **kubectl:** For help, refer to these [installation steps.](https://kubernetes.io/docs/tasks/tools/#kubectl)
|
||||
- **helm:** For help, refer to these [installation steps.](https://helm.sh/docs/intro/install/)
|
||||
|
||||
# 2. Create a Resource Group
|
||||
## 2. Create a Resource Group
|
||||
|
||||
After installing the CLI, you will need to log in with your Azure account.
|
||||
|
||||
@@ -46,7 +46,7 @@ Create a [resource group](https://docs.microsoft.com/en-us/azure/azure-resource-
|
||||
az group create --name rancher-rg --location eastus
|
||||
```
|
||||
|
||||
# 3. Create the AKS Cluster
|
||||
## 3. Create the AKS Cluster
|
||||
|
||||
To create an AKS cluster, run the following command. Use a VM size that applies to your use case. Refer to [this article](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for available sizes and options. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
|
||||
|
||||
@@ -67,7 +67,7 @@ az aks create \
|
||||
|
||||
The cluster will take some time to be deployed.
|
||||
|
||||
# 4. Get Access Credentials
|
||||
## 4. Get Access Credentials
|
||||
|
||||
After the cluster is deployed, get the access credentials.
|
||||
|
||||
@@ -77,7 +77,7 @@ az aks get-credentials --resource-group rancher-rg --name rancher-server
|
||||
|
||||
This command merges your cluster's credentials into the existing kubeconfig and allows `kubectl` to interact with the cluster.
|
||||
|
||||
# 5. Install an Ingress
|
||||
## 5. Install an Ingress
|
||||
|
||||
The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription.
|
||||
|
||||
@@ -94,7 +94,7 @@ helm upgrade --install \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
# 6. Get Load Balancer IP
|
||||
## 6. Get Load Balancer IP
|
||||
|
||||
To get the address of the load balancer, run:
|
||||
|
||||
@@ -113,7 +113,7 @@ ingress-nginx-controller LoadBalancer 10.0.116.18 40.31.180.83 80:31229
|
||||
|
||||
Save the `EXTERNAL-IP`.
|
||||
|
||||
# 7. Set up DNS
|
||||
## 7. Set up DNS
|
||||
|
||||
External traffic to the Rancher server will need to be directed at the load balancer you created.
|
||||
|
||||
@@ -121,7 +121,7 @@ Set up a DNS to point at the `EXTERNAL-IP` that you saved. This DNS will be used
|
||||
|
||||
There are many valid ways to set up the DNS. For help, refer to the [Azure DNS documentation](https://docs.microsoft.com/en-us/azure/dns/)
|
||||
|
||||
# 8. Install the Rancher Helm Chart
|
||||
## 8. Install the Rancher Helm Chart
|
||||
|
||||
Next, install the Rancher Helm chart by following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
|
||||
|
||||
|
||||
+2
-4
@@ -12,10 +12,8 @@ The second is a guide for installing an EKS cluster with an ingress by using com
|
||||
|
||||
If you already have an EKS Kubernetes cluster, skip to the step about [installing an ingress.](#5-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)
|
||||
|
||||
- [Automated Quickstart using AWS Best Practices](#automated-quickstart-using-aws-best-practices)
|
||||
- [Creating an EKS Cluster for the Rancher Server](#creating-an-eks-cluster-for-the-rancher-server)
|
||||
|
||||
# Automated Quickstart using AWS Best Practices
|
||||
## Automated Quickstart using AWS Best Practices
|
||||
|
||||
Rancher and Amazon Web Services collaborated on a quick start guide for deploying Rancher on an EKS cluster following AWS best practices. The deployment guide is [here.](https://aws-quickstart.github.io/quickstart-eks-rancher/)
|
||||
|
||||
@@ -41,7 +39,7 @@ Deploying this Quick Start for a new virtual private cloud (VPC) and new Amazon
|
||||
|
||||
\* The CloudFormation template that deploys the Quick Start into an existing Amazon EKS cluster skips the components marked by asterisks and prompts you for your existing VPC configuration.
|
||||
|
||||
# Creating an EKS Cluster for the Rancher Server
|
||||
## Creating an EKS Cluster for the Rancher Server
|
||||
|
||||
In this section, you'll install an EKS cluster with an ingress by using command line tools. This guide may be useful if you want to use fewer resources while trying out Rancher on EKS.
|
||||
|
||||
|
||||
+11
-11
@@ -11,13 +11,13 @@ In this section, you'll learn how to install Rancher using Google Kubernetes Eng
|
||||
|
||||
If you already have a GKE Kubernetes cluster, skip to the step about [installing an ingress.](#7-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)
|
||||
|
||||
# Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
- You will need a Google account.
|
||||
- You will need a Google Cloud billing account. You can manage your Cloud Billing accounts using the Google Cloud Console. For more information about the Cloud Console, visit [General guide to the console.](https://support.google.com/cloud/answer/3465889?hl=en&ref_topic=3340599)
|
||||
- You will need a cloud quota for at least one in-use IP address and at least 2 CPUs. For more details about hardware requirements for the Rancher server, refer to [this section.](../../../pages-for-subheaders/installation-requirements.md#rke-and-hosted-kubernetes)
|
||||
|
||||
# 1. Enable the Kubernetes Engine API
|
||||
## 1. Enable the Kubernetes Engine API
|
||||
|
||||
Take the following steps to enable the Kubernetes Engine API:
|
||||
|
||||
@@ -26,7 +26,7 @@ Take the following steps to enable the Kubernetes Engine API:
|
||||
1. Open the project and enable the Kubernetes Engine API for the project. Wait for the API and related services to be enabled. This can take several minutes.
|
||||
1. Make sure that billing is enabled for your Cloud project. For information on how to enable billing for your project, refer to the [Google Cloud documentation.](https://cloud.google.com/billing/docs/how-to/modify-project#enable_billing_for_a_project)
|
||||
|
||||
# 2. Open the Cloud Shell
|
||||
## 2. Open the Cloud Shell
|
||||
|
||||
Cloud Shell is a shell environment for managing resources hosted on Google Cloud. Cloud Shell comes preinstalled with the `gcloud` command-line tool and kubectl command-line tool. The `gcloud` tool provides the primary command-line interface for Google Cloud, and `kubectl` provides the primary command-line interface for running commands against Kubernetes clusters.
|
||||
|
||||
@@ -65,7 +65,7 @@ To install `gcloud` and `kubectl`, perform the following steps:
|
||||
|
||||
|
||||
|
||||
# 3. Configure the gcloud CLI
|
||||
## 3. Configure the gcloud CLI
|
||||
|
||||
Set up default gcloud settings using one of the following methods:
|
||||
|
||||
@@ -93,7 +93,7 @@ To install `gcloud` and `kubectl`, perform the following steps:
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# 4. Confirm that gcloud is configured correctly
|
||||
## 4. Confirm that gcloud is configured correctly
|
||||
|
||||
Run:
|
||||
|
||||
@@ -115,7 +115,7 @@ project = <Your project ID>
|
||||
Your active configuration is: [default]
|
||||
```
|
||||
|
||||
# 5. Create a GKE Cluster
|
||||
## 5. Create a GKE Cluster
|
||||
|
||||
The following command creates a three-node cluster.
|
||||
|
||||
@@ -129,7 +129,7 @@ When choosing a Kubernetes version, be sure to first consult the [support matrix
|
||||
gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=<VERSION>
|
||||
```
|
||||
|
||||
# 6. Get Authentication Credentials
|
||||
## 6. Get Authentication Credentials
|
||||
|
||||
After creating your cluster, you need to get authentication credentials to interact with the cluster:
|
||||
|
||||
@@ -139,7 +139,7 @@ gcloud container clusters get-credentials cluster-name
|
||||
|
||||
This command configures `kubectl` to use the cluster you created.
|
||||
|
||||
# 7. Install an Ingress
|
||||
## 7. Install an Ingress
|
||||
|
||||
The cluster needs an Ingress so that Rancher can be accessed from outside the cluster.
|
||||
|
||||
@@ -156,7 +156,7 @@ helm upgrade --install \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
# 8. Get the Load Balancer IP
|
||||
## 8. Get the Load Balancer IP
|
||||
|
||||
To get the address of the load balancer, run:
|
||||
|
||||
@@ -173,7 +173,7 @@ ingress-nginx-controller LoadBalancer 10.3.244.156 35.233.206.34 80:3187
|
||||
|
||||
Save the `EXTERNAL-IP`.
|
||||
|
||||
# 9. Set up DNS
|
||||
## 9. Set up DNS
|
||||
|
||||
External traffic to the Rancher server will need to be directed at the load balancer you created.
|
||||
|
||||
@@ -181,7 +181,7 @@ Set up a DNS to point at the external IP that you saved. This DNS will be used a
|
||||
|
||||
There are many valid ways to set up the DNS. For help, refer to the Google Cloud documentation about [managing DNS records.](https://cloud.google.com/dns/docs/records)
|
||||
|
||||
# 10. Install the Rancher Helm chart
|
||||
## 10. Install the Rancher Helm chart
|
||||
|
||||
Next, install the Rancher Helm chart by following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
|
||||
|
||||
|
||||
+3
-6
@@ -3,11 +3,8 @@ title: Rollbacks
|
||||
weight: 3
|
||||
---
|
||||
|
||||
- [Rolling Back to Rancher v2.5.0+](#rolling-back-to-rancher-v2-5-0)
|
||||
- [Rolling Back to Rancher v2.2-v2.4+](#rolling-back-to-rancher-v2-2-v2-4)
|
||||
- [Rolling Back to Rancher v2.0-v2.1](#rolling-back-to-rancher-v2-0-v2-1)
|
||||
|
||||
# Rolling Back to Rancher v2.5.0+
|
||||
## Rolling Back to Rancher v2.5.0+
|
||||
|
||||
To roll back to Rancher v2.5.0+, use the **Rancher Backups** application and restore Rancher from backup.
|
||||
|
||||
@@ -102,7 +99,7 @@ When the target revision is determined, perform the rollback. This example will
|
||||
helm rollback rancher 3 -n cattle-system
|
||||
```
|
||||
|
||||
# Rolling Back to Rancher v2.2-v2.4+
|
||||
## Rolling Back to Rancher v2.2-v2.4+
|
||||
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](../../../../versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
|
||||
@@ -114,6 +111,6 @@ Managed clusters are authoritative for their state. This means restoring the Ran
|
||||
|
||||
:::
|
||||
|
||||
# Rolling Back to Rancher v2.0-v2.1
|
||||
## Rolling Back to Rancher v2.0-v2.1
|
||||
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](../../../../versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
|
||||
+8
-16
@@ -8,12 +8,8 @@ For the instructions to upgrade Rancher installed with Docker, refer to [this pa
|
||||
|
||||
To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Upgrade Outline](#upgrade-outline)
|
||||
- [Known Upgrade Issues](#known-upgrade-issues)
|
||||
- [RKE Add-on Installs](#rke-add-on-installs)
|
||||
|
||||
# Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
### Access to kubeconfig
|
||||
|
||||
@@ -47,22 +43,18 @@ If you are upgrading to Rancher v2.5 from a Rancher server that was started with
|
||||
|
||||
[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) Upgrade cert-manager to the latest version by following [these instructions.](../resources/upgrade-cert-manager.md)
|
||||
|
||||
# Upgrade Outline
|
||||
## Upgrade Outline
|
||||
|
||||
Follow the steps to upgrade Rancher server:
|
||||
|
||||
- [1. Back up your Kubernetes cluster that is running Rancher server](#1-back-up-your-kubernetes-cluster-that-is-running-rancher-server)
|
||||
- [2. Update the Helm chart repository](#2-update-the-helm-chart-repository)
|
||||
- [3. Upgrade Rancher](#3-upgrade-rancher)
|
||||
- [4. Verify the Upgrade](#4-verify-the-upgrade)
|
||||
|
||||
# 1. Back up Your Kubernetes Cluster that is Running Rancher Server
|
||||
### 1. Back up Your Kubernetes Cluster that is Running Rancher Server
|
||||
|
||||
Use the [backup application](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) to back up Rancher.
|
||||
|
||||
You'll use the backup as a restore point if something goes wrong during upgrade.
|
||||
|
||||
# 2. Update the Helm chart repository
|
||||
### 2. Update the Helm chart repository
|
||||
|
||||
1. Update your local helm repo cache.
|
||||
|
||||
@@ -115,7 +107,7 @@ You'll use the backup as a restore point if something goes wrong during upgrade.
|
||||
helm fetch rancher-<CHART_REPO>/rancher --version=v2.4.11
|
||||
```
|
||||
|
||||
# 3. Upgrade Rancher
|
||||
### 3. Upgrade Rancher
|
||||
|
||||
This section describes how to upgrade normal (Internet-connected) or air-gapped installations of Rancher with Helm.
|
||||
|
||||
@@ -143,7 +135,7 @@ There will be more values that are listed with this command. This is just an exa
|
||||
|
||||
If you are upgrading cert-manager to the latest version from v1.5 or below, follow the [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#option-c-upgrade-cert-manager-from-versions-1-5-and-below) to learn how to upgrade cert-manager without needing to perform an uninstall or reinstall of Rancher. Otherwise, follow the [steps to upgrade Rancher](#steps-to-upgrade-rancher) below.
|
||||
|
||||
### Steps to Upgrade Rancher
|
||||
#### Steps to Upgrade Rancher
|
||||
|
||||
Upgrade Rancher to the latest version with all your settings.
|
||||
|
||||
@@ -172,7 +164,7 @@ helm upgrade rancher rancher-<CHART_REPO>/rancher \
|
||||
--version=2.4.5
|
||||
```
|
||||
|
||||
# 4. Verify the Upgrade
|
||||
### 4. Verify the Upgrade
|
||||
|
||||
Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
@@ -184,6 +176,6 @@ See [Restoring Cluster Networking](../../../../versioned_docs/version-2.0-2.4/ge
|
||||
|
||||
:::
|
||||
|
||||
# Known Upgrade Issues
|
||||
## Known Upgrade Issues
|
||||
|
||||
A list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
|
||||
|
||||
+2
-2
@@ -45,7 +45,7 @@ Create the registries.yaml file at `/etc/rancher/k3s/registries.yaml`. This will
|
||||
|
||||
The registries.yaml file should look like this before plugging in the necessary information:
|
||||
|
||||
```
|
||||
```yaml
|
||||
---
|
||||
mirrors:
|
||||
customreg:
|
||||
@@ -109,7 +109,7 @@ To use this `kubeconfig` file,
|
||||
2. Copy the file at `/etc/rancher/k3s/k3s.yaml` and save it to the directory `~/.kube/config` on your local machine.
|
||||
3. In the kubeconfig file, the `server` directive is defined as localhost. Configure the server as the DNS of your load balancer, referring to port 6443. (The Kubernetes API server will be reached at port 6443, while the Rancher server will be reached at ports 80 and 443.) Here is an example `k3s.yaml`:
|
||||
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
|
||||
+30
-38
@@ -9,22 +9,15 @@ This section is about how to deploy Rancher for your air gapped environment in a
|
||||
|
||||
When the Rancher server is deployed in the Docker container, a local Kubernetes cluster is installed within the container for Rancher to use. Because many features of Rancher run as deployments, and privileged mode is required to run containers within containers, you will need to install Rancher with the `--privileged` option.
|
||||
|
||||
# Docker Instructions
|
||||
## Docker Instructions
|
||||
|
||||
If you want to continue the air gapped installation using Docker commands, skip the rest of this page and follow the instructions on [this page.](docker-install-commands.md)
|
||||
|
||||
# Kubernetes Instructions
|
||||
## Kubernetes Instructions
|
||||
|
||||
Rancher recommends installing Rancher on a Kubernetes cluster. A highly available Kubernetes install is comprised of three nodes running the Rancher server components on a Kubernetes cluster. The persistence layer (etcd) is also replicated on these three nodes, providing redundancy and data duplication in case one of the nodes fails.
|
||||
|
||||
This section describes installing Rancher:
|
||||
|
||||
- [1. Add the Helm Chart Repository](#1-add-the-helm-chart-repository)
|
||||
- [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration)
|
||||
- [3. Render the Rancher Helm Template](#3-render-the-rancher-helm-template)
|
||||
- [4. Install Rancher](#4-install-rancher)
|
||||
|
||||
# 1. Add the Helm Chart Repository
|
||||
### 1. Add the Helm Chart Repository
|
||||
|
||||
From a system that has access to the internet, fetch the latest Helm chart and copy the resulting manifests to a system that has access to the Rancher server cluster.
|
||||
|
||||
@@ -55,7 +48,7 @@ From a system that has access to the internet, fetch the latest Helm chart and c
|
||||
helm fetch rancher-stable/rancher --version=v2.4.8
|
||||
```
|
||||
|
||||
# 2. Choose your SSL Configuration
|
||||
### 2. Choose your SSL Configuration
|
||||
|
||||
Rancher Server is designed to be secure by default and requires SSL/TLS configuration.
|
||||
|
||||
@@ -72,7 +65,7 @@ If you want terminate SSL/TLS externally, see [TLS termination on an External Lo
|
||||
| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br/> This is the **default** and does not need to be added when rendering the Helm template. | yes |
|
||||
| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s). <br/> This option must be passed when rendering the Rancher Helm template. | no |
|
||||
|
||||
# Helm Chart Options for Air Gap Installations
|
||||
### Helm Chart Options for Air Gap Installations
|
||||
|
||||
When setting up the Rancher Helm template, there are several options in the Helm chart that are designed specifically for air gap installations.
|
||||
|
||||
@@ -82,11 +75,11 @@ When setting up the Rancher Helm template, there are several options in the Helm
|
||||
| `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters. |
|
||||
| `useBundledSystemChart` | `true` | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. |
|
||||
|
||||
# 3. Render the Rancher Helm Template
|
||||
### 3. Render the Rancher Helm Template
|
||||
|
||||
Based on the choice your made in [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration), complete one of the procedures below.
|
||||
|
||||
# Option A: Default Self-Signed Certificate
|
||||
#### Option A: Default Self-Signed Certificate
|
||||
|
||||
|
||||
By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface.
|
||||
@@ -97,7 +90,7 @@ Recent changes to cert-manager require an upgrade. If you are upgrading Rancher
|
||||
|
||||
:::
|
||||
|
||||
### 1. Add the cert-manager repo
|
||||
##### 1. Add the cert-manager repo
|
||||
|
||||
From a system connected to the internet, add the cert-manager repo to Helm:
|
||||
|
||||
@@ -106,7 +99,7 @@ helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
```
|
||||
|
||||
### 2. Fetch the cert-manager chart
|
||||
##### 2. Fetch the cert-manager chart
|
||||
|
||||
Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).
|
||||
|
||||
@@ -120,7 +113,7 @@ New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommen
|
||||
helm fetch jetstack/cert-manager --version v1.7.1
|
||||
```
|
||||
|
||||
### 3. Render the cert-manager template
|
||||
##### 3. Render the cert-manager template
|
||||
|
||||
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.
|
||||
|
||||
@@ -133,14 +126,14 @@ helm template cert-manager ./cert-manager-v1.7.1.tgz --output-dir . \
|
||||
--set startupapicheck.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-ctl
|
||||
```
|
||||
|
||||
### 4. Download the cert-manager CRD
|
||||
##### 4. Download the cert-manager CRD
|
||||
|
||||
Download the required CRD file for cert-manager:
|
||||
```plain
|
||||
curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
|
||||
```
|
||||
|
||||
### 5. Render the Rancher template
|
||||
##### 5. Render the Rancher template
|
||||
|
||||
Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
|
||||
|
||||
@@ -165,14 +158,14 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
|
||||
**Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.5.8`
|
||||
|
||||
# Option B: Certificates From Files using Kubernetes Secrets
|
||||
#### Option B: Certificates From Files using Kubernetes Secrets
|
||||
|
||||
|
||||
### 1. Create secrets
|
||||
##### 1. Create secrets
|
||||
|
||||
Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher.
|
||||
|
||||
### 2. Render the Rancher template
|
||||
##### 2. Render the Rancher template
|
||||
|
||||
Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
|
||||
|
||||
@@ -211,7 +204,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
|
||||
|
||||
Then refer to [Adding TLS Secrets](../../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them.
|
||||
|
||||
# 4. Install Rancher
|
||||
### 4. Install Rancher
|
||||
|
||||
Copy the rendered manifest directories to a system that has access to the Rancher server cluster to complete installation.
|
||||
|
||||
@@ -219,7 +212,7 @@ Use `kubectl` to create namespaces and apply the rendered manifests.
|
||||
|
||||
If you choose to use self-signed certificates in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), install cert-manager.
|
||||
|
||||
### For Self-Signed Certificate Installs, Install Cert-manager
|
||||
#### For Self-Signed Certificate Installs, Install Cert-manager
|
||||
|
||||
<details id="install-cert-manager">
|
||||
<summary>Click to expand</summary>
|
||||
@@ -227,14 +220,13 @@ If you choose to use self-signed certificates in [B. Choose your SSL Configurati
|
||||
If you are using self-signed certificates, install cert-manager:
|
||||
|
||||
1. Create the namespace for cert-manager.
|
||||
```plain
|
||||
kubectl create namespace cert-manager
|
||||
```
|
||||
|
||||
1. Create the cert-manager CustomResourceDefinitions (CRDs).
|
||||
```plain
|
||||
kubectl apply -f cert-manager/cert-manager-crd.yaml
|
||||
```
|
||||
```plain
|
||||
kubectl create namespace cert-manager
|
||||
```
|
||||
2. Create the cert-manager CustomResourceDefinitions (CRDs).
|
||||
```plain
|
||||
kubectl apply -f cert-manager/cert-manager-crd.yaml
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
@@ -242,14 +234,14 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml
|
||||
|
||||
:::
|
||||
|
||||
1. Launch cert-manager.
|
||||
```plain
|
||||
kubectl apply -R -f ./cert-manager
|
||||
```
|
||||
3. Launch cert-manager.
|
||||
```plain
|
||||
kubectl apply -R -f ./cert-manager
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### Install Rancher with kubectl
|
||||
#### Install Rancher with kubectl
|
||||
|
||||
```plain
|
||||
kubectl create namespace cattle-system
|
||||
@@ -263,7 +255,7 @@ If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/
|
||||
|
||||
:::
|
||||
|
||||
# Additional Resources
|
||||
## Additional Resources
|
||||
|
||||
These resources could be helpful when installing Rancher:
|
||||
|
||||
|
||||
+1
-1
@@ -178,7 +178,7 @@ Your registry must support manifests. As of April 2020, Amazon Elastic Container
|
||||
|
||||
Append your private registry address to the `allow-nondistributable-artifacts` config field in the Docker daemon (`C:\ProgramData\Docker\config\daemon.json`). Since the base image of Windows images are maintained by the `mcr.microsoft.com` registry, this step is required as the layers in the Microsoft registry are missing from Docker Hub and need to be pulled into the private registry.
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
...
|
||||
"allow-nondistributable-artifacts": [
|
||||
|
||||
+1
-3
@@ -5,8 +5,6 @@ weight: 200
|
||||
|
||||
Once the infrastructure is ready, you can continue with setting up an RKE cluster to install Rancher in.
|
||||
|
||||
### Installing Docker
|
||||
|
||||
First, you have to install Docker and setup the HTTP proxy on all three Linux nodes. For this perform the following steps on all three nodes.
|
||||
|
||||
For convenience, export the IP address and port of your proxy into an environment variable and set up the HTTP_PROXY variables for your current shell:
|
||||
@@ -105,7 +103,7 @@ sudo ./get_helm.sh
|
||||
|
||||
Next, create a YAML file that describes the RKE cluster. Ensure that the IP addresses of the nodes and the SSH username are correct. For more information on the cluster YAML, have a look at the [RKE documentation](https://rancher.com/docs/rke/latest/en/example-yamls/).
|
||||
|
||||
```
|
||||
```yml
|
||||
nodes:
|
||||
- address: 10.0.1.200
|
||||
user: ubuntu
|
||||
|
||||
+20
-30
@@ -14,12 +14,12 @@ The following instructions will guide you through upgrading a Rancher server tha
|
||||
|
||||
:::
|
||||
|
||||
# Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
- **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#known-upgrade-issues)** section in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums](https://forums.rancher.com/c/announcements/12). Note that upgrades to or from any chart in the [rancher-alpha repository](../../../../reference-guides/installation-references/helm-chart-options.md#helm-chart-repositories/) aren’t supported.
|
||||
- **For [air gap installs only,](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version**. Follow the guide to [populate your private registry](../air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
|
||||
|
||||
# Placeholder Review
|
||||
## Placeholder Review
|
||||
|
||||
During upgrade, you'll enter a series of commands, filling placeholders with data from your environment. These placeholders are denoted with angled brackets and all capital letters (`<EXAMPLE>`).
|
||||
|
||||
@@ -31,7 +31,7 @@ docker stop <RANCHER_CONTAINER_NAME>
|
||||
|
||||
In this command, `<RANCHER_CONTAINER_NAME>` is the name of your Rancher container.
|
||||
|
||||
# Get Data for Upgrade Commands
|
||||
## Get Data for Upgrade Commands
|
||||
|
||||
To obtain the data to replace the placeholders, run:
|
||||
|
||||
@@ -55,18 +55,10 @@ Write down or copy this information before starting the upgrade.
|
||||
|
||||
You can obtain `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>` by logging into your Rancher server by remote connection and entering the command to view the containers that are running: `docker ps`. You can also view containers that are stopped using a different command: `docker ps -a`. Use these commands for help anytime during while creating backups.
|
||||
|
||||
# Upgrade Outline
|
||||
## Upgrade
|
||||
|
||||
During upgrade, you create a copy of the data from your current Rancher container and a backup in case something goes wrong. Then you deploy the new version of Rancher in a new container using your existing data. Follow the steps to upgrade Rancher server:
|
||||
|
||||
- [1. Create a copy of the data from your Rancher server container](#1-create-a-copy-of-the-data-from-your-rancher-server-container)
|
||||
- [2. Create a backup tarball](#2-create-a-backup-tarball)
|
||||
- [3. Pull the new Docker image](#3-pull-the-new-docker-image)
|
||||
- [4. Start the new Rancher server container](#4-start-the-new-rancher-server-container)
|
||||
- [5. Verify the Upgrade](#5-verify-the-upgrade)
|
||||
- [6. Clean up your old Rancher server container](#6-clean-up-your-old-rancher-server-container)
|
||||
|
||||
# 1. Create a copy of the data from your Rancher server container
|
||||
During upgrade, you create a copy of the data from your current Rancher container and a backup in case something goes wrong. Then you deploy the new version of Rancher in a new container using your existing data.
|
||||
### 1. Create a copy of the data from your Rancher server container
|
||||
|
||||
1. Using a remote Terminal connection, log into the node running your Rancher server.
|
||||
|
||||
@@ -82,13 +74,11 @@ During upgrade, you create a copy of the data from your current Rancher containe
|
||||
docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data rancher/rancher:<RANCHER_CONTAINER_TAG>
|
||||
```
|
||||
|
||||
# 2. Create a backup tarball
|
||||
### 2. Create a backup tarball
|
||||
|
||||
1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data</code>), create a backup tarball (<code>rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz</code>).
|
||||
|
||||
This tarball will serve as a rollback point if something goes wrong during upgrade. Use the following command, replacing each placeholder.
|
||||
|
||||
|
||||
```
|
||||
docker run --volumes-from rancher-data -v "$PWD:/backup" --rm busybox tar zcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
|
||||
```
|
||||
@@ -104,7 +94,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
|
||||
|
||||
1. Move your backup tarball to a safe location external from your Rancher server.
|
||||
|
||||
# 3. Pull the New Docker Image
|
||||
### 3. Pull the New Docker Image
|
||||
|
||||
Pull the image of the Rancher version that you want to upgrade to.
|
||||
|
||||
@@ -116,7 +106,7 @@ Placeholder | Description
|
||||
docker pull rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
# 4. Start the New Rancher Server Container
|
||||
### 4. Start the New Rancher Server Container
|
||||
|
||||
Start a new Rancher server container using the data from the `rancher-data` container. Remember to pass in all the environment variables that you had used when you started the original container.
|
||||
|
||||
@@ -142,7 +132,7 @@ To see the command to use when starting the new Rancher server container, choose
|
||||
|
||||
Select which option you had installed Rancher server
|
||||
|
||||
### Option A: Default Self-Signed Certificate
|
||||
#### Option A: Default Self-Signed Certificate
|
||||
|
||||
<details id="option-a">
|
||||
<summary>Click to expand</summary>
|
||||
@@ -165,10 +155,10 @@ Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-s
|
||||
|
||||
</details>
|
||||
|
||||
### Option B: Bring Your Own Certificate: Self-Signed
|
||||
#### Option B: Bring Your Own Certificate: Self-Signed
|
||||
|
||||
<details id="option-b">
|
||||
<summary>Click to expand</summary>
|
||||
<summary>Click to expand</summary>
|
||||
|
||||
If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
|
||||
|
||||
@@ -201,7 +191,7 @@ Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-s
|
||||
|
||||
</details>
|
||||
|
||||
### Option C: Bring Your Own Certificate: Signed by Recognized CA
|
||||
#### Option C: Bring Your Own Certificate: Signed by Recognized CA
|
||||
|
||||
<details id="option-c">
|
||||
<summary>Click to expand</summary>
|
||||
@@ -235,7 +225,7 @@ docker run -d --volumes-from rancher-data \
|
||||
Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)
|
||||
</details>
|
||||
|
||||
### Option D: Let's Encrypt Certificate
|
||||
#### Option D: Let's Encrypt Certificate
|
||||
|
||||
<details id="option-d">
|
||||
<summary>Click to expand</summary>
|
||||
@@ -280,7 +270,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
|
||||
|
||||
When starting the new Rancher server container, choose from the following options:
|
||||
|
||||
### Option A: Default Self-Signed Certificate
|
||||
#### Option A: Default Self-Signed Certificate
|
||||
|
||||
<details id="option-a">
|
||||
<summary>Click to expand</summary>
|
||||
@@ -305,7 +295,7 @@ Placeholder | Description
|
||||
Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)
|
||||
</details>
|
||||
|
||||
### Option B: Bring Your Own Certificate: Self-Signed
|
||||
#### Option B: Bring Your Own Certificate: Self-Signed
|
||||
|
||||
<details id="option-b">
|
||||
<summary>Click to expand</summary>
|
||||
@@ -341,7 +331,7 @@ docker run -d --restart=unless-stopped \
|
||||
Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)
|
||||
</details>
|
||||
|
||||
### Option C: Bring Your Own Certificate: Signed by Recognized CA
|
||||
#### Option C: Bring Your Own Certificate: Signed by Recognized CA
|
||||
|
||||
<details id="option-c">
|
||||
<summary>Click to expand</summary>
|
||||
@@ -388,7 +378,7 @@ privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-s
|
||||
|
||||
**Result:** You have upgraded Rancher. Data from your upgraded server is now saved to the `rancher-data` container for use in future upgrades.
|
||||
|
||||
# 5. Verify the Upgrade
|
||||
### 5. Verify the Upgrade
|
||||
|
||||
Log into Rancher. Confirm that the upgrade succeeded by checking the version displayed in the bottom-left corner of the browser window.
|
||||
|
||||
@@ -398,10 +388,10 @@ See [Restoring Cluster Networking](../../../../../versioned_docs/version-2.0-2.4
|
||||
|
||||
:::
|
||||
|
||||
# 6. Clean up Your Old Rancher Server Container
|
||||
### 6. Clean up Your Old Rancher Server Container
|
||||
|
||||
Remove the previous Rancher server container. If you only stop the previous Rancher server container (and don't remove it), the container may restart after the next server reboot.
|
||||
|
||||
# Rolling Back
|
||||
## Rolling Back
|
||||
|
||||
If your upgrade does not complete successfully, you can roll back Rancher server and its data back to its last healthy state. For more information, see [Docker Rollback](roll-back-docker-installed-rancher.md).
|
||||
|
||||
@@ -99,6 +99,7 @@ Because the rancher-alpha repository contains only alpha charts, switching betwe
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Docker Images">
|
||||
|
||||
When performing [Docker installs](../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md), upgrades, or rollbacks, you can use _tags_ to install a specific version of Rancher.
|
||||
|
||||
### Server Tags
|
||||
|
||||
@@ -7,33 +7,19 @@ Following an upgrade to the latest version of Rancher, downstream Kubernetes clu
|
||||
|
||||
Rancher calls RKE (Rancher Kubernetes Engine) as a library when provisioning and editing RKE clusters. For more information on configuring the upgrade strategy for RKE clusters, refer to the [RKE documentation](https://rancher.com/docs/rke/latest/en/).
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
- [New Features](#new-features)
|
||||
- [Tested Kubernetes Versions](#tested-kubernetes-versions)
|
||||
- [How Upgrades Work](#how-upgrades-work)
|
||||
- [Recommended Best Practice for Upgrades](#recommended-best-practice-for-upgrades)
|
||||
- [Upgrading the Kubernetes Version](#upgrading-the-kubernetes-version)
|
||||
- [Rolling Back](#rolling-back)
|
||||
- [Configuring the Upgrade Strategy](#configuring-the-upgrade-strategy)
|
||||
- [Configuring the Maximum Unavailable Worker Nodes in the Rancher UI](#configuring-the-maximum-unavailable-worker-nodes-in-the-rancher-ui)
|
||||
- [Enabling Draining Nodes During Upgrades from the Rancher UI](#enabling-draining-nodes-during-upgrades-from-the-rancher-ui)
|
||||
- [Maintaining Availability for Applications During Upgrades](#maintaining-availability-for-applications-during-upgrades)
|
||||
- [Configuring the Upgrade Strategy in the cluster.yml](#configuring-the-upgrade-strategy-in-the-cluster-yml)
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
|
||||
# Tested Kubernetes Versions
|
||||
## Tested Kubernetes Versions
|
||||
|
||||
Before a new version of Rancher is released, it's tested with the latest minor versions of Kubernetes to ensure compatibility. For details on which versions of Kubernetes were tested on each Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/)
|
||||
|
||||
# How Upgrades Work
|
||||
## How Upgrades Work
|
||||
|
||||
RKE v1.1.0 changed the way that clusters are upgraded.
|
||||
|
||||
In this section of the [RKE documentation,](https://rancher.com/docs/rke/latest/en/upgrades/how-upgrades-work) you'll learn what happens when you edit or upgrade your RKE Kubernetes cluster.
|
||||
|
||||
|
||||
# Recommended Best Practice for Upgrades
|
||||
## Recommended Best Practice for Upgrades
|
||||
|
||||
When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
|
||||
@@ -43,7 +29,7 @@ When upgrading the Kubernetes version of a cluster, we recommend that you:
|
||||
|
||||
The restore operation will work on a cluster that is not in a healthy or active state.
|
||||
|
||||
# Upgrading the Kubernetes Version
|
||||
## Upgrading the Kubernetes Version
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
@@ -59,14 +45,14 @@ The restore operation will work on a cluster that is not in a healthy or active
|
||||
|
||||
**Result:** Kubernetes begins upgrading for the cluster.
|
||||
|
||||
# Rolling Back
|
||||
## Rolling Back
|
||||
|
||||
A cluster can be restored to a backup in which the previous Kubernetes version was used. For more information, refer to the following sections:
|
||||
|
||||
- [Backing up a cluster](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md#how-snapshots-work)
|
||||
- [Restoring a cluster from backup](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md#restoring-a-cluster-from-a-snapshot)
|
||||
|
||||
# Configuring the Upgrade Strategy
|
||||
## Configuring the Upgrade Strategy
|
||||
|
||||
As of RKE v1.1.0, additional upgrade options became available to give you more granular control over the upgrade process. These options can be used to maintain availability of your applications during a cluster upgrade if certain [conditions and requirements](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability) are met.
|
||||
|
||||
@@ -122,7 +108,7 @@ More advanced upgrade strategy configuration options are available by editing th
|
||||
|
||||
For details, refer to [Configuring the Upgrade Strategy](https://rancher.com/docs/rke/latest/en/upgrades/configuring-strategy) in the RKE documentation. The section also includes an example `cluster.yml` for configuring the upgrade strategy.
|
||||
|
||||
# Troubleshooting
|
||||
## Troubleshooting
|
||||
|
||||
If a node doesn't come up after an upgrade, the `rke up` command errors out.
|
||||
|
||||
|
||||
@@ -6,20 +6,6 @@ The [Divio documentation system](https://documentation.divio.com/) is a software
|
||||
|
||||
In our docs, we have used this guideline to craft a unique set of docs which include [getting started](../../getting-started.md), [how-to guides](../../how-to-guides.md) (including [new](../../pages-for-subheaders/new-user-guides.md) and [advanced user guides](../../pages-for-subheaders/advanced-user-guides.md)), [reference guides](../../reference-guides.md), [explanations](../../explanations.md), an [FAQ section](../../faq.md), [troubleshooting tips](../../troubleshooting.md), and the ability to [contribute to Rancher](../../contribute-to-rancher.md).
|
||||
|
||||
- [Getting Started](#getting-started)
|
||||
- [How-to Guides](#how-to-guides)
|
||||
- [New User Guides](#new-user-guides)
|
||||
- [Advanced User Guides](#advanced-user-guides)
|
||||
- [Reference Guides](#reference-guides)
|
||||
- [Explanations](#explanations)
|
||||
- [Integrations in Rancher](#integrations-in-rancher)
|
||||
- [Other Docs Categories](#other-docs-categories)
|
||||
- [FAQ](#faq)
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
- [Contribute to Rancher](#contribute-to-rancher)
|
||||
- [Overlapping of Categories](#overlapping-of-categories)
|
||||
- [New Structure Goals](#new-structure-goals)
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ Deploying to Amazon AWS will incur charges.
|
||||
|
||||
The AWS module just creates an EC2 KeyPair, an EC2 SecurityGroup and an EC2 instance. A simple policy would be:
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
@@ -50,17 +50,18 @@ The AWS module just creates an EC2 KeyPair, an EC2 SecurityGroup and an EC2 inst
|
||||
3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
|
||||
|
||||
4. Edit `terraform.tfvars` and customize the following variables:
|
||||
|
||||
- `aws_access_key` - Amazon AWS Access Key
|
||||
- `aws_secret_key` - Amazon AWS Secret Key
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
|
||||
5. **Optional:** Modify optional variables within `terraform.tfvars`.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) for more information.
|
||||
5. **Optional:** Modify optional variables within `terraform.tfvars`. See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) for more information.
|
||||
Suggestions include:
|
||||
- `aws_region` - Amazon AWS region, choose the closest instead of the default (`us-east-1`)
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `instance_type` - EC2 instance size used, minimum is `t3a.medium` but `t3a.large` or `t3a.xlarge` could be used if within budget
|
||||
- `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster
|
||||
|
||||
- `aws_region` - Amazon AWS region, choose the closest instead of the default (`us-east-1`)
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `instance_type` - EC2 instance size used, minimum is `t3a.medium` but `t3a.large` or `t3a.xlarge` could be used if within budget
|
||||
- `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster
|
||||
|
||||
6. Run `terraform init`.
|
||||
|
||||
|
||||
@@ -43,13 +43,12 @@ Deploying to Microsoft Azure will incur charges.
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
|
||||
5. **Optional:** Modify optional variables within `terraform.tfvars`.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) for more information.
|
||||
Suggestions include:
|
||||
- `azure_location` - Microsoft Azure region, choose the closest instead of the default (`East US`)
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `instance_type` - Compute instance size used, minimum is `Standard_DS2_v2` but `Standard_DS2_v3` or `Standard_DS3_v2` could be used if within budget
|
||||
- `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster
|
||||
- `windows_admin_password` - The admin password of the windows worker node
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) for more information. Suggestions include:
|
||||
- `azure_location` - Microsoft Azure region, choose the closest instead of the default (`East US`)
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `instance_type` - Compute instance size used, minimum is `Standard_DS2_v2` but `Standard_DS2_v3` or `Standard_DS3_v2` could be used if within budget
|
||||
- `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster
|
||||
- `windows_admin_password` - The admin password of the windows worker node
|
||||
|
||||
6. Run `terraform init`.
|
||||
|
||||
|
||||
@@ -37,11 +37,10 @@ Deploying to DigitalOcean will incur charges.
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
|
||||
5. **Optional:** Modify optional variables within `terraform.tfvars`.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) for more information.
|
||||
Suggestions include:
|
||||
- `do_region` - DigitalOcean region, choose the closest instead of the default (`nyc1`)
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `droplet_size` - Droplet size used, minimum is `s-2vcpu-4gb` but `s-4vcpu-8gb` could be used if within budget
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) for more information. Suggestions include:
|
||||
- `do_region` - DigitalOcean region, choose the closest instead of the default (`nyc1`)
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `droplet_size` - Droplet size used, minimum is `s-2vcpu-4gb` but `s-4vcpu-8gb` could be used if within budget
|
||||
|
||||
6. Run `terraform init`.
|
||||
|
||||
|
||||
@@ -20,18 +20,6 @@ The intent of these guides is to quickly launch a sandbox that you can use to ev
|
||||
|
||||
This Quick Start Guide is divided into different tasks for easier consumption.
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
|
||||
1. [Provision a Equinix Metal Host](#1-provision-a-equinix-metal-host)
|
||||
|
||||
1. [Install Rancher](#2-install-rancher)
|
||||
|
||||
1. [Log In](#3-log-in)
|
||||
|
||||
1. [Create the Cluster](#4-create-the-cluster)
|
||||
|
||||
<!-- /TOC -->
|
||||
<br/>
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -40,10 +40,10 @@ Deploying to Google GCP will incur charges.
|
||||
5. **Optional:** Modify optional variables within `terraform.tfvars`.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp) for more information.
|
||||
Suggestions include:
|
||||
- `gcp_region` - Google GCP region, choose the closest instead of the default (`us-east4`)
|
||||
- `gcp_zone` - Google GCP zone, choose the closest instead of the default (`us-east4-a`)
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `machine_type` - Compute instance size used, minimum is `n1-standard-1` but `n1-standard-2` or `n1-standard-4` could be used if within budget
|
||||
- `gcp_region` - Google GCP region, choose the closest instead of the default (`us-east4`)
|
||||
- `gcp_zone` - Google GCP zone, choose the closest instead of the default (`us-east4-a`)
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `machine_type` - Compute instance size used, minimum is `n1-standard-1` but `n1-standard-2` or `n1-standard-4` could be used if within budget
|
||||
|
||||
6. Run `terraform init`.
|
||||
|
||||
|
||||
@@ -39,9 +39,10 @@ Deploying to Hetzner Cloud will incur charges.
|
||||
5. **Optional:** Modify optional variables within `terraform.tfvars`.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Hetzner Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/hcloud) for more information.
|
||||
Suggestions include:
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `instance_type` - Instance type, minimum required is `cx21`
|
||||
- `hcloud_location` - Hetzner Cloud location, choose the closest instead of the default (`fsn1`)
|
||||
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `instance_type` - Instance type, minimum required is `cx21`
|
||||
- `hcloud_location` - Hetzner Cloud location, choose the closest instead of the default (`fsn1`)
|
||||
|
||||
6. Run `terraform init`.
|
||||
|
||||
|
||||
@@ -45,7 +45,7 @@ From the **Workloads** page, click the link underneath your workload. If your de
|
||||
|
||||
When using a cloud-hosted virtual machine, you may not have access to the port running the container. In this event, you can test Nginx in an ssh session on the local machine using `Execute Shell`. Use the port number after the `:` in the link under your workload if available, which is `31568` in this example.
|
||||
|
||||
```sh
|
||||
```html
|
||||
gettingstarted@rancher:~$ curl http://localhost:31568
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
|
||||
@@ -28,7 +28,6 @@ For this workload, you'll be deploying the application Rancher Hello-World.
|
||||
* Your workload is deployed. This process might take a few minutes to complete.
|
||||
* When your workload completes deployment, it's assigned a state of **Active**. You can view this status from the project's **Workloads** page.
|
||||
|
||||
<br/>
|
||||
### 2. Expose The Application Via An Ingress
|
||||
|
||||
Now that the application is up and running, it needs to be exposed so that other services can connect.
|
||||
|
||||
Reference in New Issue
Block a user