mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-16 10:03:28 +00:00
Updating tabs
This commit is contained in:
Jennifer Travinski
+8
-8
@@ -34,12 +34,12 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati
|
||||
|
||||
## Getting the IDP Metadata
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Keycloak 5 and earlier" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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.
|
||||
{{% /tab %}}
|
||||
{{% tab "Keycloak 6-13" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Keycloak 6-13">
|
||||
|
||||
1. From the **Configure** section, click the **Realm Settings** tab.
|
||||
1. Click the **General** tab.
|
||||
@@ -77,8 +77,8 @@ You are left with something similar as the example below:
|
||||
</EntityDescriptor>
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Keycloak 14+" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Keycloak 14+">
|
||||
|
||||
1. From the **Configure** section, click the **Realm Settings** tab.
|
||||
1. Click the **General** tab.
|
||||
@@ -102,8 +102,8 @@ The following is an example process for Firefox, but will vary slightly for othe
|
||||
1. From the details pane, click the **Response** tab.
|
||||
1. Copy the raw response data.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Configuring Keycloak in Rancher
|
||||
|
||||
|
||||
@@ -40,11 +40,11 @@ You can override the primary color used throughout the UI with a custom color of
|
||||
|
||||
### Fixed Banners
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher before v2.6.4" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher before v2.6.4">
|
||||
Display a custom fixed banner in the header, footer, or both.
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.6.4+" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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,8 +53,8 @@ To configure banner settings,
|
||||
|
||||
1. Click **☰ > Global settings**.
|
||||
2. Click **Banners**.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Custom Navigation Links
|
||||
|
||||
|
||||
+6
-6
@@ -81,24 +81,24 @@ 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 %}}
|
||||
{{% tab "Rancher before v2.6.4" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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**.
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.6.4+" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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**.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:** The member has the assigned role.
|
||||
|
||||
|
||||
@@ -7,20 +7,20 @@ weight: 24
|
||||
|
||||
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 %}}
|
||||
{{% tab "Rancher v2.6.4+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.6.4+">
|
||||
|
||||
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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.6.4" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Authentication
|
||||
|
||||
|
||||
+12
-12
@@ -9,8 +9,8 @@ By default, Kubernetes clusters require certificates and Rancher launched Kubern
|
||||
|
||||
Certificates can be rotated for the following services:
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "RKE" %}}
|
||||
<Tabs>
|
||||
<TabItem label="RKE">
|
||||
|
||||
- etcd
|
||||
- kubelet (node certificate)
|
||||
@@ -20,8 +20,8 @@ Certificates can be rotated for the following services:
|
||||
- kube-scheduler
|
||||
- kube-controller-manager
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "RKE2" %}}
|
||||
</TabItem>
|
||||
<TabItem label="RKE2">
|
||||
|
||||
- admin
|
||||
- api-server
|
||||
@@ -35,8 +35,8 @@ Certificates can be rotated for the following services:
|
||||
- kubelet
|
||||
- kube-proxy
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
> **Note:** For users who didn't rotate their webhook certificates, and they have expired after one year, please see this [page]({{<baseurl>}}/rancher/v2.6/en/troubleshooting/expired-webhook-certificates/) for help.
|
||||
|
||||
@@ -58,15 +58,15 @@ Rancher launched Kubernetes clusters have the ability to rotate the auto-generat
|
||||
|
||||
### Additional Notes
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "RKE" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "RKE2" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -55,8 +55,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 %}}
|
||||
{{% tab "By UI / API" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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.
|
||||
@@ -69,8 +69,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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "By Script" %}}
|
||||
</TabItem>
|
||||
<TabItem label="By Script">
|
||||
Rather than cleaning registered cluster nodes using the Rancher UI, you can run a script instead.
|
||||
|
||||
>**Prerequisite:**
|
||||
@@ -100,8 +100,8 @@ Rather than cleaning registered cluster nodes using the Rancher UI, you can run
|
||||
|
||||
**Result:** The script runs. All components listed for registered clusters in [What Gets Removed?](#what-gets-removed) are deleted.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Windows Nodes
|
||||
|
||||
|
||||
+6
-6
@@ -45,8 +45,8 @@ 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 %}}
|
||||
{{% tab "Canal"%}}
|
||||
<Tabs>
|
||||
<TabItem label="Canal">
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config:
|
||||
@@ -61,9 +61,9 @@ rancher_kubernetes_engine_config:
|
||||
extra_args:
|
||||
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
|
||||
```
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% tab "Calico"%}}
|
||||
<TabItem label="Calico">
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config:
|
||||
@@ -78,8 +78,8 @@ rancher_kubernetes_engine_config:
|
||||
extra_args:
|
||||
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
It is also required to enable the Docker service, you can enable the Docker service using the following command:
|
||||
|
||||
|
||||
+6
-6
@@ -43,8 +43,8 @@ The creation of this service principal returns three pieces of identification in
|
||||
|
||||
# Creating an Azure Cluster
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "RKE" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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)
|
||||
@@ -84,8 +84,8 @@ Use Rancher to create a Kubernetes cluster in Azure.
|
||||
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. Click **Create**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "RKE2" %}}
|
||||
</TabItem>
|
||||
<TabItem label="RKE2">
|
||||
|
||||
### 1. Create your cloud credentials
|
||||
|
||||
@@ -116,8 +116,8 @@ Use Rancher to create a Kubernetes cluster in Azure.
|
||||
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. Click **Create**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:**
|
||||
|
||||
|
||||
+6
-6
@@ -9,8 +9,8 @@ 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 %}}
|
||||
{{% tab "RKE" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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)
|
||||
@@ -48,8 +48,8 @@ Creating a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rk
|
||||
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. Click **Create**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "RKE2" %}}
|
||||
</TabItem>
|
||||
<TabItem label="RKE2">
|
||||
|
||||
### 1. Create your cloud credentials
|
||||
|
||||
@@ -78,8 +78,8 @@ Use Rancher to create a Kubernetes cluster in DigitalOcean.
|
||||
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. Click **Create**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:**
|
||||
|
||||
|
||||
+6
-6
@@ -23,8 +23,8 @@ 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 %}}
|
||||
{{% tab "RKE" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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)
|
||||
@@ -69,8 +69,8 @@ Add one or more node pools to your cluster. For more information about node pool
|
||||
>**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**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "RKE2" %}}
|
||||
</TabItem>
|
||||
<TabItem label="RKE2">
|
||||
|
||||
### 1. Create your cloud credentials
|
||||
|
||||
@@ -101,8 +101,8 @@ If you already have a set of cloud credentials to use, skip this section.
|
||||
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. Click **Create**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:**
|
||||
|
||||
|
||||
@@ -69,8 +69,8 @@ To install `gcloud` and `kubectl`, perform the following steps:
|
||||
- Using gcloud init, if you want to be walked through setting defaults.
|
||||
- Using gcloud config, to individually set your project ID, zone, and region.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Using gloud init" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Using gloud init">
|
||||
|
||||
1. Run gcloud init and follow the directions:
|
||||
|
||||
@@ -84,10 +84,10 @@ 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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Using gcloud config" %}}
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
<TabItem label="Using gcloud config">
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# 4. Confirm that gcloud is configured correctly
|
||||
|
||||
|
||||
+8
-8
@@ -154,8 +154,8 @@ However, irrespective of the certificate configuration, the name of the Rancher
|
||||
|
||||
> **Tip for testing and development:** This final command to install Rancher requires a domain name that forwards traffic to Rancher. If you are using the Helm CLI to set up a proof-of-concept, you can use a fake domain name when passing the `hostname` option. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`, which would expose Rancher on an IP where it is running. Production installs would require a real domain name.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher-generated Certificates" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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.
|
||||
@@ -182,8 +182,8 @@ Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are
|
||||
deployment "rancher" successfully rolled out
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Let's Encrypt" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.
|
||||
|
||||
@@ -216,8 +216,8 @@ Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are
|
||||
deployment "rancher" successfully rolled out
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Certificates from Files" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.
|
||||
@@ -251,8 +251,8 @@ 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.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
The Rancher chart configuration has many options for customizing the installation to suit your specific environment. Here are some common advanced scenarios.
|
||||
|
||||
|
||||
+6
-6
@@ -11,8 +11,8 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes
|
||||
|
||||
The steps to set up an air-gapped Kubernetes cluster on RKE or K3s are shown below.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "K3s" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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.
|
||||
|
||||
@@ -135,8 +135,8 @@ 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).
|
||||
{{% /tab %}}
|
||||
{{% tab "RKE" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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
|
||||
@@ -208,8 +208,8 @@ 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._
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
> **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
|
||||
|
||||
|
||||
+6
-6
@@ -17,8 +17,8 @@ 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 %}}
|
||||
{{% tab "Linux Only Clusters" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Linux Only Clusters">
|
||||
|
||||
For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
|
||||
|
||||
@@ -104,8 +104,8 @@ 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>
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab "Linux and Windows Clusters" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.
|
||||
|
||||
@@ -283,8 +283,8 @@ The image list, `rancher-images.txt` or `rancher-windows-images.txt`, is expecte
|
||||
```
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### [Next step for Kubernetes Installs - Launch a Kubernetes Cluster]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/air-gap/launch-kubernetes/)
|
||||
|
||||
|
||||
+8
-8
@@ -11,8 +11,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 %}}
|
||||
{{% tab "K3s" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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 +82,8 @@ 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)
|
||||
{{% /tab %}}
|
||||
{{% tab "RKE" %}}
|
||||
</TabItem>
|
||||
<TabItem label="RKE">
|
||||
|
||||
To install the Rancher management server on a high-availability RKE cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
@@ -146,8 +146,8 @@ 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)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.
|
||||
>
|
||||
> 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.6/en/backups/migrating-rancher)
|
||||
@@ -166,7 +166,7 @@ Rancher supports air gap installs using a Docker private registry on your bastio
|
||||
|
||||
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### [Next: Collect and Publish Images to your Private Registry]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/air-gap/populate-private-registry/)
|
||||
|
||||
+6
-6
@@ -125,8 +125,8 @@ To see the command to use when starting the new Rancher server container, choose
|
||||
- Docker Upgrade
|
||||
- Docker Upgrade for Air Gap Installs
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Docker Upgrade" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Docker Upgrade">
|
||||
|
||||
Select which option you had installed Rancher server
|
||||
|
||||
@@ -243,8 +243,8 @@ Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
|
||||
|
||||
{{% /accordion %}}
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker Air Gap Upgrade" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.
|
||||
|
||||
@@ -337,8 +337,8 @@ 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 %}}
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:** You have upgraded Rancher. Data from your upgraded server is now saved to the `rancher-data` container for use in future upgrades.
|
||||
|
||||
|
||||
@@ -279,8 +279,8 @@ 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 %}}
|
||||
{{% tab "SLES 15 / openSUSE Leap 15" %}}
|
||||
<Tabs>
|
||||
<TabItem label="SLES 15 / openSUSE Leap 15">
|
||||
1. SSH into the instance.
|
||||
1. Start YaST in text mode:
|
||||
```
|
||||
@@ -298,8 +298,8 @@ UDP Ports
|
||||
|
||||
1. When all required ports are enter, select **Accept**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "SLES 12 / openSUSE Leap 42" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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:
|
||||
```
|
||||
@@ -311,7 +311,7 @@ UDP Ports
|
||||
```
|
||||
SuSEfirewall2
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:** The node has the open ports required to be added to a custom cluster.
|
||||
|
||||
+6
-6
@@ -9,8 +9,8 @@ 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 %}}
|
||||
{{% tab "Helm Charts" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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.
|
||||
|
||||
@@ -73,8 +73,8 @@ 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.6/en/installation/install-rancher-on-k8s/upgrades) from the new Helm chart repository.
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker Images" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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
|
||||
@@ -92,5 +92,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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -32,8 +32,8 @@ The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configurati
|
||||
|
||||
To create notification receivers in the Rancher UI,
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.6.5+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.6.5+">
|
||||
|
||||
1. Go to the cluster where you want to create receivers. Click **Monitoring -> Alerting -> AlertManagerConfigs**.
|
||||
1. Ciick **Create**.
|
||||
@@ -42,16 +42,16 @@ To create notification receivers in the Rancher UI,
|
||||
1. Configure one or more providers for the receiver. For help filling out the forms, refer to the configuration options below.
|
||||
1. Click **Create**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.6.5" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.
|
||||
3. Configure one or more providers for the receiver. For help filling out the forms, refer to the configuration options below.
|
||||
4. Click **Create**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:** Alerts can be configured to send notifications to the receiver(s).
|
||||
|
||||
|
||||
@@ -42,8 +42,8 @@ The route needs to refer to a [receiver](#receiver-configuration) that has alrea
|
||||
|
||||
### Grouping
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.6.5+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.6.5+">
|
||||
|
||||
> **Note** As of Rancher v2.6.5 `Group By` now accepts a list of strings instead of key-value pairs. See the [upstream documentation](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#route) for details.
|
||||
|
||||
@@ -54,8 +54,8 @@ The route needs to refer to a [receiver](#receiver-configuration) that has alrea
|
||||
| Group Interval | 5m | How long to wait before sending an alert that has been added to a group of alerts for which an initial notification has already been sent. |
|
||||
| Repeat Interval | 4h | How long to wait before re-sending a given alert that has already been sent. |
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.6.5" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.6.5">
|
||||
|
||||
| Field | Default | Description |
|
||||
|-------|--------------|---------|
|
||||
@@ -64,8 +64,8 @@ The route needs to refer to a [receiver](#receiver-configuration) that has alrea
|
||||
| Group Interval | 5m | How long to wait before sending an alert that has been added to a group of alerts for which an initial notification has already been sent. |
|
||||
| Repeat Interval | 4h | How long to wait before re-sending a given alert that has already been sent. |
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
|
||||
+6
-6
@@ -10,8 +10,8 @@ To allow the Grafana dashboard to persist after the Grafana instance restarts, a
|
||||
|
||||
# Creating a Persistent Grafana Dashboard
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.8+">
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
@@ -82,8 +82,8 @@ 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`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - The monitoring application needs to be installed.
|
||||
@@ -124,8 +124,8 @@ To prevent the persistent dashboard from being deleted when Monitoring v2 is uni
|
||||
helm.sh/resource-policy: "keep"
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Known Issues
|
||||
|
||||
|
||||
@@ -100,8 +100,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 %}}
|
||||
{{% tab "GitHub" %}}
|
||||
<Tabs>
|
||||
<TabItem label="GitHub">
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where you want to configure pipelines and click **Explore**.
|
||||
@@ -113,8 +113,8 @@ Select your provider's tab below and follow the directions.
|
||||
1. If you're using GitHub for enterprise, select **Use a private github enterprise installation**. Enter the host address of your GitHub installation.
|
||||
1. Click **Authenticate**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "GitLab" %}}
|
||||
</TabItem>
|
||||
<TabItem label="GitLab">
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where you want to configure pipelines and click **Explore**.
|
||||
@@ -130,8 +130,8 @@ Select your provider's tab below and follow the directions.
|
||||
>**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+.
|
||||
> 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.
|
||||
{{% /tab %}}
|
||||
{{% tab "Bitbucket Cloud" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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**.
|
||||
@@ -143,8 +143,8 @@ Select your provider's tab below and follow the directions.
|
||||
1. From Bitbucket, copy the consumer **Key** and **Secret**. Paste them into Rancher.
|
||||
1. Click **Authenticate**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Bitbucket Server" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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**.
|
||||
@@ -162,8 +162,8 @@ 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).
|
||||
>
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:** After the version control provider is authenticated, you will be automatically re-directed to start configuring which repositories you want start using with a pipeline.
|
||||
|
||||
|
||||
@@ -25,8 +25,8 @@ 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 %}}
|
||||
{{% tab "Add a new persistent volume" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Add a new persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
@@ -39,9 +39,9 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% tab "Use an existing persistent volume" %}}
|
||||
<TabItem label="Use an existing persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
@@ -51,9 +51,9 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% /tabs %}}
|
||||
</Tabs>
|
||||
|
||||
1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container.
|
||||
|
||||
@@ -72,9 +72,9 @@ 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>
|
||||
|
||||
{{% tab "Add a new persistent volume" %}}
|
||||
<TabItem label="Add a new persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
@@ -87,8 +87,8 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Use an existing persistent volume" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Use an existing persistent volume">
|
||||
<br/>
|
||||
1. Enter a **Name** for the volume claim.
|
||||
|
||||
@@ -98,8 +98,8 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
|
||||
1. Click **Define**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container.
|
||||
|
||||
|
||||
+12
-12
@@ -28,15 +28,15 @@ 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 %}}
|
||||
{{% tab "Mac and Linux" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Mac and Linux">
|
||||
|
||||
```
|
||||
scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml ~/.kube/config
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Windows" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Windows">
|
||||
|
||||
By default, "scp" is not a recognized command, so we need to install a module first.
|
||||
|
||||
@@ -50,15 +50,15 @@ Install-Module Posh-SSH
|
||||
scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml $env:USERPROFILE\.kube\config
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Edit the Rancher server URL in the kubeconfig
|
||||
|
||||
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 %}}
|
||||
{{% tab "Mac and Linux" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Mac and Linux">
|
||||
|
||||
One way to open the kubeconfig file for editing is to use Vim:
|
||||
|
||||
@@ -68,8 +68,8 @@ vi ~/.kube/config
|
||||
|
||||
Press `i` to put Vim in insert mode. To save your work, press `Esc`. Then press `:wq` and press `Enter`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Windows" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Windows">
|
||||
|
||||
In Windows Powershell, you can use `notepad.exe` for editing the kubeconfig file:
|
||||
|
||||
@@ -80,8 +80,8 @@ notepad.exe $env:USERPROFILE\.kube\config
|
||||
Once edited, either press `ctrl+s` or go to `File > Save` to save your work.
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Install Rancher with Helm
|
||||
|
||||
|
||||
Reference in New Issue
Block a user