mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 12:38:05 +00:00
Merge remote-tracking branch 'upstream/main' into rke2-backup-restore
This commit is contained in:
@@ -10,7 +10,7 @@ jobs:
|
||||
name: Deploy to GitHub Pages
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/checkout@v3
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- uses: actions/setup-node@v3
|
||||
@@ -21,7 +21,9 @@ jobs:
|
||||
- name: Install dependencies
|
||||
run: yarn install --frozen-lockfile
|
||||
- name: Build website
|
||||
run: yarn build
|
||||
env:
|
||||
NODE_OPTIONS: "--max_old_space_size=6144"
|
||||
run: yarn build --no-minify
|
||||
|
||||
# Popular action to deploy to GitHub Pages:
|
||||
# Docs: https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-docusaurus
|
||||
|
||||
@@ -10,7 +10,7 @@ jobs:
|
||||
name: Test deployment
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/checkout@v3
|
||||
- uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: 18
|
||||
@@ -18,5 +18,9 @@ jobs:
|
||||
|
||||
- name: Install dependencies
|
||||
run: yarn install --frozen-lockfile
|
||||
- name: Check links
|
||||
run: yarn run remark --quiet --use remark-validate-links --use remark-lint-no-dead-urls ./docs
|
||||
- name: Test build website
|
||||
run: yarn build
|
||||
env:
|
||||
NODE_OPTIONS: "--max_old_space_size=6144"
|
||||
run: yarn build --no-minify
|
||||
+6
-1
@@ -17,4 +17,9 @@
|
||||
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
yarn-error.log*
|
||||
|
||||
.idea/
|
||||
|
||||
/dev-resources/algolia-search/.env
|
||||
/dev-resources/algolia-search/algolia-index.sh
|
||||
@@ -55,14 +55,14 @@ You can also use [Docker](https://www.docker.com/) to launch the website.
|
||||
The below command can be used to install the dependencies and run the site inside a container:
|
||||
|
||||
```
|
||||
docker run --rm -it -v $PWD:$PWD -w $PWD -p 3000:3000 node /bin/sh -c "yarn install && yarn start -h 0.0.0.0"
|
||||
docker run --rm -it -v $PWD:$PWD -w $PWD -p 3000:3000 node:18 /bin/sh -c "yarn install && yarn start -h 0.0.0.0"
|
||||
```
|
||||
|
||||
Subsequent executions will check for updated dependencies, if there are none, it will skip the updates and quickly start the server.
|
||||
|
||||
License
|
||||
=======
|
||||
Copyright (c) 2014-2022 [Rancher Labs, Inc.](https://rancher.com)
|
||||
Copyright (c) 2014-2023 [Rancher Labs, Inc.](https://rancher.com)
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
# Dev Resources
|
||||
|
||||
This folder contains resources intended to help ease the process of maintaining and/or contributing to the Rancher Manager Documentation.
|
||||
This folder contains resources intended to help ease the process of maintaining and/or contributing to the Rancher Documentation.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Algolia with Rancher Manager Documentation
|
||||
# Algolia with Rancher Documentation
|
||||
|
||||
The search index used by the Rancher Manager documentation is generated by [running our own crawler](https://docsearch.algolia.com/docs/legacy/run-your-own).
|
||||
The search index used by the Rancher documentation is generated by [running our own crawler](https://docsearch.algolia.com/docs/legacy/run-your-own).
|
||||
|
||||
## Running the Crawler
|
||||
|
||||
|
||||
@@ -1,21 +1,21 @@
|
||||
{
|
||||
"index_name": "docs_ranchermanager_rancher_io",
|
||||
"sitemap_urls": ["http://ranchermanager.docs.rancher.com/sitemap.xml"],
|
||||
"start_urls": ["http://ranchermanager.docs.rancher.com/"],
|
||||
"selectors": {
|
||||
"lvl0": "",
|
||||
"lvl1": "article h1",
|
||||
"lvl2": "article h2",
|
||||
"lvl3": "article h3",
|
||||
"lvl4": "article h4",
|
||||
"lvl5": "article h5"
|
||||
},
|
||||
"custom_settings": {
|
||||
"attributesForFaceting": [
|
||||
"language",
|
||||
"version",
|
||||
"type",
|
||||
"docusaurus_tag"
|
||||
]
|
||||
}
|
||||
"index_name": "docs_ranchermanager_rancher_io",
|
||||
"sitemap_urls": ["http://ranchermanager.docs.rancher.com/sitemap.xml"],
|
||||
"start_urls": ["http://ranchermanager.docs.rancher.com/"],
|
||||
"selectors": {
|
||||
"lvl0": "",
|
||||
"lvl1": "article h1",
|
||||
"lvl2": "article h2",
|
||||
"lvl3": "article h3",
|
||||
"lvl4": "article h4",
|
||||
"lvl5": "article h5"
|
||||
},
|
||||
"custom_settings": {
|
||||
"attributesForFaceting": [
|
||||
"language",
|
||||
"version",
|
||||
"type",
|
||||
"docusaurus_tag"
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# File Mappings
|
||||
|
||||
The content structure of the the Rancher Manager documentation has undergone substantial changes.
|
||||
The content structure of the the Rancher documentation has undergone substantial changes.
|
||||
|
||||
In this folder, you can find files containing mappings for pages from our current documentation to our previous documentation<sup>1</sup>.
|
||||
|
||||
|
||||
@@ -22,13 +22,13 @@ Yes.
|
||||
|
||||
**Does Rancher support Windows?**
|
||||
|
||||
As of Rancher 2.3.0, we support Windows Server 1809 containers. For details on how to set up a cluster with Windows worker nodes, refer to the section on [configuring custom clusters for Windows.](../pages-for-subheaders/use-windows-clusters.md)
|
||||
Rancher supports Windows Server 1809 containers. For details on how to set up a cluster with Windows worker nodes, refer to the section on [configuring custom clusters for Windows.](../pages-for-subheaders/use-windows-clusters.md)
|
||||
|
||||
<br/>
|
||||
|
||||
**Does Rancher support Istio?**
|
||||
|
||||
As of Rancher 2.3.0, we support [Istio.](../pages-for-subheaders/istio.md)
|
||||
Rancher supports [Istio.](../pages-for-subheaders/istio.md)
|
||||
|
||||
Furthermore, Istio is implemented in our micro-PaaS "Rio", which works on Rancher 2.x along with any CNCF compliant Kubernetes cluster. You can read more about it [here](https://rio.io/)
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ The capability to access a downstream cluster without Rancher depends on the typ
|
||||
|
||||
- **Registered clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
|
||||
- **Hosted Kubernetes clusters:** If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider's cloud credentials.
|
||||
- **RKE clusters:** To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../pages-for-subheaders/rancher-manager-architecture.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
|
||||
- **RKE clusters:** To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
|
||||
|
||||
### What if I don't want Rancher anymore?
|
||||
|
||||
@@ -27,7 +27,7 @@ The previously recommended [System Tools](../reference-guides/system-tools.md) h
|
||||
|
||||
If you [installed Rancher on a Kubernetes cluster,](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md) remove Rancher by using the [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) tool.
|
||||
|
||||
As of Rancher v2.5.8, uninstalling Rancher in high-availability (HA) mode will also remove all `helm-operation-*` pods and the following apps:
|
||||
Uninstalling Rancher in high-availability (HA) mode will also remove all `helm-operation-*` pods and the following apps:
|
||||
|
||||
- fleet
|
||||
- fleet-agent
|
||||
|
||||
@@ -60,7 +60,7 @@ The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, thi
|
||||
|
||||
### How are the supported Docker versions determined?
|
||||
|
||||
We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
|
||||
We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
|
||||
|
||||
### How can I access nodes created by Rancher?
|
||||
|
||||
@@ -91,7 +91,7 @@ When the node is removed from the cluster, and the node is cleaned, you can read
|
||||
|
||||
### How can I add additional arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
|
||||
|
||||
You can add additional arguments/binds/environment variables via the [Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#cluster-config-file) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls](https://rancher.com/docs/rke/latest/en/example-yamls/).
|
||||
You can add additional arguments/binds/environment variables via the [Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-cluster-config-file-reference) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls](https://rancher.com/docs/rke/latest/en/example-yamls/).
|
||||
|
||||
### How do I check if my certificate chain is valid?
|
||||
|
||||
|
||||
+5
-1
@@ -2,6 +2,10 @@
|
||||
title: Rendering the Helm Template in an Air-Gapped Environment
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/air-gapped-upgrades"/>
|
||||
</head>
|
||||
|
||||
:::note
|
||||
|
||||
These instructions assume you have already followed the instructions for a Kubernetes upgrade on [this page,](upgrades.md) including the prerequisites, up until step 3. Upgrade Rancher.
|
||||
@@ -80,7 +84,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](../../../../versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+20
-5
@@ -2,6 +2,10 @@
|
||||
title: Installing Rancher on Azure Kubernetes Service
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks"/>
|
||||
</head>
|
||||
|
||||
This page covers how to install Rancher on Microsoft's Azure Kubernetes Service (AKS).
|
||||
|
||||
The guide uses command line tools to provision an AKS cluster with an ingress. If you prefer to provision your cluster using the Azure portal, refer to the [official documentation](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal).
|
||||
@@ -50,7 +54,7 @@ To create an AKS cluster, run the following command. Use a VM size that applies
|
||||
|
||||
:::note
|
||||
|
||||
If the version of Kubernetes is updated to v1.22 or later, the version of ingress-nginx would also need to be [updated](https://kubernetes.github.io/ingress-nginx/#faq-migration-to-apiversion-networkingk8siov1).
|
||||
If you're updating from an older version of Kubernetes, to Kubernetes v1.22 or above, you also need to [update](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx.
|
||||
|
||||
:::
|
||||
|
||||
@@ -79,16 +83,29 @@ This command merges your cluster's credentials into the existing kubeconfig and
|
||||
|
||||
The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription.
|
||||
|
||||
The following command installs an `nginx-ingress-controller` with a Kubernetes load balancer service.
|
||||
To make sure that you choose the correct Ingress-NGINX Helm chart, first find an `Ingress-NGINX version` that's compatible with your Kubernetes version in the [Kubernetes/ingress-nginx support table](https://github.com/kubernetes/ingress-nginx#supported-versions-table).
|
||||
|
||||
Then, list the Helm charts available to you by running the following command:
|
||||
|
||||
```
|
||||
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
|
||||
helm repo update
|
||||
helm search repo ingress-nginx -l
|
||||
```
|
||||
|
||||
The `helm search` command's output contains an `APP VERSION` column. The versions under this column are equivalent to the `Ingress-NGINX version` you chose earlier. Using the app version, select a chart version that bundles an app compatible with your Kubernetes install. For example, if you have Kubernetes v1.24, you can select the v4.6.0 Helm chart, since Ingress-NGINX v1.7.0 comes bundled with that chart, and v1.7.0 is compatible with Kubernetes v1.24. When in doubt, select the most recent compatible version.
|
||||
|
||||
Now that you know which Helm chart `version` you need, run the following command. It installs an `nginx-ingress-controller` with a Kubernetes load balancer service:
|
||||
|
||||
```
|
||||
helm search repo ingress-nginx -l
|
||||
helm upgrade --install \
|
||||
ingress-nginx ingress-nginx/ingress-nginx \
|
||||
--namespace ingress-nginx \
|
||||
--set controller.service.type=LoadBalancer \
|
||||
--version 4.0.18 \
|
||||
--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
|
||||
--set controller.service.externalTrafficPolicy=Local \
|
||||
--version 4.6.0 \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
@@ -125,8 +142,6 @@ Next, install the Rancher Helm chart by following the instructions on [this page
|
||||
|
||||
Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
|
||||
**_New in v2.6.7_**
|
||||
|
||||
When installing Rancher on top of this setup, you will also need to pass the value below into the Rancher Helm install command in order to set the name of the ingress controller to be used with Rancher's ingress resource:
|
||||
|
||||
```
|
||||
|
||||
+17
-5
@@ -2,6 +2,10 @@
|
||||
title: Installing Rancher on Amazon EKS
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks"/>
|
||||
</head>
|
||||
|
||||
This page covers two ways to install Rancher on EKS.
|
||||
|
||||
The first is a guide for deploying the Rancher server on an EKS cluster using CloudFormation. This guide was created in collaboration with Amazon Web Services to show how to deploy Rancher following best practices.
|
||||
@@ -79,7 +83,7 @@ Then enter the following values:
|
||||
|
||||
To create an EKS cluster, run the following command. Use the AWS region that applies to your use case. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
|
||||
|
||||
**Note:** If the version of Kubernetes is updated to v1.22 or later, the version of ingress-nginx would also need to be [updated](https://kubernetes.github.io/ingress-nginx/#faq-migration-to-apiversion-networkingk8siov1).
|
||||
**Note:** If you're updating from an older version of Kubernetes, to Kubernetes v1.22 or above, you also need to [update](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx.
|
||||
|
||||
```
|
||||
eksctl create cluster \
|
||||
@@ -117,16 +121,26 @@ rancher-server-cluster us-west-2 True
|
||||
|
||||
The cluster needs an Ingress so that Rancher can be accessed from outside the cluster.
|
||||
|
||||
The following command installs an `nginx-ingress-controller` with a LoadBalancer service. This will result in an ELB (Elastic Load Balancer) in front of NGINX:
|
||||
To make sure that you choose the correct Ingress-NGINX Helm chart, first find an `Ingress-NGINX version` that's compatible with your Kubernetes version in the [Kubernetes/ingress-nginx support table](https://github.com/kubernetes/ingress-nginx#supported-versions-table).
|
||||
|
||||
Then, list the Helm charts available to you by running the following command:
|
||||
|
||||
```
|
||||
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
|
||||
helm repo update
|
||||
helm search repo ingress-nginx -l
|
||||
```
|
||||
|
||||
The `helm search` command's output contains an `APP VERSION` column. The versions under this column are equivalent to the `Ingress-NGINX version` you chose earlier. Using the app version, select a chart version that bundles an app compatible with your Kubernetes install. For example, if you have Kubernetes v1.23, you can select the v4.6.0 Helm chart, since Ingress-NGINX v1.7.0 comes bundled with that chart, and v1.7.0 is compatible with Kubernetes v1.23. When in doubt, select the most recent compatible version.
|
||||
|
||||
Now that you know which Helm chart `version` you need, run the following command. It installs an `nginx-ingress-controller` with a Kubernetes load balancer service:
|
||||
|
||||
```
|
||||
helm upgrade --install \
|
||||
ingress-nginx ingress-nginx/ingress-nginx \
|
||||
--namespace ingress-nginx \
|
||||
--set controller.service.type=LoadBalancer \
|
||||
--version 4.0.18 \
|
||||
--version 4.6.0 \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
@@ -163,8 +177,6 @@ Next, install the Rancher Helm chart by following the instructions on [this page
|
||||
|
||||
Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
|
||||
**_New in v2.6.7_**
|
||||
|
||||
When installing Rancher on top of this setup, you will also need to pass the value below into the Rancher Helm install command in order to set the name of the ingress controller to be used with Rancher's ingress resource:
|
||||
|
||||
```
|
||||
|
||||
+15
-5
@@ -2,6 +2,10 @@
|
||||
title: Installing Rancher on a Google Kubernetes Engine Cluster
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke"/>
|
||||
</head>
|
||||
|
||||
In this section, you'll learn how to install Rancher using Google Kubernetes Engine.
|
||||
|
||||
If you already have a GKE Kubernetes cluster, skip to the step about [installing an ingress.](#7-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart)
|
||||
@@ -120,7 +124,7 @@ When choosing a Kubernetes version, be sure to first consult the [support matrix
|
||||
|
||||
To successfully create a GKE cluster with Rancher, your GKE must be in Standard mode. GKE has two modes of operation when creating a Kubernetes cluster, Autopilot and Standard mode. The cluster configuration for Autopilot mode has restrictions on editing the kube-system namespace. However, Rancher needs to create resources in the kube-system namespace during installation. As a result, you will not be able to install Rancher on a GKE cluster created in Autopilot mode. For more information about the difference between GKE Autopilot mode and Standard mode, visit [Compare GKE Autopilot and Standard.](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison)
|
||||
|
||||
**Note:** If the version of Kubernetes is updated to v1.22 or later, the version of ingress-nginx would also need to be [updated](https://kubernetes.github.io/ingress-nginx/#faq-migration-to-apiversion-networkingk8siov1).
|
||||
**Note:** If you're updating from an older version of Kubernetes, to Kubernetes v1.22 or above, you also need to [update](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx.
|
||||
|
||||
```
|
||||
gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=<VERSION>
|
||||
@@ -150,7 +154,7 @@ helm upgrade --install \
|
||||
--namespace ingress-nginx \
|
||||
--set controller.service.type=LoadBalancer \
|
||||
--version 4.0.18 \
|
||||
--create-namespace
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
## 8. Get the Load Balancer IP
|
||||
@@ -184,12 +188,18 @@ Next, install the Rancher Helm chart by following the instructions on [this page
|
||||
|
||||
Use the DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
|
||||
**_New in v2.6.7_**
|
||||
|
||||
When installing Rancher on top of this setup, you will also need to pass the value below into the Rancher Helm install command in order to set the name of the ingress controller to be used with Rancher's ingress resource:
|
||||
When installing Rancher on top of this setup, you will also need to set the name of the ingress controller to be used with Rancher's ingress resource:
|
||||
|
||||
```
|
||||
--set ingress.ingressClassName=nginx
|
||||
```
|
||||
|
||||
Refer [here for the Helm install command](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#5-install-rancher-with-helm-and-your-chosen-certificate-option) for your chosen certificate option.
|
||||
|
||||
In Rancher v2.7.5, if you intend to use the default GKE ingress on your cluster without enabling VPC-native cluster mode, you need to set the following flag:
|
||||
|
||||
```
|
||||
--set service.type=NodePort
|
||||
```
|
||||
|
||||
This is necessary because of compatibility issues between this setup and ClusterIP, the default type for `cattle-system/rancher`.
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: AdmissionConfiguration
|
||||
plugins:
|
||||
- configuration:
|
||||
apiVersion: pod-security.admission.config.k8s.io/v1
|
||||
defaults:
|
||||
audit: restricted
|
||||
audit-version: latest
|
||||
enforce: restricted
|
||||
enforce-version: latest
|
||||
warn: restricted
|
||||
warn-version: latest
|
||||
exemptions:
|
||||
namespaces:
|
||||
- ingress-nginx
|
||||
- kube-system
|
||||
- cattle-system
|
||||
- cattle-epinio-system
|
||||
- cattle-fleet-system
|
||||
- longhorn-system
|
||||
- cattle-neuvector-system
|
||||
- cattle-monitoring-system
|
||||
- rancher-alerting-drivers
|
||||
- cis-operator-system
|
||||
- cattle-csp-adapter-system
|
||||
- cattle-externalip-system
|
||||
- cattle-gatekeeper-system
|
||||
- istio-system
|
||||
- cattle-istio-system
|
||||
- cattle-logging-system
|
||||
- cattle-windows-gmsa-system
|
||||
- cattle-sriov-system
|
||||
- cattle-ui-plugin-system
|
||||
- tigera-operator
|
||||
kind: PodSecurityConfiguration
|
||||
name: PodSecurity
|
||||
path: ""
|
||||
+9
-14
@@ -1,13 +1,18 @@
|
||||
---
|
||||
title: Rollbacks
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks"/>
|
||||
</head>
|
||||
|
||||
## Additional Steps for Rollbacks with Rancher v2.6.4+
|
||||
|
||||
Rancher v2.6.4 upgrades the cluster-api module from v0.4.4 to v1.0.2. Version v1.0.2 of the cluster-api, in turn, upgrades the Cluster API's Custom Resource Definitions (CRDs) from `cluster.x-k8s.io/v1alpha4` to `cluster.x-k8s.io/v1beta1`. The CRDs upgrade to v1beta1 causes rollbacks to fail when you attempt to move from Rancher v2.6.4 to any previous version of Rancher v2.6.x. This is because CRDs that use the older apiVersion (v1alpha4) are incompatible with v1beta1.
|
||||
|
||||
To avoid rollback failure, the following Rancher scripts should be run **before** you attempt a restore operation or rollback:
|
||||
To avoid rollback failure, the following Rancher scripts should be run **before** you attempt a restore operation or rollback:
|
||||
|
||||
* `verify.sh`: Checks for any Rancher-related resources in the cluster.
|
||||
* `verify.sh`: Checks for any Rancher-related resources in the cluster.
|
||||
* `cleanup.sh`: Cleans up the cluster.
|
||||
|
||||
See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup) for more details and source code.
|
||||
@@ -41,16 +46,6 @@ A restore is performed by creating a Restore custom resource.
|
||||
|
||||
:::
|
||||
|
||||
### Scale the Rancher Deployment to 0
|
||||
|
||||
1. In the upper left corner, click **☰ > local**.
|
||||
1. From the menu on the left, click **Workload**.
|
||||
1. Under **Workload**, click on **Deployments**.
|
||||
1. At the top, click on the dropdown to adjust the filter. Select **cattle-system** as the filter.
|
||||
1. Find the row for the `rancher` deployment and click **⋮ > Edit Config**.
|
||||
1. Change **Replicas** to 0.
|
||||
1. Scroll to the bottom and click **Save**.
|
||||
|
||||
### Create the Restore Custom Resource
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
@@ -122,7 +117,7 @@ helm rollback rancher 3 -n cattle-system
|
||||
|
||||
## Rolling Back to Rancher v2.2-v2.4+
|
||||
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](../../../../versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot.
|
||||
|
||||
For information on how to roll back Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)
|
||||
|
||||
@@ -134,4 +129,4 @@ Managed clusters are authoritative for their state. This means restoring the Ran
|
||||
|
||||
## Rolling Back to Rancher v2.0-v2.1
|
||||
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](../../../../versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
|
||||
+5
-1
@@ -2,6 +2,10 @@
|
||||
title: Troubleshooting the Rancher Server Kubernetes Cluster
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/troubleshooting"/>
|
||||
</head>
|
||||
|
||||
This section describes how to troubleshoot an installation of Rancher on a Kubernetes cluster.
|
||||
|
||||
### Relevant Namespaces
|
||||
@@ -146,7 +150,7 @@ Once the network issue is resolved, the `canal` pods should timeout and restart
|
||||
|
||||
### nginx-ingress-controller Pods show RESTARTS
|
||||
|
||||
The most common cause of this issue is the `canal` pods have failed to establish the overlay network. See [canal Pods show READY `2/3`](#canal-pods-show-ready-2-3) for troubleshooting.
|
||||
The most common cause of this issue is the `canal` pods have failed to establish the overlay network. See [canal Pods show READY `2/3`](#canal-pods-show-ready-23) for troubleshooting.
|
||||
|
||||
|
||||
### Failed to dial to /var/run/docker.sock: ssh: rejected: administratively prohibited (open failed)
|
||||
|
||||
+68
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: Upgrade a Hardened Custom/Imported Cluster to Kubernetes v1.25
|
||||
---
|
||||
|
||||
Kubernetes v1.25 changes how clusters describe and implement security policies. From this version forward, [Pod Security Policies (PSPs)](https://kubernetes.io/docs/concepts/security/pod-security-policy/) are no longer available. Kubernetes v1.25 replaces them with new security objects: [Pod Security Standards (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/), and [Pod Security Admissions (PSAs)](https://kubernetes.io/docs/concepts/security/pod-security-admission/).
|
||||
|
||||
If you have custom or imported hardened clusters, you must take special preparations to ensure that the upgrade from an earlier version of Kubernetes to v1.25 or later goes smoothly.
|
||||
|
||||
:::note
|
||||
|
||||
After you upgrade to v1.25, add the necessary Rancher namespace exemptions. See [Pod Security Admission (PSA) Configuration Templates](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#exempting-required-rancher-namespaces) for more details.
|
||||
|
||||
:::
|
||||
|
||||
## Upgrading Imported Hardened Clusters to Kubernetes v1.25 or Later
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2" default>
|
||||
|
||||
Perform the following on each node in the cluster:
|
||||
1. Save [`rancher-psact.yaml`](./rancher-psact.yaml) in `/etc/rancher/rke2`.
|
||||
1. Edit the RKE2 configuration file:
|
||||
1. Update the `profile` field to `cis-1.23`.
|
||||
1. Specify the path for the configuration file that you just added: `pod-security-admission-config-file: /etc/rancher/rke2/rancher-psact.yaml`.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="K3s">
|
||||
|
||||
Perform the following on each node in the cluster:
|
||||
|
||||
Follow the official K3s instructions on [Upgrading Hardened Clusters from v1.24.x to v1.25.x](https://docs.k3s.io/known-issues#hardened-125), but use a [custom](./rancher-psact.yaml) Rancher PSA configuration template, instead of the configuration provided on the official K3s site.
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
After you perform these steps, you can upgrade the cluster's Kubernetes version through the Rancher UI:
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Find the cluster you want to update in the **Clusters** table, and click the **⋮**.
|
||||
1. Select **Edit Config**.
|
||||
1. In the **Kubernetes Version** dropdown menu, select the version that you would like to use.
|
||||
1. Click **Save**.
|
||||
|
||||
## Upgrading Custom Hardened Clusters to Kubernetes v1.25 or Later
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2" default>
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Find the cluster you want to update in the **Clusters** table, and click the **⋮**.
|
||||
1. Select **Edit Config**.
|
||||
1. Under **Basics > Security**, in the **CIS Profile** dropdown menu, select `cis-1.23`.
|
||||
1. In the **Pod Security Admission Configuration Template** dropdown menu, select `rancher-restricted`.
|
||||
1. In the **Kubernetes Version** dropdown menu, select the version that you would like to use.
|
||||
1. Click **Save**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="K3s">
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Find the cluster you want to update in the **Clusters** table, and click the **⋮**.
|
||||
1. Select **Edit YAML**.
|
||||
1. Delete `PodSecurityPolicy` from `kube-apiserver-arg.enable-admission-plugins`
|
||||
1. Add this line to the `spec` field: `defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted`
|
||||
1. Update `kubernetesVersion` to your chosen version (v1.25 or later).
|
||||
1. Click **Save**.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
+26
-17
@@ -1,6 +1,11 @@
|
||||
---
|
||||
title: Upgrades
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades"/>
|
||||
</head>
|
||||
|
||||
The following instructions will guide you through upgrading a Rancher server that was installed on a Kubernetes cluster with Helm. These steps also apply to air-gapped installs with Helm.
|
||||
|
||||
For the instructions to upgrade Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md)
|
||||
@@ -22,21 +27,17 @@ 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](../../../getting-started/installation-and-upgrade/installation-references/helm-chart-options.md#helm-chart-repositories/) aren't supported.
|
||||
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.
|
||||
|
||||
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 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
|
||||
|
||||
For [air-gapped installs only,](../../../pages-for-subheaders/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version. Follow the guide to [populate your private registry](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
|
||||
|
||||
### For upgrades from a Rancher server with a hidden local cluster
|
||||
|
||||
If you are upgrading to Rancher v2.5 from a Rancher server that was started with the Helm chart option `--add-local=false`, you will need to drop that flag when upgrading. Otherwise, the Rancher server will not start. The `restricted-admin` role can be used to continue restricting access to the local cluster. For more information, see [this section.](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#upgrading-from-rancher-with-a-hidden-local-cluster)
|
||||
|
||||
### For upgrades with cert-manager older than 0.8.0
|
||||
|
||||
[Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753) Upgrade cert-manager to the latest version by following [these instructions.](../resources/upgrade-cert-manager.md)
|
||||
@@ -62,7 +63,7 @@ You'll use the backup as a restore point if something goes wrong during upgrade.
|
||||
|
||||
1. Get the repository name that you used to install Rancher.
|
||||
|
||||
For information about the repos and their differences, see [Helm Chart Repositories](../installation-references/helm-chart-options.md#helm-chart-repositories).
|
||||
For information about the repos and their differences, see [Helm Chart Repositories](../resources/choose-a-rancher-version.md#helm-chart-repositories).
|
||||
|
||||
- Latest: Recommended for trying out the newest features
|
||||
```
|
||||
@@ -131,13 +132,15 @@ There will be more values that are listed with this command. This is just an exa
|
||||
:::
|
||||
|
||||
|
||||
If you are upgrading cert-manager to the latest version from v1.5 or below, follow the [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#option-c-upgrade-cert-manager-from-versions-1-5-and-below) to learn how to upgrade cert-manager without needing to perform an uninstall or reinstall of Rancher. Otherwise, follow the [steps to upgrade Rancher](#steps-to-upgrade-rancher) below.
|
||||
If you are upgrading cert-manager to the latest version from v1.5 or below, follow the [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#option-c-upgrade-cert-manager-from-versions-15-and-below) to learn how to upgrade cert-manager without needing to perform an uninstall or reinstall of Rancher. Otherwise, follow the [steps to upgrade Rancher](#steps-to-upgrade-rancher) below.
|
||||
|
||||
#### Steps to Upgrade Rancher
|
||||
|
||||
Upgrade Rancher to the latest version with all your settings.
|
||||
|
||||
Take all the values from the previous step and append them to the command using `--set key=value`:
|
||||
Take all the values from the previous step and append them to the command using `--set key=value`.
|
||||
|
||||
For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.
|
||||
|
||||
```
|
||||
helm upgrade rancher rancher-<CHART_REPO>/rancher \
|
||||
@@ -153,14 +156,20 @@ The above is an example, there may be more values from the previous step that ne
|
||||
|
||||
Alternatively, it's possible to export the current values to a file and reference that file during upgrade. For example, to only change the Rancher version:
|
||||
|
||||
```
|
||||
helm get values rancher -n cattle-system -o yaml > values.yaml
|
||||
1. Export the current values to a file:
|
||||
```
|
||||
helm get values rancher -n cattle-system -o yaml > values.yaml
|
||||
```
|
||||
1. Update only the Rancher version:
|
||||
|
||||
helm upgrade rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
-f values.yaml \
|
||||
--version=2.6.8
|
||||
```
|
||||
For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.
|
||||
|
||||
```
|
||||
helm upgrade rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
-f values.yaml \
|
||||
--version=2.6.8
|
||||
```
|
||||
|
||||
### 4. Verify the Upgrade
|
||||
|
||||
@@ -170,7 +179,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
Having network issues following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](../../../../versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+29
-29
@@ -2,42 +2,42 @@
|
||||
title: Feature Flags
|
||||
---
|
||||
|
||||
Feature flags were introduced to allow you to try experimental features that are not enabled by default.
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references/feature-flags"/>
|
||||
</head>
|
||||
|
||||
To learn about feature values and how to enable features, refer [here](../../../pages-for-subheaders/enable-experimental-features.md).
|
||||
With feature flags, you can try out optional or experimental features, and enable legacy features that are being phased out.
|
||||
|
||||
To learn more about feature values and how to enable them, see [Enabling Experimental Features](../../../pages-for-subheaders/enable-experimental-features.md).
|
||||
|
||||
:::note
|
||||
|
||||
There are some feature flags that may require a restart of the Rancher server container. These features that require a restart are marked in the table of these docs and in the UI.
|
||||
Some feature flags require a restart of the Rancher container. Features that require a restart are marked in the Rancher UI.
|
||||
|
||||
:::
|
||||
|
||||
The following is a list of the feature flags available in Rancher:
|
||||
The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)):
|
||||
|
||||
- `harvester`: This feature flag is available starting in v2.6.1. It is used to manage access to the Virtualization Management page where users can navigate directly to Harvester clusters and access the Harvester UI. For more information, see [this page](../../../integrations-in-rancher/harvester.md#feature-flag/).
|
||||
- `rke2`: Used to enable the ability to provision RKE2 clusters. By default, this feature flag is enabled, which allows users to attempt to provision these type of clusters.
|
||||
- `fleet`: The previous `fleet` feature flag is now required to be enabled as the Fleet capabilities are leveraged within the new provisioning framework. If you had this feature flag disabled in earlier versions, upon upgrading to Rancher v2.6, the flag will automatically be enabled. See this [page](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) for more information.
|
||||
- `continuous-delivery`: In Rancher v2.5.x, Fleet came with a GitOps feature that could not be disabled separately from Fleet. In Rancher v2.6, the `continuous-delivery` feature flag was introduced to allow the GitOps feature of Fleet to be disabled. For more information, see [this page.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md)
|
||||
- `legacy`: There are a set of features from previous versions that are slowly being phased out of Rancher for newer iterations of the feature. This is a mix of deprecated features as well as features that will eventually be moved to newer variations in Rancher. By default, this feature flag is disabled for new installations. If you are upgrading from a previous version, this feature flag would be enabled.
|
||||
- `token-hashing`: Used to enable new token-hashing feature. Once enabled, existing tokens will be hashed and all new tokens will be hashed automatically using the SHA256 algorithm. Once a token is hashed it cannot be undone. Once this feature flag is enabled, it cannot be disabled. See [hashing of tokens](../../../reference-guides/about-the-api/api-tokens.md) for more information.
|
||||
- `unsupported-storage-drivers`: This feature [allows unsupported storage drivers.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md). In other words, it enables types for storage providers and provisioners that are not enabled by default.
|
||||
- `istio-virtual-service-ui`: This feature enables a [UI to create, read, update, and delete Istio virtual services and destination rules,](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md) which are traffic management features of Istio.
|
||||
- `multi-cluster-management`: Used for multi-cluster provisioning and management of Kubernetes clusters. This feature flag can only be set at install time and not changed afterwards.
|
||||
- `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
|
||||
- `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Fleet - GitOps at Scale](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) for more information.
|
||||
- `harvester`: Manages access to the Virtualization Management page, where users can navigate directly to Harvester clusters and access the Harvester UI. See [Harvester Integration](../../../integrations-in-rancher/harvester.md) for more information.
|
||||
- `istio-virtual-service-ui`: Enables a [visual interface](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md) to create, read, update, and delete Istio virtual services and destination rules, which are Istio traffic management features.
|
||||
- `legacy`: Enables a set of features from 2.5.x and earlier, that are slowly being phased out in favor of newer implementations. These are a mix of deprecated features as well as features that will eventually be available to newer versions. This flag is disabled by default on new Rancher installations. If you're upgrading from a previous version of Rancher, this flag is enabled.
|
||||
- `multi-cluster-management`: Allows multi-cluster provisioning and management of Kubernetes clusters. This flag can only be set at install time. It can't be enabled or disabled later.
|
||||
- `rke1-custom-node-cleanup`: Enables cleanup of deleted RKE1 custom nodes. We recommend that you keep this flag enabled, to prevent removed nodes from attempting to rejoin the cluster.
|
||||
- `rke2`: Enables provisioning RKE2 clusters. This flag is enabled by default.
|
||||
- `token-hashing`: Enables token hashing. Once enabled, existing tokens will be hashed and all new tokens will be hashed automatically with the SHA256 algorithm. Once a token is hashed it can't be undone. This flag can't be disabled after its enabled. See [API Tokens](../../../reference-guides/about-the-api/api-tokens.md#token-hashing) for more information.
|
||||
- `unsupported-storage-drivers`: Enables types for storage providers and provisioners that aren't enabled by default. See [Allow Unsupported Storage Drivers](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md) for more information.
|
||||
|
||||
The below table shows the availability and default value for feature flags in Rancher:
|
||||
The following table shows the availability and default values for some feature flags in Rancher. Features marked "GA" are generally available:
|
||||
|
||||
| Feature Flag Name | Default Value | Status | Available as of | Rancher Restart Required? |
|
||||
| ----------------------------- | ------------- | ------------ | --------------- |---|
|
||||
| `istio-virtual-service-ui` | `false` | Experimental | v2.3.0 | |
|
||||
| `istio-virtual-service-ui` | `true` | GA* | v2.3.2 | |
|
||||
| `unsupported-storage-drivers` | `false` | Experimental | v2.3.0 | |
|
||||
| `fleet` | `true` | GA* | v2.5.0 | |
|
||||
| `fleet` | `true` | Can no longer be disabled | v2.6.0 | N/A |
|
||||
| `continuous-delivery` | `true` | GA* | v2.6.0 | |
|
||||
| `token-hashing` | `false` for new installs, `true` for upgrades | GA* | v2.6.0 | |
|
||||
| `legacy` | `false` for new installs, `true` for upgrades | GA* | v2.6.0 | |
|
||||
| `multi-cluster-management` | `false` | GA* | v2.5.0 | |
|
||||
| `harvester` | `true` | Experimental | v2.6.1 | |
|
||||
| `rke2` | `true` | Experimental | v2.6.0 | |
|
||||
|
||||
\* Generally Available. This feature is included in Rancher and it is not experimental.
|
||||
| Feature Flag Name | Default Value | Status | Available As Of |
|
||||
| ----------------------------- | ------------- | ------------ | --------------- |
|
||||
| `continuous-delivery` | `true` | GA | v2.6.0 |
|
||||
| `fleet` | `true` | Can no longer be disabled | v2.6.0 |
|
||||
| `fleet` | `true` | GA | v2.5.0 |
|
||||
| `harvester` | `true` | Experimental | v2.6.1 |
|
||||
| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 |
|
||||
| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 |
|
||||
| `rke2` | `true` | Experimental | v2.6.0 |
|
||||
| `token-hashing` | `false` for new installs, `true` for upgrades | GA | v2.6.0 |
|
||||
|
||||
+46
-6
@@ -1,7 +1,12 @@
|
||||
---
|
||||
title: Rancher Helm Chart Options
|
||||
keywords: [rancher helm chart, rancher helm options, rancher helm chart options, helm chart rancher, helm options rancher, helm chart options rancher]
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references/helm-chart-options"/>
|
||||
</head>
|
||||
|
||||
This page is a configuration reference for the Rancher Helm chart.
|
||||
|
||||
For help choosing a Helm chart version, refer to [this page.](../../../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md)
|
||||
@@ -57,7 +62,7 @@ For information on enabling experimental features, refer to [this page.](../../.
|
||||
| `systemDefaultRegistry` | "" | `string` - private registry to be used for all system container images, e.g., http://registry.example.com/ |
|
||||
| `tls` | "ingress" | `string` - See [External TLS Termination](#external-tls-termination) for details. - "ingress, external" |
|
||||
| `useBundledSystemChart` | `false` | `bool` - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations. |
|
||||
|
||||
| `global.cattle.psp.enabled` | `true` | `bool` - select 'false' to disable PSPs for Kubernetes v1.25 and above when using Rancher v2.7.2-v2.7.4. When using Rancher v2.7.5 and above, Rancher attempts to detect if a cluster is running a Kubernetes version where PSPs are not supported, and will default it's usage of PSPs to false if it can determine that PSPs are not supported in the cluster. Users can still manually override this by explicitly providing `true` or `false` for this value. Rancher will still use PSPs by default in clusters which support PSPs (such as clusters running Kubernetes v1.24 or lower).|
|
||||
|
||||
|
||||
### Bootstrap Password
|
||||
@@ -92,13 +97,19 @@ Set the `auditLog.destination` to `hostPath` to forward logs to volume shared wi
|
||||
|
||||
### Setting Extra Environment Variables
|
||||
|
||||
You can set extra environment variables for Rancher server using `extraEnv`. This list uses the same `name` and `value` keys as the container manifest definitions. Remember to quote the values.
|
||||
You can set extra environment variables for Rancher server using `extraEnv`. This list is passed to the Rancher deployment in its YAML format. It is embedded under `env` for the Rancher container. Refer to the Kubernetes documentation for setting container environment variables, `extraEnv` can use any of the keys referenced in [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container).
|
||||
|
||||
Consider an example that uses the `name` and `value` keys:
|
||||
|
||||
```plain
|
||||
--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
|
||||
--set 'extraEnv[0].value=1.0'
|
||||
```
|
||||
|
||||
If passing sensitive data as the value for an environment variable, such as proxy authentication credentials, it is strongly recommended that a secret reference is used. This will prevent sensitive data from being exposed in Helm or the Rancher deployment.
|
||||
|
||||
Consider an example that uses the `name`, `valueFrom.secretKeyRef.name`, and `valueFrom.secretKeyRef.key` keys. See example in [HTTP Proxy](#http-proxy)
|
||||
|
||||
### TLS Settings
|
||||
|
||||
When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. The possible TLS settings depend on the used ingress controller.
|
||||
@@ -141,15 +152,44 @@ Example on setting a static proxy header with `ingress.configurationSnippet`. Th
|
||||
|
||||
### HTTP Proxy
|
||||
|
||||
Rancher requires internet access for some functionality (helm charts). Use `proxy` to set your proxy server.
|
||||
Rancher requires internet access for some functionality (Helm charts). Use `proxy` to set your proxy server or use `extraEnv` to set the `HTTPS_PROXY` environment variable to point to your proxy server.
|
||||
|
||||
Add your IP exceptions to the `noProxy` list. Make sure you add the Pod cluster IP range (default: `10.42.0.0/16`), Service cluster IP range (default: `10.43.0.0/16`), the internal cluster domains (default: `.svc,.cluster.local`) and any worker cluster `controlplane` nodes. Rancher supports CIDR notation ranges in this list.
|
||||
Add your IP exceptions to the `noProxy` chart value as a comma separated list. Make sure you add the following values:
|
||||
- Pod cluster IP range (default: `10.42.0.0/16`).
|
||||
- Service cluster IP range (default: `10.43.0.0/16`).
|
||||
- Internal cluster domains (default: `.svc,.cluster.local`).
|
||||
- Any worker cluster `controlplane` nodes.
|
||||
Rancher supports CIDR notation ranges in this list.
|
||||
|
||||
When not including sensitive data, the `proxy` or `extraEnv` chart options can be used. When using `extraEnv` the `noProxy` Helm option is ignored. Therefore, the `NO_PROXY` environment variable must also be set with `extraEnv`.
|
||||
|
||||
The following is an example of setting proxy using the `extraEnv` chart option:
|
||||
|
||||
```plain
|
||||
--set proxy="http://<username>:<password>@<proxy_url>:<proxy_port>/"
|
||||
--set noProxy="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
|
||||
--set proxy="http://<proxy_url:proxy_port>/"
|
||||
```
|
||||
|
||||
Example of setting proxy using the `extraEnv` chart option:
|
||||
```plain
|
||||
--set extraEnv[1].name=HTTPS_PROXY
|
||||
--set extraEnv[1].value="http://<proxy_url>:<proxy_port>/"
|
||||
--set extraEnv[2].name=NO_PROXY
|
||||
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
|
||||
```
|
||||
|
||||
When including sensitive data, such as proxy authentication credentials, use the `extraEnv` option with `valueFrom.secretRef` to prevent sensitive data from being exposed in Helm or the Rancher deployment.
|
||||
|
||||
The following is an example of using `extraEnv` to configure proxy. This example secret would contain the value `"http://<username>:<password>@<proxy_url>:<proxy_port>/"` in the secret's `"https-proxy-url"` key:
|
||||
```plain
|
||||
--set extraEnv[1].name=HTTPS_PROXY
|
||||
--set extraEnv[1].valueFrom.secretKeyRef.name=secret-name
|
||||
--set extraEnv[1].valueFrom.secretKeyRef.key=https-proxy-url
|
||||
--set extraEnv[2].name=NO_PROXY
|
||||
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
|
||||
```
|
||||
|
||||
To learn more about how to configure environment variables, refer to [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container).
|
||||
|
||||
### Additional Trusted CAs
|
||||
|
||||
If you have private registries, catalogs or a proxy that intercepts certificates, you may need to add additional trusted CAs to Rancher.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: TLS Settings
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references/tls-settings"/>
|
||||
</head>
|
||||
|
||||
Changing the default TLS settings depends on the chosen installation method.
|
||||
|
||||
## Running Rancher in a highly available Kubernetes cluster
|
||||
|
||||
+5
-1
@@ -2,13 +2,17 @@
|
||||
title: Installing Docker
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-requirements/install-docker"/>
|
||||
</head>
|
||||
|
||||
Docker is required to be installed on nodes where the Rancher server will be installed with Helm on an RKE cluster or with Docker. Docker is not required for RKE2 or K3s clusters.
|
||||
|
||||
There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.
|
||||
|
||||
Another option is to use one of Rancher's Docker installation scripts, which are available for most recent versions of Docker.
|
||||
|
||||
For example, this command could be used to install Docker 20.10 on Ubuntu:
|
||||
For example, this command could be used to install Docker 20.10 on the main Linux distributions like SUSE Linux Enterprise or Ubuntu:
|
||||
|
||||
```
|
||||
curl https://releases.rancher.com/install-docker/20.10.sh | sh
|
||||
|
||||
+5
-1
@@ -3,6 +3,10 @@ title: Port Requirements
|
||||
description: Read about port requirements needed in order for Rancher to operate properly, both for Rancher nodes and downstream Kubernetes cluster nodes
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-requirements/port-requirements"/>
|
||||
</head>
|
||||
|
||||
import PortsIaasNodes from '@site/src/components/PortsIaasNodes'
|
||||
import PortsCustomNodes from '@site/src/components/PortsCustomNodes'
|
||||
import PortsImportedHosted from '@site/src/components/PortsImportedHosted'
|
||||
@@ -309,7 +313,7 @@ SUSE Linux may have a firewall that blocks all ports by default. To open the por
|
||||
sudo yast2
|
||||
```
|
||||
|
||||
1. Navigate to **Security and Users** > **Firewall** > **Zones:public** > **Ports**. To navigate within the interface, follow the instructions [here](https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-yast-text.html#sec-yast-cli-navigate).
|
||||
1. Navigate to **Security and Users** > **Firewall** > **Zones:public** > **Ports**. To navigate within the interface, follow these [instructions](https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-yast-text.html#sec-yast-cli-navigate).
|
||||
1. To open the required ports, enter them into the **TCP Ports** and **UDP Ports** fields. In this example, ports 9796 and 10250 are also opened for monitoring. The resulting fields should look similar to the following:
|
||||
```yaml
|
||||
TCP Ports
|
||||
|
||||
+3
-3
@@ -38,7 +38,7 @@ Log into your Linux host, and then run the installation command below. When ente
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port. |
|
||||
| `<RANCHER_VERSION_TAG>` | The release tag of the [Rancher version](../../installation-references/helm-chart-options.md) that you want to install. |
|
||||
|
||||
Privileged access is [required.](#privileged-access-for-rancher)
|
||||
Privileged access is [required.](./install-rancher-ha.md#privileged-access-for-rancher)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -78,7 +78,7 @@ After creating your certificate, log into your Linux host, and then run the inst
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port. |
|
||||
| `<RANCHER_VERSION_TAG>` | The release tag of the [Rancher version](../../installation-references/helm-chart-options.md) that you want to install. |
|
||||
|
||||
Privileged access is [required.](#privileged-access-for-rancher)
|
||||
Privileged access is [required.](./install-rancher-ha.md#privileged-access-for-rancher)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -123,7 +123,7 @@ Use the `--no-cacerts` as argument to the container to disable the default CA ce
|
||||
|
||||
:::
|
||||
|
||||
Privileged access is [required.](#privileged-access-for-rancher)
|
||||
Privileged access is [required.](./install-rancher-ha.md#privileged-access-for-rancher)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
|
||||
+13
-10
@@ -2,6 +2,10 @@
|
||||
title: '3. Install Kubernetes (Skip for Docker Installs)'
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes"/>
|
||||
</head>
|
||||
|
||||
:::note
|
||||
|
||||
Skip this section if you are installing Rancher on a single node with Docker.
|
||||
@@ -64,9 +68,9 @@ For more information on private registries configuration file for K3s, refer to
|
||||
|
||||
### 3. Install K3s
|
||||
|
||||
Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/)
|
||||
Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
|
||||
|
||||
To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script.
|
||||
To specify the K3s (Kubernetes) version, use the INSTALL_K3S_VERSION (e.g., `INSTALL_K3S_VERSION="v1.24.10+k3s1"`) environment variable when running the K3s installation script.
|
||||
|
||||
Obtain the K3s binary from the [releases](https://github.com/k3s-io/k3s/releases) page, matching the same version used to get the airgap images tar.
|
||||
Also obtain the K3s install script at https://get.k3s.io
|
||||
@@ -77,17 +81,16 @@ Place the install script anywhere on each node, and name it `install.sh`.
|
||||
Install K3s on each server:
|
||||
|
||||
```
|
||||
INSTALL_K3S_SKIP_DOWNLOAD=true ./install.sh
|
||||
INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_VERSION=<VERSION> ./install.sh
|
||||
```
|
||||
|
||||
Install K3s on each agent:
|
||||
|
||||
```
|
||||
INSTALL_K3S_SKIP_DOWNLOAD=true K3S_URL=https://myserver:6443 K3S_TOKEN=mynodetoken ./install.sh
|
||||
INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_VERSION=<VERSION> K3S_URL=https://<SERVER>:6443 K3S_TOKEN=<TOKEN> ./install.sh
|
||||
```
|
||||
|
||||
Note, take care to ensure you replace `myserver` with the IP or valid DNS of the server and replace `mynodetoken` with the node-token from the server.
|
||||
The node-token is on the server at `/var/lib/rancher/k3s/server/node-token`
|
||||
Where `<SERVER>` is the IP or valid DNS of the server and `<TOKEN>` is the node-token from the server found at `/var/lib/rancher/k3s/server/node-token`.
|
||||
|
||||
:::note
|
||||
|
||||
@@ -175,7 +178,7 @@ tls-san:
|
||||
- loadbalancer-dns-domain.com
|
||||
```
|
||||
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/ha/).
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/ha).
|
||||
|
||||
:::note
|
||||
|
||||
@@ -205,7 +208,7 @@ configs:
|
||||
ca_file: <path to the ca file used in the registry>
|
||||
```
|
||||
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration/)
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)
|
||||
|
||||
### 3. Install RKE2
|
||||
|
||||
@@ -234,7 +237,7 @@ systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
``
|
||||
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/airgap/).
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/airgap).
|
||||
|
||||
### 4. Save and Start Using the kubeconfig File
|
||||
|
||||
@@ -274,7 +277,7 @@ users:
|
||||
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access/) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
|
||||
### Note on Upgrading
|
||||
|
||||
|
||||
+20
-14
@@ -2,6 +2,10 @@
|
||||
title: 4. Install Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha"/>
|
||||
</head>
|
||||
|
||||
This section is about how to deploy Rancher for your air gapped environment in a high-availability Kubernetes installation. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy.
|
||||
|
||||
### Privileged Access for Rancher
|
||||
@@ -22,7 +26,7 @@ From a system that has access to the internet, fetch the latest Helm chart and c
|
||||
|
||||
1. If you haven't already, install `helm` locally on a workstation that has internet access. Note: Refer to the [Helm version requirements](../../resources/helm-version-requirements.md) to choose a version of Helm to install Rancher.
|
||||
|
||||
2. Use `helm repo add` command to add the Helm chart repository that contains charts to install Rancher. For more information about the repository choices and which is best for your use case, see [Choosing a Version of Rancher](../../installation-references/helm-chart-options.md#helm-chart-repositories).
|
||||
2. Use `helm repo add` command to add the Helm chart repository that contains charts to install Rancher. For more information about the repository choices and which is best for your use case, see [Choosing a Rancher Version](../../resources/choose-a-rancher-version.md).
|
||||
- Latest: Recommended for trying out the newest features
|
||||
```
|
||||
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
@@ -74,13 +78,12 @@ When setting up the Rancher Helm template, there are several options in the Helm
|
||||
| `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters. |
|
||||
| `useBundledSystemChart` | `true` | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. |
|
||||
|
||||
### 3. Fetch the Cert-Manager chart
|
||||
### 3. Fetch the Cert-Manager Chart
|
||||
|
||||
Based on the choice your made in [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration), complete one of the procedures below.
|
||||
|
||||
#### Option A: Default Self-Signed Certificate
|
||||
|
||||
|
||||
By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface.
|
||||
|
||||
:::note
|
||||
@@ -102,22 +105,15 @@ helm repo update
|
||||
|
||||
Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).
|
||||
|
||||
:::note
|
||||
|
||||
New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommend v1.7.x because v 1.6.x will reach end-of-life on March 30, 2022.
|
||||
|
||||
:::
|
||||
|
||||
```plain
|
||||
helm fetch jetstack/cert-manager --version v1.7.1
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
```
|
||||
|
||||
|
||||
##### 3. Retrieve the Cert-Manager CRDs
|
||||
|
||||
Download the required CRD file for cert-manager:
|
||||
```plain
|
||||
curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
|
||||
curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
```
|
||||
|
||||
### 4. Install Rancher
|
||||
@@ -128,6 +124,12 @@ Copy the fetched charts to a system that has access to the Rancher server cluste
|
||||
|
||||
Install cert-manager with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.
|
||||
|
||||
:::note
|
||||
|
||||
To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
|
||||
|
||||
:::
|
||||
|
||||
<details id="install-cert-manager">
|
||||
<summary>Click to expand</summary>
|
||||
|
||||
@@ -139,7 +141,7 @@ If you are using self-signed certificates, install cert-manager:
|
||||
kubectl create namespace cert-manager
|
||||
```
|
||||
|
||||
2. Create the cert-manager CustomResourceDefinitions (CRDs).
|
||||
2. Create the cert-manager CustomResourceDefinitions (CRDs).
|
||||
|
||||
```plain
|
||||
kubectl apply -f cert-manager/cert-manager-crd.yaml
|
||||
@@ -148,7 +150,7 @@ If you are using self-signed certificates, install cert-manager:
|
||||
3. Install cert-manager.
|
||||
|
||||
```plain
|
||||
helm install cert-manager ./cert-manager-v1.7.1.tgz \
|
||||
helm install cert-manager ./cert-manager-v1.11.0.tgz \
|
||||
--namespace cert-manager \
|
||||
--set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller \
|
||||
--set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook \
|
||||
@@ -169,6 +171,8 @@ kubectl create namespace cattle-system
|
||||
|
||||
Next, install Rancher, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
|
||||
|
||||
For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.
|
||||
|
||||
Placeholder | Description
|
||||
------------|-------------
|
||||
`<VERSION>` | The version number of the output tarball.
|
||||
@@ -198,6 +202,8 @@ Create Kubernetes secrets from your own certificates for Rancher to use. The com
|
||||
|
||||
Install Rancher, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
|
||||
|
||||
For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.
|
||||
|
||||
| Placeholder | Description |
|
||||
| -------------------------------- | ----------------------------------------------- |
|
||||
| `<VERSION>` | The version number of the output tarball. |
|
||||
|
||||
+6
-9
@@ -2,6 +2,10 @@
|
||||
title: '2. Collect and Publish Images to your Private Registry'
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images"/>
|
||||
</head>
|
||||
|
||||
This section describes how to set up your private registry so that when you install Rancher, Rancher will pull all the required images from this registry.
|
||||
|
||||
By default, all images used to [provision Kubernetes clusters](../../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) or launch any tools in Rancher, e.g. monitoring, pipelines, alerts, are pulled from Docker Hub. In an air gapped installation of Rancher, you will need a private registry that is located somewhere accessible by your Rancher server. Then, you will load the registry with all the images.
|
||||
@@ -56,13 +60,6 @@ Skip this step if you are using your own certificates, or if you are terminating
|
||||
|
||||
In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS certificates, you must add the [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) image to `rancher-images.txt` as well.
|
||||
|
||||
|
||||
:::note
|
||||
|
||||
New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommend v1.7.x because v 1.6.x will reach end-of-life on March 30, 2022.
|
||||
|
||||
:::
|
||||
|
||||
1. Fetch the latest `cert-manager` Helm chart and parse the template for image details:
|
||||
|
||||
:::note
|
||||
@@ -74,7 +71,7 @@ New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommen
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v1.7.1
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
@@ -253,7 +250,7 @@ The workstation must have Docker 18.02+ in order to support manifests, which are
|
||||
```plain
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
helm repo update
|
||||
helm fetch jetstack/cert-manager --version v0.12.0
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
|
||||
```
|
||||
|
||||
|
||||
+12
-6
@@ -2,6 +2,10 @@
|
||||
title: '2. Install Kubernetes'
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes"/>
|
||||
</head>
|
||||
|
||||
Once the infrastructure is ready, you can continue with setting up a Kubernetes cluster to install Rancher in.
|
||||
|
||||
The steps to set up RKE, RKE2, or K3s are shown below.
|
||||
@@ -28,18 +32,22 @@ NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.
|
||||
EOF
|
||||
```
|
||||
|
||||
Then run the K3s installation script to create a new K3s cluster. Ensure that the K3s version you are installing is [supported by Rancher](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
|
||||
Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
|
||||
|
||||
To specify the K3s (Kubernetes) version, use the INSTALL_K3S_VERSION (e.g., `INSTALL_K3S_VERSION="v1.24.10+k3s1"`) environment variable when running the K3s installation script.
|
||||
|
||||
On the first node, create a new cluster:
|
||||
```
|
||||
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=v1.xx K3S_TOKEN=your_secret sh -s - server --cluster-init
|
||||
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> K3S_TOKEN=<TOKEN> sh -s - server --cluster-init
|
||||
```
|
||||
|
||||
And then join the other nodes:
|
||||
```
|
||||
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=v1.xx K3S_TOKEN=your_secret sh -s - server --server https://<ip or hostname of server1>:6443
|
||||
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> K3S_TOKEN=<TOKEN> sh -s - server --server https://<SERVER>:6443
|
||||
```
|
||||
|
||||
Where `<SERVER>` is the IP or valid DNS of the server and `<TOKEN>` is the node-token from the server found at `/var/lib/rancher/k3s/server/node-token`.
|
||||
|
||||
For more information on installing K3s see the [K3s installation docs](https://docs.k3s.io/installation).
|
||||
|
||||
To have a look at your cluster run:
|
||||
@@ -77,7 +85,7 @@ systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
```
|
||||
|
||||
For more information on installing RKE2 see the [RKE2 installation docs](https://docs.rke2.io/install/).
|
||||
For more information on installing RKE2 see the [RKE2 documentation](https://docs.rke2.io).
|
||||
|
||||
To have a look at your cluster run:
|
||||
|
||||
@@ -135,8 +143,6 @@ sudo systemctl restart docker
|
||||
|
||||
#### Air-gapped proxy
|
||||
|
||||
_New in v2.6.4_
|
||||
|
||||
You can now provision node driver clusters from an air-gapped cluster configured to use a proxy for outbound connections.
|
||||
|
||||
In addition to setting the default rules for a proxy server, you will need to add additional rules, shown below, to provision node driver clusters from a proxied Rancher environment.
|
||||
|
||||
+12
-8
@@ -2,6 +2,10 @@
|
||||
title: 3. Install Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-rancher"/>
|
||||
</head>
|
||||
|
||||
Now that you have a running RKE cluster, you can install Rancher in it. For security reasons all traffic to Rancher must be encrypted with TLS. For this tutorial you are going to automatically issue a self-signed certificate through [cert-manager](https://cert-manager.io/). In a real-world use-case you will likely use Let's Encrypt or provide your own certificate.
|
||||
|
||||
### Install the Helm CLI
|
||||
@@ -30,21 +34,21 @@ kubectl create namespace cert-manager
|
||||
|
||||
Install the CustomResourceDefinitions of cert-manager:
|
||||
|
||||
:::note
|
||||
|
||||
New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommend v1.7.x because v 1.6.x will reach end-of-life on March 30, 2022.
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
```
|
||||
|
||||
And install it with Helm. Note that cert-manager also needs your proxy configured in case it needs to communicate with Let's Encrypt or other external certificate issuers:
|
||||
|
||||
:::note
|
||||
|
||||
To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
helm upgrade --install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager --version v1.7.1 \
|
||||
--namespace cert-manager --version v1.11.0 \
|
||||
--set http_proxy=http://${proxy_host} \
|
||||
--set https_proxy=http://${proxy_host} \
|
||||
--set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: '1. Set up Infrastructure'
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/set-up-infrastructure"/>
|
||||
</head>
|
||||
|
||||
In this section, you will provision the underlying infrastructure for your Rancher management server with internet access through a HTTP proxy.
|
||||
|
||||
To install the Rancher management server on a high-availability RKE cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
+5
@@ -1,6 +1,11 @@
|
||||
---
|
||||
title: Certificate Troubleshooting
|
||||
---
|
||||
|
||||
<head>
|
||||
<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?
|
||||
|
||||
You can recognize the PEM format by the following traits:
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Rolling Back Rancher Installed with Docker
|
||||
---
|
||||
|
||||
<head>
|
||||
<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>
|
||||
|
||||
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.
|
||||
|
||||
+6
-2
@@ -2,6 +2,10 @@
|
||||
title: Upgrading Rancher Installed with Docker
|
||||
---
|
||||
|
||||
<head>
|
||||
<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>
|
||||
|
||||
The following instructions will guide you through upgrading a Rancher server that was installed with Docker.
|
||||
|
||||
:::caution
|
||||
@@ -12,7 +16,7 @@ The following instructions will guide you through upgrading a Rancher server tha
|
||||
|
||||
## 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](../../../../getting-started/installation-and-upgrade/installation-references/helm-chart-options.md#helm-chart-repositories/) aren’t supported.
|
||||
- **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.
|
||||
- **For [air gap installs only,](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version**. Follow the guide to [populate your private registry](../air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
|
||||
|
||||
## Placeholder Review
|
||||
@@ -380,7 +384,7 @@ Log into Rancher. Confirm that the upgrade succeeded by checking the version dis
|
||||
|
||||
:::note Having network issues in your user clusters following upgrade?
|
||||
|
||||
See [Restoring Cluster Networking](../../../../../versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
See [Restoring Cluster Networking](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Adding TLS Secrets
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/add-tls-secrets"/>
|
||||
</head>
|
||||
|
||||
Kubernetes will create all the objects and services for Rancher, but it will not become available until we populate the `tls-rancher-ingress` secret in the `cattle-system` namespace with the certificate and key.
|
||||
|
||||
Combine the server certificate followed by any intermediate certificate(s) needed into a file named `tls.crt`. Copy your certificate key into a file named `tls.key`.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Bootstrap Password
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/bootstrap-password"/>
|
||||
</head>
|
||||
|
||||
When Rancher starts for the first time, a password is randomly generated for the first admin user. When the admin first logs in to Rancher, the UI shows commands that can be used to retrieve the bootstrap password. The admin needs to run those commands and log in with the bootstrap password. Then Rancher gives the admin an opportunity to reset the password.
|
||||
|
||||
The bootstrap password is randomly generated if it is not set during installation with a variable. For details on how to set the bootstrap password using a variable, see below.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Choosing a Rancher Version
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/choose-a-rancher-version"/>
|
||||
</head>
|
||||
|
||||
This section describes how to choose a Rancher version.
|
||||
|
||||
For a high-availability installation of Rancher, which is recommended for production, the Rancher server is installed using a **Helm chart** on a Kubernetes cluster. Refer to the [Helm version requirements](helm-version-requirements.md) to choose a version of Helm to install Rancher.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: About Custom CA Root Certificates
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/custom-ca-root-certificates"/>
|
||||
</head>
|
||||
|
||||
If you're using Rancher in an internal production environment where you aren't exposing apps publicly, use a certificate from a private certificate authority (CA).
|
||||
|
||||
Services that Rancher needs to access are sometimes configured with a certificate from a custom/internal CA root, also known as self signed certificate. If the presented certificate from the service cannot be validated by Rancher, the following error displays: `x509: certificate signed by unknown authority`.
|
||||
|
||||
+5
-1
@@ -2,9 +2,13 @@
|
||||
title: Helm Version Requirements
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/helm-version-requirements"/>
|
||||
</head>
|
||||
|
||||
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/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.
|
||||
|
||||
- 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.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Setting up Local System Charts for Air Gapped Installations
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/local-system-charts"/>
|
||||
</head>
|
||||
|
||||
The [Charts](https://github.com/rancher/charts) repository contains all the Helm catalog items required for features such as monitoring, logging, alerting and Istio.
|
||||
|
||||
In an air gapped installation of Rancher, you will need to configure Rancher to use a local copy of the system charts. This section describes how to use local system charts using a CLI flag.
|
||||
|
||||
+8
-4
@@ -2,6 +2,10 @@
|
||||
title: Updating the Rancher Certificate
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/update-rancher-certificate"/>
|
||||
</head>
|
||||
|
||||
## Updating a Private CA Certificate
|
||||
|
||||
Follow these steps to rotate an SSL certificate and private CA used by Rancher [installed on a Kubernetes cluster](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md), or migrate to an SSL certificate signed by a private CA.
|
||||
@@ -124,7 +128,7 @@ When Rancher is configured with a certificate signed by a private CA, the CA cer
|
||||
|
||||
Method 1 is the easiest, but requires all clusters to be connected to Rancher after the certificates have been rotated. This is usually the case if the process is performed right after updating or redeploying the Rancher deployment (Step 3).
|
||||
|
||||
If the clusters have lost connection to Rancher but [Authorized Cluster Endpoint](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint) (ACE) is enabled on all clusters, then go with method 2.
|
||||
If the clusters have lost connection to Rancher but [Authorized Cluster Endpoint](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md) (ACE) is enabled on all clusters, then go with method 2.
|
||||
|
||||
Method 3 can be used as a fallback if method 1 and 2 are not possible.
|
||||
|
||||
@@ -150,7 +154,7 @@ Manually patch the agent Kubernetes objects by updating the `CATTLE_CA_CHECKSUM`
|
||||
curl -k -s -fL <RANCHER_SERVER_URL>/v3/settings/cacerts | jq -r .value | sha256sum | awk '{print $1}'
|
||||
```
|
||||
|
||||
Using a Kubeconfig for each downstream cluster update the environment variable for the two agent deployments. If the [ACE](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint) is enabled for the cluster, [the kubectl context can be adjusted](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig#authenticating-directly-with-a-downstream-cluster) to connect directly to the downstream cluster.
|
||||
Using a Kubeconfig for each downstream cluster update the environment variable for the two agent deployments. If the [ACE](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md) is enabled for the cluster, [the kubectl context can be adjusted](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) to connect directly to the downstream cluster.
|
||||
|
||||
```bash
|
||||
kubectl edit -n cattle-system ds/cattle-node-agent
|
||||
@@ -169,7 +173,7 @@ Repeat the below steps for each downstream cluster:
|
||||
1. Copy the command from the `insecureCommand` field, this command is used because a private CA is un use
|
||||
|
||||
2. Run the kubectl command from the previous step using a kubeconfig for the downstream cluster with one of the following methods:
|
||||
1. If the [ACE](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint) is enabled for the cluster, [the context can be adjusted](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig#authenticating-directly-with-a-downstream-cluster) to connect directly to the downstream cluster
|
||||
1. If the [ACE](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md) is enabled for the cluster, [the context can be adjusted](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) to connect directly to the downstream cluster
|
||||
1. Alternatively, SSH into the control plane node:
|
||||
- RKE: Use the [steps in the document here](https://github.com/rancherlabs/support-tools/tree/master/how-to-retrieve-kubeconfig-from-custom-cluster) to generate a kubeconfig
|
||||
- RKE2/K3s: Use the kubeconfig populated during installation
|
||||
@@ -239,7 +243,7 @@ The below steps update the Helm values for the Rancher chart, so the Rancher pod
|
||||
```
|
||||
1. Update the current Helm values in the `values.yaml` file:
|
||||
1. As a private CA is no longer being used, remove the `privateCA: true` field, or set this to `false`
|
||||
1. Adjust the `ingress.tls.source` field as necessary. Please [refer to the chart options](../installation-references/helm-chart-options#common-options) for more details. Here are some examples:
|
||||
1. Adjust the `ingress.tls.source` field as necessary. Please [refer to the chart options](../installation-references/helm-chart-options.md#common-options) for more details. Here are some examples:
|
||||
1. If using a public CA continue with a value of: `secret`
|
||||
1. If using Let's Encrypt update the value to: `letsEncrypt`
|
||||
1. Update the Helm values for the Rancher chart using the `values.yaml` file, and the current chart version to prevent an upgrade:
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Upgrading Cert-Manager
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/upgrade-cert-manager"/>
|
||||
</head>
|
||||
|
||||
Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, three important changes to cert-manager are set to occur that you need to take action on if you have an HA deployment of Rancher:
|
||||
|
||||
1. [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
|
||||
@@ -15,7 +19,7 @@ To address these changes, this guide will do two things:
|
||||
|
||||
:::note Important:
|
||||
|
||||
If you are upgrading cert-manager to the latest version from a version older than 1.5, follow the steps in [Option C](#option-c-upgrade-to-new-cert-manager-from-versions-15-and-below) below to do so. Note that you do not need to reinstall Rancher to perform this upgrade.
|
||||
If you are upgrading cert-manager to the latest version from a version older than 1.5, follow the steps in [Option C](#option-c-upgrade-cert-manager-from-versions-15-and-below) below to do so. Note that you do not need to reinstall Rancher to perform this upgrade.
|
||||
|
||||
:::
|
||||
|
||||
@@ -93,7 +97,7 @@ In order to upgrade cert-manager, follow these instructions:
|
||||
helm install \
|
||||
cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--version v0.12.0
|
||||
--version v1.11.0
|
||||
```
|
||||
|
||||
1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
|
||||
@@ -125,7 +129,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
|
||||
1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager).
|
||||
|
||||
```plain
|
||||
helm fetch jetstack/cert-manager --version v0.12.0
|
||||
helm fetch jetstack/cert-manager --version v1.11.0
|
||||
```
|
||||
|
||||
1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files.
|
||||
@@ -153,7 +157,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
|
||||
1. Download the required CRD file for cert-manager (old and new)
|
||||
|
||||
```plain
|
||||
curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
|
||||
curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
|
||||
curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml
|
||||
```
|
||||
|
||||
@@ -260,7 +264,6 @@ cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
|
||||
## Cert-Manager API change and data migration
|
||||
|
||||
---
|
||||
_New in v2.6.4_
|
||||
|
||||
Rancher now supports cert-manager versions 1.6.2 and 1.7.1. We recommend v1.7.x because v 1.6.x will reach end-of-life on March 30, 2022. To read more, see the [cert-manager docs](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#4-install-cert-manager). For instructions on upgrading cert-manager from version 1.5 to 1.6, see the upstream cert-manager documentation [here](https://cert-manager.io/docs/installation/upgrading/upgrading-1.5-1.6/). For instructions on upgrading cert-manager from version 1.6 to 1.7, see the upstream cert-manager documentation [here](https://cert-manager.io/docs/installation/upgrading/upgrading-1.6-1.7/).
|
||||
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Upgrading and Rolling Back Kubernetes
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes"/>
|
||||
</head>
|
||||
|
||||
Following an upgrade to the latest version of Rancher, downstream Kubernetes clusters can be upgraded to use the latest supported version of Kubernetes.
|
||||
|
||||
Rancher calls RKE (Rancher Kubernetes Engine) as a library when provisioning and editing RKE clusters. For more information on configuring the upgrade strategy for RKE clusters, refer to the [RKE documentation](https://rancher.com/docs/rke/latest/en/).
|
||||
@@ -32,7 +36,8 @@ The restore operation will work on a cluster that is not in a healthy or active
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
- The options below are available only for [Rancher-launched RKE Kubernetes clusters](../../pages-for-subheaders/launch-kubernetes-with-rancher.md) and [Registered K3s Kubernetes clusters.](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#additional-features-for-registered-k3s-clusters)
|
||||
- The options below are available for [Rancher-launched Kubernetes clusters](../../pages-for-subheaders/launch-kubernetes-with-rancher.md) and [Registered K3s Kubernetes clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#additional-features-for-registered-rke2-and-k3s-clusters).
|
||||
- The following options also apply to imported RKE2 clusters that you have registered. If you import a cluster from an external cloud platform but don't register it, you won't be able to upgrade the Kubernetes version from Rancher.
|
||||
- Before upgrading Kubernetes, [back up your cluster.](../../pages-for-subheaders/backup-restore-and-disaster-recovery.md)
|
||||
|
||||
:::
|
||||
@@ -91,7 +96,7 @@ To enable draining each node during a cluster upgrade,
|
||||
|
||||
:::note
|
||||
|
||||
As of Rancher v2.4.0, there is a [known issue](https://github.com/rancher/rancher/issues/25478) in which the Rancher UI doesn't show state of etcd and controlplane as drained, even though they are being drained.
|
||||
There is a [known issue](https://github.com/rancher/rancher/issues/25478) in which the Rancher UI doesn't show state of etcd and controlplane as drained, even though they are being drained.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Upgrading Kubernetes without Upgrading Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/upgrade-kubernetes-without-upgrading-rancher"/>
|
||||
</head>
|
||||
|
||||
The RKE metadata feature allows you to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. This feature is useful for taking advantage of patch versions of Kubernetes, for example, if you want to upgrade to Kubernetes v1.14.7 when your Rancher server originally supported v1.14.6.
|
||||
|
||||
:::note
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Overview
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/overview"/>
|
||||
</head>
|
||||
|
||||
Rancher is a container management platform built for organizations that deploy containers in production. Rancher makes it easy to run Kubernetes everywhere, meet IT requirements, and empower DevOps teams.
|
||||
|
||||
## Run Kubernetes Everywhere
|
||||
@@ -56,7 +60,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
|
||||
|
||||
The options and settings available for an existing cluster change based on the method that you used to provision it. For example, only clusters [provisioned by RKE](../pages-for-subheaders/launch-kubernetes-with-rancher.md) have **Cluster Options** available for editing.
|
||||
|
||||
After a cluster is created with Rancher, a cluster administrator can manage cluster membership, enable pod security policies, and manage node pools, among [other options.](../pages-for-subheaders/cluster-configuration.md)
|
||||
After a cluster is created with Rancher, a cluster administrator can manage cluster membership or manage node pools, among [other options.](../pages-for-subheaders/cluster-configuration.md)
|
||||
|
||||
The following table summarizes the options and settings available for each cluster type:
|
||||
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: Rancher AWS Marketplace Quick Start
|
||||
description: Use Amazon EKS to deploy Rancher server.
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace"/>
|
||||
</head>
|
||||
|
||||
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](https://youtu.be/9dznJ7Ons0M) for a walkthrough of AWS Marketplace SUSE Rancher setup.
|
||||
@@ -2,6 +2,11 @@
|
||||
title: Rancher AWS Quick Start Guide
|
||||
description: Read this step by step Rancher AWS 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/aws"/>
|
||||
</head>
|
||||
|
||||
The following steps will quickly deploy a Rancher server on AWS in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
|
||||
|
||||
:::caution
|
||||
@@ -52,7 +57,7 @@ The AWS module just creates an EC2 KeyPair, an EC2 SecurityGroup and an EC2 inst
|
||||
|
||||
- `aws_access_key` - Amazon AWS Access Key
|
||||
- `aws_secret_key` - Amazon AWS Secret Key
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
- `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 [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) for more information.
|
||||
Suggestions include:
|
||||
|
||||
@@ -3,6 +3,10 @@ title: Rancher Azure Quick Start Guide
|
||||
description: Read this step by step Rancher Azure 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/azure"/>
|
||||
</head>
|
||||
|
||||
The following steps will quickly deploy a Rancher server on Azure in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
|
||||
|
||||
:::caution
|
||||
@@ -39,7 +43,7 @@ Deploying to Microsoft Azure will incur charges.
|
||||
- `azure_client_id` - Microsoft Azure Client ID
|
||||
- `azure_client_secret` - Microsoft Azure Client Secret
|
||||
- `azure_tenant_id` - Microsoft Azure Tenant ID
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
- `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 [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) for more information. Suggestions include:
|
||||
|
||||
@@ -2,6 +2,11 @@
|
||||
title: Rancher DigitalOcean Quick Start Guide
|
||||
description: Read this step by step Rancher DigitalOcean 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/digitalocean"/>
|
||||
</head>
|
||||
|
||||
The following steps will quickly deploy a Rancher server on DigitalOcean in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
|
||||
|
||||
:::caution
|
||||
@@ -33,7 +38,7 @@ Deploying to DigitalOcean will incur charges.
|
||||
|
||||
4. Edit `terraform.tfvars` and customize the following variables:
|
||||
- `do_token` - DigitalOcean access key
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
- `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 [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) for more information. Suggestions include:
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Rancher Equinix Metal Quick Start
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/equinix-metal"/>
|
||||
</head>
|
||||
|
||||
## This tutorial walks you through the following:
|
||||
|
||||
- Provisioning an Equinix Metal Server
|
||||
|
||||
@@ -2,6 +2,11 @@
|
||||
title: Rancher GCP Quick Start Guide
|
||||
description: Read this step by step Rancher GCP 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/gcp"/>
|
||||
</head>
|
||||
|
||||
The following steps will quickly deploy a Rancher server on GCP in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
|
||||
|
||||
:::caution
|
||||
@@ -34,7 +39,7 @@ Deploying to Google GCP will incur charges.
|
||||
|
||||
4. Edit `terraform.tfvars` and customize the following variables:
|
||||
- `gcp_account_json` - GCP service account file path and file name
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
- `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 [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp) for more information.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Helm CLI Quick Start
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli"/>
|
||||
</head>
|
||||
|
||||
These instructions capture a quick way to set up a proof-of-concept Rancher installation.
|
||||
|
||||
These instructions assume you have a Linux virtual machine that you will communicate with from your local workstation. Rancher will be installed on the Linux machine. You will need to retrieve the IP address of that machine so that you can access Rancher from your local workstation. Rancher is designed to manage Kubernetes clusters remotely, so any Kubernetes cluster that Rancher manages in the future will also need to be able to reach this IP address.
|
||||
@@ -12,17 +16,18 @@ Your Linux machine can be anywhere. It could be an Amazon EC2 instance, a Digita
|
||||
|
||||
The full installation requirements are [here](../../../pages-for-subheaders/installation-requirements.md).
|
||||
|
||||
|
||||
## Install K3s on Linux
|
||||
|
||||
Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
|
||||
|
||||
To specify the K3s (Kubernetes) version, use the INSTALL_K3S_VERSION (e.g., `INSTALL_K3S_VERSION="v1.24.10+k3s1"`) environment variable when running the K3s installation script.
|
||||
|
||||
Install a K3s cluster by running this command on the Linux machine:
|
||||
|
||||
```
|
||||
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="***" sh -s - server --cluster-init
|
||||
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> sh -s - server --cluster-init
|
||||
```
|
||||
|
||||
Rancher needs to be installed on a supported Kubernetes version. To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script. Refer to the [support maintenance terms](https://rancher.com/support-maintenance-terms/).
|
||||
|
||||
Using `--cluster-init` allows K3s to use embedded etcd as the datastore and has the ability to convert to an HA setup. Refer to [High Availability with Embedded DB](https://rancher.com/docs/k3s/latest/en/installation/ha-embedded/).
|
||||
|
||||
Save the IP of the Linux machine.
|
||||
@@ -38,6 +43,8 @@ The kubeconfig file is important for accessing the Kubernetes cluster. Copy the
|
||||
scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml ~/.kube/config
|
||||
```
|
||||
|
||||
In some cases it may need to make sure that your shell has the environment variable `KUBECONFIG=~/.kube/config` defined, for instance, it can be exported in your profile or rc files.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Windows">
|
||||
|
||||
@@ -90,12 +97,18 @@ Once edited, either press `ctrl+s` or go to `File > Save` to save your work.
|
||||
|
||||
Then from your local workstation, run the following commands. You will need to have [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) and [helm.](https://helm.sh/docs/intro/install/) installed.
|
||||
|
||||
:::note
|
||||
|
||||
To see options on how to customize the cert-manager install (including for cases where your cluster uses PodSecurityPolicies), see the [cert-manager docs](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration).
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
|
||||
kubectl create namespace cattle-system
|
||||
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
|
||||
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
|
||||
@@ -104,19 +117,23 @@ helm repo update
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--version v1.7.1
|
||||
--version v1.11.0
|
||||
|
||||
# Windows Powershell
|
||||
helm install cert-manager jetstack/cert-manager `
|
||||
--namespace cert-manager `
|
||||
--create-namespace `
|
||||
--version v1.7.1
|
||||
--version v1.11.0
|
||||
```
|
||||
|
||||
The final command to install Rancher is below. The command requires a domain name that forwards traffic to the Linux machine. For the sake of simplicity in this tutorial, you can use a fake domain name to create your proof-of-concept. An example of a fake domain name would be `<IP_OF_LINUX_NODE>.sslip.io`.
|
||||
|
||||
To install a specific Rancher version, use the `--version` flag (e.g., `--version 2.6.6`). Otherwise, the latest Rancher is installed by default. Refer to [Choosing a Rancher Version](../../installation-and-upgrade/resources/choose-a-rancher-version.md).
|
||||
|
||||
For Kubernetes v1.25 or later, set `global.cattle.psp.enabled` to `false` when using Rancher v2.7.2-v2.7.4. This is not necessary for Rancher v2.7.5 and above, but you can still manually set the option if you choose.
|
||||
|
||||
Note the password requires a minimum of 12 characters.
|
||||
|
||||
```
|
||||
helm install rancher rancher-latest/rancher \
|
||||
--namespace cattle-system \
|
||||
|
||||
@@ -2,6 +2,11 @@
|
||||
title: Rancher Hetzner Cloud Quick Start Guide
|
||||
description: Read this step by step Rancher Hetzner Cloud 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/hetzner-cloud"/>
|
||||
</head>
|
||||
|
||||
The following steps will quickly deploy a Rancher server on Hetzner Cloud in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
|
||||
|
||||
:::caution
|
||||
@@ -33,7 +38,7 @@ Deploying to Hetzner Cloud will incur charges.
|
||||
|
||||
4. Edit `terraform.tfvars` and customize the following variables:
|
||||
- `hcloud_token` - Hetzner API access key
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
- `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 [Hetzner Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/hcloud) for more information.
|
||||
|
||||
@@ -2,6 +2,11 @@
|
||||
title: Rancher Outscale Quick Start Guide
|
||||
description: Read this step by step Rancher Outscale 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/outscale-qs"/>
|
||||
</head>
|
||||
|
||||
The following steps will quickly deploy a Rancher server on Outscale in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
|
||||
|
||||
:::note
|
||||
@@ -34,7 +39,7 @@ Deploying to Outscale will incur charges.
|
||||
4. Edit `terraform.tfvars` and customize the following variables:
|
||||
- `access_key_id` - Outscale access key
|
||||
- `secret_key_id` - Outscale secret key
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
- `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 [Outscale Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/outscale) for more information.
|
||||
|
||||
@@ -1,6 +1,11 @@
|
||||
---
|
||||
title: Vagrant Quick Start
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/vagrant"/>
|
||||
</head>
|
||||
|
||||
The following steps quickly deploy a Rancher Server with a single node cluster attached.
|
||||
|
||||
:::caution
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Workload with NodePort Quick Start
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-workloads/nodeports"/>
|
||||
</head>
|
||||
|
||||
### Prerequisite
|
||||
|
||||
You have a running cluster with at least 1 node.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Workload with Ingress Quick Start
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-workloads/workload-ingress"/>
|
||||
</head>
|
||||
|
||||
### Prerequisite
|
||||
|
||||
You have a running cluster with at least 1 node.
|
||||
@@ -19,7 +23,7 @@ For this workload, you'll be deploying the application Rancher Hello-World.
|
||||
1. Click **Deployment**.
|
||||
1. Enter a **Name** for your workload.
|
||||
1. From the **Container Image** field, enter `rancher/hello-world`. This field is case-sensitive.
|
||||
1. Click **Add Port** and enter `80` in the **Private Container Port** field. Adding a port enables access to the application inside and outside of the cluster. For more information, see [Services](../../../pages-for-subheaders/workloads-and-pods.md#services).
|
||||
1. Click **Add Port** and `Cluster IP` for the `Service Type` and enter `80` in the **Private Container Port** field. You may leave the `Name` blank or specify any name that you wish. Adding a port enables access to the application inside and outside of the cluster. For more information, see [Services](../../../pages-for-subheaders/workloads-and-pods.md#services).
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:**
|
||||
|
||||
+1
-1
@@ -23,7 +23,7 @@ While configuring the routes for `rancher-cis-benchmark` alerts, you can specify
|
||||
|
||||
To configure alerts for a scan that runs on a schedule,
|
||||
|
||||
1. Please enable alerts on the `rancher-cis-benchmark` application (#enabling-alerting-for-rancher-cis-benchmark)
|
||||
1. Please enable alerts on the `rancher-cis-benchmark` application. For more information, see [this page](../../../how-to-guides/advanced-user-guides/cis-scan-guides/enable-alerting-for-rancher-cis-benchmark.md).
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to run a CIS scan and click **Explore**.
|
||||
1. Click **CIS Benchmark > Scan**.
|
||||
|
||||
+7
-1
@@ -8,4 +8,10 @@ title: Install Rancher CIS Benchmark
|
||||
1. Click **CIS Benchmark**
|
||||
1. Click **Install**.
|
||||
|
||||
**Result:** The CIS scan application is deployed on the Kubernetes cluster.
|
||||
**Result:** The CIS scan application is deployed on the Kubernetes cluster.
|
||||
|
||||
:::note
|
||||
|
||||
CIS Benchmark 4.0.0 and above have PSPs disabled by default. To install CIS Benchmark on a hardened cluster, set `global.psp.enabled` to `true` in the values before installing the chart.
|
||||
|
||||
:::
|
||||
|
||||
@@ -31,4 +31,4 @@ To skip tests, you will create a custom CIS scan profile. A profile contains the
|
||||
|
||||
**Result:** A new CIS scan profile is created.
|
||||
|
||||
When you [run a scan](#running-a-scan) that uses this profile, the defined tests will be skipped during the scan. The skipped tests will be marked in the generated report as `Skip`.
|
||||
When you [run a scan](./run-a-scan.md) that uses this profile, the defined tests will be skipped during the scan. The skipped tests will be marked in the generated report as `Skip`.
|
||||
|
||||
@@ -208,7 +208,7 @@ docker run -d --restart=unless-stopped \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
This operation requires [privileged access](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher).
|
||||
|
||||
This layer 7 NGINX configuration is tested on NGINX version 1.13 (mainline) and 1.14 (stable).
|
||||
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
title: Continuous Delivery
|
||||
---
|
||||
|
||||
As of Rancher v2.5, [Fleet](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) comes preinstalled in Rancher, and as of Rancher v2.6, Fleet can no longer be fully disabled. However, the Fleet feature for GitOps continuous delivery may be disabled using the `continuous-delivery` feature flag.
|
||||
[Fleet](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) comes preinstalled in Rancher can't be fully disabled. However, the Fleet feature for GitOps continuous delivery may be disabled using the `continuous-delivery` feature flag.
|
||||
|
||||
To enable or disable this feature, refer to the instructions on [the main page about enabling experimental features.](../../../pages-for-subheaders/enable-experimental-features.md)
|
||||
|
||||
|
||||
+1
-1
@@ -37,7 +37,7 @@ version's release notes in the following two ways:
|
||||
- Importing clusters that contain ARM64 based nodes
|
||||
- Kubernetes cluster version must be 1.12 or higher
|
||||
|
||||
Please see [Cluster Options](cluster-provisioning/rke-clusters/options/) how to configure the cluster options.
|
||||
Please see [Cluster Options](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md) how to configure the cluster options.
|
||||
|
||||
The following features are not tested:
|
||||
|
||||
|
||||
+2
-1
@@ -36,4 +36,5 @@ The following resource limits can be configured:
|
||||
| CPU Limit | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the container.|
|
||||
| CPU Reservation | The minimum amount of CPU (in millicores) guaranteed to the container. |
|
||||
| Memory Limit | The maximum amount of memory (in bytes) allocated to the container. |
|
||||
| Memory Reservation | The minimum amount of memory (in bytes) guaranteed to the container.
|
||||
| Memory Reservation | The minimum amount of memory (in bytes) guaranteed to the container.
|
||||
| NVIDIA GPU Limit/Reservation | The amount of GPUs allocated to the container. The limit and reservation are always the same for GPUs. |
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ To allow the Grafana dashboard to persist after the Grafana instance restarts, a
|
||||
|
||||
- The monitoring application needs to be installed.
|
||||
- To create the persistent dashboard, you must have at least the **Manage Config Maps** Rancher RBAC permissions assigned to you in the project or namespace that contains the Grafana Dashboards. This correlates to the `monitoring-dashboard-edit` or `monitoring-dashboard-admin` Kubernetes native RBAC Roles exposed by the Monitoring chart.
|
||||
- To see the links to the external monitoring UIs, including Grafana dashboards, you will need at least a [project-member role.](../../../integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md#users-with-rancher-cluster-manager-based-permissions)
|
||||
- To see the links to the external monitoring UIs, including Grafana dashboards, you will need at least a [project-member role.](../../../integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md#users-with-rancher-based-permissions)
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+3
-3
@@ -8,7 +8,7 @@ In this section, you'll learn how to customize the Grafana dashboard to show met
|
||||
|
||||
Before you can customize a Grafana dashboard, the `rancher-monitoring` application must be installed.
|
||||
|
||||
To see the links to the external monitoring UIs, including Grafana dashboards, you will need at least a [project-member role.](../../../integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md#users-with-rancher-cluster-manager-based-permissions)
|
||||
To see the links to the external monitoring UIs, including Grafana dashboards, you will need at least a [project-member role.](../../../integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md#users-with-rancher-based-permissions)
|
||||
|
||||
### Signing in to Grafana
|
||||
|
||||
@@ -35,5 +35,5 @@ You can then modify the query in the Grafana panel or create a new Grafana panel
|
||||
|
||||
See also:
|
||||
|
||||
- [Grafana docs on editing a panel](https://grafana.com/docs/grafana/latest/panels/panel-editor/)
|
||||
- [Grafana docs on adding a panel to a dashboard](https://grafana.com/docs/grafana/latest/panels/add-a-panel/)
|
||||
- [Grafana docs on editing a panel](https://grafana.com/docs/grafana/latest/panels-visualizations/configure-panel-options/#edit-a-panel)
|
||||
- [Grafana docs on adding a panel to a dashboard](https://grafana.com/docs/grafana/latest/panels-visualizations/panel-editor-overview)
|
||||
|
||||
+7
-6
@@ -10,10 +10,11 @@ You can enable monitoring with or without SSL.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Make sure that you are allowing traffic on port 9796 for each of your nodes because Prometheus will scrape metrics from here.
|
||||
- Make sure your cluster fulfills the resource requirements. The cluster should have at least 1950Mi memory available, 2700m CPU, and 50Gi storage. A breakdown of the resource limits and requests is [here.](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests)
|
||||
- When installing monitoring on an RKE cluster using RancherOS or Flatcar Linux nodes, change the etcd node certificate directory to `/opt/rke/etc/kubernetes/ssl`.
|
||||
- For clusters provisioned with the RKE CLI and the address is set to a hostname instead of an IP address, set `rkeEtcd.clients.useLocalhost` to `true` during the Values configuration step of the installation. The YAML snippet will look like the following:
|
||||
- Allow traffic on port 9796 for each of your nodes. Prometheus scrapes metrics from these ports.
|
||||
- You may also need to allow traffic on port 10254 for each of your nodes, if [PushProx](../../../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#pushprox) is disabled (`ingressNginx.enabled` set to `false`), or you've upgraded from a previous Rancher version that had v1 monitoring already installed.
|
||||
- Make sure that your cluster fulfills the resource requirements. The cluster should have at least 1950Mi memory available, 2700m CPU, and 50Gi storage. See [Configuring Resource Limits and Requests](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests) for a breakdown of the resource limits and requests.
|
||||
- When you install monitoring on an RKE cluster that uses RancherOS or Flatcar Linux nodes, change the etcd node certificate directory to `/opt/rke/etc/kubernetes/ssl`.
|
||||
- For clusters that have been provisioned with the RKE CLI and that have the address set to a hostname instead of an IP address, set `rkeEtcd.clients.useLocalhost` to `true` when you configure the Values during installation. For example:
|
||||
|
||||
```yaml
|
||||
rkeEtcd:
|
||||
@@ -27,7 +28,7 @@ If you want to set up Alertmanager, Grafana or Ingress, it has to be done with t
|
||||
|
||||
:::
|
||||
|
||||
#Setting Resource Limits and Requests
|
||||
## Setting Resource Limits and Requests
|
||||
|
||||
The resource requests and limits can be configured when installing `rancher-monitoring`. To configure Prometheus resources from the Rancher UI, click **Apps > Monitoring** in the upper left corner.
|
||||
|
||||
@@ -61,7 +62,7 @@ For more information about the default limits, see [this page.](../../../referen
|
||||
|
||||
**Result:** The monitoring app is deployed in the `cattle-monitoring-system` namespace.
|
||||
|
||||
When [creating a receiver,](../monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md#creating-receivers-in-the-rancher-ui) SSL-enabled receivers such as email or webhook will have a **SSL** section with fields for **CA File Path**, **Cert File Path**, and **Key File Path**. Fill in these fields with the paths to each of `ca`, `cert`, and `key`. The path will be of the form `/etc/alertmanager/secrets/name-of-file-in-secret`.
|
||||
When [creating a receiver,](../../../reference-guides/monitoring-v2-configuration/receivers.md#creating-receivers-in-the-rancher-ui) SSL-enabled receivers such as email or webhook will have a **SSL** section with fields for **CA File Path**, **Cert File Path**, and **Key File Path**. Fill in these fields with the paths to each of `ca`, `cert`, and `key`. The path will be of the form `/etc/alertmanager/secrets/name-of-file-in-secret`.
|
||||
|
||||
For example, if you created a secret with these key-value pairs:
|
||||
|
||||
|
||||
+6
-1
@@ -75,7 +75,12 @@ There are no specific recommendations on how much memory the Cluster Prometheus
|
||||
1. Click the **Prometheus Federator** chart.
|
||||
1. Click **Install**.
|
||||
1. On the **Metadata** page, click **Next**.
|
||||
1. In the **Project Release Namespace Project ID** field, the `System Project` is used as the default but can be overridden with another project with similarly [limited access](#ensure-the-cattle-monitoring-system-namespace-is-placed-into-the-system-project-or-a-similarly-locked-down-project-that-has-access-to-other-projects-in-the-cluster). <!-- add info on retrieving project IDs >
|
||||
1. In the **Project Release Namespace Project ID** field, the `System Project` is used as the default but can be overridden with another project with similarly [limited access](#ensure-the-cattle-monitoring-system-namespace-is-placed-into-the-system-project-or-a-similarly-locked-down-project-that-has-access-to-other-projects-in-the-cluster). Project IDs can be found with the following command run in the local upstream cluster:
|
||||
|
||||
```plain
|
||||
kubectl get projects -A -o custom-columns="NAMESPACE":.metadata.namespace,"ID":.metadata.name,"NAME":.spec.displayName
|
||||
```
|
||||
|
||||
1. Click **Install**.
|
||||
|
||||
**Result:** The Prometheus Federator app is deployed in the `cattle-monitoring-system` namespace.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Cluster Drivers
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers"/>
|
||||
</head>
|
||||
|
||||
Cluster drivers are used to create clusters in a [hosted Kubernetes provider](../../../../pages-for-subheaders/set-up-clusters-from-hosted-kubernetes-providers.md), such as Google GKE. The availability of which cluster driver to display when creating clusters is defined by the cluster driver's status. Only `active` cluster drivers will be displayed as an option for creating clusters. By default, Rancher is packaged with several existing cloud provider cluster drivers, but you can also add custom cluster drivers to Rancher.
|
||||
|
||||
If there are specific cluster drivers that you do not want to show your users, you may deactivate those cluster drivers within Rancher and they will not appear as an option for cluster creation.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Node Drivers
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers"/>
|
||||
</head>
|
||||
|
||||
Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). The availability of which node driver to display when creating node templates is defined based on the node driver's status. Only `active` node drivers will be displayed as an option for creating node templates. By default, Rancher is packaged with many existing Docker Machine drivers, but you can also create custom node drivers to add to Rancher.
|
||||
|
||||
If there are specific node drivers that you don't want to show to your users, you would need to de-activate these node drivers.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Access and Sharing
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/access-or-share-templates"/>
|
||||
</head>
|
||||
|
||||
If you are an RKE template owner, you can share it with users or groups of users, who can then use the template to create clusters.
|
||||
|
||||
Since RKE templates are specifically shared with users and groups, owners can share different RKE templates with different sets of users.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Applying Templates
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates"/>
|
||||
</head>
|
||||
|
||||
You can create a cluster from an RKE template that you created, or from a template that has been [shared with you.](access-or-share-templates.md)
|
||||
|
||||
RKE templates can be applied to new clusters.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Template Creator Permissions
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/creator-permissions"/>
|
||||
</head>
|
||||
|
||||
Administrators have the permission to create RKE templates, and only administrators can give that permission to other users.
|
||||
|
||||
For more information on administrator permissions, refer to the [documentation on global permissions](../manage-role-based-access-control-rbac/global-permissions.md).
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Template Enforcement
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates"/>
|
||||
</head>
|
||||
|
||||
This section describes how template administrators can enforce templates in Rancher, restricting the ability of users to create clusters without a template.
|
||||
|
||||
By default, any standard user in Rancher can create clusters. But when RKE template enforcement is turned on,
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Example Scenarios
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases"/>
|
||||
</head>
|
||||
|
||||
These example scenarios describe how an organization could use templates to standardize cluster creation.
|
||||
|
||||
- **Enforcing templates:** Administrators might want to [enforce one or more template settings for everyone](#enforcing-a-template-setting-for-everyone) if they want all new Rancher-provisioned clusters to have those settings.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: RKE Templates and Infrastructure
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure"/>
|
||||
</head>
|
||||
|
||||
In Rancher, RKE templates are used to provision Kubernetes and define Rancher settings, while node templates are used to provision nodes.
|
||||
|
||||
Therefore, even if RKE template enforcement is turned on, the end user still has flexibility when picking the underlying hardware when creating a Rancher cluster. The end users of an RKE template can still choose an infrastructure provider and the nodes they want to use.
|
||||
|
||||
+5
-1
@@ -2,6 +2,10 @@
|
||||
title: Creating and Revising RKE Templates
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates"/>
|
||||
</head>
|
||||
|
||||
This section describes how to manage RKE templates and revisions. You an create, share, update, and delete templates from the **Cluster Management** view under **RKE1 Configuration > RKE Templates**.
|
||||
|
||||
Template updates are handled through a revision system. When template owners want to change or update a template, they create a new revision of the template. Individual revisions cannot be edited. However, if you want to prevent a revision from being used to create a new cluster, you can disable it.
|
||||
@@ -146,7 +150,7 @@ To upgrade a cluster to use a new template revision,
|
||||
|
||||
You can save an existing cluster's settings as an RKE template.
|
||||
|
||||
This exports the cluster's settings as a new RKE template, and also binds the cluster to that template. The result is that the cluster can only be changed if the [template is updated,](manage-rke1-templates.md#updating-a-template) and the cluster is upgraded to [use a newer version of the template.]
|
||||
This exports the cluster's settings as a new RKE template, and also binds the cluster to that template. The result is that the cluster can only be changed if the [template is updated,](#updating-a-template) and the cluster is upgraded to [use a newer version of the template](#upgrading-a-cluster-to-use-a-new-template-revision).
|
||||
|
||||
To convert an existing cluster to use an RKE template,
|
||||
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Overriding Template Settings
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/override-template-settings"/>
|
||||
</head>
|
||||
|
||||
When a user creates an RKE template, each setting in the template has a switch in the Rancher UI that indicates if users can override the setting. This switch marks those settings as **Allow User Override**.
|
||||
|
||||
After a cluster is created with a template, end users can't update any of the settings defined in the template unless the template owner marked them as **Allow User Override**. However, if the template is [updated to a new revision](manage-rke1-templates.md) that changes the settings or allows end users to change them, the cluster can be upgraded to a new revision of the template and the changes in the new revision will be applied to the cluster.
|
||||
|
||||
+5
-1
@@ -2,6 +2,10 @@
|
||||
title: Configure Active Directory (AD)
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-active-directory"/>
|
||||
</head>
|
||||
|
||||
If your organization uses Microsoft Active Directory as central user repository, you can configure Rancher to communicate with an Active Directory server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the Active Directory, while allowing end-users to authenticate with their AD credentials when logging in to the Rancher UI.
|
||||
|
||||
Rancher uses LDAP to communicate with the Active Directory server. The authentication flow for Active Directory is therefore the same as for the [OpenLDAP authentication](../../../../pages-for-subheaders/configure-openldap.md) integration.
|
||||
@@ -146,7 +150,7 @@ You will still be able to login using the locally configured `admin` account and
|
||||
|
||||
In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hierarchy and schema of your AD server.
|
||||
|
||||
The [`ldapsearch`](http://manpages.ubuntu.com/manpages/artful/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
The [`ldapsearch`](https://manpages.ubuntu.com/manpages/kinetic/en/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects.
|
||||
|
||||
For the purpose of the example commands provided below we will assume:
|
||||
|
||||
|
||||
+59
-32
@@ -2,10 +2,16 @@
|
||||
title: Configure Azure AD
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-azure-ad"/>
|
||||
</head>
|
||||
|
||||
## Microsoft Graph API
|
||||
|
||||
Microsoft Graph API is now the flow through which you will set up Azure AD. The below sections will assist [new users](#new-user-setup) in configuring Azure AD with a new instance as well as assist existing Azure app owners in [migrating to the new flow](#migrating-from-azure-ad-graph-api-to-microsoft-graph-api).
|
||||
|
||||
The Microsoft Graph API flow in Rancher is constantly evolving. We recommend that you use the latest patched version of 2.7, as it is still in active development and will continue to receive new features and improvements.
|
||||
|
||||
### New User Setup
|
||||
|
||||
If you have an instance of Active Directory (AD) hosted in Azure, you can configure Rancher to allow your users to log in using their AD accounts. Configuration of Azure AD external authentication requires you to make configurations in both Azure and Rancher.
|
||||
@@ -23,8 +29,7 @@ Configuring Rancher to allow your users to authenticate with their Azure AD acco
|
||||
|
||||
:::tip
|
||||
|
||||
Before you start, open two browser tabs: one for Rancher, one for the Azure portal. That will help in easily copying and pasting
|
||||
configuration values from the portal to Rancher.
|
||||
Before you start, open two browser tabs: one for Rancher, and one for the Azure portal. This will help with copying and pasting configuration values from the portal to Rancher.
|
||||
|
||||
:::
|
||||
|
||||
@@ -76,13 +81,13 @@ From the Azure portal, create a client secret. Rancher will use this key to auth
|
||||
|
||||

|
||||
|
||||
1. From the navigation pane on left, click **Certificates & secrets**.
|
||||
1. From the navigation pane, click **Certificates & secrets**.
|
||||
|
||||
1. Click **New client secret**.
|
||||

|
||||
1. Enter a **Description** (something like `Rancher`).
|
||||
1. Select duration for the key from the options under **Expires**. This drop-down sets the expiration date for the key. Shorter durations are more secure, but require you to create a new key after expiration.
|
||||
Note that users won't be able to log in to Rancher when it detects that the application secret has expired, so rotate the secret in Azure and update in Rancher before it expires.
|
||||
1. Select the duration from the options under **Expires**. This drop-down menu sets the expiration date for the key. Shorter durations are more secure, but require you to create a new key more frequently.
|
||||
Note that users won't be able to log in to Rancher if it detects that the application secret has expired. To avoid this problem, rotate the secret in Azure and update it in Rancher before it expires.
|
||||
1. Click **Add** (you don't need to enter a value—it will automatically populate after you save).
|
||||
<a id="secret"></a>
|
||||
|
||||
@@ -94,11 +99,11 @@ Next, set API permissions for Rancher within Azure.
|
||||
|
||||
:::caution
|
||||
|
||||
Ensure that you set the permissions of type Application and NOT Delegated. Otherwise, you may not be able to login to Azure AD.
|
||||
Ensure that you set Application permissions, and *not* Delegated permissions. Otherwise, you won't be able to login to Azure AD.
|
||||
|
||||
:::
|
||||
|
||||
1. From the navigation pane on the left, select **API permissions**.
|
||||
1. From the navigation pane on, select **API permissions**.
|
||||
|
||||
1. Click **Add a permission**.
|
||||
|
||||
@@ -106,13 +111,27 @@ Ensure that you set the permissions of type Application and NOT Delegated. Other
|
||||
|
||||

|
||||
|
||||
1. Return to **API permissions** in the left nav bar. From there, click **Grant admin consent**. Then click **Yes**. The app's permissions should look like the following:
|
||||
1. Return to **API permissions** in the nav bar. From there, click **Grant admin consent**. Then click **Yes**. The app's permissions should look like the following:
|
||||
|
||||

|
||||
|
||||
:::note
|
||||
|
||||
Rancher does not validate the permissions you grant to the app in Azure. We only support the use of the `Directory.Read.All` application permission.
|
||||
Rancher doesn't validate the permissions you grant to the app in Azure. You're free to try any permissions you want, as long as they allow Rancher to work with AD users and groups.
|
||||
|
||||
Specifically, Rancher needs permissions that allow the following actions:
|
||||
- Get a user.
|
||||
- List all users.
|
||||
- List groups of which a given user is a member.
|
||||
- Get a group.
|
||||
- List all groups.
|
||||
|
||||
Rancher performs these actions either to log in a user or to run a user/group search. Keep in mind that the permissions must be of type `Application`.
|
||||
|
||||
Here are a few examples of permission combinations that satisfy Rancher's needs:
|
||||
- `Directory.Read.All`
|
||||
- `User.Read.All` and `GroupMember.Read.All`
|
||||
- `User.Read.All` and `Group.Read.All`
|
||||
|
||||
:::
|
||||
|
||||
@@ -130,38 +149,42 @@ Rancher does not validate the permissions you grant to the app in Azure. We only
|
||||
|
||||
1. Obtain your Rancher **Application (Client) ID**.
|
||||
|
||||
1. Use search to open **App registrations** (if not already there).
|
||||
1. If you aren't already there, use search to open **App registrations**.
|
||||
|
||||
1. In **Overview**, find the entry you created for Rancher.
|
||||
|
||||
1. Copy the **Application (Client) ID** and paste it into Rancher as your **Application ID**.
|
||||
|
||||
1. Your endpoint options will typically be either [Standard](#global) or [China](#china). With these options, you only enter the **Tenant ID**, **Application ID**, and **Application Secret**.
|
||||
1. In most cases, your endpoint options will either be [Standard](#global) or [China](#china). For either of these options, you only need to enter the **Tenant ID**, **Application ID**, and **Application Secret**.
|
||||
|
||||

|
||||
|
||||
**For Custom Endpoints:**
|
||||
|
||||
**Warning:** Custom Endpoints are not tested or fully supported by Rancher.
|
||||
:::caution
|
||||
|
||||
You will need to also manually enter the Graph, Token, and Auth Endpoints.
|
||||
Custom Endpoints are not tested or fully supported by Rancher.
|
||||
|
||||
:::
|
||||
|
||||
You'll also need to manually enter the Graph, Token, and Auth Endpoints.
|
||||
|
||||
- From <b>App registrations</b>, click <b>Endpoints</b>:
|
||||
|
||||

|
||||
|
||||
- Note the following endpoints - these values will be your Rancher endpoint values. Make sure to use the v1 version of the endpoints.
|
||||
- The following endpoints will be your Rancher endpoint values. Make sure to use the v1 version of these endpoints:
|
||||
- **Microsoft Graph API endpoint** (Graph Endpoint)
|
||||
- **OAuth 2.0 token endpoint (v1)** (Token Endpoint)
|
||||
- **OAuth 2.0 authorization endpoint (v1)** (Auth Endpoint)
|
||||
|
||||
#### 5. Configure Azure AD in Rancher
|
||||
|
||||
From the Rancher UI, enter information about your AD instance hosted in Azure to complete configuration.
|
||||
To complete configuration, enter information about your AD instance in the Rancher UI.
|
||||
|
||||
1. Log into Rancher.
|
||||
|
||||
1. In the top left corner, click **☰ > Users & Authentication**.
|
||||
1. In the top left corner, click **☰ > Users & Authentication**.
|
||||
|
||||
1. In the left navigation menu, click **Auth Provider**.
|
||||
|
||||
@@ -169,14 +192,14 @@ From the Rancher UI, enter information about your AD instance hosted in Azure to
|
||||
|
||||
1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#4-copy-azure-application-data).
|
||||
|
||||
:::caution
|
||||
|
||||
The Azure AD account will be granted administrator privileges, since its details will be mapped to the Rancher local principal account. Make sure that this level of privilege is appropriate before you continue.
|
||||
|
||||
:::caution
|
||||
|
||||
The Azure AD account will be granted administrator privileges, since its details will be mapped to the Rancher local principal account. Make sure that this level of privilege is appropriate before you continue.
|
||||
|
||||
:::
|
||||
|
||||
**For Standard or China Endpoints:**
|
||||
|
||||
|
||||
The following table maps the values you copied in the Azure portal to the fields in Rancher:
|
||||
|
||||
| Rancher Field | Azure Value |
|
||||
@@ -207,21 +230,19 @@ From the Rancher UI, enter information about your AD instance hosted in Azure to
|
||||
|
||||
### Migrating from Azure AD Graph API to Microsoft Graph API
|
||||
|
||||
Since [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) was deprecated in June 2020
|
||||
and will be retired in June 2023, admins should update their Azure AD App to use the new
|
||||
[Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) in Rancher.
|
||||
This needs to be done well in advance of the endpoint being retired.
|
||||
If Rancher is still configured to use the old Azure AD Graph API when it is retired, users may not be able to log into Rancher using Azure AD.
|
||||
Since the [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) is deprecated and slated to retire in June 2023, admins should update their Azure AD App to use the [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) in Rancher.
|
||||
This needs to be done well in advance of the endpoint being retired.
|
||||
If Rancher is still configured to use the Azure AD Graph API when it is retired, users may not be able to log into Rancher using Azure AD.
|
||||
|
||||
#### Updating Endpoints in the Rancher UI
|
||||
|
||||
:::caution
|
||||
|
||||
Admins should create a [backup](../../../new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) right before they commit to the endpoint migration described below.
|
||||
Admins should create a [Rancher backup](../../../new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) before they commit to the endpoint migration described below.
|
||||
|
||||
:::
|
||||
|
||||
1. Update the permissions of your Azure AD app registration as described [here](#3-set-required-permissions-for-rancher). This is critical.
|
||||
1. [Update](#3-set-required-permissions-for-rancher) the permissions of your Azure AD app registration. This is critical.
|
||||
|
||||
1. Log into Rancher.
|
||||
|
||||
@@ -253,7 +274,12 @@ If you need to roll back your migration, please note the following:
|
||||
|
||||
1. Azure app owners who want to rotate the Application Secret will need to also rotate it in Rancher as Rancher does not automatically update the Application Secret when it is changed in Azure. In Rancher, note that it is stored in a Kubernetes secret called `azureadconfig-applicationsecret` which is in the `cattle-global-data` namespace.
|
||||
|
||||
1. **Caution:** If admins upgrade to Rancher v2.7.0+ with an existing Azure AD setup and choose to disable the auth provider, they won't be able to restore the previous setup and also will not be able to set up Azure AD anew using the old flow. Admins will then need to register again with the new auth flow. Rancher now uses the new Graph API and, therefore, users need set up the [proper permissions in the Azure portal](#3-set-required-permissions-for-rancher).
|
||||
:::caution
|
||||
|
||||
If you upgrade to Rancher v2.7.0+ with an existing Azure AD setup, and choose to disable the auth provider, you won't be able to restore the previous setup. You also won't be able to set up Azure AD using the old flow. You'll need to re-register with the new auth flow. Since Rancher now uses the Graph API, users need set up the [proper permissions in the Azure portal](#3-set-required-permissions-for-rancher).
|
||||
|
||||
:::
|
||||
|
||||
|
||||
#### Global:
|
||||
|
||||
@@ -292,12 +318,13 @@ Token Endpoint | https://login.partner.microsoftonline.cn/{tenantID}/oauth2/v2
|
||||
|
||||
>**Important:**
|
||||
>
|
||||
>- The [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) was deprecated in June 2022 and will be retired at the end of 2022. We will update our docs to advise the community when it is retired. Rancher now uses the [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) as the new flow to set up Azure AD as the external auth provider.
|
||||
>- The [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) is deprecated and will be retired by Microsoft at any time after June 30, 2023, without advance notice. We will update our docs to advise the community when it is retired. Rancher now uses the [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) as the new flow to set up Azure AD as the external auth provider.
|
||||
>
|
||||
>
|
||||
>- For new users, or existing users who wish to migrate, refer to the new flow instructions for <a href="#microsoft-graph-api/" target="_blank">Rancher v2.7.0+</a>.
|
||||
>- If you're a new user, or wish to migrate, refer to the new flow instructions for <a href="#microsoft-graph-api/" target="_blank">Rancher v2.7.0+</a>.
|
||||
>
|
||||
>
|
||||
>- For existing users who do not wish to upgrade to v2.7.0+ after the Azure AD Graph API is retired, they will need to either:
|
||||
>- If you don't wish to upgrade to v2.7.0+ after the Azure AD Graph API is retired, you'll need to either:
|
||||
- Use the built-in Rancher auth or
|
||||
- Use another third-party auth system and set that up in Rancher. Please see the [authentication docs](../../../../pages-for-subheaders/authentication-config.md) to learn how to configure other open authentication providers.
|
||||
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Configure FreeIPA
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-freeipa"/>
|
||||
</head>
|
||||
|
||||
If your organization uses FreeIPA for user authentication, you can configure Rancher to allow your users to login using their FreeIPA credentials.
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Configure GitHub
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-github"/>
|
||||
</head>
|
||||
|
||||
In environments using GitHub, you can configure Rancher to allow sign on using GitHub credentials.
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Configure Google OAuth
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-google-oauth"/>
|
||||
</head>
|
||||
|
||||
If your organization uses G Suite for user authentication, you can configure Rancher to allow your users to log in using their G Suite credentials.
|
||||
|
||||
Only admins of the G Suite domain have access to the Admin SDK. Therefore, only G Suite admins can configure Google OAuth for Rancher.
|
||||
|
||||
+5
@@ -2,6 +2,11 @@
|
||||
title: Configure Keycloak (OIDC)
|
||||
description: Create a Keycloak OpenID Connect (OIDC) client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-keycloak-oidc"/>
|
||||
</head>
|
||||
|
||||
If your organization uses [Keycloak Identity Provider (IdP)](https://www.keycloak.org) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials. Rancher supports integration with Keycloak using the OpenID Connect (OIDC) protocol and the SAML protocol. Both implementations are functionally equivalent when used with Rancher. This page describes the process to configure Rancher to work with Keycloak using the OIDC protocol.
|
||||
|
||||
If you prefer to use Keycloak with the SAML protocol instead, refer to [this page](configure-keycloak-saml.md).
|
||||
|
||||
+4
@@ -3,6 +3,10 @@ title: Configure Keycloak (SAML)
|
||||
description: Create a Keycloak SAML client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-keycloak-saml"/>
|
||||
</head>
|
||||
|
||||
If your organization uses Keycloak Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
+46
-3
@@ -2,6 +2,10 @@
|
||||
title: Configure Okta (SAML)
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-okta-saml"/>
|
||||
</head>
|
||||
|
||||
If your organization uses Okta Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
|
||||
|
||||
:::note
|
||||
@@ -20,10 +24,12 @@ Setting | Value
|
||||
|
||||
## Configuring Okta in Rancher
|
||||
|
||||
1. In the top left corner, click **☰ > Users & Authentication**.
|
||||
You can integrate Okta with Rancher, so that authenticated users can access Rancher resources through their group permissions. Okta returns a SAML assertion that authenticates a user, including which groups a user belongs to.
|
||||
|
||||
1. In the top left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation menu, click **Auth Provider**.
|
||||
1. Click **Okta**.
|
||||
1. Complete the **Configure Okta Account** form. The examples below describe how you can map Okta attributes from attribute statements to fields within Rancher.
|
||||
1. Complete the **Configure Okta Account** form. The examples below describe how you can map Okta attributes from attribute statements to fields within Rancher.
|
||||
|
||||
| Field | Description |
|
||||
| ------------------------- | ----------------------------------------------------------------------------- |
|
||||
@@ -60,9 +66,46 @@ Setting | Value
|
||||
|
||||
:::note SAML Provider Caveats:
|
||||
|
||||
- SAML Protocol does not support search or lookup for users or groups. Therefore, there is no validation on users or groups when adding them to Rancher.
|
||||
If you configure Okta without OpenLDAP, you won't be able to search for or directly lookup users or groups. This brings several caveats:
|
||||
|
||||
- Users and groups aren't validated when you assign permissions to them in Rancher.
|
||||
- When adding users, the exact user IDs (i.e. `UID Field`) must be entered correctly. As you type the user ID, there will be no search for other user IDs that may match.
|
||||
- When adding groups, you must select the group from the drop-down that is next to the text box. Rancher assumes that any input from the text box is a user.
|
||||
- The group drop-down shows only the groups that you are a member of. You will not be able to add groups that you are not a member of.
|
||||
|
||||
:::
|
||||
|
||||
## Okta with OpenLDAP search
|
||||
|
||||
You can add an OpenLDAP backend to assist with user and group search. Rancher will display additional users and groups from the OpenLDAP service. This allows assigning permissions to groups that the logged-in user is not already a member of.
|
||||
|
||||
### OpenLDAP Prerequisites
|
||||
|
||||
If you use Okta as your IdP, you can [set up an LDAP interface](https://help.okta.com/en-us/Content/Topics/Directory/LDAP-interface-main.htm) for Rancher to use. You can also configure an external OpenLDAP server.
|
||||
|
||||
You must configure Rancher with a LDAP bind account (aka service account) so that you can search and retrieve LDAP entries for users and groups that should have access. Don't use an administrator account or personal account as an LDAP bind account. [Create](https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-add-users.htm) a dedicated account in OpenLDAP, with read-only access to users and groups under the configured searchbase.
|
||||
|
||||
:::warning Security Considerations
|
||||
|
||||
The OpenLDAP service account is used for all searches. Rancher users will see users and groups that the OpenLDAP service account can view, regardless of their individual SAML permissions.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
> **Using TLS?**
|
||||
>
|
||||
> If the certificate used by the OpenLDAP server is self-signed or from an unrecognized certificate authority, Rancher needs the CA certificate (concatenated with any intermediate certificates) in PEM format. Provide this certificate during the configuration so that Rancher can validate the certificate chain.
|
||||
|
||||
### Configure OpenLDAP in Rancher
|
||||
|
||||
[Configure the settings](../configure-openldap/openldap-config-reference.md) for the OpenLDAP server, groups and users. Note that nested group membership isn't available.
|
||||
|
||||
> Before you proceed with the configuration, please familiarise yourself with [external authentication configuration and principal users](../../../../pages-for-subheaders/authentication-config.md#external-authentication-configuration-and-principal-users).
|
||||
|
||||
1. Sign into Rancher using a local user assigned the [administrator](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions) role (i.e., the _local principal_).
|
||||
1. In the top left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation menu, click **Auth Provider**.
|
||||
1. Click **Okta** or, if SAML is already configured, **Edit Config**
|
||||
1. Under **User and Group Search**, check **Configure an OpenLDAP server**
|
||||
|
||||
If you experience issues when you test the connection to the OpenLDAP server, ensure that you entered the credentials for the service account and configured the search base correctly. Inspecting the Rancher logs can help pinpoint the root cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) for more information.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Configure PingIdentity (SAML)
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-pingidentity"/>
|
||||
</head>
|
||||
|
||||
If your organization uses Ping Identity Provider (IdP) for user authentication, you can configure Rancher to allow your users to log in using their IdP credentials.
|
||||
|
||||
>**Prerequisites:**
|
||||
|
||||
+5
-1
@@ -2,7 +2,11 @@
|
||||
title: Local Authentication
|
||||
---
|
||||
|
||||
Local authentication is the default until you configure an external authentication provider. Local authentication is where Rancher stores the user information, i.e. names and passwords, of who can log in to Rancher. By default, the `admin` user that logs in to Rancher for the first time is a local user.
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/create-local-users"/>
|
||||
</head>
|
||||
|
||||
Local authentication is the default until you configure an external authentication provider. Rancher stores user account information, such as usernames and passwords, locally. By default, the `admin` user that logs in to Rancher for the first time is a local user.
|
||||
|
||||
## Adding Local Users
|
||||
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Users and Groups
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups"/>
|
||||
</head>
|
||||
|
||||
Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When you configure an external authentication provider, users from that provider will be able to log in to your Rancher server. When a user logs in, the authentication provider will supply your Rancher server with a list of groups to which the user belongs.
|
||||
|
||||
Access to clusters, projects, multi-cluster apps, and global DNS providers and entries can be controlled by adding either individual users or groups to these resources. When you add a group to a resource, all users who are members of that group in the authentication provider, will be able to access the resource with the permissions that you've specified for the group. For more information on roles and permissions, see [Role Based Access Control](../../../../pages-for-subheaders/manage-role-based-access-control-rbac.md).
|
||||
|
||||
+5
-1
@@ -2,7 +2,11 @@
|
||||
title: 1. Configuring Microsoft AD FS for Rancher
|
||||
---
|
||||
|
||||
Before configuring Rancher to support AD FS users, you must add Rancher as a [relying party trust](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts) in AD FS.
|
||||
<head>
|
||||
<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/configure-ms-adfs-for-rancher"/>
|
||||
</head>
|
||||
|
||||
Before you configure Rancher to support Active Directory Federation Service (AD FS), you must add Rancher as a [relying party trust](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts) in AD FS.
|
||||
|
||||
1. Log into your AD server as an administrative user.
|
||||
|
||||
|
||||
+5
-1
@@ -2,7 +2,11 @@
|
||||
title: 2. Configuring Rancher for Microsoft AD FS
|
||||
---
|
||||
|
||||
After you complete [Configuring Microsoft AD FS for Rancher](configure-ms-adfs-for-rancher.md), enter your AD FS information into Rancher to allow AD FS users to authenticate with Rancher.
|
||||
<head>
|
||||
<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/configure-rancher-for-ms-adfs"/>
|
||||
</head>
|
||||
|
||||
After you complete [Configuring Microsoft AD FS for Rancher](configure-ms-adfs-for-rancher.md), enter your Active Directory Federation Service (AD FS) information into Rancher so that AD FS users can authenticate with Rancher.
|
||||
|
||||
:::note Important Notes For Configuring Your ADFS Server:
|
||||
|
||||
|
||||
+4
-2
@@ -2,9 +2,11 @@
|
||||
title: OpenLDAP Configuration Reference
|
||||
---
|
||||
|
||||
This section is intended to be used as a reference when setting up an OpenLDAP authentication provider in Rancher.
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-openldap/openldap-config-reference"/>
|
||||
</head>
|
||||
|
||||
For further details on configuring OpenLDAP, refer to the [official documentation.](https://www.openldap.org/doc/)
|
||||
For further details on configuring OpenLDAP authentication, refer to the [official documentation.](https://www.openldap.org/doc/)
|
||||
|
||||
> Before you proceed with the configuration, please familiarize yourself with the concepts of [External Authentication Configuration and Principal Users](../../../../pages-for-subheaders/authentication-config.md#external-authentication-configuration-and-principal-users).
|
||||
|
||||
|
||||
+4
-2
@@ -2,9 +2,11 @@
|
||||
title: Group Permissions with Shibboleth and OpenLDAP
|
||||
---
|
||||
|
||||
This page provides background information and context for Rancher users who intend to set up the Shibboleth authentication provider in Rancher.
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-shibboleth-saml/about-group-permissions"/>
|
||||
</head>
|
||||
|
||||
Because Shibboleth is a SAML provider, it does not support searching for groups. While a Shibboleth integration can validate user credentials, it can't be used to assign permissions to groups in Rancher without additional configuration.
|
||||
Because Shibboleth is a SAML provider, it doesn't support searching for groups. While a Shibboleth integration can validate user credentials, it can't be used to assign permissions to groups in Rancher without additional configuration.
|
||||
|
||||
One solution to this problem is to configure an OpenLDAP identity provider. With an OpenLDAP back end for Shibboleth, you will be able to search for groups in Rancher and assign them to resources such as clusters, projects, or namespaces from the Rancher UI.
|
||||
|
||||
|
||||
+16
-2
@@ -2,9 +2,17 @@
|
||||
title: Pod Security Policies
|
||||
---
|
||||
|
||||
_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification (like root privileges).
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies"/>
|
||||
</head>
|
||||
|
||||
If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message of `Pod <NAME> is forbidden: unable to validate...`.
|
||||
:::caution
|
||||
Pod Security Policies are only available in Kubernetes until v1.24. [Pod Security Standards](pod-security-standards.md) are the built-in alternative.
|
||||
:::
|
||||
|
||||
[Pod Security Policies (PSPs)](https://kubernetes.io/docs/concepts/security/pod-security-policy/) are objects that control security-sensitive aspects of the pod specification (such as root privileges).
|
||||
|
||||
If a pod doesn't meet the conditions specified in the PSP, Kubernetes won't allow it to start, and Rancher will display the following error message: `Pod <NAME> is forbidden: unable to validate...`.
|
||||
|
||||
|
||||
## How PSPs Work
|
||||
@@ -40,6 +48,12 @@ This policy is a relaxed version of the `restricted-noroot` policy, with almost
|
||||
|
||||
This policy is equivalent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project.
|
||||
|
||||
:::note important
|
||||
|
||||
When disabling PSPs, default PSPs are **not** automatically deleted from your cluster. You must manually delete them if they're no longer needed.
|
||||
|
||||
:::
|
||||
|
||||
## Creating PSPs
|
||||
|
||||
Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file.
|
||||
|
||||
+6
-21
@@ -2,26 +2,24 @@
|
||||
title: Custom Branding
|
||||
---
|
||||
|
||||
Rancher v2.6 introduced the ability to customize Rancher’s branding and navigation links.
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/custom-branding"/>
|
||||
</head>
|
||||
|
||||
## Changing Brand Settings
|
||||
|
||||
:::note Prerequisite:
|
||||
## Prerequisite
|
||||
|
||||
You will need to have at least cluster member permissions.
|
||||
|
||||
:::
|
||||
## Brand Configuration
|
||||
|
||||
To configure the brand settings,
|
||||
|
||||
1. Click **☰ > Global settings**.
|
||||
2. Click **Branding**.
|
||||
|
||||
## Brand Configuration
|
||||
|
||||
### Private Label Company Name
|
||||
|
||||
This option replaces “Rancher” with the value you provide in most places. Files that need to have Rancher in the name, such as “rancher-compose.yml”, will not be changed.
|
||||
This option replaces "Rancher" with the value you provide in most places. Files that need to have Rancher in the name, such as `rancher-compose.yml`, won't be changed.
|
||||
|
||||
### Support Links
|
||||
|
||||
@@ -37,26 +35,13 @@ You can override the primary color used throughout the UI with a custom color of
|
||||
|
||||
### Fixed Banners
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher before v2.6.4">
|
||||
|
||||
Display a custom fixed banner in the header, footer, or both.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher v2.6.4+">
|
||||
|
||||
Display a custom fixed banner in the header, footer, or both.
|
||||
|
||||
As of Rancher v2.6.4, configuration of fixed banners has moved from the **Branding** tab to the **Banners** tab.
|
||||
|
||||
To configure banner settings,
|
||||
|
||||
1. Click **☰ > Global settings**.
|
||||
2. Click **Banners**.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Custom Navigation Links
|
||||
|
||||
In this section, you'll learn how to configure the links in the left navigation bar of the **Cluster Dashboard**. To get to the cluster dashboard,
|
||||
|
||||
+41
-17
@@ -2,36 +2,60 @@
|
||||
title: Configuring a Global Default Private Registry
|
||||
---
|
||||
|
||||
You might want to use a private container image registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the container images that are used in your clusters.
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry"/>
|
||||
</head>
|
||||
|
||||
There are two main ways to set up private registries in Rancher: by setting up the global default registry through the **Settings** tab in the global view, and by setting up a private registry in the advanced options in the cluster-level settings. The global default registry is intended to be used for air-gapped setups, for registries that do not require credentials. The cluster-level private registry is intended to be used in all setups in which the private registry requires credentials.
|
||||
:::note
|
||||
This page describes how to configure a global default private registry from the Rancher UI, after Rancher is already installed.
|
||||
|
||||
This section is about configuring the global default private registry, and focuses on how to configure the registry from the Rancher UI after Rancher is installed.
|
||||
For instructions on how to set up a private registry during Rancher installation, refer to the [air-gapped installation guide](../../../pages-for-subheaders/air-gapped-helm-cli-install.md).
|
||||
|
||||
For instructions on setting up a private registry with command line options during the installation of Rancher, refer to the [air-gapped installation guide](../../../pages-for-subheaders/air-gapped-helm-cli-install.md).
|
||||
:::
|
||||
|
||||
If your private registry requires credentials, it cannot be used as the default registry. There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry with credentials, you will have to [pass in the registry credentials through the advanced cluster options](#setting-a-private-registry-with-credentials-when-deploying-a-cluster) every time you create a new cluster.
|
||||
A private registry is a private, consistent, and centralized source of truth for the container images in your clusters. You can use a private container image registry to share custom base images within your organization.
|
||||
|
||||
## Setting a Private Registry with No Credentials as the Default Registry
|
||||
There are two main ways to set up a private registry in Rancher:
|
||||
|
||||
* Set up a global default registry through the **Settings** tab in the global view.
|
||||
* Set up a private registry in the advanced options under cluster-level settings.
|
||||
|
||||
The global default registry is intended to be used in air-gapped setups, for registries that don't require credentials. The cluster-level private registry is intended to be used in setups where the private registry requires credentials.
|
||||
|
||||
## Set a Private Registry with No Credentials as the Default Registry
|
||||
|
||||
1. Log into Rancher and configure the default administrator password.
|
||||
1. Click **☰ > Global Settings**.
|
||||
1. Go to the setting called `system-default-registry` and choose **⋮ > Edit Setting**.
|
||||
1. Change the value to your registry (e.g. `registry.yourdomain.com:port`). Do not prefix the registry with `http://` or `https://`.
|
||||
1. Select **☰ > Global Settings**.
|
||||
1. Go to `system-default-registry` and choose **⋮ > Edit Setting**.
|
||||
1. Enter your registry's hostname and port (e.g. `registry.yourdomain.com:port`). Do not prefix the text with `http://` or `https://`.
|
||||
|
||||
**Result:** Rancher will use your private registry to pull system images.
|
||||
**Result:** Rancher pulls system images from your private registry.
|
||||
|
||||
## Setting a Private Registry with Credentials when Deploying a Cluster
|
||||
### Namespaced Private Registry with RKE2 Downstream Clusters
|
||||
|
||||
You can follow these steps to configure a private registry when you create a cluster:
|
||||
Most private registries should work, by default, with RKE2 downstream clusters.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
However, you'll need to do some additional steps if you're trying to set a namespaced private registry whose URL is formated like this: `website/subdomain:portnumber`.
|
||||
|
||||
1. Select **☰ > Cluster Management**.
|
||||
1. Find the RKE2 cluster in the list and click **⋮ >Edit Config**.
|
||||
1. From the **Cluster config** menu, select **Registries**.
|
||||
1. In the **Registries** pane, select the **Configure advanced containerd mirroring and registry authentication options** option.
|
||||
1. In the text fields under **Mirrors**, enter the **Registry Hostname** and **Mirror Endpoints**.
|
||||
1. Click **Save**.
|
||||
1. Repeat as necessary for each downstream RKE2 cluster.
|
||||
|
||||
## Configure a Private Registry with Credentials when Creating a Cluster
|
||||
|
||||
There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry that requires credentials, you'll have to pass the registry credentials through the advanced cluster options every time you create a new cluster.
|
||||
|
||||
Since the private registry cannot be configured after the cluster is created, you'll need to perform these steps during initial cluster setup.
|
||||
|
||||
1. Select **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Choose a cluster type.
|
||||
1. In the **Cluster Configuration** go to the **Registries** tab and click **Pull images for Rancher from a private registry**.
|
||||
1. In the **Cluster Configuration** go to the **Registries** tab and select **Pull images for Rancher from a private registry**.
|
||||
1. Enter the registry hostname and credentials.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** The new cluster will be able to pull images from the private registry.
|
||||
|
||||
The private registry cannot be configured after the cluster is created.
|
||||
**Result:** The new cluster pulls images from the private registry.
|
||||
|
||||
+5
-1
@@ -2,6 +2,10 @@
|
||||
title: Cluster and Project Roles
|
||||
---
|
||||
|
||||
<head>
|
||||
<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/cluster-and-project-roles"/>
|
||||
</head>
|
||||
|
||||
Cluster and project roles define user authorization inside a cluster or project.
|
||||
|
||||
To manage these roles,
|
||||
@@ -228,7 +232,7 @@ If you want to remove a default role, edit the permission and select **No** from
|
||||
|
||||
### Cluster Membership Revocation Behavior
|
||||
|
||||
When you revoke the cluster membership for a standard user that's explicitly assigned membership to both the cluster _and_ a project within the cluster, that standard user [loses their cluster roles](#clus-roles) but [retains their project roles](#proj-roles). In other words, although you have revoked the user's permissions to access the cluster and its nodes, the standard user can still:
|
||||
When you revoke the cluster membership for a standard user that's explicitly assigned membership to both the cluster _and_ a project within the cluster, that standard user [loses their cluster roles](#cluster-roles) but [retains their project roles](#project-roles). In other words, although you have revoked the user's permissions to access the cluster and its nodes, the standard user can still:
|
||||
|
||||
- Access the projects they hold membership in.
|
||||
- Exercise any [individual project roles](#project-role-reference) they are assigned.
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: Custom Roles
|
||||
---
|
||||
|
||||
<head>
|
||||
<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/custom-roles"/>
|
||||
</head>
|
||||
|
||||
Within Rancher, _roles_ determine what actions a user can make within a cluster or project.
|
||||
|
||||
Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access.
|
||||
|
||||
+5
-1
@@ -2,6 +2,10 @@
|
||||
title: Global Permissions
|
||||
---
|
||||
|
||||
<head>
|
||||
<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/global-permissions"/>
|
||||
</head>
|
||||
|
||||
_Permissions_ are individual access rights that you can assign when selecting a custom permission for a user.
|
||||
|
||||
Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are four default global permissions: `Administrator`, `Restricted Admin`,`Standard User` and `User-base`.
|
||||
@@ -115,7 +119,7 @@ To see the default permissions for new users,
|
||||
|
||||
You can [change the default permissions to meet your needs.](#configuring-default-global-permissions)
|
||||
|
||||
Permissions can be assigned to an individual user with [these steps.](#configuring-global-permissions-for-existing-individual-users)
|
||||
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.
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user