mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
resolving merging conflict
This commit is contained in:
martyav
@@ -10,7 +10,7 @@ Fixes #[issue_number]
|
||||
|
||||
- Verify if changes pertain to other versions of Rancher. If they do, finalize the edits on one version of the page, then apply the edits to the other versions.
|
||||
|
||||
- If the pull request is dependent on an upcoming release, make sure to target the release branch instead of `main`.
|
||||
- If the pull request is dependent on an upcoming release, remember to add a "MERGE ON RELEASE" label and set the proper milestone.
|
||||
|
||||
## Description
|
||||
|
||||
@@ -24,4 +24,4 @@ Fixes #[issue_number]
|
||||
|
||||
<!--
|
||||
Any additional notes a reviewer should know before we review.
|
||||
-->
|
||||
-->
|
||||
|
||||
@@ -6,14 +6,14 @@ on:
|
||||
- main
|
||||
|
||||
jobs:
|
||||
deploy:
|
||||
name: Deploy to GitHub Pages
|
||||
build:
|
||||
name: Build Docusaurus
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- uses: actions/setup-node@v3
|
||||
- uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: 18
|
||||
cache: yarn
|
||||
@@ -25,18 +25,25 @@ jobs:
|
||||
NODE_OPTIONS: "--max_old_space_size=7168"
|
||||
run: yarn build --no-minify
|
||||
|
||||
# Popular action to deploy to GitHub Pages:
|
||||
# Docs: https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-docusaurus
|
||||
- name: Deploy to GitHub Pages
|
||||
uses: peaceiris/actions-gh-pages@v3
|
||||
- name: Upload Build Artifact
|
||||
uses: actions/upload-pages-artifact@v3
|
||||
with:
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
# Build output to publish to the `gh-pages` branch:
|
||||
publish_dir: ./build
|
||||
# The following lines assign commit authorship to the official
|
||||
# GH-Actions bot for deploys to `gh-pages` branch:
|
||||
# https://github.com/actions/checkout/issues/13#issuecomment-724415212
|
||||
# The GH actions bot is used by default if you didn't specify the two fields.
|
||||
# You can swap them out with your own user credentials.
|
||||
user_name: github-actions[bot]
|
||||
user_email: 41898282+github-actions[bot]@users.noreply.github.com
|
||||
path: build
|
||||
|
||||
deploy:
|
||||
name: Deploy to GitHub Pages
|
||||
needs: build
|
||||
|
||||
permissions:
|
||||
pages: write
|
||||
id-token: write
|
||||
|
||||
environment:
|
||||
name: github-pages
|
||||
url: ${{ steps.deployment.outputs.page_url }}
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Deploy to GitHub Pages
|
||||
id: deployment
|
||||
uses: actions/deploy-pages@v4
|
||||
@@ -10,8 +10,10 @@ jobs:
|
||||
name: Test deployment
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- uses: actions/setup-node@v3
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: 18
|
||||
cache: yarn
|
||||
|
||||
@@ -96,7 +96,7 @@ Kubernetes workers should open TCP port `6783` (control port), UDP port `6783` a
|
||||
|
||||
For more information, see the following pages:
|
||||
|
||||
- [Weave Net Official Site](https://www.weave.works/)
|
||||
- [Weave Net Official Site](https://github.com/weaveworks/weave/blob/master/site/overview.md)
|
||||
|
||||
### RKE2 Kubernetes clusters
|
||||
|
||||
|
||||
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.8.4](https://github.com/rancher/rancher/releases/tag/v2.8.4) | May 16, 2024 |
|
||||
| [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 |
|
||||
|
||||
@@ -10,10 +10,6 @@ This FAQ is a work in progress designed to answer the questions most frequently
|
||||
|
||||
See the [Technical FAQ](technical-items.md) for frequently asked technical questions.
|
||||
|
||||
## Does Rancher v2.x support Docker Swarm and Mesos as environment types?
|
||||
|
||||
Swarm and Mesos are no longer selectable options when you create a new environment in Rancher v2.x. However, both Swarm and Mesos will continue to be available as Catalog applications you can deploy. It was a tough decision to make but, in the end, it came down to adoption. For example, out of more than 15,000 clusters, only about 200 were running Swarm.
|
||||
|
||||
## Is it possible to manage Azure Kubernetes Services with Rancher v2.x?
|
||||
|
||||
Yes. See our [Cluster Administration](../how-to-guides/new-user-guides/manage-clusters/manage-clusters.md) guide for what Rancher features are available on AKS, as well as our [documentation on AKS](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md).
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: Glossary
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/glossary"/>
|
||||
</head>
|
||||
|
||||
This page covers Rancher-specific terminology and symbols which might be unfamiliar, or which differ between Rancher versions.
|
||||
|
||||
```mdx-code-block
|
||||
import Glossary, {toc as GlossaryTOC} from "/shared-files/_glossary.md"
|
||||
|
||||
<Glossary />
|
||||
|
||||
export const toc = GlossaryTOC;
|
||||
```
|
||||
+8
-8
@@ -28,14 +28,14 @@ spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
audit-policy-file: |
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
rules:
|
||||
- level: RequestResponse
|
||||
resources:
|
||||
- group: ""
|
||||
resources:
|
||||
- pods
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
rules:
|
||||
- level: RequestResponse
|
||||
resources:
|
||||
- group: ""
|
||||
resources:
|
||||
- pods
|
||||
```
|
||||
|
||||
### Method 2: Use the Directives, `machineSelectorFiles` and `machineGlobalConfig`
|
||||
|
||||
@@ -36,12 +36,12 @@ The usage below defines rules about what the audit log should record and what da
|
||||
|
||||
The following table displays what parts of API transactions are logged for each [`AUDIT_LEVEL`](#api-audit-log-options) setting.
|
||||
|
||||
| `AUDIT_LEVEL` Setting | Request Metadata | Request Body | Response Metadata | Response Body |
|
||||
| --------------------- | ---------------- | ------------ | ----------------- | ------------- |
|
||||
| `0` | | | | |
|
||||
| `1` | ✓ | | | |
|
||||
| `2` | ✓ | ✓ | | |
|
||||
| `3` | ✓ | ✓ | ✓ | ✓ |
|
||||
| `AUDIT_LEVEL` Setting | Metadata | Request Body | Response Body |
|
||||
| --------------------- | -------- | ------------ | ------------- |
|
||||
| `0` | | | |
|
||||
| `1` | ✓ | | |
|
||||
| `2` | ✓ | ✓ | |
|
||||
| `3` | ✓ | ✓ | ✓ |
|
||||
|
||||
## Viewing API Audit Logs
|
||||
|
||||
|
||||
+77
-1
@@ -42,7 +42,7 @@ For more information about the default limits, see [this page.](../../../referen
|
||||
|
||||
### Enable Monitoring for use without SSL
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you created and click **Explore**.
|
||||
1. Click **Cluster Tools** (bottom left corner).
|
||||
1. Click **Install** by Monitoring.
|
||||
@@ -77,3 +77,79 @@ key.pfx=`base64-content`
|
||||
```
|
||||
|
||||
Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`.
|
||||
|
||||
## Rancher Performance Dashboard
|
||||
|
||||
When monitoring is installed on the upstream (local) cluster, you are given basic health metrics about the Rancher pods, such as CPU and memory data. To get advanced metrics for your local Rancher server, you must additionally enable the Rancher Performance Dashboard for Grafana.
|
||||
|
||||
This dashboard provides access to the following advanced metrics:
|
||||
|
||||
- Handler Average Execution Times Over Last 5 Minutes
|
||||
- Rancher API Average Request Times Over Last 5 Minutes
|
||||
- Subscribe Average Request Times Over Last 5 Minutes
|
||||
- Lasso Controller Work Queue Depth (Top 20)
|
||||
- Number of Rancher Requests (Top 20)
|
||||
- Number of Failed Rancher API Requests (Top 20)
|
||||
- K8s Proxy Store Average Request Times Over Last 5 Minutes (Top 20)
|
||||
- K8s Proxy Client Average Request Times Over Last 5 Minutes (Top 20)
|
||||
- Cached Objects by GroupVersionKind (Top 20)
|
||||
- Lasso Handler Executions (Top 20)
|
||||
- Handler Executions Over Last 2 Minutes (Top 20)
|
||||
- Total Handler Executions with Error (Top 20)
|
||||
- Data Transmitted by Remote Dialer Sessions (Top 20)
|
||||
- Errors for Remote Dialer Sessions (Top 20)
|
||||
- Remote Dialer Connections Removed (Top 20)
|
||||
- Remote Dialer Connections Added by Client (Top 20)
|
||||
|
||||
:::note
|
||||
|
||||
Profiling data (such as advanced memory or CPU analysis) is not present as it is a very context-dependent technique that's meant for debugging and not intended for normal observation.
|
||||
|
||||
:::
|
||||
|
||||
### Enabling the Rancher Performance Dashboard
|
||||
|
||||
To enable the Rancher Performance Dashboard:
|
||||
|
||||
<Tabs groupid="UIorCLI">
|
||||
<TabItem value="Helm">
|
||||
|
||||
Use the following options with the Helm CLI:
|
||||
|
||||
```bash
|
||||
--set extraEnv\[0\].name="CATTLE_PROMETHEUS_METRICS" --set-string extraEnv\[0\].value=true
|
||||
```
|
||||
|
||||
You can also include the following snippet in your Rancher Helm chart's values.yaml file:
|
||||
|
||||
```yaml
|
||||
extraEnv:
|
||||
- name: "CATTLE_PROMETHEUS_METRICS"
|
||||
value: "true"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="UI">
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the row of the `local` cluster and click **Explore**.
|
||||
1. Click **Workloads > Deployments**.
|
||||
1. Use the dropdown menu at the top to filter for **All Namespaces**.
|
||||
1. Under the `cattle-system` namespace, go to the `rancher` row and click **⋮ > Edit Config**
|
||||
1. Under **Environment Variables**, click **Add Variable**.
|
||||
1. For **Type**, select `Key/Value Pair`.
|
||||
1. For **Variable Name**, enter `CATTLE_PROMETHEUS_METRICS`.
|
||||
1. For **Value**, enter `true`.
|
||||
1. Click **Save** to apply the change.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Accessing the Rancher Performance Dashboard
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the row of the `local` cluster and click **Explore**.
|
||||
1. Click **Monitoring**
|
||||
1. Select the **Grafana** dashboard.
|
||||
1. From the sidebar, click **Search dashboards**.
|
||||
1. Enter `Rancher Performance Debugging` and select it.
|
||||
|
||||
@@ -6,7 +6,17 @@ title: Opening Ports with firewalld
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/open-ports-with-firewalld"/>
|
||||
</head>
|
||||
|
||||
> We recommend disabling firewalld. For Kubernetes 1.19.x and higher, firewalld must be turned off.
|
||||
:::danger
|
||||
|
||||
Enabling firewalld can cause serious network communication problems.
|
||||
|
||||
For proper network function, firewalld must be disabled on systems running RKE2. [Firewalld conflicts with Canal](https://docs.rke2.io/known_issues#firewalld-conflicts-with-default-networking), RKE2's default networking stack.
|
||||
|
||||
Firewalld must also be disabled on systems running Kubernetes 1.19 and later.
|
||||
|
||||
If you enable firewalld on systems running Kubernetes 1.18 or earlier, understand that this may cause networking issues. CNIs in Kubernetes dynamically update iptables and networking rules independently of any external firewalls, such as firewalld. This can cause unexpected behavior when the CNI and the external firewall conflict.
|
||||
|
||||
:::
|
||||
|
||||
Some distributions of Linux [derived from RHEL,](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds) including Oracle Linux, may have default firewall rules that block communication with Helm.
|
||||
|
||||
|
||||
+3
-1
@@ -56,4 +56,6 @@ If you want to use a node driver that Rancher doesn't support out-of-the-box, yo
|
||||
|
||||
### Developing Your Own Node Drivers
|
||||
|
||||
Node drivers are implemented with [Docker Machine](https://docs.docker.com/machine/).
|
||||
Node drivers are implemented with [Rancher Machine](https://github.com/rancher/machine), a fork of [Docker Machine](https://github.com/docker/machine). Docker Machine is no longer under active development.
|
||||
|
||||
Refer to the original [Docker Machine documentation](https://github.com/docker/docs/blob/vnext-engine/machine/overview.md) for details on how to develop your own node drivers.
|
||||
|
||||
-1
@@ -51,7 +51,6 @@ You can integrate Okta with Rancher, so that authenticated users can access Ranc
|
||||
|
||||
:::
|
||||
|
||||
|
||||
1. After you complete the **Configure Okta Account** form, click **Enable**.
|
||||
|
||||
Rancher redirects you to the IdP login page. Enter credentials that authenticate with Okta IdP to validate your Rancher Okta configuration.
|
||||
|
||||
+16
-3
@@ -79,15 +79,20 @@ If you are using [local snapshots](./back-up-rancher-launched-kubernetes-cluster
|
||||
1. In the **Clusters** page, go to the cluster where you want to remove nodes.
|
||||
1. In the **Machines** tab, click **⋮ > Delete** on each node you want to delete. Initially, you will see the nodes hang in a `deleting` state, but once all etcd nodes are deleting, they will be removed together. This is due to the fact that Rancher sees all etcd nodes deleting and proceeds to "short circuit" the etcd safe-removal logic.
|
||||
|
||||
1. After all etcd nodes are removed, add a new etcd node that you are planning to restore from.
|
||||
1. After all etcd nodes are removed, add the new etcd node that you are planning to restore from. Assign the new node the role of `all` (etcd, controlplane, and worker).
|
||||
|
||||
- For custom clusters, go to the **Registration** tab then copy and run the registration command on your node. If the node has previously been used in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
|
||||
- If the node was previously in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
|
||||
- For custom clusters, go to the **Registration** tab and check the box for `etcd, controlplane, and worker`. Then copy and run the registration command on your node.
|
||||
- For node driver clusters, a new node is provisioned automatically.
|
||||
|
||||
At this point, Rancher will indicate that restoration from etcd snapshot is required.
|
||||
|
||||
1. Restore from an etcd snapshot.
|
||||
|
||||
:::note
|
||||
As the etcd node is a clean node, you may need to manually create the `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/` path.
|
||||
:::
|
||||
|
||||
- For S3 snapshots, restore using the UI.
|
||||
1. Click the **Snapshots** tab to view the list of saved snapshots.
|
||||
1. Go to the snapshot you want to restore and click **⋮ > Restore**.
|
||||
@@ -95,7 +100,15 @@ If you are using [local snapshots](./back-up-rancher-launched-kubernetes-cluster
|
||||
1. Click **Restore**.
|
||||
- For local snapshots, restore using the UI is **not** available.
|
||||
1. In the upper right corner, click **⋮ > Edit YAML**.
|
||||
1. Define `spec.cluster.rkeConfig.etcdSnapshotRestore.name` as the filename of the snapshot on disk in `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/`.
|
||||
1. The example YAML below can be added under your `rkeConfig` to configure the etcd restore:
|
||||
|
||||
```yaml
|
||||
...
|
||||
rkeConfig:
|
||||
etcdSnapshotRestore:
|
||||
name: <string> # This field is required. Refers to the filename of the associated etcdsnapshot object.
|
||||
...
|
||||
```
|
||||
|
||||
1. After restoration is successful, you can scale your etcd nodes back up to the desired redundancy.
|
||||
|
||||
|
||||
@@ -167,6 +167,23 @@ spec:
|
||||
|
||||
Only Helm 3 compatible charts are supported.
|
||||
|
||||
### Refresh Chart Repositories
|
||||
|
||||
The **Refresh** button can be used to sync changes from selected Helm chart repositories on the **Repositories** page.
|
||||
|
||||
To refresh a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Use the toggle next to the **State** field to select all repositories, or toggle specified chart repositories to sync changes.
|
||||
1. Click **Refresh**.
|
||||
1. The **⋮** at the end of each chart repository row also includes a **Refresh** option, which can be clicked to refresh the respective repository.
|
||||
|
||||
Non-Airgap Rancher installations upon refresh will reflect any chart repository changes immediately and you will see the **State** field for updated repositories move from `In Progress` to `Active` once the action is completed.
|
||||
|
||||
Airgap installations where Rancher is configured to use the packaged copy of Helm system charts ([`useBundledSystemChart=true`](../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md#helm-chart-options-for-air-gap-installations)) will only refer to the [system-chart](https://github.com/rancher/system-charts) repository that comes bundled and will not be able to be refreshed or synced.
|
||||
|
||||
## Deploy and Upgrade Charts
|
||||
|
||||
To install and deploy a chart:
|
||||
|
||||
+20
-36
@@ -21,65 +21,48 @@ To interact with Azure APIs, an AKS cluster requires an Azure Active Directory (
|
||||
Before creating the service principal, you need to obtain the following information from the [Microsoft Azure Portal](https://portal.azure.com):
|
||||
|
||||
- Subscription ID
|
||||
- Client ID
|
||||
- Client ID (also known as app ID)
|
||||
- Client secret
|
||||
|
||||
The below sections describe how to set up these prerequisites using either the Azure command line tool or the Azure portal.
|
||||
|
||||
### Setting Up the Service Principal with the Azure Command Line Tool
|
||||
|
||||
You can create the service principal by running this command:
|
||||
You must assign roles to the service principal so that it has communication privileges with the AKS API. It also needs access to create and list virtual networks.
|
||||
|
||||
In the following example, the command creates the service principal and gives it the Contributor role. The Contributor role can manage anything on AKS but cannot give access to others. Note that you must provide `scopes` a full path to at least one Azure resource:
|
||||
|
||||
```
|
||||
az ad sp create-for-rbac --skip-assignment
|
||||
az ad sp create-for-rbac --role Contributor --scopes /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>
|
||||
```
|
||||
|
||||
The result should show information about the new service principal:
|
||||
|
||||
```
|
||||
{
|
||||
"appId": "xxxx--xxx",
|
||||
"displayName": "<SERVICE-PRINCIPAL-NAME>",
|
||||
"name": "http://<SERVICE-PRINCIPAL-NAME>",
|
||||
"password": "<SECRET>",
|
||||
"tenant": "<TENANT NAME>"
|
||||
"displayName": "<service-principal-name>",
|
||||
"name": "http://<service-principal-name>",
|
||||
"password": "<secret>",
|
||||
"tenant": "<tenant-name>"
|
||||
}
|
||||
```
|
||||
|
||||
You also need to add roles to the service principal so that it has privileges for communication with the AKS API. It also needs access to create and list virtual networks.
|
||||
|
||||
Below is an example command for assigning the Contributor role to a service principal. Contributors can manage anything on AKS but cannot give access to others:
|
||||
The following creates a [Resource Group](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-cli) to contain your Azure resources:
|
||||
|
||||
```
|
||||
az role assignment create \
|
||||
--assignee $appId \
|
||||
--scope /subscriptions/$<SUBSCRIPTION-ID>/resourceGroups/$<GROUP> \
|
||||
--role Contributor
|
||||
```
|
||||
|
||||
You can also create the service principal and give it Contributor privileges by combining the two commands into one. In this command, the scope needs to provide a full path to an Azure resource:
|
||||
|
||||
```
|
||||
az ad sp create-for-rbac \
|
||||
--scope /subscriptions/$<SUBSCRIPTION-ID>/resourceGroups/$<GROUP> \
|
||||
--role Contributor
|
||||
```
|
||||
|
||||
Create the Resource Group by running this command:
|
||||
|
||||
```
|
||||
az group create --location AZURE_LOCATION_NAME --resource-group AZURE_RESOURCE_GROUP_NAME
|
||||
az group create --location <azure-location-name> --resource-group <resource-group-name>
|
||||
```
|
||||
|
||||
### Setting Up the Service Principal from the Azure Portal
|
||||
|
||||
You can also follow these instructions to set up a service principal and give it role-based access from the Azure Portal.
|
||||
Follow these instructions to set up a service principal and give it role-based access from the Azure Portal.
|
||||
|
||||
1. Go to the Microsoft Azure Portal [home page](https://portal.azure.com).
|
||||
|
||||
1. Click **Azure Active Directory**.
|
||||
1. Click **App registrations**.
|
||||
1. Click **New registration**.
|
||||
1. Enter a name. This will be the name of your service principal.
|
||||
1. Enter a name for your service principal.
|
||||
1. Optional: Choose which accounts can use the service principal.
|
||||
1. Click **Register**.
|
||||
1. You should now see the name of your service principal under **Azure Active Directory > App registrations**.
|
||||
@@ -101,7 +84,7 @@ To give role-based access to your service principal,
|
||||
|
||||
**Result:** Your service principal now has access to AKS.
|
||||
|
||||
## 1. Create the AKS Cloud Credentials
|
||||
## Create the AKS Cloud Credentials
|
||||
|
||||
1. In the Rancher UI, click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
@@ -110,7 +93,7 @@ To give role-based access to your service principal,
|
||||
1. Fill out the form. For help with filling out the form, see the [configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md#cloud-credentials)
|
||||
1. Click **Create**.
|
||||
|
||||
## 2. Create the AKS Cluster
|
||||
## Create the AKS Cluster
|
||||
|
||||
Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
@@ -124,7 +107,8 @@ Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
## Role-based Access Control
|
||||
## Configure Role-based Access Control
|
||||
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC is not configurable because it is required to be enabled.
|
||||
|
||||
RBAC is required for AKS clusters that are registered or imported into Rancher.
|
||||
@@ -135,8 +119,8 @@ Assign the Rancher AKSv2 role to the service principal with the Azure Command Li
|
||||
|
||||
```
|
||||
az role assignment create \
|
||||
--assignee CLIENT_ID \
|
||||
--scope "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME" \
|
||||
--assignee <client-id> \
|
||||
--scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>" \
|
||||
--role "Rancher AKSv2"
|
||||
```
|
||||
|
||||
|
||||
+2
-2
@@ -70,7 +70,7 @@ StatefulSets manage the deployment and scaling of Pods while maintaining a stick
|
||||
1. Click **StatefulSet**.
|
||||
1. In the **Volume Claim Templates** tab, click **Add Claim Template**.
|
||||
1. Enter a name for the persistent volume.
|
||||
1. In the **StorageClass* field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **StorageClass** field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
1. Click **Launch**.
|
||||
|
||||
@@ -84,7 +84,7 @@ To attach the PVC to an existing workload,
|
||||
1. Go to the workload that will use storage provisioned with the StorageClass that you cared at click **⋮ > Edit Config**.
|
||||
1. In the **Volume Claim Templates** section, click **Add Claim Template**.
|
||||
1. Enter a persistent volume name.
|
||||
1. In the **StorageClass* field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **StorageClass** field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
1. Click **Save**.
|
||||
|
||||
|
||||
+1
-1
@@ -304,7 +304,7 @@ cloud-provider|-|Cloud provider type|
|
||||
|max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
|
||||
|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
|
||||
|node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
|
||||
|estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
|
||||
|estimator|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
|
||||
|expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
|
||||
|ignore-daemonsets-utilization|false|Should CA ignore DaemonSet pods when calculating resource utilization for scaling down|
|
||||
|ignore-mirror-pods-utilization|false|Should CA ignore Mirror pods when calculating resource utilization for scaling down|
|
||||
|
||||
+4
-3
@@ -19,10 +19,11 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|:----------------:|
|
||||
| v2.8.0 | v103.0.0+up3.0.0 |
|
||||
| v2.8.1 | v103.0.0+up3.0.0 |
|
||||
| v2.8.2 | v103.0.0+up3.0.0 |
|
||||
| v2.8.4 | v103.0.1+up3.0.1 |
|
||||
| v2.8.3 | v103.0.1+up3.0.1 |
|
||||
| v2.8.2 | v103.0.0+up3.0.0 |
|
||||
| v2.8.1 | v103.0.0+up3.0.0 |
|
||||
| v2.8.0 | v103.0.0+up3.0.0 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
|
||||
@@ -185,7 +185,7 @@ For detailed information on the values supported by the chart and their usage, r
|
||||
|
||||
:::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.
|
||||
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/contributing/install_capi_operator) in the Rancher Turtles documentation for assistance.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+24
-1
@@ -49,7 +49,6 @@ This is typical in Rancher, as many operations create new `RoleBinding` objects
|
||||
|
||||
You can reduce the number of `RoleBindings` in the upstream cluster in the following ways:
|
||||
* Limit the use of the [Restricted Admin](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin) role. Apply other roles wherever possible.
|
||||
* If you use [external authentication](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md), use groups to assign roles.
|
||||
* Only add users to clusters and projects when necessary.
|
||||
* Remove clusters and projects when they are no longer needed.
|
||||
* Only use custom roles if necessary.
|
||||
@@ -59,6 +58,12 @@ You can reduce the number of `RoleBindings` in the upstream cluster in the follo
|
||||
* Kubernetes permissions are always "additive" (allow-list) rather than "subtractive" (deny-list). Try to minimize configurations that gives access to all but one aspect of a cluster, project, or namespace, as that will result in the creation of a high number of `RoleBinding` objects.
|
||||
* Experiment to see if creating new projects or clusters manifests in fewer `RoleBindings` for your specific use case.
|
||||
|
||||
### Using External Authentication
|
||||
|
||||
If you have fifty or more users, you should configure an [external authentication provider](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md). This is necessary for better performance.
|
||||
|
||||
After you configure external authentication, make sure to assign permissions to groups instead of to individual users. This helps reduce the `RoleBinding` object count.
|
||||
|
||||
### RoleBinding Count Estimation
|
||||
|
||||
Predicting how many `RoleBinding` objects a given configuration will create is complicated. However, the following considerations can offer a rough estimate:
|
||||
@@ -105,6 +110,14 @@ Although managed Kubernetes services make it easier to deploy and run Kubernetes
|
||||
|
||||
Use RKE2 for large scale use cases.
|
||||
|
||||
### Keep all Upstream Cluster Nodes co-located
|
||||
|
||||
To provide high availability, Kubernetes is designed to run nodes and control components in different zones. However, if nodes and control plane components are located in different zones, network traffic may be slower.
|
||||
|
||||
Traffic between Rancher components and the Kubernetes API is especially sensitive to network latency, as is etcd traffic between nodes.
|
||||
|
||||
To improve performance, run all upstream node clusters in the same location. In particular, make sure that latency between etcd nodes and Rancher is as low as possible.
|
||||
|
||||
### Keeping Kubernetes Versions Up to Date
|
||||
|
||||
You should keep the local Kubernetes cluster up to date. This will ensure that your cluster has all available performance enhancements and bug fixes.
|
||||
@@ -118,3 +131,13 @@ The two main bottlenecks to [etcd performance](https://etcd.io/docs/v3.4/op-guid
|
||||
It's best to run etcd on exactly three nodes, as adding more nodes will reduce operation speed. This may be counter-intuitive to common scaling approaches, but it's due to etcd's [replication mechanisms](https://etcd.io/docs/v3.5/faq/#what-is-maximum-cluster-size).
|
||||
|
||||
Etcd performance will also be negatively affected by network latency between nodes as that will slow down network communication. Etcd nodes should be located together with Rancher nodes.
|
||||
|
||||
### Browser Requirements
|
||||
|
||||
At high scale, Rancher transfers more data from the upstream cluster to UI components running in the browser, and those components also need to perform more processing.
|
||||
|
||||
For best performance, ensure that the host running the hardware meets these requirements:
|
||||
- 2020 i5 10th generation Intel (4 cores) or equivalent
|
||||
- 8 GB RAM
|
||||
- Total network bandwith to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
|
||||
|
||||
+3
-3
@@ -149,13 +149,13 @@ Project network isolation is available if you are using any RKE2 network plugin
|
||||
|
||||
##### CoreDNS
|
||||
|
||||
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#coredns) for additional CoreDNS configurations.
|
||||
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [RKE2 documentation](https://docs.rke2.io/networking/networking_services#coredns) for additional CoreDNS configurations.
|
||||
|
||||
##### NGINX Ingress
|
||||
|
||||
If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
|
||||
If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster. Refer to the [RKE2 documentation](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller) for additional configuration options.
|
||||
|
||||
Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
|
||||
Refer to the [RKE2 documentation](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller) for additional configuration options.
|
||||
|
||||
##### Metrics Server
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ Logging is helpful because it allows you to:
|
||||
- Look for trends in your environment
|
||||
- Save your logs to a safe location outside of your cluster
|
||||
- Stay informed of events like a container crashing, a pod eviction, or a node dying
|
||||
- More easily debugg and troubleshoot problems
|
||||
- More easily debug and troubleshoot problems
|
||||
|
||||
Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd.
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ Logging is helpful because it allows you to:
|
||||
- Look for trends in your environment
|
||||
- Save your logs to a safe location outside of your cluster
|
||||
- Stay informed of events like a container crashing, a pod eviction, or a node dying
|
||||
- More easily debugg and troubleshoot problems
|
||||
- More easily debug and troubleshoot problems
|
||||
|
||||
Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd.
|
||||
|
||||
|
||||
+1
-1
@@ -102,7 +102,7 @@ The `rancher-restricted` template is provided by Rancher to enforce the highly-r
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
K3s v1.24 and older support [Pod Security Policy (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) for controlling pod security.
|
||||
K3s v1.24 and older support [Pod Security Policy (PSP)](https://github.com/kubernetes/website/blob/release-1.24/content/en/docs/concepts/security/pod-security-policy.md) for controlling pod security.
|
||||
|
||||
You can enable PSPs by passing the following flags in the cluster configuration in Rancher:
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
| [CVE-2022-31247](https://github.com/rancher/rancher/security/advisories/GHSA-6x34-89p7-95wg) | An issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where a flaw with authorization logic allows privilege escalation in downstream clusters through cluster role template binding (CRTB) and project role template binding (PRTB). The vulnerability can be exploited by any user who has permissions to create/edit CRTB or PRTB (such as `cluster-owner`, `manage cluster members`, `project-owner`, and `manage project members`) to gain owner permission in another project in the same cluster or in another project on a different downstream cluster. | 18 August 2022 | [Rancher v2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) and [Rancher v2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36783](https://github.com/rancher/rancher/security/advisories/GHSA-8w87-58w6-hfv8) | It was discovered that in Rancher versions up to and including 2.5.12 and 2.6.3, there is a failure to properly sanitize credentials in cluster template answers. This failure can lead to plaintext storage and exposure of credentials, passwords, and API tokens. The exposed credentials are visible in Rancher to authenticated `Cluster Owners`, `Cluster Members`, `Project Owners`, and `Project Members` on the endpoints `/v1/management.cattle.io.clusters`, `/v3/clusters`, and `/k8s/clusters/local/apis/management.cattle.io/v3/clusters`. | 18 August 2022 | [Rancher v2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) and [Rancher v2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36782](https://github.com/rancher/rancher/security/advisories/GHSA-g7j7-h4q8-8w2f) | An issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where sensitive fields like passwords, API keys, and Rancher's service account token (used to provision clusters) were stored in plaintext directly on Kubernetes objects like `Clusters` (e.g., `cluster.management.cattle.io`). Anyone with read access to those objects in the Kubernetes API could retrieve the plaintext version of those sensitive data. The issue was partially found and reported by Florian Struck (from [Continum AG](https://www.continum.net/)) and [Marco Stuurman](https://github.com/fe-ax) (from [Shock Media B.V.](https://www.shockmedia.nl/)). | 18 August 2022 | [Rancher v2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) and [Rancher v2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [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-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://github.com/weaveworks/weave/blob/master/site/tasks/manage/security-untrusted-networks.md) 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 [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) |
|
||||
|
||||
@@ -19,6 +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.4 | v0.4.5 | ✓ | ✓ |
|
||||
| v2.8.3 | v0.4.3 | ✓ | ✓ |
|
||||
| v2.8.2 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.1 | v0.4.2 | ✓ | ✓ |
|
||||
|
||||
@@ -107,20 +107,3 @@ When the MTU is incorrectly configured (either on hosts running Rancher, nodes i
|
||||
* `read tcp: i/o timeout`
|
||||
|
||||
See [Google Cloud VPN: MTU Considerations](https://cloud.google.com/vpn/docs/concepts/mtu-considerations#gateway_mtu_vs_system_mtu) for an example how to configure MTU correctly when using Google Cloud VPN between Rancher and cluster nodes.
|
||||
|
||||
### Resolved issues
|
||||
|
||||
#### Overlay network broken when using Canal/Flannel due to missing node annotations
|
||||
|
||||
| | |
|
||||
|------------|------------|
|
||||
| GitHub issue | [#13644](https://github.com/rancher/rancher/issues/13644) |
|
||||
| Resolved in | v2.1.2 |
|
||||
|
||||
To check if your cluster is affected, the following command will list nodes that are broken (this command requires `jq` to be installed):
|
||||
|
||||
```
|
||||
kubectl get nodes -o json | jq '.items[].metadata | select(.annotations["flannel.alpha.coreos.com/public-ip"] == null or .annotations["flannel.alpha.coreos.com/kube-subnet-manager"] == null or .annotations["flannel.alpha.coreos.com/backend-type"] == null or .annotations["flannel.alpha.coreos.com/backend-data"] == null) | .name'
|
||||
```
|
||||
|
||||
If there is no output, the cluster is not affected.
|
||||
|
||||
@@ -184,6 +184,11 @@ module.exports = {
|
||||
current: {
|
||||
label: 'Latest',
|
||||
},
|
||||
2.9: {
|
||||
label: 'v2.9 (Preview)',
|
||||
path: 'v2.9',
|
||||
banner: 'unreleased'
|
||||
},
|
||||
2.8: {
|
||||
label: 'v2.8',
|
||||
path: 'v2.8',
|
||||
|
||||
+1
-1
@@ -90,7 +90,7 @@ Kubernetes worker 需要打开 TCP 端口 `6783`（控制端口）、UDP 端口
|
||||
|
||||
有关详细信息，请参阅以下页面：
|
||||
|
||||
- [Weave Net 官网](https://www.weave.works/)
|
||||
- [Weave Net 官网](https://github.com/weaveworks/weave/blob/master/site/overview.md)
|
||||
|
||||
### RKE2 Kubernetes 集群
|
||||
|
||||
|
||||
+2
-2
@@ -66,7 +66,7 @@ StatefulSet 管理 Pod 的部署和扩展，同时为每个 Pod 维护一个粘
|
||||
1. 单击 **StatefulSet**。
|
||||
1. 在**卷声明模板**选项卡上，单击**添加声明模板**。
|
||||
1. 输入持久卷的名称。
|
||||
1. 在*存储类*\*字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**存储类**字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**挂载点**字段中，输入工作负载将用于访问卷的路径。
|
||||
1. 点击**启动**。
|
||||
|
||||
@@ -80,7 +80,7 @@ StatefulSet 管理 Pod 的部署和扩展，同时为每个 Pod 维护一个粘
|
||||
1. 单击 **⋮ > 编辑配置**，转到使用由 StorageClass 配置的存储的工作负载。
|
||||
1. 在**卷声明模板**中，单击**添加声明模板**。
|
||||
1. 输入持久卷名称。
|
||||
1. 在*存储类*\*字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**存储类**字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**挂载点**字段中，输入工作负载将用于访问卷的路径。
|
||||
1. 单击**保存**。
|
||||
|
||||
|
||||
+1
-1
@@ -300,7 +300,7 @@ title: 通过 AWS EC2 Auto Scaling 组使用 Cluster Autoscaler
|
||||
| max-node-provision-time | "15m" | CA 等待节点配置的最长时间 |
|
||||
| nodes | - | 以云提供商接受的格式设置节点组的最小、最大大小和其他配置数据。可以多次使用。格式是 `<min>:<max>:<other...>`。 |
|
||||
| node-group-auto-discovery | - | 节点组自动发现的一个或多个定义。定义表示为 `<name of discoverer>:[<key>[=<value>]]` |
|
||||
| estimator | - | "binpacking" | 用于扩容的资源评估器类型。可用值：["binpacking"] |
|
||||
| estimator |"binpacking" | 用于扩容的资源评估器类型。可用值：["binpacking"] |
|
||||
| expander | "random" | 要在扩容中使用的节点组扩展器的类型。可用值：`["random","most-pods","least-waste","price","priority"]` |
|
||||
| ignore-daemonsets-utilization | false | CA 为了缩容而计算资源利用率时，是否应忽略 DaemonSet pod |
|
||||
| ignore-mirror-pods-utilization | false | CA 为了缩容而计算资源利用率时，是否应忽略 Mirror pod |
|
||||
|
||||
+1
-1
@@ -185,7 +185,7 @@ stringData:
|
||||
|
||||
:::note
|
||||
|
||||
请记住，如果使用此安装选项，你必须自行管理 CAPI Operator 的安装。你可以参照 Rancher Turtles 文档中的 [CAPI Operator 指南](https://turtles.docs.rancher.com/tasks/capi-operator/intro)
|
||||
请记住，如果使用此安装选项，你必须自行管理 CAPI Operator 的安装。你可以参照 Rancher Turtles 文档中的 [CAPI Operator 指南](https://turtles.docs.rancher.com/contributing/install_capi_operator)
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -85,7 +85,7 @@ The `rancher-restricted` template is provided by Rancher to enforce the highly-r
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
K3s v1.24 and older support [Pod Security Policy (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) for controlling pod security.
|
||||
K3s v1.24 and older support [Pod Security Policy (PSP)](https://github.com/kubernetes/website/blob/release-1.24/content/en/docs/concepts/security/pod-security-policy.md) for controlling pod security.
|
||||
|
||||
You can enable PSPs by passing the following flags in the cluster configuration in Rancher:
|
||||
|
||||
|
||||
+3
-3
@@ -140,13 +140,13 @@ Rancher 与以下开箱即用的网络提供商兼容：
|
||||
|
||||
#### CoreDNS
|
||||
|
||||
默认情况下，[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS，则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置，请参阅 [RKE2 文档](https://docs.rke2.io/networking#coredns)。
|
||||
默认情况下，[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS，则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#coredns)。
|
||||
|
||||
#### NGINX Ingress
|
||||
|
||||
如果你想使用高可用性配置来发布应用，并且你使用没有原生负载均衡功能的云提供商来托管主机，请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
如果你想使用高可用性配置来发布应用，并且你使用没有原生负载均衡功能的云提供商来托管主机，请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller)。
|
||||
|
||||
有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller)。
|
||||
|
||||
#### Metrics Server
|
||||
|
||||
|
||||
+1
-1
@@ -102,7 +102,7 @@ Rancher 提供了 `rancher-restricted` 模板，用于强制执行高度限制
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
K3s v1.24 及更早版本支持 [Pod 安全策略 (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) 以控制 Pod 安全性。
|
||||
K3s v1.24 及更早版本支持 [Pod 安全策略 (PSP)](https://github.com/kubernetes/website/blob/release-1.24/content/en/docs/concepts/security/pod-security-policy.md) 以控制 Pod 安全性。
|
||||
|
||||
你可以在 Rancher 中通过集群配置，传递以下标志来启用 PSPs：
|
||||
|
||||
|
||||
+1
-1
@@ -28,7 +28,7 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
| [CVE-2022-31247](https://github.com/rancher/rancher/security/advisories/GHSA-6x34-89p7-95wg) | 在 Rancher 2.5.15 和 2.6.6 及之前的版本中发现了一个问题。授权逻辑缺陷允许在下游集群中通过集群角色模板绑定 (CRTB) 和项目角色模板绑定 (PRTB) 来提升权限。任何有权限创建/编辑 CRTB 或 PRTB 的用户（例如 `cluster-owner`、`manage cluster members`、`project-owner` 和 `manage project members`）都可以利用该漏洞，在同一集群的另一个项目或不同下游集群的另一个项目中获得所有者权限。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36783](https://github.com/rancher/rancher/security/advisories/GHSA-8w87-58w6-hfv8) | 2.5.12 到 2.6.3 的 Rancher 版本无法正确清理集群模板 answer 中的凭证。此错误可能会导致明文存储以及凭证、密码和 API 令牌被暴露。在 Rancher 中，已认证的 `Cluster Owner`、`Cluster Member`、`Project Owner` 和 `Project Member` 可以在 `/v1/management.cattle.io.clusters`、`/v3/clusters` 和 `/k8s/clusters/local/apis/management.cattle.io/v3/clusters` 端点上看到暴露的凭证。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36782](https://github.com/rancher/rancher/security/advisories/GHSA-g7j7-h4q8-8w2f) | 在 2.5.15 到 2.6.6 的 Rancher 版本中发现了一个问题，其中密码、API 密钥和 Rancher 的 ServiceAccount 令牌（用于配置集群）等敏感字段直接以明文形式存储在 `Cluster` 等 Kubernetes 对象上（例如，`cluster.management.cattle.io`）。任何能够读取 Kubernetes API 中的对象的用户都可以检索这些敏感数据的明文版本。该问题由 Florian Struck（来自 [Continum AG](https://www.continum.net/)）和 [Marco Stuurman](https://github.com/fe-ax)（来自 [Shock Media B.V.](https://www.shockmedia.nl/)）发现并报告。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](../../pages-for-subheaders/about-rke1-templates.md)配置 [Weave](../../faq/container-network-interface-providers.md#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://www.weave.works/docs/net/latest/tasks/manage/security-untrusted-networks/)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](../../pages-for-subheaders/about-rke1-templates.md)配置 [Weave](../../faq/container-network-interface-providers.md#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://github.com/weaveworks/weave/blob/master/site/tasks/manage/security-untrusted-networks.md)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.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) | 在 Rancher 2.5.0 到 2.5.12 和 Rancher 2.6.0 到 2.6.3 中发现了一个漏洞，该漏洞允许能创建或更新[全局角色](../../pages-for-subheaders/manage-role-based-access-control-rbac.md)的用户将他们或其他用户升级为管理员。全局角色能授予用户 Rancher 级别的权限，例如能创建集群。在已识别的 Rancher 版本中，如果用户被授予了编辑或创建全局角色的权限，他们不仅仅能授予他们已经拥有的权限。此漏洞影响使用能够创建或编辑全局角色的非管理员用户的客户。此场景最常见的用例是 `restricted-admin` 角色。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.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) | 此漏洞仅影响在 Rancher 中使用 `restricted-admin` 角色的客户。在 Rancher 2.5.0 到 2.5.12 和 2.6.0 到 2.6.3 中发现了一个漏洞，其中 `cattle-global-data` 命名空间中的 `global-data` 角色授予了应用商店的写权限。由于具有任何级别的应用商店访问权限的用户都会绑定到 `global-data` 角色，因此这些用户都能写入模板 `CatalogTemplates`) 和模板版本 (`CatalogTemplateVersions`)。在 Rancher 中创建的新用户默认分配到 `user` 角色（普通用户），该角色本不该具有写入应用商店的权限。此漏洞提升了能写入应用商店模板和应用商店模板版本资源的用户的权限。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.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) | 此漏洞仅影响使用经过认证的 Git 和/或 Helm 仓库通过 [Fleet](../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) 进行持续交付的客户。在 [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) 之前版本中的 `go-getter` 库中发现了一个问题，错误消息中没有删除 Base64 编码的 SSH 私钥，导致该信息暴露。Rancher 中 [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9) 之前的 Fleet 版本使用了该库的漏洞版本。此问题影响 Rancher 2.5.0 到 2.5.12（包括 2.5.12）以及 2.6.0 到 2.6.3（包括 2.6.3）。该问题由 Raft Engineering 的 Dagan Henderson 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
|
||||
-17
@@ -102,20 +102,3 @@ title: 网络
|
||||
* `read tcp: i/o timeout`
|
||||
|
||||
有关在 Rancher 和集群节点之间使用 Google Cloud VPN 时如何正确配置 MTU 的示例，请参阅 [Google Cloud VPN：MTU 注意事项](https://cloud.google.com/vpn/docs/concepts/mtu-considerations#gateway_mtu_vs_system_mtu)。
|
||||
|
||||
### 已解决的问题
|
||||
|
||||
#### 由于缺少节点注释，使用 Canal/Flannel 时覆盖网络中断
|
||||
|
||||
| | |
|
||||
|------------|------------|
|
||||
| GitHub issue | [#13644](https://github.com/rancher/rancher/issues/13644) |
|
||||
| 解决于 | v2.1.2 |
|
||||
|
||||
要检查你的集群是否受到影响，运行以下命令来列出损坏的节点（此命令要求安装 `jq`）：
|
||||
|
||||
```
|
||||
kubectl get nodes -o json | jq '.items[].metadata | select(.annotations["flannel.alpha.coreos.com/public-ip"] == null or .annotations["flannel.alpha.coreos.com/kube-subnet-manager"] == null or .annotations["flannel.alpha.coreos.com/backend-type"] == null or .annotations["flannel.alpha.coreos.com/backend-data"] == null) | .name'
|
||||
```
|
||||
|
||||
如果没有输出，则集群没有影响。
|
||||
|
||||
+1
-1
@@ -90,7 +90,7 @@ Kubernetes worker 需要打开 TCP 端口 `6783`（控制端口）、UDP 端口
|
||||
|
||||
有关详细信息，请参阅以下页面：
|
||||
|
||||
- [Weave Net 官网](https://www.weave.works/)
|
||||
- [Weave Net 官网](https://github.com/weaveworks/weave/blob/master/site/overview.md)
|
||||
|
||||
### RKE2 Kubernetes 集群
|
||||
|
||||
|
||||
+2
-2
@@ -66,7 +66,7 @@ StatefulSet 管理 Pod 的部署和扩展，同时为每个 Pod 维护一个粘
|
||||
1. 单击 **StatefulSet**。
|
||||
1. 在**卷声明模板**选项卡上，单击**添加声明模板**。
|
||||
1. 输入持久卷的名称。
|
||||
1. 在*存储类*\*字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**存储类**字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**挂载点**字段中，输入工作负载将用于访问卷的路径。
|
||||
1. 点击**启动**。
|
||||
|
||||
@@ -80,7 +80,7 @@ StatefulSet 管理 Pod 的部署和扩展，同时为每个 Pod 维护一个粘
|
||||
1. 单击 **⋮ > 编辑配置**，转到使用由 StorageClass 配置的存储的工作负载。
|
||||
1. 在**卷声明模板**中，单击**添加声明模板**。
|
||||
1. 输入持久卷名称。
|
||||
1. 在*存储类*\*字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**存储类**字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**挂载点**字段中，输入工作负载将用于访问卷的路径。
|
||||
1. 单击**保存**。
|
||||
|
||||
|
||||
+1
-1
@@ -300,7 +300,7 @@ title: 通过 AWS EC2 Auto Scaling 组使用 Cluster Autoscaler
|
||||
| max-node-provision-time | "15m" | CA 等待节点配置的最长时间 |
|
||||
| nodes | - | 以云提供商接受的格式设置节点组的最小、最大大小和其他配置数据。可以多次使用。格式是 `<min>:<max>:<other...>`。 |
|
||||
| node-group-auto-discovery | - | 节点组自动发现的一个或多个定义。定义表示为 `<name of discoverer>:[<key>[=<value>]]` |
|
||||
| estimator | - | "binpacking" | 用于扩容的资源评估器类型。可用值：["binpacking"] |
|
||||
| estimator |"binpacking" | 用于扩容的资源评估器类型。可用值：["binpacking"] |
|
||||
| expander | "random" | 要在扩容中使用的节点组扩展器的类型。可用值：`["random","most-pods","least-waste","price","priority"]` |
|
||||
| ignore-daemonsets-utilization | false | CA 为了缩容而计算资源利用率时，是否应忽略 DaemonSet pod |
|
||||
| ignore-mirror-pods-utilization | false | CA 为了缩容而计算资源利用率时，是否应忽略 Mirror pod |
|
||||
|
||||
+3
-3
@@ -140,13 +140,13 @@ Rancher 与以下开箱即用的网络提供商兼容：
|
||||
|
||||
#### CoreDNS
|
||||
|
||||
默认情况下，[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS，则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置，请参阅 [RKE2 文档](https://docs.rke2.io/networking#coredns)。
|
||||
默认情况下，[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS，则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#coredns)。
|
||||
|
||||
#### NGINX Ingress
|
||||
|
||||
如果你想使用高可用性配置来发布应用，并且你使用没有原生负载均衡功能的云提供商来托管主机，请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
如果你想使用高可用性配置来发布应用，并且你使用没有原生负载均衡功能的云提供商来托管主机，请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller)。
|
||||
|
||||
有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller)。
|
||||
|
||||
#### Metrics Server
|
||||
|
||||
|
||||
+1
-1
@@ -27,7 +27,7 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
| [CVE-2022-31247](https://github.com/rancher/rancher/security/advisories/GHSA-6x34-89p7-95wg) | 在 Rancher 2.5.15 和 2.6.6 及之前的版本中发现了一个问题。授权逻辑缺陷允许在下游集群中通过集群角色模板绑定 (CRTB) 和项目角色模板绑定 (PRTB) 来提升权限。任何有权限创建/编辑 CRTB 或 PRTB 的用户（例如 `cluster-owner`、`manage cluster members`、`project-owner` 和 `manage project members`）都可以利用该漏洞，在同一集群的另一个项目或不同下游集群的另一个项目中获得所有者权限。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36783](https://github.com/rancher/rancher/security/advisories/GHSA-8w87-58w6-hfv8) | 2.5.12 到 2.6.3 的 Rancher 版本无法正确清理集群模板 answer 中的凭证。此错误可能会导致明文存储以及凭证、密码和 API 令牌被暴露。在 Rancher 中，已认证的 `Cluster Owner`、`Cluster Member`、`Project Owner` 和 `Project Member` 可以在 `/v1/management.cattle.io.clusters`、`/v3/clusters` 和 `/k8s/clusters/local/apis/management.cattle.io/v3/clusters` 端点上看到暴露的凭证。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36782](https://github.com/rancher/rancher/security/advisories/GHSA-g7j7-h4q8-8w2f) | 在 2.5.15 到 2.6.6 的 Rancher 版本中发现了一个问题，其中密码、API 密钥和 Rancher 的 ServiceAccount 令牌（用于配置集群）等敏感字段直接以明文形式存储在 `Cluster` 等 Kubernetes 对象上（例如，`cluster.management.cattle.io`）。任何能够读取 Kubernetes API 中的对象的用户都可以检索这些敏感数据的明文版本。该问题由 Florian Struck（来自 [Continum AG](https://www.continum.net/)）和 [Marco Stuurman](https://github.com/fe-ax)（来自 [Shock Media B.V.](https://www.shockmedia.nl/)）发现并报告。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rke-templates/)配置 [Weave](https://rancher.com/docs/rancher/v2.6/en/faq/networking/cni-providers/#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://www.weave.works/docs/net/latest/tasks/manage/security-untrusted-networks/)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rke-templates/)配置 [Weave](https://rancher.com/docs/rancher/v2.6/en/faq/networking/cni-providers/#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://github.com/weaveworks/weave/blob/master/site/tasks/manage/security-untrusted-networks.md)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.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) | 在 Rancher 2.5.0 到 2.5.12 和 Rancher 2.6.0 到 2.6.3 中发现了一个漏洞，该漏洞允许能创建或更新[全局角色](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rbac/)的用户将他们或其他用户升级为管理员。全局角色能授予用户 Rancher 级别的权限，例如能创建集群。在已识别的 Rancher 版本中，如果用户被授予了编辑或创建全局角色的权限，他们不仅仅能授予他们已经拥有的权限。此漏洞影响使用能够创建或编辑全局角色的非管理员用户的客户。此场景最常见的用例是 `restricted-admin` 角色。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.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) | 此漏洞仅影响在 Rancher 中使用 `restricted-admin` 角色的客户。在 Rancher 2.5.0 到 2.5.12 和 2.6.0 到 2.6.3 中发现了一个漏洞，其中 `cattle-global-data` 命名空间中的 `global-data` 角色授予了应用商店的写权限。由于具有任何级别的应用商店访问权限的用户都会绑定到 `global-data` 角色，因此这些用户都能写入模板 `CatalogTemplates`) 和模板版本 (`CatalogTemplateVersions`)。在 Rancher 中创建的新用户默认分配到 `user` 角色（普通用户），该角色本不该具有写入应用商店的权限。此漏洞提升了能写入应用商店模板和应用商店模板版本资源的用户的权限。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.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) | 此漏洞仅影响使用经过认证的 Git 和/或 Helm 仓库通过 [Fleet](https://rancher.com/docs/rancher/v2.6/en/deploy-across-clusters/fleet/) 进行持续交付的客户。在 [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) 之前版本中的 `go-getter` 库中发现了一个问题，错误消息中没有删除 Base64 编码的 SSH 私钥，导致该信息暴露。Rancher 中 [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9) 之前的 Fleet 版本使用了该库的漏洞版本。此问题影响 Rancher 2.5.0 到 2.5.12（包括 2.5.12）以及 2.6.0 到 2.6.3（包括 2.6.3）。该问题由 Raft Engineering 的 Dagan Henderson 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
|
||||
-17
@@ -102,20 +102,3 @@ title: 网络
|
||||
* `read tcp: i/o timeout`
|
||||
|
||||
有关在 Rancher 和集群节点之间使用 Google Cloud VPN 时如何正确配置 MTU 的示例，请参阅 [Google Cloud VPN：MTU 注意事项](https://cloud.google.com/vpn/docs/concepts/mtu-considerations#gateway_mtu_vs_system_mtu)。
|
||||
|
||||
### 已解决的问题
|
||||
|
||||
#### 由于缺少节点注释，使用 Canal/Flannel 时覆盖网络中断
|
||||
|
||||
| | |
|
||||
|------------|------------|
|
||||
| GitHub issue | [#13644](https://github.com/rancher/rancher/issues/13644) |
|
||||
| 解决于 | v2.1.2 |
|
||||
|
||||
要检查你的集群是否受到影响，运行以下命令来列出损坏的节点（此命令要求安装 `jq`）：
|
||||
|
||||
```
|
||||
kubectl get nodes -o json | jq '.items[].metadata | select(.annotations["flannel.alpha.coreos.com/public-ip"] == null or .annotations["flannel.alpha.coreos.com/kube-subnet-manager"] == null or .annotations["flannel.alpha.coreos.com/backend-type"] == null or .annotations["flannel.alpha.coreos.com/backend-data"] == null) | .name'
|
||||
```
|
||||
|
||||
如果没有输出，则集群没有影响。
|
||||
|
||||
+1
-1
@@ -90,7 +90,7 @@ Kubernetes worker 需要打开 TCP 端口 `6783`（控制端口）、UDP 端口
|
||||
|
||||
有关详细信息，请参阅以下页面：
|
||||
|
||||
- [Weave Net 官网](https://www.weave.works/)
|
||||
- [Weave Net 官网](https://github.com/weaveworks/weave/blob/master/site/overview.md)
|
||||
|
||||
### RKE2 Kubernetes 集群
|
||||
|
||||
|
||||
+2
-2
@@ -66,7 +66,7 @@ StatefulSet 管理 Pod 的部署和扩展，同时为每个 Pod 维护一个粘
|
||||
1. 单击 **StatefulSet**。
|
||||
1. 在**卷声明模板**选项卡上，单击**添加声明模板**。
|
||||
1. 输入持久卷的名称。
|
||||
1. 在*存储类*\*字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**存储类**字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**挂载点**字段中，输入工作负载将用于访问卷的路径。
|
||||
1. 点击**启动**。
|
||||
|
||||
@@ -80,7 +80,7 @@ StatefulSet 管理 Pod 的部署和扩展，同时为每个 Pod 维护一个粘
|
||||
1. 单击 **⋮ > 编辑配置**，转到使用由 StorageClass 配置的存储的工作负载。
|
||||
1. 在**卷声明模板**中，单击**添加声明模板**。
|
||||
1. 输入持久卷名称。
|
||||
1. 在*存储类*\*字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**存储类**字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**挂载点**字段中，输入工作负载将用于访问卷的路径。
|
||||
1. 单击**保存**。
|
||||
|
||||
|
||||
+1
-1
@@ -300,7 +300,7 @@ title: 通过 AWS EC2 Auto Scaling 组使用 Cluster Autoscaler
|
||||
| max-node-provision-time | "15m" | CA 等待节点配置的最长时间 |
|
||||
| nodes | - | 以云提供商接受的格式设置节点组的最小、最大大小和其他配置数据。可以多次使用。格式是 `<min>:<max>:<other...>`。 |
|
||||
| node-group-auto-discovery | - | 节点组自动发现的一个或多个定义。定义表示为 `<name of discoverer>:[<key>[=<value>]]` |
|
||||
| estimator | - | "binpacking" | 用于扩容的资源评估器类型。可用值：["binpacking"] |
|
||||
| estimator |"binpacking" | 用于扩容的资源评估器类型。可用值：["binpacking"] |
|
||||
| expander | "random" | 要在扩容中使用的节点组扩展器的类型。可用值：`["random","most-pods","least-waste","price","priority"]` |
|
||||
| ignore-daemonsets-utilization | false | CA 为了缩容而计算资源利用率时，是否应忽略 DaemonSet pod |
|
||||
| ignore-mirror-pods-utilization | false | CA 为了缩容而计算资源利用率时，是否应忽略 Mirror pod |
|
||||
|
||||
+1
-1
@@ -185,7 +185,7 @@ stringData:
|
||||
|
||||
:::note
|
||||
|
||||
请记住，如果使用此安装选项，你必须自行管理 CAPI Operator 的安装。你可以参照 Rancher Turtles 文档中的 [CAPI Operator 指南](https://turtles.docs.rancher.com/tasks/capi-operator/intro)
|
||||
请记住，如果使用此安装选项，你必须自行管理 CAPI Operator 的安装。你可以参照 Rancher Turtles 文档中的 [CAPI Operator 指南](https://turtles.docs.rancher.com/contributing/install_capi_operator)
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -85,7 +85,7 @@ The `rancher-restricted` template is provided by Rancher to enforce the highly-r
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
K3s v1.24 and older support [Pod Security Policy (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) for controlling pod security.
|
||||
K3s v1.24 and older support [Pod Security Policy (PSP)](https://github.com/kubernetes/website/blob/release-1.24/content/en/docs/concepts/security/pod-security-policy.md) for controlling pod security.
|
||||
|
||||
You can enable PSPs by passing the following flags in the cluster configuration in Rancher:
|
||||
|
||||
|
||||
+3
-3
@@ -140,13 +140,13 @@ Rancher 与以下开箱即用的网络提供商兼容：
|
||||
|
||||
#### CoreDNS
|
||||
|
||||
默认情况下，[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS，则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置，请参阅 [RKE2 文档](https://docs.rke2.io/networking#coredns)。
|
||||
默认情况下，[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS，则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#coredns)。
|
||||
|
||||
#### NGINX Ingress
|
||||
|
||||
如果你想使用高可用性配置来发布应用，并且你使用没有原生负载均衡功能的云提供商来托管主机，请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
如果你想使用高可用性配置来发布应用，并且你使用没有原生负载均衡功能的云提供商来托管主机，请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller)。
|
||||
|
||||
有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller)。
|
||||
|
||||
#### Metrics Server
|
||||
|
||||
|
||||
+1
-1
@@ -102,7 +102,7 @@ Rancher 提供了 `rancher-restricted` 模板，用于强制执行高度限制
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
K3s v1.24 及更早版本支持 [Pod 安全策略 (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) 以控制 Pod 安全性。
|
||||
K3s v1.24 及更早版本支持 [Pod 安全策略 (PSP)](https://github.com/kubernetes/website/blob/release-1.24/content/en/docs/concepts/security/pod-security-policy.md) 以控制 Pod 安全性。
|
||||
|
||||
你可以在 Rancher 中通过集群配置，传递以下标志来启用 PSPs：
|
||||
|
||||
|
||||
+1
-1
@@ -27,7 +27,7 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
| [CVE-2022-31247](https://github.com/rancher/rancher/security/advisories/GHSA-6x34-89p7-95wg) | 在 Rancher 2.5.15 和 2.6.6 及之前的版本中发现了一个问题。授权逻辑缺陷允许在下游集群中通过集群角色模板绑定 (CRTB) 和项目角色模板绑定 (PRTB) 来提升权限。任何有权限创建/编辑 CRTB 或 PRTB 的用户（例如 `cluster-owner`、`manage cluster members`、`project-owner` 和 `manage project members`）都可以利用该漏洞，在同一集群的另一个项目或不同下游集群的另一个项目中获得所有者权限。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36783](https://github.com/rancher/rancher/security/advisories/GHSA-8w87-58w6-hfv8) | 2.5.12 到 2.6.3 的 Rancher 版本无法正确清理集群模板 answer 中的凭证。此错误可能会导致明文存储以及凭证、密码和 API 令牌被暴露。在 Rancher 中，已认证的 `Cluster Owner`、`Cluster Member`、`Project Owner` 和 `Project Member` 可以在 `/v1/management.cattle.io.clusters`、`/v3/clusters` 和 `/k8s/clusters/local/apis/management.cattle.io/v3/clusters` 端点上看到暴露的凭证。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36782](https://github.com/rancher/rancher/security/advisories/GHSA-g7j7-h4q8-8w2f) | 在 2.5.15 到 2.6.6 的 Rancher 版本中发现了一个问题，其中密码、API 密钥和 Rancher 的 ServiceAccount 令牌（用于配置集群）等敏感字段直接以明文形式存储在 `Cluster` 等 Kubernetes 对象上（例如，`cluster.management.cattle.io`）。任何能够读取 Kubernetes API 中的对象的用户都可以检索这些敏感数据的明文版本。该问题由 Florian Struck（来自 [Continum AG](https://www.continum.net/)）和 [Marco Stuurman](https://github.com/fe-ax)（来自 [Shock Media B.V.](https://www.shockmedia.nl/)）发现并报告。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](../../pages-for-subheaders/about-rke1-templates.md)配置 [Weave](../../faq/container-network-interface-providers.md#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://www.weave.works/docs/net/latest/tasks/manage/security-untrusted-networks/)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](../../pages-for-subheaders/about-rke1-templates.md)配置 [Weave](../../faq/container-network-interface-providers.md#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://github.com/weaveworks/weave/blob/master/site/tasks/manage/security-untrusted-networks.md)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.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) | 在 Rancher 2.5.0 到 2.5.12 和 Rancher 2.6.0 到 2.6.3 中发现了一个漏洞，该漏洞允许能创建或更新[全局角色](../../pages-for-subheaders/manage-role-based-access-control-rbac.md)的用户将他们或其他用户升级为管理员。全局角色能授予用户 Rancher 级别的权限，例如能创建集群。在已识别的 Rancher 版本中，如果用户被授予了编辑或创建全局角色的权限，他们不仅仅能授予他们已经拥有的权限。此漏洞影响使用能够创建或编辑全局角色的非管理员用户的客户。此场景最常见的用例是 `restricted-admin` 角色。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.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) | 此漏洞仅影响在 Rancher 中使用 `restricted-admin` 角色的客户。在 Rancher 2.5.0 到 2.5.12 和 2.6.0 到 2.6.3 中发现了一个漏洞，其中 `cattle-global-data` 命名空间中的 `global-data` 角色授予了应用商店的写权限。由于具有任何级别的应用商店访问权限的用户都会绑定到 `global-data` 角色，因此这些用户都能写入模板 `CatalogTemplates`) 和模板版本 (`CatalogTemplateVersions`)。在 Rancher 中创建的新用户默认分配到 `user` 角色（普通用户），该角色本不该具有写入应用商店的权限。此漏洞提升了能写入应用商店模板和应用商店模板版本资源的用户的权限。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.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) | 此漏洞仅影响使用经过认证的 Git 和/或 Helm 仓库通过 [Fleet](../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) 进行持续交付的客户。在 [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) 之前版本中的 `go-getter` 库中发现了一个问题，错误消息中没有删除 Base64 编码的 SSH 私钥，导致该信息暴露。Rancher 中 [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9) 之前的 Fleet 版本使用了该库的漏洞版本。此问题影响 Rancher 2.5.0 到 2.5.12（包括 2.5.12）以及 2.6.0 到 2.6.3（包括 2.6.3）。该问题由 Raft Engineering 的 Dagan Henderson 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
|
||||
-17
@@ -102,20 +102,3 @@ title: 网络
|
||||
* `read tcp: i/o timeout`
|
||||
|
||||
有关在 Rancher 和集群节点之间使用 Google Cloud VPN 时如何正确配置 MTU 的示例，请参阅 [Google Cloud VPN：MTU 注意事项](https://cloud.google.com/vpn/docs/concepts/mtu-considerations#gateway_mtu_vs_system_mtu)。
|
||||
|
||||
### 已解决的问题
|
||||
|
||||
#### 由于缺少节点注释，使用 Canal/Flannel 时覆盖网络中断
|
||||
|
||||
| | |
|
||||
|------------|------------|
|
||||
| GitHub issue | [#13644](https://github.com/rancher/rancher/issues/13644) |
|
||||
| 解决于 | v2.1.2 |
|
||||
|
||||
要检查你的集群是否受到影响，运行以下命令来列出损坏的节点（此命令要求安装 `jq`）：
|
||||
|
||||
```
|
||||
kubectl get nodes -o json | jq '.items[].metadata | select(.annotations["flannel.alpha.coreos.com/public-ip"] == null or .annotations["flannel.alpha.coreos.com/kube-subnet-manager"] == null or .annotations["flannel.alpha.coreos.com/backend-type"] == null or .annotations["flannel.alpha.coreos.com/backend-data"] == null) | .name'
|
||||
```
|
||||
|
||||
如果没有输出，则集群没有影响。
|
||||
|
||||
+1
-1
@@ -90,7 +90,7 @@ Kubernetes worker 需要打开 TCP 端口 `6783`（控制端口）、UDP 端口
|
||||
|
||||
有关详细信息，请参阅以下页面：
|
||||
|
||||
- [Weave Net 官网](https://www.weave.works/)
|
||||
- [Weave Net 官网](https://github.com/weaveworks/weave/blob/master/site/overview.md)
|
||||
|
||||
### RKE2 Kubernetes 集群
|
||||
|
||||
|
||||
+2
-2
@@ -66,7 +66,7 @@ StatefulSet 管理 Pod 的部署和扩展，同时为每个 Pod 维护一个粘
|
||||
1. 单击 **StatefulSet**。
|
||||
1. 在**卷声明模板**选项卡上，单击**添加声明模板**。
|
||||
1. 输入持久卷的名称。
|
||||
1. 在*存储类*\*字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**存储类**字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**挂载点**字段中，输入工作负载将用于访问卷的路径。
|
||||
1. 点击**启动**。
|
||||
|
||||
@@ -80,7 +80,7 @@ StatefulSet 管理 Pod 的部署和扩展，同时为每个 Pod 维护一个粘
|
||||
1. 单击 **⋮ > 编辑配置**，转到使用由 StorageClass 配置的存储的工作负载。
|
||||
1. 在**卷声明模板**中，单击**添加声明模板**。
|
||||
1. 输入持久卷名称。
|
||||
1. 在*存储类*\*字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**存储类**字段中，选择将为此 StatefulSet 管理的 pod 动态配置存储的 StorageClass。
|
||||
1. 在**挂载点**字段中，输入工作负载将用于访问卷的路径。
|
||||
1. 单击**保存**。
|
||||
|
||||
|
||||
+1
-1
@@ -300,7 +300,7 @@ title: 通过 AWS EC2 Auto Scaling 组使用 Cluster Autoscaler
|
||||
| max-node-provision-time | "15m" | CA 等待节点配置的最长时间 |
|
||||
| nodes | - | 以云提供商接受的格式设置节点组的最小、最大大小和其他配置数据。可以多次使用。格式是 `<min>:<max>:<other...>`。 |
|
||||
| node-group-auto-discovery | - | 节点组自动发现的一个或多个定义。定义表示为 `<name of discoverer>:[<key>[=<value>]]` |
|
||||
| estimator | - | "binpacking" | 用于扩容的资源评估器类型。可用值：["binpacking"] |
|
||||
| estimator |"binpacking" | 用于扩容的资源评估器类型。可用值：["binpacking"] |
|
||||
| expander | "random" | 要在扩容中使用的节点组扩展器的类型。可用值：`["random","most-pods","least-waste","price","priority"]` |
|
||||
| ignore-daemonsets-utilization | false | CA 为了缩容而计算资源利用率时，是否应忽略 DaemonSet pod |
|
||||
| ignore-mirror-pods-utilization | false | CA 为了缩容而计算资源利用率时，是否应忽略 Mirror pod |
|
||||
|
||||
+1
-1
@@ -185,7 +185,7 @@ stringData:
|
||||
|
||||
:::note
|
||||
|
||||
请记住，如果使用此安装选项，你必须自行管理 CAPI Operator 的安装。你可以参照 Rancher Turtles 文档中的 [CAPI Operator 指南](https://turtles.docs.rancher.com/tasks/capi-operator/intro)
|
||||
请记住，如果使用此安装选项，你必须自行管理 CAPI Operator 的安装。你可以参照 Rancher Turtles 文档中的 [CAPI Operator 指南](https://turtles.docs.rancher.com/contributing/install_capi_operator)
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -85,7 +85,7 @@ The `rancher-restricted` template is provided by Rancher to enforce the highly-r
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
K3s v1.24 and older support [Pod Security Policy (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) for controlling pod security.
|
||||
K3s v1.24 and older support [Pod Security Policy (PSP)](https://github.com/kubernetes/website/blob/release-1.24/content/en/docs/concepts/security/pod-security-policy.md) for controlling pod security.
|
||||
|
||||
You can enable PSPs by passing the following flags in the cluster configuration in Rancher:
|
||||
|
||||
|
||||
+3
-3
@@ -140,13 +140,13 @@ Rancher 与以下开箱即用的网络提供商兼容：
|
||||
|
||||
#### CoreDNS
|
||||
|
||||
默认情况下，[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS，则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置，请参阅 [RKE2 文档](https://docs.rke2.io/networking#coredns)。
|
||||
默认情况下，[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS，则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#coredns)。
|
||||
|
||||
#### NGINX Ingress
|
||||
|
||||
如果你想使用高可用性配置来发布应用，并且你使用没有原生负载均衡功能的云提供商来托管主机，请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
如果你想使用高可用性配置来发布应用，并且你使用没有原生负载均衡功能的云提供商来托管主机，请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller)。
|
||||
|
||||
有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
有关其他配置选项，请参阅 [RKE2 文档](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller)。
|
||||
|
||||
#### Metrics Server
|
||||
|
||||
|
||||
+1
-1
@@ -102,7 +102,7 @@ Rancher 提供了 `rancher-restricted` 模板，用于强制执行高度限制
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
K3s v1.24 及更早版本支持 [Pod 安全策略 (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) 以控制 Pod 安全性。
|
||||
K3s v1.24 及更早版本支持 [Pod 安全策略 (PSP)](https://github.com/kubernetes/website/blob/release-1.24/content/en/docs/concepts/security/pod-security-policy.md) 以控制 Pod 安全性。
|
||||
|
||||
你可以在 Rancher 中通过集群配置，传递以下标志来启用 PSPs：
|
||||
|
||||
|
||||
+1
-1
@@ -28,7 +28,7 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
| [CVE-2022-31247](https://github.com/rancher/rancher/security/advisories/GHSA-6x34-89p7-95wg) | 在 Rancher 2.5.15 和 2.6.6 及之前的版本中发现了一个问题。授权逻辑缺陷允许在下游集群中通过集群角色模板绑定 (CRTB) 和项目角色模板绑定 (PRTB) 来提升权限。任何有权限创建/编辑 CRTB 或 PRTB 的用户（例如 `cluster-owner`、`manage cluster members`、`project-owner` 和 `manage project members`）都可以利用该漏洞，在同一集群的另一个项目或不同下游集群的另一个项目中获得所有者权限。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36783](https://github.com/rancher/rancher/security/advisories/GHSA-8w87-58w6-hfv8) | 2.5.12 到 2.6.3 的 Rancher 版本无法正确清理集群模板 answer 中的凭证。此错误可能会导致明文存储以及凭证、密码和 API 令牌被暴露。在 Rancher 中，已认证的 `Cluster Owner`、`Cluster Member`、`Project Owner` 和 `Project Member` 可以在 `/v1/management.cattle.io.clusters`、`/v3/clusters` 和 `/k8s/clusters/local/apis/management.cattle.io/v3/clusters` 端点上看到暴露的凭证。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36782](https://github.com/rancher/rancher/security/advisories/GHSA-g7j7-h4q8-8w2f) | 在 2.5.15 到 2.6.6 的 Rancher 版本中发现了一个问题，其中密码、API 密钥和 Rancher 的 ServiceAccount 令牌（用于配置集群）等敏感字段直接以明文形式存储在 `Cluster` 等 Kubernetes 对象上（例如，`cluster.management.cattle.io`）。任何能够读取 Kubernetes API 中的对象的用户都可以检索这些敏感数据的明文版本。该问题由 Florian Struck（来自 [Continum AG](https://www.continum.net/)）和 [Marco Stuurman](https://github.com/fe-ax)（来自 [Shock Media B.V.](https://www.shockmedia.nl/)）发现并报告。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](../../pages-for-subheaders/about-rke1-templates.md)配置 [Weave](../../faq/container-network-interface-providers.md#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://www.weave.works/docs/net/latest/tasks/manage/security-untrusted-networks/)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](../../pages-for-subheaders/about-rke1-templates.md)配置 [Weave](../../faq/container-network-interface-providers.md#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://github.com/weaveworks/weave/blob/master/site/tasks/manage/security-untrusted-networks.md)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.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) | 在 Rancher 2.5.0 到 2.5.12 和 Rancher 2.6.0 到 2.6.3 中发现了一个漏洞，该漏洞允许能创建或更新[全局角色](../../pages-for-subheaders/manage-role-based-access-control-rbac.md)的用户将他们或其他用户升级为管理员。全局角色能授予用户 Rancher 级别的权限，例如能创建集群。在已识别的 Rancher 版本中，如果用户被授予了编辑或创建全局角色的权限，他们不仅仅能授予他们已经拥有的权限。此漏洞影响使用能够创建或编辑全局角色的非管理员用户的客户。此场景最常见的用例是 `restricted-admin` 角色。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.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) | 此漏洞仅影响在 Rancher 中使用 `restricted-admin` 角色的客户。在 Rancher 2.5.0 到 2.5.12 和 2.6.0 到 2.6.3 中发现了一个漏洞，其中 `cattle-global-data` 命名空间中的 `global-data` 角色授予了应用商店的写权限。由于具有任何级别的应用商店访问权限的用户都会绑定到 `global-data` 角色，因此这些用户都能写入模板 `CatalogTemplates`) 和模板版本 (`CatalogTemplateVersions`)。在 Rancher 中创建的新用户默认分配到 `user` 角色（普通用户），该角色本不该具有写入应用商店的权限。此漏洞提升了能写入应用商店模板和应用商店模板版本资源的用户的权限。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.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) | 此漏洞仅影响使用经过认证的 Git 和/或 Helm 仓库通过 [Fleet](../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) 进行持续交付的客户。在 [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) 之前版本中的 `go-getter` 库中发现了一个问题，错误消息中没有删除 Base64 编码的 SSH 私钥，导致该信息暴露。Rancher 中 [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9) 之前的 Fleet 版本使用了该库的漏洞版本。此问题影响 Rancher 2.5.0 到 2.5.12（包括 2.5.12）以及 2.6.0 到 2.6.3（包括 2.6.3）。该问题由 Raft Engineering 的 Dagan Henderson 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
|
||||
-17
@@ -102,20 +102,3 @@ title: 网络
|
||||
* `read tcp: i/o timeout`
|
||||
|
||||
有关在 Rancher 和集群节点之间使用 Google Cloud VPN 时如何正确配置 MTU 的示例，请参阅 [Google Cloud VPN：MTU 注意事项](https://cloud.google.com/vpn/docs/concepts/mtu-considerations#gateway_mtu_vs_system_mtu)。
|
||||
|
||||
### 已解决的问题
|
||||
|
||||
#### 由于缺少节点注释，使用 Canal/Flannel 时覆盖网络中断
|
||||
|
||||
| | |
|
||||
|------------|------------|
|
||||
| GitHub issue | [#13644](https://github.com/rancher/rancher/issues/13644) |
|
||||
| 解决于 | v2.1.2 |
|
||||
|
||||
要检查你的集群是否受到影响，运行以下命令来列出损坏的节点（此命令要求安装 `jq`）：
|
||||
|
||||
```
|
||||
kubectl get nodes -o json | jq '.items[].metadata | select(.annotations["flannel.alpha.coreos.com/public-ip"] == null or .annotations["flannel.alpha.coreos.com/kube-subnet-manager"] == null or .annotations["flannel.alpha.coreos.com/backend-type"] == null or .annotations["flannel.alpha.coreos.com/backend-data"] == null) | .name'
|
||||
```
|
||||
|
||||
如果没有输出，则集群没有影响。
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: API 参考
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/api-reference"/>
|
||||
</head>
|
||||
|
||||
:::note
|
||||
|
||||
目前，并非所有的 Rancher 资源都可以通过 Rancher Kubernetes API 操作。
|
||||
|
||||
:::
|
||||
|
||||
import ApiDocMdx from '@theme/ApiDocMdx';
|
||||
|
||||
<ApiDocMdx id="rancher-api" />
|
||||
@@ -0,0 +1,152 @@
|
||||
---
|
||||
title: API 快速入门指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/quickstart"/>
|
||||
</head>
|
||||
|
||||
你可以通过 Kubernetes API 访问 Rancher 的资源。本指南将帮助你以 Rancher 用户的身份开始使用此 API。
|
||||
|
||||
1. 在左上角，点击 **☰ > 全局设置**.
|
||||
2. 找到 `server-url` 字段并复制其地址。
|
||||
3. [创建](../reference-guides/user-settings/api-keys.md#创建-api-密钥)一个没有作用域的 Rancher API 密钥。
|
||||
|
||||
:::danger
|
||||
|
||||
没有作用域的 Rancher API 密钥授予用户可以访问的所有资源的无限制的访问权限。为防止未经授权的使用，此密钥应安全存储并经常轮换。
|
||||
|
||||
:::
|
||||
|
||||
4. 创建一个 `kubeconfig.yaml` 文件，将 `$SERVER_URL` 替换成上面从全局设置中复制的地址，并且将 `$API_KEY` 替换为上面创建的 Rancher API 密钥：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
clusters:
|
||||
- name: "rancher"
|
||||
cluster:
|
||||
server: "$SERVER_URL"
|
||||
|
||||
users:
|
||||
- name: "rancher"
|
||||
user:
|
||||
token: "$API_KEY"
|
||||
|
||||
contexts:
|
||||
- name: "rancher"
|
||||
context:
|
||||
user: "rancher"
|
||||
cluster: "rancher"
|
||||
|
||||
current-context: "rancher"
|
||||
```
|
||||
|
||||
你可以使用任何兼容的工具来引用这个文件，例如 kubectl 或 [client-go](https://github.com/kubernetes/client-go)。快速演示内容请参阅 [kubectl 示例](#api-kubectl-示例)
|
||||
|
||||
更多有关处理更复杂证书的设置信息，请参阅[指定 CA 证书](#指定-ca-证书)。
|
||||
|
||||
更多关于可用的 kubeconfig 选项，请参阅[上游文档](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。
|
||||
|
||||
## API kubectl 示例
|
||||
|
||||
在此示例中，我们将展示如何使用 kubectl 创建一个项目，然后删除它。关于其他可用的 Rancher 资源列表，请参阅 [API 参考](./api-reference.mdx)。
|
||||
|
||||
:::note
|
||||
|
||||
目前，并非所有的 Rancher 资源都可以通过 Rancher Kubernetes API 操作。
|
||||
|
||||
:::
|
||||
|
||||
1. 将 KUBECONFIG 环境变量设置为刚才创建的 kubeconfig 文件：
|
||||
|
||||
```bash
|
||||
export KUBECONFIG=$(pwd)/kubeconfig.yaml
|
||||
```
|
||||
|
||||
2. 使用 `kubectl explain` 查看项目的可用字段，或者复杂资源的子字段：
|
||||
|
||||
```bash
|
||||
kubectl explain projects
|
||||
kubectl explain projects.spec
|
||||
```
|
||||
|
||||
不是所有的资源都有详细的输出。
|
||||
|
||||
3. 在名称为 `project.yaml` 的文件中添加以下内容：
|
||||
|
||||
```yaml
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: Project
|
||||
metadata:
|
||||
# name 应在每个集群的所有项目中都是唯一的
|
||||
name: p-abc123
|
||||
# generateName 可以替代 `name` 来随机生成一个名称
|
||||
# generateName: p-
|
||||
# namespace 应与 spec.ClusterName 匹配
|
||||
namespace: local
|
||||
spec:
|
||||
# clusterName 应与目标集群的 `metadata.Name` 匹配
|
||||
clusterName: local
|
||||
description: Example Project
|
||||
# displayName 是人类可读的名称并且从 UI 中显示
|
||||
displayName: Example
|
||||
```
|
||||
|
||||
4. 创建项目：
|
||||
|
||||
```bash
|
||||
kubectl create -f project.yaml
|
||||
```
|
||||
|
||||
5. 删除项目：
|
||||
|
||||
项目删除的方式取决于项目名称的创建方式。
|
||||
|
||||
**A. 如果在创建项目时使用 `name`**：
|
||||
|
||||
```bash
|
||||
kubectl delete -f project.yaml
|
||||
```
|
||||
|
||||
**B. 如果你使用 `generateName`**：
|
||||
|
||||
将 `$PROJECT_NAME` 替换为 kubectl 创建项目后随机生成的项目名称。
|
||||
|
||||
```bash
|
||||
kubectl delete project $PROJECT_NAME -n local
|
||||
```
|
||||
|
||||
## 指定 CA 证书
|
||||
|
||||
为确保你的工具能够识别 Rancher 的 CA 证书，大多数设置都需要对上述模板进行额外修改。
|
||||
|
||||
1. 在左上角点击 **☰ > 全局设置**.
|
||||
2. 查找并复制 `ca-certs` 字段中的值。
|
||||
3. 将复制的值保存在名称为 `rancher.crt` 的文件中。
|
||||
|
||||
:::note
|
||||
如果你的 Rancher 实例由其他服务代理，你必须提取该服务正在使用的证书，并将其添加到 kubeconfig 文件中，如步骤 5 所示。
|
||||
:::
|
||||
|
||||
4. 以下命令会将 `rancher.crt` 转换为 base64 输出，除去所有换行符，并使用证书内容更新 kubeconfig 中的 cluster 选项，然后删除 `rancher.crt` 文件：
|
||||
|
||||
```bash
|
||||
export KUBECONFIG=$PATH_TO_RANCHER_KUBECONFIG
|
||||
kubectl config set clusters.rancher.certificate-authority-data $(cat rancher.crt | base64 -i - | tr -d '\n')
|
||||
rm rancher.crt
|
||||
```
|
||||
5. （可选项）如果你使用不受系统信任的自签名证书，则可以通过 kubectl 在 kubeconfig 中设置不安全选项：
|
||||
|
||||
:::danger
|
||||
|
||||
此选项不应该在生产环境中使用，因为它存在安全风险。
|
||||
|
||||
:::
|
||||
|
||||
```bash
|
||||
export KUBECONFIG=$PATH_TO_RANCHER_KUBECONFIG
|
||||
kubectl config set clusters.rancher.insecure-skip-tls-verify true
|
||||
```
|
||||
|
||||
如果你的 Rancher 实例由其他服务代理，你必须提取该服务正在使用的证书，并如上面演示的方法，将其添加到 kubeconfig 文件中。
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
title: 项目
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/workflows/projects"/>
|
||||
</head>
|
||||
|
||||
## 创建项目
|
||||
|
||||
项目资源只能在管理集群上创建，请参考下文了解如何[在管理集群中的项目下创建命名空间](#在项目中创建命名空间)
|
||||
|
||||
### 创建一个基本项目
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: Project
|
||||
metadata:
|
||||
generateName: p-
|
||||
namespace: c-m-abcde
|
||||
spec:
|
||||
clusterName: c-m-abcde
|
||||
displayName: myproject
|
||||
EOF
|
||||
```
|
||||
|
||||
使用 `metadata.generateName` 来确保一个唯一的项目 ID，但是需要注意 `kubectl apply` 不能与 `metadata.generateName` 一起使用，因此必须使用 `kubectl create` 来替代。
|
||||
|
||||
将 `metadata.namespace` 和 `spec.clusterName` 设置为项目所属的集群 ID。
|
||||
|
||||
如果你通过集群成员账户创建项目，则必须包含注释 `field.cattle.io/creatorId`，并将注释值设置为集群成员账号的用户 ID。
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: Project
|
||||
metadata:
|
||||
annotations:
|
||||
field.cattle.io/creatorId:
|
||||
user-id
|
||||
generateName: p-
|
||||
namespace: c-m-abcde
|
||||
spec:
|
||||
clusterName: c-m-abcde
|
||||
displayName: myproject
|
||||
EOF
|
||||
```
|
||||
|
||||
设置 `field.cattle.io/creatorId` 字段允许集群成员账户通过 `get` 命令查看项目资源，并可以在 Rancher UI 中查看项目。集群所有者和管理员账号不需要设置此注释。
|
||||
|
||||
### 创建一个具有 Resource Quota 的项目
|
||||
|
||||
请查看 [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/)。
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: Project
|
||||
metadata:
|
||||
generateName: p-
|
||||
namespace: c-m-abcde
|
||||
spec:
|
||||
clusterName: c-m-abcde
|
||||
displayName: myproject
|
||||
resourceQuota:
|
||||
limit:
|
||||
limitsCpu: 1000m
|
||||
namespaceDefaultResourceQuota:
|
||||
limit:
|
||||
limitsCpu: 50m
|
||||
EOF
|
||||
```
|
||||
|
||||
### 创建一个具有 Container Limit Ranges 的项目
|
||||
|
||||
请查看 [Kubernetes Limit Ranges](https://kubernetes.io/docs/concepts/policy/limit-range/)。
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: Project
|
||||
metadata:
|
||||
generateName: p-
|
||||
namespace: c-m-abcde
|
||||
spec:
|
||||
clusterName: c-m-abcde
|
||||
displayName: myproject
|
||||
containerDefaultResourceLimit:
|
||||
limitsCpu: 100m
|
||||
limitsMemory: 100Mi
|
||||
requestsCpu: 50m
|
||||
requestsMemory: 50Mi
|
||||
```
|
||||
|
||||
## 在项目中创建命名空间
|
||||
|
||||
项目资源保存在管理集群中，即使该项目使用于托管集群也是如此。项目下的命名空间保存在托管集群中。
|
||||
|
||||
在管理集群上查找你正在管理的集群的项目 ID，因为它是使用 `metadata.generateName` 生成的：
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
在托管集群上，使用项目注释创建命名空间:
|
||||
|
||||
```bash
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: mynamespace
|
||||
annotations:
|
||||
field.cattle.io/projectId: c-m-abcde:p-vwxyz
|
||||
EOF
|
||||
```
|
||||
|
||||
注意格式：`<cluster ID>:<project ID>`
|
||||
|
||||
## 删除项目
|
||||
|
||||
在集群命名空间中查找要删除的项目：
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
删除集群命名空间下的项目：
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde delete project p-vwxyz
|
||||
```
|
||||
|
||||
请注意此命令不会删除以前属于该项目的命名空间和资源。
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: 备份和恢复 Docker 安装的 Rancher
|
||||
---
|
||||
|
||||
- [备份](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md)
|
||||
- [还原](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md)
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: RKE 集群配置
|
||||
---
|
||||
|
||||
本文已迁移到[此处](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
title: 参与 Rancher 社区贡献
|
||||
---
|
||||
|
||||
本文介绍了 Rancher 仓库和 Rancher 文档、如何构建 Rancher 仓库以及提交 issue 时要包含哪些信息。
|
||||
|
||||
有关如何为 Rancher 项目开发做出贡献的更多详细信息，请参阅 [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki)。Wiki 包含以下主题的资源：
|
||||
|
||||
- 如何搭建 Rancher 开发环境并运行测试
|
||||
- Issue 在开发生命周期中的典型流程
|
||||
- 编码指南和开发最佳实践
|
||||
- 调试和故障排除
|
||||
- 开发 Rancher API
|
||||
|
||||
在 Rancher Users Slack 上，开发者的频道是 **#developer**。
|
||||
|
||||
## Rancher 文档
|
||||
|
||||
如果你对此网站上的文档有建议，请在主 [Rancher 文档](https://github.com/rancher/rancher-docs)仓库中[提交 issue](https://github.com/rancher/rancher-docs/issues/new/choose)。此仓库包含 Rancher v2.0 及更高版本的文档。
|
||||
|
||||
有关贡献和构建 Rancher v2.x 文档仓库的更多详细信息，请参阅 [Rancher 文档 README](https://github.com/rancher/rancher-docs#readme)。
|
||||
|
||||
有关 Rancher v1.6 及更早版本的文档，请参阅 [Rancher 1.x docs](https://github.com/rancher/rancher.github.io) 仓库，其中包含 https://rancher.com/docs/rancher/v1.6/en/ 的源文件。
|
||||
|
||||
## Rancher 仓库
|
||||
|
||||
所有仓库都位于我们的主要 GitHub 组织内。Rancher 使用了很多仓库，以下是部分主要仓库的描述：
|
||||
|
||||
| 仓库 | URL | 描述 |
|
||||
-----------|-----|-------------
|
||||
| Rancher | https://github.com/rancher/rancher | Rancher 2.x 的主要源码仓库。 |
|
||||
| Types | https://github.com/rancher/types | 包含 Rancher 2.x 的所有 API 类型的仓库。 |
|
||||
| API Framework | https://github.com/rancher/norman | API 框架，用于构建由 Kubernetes 自定义资源支持的 Rancher 风格的 API。 |
|
||||
| User Interface | https://github.com/rancher/dashboard/ | Dashboard UI 源码仓库。 |
|
||||
| (Rancher) Docker Machine | https://github.com/rancher/machine | 使用主机驱动时使用的 Docker Machine 二进制文件的源码仓库。这是 `docker/machine` 仓库的一个 fork。 |
|
||||
| machine-package | https://github.com/rancher/machine-package | 用于构建 Rancher Docker Machine 二进制文件。 |
|
||||
| kontainer-engine | https://github.com/rancher/kontainer-engine | kontainer-engine 的源码仓库，它是配置托管 Kubernetes 集群的工具。 |
|
||||
| RKE repository | https://github.com/rancher/rke | Rancher Kubernetes Engine 的源码仓库，该工具可在任何主机上配置 Kubernetes 集群。 |
|
||||
| CLI | https://github.com/rancher/cli | Rancher 2.x 中使用的 Rancher CLI 的源码仓库。 |
|
||||
| (Rancher) Helm repository | https://github.com/rancher/helm | 打包的 Helm 二进制文件的源码仓库。这是 `helm/helm` 仓库的一个 fork。 |
|
||||
| Telemetry repository | https://github.com/rancher/telemetry | Telemetry 二进制文件的源码仓库。 |
|
||||
| loglevel repository | https://github.com/rancher/loglevel | loglevel 二进制文件的源码仓库，用于动态更改日志级别。 |
|
||||
|
||||
要查看 Rancher 使用的所有库/项目，请查看 `rancher/rancher` 仓库中的 [`go.mod` 文件](https://github.com/rancher/rancher/blob/master/go.mod)。
|
||||
|
||||
<br/>
|
||||
<sup>用于配置/管理 Kubernetes 集群的 Rancher 组件。</sup>
|
||||
|
||||
### 构建 Rancher 仓库
|
||||
|
||||
每个仓库都应该有一个 Makefile，并且可以使用 `make` 命令进行构建。`make` 目标基于仓库中 `/scripts` 目录中的脚本，每个目标都使用 [Dapper](https://github.com/rancher/dapper) 在孤立的环境中运行。`Dockerfile.dapper` 将用于此操作，它包含了所需的所有构建工具。
|
||||
|
||||
默认目标是 `ci`，它将运行 `./scripts/validate`、`./scripts/build`、`./scripts/test ` 和 `./scripts/package`。生成的二进制文件将在 `./build/bin` 中，通常也打包在 Docker 镜像中。
|
||||
|
||||
### Rancher Bug、Issue 或疑问
|
||||
|
||||
如果你发现任何 bug 或问题，由于有人可能遇到过同样的问题，或者我们已经正在寻找解决方案，因此请先在[已报告 issue](https://github.com/rancher/rancher/issues) 中搜索。
|
||||
|
||||
如果找不到与你的问题相关的内容，请通过[提出 issue](https://github.com/rancher/rancher/issues/new) 与我们联系。与 Rancher 相关的仓库有很多，但请将 issue 提交到 Rancher 仓库中，这样能确保我们能看到这些 issue。如果你想就一个用例提出问题或询问其他用户，你可以在 [Rancher 论坛](https://forums.rancher.com)上发帖。
|
||||
|
||||
#### 提交 Issue 的检查清单
|
||||
|
||||
提交问题时请遵循此清单，以便我们调查和解决问题。如果你能提供更多信息，我们就可以使用更多数据来确定导致问题的原因或发现更多相关的内容。
|
||||
|
||||
:::note
|
||||
|
||||
如果数据量很大，请使用 [GitHub Gist](https://gist.github.com/) 或类似工具，并在 issue 中链接你创建的资源。
|
||||
|
||||
:::
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
请删除所有敏感数据。
|
||||
|
||||
:::
|
||||
|
||||
- **资源**：请尽量详细地提供所使用的资源。导致问题的原因可能很多，因此请尽量提供更多细节来帮助我们确定根本原因。下面是一些参考示例：
|
||||
- **主机**：主机的规格（例如 CPU/内存/磁盘），运行在什么云厂商上，使用的 Amazon Machine Image，使用的 DigitalOcean droplet，配置的镜像（复现时用于重新构建或使用）。
|
||||
- **操作系统**：使用的是什么操作系统。在此处提供详细信息，例如 `cat /etc/os-release` 的输出（确切的操作系统版本）和 `uname -r` 的输出（确切的内核）。
|
||||
- **Docker**：使用的 Docker 版本以及安装的方法。Docker 的大部分详情都可以在 `docker version` 和 `docker info` 的输出中找到。
|
||||
- **环境**：是否使用了代理，是否使用可信的 CA/自签名证书，是否使用了外部负载均衡器。
|
||||
- **Rancher**：使用的 Rancher 版本，可以在 UI 左下角或者从主机运行的 image 标签中获取。
|
||||
- **集群**：创建了什么样的集群，如何创建的，在创建时指定了什么参数。
|
||||
- **复现 issue 的步骤**：尽量详细地说明你是如何触发所报告的情况的。这有助于复现你的情况。
|
||||
- 提供从创建到你报告的情况使用的手动步骤或自动化脚本。
|
||||
- **日志**：提供使用资源的数据/日志。
|
||||
- Rancher
|
||||
- Docker 安装
|
||||
|
||||
```
|
||||
docker logs \
|
||||
--timestamps \
|
||||
$(docker ps | grep -E "rancher/rancher:|rancher/rancher " | awk '{ print $1 }')
|
||||
```
|
||||
- 使用 `kubectl` 的 Kubernetes 安装
|
||||
|
||||
:::note
|
||||
|
||||
确保你配置了正确的 kubeconfig（例如，如果 Rancher 安装在 Kubernetes 集群上，则 `export KUBECONFIG=$PWD/kube_config_cluster.yml`）或通过 UI 使用了嵌入式 kubectl。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
kubectl -n cattle-system \
|
||||
logs \
|
||||
-l app=rancher \
|
||||
--timestamps=true
|
||||
```
|
||||
- 在 RKE 集群的每个节点上使用 `docker` 的 Docker 安装
|
||||
|
||||
```
|
||||
docker logs \
|
||||
--timestamps \
|
||||
$(docker ps | grep -E "rancher/rancher@|rancher_rancher" | awk '{ print $1 }')
|
||||
```
|
||||
- 使用 RKE 附加组件的 Kubernetes 安装
|
||||
|
||||
:::note
|
||||
|
||||
确保你配置了正确的 kubeconfig（例如，如果 Rancher Server 安装在 Kubernetes 集群上，则 `export KUBECONFIG=$PWD/kube_config_cluster.yml`）或通过 UI 使用了嵌入式 kubectl。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
kubectl -n cattle-system \
|
||||
logs \
|
||||
--timestamps=true \
|
||||
-f $(kubectl --kubeconfig $KUBECONFIG get pods -n cattle-system -o json | jq -r '.items[] | select(.spec.containers[].name="cattle-server") | .metadata.name')
|
||||
```
|
||||
- 系统日志记录（可能不存在，取决于操作系统）
|
||||
- `/var/log/messages`
|
||||
- `/var/log/syslog`
|
||||
- `/var/log/kern.log`
|
||||
- Docker Daemon 日志记录（可能并不全部存在，取决于操作系统）
|
||||
- `/var/log/docker.log`
|
||||
- **指标**：如果你遇到性能问题，请提供尽可能多的指标数据（文件或屏幕截图）来帮助我们确定问题。如果你遇到主机相关的问题，你可以提供 `top`、`free -m`、`df` 的输出，这些输出会显示进程/内存/磁盘的使用情况。
|
||||
+204
@@ -0,0 +1,204 @@
|
||||
---
|
||||
title: CNI 网络插件
|
||||
description: 了解容器网络接口 (CNI)、Rancher 提供的 CNI 网络插件、提供商的功能，以及如何选择网络提供商
|
||||
---
|
||||
|
||||
## 什么是 CNI？
|
||||
|
||||
CNI（容器网络接口）是一个[云原生计算基金会项目](https://cncf.io/)，它包含了一些规范和库，用于编写在 Linux 容器中配置网络接口的一系列插件。CNI 只关注容器的网络连接，并在容器被删除时移除所分配的资源。
|
||||
|
||||
Kubernetes 使用 CNI 作为网络提供商和 Kubernetes Pod 网络之间的接口。
|
||||
|
||||
|
||||
|
||||
有关更多信息，请访问 [CNI GitHub 项目](https://github.com/containernetworking/cni)。
|
||||
|
||||
## CNI 使用了哪些网络模型？
|
||||
|
||||
CNI 网络插件使用封装网络模型（例如 Virtual Extensible Lan，缩写是 [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan)）或非封装网络模型（例如 Border Gateway Protocol，缩写是 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)）来实现网络结构。
|
||||
|
||||
### 什么是封装网络？
|
||||
|
||||
此网络模型提供了一个逻辑二层（L2）网络，该网络封装在跨 Kubernetes 集群节点的现有三层（L3）网络拓扑上。使用此模型，你可以为容器提供一个隔离的 L2 网络，而无需分发路由。封装网络带来了少量的处理开销以及由于覆盖封装生成 IP header 造成的 IP 包大小增加。封装信息由 Kubernetes worker 之间的 UDP 端口分发，交换如何访问 MAC 地址的网络控制平面信息。此类网络模型中常用的封装是 VXLAN、Internet 协议安全性 (IPSec) 和 IP-in-IP。
|
||||
|
||||
简单来说，这种网络模型在 Kubernetes worker 之间生成了一种扩展网桥，其中连接了 pod。
|
||||
|
||||
如果你偏向使用扩展 L2 网桥，则可以选择此网络模型。此网络模型对 Kubernetes worker 的 L3 网络延迟很敏感。如果数据中心位于不同的地理位置，请确保它们之间的延迟较低，以避免最终的网络分段。
|
||||
|
||||
使用这种网络模型的 CNI 网络插件包括 Flannel、Canal、Weave 和 Cilium。默认情况下，Calico 不会使用此模型，但你可以对其进行配置。
|
||||
|
||||
|
||||
|
||||
### 什么是非封装网络？
|
||||
|
||||
该网络模型提供了一个 L3 网络，用于在容器之间路由数据包。此模型不会生成隔离的 L2 网络，也不会产生开销。这些好处的代价是，Kubernetes worker 必须管理所需的所有路由分发。该网络模型不使用 IP header 进行封装，而是使用 Kubernetes Worker 之间的网络协议来分发路由信息以实现 Pod 连接，例如 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)。
|
||||
|
||||
简而言之，这种网络模型在 Kubernetes worker 之间生成了一种扩展网络路由器，提供了如何连接 Pod 的信息。
|
||||
|
||||
如果你偏向使用 L3 网络，则可以选择此网络模型。此模型在操作系统级别为 Kubernetes Worker 动态更新路由。对延迟较不敏感。
|
||||
|
||||
使用这种网络模型的 CNI 网络插件包括 Calico 和 Cilium。Cilium 可以使用此模型进行配置，即使这不是默认模式。
|
||||
|
||||
|
||||
|
||||
## Rancher 提供哪些 CNI 插件？
|
||||
|
||||
### RKE Kubernetes 集群
|
||||
|
||||
Rancher 开箱即用地为 RKE Kubernetes 集群提供了几个 CNI 网络插件，分别是 Canal、Flannel、Calico 和 Weave。
|
||||
|
||||
如果你使用 Rancher 创建新的 Kubernetes 集群，你可以选择你的 CNI 网络插件。
|
||||
|
||||
#### Canal
|
||||
|
||||
|
||||
|
||||
Canal 是一个 CNI 网络插件，它很好地结合了 Flannel 和 Calico 的优点。它让你轻松地将 Calico 和 Flannel 网络部署为统一的网络解决方案，将 Calico 的网络策略执行与 Calico（未封装）和 Flannel（封装）丰富的网络连接选项结合起来。
|
||||
|
||||
Canal 是 Rancher 默认的 CNI 网络插件，并采用了 Flannel 和 VXLAN 封装。
|
||||
|
||||
Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN) 和 TCP 端口 `9099`（健康检查）。如果使用 Wireguard，则需要打开 UDP 端口 `51820` 和 `51821`。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)。
|
||||
|
||||
|
||||
|
||||
有关详细信息，请参阅 [Canal GitHub 页面](https://github.com/projectcalico/canal)。
|
||||
|
||||
#### Flannel
|
||||
|
||||
|
||||
|
||||
Flannel 是为 Kubernetes 配置 L3 网络结构的简单方法。Flannel 在每台主机上运行一个名为 flanneld 的二进制 Agent，该 Agent 负责从更大的预配置地址空间中为每台主机分配子网租约。Flannel 通过 Kubernetes API 或直接使用 etcd 来存储网络配置、分配的子网、以及其他辅助数据（例如主机的公共 IP）。数据包使用某种后端机制来转发，默认封装为 [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan)。
|
||||
|
||||
默认情况下，封装的流量是不加密的。Flannel 提供了两种加密方案：
|
||||
|
||||
* [IPSec](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#ipsec)：使用 [strongSwan](https://www.strongswan.org/) 在 Kubernetes worker 之间建立加密的 IPSec 隧道。它是加密的实验性后端。
|
||||
* [WireGuard](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#wireguard)：比 strongSwan 更快的替代方案。
|
||||
|
||||
Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN)。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
|
||||
|
||||
|
||||
|
||||
有关详细信息，请参阅 [Flannel GitHub 页面](https://github.com/flannel-io/flannel)。
|
||||
|
||||
#### Weave
|
||||
|
||||
|
||||
|
||||
Weave 在云上的 Kubernetes 集群中启用网络和网络策略。此外，它还支持加密对等节点之间的流量。
|
||||
|
||||
Kubernetes worker 需要打开 TCP 端口 `6783`（控制端口）、UDP 端口 `6783` 和 UDP 端口 `6784`（数据端口）。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
|
||||
|
||||
有关详细信息，请参阅以下页面：
|
||||
|
||||
- [Weave Net 官网](https://www.weave.works/)
|
||||
|
||||
### RKE2 Kubernetes 集群
|
||||
|
||||
Rancher 开箱即用地为 RKE2 Kubernetes 集群提供了几个 CNI 网络插件，分别是 [Canal](#canal)（见上一节）、Calico 和 Cilium。
|
||||
|
||||
如果你使用 Rancher 创建新的 Kubernetes 集群，你可以选择你的 CNI 网络插件。
|
||||
|
||||
#### Calico
|
||||
|
||||
|
||||
|
||||
Calico 在云上的 Kubernetes 集群中启用网络和网络策略。默认情况下，Calico 使用纯净、未封装的 IP 网络结构和策略引擎为 Kubernetes 工作负载提供网络。工作负载能够使用 BGP 在云上和本地进行通信。
|
||||
|
||||
Calico 还提供了一种无状态的 IP-in-IP 或 VXLAN 封装模式。如果需要，你可以使用它。Calico 还支持策略隔离，让你使用高级 ingress 和 egress 策略保护和管理 Kubernetes 工作负载。
|
||||
|
||||
如果使用 BGP，Kubernetes Worker 需要打开 TCP 端口 `179`，如果使用 VXLAN 封装，则需要打开 UDP 端口 `4789`。另外，使用 Typha 时需要 TCP 端口 `5473`。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
在 Rancher 2.6.3 中，Calico 探测到在安装 RKE2 时 Windows 节点会失败。<b>请注意，此问题已在 v2.6.4 中解决。</b>
|
||||
|
||||
- 要解决此问题，请先导航到 `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`。
|
||||
|
||||
- 在那里，将当前设置 `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` 更改为新设置 `https://raw.githubusercontent .com/rancher/rke2/master/windows/rke2-install.ps1`。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
|
||||
有关详细信息，请参阅以下页面：
|
||||
|
||||
- [Project Calico 官方网站](https://www.projectcalico.org/)
|
||||
- [Calico 项目 GitHub 页面](https://github.com/projectcalico/calico)
|
||||
|
||||
#### Cilium
|
||||
|
||||
|
||||
|
||||
Cilium 在 Kubernetes 中启用网络和网络策略（L3、L4 和 L7）。默认情况下，Cilium 使用 eBPF 技术在节点内部路由数据包，并使用 VXLAN 将数据包发送到其他节点。你也可以配置非封装的技术。
|
||||
|
||||
Cilium 推荐大于 5.2 的内核版本，从而充分利用 eBPF 的能力。Kubernetes worker 需要打开 TCP 端口 `8472`（VXLAN）和 TCP 端口 `4240`（健康检查）。此外，还必须为健康检查启用 ICMP 8/0。有关详细信息，请查看 [Cilium 系统要求](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements)。
|
||||
|
||||
##### Cilium 中跨节点的 Ingress 路由
|
||||
<br/>
|
||||
默认情况下，Cilium 不允许 Pod 与其他节点上的 Pod 通信。要解决此问题，请启用 Ingress Controller 以使用 “CiliumNetworkPolicy” 进行跨节点路由请求。
|
||||
|
||||
选择 Cilium CNI 并为新集群启用项目网络隔离后，配置如下：
|
||||
|
||||
```
|
||||
apiVersion: cilium.io/v2
|
||||
kind: CiliumNetworkPolicy
|
||||
metadata:
|
||||
name: hn-nodes
|
||||
namespace: default
|
||||
spec:
|
||||
endpointSelector: {}
|
||||
ingress:
|
||||
- fromEntities:
|
||||
- remote-node
|
||||
```
|
||||
|
||||
## 各个网络插件的 CNI 功能
|
||||
|
||||
下表总结了 Rancher 中每个 CNI 网络插件支持的不同功能：
|
||||
|
||||
| 提供商 | 网络模型 | 路线分发 | 网络策略 | 网格 | 外部数据存储 | 加密 | Ingress/Egress 策略 |
|
||||
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
|
||||
| Canal | 封装 (VXLAN) | 否 | 是 | 否 | K8s API | 是 | 是 |
|
||||
| Flannel | 封装 (VXLAN) | 否 | 否 | 否 | K8s API | 是 | 否 |
|
||||
| Calico | 封装（VXLAN，IPIP）或未封装 | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
|
||||
| Weave | 封装 | 是 | 是 | 是 | 否 | 是 | 是 |
|
||||
| Cilium | 封装 (VXLAN) | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
|
||||
|
||||
- 网络模型：封装或未封装。如需更多信息，请参阅 [CNI 中使用的网络模型](#cni-使用了哪些网络模型)。
|
||||
|
||||
- 路由分发：一种外部网关协议，用于在互联网上交换路由和可达性信息。BGP 可以帮助进行跨集群 pod 之间的网络。此功能对于未封装的 CNI 网络插件是必须的，并且通常由 BGP 完成。如果你想构建跨网段拆分的集群，路由分发是一个很好的功能。
|
||||
|
||||
- 网络策略：Kubernetes 提供了强制执行规则的功能，这些规则决定了哪些 service 可以使用网络策略进行相互通信。这是从 Kubernetes 1.7 起稳定的功能，可以与某些网络插件一起使用。
|
||||
|
||||
- 网格：允许在不同的 Kubernetes 集群间进行 service 之间的网络通信。
|
||||
|
||||
- 外部数据存储：具有此功能的 CNI 网络插件需要一个外部数据存储来存储数据。
|
||||
|
||||
- 加密：允许加密和安全的网络控制和数据平面。
|
||||
|
||||
- Ingress/Egress 策略：允许你管理 Kubernetes 和非 Kubernetes 通信的路由控制。
|
||||
|
||||
|
||||
## CNI 社区人气
|
||||
|
||||
下表总结了不同的 GitHub 指标，让你了解每个项目的受欢迎程度和活动。数据收集于 2022 年 1 月。
|
||||
|
||||
| 提供商 | 项目 | Stars | Forks | Contributors |
|
||||
| ---- | ---- | ---- | ---- | ---- |
|
||||
| Canal | https://github.com/projectcalico/canal | 679 | 100 | 21 |
|
||||
| Flannel | https://github.com/flannel-io/flannel | 7k | 2.5k | 185 |
|
||||
| Calico | https://github.com/projectcalico/calico | 3.1k | 741 | 224 |
|
||||
| Weave | https://github.com/weaveworks/weave/ | 6.2k | 635 | 84 |
|
||||
| Cilium | https://github.com/cilium/cilium | 10.6k | 1.3k | 352 |
|
||||
|
||||
<br/>
|
||||
|
||||
## 使用哪个 CNI 插件？
|
||||
|
||||
这取决于你的项目需求。各个提供商都有不同的功能和选项。没有一个提供商可以满足所有用户的需求。
|
||||
|
||||
Canal 是默认的 CNI 网络插件。对于大多数用例，我们推荐你使用它。它使用 Flannel 为容器提供封装网络，同时添加 Calico 网络策略，可以在网络方面提供项目/命名空间隔离。
|
||||
|
||||
## 如何配置 CNI 网络插件？
|
||||
|
||||
如需了解如何为你的集群配置网络插件，请参阅[集群选项](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。有关更高级的配置选项，请参阅有关使用[配置文件](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-集群配置文件参考)和[网络插件](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/)选项来配置集群的说明。
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Rancher 弃用的功能
|
||||
---
|
||||
|
||||
### Rancher 的弃用策略是什么？
|
||||
|
||||
我们在支持[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方弃用策略。
|
||||
|
||||
### 在哪里可以找到 Rancher 已弃用的功能？
|
||||
|
||||
Rancher 会在 GitHub 上的[发行说明](https://github.com/rancher/rancher/releases)中公布已弃用的功能。请参阅以下补丁版本了解已弃用的功能：
|
||||
|
||||
| 补丁版本 | 发布日期 |
|
||||
|---------------|---------------|
|
||||
| [2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) | 2021 年 8 月 31 日 |
|
||||
| [2.6.1](https://github.com/rancher/rancher/releases/tag/v2.6.1) | 2021 年 10 月 11 日 |
|
||||
| [2.6.2](https://github.com/rancher/rancher/releases/tag/v2.6.2) | 2021 年 10 月 19 日 |
|
||||
| [2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) | 2021 年 12 月 21 日 |
|
||||
| [2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) | 2022 年 3 月 31 日 |
|
||||
| [2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) | 2022 年 5 月 12 日 |
|
||||
| [2.6.6](https://github.com/rancher/rancher/releases/tag/v2.6.6) | 2022 年 6 月 30 日 |
|
||||
|
||||
|
||||
### 如果某个功能标记为弃用，我要怎么做？
|
||||
|
||||
如果某个发行版将某功能标记为"Deprecated"（已弃用），该功能仍然可用并受支持，从而允许用户按照常规流程进行升级。在升级到该功能被标记为"已删除"的发行版前，用户/管理员应该计划剥离该功能。对于新部署，我们建议不要使用已弃用的功能。
|
||||
@@ -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 日 |
|
||||
|
||||
### 当一个功能被标记为弃用我可以得到什么样的预期？
|
||||
|
||||
当功能被标记为“已弃用”时，它依然可用并得到支持，允许按照常规的流程进行升级。一旦升级完成，用户/管理员应开始计划在升级到标记为已移除的版本之前放弃使用已弃用的功能。对于新的部署，建议不要使用已弃用的功能。
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: Dockershim
|
||||
---
|
||||
|
||||
Dockershim 是 Kubelet 和 Docker Daemon 之间的 CRI 兼容层。Kubernetes 1.20 版本宣布了[移除树内 Dockershim](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。目前计划在 Kubernetes 1.24 中移除。有关此移除的更多信息以及时间线，请参见 [Kubernetes Dockershim 弃用相关的常见问题](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed)。
|
||||
|
||||
从 Kubernetes 1.21 开始。RKE 集群支持外部 Dockershim，来让用户继续使用 Docker 作为 CRI 运行时。现在，我们通过使用 [Mirantis 和 Docker ](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) 来确保 RKE 集群可以继续使用 Docker，从而实现上游开源社区的 Dockershim。
|
||||
|
||||
要启用外部 Dockershim，配置以下选项：
|
||||
|
||||
```
|
||||
enable_cri_dockerd: true
|
||||
```
|
||||
|
||||
如果你想使用其他容器运行时，Rancher 也提供使用 Containerd 作为默认运行时的，以边缘为中心的 K3s，和以数据中心为中心的 RKE2 Kubernetes 发行版。即使在 Kubernetes 1.24 删除了树内 Dockershim 之后，你也可以通过 Rancher 升级和管理导入的 RKE2 和 K3s Kubernetes 集群。
|
||||
|
||||
### 常见问题
|
||||
|
||||
<br/>
|
||||
|
||||
Q. 如果要获得 Rancher 对上游 Dockershim 的支持，我需要升级 Rancher 吗？
|
||||
|
||||
对于 RKE，Dockershim 的上游支持从 Kubernetes 1.21 开始。你需要使用 Rancher 2.6 或更高版本才能获取使用 Kubernetes 1.21 的 RKE 的支持。详情请参阅我们的[支持矩阵](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/)。
|
||||
|
||||
<br/>
|
||||
|
||||
Q. 我目前的 RKE 使用 Kubernetes 1.20。为了避免出现不再支持 Dockershim 的情况，我是否需要尽早将 RKE 升级到 Kubernetes 1.21？
|
||||
|
||||
A. 在使用 Kubernetes 1.20 的 RKE 中，Dockershim 版本依然可用，而且在 Kubernetes 1.24 之前不会在上游弃用。Kubernetes 会发出弃用 Dockershim 的警告，而 Rancher 在使用 Kubernetes 1.21 的 RKE 中已经缓解了这个问题。你可以按照计划正常升级到 Kubernetes 1.21，但也应该考虑在升级到 Kubernetes 1.22 时启用外部 Dockershim。在升级到 Kubernetes 1.24 之前，你需要启用外部 Dockershim，此时现有的实现都会被删除。
|
||||
|
||||
有关此移除的更多信息以及时间线，请参见 [Kubernetes Dockershim 弃用相关的常见问题](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed)。
|
||||
|
||||
<br/>
|
||||
|
||||
Q: 如果我不想再依赖 Dockershim，我还有什么选择？
|
||||
|
||||
A: 你可以为 Kubernetes 使用不需要 Dockershim 支持的运行时，如 Containerd。RKE2 和 K3s 就是其中的两个选项。
|
||||
|
||||
<br/>
|
||||
|
||||
Q: 如果我目前使用 RKE1，但想切换到 RKE2，我可以怎样进行迁移？
|
||||
|
||||
A: Rancher 也在探索就地升级路径的可能性。此外，你始终可以使用 kubectl 将工作负载迁移到另一个集群。
|
||||
|
||||
<br/>
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: 一般常见问题解答
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/general-faq"/>
|
||||
</head>
|
||||
|
||||
本文包含了用户常见的 Rancher 2.x 问题。
|
||||
|
||||
有关常见技术问题，请参阅[常见技术问题解答](technical-items.md)。
|
||||
|
||||
## Rancher 2.x 支持 Docker Swarm 和 Mesos 作为环境类型吗？
|
||||
|
||||
如果你在 Rancher 2.x 中创建环境，Swarm 和 Mesos 将不再是可选的标准选项。但是，Swarm 和 Mesos 还能继续作为可以部署的商店应用程序。这是一个艰难的决定，但这是大势所趋。比如说，15,000 多个集群可能只有大约 200 个在运行 Swarm。
|
||||
|
||||
## 是否可以使用 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？
|
||||
|
||||
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 是否支持 Istio？
|
||||
|
||||
Rancher 支持 [Istio](../pages-for-subheaders/istio.md)。
|
||||
|
||||
## Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文？
|
||||
|
||||
密文管理已在我们的 roadmap 上，但我们尚未将该功能分配给特定版本。
|
||||
|
||||
## Rancher 2.x 是否也支持 RKT 容器？
|
||||
|
||||
目前，我们只支持 Docker。
|
||||
|
||||
## Rancher 2.x 是否支持将 Calico、Contiv、Contrail、Flannel、Weave net 等网络插件用于嵌入和已注册的 Kubernetes？
|
||||
|
||||
Rancher 开箱即用地为 Kubernetes 集群提供了几个 CNI 网络插件，分别是 Canal、Flannel、Calico 和 Weave。有关官方支持的详细信息，请参阅 [Rancher 支持矩阵](https://rancher.com/support-maintenance-terms/)。
|
||||
|
||||
## Rancher 是否计划支持 Traefik？
|
||||
|
||||
目前，我们不打算提供嵌入式 Traefik 支持，但我们仍在探索负载均衡方案。
|
||||
|
||||
## 我可以将 OpenShift Kubernetes 集群导入 2.x 吗？
|
||||
|
||||
我们的目标是运行任何上游 Kubernetes 集群。因此，Rancher 2.x 应该可以与 OpenShift 一起使用，但我们尚未对此进行测试。
|
||||
|
||||
## Rancher 会集成 Longhorn 吗？
|
||||
|
||||
是的。Longhorn 已集成到 Rancher 2.5+ 中。
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: 安装和配置 kubectl
|
||||
---
|
||||
|
||||
`kubectl` 是一个 CLI 工具，用于运行 Kubernetes 集群相关的命令。Rancher 2.x 中的许多维护和管理任务都需要它。
|
||||
|
||||
### 安装
|
||||
|
||||
请参阅 [kubectl 安装](https://kubernetes.io/docs/tasks/tools/install-kubectl/)将 kubectl 安装到你的操作系统上。
|
||||
|
||||
### 配置
|
||||
|
||||
使用 RKE 创建 Kubernetes 集群时，RKE 会在本地目录中创建一个 `kube_config_cluster.yml`，该文件包含使用 `kubectl` 或 `helm` 等工具连接到新集群的凭证。
|
||||
|
||||
你可以将此文件复制为 `$HOME/.kube/config`。如果你使用多个 Kubernetes 集群，将 `KUBECONFIG` 环境变量设置为 `kube_config_cluster.yml` 的路径：
|
||||
|
||||
```
|
||||
export KUBECONFIG=$(pwd)/kube_config_cluster.yml
|
||||
```
|
||||
|
||||
使用 `kubectl` 测试你的连接性，并查看你是否可以获取节点列表：
|
||||
|
||||
```
|
||||
kubectl get nodes
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
165.227.114.63 Ready controlplane,etcd,worker 11m v1.10.1
|
||||
165.227.116.167 Ready controlplane,etcd,worker 11m v1.10.1
|
||||
165.227.127.226 Ready controlplane,etcd,worker 11m v1.10.1
|
||||
```
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: 卸载 Rancher
|
||||
---
|
||||
|
||||
本文介绍了如果你不再需要 Rancher、不想再由 Rancher 管理集群、或想删除 Rancher Server 需要怎么做。
|
||||
|
||||
|
||||
### 如果 Rancher Server 被删除，下游集群中的工作负载会怎样？
|
||||
|
||||
如果 Rancher 删除了或无法恢复，Rancher 管理的下游 Kubernetes 集群中的所有工作负载将继续正常运行。
|
||||
|
||||
### 如果删除了 Rancher Server，该如何访问下游集群？
|
||||
|
||||
如果删除了 Rancher，访问下游集群的方式取决于集群的类型和集群的创建方式。总而言之：
|
||||
|
||||
- **注册集群**：集群不受影响，你可以注册集群前的方法访问该集群。
|
||||
- **托管的 Kubernetes 集群**：如果你在 Kubernetes 云提供商（例如 EKS、GKE 或 AKS）中创建集群，你可以继续使用提供商的云凭证来管理集群。
|
||||
- **RKE 集群**：要访问 [RKE 集群](../pages-for-subheaders/launch-kubernetes-with-rancher.md)，集群必须启用了[授权集群端点（authorized cluster endpoint，ACE）](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-授权集群端点)，而且你必须从 Rancher UI 下载了集群的 kubeconfig 文件。RKE 集群默认启用授权集群端点。通过使用此端点，你可以直接使用 kubectl 访问你的集群，而不用通过 Rancher Server 的[认证代理](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-认证代理)进行通信。有关配置 kubectl 以使用授权集群端点的说明，请参阅[使用 kubectl 和 kubeconfig 文件直接访问集群](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#直接使用下游集群进行身份验证)。这些集群将使用删除 Rancher 时配置的身份验证快照。
|
||||
|
||||
### 如果我不想再使用 Rancher 了该怎么做？
|
||||
|
||||
:::note
|
||||
|
||||
之前推荐的 [System Tools](../reference-guides/system-tools.md) 自 2022 年 6 月起已弃用。
|
||||
|
||||
:::
|
||||
|
||||
如果你[在 Kubernetes 集群上安装了 Rancher](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md)，你可以使用 [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) 工具删除 Rancher。
|
||||
|
||||
在高可用 (HA) 模式下卸载 Rancher 还将删除所有 `helm-operation-*` Pod 和以下应用程序：
|
||||
|
||||
- fleet
|
||||
- fleet-agent
|
||||
- rancher-operator
|
||||
- rancher-webhook
|
||||
|
||||
自定义资源 (CRD) 和自定义命名空间仍需要手动删除。
|
||||
|
||||
如果你在 Docker 中安装 Rancher，则可以通过删除运行 Rancher 的单个 Docker 容器来卸载 Rancher。
|
||||
|
||||
移除 Rancher 不会影响导入的集群。有关其他集群类型，请参考[移除 Rancher 后访问下游集群](#如果删除了-rancher-server该如何访问下游集群)。
|
||||
|
||||
### 如果我不想 Rancher 管理我的注册集群该怎么办？
|
||||
|
||||
如果你在 Rancher UI 中删除了已注册的集群，则该集群将与 Rancher 分离，集群不会发生改变，你可以使用注册集群之前的方法访问该集群。
|
||||
|
||||
要分离集群：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
2. 转到要与 Rancher 分离的已注册集群，然后单击 **⋮ > 删除**。
|
||||
3. 单击**删除**。
|
||||
|
||||
**结果**：注册的集群已与 Rancher 分离，并在 Rancher 外正常运行。
|
||||
|
||||
### 如果我不想 Rancher 管理我的 RKE 集群或托管的 Kubernetes 集群该怎么办？
|
||||
|
||||
目前，我们没有将这些集群从 Rancher 中分离出来的功能。在这种情况下，“分离”指的是将 Rancher 组件移除出集群，并独立于 Rancher 管理对集群的访问。
|
||||
|
||||
[此 issue](https://github.com/rancher/rancher/issues/25234) 跟踪了在没有 Rancher 的情况下管理这些集群的功能。
|
||||
|
||||
有关如何在删除 Rancher Server 后访问集群的更多信息，请参阅[本节](#如果删除了-rancher-server该如何访问下游集群)。
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: 安全
|
||||
|
||||
---
|
||||
|
||||
**是否有强化指南？**
|
||||
|
||||
强化指南现在位于[安全](../pages-for-subheaders/rancher-security.md)部分。
|
||||
|
||||
<br/>
|
||||
|
||||
**Rancher Kubernetes 集群 CIS Benchmark 测试的结果是什么？**
|
||||
|
||||
我们已经针对强化的 Rancher Kubernetes 集群运行了 CIS Kubernetes Benchmark 测试。你可以在[安全](../pages-for-subheaders/rancher-security.md)中找到该评估的结果。
|
||||
@@ -0,0 +1,176 @@
|
||||
---
|
||||
title: 技术
|
||||
---
|
||||
|
||||
### 如何重置管理员密码？
|
||||
|
||||
Docker 安装：
|
||||
```
|
||||
$ docker exec -ti <container_id> reset-password
|
||||
New password for default administrator (user-xxxxx):
|
||||
<new_password>
|
||||
```
|
||||
|
||||
Kubernetes 安装（Helm）：
|
||||
```
|
||||
$ KUBECONFIG=./kube_config_cluster.yml
|
||||
$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher --no-headers | head -1 | awk '{ print $1 }') -c rancher -- reset-password
|
||||
New password for default administrator (user-xxxxx):
|
||||
<new_password>
|
||||
```
|
||||
|
||||
|
||||
|
||||
### 我删除/停用了最后一个 admin，该如何解决？
|
||||
Docker 安装：
|
||||
```
|
||||
$ docker exec -ti <container_id> ensure-default-admin
|
||||
New default administrator (user-xxxxx)
|
||||
New password for default administrator (user-xxxxx):
|
||||
<new_password>
|
||||
```
|
||||
|
||||
Kubernetes 安装（Helm）：
|
||||
```
|
||||
$ KUBECONFIG=./kube_config_cluster.yml
|
||||
$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin
|
||||
New password for default administrator (user-xxxxx):
|
||||
<new_password>
|
||||
```
|
||||
### 如何启用调试日志记录？
|
||||
|
||||
请参阅[故障排除：日志记录](../troubleshooting/other-troubleshooting-tips/logging.md)。
|
||||
|
||||
### 我的 ClusterIP 不响应 ping，该如何解决？
|
||||
|
||||
ClusterIP 是一个虚拟 IP，不会响应 ping。要测试 ClusterIP 是否配置正确，最好的方法是使用 `curl` 访问 IP 和端口并检查它是否响应。
|
||||
|
||||
### 在哪里管理节点模板？
|
||||
|
||||
打开你的账号菜单（右上角）并选择`节点模板`。
|
||||
|
||||
### 为什么我的四层负载均衡器处于 `Pending` 状态？
|
||||
|
||||
四层负载均衡器创建为 `type: LoadBalancer`。Kubernetes 需要一个可以满足这些请求的云提供商或控制器，否则这些请求将永远处于 `Pending` 状态。有关更多信息，请参阅[云提供商](../pages-for-subheaders/set-up-cloud-providers.md)或[创建外部负载均衡器](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)。
|
||||
|
||||
### Rancher 的状态存储在哪里？
|
||||
|
||||
- Docker 安装：在 `rancher/rancher` 容器的嵌入式 etcd 中，位于 `/var/lib/rancher`。
|
||||
- Kubernetes install：在为运行 Rancher 而创建的 RKE 集群的 etcd 中。
|
||||
|
||||
### 支持的 Docker 版本是如何确定的？
|
||||
|
||||
我们遵循上游 Kubernetes 版本验证过的 Docker 版本。如果需要获取验证过的版本，请查看 Kubernetes 版本 CHANGELOG.md 中的 [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies)。
|
||||
|
||||
### 如何访问 Rancher 创建的节点？
|
||||
|
||||
你可以转到**节点**视图，然后下载用于访问 Rancher 创建的节点的 SSH 密钥。选择要访问的节点并单击行尾 **⋮** 按钮，然后选择**下载密钥**，如下图所示。
|
||||
|
||||
|
||||
|
||||
解压缩下载的 zip 文件，并使用 `id_rsa` 文件连接到你的主机。请务必使用正确的用户名（如果是 RancherOS，则使用 `rancher` 或 `docker`；如果是 Ubuntu，则使用 `ubuntu`；如果是 Amazon Linux，则使用 `ec2-user`）。
|
||||
|
||||
```
|
||||
$ ssh -i id_rsa user@ip_of_node
|
||||
```
|
||||
|
||||
### 如何在 Rancher 中自动化任务 X？
|
||||
|
||||
UI 由静态文件组成，并根据 API 的响应工作。换言之，UI 中可以执行的每个操作/任务都可以通过 API 进行自动化。有两种方法可以实现这一点：
|
||||
|
||||
* 访问 `https://your_rancher_ip/v3` 并浏览 API 选项。
|
||||
* 在使用 UI 时捕获 API 调用（通常使用 [Chrome 开发者工具](https://developers.google.com/web/tools/chrome-devtools/#network)，但你也可以使用其他工具）。
|
||||
|
||||
### 节点的 IP 地址改变了，该如何恢复？
|
||||
|
||||
节点需要配置静态 IP（或使用 DHCP 保留的 IP）。如果节点的 IP 已更改，你必须在集群中删除并重新添加它。删除后，Rancher 会将集群更新为正确的状态。如果集群不再处于 `Provisioning` 状态，则已从集群删除该节点。
|
||||
|
||||
节点的 IP 地址发生变化时，Rancher 会失去与节点的连接，因此无法正常清理节点。请参阅[清理集群节点](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md)来清理节点。
|
||||
|
||||
在集群中移除并清理节点时，你可以将节点重新添加到集群中。
|
||||
|
||||
### 如何将其他参数/绑定/环境变量添加到 Rancher 启动的 Kubernetes 集群的 Kubernetes 组件中？
|
||||
|
||||
你可以使用集群选项中的[配置文件](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-集群配置文件参考)选项来添加其他参数/绑定/环境变量。有关详细信息，请参阅 RKE 文档中的[其他参数、绑定和环境变量](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/)，或浏览 [Cluster.ymls 示例](https://rancher.com/docs/rke/latest/en/example-yamls/)。
|
||||
|
||||
### 如何检查证书链是否有效？
|
||||
|
||||
使用 `openssl verify` 命令来验证你的证书链：
|
||||
|
||||
:::tip
|
||||
|
||||
将 `SSL_CERT_DIR` 和 `SSL_CERT_FILE` 配置到虚拟位置，从而确保在手动验证时不使用操作系统安装的证书。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
SSL_CERT_DIR=/dummy SSL_CERT_FILE=/dummy openssl verify -CAfile ca.pem rancher.yourdomain.com.pem
|
||||
rancher.yourdomain.com.pem: OK
|
||||
```
|
||||
|
||||
如果你看到 `unable to get local issuer certificate` 错误，则表示链不完整。通常情况下，这表示你的服务器证书由中间 CA 颁发。如果你已经拥有此证书，你可以在证书的验证中使用它，如下所示：
|
||||
|
||||
```
|
||||
SSL_CERT_DIR=/dummy SSL_CERT_FILE=/dummy openssl verify -CAfile ca.pem -untrusted intermediate.pem rancher.yourdomain.com.pem
|
||||
rancher.yourdomain.com.pem: OK
|
||||
```
|
||||
|
||||
如果你已成功验证证书链，你需要在服务器证书中包含所需的中间 CA 证书，从而完成与 Rancher 连接的证书链（例如，使用 Rancher Agent）。服务器证书文件中证书的顺序首先是服务器证书本身（`rancher.yourdomain.com.pem` 的内容），然后是中间 CA 证书（`intermediate.pem` 的内容）：
|
||||
|
||||
```
|
||||
-----BEGIN CERTIFICATE-----
|
||||
%YOUR_CERTIFICATE%
|
||||
-----END CERTIFICATE-----
|
||||
-----BEGIN CERTIFICATE-----
|
||||
%YOUR_INTERMEDIATE_CERTIFICATE%
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
如果在验证过程中仍然出现错误，你可以运行以下命令，检索服务器证书的主题和颁发者：
|
||||
|
||||
```
|
||||
openssl x509 -noout -subject -issuer -in rancher.yourdomain.com.pem
|
||||
subject= /C=GB/ST=England/O=Alice Ltd/CN=rancher.yourdomain.com
|
||||
issuer= /C=GB/ST=England/O=Alice Ltd/CN=Alice Intermediate CA
|
||||
```
|
||||
|
||||
### 如何在服务器证书中检查 `Common Name` 和 `Subject Alternative Names`？
|
||||
|
||||
虽然技术上仅需要 `Subject Alternative Names` 中有一个条目，但在 `Common Name` 和 `Subject Alternative Names` 中都包含主机名可以最大程度地提高与旧版浏览器/应用程序的兼容性。
|
||||
|
||||
检查 `Common Name`：
|
||||
|
||||
```
|
||||
openssl x509 -noout -subject -in cert.pem
|
||||
subject= /CN=rancher.my.org
|
||||
```
|
||||
|
||||
检查 `Subject Alternative Names`：
|
||||
|
||||
```
|
||||
openssl x509 -noout -in cert.pem -text | grep DNS
|
||||
DNS:rancher.my.org
|
||||
```
|
||||
|
||||
### 为什么节点发生故障时重新调度一个 pod 需要 5 分钟以上的时间？
|
||||
|
||||
这是以下默认 Kubernetes 设置的组合导致的：
|
||||
|
||||
* kubelet
|
||||
* `node-status-update-frequency`：指定 kubelet 将节点状态发布到 master 的频率（默认 10s）。
|
||||
* kube-controller-manager
|
||||
* `node-monitor-period`：在 NodeController 中同步 NodeStatus 的周期（默认 5s）。
|
||||
* `node-monitor-grace-period`：在将节点标记为不健康之前，允许节点无响应的时间长度（默认 40s）。
|
||||
* `pod-eviction-timeout`：在故障节点上删除 pod 的宽限期（默认 5m0s）。
|
||||
|
||||
有关这些设置的更多信息，请参阅 [Kubernetes：kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 和 [Kubernetes：kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/)。
|
||||
|
||||
Kubernetes 1.13 默认启用 `TaintBasedEvictions` 功能。有关详细信息，请参阅 [Kubernetes：基于污点的驱逐](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint-based-evictions)。
|
||||
|
||||
* kube-apiserver（Kubernetes 1.13 及更高版本）
|
||||
* `default-not-ready-toleration-seconds`：表示 `notReady:NoExecute` 的容忍度的 `tolerationSeconds`，该设置默认添加到还没有该容忍度的 pod。
|
||||
* `default-unreachable-toleration-seconds`：表示 `unreachable:NoExecute` 的容忍度的 `tolerationSeconds`，该设置默认添加到还没有该容忍度的 pod。
|
||||
|
||||
### 我可以在 UI 中使用键盘快捷键吗？
|
||||
|
||||
是的，你可以使用键盘快捷键访问 UI 的大部分内容。要查看快捷方式的概览，请在 UI 任意位置按 `?`。
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: 遥测
|
||||
---
|
||||
|
||||
### 什么是遥测？
|
||||
|
||||
遥测（Telemetry）收集 Rancher 安装大小、使用的组件版本以及使用功能的汇总信息。Rancher Labs 会使用此信息来改进产品，我们不会与第三方共享此信息。
|
||||
|
||||
### 收集什么信息？
|
||||
|
||||
我们不会收集任何识别信息（如用户名、密码或用户资源的名称或地址）。
|
||||
|
||||
收集的主要内容包括：
|
||||
|
||||
- 每个集群的节点总数（最小、平均、最大、总数）及其大小（例如 CPU 核心数和 RAM）。
|
||||
- 集群、项目、命名空间和 Pod 等逻辑资源的聚合计数。
|
||||
- 用于部署集群和节点的驱动程序计数（例如 GKE、EC2、导入与自定义）。
|
||||
- 部署在节点上的 Kubernetes 组件、操作系统和 Docker 的版本。
|
||||
- 是否启用了某些可选组件（例如，使用了哪些身份验证提供程序）。
|
||||
- 运行的 Rancher 的镜像名称和版本。
|
||||
- 此安装的唯一随机标识符。
|
||||
|
||||
### 我可以看到发送的信息吗？
|
||||
|
||||
如果启用了遥测，你可以转到 `https://<your rancher server>/v1-telemetry` 查看当前数据。
|
||||
|
||||
如果未启用遥测，则收集数据的进程未运行，因此没有可供查看的内容。
|
||||
|
||||
### 如何打开或关闭它？
|
||||
|
||||
完成初始设置后，管理员可以转到 UI `全局`中的`设置`页面，单击**编辑**，然后将 `telemetry-opt` 更改为 `in` 或 `out`。
|
||||
+99
@@ -0,0 +1,99 @@
|
||||
---
|
||||
title: 在离线环境中升级
|
||||
---
|
||||
|
||||
:::note
|
||||
|
||||
以下说明假设你已经按照[本页](upgrades.md)的 Kubernetes 升级说明操作（包括先决条件）到步骤 3：升级 Rancher。
|
||||
|
||||
:::
|
||||
|
||||
### Rancher Helm 模板选项
|
||||
|
||||
使用安装 Rancher 时选择的选项来渲染 Rancher 模板。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库，以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。
|
||||
|
||||
根据你在安装过程中做出的选择，完成以下步骤之一。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
------------|-------------
|
||||
| `<VERSION>` | 输出压缩包的版本号。 |
|
||||
| `<RANCHER.YOURDOMAIN.COM>` | 指向负载均衡器的 DNS 名称。 |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 你的私有镜像仓库的 DNS 名称。 |
|
||||
| `<CERTMANAGER_VERSION>` | 在 K8s 集群上运行的 cert-manager 版本。 |
|
||||
|
||||
|
||||
### 选项 A：使用默认的自签名证书
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
#### 解决 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
|
||||
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 rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
--set ingress.tls.source=secret \
|
||||
--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
|
||||
```
|
||||
|
||||
如果你使用的是私有 CA 签名的证书，请在 `--set ingress.tls.source=secret` 后加上 `--set privateCA=true`：
|
||||
|
||||
```plain
|
||||
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 rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
--set ingress.tls.source=secret \
|
||||
--set privateCA=true \
|
||||
--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
|
||||
```
|
||||
|
||||
## 验证升级
|
||||
|
||||
登录 Rancher 以确认升级成功。
|
||||
|
||||
:::tip
|
||||
|
||||
升级后出现网络问题？
|
||||
|
||||
请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 已知升级问题
|
||||
|
||||
你可以在 [GitHub](https://github.com/rancher/rancher/releases) 发布说明以及 [Rancher 论坛](https://forums.rancher.com/c/announcements/12)中找到每个 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)。
|
||||
+147
@@ -0,0 +1,147 @@
|
||||
---
|
||||
title: 在 Azure Kubernetes Service 上安装 Rancher
|
||||
---
|
||||
|
||||
本文介绍了如何在微软的 Azure Kubernetes Service (AKS) 上安装 Rancher。
|
||||
|
||||
本指南使用命令行工具来配置一个带有 Ingress 的 AKS 集群。如果你更喜欢使用 Azure 门户来配置集群，请参见[官方文档](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal)。
|
||||
|
||||
如果你已有一个 AKS Kubernetes 集群，请直接跳到[安装 Ingress](#5-安装-ingress) 的步骤，然后按照[此页](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。
|
||||
|
||||
## 先决条件
|
||||
|
||||
:::caution
|
||||
|
||||
部署到 Microsoft Azure 会产生费用。
|
||||
|
||||
:::
|
||||
|
||||
- [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 资源要求的详情，请参见[此节](../installation-requirements/installation-requirements.md)。
|
||||
- 在 Azure 中用 Helm 安装 Rancher 时，请使用 L7 负载均衡器来避免网络问题。详情请参见 [Azure 负载均衡器限制](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations)。
|
||||
|
||||
## 1. 准备你的工作站
|
||||
|
||||
在工作站上安装以下命令行工具：
|
||||
|
||||
- **az**，Azure CLI：如需获得帮助，请参见[安装步骤](https://docs.microsoft.com/en-us/cli/azure/)。
|
||||
- **kubectl**：如需获得帮助，请参见[安装步骤](https://kubernetes.io/docs/tasks/tools/#kubectl)。
|
||||
- **helm**：如需获取帮助，请参见[安装步骤](https://helm.sh/docs/intro/install/)。
|
||||
|
||||
## 2. 创建资源组
|
||||
|
||||
安装 CLI 后，你需要用你的 Azure 账户登录：
|
||||
|
||||
```
|
||||
az login
|
||||
```
|
||||
|
||||
创建一个 [资源组](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal) 来保存集群的所有相关资源。使用一个适用于你实际情况的位置：
|
||||
|
||||
```
|
||||
az group create --name rancher-rg --location eastus
|
||||
```
|
||||
|
||||
## 3. 创建 AKS 集群
|
||||
|
||||
运行以下命令创建一个 AKS 集群。选择适用于你实际情况的虚拟机大小。如需获得可用的大小和选项，请参见[此处](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes)。在选择 Kubernetes 版本时，请务必先查阅[支持矩阵](https://rancher.com/support-matrix/)，以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
|
||||
|
||||
:::note
|
||||
|
||||
如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
az aks create \
|
||||
--resource-group rancher-rg \
|
||||
--name rancher-server \
|
||||
--kubernetes-version <VERSION> \
|
||||
--node-count 3 \
|
||||
--node-vm-size Standard_D2_v3
|
||||
```
|
||||
|
||||
集群部署需要一些时间才能完成。
|
||||
|
||||
## 4. 获取访问凭证
|
||||
|
||||
集群部署完成后，获取访问凭证。
|
||||
|
||||
```
|
||||
az aks get-credentials --resource-group rancher-rg --name rancher-server
|
||||
```
|
||||
|
||||
此命令把集群的凭证合并到现有的 kubeconfig 中，并允许 `kubectl` 与集群交互。
|
||||
|
||||
## 5. 安装 Ingress
|
||||
|
||||
集群需要一个 Ingress，以从集群外部访问 Rancher。要 Ingress，你需要分配一个公共 IP 地址。请确保你有足够的配额，否则它将无法分配 IP 地址。公共 IP 地址的限制在每个订阅的区域级别生效。
|
||||
|
||||
为确保你选择了正确的 Ingress-NGINX Helm Chart，首先在 [Kubernetes/ingress-nginx 支持表](https://github.com/kubernetes/ingress-nginx#supported-versions-table)中找到与你的 Kubernetes 版本兼容的 `Ingress-NGINX 版本`。
|
||||
|
||||
然后，运行以下命令列出可用的 Helm Chart：
|
||||
|
||||
```
|
||||
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
|
||||
helm repo update
|
||||
helm search repo ingress-nginx -l
|
||||
```
|
||||
|
||||
`helm search` 命令的输出包含一个 `APP VERSION` 列。此列下的版本等同于你之前选择的 `Ingress-NGINX 版本`。使用应用程序版本，选择一个 Chart 版本，该版本打包了与你的 Kubernetes 兼容的应用程序。例如，如果使用的是 Kubernetes v1.24，则可以选择 v4.6.0 Helm Chart，因为 Ingress-NGINX v1.7.0 与该 Chart 打包在一起，而 v1.7.0 与 Kubernetes v1.24 兼容。如有疑问，请选择最新的兼容版本。
|
||||
|
||||
了解你需要的 Helm chart `版本`后，运行以下命令。它安装一个带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`：
|
||||
|
||||
```
|
||||
helm search repo ingress-nginx -l
|
||||
helm upgrade --install \
|
||||
ingress-nginx ingress-nginx/ingress-nginx \
|
||||
--namespace ingress-nginx \
|
||||
--set controller.service.type=LoadBalancer \
|
||||
--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
|
||||
--set controller.service.externalTrafficPolicy=Local \
|
||||
--version 4.6.0 \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
## 6. 获取负载均衡器的 IP
|
||||
|
||||
运行以下命令获取负载均衡器的 IP 地址：
|
||||
|
||||
```
|
||||
kubectl get service ingress-nginx-controller --namespace=ingress-nginx
|
||||
```
|
||||
|
||||
返回的结果应与以下内容类似：
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
|
||||
AGE
|
||||
ingress-nginx-controller LoadBalancer 10.0.116.18 40.31.180.83 80:31229/TCP,443:31050/TCP
|
||||
67s
|
||||
```
|
||||
|
||||
保存 `EXTERNAL-IP`。
|
||||
|
||||
## 7. 设置 DNS
|
||||
|
||||
到 Rancher Server 的外部流量需要重定向到你创建的负载均衡器。
|
||||
|
||||
创建指向你保存的 `EXTERNAL-IP` 的 DNS。这个 DNS 会用作 Rancher Server 的 URL。
|
||||
|
||||
设置 DNS 的有效方法有很多。如需获取帮助，请参见 [Azure DNS 文档中心](https://docs.microsoft.com/en-us/azure/dns/)。
|
||||
|
||||
## 8. 安装 Rancher Helm Chart
|
||||
|
||||
按照[本页](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 安装命令。
|
||||
|
||||
在此设置之上安装 Rancher 时，你还需要将以下值传递到 Rancher Helm 安装命令，以设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称：
|
||||
|
||||
```
|
||||
--set ingress.ingressClassName=nginx
|
||||
```
|
||||
|
||||
请参阅[Helm 安装命令](install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
+151
@@ -0,0 +1,151 @@
|
||||
---
|
||||
title: 在 Amazon EKS 上安装 Rancher
|
||||
---
|
||||
|
||||
本文介绍了如何在 Amazon EKS 集群上安装 Rancher。你也可以[通过 AWS Marketplace 安装 Rancher](../../quick-start-guides/deploy-rancher-manager/aws-marketplace.md)。
|
||||
|
||||
如果你已经有一个 EKS Kubernetes 集群，请直接跳转到[安装 Ingress](#5-安装-ingress)这个步骤。然后按照[此处](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
|
||||
|
||||
## 为 Rancher Server 创建 EKS 集群
|
||||
|
||||
在本节中，你将使用命令行工具安装一个带有 Ingress 的 EKS 集群。如果你想在 EKS 上使用 Rancher 时使用较少的资源，请使用此方法。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
- 已有一个 AWS 账户。
|
||||
- 建议使用 IAM 用户而不是 AWS 根账户。你将需要 IAM 用户的访问密钥 (access key) 和密文秘钥 (secret key) 来配置 AWS 命令行界面。
|
||||
- IAM 用户需要具备[eksctl 文档](https://eksctl.io/usage/minimum-iam-policies/)中描述的最低 IAM 策略。
|
||||
|
||||
:::
|
||||
|
||||
### 1. 准备你的工作站
|
||||
|
||||
在工作站上安装以下命令行工具：
|
||||
|
||||
- **AWS CLI v2**：如需获取帮助，请参见[安装步骤](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)。
|
||||
- **eksctl**：如需获取帮助，请参见[安装步骤](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)。
|
||||
- **kubectl**：如需获得帮助，请参见[安装步骤](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)。
|
||||
- **helm**：如需获取帮助，请参见[安装步骤](https://helm.sh/docs/intro/install/)。
|
||||
|
||||
### 2. 配置 AWS CLI
|
||||
|
||||
运行以下命令，配置 AWS CLI：
|
||||
|
||||
```
|
||||
aws configure
|
||||
```
|
||||
|
||||
输入以下参数：
|
||||
|
||||
| 值 | 描述 |
|
||||
|-------|-------------|
|
||||
| AWS Access Key ID | 具有 EKS 权限的 IAM 用户的访问密钥凭证。 |
|
||||
| AWS Secret Access Key | 具有 EKS 权限的 IAM 用户的密文密钥凭证。 |
|
||||
| Default region name | 集群节点所在的 [AWS 区域](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html#Concepts.RegionsAndAvailabilityZones.Regions)。 |
|
||||
| Default output format | 输入 `json`。 |
|
||||
|
||||
### 3. 创建 EKS 集群
|
||||
|
||||
运行以下命令创建一个 EKS 集群。使用适用于你的用例的 AWS 区域。在选择 Kubernetes 版本时，请务必先查阅[支持矩阵](https://rancher.com/support-matrix/)，以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
|
||||
|
||||
**注意**：如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
|
||||
|
||||
```
|
||||
eksctl create cluster \
|
||||
--name rancher-server \
|
||||
--version <VERSION> \
|
||||
--region us-west-2 \
|
||||
--nodegroup-name ranchernodes \
|
||||
--nodes 3 \
|
||||
--nodes-min 1 \
|
||||
--nodes-max 4 \
|
||||
--managed
|
||||
```
|
||||
|
||||
使用 CloudFormation 进行的集群部署可能需要一些时间才能完成。
|
||||
|
||||
### 4. 测试集群
|
||||
|
||||
运行以下命令测试集群：
|
||||
|
||||
```
|
||||
eksctl get cluster
|
||||
```
|
||||
|
||||
返回的结果应与以下内容类似：
|
||||
|
||||
```
|
||||
eksctl get cluster
|
||||
2021-03-18 15:09:35 [ℹ] eksctl version 0.40.0
|
||||
2021-03-18 15:09:35 [ℹ] using region us-west-2
|
||||
NAME REGION EKSCTL CREATED
|
||||
rancher-server-cluster us-west-2 True
|
||||
```
|
||||
|
||||
### 5. 安装 Ingress
|
||||
|
||||
集群需要一个 Ingress，以从集群外部访问 Rancher。
|
||||
|
||||
为确保你选择了正确的 Ingress-NGINX Helm Chart，首先在 [Kubernetes/ingress-nginx 支持表](https://github.com/kubernetes/ingress-nginx#supported-versions-table)中找到与你的 Kubernetes 版本兼容的 `Ingress-NGINX 版本`。
|
||||
|
||||
然后，运行以下命令列出可用的 Helm Chart：
|
||||
|
||||
```
|
||||
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
|
||||
helm repo update
|
||||
helm search repo ingress-nginx -l
|
||||
```
|
||||
|
||||
`helm search` 命令的输出包含一个 `APP VERSION` 列。此列下的版本等同于你之前选择的 `Ingress-NGINX 版本`。使用应用程序版本，选择一个 Chart 版本，该版本打包了与你的 Kubernetes 兼容的应用程序。例如，如果使用的是 Kubernetes v1.23，则可以选择 v4.6.0 Helm Chart，因为 Ingress-NGINX v1.7.0 与该 Chart 打包在一起，而 v1.7.0 与 Kubernetes v1.23 兼容。如有疑问，请选择最新的兼容版本。
|
||||
|
||||
了解你需要的 Helm chart `版本`后，运行以下命令。它安装一个带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`：
|
||||
|
||||
```
|
||||
helm upgrade --install \
|
||||
ingress-nginx ingress-nginx/ingress-nginx \
|
||||
--namespace ingress-nginx \
|
||||
--set controller.service.type=LoadBalancer \
|
||||
--version 4.6.0 \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
### 6. 获取负载均衡器的 IP
|
||||
|
||||
运行以下命令获取负载均衡器的 IP 地址：
|
||||
|
||||
```
|
||||
kubectl get service ingress-nginx-controller --namespace=ingress-nginx
|
||||
```
|
||||
|
||||
返回的结果应与以下内容类似：
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
|
||||
AGE
|
||||
ingress-nginx-controller LoadBalancer 10.100.90.18 a904a952c73bf4f668a17c46ac7c56ab-962521486.us-west-2.elb.amazonaws.com 80:31229/TCP,443:31050/TCP
|
||||
27m
|
||||
```
|
||||
|
||||
保存 `EXTERNAL-IP`。
|
||||
|
||||
### 7. 设置 DNS
|
||||
|
||||
到 Rancher Server 的外部流量需要重定向到你创建的负载均衡器。
|
||||
|
||||
创建指向你保存的外部 IP 地址的 DNS。这个 DNS 会用作 Rancher Server 的 URL。
|
||||
|
||||
设置 DNS 的有效方法有很多。如需获得帮助，请参见 AWS 文档中心的[转发流量到 ELB 负载均衡器](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html)。
|
||||
|
||||
### 8. 安装 Rancher Helm Chart
|
||||
|
||||
按照[本页](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 安装命令。
|
||||
|
||||
在此设置之上安装 Rancher 时，你还需要将以下值传递到 Rancher Helm 安装命令，以设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称：
|
||||
|
||||
```
|
||||
--set ingress.ingressClassName=nginx
|
||||
```
|
||||
|
||||
请参阅[Helm 安装命令](install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
+201
@@ -0,0 +1,201 @@
|
||||
---
|
||||
title: 在 GKE 集群上安装 Rancher
|
||||
---
|
||||
|
||||
在本节中，你将学习如何使用 GKE 安装 Rancher。
|
||||
|
||||
如果你已经有一个 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 的硬件要求，请参见[本节](../installation-requirements/installation-requirements.md)。
|
||||
|
||||
## 1. 启用 Kubernetes Engine API
|
||||
|
||||
按照以下步骤启用 Kubernetes Engine API：
|
||||
|
||||
1. 访问 Google Cloud Console 中的 [Kubernetes Engine 页面](https://console.cloud.google.com/projectselector/kubernetes?_ga=2.169595943.767329331.1617810440-856599067.1617343886)。
|
||||
1. 创建或选择一个项目。
|
||||
1. 打开项目，并为项目启用 Kubernetes Engine API。等待 API 和相关服务的启用。这可能需要几分钟时间。
|
||||
1. 确保为你的云项目启用了计费。有关如何为你的项目启用计费，请参见 [Google Cloud 文档中心](https://cloud.google.com/billing/docs/how-to/modify-project#enable_billing_for_a_project)。
|
||||
|
||||
## 2. 打开 Cloud Shell
|
||||
|
||||
Cloud Shell 是一个 shell 环境，用于管理托管在 Google Cloud 上的资源。Cloud Shell 预装了 `gcloud` 命令行工具和 kubectl 命令行工具中。`gcloud` 工具为 Google Cloud 提供主要的命令行界面，而`kubectl` 则提供针对 Kubernetes 集群的主要命令行界面。
|
||||
|
||||
下文描述了如何从 Google Cloud Console 或从本地工作站启动 Cloud Shell。
|
||||
|
||||
### Cloud Shell
|
||||
|
||||
如需从 [Google Cloud Console](https://console.cloud.google.com) 启动 shell，请在控制台的右上角点击终端按钮。鼠标悬停在按钮上时，它会标记为 **Activate Cloud Shell**。
|
||||
|
||||
### 本地 Shell
|
||||
|
||||
执行以下步骤以安装 `gcloud` 和 `kubectl`：
|
||||
|
||||
1. 按照[这些步骤](https://cloud.google.com/sdk/docs/install)安装 Cloud SDK。The Cloud SDK 包括 `gcloud` 命令行工具。不同操作系统对应的步骤有所不同。
|
||||
1. 安装 Cloud SDK 后，运行以下命令以安装 `kubectl` 命令行工具：
|
||||
|
||||
```
|
||||
gcloud components install kubectl
|
||||
```
|
||||
后面的步骤会配置 `kubectl`，使其用于使用新的 GKE 集群。
|
||||
1. 如果 Helm 3 未安装的话，[安装 Helm 3](https://helm.sh/docs/intro/install/)。
|
||||
1. 使用 `HELM_EXPERIMENTAL_OCI` 变量来启用 Helm 的实验功能 [OCI 镜像支持](https://github.com/helm/community/blob/master/hips/hip-0006.md)。把以下行添加到 `~/.bashrc` （或 macOS 中的 `~/.bash_profile`，或者你的 shell 存储环境变量的地方）：
|
||||
|
||||
```
|
||||
export HELM_EXPERIMENTAL_OCI=1
|
||||
```
|
||||
1. 运行以下命令来加载你更新的 `.bashrc` 文件：
|
||||
|
||||
```
|
||||
source ~/.bashrc
|
||||
```
|
||||
如果你运行的是 macOS，使用这个命令:
|
||||
```
|
||||
source ~/.bash_profile
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 3. 配置 gcloud CLI
|
||||
|
||||
选择以下方法之一配置默认的 gcloud 设置：
|
||||
|
||||
- 如果你想了解默认值，请使用 gcloud init。
|
||||
- 如需单独设置你的项目 ID、地区和区域，使用 gcloud config。
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="使用 gcloud init">
|
||||
|
||||
1. 运行 gcloud init 并按照指示操作：
|
||||
|
||||
```
|
||||
gcloud init
|
||||
```
|
||||
如果你在远程服务器上使用 SSH，使用 --console-only 标志，以防止该命令启动浏览器。
|
||||
|
||||
```
|
||||
gcloud init --console-only
|
||||
```
|
||||
2. 按照指示，以授权 gcloud 使用你的 Google Cloud 账户，并选择你创建的新项目。
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="使用 gcloud config">
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 4. 确认 gcloud 的配置是否正确
|
||||
|
||||
运行：
|
||||
|
||||
```
|
||||
gcloud config list
|
||||
```
|
||||
|
||||
返回的结果应与以下内容类似：
|
||||
|
||||
```
|
||||
[compute]
|
||||
region = us-west1 # Your chosen region
|
||||
zone = us-west1-b # Your chosen zone
|
||||
[core]
|
||||
account = <Your email>
|
||||
disable_usage_reporting = True
|
||||
project = <Your project ID>
|
||||
|
||||
Your active configuration is: [default]
|
||||
```
|
||||
|
||||
## 5. 创建一个 GKE 集群
|
||||
|
||||
下面的命令创建了一个三节点的集群。
|
||||
|
||||
把 `cluster-name` 替换为你新集群的名称。
|
||||
|
||||
在选择 Kubernetes 版本时，请务必先查阅[支持矩阵](https://rancher.com/support-matrix/)，以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
|
||||
|
||||
要使用 Rancher 成功创建 GKE 集群，GKE 必须处于 Standard 模式。GKE 在创建 Kubernetes 集群时有两种运行模式，分别是 Autopilot 和 Standard 模式。Autopilot 模式的集群配置对编辑 kube-system 命名空间有限制。但是，Rancher 在安装时需要在 kube-system 命名空间中创建资源。因此，你将无法在以 Autopilot 模式创建的 GKE 集群上安装 Rancher。如需详细了解 GKE Autopilot 模式和 Standard 模式之间的差异，请访问[比较 GKE Autopilot 和 Standard ](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison)。
|
||||
|
||||
**注意**：如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
|
||||
|
||||
```
|
||||
gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=<VERSION>
|
||||
```
|
||||
|
||||
## 6. 获取验证凭证
|
||||
|
||||
创建集群后，你需要获得认证凭证才能与集群交互：
|
||||
|
||||
```
|
||||
gcloud container clusters get-credentials cluster-name
|
||||
```
|
||||
|
||||
此命令将 `kubectl` 配置成使用你创建的集群。
|
||||
|
||||
## 7. 安装 Ingress
|
||||
|
||||
集群需要一个 Ingress，以从集群外部访问 Rancher。
|
||||
|
||||
以下命令安装带有 LoadBalancer 服务的 `nginx-ingress-controller`：
|
||||
|
||||
```
|
||||
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
|
||||
helm repo update
|
||||
helm upgrade --install \
|
||||
ingress-nginx ingress-nginx/ingress-nginx \
|
||||
--namespace ingress-nginx \
|
||||
--set controller.service.type=LoadBalancer \
|
||||
--version 4.0.18 \
|
||||
--create-namespace
|
||||
```
|
||||
|
||||
## 8. 获取负载均衡器的 IP
|
||||
|
||||
运行以下命令获取负载均衡器的 IP 地址：
|
||||
|
||||
```
|
||||
kubectl get service ingress-nginx-controller --namespace=ingress-nginx
|
||||
```
|
||||
|
||||
返回的结果应与以下内容类似：
|
||||
|
||||
```
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
ingress-nginx-controller LoadBalancer 10.3.244.156 35.233.206.34 80:31876/TCP,443:32497/TCP 81s
|
||||
```
|
||||
|
||||
保存 `EXTERNAL-IP`。
|
||||
|
||||
## 9. 设置 DNS
|
||||
|
||||
到 Rancher Server 的外部流量需要重定向到你创建的负载均衡器。
|
||||
|
||||
创建指向你保存的外部 IP 地址的 DNS。这个 DNS 会用作 Rancher Server 的 URL。
|
||||
|
||||
设置 DNS 的有效方法有很多。如需获取帮助，请参见 Google Cloud 文档中的[管理 DNS 记录](https://cloud.google.com/dns/docs/records)部分。
|
||||
|
||||
## 10. 安装 Rancher Helm Chart
|
||||
|
||||
按照[本页](../../../pages-for-subheaders/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 安装命令。
|
||||
|
||||
在此设置之上安装 Rancher 时，你还需要设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称：
|
||||
|
||||
```
|
||||
--set ingress.ingressClassName=nginx
|
||||
```
|
||||
|
||||
请参阅[Helm 安装命令](install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
|
||||
|
||||
在 Rancher v2.7.5 中，如果你打算在集群上使用默认的 GKE Ingress 而不启用 VPC 原生的集群模式，则需要设置以下标志：
|
||||
|
||||
```
|
||||
--set service.type=NodePort
|
||||
```
|
||||
|
||||
此设置是必要的，这考虑了与 ClusterIP（`cattle-system/rancher` 的默认类型）之间的兼容性问题。
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: AdmissionConfiguration
|
||||
plugins:
|
||||
- configuration:
|
||||
apiVersion: pod-security.admission.config.k8s.io/v1
|
||||
defaults:
|
||||
audit: restricted
|
||||
audit-version: latest
|
||||
enforce: restricted
|
||||
enforce-version: latest
|
||||
warn: restricted
|
||||
warn-version: latest
|
||||
exemptions:
|
||||
namespaces:
|
||||
- ingress-nginx
|
||||
- kube-system
|
||||
- cattle-system
|
||||
- cattle-epinio-system
|
||||
- cattle-fleet-system
|
||||
- longhorn-system
|
||||
- cattle-neuvector-system
|
||||
- cattle-monitoring-system
|
||||
- rancher-alerting-drivers
|
||||
- cis-operator-system
|
||||
- cattle-csp-adapter-system
|
||||
- cattle-externalip-system
|
||||
- cattle-gatekeeper-system
|
||||
- istio-system
|
||||
- cattle-istio-system
|
||||
- cattle-logging-system
|
||||
- cattle-windows-gmsa-system
|
||||
- cattle-sriov-system
|
||||
- cattle-ui-plugin-system
|
||||
- tigera-operator
|
||||
kind: PodSecurityConfiguration
|
||||
name: PodSecurity
|
||||
path: ""
|
||||
+154
@@ -0,0 +1,154 @@
|
||||
---
|
||||
title: 回滚
|
||||
---
|
||||
|
||||
本页概述了如何在升级 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 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 脚本：
|
||||
|
||||
|
||||
* `cleanup.sh`：清理集群。
|
||||
* `verify.sh`：检查集群中是否有任何与 Rancher 相关的资源。
|
||||
|
||||
|
||||
:::caution
|
||||
|
||||
`cleanup.sh` 运行的时候会有停机时间，这是因为脚本会删除 Rancher 创建的资源。
|
||||
|
||||
:::
|
||||
|
||||
**结果：** 上游（本地）集群中所有 Rancher 关联的资源将被清理。
|
||||
|
||||
请参阅 [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+
|
||||
|
||||
要回滚到 Rancher 2.5.0+，使用 **Rancher 备份**应用并通过备份来恢复 Rancher。
|
||||
|
||||
回滚后，Rancher 必须以较低/较早的版本启动。
|
||||
|
||||
还原是通过创建 Restore 自定义资源实现的。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
* 请按照此页面上的说明在已备份的同一集群上还原 Rancher。要把 Rancher 迁移到新集群，请参照步骤[迁移 Rancher](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
|
||||
|
||||
* 在使用相同设置恢复 Rancher 时，Rancher deployment 在恢复开始前被手动缩减，然后 Operator 将在恢复完成后将其缩回。因此，在恢复完成之前，Rancher 和 UI 都将不可用。如果 UI 不可用时，你可使用 `kubectl create -f restore.yaml`YAML 恢复文件来使用初始的集群 kubeconfig。
|
||||
|
||||
:::
|
||||
|
||||
### 步骤 1 ：创建 Restore 自定义资源
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 找到你的本地集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，点击 **Rancher 备份 > 还原**。
|
||||
:::note
|
||||
|
||||
如果 Rancher Backups 应用不可见，你需要到 **Apps** 的 Charts 页面中安装应用。详情请参见[此处](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#access-charts)。
|
||||
|
||||
:::
|
||||
|
||||
1. 单击**创建**。
|
||||
1. 使用表单或 YAML 创建 Restore。如需获取使用表单创建 Restore 资源的更多信息，请参见[配置参考](../../../reference-guides/backup-restore-configuration/restore-configuration.md)和[示例](../../../reference-guides/backup-restore-configuration/examples.md)。
|
||||
1. 如需使用 YAML 编辑器，点击**创建 > 使用 YAML 文件创建**。然后输入 Restore YAML。以下是 Restore 自定义资源示例：
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Restore
|
||||
metadata:
|
||||
name: restore-migration
|
||||
spec:
|
||||
backupFilename: backup-b0450532-cee1-4aa1-a881-f5f48a007b1c-2020-09-15T07-27-09Z.tar.gz
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
storageLocation:
|
||||
s3:
|
||||
credentialSecretName: s3-creds
|
||||
credentialSecretNamespace: default
|
||||
bucketName: rancher-backups
|
||||
folder: rancher
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
```
|
||||
如需获得配置 Restore 的帮助，请参见[配置参考](../../../reference-guides/backup-restore-configuration/restore-configuration.md)和[示例](../../../reference-guides/backup-restore-configuration/examples.md)。
|
||||
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：已创建备份文件并更新到目标存储位置。资源还原顺序如下：
|
||||
|
||||
1. 自定义资源定义（CRD）
|
||||
2. 集群范围资源
|
||||
3. 命名空间资源
|
||||
|
||||
如需查看还原的处理方式，请检查 Operator 的日志。按照如下步骤获取日志：
|
||||
|
||||
```yaml
|
||||
kubectl get pods -n cattle-resources-system
|
||||
kubectl logs -n cattle-resources-system -f
|
||||
```
|
||||
|
||||
### 步骤 2：回滚到上一个 Rancher 版本
|
||||
|
||||
你可以使用 Helm CLI 回滚 Rancher。要回滚到上一个版本：
|
||||
|
||||
```yaml
|
||||
helm rollback rancher -n cattle-system
|
||||
```
|
||||
|
||||
如果你不是想回滚到上一个版本，你也可以指定回滚的版本。查看部署历史记录：
|
||||
|
||||
```yaml
|
||||
helm history rancher -n cattle-system
|
||||
```
|
||||
|
||||
确定目标版本后，执行回滚。此示例回滚到版本 `3`：
|
||||
|
||||
```yaml
|
||||
helm rollback rancher 3 -n cattle-system
|
||||
```
|
||||
|
||||
## 回滚到 Rancher 2.2-2.4
|
||||
|
||||
要回滚到 2.5 之前的 Rancher 版本，参考此处的步骤[恢复备份 — Kubernetes 安装](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md)。如果恢复 Rancher Server 的集群的某个快照，Rancher 的版本以及状态均会恢复回到快照时的版本和状态。
|
||||
|
||||
有关回滚 Docker 安装的 Rancher，请参见[本页](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)。
|
||||
|
||||
:::note
|
||||
|
||||
托管集群对其状态具有权威性。因此，恢复 Rancher Server 不会恢复快照后对托管集群进行的工作负载部署或更改。
|
||||
|
||||
:::
|
||||
|
||||
## 回滚到 Rancher 2.0-2.1
|
||||
|
||||
我们不再支持回滚到 Rancher 2.0-2.1。回滚到这些版本的说明保留在[此处](/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md)，仅用于无法升级到 v2.2 的情况。
|
||||
+188
@@ -0,0 +1,188 @@
|
||||
---
|
||||
title: Rancher Server Kubernetes 集群的问题排查
|
||||
---
|
||||
|
||||
本文介绍如何对安装在 Kubernetes 集群上的 Rancher 进行故障排除。
|
||||
|
||||
### 相关命名空间
|
||||
|
||||
故障排除主要针对以下 3 个命名空间中的对象：
|
||||
|
||||
- `cattle-system`：`rancher` deployment 和 Pod。
|
||||
- `ingress-nginx`：Ingress Controller Pod 和 services。
|
||||
- `cert-manager`：`cert-manager` Pod。
|
||||
|
||||
### "default backend - 404"
|
||||
|
||||
很多操作都有可能导致 Ingress Controller 无法将流量转发到你的 Rancher 实例。但是大多数情况下都是由错误的 SSL 配置导致的。
|
||||
|
||||
检查事项：
|
||||
|
||||
- [Rancher 是否正在运行](#检查-rancher-是否正在运行)
|
||||
- [证书的 Common Name（CN）是 "Kubernetes Ingress Controller Fake Certificate"](#证书的-cn-是-kubernetes-ingress-controller-fake-certificate)
|
||||
|
||||
### 检查 Rancher 是否正在运行
|
||||
|
||||
使用 `kubectl` 检查 `cattle-system` 系统命名空间，并查看 Rancher Pod 的状态是否是 **Running**：
|
||||
|
||||
```
|
||||
kubectl -n cattle-system get pods
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
pod/rancher-784d94f59b-vgqzh 1/1 Running 0 10m
|
||||
```
|
||||
|
||||
如果状态不是 `Running`，在 Pod 上运行 `describe`，并检查 **Events**：
|
||||
|
||||
```
|
||||
kubectl -n cattle-system describe pod
|
||||
|
||||
...
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal Scheduled 11m default-scheduler Successfully assigned rancher-784d94f59b-vgqzh to localhost
|
||||
Normal SuccessfulMountVolume 11m kubelet, localhost MountVolume.SetUp succeeded for volume "rancher-token-dj4mt"
|
||||
Normal Pulling 11m kubelet, localhost pulling image "rancher/rancher:v2.0.4"
|
||||
Normal Pulled 11m kubelet, localhost Successfully pulled image "rancher/rancher:v2.0.4"
|
||||
Normal Created 11m kubelet, localhost Created container
|
||||
Normal Started 11m kubelet, localhost Started container
|
||||
```
|
||||
|
||||
### 检查 Rancher 日志
|
||||
|
||||
使用 `kubectl` 列出 Pod：
|
||||
|
||||
```
|
||||
kubectl -n cattle-system get pods
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
pod/rancher-784d94f59b-vgqzh 1/1 Running 0 10m
|
||||
```
|
||||
|
||||
使用 `kubectl` 和 Pod 名称列出该 Pod 的日志：
|
||||
|
||||
```
|
||||
kubectl -n cattle-system logs -f rancher-784d94f59b-vgqzh
|
||||
```
|
||||
|
||||
### 证书的 CN 是 "Kubernetes Ingress Controller Fake Certificate"
|
||||
|
||||
使用浏览器检查证书的详细信息。如果显示 CN 是 "Kubernetes Ingress Controller Fake Certificate"，则说明读取或颁发 SSL 证书时出现了问题。
|
||||
|
||||
:::note
|
||||
|
||||
如果你使用的是 Let's Encrypt 证书，证书颁发的过程可能需要几分钟。
|
||||
|
||||
:::
|
||||
|
||||
### 排查 Cert-Manager 颁发的证书（Rancher 或 Let's Encrypt 生成的）问题
|
||||
|
||||
`cert-manager` 有 3 部分：
|
||||
|
||||
- `cert-manager` 命名空间中的 `cert-manager` Pod。
|
||||
- `cattle-system` 命名空间中的 `Issuer` 对象。
|
||||
- `cattle-system` 命名空间中的 `Certificate` 对象。
|
||||
|
||||
往后操作，对每个对象运行 `kubectl describe` 并检查事件。这样，你可以追踪可能丢失的内容。
|
||||
|
||||
以下是 Issuer 有问题的示例：
|
||||
|
||||
```
|
||||
kubectl -n cattle-system describe certificate
|
||||
...
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Warning IssuerNotReady 18s (x23 over 19m) cert-manager Issuer rancher not ready
|
||||
```
|
||||
|
||||
```
|
||||
kubectl -n cattle-system describe issuer
|
||||
...
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Warning ErrInitIssuer 19m (x12 over 19m) cert-manager Error initializing issuer: secret "tls-rancher" not found
|
||||
Warning ErrGetKeyPair 9m (x16 over 19m) cert-manager Error getting keypair for CA issuer: secret "tls-rancher" not found
|
||||
```
|
||||
|
||||
### 排查你自己提供的 SSL 证书问题
|
||||
|
||||
你的证书直接应用于 `cattle-system` 命名空间中的 Ingress 对象。
|
||||
|
||||
检查 Ingress 对象的状态，并查看它是否准备就绪：
|
||||
|
||||
```
|
||||
kubectl -n cattle-system describe ingress
|
||||
```
|
||||
|
||||
如果 Ingress 对象已就绪，但是 SSL 仍然无法正常工作，你的证书或密文的格式可能不正确。
|
||||
|
||||
这种情况下，请检查 nginx-ingress-controller 的日志。nginx-ingress-controller 的 Pod 中有多个容器，因此你需要指定容器的名称：
|
||||
|
||||
```
|
||||
kubectl -n ingress-nginx logs -f nginx-ingress-controller-rfjrq nginx-ingress-controller
|
||||
...
|
||||
W0705 23:04:58.240571 7 backend_ssl.go:49] error obtaining PEM from secret cattle-system/tls-rancher-ingress: error retrieving secret cattle-system/tls-rancher-ingress: secret cattle-system/tls-rancher-ingress was not found
|
||||
```
|
||||
|
||||
### 没有匹配的 "Issuer"
|
||||
|
||||
你所选的 SSL 配置要求在安装 Rancher 之前先安装 Cert-Manager，否则会出现以下错误:
|
||||
|
||||
```
|
||||
Error: validation failed: unable to recognize "": no matches for kind "Issuer" in version "certmanager.k8s.io/v1alpha1"
|
||||
```
|
||||
|
||||
在这种情况下，先安装 Cert-Manager，然后再重新安装 Rancher。
|
||||
|
||||
|
||||
### Canal Pod 显示 READY 2/3
|
||||
|
||||
此问题的最常见原因是端口 8472/UDP 在节点之间未打开。因此，你可以检查你的本地防火墙、网络路由或安全组。
|
||||
|
||||
解决网络问题后，`canal` Pod 会超时并重启以建立连接。
|
||||
|
||||
### nginx-ingress-controller Pod 显示 RESTARTS
|
||||
|
||||
此问题的最常见原因是 `canal` pod 未能建立覆盖网络。参见 [canal Pod 显示 READY `2/3`](#canal-pod-显示-ready-23) 进行排查。
|
||||
|
||||
|
||||
### Failed to dial to /var/run/docker.sock: ssh: rejected: administratively prohibited (open failed)
|
||||
|
||||
此错误的原因可能是：
|
||||
|
||||
* 指定连接的用户无权访问 Docker Socket。如果是这个原因，你通过登录主机并运行 `docker ps` 命令来检查：
|
||||
|
||||
```
|
||||
$ ssh user@server
|
||||
user@server$ docker ps
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
```
|
||||
|
||||
如果需要了解如何进行正确设置，请参见[以非 root 用户身份管理 Docker](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user)。
|
||||
|
||||
* 你使用的操作系统是 RedHat 或 CentOS：由于 [Bugzilla #1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565)，你不能使用 `root` 用户连接到节点。因此，你需要添加一个单独的用户并配置其访问 Docker Socket。如果需要了解如何进行正确设置，请参见[以非 root 用户身份管理 Docker](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user)。
|
||||
|
||||
* SSH 服务器版本不是 6.7 或更高版本：高版本是 Socket 转发所必须的，用于通过 SSH 连接到 Docker Socket。你可以在你要连接的主机上使用 `sshd -V` 或使用 netcat 进行检查：
|
||||
```
|
||||
$ nc xxx.xxx.xxx.xxx 22
|
||||
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10
|
||||
```
|
||||
|
||||
### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: no key found
|
||||
|
||||
`ssh_key_path` 密钥文件无法访问：请确保你已经指定了私钥文件（不是公钥 `.pub`），而且运行 `rke` 命令的用户可以访问该私钥文件。
|
||||
|
||||
### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
|
||||
|
||||
`ssh_key_path` 密钥文件不是访问节点的正确文件：请仔细检查，确保你已为节点指定了正确的 `ssh_key_path` 和连接用户。
|
||||
|
||||
### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: cannot decode encrypted private keys
|
||||
|
||||
如需使用加密的私钥，请使用 `ssh-agent` 来使用密码来加载密钥。如果在运行 `rke` 命令的环境中找到 `SSH_AUTH_SOCK` 环境变量，它将自动用于连接到节点。
|
||||
|
||||
### Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
|
||||
|
||||
节点无法通过配置的 `address` 和 `port` 访问。
|
||||
+68
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: 将加固的自定义/导入集群升级到 Kubernetes v1.25
|
||||
---
|
||||
|
||||
Kubernetes v1.25 改变了集群描述和执行安全策略的方式。从这个版本开始，[Pod 安全策略 (PSP)](https://kubernetes.io/docs/concepts/security/pod-security-policy/)不再可用。Kubernetes v1.25 将它们替换为新的安全对象：[Pod 安全标准 (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/) 和 [Pod 安全准入 (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/)。
|
||||
|
||||
如果你具有自定义或导入的加固集群，你需要做好准备，确保将旧版本的 Kubernetes 顺利升级到 v1.25 或更高版本。
|
||||
|
||||
:::note
|
||||
|
||||
升级到 v1.25 后，添加必要的 Rancher 命名空间豁免。有关详细信息，请参阅 [Pod 安全准入 (PSA) 配置模板](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#豁免必须的-rancher-命名空间)。
|
||||
|
||||
:::
|
||||
|
||||
## 将导入的加固集群升级到 Kubernetes v1.25 或更高版本
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2" default>
|
||||
|
||||
在集群中的每个节点上执行以下操作：
|
||||
1. 将 [`rancher-psact.yaml`](./rancher-psact.yaml) 保存到 `/etc/rancher/rke2` 中。
|
||||
1. 编辑 RKE2 配置文件：
|
||||
1. 将 `profile` 字段更新为 `cis-1.23`。
|
||||
1. 指定刚才添加的配置文件的路径：`pod-security-admission-config-file: /etc/rancher/rke2/rancher-psact.yaml`。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="K3s">
|
||||
|
||||
在集群中的每个节点上执行以下操作：
|
||||
|
||||
遵循 K3s [将加固集群从 v1.24.x 升级到 v1.25.x](https://docs.k3s.io/known-issues#hardened-125)的官方说明，但使用[自定义](./rancher-psact.yaml)Rancher PSA 配置模板，而不是 K3s 官方网站上提供的配置。
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
执行这些步骤后，你可以通过 Rancher UI 升级集群的 Kubernetes 版本：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**表中找到要更新的集群，点击 **⋮**。
|
||||
1. 选择**编辑配置**。
|
||||
1. 在 **Kubernetes 版本**下拉菜单中，选择要使用的版本。
|
||||
1. 单击**保存**。
|
||||
|
||||
## 将自定义加固集群升级到 Kubernetes v1.25 或更高版本
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2" default>
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**表中找到要更新的集群，点击 **⋮**。
|
||||
1. 选择**编辑配置**。
|
||||
1. 在**基本信息 > 安全**下的 **CIS 配置文件**下拉菜单中，选择 `cis-1.23`。
|
||||
1. 在 **PSA 配置模板**下拉菜单中，选择 `rancher-restricted`。
|
||||
1. 在 **Kubernetes 版本**下拉菜单中，选择要使用的版本。
|
||||
1. 单击**保存**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="K3s">
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**表中找到要更新的集群，点击 **⋮**。
|
||||
1. 选择**编辑 YAML**。
|
||||
1. 从 `kube-apiserver-arg.enable-admission-plugins` 中删除 `PodSecurityPolicy`。
|
||||
1. 在 `spec` 字段中，添加一行：`defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted`
|
||||
1. 将 `kubernetesVersion` 更新为你选择的版本（v1.25 或更高版本）。
|
||||
1. 单击**保存**。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
+209
@@ -0,0 +1,209 @@
|
||||
---
|
||||
title: 升级
|
||||
---
|
||||
|
||||
本文介绍如何升级使用 Helm 安装在 Kubernetes 集群上的 Rancher Server。这些步骤也适用于使用 Helm 进行的离线安装。
|
||||
|
||||
有关使用 Docker 安装的 Rancher 的升级说明，请参见[本页。](../other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md)
|
||||
|
||||
如需升级 Kubernetes 集群中的组件，或 [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) 或 [附加组件（add-on）](https://rancher.com/docs/rke/latest/en/config-options/add-ons/)的定义，请参见 [RKE 升级文档](https://rancher.com/docs/rke/latest/en/upgrades/)的 Rancher Kubernetes 引擎。
|
||||
|
||||
|
||||
## 先决条件
|
||||
|
||||
### 访问 kubeconfig
|
||||
|
||||
Helm 的运行位置，应该与你的 kubeconfig 文件，或你运行 kubectl 命令的位置相同。
|
||||
|
||||
如果你在安装 Kubernetes 时使用了 RKE，那么 config 将会在你运行 `rke up` 的目录下创建。
|
||||
|
||||
kubeconfig 也可以通过 `--kubeconfig` 标签（详情请参见 https://helm.sh/docs/helm/helm/ ）来手动指定所需的集群。
|
||||
|
||||
### 查看已知问题
|
||||
|
||||
如需查看每个 Rancher 版本的已知问题，请参见 [GitHub](https://github.com/rancher/rancher/releases) 中的发行说明，或查看 [Rancher 论坛](https://forums.rancher.com/c/announcements/12)。
|
||||
|
||||
不支持 _升级_ 或 _升级到_ [rancher-alpha 仓库](../resources/choose-a-rancher-version.md#helm-chart-仓库)中的任何 Chart。
|
||||
### 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 升级的旧升级指南。
|
||||
|
||||
### 离线安装：推送镜像到私有镜像仓库
|
||||
|
||||
[仅适用于离线安装](../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 之前的版本升级
|
||||
|
||||
[从 2019 年 11 月 1 日开始，Let's Encrypt 已屏蔽早于 0.8.0 的 cert-manager 实例](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)。因此，请参见[说明](../resources/upgrade-cert-manager.md)把 cert-manager 升级到最新版本。
|
||||
|
||||
## 升级概要
|
||||
|
||||
按照以下步骤升级 Rancher Server：
|
||||
|
||||
|
||||
### 1. 备份运行 Rancher Server 的 Kubernetes 集群
|
||||
|
||||
使用[备份应用](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md)来备份 Rancher。
|
||||
|
||||
如果升级过程中出现问题，你将使用备份作为还原点。
|
||||
|
||||
### 2. 更新 Helm Chart 仓库
|
||||
|
||||
1. 更新本地 Helm 仓库缓存。
|
||||
|
||||
```
|
||||
helm repo update
|
||||
```
|
||||
|
||||
1. 获取你用来安装 Rancher 的仓库名称。
|
||||
|
||||
关于仓库及其区别，请参见 [Helm Chart 仓库](../resources/choose-a-rancher-version.md#helm-chart-仓库)。
|
||||
|
||||
- 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 版之间升级。
|
||||
|
||||
```
|
||||
helm repo list
|
||||
|
||||
NAME URL
|
||||
stable https://charts.helm.sh/stable
|
||||
rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
如果你想切换到不同的 Helm Chart 仓库，请按照[切换仓库步骤](../resources/choose-a-rancher-version.md#切换到不同-helm-chart-仓库)进行操作。如果你要切换仓库，请先再次列出仓库，再继续执行步骤 3，以确保添加了正确的仓库。
|
||||
|
||||
:::
|
||||
|
||||
1. 从 Helm Chart 仓库获取最新的 Chart 来安装 Rancher。
|
||||
|
||||
该命令将提取最新的 Chart，并将其作为 `.tgz`文件保存在当前目录中。
|
||||
|
||||
```plain
|
||||
helm fetch rancher-<CHART_REPO>/rancher
|
||||
```
|
||||
你可以通过 `--version=` 标记，来指定要升级的目标 Chart 版本。例如：
|
||||
|
||||
```plain
|
||||
helm fetch rancher-<CHART_REPO>/rancher --version=2.6.8
|
||||
```
|
||||
|
||||
### 3. 升级 Rancher
|
||||
|
||||
本节介绍了如何使用 Helm 升级 Rancher 的一般（互联网连接）或离线安装。
|
||||
|
||||
:::note 离线说明：
|
||||
|
||||
如果你在离线环境中安装 Rancher，请跳过本页的其余部分，按照[本页](air-gapped-upgrades.md)上的说明渲染 Helm 模板。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
从当前安装的 Rancher Helm Chart 中获取用 `--set`传递的值。
|
||||
|
||||
```
|
||||
helm get values rancher -n cattle-system
|
||||
|
||||
hostname: rancher.my.org
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
这个命令会列出更多的值。此处展示的只是其中一个值的例子。
|
||||
|
||||
:::
|
||||
|
||||
:::tip
|
||||
|
||||
Deployment 的名称可能会有所不同。例如，如果你通过 AWS Marketplace 部署 Rancher，则 Deployment 的名称为“rancher-stable”。
|
||||
因此：
|
||||
```
|
||||
helm get values rancher-stable -n cattle-system
|
||||
|
||||
hostname: rancher.my.org
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
如果要将 cert-manager 从 v1.5 或更早的版本升级到最新版本，请参阅 [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#选项-c升级-15-及以下版本的-cert-manager) 了解如何在不卸载或重新安装 Rancher 的情况下升级 cert-manager。否则，请按照以下[ Rancher 升级步骤](#rancher-升级步骤)进行操作。
|
||||
|
||||
#### Rancher 升级步骤
|
||||
|
||||
保留你的所有设置把 Rancher 升级到最新版本。
|
||||
|
||||
将上一步中的所有值用 `--set key=value` 追加到命令中。
|
||||
|
||||
对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。
|
||||
|
||||
```
|
||||
helm upgrade rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
以上是一个例子，可能有更多上一步的值需要追加。
|
||||
|
||||
:::
|
||||
|
||||
:::tip
|
||||
|
||||
如果你通过 AWS Marketplace 部署 Rancher，则 Deployment 的名称为“rancher-stable”。
|
||||
因此：
|
||||
```
|
||||
helm upgrade rancher-stable rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
另外，你也可以将当前的值导出到一个文件中，并在升级时引用该文件。例如，如果你只需要改变 Rancher 的版本：
|
||||
|
||||
1. 将当前值导出到文件：
|
||||
```
|
||||
helm get values rancher -n cattle-system -o yaml > values.yaml
|
||||
```
|
||||
1. 只更新 Rancher 版本：
|
||||
|
||||
对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。
|
||||
|
||||
```
|
||||
helm upgrade rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
-f values.yaml \
|
||||
--version=2.6.8
|
||||
```
|
||||
|
||||
### 4. 验证升级
|
||||
|
||||
登录 Rancher 以确认升级成功。
|
||||
|
||||
:::tip
|
||||
|
||||
升级后出现网络问题？
|
||||
|
||||
请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 已知升级问题
|
||||
|
||||
你可以在 [GitHub](https://github.com/rancher/rancher/releases) 发布说明以及 [Rancher 论坛](https://forums.rancher.com/c/announcements/12)中找到每个 Rancher 版本的已知问题。
|
||||
+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#持久化数据)
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: 功能开关
|
||||
---
|
||||
|
||||
使用功能开关（Feature Flag），你可以试用可选或实验性的功能并启用正在逐步淘汰的旧版功能。
|
||||
|
||||
要了解功能的值以及如何启用它们，请参阅[启用实验性功能](../../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。
|
||||
|
||||
:::note
|
||||
|
||||
某些功能要求重新启动 Rancher 容器。Rancher UI 中标记了要求重启的功能。
|
||||
|
||||
:::
|
||||
|
||||
以下是 Rancher 中可用的功能开关列表。如果你是从旧 Rancher 版本升级的，你可能会在 Rancher UI 中看到其他功能，例如 `proxy` 或 `dashboard`（均[已中断](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)）：
|
||||
|
||||
- `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/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 集群。此标志只能在安装时设置。后续无法启用或禁用它。
|
||||
- `rke1-custom-node-cleanup`：清除已删除的 RKE1 自定义节点。建议你启用此标志，以防止已删除的节点尝试重新加入集群。
|
||||
- `rke2`：启用配置 RKE2 集群。此标志默认启用。
|
||||
- `token-hashing`：启用令牌哈希。启用后，会使用 SHA256 算法对现有 Token 和所有新 Token 进行哈希处理。一旦对 Token 进行哈希处理，就无法撤消操作。此标志在启用后无法禁用。有关详细信息，请参阅 [API 令牌](../../../reference-guides/about-the-api/api-tokens.md#令牌哈希)。
|
||||
- `unsupported-storage-drivers`：允许启用非默认启用的存储提供程序和卷插件。有关详细信息，请参阅[允许使用不受支持的存储驱动程序](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)。
|
||||
|
||||
下表介绍了 Rancher 中功能开关的可用性和默认值。标记为“GA”的功能已普遍可用：
|
||||
|
||||
| 功能开关名称 | 默认值 | 状态 | 可用于 |
|
||||
| ----------------------------- | ------------- | ------------ | --------------- |
|
||||
| `continuous-delivery` | `true` | GA | v2.6.0 |
|
||||
| `fleet` | `true` | 不能禁用 | v2.6.0 |
|
||||
| `fleet` | `true` | GA | v2.5.0 |
|
||||
| `harvester` | `true` | 实验功能 | v2.6.1 |
|
||||
| `legacy` | 新安装：`false`；升级：`true` | GA | v2.6.0 |
|
||||
| `rke1-custom-node-cleanup` | `true` | GA | v2.6.0 |
|
||||
| `rke2` | `true` | 实验功能 | v2.6.0 |
|
||||
| `token-hashing` | 新安装：`false`；升级：`true` | GA | v2.6.0 |
|
||||
+310
@@ -0,0 +1,310 @@
|
||||
---
|
||||
title: Rancher Helm Chart 选项
|
||||
keywords: [rancher helm chart, rancher helm 选项, rancher helm chart 选项, helm chart rancher, helm 选项 rancher, helm chart 选项 rancher]
|
||||
---
|
||||
|
||||
本文提供了 Rancher Helm Chart 的配置参考。
|
||||
|
||||
如需选择 Helm Chart 版本，请参见[本页](../../../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md)。
|
||||
|
||||
了解开启实验性功能的详情，请参见[本页](../../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。
|
||||
|
||||
## 常用选项
|
||||
|
||||
| 选项 | 默认值 | 描述 |
|
||||
| ------------------------- | ------------- | ---------------------------------------------------------------------------------- |
|
||||
| `bootstrapPassword` | " " | `string` - 为第一个管理员用户设置[引导密码](#引导密码)。登录后，管理员需要重置密码。如不设置，会使用随机生成的引导密码。 |
|
||||
| `hostname` | " " | `string` - 你的 Rancher Server 的完全限定的域名（FQDN) |
|
||||
| `ingress.tls.source` | "rancher" | `string` - 从哪里获取 Ingress 的证书- "rancher, letsEncrypt, secret" |
|
||||
| `letsEncrypt.email` | " " | `string` - 你的邮箱地址 |
|
||||
| `letsEncrypt.environment` | "production" | `string` - 可选项："staging, production" |
|
||||
| `privateCA` | false | `bool` - 如果你的证书是由私有 CA 签发的，把这个值设置为 true |
|
||||
|
||||
<br/>
|
||||
|
||||
## 高级选项
|
||||
|
||||
| 选项 | 默认值 | 描述 |
|
||||
| ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `additionalTrustedCAs` | false | `bool` - 请参见[额外的授信 CA](#额外的授信-ca) |
|
||||
| `addLocal` | "true" | `string` - 让 Rancher 检测并导入 “local” Rancher Server 集群。_注意：此选项在 2.5.0 中已不可用。你可考虑使用 `restrictedAdmin` 选项，来避免用户修改本地集群。_ |
|
||||
| `antiAffinity` | "preferred" | `string` - Rancher Pod 的反亲和性规则 - "preferred, required" |
|
||||
| `auditLog.destination` | "sidecar" | `string` - 发送审计日志到 Sidecar 容器的控制台或 hostPath 卷 - "sidecar, hostPath" |
|
||||
| `auditLog.hostPath` | "/var/log/rancher/audit" | `string` - 主机上的日志文件目标地址（仅当`auditLog.destination` 的值是 `hostPath` 时生效） |
|
||||
| `auditLog.level` | 0 | `int` - 设置 [API 审计日志](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md)等级。0 代表关闭。[0-3] |
|
||||
| `auditLog.maxAge` | 1 | `int` - 旧审计日志文件最多可保留的天数（仅当`auditLog.destination` 的值是 `hostPath` 时生效） |
|
||||
| `auditLog.maxBackup` | 1 | `int` - 审计文件最大可保留的个数（仅当 `auditLog.destination` 的值是 `hostPath` 时生效） |
|
||||
| `auditLog.maxSize` | 100 | `int` - 在审计日志被轮换前的最大容量，单位是 MB（仅当 `auditLog.destination` 的值是 `hostPath` 时生效） |
|
||||
| `auditLog.image.repository` | "registry.suse.com/bci/bci-micro" | `string` - 用于收集审计日志的镜像的位置。 |
|
||||
| `auditLog.image.tag` | "15.4.14.3" | `string` - 用于收集审计日志的镜像的标签。 |
|
||||
| `auditLog.image.pullPolicy` | "IfNotPresent" | `string` - 覆盖 auditLog 镜像的 imagePullPolicy - “Always”、“Never”、“IfNotPresent”。 |
|
||||
| `busyboxImage` | "" | `string` - 用于收集审计日志的 busybox 镜像位置。_注意：此选项已弃用，请使用 `auditLog.image.repository` 来控制审计 sidecar 镜像_。 |
|
||||
| `certmanager.version` | "" | `string` - 设置 cert-manager compatibility |
|
||||
| `debug` | false | `bool` - 在 Rancher Server 设置 debug 参数 |
|
||||
| `extraEnv` | [] | `list` - 为 Rancher 额外设置环境变量 |
|
||||
| `imagePullSecrets` | [] | `list` - 私有镜像仓库凭证的密文名称列表 |
|
||||
| `ingress.configurationSnippet` | "" | `string` - 添加额外的 Nginx 配置。可用于代理配置。 |
|
||||
| `ingress.extraAnnotations` | {} | `map` - 用于自定义 Ingress 的额外注释 |
|
||||
| `ingress.enabled` | true | 如果值为 false，Helm 不会安装 Rancher Ingress。你可把值设为 false 以部署你自己的 Ingress。 |
|
||||
| `letsEncrypt.ingress.class` | "" | `string` - cert-manager acmesolver ingress 的可选 ingress 类，用于响应 Let's Encrypt ACME 质询。选项：traefik，nginx。 | |
|
||||
| `noProxy` | "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local,cattle-system.svc" | `string` - 不使用代理的主机名或 IP 地址的逗号分隔列表 | |
|
||||
| `proxy` | "" | `string` - 给 Rancher 配置的 HTTP[S] 代理 |
|
||||
| `rancherImage` | "rancher/rancher" | `string` - Rancher 镜像源 |
|
||||
| `rancherImagePullPolicy` | "IfNotPresent" | `string` - 覆盖 Rancher Server 镜像的 imagePullPolicy - "Always", "Never", "IfNotPresent" |
|
||||
| `rancherImageTag` | 和 Chart 版本一致 | `string` - rancher/rancher 镜像标签 |
|
||||
| `replicas` | 3 | `int` - Rancher Server 副本数。如果设为 -1，会根据集群中的可用节点数自动选择 1，2或3。 |
|
||||
| `resources` | {} | `map` - Rancher Pod 资源请求和限制 |
|
||||
| `restrictedAdmin` | `false` | `bool` - 如果值为 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#受限管理员)。 |
|
||||
| `systemDefaultRegistry` | "" | `string` - 用于所有系统容器镜像的私有仓库，例如 http://registry.example.com/ |
|
||||
| `tls` | "ingress" | `string` - 详情请参见[外部 TLS 终止](#外部-tls-终止)。- "ingress, external" |
|
||||
| `useBundledSystemChart` | `false` | `bool` - 选择 Rancher Server 打包的 system-charts。此参数用于离线环境安装。 |
|
||||
| `global.cattle.psp.enabled` | `true` | `bool` - 使用 Rancher v2.7.2-v2.7.4 时，选择 `false` 以禁用 Kubernetes v1.25 及更高版本的 PSP。使用 Rancher v2.7.5 及更高版本时，Rancher 会尝试检测集群是否运行不支持 PSP 的 Kubernetes 版本，如果确定集群不支持 PSP，则将默认 PSP 的使用设置为 false。你仍然可以通过显式提供此值的 `true` 或 `false` 来手动覆盖此值。在支持 PSP 的集群中（例如使用 Kubernetes v1.24 或更低版本的集群），Rancher 仍将默认使用 PSP。 |
|
||||
|
||||
|
||||
### 引导密码
|
||||
|
||||
Rancher 首次启动时，会为第一个管理员用户随机生成一个密码。当管理员首次登录 Rancher 时，用于获取引导密码（Bootstrap）的命令会在 UI 上显示。管理员需要运行命令并使用引导密码登录。然后 Rancher 会让管理员重置密码。
|
||||
|
||||
如果你想指定引导密码而不使用随机生成的密码，请参考以下命令设置密码。
|
||||
|
||||
```plain
|
||||
--set bootstrapPassword="rancher"
|
||||
```
|
||||
|
||||
无论你是使用提供的密码还是生成的密码，密码均存储在 Kubernetes 密文中。安装 Rancher 后，如何使用 kubectl 获取密码的说明将会在 UI 中显示：
|
||||
|
||||
```
|
||||
kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
|
||||
```
|
||||
|
||||
### API 审计日志
|
||||
|
||||
启用 [API 审计日志](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.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](../../../integrations-in-rancher/logging/logging.md)。
|
||||
|
||||
将 `auditLog.destination` 的值设为 `hostPath`，可以将日志转发到与主机系统共享的卷，而不是传输到 Sidecar 容器。如果目标设置为 `hostPath`，你可能需要调整其他 auditLog 参数以进行日志轮换。
|
||||
|
||||
### 额外设置环境变量
|
||||
|
||||
你可以使用 `extraEnv` 为 Rancher Server 额外设置环境变量。该列表以 YAML 格式传递给 Rancher 部署，它嵌入在 Rancher 容器的 `env` 下。你可以参考 Kubernetes 文档设置容器环境变量。`extraEnv` 可以使用 [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container) 中引用的任何键。
|
||||
|
||||
使用 `name` 和 `value` 键的示例：
|
||||
|
||||
```plain
|
||||
--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
|
||||
--set 'extraEnv[0].value=1.0'
|
||||
```
|
||||
|
||||
如果将敏感数据（例如代理认证凭证）作为环境变量的值传递，则强烈建议使用 Secret 引用。这将防止敏感数据在 Helm 或 Rancher 部署中暴露。
|
||||
|
||||
你可以参考使用 `name`、`valueFrom.secretKeyRef.name` 和 `valueFrom.secretKeyRef.key` 键的示例。详见 [HTTP 代理](#http-代理)中的示例。
|
||||
|
||||
### TLS 设置
|
||||
|
||||
当你在 Kubernetes 集群内安装 Rancher 时，TLS 会在集群的 Ingress Controller 上卸载。支持的 TLS 设置取决于使用的 Ingress Controller。
|
||||
|
||||
参见 [TLS 设置](tls-settings.md)了解更多信息和选项。
|
||||
|
||||
### 导入 `local` 集群
|
||||
|
||||
默认情况下，Rancher Server 会检测并导入其所在的 `local` 集群。有权访问 `local` 集群的用户对 Rancher Server 管理的所有集群具有“root”访问权限。
|
||||
|
||||
:::caution
|
||||
|
||||
如果你关闭 addLocal，大多数 Rancher 2.5 功能都不能使用，包括 EKS Provisioner。
|
||||
|
||||
:::
|
||||
|
||||
如果这在你的环境中是一个问题，你可以在初始安装时将此选项设置为“false”。
|
||||
|
||||
此选项仅在首次安装 Rancher 时有效。详情请参见 [Issue 16522](https://github.com/rancher/rancher/issues/16522)。
|
||||
|
||||
```plain
|
||||
--set addLocal="false"
|
||||
```
|
||||
|
||||
### 自定义 Ingress
|
||||
|
||||
要自定义或使用 Rancher Server 的其他 Ingress，你可以设置自己的 Ingress 注释。
|
||||
|
||||
设置自定义证书颁发者的示例：
|
||||
|
||||
```plain
|
||||
--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
|
||||
```
|
||||
|
||||
以下是使用 `ingress.configurationSnippet`设置静态代理标头的示例。该值像模板一样进行解析，因此可以使用变量。
|
||||
|
||||
```plain
|
||||
--set ingress.configurationSnippet='more_set_input_headers X-Forwarded-Host {{ .Values.hostname }};'
|
||||
```
|
||||
|
||||
### HTTP 代理
|
||||
|
||||
Rancher 的一些功能（Helm Chart）需要使用互联网才能使用。你可以使用 `proxy` 设置代理服务器，或使用 `extraEnv` 设置 `HTTPS_PROXY` 环境变量来指向代理服务器。
|
||||
|
||||
将要排除的 IP 使用逗号分隔列表添加到 `noProxy` Chart value 中。确保添加了以下值：
|
||||
- Pod 集群 IP 范围（默认值：`10.42.0.0/16`）。
|
||||
- Service Cluster IP 范围（默认值：`10.43.0.0/16`）。
|
||||
- 内部集群域（默认值：`.svc,.cluster.local`）。
|
||||
- 任何 Worker 集群 `controlplane` 节点。
|
||||
Rancher 支持在此列表中使用 CIDR 表示法来表示范围。
|
||||
|
||||
不包括敏感数据时，可以使用 `proxy` 或 `extraEnv` Chart 选项。使用 `extraEnv` 时将忽略 `noProxy` Helm 选项。因此，`NO_PROXY` 环境变量也必须设置为 `extraEnv`。
|
||||
|
||||
以下是使用 `proxy` Chart 选项设置代理的示例：
|
||||
|
||||
```plain
|
||||
--set proxy="http://<proxy_url:proxy_port>/"
|
||||
```
|
||||
|
||||
使用 `extraEnv` Chart 选项设置代理的示例：
|
||||
```plain
|
||||
--set extraEnv[1].name=HTTPS_PROXY
|
||||
--set extraEnv[1].value="http://<proxy_url>:<proxy_port>/"
|
||||
--set extraEnv[2].name=NO_PROXY
|
||||
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
|
||||
```
|
||||
|
||||
包含敏感数据（例如代理认证凭证）时，请使用 `extraEnv` 选项和 `valueFrom.secretRef` 来防止敏感数据在 Helm 或 Rancher 部署中暴露。
|
||||
|
||||
下面是使用 `extraEnv` 配置代理的示例。此示例 Secret 在 Secret 的 `"https-proxy-url"` 键中包含 `"http://<username>:<password>@<proxy_url>:<proxy_port>/"` 值：
|
||||
```plain
|
||||
--set extraEnv[1].name=HTTPS_PROXY
|
||||
--set extraEnv[1].valueFrom.secretKeyRef.name=secret-name
|
||||
--set extraEnv[1].valueFrom.secretKeyRef.key=https-proxy-url
|
||||
--set extraEnv[2].name=NO_PROXY
|
||||
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
|
||||
```
|
||||
|
||||
有关如何配置环境变量的更多信息，请参阅[为容器定义环境变量](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container)。
|
||||
|
||||
### 额外的授信 CA
|
||||
|
||||
如果你有私有镜像仓库（registries）、应用商店（catalogs）或拦截证书的代理，则可能需要向 Rancher 添加额外的授信 CA。
|
||||
|
||||
```plain
|
||||
--set additionalTrustedCAs=true
|
||||
```
|
||||
|
||||
创建完 Rancher deployment 后，将 pem 格式的 CA 证书复制到一个名为 `ca-additional.pem` 的文件中，并使用 `kubectl` 在 `cattle-system` 命名空间中创建 `tls-ca-additional` 密文。
|
||||
|
||||
```plain
|
||||
kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-additional.pem=./ca-additional.pem
|
||||
```
|
||||
|
||||
### 私有仓库和离线安装
|
||||
|
||||
有关使用私有仓库安装 Rancher 的详情，请参见[离线安装](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md)。
|
||||
|
||||
## 外部 TLS 终止
|
||||
|
||||
我们建议将负载均衡器配置为 4 层均衡，将普通 80/tcp 和 443/tcp 转发到 Rancher Management 集群节点。集群上的 Ingress Controller 会将端口 80 上的 HTTP 流量重定向到端口 443 上的 HTTPS。
|
||||
|
||||
你可以在 Rancher 集群（Ingress）外部的 L7 负载均衡器上终止 SSL/TLS。使用 `--set tls=external` 选项，将负载均衡器指向所有 Rancher 集群节点上的端口 HTTP 80。这将在 HTTP 端口 80 上暴露 Rancher 接口。请注意，允许直接连接到 Rancher 集群的客户端不会被加密。如果你选择这样做，我们建议你将网络级别的直接访问限制为仅你的负载均衡器。
|
||||
|
||||
:::note
|
||||
|
||||
如果你使用的是私有 CA 签名的证书，请添加 `--set privateCA=true` 并参见[添加 TLS 密文 - 使用私有 CA 签名证书](../../../getting-started/installation-and-upgrade/resources/add-tls-secrets.md)，为 Rancher 添加 CA 证书。
|
||||
|
||||
:::
|
||||
|
||||
你的负载均衡器必须支持长期存在的 Websocket 连接，并且需要插入代理头，以便 Rancher 可以正确传送链接。
|
||||
|
||||
### 使用 NGINX v0.25 为外部 TLS 配置 Ingress
|
||||
|
||||
在 NGINX 0.25 中，NGINX 关于转发头和外部 TLS 终止的行为[已更改](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0220)。因此，如果你同时使用 NGINX 0.25 和外部 TLS 终止配置，你必须编辑 `cluster.yml` 来为 Ingress 启用 `use-forwarded-headers` 选项。
|
||||
|
||||
```yaml
|
||||
ingress:
|
||||
provider: nginx
|
||||
options:
|
||||
use-forwarded-headers: 'true'
|
||||
```
|
||||
|
||||
### 必须的 Header
|
||||
|
||||
- `Host`
|
||||
- `X-Forwarded-Proto`
|
||||
- `X-Forwarded-Port`
|
||||
- `X-Forwarded-For`
|
||||
|
||||
### 建议的超时时间
|
||||
|
||||
- 读超时：`1800 seconds`
|
||||
- 写超时：`1800 seconds`
|
||||
- 连接超时：`30 seconds`
|
||||
|
||||
### 健康检查
|
||||
|
||||
Rancher 将对 `/healthz` 端点的健康检查响应`200`。
|
||||
|
||||
### 示例 NGINX 配置
|
||||
|
||||
此 NGINX 配置已在 NGINX 1.14 上进行了测试。
|
||||
|
||||
:::caution
|
||||
|
||||
此 NGINX 配置只是一个示例，可能不适合你的环境。如需查阅完整文档，请参见 [NGINX 负载均衡 - HTTP 负载均衡](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/)。
|
||||
|
||||
:::
|
||||
|
||||
- 将 `IP_NODE1`，`IP_NODE2` 和 `IP_NODE3` 替换为你集群中节点的 IP 地址。
|
||||
- 将两处的 `FQDN` 均替换为 Rancher 的 DNS 名称。
|
||||
- 把 `/certs/fullchain.pem` 和 `/certs/privkey.pem` 分别替换为服务器证书和服务器证书密钥的位置。
|
||||
|
||||
```
|
||||
worker_processes 4;
|
||||
worker_rlimit_nofile 40000;
|
||||
|
||||
events {
|
||||
worker_connections 8192;
|
||||
}
|
||||
|
||||
http {
|
||||
upstream rancher {
|
||||
server IP_NODE_1:80;
|
||||
server IP_NODE_2:80;
|
||||
server IP_NODE_3:80;
|
||||
}
|
||||
|
||||
map $http_upgrade $connection_upgrade {
|
||||
default Upgrade;
|
||||
'' close;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 443 ssl http2;
|
||||
server_name FQDN;
|
||||
ssl_certificate /certs/fullchain.pem;
|
||||
ssl_certificate_key /certs/privkey.pem;
|
||||
|
||||
location / {
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
proxy_set_header X-Forwarded-Port $server_port;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_pass http://rancher;
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection $connection_upgrade;
|
||||
# 此项允许执行的 shell 窗口保持开启，最长可达15分钟。不使用此参数的话，默认1分钟后自动关闭。
|
||||
proxy_read_timeout 900s;
|
||||
proxy_buffering off;
|
||||
}
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
server_name FQDN;
|
||||
return 301 https://$server_name$request_uri;
|
||||
}
|
||||
}
|
||||
```
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: 安装参考
|
||||
---
|
||||
|
||||
有关其他安装资源，请参阅以下参考指南：[Rancher Helm Chart 选项](helm-chart-options.md)、[TLS 设置](tls-settings.md)和[功能开关](feature-flags.md)。
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: TLS 设置
|
||||
---
|
||||
|
||||
更改默认 TLS 设置的方法取决于它的安装方式。
|
||||
|
||||
## 在高可用 Kubernetes 集群中运行 Rancher
|
||||
|
||||
当你在 Kubernetes 集群内安装 Rancher 时，TLS 会在集群的 Ingress Controller 上卸载。可用的 TLS 设置取决于使用的 Ingress Controller：
|
||||
|
||||
* nginx-ingress-controller（RKE1 和 RKE2 默认）：[默认的 TLS 版本和密码](https://kubernetes.github.io/ingress-nginx/user-guide/tls/#default-tls-version-and-ciphers)。
|
||||
* traefik（K3s 默认）：[TLS 选项](https://doc.traefik.io/traefik/https/tls/#tls-options)。
|
||||
|
||||
## 在单个 Docker 容器中运行 Rancher
|
||||
|
||||
默认 TLS 配置仅支持 TLS 1.2 和安全的 TLS 密码套件。你可以通过设置以下环境变量来更改此配置：
|
||||
|
||||
| 参数 | 描述 | 默认 | 可用选项 |
|
||||
|-----|-----|-----|-----|
|
||||
| `CATTLE_TLS_MIN_VERSION` | 最小 TLS 版本 | `1.2` | `1.0`, `1.1`, `1.2`, `1.3` |
|
||||
| `CATTLE_TLS_CIPHERS` | 支持的 TLS 密码套件 | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`,<br/>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | 详情请参见 [Golang TLS 常量](https://golang.org/pkg/crypto/tls/#pkg-constants)。 |
|
||||
+47
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: Dockershim
|
||||
---
|
||||
|
||||
Dockershim 是 Kubelet 和 Docker Daemon 之间的 CRI 兼容层。Kubernetes 1.20 版本宣布了[移除树内 Dockershim](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。有关此移除的更多信息以及时间线，请参见 [Kubernetes Dockershim 弃用相关的常见问题](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed)。
|
||||
|
||||
RKE 集群现在支持外部 Dockershim，来让用户继续使用 Docker 作为 CRI 运行时。现在，我们通过使用 [Mirantis 和 Docker ](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/) 来确保 RKE 集群可以继续使用 Docker，从而实现上游开源社区的外部 Dockershim。
|
||||
|
||||
RKE2 和 K3s 集群使用嵌入的 containerd 作为容器运行时，因此不受影响。
|
||||
|
||||
要在 1.24 之前的 RKE 版本中启用外部 Dockershim，请配置以下选项：
|
||||
|
||||
```
|
||||
enable_cri_dockerd: true
|
||||
```
|
||||
|
||||
从 1.24 版本开始，以上默认为 true。
|
||||
|
||||
如果你想使用其他容器运行时，Rancher 也提供使用 Containerd 作为默认运行时的，以边缘为中心的 K3s，和以数据中心为中心的 RKE2 Kubernetes 发行版。然后，你就可以通过 Rancher 对导入的 RKE2 和 K3s Kubernetes 集群进行升级和管理。
|
||||
|
||||
### 常见问题
|
||||
|
||||
<br/>
|
||||
|
||||
Q：是否必须升级 Rancher 才能获得 Rancher 对上游外部 Dockershim 替换的支持？
|
||||
|
||||
A：对于 RKE，Dockershim `cri_dockerd` 替换的上游支持从 Kubernetes 1.21 开始。你需要使用支持 RKE 1.21 的 Rancher 版本。详情请参见我们的支持矩阵。
|
||||
|
||||
<br/>
|
||||
|
||||
Q：我目前的 RKE 使用 Kubernetes 1.23。如果上游最终在 1.24 中删除 Dockershim，会发生什么？
|
||||
|
||||
A：RKE 中带有 Kubernetes 的 Dockershim 版本将继续工作到 1.23。有关时间线的更多信息，请参见 [Kubernetes Dockershim 弃用相关的常见问题](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed)。从 1.24 开始，RKE 将默认启用 `cri_dockerd` 并在之后的版本中继续启用。
|
||||
|
||||
<br/>
|
||||
|
||||
Q: 如果我不想再依赖 Dockershim 或 cri_dockerd，我还有什么选择？
|
||||
|
||||
A: 你可以为 Kubernetes 使用不需要 Dockershim 支持的运行时，如 Containerd。RKE2 和 K3s 就是其中的两个选项。
|
||||
|
||||
<br/>
|
||||
|
||||
Q: 如果我目前使用 RKE1，但想切换到 RKE2，我可以怎样进行迁移？
|
||||
|
||||
A: 你可以构建一个新集群，然后将工作负载迁移到使用 Containerd 的新 RKE2 集群。Rancher 也在探索就地升级路径的可能性。
|
||||
|
||||
<br/>
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: 安装 Docker
|
||||
---
|
||||
|
||||
在使用 Helm 在 RKE 集群节点上或使用 Docker 安装 Rancher Server 前，你需要在节点中先安装 Docker。RKE2 和 K3s 集群不要求使用 Docker。
|
||||
|
||||
Docker 有几个安装方法。一种方法是参见 [Docker 官方文档](https://docs.docker.com/install/)以了解如何在 Linux 上安装 Docker。不同 Linux 发行版的安装步骤可能有所不同。
|
||||
|
||||
另一种方式是使用 Rancher 的 Docker 安装脚本，该脚本可用于较新的 Docker 版本。 Rancher 为每个 Kubernetes 支持的上游 Docker 版本提供了安装脚本。
|
||||
|
||||
例如，此命令可用于在 SUSE Linux Enterprise 或 Ubuntu 等主要 Linux 发行版上安装 Docker ：
|
||||
|
||||
```bash
|
||||
curl https://releases.rancher.com/install-docker/<version-number>.sh | sh
|
||||
```
|
||||
|
||||
请参阅 [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)。
|
||||
+343
@@ -0,0 +1,343 @@
|
||||
---
|
||||
title: 端口要求
|
||||
description: 了解 Rancher 正常运行所需的端口要求，包括 Rancher 节点和下游 Kubernetes 集群节点
|
||||
---
|
||||
|
||||
import PortsIaasNodes from '@site/src/components/PortsIaasNodes'
|
||||
import PortsCustomNodes from '@site/src/components/PortsCustomNodes'
|
||||
import PortsImportedHosted from '@site/src/components/PortsImportedHosted'
|
||||
|
||||
为了确保能正常运行，Rancher 需要在 Rancher 节点和下游 Kubernetes 集群节点上开放一些端口。
|
||||
|
||||
## Rancher 节点
|
||||
|
||||
下表列出了运行 Rancher Server 的节点之间需要开放的端口。
|
||||
|
||||
不同的 Rancher Server 架构有不同的端口要求。
|
||||
|
||||
Rancher 可以安装在任何 Kubernetes 集群上。如果你的 Rancher 安装在 K3s、RKE 或 RKE2 Kubernetes 集群上，请参考下面的标签页。对于其他 Kubernetes 发行版，请参见该发行版的文档，了解集群节点的端口要求。
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
- Rancher 节点可能要求额外出站访问已配置的外部验证提供程序（如 LDAP）。
|
||||
- Kubernetes 建议节点端口服务使用 TCP 30000-32767。
|
||||
- 对于防火墙，可能需要在集群和 Pod CIDR 内启用流量。
|
||||
- Rancher 节点可能还需要出站访问用于存储集群备份（如 Minio）的外部 S3 上的位置。
|
||||
|
||||
:::
|
||||
|
||||
### K3s 上 Rancher Server 节点的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
K3s server 需要开放端口 6443 才能供节点访问。
|
||||
|
||||
使用 Flannel VXLAN 时，节点需要能够通过 UDP 端口 8472 访问其他节点。节点不应监听任何其他端口。K3s 使用反向隧道，建立节点与 Server 的出站连接，所有 kubelet 流量都通过该隧道进行。但是，如果你不使用 Flannel，而是使用自定义的 CNI，K3s 则不需要打开 8472 端口。
|
||||
|
||||
如果要使用 Metrics Server，则需要在每个节点上打开端口 10250。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
节点上的 VXLAN 端口会开放集群网络，让任何人均能访问集群。因此，不要将 VXLAN 端口暴露给外界。请使用禁用 8472 端口的防火墙/安全组来运行节点。
|
||||
|
||||
:::
|
||||
|
||||
下表描述了入站和出站流量的端口要求：
|
||||
|
||||
<figcaption>Rancher Server 节点的入站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 源 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 80 | 执行外部 SSL 终止的负载均衡器/代理 | 使用外部 SSL 终止时的 Rancher UI/API |
|
||||
| TCP | 443 | <ul><li>Server 节点</li><li>Agent 节点</li><li>托管/注册的 Kubernetes</li><li>任何需要使用 Rancher UI 或 API 的源</li></ul> | Rancher Agent，Rancher UI/API，kubectl |
|
||||
| TCP | 6443 | K3s Server 节点 | Kubernetes API |
|
||||
| UDP | 8472 | K3s Server 和 Agent 节点 | 仅 Flannel VXLAN 需要 |
|
||||
| TCP | 10250 | K3s Server 和 Agent 节点 | kubelet |
|
||||
|
||||
<figcaption>Rancher 节点的出站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 目标 | 描述 |
|
||||
| -------- | ---- | -------------------------------------------------------- | --------------------------------------------- |
|
||||
| TCP | 22 | 使用 Node Driver 创建的节点的任何节点 IP | 使用 Node Driver SSH 配置节点 |
|
||||
| TCP | 443 | git.rancher.io | Rancher catalog |
|
||||
| TCP | 2376 | 使用 Node Driver 创建的节点的任何节点 IP | Docker Machine 使用的 Docker daemon TLS 端口 |
|
||||
| TCP | 6443 | 托管/导入的 Kubernetes API | Kubernetes API Server |
|
||||
|
||||
</details>
|
||||
|
||||
### RKE 上 Rancher Server 节点的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
通常情况下，Rancher 安装在三个 RKE 节点上，这些节点都有 etcd、controlplane 和 worker 角色。
|
||||
|
||||
|
||||
|
||||
下表描述了 Rancher 节点之间流量的端口要求：
|
||||
|
||||
<figcaption>Rancher 节点的流量规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 描述 |
|
||||
|-----|-----|----------------|
|
||||
| TCP | 443 | Rancher Agents |
|
||||
| TCP | 2379 | etcd 客户端请求 |
|
||||
| TCP | 2380 | etcd 对等通信 |
|
||||
| TCP | 6443 | Kubernetes apiserver |
|
||||
| TCP | 8443 | NGINX Ingress 的验证 Webhook |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN 覆盖网络 |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 10250 | Metrics Server 与所有节点的通信 |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
|
||||
下表描述了入站和出站流量的端口要求：
|
||||
|
||||
<figcaption>Rancher 节点的入站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 源 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 22 | RKE CLI | RKE 通过 SSH 配置节点 |
|
||||
| TCP | 80 | 负载均衡器/反向代理 | 到 Rancher UI/API 的 HTTP 流量 |
|
||||
| TCP | 443 | <ul><li>负载均衡器/反向代理</li><li>所有集群节点和其他 API/UI 客户端的 IP</li></ul> | 到 Rancher UI/API 的 HTTPS 流量 |
|
||||
| TCP | 6443 | Kubernetes API 客户端 | 到 Kubernetes API 的 HTTPS 流量 |
|
||||
|
||||
<figcaption>Rancher 节点的出站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 目标 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 443 | git.rancher.io | Rancher catalog |
|
||||
| TCP | 22 | 使用 Node Driver 创建的任何节点 | Node Driver 通过 SSH 配置节点 |
|
||||
| TCP | 2376 | 使用 Node Driver 创建的任何节点 | Node Driver 使用的 Docker daemon TLS 端口 |
|
||||
| TCP | 6443 | 托管/导入的 Kubernetes API | Kubernetes API Server |
|
||||
| TCP | 提供商依赖 | 托管集群中 Kubernetes API 端点的端口 | Kubernetes API |
|
||||
|
||||
</details>
|
||||
|
||||
### RKE2 上 Rancher Server 节点的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
RKE2 server 需要开放端口 6443 和 9345 才能供集群中的其他节点访问。
|
||||
|
||||
使用 Flannel VXLAN 时，所有节点都需要能够通过 UDP 端口 8472 访问其他节点。
|
||||
|
||||
如果要使用 Metrics Server，则需要在每个节点上打开端口 10250。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
节点上的 VXLAN 端口会开放集群网络，让任何人均能访问集群。因此，不要将 VXLAN 端口暴露给外界。请使用禁用 8472 端口的防火墙/安全组来运行节点。
|
||||
|
||||
:::
|
||||
|
||||
<figcaption>RKE2 Server 节点的入站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 源 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 9345 | RKE2 Server 和 Agent 节点 | 节点注册。需要在所有 Server 节点上将端口开放给集群中的所有其他节点。 |
|
||||
| TCP | 6443 | RKE2 Agent 节点 | Kubernetes API |
|
||||
| UDP | 8472 | RKE2 Server 和 Agent 节点 | 仅 Flannel VXLAN 需要 |
|
||||
| TCP | 10250 | RKE2 Server 和 Agent 节点 | kubelet |
|
||||
| TCP | 2379 | RKE2 Server 节点 | etcd 客户端端口 |
|
||||
| TCP | 2380 | RKE2 Server 节点 | etcd 对等端口 |
|
||||
| TCP | 30000-32767 | RKE2 Server 和 Agent 节点 | NodePort 端口范围。可以使用 TCP 或 UDP。 |
|
||||
| TCP | 5473 | Calico-node pod 连接到 typha pod | 使用 Calico 部署时需要 |
|
||||
| HTTP | 80 | 执行外部 SSL 终止的负载均衡器/代理 | 使用外部 SSL 终止时的 Rancher UI/API |
|
||||
| HTTPS | 443 | <ul><li>托管/注册的 Kubernetes</li><li>任何需要使用 Rancher UI 或 API 的源</li></ul> | Rancher Agent，Rancher UI/API，kubectl。如果负载均衡器执行 TLS 终止，则不需要。 |
|
||||
|
||||
所有出站流量通常都是允许的。
|
||||
</details>
|
||||
|
||||
### Docker 安装的 Rancher Server 的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了 Rancher 节点入站和出站流量的端口要求：
|
||||
|
||||
<figcaption>Rancher 节点的入站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 源 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 80 | 执行外部 SSL 终止的负载均衡器/代理 | 使用外部 SSL 终止时的 Rancher UI/API |
|
||||
| TCP | 443 | <ul><li>托管/注册的 Kubernetes</li><li>任何需要使用 Rancher UI 或 API 的源</li></ul> | Rancher Agent，Rancher UI/API，kubectl |
|
||||
|
||||
<figcaption>Rancher 节点的出站规则</figcaption>
|
||||
|
||||
| 协议 | 端口 | 源 | 描述 |
|
||||
|-----|-----|----------------|---|
|
||||
| TCP | 22 | 使用 Node Driver 创建的节点的任何节点 IP | 使用 Node Driver SSH 配置节点 |
|
||||
| TCP | 443 | git.rancher.io | Rancher catalog |
|
||||
| TCP | 2376 | 使用 Node Driver 创建的节点的任何节点 IP | Docker Machine 使用的 Docker daemon TLS 端口 |
|
||||
| TCP | 6443 | 托管/导入的 Kubernetes API | Kubernetes API Server |
|
||||
|
||||
</details>
|
||||
|
||||
## 下游 Kubernetes 集群节点
|
||||
|
||||
下游 Kubernetes 集群用于运行你的应用和服务。本节介绍了哪些端口需要在下游集群的节点上打开，以便 Rancher 能够与它们进行通信。
|
||||
|
||||
不同的下游集群的启动方式有不同的端口要求。下面的每个标签都列出了不同[集群类型](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/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>
|
||||
|
||||
|
||||
|
||||
:::tip
|
||||
|
||||
如果你对安全性的关注不是太高，而且也愿意多打开几个端口，你可以参考[常用端口](#常用端口)中列出的端口，而不是参考下方的表格。
|
||||
|
||||
:::
|
||||
|
||||
### Harvester 集群的端口
|
||||
|
||||
有关 Harvester 端口要求的更多信息，请参阅[此处](../../../integrations-in-rancher/harvester.md#端口要求)。
|
||||
|
||||
|
||||
### Rancher 使用节点池启动 Kubernetes 集群的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了节点在[云提供商](../../../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
|
||||
|
||||
在 AWS EC2 或 DigitalOcean 等云提供商中创建集群期间，Rancher 会自动打开所需的端口。
|
||||
|
||||
:::
|
||||
|
||||
<PortsIaasNodes/>
|
||||
|
||||
</details>
|
||||
|
||||
### Rancher 使用自定义节点启动 Kubernetes 集群的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了使用[自定义节点](../../../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/>
|
||||
|
||||
</details>
|
||||
|
||||
### 托管 Kubernetes 集群的端口
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了[托管集群](../../../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/>
|
||||
|
||||
</details>
|
||||
|
||||
### 已注册集群的端口
|
||||
|
||||
:::note
|
||||
|
||||
在 Rancher 2.5 之前，注册集群被称为导入集群。
|
||||
|
||||
:::
|
||||
|
||||
<details>
|
||||
<summary>单击展开</summary>
|
||||
|
||||
下表描述了[注册集群](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md)的端口要求。
|
||||
|
||||
<PortsImportedHosted/>
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
## 其他端口注意事项
|
||||
|
||||
### 常用端口
|
||||
|
||||
无论集群是什么类型，常用端口通常在你的 Kubernetes 节点上打开。
|
||||
|
||||
import CommonPortsTable from '../../../shared-files/_common-ports-table.md';
|
||||
|
||||
<CommonPortsTable />
|
||||
|
||||
----
|
||||
|
||||
### 本地节点流量
|
||||
|
||||
上述要求中标记为`本地流量`（例如 `9099 TCP`）的端口会用于 Kubernetes 健康检查 （`livenessProbe` 和 `readinessProbe`）。
|
||||
这些健康检查是在节点本身执行的。在大多数云环境中，这种本地流量是默认允许的。
|
||||
|
||||
但是，在以下情况下可能会阻止此流量：
|
||||
|
||||
- 你已在节点上应用了严格的主机防火墙策略。
|
||||
- 你正在使用有多个接口（多宿主）的节点。
|
||||
|
||||
在这些情况下，你必须在你的主机防火墙中主动允许这种流量，如果是公共/私有云托管的主机（例如 AWS 或 OpenStack），你需要在你的安全组配置中主动允许此流量。请记住，如果你在安全组中使用安全组作为源或目标，主动开放端口只适用于节点/实例的私有接口。
|
||||
|
||||
### Rancher AWS EC2 安全组
|
||||
|
||||
当你使用 [AWS EC2 Node Driver](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) 在 Rancher 中配置集群节点时，你可以让 Rancher 创建一个名为 `rancher-nodes` 的安全组。以下规则会自动添加到该安全组中。
|
||||
|
||||
| 类型 | 协议 | 端口范围 | 源/目标 | 规则类型 |
|
||||
|-----------------|:--------:|:-----------:|------------------------|:---------:|
|
||||
| SSH | TCP | 22 | 0.0.0.0/0 | 入站 |
|
||||
| HTTP | TCP | 80 | 0.0.0.0/0 | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 443 | 0.0.0.0/0 | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 2376 | 0.0.0.0/0 | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 2379-2380 | sg-xxx (rancher-nodes) | 入站 |
|
||||
| 自定义 UDP 规则 | UDP | 4789 | sg-xxx (rancher-nodes) | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 6443 | 0.0.0.0/0 | 入站 |
|
||||
| 自定义 UDP 规则 | UDP | 8472 | sg-xxx (rancher-nodes) | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 10250-10252 | sg-xxx (rancher-nodes) | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 10256 | sg-xxx (rancher-nodes) | 入站 |
|
||||
| 自定义 TCP 规则 | TCP | 30000-32767 | 0.0.0.0/0 | 入站 |
|
||||
| 自定义 UDP 规则 | UDP | 30000-32767 | 0.0.0.0/0 | 入站 |
|
||||
| 所有流量 | 全部 | 全部 | 0.0.0.0/0 | 出站 |
|
||||
|
||||
### 打开 SUSE Linux 端口
|
||||
|
||||
SUSE Linux 可能有一个防火墙，默认情况下会阻止所有端口。要打开将主机添加到自定义集群所需的端口：
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="SLES 15 / openSUSE Leap 15">
|
||||
|
||||
1. SSH 进入实例。
|
||||
1. 以文本模式启动 YaST：
|
||||
```
|
||||
sudo yast2
|
||||
```
|
||||
|
||||
1. 导航到**安全和用户** > **防火墙** > **区域：公共** > **端口**。要在界面内导航，请参照[说明](https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-yast-text.html#sec-yast-cli-navigate)。
|
||||
1. 要打开所需的端口，把它们输入到 **TCP 端口** 和 **UDP 端口** 字段。在这个例子中，端口 9796 和 10250 也被打开，用于监控。由此产生的字段应类似于以下内容：
|
||||
```yaml
|
||||
TCP Ports
|
||||
22, 80, 443, 2376, 2379, 2380, 6443, 9099, 9796, 10250, 10254, 30000-32767
|
||||
UDP Ports
|
||||
8472, 30000-32767
|
||||
```
|
||||
|
||||
1. 所有必须端口都输入后，选择**接受**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="SLES 12 / openSUSE Leap 42">
|
||||
|
||||
1. SSH 进入实例。
|
||||
1. 编辑 `/etc/sysconfig/SuSEfirewall2` 并打开所需的端口。在这个例子中，端口 9796 和 10250 也被打开，用于监控。
|
||||
```
|
||||
FW_SERVICES_EXT_TCP="22 80 443 2376 2379 2380 6443 9099 9796 10250 10254 30000:32767"
|
||||
FW_SERVICES_EXT_UDP="8472 30000:32767"
|
||||
FW_ROUTE=yes
|
||||
```
|
||||
1. 用新的端口重启防火墙：
|
||||
```
|
||||
SuSEfirewall2
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**结果** ：该节点已打开添加到自定义集群所需的端口。
|
||||
+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)
|
||||
+149
@@ -0,0 +1,149 @@
|
||||
---
|
||||
title: Docker 安装命令
|
||||
---
|
||||
|
||||
Docker 安装适用于想要测试 Rancher 的用户。
|
||||
|
||||
你可以使用 `docker run`命令，把 Rancher Server 组件安装到单个节点上，而不需要运行 Kubernetes 集群。由于只有一个节点和一个 Docker 容器，因此，如果该节点发生故障，由于其他节点上没有可用的 etcd 数据副本，你将丢失 Rancher Server 的所有数据。
|
||||
|
||||
你可以使用备份应用，按照[这些步骤](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)，将 Rancher Server 从 Docker 安装迁移到 Kubernetes 安装。
|
||||
|
||||
出于安全考虑，使用 Rancher 时请使用 SSL（Secure Sockets Layer）。SSL 保护所有 Rancher 网络通信（如登录和与集群交互）的安全。
|
||||
|
||||
| 环境变量键 | 环境变量值 | 描述 |
|
||||
| -------------------------------- | -------------------------------- | ---- |
|
||||
| `CATTLE_SYSTEM_DEFAULT_REGISTRY` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | 将 Rancher Server 配置成在配置集群时，始终从私有镜像仓库中拉取镜像。 |
|
||||
| `CATTLE_SYSTEM_CATALOG` | `bundled` | 配置 Rancher Server 使用打包的 Helm System Chart 副本。[system charts](https://github.com/rancher/system-charts) 仓库包含所有 Monitoring，Logging，告警和全局 DNS 等功能所需的应用商店项目。这些 [Helm Chart](https://github.com/rancher/system-charts) 位于 GitHub 中。但是由于你处在离线环境，因此使用 Rancher 内置的 Chart 会比设置 Git mirror 容易得多。 |
|
||||
|
||||
:::note 你是否需要：
|
||||
|
||||
- 配置自定义 CA 根证书以访问服务。参见[自定义 CA 根证书](../../resources/custom-ca-root-certificates.md)。
|
||||
- 记录所有 Rancher API 的事务。参见 [API 审计](../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-审计日志)。
|
||||
|
||||
:::
|
||||
|
||||
选择以下的选项之一：
|
||||
|
||||
### 选项 A：使用 Rancher 默认的自签名证书
|
||||
|
||||
<details id="option-a">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
如果你在不考虑身份验证的开发或测试环境中安装 Rancher，可以使用 Rancher 生成的自签名证书安装 Rancher。这种安装方式避免了自己生成证书的麻烦。
|
||||
|
||||
登录到你的 Linux 主机，然后运行下面的安装命令。输入命令时，参考下表来替换每个占位符。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 私有镜像仓库的 URL 和端口。 |
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要安装的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
特权访问是[必须](./install-rancher-ha.md#rancher-特权访问)的。
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
-e CATTLE_SYSTEM_CATALOG=bundled \ # 使用打包的 Rancher System Chart
|
||||
--privileged \
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 选项 B：使用你自己的证书 - 自签名
|
||||
|
||||
<details id="option-b">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
在你团队访问 Rancher Server 的开发或测试环境中，创建一个用于你的安装的自签名证书，以便团队验证他们对实例的连接。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
从能连接到互联网的计算机上，使用 [OpenSSL](https://www.openssl.org/) 或其他方法创建自签名证书。
|
||||
|
||||
- 证书文件的格式必须是 PEM。
|
||||
- 在你的证书文件中，包括链中的所有中间证书。你需要对你的证书进行排序，把你的证书放在最前面，后面跟着中间证书。如需查看示例，请参见[证书故障排除](../rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)。
|
||||
|
||||
:::
|
||||
|
||||
创建证书后，登录 Linux 主机，然后运行以下安装命令。输入命令时，参考下表来替换每个占位符。使用 `-v` 标志并提供证书的路径，以将证书挂载到容器中。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `<CERT_DIRECTORY>` | 包含证书文件的目录的路径。 |
|
||||
| `<FULL_CHAIN.pem>` | 完整证书链的路径。 |
|
||||
| `<PRIVATE_KEY.pem>` | 证书私钥的路径。 |
|
||||
| `<CA_CERTS.pem>` | CA 证书的路径。 |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 私有镜像仓库的 URL 和端口。 |
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要安装的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
特权访问是[必须](./install-rancher-ha.md#rancher-特权访问)的。
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
-v /<CERT_DIRECTORY>/<FULL_CHAIN.pem>:/etc/rancher/ssl/cert.pem \
|
||||
-v /<CERT_DIRECTORY>/<PRIVATE_KEY.pem>:/etc/rancher/ssl/key.pem \
|
||||
-v /<CERT_DIRECTORY>/<CA_CERTS.pem>:/etc/rancher/ssl/cacerts.pem \
|
||||
-e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
-e CATTLE_SYSTEM_CATALOG=bundled \ # 使用打包的 Rancher System Chart
|
||||
--privileged \
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 选项 C：使用你自己的证书 - 可信 CA 签名的证书
|
||||
|
||||
<details id="option-c">
|
||||
<summary>单击展开</summary>
|
||||
|
||||
在公开暴露应用的开发或测试环境中，请使用由可信 CA 签名的证书，以避免用户收到证书安全警告。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
证书文件的格式必须是 PEM。
|
||||
|
||||
:::
|
||||
|
||||
获取证书后，登录 Linux 主机，然后运行以下安装命令。输入命令时，参考下表来替换每个占位符。因为你的证书是由可信的 CA 签名的，因此你不需要安装额外的 CA 证书文件。
|
||||
|
||||
| 占位符 | 描述 |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `<CERT_DIRECTORY>` | 包含证书文件的目录的路径。 |
|
||||
| `<FULL_CHAIN.pem>` | 完整证书链的路径。 |
|
||||
| `<PRIVATE_KEY.pem>` | 证书私钥的路径。 |
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 私有镜像仓库的 URL 和端口。 |
|
||||
| `<RANCHER_VERSION_TAG>` | 你想要安装的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
|
||||
|
||||
:::note
|
||||
|
||||
使用 `--no-cacerts` 作为容器的参数，以禁用 Rancher 生成的默认 CA 证书。
|
||||
|
||||
:::
|
||||
|
||||
特权访问是[必须](./install-rancher-ha.md#rancher-特权访问)的。
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
--no-cacerts \
|
||||
-v /<CERT_DIRECTORY>/<FULL_CHAIN.pem>:/etc/rancher/ssl/cert.pem \
|
||||
-v /<CERT_DIRECTORY>/<PRIVATE_KEY.pem>:/etc/rancher/ssl/key.pem \
|
||||
-e CATTLE_SYSTEM_DEFAULT_REGISTRY=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的默认私有镜像仓库
|
||||
-e CATTLE_SYSTEM_CATALOG=bundled \ # 使用打包的 Rancher System Chart
|
||||
--privileged
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
|
||||
:::note
|
||||
|
||||
如果你不想发送遥测数据，在首次登录时退出[遥测](../../../../faq/telemetry.md)。
|
||||
|
||||
:::
|
||||
|
||||
+193
@@ -0,0 +1,193 @@
|
||||
---
|
||||
title: '1. 设置基础设施和私有镜像仓库'
|
||||
---
|
||||
|
||||
本文介绍如何在离线环境中，为 Rancher Management server 配置底层基础设施。你还将设置 Rancher 节点中必须可用的私有容器镜像仓库。
|
||||
|
||||
离线环境是 Rancher Server 离线安装或安装在防火墙后面的环境。
|
||||
|
||||
Rancher 安装在 K3s Kubernetes 集群、RKE Kubernetes 集群还是单个 Docker 容器上对应的基础设施设置会有所不同。如需了解各个安装方式的更多信息，请参见[本页](../../installation-and-upgrade.md)。
|
||||
|
||||
Rancher 可以安装在任何 Kubernetes 集群上。为了阅读方便，我们在下文中仍提供了 RKE 和 K3s Kubernetes 基础设施教程。
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="K3s">
|
||||
|
||||
为了实现高可用安装，我们建议设置以下的基础设施：
|
||||
|
||||
- **2 个 Linux 节点**：可以是你的云提供商中的虚拟机。
|
||||
- **1 个外部数据库**：用于存储集群数据。支持 PostgreSQL, MySQL 和 etcd。
|
||||
- **1 个负载均衡器**：用于将流量转发到这两个节点中。
|
||||
- **1 个 DNS 记录**：用于将 URL 映射到负载均衡器。此 DNS 记录将成为 Rancher Server 的 URL，下游集群需要可以访问到这个地址。
|
||||
- **私有镜像仓库**，用于将容器镜像分发到你的主机。
|
||||
|
||||
### 1. 配置 Linux 节点
|
||||
|
||||
这些主机会断开互联网链接，但需要能与你的私有镜像仓库连接。
|
||||
|
||||
请确保你的节点满足[操作系统，容器运行时，硬件和网络](../../installation-requirements/installation-requirements.md)的常规要求。
|
||||
|
||||
如需获取配置 Linux 节点的示例，请参见[在 Amazon EC2 中配置节点](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md)的教程。
|
||||
|
||||
### 2. 配置外部数据库
|
||||
|
||||
K3s 与其他 Kubernetes 发行版不同，在于其支持使用 etcd 以外的数据库来运行 Kubernetes。该功能让 Kubernetes 运维更加灵活。你可以根据实际情况选择合适的数据库。
|
||||
|
||||
对于 K3s 高可用安装，你需要配置以下的其中一个数据库：
|
||||
|
||||
* [PostgreSQL](https://www.postgresql.org/)（10.7 和 11.5 已验证）
|
||||
* [MySQL](https://www.mysql.com/)（5.7 已验证）
|
||||
* [etcd](https://etcd.io/)（3.3.15 已验证）
|
||||
|
||||
在安装 Kubernetes 时，你需要传入 K3s 连接数据库的详细信息。
|
||||
|
||||
如需获取配置数据库示例，请参见[在 Amazon RDS 服务中配置 MySQL 数据库](../../../../how-to-guides/new-user-guides/infrastructure-setup/mysql-database-in-amazon-rds.md)的教程。
|
||||
|
||||
如需获取配置 K3s 集群数据库的所有可用选项，请参见 [K3s 官方文档](https://rancher.com/docs/k3s/latest/en/installation/datastore/)。
|
||||
|
||||
### 3. 配置负载均衡器
|
||||
|
||||
你还需要设置一个负载均衡器，来将流量重定向到两个节点上的 Rancher 副本。配置后，当单个节点不可用时，继续保障与 Rancher Management Server 的通信。
|
||||
|
||||
在后续步骤中配置 Kubernetes 时，K3s 工具会部署一个 Traefik Ingress Controller。该 Controller 将侦听 worker 节点的 80 端口和 443 端口，以响应发送给特定主机名的流量。
|
||||
|
||||
在安装 Rancher 后（也是在后续步骤中），Rancher 系统将创建一个 Ingress 资源。该 Ingress 通知 Traefik Ingress Controller 监听发往 Rancher 主机名的流量。Traefik Ingress Controller 在收到发往 Rancher 主机名的流量时，会将其转发到集群中正在运行的 Rancher Server Pod。
|
||||
|
||||
在你的实现中，你可以考虑是否需要使用 4 层或 7 层的负载均衡器：
|
||||
|
||||
- **4 层负载均衡器**：两种选择中较为简单的一种，它将 TCP 流量转发到你的节点中。我们建议使用 4 层负载均衡器，将流量从 TCP/80 端口和 TCP/443 端口转发到 Rancher Management 集群节点上。集群上的 Ingress Controller 会将 HTTP 流量重定向到 HTTPS，并在 TCP/443 端口上终止 SSL/TLS。Ingress Controller 会将流量转发到 Rancher deployment 中 Ingress Pod 的 TCP/80 端口。
|
||||
- **7 层负载均衡器**：相对比较复杂，但功能更全面。例如，与 Rancher 本身进行 TLS 终止相反，7 层负载均衡器能够在负载均衡器处处理 TLS 终止。如果你需要集中在基础设施中进行 TLS 终止，7 层负载均衡可能会很适合你。7 层负载均衡还能让你的负载均衡器基于 HTTP 属性（例如 cookie 等）做出决策，而 4 层负载均衡器则不能。如果你选择在 7 层负载均衡器上终止 SSL/TLS 流量，则在安装 Rancher 时（后续步骤）需要使用 `--set tls=external` 选项。详情请参见 [Rancher Helm Chart 选项](../../installation-references/helm-chart-options.md#外部-tls-终止)。
|
||||
|
||||
如需获取配置 NGINX 负载均衡器的示例，请参见[本页](../../../../how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md)。
|
||||
|
||||
如需获取如何配置 Amazon ELB 网络负载均衡器的指南，请参见[本页](../../../../how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md)。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
安装后，请勿将此负载均衡（例如 `local` 集群 Ingress）用于 Rancher 以外的应用。如果此 Ingress 与其他应用共享，在其他应用的 Ingress 配置重新加载后，可能导致 Rancher 出现 websocket 错误。我们建议把 `local` 集群专用给 Rancher，不要在集群内部署其他应用。
|
||||
|
||||
:::
|
||||
|
||||
### 4. 配置 DNS 记录
|
||||
|
||||
配置完负载均衡器后，你将需要创建 DNS 记录，以将流量发送到该负载均衡器。
|
||||
|
||||
根据你的环境，DNS 记录可以是指向负载均衡器 IP 的 A 记录，也可以是指向负载均衡器主机名的 CNAME。无论是哪种情况，请确保该记录是你要 Rancher 进行响应的主机名。
|
||||
|
||||
在安装 Rancher 时（后续步骤），你需要指定此主机名。请知悉，此主机名无法修改。请确保你设置的主机名是你想要的。
|
||||
|
||||
有关设置 DNS 记录以将域流量转发到 Amazon ELB 负载均衡器的指南，请参见 [AWS 官方文档](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)。
|
||||
|
||||
### 5. 配置私有镜像仓库
|
||||
|
||||
Rancher 支持使用私有镜像仓库进行离线安装。你必须有自己的私有镜像仓库或使用其他方式将容器镜像分发到主机。
|
||||
|
||||
在后续设置 K3s Kubernetes 集群时，你需要创建一个[私有镜像仓库配置文件](https://rancher.com/docs/k3s/latest/en/installation/private-registry/)，其中包含此镜像仓库的信息。
|
||||
|
||||
如果你需要创建私有镜像仓库，请参阅相应运行时的文档：
|
||||
|
||||
* [Containerd](https://github.com/containerd/containerd/blob/main/docs/cri/config.md#registry-configuration).
|
||||
* [Nerdctl 命令和镜像仓库托管服务](https://github.com/containerd/nerdctl/blob/main/docs/registry.md)
|
||||
* [Docker](https://docs.docker.com/registry/deploying/).
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE">
|
||||
|
||||
如需在高可用 RKE 集群中安装 Rancher Management Server，我们建议配置以下基础设施：
|
||||
|
||||
- **3 个 Linux 节点**：可以是你的云提供商（例如 Amazon EC2，GCE 或 vSphere）中的虚拟机。
|
||||
- **1 个负载均衡器**：用于将前端流量转发到这三个节点中。
|
||||
- **1 个 DNS 记录**：用于将 URL 映射到负载均衡器。此 DNS 记录将成为 Rancher Server 的 URL，下游集群需要可以访问到这个地址。
|
||||
- **私有镜像仓库**，用于将容器镜像分发到你的主机。
|
||||
|
||||
这些节点必须位于同一个区域或数据中心。但是你可以把这些服务器放在不同的可用区。
|
||||
|
||||
### 为什么使用三个节点？
|
||||
|
||||
在 RKE 集群中，Rancher Server 的数据存储在 etcd 中。而这个 etcd 数据库在这三个节点上运行。
|
||||
|
||||
为了选举出大多数 etcd 节点认可的 etcd 集群 leader，etcd 数据库需要奇数个节点。如果 etcd 数据库无法选出 leader，etcd 可能会出现[脑裂（split brain）](https://www.quora.com/What-is-split-brain-in-distributed-systems)的问题，此时你需要使用备份恢复集群。如果三个 etcd 节点之一发生故障，其余两个节点可以选择一个 leader，因为它们是 etcd 节点总数的大多数部分。
|
||||
|
||||
### 1. 配置 Linux 节点
|
||||
|
||||
这些主机会断开互联网链接，但需要能与你的私有镜像仓库连接。
|
||||
|
||||
请确保你的节点满足[操作系统，容器运行时，硬件和网络](../../../../pages-for-subheaders/installation-requirements.md)的常规要求。
|
||||
|
||||
如需获取配置 Linux 节点的示例，请参见[在 Amazon EC2 中配置节点](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md)的教程。
|
||||
|
||||
### 2. 配置负载均衡器
|
||||
|
||||
你还需要设置一个负载均衡器，来将流量重定向到两个节点上的 Rancher 副本。配置后，当单个节点不可用时，继续保障与 Rancher Management Server 的通信。
|
||||
|
||||
在后续步骤中配置 Kubernetes 时，RKE 工具会部署一个 NGINX Ingress Controller。该 Controller 将侦听 worker 节点的 80 端口和 443 端口，以响应发送给特定主机名的流量。
|
||||
|
||||
在安装 Rancher 后（也是在后续步骤中），Rancher 系统将创建一个 Ingress 资源。该 Ingress 通知 NGINX Ingress Controller 监听发往 Rancher 主机名的流量。NGINX Ingress Controller 在收到发往 Rancher 主机名的流量时，会将其转发到集群中正在运行的 Rancher Server Pod。
|
||||
|
||||
在你的实现中，你可以考虑是否需要使用 4 层或 7 层的负载均衡器：
|
||||
|
||||
- **4 层负载均衡器**：两种选择中较为简单的一种，它将 TCP 流量转发到你的节点中。我们建议使用 4 层负载均衡器，将流量从 TCP/80 端口和 TCP/443 端口转发到 Rancher Management 集群节点上。集群上的 Ingress Controller 会将 HTTP 流量重定向到 HTTPS，并在 TCP/443 端口上终止 SSL/TLS。Ingress Controller 会将流量转发到 Rancher deployment 中 Ingress Pod 的 TCP/80 端口。
|
||||
- **7 层负载均衡器**：相对比较复杂，但功能更全面。例如，与 Rancher 本身进行 TLS 终止相反，7 层负载均衡器能够在负载均衡器处处理 TLS 终止。如果你需要集中在基础设施中进行 TLS 终止，7 层负载均衡可能会很适合你。7 层负载均衡还能让你的负载均衡器基于 HTTP 属性（例如 cookie 等）做出决策，而 4 层负载均衡器则不能。如果你选择在 7 层负载均衡器上终止 SSL/TLS 流量，则在安装 Rancher 时（后续步骤）需要使用 `--set tls=external` 选项。详情请参见 [Rancher Helm Chart 选项](../../installation-references/helm-chart-options.md#外部-tls-终止)。
|
||||
|
||||
如需获取配置 NGINX 负载均衡器的示例，请参见[本页](../../../../how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md)。
|
||||
|
||||
如需获取如何配置 Amazon ELB 网络负载均衡器的指南，请参见[本页](../../../../how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md)。
|
||||
|
||||
:::caution
|
||||
|
||||
安装后，请勿将此负载均衡（例如 `local` 集群 Ingress）用于 Rancher 以外的应用。如果此 Ingress 与其他应用共享，在其他应用的 Ingress 配置重新加载后，可能导致 Rancher 出现 websocket 错误。我们建议把 `local` 集群专用给 Rancher，不要在集群内部署其他应用。
|
||||
|
||||
:::
|
||||
|
||||
### 3. 配置 DNS 记录
|
||||
|
||||
配置完负载均衡器后，你将需要创建 DNS 记录，以将流量发送到该负载均衡器。
|
||||
|
||||
根据你的环境，DNS 记录可以是指向负载均衡器 IP 的 A 记录，也可以是指向负载均衡器主机名的 CNAME。无论是哪种情况，请确保该记录是你要 Rancher 进行响应的主机名。
|
||||
|
||||
在安装 Rancher 时（后续步骤），你需要指定此主机名。请知悉，此主机名无法修改。请确保你设置的主机名是你想要的。
|
||||
|
||||
有关设置 DNS 记录以将域流量转发到 Amazon ELB 负载均衡器的指南，请参见 [AWS 官方文档](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)。
|
||||
|
||||
### 4. 配置私有镜像仓库
|
||||
|
||||
Rancher 支持使用安全的私有镜像仓库进行离线安装。你必须有自己的私有镜像仓库或使用其他方式将容器镜像分发到主机。
|
||||
|
||||
在后续设置 RKE Kubernetes 集群时，你需要创建一个[私有镜像仓库配置文件](https://rancher.com/docs/rke/latest/en/config-options/private-registries/)，其中包含此镜像仓库的信息。
|
||||
|
||||
如果你需要创建私有镜像仓库，请参阅相应运行时的文档：
|
||||
|
||||
* [Containerd](https://github.com/containerd/containerd/blob/main/docs/cri/config.md#registry-configuration).
|
||||
* [Nerdctl 命令和镜像仓库托管服务](https://github.com/containerd/nerdctl/blob/main/docs/registry.md)
|
||||
* [Docker](https://docs.docker.com/registry/deploying/).
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Docker">
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
- Docker 安装适用于想要测试 Rancher 的用户。由于只有一个节点和一个 Docker 容器，因此如果该节点发生故障，你将丢失 Rancher Server 的所有数据。
|
||||
|
||||
- Rancher backup operator 可将 Rancher 从单个 Docker 容器迁移到高可用 Kubernetes 集群上。详情请参见[把 Rancher 迁移到新集群](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
|
||||
|
||||
:::
|
||||
|
||||
### 1. 配置 Linux 节点
|
||||
|
||||
此主机会断开互联网链接，但需要能与你的私有镜像仓库连接。
|
||||
|
||||
请确保你的节点满足[操作系统，容器，硬件和网络](../../../../pages-for-subheaders/installation-requirements.md)的常规安装要求。
|
||||
|
||||
如需获取配置 Linux 节点的示例，请参见[在 Amazon EC2 中配置节点](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md)的教程。
|
||||
|
||||
### 2. 配置私有 Docker 镜像仓库
|
||||
|
||||
Rancher 支持使用私有镜像仓库在堡垒服务器中进行离线安装。你必须有自己的私有镜像仓库或使用其他方式将容器镜像分发到主机。
|
||||
|
||||
如需获得创建私有镜像仓库的帮助，请参见 [Docker 官方文档](https://docs.docker.com/registry/)。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 后续操作
|
||||
[收集镜像并发布到你的私有镜像仓库](publish-images.md)
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user