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
@@ -36,12 +36,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.
|
||||
@@ -79,8 +79,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.
|
||||
@@ -104,8 +104,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
|
||||
|
||||
|
||||
+6
-6
@@ -47,8 +47,8 @@ CATTLE_RESTRICTED_DEFAULT_ADMIN=true
|
||||
|
||||
The permissions for the `restricted-admin` role differ based on the Rancher version.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "v2.5.7+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="v2.5.7+">
|
||||
|
||||
The `restricted-admin` permissions are as follows:
|
||||
|
||||
@@ -56,8 +56,8 @@ The `restricted-admin` permissions are as follows:
|
||||
- Can add other users and assign them to clusters outside of the local cluster.
|
||||
- Can create other restricted admins.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "v2.5.0-v2.5.6" %}}
|
||||
</TabItem>
|
||||
<TabItem label="v2.5.0-v2.5.6">
|
||||
|
||||
The `restricted-admin` permissions are as follows:
|
||||
|
||||
@@ -67,8 +67,8 @@ The `restricted-admin` permissions are as follows:
|
||||
- Can create other restricted admins.
|
||||
- Cannot grant any permissions in the local cluster they don't currently have. (This is how Kubernetes normally operates)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Upgrading from Rancher with a Hidden Local Cluster
|
||||
|
||||
|
||||
@@ -41,8 +41,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 %}}
|
||||
{{% tab "Profiles in v2.5.4" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Profiles in v2.5.4">
|
||||
- Generic CIS 1.5
|
||||
- Generic CIS 1.6
|
||||
- RKE permissive 1.5
|
||||
@@ -53,22 +53,22 @@ In Rancher v2.4, permissive and hardened profiles were included. In Rancher v2.5
|
||||
- GKE
|
||||
- RKE2 permissive 1.5
|
||||
- RKE2 permissive 1.5
|
||||
{{% /tab %}}
|
||||
{{% tab "Profiles in v2.5.0-v2.5.3" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Profiles in v2.5.0-v2.5.3">
|
||||
- Generic CIS 1.5
|
||||
- RKE permissive
|
||||
- RKE hardened
|
||||
- EKS
|
||||
- GKE
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
<br/>
|
||||
|
||||
|
||||
The default profile and the supported CIS benchmark version depends on the type of cluster that will be scanned and the Rancher version:
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "v2.5.4" %}}
|
||||
<Tabs>
|
||||
<TabItem label="v2.5.4">
|
||||
|
||||
The `rancher-cis-benchmark` supports the CIS 1.6 Benchmark version.
|
||||
|
||||
@@ -77,8 +77,8 @@ The `rancher-cis-benchmark` supports the CIS 1.6 Benchmark version.
|
||||
- For RKE2 Kubernetes clusters, the RKE2 Permissive 1.5 profile is the default.
|
||||
- For cluster types other than RKE, RKE2, EKS and GKE, the Generic CIS 1.5 profile will be used by default.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "v2.5.0-v2.5.3" %}}
|
||||
</TabItem>
|
||||
<TabItem label="v2.5.0-v2.5.3">
|
||||
|
||||
The `rancher-cis-benchmark` supports the CIS 1.5 Benchmark version.
|
||||
|
||||
@@ -86,8 +86,8 @@ The `rancher-cis-benchmark` supports the CIS 1.5 Benchmark version.
|
||||
- EKS and GKE have their own CIS Benchmarks published by `kube-bench`. The corresponding test profiles are used by default for those clusters.
|
||||
- For cluster types other than RKE, EKS and GKE, the Generic CIS 1.5 profile will be used by default.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
> **Note:** CIS v1 cannot run on a cluster when CIS v2 is deployed. In other words, after `rancher-cis-benchmark` is installed, you can't run scans by going to the Cluster Manager view in the Rancher UI and clicking <b>Tools > CIS Scans.</b>
|
||||
|
||||
@@ -135,8 +135,8 @@ Refer to <a href="{{<baseurl>}}/rancher/v2.5/en/security/" target="_blank">the t
|
||||
|
||||
The following profiles are available:
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Profiles in v2.5.4" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Profiles in v2.5.4">
|
||||
- Generic CIS 1.5
|
||||
- Generic CIS 1.6
|
||||
- RKE permissive 1.5
|
||||
@@ -147,15 +147,15 @@ The following profiles are available:
|
||||
- GKE
|
||||
- RKE2 permissive 1.5
|
||||
- RKE2 permissive 1.5
|
||||
{{% /tab %}}
|
||||
{{% tab "Profiles in v2.5.0-v2.5.3" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Profiles in v2.5.0-v2.5.3">
|
||||
- Generic CIS 1.5
|
||||
- RKE permissive
|
||||
- RKE hardened
|
||||
- EKS
|
||||
- GKE
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
You also have the ability to customize a profile by saving a set of tests to skip.
|
||||
|
||||
|
||||
+6
-6
@@ -58,8 +58,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.
|
||||
@@ -72,8 +72,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:**
|
||||
@@ -103,8 +103,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
|
||||
|
||||
|
||||
+14
-14
@@ -4,8 +4,8 @@ shortTitle: EKS Cluster Configuration
|
||||
weight: 2
|
||||
---
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.6+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.6+">
|
||||
|
||||
### Account Access
|
||||
|
||||
@@ -152,8 +152,8 @@ The following settings are also configurable. All of these except for the "Node
|
||||
| Tags | These are tags for the managed node group and do not propagate to any of the associated resources. |
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-v2.5.5" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher v2.5.0-v2.5.5">
|
||||
|
||||
### Changes in Rancher v2.5
|
||||
|
||||
@@ -283,8 +283,8 @@ Amazon will use the [EKS-optimized AMI](https://docs.aws.amazon.com/eks/latest/u
|
||||
| Maximum ASG Size | The maximum 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. |
|
||||
| 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. |
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher prior to v2.5" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher prior to v2.5">
|
||||
|
||||
|
||||
### Account Access
|
||||
@@ -390,15 +390,15 @@ Custom AMI Override | If you want to use a custom [Amazon Machine Image](https:/
|
||||
Desired ASG Size | The number of instances that your cluster will provision.
|
||||
User Data | Custom commands can to be passed to perform automated configuration tasks **WARNING: Modifying this may cause your nodes to be unable to join the cluster.** _Note: Available as of v2.2.0_
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
### Configuring the Refresh Interval
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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.
|
||||
|
||||
@@ -410,12 +410,12 @@ 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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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 * * * *`.
|
||||
|
||||
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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -4,8 +4,8 @@ shortTitle: GKE Cluster Configuration
|
||||
weight: 3
|
||||
---
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.8+">
|
||||
|
||||
# Changes in v2.5.8
|
||||
|
||||
@@ -302,8 +302,8 @@ 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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
|
||||
|
||||
# Labels & Annotations
|
||||
@@ -449,5 +449,5 @@ 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)
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -2,8 +2,8 @@
|
||||
headless: true
|
||||
---
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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 |
|
||||
| --- | --- | ---| ---|----|
|
||||
@@ -31,8 +31,8 @@ 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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
|
||||
| Action | Rancher Launched Kubernetes Clusters | Hosted Kubernetes Clusters | Registered EKS Clusters | All Other Registered Clusters |
|
||||
| --- | --- | ---| ---|----|
|
||||
@@ -59,5 +59,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.
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -8,8 +8,8 @@ aliases:
|
||||
- /rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/gke/
|
||||
---
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.8+">
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Provisioning a GKE Cluster](#provisioning-a-gke-cluster)
|
||||
@@ -105,8 +105,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)
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
|
||||
# Prerequisites
|
||||
|
||||
@@ -159,5 +159,5 @@ You can access your cluster after its state is updated to **Active.**
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -47,8 +47,8 @@ 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 %}}
|
||||
{{% tab "Canal"%}}
|
||||
<Tabs>
|
||||
<TabItem label="Canal">
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config:
|
||||
@@ -63,9 +63,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:
|
||||
@@ -80,8 +80,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:
|
||||
|
||||
|
||||
+12
-12
@@ -20,8 +20,8 @@ The control that Rancher has to manage a registered cluster depends on the type
|
||||
|
||||
# Prerequisites
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "v2.5.9+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="v2.5.9+">
|
||||
|
||||
### Kubernetes Node Roles
|
||||
|
||||
@@ -51,8 +51,8 @@ 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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.9" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.9">
|
||||
|
||||
### Permissions
|
||||
|
||||
@@ -76,8 +76,8 @@ 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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Registering a Cluster
|
||||
|
||||
@@ -151,8 +151,8 @@ resource "rancher2_cluster" "my-eks-to-import" {
|
||||
|
||||
The control that Rancher has to manage a registered cluster depends on the type of cluster.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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)
|
||||
@@ -197,8 +197,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/)
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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,8 +236,8 @@ 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/)
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
|
||||
+6
-6
@@ -70,18 +70,18 @@ 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 %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
|
||||
To enable project network isolation as a cluster option, you will need to use Canal as the CNI.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Kubernetes Cloud Providers
|
||||
|
||||
|
||||
+6
-6
@@ -35,14 +35,14 @@ The general node requirements for networking, operating systems, and Docker are
|
||||
|
||||
### OS and Docker Requirements
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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)
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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,8 +52,8 @@ 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.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Kubernetes Version
|
||||
|
||||
|
||||
@@ -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
@@ -159,8 +159,8 @@ 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 %}}
|
||||
{{% tab "Rancher-generated Certificates" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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.
|
||||
@@ -187,8 +187,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.
|
||||
|
||||
@@ -222,8 +222,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.
|
||||
@@ -257,8 +257,8 @@ 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.
|
||||
{{% /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.
|
||||
|
||||
|
||||
+12
-12
@@ -22,8 +22,8 @@ Placeholder | Description
|
||||
|
||||
### Option A: Default Self-signed Certificate
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.8+">
|
||||
|
||||
```
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
@@ -36,8 +36,8 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
|
||||
```plain
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
@@ -49,16 +49,16 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
### Option B: Certificates from Files using Kubernetes Secrets
|
||||
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.8+">
|
||||
|
||||
|
||||
```plain
|
||||
@@ -86,8 +86,8 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
|
||||
|
||||
```plain
|
||||
@@ -112,8 +112,8 @@ 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
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Apply the Rendered Templates
|
||||
|
||||
+12
-12
@@ -138,8 +138,8 @@ Placeholder | Description
|
||||
`<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.
|
||||
`<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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 +152,8 @@ 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`
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
|
||||
```plain
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
@@ -166,8 +166,8 @@ 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`
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
@@ -188,8 +188,8 @@ Render the Rancher template, declaring your chosen options. Use the reference ta
|
||||
| `<RANCHER.YOURDOMAIN.COM>` | The DNS name you pointed at your load balancer. |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry. |
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.8+">
|
||||
|
||||
```plain
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
@@ -219,8 +219,8 @@ 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.
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
|
||||
|
||||
```plain
|
||||
@@ -249,8 +249,8 @@ 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.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
|
||||
+6
-6
@@ -14,8 +14,8 @@ 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 %}}
|
||||
{{% 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.
|
||||
|
||||
@@ -138,8 +138,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
|
||||
@@ -211,8 +211,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
@@ -24,8 +24,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.
|
||||
|
||||
@@ -109,8 +109,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.
|
||||
|
||||
@@ -288,8 +288,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.5/en/installation/other-installation-methods/air-gap/launch-kubernetes/)
|
||||
|
||||
|
||||
+8
-8
@@ -14,8 +14,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 %}}
|
||||
{{% 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.
|
||||
@@ -85,8 +85,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:
|
||||
|
||||
@@ -149,8 +149,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.
|
||||
>
|
||||
> 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)
|
||||
@@ -169,7 +169,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.5/en/installation/other-installation-methods/air-gap/populate-private-registry/)
|
||||
|
||||
+6
-6
@@ -130,8 +130,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
|
||||
|
||||
@@ -248,8 +248,8 @@ As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/
|
||||
|
||||
{{% /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.
|
||||
|
||||
@@ -342,8 +342,8 @@ 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 %}}
|
||||
{{% /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.
|
||||
|
||||
|
||||
@@ -280,8 +280,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 %}}
|
||||
{{% 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:
|
||||
```
|
||||
@@ -299,8 +299,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:
|
||||
```
|
||||
@@ -312,7 +312,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
@@ -16,8 +16,8 @@ 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 %}}
|
||||
{{% 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.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 +80,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.5/en/installation/upgrades-rollbacks/upgrades/ha) from the new Helm chart repository.
|
||||
{{% /tab %}}
|
||||
{{% tab "Docker Images" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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 +99,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
@@ -77,8 +77,8 @@ Here is an example of a command for passing in the feature flag names when rende
|
||||
|
||||
The Helm 3 command is as follows:
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.8+">
|
||||
|
||||
```
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
@@ -92,8 +92,8 @@ 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'
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
|
||||
```
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
@@ -106,8 +106,8 @@ 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'
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
The Helm 2 command is as follows:
|
||||
|
||||
|
||||
+6
-6
@@ -15,8 +15,8 @@ The Istio CNI plugin removes the need for each application pod to have a privile
|
||||
|
||||
The steps differ based on the Rancher version.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "v2.5.4+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="v2.5.4+">
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
@@ -59,8 +59,8 @@ 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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "v2.5.0-v2.5.3" %}}
|
||||
</TabItem>
|
||||
<TabItem label="v2.5.0-v2.5.3">
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
@@ -107,5 +107,5 @@ Follow the [primary instructions]({{<baseurl>}}/rancher/v2.5/en/istio/setup/enab
|
||||
|
||||
After Istio has finished installing, the Apps page in System Projects should show both istio and `istio-cni` applications deployed successfully. Sidecar injection will now be functional.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
@@ -21,8 +21,8 @@ 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 %}}
|
||||
{{% tab "v2.5.6+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="v2.5.6+">
|
||||
|
||||
| Workload | CPU - Request | Memory - Request | CPU - Limit | Memory - Limit |
|
||||
|----------------------|---------------|------------|-----------------|-------------------|
|
||||
@@ -32,8 +32,8 @@ In Kubernetes, the resource request indicates that the workload will not be depl
|
||||
| proxy | 10m | 10mi | 2000m | 1024mi |
|
||||
| **Totals:** | **710m** | **2314Mi** | **6000m** | **3072Mi** |
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "v2.5.0-v2.5.5" %}}
|
||||
</TabItem>
|
||||
<TabItem label="v2.5.0-v2.5.5">
|
||||
|
||||
Workload | CPU - Request | Memory - Request | CPU - Limit | Mem - Limit | Configurable
|
||||
---------:|---------------:|---------------:|-------------:|-------------:|-------------:
|
||||
@@ -43,8 +43,8 @@ Istio-ingressgateway | 100m | 128Mi | 2000m | 1024Mi | Y |
|
||||
Others | 10m | - | - | - | Y |
|
||||
Totals: | 1710m | 3304Mi | >8800m | >6048Mi | -
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -10,8 +10,8 @@ For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai
|
||||
|
||||
# Configuration
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.8+">
|
||||
|
||||
- [Flows](#flows-2-5-8)
|
||||
- [Matches](#matches-2-5-8)
|
||||
@@ -73,8 +73,8 @@ 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`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
|
||||
- [Flows](#flows-2-5-0)
|
||||
- [Matches](#matches-2-5-0)
|
||||
@@ -130,8 +130,8 @@ Matches, filters and `Outputs` are also configured for `ClusterFlows`. The only
|
||||
|
||||
`ClusterFlows` need to be defined in YAML.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
# YAML Example
|
||||
|
||||
+6
-6
@@ -14,8 +14,8 @@ For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Ban
|
||||
|
||||
# Configuration
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="v2.5.8+">
|
||||
|
||||
- [Outputs](#outputs-2-5-8)
|
||||
- [ClusterOutputs](#clusteroutputs-2-5-8)
|
||||
@@ -68,8 +68,8 @@ 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/)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher before v2.5.8">
|
||||
|
||||
|
||||
- [Outputs](#outputs-2-5-0)
|
||||
@@ -101,8 +101,8 @@ The Rancher UI provides forms for configuring the `ClusterOutput` type, target,
|
||||
|
||||
For example configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
# YAML Examples
|
||||
|
||||
@@ -80,20 +80,20 @@ For a list of options that can be configured when the logging application is ins
|
||||
|
||||
### Windows Support
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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)
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Working with a Custom Docker Root Directory
|
||||
|
||||
@@ -19,20 +19,20 @@ Both provide choice for the what node(s) the pod will run on.
|
||||
|
||||
### Default Implementation in Rancher's Logging Stack
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
This example Pod YAML file shows a nodeSelector being used with a toleration:
|
||||
|
||||
|
||||
+6
-6
@@ -44,8 +44,8 @@ For examples, refer to the Prometheus documentation on [recording rules](https:/
|
||||
|
||||
# Configuration
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.4" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.4">
|
||||
Rancher v2.5.4 introduced the capability to configure PrometheusRules by filling out forms in the Rancher UI.
|
||||
|
||||
|
||||
@@ -81,8 +81,8 @@ Rancher v2.5.4 introduced the capability to configure PrometheusRules by filling
|
||||
| PromQL Expression | The PromQL expression to evaluate. Prometheus will evaluate the current value of this PromQL expression on every evaluation cycle and the result will be recorded as a new set of time series with the metric name as given by 'record'. For more information about expressions, refer to the [Prometheus documentation](https://prometheus.io/docs/prometheus/latest/querying/basics/) or our [example PromQL expressions.](../expression) |
|
||||
| Labels | Labels to add or overwrite before storing the result. |
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-v2.5.3" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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/)
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
+8
-8
@@ -72,8 +72,8 @@ 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 %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.8+">
|
||||
|
||||
The following types of receivers can be configured in the Rancher UI:
|
||||
|
||||
@@ -229,8 +229,8 @@ url http://rancher-alerting-drivers-sachet.ns-1.svc:9876/alert
|
||||
|
||||
<!-- https://github.com/messagebird/sachet -->
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.4-2.5.7" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher v2.5.4-2.5.7">
|
||||
|
||||
The following types of receivers can be configured in the Rancher UI:
|
||||
|
||||
@@ -305,11 +305,11 @@ Opsgenie Responders:
|
||||
|
||||
The YAML provided here will be directly appended to your receiver within the Alertmanager Config Secret.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-2.5.3" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher v2.5.0-2.5.3">
|
||||
The Alertmanager must be configured in YAML, as shown in these [examples.](#example-alertmanager-configs)
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
# Configuring Multiple Receivers
|
||||
|
||||
|
||||
@@ -36,8 +36,8 @@ 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 %}}
|
||||
{{% tab "Rancher v2.5.4+" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.4+">
|
||||
|
||||
### Receiver
|
||||
The route needs to refer to a [receiver](#receiver-configuration) that has already been configured.
|
||||
@@ -67,8 +67,8 @@ match_re:
|
||||
[ <labelname>: <regex>, ... ]
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-2.5.3" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Rancher v2.5.0-2.5.3">
|
||||
The Alertmanager must be configured in YAML, as shown in this [example.](../examples/#alertmanager-config)
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
+6
-6
@@ -32,8 +32,8 @@ For more information about the default limits, see [this page.]({{<baseurl>}}/ra
|
||||
|
||||
# Install the Monitoring Application
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8" %}}
|
||||
<Tabs>
|
||||
<TabItem label="Rancher v2.5.8">
|
||||
|
||||
### Enable Monitoring for use without SSL
|
||||
|
||||
@@ -70,8 +70,8 @@ key.pfx=`base64-content`
|
||||
|
||||
Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0-2.5.7" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.**
|
||||
@@ -81,6 +81,6 @@ 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.
|
||||
|
||||
{{% /tab %}}
|
||||
</TabItem>
|
||||
|
||||
{{% /tabs %}}
|
||||
</Tabs>
|
||||
|
||||
+6
-6
@@ -13,8 +13,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:**
|
||||
>
|
||||
@@ -84,8 +84,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.
|
||||
@@ -123,8 +123,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
|
||||
|
||||
|
||||
@@ -94,8 +94,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. From the **Global** view, navigate to the project that you want to configure pipelines.
|
||||
|
||||
1. Select **Tools > Pipelines** in the navigation bar.
|
||||
@@ -108,8 +108,8 @@ Select your provider's tab below and follow the directions.
|
||||
|
||||
1. Click **Authenticate**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "GitLab" %}}
|
||||
</TabItem>
|
||||
<TabItem label="GitLab">
|
||||
|
||||
1. From the **Global** view, navigate to the project that you want to configure pipelines.
|
||||
|
||||
@@ -126,8 +126,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. From the **Global** view, navigate to the project that you want to configure pipelines.
|
||||
|
||||
@@ -141,8 +141,8 @@ Select your provider's tab below and follow the directions.
|
||||
|
||||
1. Click **Authenticate**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Bitbucket Server" %}}
|
||||
</TabItem>
|
||||
<TabItem label="Bitbucket Server">
|
||||
|
||||
1. From the **Global** view, navigate to the project that you want to configure pipelines.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -26,8 +26,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.
|
||||
|
||||
@@ -40,9 +40,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.
|
||||
|
||||
@@ -52,9 +52,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.
|
||||
|
||||
@@ -70,9 +70,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.
|
||||
|
||||
@@ -85,8 +85,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.
|
||||
|
||||
@@ -96,8 +96,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.
|
||||
|
||||
|
||||
@@ -9,8 +9,8 @@ Each user can choose preferences to personalize their Rancher experience. To cha
|
||||
|
||||
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 %}}
|
||||
{{% tab "Cluster Manager" %}}
|
||||
<Tabs>
|
||||
<TabItem label="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 +23,8 @@ 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`.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Cluster Explorer" %}}
|
||||
</TabItem>
|
||||
<TabItem label="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.
|
||||
@@ -61,5 +61,5 @@ Hides all description boxes.
|
||||
|
||||
When deploying applications from the "Apps & Marketplace", choose whether to show only released versions of the Helm chart or to include prerelease versions as well.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
Reference in New Issue
Block a user