public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-05-01 18:53:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add i18n and Chinese translation

Browse Source
This commit is contained in:
vickyhella
2022-09-13 00:41:52 +08:00
parent 872809ba37
commit 4d88df32b1
453 changed files with 47673 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
i18n/zh/docusaurus-plugin-content-docs/current/backups/docker-installs/docker-installs.md
+8
View File
@@ -0,0 +1,8 @@
---
title: 备份和恢复 Docker 安装的 Rancher
shortTitle: Docker 安装
weight: 10
---
- [备份](../../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)
i18n/zh/docusaurus-plugin-content-docs/current/cluster-provisioning/rke-clusters/options/options.md
+6
View File
@@ -0,0 +1,6 @@
---
title: RKE 集群配置
weight: 2300
---
本文已迁移到[此处](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。
i18n/zh/docusaurus-plugin-content-docs/current/contribute-to-rancher.md
+137
View File
@@ -0,0 +1,137 @@
---
title: 参与 Rancher 社区贡献
weight: 700
---
本节介绍 Rancher 使用的仓库、如何构建仓库以及提交 issue 时要包含的信息。
有关如何为 Rancher 项目开发做出贡献的更多详细信息，请参阅 [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki)。Wiki 包含以下主题的资源：
- 如何搭建 Rancher 开发环境并运行测试
- Issue 在开发生命周期中的典型流程
- 编码指南和开发最佳实践
- 调试和故障排除
- 开发 Rancher API
在 Rancher Users Slack 上，开发者的频道是 **#developer**。
## 仓库
所有仓库都位于我们的主要 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>
## 构建
每个仓库都应该有一个 Makefile，并且可以使用 `make` 命令进行构建。`make` 目标基于仓库中 `/scripts` 目录中的脚本，每个目标都使用 [Dapper](https://github.com/rancher/dapper) 在孤立的环境中运行。`Dockerfile.dapper` 将用于此操作，它包含了所需的所有构建工具。
默认目标是 `ci`，它将运行 `./scripts/validate`、`./scripts/build`、`./scripts/test ` 和 `./scripts/package`。生成的二进制文件将在 `./build/bin` 中，通常也打包在 Docker 镜像中。
## 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` 的输出，这些输出会显示进程/内存/磁盘的使用情况。
## 文档
如果你对我们的文档有修改意见，请在我们的文档仓库中提交 PR。
- [Rancher 2.x 文档仓库](https://github.com/rancher/docs)：Rancher 2.x 所有文档都在这个仓库中。具体位于仓库的 `content` 文件夹中。
- [Rancher 1.x 文档仓库](https://github.com/rancher/rancher.github.io)：Rancher 1.x 所有文档都在这个仓库中。具体位于仓库的 `rancher` 文件夹中。
i18n/zh/docusaurus-plugin-content-docs/current/explanations.md
+6
View File
@@ -0,0 +1,6 @@
---
title: 说明
weight: 400
---
**说明文档**主要用于为某个任务或主题背后的“原因”提供理论知识。说明文档是“理解导向”的，用于拓宽用户的知识。在本节中，用户可以找到有关主题的上下文和背景、替代方案和意见等，还可能找到历史原因、相关限制以及流程的工作原理。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/cis-scans/configuration-reference.md
+106
View File
@@ -0,0 +1,106 @@
---
title: 配置
weight: 3
---
此配置参考用于帮助你管理由 `rancher-cis-benchmark` 应用创建的自定义资源。这些资源用于在集群上执行 CIS 扫描、跳过测试、设置扫描使用的测试配置文件和其他自定义配置。
要配置自定义资源，转到**集群**仪表板。要配置 CIS 扫描：
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面上，转到要配置 CIS 扫描的集群，然后单击 **Explore**。
1. 在左侧导航栏中，单击 **CIS Benchmark**。
### 扫描
扫描是用来根据定义的配置文件，在集群上触发 CIS 扫描的。扫描完成后会创建一份报告。
配置扫描时，你需要定义与 `scanProfileName` 参数一起使用的扫描配置文件的名称。
下面是一个 ClusterScan 自定义资源示例：
```yaml
apiVersion: cis.cattle.io/v1
kind: ClusterScan
metadata:
name: rke-cis
spec:
scanProfileName: rke-profile-hardened
```
### 配置文件
配置文件包含 CIS 扫描的配置，包括要使用的 Benchmark 测试版本以及要在该 Benchmark 测试中跳过的测试。
:::caution
默认情况下，一些 ClusterScanProfile 会作为 `rancher-cis-benchmark` Chart 的一部分进行安装。如果用户编辑了这些默认 Benchmark 或配置文件，它们会在下一次 Chart 更新时被重置。因此，建议用户不要编辑默认的 ClusterScanProfile。
:::
用户可以通过克隆 ClusterScanProfile 来创建自定义配置文件。
跳过的测试会列在 `skipTests` 参数下。
创建新配置文件时，你还需要命名配置文件。
`ClusterScanProfile` 示例如下：
```yaml
apiVersion: cis.cattle.io/v1
kind: ClusterScanProfile
metadata:
annotations:
meta.helm.sh/release-name: clusterscan-operator
meta.helm.sh/release-namespace: cis-operator-system
labels:
app.kubernetes.io/managed-by: Helm
name: "<example-profile>"
spec:
benchmarkVersion: cis-1.5
skipTests:
- "1.1.20"
- "1.1.21"
```
### Benchmark 版本
Benchmark 版本是指使用 `kube-bench` 运行的 Benchmark 名称，以及该 Benchmark 的有效配置参数。
`ClusterScanBenchmark` 定义了 CIS `BenchmarkVersion` 的名称和测试配置。`BenchmarkVersion` 名称是提供给 `kube-bench` 工具的参数。
默认情况下，一些 `BenchmarkVersion` 名称和测试配置会作为 CIS 扫描应用的一部分进行打包。启用此功能后，这些默认 BenchmarkVersion 将自动安装，用户可以使用它们来创建 ClusterScanProfile。
:::caution
如果用户编辑了默认的 BenchmarkVersion，它们会在下一次 Chart 更新时被重置。因此，不建议编辑默认的 ClusterScanBenchmark。
:::
ClusterScanBenchmark 由以下字段组成：
- `ClusterProvider`：此 Benchmark 适用的集群提供商名称，例如，RKE、EKS、GKE。如果此基准测试可以在任何集群类型上运行，则留空。
- `MinKubernetesVersion`：集群运行此 Benchmark 测试所需的最低 kubernetes 版本。如果不依赖特定的 Kubernetes 版本，则留空。
- `MaxKubernetesVersion`：集群运行此 Benchmark 测试所需的最高 Kubernetes 版本。如果不依赖特定的 Kubernetes 版本，则留空。
`ClusterScanBenchmark` 示例如下：
```yaml
apiVersion: cis.cattle.io/v1
kind: ClusterScanBenchmark
metadata:
annotations:
meta.helm.sh/release-name: clusterscan-operator
meta.helm.sh/release-namespace: cis-operator-system
creationTimestamp: "2020-08-28T18:18:07Z"
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
name: cis-1.5
resourceVersion: "203878"
selfLink: /apis/cis.cattle.io/v1/clusterscanbenchmarks/cis-1.5
uid: 309e543e-9102-4091-be91-08d7af7fb7a7
spec:
clusterProvider: ""
minKubernetesVersion: 1.15.0
```
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/cis-scans/custom-benchmark.md
+79
View File
@@ -0,0 +1,79 @@
---
title: 为集群扫描创建自定义 Benchmark 版本
weight: 4
---
每个 Benchmark 版本都定义了一组测试配置文件，这些文件定义了由 <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> 工具运行的 CIS 测试。
`rancher-cis-benchmark` 应用安装了一些默认的 Benchmark 测试版本，这些版本列在了 CIS Benchmark 测试应用菜单下。
但是，某些 Kubernetes 集群可能需要自定义配置 Benchmark 测试。例如，Kubernetes 配置文件或证书的路径可能与上游 CIS Benchmark 的标准位置不同。
现在，你可以使用 `rancher-cis-benchmark` 应用来创建自定义 Benchmark 版本，从而运行集群扫描。
运行集群扫描时，你需要选择指向特定 Benchmark 版本的配置文件。
按照以下所有步骤添加自定义 Benchmark 版本并使用它运行扫描。
### 1. 准备自定义 Benchmark 版本 ConfigMap
要创建自定义 Benchmark 版本，你需要先创建一个包含 Benchmark 版本配置文件的 ConfigMap，并将其上传到要运行扫描的 Kubernetes 集群。
假设要添加一个名为 `foo` 的自定义 Benchmark 版本，你可以按照以下步骤准备自定义 Benchmark 版本 ConfigMap：
1. 创建一个名为 `foo` 的目录，并在该目录中放置所有配置 YAML 文件， <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> 工具会搜索这些文件。例如，通用 CIS 1.5 Benchmark 版本的配置 YAML 文件在[此处](https://github.com/aquasecurity/kube-bench/tree/master/cfg/cis-1.5)。
1. 放置完整的 `config.yaml` 文件，其中包括所有要测试的组件。
1. 将 Benchmark 版本名称添加到 `config.yaml` 的 `target_mapping` 中：
```yaml
target_mapping:
"foo":
- "master"
- "node"
- "controlplane"
- "etcd"
- "policies"
```
1. 通过创建 ConfigMap 将此目录上传到 Kubernetes 集群：
```yaml
kubectl create configmap -n <namespace> foo --from-file=<path to directory foo>
```
### 2. 将自定义 Benchmark 版本添加到集群
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面上，转到要添加自定义 Benchmark 的集群，然后单击 **Explore**。
1. 在左侧导航栏中，单击 **CIS Benchmark > Benchmark 版本**。
1. 单击**创建**。
1. 输入自定义 Benchmark 版本的**名称**和描述。
1. 选择要应用 Benchmark 版本的集群提供商。
1. 在下拉列表中选择你已上传的 ConfigMap。
1. 添加最低和最高 Kubernetes 版本限制（如果有）。
1. 单击**创建**。
### 3. 为自定义 Benchmark 版本创建新配置文件
要使用你的自定义 Benchmark 版本运行扫描，你需要添加一个指向此 Benchmark 版本的新配置文件：
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面上，转到要添加自定义 Benchmark 的集群，然后单击 **Explore**。
1. 在左侧导航栏中，单击 **CIS Benchmark > 配置文件**。
1. 单击**创建**。
1. 设置**名称**和描述。在本例中，我们将其命名为 `foo-profile`。
1. 在下拉列表中选择 Benchmark 版本。
1. 单击**创建**。
### 4. 使用自定义 Benchmark 版本运行扫描
指向你的自定义 Benchmark 版本的 `foo` 配置文件创建完成后，你可以创建一个新的扫描，从而在 Benchmark 版本中运行自定义测试。
要运行扫描：
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面上，转到要添加自定义 Benchmark 的集群，然后单击 **Explore**。
1. 在左侧导航栏中，单击 **CIS Benchmark > 扫描**。
1. 单击**创建**。
1. 选择新的集群扫描配置文件。
1. 单击**创建**。
**结果**：已生成带有扫描结果的报告。如需查看结果，请单击显示的扫描名称。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/cis-scans/rbac-for-cis-scans.md
+48
View File
@@ -0,0 +1,48 @@
---
title: RBAC
shortTitle: RBAC
weight: 3
---
本文介绍使用 rancher-cis-benchmark 应用所需的权限。
默认情况下，rancher-cis-benchmark 是集群管理员独有的功能。
但是，`rancher-cis-benchmark` Chart 安装了这两个默认的 `ClusterRole`：
- cis-admin
- cis-view
在 Rancher 中，默认情况下只有集群所有者和全局管理员具有 `cis-admin` 访问权限。
注意：如果你使用在 Rancher 2.5 中添加的 `cis-edit` 角色，该角色从 2.5.2 开始已被删除，删除的原因是该角色本质上与 `cis-admin` 相同。如果你为 `cis-edit` 创建了任何 clusterrolebinding，请更新这些绑定以使用 `cis-admin` ClusterRole。
## Cluster-Admin 访问
默认情况下，Rancher CIS 扫描是集群管理员独有的功能。
换言之，只有 Rancher 全局管理员和集群的集群所有者可以：
- 安装/卸载 rancher-cis-benchmark 应用。
- 查看 CIS Benchmark CRD 的导航链接 - ClusterScanBenchmarks、ClusterScanProfiles、ClusterScans。
- 列出默认的 ClusterScanBenchmarks 和 ClusterScanProfiles。
- 创建/编辑/删除新的 ClusterScanProfiles。
- 创建/编辑/删除新的 ClusterScan，从而在集群上运行 CIS 扫描。
- 在 ClusterScan 完成后查看并下载 ClusterScanReport。
## Kubernetes 默认角色的默认权限摘要
rancher-cis-benchmark 创建了三个 `ClusterRole`，并将 CIS Benchmark CRD 访问权限添加到以下默认 K8s `ClusterRole`：
| Chart 创建的 ClusterRole | 默认 K8s ClusterRole | 角色赋予的权限 |
| ------------------------------| ---------------------------| ---------------------------|
| `cis-admin` | `admin` | 增刪查改（CRUD）clusterscanbenchmarks、clusterscanprofiles、clusterscans、clusterscanreports CR |
| `cis-view` | `view ` | 列出 (R) clusterscanbenchmarks、clusterscanprofiles、clusterscans、clusterscanreports CR |
默认情况下，只有 cluster-owner 角色能管理和使用 `rancher-cis-benchmark` 功能。
默认情况下，其他 Rancher 角色（cluster-member、project-owner 和 project-member）没有管理和使用 rancher-cis-benchmark 资源的权限。
但是，如果 cluster-owner 想将访问权限分配给其他用户，他们可以手动创建目标用户与上述 CIS ClusterRole 之间的 ClusterRoleBinding，从而实现权限分配。
`rancher-cis-benchmark` ClusterRole 不支持自动角色聚合。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md
+54
View File
@@ -0,0 +1,54 @@
---
title: 跳过和不适用的测试
weight: 3
---
本文列出了在 RKE 的 permissive 测试配置文件中跳过的测试。
> 在 v2.5 生成的报告中，此页面上被跳过且不适用的测试将会计为不适用。跳过的测试计数只会涉及用户定义的跳过测试。这样，你可以区分用户要跳过的测试与 RKE permissive 测试配置文件中默认跳过的测试。
## CIS Benchmark v1.5
### CIS Benchmark v1.5 跳过的测试
| 数字 | 描述 | 跳过的原因 |
| ---------- | ------------- | --------- |
| 1.1.12 | 确保 etcd 数据目录所有权设置为 etcd:etcd（自动） | etcd 数据目录所有权需要系统 ServiceAccount。有关如何配置所有权的更多信息，请参阅 Rancher 的强化指南。 |
| 1.2.6 | 确保根据需要设置 --kubelet-certificate-authority 参数（自动） | 在生成服务证书时，功能可能会与某些云提供商所需的主机名覆盖一起中断。 |
| 1.2.16 | 确保设置了准入控制插件 PodSecurityPolicy（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
| 1.2.33 | 确保能根据需要设置 --encryption-provider-config 参数（手动） | 启用加密会改变恢复加密数据的方式。 |
| 1.2.34 | 确保正确配置了加密提供程序（手动） | 启用加密会改变恢复加密数据的方式。 |
| 4.2.6 | 确保 --protect-kernel-defaults 参数设置为 true（自动） | 在配置集群之前需要系统级别的配置，才能将此参数设置为 true。 |
| 4.2.10 | 确保根据需要设置 --tls-cert-file 和 --tls-private-key-file 参数（自动） | 在生成服务证书时，功能可能会与某些云提供商所需的主机名覆盖一起中断。 |
| 5.1.5 | 确保未主动使用默认 ServiceAccount。（自动） | Kubernetes 提供了要使用的默认 ServiceAccount。 |
| 5.2.2 | 最小化需要共享主机进程 ID 命名空间的容器准入（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
| 5.2.3 | 最小化需要共享主机 IPC 命名空间的容器准入（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
| 5.2.4 | 最小化需要共享主机网络命名空间的容器准入（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
| 5.2.5 | 使用 allowPrivilegeEscalation（自动）最小化容器的准入 | 启用 Pod 安全策略可能会导致应用意外失败。 |
| 5.3.2 | 确保所有命名空间都定义了网络策略（自动） | 启用网络策略可以防止某些应用进行相互通信。 |
| 5.6.4 | 确保不使用 Default 命名空间（自动） | Kubernetes 提供了一个 Default 命名空间。 |
### CIS Benchmark v1.5 不适用的测试
| 数字 | 描述 | 不适用的原因 |
| ---------- | ------------- | --------- |
| 1.1.1 | 确保 API Server pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 kube-apiserver 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.1.2 | 确保 API Server pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 kube-apiserver 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.1.3 | 确保 Controller Manager pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.1.4 | 确保 Controller Manager pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.1.5 | 确保 Scheduler pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.1.6 | 确保 Scheduler pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.1.7 | 确保 etcd pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 etcd 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.1.8 | 确保 etcd pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 etcd 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.1.13 | 确保 admin.conf 文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不会在节点上存储 kubernetes 的默认 kubeconfig 凭证文件。 |
| 1.1.14 | 确保 admin.conf 文件所有权设置为 root:root（自动） | RKE 配置的集群不会在节点上存储 kubernetes 的默认 kubeconfig 凭证文件。 |
| 1.1.15 | 确保 scheduler.conf 文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.1.16 | 确保 scheduler.conf 文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.1.17 | 确保 controller-manager.conf 文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.1.18 | 确保将 controller-manager.conf 文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
| 1.3.6 | 确保 RotateKubeletServerCertificate 参数设置为 true（自动） | RKE 配置的集群直接使用 RKE 处理证书轮换。 |
| 4.1.1 | 确保 kubelet 服务文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 kubelet 服务的配置文件。所有配置在容器运行时作为参数传入。 |
| 4.1.2 | 确保 kubelet 服务文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 kubelet 服务的配置文件。所有配置在容器运行时作为参数传入。 |
| 4.1.9 | 确保 kubelet 配置文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 kubelet 的配置文件。所有配置在容器运行时作为参数传入。 |
| 4.1.10 | 确保 kubelet 配置文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 kubelet 的配置文件。所有配置在容器运行时作为参数传入。 |
| 4.2.12 | 确保 RotateKubeletServerCertificate 参数设置为 true（自动） | RKE 配置的集群直接使用 RKE 处理证书轮换。 |
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/adapter-requirements.md
+97
View File
@@ -0,0 +1,97 @@
---
title: 先决条件
weight: 1
---
### 1. 设置许可证管理器和购买支持
首先，完成许可证管理器设置的[第一步](https://docs.aws.amazon.com/license-manager/latest/userguide/getting-started.html)。
然后，转到 AWS Marketplace。找到 “Rancher Premium Support Billing Container Starter Pack”。最后，购买至少一项 Entitlement。
如果你已使用 “Rancher Setup” AWS Marketplace 产品安装了 Rancher，请跳至[步骤 4](#4-创建-oidc-提供商)。
> **注意**：每项 Entitlement 都对一定数量的节点授予访问支持的权限。你可以后续根据需要购买更多许可证。
### 2. 创建 EKS 集群
按照 [Rancher 文档](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md)创建 EKS 集群。进行到[安装 Rancher Helm Chart](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md#8-安装-rancher-helm-chart)（最后一步）时，**停止并返回此页面**。该集群需要满足以下要求：
- EKS 1.22 版本。
- 集群中的每个节点都可以访问包含 Rancher 及其相关镜像的镜像仓库。
- 集群中的每个节点都可以访问存储 CSP Adapter 的 ECR 仓库。
- 集群中的每个节点都可以访问许可证管理器服务。
- 集群中的每个节点都可以访问 STS 服务的全局端点。
### 3. 安装 Rancher
除了在 [Rancher 文档](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md#8-安装-rancher-helm-chart)中指定的 Rancher 安装选项外，你还需要启用其它指标。
你可以通过 Helm CLI 使用以下选项来完成：
```bash
--set extraEnv\[0\].name="CATTLE_PROMETHEUS_METRICS" --set-string extraEnv\[0\].value=true
```
你还可以使用 values.yaml，如下所示：
```yaml
extraEnv:
- name: "CATTLE_PROMETHEUS_METRICS"
value: "true"
```
你还需要安装 Rancher 2.6.7 或更高版本。
### 4. 创建 OIDC 提供程序
按照 [AWS 文档](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html)为上一节中指定的集群创建 OIDC 提供程序。
### 5. 创建 IAM 角色
CSP Adapter 需要 IAM 角色才能签入/签出 Entitlement。
首先，配置如下的信任策略。你需要将 `MY_AWS_ACC` 替换为你的 AWS 帐号，将 `MY_AWS_REGION` 替换为你的 AWS 区域，并将 `MY_OIDC_PROVIDER` 替换为你的 OIDC 提供商 ID：
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::${MY_AWS_ACC}:oidc-provider/oidc.eks.${MY_AWS_REGION}.amazonaws.com/id/${MY_OIDC_PROVIDER}"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.${MY_AWS_REGION}.amazonaws.com/id/${MY_OIDC_PROVIDER}:sub": "system:serviceaccount:cattle-csp-adapter-system:rancher-csp-adapter",
"oidc.eks.${MY_AWS_REGION}.amazonaws.com/id/${MY_OIDC_PROVIDER}:aud": "sts.amazonaws.com"
}
}
}
]
}
```
接下来，为具有以下权限的角色使用策略：
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RancherCSPAdapterPermissions",
"Effect": "Allow",
"Action": [
"license-manager:ListReceivedLicenses",
"license-manager:CheckoutLicense",
"license-manager:ExtendLicenseConsumption",
"license-manager:CheckInLicense",
"license-manager:GetLicense",
"license-manager:GetLicenseUsage"
],
"Resource": "*"
}
]
}
```
保存角色的名称。稍后安装 CSP Adapter 时将需要它。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/common-issues.md
+29
View File
@@ -0,0 +1,29 @@
---
title: 常见问题
weight: 4
---
**安装 Adapter 后，Rancher 中出现一条横幅消息，上面写着 "AWS Marketplace Adapter: Unable to run the adapter, please check the adapter logs"**
此错误表示 Adapter 安装到集群中时发生了一个错误，导致它无法正确签入/签出许可证。
这通常是因为 IAM 角色设置不正确。请查看[先决条件](./adapter-requirements.md)并确认：
- 已创建一个 OIDC 提供程序，并且它已关联到运行 Rancher 的集群。
- IAM 角色已配置为信任此 OIDC 提供程序。
- IAM 角色至少具有策略中概述的权限。
如果上述所有配置均已正确配置，请联系支持寻求帮助。
**我看到一条横幅消息，上面写着 "AWS Marketplace Adapter: You have exceeded your licensed node count. At least x more license(s) are required in AWS to become compliant"**
此消息表明你没有足够的 Entitlement 来满足 Rancher 当前管理的节点数量。
请记住以下限制：
- 每个 Entitlement 仅对一定数量的节点有效。
- 当前由 Rancher 管理的每个节点都计入你的总使用量（安装了集群 Rancher 的节点除外）。
- 每个 Entitlement 最多可以被一个 Rancher 实例使用。例如，如果你的账户中有两个正在运行的 Rancher 实例（每个都安装在单独的 EKS 集群上），那么你至少需要两个 Entitlement。
你最近可能还卸载/重新安装了 Adapter。如果 Adapter 丢失了它当前管理的许可证的跟踪，则可能需要一个小时来解析许可证的实际状态。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md
+144
View File
@@ -0,0 +1,144 @@
---
title: 安装 Adapter
weight: 2
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
> **重要提示**：如果你尝试重新安装 Adapter，你可能会在长达一小时的时间内收到不合规的错误消息。
### 1. 获取对 Local 集群的访问权限
> **注意**：只有管理员用户才能访问 Local 集群。因为 CSP Adapter 必须安装在 Local 集群中，所以此安装必须由管理员用户执行。
首先，单击 Local 集群并下载 kubeconfig 令牌。然后，使用下方的命令配置 CLI 以使用此新令牌，你需要将 `$TOKEN_PATH` 替换为文件系统上令牌的下载路径：
```bash
export KUBECONFIG=$TOKEN_PATH
```
### 2. 创建 Adapter 命名空间
创建要安装 Adapter 的命名空间：
```bash
kubectl create ns cattle-csp-adapter-system
```
### 3. 创建证书密文
Adapter 需要访问 Rancher 用来与 Rancher Server 通信的根 CA。有关 Rancher 支持的证书选项的更多信息，请参阅 [Chart 选项页面](../../../../reference-guides/installation-references/helm-chart-options.md)。
如果你的 Rancher 使用由公认的证书颁发机构（例如 Let's Encrypt）签发的证书，你可以跳到[步骤 4](#4-安装-chart)。
但是，如果你的 Rancher 使用了自定义证书（例如 Rancher 生成的证书或由私有证书颁发机构签发的证书），你需要为该 CA 提供 PEM 编码格式的证书以便 Adapter 可以与 Rancher 通信。
首先，检索 Rancher 正在使用的证书并将其放入名为 `ca-additional.pem` 的文件中。如果你使用 Rancher 生成的证书，你可以使用以下命令完成此操作：
```bash
kubectl get secret tls-rancher -n cattle-system -o jsonpath="{.data.tls\.crt}" | base64 -d >> ca-additional.pem
```
然后，创建一个使用此证书的密文：
```bash
kubectl -n cattle-csp-adapter-system create secret generic tls-ca-additional --from-file=ca-additional.pem
```
> **重要提示**：不要更改文件名或创建的密文的名称，否则可能会导致 Adapter 运行出错。
### 4. 安装 Chart
首先，使用以下命令添加 `rancher/charts` 仓库：
```bash
helm repo add rancher-charts https://charts.rancher.io
```
接下来，安装 CSP Adapter。你必须指定多个值，其中包括账号号码以及在先决条件中创建的角色的名称。
在下方的操作中，将 `$MY_ACC_NUM` 替换为你的 AWS 账号，将 `$MY_ROLE_NAME` 替换为先决条件中创建的角色的名称。
> **注意**：如果你使用 shell 变量，请不要使用引号。例如，MY_ACC_NUM=123456789012 可用，但 MY_ACC_NUM="123456789012" 将失败。
> **注意**：使用欧盟和英国的 AWS Marketplace 列表的账号需要额外指定 `--set image.repository=rancher/rancher-csp-adapter-eu` 选项。要查看你的账号在安装 Adapter 时是否需要此选项，请参阅 Marketplace 列表的使用说明。
> **注意**：请务必严格按照以下说明进行操作。尤其需要注意安装 1.0.1 版本 Adapter 的命令（使用 `--set image.tag=v1.0.1`），这是确保节点数量准确的关键。
<Tabs>
<TabItem value="Let's Encrypt/ Public Certificate Authority">
```bash
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter --namespace cattle-csp-adapter-system --set aws.enabled=true --set aws.roleName=$MY_ROLE_NAME --set-string aws.accountNumber=$MY_ACC_NUM --set image.tag=v1.0.1
```
你也可以使用 `values.yaml` 并指定以下选项：
```yaml
image:
tag: v1.0.1
aws:
enabled: true
accountNumber: "$MY_ACC_NUM"
roleName: $MY_ROLE_NAME
```
> **注意**：账号需要像上面那样以字符串格式指定，否则安装会失败。
然后，使用以下命令安装 Adapter：
```bash
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter -f values.yaml
```
</TabItem>
<TabItem value="Private CA Authority / Rancher-generated Certificates">
```bash
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter --namespace cattle-csp-adapter-system --set aws.enabled=true --set aws.roleName=$MY_ROLE_NAME --set-string aws.accountNumber=$MY_ACC_NUM --set additionalTrustedCAs=true --set image.tag=v1.0.1
```
你也可以使用 `values.yaml` 并指定以下选项：
```yaml
image:
tag: v1.0.1
aws:
enabled: true
accountNumber: "$MY_ACC_NUM"
roleName: $MY_ROLE_NAME
additionalTrustedCAs: true
```
> **注意**：账号需要像上面那样以字符串格式指定，否则安装会失败。
然后，使用以下命令安装 Adapter：
```bash
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter -f values.yaml
```
</TabItem>
</Tabs>
### 5. 管理证书更新
如果你在[步骤 3](#3-创建证书密文) 中创建了一个用于存储自定义证书的密文，则随着证书的轮换，你将需要更新此密文。
首先，使用以下命令删除 cattle-csp-adapter-system 命名空间中的原始密文：
```bash
kubectl delete secret tls-ca-additional -n cattle-csp-adapter-system
```
然后，按照[步骤 3](#3-创建证书密文) 中的安装步骤，将密文的内容替换为更新后的值。
最后，重新启动 rancher-csp-adapter deployment 来确保更新后的值可供 Adapter 使用：
```bash
kubectl rollout restart deploy rancher-csp-adapter -n cattle-csp-adapter-system
```
> **注意**：有一些方法（例如 cert-manager 的 [trust operator](https://cert-manager.io/docs/projects/trust/)）可以帮助你减少手动轮换任务的数量。这些选项不受官方支持，但可能对想要自动化某些任务的用户有用。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/uninstall-adapter.md
+22
View File
@@ -0,0 +1,22 @@
---
title: 卸载 Adapter
weight: 3
---
### 1. 使用 Helm 卸载 Adapter Chart：
```bash
helm uninstall rancher-csp-adapter -n cattle-csp-adapter-system
```
### 2. 删除为 Adapter 创建的命名空间：
```bash
kubectl delete ns cattle-csp-adapter-system
```
### 3. （可选）删除未完成的用户通知：
```bash
kubectl delete RancherUserNotification csp-compliance
```
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/cloud-marketplace/supportconfig.md
+54
View File
@@ -0,0 +1,54 @@
---
title: Supportconfig Bundle
weight: 100
---
安装 CSP Adapter 后，你将能够生成一个 Supportconfig Bundle。此 Bundle 是一个 tar 包，可用于快速提供支持信息。
你可以通过 Rancher 或通过直接访问安装 Rancher 的集群来创建这些 Bundle。请注意，建议通过 Rancher 访问。
> **注意**：无论采用何种方法，只有管理员可以生成/下载 Supportconfig Bundle。
### 通过 Rancher 访问
首先，点击汉堡菜单。然后单击 `Get Support` 按钮。
![Get Support](/img/support-help.png)
在下一页中，单击 `Generate Support Config` 按钮。
> **注意**：如果未安装 Adapter ，则不会出现生成 Supportconfig Bundle 的选项。你必须安装 CSP Adapter 才能生成 Supportconfig Bundle。
![Get Support](/img/generate-support-config.png)
### 不通过 Rancher 进行访问
首先，为安装 Rancher 的集群生成 kubeconfig。
> **注意**：如果 Rancher 宕机，你将无法使用 Rancher 生成的 kubeconfig 令牌访问集群。
配置你的 shell 环境以使用此 kubeconfig 令牌：
```bash
export KUBECONFIG=$MY_KUBECONFIG_PATH
```
建议在运行此命令时创建一个临时工作目录，如下所示：
```bash
mkdir temp && cd temp
```
然后，检索 Supportconfig Bundle：
```bash
mkdir rancher && kubectl get configmap csp-config -n cattle-csp-adapter-system -o=jsonpath='{.data.data}' >> rancher/config.json && tar -c -f supportconfig_rancher.tar rancher && rm -rf rancher
```
这将在你的当前目录中创建一个 `supportconfig_rancher.tar` 文件。
由于 gnu-tar 和 bsd-tar 不兼容，在 Mac 上运行这些命令的用户可能会遇到问题。如果支持部门在读取你制作的 Supportconfig 时出现问题，你可以先尝试在你的路径上将 gnu-tar 作为 `gtar` 进行访问，然后运行以下命令：
```bash
mkdir rancher && kubectl get configmap csp-config -n cattle-csp-adapter-system -o=jsonpath='{.data.data}' >> rancher/config.json && gtar -c -f supportconfig_rancher.tar rancher && rm -rf rancher
```
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/fleet-gitops-at-scale/architecture.md
+9
View File
@@ -0,0 +1,9 @@
---
title: 架构
weight: 1
---
Fleet 可以管理来自 Git 的原始 Kubernetes YAML、Helm Chart、Kustomize 或三者的任何组合的部署。无论来源如何，所有资源都会动态转化为 Helm Chart，Helm 会用作引擎来将所有资源部署到集群中。这给了你高度的控制、一致性和可审计性。Fleet 不仅关注扩展能力，而且还提供高度的控制和可见性，从而让用户准确了解集群上安装的内容。
![架构](/img/fleet-architecture.svg)
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md
+55
View File
@@ -0,0 +1,55 @@
---
title: 在代理后使用 Fleet
weight: 3
---
在本节中，你将学习如何在一个设置中启用 Fleet，该设置有一个具有公共 IP 的 Rancher Server，以及一个没有公共 IP 但配置为使用代理的 Kubernetes 集群。
Rancher 不会与已注册的下游集群建立连接。部署在下游集群上的 Rancher agent 必须能够与 Rancher 建立连接。
要让 Fleet 在代理后工作，你需要为下游集群设置 **Agent 环境变量**。以下是集群级别的配置选项。
你可以通过 Rancher UI 为任何集群类型（包括注册集群和自定义集群）配置这些环境变量。可以在编辑现有集群或配置新集群时添加变量。
对于公共下游集群，[在 Rancher UI 中设置必要的环境变量](#在-rancher-ui-中设置环境变量)就足够了。
对于私有节点或私有集群，则需要在节点上设置环境变量。然后，在配置自定义集群或注册私有集群时，在 Rancher UI 中配置环境变量。有关如何在 K3s Kubernetes 集群中的 Ubuntu 节点上设置环境变量的示例，请参阅[本节](#在私有节点上设置环境变量)。
# 必要的环境变量
为代理添加 Fleet agent 环境变量时，将 <PROXY_IP> 替换为你的私有代理 IP。
| 变量名称 | 值 |
|------------------|--------|
| `HTTP_PROXY` | http://<PROXY_IP>:8888 |
| `HTTPS_PROXY` | http://<PROXY_IP>:8888 |
| `NO_PROXY` | 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local |
## 在 Rancher UI 中设置环境变量
要将环境变量添加到现有集群：
1. 点击 **☰ > 集群管理**。
1. 转到要添加环境变量的集群，然后单击 **⋮ > 编辑配置**。
1. 单击**高级选项**。
1. 单击**添加环境变量**。
1. 输入[必要的环境变量](#必要的环境变量)
1. 单击**保存**。
**结果**：Fleet agent 会在代理后工作。
## 在私有节点上设置环境变量
对于私有节点和私有集群，代理环境变量需要在节点本身上设置，以及从 Rancher UI 配置。
此示例显示了如何在 K3s Kubernetes 集群中的 Ubuntu 节点上设置环境变量：
```
ssh -o ForwardAgent=yes ubuntu@<public_proxy_ip>
ssh <k3s_ip>
export proxy_private_ip=<private_proxy_ip>
export HTTP_PROXY=http://${proxy_private_ip}:8888
export HTTPS_PROXY=http://${proxy_private_ip}:8888
export NO_PROXY=127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
```
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/fleet-gitops-at-scale/windows-support.md
+23
View File
@@ -0,0 +1,23 @@
---
title: Windows 支持
weight: 2
---
在 Rancher 2.5.6 之前，`agent` 在具有 Windows 节点的下游集群上没有原生的 Windows 清单。这将导致集群的 `agent` pod 失败。
如果你从旧版本的 Rancher 升级到 2.5.6+，你可以在*下游集群*中部署具有以下工作流的工作 `agent`：
1. 封锁所有 Windows 节点。
1. 对 `agent` 工作负载应用以下容忍度。
1. 取消所有 Windows 节点的封锁。
1. 删除所有 `agent` pod。使用新的容忍度来创建新 pod。
1. `agent` pod 运行并为 Fleet 启用了自动更新后，它们会更新到与 Windows 兼容的 `agent` 版本。
```yaml
tolerations:
- effect: NoSchedule
key: cattle.io/os
operator: Equal
value: linux
```
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/harvester.md
+44
View File
@@ -0,0 +1,44 @@
---
title: Harvester 集成
weight: 10
---
Harvester 是 Rancher 2.6.1 新增的功能，[Harvester](https://docs.harvesterhci.io/) 是基于 Kubernetes 构建的开源超融合基础架构 (HCI) 软件。Harvester 安装在裸金属服务器上，提供集成的虚拟化和分布式存储功能。虽然 Harvester 使用 Kubernetes 运行，但它不需要用户了解 Kubernetes 概念，因此是一个更加用户友好的应用。
---
**_v2.6.3 的新功能_**
Harvester 已 GA。有关所有更新，请参阅 [Harvester 发行说明](https://github.com/harvester/harvester/releases)。
---
### 功能开关
你可以使用 Harvester 的功能开关来管理 Harvester 在 Rancher 虚拟化管理页面的访问，用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。Harvester 的功能开关是默认启用的。如需了解 Rancher 中功能开关的更多详细信息，请单击[此处](../../pages-for-subheaders/enable-experimental-features.md)。
要导航到 Harvester 集群，请单击 **☰ > 虚拟化管理**。在 **Harvester 集群**页面中，单击集群以转到该 Harvester 集群的视图。
* 如果启用了 Harvester 功能开关，则会从列出 Kubernetes 集群的任何页面或应用（例如 Fleet 和多集群应用）中过滤掉 Harvester 集群。
* 如果禁用了 Harvester 功能开关，并且导入了 Harvester 集群，Harvester 集群将显示在**集群管理**页面的 Rancher 集群列表中。仅当功能开关为关闭时，Harvester 集群才会显示在集群列表中。
* 集成 Harvester 后，你可以将 Harvester 集群导入 Rancher，对应的集群类型是 `Harvester`。
* 用户只能在**虚拟化管理**页面上导入 Harvester 集群。在**集群管理**页面上导入集群是不支持的，而且会出现警告。建议你返回**虚拟化管理**页面执行此操作。
### Harvester 主机驱动
在 Rancher 的 RKE 和 RKE2 选项中，[Harvester 主机驱动](https://docs.harvesterhci.io/v0.3/rancher/node-driver/)被标记为`技术预览`。在**创建**页面和启用驱动后的页面都是一样的情况。无论 Harvester 功能开关是否启用，主机驱动都是可用的。请注意，默认情况下主机驱动是关闭的。用户只能通过**集群管理**页面在 Harvester 上创建 RKE 或 RKE2 集群。
Harvester 允许通过 Harvester UI 上传和显示 `.ISO` 镜像，但 Rancher UI 不支持。这是因为 `.ISO` 镜像通常需要额外的设置，这会干扰干净的部署（即无需用户干预），并且它们通常不用于云环境。
如需了解 Rancher 中主机驱动的更多详细信息，请单击[此处](../../pages-for-subheaders/about-provisioning-drivers.md#主机驱动)。
### 限制
---
**仅适用于 Rancher v2.6.1 和 v2.6.2**：
- Harvester 0.3.0 不支持离线环境安装。
- 不支持将 Harvester 0.2.0 升级到 0.3.0，也不支持升级到新的 1.0.0 版本。
---
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/istio/configuration-options/install-istio-on-rke2-cluster.md
+38
View File
@@ -0,0 +1,38 @@
---
title: 在 RKE2 集群上安装 Istio 的其他步骤
weight: 3
---
通过**应用 & 应用市场**页面安装或升级 Istio Helm Chart 时：
1. 如果要安装 Chart，请单击**在安装前自定义 Helm 选项**，然后单击**下一步**。
1. 你将看到配置 Istio Helm Chart 的选项。在**组件**选项卡上，选中**启用 CNI** 旁边的框。
1. 添加一个自定义覆盖文件，该文件指定 `cniBinDir` 和 `cniConfDir`。有关这些选项的更多信息，请参阅 [Istio 文档](https://istio.io/latest/docs/setup/additional-setup/cni/#helm-chart-parameters)。下方是一个示例：
```yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
components:
cni:
enabled: true
k8s:
overlays:
- apiVersion: "apps/v1"
kind: "DaemonSet"
name: "istio-cni-node"
patches:
- path: spec.template.spec.containers.[name:install-cni].securityContext.privileged
value: true
values:
cni:
image: rancher/mirrored-istio-install-cni:1.9.3
excludeNamespaces:
- istio-system
- kube-system
logLevel: info
cniBinDir: /opt/cni/bin
cniConfDir: /etc/cni/net.d
```
**结果**：现在你应该可以根据需要使用 Istio，包括 Sidecar 注入和通过 Kiali 进行监控。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/istio/configuration-options/pod-security-policies.md
+54
View File
@@ -0,0 +1,54 @@
---
title: 在具有 Pod 安全策略的情况下启用 Istio
weight: 1
---
如果你启用了限制性 Pod 安全策略（Pod Security Policy），由于 Istio 需要某些权限才能自行安装和管理 pod 基础设施，因此 Istio 可能无法正常运行。在本文中，我们将配置一个为 Istio 启用了 PSP 的集群，并设置 Istio CNI 插件。
Istio CNI 插件不再要求每个应用 pod 具有特权 `NET_ADMIN` 容器。如需更多信息，请参阅 [Istio CNI 插件文档](https://istio.io/docs/setup/additional-setup/cni)。请注意，[Istio CNI 插件处于 alpha 阶段](https://istio.io/about/feature-stages/)。
:::note 先决条件：
- 集群必须是 RKE Kubernetes 集群。
- 必须使用默认 PodSecurityPolicy 创建集群。
要在使用 Rancher UI 创建 Kubernetes 集群时启用 Pod 安全策略支持，请转到<b>高级选项</b>。在 <b>Pod 安全策略支持</b>中，单击<b>启用</b>，然后选择一个默认的 pod 安全策略。
:::
1. [将 PodSecurityPolicy 设置为不受限制](#1-将-podsecuritypolicy-设置为不受限制)
2. [启用 CNI](#2-启用-cni)
3. [验证 CNI 是否正常工作](#3-验证-cni-是否正常工作)
### 1. 将 PodSecurityPolicy 设置为不受限制
不受限制的 PSP 支持安装 Istio。
在安装 Istio 的项目或计划安装 Istio 的项目中，将 PSP 设置为 `unrestricted`。
1. 点击 **☰ > 集群管理**。
1. 选择你创建的集群，并点击 **Explore**。
1. 单击**集群 > 项目/命名空间**。
1. 找到**项目: System**，然后选择 **⋮ > 编辑配置**。
1. 将 Pod 安全策略选项更改为不受限制，然后单击**保存**。
### 2. 启用 CNI
通过**应用 & 应用市场**安装或升级 Istio 时：
1. 单击**组件**。
2. 选中**启用 CNI**旁边的框。
3. 完成 Istio 的安装或升级。
你也可以通过编辑 `values.yaml` 来启用 CNI：
```
istio_cni.enabled: true
```
在集群中启用 CNI 后，Istio 应该能成功安装。
### 3. 验证 CNI 是否正常工作
通过部署[示例应用](https://istio.io/latest/docs/examples/bookinfo/)或部署你自己的应用，来验证 CNI 是否正常工作。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/istio/configuration-options/project-network-isolation.md
+22
View File
@@ -0,0 +1,22 @@
---
title: 项目网络隔离的其他步骤
weight: 4
---
在集群中：
- 你同时使用了 Canal 网络插件与 Rancher 2.5.8 之前版本，或者同时使用了 Rancher 2.5.8+ 以及任意支持执行 Kubernetes 网络策略的 RKE 网络插件（例如 Canal 或 Cisco ACI 插件）。
- 启用了项目网络隔离选项。
- 安装了 Istio Ingress 模块。
默认情况下，Istio Ingress Gateway pod 无法将入口流量重定向到工作负载。这是因为安装了 Istio 的命名空间无法访问所有命名空间。为此你有两个选项。
第一个选项是在需要让 Istio 控制入口的每个命名空间中添加一个新的网络策略。你的策略需要包括以下几行：
```
- podSelector:
matchLabels:
app: istio-ingressgateway
```
第二个选项是将 `istio-system` 命名空间移动到 `system` 项目中，默认情况下该项目被排除在网络隔离之外。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md
+121
View File
@@ -0,0 +1,121 @@
---
title: 选择器和抓取配置
weight: 2
---
Monitoring 应用设置了 `prometheus.prometheusSpec.ignoreNamespaceSelectors=false`，即在默认情况下跨所有命名空间进行监控。
这样，你可以查看部署在具有 `istio-injection=enabled` 标签的命名空间中的资源的流量、指标和图。
如果你想将 Prometheus 限制为特定的命名空间，请设置 `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`。完成此操作后，你需要添加其他配置来继续监控你的资源。
### 通过将 ignoreNamespaceSelectors 设置为 True 来限制对特定命名空间的监控
要限制对特定命名空间的监控，你需要编辑 `ignoreNamespaceSelectors` Helm Chart 选项。你可以在安装或升级 Monitoring Helm Chart 时配置此选项：
1. 安装或升级 Monitoring Helm Chart 时，编辑 values.yml 并设置 `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`。
1. 完成安装或升级。
**结果**：Prometheus 将仅用于特定命名空间。换言之，你需要设置以下配置之一才能继续在各种仪表板中查看数据。
### 让 Prometheus 检测其他命名空间中的资源
如果设置了 `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`，则有两种方法让 Prometheus 检测其他命名空间中的资源：
- **监控特定的命名空间**：在命名空间中添加一个 ServiceMonitor 或 PodMonitor 以及要抓取的目标。
- **跨命名空间监控**：将 `additionalScrapeConfig` 添加到你的 rancher-monitoring 实例，从而抓取所有命名空间中的所有目标。
### 监控特定命名空间：创建 ServiceMonitor 或 PodMonitor
此选项用于定义在特定命名空间中要监控的服务或 pod。
可用性权衡指的是，由于你无法跨命名空间进行监控，因此你必须为每个命名空间创建 ServiceMonitor 或 PodMonitor。
:::note 先决条件：
为 `<your namespace>` 定义 ServiceMonitor 或 PodMonitor。下面提供了一个 ServiceMonitor 示例。
:::
1. 点击 **☰ > 集群管理**。
1. 选择你创建的集群，并点击 **Explore**。
1. 在顶部导航栏中，打开 kubectl shell。
1. 如果 ServiceMonitor 或 PodMonitor 文件存储在本地集群中，请运行 `kubectl create -f <name of service/pod monitor file>.yaml`。
1. 如果 ServiceMonitor 或 PodMonitor 没有存储在本地，请运行 `cat<< EOF | kubectl apply -f -`，将文件内容粘贴到终端，然后运行 ​​`EOF` 来完成命令。
1. 运行 `kubectl label namespace <your namespace> istio-injection=enabled` 来启用 Envoy sidecar 注入。
**结果**：Prometheus 可以抓取 `<your namespace>`。
<figcaption>Istio 代理的 ServiceMonitor 示例</figcaption>
```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: envoy-stats-monitor
namespace: istio-system
labels:
monitoring: istio-proxies
spec:
selector:
matchExpressions:
- {key: istio-prometheus-ignore, operator: DoesNotExist}
namespaceSelector:
any: true
jobLabel: envoy-stats
endpoints:
- path: /stats/prometheus
targetPort: 15090
interval: 15s
relabelings:
- sourceLabels: [__meta_kubernetes_pod_container_port_name]
action: keep
regex: '.*-envoy-prom'
- action: labeldrop
regex: "__meta_kubernetes_pod_label_(.+)"
- sourceLabels: [__meta_kubernetes_namespace]
action: replace
targetLabel: namespace
- sourceLabels: [__meta_kubernetes_pod_name]
action: replace
targetLabel: pod_name
```
### 跨命名空间监控：将 ignoreNamespaceSelectors 设置为 False
此设置为 Prometheus 提供额外的抓取配置来实现跨命名空间监控。
可用性权衡指的是 Prometheus 的所有 `additionalScrapeConfigs` 都维护在一个 Secret 中。如果在安装 Istio 之前已经使用 additionalScrapeConfigs 部署了监控，升级可能会变得困难。
1. 安装或升级 Monitoring Helm Chart 时，编辑 values.yml 并将 `prometheus.prometheusSpec.additionalScrapeConfigs` 数组设置为下方的**其它抓取配置**。
1. 完成安装或升级。
**结果**：Promethe 会抓取所有带有 `istio-injection=enabled` 标签的命名空间。
<figcaption>其它抓取配置</figcaption>
```yaml
- job_name: 'istio/envoy-stats'
scrape_interval: 15s
metrics_path: /stats/prometheus
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_container_port_name]
action: keep
regex: '.*-envoy-prom'
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
action: replace
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:15090
target_label: __address__
- action: labelmap
regex: __meta_kubernetes_pod_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: pod_name
```
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/istio/cpu-and-memory-allocations.md
+64
View File
@@ -0,0 +1,64 @@
---
title: CPU 和内存分配
weight: 1
---
本文介绍我们建议在集群中分配给 Istio 组件的最少计算资源。
每个组件的 CPU 和内存分配是[可配置](#配置资源分配)的。
在启用 Istio 之前，建议你先确认你的 Rancher worker 节点是否有足够的 CPU 和内存来运行 Istio 的所有组件。
:::tip
在规模较大的部署中，我们强烈建议通过为每个 Istio 组件添加节点选择器，来将基础设施放置在集群中的专用节点上。
:::
下表总结了每个核心 Istio 组件推荐配置的 CPU 和内存的最低资源请求和限制。
Kubernetes 中的资源请求指的是，除非该节点至少具有指定数量的可用内存和 CPU，否则工作负载不会部署在节点上。如果工作负载超过 CPU 或内存的限制，则可以将其从节点中终止或驱逐。有关管理容器资源限制的更多信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)。
| 工作负载 | CPU - 请求 | 内存 - 请求 | CPU - 限制 | 内存 - 限制 |
|----------------------|---------------|------------|-----------------|-------------------|
| 入口网关 | 100m | 128mi | 2000m | 1024mi |
| 出口网关 | 100m | 128mi | 2000m | 1024mi |
| istiod | 500m | 2048mi | 没有限制 | 没有限制 |
| proxy | 10m | 10mi | 2000m | 1024mi |
| **总计：** | **710m** | **2314Mi** | **6000m** | **3072Mi** |
## 配置资源分配
你可以为每种类型的 Istio 组件单独配置资源分配。本节介绍了每个组件默认分配的资源。
为了更轻松地将工作负载调度到节点，集群管理员可以降低组件的 CPU 和内存资源请求。默认 CPU 和内存分配是我们推荐的最小值。
关于 Istio 配置的更多信息，请参阅 [Istio 官方文档](https://istio.io/)。
要配置分配给 Istio 组件的资源：
1. 点击 **☰ > 集群管理**。
1. 选择你创建的集群，并点击 **Explore**。
1. 在左侧导航栏中，点击**应用 & 应用市场**。
1. 点击**已安装的应用**。
1. 转到 `istio-system` 命名空间。在某个 Istio 工作负载中（例如 `rancher-istio`），点击**⋮ > 编辑/升级**。
1. 点击**升级**，然后通过更改 values.yaml 或添加[覆盖文件](../../../pages-for-subheaders/configuration-options.md#覆盖文件)来编辑基本组件。有关编辑覆盖文件的更多信息，请参阅[本节](cpu-and-memory-allocations.md#编辑覆盖文件)。
1. 更改 CPU 或内存分配、调度各个组件的节点，或节点容忍度。
1. 点击**升级**。然后，更改就能启用。
**结果**：已更新 Istio 组件的资源分配。
### 编辑覆盖文件
覆盖文件可以包含 [Istio Operator 规范](https://istio.io/latest/docs/reference/config/istio.operator.v1alpha1/#IstioOperatorSpec)中的任意值。包含 Istio 应用的覆盖文件只是覆盖文件潜在配置的一个示例。
只要文件包含 `kind: IstioOperator` 且 YAML 选项有效，文件就可以用作覆盖。
在 Istio 应用提供的示例覆盖文件中，以下部分能让你更改 Kubernetes 资源：
```
# k8s:
# resources:
# requests:
# cpu: 200m
```
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/istio/disable-istio.md
+43
View File
@@ -0,0 +1,43 @@
---
title: 禁用 Istio
weight: 4
---
本文介绍如何在集群中卸载 Istio，以及如何在命名空间或工作负载中禁用 Istio。
## 在集群中卸载 Istio
要卸载 Istio：
1. 点击 **☰ > 集群管理**。
1. 选择你创建的集群，并点击 **Explore**。
1. 在左侧导航栏中，单击**应用 & 应用市场 > 已安装的应用**。
1. 在 `istio-system` 命名空间中，转到 `rancher-istio` 并单击 **⋮ > 删除**。
1. 删除 `rancher-istio` 后，选择 `istio-system` 命名空间中所有剩余的应用，然后单击**删除**。
**结果**：已删除集群中的 `rancher-istio` 应用。Istio sidecar 不能部署在集群中的任何工作负载上。
:::note
你不能再禁用和重新启用你的 Istio 安装。如果你想保存设置以供将来的安装使用，请查看并保存各个 YAML，以便在之后的安装中参考/重复使用。
:::
**卸载疑难解答**：如果你没有按照卸载步骤操作，则可能会在卸载过程中遇到以下警告：
`Error: uninstallation completed with 1 error(s): unable to build kubernetes objects for delete: unable to recognize "": no matches for kind "MonitoringDashboard" in version "monitoring.kiali.io/v1alpha1"`
这可能意味着几种情况。第一种情况是你选择了 `istio-system` 命名空间中的所有应用并同时删除了它们，另一种情况是你在删除 `rancher-istio` Chart 之前删除了`rancher-istio` Chart 依赖项。由于卸载未正确完成，你将需要手动清理 `istio-system` 命名空间中剩余的资源。如果不想进行手动清理，你可以重新安装 `rancher-istio`，然后按照正确的顺序卸载它。
## 在命名空间中禁用 Istio
1. 点击 **☰ > 集群管理**。
1. 选择你创建的集群，并点击 **Explore**。
1. 单击**集群 > 项目/命名空间**。
1. 转到要启用 Istio 的命名空间，然后单击**⋮ > 启用 Istio 自动注入**。或者，你也可以单击命名空间，然后在命名空间详情页面上，单击**⋮ > 启用 Istio 自动注入**。
**结果**：如果工作负载部署到此命名空间，它们将没有 Istio sidecar。
## 从工作负载中移除 Istio Sidecar
在命名空间中禁用 Istio，然后重新部署其中的工作负载。这些工作负载将在没有 Istio sidecar 的情况下部署。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/istio/rbac-for-istio.md
+44
View File
@@ -0,0 +1,44 @@
---
title: RBAC
weight: 3
---
本文介绍访问 Istio 功能所需的权限。
Rancher Istio Chart 安装了三个 `ClusterRole`。
## Cluster-Admin 访问
默认情况下，只有具有 `cluster-admin` `ClusterRole` 的用户可以：
- 在集群中安装 Istio 应用。
- 为 Istio 配置资源分配。
## Admin 和 Edit 权限
默认情况下，只有 Admin 和 Edit 角色可以：
- 为命名空间启用和禁用 Istio sidecar 自动注入。
- 将 Istio sidecar 添加到工作负载。
- 查看集群的流量指标和流量图。
- 配置 Istio 的资源（例如网关、目标规则或虚拟服务）。
## Kubernetes 默认角色的默认权限摘要
Istio 创建了三个 `ClusterRole`，并将 Istio CRD 访问权限添加到以下默认 K8s `ClusterRole`：
| Chart 创建的 ClusterRole | 默认 K8s ClusterRole | Rancher 角色 |
------------------------------:| ---------------------------:|---------:|
| `istio-admin` | admin | 项目所有者 |
| `istio-edit` | edit | 项目成员 |
| `istio-view` | view | 只读 |
Rancher 将继续使用 cluster-owner、cluster-member、project-owner、project-member 等作为角色名称，但会使用默认角色来确定访问权限。每个默认的 K8s `ClusterRole` 都有不同的 Istio CRD 权限以及可以执行的 K8s 操作，包括 Create (C)，Get (G)，List (L)，Watch (W)，Update (U)，Patch (P)，Delete (D) 和 All (*)。
| CRD | Admin | Edit | View |
|----------------------------| ------| -----| -----
| <ul><li>`config.istio.io`</li><ul><li>`adapters`</li><li>`attributemanifests`</li><li>`handlers`</li><li>`httpapispecbindings`</li><li>`httpapispecs`</li><li>`instances`</li><li>`quotaspecbindings`</li><li>`quotaspecs`</li><li>`rules`</li><li>`templates`</li></ul></ul> | GLW | GLW | GLW |
| <ul><li>`networking.istio.io`</li><ul><li>`destinationrules`</li><li>`envoyfilters`</li><li>`gateways`</li><li>`serviceentries`</li><li>`sidecars`</li><li>`virtualservices`</li><li>`workloadentries`</li></ul></ul> | * | * | GLW |
| <ul><li>`security.istio.io`</li><ul><li>`authorizationpolicies`</li><li>`peerauthentications`</li><li>`requestauthentications`</li></ul></ul> | * | * | GLW |
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md
+75
View File
@@ -0,0 +1,75 @@
---
title: Flows 和 ClusterFlows
weight: 1
---
有关配置 `Flow` 和 `ClusterFlow` 的完整详细信息，请参阅 [Banzai Cloud Logging Operator 文档](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/flow/)。
## Flows
`Flow` 定义要收集和过滤哪些日志，以及将日志发送到哪个 Output。
`Flow` 是一个命名空间资源。换言之，只有部署了该 Flow 的命名空间日志才能被 `Flow` 收集。
你可以通过在 Rancher UI 中填写表单来配置 `Flow`。
有关 `Flow` 自定义资源的更多详细信息，请参阅 [FlowSpec](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/flow_types/)。
### Matches
匹配语句用于选择从哪些容器中拉取日志。
你可以指定 match 语句，然后根据 Kubernetes 标签、容器和主机名来选择或排除日志。匹配语句会按照定义和处理的顺序进行评估，直到应用了第一个匹配的选择/排除规则。
你可以通过填写 Rancher UI 中的 `Flow` 或 `ClusterFlow` 表单来配置匹配。
使用 match 语句的详细示例，请参阅[日志路由的官方文档](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/log-routing/)。
### Filters
你可以在 `Flow` 中定义一个或多个过滤器。过滤器可以对日志执行各种操作，例如，添加其他数据、转换日志或解析记录中的值。`Flow` 中的过滤器会按定义的顺序应用。
有关 Banzai Cloud Logging Operator 支持的过滤器列表，请参阅[此页面](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/filters/)。
过滤器需要在 YAML 中配置。
### Outputs
此 `Output` 会接收来自 `Flow` 的日志。由于 `Flow` 是一个命名空间资源，因此 `Output` 必须与 `Flow` 位于相同的命名空间中。
在 Rancher UI 中填写 `Flow` 或 `ClusterFlow` 表单时，你可以引用`Output`。
## ClusterFlows
为 `ClusterFlow` 配置匹配、过滤器和 `Output` 的方式与 `Flow` 的配置方式相同。主要区别在于 `ClusterFlow` 是集群级别的，并且可以跨所有命名空间配置日志收集。
你可以通过在 Rancher UI 中填写表单来配置 `ClusterFlow`。
`ClusterFlow` 选择集群中所有命名空间的日志后，集群的日志会被收集并记录到所选的 `ClusterOutput`。
## YAML 示例
以下示例 `Flow` 转换了默认命名空间的日志消息，并将日志发送到 S3 `Output`：
```yaml
apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow
metadata:
name: flow-sample
namespace: default
spec:
filters:
- parser:
remove_key_name_field: true
parse:
type: nginx
- tag_normaliser:
format: ${namespace_name}.${pod_name}.${container_name}
localOutputRefs:
- s3-output
match:
- select:
labels:
app: nginx
```
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md
+294
View File
@@ -0,0 +1,294 @@
---
title: Outputs 和 ClusterOutputs
weight: 2
---
有关配置 `Output` 和 `ClusterOutput` 的完整详细信息，请参阅 [Banzai Cloud Logging Operator 文档](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/)。
## Outputs
`Output` 资源定义了你的 `Flow` 可以发送日志消息的位置。`Output` 是 Logging `Flow` 的最后阶段。
`Output` 是命名空间资源，换言之，只有同一命名空间内的 `Flow` 可以访问它。
你可以在这些定义中使用密文，但这些密文也必须位于同一命名空间中。
你可以通过在 Rancher UI 中填写表单来配置 `Output`。
有关 `Output` 自定义资源的更多详细信息，请参阅 [OutputSpec](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/output_types/)。
Rancher UI 提供了用于配置以下类型 `Output` 的表单：
- Amazon ElasticSearch
- Azure Storage
- Cloudwatch
- Datadog
- Elasticsearch
- File
- Fluentd
- GCS
- Kafka
- Kinesis Stream
- LogDNA
- LogZ
- Loki
- New Relic
- Splunk
- SumoLogic
- Syslog
Rancher UI 提供了用于配置 `Output` 类型、目标和访问凭证（如果适用）的表单。
有关 Logging Operator 支持的日志插件配置示例，请参阅 [Logging Operator 文档](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/)。
## ClusterOutputs
`ClusterOutput` 定义了一个没有命名空间限制的 `Output`。只有在与 Logging Operator 部署在同一命名空间中时，它才能生效。
你可以通过在 Rancher UI 中填写表单来配置 `ClusterOutput`。
有关 `ClusterOutput` 自定义资源的更多详细信息，请参阅 [ClusterOutput](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)。
## YAML 示例
安装 Logging 后，你可以参考以下示例来构建你自己的 Logging 流水线：
- [ClusterOutput 设为 ElasticSearch](#clusteroutput-设为-elasticsearch)
- [Output 设为 Splunk](#output-设为-splunk)
- [Output 设为 Syslog](#output-设为-syslog)
- [不支持的 Output](#不支持的-output)
### ClusterOutput 设为 ElasticSearch
假设你想将集群中的所有日志发送到 `elasticsearch` 集群。首先，创建一个集群 `Output`：
```yaml
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterOutput
metadata:
name: "example-es"
namespace: "cattle-logging-system"
spec:
elasticsearch:
host: elasticsearch.example.com
port: 9200
scheme: http
```
在与 Operator 相同的命名空间（`cattle-logging-system`）中，我们创建了这个 `ClusterOutput`（没有 elasticsearch 配置）。每次创建 `ClusterFlow` 或 `ClusterOutput` 时，我们都必须将其放在 `cattle-logging-system` 命名空间中。
配置日志的目的位置后，我们可以尝试将所有日志都配置到该 `ClusterOutput`：
```yaml
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow
metadata:
name: "all-logs"
namespace: "cattle-logging-system"
spec:
globalOutputRefs:
- "example-es"
```
现在，我们应该能看到配置的包含日志的索引。
### Output 设为 Splunk
有时候，你的应用程序团队可能只想将某个命名空间的日志发送到 `splunk` 服务器。对于这种情况，你可以使用命名空间范围的 `Output` 和 `Flow`。
在开始之前，先设置该团队的应用程序 `coolapp`。
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: devteam
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: coolapp
namespace: devteam
labels:
app: coolapp
spec:
replicas: 2
selector:
matchLabels:
app: coolapp
template:
metadata:
labels:
app: coolapp
spec:
containers:
- name: generator
image: paynejacob/loggenerator:latest
```
`coolapp` 运行时，我们将使用与创建 `ClusterOutput` 时类似的路径。但是，我们不使用 `ClusterOutput`，而是在应用程序的命名空间中创建 `Output`。
```yaml
apiVersion: logging.banzaicloud.io/v1beta1
kind: Output
metadata:
name: "devteam-splunk"
namespace: "devteam"
spec:
splunkHec:
hec_host: splunk.example.com
hec_port: 8088
protocol: http
```
然后，再次为 `Output` 提供一些日志：
```yaml
apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow
metadata:
name: "devteam-logs"
namespace: "devteam"
spec:
localOutputRefs:
- "devteam-splunk"
```
### Output 设为 Syslog
假设你想将集群中的所有日志发送到 `syslog` 服务器。首先，我们创建一个 `ClusterOutput`：
```yaml
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterOutput
metadata:
name: "example-syslog"
namespace: "cattle-logging-system"
spec:
syslog:
buffer:
timekey: 30s
timekey_use_utc: true
timekey_wait: 10s
flush_interval: 5s
format:
type: json
app_name_field: test
host: syslog.example.com
insecure: true
port: 514
transport: tcp
```
配置日志的目的位置后，我们可以尝试将所有日志都配置到该 `Output`：
```yaml
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow
metadata:
name: "all-logs"
namespace: cattle-logging-system
spec:
globalOutputRefs:
- "example-syslog"
```
### 不支持的 Output
对于最后一个示例，我们创建一个 `Output` 来将日志写入到不是开箱即用的目标位置：
:::note Syslog 注意事项：
`Syslog` 是受支持的 `Output`。但是，此示例仍提供了不受支持的插件概述。
:::
```yaml
apiVersion: v1
kind: Secret
metadata:
name: syslog-config
namespace: cattle-logging-system
type: Opaque
stringData:
fluent-bit.conf: |
[INPUT]
Name forward
Port 24224
[OUTPUT]
Name syslog
InstanceName syslog-output
Match *
Addr syslog.example.com
Port 514
Cluster ranchers
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: fluentbit-syslog-forwarder
namespace: cattle-logging-system
labels:
output: syslog
spec:
selector:
matchLabels:
output: syslog
template:
metadata:
labels:
output: syslog
spec:
containers:
- name: fluentbit
image: paynejacob/fluent-bit-out-syslog:latest
ports:
- containerPort: 24224
volumeMounts:
- mountPath: "/fluent-bit/etc/"
name: configuration
volumes:
- name: configuration
secret:
secretName: syslog-config
---
apiVersion: v1
kind: Service
metadata:
name: syslog-forwarder
namespace: cattle-logging-system
spec:
selector:
output: syslog
ports:
- protocol: TCP
port: 24224
targetPort: 24224
---
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow
metadata:
name: all-logs
namespace: cattle-logging-system
spec:
globalOutputRefs:
- syslog
---
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterOutput
metadata:
name: syslog
namespace: cattle-logging-system
spec:
forward:
servers:
- host: "syslog-forwarder.cattle-logging-system"
require_ack_response: false
ignore_network_errors_at_startup: false
```
现在，我们分解这里的内容。首先，我们创建一个容器 Deployment，该容器具有额外的 `syslog` 插件并支持转发自另一个 `fluentd` 的日志。接下来，我们创建一个配置为 Deployment 转发器的 `Output`。然后，Deployment `fluentd` 会将所有日志转发到配置的 `syslog` 目标。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/logging/logging-architecture.md
+29
View File
@@ -0,0 +1,29 @@
---
title: 架构
weight: 1
---
本节介绍了 Rancher Logging 应用程序的架构。
有关 Banzai Cloud Logging Operator 工作原理的更多详细信息，请参阅[官方文档](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture)。
### Banzai Cloud Logging Operator 工作原理
Logging Operator 自动部署和配置 Kubernetes 日志流水线。它会在每个节点上部署和配置一个 Fluent Bit DaemonSet，从而收集节点文件系统中的容器和应用程序日志。
Fluent Bit 查询 Kubernetes API 并使用 pod 的元数据来丰富日志，然后将日志和元数据都传输到 Fluentd。Fluentd 会接收和过滤日志并将日志传输到多个`Output`。
以下自定义资源用于定义了如何过滤日志并将日志发送到 `Output`：
- `Flow` 是一个命名空间自定义资源，它使用过滤器和选择器将日志消息路由到对应的 `Output`。
- `ClusterFlow` 用于路由集群级别的日志消息。
- `Output` 是一个命名空间资源，用于定义发送日志消息的位置。
- `ClusterOutput` 定义了一个所有 `Flow` 和 `ClusterFlow` 都可用的 `Output`。
每个 `Flow` 都必须引用一个 `Output`，而每个 `ClusterFlow` 都必须引用一个 `ClusterOutput`。
[Banzai 文档](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture)中的下图显示了新的 Logging 架构：
<figcaption>Banzai Cloud Logging Operator 如何与 Fluentd 和 Fluent Bit 一起使用</figcaption>
![Banzai Cloud Logging Operator 如何与 Fluentd 一起使用](/img/banzai-cloud-logging-operator.png)
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/logging/logging-helm-chart-options.md
+97
View File
@@ -0,0 +1,97 @@
---
title: rancher-logging Helm Chart 选项
shortTitle: Helm Chart 选项
weight: 4
---
### 启用/禁用 Windows 节点 Logging
要启用或禁用 Windows 节点 Logging，你可以在 `values.yaml` 中将 `global.cattle.windows.enabled` 设置为 `true` 或 `false`。
默认情况下，如果使用 Cluster Dashboard UI 在 Windows 集群上安装了 Logging 应用程序，Windows 节点的 Logging 就会启用。
在这种情况下，将 `global.cattle.windows.enabled` 设置为 `false` 会禁用集群上的 Windows 节点 Logging。
禁用后，仍会从 Windows 集群中的 Linux 节点收集日志。
:::note
目前存在一个[问题](https://github.com/rancher/rancher/issues/32325)，在 Windows 集群中禁用 Windows Logging 后执行 `helm upgrade` 时不会删除 Windows nodeAgent。在这种情况下，如果已安装 Windows nodeAgents，用户可能需要手动卸载它们。
:::
### 使用自定义 Docker 根目录
如果使用了自定义 Docker 根目录，你可以在 `values.yaml` 中设置 `global.dockerRootDirectory`。
这将确保创建的 Logging CR 使用你指定的路径，而不是使用默认的 Docker `data-root` 位置。
请注意，这只影响 Linux 节点。
如果集群中有任何 Windows 节点，则更改将不适用于这些节点。
### 为自定义污点添加 NodeSelector 设置和容忍度
你可以添加 `nodeSelector` 设置，并通过编辑 Logging Helm Chart 值来添加其他`容忍度`。有关详细信息，请参阅[此页面](taints-and-tolerations.md)。
### 启用 Logging 应用程序以使用 SELinux
:::note 要求：
Logging v2 已在 RHEL/CentOS 7 和 8 上使用 SELinux 进行了测试。
:::
[安全增强型 Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是对 Linux 的安全增强。被政府机构使用之后，SELinux 已成为行业标准，并在 CentOS 7 和 8 上默认启用。
要配合使用 Logging V2 与 SELinux，我们建议你根据[此页面](../../../pages-for-subheaders/selinux-rpm.md#安装-rancher-selinux-rpm)的安装说明安装 `rancher-selinux` RPM。
然后，在安装 Logging 应用程序时，在 `values.yaml` 中将 `global.seLinux.enabled` 更改为 `true`，使 Chart 支持 SELinux。
### 其他日志来源
默认情况下，Rancher 会收集所有类型集群的 [controlplane 组件](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components)和[节点组件](https://kubernetes.io/docs/concepts/overview/components/#node-components)的日志。
在某些情况下，Rancher 也能收集其他的日志。
下表总结了每种节点类型可以收集的其他日志来源：
| 日志来源 | Linux 节点（包括在 Windows 集群中） | Windows 节点 |
| --- | --- | ---|
| RKE | ✓ | ✓ |
| RKE2 | ✓ | |
| K3s | ✓ | |
| AKS | ✓ | |
| EKS | ✓ | |
| GKE | ✓ | |
要将托管 Kubernetes 的提供商作为额外的日志来源，在安装或升级 Logging Helm Chart 时，请启用 **Enable enhanced cloud provider logging** 选项。
启用后，Rancher 会收集提供商开放可用的所有其他节点和 controlplane 日志，不同提供商可能有所不同。
如果你已经使用了云提供商的日志解决方案，例如 AWS CloudWatch 或 Google Cloud Operations Suite（以前称为 Stackdriver），由于原生解决方案可以不受限制地访问所有日志，因此你无需启用此选项。
### Systemd 配置
在 Rancher Logging 中，你必须为 K3s 和 RKE2 Kubernetes 发行版配置 `SystemdLogPath`。
K3s 和 RKE2 Kubernetes 发行版将日志写入到 journald，它是 systemd 的子系统，用于日志记录。要收集这些日志，你需要定义 `systemdLogPath`。默认路径是 `run/log/journal`，但某些 Linux 发行版不默认使用该路径。例如，Ubuntu 默认使用 `var/log/journal`。要确定你的 `systemdLogPath` 配置，请参阅以下步骤。
**Systemd 配置步骤：**
* 在其中一个节点上运行 `cat /etc/systemd/journald.conf | grep -E ^\#?Storage | cut -d"=" -f2`。
* 如果返回 `persistent`，则你的 `systemdLogPath` 是 `/var/log/journal`。
* 如果返回 `volatile`，则你的 `systemdLogPath` 是 `/run/log/journal`。
* 如果返回 `auto`，则检查 `/var/log/journal` 是否存在。
* 如果 `/var/log/journal` 存在，则使用 `/var/log/journal`。
* 如果 `/var/log/journal` 不存在，则使用 `/run/log/journal`。
:::note 注意事项：
如果返回的值不包括在上述描述中，Rancher Logging 将无法收集 controlplane 日志。要解决此问题，你需要在每个 controlplane 节点上执行以下操作。
* 在 journald.conf 中设置 `Storage=volatile`。
* 重启主机。
* 将 `systemdLogPath` 设置为 `/run/log/journal`。
:::
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md
+189
View File
@@ -0,0 +1,189 @@
---
title: 迁移到 Rancher 2.5 Logging
weight: 2
---
Rancher 2.5 彻底修改了 Logging 功能。我们现在使用了 Banzai Cloud 的 [logging operator](https://github.com/banzaicloud/logging-operator)，Rancher 配置了此工具以供部署 Logging 使用。
在新的 Logging 功能的众多特性和变化中，其中一项是取消了项目级别的 Logging 配置。取而代之的是在命名空间级别配置 Logging。集群级日志仍然可用，但配置选项不同。
## 安装
要在 Rancher 2.5+ 中安装 Logging，请参阅[安装说明](../../../pages-for-subheaders/logging.md#启用-logging)。
### 名词解释
在 Rancher 2.5+ 中，你需要在**集群仪表板**中配置 Logging。要在安装 Logging 应用程序后配置 Logging 自定义资源，请转到左侧导航栏并单击 **Logging**。这个菜单的选项可以配置集群和命名空间的 Logging。
:::note
Logging 是按集群安装的。你将需要在集群之间切换以配置每个集群的 Logging。
:::
对于 Rancher 2.5+ 中的 Logging 应用程序，你需要了解以下四个关键概念：
1. Outputs
`Outputs` 是一种配置资源，用于确定收集日志的目的位置。这是存储 ElasticSearch、Kafka 等聚合器设置的地方。`Outputs` 是命名空间资源。
2. Flows
`Flows` 是一种配置资源，用于确定日志的收集、过滤和目标位置规则。在一个 Flow 中，你需要配置要收集哪些日志、如何改变或过滤它们，以及将日志发送到哪个 `Output`。`Flows` 是命名空间资源，可以连接到同一命名空间中的 `Output` 或 `ClusterOutput`。
3. ClusterOutputs
`ClusterOutputs` 的功能与 `Outputs` 相同，但 ClusterOutput 是集群级别资源。在集群范围内收集日志或要为集群中的所有命名空间提供 `Output` 时，`ClusterOutput` 是必需的。
4. ClusterFlows
`ClusterFlows` 的功能与 `Flows` 相同，但 ClusterFlow 是集群级别资源。它们用于为整个集群配置日志收集，而不是在命名空间级别进行逐个配置。`ClusterFlows` 也是定义改变和过滤器的地方，在功能上与 `Flows` 相同。
## 集群日志
要在 Rancher 2.5+ 中配置集群级别的 Logging，你需要设置 `ClusterFlow`。此对象定义了日志的来源、要应用的转换或过滤器，以及日志的一个或多个 `Output`。
:::note 重要提示：
`ClusterFlow` 必须在 `cattle-logging-system` 命名空间中定义。如果在其他命名空间中定义，`ClusterFlow` 将不起作用。
:::
在旧版 Logging 中，如果要收集整个集群的日志，你只需要启用集群级别的 Logging 并定义所需的 `Output`。Rancher 2.5+ Logging 保留了这个基本方法。要复制旧版集群级别日志，请执行以下步骤：
1. 根据[输出配置](#输出配置)下的说明定义 `ClusterOutput`。
2. 创建一个 `ClusterFlow`，确保它在 `cattle-logging-system` 命名空间中创建。
1. 删除 `Flow` 定义的所有 _Include_ 和 _Exclude_ 规则。这将确保能收集所有日志。
2. 如果不需要，你可以不配置任何过滤器（默认不需要创建）。
3. 定义你的集群 `Output`。
操作完成后，集群中所有源（所有 pod 和所有系统组件）上收集的日志都会发送到定义在 `ClusterFlow` 中的 `Output` 处。
## 项目日志
Rancher 2.5+ Logging 不支持项目。换言之，如果要收集运行在项目命名空间中的 pod 日志，你需要为这些命名空间定义 `Flow`。
要收集指定命名空间的日志，请执行以下步骤：
1. 根据[输出配置](#输出配置)下的说明定义 `Output` 或 `ClusterOutput`。
2. 创建一个 `Flow`，确保它在你要收集日志的命名空间中创建。
1. 如果有需要，你可以定义 _Include_ 或 _Exclude_ 规则。如果删除所有规则，则会收集目标命名空间中的所有 pod 日志。
2. 如果不需要，你可以不配置任何过滤器（默认不需要创建）。
3. 定义你的 Output，可以是 `ClusterOutput` 或 `Output` 对象。
操作完成后，命名空间中所有源（pod）上收集的日志都会发送到你在 `Flow` 中定义的 `Output` 处。
:::note
要收集项目中的日志，请在项目中的每个命名空间中重复上述步骤。你也可以使用通用标签（例如 `project=my-project`）标记你的项目工作负载，并使用 `ClusterFlow` 收集匹配此标签的所有 pod 的日志。
:::
## 输出配置
旧版 Logging 中有五个日志目标位置可供选择，分别是 Elasticsearch、Splunk、Kafka、Fluentd 和 Syslog。除 Syslog 外，这些目标位置都可用于 2.5+ Logging。
### Elasticsearch
| 旧版 Logging | 2.5+ Logging | 注意 |
|-----------------------------------------------|-----------------------------------|-----------------------------------------------------------|
| 端点 | Target -> Host | 确保指定了协议 (https/http) 以及端口。 |
| X-Pack Security -> Username | Access -> User | |
| X-Pack Security -> Password | Access -> Password | 密码必须存储在密文中。 |
| SSL Configuration -> Client Private Key | SSL -> Client Key | 密钥必须存储在密文中。 |
| SSL Configuration -> Client Certificate | SSL -> Client Cert | 证书必须存储在密文中。 |
| SSL Configuration -> Client Key Password | SSL -> Client Key Pass | 密码必须存储在密文中。 |
| SSL Configuration -> Enabled SSL Verification | SSL -> Certificate Authority File | 证书必须存储在密文中。 |
在旧版 Logging 中，索引是根据“索引模式”中的格式自动创建的。在 2.5 Logging 中，默认的操作已更改为记录单个索引。你仍然可以编辑 YAML 并输入以下值，从而在 `Output` 对象上配置索引模式功能：
```yaml
...
spec:
elasticsearch:
...
logstash_format: true
logstash_prefix: <desired prefix>
logstash_dateformat: "%Y-%m-%d"
```
将 `<desired prefix>` 替换为要创建的索引的前缀。在旧版 Logging 中，默认值是集群的名称。
### Splunk
| 旧版 Logging | 2.5+ Logging | 注意 |
|------------------------------------------|----------------------------------------|----------------------------------------------------------------------------------------|
| HEC Configuration -> Endpoint | Target -> Host | 协议（https/http）和端口必须与主机分开定义。 |
| HEC Configuration -> Token | Access -> Token | 令牌必须作为密文存储。 |
| HEC Configuration -> Index | Edit as YAML -> `index` | `index` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。 |
| HEC Configuration -> Source | Edit as YAML -> `source` | `source` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。 |
| SSL Configuration -> Client Private Key | Edit as YAML -> `client_key` | `client_key` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。详见（1）。 |
| SSL Configuration -> Client Certificate | Edit as YAML -> `client_cert` | `client_cert` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。详见（1）。 |
| SSL Configuration -> Client Key Password | _Not Supported_ | 现在不支持为客户端私钥指定密码。 |
| SSL Configuration -> SSL Verify | Edit as YAML -> `ca_file` or `ca_path` | `ca_file` 或 `ca_path` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。详见（2）。 |
_(1) `client_key` 和 `client_cert` 的值必须分别是密钥和证书文件的路径。这些文件必须挂载到 `rancher-logging-fluentd` pod 中才能使用_。
_(2) 用户可以配置 `ca_file`（PEM 编码的 CA 证书的路径）或 `ca_path`（包含 PEM 格式的 CA 证书的目录路径）。这些文件必须挂载到 `rancher-logging-fluentd` pod 中才能使用_。
### Kafka
| 旧版 Logging | 2.5+ Logging | 注意 |
|-----------------------------------------|----------------------------|------------------------------------------------------|
| Kafka Configuration -> Endpoint Type | - | 不再支持将 Zookeeper 作为端点类型。 |
| Kafka Configuration -> Endpoint | Target -> Brokers | 逗号分隔的 Broker 列表（host:port）。 |
| Kafka Configuration -> Topic | Target -> Default Topic | |
| SSL Configuration -> Client Private Key | SSL -> SSL Client Cert | 证书必须作为密文存储。 |
| SSL Configuration -> Client Certificate | SSL -> SSL Client Cert Key | 密钥必须作为密文存储。 |
| SSL Configuration -> CA Certificate PEM | SSL -> SSL CA Cert | 证书必须作为密文存储。 |
| SASL Configuration -> Username | Access -> Username | 用户名必须存储在密文中。 |
| SASL Configuration -> Password | Access -> Password | 密码必须存储在密文中。 |
| SASL Configuration -> Scram Mechanism | Access -> Scram Mechanism | 输入机制为字符串，例如“sha256”或“sha512”。 |
### Fluentd
v2.5.2 开始只支持使用“以表单编辑”选项来添加单个 Fluentd 服务器。要添加多个服务器，请将 `Output` 编辑为 YAML 并输入多个服务器。
| 旧版 Logging | 2.5+ Logging | 注意 |
|------------------------------------------|-----------------------------------------------------|----------------------------------------------------------------------|
| Fluentd Configuration -> Endpoint | Target -> Host, Port | 分别输入主机和端口。 |
| Fluentd Configuration -> Shared Key | Access -> Shared Key | 共享密钥必须存储为密文。 |
| Fluentd Configuration -> Username | Access -> Username | 用户名必须存储为密文。 |
| Fluentd Configuration -> Password | Access -> Password | 密码必须存储为密文。 |
| Fluentd Configuration -> Hostname | Edit as YAML -> `host` | `host` 字段作为 YAML 键设置在 `spec.forward.servers[n]`下。 |
| Fluentd Configuration -> Weight | Edit as YAML -> `weight` | `weight` 字段作为 YAML 键设置在 `spec.forward.servers[n]`下。 |
| SSL Configuration -> Use TLS | - | 不需要显式启用。定义客户端证书字段即可。 |
| SSL Configuration -> Client Private Key | Edit as YAML -> `tls_private_key_path` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
| SSL Configuration -> Client Certificate | Edit as YAML -> `tls_client_cert_path` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
| SSL Configuration -> Client Key Password | Edit as YAML -> `tls_client_private_key_passphrase` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
| SSL Configuration -> SSL Verify | Edit as YAML -> `tls_insecure_mode` | `spec.forward` 下的字段设置为 YAML 键。默认：`false`。 |
| SSL Configuration -> CA Certificate PEM | Edit as YAML -> `tls_cert_path` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
| Enable Gzip Compression | - | 2.5+ Logging 不再支持。 |
_(1) 这些值将被指定为文件的路径。这些文件必须挂载到 `rancher-logging-fluentd` pod 中才能使用。_
### Syslog
从 v2.5.2 开始，使用 2.5+ Logging 的 `Output` 不支持 syslog。
## 自定义日志字段
要添加自定义日志字段，你需要将以下 YAML 添加到你的 `Flow` 配置中：
```yaml
...
spec:
filters:
- record_modifier:
records:
- foo: "bar"
```
（将 `foo: "bar"` 替换为要添加的自定义日志字段）
## 系统日志
在旧版 Logging 中，你需要在设置集群 Logging 时选中“包括系统日志”来收集系统组件的日志。在 v2.5+ Logging 中，系统日志可以通过以下两种方式之一来收集：
1. 收集所有集群日志，不指定任何匹配或排除规则。该设置会收集集群所有容器的日志，其中包括系统日志。
2. 通过为系统组件添加匹配规则来专门收集系统日志。要收集的组件决定了具体的匹配规则。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/logging/rbac-for-logging.md
+25
View File
@@ -0,0 +1,25 @@
---
shortTitle: RBAC
title: Logging 的 RBAC
weight: 3
---
Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`。
- `logging-admin` 允许用户完全访问命名空间的 `Flow` 和 `Output`。
- `logging-view` 允许用户*查看*命名空间的 `Flow` 和 `Output`，以及 `ClusterFlow` 和 `ClusterOutput`。
:::note 为什么选择一个角色而不是另一个角色？
`ClusterFlow` 和 `ClusterOutput` 资源的编辑权限非常强大。任何拥有该权限的用户都能编辑集群中的所有日志。
:::
在 Rancher 中，集群管理员角色是唯一可以完全访问所有 `rancher-logging` 资源的角色。集群成员无法编辑或读取任何 Logging 资源。项目所有者和成员具有以下权限：
| 项目所有者 | 项目成员 |
--- | ---
| 能够在其项目命名空间中创建命名空间级别的 `Flow` 和 `Output` | 只能查看项目命名空间中的 `Flow` 和 `Output` |
| 可以从项目命名空间中收集任何日志 | 无法在其项目命名空间中收集任何日志 |
如果项目所有者和项目成员需要使用 Logging，他们需要在项目中至少有*一个*命名空间。如果没有，他们可能看不到顶部导航下拉列表中的 Logging 按钮。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/logging/taints-and-tolerations.md
+66
View File
@@ -0,0 +1,66 @@
---
title: 处理污点和容忍度
weight: 6
---
在 Kubernetes 节点上添加污点会导致 pod 排斥在该节点上运行。
除非 pod 对该节点的污点具有`容忍度`（toleration），否则 Pod 将在集群中的其他节点上运行。
[污点和容忍度](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)可以与 `PodSpec` 中的 `nodeSelector` [字段](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)一起使用，从而实现*相反的*污点效果。
`nodeSelector` 可以使 pod 被吸引到某类节点。
两者都能让 pod 选择在哪个节点上运行。
- [Rancher Logging 堆栈中的默认实现](#rancher-日志堆栈中的默认实现)
- [为自定义污点添加 NodeSelector 设置和容忍度](#为自定义污点添加-nodeselector-设置和容忍度)
### Rancher 日志堆栈中的默认实现
默认情况下，Rancher 使用 `cattle.io/os=linux` 来将污点应用到所有 Linux 节点，而不影响 Windows 节点。
日志堆栈 pod 具有针对此污点的`容忍度`，因此它们能够运行在 Linux 节点上。
此外，大多数日志堆栈 pod 仅在 Linux 上运行，并添加了 `nodeSelector` 以确保它们在 Linux 节点上运行。
此示例 Pod YAML 文件显示了与容忍度一起使用的 nodeSelector：
```yaml
apiVersion: v1
kind: Pod
# metadata...
spec:
# containers...
tolerations:
- key: cattle.io/os
operator: "Equal"
value: "linux"
effect: NoSchedule
nodeSelector:
kubernetes.io/os: linux
```
在上面的示例中，我们确保了的 pod 仅在 Linux 节点上运行，并且为所有 Linux 节点上的污点添加了`容忍度`。
你可以对 Rancher 现有的污点或你自己的自定义污点执行相同的操作。
### 为自定义污点添加 NodeSelector 设置和容忍度
如果要添加你自己的 `nodeSelector` 设置，或者要为其他污点添加 `容忍度`，你可以将以下内容传递给 Chart 的值：
```yaml
tolerations:
# insert tolerations...
nodeSelector:
# insert nodeSelector...
```
这些值会将这两个设置添加到 `fluentd`、`fluentbit`和 `logging-operator` 容器中。
本质上，这些是日志堆栈中所有 pod 的全局设置。
但是，如果你想*仅*为 `fluentbit` 容器添加容忍度，你可以将以下内容添加到 Chart 的值中：
```yaml
fluentbit_tolerations:
# insert tolerations list for fluentbit containers only...
```
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/longhorn.md
+71
View File
@@ -0,0 +1,71 @@
---
title: Longhorn - Kubernetes 的云原生分布式块存储
shortTitle: Longhorn 存储
weight: 19
---
[Longhorn](https://longhorn.io/) 是一个轻量级、可靠、易用的 Kubernetes 分布式块存储系统。
Longhorn 是免费的开源软件。Longhorn 最初由 Rancher Labs 开发，现在正在作为云原生计算基金会的沙盒项目进行开发。它可以通过 Helm、kubectl 或 Rancher UI 安装在任何 Kubernetes 集群上。有关其架构的更多信息，请参阅[此处](https://longhorn.io/docs/latest/concepts/)。
使用 Longhorn，你可以：
- 将 Longhorn 卷用作 Kubernetes 集群中分布式有状态应用程序的持久存储
- 将你的块存储分区为 Longhorn 卷，以便在有或没有云提供商的情况下使用 Kubernetes 卷
- 跨多个节点和数据中心复制块存储以提高可用性
- 将备份数据存储在 NFS 或 AWS S3 等外部存储中
- 创建跨集群灾难恢复卷，以便使用另一个 Kubernetes 集群中的备份快速恢复主 Kubernetes 集群中的数据
- 计划卷的定期快照，并将定期备份调度到 NFS 或兼容 S3 的辅助存储
- 使用备份来恢复卷
- 在不中断持久卷的情况下升级 Longhorn
<figcaption>Longhorn 仪表板</figcaption>
![Longhorn 仪表板](/img/longhorn-screenshot.png)
### 使用 Rancher 安装 Longhorn
1. 满足所有[安装要求](https://longhorn.io/docs/latest/deploy/install/#installation-requirements)。
1. 转到要安装 Longhorn 的集群。
1. 单击**应用 & 应用市场**。
1. 单击 **Chart**。
1. 点击 **Longhorn**。
1. 可选：要自定义初始设置，请单击 **Longhorn 默认设置**并编辑配置。如需自定义设置的帮助，请参阅 [Longhorn 文档](https://longhorn.io/docs/latest/references/settings/)。
1. 单击**安装**。
**结果**：Longhorn 已部署到 Kubernetes 集群中。
### 从 Rancher UI 访问 Longhorn
1. 转到安装了 Longhorn 的集群。在左侧导航菜单中，单击 **Longhorn**。
1. 在此页面上，你可以编辑 Longhorn 管理的 Kubernetes 资源。要查看 Longhorn UI，请单击**概述**中的 **Longhorn** 按钮。
**结果**：你将转到 Longhorn UI，你可以在那里管理 Longhorn 卷及其在 Kubernetes 集群中的副本，还可以查看位于另一个 Kubernetes 集群或 S3 中的 Longhorn 存储辅助备份。
### 从 Rancher UI 卸载 Longhorn
1. 转到安装了 Longhorn 的集群，然后单击**应用 & 应用市场**。
1. 点击**已安装的应用**。
1. 转到 `longhorn-system` 命名空间并选中 `longhorn` 和 `longhorn-crd` 应用程序旁边的框。
1. 单击**删除**并确认**删除**。
**结果**：Longhorn 已被卸载。
### GitHub 仓库
Longhorn 项目在[此处](https://github.com/longhorn/longhorn)。
### 文档
Longhorn 文档在[此处](https://longhorn.io/docs/)。
### 架构
Longhorn 为每个卷创建专用的存储控制器，并在存储在多个节点上的多个副本之间同步复制该卷。
存储控制器和副本本身是使用 Kubernetes 编排的。
有关其架构的更多信息，请参阅[此处](https://longhorn.io/docs/latest/concepts/)。
<figcaption>Longhorn 架构</figcaption>
![Longhorn 架构](/img/longhorn-architecture.svg)
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md
+112
View File
@@ -0,0 +1,112 @@
---
title: 内置仪表板
weight: 3
---
## Grafana UI
你可以使用 [Grafana](https://grafana.com/grafana/) 对存储在各个地方的指标进行查询、可视化、告警和了解。你能与你的团队创建、探索和共享仪表板，并培养数据驱动的文化。
要查看时间序列数据可视化的默认仪表板，请转到 Grafana UI。
### 自定义 Grafana
要查看和自定义用于支持 Grafana 仪表板的 PromQL 查询，请参阅[此页面](../../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/customize-grafana-dashboard.md)。
### 持久化 Grafana 仪表板
要创建持久化 Grafana 仪表板，请参阅[此页面](../../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/create-persistent-grafana-dashboard.md)。
### 访问 Grafana
有关 Grafana 的 RBAC，请参阅[本节](rbac-for-monitoring.md#grafana-的-rbac)。
## Alertmanager UI
安装 `rancher-monitoring` 后，会部署 Prometheus Alertmanager UI，从而让你查看告警以及当前的 Alertmanager 配置。
:::note
本节参考假设你已经熟悉 Monitoring 组件的协同工作方式。有关 Alertmanager 的详细信息，请参阅[本节](how-monitoring-works.md#alertmanager-工作原理)。
:::
### 访问 Alertmanager UI
Alertmanager UI 可让你查看最近触发的告警。
:::note 先决条件：
必须安装 `rancher-monitoring` 应用。
:::
要查看 Alertmanager UI：
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面上，转到要查看 Alertmanager UI 的集群，然后单击 **Explore**。
1. 在左侧导航栏中，单击**监控**。
1. 单击 **Alertmanager**。
**结果**：在新选项卡中打开 Alertmanager UI。如需配置帮助，请参阅[官方 Alertmanager 文档](https://prometheus.io/docs/alerting/latest/alertmanager/)。
有关在 Rancher 中配置 Alertmanager 的更多信息，请参阅[此页面](../../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md)。
<figcaption>Alertmanager UI</figcaption>
![Alertmanager UI](/img/alertmanager-ui.png)
### 查看默认告警
要查看默认触发的告警，请转到 Alertmanager UI 并单击**展开所有组**。
## Prometheus UI
默认情况下，[kube-state-metrics service](https://github.com/kubernetes/kube-state-metrics) 向 monitoring 应用提供 CPU 和内存利用率的大量信息。这些指标涵盖了跨命名空间的 Kubernetes 资源。换言之，如果你要查看服务的资源指标，你无需为其创建新的 ServiceMonitor。由于数据已经在时间序列数据库中，你可以转到 Prometheus UI 并运行 PromQL 查询来获取信息。你可以使用相同的查询来配置 Grafana 仪表板，从而显示这些指标随时间变化的图表。
要查看 Prometheus UI，请安装 `rancher-monitoring`。然后：
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面上，转到要查看 Prometheus UI 的集群，然后单击 **Explore**。
1. 在左侧导航栏中，单击**监控**。
1. 单击 **Prometheus Graph**。
<figcaption>Prometheus Graph UI</figcaption>
![Prometheus Graph UI](/img/prometheus-graph-ui.png)
### 查看 Prometheus 目标
要查看你正在监控的服务，你需要查看你的目标。目标是由 ServiceMonitor 和 PodMonitor 设置的，指的是指标抓取的的源。你无需直接编辑目标，但 Prometheus UI 可为你提供抓取的所有指标来源的概览。
要查看 Prometheus 目标，请安装 `rancher-monitoring`。然后：
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面上，转到要查看 Prometheus 目标的集群，然后单击 **Explore**。
1. 在左侧导航栏中，单击**监控**。
1. 单击 **Prometheus 目标**。
<figcaption>Prometheus UI 中的目标</figcaption>
![Prometheus 目标 UI](/img/prometheus-targets-ui.png)
### 查看 PrometheusRules
当你定义规则时（在 PrometheusRule 资源的 RuleGroup 中声明），[规则本身的规范](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#rule)会包含标签，然后 Alertmanager 会使用这些标签来确定接收对应告警的路由。
要查看 PrometheusRule，请安装 `rancher-monitoring`。然后：
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面上，转到要可视化的集群，然后单击 **Explore**。
1. 在左侧导航栏中，单击**监控**。
1. 点击 **Prometheus 规则**。
你还可以在 Prometheus UI 中查看规则：
<figcaption>Prometheus UI 中的规则</figcaption>
![PrometheusRules UI](/img/prometheus-rules-ui.png)
有关在 Rancher 中配置 PrometheusRule 的更多信息，请参阅[此页面](../../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheusrules.md)。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md
+250
View File
@@ -0,0 +1,250 @@
---
title: Monitoring 的工作原理
weight: 1
---
## 1. 架构概述
_**下文描述了数据如何流经 Monitoring V2 应用程序：**_
### Prometheus Operator
Prometheus Operator 观察正在创建的 ServiceMonitors、PodMonitors 和 PrometheusRules。在创建 Prometheus 配置资源时，Prometheus Operator 会调用 Prometheus API 来同步新配置。如本节末尾的图所示，Prometheus Operator 充当 Prometheus 和 Kubernetes 之间的中介，调用 Prometheus API 来同步 Prometheus 与 Kubernetes 中的监控相关资源。
### ServiceMonitor 和 PodMonitor
ServiceMonitor 和 PodMonitor 以声明方式指定需要监控的目标，例如 Service 和 Pod。
- 目标是根据配置的 Prometheus 抓取间隔定期抓取的，而抓取的指标存储在 Prometheus 时间序列数据库（Time Series Database，TSDB）中。
- 为了执行抓取，你需要使用标签选择器来定义 ServiceMonitor 和 PodMonitor，这些标签选择器用于确定要抓取的 Service 或 Pod，并能确定端点（端点能确定抓取如何在给定目标上进行，例如在 TCP 10252 中抓取指标，通过 IP 地址 x.x.x.x 进行代理）。
- 开箱即用地，Monitoring V2 附带了一些预配置的 Exporter，这些 Exporter 根据其所在的 Kubernetes 集群的类型进行部署。有关详细信息，请参阅[抓取和公开指标](#5-抓取和公开指标)。
### PushProx 的工作原理
- 某些内部 Kubernetes 组件是通过部署在 Monitoring V2 中名为 **PushProx** 的代理来抓取的。通过 PushProx 向 Prometheus 公开指标的 Kubernetes 组件分别是 `kube-controller-manager`、`kube-scheduler`, `etcd` 和 `kube-proxy`。
- 对于每个 PushProx Exporter，我们在所有目标节点上都部署一个 PushProx 客户端。例如，将 PushProx 客户端部署到 kube-controller-manager 的所有 controlplane 节点、kube-etcd 的所有 etcd 节点上，和 kubelet 的所有节点上。
- 我们为每个 Exporter 部署了一个 PushProx 代理。导出指标的流程如下：
1. PushProx 客户端与 PushProx 代理建立出站连接。
1. 然后，客户端会轮询代理以获取进入代理的抓取请求。
1. 当代理收到来自 Prometheus 的抓取请求时，客户端会将其视为轮询的结果。
1. 客户端抓取内部组件。
1. 内部组件通过将指标推回代理来响应。
<figcaption><br/>使用 PushProx 导出指标的过程：<br/></figcaption>
![使用 PushProx 导出指标的过程](/img/pushprox-process.svg)
### PrometheusRules
PrometheusRule 用于定义指标或时间序列数据库查询触发告警的规则。规则是按时间间隔评估的。
- **记录规则**根据已收集的现有序列创建一个新的时间序列。它们常用于预先计算的复杂查询。
- **告警规则**运行特定查询，如果查询评估为非零值，则从 Prometheus 触发告警。
### 告警路由
一旦 Prometheus 确定需要触发告警，就会将告警转发到 **Alertmanager**。
- 告警包含来自 PromQL 查询本身的标签，以及指定初始 PrometheusRule 时设置的其他标签和注释。
- 在接收任何告警之前，Alertmanager 会用配置中指定的**路由 (Route)** 和**接收器 (Receiver)** 来形成一个路由树，所有传入的告警都会在该路由树上进行评估。路由树的每个节点都可以根据附加到 Prometheus 告警的标签来指定要进行的其他分组、标签和过滤。路由树上的节点（通常是叶节点）还可以指定到达的告警需要发送到什么接收器，例如 Slack、PagerDuty、SMS 等。请注意，Alertmanager 首先向 **alertingDriver** 发送告警，然后 alertingDriver 再将告警发送或转发到正确的目标位置。
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时，Alertmanager 也会自动更新。请注意，路由仅通过标签发生（而不是通过注释等）。
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
## 2. Prometheus 的工作原理
### 存储时间序列数据
收集 Exporter 的指标后，Prometheus 将时间序列存储在本地磁盘时间序列数据库中。Prometheus 可以选择与远程系统集成，但 `rancher-monitoring` 使用本地存储来存储时间序列数据库。
存储后，用户可以使用 PromQL（Prometheus 的查询语言）查询此 TSDB。
PromQL 查询可以通过以下两种方式进行可视化：
1. 通过在 Prometheus 的 Graph UI 中提供查询，UI 会显示数据的简单图形视图。
1. 通过创建包含 PromQL 查询和其他格式化指令的 Grafana 仪表板，这些指令用于标记轴、添加单位、更改颜色、使用替代可视化等。
### 为 Prometheus 定义规则
规则定义了 Prometheus 需要在常规 `evaluationInterval` 上执行的查询，从而执行某些操作，例如触发告警（告警规则）或根据 TSDB 中存在的其他查询（记录规则）预先计算查询。这些规则编码在 PrometheusRules 自定义资源中。创建或更新 PrometheusRule 自定义资源后，Prometheus Operator 会观察变化，并调用 Prometheus API 来定期同步 Prometheus 当前正在评估的规则集。
PrometheusRule 支持定义一个或多个 RuleGroup。每个 RuleGroup 由一组 Rule 对象组成，每个 Rule 对象均能表示告警或记录规则，并具有以下字段：
- 新告警或记录的名称
- 新告警或记录的 PromQL 表达式
- 用于标记告警或记录的标签（例如集群名称或严重性）
- 对需要在告警通知上显示的其他重要信息进行编码的注释（例如摘要、描述、消息、Runbook URL 等）。记录规则不需要此字段。
在评估[规则](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#rule)时，Prometheus 将执行配置的 PromQL 查询，添加其他标签（或注释 - 仅用于告警规则），并为规则执行所需的操作。例如，如果某个告警规则将 `team:front-end` 作为标签添加到配置的 PromQL 查询，该标签会尾附到触发的告警，这将允许 Alertmanager 将告警转发到正确的接收器。
### 告警和记录规则
Prometheus 不会维护告警是否处于 active 状态。它在每个评估间隔内重复触发告警，并根据 Alertmanager 对告警进行分组和过滤成有意义的通知。
`evaluation_interval` 常量定义了 Prometheus 根据时间序列数据库评估告警规则的频率。与 `scrape_interval` 类似，`evaluation_interval` 的默认值也是一分钟。
规则包含在一组规则文件中。规则文件包括告警规则和记录规则，但只有告警规则才会在评估后触发告警。
对于记录规则，Prometheus 会运行查询，然后将其存储为时间序列。如果需要存储非常昂贵或耗时的查询的结果，这种合成的时间序列则非常有用，因此你可以在后续更快地进行查询它们。
告警规则是更常用的。每当告警规则评估为正数时，Prometheus 都会触发告警。
在触发告警之前，Rule 文件会根据实际用例将标签和注释添加到告警中：
- 标签用于标识告警的信息，并可能影响告警的路由。例如，如果在发送有关某个容器的告警时，你可以使用容器 ID 作为标签。
- 注释用于表示不影响告警路由位置的信息，例如 Runbook 或错误消息。
## 3. Alertmanager 的工作原理
Alertmanager 处理由 Prometheus server 等客户端应用发送的告警。它负责以下任务：
- 删除重复数据，分组，并将告警路由到正确的接收器集成（例如电子邮件、PagerDuty 或 OpsGenie）
- 静音和抑制告警
- 跟踪随时间触发的告警
- 发送告警的状态，即告警是否正在触发，或者是否已经解决
### 由 alertingDrivers 转发的告警
安装 alertingDriver 后会根据 alertingDriver 的配置创建一个 `Service`，可用作 Teams 或 SMS 的接收器 URL。接收器中的 URL 会指向 alertingDrivers。因此 Alertmanager 首先向 alertingDriver 发送告警，然后 alertingDriver 将告警转发或发送到正确的目的位置。
### 将告警路由到接收器
Alertmanager 负责协调告警的发送位置。它允许你根据标签对告警进行分组，并根据标签匹配情况来触发告警。一个最顶层路由会接受所有告警。然后，Alertmanager 会根据告警是否匹配下一个路由的条件，继续将告警路由到接收器。
虽然 Rancher UI 表单只允许编辑两层深的路由树，但你可以通过编辑 Alertmanager Secret 来配置更深的嵌套路由结构。
### 配置多个接收器
你可以编辑 Rancher UI 中的表单来设置一个接收器资源，其中包含 Alertmanager 将告警发送到你的通知系统所需的所有信息。
通过在 Alertmanager 或接收器配置中编辑自定义 YAML，你还可以将告警发送到多个通知系统。有关详细信息，请参阅[接收器配置](../../../reference-guides/monitoring-v2-configuration/receivers.md#配置多个接收器)。
## 4. Monitoring V2 特定组件
Prometheus Operator 引入了一组[自定义资源定义](https://github.com/prometheus-operator/prometheus-operator#customresourcedefinitions)，允许用户通过在集群上创建和修改这些自定义资源来部署和管理 Prometheus 和 Alertmanager 实例。
Prometheus Operator 会根据 Rancher UI 中编辑的资源和配置选项的实时状态来自动更新 Prometheus 配置。
### 默认部署的资源
默认情况下，由 [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus) 项目策划的一组资源会作为 Rancher Monitoring 安装的一部分部署到你的集群上，用来设置基本的 Monitoring/Alerting 堆栈。
你可以在 [`rancher-monitoring`](https://github.com/rancher/charts/tree/main/charts/rancher-monitoring) Helm Chart 中找到部署到你的集群以支持此解决方案的资源，该 chart 密切跟踪由 Prometheus 社区维护的上游 [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack) Helm Chart，并在 [CHANGELOG.md](https://github.com/rancher/charts/blob/main/charts/rancher-monitoring/CHANGELOG.md) 中跟踪变更。
### 默认 Exporter
Monitoring V2 部署了三个默认 Exporter，它们为 Prometheus 提供额外的指标来存储：
1. `node-exporter`：公开 Linux 主机的硬件和操作系统指标。有关 `node-exporter` 的更多信息，请参阅[上游文档](https://prometheus.io/docs/guides/node-exporter/)。
1. `windows-exporter`：公开 Windows 主机的硬件和操作系统指标（仅部署在 Windows 集群上）。有关 `windows-exporter` 的更多信息，请参阅[上游文档](https://github.com/prometheus-community/windows_exporter)。
1. `kube-state-metrics`：公开跟踪 Kubernetes API 中包含的资源状态的其他指标（例如，pod、工作负载等）。有关 `kube-state-metrics` 的更多信息，请参阅[上游文档](https://github.com/kubernetes/kube-state-metrics/tree/master/docs)。
ServiceMonitor 和 PodMonitor 将按照[此定义](#定义要抓取的指标)来抓取这些 Exporter。Prometheus 会存储这些指标，你可以通过 Prometheus 的 UI 或 Grafana 查询结果。
有关记录规则、告警规则和 Alertmanager 的更多信息，请参阅[架构](#1-架构概述)。
### Rancher UI 中公开的组件
安装 monitoring 应用后，你将能够在 Rancher UI 中编辑以下组件：
| 组件 | 组件类型 | 编辑的目的和常见用例 |
|--------------|------------------------|---------------------------|
| ServiceMonitor | 自定义资源 | 设置 Kubernetes Service 来获取其自定义指标。自动更新 Prometheus 自定义资源中的抓取配置。 |
| PodMonitor | 自定义资源 | 设置 Kubernetes Pod 来获取其自定义指标。自动更新 Prometheus 自定义资源中的抓取配置。 |
| 接收器 | 配置块（Alertmanager 的一部分） | 修改将告警发送到什么位置的信息（例如，Slack、PagerDuty 等）以及发送告警的其他必要信息（例如，TL​​S 证书、代理 URL 等）。自动更新 Alertmanager 自定义资源。 |
| Route | 配置块（Alertmanager 的一部分） | 修改用于根据标签过滤、标记和分组告警的路由树，并将告警发送到所需的接收器。自动更新 Alertmanager 自定义资源。 |
| PrometheusRule | 自定义资源 | 定义其他查询，这些查询能触发告警或定义 Prometheus TSDB 中现有的物化视图。自动更新 Prometheus 自定义资源。 |
### PushProx
PushProx 允许 Prometheus 跨网络边界抓取指标，这样，用户就不用必须为 Kubernetes 集群中每个节点上的内部 Kubernetes 组件公开指标端口。
由于 Kubernetes 组件的指标通常暴露在集群中节点的主机网络上，PushProx 部署了一个客户端 DaemonSet，这些客户端位于每个节点的主机网络上，并与位于 Kubernetes API 上的单个代理建立出站连接。然后，你可以让 Prometheus 通过代理将抓取请求发送到每个客户端，这样，Prometheus 能从内部 Kubernetes 组件抓取指标，而不需要打开任何入站节点端口。
有关更多信息，请参阅[使用 PushProx 抓取指标](#使用-pushprox-抓取指标)。
## 5. 抓取和公开指标
### 定义要抓取的指标
ServiceMonitor 和 PodMonitor 定义了 Prometheus 要抓取的目标。[Prometheus 自定义资源](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md#prometheus)告诉 Prometheus 应该使用哪个 ServiceMonitor 或 PodMonitor 来确定从哪里抓取指标。
Prometheus Operator 观察 ServiceMonitor 和 PodMonitor。当它观察到二者被创建或更新时，它会调用 Prometheus API 来更新 Prometheus 自定义资源中的抓取配置，并使该配置与 ServiceMonitor 或 PodMonitor 中的抓取配置保持同步。此抓取配置告诉 Prometheus 从哪些端点抓取指标，以及如何标记这些端点的指标。
Prometheus 会根据 `scrape_interval`（默认为一分钟）来抓取定义在抓取配置中的所有指标。
抓取配置可以作为 Prometheus 自定义资源的一部分被查看，该资源在 Rancher UI 中公开。
### Prometheus Operator 如何设置指标抓取
Prometheus Deployment 或 StatefulSet 能抓取指标，而 Prometheus 的配置由 Prometheus 自定义资源控制。Prometheus Operator 会观察 Prometheus 和 Alertmanager 资源，当它们被创建时，Prometheus Operator 使用用户定义的配置，为 Prometheus 或 Alertmanager 创建一个 Deployment 或 StatefulSet。
如果 Prometheus Operator 观察到正在创建的 ServiceMonitor、PodMonitor 和 PrometheusRule，它就知道需要在 Prometheus 中更新抓取配置。首先，会通过更新 Prometheus 的 Deployment 或 StatefulSet 卷中的配置和规则文件来更新 Prometheus。然后，再调用 Prometheus API 来同步新配置，从而将 Prometheus Deployment 或 StatefulSet 修改到位。
### 如何公开 Kubernetes 组件指标
Prometheus 从称为 [exporter](https://prometheus.io/docs/instrumenting/exporters/) 的 deployment 中抓取指标，exporter 以 Prometheus 可以抓取的格式导出时间序列数据。在 Prometheus 中，时间序列由属于相同指标和相同标记维度集的时间戳值流组成。
### 使用 PushProx 抓取指标
某些内部 Kubernetes 组件是通过部署在 Monitoring V2 中名为 PushProx 的代理来抓取的。有关 PushProx 的详细信息，请参阅[此处](#pushprox-的工作原理)和上面的[架构](#1-架构概述)部分。
### 抓取指标
Prometheus 直接抓取以下 Kubernetes 组件：
- kubelet\*
- ingress-nginx\*\*
- coreDns/kubeDns
- kube-api-server
\* 你可以选择通过 `hardenedKubelet.enabled` 来使用 PushProx，但这不是默认设置。
\*\* RKE 和 RKE2 集群默认部署 ingress-nginx，并将其视为内部 Kubernetes 组件。
### 基于 Kubernetes 发行版抓取指标
指标的抓取方式根据 Kubernetes 发行版而有所不同。有关术语的帮助，请参阅[此处](#名词解释)。详情见下表：
<figcaption>指标如何暴露给 Prometheus</figcaption>
| Kubernetes 组件 | RKE | RKE2 | KubeADM | K3s |
|-----|-----|-----|-----|-----|
| kube-controller-manager | rkeControllerManager.enabled | rke2ControllerManager.enabled | kubeAdmControllerManager.enabled | k3sServer.enabled |
| kube-scheduler | rkeScheduler.enabled | rke2Scheduler.enabled | kubeAdmScheduler.enabled | k3sServer.enabled |
| etcd | rkeEtcd.enabled | rke2Etcd.enabled | kubeAdmEtcd.enabled | 不可用 |
| kube-proxy | rkeProxy.enabled | rke2Proxy.enabled | kubeAdmProxy.enabled | k3sServer.enabled |
| kubelet | 收集 kubelet 直接公开的指标 | 收集 kubelet 直接公开的指标 | 收集 kubelet 直接公开的指标 | 收集 kubelet 直接公开的指标 |
| ingress-nginx* | 收集 kubelet 直接公开的指标，由 rkeIngressNginx.enabled 公开 | 收集 kubelet 直接公开的指标，由 rke2IngressNginx.enabled 公开 | 不可用 | 不可用 |
| coreDns/kubeDns | 收集 coreDns/kubeDns 直接公开的指标 | 收集 coreDns/kubeDns 直接公开的指标 | 收集 coreDns/kubeDns 直接公开的指标 | 收集 coreDns/kubeDns 直接公开的指标 |
| kube-api-server | 收集 kube-api-server 直接公开的指标 | 收集 kube-api-server 直接公开的指标 | 收集 kube-appi-server 直接公开的指标 | 收集 kube-api-server 直接公开的指标 |
\* RKE 和 RKE2 集群默认部署 ingress-nginx，并将其视为内部 Kubernetes 组件。
### 名词解释
- **kube-scheduler**：内部 Kubernetes 组件，该组件使用 pod 规范中的信息来决定在哪个节点上运行 pod。
- **kube-controller-manager**：负责节点管理（检测节点是否失败）、pod 复制，以及端点创建的内部 Kubernetes 组件。
- **etcd**：Kubernetes 内部组件，它是 Kubernetes 用于持久存储所有集群信息的分布式键/值存储。
- **kube-proxy**：内部 Kubernetes 组件，用于监控 API server 的 pod/service 更改以保持网络最新状态。
- **kubelet**：内部 Kubernetes 组件，用于为 pod 监视节点上的 API server 并确保这些 pod 能运行。
- **ingress-nginx**：用于 Kubernetes 的 Ingress controller，使用 NGINX 作为反向代理和负载均衡器。
- **coreDns/kubeDns**：负责 DNS 的内部 Kubernetes 组件。
- **kube-api-server**：负责为其他 master 组件公开 API 的主要内部 Kubernetes 组件。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/monitoring-and-alerting/promql-expressions.md
+366
View File
@@ -0,0 +1,366 @@
---
title: PromQL 表达式参考
weight: 6
---
本文档中的 PromQL 表达式可用于配置告警。
关于查询 Prometheus 时间序列数据库的更多信息，请参阅 [Prometheus 官方文档](https://prometheus.io/docs/prometheus/latest/querying/basics/)。
## 集群指标
### 集群 CPU 利用率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `1 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance))` |
| 摘要 | `1 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])))` |
### 集群平均负载
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>load1</td><td>`sum(node_load1) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`</td></tr><tr><td>load5</td><td>`sum(node_load5) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`</td></tr><tr><td>load15</td><td>`sum(node_load15) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`</td></tr></table> |
| 摘要 | <table><tr><td>load1</td><td>`sum(node_load1) by (instance) / count(node_cpu_seconds_total{mode="system"})`</td></tr><tr><td>load5</td><td>`sum(node_load5) by (instance) / count(node_cpu_seconds_total{mode="system"})`</td></tr><tr><td>load15</td><td>`sum(node_load15) by (instance) / count(node_cpu_seconds_total{mode="system"})`</td></tr></table> |
### 集群内存利用率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `1 - sum(node_memory_MemAvailable_bytes) by (instance) / sum(node_memory_MemTotal_bytes) by (instance)` |
| 摘要 | `1 - sum(node_memory_MemAvailable_bytes) / sum(node_memory_MemTotal_bytes)` |
### 集群磁盘利用率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `(sum(node_filesystem_size_bytes{device!="rootfs"}) by (instance) - sum(node_filesystem_free_bytes{device!="rootfs"}) by (instance)) / sum(node_filesystem_size_bytes{device!="rootfs"}) by (instance)` |
| 摘要 | `(sum(node_filesystem_size_bytes{device!="rootfs"}) - sum(node_filesystem_free_bytes{device!="rootfs"})) / sum(node_filesystem_size_bytes{device!="rootfs"})` |
### 集群磁盘 I/O
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total[5m])) by (instance)`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total[5m])) by (instance)`</td></tr></table> |
| 摘要 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total[5m]))`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total[5m]))`</td></tr></table> |
### 集群网络数据包
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
| 摘要 | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |
### 集群网络 I/O
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
| 摘要 | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |
## 节点指标
### 节点 CPU 利用率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `avg(irate(node_cpu_seconds_total{mode!="idle", instance=~"$instance"}[5m])) by (mode)` |
| 摘要 | `1 - (avg(irate(node_cpu_seconds_total{mode="idle", instance=~"$instance"}[5m])))` |
### 节点平均负载
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>load1</td><td>`sum(node_load1{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load5</td><td>`sum(node_load5{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load15</td><td>`sum(node_load15{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr></table> |
| 摘要 | <table><tr><td>load1</td><td>`sum(node_load1{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load5</td><td>`sum(node_load5{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load15</td><td>`sum(node_load15{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr></table> |
### 节点内存利用率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `1 - sum(node_memory_MemAvailable_bytes{instance=~"$instance"}) / sum(node_memory_MemTotal_bytes{instance=~"$instance"})` |
| 摘要 | `1 - sum(node_memory_MemAvailable_bytes{instance=~"$instance"}) / sum(node_memory_MemTotal_bytes{instance=~"$instance"}) ` |
### 节点磁盘利用率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `(sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"}) by (device) - sum(node_filesystem_free_bytes{device!="rootfs",instance=~"$instance"}) by (device)) / sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"}) by (device)` |
| 摘要 | `(sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"}) - sum(node_filesystem_free_bytes{device!="rootfs",instance=~"$instance"})) / sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"})` |
### 节点磁盘 I/O
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total{instance=~"$instance"}[5m]))`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total{instance=~"$instance"}[5m]))`</td></tr></table> |
| 摘要 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total{instance=~"$instance"}[5m]))`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total{instance=~"$instance"}[5m]))`</td></tr></table> |
### 节点网络数据包
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
| 摘要 | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |
### 节点网络 I/O
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
| 摘要 | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |
## ETCD 指标
### ETCD 有一个 Leader
`max(etcd_server_has_leader)`
### Leader 更换次数
`max(etcd_server_leader_changes_seen_total)`
### 失败的 Proposal 数量
`sum(etcd_server_proposals_failed_total)`
### GRPC 客户端流量
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>in</td><td>`sum(rate(etcd_network_client_grpc_received_bytes_total[5m])) by (instance)`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_client_grpc_sent_bytes_total[5m])) by (instance)`</td></tr></table> |
| 摘要 | <table><tr><td>in</td><td>`sum(rate(etcd_network_client_grpc_received_bytes_total[5m]))`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_client_grpc_sent_bytes_total[5m]))`</td></tr></table> |
### 对等流量
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>in</td><td>`sum(rate(etcd_network_peer_received_bytes_total[5m])) by (instance)`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_peer_sent_bytes_total[5m])) by (instance)`</td></tr></table> |
| 摘要 | <table><tr><td>in</td><td>`sum(rate(etcd_network_peer_received_bytes_total[5m]))`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_peer_sent_bytes_total[5m]))`</td></tr></table> |
### 数据库大小
| 目录 | 表达式 |
| --- | --- |
| 详情 | `sum(etcd_debugging_mvcc_db_total_size_in_bytes) by (instance)` |
| 摘要 | `sum(etcd_debugging_mvcc_db_total_size_in_bytes)` |
### 活动流
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>lease-watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) by (instance) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) by (instance)`</td></tr><tr><td>watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) by (instance) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) by (instance)`</td></tr></table> |
| 摘要 | <table><tr><td>lease-watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"})`</td></tr><tr><td>watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"})`</td></tr></table> |
### Raft 方案
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>applied</td><td>`sum(increase(etcd_server_proposals_applied_total[5m])) by (instance)`</td></tr><tr><td>committed</td><td>`sum(increase(etcd_server_proposals_committed_total[5m])) by (instance)`</td></tr><tr><td>pending</td><td>`sum(increase(etcd_server_proposals_pending[5m])) by (instance)`</td></tr><tr><td>failed</td><td>`sum(increase(etcd_server_proposals_failed_total[5m])) by (instance)`</td></tr></table> |
| 摘要 | <table><tr><td>applied</td><td>`sum(increase(etcd_server_proposals_applied_total[5m]))`</td></tr><tr><td>committed</td><td>`sum(increase(etcd_server_proposals_committed_total[5m]))`</td></tr><tr><td>pending</td><td>`sum(increase(etcd_server_proposals_pending[5m]))`</td></tr><tr><td>failed</td><td>`sum(increase(etcd_server_proposals_failed_total[5m]))`</td></tr></table> |
### RPC 速率
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>total</td><td>`sum(rate(grpc_server_started_total{grpc_type="unary"}[5m])) by (instance)`</td></tr><tr><td>fail</td><td>`sum(rate(grpc_server_handled_total{grpc_type="unary",grpc_code!="OK"}[5m])) by (instance)`</td></tr></table> |
| 摘要 | <table><tr><td>total</td><td>`sum(rate(grpc_server_started_total{grpc_type="unary"}[5m]))`</td></tr><tr><td>fail</td><td>`sum(rate(grpc_server_handled_total{grpc_type="unary",grpc_code!="OK"}[5m]))`</td></tr></table> |
### 磁盘操作
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>commit-called-by-backend</td><td>`sum(rate(etcd_disk_backend_commit_duration_seconds_sum[1m])) by (instance)`</td></tr><tr><td>fsync-called-by-wal</td><td>`sum(rate(etcd_disk_wal_fsync_duration_seconds_sum[1m])) by (instance)`</td></tr></table> |
| 摘要 | <table><tr><td>commit-called-by-backend</td><td>`sum(rate(etcd_disk_backend_commit_duration_seconds_sum[1m]))`</td></tr><tr><td>fsync-called-by-wal</td><td>`sum(rate(etcd_disk_wal_fsync_duration_seconds_sum[1m]))`</td></tr></table> |
### 磁盘同步持续时间
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>wal</td><td>`histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le))`</td></tr><tr><td>db</td><td>`histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le))`</td></tr></table> |
| 摘要 | <table><tr><td>wal</td><td>`sum(histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le)))`</td></tr><tr><td>db</td><td>`sum(histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le)))`</td></tr></table> |
## Kubernetes 组件指标
### API Server 请求延迟
| 目录 | 表达式 |
| --- | --- |
| 详情 | `avg(apiserver_request_latencies_sum / apiserver_request_latencies_count) by (instance, verb) /1e+06` |
| 摘要 | `avg(apiserver_request_latencies_sum / apiserver_request_latencies_count) by (instance) /1e+06` |
### API Server 请求速率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `sum(rate(apiserver_request_count[5m])) by (instance, code)` |
| 摘要 | `sum(rate(apiserver_request_count[5m])) by (instance)` |
### 调度失败的 Pod
| 目录 | 表达式 |
| --- | --- |
| 详情 | `sum(kube_pod_status_scheduled{condition="false"})` |
| 摘要 | `sum(kube_pod_status_scheduled{condition="false"})` |
### Controller Manager 队列深度
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>volumes</td><td>`sum(volumes_depth) by instance`</td></tr><tr><td>deployment</td><td>`sum(deployment_depth) by instance`</td></tr><tr><td>replicaset</td><td>`sum(replicaset_depth) by instance`</td></tr><tr><td>service</td><td>`sum(service_depth) by instance`</td></tr><tr><td>serviceaccount</td><td>`sum(serviceaccount_depth) by instance`</td></tr><tr><td>endpoint</td><td>`sum(endpoint_depth) by instance`</td></tr><tr><td>daemonset</td><td>`sum(daemonset_depth) by instance`</td></tr><tr><td>statefulset</td><td>`sum(statefulset_depth) by instance`</td></tr><tr><td>replicationmanager</td><td>`sum(replicationmanager_depth) by instance`</td></tr></table> |
| 摘要 | <table><tr><td>volumes</td><td>`sum(volumes_depth)`</td></tr><tr><td>deployment</td><td>`sum(deployment_depth)`</td></tr><tr><td>replicaset</td><td>`sum(replicaset_depth)`</td></tr><tr><td>service</td><td>`sum(service_depth)`</td></tr><tr><td>serviceaccount</td><td>`sum(serviceaccount_depth)`</td></tr><tr><td>endpoint</td><td>`sum(endpoint_depth)`</td></tr><tr><td>daemonset</td><td>`sum(daemonset_depth)`</td></tr><tr><td>statefulset</td><td>`sum(statefulset_depth)`</td></tr><tr><td>replicationmanager</td><td>`sum(replicationmanager_depth)`</td></tr></table> |
### 调度器 E2E 调度延迟
| 目录 | 表达式 |
| --- | --- |
| 详情 | `histogram_quantile(0.99, sum(scheduler_e2e_scheduling_latency_microseconds_bucket) by (le, instance)) / 1e+06` |
| 摘要 | `sum(histogram_quantile(0.99, sum(scheduler_e2e_scheduling_latency_microseconds_bucket) by (le, instance)) / 1e+06)` |
### 调度器抢占尝试
| 目录 | 表达式 |
| --- | --- |
| 详情 | `sum(rate(scheduler_total_preemption_attempts[5m])) by (instance)` |
| 摘要 | `sum(rate(scheduler_total_preemption_attempts[5m]))` |
### Ingress Controller 连接数
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>reading</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="reading"}) by (instance)`</td></tr><tr><td>waiting</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"}) by (instance)`</td></tr><tr><td>writing</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="writing"}) by (instance)`</td></tr><tr><td>accepted</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m]))) by (instance)`</td></tr><tr><td>active</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m]))) by (instance)`</td></tr><tr><td>handled</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m]))) by (instance)`</td></tr></table> |
| 摘要 | <table><tr><td>reading</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="reading"})`</td></tr><tr><td>waiting</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"})`</td></tr><tr><td>writing</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="writing"})`</td></tr><tr><td>accepted</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m])))`</td></tr><tr><td>active</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m])))`</td></tr><tr><td>handled</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m])))`</td></tr></table> |
### Ingress Controller 请求处理时间
| 目录 | 表达式 |
| --- | --- |
| 详情 | `topk(10, histogram_quantile(0.95,sum by (le, host, path)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` |
| 摘要 | `topk(10, histogram_quantile(0.95,sum by (le, host)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` |
## Rancher Logging 指标
### Fluentd 缓冲区队列速率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `sum(rate(fluentd_output_status_buffer_queue_length[5m])) by (instance)` |
| 摘要 | `sum(rate(fluentd_output_status_buffer_queue_length[5m]))` |
### Fluentd 输入速率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `sum(rate(fluentd_input_status_num_records_total[5m])) by (instance)` |
| 摘要 | `sum(rate(fluentd_input_status_num_records_total[5m]))` |
### Fluentd 输出错误率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `sum(rate(fluentd_output_status_num_errors[5m])) by (type)` |
| 摘要 | `sum(rate(fluentd_output_status_num_errors[5m]))` |
### Fluentd 输出速率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `sum(rate(fluentd_output_status_num_records_total[5m])) by (instance)` |
| 摘要 | `sum(rate(fluentd_output_status_num_records_total[5m]))` |
## 工作负载指标
### 工作负载 CPU 利用率
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
| 摘要 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
### 工作负载内存利用率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `sum(container_memory_working_set_bytes{namespace="$namespace",pod_name=~"$podName", container_name!=""}) by (pod_name)` |
| 摘要 | `sum(container_memory_working_set_bytes{namespace="$namespace",pod_name=~"$podName", container_name!=""})` |
### 工作负载网络数据包
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
| 摘要 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
### 工作负载网络 I/O
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
| 摘要 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
### 工作负载磁盘 I/O
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
| 摘要 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
## Pod 指标
### Pod CPU 利用率
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr></table> |
| 摘要 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr></table> |
### Pod 内存利用率
| 目录 | 表达式 |
| --- | --- |
| 详情 | `sum(container_memory_working_set_bytes{container_name!="POD",namespace="$namespace",pod_name="$podName",container_name!=""}) by (container_name)` |
| 摘要 | `sum(container_memory_working_set_bytes{container_name!="POD",namespace="$namespace",pod_name="$podName",container_name!=""})` |
### Pod 网络数据包
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
| 摘要 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
### Pod 网络 I/O
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
| 摘要 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
### Pod 磁盘 I/O
| 目录 | 表达式 |
| --- | --- |
| 详情 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`</td></tr></table> |
| 摘要 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
## 容器指标
### 容器 CPU 利用率
| 目录 | 表达式 |
| --- | --- |
| cfs throttled seconds | `sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
| usage seconds | `sum(rate(container_cpu_usage_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
| system seconds | `sum(rate(container_cpu_system_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
| user seconds | `sum(rate(container_cpu_user_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
### 容器内存利用率
`sum(container_memory_working_set_bytes{namespace="$namespace",pod_name="$podName",container_name="$containerName"})`
### 容器磁盘 I/O
| 目录 | 表达式 |
| --- | --- |
| read | `sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
| write | `sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md
+171
View File
@@ -0,0 +1,171 @@
---
title: RBAC
shortTitle: RBAC
weight: 2
---
本节描述了 RBAC 在 Rancher Monitoring 中的作用。
## 集群管理员
默认情况下，只有具有 cluster-admin `ClusterRole` 的用户才能：
- 将 `rancher-monitoring` 应用安装到集群上，并在 Chart 部署上执行所有其他相关配置。
- 例如，是否创建了默认仪表板，要将哪些 Exporter 部署到集群上以收集指标等。
- 通过 Prometheus CR 在集群中创建/修改/删除 Prometheus deployment。
- 通过 Alertmanager CR 在集群中创建/修改/删除 Alertmanager deployment。
- 通过在命名空间中创建 ConfigMap 来保留新的 Grafana 仪表板或数据源。
- 通过 `cattle-monitoring-system` 命名空间中的 Secret 将某些 Prometheus 指标暴露给 HPA 的 K8s Custom Metrics API。
## 具有基于 Kubernetes ClusterRole 权限的用户
`rancher-monitoring` Chart 安装了以下三个 `ClusterRole`。默认情况下，它们会聚合到相应的 K8s `ClusterRole` 中：
| ClusterRole | 聚合到默认的 K8s ClusterRole |
| ------------------------------| ---------------------------|
| `monitoring-admin` | `admin` |
| `monitoring-edit` | `edit` |
| `monitoring-view` | `view ` |
这些 `ClusterRole` 根据可执行的操作提供对 Monitoring CRD 的不同访问级别：
| CRD (monitoring.coreos.com) | Admin | Edit | View |
| ------------------------------| ---------------------------| ---------------------------| ---------------------------|
| <ul><li>`prometheuses`</li><li>`alertmanagers`</li></ul> | Get, List, Watch | Get, List, Watch | Get, List, Watch |
| <ul><li>`servicemonitors`</li><li>`podmonitors`</li><li>`prometheusrules`</li></ul> | * | * | Get, List, Watch |
在较高级别上，默认情况下会分配以下权限。
### 具有 Kubernetes 管理员/编辑权限的用户
只有具有 cluster-admin、admin 或 edit 的 `ClusterRole` 可以：
- 通过 ServiceMonitor 和 PodMonitor CR 修改 Prometheus deployment 的抓取配置。
- 通过 PrometheusRules CR 修改 Prometheus deployment 的告警/记录规则。
### 具有 Kubernetes 查看权限的用户
只有具有 Kubernetes `ClusterRole` 的用户可以：
- 查看集群内部署的 Prometheuses 的配置。
- 查看集群内部署的 Alertmanagers 的配置。
- 通过 ServiceMonitor 和 PodMonitor CR 查看 Prometheus deployment 的抓取配置。
- 通过 PrometheusRules CR 查看 Prometheus deployment 的告警/记录规则。
### 其他监控角色
Monitoring 还会创建其他 `Role`，这些角色默认情况下不会分配给用户，而是在集群中创建。你可以部署引用角色的 `RoleBinding` 来将角色绑定到命名空间。要使用 `kubectl` 而不是通过 Rancher 来定义 `RoleBinding`，请单击[此处](#使用-kubectl-分配-role-和-clusterrole)。
管理员应使用这些角色为用户提供更细粒度的访问权限：
| 角色 | 用途 |
| ------------------------------| ---------------------------|
| monitoring-config-admin | 允许管理员为用户分配角色，以便查看/编辑 cattle-monitoring-system 命名空间中的 Secret 和 ConfigMap。修改此命名空间中的 Secret/ConfigMap 可以允许用户更改集群的 Alertmanager 配置、Prometheus Adapter 配置、其他 Grafana 数据源、TLS 密钥等。 |
| monitoring-config-edit | 允许管理员为用户分配角色，以便查看/编辑 cattle-monitoring-system 命名空间中的 Secret 和 ConfigMap。修改此命名空间中的 Secret/ConfigMap 可以允许用户更改集群的 Alertmanager 配置、Prometheus Adapter 配置、其他 Grafana 数据源、TLS 密钥等。 |
| monitoring-config-view | 允许管理员为用户分配角色，以便查看 cattle-monitoring-system 命名空间中的 Secret 和 ConfigMap。查看此命名空间中的 Secret/ConfigMap 可以允许用户观察集群的 Alertmanager 配置、Prometheus Adapter 配置、其他 Grafana 数据源、TLS 密钥等。 |
| monitoring-dashboard-admin | 允许管理员为用户分配角色，以便查看/编辑 cattle-dashboards 命名空间中的 ConfigMap。此命名空间中的 ConfigMap 将对应于持久化到集群上的 Grafana 仪表板。 |
| monitoring-dashboard-edit | 允许管理员为用户分配角色，以便查看/编辑 cattle-dashboards 命名空间中的 ConfigMap。此命名空间中的 ConfigMap 将对应于持久化到集群上的 Grafana 仪表板。 |
| monitoring-dashboard-view | 允许管理员为用户分配角色，以便查看 cattle-dashboards 命名空间中的 ConfigMap。此命名空间中的 ConfigMap 将对应于持久化到集群上的 Grafana 仪表板。 |
### 其他监控集群角色
Monitoring 还会创建其他 `ClusterRole`，这些角色默认情况下不会分配给用户，而是在集群中创建。默认情况下，这些角色不会聚合，但你可以部署引用角色的 `RoleBinding` 或 `ClusterRoleBinding` 来将角色绑定到命名空间。要使用 `kubectl` 而不是通过 Rancher 来定义 `RoleBinding`，请单击[此处](#使用-kubectl-分配-role-和-clusterrole)。
| 角色 | 用途 |
| ------------------------------| ---------------------------|
| monitoring-ui-view | <a id="monitoring-ui-view"></a>_从 Monitoring v2 14.5.100+ 开始可用_。通过授权用户列出 Prometheus、Alertmanager 和 Grafana 端点，并通过 Rancher 代理向 Prometheus、Grafana 和 Alertmanager UI 进行 GET 请求，来允许用户对外部 Monitoring UI 进行只读访问。 |
### 使用 kubectl 分配 Role 和 ClusterRole
使用 Rancher 将 `Role` 或 `ClusterRole` 附加到用户或组的另一种方法，是在你创建的 YAML 文件中定义绑定。你必须首先使用 YAML 文件配置 `RoleBinding`，然后运行 `kubectl apply` 命令来应用配置更改。
* **Role**：以下 YAML 文件示例可帮助你在 Kubernetes 中配置 `RoleBinding`。你需要填写下方的 `name`（区分大小写）：
```yaml
# monitoring-config-view-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: monitoring-config-view
namespace: cattle-monitoring-system
roleRef:
kind: Role
name: monitoring-config-view
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
name: u-b4qkhsnliz # this can be found via `kubectl get users -A`
apiGroup: rbac.authorization.k8s.io
```
* **kubectl**：以下 `kubectl` 示例命令用于应用 YAML 文件中创建的绑定。如前所述，你需要相应地填写你的 YAML 文件名。
* `kubectl apply -f monitoring-config-view-role-binding.yaml`
## 具有 Rancher 权限的用户
Rancher 部署的默认角色（即 cluster-owner、cluster-member、project-owner、project-member）、Kubernetes 默认角色，以及 rancher-monitoring Chart 部署的角色之间的关系如下：
<figcaption>默认 Rancher 权限和对应的 Kubernetes ClusterRole</figcaption>
| Rancher 角色 | Kubernetes 角色 | Monitoring ClusterRole/Role | ClusterRoleBinding/RoleBinding |
| --------- | --------- | --------- | --------- |
| cluster-owner | cluster-admin | N/A | ClusterRoleBinding |
| cluster-member | admin | monitoring-admin | ClusterRoleBinding |
| project-owner | admin | monitoring-admin | 项目命名空间中的 RoleBinding |
| project-member | edit | monitoring-edit | 项目命名空间中的 RoleBinding |
除这些默认角色之外，你还可以将以下的其他 Rancher 项目角色应用于集群成员，以提供对 Monitoring 的其他访问。这些 Rancher 角色将与 Monitoring Chart 部署的 ClusterRole 相关联：
<figcaption>非默认的 Rancher 权限和对应的 Kubernetes ClusterRole</figcaption>
| Rancher 角色 | Kubernetes ClusterRole | 可用 Rancher 版本 | 可用 Monitoring V2 版本 |
|--------------------------|-------------------------------|-------|------|
| 查看 Monitoring\* | [monitoring-ui-view](#monitoring-ui-view) | 2.4.8+ | 9.4.204+ |
\* 如果某个用户绑定了 Rancher 的 **View Monitoring** 角色，该用户只有在有 UI 链接时才有权访问外部 Monitoring UI。要访问 Monitoring Pane 以获取这些链接，用户必须是至少一个项目的项目成员。
### 2.5.x 中的差异
在 Rancher 2.5.x 中，分配了 project-member 或 project-owner 角色的用户将无法访问 Prometheus 或 Grafana，因为我们仅在集群级别创建 Grafana 或 Prometheus。
此外，虽然 project-owner 仍然只能添加默认在项目命名空间内抓取资源的 ServiceMonitor/PodMonitor，但 PrometheusRule 并不局限于单个命名空间/项目。因此，即使 project-owner 无法查看/编辑/删除在项目命名空间之外创建的任何规则，project-owner 在其项目命名空间内创建的任何告警规则或记录规则都将应用于整个集群。
### 分配其他访问权限
如果 cluster-admin 想要为不具有 rancher-monitoring chart 角色的用户提供 admin/edit 访问权限，则存在下表的潜在影响：
| CRD (monitoring.coreos.com) | 是否会在命名空间/项目之外造成影响 | 影响 |
|----------------------------| ------| ----------------------------|
| `prometheuses` | 是。该资源可以从整个集群中的任何目标中抓取指标（除非 Operator 本身进行了额外的配置）。 | 用户将能够定义应在集群中创建的新集群级 Prometheus deployment 的配置。 |
| `alertmanagers` | 否 | 用户将能够定义应在集群中创建的新集群级 Alertmanager deployment 的配置。注意：如果你只想允许用户配置路由和接收器等设置，你应该只提供对 Alertmanager Config Secret 的访问权限。 |
| <ul><li>`servicemonitors`</li><li>`podmonitors`</li></ul> | 否（默认）。可以通过 Prometheus CR 上的 `ignoreNamespaceSelectors` 进行配置。 | 用户将能够通过 Prometheus，在他们被授予此权限的命名空间内的 Service/Pod 暴露的端点上设置抓取。 |
| `prometheusrules` | 是。PrometheusRules 是集群范围的。 | 用户将能够根据在整个集群中收集的任何系列，在 Prometheus 上定义告警或记录规则。 |
| K8s 资源 | 命名空间 | 是否会在命名空间/项目之外造成影响 | 影响 |
|----------------------------| ------| ------| ----------------------------|
| <ul><li>`secrets`</li><li>`configmaps`</li></ul> | `cattle-monitoring-system` | 是。此命名空间中的 Config 和 Secret 会影响整个监控/告警流水线。 | 用户将能够创建或编辑 Secret/ ConfigMap，例如 Alertmanager Config、Prometheus Adapter 配置、TLS 密文、其他 Grafana 数据源等。这会对所有集群监控/告警产生广泛影响。 |
| <ul><li>`secrets`</li><li>`configmaps`</li></ul> | `cattle-dashboards` | 是。此命名空间中的 Config 和 Secret 可以创建仪表板，对在集群级别收集的所有指标进行查询。 | 用户将能够创建仅保留新 Grafana 仪表板的 Secret/ConfigMap。 |
## Grafana 的 RBAC
对于经过 Kubernetes 认证并可以访问 Rancher Monitoring Chart 部署的 Grafana 服务的任何用户，Rancher 允许他们通过 Rancher Dashboard UI 访问 Grafana。默认情况下，所有能够访问 Grafana 的用户都被赋予 [Viewer](https://grafana.com/docs/grafana/latest/permissions/organization_roles/#viewer-role) 角色，能查看 Rancher 部署的任何默认仪表板。
但是，如果有需要的话，用户可以选择以 [Admin](https://grafana.com/docs/grafana/latest/permissions/organization_roles/#admin-role) 身份登录 Grafana。Grafana 实例的默认 Admin 用户名和密码是 `admin`/`prom-operator`，但你也可以在部署或升级 Chart 时替换凭证。
要查看 Grafana UI，请安装 `rancher-monitoring`。然后：
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面上，转到要可视化的集群，然后单击 **Explore**。
1. 在左侧导航栏中，单击**监控**。
1. 点击 **Grafana**。
<figcaption>Grafana 中的集群计算资源仪表板</figcaption>
![Grafana 中的集群计算资源仪表板](/img/cluster-compute-resources-dashboard.png)
<figcaption>Grafana 中的默认仪表板</figcaption>
![Grafana 中的默认仪表板](/img/grafana-default-dashboard.png)
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/monitoring-and-alerting/windows-support.md
+59
View File
@@ -0,0 +1,59 @@
---
title: Monitoring V2 的 Windows 集群支持
shortTitle: Windows 支持
weight: 5
---
_从 v2.5.8 起可用_
从 Monitoring V2 14.5.100（Rancher 2.5.8 的默认版本）开始，Monitoring V2 可以部署在 Windows 集群上，并将使用 [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter)（旧名是 `wmi_exporter`）来抓取 Windows 节点的指标。
## 与 Monitoring V1 的对比
由于命名已根据上游从 `wmi_exporter` 更改为 `windows_exporter`，因此 `windows_exporter` 收集的指标会标记为 `windows_` 而不是 `wmi_`。
此外，由于主机指标将直接发布到暴露在 windows-exporter Pod 上的端口上，因此 Monitoring V2 for Windows 将不再要求用户在 Windows 主机上保持打开端口 9796。此功能由 `wins` v0.1.0 最近的更改提供，以支持在 Pod 上发布暴露在 hostNetwork 上的端口，这些 Pod 使用 wins 来运行一个有特权的 Windows 二进制文件作为主机进程。
## 集群要求
Monitoring V2 for Windows 只能从最低是 `wins` v0.1.0 的 Windows 主机中抓取指标。要完全部署 Monitoring V2 for Windows，你的所有主机都必须满足此要求。
如果你在 Rancher 2.5.8 中配置新的 RKE1 集群，你的集群应该已经满足此要求。
### 将现有集群升级到 wins v0.1.0
如果集群是在 Rancher 2.5.8 之前配置的（即使当前 Rancher 版本是 2.5.8），你将无法成功部署 Monitoring V2 for Windows，除非你将每台主机的 wins 版本升级到 v0.1.0 或以上版本。
为了方便此次升级，Rancher 2.5.8 发布了一个全新的 Helm Chart，名为 `rancher-wins-upgrader`。
> **先决条件**：确保已卸载 Monitoring V1 for Windows。
1. 使用以下覆盖部署 `rancher-wins-upgrader`：
```yaml
# 通过先前已列入白名单的进程路径
# 来引导 win-upgrader 安装，这是因为正常安装路径
# c:\\etc\\rancher\\wins\\wins-upgrade.exe 通常不会被列入白名单。
# 因此，我们使用 Monitoring V1 之前所用的
# 已列入白名单的进程路径。
masquerade:
enabled: true
as: c:\\etc\wmi-exporter\wmi-exporter.exe
```
:::note 非默认 Windows 前缀路径的注意事项：
- 如果你使用具有非默认 `win_prefix_path` 的 `cluster.yml` 来设置 RKE 集群，你需要将 `c:\\` 替换为你的前缀路径字段的值来修改 `masquerade.as`。
- 例如，如果你使用 `win_prefix_path: 'c:\host\opt\'`，则需要设置为 `as: c:\host\opt\etc\wmi-exporter\wmi-exporter.exe`。
:::
2. 成功升级所有主机后，请再次使用默认值部署 Helm Chart，以避免与以下设置发生冲突：
```yaml
masquerade:
enabled: false
```
**结果**：主机已准备好安装 Monitoring V2。你可以选择卸载 `rancher-wins-upgrader` Chart，或将其保留在集群中以方便将来升级。
有关如何使用它的更多信息，请参阅 Chart 的 [README.md](https://github.com/rancher/wins/blob/master/charts/rancher-wins-upgrader/README.md)。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/neuvector.md
+205
View File
@@ -0,0 +1,205 @@
---
title: NeuVector 集成
weight: 22
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
### Rancher 中的 NeuVector 集成
[NeuVector 5.x](https://open-docs.neuvector.com/) 是一个开源的，以容器为中心的安全应用程序，Rancher 2.6.5 现已集成 NeuVector。NeuVector 在运行时为关键应用程序和数据提供实时的合规、可见和保护功能。NeuVector 提供具有 CIS Benchmark 和漏洞扫描的防火墙、容器进程/文件系统监控和安全审计。有关 Rancher 安全性的更多信息，请参阅[安全文档](../../pages-for-subheaders/rancher-security.md)。
NeuVector 可以通过 Helm Chart 启用。你可以在**应用 & 应用市场**或 Rancher UI 中的**集群工具**中安装该 Chart。安装 Helm Chart 后，用户可以轻松地[在 Rancher 中部署和管理 NeuVector 集群](https://open-docs.neuvector.com/deploying/rancher#deploy-and-manage-neuvector-through-rancher-apps-marketplace)。
### 使用 Rancher 安装 NeuVector
Harvester Helm Chart 用于管理 Rancher 中 NeuVector UI 的访问，用户可以在 Rancher 中直接跳转，然后部署和管理 NeuVector 集群。
**通过"应用 & 应用市场"导航并安装 NeuVector Chart**：
1. 点击 **☰ > 集群管理**。
1. 在 Clusters 页面上，转到要部署 NeuVector 的集群，然后单击 **Explore**。
1. 转到 **应用 & 应用市场 > Charts**，然后从 Chart 仓库中安装 **NeuVector**。
1. 不同的集群类型需要不同的容器运行时。配置 Helm Chart 值时，转到**容器运行时**，然后根据集群类型选择运行时。最后，再次单击**安装**。
以下是一些例子：
- RKE1：`docker`
- K3s 和 RKE2：`k3scontainerd`
- AKS：`containerd` 适用于 v1.19 及更高版本
- EKS：`docker` 适用于 v1.22 及以下版本；`containerd` 适用于 v1.23 及更高版本
- GKE：`containerd`（请参阅 [Google 文档](https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd)了解更多信息）
:::note
在安装过程中一次只能选择一个容器运行时引擎。
:::
**通过集群工具导航并安装 NeuVector Chart**：
1. 点击 **☰ > 集群管理**。
1. 在 Clusters 页面上，转到要部署 NeuVector 的集群，然后单击 **Explore**。
1. 点击左侧导航栏底部的**集群工具**。
1. 按照上面的步骤 4 相应地选择你的容器运行时，然后再次单击**安装**。
### 从 Rancher UI 访问 NeuVector
1. 导航到安装了 NeuVector 的集群的 Cluster Explorer。在左侧导航栏中，单击 **NeuVector**。
1. 单击外部链接以转到 NeuVector UI。选择链接后，用户必须接受`最终用户许可协议`才能访问 NeuVector UI。
### 从 Rancher UI 卸载 NeuVector
**通过"应用 & 应用市场"卸载**：
1. 点击 **☰ > 集群管理**。
1. 在**应用 & 应用市场**下，点击**已安装的应用**。
1. 在 `cattle-neuvector-system` 下，选择 NeuVector 应用程序（如果需要，还可以选择相关的 CRD），然后单击**删除**。
**通过集群工具卸载**：
1. 点击 **☰ > 集群管理**。
1. 单击屏幕左下角的**集群工具**，然后单击 NeuVector Chart 下方的垃圾桶图标。如果需要，选择`删除与此应用关联的 CRD`，然后单击**删除**。
### GitHub 仓库
NeuVector 项目在[这里](https://github.com/neuvector/neuvector)。
### 文档
NeuVector 文档在[这里](https://open-docs.neuvector.com/)。
### 架构
NeuVector 安全解决方案包含四种类型的安全容器，分别是 Controller、Enforcer、Manager 和 Scanner。它还提供了一个称为 All-in-One 的特殊容器（主要用于 Docker 原生部署），能将 Controller、Enforcer 和 Manager 功能组合在一个容器中。此外，还有一个 Updater，运行该程序时会更新 CVE 数据库。
- **Controller**：管理 NeuVector Enforcer 容器；为管理控制台提供 REST API。
- **Enforcer**：执行安全策略。
- **Manager**：提供一个 web-UI 和 CLI 控制台来管理 NeuVector 平台。
- **All-in-One**：包括 Controller、Enforcer 和 Manager。
- **Scanner**：对镜像、容器和节点执行漏洞和合规性扫描。
- **Updater**：更新 Neuvector 的 CVE 数据库（运行的时候）；重新部署 scanner pod。
<figcaption>**NeuVector 安全容器：**</figcaption>
![NeuVector 安全容器](/img/neuvector-security-containers.png)
<figcaption>**NeuVector 架构：**</figcaption>
![NeuVector 架构](/img/neuvector-architecture.png)
要了解有关 NeuVector 架构的更多信息，请参阅[此处](https://open-docs.neuvector.com/basics/overview#architecture)。
### CPU 和内存分配
以下是默认 NeuVector Chart 安装部署的最低计算资源推荐。请注意，未设置资源限制。
| 容器 | CPU - 请求 | 内存 - 请求 |
|------------|--------|---------|
| Controller | 3（每个控制器需要 1GB 1vCPU） | * |
| Enforcer | 所有节点上 (500MB .5vCPU) | 1GB |
| Manager | 1 (500MB .5vCPU) | * |
| Scanner | 3 (100MB .5vCPU) | * |
\* Controller、Manager 和 Scanner 容器合计至少需要 1GB 内存。
### 强化集群支持 - Calico 和 Canal
<Tabs>
<TabItem value="RKE1">
- 如果 PSP 设置为 true，则所有 NeuVector 组件都是可部署的。
**_v2.6.7 新功能_**
你需要为强化集群环境进行额外的配置，如下所示：
1. 点击 **☰ > 集群管理**。
1. 选择你创建的集群，并点击 **Explore**。
1. 在左侧导航栏中，点击**应用 & 应用市场**。
1. 安装（或升级到）NeuVector 版本 `100.0.1+up2.2.2`。
- 在 **编辑选项** > **其它配置**下，选中复选框来启用 **Pod 安全策略**（无需其他配置）：
![为 RKE1 强化集群启用 PSP](/img/psp-nv-rke.png)
1. 点击右下角的**安装**。
</TabItem>
<TabItem value="RKE2">
- 如果 PSP 设置为 true，则可以部署 NeuVector 组件 Controller 和 Enforcer。
**仅适用于 NeuVector Chart 版本 100.0.0+up2.2.0**：
- 对于 Manager、Scanner 和 Updater 组件，需要进行额外的配置，如下所示：
```
kubectl patch deploy neuvector-manager-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
kubectl patch deploy neuvector-scanner-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
kubectl patch cronjob neuvector-updater-pod -n cattle-neuvector-system --patch '{"spec":{"jobTemplate":{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}}}'
```
<br/>
**_v2.6.7 新功能_**
你需要为强化集群环境进行额外的配置。
> **注意**：你必须更新 RKE2 和 K3s 强化集群中的配置，如下所示。
1. 点击 **☰ > 集群管理**。
1. 选择你创建的集群，并点击 **Explore**。
1. 在左侧导航栏中，点击**应用 & 应用市场**。
1. 安装（或升级到）NeuVector 版本 `100.0.1+up2.2.2`。
- 在 **编辑选项** > **其它配置**下，选中复选框来启用 **Pod 安全策略**。请注意，对于 `Manager runAsUser ID`、`Scanner runAsUser ID` 和 `Updater runAsUser ID`，你还必须输入大于 `0` 的值:
![为 RKE2 和 K3s 强化集群启用 PSP](/img/psp-nv-rke2.png)
1. 点击右下角的**安装**。
</TabItem>
</Tabs>
### 启用 SELinux 的集群支持 - Calico 和 Canal
要在 RKE2 集群上启用 SELinux，请执行以下步骤：
- 如果 PSP 设置为 true，则可以部署 NeuVector 组件 Controller 和 Enforcer。
**仅适用于 NeuVector Chart 版本 100.0.0+up2.2.0**：
- 对于 Manager、Scanner 和 Updater 组件，需要进行额外的配置，如下所示：
```
kubectl patch deploy neuvector-manager-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
kubectl patch deploy neuvector-scanner-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
kubectl patch cronjob neuvector-updater-pod -n cattle-neuvector-system --patch '{"spec":{"jobTemplate":{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}}}'
```
### 离线环境中的集群支持
- 所有 NeuVector 组件都可部署在离线环境中的集群上，无需任何额外配置。
### 支持限制
* 目前仅支持管理员和集群所有者。
* 不支持 Fleet 多集群部署。
* Windows 集群不支持 NeuVector。
### 其他限制
* 目前，如果 NeuVector partner Chart 已存在，则 NeuVector 功能 Chart 的安装会失败。要解决此问题，请卸载 NeuVector partner Chart 并重新安装 NeuVector 功能 Chart。
* Controller 未准备好时，有可能无法从 Rancher UI 访问 NeuVector UI。在此期间，Controller 将尝试重新启动，并且需要几分钟才能进入 active 状态。
* 安装 NeuVector Chart 时，不会针对不同的集群类型自动检测容器运行时。要解决此问题，你可以手动指定运行时。
i18n/zh/docusaurus-plugin-content-docs/current/explanations/integrations-in-rancher/opa-gatekeeper.md
+112
View File
@@ -0,0 +1,112 @@
---
title: OPA Gatekeeper
weight: 16
---
为了确保一致性和合规性，每个组织都需要能够以自动化的方式在环境中定义和执行策略。[OPA（Open Policy Agent）](https://www.openpolicyagent.org/) 是一个策略引擎，用于基于策略控制云原生环境。Rancher 支持在 Kubernetes 集群中启用 OPA Gatekeeper，并且还安装了一些内置的策略定义（也称为约束模板）。
OPA 提供了一种高级声明性语言，可以让你将策略指定为代码，还能扩展简单的 API，从而减轻策略决策的负担。
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 是一个提供 OPA 和 Kubernetes 集成的项目。OPA Gatekeeper 提供：
- 一个可扩展的参数化策略库。
- 用于实例化策略库的原生 Kubernetes CRD，也称为“约束”。
- 用于扩展策略库的原生 Kubernetes CRD，也称为“约束模板”。
- 审计功能。
要了解更多关于 OPA 的信息，请参阅[官方文档](https://www.openpolicyagent.org/docs/latest/)。
## OPA Gatekeeper 集成的工作原理
Kubernetes 支持通过准入控制器（准入控制器）webhook 来扩展 API Server 的功能，创建、更新或删除资源时都会调用这些 webhook。Gatekeeper 作为验证 webhook 安装，并执行由 Kubernetes CRD（Custom Resource Definition）定义的策略。除了使用准入控制之外，Gatekeeper 还能审计 Kubernetes 集群中的现有资源，并对违反当前策略的情况进行标记。
OPA Gatekeeper 由 Rancher 的 Helm system Chart 提供，它安装在名为 `gatekeeper-system` 的命名空间中。
## 在集群中启用 OPA Gatekeeper
:::note
Rancher 2.5 改进了 OPA Gatekeeper 应用。无法从 Rancher 2.4 升级到 Rancher 2.5 中的新版本。如果你在 Rancher 2.4 中安装了 OPA Gatekeeper，则需要在旧 UI 中卸载 OPA Gatekeeper 及其 CRD，然后在 Rancher 2.5 中重新安装它。如需卸载 CRD，请在 kubectl 控制台中运行 `kubectl delete crd configs.config.gatekeeper.sh constrainttemplates.templates.gatekeeper.sh` 命令。
:::
:::note 先决条件：
只有管理员和集群所有者才能启用 OPA Gatekeeper。
:::
你可以在**应用 & 应用市场**页面安装 OPA Gatekeeper Helm Chart。
### 启用 OPA Gatekeeper
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面中，转到要启用 OPA Gatekeeper 的集群，然后单击 **Explore**。
1. 在左侧导航栏中，点击**应用 & 应用市场**。
1. 点击 **Charts** 并点击 **OPA Gatekeeper**。
1. 单击**安装**。
**结果**：已将 OPA Gatekeeper 部署到你的 Kubernetes 集群。
## 约束模板
[约束模板](https://github.com/open-policy-agent/gatekeeper#constraint-templates)是 Kubernetes 自定义资源，用于定义要由 Gatekeeper 应用的 OPA 策略的架构和 Rego 逻辑。有关 Rego 策略语言的更多信息，请参阅[官方文档](https://www.openpolicyagent.org/docs/latest/policy-language/)。
启用 OPA Gatekeeper 后，Rancher 默认会安装一些模板。
要列出集群中安装的约束模板，请转到 OPA Gatekeeper 下的左侧菜单，然后单击**模板**。
Rancher 还支持通过导入 YAML 定义来创建你自己的约束模板。
## 创建和配置约束
[约束](https://github.com/open-policy-agent/gatekeeper#constraints)是 Kubernetes 自定义资源，用于定义要应用约束模板的对象范围。约束模板和约束共同定义一个完整的策略。
:::note 先决条件：
集群中已启用 OPA Gatekeeper。
:::
要列出已安装的约束，请转到 OPA Gatekeeper 下的左侧菜单，然后单击**约束**。
可以从约束模板创建新的约束。
Rancher 支持通过使用方便的表单来创建约束，你可以在该表单中输入各种约束字段。
**以 YAML 文件编辑**选项也可以用于配置约束的 YAML 定义。
### 使 Rancher 的 System 命名空间不受约束
创建约束时，请确保该约束不应用于任何 Rancher 或 Kubernetes System 命名空间。如果不排除 System 命名空间，则可能会出现 system 命名空间下的许多资源被标记为违反约束。
要让约束仅限制用户命名空间，请在约束的**匹配**字段下指定这些命名空间。
此外，该约束可能会干扰其他 Rancher 功能并拒绝部署系统工作负载。为避免这种情况，请从你的约束中排除所有 Rancher 特定的命名空间。
## 在集群中实施约束
如果**执行动作**为 **Deny**，约束会立即启用，并拒绝任何违反策略的请求。默认情况下，执行的值为 **Deny**。
如果**执行动作** 为 **Dryrun**，违反策略的资源仅会记录在约束的状态字段中。
要强制执行约束，请使用表单创建约束。在**执行动作**字段中，选择 **Deny**。
## 集群中的审计和违规
OPA Gatekeeper 运行定期审计，以检查现有资源是否违反强制执行的约束。你可以在安装 Gatekeeper 时配置审计间隔（默认 300 秒）。
Gatekeeper 页面上列出了违反已定义的约束的情况。
此外，你也可以在**约束**页面中找到违反约束的数量。
每个约束的详细信息视图列出了违反约束的资源的信息。
## 禁用 Gatekeeper
1. 导航到集群的仪表板视图。
1. 在左侧菜单中，展开集群菜单并单击 **OPA Gatekeeper**。
1. 单击 **⋮ > 禁用**。
**结果**：禁用 OPA Gatekeeper 后，所有约束模板和约束也将被删除。
i18n/zh/docusaurus-plugin-content-docs/current/faq.md
+70
View File
@@ -0,0 +1,70 @@
---
title: 常见问题
weight: 500
---
本文包含了用户常见的 Rancher 2.x 问题。
有关常见技术问题，请参阅[常见技术问题解答](faq/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 2.3.0 开始，我们支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息，请参阅[为 Windows 配置自定义集群](pages-for-subheaders/use-windows-clusters.md)。
<br/>
**Rancher 是否支持 Istio？**
从 Rancher 2.3.0 开始，我们支持 [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+ 中。
i18n/zh/docusaurus-plugin-content-docs/current/faq/container-network-interface-providers.md
+205
View File
@@ -0,0 +1,205 @@
---
title: CNI 网络插件
description: 了解容器网络接口 (CNI)、Rancher 提供的 CNI 网络插件、提供商的功能，以及如何选择网络提供商
weight: 2300
---
## 什么是 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/)选项来配置集群的说明。
i18n/zh/docusaurus-plugin-content-docs/current/faq/deprecated-features-in-v2.5.md
+27
View File
@@ -0,0 +1,27 @@
---
title: Rancher 弃用的功能
weight: 100
---
### 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"（已弃用），该功能仍然可用并受支持，从而允许用户按照常规流程进行升级。在升级到该功能被标记为"已删除"的发行版前，用户/管理员应该计划剥离该功能。对于新部署，我们建议不要使用已弃用的功能。
i18n/zh/docusaurus-plugin-content-docs/current/faq/dockershim.md
+46
View File
@@ -0,0 +1,46 @@
---
title: Dockershim
weight: 300
---
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/>
i18n/zh/docusaurus-plugin-content-docs/current/faq/install-and-configure-kubectl.md
+30
View File
@@ -0,0 +1,30 @@
---
title: 安装和配置 kubectl
weight: 100
---
`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
```
i18n/zh/docusaurus-plugin-content-docs/current/faq/networking/networking.md
+9
View File
@@ -0,0 +1,9 @@
---
title: 网络
weight: 8005
---
网络常见问题
- [CNI 网络插件](../container-network-interface-providers.md)
i18n/zh/docusaurus-plugin-content-docs/current/faq/rancher-is-no-longer-needed.md
+62
View File
@@ -0,0 +1,62 @@
---
title: 卸载 Rancher
weight: 8010
---
本文介绍了如果你不再需要 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）](../pages-for-subheaders/rancher-manager-architecture.md#4-授权集群端点)，而且你必须从 Rancher UI 下载了集群的 kubeconfig 文件。RKE 集群默认启用授权集群端点。通过使用此端点，你可以直接使用 kubectl 访问你的集群，而不用通过 Rancher Server 的[认证代理](../pages-for-subheaders/rancher-manager-architecture.md#1-认证代理)进行通信。有关配置 kubectl 以使用授权集群端点的说明，请参阅[使用 kubectl 和 kubeconfig 文件直接访问集群](../how-to-guides/advanced-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。
从 Rancher 2.5.8 开始，在高可用性 (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，该如何访问下游集群)。
i18n/zh/docusaurus-plugin-content-docs/current/faq/security.md
+15
View File
@@ -0,0 +1,15 @@
---
title: 安全
weight: 8007
---
**是否有强化指南？**
强化指南现在位于[安全](../pages-for-subheaders/rancher-security.md)部分。
<br/>
**Rancher Kubernetes 集群 CIS Benchmark 测试的结果是什么？**
我们已经针对强化的 Rancher Kubernetes 集群运行了 CIS Kubernetes Benchmark 测试。你可以在[安全](../pages-for-subheaders/rancher-security.md)中找到该评估的结果。
i18n/zh/docusaurus-plugin-content-docs/current/faq/technical-items.md
+177
View File
@@ -0,0 +1,177 @@
---
title: 技术
weight: 8006
---
### 如何重置管理员密码？
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-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/advanced-user-guides/manage-clusters/clean-cluster-nodes.md)来清理节点。
在集群中移除并清理节点时，你可以将节点重新添加到集群中。
### 如何将其他参数/绑定/环境变量添加到 Rancher 启动的 Kubernetes 集群的 Kubernetes 组件中？
你可以使用集群选项中的[配置文件](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#集群配置文件)选项来添加其他参数/​​绑定/环境变量。有关详细信息，请参阅 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 任意位置按 `?`。
i18n/zh/docusaurus-plugin-content-docs/current/faq/telemetry.md
+32
View File
@@ -0,0 +1,32 @@
---
title: 遥测
weight: 8008
---
### 什么是遥测？
遥测（Telemetry）收集 Rancher 安装大小、使用的组件版本以及使用功能的汇总信息。Rancher Labs 会使用此信息来改进产品，我们不会与第三方共享此信息。
### 收集什么信息？
我们不会收集任何识别信息（如用户名、密码或用户资源的名称或地址）。
收集的主要内容包括：
- 每个集群的节点总数（最小、平均、最大、总数）及其大小（例如 CPU 核心数和 RAM）。
- 集群、项目、命名空间和 Pod 等逻辑资源的聚合计数。
- 用于部署集群和节点的驱动程序计数（例如 GKE、EC2、导入与自定义）。
- 部署在节点上的 Kubernetes 组件、操作系统和 Docker 的版本。
- 是否启用了某些可选组件（例如，使用了哪些身份验证提供程序）。
- 运行的 Rancher 的镜像名称和版本。
- 此安装的唯一随机标识符。
### 我可以看到发送的信息吗？
如果启用了遥测，你可以转到 `https://<your rancher server>/v1-telemetry` 查看当前数据。
如果未启用遥测，则收集数据的进程未运行，因此没有可供查看的内容。
### 如何打开或关闭它？
完成初始设置后，管理员可以转到 UI `全局`中的`设置`页面，单击**编辑**，然后将 `telemetry-opt` 更改为 `in` 或 `out`。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started.md
+10
View File
@@ -0,0 +1,10 @@
---
title: 开始使用
---
**开始使用**章节能帮助你快速启动和运行 Rancher。
本章节旨在帮助用户部署 Rancher 和工作负载，并快速有效地安装或升级 Rancher。
请参阅[简介](./pages-for-subheaders/introduction.md)、[快速入门指南](./pages-for-subheaders/quick-start-guides.md)以及[安装和升级](./pages-for-subheaders/installation-and-upgrade.md)部分了解更多信息。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md
+261
View File
@@ -0,0 +1,261 @@
---
title: 7 层 NGINX 负载均衡器上的 TLS 终止（Docker 安装）
weight: 252
---
如果你的开发或测试环境要求在负载均衡器上终止 TLS/SSL，而不是在 Rancher Server 上，请部署 Rancher 并配置负载均衡器。
如果要在基础设施中对 TLS 集中进行终止，请使用 7 层负载均衡器。7 层负载均衡还能让你的负载均衡器基于 HTTP 属性（例如 cookie 等）做出决策，而 4 层负载均衡器则不能。
本文中的安装步骤将引导你使用单个容器部署 Rancher，并提供 7 层 NGINX 负载均衡器的示例配置。
## 操作系统，Docker，硬件和网络要求
请确保你的节点满足常规的[安装要求](../../../../pages-for-subheaders/installation-requirements.md)。
## 安装概要
## 1. 配置 Linux 主机
根据我们的[要求](../../../../pages-for-subheaders/installation-requirements.md)配置一个 Linux 主机来启动 Rancher Server。
## 2. 选择一个 SSL 选项并安装 Rancher
出于安全考虑，使用 Rancher 时请使用 SSL（Secure Sockets Layer）。SSL 保护所有 Rancher 网络通信（如登录和与集群交互）的安全。
:::note 你是否需要：
- 完成离线安装。
- 记录所有 Rancher API 的事务。
继续之前，请参见[高级选项](#高级选项)。
:::
选择以下的选项之一：
<details id="option-a">
<summary>选项 A：使用你自己的证书 - 自签名</summary>
如果要使用自签名证书来加密通信，你必须在负载均衡器（后续步骤）和 Rancher 容器上安装证书。运行 Docker 命令部署 Rancher，将 Docker 指向你的证书。
:::note 先决条件：
创建自签名证书。
- 证书文件的格式必须是 PEM。
:::
**使用自签名证书安装 Rancher**：
1. 在运行 Docker 命令部署 Rancher 时，将 Docker 指向你的 CA 证书文件。
```
docker run -d --restart=unless-stopped \
-p 80:80 -p 443:443 \
-v /etc/your_certificate_directory/cacerts.pem:/etc/rancher/ssl/cacerts.pem \
rancher/rancher:latest
```
</details>
<details id="option-b">
<summary>选项 B：使用你自己的证书 - 可信 CA 签名的证书</summary>
如果你的集群面向公众，则最好使用由公认 CA 签署的证书。
:::note 先决条件：
- 证书文件的格式必须是 PEM。
:::
**使用授信 CA 签发的证书安装 Rancher**：
如果你使用授信 CA 签发的证书，你无需在 Rancher 容器中安装证书。但是，请确保不要生成和存储默认的 CA 证书（你可以通过将 `--no-cacerts` 参数传递给容器来实现）。
1. 输入以下命令：
```
docker run -d --restart=unless-stopped \
-p 80:80 -p 443:443 \
rancher/rancher:latest --no-cacerts
```
</details>
## 3. 配置负载均衡器
在 Rancher 容器前使用负载均衡器时，容器无需从端口 80 或端口 443 重定向端口通信。你可以通过传递 `X-Forwarded-Proto: https` 标头禁用此重定向。
负载均衡器或代理必须支持以下内容：
- **WebSocket** 连接
- **SPDY** / **HTTP/2** 协议
- 传递/设置以下标头：
| 标头 | 值 | 描述 |
|--------|-------|-------------|
| `Host` | 用于访问 Rancher 的主机名。 | 识别客户端所请求的服务器。 |
| `X-Forwarded-Proto` | `https` | 识别客户端连接负载均衡器或代理时所用的协议。<br /><br/>**注意**：如果此标头存在，`rancher/rancher` 不会将 HTTP 重定向到 HTTPS。 |
| `X-Forwarded-Port` | 用于访问 Rancher 的端口。 | 识别客户端连接到负载均衡器或代理时所用的端口。 |
| `X-Forwarded-For` | 客户端 IP 地址 | 识别客户端的原始 IP 地址。 |
### 示例 NGINX 配置
此 NGINX 配置已在 NGINX 1.14 上进行了测试。
:::note
此 NGINX 配置只是一个示例，可能不适合你的环境。如需查阅完整文档，请参见 [NGINX 负载均衡 - HTTP 负载均衡](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/)。
:::
- 将 `rancher-server` 替换为运行 Rancher 容器的节点的 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 rancher-server: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;
}
}
```
<br/>
## 后续操作
- **推荐**：检查单节点[备份](../../../../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)。你可能暂时没有需要备份的数据，但是我们建议你在常规使用 Rancher 后创建备份。
- 创建 Kubernetes 集群：[配置 Kubernetes 集群](../../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)。
<br/>
## 常见问题和故障排除
如果你需要对证书进行故障排除，请参见[此章节](../../other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)。
## 高级选项
### API 审计
如果你需要记录所有 Rancher API 事务，请将以下标志添加到安装命令中，从而启用 [API 审计](enable-api-audit-log.md)功能。
-e AUDIT_LEVEL=1 \
-e AUDIT_LOG_PATH=/var/log/auditlog/rancher-api-audit.log \
-e AUDIT_LOG_MAXAGE=20 \
-e AUDIT_LOG_MAXBACKUP=20 \
-e AUDIT_LOG_MAXSIZE=100 \
### 离线环境
如果你访问此页面是为了完成[离线安装](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md)，则在运行安装命令时，先将你的私有镜像仓库 URL 附加到 Server 标志中。也就是说，在 `rancher/rancher:latest` 前面添加 `<REGISTRY.DOMAIN.COM:PORT>` 和私有镜像仓库 URL。
**示例**：
<REGISTRY.DOMAIN.COM:PORT>/rancher/rancher:latest
### 持久化数据
Rancher 使用 etcd 作为数据存储。如果 Rancher 是使用 Docker 安装的，Rancher 会使用嵌入式 etcd。持久化数据位于容器的 `/var/lib/rancher` 路径中。
你可以将主机卷挂载到该位置，来将数据保留在运行它的主机上：
```
docker run -d --restart=unless-stopped \
-p 80:80 -p 443:443 \
-v /opt/rancher:/var/lib/rancher \
--privileged \
rancher/rancher:latest
```
Rancher 2.5 开始需要[特权访问](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#rancher-特权访问)。
这个 7 层 NGINX 配置已经在 NGINX 1.13（Mainline）和 1.14（Stable）版本上进行了测试。
:::note
此 NGINX 配置只是一个示例，可能不适合你的环境。如果需要查阅完整文档，请参见 [NGINX 负载均衡 - TCP 和 UDP 负载均衡器](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/)。
:::
```
upstream rancher {
server rancher-server:80;
}
map $http_upgrade $connection_upgrade {
default Upgrade;
'' close;
}
server {
listen 443 ssl http2;
server_name rancher.yourdomain.com;
ssl_certificate /etc/your_certificate_directory/fullchain.pem;
ssl_certificate_key /etc/your_certificate_directory/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 rancher.yourdomain.com;
return 301 https://$server_name$request_uri;
}
```
<br/>
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/enable-api-audit-log.md
+559
View File
@@ -0,0 +1,559 @@
---
title: 启用 API 审计日志以记录系统事件
weight: 4
---
你可以启用 API 审计日志来记录各个用户发起的系统事件的顺序。通过查看日志，你可以了解发生了什么事件、事件发生的时间，事件发起人，以及事件影响的集群。启用此功能后，所有 Rancher API 的请求和响应都会写入日志中。
API 审计可以在 Rancher 安装或升级期间启用。
## 启用 API 审计日志
你可以将环境变量传递给 Rancher Server 容器，从而启用和配置审计日志。请参见以下文档，在安装时启用该功能：
- [Docker 安装](../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-审计日志)
- [Kubernetes 安装](../../../../reference-guides/installation-references/helm-chart-options.md#api-审计日志)
## API 审计日志选项
以下参数定义了审计日志的记录规则，其中包括应该记录什么内容以及包括什么数据：
| 参数 | 描述 |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| <a id="audit-level"></a>`AUDIT_LEVEL` | `0` - 禁用审计日志（默认）<br /> `1` - 日志事件元数据<br /> `2` - 日志事件元数据和请求体<br /> `3` - 日志事件元数据，请求体和响应体。请求/响应对的每个日志事务都使用同一个的 `auditID`。<br /> 如需了解每个设置记录的日志内容，请参见[审计日志级别](#审核日志级别)。 |
| `AUDIT_LOG_PATH` | Rancher Server API 的日志路径。默认路径：`/var/log/auditlog/rancher-api-audit.log`。你可以将日志目录挂载到主机。<br/><br/>示例：`AUDIT_LOG_PATH=/my/custom/path/`<br/> |
| `AUDIT_LOG_MAXAGE` | 旧审计日志文件可保留的最大天数。默认为 10 天。 |
| `AUDIT_LOG_MAXBACKUP` | 保留的审计日志最大文件个数。默认值为 10。 |
| `AUDIT_LOG_MAXSIZE` | 在审计日志文件被轮换前的最大容量，单位是 MB。默认大小为 100MB。 |
<br/>
### 审核日志级别
下表介绍了每个 [`AUDIT_LEVEL`](#audit-level) 记录的 API 事务：
| `AUDIT_LEVEL` 设置 | 请求元数据 | 请求体 | 响应元数据 | 响应体 |
| --------------------- | ---------------- | ------------ | ----------------- | ------------- |
| `0` | | | | |
| `1` | ✓ | | | |
| `2` | ✓ | ✓ | | |
| `3` | ✓ | ✓ | ✓ | ✓ |
## 查看 API 审计日志
### Docker 安装
与主机系统共享 `AUDIT_LOG_PATH` 目录（默认目录：`/var/log/auditlog`）。日志可以通过标准 CLI 工具进行解析，也可以转发到 Fluentd、Filebeat、Logstash 等日志收集工具。
### Kubernetes 安装
使用 Helm Chart 安装 Rancher 时启动 API 审计日志，会在 Rancher Pod 中创建一个 `rancher-audit-log` Sidecar 容器。该容器会将日志发送到标准输出 (stdout)。你可以像查看其他容器的日志一样查看 API 审计日志。
`rancher-audit-log` 容器位于 `cattle-system` 命名空间中的 `rancher` Pod 中。
#### CLI
```bash
kubectl -n cattle-system logs -f rancher-84d886bdbb-s4s69 rancher-audit-log
```
#### 发送审计日志
你可以为集群启用 Rancher 的内置日志收集和传送功能，将审计日志和其他服务日志发送到支持的 endpoint。详情请参见 [Rancher 工具 - Logging](../../../../pages-for-subheaders/logging.md)。
## 审计日志示例
启用审计日志后，Rancher 会以 JSON 格式记录每个 API 的请求和响应。下文的代码示例展示了如何查看 API 事务。
### 元数据日志级别
如果你将 `AUDIT_LEVEL` 设置为 `1`，Rancher 只会记录每个 API 请求的元数据标头，而不会记录请求体。标头记录了 API 事务的基本信息，包括 ID、发起人、发起时间等。代码示例如下：
```json
{
"auditID": "30022177-9e2e-43d1-b0d0-06ef9d3db183",
"requestURI": "/v3/schemas",
"sourceIPs": ["::1"],
"user": {
"name": "user-f4tt2",
"group": ["system:authenticated"]
},
"verb": "GET",
"stage": "RequestReceived",
"stageTimestamp": "2018-07-20 10:22:43 +0800"
}
```
### 元数据和请求体日志级别
如果你将 `AUDIT_LEVEL` 设置为 `2`，Rancher 会记录每个 API 请求的元数据标头和请求体。
下面的代码示例描述了一个 API 请求，包括它的元数据标头和正文：
```json
{
"auditID": "ef1d249e-bfac-4fd0-a61f-cbdcad53b9bb",
"requestURI": "/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
"sourceIPs": ["::1"],
"user": {
"name": "user-f4tt2",
"group": ["system:authenticated"]
},
"verb": "PUT",
"stage": "RequestReceived",
"stageTimestamp": "2018-07-20 10:28:08 +0800",
"requestBody": {
"hostIPC": false,
"hostNetwork": false,
"hostPID": false,
"paused": false,
"annotations": {},
"baseType": "workload",
"containers": [
{
"allowPrivilegeEscalation": false,
"image": "nginx",
"imagePullPolicy": "Always",
"initContainer": false,
"name": "nginx",
"ports": [
{
"containerPort": 80,
"dnsName": "nginx-nodeport",
"kind": "NodePort",
"name": "80tcp01",
"protocol": "TCP",
"sourcePort": 0,
"type": "/v3/project/schemas/containerPort"
}
],
"privileged": false,
"readOnly": false,
"resources": {
"type": "/v3/project/schemas/resourceRequirements",
"requests": {},
"limits": {}
},
"restartCount": 0,
"runAsNonRoot": false,
"stdin": true,
"stdinOnce": false,
"terminationMessagePath": "/dev/termination-log",
"terminationMessagePolicy": "File",
"tty": true,
"type": "/v3/project/schemas/container",
"environmentFrom": [],
"capAdd": [],
"capDrop": [],
"livenessProbe": null,
"volumeMounts": []
}
],
"created": "2018-07-18T07:34:16Z",
"createdTS": 1531899256000,
"creatorId": null,
"deploymentConfig": {
"maxSurge": 1,
"maxUnavailable": 0,
"minReadySeconds": 0,
"progressDeadlineSeconds": 600,
"revisionHistoryLimit": 10,
"strategy": "RollingUpdate"
},
"deploymentStatus": {
"availableReplicas": 1,
"conditions": [
{
"lastTransitionTime": "2018-07-18T07:34:38Z",
"lastTransitionTimeTS": 1531899278000,
"lastUpdateTime": "2018-07-18T07:34:38Z",
"lastUpdateTimeTS": 1531899278000,
"message": "Deployment has minimum availability.",
"reason": "MinimumReplicasAvailable",
"status": "True",
"type": "Available"
},
{
"lastTransitionTime": "2018-07-18T07:34:16Z",
"lastTransitionTimeTS": 1531899256000,
"lastUpdateTime": "2018-07-18T07:34:38Z",
"lastUpdateTimeTS": 1531899278000,
"message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
"reason": "NewReplicaSetAvailable",
"status": "True",
"type": "Progressing"
}
],
"observedGeneration": 2,
"readyReplicas": 1,
"replicas": 1,
"type": "/v3/project/schemas/deploymentStatus",
"unavailableReplicas": 0,
"updatedReplicas": 1
},
"dnsPolicy": "ClusterFirst",
"id": "deployment:default:nginx",
"labels": {
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
},
"name": "nginx",
"namespaceId": "default",
"projectId": "c-bcz5t:p-fdr4s",
"publicEndpoints": [
{
"addresses": ["10.64.3.58"],
"allNodes": true,
"ingressId": null,
"nodeId": null,
"podId": null,
"port": 30917,
"protocol": "TCP",
"serviceId": "default:nginx-nodeport",
"type": "publicEndpoint"
}
],
"restartPolicy": "Always",
"scale": 1,
"schedulerName": "default-scheduler",
"selector": {
"matchLabels": {
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
},
"type": "/v3/project/schemas/labelSelector"
},
"state": "active",
"terminationGracePeriodSeconds": 30,
"transitioning": "no",
"transitioningMessage": "",
"type": "deployment",
"uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
"workloadAnnotations": {
"deployment.kubernetes.io/revision": "1",
"field.cattle.io/creatorId": "user-f4tt2"
},
"workloadLabels": {
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
},
"scheduling": {
"node": {}
},
"description": "my description",
"volumes": []
}
}
```
### 元数据、请求体和响应体日志级别
如果你将 `AUDIT_LEVEL` 设置为 `3`，Rancher 会记录：
- 每个 API 请求的元数据标头和请求体。
- 每个 API 响应的元数据标头和响应体。
#### 请求
下面的代码示例描述了一个 API 请求，包括它的元数据标头和正文：
```json
{
"auditID": "a886fd9f-5d6b-4ae3-9a10-5bff8f3d68af",
"requestURI": "/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
"sourceIPs": ["::1"],
"user": {
"name": "user-f4tt2",
"group": ["system:authenticated"]
},
"verb": "PUT",
"stage": "RequestReceived",
"stageTimestamp": "2018-07-20 10:33:06 +0800",
"requestBody": {
"hostIPC": false,
"hostNetwork": false,
"hostPID": false,
"paused": false,
"annotations": {},
"baseType": "workload",
"containers": [
{
"allowPrivilegeEscalation": false,
"image": "nginx",
"imagePullPolicy": "Always",
"initContainer": false,
"name": "nginx",
"ports": [
{
"containerPort": 80,
"dnsName": "nginx-nodeport",
"kind": "NodePort",
"name": "80tcp01",
"protocol": "TCP",
"sourcePort": 0,
"type": "/v3/project/schemas/containerPort"
}
],
"privileged": false,
"readOnly": false,
"resources": {
"type": "/v3/project/schemas/resourceRequirements",
"requests": {},
"limits": {}
},
"restartCount": 0,
"runAsNonRoot": false,
"stdin": true,
"stdinOnce": false,
"terminationMessagePath": "/dev/termination-log",
"terminationMessagePolicy": "File",
"tty": true,
"type": "/v3/project/schemas/container",
"environmentFrom": [],
"capAdd": [],
"capDrop": [],
"livenessProbe": null,
"volumeMounts": []
}
],
"created": "2018-07-18T07:34:16Z",
"createdTS": 1531899256000,
"creatorId": null,
"deploymentConfig": {
"maxSurge": 1,
"maxUnavailable": 0,
"minReadySeconds": 0,
"progressDeadlineSeconds": 600,
"revisionHistoryLimit": 10,
"strategy": "RollingUpdate"
},
"deploymentStatus": {
"availableReplicas": 1,
"conditions": [
{
"lastTransitionTime": "2018-07-18T07:34:38Z",
"lastTransitionTimeTS": 1531899278000,
"lastUpdateTime": "2018-07-18T07:34:38Z",
"lastUpdateTimeTS": 1531899278000,
"message": "Deployment has minimum availability.",
"reason": "MinimumReplicasAvailable",
"status": "True",
"type": "Available"
},
{
"lastTransitionTime": "2018-07-18T07:34:16Z",
"lastTransitionTimeTS": 1531899256000,
"lastUpdateTime": "2018-07-18T07:34:38Z",
"lastUpdateTimeTS": 1531899278000,
"message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
"reason": "NewReplicaSetAvailable",
"status": "True",
"type": "Progressing"
}
],
"observedGeneration": 2,
"readyReplicas": 1,
"replicas": 1,
"type": "/v3/project/schemas/deploymentStatus",
"unavailableReplicas": 0,
"updatedReplicas": 1
},
"dnsPolicy": "ClusterFirst",
"id": "deployment:default:nginx",
"labels": {
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
},
"name": "nginx",
"namespaceId": "default",
"projectId": "c-bcz5t:p-fdr4s",
"publicEndpoints": [
{
"addresses": ["10.64.3.58"],
"allNodes": true,
"ingressId": null,
"nodeId": null,
"podId": null,
"port": 30917,
"protocol": "TCP",
"serviceId": "default:nginx-nodeport",
"type": "publicEndpoint"
}
],
"restartPolicy": "Always",
"scale": 1,
"schedulerName": "default-scheduler",
"selector": {
"matchLabels": {
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
},
"type": "/v3/project/schemas/labelSelector"
},
"state": "active",
"terminationGracePeriodSeconds": 30,
"transitioning": "no",
"transitioningMessage": "",
"type": "deployment",
"uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
"workloadAnnotations": {
"deployment.kubernetes.io/revision": "1",
"field.cattle.io/creatorId": "user-f4tt2"
},
"workloadLabels": {
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
},
"scheduling": {
"node": {}
},
"description": "my decript",
"volumes": []
}
}
```
#### 响应
下面的代码示例描述了一个 API 响应，包括它的元数据标头和正文：
```json
{
"auditID": "a886fd9f-5d6b-4ae3-9a10-5bff8f3d68af",
"responseStatus": "200",
"stage": "ResponseComplete",
"stageTimestamp": "2018-07-20 10:33:06 +0800",
"responseBody": {
"actionLinks": {
"pause": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=pause",
"resume": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=resume",
"rollback": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=rollback"
},
"annotations": {},
"baseType": "workload",
"containers": [
{
"allowPrivilegeEscalation": false,
"image": "nginx",
"imagePullPolicy": "Always",
"initContainer": false,
"name": "nginx",
"ports": [
{
"containerPort": 80,
"dnsName": "nginx-nodeport",
"kind": "NodePort",
"name": "80tcp01",
"protocol": "TCP",
"sourcePort": 0,
"type": "/v3/project/schemas/containerPort"
}
],
"privileged": false,
"readOnly": false,
"resources": {
"type": "/v3/project/schemas/resourceRequirements"
},
"restartCount": 0,
"runAsNonRoot": false,
"stdin": true,
"stdinOnce": false,
"terminationMessagePath": "/dev/termination-log",
"terminationMessagePolicy": "File",
"tty": true,
"type": "/v3/project/schemas/container"
}
],
"created": "2018-07-18T07:34:16Z",
"createdTS": 1531899256000,
"creatorId": null,
"deploymentConfig": {
"maxSurge": 1,
"maxUnavailable": 0,
"minReadySeconds": 0,
"progressDeadlineSeconds": 600,
"revisionHistoryLimit": 10,
"strategy": "RollingUpdate"
},
"deploymentStatus": {
"availableReplicas": 1,
"conditions": [
{
"lastTransitionTime": "2018-07-18T07:34:38Z",
"lastTransitionTimeTS": 1531899278000,
"lastUpdateTime": "2018-07-18T07:34:38Z",
"lastUpdateTimeTS": 1531899278000,
"message": "Deployment has minimum availability.",
"reason": "MinimumReplicasAvailable",
"status": "True",
"type": "Available"
},
{
"lastTransitionTime": "2018-07-18T07:34:16Z",
"lastTransitionTimeTS": 1531899256000,
"lastUpdateTime": "2018-07-18T07:34:38Z",
"lastUpdateTimeTS": 1531899278000,
"message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
"reason": "NewReplicaSetAvailable",
"status": "True",
"type": "Progressing"
}
],
"observedGeneration": 2,
"readyReplicas": 1,
"replicas": 1,
"type": "/v3/project/schemas/deploymentStatus",
"unavailableReplicas": 0,
"updatedReplicas": 1
},
"dnsPolicy": "ClusterFirst",
"hostIPC": false,
"hostNetwork": false,
"hostPID": false,
"id": "deployment:default:nginx",
"labels": {
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
},
"links": {
"remove": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
"revisions": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx/revisions",
"self": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
"update": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
"yaml": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx/yaml"
},
"name": "nginx",
"namespaceId": "default",
"paused": false,
"projectId": "c-bcz5t:p-fdr4s",
"publicEndpoints": [
{
"addresses": ["10.64.3.58"],
"allNodes": true,
"ingressId": null,
"nodeId": null,
"podId": null,
"port": 30917,
"protocol": "TCP",
"serviceId": "default:nginx-nodeport"
}
],
"restartPolicy": "Always",
"scale": 1,
"schedulerName": "default-scheduler",
"selector": {
"matchLabels": {
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
},
"type": "/v3/project/schemas/labelSelector"
},
"state": "active",
"terminationGracePeriodSeconds": 30,
"transitioning": "no",
"transitioningMessage": "",
"type": "deployment",
"uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
"workloadAnnotations": {
"deployment.kubernetes.io/revision": "1",
"field.cattle.io/creatorId": "user-f4tt2"
},
"workloadLabels": {
"workload.user.cattle.io/workloadselector": "deployment-default-nginx"
}
}
}
```
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/open-ports-with-firewalld.md
+108
View File
@@ -0,0 +1,108 @@
---
title: 使用 firewalld 打开端口
weight: 1
---
> 我们建议禁用 firewalld。如果你使用的是 Kubernetes 1.19 或更高版本，则必须关闭 firewalld。
某些 [源自 RHEL](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds) 的 Linux 发行版（包括 Oracle Linux）的默认防火墙规则可能会阻止与 Helm 的通信。
例如，AWS 中的一个 Oracle Linux 镜像具有 REJECT 规则，这些规则会阻止 Helm 与 Tiller 通信：
```
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
```
你可运行以下命令检查默认防火墙规则：
```
sudo iptables --list
```
下文介绍如何使用 `firewalld`，将[防火墙端口规则](../../installation-requirements/port-requirements.md)应用到高可用 Rancher Server 集群中的节点。
## 先决条件
安装 v7.x 或更高版本的 `firewalld`：
```
yum install firewalld
systemctl start firewalld
systemctl enable firewalld
```
## 应用防火墙端口规则
在 Rancher 高可用安装中，Rancher Server 设置在三个节点上，三个节点均具有 Kubernetes 的所有三个角色（etcd、controlplane 和 worker）。如果你的 Rancher Server 节点同时具有这三个角色，请在每个节点上运行以下命令：
```
firewall-cmd --permanent --add-port=22/tcp
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --permanent --add-port=2376/tcp
firewall-cmd --permanent --add-port=2379/tcp
firewall-cmd --permanent --add-port=2380/tcp
firewall-cmd --permanent --add-port=6443/tcp
firewall-cmd --permanent --add-port=8472/udp
firewall-cmd --permanent --add-port=9099/tcp
firewall-cmd --permanent --add-port=10250/tcp
firewall-cmd --permanent --add-port=10254/tcp
firewall-cmd --permanent --add-port=30000-32767/tcp
firewall-cmd --permanent --add-port=30000-32767/udp
```
如果你的 Rancher Server 节点配置了单独的角色，请根据节点角色运行以下命令：
```
# 在 etcd 节点上运行以下命令：
firewall-cmd --permanent --add-port=2376/tcp
firewall-cmd --permanent --add-port=2379/tcp
firewall-cmd --permanent --add-port=2380/tcp
firewall-cmd --permanent --add-port=8472/udp
firewall-cmd --permanent --add-port=9099/tcp
firewall-cmd --permanent --add-port=10250/tcp
# 在 controlplane 节点上运行以下命令：
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --permanent --add-port=2376/tcp
firewall-cmd --permanent --add-port=6443/tcp
firewall-cmd --permanent --add-port=8472/udp
firewall-cmd --permanent --add-port=9099/tcp
firewall-cmd --permanent --add-port=10250/tcp
firewall-cmd --permanent --add-port=10254/tcp
firewall-cmd --permanent --add-port=30000-32767/tcp
firewall-cmd --permanent --add-port=30000-32767/udp
# 在 worker 节点上运行以下命令：
firewall-cmd --permanent --add-port=22/tcp
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --permanent --add-port=2376/tcp
firewall-cmd --permanent --add-port=8472/udp
firewall-cmd --permanent --add-port=9099/tcp
firewall-cmd --permanent --add-port=10250/tcp
firewall-cmd --permanent --add-port=10254/tcp
firewall-cmd --permanent --add-port=30000-32767/tcp
firewall-cmd --permanent --add-port=30000-32767/udp
```
在节点上运行 `firewall-cmd` 命令后，使用以下命令启用防火墙规则：
```
firewall-cmd --reload
```
**结果**：防火墙已更新，因此 Helm 可以与 Rancher Server 节点通信了。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/tune-etcd-for-large-installs.md
+40
View File
@@ -0,0 +1,40 @@
---
title: 为大型安装进行 etcd 调优
weight: 2
---
当你运行具有 15 个或更多集群的大型 Rancher 安装时，我们建议你扩大 etcd 的默认 keyspace（默认为 2GB）。你最大可以将它设置为 8GB。此外，请确保主机有足够的 RAM 来保存整个数据集。如果需要增加这个值，你还需要同步增加主机的大小。如果你预计在垃圾回收间隔期间 Pod 的变化率很高，你也可以在较小的安装中调整 Keyspace 大小。
Kubernetes 每隔五分钟会自动清理 etcd 数据集。在某些情况下（例如发生部署抖动），在垃圾回收发生并进行清理之前会有大量事件写入 etcd 并删除，从而导致 Keyspace 填满。如果你在 etcd 日志或 Kubernetes API Server 日志中看到 `mvcc: database space exceeded` 错误，你可以在 etcd 服务器上设置 [quota-backend-bytes](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota) 来增加 Keyspace 的大小。
### 示例：此 RKE cluster.yml 文件的代码片段将 Keyspace 的大小增加到 5GB
```yaml
# RKE cluster.yml
---
services:
etcd:
extra_args:
quota-backend-bytes: 5368709120
```
## 扩展 etcd 磁盘性能
你可以参见 [etcd 文档](https://etcd.io/docs/v3.4.0/tuning/#disk)中的建议，了解如何调整主机上的磁盘优先级。
此外，为了减少 etcd 磁盘上的 IO 争用，你可以为 data 和 wal 目录使用专用设备。etcd 最佳实践不建议配置 Mirror RAID（因为 etcd 在集群中的节点之间复制数据）。你可以使用 striping RAID 配置来增加可用的 IOPS。
要在 RKE 集群中实现此解决方案，你需要在底层主机上为 `/var/lib/etcd/data` 和 `/var/lib/etcd/wal` 目录挂载并格式化磁盘。`etcd` 服务的 `extra_args` 指令中必须包含 `wal_dir` 目录。如果不指定 `wal_dir`，etcd 进程会尝试在权限不足的情况下操作底层的 `wal` 挂载。
```yaml
# RKE cluster.yml
---
services:
etcd:
extra_args:
data-dir: '/var/lib/rancher/etcd/data/'
wal-dir: '/var/lib/rancher/etcd/wal/wal_dir'
extra_binds:
- '/var/lib/etcd/data:/var/lib/rancher/etcd/data'
- '/var/lib/etcd/wal:/var/lib/rancher/etcd/wal'
```
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/continuous-delivery.md
+14
View File
@@ -0,0 +1,14 @@
---
title: 持续交付
weight: 3
---
从 Rancher 2.5 开始，[Fleet](../../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) 已经预装在 Rancher 中，且从 Rancher 2.6 开始，Fleet 不能再完全禁用。但是，你可以使用 `continuous-delivery` 功能开关来禁用 GitOps 持续交付的 Fleet 功能。
如需启用或禁用此功能，请参见[启用实验功能主页](../../../../pages-for-subheaders/enable-experimental-features.md)中的说明。
| 环境变量键 | 默认值 | 描述 |
---|---|---
| `continuous-delivery` | `true` | 此开关禁用 Fleet 的 GitOps 持续交付功能。 |
如果你在 Rancher 2.5.x 中禁用了 Fleet，然后将 Rancher 升级到 v2.6.x，Fleet 将启用。只有 Fleet 的持续交付功能可以被禁用。当 `continuous-delivery` 被禁用时，`gitjob` deployment 不再部署到 Rancher Server 的本地集群中，且 `continuous-delivery` 不会在 Rancher UI 中显示。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/istio-traffic-management-features.md
+33
View File
@@ -0,0 +1,33 @@
---
title: UI 管理 Istio 虚拟服务和目标规则
weight: 2
---
此功能可启动一个 UI，用于管理 Istio 的流量，其中包括创建、读取、更新和删除虚拟服务（Virtual Service）和目标规则（Destination Rule）。
> **注意**：启用此功能并不会启用 Istio。集群管理员需要[为集群启用 Istio](../../../../pages-for-subheaders/istio-setup-guide.md) 才能使用该功能。
如需启用或禁用此功能，请参见[启用实验功能主页](../../../../pages-for-subheaders/enable-experimental-features.md)中的说明。
| 环境变量键 | 默认值 | 状态 | 可用于 |
---|---|---|---
| `istio-virtual-service-ui` | `false` | 实验功能 | v2.3.0 |
| `istio-virtual-service-ui` | `true` | GA | v2.3.2 |
## 功能介绍
Istio 流量管理功能的主要优势时允许动态请求路由，这对于金丝雀发布，蓝/绿发布或 A/B 测试都非常有用。
启用此功能后，一个页面会打开，让你通过 Rancher UI 配置 Istio 的某些流量管理功能。如果不使用此功能，你可以通过 `kubectl` 来使用 Istio 管理流量。
此功能会启用两个选项卡，一个用于**虚拟服务**，另一个用于**目标规则**。
- **虚拟服务**：拦截并将流量重定向到你的 Kubernetes Service 上。这样，你可以将部分请求流量定向到不同的服务上。你可以使用这些服务来定义一组路由规则，用于主机寻址。详情请参见 [Istio 官方文档](https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service/)。
- **目标规则**：作为唯一可信来源，表明哪些服务版本可用于接收虚拟服务的流量。你可以使用这些资源来定义策略，这些策略适用于路由发生后用于服务的流量。详情请参见 [Istio 官方文档](https://istio.io/docs/reference/config/networking/v1alpha3/destination-rule)。
如需查看选项卡：
1. 点击 **☰ > 集群管理**。
1. 转到安装了 Istio 的集群，然后单击 **Explore**。
1. 在左侧导航栏中，单击 **Istio**。
1. 你将看到 **Kiali** 和 **Jaeger** 的选项卡。在左侧导航栏中，你可查看和配置**虚拟服务**和**目标规则**。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/rancher-on-arm64.md
+45
View File
@@ -0,0 +1,45 @@
---
title: "在 ARM64 上运行 Rancher（实验性）"
weight: 3
---
:::caution
在使用 ARM64 架构的节点上运行 Rancher 目前还处在实验阶段，Rancher 尚未正式支持该功能。因此，我们不建议你在生产环境中使用 ARM64 架构的节点。
:::
如果你的节点使用 ARM64 架构，你可以使用以下选项：
- 在 ARM64 架构的节点上运行 Rancher
- 此选项仅适用于 Docker 安装。请知悉，以下安装命令取代了 [Docker 安装](../../../../../versioned_docs/version-2.0-2.4/pages-for-subheaders/rancher-on-a-single-node-with-docker.md)链接中的示例：
```
# 在最后一行 `rancher/rancher:vX.Y.Z` 中，请务必将 "X.Y.Z" 替换为包含 ARM64 版本的发布版本。例如，如果你的匹配版本是 v2.5.8，请在此行填写 `rancher/rancher:v2.5.8`。
docker run -d --restart=unless-stopped \
-p 80:80 -p 443:443 \
--privileged \
rancher/rancher:vX.Y.Z
```
:::note
要检查你的发行版本是否与 ARM64 架构兼容，你可以使用以下两种方式找到对应版本的发行说明：
- 访问 [Rancher 发行版本](https://github.com/rancher/rancher/releases)自行查询。
- 根据标签和版本号直接找到你的版本。例如，你使用的版本为 2.5.8，你可以访问 [Rancher 发行版本 - 2.5.8](https://github.com/rancher/rancher/releases/tag/v2.5.8)。
:::
- 创建自定义集群并添加使用 ARM64 架构的节点
- Kubernetes 集群必须为 1.12 或更高版本
- CNI 网络插件必须是 [Flannel](../../../../faq/container-network-interface-providers.md#flannel)
- 导入包含使用 ARM64 架构的节点的集群
- Kubernetes 集群必须为 1.12 或更高版本
如需了解如何配置集群选项，请参见[集群选项](cluster-provisioning/rke-clusters/options/)。
以下是未经测试的功能：
- Monitoring、告警、Notifiers、流水线和 Logging
- 通过应用商店发布应用
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/unsupported-storage-drivers.md
+40
View File
@@ -0,0 +1,40 @@
---
title: 使用非默认支持的存储驱动
weight: 1
---
此功能允许你使用不是默认启用的存储提供商和卷插件。
如需启用或禁用此功能，请参见[启用实验功能主页](../../../../pages-for-subheaders/enable-experimental-features.md)中的说明。
| 环境变量键 | 默认值 | 描述 |
---|---|---
| `unsupported-storage-drivers` | `false` | 启用非默认启用的存储提供商和卷插件。 |
### 默认启用的持久卷插件
下表描述了默认启用的存储类型对应的持久卷插件。启用此功能开关时，不在此列表中的任何持久卷插件均被视为实验功能，且不受支持：
| 名称 | 插件 |
--------|----------
| Amazon EBS Disk | `aws-ebs` |
| AzureFile | `azure-file` |
| AzureDisk | `azure-disk` |
| Google Persistent Disk | `gce-pd` |
| Longhorn | `flex-volume-longhorn` |
| VMware vSphere Volume | `vsphere-volume` |
| 本地 | `local` |
| 网络文件系统 | `nfs` |
| hostPath | `host-path` |
### 默认启用的 StorageClass
下表描述了默认启用的 StorageClass 对应的持久卷插件。启用此功能开关时，不在此列表中的任何持久卷插件均被视为实验功能，且不受支持：
| 名称 | 插件 |
--------|--------
| Amazon EBS Disk | `aws-ebs` |
| AzureFile | `azure-file` |
| AzureDisk | `azure-disk` |
| Google Persistent Disk | `gce-pd` |
| Longhorn | `flex-volume-longhorn` |
| VMware vSphere Volume | `vsphere-volume` |
| 本地 | `local` |
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/air-gapped-upgrades.md
+91
View File
@@ -0,0 +1,91 @@
---
title: 在离线环境中渲染 Helm 模板
shortTitle: 离线升级
weight: 1
---
:::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 版本的已知问题。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md
+138
View File
@@ -0,0 +1,138 @@
---
title: 在 Azure Kubernetes Service 上安装 Rancher
shortTitle: AKS
weight: 3
---
本文介绍了如何在微软的 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 的版本更新到 v1.22 或更高版本，则 ingress-nginx 的版本也需要[更新](https://kubernetes.github.io/ingress-nginx/#faq-migration-to-apiversion-networkingk8siov1)。
:::
```
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 地址的限制在每个订阅的区域级别生效。
以下命令安装了带有 Kubernetes 负载均衡器服务的 `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
```
## 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 安装命令。
**_v2.6.7 新功能_**
在此设置之上安装 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)了解你的证书选项。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md
+176
View File
@@ -0,0 +1,176 @@
---
title: 在 Amazon EKS 上安装 Rancher
shortTitle: Amazon EKS
weight: 3
---
本文介绍了在 EKS 上安装 Rancher 的两种方法。
第一种方法是使用 CloudFormation 在 EKS 集群上部署 Rancher Server。该方法的指南是与 Amazon Web Services 合作创建的，旨在展示如何按照最佳实践部署 Rancher。
第二种方法是使用命令行工具安装带有 Ingress 的 EKS 集群。如果你想在 EKS 上使用 Rancher 时使用较少的资源，请使用此方法。
如果你已经有一个 EKS Kubernetes 集群，请直接跳转到[安装 Ingress](#5-安装-ingress)这个步骤。然后按照[此处](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
## 使用 AWS 最佳实践的快速入门
Rancher 和 Amazon Web Services 合作编写了一份快速入门指南，用于按照 AWS 的最佳实践，在 EKS 集群上部署 Rancher。详情请参见[部署指南](https://aws-quickstart.github.io/quickstart-eks-rancher/)。
快速入门指南提供了在 EKS 上部署 Rancher 的三个选项：
- **将 Rancher 部署到新的 VPC 和新的 Amazon EKS 集群中**：该选项构建了一个由 VPC、子网、NAT 网关、安全组、堡垒主机、Amazon EKS 集群和其他基础设施组件组成的全新 AWS 环境。然后将 Rancher 部署到这个新的 EKS 集群中。
- **将 Rancher 部署到现有 VPC 和新的 Amazon EKS 集群中**：此选项在现有 AWS 基础架构中配置 Rancher。
- **将 Rancher 部署到现有的 VPC 和现有的 Amazon EKS 集群中**。此选项在现有 AWS 基础架构中配置 Rancher。
使用默认参数为新的 Virtual Private Cloud（VPC）和新的 Amazon EKS 集群按照此快速入门部署，会在 AWS Cloud 中构建以下 Rancher 环境：
- 跨越三个可用区的高可用架构。\*
- 根据 AWS 最佳实践，配置有公共和私有子网的 VPC，为你提供 AWS 上你自己的虚拟网络。\*
- 在公共子网中：
- 管理网络地址转换（NAT）网关，以允许资源的出站互联网访问。\*
- 自动扩缩组中的 Linux 堡垒主机，允许对公共和私有子网中的 Amazon Elastic Compute Cloud (Amazon EC2) 实例进行入站安全 Shell (SSH) 访问。\*
- 私有子网中：
- 自动扩缩组中的 Kubernetes 节点。\*
- 网络负载均衡器（未显示），用于访问 Rancher 控制台。
- 使用 AWS Systems Manager 自动化进行 Rancher 部署。
- 用于 EKS 集群的 Amazon EKS 服务，它提供了 Kubernetes controlplane。\*
- 用于访问 Rancher 部署的 Amazon Route 53 DNS 记录。
\* 将快速启动部署到现有 Amazon EKS 集群中的 CloudForm 模板会跳过标有星号（\*）的组件，并提示你查看现有 VPC 配置。
## 为 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 的版本更新到 v1.22 或更高版本，则 ingress-nginx 的版本也需要[更新](https://kubernetes.github.io/ingress-nginx/#faq-migration-to-apiversion-networkingk8siov1)。
```
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。
以下命令安装了一个 `nginx-ingress-controller`和一个 LoadBalancer 服务。因此，NGINX 前面会有一个 ELB（Elastic Load Balancer）：
```
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
```
### 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 安装命令。
**_v2.6.7 新功能_**
在此设置之上安装 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)了解你的证书选项。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md
+198
View File
@@ -0,0 +1,198 @@
---
title: 在 GKE 集群上安装 Rancher
shortTitle: GKE
weight: 3
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
在本节中，你将学习如何使用 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 版本。
**注意**：如果 Kubernetes 的版本更新到 v1.22 或更高版本，则 ingress-nginx 的版本也需要[更新](https://kubernetes.github.io/ingress-nginx/#faq-migration-to-apiversion-networkingk8siov1)。
```
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 安装命令。
**_v2.6.7 新功能_**
在此设置之上安装 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)了解你的证书选项。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md
+116
View File
@@ -0,0 +1,116 @@
---
title: 回滚
weight: 3
---
## 回滚到 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。
:::
### 将 Rancher Deployment 规模扩展到 0
1. 在左上角，点击 **☰ > local**。
1. 在左侧主菜单中，点击**工作负载**。
1. 在**工作负载**下，点击 **Deployments**。
1. 点击上方下拉菜单以调整筛选条件。选择 **cattle-system** 作为筛选条件。
1. 找到 `rancher` deployment 的行，并点击**⋮ > 编辑配置**。
1. 将**副本数量**改为 0。
1. 滚动到底部并点击**保存**。
### 创建 Restore 自定义资源
1. 点击 **☰ > 集群管理**。
1. 找到你的本地集群，并点击 **Explore**。
1. 在左侧导航栏中，点击 **Rancher 备份 > 还原**。
:::note
如果 Rancher Backups 应用不可见，你需要到**应用 & 应用市场**的 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 的情况。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/troubleshooting.md
+189
View File
@@ -0,0 +1,189 @@
---
title: Rancher Server Kubernetes 集群的问题排查
weight: 276
---
本文介绍如何对安装在 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-2/3) 进行排查。
### 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` 访问。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md
+181
View File
@@ -0,0 +1,181 @@
---
title: 升级
weight: 2
---
本文介绍如何升级使用 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 仓库](../../../reference-guides/installation-references/helm-chart-options.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)。
### 升级 Rancher Server 并使用隐藏的本地集群
如果你从使用 Helm Chart 选项 `--add-local=false` 启动的 Rancher Server 升级到 Rancher 2.5，你需要在升级时取消该标志。否则，Rancher Server 将无法启动。`restricted-admin` 角色可以继续用来限制对本地集群的访问。详情请参见[本章节](../../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#在-rancher-中使用隐藏的-local-集群进行升级)。
### 使用 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](../../../reference-guides/installation-references/helm-chart-options.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-stable https://releases.rancher.com/server-charts/stable
```
注意：不支持升级到 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=v2.4.11
```
### 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
这个命令会列出更多的值。此处展示的只是其中一个值的例子。
:::
如果要将 cert-manager 从 v1.5 或更早的版本升级到最新版本，请参阅 [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#选项-c：升级-1.5-及以下版本的-cert-manager) 了解如何在不卸载或重新安装 Rancher 的情况下升级 cert-manager。否则，请按照以下[ Rancher 升级步骤](#rancher-升级步骤)进行操作。
#### Rancher 升级步骤
保留你的所有设置把 Rancher 升级到最新版本。
将上一步中的所有值用 `--set key=value`追加到命令中。
```
helm upgrade rancher rancher-<CHART_REPO>/rancher \
--namespace cattle-system \
--set hostname=rancher.my.org
```
:::note
以上是一个例子，可能有更多上一步的值需要追加。
:::
另外，你也可以将当前的值导出到一个文件中，并在升级时引用该文件。例如，如果你只需要改变 Rancher 的版本：
```
helm get values rancher -n cattle-system -o yaml > values.yaml
helm upgrade rancher rancher-<CHART_REPO>/rancher \
--namespace cattle-system \
-f values.yaml \
--version=2.4.5
```
### 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 版本的已知问题。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/installation-requirements/dockershim.md
+46
View File
@@ -0,0 +1,46 @@
---
title: Dockershim
weight: 300
---
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。
要在 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/>
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/installation-requirements/install-docker.md
+18
View File
@@ -0,0 +1,18 @@
---
title: 安装 Docker
weight: 1
---
在使用 Helm 或 Docker 在节点上安装 Rancher Server 前，你需要先安装 Docker。
Docker 有几个安装方法。一种方法是参见 [Docker 官方文档](https://docs.docker.com/install/)以了解如何在 Linux 上安装 Docker。不同 Linux 发行版的安装步骤可能有所不同。
另一种方式是使用 Rancher 的 Docker 安装脚本，该脚本可用于较新的 Docker 版本。
例如，你可执行以下命令，在 Ubuntu 上安装 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)。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/installation-requirements/port-requirements.md
+339
View File
@@ -0,0 +1,339 @@
---
title: 端口要求
description: 了解 Rancher 正常运行所需的端口要求，包括 Rancher 节点和下游 Kubernetes 集群节点
weight: 300
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
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 | `35.160.43.145`，`35.167.242.46`，`52.33.59.17` | Rancher catalog（git.rancher.io） |
| 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 Agent 节点 | Kubernetes API |
| 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 | 5473 | Calico-node pod 连接到 typha pod | 使用 Calico 部署时需要 |
| HTTP | 8080 | 执行外部 SSL 终止的负载均衡器/代理 | 使用外部 SSL 终止时的 Rancher UI/API |
| HTTPS | 8443 | <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
如果你对安全性的关注不是太高，而且也愿意多打开几个端口，你可以参考[常用端口](#常用端口)中列出的端口，而不是参考下方的表格。
:::
### 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/kubernetes-clusters-in-rancher-setup/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.opensuse.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>
**结果** ：该节点已打开添加到自定义集群所需的端口。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/docker-install-commands.md
+150
View File
@@ -0,0 +1,150 @@
---
title: Docker 安装命令
weight: 1
---
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 版本](../../../../reference-guides/installation-references/helm-chart-options.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 版本](../../../../reference-guides/installation-references/helm-chart-options.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 版本](../../../../reference-guides/installation-references/helm-chart-options.md)的版本标签。 |
:::note
使用 `--no-cacerts` 作为容器的参数，以禁用 Rancher 生成的默认 CA 证书。
:::
特权访问是[必须](#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)。
:::
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/infrastructure-private-registry.md
+189
View File
@@ -0,0 +1,189 @@
---
title: '1. 设置基础设施和私有镜像仓库'
weight: 100
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
本文介绍如何在离线环境中，为 Rancher Management server 配置底层基础设施。你还将设置 Rancher 节点中必须可用的 Docker 私有仓库。
离线环境是 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 个私有 Docker 镜像仓库**：用于将 Docker 镜像分发到你的主机。
### 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 选项](../../../../reference-guides/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. 配置私有 Docker 镜像仓库
Rancher 支持使用私有镜像仓库进行离线安装。你必须有自己的私有镜像仓库或使用其他方式将 Docker 镜像分发到主机。
在后续设置 K3s Kubernetes 集群时，你需要创建一个[私有镜像仓库配置文件](https://rancher.com/docs/k3s/latest/en/installation/private-registry/)，其中包含此镜像仓库的信息。
如需获得创建私有镜像仓库的帮助，请参见 [Docker 官方文档](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)。
</TabItem>
<TabItem value="RKE">
如需在高可用 RKE 集群中安装 Rancher Management Server，我们建议配置以下基础设施：
- **3 个 Linux 节点**：可以是你的云提供商（例如 Amazon EC2，GCE 或 vSphere）中的虚拟机。
- **1 个负载均衡器**：用于将前端流量转发到这三个节点中。
- **1 个 DNS 记录**：用于将 URL 映射到负载均衡器。此 DNS 记录将成为 Rancher Server 的 URL，下游集群需要可以访问到这个地址。
- **1 个私有 Docker 镜像仓库**：用于将 Docker 镜像分发到你的主机。
这些节点必须位于同一个区域或数据中心。但是你可以把这些服务器放在不同的可用区。
### 为什么使用三个节点？
在 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 选项](../../../../reference-guides/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. 配置私有 Docker 镜像仓库
Rancher 支持使用安全的 Docker 私有镜像仓库进行离线安装。你必须有自己的私有镜像仓库或使用其他方式将 Docker 镜像分发到主机。
在后续设置 RKE Kubernetes 集群时，你需要创建一个[私有镜像仓库配置文件](https://rancher.com/docs/rke/latest/en/config-options/private-registries/)，其中包含此镜像仓库的信息。
如需获得创建私有镜像仓库的帮助，请参见 [Docker 官方文档](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)。
</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 节点
此主机会断开互联网链接，但需要能与你的私有镜像仓库连接。
请确保你的节点满足[操作系统，Docker，硬件和网络](../../../../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 私有镜像仓库在堡垒服务器中进行离线安装。你必须有自己的私有镜像仓库或使用其他方式将 Docker 镜像分发到主机。
如需获得创建私有镜像仓库的帮助，请参见 [Docker 官方文档](https://docs.docker.com/registry/)。
</TabItem>
</Tabs>
### 后续操作
[收集镜像并发布到你的私有镜像仓库](publish-images.md)
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes.md
+386
View File
@@ -0,0 +1,386 @@
---
title: '3. 安装 Kubernetes（Docker 安装请跳过）'
weight: 300
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
:::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 版本，请参见[支持维护条款](https://rancher.com/support-maintenance-terms/)。
如需指定 K3s 版本，在运行 K3s 安装脚本时，使用 `INSTALL_K3S_VERSION` 环境变量。
从 [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.sh
```
在每个 Agent 上安装 K3s：
```
INSTALL_K3S_SKIP_DOWNLOAD=true K3S_URL=https://myserver:6443 K3S_TOKEN=mynodetoken ./install.sh
```
请确保你将 `myserver` 替换为 Server 的 IP 或有效 DNS，并将 `mynodetoken` 替换为 Server 节点上的 node-token。
node-token 位于 Server 节点上的 `/var/lib/rancher/k3s/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。
### 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)
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md
+264
View File
@@ -0,0 +1,264 @@
---
title: 4. 安装 Rancher
weight: 400
---
本文介绍如何在高可用 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 版本](../../../../reference-guides/installation-references/helm-chart-options.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-stable https://releases.rancher.com/server-charts/stable
```
注意：不支持升级到 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 终止](../../../../reference-guides/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. 渲染 Rancher Helm 模板
根据你在[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：
:::note
v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为 v 1.6.x 将在 2022 年 3 月 30 日结束生命周期。
:::
```plain
helm fetch jetstack/cert-manager --version v1.7.1
```
##### 3. 渲染 cert-manager 模板
使用你想用来安装 Chart 的选项来渲染 cert-manager 模板。记住要设置 `image.repository` 选项，以从你的私有镜像仓库拉取镜像。此操作会创建一个包含 Kubernetes manifest 文件的 `cert-manager` 目录。
```plain
helm template cert-manager ./cert-manager-v1.7.1.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 \
--set startupapicheck.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-ctl
```
##### 4. 下载 cert-manager CRD
为 cert-manager 下载所需的 CRD 文件：
```plain
curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
```
##### 5. 渲染 Rancher 模板
渲染 Rancher 模板来声明你的选项。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库，以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。
| 占位符 | 描述 |
------------|-------------
| `<VERSION>` | 输出压缩包的版本号。 |
| `<RANCHER.YOURDOMAIN.COM>` | 指向负载均衡器的 DNS 名称。 |
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 你的私有镜像仓库的 DNS 名称。 |
| `<CERTMANAGER_VERSION>` | 在 K8s 集群上运行的 cert-manager 版本。 |
```plain
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
--no-hooks \ # 避免生成 Helm 钩子文件
--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 工具。
| 占位符 | 描述 |
| -------------------------------- | ----------------------------------------------- |
| `<VERSION>` | 输出压缩包的版本号。 |
| `<RANCHER.YOURDOMAIN.COM>` | 指向负载均衡器的 DNS 名称。 |
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 你的私有镜像仓库的 DNS 名称。 |
```plain
helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
--no-hooks \ # 避免生成 Helm 钩子文件
--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 template rancher ./rancher-<VERSION>.tgz --output-dir . \
--no-hooks \ # 避免生成 Helm 钩子文件
--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
```
**可选**：如需安装特定的 Rancher 版本，设置`rancherImageTag` 的值，例如：`--set rancherImageTag=v2.3.6`
然后，参见[添加 TLS 密文](../../resources/add-tls-secrets.md)发布证书文件，以便 Rancher 和 Ingress Controller 可以使用它们。
### 4. 安装 Rancher
将渲染的 manifest 目录复制到可以访问 Rancher Server 集群的系统中，以完成安装。
使用 `kubectl` 来创建命名空间和应用渲染的 manifest。
如果你使用自签名证书（在[选项B. 选择 SSL 配置](#b-选择-ssl-配置)中），安装 cert-manager。
#### 自签名证书安装 - 安装 Cert-manager
<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
```
:::note
如果你运行的 Kubernetes 版本是 1.15 或更低版本，你需要在以上的 `kubectl apply` 命令中添加 `--validate=false`，否则你将看到 cert-manager CRD 资源中的 `x-kubernetes-preserve-unknown-fields` 字段校验错误提示。这是 kubectl 执行资源校验方式产生的良性错误。
:::
3. 启动 cert-manager.
```plain
kubectl apply -R -f ./cert-manager
```
</details>
#### 使用 kubectl 安装 Rancher
```plain
kubectl create namespace cattle-system
kubectl -n cattle-system apply -R -f ./rancher
```
安装已完成。
:::caution
如果你不想发送遥测数据，在首次登录时退出[遥测](../../../../faq/telemetry.md)。如果在离线安装的环境中让这个功能处于 active 状态，socket 可能无法打开。
:::
## 其他资源
以下资源可能对安装 Rancher 有帮助：
- [Rancher Helm Chart 选项](../../../../reference-guides/installation-references/helm-chart-options.md)
- [添加 TLS 密文](../../resources/add-tls-secrets.md)
- [Rancher Kubernetes 安装的故障排除](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images.md
+316
View File
@@ -0,0 +1,316 @@
---
title: '2. 收集镜像并发布到私有仓库'
weight: 200
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
本文介绍如何配置私有镜像仓库，以便在安装 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` 文件中。
:::note
v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为 v 1.6.x 将在 2022 年 3 月 30 日结束生命周期。
:::
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.7.1
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 v0.12.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)
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md
+175
View File
@@ -0,0 +1,175 @@
---
title: '2. 安装 Kubernetes'
weight: 200
---
基础设施配置好后，你可以设置一个 RKE 集群来安装 Rancher。
首先，你需要在所有三个 Linux 节点上安装 Docker 并设置 HTTP 代理。因此，你可以在这三个节点上执行以下步骤。
为方便起见，将代理的 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
```
接下来配置 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
```
#### 离线代理
_v2.6.4 的新功能_
你现在可以在配置的离线集群中配置主机驱动集群，以使用代理进行出站连接。
除了为代理服务器设置默认规则外，你还需要额外添加如下所示的规则，以从代理的 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
```
* [helm](https://helm.sh/docs/intro/install/)
```
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
```
接下来，创建一个描述 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 集群配置文件的方式。
:::
### 故障排除
参见[故障排除](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)页面。
### 后续操作
[安装 Rancher](install-rancher.md)
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-rancher.md
+101
View File
@@ -0,0 +1,101 @@
---
title: 3. 安装 Rancher
weight: 300
---
在前文的操作后，你已经有了一个运行的 RKE 集群，现在可以在其中安装 Rancher 了。出于安全考虑，所有到 Rancher 的流量都必须使用 TLS 加密。在本教程中，你将使用 [cert-manager](https://cert-manager.io/)自动颁发自签名证书。在实际使用情况下，你可使用 Let's Encrypt 或自己的证书。
:::note
这些安装指南假定你使用的是 Helm 3。
:::
### 安装 cert-manager
添加 cert-manager Helm 仓库：
```
helm repo add jetstack https://charts.jetstack.io
```
为 cert-manager 创建命名空间：
```
kubectl create namespace cert-manager
```
安装 cert-manager 的 CustomResourceDefinitions：
:::note
v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为 v 1.6.x 将在 2022 年 3 月 30 日结束生命周期。
:::
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
```
使用 Helm 安装 cert-manager。请注意，cert-manager 还需要你配置代理，以防它需要与 Let's Encrypt 或其他外部证书颁发商进行通信：
```
helm upgrade --install cert-manager jetstack/cert-manager \
--namespace cert-manager --version v1.7.1 \
--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 选项](../../../../reference-guides/installation-references/helm-chart-options.md)
- [添加 TLS 密文](../../resources/add-tls-secrets.md)
- [Rancher Kubernetes 安装的故障排除](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md)
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/set-up-infrastructure.md
+65
View File
@@ -0,0 +1,65 @@
---
title: '1. 配置基础设施'
weight: 100
---
在本节中，你将为 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 选项](../../../../reference-guides/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)
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md
+90
View File
@@ -0,0 +1,90 @@
---
title: 证书故障排除
weight: 4
---
### 如何确定我的证书格式是否为 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)
```
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md
+92
View File
@@ -0,0 +1,92 @@
---
title: 回滚 Docker 安装的 Rancher
weight: 1015
---
如果 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 回滚到升级前的版本和数据状态。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md
+397
View File
@@ -0,0 +1,397 @@
---
title: 升级 Docker 安装的 Rancher
weight: 1010
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
本文介绍如何升级通过 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 仓库](../../../../reference-guides/installation-references/helm-chart-options.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 版本](../../../../reference-guides/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 版本](../../../../reference-guides/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 版本](../../../../reference-guides/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 版本](../../../../reference-guides/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 版本](../../../../reference-guides/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 版本](../../../../reference-guides/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 版本](../../../../reference-guides/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 版本](../../../../reference-guides/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)。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/resources/add-tls-secrets.md
+46
View File
@@ -0,0 +1,46 @@
---
title: 添加 TLS 密文
weight: 2
---
我们使用证书和密钥将 `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 的连接。
将 CA 证书拷贝到名为 `cacerts.pem` 的文件中，然后使用 `kubectl` 在 `cattle-system` 命名空间中创建 `tls-ca` 密文。
```
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，或从默认自签名证书切换到自定义证书。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/resources/bootstrap-password.md
+28
View File
@@ -0,0 +1,28 @@
---
title: 引导密码
weight: 800
---
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:"
```
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md
+122
View File
@@ -0,0 +1,122 @@
---
title: 选择 Rancher 版本
weight: 1
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
本节介绍如何选择 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-stable https://releases.rancher.com/server-charts/stable
```
注意：不支持升级到 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>
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/resources/custom-ca-root-certificates.md
+25
View File
@@ -0,0 +1,25 @@
---
title: 自定义 CA 根证书
weight: 1
---
如果你在内部生产环境使用 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 选项](../../../reference-guides/installation-references/helm-chart-options.md#额外的授信-ca)
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/resources/helm-version-requirements.md
+13
View File
@@ -0,0 +1,13 @@
---
title: Helm 版本要求
weight: 3
---
本文介绍 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` 的兼容问题。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/resources/local-system-charts.md
+15
View File
@@ -0,0 +1,15 @@
---
title: 离线安装中设置本地 System Charts
weight: 120
---
[System Charts](https://github.com/rancher/system-charts) 仓库包含 Monitoring、Logging、告警和全局 DNS 等功能所需的所有应用项。
在 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)中。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/resources/update-rancher-certificate.md
+264
View File
@@ -0,0 +1,264 @@
---
title: 更新 Rancher 证书
weight: 10
---
# 更新私有 CA 证书
本文介绍如何更新 Rancher [高可用 Kubernetes 安装](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md) 中 Ingress 的 SSL 证书，以及如何从默认的自签名证书切换到自定义证书。
步骤概述：
1. 使用新证书和私钥创建或更新 `tls-rancher-ingress` Kubernetes 密文资源。
2. 使用根 CA 证书创建或更新 `tls-ca` Kubernetes 密文资源（仅在使用私有 CA 时需要）。
3. 使用 Helm CLI 更新 Rancher 安装。
4. 重新配置 Rancher Agent 以信任新的 CA 证书。
5. 选择 Fleet 集群的强制更新，来将 fleet-agent 连接到 Rancher。
各个步骤的详细说明如下。
## 1. 创建/更新证书密文资源
首先，将服务器证书和所有中间证书合并到名为 `tls.crt` 的文件，并在名为 `tls.key` 的文件中提供相应的证书密钥。
如果你想切换 Rancher 自签名证书或 Let's Encrypt 证书，请运行以下命令，在 Rancher 高可用集群中创建 `tls-rancher-ingress` 密文资源：
```
$ kubectl -n cattle-system create secret tls tls-rancher-ingress \
--cert=tls.crt \
--key=tls.key
```
你也可以运行以下命令，更新现有的证书密文：
```
$ 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 密文资源
如果新证书由私有 CA 签发的，你需要将相应的根 CA 证书复制到名为 `cacerts.pem` 的文件中，并创建或更新 `cattle-system` 命名空间中的 `tls-ca` 密文。如果证书由中间 CA 签名，则 `cacerts.pem` 必须按顺序同时包含中间 CA 证书和根 CA 证书。
创建初始密文：
```
$ kubectl -n cattle-system create secret generic tls-ca \
--from-file=cacerts.pem
```
要更新现有的 `tls-ca` 密文：
```
$ kubectl -n cattle-system create secret generic tls-ca \
--from-file=cacerts.pem \
--dry-run --save-config -o yaml | kubectl apply -f -
```
## 3. 重新配置 Rancher 部署
:::note
在继续之前，在 Rancher UI (<b>用户 > API & 密钥 </b>) 中生成一个 API Token，并保存持有者 Token（你在步骤 4 中可能需要）。
:::
只有在最初安装 Rancher 时使用了自签名证书 （`ingress.tls.source=rancher`）或 Let's Encrypt 证书（`ingress.tls.source=letsEncrypt`）时，你才需要执行此步骤。
这一步骤确保 Rancher Pod 和 Ingress 资源能够重新配置，来使用新的服务器和可选的 CA 证书。
要更新 Helm 部署，请使用初始安装时的选项（`--set`）。运行以下命令检查：
```
$ helm get values rancher -n cattle-system
```
获取当前部署的 Rancher Chart 的版本字符串：
```
$ helm ls -A
```
使用初始配置的值升级 Helm 应用实例，并指定 `ingress.tls.source=secret` 以及当前的 Chart 版本来防止应用升级。
如果证书是由私有 CA 签发的，你需要添加 `set privateCA=true` 参数。请确保你已经阅读了使用自定义证书进行初始安装的文档。
```
helm upgrade rancher rancher-stable/rancher \
--namespace cattle-system \
--version <DEPLOYED_CHART_VERSION> \
--set hostname=rancher.my.org \
--set ingress.tls.source=secret \
--set ...
```
升级完成后，访问 `https://<Rancher_SERVER>/v3/settings/cacerts`，验证该值是否与先前写入 `tls-ca` 密文中的 CA 证书匹配。
## 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 容器中。代理会对下载证书的校验和及 `CATTLE_CA_CHECKSUM` 环境变量进行比较。如果私有 CA 证书在 Rancher Server 端更改了，环境变量 `CATTLE_CA_CHECKSUM` 必须相应进行更新。
### 可使用的方法
- 方法 1（最简单的方法）：
在轮换证书后将所有集群连接到 Rancher。适用于更新 Rancher 部署（步骤 3）后立即执行的情况。
- 方法 2：适用于集群失去了与 Rancher 的连接，但是你已启动了[授权集群端点（ACE）](https://rancher.com/docs/rancher/v2.6/en/cluster-admin/cluster-access/ace/)的情况。
- 方法 3：方法 1 和方法 2 不可用的情况下可使用。
### 方法 1：Kubectl 命令
对于**集群管理**中的每个集群（除去 `local` Rancher 管理集群），使用 Rancher 管理集群（RKE 或 K3S）的 `Kubeconfig` 文件运行以下命令：
```
kubectl patch clusters.management.cattle.io <REPLACE_WITH_CLUSTERID> -p '{"status":{"agentImage":"dummy"}}' --type merge
```
这个命令能使所有 Agent Kubernetes 资源使用新证书的校验和重新配置。
### 方法 2：手动更新校验和
通过将 `CATTLE_CA_CHECKSUM` 环境变量更新为匹配新 CA 证书校验和的值，来手动为 Agent Kubernetes 资源打上补丁。通过以下操作生成新的校验和：
```
$ curl -k -s -fL <RANCHER_SERVER>/v3/settings/cacerts | jq -r .value > cacert.tmp
$ sha256sum cacert.tmp | awk '{print $1}'
```
为每个下游集群使用 Kubeconfig 更新两个 Agent 部署的环境变量：
```
$ kubectl edit -n cattle-system ds/cattle-node-agent
$ kubectl edit -n cattle-system deployment/cattle-cluster-agent
```
### 方法 3：重新创建 Rancher Agent
你可以在每个下游集群的 controlplane 节点上运行一组命令，来重新创建 Rancher Agent。
首先，生成 Agent 定义（参见[此处](https://gist.github.com/superseb/076f20146e012f1d4e289f5bd1bd4971)）。
然后，SSH 连接到下游集群的 controlplane 节点，创建 Kubeconfig 并应用定义（参见[此处](
https://gist.github.com/superseb/b14ed3b5535f621ad3d2aa6a4cd6443b)）。
## 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 存储 kubeconfig，该配置用于连接到 Fleet 系统命名空间的 fleet-agent 密文中的 Rancher 代理 kube-api。kubeconfig 包括一个包含 Rancher CA 的证书授权数据块。更改 Rancher CA 时，需要更新此块来使 fleet-agent 成功连接到 Rancher。
# 将私有 CA 证书更改为通用证书
:::note
你可以执行与上文描述相反的操作，即将私有证书更改为通用或非私有证书。所涉及的步骤概述如下。
:::
## 1. 创建/更新证书密文资源
首先，将服务器证书和所有中间证书合并到名为 `tls.crt` 的文件，并在名为 `tls.key` 的文件中提供相应的证书密钥。
如果你想切换 Rancher 自签名证书或 Let's Encrypt 证书，请运行以下命令，在 Rancher 高可用集群中创建 `tls-rancher-ingress` 密文资源：
```
$ kubectl -n cattle-system create secret tls tls-rancher-ingress \
--cert=tls.crt \
--key=tls.key
```
你也可以运行以下命令，更新现有的证书密文：
```
$ 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 证书密文资源
你需要删除 `cattle-system` 命名空间中的 `tls-ca secret`（不再需要它）。如果需要，你还可以选择保存 `tls-ca secret` 的副本。
要保存现有密文：
```
kubectl -n cattle-system get secret tls-ca -o yaml > tls-ca.yaml
```
要删除现有的 `tls-ca` 密文：
```
kubectl -n cattle-system delete secret tls-ca
```
## 3. 重新配置 Rancher 部署
:::note 重要提示：
在继续之前，先[在 Rancher UI 中生成 API 令牌](../../../reference-guides/user-settings/api-keys.md#创建-api-密钥)（在 <b>User > API & Keys</b> 中）。
:::
只有在最初安装 Rancher 时使用了自签名证书 （`ingress.tls.source=rancher`）或 Let's Encrypt 证书（`ingress.tls.source=letsEncrypt`）时，你才需要执行此步骤。
这一步骤确保 Rancher Pod 和 Ingress 资源能够重新配置，来使用新的服务器和可选的 CA 证书。
要更新 Helm 部署，请使用初始安装时的选项（`--set`）。运行以下命令检查：
```
$ helm get values rancher -n cattle-system
```
获取当前部署的 Rancher Chart 的版本字符串：
```
$ helm ls -A
```
使用初始配置的值升级 Helm 应用程序实例，并指定当前的 Chart 版本以防止应用程序升级。
请确保你已经阅读了使用自定义证书进行初始安装的文档。
```
helm upgrade rancher rancher-stable/rancher \
--namespace cattle-system \
--version <DEPLOYED_CHART_VERSION> \
--set hostname=rancher.my.org \
--set ...
```
升级时，你可以执行以下其中一个操作：
- 从 Helm 升级命令中删除 `--set ingress.tls.source=secret \`，如上所示。
- 删除 `privateCA` 参数或将其设置为 `false` （因为 CA 有效）：
```
set privateCA=false
```
## 4. 为非私有/通用证书重新配置 Rancher Agent
下游集群 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 存储 kubeconfig，该配置用于连接到 Fleet 系统命名空间的 fleet-agent 密文中的 Rancher 代理 kube-api。kubeconfig 包括一个包含 Rancher CA 的证书授权数据块。更改 Rancher CA 时，需要更新此块来使 fleet-agent 成功连接到 Rancher。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/resources/upgrade-cert-manager.md
+283
View File
@@ -0,0 +1,283 @@
---
title: 升级 Cert-Manager
weight: 4
---
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：升级-1.5-及以下版本的-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 v0.12.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 v0.12.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/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 变更和数据迁移
---
_v2.6.4 的新功能_
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/)。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md
+126
View File
@@ -0,0 +1,126 @@
---
title: 升级和回滚 Kubernetes
weight: 70
---
升级到最新版本的 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 启动的 RKE 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#注册-k3s-集群的其他功能)。
- 在升级 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/advanced-user-guides/manage-clusters/nodes-and-node-pools.md#激进和安全的清空选项)。
1. （可选）配置宽限期。宽限期是给每个 pod 进行清理的超时时间，能让 pod 有机会优雅地退出。Pod 可能需要完成任何未完成的请求、回滚事务或将状态保存到某些外部存储。如果该值为负数，将使用 pod 中指定的默认值。
1. （可选）配置超时，这是在清空放弃之前应该继续等待的时间。
1. 单击**保存**。
**结果**：集群更新为使用新的升级策略。
:::note
从 Rancher v2.4.0 开始出现了一个[已知问题](https://github.com/rancher/rancher/issues/25478)，即使 etcd 和 controlplane 正在被清空， Rancher UI 不会将它们的状态显示为已清空。
:::
### 在升级期间维护应用的可用性
_从 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 节点。它将继续评估不可用的节点集，以防其中一个节点变得可用。如果无法修复节点，则必须移除节点才能继续升级。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/upgrade-kubernetes-without-upgrading-rancher.md
+89
View File
@@ -0,0 +1,89 @@
---
title: 在不升级 Rancher 的情况下升级 Kubernetes
weight: 30
---
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/advanced-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 系统镜像并为镜像准备私有 Docker 镜像仓库。
1. 要把系统镜像下载到私有镜像仓库，请单击 Rancher UI 左下角的 Rancher Server 版本。
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。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/introduction/overview.md
+66
View File
@@ -0,0 +1,66 @@
---
title: 概述
weight: 1
---
Rancher 是一个为使用容器的公司打造的容器管理平台。Rancher 使得开发者可以随处运行 Kubernetes（Run Kubernetes Everywhere），满足 IT 需求规范，赋能 DevOps 团队。
# Run Kubernetes Everywhere
Kubernetes 已经成为容器编排标准。现在，大多数云和虚拟化提供商都提供容器编排服务。Rancher 用户可以选择使用 Rancher Kubernetes Engine（RKE）或云 Kubernetes 服务（例如 GKE、AKS 和 EKS）创建 Kubernetes 集群。还可以导入和管理使用任何 Kubernetes 发行版或安装程序创建的现有 Kubernetes 集群。
# 满足 IT 需求规范
Rancher 支持对其控制的所有 Kubernetes 集群进行集中认证、访问控制和监控。例如，你可以：
- 使用你的 Active Directory 凭证访问由云提供商（例如 GKE）托管的 Kubernetes 集群。
- 设置所有用户、组、项目、集群和云服务的权限控制策略和安全策略。
- 一站式查看 Kubernetes 集群的运行状况和容量。
# 赋能 DevOps 团队
Rancher 为 DevOps 工程师提供简单直接的用户界面，以管理其应用负载。用户不需要对 Kubernetes 有非常深入的了解，即可使用 Rancher。Rancher 应用商店包含一套实用的 DevOps 开发工具。Rancher 获得了多种云原生生态系统产品的认证，包括安全工具、监控系统、容器镜像仓库、存储和网络驱动等。
下图讲述了 Rancher 在 IT 管理团队和 DevOps 开发团队之间扮演的角色。DevOps 团队把他们的应用部署在他们选择的公有云或私有云上。IT 管理员负责查看并管理用户、集群、云服务的权限。
![平台](/img/platform.png)
# Rancher API Server 的功能
Rancher API Server 是基于嵌入式 Kubernetes API Server 和 etcd 数据库建立的，它提供了以下功能：
### 授权和基于角色的权限控制（RBAC）
- **用户管理**：Rancher API Server 除了管理本地用户，还[管理用户用来访问外部服务所需的认证信息](../../pages-for-subheaders/about-authentication.md)，如登录 Active Directory 和 GitHub 所需的账号密码。
- **授权**：Rancher API Server 可以管理[访问控制策略](../../pages-for-subheaders/manage-role-based-access-control-rbac.md)和[安全策略](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)。
### 使用 Kubernetes 的功能
- **配置 Kubernetes 集群**：Rancher API Server 可以在已有节点上[配置 Kubernetes](../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md)，或进行 [Kubernetes 版本升级](../installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)。
- **管理应用商店**：Rancher 支持使用 [Helm Chart 应用商店](../../pages-for-subheaders/helm-charts-in-rancher.md)实现轻松重复部署应用。
- **管理项目**：项目由集群中多个命名空间和访问控制策略组成，是 Rancher 中的一个概念，Kubernetes 中并没有这个概念。你可以使用项目实现以组为单位，管理多个命名空间，并进行 Kubernetes 相关操作。Rancher UI 提供用于[项目管理](../../pages-for-subheaders/manage-projects.md)和[项目内应用管理](../../pages-for-subheaders/kubernetes-resources-setup.md)的功能。
- **流水线**：[流水线](../../how-to-guides/advanced-user-guides/manage-projects/ci-cd-pipelines.md)可以帮助开发者快速高效地上线新软件。Rancher 支持给每个项目单独设置流水线。
- **Istio**：[Rancher 与 Istio 集成](../../pages-for-subheaders/istio.md)，使得管理员或集群所有者可以将 Istio 交给开发者，然后开发者使用 Istio 执行安全策略，排查问题，或为蓝绿部署，金丝雀部署，和 A/B 测试进行流量管理。
### 配置云基础设施
- **同步节点信息**：Rancher API Server 可以同步所有集群中全部[节点](../../how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md)的信息。
- **配置云基础设施**：如果你为 Rancher 配置了云提供商，Rancher 可以在云端动态配置[新节点](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)和[持久化存储](../../pages-for-subheaders/create-kubernetes-persistent-storage.md)。
### 查看集群信息
- **日志管理**：Rancher 可以与多种 Kubernetes 集群之外的主流日志管理工具集成。
- **监控**：你可以使用 Rancher，通过业界领先并开源的 Prometheus 来监控集群节点、Kubernetes 组件和软件部署的状态和进程。
- **告警**：为了保证集群和应用的正常运行，提高公司的生产效率，你需要随时了解集群和项目的计划内和非计划事件。
# 使用 Rancher 编辑下游集群
对于已有集群而言，可提供的选项和设置取决于你配置集群的方法。例如，只有[通过 RKE 启动](../../pages-for-subheaders/launch-kubernetes-with-rancher.md)的集群才有可编辑的**集群选项**。
使用 Rancher 创建集群后，集群管理员可以管理集群成员，开启 Pod 安全策略，管理节点池，以及进行[其他操作](../../pages-for-subheaders/cluster-configuration.md)。
下表总结了每一种类型的集群和对应的可编辑的选项和设置：
import ClusterCapabilitiesTable from '../../shared-files/_cluster-capabilities-table.md';
<ClusterCapabilitiesTable />
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/introduction/what-are-divio-docs.md
+100
View File
@@ -0,0 +1,100 @@
---
title: Divio 文档介绍
---
[Divio 文档系统](https://documentation.divio.com/)是一种软件文档范式，它以功能为基础，旨在为用户提供具体、简明而且目的明确的文档。一般来说，Divio 由四个类别组成，分别是教程、操作指南、参考指南和解释。
我们将文档划分为以下章节：
## 开始使用
**开始使用**章节能帮助你快速启动和运行 Rancher。
本章节旨在帮助用户部署 Rancher 和工作负载，并快速有效地安装或升级 Rancher。
请参阅[简介](../../pages-for-subheaders/introduction.md)、[快速入门指南](../../pages-for-subheaders/quick-start-guides.md)以及[安装和升级](../../pages-for-subheaders/installation-and-upgrade.md)部分了解更多信息。
## 操作指南
操作指南描述了用户完成某些任务的实际步骤。在 Rancher 中，我们将操作指南进一步细分为[新用户指南](#新用户指南)和[高级用户指南](#高级用户指南)。
### 新用户指南
新用户指南（也称为教程）描述了某些操作的实际步骤。这些文档是“学习导向”的，也就是说用户通过“操作”来学习。
新用户指南旨在引导初学者或 Rancher 的日常用户通过一系列步骤来学习如何进行某些操作。这些文档旨在帮助用户通过使用易于遵循、有意义且可重复的操作来了解如何完成任务。这些指南将帮助用户完成工作，并能立刻看到效果。
正常来说，普通 Rancher 用户的技术水平高于“初学者”，但是，我们的新用户指南为初学者以及经验丰富的 Rancher 用户提供相同的指导。我们结合使用了高级语言和技术语言来介绍各个主题，并指导用户完成 Rancher 用户需要了解的通用任务。
你可以在[此处](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/deploy-workloads.md)找到新用户指南的一个示例。
### 高级用户指南
高级用户指南是“问题导向”的文档，用户可以从中学习如何解决问题。高级用于指南与新用户指南的主要区别在于，高级用户指南面向更有经验或更高级的用户，这些用户对文档有更多的技术需求，而且已经了解 Rancher 及其功能。他们知道自己需要做什么，只是需要额外的指导来完成更复杂的任务。
应该注意的是，新用户指南和高级用户指南都没有提供详细的解释或讨论（这些文档不包括在本部分）。操作指南侧重于引导用户通过可重复、有效的步骤来学习新技能、掌握某些操作或解决某些问题。
你可以在[此处](../../how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/dynamically-provision-new-storage.md)找到高级用户指南的一个示例。
## 参考指南
参考指南是用户可以学习的产品或流程描述。参考指南是“信息导向”的，主要用于描述。
本章节的文档可能包含一些操作步骤，但是描述操作步骤不是本章节的主要目的。
使用参考指南的用户熟悉且了解如何使用 Rancher。当用户需要参考具体使用细节时，用户可以获取更详细的使用描述。
Rancher 参考指南示例：
1. [Rancher Manager 架构](../../pages-for-subheaders/rancher-manager-architecture.md)
2. [集群配置指南](../../pages-for-subheaders/cluster-configuration.md)
## 说明
说明文档主要用于为某个任务或主题背后的“原因”提供理论知识。说明文档是“理解导向”的，用于拓宽用户的知识。在本节中，用户可以找到有关主题的上下文和背景、替代方案和意见等，还可能找到历史原因、相关限制以及流程的工作原理。
说明文档不会像操作指南那样指导用户进行操作，也不会像参考文档那样给出详细的描述。说明文档用于提供简单和复杂主题的实质和背景。
由于我们以前的大多数文档都不是"以讨论为导向"的，因此我们的新文档会增加这一部分内容。目前，我们以[Rancher 中的集成](../../pages-for-subheaders/integrations-in-rancher.md)来讨论我们的集成产品。
### Rancher 中的集成
Rancher 已经积累了多个产品和项目，而且已将它们集成到 Rancher UI 中。为了帮助用户了解这些集成，我们已将此小节添加到**说明**下。
集成示例：[Harvester](../../explanations/integrations-in-rancher/harvester.md) 和 [NeuVector](../../explanations/integrations-in-rancher/neuvector.md)
## 其他文档类别
### 常见问题
[常见问题](../../faq.md)包含了用户常见的 Rancher v2.x 问题。这些问题可能是技术性的或非技术性的。
我们会不断补充和优化这一部分，你可以常来浏览更新的内容。
### 故障排除
[故障排除](../../troubleshooting.md)旨在帮助新老 Rancher 用户解决他们在使用 Rancher 时可能遇到的已知问题。
我们会不断补充和优化这一部分，你可以常来浏览更新的内容。
### 参与 Rancher 社区贡献
为了提高文档的质量，我们一直在更新、检查和改进 Rancher Manager 文档。同时，我们也呼吁社区用户参与贡献。
你可以查阅[参与 Rancher 社区贡献](../../contribute-to-rancher.md)章节，了解 Rancher 使用的仓库，以及学习如何构建仓库、提交 issue 或创建 PR。
我们会经常 review 用户的贡献，并将及时向贡献者提供反馈。
## 重叠类别
你可能会发现，各个文档类别（新用户指南、高级用户指南、参考资料）存在一些重叠。这是因为信息流是流动的，因此通常情况下，某些文档在逻辑上可能属于多个类别。虽然我们的文档有一些重叠，但如果我们记住每个类别的主要功能并努力区分它们，那么文档将更加清晰可用。
## 新结构目标
旧版 Rancher 文档侧重于单个功能和主题，而新的 Divio 范式则优先考虑功能和及其内在联系。
我们旧版的文档结构没有采用 Divio 范式（例如，并非每个文档都可以合理地放入用户指南或参考文献中）。某些文档可能包含多个文档功能的内容。
因此，我们一直在努力把现有的文档转移到基于文档功能的新结构。未来，我们将根据需要创建、重写和重塑我们的文档，使我们的文档更加符合 Divio 结构、目的及其设计概念。
最终，我们的文档将强调单个主题或功能，从而更加有效地帮助我们的用户。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace.md
+7
View File
@@ -0,0 +1,7 @@
---
title: Rancher AWS Marketplace 快速入门
description: 使用 Amazon EKS 部署 Rancher Server。
weight: 110
---
你可以在 AWS 中使用 Amazon EKS 部署 Rancher Server。详情请参见我们的 [Amazon Marketplace 列表](https://aws.amazon.com/marketplace/pp/prodview-2yzbnvagmi4as)。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/aws.md
+95
View File
@@ -0,0 +1,95 @@
---
title: Rancher AWS 快速入门指南
description: 阅读此分步 Rancher AWS 指南，以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
weight: 100
---
你可以参考以下步骤，在 AWS 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server，并附加一个单节点下游 Kubernetes 集群。
:::caution
本章节中提供的指南，旨在帮助你快速启动一个用于 Rancher 的沙盒，以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导，请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
:::
## 先决条件
:::caution
部署到 Amazon AWS 会产生费用。
:::
- [Amazon AWS 账号](https://aws.amazon.com/account/): 用于创建部署 Rancher Server 和 Kubernetes 的资源。
- [Amazon AWS 访问密钥](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html)：如果你没有的话，请访问此链接查看相关指南。
- [已创建 IAM 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start)：定义附加此策略的账号所具有的权限。
- [Terraform](https://www.terraform.io/downloads.html): 用于在 Amazon AWS 中配置服务器和集群。
### IAM 策略示例
AWS 模块只创建一个 EC2 密钥对、一个 EC2 安全组和一个 EC2 实例。以下是一个简单的策略：
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*"
}
]
}
```
## 开始使用
1. 使用命令行工具，执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
2. 执行 `cd quickstart/rancher/aws` 命令，进入包含 terraform 文件的 AWS 文件夹。
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `aws_access_key` - 替换为 Amazon AWS 访问密钥
- `aws_secret_key` - 替换为 Amazon AWS Secret 密钥
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
5. **可选**：修改 `terraform.tfvars` 中的可选参数。参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) 了解更多信息。
建议包括：
- `aws_region` - Amazon AWS 区域。AWS 的默认区域 (`us-east-1`) 不一定是距离你最近的区域。建议修改为距离你最近的区域。
- `prefix` - 所有创建资源的前缀
- `instance_type` - EC2 使用的实例规格，最小规格为 `t3a.medium` 。如果在预算范围内，可以使用 `t3a.large` 或 `t3a.xlarge`。
- `add_windows_node` - 如果设为 true，一个额外的 Windows worker 节点会添加到工作负载集群中。
6. 执行 `terraform init`。
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后，等待命令行工具返回以下信息：
```
Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
Outputs:
rancher_node_ip = xx.xx.xx.xx
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
workload_node_ip = yy.yy.yy.yy
```
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录（默认用户名为 `admin`，密码为在 `rancher_server_admin_password` 中设置的密码）。
9. 使用 `quickstart/rancher/aws` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
##### 结果
两个 Kubernetes 集群已部署到你的 AWS 账户中，一个运行 Rancher Server，另一个为实验部署做好准备。请注意，虽然这种设置是探索 Rancher 功能的好方法，但在生产环境中，应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的，存储在模块目录中。
## 后续操作
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
## 销毁环境
1. 进入 `quickstart/rancher/aws` 文件夹，然后执行 `terraform destroy --auto-approve`。
2. 等待命令行界面显示资源已删除的消息。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/azure.md
+82
View File
@@ -0,0 +1,82 @@
---
title: Rancher Azure 快速入门指南
description: 阅读此分步 Rancher Azure 指南，以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
weight: 115
---
你可以参考以下步骤，在 Azure 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server，并附加一个单节点下游 Kubernetes 集群。
:::caution
本章节中提供的指南，旨在帮助你快速启动一个用于 Rancher 的沙盒，以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导，请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
:::
## 先决条件
:::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 租户。
- [Microsoft Azure 客户端 ID/密文](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal)：访问此链接并参考教程以创建 Microsoft Azure 客户端和密文。
- [Terraform](https://www.terraform.io/downloads.html)：用于在 Microsoft Azure 中配置服务器和集群。
## 开始使用
1. 使用命令行工具，执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
2. 执行 `cd quickstart/rancher/azure` 命令，进入包含 terraform 文件的 Azure 文件夹。
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `azure_subscription_id` - 替换为 Microsoft Azure 订阅 ID。
- `azure_client_id` - 替换为 Microsoft Azure 客户端 ID。
- `azure_client_secret` - 替换为 Microsoft Azure 客户端密文。
- `azure_tenant_id` - 替换为 Microsoft Azure 租户 ID。
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) 了解更多信息。建议包括：
- `azure_location` - Microsoft Azure 区域。Azure 的默认区域 (`East US`) 不一定是距离你最近的区域。建议修改为距离你最近的区域。
- `prefix` - 所有创建资源的前缀
- `instance_type` - 使用的计算实例大小，最小规格为 `Standard_DS2_v2`。如果在预算范围内，可以使用 `Standard_DS2_v3` 或 `Standard_DS3_v2`。
- `add_windows_node` - 如果设为 true，一个额外的 Windows worker 节点会添加到工作负载集群中。
- `windows_admin_password` - Windows worker 节点管理员的密码
6. 执行 `terraform init`。
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后，等待命令行工具返回以下信息：
```
Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
Outputs:
rancher_node_ip = xx.xx.xx.xx
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
workload_node_ip = yy.yy.yy.yy
```
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录（默认用户名为 `admin`，密码为在 `rancher_server_admin_password` 中设置的密码）。
9. 使用 `quickstart/rancher/azure` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
#### 结果
两个 Kubernetes 集群已部署到你的 Azure 账户中，一个运行 Rancher Server，另一个为实验部署做好准备。请注意，虽然这种设置是探索 Rancher 功能的好方法，但在生产环境中，应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的，存储在模块目录中。
### 后续操作
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
## 销毁环境
1. 进入 `quickstart/rancher/azure` 文件夹，然后执行 `terraform destroy --auto-approve`。
2. 等待命令行界面显示资源已删除的消息。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/digitalocean.md
+74
View File
@@ -0,0 +1,74 @@
---
title: Rancher DigitalOcean 快速入门指南
description: 阅读此分步 Rancher DigitalOcean 指南，以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
weight: 120
---
你可以参考以下步骤，在 DigitalOcean 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server，并附加一个单节点下游 Kubernetes 集群。
:::caution
本章节中提供的指南，旨在帮助你快速启动一个用于 Rancher 的沙盒，以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导，请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
:::
## 先决条件
:::caution
部署到 DigitalOcean 会产生费用。
:::
- [DigitalOcean 账号](https://www.digitalocean.com)：用于运行服务器和集群。
- [DigitalOcean 访问密钥](https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key)：如果你没有的话，请访问此链接创建一个。
- [Terraform](https://www.terraform.io/downloads.html)：用于在 DigitalOcean 中配置服务器和集群。
## 开始使用
1. 使用命令行工具，执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
2. 执行 `cd quickstart/rancher/do` 命令，进入包含 terraform 文件的 DigitalOcean 文件夹。
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `do_token` - 替换为 DigitalOcean 访问密钥
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) 了解更多信息。建议包括：
- `do_region` - DigitalOcean 区域。DigitalOcean 的默认区域不一定是距离你最近的区域。建议修改为距离你最近的区域。
- `prefix` - 所有创建资源的前缀
- `droplet_size` - 使用的计算实例规格，最小规格为`s-2vcpu-4gb`。如果在预算范围内，可以使用 `s-4vcpu-8gb`。
6. 执行 `terraform init`。
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后，等待命令行工具返回以下信息：
```
Apply complete! Resources: 15 added, 0 changed, 0 destroyed.
Outputs:
rancher_node_ip = xx.xx.xx.xx
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
workload_node_ip = yy.yy.yy.yy
```
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录（默认用户名为 `admin`，密码为在 `rancher_server_admin_password` 中设置的密码）。
9. 使用 `quickstart/rancher/do` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
#### 结果
两个 Kubernetes 集群已部署到你的 DigitalOcean 账户中，一个运行 Rancher Server，另一个为实验部署做好准备。请注意，虽然这种设置是探索 Rancher 功能的好方法，但在生产环境中，应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的，存储在模块目录中。
### 后续操作
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
## 销毁环境
1. 进入 `quickstart/rancher/do` 文件夹，然后执行 `terraform destroy --auto-approve`。
2. 等待命令行界面显示资源已删除的消息。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/equinix-metal.md
+118
View File
@@ -0,0 +1,118 @@
---
title: Rancher Equinix Metal 快速入门
weight: 250
---
## 本章节引导你：
- 配置 Equinix Metal server
- 安装 Rancher 2.x
- 创建你的第一个集群
- 部署一个 Nginx 应用
:::caution
本章节中提供的指南，旨在帮助你快速启动一个用于 Rancher 的沙盒，以评估 Rancher 是否能满足你的使用需求。不建议将 Docker 安装用于生产环境。如果你需要获取生产环境的操作指导，请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
:::
## 快速入门概述
本指南划分为不同任务，以便于使用。
<br/>
## 先决条件
- [Equinix Metal 账号](https://metal.equinix.com/developers/docs/accounts/users/)
- [Equinix Metal 项目](https://metal.equinix.com/developers/docs/accounts/projects/)
### 1. 配置 Equinix Metal 主机
开始部署 Equinix Metal 主机。你可以使用 Equinix Metal 控制台，API 或 CLI 来配置 Equinix Metal Server。如果你需要了解如何部署每种类型的 deployment，请参见 [Equinix Metal 部署](https://metal.equinix.com/developers/docs/deploy/on-demand/)。以下链接介绍 Equinix Metal Server 的类型以及价格。
- [Equinix Metal Server 类型](https://metal.equinix.com/developers/docs/servers/about/)
- [Equinix Metal 价格](https://metal.equinix.com/developers/docs/servers/server-specs/)
:::note 注意事项：
- 如果使用 CLI 或 API 配置新的 Equinix Metal Server，你需要提供项目 ID、计划、metro 和操作系统。
- 当使用云主机的虚拟机时，你需要允许 80 和 443 端口的入站 TCP 通信。有关端口配置的信息，请参见你的云主机的文档。
- 如需了解所有端口要求，请参见 [Docker 安装](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)。
- 根据我们的[要求](../../../pages-for-subheaders/installation-requirements.md)配置主机。
:::
### 2. 安装 Rancher
要在 Equinix Metal 主机上安装 Rancher，先与它连接，然后使用 shell 进行安装。
1. 使用你惯用的 shell（例如 PuTTy 或远程终端）登录到你的 Equinix Metal 主机。
2. 在 shell 中执行以下命令：
```
sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher
```
**结果**：Rancher 已安装。
### 3. 登录
登录到 Rancher 后，你还需要进行一些一次性配置。
1. 打开 Web 浏览器并输入主机的 IP 地址`https://<SERVER_IP>`。
将 `<SERVER_IP>` 替换为你的主机 IP 地址。
2. 出现提示时，为默认 `admin` 账号创建密码。
3. 设置 **Rancher Server URL**。URL 可以是 IP 地址或主机名。需要注意，添加到集群中的每个节点都必须能够连接到此 URL。<br/><br/>如果你在 URL 中使用主机名，则此主机名必须在 DNS 中解析到你需要添加到集群的节点上。
<br/>
### 4. 创建集群
欢迎使用 Rancher！现在，你可以创建你的第一个 Kubernetes 集群了。
在此任务中，你可以使用**自定义**选项。此选项允许你把 _任意_ Linux 主机（云虚拟机、本地虚拟机或裸机）添加到集群中。
1. 点击 **☰ > 集群管理**。
1. 在**集群**页面，点击**创建**。
2. 选择**自定义**。
3. 输入**集群名称**。
4. 跳过**成员角色**和**集群选项**。此部分我们稍后会详细介绍。
5. 点击**下一步**。
6. 在**节点角色**中，选择 _全部_ 角色，即 **etcd**，**Control** 和 **Worker**。
7. **可选**：Rancher 会自动检测用于 Rancher 通信和集群通信的 IP 地址。你可以使用**节点地址**处的`公有地址`和`内网地址`进行覆盖。
8. 跳过**标签**部分的内容。这部分内容暂时不重要。
9. 将屏幕上显示的命令复制到剪贴板。
10. 使用你惯用的 shell（例如 PuTTy 或远程终端）登录到你的 Linux 主机。粘贴剪贴板的命令并运行。
11. 在 Linux 主机上运行完命令后，单击**完成**。
**结果**：
你已创建集群，集群的状态是**配置中**。Rancher 已在你的集群中。
当集群状态变为 **Active** 后，你可访问集群。
**Active** 状态的集群会分配到两个项目：
- `Default`：包含 `default` 命名空间
- `System`：包含 `cattle-system`，`ingress-nginx`，`kube-public` 和 `kube-system` 命名空间。
#### 已完成！
恭喜！你已创建第一个集群。
#### 后续操作
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/gcp.md
+77
View File
@@ -0,0 +1,77 @@
---
title: Rancher GCP 快速入门指南
description: 阅读此分步 Rancher GCP 指南，以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
weight: 130
---
你可以参考以下步骤，在 GCP 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server，并附加一个单节点下游 Kubernetes 集群。
:::caution
本章节中提供的指南，旨在帮助你快速启动一个用于 Rancher 的沙盒，以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导，请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
:::
## 先决条件
:::caution
部署到 Google GCP 会产生费用。
:::
- [Google GCP Account](https://console.cloud.google.com/)：用于创建部署 Rancher 和 Kubernetes 的资源。
- [Google GCP 项目](https://cloud.google.com/appengine/docs/standard/nodejs/building-app/creating-project)：如果你没有的话，请访问此链接查看如何创建 GCP 项目。
- [Google GCP ServiceAccount](https://cloud.google.com/iam/docs/creating-managing-service-account-keys)：请访问此链接查看如何创建 GCP ServiceAccount 和 Token 文件。
- [Terraform](https://www.terraform.io/downloads.html)：用于在 Google GCP 中配置服务器和集群。
## 开始使用
1. 使用命令行工具，执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
2. 执行 `cd quickstart/rancher/gcp` 命令，进入包含 terraform 文件的 GCP 文件夹。
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `gcp_account_json` - 替换为 GCP ServiceAccount 文件路径和文件名。
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp) 了解更多信息。
建议包括：
- `gcp_region` - Google GCP 区域。GCP 的默认区域 (`us-east4`) 不一定是距离你最近的区域。建议修改为距离你最近的区域。
- `gcp_zone` - Google GCP 区域。GCP 的默认区域 (`us-east4-a`) 不一定是距离你最近的区域。建议修改为距离你最近的区域。
- `prefix` - 所有创建资源的前缀
- `machine_type` - 使用的计算实例大小，最小规格为 `n1-standard-1`。如果在预算范围内，可以使用 `n1-standard-2` 或 `n1-standard-4`。
6. 执行 `terraform init`。
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后，等待命令行工具返回以下信息：
```
Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
Outputs:
rancher_node_ip = xx.xx.xx.xx
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
workload_node_ip = yy.yy.yy.yy
```
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录（默认用户名为 `admin`，密码为在 `rancher_server_admin_password` 中设置的密码）。
9. 使用 `quickstart/rancher/gcp` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
#### 结果
两个 Kubernetes 集群已部署到你的 GCP 账户中，一个运行 Rancher Server，另一个为实验部署做好准备。请注意，虽然这种设置是探索 Rancher 功能的好方法，但在生产环境中，应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的，存储在模块目录中。
### 后续操作
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
## 销毁环境
1. 进入 `quickstart/rancher/gcp` 文件夹，然后执行 `terraform destroy --auto-approve`。
2. 等待命令行界面显示资源已删除的消息。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md
+145
View File
@@ -0,0 +1,145 @@
---
title: Helm CLI 快速入门
weight: 300
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
本文提供了快速安装 Rancher 的方法。
这些说明假设你有一个 Linux 虚拟机，并能从本地工作站与之通信。Rancher 将安装在 Linux 主机上。你将需要检索该主机的 IP 地址，以便从本地工作站访问 Rancher。Rancher 旨在远程管理 Kubernetes 集群，因此 Rancher 管理的任何 Kubernetes 集群也都需要能够访问该 IP 地址。
我们不建议在本地安装 Rancher，因为它会产生网络问题。如果你在 localhost 上安装 Rancher，Rancher 无法与下游 Kubernetes 集群通信，因此在 localhost 上你无法测试 Rancher 的集群配置和集群管理功能。
你的 Linux 主机可以位于任何地方。例如，它可以是 Amazon EC2 实例、Digital Ocean Droplet 或 Azure 虚拟机。其他 Rancher 文档也经常称它们为“节点”。部署 Linux 主机的一种方法是设置一个 Amazon EC2 实例，如[本教程](../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md)中所示。
完整的安装要求在[这里](../../../pages-for-subheaders/installation-requirements.md)。
## 在 Linux 上安装 K3s
在 Linux 主机上运行以下命令来安装 K3s 集群：
```
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="***" sh -s - server --cluster-init
```
Rancher 需要安装在支持的 Kubernetes 版本上。如需指定 K3s 版本，在运行 K3s 安装脚本时，使用 `INSTALL_K3S_VERSION` 环境变量。请参阅[支持维护条款](https://rancher.com/support-maintenance-terms/)。
`--cluster-init` 允许 K3s 使用嵌入式 etcd 作为数据存储，并能够转换为 HA 设置。请参阅[嵌入式数据库的高可用性](https://rancher.com/docs/k3s/latest/en/installation/ha-embedded/)。
保存 Linux 主机的 IP。
## 将 kubeconfig 保存到你的工作站
kubeconfig 文件对于访问 Kubernetes 集群非常重要。从 Linux 主机复制 `/etc/rancher/k3s/k3s.yaml` 中的文件，并将其保存到本地工作站的 `~/.kube/config` 目录中。一种方法是使用 `scp` 工具并在本地计算机上运行此命令：
<Tabs>
<TabItem value="Mac 和 Linux">
```
scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml ~/.kube/config
```
</TabItem>
<TabItem value="Windows">
默认情况下不能识别“scp”命令，所以我们需要先安装一个模块。
在 Windows Powershell 中：
```
Find-Module Posh-SSH
Install-Module Posh-SSH
## 获取远程 kubeconfig 文件
scp root@<IP_OF_LINUX_MACHINE>:/etc/rancher/k3s/k3s.yaml $env:USERPROFILE\.kube\config
```
</TabItem>
</Tabs>
## 在 kubeconfig 中编辑 Rancher Server URL
在 kubeconfig 文件中，你需要将 `server` 字段的值更改为 `<IP_OF_LINUX_NODE>:6443`。你可以通过端口 6443 访问 Kubernetes API Server，通过端口 80 和 443 访问 Rancher Server。你需要进行此编辑，以便你从本地工作站运行 Helm 或 kubectl 命令时，能够与安装了 Rancher 的 Kubernetes 集群进行通信。
<Tabs>
<TabItem value="Mac 和 Linux">
打开 kubeconfig 文件进行编辑的一种方法是使用 Vim：
```
vi ~/.kube/config
```
输入 `i` 以打开 Vim 的插入模式。要保存你的工作，请按 `Esc`。然后输入 `:wq` 并按 `Enter`。
</TabItem>
<TabItem value="Windows">
在 Windows Powershell 中，你可以使用 `notepad.exe` 来编辑 kubeconfig 文件：
```
notepad.exe $env:USERPROFILE\.kube\config
```
编辑完成后，按 `ctrl+s` 或转到 `File > Save` 来保存你的工作。
</TabItem>
</Tabs>
## 使用 Helm 来安装 Rancher
从本地工作站运行以下命令。你需要先安装 [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) 和 [helm](https://helm.sh/docs/intro/install/)：
```
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
kubectl create namespace cattle-system
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--version v1.7.1
# Windows Powershell
helm install cert-manager jetstack/cert-manager `
--namespace cert-manager `
--create-namespace `
--version v1.7.1
```
安装 Rancher 的最终命令如下。该命令需要一个将流量转发到 Linux 主机的域名。为了简化本教程，你可以使用假域名。`<IP_OF_LINUX_NODE>.sslip.io` 是一个假域名的例子。
要安装特定的 Rancher 版本，请使用 `--version` 标志（例如，`--version 2.6.6`）。否则，默认安装最新的 Rancher。请参阅[选择 Rancher 版本](../../installation-and-upgrade/resources/choose-a-rancher-version.md)。
```
helm install rancher rancher-latest/rancher \
--namespace cattle-system \
--set hostname=<IP_OF_LINUX_NODE>.sslip.io \
--set replicas=1 \
--set bootstrapPassword=<PASSWORD_FOR_RANCHER_ADMIN>
# Windows Powershell
helm install rancher rancher-latest/rancher `
--namespace cattle-system `
--set hostname=<IP_OF_LINUX_NODE>.sslip.io `
--set replicas=1 `
--set bootstrapPassword=<PASSWORD_FOR_RANCHER_ADMIN>
```
现在，如果你在 Web 浏览器中导航到 `<IP_OF_LINUX_NODE>.sslip.io`，你应该会看到 Rancher UI。
为了简化说明，我们使用了一个假域名和自签名证书来进行安装。因此，你可能需要在 Web 浏览器中添加一个安全例外来查看 Rancher UI。请注意，对于生产安装，你需要具有负载均衡器、真实域名和真实证书的高可用性设置。
这些说明还省略了完整的安装要求和其他安装选项。如果你对这些步骤有任何疑问，请参阅完整的 [Helm CLI 安装文档](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md)。
要使用新的 Rancher Server 来启动新的 Kubernetes 集群，你可能需要在 Rancher 中设置云凭证。有关更多信息，请参阅[使用 Rancher 启动 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/hetzner-cloud.md
+76
View File
@@ -0,0 +1,76 @@
---
title: Rancher Hetzner Cloud 快速入门指南
description: 阅读此分步 Rancher Hetzner Cloud 指南，以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
weight: 140
---
你可以参考以下步骤，在 Hetzner Cloud 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server，并附加一个单节点下游 Kubernetes 集群。
:::caution
本章节中提供的指南，旨在帮助你快速启动一个用于 Rancher 的沙盒，以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导，请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
:::
## 先决条件
:::caution
部署到 Hetzner Cloud 会产生费用。
:::
- [Hetzner Cloud 账号](https://www.hetzner.com)：用于运行服务器和集群。
- [Hetzner API 访问密钥](https://docs.hetzner.cloud/#getting-started)：如果你没有的话，请参考说明创建一个。
- [Terraform](https://www.terraform.io/downloads.html)：用于在 Hetzner 中配置服务器和集群。
## 开始使用
1. 使用命令行工具，执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
2. 执行 `cd quickstart/rancher/hcloud` 命令，进入包含 terraform 文件的 Hetzner 文件夹。
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `hcloud_token` - 替换为 Hetzner API 访问密钥。
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Hetzner Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/hcloud) 了解更多信息。
建议包括：
- `prefix` - 所有创建资源的前缀
- `instance_type` - 实例类型，至少需要是 `cx21`。
- `hcloud_location`- Hetzner Cloud 位置。选择最近的位置，而不是使用默认位置（`fsn1`）。
6. 执行 `terraform init`。
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后，等待命令行工具返回以下信息：
```
Apply complete! Resources: 15 added, 0 changed, 0 destroyed.
Outputs:
rancher_node_ip = xx.xx.xx.xx
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
workload_node_ip = yy.yy.yy.yy
```
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录（默认用户名为 `admin`，密码为在 `rancher_server_admin_password` 中设置的密码）。
9. 使用 `quickstart/rancher/hcloud` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
#### 结果
两个 Kubernetes 集群已部署到你的 Hetzner 账户中，一个运行 Rancher Server，另一个为实验部署做好准备。请注意，虽然这种设置是探索 Rancher 功能的好方法，但在生产环境中，应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的，存储在模块目录中。
### 后续操作
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
## 销毁环境
1. 进入 `quickstart/rancher/hcloud` 文件夹，然后执行 `terraform destroy --auto-approve`。
2. 等待命令行界面显示资源已删除的消息。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/outscale-qs.md
+76
View File
@@ -0,0 +1,76 @@
---
title: Rancher Outscale 快速入门指南
description: 阅读此分步 Rancher Outscale 指南，以快速部署带有单节点下游 Kubernetes 集群的 Rancher Server。
weight: 140
---
你可以参考以下步骤，在 Outscale 的单节点 K3s Kubernetes 集群中快速部署 Rancher Server，并附加一个单节点下游 Kubernetes 集群。
:::note
本章节中提供的指南，旨在帮助你快速启动一个用于 Rancher 的沙盒，以评估 Rancher 是否能满足你的使用需求。快速入门指南不适用于生产环境。如果你需要获取生产环境的操作指导，请参见[安装](../../../pages-for-subheaders/installation-and-upgrade.md)。
:::
## 先决条件
:::caution
部署到 Outscale 会产生费用。
:::
- [Outscale 账号](https://en.outscale.com/)：用于运行服务器和集群。
- [Outscale 访问密钥](https://docs.outscale.com/en/userguide/About-Access-Keys.html)：如果你没有的话，请按照说明创建一个 Outscale 访问密钥。
- [Terraform](https://www.terraform.io/downloads.html)：用于在 Outscale 中配置服务器和集群。
## 开始使用
1. 使用命令行工具，执行 `git clone https://github.com/rancher/quickstart` 把 [Rancher Quickstart](https://github.com/rancher/quickstart) 克隆到本地。
2. 执行 `cd quickstart/rancher/outscale` 命令，进入包含 terraform 文件的 Outscale 文件夹。
3. 把 `terraform.tfvars.example` 文件重命名为 `terraform.tfvars`。
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `access_key_id` - 替换为 Outscale 访问密钥
- `secret_key_id` - 替换为 Outscale 密文密钥
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Outscale Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/outscale) 了解更多信息。
建议包括：
- `region` - Outscale 区域。Outscale 的默认区域不一定是距离你最近的区域。建议修改为距离你最近的区域（`eu-west-2`）。
- `prefix` - 所有创建资源的前缀
- `instance_type` - 实例类型，至少需要是 `tinav3.c2r4p3`。
6. 执行 `terraform init`。
7. 执行 `terraform apply --auto-approve` 以初始化环境。然后，等待命令行工具返回以下信息：
```
Apply complete! Resources: 21 added, 0 changed, 0 destroyed.
Outputs:
rancher_node_ip = xx.xx.xx.xx
rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
workload_node_ip = yy.yy.yy.yy
```
8. 将以上输出中的 `rancher_server_url` 粘贴到浏览器中。在登录页面中登录（默认用户名为 `admin`，密码为在 `rancher_server_admin_password` 中设置的密码）。
9. 使用 `quickstart/rancher/outscale` 中生成的 `id_rsa` 密钥 SSH 到 Rancher Server。
#### 结果
两个 Kubernetes 集群已部署到你的 Outscale 账户中，一个运行 Rancher Server，另一个为实验部署做好准备。请注意，虽然这种设置是探索 Rancher 功能的好方法，但在生产环境中，应遵循我们的高可用设置指南。用于虚拟机的 SSH 密钥是自动生成的，存储在模块目录中。
### 后续操作
使用 Rancher 创建 deployment。详情请参见[创建 Deployment](../../../pages-for-subheaders/deploy-rancher-workloads.md)。
## 销毁环境
1. 进入 `quickstart/rancher/outscale` 文件夹，然后执行 `terraform destroy --auto-approve`。
2. 等待命令行界面显示资源已删除的消息。

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