mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-29 14:38:50 +00:00
Compare commits
212
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
7b3067229e | ||
|
|
7ec567a5a6 | ||
|
|
34beb5f7f5 | ||
|
|
79bef2c1ff | ||
|
|
785db2b776 | ||
|
|
5d05eb6118 | ||
|
|
5330e6e002 | ||
|
|
fd56e5239a | ||
|
|
ba04468ce6 | ||
|
|
d711795c24 | ||
|
|
561428df96 | ||
|
|
89d3efd25f | ||
|
|
cda28da001 | ||
|
|
3fb94fe646 | ||
|
|
8ab7324802 | ||
|
|
48f4b33402 | ||
|
|
cd940d28c5 | ||
|
|
29c8fe37f9 | ||
|
|
c1d73dd091 | ||
|
|
6c4eb63232 | ||
|
|
a0a74b9c31 | ||
|
|
fb77180158 | ||
|
|
e81da89b4e | ||
|
|
5e5385910c | ||
|
|
3c043cac1e | ||
|
|
e85792acfc | ||
|
|
3c2aaba993 | ||
|
|
0a7c7e7230 | ||
|
|
b9c5733544 | ||
|
|
87c743543a | ||
|
|
03db01f162 | ||
|
|
444bb237fe | ||
|
|
c256118aa9 | ||
|
|
cb9ac7370c | ||
|
|
680e7d4d20 | ||
|
|
84ac216b9c | ||
|
|
ab8df7f920 | ||
|
|
bc33662b1f | ||
|
|
51beaa2aeb | ||
|
|
d6a5c9cb78 | ||
|
|
e936aacd19 | ||
|
|
0d6df81676 | ||
|
|
ea8bdfc2a9 | ||
|
|
7fea577f97 | ||
|
|
558e533dd1 | ||
|
|
31cdce4a59 | ||
|
|
c30bd272c7 | ||
|
|
8979f221b8 | ||
|
|
b8cbfaa2c3 | ||
|
|
d6ef2f108f | ||
|
|
8fc6c72999 | ||
|
|
4db4014a20 | ||
|
|
ef19e6525d | ||
|
|
37df45110e | ||
|
|
1f6a00bef3 | ||
|
|
f37b7655f9 | ||
|
|
8dd35d3e02 | ||
|
|
41bc844cd3 | ||
|
|
d6e4702ca7 | ||
|
|
0316eb7e82 | ||
|
|
ef8ac6c151 | ||
|
|
28c4c6951c | ||
|
|
119888948e | ||
|
|
a784ebb49f | ||
|
|
dfcb3b7fde | ||
|
|
e18bb7cc04 | ||
|
|
0e76fd2d59 | ||
|
|
5664965fa1 | ||
|
|
224bc8168b | ||
|
|
8e216e1700 | ||
|
|
6b0b653e7c | ||
|
|
189d93d656 | ||
|
|
6406d2aea5 | ||
|
|
bbbb18eede | ||
|
|
0565314013 | ||
|
|
485b3c0c5d | ||
|
|
3ccf3ddd13 | ||
|
|
18b43d1c9c | ||
|
|
dec4286a3b | ||
|
|
7db7b7e49e | ||
|
|
7383ce704b | ||
|
|
0563bcabc1 | ||
|
|
87f7929549 | ||
|
|
1bd945da7d | ||
|
|
a670421db3 | ||
|
|
0888094685 | ||
|
|
34bd9c5aa8 | ||
|
|
1ad8d182bc | ||
|
|
4d002aa117 | ||
|
|
5f19499158 | ||
|
|
b9e7863ef8 | ||
|
|
73f1cda91a | ||
|
|
004001a047 | ||
|
|
b0b6b185b9 | ||
|
|
b78a5cb897 | ||
|
|
d8180384be | ||
|
|
de7cab1891 | ||
|
|
48bb9052b4 | ||
|
|
c8c3484196 | ||
|
|
f9bb639344 | ||
|
|
9ad451f11f | ||
|
|
43fc8c84bd | ||
|
|
a7ce4ff08f | ||
|
|
e332ff4ffa | ||
|
|
0ab94d8800 | ||
|
|
53357bc7f0 | ||
|
|
9a0df1f1ba | ||
|
|
f2a8dfaa0a | ||
|
|
ff63f11116 | ||
|
|
1e76595c2f | ||
|
|
b187a46a75 | ||
|
|
b29b762dd6 | ||
|
|
ba0fefb289 | ||
|
|
fa11eeda9f | ||
|
|
afa972e2b2 | ||
|
|
5a9d423cb6 | ||
|
|
d56729e94a | ||
|
|
17af76d76f | ||
|
|
d7dae21ca7 | ||
|
|
da7e68b044 | ||
|
|
82ed34bc7b | ||
|
|
d9ba7f2e95 | ||
|
|
2a02adeb72 | ||
|
|
513cc5c340 | ||
|
|
755080de3d | ||
|
|
a4bb88e67d | ||
|
|
c3aff0b8e4 | ||
|
|
3a6b7e866a | ||
|
|
44ac9a470a | ||
|
|
cab46bd291 | ||
|
|
befa29d935 | ||
|
|
5fd5c7f9db | ||
|
|
8e81ecac58 | ||
|
|
74f23ff609 | ||
|
|
829ec114c4 | ||
|
|
b9f1ae86c9 | ||
|
|
00ac7e524b | ||
|
|
64e634ff9a | ||
|
|
d9cab2613f | ||
|
|
813ceaa835 | ||
|
|
eb27c457de | ||
|
|
3d10005273 | ||
|
|
6fdd90be51 | ||
|
|
8fcf90f7ac | ||
|
|
0cd21101cd | ||
|
|
81637f366a | ||
|
|
2e142301f6 | ||
|
|
212fa6c3de | ||
|
|
3eb0e37387 | ||
|
|
c5a198f142 | ||
|
|
77a86a5acc | ||
|
|
22ed868912 | ||
|
|
0bce62456f | ||
|
|
4a9e9d0d0c | ||
|
|
ddabfef05e | ||
|
|
adf6d83398 | ||
|
|
9012432eb8 | ||
|
|
de769a0cca | ||
|
|
c5bd3a9126 | ||
|
|
d3780fc278 | ||
|
|
00d9654e47 | ||
|
|
f811383396 | ||
|
|
d90597785a | ||
|
|
c840cb331e | ||
|
|
ed88739bef | ||
|
|
9a4f272235 | ||
|
|
00c791500f | ||
|
|
28d6268f5f | ||
|
|
2044ea50d2 | ||
|
|
80433ba8d4 | ||
|
|
d0f2f658c9 | ||
|
|
9b25313f60 | ||
|
|
a834a55fac | ||
|
|
c6a11eaeab | ||
|
|
395d484bc7 | ||
|
|
2ae06b1abc | ||
|
|
9d1da51d63 | ||
|
|
a3d005272b | ||
|
|
4e438b5cb9 | ||
|
|
dae1b76dc6 | ||
|
|
a138306885 | ||
|
|
0b12ffe2ee | ||
|
|
6085d82833 | ||
|
|
126228f266 | ||
|
|
253f80e509 | ||
|
|
cdc3587166 | ||
|
|
1621ea5b5d | ||
|
|
76b61df25b | ||
|
|
34dda87c71 | ||
|
|
04306dd362 | ||
|
|
a242cf5486 | ||
|
|
5f6b134ddd | ||
|
|
26465bcb5f | ||
|
|
a2701ae760 | ||
|
|
03f245ac3b | ||
|
|
67c7ebcf1a | ||
|
|
962e1cdfa6 | ||
|
|
07f3aa96d0 | ||
|
|
fdb9532d8a | ||
|
|
cb914c11f6 | ||
|
|
0b9bdeab24 | ||
|
|
986e14346f | ||
|
|
1c5e39e01b | ||
|
|
43a50c7518 | ||
|
|
e9755fe5c8 | ||
|
|
021840e6f4 | ||
|
|
c32fd49367 | ||
|
|
d8f25f1e7c | ||
|
|
7b9b1e0bfc | ||
|
|
e735be11b9 | ||
|
|
ca77220901 | ||
|
|
c2dd038c3d |
@@ -22,7 +22,7 @@ jobs:
|
||||
run: yarn install --frozen-lockfile
|
||||
- name: Build website
|
||||
env:
|
||||
NODE_OPTIONS: "--max_old_space_size=5120"
|
||||
NODE_OPTIONS: "--max_old_space_size=7168"
|
||||
run: yarn build --no-minify
|
||||
|
||||
# Popular action to deploy to GitHub Pages:
|
||||
|
||||
@@ -19,10 +19,10 @@ jobs:
|
||||
- name: Install dependencies
|
||||
run: yarn install --frozen-lockfile
|
||||
- name: Check Markdown links
|
||||
run: yarn run remark --quiet --use remark-validate-links ./docs
|
||||
run: yarn run remark --quiet --frail --use remark-validate-links ./docs
|
||||
- name: Check External links
|
||||
run: yarn run remark --quiet --use remark-lint-no-dead-urls ./docs
|
||||
- name: Test build website
|
||||
env:
|
||||
NODE_OPTIONS: "--max_old_space_size=5120"
|
||||
NODE_OPTIONS: "--max_old_space_size=7168"
|
||||
run: yarn build --no-minify
|
||||
@@ -0,0 +1 @@
|
||||
* @btat @LucasSaintarbor @martyav @sunilarjun
|
||||
@@ -23,7 +23,7 @@ If a file is moved or renamed, you'll also need to edit the `sidebars.js` files
|
||||
|
||||
### Navigate the Repo
|
||||
|
||||
The file paths in the repo correspond to the URLs for pages on the docs website. The docs for the latest version of Rancher are located in `/docs`. Most index pages are found within the `/pages-for-subheaders` directory in `/docs`. All images are in `/static/img` in the top level of the repo. Older docs are found within `/versioned_docs` and generally follow the same structure as the files in `/docs`.
|
||||
The file paths in the repo correspond to the URLs for pages on the docs website. The docs for the latest version of Rancher are located in `/docs`. All images are in `/static/img` in the top level of the repo. Older docs are found within `/versioned_docs` and generally follow the same structure as the files in `/docs`.
|
||||
|
||||
### Style & Formatting
|
||||
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: API Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-reference"/>
|
||||
</head>
|
||||
|
||||
:::note
|
||||
|
||||
At this time, not all Rancher resources are available through the Rancher Kubernetes API.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: API Quick Start Guide
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/quickstart"/>
|
||||
</head>
|
||||
|
||||
You can access Rancher's resources through the Kubernetes API. This guide will help you get started on using this API as a Rancher user.
|
||||
|
||||
1. In the upper left corner, click **☰ > Global Settings**.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Projects
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/workflows/projects"/>
|
||||
</head>
|
||||
|
||||
## Creating a Project
|
||||
|
||||
Project resources may only be created on the management cluster. See below for [creating namespaces under projects in a managed cluster](#creating-a-namespace-in-a-project).
|
||||
@@ -25,6 +29,26 @@ Use `metadata.generateName` to ensure a unique project ID, but note that `kubect
|
||||
|
||||
Set `metadata.namespace` and `spec.clusterName` to the ID for the cluster the project belongs to.
|
||||
|
||||
If you create a project through a cluster member account, you must include the annotation, `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: Project
|
||||
metadata:
|
||||
annotations:
|
||||
field.cattle.io/creatorId:
|
||||
user-id
|
||||
generateName: p-
|
||||
namespace: c-m-abcde
|
||||
spec:
|
||||
clusterName: c-m-abcde
|
||||
displayName: myproject
|
||||
EOF
|
||||
```
|
||||
|
||||
Setting the `field.cattle.io/creatorId` field allows the cluster member account to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
|
||||
|
||||
### Creating a Project With a Resource Quota
|
||||
|
||||
Refer to [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/).
|
||||
@@ -107,3 +131,5 @@ Delete the project under the cluster namespace:
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde delete project p-vwxyz
|
||||
```
|
||||
|
||||
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
|
||||
|
||||
@@ -86,6 +86,8 @@ For more information, see the [Flannel GitHub Page](https://github.com/flannel-i
|
||||
|
||||
#### Weave
|
||||
|
||||
<DeprecationWeave />
|
||||
|
||||

|
||||
|
||||
Weave enables networking and network policy in Kubernetes clusters across the cloud. Additionally, it support encrypting traffic between the peers.
|
||||
@@ -184,8 +186,6 @@ The following table summarizes the different features available for each CNI net
|
||||
|
||||
## CNI Community Popularity
|
||||
|
||||
import CNIPopularityTable from '/shared-files/_cni-popularity.md';
|
||||
|
||||
<CNIPopularityTable />
|
||||
|
||||
## Which CNI Provider Should I Use?
|
||||
|
||||
+21
@@ -38,6 +38,27 @@ helm upgrade rancher ./rancher-<VERSION>.tgz \
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
#### Resolving UPGRADE FAILED Error
|
||||
|
||||
If you encounter the error message, `Error: UPGRADE FAILED: "rancher" has no deployed releases`, Rancher might have been installed via the `helm template` command. To successfully upgrade Rancher, use the following command instead:
|
||||
|
||||
```
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--no-hooks \ # prevent files for Helm hooks from being generated
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set certmanager.version=<CERTMANAGER_VERSION> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
--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
|
||||
```
|
||||
|
||||
After you run the Helm command, apply the rendered template:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system apply -R -f ./rancher
|
||||
```
|
||||
|
||||
### Option B: Certificates from Files using Kubernetes Secrets
|
||||
|
||||
```plain
|
||||
|
||||
+3
-2
@@ -4,7 +4,7 @@ description: Learn how to install Rancher in development and production environm
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster"/>
|
||||
</head>
|
||||
|
||||
In this section, you'll learn how to deploy Rancher on a Kubernetes cluster using the Helm CLI.
|
||||
@@ -160,7 +160,8 @@ helm repo update
|
||||
# Install the cert-manager Helm chart
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace
|
||||
--create-namespace \
|
||||
--set installCRDs=true
|
||||
```
|
||||
|
||||
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
|
||||
|
||||
+1
-1
@@ -78,7 +78,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
1. In the left navigation bar, click **Rancher Backups > Restore**.
|
||||
:::note
|
||||
|
||||
If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps**. Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#charts) for more information.
|
||||
If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps**. Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#access-charts) for more information.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+3
@@ -28,10 +28,13 @@ The kubeconfig can also be manually targeted for the intended cluster with the `
|
||||
Review the list of known issues for each Rancher version, which can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
|
||||
|
||||
Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](../resources/choose-a-rancher-version.md#helm-chart-repositories) aren't supported.
|
||||
|
||||
### Helm Version
|
||||
|
||||
The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
### For air-gapped installs: Populate private registry
|
||||
|
||||
@@ -4,7 +4,7 @@ description: Learn how to install Rancher in development and production environm
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/installation-and-upgrade"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade"/>
|
||||
</head>
|
||||
|
||||
This section provides an overview of the architecture options of installing Rancher, describing advantages of each option.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Installation References
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/installation-references"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references"/>
|
||||
</head>
|
||||
|
||||
Please see the following reference guides for other installation resources: [Rancher Helm chart options](helm-chart-options.md), [TLS settings](tls-settings.md), and [feature flags](feature-flags.md).
|
||||
+1
-1
@@ -4,7 +4,7 @@ description: Learn the node requirements for each node running Rancher server wh
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/installation-requirements"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-requirements"/>
|
||||
</head>
|
||||
|
||||
This page describes the software, hardware, and networking requirements for the nodes where the Rancher server will be installed. The Rancher server can be installed on a single node or a high-availability Kubernetes cluster.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Air-Gapped Helm CLI Install
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/air-gapped-helm-cli-install"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install"/>
|
||||
</head>
|
||||
|
||||
This section is about using the Helm CLI to install the Rancher server in an air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Other Installation Methods
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/other-installation-methods"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods"/>
|
||||
</head>
|
||||
|
||||
### Air Gapped Installations
|
||||
|
||||
+2
@@ -10,6 +10,8 @@ Now that you have a running RKE cluster, you can install Rancher in it. For secu
|
||||
|
||||
### Install the Helm CLI
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
Install the [Helm](https://helm.sh/docs/intro/install/) CLI on a host where you have a kubeconfig to access your Kubernetes cluster:
|
||||
|
||||
```
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Installing Rancher behind an HTTP Proxy
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/rancher-behind-an-http-proxy"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy"/>
|
||||
</head>
|
||||
|
||||
In a lot of enterprise environments, servers or VMs running on premise do not have direct Internet access, but must connect to external services through a HTTP(S) proxy for security reasons. This tutorial shows step by step how to set up a highly available Rancher installation in such an environment.
|
||||
|
||||
+6
-4
@@ -6,7 +6,9 @@ title: Troubleshooting Certificates
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting"/>
|
||||
</head>
|
||||
|
||||
### How Do I Know if My Certificates are in PEM Format?
|
||||
<DockerSupportWarning />
|
||||
|
||||
## How Do I Know if My Certificates are in PEM Format?
|
||||
|
||||
You can recognize the PEM format by the following traits:
|
||||
|
||||
@@ -48,7 +50,7 @@ VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
|
||||
-----END PRIVATE KEY-----
|
||||
```
|
||||
|
||||
### Converting a Certificate Key From PKCS8 to PKCS1
|
||||
## Converting a Certificate Key From PKCS8 to PKCS1
|
||||
|
||||
If you are using a PKCS8 certificate key file, Rancher will log the following line:
|
||||
|
||||
@@ -64,7 +66,7 @@ openssl rsa -in key.pem -out convertedkey.pem
|
||||
|
||||
You can now use `convertedkey.pem` as certificate key file for Rancher.
|
||||
|
||||
### What is the Order of Certificates if I Want to Add My Intermediate(s)?
|
||||
## What is the Order of Certificates if I Want to Add My Intermediate(s)?
|
||||
|
||||
The order of adding certificates is as follows:
|
||||
|
||||
@@ -77,7 +79,7 @@ The order of adding certificates is as follows:
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
### How Do I Validate My Certificate Chain?
|
||||
## How Do I Validate My Certificate Chain?
|
||||
|
||||
You can validate the certificate chain by using the `openssl` binary. If the output of the command (see the command example below) ends with `Verify return code: 0 (ok)`, your certificate chain is valid. The `ca.pem` file must be the same as you added to the `rancher/rancher` container.
|
||||
|
||||
|
||||
+3
-1
@@ -4,9 +4,11 @@ description: For development and testing environments only, use a Docker install
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/rancher-on-a-single-node-with-docker"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker"/>
|
||||
</head>
|
||||
|
||||
<DockerSupportWarning />
|
||||
|
||||
Rancher can be installed by running a single Docker container.
|
||||
|
||||
In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container.
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: Rolling Back Rancher Installed with Docker
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher"/>
|
||||
</head>
|
||||
|
||||
<DockerSupportWarning />
|
||||
|
||||
If a Rancher upgrade does not complete successfully, you'll have to roll back to your Rancher setup that you were using before [Docker Upgrade](upgrade-docker-installed-rancher.md). Rolling back restores:
|
||||
|
||||
- Your previous version of Rancher.
|
||||
|
||||
+2
-6
@@ -6,14 +6,10 @@ title: Upgrading Rancher Installed with Docker
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher"/>
|
||||
</head>
|
||||
|
||||
<DockerSupportWarning />
|
||||
|
||||
The following instructions will guide you through upgrading a Rancher server that was installed with Docker.
|
||||
|
||||
:::caution
|
||||
|
||||
**Docker installs are not supported in production environments.** These instructions are provided for testing and development purposes only. If you have already deployed a Docker install in production and need to upgrade to a new Rancher version, we recommend [migrating to the Helm chart install](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) before upgrading.
|
||||
|
||||
:::
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#known-upgrade-issues)** section in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums](https://forums.rancher.com/c/announcements/12). Note that upgrades to or from any chart in the [rancher-alpha repository](../../resources/choose-a-rancher-version.md#helm-chart-repositories) aren’t supported.
|
||||
|
||||
+3
-1
@@ -8,7 +8,9 @@ title: Helm Version Requirements
|
||||
|
||||
This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.
|
||||
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/helm2/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
- Helm v3.2.x or higher is required to install or upgrade Rancher v2.5.
|
||||
- Helm v2.16.0 or higher is required for Kubernetes v1.16. For the default Kubernetes version, refer to the [release notes](https://github.com/rancher/rke/releases) for the version of RKE that you are using.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Resources
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/resources"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources"/>
|
||||
</head>
|
||||
|
||||
### Docker Installations
|
||||
|
||||
@@ -145,6 +145,8 @@ Before you can perform the upgrade, you must prepare your air gapped environment
|
||||
--set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
|
||||
```
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
The Helm 2 command is as follows:
|
||||
|
||||
```plain
|
||||
|
||||
@@ -1,14 +1,11 @@
|
||||
---
|
||||
title: Rancher AWS Marketplace Quick Start
|
||||
description: Use Amazon EKS to deploy Rancher server.
|
||||
title: Rancher Prime AWS Marketplace Quick Start
|
||||
description: Deploy SUSE Rancher from the AWS Marketplace listing.
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace"/>
|
||||
</head>
|
||||
|
||||
import YouTube from '@site/src/components/YouTube'
|
||||
You can quickly deploy Rancher Prime on Amazon Elastic Kubernetes Service (EKS.) To learn more, see the [instructions](https://suse-enceladus.github.io/marketplace-docs/rancher-prime/aws/?repository=rancher-payg-billing-adapter-llc-prd) under Usage Information in the [AWS Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-f2bvszurj2p2c).
|
||||
|
||||
Amazon Elastic Kubernetes Service (EKS) can quickly [deploy Rancher to Amazon Web Services (AWS)](https://documentation.suse.com/trd/kubernetes/single-html/gs_rancher_aws-marketplace/). To learn more, see our [Amazon Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-go7ent7goo5ae). Watch the demo for a walkthrough of AWS Marketplace SUSE Rancher setup:
|
||||
|
||||
<YouTube id="9dznJ7Ons0M"/>
|
||||
|
||||
+2
-1
@@ -3,7 +3,7 @@ title: Deploying Rancher Server
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/deploy-rancher-manager"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager"/>
|
||||
</head>
|
||||
|
||||
Use one of the following guides to deploy and provision Rancher and a Kubernetes cluster in the provider of your choice.
|
||||
@@ -14,6 +14,7 @@ Use one of the following guides to deploy and provision Rancher and a Kubernetes
|
||||
- [DigitalOcean](digitalocean.md) (uses Terraform)
|
||||
- [GCP](gcp.md) (uses Terraform)
|
||||
- [Hetzner Cloud](hetzner-cloud.md) (uses Terraform)
|
||||
- [Linode](linode.md) (uses Terraform)
|
||||
- [Vagrant](vagrant.md)
|
||||
- [Equinix Metal](equinix-metal.md)
|
||||
- [Outscale](outscale-qs.md) (uses Terraform)
|
||||
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: Rancher Linode Quick Start Guide
|
||||
description: Read this step by step guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/linode"/>
|
||||
</head>
|
||||
|
||||
The following steps will quickly deploy a Rancher server on Linode in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
|
||||
|
||||
:::caution
|
||||
|
||||
The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
|
||||
|
||||
:::
|
||||
|
||||
## Prerequisites
|
||||
|
||||
:::caution
|
||||
|
||||
Deploying to Linode will incur charges.
|
||||
|
||||
:::
|
||||
|
||||
- [Linode Account](https://linode.com): The Linode account to run provision server and cluster under.
|
||||
- [Linode Personal Access Token](https://www.linode.com/docs/products/tools/api/guides/manage-api-tokens/): A Linode Personal Access Token to authenticate with.
|
||||
- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster on Linode.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
|
||||
|
||||
2. Go into the Linode folder containing the Terraform files by executing `cd quickstart/rancher/linode`.
|
||||
|
||||
3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
|
||||
|
||||
4. Edit `terraform.tfvars` and customize the following variables:
|
||||
- `linode_token` - The Linode Personal Access Token mentioned above.
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server (minimum 12 characters).
|
||||
|
||||
5. **Optional:** Modify optional variables within `terraform.tfvars`.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Linode Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/linode) for more information. Suggestions include:
|
||||
- `linode_region` - The target Linode region to provision the server and cluster in.
|
||||
- Default: `eu-central`
|
||||
- For a complete list of regions, see the [official Region Availability page](https://www.linode.com/global-infrastructure/availability/).
|
||||
- `prefix` - The prefix for all created infrastructure.
|
||||
- `linode_type` - The type/plan that all infrastructure Linodes should use.
|
||||
- Default: `g6-standard-2`
|
||||
- For a complete list of plans, see the [official Plan Types page](https://www.linode.com/docs/products/compute/compute-instances/plans/).
|
||||
|
||||
6. Run `terraform init`.
|
||||
|
||||
7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
|
||||
|
||||
```
|
||||
Apply complete! Resources: 15 added, 0 changed, 0 destroyed.
|
||||
|
||||
Outputs:
|
||||
|
||||
rancher_node_ip = xx.xx.xx.xx
|
||||
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
|
||||
workload_node_ip = yy.yy.yy.yy
|
||||
```
|
||||
|
||||
8. Paste the `rancher_server_url` from the output above into the browser and log in when prompted. The default username is `admin` and the password is defined in `rancher_server_admin_password`.
|
||||
9. `ssh` into the Rancher Server using the `id_rsa` key generated in `quickstart/rancher/linode`.
|
||||
|
||||
#### Result
|
||||
|
||||
Two Kubernetes clusters are deployed on your Linode account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
|
||||
|
||||
### What's Next?
|
||||
|
||||
Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
|
||||
|
||||
## Destroying the Environment
|
||||
|
||||
1. From the `quickstart/rancher/linode` folder, execute `terraform destroy --auto-approve`.
|
||||
|
||||
2. Wait for confirmation that all resources have been destroyed.
|
||||
@@ -3,7 +3,7 @@ title: Deploying Workloads
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/deploy-rancher-workloads"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-workloads"/>
|
||||
</head>
|
||||
|
||||
These guides walk you through the deployment of an application, including how to expose the application for use outside of the cluster.
|
||||
|
||||
@@ -73,4 +73,5 @@ When you're done using your sandbox, destroy the Rancher Server and your cluster
|
||||
|
||||
- [Amazon AWS: Destroying the Environment](../deploy-rancher-manager/aws.md#destroying-the-environment)
|
||||
- [DigitalOcean: Destroying the Environment](../deploy-rancher-manager/digitalocean.md#destroying-the-environment)
|
||||
- [Linode: Destroying the Environment](../deploy-rancher-manager/linode.md#destroying-the-environment)
|
||||
- [Vagrant: Destroying the Environment](../deploy-rancher-manager/vagrant.md#destroying-the-environment)
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Rancher Deployment Quick Start Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/quick-start-guides"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides"/>
|
||||
</head>
|
||||
|
||||
:::caution
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Advanced User Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/advanced-user-guides"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides"/>
|
||||
</head>
|
||||
|
||||
Advanced user guides are "problem-oriented" docs in which users learn how to answer questions or solve problems. The major difference between these and the new user guides is that these guides are geared toward more experienced or advanced users who have more technical needs from their documentation. These users already have an understanding of Rancher and its functions. They know what they need to accomplish; they just need additional guidance to complete some more complex task they they have encountered while working.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: CIS Scan Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/cis-scan-guides"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/cis-scan-guides"/>
|
||||
</head>
|
||||
|
||||
- [Install rancher-cis-benchmark](install-rancher-cis-benchmark.md)
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Enabling Experimental Features
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/enable-experimental-features"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features"/>
|
||||
</head>
|
||||
|
||||
Rancher includes some features that are experimental and disabled by default. You might want to enable these features, for example, if you decide that the benefits of using an [unsupported storage type](unsupported-storage-drivers.md) outweighs the risk of using an untested feature. Feature flags were introduced to allow you to try these features that are not enabled by default.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Setup Guide
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/istio-setup-guide"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide"/>
|
||||
</head>
|
||||
|
||||
This section describes how to enable Istio and start using it in your projects.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Project Resource Quotas
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/manage-project-resource-quotas"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas"/>
|
||||
</head>
|
||||
|
||||
In situations where several teams share a cluster, one team may overconsume the resources available: CPU, memory, storage, services, Kubernetes objects like pods or secrets, and so on. To prevent this overconsumption, you can apply a _resource quota_, which is a Rancher feature that limits the resources available to a project or namespace.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Project Administration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/manage-projects"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects"/>
|
||||
</head>
|
||||
|
||||
_Projects_ are objects introduced in Rancher that help organize namespaces in your Kubernetes cluster. You can use projects to create multi-tenant clusters, which allows a group of users to share the same underlying resources without interacting with each other's applications.
|
||||
|
||||
+11
-4
@@ -46,7 +46,7 @@ To use your own dashboard:
|
||||
|
||||
### 2. Create a ConfigMap using the Grafana JSON model
|
||||
|
||||
Create a ConfigMap in the namespace that contains your Grafana Dashboards (e.g. cattle-dashboards by default).
|
||||
Create a ConfigMap in the namespace that contains your Grafana Dashboards (e.g. `cattle-dashboards` by default).
|
||||
|
||||
The ConfigMap should look like this:
|
||||
|
||||
@@ -65,19 +65,26 @@ data:
|
||||
|
||||
By default, Grafana is configured to watch all ConfigMaps with the `grafana_dashboard` label within the `cattle-dashboards` namespace.
|
||||
|
||||
To specify that you would like Grafana to watch for ConfigMaps across all namespaces, refer to [this section.](#configuring-namespaces-for-the-grafana-dashboard-configmap)
|
||||
To specify that you would like Grafana to watch for ConfigMaps across all namespaces, refer to [this section](#configuring-namespaces-for-the-grafana-dashboard-configmap).
|
||||
|
||||
To create the ConfigMap in the Rancher UI,
|
||||
To create the ConfigMap through the Rancher UI, first make sure that you are currently logged in to the Grafana UI, to ensure that dashboards import without encountering permissions issues. Then, return to the Rancher UI and perform the following steps:
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to see the visualizations and click **Explore**.
|
||||
1. Click **More Resources > Core > ConfigMaps**.
|
||||
1. Click **Create**.
|
||||
1. Set up the key-value pairs similar to the example above. When entering the value for `<dashboard-name>.json`, click **Read from File** to upload the JSON data model as the value.
|
||||
1. On the **Data** tab, set up the key-value pairs similar to the example above. When entering the value for `<dashboard-name>.json`, click **Read from File** to upload the JSON data model as the value.
|
||||
1. On the **Labels & Annotations** tab, click **Add Label** and enter `grafana_dashboard` as the key, and `1` as the value.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** After the ConfigMap is created, it should show up on the Grafana UI and be persisted even if the Grafana pod is restarted.
|
||||
|
||||
:::note
|
||||
|
||||
The actual key-value pair may differ if you have modified the Helm chart to watch a different dashboard label and value.
|
||||
|
||||
:::
|
||||
|
||||
Dashboards that are persisted using ConfigMaps cannot be deleted or edited from the Grafana UI.
|
||||
|
||||
If you attempt to delete the dashboard in the Grafana UI, you will see the error message "Dashboard cannot be deleted because it was provisioned." To delete the dashboard, you will need to delete the ConfigMap.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Monitoring/Alerting Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/monitoring-alerting-guides"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/monitoring-alerting-guides"/>
|
||||
</head>
|
||||
|
||||
- [Enable monitoring](enable-monitoring.md)
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Prometheus Federator Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/prometheus-federator-guides"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides"/>
|
||||
</head>
|
||||
|
||||
- [Enable Prometheus Operator](enable-prometheus-federator.md)
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Advanced Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/advanced-configuration"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration"/>
|
||||
</head>
|
||||
|
||||
### Alertmanager
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/monitoring-v2-configuration-guides"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides"/>
|
||||
</head>
|
||||
|
||||
This page captures some of the most important options for configuring Monitoring V2 in the Rancher UI.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: About Provisioning Drivers
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/about-provisioning-drivers"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers"/>
|
||||
</head>
|
||||
|
||||
Drivers in Rancher allow you to manage which providers can be used to deploy [hosted Kubernetes clusters](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md) or [nodes in an infrastructure provider](../../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md) to allow Rancher to deploy and manage Kubernetes.
|
||||
|
||||
+1
-1
@@ -23,7 +23,7 @@ To create, edit, or delete drivers, you need _one_ of the following permissions:
|
||||
|
||||
## Activating/Deactivating Node Drivers
|
||||
|
||||
By default, Rancher only activates drivers for the most popular cloud providers, Amazon EC2, Azure, DigitalOcean and vSphere. If you want to show or hide any node driver, you can change its status.
|
||||
By default, Rancher only activates drivers for the most popular cloud providers, Amazon EC2, Azure, DigitalOcean, Linode and vSphere. If you want to show or hide any node driver, you can change its status.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: RKE Templates
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/about-rke1-templates"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates"/>
|
||||
</head>
|
||||
|
||||
RKE templates are designed to allow DevOps and security teams to standardize and simplify the creation of Kubernetes clusters.
|
||||
|
||||
+2
-2
@@ -40,8 +40,8 @@ An administrator can individually grant the role **Create RKE Templates** to any
|
||||
Alternatively, the administrator can give all new users the default permission to create RKE templates by following the following steps. This will not affect the permissions of existing users.
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles**.
|
||||
1. Go to the role named **Create new RKE Cluster Templates and click **⋮ > Edit Config**.
|
||||
1. In the left navigation bar, click **Role Templates**.
|
||||
1. Select **Create new RKE Cluster Templates** and click **⋮ > Edit Config**.
|
||||
1. Select the option **Yes: Default role for new users**.
|
||||
1. Click **Save**.
|
||||
1. If you would like new users to also be able to create RKE template revisions, enable that role as default as well.
|
||||
|
||||
-2
@@ -52,8 +52,6 @@ When you need to make changes to your infrastructure, instead of manually updati
|
||||
|
||||
- You can reverse engineer how to do define a setting in Terraform by changing the setting in Rancher, then going back and checking your Terraform state file to see how it maps to the current state of your infrastructure.
|
||||
|
||||
- If you want to manage Kubernetes cluster settings, Rancher settings, and hardware settings all in one place, use [Terraform modules](https://github.com/rancher/terraform-modules). You can pass a cluster configuration YAML file or an RKE template configuration file to a Terraform module so that the Terraform module will create it. In that case, you could use your infrastructure-as-code to manage the version control and revision history of both your Kubernetes cluster and its underlying hardware.
|
||||
|
||||
## Tip for Creating CIS Benchmark Compliant Clusters
|
||||
|
||||
This section describes one way that you can make security and compliance-related config files standard in your clusters.
|
||||
|
||||
+11
-3
@@ -4,13 +4,19 @@ weight: 10
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/authentication-config"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config"/>
|
||||
</head>
|
||||
|
||||
One of the key features that Rancher adds to Kubernetes is centralized user authentication. This feature allows your users to use one set of credentials to authenticate with any of your Kubernetes clusters.
|
||||
|
||||
This centralized user authentication is accomplished using the Rancher authentication proxy, which is installed along with the rest of Rancher. This proxy authenticates your users and forwards their requests to your Kubernetes clusters using a service account.
|
||||
|
||||
:::warning
|
||||
|
||||
The account used to enable the external provider will be granted admin permissions. If you use a test account or non-admin account, that account will still be granted admin-level permissions. See [External Authentication Configuration and Principal Users](#external-authentication-configuration-and-principal-users) to understand why.
|
||||
|
||||
:::
|
||||
|
||||
## External vs. Local Authentication
|
||||
|
||||
The Rancher authentication proxy integrates with the following external authentication services.
|
||||
@@ -77,12 +83,14 @@ To set the Rancher access level for users in the authorization service, follow t
|
||||
|
||||
## External Authentication Configuration and Principal Users
|
||||
|
||||
Configuration of external authentication requires:
|
||||
Configuring external authentication requires:
|
||||
|
||||
- A local user assigned the administrator role, called hereafter the _local principal_.
|
||||
- An external user that can authenticate with your external authentication service, called hereafter the _external principal_.
|
||||
|
||||
Configuration of external authentication affects how principal users are managed within Rancher. Follow the list below to better understand these effects.
|
||||
The configuration of external authentication also affects how principal users are managed within Rancher. Specifically, when a user account enables an external provider, it is granted admin-level permissions. This is because the local principal and external principal share the same user ID and access rights.
|
||||
|
||||
The following instructions demonstrate these effects:
|
||||
|
||||
1. Sign into Rancher as the local principal and complete configuration of external authentication.
|
||||
|
||||
|
||||
+2
-2
@@ -3,7 +3,7 @@ title: Authentication, Permissions and Global Settings
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/authentication-permissions-and-global-configuration"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration"/>
|
||||
</head>
|
||||
|
||||
After installation, the [system administrator](manage-role-based-access-control-rbac/global-permissions.md) should configure Rancher to configure authentication, authorization, security, default settings, security policies, drivers and global DNS entries.
|
||||
@@ -82,4 +82,4 @@ The following features are available under **Global Configuration**:
|
||||
- **Global DNS Entries**
|
||||
- **Global DNS Providers**
|
||||
|
||||
As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm-charts-in-rancher.md), [global DNS entries](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details.
|
||||
As these are legacy features, please see the Rancher v2.0—v2.4 docs on [catalogs](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [global DNS entries](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), and [global DNS providers](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider) for more details.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Configuring Microsoft Active Directory Federation Service (SAML)
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/configure-microsoft-ad-federation-service-saml"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-microsoft-ad-federation-service-saml"/>
|
||||
</head>
|
||||
|
||||
If your organization uses Microsoft Active Directory Federation Services (AD FS) for user authentication, you can configure Rancher to allow your users to log in using their AD FS credentials.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Configuring OpenLDAP
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/configure-openldap"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-openldap"/>
|
||||
</head>
|
||||
|
||||
If your organization uses LDAP for user authentication, you can configure Rancher to communicate with an OpenLDAP server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the organisation's central user repository, while allowing end-users to authenticate with their LDAP credentials when logging in to the Rancher UI.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Configuring Shibboleth (SAML)
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/configure-shibboleth-saml"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-shibboleth-saml"/>
|
||||
</head>
|
||||
|
||||
If your organization uses Shibboleth Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in to Rancher using their Shibboleth credentials.
|
||||
|
||||
+3
-3
@@ -11,7 +11,7 @@ Cluster and project roles define user authorization inside a cluster or project.
|
||||
To manage these roles,
|
||||
|
||||
1. Click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles** and go to the **Cluster** or **Project/Namespaces** tab.
|
||||
1. In the left navigation bar, click **Role Templates** and go to the **Cluster** or **Project/Namespaces** tab.
|
||||
|
||||
### Membership and Role Assignment
|
||||
|
||||
@@ -73,7 +73,7 @@ The following table lists the permissions available for the `Manage Nodes` role
|
||||
For details on how each cluster role can access Kubernetes resources, you can look them up in the Rancher UI:
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles**.
|
||||
1. In the left navigation bar, click **Role Templates**.
|
||||
1. Click the **Cluster** tab.
|
||||
1. Click the name of an individual role. The table shows all of the operations and resources that are permitted by the role.
|
||||
|
||||
@@ -220,7 +220,7 @@ There are two methods for changing default cluster/project roles:
|
||||
You can change the cluster or project role(s) that are automatically assigned to the creating user.
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles**.
|
||||
1. In the left navigation bar, click **Role Templates**.
|
||||
1. Click the **Cluster** or **Project/Namespaces** tab.
|
||||
1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **⋮ > Edit Config**.
|
||||
1. In the **Cluster Creator Default** or **Project Creator Default** section, enable the role as the default.
|
||||
|
||||
+3
-3
@@ -31,7 +31,7 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als
|
||||
The steps to add custom roles differ depending on the version of Rancher.
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles**.
|
||||
1. In the left navigation bar, click **Role Templates**.
|
||||
1. Select a tab to determine the scope of the role you're adding. The tabs are:
|
||||
|
||||
- **Global:** The role is valid for allowing members to manage global scoped resources.
|
||||
@@ -65,7 +65,7 @@ The custom role can then be assigned to a user or group so that the role takes e
|
||||
To create a custom role based on an existing role,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles**.
|
||||
1. In the left navigation bar, click **Role Templates**.
|
||||
1. Click the **Cluster** or **Project/Namespaces** tab. Click **Create Cluster Role** or **Create Project/Namespaces Role** depending on the scope. Note: Only cluster roles and project/namespace roles can inherit from another role.
|
||||
1. Enter a name for the role.
|
||||
1. In the **Inherit From** tab, select the role(s) that the custom role will inherit permissions from.
|
||||
@@ -86,7 +86,7 @@ Custom roles can be deleted, but built-in roles cannot be deleted.
|
||||
To delete a custom role,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles**.
|
||||
1. In the left navigation bar, click **Role Templates**.
|
||||
2. Go to the custom global role that should be deleted and click **⋮ (…) > Delete**.
|
||||
3. Click **Delete**.
|
||||
|
||||
|
||||
+276
-163
@@ -12,7 +12,7 @@ Global Permissions define user authorization outside the scope of any particular
|
||||
|
||||
- **Administrator:** These users have full control over the entire Rancher system and all clusters within it.
|
||||
|
||||
- **Restricted Admin:** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster.
|
||||
- **Restricted Admin (Deprecated) :** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster.
|
||||
|
||||
- **Standard User:** These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters.
|
||||
|
||||
@@ -20,9 +20,282 @@ Global Permissions define user authorization outside the scope of any particular
|
||||
|
||||
You cannot update or delete the built-in Global Permissions.
|
||||
|
||||
## Global Permission Assignment
|
||||
|
||||
Global permissions for local users are assigned differently than users who log in to Rancher using external authentication.
|
||||
|
||||
### Global Permissions for New Local Users
|
||||
|
||||
When you create a new local user, you assign them a global permission as you complete the **Add User** form.
|
||||
|
||||
To see the default permissions for new users,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Role Templates**.
|
||||
1. The **Role Templates** page has tabs for roles grouped by scope. Each table lists the roles in that scope. In the **Global** tab, in the **New User Default** column, the permissions given to new users by default are indicated with a checkmark.
|
||||
|
||||
You can [change the default global permissions to meet your needs.](#configuring-default-global-permissions)
|
||||
|
||||
### Global Permissions for Users with External Authentication
|
||||
|
||||
When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the **New User Default** global permissions. By default, Rancher assigns the **Standard User** permission for new users.
|
||||
|
||||
To see the default permissions for new users,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Role Templates**.
|
||||
1. The **Role Templates** page has tabs for roles grouped by scope. Each table lists the roles in that scope. In the **New User Default** column on each page, the permissions given to new users by default are indicated with a checkmark.
|
||||
|
||||
You can [change the default permissions to meet your needs.](#configuring-default-global-permissions)
|
||||
|
||||
Permissions can be [assigned](#configuring-global-permissions-for-individual-users) to an individual user.
|
||||
|
||||
You can [assign a role to everyone in the group at the same time](#configuring-global-permissions-for-groups) if the external authentication provider supports groups.
|
||||
|
||||
## Custom Global Permissions
|
||||
|
||||
Using custom permissions is convenient for providing users with narrow or specialized access to Rancher.
|
||||
|
||||
When a user from an [external authentication source](../authentication-config/authentication-config.md) signs into Rancher for the first time, they're automatically assigned a set of global permissions (hereafter, permissions). By default, after a user logs in for the first time, they are created as a user and assigned the default `user` permission. The standard `user` permission allows users to login and create clusters.
|
||||
|
||||
However, in some organizations, these permissions may extend too much access. Rather than assigning users the default global permissions of `Administrator` or `Standard User`, you can assign them a more restrictive set of custom global permissions.
|
||||
|
||||
The default roles, Administrator and Standard User, each come with multiple global permissions built into them. The Administrator role includes all global permissions, while the default user role includes three global permissions: Create Clusters, Use Catalog Templates, and User Base, which is equivalent to the minimum permission to log in to Rancher. In other words, the custom global permissions are modularized so that if you want to change the default user role permissions, you can choose which subset of global permissions are included in the new default user role.
|
||||
|
||||
Administrators can enforce custom global permissions in multiple ways:
|
||||
|
||||
- [Creating custom global roles](#custom-globalroles).
|
||||
- [Changing the default permissions for new users](#configuring-default-global-permissions).
|
||||
- [Configuring global permissions for individual users](#configuring-global-permissions-for-individual-users).
|
||||
- [Configuring global permissions for groups](#configuring-global-permissions-for-groups).
|
||||
|
||||
### Combining Built-in GlobalRoles
|
||||
|
||||
Rancher provides several GlobalRoles which grant granular permissions for certain common use cases.
|
||||
The following table lists each built-in global permission and whether it is included in the default global permissions, `Administrator`, `Standard User` and `User-Base`.
|
||||
|
||||
| Custom Global Permission | Administrator | Standard User | User-Base |
|
||||
| ---------------------------------- | ------------- | ------------- |-----------|
|
||||
| Create Clusters | ✓ | ✓ | |
|
||||
| Create RKE Templates | ✓ | ✓ | |
|
||||
| Manage Authentication | ✓ | | |
|
||||
| Manage Catalogs | ✓ | | |
|
||||
| Manage Cluster Drivers | ✓ | | |
|
||||
| Manage Node Drivers | ✓ | | |
|
||||
| Manage PodSecurityPolicy Templates | ✓ | | |
|
||||
| Manage Roles | ✓ | | |
|
||||
| Manage Settings | ✓ | | |
|
||||
| Manage Users | ✓ | | |
|
||||
| Use Catalog Templates | ✓ | ✓ | |
|
||||
| User-Base (Basic log-in access) | ✓ | ✓ | |
|
||||
|
||||
For details on which Kubernetes resources correspond to each global permission,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Role Templates**.
|
||||
1. If you click the name of an individual role, a table shows all of the operations and resources that are permitted by the role.
|
||||
|
||||
:::note Notes:
|
||||
|
||||
- Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalRoles`.
|
||||
- When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
|
||||
|
||||
:::
|
||||
|
||||
### Custom GlobalRoles
|
||||
|
||||
You can create custom GlobalRoles to satisfy use cases not directly addressed by built-in GlobalRoles.
|
||||
|
||||
Create custom GlobalRoles through the UI or through automation (such as the Rancher Kubernetes API). You can specify the same type of rules as the rules for upstream roles and clusterRoles.
|
||||
|
||||
#### Escalate and Bind verbs
|
||||
|
||||
When giving permissions on GlobalRoles, keep in mind that Rancher respects the `escalate` and `bind` verbs, in a similar fashion to [Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update).
|
||||
|
||||
Both of these verbs, which are given on the GlobalRoles resource, can grant users the permission to bypass Rancher's privilege escalation checks. This potentially allows users to become admins. Since this represents a serious security risk, `bind` and `escalate` should be distributed to users with great caution.
|
||||
|
||||
The `escalate` verb allows users to change a GlobalRole and add any permission, even if the users doesn't have the permissions in the current GlobalRole or the new version of the GlobalRole.
|
||||
|
||||
The `bind` verb allows users to create a GlobalRoleBinding to the specified GlobalRole, even if they do not have the permissions in the GlobalRole.
|
||||
|
||||
:::danger
|
||||
|
||||
The wildcard verb `*` also includes the `bind` and `escalate` verbs. This means that giving `*` on GlobalRoles to a user also gives them both `escalate` and `bind`.
|
||||
|
||||
:::
|
||||
|
||||
##### Custom GlobalRole Examples
|
||||
|
||||
To grant permission to escalate only the `test-gr` GlobalRole:
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
- apiGroups:
|
||||
- 'management.cattle.io'
|
||||
resources:
|
||||
- 'globalroles'
|
||||
resourceNames:
|
||||
- 'test-gr'
|
||||
verbs:
|
||||
- 'escalate'
|
||||
```
|
||||
|
||||
To grant permission to escalate all GlobalRoles:
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
- apiGroups:
|
||||
- 'management.cattle.io'
|
||||
resources:
|
||||
- 'globalroles'
|
||||
verbs:
|
||||
- 'escalate'
|
||||
```
|
||||
|
||||
To grant permission to create bindings (which bypass escalation checks) to only the `test-gr` GlobalRole:
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
- apiGroups:
|
||||
- 'management.cattle.io'
|
||||
resources:
|
||||
- 'globalroles'
|
||||
resourceNames:
|
||||
- 'test-gr'
|
||||
verbs:
|
||||
- 'bind'
|
||||
- apiGroups:
|
||||
- 'management.cattle.io'
|
||||
resources:
|
||||
- 'globalrolebindings'
|
||||
verbs:
|
||||
- 'create'
|
||||
```
|
||||
|
||||
Granting `*` permissions (which includes both `escalate` and `bind`):
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
- apiGroups:
|
||||
- 'management.cattle.io'
|
||||
resources:
|
||||
- 'globalroles'
|
||||
verbs:
|
||||
- '*'
|
||||
```
|
||||
|
||||
#### GlobalRole Permissions on Downstream Clusters
|
||||
|
||||
GlobalRoles can grant one or more RoleTemplates on every downstream cluster through the `inheritedClusterRoles` field. Values in this field must refer to a RoleTemplate which exists and has a `context` of Cluster.
|
||||
|
||||
With this field, users gain the specified permissions on all current or future downstream clusters. For example, consider the following GlobalRole:
|
||||
|
||||
```yaml
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: GlobalRole
|
||||
displayName: All Downstream Owner
|
||||
metadata:
|
||||
name: all-downstream-owner
|
||||
inheritedClusterRoles:
|
||||
- cluster-owner
|
||||
```
|
||||
|
||||
Any user with this permission will be a cluster-owner on all downstream clusters. If a new cluster is added, regardless of type, the user will be an owner on that cluster as well.
|
||||
|
||||
:::danger
|
||||
|
||||
Using this field on [default GlobalRoles](#configuring-default-global-permissions) may result in users gaining excessive permissions.
|
||||
|
||||
:::
|
||||
|
||||
### Configuring Default Global Permissions
|
||||
|
||||
If you want to restrict the default permissions for new users, you can remove the `user` permission as default role and then assign multiple individual permissions as default instead. Conversely, you can also add administrative permissions on top of a set of other standard permissions.
|
||||
|
||||
:::note
|
||||
|
||||
Default roles are only assigned to users added from an external authentication provider. For local users, you must explicitly assign global permissions when adding a user to Rancher. You can customize these global permissions when adding the user.
|
||||
|
||||
:::
|
||||
|
||||
To change the default global permissions that are assigned to external users upon their first log in, follow these steps:
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Role Templates**. On the **Role Templates** page, make sure the **Global** tab is selected.
|
||||
1. Find the permissions set that you want to add or remove as a default. Then edit the permission by selecting **⋮ > Edit Config**.
|
||||
1. If you want to add the permission as a default, Select **Yes: Default role for new users** and then click **Save**. If you want to remove a default permission, edit the permission and select **No**.
|
||||
|
||||
**Result:** The default global permissions are configured based on your changes. Permissions assigned to new users display a check in the **New User Default** column.
|
||||
|
||||
### Configuring Global Permissions for Individual Users
|
||||
|
||||
To configure permission for a user,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Users**.
|
||||
1. Go to the user whose access level you want to change and click **⋮ > Edit Config**.
|
||||
1. In the **Global Permissions** and **Built-in** sections, check the boxes for each permission you want the user to have. If you have created roles from the **Role Templates** page, they will appear in the **Custom** section and you can choose from them as well.
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** The user's global permissions have been updated.
|
||||
|
||||
### Configuring Global Permissions for Groups
|
||||
|
||||
If you have a group of individuals that need the same level of access in Rancher, it can save time to assign permissions to the entire group at once, so that the users in the group have the appropriate level of access the first time they sign into Rancher.
|
||||
|
||||
After you assign a custom global role to a group, the custom global role will be assigned to a user in the group when they log in to Rancher.
|
||||
|
||||
For existing users, the new permissions will take effect when the users log out of Rancher and back in again, or when an administrator [refreshes the group memberships.](#refreshing-group-memberships)
|
||||
|
||||
For new users, the new permissions take effect when the users log in to Rancher for the first time. New users from this group will receive the permissions from the custom global role in addition to the **New User Default** global permissions. By default, the **New User Default** permissions are equivalent to the **Standard User** global role, but the default permissions can be [configured.](#configuring-default-global-permissions)
|
||||
|
||||
If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default**. Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,](#refreshing-group-memberships) whichever comes first.
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
You can only assign a global role to a group if:
|
||||
|
||||
* You have set up an [external authentication provider](../authentication-config/authentication-config.md#external-vs-local-authentication)
|
||||
* The external authentication provider supports [user groups](../authentication-config/manage-users-and-groups.md)
|
||||
* You have already set up at least one user group with the authentication provider
|
||||
|
||||
:::
|
||||
|
||||
To assign a custom global role to a group, follow these steps:
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Groups**.
|
||||
1. Go to the group you want to assign a custom global role to and click **⋮ > Edit Config**.
|
||||
1. In the **Global Permissions,** **Custom,** and/or **Built-in** sections, select the permissions that the group should have.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** The custom global role will take effect when the users in the group log into Rancher.
|
||||
|
||||
### Refreshing Group Memberships
|
||||
|
||||
When an administrator updates the global permissions for a group, the changes take effect for individual group members after they log out of Rancher and log in again.
|
||||
|
||||
To make the changes take effect immediately, an administrator or cluster owner can refresh group memberships.
|
||||
|
||||
An administrator might also want to refresh group memberships if a user is removed from a group in the external authentication service. In that case, the refresh makes Rancher aware that the user was removed from the group.
|
||||
|
||||
To refresh group memberships,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Users**.
|
||||
1. Click **Refresh Group Memberships**.
|
||||
|
||||
**Result:** Any changes to the group members' permissions will take effect.
|
||||
|
||||
## Restricted Admin
|
||||
|
||||
A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation from the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster.
|
||||
:::warning Deprecated
|
||||
|
||||
The Restricted Admin role is deprecated, and will be removed in a future version of Rancher (2.10 or higher). You should make a custom role with the desired permissions instead of relying on this built-in role.
|
||||
|
||||
:::
|
||||
|
||||
A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation on the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster.
|
||||
|
||||
The `restricted-admin` can create other `restricted-admin` users with an equal level of access.
|
||||
|
||||
@@ -82,170 +355,10 @@ The following table lists the permissions and actions that a `restricted-admin`
|
||||
| | Deploy GKE cluster | Yes | Yes | Yes | |
|
||||
| | Deploy AKS cluster | Yes | Yes | Yes | |
|
||||
|
||||
|
||||
### Changing Global Administrators to Restricted Admins
|
||||
|
||||
If Rancher already has a global administrator, they should change all global administrators over to the new `restricted-admin` role.
|
||||
In previous version, the docs recommended that all users should be changed over to Restricted Admin if the role was in use. Users are now encouraged to use a custom-built role using the cluster permissions feature, and migrate any current restricted admins to use that approach.
|
||||
|
||||
This can be done through **Security > Users** and moving any Administrator role over to Restricted Administrator.
|
||||
|
||||
Signed-in users can change themselves over to the `restricted-admin` if they wish, but they should only do that as the last step, otherwise they won't have the permissions to do so.
|
||||
|
||||
## Global Permission Assignment
|
||||
|
||||
Global permissions for local users are assigned differently than users who log in to Rancher using external authentication.
|
||||
|
||||
### Global Permissions for New Local Users
|
||||
|
||||
When you create a new local user, you assign them a global permission as you complete the **Add User** form.
|
||||
|
||||
To see the default permissions for new users,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles**.
|
||||
1. The **Roles** page has tabs for roles grouped by scope. Each table lists the roles in that scope. In the **Global** tab, in the **New User Default** column, the permissions given to new users by default are indicated with a checkmark.
|
||||
|
||||
You can [change the default global permissions to meet your needs.](#configuring-default-global-permissions)
|
||||
|
||||
### Global Permissions for Users with External Authentication
|
||||
|
||||
When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the **New User Default** global permissions. By default, Rancher assigns the **Standard User** permission for new users.
|
||||
|
||||
To see the default permissions for new users,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles**.
|
||||
1. The **Roles** page has tabs for roles grouped by scope. Each table lists the roles in that scope. In the **New User Default** column on each page, the permissions given to new users by default are indicated with a checkmark.
|
||||
|
||||
You can [change the default permissions to meet your needs.](#configuring-default-global-permissions)
|
||||
|
||||
Permissions can be [assigned](#configuring-global-permissions-for-individual-users) to an individual user.
|
||||
|
||||
You can [assign a role to everyone in the group at the same time](#configuring-global-permissions-for-groups) if the external authentication provider supports groups.
|
||||
|
||||
## Custom Global Permissions
|
||||
|
||||
Using custom permissions is convenient for providing users with narrow or specialized access to Rancher.
|
||||
|
||||
When a user from an [external authentication source](../authentication-config/authentication-config.md) signs into Rancher for the first time, they're automatically assigned a set of global permissions (hereafter, permissions). By default, after a user logs in for the first time, they are created as a user and assigned the default `user` permission. The standard `user` permission allows users to login and create clusters.
|
||||
|
||||
However, in some organizations, these permissions may extend too much access. Rather than assigning users the default global permissions of `Administrator` or `Standard User`, you can assign them a more restrictive set of custom global permissions.
|
||||
|
||||
The default roles, Administrator and Standard User, each come with multiple global permissions built into them. The Administrator role includes all global permissions, while the default user role includes three global permissions: Create Clusters, Use Catalog Templates, and User Base, which is equivalent to the minimum permission to log in to Rancher. In other words, the custom global permissions are modularized so that if you want to change the default user role permissions, you can choose which subset of global permissions are included in the new default user role.
|
||||
|
||||
Administrators can enforce custom global permissions in multiple ways:
|
||||
|
||||
- [Changing the default permissions for new users](#configuring-default-global-permissions)
|
||||
- [Configuring global permissions for individual users](#configuring-global-permissions-for-individual-users)
|
||||
- [Configuring global permissions for groups](#configuring-global-permissions-for-groups)
|
||||
|
||||
### Custom Global Permissions Reference
|
||||
|
||||
The following table lists each custom global permission available and whether it is included in the default global permissions, `Administrator`, `Standard User` and `User-Base`.
|
||||
|
||||
| Custom Global Permission | Administrator | Standard User | User-Base |
|
||||
| ---------------------------------- | ------------- | ------------- |-----------|
|
||||
| Create Clusters | ✓ | ✓ | |
|
||||
| Create RKE Templates | ✓ | ✓ | |
|
||||
| Manage Authentication | ✓ | | |
|
||||
| Manage Catalogs | ✓ | | |
|
||||
| Manage Cluster Drivers | ✓ | | |
|
||||
| Manage Node Drivers | ✓ | | |
|
||||
| Manage PodSecurityPolicy Templates | ✓ | | |
|
||||
| Manage Roles | ✓ | | |
|
||||
| Manage Settings | ✓ | | |
|
||||
| Manage Users | ✓ | | |
|
||||
| Use Catalog Templates | ✓ | ✓ | |
|
||||
| User-Base (Basic log-in access) | ✓ | ✓ | |
|
||||
|
||||
For details on which Kubernetes resources correspond to each global permission,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles**.
|
||||
1. If you click the name of an individual role, a table shows all of the operations and resources that are permitted by the role.
|
||||
|
||||
:::note Notes:
|
||||
|
||||
- Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalRoles`.
|
||||
- When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
|
||||
|
||||
:::
|
||||
|
||||
### Configuring Default Global Permissions
|
||||
|
||||
If you want to restrict the default permissions for new users, you can remove the `user` permission as default role and then assign multiple individual permissions as default instead. Conversely, you can also add administrative permissions on top of a set of other standard permissions.
|
||||
|
||||
:::note
|
||||
|
||||
Default roles are only assigned to users added from an external authentication provider. For local users, you must explicitly assign global permissions when adding a user to Rancher. You can customize these global permissions when adding the user.
|
||||
|
||||
:::
|
||||
|
||||
To change the default global permissions that are assigned to external users upon their first log in, follow these steps:
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles**. On the **Roles** page, make sure the **Global** tab is selected.
|
||||
1. Find the permissions set that you want to add or remove as a default. Then edit the permission by selecting **⋮ > Edit Config**.
|
||||
1. If you want to add the permission as a default, Select **Yes: Default role for new users** and then click **Save**. If you want to remove a default permission, edit the permission and select **No**.
|
||||
|
||||
**Result:** The default global permissions are configured based on your changes. Permissions assigned to new users display a check in the **New User Default** column.
|
||||
|
||||
### Configuring Global Permissions for Individual Users
|
||||
|
||||
To configure permission for a user,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Users**.
|
||||
1. Go to the user whose access level you want to change and click **⋮ > Edit Config**.
|
||||
1. In the **Global Permissions** and **Built-in** sections, check the boxes for each permission you want the user to have. If you have created roles from the **Roles** page, they will appear in the **Custom** section and you can choose from them as well.
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** The user's global permissions have been updated.
|
||||
|
||||
### Configuring Global Permissions for Groups
|
||||
|
||||
If you have a group of individuals that need the same level of access in Rancher, it can save time to assign permissions to the entire group at once, so that the users in the group have the appropriate level of access the first time they sign into Rancher.
|
||||
|
||||
After you assign a custom global role to a group, the custom global role will be assigned to a user in the group when they log in to Rancher.
|
||||
|
||||
For existing users, the new permissions will take effect when the users log out of Rancher and back in again, or when an administrator [refreshes the group memberships.](#refreshing-group-memberships)
|
||||
|
||||
For new users, the new permissions take effect when the users log in to Rancher for the first time. New users from this group will receive the permissions from the custom global role in addition to the **New User Default** global permissions. By default, the **New User Default** permissions are equivalent to the **Standard User** global role, but the default permissions can be [configured.](#configuring-default-global-permissions)
|
||||
|
||||
If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default**. Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,](#refreshing-group-memberships) whichever comes first.
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
You can only assign a global role to a group if:
|
||||
|
||||
* You have set up an [external authentication provider](../authentication-config/authentication-config.md#external-vs-local-authentication)
|
||||
* The external authentication provider supports [user groups](../authentication-config/manage-users-and-groups.md)
|
||||
* You have already set up at least one user group with the authentication provider
|
||||
|
||||
:::
|
||||
|
||||
To assign a custom global role to a group, follow these steps:
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Groups**.
|
||||
1. Go to the group you want to assign a custom global role to and click **⋮ > Edit Config**.
|
||||
1. In the **Global Permissions,** **Custom,** and/or **Built-in** sections, select the permissions that the group should have.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** The custom global role will take effect when the users in the group log into Rancher.
|
||||
|
||||
### Refreshing Group Memberships
|
||||
|
||||
When an administrator updates the global permissions for a group, the changes take effect for individual group members after they log out of Rancher and log in again.
|
||||
|
||||
To make the changes take effect immediately, an administrator or cluster owner can refresh group memberships.
|
||||
|
||||
An administrator might also want to refresh group memberships if a user is removed from a group in the external authentication service. In that case, the refresh makes Rancher aware that the user was removed from the group.
|
||||
|
||||
To refresh group memberships,
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Users**.
|
||||
1. Click **Refresh Group Memberships**.
|
||||
|
||||
**Result:** Any changes to the group members' permissions will take effect.
|
||||
|
||||
+1
-1
@@ -36,7 +36,7 @@ You can lock roles in two contexts:
|
||||
Cluster roles and project/namespace roles can be locked, but global roles cannot.
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Roles**.
|
||||
1. In the left navigation bar, click **Role Templates**.
|
||||
1. Go to the **Cluster** tab or the **Project/Namespaces** tab.
|
||||
1. From the role that you want to lock (or unlock), select **⋮ > Edit Config**.
|
||||
1. From the **Locked** option, choose the **Yes** or **No** radio button. Then click **Save**.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Managing Role-Based Access Control (RBAC)
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/manage-role-based-access-control-rbac"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac"/>
|
||||
</head>
|
||||
|
||||
Within Rancher, each person authenticates as a _user_, which is a login that grants you access to Rancher. As mentioned in [Authentication](../authentication-config/authentication-config.md), users can either be local or external.
|
||||
|
||||
+4
-4
@@ -4,7 +4,7 @@ keywords: [rancher backup restore, rancher backup and restore, backup restore ra
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/backup-restore-and-disaster-recovery"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery"/>
|
||||
</head>
|
||||
|
||||
In this section, you'll learn how to create backups of Rancher, how to restore Rancher from backup, and how to migrate Rancher to a new Kubernetes cluster.
|
||||
@@ -91,10 +91,10 @@ A migration is performed by following [these steps.](migrate-rancher-to-new-clus
|
||||
|
||||
## Default Storage Location Configuration
|
||||
|
||||
Configure a storage location where all backups are saved by default. You will have the option to override this with each backup, but will be limited to using an S3-compatible or Minio object store.
|
||||
Configure a default storage location for your backups. There are various configuration options, such as specifying an S3-compatible object store as the location for individual backups or choosing an existing `StorageClass` during installation of the `backup-restore-operator` Helm chart. You also have the option to override the configured storage location with each backup, but are limited to using an S3-compatible or Minio object store.
|
||||
|
||||
For information on configuring these options, refer to [this page.](../../../reference-guides/backup-restore-configuration/storage-configuration.md)
|
||||
|
||||
### Example values.yaml for the rancher-backup Helm Chart
|
||||
### Example YAML File: Rancher Backup Helm Chart
|
||||
|
||||
The example [values.yaml file](../../../reference-guides/backup-restore-configuration/storage-configuration.md#example-valuesyaml-for-the-rancher-backup-helm-chart) can be used to configure the `rancher-backup` operator when the Helm CLI is used to install it.
|
||||
The example [values.yaml file](../../../reference-guides/backup-restore-configuration/storage-configuration.md#example-yaml-file-rancher-backup-helm-chart) can be used to configure the `backup-restore-operator` when the Helm CLI is used to install it.
|
||||
|
||||
+7
-5
@@ -27,7 +27,8 @@ Since Rancher can be installed on any Kubernetes cluster, you can use this backu
|
||||
|
||||
|
||||
### 1. Install the rancher-backup Helm chart
|
||||
Install the [rancher-backup chart](https://github.com/rancher/backup-restore-operator/tags), using a version in the 2.x.x major version range:
|
||||
|
||||
Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-operator/tags):
|
||||
|
||||
1. Add the Helm repository:
|
||||
|
||||
@@ -36,13 +37,14 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
|
||||
helm repo update
|
||||
```
|
||||
|
||||
1. Select and set `CHART_VERSION` variable with a 2.x.x rancher-backup release version:
|
||||
1. Set a `CHART_VERSION` variable, selecting a `rancher-backup` chart version compatible with your version of Rancher. See the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions), within the **Rancher Apps / Cluster Tools** section, to see which `rancher-backup` versions are supported:
|
||||
|
||||
```bash
|
||||
helm search repo --versions rancher-charts/rancher-backup
|
||||
CHART_VERSION=<2.x.x>
|
||||
CHART_VERSION=<chart-version>
|
||||
```
|
||||
|
||||
1. Install the charts:
|
||||
|
||||
```bash
|
||||
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
|
||||
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
|
||||
@@ -50,7 +52,7 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
|
||||
|
||||
:::note
|
||||
|
||||
The above assumes an environment with outbound connectivity to Docker Hub
|
||||
The above assumes an environment with outbound connectivity to Docker Hub.
|
||||
|
||||
For an **air-gapped environment**, use the Helm value below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup Helm chart.
|
||||
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Deploying Applications across Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/deploy-apps-across-clusters"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters"/>
|
||||
</head>
|
||||
|
||||
Rancher offers several ways to deploy applications across clusters, depending on version.
|
||||
|
||||
+130
-69
@@ -1,20 +1,48 @@
|
||||
---
|
||||
title: Helm Charts in Rancher
|
||||
title: Helm Charts and Apps
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/helm-charts-in-rancher"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher"/>
|
||||
</head>
|
||||
|
||||
In this section, you'll learn how to manage Helm chart repositories and applications in Rancher. Helm chart repositories are managed using **Apps**. It uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Helm applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.
|
||||
In this section, you'll learn how to manage Helm chart repositories and apps in Rancher.
|
||||
|
||||
## How Helm Charts Work in Rancher
|
||||
|
||||
Helm chart repositories in Rancher are managed using **Apps**.
|
||||
|
||||
Rancher uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Kubernetes applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.
|
||||
|
||||
### Catalogs, Apps, and the Rancher UI
|
||||
|
||||
[Rancher v2.4 and earlier](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI.
|
||||
|
||||
Rancher v2.5 replaced the former catalog system with a new **Apps & Marketplace** feature.
|
||||
|
||||
Since Rancher v2.6.5, the **Apps & Marketplace** feature is named **Apps** in the UI.
|
||||
|
||||
### Versioning Scheme
|
||||
|
||||
The Rancher feature charts versioning scheme is centered around the major version of the charts and the `+up` annotation for upstream charts, where applicable.
|
||||
|
||||
**Major Version:** The major version of the charts is tied to Rancher minor versions. When you upgrade to a new Rancher minor version, you should ensure that all of your **Apps** charts are also upgraded to the correct release line for the chart.
|
||||
**Major Version:** The major versions of feature charts are tied to particular minor versions of Rancher. When you upgrade to a new Rancher minor version, you should ensure that all of your feature charts are also upgraded to the correct release line for the chart.
|
||||
|
||||
**Feature Charts:**
|
||||
**Charts based on upstream:** When you upgrade, make sure that the upstream chart version is compatible with your Rancher version. The `+up` annotation for the chart indicates which upstream version the Rancher chart is tracking. For example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some additional Rancher patches.
|
||||
|
||||
When upgrading Rancher versions, don't downgrade the version of the chart that you are using. For example, if you are using a version of Monitoring that is later than `16.6.0` in Rancher v2.5, you shouldn't upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.
|
||||
|
||||
#### Prerelease Versions
|
||||
|
||||
Prereleases adhere to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` is considered a prerelease. Prerelease versions are not displayed by default and must be configured to do so.
|
||||
|
||||
To display prerelease versions:
|
||||
|
||||
1. Click on your user avatar in the upper right corner.
|
||||
1. Click **Preferences**.
|
||||
1. Under **Helm Charts**, select **Include Prerelease Versions**.
|
||||
|
||||
### Feature Charts
|
||||
|
||||
| **Name** | **Supported Minimum Version** | **Supported Maximum Version** |
|
||||
| ---------------- | ------------ | ------------ |
|
||||
@@ -35,51 +63,82 @@ The Rancher feature charts versioning scheme is centered around the major versio
|
||||
| rancher-vsphere-csi | 100.3.0+up2.5.1-rancher1 | 100.3.0+up2.5.1-rancher1 |
|
||||
| rancher-wins-upgrader | 0.0.100 | 100.0.1+up0.0.1 |
|
||||
|
||||
<br/>
|
||||
**Charts based on upstream:** For charts that are based on upstreams, the +up annotation should inform you of what upstream version the Rancher chart is tracking. Check the upstream version compatibility with Rancher during upgrades also.
|
||||
## Access Charts
|
||||
|
||||
- As an example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some Rancher patches added to it.
|
||||
The **Charts** page contains all Rancher, Partner, and Custom charts. You can filter charts by selecting the left-most dropdown menu:
|
||||
|
||||
- On upgrades, ensure that you are not downgrading the version of the chart that you are using. For example, if you are using a version of Monitoring > `16.6.0` in Rancher 2.5, you should not upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.
|
||||
* Rancher tools such as Logging or Monitoring are listed under the **Rancher** label.
|
||||
* Partner charts are under the **Partners** label.
|
||||
* Custom charts are listed under the name of their respective repository.
|
||||
|
||||
### Prerelease Versions
|
||||
|
||||
Prereleases adhere to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` is considered a prerelease. Prerelease versions are not displayed by default and must be configured to do so.
|
||||
|
||||
To display prerelease versions:
|
||||
|
||||
1. Click on your user avatar in the upper right corner.
|
||||
1. Click **Preferences**.
|
||||
1. Under **Helm Charts**, select **Include Prerelease Versions**.
|
||||
|
||||
### Charts
|
||||
|
||||
From the top-left menu select _"Apps"_ and you will be taken to the Charts page.
|
||||
|
||||
The charts page contains all Rancher, Partner, and Custom Charts.
|
||||
|
||||
* Rancher tools such as Logging or Monitoring are included under the Rancher label
|
||||
* Partner charts reside under the Partners label
|
||||
* Custom charts will show up under the name of the repository
|
||||
|
||||
All three types are deployed and managed in the same way.
|
||||
All three types of charts are deployed and managed in the same way.
|
||||
|
||||
:::note
|
||||
|
||||
Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) should continue to be managed only by the Cluster Manager, and apps managed with <b>Apps</b> in the new UI must be managed only by <b>Apps</b>.
|
||||
Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) continue to be managed only by the Cluster Manager, and apps managed with **Apps** in the new UI must be managed only by **Apps**.
|
||||
|
||||
:::
|
||||
|
||||
### Repositories
|
||||
To access the **Charts** page:
|
||||
|
||||
From the left sidebar select _"Repositories"_.
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose charts you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
|
||||
|
||||
These items represent Helm repositories, and can be either traditional Helm endpoints which have an index.yaml, or git repositories which will be cloned and can point to a specific branch. In order to use custom charts, simply add your repository here and they will become available in the Charts tab under the name of the repository.
|
||||
## Manage Repositories
|
||||
|
||||
To add a private CA for Helm Chart repositories:
|
||||
The **Repositories** page lists your Helm repositories. These include traditional Helm endpoints which have an index.yaml, and Git repositories that are cloned and point to a specific branch. To use custom charts, add your repository here. After you add a repository, you can access custom charts in the **Charts** page, listed under the name of the repository.
|
||||
|
||||
- **HTTP-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
|
||||
```
|
||||
To access the **Repositories** page:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
|
||||
### Add Custom Git Repositories
|
||||
|
||||
To add a custom Git repository that contains your Helm charts or cluster template definitions:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Click **Create**.
|
||||
1. Select the target, **Git repository containing Helm chart...**.
|
||||
1. You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from whichever branch the repo owner has set as the default. Usually, the default branch is named either `main` or `master`.
|
||||
1. Click **Create** to add the repository.
|
||||
|
||||
After you add a chart repository to Rancher, it becomes available immediately.
|
||||
|
||||
### Add Custom Helm Chart Repositories
|
||||
|
||||
You can add your own Helm chart repositories to serve chart packages to Rancher. You can use any HTTP server, as long as the server can respond to GET requests and serve YAML files and tar archives.
|
||||
|
||||
For more information on Helm chart repositories, see the [official Helm docs](https://helm.sh/docs/topics/chart_repository/).
|
||||
|
||||
To add a custom Helm chart repository to Rancher:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Click **Create**.
|
||||
1. Select the target, **http(s) URL to an index generated by Helm**.
|
||||
1. Enter a repo name and the index URL address of the chart repository.
|
||||
1. Click **Create** to add the repository.
|
||||
|
||||
### Add Private Git/Helm Chart Repositories
|
||||
|
||||
You can add private Git or Helm chart repositories with SSH key credentials or an HTTP basic auth secret, such as a username and password.
|
||||
|
||||
### Add a Private CA to Repositories
|
||||
|
||||
To add a private CA to Helm chart repositories, you must add a base64 encoded copy of the CA certificate in DER format to the `spec.caBundle field` of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Instructions are the same for both Git-based and HTTP-based repositories:
|
||||
|
||||
1. Click **☰**. Under **Explore Cluster** in the left navigation menu, select a cluster.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the row associated with the Git-based or HTTP-based repository you want to add a private CA to, and click **⋮ > Edit YAML**.
|
||||
1. Set the `caBundle` value, as in the following example:
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
spec:
|
||||
caBundle:
|
||||
@@ -87,25 +146,13 @@ To add a private CA for Helm Chart repositories:
|
||||
...
|
||||
nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
|
||||
[...]
|
||||
```
|
||||
|
||||
|
||||
- **Git-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
|
||||
```
|
||||
[...]
|
||||
spec:
|
||||
caBundle:
|
||||
MIIFXzCCA0egAwIBAgIUWNy8WrvSkgNzV0zdWRP79j9cVcEwDQYJKoZIhvcNAQELBQAwPzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYDVQQKDAtNeU9yZywgSW5jLjENMAsGA1UEAwwEcm9vdDAeFw0yMTEyMTQwODMyMTdaFw0yNDEwMDMwODMyMT
|
||||
...
|
||||
nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
|
||||
[...]
|
||||
```
|
||||
```
|
||||
|
||||
:::note Helm chart repositories with authentication
|
||||
|
||||
The Repo.Spec contains a `disableSameOriginCheck` value that allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
|
||||
The Repo.Spec contains a `disableSameOriginCheck` value. This value allows you to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories, such as those that have redirects to a different origin URL.
|
||||
|
||||
To use this feature for an existing Helm chart repository, click <b>⋮ > Edit YAML</b>. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
|
||||
To use this feature for an existing Helm chart repository, follow previous steps up to edit the YAML. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
@@ -120,37 +167,51 @@ spec:
|
||||
|
||||
Only Helm 3 compatible charts are supported.
|
||||
|
||||
## Deploy and Upgrade Charts
|
||||
|
||||
### Deployment and Upgrades
|
||||
To install and deploy a chart:
|
||||
|
||||
From the _"Charts"_ tab select a Chart to install. Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files, but all chart installations can modify the values.yaml and other basic settings. Once you click install, a Helm operation job is deployed, and the console for the job is displayed.
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
|
||||
1. Select a chart, and click **Install**.
|
||||
|
||||
To view all recent changes, go to the _"Recent Operations"_ tab. From there you can view the call that was made, conditions, events, and logs.
|
||||
Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files. However, all chart installations can modify the values.yaml and other basic settings. After you click **Install**, a Helm operation job is deployed, and the console for the job is displayed.
|
||||
|
||||
After installing a chart, you can find it in the _"Installed Apps"_ tab. In this section you can upgrade or delete the installation, and see further details. When choosing to upgrade, the form and values presented will be the same as installation.
|
||||
To view all recent changes, click **Apps > Recent Operations** in the left navigation menu. From there you can view the calls, conditions, events, and logs.
|
||||
|
||||
Most Rancher tools have additional pages located in the toolbar below the _"Apps"_ section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.
|
||||
After installing a chart, you can view it by clicking **Apps > Installed Apps** in the left navigation menu. You can upgrade or delete the installation, and see further details. Upgrading uses the same forms and values as you saw during inital installation.
|
||||
|
||||
Most Rancher tools have additional pages located in the toolbar below the **Apps** section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.
|
||||
|
||||
:::caution
|
||||
|
||||
If you are upgrading your chart using _"Customize Helm options before upgrade"_ , please be aware that using the _"--force"_ option may result in errors if your chart has immutable fields. This is because some objects in Kubernetes cannot be changed once they are created. To ensure you do not get this error you can:
|
||||
If you are upgrading your chart using **Customize Helm options before upgrade**, and your chart contains immutable fields, using the `--force` option may result in errors. This is because some objects in Kubernetes can't be changed after they're created. To prevent this error:
|
||||
|
||||
* use the default upgrade option ( i.e do not use _"--force"_ option )
|
||||
* uninstall the existing chart and install the upgraded chart
|
||||
* delete the resources with immutable fields from the cluster before performing the _"--force"_ upgrade
|
||||
* Use the default upgrade option (i.e don't use `--force`).
|
||||
* Uninstall the existing chart and install the upgraded chart.
|
||||
* Delete the resources with immutable fields from the cluster before performing a forced upgrade.
|
||||
|
||||
:::
|
||||
|
||||
#### Legacy Apps
|
||||
### Legacy Apps
|
||||
|
||||
The upgrade button has been removed for legacy apps from the **Apps > Installed Apps** page.
|
||||
The upgrade button isn't available for legacy apps on the **Apps > Installed Apps** page.
|
||||
|
||||
If you have a legacy app installed and want to upgrade it:
|
||||
If you want to upgrade an installed legacy app, the [legacy feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on. This flag is automatically turned on if you had a legacy app already running before you upgraded Rancher.
|
||||
|
||||
- The legacy [feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on (if it's not turned on automatically because of having a legacy app before upgrading)
|
||||
- You can upgrade the app from cluster explorer, from the left nav section **Legacy > Project > Apps**
|
||||
- For multi-cluster apps, you can go to **≡ > Multi-cluster Apps** and upgrade the app from there
|
||||
1. Enable the [legacy feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md), if it isn't enabled already.
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose apps you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. Click **Legacy > Project > Apps**.
|
||||
|
||||
### Limitations
|
||||
If you don't see **Apps** listed under **Legacy > Project**, click the project/namespace search bar in the top navigation and select the relevant project from the dropdown menu.
|
||||
|
||||
Dashboard apps or Rancher feature charts **cannot** be installed using the Rancher CLI.
|
||||
To upgrade legacy multi-cluster apps:
|
||||
|
||||
1. Click **☰**.
|
||||
1. Under **Legacy Apps**, click **Multi-cluster Apps**.
|
||||
|
||||
## Limitations
|
||||
|
||||
Dashboard apps or Rancher feature charts can't be installed using the Rancher CLI.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Don't have infrastructure for your Kubernetes cluster? Try one of these t
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/infrastructure-setup"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/infrastructure-setup"/>
|
||||
</head>
|
||||
|
||||
To set up infrastructure for a high-availability K3s Kubernetes cluster with an external DB, refer to [this page.](ha-k3s-kubernetes-cluster.md)
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: "Don't have a Kubernetes cluster? Try one of these tutorials."
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/kubernetes-cluster-setup"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-cluster-setup"/>
|
||||
</head>
|
||||
|
||||
This section contains information on how to install a Kubernetes cluster that the Rancher server can be installed on.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Checklist for Production-Ready Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/checklist-for-production-ready-clusters"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters"/>
|
||||
</head>
|
||||
|
||||
In this section, we recommend best practices for creating the production-ready Kubernetes clusters that will run your apps and services.
|
||||
|
||||
+1
-1
@@ -4,7 +4,7 @@ description: Provisioning Kubernetes Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/kubernetes-clusters-in-rancher-setup"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup"/>
|
||||
</head>
|
||||
|
||||
Rancher simplifies the creation of clusters by allowing you to create them through the Rancher UI rather than more complex alternatives. Rancher provides multiple options for launching a cluster. Use the option that best fits your use case.
|
||||
|
||||
+4
-4
@@ -6,13 +6,13 @@ title: Migrating Amazon In-tree to Out-of-tree
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-amazon"/>
|
||||
</head>
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. In Kubernetes 1.27 and later, the in-tree cloud providers have been removed.
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. In Kubernetes v1.27 and later, the in-tree cloud providers have been removed. The Rancher UI allows you to upgrade to Kubernetes v1.27 when you migrate from an in-tree to out-of-tree provider.
|
||||
|
||||
You can migrate from an in-tree to an out-of-tree AWS cloud provider on Kubernetes 1.26 and earlier. All existing clusters must migrate prior to upgrading to v1.27 in order to stay functional.
|
||||
However, if you're performing a manual migration, existing clusters must upgrade to Kubernetes v1.27 after you migrate in order to remain functional.
|
||||
|
||||
To migrate from the in-tree cloud provider to the out-of-tree AWS cloud provider, you must stop the existing cluster's kube controller manager and install the AWS cloud controller manager. There are many ways to do this. Refer to the official AWS documentation on the [external cloud controller manager](https://cloud-provider-aws.sigs.k8s.io/getting_started/) for details.
|
||||
|
||||
If it's acceptable to have some downtime, you can [switch to an external cloud provider](../set-up-cloud-providers/amazon.md#using-the-out-of-tree-aws-cloud-provider), which removes in-tree components and then deploy charts to install the AWS cloud controller manager.
|
||||
If it's acceptable to have some downtime during migration, follow the instructions to [set up an external cloud provider](../set-up-cloud-providers/amazon.md#using-the-out-of-tree-aws-cloud-provider). These instructions outline how to configure the out-of-tree cloud provider for a newly provisioned cluster. During set up, there will be some downtime, as there is a time gap between when the old cloud provider stops running and when the new cloud provider starts to run.
|
||||
|
||||
If your setup can't tolerate any control plane downtime, you must enable leader migration. This facilitates a smooth transition from the controllers in the kube controller manager to their counterparts in the cloud controller manager. Refer to the official AWS documentation on [Using leader migration](https://cloud-provider-aws.sigs.k8s.io/getting_started/) for more details.
|
||||
|
||||
@@ -52,7 +52,7 @@ spec:
|
||||
2. Cordon control plane nodes so that AWS cloud controller pods run on nodes only after upgrading to the external cloud provider:
|
||||
|
||||
```shell
|
||||
kubectl cordon -l "node-role.kubernetes.io/controlplane=true"
|
||||
kubectl cordon -l "node-role.kubernetes.io/control-plane=true"
|
||||
```
|
||||
|
||||
3. To install the AWS cloud controller manager with leader migration enabled, follow Steps 1-3 for [deploying the cloud controller manager chart](../set-up-cloud-providers/amazon.md#using-the-out-of-tree-aws-cloud-provider). From Kubernetes 1.22 onwards, the kube-controller-manager will utilize a default configuration which will satisfy the controller-to-manager migration. Update container args of the `aws-cloud-controller-manager` under `spec.rkeConfig.additionalManifest` to enable leader migration:
|
||||
|
||||
+6
-6
@@ -352,9 +352,9 @@ tolerations:
|
||||
value: 'true'
|
||||
- effect: NoSchedule
|
||||
value: 'true'
|
||||
key: node-role.kubernetes.io/controlplane
|
||||
key: node-role.kubernetes.io/control-plane
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/controlplane: 'true'
|
||||
node-role.kubernetes.io/control-plane: 'true'
|
||||
args:
|
||||
- --configure-cloud-routes=false
|
||||
- --use-service-account-credentials=true
|
||||
@@ -639,7 +639,7 @@ kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
|
||||
- get
|
||||
```
|
||||
|
||||
9. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector:
|
||||
9. Rancher-provisioned RKE2 nodes are tainted `node-role.kubernetes.io/control-plane`. Update tolerations and the nodeSelector:
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
@@ -648,13 +648,13 @@ tolerations:
|
||||
value: 'true'
|
||||
- effect: NoSchedule
|
||||
value: 'true'
|
||||
key: node-role.kubernetes.io/controlplane
|
||||
key: node-role.kubernetes.io/control-plane
|
||||
|
||||
```
|
||||
|
||||
```yaml
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/controlplane: 'true'
|
||||
node-role.kubernetes.io/control-plane: 'true'
|
||||
```
|
||||
|
||||
:::note
|
||||
@@ -663,7 +663,7 @@ There's currently a [known issue](https://github.com/rancher/dashboard/issues/92
|
||||
|
||||
```yaml
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/controlplane: 'true'
|
||||
node-role.kubernetes.io/control-plane: 'true'
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Setting up Cloud Providers
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/set-up-cloud-providers"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers"/>
|
||||
</head>
|
||||
|
||||
A _cloud provider_ is a module in Kubernetes that provides an interface for managing nodes, load balancers, and networking routes.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Setting up Clusters from Hosted Kubernetes Providers
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/set-up-clusters-from-hosted-kubernetes-providers"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers"/>
|
||||
</head>
|
||||
|
||||
In this scenario, Rancher does not provision Kubernetes because it is installed by providers such as Google Kubernetes Engine (GKE), Amazon Elastic Container Service for Kubernetes, or Azure Kubernetes Service.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Launching Kubernetes on Windows Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/use-windows-clusters"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters"/>
|
||||
</head>
|
||||
|
||||
When provisioning a [custom cluster](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md) using Rancher, Rancher uses RKE (the Rancher Kubernetes Engine) to install Kubernetes on your existing nodes.
|
||||
|
||||
+1
-1
@@ -4,7 +4,7 @@ description: Learn about the horizontal pod autoscaler (HPA). How to manage HPAs
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/horizontal-pod-autoscaler"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/horizontal-pod-autoscaler"/>
|
||||
</head>
|
||||
|
||||
The [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) is a Kubernetes feature that allows you to configure your cluster to automatically scale the services it's running up or down.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Kubernetes Resources
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/kubernetes-resources-setup"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup"/>
|
||||
</head>
|
||||
|
||||
You can view and manipulate all of the custom resources and CRDs in a Kubernetes cluster from the Rancher UI.
|
||||
|
||||
+1
-1
@@ -4,7 +4,7 @@ description: Learn how you can set up load balancers and ingress controllers to
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/load-balancer-and-ingress-controller"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller"/>
|
||||
</head>
|
||||
|
||||
Within Rancher, you can set up load balancers and ingress controllers to redirect service requests.
|
||||
|
||||
+1
-1
@@ -4,7 +4,7 @@ description: "Learn about the two constructs with which you can build any comple
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/workloads-and-pods"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods"/>
|
||||
</head>
|
||||
|
||||
You can build any complex containerized application in Kubernetes using two basic constructs: pods and workloads. Once you build an application, you can expose it for access either within the same cluster or on the Internet using a third construct: services.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Launching Kubernetes with Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/launch-kubernetes-with-rancher"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher"/>
|
||||
</head>
|
||||
|
||||
You can have Rancher launch a Kubernetes cluster using any nodes you want. When Rancher deploys Kubernetes onto these nodes, you can choose between [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/) (RKE) or [RKE2](https://docs.rke2.io) distributions. Rancher can launch Kubernetes on any computers, including:
|
||||
|
||||
+1
-1
@@ -4,7 +4,7 @@ description: Use Rancher to create a Nutanix AOS (AHV) cluster. It may consist o
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/nutanix"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/nutanix"/>
|
||||
</head>
|
||||
|
||||
[Nutanix Acropolis Operating System](https://www.nutanix.com/products/acropolis) (Nutanix AOS) is an operating system for the Nutanix hyper-converged infrastructure platform. AOS comes with a built-in hypervisor called [Acropolis Hypervisor](https://www.nutanix.com/products/ahv), or AHV. By using Rancher with Nutanix AOS (AHV), you can bring cloud operations on-premises.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Launching Kubernetes on New Nodes in an Infrastructure Provider
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/use-new-nodes-in-an-infra-provider"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider"/>
|
||||
</head>
|
||||
|
||||
When you create an RKE or RKE2 cluster using a node template in Rancher, each resulting node pool is shown in a new **Machine Pools** tab. You can see the machine pools by doing the following:
|
||||
|
||||
+1
-1
@@ -4,7 +4,7 @@ description: Use Rancher to create a vSphere cluster. It may consist of groups o
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/vsphere"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere"/>
|
||||
</head>
|
||||
|
||||
import YouTube from '@site/src/components/YouTube'
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Cluster Access
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/access-clusters"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/access-clusters"/>
|
||||
</head>
|
||||
|
||||
This section is about what tools can be used to access clusters managed by Rancher.
|
||||
|
||||
+1
-1
@@ -4,7 +4,7 @@ description: "Learn about the two ways with which you can create persistent stor
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/create-kubernetes-persistent-storage"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage"/>
|
||||
</head>
|
||||
|
||||
When deploying an application that needs to retain data, you'll need to create persistent storage. Persistent storage allows you to store application data external from the pod running your application. This storage practice allows you to maintain application data, even if the application's pod fails.
|
||||
|
||||
+3
-1
@@ -18,7 +18,7 @@ In clusters that store data on GlusterFS volumes, you may experience an issue wh
|
||||
- The `systemd-run` binary needs to be compatible with Debian OS on which the hyperkube image is based (this can be checked using the following command on each cluster node, replacing the image tag with the Kubernetes version you want to use)
|
||||
|
||||
```
|
||||
docker run -v /usr/bin/systemd-run:/usr/bin/systemd-run --entrypoint /usr/bin/systemd-run rancher/hyperkube:v1.16.2-rancher1 --version
|
||||
docker run -v /usr/bin/systemd-run:/usr/bin/systemd-run -v /usr/lib/x86_64-linux-gnu/libcrypto.so.3:/usr/lib/x86_64-linux-gnu/libcrypto.so.3 -v /lib/systemd/libsystemd-shared-249.so:/lib/systemd/libsystemd-shared-249.so --entrypoint /usr/bin/systemd-run rancher/hyperkube:v1.26.14-rancher1 --version
|
||||
```
|
||||
|
||||
:::caution
|
||||
@@ -32,6 +32,8 @@ services:
|
||||
kubelet:
|
||||
extra_binds:
|
||||
- "/usr/bin/systemd-run:/usr/bin/systemd-run"
|
||||
- "/usr/lib/x86_64-linux-gnu/libcrypto.so.3:/usr/lib/x86_64-linux-gnu/libcrypto.so.3"
|
||||
- "/lib/systemd/libsystemd-shared-249.so:/lib/systemd/libsystemd-shared-249.so"
|
||||
```
|
||||
|
||||
After the cluster has finished provisioning, you can check the `kubelet` container logging to see if the functionality is activated by looking for the following logline:
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Cluster Autoscaler
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/install-cluster-autoscaler"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/install-cluster-autoscaler"/>
|
||||
</head>
|
||||
|
||||
In this section, you'll learn how to install and use the [Kubernetes cluster-autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/) on Rancher custom clusters using AWS EC2 Auto Scaling Groups.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Cluster Administration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/manage-clusters"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters"/>
|
||||
</head>
|
||||
|
||||
After you provision a cluster in Rancher, you can begin using powerful Kubernetes features to deploy and scale your containerized applications in development, testing, or production environments.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Provisioning Storage Examples
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/provisioning-storage-examples"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/provisioning-storage-examples"/>
|
||||
</head>
|
||||
|
||||
Rancher supports persistent storage with a variety of volume plugins. However, before you use any of these plugins to bind persistent storage to your workloads, you have to configure the storage itself, whether its a cloud-based solution from a service-provider or an on-prem solution that you manage yourself.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: New User Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/new-user-guides"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides"/>
|
||||
</head>
|
||||
|
||||
New user guides, also known as **tutorials**, describe practical steps for users to follow in order to complete some concrete action. These docs are known as "learning-oriented" docs in which users learn by "doing".
|
||||
|
||||
@@ -3,7 +3,7 @@ title: CIS Scans
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/cis-scans"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cis-scans"/>
|
||||
</head>
|
||||
|
||||
Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark. The CIS scans can run on any Kubernetes cluster, including hosted Kubernetes providers such as EKS, AKS, and GKE.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: AWS Marketplace Integration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/aws-cloud-marketplace"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace"/>
|
||||
</head>
|
||||
|
||||
## Overview
|
||||
|
||||
+3
@@ -20,6 +20,9 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|:----------------:|
|
||||
| v2.8.0 | v103.0.0+up3.0.0 |
|
||||
| v2.8.1 | v103.0.0+up3.0.0 |
|
||||
| v2.8.2 | v103.0.0+up3.0.0 |
|
||||
| v2.8.3 | v103.0.1+up3.0.1 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Cloud Marketplace Integration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/cloud-marketplace"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace"/>
|
||||
</head>
|
||||
|
||||
Rancher offers integration with cloud marketplaces to easily purchase support for installations hosted on certain cloud providers. In addition, this integration also provides the ability to generate a supportconfig bundle which can be provided to rancher support.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Operating System Management with Elemental
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/elemental"/>
|
||||
</head>
|
||||
|
||||
Elemental enables cloud-native host management. Elemental allows you to onboard any machine in any location, whether its in a datacenter or on the edge, and integrate them seamlessly into Kubernetes while managing your workflows (e.g., OS updates).
|
||||
|
||||
## Elemental with Rancher
|
||||
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: Application Development Engine with Epinio
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/epinio"/>
|
||||
</head>
|
||||
|
||||
Epinio is a Kubernetes-based Application Development Platform. It helps operators and developers collaborate without conflict, and accelerates the development process. With Epinio, teams can move from application sources to a live URL in a single step.
|
||||
|
||||
## Epinio with Rancher
|
||||
|
||||
Epinio's integration with Rancher gives developers a jump start, without having to deal with the installation process or configuration. You can install Epinio directly from the Rancher UI's Apps page.
|
||||
|
||||
## Epinio with Rancher Prime
|
||||
|
||||
Rancher Prime customers can expect better integration of Epinio with other areas in the Rancher ecosystem such as:
|
||||
|
||||
- Better integration with Rancher authentication.
|
||||
- Integration with Neuvector and Kubewarden.
|
||||
- Custom Helm chart templates with preset annotations to seamlessly integrate with monitoring and other key tools.
|
||||
- Improved service marketplace.
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Architecture
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/architecture"/>
|
||||
</head>
|
||||
|
||||
Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, or Kustomize or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy everything in the cluster. This gives you a high degree of control, consistency, and auditability. Fleet focuses not only on the ability to scale, but to give one a high degree of control and visibility to exactly what is installed on the cluster.
|
||||
|
||||

|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Continuous Delivery with Fleet
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet"/>
|
||||
</head>
|
||||
|
||||
Fleet orchestrates and manages the continuous delivery of applications through the supply chain for fleets of clusters. Fleet organizes the supply chain to help teams deliver with confidence and trust in a timely manner using GitOps as a safe operating model.
|
||||
|
||||
## Fleet with Rancher
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Overview
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/overview"/>
|
||||
</head>
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/installation#configuration-for-multi-cluster). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
|
||||
|
||||
Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Using Fleet Behind a Proxy
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/use-fleet-behind-a-proxy"/>
|
||||
</head>
|
||||
|
||||
In this section, you'll learn how to enable Fleet in a setup that has a Rancher server with a public IP a Kubernetes cluster that has no public IP, but is configured to use a proxy.
|
||||
|
||||
Rancher does not establish connections with registered downstream clusters. The Rancher agent deployed on the downstream cluster must be able to establish the connection with Rancher.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Windows Support
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/windows-support"/>
|
||||
</head>
|
||||
|
||||
Prior to Rancher v2.5.6, the `agent` did not have native Windows manifests on downstream clusters with Windows nodes. This would result in a failing `agent` pod for the cluster.
|
||||
|
||||
If you are upgrading from an older version of Rancher to v2.5.6+, you can deploy a working `agent` with the following workflow *in the downstream cluster*:
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Virtualization on Kubernetes with Harvester
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/harvester"/>
|
||||
</head>
|
||||
|
||||
## Harvester
|
||||
|
||||
Introduced in Rancher v2.6.1, Harvester is an open-source hyper-converged infrastructure (HCI) software built on Kubernetes. Harvester installs on bare metal servers and provides integrated virtualization and distributed storage capabilities. Although Harvester operates using Kubernetes, it does not require knowledge of Kubernetes concepts, making it more user-friendly.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Overview
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/harvester/overview"/>
|
||||
</head>
|
||||
|
||||
Introduced in Rancher v2.6.1, [Harvester](https://docs.harvesterhci.io/) is an open-source hyper-converged infrastructure (HCI) software built on Kubernetes. Harvester installs on bare metal servers and provides integrated virtualization and distributed storage capabilities. Although Harvester operates using Kubernetes, it does not require users to know Kubernetes concepts, making it a more user-friendly application.
|
||||
|
||||
### Feature Flag
|
||||
|
||||
@@ -1,17 +1,13 @@
|
||||
---
|
||||
title: Integrations in Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher"/>
|
||||
</head>
|
||||
|
||||
import {Card, CardSection} from '@site/src/components/CardComponents';
|
||||
import {
|
||||
ReadingModeMobileRegular,
|
||||
QuestionRegular,
|
||||
ArrowUpRegular,
|
||||
PlayRegular,
|
||||
FlowchartRegular,
|
||||
RocketRegular
|
||||
} from '@fluentui/react-icons';
|
||||
import { FaAws, FaGoogle, FaCloud, FaServer, faGear } from "react-icons/fa6";
|
||||
import HarvesterIcon from '@site/static/img/harvester_logo_horizontal.svg';
|
||||
import {RocketRegular} from '@fluentui/react-icons';
|
||||
|
||||
Prime is the Rancher ecosystem’s enterprise offering, with additional security, extended lifecycles, and access to Prime-exclusive documentation. Rancher Prime installation assets are hosted on a trusted SUSE registry, owned and managed by Rancher. The trusted Prime registry includes only stable releases that have been community-tested.
|
||||
|
||||
@@ -47,10 +43,6 @@ To learn more and get started with Rancher Prime, please visit [this page](https
|
||||
title="Operating System Management with Elemental"
|
||||
to="./integrations-in-rancher/elemental"
|
||||
/>
|
||||
<Card
|
||||
title="Observability with Opni"
|
||||
to="./integrations-in-rancher/opni"
|
||||
/>
|
||||
<Card
|
||||
title="Continuous Delivery with Fleet"
|
||||
to="./integrations-in-rancher/fleet"
|
||||
@@ -59,8 +51,4 @@ To learn more and get started with Rancher Prime, please visit [this page](https
|
||||
title="Kubernetes on the Desktop"
|
||||
to="./integrations-in-rancher/rancher-desktop"
|
||||
/>
|
||||
<Card
|
||||
title="Application Development Engine with Epinio"
|
||||
to="./integrations-in-rancher/epinio"
|
||||
/>
|
||||
</CardSection>
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user