fix conflicts

This commit is contained in:
Pietro Dell'Amore
2023-10-09 11:32:21 -03:00
1954 changed files with 294548 additions and 42168 deletions
@@ -1,6 +0,0 @@
---
title: Backup and Restore for Rancher Installed with Docker
---
- [Backups](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md)
- [Restores](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md)
@@ -45,6 +45,27 @@ If the requested resources exceed the remaining capacity in the project for thos
However, this is not the case with namespaces created **_outside_** of Rancher's UI. For namespaces created via `kubectl`, Rancher
will assign a resource quota that has a **zero** amount for any resource that requested more capacity than what remains in the project.
To create a project with a resource quota via `kubectl`, use the `spec.resourceQuota` and `spec.namespaceDefaultResourceQuota` fields:
```
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
```
Use `metadata.generateName` to ensure a unique project ID. Set `metadata.namespace` and `spec.clusterName` to the ID for the cluster the project belongs to.
To create a namespace in an existing project via `kubectl`, use the `field.cattle.io/projectId` annotation. To override the default
requested quota limit, use the `field.cattle.io/resourceQuota` annotation.
@@ -109,20 +109,23 @@ This reference contains variables that you can use in `questions.yml` nested und
| label | string | true | Define the UI label. |
| description | string | false | Specify the description of the variable.|
| type | string | false | Default to `string` if not specified (current supported types are string, multiline, boolean, int, enum, password, storageclass, hostname, pvc, and secret).|
| required | bool | false | Define if the variable is required or not (true \| false)|
| default | string | false | Specify the default value. Only used if there is no corresponding value in the `values.yml` file. |
| group | string | false | Group questions by input value. |
| min_length | int | false | Min character length.|
| max_length | int | false | Max character length.|
| min | int | false | Min integer length. |
| max | int | false | Max integer length. |
| options | []string | false | Specify the options when the variable type is `enum`, for example: options:<br/> - "ClusterIP" <br/> - "NodePort" <br/> - "LoadBalancer"|
| valid_chars | string | false | Regular expression for input chars validation. |
| invalid_chars | string | false | Regular expression for invalid input chars validation.|
| subquestions | []subquestion | false| Add an array of subquestions.|
| show_if | string | false | Show current variable if conditional variable is true. For example `show_if: "serviceType=Nodeport"` |
| show\_subquestion_if | string | false | Show subquestions if is true or equal to one of the options. for example `show_subquestion_if: "true"`|
<!-- The following values are not yet supported and are pending a merge of https://github.com/rancher/dashboard/issues/5754
| min_length | int | false | Min character length.|
| max_length | int | false | Max character length.|
| min | int | false | Min integer value. |
| max | int | false | Max integer value. |
| valid_chars | string | false | Regular expression for input chars validation. |
| invalid_chars | string | false | Regular expression for invalid input chars validation.|
| required | bool | false | Define if the variable is required or not (true \| false)|
-->
:::note
`subquestions[]` cannot contain `subquestions` or `show_subquestions_if` keys, but all other keys in the above table are supported.
@@ -8,7 +8,6 @@ title: Creating an AKS Cluster
You can use Rancher to create a cluster hosted in Microsoft Azure Kubernetes Service (AKS).
## Prerequisites in Microsoft Azure
:::caution
@@ -65,6 +64,14 @@ az ad sp create-for-rbac \
--role Contributor
```
### Setting Up the Service Principal with the Azure Command Line Tool
Create the Resource Group by running this command:
```
az group create --location AZURE_LOCATION_NAME --resource-group AZURE_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.
@@ -124,6 +131,17 @@ When provisioning an AKS cluster in the Rancher UI, RBAC is not configurable bec
RBAC is required for AKS clusters that are registered or imported into Rancher.
### Setting Up the Role Assignment to Service Principal with the Azure Command Line Tool
Assign the Rancher AKSv2 role to the service principal with the Azure Command Line Tool:
```
az role assignment create \
--assignee CLIENT_ID \
--scope "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME" \
--role "Rancher AKSv2"
```
## AKS Cluster Configuration Reference
For more information about how to configure AKS clusters from the Rancher UI, see the [configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md)
@@ -146,12 +164,114 @@ Please be aware that when registering an existing AKS cluster, the cluster might
For more information about connecting to an AKS private cluster, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/private-clusters#options-for-connecting-to-the-private-cluster)
## Setting Up the Minimum Permission Role with the Azure Command Line Tool
1. Create the Minimum Rancher AKSv2 Permission Role by running this command:
```
cat >> rancher-azure.json << EOF
{
"Name": "Rancher AKSv2",
"IsCustom": true,
"Description": "Everything needed by Rancher AKSv2 operator",
"Actions": [
"Microsoft.Compute/disks/delete",
"Microsoft.Compute/disks/read",
"Microsoft.Compute/disks/write",
"Microsoft.Compute/diskEncryptionSets/read",
"Microsoft.Compute/locations/DiskOperations/read",
"Microsoft.Compute/locations/vmSizes/read",
"Microsoft.Compute/locations/operations/read",
"Microsoft.Compute/proximityPlacementGroups/write",
"Microsoft.Compute/snapshots/delete",
"Microsoft.Compute/snapshots/read",
"Microsoft.Compute/snapshots/write",
"Microsoft.Compute/virtualMachineScaleSets/manualUpgrade/action",
"Microsoft.Compute/virtualMachineScaleSets/delete",
"Microsoft.Compute/virtualMachineScaleSets/read",
"Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/read",
"Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/ipconfigurations/publicipaddresses/read",
"Microsoft.Compute/virtualMachineScaleSets/virtualmachines/instanceView/read",
"Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read",
"Microsoft.Compute/virtualMachineScaleSets/virtualMachines/write",
"Microsoft.Compute/virtualMachineScaleSets/write",
"Microsoft.Compute/virtualMachines/read",
"Microsoft.Compute/virtualMachines/write",
"Microsoft.ContainerService/managedClusters/read",
"Microsoft.ContainerService/managedClusters/write"
"Microsoft.ContainerService/managedClusters/delete",
"Microsoft.ContainerService/managedClusters/accessProfiles/listCredential/action",
"Microsoft.ContainerService/managedClusters/agentPools/read",
"Microsoft.ContainerService/managedClusters/agentPools/write",
"Microsoft.ManagedIdentity/userAssignedIdentities/assign/action",
"Microsoft.Network/applicationGateways/read",
"Microsoft.Network/applicationGateways/write",
"Microsoft.Network/loadBalancers/write",
"Microsoft.Network/loadBalancers/backendAddressPools/join/action",
"Microsoft.Network/loadBalancers/delete",
"Microsoft.Network/loadBalancers/read",
"Microsoft.Network/networkInterfaces/join/action",
"Microsoft.Network/networkInterfaces/read",
"Microsoft.Network/networkInterfaces/write",
"Microsoft.Network/networkSecurityGroups/read",
"Microsoft.Network/networkSecurityGroups/write",
"Microsoft.Network/publicIPAddresses/delete",
"Microsoft.Network/publicIPAddresses/join/action",
"Microsoft.Network/publicIPAddresses/read",
"Microsoft.Network/publicIPAddresses/write",
"Microsoft.Network/publicIPPrefixes/join/action",
"Microsoft.Network/privatednszones/*",
"Microsoft.Network/routeTables/read",
"Microsoft.Network/routeTables/routes/delete",
"Microsoft.Network/routeTables/routes/read",
"Microsoft.Network/routeTables/routes/write",
"Microsoft.Network/routeTables/write",
"Microsoft.Network/virtualNetworks/read",
"Microsoft.Network/virtualNetworks/subnets/join/action",
"Microsoft.Network/virtualNetworks/subnets/read",
"Microsoft.Network/virtualNetworks/joinLoadBalancer/action",
"Microsoft.OperationalInsights/workspaces/sharedkeys/read",
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationsManagement/solutions/write",
"Microsoft.OperationsManagement/solutions/read",
"Microsoft.Resources/subscriptions/resourcegroups/read",
"Microsoft.Resources/subscriptions/resourcegroups/write",
"Microsoft.Storage/operations/read",
"Microsoft.Storage/storageAccounts/listKeys/action",
"Microsoft.Storage/storageAccounts/delete",
"Microsoft.Storage/storageAccounts/read",
"Microsoft.Storage/storageAccounts/write"
],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/subscriptions/SUBSCRIPTION_ID"
]
}
EOF
```
2. Apply the Rancher AKSv2 Role:
```
az role definition create --role-definition rancher-azure.json
```
3. Verify if the Rancher AKSv2 Role was created:
```
az role definition list | grep "Rancher AKSv2"
```
## Syncing
The AKS provisioner can synchronize the state of an AKS cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md)
For information on configuring the refresh interval, see [this section.](../../../../pages-for-subheaders/gke-cluster-configuration.md#configuring-the-refresh-interval)
## Programmatically Creating AKS Clusters
The most common way to programmatically deploy AKS clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
The most common way to programmatically deploy AKS clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster).
@@ -27,25 +27,25 @@ Each self-assessment guide is accompanied by a hardening guide. These guides wer
| Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|--------------------|-----------------------|-----------------------|------------------|
| Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](rke1-hardening-guide.md) |
| Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](rke1-hardening-guide.md) |
| Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25.md) | [Link](rke1-hardening-guide.md) |
| Kubernetes v1.24 | CIS v1.24 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [Link](rke1-hardening-guide.md) |
| Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [Link](rke1-hardening-guide.md) |
### RKE2 Guides
| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|------|--------------------|-----------------------|-----------------------|------------------|
| Rancher provisioned RKE2 | Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](rke2-hardening-guide.md) |
| Rancher provisioned RKE2 | Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](rke2-hardening-guide.md) |
| Rancher provisioned RKE2 | Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.7-k8s-v1.25.md) | [Link](rke2-hardening-guide.md) |
| Standalone RKE2 | Kubernetes v1.25 | CIS v1.23 | [Link](https://docs.rke2.io/security/cis_self_assessment123) | [Link](https://docs.rke2.io/security/hardening_guide) |
| Rancher provisioned RKE2 | Kubernetes v1.24 | CIS v1.24 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [Link](rke2-hardening-guide.md) |
| Rancher provisioned RKE2 | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [Link](rke2-hardening-guide.md) |
| Standalone RKE2 | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [Link](https://docs.rke2.io/security/cis_self_assessment123) | [Link](https://docs.rke2.io/security/hardening_guide) |
### K3s Guides
| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|------|--------------------|-----------------------|-----------------------|------------------|
| Rancher provisioned K3s cluster | Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](k3s-hardening-guide.md) |
| Rancher provisioned K3s cluster | Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](k3s-hardening-guide.md) |
| Rancher provisioned K3s cluster | Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.7-k8s-v1.25.md) | [Link](k3s-hardening-guide.md) |
| Rancher provisioned K3s cluster | Kubernetes v1.24 | CIS v1.24 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [Link](k3s-hardening-guide.md) |
| Rancher provisioned K3s cluster | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [Link](k3s-hardening-guide.md) |
| Standalone K3s | Kubernetes v1.22 up to v1.24 | CIS v1.23 | [Link](https://docs.k3s.io/security/self-assessment) | [Link](https://docs.k3s.io/security/hardening-guide) |
## Rancher with SELinux
@@ -88,6 +88,10 @@ Rancher is committed to informing the community of security issues in our produc
For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](../reference-guides/rancher-security/kubernetes-security-best-practices.md) guide.
### Rancher Webhook Hardening
The Rancher webhook deploys on both the upstream Rancher cluster and all provisioned clusters. For recommendations on hardening the Rancher webhook, see the [Hardening the Rancher Webhook](../reference-guides/rancher-security/rancher-webhook-hardening.md) guide.
### Rancher Security Best Practices
For recommendations on securing your Rancher, refer to the [Rancher Security Best Practices](../reference-guides/rancher-security/rancher-security-best-practices.md) guide.
For recommendations on securing your Rancher Manager deployments, refer to the [Rancher Security Best Practices](../reference-guides/rancher-security/rancher-security-best-practices.md) guide.
@@ -3,7 +3,7 @@ title: API Tokens
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/about-the-api/api-tokens"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/about-the-api/api-tokens"/>
</head>
By default, some cluster-level API tokens are generated with infinite time-to-live (`ttl=0`). In other words, API tokens with `ttl=0` never expire unless you invalidate them. Tokens are not invalidated by changing a password.
@@ -3,7 +3,7 @@ title: Backup Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/backup-configuration"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/backup-restore-configuration/backup-configuration"/>
</head>
The **Backup: Create** page lets you configure a schedule, enable encryption and specify the storage location for your backups.
@@ -3,7 +3,7 @@ title: Examples
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/examples"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/backup-restore-configuration/examples"/>
</head>
This section contains examples of Backup and Restore custom resources.
@@ -3,7 +3,7 @@ title: Restore Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/restore-configuration"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/backup-restore-configuration/restore-configuration"/>
</head>
The Restore Create page lets you provide details of the backup to restore from
@@ -3,7 +3,7 @@ title: Backup Storage Location Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/storage-configuration"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/backup-restore-configuration/storage-configuration"/>
</head>
Configure a storage location where all backups are saved by default. You will have the option to override this with each backup, but will be limited to using an S3-compatible object store.
@@ -3,7 +3,7 @@ title: Logging Best Practices
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/logging-best-practices"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-managed-clusters/logging-best-practices"/>
</head>
In this guide, we recommend best practices for cluster-level logging and application logging.
@@ -3,7 +3,7 @@ title: Monitoring Best Practices
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices"/>
</head>
Configuring sensible monitoring and alerting rules is vital for running any production workloads securely and reliably. This is not different when using Kubernetes and Rancher. Fortunately the integrated monitoring and alerting functionality makes this whole process a lot easier.
@@ -3,7 +3,7 @@ title: Best Practices for Rancher Managed vSphere Clusters
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/rancher-managed-clusters-in-vsphere"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-managed-clusters/rancher-managed-clusters-in-vsphere"/>
</head>
This guide outlines a reference architecture for provisioning downstream Rancher clusters in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
@@ -3,7 +3,7 @@ title: Tips for Setting Up Containers
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers"/>
</head>
Running well-built containers can greatly impact the overall performance and security of your environment.
@@ -3,7 +3,7 @@ title: Installing Rancher in a vSphere Environment
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere"/>
</head>
This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
@@ -3,7 +3,7 @@ title: Rancher Deployment Strategy
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/rancher-deployment-strategy"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/rancher-deployment-strategy"/>
</head>
There are two recommended deployment strategies for a Rancher instance that manages downstream Kubernetes clusters. Each one has its own pros and cons. Read more about which one would fit best for your use case.
@@ -3,7 +3,7 @@ title: Tips for Running Rancher
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/tips-for-running-rancher"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/tips-for-running-rancher"/>
</head>
This guide is geared toward use cases where Rancher is used to manage downstream Kubernetes clusters. The high-availability setup is intended to prevent losing access to downstream clusters if the Rancher server is not available.
@@ -3,7 +3,7 @@ title: Tips for Scaling Rancher
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/tips-for-scaling-rancher"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/tips-for-scaling-rancher"/>
</head>
This guide aims to introduce the approaches that should be considered to scale Rancher setups, and associated challenges with doing so. As systems grow performance will naturally reduce, but there are steps we can take to minimize the load put on Rancher, as well as optimize Rancher's ability to handle these larger setups.
@@ -3,7 +3,7 @@ title: kubectl Utility
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cli-with-rancher/kubectl-utility"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cli-with-rancher/kubectl-utility"/>
</head>
## kubectl
@@ -4,7 +4,7 @@ description: Interact with Rancher using command line interface (CLI) tools from
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cli-with-rancher/rancher-cli"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cli-with-rancher/rancher-cli"/>
</head>
The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.
@@ -3,7 +3,7 @@ title: EC2 Machine Configuration Reference
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/amazon-ec2"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/amazon-ec2"/>
</head>
For more details about EC2 nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
@@ -3,7 +3,7 @@ title: Azure Machine Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/azure"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/azure"/>
</head>
For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)
@@ -3,7 +3,7 @@ title: DigitalOcean Machine Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/digitalocean"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/digitalocean"/>
</head>
For more details about DigitalOcean, Droplets, refer to the [official documentation](https://docs.digitalocean.com/products/compute/).
@@ -3,7 +3,7 @@ title: EC2 Node Template Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/amazon-ec2"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/amazon-ec2"/>
</head>
For more details about EC2, nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
@@ -3,7 +3,7 @@ title: Azure Node Template Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/azure"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/azure"/>
</head>
For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)
@@ -3,7 +3,7 @@ title: DigitalOcean Node Template Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/digitalocean"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/digitalocean"/>
</head>
Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
@@ -3,7 +3,7 @@ title: Nutanix Node Template Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix"/>
</head>
## Account Access
@@ -3,7 +3,7 @@ title: VSphere Node Template Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere"/>
</head>
## Account Access
@@ -3,7 +3,7 @@ title: AKS Cluster Configuration Reference
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration"/>
</head>
## Changes in Rancher v2.6
@@ -3,7 +3,7 @@ title: EKS Cluster Configuration Reference
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/eks-cluster-configuration" />
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/eks-cluster-configuration"/>
</head>
### Account Access
@@ -3,7 +3,7 @@ title: Private Clusters
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-private-clusters"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-private-clusters"/>
</head>
In GKE, [private clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/private-cluster-concept) are clusters whose nodes are isolated from inbound and outbound traffic by assigning them internal IP addresses only. Private clusters in GKE have the option of exposing the control plane endpoint as a publicly accessible address or as a private address. This is different from other Kubernetes providers, which may refer to clusters with private control plane endpoints as "private clusters" but still allow traffic to and from nodes. You may want to create a cluster with private nodes, with or without a public control plane endpoint, depending on your organization's networking and security requirements. A GKE cluster provisioned from Rancher can use isolated nodes by selecting "Private Cluster" in the Cluster Options (under "Show advanced options"). The control plane endpoint can optionally be made private by selecting "Enable Private Endpoint".
@@ -127,7 +127,7 @@ ACE is available on RKE, RKE2, and K3s clusters that are provisioned or register
:::
ACE must be set up [manually](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters.md) on RKE2 and K3s clusters. In RKE, ACE is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self-signed certificates.
ACE must be set up [manually](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters) on RKE2 and K3s clusters. In RKE, ACE is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self-signed certificates.
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint)
@@ -3,7 +3,7 @@ title: Syncing
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters"/>
</head>
Syncing allows Rancher to update cluster values so that they're up to date with the corresponding cluster object hosted in AKS, EKS or GKE. This enables sources other than Rancher to own a hosted cluster’s state.
@@ -3,7 +3,7 @@ title: Rancher Agent Options
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options"/>
</head>
Rancher deploys an agent on each node to communicate with the node. This pages describes the options that can be passed to the agent. To use these options, you will need to [create a cluster with custom nodes](../../../../pages-for-subheaders/use-existing-nodes.md) and add the options to the generated `docker run` command when adding a node.
@@ -3,7 +3,7 @@ title: Examples
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/monitoring-v2-configuration/examples"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/examples"/>
</head>
### ServiceMonitor
@@ -3,7 +3,7 @@ title: Helm Chart Options
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/monitoring-v2-configuration/helm-chart-options"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/helm-chart-options"/>
</head>
## Configuring Resource Limits and Requests
@@ -3,7 +3,7 @@ title: Receiver Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/monitoring-v2-configuration/receivers"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/receivers"/>
</head>
The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configuration/#configuration-file) Secret contains the configuration of an Alertmanager instance that sends out notifications based on alerts it receives from Prometheus.
@@ -3,7 +3,7 @@ title: Route Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/monitoring-v2-configuration/routes"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/routes"/>
</head>
The route configuration is the section of the Alertmanager custom resource that controls how the alerts fired by Prometheus are grouped and filtered before they reach the receiver.
@@ -3,7 +3,7 @@ title: ServiceMonitor and PodMonitor Configuration
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/monitoring-v2-configuration/servicemonitors-and-podmonitors"/>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/servicemonitors-and-podmonitors"/>
</head>
ServiceMonitors and PodMonitors are both pseudo-CRDs that map the scrape configuration of the Prometheus custom resource.
@@ -2,6 +2,10 @@
title: Role-Based Access Control
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/prometheus-federator/rbac"/>
</head>
This section describes the expectations for Role-Based Access Control (RBAC) for Prometheus Federator.
As described in the section on [namespaces](../../pages-for-subheaders/prometheus-federator.md#namespaces), Prometheus Federator expects that Project Owners, Project Members, and other users in the cluster with Project-level permissions (e.g. permissions in a certain set of namespaces identified by a single label selector) have minimal permissions in any namespaces except the Project Registration Namespace (which is imported into the project by default) and those that already comprise their projects. Therefore, in order to allow Project Owners to assign specific chart permissions to other users in their Project namespaces, the Helm Project Operator will automatically watch the following bindings:
@@ -2,6 +2,10 @@
title: Architecture Recommendations
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-manager-architecture/architecture-recommendations"/>
</head>
If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters)
## Separation of Rancher and User Clusters
@@ -2,6 +2,10 @@
title: Communicating with Downstream User Clusters
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters"/>
</head>
This section describes how Rancher provisions and manages the downstream user clusters that run your apps and services.
The below diagram shows how the cluster controllers, cluster agents, and node agents allow Rancher to control downstream clusters.
@@ -2,6 +2,10 @@
title: Rancher Server and Components
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-manager-architecture/rancher-server-and-components"/>
</head>
The majority of Rancher 2.x software runs on the Rancher Server. Rancher Server includes all the software components used to manage the entire Rancher deployment.
The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two downstream Kubernetes clusters: one created by RKE and another created by Amazon EKS (Elastic Kubernetes Service).
@@ -0,0 +1,133 @@
---
title: Hardening the Rancher Webhook
---
Rancher Webhook is an important component within Rancher, playing a role in enforcing security requirements for Rancher and its workloads. To decrease its attack surface, access to it should be limited to the only valid caller it has: the Kubernetes API server. This can be done by using network policies and authentication independently or in conjunction with each other to harden the webhook against attacks.
## Block External Traffic Using Network Policies
The webhook is only expected to accept requests from the Kubernetes API server. By default, however, the webhook can accept traffic from any source. If you are using a CNI that supports Network Policies, you can create a policy that blocks traffic that doesn't originate from the API server.
The built-in NetworkPolicy resource in Kubernetes can't block or admit traffic from the cluster hosts, and the `kube-apiserver` process is always running on the host network. Therefore, you must use the advanced network policy resources from the CNI in use. Examples for Calico and Cilium follow. Consult the documentation for your CNI for more details.
### Calico
Use the NetworkPolicy resource in the `crd.projectcalico.org/v1` API group. Use the selector `app == 'rancher-webhook'` to create a rule for the webhook, and set the CIDR of the control plane hosts as the ingress source:
```yaml
apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
name: allow-k8s
namespace: cattle-system
spec:
selector: app == 'rancher-webhook'
types:
- Ingress
ingress:
- action: Allow
protocol: TCP
source:
nets:
- 192.168.42.0/24 # CIDR of the control plane host. May list more than 1 if the hosts are in different subnets.
destination:
selector:
app == 'rancher-webhook'
```
### Cilium
Use the CiliumNetworkPolicy resource in the `cilium.io/v2` API group. Add the `host` and `remote-node` keys to the `fromEntities` ingress rule. This blocks in-cluster and external traffic while allowing traffic from the hosts.
```yaml
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: allow-k8s
namespace: cattle-system
spec:
endpointSelector:
matchLabels:
app: rancher-webhook
ingress:
- fromEntities:
- host
- remote-node
```
## Require the Kubernetes API Server to Authenticate to the Webhook
The webhook should only accept requests from the Kubernetes API server. By default, the webhook doesn't require clients to authenticate to it. It will accept any request. You can configure the webhook to require credentials so that only the API server can access it. More information can be found in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#authenticate-apiservers).
1. Configure the API server to present a client certificate to the webhook, pointing to an AdmissionConfiguration file to configure the ValidatingAdmissionWebhook and MutatingAdmissionWebhook plugins:
```yaml
# /etc/rancher/admission/admission.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionWebhook
configuration:
apiVersion: apiserver.config.k8s.io/v1
kind: WebhookAdmissionConfiguration
kubeConfigFile: "/etc/rancher/admission/kubeconfig"
- name: MutatingAdmissionWebhook
configuration:
apiVersion: apiserver.config.k8s.io/v1
kind: WebhookAdmissionConfiguration
kubeConfigFile: "/etc/rancher/admission/kubeconfig"
```
This is also the same config file where other admission plugins are configured, such as PodSecurity. If your distro or your setup uses additional admission plugins, configure those as well. For example, add [RKE2's PodSecurity configuration](https://docs.rke2.io/security/pod_security_standards) to this file.
2. Create the kubeconfig file that the admission plugins refer to. Rancher Webhook only supports client certificate authentication, so generate a TLS key pair, and set the kubeconfig to use either `client-certificate` and `client-key` or `client-certificate-data` and `client-key-data`. For example:
```yaml
# /etc/rancher/admission/kubeconfig
apiVersion: v1
kind: Config
users:
- name: 'rancher-webhook.cattle-system.svc'
user:
client-certificate: /path/to/client/cert
client-key: /path/to/client/key
```
3. Start the kube-apiserver binary with the flag `--admission-control-config-file` pointing to your AdmissionConfiguration file. The way to do this varies by distro, and it isn't supported universally, such as in hosted Kubernetes providers. Consult the documentation for your Kubernetes distribution.
For RKE2, `rke2-server` can be started with a config file like so:
```yaml
# /etc/rancher/rke2/config.yaml
kube-apiserver-arg:
- admission-control-config-file=/etc/rancher/admission/admission.yaml
kube-apiserver-extra-mount:
- /etc/rancher/admission:/etc/rancher/admission:ro
```
:::danger
Some distros set this flag by default. If your distro provisions its own AdmissionConfiguration, you must include it in your custom admission control config file. For example, RKE2 installs an AdmissionConfiguration file at `/etc/rancher/rke2/rke2-pss.yaml`, which configures the PodSecurity admission plugin. Setting `admission-control-config-file` in config.yaml will override this essential security setting. To include both plugins, consult [the Default Pod Security Standards documentation](https://docs.rke2.io/security/pod_security_standards) and copy the appropriate plugin configuration to your admission.yaml.
:::
4. If you're using Rancher to provision your cluster using existing nodes, create these files on the node before you provision them.
If you're using Rancher to provision your cluster on new nodes, allow the provisioning to complete, then use the provided SSH key and IP address to connect to the nodes, and place the RKE2 config file in the `/etc/rancher/rke2/config.yaml.d/` directory.
5. After the cluster is configured with these credentials, configure the Rancher cluster agent to enable authentication in the webhook. Create a file containing these chart values:
```yaml
# values.yaml
auth:
clientCA: <base64-encoded certificate authority that signed the kube-apiserver's client certificates>
allowedCNs:
- <list of Common Names identifying the kube-apiserver's client certificates.>
- <if not provided, any cert signed by the given CA will be accepted.>
```
6. Create a configmap in the `cattle-system` namespace on the provisioned cluster with these values:
```
kubectl --namespace cattle-system create configmap --from-file=rancher-webhook=values.yaml
```
The webhook will restart with these values.
+46 -9
View File
@@ -124,10 +124,23 @@ module.exports = {
sidebarPath: require.resolve('./sidebars.js'),
showLastUpdateTime: true,
editUrl: 'https://github.com/rancher/rancher-docs/edit/main/',
lastVersion: 'current',
// lastVersion: '2.7',
includeCurrentVersion: false,
versions: {
current: {
label: 'Latest'
// current: {
// label: 'Next 🚧',
// path: 'next',
// banner: 'unreleased'
// },
latest: {
label: 'Latest',
path: '',
banner: 'none'
},
2.8: {
label: 'v2.8 (Preview)',
path: 'v2.8',
banner: 'unreleased'
},
2.7: {
label: 'v2.7',
@@ -1143,28 +1156,52 @@ module.exports = {
from: '/v2.6/explanations/integrations-in-rancher/opa-gatekeeper'
}, // Redirects for restructure from PR #234 (end)
{
to: "/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.7-k8s-v1.25",
to: "/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.24-k8s-v1.24",
from: "/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.24"
},
{
to: "/v2.7/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.24-k8s-v1.24",
from: "/2.7/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.24"
},
{
to: "/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27",
from: "/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.25"
},
{
to: "/v2.7/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.7-k8s-v1.25",
to: "/v2.7/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27",
from: "/v2.7/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.25"
},
{
to: "/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25",
to: "/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24",
from: "/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.24"
},
{
to: "/v2.7/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24",
from: "/v2.7/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.24"
},
{
to: "/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27",
from: "/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.25"
},
{
to: "/v2.7/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25",
to: "/v2.7/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27",
from: "/v2.7/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.25"
},
{
to: "/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.7-k8s-v1.25",
to: "/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.24-k8s-v1.24",
from: "/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.24"
},
{
to: "/v2.7/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.24-k8s-v1.24",
from: "/v2.7/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.24"
},
{
to: "/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27",
from: "/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.25"
},
{
to: "/v2.7/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.7-k8s-v1.25",
to: "/v2.7/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27",
from: "/v2.7/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.25"
}
],
@@ -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)
@@ -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)。
![Rancher diagram](/img/ranchercomponentsdiagram-2.6.svg)<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` 的输出,这些输出会显示进程/内存/磁盘的使用情况。
@@ -0,0 +1,204 @@
---
title: CNI 网络插件
description: 了解容器网络接口 (CNI)、Rancher 提供的 CNI 网络插件、提供商的功能,以及如何选择网络提供商
---
## 什么是 CNI?
CNI(容器网络接口)是一个[云原生计算基金会项目](https://cncf.io/),它包含了一些规范和库,用于编写在 Linux 容器中配置网络接口的一系列插件。CNI 只关注容器的网络连接,并在容器被删除时移除所分配的资源。
Kubernetes 使用 CNI 作为网络提供商和 Kubernetes Pod 网络之间的接口。
![CNI Logo](/img/cni-logo.png)
有关更多信息,请访问 [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 不会使用此模型,但你可以对其进行配置。
![封装网络](/img/encapsulated-network.png)
### 什么是非封装网络?
该网络模型提供了一个 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 可以使用此模型进行配置,即使这不是默认模式。
![非封装网络](/img/unencapsulated-network.png)
## Rancher 提供哪些 CNI 插件?
### RKE Kubernetes 集群
Rancher 开箱即用地为 RKE Kubernetes 集群提供了几个 CNI 网络插件,分别是 Canal、Flannel、Calico 和 Weave。
如果你使用 Rancher 创建新的 Kubernetes 集群,你可以选择你的 CNI 网络插件。
#### Canal
![Canal Logo](/img/canal-logo.png)
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)。
![](/img/canal-diagram.png)
有关详细信息,请参阅 [Canal GitHub 页面](https://github.com/projectcalico/canal)。
#### Flannel
![Flannel Logo](/img/flannel-logo.png)
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 Diagram](/img/flannel-diagram.png)
有关详细信息,请参阅 [Flannel GitHub 页面](https://github.com/flannel-io/flannel)。
#### Weave
![Weave Logo](/img/weave-logo.png)
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 Logo](/img/calico-logo.png)
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`。
:::
![Calico Diagram](/img/calico-diagram.svg)
有关详细信息,请参阅以下页面:
- [Project Calico 官方网站](https://www.projectcalico.org/)
- [Calico 项目 GitHub 页面](https://github.com/projectcalico/calico)
#### Cilium
![Cilium Logo](/img/cilium-logo.png)
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,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,69 @@
---
title: 一般常见问题解答
---
本文包含了用户常见的 Rancher 2.x 问题。
有关常见技术问题,请参阅[常见技术问题解答](technical-items.md)。
<br/>
**Rancher 2.x 支持 Docker Swarm 和 Mesos 作为环境类型吗?**
如果你在 Rancher 2.x 中创建环境,Swarm 和 Mesos 将不再是可选的标准选项。但是,Swarm 和 Mesos 还能继续作为可以部署的商店应用程序。这是一个艰难的决定,但这是大势所趋。比如说,15,000 多个集群可能只有大约 200 个在运行 Swarm。
<br/>
**是否可以使用 Rancher 2.x 管理 Azure Kubernetes 服务?**
是的。
<br/>
**Rancher 是否支持 Windows?**
Rancher 支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息,请参阅[为 Windows 配置自定义集群](../pages-for-subheaders/use-windows-clusters.md)。
<br/>
**Rancher 是否支持 Istio?**
Rancher 支持 [Istio](../pages-for-subheaders/istio.md)。
此外,Istio 是在我们的微型 PaaS “Rio” 中实现的,它可以运行在 Rancher 2.x 以及任何符合 CNCF 的 Kubernetes 集群上。详情请参阅[这里](https://rio.io/)。
<br/>
**Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文?**
密文管理已在我们的 roadmap 上,但我们尚未将该功能分配给特定版本。
<br/>
**Rancher 2.x 是否也支持 RKT 容器?**
目前,我们只支持 Docker。
<br/>
**Rancher 2.x 是否支持将 Calico、Contiv、Contrail、Flannel、Weave net 等网络插件用于嵌入和已注册的 Kubernetes?**
Rancher 开箱即用地为 Kubernetes 集群提供了几个 CNI 网络插件,分别是 Canal、Flannel、Calico 和 Weave。有关官方支持的详细信息,请参阅 [Rancher 支持矩阵](https://rancher.com/support-maintenance-terms/)。
<br/>
**Rancher 是否计划支持 Traefik?**
目前,我们不打算提供嵌入式 Traefik 支持,但我们仍在探索负载均衡方案。
<br/>
**我可以将 OpenShift Kubernetes 集群导入 2.x 吗?**
我们的目标是运行任何上游 Kubernetes 集群。因此,Rancher 2.x 应该可以与 OpenShift 一起使用,但我们尚未对此进行测试。
<br/>
**Rancher 会集成 Longhorn 吗?**
是的。Longhorn 已集成到 Rancher 2.5+ 中。
@@ -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 密钥。选择要访问的节点并单击行尾 **⋮** 按钮,然后选择**下载密钥**,如下图所示。
![下载密钥](/img/downloadsshkeys.png)
解压缩下载的 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`。
@@ -0,0 +1,89 @@
---
title: 在离线环境中渲染 Helm 模板
---
:::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
```
### 选项 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
```
### 应用已渲染的模板
将渲染的 manifest 目录复制到可以访问 Rancher Server 集群的系统中,并应用渲染的模板。
使用 `kubectl` 来应用渲染的 manifest。
```plain
kubectl -n cattle-system apply -R -f ./rancher
```
## 验证升级
登录 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 版本的已知问题。
@@ -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) 的步骤,然后按照[此页](../../../pages-for-subheaders/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 资源要求的详情,请参见[此节](../../../pages-for-subheaders/installation-requirements.md#rke-和托管-kubernetes)。
- 在 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
按照[本页](../../../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 Helm 安装命令,以设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称:
```
--set ingress.ingressClassName=nginx
```
请参阅[Helm 安装命令](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
@@ -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)这个步骤。然后按照[此处](../../../pages-for-subheaders/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
按照[本页](../../../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 Helm 安装命令,以设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称:
```
--set ingress.ingressClassName=nginx
```
请参阅[Helm 安装命令](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
@@ -0,0 +1,201 @@
---
title: 在 GKE 集群上安装 Rancher
---
在本节中,你将学习如何使用 GKE 安装 Rancher。
如果你已经有一个 GKE Kubernetes 集群,请直接跳转到[安装 Ingress](#7-安装-ingress)这个步骤。然后按照[此处](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
## 先决条件
- 你需要有一个 Google 账号。
- 你需要有一个 Google Cloud Billing 账号。你可使用 Google Cloud Console 来管理你的 Cloud Billing 账号。有关 Cloud Console 的详情,请参见 [ Console 通用指南](https://support.google.com/cloud/answer/3465889?hl=en&ref_topic=3340599)。
- 你需要至少一个在用的 IP 地址和至少 2 个 CPU 的云配额。有关 Rancher Server 的硬件要求,请参见[本节](../../../pages-for-subheaders/installation-requirements.md#rke-和托管-kubernetes)。
## 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 安装命令](../../../pages-for-subheaders/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` 的默认类型)之间的兼容性问题。
@@ -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: ""
@@ -0,0 +1,128 @@
---
title: 回滚
---
## 使用 Rancher 2.6.4+ 进行回滚的其他步骤
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 脚本:
* `verify.sh`:检查集群中是否有任何与 Rancher 相关的资源。
* `cleanup.sh`:清理集群。
有关详细信息和源代码,请参阅 [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanup)。
:::caution
`cleanup.sh` 运行的时候会有停机时间,这是因为脚本会删除 Rancher 创建的资源。
:::
### 从 v2.6.4+ 回滚到较低版本的 v2.6.x
1. 按照[说明](https://github.com/rancher/rancher-cleanup/blob/main/README.md)运行脚本。
1. 按照[说明](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)在现有集群上安装 rancher-backup Helm Chart 并恢复之前的状态。
1. 省略步骤 3。
1. 执行到步骤 4 时,在要回滚到的 local 集群上安装 Rancher 2.6.x 版本。
## 回滚到 Rancher 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。
:::
### 创建 Restore 自定义资源
1. 点击 **☰ > 集群管理**。
1. 找到你的本地集群,并点击 **Explore**。
1. 在左侧导航栏中,点击 **Rancher 备份 > 还原**。
:::note
如果 Rancher Backups 应用不可见,你需要到 **Apps** 的 Charts 页面中安装应用。详情请参见[此处](../../../pages-for-subheaders/helm-charts-in-rancher.md#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
```
### 回滚到上一个 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 的情况。
@@ -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` 访问。
@@ -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>
@@ -0,0 +1,207 @@
---
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。
如果你使用 Helm 2,请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。如果你不能升级到 Helm 3,[Helm 2 升级页面](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)提供了使用 Helm 2 升级的旧升级指南。
### 离线安装:推送镜像到私有镜像仓库
[仅适用于离线安装](../../../pages-for-subheaders/air-gapped-helm-cli-install.md):为新的 Rancher Server 版本收集和推送镜像。使用你需要针对 Rancher 版本升级的镜像,按照步骤[推送镜像到私有镜像仓库](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md)。
### 使用 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 Repositories](../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 版本的已知问题。
@@ -0,0 +1,39 @@
---
title: 功能开关
---
使用功能开关(Feature Flag),你可以试用可选或实验性的功能并启用正在逐步淘汰的旧版功能。
要了解功能的值以及如何启用它们,请参阅[启用实验性功能](../../../pages-for-subheaders/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.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 |
@@ -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)。
了解开启实验性功能的详情,请参见[本页](../../../pages-for-subheaders/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](../../../pages-for-subheaders/logging.md)。
```plain
--set auditLog.level=1
```
默认情况下,启用审计日志会在 Rancher pod 中创建一个 Sidecar 容器。这个容器(`rancher-audit-log`)会把日志流传输到 `stdout`。你可以像收集其他容器日志一样收集此日志。如果你使用 Sidecar 作为审计日志的目标时, `hostPath`,`maxAge`,`maxBackups` 和 `maxSize` 选项不会生效。建议使用你的操作系统或 Docker Daemon 的日志轮换功能来控制磁盘空间的使用。请为 Rancher Server 集群或 System 项目启用 [Logging](../../../pages-for-subheaders/logging.md)。
将 `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`。
以下是使用 `extraEnv` 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 的详情,请参见[离线安装](../../../pages-for-subheaders/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;
}
}
```
@@ -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)。 |
@@ -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/>
@@ -0,0 +1,23 @@
---
title: 安装 Docker
---
在使用 Helm 或 Docker 在 RKE 集群节点上安装 Rancher Server 前,你需要先安装 Docker。RKE2 和 K3s 集群不要求使用 Docker。
Docker 有几个安装方法。一种方法是参见 [Docker 官方文档](https://docs.docker.com/install/)以了解如何在 Linux 上安装 Docker。不同 Linux 发行版的安装步骤可能有所不同。
另一种方式是使用 Rancher 的 Docker 安装脚本,该脚本可用于较新的 Docker 版本。
例如,此命令可用于在 SUSE Linux Enterprise 或 Ubuntu 等主要 Linux 发行版上安装 Docker 20.10:
```
curl https://releases.rancher.com/install-docker/20.10.sh | sh
```
Rancher 提供 Kubernetes 支持的所有上游 Docker 版本的安装脚本。如需了解我们是否提供某个 Docker 版本的安装脚本,请参见包含了 Rancher 所有的 Docker 安装脚本的 [GitHub 仓库](https://github.com/rancher/install-docker)。
请注意,必须应用以下 sysctl 设置:
```
net.bridge.bridge-nf-call-iptables=1
```
@@ -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 能够与它们进行通信。
不同的下游集群的启动方式有不同的端口要求。下面的每个标签都列出了不同[集群类型](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)所需打开的端口。
下图描述了为每个[集群类型](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)打开的端口。
<figcaption>Rancher 管理面板的端口要求</figcaption>
![基本端口要求](/img/port-communications.svg)
:::tip
如果你对安全性的关注不是太高,而且也愿意多打开几个端口,你可以参考[常用端口](#常用端口)中列出的端口,而不是参考下方的表格。
:::
### Harvester 集群的端口
有关 Harvester 端口要求的更多信息,请参阅[此处](../../../integrations-in-rancher/harvester.md#端口要求)。
### Rancher 使用节点池启动 Kubernetes 集群的端口
<details>
<summary>单击展开</summary>
下表描述了节点在[云提供商](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)中创建的情况下,[Rancher 启动 Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 的端口要求。
:::note
在 AWS EC2 或 DigitalOcean 等云提供商中创建集群期间,Rancher 会自动打开所需的端口。
:::
<PortsIaasNodes/>
</details>
### Rancher 使用自定义节点启动 Kubernetes 集群的端口
<details>
<summary>单击展开</summary>
下表描述了使用[自定义节点](../../../pages-for-subheaders/use-existing-nodes.md)的情况下,[Rancher 启动 Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 的端口要求。
<PortsCustomNodes/>
</details>
### 托管 Kubernetes 集群的端口
<details>
<summary>单击展开</summary>
下表描述了[托管集群](../../../pages-for-subheaders/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>
**结果** :该节点已打开添加到自定义集群所需的端口。
@@ -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)。
:::
@@ -0,0 +1,193 @@
---
title: '1. 设置基础设施和私有镜像仓库'
---
本文介绍如何在离线环境中,为 Rancher Management server 配置底层基础设施。你还将设置 Rancher 节点中必须可用的私有容器镜像仓库。
离线环境是 Rancher Server 离线安装或安装在防火墙后面的环境。
Rancher 安装在 K3s Kubernetes 集群、RKE Kubernetes 集群还是单个 Docker 容器上对应的基础设施设置会有所不同。如需了解各个安装方式的更多信息,请参见[本页](../../../../pages-for-subheaders/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 节点
这些主机会断开互联网链接,但需要能与你的私有镜像仓库连接。
请确保你的节点满足[操作系统,容器运行时,硬件和网络](../../../../pages-for-subheaders/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)
@@ -0,0 +1,387 @@
---
title: '3. 安装 Kubernetes(Docker 安装请跳过)'
---
:::note
如果你使用 Docker 在单个节点上安装 Rancher,请跳过本节。
:::
本文描述了如何根据 [Rancher Server 环境的最佳实践](../../../../reference-guides/rancher-manager-architecture/architecture-recommendations.md#kubernetes-安装环境)来安装 Kubernetes 集群。该集群需要专用于运行 Rancher Server。
Rancher 可以安装在任何 Kubernetes 集群上,包括托管的 Kubernetes。
在 RKE、RKE2 或 K3s 上离线安装 Kubernetes 集群的步骤如下所示:
<Tabs>
<TabItem value="K3s">
在本指南中,我们假设你已经在离线环境中创建了节点,并且在堡垒服务器上有一个安全的 Docker 私有镜像仓库。
### 安装概要
1. [准备镜像目录](#1-准备镜像目录)
2. [创建镜像仓库 YAML](#2-创建镜像仓库-yaml)
3. [安装 K3s](#3-安装-k3s)
4. [保存并开始使用 kubeconfig 文件](#4-保存并开始使用-kubeconfig-文件)
### 1. 准备镜像目录
从 [Releases](https://github.com/k3s-io/k3s/releases) 页面获取要运行的 K3s 版本的镜像 tar 文件。
在每个节点上启动 K3s 之前,将这个 tar 文件放在 `images` 目录中,例如:
```sh
sudo mkdir -p /var/lib/rancher/k3s/agent/images/
sudo cp ./k3s-airgap-images-$ARCH.tar /var/lib/rancher/k3s/agent/images/
```
### 2. 创建镜像仓库 YAML
把 `registries.yaml` 文件创建到 `/etc/rancher/k3s/registries.yaml` 中。此文件为 K3s 提供连接到你的私有镜像仓库的详细信息。
在加入必要信息之前,`registries.yaml` 文件是这样的:
```yaml
---
mirrors:
customreg:
endpoint:
- "https://ip-to-server:5000"
configs:
customreg:
auth:
username: xxxxxx # 镜像仓库的用户名
password: xxxxxx # 镜像仓库的密码
tls:
cert_file: <镜像仓库所用的证书文件路径>
key_file: <镜像仓库所用的密钥文件路径>
ca_file: <镜像仓库所用的 CA 文件路径>
```
请注意,目前,K3s 仅支持安全的镜像仓库(带有自定义 CA 的 SSL)。
有关 K3s 的私有镜像仓库配置文件的详情,请参见 [K3s 官方文档](https://rancher.com/docs/k3s/latest/en/installation/private-registry/)。
### 3. 安装 K3s
Rancher 需要安装在支持的 Kubernetes 版本上。如需了解你使用的 Rancher 版本支持哪些 Kubernetes 版本,请参见 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/)。
如需指定 K3s(Kubernetes)版本,在运行 K3s 安装脚本时使用 `INSTALL_K3S_VERSION` 环境变量(例如 `INSTALL_K3S_VERSION="v1.24.10+k3s1"`)。
从 [Releases](https://github.com/k3s-io/k3s/releases) 页面获取 K3s 的二进制文件,该文件要匹配用于获取离线镜像的 tar 版本。
访问 [K3s 安装脚本](https://get.k3s.io)以获取 K3s 的安装脚本。
将二进制文件放到每个节点的 `/usr/local/bin` 中。
将安装脚本放在每个节点的任意位置,并将脚本命名为 `install.sh`。
在每个 Server 上安装 K3s:
```
INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_VERSION=<VERSION> ./install.sh
```
在每个 Agent 上安装 K3s:
```
INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_VERSION=<VERSION> K3S_URL=https://<SERVER>:6443 K3S_TOKEN=<TOKEN> ./install.sh
```
其中 `<SERVER>` 是 Server 的 IP 或有效 DNS,`<TOKEN>` 是可以在 `/var/lib/rancher/k3s/server/node-token` 中找到的 Server node-token。
:::note
K3s 自动为 kubelets 提供 `--resolv-conf` 标志,该标志可能对在离线环境中配置 DNS 有帮助。
:::
### 4. 保存并开始使用 kubeconfig 文件
在每个 Rancher Server 节点安装 K3s 时,会在每个节点的 `/etc/rancher/k3s/k3s.yaml` 中生成一个 `kubeconfig` 文件。该文件包含访问集群的凭证。请将该文件保存在安全的位置。
如要使用该 `kubeconfig` 文件:
1. 安装 Kubernetes 命令行工具 [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl)。
2. 复制 `/etc/rancher/k3s/k3s.yaml` 文件并保存到本地主机的 `~/.kube/config` 目录上。
3. 在 kubeconfig 文件中,`server` 的参数为 localhost。你需要将 `server` 配置为负载均衡器的 DNS,并指定端口 6443(通过端口 6443 访问 Kubernetes API Server,通过端口 80 和 443 访问 Rancher Server)。以下是一个 `k3s.yaml` 示例:
```yaml
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: [CERTIFICATE-DATA]
server: [LOAD-BALANCER-DNS]:6443 # 编辑此行
name: default
contexts:
- context:
cluster: default
user: default
name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
user:
password: [PASSWORD]
username: admin
```
**结果**:你可以开始使用 `kubectl` 来管理你的 K3s 集群。如果你有多个 `kubeconfig` 文件,在使用 `kubectl` 时,你可以传入文件路径来指定要使用的 `kubeconfig` 文件:
```
kubectl --kubeconfig ~/.kube/config/k3s.yaml get pods --all-namespaces
```
有关 `kubeconfig` 文件的详情,请参见 [K3s 官方文档](https://rancher.com/docs/k3s/latest/en/cluster-access/) 或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
### 升级注意事项
你可以通过以下方式完成离线环境的升级:
1. 从 [Releases](https://github.com/k3s-io/k3s/releases) 页面下载要升级的 K3s 版本的新离线镜像 tar 包。将 tar 文件放在每个节点上的 `/var/lib/rancher/k3s/agent/images/` 目录中。删除旧的 tar 文件。
2. 复制并替换每个节点上 `/usr/local/bin` 中的旧 K3s 二进制文件。复制 [K3s 安装脚本](https://get.k3s.io)(因为脚本可能自上次版本发布以来已更改)。使用相同的环境变量再次运行脚本。
3. 重启 K3s 服务(如果安装程序没有自动重启 K3s 的话)。
</TabItem>
<TabItem value="RKE2">
在本指南中,我们假设你已经在离线环境中创建了节点,并且在堡垒服务器上有一个安全的 Docker 私有镜像仓库。
### 安装概要
1. [创建 RKE2 配置](#1-创建-rke2-配置)
2. [创建镜像仓库 YAML](#2-创建镜像仓库-yaml)
3. [安装 RKE2](#3-安装-rke2)
4. [保存并开始使用 kubeconfig 文件](#4-保存并开始使用-kubeconfig-文件)
### 1. 创建 RKE2 配置
把 config.yaml 文件创建到 `/etc/rancher/rke2/config.yaml` 中。这将包含创建高可用 RKE2 集群所需的所有配置选项。
第一台服务器的最低配置是:
```
token: my-shared-secret
tls-san:
- loadbalancer-dns-domain.com
```
其他服务器的配置文件应该包含相同的令牌,并让 RKE2 知道要连接到现有的第一台服务器:
```
server: https://ip-of-first-server:9345
token: my-shared-secret
tls-san:
- loadbalancer-dns-domain.com
```
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/ha)。
:::note
RKE2 自动为 kubelets 提供 `resolv-conf` 选项,该标志可能对在离线环境中配置 DNS 有帮助。
:::
### 2. 创建镜像仓库 YAML
把 `registries.yaml` 文件创建到 `/etc/rancher/rke2/registries.yaml` 中。此文件为 RKE2 提供连接到你的私有镜像仓库的详细信息。
在加入必要信息之前,`registries.yaml` 文件是这样的:
```
---
mirrors:
customreg:
endpoint:
- "https://ip-to-server:5000"
configs:
customreg:
auth:
username: xxxxxx # 镜像仓库的用户名
password: xxxxxx # 镜像仓库的密码
tls:
cert_file: <镜像仓库所用的证书文件路径>
key_file: <镜像仓库所用的密钥文件路径>
ca_file: <镜像仓库所用的 CA 文件路径>
```
有关 RKE2 的私有镜像仓库配置文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/install/containerd_registry_configuration)。
### 3. 安装 RKE2
Rancher 需要安装在支持的 Kubernetes 版本上。如需了解你使用的 Rancher 版本支持哪些 Kubernetes 版本,请参见[支持维护条款](https://rancher.com/support-maintenance-terms/)。
从 Release 页面下载安装脚本、rke2、rke2-images 和 sha256sum 存档,并将它们上传到每个服务器上的目录中:
```
mkdir /tmp/rke2-artifacts && cd /tmp/rke2-artifacts/
wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/rke2-images.linux-amd64.tar.zst
wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/rke2.linux-amd64.tar.gz
wget https://github.com/rancher/rke2/releases/download/v1.21.5%2Brke2r2/sha256sum-amd64.txt
curl -sfL https://get.rke2.io --output install.sh
```
接下来,使用每个服务器上的目录运行 install.sh,如下例所示:
```
INSTALL_RKE2_ARTIFACT_PATH=/tmp/rke2-artifacts sh install.sh
```
然后在所有服务器上启用并启动该服务:
``
systemctl enable rke2-server.service
systemctl start rke2-server.service
``
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/airgap)。
### 4. 保存并开始使用 kubeconfig 文件
在每个 Rancher Server 节点安装 RKE2 时,会在每个节点的 `/etc/rancher/rke2/rke2.yaml` 中生成一个 `kubeconfig` 文件。该文件包含访问集群的凭证。请将该文件保存在安全的位置。
如要使用该 `kubeconfig` 文件:
1. 安装 [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl)(Kubernetes 命令行工具)。
2. 复制 `/etc/rancher/rke2/rke2.yaml` 文件并保存到本地主机的 `~/.kube/config` 目录上。
3. 在 kubeconfig 文件中,`server` 的参数为 localhost。你需要将 `server` 配置为负载均衡器的 DNS,并指定端口 6443(通过端口 6443 访问 Kubernetes API Server,通过端口 80 和 443 访问 Rancher Server)。以下是一个 `rke2.yaml` 示例:
```
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: [CERTIFICATE-DATA]
server: [LOAD-BALANCER-DNS]:6443 # 编辑此行
name: default
contexts:
- context:
cluster: default
user: default
name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
user:
password: [PASSWORD]
username: admin
```
**结果**:你可以开始使用 `kubectl` 来管理你的 RKE2 集群。如果你有多个 `kubeconfig` 文件,在使用 `kubectl` 时,你可以传入文件路径来指定要使用的 `kubeconfig` 文件:
```
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
```
有关 `kubeconfig` 文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/cluster_access)或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
### 升级注意事项
你可以通过以下方式完成离线环境的升级:
1. 从 [Releases](https://github.com/rancher/rke2/releases) 页面下载新的离线工件,并安装升级 RKE2 版本的脚本。
2. 使用相同的环境变量再次运行脚本。
3. 重启 RKE2 服务。
</TabItem>
<TabItem value="RKE">
我们将使用 Rancher Kubernetes Engine (RKE) 创建一个 Kubernetes 集群。在启动 Kubernetes 集群之前,你需要安装 RKE 并创建 RKE 配置文件。
### 1. 安装 RKE
参照 [RKE 官方文档](https://rancher.com/docs/rke/latest/en/installation/)的说明安装 RKE。
:::note
你可以在 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/)中找到基于 Rancher 版本的 RKE 认证版本。
:::
### 2. 创建 RKE 配置文件
在可访问你 Linux 主机节点上的 22/TCP 端口和 6443/TCP 端口的系统上,使用以下示例创建一个名为 `rancher-cluster.yml` 的新文件。
该文件是 RKE 配置文件,用于配置你要部署 Rancher 的集群。
参考下方的 _RKE 选项_ 表格,修改代码示例中的参数。使用你创建的三个节点的 IP 地址或 DNS 名称。
:::tip
如需获取可用选项的详情,请参见 RKE [配置选项](https://rancher.com/docs/rke/latest/en/config-options/)。
:::
<figcaption>RKE 选项</figcaption>
| 选项 | 必填 | 描述 |
| ------------------ | -------------------- | --------------------------------------------------------------------------------------- |
| `address` | ✓ | 离线环境中节点的 DNS 或 IP 地址 |
| `user` | ✓ | 可运行 Docker 命令的用户 |
| `role` | ✓ | 分配给节点的 Kubernetes 角色列表 |
| `internal_address` | 可选<sup>1</sup> | 用于集群内部流量的 DNS 或 IP 地址 |
| `ssh_key_path` | | 用来验证节点的 SSH 私钥文件路径(默认值为 `~/.ssh/id_rsa`) |
> <sup>1</sup> 如果你想使用引用安全组或防火墙,某些服务(如 AWS EC2)要求设置 `internal_address`。
```yaml
nodes:
- address: 10.10.3.187 # 离线环境节点 IP
internal_address: 172.31.7.22 # 节点内网 IP
user: rancher
role: ['controlplane', 'etcd', 'worker']
ssh_key_path: /home/user/.ssh/id_rsa
- address: 10.10.3.254 # 离线环境节点 IP
internal_address: 172.31.13.132 # 节点内网 IP
user: rancher
role: ['controlplane', 'etcd', 'worker']
ssh_key_path: /home/user/.ssh/id_rsa
- address: 10.10.3.89 # 离线环境节点 IP
internal_address: 172.31.3.216 # 节点内网 IP
user: rancher
role: ['controlplane', 'etcd', 'worker']
ssh_key_path: /home/user/.ssh/id_rsa
private_registries:
- url: <REGISTRY.YOURDOMAIN.COM:PORT> # 私有镜像仓库 URL
user: rancher
password: '*********'
is_default: true
```
### 3. 运行 RKE
配置 `rancher-cluster.yml`后,启动你的 Kubernetes 集群:
```
rke up --config ./rancher-cluster.yml
```
### 4. 保存你的文件
:::note 重要提示:
维护、排除问题和升级集群需要用到以下文件,请妥善保管这些文件:
:::
将以下文件的副本保存在安全位置:
- `rancher-cluster.yml`:RKE 集群配置文件。
- `kube_config_cluster.yml`:集群的 [Kubeconfig 文件](https://rancher.com/docs/rke/latest/en/kubeconfig/)。该文件包含可完全访问集群的凭证。
- `rancher-cluster.rkestate`:[Kubernetes 集群状态文件](https://rancher.com/docs/rke/latest/en/installation/#kubernetes-cluster-state)。该文件包含集群的当前状态,包括 RKE 配置以及证书<br/>。<br/>_Kubernetes 集群状态文件仅在使用 RKE 0.2.0 或更高版本时创建。_
</TabItem>
</Tabs>
:::note
后两个文件名中的 `rancher-cluster` 部分取决于你命名 RKE 集群配置文件的方式。
:::
### 故障排除
参见[故障排除](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)页面。
### 后续操作
[安装 Rancher](install-rancher-ha.md)
@@ -0,0 +1,246 @@
---
title: 4. 安装 Rancher
---
本文介绍如何在高可用 Kubernetes 安装的离线环境部署 Rancher。离线环境可以是 Rancher Server 离线安装、防火墙后面或代理后面。
### Rancher 特权访问
当 Rancher Server 部署在 Docker 容器中时,容器内会安装一个本地 Kubernetes 集群供 Rancher 使用。为 Rancher 的很多功能都是以 deployment 的方式运行的,而在容器内运行容器是需要特权模式的,因此你需要在安装 Rancher 时添加 `--privileged` 选项。
## Docker 说明
如果你想使用 Docker 命令进行离线安装,请跳过本页的剩余部分,并按照[此页](docker-install-commands.md)进行操作。
## Kubernetes 说明
我们建议在 Kubernetes 集群上安装 Rancher。高可用的 Kubernetes 安装的情况下,一个 Kubernetes 集群包含三个运行 Rancher Server 组件的节点。持久层(etcd)也在这三个节点上进行复制,以便在其中一个节点发生故障时提供冗余和数据复制。
### 1. 添加 Helm Chart 仓库
从可以访问互联网的系统中,获取最新的 Helm Chart,然后将 manifest 复制到可访问 Rancher Server 集群的系统中。
1. 如果你还没有安装 `helm`,请在可访问互联网的工作站上进行本地安装。注意:参考 [Helm 版本要求](../../resources/helm-version-requirements.md)选择 Helm 版本来安装 Rancher。
2. 执行 `helm repo add` 命令,以添加包含安装 Rancher 的 Chart 的 Helm Chart 仓库。有关如何选择仓库,以及哪个仓库最适合你的用例,请参见[选择 Rancher 版本](../../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 版之间升级。
3. 获取最新的 Rancher Chart。此操作将获取 Chart 并将其作为 `.tgz` 文件保存在当前目录中。
```plain
helm fetch rancher-<CHART_REPO>/rancher
```
如需下载特定的 Rancher 版本,你可以用 Helm `--version` 参数指定版本,如下:
```plain
helm fetch rancher-stable/rancher --version=v2.4.8
```
### 2. 选择 SSL 配置
Rancher Server 默认设计为安全的,并且需要 SSL/TLS 配置。
如果你在离线的 Kubernetes 集群中安装 Rancher,我们建议使用以下两种证书生成方式。
:::note
如果你想在外部终止 SSL/TLS,请参见[外部负载均衡器的 TLS 终止](../../installation-references/helm-chart-options.md#外部-tls-终止)。
:::
| 配置 | Chart 选项 | 描述 | 是否需要 cert-manager |
| ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
| Rancher 生成的自签名证书 | `ingress.tls.source=rancher` | 使用 Rancher 生成的 CA 签发的自签名证书。此项是**默认选项**。在渲染 Helm 模板的时候不需要传递此项。 | 是 |
| 你已有的证书 | `ingress.tls.source=secret` | 通过创建 Kubernetes 密文使用你自己的证书文件。<br />在渲染 Rancher Helm 模板时必须传递此选项。 | 否 |
### 离线安装的 Helm Chart 选项
在配置 Rancher Helm 模板时,Helm Chart 中有几个专为离线安装设计的选项,如下表:
| Chart 选项 | Chart 值 | 描述 |
| ----------------------- | -------------------------------- | ---- |
| `certmanager.version` | `<version>` | 根据运行的 cert-manager 版本配置适当的 Rancher TLS 颁发者。 |
| `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | 将 Rancher Server 配置成在配置集群时,始终从私有镜像仓库中拉取镜像。 |
| `useBundledSystemChart` | `true` | 配置 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 容易得多。 |
### 3. 获取 Cert-Manager Chart
根据你在[2:选择 SSL 配置](#2-选择-ssl-配置)中的选择,完成以下步骤之一:
#### 选项 A:使用 Rancher 默认的自签名证书
默认情况下,Rancher 会生成一个 CA 并使用 cert-manager 颁发证书以访问 Rancher Server 界面。
:::note
由于 cert-manager 的最新改动,你需要升级 cert-manager 版本。如果你需要升级 Rancher 并使用低于 0.11.0 的 cert-manager 版本,请参见 [cert-manager 升级文档](../../resources/upgrade-cert-manager.md)。
:::
##### 1. 添加 cert-manager 仓库
在可以连接互联网的系统中,将 cert-manager 仓库添加到 Helm:
```plain
helm repo add jetstack https://charts.jetstack.io
helm repo update
```
##### 2. 获取 cert-manager Chart
从 [Helm Chart 仓库](https://artifacthub.io/packages/helm/cert-manager/cert-manager)中获取最新可用的 cert-manager Chart:
```plain
helm fetch jetstack/cert-manager --version v1.11.0
```
##### 3. 检索 Cert-Manager CRD
为 cert-manager 下载所需的 CRD 文件:
```plain
curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
```
### 4. 安装 Rancher
将获取的 Chart 复制到有权访问 Rancher Server 集群的系统以完成安装。
##### 1. 安装 Cert-Manager
使用要用于安装 Chart 的选项来安装 cert-manager。记住要设置 `image.repository` 选项,以从你的私有镜像仓库拉取镜像。此操作会创建一个包含 Kubernetes manifest 文件的 `cert-manager` 目录。
:::note
要查看自定义 cert-manager 安装的选项(包括集群使用 PodSecurityPolicies 的情况),请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
:::
<details id="install-cert-manager">
<summary>单击展开</summary>
如果你使用自签名证书,安装 cert-manager:
1. 为 cert-manager 创建命名空间:
```plain
kubectl create namespace cert-manager
```
2. 创建 cert-manager CustomResourceDefinition (CRD)。
```plain
kubectl apply -f cert-manager/cert-manager-crd.yaml
```
3. 安装 cert-manager。
```plain
helm install cert-manager ./cert-manager-v1.11.0.tgz \
--namespace cert-manager \
--set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller \
--set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook \
--set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector \
--set startupapicheck.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-ctl
```
</details>
##### 2. 安装 Rancher
首先,参见[添加 TLS 密文](../../resources/add-tls-secrets.md)发布证书文件,以便 Rancher 和 Ingress Controller 可以使用它们。
然后,使用 kubectl 为 Rancher 创建命名空间:
```plain
kubectl create namespace cattle-system
```
然后安装 Rancher,并声明你选择的选项。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库,以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。
对于 Kubernetes v1.25 或更高版本,使用 Rancher v2.7.2-v2.7.4 时,将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说,这不是必需的,但你仍然可以手动设置该选项。
| 占位符 | 描述 |
------------|-------------
| `<VERSION>` | 输出压缩包的版本号。 |
| `<RANCHER.YOURDOMAIN.COM>` | 指向负载均衡器的 DNS 名称。 |
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 你的私有镜像仓库的 DNS 名称。 |
| `<CERTMANAGER_VERSION>` | 在 K8s 集群上运行的 cert-manager 版本。 |
```plain
helm install rancher ./rancher-<VERSION>.tgz \
--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> \ # 设置在 Rancher 中使用的默认私有镜像仓库
--set useBundledSystemChart=true # 使用打包的 Rancher System Chart
```
**可选**:如需安装特定的 Rancher 版本,设置`rancherImageTag` 的值,例如:`--set rancherImageTag=v2.5.8`
#### 选项 B:使用 Kubernetes 密文从文件中获取证书
##### 1. 创建密文
使用你自己的证书来创建 Kubernetes 密文,以供 Rancher 使用。证书的 common name 需要与以下命令中的 `hostname` 选项匹配,否则 Ingress Controller 将无法为 Rancher 配置站点。
##### 2. 安装 Rancher
安装 Rancher,并声明你选择的选项。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库,以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。
对于 Kubernetes v1.25 或更高版本,使用 Rancher v2.7.2-v2.7.4 时,将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说,这不是必需的,但你仍然可以手动设置该选项。
| 占位符 | 描述 |
| -------------------------------- | ----------------------------------------------- |
| `<VERSION>` | 输出压缩包的版本号。 |
| `<RANCHER.YOURDOMAIN.COM>` | 指向负载均衡器的 DNS 名称。 |
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 你的私有镜像仓库的 DNS 名称。 |
```plain
helm install rancher ./rancher-<VERSION>.tgz \
--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> \ # 设置在 Rancher 中使用的默认私有镜像仓库
--set useBundledSystemChart=true # 使用打包的 Rancher System Chart
```
如果你使用的是私有 CA 签名的证书,请在 `--set ingress.tls.source=secret` 后加上 `--set privateCA=true`:
```plain
helm install rancher ./rancher-<VERSION>.tgz \
--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> \ # 设置在 Rancher 中使用的默认私有镜像仓库
--set useBundledSystemChart=true # 使用打包的 Rancher System Chart
```
安装已完成。
:::caution
如果你不想发送遥测数据,在首次登录时退出[遥测](../../../../faq/telemetry.md)。如果在离线安装的环境中让这个功能处于 active 状态,socket 可能无法打开。
:::
## 其他资源
以下资源可能对安装 Rancher 有帮助:
- [Rancher Helm Chart 选项](../../installation-references/helm-chart-options.md)
- [添加 TLS 密文](../../resources/add-tls-secrets.md)
- [Rancher Kubernetes 安装的故障排除](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)
@@ -0,0 +1,305 @@
---
title: '2. 收集镜像并发布到私有仓库'
---
本文介绍如何配置私有镜像仓库,以便在安装 Rancher 时,Rancher 可以从此私有镜像仓库中拉取所需的镜像。
默认情况下,所有用于[配置 Kubernetes 集群](../../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)或启动 Rancher 中的工具(如监控,流水线,告警等)的镜像都是从 Docker Hub 中拉取的。在 Rancher 的离线安装中,你需要一个私有仓库,该仓库位于你的 Rancher Server 中某个可访问的位置。然后,你可加载该存有所有镜像的镜像仓库。
使用 Docker 安装 Rancher,和把 Rancher 安装到 Kubernetes 集群,其对应的推送镜像到私有镜像仓库步骤是一样的。
你使用 Rancher 配置的下游集群是否有运行 Windows 的节点,决定了本文涉及的步骤。我们提供的推送镜像到私有镜像仓库步骤,是基于假设 Rancher 仅配置运行 Linux 节点的下游 Kubernetes 集群的。但是,如果你计划[在下游 Kubernetes 集群中使用 Windows 节点](../../../../pages-for-subheaders/use-windows-clusters.md),我们有单独的文档来介绍如何为需要的镜像提供支持。
:::note 先决条件:
你必须有一个可用的[私有镜像仓库](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)。
如果镜像仓库有证书,请参见 [K3s 文档中心](https://rancher.com/docs/k3s/latest/en/installation/private-registry/)了解添加私有镜像仓库的详情。证书和镜像仓库配置文件均需要挂载到 Rancher 容器中。
:::
<Tabs>
<TabItem value="仅包含 Linux 的集群">
如果 Rancher Server 用于配置仅有 Linux 节点的集群,请按以下步骤将你的镜像推送到私有镜像仓库。
1. [找到你的 Rancher 版本所需的资源](#1-找到你的-rancher-版本所需的资源)
2. [收集 cert-manager 镜像](#2-收集-cert-manager-镜像)(除非你使用自己的证书,或在负载均衡器上终止 TLS)
3. [把镜像保存到你的工作站](#3-将镜像保存到你的工作站中)
4. [推送镜像到私有镜像仓库](#4-推送镜像到私有镜像仓库)
### 先决条件
这些步骤要求你使用一个 Linux 工作站,该工作站需要可访问互联网和你的私有镜像仓库,且至少有 20GB 的可用磁盘空间。
如果你的主机架构是 ARM64,镜像仓库必须支持 Manifest。这是因为从 2020 年 4 月开始, Amazon Elastic Container Registry 已经不再支持 Manifest。
### 1. 找到你的 Rancher 版本所需的资源
1. 访问 Rancher 的[发布说明](https://github.com/rancher/rancher/releases)页面,找到你需要安装的 Rancher v2.x.x 版本,然后点击 **Assets**。注意不要使用带有 `rc` 或 `Pre-release` 标记的版本,因为这些版本在生产环境中不够稳定。
2. 从你所需版本的 **Assets** 处下载以下文件,这些文件是在离线环境中安装 Rancher 所必须的:
| Release 文件 | 描述 |
| ---------------- | -------------- |
| `rancher-images.txt` | 此文件包含安装 Rancher、配置集群和用户 Rancher 工具所需的镜像。 |
| `rancher-save-images.sh` | 该脚本从 Docker Hub 中拉取在文件 `rancher-images.txt` 中记录的所有镜像,并把这些镜像保存为 `rancher-images.tar.gz`。 |
| `rancher-load-images.sh` | 该脚本从 `rancher-images.tar.gz` 文件中加载镜像,并把镜像推送到你的私有镜像仓库。 |
### 2. 收集 cert-manager 镜像
:::note
如果你使用自己的证书,或要在外部负载均衡器上终止 TLS,请跳过此步骤。
:::
在 Kubernetes 安装中,如果你使用的是 Rancher 默认的自签名 TLS 证书,则必须将 [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) 镜像添加到 `rancher-images.txt` 文件中。
1. 获取最新的 `cert-manager` Helm Chart,并解析模板以获取镜像的详情信息:
:::note
由于 cert-manager 的最新改动,你需要升级 cert-manager 版本。如果你需要升级 Rancher 并使用低于 0.12.0 的 cert-manager 版本,请参见[升级文档](../../resources/upgrade-cert-manager.md)。
:::
```plain
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm fetch jetstack/cert-manager --version v1.11.0
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
```
2. 对镜像列表进行排序和唯一化,以去除重复的镜像源:
```plain
sort -u rancher-images.txt -o rancher-images.txt
```
### 3. 将镜像保存到你的工作站中
1. 为 `rancher-save-images.sh` 文件添加可执行权限:
```
chmod +x rancher-save-images.sh
```
1. 使用 `rancher-images.txt` 镜像列表执行 `rancher-save-images.sh` 脚本,以创建包含所有所需镜像的压缩包:
```plain
./rancher-save-images.sh --image-list ./rancher-images.txt
```
**结果**:Docker 开始拉取用于离线安装的镜像。请耐心等待。这个过程需要几分钟。完成时,你的当前目录会输出名为 `rancher-images.tar.gz` 的压缩包。请确认输出文件是否存在。
### 4. 推送镜像到私有镜像仓库
下一步,你将使用脚本将 `rancher-images.tar.gz` 中的镜像移动到你的私有镜像仓库,以方便加载镜像。
使用脚本将 `rancher-images.tar.gz` 中的镜像移动到你的私有镜像仓库,以方便加载镜像。
`rancher-images.txt` 需要位于工作站中运行 `rancher-load-images.sh` 脚本的同一目录中。`rancher-images.tar.gz` 也需要位于同一目录中。
1. 登录到你的私有镜像仓库:
```plain
docker login <REGISTRY.YOURDOMAIN.COM:PORT>
```
1. 为 `rancher-load-images.sh` 添加可执行权限:
```
chmod +x rancher-load-images.sh
```
1. 使用 `rancher-load-images.sh` 脚本来提取,标记和推送 `rancher-images.txt` 及 `rancher-images.tar.gz` 到你的私有镜像仓库:
```plain
./rancher-load-images.sh --image-list ./rancher-images.txt --registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
</TabItem>
<TabItem value="Linux 和 Windows 集群">
如果你的 Rancher Server 将用于配置 Linux 和 Windows 集群,你需要执行不同的步骤,来将 Windows 镜像和 Linux 镜像推送到你的私有镜像仓库。由于 Windows 集群同时包含 Linux 和 Windows 节点,因此推送到私有镜像仓库的 Linux 镜像是 Manifest。
## Windows 步骤
从 Windows Server 工作站中收集和推送 Windows 镜像。
1. <a href="#windows-1">找到你的 Rancher 版本所需的资源</a>
2. <a href="#windows-2">将镜像保存到你的 Windows Server 工作站</a>
3. <a href="#windows-3">准备 Docker daemon</a>
4. <a href="#windows-4">推送镜像到私有镜像仓库</a>
### 先决条件
以下步骤假设你使用 Windows Server 1809 工作站,该工作站能访问网络及你的私有镜像仓库,且至少拥有 50GB 的磁盘空间。
工作站必须安装 Docker 18.02+ 版本以提供 manifest 支持。Manifest 支持是配置 Windows 集群所必须的。
你的镜像仓库必须支持 Manifest。这是因为从 2020 年 4 月开始, Amazon Elastic Container Registry 已经不再支持 Manifest。
<a name="windows-1"></a>
### 1. 找到你的 Rancher 版本所需的资源
1. 访问 Rancher 的[发布说明](https://github.com/rancher/rancher/releases)页面,找到你需要安装的 Rancher v2.x.x 版本。不要下载带有 `rc` 或 `Pre-release` 标记的版本,因为这些版本在生产环境中不够稳定。
2. 从你所需版本的 **Assets** 处下载以下文件:
| Release 文件 | 描述 |
|----------------------------|------------------|
| `rancher-windows-images.txt` | 此文件包含配置 Windows 集群所需的 Windows 镜像。 |
| `rancher-save-images.ps1` | 该脚本从 Docker Hub 中拉取在文件 `rancher-windows-images.txt` 中记录的所有镜像,并把这些镜像保存为 `rancher-windows-images.tar.gz`。 |
| `rancher-load-images.ps1` | 该脚本从 `rancher-windows-images.tar.gz` 文件中加载镜像,并把镜像推送到你的私有镜像仓库。 |
<a name="windows-2"></a>
### 2. 将镜像保存到你的 Windows Server 工作站
1. 在 `powershell` 中,进入上一步下载的文件所在的目录。
1. 运行 `rancher-save-images.ps1` 以创建包含所有所需镜像的压缩包:
```plain
./rancher-save-images.ps1
```
**结果**:Docker 开始拉取用于离线安装的镜像。请耐心等待。这个过程需要几分钟。完成时,你的当前目录会输出名为 `rancher-windows-images.tar.gz` 的压缩包。请确认输出文件是否存在。
<a name="windows-3"></a>
### 3. 准备 Docker daemon
将你的私有镜像仓库地址尾附到 Docker daemon (`C:\\ProgramData\\Docker\\config\\daemon.json`) 的 `allow-nondistributable-artifacts` 配置字段中。Windows 镜像的基础镜像是由 `mcr.microsoft.com` 镜像仓库维护的,而 Docker Hub 中缺少 Microsoft 镜像仓库层,且需要将其拉入私有镜像仓库,因此这一步骤是必须的。
```json
{
...
"allow-nondistributable-artifacts": [
...
"<REGISTRY.YOURDOMAIN.COM:PORT>"
]
...
}
```
<a name="windows-4"></a>
### 4. 推送镜像到私有镜像仓库
使用脚本将 `rancher-windows-images.tar.gz` 中的镜像移动到你的私有镜像仓库,以方便加载镜像。
`rancher-windows-images.txt` 需要位于工作站中运行 `rancher-load-images.ps1` 脚本的同一目录中。`rancher-windows-images.tar.gz` 也需要位于同一目录中。
1. 使用 `powershell` 登录到你的私有镜像仓库:
```plain
docker login <REGISTRY.YOURDOMAIN.COM:PORT>
```
1. 在 `powershell` 中,使用 `rancher-load-images.ps1` 脚本来提取,标记和推送 `rancher-images.tar.gz` 中的镜像到你的私有镜像仓库:
```plain
./rancher-load-images.ps1 --registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
## Linux 步骤
Linux 镜像需要在 Linux 主机上收集和推送,但是你必须先将 Windows 镜像推送到私有镜像仓库,然后再推送 Linux 镜像。由于被推送的 Linux 镜像实际上是支持 Windows 和 Linux 镜像的 manifest,因此涉及的步骤不同于只包含 Linux 节点的集群。
1. <a href="#linux-1">找到你的 Rancher 版本所需的资源</a>
2. <a href="#linux-2">收集所有需要的镜像</a>
3. <a href="#linux-3">将镜像保存到你的 Linux 工作站中</a>
4. <a href="#linux-4">推送镜像到私有镜像仓库</a>
### 先决条件
在将 Linux 镜像推送到私有镜像仓库之前,你必须先把 Windows 镜像推送到私有镜像仓库。如果你已经把 Linux 镜像推送到私有镜像仓库,则需要再次按照说明重新推送,因为它们需要发布支持 Windows 和 Linux 镜像的 manifest。
这些步骤要求你使用一个 Linux 工作站,该工作站需要可访问互联网和你的私有镜像仓库,且至少有 20GB 的可用磁盘空间。
工作站必须安装 Docker 18.02+ 版本以提供 manifest 支持。Manifest 支持是配置 Windows 集群所必须的。
<a name="linux-1"></a>
### 1. 找到你的 Rancher 版本所需的资源
1. 访问 Rancher 的[发布说明](https://github.com/rancher/rancher/releases)页面,找到你需要安装的 Rancher v2.x.x 版本。不要下载带有 `rc` 或 `Pre-release` 标记的版本,因为这些版本在生产环境中不够稳定。点击 **Assets**。
2. 从你所需版本的 **Assets** 处下载以下文件:
| Release 文件 | 描述 |
|----------------------------| -------------------------- |
| `rancher-images.txt` | 此文件包含安装 Rancher、配置集群和用户 Rancher 工具所需的镜像。 |
| `rancher-windows-images.txt` | 此文件包含配置 Windows 集群所需的镜像。 |
| `rancher-save-images.sh` | 该脚本从 Docker Hub 中拉取在文件 `rancher-images.txt` 中记录的所有镜像,并把这些镜像保存为 `rancher-images.tar.gz`。 |
| `rancher-load-images.sh` | 该脚本从 `rancher-images.tar.gz` 文件中加载镜像,并把镜像推送到你的私有镜像仓库。 |
<a name="linux-2"></a>
### 2. 收集所有需要的镜像
**在 Kubernetes 安装中,如果你使用的是 Rancher 默认的自签名 TLS 证书**,则必须将 [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) 镜像添加到 `rancher-images.txt` 文件中。如果你使用自己的证书,则可跳过此步骤。
1. 获取最新的 `cert-manager` Helm Chart,并解析模板以获取镜像的详情信息:
:::note
由于 cert-manager 的最新改动,你需要升级 cert-manager 版本。如果你需要升级 Rancher 并使用低于 0.12.0 的 cert-manager 版本,请参见[升级文档](../../resources/upgrade-cert-manager.md)。
:::
```plain
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm fetch jetstack/cert-manager --version v1.11.0
helm template ./cert-manager-<version>.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
```
2. 对镜像列表进行排序和唯一化,以去除重复的镜像源:
```plain
sort -u rancher-images.txt -o rancher-images.txt
```
<a name="linux-3"></a>
### 3. 将镜像保存到你的工作站中
1. 为 `rancher-save-images.sh` 文件添加可执行权限:
```
chmod +x rancher-save-images.sh
```
1. 使用 `rancher-images.txt` 镜像列表执行 `rancher-save-images.sh` 脚本,以创建包含所有所需镜像的压缩包:
```plain
./rancher-save-images.sh --image-list ./rancher-images.txt
```
**结果**:Docker 开始拉取用于离线安装的镜像。请耐心等待。这个过程需要几分钟。完成时,你的当前目录会输出名为 `rancher-images.tar.gz` 的压缩包。请确认输出文件是否存在。
<a name="linux-4"></a>
### 4. 推送镜像到私有镜像仓库
使用 `rancher-load-images.sh script` 脚本将 `rancher-images.tar.gz` 中的镜像移动到你的私有镜像仓库,以方便加载镜像。
镜像列表,即 `rancher-images.txt` 或 `rancher-windows-images.txt` 需要位于工作站中运行 `rancher-load-images.sh` 脚本的同一目录中。`rancher-images.tar.gz` 也需要位于同一目录中。
1. 登录到你的私有镜像仓库:
```plain
docker login <REGISTRY.YOURDOMAIN.COM:PORT>
```
1. 为 `rancher-load-images.sh` 添加可执行权限:
```
chmod +x rancher-load-images.sh
```
1. 使用 `rancher-load-images.sh` 脚本来提取,标记和推送 `rancher-images.tar.gz` 中的镜像到你的私有镜像仓库:
```plain
./rancher-load-images.sh --image-list ./rancher-images.txt \
--windows-image-list ./rancher-windows-images.txt \
--registry <REGISTRY.YOURDOMAIN.COM:PORT>
```
</TabItem>
</Tabs>
### [Kubernetes 安装的后续步骤 - 启动 Kubernetes 集群](install-kubernetes.md)
### [Docker 安装的后续步骤 - 安装 Rancher](install-rancher-ha.md)
@@ -0,0 +1,249 @@
---
title: '2. 安装 Kubernetes'
---
基础设施配置好后,你可以设置一个 Kubernetes 集群来安装 Rancher。
设置 RKE、RKE2 或 K3s 的步骤如下所示。
为方便起见,将代理的 IP 地址和端口导出到一个环境变量中,并在每个节点上为你当前的 shell 设置 HTTP_PROXY 变量:
```
export proxy_host="10.0.0.5:8888"
export HTTP_PROXY=http://${proxy_host}
export HTTPS_PROXY=http://${proxy_host}
export NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16
```
<Tabs>
<TabItem value="K3s">
首先在 K3s systemd 服务上配置 HTTP 代理设置,让 K3s 的 containerd 可以通过代理拉取镜像:
```
cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
HTTP_PROXY=http://${proxy_host}
HTTPS_PROXY=http://${proxy_host}"
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
EOF
```
Rancher 需要安装在支持的 Kubernetes 版本上。如需了解你使用的 Rancher 版本支持哪些 Kubernetes 版本,请参见 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/)。
如需指定 K3s(Kubernetes)版本,在运行 K3s 安装脚本时使用 `INSTALL_K3S_VERSION` 环境变量(例如 `INSTALL_K3S_VERSION="v1.24.10+k3s1"`)。
在第一个节点上,创建一个新集群:
```
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> K3S_TOKEN=<TOKEN> sh -s - server --cluster-init
```
然后加入其他节点:
```
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=<VERSION> K3S_TOKEN=<TOKEN> sh -s - server --server https://<SERVER>:6443
```
其中 `<SERVER>` 是 Server 的 IP 或有效 DNS,`<TOKEN>` 是可以在 `/var/lib/rancher/k3s/server/node-token` 中找到的 Server node-token。
有关安装 K3s 的更多信息,请参阅 [K3s 安装文档](https://docs.k3s.io/installation)。
如需查看集群,请运行以下命令:
```
kubectl cluster-info
kubectl get pods --all-namespaces
```
</TabItem>
<TabItem value="RKE2">
在每个节点上,运行 RKE2 安装脚本。确保你安装的 RKE2 版本受 [Rancher 支持](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/)。
```
curl -sfL https://get.rke2.io | INSTALL_RKE2_CHANNEL=v1.xx sh -
```
然后,你必须在 RKE2 systemd 服务上配置 HTTP 代理设置,让 RKE2 的 containerd 可以通过代理拉取镜像:
```
cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
HTTP_PROXY=http://${proxy_host}
HTTPS_PROXY=http://${proxy_host}"
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
EOF
```
接下来,按照 [RKE2 高可用性文档](https://docs.rke2.io/install/ha)在每个节点上创建 RKE2 配置文件。
之后启动并启用 `rke2-server` 服务:
```
systemctl enable rke2-server.service
systemctl start rke2-server.service
```
有关安装 RKE2 的更多信息,请参阅 [RKE2 文档](https://docs.rke2.io)。
如需查看集群,请运行以下命令:
```
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
alias kubectl=/var/lib/rancher/rke2/bin/kubectl
kubectl cluster-info
kubectl get pods --all-namespaces
```
</TabItem>
<TabItem value="RKE">
首先,你需要在所有三个 Linux 节点上安装 Docker 并设置 HTTP 代理。因此,你可以在这三个节点上执行以下步骤。
接下来配置 apt 以在安装包时使用这个代理。如果你使用的不是 Ubuntu,请相应调整步骤。
```
cat <<'EOF' | sudo tee /etc/apt/apt.conf.d/proxy.conf > /dev/null
Acquire::http::Proxy "http://${proxy_host}/";
Acquire::https::Proxy "http://${proxy_host}/";
EOF
```
安装 Docker:
```
curl -sL https://releases.rancher.com/install-docker/19.03.sh | sh
```
然后,确保你的当前用户能够在没有 sudo 的情况下访问 Docker Daemon:
```
sudo usermod -aG docker YOUR_USERNAME
```
配置 Docker Daemon 使用代理来拉取镜像:
```
sudo mkdir -p /etc/systemd/system/docker.service.d
cat <<'EOF' | sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf > /dev/null
[Service]
Environment="HTTP_PROXY=http://${proxy_host}"
Environment="HTTPS_PROXY=http://${proxy_host}"
Environment="NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16"
EOF
```
要应用配置,请重新启动 Docker Daemon:
```
sudo systemctl daemon-reload
sudo systemctl restart docker
```
#### 离线代理
你现在可以在配置的离线集群中配置主机驱动集群,以使用代理进行出站连接。
除了为代理服务器设置默认规则外,你还需要额外添加如下所示的规则,以从代理的 Rancher 环境中配置主机驱动集群。
根据你的设置配置文件路径,例如 `/etc/apt/apt.conf.d/proxy.conf`:
```
acl SSL_ports port 22
acl SSL_ports port 2376
acl Safe_ports port 22 # ssh
acl Safe_ports port 2376 # docker port
```
### 创建 RKE 集群
在能通过 SSH 访问 Linux 节点的主机上,你需要有几个命令行工具,来创建集群并与之交互:
* [RKE CLI binary](https://rancher.com/docs/rke/latest/en/installation/#download-the-rke-binary)
```
sudo curl -fsSL -o /usr/local/bin/rke https://github.com/rancher/rke/releases/download/v1.1.4/rke_linux-amd64
sudo chmod +x /usr/local/bin/rke
```
* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
```
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
```
接下来,创建一个描述 RKE 集群的 YAML 文件。确保节点的 IP 地址和 SSH 用户名是正确的。有关集群 YAML 的详情,请参见 [RKE 官方文档](https://rancher.com/docs/rke/latest/en/example-yamls/)。
```yml
nodes:
- address: 10.0.1.200
user: ubuntu
role: [controlplane,worker,etcd]
- address: 10.0.1.201
user: ubuntu
role: [controlplane,worker,etcd]
- address: 10.0.1.202
user: ubuntu
role: [controlplane,worker,etcd]
services:
etcd:
backup_config:
interval_hours: 12
retention: 6
```
之后,你可以通过运行以下命令来创建 Kubernetes 集群:
```
rke up --config rancher-cluster.yaml
```
RKE 会创建一个名为 `rancher-cluster.rkestate` 的状态文件。如果你需要更新或修改集群配置,或使用备份恢复集群,则需要使用该文件。RKE 还会创建一个 `kube_config_cluster.yaml` 文件,你可以使用该文件在本地使用 kubectl 或 Helm 等工具连接到远端的 Kubernetes 集群。请将这些文件保存在安全的位置,例如版本控制系统中。
如需查看集群,请运行以下命令:
```
export KUBECONFIG=kube_config_cluster.yaml
kubectl cluster-info
kubectl get pods --all-namespaces
```
你也可以验证你的外部负载均衡器是否工作,DNS 条目是否设置正确。如果你向其中之一发送请求,你会收到来自 Ingress Controller 的 HTTP 404 响应:
```
$ curl 10.0.1.100
default backend - 404
$ curl rancher.example.com
default backend - 404
```
### 保存你的文件
:::note 重要提示:
维护、排除问题和升级集群需要用到以下文件,请妥善保管这些文件:
:::
将以下文件的副本保存在安全位置:
- `rancher-cluster.yml`:RKE 集群配置文件。
- `kube_config_cluster.yml`:集群的 [Kubeconfig 文件](https://rancher.com/docs/rke/latest/en/kubeconfig/)。该文件包含可完全访问集群的凭证。
- `rancher-cluster.rkestate`:[Kubernetes 集群状态文件](https://rancher.com/docs/rke/latest/en/installation/#kubernetes-cluster-state)。此文件包含集群的当前状态,包括 RKE 配置和证书。
:::note
后两个文件名中的 `rancher-cluster` 部分取决于你命名 RKE 集群配置文件的方式。
:::
</TabItem>
</Tabs>
### 故障排除
参见[故障排除](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)页面。
### 后续操作
[安装 Rancher](install-rancher.md)
@@ -0,0 +1,104 @@
---
title: 3. 安装 Rancher
---
在前文的操作后,你已经有了一个运行的 RKE 集群,现在可以在其中安装 Rancher 了。出于安全考虑,所有到 Rancher 的流量都必须使用 TLS 加密。在本教程中,你将使用 [cert-manager](https://cert-manager.io/)自动颁发自签名证书。在实际使用情况下,你可使用 Let's Encrypt 或自己的证书。
### 安装 Helm CLI
在具有 kubeconfig 的主机上安装 [Helm](https://helm.sh/docs/intro/install/) CLI 以访问 Kubernetes 集群:
```
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod +x get_helm.sh
sudo ./get_helm.sh
```
### 安装 cert-manager
添加 cert-manager Helm 仓库:
```
helm repo add jetstack https://charts.jetstack.io
```
为 cert-manager 创建命名空间:
```
kubectl create namespace cert-manager
```
安装 cert-manager 的 CustomResourceDefinitions:
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
```
使用 Helm 安装 cert-manager。请注意,cert-manager 还需要你配置代理,以防它需要与 Let's Encrypt 或其他外部证书颁发商进行通信:
:::note
要查看自定义 cert-manager 安装的选项(包括集群使用 PodSecurityPolicies 的情况),请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
:::
```
helm upgrade --install cert-manager jetstack/cert-manager \
--namespace cert-manager --version v1.11.0 \
--set http_proxy=http://${proxy_host} \
--set https_proxy=http://${proxy_host} \
--set no_proxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
```
等待 cert-manager 完成启动:
```
kubectl rollout status deployment -n cert-manager cert-manager
kubectl rollout status deployment -n cert-manager cert-manager-webhook
```
### 安装 Rancher
接下来,你可以安装 Rancher 了。首先,添加 Helm 仓库:
```
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
```
创建命名空间:
```
kubectl create namespace cattle-system
```
然后使用 Helm 安装 Rancher:Rancher 也需要你配置代理,以便它可以与外部应用商店通信,或检索 Kubernetes 版本更新元数据:
```
helm upgrade --install rancher rancher-latest/rancher \
--namespace cattle-system \
--set hostname=rancher.example.com \
--set proxy=http://${proxy_host} \
--set noProxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
```
等待部署完成:
```
kubectl rollout status deployment -n cattle-system rancher
```
现在,你可以导航到 `https://rancher.example.com` 并开始使用 Rancher。
:::caution
如果你不想发送遥测数据,在首次登录时退出[遥测](../../../../faq/telemetry.md)。如果在离线安装的环境中让这个功能处于 active 状态,socket 可能无法打开。
:::
### 其他资源
以下资源可能对安装 Rancher 有帮助:
- [Rancher Helm Chart 选项](../../installation-references/helm-chart-options.md)
- [添加 TLS 密文](../../resources/add-tls-secrets.md)
- [Rancher Kubernetes 安装的故障排除](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)
@@ -0,0 +1,64 @@
---
title: '1. 配置基础设施'
---
在本节中,你将为 Rancher Management Server 配置底层基础设施,并使其通过 HTTP 代理访问互联网。
如需在高可用 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 节点
这些主机将通过 HTTP 代理连接到互联网。
请确保你的节点满足[操作系统,容器运行时,硬件和网络](../../../../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)。
:::note 重要提示:
安装后,请勿将此负载均衡(例如 `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)。
### 后续操作
[配置 Kubernetes 集群](install-kubernetes.md)
@@ -0,0 +1,90 @@
---
title: 证书故障排除
---
### 如何确定我的证书格式是否为 PEM?
你可以通过以下特征识别 PEM 格式:
- 文件开始的标头:
```
-----BEGIN CERTIFICATE-----
```
- 表头后跟一长串字符。
- 文件结束的页脚:
```
-----END CERTIFICATE-----
```
PEM 证书示例:
```
----BEGIN CERTIFICATE-----
MIIGVDCCBDygAwIBAgIJAMiIrEm29kRLMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
... more lines
VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
-----END CERTIFICATE-----
```
PEM 证书密钥示例:
```
-----BEGIN RSA PRIVATE KEY-----
MIIGVDCCBDygAwIBAgIJAMiIrEm29kRLMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
... more lines
VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
-----END RSA PRIVATE KEY-----
```
如果你的密钥与以下示例类似,请参见[将 PKCS8 证书密钥转换为 PKCS1](#将-pkcs8-证书密钥转换为-pkcs1)。
```
-----BEGIN PRIVATE KEY-----
MIIGVDCCBDygAwIBAgIJAMiIrEm29kRLMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
... more lines
VWQqljhfacYPgp8KJUJENQ9h5hZ2nSCrI+W00Jcw4QcEdCI8HL5wmg==
-----END PRIVATE KEY-----
```
### 将 PKCS8 证书密钥转换为 PKCS1
如果你使用的是 PKCS8 证书密钥文件,Rancher 将打印以下日志:
```
ListenConfigController cli-config [listener] failed with : failed to read private key: asn1: structure error: tags don't match (2 vs {class:0 tag:16 length:13 isCompound:true})
```
为了能正常工作,你需要运行以下命令,将密钥从 PKCS8 转换为 PKCS1:
```
openssl rsa -in key.pem -out convertedkey.pem
```
你可使用 `convertedkey.pem` 作为 Rancher 证书密钥文件。
### 添加中间证书的顺序是什么?
添加证书的顺序如下:
```
-----BEGIN CERTIFICATE-----
%YOUR_CERTIFICATE%
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
%YOUR_INTERMEDIATE_CERTIFICATE%
-----END CERTIFICATE-----
```
### 如何验证我的证书链?
你可使用 `openssl` 二进制文件来验证证书链。如果命令的输出以 `Verify return code: 0 (ok)` 结尾(参见以下示例),你的证书链是有效的。`ca.pem` 文件必须与你添加到 `rancher/rancher` 容器中的文件一致。
如果你使用由可信的 CA 签发的证书,可省略 `-CAfile` 参数。
命令:
```
openssl s_client -CAfile ca.pem -connect rancher.yourdomain.com:443
...
Verify return code: 0 (ok)
```
@@ -0,0 +1,91 @@
---
title: 回滚 Docker 安装的 Rancher
---
如果 Rancher 升级没有成功完成,你需要回滚到你在 [Docker 升级](upgrade-docker-installed-rancher.md)之前使用的 Rancher 设置。回滚可以恢复:
- 先前版本的 Rancher。
- 升级前创建的数据备份。
## 在你开始前
在回滚到先前 Rancher 版本的过程中,你将输入一系列命令。请按照你环境的实际情况替换占位符。占位符用尖括号和大写字母(如 `<EXAMPLE>`)表示。以下是带有占位符的命令示例:
```
docker pull rancher/rancher:<PRIOR_RANCHER_VERSION>
```
在此命令中,`<PRIOR_RANCHER_VERSION>` 是升级失败之前运行的 Rancher 版本,如 `v2.0.5`。
请交叉参考下方的图片和表格,了解获取此占位符数据的方法。在开始以下步骤之前,请先记下或复制此信息。
<sup>终端 <code>docker ps</code> 命令,显示如何找到 <code>&lt;PRIOR_RANCHER_VERSION&gt;</code> 和 <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>![占位符参考](/img/placeholder-ref-2.png)
| 占位符 | 示例 | 描述 |
| -------------------------- | -------------------------- | ------------------------------------------------------- |
| `<PRIOR_RANCHER_VERSION>` | `v2.0.5` | 升级前使用的 rancher/rancher 镜像。 |
| `<RANCHER_CONTAINER_NAME>` | `festive_mestorf` | 你的 Rancher 容器的名称。 |
| `<RANCHER_VERSION>` | `v2.0.5` | 备份对应的 Rancher 版本。 |
| `<DATE>` | `9-27-18` | 数据容器或备份的创建日期。 |
<br/>
可以通过远程连接登录到 Rancher Server 所在的主机并输入命令 `docker ps` 以查看正在运行的容器,从而获得 `<PRIOR_RANCHER_VERSION>` 和 `<RANCHER_CONTAINER_NAME>` 。你还可以运行 `docker ps -a` 命令查看停止了的容器。在创建备份期间,你随时可以运行这些命令来获得帮助。
## 回滚 Rancher
如果你在升级 Rancher 时遇到问题,你可拉取先前使用的镜像并恢复在升级前所做的备份,从而将 Rancher 回滚到之前的正常工作状态。
:::danger
回滚到先前的 Rancher 版本会破坏你在升级后对 Rancher 做出的所有更改。丢失的数据可能无法恢复。
:::
1. 使用远程终端连接,登录到运行 Rancher Server 的节点。
1. 拉取升级前运行的 Rancher 版本。把 `<PRIOR_RANCHER_VERSION>` 替换为该版本。
例如,如果升级之前运行的是 Rancher v2.0.5,请拉取 v2.0.5。
```
docker pull rancher/rancher:<PRIOR_RANCHER_VERSION>
```
1. 停止当前运行 Rancher Server 的容器。将 `<RANCHER_CONTAINER_NAME>` 替换为你的 Rancher 容器的名称:
```
docker stop <RANCHER_CONTAINER_NAME>
```
你可输入 `docker ps`获取 Rancher 容器的名称。
1. 将你在 [Docker 升级](upgrade-docker-installed-rancher.md)时创建的备份压缩包移动到 Rancher Server。切换到你将其移动到的目录。输入 `dir` 以确认它在该位置。
如果你遵循了我们在 [Docker 升级](upgrade-docker-installed-rancher.md)中推荐的命名方式,它的名称会与 `rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz` 类似。
1. 替换占位符来运行以下命令,将 `rancher-data` 容器中的数据替换为备份压缩包中的数据。不要忘记关闭引号。
```
docker run --volumes-from rancher-data \
-v $PWD:/backup busybox sh -c "rm /var/lib/rancher/* -rf \
&& tar zxvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz"
```
1. 将 `<PRIOR_RANCHER_VERSION>` 占位符指向数据容器,启动一个新的 Rancher Server 容器。
```
docker run -d --volumes-from rancher-data \
--restart=unless-stopped \
-p 80:80 -p 443:443 \
--privileged \
rancher/rancher:<PRIOR_RANCHER_VERSION>
```
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
:::danger
启动回滚后,即使回滚耗时比预期长,也 **_不要_** 停止回滚。如果你停止回滚,可能会导致之后的升级中出现数据库错误。
:::
1. 等待片刻,然后在浏览器中打开 Rancher。确认回滚成功并且你的数据已恢复。
**结果**:Rancher 回滚到升级前的版本和数据状态。
@@ -0,0 +1,393 @@
---
title: 升级 Docker 安装的 Rancher
---
本文介绍如何升级通过 Docker 安装的 Rancher Server。
:::caution
**生产环境不支持 Docker 安装**。这些说明仅适用于测试和开发。如果你已经在生产环境中部署了 Docker 安装并且需要升级到新的 Rancher 版本,我们建议你在升级前先[迁移到 Helm Chart 安装](../../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
:::
## 先决条件
- 在 Rancher 文档中**检查[已知升级问题](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#已知升级问题)**,了解升级 Rancher 时最需要注意的问题。你可以在 [GitHub](https://github.com/rancher/rancher/releases) 发布说明以及 [Rancher 论坛](https://forums.rancher.com/c/announcements/12)中找到每个 Rancher 版本的已知问题。不支持升级或升级到 [rancher-alpha 仓库](../../resources/choose-a-rancher-version.md#helm-chart-仓库)中的任何 Chart。
- **[仅适用于离线安装](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md):为新的 Rancher Server 版本收集和推送镜像**。按照指南为你想要升级的目标 Rancher 版本[推送镜像到私有镜像仓库](../air-gapped-helm-cli-install/publish-images.md)。
## 占位符
在升级过程中,你将输入一系列命令。请按照你环境的实际情况替换占位符。占位符用尖括号和大写字母(如 `<EXAMPLE>`)表示。
以下是带有占位符的命令**示例**:
```
docker stop <RANCHER_CONTAINER_NAME>
```
在此命令中,`<RANCHER_CONTAINER_NAME>` 是你的 Rancher 容器的名称。
## 获取升级命令的数据
要获取替换占位符的数据,请运行:
```
docker ps
```
在开始升级之前记下或复制此信息。
<sup>终端 <code>docker ps</code> 命令,显示如何找到 <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> 和 <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
![占位符参考](/img/placeholder-ref.png)
| 占位符 | 示例 | 描述 |
| -------------------------- | -------------------------- | --------------------------------------------------------- |
| `<RANCHER_CONTAINER_TAG>` | `v2.1.3` | 首次安装拉取的 rancher/rancher 镜像。 |
| `<RANCHER_CONTAINER_NAME>` | `festive_mestorf` | 你的 Rancher 容器的名称。 |
| `<RANCHER_VERSION>` | `v2.1.3` | 你为其创建备份的 Rancher 版本。 |
| `<DATE>` | `2018-12-19` | 数据容器或备份的创建日期。 |
<br/>
可以通过远程连接登录到 Rancher Server 所在的主机并输入命令 `docker ps` 以查看正在运行的容器,从而获得 `<RANCHER_CONTAINER_TAG>` 和 `<RANCHER_CONTAINER_NAME>`。你还可以运行 `docker ps -a` 命令查看停止了的容器。在创建备份期间,你随时可以运行这些命令来获得帮助。
## 升级
在升级期间,你可以为当前 Rancher 容器创建数据的副本及备份,以确保可以在升级出现问题时可以进行回滚。然后,你可使用现有数据将新版本的 Rancher 部署到新容器中。
### 1. 创建 Rancher Server 容器的数据副本
1. 使用远程终端连接,登录到运行 Rancher Server 的节点。
1. 停止正在运行 Rancher Server 的容器。将 `<RANCHER_CONTAINER_NAME>` 替换为你的 Rancher 容器的名称:
```
docker stop <RANCHER_CONTAINER_NAME>
```
1. <a id="backup"></a>运行以下命令,从刚才停止的 Rancher 容器创建一个数据容器。请替换命令中的占位符:
```
docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data rancher/rancher:<RANCHER_CONTAINER_TAG>
```
### 2. 创建备份压缩包
1. <a id="tarball"></a>从你刚刚创建的数据容器(<code>rancher-data</code>)中,创建一个备份 tar 包(<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>)。
如果升级期间出现问题,此压缩包可以用作回滚点。替换占位符来运行以下命令。
```
docker run --volumes-from rancher-data -v "$PWD:/backup" --rm busybox tar zcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
```
**步骤结果**:你输入此命令时,会运行一系列命令。
1. 输入 `ls` 命令,确认备份压缩包已创建成功。压缩包的名称格式类似 `rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`。
```
[rancher@ip-10-0-0-50 ~]$ ls
rancher-data-backup-v2.1.3-20181219.tar.gz
```
1. 将备份压缩包移动到 Rancher Server 外的安全位置。
### 3. 拉取新的 Docker 镜像
拉取你需要升级到的 Rancher 版本镜像。
| 占位符 | 描述 |
------------|-------------
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
```
docker pull rancher/rancher:<RANCHER_VERSION_TAG>
```
### 4. 启动新的 Rancher Server 容器
使用 `rancher-data` 容器中的数据启动一个新的 Rancher Server 容器。记住要传入启动原始容器时使用的所有环境变量。
:::danger
启动升级后,即使升级耗时比预期长,也 **_不要_** 停止升级。如果你停止升级,可能会导致之后的升级中出现数据库迁移错误。
:::
如果你使用代理,请参见 [HTTP 代理配置](../../../../reference-guides/single-node-rancher-in-docker/http-proxy-configuration.md)。
如果你配置了自定义 CA 根证书来访问服务,请参见[自定义 CA 根证书](../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#自定义-ca-证书)。
如果你要记录所有 Rancher API 的事务,请参见 [API 审计](../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-审计日志)。
如需查看启动新 Rancher Server 容器时使用的命令,从以下的选项中进行选择:
- Docker 升级
- 离线安装的 Docker 升级
<Tabs>
<TabItem value="Docker 升级">
选择你安装 Rancher Server 时用的选项
#### 选项 A:使用 Rancher 默认的自签名证书
<details id="option-a">
<summary>单击展开</summary>
如果你使用 Rancher 生成的自签名证书,则将 `--volumes-from rancher-data` 添加到你启动原始 Rancher Server 容器的命令中。
| 占位符 | 描述 |
------------|-------------
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
```
docker run -d --volumes-from rancher-data \
--restart=unless-stopped \
-p 80:80 -p 443:443 \
--privileged \
rancher/rancher:<RANCHER_VERSION_TAG>
```
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
</details>
#### 选项 B:使用你自己的证书 - 自签名
<details id="option-b">
<summary>单击展开</summary>
如果你选择使用自己的自签名证书,则在启动原始 Rancher Server 容器的命令中添加 `--volumes-from rancher-data`。此外,你需要能够访问你原始安装时使用的证书。
:::note 证书要求提示:
证书文件的格式必须是 PEM。在你的证书文件中,包括链中的所有中间证书。你需要对你的证书进行排序,把你的证书放在最前面,后面跟着中间证书。
:::
| 占位符 | 描述 |
------------|-------------
| `<CERT_DIRECTORY>` | 包含证书文件的目录的路径。 |
| `<FULL_CHAIN.pem>` | 完整证书链的路径。 |
| `<PRIVATE_KEY.pem>` | 证书私钥的路径。 |
| `<CA_CERTS.pem>` | CA 证书的路径。 |
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
```
docker run -d --volumes-from rancher-data \
--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 \
--privileged \
rancher/rancher:<RANCHER_VERSION_TAG>
```
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
</details>
#### 选项 C:使用你自己的证书 - 可信 CA 签名的证书
<details id="option-c">
<summary>单击展开</summary>
如果你选择使用可信 CA 签名的证书,则在启动原始 Rancher Server 容器的命令中添加 `--volumes-from rancher-data`。此外,你需要能够访问你原始安装时使用的证书。注意要使用 `--no-cacerts` 作为容器的参数,以禁用 Rancher 生成的默认 CA 证书。
:::note 证书要求提示:
证书文件的格式必须是 PEM。在你的证书文件中,包括可信 CA 提供的所有中间证书。你需要对你的证书进行排序,把你的证书放在最前面,后面跟着中间证书。如需查看示例,请参见[证书故障排除](certificate-troubleshooting.md)。
:::
| 占位符 | 描述 |
------------|-------------
| `<CERT_DIRECTORY>` | 包含证书文件的目录的路径。 |
| `<FULL_CHAIN.pem>` | 完整证书链的路径。 |
| `<PRIVATE_KEY.pem>` | 证书私钥的路径。 |
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
```
docker run -d --volumes-from rancher-data \
--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 \
--privileged \
rancher/rancher:<RANCHER_VERSION_TAG> \
--no-cacerts
```
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
</details>
#### 选项 D:Let's Encrypt 证书
<details id="option-d">
<summary>单击展开</summary>
:::caution
Let's Encrypt 对新证书请求有频率限制。因此,请限制创建或销毁容器的频率。详情请参见 [Let's Encrypt 官方文档 - 频率限制](https://letsencrypt.org/docs/rate-limits/)。
:::
如果你选择使用 [Let's Encrypt](https://letsencrypt.org/) 证书,则在启动原始 Rancher Server 容器的命令中添加 `--volumes-from rancher-data`,并且提供最初安装 Rancher 时使用的域名。
:::note 证书要求提示:
- 在 DNS 中创建一条记录,将 Linux 主机 IP 地址绑定到要用于访问 Rancher 的主机名(例如,`rancher.mydomain.com`)。
- 在 Linux 主机上打开 `TCP/80` 端口。Let's Encrypt 的 HTTP-01 质询可以来自任何源 IP 地址,因此端口 `TCP/80` 必须开放开所有 IP 地址。
:::
| 占位符 | 描述 |
------------|-------------
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
| `<YOUR.DNS.NAME>` | 你最初使用的域名 |
```
docker run -d --volumes-from rancher-data \
--restart=unless-stopped \
-p 80:80 -p 443:443 \
--privileged \
rancher/rancher:<RANCHER_VERSION_TAG> \
--acme-domain <YOUR.DNS.NAME>
```
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
</details>
</TabItem>
<TabItem value="Docker 离线升级">
出于安全考虑,使用 Rancher 时请使用 SSL(Secure Sockets Layer)。SSL 保护所有 Rancher 网络通信(如登录和与集群交互)的安全。
启动新的 Rancher Server 容器时,从以下的选项中进行选择:
#### 选项 A:使用 Rancher 默认的自签名证书
<details id="option-a">
<summary>单击展开</summary>
如果你使用 Rancher 生成的自签名证书,则将 `--volumes-from rancher-data` 添加到你启动原始 Rancher Server 容器的命令中。
| 占位符 | 描述 |
------------|-------------
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 私有镜像仓库的 URL 和端口。 |
| `<RANCHER_VERSION_TAG>` | 你想要升级到的 [Rancher 版本](../../installation-references/helm-chart-options.md)的版本标签。 |
```
docker run -d --volumes-from rancher-data \
--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>
```
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
</details>
#### 选项 B:使用你自己的证书 - 自签名
<details id="option-b">
<summary>单击展开</summary>
如果你选择使用自己的自签名证书,则在启动原始 Rancher Server 容器的命令中添加 `--volumes-from rancher-data`。此外,你需要能够访问你原始安装时使用的证书。
:::note 证书要求提示:
证书文件的格式必须是 PEM。在你的证书文件中,包括链中的所有中间证书。你需要对你的证书进行排序,把你的证书放在最前面,后面跟着中间证书。如需查看示例,请参见[证书故障排除](certificate-troubleshooting.md)。
:::
| 占位符 | 描述 |
------------|-------------
| `<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)的版本标签。 |
```
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>
```
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
</details>
#### 选项 C:使用你自己的证书 - 可信 CA 签名的证书
<details id="option-c">
<summary>单击展开</summary>
如果你选择使用可信 CA 签名的证书,则在启动原始 Rancher Server 容器的命令中添加 `--volumes-from rancher-data`。此外,你需要能够访问你原始安装时使用的证书。
:::note 证书要求提示:
证书文件的格式必须是 PEM。在你的证书文件中,包括可信 CA 提供的所有中间证书。你需要对你的证书进行排序,把你的证书放在最前面,后面跟着中间证书。如需查看示例,请参见[证书故障排除](certificate-troubleshooting.md)。
:::
| 占位符 | 描述 |
------------|-------------
| `<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 证书。
:::
```
docker run -d --volumes-from rancher-data \
--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>
```
特权访问是[必须](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)的。
</details>
</TabItem>
</Tabs>
**结果**:你已升级 Rancher。已升级 Server 中的数据将保存在 `rancher-data` 容器中,用于将来的升级。
### 5. 验证升级
登录到 Rancher。通过检查浏览器左下角的版本号,确认升级是否成功。
:::note 升级后下游集群出现网络问题?
请参见[恢复集群网络](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。
:::
### 6. 清理旧的 Rancher Server 容器
移除旧的 Rancher Server 容器。如果你仅停止了旧的 Rancher Server 容器,但没有移除它,该容器还可能在服务器下次重启后重新启动。
## 回滚
如果升级没有成功完成,你可以将 Rancher Server 及其数据回滚到上次的健康状态。详情请参见 [Docker 回滚](roll-back-docker-installed-rancher.md)。
@@ -0,0 +1,45 @@
---
title: 添加 TLS 密文
---
我们使用证书和密钥将 `cattle-system` 命名空间中的 `tls-rancher-ingress` 密文配置好后,Kubernetes 会为 Rancher 创建对象和服务。
将服务器证书和所需的所有中间证书合并到名为 `tls.crt`的文件中。将证书密钥复制到名为 `tls.key` 的文件中。
例如,[acme.sh](https://acme.sh) 在 `fullchain.cer` 文件中提供服务器证书和 CA 链。
请将 `fullchain.cer` 命名为 `tls.crt`,将证书密钥文件命名为 `tls.key`。
使用 `kubectl` 创建 `tls` 类型的密文。
```
kubectl -n cattle-system create secret tls tls-rancher-ingress \
--cert=tls.crt \
--key=tls.key
```
:::note
如需替换证书,你可以运行 `kubectl -n cattle-system delete secret tls-rancher-ingress` 来删除 `tls-rancher-ingress` 密文,然后运行上方命令来添加新的密文。如果你使用的是私有 CA 签名证书,仅当新证书与当前证书是由同一个 CA 签发的,才可以替换。
:::
## 使用私有 CA 签名证书
如果你使用的是私有 CA,Rancher 需要私有 CA 的根证书或证书链的副本,Rancher Agent 使用它来校验与 Server 的连接。
创建一个名为 `cacerts.pem` 的文件,该文件仅包含私有 CA 的根 CA 证书或证书链,并使用 `kubectl` 在 `cattle-system` 命名空间中创建 `tls-ca` Secret。
```
kubectl -n cattle-system create secret generic tls-ca \
--from-file=cacerts.pem=./cacerts.pem
```
:::note
Rancher 启动时会检索配置的 `tls-ca` 密文。如果 Rancher 在运行中,更新的 CA 会在新的 Rancher Pod 启动后生效。
:::
## 更新私有 CA 证书
按照[步骤](update-rancher-certificate.md)更新 [Rancher 高可用 Kubernetes 安装](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md)中的 Ingress,或从默认自签名证书切换到自定义证书。
@@ -0,0 +1,27 @@
---
title: 引导密码
---
Rancher 首次启动时,会为第一个管理员用户随机生成一个密码。当管理员首次登录 Rancher 时,用于获取引导密码(Bootstrap)的命令会在 UI 上显示。管理员需要运行命令并使用引导密码登录。然后 Rancher 会让管理员重置密码。
如果你在安装过程中没有使用变量来设置引导密码,则会随机生成引导密码。如需了解使用变量设置引导密码的详情,请参见下文。
### 在 Helm 安装中指定引导密码
Helm 安装的情况下,你可以使用 `.Values.bootstrapPassword` 在 Helm Chart 值中指定引导密码变量。
密码将存储在 Kubernetes 密文中。安装 Rancher 后,如何使用 kubectl 获取密码的说明将会在 UI 中显示:
```
kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
```
### 在 Docker 安装中指定引导密码
如果 Rancher 是使用 Docker 安装的,你可以通过在 Docker 安装命令中传递 `-e CATTLE_BOOTSTRAP_PASSWORD=password` 来指定引导密码。
密码将存储在 Docker 容器日志中。安装 Rancher 后,如何使用 Docker 容器 ID 获取密码的说明将会在 UI 中显示:
```
docker logs container-id 2>&1 | grep "Bootstrap Password:"
```
@@ -0,0 +1,118 @@
---
title: 选择 Rancher 版本
---
本节介绍如何选择 Rancher 版本。
在我们推荐用于生产环境的 Rancher 高可用安装中,Rancher Server 是通过 Kubernetes 集群上的 **Helm Chart** 安装的。请参见 [Helm 版本要求](helm-version-requirements.md)选择 Helm 版本来安装 Rancher。
如果你在开发和测试中使用 Docker 来安装 Rancher,你需要把 Rancher 作为一个 **Docker 镜像**来安装。
<Tabs>
<TabItem value="Helm Charts">
如果 Rancher Server 是[安装在 Kubernetes 集群上](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md)的,Rancher Server 的安装,升级和回滚中,都是使用 Kubernetes 集群上的 Helm Chart 来安装 Rancher 的。因此,在准备安装或升级 Rancher 高可用时,必须添加包含用于安装 Rancher 的 Chart 的 Helm Chart 仓库。
请参见 [Helm 版本要求](helm-version-requirements.md)选择 Helm 版本来安装 Rancher。
### Helm Chart 仓库
Rancher 提供几个可选的 Helm Chart 仓库供你选择。最新版或稳定版的 Helm Chart 仓库与用于 Docker 安装中的 Docker 标签对应。因此,`rancher-latest` 仓库包含所有标记为 `rancher/rancher:latest` 的 Rancher 版本 Chart。当 Rancher 版本升级到 `rancher/rancher:stable`,它会被添加到 `rancher-stable` 仓库中。
| 类型 | 添加仓库的命令 | 仓库描述 |
| -------------- | ------------ | ----------------- |
| rancher-latest | `helm repo add rancher-latest https://releases.rancher.com/server-charts/latest` | 添加最新版本的 Rancher 的 Helm Chart 仓库。建议使用此仓库来测试新版本的 Rancher。 |
| rancher-stable | `helm repo add rancher-stable https://releases.rancher.com/server-charts/stable` | 添加较旧的,稳定的版本的 Rancher 的 Helm Chart 仓库。建议在生产环境中使用此仓库。 |
| rancher-alpha | `helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha` | 添加 alpha 版本的 Rancher 的 Helm Chart 仓库,以预览即将发布的版本。不建议在生产环境中使用这些版本。无论是什么仓库,均不支持 _升级_ 或 _升级到_ rancher-alpha 仓库中的任何 Chart。 |
了解何时选择这些仓库,请参见[切换到不同 Helm Chart 仓库](#切换到不同-helm-chart-仓库)。
:::note
`rancher-stable` 仓库中的所有 Chart 都与 `stable` 标记的 Rancher 版本对应。
:::
### Helm Chart 版本
Rancher Helm Chart 版本与 Rancher 版本(即 `appVersion`)对应。添加仓库后,你可以运行以下命令搜索可用版本:<br/>
&nbsp;&nbsp;&nbsp;&nbsp;`helm search repo --versions`
如果你有多个仓库,你可指定仓库名称,即:`helm search repo rancher-stable/rancher --versions` <br/>
详情请访问 https://helm.sh/docs/helm/helm_search_repo/
要获取所选仓库的指定版本,参见如下示例指定 `--version` 参数:<br/>
&nbsp;&nbsp;&nbsp;&nbsp;`helm fetch rancher-stable/rancher --version=2.4.8`
### 切换到不同 Helm Chart 仓库
安装 Rancher 后,如果想修改安装 Rancher 的 Helm Chart 仓库,按照以下步骤操作。
:::note
由于 rancher-alpha 仓库只包含 alpha 版本 Chart,因此不支持从 rancher alpha 仓库切换到 rancher-stable 或 rancher-latest 仓库以进行升级。
:::
- 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 版之间升级。
1. 列出当前 Helm Chart 仓库。
```plain
helm repo list
NAME URL
stable https://charts.helm.sh/stable
rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
```
2. 删除包含安装 Rancher 时用的 Chart 的 Helm Chart 仓库。是 `rancher-stable` 或 `rancher-latest` 取决于你初始安装时的选择。
```plain
helm repo remove rancher-<CHART_REPO>
```
3. 添加你要用于安装 Rancher 的 Helm Chart 仓库。
```plain
helm repo add rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
```
4. 按照以下步骤,从新的 Helm Chart 仓库[升级 Rancher](../install-upgrade-on-a-kubernetes-cluster/upgrades.md)。
</TabItem>
<TabItem value="Docker 镜像">
在执行 [Docker 安装](../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md)、升级或回滚时,你可以使用 _tags_ 来安装特定版本的 Rancher。
### Server 标签
Rancher Server 以 Docker 镜像的形式分发并附有标签。你可以在输入命令部署 Rancher 时指定标签。请记住,如果你指定了标签,但是没有指定版本(如 `latest` 或 `stable`),你必须显式拉取该镜像标签的新版本。否则,将使用缓存在主机上的镜像。
| 标签 | 描述 |
| -------------------------- | ------ |
| `rancher/rancher:latest` | 最新的开发版本。这些版本通过了我们的 CI 自动化验证。不推荐在生产环境使用这些版本。 |
| `rancher/rancher:stable` | 最新的稳定版本。推荐将此标签用于生产环境。 |
| `rancher/rancher:<v2.X.X>` | 你可以使用以前版本中的标签来指定要安装的 Rancher 版本。访问 DockerHub 查看可用的版本。 |
:::note
- `master` 和带有 `-rc` 或其他后缀的标签是供 Rancher 测试团队验证用的。这些标签不受官方支持,因此请不要使用这些标签。
- 安装 alpha 版本进行预览:使用我们的[公告页面](https://forums.rancher.com/c/announcements)中列出的 alpha 标签(例如,`v2.2.0-alpha1`)进行安装。不支持升级或升级到 Alpha 版本。
:::
</TabItem>
</Tabs>
@@ -0,0 +1,24 @@
---
title: 自定义 CA 根证书
---
如果你在内部生产环境使用 Rancher,且不打算公开暴露应用,你可以使用使用私有 CA 颁发的证书。
Rancher 可能会访问配置了自定义/内部 CA 根证书(也称为自签名证书)的服务。如果 Rancher 无法验证服务的证书,则会显示错误信息 `x509: certificate signed by unknown authority`。
如需验证证书,你需要把 CA 根证书添加到 Rancher。由于 Rancher 是用 Go 编写的,我们可以使用环境变量 `SSL_CERT_DIR` 指向容器中 CA 根证书所在的目录。启动 Rancher 容器时,可以使用 Docker 卷选项(`-v host-source-directory:container-destination-directory`)来挂载 CA 根证书目录。
Rancher 可以访问的服务示例:
- 应用商店
- 验证提供程序
- 使用 Node Driver 访问托管/云 API
## 使用自定义 CA 证书安装
有关启动挂载了私有 CA 证书的 Rancher 容器的详情,请参见安装文档:
- [Docker 安装的自定义 CA 证书选项](../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#自定义-ca-证书)
- [Kubernetes 安装的其他受信 CA 选项](../installation-references/helm-chart-options.md#额外的授信-ca)
@@ -0,0 +1,12 @@
---
title: Helm 版本要求
---
本文介绍 Helm 的要求。Helm 是用于把 Rancher 安装在高可用 Kubernetes 集群上的工具。
> 我们已针对 Helm 3 更新了安装指南。如果你使用 Helm 2 进行安装,请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。[本文](/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2.md)提供了较早的使用 Helm 2 的 Rancher 高可用安装指南的副本。如果你如果无法升级到 Helm 3,可以使用这个说明安装。
- 如需安装或升级 Rancher 2.5,请使用 Helm 3.2.x 或更高版本。
- Kubernetes 1.16 要求 Helm 2.16.0 或更高版本。如果使用的是默认 Kubernetes 版本,请参见[发行说明](https://github.com/rancher/rke/releases)获取所使用的 RKE 版本。
- 请不要使用 Helm 2.15.0,因为这个版本有转换/比较数字的问题。
- 请不要使用 Helm 2.12.0,因为该版本有 `cert-manager` 的兼容问题。
@@ -0,0 +1,13 @@
---
title: 离线安装中设置本地 System Charts
---
[Charts](https://github.com/rancher/charts) 仓库包含 Monitoring、Logging、告警和 Istio 等功能所需的所有 Helm 目录项。
在 Rancher 的离线安装中,你需要配置 Rancher 以使用 System Charts 的本地副本。本节介绍如何通过 CLI 标志使用本地 System Charts。
## 使用本地 System Charts
`system-charts` 的一个本地副本已经打包到 `rancher/rancher` 容器中。为了在离线安装中使用这些功能,你需要使用额外的环境变量 `CATTLE_SYSTEM_CATALOG=bundled` 来运行 Rancher 安装命令,该环境变量告诉 Rancher 使用 Chart 的本地副本,而不是尝试从 GitHub 获取 Chart。
带有 `system-charts` 的 Rancher 安装命令示例包含在 Docker 和 Helm 的[离线安装说明](../../../pages-for-subheaders/air-gapped-helm-cli-install.md)中。
@@ -0,0 +1,263 @@
---
title: 更新 Rancher 证书
---
## 更新私有 CA 证书
按照以下步骤轮换[安装在 Kubernetes 集群上](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md)、由 Rancher 使用的 SSL 证书和私有 CA,或转用由私有 CA 签发的 SSL 证书。
步骤概述:
1. 使用新证书和私钥创建或更新 `tls-rancher-ingress` Kubernetes Secret 对象。
1. 使用根 CA 证书创建或更新 `tls-ca` Kubernetes Secret 对象(仅在使用私有 CA 时需要)。
1. 使用 Helm CLI 更新 Rancher 安装。
1. 重新配置 Rancher Agent 以信任新的 CA 证书。
1. 选择 Fleet 集群的强制更新,来将 fleet-agent 连接到 Rancher。
各个步骤的详细说明如下。
### 1. 创建/更新证书 Secret 对象
首先,将服务器证书和所有中间证书合并到名为 `tls.crt` 的文件,并在名为 `tls.key` 的文件中提供相应的证书密钥。
使用以下命令在 Rancher(本地)管理集群中创建 `tls-rancher-ingress` Secret 对象:
```bash
kubectl -n cattle-system create secret tls tls-rancher-ingress \
--cert=tls.crt \
--key=tls.key
```
或者,更新现有的 `tls-rancher-ingress` Secret:
```bash
kubectl -n cattle-system create secret tls tls-rancher-ingress \
--cert=tls.crt \
--key=tls.key \
--dry-run --save-config -o yaml | kubectl apply -f -
```
### 2. 创建/更新证书 CA Secret 对象
如果新证书由私有 CA 签发的,你需要将相应的根 CA 证书复制到名为 `cacerts.pem` 的文件中,并创建或更新 `cattle-system` 命名空间中的 `tls-ca` Secret。如果证书由中间 CA 签名,则 `cacerts.pem` 必须按顺序同时包含中间 CA 证书和根 CA 证书。
创建初始 `tls-ca` Secret:
```bash
kubectl -n cattle-system create secret generic tls-ca \
--from-file=cacerts.pem
```
要更新现有的 `tls-ca` Secret:
```bash
kubectl -n cattle-system create secret generic tls-ca \
--from-file=cacerts.pem \
--dry-run --save-config -o yaml | kubectl apply -f -
```
### 3. 重新配置 Rancher 部署
如果证书源保持不变(例如,`secret`),请按照步骤 3a 中的步骤操作。
但是,如果证书源发生变化(例如,`letsEncrypt` 更改为 `secret`),请按照 3b 中的步骤操作。
#### 3a. 重新部署 Rancher pod
当证书源保持不变,但需要更新 CA 证书时,需要执行此步骤。
在这种情况下,由于 `tls-ca` secret 在启动时由 Rancher pod 读取,因此你需要重新部署 Rancher pod。
你可以运行以下命令重新部署 Rancher pod:
```bash
kubectl rollout restart deploy/rancher -n cattle-system
```
修改完成后,访问 `https://<RANCHER_SERVER_URL>/v3/settings/cacerts`,验证该值是否与先前写入 `tls-ca` Secret 中的 CA 证书匹配。在所有重新部署的 Rancher pod 启动之前,CA `cacerts` 值可能不会更新。
#### 3b. 更新 Rancher 的 Helm 值
如果证书源有更改,则需要执行此步骤。如果你的 Rancher 之前使用默认的自签名证书 (`ingress.tls.source=rancher`) 或 Let's Encrypt (`ingress.tls.source=letsEncrypt`) 证书,并且现在正在使用由私有 CA (`ingress.tls.source=secret`) 签名的证书。
以下步骤更新了 Rancher Chart 的 Helm 值,因此 Rancher pod 和 ingress 会使用在步骤 1 和 2 中创建的新私有 CA 证书。
1. 调整初始安装期间使用的值,将当前值存储为:
```bash
helm get values rancher -n cattle-system -o yaml > values.yaml
```
1. 检索当前部署的 Rancher Chart 的版本字符串:
```bash
helm ls -n cattle-system
```
1. 更新 `values.yaml` 文件中的当前 Helm 值以包含下方内容:
```yaml
ingress:
tls:
source: secret
privateCA: true
```
:::note 重要:
由于证书由私有 CA 签发,因此确保在 `values.yaml` 文件中设置了 [`privateCA: true`](../installation-references/helm-chart-options.md#常用选项) 是非常重要的。
:::
1. 使用 `values.yaml` 文件和当前 Chart 版本升级 Helm 应用程序实例。版本必须匹配以防止 Rancher 升级。
```bash
helm upgrade rancher rancher-stable/rancher \
--namespace cattle-system \
-f values.yaml \
--version <DEPLOYED_RANCHER_VERSION>
```
修改完成后,访问 `https://<RANCHER_SERVER_URL>/v3/settings/cacerts`,验证该值是否与先前写入 `tls-ca` Secret 中的 CA 证书匹配。在所有 Rancher pod 启动之前,CA `cacerts` 值可能不会更新。
### 4. 重新配置 Rancher Agent 以信任私有 CA
本节介绍了重新配置 Rancher Agent 以信任私有 CA 的三种方法。如果你的实际情况符合以下任意一个条件,请执行此步骤:
- Rancher 在先前的配置中使用了 Rancher 自签名证书 (`ingress.tls.source=rancher`) 或 Let's Encrypt 证书 (`ingress.tls.source=letsEncrypt`)。
- 该证书由不同的私有 CA 签发
#### 为什么要执行这一步骤?
如果 Rancher 配置了私有 CA 签名的证书时,CA 证书链将受到 Rancher agent 容器的信任。Agent 会对下载证书的校验和及 `CATTLE_CA_CHECKSUM` 环境变量进行比较。换言之,如果 Rancher 使用的私有 CA 证书发生变化,环境变量 `CATTLE_CA_CHECKSUM` 必须相应更新。
#### 可使用的方法
- 方法 1(最简单的方法):在轮换证书后将所有集群连接到 Rancher。适用于更新或重新部署 Rancher 部署(步骤 3)后立即执行的情况。
- 方法 2:适用于集群与 Rancher 失去连接,但所有集群都启用了 [Authorized Cluster Endpoint](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md) (ACE) 的情况。
- 方法 3:如果方法 1 和 2 不可行,则可使用方法 3 进行回退。
#### 方法 1:强制重新部署 Rancher Agent
对于每个下游集群,使用 Rancher(本地)管理集群的 Kubeconfig 文件运行以下命令。
```bash
kubectl annotate clusters.management.cattle.io <CLUSTER_ID> io.cattle.agent.force.deploy=true
```
:::note
找到下游集群的集群 ID (c-xxxxx)。你可以在 Rancher UI 的**集群管理**中查看集群时在浏览器 URL 中找到 ID。
:::
此命令将使 Agent 清单重新应用新证书的校验和。
#### 方法二:手动更新校验和环境变量
将 `CATTLE_CA_CHECKSUM` 环境变量更新为匹配新 CA 证书校验和的值,从而手动为 Agent Kubernetes 对象打上补丁。通过以下操作生成新的校验和:
```bash
curl -k -s -fL <RANCHER_SERVER_URL>/v3/settings/cacerts | jq -r .value | sha256sum | awk '{print $1}'
```
为每个下游集群使用 Kubeconfig 更新两个 Agent 部署的环境变量。如果集群启用了 [ACE](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md),你可以[调整 kubectl 上下文](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#直接使用下游集群进行身份验证),从而直接连接到下游集群。
```bash
kubectl edit -n cattle-system ds/cattle-node-agent
kubectl edit -n cattle-system deployment/cattle-cluster-agent
```
#### 方法三:手动重新部署 Rancher agent
该方法通过在每个下游集群的 control plane 节点上运行一组命令,从而重新应用 Rancher agent。
对每个下游集群重复以下步骤:
1. 检索 agent 注册 kubectl 命令:
1. 找到下游集群的集群 ID (c-xxxxx)。你可以在 Rancher UI 的**集群管理**中查看集群时在浏览器 URL 中找到 ID。
1. 将 Rancher Server URL 和集群 ID 添加到以下 URL:`https://<RANCHER_SERVER_URL>/v3/clusterregistrationtokens?clusterId=<CLUSTER_ID>`。
1. 复制 `insecureCommand` 字段中的命令,使用此命令是因为未使用私有 CA。
2. 使用以下其中一种方法,使用 kubeconfig 为下游集群运行上一步中的 kubectl 命令:
1. 如果集群启用了 [ACE](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint.md),你可以[调整上下文](../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#直接使用下游集群进行身份验证),从而直接连接到下游集群。
1. 或者,SSH 到 control plane 节点:
- RKE:使用[此处文档中的步骤](https://github.com/rancherlabs/support-tools/tree/master/how-to-retrieve-kubeconfig-from-custom-cluster)生成 kubeconfig
- RKE2/K3s:使用安装时填充的 kubeconfig
### 5. 强制更新 Fleet 集群,从而将 fleet-agent 重新连接到 Rancher
在 Rancher UI 的[持续交付](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#在-rancher-ui-中访问-fleet)中,为集群选择“强制更新”,来允许下游集群中的 fleet-agent 成功连接到 Rancher。
#### 为什么要执行这一步骤?
Rancher 管理的集群中的 Fleet agent 存储了用于连接到 Rancher 的 kubeconfig。kubeconfig 包含一个 `certificate-authority-data` 字段,该字段包含 Rancher 使用的证书的 CA。更改 CA 时,你需要更新此块来允许 fleet-agent 信任 Rancher 使用的证书。
## 将私有 CA 证书更改为公共证书
按照以下步骤执行与上面相反的操作,将私有 CA 颁发的证书更改为公共或自签名 CA。
### 1. 创建/更新证书 Secret 对象
首先,将服务器证书和所有中间证书合并到名为 `tls.crt` 的文件,并在名为 `tls.key` 的文件中提供相应的证书密钥。
使用以下命令在 Rancher(本地)管理集群中创建 `tls-rancher-ingress` Secret 对象:
```bash
kubectl -n cattle-system create secret tls tls-rancher-ingress \
--cert=tls.crt \
--key=tls.key
```
或者,更新现有的 `tls-rancher-ingress` Secret:
```bash
kubectl -n cattle-system create secret tls tls-rancher-ingress \
--cert=tls.crt \
--key=tls.key \
--dry-run --save-config -o yaml | kubectl apply -f -
```
### 2. 删除 CA 证书 Secret 对象
你需要删除 `cattle-system` 命名空间中的 `tls-ca secret`(不再需要它)。如果需要,你还可以选择保存 `tls-ca` secret 的副本。
要保存现有的 `tls-ca` Secret:
```bash
kubectl -n cattle-system get secret tls-ca -o yaml > tls-ca.yaml
```
要删除现有的 `tls-ca` 密文:
```bash
kubectl -n cattle-system delete secret tls-ca
```
### 3. 重新配置 Rancher 部署
如果证书源有更改,则需要执行此步骤。在这种情况下,它变化的原因很可能是因为 Rancher 之前配置为使用默认的自签名证书 (`ingress.tls.source=rancher`)。
以下步骤更新了 Rancher Chart 的 Helm 值,因此 Rancher pod 和 Ingress 会使用在步骤 1 中创建的新证书。
1. 调整初始安装期间使用的值,将当前值存储为:
```bash
helm get values rancher -n cattle-system -o yaml > values.yaml
```
1. 获取当前部署的 Rancher Chart 的版本字符串:
```bash
helm ls -n cattle-system
```
1. 更新 `values.yaml` 文件中的当前 Helm 值:
1. 由于不再使用私有 CA,删除 `privateCA: true` 字段,或将其设置为 `false`。
1. 根据需要调整 `ingress.tls.source` 字段。有关更多信息,请参阅 [Chart 选项](../installation-references/helm-chart-options.md#常用选项)。以下是一些示例:
1. 如果使用公共 CA,继续使用 `secret`
1. 如果使用 Let's Encrypt,将值更新为 `letsEncrypt`
1. 使用 `values.yaml` 文件更新 Rancher Chart 的 Helm 值,并使用当前 Chart 版本防止升级:
```bash
helm upgrade rancher rancher-stable/rancher \
--namespace cattle-system \
-f values.yaml \
--version <DEPLOYED_RANCHER_VERSION>
```
### 4. 为非私有/通用证书重新配置 Rancher Agent
由于不再使用私有 CA,因此你需要删除下游集群 agent 上的 `CATTLE_CA_CHECKSUM` 环境变量,或将其设置为 ""(空字符串)。
### 5. 强制更新 Fleet 集群,从而将 fleet-agent 重新连接到 Rancher
在 Rancher UI 的[持续交付](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#在-rancher-ui-中访问-fleet)中,为集群选择“强制更新”,来允许下游集群中的 fleet-agent 成功连接到 Rancher。
#### 为什么要执行这一步骤?
Rancher 管理的集群中的 Fleet agent 存储了用于连接到 Rancher 的 kubeconfig。kubeconfig 包含一个 `certificate-authority-data` 字段,该字段包含 Rancher 使用的证书的 CA。更改 CA 时,你需要更新此块来允许 fleet-agent 信任 Rancher 使用的证书。
@@ -0,0 +1,281 @@
---
title: 升级 Cert-Manager
---
Rancher 使用 cert-manager 为 Rancher 高可用部署自动生成和续期 TLS 证书。从 2019 秋季开始,cert-manager 发生了以下的三个重要变更。如果你在此时间段前创建了 Rancher 高可用部署,请进行相关操作。
1. [从 2019 年 11 月 1 日开始,Let's Encrypt 已阻止低于 0.8.0 的 cert-manager 实例。](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
1. [Cert-manager 正在弃用和替换 certificate.spec.acme.solvers 字段](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/)。此更改暂时没有确切的截止日期。
1. [Cert-manager 正在弃用 `v1alpha1` API 和替换它的 API 组](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/)。
为了帮助你应对这些变化,本文将:
1. 提供升级 cert-manager 步骤的文档。
1. 阐述 cert-manager API 的变更,并提供 cert-manager 官方文档的链接,助你实现数据迁移。
:::note 重要提示:
如果你要将 cert-manager 从早于 1.5 的版本升级到最新版本,请按照以下[选项 C](#选项-c升级-15-及以下版本的-cert-manager) 中的步骤进行操作。请注意,你无需重新安装 Rancher 即可执行此升级。
:::
## 升级 Cert-Manager
以下说明中使用的命名空间是由当前安装了 cert-manager 的命名空间决定的。如果它在 kube-system 中,在以下说明步骤中使用。你可以运行 `kubectl get pods --all-namespaces` 来验证,并检查 cert-manager-\* pods 列在哪个命名空间中。不要更改运行 cert-manager 的命名空间,否则可能会出现错误。
要升级 cert-manager,请遵循步骤操作。
### 选项 A:联网升级 cert-manager
<details id="normal">
<summary>单击展开</summary>
1. [备份现有资源](https://cert-manager.io/docs/tutorials/backup/):
```plain
kubectl get -o yaml --all-namespaces \
issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup.yaml
```
:::note 重要提示:
如果你从低于 0.11.0 的版本升级,请将所有备份资源上的 apiVersion 从 `certmanager.k8s.io/v1alpha1` 升级到 `cert-manager.io/v1alpha2`。如果你需要在其他资源上使用 cert-manager 注释,请对其进行更新以反映新的 API 组。详情请参见[附加注释变更](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes)。
:::
1. [卸载现有部署](https://cert-manager.io/docs/installation/uninstall/kubernetes/#uninstalling-with-helm):
```plain
helm uninstall cert-manager
```
使用你安装的 vX.Y.Z 版本的链接删除 CustomResourceDefinition:
```plain
kubectl delete -f https://github.com/cert-manager/cert-manager/releases/download/vX.Y.Z/cert-manager.crds.yaml
```
1. 单独安装 CustomResourceDefinition 资源:
```plain
kubectl apply --validate=false -f https://github.com/cert-manager/cert-manager/releases/download/vX.Y.Z/cert-manager.crds.yaml
```
:::note
如果你运行的 Kubernetes 版本是 1.15 或更低版本,你需要在以上的 `kubectl apply` 命令中添加 `--validate=false`。否则你将看到 cert-manager CRD 资源中的 `x-kubernetes-preserve-unknown-fields` 字段校验错误提示。这是 kubectl 执行资源校验方式产生的良性错误。
:::
1. 根据需要为 cert-manager 创建命名空间:
```plain
kubectl create namespace cert-manager
```
1. 添加 Jetstack Helm 仓库:
```plain
helm repo add jetstack https://charts.jetstack.io
```
1. 更新 Helm Chart 仓库本地缓存:
```plain
helm repo update
```
1. 安装新版本的 cert-manager:
```plain
helm install \
cert-manager jetstack/cert-manager \
--namespace cert-manager \
--version v1.11.0
```
1. [恢复备份资源](https://cert-manager.io/docs/tutorials/backup/#restoring-resources):
```plain
kubectl apply -f cert-manager-backup.yaml
```
</details>
### 选项 B:在离线环境中升级 Cert-Manager
<details id="airgap">
<summary>单击展开</summary>
### 先决条件
在执行升级之前,先将所需的容器镜像添加到私有镜像仓库中,并下载/渲染所需的 Kubernetes manifest 文件来准备离线环境。
1. 参见[准备私有镜像仓库](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md)指南,将升级所需的镜像推送到镜像仓库。
1. 在可以连接互联网的系统中,将 cert-manager 仓库添加到 Helm:
```plain
helm repo add jetstack https://charts.jetstack.io
helm repo update
```
1. 从 [Helm Chart 仓库](https://artifacthub.io/packages/helm/cert-manager/cert-manager)中获取最新可用的 cert-manager Chart:
```plain
helm fetch jetstack/cert-manager --version v1.11.0
```
1. 使用安装 Chart 的选项来渲染 cert-manager 模板。记住要设置 `image.repository` 选项,以从你的私有镜像仓库拉取镜像。此操作会创建一个包含 Kubernetes manifest 文件的 `cert-manager` 目录。
Helm 3 命令如下:
```plain
helm template cert-manager ./cert-manager-v0.12.0.tgz --output-dir . \
--namespace cert-manager \
--set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller
--set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook
--set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
```
Helm 2 命令如下:
```plain
helm template ./cert-manager-v0.12.0.tgz --output-dir . \
--name cert-manager --namespace cert-manager \
--set image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-controller
--set webhook.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-webhook
--set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
```
1. 下载新旧版 cert-manager 所需的 CRD 文件:
```plain
curl -L -o cert-manager-crd.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-0.12/deploy/manifests/00-crds.yaml
curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/cert-manager/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml
```
### 安装 cert-manager
1. 备份现有资源:
```plain
kubectl get -o yaml --all-namespaces \
issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup.yaml
```
:::note 重要提示:
如果你从低于 0.11.0 的版本升级,请将所有备份资源上的 apiVersion 从 `certmanager.k8s.io/v1alpha1` 升级到 `cert-manager.io/v1alpha2`。如果你需要在其他资源上使用 cert-manager 注释,请对其进行更新以反映新的 API 组。详情请参见[附加注释变更](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes)。
:::
1. 删除现有的 cert-manager 安装包:
```plain
kubectl -n cert-manager \
delete deployment,sa,clusterrole,clusterrolebinding \
-l 'app=cert-manager' -l 'chart=cert-manager-v0.5.2'
```
使用你安装的 vX.Y 版本的链接删除 CustomResourceDefinition:
```plain
kubectl delete -f cert-manager/cert-manager-crd-old.yaml
```
1. 单独安装 CustomResourceDefinition 资源:
```plain
kubectl apply -f cert-manager/cert-manager-crd.yaml
```
:::note 重要提示:
如果你运行的 Kubernetes 版本是 1.15 或更低版本,你需要在以上的 `kubectl apply` 命令中添加 `--validate=false`。否则你将看到 cert-manager CRD 资源中的 `x-kubernetes-preserve-unknown-fields` 字段校验错误提示。这是 kubectl 执行资源校验方式产生的良性错误。
:::
1. 为 cert-manager 创建命名空间:
```plain
kubectl create namespace cert-manager
```
1. 安装 cert-manager
```plain
kubectl -n cert-manager apply -R -f ./cert-manager
```
1. [恢复备份资源](https://cert-manager.io/docs/tutorials/backup/#restoring-resources):
```plain
kubectl apply -f cert-manager-backup.yaml
```
</details>
### 选项 C:升级 1.5 及以下版本的 cert-manager
<details id="normal">
<summary>单击展开</summary>
以前,要升级旧版本的 cert-manager,我们建议卸载并重新安装 Rancher。使用以下方法,你可以升级 cert-manager 而无需执行此额外步骤,从而更好地保护你的生产环境:
1. 按照[安装指南](https://cert-manager.io/docs/usage/cmctl/#installation)安装 `cmctl`(cert-manager CLI 工具)。
1. 确保所有以已弃用的 API 版本存储在 etcd 中的 cert-manager 自定义资源都迁移到 v1:
```
cmctl upgrade migrate-api-version
```
有关详细信息,请参阅 [API 版本迁移文档](https://cert-manager.io/docs/usage/cmctl/#migrate-api-version)。另请参阅[将 1.5 升级到 1.6](https://cert-manager.io/docs/installation/upgrading/upgrading-1.5-1.6/) 和[将 1.6 升级到到 1.7](https://cert-manager.io/docs/installation/upgrading/upgrading-1.6-1.7/)。
1. 正常使用 `helm upgrade` 将 cert-manager 升级到 1.7.1。如果需要,你可以直接从版本 1.5 转到 1.7。
1. 按照 Helm 教程[更新发布清单的 API 版本](https://helm.sh/docs/topics/kubernetes_apis/#updating-api-versions-of-a-release-manifest)。Chart 发布名称为 `release_name=rancher`,发布命名空​​间为 `release_namespace=cattle-system`。
1. 在解码后的文件中,搜索 `cert-manager.io/v1beta1` 并将其**替换**为 `cert-manager.io/v1`。
1. 使用 `helm upgrade` 正常升级 Rancher。
</details>
### 验证部署
安装完 cert-manager 后,你可以通过检查 kube-system 命名空间中正在运行的 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
```
## Cert-Manager API 变更和数据迁移
---
Rancher 现在支持 cert-manager 1.6.2 和 1.7.1。推荐使用 v1.7.x,因为 v 1.6.x 将在 2022 年 3 月 30 日结束生命周期。详情请参见 [cert-manager 文档](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#4-安装-cert-manager)。有关将 cert-manager 从 1.5 升级到 1.6 的说明,请参见上游的 [cert-manager 文档](https://cert-manager.io/docs/installation/upgrading/upgrading-1.5-1.6/)。有关将 cert-manager 从 1.6 升级到 1.7 的说明,请参见上游的 [cert-manager 文档](https://cert-manager.io/docs/installation/upgrading/upgrading-1.6-1.7/)。
---
Cert-manager 已经弃用 `certificate.spec.acme.solvers` 字段,而且会在未来的版本中放弃对该字段的支持。
根据 cert-manager 文档,v0.8 引入了配置 ACME 证书资源的新格式。具体来说,就是移动了 challenge solver 字段。v0.9 新旧格式均支持。请知悉,之后发布的新 cert-manager 版本会放弃对旧格式的支持。Cert-Manager 文档建议你在更新后,将 ACME 颁发者和证书资源更新到新格式。
如需了解变更细节以及迁移说明,请参见[将 Cert-Manager 从 v0.7 升级到 v0.8](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/)。
v0.11 版本标志着删除先前 Cert-Manager 版本中使用的 v1alpha1 API,以及将 API 组从 certmanager.k8s.io 更改到 cert-manager.io。
此外,我们已不再支持 v0.8 版本中已弃用的旧配置格式。换言之,在升级到 v0.11 之前,你必须先为 ACME 发行者使用新的 solver 样式配置格式作为过渡。详情请参见[升级到 v0.8](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/)。
如需了解变更细节以及迁移说明,请参见[将 Cert-Manager 从 v0.10 升级到 v0.11](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/)。
如需获得更多信息,请参见 [Cert-Manager 升级](https://cert-manager.io/docs/installation/upgrading/)。
@@ -0,0 +1,126 @@
---
title: 升级和回滚 Kubernetes
---
升级到最新版本的 Rancher 之后,下游 Kubernetes 集群可以升级为 Rancher 支持的最新的 Kubernetes 版本。
Rancher 使用 RKE(Rancher Kubernetes Engine)来预置和编辑 RKE 集群。有关为 RKE 集群配置升级策略的更多信息,请参阅 [RKE 文档](https://rancher.com/docs/rke/latest/en/)。
## 经过测试的 Kubernetes 版本
Rancher 在发布新版本之前,会对其与 Kubernetes 的最新次要版本进行测试,以确保兼容性。有关各个 Rancher 版本测试了哪些 Kubernetes 版本的详细信息,请参阅[支持维护条款](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/)。
## 升级的工作原理
RKE v1.1.0 改变了集群升级的方式。
在 [RKE 文档](https://rancher.com/docs/rke/latest/en/upgrades/how-upgrades-work)中,你将了解编辑或升级 RKE Kubernetes 集群时会发生的情况。
## 升级的最佳实践
在升级集群的 Kubernetes 版本时,我们建议你:
1. 拍一张快照。
1. 启动 Kubernetes 升级。
1. 如果升级失败,请将集群恢复到升级前的 Kubernetes 版本。这可以通过选择**恢复 etcd 和 Kubernetes 版本**选项来实现。在恢复 etcd 快照 之前,这会将你的集群恢复到升级前的 kubernetes 版本。
恢复操作将在不处于健康或 active 状态的集群上运行。
## 升级 Kubernetes 版本
:::note 先决条件:
- 以下选项适用于 [Rancher 启动的 Kubernetes 集群](../../pages-for-subheaders/launch-kubernetes-with-rancher.md)和[注册的 K3s Kubernetes 集群](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#已注册-rke2-和-k3s-集群的附加功能)。
- 以下选项也适用于导入且已注册的 RKE2 集群。如果你从外部云平台导入集群但不注册,你将无法在 Rancher 中升级 Kubernetes 版本。
- 在升级 Kubernetes 之前,先[备份你的集群](../../pages-for-subheaders/backup-restore-and-disaster-recovery.md)。
:::
1. 在左上角,单击 **☰ > 集群管理**。
1. 在**集群**页面中,进入要升级的集群,然后点击 **⋮ > 编辑配置**。
1. 从 **Kubernetes 版本** 下拉列表中,选择要用于集群的 Kubernetes 版本。
1. 单击**保存**。
**结果**:已开始为集群升级 Kubernetes。
## 回滚
你可以将集群恢复到使用先前 Kubernetes 版本的备份。有关详细信息,请参阅:
- [备份集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md#快照工作原理)
- [使用备份恢复集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md#使用快照恢复集群)
## 配置升级策略
从 RKE v1.1.0 开始,我们提供了额外的升级选项,让你更精细地控制升级过程。如果满足[条件和要求](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability),你可以使用这些选项,从而在集群升级期间维持应用的可用性。
你可以在 Rancher UI 中配置升级策略,也可以通过编辑 `cluster.yml` 来配置策略。编辑 `cluster.yml` 可以配置更多高级选项。
### 在 Rancher UI 中配置最大不可用的 Worker 节点
你可以在 Rancher UI 中配置不可用 worker 节点的最大数量。在集群升级期间,worker 节点将按此大小批量升级。
默认情况下,不可用 worker 节点的最大数量为所有 worker 节点的 10%。此数字可以配置为百分比或整数。当定义为百分比时,批大小会被四舍五入到最近的节点,最小为一个节点。
要更改 worker 节点的默认数量或百分比:
1. 在左上角,单击 **☰ > 集群管理**。
1. 在**集群**页面中,进入要升级的集群,然后点击 **⋮ > 编辑配置**。
1. 在**升级策略**选项卡中,输入 **Worker 并发**作为固定的数字或百分比。你可以通过将集群中的节点数减去最大不可用节点数来获取该数字。
1. 单击**保存**。
**结果**:集群更新为使用新的升级策略。
### 使用 Rancher UI 在升级期间启用节点清空
默认情况下,RKE 会在升级之前[封锁](https://kubernetes.io/docs/concepts/architecture/nodes/#manual-node-administration)每个节点。默认情况下,[清空](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)会在升级期间被禁用。如果在集群配置中启用了清空​​,RKE 将在升级之前对节点进行封锁和清空。
要在集群升级期间清空每个节点:
1. 在左上角,单击 **☰ > 集群管理**。
1. 在**集群**页面中,进入要启用节点清空的集群,然后点击 **⋮ > 编辑配置**。
1. 单击 **⋮ > 编辑**。
1. 在**升级策略**选项卡中,转到**清空节点**字段并单击**是**。controlplane 和 worker 节点的清空是单独配置的。
1. 配置如何删除 pod 的选项。有关每个选项的详细信息,请参阅[本节](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md#激进和安全的清空选项)。
1. (可选)配置宽限期。宽限期是给每个 pod 进行清理的超时时间,能让 pod 有机会优雅地退出。Pod 可能需要完成任何未完成的请求、回滚事务或将状态保存到某些外部存储。如果该值为负数,将使用 pod 中指定的默认值。
1. (可选)配置超时,这是在清空放弃之前应该继续等待的时间。
1. 单击**保存**。
**结果**:集群更新为使用新的升级策略。
:::note
目前存在一个[已知问题](https://github.com/rancher/rancher/issues/25478),即使 etcd 和 controlplane 正在被清空, Rancher UI 也不会将它们的状态显示为 drained。
:::
### 在升级期间维护应用的可用性
_从 RKE v1.1.0 起可用_
在 [RKE 文档](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability/)中,你将了解在升级集群时防止应用停机的要求。
### 在 cluster.yml 中配置升级策略
你通过编辑 `cluster.yml` 来获得更高级的升级策略配置选项。
有关详细信息,请参阅 RKE 文档中的[配置升级策略](https://rancher.com/docs/rke/latest/en/upgrades/configuring-strategy)。这部分还包括一个用于配置升级策略的示例 `cluster.yml`。
## 故障排除
如果升级后节点没有出现,`rke up` 命令会出错。
如果不可用节点的数量超过配置的最大值,则不会进行升级。
如果升级停止,你可能需要修复不可用节点或将其从集群中删除,然后才能继续升级。
失败的节点可能处于许多不同的状态:
- 关机
- 不可用
- 用户在升级过程中清空了节点,因此节点上没有 kubelet
- 升级本身失败
如果在升级过程中达到最大不可用节点数,Rancher 的下游集群将停留在更新中的状态,并且不会继续升级其他 controlplane 节点。它将继续评估不可用的节点集,以防其中一个节点变得可用。如果无法修复节点,则必须移除节点才能继续升级。
@@ -0,0 +1,91 @@
---
title: 在不升级 Rancher 的情况下升级 Kubernetes
---
RKE 元数据功能允许你在新版本 Kubernetes 发布后立即为集群配置新版本,而无需升级 Rancher。此功能对于使用 Kubernetes 的补丁版本非常有用,例如,在原本支持 Kubernetes v1.14.6 的 Rancher Server 版本中,将 Kubernetes 升级到 v1.14.7。
:::note
Kubernetes API 可以在次要版本之间更改。因此,我们不支持引入 Kubernetes 次要版本,例如在 Rancher 支持 v1.14 的情况下引入 v1.15。在这种情况下,你需要升级 Rancher 以添加对 Kubernetes 次要版本的支持。
:::
Rancher 的 Kubernetes 元数据包含 Rancher 用于配置 [RKE 集群](../../pages-for-subheaders/launch-kubernetes-with-rancher.md)的 Kubernetes 版本信息。Rancher 会定期同步数据并为 **系统镜像**、**服务选项**和**插件模板**创建自定义资源定义 (CRD)。因此,当新的 Kubernetes 版本与 Rancher Server 版本兼容时,Kubernetes 元数据可以使 Rancher 使用新版本来配置集群。元数据概述了 [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/) (RKE) 用于部署各种 Kubernetes 版本的信息。
下表描述了受周期性数据同步影响的 CRD。
:::note
只有管理员可以编辑元数据 CRD。除非明确需要,否则建议不要更新现有对象。
:::
| 资源 | 描述 | Rancher API URL |
|----------|-------------|-----------------|
| 系统镜像 | 用于通过 RKE 部署 Kubernetes 集群的系统镜像列表。 | `<RANCHER_SERVER_URL>/v3/rkek8ssystemimages` |
| 服务选项 | 传递给 Kubernetes 组件的默认选项,例如 `kube-api`、`scheduler`、`kubelet`、`kube-proxy` 和 `kube-controller-manager` | `<RANCHER_SERVER_URL>/v3/rkek8sserviceoptions` |
| 插件模板 | 用于部署插件组件的 YAML 定义,例如 Canal、Calico、Flannel、Weave、Kube-dns、CoreDNS、`metrics-server`、`nginx-ingress` | `<RANCHER_SERVER_URL>/v3/rkeaddons` |
管理员可以通过配置 RKE 元数据设置来执行以下操作:
- 刷新 Kubernetes 元数据。适用于有新的 Kubernetes 补丁版本发布,而用户希望在不升级 Rancher 的情况下为集群配置最新版本的 Kubernetes 的情景。
- 更改 Rancher 用于同步元数据的 URL。适用于要让 Rancher 从本地同步而不是与 GitHub 同步的情况。这在离线环境下非常有用。
- 防止 Rancher 自动同步元数据。这可以防止在 Rancher 中使用新的/不受支持的 Kubernetes 版本。
### 刷新 Kubernetes 元数据
默认情况下,管理员或具有**管理集群驱动**[全局角色](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)的用户,可以刷新 Kubernetes 元数据。
要强制 Rancher 刷新 Kubernetes 元数据,可以执行手动刷新操作:
1. 在左上角,单击 **☰ > 集群管理**。
1. 在左侧导航菜单中,单击**驱动**。
1. 单击**刷新 Kubernetes 元数据**。
你可以将 `refresh-interval-minutes` 设置为 `0`(见下文),将 Rancher 配置为仅在需要时刷新元数据,并在需要时使用此按钮手动执行元数据刷新。
### 配置元数据同步
:::caution
只有管​​理员可以更改这些设置。
:::
RKE 元数据的配置控制 Rancher 同步元数据的频率以及从何处下载数据。你可以通过 Rancher UI 或通过 Rancher API 端点 `v3/settings/rke-metadata-config` 配置元数据。
元数据的配置方式取决于 Rancher 版本。
要在 Rancher 中编辑元数据配置:
1. 在左上角,单击 **☰ > 全局设置**。
1. 转到 **rke-metadata-config**。单击 **⋮ > 编辑设置**。
1. 你可以选择填写以下参数:
- `refresh-interval-minutes`:Rancher 等待同步元数据的时间。如果要禁用定期刷新,请将 `refresh-interval-minutes` 设置为 0。
- `url`:Rancher 从中获取数据的 HTTP 路径。该路径必须是 JSON 文件的直接路径。例如,Rancher v2.4 的默认 URL 是 `https://releases.rancher.com/kontainer-driver-metadata/release-v2.4/data.json`。
1. 单击**保存**。
如果你没有离线设置,则无需指定 Rancher 获取元数据的 URL,因为默认是从 [Rancher 的元数据 Git 仓库获取](https://github.com/rancher/kontainer-driver-metadata/blob/dev-v2.5/data/data.json)的。
但是,如果你有[离线设置](#离线设置)需求,你需要将 Kubernetes 元数据仓库镜像到 Rancher 可用的位置。然后,你需要更改 URL 来指向 JSON 文件的新位置。
### 离线设置
Rancher Server 会定期刷新 `rke-metadata-config` 来下载新的 Kubernetes 版本元数据。有关 Kubernetes 和 Rancher 版本的兼容性表,请参阅[服务条款](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.2.8/)。
如果你使用离线设置,则可能无法从 Rancher 的 Git 仓库自动定期刷新 Kubernetes 元数据。在这种情况下,应该禁用定期刷新以防止在日志中显示相关错误。或者,你可以配置元数据,以便 Rancher 与本地的 RKE 元数据副本进行同步。
要将 Rancher 与 RKE 元数据的本地镜像同步,管理员需要配置 `rke-metadata-config` 来指向镜像。详情请参考[配置元数据同步](#配置元数据同步)
在将新的 Kubernetes 版本加载到 Rancher Server 中之后,需要执行其他步骤才能使用它们启动集群。Rancher 需要访问更新的系统镜像。虽然只有管理员可以更改元数据设置,但任何用户都可以下载 Rancher 系统镜像并为镜像准备私有容器镜像仓库。
要下载私有镜像仓库的系统镜像:
1. 点击左上角的 **☰**。
1. 点击左侧导航底部的**简介**。
1. 下载适用于 Linux 或 Windows 操作系统的镜像。
1. 下载 `rancher-images.txt`。
1. 使用[离线环境安装](other-installation-methods/air-gapped-helm-cli-install/publish-images.md)时使用的步骤准备私有镜像仓库,但不要使用发布页面中的 `rancher-images.txt`,而是使用上一个步骤中获取的文件。
**结果**:Rancher 的离线安装现在可以同步 Kubernetes 元数据。如果你在发布新版本的 Kubernetes 时更新了私有镜像仓库,你可以使用新版本配置集群,而无需升级 Rancher。

Some files were not shown because too many files have changed in this diff Show More