mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-21 12:25:19 +00:00
Merge branch 'rancher:main' into update-api-sidebar
This commit is contained in:
Sunil Singh
GitHub
+2
-1
@@ -160,7 +160,8 @@ helm repo update
|
||||
# Install the cert-manager Helm chart
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace
|
||||
--create-namespace \
|
||||
--set installCRDs=true
|
||||
```
|
||||
|
||||
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
|
||||
|
||||
+1
-1
@@ -53,7 +53,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
1. In the left navigation bar, click **Rancher Backups > Restore**.
|
||||
:::note
|
||||
|
||||
If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps**. Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#charts) for more information.
|
||||
If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps**. Refer [here](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#access-charts) for more information.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+6
-4
@@ -6,7 +6,9 @@ title: Troubleshooting Certificates
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting"/>
|
||||
</head>
|
||||
|
||||
### How Do I Know if My Certificates are in PEM Format?
|
||||
<DockerSupportWarning />
|
||||
|
||||
## How Do I Know if My Certificates are in PEM Format?
|
||||
|
||||
You can recognize the PEM format by the following traits:
|
||||
|
||||
@@ -48,7 +50,7 @@ VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
|
||||
-----END PRIVATE KEY-----
|
||||
```
|
||||
|
||||
### Converting a Certificate Key From PKCS8 to PKCS1
|
||||
## Converting a Certificate Key From PKCS8 to PKCS1
|
||||
|
||||
If you are using a PKCS8 certificate key file, Rancher will log the following line:
|
||||
|
||||
@@ -64,7 +66,7 @@ openssl rsa -in key.pem -out convertedkey.pem
|
||||
|
||||
You can now use `convertedkey.pem` as certificate key file for Rancher.
|
||||
|
||||
### What is the Order of Certificates if I Want to Add My Intermediate(s)?
|
||||
## What is the Order of Certificates if I Want to Add My Intermediate(s)?
|
||||
|
||||
The order of adding certificates is as follows:
|
||||
|
||||
@@ -77,7 +79,7 @@ The order of adding certificates is as follows:
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
### How Do I Validate My Certificate Chain?
|
||||
## How Do I Validate My Certificate Chain?
|
||||
|
||||
You can validate the certificate chain by using the `openssl` binary. If the output of the command (see the command example below) ends with `Verify return code: 0 (ok)`, your certificate chain is valid. The `ca.pem` file must be the same as you added to the `rancher/rancher` container.
|
||||
|
||||
|
||||
+2
-6
@@ -3,16 +3,12 @@ title: Installing Rancher on a Single Node Using Docker
|
||||
description: For development and testing environments only, use a Docker install. Install Docker on a single Linux host, and deploy Rancher with a single Docker container.
|
||||
---
|
||||
|
||||
:::caution
|
||||
|
||||
Docker installs are not supported in production environments. These instructions are provided for testing and development purposes only. Please don't use this method to install Rancher in production environments.
|
||||
|
||||
:::
|
||||
|
||||
<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"/>
|
||||
</head>
|
||||
|
||||
<DockerSupportWarning />
|
||||
|
||||
Rancher can be installed by running a single Docker container.
|
||||
|
||||
In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container.
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: Rolling Back Rancher Installed with Docker
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher"/>
|
||||
</head>
|
||||
|
||||
<DockerSupportWarning />
|
||||
|
||||
If a Rancher upgrade does not complete successfully, you'll have to roll back to your Rancher setup that you were using before [Docker Upgrade](upgrade-docker-installed-rancher.md). Rolling back restores:
|
||||
|
||||
- Your previous version of Rancher.
|
||||
|
||||
+1
-5
@@ -8,11 +8,7 @@ title: Upgrading Rancher Installed with Docker
|
||||
|
||||
The following instructions will guide you through upgrading a Rancher server that was installed with Docker.
|
||||
|
||||
:::caution
|
||||
|
||||
**Docker installs are not supported in production environments.** These instructions are provided for testing and development purposes only. If you have already deployed a Docker install in production and need to upgrade to a new Rancher version, we recommend [migrating to the Helm chart install](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) before upgrading.
|
||||
|
||||
:::
|
||||
<DockerSupportWarning />
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
||||
-2
@@ -52,8 +52,6 @@ When you need to make changes to your infrastructure, instead of manually updati
|
||||
|
||||
- You can reverse engineer how to do define a setting in Terraform by changing the setting in Rancher, then going back and checking your Terraform state file to see how it maps to the current state of your infrastructure.
|
||||
|
||||
- If you want to manage Kubernetes cluster settings, Rancher settings, and hardware settings all in one place, use [Terraform modules](https://github.com/rancher/terraform-modules). You can pass a cluster configuration YAML file or an RKE template configuration file to a Terraform module so that the Terraform module will create it. In that case, you could use your infrastructure-as-code to manage the version control and revision history of both your Kubernetes cluster and its underlying hardware.
|
||||
|
||||
## Tip for Creating CIS Benchmark Compliant Clusters
|
||||
|
||||
This section describes one way that you can make security and compliance-related config files standard in your clusters.
|
||||
|
||||
+114
-76
@@ -1,20 +1,48 @@
|
||||
---
|
||||
title: Helm Charts in Rancher
|
||||
title: Helm Charts and Apps
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/helm-charts-in-rancher"/>
|
||||
</head>
|
||||
|
||||
In this section, you'll learn how to manage Helm chart repositories and applications in Rancher. Helm chart repositories are managed using **Apps**. It uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Helm applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.
|
||||
In this section, you'll learn how to manage Helm chart repositories and apps in Rancher.
|
||||
|
||||
## How Helm Charts Work in Rancher
|
||||
|
||||
Helm chart repositories in Rancher are managed using **Apps**.
|
||||
|
||||
Rancher uses a catalog-like system to import bundles of charts from repositories and then uses those charts to either deploy custom Kubernetes applications or Rancher's tools such as Monitoring or Istio. Rancher tools come as pre-loaded repositories which deploy as standalone Helm charts. Any additional repositories are only added to the current cluster.
|
||||
|
||||
### Catalogs, Apps, and the Rancher UI
|
||||
|
||||
[Rancher v2.4 and earlier](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), repositories of ready-to-deploy applications were called "catalogs". These repositories were managed through the **Catalogs** section of the UI.
|
||||
|
||||
Rancher v2.5 replaced the former catalog system with a new **Apps & Marketplace** feature.
|
||||
|
||||
Since Rancher v2.6.5, the **Apps & Marketplace** feature is named **Apps** in the UI.
|
||||
|
||||
### Versioning Scheme
|
||||
|
||||
The Rancher feature charts versioning scheme is centered around the major version of the charts and the `+up` annotation for upstream charts, where applicable.
|
||||
|
||||
**Major Version:** The major version of the charts is tied to Rancher minor versions. When you upgrade to a new Rancher minor version, you should ensure that all of your **Apps** charts are also upgraded to the correct release line for the chart.
|
||||
**Major Version:** The major versions of feature charts are tied to particular minor versions of Rancher. When you upgrade to a new Rancher minor version, you should ensure that all of your feature charts are also upgraded to the correct release line for the chart.
|
||||
|
||||
**Feature Charts:**
|
||||
**Charts based on upstream:** When you upgrade, make sure that the upstream chart version is compatible with your Rancher version. The `+up` annotation for the chart indicates which upstream version the Rancher chart is tracking. For example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some additional Rancher patches.
|
||||
|
||||
When upgrading Rancher versions, don't downgrade the version of the chart that you are using. For example, if you are using a version of Monitoring that is later than `16.6.0` in Rancher v2.5, you shouldn't upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.
|
||||
|
||||
#### Prerelease Versions
|
||||
|
||||
Prereleases adhere to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` is considered a prerelease. Prerelease versions are not displayed by default and must be configured to do so.
|
||||
|
||||
To display prerelease versions:
|
||||
|
||||
1. Click on your user avatar in the upper right corner.
|
||||
1. Click **Preferences**.
|
||||
1. Under **Helm Charts**, select **Include Prerelease Versions**.
|
||||
|
||||
### Feature Charts
|
||||
|
||||
| **Name** | **Supported Minimum Version** | **Supported Maximum Version** |
|
||||
| ---------------- | ------------ | ------------ |
|
||||
@@ -35,73 +63,81 @@ The Rancher feature charts versioning scheme is centered around the major versio
|
||||
| rancher-vsphere-csi | 100.3.0+up2.5.1-rancher1 | 100.3.0+up2.5.1-rancher1 |
|
||||
| rancher-wins-upgrader | 0.0.100 | 100.0.1+up0.0.1 |
|
||||
|
||||
<br/>
|
||||
**Charts based on upstream:** For charts that are based on upstreams, the +up annotation should inform you of what upstream version the Rancher chart is tracking. Check the upstream version compatibility with Rancher during upgrades also.
|
||||
## Access Charts
|
||||
|
||||
- As an example, `100.x.x+up16.6.0` for Monitoring tracks upstream kube-prometheus-stack `16.6.0` with some Rancher patches added to it.
|
||||
The **Charts** page contains all Rancher, Partner, and Custom charts. You can filter charts by selecting the left-most dropdown menu:
|
||||
|
||||
- On upgrades, ensure that you are not downgrading the version of the chart that you are using. For example, if you are using a version of Monitoring > `16.6.0` in Rancher 2.5, you should not upgrade to `100.x.x+up16.6.0`. Instead, you should upgrade to the appropriate version in the next release.
|
||||
* Rancher tools such as Logging or Monitoring are listed under the **Rancher** label.
|
||||
* Partner charts are under the **Partners** label.
|
||||
* Custom charts are listed under the name of their respective repository.
|
||||
|
||||
### Prerelease Versions
|
||||
|
||||
Prereleases adhere to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` is considered a prerelease. Prerelease versions are not displayed by default and must be configured to do so.
|
||||
|
||||
To display prerelease versions:
|
||||
|
||||
1. Click on your user avatar in the upper right corner.
|
||||
1. Click **Preferences**.
|
||||
1. Under **Helm Charts**, select **Include Prerelease Versions**.
|
||||
|
||||
### Charts
|
||||
|
||||
From the top-left menu select _"Apps"_ and you will be taken to the Charts page.
|
||||
|
||||
The charts page contains all Rancher, Partner, and Custom Charts.
|
||||
|
||||
* Rancher tools such as Logging or Monitoring are included under the Rancher label
|
||||
* Partner charts reside under the Partners label
|
||||
* Custom charts will show up under the name of the repository
|
||||
|
||||
All three types are deployed and managed in the same way.
|
||||
All three types of charts are deployed and managed in the same way.
|
||||
|
||||
:::note
|
||||
|
||||
Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) should continue to be managed only by the Cluster Manager, and apps managed with <b>Apps</b> in the new UI must be managed only by <b>Apps</b>.
|
||||
Apps managed by the Cluster Manager (the global view in the legacy Rancher UI) continue to be managed only by the Cluster Manager, and apps managed with **Apps** in the new UI must be managed only by **Apps**.
|
||||
|
||||
:::
|
||||
|
||||
### Repositories
|
||||
To access the **Charts** page:
|
||||
|
||||
From the left sidebar select _"Repositories"_.
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose charts you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
|
||||
|
||||
These items represent Helm repositories, and can be either traditional Helm endpoints which have an index.yaml, or Git repositories which will be cloned and can point to a specific branch. In order to use custom charts, simply add your repository here and they will become available in the Charts tab under the name of the repository.
|
||||
## Manage Repositories
|
||||
|
||||
#### Add Custom Git Repositories
|
||||
The **Repositories** page lists your Helm repositories. These include traditional Helm endpoints which have an index.yaml, and Git repositories that are cloned and point to a specific branch. To use custom charts, add your repository here. After you add a repository, you can access custom charts in the **Charts** page, listed under the name of the repository.
|
||||
|
||||
Click **Create** and select the target, **Git repository containing Helm chart...** to add a custom Git repository that contains your Helm charts or cluster template definitions.
|
||||
To access the **Repositories** page:
|
||||
|
||||
You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from the default, `main`.
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
|
||||
Whenever you add a chart repository to Rancher, it becomes available immediately.
|
||||
### Add Custom Git Repositories
|
||||
|
||||
#### Add Custom Helm Chart Repositories
|
||||
To add a custom Git repository that contains your Helm charts or cluster template definitions:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Click **Create**.
|
||||
1. Select the target, **Git repository containing Helm chart...**.
|
||||
1. You must enter a name and a Git repository URL. The other fields, including the description, are optional. Enter an alternative branch name if you don't want to pull from whichever branch the repo owner has set as the default. Usually, the default branch is named either `main` or `master`.
|
||||
1. Click **Create** to add the repository.
|
||||
|
||||
After you add a chart repository to Rancher, it becomes available immediately.
|
||||
|
||||
### Add Custom Helm Chart Repositories
|
||||
|
||||
You can add your own Helm chart repositories to serve chart packages to Rancher. You can use any HTTP server, as long as the server can respond to GET requests and serve YAML files and tar archives.
|
||||
|
||||
For more information on Helm chart repositories, see the [official Helm docs](https://helm.sh/docs/topics/chart_repository/).
|
||||
|
||||
To add a custom Helm chart repository to Rancher, click **Create** and select **http(s) URL to an index generated by Helm** as the target. Enter a repo name and the index URL address of the chart repository.
|
||||
To add a custom Helm chart repository to Rancher:
|
||||
|
||||
#### Add Private Git/Helm Chart Repositories
|
||||
1. Click **☰**. Under **Explore Cluster** in the left navigation menu, select a cluster.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
|
||||
1. Click **Create**.
|
||||
1. Select the target, **http(s) URL to an index generated by Helm**.
|
||||
1. Enter a repo name and the index URL address of the chart repository.
|
||||
1. Click **Create** to add the repository.
|
||||
|
||||
### Add Private Git/Helm Chart Repositories
|
||||
|
||||
You can add private Git or Helm chart repositories with SSH key credentials or an HTTP basic auth secret, such as a username and password.
|
||||
|
||||
#### Add a Private CA to Repositories
|
||||
### Add a Private CA to Repositories
|
||||
|
||||
To add a private CA to Helm chart repositories:
|
||||
To add a private CA to Helm chart repositories, you must add a base64 encoded copy of the CA certificate in DER format to the `spec.caBundle field` of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Instructions are the same for both Git-based and HTTP-based repositories:
|
||||
|
||||
- **HTTP-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
|
||||
```
|
||||
1. Click **☰**. Under **Explore Cluster** in the left navigation menu, select a cluster.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the row associated with the Git or HTTP-based repository you want to add a private CA to, and click **⋮ > Edit YAML**.
|
||||
1. Set the `caBundle` value, as in the following example:
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
spec:
|
||||
caBundle:
|
||||
@@ -109,25 +145,13 @@ To add a private CA to Helm chart repositories:
|
||||
...
|
||||
nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
|
||||
[...]
|
||||
```
|
||||
|
||||
|
||||
- **Git-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
|
||||
```
|
||||
[...]
|
||||
spec:
|
||||
caBundle:
|
||||
MIIFXzCCA0egAwIBAgIUWNy8WrvSkgNzV0zdWRP79j9cVcEwDQYJKoZIhvcNAQELBQAwPzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYDVQQKDAtNeU9yZywgSW5jLjENMAsGA1UEAwwEcm9vdDAeFw0yMTEyMTQwODMyMTdaFw0yNDEwMDMwODMyMT
|
||||
...
|
||||
nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
|
||||
[...]
|
||||
```
|
||||
```
|
||||
|
||||
:::note Helm chart repositories with authentication
|
||||
|
||||
The Repo.Spec contains a `disableSameOriginCheck` value that allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
|
||||
The Repo.Spec contains a `disableSameOriginCheck` value. This value allows you to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories, such as those that have redirects to a different origin URL.
|
||||
|
||||
To use this feature for an existing Helm chart repository, click <b>⋮ > Edit YAML</b>. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
|
||||
To use this feature for an existing Helm chart repository, follow previous steps up to edit the YAML. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
|
||||
|
||||
```yaml
|
||||
[...]
|
||||
@@ -142,37 +166,51 @@ spec:
|
||||
|
||||
Only Helm 3 compatible charts are supported.
|
||||
|
||||
## Deploy and Upgrade Charts
|
||||
|
||||
### Deployment and Upgrades
|
||||
To install and deploy a chart:
|
||||
|
||||
From the _"Charts"_ tab select a Chart to install. Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files, but all chart installations can modify the values.yaml and other basic settings. Once you click install, a Helm operation job is deployed, and the console for the job is displayed.
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose charts you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
|
||||
1. Select a chart, and click **Install**.
|
||||
|
||||
To view all recent changes, go to the _"Recent Operations"_ tab. From there you can view the call that was made, conditions, events, and logs.
|
||||
Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files. However, all chart installations can modify the values.yaml and other basic settings. After you click **Install**, a Helm operation job is deployed, and the console for the job is displayed.
|
||||
|
||||
After installing a chart, you can find it in the _"Installed Apps"_ tab. In this section you can upgrade or delete the installation, and see further details. When choosing to upgrade, the form and values presented will be the same as installation.
|
||||
To view all recent changes, click **Apps > Recent Operations** in the left navigation menu. From there you can view the calls, conditions, events, and logs.
|
||||
|
||||
Most Rancher tools have additional pages located in the toolbar below the _"Apps"_ section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.
|
||||
After installing a chart, you can view it by clicking **Apps > Installed Apps** in the left navigation menu. You can upgrade or delete the installation, and see further details. Upgrading uses the same forms and values as you saw during inital installation.
|
||||
|
||||
Most Rancher tools have additional pages located in the toolbar below the **Apps** section to help manage and use the features. These pages include links to dashboards, forms to easily add Custom Resources, and additional information.
|
||||
|
||||
:::caution
|
||||
|
||||
If you are upgrading your chart using _"Customize Helm options before upgrade"_ , please be aware that using the _"--force"_ option may result in errors if your chart has immutable fields. This is because some objects in Kubernetes cannot be changed once they are created. To ensure you do not get this error you can:
|
||||
If you are upgrading your chart using **Customize Helm options before upgrade**, and your chart contains immutable fields, using the `--force` option may result in errors. This is because some objects in Kubernetes can't be changed after they're created. To prevent this error:
|
||||
|
||||
* use the default upgrade option ( i.e do not use _"--force"_ option )
|
||||
* uninstall the existing chart and install the upgraded chart
|
||||
* delete the resources with immutable fields from the cluster before performing the _"--force"_ upgrade
|
||||
* Use the default upgrade option (i.e don't use `--force`).
|
||||
* Uninstall the existing chart and install the upgraded chart.
|
||||
* Delete the resources with immutable fields from the cluster before performing a forced upgrade.
|
||||
|
||||
:::
|
||||
|
||||
#### Legacy Apps
|
||||
### Legacy Apps
|
||||
|
||||
The upgrade button has been removed for legacy apps from the **Apps > Installed Apps** page.
|
||||
The upgrade button isn't available for legacy apps on the **Apps > Installed Apps** page.
|
||||
|
||||
If you have a legacy app installed and want to upgrade it:
|
||||
If you want to upgrade an installed legacy app, the [legacy feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on. This flag is automatically turned on if you had a legacy app already running before you upgraded Rancher.
|
||||
|
||||
- The legacy [feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) must be turned on (if it's not turned on automatically because of having a legacy app before upgrading)
|
||||
- You can upgrade the app from cluster explorer, from the left nav section **Legacy > Project > Apps**
|
||||
- For multi-cluster apps, you can go to **≡ > Multi-cluster Apps** and upgrade the app from there
|
||||
1. Enable the [legacy feature flag](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md), if it isn't enabled already.
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose apps you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. Click **Legacy > Project > Apps**.
|
||||
|
||||
### Limitations
|
||||
If you don't see **Apps** listed under **Legacy > Project**, click the project/namespace search bar in the top navigation and select the relevant project from the dropdown menu.
|
||||
|
||||
Dashboard apps or Rancher feature charts **cannot** be installed using the Rancher CLI.
|
||||
To upgrade legacy multi-cluster apps:
|
||||
|
||||
1. Click **☰**.
|
||||
1. Under **Legacy Apps**, click **Multi-cluster Apps**.
|
||||
|
||||
## Limitations
|
||||
|
||||
Dashboard apps or Rancher feature charts can't be installed using the Rancher CLI.
|
||||
+3
-3
@@ -6,9 +6,9 @@ title: Migrating Amazon In-tree to Out-of-tree
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-amazon"/>
|
||||
</head>
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. In Kubernetes 1.27 and later, the in-tree cloud providers have been removed.
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. In Kubernetes v1.27 and later, the in-tree cloud providers have been removed. The Rancher UI allows you to upgrade to Kubernetes v1.27 when you migrate from an in-tree to out-of-tree provider.
|
||||
|
||||
You can migrate from an in-tree to an out-of-tree AWS cloud provider on Kubernetes 1.26 and earlier. All existing clusters must migrate prior to upgrading to v1.27 in order to stay functional.
|
||||
However, if you're performing a manual migration, existing clusters must upgrade to Kubernetes v1.27 after you migrate in order to remain functional.
|
||||
|
||||
To migrate from the in-tree cloud provider to the out-of-tree AWS cloud provider, you must stop the existing cluster's kube controller manager and install the AWS cloud controller manager. There are many ways to do this. Refer to the official AWS documentation on the [external cloud controller manager](https://cloud-provider-aws.sigs.k8s.io/getting_started/) for details.
|
||||
|
||||
@@ -52,7 +52,7 @@ spec:
|
||||
2. Cordon control plane nodes so that AWS cloud controller pods run on nodes only after upgrading to the external cloud provider:
|
||||
|
||||
```shell
|
||||
kubectl cordon -l "node-role.kubernetes.io/controlplane=true"
|
||||
kubectl cordon -l "node-role.kubernetes.io/control-plane=true"
|
||||
```
|
||||
|
||||
3. To install the AWS cloud controller manager with leader migration enabled, follow Steps 1-3 for [deploying the cloud controller manager chart](../set-up-cloud-providers/amazon.md#using-the-out-of-tree-aws-cloud-provider). From Kubernetes 1.22 onwards, the kube-controller-manager will utilize a default configuration which will satisfy the controller-to-manager migration. Update container args of the `aws-cloud-controller-manager` under `spec.rkeConfig.additionalManifest` to enable leader migration:
|
||||
|
||||
+6
-6
@@ -352,9 +352,9 @@ tolerations:
|
||||
value: 'true'
|
||||
- effect: NoSchedule
|
||||
value: 'true'
|
||||
key: node-role.kubernetes.io/controlplane
|
||||
key: node-role.kubernetes.io/control-plane
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/controlplane: 'true'
|
||||
node-role.kubernetes.io/control-plane: 'true'
|
||||
args:
|
||||
- --configure-cloud-routes=false
|
||||
- --use-service-account-credentials=true
|
||||
@@ -639,7 +639,7 @@ kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
|
||||
- get
|
||||
```
|
||||
|
||||
9. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector:
|
||||
9. Rancher-provisioned RKE2 nodes are tainted `node-role.kubernetes.io/control-plane`. Update tolerations and the nodeSelector:
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
@@ -648,13 +648,13 @@ tolerations:
|
||||
value: 'true'
|
||||
- effect: NoSchedule
|
||||
value: 'true'
|
||||
key: node-role.kubernetes.io/controlplane
|
||||
key: node-role.kubernetes.io/control-plane
|
||||
|
||||
```
|
||||
|
||||
```yaml
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/controlplane: 'true'
|
||||
node-role.kubernetes.io/control-plane: 'true'
|
||||
```
|
||||
|
||||
:::note
|
||||
@@ -663,7 +663,7 @@ There's currently a [known issue](https://github.com/rancher/dashboard/issues/92
|
||||
|
||||
```yaml
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/controlplane: 'true'
|
||||
node-role.kubernetes.io/control-plane: 'true'
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
+3
-1
@@ -18,7 +18,7 @@ In clusters that store data on GlusterFS volumes, you may experience an issue wh
|
||||
- The `systemd-run` binary needs to be compatible with Debian OS on which the hyperkube image is based (this can be checked using the following command on each cluster node, replacing the image tag with the Kubernetes version you want to use)
|
||||
|
||||
```
|
||||
docker run -v /usr/bin/systemd-run:/usr/bin/systemd-run --entrypoint /usr/bin/systemd-run rancher/hyperkube:v1.16.2-rancher1 --version
|
||||
docker run -v /usr/bin/systemd-run:/usr/bin/systemd-run -v /usr/lib/x86_64-linux-gnu/libcrypto.so.3:/usr/lib/x86_64-linux-gnu/libcrypto.so.3 -v /lib/systemd/libsystemd-shared-249.so:/lib/systemd/libsystemd-shared-249.so --entrypoint /usr/bin/systemd-run rancher/hyperkube:v1.26.14-rancher1 --version
|
||||
```
|
||||
|
||||
:::caution
|
||||
@@ -32,6 +32,8 @@ services:
|
||||
kubelet:
|
||||
extra_binds:
|
||||
- "/usr/bin/systemd-run:/usr/bin/systemd-run"
|
||||
- "/usr/lib/x86_64-linux-gnu/libcrypto.so.3:/usr/lib/x86_64-linux-gnu/libcrypto.so.3"
|
||||
- "/lib/systemd/libsystemd-shared-249.so:/lib/systemd/libsystemd-shared-249.so"
|
||||
```
|
||||
|
||||
After the cluster has finished provisioning, you can check the `kubelet` container logging to see if the functionality is activated by looking for the following logline:
|
||||
|
||||
+3
@@ -20,6 +20,9 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|:----------------:|
|
||||
| v2.8.0 | v103.0.0+up3.0.0 |
|
||||
| v2.8.1 | v103.0.0+up3.0.0 |
|
||||
| v2.8.2 | v103.0.0+up3.0.0 |
|
||||
| v2.8.3 | v103.0.1+up3.0.1 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
|
||||
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.8.3 | v0.4.3 | ✗ | ✓ |
|
||||
| v2.8.2 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.1 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.0 | v0.4.2 | ✗ | ✓ |
|
||||
|
||||
@@ -74,10 +74,15 @@ kubectl -n ingress-nginx logs -l app=ingress-nginx
|
||||
|
||||
### Leader election
|
||||
|
||||
The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` ConfigMap (in this example, `rancher-7dbd7875f7-qbj5k`).
|
||||
The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` Lease in the `kube-system` namespace (in this example, `rancher-dbc7ff869-gvg6k`).
|
||||
|
||||
```
|
||||
kubectl -n kube-system get configmap cattle-controllers -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
|
||||
{"holderIdentity":"rancher-7dbd7875f7-qbj5k","leaseDurationSeconds":45,"acquireTime":"2019-04-04T11:53:12Z","renewTime":"2019-04-04T12:24:08Z","leaderTransitions":0}
|
||||
kubectl -n kube-system get lease cattle-controllers
|
||||
```
|
||||
|
||||
Example output:
|
||||
|
||||
```
|
||||
NAME HOLDER AGE
|
||||
cattle-controllers rancher-dbc7ff869-gvg6k 6h10m
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user