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

Fix tabs: add import statements, specify value, spacing

Browse Source
This commit is contained in:
Billy Tat
2022-07-14 20:14:23 -07:00
parent afbabffdeb
commit c55f4b2931
122 changed files with 1162 additions and 712 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/en/admin-settings/authentication/keycloak-saml/keycloak-saml.md
+9 -4
View File
@@ -4,6 +4,9 @@ description: Create a Keycloak SAML client and configure Rancher to work with Ke
weight: 1200
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
If your organization uses Keycloak Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
## Prerequisites
@@ -35,11 +38,13 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati
## Getting the IDP Metadata
<Tabs>
<TabItem label="Keycloak 5 and earlier">
<TabItem value="Keycloak 5 and earlier">
To get the IDP metadata, export a `metadata.xml` file from your Keycloak client.
From the **Installation** tab, choose the **SAML Metadata IDPSSODescriptor** format option and download your file.
</TabItem>
<TabItem label="Keycloak 6-13">
<TabItem value="Keycloak 6-13">
1. From the **Configure** section, click the **Realm Settings** tab.
1. Click the **General** tab.
@@ -78,7 +83,7 @@ You are left with something similar as the example below:
```
</TabItem>
<TabItem label="Keycloak 14+">
<TabItem value="Keycloak 14+">
1. From the **Configure** section, click the **Realm Settings** tab.
1. Click the **General** tab.
@@ -117,7 +122,7 @@ The following is an example process for Firefox, but will vary slightly for othe
Rancher redirects you to the IdP login page. Enter credentials that authenticate with Keycloak IdP to validate your Rancher Keycloak configuration.
:::note
You may have to disable your popup blocker to see the IdP login page.
:::
docs/en/admin-settings/branding/branding.md
+13 -6
View File
@@ -3,6 +3,9 @@ title: Custom Branding
weight: 90
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Rancher v2.6 introduced the ability to customize Rancher’s branding and navigation links.
- [Changing Brand Settings](#changing-brand-settings)
@@ -19,7 +22,7 @@ You will need to have at least cluster member permissions.
:::
To configure the brand settings,
To configure the brand settings,
1. Click **☰ > Global settings**.
2. Click **Branding**.
@@ -45,10 +48,13 @@ You can override the primary color used throughout the UI with a custom color of
### Fixed Banners
<Tabs>
<TabItem label="Rancher before v2.6.4">
<TabItem value="Rancher before v2.6.4">
Display a custom fixed banner in the header, footer, or both.
</TabItem>
<TabItem label="Rancher v2.6.4+">
<TabItem value="Rancher v2.6.4+">
Display a custom fixed banner in the header, footer, or both.
As of Rancher v2.6.4, configuration of fixed banners has moved from the **Branding** tab to the **Banners** tab.
@@ -57,12 +63,13 @@ To configure banner settings,
1. Click **☰ > Global settings**.
2. Click **Banners**.
</TabItem>
</Tabs>
# Custom Navigation Links
In this section, you'll learn how to configure the links in the left navigation bar of the **Cluster Dashboard**. To get to the cluster dashboard,
In this section, you'll learn how to configure the links in the left navigation bar of the **Cluster Dashboard**. To get to the cluster dashboard,
1. In the upper left corner, click **☰ > Cluster Management**.
1. On the **Clusters** page, go to the cluster where you want custom navigation links and click **Explore**.
@@ -96,7 +103,7 @@ You will need to have at least cluster member or project member permissions.
# Link Configuration
### `name`
### `name`
Display name for the link. Required.
@@ -124,7 +131,7 @@ data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAMgAAADICAYAAACtWK6eAAAgAElEQVR4Ae
A Kubernetes annotation for the NavLink custom resource.
### `label`
### `label`
A Kubernetes label for the NavLink custom resource.
docs/en/admin-settings/rbac/cluster-project-roles/cluster-project-roles.md
+12 -5
View File
@@ -3,6 +3,9 @@ title: Cluster and Project Roles
weight: 1127
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Cluster and project roles define user authorization inside a cluster or project.
To manage these roles,
@@ -16,7 +19,7 @@ The projects and clusters accessible to non-administrative users is determined b
When you create a cluster or project, Rancher automatically assigns you as the `Owner` for it. Users assigned the `Owner` role can assign other users roles in the cluster or project.
:::note
:::note
Non-administrative users cannot access any existing projects/clusters by default. A user with appropriate permissions (typically the owner) must explicitly assign the project and cluster membership.
@@ -89,21 +92,25 @@ To assign a custom role to a new cluster member, you can use the Rancher UI. To
To assign the role to a new cluster member,
<Tabs>
<TabItem label="Rancher before v2.6.4">
<TabItem value="Rancher before v2.6.4">
1. Click **☰ > Cluster Management**.
1. Go to the cluster where you want to assign a role to a member and click **Explore**.
1. Click **RBAC > Cluster Members**.
1. Click **Add**.
1. In the **Cluster Permissions** section, choose the custom cluster role that should be assigned to the member.
1. Click **Create**.
</TabItem>
<TabItem label="Rancher v2.6.4+">
<TabItem value="Rancher v2.6.4+">
1. Click **☰ > Cluster Management**.
1. Go to the cluster where you want to assign a role to a member and click **Explore**.
1. Click **Cluster > Cluster Members**.
1. Click **Add**.
1. In the **Cluster Permissions** section, choose the custom cluster role that should be assigned to the member.
1. Click **Create**.
</TabItem>
</Tabs>
@@ -131,7 +138,7 @@ _Project roles_ are roles that can be used to grant users access to a project. T
These users can manage project-scoped resources like namespaces and workloads, but cannot manage other project members.
:::note
By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
:::
@@ -141,7 +148,7 @@ _Project roles_ are roles that can be used to grant users access to a project. T
These users can view everything in the project but cannot create, update, or delete anything.
:::note danger
Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `owner` or `member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
:::
docs/en/api/api.md
+6 -3
View File
@@ -3,19 +3,22 @@ title: API
weight: 24
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
## How to use the API
The API has its own user interface accessible from a web browser. This is an easy way to see resources, perform actions, and see the equivalent cURL or HTTP request & response. To access it:
<Tabs>
<TabItem label="Rancher v2.6.4+">
<TabItem value="Rancher v2.6.4+">
1. Click on your user avatar in the upper right corner.
1. Click on your user avatar in the upper right corner.
1. Click **Account & API Keys**.
1. Under the **API Keys** section, find the **API Endpoint** field and click the link. The link will look something like `https://<RANCHER_FQDN>/v3`, where `<RANCHER_FQDN>` is the fully qualified domain name of your Rancher deployment.
</TabItem>
<TabItem label="Rancher before v2.6.4">
<TabItem value="Rancher before v2.6.4">
Go to the URL endpoint at `https://<RANCHER_FQDN>/v3`, where `<RANCHER_FQDN>` is the fully qualified domain name of your Rancher deployment.
docs/en/cluster-admin/certificate-rotation/certificate-rotation.md
+7 -4
View File
@@ -3,6 +3,9 @@ title: Certificate Rotation
weight: 2040
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
:::caution
Rotating Kubernetes certificates may result in your cluster being temporarily unavailable as components are restarted. For production environments, it's recommended to perform this action during a maintenance window.
@@ -14,7 +17,7 @@ By default, Kubernetes clusters require certificates and Rancher launched Kubern
Certificates can be rotated for the following services:
<Tabs>
<TabItem label="RKE">
<TabItem value="RKE">
- etcd
- kubelet (node certificate)
@@ -25,7 +28,7 @@ Certificates can be rotated for the following services:
- kube-controller-manager
</TabItem>
<TabItem label="RKE2">
<TabItem value="RKE2">
- admin
- api-server
@@ -66,12 +69,12 @@ Rancher launched Kubernetes clusters have the ability to rotate the auto-generat
### Additional Notes
<Tabs>
<TabItem label="RKE">
<TabItem value="RKE">
Even though the RKE CLI can use custom certificates for the Kubernetes cluster components, Rancher currently doesn't allow the ability to upload these in Rancher launched Kubernetes clusters.
</TabItem>
<TabItem label="RKE2">
<TabItem value="RKE2">
In RKE2, both etcd and control plane nodes are treated as the same `server` concept. As such, when rotating certificates of services specific to either of these components will result in certificates being rotated on both. The certificates will only change for the specified service, but you will see nodes for both components go into an updating state. You may also see worker only nodes go into an updating state. This is to restart the workers after a certificate change to ensure they get the latest client certs.
docs/en/cluster-admin/cleaning-cluster-nodes/cleaning-cluster-nodes.md
+8 -3
View File
@@ -4,6 +4,9 @@ description: Learn about cluster cleanup when removing nodes from your Rancher-l
weight: 2055
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes how to disconnect a node from a Rancher-launched Kubernetes cluster and remove all of the Kubernetes components from the node. This process allows you to use the node for other purposes.
When you use Rancher to install Kubernetes on new nodes in an infrastructure provider, resources (containers/virtual network interfaces) and configuration items (certificates/configuration files) are created.
@@ -60,7 +63,8 @@ For registered clusters, the process for removing Rancher is a little different.
After the registered cluster is detached from Rancher, the cluster's workloads will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
<Tabs>
<TabItem label="By UI / API">
<TabItem value="By UI / API">
:::danger
This process will remove data from your cluster. Make sure you have created a backup of files you want to keep before executing the command, as data will be lost.
@@ -78,7 +82,8 @@ After you initiate the removal of a registered cluster using the Rancher UI (or
**Result:** All components listed for registered clusters in [What Gets Removed?](#what-gets-removed) are deleted.
</TabItem>
<TabItem label="By Script">
<TabItem value="By Script">
Rather than cleaning registered cluster nodes using the Rancher UI, you can run a script instead.
:::note Prerequisite:
@@ -102,7 +107,7 @@ Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
1. From the same directory, run the script and provide the `rancher/rancher-agent` image version which should be equal to the version of Rancher used to manage the cluster. (`<RANCHER_VERSION>`):
:::tip
Add the `-dry-run` flag to preview the script's outcome without making changes.
```
./user-cluster.sh rancher/rancher-agent:<RANCHER_VERSION>
docs/en/cluster-provisioning/node-requirements/node-requirements.md
+8 -4
View File
@@ -3,6 +3,9 @@ title: Node Requirements for Rancher Managed Clusters
weight: 1
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This page describes the requirements for the Rancher managed Kubernetes clusters where your apps and services will be installed. These downstream clusters should be separate from the three-node cluster running Rancher.
:::note
@@ -37,7 +40,7 @@ Some distributions of Linux derived from RHEL, including Oracle Linux, may have
:::note
In RHEL 8.4, two extra services are included on the NetworkManager: `nm-cloud-setup.service` and `nm-cloud-setup.timer`. These services add a routing table that interferes with the CNI plugin's configuration. If these services are enabled, you must disable them using the command below, and then reboot the node to restore connectivity:
```
systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
reboot
@@ -54,7 +57,7 @@ SUSE Linux may have a firewall that blocks all ports by default. In that situati
When [Launching Kubernetes with Rancher]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) using Flatcar Container Linux nodes, it is required to use the following configuration in the [Cluster Config File]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options/#cluster-config-file)
<Tabs>
<TabItem label="Canal">
<TabItem value="Canal">
```yaml
rancher_kubernetes_engine_config:
@@ -69,9 +72,9 @@ rancher_kubernetes_engine_config:
extra_args:
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
```
</TabItem>
<TabItem label="Calico">
</TabItem>
<TabItem value="Calico">
```yaml
rancher_kubernetes_engine_config:
@@ -86,6 +89,7 @@ rancher_kubernetes_engine_config:
extra_args:
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
```
</TabItem>
</Tabs>
docs/en/cluster-provisioning/rke-clusters/node-pools/azure/azure.md
+5 -2
View File
@@ -4,6 +4,9 @@ shortTitle: Azure
weight: 2220
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you'll learn how to install an [RKE]({{<baseurl>}}/rke/latest/en/) Kubernetes cluster in Azure through Rancher.
First, you will set up your Azure cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in Azure.
@@ -48,7 +51,7 @@ The creation of this service principal returns three pieces of identification in
# Creating an Azure Cluster
<Tabs>
<TabItem label="RKE">
<TabItem value="RKE">
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
@@ -89,7 +92,7 @@ Use Rancher to create a Kubernetes cluster in Azure.
1. Click **Create**.
</TabItem>
<TabItem label="RKE2">
<TabItem value="RKE2">
### 1. Create your cloud credentials
docs/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/digital-ocean.md
+6 -2
View File
@@ -3,6 +3,10 @@ title: Creating a DigitalOcean Cluster
shortTitle: DigitalOcean
weight: 2215
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in DigitalOcean.
First, you will set up your DigitalOcean cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in DigitalOcean.
@@ -10,7 +14,7 @@ First, you will set up your DigitalOcean cloud credentials in Rancher. Then you
Then you will create a DigitalOcean cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
<Tabs>
<TabItem label="RKE">
<TabItem value="RKE">
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
@@ -49,7 +53,7 @@ Creating a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rk
1. Click **Create**.
</TabItem>
<TabItem label="RKE2">
<TabItem value="RKE2">
### 1. Create your cloud credentials
docs/en/cluster-provisioning/rke-clusters/node-pools/ec2/ec2.md
+9 -5
View File
@@ -4,6 +4,10 @@ shortTitle: Amazon EC2
description: Learn the prerequisites and steps required in order for you to create an Amazon EC2 cluster using Rancher
weight: 2210
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in Amazon EC2.
First, you will set up your EC2 cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in EC2.
@@ -24,7 +28,7 @@ Then you will create an EC2 cluster in Rancher, and when configuring the new clu
The steps to create a cluster differ based on your Rancher version.
<Tabs>
<TabItem label="RKE">
<TabItem value="RKE">
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
2. [Create a node template with your cloud credentials and information from EC2](#2-create-a-node-template-with-your-cloud-credentials-and-information-from-ec2)
@@ -54,7 +58,7 @@ Creating a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rk
1. Click **Create**.
:::note
If you want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) that must be taken into consideration.
:::
@@ -71,15 +75,15 @@ Add one or more node pools to your cluster. For more information about node pool
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. Refer to [Selecting Cloud Providers]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/) to configure the Kubernetes Cloud Provider. For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options)
:::note
If you want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) that must be taken into consideration.
:::
1. Click **Create**.
</TabItem>
<TabItem label="RKE2">
<TabItem value="RKE2">
### 1. Create your cloud credentials
docs/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
+7 -4
View File
@@ -4,6 +4,9 @@ description: Learn how to install Rancher in development and production environm
weight: 2
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you'll learn how to deploy Rancher on a Kubernetes cluster using the Helm CLI.
- [Prerequisites](#prerequisites)
@@ -179,8 +182,7 @@ This final command to install Rancher requires a domain name that forwards traff
:::
<Tabs>
<TabItem label="Rancher-generated Certificates">
<TabItem value="Rancher-generated Certificates">
The default is for Rancher to generate a CA and uses `cert-manager` to issue the certificate for access to the Rancher server interface.
@@ -207,7 +209,7 @@ deployment "rancher" successfully rolled out
```
</TabItem>
<TabItem label="Let's Encrypt">
<TabItem value="Let's Encrypt">
This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA.
@@ -245,7 +247,7 @@ deployment "rancher" successfully rolled out
```
</TabItem>
<TabItem label="Certificates from Files">
<TabItem value="Certificates from Files">
In this option, Kubernetes secrets are created from your own certificates for Rancher to use.
When you run this command, the `hostname` option must match the `Common Name` or a `Subject Alternative Names` entry in the server certificate or the Ingress controller will fail to configure correctly.
@@ -283,6 +285,7 @@ helm install rancher rancher-<CHART_REPO>/rancher \
```
Now that Rancher is deployed, see [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.6/en/installation/resources/tls-secrets/) to publish the certificate files so Rancher and the Ingress controller can use them.
</TabItem>
</Tabs>
docs/en/installation/other-installation-methods/air-gap/launch-kubernetes/launch-kubernetes.md
+10 -4
View File
@@ -3,6 +3,9 @@ title: '3. Install Kubernetes (Skip for Docker Installs)'
weight: 300
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
:::note
Skip this section if you are installing Rancher on a single node with Docker.
@@ -16,7 +19,7 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes
The steps to set up an air-gapped Kubernetes cluster on RKE, RKE2, or K3s are shown below.
<Tabs>
<TabItem label="K3s">
<TabItem value="K3s">
In this guide, we are assuming you have created your nodes in your air gapped environment and have a secure Docker private registry on your bastion server.
@@ -100,7 +103,7 @@ K3s additionally provides a `--resolv-conf` flag for kubelets, which may help wi
When you installed K3s on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/k3s/k3s.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
To use this `kubeconfig` file,
To use this `kubeconfig` file,
1. Install [kubectl,](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) a Kubernetes command-line tool.
2. Copy the file at `/etc/rancher/k3s/k3s.yaml` and save it to the directory `~/.kube/config` on your local machine.
@@ -143,8 +146,9 @@ Upgrading an air-gap environment can be accomplished in the following manner:
1. Download the new air-gap images (tar file) from the [releases](https://github.com/k3s-io/k3s/releases) page for the version of K3s you will be upgrading to. Place the tar in the `/var/lib/rancher/k3s/agent/images/` directory on each node. Delete the old tar file.
2. Copy and replace the old K3s binary in `/usr/local/bin` on each node. Copy over the install script at https://get.k3s.io (as it is possible it has changed since the last release). Run the script again just as you had done in the past with the same environment variables.
3. Restart the K3s service (if not restarted automatically by installer).
</TabItem>
<TabItem label="RKE2">
<TabItem value="RKE2">
In this guide, we are assuming you have created your nodes in your air-gapped environment and have a secure Docker private registry on your bastion server.
@@ -283,8 +287,9 @@ Upgrading an air-gap environment can be accomplished in the following manner:
1. Download the new air-gap artifacts and install script from the [releases](https://github.com/rancher/rke2/releases) page for the version of RKE2 you will be upgrading to.
2. Run the script again just as you had done in the past with the same environment variables.
3. Restart the RKE2 service.
</TabItem>
<TabItem label="RKE">
<TabItem value="RKE">
We will create a Kubernetes cluster using Rancher Kubernetes Engine (RKE). Before being able to start your Kubernetes cluster, you’ll need to install RKE and create a RKE config file.
### 1. Install RKE
@@ -363,6 +368,7 @@ Save a copy of the following files in a secure location:
- `rancher-cluster.yml`: The RKE cluster configuration file.
- `kube_config_cluster.yml`: The [Kubeconfig file]({{<baseurl>}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{<baseurl>}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains the current state of the cluster including the RKE configuration and the certificates.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
</TabItem>
</Tabs>
docs/en/installation/other-installation-methods/air-gap/populate-private-registry/populate-private-registry.md
+6 -3
View File
@@ -3,6 +3,9 @@ title: '2. Collect and Publish Images to your Private Registry'
weight: 200
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes how to set up your private registry so that when you install Rancher, Rancher will pull all the required images from this registry.
By default, all images used to [provision Kubernetes clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/) or launch any tools in Rancher, e.g. monitoring, pipelines, alerts, are pulled from Docker Hub. In an air gapped installation of Rancher, you will need a private registry that is located somewhere accessible by your Rancher server. Then, you will load the registry with all the images.
@@ -20,7 +23,7 @@ If the registry has certs, follow [this K3s documentation](https://rancher.com/d
:::
<Tabs>
<TabItem label="Linux Only Clusters">
<TabItem value="Linux Only Clusters">
For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
@@ -119,8 +122,9 @@ The `rancher-images.txt` is expected to be on the workstation in the same direct
```plain
./rancher-load-images.sh --image-list ./rancher-images.txt --registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
</TabItem>
<TabItem label="Linux and Windows Clusters">
<TabItem value="Linux and Windows Clusters">
For Rancher servers that will provision Linux and Windows clusters, there are distinctive steps to populate your private registry for the Windows images and the Linux images. Since a Windows cluster is a mix of Linux and Windows nodes, the Linux images pushed into the private registry are manifests.
@@ -304,7 +308,6 @@ The image list, `rancher-images.txt` or `rancher-windows-images.txt`, is expecte
--registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
</TabItem>
</Tabs>
docs/en/installation/other-installation-methods/air-gap/prepare-nodes/prepare-nodes.md
+8 -3
View File
@@ -3,6 +3,9 @@ title: '1. Set up Infrastructure and Private Registry'
weight: 100
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you will provision the underlying infrastructure for your Rancher management server in an air gapped environment. You will also set up the private Docker registry that must be available to your Rancher node(s).
An air gapped environment is an environment where the Rancher server is installed offline or behind a firewall.
@@ -12,7 +15,8 @@ The infrastructure depends on whether you are installing Rancher on a K3s Kubern
Rancher can be installed on any Kubernetes cluster. The RKE and K3s Kubernetes infrastructure tutorials below are still included for convenience.
<Tabs>
<TabItem label="K3s">
<TabItem value="K3s">
We recommend setting up the following infrastructure for a high-availability installation:
- **Two Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
@@ -85,8 +89,9 @@ Rancher supports air gap installs using a private registry. You must have your o
In a later step, when you set up your K3s Kubernetes cluster, you will create a [private registries configuration file]({{<baseurl>}}/k3s/latest/en/installation/private-registry/) with details from this registry.
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
</TabItem>
<TabItem label="RKE">
<TabItem value="RKE">
To install the Rancher management server on a high-availability RKE cluster, we recommend setting up the following infrastructure:
@@ -153,7 +158,7 @@ In a later step, when you set up your RKE Kubernetes cluster, you will create a
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
</TabItem>
<TabItem label="Docker">
<TabItem value="Docker">
:::note Notes:
docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+12 -8
View File
@@ -3,6 +3,9 @@ title: Upgrading Rancher Installed with Docker
weight: 1010
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The following instructions will guide you through upgrading a Rancher server that was installed with Docker.
:::caution
@@ -134,7 +137,7 @@ To see the command to use when starting the new Rancher server container, choose
- Docker Upgrade for Air Gap Installs
<Tabs>
<TabItem label="Docker Upgrade">
<TabItem value="Docker Upgrade">
Select which option you had installed Rancher server
@@ -166,7 +169,7 @@ Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
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.
:::note Reminder of the Cert Prerequisite:
:::note Reminder of the Cert Prerequisite:
The certificate files must be in PEM format. In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates.
@@ -201,7 +204,7 @@ Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
If you have selected to use a certificate signed by a recognized CA, 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 certificates that you had originally installed with. Remember to include `--no-cacerts` as an argument to the container to disable the default CA certificate generated by Rancher.
:::note Reminder of the Cert Prerequisite:
:::note Reminder of the Cert Prerequisite:
The certificate files must be in PEM format. In your certificate file, include all intermediate certificates provided by the recognized CA. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
@@ -240,7 +243,7 @@ Let's Encrypt provides rate limits for requesting new certificates. Therefore, l
If you have selected to use [Let's Encrypt](https://letsencrypt.org/) certificates, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to provide the domain that you had used when you originally installed Rancher.
:::note Reminder of the Cert Prerequisites:
:::note Reminder of the Cert Prerequisites:
- Create a record in your DNS that binds your Linux host IP address to the hostname that you want to use for Rancher access (`rancher.mydomain.com` for example).
- Open port `TCP/80` on your Linux host. The Let's Encrypt http-01 challenge can come from any source IP address, so port `TCP/80` must be open to all IP addresses.
@@ -266,7 +269,7 @@ Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
{{% /accordion %}}
</TabItem>
<TabItem label="Docker Air Gap Upgrade">
<TabItem value="Docker Air Gap Upgrade">
For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
@@ -302,7 +305,7 @@ Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
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.
:::note Reminder of the Cert Prerequisite:
:::note Reminder of the Cert Prerequisite:
The certificate files must be in PEM format. In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
@@ -337,8 +340,8 @@ Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
If you have selected to use a certificate signed by a recognized CA, 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 certificates that you had originally installed with.
:::note Reminder of the Cert Prerequisite:
:::note Reminder of the Cert Prerequisite:
The certificate files must be in PEM format. In your certificate file, include all intermediate certificates provided by the recognized CA. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
:::
@@ -371,6 +374,7 @@ docker run -d --volumes-from rancher-data \
```
privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
{{% /accordion %}}
</TabItem>
</Tabs>
docs/en/installation/requirements/ports/ports.md
+6 -2
View File
@@ -4,6 +4,9 @@ description: Read about port requirements needed in order for Rancher to operate
weight: 300
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes.
- [Rancher Nodes](#rancher-nodes)
@@ -301,7 +304,7 @@ When using the [AWS EC2 node driver]({{<baseurl>}}/rancher/v2.6/en/cluster-provi
SUSE Linux may have a firewall that blocks all ports by default. To open the ports needed for adding the host to a custom cluster,
<Tabs>
<TabItem label="SLES 15 / openSUSE Leap 15">
<TabItem value="SLES 15 / openSUSE Leap 15">
1. SSH into the instance.
1. Start YaST in text mode:
```
@@ -320,7 +323,7 @@ UDP Ports
1. When all required ports are enter, select **Accept**.
</TabItem>
<TabItem label="SLES 12 / openSUSE Leap 42">
<TabItem value="SLES 12 / openSUSE Leap 42">
1. SSH into the instance.
1. Edit /`etc/sysconfig/SuSEfirewall2` and open the required ports. In this example, ports 9796 and 10250 are also opened for monitoring:
```
@@ -332,6 +335,7 @@ UDP Ports
```
SuSEfirewall2
```
</TabItem>
</Tabs>
docs/en/installation/resources/choosing-version/choosing-version.md
+7 -3
View File
@@ -3,6 +3,9 @@ title: Choosing a Rancher Version
weight: 1
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes how to choose a Rancher version.
For a high-availability installation of Rancher, which is recommended for production, the Rancher server is installed using a **Helm chart** on a Kubernetes cluster. Refer to the [Helm version requirements]({{<baseurl>}}/rancher/v2.6/en/installation/resources/helm-version) to choose a version of Helm to install Rancher.
@@ -10,7 +13,7 @@ For a high-availability installation of Rancher, which is recommended for produc
For Docker installations of Rancher, which is used for development and testing, you will install Rancher as a **Docker image**.
<Tabs>
<TabItem label="Helm Charts">
<TabItem value="Helm Charts">
When installing, upgrading, or rolling back Rancher Server when it is [installed on a Kubernetes cluster]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/), Rancher server is installed using a Helm chart on a Kubernetes cluster. Therefore, as you prepare to install or upgrade a high availability Rancher configuration, you must add a Helm chart repository that contains the charts for installing Rancher.
@@ -81,8 +84,9 @@ Because the rancher-alpha repository contains only alpha charts, switching betwe
```
4. Continue to follow the steps to [upgrade Rancher]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/upgrades) from the new Helm chart repository.
</TabItem>
<TabItem label="Docker Images">
<TabItem value="Docker Images">
When performing [Docker installs]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker), upgrades, or rollbacks, you can use _tags_ to install a specific version of Rancher.
### Server Tags
@@ -102,5 +106,5 @@ Rancher Server is distributed as a Docker image, which have tags attached to the
:::
</TabItem>
</TabItem>
</Tabs>
docs/en/installation/resources/k8s-tutorials/gke/gke.md
+8 -4
View File
@@ -4,6 +4,9 @@ shortTitle: GKE
weight: 3
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you'll learn how to install Rancher using Google Kubernetes Engine.
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.]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/#install-the-rancher-helm-chart)
@@ -59,8 +62,8 @@ To install `gcloud` and `kubectl`, perform the following steps:
```
source ~/.bash_profile
```
# 3. Configure the gcloud CLI
@@ -70,7 +73,7 @@ To install `gcloud` and `kubectl`, perform the following steps:
- Using gcloud config, to individually set your project ID, zone, and region.
<Tabs>
<TabItem label="Using gcloud init">
<TabItem value="Using gcloud init">
1. Run gcloud init and follow the directions:
@@ -84,8 +87,9 @@ To install `gcloud` and `kubectl`, perform the following steps:
```
2. Follow the instructions to authorize gcloud to use your Google Cloud account and select the new project that you created.
</TabItem>
<TabItem label="Using gcloud config">
<TabItem value="Using gcloud config">
</TabItem>
</Tabs>
docs/en/monitoring-alerting/configuration/receiver/receiver.md
+5 -2
View File
@@ -4,6 +4,9 @@ shortTitle: Receivers
weight: 1
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configuration/#configuration-file) Secret contains the configuration of an Alertmanager instance that sends out notifications based on alerts it receives from Prometheus.
:::note
@@ -39,7 +42,7 @@ This section assumes familiarity with how monitoring components work together. F
To create notification receivers in the Rancher UI,
<Tabs>
<TabItem label="Rancher v2.6.5+">
<TabItem value="Rancher v2.6.5+">
1. Go to the cluster where you want to create receivers. Click **Monitoring -> Alerting -> AlertManagerConfigs**.
1. Ciick **Create**.
@@ -49,7 +52,7 @@ To create notification receivers in the Rancher UI,
1. Click **Create**.
</TabItem>
<TabItem label="Rancher before v2.6.5">
<TabItem value="Rancher before v2.6.5">
1. Go to the cluster where you want to create receivers. Click **Monitoring** and click **Receiver**.
2. Enter a name for the receiver.
docs/en/monitoring-alerting/configuration/route/route.md
+5 -2
View File
@@ -4,6 +4,9 @@ shortTitle: Routes
weight: 5
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The route configuration is the section of the Alertmanager custom resource that controls how the alerts fired by Prometheus are grouped and filtered before they reach the receiver.
When a Route is changed, the Prometheus Operator regenerates the Alertmanager custom resource to reflect the changes.
@@ -47,7 +50,7 @@ The route needs to refer to a [receiver](#receiver-configuration) that has alrea
### Grouping
<Tabs>
<TabItem label="Rancher v2.6.5+">
<TabItem value="Rancher v2.6.5+">
:::note
@@ -63,7 +66,7 @@ As of Rancher v2.6.5, `Group By` now accepts a list of strings instead of key-va
| Repeat Interval | 4h | How long to wait before re-sending a given alert that has already been sent. |
</TabItem>
<TabItem label="Rancher before v2.6.5">
<TabItem value="Rancher before v2.6.5">
| Field | Default | Description |
|-------|--------------|---------|
docs/en/monitoring-alerting/guides/persist-grafana/persist-grafana.md
+10 -7
View File
@@ -3,6 +3,9 @@ title: Persistent Grafana Dashboards
weight: 6
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
To allow the Grafana dashboard to persist after the Grafana instance restarts, add the dashboard configuration JSON into a ConfigMap. ConfigMaps also allow the dashboards to be deployed with a GitOps or CD based approach. This allows the dashboard to be put under version control.
- [Creating a Persistent Grafana Dashboard](#creating-a-persistent-grafana-dashboard)
@@ -11,7 +14,7 @@ To allow the Grafana dashboard to persist after the Grafana instance restarts, a
# Creating a Persistent Grafana Dashboard
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
:::note Prerequisites:
@@ -33,7 +36,7 @@ To use your own dashboard:
1. Log in to Grafana. Note: The default Admin username and password for the Grafana instance is `admin/prom-operator`. Alternative credentials can also be supplied on deploying or upgrading the chart.
:::note
Regardless of who has the password, in order to access the Grafana instance, you still need at least the <b>Manage Services</b> or <b>View Monitoring</b> permissions in the project that Rancher Monitoring is deployed into. Alternative credentials can also be supplied on deploying or upgrading the chart.
:::
@@ -43,7 +46,7 @@ To use your own dashboard:
### 2. Create a ConfigMap using the Grafana JSON model
Create a ConfigMap in the namespace that contains your Grafana Dashboards (e.g. cattle-dashboards by default).
Create a ConfigMap in the namespace that contains your Grafana Dashboards (e.g. cattle-dashboards by default).
The ConfigMap should look like this:
@@ -90,10 +93,10 @@ grafana.sidecar.dashboards.searchNamespace=ALL
Note that the RBAC roles exposed by the Monitoring chart to add Grafana Dashboards are still restricted to giving permissions for users to add dashboards in the namespace defined in `grafana.dashboards.namespace`, which defaults to `cattle-dashboards`.
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
:::note Prerequisites:
- The monitoring application needs to be installed.
- You must have the cluster-admin ClusterRole permission.
@@ -106,11 +109,11 @@ Note that the RBAC roles exposed by the Monitoring chart to add Grafana Dashboar
1. Log in to Grafana. Note: The default Admin username and password for the Grafana instance is `admin/prom-operator`. Alternative credentials can also be supplied on deploying or upgrading the chart.
:::note
Regardless of who has the password, cluster administrator permission in Rancher is still required to access the Grafana instance.
:::
1. Go to the dashboard that you want to persist. In the top navigation menu, go to the dashboard settings by clicking the gear icon.
1. In the left navigation menu, click **JSON Model**.
1. Copy the JSON data structure that appears.
docs/en/pipelines/pipelines.md
+12 -9
View File
@@ -3,6 +3,9 @@ title: Pipelines
weight: 10
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
:::note Notes
- As of Rancher v2.5, Git-based deployment pipelines are now deprecated. We recommend handling pipelines with Rancher Continuous Delivery powered by [Fleet]({{<baseurl>}}/rancher/v2.6/en/deploy-across-clusters/fleet). To get to Fleet in Rancher, click <b>☰ > Continuous Delivery</b>.
@@ -22,7 +25,7 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins
- Build your application from code to image.
- Validate your builds.
- Deploy your build images to your cluster.
- Run unit tests.
- Run unit tests.
- Run regression tests.
:::note
@@ -64,7 +67,7 @@ When you configure a pipeline in one of your projects, a namespace specifically
The pipeline's build engine. Because project users do not directly interact with Jenkins, it's managed and locked.
:::note
There is no option to use existing Jenkins deployments as the pipeline engine.
:::
@@ -78,7 +81,7 @@ When you configure a pipeline in one of your projects, a namespace specifically
Minio storage is used to store the logs for pipeline executions.
:::note
The managed Jenkins instance works statelessly, so don't worry about its data persistency. The Docker Registry and Minio instances use ephemeral volumes by default, which is fine for most use cases. If you want to make sure pipeline logs can survive node failures, you can configure persistent volumes for them, as described in [data persistency for pipeline components]({{<baseurl>}}/rancher/v2.6/en/pipelines/storage).
:::
@@ -120,7 +123,7 @@ Before you can start configuring a pipeline for your repository, you must config
Select your provider's tab below and follow the directions.
<Tabs>
<TabItem label="GitHub">
<TabItem value="GitHub">
1. In the upper left corner, click **☰ > Cluster Management**.
1. Go to the cluster where you want to configure pipelines and click **Explore**.
@@ -133,7 +136,7 @@ Select your provider's tab below and follow the directions.
1. Click **Authenticate**.
</TabItem>
<TabItem label="GitLab">
<TabItem value="GitLab">
1. In the upper left corner, click **☰ > Cluster Management**.
1. Go to the cluster where you want to configure pipelines and click **Explore**.
@@ -148,13 +151,13 @@ Select your provider's tab below and follow the directions.
:::note Notes:
1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
:::
</TabItem>
<TabItem label="Bitbucket Cloud">
<TabItem value="Bitbucket Cloud">
1. In the upper left corner, click **☰ > Cluster Management**.
1. Go to the cluster where you want to configure pipelines and click **Explore**.
@@ -167,7 +170,7 @@ Select your provider's tab below and follow the directions.
1. Click **Authenticate**.
</TabItem>
<TabItem label="Bitbucket Server">
<TabItem value="Bitbucket Server">
1. In the upper left corner, click **☰ > Cluster Management**.
1. Go to the cluster where you want to configure pipelines and click **Explore**.
@@ -231,7 +234,7 @@ Now that repositories are added to your project, you can start configuring the p
1. Set up the trigger rules for the pipeline.
1. Enter a **Timeout** for the pipeline.
1. Enter a **Timeout** for the pipeline.
1. When all the stages and steps are configured, click **Done**.
docs/en/pipelines/storage/storage.md
+35 -49
View File
@@ -3,6 +3,9 @@ title: Configuring Persistent Data for Pipeline Components
weight: 600
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The pipelines' internal Docker registry and the Minio workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.
This section assumes that you understand how persistent storage works in Kubernetes. For more information, refer to the section on [how storage works.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/volumes-and-storage/how-storage-works/)
@@ -27,35 +30,26 @@ This section assumes that you understand how persistent storage works in Kuberne
- **Add Volume > Use an existing persistent volume (claim)**
1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
<Tabs>
<TabItem label="Add a new persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
<Tabs>
<TabItem value="Add a new persistent volume">
1. Select a volume claim **Source**:
1. Enter a **Name** for the volume claim.
1. Select a volume claim **Source**:
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
</TabItem>
<TabItem value="Use an existing persistent volume">
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the dropdown.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
1. Click **Define**.
</TabItem>
<TabItem label="Use an existing persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the dropdown.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
</TabItem>
</Tabs>
</TabItem>
</Tabs>
1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container.
@@ -74,34 +68,26 @@ This section assumes that you understand how persistent storage works in Kuberne
- **Add Volume > Use an existing persistent volume (claim)**
1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
<Tabs>
<Tabs>
<TabItem value="Add a new persistent volume">
<TabItem label="Add a new persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
1. Enter a **Name** for the volume claim.
1. Select a volume claim **Source**:
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
1. Select a volume claim **Source**:
</TabItem>
<TabItem value="Use an existing persistent volume">
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
</TabItem>
<TabItem label="Use an existing persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
</TabItem>
</Tabs>
</TabItem>
</Tabs>
1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container.
docs/en/quick-start-guide/deployment/quickstart-manual-setup/quickstart-manual-setup.md
+8 -5
View File
@@ -3,6 +3,9 @@ title: Helm CLI Quick Start
weight: 300
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
These instructions capture a quick way to set up a proof-of-concept Rancher installation.
These instructions assume you have a Linux virtual machine that you will communicate with from your local workstation. Rancher will be installed on the Linux machine. You will need to retrieve the IP address of that machine so that you can access Rancher from your local workstation. Rancher is designed to manage Kubernetes clusters remotely, so any Kubernetes cluster that Rancher manages in the future will also need to be able to reach this IP address.
@@ -29,14 +32,14 @@ Save the IP of the Linux machine.
The kubeconfig file is important for accessing the Kubernetes cluster. Copy the file at `/etc/rancher/k3s/k3s.yaml` from the Linux machine and save it to your local workstation in the directory `~/.kube/config`. One way to do this is by using the `scp` tool and run this command on your local machine:
<Tabs>
<TabItem label="Mac and Linux">
<TabItem value="Mac and Linux">
```
scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml ~/.kube/config
```
</TabItem>
<TabItem label="Windows">
<TabItem value="Windows">
By default, "scp" is not a recognized command, so we need to install a module first.
@@ -58,7 +61,7 @@ scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml $env:USERPROFILE\.kube\
In the kubeconfig file, you will need to change the value of the `server` field to `<IP_OF_LINUX_NODE>:6443`. The Kubernetes API server will be reached at port 6443, while the Rancher server will be reached at ports 80 and 443. This edit is needed so that when you run Helm or kubectl commands from your local workstation, you will be able to communicate with the Kubernetes cluster that Rancher will be installed on.
<Tabs>
<TabItem label="Mac and Linux">
<TabItem value="Mac and Linux">
One way to open the kubeconfig file for editing is to use Vim:
@@ -68,8 +71,9 @@ vi ~/.kube/config
Press `i` to put Vim in insert mode. To save your work, press `Esc`. Then press `:wq` and press `Enter`.
</TabItem>
<TabItem label="Windows">
<TabItem value="Windows">
In Windows Powershell, you can use `notepad.exe` for editing the kubeconfig file:
@@ -79,7 +83,6 @@ notepad.exe $env:USERPROFILE\.kube\config
Once edited, either press `ctrl+s` or go to `File > Save` to save your work.
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/admin-settings/k8s-metadata/k8s-metadata.md
+13 -6
View File
@@ -3,6 +3,9 @@ title: Upgrading Kubernetes without Upgrading Rancher
weight: 1120
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
_Available as of v2.3.0_
The RKE metadata feature allows you to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. This feature is useful for taking advantage of patch versions of Kubernetes, for example, if you want to upgrade to Kubernetes v1.14.7 when your Rancher server originally supported v1.14.6.
@@ -11,7 +14,7 @@ The RKE metadata feature allows you to provision clusters with new versions of K
Rancher's Kubernetes metadata contains information specific to the Kubernetes version that Rancher uses to provision [RKE clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/). Rancher syncs the data periodically and creates custom resource definitions (CRDs) for **system images,** **service options** and **addon templates.** Consequently, when a new Kubernetes version is compatible with the Rancher server version, the Kubernetes metadata makes the new version available to Rancher for provisioning clusters. The metadata gives you an overview of the information that the [Rancher Kubernetes Engine]({{<baseurl>}}/rke/latest/en/) (RKE) uses for deploying various Kubernetes versions.
This table below describes the CRDs that are affected by the periodic data sync.
This table below describes the CRDs that are affected by the periodic data sync.
> **Note:** Only administrators can edit metadata CRDs. It is recommended not to update existing objects unless explicitly advised.
@@ -31,7 +34,7 @@ Administrators might configure the RKE metadata settings to do the following:
The option to refresh the Kubernetes metadata is available for administrators by default, or for any user who has the **Manage Cluster Drivers** [global role.]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/global-permissions/)
To force Rancher to refresh the Kubernetes metadata, a manual refresh action is available under **Tools > Drivers > Refresh Kubernetes Metadata** on the right side corner.
To force Rancher to refresh the Kubernetes metadata, a manual refresh action is available under **Tools > Drivers > Refresh Kubernetes Metadata** on the right side corner.
You can configure Rancher to only refresh metadata when desired by setting `refresh-interval-minutes` to `0` (see below) and using this button to perform the metadata refresh manually when desired.
@@ -44,7 +47,8 @@ The RKE metadata config controls how often Rancher syncs metadata and where it d
The way that the metadata is configured depends on the Rancher version.
<Tabs>
<TabItem label="Rancher v2.4+">
<TabItem value="Rancher v2.4+">
To edit the metadata config in Rancher,
1. Go to the **Global** view and click the **Settings** tab.
@@ -56,9 +60,11 @@ To edit the metadata config in Rancher,
If you don't have an air gap setup, you don't need to specify the URL where Rancher gets the metadata, because the default setting is to pull from [Rancher's metadata Git repository.](https://github.com/rancher/kontainer-driver-metadata/blob/dev-v2.5/data/data.json)
However, if you have an [air gap setup,](#air-gap-setups) you will need to mirror the Kubernetes metadata repository in a location available to Rancher. Then you need to change the URL to point to the new location of the JSON file.
However, if you have an [air gap setup,](#air-gap-setups) you will need to mirror the Kubernetes metadata repository in a location available to Rancher. Then you need to change the URL to point to the new location of the JSON file.
</TabItem>
<TabItem label="Rancher v2.3">
<TabItem value="Rancher v2.3">
To edit the metadata config in Rancher,
1. Go to the **Global** view and click the **Settings** tab.
@@ -67,11 +73,12 @@ To edit the metadata config in Rancher,
- `refresh-interval-minutes`: This is the amount of time that Rancher waits to sync the metadata. To disable the periodic refresh, set `refresh-interval-minutes` to 0.
- `url`: This is the HTTP path that Rancher fetches data from.
- `branch`: This refers to the Git branch name if the URL is a Git URL.
- `branch`: This refers to the Git branch name if the URL is a Git URL.
If you don't have an air gap setup, you don't need to specify the URL or Git branch where Rancher gets the metadata, because the default setting is to pull from [Rancher's metadata Git repository.](https://github.com/rancher/kontainer-driver-metadata.git)
However, if you have an [air gap setup,](#air-gap-setups) you will need to mirror the Kubernetes metadata repository in a location available to Rancher. Then you need to change the URL and Git branch in the `rke-metadata-config` settings to point to the new location of the repository.
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/admin-settings/rbac/default-custom-roles/default-custom-roles.md
+8 -5
View File
@@ -5,6 +5,9 @@ aliases:
- /rancher/v2.0-v2.4/en/tasks/global-configuration/roles/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Within Rancher, _roles_ determine what actions a user can make within a cluster or project.
Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access.
@@ -31,7 +34,7 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als
The steps to add custom roles differ depending on the version of Rancher.
<Tabs>
<TabItem label="Rancher v2.0.7+">
<TabItem value="Rancher v2.0.7+">
1. From the **Global** view, select **Security > Roles** from the main menu.
@@ -51,7 +54,7 @@ The steps to add custom roles differ depending on the version of Rancher.
1. Use the **Grant Resources** options to assign individual [Kubernetes API endpoints](https://kubernetes.io/docs/reference/) to the role.
> When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
> The Resource text field provides a method to search for pre-defined Kubernetes API resources, or enter a custom resource name for the grant. The pre-defined or `(Custom)` resource must be selected from the dropdown, after entering a resource name into this field.
You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign.
@@ -61,7 +64,7 @@ The steps to add custom roles differ depending on the version of Rancher.
1. Click **Create**.
</TabItem>
<TabItem label="Rancher before v2.0.7">
<TabItem value="Rancher before v2.0.7">
1. From the **Global** view, select **Security > Roles** from the main menu.
@@ -84,7 +87,7 @@ The steps to add custom roles differ depending on the version of Rancher.
1. Use the **Grant Resources** options to assign individual [Kubernetes API endpoints](https://kubernetes.io/docs/reference/) to the role.
> When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
> The Resource text field provides a method to search for pre-defined Kubernetes API resources, or enter a custom resource name for the grant. The pre-defined or `(Custom)` resource must be selected from the dropdown, after entering a resource name into this field.
You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign.
@@ -129,7 +132,7 @@ Custom global roles don't have to be based on existing roles. To create a custom
1. In the **Grant Resources** section, select the Kubernetes resource operations that will be enabled for users with the custom role.
> The Resource text field provides a method to search for pre-defined Kubernetes API resources, or enter a custom resource name for the grant. The pre-defined or `(Custom)` resource must be selected from the dropdown, after entering a resource name into this field.
1. Click **Save.**
## Deleting a Custom Global Role
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/backup/rke-backups/rke-backups.md
+9 -3
View File
@@ -13,6 +13,10 @@ aliases:
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/backup/rke-backups
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/backup/rke-backups/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes how to create backups of your high-availability Rancher install.
In an RKE installation, the cluster data is replicated on each of three etcd nodes in the cluster, providing redundancy and data duplication in case one of the nodes fails.
@@ -68,10 +72,10 @@ To take recurring snapshots, enable the `etcd-snapshot` service, which is a serv
The steps to enable recurring snapshots differ based on the version of RKE.
<Tabs>
<TabItem label="RKE v0.2.0+">
<TabItem value="RKE v0.2.0+">
1. Open `rancher-cluster.yml` with your favorite text editor.
2. Edit the code for the `etcd` service to enable recurring snapshots. Snapshots can be saved in a S3 compatible backend.
2. Edit the code for the `etcd` service to enable recurring snapshots. Snapshots can be saved in a S3 compatible backend.
```
services:
@@ -101,8 +105,9 @@ The steps to enable recurring snapshots differ based on the version of RKE.
```
**Result:** RKE is configured to take recurring snapshots of `etcd` on all nodes running the `etcd` role. Snapshots are saved locally to the following directory: `/opt/rke/etcd-snapshots/`. If configured, the snapshots are also uploaded to your S3 compatible backend.
</TabItem>
<TabItem label="RKE v0.1.x">
<TabItem value="RKE v0.1.x">
1. Open `rancher-cluster.yml` with your favorite text editor.
2. Edit the code for the `etcd` service to enable recurring snapshots.
@@ -122,6 +127,7 @@ The steps to enable recurring snapshots differ based on the version of RKE.
```
**Result:** RKE is configured to take recurring snapshots of `etcd` on all nodes running the `etcd` role. Snapshots are saved locally to the following directory: `/opt/rke/etcd-snapshots/`.
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/backing-up-etcd/backing-up-etcd.md
+8 -3
View File
@@ -3,6 +3,9 @@ title: Backing up a Cluster
weight: 2045
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
_Available as of v2.2.0_
In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) can be easily performed.
@@ -28,11 +31,11 @@ This section covers the following topics:
# How Snapshots Work
<Tabs>
<TabItem label="Rancher v2.4.0+">
<TabItem value="Rancher v2.4.0+">
### Snapshot Components
When Rancher creates a snapshot, it includes three components:
When Rancher creates a snapshot, it includes three components:
- The cluster data in etcd
- The Kubernetes version
@@ -85,7 +88,8 @@ On restore, the following process is used:
5. The cluster is restored and post-restore actions will be done in the cluster.
</TabItem>
<TabItem label="Rancher before v2.4.0">
<TabItem value="Rancher before v2.4.0">
When Rancher creates a snapshot, only the etcd data is included in the snapshot.
Because the Kubernetes version is not included in the snapshot, there is no option to restore a cluster to a different Kubernetes version.
@@ -128,6 +132,7 @@ On restore, the following process is used:
4. The other etcd nodes download the snapshot and validate the checksum so that they all use the same snapshot for the restore.
5. The cluster is restored and post-restore actions will be done in the cluster.
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/cleaning-cluster-nodes/cleaning-cluster-nodes.md
+7 -2
View File
@@ -4,6 +4,9 @@ description: Learn about cluster cleanup when removing nodes from your Rancher-l
weight: 2055
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes how to disconnect a node from a Rancher-launched Kubernetes cluster and remove all of the Kubernetes components from the node. This process allows you to use the node for other purposes.
When you use Rancher to install Kubernetes on new nodes in an infrastructure provider, resources (containers/virtual network interfaces) and configuration items (certificates/configuration files) are created.
@@ -56,7 +59,8 @@ For imported clusters, the process for removing Rancher is a little different. Y
After the imported cluster is detached from Rancher, the cluster's workloads will be unaffected and you can access the cluster using the same methods that you did before the cluster was imported into Rancher.
<Tabs>
<TabItem label="By UI / API">
<TabItem value="By UI / API">
>**Warning:** This process will remove data from your cluster. Make sure you have created a backup of files you want to keep before executing the command, as data will be lost.
After you initiate the removal of an imported cluster using the Rancher UI (or API), the following events occur.
@@ -70,7 +74,8 @@ After you initiate the removal of an imported cluster using the Rancher UI (or A
**Result:** All components listed for imported clusters in [What Gets Removed?](#what-gets-removed) are deleted.
</TabItem>
<TabItem label="By Script">
<TabItem value="By Script">
Rather than cleaning imported cluster nodes using the Rancher UI, you can run a script instead. This functionality is available since `v2.1.0`.
>**Prerequisite:**
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/nodes/nodes.md
+9 -3
View File
@@ -3,6 +3,9 @@ title: Nodes and Node Pools
weight: 2030
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab. Depending on the [option used]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/) to provision the cluster, there are different node options available.
> If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters]({{< baseurl >}}/rancher/v2.0-v2.4/en/cluster-admin/editing-clusters/#editing-clusters-with-yaml).
@@ -131,7 +134,8 @@ However, you can override the conditions draining when you initiate the drain. Y
The node draining options are different based on your version of Rancher.
<Tabs>
<TabItem label="Rancher v2.2.x+">
<TabItem value="Rancher v2.2.x+">
There are two drain modes: aggressive and safe.
- **Aggressive Mode**
@@ -143,8 +147,9 @@ There are two drain modes: aggressive and safe.
- **Safe Mode**
If a node has standalone pods or ephemeral data it will be cordoned but not drained.
</TabItem>
<TabItem label="Rancher before v2.2.x">
<TabItem value="Rancher before v2.2.x">
The following list describes each drain option:
@@ -159,6 +164,7 @@ The following list describes each drain option:
- **Even if there are pods using emptyDir**
If a pod uses emptyDir to store local data, you might not be able to safely delete it, since the data in the emptyDir will be deleted once the pod is removed from the node. Similar to the first option, Kubernetes expects the implementation to decide what to do with these pods. Choosing this option will delete these pods.
</TabItem>
</Tabs>
@@ -219,7 +225,7 @@ cattle.rancher.io/node-status: ignore
**Result:** If you add the node to a cluster, Rancher will not attempt to sync with this node. The node can still be part of the cluster and can be listed with `kubectl`.
If the label is added before the node is added to the cluster, the node will not be shown in the Rancher UI.
If the label is added before the node is added to the cluster, the node will not be shown in the Rancher UI.
If the label is added after the node is added to a Rancher cluster, the node will not be removed from the UI.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/restoring-etcd/restoring-etcd.md
+9 -6
View File
@@ -1,8 +1,11 @@
---
title: Restoring a Cluster from Backup
title: Restoring a Cluster from Backup
weight: 2050
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
_Available as of v2.2.0_
etcd backup and recovery for [Rancher launched Kubernetes clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) can be easily performed. Snapshots of the etcd database are taken and saved either locally onto the etcd nodes or to a S3 compatible target. The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.
@@ -33,7 +36,7 @@ If your Kubernetes cluster is broken, you can restore the cluster from a snapsho
Restores changed in Rancher v2.4.0.
<Tabs>
<TabItem label="Rancher v2.4.0+">
<TabItem value="Rancher v2.4.0+">
Snapshots are composed of the cluster data in etcd, the Kubernetes version, and the cluster configuration in the `cluster.yml.` These components allow you to select from the following options when restoring a cluster from a snapshot:
@@ -58,9 +61,9 @@ When rolling back to a prior Kubernetes version, the [upgrade strategy options](
**Result:** The cluster will go into `updating` state and the process of restoring the `etcd` nodes from the snapshot will start. The cluster is restored when it returns to an `active` state.
</TabItem>
<TabItem label="Rancher before v2.4.0">
<TabItem value="Rancher before v2.4.0">
> **Prerequisites:**
> **Prerequisites:**
>
> - Make sure your etcd nodes are healthy. If you are restoring a cluster with unavailable etcd nodes, it's recommended that all etcd nodes are removed from Rancher before attempting to restore. For clusters in which Rancher used node pools to provision [nodes in an infrastructure provider]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/), new etcd nodes will automatically be created. For [custom clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/custom-nodes/), please ensure that you add new etcd nodes to the cluster.
> - To restore snapshots from S3, the cluster needs to be configured to [take recurring snapshots on S3.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/backing-up-etcd/#configuring-recurring-snapshots)
@@ -71,7 +74,7 @@ When rolling back to a prior Kubernetes version, the [upgrade strategy options](
3. Select the snapshot that you want to use for restoring your cluster from the dropdown of available snapshots.
4. Click **Save**.
4. Click **Save**.
**Result:** The cluster will go into `updating` state and the process of restoring the `etcd` nodes from the snapshot will start. The cluster is restored when it returns to an `active` state.
@@ -106,7 +109,7 @@ If the group of etcd nodes loses quorum, the Kubernetes cluster will report a fa
5. Run the revised command.
6. After the single nodes is up and running, Rancher recommends adding additional etcd nodes to your cluster. If you have a [custom cluster]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/custom-nodes) and you want to reuse an old node, you are required to [clean up the nodes]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/cleaning-cluster-nodes/) before attempting to add them back into a cluster.
6. After the single nodes is up and running, Rancher recommends adding additional etcd nodes to your cluster. If you have a [custom cluster]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/custom-nodes) and you want to reuse an old node, you are required to [clean up the nodes]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/cleaning-cluster-nodes/) before attempting to add them back into a cluster.
# Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/upgrading-kubernetes/upgrading-kubernetes.md
+9 -2
View File
@@ -3,6 +3,9 @@ title: Upgrading and Rolling Back Kubernetes
weight: 70
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Following an upgrade to the latest version of Rancher, downstream Kubernetes clusters can be upgraded to use the latest supported version of Kubernetes.
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]({{<baseurl>}}/rke/latest/en/).
@@ -45,7 +48,8 @@ In this section of the [RKE documentation,]({{<baseurl>}}/rke/latest/en/upgrades
# Recommended Best Practice for Upgrades
<Tabs>
<TabItem label="Rancher v2.4+">
<TabItem value="Rancher v2.4+">
When upgrading the Kubernetes version of a cluster, we recommend that you:
1. Take a snapshot.
@@ -53,8 +57,10 @@ When upgrading the Kubernetes version of a cluster, we recommend that you:
1. If the upgrade fails, revert the cluster to the pre-upgrade Kubernetes version. This is achieved by selecting the **Restore etcd and Kubernetes version** option. This will return your cluster to the pre-upgrade kubernetes version before restoring the etcd snapshot.
The restore operation will work on a cluster that is not in a healthy or active state.
</TabItem>
<TabItem label="Rancher before v2.4">
<TabItem value="Rancher before v2.4">
When upgrading the Kubernetes version of a cluster, we recommend that you:
1. Take a snapshot.
@@ -62,6 +68,7 @@ When upgrading the Kubernetes version of a cluster, we recommend that you:
1. If the upgrade fails, restore the cluster from the etcd snapshot.
The cluster cannot be downgraded to a previous Kubernetes version.
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/node-requirements/node-requirements.md
+7 -3
View File
@@ -3,6 +3,9 @@ title: Node Requirements for Rancher Managed Clusters
weight: 1
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This page describes the requirements for the Rancher managed Kubernetes clusters where your apps and services will be installed. These downstream clusters should be separate from the three-node cluster running Rancher.
> If Rancher is installed on a high-availability Kubernetes cluster, the Rancher server three-node cluster and downstream clusters have different requirements. For Rancher installation requirements, refer to the node requirements in the [installation section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/requirements/)
@@ -39,7 +42,7 @@ SUSE Linux may have a firewall that blocks all ports by default. In that situati
When [Launching Kubernetes with Rancher]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) using Flatcar Container Linux nodes, it is required to use the following configuration in the [Cluster Config File]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/#cluster-config-file)
<Tabs>
<TabItem label="Canal">
<TabItem value="Canal">
```yaml
rancher_kubernetes_engine_config:
@@ -54,9 +57,9 @@ rancher_kubernetes_engine_config:
extra_args:
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
```
</TabItem>
<TabItem label="Calico">
</TabItem>
<TabItem value="Calico">
```yaml
rancher_kubernetes_engine_config:
@@ -71,6 +74,7 @@ rancher_kubernetes_engine_config:
extra_args:
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
```
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/azure/azure-node-template-config/azure-node-template-config.md
+8 -4
View File
@@ -3,12 +3,15 @@ title: Azure Node Template Configuration
weight: 1
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)
<Tabs>
<TabItem label="Rancher v2.2.0+">
<TabItem value="Rancher v2.2.0+">
Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
- **Placement** sets the geographical region where your cluster is hosted and other location metadata.
- **Network** configures the networking used in your cluster.
@@ -22,9 +25,9 @@ The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-d
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
</TabItem>
<TabItem label="Rancher before v2.2.0">
<TabItem value="Rancher before v2.2.0">
- **Account Access** stores your account information for authenticating with Azure.
- **Account Access** stores your account information for authenticating with Azure.
- **Placement** sets the geographical region where your cluster is hosted and other location metadata.
- **Network** configures the networking used in your cluster.
- **Instance** customizes your VM configuration.
@@ -35,5 +38,6 @@ The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-d
- **Docker Engine Install URL:** Determines what Docker version will be installed on the instance.
- **Registry mirrors:** Docker Registry mirror to be used by the Docker daemon
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/azure/azure.md
+16 -13
View File
@@ -6,9 +6,12 @@ aliases:
- /rancher/v2.0-v2.4/en/tasks/clusters/creating-a-cluster/create-cluster-azure/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you'll learn how to install an [RKE]({{<baseurl>}}/rke/latest/en/) Kubernetes cluster in Azure through Rancher.
First, you will set up your Azure cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in Azure.
First, you will set up your Azure cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in Azure.
Then you will create an Azure cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
@@ -27,31 +30,31 @@ For more information on configuring Azure node templates, refer to the [Azure no
- [Creating an Azure Cluster](#creating-an-azure-cluster)
# Preparation in Azure
Before creating a node template in Rancher using a cloud infrastructure such as Azure, we must configure Rancher to allow the manipulation of resources in an Azure subscription.
To do this, we will first create a new Azure **service principal (SP)** in Azure **Active Directory (AD)**, which, in Azure, is an application user who has permission to manage Azure resources.
The following is a template `az cli` script that you have to run for creating an service principal, where you have to enter your SP name, role, and scope:
```
az ad sp create-for-rbac \
--name="<Rancher ServicePrincipal name>" \
--role="Contributor" \
--scopes="/subscriptions/<subscription Id>"
```
The creation of this service principal returns three pieces of identification information, *The application ID, also called the client ID*, *The client secret*, and *The tenant ID*. This information will be used when you create a node template for Azure.
# Creating an Azure Cluster
<Tabs>
<TabItem label="Rancher v2.2.0+">
<TabItem value="Rancher v2.2.0+">
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
### 1. Create your cloud credentials
1. In the Rancher UI, click the user profile button in the upper right corner, and click **Cloud Credentials.**
@@ -61,7 +64,7 @@ The creation of this service principal returns three pieces of identification in
1. Enter your Azure credentials.
1. Click **Create.**
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
### 2. Create a node template with your cloud credentials
@@ -83,19 +86,19 @@ Use Rancher to create a Kubernetes cluster in Azure.
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
1. Review your options to confirm they're correct. Then click **Create**.
**Result:**
**Result:**
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
</TabItem>
<TabItem label="Rancher before v2.2.0">
<TabItem value="Rancher before v2.2.0">
Use Rancher to create a Kubernetes cluster in Azure.
@@ -104,16 +107,16 @@ Use Rancher to create a Kubernetes cluster in Azure.
1. Enter a **Cluster Name**.
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options.** For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options)
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. To create a node template, click **Add Node Template** and complete the **Azure Options** form. For help filling out the form, refer to the [Azure node template configuration reference.](./azure-node-template-config) For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. To create a node template, click **Add Node Template** and complete the **Azure Options** form. For help filling out the form, refer to the [Azure node template configuration reference.](./azure-node-template-config) For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
1. Review your options to confirm they're correct. Then click **Create**.
**Result:**
**Result:**
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/digital-ocean.md
+16 -10
View File
@@ -5,14 +5,19 @@ weight: 2215
aliases:
- /rancher/v2.0-v2.4/en/tasks/clusters/creating-a-cluster/create-cluster-digital-ocean/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in DigitalOcean.
First, you will set up your DigitalOcean cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in DigitalOcean.
First, you will set up your DigitalOcean cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in DigitalOcean.
Then you will create a DigitalOcean cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
<Tabs>
<TabItem label="Rancher v2.2.0+">
<TabItem value="Rancher v2.2.0+">
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
@@ -26,7 +31,7 @@ Then you will create a DigitalOcean cluster in Rancher, and when configuring the
1. Enter your Digital Ocean credentials.
1. Click **Create.**
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
### 2. Create a node template with your cloud credentials
@@ -43,41 +48,42 @@ Creating a [node template]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioni
1. Enter a **Cluster Name**.
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options.** For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options)
1. Add one or more node pools to your cluster. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
1. Add one or more node pools to your cluster. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
1. Review your options to confirm they're correct. Then click **Create**.
**Result:**
**Result:**
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
</TabItem>
<TabItem label="Rancher before v2.2.0">
<TabItem value="Rancher before v2.2.0">
1. From the **Clusters** page, click **Add Cluster**.
1. Choose **DigitalOcean**.
1. Enter a **Cluster Name**.
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options.** For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options)
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. To create a node template, click **Add Node Template** and complete the **Digital Ocean Options** form. For help filling out the form, refer to the [Digital Ocean node template configuration reference.](./do-node-template-config) For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. To create a node template, click **Add Node Template** and complete the **Digital Ocean Options** form. For help filling out the form, refer to the [Digital Ocean node template configuration reference.](./do-node-template-config) For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
1. Review your options to confirm they're correct. Then click **Create**.
**Result:**
**Result:**
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/do-node-template-config/do-node-template-config.md
+7 -2
View File
@@ -3,8 +3,11 @@ title: DigitalOcean Node Template Configuration
weight: 1
----
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
<Tabs>
<TabItem label="Rancher v2.2.0+">
<TabItem value="Rancher v2.2.0+">
Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
@@ -20,8 +23,9 @@ The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-d
- **Docker Engine Install URL:** Determines what Docker version will be installed on the instance.
- **Registry mirrors:** Docker Registry mirror to be used by the Docker daemon
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
</TabItem>
<TabItem label="Rancher before v2.2.0">
<TabItem value="Rancher before v2.2.0">
### Access Token
@@ -39,5 +43,6 @@ The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-d
- **Docker Engine Install URL:** Determines what Docker version will be installed on the instance.
- **Registry mirrors:** Docker Registry mirror to be used by the Docker daemon
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/ec2/ec2-node-template-config/ec2-node-template-config.md
+12 -8
View File
@@ -3,10 +3,13 @@ title: EC2 Node Template Configuration
weight: 1
---
For more details about EC2, nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
For more details about EC2, nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
<Tabs>
<TabItem label="Rancher v2.2.0+">
<TabItem value="Rancher v2.2.0+">
### Region
@@ -14,13 +17,13 @@ In the **Region** field, select the same region that you used when creating your
### Cloud Credentials
Your AWS account access information, stored in a [cloud credential.]({{<baseurl>}}/rancher/v2.0-v2.4/en/user-settings/cloud-credentials/)
Your AWS account access information, stored in a [cloud credential.]({{<baseurl>}}/rancher/v2.0-v2.4/en/user-settings/cloud-credentials/)
See [Amazon Documentation: Creating Access Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) how to create an Access Key and Secret Key.
See [Amazon Documentation: Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) how to create an IAM policy.
See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach an IAM
See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach an IAM
See our three example JSON policies:
@@ -30,7 +33,7 @@ See our three example JSON policies:
### Authenticate & Configure Nodes
Choose an availability zone and network settings for your cluster.
Choose an availability zone and network settings for your cluster.
### Security Group
@@ -49,7 +52,7 @@ If you need to pass an **IAM Instance Profile Name** (not ARN), for example, whe
In the **Engine Options** section of the node template, you can configure the Docker daemon. You may want to specify the docker version or a Docker registry mirror.
</TabItem>
<TabItem label="Rancher before v2.2.0">
<TabItem value="Rancher before v2.2.0">
### Account Access
@@ -59,7 +62,7 @@ See [Amazon Documentation: Creating Access Keys](https://docs.aws.amazon.com/IAM
See [Amazon Documentation: Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) how to create an IAM policy.
See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach an IAM
See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach an IAM
See our three example JSON policies:
@@ -72,7 +75,7 @@ See our three example JSON policies:
**Zone and Network** configures the availability zone and network settings for your cluster.
### Security Groups
**Security Groups** creates or configures the Security Groups applied to your nodes. Please refer to [Amazon EC2 security group when using Node Driver]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/requirements/ports/#rancher-aws-ec2-security-group) to see what rules are created in the `rancher-nodes` Security Group.
### Instance
@@ -95,5 +98,6 @@ The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-d
- **Docker Engine Install URL:** Determines what Docker version will be installed on the instance.
- **Registry mirrors:** Docker Registry mirror to be used by the Docker daemon
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/ec2/ec2.md
+13 -9
View File
@@ -4,9 +4,13 @@ shortTitle: Amazon EC2
description: Learn the prerequisites and steps required in order for you to create an Amazon EC2 cluster using Rancher
weight: 2210
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in Amazon EC2.
First, you will set up your EC2 cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in EC2.
First, you will set up your EC2 cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in EC2.
Then you will create an EC2 cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
@@ -26,7 +30,7 @@ Then you will create an EC2 cluster in Rancher, and when configuring the new clu
The steps to create a cluster differ based on your Rancher version.
<Tabs>
<TabItem label="Rancher v2.2.0+">
<TabItem value="Rancher v2.2.0+">
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
2. [Create a node template with your cloud credentials and information from EC2](#2-create-a-node-template-with-your-cloud-credentials-and-information-from-ec2)
@@ -42,7 +46,7 @@ The steps to create a cluster differ based on your Rancher version.
1. Enter your AWS EC2 **Access Key** and **Secret Key.**
1. Click **Create.**
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
### 2. Create a node template with your cloud credentials and information from EC2
@@ -59,24 +63,24 @@ Add one or more node pools to your cluster. For more information about node pool
1. From the **Clusters** page, click **Add Cluster**.
1. Choose **Amazon EC2**.
1. Enter a **Cluster Name**.
1. Create a node pool for each Kubernetes role. For each node pool, choose a node template that you created. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
1. Create a node pool for each Kubernetes role. For each node pool, choose a node template that you created. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools)
1. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. Refer to [Selecting Cloud Providers]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/cloud-providers/) to configure the Kubernetes Cloud Provider. For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options)
1. Click **Create**.
**Result:**
**Result:**
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
</TabItem>
<TabItem label="Rancher before v2.2.0">
<TabItem value="Rancher before v2.2.0">
1. From the **Clusters** page, click **Add Cluster**.
1. Choose **Amazon EC2**.
@@ -88,13 +92,13 @@ You can access your cluster after its state is updated to **Active.**
1. **Optional:** Add additional node pools.
1. Review your cluster settings to confirm they are correct. Then click **Create**.
**Result:**
**Result:**
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/provisioning-vsphere-clusters.md
+15 -9
View File
@@ -3,9 +3,13 @@ title: Provisioning Kubernetes Clusters in vSphere
weight: 1
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you'll learn how to use Rancher to install an [RKE]({{<baseurl>}}/rke/latest/en/) Kubernetes cluster in vSphere.
First, you will set up your vSphere cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision nodes in vSphere.
First, you will set up your vSphere cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision nodes in vSphere.
Then you will create a vSphere cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
@@ -51,7 +55,8 @@ If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https:
The a vSphere cluster is created in Rancher depends on the Rancher version.
<Tabs>
<TabItem label="Rancher v2.2.0+">
<TabItem value="Rancher v2.2.0+">
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
@@ -65,7 +70,7 @@ The a vSphere cluster is created in Rancher depends on the Rancher version.
1. Enter your vSphere credentials. For help, refer to **Account Access** in the [configuration reference for your Rancher version.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/)
1. Click **Create.**
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
### 2. Create a node template with your cloud credentials
@@ -91,18 +96,19 @@ Use Rancher to create a Kubernetes cluster in vSphere.
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to the nodes, see [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/#node-pools)
1. Review your options to confirm they're correct. Then click **Create**.
**Result:**
**Result:**
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
</TabItem>
<TabItem label="Rancher before v2.2.0">
<TabItem value="Rancher before v2.2.0">
Use Rancher to create a Kubernetes cluster in vSphere.
@@ -116,16 +122,16 @@ For Rancher versions before v2.0.4, when you create the cluster, you will also n
1. If you want to dynamically provision persistent storage or other infrastructure later, you will need to enable the vSphere cloud provider by modifying the cluster YAML file. For details, refer to [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere)
1. Add one or more [node pools]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) to your cluster. Each node pool uses a node template to provision new nodes. To create a node template, click **Add Node Template** and complete the **vSphere Options** form. For help filling out the form, refer to the vSphere node template configuration reference. Refer to the newest version of the configuration reference that is less than or equal to your Rancher version:
- [v2.0.4]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.0.4)
- [before v2.0.4]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/prior-to-2.0.4)
- [before v2.0.4]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/prior-to-2.0.4)
1. Review your options to confirm they're correct. Then click **Create** to start provisioning the VMs and Kubernetes services.
**Result:**
**Result:**
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/helm-charts/launching-apps/launching-apps.md
+7 -2
View File
@@ -6,6 +6,10 @@ aliases:
- /rancher/v2.0-v2.4/en/helm-charts/legacy-catalogs/launching-apps
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Within a project, when you want to deploy applications from catalogs, the applications available in your project will be based on the [scope of the catalogs]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/legacy-catalogs/#catalog-scopes).
If your application is using ingresses, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/globaldns/).
@@ -57,7 +61,7 @@ For each Helm chart, there are a list of desired answers that must be entered in
> For example, when entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is required to wrap the values with double quotes (i.e., ``"abc, bcd"``).
<Tabs>
<TabItem label="UI">
<TabItem value="UI">
### Using a questions.yml file
@@ -68,7 +72,7 @@ If the Helm chart that you are deploying contains a `questions.yml` file, Ranche
For native Helm charts (i.e., charts from the **Helm Stable** or **Helm Incubator** catalogs or a [custom Helm chart repository]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/legacy-catalogs/catalog-config/#custom-helm-chart-repository)), answers are provided as key value pairs in the **Answers** section. These answers are used to override the default values.
</TabItem>
<TabItem label="Editing YAML Files">
<TabItem value="Editing YAML Files">
_Available as of v2.1.0_
@@ -101,5 +105,6 @@ servers[0].host=example
_Available as of v2.2.0_
You can directly paste that YAML formatted structure into the YAML editor. By allowing custom values to be set using a YAML formatted structure, Rancher has the ability to easily customize for more complicated input values (e.g. multi-lines, array and JSON objects).
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
+14 -10
View File
@@ -6,13 +6,16 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/k8s-install/
- /rancher/v2.0-v2.4/en/installation/k8s-install/helm-rancher
- /rancher/v2.0-v2.4/en/installation/k8s-install/kubernetes-rke
- /rancher/v2.0-v2.4/en/installation/ha-server-install
- /rancher/v2.0-v2.4/en/installation/ha-server-install
- /rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/install
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
# Prerequisite
Set up the Rancher server's local Kubernetes cluster.
Set up the Rancher server's local Kubernetes cluster.
The cluster requirements depend on the Rancher version:
@@ -96,7 +99,7 @@ There are three recommended options for the source of the certificate used for T
### 5. Install cert-manager
> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/chart-options/#external-tls-termination).
> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/chart-options/#external-tls-termination).
This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
@@ -154,15 +157,14 @@ cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
The exact command to install Rancher differs depending on the certificate configuration.
<Tabs>
<TabItem label="Rancher-generated Certificates">
<TabItem value="Rancher-generated Certificates">
The default is for Rancher to generate a CA and uses `cert-manager` to issue the certificate for access to the Rancher server interface.
Because `rancher` is the default option for `ingress.tls.source`, we are not specifying `ingress.tls.source` when running the `helm install` command.
- Set the `hostname` to the DNS name you pointed at your load balancer.
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
- To install a specific Rancher version, use the `--version` flag, example: `--version 2.3.6`
```
@@ -180,7 +182,7 @@ deployment "rancher" successfully rolled out
```
</TabItem>
<TabItem label="Let's Encrypt">
<TabItem value="Let's Encrypt">
This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA.
@@ -189,7 +191,7 @@ In the following command,
- `hostname` is set to the public DNS record,
- `ingress.tls.source` is set to `letsEncrypt`
- `letsEncrypt.email` is set to the email address used for communication about your certificate (for example, expiry notices)
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
```
helm install rancher rancher-<CHART_REPO>/rancher \
@@ -208,7 +210,8 @@ deployment "rancher" successfully rolled out
```
</TabItem>
<TabItem label="Certificates from Files">
<TabItem value="Certificates from Files">
In this option, Kubernetes secrets are created from your own certificates for Rancher to use.
When you run this command, the `hostname` option must match the `Common Name` or a `Subject Alternative Names` entry in the server certificate or the Ingress controller will fail to configure correctly.
@@ -219,7 +222,7 @@ Although an entry in the `Subject Alternative Names` is technically required, ha
- Set the `hostname`.
- Set `ingress.tls.source` to `secret`.
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
```
helm install rancher rancher-<CHART_REPO>/rancher \
@@ -239,6 +242,7 @@ helm install rancher rancher-<CHART_REPO>/rancher \
```
Now that Rancher is deployed, see [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/encryption/tls-secrets/) to publish the certificate files so Rancher and the Ingress controller can use them.
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/helm2/helm2.md
+8 -6
View File
@@ -10,20 +10,23 @@ aliases:
- /rancher/v2.x/en/installation/install-rancher-on-k8s/upgrades/helm2/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
> Helm 3 has been released. If you are using Helm 2, we recommend [migrating to Helm 3](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) because it is simpler to use and more secure than Helm 2.
>
> The [current instructions for Upgrading Rancher Installed on Kubernetes](https://rancher.com/docs/rancher/v2.0-v2.4/en/upgrades/upgrades/ha/) use Helm 3.
>
> This section provides a copy of the older instructions for upgrading Rancher with Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
The following instructions will guide you through using Helm to upgrade a Rancher server that is installed on a Kubernetes cluster.
The following instructions will guide you through using Helm to upgrade a Rancher server that is installed on a Kubernetes cluster.
To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services]({{<baseurl>}}/rke/latest/en/config-options/services/) or [add-ons]({{<baseurl>}}/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE]({{<baseurl>}}/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
If you installed Rancher using the RKE Add-on yaml, follow the directions to [migrate or upgrade]({{<baseurl>}}/rancher/v2.0-v2.4/en/upgrades/upgrades/migrating-from-rke-add-on).
>**Notes:**
>
>
> - [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.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/upgrading-cert-manager)
> - If you are upgrading Rancher from v2.x to v2.3+, and you are using external TLS termination, you will need to edit the cluster.yml to [enable using forwarded host headers.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/chart-options/#configuring-ingress-for-external-tls-when-using-nginx-v0-25)
> - The upgrade instructions assume you are using Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) This [section]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/helm2) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
@@ -85,7 +88,7 @@ of your Kubernetes cluster running Rancher server. You'll use the snapshot as a
This section describes how to upgrade normal (Internet-connected) or air gap installations of Rancher with Helm.
<Tabs>
<TabItem label="Kubernetes Upgrade">
<TabItem value="Kubernetes Upgrade">
Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
@@ -114,7 +117,7 @@ helm upgrade --install rancher rancher-<CHART_REPO>/rancher \
{{% accordion label="Option B: Reinstalling Rancher chart" %}}
If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
1. Uninstall Rancher
@@ -137,8 +140,7 @@ If you are currently running the cert-manager whose version is older than v0.11,
{{% /accordion %}}
</TabItem>
<TabItem label="Kubernetes Air Gap Upgrade">
<TabItem value="Kubernetes Air Gap Upgrade">
1. Render the Rancher template using the same chosen options that were used when installing Rancher. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/namespace-migration/namespace-migration.md
+8 -3
View File
@@ -7,6 +7,10 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades-rollbacks/upgrades/namespace-migration
- /rancher/v2.x/en/installation/install-rancher-on-k8s/upgrades/namespace-migration/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
>This section applies only to Rancher upgrades from v2.0.6 or earlier to v2.0.7 or later. Upgrades from v2.0.7 to later version are unaffected.
In Rancher v2.0.6 and prior, system namespaces crucial for Rancher and Kubernetes operations were not assigned to any Rancher project by default. Instead, these namespaces existed independently from all Rancher projects, but you could move these namespaces into any project without affecting cluster operations.
@@ -72,7 +76,8 @@ Reset the cluster nodes' network policies to restore connectivity.
>Download and setup [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
<Tabs>
<TabItem label="Kubernetes Install">
<TabItem value="Kubernetes Install">
1. From **Terminal**, change directories to your kubectl file that's generated during Rancher install, `kube_config_rancher-cluster.yml`. This file is usually in the directory where you ran RKE during Rancher installation.
1. Before repairing networking, run the following two commands to make sure that your nodes have a status of `Ready` and that your cluster components are `Healthy`.
@@ -172,8 +177,8 @@ Reset the cluster nodes' network policies to restore connectivity.
1. Log into the Rancher UI and view your clusters. Created clusters will show errors from attempting to contact Rancher while it was unavailable. However, these errors should resolve automatically.
</TabItem>
<TabItem label="Rancher Launched Kubernetes">
<br/>
<TabItem value="Rancher Launched Kubernetes">
If you can access Rancher, but one or more of the clusters that you launched using Rancher has no networking, you can repair them by moving them:
- Using the cluster's [embedded kubectl shell]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/kubectl/).
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/upgrades.md
+10 -6
View File
@@ -16,6 +16,10 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/
- /rancher/v2.0-v2.4/en/upgrades/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The following instructions will guide you through upgrading a Rancher server that was installed on a Kubernetes cluster with Helm. These steps also apply to air gap installs with Helm.
For the instructions to upgrade Rancher installed with Docker, refer to [this page.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades)
@@ -35,7 +39,7 @@ If you installed Rancher using the RKE Add-on yaml, follow the directions to [mi
Helm should be run from the same location as your kubeconfig file, or the same location where you run your kubectl commands from.
If you installed Kubernetes with RKE, the config will have been created in the directory you ran `rke up` in.
If you installed Kubernetes with RKE, the config will have been created in the directory you ran `rke up` in.
The kubeconfig can also be manually targeted for the intended cluster with the `--kubeconfig` tag (see: https://helm.sh/docs/helm/helm/)
@@ -115,7 +119,7 @@ You'll use the backup as a restoration point if something goes wrong during upgr
helm fetch rancher-<CHART_REPO>/rancher
```
You can fetch the chart for the specific version you are upgrading to by adding in the `--version=` tag. For example:
```plain
helm fetch rancher-<CHART_REPO>/rancher --version=v2.4.11
```
@@ -125,7 +129,7 @@ You'll use the backup as a restoration point if something goes wrong during upgr
This section describes how to upgrade normal (Internet-connected) or air gap installations of Rancher with Helm.
<Tabs>
<TabItem label="Kubernetes Upgrade">
<TabItem value="Kubernetes Upgrade">
Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
@@ -168,7 +172,7 @@ helm upgrade rancher rancher-<CHART_REPO>/rancher \
### Option B: Reinstalling Rancher and cert-manager
If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
1. Uninstall Rancher
@@ -186,9 +190,9 @@ If you are currently running the cert-manager whose version is older than v0.11,
--set hostname=rancher.my.org
```
</TabItem>
<TabItem label="Kubernetes Air Gap Upgrade">
</TabItem>
<TabItem value="Kubernetes Air Gap Upgrade">
Render the Rancher template using the same chosen options that were used when installing Rancher. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+7 -4
View File
@@ -9,10 +9,13 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/install-rancher/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section is about how to deploy Rancher for your air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy. There are _tabs_ for either a high availability (recommended) or a Docker installation.
<Tabs>
<TabItem label="Kubernetes Install (Recommended)">
<TabItem value="Kubernetes Install (Recommended)">
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.
@@ -230,11 +233,11 @@ These resources could be helpful when installing Rancher:
- [Troubleshooting Rancher Kubernetes Installations]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/troubleshooting/)
</TabItem>
<TabItem label="Docker Install">
<TabItem value="Docker Install">
The Docker installation is for Rancher users who want to test out Rancher.
The Docker installation is for Rancher users who want to test out Rancher.
Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
> **Important:** There is no upgrade path to transition your Docker installation to a Kubernetes Installation.** Instead of running the single node installation, you have the option to follow the Kubernetes Install guide, but only use one node to install Rancher. Afterwards, you can scale up the etcd nodes in your Kubernetes cluster to make it a Kubernetes Installation.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/launch-kubernetes/launch-kubernetes.md
+10 -4
View File
@@ -5,18 +5,21 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/install-kube
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
> Skip this section if you are installing Rancher on a single node with Docker.
This section describes how to install a Kubernetes cluster according to our [best practices for the Rancher server environment.]({{<baseurl>}}/rancher/v2.0-v2.4/en/overview/architecture-recommendations/#environment-for-kubernetes-installations) This cluster should be dedicated to run only the Rancher server.
For Rancher before v2.4, Rancher should be installed on an [RKE]({{<baseurl>}}/rke/latest/en/) (Rancher Kubernetes Engine) Kubernetes cluster. RKE is a CNCF-certified Kubernetes distribution that runs entirely within Docker containers.
In Rancher v2.4, the Rancher management server can be installed on either an RKE cluster or a K3s Kubernetes cluster. K3s is also a fully certified Kubernetes distribution released by Rancher, but is newer than RKE. We recommend installing Rancher on K3s because K3s is easier to use, and more lightweight, with a binary size of less than 100 MB. The Rancher management server can only be run on a Kubernetes cluster in an infrastructure provider where Kubernetes is installed using RKE or K3s. Use of Rancher on hosted Kubernetes providers, such as EKS, is not supported. Note: After Rancher is installed on an RKE cluster, there is no migration path to a K3s setup at this time.
In Rancher v2.4, the Rancher management server can be installed on either an RKE cluster or a K3s Kubernetes cluster. K3s is also a fully certified Kubernetes distribution released by Rancher, but is newer than RKE. We recommend installing Rancher on K3s because K3s is easier to use, and more lightweight, with a binary size of less than 100 MB. The Rancher management server can only be run on a Kubernetes cluster in an infrastructure provider where Kubernetes is installed using RKE or K3s. Use of Rancher on hosted Kubernetes providers, such as EKS, is not supported. Note: After Rancher is installed on an RKE cluster, there is no migration path to a K3s setup at this time.
The steps to set up an air-gapped Kubernetes cluster on RKE or K3s are shown below.
<Tabs>
<TabItem label="K3s">
<TabItem value="K3s">
In this guide, we are assuming you have created your nodes in your air gapped environment and have a secure Docker private registry on your bastion server.
@@ -96,7 +99,7 @@ The node-token is on the server at `/var/lib/rancher/k3s/server/node-token`
When you installed K3s on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/k3s/k3s.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
To use this `kubeconfig` file,
To use this `kubeconfig` file,
1. Install [kubectl,](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) a Kubernetes command-line tool.
2. Copy the file at `/etc/rancher/k3s/k3s.yaml` and save it to the directory `~/.kube/config` on your local machine.
@@ -139,8 +142,10 @@ Upgrading an air-gap environment can be accomplished in the following manner:
1. Download the new air-gap images (tar file) from the [releases](https://github.com/rancher/k3s/releases) page for the version of K3s you will be upgrading to. Place the tar in the `/var/lib/rancher/k3s/agent/images/` directory on each node. Delete the old tar file.
2. Copy and replace the old K3s binary in `/usr/local/bin` on each node. Copy over the install script at https://get.k3s.io (as it is possible it has changed since the last release). Run the script again just as you had done in the past with the same environment variables.
3. Restart the K3s service (if not restarted automatically by installer).
</TabItem>
<TabItem label="RKE">
<TabItem value="RKE">
We will create a Kubernetes cluster using Rancher Kubernetes Engine (RKE). Before being able to start your Kubernetes cluster, you’ll need to install RKE and create a RKE config file.
### 1. Install RKE
@@ -212,6 +217,7 @@ Save a copy of the following files in a secure location:
- `rancher-cluster.yml`: The RKE cluster configuration file.
- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{<baseurl>}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{<baseurl>}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains the current state of the cluster including the RKE configuration and the certificates.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/populate-private-registry/populate-private-registry.md
+7 -4
View File
@@ -8,6 +8,9 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/config-rancher-for-private-reg/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes how to set up your private registry so that when you install Rancher, Rancher will pull all the required images from this registry.
By default, all images used to [provision Kubernetes clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/) or launch any [tools]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/) in Rancher, e.g. monitoring, pipelines, alerts, are pulled from Docker Hub. In an air gapped installation of Rancher, you will need a private registry that is located somewhere accessible by your Rancher server. Then, you will load the registry with all the images.
@@ -23,7 +26,7 @@ The steps in this section differ depending on whether or not you are planning to
> If the registry has certs, follow [this K3s documentation](https://rancher.com/docs/k3s/latest/en/installation/private-registry/) about adding a private registry. The certs and registry configuration files need to be mounted into the Rancher container.
<Tabs>
<TabItem label="Linux Only Clusters">
<TabItem value="Linux Only Clusters">
For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
@@ -54,7 +57,7 @@ If you will use ARM64 hosts, the registry must support manifests. As of April 20
> Skip this step if you are using your own certificates, or if you are terminating TLS on an external load balancer.
In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://hub.helm.sh/charts/jetstack/cert-manager) image to `rancher-images.txt` as well.
In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://hub.helm.sh/charts/jetstack/cert-manager) image to `rancher-images.txt` as well.
1. Fetch the latest `cert-manager` Helm chart and parse the template for image details:
@@ -107,8 +110,9 @@ The `rancher-images.txt` is expected to be on the workstation in the same direct
```plain
./rancher-load-images.sh --image-list ./rancher-images.txt --registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
</TabItem>
<TabItem label="Linux and Windows Clusters">
<TabItem value="Linux and Windows Clusters">
_Available as of v2.3.0_
@@ -289,7 +293,6 @@ chmod +x rancher-load-images.sh
--registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/prepare-nodes/prepare-nodes.md
+10 -3
View File
@@ -5,6 +5,9 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/air-gap-single-node/provision-host
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you will provision the underlying infrastructure for your Rancher management server in an air gapped environment. You will also set up the private Docker registry that must be available to your Rancher node(s).
An air gapped environment is an environment where the Rancher server is installed offline or behind a firewall.
@@ -12,7 +15,8 @@ An air gapped environment is an environment where the Rancher server is installe
The infrastructure depends on whether you are installing Rancher on a K3s Kubernetes cluster, an RKE Kubernetes cluster, or a single Docker container. For more information on each installation option, refer to [this page.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/)
<Tabs>
<TabItem label="K3s">
<TabItem value="K3s">
We recommend setting up the following infrastructure for a high-availability installation:
- **Two Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
@@ -82,8 +86,9 @@ Rancher supports air gap installs using a private registry. You must have your o
In a later step, when you set up your K3s Kubernetes cluster, you will create a [private registries configuration file]({{<baseurl>}}/k3s/latest/en/installation/private-registry/) with details from this registry.
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
</TabItem>
<TabItem label="RKE">
<TabItem value="RKE">
To install the Rancher management server on a high-availability RKE cluster, we recommend setting up the following infrastructure:
@@ -146,8 +151,10 @@ In a later step, when you set up your RKE Kubernetes cluster, you will create a
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
</TabItem>
<TabItem label="Docker">
<TabItem value="Docker">
> The Docker installation is for Rancher users that are wanting to test out Rancher. Since there is only one node and a single Docker container, if the node goes down, you will lose all the data of your Rancher server.
>
> For Rancher v2.0-v2.4, there is no migration path from a Docker installation to a high-availability installation. Therefore, you may want to use a Kubernetes installation from the start.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+6 -2
View File
@@ -9,6 +9,9 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/upgrades/single-node/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The following instructions will guide you through upgrading a Rancher server that was installed with Docker.
# Prerequisites
@@ -130,7 +133,7 @@ To see the command to use when starting the new Rancher server container, choose
- Docker Upgrade for Air Gap Installs
<Tabs>
<TabItem label="Docker Upgrade">
<TabItem value="Docker Upgrade">
Select which option you had installed Rancher server
@@ -238,7 +241,7 @@ docker run -d --volumes-from rancher-data \
{{% /accordion %}}
</TabItem>
<TabItem label="Docker Air Gap Upgrade">
<TabItem value="Docker Air Gap Upgrade">
For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
@@ -328,6 +331,7 @@ docker run -d --volumes-from rancher-data \
```
{{% /accordion %}}
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/requirements/requirements.md
+9 -5
View File
@@ -4,6 +4,9 @@ description: Learn the node requirements for each node running Rancher server wh
weight: 1
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This page describes the software, hardware, and networking requirements for the nodes where the Rancher server will be installed. The Rancher server can be installed on a single node or a high-availability Kubernetes cluster.
> It is important to note that if you install Rancher on a Kubernetes cluster, requirements are different from the [node requirements for downstream user clusters,]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/node-requirements/) which will run your apps and services.
@@ -64,7 +67,7 @@ This section describes the CPU, memory, and disk requirements for the nodes wher
Hardware requirements scale based on the size of your Rancher deployment. Provision each individual node according to the requirements. The requirements are different depending on if you are installing Rancher in a single container with Docker, or if you are installing Rancher on a Kubernetes cluster.
<Tabs>
<TabItem label="RKE">
<TabItem value="RKE">
These requirements apply to each host in an [RKE Kubernetes cluster where the Rancher server is installed.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/)
@@ -80,9 +83,9 @@ Performance increased in Rancher v2.4.0. For the requirements of Rancher before
Every use case and environment is different. Please [contact Rancher](https://rancher.com/contact/) to review yours.
</TabItem>
<TabItem label="K3s">
</TabItem>
<TabItem value="K3s">
These requirements apply to each host in a [K3s Kubernetes cluster where the Rancher server is installed.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/)
@@ -96,9 +99,9 @@ These requirements apply to each host in a [K3s Kubernetes cluster where the Ran
Every use case and environment is different. Please [contact Rancher](https://rancher.com/contact/) to review yours.
</TabItem>
<TabItem label="Docker">
</TabItem>
<TabItem value="Docker">
These requirements apply to a host with a [single-node]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker) installation of Rancher.
@@ -107,6 +110,7 @@ These requirements apply to a host with a [single-node]({{<baseurl>}}/rancher/v2
| Small | Up to 5 | Up to 50 | 1 | 4 GB |
| Medium | Up to 15 | Up to 200 | 2 | 8 GB |
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md
+5 -2
View File
@@ -11,10 +11,13 @@ aliases:
- /rancher/v2.x/en/installation/resources/advanced/air-gap-helm2/install-rancher/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section is about how to deploy Rancher for your air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy. There are _tabs_ for either a high availability (recommended) or a Docker installation.
<Tabs>
<TabItem label="Kubernetes Install (Recommended)">
<TabItem value="Kubernetes Install (Recommended)">
Rancher recommends installing Rancher on a Kubernetes cluster. A highly available Kubernetes Installation 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.
@@ -223,7 +226,7 @@ These resources could be helpful when installing Rancher:
- [Troubleshooting Rancher Kubernetes Installations]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/troubleshooting/)
</TabItem>
<TabItem label="Docker Install">
<TabItem value="Docker Install">
The Docker installation is for Rancher users that are wanting to **test** out Rancher. Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server. **Important: If you install Rancher following the Docker installation guide, there is no upgrade path to transition your Docker installation to a Kubernetes Installation.** Instead of running the single node installation, you have the option to follow the Kubernetes Install guide, but only use one node to install Rancher. Afterwards, you can scale up the etcd nodes in your Kubernetes cluster to make it a Kubernetes Installation.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md
+6 -2
View File
@@ -11,6 +11,9 @@ aliases:
- /rancher/v2.x/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
> **Prerequisites:** You must have a [private registry](https://docs.docker.com/registry/deploying/) available to use.
>
> **Note:** Populating the private registry with images is the same process for HA and Docker installations, the differences in this section is based on whether or not you are planning to provision a Windows cluster or not.
@@ -22,7 +25,7 @@ This section describes how to set up your private registry so that when you inst
By default, we provide the steps of how to populate your private registry assuming you are provisioning Linux only clusters, but if you plan on provisioning any [Windows clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/windows-clusters/), there are separate instructions to support the images needed for a Windows cluster.
<Tabs>
<TabItem label="Linux Only Clusters">
<TabItem value="Linux Only Clusters">
For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
@@ -100,8 +103,9 @@ Move the images in the `rancher-images.tar.gz` to your private registry using th
```plain
./rancher-load-images.sh --image-list ./rancher-images.txt --registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
</TabItem>
<TabItem label="Linux and Windows Clusters">
<TabItem value="Linux and Windows Clusters">
_Available as of v2.3.0_
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/prepare-nodes/prepare-nodes.md
+9 -4
View File
@@ -8,12 +8,15 @@ aliases:
- /rancher/v2.x/en/installation/resources/advanced/air-gap-helm2/prepare-nodes/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section is about how to prepare your node(s) to install Rancher for your air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy. There are _tabs_ for either a high availability (recommended) or a Docker installation.
# Prerequisites
<Tabs>
<TabItem label="Kubernetes Install (Recommended)">
<TabItem value="Kubernetes Install (Recommended)">
### OS, Docker, Hardware, and Networking
@@ -33,8 +36,9 @@ The following CLI tools are required for the Kubernetes Install. Make sure these
- [rke]({{<baseurl>}}/rke/latest/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
- [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes. Refer to the [Helm version requirements]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/helm-version) to choose a version of Helm to install Rancher.
</TabItem>
<TabItem label="Docker Install">
<TabItem value="Docker Install">
### OS, Docker, Hardware, and Networking
@@ -45,13 +49,14 @@ Make sure that your node(s) fulfill the general [installation requirements.]({{<
Rancher supports air gap installs using a private registry. You must have your own private registry or other means of distributing Docker images to your machines.
If you need help with creating a private registry, please refer to the [Docker documentation](https://docs.docker.com/registry/).
</TabItem>
</Tabs>
# Set up Infrastructure
<Tabs>
<TabItem label="Kubernetes Install (Recommended)">
<TabItem value="Kubernetes Install (Recommended)">
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.
@@ -87,7 +92,7 @@ You will need to configure a load balancer as a basic Layer 4 TCP forwarder to d
- For an example showing how to set up an Amazon NLB load balancer, refer to [this page.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/nlb)
</TabItem>
<TabItem label="Docker Install">
<TabItem value="Docker Install">
The Docker installation is for Rancher users that are wanting to test out Rancher. Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/choosing-version/choosing-version.md
+8 -3
View File
@@ -5,6 +5,9 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/options/server-tags
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes how to choose a Rancher version.
For a high-availability installation of Rancher, which is recommended for production, the Rancher server is installed using a **Helm chart** on a Kubernetes cluster. Refer to the [Helm version requirements]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/helm-version) to choose a version of Helm to install Rancher.
@@ -12,7 +15,7 @@ For a high-availability installation of Rancher, which is recommended for produc
For Docker installations of Rancher, which is used for development and testing, you will install Rancher as a **Docker image.**
<Tabs>
<TabItem label="Helm Charts">
<TabItem value="Helm Charts">
When installing, upgrading, or rolling back Rancher Server when it is [installed on a Kubernetes cluster]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/), Rancher server is installed using a Helm chart on a Kubernetes cluster. Therefore, as you prepare to install or upgrade a high availability Rancher configuration, you must add a Helm chart repository that contains the charts for installing Rancher.
@@ -77,8 +80,10 @@ After installing Rancher, if you want to change which Helm chart repository to i
```
4. Continue to follow the steps to [upgrade Rancher]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha) from the new Helm chart repository.
</TabItem>
<TabItem label="Docker Images">
<TabItem value="Docker Images">
When performing [Docker installs]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/single-node), upgrades, or rollbacks, you can use _tags_ to install a specific version of Rancher.
### Server Tags
@@ -96,5 +101,5 @@ Rancher Server is distributed as a Docker image, which have tags attached to the
> - The `master` tag or any tag with `-rc` or another suffix is meant for the Rancher testing team to validate. You should not use these tags, as these builds are not officially supported.
> - Want to install an alpha review for preview? Install using one of the alpha tags listed on our [announcements page](https://forums.rancher.com/c/announcements) (e.g., `v2.2.0-alpha1`). Caveat: Alpha releases cannot be upgraded to or from any other release.
</TabItem>
</TabItem>
</Tabs>
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/feature-flags/feature-flags.md
+9 -2
View File
@@ -5,6 +5,10 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/options/feature-flags/
- /rancher/v2.0-v2.4/en/admin-settings/feature-flags/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Rancher includes some features that are experimental and disabled by default. You might want to enable these features, for example, if you decide that the benefits of using an [unsupported storage type]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/feature-flags/enable-not-default-storage-drivers) outweighs the risk of using an untested feature. Feature flags were introduced to allow you to try these features that are not enabled by default.
The features can be enabled in three ways:
@@ -50,7 +54,8 @@ When you install Rancher, enable the feature you want with a feature flag. The c
> **Note:** Values set from the Rancher API will override the value passed in through the command line.
<Tabs>
<TabItem label="Kubernetes Install">
<TabItem value="Kubernetes Install">
When installing Rancher with a Helm chart, use the `--features` option. In the below example, two features are enabled by passing the feature flag names names in a comma separated list:
```
@@ -99,8 +104,10 @@ helm template ./rancher-<VERSION>.tgz --output-dir . \
--set 'extraEnv[0].value=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true' # Available as of v2.3.0
```
</TabItem>
<TabItem label="Docker Install">
<TabItem value="Docker Install">
When installing Rancher with Docker, use the `--features` option. In the below example, two features are enabled by passing the feature flag names in a comma separated list:
```
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/local-system-charts/local-system-charts.md
+5 -2
View File
@@ -7,6 +7,9 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/options/local-system-charts
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
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.
In an air gapped installation of Rancher, you will need to configure Rancher to use a local copy of the system charts. This section describes how to use local system charts using a CLI flag in Rancher v2.3.0, and using a Git mirror for Rancher versions before v2.3.0.
@@ -30,7 +33,7 @@ Refer to the release notes in the `system-charts` repository to see which branch
Rancher needs to be configured to use your Git mirror of the `system-charts` repository. You can configure the system charts repository either from the Rancher UI or from Rancher's API view.
<Tabs>
<TabItem label="Rancher UI">
<TabItem value="Rancher UI">
In the catalog management page in the Rancher UI, follow these steps:
@@ -47,7 +50,7 @@ In the catalog management page in the Rancher UI, follow these steps:
**Result:** Rancher is configured to download all the required catalog items from your `system-charts` repository.
</TabItem>
<TabItem label="Rancher API">
<TabItem value="Rancher API">
1. Log into Rancher.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/pipelines/pipelines.md
+16 -8
View File
@@ -2,9 +2,12 @@
title: Pipelines
weight: 11
aliases:
- /rancher/v2.0-v2.4/en/k8s-in-rancher/pipelines
- /rancher/v2.0-v2.4/en/k8s-in-rancher/pipelines
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Rancher's pipeline provides a simple CI/CD experience. Use it to automatically checkout code, run builds or scripts, publish Docker images or catalog applications, and deploy the updated software to users.
Setting up a pipeline can help developers deliver new software as quickly and efficiently as possible. Using Rancher, you can integrate with a GitHub repository to setup a continuous integration (CI) pipeline.
@@ -14,7 +17,7 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins
- Build your application from code to image.
- Validate your builds.
- Deploy your build images to your cluster.
- Run unit tests.
- Run unit tests.
- Run regression tests.
>**Notes:**
@@ -96,7 +99,8 @@ Before you can start configuring a pipeline for your repository, you must config
Select your provider's tab below and follow the directions.
<Tabs>
<TabItem label="GitHub">
<TabItem value="GitHub">
1. From the **Global** view, navigate to the project that you want to configure pipelines.
1. Select **Tools > Pipelines** in the navigation bar. In versions before v2.2.0, you can select **Resources > Pipelines**.
@@ -109,8 +113,9 @@ Select your provider's tab below and follow the directions.
1. Click **Authenticate**.
</TabItem>
<TabItem label="GitLab">
<TabItem value="GitLab">
_Available as of v2.1.0_
@@ -127,10 +132,11 @@ _Available as of v2.1.0_
1. Click **Authenticate**.
>**Note:**
> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
> 2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
</TabItem>
<TabItem label="Bitbucket Cloud">
<TabItem value="Bitbucket Cloud">
_Available as of v2.2.0_
@@ -146,8 +152,9 @@ _Available as of v2.2.0_
1. Click **Authenticate**.
</TabItem>
<TabItem label="Bitbucket Server">
<TabItem value="Bitbucket Server">
_Available as of v2.2.0_
@@ -169,6 +176,7 @@ _Available as of v2.2.0_
> 1. Setup Rancher server with a certificate from a trusted CA.
> 1. If you're using self-signed certificates, import Rancher server's certificate to the Bitbucket server. For instructions, see the Bitbucket server documentation for [configuring self-signed certificates](https://confluence.atlassian.com/bitbucketserver/if-you-use-self-signed-certificates-938028692.html).
>
</TabItem>
</Tabs>
@@ -213,7 +221,7 @@ Now that repositories are added to your project, you can start configuring the p
1. Set up the trigger rules for the pipeline.
1. Enter a **Timeout** for the pipeline.
1. Enter a **Timeout** for the pipeline.
1. When all the stages and steps are configured, click **Done**.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/pipelines/storage/storage.md
+35 -49
View File
@@ -5,6 +5,9 @@ aliases:
- /rancher/v2.0-v2.4/en/k8s-in-rancher/pipelines/storage
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The pipelines' internal Docker registry and the Minio workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.
This section assumes that you understand how persistent storage works in Kubernetes. For more information, refer to the section on [how storage works.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/volumes-and-storage/how-storage-works/)
@@ -25,35 +28,26 @@ This section assumes that you understand how persistent storage works in Kuberne
- **Add Volume > Use an existing persistent volume (claim)**
1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
<Tabs>
<TabItem label="Add a new persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
<Tabs>
<TabItem value="Add a new persistent volume">
1. Select a volume claim **Source**:
1. Enter a **Name** for the volume claim.
1. Select a volume claim **Source**:
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
</TabItem>
<TabItem value="Use an existing persistent volume">
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
1. Click **Define**.
</TabItem>
<TabItem label="Use an existing persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
</TabItem>
</Tabs>
</TabItem>
</Tabs>
1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container.
@@ -69,34 +63,26 @@ This section assumes that you understand how persistent storage works in Kuberne
- **Add Volume > Use an existing persistent volume (claim)**
1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
<Tabs>
<Tabs>
<TabItem value="Add a new persistent volume">
<TabItem label="Add a new persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
1. Enter a **Name** for the volume claim.
1. Select a volume claim **Source**:
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
1. Select a volume claim **Source**:
</TabItem>
<TabItem value="Use an existing persistent volume">
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
</TabItem>
<TabItem label="Use an existing persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
</TabItem>
</Tabs>
</TabItem>
</Tabs>
1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container.
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/v1.6-migration/monitor-apps/monitor-apps.md
+6 -5
View File
@@ -5,6 +5,9 @@ aliases:
- /rancher/v2.x/en/v1.6-migration/monitor-apps/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Rancher v1.6 provided TCP and HTTP health checks on your nodes and services using its own health check microservice. These health checks monitored your containers to confirm they're operating as intended. If a container failed a health check, Rancher would destroy the unhealthy container and then replicates a healthy one to replace it.
For Rancher v2.x, we've replaced the health check microservice, leveraging instead Kubernetes' native health check support.
@@ -92,8 +95,7 @@ Configure probes by using the **Health Check** section while editing deployments
While you create a workload using Rancher v2.x, we recommend configuring a check that monitors the health of the deployment's pods.
<Tabs>
<TabItem label="TCP Check">
<TabItem value="TCP Check">
TCP checks monitor your deployment's health by attempting to open a connection to the pod over a specified port. If the probe can open the port, it's considered healthy. Failure to open it is considered unhealthy, which notifies Kubernetes that it should kill the pod and then replace it according to its [restart policy](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy). (this applies to Liveness probes, for Readiness probes, it will mark the pod as Unready).
@@ -129,9 +131,9 @@ When you configure a readiness check using Rancher v2.x, the `readinessProbe` di
-->
</TabItem>
<TabItem label="HTTP Check">
</TabItem>
<TabItem value="HTTP Check">
HTTP checks monitor your deployment's health by sending an HTTP GET request to a specific URL path that you define. If the pod responds with a message range of `200`-`400`, the health check is considered successful. If the pod replies with any other value, the check is considered unsuccessful, so Kubernetes kills and replaces the pod according to its [restart policy](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy). (this applies to Liveness probes, for Readiness probes, it will mark the pod as Unready).
@@ -142,7 +144,6 @@ You can configure the probe along with values for specifying its behavior by sel
When you configure a readiness check using Rancher v2.x, the `readinessProbe` directive and the values you've set are added to the deployment's Kubernetes manifest. Configuring a readiness check also automatically adds a liveness check (`livenessProbe`) to the deployment.
</TabItem>
</Tabs>
### Configuring Separate Liveness Checks
versioned_docs/version-2.0-2.4/v2.0-v2.4/en/v1.6-migration/run-migration-tool/run-migration-tool.md
+8 -8
View File
@@ -5,6 +5,9 @@ aliases:
- /rancher/v2.x/en/v1.6-migration/run-migration-tool/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Although your services from v1.6 won't work in Rancher v2.x by default, that doesn't mean you have to start again from square one, manually rebuilding your applications in v2.x. To help with migration from v1.6 to v2.x, Rancher has developed a migration tool. The migration-tools CLI is a utility that helps you recreate your applications in Rancher v2.x. This tool exports your Rancher v1.6 services as Compose files and converts them to a Kubernetes manifest that Rancher v2.x can consume.
Additionally, for each Rancher v1.6-specific Compose directive that cannot be consumed by Kubernetes, migration-tools CLI provides instructions on how to manually recreate them in Rancher v2.x.
@@ -122,7 +125,7 @@ File | Description
The following tabs display the contents of each parsed file. We've omitted `webLB-deployment.yaml` and `webLB-service.yaml` because we aren't migrating them to v2.x.
<Tabs>
<TabItem label="web-deployment.yaml">
<TabItem value="web-deployment.yaml">
```YAML
apiVersion: extensions/v1beta1
@@ -160,7 +163,7 @@ status: {}
```
</TabItem>
<TabItem label="web-service.yaml">
<TabItem value="web-service.yaml">
```YAML
apiVersion: v1
@@ -188,7 +191,7 @@ status:
```
</TabItem>
<TabItem label="database-deployment.yaml">
<TabItem value="database-deployment.yaml">
```YAML
apiVersion: extensions/v1beta1
@@ -225,8 +228,6 @@ status: {}
```
</TabItem>
</Tabs>
-->
@@ -236,7 +237,7 @@ status: {}
>**Note:** Although these instructions deploy your v1.6 services in Rancher v2.x, they will not work correctly until you adjust their Kubernetes manifests.
<Tabs>
<TabItem label="Rancher UI">
<TabItem value="Rancher UI">
You can deploy the Kubernetes manifests created by migration-tools by importing them into Rancher v2.x.
@@ -249,8 +250,7 @@ You can deploy the Kubernetes manifests created by migration-tools by importing
![Deploy Services]({{<baseurl>}}/img/rancher/deploy-service.gif)
</TabItem>
<TabItem label="Rancher CLI">
<TabItem value="Rancher CLI">
>**Prerequisite:** [Install Rancher CLI]({{<baseurl>}}/rancher/v2.0-v2.4/en/cli/) for Rancher v2.x.
versioned_docs/version-2.5/v2.5/en/admin-settings/authentication/keycloak/keycloak.md
+8 -3
View File
@@ -6,6 +6,9 @@ aliases:
- /rancher/v2.x/en/admin-settings/authentication/keycloak/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
If your organization uses Keycloak Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
## Prerequisites
@@ -37,11 +40,13 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati
## Getting the IDP Metadata
<Tabs>
<TabItem label="Keycloak 5 and earlier">
<TabItem value="Keycloak 5 and earlier">
To get the IDP metadata, export a `metadata.xml` file from your Keycloak client.
From the **Installation** tab, choose the **SAML Metadata IDPSSODescriptor** format option and download your file.
</TabItem>
<TabItem label="Keycloak 6-13">
<TabItem value="Keycloak 6-13">
1. From the **Configure** section, click the **Realm Settings** tab.
1. Click the **General** tab.
@@ -80,7 +85,7 @@ You are left with something similar as the example below:
```
</TabItem>
<TabItem label="Keycloak 14+">
<TabItem value="Keycloak 14+">
1. From the **Configure** section, click the **Realm Settings** tab.
1. Click the **General** tab.
versioned_docs/version-2.5/v2.5/en/admin-settings/rbac/global-permissions/global-permissions.md
+5 -2
View File
@@ -5,6 +5,9 @@ aliases:
- /rancher/v2.x/en/admin-settings/rbac/global-permissions/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
_Permissions_ are individual access rights that you can assign when selecting a custom permission for a user.
Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are three default global permissions: `Administrator`, `Standard User` and `User-base`.
@@ -48,7 +51,7 @@ CATTLE_RESTRICTED_DEFAULT_ADMIN=true
The permissions for the `restricted-admin` role differ based on the Rancher version.
<Tabs>
<TabItem label="v2.5.7+">
<TabItem value="v2.5.7+">
The `restricted-admin` permissions are as follows:
@@ -57,7 +60,7 @@ The `restricted-admin` permissions are as follows:
- Can create other restricted admins.
</TabItem>
<TabItem label="v2.5.0-v2.5.6">
<TabItem value="v2.5.0-v2.5.6">
The `restricted-admin` permissions are as follows:
versioned_docs/version-2.5/v2.5/en/cis-scans/cis-scans.md
+23 -12
View File
@@ -7,6 +7,9 @@ aliases:
- /rancher/v2.x/en/cis-scans/v2.5/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark.
The `rancher-cis-benchmark` app leverages <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench,</a> an open-source tool from Aqua Security, to check clusters for CIS Kubernetes Benchmark compliance. Also, to generate a cluster-wide report, the application utilizes <a href="https://github.com/vmware-tanzu/sonobuoy" target="_blank">Sonobuoy</a> for report aggregation.
@@ -42,7 +45,8 @@ Support for alerting for the cluster scan results is now also available from Ran
In Rancher v2.4, permissive and hardened profiles were included. In Rancher v2.5.0 and in v2.5.4, more profiles were included.
<Tabs>
<TabItem label="Profiles in v2.5.4">
<TabItem value="Profiles in v2.5.4">
- Generic CIS 1.5
- Generic CIS 1.6
- RKE permissive 1.5
@@ -53,13 +57,16 @@ In Rancher v2.4, permissive and hardened profiles were included. In Rancher v2.5
- GKE
- RKE2 permissive 1.5
- RKE2 permissive 1.5
</TabItem>
<TabItem label="Profiles in v2.5.0-v2.5.3">
<TabItem value="Profiles in v2.5.0-v2.5.3">
- Generic CIS 1.5
- RKE permissive
- RKE hardened
- EKS
- GKE
</TabItem>
</Tabs>
<br/>
@@ -68,7 +75,7 @@ In Rancher v2.4, permissive and hardened profiles were included. In Rancher v2.5
The default profile and the supported CIS benchmark version depends on the type of cluster that will be scanned and the Rancher version:
<Tabs>
<TabItem label="v2.5.4">
<TabItem value="v2.5.4">
The `rancher-cis-benchmark` supports the CIS 1.6 Benchmark version.
@@ -78,7 +85,7 @@ The `rancher-cis-benchmark` supports the CIS 1.6 Benchmark version.
- For cluster types other than RKE, RKE2, EKS and GKE, the Generic CIS 1.5 profile will be used by default.
</TabItem>
<TabItem label="v2.5.0-v2.5.3">
<TabItem value="v2.5.0-v2.5.3">
The `rancher-cis-benchmark` supports the CIS 1.5 Benchmark version.
@@ -97,7 +104,7 @@ The Center for Internet Security is a 501(c\)(3) non-profit organization, formed
CIS Benchmarks are best practices for the secure configuration of a target system. CIS Benchmarks are developed through the generous volunteer efforts of subject matter experts, technology vendors, public and private community members, and the CIS Benchmark Development team.
The official Benchmark documents are available through the CIS website. The sign-up form to access the documents is
The official Benchmark documents are available through the CIS website. The sign-up form to access the documents is
<a href="https://learn.cisecurity.org/benchmarks" target="_blank">here.</a>
# About the Generated Report
@@ -136,7 +143,8 @@ Refer to <a href="{{<baseurl>}}/rancher/v2.5/en/security/" target="_blank">the t
The following profiles are available:
<Tabs>
<TabItem label="Profiles in v2.5.4">
<TabItem value="Profiles in v2.5.4">
- Generic CIS 1.5
- Generic CIS 1.6
- RKE permissive 1.5
@@ -147,13 +155,16 @@ The following profiles are available:
- GKE
- RKE2 permissive 1.5
- RKE2 permissive 1.5
</TabItem>
<TabItem label="Profiles in v2.5.0-v2.5.3">
<TabItem value="Profiles in v2.5.0-v2.5.3">
- Generic CIS 1.5
- RKE permissive
- RKE hardened
- EKS
- GKE
</TabItem>
</Tabs>
@@ -242,7 +253,7 @@ To run a ClusterScan on a schedule,
1. Choose a **Retention** count, which indicates the number of reports maintained for this recurring scan. By default this count is 3. When this retention limit is reached, older reports will get purged.
1. Click **Create.**
**Result:** The scan runs and reschedules to run according to the cron schedule provided. The **Next Scan** value indicates the next time this scan will run again.
**Result:** The scan runs and reschedules to run according to the cron schedule provided. The **Next Scan** value indicates the next time this scan will run again.
A report is generated with the scan results every time the scan runs. To see the latest results, click the name of the scan that appears.
@@ -294,7 +305,7 @@ _Available as of v2.5.4_
Alerts can be configured to be sent out for a scan that runs on a schedule.
> **Prerequisite:**
> **Prerequisite:**
>
> Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/configuration/alertmanager/)
>
@@ -321,7 +332,7 @@ The `rancher-cis-benchmark` application supports two types of alerts:
- Alert on scan completion: This alert is sent out when the scan run finishes. The alert includes details including the ClusterScan's name and the ClusterScanProfile name.
- Alert on scan failure: This alert is sent out if there are some test failures in the scan run or if the scan is in a `Fail` state.
> **Prerequisite:**
> **Prerequisite:**
>
> Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/configuration/alertmanager/)
>
@@ -343,9 +354,9 @@ To configure alerts for a scan that runs on a schedule,
A report is generated with the scan results every time the scan runs. To see the latest results, click the name of the scan that appears.
### Creating a Custom Benchmark Version for Running a Cluster Scan
### Creating a Custom Benchmark Version for Running a Cluster Scan
_Available as of v2.5.4_
There could be some Kubernetes cluster setups that require custom configurations of the Benchmark tests. For example, the path to the Kubernetes config files or certs might be different than the standard location where the upstream CIS Benchmarks look for them.
It is now possible to create a custom Benchmark Version for running a cluster scan using the `rancher-cis-benchmark` application.
versioned_docs/version-2.5/v2.5/en/cluster-admin/cleaning-cluster-nodes/cleaning-cluster-nodes.md
+8 -2
View File
@@ -7,6 +7,9 @@ aliases:
- /rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes how to disconnect a node from a Rancher-launched Kubernetes cluster and remove all of the Kubernetes components from the node. This process allows you to use the node for other purposes.
When you use Rancher to install Kubernetes on new nodes in an infrastructure provider, resources (containers/virtual network interfaces) and configuration items (certificates/configuration files) are created.
@@ -59,7 +62,8 @@ For registered clusters, the process for removing Rancher is a little different.
After the registered cluster is detached from Rancher, the cluster's workloads will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
<Tabs>
<TabItem label="By UI / API">
<TabItem value="By UI / API">
>**Warning:** This process will remove data from your cluster. Make sure you have created a backup of files you want to keep before executing the command, as data will be lost.
After you initiate the removal of a registered cluster using the Rancher UI (or API), the following events occur.
@@ -72,8 +76,10 @@ After you initiate the removal of a registered cluster using the Rancher UI (or
**Result:** All components listed for registered clusters in [What Gets Removed?](#what-gets-removed) are deleted.
</TabItem>
<TabItem label="By Script">
<TabItem value="By Script">
Rather than cleaning registered cluster nodes using the Rancher UI, you can run a script instead.
>**Prerequisite:**
versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md
+11 -12
View File
@@ -4,8 +4,11 @@ shortTitle: EKS Cluster Configuration
weight: 2
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
<Tabs>
<TabItem label="Rancher v2.5.6+">
<TabItem value="Rancher v2.5.6+">
### Account Access
@@ -101,7 +104,7 @@ For more information on EKS control plane logging, refer to the official [docume
<a id="managed-node-groups-2-5-6"></a>
Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters.
Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters.
For more information about how node groups work and how they are configured, refer to the [EKS documentation.](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)
@@ -151,9 +154,8 @@ The following settings are also configurable. All of these except for the "Node
| Labels | Kubernetes labels applied to the nodes in the managed node group. Note: Invalid labels can prevent upgrades or can prevent Rancher from starting. For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) |
| Tags | These are tags for the managed node group and do not propagate to any of the associated resources. |
</TabItem>
<TabItem label="Rancher v2.5.0-v2.5.5">
<TabItem value="Rancher v2.5.0-v2.5.5">
### Changes in Rancher v2.5
@@ -271,7 +273,7 @@ For more information on EKS control plane logging, refer to the official [docume
<a id="managed-node-groups-2-5"></a>
Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters.
Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters.
For more information about how node groups work and how they are configured, refer to the [EKS documentation.](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)
@@ -284,8 +286,7 @@ Amazon will use the [EKS-optimized AMI](https://docs.aws.amazon.com/eks/latest/u
| Minimum ASG Size | The minimum number of instances. This setting won't take effect until the [Cluster Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html) is installed. |
</TabItem>
<TabItem label="Rancher prior to v2.5">
<TabItem value="Rancher prior to v2.5">
### Account Access
@@ -393,12 +394,10 @@ User Data | Custom commands can to be passed to perform automated configuration
</TabItem>
</Tabs>
### Configuring the Refresh Interval
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
The `eks-refresh-cron` setting is deprecated. It has been migrated to the `eks-refresh` setting, which is an integer representing seconds.
@@ -411,9 +410,9 @@ If the `eks-refresh-cron` setting was previously set, the migration will happen
The shorter the refresh window, the less likely any race conditions will occur, but it does increase the likelihood of encountering request limits that may be in place for AWS APIs.
</TabItem>
<TabItem label="Before v2.5.8">
<TabItem value="Before v2.5.8">
It is possible to change the refresh interval through the setting `eks-refresh-cron`. This setting accepts values in the Cron format. The default is `*/5 * * * *`.
It is possible to change the refresh interval through the setting `eks-refresh-cron`. This setting accepts values in the Cron format. The default is `*/5 * * * *`.
The shorter the refresh window, the less likely any race conditions will occur, but it does increase the likelihood of encountering request limits that may be in place for AWS APIs.
versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/gke-config-reference.md
+9 -6
View File
@@ -4,8 +4,11 @@ shortTitle: GKE Cluster Configuration
weight: 3
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
# Changes in v2.5.8
@@ -303,8 +306,7 @@ The syncing interval can be changed by running `kubectl edit setting gke-refresh
The shorter the refresh window, the less likely any race conditions will occur, but it does increase the likelihood of encountering request limits that may be in place for GCP APIs.
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
# Labels & Annotations
@@ -315,7 +317,7 @@ Invalid labels can prevent upgrades or can prevent Rancher from starting. For de
# Kubernetes Options
### Location Type
Zonal or Regional. With GKE, you can create a cluster tailored to the availability requirements of your workload and your budget. By default, a cluster's nodes run in a single compute zone. When multiple zones are selected, the cluster's nodes will span multiple compute zones, while the controlplane is located in a single zone. Regional clusters increase the availability of the controlplane as well. For help choosing the type of cluster availability, refer to [these docs.](https://cloud.google.com/kubernetes-engine/docs/best-practices/scalability#choosing_a_regional_or_zonal_control_plane)
Zonal or Regional. With GKE, you can create a cluster tailored to the availability requirements of your workload and your budget. By default, a cluster's nodes run in a single compute zone. When multiple zones are selected, the cluster's nodes will span multiple compute zones, while the controlplane is located in a single zone. Regional clusters increase the availability of the controlplane as well. For help choosing the type of cluster availability, refer to [these docs.](https://cloud.google.com/kubernetes-engine/docs/best-practices/scalability#choosing_a_regional_or_zonal_control_plane)
For [regional clusters,](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#regional_clusters) you can select a region. For more information about available regions and zones, refer to [this section](https://cloud.google.com/compute/docs/regions-zones#available). The first part of each zone name is the name of the region.
@@ -327,7 +329,7 @@ Each region in Compute engine contains a number of zones.
For more information about available regions and zones, refer to [these docs.](https://cloud.google.com/compute/docs/regions-zones#available)
### Additional Zones
For zonal clusters, you can select additional zones to create a [multi-zone cluster.](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#multi-zonal_clusters)
For zonal clusters, you can select additional zones to create a [multi-zone cluster.](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#multi-zonal_clusters)
### Kubernetes Version
Link to list of GKE kubernetes versions
@@ -405,7 +407,7 @@ Standard persistent disks are backed by standard hard disk drives (HDD), while S
The size in GB of the [root disk.](https://cloud.google.com/compute/docs/disks)
### Local SSD disks
Configure each node's local SSD disk storage in GB.
Configure each node's local SSD disk storage in GB.
Local SSDs are physically attached to the server that hosts your VM instance. Local SSDs have higher throughput and lower latency than standard persistent disks or SSD persistent disks. The data that you store on a local SSD persists only until the instance is stopped or deleted. For more information, see [this section.](https://cloud.google.com/compute/docs/disks#localssds)
@@ -449,5 +451,6 @@ Access scopes are the legacy method of specifying permissions for your nodes.
- **Set access for each API:** Alternatively, you can choose to set specific scopes that permit access to the particular API methods that the service will call.
For more information, see the [section about enabling service accounts for a VM.](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances)
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/cluster-provisioning/cluster-capabilities-table/index.md
+5 -3
View File
@@ -2,8 +2,11 @@
headless: true
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
| Action | Rancher Launched Kubernetes Clusters | EKS and GKE Clusters<sup>1</sup> | Other Hosted Kubernetes Clusters | Non-EKS or GKE Registered Clusters |
| --- | --- | ---| ---|----|
@@ -32,7 +35,7 @@ headless: true
4. For registered clusters using etcd as a control plane, snapshots must be taken manually outside of the Rancher UI to use for backup and recovery.
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
| Action | Rancher Launched Kubernetes Clusters | Hosted Kubernetes Clusters | Registered EKS Clusters | All Other Registered Clusters |
| --- | --- | ---| ---|----|
@@ -58,6 +61,5 @@ headless: true
3. For registered clusters using etcd as a control plane, snapshots must be taken manually outside of the Rancher UI to use for backup and recovery.
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/gke/gke.md
+10 -8
View File
@@ -8,8 +8,11 @@ aliases:
- /rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
- [Prerequisites](#prerequisites)
- [Provisioning a GKE Cluster](#provisioning-a-gke-cluster)
@@ -30,7 +33,7 @@ The service account requires the following roles:
- **Compute Viewer:** `roles/compute.viewer`
- **Project Viewer:** `roles/viewer`
- **Kubernetes Engine Admin:** `roles/container.admin`
- **Kubernetes Engine Admin:** `roles/container.admin`
- **Service Account User:** `roles/iam.serviceAccountUser`
[Google Documentation: Creating and Enabling Service Accounts](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances)
@@ -79,7 +82,7 @@ Your cluster is created and assigned a state of **Provisioning.** Rancher is sta
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
@@ -104,9 +107,8 @@ The GKE provisioner can synchronize the state of a GKE cluster between Rancher a
For information on configuring the refresh interval, see [this section.]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/#configuring-the-refresh-interval)
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
# Prerequisites
@@ -120,7 +122,7 @@ The service account requires the following roles:
- **Compute Viewer:** `roles/compute.viewer`
- **Project Viewer:** `roles/viewer`
- **Kubernetes Engine Admin:** `roles/container.admin`
- **Kubernetes Engine Admin:** `roles/container.admin`
- **Service Account User:** `roles/iam.serviceAccountUser`
[Google Documentation: Creating and Enabling Service Accounts](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances)
@@ -145,7 +147,7 @@ Use Rancher to set up and configure your Kubernetes cluster.
>**Note:** After submitting your private key, you may have to enable the Google Kubernetes Engine API. If prompted, browse to the URL displayed in the Rancher UI to enable the API.
6. Select your cluster options, node options and security options. For help, refer to the [GKE Cluster Configuration Reference.](#gke-before-v2-5-8)
6. Select your cluster options, node options and security options. For help, refer to the [GKE Cluster Configuration Reference.](#gke-before-v2-5-8)
9. Review your options to confirm they're correct. Then click **Create**.
**Result:** You have successfully deployed a GKE cluster.
@@ -154,7 +156,7 @@ Your cluster is created and assigned a state of **Provisioning.** Rancher is sta
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
versioned_docs/version-2.5/v2.5/en/cluster-provisioning/node-requirements/node-requirements.md
+8 -4
View File
@@ -5,6 +5,9 @@ aliases:
- /rancher/v2.x/en/cluster-provisioning/node-requirements/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This page describes the requirements for the Rancher managed Kubernetes clusters where your apps and services will be installed. These downstream clusters should be separate from the three-node cluster running Rancher.
> If Rancher is installed on a high-availability Kubernetes cluster, the Rancher server three-node cluster and downstream clusters have different requirements. For Rancher installation requirements, refer to the node requirements in the [installation section.]({{<baseurl>}}/rancher/v2.5/en/installation/requirements/)
@@ -33,7 +36,7 @@ For information on how to install Docker, refer to the official [Docker document
Some distributions of Linux derived from RHEL, including Oracle Linux, may have default firewall rules that block communication with Helm. We recommend disabling firewalld. For Kubernetes 1.19, firewalld must be turned off.
>**Note:** In RHEL 8.4, two extra services are included on the NetworkManager: `nm-cloud-setup.service` and `nm-cloud-setup.timer`. These services add a routing table that interferes with the CNI plugin's configuration. If these services are enabled, you must disable them using the command below, and then reboot the node to restore connectivity:
>
>
> ```
systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
reboot
@@ -48,7 +51,7 @@ SUSE Linux may have a firewall that blocks all ports by default. In that situati
When [Launching Kubernetes with Rancher]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/) using Flatcar Container Linux nodes, it is required to use the following configuration in the [Cluster Config File]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/#cluster-config-file)
<Tabs>
<TabItem label="Canal">
<TabItem value="Canal">
```yaml
rancher_kubernetes_engine_config:
@@ -63,9 +66,9 @@ rancher_kubernetes_engine_config:
extra_args:
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
```
</TabItem>
<TabItem label="Calico">
</TabItem>
<TabItem value="Calico">
```yaml
rancher_kubernetes_engine_config:
@@ -80,6 +83,7 @@ rancher_kubernetes_engine_config:
extra_args:
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
```
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/cluster-provisioning/registered-clusters/registered-clusters.md
+11 -10
View File
@@ -7,6 +7,9 @@ aliases:
- /rancher/v2.x/en/cluster-provisioning/registered-clusters/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The cluster registration feature replaced the feature to import clusters.
The control that Rancher has to manage a registered cluster depends on the type of cluster. For details, see [Management Capabilities for Registered Clusters.](#management-capabilities-for-registered-clusters)
@@ -21,7 +24,7 @@ The control that Rancher has to manage a registered cluster depends on the type
# Prerequisites
<Tabs>
<TabItem label="v2.5.9+">
<TabItem value="v2.5.9+">
### Kubernetes Node Roles
@@ -52,7 +55,7 @@ If you are registering a K3s cluster, make sure the `cluster.yml` is readable. I
EKS clusters must have at least one managed node group to be imported into Rancher or provisioned from Rancher successfully.
</TabItem>
<TabItem label="Rancher before v2.5.9">
<TabItem value="Rancher before v2.5.9">
### Permissions
@@ -121,7 +124,7 @@ $ curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -s -
### Configuring an Imported EKS Cluster with Terraform
You should define **only** the minimum fields that Rancher requires when importing an EKS cluster with Terraform. This is important as Rancher will overwrite what was in the EKS cluster with any config that the user has provided.
You should define **only** the minimum fields that Rancher requires when importing an EKS cluster with Terraform. This is important as Rancher will overwrite what was in the EKS cluster with any config that the user has provided.
>**Warning:** Even a small difference between the current EKS cluster and a user-provided config could have unexpected results.
@@ -152,7 +155,7 @@ resource "rancher2_cluster" "my-eks-to-import" {
The control that Rancher has to manage a registered cluster depends on the type of cluster.
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
- [Changes in v2.5.8](#changes-in-v2-5-8)
- [Features for All Registered Clusters](#2-5-8-features-for-all-registered-clusters)
@@ -196,9 +199,8 @@ When you delete an EKS cluster or GKE cluster that was created in Rancher, the c
The capabilities for registered clusters are listed in the table on [this page.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/)
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
- [Features for All Registered Clusters](#before-2-5-8-features-for-all-registered-clusters)
- [Additional Features for Registered K3s Clusters](#before-2-5-8-additional-features-for-registered-k3s-clusters)
@@ -236,11 +238,10 @@ Amazon EKS clusters can now be registered in Rancher. For the most part, registe
When you delete an EKS cluster that was created in Rancher, the cluster is destroyed. When you delete an EKS cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher.
The capabilities for registered EKS clusters are listed in the table on [this page.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/)
</TabItem>
</Tabs>
# Configuring K3s Cluster Upgrades
> It is a Kubernetes best practice to back up the cluster before upgrading. When upgrading a high-availability K3s cluster with an external database, back up the database in whichever way is recommended by the relational database provider.
@@ -256,7 +257,7 @@ Also in the K3s documentation, nodes with the worker role are called agent nodes
# Debug Logging and Troubleshooting for Registered K3s Clusters
Nodes are upgraded by the system upgrade controller running in the downstream cluster. Based on the cluster configuration, Rancher deploys two [plans](https://github.com/rancher/system-upgrade-controller#example-upgrade-plan) to upgrade K3s nodes: one for controlplane nodes and one for workers. The system upgrade controller follows the plans and upgrades the nodes.
Nodes are upgraded by the system upgrade controller running in the downstream cluster. Based on the cluster configuration, Rancher deploys two [plans](https://github.com/rancher/system-upgrade-controller#example-upgrade-plan) to upgrade K3s nodes: one for controlplane nodes and one for workers. The system upgrade controller follows the plans and upgrades the nodes.
To enable debug logging on the system upgrade controller deployment, edit the [configmap](https://github.com/rancher/system-upgrade-controller/blob/50a4c8975543d75f1d76a8290001d87dc298bdb4/manifests/system-upgrade-controller.yaml#L32) to set the debug environment variable to true. Then restart the `system-upgrade-controller` pod.
@@ -298,7 +299,7 @@ This example annotation indicates that a pod security policy is enabled:
The following annotation indicates Ingress capabilities. Note that that the values of non-primitive objects need to be JSON encoded, with quotations escaped.
```
"capabilities.cattle.io/ingressCapabilities": "[
"capabilities.cattle.io/ingressCapabilities": "[
{
"customDefaultBackend":true,
"ingressProvider":"asdf"
versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/options/options.md
+6 -3
View File
@@ -5,6 +5,9 @@ aliases:
- /rancher/v2.x/en/cluster-provisioning/rke-clusters/options/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
When Rancher installs Kubernetes, it uses [RKE]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/) as the Kubernetes distribution.
This section covers the configuration options that are available in Rancher for a new or existing RKE Kubernetes cluster.
@@ -71,12 +74,12 @@ When Weave is selected as network provider, Rancher will automatically enable en
Project network isolation is used to enable or disable communication between pods in different projects.
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
To enable project network isolation as a cluster option, you will need to use any RKE network plugin that supports the enforcement of Kubernetes network policies, such as Canal or the Cisco ACI plugin.
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
To enable project network isolation as a cluster option, you will need to use Canal as the CNI.
@@ -294,7 +297,7 @@ Option to enable or disable [Cluster Monitoring]({{<baseurl>}}/rancher/v2.5/en/m
Option to enable or disable Project Network Isolation.
Before Rancher v2.5.8, project network isolation is only available if you are using the Canal network plugin for RKE.
Before Rancher v2.5.8, project network isolation is only available if you are using the Canal network plugin for RKE.
In v2.5.8+, project network isolation is available if you are using any RKE network plugin that supports the enforcement of Kubernetes network policies, such as Canal or the Cisco ACI plugin.
versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/windows-clusters.md
+10 -4
View File
@@ -5,6 +5,9 @@ aliases:
- /rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
When provisioning a [custom cluster]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/custom-nodes) using Rancher, Rancher uses RKE (the Rancher Kubernetes Engine) to install Kubernetes on your existing nodes.
In a Windows cluster provisioned with Rancher, the cluster must contain both Linux and Windows nodes. The Kubernetes controlplane can only run on Linux nodes, and the Windows nodes can only have the worker role. Windows nodes can only be used for deploying workloads.
@@ -36,13 +39,15 @@ The general node requirements for networking, operating systems, and Docker are
### OS and Docker Requirements
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
Our support for Windows Server and Windows containers match the Microsoft official lifecycle for LTSC (Long-Term Servicing Channel) and SAC (Semi-Annual Channel).
For the support lifecycle dates for Windows Server, see the [Microsoft Documentation.](https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info)
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
In order to add Windows worker nodes to a cluster, the node must be running one of the following Windows Server versions and the corresponding version of Docker Engine - Enterprise Edition (EE):
- Nodes with Windows Server core version 1809 should use Docker EE-basic 18.09 or Docker EE-basic 19.03.
@@ -52,6 +57,7 @@ In order to add Windows worker nodes to a cluster, the node must be running one
>
> - If you are using AWS, Rancher recommends _Microsoft Windows Server 2019 Base with Containers_ as the Amazon Machine Image (AMI).
> - If you are using GCE, Rancher recommends _Windows Server 2019 Datacenter for Containers_ as the OS image.
</TabItem>
</Tabs>
@@ -214,13 +220,13 @@ The first node in your cluster should be a Linux host has both the **Control Pla
1. SSH into your Linux host and run the command that you copied to your clipboard.
1. When you are finished provisioning your Linux node(s), select **Done**.
**Result:**
**Result:**
Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
You can access your cluster after its state is updated to **Active.**
**Active** clusters are assigned two Projects:
**Active** clusters are assigned two Projects:
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
versioned_docs/version-2.5/v2.5/en/installation/install-rancher-on-k8s/gke/gke.md
+8 -4
View File
@@ -4,6 +4,9 @@ shortTitle: GKE
weight: 5
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you'll learn how to install Rancher using Google Kubernetes Engine.
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.]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/#install-the-rancher-helm-chart)
@@ -59,8 +62,8 @@ To install `gcloud` and `kubectl`, perform the following steps:
```
source ~/.bash_profile
```
# 3. Configure the gcloud CLI
@@ -70,7 +73,7 @@ To install `gcloud` and `kubectl`, perform the following steps:
- Using gcloud config, to individually set your project ID, zone, and region.
<Tabs>
<TabItem label="Using gloud init">
<TabItem value="Using gloud init">
1. Run gcloud init and follow the directions:
@@ -85,7 +88,8 @@ To install `gcloud` and `kubectl`, perform the following steps:
2. Follow the instructions to authorize gcloud to use your Google Cloud account and select the new project that you created.
</TabItem>
<TabItem label="Using gcloud config">
<TabItem value="Using gcloud config">
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
+7 -4
View File
@@ -11,6 +11,9 @@ aliases:
- /rancher/v2.x/en/installation/install-rancher-on-k8s/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you'll learn how to deploy Rancher on a Kubernetes cluster using the Helm CLI.
- [Prerequisites](#prerequisites)
@@ -160,8 +163,7 @@ The exact command to install Rancher differs depending on the certificate config
However, irrespective of the certificate configuration, the name of the Rancher installation in the `cattle-system` namespace should always be `rancher`.
<Tabs>
<TabItem label="Rancher-generated Certificates">
<TabItem value="Rancher-generated Certificates">
The default is for Rancher to generate a self-signed CA, and uses `cert-manager` to issue the certificate for access to the Rancher server interface.
@@ -188,7 +190,7 @@ deployment "rancher" successfully rolled out
```
</TabItem>
<TabItem label="Let's Encrypt">
<TabItem value="Let's Encrypt">
This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA.
@@ -223,7 +225,7 @@ deployment "rancher" successfully rolled out
```
</TabItem>
<TabItem label="Certificates from Files">
<TabItem value="Certificates from Files">
In this option, Kubernetes secrets are created from your own certificates for Rancher to use.
When you run this command, the `hostname` option must match the `Common Name` or a `Subject Alternative Names` entry in the server certificate, or the Ingress controller will fail to configure correctly.
@@ -257,6 +259,7 @@ helm install rancher rancher-<CHART_REPO>/rancher \
```
Now that Rancher is deployed, see [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.5/en/installation/resources/encryption/tls-secrets/) to publish the certificate files so Rancher and the Ingress controller can use them.
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/installation/install-rancher-on-k8s/upgrades/air-gap-upgrade/air-gap-upgrade.md
+8 -9
View File
@@ -4,6 +4,9 @@ shortTitle: Air Gap Upgrade
weight: 1
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
> These instructions assume you have already followed the instructions for a Kubernetes upgrade on [this page,]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades/) including the prerequisites, up until step 3. Upgrade Rancher.
### Rancher Helm Template Options
@@ -23,7 +26,7 @@ Placeholder | Description
### Option A: Default Self-signed Certificate
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
```
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -37,7 +40,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
```
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
```plain
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -52,14 +55,10 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
</TabItem>
</Tabs>
### Option B: Certificates from Files using Kubernetes Secrets
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
```plain
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -87,8 +86,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
```
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
```plain
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -112,6 +110,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
--set useBundledSystemChart=true # Use the packaged Rancher system charts
```
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+13 -5
View File
@@ -11,13 +11,16 @@ aliases:
- /rancher/v2.x/en/installation/other-installation-methods/air-gap/install-rancher/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section is about how to deploy Rancher for your air gapped environment in a high-availability Kubernetes installation. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy.
### Privileged Access for Rancher v2.5+
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)
@@ -139,7 +142,8 @@ Placeholder | Description
`<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
```plain
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
--no-hooks \ # prevent files for Helm hooks from being generated
@@ -152,8 +156,9 @@ 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`
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
```plain
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -166,6 +171,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
```
**Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.5.6`
</TabItem>
</Tabs>
@@ -189,7 +195,7 @@ Render the Rancher template, declaring your chosen options. Use the reference ta
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry. |
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
```plain
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -219,8 +225,9 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
**Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.3.6`
Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.5/en/installation/resources/encryption/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
```plain
@@ -249,6 +256,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
**Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.3.6`
Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.5/en/installation/resources/encryption/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/launch-kubernetes/launch-kubernetes.md
+9 -3
View File
@@ -6,6 +6,9 @@ aliases:
- /rancher/v2.x/en/installation/other-installation-methods/air-gap/launch-kubernetes/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
> Skip this section if you are installing Rancher on a single node with Docker.
This section describes how to install a Kubernetes cluster according to our [best practices for the Rancher server environment.]({{<baseurl>}}/rancher/v2.5/en/overview/architecture-recommendations/#environment-for-kubernetes-installations) This cluster should be dedicated to run only the Rancher server.
@@ -15,7 +18,7 @@ As of Rancher v2.5, Rancher can be installed on any Kubernetes cluster, includin
The steps to set up an air-gapped Kubernetes cluster on RKE or K3s are shown below.
<Tabs>
<TabItem label="K3s">
<TabItem value="K3s">
In this guide, we are assuming you have created your nodes in your air gapped environment and have a secure Docker private registry on your bastion server.
@@ -95,7 +98,7 @@ The node-token is on the server at `/var/lib/rancher/k3s/server/node-token`
When you installed K3s on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/k3s/k3s.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
To use this `kubeconfig` file,
To use this `kubeconfig` file,
1. Install [kubectl,](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) a Kubernetes command-line tool.
2. Copy the file at `/etc/rancher/k3s/k3s.yaml` and save it to the directory `~/.kube/config` on your local machine.
@@ -138,8 +141,10 @@ Upgrading an air-gap environment can be accomplished in the following manner:
1. Download the new air-gap images (tar file) from the [releases](https://github.com/rancher/k3s/releases) page for the version of K3s you will be upgrading to. Place the tar in the `/var/lib/rancher/k3s/agent/images/` directory on each node. Delete the old tar file.
2. Copy and replace the old K3s binary in `/usr/local/bin` on each node. Copy over the install script at https://get.k3s.io (as it is possible it has changed since the last release). Run the script again just as you had done in the past with the same environment variables.
3. Restart the K3s service (if not restarted automatically by installer).
</TabItem>
<TabItem label="RKE">
<TabItem value="RKE">
We will create a Kubernetes cluster using Rancher Kubernetes Engine (RKE). Before being able to start your Kubernetes cluster, you’ll need to install RKE and create a RKE config file.
### 1. Install RKE
@@ -211,6 +216,7 @@ Save a copy of the following files in a secure location:
- `rancher-cluster.yml`: The RKE cluster configuration file.
- `kube_config_cluster.yml`: The [Kubeconfig file]({{<baseurl>}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{<baseurl>}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains the current state of the cluster including the RKE configuration and the certificates.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/populate-private-registry/populate-private-registry.md
+7 -4
View File
@@ -10,6 +10,9 @@ aliases:
- /rancher/v2.x/en/installation/other-installation-methods/air-gap/populate-private-registry/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes how to set up your private registry so that when you install Rancher, Rancher will pull all the required images from this registry.
By default, all images used to [provision Kubernetes clusters]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/) or launch any tools in Rancher, e.g. monitoring and logging, are pulled from Docker Hub. In an air gapped installation of Rancher, you will need a private registry that is located somewhere accessible by your Rancher server. Then, you will load the registry with all the images.
@@ -25,7 +28,7 @@ The steps in this section differ depending on whether or not you are planning to
> If the registry has certs, follow [this K3s documentation](https://rancher.com/docs/k3s/latest/en/installation/private-registry/) about adding a private registry. The certs and registry configuration files need to be mounted into the Rancher container.
<Tabs>
<TabItem label="Linux Only Clusters">
<TabItem value="Linux Only Clusters">
For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
@@ -56,7 +59,7 @@ If you will use ARM64 hosts, the registry must support manifests. As of April 20
> Skip this step if you are using your own certificates, or if you are terminating TLS on an external load balancer.
In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://hub.helm.sh/charts/jetstack/cert-manager) image to `rancher-images.txt` as well.
In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://hub.helm.sh/charts/jetstack/cert-manager) image to `rancher-images.txt` as well.
1. Fetch the latest `cert-manager` Helm chart and parse the template for image details:
@@ -109,8 +112,9 @@ The `rancher-images.txt` is expected to be on the workstation in the same direct
```plain
./rancher-load-images.sh --image-list ./rancher-images.txt --registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
</TabItem>
<TabItem label="Linux and Windows Clusters">
<TabItem value="Linux and Windows Clusters">
For Rancher servers that will provision Linux and Windows clusters, there are distinctive steps to populate your private registry for the Windows images and the Linux images. Since a Windows cluster is a mix of Linux and Windows nodes, the Linux images pushed into the private registry are manifests.
@@ -287,7 +291,6 @@ The image list, `rancher-images.txt` or `rancher-windows-images.txt`, is expecte
--registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/prepare-nodes/prepare-nodes.md
+10 -3
View File
@@ -6,6 +6,9 @@ aliases:
- /rancher/v2.x/en/installation/other-installation-methods/air-gap/prepare-nodes/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
In this section, you will provision the underlying infrastructure for your Rancher management server in an air gapped environment. You will also set up the private Docker registry that must be available to your Rancher node(s).
An air gapped environment is an environment where the Rancher server is installed offline or behind a firewall.
@@ -15,7 +18,8 @@ The infrastructure depends on whether you are installing Rancher on a K3s Kubern
As of Rancher v2.5, Rancher can be installed on any Kubernetes cluster. The RKE and K3s Kubernetes infrastructure tutorials below are still included for convenience.
<Tabs>
<TabItem label="K3s">
<TabItem value="K3s">
We recommend setting up the following infrastructure for a high-availability installation:
- **Two Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
@@ -85,8 +89,9 @@ Rancher supports air gap installs using a private registry. You must have your o
In a later step, when you set up your K3s Kubernetes cluster, you will create a [private registries configuration file]({{<baseurl>}}/k3s/latest/en/installation/private-registry/) with details from this registry.
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
</TabItem>
<TabItem label="RKE">
<TabItem value="RKE">
To install the Rancher management server on a high-availability RKE cluster, we recommend setting up the following infrastructure:
@@ -149,8 +154,10 @@ In a later step, when you set up your RKE Kubernetes cluster, you will create a
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
</TabItem>
<TabItem label="Docker">
<TabItem value="Docker">
> The Docker installation is for Rancher users that are wanting to test out Rancher. Since there is only one node and a single Docker container, if the node goes down, you will lose all the data of your Rancher server.
>
> As of Rancher v2.5, the Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster.]({{<baseurl>}}/rancher/v2.5/en/backups/migrating-rancher)
versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+6 -2
View File
@@ -10,6 +10,9 @@ aliases:
- /rancher/v2.x/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The following instructions will guide you through upgrading a Rancher server that was installed with Docker.
# Prerequisites
@@ -131,7 +134,7 @@ To see the command to use when starting the new Rancher server container, choose
- Docker Upgrade for Air Gap Installs
<Tabs>
<TabItem label="Docker Upgrade">
<TabItem value="Docker Upgrade">
Select which option you had installed Rancher server
@@ -249,7 +252,7 @@ As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/
{{% /accordion %}}
</TabItem>
<TabItem label="Docker Air Gap Upgrade">
<TabItem value="Docker Air Gap Upgrade">
For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
@@ -342,6 +345,7 @@ docker run -d --volumes-from rancher-data \
```
As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
{{% /accordion %}}
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/installation/requirements/ports/ports.md
+9 -2
View File
@@ -6,6 +6,9 @@ aliases:
- /rancher/v2.x/en/installation/requirements/ports/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes.
- [Rancher Nodes](#rancher-nodes)
@@ -281,7 +284,8 @@ When using the [AWS EC2 node driver]({{<baseurl>}}/rancher/v2.5/en/cluster-provi
SUSE Linux may have a firewall that blocks all ports by default. To open the ports needed for adding the host to a custom cluster,
<Tabs>
<TabItem label="SLES 15 / openSUSE Leap 15">
<TabItem value="SLES 15 / openSUSE Leap 15">
1. SSH into the instance.
1. Start YaST in text mode:
```
@@ -299,8 +303,10 @@ UDP Ports
1. When all required ports are enter, select **Accept**.
</TabItem>
<TabItem label="SLES 12 / openSUSE Leap 42">
<TabItem value="SLES 12 / openSUSE Leap 42">
1. SSH into the instance.
1. Edit /`etc/sysconfig/SuSEfirewall2` and open the required ports. In this example, ports 9796 and 10250 are also opened for monitoring:
```
@@ -312,6 +318,7 @@ UDP Ports
```
SuSEfirewall2
```
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/installation/resources/choosing-version/choosing-version.md
+8 -3
View File
@@ -6,6 +6,9 @@ aliases:
- /rancher/v2.x/en/installation/resources/choosing-version/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes how to choose a Rancher version.
For a high-availability installation of Rancher, which is recommended for production, the Rancher server is installed using a **Helm chart** on a Kubernetes cluster. Refer to the [Helm version requirements]({{<baseurl>}}/rancher/v2.5/en/installation/options/helm-version) to choose a version of Helm to install Rancher.
@@ -17,7 +20,7 @@ The Helm chart version also applies to RancherD installs because RancherD instal
> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
<Tabs>
<TabItem label="Helm Charts">
<TabItem value="Helm Charts">
When installing, upgrading, or rolling back Rancher Server when it is [installed on a Kubernetes cluster]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/), Rancher server is installed using a Helm chart on a Kubernetes cluster. Therefore, as you prepare to install or upgrade a high availability Rancher configuration, you must add a Helm chart repository that contains the charts for installing Rancher.
@@ -80,8 +83,10 @@ After installing Rancher, if you want to change which Helm chart repository to i
```
4. Continue to follow the steps to [upgrade Rancher]({{<baseurl>}}/rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha) from the new Helm chart repository.
</TabItem>
<TabItem label="Docker Images">
<TabItem value="Docker Images">
When performing [Docker installs]({{<baseurl>}}/rancher/v2.5/en/installation/single-node), upgrades, or rollbacks, you can use _tags_ to install a specific version of Rancher.
### Server Tags
@@ -99,5 +104,5 @@ Rancher Server is distributed as a Docker image, which have tags attached to the
> - The `master` tag or any tag with `-rc` or another suffix is meant for the Rancher testing team to validate. You should not use these tags, as these builds are not officially supported.
> - Want to install an alpha review for preview? Install using one of the alpha tags listed on our [announcements page](https://forums.rancher.com/c/announcements) (e.g., `v2.2.0-alpha1`). Caveat: Alpha releases cannot be upgraded to or from any other release.
</TabItem>
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/installation/resources/feature-flags/feature-flags.md
+8 -2
View File
@@ -6,6 +6,10 @@ aliases:
- /rancher/v2.5/en/admin-settings/feature-flags/
- /rancher/v2.x/en/installation/resources/feature-flags/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Rancher includes some features that are experimental and disabled by default. You might want to enable these features, for example, if you decide that the benefits of using an [unsupported storage type]({{<baseurl>}}/rancher/v2.5/en/installation/options/feature-flags/enable-not-default-storage-drivers) outweighs the risk of using an untested feature. Feature flags were introduced to allow you to try these features that are not enabled by default.
The features can be enabled in three ways:
@@ -78,7 +82,7 @@ Here is an example of a command for passing in the feature flag names when rende
The Helm 3 command is as follows:
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
```
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -92,8 +96,9 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
--set 'extraEnv[0].name=CATTLE_FEATURES'
--set 'extraEnv[0].value=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true'
```
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
```
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
@@ -106,6 +111,7 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
--set 'extraEnv[0].name=CATTLE_FEATURES'
--set 'extraEnv[0].value=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true'
```
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/istio/configuration-reference/enable-istio-with-psp/enable-istio-with-psp.md
+8 -5
View File
@@ -9,19 +9,22 @@ aliases:
- /rancher/v2.x/en/istio/v2.5/configuration-reference/enable-istio-with-psp/
---
If you have restrictive Pod Security Policies enabled, then Istio may not be able to function correctly, because it needs certain permissions in order to install itself and manage pod infrastructure. In this section, we will configure a cluster with PSPs enabled for an Istio install, and also set up the Istio CNI plugin.
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
If you have restrictive Pod Security Policies enabled, then Istio may not be able to function correctly, because it needs certain permissions in order to install itself and manage pod infrastructure. In this section, we will configure a cluster with PSPs enabled for an Istio install, and also set up the Istio CNI plugin.
The Istio CNI plugin removes the need for each application pod to have a privileged `NET_ADMIN` container. For further information, see the [Istio CNI Plugin docs](https://istio.io/docs/setup/additional-setup/cni). Please note that the [Istio CNI Plugin is in alpha](https://istio.io/about/feature-stages/).
The steps differ based on the Rancher version.
<Tabs>
<TabItem label="v2.5.4+">
<TabItem value="v2.5.4+">
> **Prerequisites:**
>
> - The cluster must be an RKE Kubernetes cluster.
> - The cluster must have been created with a default PodSecurityPolicy.
> - The cluster must have been created with a default PodSecurityPolicy.
>
> To enable pod security policy support when creating a Kubernetes cluster in the Rancher UI, go to <b>Advanced Options.</b> In the <b>Pod Security Policy Support</b> section, click <b>Enabled.</b> Then select a default pod security policy.
@@ -60,12 +63,12 @@ Istio should install successfully with the CNI enabled in the cluster.
Verify that the CNI is working by deploying a [sample application](https://istio.io/latest/docs/examples/bookinfo/) or deploying one of your own applications.
</TabItem>
<TabItem label="v2.5.0-v2.5.3">
<TabItem value="v2.5.0-v2.5.3">
> **Prerequisites:**
>
> - The cluster must be an RKE Kubernetes cluster.
> - The cluster must have been created with a default PodSecurityPolicy.
> - The cluster must have been created with a default PodSecurityPolicy.
>
> To enable pod security policy support when creating a Kubernetes cluster in the Rancher UI, go to <b>Advanced Options.</b> In the <b>Pod Security Policy Support</b> section, click <b>Enabled.</b> Then select a default pod security policy.
versioned_docs/version-2.5/v2.5/en/istio/resources/resources.md
+5 -5
View File
@@ -9,6 +9,9 @@ aliases:
- /rancher/v2.x/en/istio/v2.5/resources/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes the minimum recommended computing resources for the Istio components in a cluster.
The CPU and memory allocations for each component are [configurable.](#configuring-resource-allocations)
@@ -22,7 +25,7 @@ The table below shows a summary of the minimum recommended resource requests and
In Kubernetes, the resource request indicates that the workload will not be deployed on a node unless the node has at least the specified amount of memory and CPU available. If the workload surpasses the limit for CPU or memory, it can be terminated or evicted from the node. For more information on managing resource limits for containers, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)
<Tabs>
<TabItem label="v2.5.6+">
<TabItem value="v2.5.6+">
| Workload | CPU - Request | Memory - Request | CPU - Limit | Memory - Limit |
|----------------------|---------------|------------|-----------------|-------------------|
@@ -33,7 +36,7 @@ In Kubernetes, the resource request indicates that the workload will not be depl
| **Totals:** | **710m** | **2314Mi** | **6000m** | **3072Mi** |
</TabItem>
<TabItem label="v2.5.0-v2.5.5">
<TabItem value="v2.5.0-v2.5.5">
Workload | CPU - Request | Memory - Request | CPU - Limit | Mem - Limit | Configurable
---------:|---------------:|---------------:|-------------:|-------------:|-------------:
@@ -46,9 +49,6 @@ Totals: | 1710m | 3304Mi | >8800m | >6048Mi | -
</TabItem>
</Tabs>
# Configuring Resource Allocations
You can individually configure the resource allocation for each type of Istio component. This section includes the default resource allocations for each component.
versioned_docs/version-2.5/v2.5/en/logging/custom-resource-config/flows/flows.md
+6 -2
View File
@@ -3,6 +3,9 @@ title: Flows and ClusterFlows
weight: 1
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/)
- [Configuration](#configuration)
@@ -11,7 +14,7 @@ For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai
# Configuration
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
- [Flows](#flows-2-5-8)
- [Matches](#matches-2-5-8)
@@ -73,8 +76,9 @@ Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way
After `ClusterFlow` selects logs from all namespaces in the cluster, logs from the cluster will be collected and logged to the selected `ClusterOutput`.
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
- [Flows](#flows-2-5-0)
- [Matches](#matches-2-5-0)
versioned_docs/version-2.5/v2.5/en/logging/custom-resource-config/outputs/outputs.md
+8 -6
View File
@@ -3,6 +3,9 @@ title: Outputs and ClusterOutputs
weight: 2
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/)
- [Configuration](#configuration)
@@ -15,7 +18,7 @@ For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Ban
# Configuration
<Tabs>
<TabItem label="v2.5.8+">
<TabItem value="v2.5.8+">
- [Outputs](#outputs-2-5-8)
- [ClusterOutputs](#clusteroutputs-2-5-8)
@@ -32,7 +35,7 @@ The `Output` resource defines where your `Flows` can send the log messages. `Out
The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.
You can use secrets in these definitions, but they must also be in the same namespace.
You can use secrets in these definitions, but they must also be in the same namespace.
For the details of `Output` custom resource, see [OutputSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/output_types/)
@@ -69,8 +72,7 @@ For example configuration for each logging plugin supported by the logging opera
For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
- [Outputs](#outputs-2-5-0)
- [ClusterOutputs](#clusteroutputs-2-5-0)
@@ -81,9 +83,9 @@ For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](htt
The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.
The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.
The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.
You can use secrets in these definitions, but they must also be in the same namespace.
You can use secrets in these definitions, but they must also be in the same namespace.
`Outputs` are configured in YAML. For the details of `Output` custom resource, see [OutputSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/output_types/)
versioned_docs/version-2.5/v2.5/en/logging/logging.md
+10 -3
View File
@@ -7,11 +7,14 @@ weight: 15
aliases:
- /rancher/v2.5/en/dashboard/logging
- /rancher/v2.5/en/logging/v2.5
- /rancher/v2.5/en/cluster-admin/tools/logging
- /rancher/v2.5/en/cluster-admin/tools/logging
- /rancher/v2.x/en/logging/
- /rancher/v2.x/en/logging/v2.5/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging solution in place of the former, in-house solution.
For an overview of the changes in v2.5, see [this section.]({{<baseurl>}}/rancher/v2.5/en/logging/architecture/#changes-in-rancher-v2-5) For information about migrating from Logging V1, see [this page.](./migrating)
@@ -81,17 +84,21 @@ For a list of options that can be configured when the logging application is ins
### Windows Support
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
As of Rancher v2.5.8, logging support for Windows clusters has been added and logs can be collected from Windows nodes.
For details on how to enable or disable Windows node logging, see [this section.](./helm-chart-options/#enable-disable-windows-node-logging)
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
Clusters with Windows workers support exporting logs from Linux nodes, but Windows node logs are currently unable to be exported.
Only Linux node logs are able to be exported.
To allow the logging pods to be scheduled on Linux nodes, tolerations must be added to the pods. Refer to the [Working with Taints and Tolerations]({{<baseurl>}}/rancher/v2.5/en/logging/taints-tolerations/) section for details and an example.
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/logging/taints-tolerations/taints-tolerations.md
+9 -3
View File
@@ -3,11 +3,14 @@ title: Working with Taints and Tolerations
weight: 6
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
"Tainting" a Kubernetes node causes pods to repel running on that node.
Unless the pods have a `toleration` for that node's taint, they will run on other nodes in the cluster.
[Taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) can work in conjunction with the `nodeSelector` [field](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) within the `PodSpec`, which enables the *opposite* effect of a taint.
[Taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) can work in conjunction with the `nodeSelector` [field](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) within the `PodSpec`, which enables the *opposite* effect of a taint.
Using `nodeSelector` gives pods an affinity towards certain nodes.
@@ -20,13 +23,16 @@ Both provide choice for the what node(s) the pod will run on.
### Default Implementation in Rancher's Logging Stack
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
Moreover, most logging stack pods run on Linux only and have a `nodeSelector` added to ensure they run on Linux nodes.
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
Moreover, we can populate the `nodeSelector` to ensure that our pods *only* run on Linux nodes.
versioned_docs/version-2.5/v2.5/en/monitoring-alerting/configuration/advanced/prometheusrules/prometheusrules.md
+10 -4
View File
@@ -5,6 +5,9 @@ aliases:
- /rancher/v2.x/en/monitoring-alerting/v2.5/configuration/prometheusrules/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
A PrometheusRule defines a group of Prometheus alerting and/or recording rules.
> This section assumes familiarity with how monitoring components work together. For more information, see [this section.]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/how-monitoring-works)
@@ -17,7 +20,7 @@ _Available as of v2.5.4_
To create rule groups in the Rancher UI,
1. Click **Cluster Explorer > Monitoring** and click **Prometheus Rules.**
1. Click **Cluster Explorer > Monitoring** and click **Prometheus Rules.**
1. Click **Create.**
1. Enter a **Group Name.**
1. Configure the rules. In Rancher's UI, we expect a rule group to contain either alert rules or recording rules, but not both. For help filling out the forms, refer to the configuration options below.
@@ -45,7 +48,8 @@ For examples, refer to the Prometheus documentation on [recording rules](https:/
# Configuration
<Tabs>
<TabItem label="Rancher v2.5.4">
<TabItem value="Rancher v2.5.4">
Rancher v2.5.4 introduced the capability to configure PrometheusRules by filling out forms in the Rancher UI.
@@ -73,7 +77,7 @@ Rancher v2.5.4 introduced the capability to configure PrometheusRules by filling
### Recording Rules
[Recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/#recording-rules) allow you to precompute frequently needed or computationally expensive PromQL (Prometheus Query Language) expressions and save their result as a new set of time series.
[Recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/#recording-rules) allow you to precompute frequently needed or computationally expensive PromQL (Prometheus Query Language) expressions and save their result as a new set of time series.
| Field | Description |
|-------|----------------|
@@ -82,7 +86,9 @@ Rancher v2.5.4 introduced the capability to configure PrometheusRules by filling
| Labels | Labels to add or overwrite before storing the result. |
</TabItem>
<TabItem label="Rancher v2.5.0-v2.5.3">
<TabItem value="Rancher v2.5.0-v2.5.3">
For Rancher v2.5.0-v2.5.3, PrometheusRules must be configured in YAML. For examples, refer to the Prometheus documentation on [recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/) and [alerting rules.](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/monitoring-alerting/configuration/receiver/receiver.md
+16 -12
View File
@@ -10,6 +10,9 @@ aliases:
- /rancher/v2.5/en/monitoring-alerting/configuration/alertmanager
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configuration/#configuration-file) Secret contains the configuration of an Alertmanager instance that sends out notifications based on alerts it receives from Prometheus.
> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../how-monitoring-works/#3-how-alertmanager-works)
@@ -43,7 +46,7 @@ _Available as of v2.5.4_
To create notification receivers in the Rancher UI,
1. Click **Cluster Explorer > Monitoring** and click **Receiver.**
1. Click **Cluster Explorer > Monitoring** and click **Receiver.**
2. Enter a name for the receiver.
3. Configure one or more providers for the receiver. For help filling out the forms, refer to the configuration options below.
4. Click **Create.**
@@ -73,7 +76,7 @@ Rancher v2.5.8 added Microsoft Teams and SMS as configurable receivers in the Ra
Rancher v2.5.4 introduced the capability to configure receivers by filling out forms in the Rancher UI.
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
The following types of receivers can be configured in the Rancher UI:
@@ -93,7 +96,7 @@ The custom receiver option can be used to configure any receiver in YAML that ca
| Field | Type | Description |
|------|--------------|------|
| URL | String | Enter your Slack webhook URL. For instructions to create a Slack webhook, see the [Slack documentation.](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack) |
| Default Channel | String | Enter the name of the channel that you want to send alert notifications in the following format: `#<channelname>`. |
| Default Channel | String | Enter the name of the channel that you want to send alert notifications in the following format: `#<channelname>`. |
| Proxy URL | String | Proxy for the webhook notifications. |
| Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |
@@ -102,7 +105,7 @@ The custom receiver option can be used to configure any receiver in YAML that ca
| Field | Type | Description |
|------|--------------|------|
| Default Recipient Address | String | The email address that will receive notifications. |
| Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |
| Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |
SMTP options:
@@ -121,7 +124,7 @@ SMTP options:
| Integration Type | String | `Events API v2` or `Prometheus`. |
| Default Integration Key | String | For instructions to get an integration key, see the [PagerDuty documentation.](https://www.pagerduty.com/docs/guides/prometheus-integration-guide/) |
| Proxy URL | String | Proxy for the PagerDuty notifications. |
| Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |
| Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |
# Opsgenie
@@ -230,7 +233,7 @@ url http://rancher-alerting-drivers-sachet.ns-1.svc:9876/alert
<!-- https://github.com/messagebird/sachet -->
</TabItem>
<TabItem label="Rancher v2.5.4-2.5.7">
<TabItem value="Rancher v2.5.4-2.5.7">
The following types of receivers can be configured in the Rancher UI:
@@ -248,7 +251,7 @@ The custom receiver option can be used to configure any receiver in YAML that ca
| Field | Type | Description |
|------|--------------|------|
| URL | String | Enter your Slack webhook URL. For instructions to create a Slack webhook, see the [Slack documentation.](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack) |
| Default Channel | String | Enter the name of the channel that you want to send alert notifications in the following format: `#<channelname>`. |
| Default Channel | String | Enter the name of the channel that you want to send alert notifications in the following format: `#<channelname>`. |
| Proxy URL | String | Proxy for the webhook notifications. |
| Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |
@@ -257,7 +260,7 @@ The custom receiver option can be used to configure any receiver in YAML that ca
| Field | Type | Description |
|------|--------------|------|
| Default Recipient Address | String | The email address that will receive notifications. |
| Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |
| Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |
SMTP options:
@@ -276,7 +279,7 @@ SMTP options:
| Integration Type | String | `Events API v2` or `Prometheus`. |
| Default Integration Key | String | For instructions to get an integration key, see the [PagerDuty documentation.](https://www.pagerduty.com/docs/guides/prometheus-integration-guide/) |
| Proxy URL | String | Proxy for the PagerDuty notifications. |
| Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |
| Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). |
### Opsgenie {#opsgenie-254-257}
@@ -306,8 +309,9 @@ Opsgenie Responders:
The YAML provided here will be directly appended to your receiver within the Alertmanager Config Secret.
</TabItem>
<TabItem label="Rancher v2.5.0-2.5.3">
<TabItem value="Rancher v2.5.0-2.5.3">
The Alertmanager must be configured in YAML, as shown in these [examples.](#example-alertmanager-configs)
</TabItem>
</Tabs>
@@ -326,11 +330,11 @@ You can also set up multiple receivers by using the `continue` option for a rout
To set up notifications via Slack, the following Alertmanager Config YAML can be placed into the `alertmanager.yaml` key of the Alertmanager Config Secret, where the `api_url` should be updated to use your Webhook URL from Slack:
```yaml
route:
route:
group_by: ['job']
group_wait: 30s
group_interval: 5m
repeat_interval: 3h
repeat_interval: 3h
receiver: 'slack-notifications'
receivers:
- name: 'slack-notifications'
versioned_docs/version-2.5/v2.5/en/monitoring-alerting/configuration/route/route.md
+7 -2
View File
@@ -4,6 +4,9 @@ shortTitle: Routes
weight: 5
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The route configuration is the section of the Alertmanager custom resource that controls how the alerts fired by Prometheus are grouped and filtered before they reach the receiver.
When a Route is changed, the Prometheus Operator regenerates the Alertmanager custom resource to reflect the changes.
@@ -37,7 +40,7 @@ Labels should be used for identifying information that can affect the routing of
Annotations should be used for information that does not affect who receives the alert, such as a runbook url or error message.
<Tabs>
<TabItem label="Rancher v2.5.4+">
<TabItem value="Rancher v2.5.4+">
### Receiver
The route needs to refer to a [receiver](#receiver-configuration) that has already been configured.
@@ -68,7 +71,9 @@ match_re:
```
</TabItem>
<TabItem label="Rancher v2.5.0-2.5.3">
<TabItem value="Rancher v2.5.0-2.5.3">
The Alertmanager must be configured in YAML, as shown in this [example.](../examples/#alertmanager-config)
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/monitoring-alerting/guides/enable-monitoring/enable-monitoring.md
+5 -3
View File
@@ -3,6 +3,9 @@ title: Enable Monitoring
weight: 1
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
As an [administrator]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/global-permissions/) or [cluster owner]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), you can configure Rancher to deploy Prometheus to monitor your Kubernetes cluster.
This page describes how to enable monitoring and alerting within a cluster using the new monitoring application.
@@ -33,7 +36,7 @@ For more information about the default limits, see [this page.]({{<baseurl>}}/ra
# Install the Monitoring Application
<Tabs>
<TabItem label="Rancher v2.5.8">
<TabItem value="Rancher v2.5.8">
### Enable Monitoring for use without SSL
@@ -71,7 +74,7 @@ key.pfx=`base64-content`
Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`.
</TabItem>
<TabItem label="Rancher v2.5.0-2.5.7">
<TabItem value="Rancher v2.5.0-2.5.7">
1. In the Rancher UI, go to the cluster where you want to install monitoring and click **Cluster Explorer.**
1. Click **Apps.**
@@ -82,5 +85,4 @@ Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`.
**Result:** The monitoring app is deployed in the `cattle-monitoring-system` namespace.
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/monitoring-alerting/guides/persist-grafana/persist-grafana.md
+9 -5
View File
@@ -6,6 +6,9 @@ aliases:
- /rancher/v2.x/en/monitoring-alerting/v2.5/persist-grafana/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
To allow the Grafana dashboard to persist after the Grafana instance restarts, add the dashboard configuration JSON into a ConfigMap. ConfigMaps also allow the dashboards to be deployed with a GitOps or CD based approach. This allows the dashboard to be put under version control.
- [Creating a Persistent Grafana Dashboard](#creating-a-persistent-grafana-dashboard)
@@ -14,10 +17,10 @@ To allow the Grafana dashboard to persist after the Grafana instance restarts, a
# Creating a Persistent Grafana Dashboard
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
> **Prerequisites:**
>
>
> - The monitoring application needs to be installed.
> - To create the persistent dashboard, you must have at least the **Manage Config Maps** Rancher RBAC permissions assigned to you in the project or namespace that contains the Grafana Dashboards. This correlates to the `monitoring-dashboard-edit` or `monitoring-dashboard-admin` Kubernetes native RBAC Roles exposed by the Monitoring chart.
> - To see the links to the external monitoring UIs, including Grafana dashboards, you will need at least a [project-member role.]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/rbac/#users-with-rancher-cluster-manager-based-permissions)
@@ -39,7 +42,7 @@ To use your own dashboard:
### 2. Create a ConfigMap using the Grafana JSON model
Create a ConfigMap in the namespace that contains your Grafana Dashboards (e.g. cattle-dashboards by default).
Create a ConfigMap in the namespace that contains your Grafana Dashboards (e.g. cattle-dashboards by default).
The ConfigMap should look like this:
@@ -85,9 +88,10 @@ grafana.sidecar.dashboards.searchNamespace=ALL
Note that the RBAC roles exposed by the Monitoring chart to add Grafana Dashboards are still restricted to giving permissions for users to add dashboards in the namespace defined in `grafana.dashboards.namespace`, which defaults to `cattle-dashboards`.
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
> **Prerequisites:**
>
>
> - The monitoring application needs to be installed.
> - You must have the cluster-admin ClusterRole permission.
versioned_docs/version-2.5/v2.5/en/pipelines/pipelines.md
+14 -8
View File
@@ -2,10 +2,13 @@
title: Pipelines
weight: 10
aliases:
- /rancher/v2.5/en/k8s-in-rancher/pipelines
- /rancher/v2.5/en/k8s-in-rancher/pipelines
- /rancher/v2.x/en/pipelines/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
> As of Rancher v2.5, Git-based deployment pipelines are now deprecated. We recommend handling pipelines with Rancher Continuous Delivery powered by [Fleet]({{<baseurl>}}/rancher/v2.5/en/deploy-across-clusters/fleet), available in Cluster Explorer.
>
>**Notice:** Fleet does not replace Rancher pipelines; the distinction is that Rancher pipelines are now powered by Fleet.
@@ -19,7 +22,7 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins
- Build your application from code to image.
- Validate your builds.
- Deploy your build images to your cluster.
- Run unit tests.
- Run unit tests.
- Run regression tests.
>**Note:** Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses.
@@ -95,7 +98,8 @@ Before you can start configuring a pipeline for your repository, you must config
Select your provider's tab below and follow the directions.
<Tabs>
<TabItem label="GitHub">
<TabItem value="GitHub">
1. From the **Global** view, navigate to the project that you want to configure pipelines.
1. Select **Tools > Pipelines** in the navigation bar.
@@ -109,7 +113,7 @@ Select your provider's tab below and follow the directions.
1. Click **Authenticate**.
</TabItem>
<TabItem label="GitLab">
<TabItem value="GitLab">
1. From the **Global** view, navigate to the project that you want to configure pipelines.
@@ -124,10 +128,11 @@ Select your provider's tab below and follow the directions.
1. Click **Authenticate**.
>**Note:**
> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
> 2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
</TabItem>
<TabItem label="Bitbucket Cloud">
<TabItem value="Bitbucket Cloud">
1. From the **Global** view, navigate to the project that you want to configure pipelines.
@@ -142,7 +147,7 @@ Select your provider's tab below and follow the directions.
1. Click **Authenticate**.
</TabItem>
<TabItem label="Bitbucket Server">
<TabItem value="Bitbucket Server">
1. From the **Global** view, navigate to the project that you want to configure pipelines.
@@ -162,6 +167,7 @@ Select your provider's tab below and follow the directions.
> 1. Setup Rancher server with a certificate from a trusted CA.
> 1. If you're using self-signed certificates, import Rancher server's certificate to the Bitbucket server. For instructions, see the Bitbucket server documentation for [configuring self-signed certificates](https://confluence.atlassian.com/bitbucketserver/if-you-use-self-signed-certificates-938028692.html).
>
</TabItem>
</Tabs>
@@ -206,7 +212,7 @@ Now that repositories are added to your project, you can start configuring the p
1. Set up the trigger rules for the pipeline.
1. Enter a **Timeout** for the pipeline.
1. Enter a **Timeout** for the pipeline.
1. When all the stages and steps are configured, click **Done**.
versioned_docs/version-2.5/v2.5/en/pipelines/storage/storage.md
+35 -49
View File
@@ -6,6 +6,9 @@ aliases:
- /rancher/v2.x/en/pipelines/storage/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
The pipelines' internal Docker registry and the Minio workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.
This section assumes that you understand how persistent storage works in Kubernetes. For more information, refer to the section on [how storage works.]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/volumes-and-storage/how-storage-works/)
@@ -26,35 +29,26 @@ This section assumes that you understand how persistent storage works in Kuberne
- **Add Volume > Use an existing persistent volume (claim)**
1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
<Tabs>
<TabItem label="Add a new persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
<Tabs>
<TabItem value="Add a new persistent volume">
1. Select a volume claim **Source**:
1. Enter a **Name** for the volume claim.
1. Select a volume claim **Source**:
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
</TabItem>
<TabItem value="Use an existing persistent volume">
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
1. Click **Define**.
</TabItem>
<TabItem label="Use an existing persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
</TabItem>
</Tabs>
</TabItem>
</Tabs>
1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container.
@@ -70,34 +64,26 @@ This section assumes that you understand how persistent storage works in Kuberne
- **Add Volume > Use an existing persistent volume (claim)**
1. Complete the form that displays to choose a persistent volume for the internal Docker registry.
<Tabs>
<Tabs>
<TabItem value="Add a new persistent volume">
<TabItem label="Add a new persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
1. Enter a **Name** for the volume claim.
1. Select a volume claim **Source**:
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
1. Select a volume claim **Source**:
</TabItem>
<TabItem value="Use an existing persistent volume">
- If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**.
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
- If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
</TabItem>
<TabItem label="Use an existing persistent volume">
<br/>
1. Enter a **Name** for the volume claim.
1. Choose a **Persistent Volume Claim** from the drop-down.
1. From the **Customize** section, choose the read/write access for the volume.
1. Click **Define**.
</TabItem>
</Tabs>
</TabItem>
</Tabs>
1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container.
versioned_docs/version-2.5/v2.5/en/user-settings/preferences/preferences.md
+8 -2
View File
@@ -5,12 +5,16 @@ aliases:
- /rancher/v2.x/en/user-settings/preferences/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Each user can choose preferences to personalize their Rancher experience. To change preference settings, open the **User Settings** menu and then select **Preferences**.
The preferences available will differ depending on whether the **User Settings** menu was accessed while on the Cluster Manager UI or the Cluster Explorer UI.
<Tabs>
<TabItem label="Cluster Manager">
<TabItem value="Cluster Manager">
## Theme
Choose your background color for the Rancher UI. If you choose **Auto**, the background color changes from light to dark at 6 PM, and then changes back at 6 AM.
@@ -23,8 +27,10 @@ This section displays the **Name** (your display name) and **Username** (your lo
On pages that display system objects like clusters or deployments in a table, you can set the number of objects that display on the page before you must paginate. The default setting is `50`.
</TabItem>
<TabItem label="Cluster Explorer">
<TabItem value="Cluster Explorer">
## Theme
Choose your background color for the Rancher UI. If you choose **Auto**, the background color changes from light to dark at 6 PM, and then changes back at 6 AM.
versioned_docs/version-2.6/v2.6/en/admin-settings/authentication/keycloak-saml/keycloak-saml.md
+8 -3
View File
@@ -4,6 +4,9 @@ description: Create a Keycloak SAML client and configure Rancher to work with Ke
weight: 1200
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
If your organization uses Keycloak Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
## Prerequisites
@@ -35,11 +38,13 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati
## Getting the IDP Metadata
<Tabs>
<TabItem label="Keycloak 5 and earlier">
<TabItem value="Keycloak 5 and earlier">
To get the IDP metadata, export a `metadata.xml` file from your Keycloak client.
From the **Installation** tab, choose the **SAML Metadata IDPSSODescriptor** format option and download your file.
</TabItem>
<TabItem label="Keycloak 6-13">
<TabItem value="Keycloak 6-13">
1. From the **Configure** section, click the **Realm Settings** tab.
1. Click the **General** tab.
@@ -78,7 +83,7 @@ You are left with something similar as the example below:
```
</TabItem>
<TabItem label="Keycloak 14+">
<TabItem value="Keycloak 14+">
1. From the **Configure** section, click the **Realm Settings** tab.
1. Click the **General** tab.
versioned_docs/version-2.6/v2.6/en/admin-settings/branding/branding.md
+13 -6
View File
@@ -3,6 +3,9 @@ title: Custom Branding
weight: 90
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Rancher v2.6 introduced the ability to customize Rancher’s branding and navigation links.
- [Changing Brand Settings](#changing-brand-settings)
@@ -15,7 +18,7 @@ Rancher v2.6 introduced the ability to customize Rancher’s branding and naviga
> **Prerequisite:** You will need to have at least cluster member permissions.
To configure the brand settings,
To configure the brand settings,
1. Click **☰ > Global settings**.
2. Click **Branding**.
@@ -41,10 +44,13 @@ You can override the primary color used throughout the UI with a custom color of
### Fixed Banners
<Tabs>
<TabItem label="Rancher before v2.6.4">
<TabItem value="Rancher before v2.6.4">
Display a custom fixed banner in the header, footer, or both.
</TabItem>
<TabItem label="Rancher v2.6.4+">
<TabItem value="Rancher v2.6.4+">
Display a custom fixed banner in the header, footer, or both.
As of Rancher v2.6.4, configuration of fixed banners has moved from the **Branding** tab to the **Banners** tab.
@@ -53,12 +59,13 @@ To configure banner settings,
1. Click **☰ > Global settings**.
2. Click **Banners**.
</TabItem>
</Tabs>
# Custom Navigation Links
In this section, you'll learn how to configure the links in the left navigation bar of the **Cluster Dashboard**. To get to the cluster dashboard,
In this section, you'll learn how to configure the links in the left navigation bar of the **Cluster Dashboard**. To get to the cluster dashboard,
1. In the upper left corner, click **☰ > Cluster Management**.
1. On the **Clusters** page, go to the cluster where you want custom navigation links and click **Explore**.
@@ -88,7 +95,7 @@ Links can be created at the top level and multiple links can be grouped together
# Link Configuration
### `name`
### `name`
Display name for the link. Required.
@@ -116,7 +123,7 @@ data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAMgAAADICAYAAACtWK6eAAAgAElEQVR4Ae
A Kubernetes annotation for the NavLink custom resource.
### `label`
### `label`
A Kubernetes label for the NavLink custom resource.

Some files were not shown because too many files have changed in this diff Show More