mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 13:08:11 +00:00
Merge branch 'rancher:main' into update-api-sidebar
This commit is contained in:
Submodule
+1
Submodule .github/styles/suse-vale-styleguide added at 06f144fdfc
@@ -0,0 +1,53 @@
|
||||
# This action gets all changed markdown files in /docs and /versioned_docs using tj-actions/changed-files@v42
|
||||
# It compares new commits in the PR with the base commit (github.event.pull_request.base.sha)
|
||||
# It checks if no markdown files are changed
|
||||
# It shows a count of markdown files and lists all changed markdown files
|
||||
# It uses Vale (https://vale.sh/docs/vale-cli/installation/) to provide feedback base off the SUSE Style Guide / OpenSUSE style rules (https://github.com/openSUSE/suse-vale-styleguide)
|
||||
|
||||
name: Style check
|
||||
on: [pull_request]
|
||||
|
||||
jobs:
|
||||
vale-lint:
|
||||
name: runner / vale
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0 # OR "2" -> To retrieve the preceding commit.
|
||||
submodules: true
|
||||
- name: Get all changed markdown files
|
||||
id: changed-markdown-files
|
||||
uses: tj-actions/changed-files@v42
|
||||
with:
|
||||
# Avoid using single or double quotes for multiline patterns
|
||||
files: |
|
||||
docs/**
|
||||
versioned_docs/**
|
||||
separator: ","
|
||||
base_sha: ${{ github.event.pull_request.base.sha }}
|
||||
env:
|
||||
ALL_CHANGED_FILES: ${{ 0 }}
|
||||
- name: No files changed?
|
||||
if: steps.changed-markdown-files.outputs.any_changed == 'false'
|
||||
run: |
|
||||
echo "No files changed"
|
||||
echo "ALL_CHANGED_FILES=$ALL_CHANGED_FILES" >> $GITHUB_ENV
|
||||
- name: List all changed files markdown files
|
||||
if: steps.changed-markdown-files.outputs.any_changed == 'true'
|
||||
env:
|
||||
ALL_CHANGED_FILES: ${{ steps.changed-markdown-files.outputs.all_changed_files }}
|
||||
ALL_CHANGED_FILES_COUNT: ${{ steps.changed-markdown-files.outputs.all_changed_files_count }}
|
||||
SHA: ${{ github.head_ref }}
|
||||
HEAD: ${{ github.base_ref }}
|
||||
run: |
|
||||
echo "Total Files Changed:" ${ALL_CHANGED_FILES_COUNT}
|
||||
echo ${ALL_CHANGED_FILES}
|
||||
echo "ALL_CHANGED_FILES=$ALL_CHANGED_FILES" >> $GITHUB_ENV
|
||||
- uses: errata-ai/vale-action@v2.1.0
|
||||
if: steps.changed-markdown-files.outputs.any_changed == 'true'
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
with:
|
||||
separator: ", "
|
||||
files: ${{ env.ALL_CHANGED_FILES }}
|
||||
@@ -0,0 +1,3 @@
|
||||
[submodule ".github/styles/suse-vale-styleguide"]
|
||||
path = .github/styles/suse-vale-styleguide
|
||||
url = https://github.com/openSUSE/suse-vale-styleguide
|
||||
@@ -0,0 +1,7 @@
|
||||
StylesPath = .github/styles
|
||||
|
||||
[formtats]
|
||||
mdx = md
|
||||
|
||||
[*.md]
|
||||
BasedOnStyles = suse-vale-styleguide
|
||||
@@ -27,7 +27,17 @@ The file paths in the repo correspond to the URLs for pages on the docs website.
|
||||
|
||||
### Style & Formatting
|
||||
|
||||
The docs are written in [Markdown](https://www.markdownguide.org/getting-started/). We refer to the Microsoft [style guide](https://learn.microsoft.com/en-us/style-guide/welcome/) and use standard American English. Many pages are also available in Simplified Chinese.
|
||||
The docs are written in [Markdown](https://www.markdownguide.org/getting-started/). We use standard American English and many pages are also available in Simplified Chinese.
|
||||
|
||||
Moving forward, we are referring to the SUSE [style guide](https://documentation.suse.com/style/current/pdf/style-guide_en.pdf). The **Style check / runner / vale (pull_request)** check used [Vale](https://vale.sh/) to make style and grammar suggestions for new or updated documentation based on the SUSE style guide. To review these suggestions when working on a PR:
|
||||
|
||||
1. Select the details of the **Style check / runner / vale (pull_request)** check.
|
||||
1. In the logs, go to **Run errata-ai/vale-action@v2.1.0** and select **Running vale with reviewdog 🐶 ...** to view the suggestions.
|
||||
1. New or updated files are checked against the SUSE style guide. Suggestions have the following format: '{"message": "[suse-vale-styleguide.Rule] Rule description", "location": {"path": "file-path", "range": {"start": {"line": , "column": }}}, "severity": " "}'
|
||||
|
||||
For example: '{"message": "[suse-vale-styleguide.Usage] Use 'certain' instead of 'some'", "location": {"path": "docs/contribute-to-rancher.md", "range": {"start": {"line": 3, "column": 132}}}, "severity": "WARNING"}'
|
||||
|
||||
1. Incorporate the suggestions when possible and appropriate.
|
||||
|
||||
Every docs page contain metadata in the first few lines:
|
||||
|
||||
|
||||
@@ -8,7 +8,8 @@
|
||||
"lvl2": "article h2",
|
||||
"lvl3": "article h3",
|
||||
"lvl4": "article h4",
|
||||
"lvl5": "article h5"
|
||||
"lvl5": "article h5",
|
||||
"lvl6": "article h6"
|
||||
},
|
||||
"custom_settings": {
|
||||
"attributesForFaceting": [
|
||||
|
||||
+6
-10
@@ -3,10 +3,10 @@ title: Deprecated Features in Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features-in-v2.5"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
|
||||
</head>
|
||||
|
||||
### What is Rancher's Deprecation policy?
|
||||
### What is Rancher's deprecation policy?
|
||||
|
||||
We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).
|
||||
|
||||
@@ -16,14 +16,10 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) | Aug 31, 2021 |
|
||||
| [2.6.1](https://github.com/rancher/rancher/releases/tag/v2.6.1) | Oct 11, 2021 |
|
||||
| [2.6.2](https://github.com/rancher/rancher/releases/tag/v2.6.2) | Oct 19, 2021 |
|
||||
| [2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) | Dec 21, 2021 |
|
||||
| [2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) | Mar 31, 2022 |
|
||||
| [2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) | May 12, 2022 |
|
||||
| [2.6.6](https://github.com/rancher/rancher/releases/tag/v2.6.6) | Jun 30, 2022 |
|
||||
|
||||
| [2.8.3](https://github.com/rancher/rancher/releases/tag/v2.8.3) | Mar 28, 2024 |
|
||||
| [2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2) | Feb 8, 2024 |
|
||||
| [2.8.1](https://github.com/rancher/rancher/releases/tag/v2.8.1) | Jan 22, 2024 |
|
||||
| [2.8.0](https://github.com/rancher/rancher/releases/tag/v2.8.0) | Dec 6, 2023 |
|
||||
|
||||
### What can I expect when a feature is marked for deprecation?
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Dockershim
|
||||
title: Dockershim FAQ
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+10
-6
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Security
|
||||
title: Security FAQ
|
||||
|
||||
---
|
||||
|
||||
@@ -7,12 +7,16 @@ title: Security
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/security"/>
|
||||
</head>
|
||||
|
||||
**Is there a Hardening Guide?**
|
||||
### Is there a Hardening Guide?
|
||||
|
||||
The Hardening Guide is now located in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.
|
||||
The Hardening Guide is located in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.
|
||||
|
||||
<br/>
|
||||
|
||||
**What are the results of Rancher's Kubernetes cluster when it is CIS benchmarked?**
|
||||
### Have hardened Rancher Kubernetes clusters been evaluated by the CIS Kubernetes Benchmark? Where can I find the results?
|
||||
|
||||
We have run the CIS Kubernetes benchmark against a hardened Rancher Kubernetes cluster. The results of that assessment can be found in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.
|
||||
|
||||
### How does Rancher verify communication with downstream clusters, and what are some associated security concerns?
|
||||
|
||||
Communication between the Rancher server and downstream clusters is performed through agents. Rancher uses either a registered certificate authority (CA) bundle or the local trust store to verify communication between Rancher agents and the Rancher server. Using a CA bundle for verification is more strict, as only the certificates based on that bundle are trusted. If TLS verification for a explicit CA bundle fails, Rancher may fall back to using the local trust store for verifying future communication. Any CA within the local trust store can then be used to generate a valid certificate.
|
||||
|
||||
As described in [Rancher Security Update CVE-2024-22030](https://www.suse.com/c/rancher-security-update/), under a narrow set of circumstances, malicious actors can take over Rancher nodes by exploiting the behavior of Rancher CAs. For the attack to succeed, the malicious actor must generate a valid certificate from either a valid CA in the targeted Rancher server, or from a valid registered CA. The attacker also needs to either hijack or spoof the Rancher server-url as a preliminary step. Rancher is currently evaluating Rancher CA behavior to mitigate against this and any similar avenues of attack.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Technical
|
||||
title: Technical FAQ
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Telemetry
|
||||
title: Telemetry FAQ
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -19,7 +19,7 @@ Some feature flags require a restart of the Rancher container. Features that req
|
||||
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)):
|
||||
|
||||
- `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.
|
||||
- `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 [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/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 Overview](../../../integrations-in-rancher/harvester/overview.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.
|
||||
|
||||
+4
-14
@@ -17,7 +17,7 @@ For information on enabling experimental features, refer to [this page.](../../.
|
||||
|
||||
| Option | Default Value | Description |
|
||||
| ------------------------- | ------------- | ---------------------------------------------------------------------------------- |
|
||||
| `bootstrapPassword` | " " | `string` - Set the [bootstrap password](#bootstrap-password) for the first admin user. After logging in, the admin will need to reset their password. A randomly generated bootstrap password is used if this value is not set.
|
||||
| `bootstrapPassword` | " " | `string` - Set the [bootstrap password](#bootstrap-password) for the first admin user. After logging in, the admin should reset their password. A randomly generated bootstrap password is used if this value is not set.
|
||||
| `hostname` | " " | `string` - the Fully Qualified Domain Name for your Rancher Server |
|
||||
| `ingress.tls.source` | "rancher" | `string` - Where to get the cert for the ingress. - "rancher, letsEncrypt, secret" |
|
||||
| `letsEncrypt.email` | " " | `string` - Your email address |
|
||||
@@ -67,19 +67,9 @@ For information on enabling experimental features, refer to [this page.](../../.
|
||||
|
||||
### Bootstrap Password
|
||||
|
||||
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.
|
||||
You can [set a specific bootstrap password](../resources/bootstrap-password.md) during Rancher installation. If you don't set a specific bootstrap password, Rancher randomly generates a password for the first admin account.
|
||||
|
||||
If you want to use a specific bootstrap password instead of a randomly generated one, provide the password.
|
||||
|
||||
```plain
|
||||
--set bootstrapPassword="rancher"
|
||||
```
|
||||
|
||||
The password, whether provided or generated, will be stored in a Kubernetes secret. After Rancher is installed, the UI will show instructions for how to retrieve the password using kubectl:
|
||||
|
||||
```
|
||||
kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
|
||||
```
|
||||
When you log in for the first time, use the bootstrap password you set to log in. If you did not set a bootstrap password, the Rancher UI shows commands that can be used to [retrieve the bootstrap password](../resources/bootstrap-password.md#retrieving-the-bootstrap-password). Run those commands and log in to the account. After you log in for the first time, you are asked to reset the admin password.
|
||||
|
||||
### API Audit Log
|
||||
|
||||
@@ -163,7 +153,7 @@ 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:
|
||||
The following is an example of setting proxy using the `proxy` chart option:
|
||||
|
||||
```plain
|
||||
--set proxy="http://<proxy_url:proxy_port>/"
|
||||
|
||||
@@ -6,26 +6,63 @@ title: Setting up the Bootstrap Password
|
||||
<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.
|
||||
When you install Rancher, you can set a bootstrap password for the first admin account.
|
||||
|
||||
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.
|
||||
If you choose not to set a bootstrap password, Rancher randomly generates a bootstrap password for the first admin account.
|
||||
|
||||
### Specifying the Bootstrap Password in Helm Installs
|
||||
For details on how to set the bootstrap password, see below.
|
||||
|
||||
For a Helm install, users can specify the bootstrap password variable by configuring it in the Helm chart values with `.Values.bootstrapPassword`.
|
||||
## Password Requirements
|
||||
|
||||
The password will be stored in a Kubernetes secret. After Rancher is installed, the UI will show instructions for how to retrieve the password using kubectl:
|
||||
The bootstrap password can be any length.
|
||||
|
||||
When you reset the first admin account's password after first login, the new password must be at least 12 characters long.
|
||||
|
||||
You can [customize the minimum password length](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups.md#minimum-password-length) for user accounts, within limitations.
|
||||
|
||||
Minimum password length can be any positive integer value between 2 and 256. Decimal values and leading zeroes are not allowed.
|
||||
|
||||
## Specifying the Bootstrap Password
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Helm">
|
||||
|
||||
During [Rancher installation](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md), set `bootstrapPassword` alongside any other flags for the Rancher Helm chart. For example:
|
||||
|
||||
```bash
|
||||
helm install rancher rancher-<chart-repo>/rancher \
|
||||
--set bootstrapPassword=<password>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Docker">
|
||||
|
||||
Pass the following value to the [Docker install command](../other-installation-methods/air-gapped-helm-cli-install/docker-install-commands.md):
|
||||
|
||||
```bash
|
||||
-e CATTLE_BOOTSTRAP_PASSWORD=<password>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Retrieving the Bootstrap Password
|
||||
|
||||
The bootstrap password is stored in the Docker container logs. After Rancher is installed, the UI shows instructions for how to retrieve the password based on your installation method.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Helm">
|
||||
|
||||
```bash
|
||||
kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
|
||||
```
|
||||
|
||||
### Specifying the Bootstrap Password in Docker Installs
|
||||
|
||||
For a Docker install, you can specify the bootstrap password by passing `-e CATTLE_BOOTSTRAP_PASSWORD=password` to the Docker install command.
|
||||
|
||||
The password will be stored in the Docker container logs. After Rancher is installed, the UI will show instructions for how to retrieve the password using the Docker container ID:
|
||||
</TabItem>
|
||||
<TabItem value="Docker">
|
||||
|
||||
```bash
|
||||
docker logs container-id 2>&1 | grep "Bootstrap Password:"
|
||||
```
|
||||
docker logs container-id 2>&1 | grep "Bootstrap Password:"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
+2
-2
@@ -180,7 +180,7 @@ Repeat the below steps for each downstream cluster:
|
||||
|
||||
### 5. Force Update Fleet clusters to reconnect the fleet-agent to Rancher
|
||||
|
||||
Select 'Force Update' for the clusters within the [Continuous Delivery](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.
|
||||
Select 'Force Update' for the clusters within the [Continuous Delivery](../../../integrations-in-rancher/fleet/overview.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.
|
||||
|
||||
#### Why is this step required?
|
||||
|
||||
@@ -260,7 +260,7 @@ As a private CA is no longer being used, the `CATTLE_CA_CHECKSUM` environment va
|
||||
|
||||
### 5. Force Update Fleet clusters to reconnect the fleet-agent to Rancher
|
||||
|
||||
Select 'Force Update' for the clusters within the [Continuous Delivery](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.
|
||||
Select 'Force Update' for the clusters within the [Continuous Delivery](../../../integrations-in-rancher/fleet/overview.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.
|
||||
|
||||
#### Why is this step required?
|
||||
|
||||
|
||||
@@ -57,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 (minimum 12 characters)
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
|
||||
|
||||
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:
|
||||
|
||||
@@ -43,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 (minimum 12 characters)
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
|
||||
|
||||
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:
|
||||
|
||||
@@ -38,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 (minimum 12 characters)
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
|
||||
|
||||
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:
|
||||
|
||||
@@ -39,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 (minimum 12 characters)
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
|
||||
|
||||
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.
|
||||
|
||||
@@ -130,7 +130,7 @@ To install a specific Rancher version, use the `--version` flag (e.g., `--versio
|
||||
|
||||
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.
|
||||
See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
|
||||
|
||||
```
|
||||
helm install rancher rancher-latest/rancher \
|
||||
|
||||
@@ -38,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 (minimum 12 characters)
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
|
||||
|
||||
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.
|
||||
|
||||
@@ -38,7 +38,7 @@ Deploying to Linode will incur charges.
|
||||
|
||||
4. Edit `terraform.tfvars` and customize the following variables:
|
||||
- `linode_token` - The Linode Personal Access Token mentioned above.
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server (minimum 12 characters).
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
|
||||
|
||||
5. **Optional:** Modify optional variables within `terraform.tfvars`.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Linode Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/linode) for more information. Suggestions include:
|
||||
|
||||
@@ -39,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 (minimum 12 characters)
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server. See [Setting up the Bootstrap Password](../../installation-and-upgrade/resources/bootstrap-password.md#password-requirements) for password requirments.
|
||||
|
||||
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.
|
||||
|
||||
@@ -6,6 +6,6 @@ title: Rancher Prime
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/prime"/>
|
||||
</head>
|
||||
|
||||
Rancher v2.7 introduces Rancher Prime, an evolution of the Rancher enterprise offering. Rancher Prime is a new edition of the commercial, enterprise offering built on the the same source code. Rancher’s product will therefore continue to be 100% open source with additional value coming in from security assurances, extended lifecycles, access to focused architectures and Kubernetes advisories. Rancher Prime will also offer options to get production support for innovative Rancher projects. With Rancher Prime, installation assets are hosted on a trusted registry owned and managed by Rancher.
|
||||
SUSE Rancher introduces Rancher Prime – an evolution of Rancher – from version v2.7. Rancher Prime is the new commercially available enterprise offering of Rancher, built on the same open source code. The Rancher project will continue to be 100% open source. Prime introduces additional value with greater security assurances, extended lifecycles, access to focused architectures and Kubernetes advisories. Rancher Prime will also offer options to get production support for innovative Rancher projects. With Rancher Prime, installation assets are hosted on a trusted registry owned and managed by Rancher.
|
||||
|
||||
To get started with Rancher Prime, [go to this page](https://www.rancher.com/quick-start) and fill out the form.
|
||||
|
||||
+1
-1
@@ -6,7 +6,7 @@ title: Continuous Delivery
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery"/>
|
||||
</head>
|
||||
|
||||
[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.
|
||||
[Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) comes preinstalled in Rancher and 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.](enable-experimental-features.md)
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Setup Guide
|
||||
title: Istio Setup Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Configuration
|
||||
title: Monitoring Configuration Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+23
-9
@@ -6,11 +6,11 @@ title: Node Drivers
|
||||
<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.
|
||||
A node driver is the same as a [Docker Machine driver](https://docs.docker.com/machine/drivers/). Node drivers are used to provision hosts, which Rancher uses to launch and manage Kubernetes clusters. By default, Rancher is packaged with many node drivers, but you can also create and add custom node drivers 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.
|
||||
Only `Active` node drivers are displayed in the Rancher UI when you create node templates. If there are specific node drivers that you don't want to show your users, you must deactivate these node drivers.
|
||||
|
||||
#### Managing Node Drivers
|
||||
## Managing Node Drivers
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
@@ -21,17 +21,31 @@ To create, edit, or delete drivers, you need _one_ of the following permissions:
|
||||
|
||||
:::
|
||||
|
||||
## Activating/Deactivating Node Drivers
|
||||
### Activating/Deactivating Node Drivers
|
||||
|
||||
By default, Rancher only activates drivers for the most popular cloud providers, Amazon EC2, Azure, DigitalOcean, Linode and vSphere. If you want to show or hide any node driver, you can change its status.
|
||||
By default, Rancher only activates drivers for the most popular cloud providers, such as Amazon EC2, Azure, DigitalOcean, Linode and vSphere. If you want to show or hide any node driver, you can change its status.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. In the left navigation menu, click **Drivers**.
|
||||
1. On the **Node Drivers** tab, select the driver that you wish to activate or deactivate and click **⋮ > Activate** or **⋮ > Deactivate**.
|
||||
|
||||
2. In the left navigation menu, click **Drivers**.
|
||||
:::danger
|
||||
|
||||
2. On the **Node Drivers** tab, select the driver that you wish to activate or deactivate and click **⋮ > Activate** or **⋮ > Deactivate**.
|
||||
You can lose access to clusters after deactivating a node driver.
|
||||
|
||||
## Adding Custom Node Drivers
|
||||
Deactivating a node driver doesn't just affect its visibility in the Rancher UI. When you deactivate or delete a node driver, any nodes deployed with that driver become inaccessible.
|
||||
|
||||
For example, if you deactivate a vSphere node driver to hide it in the UI, and you have a vSphere cluster that was deployed with that driver, the initial node in the cluster will fail, and the entire cluster will become inaccessible. Attempts to delete the vSphere nodes will fail, with nodes stuck in an extended `Removing` state.
|
||||
|
||||
Before you deactivate a node driver, make sure that it has no associated clusters. One way to check is to see if the respective platform for a driver is listed among your clusters:
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Select **Clusters**.
|
||||
1. Check the **Provider** column of the table for instances of the node driver you are deactivating.
|
||||
|
||||
:::
|
||||
|
||||
### Adding Custom Node Drivers
|
||||
|
||||
If you want to use a node driver that Rancher doesn't support out-of-the-box, you can add that provider's driver in order to start using them to create node templates and eventually node pools for your Kubernetes cluster.
|
||||
|
||||
@@ -40,6 +54,6 @@ If you want to use a node driver that Rancher doesn't support out-of-the-box, yo
|
||||
1. On **Node Drivers** tab, click **Add Node Driver**.
|
||||
1. Complete the **Add Node Driver** form. Then click **Create**.
|
||||
|
||||
### Developing your own node driver
|
||||
### Developing Your Own Node Drivers
|
||||
|
||||
Node drivers are implemented with [Docker Machine](https://docs.docker.com/machine/).
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: RKE Templates
|
||||
title: About RKE1 Templates
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
-1
@@ -25,7 +25,6 @@ This section focuses on how to use Terraform with the [Rancher 2 Terraform provi
|
||||
Terraform allows you to:
|
||||
|
||||
- Define almost any kind of infrastructure-as-code, including servers, databases, load balancers, monitoring, firewall settings, and SSL certificates
|
||||
- Leverage catalog apps and multi-cluster apps
|
||||
- Codify infrastructure across many platforms, including Rancher and major cloud providers
|
||||
- Commit infrastructure-as-code to version control
|
||||
- Easily repeat configuration and setup of infrastructure
|
||||
|
||||
+1
-1
@@ -42,7 +42,7 @@ In most cases, you should use an external authentication service over local auth
|
||||
|
||||
## Users and Groups
|
||||
|
||||
Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, multi-cluster apps, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
|
||||
Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
|
||||
|
||||
:::note
|
||||
|
||||
|
||||
+9
-1
@@ -8,7 +8,7 @@ title: Users and Groups
|
||||
|
||||
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](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
|
||||
Access to clusters, projects, 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](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
|
||||
|
||||
## Managing Members
|
||||
|
||||
@@ -70,6 +70,14 @@ Since SAML does not support user lookup, SAML-based authentication providers do
|
||||
|
||||
:::
|
||||
|
||||
## Minimum Password Length
|
||||
|
||||
By default, user passwords must be at least 12 characters long. However, you can customize the password length requirement:
|
||||
|
||||
1. In the upper left corner, click **☰ > Global Settings**.
|
||||
1. Go to **`password-min-length`** and click **⋮ > Edit Setting**.
|
||||
1. Enter an integer value between 2 and 256, and click **Save**.
|
||||
|
||||
## Session Length
|
||||
|
||||
The default length (TTL) of each user session is adjustable. The default session length is 16 hours.
|
||||
|
||||
+1
-1
@@ -40,7 +40,7 @@ Backups are created as .tar.gz files. These files can be pushed to S3 or Minio,
|
||||
|
||||
:::note
|
||||
|
||||
There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here](../deploy-apps-across-clusters/fleet.md#troubleshooting) for a workaround.
|
||||
There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here](../../../integrations-in-rancher/fleet/overview.md#troubleshooting) for a workaround.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Backups and Disaster Recovery
|
||||
title: Backup, Restore, and Disaster Recovery
|
||||
keywords: [rancher backup restore, rancher backup and restore, backup restore rancher, rancher backup and restore rancher]
|
||||
---
|
||||
|
||||
|
||||
+9
-5
@@ -8,14 +8,13 @@ title: Migrating Rancher to a New Cluster
|
||||
|
||||
If you are migrating Rancher to a new Kubernetes cluster, you don't need to install Rancher on the new cluster first. If Rancher is restored to a new cluster with Rancher already installed, it can cause problems.
|
||||
|
||||
|
||||
### Prerequisites
|
||||
|
||||
These instructions assume that you have [created a backup](back-up-rancher.md) and already installed a new Kubernetes cluster where Rancher will be deployed. The backup is specific to the Rancher application and can only migrate the Rancher application.
|
||||
|
||||
:::caution
|
||||
|
||||
It is required to use the same hostname that was set as the server URL in the first cluster. If not done, downstream clusters will show as unavailable in the cluster management page of the UI, and you won't be able to click inside the cluster or on the cluster's <b>Explore</b> button.
|
||||
You must use the same hostname that was set as the server URL in the original cluster. If you don't, downstream clusters will show as unavailable in the cluster management page of the UI, and you won't be able to click inside the cluster or on the cluster's **Explore** button.
|
||||
|
||||
:::
|
||||
|
||||
@@ -25,7 +24,6 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes
|
||||
|
||||
Since Rancher can be installed on any Kubernetes cluster, you can use this backup and restore method to migrate Rancher from one Kubernetes cluster to any other Kubernetes cluster. This method *only* migrates Rancher-related resources and won't affect other applications on the cluster. Refer to the [support matrix](https://www.suse.com/lifecycle/) to identify which Kubernetes cluster types and versions are supported for your Rancher version.
|
||||
|
||||
|
||||
### 1. Install the rancher-backup Helm chart
|
||||
|
||||
Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-operator/tags):
|
||||
@@ -54,10 +52,10 @@ Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-o
|
||||
|
||||
The above assumes an environment with outbound connectivity to Docker Hub.
|
||||
|
||||
For an **air-gapped environment**, use the Helm value below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup Helm chart.
|
||||
For an **air-gapped environment**, use the following Helm value to pull the `backup-restore-operator` image from your private registry when you install the rancher-backup Helm chart.
|
||||
|
||||
```bash
|
||||
--set image.repository $REGISTRY/rancher/backup-restore-operator
|
||||
--set image.repository <registry>/rancher/backup-restore-operator
|
||||
```
|
||||
|
||||
:::
|
||||
@@ -189,3 +187,9 @@ helm install rancher rancher-latest/rancher -n cattle-system -f rancher-values.y
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### 5. Redirect Traffic to the New Cluster
|
||||
|
||||
After migration completes, update your DNS records and any load balancers, so that traffic is routed correctly to the migrated cluster. Remember that you must use the same hostname that was set as the server URL in the original cluster.
|
||||
|
||||
Full instructions on how to redirect traffic to the migrated cluster differ based on your specific environment. Refer to your hosting provider's documentation for more details.
|
||||
|
||||
-21
@@ -1,21 +0,0 @@
|
||||
---
|
||||
title: Deploying Applications across Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters"/>
|
||||
</head>
|
||||
|
||||
Rancher offers several ways to deploy applications across clusters, depending on version.
|
||||
|
||||
## Fleet
|
||||
|
||||
Rancher v2.5 and later uses Fleet to deploy applications across clusters.
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. For more information, refer to the [Fleet section](fleet.md).
|
||||
|
||||
## Multi-cluster Apps
|
||||
|
||||
In Rancher before v2.5, the multi-cluster apps feature was used to deploy applications across clusters. The multi-cluster apps feature is deprecated, but still available as a legacy feature.
|
||||
|
||||
See the [multi-cluster app documentation](multi-cluster-apps.md) for more details.
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
title: Continuous Delivery with Fleet
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet"/>
|
||||
</head>
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It's also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale.](https://fleet.rancher.io/installation#configuration-for-multi-cluster) By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
|
||||
|
||||
Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
|
||||
|
||||
|
||||
## Architecture
|
||||
|
||||
For information about how Fleet works, see [this page.](../../../integrations-in-rancher/fleet/architecture.md)
|
||||
|
||||
## Accessing Fleet in the Rancher UI
|
||||
|
||||
Fleet comes preinstalled in Rancher and is managed by the **Continous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).
|
||||
|
||||
Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice.
|
||||
|
||||
Follow the steps below to access Continuous Delivery in the Rancher UI:
|
||||
|
||||
1. Click **☰ > Continuous Delivery**.
|
||||
|
||||
1. Select your namespace at the top of the menu, noting the following:
|
||||
- By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
|
||||
- You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
|
||||
- You can then manage clusters by clicking on **Clusters** on the left navigation bar.
|
||||
|
||||
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
|
||||
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
|
||||
1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.
|
||||
|
||||
## Windows Support
|
||||
|
||||
For details on support for clusters with Windows nodes, see [this page.](../../../integrations-in-rancher/fleet/windows-support.md)
|
||||
|
||||
|
||||
## GitHub Repository
|
||||
|
||||
The Fleet Helm charts are available [here.](https://github.com/rancher/fleet/releases/latest)
|
||||
|
||||
|
||||
## Using Fleet Behind a Proxy
|
||||
|
||||
For details on using Fleet behind a proxy, see [this page.](../../../integrations-in-rancher/fleet/use-fleet-behind-a-proxy.md)
|
||||
|
||||
## Helm Chart Dependencies
|
||||
|
||||
In order for Helm charts with dependencies to deploy successfully, you must run a manual command (as listed below), as it is up to the user to fulfill the dependency list. If you do not do this and proceed to clone your repository and run `helm install`, your installation will fail because the dependencies will be missing.
|
||||
|
||||
The Helm chart in the git repository must include its dependencies in the charts subdirectory. You must either manually run `helm dependencies update $chart` or run `helm dependencies build $chart` locally, then commit the complete charts directory to your git repository. Note that you will update your commands with the applicable parameters.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
---
|
||||
* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator](../backup-restore-and-disaster-recovery/back-up-rancher.md#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place.
|
||||
|
||||
* **Temporary Workaround:** <br/>
|
||||
By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow).
|
||||
|
||||
---
|
||||
|
||||
## Documentation
|
||||
|
||||
The Fleet documentation is at [https://fleet.rancher.io/.](https://fleet.rancher.io/)
|
||||
@@ -1,179 +0,0 @@
|
||||
---
|
||||
title: Multi-cluster Apps
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps"/>
|
||||
</head>
|
||||
|
||||
Typically, most applications are deployed on a single Kubernetes cluster, but there will be times you might want to deploy multiple copies of the same application across different clusters and/or projects. In Rancher, a _multi-cluster application_, is an application deployed using a Helm chart across multiple clusters. With the ability to deploy the same application across multiple clusters, it avoids the repetition of the same action on each cluster, which could introduce user error during application configuration. With multi-cluster applications, you can customize to have the same configuration across all projects/clusters as well as have the ability to change the configuration based on your target project. Since multi-cluster application is considered a single application, it's easy to manage and maintain this application.
|
||||
|
||||
Any Helm charts from a global catalog can be used to deploy and manage multi-cluster applications.
|
||||
|
||||
After creating a multi-cluster application, you can program a global DNS entry to make it easier to access the application.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### Permissions
|
||||
|
||||
To create a multi-cluster app in Rancher, you must have at least one of the following permissions:
|
||||
|
||||
- A [project-member role](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) in the target cluster(s), which gives you the ability to create, read, update, and delete the workloads
|
||||
- A [cluster owner role](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles) for the clusters(s) that include the target project(s)
|
||||
|
||||
### Enable Legacy Features
|
||||
|
||||
Because multi-cluster apps were deprecated and replaced with Fleet in Rancher v2.5, you will need to enable multi-cluster apps with a feature flag.
|
||||
|
||||
1. In the upper left corner, click **☰ > Global Settings**.
|
||||
1. Click **Feature Flags**.
|
||||
1. Go to the `legacy` feature flag and click **Activate**.
|
||||
|
||||
## Launching a Multi-Cluster App
|
||||
|
||||
1. In the upper left corner, click **☰ > Multi-cluster Apps**.
|
||||
1. Click **Launch**.
|
||||
1. Find the application that you want to launch.
|
||||
1. (Optional) Review the detailed descriptions, which are derived from the Helm chart's `README`.
|
||||
1. Under **Configuration Options** enter a **Name** for the multi-cluster application. By default, this name is also used to create a Kubernetes namespace in each [target project](#targets) for the multi-cluster application. The namespace is named as `<MULTI-CLUSTER_APPLICATION_NAME>-<PROJECT_ID>`.
|
||||
1. Select a **Template Version**.
|
||||
1. Complete the [multi-cluster applications specific configuration options](#multi-cluster-app-configuration-options) as well as the [application configuration options](#application-configuration-options).
|
||||
1. Select the **Members** who can [interact with the multi-cluster application](#members).
|
||||
1. Add any [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects) that would change the configuration for specific project(s) from the default application configuration answers.
|
||||
1. Review the files in the **Preview** section. When you're satisfied, click **Launch**.
|
||||
|
||||
**Result**: Your application is deployed to your chosen namespace. You can view the application status from the project's:
|
||||
|
||||
## Multi-cluster App Configuration Options
|
||||
|
||||
Rancher has divided the configuration option for the multi-cluster application into several sections.
|
||||
|
||||
### Targets
|
||||
|
||||
In the **Targets** section, select the projects that you want the application to be deployed in. The list of projects is based on what projects you have access to. For each project that you select, it will be added to the list, which shows the cluster name and project name that were selected. To remove a target project, click on **-**.
|
||||
|
||||
### Upgrades
|
||||
|
||||
In the **Upgrades** section, select the upgrade strategy to use, when you decide to upgrade your application.
|
||||
|
||||
* **Rolling Update (batched):** When selecting this upgrade strategy, the number of applications upgraded at a time is based on the selected **Batch size** and the **Interval** specifies how many seconds to wait before starting the next batch of updates.
|
||||
|
||||
* **Upgrade all apps simultaneously:** When selecting this upgrade strategy, all applications across all projects will be upgraded at the same time.
|
||||
|
||||
### Roles
|
||||
|
||||
In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications](../helm-charts-in-rancher/helm-charts-in-rancher.md), that specific user's permissions are used for creation of all workloads/resources that is required by the app.
|
||||
|
||||
For multi-cluster applications, the application is deployed by a _system user_ and is assigned as the creator of all underlying resources. A _system user_ is used instead of the actual user due to the fact that the actual user could be removed from one of the target projects. If the actual user was removed from one of the projects, then that user would no longer be able to manage the application for the other projects.
|
||||
|
||||
Rancher will let you select from two options for Roles, **Project** and **Cluster**. Rancher will allow creation using any of these roles based on the user's permissions.
|
||||
|
||||
- **Project** - This is the equivalent of a [project member](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [project member](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) role. While the user might not be explicitly granted the _project member_ role, if the user is an [administrator](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md), a [cluster owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), or a [project owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles), then the user is considered to have the appropriate level of permissions.
|
||||
|
||||
- **Cluster** - This is the equivalent of a [cluster owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [cluster owner](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) role. While the user might not be explicitly granted the _cluster owner_ role, if the user is an [administrator](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md), then the user is considered to have the appropriate level of permissions.
|
||||
|
||||
When launching the application, Rancher will confirm if you have these permissions in the target projects before launching the application.
|
||||
|
||||
:::note
|
||||
|
||||
There are some applications like _Grafana_ or _Datadog_ that require access to specific cluster-scoped resources. These applications will require the _Cluster_ role. If you find out later that the application requires cluster roles, the multi-cluster application can be upgraded to update the roles.
|
||||
|
||||
:::
|
||||
|
||||
## Application Configuration Options
|
||||
|
||||
For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://helm.sh/docs/intro/using_helm/#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm.
|
||||
|
||||
:::note Example
|
||||
|
||||
When entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is required to wrap the values with double quotes (i.e., ``"abc, bcd"``).
|
||||
|
||||
:::
|
||||
|
||||
### Using a questions.yml file
|
||||
|
||||
If the Helm chart that you are deploying contains a `questions.yml` file, Rancher's UI will translate this file to display an easy to use UI to collect the answers for the questions.
|
||||
|
||||
### Key Value Pairs for Native Helm Charts
|
||||
|
||||
For native Helm charts (i.e., charts from the **Helm Stable** or **Helm Incubator** catalogs or a custom Helm chart repository, answers are provided as key value pairs in the **Answers** section. These answers are used to override the default values.
|
||||
|
||||
### Members
|
||||
|
||||
By default, multi-cluster applications can only be managed by the user who created it. In the **Members** section, other users can be added so that they can also help manage or view the multi-cluster application.
|
||||
|
||||
1. Find the user that you want to add by typing in the member's name in the **Member** search box.
|
||||
|
||||
2. Select the **Access Type** for that member. There are three access types for a multi-cluster project, but due to how the permissions of a multi-cluster application are launched, please read carefully to understand what these access types mean.
|
||||
|
||||
- **Owner**: This access type can manage any configuration part of the multi-cluster application including the template version, the [multi-cluster applications specific configuration options](#Multi-cluster App Configuration Options), the [application specific configuration options](#application-configuration-options), the members who can interact with the multi-cluster application and the [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects). Since a multi-cluster application is created with a different set of permissions from the user, any _owner_ of the multi-cluster application can manage/remove applications in [target projects](#targets) without explicitly having access to these project(s). Only trusted users should be provided with this access type.
|
||||
|
||||
- **Member**: This access type can only modify the template version, the [application specific configuration options](#application-configuration-options) and the [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects). Since a multi-cluster application is created with a different set of permissions from the user, any _member_ of the multi-cluster application can modify the application without explicitly having access to these project(s). Only trusted users should be provided with this access type.
|
||||
|
||||
- **Read-only**: This access type cannot modify any configuration option for the multi-cluster application. Users can only view these applications.
|
||||
|
||||
:::caution
|
||||
|
||||
Please ensure only trusted users are given _Owner_ or _Member_ access as they will automatically be able to manage applications created for this multi-cluster application in target projects they might not have direct access to.
|
||||
|
||||
:::
|
||||
|
||||
### Overriding Application Configuration Options for Specific Projects
|
||||
|
||||
The ability to use the same configuration to deploy the same application across multiple clusters/projects is one of the main benefits of multi-cluster applications. There might be a specific project that requires a slightly different configuration option, but you want to manage that application with all the other matching applications. Instead of creating a brand new application, you can override specific [application specific configuration options](#application-configuration-options) for specific projects.
|
||||
|
||||
1. In the **Answer Overrides** section, click **Add Override**.
|
||||
|
||||
2. For each override, you can select the following:
|
||||
|
||||
- **Scope**: Select which target projects you want to override the answer in the configuration option.
|
||||
|
||||
- **Question**: Select which question you want to override.
|
||||
|
||||
- **Answer**: Enter the answer that you want to be used instead.
|
||||
|
||||
## Upgrading Multi-Cluster App Roles and Projects
|
||||
|
||||
- **Changing Roles on an existing Multi-Cluster app**
|
||||
The creator and any users added with the access-type "owner" to a multi-cluster app, can upgrade its Roles. When adding a new Role, we check if the user has that exact role in all current target projects. These checks allow the same relaxations for global admins, cluster owners and project-owners as described in the installation section for the field `Roles`.
|
||||
|
||||
- **Adding/Removing target projects**
|
||||
1. The creator and any users added with access-type "owner" to a multi-cluster app, can add or remove its target projects. When adding a new project, we check if the caller of this request has all Roles defined on multi-cluster app, in the new projects they want to add. The roles checks are again relaxed for global admins, cluster-owners and project-owners.
|
||||
2. We do not do these membership checks when removing target projects. This is because the caller's permissions could have with respect to the target project, or the project could have been deleted and hence the caller wants to remove it from targets list.
|
||||
|
||||
|
||||
## Multi-Cluster Application Management
|
||||
|
||||
One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of management. Multi-cluster applications can be cloned, upgraded or rolled back.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
The `legacy` feature flag needs to be enabled.
|
||||
|
||||
:::
|
||||
|
||||
1. In the upper left corner, click **☰ > Multi-cluster Apps**.
|
||||
|
||||
2. Choose the multi-cluster application you want to take one of these actions on and click the **⋮**. Select one of the following options:
|
||||
|
||||
* **Clone**: Creates another multi-cluster application with the same configuration. By using this option, you can easily duplicate a multi-cluster application.
|
||||
* **Upgrade**: Upgrade your multi-cluster application to change some part of the configuration. When performing an upgrade for multi-cluster application, the [upgrade strategy](#upgrades) can be modified if you have the correct [access type](#members).
|
||||
* **Rollback**: Rollback your application to a specific version. If after an upgrade, there are issues for your multi-cluster application for one or more of your [targets](#targets), Rancher has stored up to 10 versions of the multi-cluster application. Rolling back a multi-cluster application reverts the application for **all** target clusters and projects, not just the targets(s) affected by the upgrade issue.
|
||||
|
||||
## Deleting a Multi-Cluster Application
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
The `legacy` feature flag needs to be enabled.
|
||||
|
||||
:::
|
||||
|
||||
1. In the upper left corner, click **☰ > Multi-cluster Apps**.
|
||||
|
||||
2. Choose the multi-cluster application you want to delete and click the **⋮ > Delete**. When deleting the multi-cluster application, all applications and namespaces are deleted in all of the target projects.
|
||||
|
||||
:::note
|
||||
|
||||
The applications in the target projects, that are created for a multi-cluster application, cannot be deleted individually. The applications can only be deleted when the multi-cluster application is deleted.
|
||||
|
||||
:::
|
||||
@@ -1,12 +1,13 @@
|
||||
---
|
||||
title: Don't have infrastructure for your Kubernetes cluster? Try one of these tutorials.
|
||||
title: Infrastructure Setup
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/infrastructure-setup"/>
|
||||
</head>
|
||||
|
||||
To set up infrastructure for a high-availability K3s Kubernetes cluster with an external DB, refer to [this page.](ha-k3s-kubernetes-cluster.md)
|
||||
Don't have infrastructure for your Kubernetes cluster? Try one of these tutorials.
|
||||
|
||||
To set up infrastructure for a high-availability K3s Kubernetes cluster with an external database, refer to [this page.](ha-k3s-kubernetes-cluster.md)
|
||||
|
||||
To set up infrastructure for a high-availability RKE Kubernetes cluster, refer to [this page.](ha-rke1-kubernetes-cluster.md)
|
||||
|
||||
+3
-1
@@ -1,11 +1,13 @@
|
||||
---
|
||||
title: "Don't have a Kubernetes cluster? Try one of these tutorials."
|
||||
title: Setting up a Kubernetes Cluster for Rancher Server
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-cluster-setup"/>
|
||||
</head>
|
||||
|
||||
Don't have a Kubernetes cluster? Try one of these tutorials.
|
||||
|
||||
This section contains information on how to install a Kubernetes cluster that the Rancher server can be installed on.
|
||||
|
||||
Rancher can run on any Kubernetes cluster.
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Setting up Kubernetes Clusters in Rancher
|
||||
title: Kubernetes Clusters in Rancher Setup
|
||||
description: Provisioning Kubernetes Clusters
|
||||
---
|
||||
|
||||
|
||||
+2
-2
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: Migrating vSphere In-tree to Out-of-tree
|
||||
title: Migrating VMware vSphere In-tree to Out-of-tree
|
||||
---
|
||||
|
||||
<head>
|
||||
<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-vsphere"/>
|
||||
</head>
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. VMware vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
|
||||
This page covers how to migrate from the in-tree vSphere cloud provider to out-of-tree, and manage the existing VMs post migration.
|
||||
|
||||
|
||||
+2
-2
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: Setting Up an In-tree vSphere Cloud Provider
|
||||
title: Setting Up an In-tree VMware vSphere Cloud Provider
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere"/>
|
||||
</head>
|
||||
|
||||
To set up the in-tree vSphere cloud provider, follow these steps while creating the vSphere cluster in Rancher:
|
||||
To set up the in-tree VMware vSphere cloud provider, follow these steps while creating the vSphere cluster in Rancher:
|
||||
|
||||
1. Set **Cloud Provider** option to `Custom` or `Custom (In-Tree)`.
|
||||
1. Click on **Edit as YAML**
|
||||
|
||||
+3
-3
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: Setting Up an Out-of-tree vSphere Cloud Provider
|
||||
title: Setting Up an Out-of-tree VMware vSphere Cloud Provider
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere"/>
|
||||
</head>
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. VMware vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
|
||||
This page covers how to install the Cloud Provider Interface (CPI) and Cloud Storage Interface (CSI) plugins after setting up a cluster.
|
||||
|
||||
@@ -25,7 +25,7 @@ Using the vSphere out-of-tree cloud provider requires Linux nodes and is not sup
|
||||
|
||||
The Cloud Provider Interface (CPI) should be installed first before installing the Cloud Storage Interface (CSI).
|
||||
|
||||
### 1. Create a vSphere cluster
|
||||
### 1. Create a VMware vSphere cluster
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
|
||||
+1
-1
@@ -33,7 +33,7 @@ For details on enabling the Azure cloud provider, refer to [this page.](azure.md
|
||||
|
||||
For details on enabling the Google Compute Engine cloud provider, refer to [this page.](google-compute-engine.md)
|
||||
|
||||
### Setting up the vSphere Cloud Provider
|
||||
### Setting up the VMware vSphere Cloud Provider
|
||||
|
||||
For details on enabling the vSphere cloud provider, refer to [in-tree vSphere config](configure-in-tree-vsphere.md) and [out-of-tree vSphere config](configure-out-of-tree-vsphere.md).
|
||||
|
||||
|
||||
+1
-1
@@ -86,7 +86,7 @@ Some Linux operating systems accept multiple domain names separated by spaces. H
|
||||
|
||||
:::
|
||||
|
||||
### Rancher on vSphere with ESXi 6.7u2 and above
|
||||
### Rancher on VMware vSphere with ESXi 6.7u2 and above
|
||||
|
||||
If you are using Rancher on VMware vSphere with ESXi 6.7u2 or later with Red Hat Enterprise Linux 8.3, CentOS 8.3, or SUSE Enterprise Linux 15 SP2 or later, it is necessary to disable the `vmxnet3` virtual network adapter hardware offloading feature. Failure to do so will result in all network connections between pods on different cluster nodes to fail with timeout errors. All connections from Windows pods to critical services running on Linux nodes, such as CoreDNS, will fail as well. It is also possible that external connections may fail. This issue is the result of Linux distributions enabling the hardware offloading feature in `vmxnet3` and a bug in the `vmxnet3` hardware offloading feature that results in the discarding of packets for guest overlay traffic. To address this issue, it is necessary disable the `vmxnet3` hardware offloading feature. This setting does not survive reboot, so it is necessary to disable on every boot. The recommended course of action is to create a systemd unit file at `/etc/systemd/system/disable_hw_offloading.service`, which disables the `vmxnet3` hardware offloading feature on boot. A sample systemd unit file which disables the `vmxnet3` hardware offloading feature is as follows. Note that `<VM network interface>` must be customized to the host `vmxnet3` network interface, e.g., `ens192`:
|
||||
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: The Horizontal Pod Autoscaler
|
||||
title: Horizontal Pod Autoscaler
|
||||
description: Learn about the horizontal pod autoscaler (HPA). How to manage HPAs and how to test them with a service deployment
|
||||
---
|
||||
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Kubernetes Resources
|
||||
title: Kubernetes Resources Setup
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Set Up Load Balancer and Ingress Controller within Rancher
|
||||
title: Load Balancer and Ingress Controller Setup within Rancher
|
||||
description: Learn how you can set up load balancers and ingress controllers to redirect service requests within Rancher, and learn about the limitations of load balancers
|
||||
---
|
||||
|
||||
|
||||
+53
-2
@@ -21,11 +21,62 @@ The `cattle-cluster-agent` is used to connect to the Kubernetes API of [Rancher
|
||||
|
||||
The `cattle-node-agent` is used to interact with nodes in a [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) cluster when performing cluster operations. Examples of cluster operations are upgrading Kubernetes version and creating/restoring etcd snapshots. The `cattle-node-agent` is deployed using a DaemonSet resource to make sure it runs on every node. The `cattle-node-agent` is used as fallback option to connect to the Kubernetes API of [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) clusters when `cattle-cluster-agent` is unavailable.
|
||||
|
||||
### Requests
|
||||
|
||||
The `cattle-cluster-agent` pod does not define the default CPU and memory request values. As a baseline, we recommend setting the CPU request at `50m` and memory request at `100Mi`. However, it is important that you assess your use case appropriately and that you allocate the correct resources to your cluster for your needs.
|
||||
|
||||
To configure request values through the UI:
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
1. When you [create](./launch-kubernetes-with-rancher.md) or edit an existing cluster, go to the **Cluster Options** section.
|
||||
1. Expand the **Cluster Configuration** subsection.
|
||||
1. Configure your request values using the **CPU Requests** and **Memory Requests** fields as needed.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
1. When you [create](./launch-kubernetes-with-rancher.md) or edit an existing cluster, go to the **Cluster Configuration**.
|
||||
1. Select the **Cluster Agent** subsection.
|
||||
1. Configure your request values using the **CPU Reservation** and **Memory Reservation** fields as needed.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
If you prefer to configure via YAML, add the following snippet to your configuration file:
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
```yaml
|
||||
cluster_agent_deployment_customization:
|
||||
override_resource_requirements:
|
||||
requests:
|
||||
cpu: 50m
|
||||
memory: 100Mi
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
clusterAgentDeploymentCustomization:
|
||||
overrideResourceRequirements:
|
||||
requests:
|
||||
cpu: 50m
|
||||
memory: 100Mi
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Scheduling rules
|
||||
|
||||
The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`.
|
||||
The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`.
|
||||
|
||||
If control plane nodes are present in the cluster, the default tolerations will be replaced with tolerations matching the taints on the control plane nodes. The default set of tolerations are described below.
|
||||
If control plane nodes are present in the cluster, the default tolerations will be replaced with tolerations matching the taints on the control plane nodes. The default set of tolerations are described below.
|
||||
|
||||
| Component | nodeAffinity nodeSelectorTerms | nodeSelector | Tolerations |
|
||||
| ---------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Creating a vSphere Virtual Machine Template
|
||||
title: Creating a VMware vSphere Virtual Machine Template
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+2
-2
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: Creating Credentials in the vSphere Console
|
||||
title: Creating Credentials in the VMware vSphere Console
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/create-credentials"/>
|
||||
</head>
|
||||
|
||||
This section describes how to create a vSphere username and password. You will need to provide these vSphere credentials to Rancher, which allows Rancher to provision resources in vSphere.
|
||||
This section describes how to create a VMware vSphere username and password. You must provide these vSphere credentials to Rancher, which allows Rancher to provision resources in vSphere.
|
||||
|
||||
The following table lists the permissions required for the vSphere user account:
|
||||
|
||||
|
||||
+8
-8
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: Provisioning Kubernetes Clusters in vSphere
|
||||
title: Provisioning Kubernetes Clusters in VMware vSphere
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere"/>
|
||||
</head>
|
||||
|
||||
In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in vSphere.
|
||||
In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in VMware vSphere.
|
||||
|
||||
First, you will set up your vSphere cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision nodes in vSphere.
|
||||
|
||||
@@ -17,16 +17,16 @@ For details on configuring the vSphere node template, refer to the [vSphere node
|
||||
For details on configuring RKE Kubernetes clusters in Rancher, refer to the [cluster configuration reference.](../../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-cluster-config-file-reference)
|
||||
|
||||
|
||||
- [Preparation in vSphere](#preparation-in-vsphere)
|
||||
- [Creating a vSphere Cluster](#creating-a-vsphere-cluster)
|
||||
- [Preparation in vSphere](#preparation-in-vmware-vsphere)
|
||||
- [Creating a vSphere Cluster](#creating-a-vmware-vsphere-cluster)
|
||||
|
||||
## Preparation in vSphere
|
||||
## Preparation in VMware vSphere
|
||||
|
||||
This section describes the requirements for setting up vSphere so that Rancher can provision VMs and clusters.
|
||||
|
||||
The node templates are documented and tested with the vSphere Web Services API version 6.5.
|
||||
|
||||
### Create Credentials in vSphere
|
||||
### Create Credentials in VMware vSphere
|
||||
|
||||
Before proceeding to create a cluster, you must ensure that you have a vSphere user with sufficient permissions. When you set up a node template, the template will need to use these vSphere credentials.
|
||||
|
||||
@@ -42,7 +42,7 @@ It must be ensured that the hosts running the Rancher server are able to establi
|
||||
|
||||
See [Node Networking Requirements](../../../kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for a detailed list of port requirements applicable for creating nodes on an infrastructure provider.
|
||||
|
||||
### Valid ESXi License for vSphere API Access
|
||||
### Valid ESXi License for VMware vSphere API Access
|
||||
|
||||
The free ESXi license does not support API access. The vSphere servers must have a valid or evaluation ESXi license.
|
||||
|
||||
@@ -50,7 +50,7 @@ The free ESXi license does not support API access. The vSphere servers must have
|
||||
|
||||
If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate ESXi hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes.
|
||||
|
||||
## Creating a vSphere Cluster
|
||||
## Creating a VMware vSphere Cluster
|
||||
|
||||
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
|
||||
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
|
||||
|
||||
+7
-7
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Creating a vSphere Cluster
|
||||
description: Use Rancher to create a vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
|
||||
title: Creating a VMware vSphere Cluster
|
||||
description: Use Rancher to create a VMware vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
|
||||
---
|
||||
|
||||
<head>
|
||||
@@ -9,13 +9,13 @@ description: Use Rancher to create a vSphere cluster. It may consist of groups o
|
||||
|
||||
import YouTube from '@site/src/components/YouTube'
|
||||
|
||||
By using Rancher with vSphere, you can bring cloud operations on-premises.
|
||||
By using Rancher with VMware vSphere, you can bring cloud operations on-premises.
|
||||
|
||||
Rancher can provision nodes in vSphere and install Kubernetes on them. When creating a Kubernetes cluster in vSphere, Rancher first provisions the specified number of virtual machines by communicating with the vCenter API. Then it installs Kubernetes on top of them.
|
||||
|
||||
A vSphere cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role.
|
||||
|
||||
## vSphere Enhancements in Rancher v2.3
|
||||
## VMware vSphere Enhancements in Rancher v2.3
|
||||
|
||||
The vSphere node templates have been updated, allowing you to bring cloud operations on-premises with the following enhancements:
|
||||
|
||||
@@ -33,7 +33,7 @@ It is not recommended to enable node auto-replace on a node pool of master nodes
|
||||
|
||||
Node templates for vSphere have been updated so that when you create a node template with your vSphere credentials, the template is automatically populated with the same options for provisioning VMs that you have access to in the vSphere console.
|
||||
|
||||
For the fields to be populated, your setup needs to fulfill the [prerequisites.](provision-kubernetes-clusters-in-vsphere.md#preparation-in-vsphere)
|
||||
For the fields to be populated, your setup needs to fulfill the [prerequisites.](provision-kubernetes-clusters-in-vsphere.md#preparation-in-vmware-vsphere)
|
||||
|
||||
### More Supported Operating Systems
|
||||
|
||||
@@ -45,7 +45,7 @@ In this YouTube video, we demonstrate how to set up a node template with the new
|
||||
|
||||
<YouTube id="dPIwg6x1AlU"/>
|
||||
|
||||
## Creating a vSphere Cluster
|
||||
## Creating a VMware vSphere Cluster
|
||||
|
||||
In [this section,](provision-kubernetes-clusters-in-vsphere.md) you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in vSphere.
|
||||
|
||||
@@ -53,7 +53,7 @@ In [this section,](provision-kubernetes-clusters-in-vsphere.md) you'll learn how
|
||||
|
||||
For an example of how to provision storage in vSphere using Rancher, refer to [this section.](../../../manage-clusters/provisioning-storage-examples/vsphere-storage.md) In order to dynamically provision storage in vSphere, the vSphere provider must be enabled. Refer to [in-tree vSphere config](../../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere.md) and [out-of-tree vSphere config](../../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere.md).
|
||||
|
||||
## Enabling the vSphere Cloud Provider
|
||||
## Enabling the VMware vSphere Cloud Provider
|
||||
|
||||
When a cloud provider is set up in Rancher, the Rancher server can automatically provision new infrastructure for the cluster, including new nodes or persistent storage devices.
|
||||
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Cluster Access
|
||||
title: Access Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+2
-2
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Kubernetes Persistent Storage: Volumes and Storage Classes"
|
||||
title: Create Kubernetes Persistent Volumes and Storage Classes
|
||||
description: "Learn about the two ways with which you can create persistent storage in Kubernetes: persistent volumes and storage classes"
|
||||
---
|
||||
|
||||
@@ -67,7 +67,7 @@ In [Rancher Launched Kubernetes clusters](../../launch-kubernetes-with-rancher/l
|
||||
### hostPath Volumes
|
||||
Before you create a hostPath volume, you need to set up an [extra_bind](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/#extra-binds/) in your cluster configuration. This will mount the path as a volume in your kubelets, which can then be used for hostPath volumes in your workloads.
|
||||
|
||||
### Migrating vSphere Cloud Provider from In-tree to Out-of-tree
|
||||
### Migrating VMware vSphere Cloud Provider from In-tree to Out-of-tree
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
|
||||
|
||||
+3
-3
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: vSphere Storage
|
||||
title: VMware vSphere Storage
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/provisioning-storage-examples/vsphere-storage"/>
|
||||
</head>
|
||||
|
||||
To provide stateful workloads with vSphere storage, we recommend creating a vSphereVolume StorageClass. This practice dynamically provisions vSphere storage when workloads request volumes through a PersistentVolumeClaim.
|
||||
To provide stateful workloads with VMware vSphere storage, we recommend creating a vSphereVolume StorageClass. This practice dynamically provisions vSphere storage when workloads request volumes through a PersistentVolumeClaim.
|
||||
|
||||
In order to dynamically provision storage in vSphere, the vSphere provider must be enabled. See the following pages for more: [Out-of-tree vSphere](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere.md) and [in-tree vSphere](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere.md).
|
||||
|
||||
@@ -35,7 +35,7 @@ The following steps can also be performed using the `kubectl` command line tool.
|
||||
5. Optionally, specify additional properties for this storage class under **Parameters**. Refer to the [vSphere storage documentation](https://github.com/vmware-archive/vsphere-storage-for-kubernetes/blob/master/documentation/storageclass.md) for details.
|
||||
5. Click **Create**.
|
||||
|
||||
### Creating a Workload with a vSphere Volume
|
||||
### Creating a Workload with a VMware vSphere Volume
|
||||
|
||||
1. In the left navigation bar, click **Workload**.
|
||||
1. Click **Create**.
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Cluster API (CAPI) with Rancher Turtles
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cluster-api"/>
|
||||
</head>
|
||||
|
||||
[Rancher Turtles](https://turtles.docs.rancher.com/) is a [Rancher extension](../rancher-extensions.md) that manages the lifecycle of provisioned Kubernetes clusters, by providing integration between your Cluster API (CAPI) and Rancher. With Rancher Turtles, you can:
|
||||
|
||||
- Import CAPI clusters into Rancher, by installing the Rancher Cluster Agent in CAPI provisioned clusters.
|
||||
- Configure the [CAPI Operator](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values#cluster-api-operator-values).
|
||||
|
||||
The [Overview](./overview.md) section outlines installation options, Rancher Turtles architecture, and a brief demo. For more details, see the [Rancher Turtles documentation](https://turtles.docs.rancher.com/).
|
||||
@@ -0,0 +1,260 @@
|
||||
---
|
||||
title: Overview
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/cluster-api/overview"/>
|
||||
</head>
|
||||
|
||||
## Architecture Diagram
|
||||
|
||||
Below is a visual representation of the key components of Rancher Turtles and their relationship to Rancher and the Rancher Cluster Agent. Understanding these components is essential for gaining insights into how Rancher leverages the CAPI operator for cluster management.
|
||||
|
||||

|
||||
|
||||
## Security
|
||||
|
||||
As defined by [Supply-chain Levels for Software Artifacts (SLSA)](https://slsa.dev/spec/v1.0/about), SLSA is a set of incrementally adoptable guidelines for supply chain security, established by industry consensus. The specification set by SLSA is useful for both software producers and consumers: producers can follow SLSA’s guidelines to make their software supply chain more secure, and consumers can use SLSA to make decisions about whether to trust a software package.
|
||||
|
||||
Rancher Turtles meets [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3) requirements as an appropriate hardened build platform, with consistent build processes, and provenance distribution. For more information, visit the [Rancher Turtles Security](https://turtles.docs.rancher.com/security/slsa) document.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before installing Rancher Turtles in your Rancher environment, you must disable Rancher's `embedded-cluster-api` functionality. This also includes cleaning up Rancher-specific webhooks that otherwise would conflict with CAPI ones.
|
||||
|
||||
To simplify setting up Rancher for installing Rancher Turtles, the official Rancher Turtles Helm chart includes a `pre-install` hook that removes the following:
|
||||
|
||||
- Disables the `embedded-cluster-api` feature in Rancher.
|
||||
- Deletes the `mutating-webhook-configuration` and `validating-webhook-configuration` webhooks, as they are no longer needed.
|
||||
|
||||
These webhooks can be removed through the Rancher UI as well:
|
||||
|
||||
1. In the upper left corner, click **☰** > **Cluster Management**.
|
||||
1. Select your local cluster.
|
||||
1. In the left-hand navigation menu, select **More Resources** > **Admission**.
|
||||
1. From the dropdown, select the Resource pages for `MutatingWebhookConfiguration` and `ValidatingWebhookConfiguration`.
|
||||
1. On the respective Resource pages, click the **⋮** that are attached to the `mutating-webhook-configuration` and `validating-webhook-configuration` webhooks and select the **Delete** option.
|
||||
|
||||
The webhooks can also be accessed by entering the names of the webhooks into the **Resource Search** field.
|
||||
|
||||
The following `kubectl` commands can manually remove the necessary webhooks:
|
||||
|
||||
```console
|
||||
kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io mutating-webhook-configuration
|
||||
```
|
||||
|
||||
```console
|
||||
kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io validating-webhook-configuration
|
||||
```
|
||||
|
||||
Use the following example to disable the `embedded-cluster-api` feature from the console:
|
||||
|
||||
1. Create a `feature.yaml` file, with `embedded-cluster-api` set to false:
|
||||
|
||||
```yaml title="feature.yaml"
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: Feature
|
||||
metadata:
|
||||
name: embedded-cluster-api
|
||||
spec:
|
||||
value: false
|
||||
```
|
||||
|
||||
2. Use `kubectl` to apply the `feature.yaml` file to the cluster:
|
||||
|
||||
```bash
|
||||
kubectl apply -f feature.yaml
|
||||
```
|
||||
|
||||
## Installing the Rancher Turtles Operator
|
||||
|
||||
You can install the Rancher Turtles operator via the Rancher UI, or with Helm. The first method is recommended for most environments.
|
||||
|
||||
:::caution
|
||||
|
||||
If you already have the Cluster API (CAPI) Operator installed in your cluster, you must use the [manual Helm installation method](#installing-via-helm).
|
||||
|
||||
:::
|
||||
|
||||
### Installing via the Rancher UI
|
||||
|
||||
By adding the Turtles repository via the Rancher UI, Rancher can process the installation and configuration of the CAPI Extension.
|
||||
|
||||
1. Click **☰**. Under **Explore Cluster** in the left navigation menu, select **local**.
|
||||
1. In the left navigation menu of the **Cluster Dashboard**, select **Apps > Repositories**.
|
||||
1. Click **Create** to add a new repository.
|
||||
1. Enter the following:
|
||||
- **Name**: turtles
|
||||
- **Index URL**: https://rancher.github.io/turtles
|
||||
1. Wait until the new repository has a status of `Active`.
|
||||
1. In the left navigation menu, select **Apps > Charts**.
|
||||
1. Enter "turtles" into the search filter to find the Turtles chart.
|
||||
1. Click **Rancher Turtles - the Cluster API Extension**.
|
||||
1. Click **Install > Next > Install**.
|
||||
|
||||
This process uses the default values for the Helm chart, which are good for most installations. If your configuration requires overriding some of these defaults, you can either specify the values during installation from the Rancher UI or you can [manually install the chart via Helm](#installing-via-helm). For details about available values, see the Rancher Turtles [Helm chart reference guide](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values).
|
||||
|
||||
The installation may take a few minutes and after completing you can see the following new deployments in the cluster:
|
||||
|
||||
- `rancher-turtles-system/rancher-turtles-controller-manager`
|
||||
- `rancher-turtles-system/rancher-turtles-cluster-api-operator`
|
||||
- `capi-system/capi-controller-manager`
|
||||
|
||||
#### Demo
|
||||
|
||||
This demo illustrates how to use the Rancher UI to install Rancher Turtles, create/import a CAPI cluster, and install monitoring on the cluster:
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/lGsr7KfBjgU?si=ORkzuAJjcdXUXMxh" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
|
||||
|
||||
### Installing via Helm
|
||||
|
||||
There are two ways to install Rancher Turtles with Helm, depending on whether you include the [CAPI Operator](https://github.com/kubernetes-sigs/cluster-api-operator) as a dependency:
|
||||
|
||||
- [Install Rancher Turtles with CAPI Operator as a dependency](#installing-rancher-turtles-with-cluster-api-capi-operator-as-a-helm-dependency).
|
||||
- [Install Rancher Turtles without CAPI Operator](#installing-rancher-turtles-without-cluster-api-capi-operator-as-a-helm-dependency).
|
||||
|
||||
The CAPI Operator is required for installing Rancher Turtles. You can choose whether you want to take care of this dependency yourself or let the Rancher Turtles Helm chart manage it for you. [Installing Turtles as a dependency](#installing-rancher-turtles-with-cluster-api-capi-operator-as-a-helm-dependency) is simpler, but your best option depends on your specific configuration.
|
||||
|
||||
The CAPI Operator allows for handling the lifecycle of [CAPI providers](https://turtles.docs.rancher.com/tasks/capi-operator/installing_core_provider) using a declarative approach, extending the capabilities of `clusterctl`. If you want to learn more about it, you can refer to [Cluster API Operator book](https://cluster-api-operator.sigs.k8s.io/).
|
||||
|
||||
#### Installing Rancher Turtles with `Cluster API (CAPI) Operator` as a Helm dependency
|
||||
|
||||
1. Add the Helm repository containing the `rancher-turtles` chart as the first step in installation:
|
||||
|
||||
```bash
|
||||
helm repo add turtles https://rancher.github.io/turtles
|
||||
helm repo update
|
||||
```
|
||||
|
||||
2. As mentioned before, installing Rancher Turtles requires the [CAPI Operator](https://github.com/kubernetes-sigs/cluster-api-operator). The Helm chart can automatically install it with a minimal set of flags:
|
||||
|
||||
```bash
|
||||
helm install rancher-turtles turtles/rancher-turtles --version <version> \
|
||||
-n rancher-turtles-system \
|
||||
--dependency-update \
|
||||
--create-namespace --wait \
|
||||
--timeout 180s
|
||||
```
|
||||
|
||||
3. This operation could take a few minutes and after completing you can review the installed controllers listed below:
|
||||
|
||||
- `rancher-turtles-controller`
|
||||
- `capi-operator`
|
||||
|
||||
:::note
|
||||
|
||||
- If `cert-manager` is already available in the cluster, disable its installation as a Rancher Turtles dependency. This prevents dependency conflicts:
|
||||
`--set cluster-api-operator.cert-manager.enabled=false`
|
||||
- For a list of Rancher Turtles versions, refer to the [Turtles release page](https://github.com/rancher/turtles/releases).
|
||||
|
||||
:::
|
||||
|
||||
This is the basic, recommended configuration, which manages the creation of a secret containing the required CAPI feature flags (`CLUSTER_TOPOLOGY`, `EXP_CLUSTER_RESOURCE_SET` and `EXP_MACHINE_POOL` enabled) in the core provider namespace. These feature flags are required to enable additional CAPI functionality.
|
||||
|
||||
If you need to override the default behavior and use an existing secret (or add custom environment variables), you can pass the secret name Helm flag. In this case, as a user, you are in charge of managing the secret creation and its content, including enabling the minimum required features: `CLUSTER_TOPOLOGY`, `EXP_CLUSTER_RESOURCE_SET` and `EXP_MACHINE_POOL`.
|
||||
|
||||
```bash
|
||||
helm install ...
|
||||
# Passing secret name and namespace for additional environment variables
|
||||
--set cluster-api-operator.cluster-api.configSecret.name=<secret-name>
|
||||
```
|
||||
|
||||
The following is an example of a user-managed secret `cluster-api-operator.cluster-api.configSecret.name=variables` with `CLUSTER_TOPOLOGY`, `EXP_CLUSTER_RESOURCE_SET` and `EXP_MACHINE_POOL` feature flags set and an extra custom variable:
|
||||
|
||||
```yaml title="secret.yaml"
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: variables
|
||||
namespace: rancher-turtles-system
|
||||
type: Opaque
|
||||
stringData:
|
||||
CLUSTER_TOPOLOGY: "true"
|
||||
EXP_CLUSTER_RESOURCE_SET: "true"
|
||||
EXP_MACHINE_POOL: "true"
|
||||
CUSTOM_ENV_VAR: "false"
|
||||
```
|
||||
|
||||
:::info
|
||||
|
||||
For detailed information on the values supported by the chart and their usage, refer to [Helm chart options](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values)
|
||||
|
||||
:::
|
||||
|
||||
#### Installing Rancher Turtles without `Cluster API (CAPI) Operator` as a Helm dependency
|
||||
|
||||
:::note
|
||||
|
||||
Remember that if you opt for this installation option, you must manage the CAPI Operator installation yourself. You can follow the [CAPI Operator guide](https://turtles.docs.rancher.com/tasks/capi-operator/intro) in the Rancher Turtles documentation for assistance.
|
||||
|
||||
:::
|
||||
|
||||
1. Add the Helm repository containing the `rancher-turtles` chart as the first step in installation:
|
||||
|
||||
```bash
|
||||
helm repo add turtles https://rancher.github.io/turtles
|
||||
helm repo update
|
||||
```
|
||||
|
||||
2. Install the chart into the `rancher-turtles-system` namespace:
|
||||
|
||||
```bash
|
||||
helm install rancher-turtles turtles/rancher-turtles --version <version>
|
||||
-n rancher-turtles-system
|
||||
--set cluster-api-operator.enabled=false
|
||||
--set cluster-api-operator.cluster-api.enabled=false
|
||||
--create-namespace --wait
|
||||
--dependency-update
|
||||
```
|
||||
|
||||
The previous commands tell Helm to ignore installing `cluster-api-operator` as a dependency.
|
||||
|
||||
3. This operation could take a few minutes and after completing you can review the installed controller listed below:
|
||||
|
||||
- `rancher-turtles-controller`
|
||||
|
||||
## Uninstalling Rancher Turtles
|
||||
|
||||
:::caution
|
||||
|
||||
When installing Rancher Turtles in your Rancher environment, by default, Rancher Turtles enables the CAPI Operator cleanup. This includes cleaning up CAPI Operator specific webhooks and deployments that otherwise cause issues with Rancher provisioning.
|
||||
|
||||
To simplify uninstalling Rancher Turtles (via Rancher or Helm command), the official Rancher Turtles Helm chart includes a `post-delete` hook that that removes the following:
|
||||
|
||||
- Deletes the `mutating-webhook-configuration` and `validating-webhook-configuration` webhooks that are no longer needed.
|
||||
- Deletes the CAPI `deployments` that are no longer needed.
|
||||
|
||||
:::
|
||||
|
||||
To uninstall Rancher Turtles:
|
||||
|
||||
```bash
|
||||
helm uninstall -n rancher-turtles-system rancher-turtles --cascade foreground --wait
|
||||
```
|
||||
|
||||
This may take a few minutes to complete.
|
||||
|
||||
:::note
|
||||
|
||||
Remember that, if you use a different name for the installation or a different namespace, you may need to customize the command for your specific configuration.
|
||||
|
||||
:::
|
||||
|
||||
After Rancher Turtles is uninstalled, Rancher's `embedded-cluster-api` feature must be re-enabled:
|
||||
|
||||
1. Create a `feature.yaml` file, with `embedded-cluster-api` set to true:
|
||||
|
||||
```yaml title="feature.yaml"
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: Feature
|
||||
metadata:
|
||||
name: embedded-cluster-api
|
||||
spec:
|
||||
value: true
|
||||
```
|
||||
|
||||
2. Use `kubectl` to apply the `feature.yaml` file to the cluster:
|
||||
|
||||
```bash
|
||||
kubectl apply -f feature.yaml
|
||||
```
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Architecture
|
||||
title: Fleet Architecture
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -14,7 +14,7 @@ The Harvester feature flag is used to manage access to the Virtualization Manage
|
||||
|
||||
To navigate to the Harvester cluster, click **☰ > Virtualization Management**. From Harvester Clusters page, click one of the clusters listed to go to the single Harvester cluster view.
|
||||
|
||||
* If the Harvester feature flag is enabled, Harvester clusters will be filtered out from any pages or apps (such as Fleet and the multi-cluster app) that list Kubernetes clusters.
|
||||
* If the Harvester feature flag is enabled, Harvester clusters will be filtered out from any pages or apps (such as Continuous Delivery with Fleet) that list Kubernetes clusters.
|
||||
|
||||
* If the Harvester feature flag is disabled, and a Harvester cluster is imported, the Harvester cluster will be shown in the Rancher cluster list in the Cluster Management page. Harvester clusters will only be shown on the cluster list when the feature flag is off.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Architecture
|
||||
title: Logging Architecture
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -6,7 +6,7 @@ title: Rancher Extensions
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/rancher-extensions"/>
|
||||
</head>
|
||||
|
||||
New in Rancher v2.7.0, Rancher introduces **extensions**. Extensions allow users, developers, partners, and customers to extend and enhance the Rancher UI. In addition, users can make changes and create enhancements to their UI functionality independent of Rancher releases. Extensions will enable users to build on top of Rancher to better tailor it to their respective environments. Note that users will also have the ability to update to new versions as well as roll back to a previous version.
|
||||
Extensions allow users, developers, partners, and customers to extend and enhance the Rancher UI. In addition, users can make changes and create enhancements to their UI functionality independent of Rancher releases. Extensions will enable users to build on top of Rancher to better tailor it to their respective environments. Note that users will also have the ability to update to new versions as well as roll back to a previous version.
|
||||
|
||||
Extensions are Helm charts that can only be installed once into a cluster; therefore, these charts have been simplified and separated from the general Helm charts listed under **Apps**.
|
||||
|
||||
@@ -28,13 +28,6 @@ Examples of built-in Rancher extensions are Fleet, Explorer, and Harvester. Exam
|
||||
|
||||
3. On the **Extensions** page, click on the **Available** tab to select which extensions you want to install.
|
||||
|
||||
:::info
|
||||
|
||||
In v2.7.0, the built-in extensions aren't displayed under the **Available** tab. Therefore, you'll need to manually add the desired repos to install extensions.
|
||||
|
||||
:::
|
||||
<br/>
|
||||
|
||||
4. If no extensions are showing as available, you may manually add repos as follows:
|
||||
|
||||
4.1. On the upper right of screen, click on **⋮ > Manage Repositories > Create**.
|
||||
@@ -53,29 +46,32 @@ In v2.7.0, the built-in extensions aren't displayed under the **Available** tab.
|
||||
|
||||

|
||||
|
||||
### Importing and Installing Extensions in an Air-Gapped Environment
|
||||
## Updating and Upgrading Extensions
|
||||
|
||||
1. Find the address of the container image repository that you want to import as an extension. Rancher provides some extensions, such as Kubewarden and Elemental, through the `ui-plugin-catalog` container image at https://hub.docker.com/r/rancher/ui-plugin-catalog/tags. You should import and use the latest tagged version of the image to ensure you receive the latest features and security updates.
|
||||
1. Click **☰ > Extensions** under **Configuration**.
|
||||
1. Select the **Updates** tab.
|
||||
1. Click **Update**.
|
||||
|
||||
* **(Optional)** If the container image is private: [Create](../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md) a registry secret within the `cattle-ui-plugin-system` namespace. Enter the domain of the image address in the **Registry Domain Name** field.
|
||||
If there is a new version of the extension, there will also be an **Update** button visible on the associated card for the extension in the **Available** tab.
|
||||
|
||||
## Deleting Extensions
|
||||
|
||||
1. Click **☰**, then click on the name of your local cluster.
|
||||
1. From the sidebar, select **Apps > Installed Apps**.
|
||||
1. Find the name of the chart you want to delete and select the checkbox next to it.
|
||||
1. Click **Delete**.
|
||||
|
||||
## Deleting Extension Repositories
|
||||
|
||||
1. Click **☰ > Extensions** under **Configuration**.
|
||||
1. On the top right, click **⋮ > Manage Repositories**.
|
||||
1. Find the name of the extension repository you want to delete. Select the checkbox next to the repository name, then click **Delete**.
|
||||
|
||||
## Deleting Extension Repository Container Images
|
||||
|
||||
1. Click **☰**, then select **Extensions**, under **Configuration**.
|
||||
|
||||
1. On the top right, click **⋮ > Manage Extension Catalogs**.
|
||||
|
||||
1. Select the **Import Extension Catalog** button.
|
||||
|
||||
1. Enter the image address in the **Catalog Image Reference** field.
|
||||
|
||||
* **(Optional)** If the container image is private: Select the secret you just created from the **Pull Secrets** drop-down menu.
|
||||
|
||||
1. Click **Load**. The extension will now be **Pending**.
|
||||
|
||||
1. Return to the **Extensions** page.
|
||||
|
||||
1. Select the **Available** tab, and click the **Reload** button to make sure that the list of extensions is up to date.
|
||||
|
||||
1. Find the extension you just added, and click the **Install** button.
|
||||
1. Find the name of the container image you want to delete, then click **⋮ > Uninstall**.
|
||||
|
||||
## Uninstalling Extensions
|
||||
|
||||
@@ -95,13 +91,94 @@ You must reload the page after disabling extensions or display issues may occur.
|
||||
|
||||
:::
|
||||
|
||||
## Updating and Upgrading Extensions
|
||||
## Developing Extensions
|
||||
|
||||
1. Click **☰ > Extensions** under **Configuration**.
|
||||
1. Select the **Updates** tab.
|
||||
1. Click **Update**.
|
||||
To learn how to develop your own extensions, refer to the official [Getting Started](https://rancher.github.io/dashboard/extensions/extensions-getting-started) guide.
|
||||
|
||||
If there is a new version of the extension, there will also be an **Update** button visible on the associated card for the extension in the **Available** tab.
|
||||
## Working with Extensions in an Air-gapped Environment
|
||||
|
||||
If you intend to work with extensions in an air-gapped environment, you must perform some extra steps before you can complete certain tasks.
|
||||
|
||||
### Accessing Rancher UI Extensions in an Air-Gapped Environment
|
||||
|
||||
Rancher provides some extensions, such as Kubewarden and Elemental, through the `ui-plugin-catalog` container image at https://hub.docker.com/r/rancher/ui-plugin-catalog/tags. If you're trying to install these extensions in an air-gapped environment, you must make the `ui-plugin-catalog` image accessible.
|
||||
|
||||
1. Mirror the `ui-plugin-catalog` image to a private registry:
|
||||
|
||||
```bash
|
||||
export REGISTRY_ENDPOINT=<my-private-registry-endpoint> # e.g. "my-private-registry.com"
|
||||
docker pull rancher/ui-plugin-catalog:<tag>
|
||||
docker tag rancher/ui-plugin-catalog:<tag> $REGISTRY_ENDPOINT/rancher/ui-plugin-catalog:<tag>
|
||||
docker push $REGISTRY_ENDPOINT/rancher/ui-plugin-catalog:<tag>
|
||||
2. Use the mirrored image to create a Kubernetes [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/):
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: ui-plugin-catalog
|
||||
namespace: cattle-ui-plugin-system
|
||||
labels:
|
||||
catalog.cattle.io/ui-extensions-catalog-image: ui-plugin-catalog
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
catalog.cattle.io/ui-extensions-catalog-image: ui-plugin-catalog
|
||||
template:
|
||||
metadata:
|
||||
namespace: cattle-ui-plugin-system
|
||||
labels:
|
||||
catalog.cattle.io/ui-extensions-catalog-image: ui-plugin-catalog
|
||||
spec:
|
||||
containers:
|
||||
- name: server
|
||||
image: <my-private-registry-endpoint>/rancher/ui-plugin-catalog:<tag>
|
||||
imagePullPolicy: Always
|
||||
imagePullSecrets:
|
||||
- name: <my-registry-credentials>
|
||||
```
|
||||
3. Expose the deployment by creating a [ClusterIP service](https://kubernetes.io/docs/concepts/services-networking/service/#type-clusterip):
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: ui-plugin-catalog-svc
|
||||
namespace: cattle-ui-plugin-system
|
||||
spec:
|
||||
ports:
|
||||
- name: catalog-svc-port
|
||||
port: 8080
|
||||
protocol: TCP
|
||||
targetPort: 8080
|
||||
selector:
|
||||
catalog.cattle.io/ui-extensions-catalog-image: ui-plugin-catalog
|
||||
type: ClusterIP
|
||||
```
|
||||
4. Create a [ClusterRepo](../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md) that targets the ClusterIP service:
|
||||
```yaml
|
||||
apiVersion: catalog.cattle.io/v1
|
||||
kind: ClusterRepo
|
||||
metadata:
|
||||
name: ui-plugin-catalog-repo
|
||||
spec:
|
||||
url: http://ui-plugin-catalog-svc.cattle-ui-plugin-system:8080
|
||||
```
|
||||
|
||||
After you successfully set up these resources, you can install the extensions from the `ui-plugin-charts` manifest into your air-gapped environment.
|
||||
|
||||
### Importing and Installing Extensions in an Air-gapped Environment
|
||||
|
||||
1. Find the address of the container image repository that you want to import as an extension. You should import and use the latest tagged version of the image to ensure you receive the latest features and security updates.
|
||||
- **(Optional)** If the container image is private: [Create](../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md) a registry secret within the `cattle-ui-plugin-system` namespace. Enter the domain of the image address in the **Registry Domain Name** field.
|
||||
1. Click **☰**, then select **Extensions**, under **Configuration**.
|
||||
1. On the top right, click **⋮ > Manage Extension Catalogs**.
|
||||
1. Select the **Import Extension Catalog** button.
|
||||
1. Enter the image address in the **Catalog Image Reference** field.
|
||||
* **(Optional)** If the container image is private, select the secret you just created from the **Pull Secrets** drop-down menu.
|
||||
1. Click **Load**. The extension will now be **Pending**.
|
||||
1. Return to the **Extensions** page.
|
||||
1. Select the **Available** tab, and click **Reload** to make sure that the list of extensions is up to date.
|
||||
1. Find the extension you just added, and click **Install**.
|
||||
|
||||
### Updating and Upgrading an Extensions Repository in an Air-gapped Environment
|
||||
|
||||
@@ -119,26 +196,3 @@ After you mirror the latest changes, follow these steps:
|
||||
1. Click **⋮ > Edit config**.
|
||||
1. Update the **Container Image** field within the deployment's container with the latest image.
|
||||
1. Click **Save**.
|
||||
|
||||
## Deleting Helm Charts
|
||||
|
||||
1. Click **☰**, then click on the name of your local cluster.
|
||||
1. From the sidebar, select **Apps > Installed Apps**.
|
||||
1. Find the name of the chart you want to delete and select the checkbox next to it.
|
||||
1. Click **Delete**.
|
||||
|
||||
## Deleting Extension Repositories
|
||||
|
||||
1. Click **☰ > Extensions** under **Configuration**.
|
||||
1. On the top right, click **⋮ > Manage Repositories**.
|
||||
1. Find the name of the extension repository you want to delete. Select the checkbox next to the repository name, then click **Delete**.
|
||||
|
||||
## Deleting Extension Repository Container Images
|
||||
|
||||
1. Click **☰**, then select **Extensions**, under **Configuration**.
|
||||
1. On the top right, click **⋮ > Manage Extension Catalogs**.
|
||||
1. Find the name of the container image you want to delete. Click **⋮ > Uninstall**.
|
||||
|
||||
## Developing Extensions
|
||||
|
||||
To learn how to develop your own extensions, refer to the official [Getting Started](https://rancher.github.io/dashboard/extensions/extensions-getting-started) guide.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Best Practices Guide
|
||||
title: Best Practice Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Best Practices for Rancher Managed vSphere Clusters
|
||||
title: Best Practices for Rancher Managed VMware vSphere Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -18,6 +18,6 @@ Configuring sensible monitoring and alerting rules is vital for running any prod
|
||||
|
||||
Running well-built containers can greatly impact the overall performance and security of your environment. Refer to this [guide](tips-to-set-up-containers.md) for tips.
|
||||
|
||||
### Best Practices for Rancher Managed vSphere Clusters
|
||||
### Best Practices for Rancher Managed VMware vSphere Clusters
|
||||
|
||||
This [guide](rancher-managed-clusters-in-vsphere.md) outlines a reference architecture for provisioning downstream Rancher clusters in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
|
||||
|
||||
+2
-2
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: Installing Rancher in a vSphere Environment
|
||||
title: Installing Rancher in a VMware vSphere Environment
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere"/>
|
||||
</head>
|
||||
|
||||
This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
|
||||
This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a VMware vSphere environment. It also desctibes standard vSphere best practices as documented by VMware.
|
||||
|
||||
|
||||
<figcaption>Solution Overview</figcaption>
|
||||
|
||||
@@ -16,6 +16,6 @@ Refer to this [guide](tips-for-running-rancher.md) for our general advice for se
|
||||
|
||||
This [guide](rancher-deployment-strategy.md) is designed to help you choose whether a regional deployment strategy or a hub-and-spoke deployment strategy is better for a Rancher server that manages downstream Kubernetes clusters.
|
||||
|
||||
### Installing Rancher in a vSphere Environment
|
||||
### Installing Rancher in a VMware vSphere Environment
|
||||
|
||||
This [guide](on-premises-rancher-in-vsphere.md) outlines a reference architecture for installing Rancher in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: VSphere Node Template Configuration
|
||||
title: VMware vSphere Node Template Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+4
@@ -40,6 +40,10 @@ The AKSConfig, EKSConfig or GKEConfig represents the desired state. Nil values a
|
||||
|
||||
UpstreamSpec represents the cluster as it is in the hosted Kubernetes provider. It's refreshed every 5 minutes. After the UpstreamSpec is refreshed, Rancher checks if the cluster has an update in progress. If it's currently updating, nothing further is done. If it is not currently updating, any managed fields on AKSConfig, EKSConfig or GKEConfig are overwritten with their corresponding value from the recently updated UpstreamSpec.
|
||||
|
||||
:::warning
|
||||
When you import a cluster from a cloud provider into Rancher, UpstreamSpec represents the cluster state and Config is empty. If you then update the imported cluster through the Rancher UI, both UpstreamSpec and Config become non-null. Any further updates to the cluster should be applied through Rancher. This is because there is no safe way to determine if changes originating from UpstreamSpec represent the desired state or just a mismatch with Config. If you update the imported cluster through the cloud provider console after you apply any updates through the Rancher UI, the controller will deploy a rollback and the content of Config will be considered the desired state.
|
||||
:::
|
||||
|
||||
The effective desired state can be thought of as the UpstreamSpec, plus all non-nil fields in the AKSConfig, EKSConfig or GKEConfig. This is what is displayed in the UI.
|
||||
|
||||
If Rancher and another source attempt to update a cluster at the same time, or within 5 minutes of an update finishing, any managed fields are likely to get caught in a race condition. To use EKS as an example, a cluster may have PrivateAccess as a managed field. If PrivateAccess is false and then enabled in EKS console at 11:01, and tags are updated from Rancher before 11:05, then the value is likely to be overwritten. This can also occur if tags are updated while the cluster is still processing the update. The issue described in this example shouldn't occur if the cluster is registered and the PrivateAccess fields are nil.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Monitoring V2 Configuration Examples
|
||||
title: Monitoring Configuration Examples
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Monitoring V2 Configuration
|
||||
title: Monitoring Configuration Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Architecture
|
||||
title: Rancher Architecture
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: K3s Hardening Guide
|
||||
title: K3s Hardening Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: RKE Hardening Guide
|
||||
title: RKE Hardening Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: RKE2 Hardening Guide
|
||||
title: RKE2 Hardening Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Security
|
||||
title: Rancher Security Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -31,7 +31,7 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | This vulnerability only affects customers using [Weave](../../faq/container-network-interface-providers.md#weave) Container Network Interface (CNI) when configured through [RKE templates](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/about-rke1-templates.md). A vulnerability was discovered in Rancher versions 2.5.0 up to and including 2.5.13, and 2.6.0 up to and including 2.6.4, where a user interface (UI) issue with RKE templates does not include a value for the Weave password when Weave is chosen as the CNI. If a cluster is created based on the mentioned template, and Weave is configured as the CNI, no password will be created for [network encryption](https://www.weave.works/docs/net/latest/tasks/manage/security-untrusted-networks/) in Weave; therefore, network traffic in the cluster will be sent unencrypted. | 24 May 2022 | [Rancher v2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) and [Rancher v2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [CVE-2021-36784](https://github.com/rancher/rancher/security/advisories/GHSA-jwvr-vv7p-gpwq) | A vulnerability was discovered in Rancher versions from 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3 which allows users who have create or update permissions on [Global Roles](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md) to escalate their permissions, or those of another user, to admin-level permissions. Global Roles grant users Rancher-wide permissions, such as the ability to create clusters. In the identified versions of Rancher, when users are given permission to edit or create Global Roles, they are not restricted to only granting permissions which they already posses. This vulnerability affects customers who utilize non-admin users that are able to create or edit Global Roles. The most common use case for this scenario is the `restricted-admin` role. | 14 Apr 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) and [Rancher v2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [CVE-2021-4200](https://github.com/rancher/rancher/security/advisories/GHSA-hx8w-ghh8-r4xf) | This vulnerability only affects customers using the `restricted-admin` role in Rancher. A vulnerability was discovered in Rancher versions from 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3 where the `global-data` role in `cattle-global-data` namespace grants write access to the Catalogs. Since each user with any level of catalog access was bound to the `global-data` role, this grants write access to templates (`CatalogTemplates`) and template versions (`CatalogTemplateVersions`) for any user with any level of catalog access. New users created in Rancher are by default assigned to the `user` role (standard user), which is not designed to grant write catalog access. This vulnerability effectively elevates the privilege of any user to write access for the catalog template and catalog template version resources. | 14 Apr 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) and [Rancher v2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [GHSA-wm2r-rp98-8pmh](https://github.com/rancher/rancher/security/advisories/GHSA-wm2r-rp98-8pmh) | This vulnerability only affects customers using [Fleet](../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) for continuous delivery with authenticated Git and/or Helm repositories. An issue was discovered in `go-getter` library in versions prior to [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) that exposes SSH private keys in base64 format due to a failure in redacting such information from error messages. The vulnerable version of this library is used in Rancher through Fleet in versions of Fleet prior to [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9). This issue affects Rancher versions 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3. The issue was found and reported by Dagan Henderson from Raft Engineering. | 14 Apr 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) and [Rancher v2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [GHSA-wm2r-rp98-8pmh](https://github.com/rancher/rancher/security/advisories/GHSA-wm2r-rp98-8pmh) | This vulnerability only affects customers using [Continuous Delivery with Fleet](../../integrations-in-rancher/fleet/fleet.md) for continuous delivery with authenticated Git and/or Helm repositories. An issue was discovered in `go-getter` library in versions prior to [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) that exposes SSH private keys in base64 format due to a failure in redacting such information from error messages. The vulnerable version of this library is used in Rancher through Fleet in versions of Fleet prior to [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9). This issue affects Rancher versions 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3. The issue was found and reported by Dagan Henderson from Raft Engineering. | 14 Apr 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) and [Rancher v2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [CVE-2021-36778](https://github.com/rancher/rancher/security/advisories/GHSA-4fc7-hc63-7fjg) | A vulnerability was discovered in Rancher versions from 2.5.0 up to and including 2.5.11 and from 2.6.0 up to and including 2.6.2, where an insufficient check of the same-origin policy when downloading Helm charts from a configured private repository can lead to exposure of the repository credentials to a third-party provider. This issue only happens when the user configures access credentials to a private repository in Rancher inside `Apps & Marketplace > Repositories`. The issue was found and reported by Martin Andreas Ullrich. | 14 Apr 2022 | [Rancher v2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) and [Rancher v2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) |
|
||||
| [GHSA-hwm2-4ph6-w6m5](https://github.com/rancher/rancher/security/advisories/GHSA-hwm2-4ph6-w6m5) | A vulnerability was discovered in versions of Rancher starting 2.0 up to and including 2.6.3. The `restricted` pod security policy (PSP) provided in Rancher deviated from the upstream `restricted` policy provided in Kubernetes on account of which Rancher's PSP had `runAsUser` set to `runAsAny`, while upstream had `runAsUser` set to `MustRunAsNonRoot`. This allowed containers to run as any user, including a privileged user (`root`), even when Rancher's `restricted` policy was enforced on a project or at the cluster level. | 31 Mar 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) |
|
||||
| [CVE-2021-36775](https://github.com/rancher/rancher/security/advisories/GHSA-28g7-896h-695v) | A vulnerability was discovered in Rancher versions up to and including 2.4.17, 2.5.11 and 2.6.2. After removing a `Project Role` associated with a group from the project, the bindings that granted access to cluster-scoped resources for those subjects were not deleted. This was due to an incomplete authorization logic check. A user who was a member of the affected group with authenticated access to Rancher could exploit this vulnerability to access resources they shouldn't have had access to. The exposure level would depend on the original permission level granted to the affected project role. This vulnerability only affected customers using group based authentication in Rancher. | 31 Mar 2022 | [Rancher v2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3), [Rancher v2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) and [Rancher v2.4.18](https://github.com/rancher/rancher/releases/tag/v2.4.18) |
|
||||
|
||||
@@ -19,7 +19,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.3 | v0.4.3 | ✓ | ✓ |
|
||||
| v2.8.2 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.1 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.0 | v0.4.2 | ✗ | ✓ |
|
||||
|
||||
@@ -13,15 +13,16 @@ Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG
|
||||
### Double check if all the required ports are opened in your (host) firewall
|
||||
|
||||
Double check if all the [required ports](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) are opened in your (host) firewall. The overlay network uses UDP in comparison to all other required ports which are TCP.
|
||||
|
||||
### Check if overlay network is functioning correctly
|
||||
|
||||
The pod can be scheduled to any of the hosts you used for your cluster, but that means that the NGINX ingress controller needs to be able to route the request from `NODE_1` to `NODE_2`. This happens over the overlay network. If the overlay network is not functioning, you will experience intermittent TCP/HTTP connection failures due to the NGINX ingress controller not being able to route to the pod.
|
||||
|
||||
To test the overlay network, you can launch the following `DaemonSet` definition. This will run a `swiss-army-knife` container on every host (image was developed by Rancher engineers and can be found here: https://github.com/rancherlabs/swiss-army-knife), which we will use to run a `ping` test between containers on all hosts.
|
||||
|
||||
:::note
|
||||
:::caution
|
||||
|
||||
This container [does not support ARM nodes](https://github.com/leodotcloud/swiss-army-knife/issues/18), such as a Raspberry Pi. This will be seen in the pod logs as `exec user process caused: exec format error`.
|
||||
The `swiss-army-knife` container does not support Windows nodes. It also [does not support ARM nodes](https://github.com/leodotcloud/swiss-army-knife/issues/18), such as a Raspberry Pi. When the test encounters incompatible nodes, this is recorded in the pod logs as an error message, such as `exec user process caused: exec format error` for ARM nodes, or `ImagePullBackOff (Back-off pulling image "rancherlabs/swiss-army-knife)` for Windows nodes.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+32
-12
@@ -245,6 +245,38 @@ module.exports = {
|
||||
{
|
||||
fromExtensions: ['html', 'htm'],
|
||||
redirects: [
|
||||
{ // Redirects for multi-cluster apps removal (rancher-docs/issues/734)
|
||||
to: '/integrations-in-rancher/fleet',
|
||||
from: ['/pages-for-subheaders/deploy-apps-across-clusters', '/how-to-guides/new-user-guides/deploy-apps-across-clusters', '/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet', '/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps']
|
||||
},
|
||||
{
|
||||
to: '/v2.8/integrations-in-rancher/fleet',
|
||||
from: ['/v2.8/pages-for-subheaders/deploy-apps-across-clusters', '/v2.8/how-to-guides/new-user-guides/deploy-apps-across-clusters', '/v2.8/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet', '/v2.8/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps']
|
||||
},
|
||||
{
|
||||
to: '/v2.7/integrations-in-rancher/fleet-gitops-at-scale',
|
||||
from: ['/v2.7/pages-for-subheaders/deploy-apps-across-clusters', '/v2.7/how-to-guides/new-user-guides/deploy-apps-across-clusters', '/v2.7/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet', '/v2.7/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps']
|
||||
},// Redirects for multi-cluster apps removal (rancher-docs/issues/734) (end)
|
||||
{
|
||||
to: '/faq/deprecated-features',
|
||||
from: '/faq/deprecated-features-in-v2.5'
|
||||
},
|
||||
{
|
||||
to: '/v2.8/faq/deprecated-features',
|
||||
from: '/v2.8/faq/deprecated-features-in-v2.5'
|
||||
},
|
||||
{
|
||||
to: '/v2.7/faq/deprecated-features',
|
||||
from: '/v2.7/faq/deprecated-features-in-v2.5'
|
||||
},
|
||||
{
|
||||
to: '/v2.6/faq/deprecated-features',
|
||||
from: '/v2.6/faq/deprecated-features-in-v2.5'
|
||||
},
|
||||
{
|
||||
to: '/v2.5/faq/deprecated-features',
|
||||
from: '/v2.5/faq/deprecated-features-in-v2.5'
|
||||
},
|
||||
{ // Redirects for pages-for-subheaders removal [2.0-2.4]
|
||||
to: '/v2.0-v2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication',
|
||||
from: '/v2.0-v2.4/pages-for-subheaders/about-authentication'
|
||||
@@ -1429,10 +1461,6 @@ module.exports = {
|
||||
to: '/v2.7/integrations-in-rancher/logging/custom-resource-configuration',
|
||||
from: '/v2.7/pages-for-subheaders/custom-resource-configuration'
|
||||
},
|
||||
{
|
||||
to: '/v2.7/how-to-guides/new-user-guides/deploy-apps-across-clusters',
|
||||
from: '/v2.7/pages-for-subheaders/deploy-apps-across-clusters'
|
||||
},
|
||||
{
|
||||
to: '/v2.7/getting-started/quick-start-guides/deploy-rancher-manager',
|
||||
from: '/v2.7/pages-for-subheaders/deploy-rancher-manager'
|
||||
@@ -1781,10 +1809,6 @@ module.exports = {
|
||||
to: '/v2.8/integrations-in-rancher/logging/custom-resource-configuration',
|
||||
from: '/v2.8/pages-for-subheaders/custom-resource-configuration'
|
||||
},
|
||||
{
|
||||
to: '/v2.8/how-to-guides/new-user-guides/deploy-apps-across-clusters',
|
||||
from: '/v2.8/pages-for-subheaders/deploy-apps-across-clusters'
|
||||
},
|
||||
{
|
||||
to: '/v2.8/getting-started/quick-start-guides/deploy-rancher-manager',
|
||||
from: '/v2.8/pages-for-subheaders/deploy-rancher-manager'
|
||||
@@ -2129,10 +2153,6 @@ module.exports = {
|
||||
to: '/integrations-in-rancher/logging/custom-resource-configuration',
|
||||
from: '/pages-for-subheaders/custom-resource-configuration'
|
||||
},
|
||||
{
|
||||
to: '/how-to-guides/new-user-guides/deploy-apps-across-clusters',
|
||||
from: '/pages-for-subheaders/deploy-apps-across-clusters'
|
||||
},
|
||||
{
|
||||
to: '/getting-started/quick-start-guides/deploy-rancher-manager',
|
||||
from: '/pages-for-subheaders/deploy-rancher-manager'
|
||||
|
||||
@@ -11,13 +11,13 @@
|
||||
"message": "快速入门指南",
|
||||
"description": "The label for category Quick Start Guides in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Deploy Rancher": {
|
||||
"sidebar.tutorialSidebar.category.Deploying Rancher Server": {
|
||||
"message": "部署 Rancher",
|
||||
"description": "The label for category Deploy Rancher in sidebar tutorialSidebar"
|
||||
"description": "The label for category Deploying Rancher Server in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Deploy Workloads": {
|
||||
"sidebar.tutorialSidebar.category.Deploying Workloads": {
|
||||
"message": "部署工作负载",
|
||||
"description": "The label for category Deploy Workloads in sidebar tutorialSidebar"
|
||||
"description": "The label for category Deploying Workloads in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Installation and Upgrade": {
|
||||
"message": "安装和升级",
|
||||
@@ -95,9 +95,9 @@
|
||||
"message": "关于 RKE1 模板",
|
||||
"description": "The label for category About RKE1 Templates in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Manage Clusters": {
|
||||
"message": "管理集群",
|
||||
"description": "The label for category Manage Clusters in sidebar tutorialSidebar"
|
||||
"sidebar.tutorialSidebar.category.Cluster Administration": {
|
||||
"message": "集群管理",
|
||||
"description": "The label for category Cluster Administration in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Access Clusters": {
|
||||
"message": "访问集群",
|
||||
@@ -115,49 +115,57 @@
|
||||
"message": "配置存储示例",
|
||||
"description": "The label for category Provisioning Storage Examples in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Kubernetes Cluster Setup": {
|
||||
"sidebar.tutorialSidebar.category.Setting up a Kubernetes Cluster for Rancher Server": {
|
||||
"message": "Kubernetes 集群设置",
|
||||
"description": "The label for category Kubernetes Cluster Setup in sidebar tutorialSidebar"
|
||||
"description": "The label for category Setting up a Kubernetes Cluster for Rancher Server in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Infrastructure Setup": {
|
||||
"message": "基础设施设置",
|
||||
"description": "The label for category Infrastructure Setup in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Kubernetes Clusters in Rancher Setup": {
|
||||
"message": "Rancher 设置中的 Kubernetes 集群",
|
||||
"message": "Rancher 中的 Kubernetes 集群设置",
|
||||
"description": "The label for category Kubernetes Clusters in Rancher Setup in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Checklist for Production-Ready Clusters": {
|
||||
"message": "生产就绪集群检查清单",
|
||||
"description": "The label for category Checklist for Production-Ready Clusters in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Set Up Clusters from Hosted Kubernetes Providers": {
|
||||
"sidebar.tutorialSidebar.category.Setting up Clusters from Hosted Kubernetes Providers": {
|
||||
"message": "通过托管 Kubernetes 提供商设置集群",
|
||||
"description": "The label for category Set Up Clusters from Hosted Kubernetes Providers in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Launching Kubernetes on Windows Clusters": {
|
||||
"message": "在 Windows 集群上启动 Kubernetes",
|
||||
"description": "The label for category Launching Kubernetes on Windows Clusters in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Use Windows Clusters": {
|
||||
"message": "使用 Windows 集群",
|
||||
"description": "The label for category Use Windows Clusters in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Set Up Cloud Providers": {
|
||||
"sidebar.tutorialSidebar.category.Setting up Cloud Providers": {
|
||||
"message": "设置 Cloud Provider",
|
||||
"description": "The label for category Set Up Cloud Providers in sidebar tutorialSidebar"
|
||||
"description": "The label for category Setting up Cloud Providers in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Launch Kubernetes with Rancher": {
|
||||
"sidebar.tutorialSidebar.category.Migrate to an Out-of-tree Cloud Provider": {
|
||||
"message": "迁移到树外云提供商",
|
||||
"description": "The label for category Migrate to an Out-of-tree Cloud Provider in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Launching Kubernetes with Rancher": {
|
||||
"message": "使用 Rancher 启动 Kubernetes",
|
||||
"description": "The label for category Launch Kubernetes with Rancher in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Use New Nodes in an Infra Provider": {
|
||||
"sidebar.tutorialSidebar.category.Launching New Nodes in an Infra Provider": {
|
||||
"message": "在基础设施提供商中使用新节点",
|
||||
"description": "The label for category Use New Nodes in an Infra Provider in sidebar tutorialSidebar"
|
||||
"description": "The label for category Launching New Nodes in an Infra Provider in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.vSphere": {
|
||||
"message": "vSphere",
|
||||
"description": "The label for category vSphere in sidebar tutorialSidebar"
|
||||
"sidebar.tutorialSidebar.category.Creating a vSphere Cluster": {
|
||||
"message": "创建 vSphere 集群",
|
||||
"description": "The label for category Creating a vSphere Cluster in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Nutanix": {
|
||||
"message": "Nutanix",
|
||||
"description": "The label for category Nutanix in sidebar tutorialSidebar"
|
||||
"sidebar.tutorialSidebar.category.Creating a Nutanix AOS Cluster": {
|
||||
"message": "创建 Nutanix AOS 集群",
|
||||
"description": "The label for category Creating a Nutanix AOS Cluster in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Kubernetes Resources Setup": {
|
||||
"message": "Kubernetes 资源设置",
|
||||
@@ -175,9 +183,9 @@
|
||||
"message": "负载均衡和 Ingress Controller",
|
||||
"description": "The label for category Load Balancer and Ingress Controller in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Helm Charts in Rancher": {
|
||||
"message": "Rancher 中的 Helm Chart",
|
||||
"description": "The label for category Helm Charts in Rancher in sidebar tutorialSidebar"
|
||||
"sidebar.tutorialSidebar.category.Helm Charts and Apps": {
|
||||
"message": "Helm Charts 和 Apps",
|
||||
"description": "The label for category Helm Charts and Apps in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Deploy Apps Across Clusters": {
|
||||
"message": "跨集群部署应用",
|
||||
@@ -191,13 +199,13 @@
|
||||
"message": "高级用户指南",
|
||||
"description": "The label for category Advanced User Guides in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Manage Projects": {
|
||||
"message": "管理项目",
|
||||
"description": "The label for category Manage Projects in sidebar tutorialSidebar"
|
||||
"sidebar.tutorialSidebar.category.Project Administration": {
|
||||
"message": "项目管理",
|
||||
"description": "The label for category Project Administration in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Manage Project Resource Quotas": {
|
||||
"message": "管理项目资源配额",
|
||||
"description": "The label for category Manage Project Resource Quotas in sidebar tutorialSidebar"
|
||||
"sidebar.tutorialSidebar.category.Project Resource Quotas": {
|
||||
"message": "项目资源配额",
|
||||
"description": "The label for category Project Resource Quotas in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Monitoring/Alerting Guides": {
|
||||
"message": "Monitoring/Alerting 指南",
|
||||
@@ -207,33 +215,33 @@
|
||||
"message": "Prometheus Federator 指南",
|
||||
"description": "The label for category Prometheus Federator Guides in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Monitoring V2 Configuration Guides": {
|
||||
"message": "Monitoring V2 配置指南",
|
||||
"description": "The label for category Monitoring V2 Configuration Guides in sidebar tutorialSidebar"
|
||||
"sidebar.tutorialSidebar.category.Monitoring Configuration Guides": {
|
||||
"message": "Monitoring 配置指南",
|
||||
"description": "The label for category Monitoring Configuration Guides in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Advanced Configuration": {
|
||||
"message": "高级配置",
|
||||
"description": "The label for category Advanced Configuration in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Istio Setup Guide": {
|
||||
"sidebar.tutorialSidebar.category.Istio Setup Guides": {
|
||||
"message": "Istio 设置指南",
|
||||
"description": "The label for category Istio Setup Guide in sidebar tutorialSidebar"
|
||||
"description": "The label for category Istio Setup Guides in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.CIS Scan Guides": {
|
||||
"message": "CIS 扫描指南",
|
||||
"description": "The label for category CIS Scan Guides in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Enable Experimental Features": {
|
||||
"sidebar.tutorialSidebar.category.Enabling Experimental Features": {
|
||||
"message": "启用实验功能",
|
||||
"description": "The label for category Enable Experimental Features in sidebar tutorialSidebar"
|
||||
"description": "The label for category Enabling Experimental Features in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Reference Guides": {
|
||||
"message": "参考指南",
|
||||
"description": "The label for category Reference Guides in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Best Practices": {
|
||||
"sidebar.tutorialSidebar.category.Best Practice Guides": {
|
||||
"message": "最佳实践",
|
||||
"description": "The label for category Best Practices in sidebar tutorialSidebar"
|
||||
"description": "The label for category Best Practice Guides in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Rancher Server": {
|
||||
"message": "Rancher Server",
|
||||
@@ -255,9 +263,9 @@
|
||||
"message": "Rancher Server 配置",
|
||||
"description": "The label for category Rancher Server Configuration in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.GKE Cluster Configuration": {
|
||||
"sidebar.tutorialSidebar.category.GKE Cluster Configuration Reference": {
|
||||
"message": "GKE 集群配置",
|
||||
"description": "The label for category GKE Cluster Configuration in sidebar tutorialSidebar"
|
||||
"description": "The label for category GKE Cluster Configuration Reference in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Use Existing Nodes": {
|
||||
"message": "使用现有节点",
|
||||
@@ -283,9 +291,9 @@
|
||||
"message": "备份和恢复配置",
|
||||
"description": "The label for category Backup & Restore Configuration in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Monitoring V2 Configuration": {
|
||||
"message": "Monitoring V2 配置",
|
||||
"description": "The label for category Monitoring V2 Configuration in sidebar tutorialSidebar"
|
||||
"sidebar.tutorialSidebar.category.Monitoring Configuration Reference": {
|
||||
"message": "Monitoring 配置",
|
||||
"description": "The label for category Monitoring Configuration Reference in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Prometheus Federator": {
|
||||
"message": "Prometheus Federator",
|
||||
@@ -303,9 +311,9 @@
|
||||
"message": "关于 API",
|
||||
"description": "The label for category About the API in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Rancher Security": {
|
||||
"message": "Rancher 安全",
|
||||
"description": "The label for category Rancher Security in sidebar tutorialSidebar"
|
||||
"sidebar.tutorialSidebar.category.Rancher Security Guides": {
|
||||
"message": "Rancher 安全指南",
|
||||
"description": "The label for category Rancher Security Guides in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.SELinux RPM": {
|
||||
"message": "SELinux RPM",
|
||||
@@ -386,5 +394,21 @@
|
||||
"sidebar.tutorialSidebar.category.Example Workflows": {
|
||||
"message": "工作流程示例",
|
||||
"description": "The label for category Example Workflows in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Virtualization on Kubernetes with Harvester": {
|
||||
"message": "使用 Harvester 在 Kubernetes 上进行虚拟化",
|
||||
"description": "The label for category Virtualization on Kubernetes with Harvester in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Cloud Native Storage with Longhorn": {
|
||||
"message": "使用 Longhorn 进行云原生存储",
|
||||
"description": "The label for category Cloud Native Storage with Longhorn in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Container Security with Neuvector": {
|
||||
"message": "使用 NeuVector 实现容器安全",
|
||||
"description": "The label for category Container Security with Neuvector in sidebar tutorialSidebar"
|
||||
},
|
||||
"sidebar.tutorialSidebar.category.Cluster API (CAPI) with Rancher Turtles": {
|
||||
"message": "Cluster API (CAPI) 与 Rancher Turtles",
|
||||
"description": "The label for category Cluster API (CAPI) with Rancher Turtles in sidebar tutorialSidebar"
|
||||
}
|
||||
}
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Rancher 中已弃用的功能
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/deprecated-features"/>
|
||||
</head>
|
||||
|
||||
### Rancher 的弃用策略是什么?
|
||||
|
||||
我们已经在支持的[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方的弃用策略。
|
||||
|
||||
### 在哪里可以了解 Rancher 中已弃用哪些功能?
|
||||
|
||||
Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能,请参阅以下的补丁版本:
|
||||
|
||||
| Patch 版本 | 发布时间 |
|
||||
| --------------------------------------------------------------- | ------------------ |
|
||||
| [2.8.3](https://github.com/rancher/rancher/releases/tag/v2.8.3) | 2024 年 3 月 28 日 |
|
||||
| [2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2) | 2024 年 2 月 8 日 |
|
||||
| [2.8.1](https://github.com/rancher/rancher/releases/tag/v2.8.1) | 2024 年 1 月 22 日 |
|
||||
| [2.8.0](https://github.com/rancher/rancher/releases/tag/v2.8.0) | 2023 年 12 月 6 日 |
|
||||
|
||||
### 当一个功能被标记为弃用我可以得到什么样的预期?
|
||||
|
||||
当功能被标记为“已弃用”时,它依然可用并得到支持,允许按照常规的流程进行升级。一旦升级完成,用户/管理员应开始计划在升级到标记为已移除的版本之前放弃使用已弃用的功能。对于新的部署,建议不要使用已弃用的功能。
|
||||
@@ -2,68 +2,50 @@
|
||||
title: 一般常见问题解答
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/general-faq"/>
|
||||
</head>
|
||||
|
||||
本文包含了用户常见的 Rancher 2.x 问题。
|
||||
|
||||
有关常见技术问题,请参阅[常见技术问题解答](technical-items.md)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 支持 Docker Swarm 和 Mesos 作为环境类型吗?**
|
||||
## Rancher 2.x 支持 Docker Swarm 和 Mesos 作为环境类型吗?
|
||||
|
||||
如果你在 Rancher 2.x 中创建环境,Swarm 和 Mesos 将不再是可选的标准选项。但是,Swarm 和 Mesos 还能继续作为可以部署的商店应用程序。这是一个艰难的决定,但这是大势所趋。比如说,15,000 多个集群可能只有大约 200 个在运行 Swarm。
|
||||
|
||||
<br/>
|
||||
## 是否可以使用 Rancher 2.x 管理 Azure Kubernetes 服务?
|
||||
|
||||
**是否可以使用 Rancher 2.x 管理 Azure Kubernetes 服务?**
|
||||
是的。请参阅我们的[集群管理]((../how-to-guides/new-user-guides/manage-clusters/manage-clusters.md))指南,了解 AKS 上可用的 Rancher 功能,以及相关的 [AKS 的文档](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md)
|
||||
|
||||
是的。
|
||||
## Rancher 是否支持 Windows?
|
||||
|
||||
<br/>
|
||||
Rancher 支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息,请参阅[为 Windows 配置自定义集群](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md)。
|
||||
|
||||
**Rancher 是否支持 Windows?**
|
||||
|
||||
Rancher 支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息,请参阅[为 Windows 配置自定义集群](../pages-for-subheaders/use-windows-clusters.md)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 是否支持 Istio?**
|
||||
## Rancher 是否支持 Istio?
|
||||
|
||||
Rancher 支持 [Istio](../pages-for-subheaders/istio.md)。
|
||||
|
||||
此外,Istio 是在我们的微型 PaaS “Rio” 中实现的,它可以运行在 Rancher 2.x 以及任何符合 CNCF 的 Kubernetes 集群上。详情请参阅[这里](https://rio.io/)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文?**
|
||||
## Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文?
|
||||
|
||||
密文管理已在我们的 roadmap 上,但我们尚未将该功能分配给特定版本。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 是否也支持 RKT 容器?**
|
||||
## Rancher 2.x 是否也支持 RKT 容器?
|
||||
|
||||
目前,我们只支持 Docker。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 2.x 是否支持将 Calico、Contiv、Contrail、Flannel、Weave net 等网络插件用于嵌入和已注册的 Kubernetes?**
|
||||
## Rancher 2.x 是否支持将 Calico、Contiv、Contrail、Flannel、Weave net 等网络插件用于嵌入和已注册的 Kubernetes?
|
||||
|
||||
Rancher 开箱即用地为 Kubernetes 集群提供了几个 CNI 网络插件,分别是 Canal、Flannel、Calico 和 Weave。有关官方支持的详细信息,请参阅 [Rancher 支持矩阵](https://rancher.com/support-maintenance-terms/)。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 是否计划支持 Traefik?**
|
||||
## Rancher 是否计划支持 Traefik?
|
||||
|
||||
目前,我们不打算提供嵌入式 Traefik 支持,但我们仍在探索负载均衡方案。
|
||||
|
||||
<br/>
|
||||
|
||||
**我可以将 OpenShift Kubernetes 集群导入 2.x 吗?**
|
||||
## 我可以将 OpenShift Kubernetes 集群导入 2.x 吗?
|
||||
|
||||
我们的目标是运行任何上游 Kubernetes 集群。因此,Rancher 2.x 应该可以与 OpenShift 一起使用,但我们尚未对此进行测试。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher 会集成 Longhorn 吗?**
|
||||
## Rancher 会集成 Longhorn 吗?
|
||||
|
||||
是的。Longhorn 已集成到 Rancher 2.5+ 中。
|
||||
|
||||
+21
-11
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 在离线环境中渲染 Helm 模板
|
||||
title: 在离线环境中升级
|
||||
---
|
||||
|
||||
:::note
|
||||
@@ -35,6 +35,26 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
#### 解决 UPGRADE FAILED 错误
|
||||
|
||||
如果你遇到错误消息 `Error: UPGRADE FAILED: "rancher" has no deployed releases`,Rancher 可能是通过 `helm template` 命令安装的。要成功升级 Rancher,请改用以下命令:
|
||||
|
||||
```
|
||||
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--no-hooks \ # prevent files for Helm hooks from being generated
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set certmanager.version=<CERTMANAGER_VERSION> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
执行 Helm 命令后,需要应用渲染后的模板:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system apply -R -f ./rancher
|
||||
```
|
||||
### 选项 B:使用 Kubernetes 密文从文件中获取证书
|
||||
|
||||
```plain
|
||||
@@ -62,16 +82,6 @@ helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
### 应用已渲染的模板
|
||||
|
||||
将渲染的 manifest 目录复制到可以访问 Rancher Server 集群的系统中,并应用渲染的模板。
|
||||
|
||||
使用 `kubectl` 来应用渲染的 manifest。
|
||||
|
||||
```plain
|
||||
kubectl -n cattle-system apply -R -f ./rancher
|
||||
```
|
||||
|
||||
## 验证升级
|
||||
|
||||
登录 Rancher 以确认升级成功。
|
||||
|
||||
+351
@@ -0,0 +1,351 @@
|
||||
---
|
||||
title: 在 Kubernetes 集群上安装/升级 Rancher
|
||||
description: 了解如何在开发和生产环境中安装 Rancher。了解单节点和高可用安装
|
||||
---
|
||||
|
||||
在本节中,你将学习如何使用 Helm CLI 在 Kubernetes 集群上部署 Rancher。
|
||||
|
||||
|
||||
## 先决条件
|
||||
|
||||
- [Kubernetes 集群](#kubernetes-集群)
|
||||
- [Ingress Controller](#ingress-controller)
|
||||
- [CLI 工具](#cli-工具)
|
||||
|
||||
### Kubernetes 集群
|
||||
|
||||
设置 Rancher Server 的本地 Kubernetes 集群。
|
||||
|
||||
Rancher 可以安装在任何 Kubernetes 集群上。这个集群可以使用上游 Kubernetes,也可以使用 Rancher 的 Kubernetes 发行版之一,也可以是来自 Amazon EKS 等提供商的托管 Kubernetes 集群。
|
||||
|
||||
你可参考以下教程,以获得设置 Kubernetes 集群的帮助:
|
||||
|
||||
- **RKE**:[安装 RKE Kubernetes 集群的教程](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/rke1-for-rancher.md);[为高可用 RKE 集群设置基础设施的教程](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-rke1-kubernetes-cluster.md)。
|
||||
- **K3s**:[安装 K3s Kubernetes 集群的教程](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/k3s-for-rancher.md);[设置高可用 K3s 集群的基础设施的教程](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-k3s-kubernetes-cluster.md)。
|
||||
- **RKE2:** :[安装 RKE2 Kubernetes 集群的教程](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/rke2-for-rancher.md);[设置高可用 RKE2 集群的基础设施的教程](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-rke2-kubernetes-cluster.md)。
|
||||
- **Amazon EKS**:[在 Amazon EKS 上安装 Rancher 以及如何安装 Ingress Controller 以访问 Rancher Server](rancher-on-amazon-eks.md)。
|
||||
- **AKS**:[使用 Azure Kubernetes 服务安装 Rancher 以及如何安装 Ingress Controller 以访问 Rancher Server](rancher-on-aks.md)。
|
||||
- **GKE**:有关如何使用 GKE 安装 Rancher,包括如何安装 Ingress Controller 以便可以访问 Rancher Server,请参阅[此页面](rancher-on-gke.md)。GKE 创建 Kubernetes 集群时有两种运行模式,分别是 Autopilot 和 Standard 模式。Autopilot 模式的集群配置对编辑 kube-system 命名空间有限制。但是,Rancher 在安装时需要在 kube-system 命名空间中创建资源。因此,你将无法在以 Autopilot 模式创建的 GKE 集群上安装 Rancher。
|
||||
|
||||
|
||||
### Ingress Controller
|
||||
|
||||
Rancher UI 和 API 通过 Ingress 公开。换言之,安装 Rancher 的 Kubernetes 集群必须包含一个 Ingress Controller。
|
||||
|
||||
对于 RKE、RKE2 和 K3s,你不需要手动安装 Ingress Controller,因为它是默认安装的。
|
||||
|
||||
对于默认不包含 Ingress Controller 的发行版(例如 EKS、GKE 或 AKS 等托管 Kubernetes 集群),你必须先部署 Ingress Controller。请注意,Rancher Helm Chart 默认情况下不会在 Ingress 上设置 `ingressClassName`。因此,你必须将 Ingress Controller 配置为在没有 `ingressClassName` 的情况下也可以监视 Ingress。
|
||||
|
||||
上面的 **Amazon EKS**、**AKS** 和 **GKE** 教程中包含了示例。
|
||||
|
||||
### CLI 工具
|
||||
|
||||
设置 Kubernetes 集群需要以下 CLI 工具。请确保这些工具已安装并在你的 `$PATH` 中可用。
|
||||
|
||||
- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes 命令行工具。
|
||||
- [Helm](https://docs.helm.sh/using_helm/#installing-helm) - Kubernetes 的包管理器。请参见 [Helm 版本要求](../resources/helm-version-requirements.md)选择 Helm 版本来安装 Rancher。请为你的具体平台参见 [Helm 项目提供的说明](https://helm.sh/docs/intro/install/)。
|
||||
|
||||
## 安装 Rancher Helm Chart
|
||||
|
||||
Rancher 是使用 Kubernetes 的 [Helm](https://helm.sh/) 包管理器安装的。Helm Chart 为 Kubernetes YAML 清单文件提供了模板语法。通过 Helm,用户可以创建可配置的 deployment,而不仅仅只能使用静态文件。
|
||||
|
||||
如果系统无法直接访问互联网,请参见[离线环境:Kubernetes 安装](../other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md)。
|
||||
|
||||
如果要指定安装的 Rancher 版本,请参见[选择 Rancher 版本](../resources/choose-a-rancher-version.md)。
|
||||
|
||||
如果要指定用于安装 Rancher 的 Helm 版本,请参见[Helm 版本要求](../resources/helm-version-requirements.md)。
|
||||
|
||||
:::note
|
||||
|
||||
本安装指南假定你使用的是 Helm 3。
|
||||
|
||||
:::
|
||||
|
||||
要设置 Rancher:
|
||||
|
||||
1. [添加 Helm Chart 仓库](#1-添加-helm-chart-仓库)
|
||||
2. [为 Rancher 创建命名空间](#2-为-rancher-创建命名空间)
|
||||
3. [选择 SSL 配置](#3-选择-ssl-配置)
|
||||
4. [安装 cert-manager](#4-安装-cert-manager)(除非你自带证书,否则 TLS 将在负载均衡器上终止)
|
||||
5. [使用 Helm 和你选择的证书选项安装 Rancher](#5-根据你选择的证书选项通过-helm-安装-rancher)
|
||||
6. [验证 Rancher Server 是否部署成功](#6-验证-rancher-server-是否部署成功)
|
||||
7. [保存选项](#7-保存选项)
|
||||
|
||||
### 1. 添加 Helm Chart 仓库
|
||||
|
||||
执行 `helm repo add` 命令,以添加包含安装 Rancher 的 Chart 的 Helm Chart 仓库。有关如何选择仓库,以及哪个仓库最适合你的用例,请参见[选择 Rancher 版本](../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md)。
|
||||
|
||||
- Latest:建议用于试用最新功能
|
||||
```
|
||||
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
|
||||
```
|
||||
- Stable:建议用于生产环境
|
||||
```
|
||||
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
|
||||
```
|
||||
- Alpha:即将发布的实验性预览。
|
||||
```
|
||||
helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
|
||||
```
|
||||
注意:不支持升级到 Alpha 版、从 Alpha 版升级或在 Alpha 版之间升级。
|
||||
|
||||
### 2. 为 Rancher 创建命名空间
|
||||
|
||||
你需要定义一个 Kubernetes 命名空间,用于安装由 Chart 创建的资源。这个命名空间的名称为 `cattle-system`:
|
||||
|
||||
```
|
||||
kubectl create namespace cattle-system
|
||||
```
|
||||
|
||||
### 3. 选择 SSL 配置
|
||||
|
||||
Rancher Management Server 默认需要 SSL/TLS 配置来保证访问的安全性。
|
||||
|
||||
:::note
|
||||
|
||||
如果你想在外部终止 SSL/TLS,请参见[外部负载均衡器的 TLS 终止](../getting-started/installation-and-upgrade/installation-references/helm-chart-options.md#外部-tls-终止)。
|
||||
|
||||
:::
|
||||
|
||||
你可以从以下三种证书来源中选择一种,用于在 Rancher Server 中终止 TLS:
|
||||
|
||||
- **Rancher 生成的 TLS 证书**:要求你在集群中安装 `cert-manager`。Rancher 使用 `cert-manager` 签发并维护证书。Rancher 会生成自己的 CA 证书,并使用该 CA 签署证书。然后 `cert-manager`负责管理该证书。
|
||||
- **Let's Encrypt**:Let's Encrypt 选项也需要使用 `cert-manager`。但是,在这种情况下,cert-manager 与 Let's Encrypt 的特殊颁发者相结合,该颁发者执行获取 Let's Encrypt 颁发的证书所需的所有操作(包括请求和验证)。此配置使用 HTTP 验证(`HTTP-01`),因此负载均衡器必须具有可以从互联网访问的公共 DNS 记录。
|
||||
- **你已有的证书**:使用已有的 CA 颁发的公有或私有证书。Rancher 将使用该证书来保护 WebSocket 和 HTTPS 流量。在这种情况下,你必须上传名称分别为 `tls.crt` 和 `tls.key`的 PEM 格式的证书以及相关的密钥。如果你使用私有 CA,则还必须上传该 CA 证书。这是由于你的节点可能不信任此私有 CA。Rancher 将获取该 CA 证书,并从中生成一个校验和,各种 Rancher 组件将使用该校验和来验证其与 Rancher 的连接。
|
||||
|
||||
|
||||
| 配置 | Helm Chart 选项 | 是否需要 cert-manager |
|
||||
| ------------------------------ | ----------------------- | ------------------------------------- |
|
||||
| Rancher 生成的证书(默认) | `ingress.tls.source=rancher` | [是](#4-安装-cert-manager) |
|
||||
| Let’s Encrypt | `ingress.tls.source=letsEncrypt` | [是](#4-安装-cert-manager) |
|
||||
| 你已有的证书 | `ingress.tls.source=secret` | 否 |
|
||||
|
||||
### 4. 安装 cert-manager
|
||||
|
||||
> 如果你使用自己的证书文件(`ingress.tls.source=secret`)或使用[外部负载均衡器的 TLS 终止](../installation-references/helm-chart-options.md#外部-tls-终止),你可以跳过此步骤。
|
||||
|
||||
仅在使用 Rancher 生成的证书(`ingress.tls.source=rancher`)或 Let's Encrypt 颁发的证书(`ingress.tls.source=letsEncrypt`)时,才需要安装 cert-manager。
|
||||
|
||||
<details id="cert-manager">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
由于 cert-manager 的最新改动,你需要升级 cert-manager 版本。如果你需要升级 Rancher 并使用低于 0.11.0 的 cert-manager 版本,请参见[升级文档](../resources/upgrade-cert-manager.md)。
|
||||
|
||||
:::
|
||||
|
||||
这些说明来自 [cert-manager 官方文档](https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm)。
|
||||
|
||||
:::note
|
||||
|
||||
要查看自定义 cert-manager 安装的选项(包括集群使用 PodSecurityPolicies 的情况),请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
# 如果你手动安装了CRD,而不是在 Helm 安装命令中添加了 `--set installCRDs=true` 选项,你应该在升级 Helm Chart 之前升级 CRD 资源。
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
# 添加 Jetstack Helm 仓库
|
||||
helm repo add jetstack https://charts.jetstack.io
|
||||
|
||||
# 更新本地 Helm Chart 仓库缓存
|
||||
helm repo update
|
||||
|
||||
# 安装 cert-manager Helm Chart
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
安装完 cert-manager 后,你可以通过检查 cert-manager 命名空间中正在运行的 Pod 来验证它是否已正确部署:
|
||||
|
||||
```
|
||||
kubectl get pods --namespace cert-manager
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cert-manager-5c6866597-zw7kh 1/1 Running 0 2m
|
||||
cert-manager-cainjector-577f6d9fd7-tr77l 1/1 Running 0 2m
|
||||
cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 5. 根据你选择的证书选项,通过 Helm 安装 Rancher
|
||||
|
||||
不同的证书配置需要使用不同的 Rancher 安装命令。
|
||||
|
||||
但是,无论证书如何配置,Rancher 在 `cattle-system` 命名空间中的安装名称应该总是 `rancher`。
|
||||
|
||||
:::tip 测试和开发:
|
||||
|
||||
这个安装 Rancher 的最终命令需要一个将流量转发到 Rancher 的域名。如果你使用 Helm CLI 设置概念证明,则可以在传入 `hostname` 选项时使用伪域名。伪域名的一个例子是 `<IP_OF_LINUX_NODE>.sslip.io`,这会把 Rancher 暴露在它运行的 IP 上。生产安装中要求填写真实的域名。
|
||||
|
||||
:::
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher 生成的证书">
|
||||
|
||||
默认情况是使用 Rancher 生成 CA,并使用 `cert-manager` 颁发用于访问 Rancher Server 接口的证书。
|
||||
|
||||
由于 `rancher` 是 `ingress.tls.source` 的默认选项,因此在执行 `helm install` 命令时,我们不需要指定 `ingress.tls.source`。
|
||||
|
||||
- 将 `hostname` 设置为解析到你的负载均衡器的 DNS 名称。
|
||||
- 将 `bootstrapPassword` 设置为 `admin` 用户独有的值。
|
||||
- 如果你需要安装指定的 Rancher 版本,使用 `--version` 标志,例如 `--version 2.7.0`。
|
||||
- 对于 Kubernetes v1.25 或更高版本,使用 Rancher v2.7.2-v2.7.4 时,将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说,这不是必需的,但你仍然可以手动设置该选项。
|
||||
|
||||
```
|
||||
helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org \
|
||||
--set bootstrapPassword=admin
|
||||
```
|
||||
|
||||
如果你安装的是 alpha 版本,Helm 会要求你在安装命令中添加 `--devel` 选项:
|
||||
|
||||
```
|
||||
helm install rancher rancher-alpha/rancher --devel
|
||||
```
|
||||
|
||||
等待 Rancher 运行:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system rollout status deploy/rancher
|
||||
Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
|
||||
deployment "rancher" successfully rolled out
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Let's Encrypt">
|
||||
|
||||
此选项使用 `cert-manager` 来自动请求和续订 [Let's Encrypt](https://letsencrypt.org/) 证书。Let's Encrypt 是免费的,而且是受信的 CA,因此可以为你提供有效的证书。
|
||||
|
||||
:::note
|
||||
|
||||
由于 HTTP-01 质询只能在端口 80 上完成,因此你需要打开端口 80。
|
||||
|
||||
:::
|
||||
|
||||
在以下命令中,
|
||||
|
||||
- 将 `hostname` 设置为公有 DNS 记录。
|
||||
- 将 `bootstrapPassword` 设置为 `admin` 用户独有的值。
|
||||
- 将 `ingress.tls.source` 设置为 `letsEncrypt`。
|
||||
- 将 `letsEncrypt.email` 设置为可通讯的电子邮件地址,用于发送通知(例如证书到期的通知)。
|
||||
- 将 `letsEncrypt.ingress.class` 设为你的 Ingress Controller(例如 `traefik`,`nginx`,`haproxy`)
|
||||
- 对于 Kubernetes v1.25 或更高版本,使用 Rancher v2.7.2-v2.7.4 时,将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说,这不是必需的,但你仍然可以手动设置该选项。
|
||||
|
||||
```
|
||||
helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org \
|
||||
--set bootstrapPassword=admin \
|
||||
--set ingress.tls.source=letsEncrypt \
|
||||
--set letsEncrypt.email=me@example.org \
|
||||
--set letsEncrypt.ingress.class=nginx
|
||||
```
|
||||
|
||||
如果你安装的是 alpha 版本,Helm 会要求你在安装命令中添加 `--devel` 选项:
|
||||
|
||||
```
|
||||
helm install rancher rancher-alpha/rancher --devel
|
||||
```
|
||||
|
||||
等待 Rancher 运行:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system rollout status deploy/rancher
|
||||
Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
|
||||
deployment "rancher" successfully rolled out
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="证书文件">
|
||||
在此选项中,你使用你自己的证书来创建 Kubernetes 密文,以供 Rancher 使用。
|
||||
|
||||
运行这个命令时,`hostname` 选项必须与服务器证书中的 `Common Name` 或 `Subject Alternative Names` 条目匹配,否则 Ingress controller 将无法正确配置。
|
||||
|
||||
虽然技术上仅需要 `Subject Alternative Names` 中有一个条目,但是拥有一个匹配的 `Common Name` 可以最大程度地提高与旧版浏览器/应用的兼容性。
|
||||
|
||||
:::note
|
||||
|
||||
如果你想检查证书是否正确,请查看[如何在服务器证书中检查 Common Name 和 Subject Alternative Names](../../../faq/technical-items.md#如何在服务器证书中检查-common-name-和-subject-alternative-names)。
|
||||
|
||||
:::
|
||||
|
||||
- 设置 `hostname`。
|
||||
- 将 `bootstrapPassword` 设置为 `admin` 用户独有的值。
|
||||
- 将 `ingress.tls.source` 设置为 `secret`。
|
||||
- 对于 Kubernetes v1.25 或更高版本,使用 Rancher v2.7.2-v2.7.4 时,将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说,这不是必需的,但你仍然可以手动设置该选项。
|
||||
|
||||
```
|
||||
helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org \
|
||||
--set bootstrapPassword=admin \
|
||||
--set ingress.tls.source=secret
|
||||
```
|
||||
如果你安装的是 alpha 版本,Helm 会要求你在安装命令中添加 `--devel` 选项:
|
||||
|
||||
```
|
||||
helm install rancher rancher-alpha/rancher --devel
|
||||
```
|
||||
|
||||
如果你使用的是私有 CA 证书,请在命令中增加 `--set privateCA=true`。
|
||||
|
||||
```
|
||||
helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org \
|
||||
--set bootstrapPassword=admin \
|
||||
--set ingress.tls.source=secret \
|
||||
--set privateCA=true
|
||||
```
|
||||
|
||||
**添加 TLS 密文(千万不要遗漏此步骤)**:现在 Rancher 已经完成部署,你还需要参考[添加 TLS 密文](../resources/add-tls-secrets.md)发布证书文件,以便 Rancher 和 Ingress Controller 可以使用它们。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
Rancher Chart 有许多选项,用于为你的具体环境自定义安装。以下是一些常见的高级方案:
|
||||
|
||||
- [HTTP 代理](../installation-references/helm-chart-options.md#http-代理)
|
||||
- [私有容器镜像仓库](../installation-references/helm-chart-options.md#私有仓库和离线安装)
|
||||
- [外部负载均衡器上的 TLS 终止](../installation-references/helm-chart-options.md#外部-tls-终止)
|
||||
|
||||
如需获取完整的选项列表,请参见 [Chart 选项](../installation-references/helm-chart-options.md)。
|
||||
|
||||
|
||||
### 6. 验证 Rancher Server 是否部署成功
|
||||
|
||||
添加密文后,检查 Rancher 是否已成功运行:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system rollout status deploy/rancher
|
||||
Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
|
||||
deployment "rancher" successfully rolled out
|
||||
```
|
||||
|
||||
如果你看到 `error: deployment "rancher" exceeded its progress deadline` 这个错误,可运行以下命令来检查 deployment 的状态:
|
||||
|
||||
```
|
||||
kubectl -n cattle-system get deploy rancher
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
rancher 3 3 3 3 3m
|
||||
```
|
||||
|
||||
`DESIRED` 和 `AVAILABLE`的个数应该相同。
|
||||
|
||||
### 7. 保存选项
|
||||
|
||||
请保存你使用的 `--set` 选项。使用 Helm 升级 Rancher 到新版本时,你将需要使用相同的选项。
|
||||
|
||||
### 安装完成
|
||||
|
||||
安装已完成。现在 Rancher Server 应该已经可以正常运行了。
|
||||
|
||||
使用浏览器打开把流量转发到你的负载均衡器的 DNS 域名。然后,你就会看到一个漂亮的登录页面了。
|
||||
|
||||
如果遇到任何问题,请参见[故障排除](troubleshooting.md)。
|
||||
+4
-4
@@ -6,7 +6,7 @@ title: 在 Azure Kubernetes Service 上安装 Rancher
|
||||
|
||||
本指南使用命令行工具来配置一个带有 Ingress 的 AKS 集群。如果你更喜欢使用 Azure 门户来配置集群,请参见[官方文档](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal)。
|
||||
|
||||
如果你已有一个 AKS Kubernetes 集群,请直接跳到[安装 Ingress](#5-安装-ingress) 的步骤,然后按照[此页](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。
|
||||
如果你已有一个 AKS Kubernetes 集群,请直接跳到[安装 Ingress](#5-安装-ingress) 的步骤,然后按照[此页](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。
|
||||
|
||||
## 先决条件
|
||||
|
||||
@@ -19,7 +19,7 @@ title: 在 Azure Kubernetes Service 上安装 Rancher
|
||||
- [Microsoft Azure 账号](https://azure.microsoft.com/en-us/free/):用于创建部署 Rancher 和 Kubernetes 的资源。
|
||||
- [Microsoft Azure 订阅](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal):如果你没有的话,请访问此链接查看如何创建 Microsoft Azure 订阅。
|
||||
- [Micsoroft Azure 租户](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant):访问此链接并参考教程以创建 Microsoft Azure 租户。
|
||||
- 你的订阅有足够的配额,至少有 2 个 vCPU。有关 Rancher Server 资源要求的详情,请参见[此节](../../../pages-for-subheaders/installation-requirements.md#rke-和托管-kubernetes)。
|
||||
- 你的订阅有足够的配额,至少有 2 个 vCPU。有关 Rancher Server 资源要求的详情,请参见[此节](../installation-requirements/installation-requirements.md)。
|
||||
- 在 Azure 中用 Helm 安装 Rancher 时,请使用 L7 负载均衡器来避免网络问题。详情请参见 [Azure 负载均衡器限制](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations)。
|
||||
|
||||
## 1. 准备你的工作站
|
||||
@@ -134,7 +134,7 @@ ingress-nginx-controller LoadBalancer 10.0.116.18 40.31.180.83 80:31229
|
||||
|
||||
## 8. 安装 Rancher Helm Chart
|
||||
|
||||
按照[本页](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。任何 Kubernetes 发行版上安装的 Rancher 的 Helm 说明都是一样的。
|
||||
按照[本页](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。任何 Kubernetes 发行版上安装的 Rancher 的 Helm 说明都是一样的。
|
||||
|
||||
安装 Rancher 时,使用上一步获取的 DNS 名称作为 Rancher Server 的 URL。它可以作为 Helm 选项传递进来。例如,如果 DNS 名称是 `rancher.my.org`,你需要使用 `--set hostname=rancher.my.org` 选项来运行 Helm 安装命令。
|
||||
|
||||
@@ -144,4 +144,4 @@ ingress-nginx-controller LoadBalancer 10.0.116.18 40.31.180.83 80:31229
|
||||
--set ingress.ingressClassName=nginx
|
||||
```
|
||||
|
||||
请参阅[Helm 安装命令](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
请参阅[Helm 安装命令](install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
|
||||
+3
-3
@@ -4,7 +4,7 @@ title: 在 Amazon EKS 上安装 Rancher
|
||||
|
||||
本文介绍了如何在 Amazon EKS 集群上安装 Rancher。你也可以[通过 AWS Marketplace 安装 Rancher](../../quick-start-guides/deploy-rancher-manager/aws-marketplace.md)。
|
||||
|
||||
如果你已经有一个 EKS Kubernetes 集群,请直接跳转到[安装 Ingress](#5-安装-ingress)这个步骤。然后按照[此处](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
|
||||
如果你已经有一个 EKS Kubernetes 集群,请直接跳转到[安装 Ingress](#5-安装-ingress)这个步骤。然后按照[此处](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
|
||||
|
||||
## 为 Rancher Server 创建 EKS 集群
|
||||
|
||||
@@ -138,7 +138,7 @@ ingress-nginx-controller LoadBalancer 10.100.90.18 a904a952c73bf4f668a17c4
|
||||
|
||||
### 8. 安装 Rancher Helm Chart
|
||||
|
||||
按照[本页](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。任何 Kubernetes 发行版上安装的 Rancher 的 Helm 说明都是一样的。
|
||||
按照[本页](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。任何 Kubernetes 发行版上安装的 Rancher 的 Helm 说明都是一样的。
|
||||
|
||||
安装 Rancher 时,使用上一步获取的 DNS 名称作为 Rancher Server 的 URL。它可以作为 Helm 选项传递进来。例如,如果 DNS 名称是 `rancher.my.org`,你需要使用 `--set hostname=rancher.my.org` 选项来运行 Helm 安装命令。
|
||||
|
||||
@@ -148,4 +148,4 @@ ingress-nginx-controller LoadBalancer 10.100.90.18 a904a952c73bf4f668a17c4
|
||||
--set ingress.ingressClassName=nginx
|
||||
```
|
||||
|
||||
请参阅[Helm 安装命令](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
请参阅[Helm 安装命令](install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
|
||||
+3
-3
@@ -4,13 +4,13 @@ title: 在 GKE 集群上安装 Rancher
|
||||
|
||||
在本节中,你将学习如何使用 GKE 安装 Rancher。
|
||||
|
||||
如果你已经有一个 GKE Kubernetes 集群,请直接跳转到[安装 Ingress](#7-安装-ingress)这个步骤。然后按照[此处](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
|
||||
如果你已经有一个 GKE Kubernetes 集群,请直接跳转到[安装 Ingress](#7-安装-ingress)这个步骤。然后按照[此处](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
|
||||
|
||||
## 先决条件
|
||||
|
||||
- 你需要有一个 Google 账号。
|
||||
- 你需要有一个 Google Cloud Billing 账号。你可使用 Google Cloud Console 来管理你的 Cloud Billing 账号。有关 Cloud Console 的详情,请参见 [ Console 通用指南](https://support.google.com/cloud/answer/3465889?hl=en&ref_topic=3340599)。
|
||||
- 你需要至少一个在用的 IP 地址和至少 2 个 CPU 的云配额。有关 Rancher Server 的硬件要求,请参见[本节](../../../pages-for-subheaders/installation-requirements.md#rke-和托管-kubernetes)。
|
||||
- 你需要至少一个在用的 IP 地址和至少 2 个 CPU 的云配额。有关 Rancher Server 的硬件要求,请参见[本节](../installation-requirements/installation-requirements.md)。
|
||||
|
||||
## 1. 启用 Kubernetes Engine API
|
||||
|
||||
@@ -190,7 +190,7 @@ ingress-nginx-controller LoadBalancer 10.3.244.156 35.233.206.34 80:3187
|
||||
--set ingress.ingressClassName=nginx
|
||||
```
|
||||
|
||||
请参阅[Helm 安装命令](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
请参阅[Helm 安装命令](install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
|
||||
在 Rancher v2.7.5 中,如果你打算在集群上使用默认的 GKE Ingress 而不启用 VPC 原生的集群模式,则需要设置以下标志:
|
||||
|
||||
|
||||
+38
-12
@@ -2,16 +2,37 @@
|
||||
title: 回滚
|
||||
---
|
||||
|
||||
## 使用 Rancher 2.6.4+ 进行回滚的其他步骤
|
||||
本页概述了如何在升级 Rancher 后将 Rancher 回滚到之前的版本。
|
||||
|
||||
请在以下情况时按照本页的说明进行操作:
|
||||
- 正在运行的 Rancher 实例在备份完成后升级到了更新的版本。
|
||||
- 上游(本地)集群与进行备份的集群相同。
|
||||
|
||||
:::tip
|
||||
|
||||
* [请参阅这些步骤来迁移 Rancher](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md).
|
||||
* 如果你需要还原 Rancher 到同一版本的之前的状态, 请参阅[还原 Rancher](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher.md).
|
||||
|
||||
:::
|
||||
|
||||
## 特殊场景下的操作
|
||||
|
||||
在以下场景中需要执行替代步骤来进行回滚:
|
||||
- 从 v2.6.4 及更高版本回滚到 v2.6.x 的早期版本。
|
||||
- 从 v2.7.7 及更高版本回滚到 v2.7.x 的早期版本。
|
||||
|
||||
Rancher v2.6.4 将 cluster-api 模块从 v0.4.4 升级到 v1.0.2。反过来,cluster-api 的 v1.0.2 版本将集群 API 的自定义资源定义 (CRD) 从 `cluster.x-k8s.io/v1alpha4` 升级到 `cluster.x-k8s.io/v1beta1`。当你尝试将 Rancher v2.6.4 回滚到以前版本的 Rancher v2.6.x 时,CRD 升级到 v1beta1 会导致回滚失败。这是因为使用旧 apiVersion (v1alpha4) 的 CRD 与 v1beta1 不兼容。
|
||||
|
||||
要避免回滚失败,你需要在尝试恢复操作或回滚**之前**运行以下 Rancher 脚本:
|
||||
在 Rancher v2.7.7 版本中,应用 `rancher-provisioning-capi` 会自动安装在上游(本地)集群上,来替代嵌入的 cluster-api 控制器。 如果上游集群同时包含该应用和 Rancher v2.7.6 及更早版本,则会发生冲突和意外错误。 因此,如果你尝试从 Rancher v2.7.7 回滚到 Rancher v2.7.x 的任何早期版本,需要执行替代的步骤。
|
||||
|
||||
### 步骤 1: 清理上游(本地)集群
|
||||
|
||||
要避免回滚失败,你需要在尝试恢复操作或回滚**之前**根据该[说明](https://github.com/rancher/rancher-cleanup/blob/main/README.md)运行以下 Rancher 脚本:
|
||||
|
||||
|
||||
* `verify.sh`:检查集群中是否有任何与 Rancher 相关的资源。
|
||||
* `cleanup.sh`:清理集群。
|
||||
* `verify.sh`:检查集群中是否有任何与 Rancher 相关的资源。
|
||||
|
||||
有关详细信息和源代码,请参阅 [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup)。
|
||||
|
||||
:::caution
|
||||
|
||||
@@ -19,12 +40,17 @@ Rancher v2.6.4 将 cluster-api 模块从 v0.4.4 升级到 v1.0.2。反过来,c
|
||||
|
||||
:::
|
||||
|
||||
### 从 v2.6.4+ 回滚到较低版本的 v2.6.x
|
||||
**结果:** 上游(本地)集群中所有 Rancher 关联的资源将被清理。
|
||||
|
||||
1. 按照[说明](https://github.com/rancher/rancher-cleanup/blob/main/README.md)运行脚本。
|
||||
1. 按照[说明](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)在现有集群上安装 rancher-backup Helm Chart 并恢复之前的状态。
|
||||
1. 省略步骤 3。
|
||||
1. 执行到步骤 4 时,在要回滚到的 local 集群上安装 Rancher 2.6.x 版本。
|
||||
请参阅 [rancher/rancher-cleanup 仓库](https://github.com/rancher/rancher-cleanup) 以获取更多细节和源码。
|
||||
|
||||
### 步骤 2: 还原备份并启动 Rancher
|
||||
|
||||
此时上游集群上应该已经没有 Rancher 相关的资源了。 因此,下一步与将 Rancher 迁移到不包含 Rancher 资源的新集群相同。
|
||||
|
||||
按照[说明](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)安装 Rancher-Backup Helm Chart 并恢复 Rancher 到之前的状态。请记住:
|
||||
1. 步骤 3 可以跳过,因为之前安装的 Cert-Manager 应用应该还在上游(本地)集群中。
|
||||
2. 执行到步骤 4 时,在要回滚到的 local 集群上安装你需要的 Rancher 版本。
|
||||
|
||||
## 回滚到 Rancher 2.5.0+
|
||||
|
||||
@@ -42,14 +68,14 @@ Rancher v2.6.4 将 cluster-api 模块从 v0.4.4 升级到 v1.0.2。反过来,c
|
||||
|
||||
:::
|
||||
|
||||
### 创建 Restore 自定义资源
|
||||
### 步骤 1 :创建 Restore 自定义资源
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 找到你的本地集群,并点击 **Explore**。
|
||||
1. 在左侧导航栏中,点击 **Rancher 备份 > 还原**。
|
||||
:::note
|
||||
|
||||
如果 Rancher Backups 应用不可见,你需要到 **Apps** 的 Charts 页面中安装应用。详情请参见[此处](../../../pages-for-subheaders/helm-charts-in-rancher.md#charts)。
|
||||
如果 Rancher Backups 应用不可见,你需要到 **Apps** 的 Charts 页面中安装应用。详情请参见[此处](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#access-charts)。
|
||||
|
||||
:::
|
||||
|
||||
@@ -91,7 +117,7 @@ kubectl get pods -n cattle-resources-system
|
||||
kubectl logs -n cattle-resources-system -f
|
||||
```
|
||||
|
||||
### 回滚到上一个 Rancher 版本
|
||||
### 步骤 2:回滚到上一个 Rancher 版本
|
||||
|
||||
你可以使用 Helm CLI 回滚 Rancher。要回滚到上一个版本:
|
||||
|
||||
|
||||
+4
-2
@@ -28,11 +28,13 @@ kubeconfig 也可以通过 `--kubeconfig` 标签(详情请参见 https://helm.
|
||||
|
||||
本安装指南假定你使用的是 Helm 3。
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
如果你使用 Helm 2,请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。如果你不能升级到 Helm 3,[Helm 2 升级页面](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)提供了使用 Helm 2 升级的旧升级指南。
|
||||
|
||||
### 离线安装:推送镜像到私有镜像仓库
|
||||
|
||||
[仅适用于离线安装](../../../pages-for-subheaders/air-gapped-helm-cli-install.md):为新的 Rancher Server 版本收集和推送镜像。使用你需要针对 Rancher 版本升级的镜像,按照步骤[推送镜像到私有镜像仓库](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md)。
|
||||
[仅适用于离线安装](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md):为新的 Rancher Server 版本收集和推送镜像。使用你需要针对 Rancher 版本升级的镜像,按照步骤[推送镜像到私有镜像仓库](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md)。
|
||||
|
||||
### 使用 cert-manager 0.8.0 之前的版本升级
|
||||
|
||||
@@ -59,7 +61,7 @@ kubeconfig 也可以通过 `--kubeconfig` 标签(详情请参见 https://helm.
|
||||
|
||||
1. 获取你用来安装 Rancher 的仓库名称。
|
||||
|
||||
关于仓库及其区别,请参见 [Helm Chart Repositories](../resources/choose-a-rancher-version.md#helm-chart-仓库)。
|
||||
关于仓库及其区别,请参见 [Helm Chart 仓库](../resources/choose-a-rancher-version.md#helm-chart-仓库)。
|
||||
|
||||
- Latest:建议用于试用最新功能
|
||||
```
|
||||
|
||||
+94
@@ -0,0 +1,94 @@
|
||||
---
|
||||
title: 安装/升级 Rancher
|
||||
description: 了解如何在开发和生产环境中安装 Rancher。了解单节点和高可用安装
|
||||
---
|
||||
|
||||
本节介绍了 Rancher 各种安装方式以及每个安装方式的优点。
|
||||
|
||||
## 名词解释
|
||||
|
||||
本章节涉及以下名词:
|
||||
|
||||
- **Rancher Server**:用于管理和配置 Kubernetes 集群。你可以通过 Rancher Server 的 UI 与下游 Kubernetes 集群进行交互。Rancher Management Server 可以安装到任意 Kubernetes 集群上,包括托管的集群,如 Amazon EKS 集群。
|
||||
- **RKE(Rancher Kubernetes Engine)**:是经过认证的 Kubernetes 发行版,也是用于创建和管理 Kubernetes 集群的 CLI 工具和库。
|
||||
- **K3s(轻量级 Kubernetes)**:也是经过认证的 Kubernetes 发行版。它比 RKE 更新,更易用且更轻量,其所有组件都在一个小于 100 MB 的二进制文件中。
|
||||
- **RKE2**:一个完全合规的 Kubernetes 发行版,专注于安全和合规性。
|
||||
|
||||
`restrictedAdmin` Helm Chart 选项在 **Rancher Server** 可用。如果该选项设置为 true,初始的 Rancher 用户访问本地 Kubernetes 集群会受到限制,以避免权限升级。详情请参见 [restricted-admin 角色](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#受限管理员)。
|
||||
|
||||
## 安装方式概述
|
||||
|
||||
Rancher 可以安装在以下主要架构上:
|
||||
|
||||
### 使用 Helm CLI 安装的高可用 Kubernetes
|
||||
|
||||
我们建议使用 Kubernetes 包管理器 Helm 在专用的 Kubernetes 集群上安装 Rancher。在 RKE 集群中,需要使用三个节点才能实现高可用集群。在 K3s 集群中,只需要两个节点即可。
|
||||
|
||||
### 通过 AWS Marketplace 在 EKS 上安装 Rancher
|
||||
|
||||
你可以[通过 AWS Marketplace](../quick-start-guides/deploy-rancher-manager/aws-marketplace.md) 将 Rancher 安装到 Amazon Elastic Kubernetes Service (EKS) 上。部署的 EKS 集群已生产就绪,并遵循 AWS 最佳实践。
|
||||
|
||||
### 单节点 Kubernetes 安装
|
||||
|
||||
Rancher 可以安装在单节点 Kubernetes 集群上。但是,在单节点安装的情况下,Rancher Server 没有高可用性。而高可用性对在生产环境中运行 Rancher 非常重要。
|
||||
|
||||
但是,如果你想要短期内使用单节点节省资源,同时又保留高可用性迁移路径,那么单节点 Kubernetes 安装也是合适的。你也可以之后向集群中添加节点,获得高可用的 Rancher Server。
|
||||
|
||||
### Docker 安装
|
||||
|
||||
如果你的目的是测试或演示,你可以使用 Docker 把 Rancher 安装到单个节点中。本地 Kubernetes 集群是安装到单个 Docker 容器中的,而 Rancher 是安装到本地集群中的。
|
||||
|
||||
Rancher backup operator 可将 Rancher 从单个 Docker 容器迁移到高可用 Kubernetes 集群上。详情请参见[把 Rancher 迁移到新集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
|
||||
|
||||
### 其他方式
|
||||
|
||||
如果你需要在离线环境中或使用 HTTP 代理安装 Rancher,请参见以下独立的说明文档:
|
||||
|
||||
| 网络访问方式 | 基于 Kubernetes 安装(推荐) | 基于 Docker 安装 |
|
||||
| ---------------------------------- | ------------------------------ | ---------- |
|
||||
| 可直接访问互联网 | [文档](install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) | [文档](other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md) |
|
||||
| 使用 HTTP 代理 | [文档](other-installation-methods/rancher-behind-an-http-proxy/rancher-behind-an-http-proxy.md) | [文档](other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md)及[配置](../../reference-guides/single-node-rancher-in-docker/http-proxy-configuration.md) |
|
||||
| 离线环境 | [文档](other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) | [文档](other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) |
|
||||
|
||||
我们建议在 Kubernetes 集群上安装 Rancher,因为在多节点集群中,Rancher Server 可以实现高可用。高可用配置可以提升 Rancher 访问其管理的下游 Kubernetes 集群的稳定性。
|
||||
|
||||
因此,我们建议在生产级别的架构中,设置一个高可用的 Kubernetes 集群,然后在这个集群上安装 Rancher。安装 Rancher 后,你可以使用 Rancher 部署和管理 Kubernetes 集群。
|
||||
|
||||
如果你的目的是测试或演示,你可以将 Rancher 安装到单个 Docker 容器中。Docker 安装可以让你实现开箱即用,以使用 Rancher 设置 Kubernetes 集群。Docker 安装主要是用于探索 Rancher Server 的功能,只适用于开发和测试。
|
||||
|
||||
[在 Kubernetes 上安装 Rancher 的说明](install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)介绍了如何首先使用 K3s 或 RKE 创建和管理 Kubernetes 集群,然后再将 Rancher 安装到该集群上。
|
||||
|
||||
如果 Kubernetes 集群中的节点正在运行且满足[节点要求](installation-requirements/installation-requirements.md),你可以使用 Helm 将 Rancher 部署到 Kubernetes 上。Helm 使用 Rancher 的 Helm Chart 在 Kubernetes 集群的每个节点上安装 Rancher 的副本。我们建议使用负载均衡器将流量定向到集群中的每个 Rancher 副本上。
|
||||
|
||||
如需进一步了解 Rancher 架构,请参见[架构概述](../../reference-guides/rancher-manager-architecture/rancher-manager-architecture.md),[生产级别架构推荐](../../reference-guides/rancher-manager-architecture/architecture-recommendations.md)或[最佳实践指南](../../reference-guides/best-practices/rancher-server/tips-for-running-rancher.md)。
|
||||
|
||||
## 先决条件
|
||||
|
||||
安装 Rancher 之前,请确保你的节点满足所有[安装要求](installation-requirements/installation-requirements.md)。
|
||||
|
||||
## 架构建议
|
||||
|
||||
为了达到最佳性能和安全性,我们建议你为 Rancher Management Server 使用单独的专用 Kubernetes 集群。不建议在此集群上运行用户工作负载。部署 Rancher 后,你可以[创建或导入集群](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md)来运行你的工作负载。
|
||||
|
||||
详情请参见[架构推荐](../../reference-guides/rancher-manager-architecture/architecture-recommendations.md)。
|
||||
|
||||
### 在 Kubernetes 上安装 Rancher 的更多选项
|
||||
|
||||
参见 [Helm Chart 选项](installation-references/helm-chart-options.md)以了解在 Kubernetes 集群上安装 Rancher 的其他配置,包括:
|
||||
|
||||
- [开启 API 审计日志来记录所有事务](installation-references/helm-chart-options.md#api-审计日志)
|
||||
- [负载均衡器上的 TLS 终止](installation-references/helm-chart-options.md#外部-tls-终止)
|
||||
- [自定义 Ingress](installation-references/helm-chart-options.md#自定义-ingress)
|
||||
|
||||
在 Rancher 的安装指南中,我们推荐使用 K3s 或 RKE 来配置 Kubernetes 集群,然后再在这个集群中安装 Rancher。K3s 和 RKE 均提供许多配置选项,用于为你的具体环境自定义 Kubernetes 集群。有关选项和功能的完整列表,请参见:
|
||||
|
||||
- [RKE 配置选项](https://rancher.com/docs/rke/latest/en/config-options/)
|
||||
- [K3s 配置选项](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
|
||||
|
||||
### 在 Docker 上安装 Rancher 的更多选项
|
||||
|
||||
参见 [Docker 安装选项](other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md)了解其他配置,包括:
|
||||
|
||||
- [开启 API 审计日志来记录所有事务](../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-审计日志)
|
||||
- [外部负载均衡器](../../how-to-guides/advanced-user-guides/configure-layer-7-nginx-load-balancer.md)
|
||||
- [持久化数据存储](../../reference-guides/single-node-rancher-in-docker/advanced-options.md#持久化数据)
|
||||
+2
-2
@@ -4,7 +4,7 @@ title: 功能开关
|
||||
|
||||
使用功能开关(Feature Flag),你可以试用可选或实验性的功能并启用正在逐步淘汰的旧版功能。
|
||||
|
||||
要了解功能的值以及如何启用它们,请参阅[启用实验性功能](../../../pages-for-subheaders/enable-experimental-features.md)。
|
||||
要了解功能的值以及如何启用它们,请参阅[启用实验性功能](../../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。
|
||||
|
||||
:::note
|
||||
|
||||
@@ -16,7 +16,7 @@ title: 功能开关
|
||||
|
||||
- `continuous-delivery`:允许从 Fleet 中单独禁用 Fleet GitOps。有关详细信息,请参阅[持续交付](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md)。
|
||||
- `fleet`:v2.6 及更高版本的 Rancher 配置框架需要 Fleet。即使你在旧 Rancher 版本中禁用了该标志,该标志也将在升级时自动启用。有关详细信息,请参阅 [Fleet - GitOps at Scale](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)。
|
||||
- `harvester`:管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。有关详细信息,请参阅 [Harvester 集成](../../../integrations-in-rancher/harvester.md)。
|
||||
- `harvester`:管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。有关详细信息,请参阅 [Harvester 集成](../../../integrations-in-rancher/harvester/overview.md)。
|
||||
- `istio-virtual-service-ui`:启用[可视界面](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md)来创建、读取、更新和删除 Istio 虚拟服务和目标规则,这些都是 Istio 流量管理功能。
|
||||
- `legacy`:启用 2.5.x 及更早版本的一组功能,这些功能正逐渐被新的实现淘汰。它们是已弃用以及后续可用于新版本的功能组合。新的 Rancher 安装会默认禁用此标志。如果你从以前版本的 Rancher 升级,此标志会启用。
|
||||
- `multi-cluster-management`:允许配置和管理多个 Kubernetes 集群。此标志只能在安装时设置。后续无法启用或禁用它。
|
||||
|
||||
+5
-5
@@ -7,7 +7,7 @@ keywords: [rancher helm chart, rancher helm 选项, rancher helm chart 选项, h
|
||||
|
||||
如需选择 Helm Chart 版本,请参见[本页](../../../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md)。
|
||||
|
||||
了解开启实验性功能的详情,请参见[本页](../../../pages-for-subheaders/enable-experimental-features.md)。
|
||||
了解开启实验性功能的详情,请参见[本页](../../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。
|
||||
|
||||
## 常用选项
|
||||
|
||||
@@ -81,13 +81,13 @@ kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{
|
||||
|
||||
启用 [API 审计日志](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md)。
|
||||
|
||||
你可以像收集其他容器日志一样收集此日志。在 Rancher Server 集群上为 `System` 项目启用 [Logging](../../../pages-for-subheaders/logging.md)。
|
||||
你可以像收集其他容器日志一样收集此日志。在 Rancher Server 集群上为 `System` 项目启用 [Logging](../../../integrations-in-rancher/logging/logging.md)。
|
||||
|
||||
```plain
|
||||
--set auditLog.level=1
|
||||
```
|
||||
|
||||
默认情况下,启用审计日志会在 Rancher pod 中创建一个 Sidecar 容器。这个容器(`rancher-audit-log`)会把日志流传输到 `stdout`。你可以像收集其他容器日志一样收集此日志。如果你使用 Sidecar 作为审计日志的目标时, `hostPath`,`maxAge`,`maxBackups` 和 `maxSize` 选项不会生效。建议使用你的操作系统或 Docker Daemon 的日志轮换功能来控制磁盘空间的使用。请为 Rancher Server 集群或 System 项目启用 [Logging](../../../pages-for-subheaders/logging.md)。
|
||||
默认情况下,启用审计日志会在 Rancher pod 中创建一个 Sidecar 容器。这个容器(`rancher-audit-log`)会把日志流传输到 `stdout`。你可以像收集其他容器日志一样收集此日志。如果你使用 Sidecar 作为审计日志的目标时, `hostPath`,`maxAge`,`maxBackups` 和 `maxSize` 选项不会生效。建议使用你的操作系统或 Docker Daemon 的日志轮换功能来控制磁盘空间的使用。请为 Rancher Server 集群或 System 项目启用 [Logging](../../../integrations-in-rancher/logging/logging.md)。
|
||||
|
||||
将 `auditLog.destination` 的值设为 `hostPath`,可以将日志转发到与主机系统共享的卷,而不是传输到 Sidecar 容器。如果目标设置为 `hostPath`,你可能需要调整其他 auditLog 参数以进行日志轮换。
|
||||
|
||||
@@ -159,7 +159,7 @@ Rancher 的一些功能(Helm Chart)需要使用互联网才能使用。你
|
||||
|
||||
不包括敏感数据时,可以使用 `proxy` 或 `extraEnv` Chart 选项。使用 `extraEnv` 时将忽略 `noProxy` Helm 选项。因此,`NO_PROXY` 环境变量也必须设置为 `extraEnv`。
|
||||
|
||||
以下是使用 `extraEnv` Chart 选项设置代理的示例:
|
||||
以下是使用 `proxy` Chart 选项设置代理的示例:
|
||||
|
||||
```plain
|
||||
--set proxy="http://<proxy_url:proxy_port>/"
|
||||
@@ -202,7 +202,7 @@ kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-
|
||||
|
||||
### 私有仓库和离线安装
|
||||
|
||||
有关使用私有仓库安装 Rancher 的详情,请参见[离线安装](../../../pages-for-subheaders/air-gapped-helm-cli-install.md)。
|
||||
有关使用私有仓库安装 Rancher 的详情,请参见[离线安装](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md)。
|
||||
|
||||
## 外部 TLS 终止
|
||||
|
||||
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: 安装参考
|
||||
---
|
||||
|
||||
有关其他安装资源,请参阅以下参考指南:[Rancher Helm Chart 选项](helm-chart-options.md)、[TLS 设置](tls-settings.md)和[功能开关](feature-flags.md)。
|
||||
+7
-7
@@ -2,22 +2,22 @@
|
||||
title: 安装 Docker
|
||||
---
|
||||
|
||||
在使用 Helm 或 Docker 在 RKE 集群节点上安装 Rancher Server 前,你需要先安装 Docker。RKE2 和 K3s 集群不要求使用 Docker。
|
||||
在使用 Helm 在 RKE 集群节点上或使用 Docker 安装 Rancher Server 前,你需要在节点中先安装 Docker。RKE2 和 K3s 集群不要求使用 Docker。
|
||||
|
||||
Docker 有几个安装方法。一种方法是参见 [Docker 官方文档](https://docs.docker.com/install/)以了解如何在 Linux 上安装 Docker。不同 Linux 发行版的安装步骤可能有所不同。
|
||||
|
||||
另一种方式是使用 Rancher 的 Docker 安装脚本,该脚本可用于较新的 Docker 版本。
|
||||
另一种方式是使用 Rancher 的 Docker 安装脚本,该脚本可用于较新的 Docker 版本。 Rancher 为每个 Kubernetes 支持的上游 Docker 版本提供了安装脚本。
|
||||
|
||||
例如,此命令可用于在 SUSE Linux Enterprise 或 Ubuntu 等主要 Linux 发行版上安装 Docker 20.10:
|
||||
例如,此命令可用于在 SUSE Linux Enterprise 或 Ubuntu 等主要 Linux 发行版上安装 Docker :
|
||||
|
||||
```
|
||||
curl https://releases.rancher.com/install-docker/20.10.sh | sh
|
||||
```bash
|
||||
curl https://releases.rancher.com/install-docker/<version-number>.sh | sh
|
||||
```
|
||||
|
||||
Rancher 提供 Kubernetes 支持的所有上游 Docker 版本的安装脚本。如需了解我们是否提供某个 Docker 版本的安装脚本,请参见包含了 Rancher 所有的 Docker 安装脚本的 [GitHub 仓库](https://github.com/rancher/install-docker)。
|
||||
请参阅 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix),使用匹配你的操作系统和 Rancher 版本并且经过验证的 Docker 版本。 尽管支持矩阵列出了经过验证的 Docker 版本直至补丁版本,但只有发行版的主要版本和次要版本与 Docker 安装脚本相关。
|
||||
|
||||
请注意,必须应用以下 sysctl 设置:
|
||||
|
||||
```
|
||||
```bash
|
||||
net.bridge.bridge-nf-call-iptables=1
|
||||
```
|
||||
|
||||
+219
@@ -0,0 +1,219 @@
|
||||
---
|
||||
title: 安装要求
|
||||
description: 如果 Rancher 配置在 Docker 或 Kubernetes 中运行时,了解运行 Rancher Server 的每个节点的节点要求
|
||||
---
|
||||
|
||||
本文描述了对需要安装 Rancher Server 的节点的软件、硬件和网络要求。Rancher Server 可以安装在单个节点或高可用的 Kubernetes 集群上。
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
如果你需要在 Kubernetes 集群上安装 Rancher,该节点的要求与用于运行应用和服务的[下游集群的节点要求](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)不同。
|
||||
|
||||
:::
|
||||
|
||||
Rancher UI 在基于 Firefox 或 Chromium 的浏览器(Chrome、Edge、Opera、Brave)中效果最佳。
|
||||
|
||||
查看我们的[最佳实践](../../../reference-guides/best-practices/rancher-server/tips-for-running-rancher.md)页面,获取在生产环境中运行 Rancher Server 的建议。
|
||||
|
||||
## Kubernetes 与 Rancher 的兼容性
|
||||
|
||||
Rancher 需要安装在支持的 Kubernetes 版本上。请查阅 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions),确保你的 Kubernetes 版本受支持。
|
||||
|
||||
## 在安全加固的 Kubernetes 集群上安装 Rancher
|
||||
|
||||
如果你在安全加固的 Kubernetes 集群上安装 Rancher,请查看[豁免必须的 Rancher 命名空间](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#豁免必须的-rancher-命名空间)以了解详细的要求。
|
||||
|
||||
## 操作系统和容器运行时要求
|
||||
|
||||
所有支持的操作系统都使用 64-bit x86 架构。Rancher 兼容当前所有的主流 Linux 发行版。
|
||||
|
||||
[Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions)列出了每个 Rancher 版本测试过的操作系统和 Docker 版本。
|
||||
|
||||
运行 RKE 集群的节点需要安装 Docker。RKE2 或 K3s 集群不需要它。
|
||||
|
||||
请安装 `ntp`(Network Time Protocol),以防止在客户端和服务器之间由于时间不同步造成的证书验证错误。
|
||||
|
||||
某些 Linux 发行版的默认防火墙规则可能会阻止 Kubernetes 集群内的通信。从 Kubernetes v1.19 开始,你必须关闭 firewalld,因为它与 Kubernetes 网络插件冲突。
|
||||
|
||||
如果你不太想这样做的话,你可以查看[相关问题](https://github.com/rancher/rancher/issues/28840)中的建议。某些用户已能成功[使用 ACCEPT 策略 为 Pod CIDR 创建一个独立的 firewalld 区域](https://github.com/rancher/rancher/issues/28840#issuecomment-787404822)。
|
||||
|
||||
如果你需要在 ARM64 上使用 Rancher,请参见[在 ARM64(实验功能)上运行 Rancher](../../../how-to-guides/advanced-user-guides/enable-experimental-features/rancher-on-arm64.md)。
|
||||
|
||||
### RKE2 要求
|
||||
|
||||
对于容器运行时,RKE2 附带了自己的 containerd。RKE2 安装不需要 Docker。
|
||||
|
||||
如需了解 RKE2 通过了哪些操作系统版本的测试,请参见 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions)。
|
||||
|
||||
|
||||
### K3s 要求
|
||||
|
||||
对于容器运行时,K3s 默认附带了自己的 containerd。你也可以将 K3s 配置为使用已安装的 Docker 运行时。有关在 Docker 中使用 K3s 的更多信息,请参阅 [K3s 文档](https://docs.k3s.io/advanced#using-docker-as-the-container-runtime)。
|
||||
|
||||
Rancher 需要安装在支持的 Kubernetes 版本上。如需了解你使用的 Rancher 版本支持哪些 Kubernetes 版本,请参见 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions)。如需指定 K3s 版本,在运行 K3s 安装脚本时,使用 `INSTALL_K3S_VERSION` 环境变量。
|
||||
|
||||
如果你使用 **Raspbian Buster** 在 K3s 集群上安装 Rancher,请按照[这些步骤](https://rancher.com/docs/k3s/latest/en/advanced/#enabling-legacy-iptables-on-raspbian-buster)切换到旧版 iptables。
|
||||
|
||||
如果你使用 Alpine Linux 的 K3s 集群上安装 Rancher,请按照[这些步骤](https://rancher.com/docs/k3s/latest/en/advanced/#additional-preparation-for-alpine-linux-setup)进行其他设置。
|
||||
|
||||
### RKE 要求
|
||||
|
||||
RKE 需要 Docker 容器运行时。支持的 Docker 版本请参见 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions)
|
||||
|
||||
有关详细信息,请参阅[安装 Docker](install-docker.md)。
|
||||
|
||||
## 硬件要求
|
||||
|
||||
本节描述安装 Rancher Server 的节点的 CPU、内存和磁盘要求。硬件要求根据你的 Rancher 部署规模而定。
|
||||
|
||||
### 实际考虑
|
||||
|
||||
Rancher 的硬件占用空间取决于许多因素,包括:
|
||||
|
||||
- 托管的基础设施规模 (例如: 节点数量,集群数量)。
|
||||
- 所需访问控制规则的复杂性(例如:RoleBinding 对象计数)。
|
||||
- 工作负载数量 (例如: Kubernetes 部署,Fleet 部署)。
|
||||
- 使用模式 (例如:主动使用的功能集合,使用频率,并发用户数量).
|
||||
|
||||
由于存在许多可能随时间变化的影响因素,因此此处列出的要求为适合大多数用例的起点。 然而,你的用例可能有不同的要求。 若你需要对于特定场景的咨询,请[联系 Rancher]((https://rancher.com/contact/)) 以获得进一步指导。
|
||||
|
||||
|
||||
特别指出,本页面中的要求基于以下假设的环境提出,包括:
|
||||
- 每种类型的 Kubernetes 资源数量小于 60,000 个。
|
||||
- 每个节点最多 120 个 Pod。
|
||||
- 上游(本地)集群中最多 200 个 CRD。
|
||||
- 下游集群中最多 100 个 CRD。
|
||||
- 最多 50 个 Fleet 部署。
|
||||
|
||||
更多的数量也是能够达到的,但需要更高的硬件要求。 如果你有超过 20,000 个相同类型的资源,通过 Rancher UI 加载整个列表的时间可能需要几秒钟。
|
||||
|
||||
:::note Evolution:
|
||||
|
||||
Rancher 的代码库不断发展,用例不断变化,Rancher 积累的经验也在不断增长。
|
||||
|
||||
随着指导方针的准确性不断的提高并且变得更加具体,硬件要求也会发生变化。
|
||||
|
||||
如果你发现你的 Rancher 部署不再符合列出的建议,请[联系 Rancher](https://rancher.com/contact/) 进行重新评估。
|
||||
|
||||
:::
|
||||
|
||||
### RKE2 Kubernetes
|
||||
|
||||
下面的表格列出了[上游集群](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)中每个节点最小的 CPU 和内存要求。
|
||||
|
||||
请注意,生产环境下的高可用安装最少需要 3 个节点。
|
||||
|
||||
| 部署规模 | 最大集群数量 | 最大节点数量 | vCPUs | 内存 |
|
||||
| --------------- | -------- | --------- | ----- | ---- |
|
||||
| 小 | 150 | 1500 | 4 | 16 GB |
|
||||
| 中 | 300 | 3000 | 8 | 32 GB |
|
||||
| 大 (*) | 500 | 5000 | 16 | 64 GB |
|
||||
| 更大 (†) | (†) | (†) | (†) | (†) |
|
||||
|
||||
(*): 大规模的部署需要你[遵循最佳实践](../../../reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale.md)以获得足够的性能。
|
||||
|
||||
(†): 通过特别的硬件建议和调整能够实现更大的部署规模。 你可以[联系 Rancher](https://rancher.com/contact/) 进行定制评估。
|
||||
|
||||
有关 RKE2 一般要求的更多详细信息,请参见 [RKE2 文档](https://docs.rke2.io/install/requirements)。
|
||||
|
||||
### K3s Kubernetes
|
||||
|
||||
下面的表格列出了[上游集群](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)中每个节点最小的 CPU 和内存要求。
|
||||
|
||||
请注意,生产环境下的高可用安装最少需要 3 个节点。
|
||||
|
||||
| 部署规模 | 最大集群数量 | 最大节点数量 | vCPUs | 内存 | 外部数据库(*) |
|
||||
| --------------- | ---------- | ------------ | -------| ---------| ------------------------- |
|
||||
| Small | 150 | 1500 | 4 | 16 GB | 2 vCPUs, 8 GB + 1000 IOPS |
|
||||
| Medium | 300 | 3000 | 8 | 32 GB | 4 vCPUs, 16 GB + 2000 IOPS |
|
||||
| Large (†) | 500 | 5000 | 16 | 64 GB | 8 vCPUs, 32 GB + 4000 IOPS |
|
||||
|
||||
(*):外部数据库是指将 K3s 集群数据存储在[专用的外部主机](https://docs.k3s.io/datastore)上。 这是可选的。 具体要求取决于使用的外部数据库。
|
||||
|
||||
(†):大规模的部署需要你[遵循最佳实践](../../../reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale.md)以获得足够的性能。
|
||||
|
||||
有关 K3s 一般要求的更多详细信息,请参见 [K3s 文档](https://docs.k3s.io/installation/requirements)。
|
||||
|
||||
### 托管 Kubernetes
|
||||
|
||||
下面的表格列出了[上游集群](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)中每个节点最小的 CPU 和内存要求。
|
||||
|
||||
请注意,生产环境下的高可用安装最少需要 3 个节点。
|
||||
|
||||
这些要求适用于托管 Kubernetes 集群,例如 Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS) 或 Google Kubernetes Engine (GKE)。 它们不适用于 Rancher SaaS 解决方案,例如 [Rancher Prime Hosted](https://www.rancher.com/products/rancher)。
|
||||
|
||||
| 部署规模 | 最大集群数量 | 最大节点数量 | vCPUs | 内存 |
|
||||
|-----------------------------|----------------------------|-------------------------|-------|-------|
|
||||
| 小 | 150 | 1500 | 4 | 16 GB |
|
||||
| 中 | 300 | 3000 | 8 | 32 GB |
|
||||
| 大 (*) | 500 | 5000 | 16 | 64 GB |
|
||||
|
||||
(*):大规模的部署需要你[遵循最佳实践](../../../reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale.md)以获得足够的性能。
|
||||
|
||||
|
||||
### RKE
|
||||
|
||||
下面的表格列出了[上游集群](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)中每个节点最小的 CPU 和内存要求。
|
||||
|
||||
请注意,生产环境下的高可用安装最少需要 3 个节点。
|
||||
|
||||
| 部署规模 | 最大集群数量 | 最大节点数量 | vCPUs | 内存 |
|
||||
|-----------------------------|----------------------------|-------------------------|-------|-------|
|
||||
| 小 | 150 | 1500 | 4 | 16 GB |
|
||||
| 中 | 300 | 3000 | 8 | 32 GB |
|
||||
| 大 (*) | 500 | 5000 | 16 | 64 GB |
|
||||
|
||||
(*): 大规模的部署需要你[遵循最佳实践](../../../reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale.md)以获得足够的性能。
|
||||
|
||||
有关 RKE 一般要求的更多详细信息,请参见 [RKE 文档](https://rke.docs.rancher.com/os)。
|
||||
|
||||
### Docker
|
||||
|
||||
下面的表格列出了[上游集群](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)中每个节点最小的 CPU 和内存要求。
|
||||
|
||||
请注意,在 Docker 中安装 Rancher 仅适用于开发或测试目的。不建议在生产环境中使用。
|
||||
|
||||
| 部署规模 | 最大集群数量 | 最大节点数量 | vCPUs | 内存 |
|
||||
|-----------------------------|----------------------------|-------------------------|-------|------|
|
||||
| 小 | 5 | 50 | 1 | 4 GB |
|
||||
| 中 | 15 | 200 | 2 | 8 GB |
|
||||
|
||||
## Ingress
|
||||
|
||||
安装 Rancher 的 Kubernetes 集群中的每个节点都应该运行一个 Ingress。
|
||||
|
||||
Ingress 需要部署为 DaemonSet 以确保负载均衡器能成功把流量转发到各个节点。
|
||||
|
||||
如果是 RKE,RKE2 和 K3s 安装,你不需要手动安装 Ingress,因为它是默认安装的。
|
||||
|
||||
对于托管的 Kubernetes 集群(EKS、GKE、AKS),你需要设置 Ingress。
|
||||
|
||||
- **Amazon EKS**:[在 Amazon EKS 上安装 Rancher 以及如何安装 Ingress 以访问 Rancher Server](../install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md)。
|
||||
- **AKS**:[使用 Azure Kubernetes 服务安装 Rancher 以及如何安装 Ingress 以访问 Rancher Server](../install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md)。
|
||||
- **GKE**:[使用 GKE 安装 Rancher 以及如何安装 Ingress 以访问 Rancher Server](../install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md)。
|
||||
|
||||
## 磁盘
|
||||
|
||||
etcd 在集群中的性能决定了 Rancher 的性能。因此,为了获得最佳速度,我们建议使用 SSD 磁盘来支持 Rancher 管理的 Kubernetes 集群。在云提供商上,你还需使用能获得最大 IOPS 的最小大小。在较大的集群中,请考虑使用专用存储设备存储 etcd 数据和 wal 目录。
|
||||
|
||||
## 网络要求
|
||||
|
||||
本节描述了安装 Rancher Server 的节点的网络要求。
|
||||
|
||||
:::caution
|
||||
|
||||
如果包含 Rancher 的服务器带有 `X-Frame-Options=DENY` 标头,在升级旧版 UI 之后,Rancher UI 中的某些页面可能无法渲染。这是因为某些旧版页面在新 UI 中是以 iFrames 模式嵌入的。
|
||||
|
||||
:::
|
||||
|
||||
### 节点 IP 地址
|
||||
|
||||
无论你是在单个节点还是高可用集群上安装 Rancher,每个节点都应配置一个静态 IP。如果使用 DHCP,则每个节点都应该有一个 DHCP 预留,以确保节点分配到相同的 IP 地址。
|
||||
|
||||
### 端口要求
|
||||
|
||||
为了确保能正常运行,Rancher 需要在 Rancher 节点和下游 Kubernetes 集群节点上开放一些端口。不同集群类型的 Rancher 和下游集群的所有必要端口,请参见[端口要求](port-requirements.md)。
|
||||
|
||||
## Dockershim 支持
|
||||
|
||||
有关 Dockershim 支持的详情,请参见[此页面](dockershim.md)。
|
||||
+5
-5
@@ -178,9 +178,9 @@ RKE2 server 需要开放端口 6443 和 9345 才能供集群中的其他节点
|
||||
|
||||
下游 Kubernetes 集群用于运行你的应用和服务。本节介绍了哪些端口需要在下游集群的节点上打开,以便 Rancher 能够与它们进行通信。
|
||||
|
||||
不同的下游集群的启动方式有不同的端口要求。下面的每个标签都列出了不同[集群类型](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)所需打开的端口。
|
||||
不同的下游集群的启动方式有不同的端口要求。下面的每个标签都列出了不同[集群类型](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md)所需打开的端口。
|
||||
|
||||
下图描述了为每个[集群类型](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)打开的端口。
|
||||
下图描述了为每个[集群类型](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md)打开的端口。
|
||||
|
||||
<figcaption>Rancher 管理面板的端口要求</figcaption>
|
||||
|
||||
@@ -202,7 +202,7 @@ RKE2 server 需要开放端口 6443 和 9345 才能供集群中的其他节点
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了节点在[云提供商](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)中创建的情况下,[Rancher 启动 Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 的端口要求。
|
||||
下表描述了节点在[云提供商](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)中创建的情况下,[Rancher 启动 Kubernetes](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) 的端口要求。
|
||||
|
||||
:::note
|
||||
|
||||
@@ -219,7 +219,7 @@ RKE2 server 需要开放端口 6443 和 9345 才能供集群中的其他节点
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了使用[自定义节点](../../../pages-for-subheaders/use-existing-nodes.md)的情况下,[Rancher 启动 Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 的端口要求。
|
||||
下表描述了使用[自定义节点](../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md)的情况下,[Rancher 启动 Kubernetes](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) 的端口要求。
|
||||
|
||||
<PortsCustomNodes/>
|
||||
|
||||
@@ -230,7 +230,7 @@ RKE2 server 需要开放端口 6443 和 9345 才能供集群中的其他节点
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了[托管集群](../../../pages-for-subheaders/set-up-clusters-from-hosted-kubernetes-providers.md)的端口要求。
|
||||
下表描述了[托管集群](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md)的端口要求。
|
||||
|
||||
<PortsImportedHosted/>
|
||||
|
||||
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: 离线 Helm CLI 安装
|
||||
---
|
||||
|
||||
本文介绍如何使用 Helm CLI 在离线环境中安装 Rancher Server。离线环境可以是 Rancher Server 离线安装、防火墙后面或代理后面。
|
||||
|
||||
Rancher 安装在 RKE Kubernetes 集群、K3s Kubernetes 集群,或单个 Docker 容器上对应的安装步骤会有所不同。
|
||||
|
||||
如需了解各个安装方式的更多信息,请参见[本页](../../installation-and-upgrade.md)。
|
||||
|
||||
在安装指导中,我们为不同的安装选项提供对应的 _选项卡_ 。
|
||||
|
||||
:::note 重要提示:
|
||||
|
||||
如果你按照 Docker 安装指南安装 Rancher,你将没有把 Docker 安装转换为 Kubernetes 安装的升级途径。
|
||||
|
||||
:::
|
||||
|
||||
## 安装概要
|
||||
|
||||
1. [设置基础设施和私有镜像仓库](infrastructure-private-registry.md)
|
||||
2. [收集镜像到私有镜像仓库](publish-images.md)
|
||||
3. [设置 Kubernetes 集群(如果你使用 Docker 安装,请跳过此步骤)](install-kubernetes.md)
|
||||
4. [安装 Rancher](install-rancher-ha.md)
|
||||
|
||||
## 升级
|
||||
|
||||
如需在离线环境中使用 Helm CLI 升级 Rancher,请按照[升级步骤](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md)进行操作。
|
||||
|
||||
### 后续操作
|
||||
[准备节点](infrastructure-private-registry.md)
|
||||
+2
-2
@@ -6,7 +6,7 @@ title: '1. 设置基础设施和私有镜像仓库'
|
||||
|
||||
离线环境是 Rancher Server 离线安装或安装在防火墙后面的环境。
|
||||
|
||||
Rancher 安装在 K3s Kubernetes 集群、RKE Kubernetes 集群还是单个 Docker 容器上对应的基础设施设置会有所不同。如需了解各个安装方式的更多信息,请参见[本页](../../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
Rancher 安装在 K3s Kubernetes 集群、RKE Kubernetes 集群还是单个 Docker 容器上对应的基础设施设置会有所不同。如需了解各个安装方式的更多信息,请参见[本页](../../installation-and-upgrade.md)。
|
||||
|
||||
Rancher 可以安装在任何 Kubernetes 集群上。为了阅读方便,我们在下文中仍提供了 RKE 和 K3s Kubernetes 基础设施教程。
|
||||
|
||||
@@ -25,7 +25,7 @@ Rancher 可以安装在任何 Kubernetes 集群上。为了阅读方便,我们
|
||||
|
||||
这些主机会断开互联网链接,但需要能与你的私有镜像仓库连接。
|
||||
|
||||
请确保你的节点满足[操作系统,容器运行时,硬件和网络](../../../../pages-for-subheaders/installation-requirements.md)的常规要求。
|
||||
请确保你的节点满足[操作系统,容器运行时,硬件和网络](../../installation-requirements/installation-requirements.md)的常规要求。
|
||||
|
||||
如需获取配置 Linux 节点的示例,请参见[在 Amazon EC2 中配置节点](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md)的教程。
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user