mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-05 20:53:33 +00:00
Archiving the v2.6/v2.7 zh docs. Updating the zh sidebar version JSON files to reflect archived messaging in navigation dropdown.
Signed-off-by: Sunil Singh <sunil.singh@suse.com>
This commit is contained in:
Sunil Singh
+11
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: 高级用户指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides"/>
|
||||
</head>
|
||||
|
||||
高级用户指南是“问题导向”的文档，用户可以从中学习如何解决问题。高级用于指南与新用户指南的主要区别在于，高级用户指南面向更有经验或更高级的用户，这些用户对文档有更多的技术需求，而且已经了解 Rancher 及其功能。他们知道自己需要做什么，只是需要额外的指导来完成更复杂的任务。
|
||||
|
||||
应该注意的是，新用户指南和高级用户指南都没有提供详细的解释或讨论（这些文档不包括在本部分）。操作指南侧重于引导用户通过可重复、有效的步骤来学习新技能、掌握某些操作或解决某些问题。
|
||||
+17
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: CIS 扫描指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/cis-scan-guides"/>
|
||||
</head>
|
||||
|
||||
- [安装 Rancher CIS Benchmark](install-rancher-cis-benchmark.md)
|
||||
- [卸载 Rancher CIS Benchmark](uninstall-rancher-cis-benchmark.md)
|
||||
- [运行扫描](run-a-scan.md)
|
||||
- [定时运行扫描](run-a-scan-periodically-on-a-schedule.md)
|
||||
- [跳过测试](skip-tests.md)
|
||||
- [查看报告](view-reports.md)
|
||||
- [为 Rancher CIS Benchmark 启用告警](enable-alerting-for-rancher-cis-benchmark.md)
|
||||
- [为定时扫描配置告警](configure-alerts-for-periodic-scan-on-a-schedule.md)
|
||||
- [为集群扫描创建自定义 Benchmark 版本](create-a-custom-benchmark-version-to-run.md)
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: 为定时扫描配置告警
|
||||
---
|
||||
|
||||
你可以定时运行 ClusterScan。
|
||||
|
||||
你还可以为定时扫描指定是否在扫描完成时发出告警。
|
||||
|
||||
只有定时运行的扫描才支持告警。
|
||||
|
||||
CIS Benchmark 应用支持两种类型的告警：
|
||||
|
||||
- 扫描完成告警：此告警在扫描运行完成时发出。告警包括详细信息，包括 ClusterScan 的名称和 ClusterScanProfile 的名称。
|
||||
- 扫描失败告警：如果扫描中有一些测试失败或扫描处于 `Fail` 状态，则会发出此告警。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
为 `rancher-cis-benchmark` 启用告警之前，确保安装了 `rancher-monitoring` 应用并配置了接收器（Receiver）和路由（Route）。详情请参见[本章节](../../../reference-guides/monitoring-v2-configuration/receivers.md)。
|
||||
|
||||
在为 `rancher-cis-benchmark` 告警配置路由时，你可以使用键值对 `job:rancher-cis-scan` 来指定匹配。详情请查看[路由配置示例](../../../reference-guides/monitoring-v2-configuration/receivers.md#cis-扫描告警的示例路由配置)。
|
||||
|
||||
:::
|
||||
|
||||
要为定时运行的扫描配置告警：
|
||||
|
||||
1. 请在 `rancher-cis-benchmark` 应用程序上启用告警。详情请参见[本页](../../../how-to-guides/advanced-user-guides/cis-scan-guides/enable-alerting-for-rancher-cis-benchmark.md)。
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要运行 CIS 扫描的集群，然后单击 **Explore**。
|
||||
1. 点击 **CIS Benchmark > 扫描**。
|
||||
1. 单击**创建**。
|
||||
1. 选择集群扫描配置文件。该配置文件确定要使用哪个 CIS Benchmark 版本以及要执行哪些测试。如果你选择 Default 配置文件，则 CIS Operator 将选择适用于它所在的 Kubernetes 集群类型的配置文件。
|
||||
1. 选择**定时运行扫描**的选项。
|
||||
1. 在**调度**字段中输入有效的 [Cron 表达式](https://en.wikipedia.org/wiki/Cron#CRON_expression)。
|
||||
1. 选中**告警**下告警类型旁边的框。
|
||||
1. （可选）选择一个**保留计数**，表示为这个定时扫描维护的报告数量。默认情况下，此计数为 3。超过此保留限制时，旧报告将被删除。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：扫描运行，并根据设置的 cron 表达式重新调度。如果在 `rancher-monitoring` 应用下配置了路由和接收器，则会在扫描完成时发出告警。
|
||||
|
||||
每次运行扫描都会生成一份带有扫描结果的报告。如需查看最新的结果，请单击显示的扫描名称。
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 为集群扫描创建自定义 Benchmark 版本
|
||||
---
|
||||
|
||||
某些 Kubernetes 集群可能需要自定义配置 Benchmark 测试。例如，Kubernetes 配置文件或证书的路径可能与上游 CIS Benchmark 的标准位置不同。
|
||||
|
||||
现在，你可以使用 `rancher-cis-benchmark` 应用来创建自定义 Benchmark 版本，从而运行集群扫描。
|
||||
|
||||
有关详细信息，请参阅[此页面](../../../integrations-in-rancher/cis-scans/custom-benchmark.md)。
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 为 Rancher CIS Benchmark 启用告警
|
||||
---
|
||||
|
||||
你可以配置告警，从而将告警发送给定时运行的扫描。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
为 `rancher-cis-benchmark` 启用告警之前，确保安装了 `rancher-monitoring` 应用并配置了接收器（Receiver）和路由（Route）。详情请参见[本章节](../../../reference-guides/monitoring-v2-configuration/receivers.md)。
|
||||
|
||||
在为 `rancher-cis-benchmark` 告警配置路由时，你可以使用键值对 `job:rancher-cis-scan` 来指定匹配。详情请查看[路由配置示例](../../../reference-guides/monitoring-v2-configuration/receivers.md#cis-扫描告警的示例路由配置)。
|
||||
|
||||
:::
|
||||
|
||||
在安装或升级 `rancher-cis-benchmark` Helm Chart 时，在 `values.yaml` 中将以下标志设置为 `true`：
|
||||
|
||||
```yaml
|
||||
alerts:
|
||||
enabled: true
|
||||
```
|
||||
+17
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: 安装 Rancher CIS Benchmark
|
||||
---
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要安装 CIS Benchmark 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **Apps > Charts**。
|
||||
1. 单击 **CIS Benchmark**。
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**：CIS 扫描应用已经部署在 Kubernetes 集群上。
|
||||
|
||||
:::note
|
||||
|
||||
如果你使用 Kubernetes v1.24 或更早版本，并且具有使用 [Pod 安全策略](../../new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) (PSP) 加固的集群，则 CIS Benchmark 4.0.0 及更高版本会默认禁用 PSP。要在 PSP 加固集群上安装 CIS Benchmark，请在安装 Chart 之前将 values 中的 `global.psp.enabled` 设置为 `true`。[Pod 安全准入](../../new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md) (PSA) 加固集群不受影响。
|
||||
|
||||
:::
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 定时运行扫描
|
||||
---
|
||||
|
||||
要定时运行 ClusterScan：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要运行 CIS 扫描的集群，然后单击 **Explore**。
|
||||
1. 点击 **CIS Benchmark > 扫描**。
|
||||
1. 选择集群扫描配置文件。该配置文件确定要使用哪个 CIS Benchmark 版本以及要执行哪些测试。如果你选择 Default 配置文件，则 CIS Operator 将选择适用于它所在的 Kubernetes 集群类型的配置文件。
|
||||
1. 选择**定时运行扫描**的选项。
|
||||
1. 将一个有效的 <a href="https://en.wikipedia.org/wiki/Cron#CRON_expression" target="_blank">Cron 表达式</a>填写到**调度**字段。
|
||||
1. 选择一个**保留计数**，表示为这个定时扫描维护的报告数量。默认情况下，此计数为 3。超过此保留限制时，旧报告将被删除。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：扫描运行，并根据设置的 cron 表达式重新调度。**下一次扫描**的值表示下次运行此扫描的时间。
|
||||
|
||||
每次运行扫描都会生成一份带有扫描结果的报告。如需查看最新的结果，请单击显示的扫描名称。
|
||||
|
||||
你还可以在扫描详情页面上的**报告**下拉菜单中查看之前的报告。
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: 运行扫描
|
||||
---
|
||||
|
||||
创建 ClusterScan 自定义资源后，它会在集群上为所选 ClusterScanProfile 启动新的 CIS 扫描。
|
||||
|
||||
:::note
|
||||
|
||||
请注意，目前一个集群每次只能运行一次 CIS 扫描。如果你创建了多个 ClusterScan 自定义资源，operator 只能一个接一个地运行这些资源。一个扫描完成之前，其余 ClusterScan 自定义资源将处于 “Pending” 状态。
|
||||
|
||||
:::
|
||||
|
||||
要运行扫描：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要运行 CIS 扫描的集群，然后单击 **Explore**。
|
||||
1. 点击 **CIS Benchmark > 扫描**。
|
||||
1. 单击**创建**。
|
||||
1. 选择集群扫描配置文件。该配置文件确定要使用哪个 CIS Benchmark 版本以及要执行哪些测试。如果你选择 Default 配置文件，则 CIS Operator 将选择适用于它所在的 Kubernetes 集群类型的配置文件。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：已生成带有扫描结果的报告。如需查看结果，请单击显示的扫描名称。
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: 跳过测试
|
||||
---
|
||||
|
||||
用户可以在测试配置文件中自定义要跳过的测试，然后 CIS 扫描可以使用该配置文件运行。
|
||||
|
||||
要跳过测试，你需要创建自定义一个 CIS 扫描配置文件。配置文件包含 CIS 扫描的配置，包括要使用的 Benchmark 测试版本以及要在该 Benchmark 测试中跳过的测试。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要运行 CIS 扫描的集群，然后单击 **Explore**。
|
||||
1. 单击 **CIS Benchmark > 配置文件**。
|
||||
1. 在这里，你可以使用多种方式来创建配置文件。要创建新配置文件，单击**创建**并在 UI 中填写表单。要基于现有配置文件来创建新配置文件，请转到现有配置文件并单击**⋮ 克隆**。如果你在填写表单，请使用测试 ID 添加要跳过的测试，并参考相关的 CIS Benchmark。如果你将新的测试配置文件创建为 YAML，你需要在 `skipTests` 参数中添加要跳过的测试的 ID。你还需要为配置文件命名：
|
||||
|
||||
```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"
|
||||
```
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：已创建一个新的 CIS 扫描配置文件。
|
||||
|
||||
使用此配置文件[运行扫描](./run-a-scan.md)时，会跳过定义的跳过测试。跳过的测试将在生成的报告中标记为 `Skip`。
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 卸载 Rancher CIS Benchmark
|
||||
---
|
||||
|
||||
1. 在**集群**仪表板中，单击左侧导航的 **Apps > Installed Apps**。
|
||||
1. 前往 `cis-operator-system` 命名空间，并选中 `rancher-cis-benchmark-crd` 和 `rancher-cis-benchmark` 旁边的框。
|
||||
1. 单击**删除**并确认**删除**。
|
||||
|
||||
**结果**：已卸载 `rancher-cis-benchmark` 应用。
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: 查看报告
|
||||
---
|
||||
|
||||
要查看生成的 CIS 扫描报告：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要运行 CIS 扫描的集群，然后单击 **Explore**。
|
||||
1. 点击 **CIS Benchmark > 扫描**。
|
||||
1. **扫描**页面将显示生成的报告。要查看详细报告，请转到扫描报告并单击报告名称。
|
||||
|
||||
你可以从扫描列表或扫描详情页面下载报告。
|
||||
+260
@@ -0,0 +1,260 @@
|
||||
---
|
||||
title: 7 层 NGINX 负载均衡器上的 TLS 终止（Docker 安装）
|
||||
---
|
||||
|
||||
如果你的开发或测试环境要求在负载均衡器上终止 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/>
|
||||
|
||||
## 常见问题和故障排除
|
||||
|
||||
如果你需要对证书进行故障排除，请参见[此章节](../../getting-started/installation-and-upgrade/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
|
||||
```
|
||||
|
||||
此操作需要 [privileged 访问](../../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/>
|
||||
|
||||
+140
@@ -0,0 +1,140 @@
|
||||
---
|
||||
title: 下游集群开启 API 审计日志
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/enable-api-audit-log-in-downstream-clusters"/>
|
||||
</head>
|
||||
|
||||
Kubernetes 审计提供了由 Kube-apiserver 执行的与安全相关的、按时间顺序排列的集群审计记录。Kube API 会在请求执行的每个阶段都生成一个事件，然后根据策略进行预处理并保存，审计策略配置了要记录的内容。
|
||||
|
||||
你可能希望将审计日志配置为遵守互联网安全中心 (CIS) Kubernetes 基准控制的一部分。
|
||||
|
||||
有关配置的详细信息，请参阅 [Kubernetes 官方文档](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/)。
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2/K3s" default>
|
||||
|
||||
:::note
|
||||
|
||||
Rancher v2.7.2 及以上版本提供此功能。
|
||||
|
||||
:::
|
||||
|
||||
首先，你需要创建一个 Secret 或 ConfigMap，用于配置审计策略。
|
||||
|
||||
Secret 或 ConfigMap 必须满足以下两个要求：
|
||||
|
||||
1. 必须位于 Cluster 对象所在的 `fleet-default` 命名空间中。
|
||||
2. 它必须具有注释 `rke.cattle.io/object-authorized-for-clusters: cluster-name1,cluster-name2`，以允许目标集群使用它。
|
||||
|
||||
:::tip
|
||||
|
||||
Rancher Dashboard 提供了易于使用的表单页面用于创建 Secret 或 ConfigMap。
|
||||
|
||||
:::
|
||||
|
||||
例子：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
audit-policy: >-
|
||||
IyBMb2cgYWxsIHJlcXVlc3RzIGF0IHRoZSBNZXRhZGF0YSBsZXZlbC4KYXBpVmVyc2lvbjogYXVkaXQuazhzLmlvL3YxCmtpbmQ6IFBvbGljeQpydWxlczoKLSBsZXZlbDogTWV0YWRhdGE=
|
||||
kind: Secret
|
||||
metadata:
|
||||
annotations:
|
||||
rke.cattle.io/object-authorized-for-clusters: cluster1
|
||||
name: name1
|
||||
namespace: fleet-default
|
||||
```
|
||||
|
||||
可以通过编辑集群 YAML 的 `machineSelectorFiles` 和 `machineGlobalConfig` 字段来启用和配置审计日志。
|
||||
|
||||
例子：
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- audit-policy-file=<customized-path>/dev-audit-policy.yaml
|
||||
- audit-log-path=<customized-path>/dev-audit.logs
|
||||
machineSelectorFiles:
|
||||
- fileSources:
|
||||
- configMap:
|
||||
name: ''
|
||||
secret:
|
||||
items:
|
||||
- key: audit-policy
|
||||
path: <customized-path>/dev-audit-policy.yaml
|
||||
name: dev-audit-policy
|
||||
machineLabelSelector:
|
||||
matchLabels:
|
||||
rke.cattle.io/control-plane-role: 'true'
|
||||
```
|
||||
|
||||
有关集群配置的更多信息，请参阅 REK2 或 K3s 集群配置参考页。
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="RKE1">
|
||||
|
||||
可通过编辑集群 YAML 来启用和配置审计日志。
|
||||
|
||||
在启用审计日志后，将使用 RKE1 的默认值。
|
||||
|
||||
```yaml
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
services:
|
||||
kube-api:
|
||||
audit_log:
|
||||
enabled: true
|
||||
```
|
||||
|
||||
你还可以自定义审计日志配置。
|
||||
|
||||
```yaml
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
services:
|
||||
kube-api:
|
||||
audit_log:
|
||||
enabled: true
|
||||
configuration:
|
||||
max_age: 6
|
||||
max_backup: 6
|
||||
max_size: 110
|
||||
path: /var/log/kube-audit/audit-log.json
|
||||
format: json
|
||||
policy:
|
||||
apiVersion: audit.k8s.io/v1 # 这里必须填写
|
||||
kind: Policy
|
||||
omitStages:
|
||||
- "RequestReceived"
|
||||
rules:
|
||||
# Log pod changes at RequestResponse level
|
||||
- level: RequestResponse
|
||||
resources:
|
||||
- group: ""
|
||||
# Resource "pods" doesn't match requests to any subresource of pods,
|
||||
# which is consistent with the RBAC policy.
|
||||
resources: ["pods"]
|
||||
# Log "pods/log", "pods/status" at Metadata level
|
||||
- level: Metadata
|
||||
resources:
|
||||
- group: ""
|
||||
resources: ["pods/log", "pods/status"]
|
||||
```
|
||||
|
||||
配置详情请参考 [RKE1 官方文档](https://rke.docs.rancher.com/config-options/audit-log)。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
+558
@@ -0,0 +1,558 @@
|
||||
---
|
||||
title: 启用 API 审计日志以记录系统事件
|
||||
---
|
||||
|
||||
你可以启用 API 审计日志来记录各个用户发起的系统事件的顺序。通过查看日志，你可以了解发生了什么事件、事件发生的时间，事件发起人，以及事件影响的集群。启用此功能后，所有 Rancher API 的请求和响应都会写入日志中。
|
||||
|
||||
API 审计可以在 Rancher 安装或升级期间启用。
|
||||
|
||||
## 启用 API 审计日志
|
||||
|
||||
你可以将环境变量传递给 Rancher Server 容器，从而启用和配置审计日志。请参见以下文档，在安装时启用该功能：
|
||||
|
||||
- [Docker 安装](../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-审计日志)
|
||||
|
||||
- [Kubernetes 安装](../../getting-started/installation-and-upgrade/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"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: 持续交付
|
||||
---
|
||||
|
||||
Rancher 中预装的 [Fleet](../../../integrations-in-rancher/fleet-gitops-at-scale/fleet-gitops-at-scale.md) 无法完全禁用。但是，你可以使用 `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 中显示。
|
||||
+127
@@ -0,0 +1,127 @@
|
||||
---
|
||||
title: 启用实验功能
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/enable-experimental-features"/>
|
||||
</head>
|
||||
|
||||
Rancher 包含一些默认关闭的实验功能。在某些情况下，例如当你认为使用[不支持的存储类型](unsupported-storage-drivers.md)的好处大于使用未经测试的功能的风险时，你可能想要启用实验功能。为了让你能够试用这些默认关闭的功能，我们引入了功能开关（feature flag）。
|
||||
|
||||
实验功能可以通过以下三种方式启用：
|
||||
|
||||
- [使用 CLI](#启动-rancher-时启用功能)：在使用 CLI 安装 Rancher 时，使用功能开关默认启用某个功能。
|
||||
- [使用 Rancher UI](#使用-rancher-ui-启用功能)：在**设置**页面启用功能。
|
||||
- [使用 Rancher API](#使用-rancher-api-启用功能)：安装 Rancher 后启用功能。
|
||||
|
||||
每个功能均有以下两个值：
|
||||
|
||||
- 默认值：可以通过在命令行使用标志或环境变量进行配置。
|
||||
- 设置值：可以通过 Rancher API 或 UI 进行配置。
|
||||
|
||||
如果没有设置值，Rancher 会使用默认值。
|
||||
|
||||
设置值是通过 API 设置的，而默认值是通过命令行设置。因此，如果你使用 API 或 UI 启用或禁用某个功能，命令行中设置的值将被覆盖。
|
||||
|
||||
如果你安装 Rancher 后使用 Rancher API 将功能开关设置为 true，然后在使用命令升级 Rancher 时将功能开关设置为 false，在这种情况下，虽然默认值会是 false，但是该功能依然会被启用，因为它是通过 API 设置的。如果你随后使用 Rancher API 删除设置值（true）并将它设置为 NULL，则默认值（false）将生效。有关详细信息，请参阅[功能开关页面](../../../getting-started/installation-and-upgrade/installation-references/feature-flags.md)。
|
||||
|
||||
## 启动 Rancher 时启用功能
|
||||
|
||||
安装 Rancher 时，使用功能开关启用你所需的功能。通过单节点容器安装 Rancher，和在 Kubernetes 集群上安装 Rancher 对应的命令有所不同。
|
||||
|
||||
### Kubernetes 安装的情况下启用功能
|
||||
|
||||
:::note
|
||||
|
||||
通过 Rancher API 设置的值会覆盖命令行传入的值。
|
||||
|
||||
:::
|
||||
|
||||
使用 Helm Chart 安装 Rancher 时，使用 `--set` 选项。下面的示例通过传递功能开关名称（用逗号分隔）来启用两个功能：
|
||||
|
||||
对于 Kubernetes v1.25 或更高版本，使用 Rancher v2.7.2-v2.7.4 时，将 `global.cattle.psp.enabled` 设置为 `false`。对于 Rancher v2.7.5 及更高版本来说，这不是必需的，但你仍然可以手动设置该选项。
|
||||
|
||||
```
|
||||
helm install rancher rancher-latest/rancher \
|
||||
--namespace cattle-system \
|
||||
--set hostname=rancher.my.org \
|
||||
--set 'extraEnv[0].name=CATTLE_FEATURES'
|
||||
--set 'extraEnv[0].value=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true'
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
如果你安装的是 alpha 版本，Helm 要求你在命令中添加 `--devel` 选项。
|
||||
|
||||
:::
|
||||
|
||||
### 离线安装的情况下渲染 Helm Chart
|
||||
|
||||
如果你是在离线环境安装 Rancher 的，在使用 Helm 安装 Rancher 之前，你需要添加一个 Helm Chart 仓库并渲染一个 Helm 模板。详情请参见[离线安装文档](../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md)。
|
||||
|
||||
以下是在渲染 Helm 模板时传入功能开关名称的命令示例。下面的示例通过传递功能开关名称（用逗号分隔）来启用两个功能。
|
||||
|
||||
Helm 命令如下：
|
||||
|
||||
```
|
||||
helm install rancher ./rancher-<VERSION>.tgz \
|
||||
--namespace cattle-system \
|
||||
--set hostname=<RANCHER.YOURDOMAIN.COM> \
|
||||
--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
|
||||
--set ingress.tls.source=secret \
|
||||
--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # 设置在 Rancher 中使用的私有镜像仓库
|
||||
--set useBundledSystemChart=true # 使用打包的 Rancher System Chart
|
||||
--set 'extraEnv[0].name=CATTLE_FEATURES'
|
||||
--set 'extraEnv[0].value=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true'
|
||||
```
|
||||
|
||||
### Docker 安装的情况下启用功能
|
||||
|
||||
如果 Rancher 是使用 Docker 安装的，请使用 `--features` 选项。下面的示例通过传递功能开关名称（用逗号分隔）来启用两个功能：
|
||||
|
||||
```
|
||||
docker run -d -p 80:80 -p 443:443 \
|
||||
--restart=unless-stopped \
|
||||
rancher/rancher:rancher-latest \
|
||||
--features=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true
|
||||
```
|
||||
|
||||
## 使用 Rancher UI 启用功能
|
||||
|
||||
1. 在左上角，单击 **☰ > 全局设置**。
|
||||
1. 单击**功能开关**。
|
||||
1. 如需启用某个功能，找到该已禁用的功能，并点击**⋮ > 激活**。
|
||||
|
||||
**结果**：该功能已启用。
|
||||
|
||||
### 使用 Rancher UI 禁用功能
|
||||
|
||||
1. 在左上角，单击 **☰ > 全局设置**。
|
||||
1. 单击**功能开关**。你将看到实验功能列表。
|
||||
1. 如需禁用某个功能，找到该已启用的功能，并点击**⋮ > 停用**。
|
||||
|
||||
**结果**：该功能已禁用。
|
||||
|
||||
## 使用 Rancher API 启用功能
|
||||
|
||||
1. 前往 `<RANCHER-SERVER-URL>/v3/features`。
|
||||
1. 在 `data` 中，你会看到一个数组，该数组包含所有能通过功能开关启用的功能。功能的名称在 `id` 字段中。单击要启用的功能的名称。
|
||||
1. 在左上角的 **Operations** 下，点击 **Edit**。
|
||||
1. 在 **Value** 下拉菜单中，单击 **True**。
|
||||
1. 单击 **Show Request**。
|
||||
1. 单击 **Send Request**。
|
||||
1. 点击 **Close**。
|
||||
|
||||
**结果**：该功能已启用。
|
||||
|
||||
### 使用 Rancher API 禁用功能
|
||||
|
||||
1. 前往 `<RANCHER-SERVER-URL>/v3/features`。
|
||||
1. 在 `data` 中，你会看到一个数组，该数组包含所有能通过功能开关启用的功能。功能的名称在 `id` 字段中。单击要启用的功能的名称。
|
||||
1. 在左上角的 **Operations** 下，点击 **Edit**。
|
||||
1. 在 **Value** 下拉菜单中，单击 **False**。
|
||||
1. 单击 **Show Request**。
|
||||
1. 单击 **Send Request**。
|
||||
1. 点击 **Close**。
|
||||
|
||||
**结果**：该功能已禁用。
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: UI 管理 Istio 虚拟服务和目标规则
|
||||
---
|
||||
|
||||
此功能可启动一个 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** 的选项卡。在左侧导航栏中，你可查看和配置**虚拟服务**和**目标规则**。
|
||||
+44
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "在 ARM64 上运行 Rancher（实验性）"
|
||||
---
|
||||
|
||||
:::caution
|
||||
|
||||
在使用 ARM64 架构的节点上运行 Rancher 目前还处在实验阶段，Rancher 尚未正式支持该功能。因此，我们不建议你在生产环境中使用 ARM64 架构的节点。
|
||||
|
||||
:::
|
||||
|
||||
如果你的节点使用 ARM64 架构，你可以使用以下选项：
|
||||
|
||||
- 在 ARM64 架构的节点上运行 Rancher
|
||||
- 此选项仅适用于 Docker 安装。请知悉，以下安装命令取代了 [Docker 安装链接](../../../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 或更高版本
|
||||
|
||||
如需了解如何配置集群选项，请参见[集群选项](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。
|
||||
|
||||
以下是未经测试的功能：
|
||||
|
||||
- Monitoring、告警、Notifiers、流水线和 Logging
|
||||
- 通过应用商店发布应用
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: 使用非默认支持的存储驱动
|
||||
---
|
||||
|
||||
此功能允许你使用不是默认启用的存储提供商和卷插件。
|
||||
|
||||
如需启用或禁用此功能，请参见[启用实验功能主页](../../../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` |
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: 1. 在集群中启用 Istio
|
||||
---
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
- 只有分配了 `cluster-admin` [Kubernetes 默认角色](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)的用户可以在 Kubernetes 集群中配置和安装 Istio。
|
||||
- 如果你有 pod 安全策略，则需要安装启用了 CNI 的 Istio。有关详细信息，请参阅[本节](../../../integrations-in-rancher/istio/configuration-options/pod-security-policies.md)。
|
||||
- 要在 RKE2 集群上安装 Istio，则需要执行额外的步骤。有关详细信息，请参阅[本节](../../../integrations-in-rancher/istio/configuration-options/install-istio-on-rke2-cluster.md)。
|
||||
- 要在启用了项目网络隔离的集群中安装 Istio，则需要执行额外的步骤。有关详细信息，请参阅[本节](../../../integrations-in-rancher/istio/configuration-options/project-network-isolation.md)。
|
||||
|
||||
:::
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到要启用 Istio 的位置，然后单击 **Explore**。
|
||||
1. 单击 **Apps**。
|
||||
1. 单击 **Chart**。
|
||||
1. 单击 **Istio**。
|
||||
1. 如果你还没有安装 Monitoring 应用，系统会提示你安装 rancher-monitoring。你也可以选择在 Rancher-monitoring 安装上设置选择器或抓取配置选项。
|
||||
1. 可选：为 Istio 组件配置成员访问和[资源限制](../../../integrations-in-rancher/istio/cpu-and-memory-allocations.md)。确保你的 Worker 节点上有足够的资源来启用 Istio。
|
||||
1. 可选：如果需要，对 values.yaml 进行额外的配置更改。
|
||||
1. 可选：通过[覆盖文件](../../../pages-for-subheaders/configuration-options.md#覆盖文件)来添加其他资源或配置。
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**：已在集群级别安装 Istio。
|
||||
|
||||
## 其他配置选项
|
||||
|
||||
有关配置 Istio 的更多信息，请参阅[配置参考](../../../pages-for-subheaders/configuration-options.md)。
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: 2. 在命名空间中启用 Istio
|
||||
---
|
||||
|
||||
你需要在需要由 Istio 跟踪或控制的每个命名空间中手动启用 Istio。在命名空间中启用 Istio 时，Envoy sidecar 代理将自动注入到部署在命名空间中的所有新工作负载中。
|
||||
|
||||
此命名空间设置只会影响命名空间中的新工作负载。之前的工作负载需要重新部署才能使用 sidecar 自动注入。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
要在命名空间中启用 Istio，集群必须安装 Istio。
|
||||
|
||||
:::
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 转到要启用 Istio 的命名空间，然后单击**⋮ > 启用 Istio 自动注入**。或者，你也可以单击命名空间，然后在命名空间详情页面上，单击**⋮ > 启用 Istio 自动注入**。
|
||||
|
||||
**结果**：命名空间带有了 `istio-injection=enabled` 标签。默认情况下，部署在此命名空间中的所有新工作负载都将注入 Istio sidecar。
|
||||
|
||||
### 验证是否启用了自动 Istio Sidecar 注入
|
||||
|
||||
要验证 Istio 是否已启用，请在命名空间中部署一个 hello-world 工作负载。转到工作负载并单击 pod 名称。在**容器**中，你应该能看到 `istio-proxy` 容器。
|
||||
|
||||
### 排除工作负载的 Istio Sidecar 注入
|
||||
|
||||
要排除 Istio sidecar 被注入某工作负载，请在工作负载上使用以下注释：
|
||||
|
||||
```
|
||||
sidecar.istio.io/inject: “false”
|
||||
```
|
||||
|
||||
要将注释添加到工作负载：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 点击**工作负载**。
|
||||
1. 转到不需要 sidecar 的工作负载并以 yaml 编辑。
|
||||
1. 将键值 `sidecar.istio.io/inject: false` 添加为工作负载的注释。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：Istio sidecar 不会被注入到工作负载中。
|
||||
|
||||
:::note
|
||||
|
||||
如果你遇到部署的 job 未完成的问题，则需要使用提供的步骤将此注释添加到 pod 中。由于 Istio Sidecars 会一直运行，因此即使任务完成了，也不能认为 Job 已完成。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
### 后续步骤
|
||||
[使用 Istio Sidecar 添加部署](use-istio-sidecar.md)
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: 6. 生成和查看流量
|
||||
---
|
||||
|
||||
本文介绍如何查看 Istio 管理的流量。
|
||||
|
||||
## Kiali 流量图
|
||||
|
||||
Istio 概览页面提供了 Kiali 仪表板的链接。在 Kiali 仪表板中，你可以查看每个命名空间的图。Kiali 图提供了一种强大的方式来可视化 Istio 服务网格的拓扑。它显示了服务之间相互通信的情况。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
要显示流量图，请确保你在集群中安装了 Prometheus。Rancher-istio 安装了默认配置的 Kiali 来与 rancher-monitoring Chart 一起工作。你可以使用 rancher-monitoring 或安装自己的监控解决方案。你也可以通过设置[选择器 & 抓取配置](../../../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md)选项来更改数据抓取的配置（可选）。
|
||||
|
||||
:::
|
||||
|
||||
要查看流量图：
|
||||
|
||||
1. 在安装了 Istio 的集群中，点击左侧导航栏中的 **Istio**。
|
||||
1. 单击 **Kiali** 链接。
|
||||
1. 单击侧导航中的**图**。
|
||||
1. 在**命名空间**下拉列表中，更改命名空间以查看每个命名空间的流量。
|
||||
|
||||
如果你多次刷新 BookInfo 应用的 URL，你将能够在 Kiali 图上看到绿色箭头，显示 `reviews` 服务 `v1` 和 `v3` 的流量。图右侧的控制面板可用于配置详细信息，包括应在图上显示多少分钟的最新流量。
|
||||
|
||||
对于其他工具和可视化，你可以从**监控** > **概览**页面转到 Grafana 和 Prometheus 仪表板。
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: 设置指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/istio-setup-guide"/>
|
||||
</head>
|
||||
|
||||
本文介绍如何启用 Istio 并在你的项目中使用它。
|
||||
|
||||
如果你使用 Istio 进行流量管理，则需要允许外部流量进入集群。在这种情况下，你将需要执行以下所有步骤。
|
||||
|
||||
## 先决条件
|
||||
|
||||
本指南假设你已经[安装 Rancher](../../../getting-started/installation-and-upgrade/installation-and-upgrade.md)，且已经[配置了一个单独的 Kubernetes 集群](../../new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md)并要在该集群上安装 Istio。
|
||||
|
||||
集群中的节点必须满足 [CPU 和内存要求](../../../integrations-in-rancher/istio/cpu-and-memory-allocations.md)。
|
||||
|
||||
Istio 控制的工作负载和服务必须满足 [Istio 要求](https://istio.io/docs/setup/additional-setup/requirements/)。
|
||||
|
||||
## 安装
|
||||
|
||||
:::tip 快速设置提示:
|
||||
|
||||
如果你不需要外部流量到达 Istio，而只想设置 Istio 以监控和跟踪集群内的流量，请跳过[设置 Istio Gateway](set-up-istio-gateway.md)和[设置 Istio 的流量管理组件](set-up-traffic-management.md)步骤。
|
||||
|
||||
:::
|
||||
|
||||
1. [在集群中启用 Istio。](enable-istio-in-cluster.md)
|
||||
2. [在命名空间中启用 Istio。](enable-istio-in-namespace.md)
|
||||
3. [使用 Istio Sidecar 添加部署和服务。](use-istio-sidecar.md)
|
||||
4. [设置 Istio Gateway。](set-up-istio-gateway.md)
|
||||
5. [设置 Istio 的流量管理组件。](set-up-traffic-management.md)
|
||||
6. [生成和查看流量。](generate-and-view-traffic.md)
|
||||
+147
@@ -0,0 +1,147 @@
|
||||
---
|
||||
title: 4. 设置 Istio Gateway
|
||||
---
|
||||
|
||||
每个集群的网关可以有自己的端口或负载均衡器，这与服务网格无关。默认情况下，每个 Rancher 配置的集群都有一个 NGINX Ingress Controller 来允许流量进入集群。
|
||||
|
||||
无论是否安装了 Istio，你都可以使用 NGINX Ingress Controller。如果这是你集群的唯一网关，Istio 将能够将流量从集群内部的服务路由到集群内部的另一个服务，但 Istio 将无法接收来自集群外部的流量。
|
||||
|
||||
要让 Istio 接收外部流量，你需要启用 Istio 的网关，作为外部流量的南北代理。启用 Istio Gateway 后，你的集群将有两个 Ingress。
|
||||
|
||||
你还需要为你的服务设置 Kubernetes 网关。此 Kubernetes 资源指向 Istio 对集群 Ingress Gateway 的实现。
|
||||
|
||||
你可以使用负载均衡器将流量路由到服务网格中，或使用 Istio 的 NodePort 网关。本文介绍如何设置 NodePort 网关。
|
||||
|
||||
有关 Istio Gateway 的更多信息，请参阅 [Istio 文档](https://istio.io/docs/reference/config/networking/v1alpha3/gateway/)。
|
||||
|
||||
|
||||
|
||||
## 启用 Istio Gateway
|
||||
|
||||
Ingress Gateway 是一个 Kubernetes 服务，将部署在你的集群中。Istio Gateway 支持更多自定义设置，更加灵活。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **Istio > 网关**。
|
||||
1. 单击**使用 YAML 文件创建**。
|
||||
1. 粘贴你的 Istio Gateway yaml，或选择**从文件读取**。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：已部署网关，将使用应用的规则来路由流量。
|
||||
|
||||
## Istio Gateway 示例
|
||||
|
||||
在演示工作负载示例时，我们在服务中添加 BookInfo 应用部署。接下来，我们添加一个 Istio Gateway，以便从集群外部访问该应用。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **Istio > 网关**。
|
||||
1. 单击**使用 YAML 文件创建**。
|
||||
1. 复制并粘贴下面的 Gateway YAML。
|
||||
1. 单击**创建**。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: bookinfo-gateway
|
||||
spec:
|
||||
selector:
|
||||
istio: ingressgateway # use istio default controller
|
||||
servers:
|
||||
- port:
|
||||
number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
hosts:
|
||||
- "*"
|
||||
---
|
||||
```
|
||||
|
||||
然后，部署为 Gateway 提供流量路由的 VirtualService：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **Istio > VirtualServices**。
|
||||
1. 复制并粘贴下面的 VirtualService YAML。
|
||||
1. 单击**创建**。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: bookinfo
|
||||
spec:
|
||||
hosts:
|
||||
- "*"
|
||||
gateways:
|
||||
- bookinfo-gateway
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
exact: /productpage
|
||||
- uri:
|
||||
prefix: /static
|
||||
- uri:
|
||||
exact: /login
|
||||
- uri:
|
||||
exact: /logout
|
||||
- uri:
|
||||
prefix: /api/v1/products
|
||||
route:
|
||||
- destination:
|
||||
host: productpage
|
||||
port:
|
||||
number: 9080
|
||||
```
|
||||
|
||||
**结果**：你已配置网关资源，Istio 现在可以接收集群外部的流量。
|
||||
|
||||
运行以下命令来确认资源存在：
|
||||
```
|
||||
kubectl get gateway -A
|
||||
```
|
||||
|
||||
结果应与以下内容类似：
|
||||
```
|
||||
NAME AGE
|
||||
bookinfo-gateway 64m
|
||||
```
|
||||
|
||||
### 在 Web 浏览器访问 ProductPage 服务
|
||||
|
||||
要测试 BookInfo 应用是否已正确部署，你可以使用 Istio 控制器 IP 和端口以及在 Kubernetes 网关资源中指定的请求名称，在 Web 浏览器中查看该应用：
|
||||
|
||||
`http://<IP of Istio controller>:<Port of istio controller>/productpage`
|
||||
|
||||
要获取 Ingress Gateway URL 和端口：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**工作负载**。
|
||||
1. 向下滚动到 `istio-system` 命名空间。
|
||||
1. 在 `istio-system`中，有一个名为 `istio-ingressgateway` 的工作负载。在此工作负载的名称下，你应该会看到如 `80/tcp` 的链接。
|
||||
1. 单击其中一个链接。然后，你的 Web 浏览器中会显示 Ingress Gateway 的 URL。将 `/productpage` 尾附到 URL。
|
||||
|
||||
**结果**：你能会在 Web 浏览器中看到 BookInfo 应用。
|
||||
|
||||
如需检查 Istio 控制器 URL 和端口的帮助，请尝试运行 [Istio 文档](https://istio.io/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports)中的命令。
|
||||
|
||||
## 故障排除
|
||||
|
||||
[官方 Istio 文档](https://istio.io/docs/tasks/traffic-management/ingress/ingress-control/#troubleshooting)建议使用 `kubectl` 命令来检查外部请求的正确 ingress 主机和 ingress 端口。
|
||||
|
||||
### 确认 Kubernetes 网关与 Istio 的 Ingress Controller 匹配
|
||||
|
||||
你可以尝试执行本节中的步骤以确保 Kubernetes 网关配置正确。
|
||||
|
||||
在网关资源中，选择器通过标签来引用 Istio 的默认 Ingress Controller，其中标签的键是 `Istio`，值是 `ingressgateway`。要确保标签适用于网关，请执行以下操作：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**工作负载**。
|
||||
1. 向下滚动到 `istio-system` 命名空间。
|
||||
1. 在 `istio-system`中，有一个名为 `istio-ingressgateway` 的工作负载。单击此工作负载的名称并转到**标签和注释**部分。你应该看到它具有 `istio` 键和 `ingressgateway` 值。这确认了 Gateway 资源中的选择器与 Istio 的默认 ingress controller 匹配。
|
||||
|
||||
### 后续步骤
|
||||
[设置 Istio 的流量管理组件](set-up-traffic-management.md)
|
||||
+76
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: 5. 设置 Istio 的流量管理组件
|
||||
---
|
||||
|
||||
Istio 中流量管理的一个核心优势是允许动态请求路由。动态请求路由通常应用于金丝雀部署和蓝/绿部署等。Istio 流量管理中的两个关键资源是*虚拟服务*和*目标规则*。
|
||||
|
||||
- [虚拟服务](https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service/)：拦截并将流量重定向到你的 Kubernetes Service 上。这样，你可以将部分请求流量分配到不同的服务上。你可以使用这些服务来定义一组路由规则，用于主机寻址。
|
||||
- [目标规则](https://istio.io/docs/reference/config/networking/v1alpha3/destination-rule/)：作为唯一可信来源，表明哪些服务版本可用于接收虚拟服务的流量。你可以使用这些资源来定义策略，这些策略适用于路由发生后用于服务的流量。
|
||||
|
||||
本文介绍如何在示例 BookInfo 应用中添加与 `reviews` 微服务对应的虚拟服务示例。此服务的目的是在 `reviews` 服务的两个版本之间划分流量。
|
||||
|
||||
在这个示例中，我们将流量带到 `reviews` 服务中并拦截流量，这样，50% 的流量会流向服务的 `v1`，另外 50% 的流量会流向 `v2 `。
|
||||
|
||||
部署这个虚拟服务后，我们将生成流量，并通过 Kiali 可视化看到流量平均路由到服务的两个版本中。
|
||||
|
||||
要为 `reviews` 服务部署虚拟服务和目标规则：
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到安装了 Istio 的集群，然后单击 **Explore**。
|
||||
1. 在安装了 Istio 的集群中，点击左侧导航栏中的 **Istio > DestinationRules**。
|
||||
1. 单击**创建**。
|
||||
1. 复制并粘贴下面的 DestinationRule YAML。
|
||||
1. 单击**创建**。
|
||||
1. 单击**以 YAML 文件编辑**并使用此配置：
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: reviews
|
||||
spec:
|
||||
host: reviews
|
||||
subsets:
|
||||
- name: v1
|
||||
labels:
|
||||
version: v1
|
||||
- name: v2
|
||||
labels:
|
||||
version: v2
|
||||
- name: v3
|
||||
labels:
|
||||
version: v3
|
||||
```
|
||||
1. 单击**创建**。
|
||||
|
||||
然后，部署提供利用 DestinationRule 的流量路由的 VirtualService：
|
||||
|
||||
1. 单击侧导航栏中的 **VirtualService**。
|
||||
1. 单击**使用 YAML 文件创建**。
|
||||
1. 复制并粘贴下面的 VirtualService YAML。
|
||||
1. 单击**创建**。
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews
|
||||
spec:
|
||||
hosts:
|
||||
- reviews
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: reviews
|
||||
subset: v1
|
||||
weight: 50
|
||||
- destination:
|
||||
host: reviews
|
||||
subset: v3
|
||||
weight: 50
|
||||
---
|
||||
```
|
||||
|
||||
**结果**：生成流到该服务的流量时（例如，刷新 Ingress Gateway URL），你可以在 Kiali 流量图中看到流到 `reviews` 服务的流量被平均分配到了 `v1` 和 `v3`。
|
||||
|
||||
### 后续步骤
|
||||
[生成和查看流量](generate-and-view-traffic.md)
|
||||
+360
@@ -0,0 +1,360 @@
|
||||
---
|
||||
title: 3. 使用 Istio Sidecar 添加部署和服务
|
||||
---
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
要为工作负载启用 Istio，你必须先在集群和命名空间中安装 Istio 应用。
|
||||
|
||||
:::
|
||||
|
||||
在命名空间中启用 Istio 只会为新工作负载启用自动 sidecar 注入。要为现有工作负载启用 Envoy sidecar，你需要手动为每个工作负载启用它。
|
||||
|
||||
要在命名空间中的现有工作负载上注入 Istio sidecar：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要可视化的集群，然后单击 **Explore**。
|
||||
1. 点击**工作负载**。
|
||||
1. 转到要注入 Istio sidecar 的工作负载，然后单击 **⋮ > 重新部署**。重新部署工作负载后，该工作负载会自动注入 Envoy sidecar。
|
||||
|
||||
等待几分钟，然后工作负载将升级并具有 Istio sidecar。单击它并转到**容器**。你应该能看到该工作负载旁边的 `istio-proxy`。这意味着为工作负载启用了 Istio sidecar。Istio 正在为 Sidecar Envoy 做所有的接线工作。如果你现在在 yaml 中启用它们，Istio 可以自动执行所有功能。
|
||||
|
||||
### 添加部署和服务
|
||||
|
||||
以下是在命名空间中添加新 **Deployment** 的几种方法：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 点击**工作负载**。
|
||||
1. 单击**创建**。
|
||||
1. 点击 **Deployment**。
|
||||
1. 填写表单，或**以 YAML 文件编辑**。
|
||||
1. 单击**创建**。
|
||||
|
||||
要将 **Service** 添加到你的命名空间：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 点击**服务发现 > 服务**。
|
||||
1. 单击**创建**。
|
||||
1. 选择所需的服务类型。
|
||||
1. 填写表单，或**以 YAML 文件编辑**。
|
||||
1. 点击**创建**。
|
||||
|
||||
你还可以使用 kubectl **shell** 来创建 deployment 和 service：
|
||||
|
||||
1. 如果你的文件存储在本地集群中，运行 `kubectl create -f <name of service/deployment file>.yaml`。
|
||||
1. 或运行 `cat<< EOF | kubectl apply -f -`，将文件内容粘贴到终端，然后运行 `EOF` 来完成命令。
|
||||
|
||||
### 部署和服务示例
|
||||
|
||||
接下来，我们为 Istio 文档中的 BookInfo 应用的示例部署和服务添加 Kubernetes 资源：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在顶部导航栏中，打开 kubectl shell。
|
||||
1. 运行 `cat<< EOF | kubectl apply -f -`。
|
||||
1. 将以下资源复制到 shell 中。
|
||||
1. 运行 `EOF`。
|
||||
|
||||
这将在 Istio 的示例 BookInfo 应用中设置以下示例资源：
|
||||
|
||||
Details 服务和部署：
|
||||
|
||||
- 一个 `details` Service。
|
||||
- 一个 `bookinfo-details` 的 ServiceAccount。
|
||||
- 一个 `details-v1` Deployment。
|
||||
|
||||
Ratings 服务和部署：
|
||||
|
||||
- 一个 `ratings` Service。
|
||||
- 一个 `bookinfo-ratings` 的 ServiceAccount。
|
||||
- 一个 `ratings-v1` Deployment。
|
||||
|
||||
Reviews 服务和部署（三个版本）：
|
||||
|
||||
- 一个 `reviews` Service。
|
||||
- 一个 `bookinfo-reviews` 的 ServiceAccount。
|
||||
- 一个 `reviews-v1` Deployment。
|
||||
- 一个 `reviews-v2` Deployment。
|
||||
- 一个 `reviews-v3` Deployment。
|
||||
|
||||
Productpage 服务和部署：
|
||||
|
||||
这是应用的主页，可以通过网络浏览器中查看。将从该页面调用其他服务。
|
||||
|
||||
- 一个 `productpage` service。
|
||||
- 一个 `bookinfo-productpage` 的 ServiceAccount。
|
||||
- 一个 `productpage-v1` Deployment。
|
||||
|
||||
### 资源 YAML
|
||||
|
||||
```yaml
|
||||
# Copyright 2017 Istio Authors
|
||||
#
|
||||
# Licensed under the Apache License, Version 2.0 (the "License");
|
||||
# you may not use this file except in compliance with the License.
|
||||
# You may obtain a copy of the License at
|
||||
#
|
||||
# http://www.apache.org/licenses/LICENSE-2.0
|
||||
#
|
||||
# Unless required by applicable law or agreed to in writing, software
|
||||
# distributed under the License is distributed on an "AS IS" BASIS,
|
||||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
# See the License for the specific language governing permissions and
|
||||
# limitations under the License.
|
||||
|
||||
##################################################################################################
|
||||
# Details service
|
||||
##################################################################################################
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: details
|
||||
labels:
|
||||
app: details
|
||||
service: details
|
||||
spec:
|
||||
ports:
|
||||
- port: 9080
|
||||
name: http
|
||||
selector:
|
||||
app: details
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: bookinfo-details
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: details-v1
|
||||
labels:
|
||||
app: details
|
||||
version: v1
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: details
|
||||
version: v1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: details
|
||||
version: v1
|
||||
spec:
|
||||
serviceAccountName: bookinfo-details
|
||||
containers:
|
||||
- name: details
|
||||
image: docker.io/istio/examples-bookinfo-details-v1:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
##################################################################################################
|
||||
# Ratings service
|
||||
##################################################################################################
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: ratings
|
||||
labels:
|
||||
app: ratings
|
||||
service: ratings
|
||||
spec:
|
||||
ports:
|
||||
- port: 9080
|
||||
name: http
|
||||
selector:
|
||||
app: ratings
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: ratings-v1
|
||||
labels:
|
||||
app: ratings
|
||||
version: v1
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: ratings
|
||||
version: v1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: ratings
|
||||
version: v1
|
||||
spec:
|
||||
serviceAccountName: bookinfo-ratings
|
||||
containers:
|
||||
- name: ratings
|
||||
image: docker.io/istio/examples-bookinfo-ratings-v1:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
##################################################################################################
|
||||
# Reviews service
|
||||
##################################################################################################
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: reviews
|
||||
labels:
|
||||
app: reviews
|
||||
service: reviews
|
||||
spec:
|
||||
ports:
|
||||
- port: 9080
|
||||
name: http
|
||||
selector:
|
||||
app: reviews
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: bookinfo-reviews
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: reviews-v1
|
||||
labels:
|
||||
app: reviews
|
||||
version: v1
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: reviews
|
||||
version: v1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: reviews
|
||||
version: v1
|
||||
spec:
|
||||
serviceAccountName: bookinfo-reviews
|
||||
containers:
|
||||
- name: reviews
|
||||
image: docker.io/istio/examples-bookinfo-reviews-v1:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: reviews-v2
|
||||
labels:
|
||||
app: reviews
|
||||
version: v2
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: reviews
|
||||
version: v2
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: reviews
|
||||
version: v2
|
||||
spec:
|
||||
serviceAccountName: bookinfo-reviews
|
||||
containers:
|
||||
- name: reviews
|
||||
image: docker.io/istio/examples-bookinfo-reviews-v2:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: reviews-v3
|
||||
labels:
|
||||
app: reviews
|
||||
version: v3
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: reviews
|
||||
version: v3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: reviews
|
||||
version: v3
|
||||
spec:
|
||||
serviceAccountName: bookinfo-reviews
|
||||
containers:
|
||||
- name: reviews
|
||||
image: docker.io/istio/examples-bookinfo-reviews-v3:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
##################################################################################################
|
||||
# Productpage services
|
||||
##################################################################################################
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: productpage
|
||||
labels:
|
||||
app: productpage
|
||||
service: productpage
|
||||
spec:
|
||||
ports:
|
||||
- port: 9080
|
||||
name: http
|
||||
selector:
|
||||
app: productpage
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: bookinfo-productpage
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: productpage-v1
|
||||
labels:
|
||||
app: productpage
|
||||
version: v1
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: productpage
|
||||
version: v1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: productpage
|
||||
version: v1
|
||||
spec:
|
||||
serviceAccountName: bookinfo-productpage
|
||||
containers:
|
||||
- name: productpage
|
||||
image: docker.io/istio/examples-bookinfo-productpage-v1:1.15.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
```
|
||||
|
||||
### 后续步骤
|
||||
[设置 Istio Gateway](set-up-istio-gateway.md)
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: Pod 安全策略
|
||||
---
|
||||
|
||||
:::note
|
||||
|
||||
本文介绍的集群选项仅适用于 [Rancher 已在其中启动 Kubernetes 的集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)。
|
||||
|
||||
:::
|
||||
|
||||
你可以在创建项目的时候设置 Pod 安全策略（PSP）。如果在创建项目期间没有为项目分配 PSP，你也随时可以将 PSP 分配给现有项目。
|
||||
|
||||
### 先决条件
|
||||
|
||||
- 在 Rancher 中创建 Pod 安全策略。在将默认 PSP 分配给现有项目之前，你必须有一个可分配的 PSP。有关说明，请参阅[创建 Pod 安全策略](../../new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)。
|
||||
- 将默认 Pod 安全策略分配给项目所属的集群。如果 PSP 还没有应用到集群，你无法将 PSP 分配给项目。有关详细信息，请参阅[将 pod 安全策略添加到集群](../../new-user-guides/manage-clusters/add-a-pod-security-policy.md)。
|
||||
|
||||
### 应用 Pod 安全策略
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到需要移动命名空间的集群，然后单击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 找到要添加 PSP 的项目。在该项目中选择 **⋮ > 编辑配置**。
|
||||
1. 从 **Pod 安全策略**下拉列表中，选择要应用于项目的 PSP。
|
||||
将 PSP 分配给项目将：
|
||||
|
||||
- 覆盖集群的默认 PSP。
|
||||
- 将 PSP 应用于项目。
|
||||
- 将 PSP 应用到后续添加到项目中的命名空间。
|
||||
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：已将 PSP 应用到项目以及项目内的命名空间。
|
||||
|
||||
:::note
|
||||
|
||||
对于在分配 PSP 之前已经在集群或项目中运行工作负载，Rancher 不会检查它们是否符合 PSP。你需要克隆或升级工作负载以查看它们是否通过 PSP。
|
||||
|
||||
:::
|
||||
+67
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: Rancher 项目中资源配额的工作原理
|
||||
---
|
||||
|
||||
Rancher 中的资源配额包含与 [Kubernetes 原生版本](https://kubernetes.io/docs/concepts/policy/resource-quotas/)相同的功能。Rancher 还扩展了资源配额的功能，让你将资源配额应用于项目。
|
||||
|
||||
在标准 Kubernetes deployment 中，资源配额会应用于各个命名空间。但是，你不能通过单次操作将配额应用到多个命名空间，而必须多次应用资源配额。
|
||||
|
||||
在下图中，Kubernetes 管理员试图在没有 Rancher 的情况下强制执行资源配额。管理员想要使用一个资源配额来为集群中的每个命名空间配置统一的 CPU 和内存限制 (`Namespace 1-4`)。但是，在 Kubernetes 的基础版本中，每个命名空间都需要单独设置资源配额。因此，管理员必须创建四个配置相同规格的不同资源配额（`Resource Quota 1-4`）并单独应用这些配额。
|
||||
|
||||
<sup>Kubernetes 基础版本：每个命名空间都需要独立设置资源配额</sup>
|
||||
|
||||
|
||||
|
||||
和原生 Kubernetes 相比，Rancher 的资源配额有不同。在 Rancher 中，你可以把资源配额应用到项目层级，进而让项目的资源配额沿用到项目内的每一个命名空间，然后 Kubernetes 会使用原生的资源配额来强制执行你设置的限制。如果要更改特定命名空间的配额，你也可以覆盖设置。
|
||||
|
||||
项目配额包括你在创建或编辑集群时设置的两个限制：
|
||||
<a id="project-limits"></a>
|
||||
|
||||
- **项目限制**：
|
||||
|
||||
配置了项目中所有命名空间共享的每个指定资源的总限制。
|
||||
|
||||
- **命名空间默认限制**：
|
||||
|
||||
配置了每个命名空间对每个指定资源的默认配额。
|
||||
如果项目中的命名空间配置没有被覆盖，那么此限制会自动绑定到命名空间并强制执行。
|
||||
|
||||
|
||||
在下图中，Rancher 管理员想使用资源配额来为项目中的每个命名空间（`命名空间 1-4`）设置相同的 CPU 和内存限制。在 Rancher 中，管理员可以为项目设置资源配额（`项目资源配额`），而不需要为命名空间单独进行设置。此配额包括整个项目（`项目限制`）和单个命名空间（`命名空间默认限制`）的资源限制。然后，Rancher 会将`命名空间默认限制`的配额沿用到每个命名空间（`命名空间资源配额`）。
|
||||
|
||||
<sup>Rancher：资源配额沿用到每个命名空间</sup>
|
||||
|
||||
|
||||
|
||||
以下介绍在 Rancher UI **_中_** 创建的命名空间的更细微的功能。如果你删除了项目级别的资源配额，无论命名空间层级是否有自定义的资源配额，项目内的所有命名空间也会移除这个资源配额。在项目层级修改已有的命名空间默认资源配额，不会影响命名空间内的资源配额，修改后的项目层级资源配额只会对以后新建的命名空间生效。要修改多个现有命名空间的默认限制，你可以在项目层级删除该限制，然后再使用新的默认值重新创建配额。这种方式会将新的默认值应用于项目中的所有现有命名空间。
|
||||
|
||||
在项目中创建命名空间之前，Rancher 会使用默认限制和覆盖限制来对比项目内的可用资源和请求资源。
|
||||
如果请求的资源超过了项目中这些资源的剩余容量，Rancher 将为命名空间分配该资源的剩余容量。
|
||||
|
||||
但是，在 Rancher 的 UI **_外_** 创建的命名空间的处理方法则不一样。对于通过 `kubectl` 创建的命名空间，如果请求的资源量多余项目内的余量，Rancher 会分配一个数值为 **0** 的资源配额。
|
||||
|
||||
要使用 `kubectl` 在现有项目中创建命名空间，请使用 `field.cattle.io/projectId` 注释。要覆盖默认的请求配额限制，请使用 `field.cattle.io/resourceQuota` 注释。
|
||||
|
||||
请注意，Rancher 只会覆盖项目配额上定义的资源限制。
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
annotations:
|
||||
field.cattle.io/projectId: [your-cluster-ID]:[your-project-ID]
|
||||
field.cattle.io/resourceQuota: '{"limit":{"limitsCpu":"100m", "configMaps": "50"}}'
|
||||
name: my-ns
|
||||
```
|
||||
在此示例中，如果项目配额在其资源列表中不包含 configMaps，那么 Rancher 将忽略此覆盖中的 `configMaps`。
|
||||
|
||||
对于项目中未定义的资源，建议你在命名空间中创建专用的 `ResourceQuota` 对象来配置其它自定义限制。
|
||||
资源配额是原生 Kubernetes 对象，如果命名空间属于具有配额的项目，Rancher 将忽略用户定义的配额，从而给予用户更多的控制权。
|
||||
|
||||
下表对比了 Rancher 和 Kubernetes 资源配额的主要区别：
|
||||
|
||||
| Rancher 资源配额 | Kubernetes 资源配额 |
|
||||
| ---------------------------------------------------------- | -------------------------------------------------------- |
|
||||
| 应用于项目和命名空间。 | 仅应用于命名空间。 |
|
||||
| 为项目中的所有命名空间创建资源池。 | 将静态资源限制应用到单独的命名空间。 |
|
||||
| 通过沿用的模式，将资源配额应用于各个命名空间。 | 仅应用于指定的命名空间。 |
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: 项目资源配额
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas"/>
|
||||
</head>
|
||||
|
||||
如果多个团队共享一个集群，某个团队可能会使用过多的可用资源，例如 CPU、内存、存储、服务、Kubernetes 对象（如 Pod 或 Secret）等。你可以应用 _资源配额_ 来防止过度消耗资源。资源配额是 Rancher 用来限制项目或命名空间可用资源的功能。
|
||||
|
||||
本文介绍如何在现有项目中创建资源配额。
|
||||
|
||||
你也可以在创建新项目时设置资源配额。有关详细信息，请参阅[创建新项目](../../../new-user-guides/manage-clusters/projects-and-namespaces.md#创建项目)。
|
||||
|
||||
Rancher 中的资源配额包含与 [Kubernetes 原生版本](https://kubernetes.io/docs/concepts/policy/resource-quotas/)相同的功能。Rancher 还扩展了资源配额的功能，从而让你将资源配额应用于项目。有关资源配额如何与 Rancher 中的项目一起使用的详细信息，请参阅[此页面](about-project-resource-quotas.md)。
|
||||
|
||||
### 将资源配额应用于现有项目
|
||||
|
||||
修改资源配额的使用场景如下：
|
||||
|
||||
- 限制某个项目和项目下的命名空间能使用的资源
|
||||
- 在资源配额已生效的情况下，对项目可用的资源进行扩容或缩容
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面，进入要应用资源配额的集群，然后单击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 确保 **Projects/Namespaces** 页面处于 **Group by Project** 视图模式。
|
||||
|
||||
|
||||
1. 找到要添加资源配额的项目，选择与项目名称同行的 **⋮**。
|
||||
|
||||
|
||||
1. 选择**编辑配置**。
|
||||
|
||||
1. 展开**资源限额**并单击**添加资源**。你也可以编辑现有配额。
|
||||
|
||||
1. 选择资源类型。有关类型的更多信息，请参阅[配额类型参考](resource-quota-types.md)。
|
||||
|
||||
1. 输入**项目限制**和**命名空间默认限制**的值。
|
||||
|
||||
| 字段 | 描述 |
|
||||
| ----------------------- | -------------------------------------------------------------------------------------------------------- |
|
||||
| 项目限制 | 项目的总资源限制。 |
|
||||
| 命名空间默认限制 | 每个命名空间的默认资源限制。此限制会沿用到项目中的每个命名空间。项目中所有命名空间的限制之和不应超过项目限制。 |
|
||||
|
||||
1. **可选**：添加更多配额。
|
||||
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：资源配额已应用到你的项目和命名空间。如果你后续需要添加更多命名空间，Rancher 会验证项目是否可以容纳该命名空间。如果项目无法分配资源，你仍然可以创建命名空间，但命名空间将获得的资源配额为 0。然后 Rancher 将不允许你创建任何受此配额限制的资源。
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: 覆盖命名空间的默认限制
|
||||
---
|
||||
|
||||
**命名空间默认限制**会在创建时从项目沿用到每个命名空间。但在某些情况下，你可能需要增加或减少特定命名空间的配额。在这种情况下，你可以通过编辑命名空间来覆盖默认限制。
|
||||
|
||||
在下图中，Rancher 管理员的项目有一个已生效的资源配额。但是，管理员想要覆盖 `Namespace 3` 的命名空间限制，以便让该命名空间使用更多资源。因此，管理员[提高了 `Namespace 3` 的命名空间限制](../../../new-user-guides/manage-clusters/projects-and-namespaces.md)，以便命名空间可以访问更多资源。
|
||||
|
||||
<sup>命名空间默认限制覆盖</sup>
|
||||
|
||||
|
||||
|
||||
有关详细信息，请参阅[如何编辑命名空间资源配额](../../../new-user-guides/manage-clusters/projects-and-namespaces.md)。
|
||||
|
||||
### 编辑命名空间资源配额
|
||||
|
||||
如果你已为项目配置了资源配额，你可以覆盖命名空间默认限制，从而为特定命名空间提供对更多（或更少）项目资源的访问权限：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要编辑命名空间资源配额的集群，然后单击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 找到要为其编辑资源配额的命名空间。单击 **⋮ > 编辑配置**。
|
||||
1. 编辑资源限制。这些限制决定了命名空间可用的资源。必须在项目限制范围内配置这些配额限制。
|
||||
|
||||
有关每个**资源类型**的详细信息，请参阅[类型参考](resource-quota-types.md)。
|
||||
|
||||
:::note
|
||||
|
||||
- 如果没有为项目配置资源配额，这些选项将不可用。
|
||||
- 如果你输入的限制超过了配置的项目限制，你将无法保存修改。
|
||||
|
||||
:::
|
||||
|
||||
**结果**：覆盖设置已经应用到命名空间的资源配额。
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: 资源配额类型参考
|
||||
---
|
||||
|
||||
创建资源配额相当于配置项目可用的资源池。你可以为以下资源类型设置资源配额：
|
||||
|
||||
| 资源类型 | 描述 |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| CPU 限制\* | 分配给项目/命名空间的最大 CPU 量（以[毫核](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)为单位）<sup>1</sup> |
|
||||
| CPU 预留\* | 预留给项目/命名空间的最小 CPU 量（以毫核为单位）<sup>1</sup> |
|
||||
| 内存限制\* | 分配给项目/命名空间的最大内存量（以字节为单位）<sup>1</sup> |
|
||||
| 内存预留\* | 预留给项目/命名空间的最小内存量（以字节为单位）<sup>1</sup> |
|
||||
| 存储预留 | 预留给项目/命名空间的最小存储量（以千兆字节为单位） |
|
||||
| 服务负载均衡器 | 项目/命名空间中可以存在的负载均衡器服务的最大数量 |
|
||||
| 服务节点端口 | 项目/命名空间中可以存在的节点端口服务的最大数量 |
|
||||
| Pod | 可以在项目/命名空间中以非终端状态存在的 pod 的最大数量（即 `.status.phase in (Failed, Succeeded)` 等于 true 的 pod） |
|
||||
| Services | 项目/命名空间中可以存在的最大 service 数量 |
|
||||
| ConfigMap | 项目/命名空间中可以存在的 ConfigMap 的最大数量 |
|
||||
| 持久卷声明 | 项目/命名空间中可以存在的持久卷声明的最大数量 |
|
||||
| ReplicationController | 项目/命名空间中可以存在的最大 ReplicationController 数量 |
|
||||
| 密文 | 项目/命名空间中可以存在的最大密文数量 |
|
||||
|
||||
:::note **<sup>*</sup>**
|
||||
|
||||
在设置资源配额时，如果你在项目或命名空间上设置了任何与 CPU 或内存相关的内容（即限制或预留），所有容器都需要在创建期间设置各自的 CPU 或内存字段。你可以同时设置容器的默认资源限制，以避免为每个工作负载显式设置这些限制。详情请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits)。
|
||||
|
||||
:::
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: 设置容器默认资源限制
|
||||
---
|
||||
|
||||
在设置资源配额时，如果你在项目或命名空间上设置了任何与 CPU 或内存相关的内容（即限制或预留），所有容器都需要在创建期间设置各自的 CPU 或内存字段。详情请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits)。
|
||||
|
||||
为了避免在创建工作负载期间对每个容器设置这些限制，可以在命名空间上指定一个默认的容器资源限制。
|
||||
|
||||
### 编辑容器默认资源限制
|
||||
|
||||
你可以在以下情况下编辑容器的默认资源限制：
|
||||
|
||||
- 你在项目上设置了 CPU 或内存资源配额，现在需要为容器设置相应的默认值。
|
||||
- 你需要编辑容器的默认资源限制。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要编辑默认资源限制的集群，然后单击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 找到要编辑容器默认资源限制的项目。在该项目中选择 **⋮ > 编辑配置**。
|
||||
1. 展开**容器默认资源限制**并编辑对应的值。
|
||||
|
||||
### 沿用资源限制
|
||||
|
||||
在项目级别设置默认容器资源限制后，项目中所有新建的命名空间都会沿用这个资源限制参数。新设置的限制不会影响项目中现有的命名空间。你需要为项目中的现有命名空间手动设置默认容器资源限制，以便创建容器时能应用该限制。
|
||||
|
||||
你可以为项目设置容器的默认资源限制并启动任何商店应用。
|
||||
|
||||
在命名空间上配置容器默认资源限制后，在该命名空间中创建的任何容器都会沿用该默认值。你可以在工作负载创建期间覆盖这些限制/预留。
|
||||
|
||||
### 容器资源配额类型
|
||||
|
||||
可以配置以下资源限制：
|
||||
|
||||
| 资源类型 | 描述 |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| CPU 限制 | 分配给容器的最大 CPU 量（以[毫核](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)为单位）。 |
|
||||
| CPU 预留 | 保留给容器的最小 CPU 量（以毫核为单位）。 |
|
||||
| 内存限制 | 分配给容器的最大内存量（以字节为单位）。 |
|
||||
| 内存预留 | 保留给容器的最小内存量（以字节为单位）。 |
|
||||
| NVIDIA GPU 限制/预留 | 分配给容器的 GPU 数量。GPU 的限制和预留始终相同。 |
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: 项目管理
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/manage-projects"/>
|
||||
</head>
|
||||
|
||||
_项目_ 是 Rancher 中引入的对象，可帮助你更有组织地管理 Kubernetes 集群中的命名空间。你可以使用项目创建多租户集群，这种集群允许一组用户共享相同的底层资源来创建应用，而应用之间不会相互影响。
|
||||
|
||||
在层次结构方面：
|
||||
|
||||
- 集群包含项目
|
||||
- 项目包含命名空间
|
||||
|
||||
在 Rancher 中，你可以使用项目将多个命名空间作为一个实体进行管理。在原生 Kubernetes（没有项目这个概念）中，RBAC 或集群资源等功能被分配给了各个命名空间。如果集群中的多个命名空间需要分配同样的访问权限，分配权限会变得非常繁琐。即使所有命名空间都需要相同的权限，但也无法使用一个操作中将这些权限应用于所有命名空间。你必须重复地将这些权限分配给每个命名空间。
|
||||
|
||||
而 Rancher 通过引入项目的概念，通过允许你在项目级别应用资源和访问权限。然后，项目中的每个命名空间都会继承这些资源和策略。因此你只需将资源和策略分配给项目即可，不需要将它们分配给每个单独的命名空间。
|
||||
|
||||
你可以使用项目执行以下操作：
|
||||
|
||||
- [为用户分配一组命名空间的访问权限](../../new-user-guides/add-users-to-projects.md)
|
||||
- 为用户分配[项目中的特定角色](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)。角色可以是所有者、成员、只读或[自定义](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md)
|
||||
- [设置资源配额](manage-project-resource-quotas/manage-project-resource-quotas.md)
|
||||
- [管理命名空间](../../new-user-guides/manage-namespaces.md)
|
||||
- [配置工具](../../../reference-guides/rancher-project-tools.md)
|
||||
- [配置 Pod 安全策略](manage-pod-security-policies.md)
|
||||
|
||||
### 授权
|
||||
|
||||
非管理者用户只有在[管理员](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)、[集群所有者或成员](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#集群角色)或[项目所有者](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)将非管理员用户添加到项目的**成员**选项卡后，才能获取项目的访问权限。
|
||||
|
||||
创建项目的人自动成为[项目所有者](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)。
|
||||
|
||||
## 在项目之间切换
|
||||
|
||||
要在项目之间切换，请使用导航栏中的下拉菜单。你也可以直接在导航栏中切换项目：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面，进入要切换项目的集群然后点击 **Explore**。
|
||||
1. 在顶部导航栏中，选择要打开的项目。
|
||||
+148
@@ -0,0 +1,148 @@
|
||||
---
|
||||
title: 持久化 Grafana 仪表板
|
||||
---
|
||||
|
||||
要在重启 Grafana 实例后保存 Grafana 仪表板，请将仪表板的配置 JSON 添加到 ConfigMap 中。ConfigMap 还支持使用基于 GitOps 或 CD 的方法来部署仪表板，从而让你对仪表板进行版本控制。
|
||||
|
||||
- [创建持久化 Grafana 仪表板](#创建持久化-grafana-仪表板)
|
||||
- [已知问题](#已知问题)
|
||||
|
||||
## 创建持久化 Grafana 仪表板
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
- 已安装 Monitoring 应用。
|
||||
- 要创建持久化仪表板，你必须在包含 Grafana 仪表板的项目或命名空间中至少具有**管理 ConfigMap** 的 Rancher RBAC 权限。这与 Monitoring Chart 公开的 `monitoring-dashboard-edit` 或 `monitoring-dashboard-admin` Kubernetes 原生 RBAC 角色对应。
|
||||
- 要查看指向外部监控 UI（包括 Grafana 仪表板）的链接，你至少需要一个 [project-member 角色](../../../integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md#具有-rancher-权限的用户)。
|
||||
|
||||
:::
|
||||
|
||||
### 1. 获取要持久化的仪表板的 JSON 模型
|
||||
|
||||
要创建持久化仪表板，你需要获取要持久化的仪表板的 JSON 模型。你可以使用预制仪表板或自行构建仪表板。
|
||||
|
||||
要使用预制仪表板，请转到 [https://grafana.com/grafana/dashboards](https://grafana.com/grafana/dashboards)，打开详细信息页面，然后单击 **Download JSON** 按钮来获取下一步所需的 JSON 模型。
|
||||
|
||||
要使用你自己的仪表板：
|
||||
|
||||
1. 点击链接打开 Grafana。在集群详细信息页面上，单击 **Monitoring**。
|
||||
1. 登录到 Grafana。请注意，Grafana 实例的默认 Admin 用户名和密码是 `admin/prom-operator`。你还可以在部署或升级 Chart 时替换凭证。
|
||||
|
||||
:::note
|
||||
|
||||
无论谁拥有密码，你都需要在部署了 Rancher Monitoring 的项目中至少具有<b>管理服务</b>或<b>查看监控</b>的权限才能访问 Grafana 实例。你还可以在部署或升级 Chart 时替换凭证。
|
||||
|
||||
:::
|
||||
|
||||
1. 使用 Grafana UI 创建仪表板。完成后，单击顶部导航菜单中的齿轮图标转到仪表板设置页面。在左侧导航菜单中，单击 **JSON Model**。
|
||||
1. 复制出现的 JSON 数据结构。
|
||||
|
||||
### 2. 使用 Grafana JSON 模型创建 ConfigMap
|
||||
|
||||
在包含 Grafana 仪表板的命名空间中创建一个 ConfigMap（默认为 cattle-dashboards ）。
|
||||
|
||||
ConfigMap 与以下内容类似：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
labels:
|
||||
grafana_dashboard: "1"
|
||||
name: <dashboard-name>
|
||||
namespace: cattle-dashboards # 如果不使用默认命名空间，则修改此值
|
||||
data:
|
||||
<dashboard-name>.json: |-
|
||||
<copied-json>
|
||||
```
|
||||
|
||||
默认情况下，Grafana 配置为监控 `cattle-dashboards` 命名空间中带有 `grafana_dashboard` 标签的所有 ConfigMap。
|
||||
|
||||
要让 Grafana 监控所有命名空间中的 ConfigMap，请参阅[本节](#为-grafana-仪表板-configmap-配置命名空间)。
|
||||
|
||||
要在 Rancher UI 中创建 ConfigMap：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要可视化的集群，然后单击 **Explore**。
|
||||
1. 单击**更多资源 > 核心 > 配置映射**。
|
||||
1. 单击**创建**。
|
||||
1. 设置与上例类似的键值对。输入 `<dashboard-name>.json` 的值时，点击**从文件读取**并上传 JSON 数据模型。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：创建 ConfigMap 后，即使 Grafana pod 重启了，ConfigMap 也能显示在 Grafana UI 上并持久化。
|
||||
|
||||
无法在 Grafana UI 中删除或编辑使用 ConfigMap 持久化了的仪表板。
|
||||
|
||||
如果你在 Grafana UI 中删除仪表板，你将看到 "Dashboard cannot be deleted because it was provisioned" 的错误消息。如需删除仪表板，你需要删除 ConfigMap。
|
||||
|
||||
### 为 Grafana 仪表板 ConfigMap 配置命名空间
|
||||
|
||||
要让 Grafana 监控所有命名空间中的 ConfigMap，请在 `rancher-monitoring` Helm chart 中指定以下值：
|
||||
|
||||
```
|
||||
grafana.sidecar.dashboards.searchNamespace=ALL
|
||||
```
|
||||
|
||||
请注意，Monitoring Chart 用于添加 Grafana 仪表板的 RBAC 角色仅能让用户将仪表板添加到定义在 `grafana.dashboards.namespace` 中的命名空间，默认为 `cattle-dashboards`。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher 版本低于 v2.5.8">
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
- 已安装 Monitoring 应用。
|
||||
- 你必须具有 cluster-admin ClusterRole 权限。
|
||||
|
||||
:::
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要在其中配置 Grafana 命名空间的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**监控**。
|
||||
1. 点击 **Grafana**。
|
||||
1. 登录到 Grafana。请注意，Grafana 实例的默认 Admin 用户名和密码是 `admin/prom-operator`。你还可以在部署或升级 Chart 时替换凭证。
|
||||
|
||||
:::note
|
||||
|
||||
无论谁拥有密码，都需要 Rancher 的集群管理员权限才能访问 Grafana 实例。
|
||||
|
||||
:::
|
||||
|
||||
1. 转到要进行持久化的仪表板。在顶部导航菜单中，通过单击齿轮图标转到仪表板设置。
|
||||
1. 在左侧导航菜单中，单击 **JSON Model**。
|
||||
1. 复制出现的 JSON 数据结构。
|
||||
1. 在 `cattle-dashboards` 命名空间中创建一个 ConfigMap。ConfigMap 需要有 `grafana_dashboard: "1"` 标签。将 JSON 粘贴到 ConfigMap 中，格式如下例所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
labels:
|
||||
grafana_dashboard: "1"
|
||||
name: <dashboard-name>
|
||||
namespace: cattle-dashboards
|
||||
data:
|
||||
<dashboard-name>.json: |-
|
||||
<copied-json>
|
||||
```
|
||||
|
||||
**结果**：创建 ConfigMap 后，即使 Grafana pod 重启了，ConfigMap 也能显示在 Grafana UI 上并持久化。
|
||||
|
||||
无法在 Grafana UI 中删除使用 ConfigMap 持久化了的仪表板。如果你在 Grafana UI 中删除仪表板，你将看到 "Dashboard cannot be deleted because it was provisioned" 的错误消息。如需删除仪表板，你需要删除 ConfigMap。
|
||||
|
||||
为防止在卸载 Monitoring v2 时删除持久化的仪表板，请将以下注释添加到 `cattle-dashboards` 命名空间：
|
||||
|
||||
```
|
||||
helm.sh/resource-policy: "keep"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 已知问题
|
||||
|
||||
如果你的 Monitoring V2 版本是 v9.4.203 或更低版本，卸载 Monitoring chart 将同时删除 `cattle-dashboards` 命名空间，所有持久化的仪表板将被删除（除非命名空间带有注释 `helm.sh/resource-policy: "keep"`）。
|
||||
|
||||
Rancher 2.5.8 发布的新 Monitoring Chart 中默认添加了该注解，但使用早期 Rancher 版本的用户仍需手动应用该注释。
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: 自定义 Grafana 仪表板
|
||||
---
|
||||
|
||||
在本文中，你将学习通过自定义 Grafana 仪表板来显示特定容器的指标。
|
||||
|
||||
### 先决条件
|
||||
|
||||
在自定义 Grafana 仪表板之前，你必须先安装 `rancher-monitoring` 应用。
|
||||
|
||||
要查看指向外部监控 UI（包括 Grafana 仪表板）的链接，你至少需要一个 [project-member 角色](../../../integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md#具有-rancher-权限的用户)。
|
||||
|
||||
### 登录 Grafana
|
||||
|
||||
1. 在 Rancher UI 中，转到要自定义的仪表板的集群。
|
||||
1. 在左侧导航栏中，单击**监控**。
|
||||
1. 单击 **Grafana**。Grafana 仪表板将在新选项卡中打开。
|
||||
1. 转到左下角的登录图标，然后单击 **Sign In**。
|
||||
1. 登录到 Grafana。Grafana 实例的默认 Admin 用户名和密码是 `admin/prom-operator`（无论谁拥有密码，都需要 Rancher 的集群管理员权限才能访问 Grafana 实例）。你还可以在部署或升级 Chart 时替换凭证。
|
||||
|
||||
|
||||
### 获取支持 Grafana 面板的 PromQL 查询
|
||||
|
||||
对于任何面板，你可以单击标题并单击 **Explore** 以获取支持图形的 PromQL 查询。
|
||||
|
||||
例如，如果要获取 Alertmanager 容器的 CPU 使用率，点击 **CPU Utilization > Inspect**。
|
||||
|
||||
**Data** 选项卡将基础数据显示为时间序列，第一列是时间，第二列是 PromQL 查询结果。复制 PromQL 查询。
|
||||
|
||||
```
|
||||
(1 - (avg(irate({__name__=~"node_cpu_seconds_total|windows_cpu_time_total",mode="idle"}[5m])))) * 100
|
||||
```
|
||||
|
||||
然后，你可以在 Grafana 面板中修改查询，或使用该查询创建新的 Grafana 面板。
|
||||
|
||||
参考：
|
||||
|
||||
- [编辑面板的 Grafana 文档](https://grafana.com/docs/grafana/latest/panels-visualizations/configure-panel-options/#edit-a-panel)
|
||||
- [向仪表板添加面板的 Grafana 文档](https://grafana.com/docs/grafana/latest/panels-visualizations/panel-editor-overview)
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: 调试高内存用量
|
||||
---
|
||||
|
||||
Prometheus 中的每个时间序列都由其[指标名称](https://prometheus.io/docs/practices/naming/#metric-names)和称为[标签](https://prometheus.io/docs/practices/naming/#labels)的可选键值对唯一标识。
|
||||
|
||||
标签允许过滤和聚合时间序列数据，但它们也使 Prometheus 收集的数据量成倍增加。
|
||||
|
||||
每个时间序列都有一组定义的标签，Prometheus 为所有唯一的标签组合生成一个新的时间序列。如果一个指标附加了两个标签，则会为该指标生成两个时间序列。更改任何标签值，包括添加或删除标签，都会创建一个新的时间序列。
|
||||
|
||||
Prometheus 经过了优化，可以存储基于索引的序列数据。它是为相对一致的时间序列数量和相对大量的样本而设计的，这些样本需要随时间从 exporter 处收集。
|
||||
|
||||
但是，Prometheus 没有就快速变化的时间序列数量进行对应的优化。因此，如果你在创建和销毁了大量资源的集群（尤其是多租户集群）上安装 Monitoring，可能会出现内存使用量激增的情况。
|
||||
|
||||
### 减少内存激增
|
||||
|
||||
为了减少内存消耗，Prometheus 可以通过抓取更少的指标或在时间序列上添加更少的标签，从而存储更少的时间序列。要查看使用内存最多的序列，你可以查看 Prometheus UI 中的 TSDB（时序数据库）状态页面。
|
||||
|
||||
分布式 Prometheus 解决方案（例如 [Thanos](https://thanos.io/) 和 [Cortex](https://cortexmetrics.io/)）使用了一个替代架构，该架构部署多个小型 Prometheus 实例。如果使用 Thanos，每个 Prometheus 的指标都聚合到通用的 Thanos 部署中，然后再将这些指标导出到 S3 之类的持久存储。这种架构更加健康，能避免给单个 Prometheus 实例带来过多时间序列，同时还能在全局级别查询指标。
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: 启用 Monitoring
|
||||
---
|
||||
|
||||
[管理员](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)或[集群所有者](../../new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#集群角色)可以通过配置 Rancher 来部署 Prometheus，从而监控 Kubernetes 集群。
|
||||
|
||||
本文介绍如何使用新的 monitoring 应用在集群内启用监控和告警。
|
||||
|
||||
不论是否使用 SSL，你都可以启用 monitoring。
|
||||
|
||||
## 要求
|
||||
|
||||
- 在每个节点上允许端口 9796 上的流量。Prometheus 将从这些端口抓取指标。
|
||||
- 如果 [PushProx](../../../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#pushprox) 被禁用（`ingressNginx.enabled` 设置为 `false`），或者你已经升级了安装了 Monitoring V1 的 Rancher 版本，你可能还需要为每个节点允许端口 10254 上的流量。
|
||||
- 确保你的集群满足资源要求。集群应至少有 1950Mi 可用内存、2700m CPU 和 50Gi 存储。有关资源限制和请求的详细信息，请参阅[配置资源限制和请求](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#配置资源限制和请求)。
|
||||
- 在使用 RancherOS 或 Flatcar Linux 节点的 RKE 集群上安装 Monitoring 时，请将 etcd 节点证书目录更改为 `/opt/rke/etc/kubernetes/ssl`。
|
||||
- 如果集群是使用 RKE CLI 配置的，而且地址设置为主机名而不是 IP 地址，请在安装的 Values 配置步骤中将 `rkeEtcd.clients.useLocalhost` 设置为 `true`。例如：
|
||||
|
||||
```yaml
|
||||
rkeEtcd:
|
||||
clients:
|
||||
useLocalhost: true
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
如果要设置 Alertmanager、Grafana 或 Ingress，必须通过 Helm chart 部署上的设置来完成。在部署之外创建 Ingress 可能会产生问题。
|
||||
|
||||
:::
|
||||
|
||||
## 设置资源限制和请求
|
||||
|
||||
安装 `rancher-monitoring` 时可以配置资源请求和限制。要从 Rancher UI 配置 Prometheus 资源，请单击左上角的 **Apps > Monitoring**。
|
||||
|
||||
有关默认限制的更多信息，请参阅[此页面](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#配置资源限制和请求)。
|
||||
|
||||
## 安装 Monitoring 应用
|
||||
|
||||
### 在不使用 SSL 的情况下启用 Monitoring
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 点击**集群工具**（左下角）。
|
||||
1. 单击 Monitoring 的**安装**。
|
||||
1. 可选：在 Values 步骤中为 Alerting、Prometheus 和 Grafana 自定义请求、限制等。如需帮助，请参阅[配置参考](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md)。
|
||||
|
||||
**结果**：Monitoring 应用已部署到 `cattle-monitoring-system` 命名空间中。
|
||||
|
||||
### 在使用 SSL 的情况下启用 Monitoring
|
||||
|
||||
1. 按照[此页面](../../new-user-guides/kubernetes-resources-setup/secrets.md)上的步骤创建密文，以便将 SSL 用于告警。
|
||||
- 密文应该创建到 `cattle-monitoring-system` 命名空间中。如果它不存在，请先创建它。
|
||||
- 将 `ca`、`cert` 和 `key` 文件添加到密文中。
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要启用 Monitoring 以与 SSL 一起使用的集群，然后单击 **Explore**。
|
||||
1. 单击 **Apps > Charts**。
|
||||
1. 单击 **Monitoring**。
|
||||
1. 根据你是否已安装 Monitoring，单击**安装**或**更新**。
|
||||
1. 选中**在安装前自定义 Helm 选项**，然后单击**下一步**。
|
||||
1. 单击 **Alerting**。
|
||||
1. 在**补充密文**字段中，添加之前创建的密文。
|
||||
|
||||
**结果**：Monitoring 应用已部署到 `cattle-monitoring-system` 命名空间中。
|
||||
|
||||
[创建接收器](../../../reference-guides/monitoring-v2-configuration/receivers.md#在-rancher-ui-中创建接收器)时，启用 SSL 的接收器（例如电子邮件或 webhook）将具有 **SSL**，其中包含 **CA 文件路径**、**证书文件路径**和**密钥文件路径**字段。使用 `ca`、`cert` 和 `key` 的路径填写这些字段。路径的格式为 `/etc/alertmanager/secrets/name-of-file-in-secret`。
|
||||
|
||||
例如，如果你使用以下键值对创建了一个密文：
|
||||
|
||||
```yaml
|
||||
ca.crt=`base64-content`
|
||||
cert.pem=`base64-content`
|
||||
key.pfx=`base64-content`
|
||||
```
|
||||
|
||||
则**证书文件路径**需要设为 `/etc/alertmanager/secrets/cert.pem`。
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: Monitoring/Alerting 指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/monitoring-alerting-guides"/>
|
||||
</head>
|
||||
|
||||
- [启用 Monitoring](enable-monitoring.md)
|
||||
- [卸载 Monitoring](uninstall-monitoring.md)
|
||||
- [为工作负载设置 Monitoring](set-up-monitoring-for-workloads.md)
|
||||
- [自定义 Grafana 仪表板](customize-grafana-dashboard.md)
|
||||
- [持久化 Grafana 仪表板](create-persistent-grafana-dashboard.md)
|
||||
- [调试高内存用量](debug-high-memory-usage.md)
|
||||
|
||||
+7
@@ -0,0 +1,7 @@
|
||||
---
|
||||
title: 自定义 Grafana 仪表板
|
||||
---
|
||||
|
||||
无论是用于 rancher-monitoring 还是 Prometheus Federator，Grafana 仪表板的定制方式都是相同的。
|
||||
|
||||
有关说明，请参阅[此页面](../customize-grafana-dashboard.md)。
|
||||
+86
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: 启用 Prometheus Federator
|
||||
---
|
||||
|
||||
## 要求
|
||||
|
||||
默认情况下，Prometheus Federator 已配置并旨在与 [rancher-monitoring](../../../../pages-for-subheaders/monitoring-and-alerting.md) 一起部署。rancher-monitoring 同时部署了 Prometheus Operator 和 Cluster Prometheus，每个项目监控堆栈（Project Monitoring Stack）默认会联合命名空间范围的指标。
|
||||
|
||||
有关安装 rancher-monitoring 的说明，请参阅[此页面](../enable-monitoring.md)。
|
||||
|
||||
默认配置与你的 rancher-monitoring 堆栈是兼容的。但是，为了提高集群中 Prometheus Federator 的安全性和可用性，我们建议对 rancher-monitoring 进行以下额外的配置：
|
||||
|
||||
- [确保 cattle-monitoring-system 命名空间位于 System 项目中](#确保-cattle-monitoring-system-命名空间位于-system-项目中或者位于一个锁定并能访问集群中其他项目的项目中)
|
||||
- [将 rancher-monitoring 配置为仅监视 Helm Chart 创建的资源](#将-rancher-monitoring-配置为仅监视-helm-chart-创建的资源)
|
||||
- [提高 Cluster Prometheus 的 CPU/内存限制](#提高-cluster-prometheus-的-cpu内存限制)
|
||||
|
||||
### 确保 cattle-monitoring-system 命名空间位于 System 项目中（或者位于一个锁定并能访问集群中其他项目的项目中）
|
||||
|
||||
|
||||
|
||||
Prometheus Operator 的安全模型有一定的要求，即希望部署它的命名空间（例如，`cattle-monitoring-system`）对除集群管理员之外的任何用户都只有有限的访问权限，从而避免通过 Pod 内执行（例如正在执行的 Helm 操作的 Job）来提升权限。此外，如果将 Prometheus Federator 和所有 Project Prometheus 堆栈都部署到 System 项目中，即使网络策略是通过项目网络隔离定义的，每个 Project Prometheus 都依然能够在所有项目中抓取工作负载。它还为项目所有者、项目成员和其他用户提供有限的访问权限，从而确保这些用户无法访问他们不应访问的数据（例如，在 pod 中执行，在项目外部抓取命名空间数据等）。
|
||||
|
||||
1. 打开 `System` 项目以检查你的命名空间：
|
||||
|
||||
在 Rancher UI 中单击 **Cluster > Projects/Namespaces**。这将显示 `System` 项目中的所有命名空间：
|
||||
|
||||
|
||||
|
||||
1. 如果你在 `cattle-monitoring-system` 命名空间中已经安装了一个 Monitoring V2，但该命名空间不在 `System` 项目中，你可以将 `cattle- monitoring-system` 命名空间移动到 `System` 项目或另一个访问受限的项目中。为此，你有以下两种方法：
|
||||
|
||||
- 将命名空间拖放到 `System` 项目。
|
||||
- 选择命名空间右侧的 **⋮**，点击 **Move**，然后从 **Target Project** 下拉列表中选择 `System`：
|
||||
|
||||
|
||||
|
||||
### 将 rancher-monitoring 配置为仅监视 Helm Chart 创建的资源
|
||||
|
||||
每个项目监控堆栈都会监视其他命名空间并收集其他自定义工作负载指标或仪表板。因此，我们建议在所有选择器上配置以下设置，以确保 Cluster Prometheus 堆栈仅监控由 Helm Chart 创建的资源：
|
||||
|
||||
```
|
||||
matchLabels:
|
||||
release: "rancher-monitoring"
|
||||
```
|
||||
|
||||
建议为以下选择器字段赋予此值：
|
||||
- `.Values.alertmanager.alertmanagerSpec.alertmanagerConfigSelector`
|
||||
- `.Values.prometheus.prometheusSpec.serviceMonitorSelector`
|
||||
- `.Values.prometheus.prometheusSpec.podMonitorSelector`
|
||||
- `.Values.prometheus.prometheusSpec.ruleSelector`
|
||||
- `.Values.prometheus.prometheusSpec.probeSelector`
|
||||
|
||||
启用此设置后，你始终可以通过向它们添加 `release: "rancher-monitoring"` 标签来创建由 Cluster Prometheus 抓取的 ServiceMonitor 或 PodMonitor。在这种情况下，即使这些 ServiceMonitor 或 PodMonitor 所在的命名空间不是 System 命名空间，项目监控堆栈也会默认自动忽略它们。
|
||||
|
||||
:::note
|
||||
|
||||
如果你不希望用户能够在 Project 命名空间中创建聚合到 Cluster Prometheus 中的 ServiceMonitor 和 PodMonitor，你可以另外将 Chart 上的 namespaceSelectors 设置为仅目标 System 命名空间（必须包含 `cattle-monitoring-system` 和 `cattle-dashboards`，默认情况下资源通过 rancher-monitoring 部署到该命名空间中。你还需要监控 `default` 命名空间以获取 apiserver 指标，或创建自定义 ServiceMonitor 以抓取位于 `default` 命名空间中的 Service 的 apiserver 指标），从而限制你的 Cluster Prometheus 获取其他 Prometheus Operator CR。在这种情况下，建议设置 `.Values.prometheus.prometheusSpec.ignoreNamespaceSelectors=true`。这样，你可以定义能从 System 命名空间中监视非 System 命名空间的 ServiceMonitor。
|
||||
|
||||
:::
|
||||
|
||||
### 提高 Cluster Prometheus 的 CPU/内存限制
|
||||
|
||||
根据集群的设置，我们一般建议为 Cluster Prometheus 配置大量的专用内存，以避免因内存不足的错误（OOMKilled）而重启。通常情况下，集群中创建的改动项（churn）会导致大量高基数指标在一个时间块内生成并被 Prometheus 引入，然后导致这些错误。这也是为什么默认的 Rancher Monitoring 堆栈希望能分配到大约 4GB 的 RAM 以在正常大小的集群中运行的原因之一。但是，如果你引入向同一个 Cluster Prometheus 发送 `/federate` 请求的项目监控堆栈，并且项目监控堆栈依赖于 Cluster Prometheus 的启动状态来在其命名空间上联合系统数据，那么你更加需要为 Cluster Prometheus 分配足够的 CPU/内存，以防止集群中的所有 Prometheus 项目出现数据间隙的中断。
|
||||
|
||||
:::note
|
||||
|
||||
我们没有 Cluster Prometheus 内存配置的具体建议，因为这完全取决于用户的设置（即遇到高改动率的可能性以及可能同时生成的指标的规模）。不同的设置通常有不同的推荐参数。
|
||||
|
||||
:::
|
||||
|
||||
## 安装 Prometheus Federator 应用程序
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到要安装 Prometheus Federator 的集群，然后单击 **Explore**。
|
||||
1. 点击**应用 > Charts**。
|
||||
1. 单击 **Prometheus Federator** Chart。
|
||||
1. 单击**安装**。
|
||||
1. 在**元数据**页面，点击**下一步**。
|
||||
1. 在**命名空间** > **项目 Release 命名空间项目 ID** 字段中，`System 项目`是默认值，但你可以使用具有类似[有限访问权限](#确保-cattle-monitoring-system-命名空间位于-system-项目中或者位于一个锁定并能访问集群中其他项目的项目中)的另一个项目覆盖它。你可以在 local 上游集群中运行以下命令来找到项目 ID：
|
||||
|
||||
```plain
|
||||
kubectl get projects -A -o custom-columns="NAMESPACE":.metadata.namespace,"ID":.metadata.name,"NAME":.spec.displayName
|
||||
```
|
||||
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**：Prometheus Federator 应用程序已部署在 `cattle-monitoring-system` 命名空间中。
|
||||
+17
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: 安装 Project Monitor
|
||||
---
|
||||
|
||||
在要启用项目监控的各个项目中安装 **Project Monitor**。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
|
||||
1. 在**集群**页面中，转到要启用监控的集群，然后单击 **Explore**。
|
||||
|
||||
1. 单击左侧导航栏上的**监控 > Project Monitor**。然后，点击右上角的**创建**。
|
||||
|
||||
|
||||
|
||||
1. 从下拉菜单中选择你的项目，然后再次单击**创建**。
|
||||
|
||||
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: Prometheus Federator 指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides"/>
|
||||
</head>
|
||||
|
||||
- [启用 Prometheus Federator](enable-prometheus-federator.md)
|
||||
- [卸载 Prometheus Federator](uninstall-prometheus-federator.md)
|
||||
- [自定义 Grafana 仪表板](customize-grafana-dashboards.md)
|
||||
- [为工作负载设置 Prometheus Federator](set-up-workloads.md)
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: 为工作负载设置 Prometheus Federator
|
||||
---
|
||||
|
||||
### 显示工作负载的 CPU 和内存指标
|
||||
|
||||
使用 Prometheus Federator 显示 CPU 和内存指标的方式与使用 rancher-monitoring 相同。有关说明，请参阅[此处](../set-up-monitoring-for-workloads.md#显示工作负载的-cpu-和内存指标)。
|
||||
|
||||
### 设置 CPU 和内存之外的指标
|
||||
|
||||
使用 Prometheus Federator 设置 CPU 和内存之外的指标与使用 rancher-monitoring 的方式相同。有关说明，请参阅[此处](../set-up-monitoring-for-workloads.md#设置-cpu-和内存之外的指标)。
|
||||
|
||||
<!-- ### Custom Metrics -->
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: 卸载 Prometheus Federator
|
||||
---
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，点击 **Apps**。
|
||||
1. 点击**已安装的应用**。
|
||||
1. 转到 `cattle-monitoring-system` 命名空间并选中 `rancher-monitoring-crd` 和 `rancher-monitoring`。
|
||||
1. 单击**删除**。
|
||||
1. 确认**删除**。
|
||||
|
||||
**结果**：已卸载 `prometheus-federator`。
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: 为工作负载设置 Monitoring
|
||||
---
|
||||
|
||||
如果你只需要工作负载的 CPU 和内存时间序列，则不需要部署 ServiceMonitor 或 PodMonitor，因为 Monitoring 应用默认会收集资源使用情况的指标数据。
|
||||
|
||||
设置工作负载监控的步骤取决于你是否需要基本指标（例如工作负载的 CPU 和内存），或者是否需要从工作负载中抓取自定义指标。
|
||||
|
||||
如果你只需要工作负载的 CPU 和内存时间序列，则不需要部署 ServiceMonitor 或 PodMonitor，因为 Monitoring 应用默认会收集资源使用情况的指标数据。资源使用的时间序列数据在 Prometheus 的本地时间序列数据库中。
|
||||
|
||||
Grafana 显示聚合数据，你也可以使用 PromQL 查询来查看单个工作负载的数据。进行 PromQL 查询后，你可以在 Prometheus UI 中单独执行查询并查看可视化的时间序列，你也可以使用查询来自定义显示工作负载指标的 Grafana 仪表板。有关工作负载指标的 PromQL 查询示例，请参阅[本节](../../../integrations-in-rancher/monitoring-and-alerting/promql-expressions.md#工作负载指标)。
|
||||
|
||||
要为你的工作负载设置自定义指标，你需要设置一个 Exporter 并创建一个新的 ServiceMonitor 自定义资源，从而将 Prometheus 配置为从 Exporter 中抓取指标。
|
||||
|
||||
### 显示工作负载的 CPU 和内存指标
|
||||
|
||||
默认情况下，Monitoring 应用会抓取 CPU 和内存指标。
|
||||
|
||||
要获取特定工作负载的细粒度信息，你可以自定义 Grafana 仪表板来显示该工作负载的指标。
|
||||
|
||||
### 设置 CPU 和内存之外的指标
|
||||
|
||||
对于自定义指标，你需要使用 Prometheus 支持的格式来公开应用上的指标。
|
||||
|
||||
我们建议你创建一个新的 ServiceMonitor 自定义资源。创建此资源时，Prometheus 自定义资源将自动更新，以便将新的自定义指标端点包含在抓取配置中。然后 Prometheus 会开始从端点抓取指标。
|
||||
|
||||
你还可以创建 PodMonitor 来公开自定义指标端点，但 ServiceMonitor 更适合大多数用例。
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: 卸载 Monitoring
|
||||
---
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，点击 **Apps**。
|
||||
1. 点击**已安装的应用**。
|
||||
1. 转到 `cattle-monitoring-system` 命名空间并选中 `rancher-monitoring-crd` 和 `rancher-monitoring`。
|
||||
1. 单击**删除**。
|
||||
1. 确认**删除**。
|
||||
|
||||
**结果**：已卸载 `rancher-monitoring`。
|
||||
|
||||
:::note 持久化 Grafana 仪表板：
|
||||
|
||||
如果你的 Monitoring V2 版本是 v9.4.203 或更低版本，卸载 Monitoring chart 将同时删除 cattle-dashboards 命名空间，所有持久化的仪表板将被删除（除非命名空间带有注释 `helm.sh/resource-policy: "keep"`）。Monitoring V2 v14.5.100+ 会默认添加此注释。但如果你的集群上安装了旧版本的 Monitoring Chart，你可以在卸载它之前手动将注释应用到 cattle-dashboards 命名空间。
|
||||
|
||||
:::
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: 高级配置
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration"/>
|
||||
</head>
|
||||
|
||||
### Alertmanager
|
||||
|
||||
有关配置 Alertmanager 自定义资源的信息，请参阅[此页面。](alertmanager.md)
|
||||
|
||||
### Prometheus
|
||||
|
||||
有关配置 Prometheus 自定义资源的信息，请参阅[此页面。](prometheus.md)
|
||||
|
||||
### PrometheusRules
|
||||
|
||||
有关配置 PrometheusRules 自定义资源的信息，请参阅[此页面。](prometheusrules.md)
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: Alertmanager 配置
|
||||
---
|
||||
|
||||
通常情况下，你不需要直接编辑 Alertmanager 自定义资源。对于大多数用例，只需要编辑接收器和路由即可配置通知。
|
||||
|
||||
当路由和接收器更新时，Monitoring 应用将自动更新 Alertmanager 自定义资源来与这些更改保持一致。
|
||||
|
||||
:::note
|
||||
|
||||
本节参考假设你已经熟悉 Monitoring 组件的协同工作方式。有关 Alertmanager 的详细信息，请参阅[本节](../../../../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#3-alertmanager-的工作原理)。
|
||||
|
||||
:::
|
||||
|
||||
## 关于 Alertmanager 自定义资源
|
||||
|
||||
默认情况下，Rancher Monitoring 将单个 Alertmanager 部署到使用默认 Alertmanager Config Secret 的集群上。
|
||||
|
||||
如果你想使用 Rancher UI 表单中未公开的高级选项（例如创建超过两层深的路由树结构），你可能需要编辑 Alertmanager 自定义资源。
|
||||
|
||||
你也可以在集群中创建多个 Alertmanager 来实现命名空间范围的监控。在这种情况下，你应该使用相同的底层 Alertmanager Config Secret 来管理 Alertmanager 自定义资源。
|
||||
|
||||
### 深度嵌套的路由
|
||||
|
||||
虽然 Rancher UI 仅支持两层深度的路由树，但你可以通过编辑 Alertmanager YAML 来配置更深的嵌套路由结构。
|
||||
|
||||
### 多个 Alertmanager 副本
|
||||
|
||||
作为 Chart 部署选项的一部分，你可以选择增加部署到集群上的 Alertmanager 副本的数量。这些副本使用相同的底层 Alertmanager Config Secret 进行管理。
|
||||
|
||||
此 Secret 可以按照你的需求随时更新或修改：
|
||||
|
||||
- 添加新的通知程序或接收器
|
||||
- 更改应该发送给指定通知程序或接收器的告警
|
||||
- 更改发出的告警组
|
||||
|
||||
默认情况下，你可以选择提供现有的 Alertmanager Config Secret（即 `cattle-monitoring-system` 命名空间中的任何 Secret），或允许 Rancher Monitoring 将默认的 Alertmanager Config Secret 部署到你的集群上。
|
||||
|
||||
默认情况下，在升级或卸载 `rancher-monitoring` Chart 时，Rancher 创建的 Alertmanager Config Secret 不会被修改或删除。这个限制可以防止用户在 Chart 上执行操作时丢失或覆盖他们的告警配置。
|
||||
|
||||
有关可以在 Alertmanager Config Secret 中指定的字段的更多信息，请查看 [Prometheus Alertmanager 文档](https://prometheus.io/docs/alerting/latest/alertmanager/)。
|
||||
|
||||
你可以在[此处](https://prometheus.io/docs/alerting/latest/configuration/#configuration-file)找到 Alertmanager 配置文件的完整规范及其内容。
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Prometheus 配置
|
||||
---
|
||||
|
||||
通常情况下，你不需要直接编辑 Prometheus 自定义资源，因为 Monitoring 应用会根据 ServiceMonitor 和 PodMonitor 的更改自动更新资源。
|
||||
|
||||
:::note
|
||||
|
||||
本节参考假设你已经熟悉 Monitoring 组件的协同工作方式。有关详细信息，请参阅[本节](../../../../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)。
|
||||
|
||||
:::
|
||||
|
||||
## 关于 Prometheus 自定义资源
|
||||
|
||||
Prometheus CR 定义了所需的 Prometheus deployment。Prometheus Operator 会观察 Prometheus CR。当 CR 发生变化时，Prometheus Operator 会创建 `prometheus-rancher-monitoring-prometheus`，即根据 CR 配置的 Prometheus deployment。
|
||||
|
||||
Prometheus CR 指定了详细信息，例如规则以及连接到 Prometheus 的 Alertmanager。Rancher 会为你构建这个 CR。
|
||||
|
||||
Monitoring V2 仅支持每个集群一个 Prometheus。如果你想将监控限制到指定命名空间，你需要编辑 Prometheus CR。
|
||||
+80
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: PrometheusRule 配置
|
||||
---
|
||||
|
||||
PrometheusRule 定义了一组 Prometheus 告警和/或记录规则。
|
||||
|
||||
:::note
|
||||
|
||||
本节参考假设你已经熟悉 Monitoring 组件的协同工作方式。有关详细信息，请参阅[本节](../../../../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)。
|
||||
|
||||
:::
|
||||
|
||||
### 在 Rancher UI 中创建 PrometheusRule
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
已安装 Monitoring 应用。
|
||||
|
||||
:::
|
||||
|
||||
要在 Rancher UI 中创建规则组：
|
||||
|
||||
1. 转到要创建规则组的集群。单击**监控 > 高级选项**，然后单击 **PrometheusRules**。
|
||||
1. 单击**创建**。
|
||||
1. 输入**组名称**。
|
||||
1. 配置规则。在 Rancher 的 UI 中，规则组需要包含告警规则或记录规则，但不能同时包含两者。如需获取填写表单的帮助，请参阅下方的配置选项。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：告警可以向接收器发送通知。
|
||||
|
||||
### 关于 PrometheusRule 自定义资源
|
||||
|
||||
当你定义规则时（在 PrometheusRule 资源的 RuleGroup 中声明），[规则本身的规范](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#rule)会包含标签，然后 Alertmanager 会使用这些标签来确定接收此告警的路由。例如，标签为 `team: front-end` 的告警将发送到与该标签匹配的所有路由。
|
||||
|
||||
Prometheus 规则文件保存在 PrometheusRule 自定义资源中。PrometheusRule 支持定义一个或多个 RuleGroup。每个 RuleGroup 由一组 Rule 对象组成，每个 Rule 对象均能表示告警或记录规则，并具有以下字段：
|
||||
|
||||
- 新告警或记录的名称
|
||||
- 新告警或记录的 PromQL 表达式
|
||||
- 用于标记告警或记录的标签（例如集群名称或严重性）
|
||||
- 对需要在告警通知上显示的其他重要信息进行编码的注释（例如摘要、描述、消息、Runbook URL 等）。记录规则不需要此字段。
|
||||
|
||||
有关可以指定的字段的更多信息，请查看 [Prometheus Operator 规范。](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#prometheusrulespec)
|
||||
|
||||
你可以使用 Prometheus 对象中的标签选择器字段 `ruleSelector` 来定义要挂载到 Prometheus 的规则文件。
|
||||
|
||||
如需查看示例，请参阅 Prometheus 文档中的[记录规则](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/)和[告警规则](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)。
|
||||
|
||||
## 配置
|
||||
|
||||
### 规则组
|
||||
|
||||
| 字段 | 描述 |
|
||||
|-------|----------------|
|
||||
| 组名称 | 组的名称。在规则文件中必须是唯一的。 |
|
||||
| 覆盖组间隔 | 组中规则的评估时间间隔（单位：秒）。 |
|
||||
|
||||
|
||||
### 告警规则
|
||||
|
||||
[告警规则](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)可以让你根据 PromQL（Prometheus 查询语言）表达式来定义告警条件，并将触发告警的通知发送到外部服务。
|
||||
|
||||
| 字段 | 描述 |
|
||||
|-------|----------------|
|
||||
| 告警名称 | 告警的名称。必须是有效的标签值。 |
|
||||
| 告警触发等待时间 | 时长，以秒为单位。当告警触发时间到达该指定时长时，则视为触发。当告警未触发足够长的时间，则视为待处理。 |
|
||||
| PromQL 表达式 | 要评估的 PromQL 表达式。Prometheus 将在每个评估周期评估此 PromQL 表达式的当前值，并且所有生成的时间序列都将成为待处理/触发告警。有关详细信息，请参阅 [Prometheus 文档](https://prometheus.io/docs/prometheus/latest/querying/basics/)或我们的 [PromQL 表达式示例](../../../../integrations-in-rancher/monitoring-and-alerting/promql-expressions.md)。 |
|
||||
| Labels | 为每个告警添加或覆盖的标签。 |
|
||||
| 严重程度 | 启用后，标签会附加到告警或记录中，这些标签通过严重程度来标识告警/记录。 |
|
||||
| 严重程度 Label 值 | Critical，warning 或 none |
|
||||
| 注释 | 注释是一组信息标签，可用于存储更长的附加信息，例如告警描述或 Runbook 链接。[Runbook](https://en.wikipedia.org/wiki/Runbook) 是一组有关如何处理告警的文档。注释值可以是[模板化](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/#templating)的。 |
|
||||
|
||||
### 记录规则
|
||||
|
||||
[记录规则](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/#recording-rules)允许你预先计算常用或计算量大的 PromQL（Prometheus 查询语言）表达式，并将其结果保存为一组新的时间序列。
|
||||
|
||||
| 字段 | 描述 |
|
||||
|-------|----------------|
|
||||
| 时间序列名称 | 要输出的时间序列的名称。必须是有效的指标名称。 |
|
||||
| PromQL 表达式 | 要评估的 PromQL 表达式。Prometheus 将在每个评估周期评估此 PromQL 表达式的当前值，并且将结果记录为一组新的时间序列，其指标名称由“记录”指定。有关表达式的更多信息，请参阅 [Prometheus 文档](https://prometheus.io/docs/prometheus/latest/querying/basics/)或我们的 [PromQL 表达式示例](../../../../integrations-in-rancher/monitoring-and-alerting/promql-expressions.md)。 |
|
||||
| Labels | 在存储结果之前要添加或覆盖的标签。 |
|
||||
+55
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: 配置
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides"/>
|
||||
</head>
|
||||
|
||||
本文介绍在 Rancher UI 中配置 Monitoring V2 的一些最重要选项。
|
||||
|
||||
有关为 Prometheus 配置自定义抓取目标和规则的信息，请参阅 [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator) 的上游文档。Prometheus Operator [设计文档](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/getting-started/design.md)中解释了一些最重要的自定义资源。Prometheus Operator 文档还可以帮助你设置 RBAC、Thanos 或进行自定义配置。
|
||||
|
||||
## 设置资源限制和请求
|
||||
|
||||
安装 `rancher-monitoring` 时可以配置 Monitoring 应用的资源请求和限制。有关默认限制的更多信息，请参阅[此页面](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#配置资源限制和请求)。
|
||||
|
||||
:::tip
|
||||
|
||||
在空闲集群上，Monitoring 可能会占用很多 CPU 资源。要提高性能，请关闭 Prometheus Adapter。
|
||||
|
||||
:::
|
||||
|
||||
## Prometheus 配置
|
||||
|
||||
通常不需要直接编辑 Prometheus 自定义资源。
|
||||
|
||||
相反，要让 Prometheus 抓取自定义指标，你只需创建一个新的 ServiceMonitor 或 PodMonitor 来将 Prometheus 配置为抓取其他指标。
|
||||
|
||||
### ServiceMonitor 和 PodMonitor 配置
|
||||
|
||||
有关详细信息，请参阅[此页面](../../../reference-guides/monitoring-v2-configuration/servicemonitors-and-podmonitors.md)。
|
||||
|
||||
### 高级 Prometheus 配置
|
||||
|
||||
有关直接编辑 Prometheus 自定义资源（对高级用例可能有帮助）的更多信息，请参阅[此页面](advanced-configuration/prometheus.md)。
|
||||
|
||||
## Alertmanager 配置
|
||||
|
||||
Alertmanager 自定义资源通常不需要直接编辑。在常见用例中，你可以通过更新路由和接收器来管理告警。
|
||||
|
||||
路由和接收器是 Alertmanager 自定义资源配置的一部分。在 Rancher UI 中，路由（Route）和接收器（Receiver）并不是真正的自定义资源，而是 Prometheus Operator 用来将你的配置与 Alertmanager 自定义资源同步的伪自定义资源。当路由和接收器更新时，Monitoring 应用将自动更新 Alertmanager 来反映这些更改。
|
||||
|
||||
对于一些高级用例，你可能需要直接配置 Alertmanager。有关详细信息，请参阅[此页面](advanced-configuration/alertmanager.md)。
|
||||
|
||||
### 接收器
|
||||
|
||||
接收器（Receiver）用于设置通知。有关如何配置接收器的详细信息，请参阅[此页面](../../../reference-guides/monitoring-v2-configuration/receivers.md)。
|
||||
|
||||
### 路由
|
||||
|
||||
路由（Route）在通知到达接收器之前过滤它们。每条路由都需要引用一个已经配置好的接收器。有关如何配置路由的详细信息，请参阅[此页面](../../../reference-guides/monitoring-v2-configuration/routes.md)。
|
||||
|
||||
### 高级配置
|
||||
|
||||
有关直接编辑 Alertmanager 自定义资源（对高级用例可能有帮助）的更多信息，请参阅[此页面](advanced-configuration/alertmanager.md)。
|
||||
+107
@@ -0,0 +1,107 @@
|
||||
---
|
||||
title: 使用 firewalld 打开端口
|
||||
---
|
||||
|
||||
> 我们建议禁用 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`，将[防火墙端口规则](../../pages-for-subheaders/installation-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 节点通信了。
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: 为大型安装进行 etcd 调优
|
||||
---
|
||||
|
||||
当你运行具有 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.5/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.5/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'
|
||||
```
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: 添加项目成员
|
||||
---
|
||||
|
||||
如果你想为用户提供集群内 _特定_ 项目和资源的访问权限，请为用户分配项目成员资格。
|
||||
|
||||
你可以在创建项目时将成员添加到项目中，或将用户添加到现有项目中。
|
||||
|
||||
:::tip
|
||||
|
||||
如果你需要为用户提供对集群内 _所有_ 项目的访问权限，请参见[添加集群成员](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)。
|
||||
|
||||
:::
|
||||
|
||||
### 将成员添加到新项目
|
||||
|
||||
你可以在创建项目时将成员添加到项目中（建议）。有关创建新项目的详细信息，请参阅[集群管理](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md)。
|
||||
|
||||
### 将成员添加到现有项目
|
||||
|
||||
创建项目后，你可以将用户添加为项目成员，以便用户可以访问项目的资源：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要添加项目成员的集群，然后单击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 转到要添加成员的项目。在项目名称上方的**创建命名空间**按钮旁边，单击 **☰**。选择 **编辑配置**。
|
||||
1. 在**成员**选项卡中，单击**添加**。
|
||||
1. 搜索要添加到项目的用户或组。
|
||||
|
||||
如果配置了外部身份验证：
|
||||
|
||||
- 在你键入时，Rancher 会从你的外部身份验证源返回用户。
|
||||
|
||||
- 你可以在下拉菜单中添加组，而不是单个用户。下拉列表仅会列出你（登录用户）所在的组。
|
||||
|
||||
:::note
|
||||
|
||||
如果你以本地用户身份登录，外部用户不会显示在你的搜索结果中。
|
||||
|
||||
:::
|
||||
|
||||
1. 分配用户或组的**项目**角色。
|
||||
|
||||
[什么是项目角色？](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
- 如果用户分配到了项目的`所有者`或`成员`角色，用户会自动继承`命名空间创建`角色。然而，这个角色是 [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole)，这表示角色的范围会延展到集群中的所有项目。因此，对于显式分配到了项目`所有者`或`成员`角色的用户来说，即使只有`只读`角色，这些用户也可以在分配给他们的其他项目中创建或删除命名空间。
|
||||
|
||||
- 默认情况下，Rancher 的`项目成员`角色继承自 `Kubernetes-edit` 角色，而`项目所有者`角色继承自 `Kubernetes-admin` 角色。因此，`项目成员`和`项目所有者`角色都能管理命名空间，包括创建和删除命名空间。
|
||||
|
||||
- 对于`自定义`角色，你可以修改可分配的角色列表。
|
||||
|
||||
- 要将角色添加到列表中，请[添加自定义角色](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md)。
|
||||
- 要从列表中删除角色，请[锁定/解锁角色](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/locked-roles.md)。
|
||||
|
||||
:::
|
||||
|
||||
**结果**：已将选中的用户添加到项目中。
|
||||
|
||||
- 要撤销项目成员资格，请选择用户并单击**删除**。此操作会删除成员资格，而不会删除用户。
|
||||
- 要修改项目中的用户角色，请将其从项目中删除，然后使用修改后的角色重新添加用户。
|
||||
+51
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: 配置驱动
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers"/>
|
||||
</head>
|
||||
|
||||
使用 Rancher 中的驱动，你可以管理可以使用哪些供应商来部署[托管的 Kubernetes 集群](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md)或[云服务器节点](../../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)，以允许 Rancher 部署和管理 Kubernetes。
|
||||
|
||||
### Rancher 驱动
|
||||
|
||||
你可以启用或禁用 Rancher 中内置的驱动。如果相关驱动 Rancher 尚未实现，你可以添加自己的驱动。
|
||||
|
||||
Rancher 中有两种类型的驱动：
|
||||
|
||||
* [集群驱动](#集群驱动)
|
||||
* [主机驱动](#主机驱动)
|
||||
|
||||
### 集群驱动
|
||||
|
||||
集群驱动用于配置[托管的 Kubernetes 集群](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md)，例如 GKE、EKS、AKS 等。创建集群时可以显示的集群驱动，是由集群驱动的状态定义的。只有 `active` 集群驱动将显示为为托管 Kubernetes 集群创建集群的选项。默认情况下，Rancher 与几个现有的集群驱动打包在一起，但你也可以创建自定义集群驱动并添加到 Rancher。
|
||||
|
||||
默认情况下，Rancher 已激活多个托管 Kubernetes 云提供商，包括：
|
||||
|
||||
* [Amazon EKS](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/eks.md)
|
||||
* [Google GKE](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/gke.md)
|
||||
* [Azure AKS](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/aks.md)
|
||||
|
||||
还有几个托管的 Kubernetes 云提供商是默认禁用的，但也打包在 Rancher 中：
|
||||
|
||||
* [Alibaba ACK](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/alibaba.md)
|
||||
* [Huawei CCE](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md)
|
||||
* [Tencent](../../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/tencent.md)
|
||||
|
||||
### 主机驱动
|
||||
|
||||
主机驱动用于配置主机，Rancher 使用这些主机启动和管理 Kubernetes 集群。主机驱动与 [Docker Machine 驱动](https://github.com/docker/docs/blob/vnext-engine/machine/drivers/index.md)相同。创建主机模板时可以显示的主机驱动，是由主机驱动的状态定义的。只有 `active` 主机驱动将显示为创建节点模板的选项。默认情况下，Rancher 与许多现有的 Docker Machine 驱动打包在一起，但你也可以创建自定义主机驱动并添加到 Rancher。
|
||||
|
||||
如果你不想向用户显示特定的主机驱动，则需要停用这些主机驱动。
|
||||
|
||||
Rancher 支持几家主要的云提供商，但默认情况下，这些主机驱动处于 active 状态并可供部署：
|
||||
|
||||
* [Amazon EC2](../../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md)
|
||||
* [Azure](../../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-azure-cluster.md)
|
||||
* [Digital Ocean](../../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-a-digitalocean-cluster.md)
|
||||
* [vSphere](../../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/vsphere.md)
|
||||
|
||||
还有其他几个默认禁用的主机驱动，但打包在 Rancher 中：
|
||||
|
||||
* [Harvester](../../../../integrations-in-rancher/harvester.md#harvester-主机驱动) - 在 Rancher 2.6.1 中可用
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: 集群驱动
|
||||
---
|
||||
|
||||
集群驱动用于在[托管 Kubernetes 提供商](../../../../pages-for-subheaders/set-up-clusters-from-hosted-kubernetes-providers.md)（例如 Google GKE）中创建集群。创建集群时可以显示的集群驱动，是由集群驱动的状态定义的。只有 `active` 集群驱动将作为创建集群的选项显示。默认情况下，Rancher 与多个现有的云提供商集群驱动打包在一起，但你也可以将自定义集群驱动添加到 Rancher。
|
||||
|
||||
如果你不想向用户显示特定的集群驱动，你可以在 Rancher 中停用这些集群驱动，它们将不会作为创建集群的选项出现。
|
||||
|
||||
### 管理集群驱动
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
要创建、编辑或删除集群驱动，你需要以下权限中的_一个_：
|
||||
|
||||
- [管理员全局权限](../manage-role-based-access-control-rbac/global-permissions.md)
|
||||
- 分配了[管理集群驱动角色](../manage-role-based-access-control-rbac/global-permissions.md)的[自定义全局权限](../manage-role-based-access-control-rbac/global-permissions.md#自定义全局权限)。
|
||||
|
||||
:::
|
||||
|
||||
## 激活/停用集群驱动
|
||||
|
||||
默认情况下，Rancher 仅激活主流的云提供商 Google GKE、Amazon EKS 和 Azure AKS 的驱动。如果要显示或隐藏驱动，你可以更改驱动的状态：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
|
||||
2. 在左侧导航菜单中，单击**驱动**。
|
||||
|
||||
3. 在**集群驱动**选项卡上，选择要激活或停用的驱动，然后单击 **⋮ > 激活** 或 **⋮ > 停用**。
|
||||
|
||||
## 添加自定义集群驱动
|
||||
|
||||
如果你想使用 Rancher 不支持开箱即用的集群驱动，你可以添加提供商的驱动，从而使用该驱动来创建 _托管_ Kubernetes 集群：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在左侧导航菜单中，单击**驱动**。
|
||||
1. 在**集群驱动**选项卡上，单击**添加集群驱动**。
|
||||
1. 填写**添加集群驱动**表单。然后单击**创建**。
|
||||
|
||||
|
||||
### 开发自己的集群驱动
|
||||
|
||||
如果要开发集群驱动并添加到 Rancher，请参考我们的[示例](https://github.com/rancher-plugins/kontainer-engine-driver-example)。
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: 主机驱动
|
||||
---
|
||||
|
||||
主机驱动用于配置主机，Rancher 使用这些主机启动和管理 Kubernetes 集群。主机驱动与 [Docker Machine 驱动](https://github.com/docker/docs/blob/vnext-engine/machine/drivers/index.md)相同。创建主机模板时可以显示的主机驱动，是由主机驱动的状态定义的。只有 `active` 主机驱动将显示为创建节点模板的选项。默认情况下，Rancher 与许多现有的 Docker Machine 驱动打包在一起，但你也可以创建自定义主机驱动并添加到 Rancher。
|
||||
|
||||
如果你不想向用户显示特定的主机驱动，则需要停用这些主机驱动。
|
||||
|
||||
#### 管理主机驱动
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
要创建、编辑或删除驱动，你需要以下权限中的_一个_：
|
||||
|
||||
- [管理员全局权限](../manage-role-based-access-control-rbac/global-permissions.md)
|
||||
- 分配了[管理主机驱动角色](../manage-role-based-access-control-rbac/global-permissions.md)的[自定义全局权限](../manage-role-based-access-control-rbac/global-permissions.md#自定义全局权限)。
|
||||
|
||||
:::
|
||||
|
||||
## 激活/停用主机驱动
|
||||
|
||||
默认情况下，Rancher 仅激活主流云提供商 Amazon EC2、Azure、DigitalOcean 和 vSphere 的驱动。如果要显示或隐藏驱动，你可以更改驱动的状态：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
|
||||
2. 在左侧导航菜单中，单击**驱动**。
|
||||
|
||||
2. 在**主机驱动**选项卡上，选择要激活或停用的驱动，然后单击 **⋮ > 激活** 或 **⋮ > 停用**。
|
||||
|
||||
## 添加自定义主机驱动
|
||||
|
||||
如果你想使用 Rancher 不支持开箱即用的主机驱动，你可以添加提供商的驱动，从而使用该驱动为你的 Kubernetes 集群创建节点模板并最终创建节点池：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在左侧导航菜单中，单击**驱动**。
|
||||
1. 在**主机驱动**选项卡上，单击**添加主机驱动**。
|
||||
1. 填写**添加主机驱动**表单。然后单击**创建**。
|
||||
|
||||
### 开发自己的主机驱动
|
||||
|
||||
主机驱动使用 [Docker Machine](https://github.com/docker/docs/blob/vnext-engine/machine/overview.md) 来实现。
|
||||
+133
@@ -0,0 +1,133 @@
|
||||
---
|
||||
title: RKE 模板
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
|
||||
RKE 模板旨在让 DevOps 和安全团队标准化和简化 Kubernetes 集群创建的流程。
|
||||
|
||||
RKE 的全称是 [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/)，它是 Rancher 用来配置 Kubernetes 集群的工具。
|
||||
|
||||
随着 Kubernetes 越来越受欢迎，管理更多小型集群逐渐成为趋势。如果你想要创建大量集群，对集群进行一致管理尤为重要。多集群管理面临着安全和附件配置执行的挑战，在将集群移交给最终用户之前，这些配置需要标准化。
|
||||
|
||||
RKE 模板有助于标准化这些配置。无论是使用 Rancher UI、Rancher API 还是自动化流程创建的集群，Rancher 都将保证从 RKE 集群模板创建的每个集群在生成方式上是一致的。
|
||||
|
||||
管理员可以控制最终用户能更改的集群选项。RKE 模板还可以与特定的用户和组共享，以便管理员可以为不同的用户集创建不同的 RKE 模板。
|
||||
|
||||
如果集群是使用 RKE 模板创建的，则不能让集群使用另一个 RKE 模板。你只能将集群更新为同一模板的新版本。
|
||||
|
||||
你可以[将现有集群的配置保存为 RKE 模板](apply-templates.md#将现有集群转换为使用-rke-模板)。这样，只有模板更新后才能更改集群的设置。新模板还可用于启动新集群。
|
||||
|
||||
RKE 模板的核心功能允许 DevOps 和安全团队：
|
||||
|
||||
- 标准化集群配置并确保按照最佳实践创建 Rancher 配置的集群
|
||||
- 配置集群时，防止用户做出不明智的选择
|
||||
- 与不同的用户和组共享不同的模板
|
||||
- 将模板的所有权委托给受信任的用户进行更改
|
||||
- 控制哪些用户可以创建模板
|
||||
- 要求用户使用模板来创建集群
|
||||
|
||||
## 可配置的设置
|
||||
|
||||
RKE 模板可以在 Rancher UI 中创建或以 YAML 格式定义。当你使用 Rancher 从基础设施提供商配置自定义节点或一般节点时，它们可以指定为相同的参数：
|
||||
|
||||
- 云提供商选项
|
||||
- Pod 安全选项
|
||||
- 网络提供商
|
||||
- Ingress Controller
|
||||
- 网络安全配置
|
||||
- 网络插件
|
||||
- 私有镜像仓库 URL 和凭证
|
||||
- 附加组件
|
||||
- Kubernetes 选项，包括 kube-api、kube-controller、kubelet 和服务等 Kubernetes 组件的配置
|
||||
|
||||
RKE 模板的[附加组件](#附加组件)的功能特别强大，因为它允许多种自定义选项。
|
||||
|
||||
## RKE 模板的范围
|
||||
|
||||
Rancher 配置的集群支持 RKE 模板。模板可用于配置自定义集群或由基础设施提供商启动的集群。
|
||||
|
||||
RKE 模板用于定义 Kubernetes 和 Rancher 设置。节点模板负责配置节点。有关如何将 RKE 模板与硬件结合使用的参考，请参阅 [RKE 模板和硬件](infrastructure.md)。
|
||||
|
||||
可以从头开始创建 RKE 模板来预先定义集群配置。它们可以用于启动新集群，也可以从现有的 RKE 集群导出模板。
|
||||
|
||||
现有集群的设置可以[保存为 RKE 模板](apply-templates.md#将现有集群转换为使用-rke-模板)。这会创建一个新模板并将集群设置绑定到该模板。这样，集群只有在[模板更新](manage-rke1-templates.md#更新模板)的情况下才能[使用新版本的模板](manage-rke1-templates.md#升级集群以使用新的模板修订版)进行升级。新模板也可以用来创建新集群。
|
||||
|
||||
|
||||
## 示例场景
|
||||
如果一个组织同时拥有普通和高级 Rancher 用户，管理员可能希望为高级用户提供更多用于集群创建的选项，并限制普通用户的选项。
|
||||
|
||||
这些[示例场景](example-use-cases.md)描述组织如何使用模板来标准化集群创建。
|
||||
|
||||
示例场景包括：
|
||||
|
||||
- **强制执行模板**：如果希望所有 Rancher 配置的新集群都具有某些设置，管理员可能想要[为每个用户强制执行一项或多项模板设置](example-use-cases.md#强制执行模板设置)。
|
||||
- **与不同的用户共享不同的模板**：管理员可以为[普通用户和高级用户提供不同的模板](example-use-cases.md#普通用户和高级用户模板)。这样，普通用户会有更多限制选项，而高级用户在创建集群时可以使用更多选项。
|
||||
- **更新模板设置**：如果组织的安全和 DevOps 团队决定将最佳实践嵌入到新集群所需的设置中，这些最佳实践可能会随着时间而改变。如果最佳实践发生变化，[可以将模板更新为新版本](example-use-cases.md#更新模板和集群)，这样，使用模板创建的集群可以[升级到模板的新版本](manage-rke1-templates.md#升级集群以使用新的模板修订版)。
|
||||
- **共享模板的所有权**：当模板所有者不再想要维护模板或想要共享模板的所有权时，此方案描述了如何[共享模板所有权](example-use-cases.md#允许其他用户控制和共享模板)。
|
||||
|
||||
## 模板管理
|
||||
|
||||
创建 RKE 模板时，可以在 Rancher UI 中的**集群管理**下的 **RKE 模板**中使用模板。创建模板后，你将成为模板所有者，这将授予你修改和共享模板的权限。你可以与特定用户或组共享 RKE 模板，也可以公开模板。
|
||||
|
||||
管理员可以开启模板强制执行，要求用户在创建集群时始终使用 RKE 模板。这使管理员可以保证 Rancher 总是创建指定配置的集群。
|
||||
|
||||
RKE 模板更新通过修订系统处理。如果要更改或更新模板，请创建模板的新版本。然后，可以将使用旧版本模板创建的集群升级到新模板修订版。
|
||||
|
||||
在 RKE 模板中，模板所有者可以限制设置的内容，也可以打开设置以供最终用户选择值。它们的差别体现在，创建模板时，Rancher UI 中的每个设置上的**允许用户覆盖**标示。
|
||||
|
||||
对于无法覆盖的设置，最终用户将无法直接编辑它们。为了让用户使用这些设置的不同选项，RKE 模板所有者需要创建 RKE 模板的新版本，这将允许用户升级和更改该选项。
|
||||
|
||||
本节中的文件解释了 RKE 模板管理的细节：
|
||||
|
||||
- [获取创建模板的权限](creator-permissions.md)
|
||||
- [创建和修改模板](manage-rke1-templates.md)
|
||||
- [强制执行模板设置](enforce-templates.md#强制新集群使用-rke-模板)
|
||||
- [覆盖模板设置](override-template-settings.md)
|
||||
- [与集群创建者共享模板](access-or-share-templates.md#与特定用户或组共享模板)
|
||||
- [共享模板的所有权](access-or-share-templates.md#共享模板所有权)
|
||||
|
||||
你可以参见此[模板的示例 YAML 文件](../../../../reference-guides/rke1-template-example-yaml.md)作为参考。
|
||||
|
||||
## 应用模板
|
||||
|
||||
你可以使用你自己创建的模板来[创建集群](apply-templates.md#使用-rke-模板创建集群)，也可以使用[与你共享的模板](access-or-share-templates.md)来创建集群。
|
||||
|
||||
如果 RKE 模板所有者创建了模板的新版本，你可以[将你的集群升级到该版本](apply-templates.md#更新使用-rke-模板创建的集群)。
|
||||
|
||||
可以从头开始创建 RKE 模板来预先定义集群配置。它们可以用于启动新集群，也可以从现有的 RKE 集群导出模板。
|
||||
|
||||
你可以[将现有集群的配置保存为 RKE 模板](apply-templates.md#将现有集群转换为使用-rke-模板)。这样，只有模板更新后才能更改集群的设置。
|
||||
|
||||
## 标准化硬件
|
||||
|
||||
RKE 模板的目的是标准化 Kubernetes 和 Rancher 设置。如果你还想标准化你的基础设施，一个选择是将 RKE 模板与[其他工具](infrastructure.md)一起使用。
|
||||
|
||||
另一种选择是使用包含节点池配置选项，但不强制执行配置的[集群模板](../../manage-clusters/manage-cluster-templates.md)。
|
||||
|
||||
## YAML 定制
|
||||
|
||||
如果将 RKE 模板定义为 YAML 文件，则可以修改此[示例 RKE 模板 YAML](../../../../reference-guides/rke1-template-example-yaml.md)。RKE 模板中的 YAML 使用了 Rancher 在创建 RKE 集群时使用的相同自定义设置。但由于 YAML 要在 Rancher 配置的集群中使用，因此需要将 RKE 模板自定义项嵌套在 YAML 中的 `rancher_kubernetes_engine_config` 参数下。
|
||||
|
||||
RKE 文档也提供[注释的](https://rancher.com/docs/rke/latest/en/example-yamls/) `cluster.yml` 文件供你参考。
|
||||
|
||||
有关可用选项的更多信息，请参阅[集群配置](https://rancher.com/docs/rke/latest/en/config-options/)上的 RKE 文档。
|
||||
|
||||
### 附加组件
|
||||
|
||||
RKE 模板配置文件的附加组件部分的工作方式与[集群配置文件的附加组件部分](https://rancher.com/docs/rke/latest/en/config-options/add-ons/)相同。
|
||||
|
||||
用户定义的附加组件指令允许你调用和下拉 Kubernetes 清单或将它们直接内联。如果这些 YAML 清单包括在 RKE 模板中，Rancher 将在集群中部署这些 YAML 文件。
|
||||
|
||||
你可以使用附加组件执行以下操作：
|
||||
|
||||
- 启动 Kubernetes 集群后，在集群上安装应用
|
||||
- 在使用 Kubernetes Daemonset 部署的节点上安装插件
|
||||
- 自动设置命名空间、ServiceAccount 或角色绑定
|
||||
|
||||
RKE 模板配置必须嵌套在 `rancher_kubernetes_engine_config` 参数中。要设置附加组件，在创建模板时单击**以 YAML 文件编辑**。然后使用 `addons` 指令添加清单，或使用 `addons_include` 指令设置哪些 YAML 文件可用于附加组件。有关自定义附加组件的更多信息，请参见[用户自定义附加组件文档](https://rancher.com/docs/rke/latest/en/config-options/add-ons/user-defined-add-ons/)。
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: 访问和共享
|
||||
---
|
||||
|
||||
如果你是 RKE 模板所有者，你可以将该模板共享给用户或用户组，然后他们可以使用该模板创建集群。
|
||||
|
||||
由于 RKE 模板是专门与用户和组共享的，因此所有者可以与不同的用户共享不同的 RKE 模板。
|
||||
|
||||
共享模板时，每个用户都可以拥有以下两个访问权限中的其中一个：
|
||||
|
||||
- **所有者**：可以更新、删除和共享他们拥有的模板。所有者还可以与其他用户共享模板。
|
||||
- **用户**：可以使用模板创建集群。他们还可以将这些集群升级到同一模板的新版本。如果你将模板共享为**公开（只读）**，你的 Rancher 设置中的所有用户都拥有该模板的用户访问权限。
|
||||
|
||||
如果你创建了一个模板，你将自动成为该模板的所有者。
|
||||
|
||||
如果你想让其他用户更新该模板，你可以共享模板的所有权。有关所有者如何修改模板的详细信息，请参阅[修改模板文档](manage-rke1-templates.md)。
|
||||
|
||||
共享模板的方式有如下几种：
|
||||
|
||||
- 在模板创建期间将用户添加到新的 RKE 模板
|
||||
- 将用户添加到现有 RKE 模板
|
||||
- 公开 RKE 模板，并与 Rancher 设置中的所有用户共享
|
||||
- 与受信任修改模板的用户共享模板所有权
|
||||
|
||||
### 与特定用户或组共享模板
|
||||
|
||||
要允许用户或组使用你的模板创建集群，你可以为他们提供模板的基本**用户**访问权限。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在 **RKE1 配置**下，单击 **RKE 模板**。
|
||||
1. 转到要共享的模板，然后单击 **⋮ > 编辑**。
|
||||
1. 在**共享模板**中，单击**添加成员**。
|
||||
1. 在**名称**字段中搜索你要与之共享模板的用户或组。
|
||||
1. 选择**用户**访问类型。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：用户或组可以使用模板创建集群。
|
||||
|
||||
### 与所有用户共享模板
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在左侧导航栏，单击 **RKE1 配置 > RKE 模板**。
|
||||
1. 转到要共享的模板，然后单击 **⋮ > 编辑**。
|
||||
1. 在**共享模板**下，选中 **公开（只读）** 复选框。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：Rancher 设置中的所有用户都可以使用该模板创建集群。
|
||||
|
||||
### 共享模板所有权
|
||||
|
||||
如果你是模板的创建者，你可能希望将维护和更新模板的责任委派给其他用户或组。
|
||||
|
||||
在这种情况下，你可以为用户提供**所有者**访问权限，该权限允许其他用户更新、删除模板或与其他用户共享对模板的访问权限。
|
||||
|
||||
要授予用户或组**所有者**权限：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在 **RKE1 配置**下，单击 **RKE 模板**。
|
||||
1. 转到要共享的 RKE 模板，然后单击 **⋮ > 编辑**。
|
||||
1. 在**共享模板**下，单击**添加成员**并在**名称**字段中搜索要与之共享模板的用户或组。
|
||||
1. 在**访问类型**字段中，单击**所有者**。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：用户或组具有**所有者**访问类型，可以修改、共享或删除模板。
|
||||
+59
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: 应用模板
|
||||
---
|
||||
|
||||
你可以使用你自己创建的 RKE 模板来创建集群，也可以使用[与你共享的模板](access-or-share-templates.md)来创建集群。
|
||||
|
||||
RKE 模板可以应用于新集群。
|
||||
|
||||
你可以[将现有集群的配置保存为 RKE 模板](#将现有集群转换为使用-rke-模板)。这样，只有模板更新后才能更改集群的设置。
|
||||
|
||||
你无法将集群更改为使用不同的 RKE 模板。你只能将集群更新为同一模板的新版本。
|
||||
|
||||
|
||||
### 使用 RKE 模板创建集群
|
||||
|
||||
要使用 RKE 模板添加[由基础设施提供商托管](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)的集群，请按照以下步骤操作：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，单击**创建**并选择基础设施提供商。
|
||||
1. 设置集群名称和节点模板详情。
|
||||
1. 要使用 RKE 模板，请在**集群选项**下，选中**使用现有 RKE 模板和修订版**复选框。
|
||||
1. 从下拉菜单中选择 RKE 模板和修订版。
|
||||
1. 可选：你可以编辑 RKE 模板所有者在创建模板时标记为**允许用户覆盖**的任何设置。如果你无法更改某些设置，则需要联系模板所有者以获取模板的新修订版。然后，你需要编辑集群来将其升级到新版本。
|
||||
1. 单击**创建**以启动集群。
|
||||
|
||||
### 更新使用 RKE 模板创建的集群
|
||||
|
||||
模板所有者创建 RKE 模板时，每个设置在 Rancher UI 中都有一个开关，指示用户是否可以覆盖该设置。
|
||||
|
||||
- 如果某个设置允许用户覆盖，你可以通过[编辑集群](../../../../pages-for-subheaders/cluster-configuration.md)来更新集群中的设置。
|
||||
- 如果该开关处于关闭状态，则除非集群所有者创建了允许你覆盖这些设置的模板修订版，否则你无法更改这些设置。如果你无法更改某些设置，则需要联系模板所有者以获取模板的新修订版。
|
||||
|
||||
如果集群是使用 RKE 模板创建的，你可以编辑集群，来将集群更新为模板的新版本。
|
||||
|
||||
现有集群的设置可以[保存为 RKE 模板](#将现有集群转换为使用-rke-模板)。在这种情况下，你还可以编辑集群以将集群更新为模板的新版本。
|
||||
|
||||
:::note
|
||||
|
||||
你无法将集群更改为使用不同的 RKE 模板。你只能将集群更新为同一模板的新版本。
|
||||
|
||||
:::
|
||||
|
||||
### 将现有集群转换为使用 RKE 模板
|
||||
|
||||
本节介绍如何使用现有集群创建 RKE 模板。
|
||||
|
||||
除非你将现有集群的设置保存为 RKE 模板，否则 RKE 模板不能应用于现有集群。这将把集群的设置导出为新的 RKE 模板，并且将集群绑定到该模板。然后，只有[更新了模板](manage-rke1-templates.md#更新模板)并且集群升级到**使用更新版本的模板**时，集群才能改变。
|
||||
|
||||
要将现有集群转换为使用 RKE 模板：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要转换为使用 RKE 模板的集群。单击 **⋮ > 保存为 RKE 模板**。
|
||||
1. 在出现的表单中输入模板的名称，然后单击**创建**。
|
||||
|
||||
**结果**：
|
||||
|
||||
- 创建了一个新的 RKE 模板。
|
||||
- 将集群转换为使用该新模板。
|
||||
- 可以[使用新模板创建新集群](#使用-rke-模板创建集群)。
|
||||
+57
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: 模板创建者权限
|
||||
---
|
||||
|
||||
管理员有创建 RKE 模板的权限，只有管理员可以将该权限授予其他用户。
|
||||
|
||||
有关管理员权限的更多信息，请参阅[全局权限文档](../manage-role-based-access-control-rbac/global-permissions.md)。
|
||||
|
||||
## 授予用户创建模板的权限
|
||||
|
||||
只有具有**创建 RKE 模板**全局权限的用户才能创建模板。
|
||||
|
||||
管理员拥有创建模板的全局权限，只有管理员才能将该权限授予其他用户。
|
||||
|
||||
有关允许用户修改现有模板的信息，请参阅[共享模板](access-or-share-templates.md)。
|
||||
|
||||
管理员可以通过两种方式授予用户创建 RKE 模板的权限：
|
||||
|
||||
- 通过编辑[单个用户](#允许用户创建模板)的权限
|
||||
- 通过更改[新用户的默认权限](#默认允许新用户创建模板)
|
||||
|
||||
### 允许用户创建模板
|
||||
|
||||
管理员可以按照以下步骤将**创建 RKE 模板**角色单独授予给任何现有用户：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**用户**。
|
||||
1. 选择要编辑的用户，然后单击 **⋮ > 编辑配置**。
|
||||
1. 在**内置角色**中，选中**创建 RKE 集群模板**角色以及用户应具有的其他角色。你可能还需要选中**创建 RKE 模板修订版**复选框。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：用户拥有创建 RKE 模板的权限。
|
||||
|
||||
### 默认允许新用户创建模板
|
||||
|
||||
管理员也可以按照以下步骤为所有新用户授予创建 RKE 模板的默认权限。这不会影响现有用户的权限。
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**。
|
||||
1. 转到**创建 RKE 集群模板**角色，然后单击 **⋮ > 编辑配置**。
|
||||
1. 选择**是：新用户的默认角色**选项。
|
||||
1. 单击**保存**。
|
||||
1. 如果你希望新用户能够创建 RKE 模板修订，请将该角色设置为默认值。
|
||||
|
||||
**结果**：在此 Rancher 安装中创建的任何新用户都可以创建 RKE 模板。现有用户将不会获得此权限。
|
||||
|
||||
### 取消创建模板的权限
|
||||
|
||||
管理员可以通过以下步骤删除用户创建模板的权限。请注意，无论是否选择了细粒度权限，管理员都可以完全控制所有资源。
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**用户**。
|
||||
1. 选择要编辑权限的用户，然后单击 **⋮ > 编辑配置**。
|
||||
1. 在**内置角色**中，取消选中**创建 RKE 模板**和**创建 RKE 模板修订版**复选框（如果适用）。在此处，你可以将用户改回普通用户，或授予用户一组不同的权限。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：用户无法创建 RKE 模板。
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: 强制使用模板
|
||||
---
|
||||
|
||||
本节介绍模板管理员如何在 Rancher 中强制执行模板，从而限制用户在没有模板的情况下创建集群。
|
||||
|
||||
默认情况下，Rancher 中的任何普通用户都可以创建集群。但当开启强制使用 RKE 模板时，有以下约束：
|
||||
|
||||
- 只有管理员才能在没有模板的情况下创建集群。
|
||||
- 所有普通用户必须使用 RKE 模板来创建新集群。
|
||||
- 普通用户在不使用模板的情况下无法创建集群。
|
||||
|
||||
只有管理员[授予权限](creator-permissions.md#允许用户创建模板)后，用户才能创建新模板。
|
||||
|
||||
使用 RKE 模板创建集群后，集群创建者无法编辑模板中定义的设置。创建集群后更改这些设置的唯一方法是[将集群升级到相同模板的新修订版](apply-templates.md#更新使用-rke-模板创建的集群)。如果集群创建者想要更改模板定义的设置，他们需要联系模板所有者以获取模板的新版本。有关模板修订如何工作的详细信息，请参阅[修订模板](manage-rke1-templates.md#更新模板)。
|
||||
|
||||
## 强制新集群使用 RKE 模板
|
||||
|
||||
要求用户创建新集群时使用模板，可以确保[普通用户](../manage-role-based-access-control-rbac/global-permissions.md)启动的任何集群都使用经过管理员审核的 Kubernetes 和 Rancher 设置。
|
||||
|
||||
管理员可以通过以下步骤启用 RKE 模板强制，从而要求用户必须使用模板创建集群：
|
||||
|
||||
1. 单击 **☰ > 全局设置**。
|
||||
1. 转到 `cluster-template-enforcement` 设置。单击 **⋮ > 编辑设置**。
|
||||
1. 将值设置为 **True** 并单击**保存**。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
如果管理员将 `cluster-template-enforcement` 设置为 <b>True</b>，还需要与用户共享 `clusterTemplates`，以便用户可以选择其中一个模板来创建集群。
|
||||
|
||||
:::
|
||||
|
||||
**结果**：除非创建者是管理员，否则 Rancher 配置的所有集群都必须使用模板。
|
||||
|
||||
## 禁用 RKE 模板强制
|
||||
|
||||
管理员可以通过以下步骤关闭 RKE 模板强制，从而允许用户在没有 RKE 模板的情况下创建新集群：
|
||||
|
||||
1. 单击 **☰ > 全局设置**。
|
||||
1. 转到 `cluster-template-enforcement` 设置。单击 **⋮ > 编辑设置**。
|
||||
1. 将值设置为 **False** 并单击**保存**。
|
||||
|
||||
**结果**：在 Rancher 中创建集群时，用户不需要使用模板。
|
||||
+70
@@ -0,0 +1,70 @@
|
||||
---
|
||||
title: 示例场景
|
||||
---
|
||||
|
||||
以下示例场景描述了组织如何使用模板来标准化集群创建。
|
||||
|
||||
- **强制执行模板**：如果希望所有 Rancher 配置的新集群都具有某些设置，管理员可能想要[为每个用户强制执行一项或多项模板设置](#强制执行模板设置)。
|
||||
- **与不同的用户共享不同的模板**：管理员可以为[普通用户和高级用户提供不同的模板](#普通用户和高级用户模板)。这样，普通用户会有更多限制选项，而高级用户在创建集群时可以使用更多选项。
|
||||
- **更新模板设置**：如果组织的安全和 DevOps 团队决定将最佳实践嵌入到新集群所需的设置中，这些最佳实践可能会随着时间而改变。如果最佳实践发生变化，[可以将模板更新为新版本](#更新模板和集群)。这样，使用模板创建的集群可以升级到模板的新版本。
|
||||
- **共享模板的所有权**：当模板所有者不再想要维护模板或想要共享模板的所有权时，此方案描述了如何[授权模板所有权](#允许其他用户控制和共享模板)。
|
||||
|
||||
|
||||
## 强制执行模板设置
|
||||
|
||||
假设一个组织的管理员决定用 Kubernetes 版本 1.14 创建所有新集群：
|
||||
|
||||
1. 首先，管理员创建一个模板，将 Kubernetes 版本指定为 1.14，并将所有其他设置标记为**允许用户覆盖**。
|
||||
1. 管理员将模板公开。
|
||||
1. 管理员打开模板强制功能。
|
||||
|
||||
**结果**：
|
||||
|
||||
- 组织中的所有 Rancher 用户都可以访问该模板。
|
||||
- [普通用户](../manage-role-based-access-control-rbac/global-permissions.md)使用此模板创建的所有新集群都将使用 Kubernetes 1.14，它们无法使用其它 Kubernetes 版本。默认情况下，普通用户没有创建模板的权限。因此，除非与他们共享更多模板，否则此模板将是普通用户唯一可以使用的模板。
|
||||
- 所有普通用户都必须使用集群模板来创建新集群。他们无法在不使用模板的情况下创建集群。
|
||||
|
||||
通过这种方式，管理员在整个组织中强制执行 Kubernetes 版本，同时仍然允许最终用户配置其他所有内容。
|
||||
|
||||
## 普通用户和高级用户模板
|
||||
|
||||
假设一个组织有普通用户和高级用户。管理员希望普通用户必须使用模板，而高级用户和管理员可以根据自己的需要创建集群。
|
||||
|
||||
1. 首先，管理员开启 [RKE 模板强制执行](enforce-templates.md#强制新集群使用-rke-模板)。这意味着 Rancher 中的每个[普通用户](../manage-role-based-access-control-rbac/global-permissions.md)在创建集群时都需要使用 RKE 模板。
|
||||
1. 然后管理员创建两个模板：
|
||||
|
||||
- 一个普通用户模板，该模板除了访问密钥外，几乎指定了所有选项
|
||||
- 一个高级用户模板，该模板具有大部分或所有已启用**允许用户覆盖**的选项
|
||||
|
||||
1. 管理员仅与高级用户共享高级模板。
|
||||
1. 管理员将普通用户的模板公开，因此在 Rancher 中创建的 RKE 集群的每个人都能选择限制性更强的模板。
|
||||
|
||||
**结果**：除管理员外，所有 Rancher 用户在创建集群时都需要使用模板。每个人都可以访问限制模板，但只有高级用户有权使用更宽松的模板。普通用户会受到更多限制，而高级用户在配置 Kubernetes 集群时有更多选择。
|
||||
|
||||
## 更新模板和集群
|
||||
|
||||
假设一个组织有一个模板，该模板要求集群使用 Kubernetes v1.14。然而，随着时间的推移，管理员改变了主意。管理员现在希望用户能够升级集群，以使用更新版本的 Kubernetes。
|
||||
|
||||
在这个组织中，许多集群是用一个需要 Kubernetes v1.14 的模板创建的。由于模板不允许重写该设置，因此创建集群的用户无法直接编辑该设置。
|
||||
|
||||
模板所有者可以有以下几个选项，来允许集群创建者在集群上升级 Kubernetes：
|
||||
|
||||
- **在模板上指定 Kubernetes v1.15**：模板所有者可以创建指定 Kubernetes v1.15 的新模板修订版。然后使用该模板的每个集群的所有者可以将集群升级到模板的新版本。此模板升级允许集群创建者在集群上将 Kubernetes 升级到 v1.15。
|
||||
- **允许在模板上使用任何 Kubernetes 版本**：创建模板修订时，模板所有者还可以使用 Rancher UI 上该设置附近的开关，将 Kubernetes 版本标记为**允许用户覆盖**。该设置允许升级到此模板版本的集群使用任意 Kubernetes 的版本。
|
||||
- **允许在模板上使用最新的 Kubernetes 次要版本**：模板所有者还可以创建一个模板修订版，其中 Kubernetes 版本被定义为 **Latest v1.14（允许补丁版本升级）**。这意味着使用该版本的集群将能够进行补丁版本升级，但不支持主要版本升级。
|
||||
|
||||
## 允许其他用户控制和共享模板
|
||||
|
||||
假设 Alice 是 Rancher 管理员。她拥有一个 RKE 模板，该模板反映了她的组织为创建集群而商定的最佳实践。
|
||||
|
||||
Bob 是一位高级用户，可以就集群配置做出明智的决策。随着最佳实践随着时间的推移不断更新，Alice 相信 Bob 会为她的模板创建新的修订。因此，她决定让 Bob 成为模板的所有者。
|
||||
|
||||
为了与 Bob 共享模板的所有权，Alice [将 Bob 添加为模板的所有者](access-or-share-templates.md#共享模板所有权)。
|
||||
|
||||
结果是，作为模板所有者，Bob 负责该模板的版本控制。Bob 现在可以执行以下所有操作：
|
||||
|
||||
- 当最佳实践发生变化时[修改模板](manage-rke1-templates.md#更新模板)
|
||||
- [禁用模板的过时修订](manage-rke1-templates.md#禁用模板修订版)，以禁止使用该模板来创建集群
|
||||
- 如果组织想要改变方向，则[删除整个模板](manage-rke1-templates.md#删除模板)
|
||||
- [将某个版本设置为默认值](manage-rke1-templates.md#将模板修订版设置为默认)，用于用户创建集群。模板的最终用户仍然可以选择他们想要使用哪个版本来创建集群。
|
||||
- [与特定用户共享模板](access-or-share-templates.md)，让所有 Rancher 用户都可以使用该模板，或与其他用户共享该模板的所有权。
|
||||
+68
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: RKE 模板和基础设施
|
||||
---
|
||||
|
||||
在 Rancher 中，RKE 模板用于配置 Kubernetes 和定义 Rancher 设置，而节点模板则用于配置节点。
|
||||
|
||||
因此，即使开启了 RKE 模板强制，最终用户在创建 Rancher 集群时仍然可以灵活选择底层硬件。RKE 模板的最终用户仍然可以选择基础设施提供商和他们想要使用的节点。
|
||||
|
||||
如果要标准化集群中的硬件，请将 RKE 模板与节点模板或服务器配置工具 (如 Terraform) 结合使用。
|
||||
|
||||
### 节点模板
|
||||
|
||||
[节点模板](../../../../reference-guides/user-settings/manage-node-templates.md)负责 Rancher 中的节点配置和节点预配。你可以在用户配置文件中设置节点模板，从而定义在每个节点池中使用的模板。启用节点池后，可以确保每个节点池中都有所需数量的节点，并确保池中的所有节点都相同。
|
||||
|
||||
### Terraform
|
||||
|
||||
Terraform 是一个服务器配置工具。它使用基础架构即代码，支持使用 Terraform 配置文件创建几乎所有的基础设施。它可以自动执行服务器配置，这种方式是自文档化的，并且在版本控制中易于跟踪。
|
||||
|
||||
本节重点介绍如何将 Terraform 与 [Rancher 2 Terraform Provider](https://www.terraform.io/docs/providers/rancher2/) 一起使用，这是标准化 Kubernetes 集群硬件的推荐选项。如果你使用 Rancher Terraform Provider 来配置硬件，然后使用 RKE 模板在该硬件上配置 Kubernetes 集群，你可以快速创建一个全面的、可用于生产的集群。
|
||||
|
||||
Terraform 支持：
|
||||
|
||||
- 定义几乎任何类型的基础架构即代码，包括服务器、数据库、负载均衡器、监控、防火墙设置和 SSL 证书
|
||||
- 跨多个平台（包括 Rancher 和主要云提供商）对基础设施进行编码
|
||||
- 将基础架构即代码提交到版本控制
|
||||
- 轻松重复使用基础设施的配置和设置
|
||||
- 将基础架构更改纳入标准开发实践
|
||||
- 防止由于配置偏移，导致一些服务器的配置与其他服务器不同
|
||||
|
||||
## Terraform 工作原理
|
||||
|
||||
Terraform 是用扩展名为 `.tf` 的文件编写的。它是用 HashiCorp 配置语言编写的。HashiCorp 配置语言是一种声明性语言，支持定义集群中所需的基础设施、正在使用的云提供商以及提供商的凭证。然后 Terraform 向提供商发出 API 调用，以便有效地创建基础设施。
|
||||
|
||||
要使用 Terraform 创建 Rancher 配置的集群，请转到你的 Terraform 配置文件并将提供商定义为 Rancher 2。你可以使用 Rancher API 密钥设置你的 Rancher 2 提供商。请注意，API 密钥与其关联的用户具有相同的权限和访问级别。
|
||||
|
||||
然后 Terraform 会调用 Rancher API 来配置你的基础设施，而 Rancher 调用基础设施提供商。例如，如果你想使用 Rancher 在 AWS 上预配基础设施，你需要在 Terraform 配置文件或环境变量中提供 Rancher API 密钥和 AWS 凭证，以便它们用于预配基础设施。
|
||||
|
||||
如果你需要对基础设施进行更改，你可以在 Terraform 配置文件中进行更改，而不是手动更新服务器。然后，可以将这些文件提交给版本控制、验证，并根据需要进行检查。然后，当你运行 `terraform apply` 时，更改将会被部署。
|
||||
|
||||
## 使用 Terraform 的技巧
|
||||
|
||||
- [Rancher 2 提供商文档](https://www.terraform.io/docs/providers/rancher2/)提供了如何配置集群大部分的示例。
|
||||
|
||||
- 在 Terraform 设置中，你可以使用 Docker Machine 主机驱动来安装 Docker Machine。
|
||||
|
||||
- 可以在 Terraform Provider 中修改身份验证。
|
||||
|
||||
- 可以通过更改 Rancher 中的设置，来反向工程如何在 Terraform 中定义设置，然后返回并检查 Terraform 状态文件，以查看该文件如何映射到基础设施的当前状态。
|
||||
|
||||
- 如果你想在一个地方管理 Kubernetes 集群设置、Rancher 设置和硬件设置，请使用 [Terraform 模块](https://github.com/rancher/terraform-modules)。你可以将集群配置 YAML 文件或 RKE 模板配置文件传递给 Terraform 模块，以便 Terraform 模块创建它。在这种情况下，你可以使用基础架构即代码来管理 Kubernetes 集群及其底层硬件的版本控制和修订历史。
|
||||
|
||||
## 创建符合 CIS 基准的集群的技巧
|
||||
|
||||
本节描述了一种方法，可以使安全合规相关的配置文件成为集群的标准配置文件。
|
||||
|
||||
在你创建[符合 CIS 基准的集群](../../../../pages-for-subheaders/rancher-security.md)时，你有一个加密配置文件和一个审计日志配置文件。
|
||||
|
||||
你的基础设施预配系统可以将这些文件写入磁盘。然后在你的 RKE 模板中，你需要指定这些文件的位置，然后将你的加密配置文件和审计日志配置文件作为额外的挂载添加到 `kube-api-server`。
|
||||
|
||||
然后，你需要确保 RKE 模板中的 `kube-api-server` 标志使用符合 CIS 的配置文件。
|
||||
|
||||
通过这种方式，你可以创建符合 CIS 基准的标志。
|
||||
|
||||
## 资源
|
||||
|
||||
- [Terraform 文档](https://www.terraform.io/docs/)
|
||||
- [Rancher2 Terraform Provider 文档](https://www.terraform.io/docs/providers/rancher2/)
|
||||
- [The RanchCast - 第 1 集：Rancher 2 Terraform Provider](https://youtu.be/YNCq-prI8-8)：在此演示中，社区主管 Jason van Brackel 使用 Rancher 2 Terraform Provider 创建了节点并创建自定义集群。
|
||||
+163
@@ -0,0 +1,163 @@
|
||||
---
|
||||
title: 创建和修改 RKE 模板
|
||||
---
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
本节介绍如何管理 RKE 模板和修订版。你可以从 **RKE1 配置 > RKE 模板**下的**集群管理**视图创建、共享、更新和删除模板。
|
||||
|
||||
模板更新通过修订系统处理。当模板所有者想要更改或更新模板时，他们会创建模板的新版本。单个修订无法编辑。但是，如果你想防止使用修订来创建新集群，你可以禁用它。
|
||||
|
||||
你可以使用两种方式来使用模板修订：创建新集群，或升级使用较早版本的模板创建的集群。模板创建者可以设置默认修订版，但是在最终用户创建集群时，他们可以选择任何模板以及可供使用的任何模板修订版。使用指定的修订版创建集群后，就无法将其更改为另一个模板，但是可以将集群升级为同一模板的较新的可用修订版。
|
||||
|
||||
模板所有者对模板修订版具有完全控制权，并且可以创建新的修订版来更新模板，删除或禁用不应被用于创建集群的修订版，和设置默认的模板修订版。
|
||||
|
||||
|
||||
### 先决条件
|
||||
|
||||
如果你具有**创建 RKE 模板**权限，则可以创建 RKE 模板，该权限可由[管理员授予](creator-permissions.md)。
|
||||
|
||||
如果你是模板的所有者，你可以修改、共享和删除模板。有关如何成为模板所有者的详细信息，请参阅[共享模板所有权文档](access-or-share-templates.md#共享模板所有权)。
|
||||
|
||||
### 创建模板
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 单击 **RKE1 配置 > 节点模板**。
|
||||
1. 单击**添加模板**。
|
||||
1. 输入模板的名称。Rancher 已经为模板的第一个版本自动生成了名称，该版本与该模板一起创建。
|
||||
1. 可选：通过将用户添加为成员，来[与其他用户或组共享模板](access-or-share-templates.md#与特定用户或组共享模板)。你还可以将模板公开，从而与 Rancher 中的所有人共享。
|
||||
1. 然后按照屏幕上的表格将集群配置参数保存为模板修订的一部分。可以将修订标记为此模板的默认值。
|
||||
|
||||
**结果**：配置了具有一个修订版的 RKE 模板。你可以稍后在[配置 Rancher 启动的集群](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)时使用此 RKE 模板修订版。通过 RKE 模板管理集群后，集群无法解除与模板的绑定，并且无法取消选中**使用现有 RKE 模板和修订版**。
|
||||
|
||||
### 更新模板
|
||||
|
||||
更新 RKE 模板相当于创建现有模板的修订版。使用旧版本模板创建的集群可以进行更新，从而匹配新版本。
|
||||
|
||||
你不能编辑单个修订。由于你无法编辑模板的单个修订，为了防止使用某个修订，你可以[禁用该修订版](#禁用模板修订版)。
|
||||
|
||||
创建新模板修订时，使用旧模板修订的集群不受影响。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在左侧导航栏，单击 **RKE1 配置 > RKE 模板**。
|
||||
1. 转到要编辑的模板，然后单击 **⋮ > 编辑**。
|
||||
1. 编辑所需信息并单击**保存**。
|
||||
1. 可选：你可以更改此模板的默认修订版，也可以更改共享对象。
|
||||
|
||||
**结果**：模板已更新。要将其应用到使用旧版本模板的集群，请参阅[升级集群以使用新的模板修订版](#升级集群以使用新的模板修订版)。
|
||||
|
||||
### 删除模板
|
||||
|
||||
当不再需要为任何集群使用某个 RKE 模板时，可以将其删除。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 单击 **RKE1 配置 > RKE 模板**。
|
||||
1. 转到要删除的 RKE 模板，然后单击 **⋮ > 删除**。
|
||||
1. 确认删除。
|
||||
|
||||
**结果**：模板被删除。
|
||||
|
||||
### 基于默认版创建新修订版
|
||||
|
||||
你可以复制默认模板修订版并快速更新其设置，而无需从头开始创建新修订版。克隆模板为你省去了重新输入集群创建所需的访问密钥和其他参数的麻烦。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在左侧导航栏，单击 **RKE1 配置 > RKE 模板**。
|
||||
1. 转到要克隆的 RKE 模板，然后单击 **⋮ > 基于默认版创建新修订版**。
|
||||
1. 填写表单的其余部分来创建新修订。
|
||||
|
||||
**结果**：克隆并配置了 RKE 模板修订版。
|
||||
|
||||
### 基于克隆版创建新修订版
|
||||
|
||||
通过用户设置创建新的 RKE 模板修订版时，可以克隆现有修订版并快速更新其设置，而无需从头开始创建新的修订版。克隆模板修订省去了重新输入集群参数的麻烦。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在 **RKE1 配置**下，单击 **RKE 模板**。
|
||||
1. 转到要克隆的模板修订。然后选择 **⋮ > 克隆修订版**。
|
||||
1. 填写表单的其余部分。
|
||||
|
||||
**结果**：克隆并配置了 RKE 模板修订版。你可以在配置集群时使用 RKE 模板修订。任何使用此 RKE 模板的现有集群都可以升级到此新版本。
|
||||
|
||||
### 禁用模板修订版
|
||||
|
||||
当你不需要将 RKE 模板修订版本用于创建新集群时，可以禁用模板修订版。你也可以重新启用禁用了的修订版。
|
||||
|
||||
如果没有任何集群使用该修订，你可以禁用该修订。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在左侧导航栏，单击 **RKE1 配置 > RKE 模板**。
|
||||
1. 转到要禁用的模板修订版。然后选择 **⋮ > 禁用**。
|
||||
|
||||
**结果**：RKE 模板修订版不能用于创建新集群。
|
||||
|
||||
### 重新启用禁用的模板修订版
|
||||
|
||||
如果要使用已禁用的 RKE 模板修订版来创建新集群，你可以重新启用该修订版。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在 **RKE1 配置**下，单击 **RKE 模板**。
|
||||
1. 转到要重新启用的模板修订。然后选择 **⋮ > 启用**。
|
||||
|
||||
**结果**：RKE 模板修订版可用于创建新集群。
|
||||
|
||||
### 将模板修订版设置为默认
|
||||
|
||||
当最终用户使用 RKE 模板创建集群时，他们可以选择使用哪个版本来创建集群。你可以配置默认使用的版本。
|
||||
|
||||
要将 RKE 模板修订版设置为默认：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在左侧导航栏，单击 **RKE1 配置 > RKE 模板**。
|
||||
1. 转到要设为默认的 RKE 模板修订版，然后单击 **⋮ > 设为默认配置**。
|
||||
|
||||
**结果**：使用模板创建集群时，RKE 模板修订版将用作默认选项。
|
||||
|
||||
### 删除模板修订版
|
||||
|
||||
你可以删除模板的所有修订（默认修订除外）。
|
||||
|
||||
要永久删除修订版：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在左侧导航栏，单击 **RKE1 配置 > RKE 模板**。
|
||||
1. 转到要删除的 RKE 模板修订版，然后单击 **⋮ > 删除**。
|
||||
|
||||
**结果**：RKE 模板修订版被删除。
|
||||
|
||||
### 升级集群以使用新的模板修订版
|
||||
|
||||
:::note
|
||||
|
||||
本部分假设你已经有一个集群，该集群[应用了 RKE 模板](apply-templates.md)。
|
||||
|
||||
本部分还假设你已[更新了集群使用的模板](#更新模板)，以便可以使用新的模板修订版。
|
||||
|
||||
:::
|
||||
|
||||
要将集群升级到使用新的模板修订版：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要升级的集群，然后单击 **⋮ > 编辑配置**。
|
||||
1. 在**集群选项**中，单击模板修订版的下拉菜单，然后选择新的模板修订版。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：集群已升级为使用新模板修订版中定义的设置。
|
||||
|
||||
### 将正在运行的集群导出到新的 RKE 模板和修订版
|
||||
|
||||
你可以将现有集群的设置保存为 RKE 模板。
|
||||
|
||||
这将把集群的设置导出为新的 RKE 模板，并且将集群绑定到该模板。然后，只有[更新了模板](#更新模板)并且集群升级到[使用更新版本的模板](#升级集群以使用新的模板修订版)时，集群才能改变。
|
||||
|
||||
要将现有集群转换为使用 RKE 模板：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到将被转换为使用 RKE 模板的集群，然后 **⋮ > 保存为 RKE 模板**。
|
||||
1. 在出现的表单中输入 RKE 模板的名称，然后单击**创建**。
|
||||
|
||||
**结果**：
|
||||
|
||||
- 创建了一个新的 RKE 模板。
|
||||
- 将集群转换为使用该新模板。
|
||||
- 可以[使用新模板和修订版创建新集群。](apply-templates.md#使用-rke-模板创建集群)
|
||||
+14
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: 覆盖模板设置
|
||||
---
|
||||
|
||||
用户创建 RKE 模板时，模板中的每个设置在 Rancher UI 中都有一个开关，指示用户是否可以覆盖该设置。此开关将这些设置标记为**允许用户覆盖**。打开开关表示用户可以修改对应的参数，关闭开关表示用户无权修改对应的参数。
|
||||
|
||||
使用模板创建集群后，除非模板所有者将设置标记为**允许用户覆盖**，否则最终用户无法更新模板中定义的任何设置。但是，如果模板[更新到新修订版](manage-rke1-templates.md)，且该修订版更改了设置或允许最终用户更改设置，则集群可以升级到模板的新修订版，并且新修订版中的更改将应用于集群。
|
||||
|
||||
如果 RKE 模板上的任何参数设置为**允许用户覆盖**，最终用户必须在集群创建期间设置这些字段，然后他们可以随时编辑这些设置。
|
||||
|
||||
RKE 模板的**允许用户覆盖**选项的适用场景如下：
|
||||
|
||||
- 管理员认为某些参数需要保持灵活性，以便随时更新。
|
||||
- 最终用户将需要输入他们自己的访问密钥或密文密钥，例如，云凭证或备份快照的凭证。
|
||||
+146
@@ -0,0 +1,146 @@
|
||||
---
|
||||
title: 配置认证
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config"/>
|
||||
</head>
|
||||
|
||||
Rancher 为 Kubernetes 添加的一个关键功能是集中式用户认证，这个特性允许用户使用一组凭证对任何 Kubernetes 集群进行身份认证。
|
||||
|
||||
这种集中式用户认证是通过 Rancher 的认证代理完成的，该代理与 Rancher 的其余部分一并安装，此代理对用户进行认证并通过一个 Service Acount 将请求转发到 Kubernetes 集群中。
|
||||
|
||||
:::warning
|
||||
|
||||
用来启用外部认证的账户将被授予管理员权限。如果你使用一个测试账号或非管理员账号，该账号仍然会被授予管理员级别权限。请查看[外部认证配置和主体用户](#外部认证配置和用户主体)了解原因。
|
||||
|
||||
:::
|
||||
|
||||
## 外部认证与本地认证
|
||||
|
||||
Rancher 认证代理可以与以下外部认证服务集成。
|
||||
|
||||
| 认证服务 |
|
||||
| ---------------------------------------------------------------------------------------------------------------------- |
|
||||
| [Microsoft Active Directory](configure-active-directory.md) |
|
||||
| [GitHub](configure-github.md) |
|
||||
| [Microsoft Azure AD](configure-azure-ad.md) |
|
||||
| [FreeIPA](configure-freeipa.md) |
|
||||
| [OpenLDAP](../configure-openldap/configure-openldap.md) |
|
||||
| [Microsoft AD FS](../configure-microsoft-ad-federation-service-saml/configure-microsoft-ad-federation-service-saml.md) |
|
||||
| [PingIdentity](configure-pingidentity.md) |
|
||||
| [Keycloak (OIDC)](configure-keycloak-oidc.md) |
|
||||
| [Keycloak (SAML)](configure-keycloak-saml.md) |
|
||||
| [Okta](configure-okta-saml.md) |
|
||||
| [Google OAuth](configure-google-oauth.md) |
|
||||
| [Shibboleth](../configure-shibboleth-saml/configure-shibboleth-saml.md) |
|
||||
|
||||
当然，Rancher 也提供[本地认证](create-local-users.md).
|
||||
|
||||
在多数情况下，你应该使用外部认证服务而不是使用本地认证，因为外部认证服务可以集中式的对用户进行管理。但是在极少数情况下，例如外部认证服务不可用或正在维护时，你可能需要使用本地认证用户来管理 Rancher。
|
||||
|
||||
## 用户和组
|
||||
|
||||
:::note
|
||||
|
||||
- Local authentication does not support creating or managing groups.
|
||||
- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider.
|
||||
|
||||
:::
|
||||
|
||||
Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
|
||||
|
||||
更多信息，请查看[用户和组](manage-users-and-groups.md)
|
||||
|
||||
## Rancher 授权范围
|
||||
|
||||
当你配置完 Rancher 使用外部认证服务后，你可以配置允许谁登录和使用 Rancher，包含如下的选项：
|
||||
|
||||
| 访问级别 | 描述 |
|
||||
| ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 允许任何有效用户 | 在认证服务中的*任何*用户都可以访问 Rancher。通常情况下不建议使用该设置！ |
|
||||
| 允许集群和项目成员，以及授权的用户和组织 | 认证服务中属于**集群成员**或**项目成员**的用户或组成员都可以登录 Rancher。此外添加在**授权的用户和组织**列表中的用户和组成员也可以登录到 Rancher。 |
|
||||
| 仅限于授权的用户可以访问 | 仅有在授权用户和组织列表中的用户和组成员可以登录到 Rancher。 |
|
||||
|
||||
要在授权服务中为用户设置 Rancher 访问级别，请执行以下步骤：
|
||||
|
||||
1. 在左上角，点击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，点击 **认证**.
|
||||
1. 设置完外部认证详细信息后，使用 **站点访问** 选项配置用户权限范围，上面的表格说明了每个选项的访问级别。
|
||||
1. 可选：如果你选择 **允许任何有效用户** 以外的选项，你可以通过在出现的文本框中搜索用户，将用户添加到授权用户和组织的列表中。
|
||||
1. 点击 **保存**。
|
||||
|
||||
**结果:** Rancher 的访问配置被应用。
|
||||
|
||||
:::note SAML 认证警告:
|
||||
|
||||
- SAML 协议不支持搜索或查找用户或组。因此，将用户或组添加到 Rancher 时不会对其进行验证。
|
||||
- 添加用户时，必须正确输入确切的用户 ID（即 UID 字段）。键入用户 ID 时，将不会搜索可能匹配的其他用户 ID。
|
||||
- 添加组时，必须从文本框旁边的下拉列表中选择组。Rancher 假定来自文本框的任何输入都是用户。
|
||||
- 用户组下拉列表仅显示您所属的用户组。您将无法添加您不是其成员的组。
|
||||
|
||||
:::
|
||||
|
||||
## 外部认证配置和用户主体
|
||||
|
||||
配置外部认证需要：
|
||||
|
||||
- 分配了管理员角色的本地用户，以下称为 _本地主体_。
|
||||
- 可以使用外部认证服务进行认证的外部用户，以下简称为 _外部主体_。
|
||||
|
||||
外部认证的配置也会影响 Rancher 中主体用户的管理方式，具体地说，当用户账户启用了外部认证时，将授予其管理员级别的权限。这是因为本地主体和外部主体共享相同的用户 ID 和访问权限。
|
||||
|
||||
以下说明演示了这些效果：
|
||||
|
||||
1. 作为本地主体登录到 Rancher 并完成外部身份验证的配置。
|
||||
|
||||
|
||||
|
||||
2. Rancher 将外部主体与本地主体相关联。这两个用户共享本地主体的用户 ID。
|
||||
|
||||
|
||||
|
||||
3. 完成配置后，Rancher 将自动退出本地主体。
|
||||
|
||||
|
||||
|
||||
4. 然后，Rancher 会自动将您登录外部主体。
|
||||
|
||||
|
||||
|
||||
5. 因为外部主体和本地主体共享一个 ID，所以用户列中不会再单独显示一个另外的外部主体的对象。
|
||||
|
||||
|
||||
|
||||
6. 外部主体和本地主体共享相同的访问权限。
|
||||
|
||||
:::note 重新配置先前设置的认证
|
||||
|
||||
如果需要重新配置或禁用后重新启用先前设置过的认证，请确保尝试这样做的用户以外部用户身份登录到 Rancher，而不是使用本地管理员登录。
|
||||
|
||||
:::
|
||||
|
||||
## 禁用认证
|
||||
|
||||
当你禁用认证时，Rancher 会删除所有与之关联的资源，例如：
|
||||
|
||||
- 密文
|
||||
- 绑定的全局角色。
|
||||
- 绑定的集群角色。
|
||||
- 绑定的项目角色。
|
||||
- 与外部认证关联但从未以本地用户身份登录 Rancher 的外部用户。
|
||||
|
||||
由于此操作可能会导致许多资源丢失，因此你可能需要添加一些保护措施。若要确保禁用外部认证时不执行清理流程，需要为外部认证的配置添加特殊的注释。
|
||||
|
||||
例如，若要对 Azure AD 认证增加保护措施，你需要在 authconfig 对象上增加 `azuread` 注释：
|
||||
|
||||
`kubectl annotate --overwrite authconfig azuread management.cattle.io/auth-provider-cleanup='user-locked'`
|
||||
|
||||
禁用 Azure AD 认证后，Rancher 不会执行清理流程，直到你将该注解设置为 `unlocked`。
|
||||
|
||||
### 手动运行资源清理
|
||||
|
||||
Rancher 可能会在本地集群中保留之前禁用的外部认证配置的资源，即使你配置对接了另一种认证也是如此。例如，如果你对接了 A 认证，然后禁用它，并重新对接使用 B 认证，当你升级到新版本的 Rancher 时，你可以手动触发对认证 A 配置的资源清理。
|
||||
|
||||
要手动触发已禁用的认证配置的清理，请将 `unlocked` 值添加到对应认证配置的 `management.cattle.io/auth-provider-cleanup` 注解中。
|
||||
+219
@@ -0,0 +1,219 @@
|
||||
---
|
||||
title: 配置 Active Directory (AD)
|
||||
---
|
||||
|
||||
如果你的组织使用 Microsoft Active Directory 作为中心用户仓库，你可以将 Rancher 配置为与 Active Directory 服务器通信，从而对用户进行身份验证。这使 Rancher 管理员可以对外部用户系统中的用户和组进行集群和项目的访问控制，同时允许最终用户在登录 Rancher UI 时使用 Active Directory 凭证进行身份验证。
|
||||
|
||||
Rancher 使用 LDAP 与 Active Directory 服务器通信。因此，Active Directory 与 [OpenLDAP 身份验证](../../../../pages-for-subheaders/configure-openldap.md)的流程相同。
|
||||
|
||||
:::note
|
||||
|
||||
在开始之前，请熟悉[外部身份验证配置和主体用户](../../../../pages-for-subheaders/authentication-config.md#外部身份验证配置和用户主体)的概念。
|
||||
|
||||
:::
|
||||
|
||||
## 先决条件
|
||||
|
||||
你需要创建或从你的 AD 管理员处获取一个新的 AD 用户，用作 Rancher 的 ServiceAccount。此用户必须具有足够的权限，才能执行 LDAP 搜索并读取你的 AD 域下的用户和组的属性。
|
||||
|
||||
通常可以使用（非管理员）**域用户**账号，因为默认情况下，该用户对域分区中的大多数对象具有只读特权。
|
||||
|
||||
但是，请注意，在某些锁定的 Active Directory 配置中，此默认操作可能不适用。在这种情况下，你需要确保 ServiceAccount 用户在 Base OU（包含用户和组）上或全局范围内至少拥有域的 **Read** 和 **List Content** 权限。
|
||||
|
||||
:::note 使用 TLS？
|
||||
|
||||
- 如果 AD 服务器使用的证书是自签名的或不是来自认可的证书颁发机构，请确保手头有 PEM 格式的 CA 证书（包含所有中间证书）。你必须在配置期间粘贴此证书，以便 Rancher 能够验证证书链。
|
||||
|
||||
- 升级到 v2.6.0 后，如果 AD 服务器上的证书不支持 SAN 属性，则使用 TLS 通过 Rancher 对 Active Directory 进行身份验证可能会失败。这是 Go v1.15 中默认启用的检查。
|
||||
|
||||
- 收到"Error creating SSL connection: LDAP Result Code 200 "Network Error": x509 错误：证书依赖于旧的通用名称（Common Name）字段，使用 SAN 或临时启用与 GODEBUG=x509ignoreCN=0 匹配的通用名称。
|
||||
|
||||
- 要解决此错误，请使用支持 SAN 属性的新证书更新或替换 AD 服务器上的证书。或者，将 `GODEBUG=x509ignoreCN=0` 设置为 Rancher Server 容器的环境变量来忽略此错误。
|
||||
|
||||
:::
|
||||
|
||||
## 配置步骤
|
||||
### 打开 Active Directory 配置
|
||||
|
||||
1. 使用初始的本地 `admin` 账号登录到 Rancher UI。
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **ActiveDirectory**。然后会显示**验证提供程序：ActiveDirectory** 的表单。
|
||||
1. 填写表单。如果需要获取帮助，请参见下方的配置选项详情。
|
||||
1. 点击**启用**。
|
||||
|
||||
### 配置 Active Directory 服务器
|
||||
|
||||
在 `1. 配置 Active Directory 服务器` 的步骤中，使用你 Active Directory 的实际信息完成字段配置。有关每个参数所需值的详细信息，请参阅下表。
|
||||
|
||||
:::note
|
||||
|
||||
如果你不确定要在用户/组`搜索库`字段中输入什么值，请参见[使用 ldapsearch 确定搜索库和 Schema](#附录使用-ldapsearch-确定搜索库和-schema)。
|
||||
|
||||
:::
|
||||
|
||||
**表 1：AD 服务器参数**
|
||||
|
||||
| 参数 | 描述 |
|
||||
|:--|:--|
|
||||
| 主机名 | 指定 AD 服务器的主机名或 IP 地址。 |
|
||||
| 端口 | 指定 AD 服务器监听连接的端口。未加密的 LDAP 通常使用 389 的标准端口，而 LDAPS 使用 636 端口。 |
|
||||
| TLS | 选中此框可启用 SSL/TLS 上的 LDAP（通常称为 LDAPS）。 |
|
||||
| 服务器连接超时 | Rancher 在认为无法访问 AD 服务器之前等待的时间（秒）。 |
|
||||
| ServiceAccount 用户名 | 输入对域分区具有只读访问权限的 AD 账号的用户名（参见[先决条件](#先决条件)）。用户名可以用 NetBIOS（例如 "DOMAIN\serviceaccount"）或 UPN 格式（例如 "serviceaccount@domain.com"）。 |
|
||||
| ServiceAccount 密码 | ServiceAccount 的密码。 |
|
||||
| 默认登录域 | 如果你使用 AD 域的 NetBIOS 名称配置此字段，在绑定到 AD 服务器时，没有包含域的用户名（例如“jdoe”）将自动转换为带斜杠的 NetBIOS 登录（例如，“LOGIN_DOMAIN\jdoe”）。如果你的用户以 UPN（例如，"jdoe@acme.com"）作为用户名进行身份验证，则此字段必须**必须**留空。 |
|
||||
| 用户搜索库 | 输入目录树中开始搜索用户对象的节点的标识名称（DN）。所有用户都必须是此基础标识名称的后代。例如，"ou=people,dc=acme,dc=com"。 |
|
||||
| 组搜索库 | 如果组位于`用户搜索库`下配置的节点之外的其他节点下，则需要在此处提供标识名称。否则请留空。例如："ou=groups,dc=acme,dc=com"。 |
|
||||
|
||||
---
|
||||
|
||||
### 配置用户/组 Schema
|
||||
|
||||
在 `2. 自定义 Schema` 中，你必须为 Rancher 提供与目录中使用的 Schema 对应的用户和组属性的正确映射。
|
||||
|
||||
Rancher 使用 LDAP 查询来搜索和检索关于 Active Directory 中的用户和组的信息。本节中配置的属性映射用于构造搜索筛选器和解析组成员身份。因此，所提供的设置需要反映你 AD 域的真实情况。
|
||||
|
||||
:::note
|
||||
|
||||
如果你不熟悉 Active Directory 域中使用的 Schema，请参见[使用 ldapsearch 确定搜索库和 Schema](#附录使用-ldapsearch-确定搜索库和-schema) 来确定正确的配置值。
|
||||
|
||||
:::
|
||||
|
||||
#### 用户 Schema
|
||||
|
||||
下表详细说明了用户 Schema 配置的参数。
|
||||
|
||||
**表 2：用户 Schema 配置参数**
|
||||
|
||||
| 参数 | 描述 |
|
||||
|:--|:--|
|
||||
| Object Class | 域中用于用户对象的对象类别名称。如果定义了此参数，则仅指定对象类别的名称 - *请勿*将其放在 LDAP 包装器中，例如 `&(objectClass=xxxx)`。 |
|
||||
| Username Attribute | 用户属性的值适合作为显示名称。 |
|
||||
| Login Attribute | 登录属性的值与用户登录 Rancher 时输入的凭证的用户名部分匹配。如果你的用户以他的 UPN（例如 "jdoe@acme.com"）作为用户名进行身份验证，则此字段通常必须设置为 `userPrincipalName`。否则，对于旧的 NetBIOS 风格的登录名（例如 "jdoe"），则通常设为 `sAMAccountName`。 |
|
||||
| User Member Attribute | 包含用户所属组的属性。 |
|
||||
| Search Attribute | 当用户输入文本以在用户界面中添加用户或组时，Rancher 会查询 AD 服务器，并尝试根据此设置中提供的属性匹配用户。可以通过使用管道（“\|”）符号分隔属性来指定多个属性。要匹配 UPN 用户名（例如 jdoe@acme.com），通常应将此字段的值设置为 `userPrincipalName`。 |
|
||||
| Search Filter | 当 Rancher 尝试将用户添加到网站访问列表，或尝试将成员添加到集群或项目时，此筛选器将应用于搜索的用户列表。例如，用户搜索筛选器可能是 <code>(|(memberOf=CN=group1,CN=Users,DC=testad,DC=rancher,DC=io)(memberOf=CN=group2,CN=Users,DC=testad,DC=rancher,DC=io))</code>。注意：如果搜索筛选器未使用[有效的 AD 搜索语法](https://docs.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax)，则用户列表将为空。 |
|
||||
| User Enabled Attribute | 该属性是一个整数值，代表用户账号标志的枚举。Rancher 使用此选项来确定用户账号是否已禁用。通常应该将此参数设置为 AD 标准的 `userAccountControl`。 |
|
||||
| Disabled Status Bitmask | 指定的禁用用户账号的 `User Enabled Attribute` 的值。通常，你应该将此参数设置为 Microsoft Active Directory Schema 中指定的默认值 2（请参见[此处](https://docs.microsoft.com/en-us/windows/desktop/adschema/a-useraccountcontrol#remarks)）。 |
|
||||
|
||||
---
|
||||
|
||||
#### 组 Schema
|
||||
|
||||
下表详细说明了组 Schema 配置的参数。
|
||||
|
||||
**表 3：组 Schema 配置参数**
|
||||
|
||||
| 参数 | 描述 |
|
||||
|:--|:--|
|
||||
| Object Class | 域中用于组对象的对象类别名称。如果定义了此参数，则仅指定对象类别的名称 - *请勿*将其放在 LDAP 包装器中，例如 `&(objectClass=xxxx)`。 |
|
||||
| Name Attribute | 名称属性的值适合作为显示名称。 |
|
||||
| Group Member User Attribute | **用户属性**的名称。它的格式与 `Group Member Mapping Attribute` 中的组成员匹配。 |
|
||||
| Group Member Mapping Attribute | 包含组成员的组属性的名称。 |
|
||||
| Search Attribute | 在将组添加到集群或项目时，用于构造搜索筛选器的属性。请参见用户 Schema 的 `Search Attribute`。 |
|
||||
| Search Filter | 当 Rancher 尝试将组添加到网站访问列表，或将组添加到集群或项目时，此筛选器将应用于搜索的组列表。例如，组搜索筛选器可以是 <code>(|(cn=group1)(cn=group2))</code>。注意：如果搜索筛选器未使用[有效的 AD 搜索语法](https://docs.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax)，则组列表将为空。 |
|
||||
| Group DN Attribute | 组属性的名称，其格式与描述用户成员身份的用户属性中的值匹配。参见 `User Member Attribute`。 |
|
||||
| Nested Group Membership | 此设置定义 Rancher 是否应解析嵌套组成员身份。仅当你的组织使用这些嵌套成员身份时才使用（即你有包含其他组作为成员的组。我们建议尽量避免使用嵌套组，从而避免在存在大量嵌套成员时出现潜在的性能问题）。 |
|
||||
|
||||
---
|
||||
|
||||
### 测试身份验证
|
||||
|
||||
完成配置后，请**使用你的 AD 管理员账户**测试与 AD 服务器的连接。如果测试成功，将启用配置的 Active Directory 身份验证，测试时使用的账号会成为管理员。
|
||||
|
||||
:::note
|
||||
|
||||
与此步骤中输入的凭证相关的 AD 用户将映射到本地主体账号，并在 Rancher 中分配系统管理员权限。因此，你应该决定使用哪个 AD 账号来执行此步骤。
|
||||
|
||||
:::
|
||||
|
||||
1. 输入应映射到本地主体账号的 AD 账号的**用户名**和**密码** 。
|
||||
2. 点击**启用 Active Directory 认证**来完成设置。
|
||||
|
||||
**结果**：
|
||||
|
||||
- 已启用 Active Directory 身份验证。
|
||||
- 你已使用 AD 凭证以系统管理员身份登录到 Rancher。
|
||||
|
||||
:::note
|
||||
|
||||
如果 LDAP 服务中断，你仍然可以使用本地配置的 `admin` 账号和密码登录。
|
||||
|
||||
:::
|
||||
|
||||
## 附录：使用 ldapsearch 确定搜索库和 Schema
|
||||
|
||||
为了成功配置 AD 身份验证，你必须提供 AD 服务器的层次结构和 Schema 的正确配置。
|
||||
|
||||
[`ldapsearch`](https://manpages.ubuntu.com/manpages/kinetic/en/man1/ldapsearch.1.html) 工具允许你查询你的 AD 服务器，从而了解用于用户和组对象的 Schema。
|
||||
|
||||
在下面的示例命令中，我们假设：
|
||||
|
||||
- Active Directory 服务器的主机名是 `ad.acme.com`。
|
||||
- 服务器正在监听端口 `389` 上的未加密连接。
|
||||
- Active Directory 的域是 `acme`。
|
||||
- 你有一个用户名为 `jdoe`，密码为 `secret` 的有效 AD 账号。
|
||||
|
||||
### 确认搜索库
|
||||
|
||||
首先，我们将使用 `ldapsearch` 来找到用户和组的父节点的标识名称：
|
||||
|
||||
```
|
||||
$ ldapsearch -x -D "acme\jdoe" -w "secret" -p 389 \
|
||||
-h ad.acme.com -b "dc=acme,dc=com" -s sub "sAMAccountName=jdoe"
|
||||
```
|
||||
|
||||
此命令执行 LDAP 搜索，搜索起点设置为域根目录（`-b "dc=acme,dc=com"`），并执行针对用户账号（`sAMAccountNam=jdoe`）的筛选器，返回所述用户的属性：
|
||||
|
||||
|
||||
|
||||
因为在这种情况下，用户的 DN 是 `CN=John Doe,CN=Users,DC=acme,DC=com` [5]，所以我们应该使用父节点 DN `CN=Users,DC=acme,DC=com` 来配置**用户搜索库**。
|
||||
|
||||
同样，基于 **memberOf** 属性 [4] 中引用的组的 DN，**组搜索库**的值将是该值的父节点，即 `OU=Groups,DC=acme,DC=com`。
|
||||
|
||||
### 确定用户 Schema
|
||||
|
||||
上述 `ldapsearch` 查询的输出还能用于确定在用户 Schema 配置中使用的值：
|
||||
|
||||
- `Object Class`：**person** [1]
|
||||
- `Username Attribute`:：**name** [2]
|
||||
- `Login Attribute`：**sAMAccountName** [3]
|
||||
- `User Member Attribute`：**memberOf** [4]
|
||||
|
||||
:::note
|
||||
|
||||
如果我们组织中的 AD 用户使用其 UPN（例如 `jdoe@acme.com`）而不是短登录名进行身份验证，则必须将 `Login Attribute` 设置为 **userPrincipalName**。
|
||||
|
||||
:::
|
||||
|
||||
我们还将 `Search Attribute` 数设置为 **sAMAccountName|name**。这样，用户可以通过输入用户名或全名添加到 Rancher UI 中的集群/项目中。
|
||||
|
||||
### 确定组 Schema
|
||||
|
||||
接下来，我们将查询与此用户关联的一个组，在本例中为 `CN=examplegroup,OU=Groups,DC=acme,DC=com`：
|
||||
|
||||
```
|
||||
$ ldapsearch -x -D "acme\jdoe" -w "secret" -p 389 \
|
||||
-h ad.acme.com -b "ou=groups,dc=acme,dc=com" \
|
||||
-s sub "CN=examplegroup"
|
||||
```
|
||||
|
||||
此命令将告知我们用于组对象的属性：
|
||||
|
||||
|
||||
|
||||
同样，这能让我们确定要在组 Schema 配置中输入的值：
|
||||
|
||||
- `Object Class`：**group** [1]
|
||||
- `Name Attribute`：**name** [2]
|
||||
- `Group Member Mapping Attribute`：**member** [3]
|
||||
- `Search Attribute`：**sAMAccountName** [4]
|
||||
|
||||
查看 **member** 属性的值，我们可以看到它包含被引用用户的 DN。这对应我们的用户对象中的 **distinguishedName** 属性。因此，必须将 `Group Member User Attribute` 参数的值设置为此属性。
|
||||
|
||||
同样，我们可以看到用户对象中 **memberOf** 属性中的值对应组的 **distinguishedName** [5]。因此，我们需要将 `Group DN Attribute` 参数的值设置为此属性。
|
||||
|
||||
## 附录：故障排除
|
||||
|
||||
如果在测试与 Active Directory 服务器的连接时遇到问题，请首先仔细检查为 ServiceAccount 输入的凭证以及搜索库配置。你还可以检查 Rancher 日志来查明问题的原因。调试日志可能包含有关错误的更详细信息。详情请参见[如何启用调试日志](../../../../faq/technical-items.md#如何启用调试日志记录)。
|
||||
+326
@@ -0,0 +1,326 @@
|
||||
---
|
||||
title: 配置 Azure AD
|
||||
---
|
||||
|
||||
## Microsoft Graph API
|
||||
|
||||
Microsoft Graph API 现在是设置 Azure AD 的流程。下文将帮助[新用户](#新用户设置)使用新实例来配置 Azure AD，并帮助现有 Azure 应用所有者[迁移到新流程](#从-azure-ad-graph-api-迁移到-microsoft-graph-api)。
|
||||
|
||||
Rancher 中的 Microsoft Graph API 流程正在不断发展。建议你使用最新的 2.7 补丁版本，该版本仍在积极开发中，并将持续获得新功能和改进。
|
||||
|
||||
### 新用户设置
|
||||
|
||||
如果你在 Azure 中托管了一个 Active Directory（AD）实例，你可以将 Rancher 配置为允许你的用户使用 AD 账号登录。你需要在 Azure 和 Rancher 中进行 Azure AD 外部身份验证。
|
||||
|
||||
:::note 注意事项
|
||||
|
||||
- Azure AD 集成仅支持服务提供商发起的登录。
|
||||
- 大部分操作是从 [Microsoft Azure 门户](https://portal.azure.com/)执行的。
|
||||
|
||||
:::
|
||||
|
||||
#### Azure Active Directory 配置概述
|
||||
|
||||
要将 Rancher 配置为允许用户使用其 Azure AD 账号进行身份验证，你需要执行多个步骤。在你开始之前，请查看下文操作步骤大纲。
|
||||
|
||||
:::tip
|
||||
|
||||
在开始之前，打开两个浏览器选项卡：一个用于 Rancher，另一个用于 Azure 门户。这样，你可以将门户的配置值复制并粘贴到 Rancher 中。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
#### 1. 在 Azure 注册 Rancher
|
||||
|
||||
在 Rancher 中启用 Azure AD 之前，你必须先向 Azure 注册 Rancher。
|
||||
|
||||
1. 以管理用户身份登录 [Microsoft Azure](https://portal.azure.com/)。后续配置步骤中需要管理访问权限。
|
||||
|
||||
1. 使用搜索功能打开 **App registrations** 服务。
|
||||
|
||||
1. 点击 **New registration** 并填写表单。
|
||||
|
||||
|
||||
|
||||
1. 输入 **Name**（例如 `Rancher`）。
|
||||
<a id="3.2"></a>
|
||||
|
||||
1. 在 **Supported account types** 中，选择 **Accounts in this organizational directory only (AzureADTest only - Single tenant)**。这对应于旧版应用注册选项。
|
||||
|
||||
:::note
|
||||
|
||||
在更新后的 Azure 门户中，Redirect URI 与 Reply URL 的意思相同。为了将 Azure AD 与 Rancher 一起使用，你必须将 Rancher 列入 Azure 白名单（之前通过 Reply URL 完成）。因此，请确保使用你的 Rancher Server URL 填写 Redirect URI，以包含下面列出的验证路径。
|
||||
|
||||
:::
|
||||
|
||||
1. 在 [**Redirect URI**](https://docs.microsoft.com/en-us/azure/active-directory/develop/reply-url) 中，确保从下拉列表中选择 **Web**，并在旁边的文本框中输入 Rancher Server 的 URL。Rancher Server URL 后需要追加验证路径，例如 `<MY_RANCHER_URL>/verify-auth-azure`。
|
||||
|
||||
:::tip
|
||||
|
||||
你可以在 Azure AD 身份验证页面（全局视图 > Authentication > Web）中找到你 Rancher 中的个性化 Azure Redirect URI（Reply URL）。
|
||||
|
||||
:::
|
||||
|
||||
1. 单击 **Register**。
|
||||
|
||||
:::note
|
||||
|
||||
此更改可能需要五分钟才能生效。因此，如果在配置 Azure AD 之后无法立即进行身份验证，请不要惊慌。
|
||||
|
||||
:::
|
||||
|
||||
#### 2. 创建客户端密文
|
||||
|
||||
在 Azure 门户中，创建一个客户端密文。Rancher 将使用此密钥向 Azure AD 进行身份验证。
|
||||
|
||||
1. 使用搜索功能打开 **App registrations** 服务。然后打开你在上一个步骤中创建的 Rancher 项。
|
||||
|
||||
|
||||
|
||||
1. 在导航窗格中，单击 **Certificates & secrets**。
|
||||
|
||||
1. 单击 **New client secret**。
|
||||
|
||||
1. 输入 **Description**（例如 `Rancher`）。
|
||||
1. 从 **Expires** 下的选项中选择持续时间。此下拉菜单设置的是密钥的到期日期。日期越短则越安全，但需要你更频繁地创建新密钥。
|
||||
请注意，如果检测到应用程序 Secret 已过期，用户将无法登录 Rancher。为避免此问题，请在 Azure 中轮换 Secret 并在过期前在 Rancher 中更新它。
|
||||
1. 单击 **Add**（无需输入值，保存后会自动填充）。
|
||||
<a id="secret"></a>
|
||||
|
||||
1. 稍后你将在 Rancher UI 中输入此密钥作为你的 **Application Secret**。由于你将无法在 Azure UI 中再次访问键值，因此请在其余设置过程中保持打开此窗口。
|
||||
|
||||
#### 3. 设置 Rancher 所需的权限
|
||||
|
||||
接下来，在 Azure 中为 Rancher 设置 API 权限。
|
||||
|
||||
:::caution
|
||||
|
||||
确保你设置了 Application 权限，而*不是* Delegated 权限。否则，你将无法登录 Azure AD。
|
||||
|
||||
:::
|
||||
|
||||
1. 在导航窗格中，选择 **API permissions**。
|
||||
|
||||
1. 单击 **Add a permission**。
|
||||
|
||||
1. 从 Microsoft Graph API 中，选择以下 **Application Permissions**: `Directory.Read.All`。
|
||||
|
||||
|
||||
|
||||
1. 返回导航栏中的 **API permissions**。在那里，单击 **Grant admin consent**。然后单击 **Yes**。该应用程序的权限应如下所示：
|
||||
|
||||
|
||||
|
||||
:::note
|
||||
|
||||
Rancher 不会验证你授予 Azure 应用程序的权限。你可以自由使用任何你所需的权限，只要这些权限允许 Rancher 使用 AD 用户和组。
|
||||
|
||||
具体来说，Rancher 需要允许以下操作的权限：
|
||||
- 获取一个用户。
|
||||
- 列出所有用户。
|
||||
- 列出给定用户所属的组。
|
||||
- 获取一个组。
|
||||
- 列出所有组。
|
||||
|
||||
Rancher 执行这些操作来登录用户或搜索用户/组。请记住，权限必须是 `Application` 类型。
|
||||
|
||||
下面是几个满足 Rancher 需求的权限组合示例：
|
||||
- `Directory.Read.All`
|
||||
- `User.Read.All` 和 `GroupMember.Read.All`
|
||||
- `User.Read.All` 和 `Group.Read.All`
|
||||
|
||||
:::
|
||||
|
||||
#### 4. 复制 Azure 应用数据
|
||||
|
||||
|
||||
|
||||
1. 获取你的 Rancher **租户 ID**。
|
||||
|
||||
1. 使用搜索打开 **App registrations**。
|
||||
|
||||
1. 找到你为 Rancher 创建的项。
|
||||
|
||||
1. 复制 **Directory ID** 并将其作为 **Tenant ID** 粘贴到 Rancher 中。
|
||||
|
||||
1. 获取你的 Rancher **Application (Client) ID**。
|
||||
|
||||
1. 如果你还未在该位置，请使用搜索打开 **App registrations**。
|
||||
|
||||
1. 在 **Overview**中，找到你为 Rancher 创建的条目。
|
||||
|
||||
1. 复制 **Application (Client) ID** 并将其作为 **Application ID** 粘贴到 Rancher 中。
|
||||
|
||||
1. 你的端点选项通常是 [Standard](#global) 或 [China](#中国)。对于这两个选项，你只需要输入 **Tenant ID**、**Application ID** 和 **Application Secret**。
|
||||
|
||||
|
||||
|
||||
**对于自定义端点**：
|
||||
|
||||
:::caution
|
||||
|
||||
Rancher 未测试也未完全支持自定义端点。
|
||||
|
||||
:::
|
||||
|
||||
你还需要手动输入 Graph、Token 和 Auth Endpoints。
|
||||
|
||||
- 从 <b>App registrations</b> 中，点击 <b>Endpoints</b>：
|
||||
|
||||
|
||||
|
||||
- 以下端点将是你的 Rancher 端点值。请使用这些端点的 v1 版本。
|
||||
- **Microsoft Graph API endpoint**（Graph 端点）
|
||||
- **OAuth 2.0 token endpoint (v1)**（Token 端点）
|
||||
- **OAuth 2.0 authorization endpoint (v1)** (Auth 端点)
|
||||
|
||||
#### 5. 在 Rancher 中配置 Azure AD
|
||||
|
||||
要完成配置，请在 Rancher UI 中输入你的 AD 实例信息。
|
||||
|
||||
1. 登录到 Rancher。
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
|
||||
1. 单击 **AzureAD**。
|
||||
|
||||
1. 使用你在[复制 Azure 应用数据](#4-复制-azure-应用数据)时复制的信息，填写**配置 Azure AD 账号**的表单。
|
||||
|
||||
:::caution
|
||||
|
||||
Azure AD 帐户将被授予管理员权限，因为其详细信息将映射到 Rancher 本地主体帐户。在继续之前确保此权限级别是适当的。
|
||||
|
||||
:::
|
||||
|
||||
**对于标准或中国端点：**
|
||||
|
||||
下表介绍了你在 Azure 门户中复制的值与 Rancher 中字段的映射：
|
||||
|
||||
| Rancher 字段 | Azure 值 |
|
||||
| ------------------ | ------------------------------------- |
|
||||
| 租户 ID | Directory ID |
|
||||
| Application ID | Application ID |
|
||||
| 应用密文 | Key Value |
|
||||
| 端点 | https://login.microsoftonline.com/ |
|
||||
|
||||
**对于自定义端点**：
|
||||
|
||||
下表将你的自定义配置值映射到 Rancher 字段：
|
||||
|
||||
| Rancher 字段 | Azure 值 |
|
||||
| ------------------ | ------------------------------------- |
|
||||
| Graph 端点 | Microsoft Graph API Endpoint |
|
||||
| Token 端点 | OAuth 2.0 Token Endpoint |
|
||||
| Auth 端点 | OAuth 2.0 Authorization Endpoint |
|
||||
|
||||
**重要提示**：在自定义配置中输入 Graph Endpoint 时，请从 URL 中删除 Tenant ID：
|
||||
|
||||
<code>http<span>s://g</span>raph.microsoft.com<del>/abb5adde-bee8-4821-8b03-e63efdc7701c</del></code>
|
||||
|
||||
1. 点击**启用**。
|
||||
|
||||
**结果**：Azure Active Directory 身份验证已配置。
|
||||
|
||||
|
||||
### 从 Azure AD Graph API 迁移到 Microsoft Graph API
|
||||
|
||||
由于 [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) 已弃用并计划于 2023 年 6 月停用，管理员应更新他们的 Azure AD 应用程序以在 Rancher 中使用 [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api)。
|
||||
你需要在端点弃用之前完成操作。
|
||||
如果在停用后 Rancher 仍配置为使用 Azure AD Graph API，用户可能无法使用 Azure AD 登录 Rancher。
|
||||
|
||||
#### 在 Rancher UI 中更新端点
|
||||
|
||||
:::caution
|
||||
|
||||
管理员需要在迁移下述端点之前创建一个 [Rancher 备份](../../../new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md)。
|
||||
|
||||
:::
|
||||
|
||||
1. [更新](#3-设置-rancher-所需的权限) Azure AD 应用程序注册的权限。这个步骤非常关键。
|
||||
|
||||
1. 登录到 Rancher。
|
||||
|
||||
1. 在 Rancher UI 主页中，记下屏幕顶部的横幅，该横幅建议用户更新 Azure AD 身份验证。单击提供的链接以执行此操作。
|
||||
|
||||
|
||||
|
||||
1. 要完成新的 Microsoft Graph API 迁移，请单击 **Update Endpoint**。
|
||||
|
||||
**注意**：在开始更新之前，请确保你的 Azure 应用程序具有[新的权限集](#3-设置-rancher-所需的权限)。
|
||||
|
||||
|
||||
|
||||
1. 在收到弹出警告消息时，单击 **Update**：
|
||||
|
||||
|
||||
|
||||
1. 有关 Rancher 执行的完整端点更改，请参阅下面的[表格](#global)。管理员不需要手动执行此操作。
|
||||
|
||||
#### 离线环境
|
||||
|
||||
在离线环境中，由于 Graph Endpoint URL 正在更改，因此管理员需要确保其端点被[列入白名单](#3.2)。
|
||||
|
||||
#### 回滚迁移
|
||||
|
||||
如果你需要回滚迁移，请注意以下事项：
|
||||
|
||||
1. 如果管理员想要回滚，我们建议他们使用正确的恢复流程。有关参考信息，请参阅[备份文档](../../../new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md)、[恢复文档](../../../new-user-guides/backup-restore-and-disaster-recovery/restore-rancher.md)和[示例](../../../../reference-guides/backup-restore-configuration/examples.md)。
|
||||
|
||||
1. 如果 Azure 应用程序所有者想要轮换应用程序密钥，他们也需要在 Rancher 中进行轮换（因为在 Azure 中更改应用程序密钥时，Rancher 不会自动更新应用程序密钥）。在 Rancher 中，它存储在名为 `azureadconfig-applicationsecret` 的 Kubernetes 密文中，该密文位于 `cattle-global-data` 命名空间中。
|
||||
|
||||
:::caution
|
||||
|
||||
如果你使用现有的 Azure AD 设置升级到 Rancher v2.7.0+，并选择了禁用认证提供程序，你将无法恢复以前的设置。你也无法使用旧流程设置 Azure AD。你需要使用新的认证流程重新注册。由于 Rancher 现在使用 Graph API，因此用户需要[在 Azure 门户中设置适当的权限](#3-设置-rancher-所需的权限)。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
#### Global:
|
||||
|
||||
| Rancher 字段 | 已弃用的端点 |
|
||||
---------------- | -------------------------------------------------------------
|
||||
| Auth 端点 | https://login.microsoftonline.com/{tenantID}/oauth2/authorize |
|
||||
| 端点 | https://login.microsoftonline.com/ |
|
||||
| Graph 端点 | https://graph.windows.net/ |
|
||||
| Token 端点 | https://login.microsoftonline.com/{tenantID}/oauth2/token |
|
||||
|
||||
| Rancher 字段 | 新端点 |
|
||||
---------------- | ------------------------------------------------------------------
|
||||
| Auth 端点 | https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/authorize |
|
||||
| 端点 | https://login.microsoftonline.com/ |
|
||||
| Graph 端点 | https://graph.microsoft.com |
|
||||
| Token 端点 | https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/token |
|
||||
|
||||
#### 中国：
|
||||
|
||||
| Rancher 字段 | 已弃用的端点 |
|
||||
---------------- | ----------------------------------------------------------
|
||||
| Auth 端点 | https://login.chinacloudapi.cn/{tenantID}/oauth2/authorize |
|
||||
| 端点 | https://login.chinacloudapi.cn/ |
|
||||
| Graph 端点 | https://graph.chinacloudapi.cn/ |
|
||||
| Token 端点 | https://login.chinacloudapi.cn/{tenantID}/oauth2/token |
|
||||
|
||||
| Rancher 字段 | 新端点 |
|
||||
---------------- | -------------------------------------------------------------------------
|
||||
| Auth 端点 | https://login.partner.microsoftonline.cn/{tenantID}/oauth2/v2.0/authorize |
|
||||
| 端点 | https://login.partner.microsoftonline.cn/ |
|
||||
| Graph 端点 | https://microsoftgraph.chinacloudapi.cn |
|
||||
| Token 端点 | https://login.partner.microsoftonline.cn/{tenantID}/oauth2/v2.0/token |
|
||||
|
||||
|
||||
## 已弃用的 Azure AD Graph API
|
||||
|
||||
> **重要提示**：
|
||||
>
|
||||
> - [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) 已被弃用，Microsoft 将在 2023 年 6 月 30 日后随时停用它且不会另行通知。我们将更新我们的文档，以便在停用时向社区提供建议。Rancher 现在使用 [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) 来将 Azure AD 设置为外部身份验证提供程序。
|
||||
>
|
||||
>
|
||||
> - 如果你是新用户或希望进行迁移，请参阅新的流程说明： <a href="#microsoft-graph-api/" target="_blank">Rancher v2.7.0+</a>。
|
||||
>
|
||||
>
|
||||
> - 如果你不想在 Azure AD Graph API 停用后升级到 v2.7.0+，你需要：
|
||||
> - 使用内置的 Rancher 身份认证，或者
|
||||
> - 使用另一个第三方身份认证系统并在 Rancher 中进行设置。请参阅[身份验证文档](../../../../pages-for-subheaders/authentication-config.md)，了解如何配置其他开放式身份验证提供程序。
|
||||
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: 配置 FreeIPA
|
||||
---
|
||||
|
||||
如果你的组织使用 FreeIPA 进行用户身份验证，你可以通过配置 Rancher 来允许你的用户使用 FreeIPA 凭证登录。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
- 你必须配置了 [FreeIPA 服务器](https://www.freeipa.org/)。
|
||||
- 在 FreeIPA 中创建一个具有 `read-only` 访问权限的 ServiceAccount 。当用户使用 API 密钥发出请求时，Rancher 使用此账号来验证组成员身份。
|
||||
- 参见[外部身份验证配置和主体用户](../../../../pages-for-subheaders/authentication-config.md#外部身份验证配置和用户主体)。
|
||||
|
||||
:::
|
||||
|
||||
1. 使用分配了 `administrator` 角色（即 _本地主体_）的本地用户登录到 Rancher。
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **FreeIPA**。
|
||||
1. 填写**配置 FreeIPA 服务器**表单，
|
||||
|
||||
你可能需要登录到域控制器，来查找表单中请求的信息。
|
||||
|
||||
:::note 使用 TLS？
|
||||
|
||||
如果证书是自签名，或者不是来自公认的证书颁发机构的，请确保提供完整的证书链。Rancher 需要该链来验证服务器的证书。
|
||||
|
||||
:::
|
||||
|
||||
:::note 用户搜索库 vs. 组搜索库
|
||||
|
||||
搜索库使 Rancher 可以搜索 FreeIPA 中的用户和组。这些字段仅用于搜索库，不适用于搜索筛选器。
|
||||
|
||||
* 如果你的用户和组位于同一搜索库中，则仅填写用户搜索库。
|
||||
* 如果你的组位于其他搜索库中，则可以选择填写组搜索库。该字段专用于搜索组，但不是必需的。
|
||||
|
||||
:::
|
||||
|
||||
1. 如果你的 FreeIPA 不同于标准的 AD Schema，则必须完成**自定义 Schema** 部分实现匹配。否则，调过此步骤。
|
||||
|
||||
:::note 搜索属性
|
||||
|
||||
`搜索属性`字段的默认值为三个特定值：`uid|sn|givenName`。配置 FreeIPA 后，当用户输入文本以添加用户或组时，Rancher 会自动查询 FreeIPA 服务器，并尝试按用户 ID，姓氏或名字来匹配字段。Rancher 专门搜索以在搜索字段中输入的文本开头的用户/组。
|
||||
|
||||
默认字段值为 `uid|sn|givenName`，但是你可以将此字段配置为这些字段的子集。管道符 (`|`) 用于分隔各个字段。
|
||||
|
||||
* `uid`：用户 ID
|
||||
* `sn`：姓
|
||||
* `givenName`：名
|
||||
|
||||
Rancher 使用此搜索属性为用户和组创建搜索筛选器，但是你*不能*在此字段中添加自己的搜索筛选器。
|
||||
|
||||
:::
|
||||
|
||||
1. 在 **Authenticate with FreeIPA** 中输入你的 FreeIPA 用户名和密码，确认已为 Rancher 配置 FreeIPA 身份验证。
|
||||
1. 点击**启用**。
|
||||
|
||||
**结果**：
|
||||
|
||||
- FreeIPA 验证配置成功。
|
||||
- 你将使用你的 FreeIPA 账号（即 _外部主体_）登录到 Rancher。
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: 配置 GitHub
|
||||
---
|
||||
|
||||
在使用 GitHub 的环境中，你可以通过配置 Rancher 允许用户使用 GitHub 凭证登录。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
参见[外部身份验证配置和主体用户](../../../../pages-for-subheaders/authentication-config.md#外部身份验证配置和用户主体)。
|
||||
|
||||
:::
|
||||
|
||||
1. 使用分配了 `administrator` 角色（即 _本地主体_）的本地用户登录到 Rancher。
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **GitHub**。
|
||||
1. 按照显示的说明设置 GitHub 应用。Rancher 会将你重定向到 GitHub 完成注册。
|
||||
|
||||
:::note 什么是授权回调 URL？
|
||||
|
||||
授权回调 URL 是用户开始使用你的应用（即初始屏幕）的 URL。
|
||||
|
||||
使用外部身份验证时，实际上不会在你的应用中进行身份验证。相反，身份验证在外部进行（在本例中为 GitHub）。在外部身份验证成功完成后，用户将通过授权回调 URL 重新进入应用。
|
||||
|
||||
:::
|
||||
|
||||
1. 从 GitHub 复制 **Client ID** 和 **Client Secret**。将它们粘贴到 Rancher 中。
|
||||
|
||||
:::note 在哪里可以找到 Client ID 和 Client Secret？
|
||||
|
||||
在 GitHub 中，选择 **Settings > Developer Settings > OAuth Apps**。你可以在此处找到 Client ID 和 Client Secret。
|
||||
|
||||
:::
|
||||
|
||||
1. 单击**使用 GitHub 认证**。
|
||||
|
||||
1. 使用 **Site Access** 选项来配置用户授权的范围。
|
||||
|
||||
- **允许任何有效用户**
|
||||
|
||||
_任何_ GitHub 用户都能访问 Rancher。通常不建议使用此设置。
|
||||
|
||||
- **允许集群和项目成员，以及授权的用户和组织**
|
||||
|
||||
添加为**集群成员**或**项目成员**的任何 GitHub 用户或组都可以登录 Rancher。此外，任何添加到**授权用户和组织**列表中的 GitHub 用户和组都能登录到 Rancher。
|
||||
|
||||
- **仅允许授权用户和组织**
|
||||
|
||||
只有添加到**授权用户和组织**的 GitHub 用户和组能登录 Rancher。
|
||||
<br/>
|
||||
1. 点击**启用**。
|
||||
|
||||
**结果**：
|
||||
|
||||
- GitHub 验证配置成功。
|
||||
- 你将使用你的 GitHub 账号（即 _外部主体_）登录到 Rancher。
|
||||
+111
@@ -0,0 +1,111 @@
|
||||
---
|
||||
title: 配置 Google OAuth
|
||||
---
|
||||
|
||||
如果你的组织使用 G Suite 进行用户身份验证，你可以通过配置 Rancher 来允许你的用户使用 G Suite 凭证登录。
|
||||
|
||||
只有 G Suite 域的管理员才能访问 Admin SDK。因此，只有 G Suite 管理员可以配置 Rancher 的 Google OAuth。
|
||||
|
||||
在 Rancher 中，只有具有 **Manage Authentication** [全局角色](../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)的管理员或用户才能配置身份验证。
|
||||
|
||||
## 先决条件
|
||||
|
||||
- 你必须配置了 [G Suite 管理员账号](https://admin.google.com)。
|
||||
- G Suite 需要一个[顶级私有域 FQDN](https://github.com/google/guava/wiki/InternetDomainNameExplained#public-suffixes-and-private-domains) 作为授权域。获取 FQDN 的一种方法是在 Route53 中为 Rancher Server 创建 A 记录。你不需要使用该记录更新 Rancher Server 的 URL 设置，因为可能有集群使用该 URL。
|
||||
- 你的 G Suite 域必须启用了 Admin SDK API。你可以按照[此页面](https://support.google.com/a/answer/60757?hl=en)中的步骤启用它。
|
||||
|
||||
启用 Admin SDK API 后，你的 G Suite 域的 API 页面应如下图所示：
|
||||
|
||||
|
||||
## 在 Rancher 中为 OAuth 设置 G Suite
|
||||
|
||||
在 Rancher 中设置 Google OAuth 之前，你需要登录到你的 G Suite 账号并完成以下设置：
|
||||
|
||||
1. [在 G Suite 中将 Rancher 添加为授权域](#1-将-rancher-添加为授权域)
|
||||
1. [为 Rancher Server 生成 OAuth2 凭证](#2-为-rancher-server-生成-oauth2-凭证)
|
||||
1. [为 Rancher Server 创建 ServiceAccount 凭证](#3-创建-serviceaccount-凭证)
|
||||
1. [将 ServiceAccount 密钥注册成 OAuth Client](#4-将-serviceaccount-密钥注册成-oauth-client)
|
||||
|
||||
### 1. 将 Rancher 添加为授权域
|
||||
|
||||
1. 点击[此处](https://console.developers.google.com/apis/credentials)前往你的 Google 域的凭证页面。
|
||||
1. 选择你的项目，然后点击 **OAuth consent screen**。
|
||||
|
||||
1. 前往 **Authorized Domains**，并在列表中输入你的 Rancher Server URL 的顶级私有域。顶级私有域是最右边的超级域。例如，`www.foo.co.uk` 是 `foo.co.uk` 的顶级私有域。有关顶级私有域的更多信息，请参见[此处](https://github.com/google/guava/wiki/InternetDomainNameExplained#public-suffixes-and-private-domains)。
|
||||
1. 前往 **Scopes for Google APIs**，并确保已启用 **email**，**profile** 和 **openid**。
|
||||
|
||||
**结果**：Rancher 已被添加为 Admin SDK API 的授权域。
|
||||
|
||||
### 2. 为 Rancher Server 生成 OAuth2 凭证
|
||||
|
||||
1. 前往 Google API 控制台，选择你的项目并前往 [credentials ](https://console.developers.google.com/apis/credentials)页面。
|
||||
|
||||
1. 在 **Create Credentials** 下拉框中，选择 **OAuth client ID**。
|
||||
1. 点击 **Web application**。
|
||||
1. 输入一个名称。
|
||||
1. 填写 **Authorized JavaScript origins** 和 **Authorized redirect URIs**。请注意，设置 Google OAuth 的 Rancher UI 页面（**Security > Authentication > Google** 下的全局视图）为你提供了这一步要输入的准确链接。
|
||||
- 在 **Authorized JavaScript origins** 处，输入你的 Rancher Server URL。
|
||||
- 在 **Authorized redirect URIs** 处，输入你的 Rancher Server 的 URL 并附加路径 `verify-auth`。例如，如果你的 URI 是 `https://rancherServer`，你需要输入 `https://rancherServer/verify-auth`。
|
||||
1. 点击 **Create**。
|
||||
1. 创建凭证之后，你将看到一个页面，其中显示你的凭证列表。选择刚刚创建的凭证，然后在最右边的行中单击 **Download JSON**。保存该文件，以便向 Rancher 提供这些凭证。
|
||||
|
||||
**结果**：你已成功创建 OAuth 凭证。
|
||||
|
||||
### 3. 创建 ServiceAccount 凭证
|
||||
由于 Google Admin SDK 只对管理员可用，普通用户不能使用它来检索其他用户或其组的配置文件。普通用户甚至不能检索他们自己的组。
|
||||
|
||||
由于 Rancher 提供基于组的成员访问，我们要求用户能够获得自己的组，并在需要时查找其他用户和组。
|
||||
|
||||
为了解决这个问题，G Suite 建议创建一个 ServiceAccount，并将你的 G Suite 域的权限委托给该 ServiceAccount。
|
||||
|
||||
本节介绍如何：
|
||||
|
||||
- 创建一个 ServiceAccount
|
||||
- 为 ServiceAccount 创建一个密钥并下载 JSON 格式的凭证
|
||||
|
||||
1. 点击[此处](https://console.developers.google.com/iam-admin/serviceaccounts)并选择要生成 OAuth 凭证的项目。
|
||||
1. 点击 **Create Service Account**。
|
||||
1. 输入名称，并点击 **Create**。
|
||||
|
||||
1. 不要在 **Service account permissions** 页面设置任何角色，然后单击 **Continue**。
|
||||
|
||||
1. 点击 **Create Key** 并选择 JSON 选项。下载并保存 JSON 文件，以便你可以将其作为 ServiceAccount 凭证提供给 Rancher。
|
||||
|
||||
|
||||
**结果**：你的 ServiceAccount 已创建成功。
|
||||
|
||||
### 4. 将 ServiceAccount 密钥注册成 OAuth Client
|
||||
|
||||
你需要为在上一步中创建的 ServiceAccount 授予一些权限。Rancher 仅要求为用户和组授予只读权限。
|
||||
|
||||
使用 ServiceAccount 密钥的唯一 ID，按照以下步骤将其注册为 Oauth Client：
|
||||
|
||||
1. 获取你刚刚创建的密钥的唯一 ID。如果它没有显示在你创建的键旁边的键列表中，你需要先启用 Unique ID 列。点击 **Unique ID** 然后点击 **OK**。这将向 ServiceAccount 密钥列表中添加 **Unique ID** 列。保存你创建的 ServiceAccount 对应的唯一 ID。注意：这是一个数字 Key，不要与字母数字字段 **Key ID** 混淆。
|
||||
|
||||
|
||||
1. 前往 [**Domain-wide Delegation** 页面。](https://admin.google.com/ac/owl/domainwidedelegation)
|
||||
1. 在 **Client Name** 字段中添加上一步中获得的唯一 ID。
|
||||
1. 在 **One or More API Scopes** 字段中，添加以下作用域：
|
||||
```
|
||||
openid,profile,email,https://www.googleapis.com/auth/admin.directory.user.readonly,https://www.googleapis.com/auth/admin.directory.group.readonly
|
||||
```
|
||||
1. 点击 **Authorize**。
|
||||
|
||||
**结果**：ServiceAccount 在你的 G Suite 账号中已注册为 OAuth 客户端。
|
||||
|
||||
## 在 Rancher 中配置 Google OAuth
|
||||
|
||||
1. 使用分配了 [administrator](../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md) 角色的本地用户登录到 Rancher。这个用户也称为本地主体。
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **Google**。UI 中的说明介绍了使用 Google OAuth 设置身份验证的步骤。
|
||||
1. 管理员邮箱：提供 GSuite 设置中的管理员账户的电子邮箱。为了查找用户和组，Google API 需要管理员的电子邮件和 ServiceAccount 密钥。
|
||||
1. 域名：提供配置了 G Suite 的域。请提供准确的域，而不是别名。
|
||||
1. 属于多个用户组的用户：选中此框以启用嵌套组成员关系。Rancher 管理员可以在配置认证后的任何时候禁用它。
|
||||
- **步骤一**是将 Rancher 添加为授权域（详情请参见[本节](#1-将-rancher-添加为授权域)）。
|
||||
- **步骤二**提供你完成[本节](#2-为-rancher-server-生成-oauth2-凭证)后下载的 OAuth 凭证 JSON。你可以上传文件或将内容粘贴到 **OAuth Credentials** 字段。
|
||||
- **步骤三**提供在[本节](#3-创建-serviceaccount-凭证)末尾下载的 ServiceAccount 凭证 JSON。仅当你成功[在 G Suite 账号中将 ServiceAccount 密钥注册为 OAuth Client](#4-将-serviceaccount-密钥注册成-oauth-client) 后，凭证才能正常工作。
|
||||
1. 点击**使用 Google 认证**。
|
||||
1. 点击**启用**。
|
||||
|
||||
**结果**：Google 验证配置成功。
|
||||
+154
@@ -0,0 +1,154 @@
|
||||
---
|
||||
title: 配置 Keycloak (OIDC)
|
||||
description: 创建 Keycloak OpenID Connect (OIDC) 客户端并配置 Rancher 以使用 Keycloak。你的用户将能够使用他们的 Keycloak 登录名登录 Rancher。
|
||||
---
|
||||
|
||||
如果你的组织使用 [Keycloak Identity Provider (IdP)](https://www.keycloak.org) 进行用户身份验证，你可以通过配置 Rancher 来允许用户使用 IdP 凭证登录。Rancher 支持使用 OpenID Connect (OIDC) 协议和 SAML 协议来集成 Keycloak。与 Rancher 一起使用时，这两种实现在功能上是等效的。本文描述了配置 Rancher 以通过 OIDC 协议与 Keycloak 一起使用的流程。
|
||||
|
||||
如果你更喜欢将 Keycloak 与 SAML 协议一起使用，请参见[此页面](configure-keycloak-saml.md)。
|
||||
|
||||
如果你有使用 SAML 协议的现有配置并希望切换到 OIDC 协议，请参见[本节](#从-saml-迁移到-oidc)。
|
||||
|
||||
## 先决条件
|
||||
|
||||
- 已在 Rancher 上禁用 Keycloak (SAML)。
|
||||
- 你必须配置了 [Keycloak IdP 服务器](https://www.keycloak.org/guides#getting-started)。
|
||||
- 在 Keycloak 中，使用以下设置创建一个[新的 OIDC 客户端](https://www.keycloak.org/docs/latest/server_admin/#oidc-clients)。如需获取帮助，请参见 [Keycloak 文档](https://www.keycloak.org/docs/latest/server_admin/#oidc-clients)。
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Client ID` | <CLIENT_ID> (例如 `rancher`) |
|
||||
| `Name` | <CLIENT_NAME> (例如 `rancher`) |
|
||||
| `Client Protocol` | `openid-connect` |
|
||||
| `Access Type` | `confidential` |
|
||||
| `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth` |
|
||||
|
||||
- 在新的 OIDC 客户端中，创建 [Mappers](https://www.keycloak.org/docs/latest/server_admin/#_protocol-mappers) 来公开用户字段。
|
||||
- 使用以下设置创建一个新的 "Groups Mapper"：
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Name` | `Groups Mapper` |
|
||||
| `Mapper Type` | `Group Membership` |
|
||||
| `Token Claim Name` | `groups` |
|
||||
| `Full group path` | `OFF` |
|
||||
| `Add to ID token` | `OFF` |
|
||||
| `Add to access token` | `OFF` |
|
||||
| `Add to user info` | `ON` |
|
||||
|
||||
- 使用以下设置创建一个新的 "Client Audience" ：
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Name` | `Client Audience` |
|
||||
| `Mapper Type` | `Audience` |
|
||||
| `Included Client Audience` | <CLIENT_NAME> |
|
||||
| `Add to ID token` | `OFF` |
|
||||
| `Add to access token` | `ON` |
|
||||
|
||||
- 使用以下设置创建一个新的 "Groups Path"：
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Name` | `Group Path` |
|
||||
| `Mapper Type` | `Group Membership` |
|
||||
| `Token Claim Name` | `full_group_path` |
|
||||
| `Full group path` | `ON` |
|
||||
| `Add to ID token` | `ON` |
|
||||
| `Add to access token` | `ON` |
|
||||
| `Add to user info` | `ON` |
|
||||
|
||||
- Go to **Role Mappings > Client Roles > realm-management** and add the following Role Mappings to all users or groups that need to query the Keycloak users.
|
||||
- query-users
|
||||
- query-groups
|
||||
- view-users
|
||||
|
||||
## 在 Rancher 中配置 Keycloak
|
||||
|
||||
1. 在 Rancher UI 中，单击 **☰ > 用户 & 认证**。
|
||||
1. 单击左侧导航栏的**认证**。
|
||||
1. 选择 **Keycloak (OIDC)**。
|
||||
1. 填写**配置 Keycloak OIDC 账号**表单。有关填写表单的帮助，请参见[配置参考](#配置参考)。
|
||||
1. 完成**配置 Keycloak OIDC 账号**表单后，单击**启用**。
|
||||
|
||||
Rancher 会将你重定向到 IdP 登录页面。输入使用 Keycloak IdP 进行身份验证的凭证，来验证你的 Rancher Keycloak 配置。
|
||||
|
||||
:::note
|
||||
|
||||
你可能需要禁用弹出窗口阻止程序才能看到 IdP 登录页面。
|
||||
|
||||
:::
|
||||
|
||||
**结果**：已将 Rancher 配置为使用 OIDC 协议与 Keycloak 一起工作。你的用户现在可以使用 Keycloak 登录名登录 Rancher。
|
||||
|
||||
## 配置参考
|
||||
|
||||
| 字段 | 描述 |
|
||||
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 客户端 ID | 你的 Keycloak 客户端的 `Client ID`。 |
|
||||
| 客户端密码 | 你的 Keycloak 客户端生成的 `Secret`。在 Keycloak 控制台中，单击 **Clients**，选择你创建的客户端，选择 **Credentials** 选项卡，然后复制 `Secret` 字段的值。 |
|
||||
| 私钥/证书 | 在 Rancher 和你的 IdP 之间创建安全外壳（SSH）的密钥/证书对。如果你的 Keycloak 服务器上启用了 HTTPS/SSL，则为必填。 |
|
||||
| 端点 | 选择为 `Rancher URL`、`发行者`和 `Auth 端点`字段使用生成的值，还是在不正确时进行手动覆盖。 |
|
||||
| Keycloak URL | 你的 Keycloak 服务器的 URL。 |
|
||||
| Keycloak Realm | 创建 Keycloak 客户端的 Realm 的名称。 |
|
||||
| Rancher URL | Rancher Server 的 URL。 |
|
||||
| Issuer | 你的 IdP 的 URL。 |
|
||||
| Auth 端点 | 重定向用户进行身份验证的 URL。 |
|
||||
|
||||
## 从 SAML 迁移到 OIDC
|
||||
|
||||
本节描述了将使用 Keycloak (SAML) 的 Rancher 过渡到 Keycloak (OIDC) 的过程。
|
||||
|
||||
### 重新配置 Keycloak
|
||||
|
||||
1. 将现有客户端更改为使用 OIDC 协议。在 Keycloak 控制台中，单击 **Clients**，选择要迁移的 SAML 客户端，选择 **Settings** 选项卡，将 `Client Protocol` 从 `saml` 更改为 `openid-connect`，然后点击 **Save**。
|
||||
|
||||
1. 验证 `Valid Redirect URIs` 是否仍然有效。
|
||||
|
||||
1. 选择 **Mappers** 选项卡并使用以下设置创建一个新的 Mapper：
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Name` | `Groups Mapper` |
|
||||
| `Mapper Type` | `Group Membership` |
|
||||
| `Token Claim Name` | `groups` |
|
||||
| `Add to ID token` | `ON` |
|
||||
| `Add to access token` | `ON` |
|
||||
| `Add to user info` | `ON` |
|
||||
|
||||
### 重新配置 Rancher
|
||||
|
||||
在将 Rancher 配置为使用 Keycloak (OIDC) 之前，必须先禁用 Keycloak (SAML)：
|
||||
|
||||
1. 在 Rancher UI 中，单击 **☰ > 用户 & 认证**。
|
||||
1. 单击左侧导航栏的**认证**。
|
||||
1. 选择 **Keycloak (SAML)**。
|
||||
1. 单击**禁用**。
|
||||
|
||||
按照[本节](#在-rancher-中配置-keycloak)中的步骤将 Rancher 配置为使用 Keycloak (OIDC)。
|
||||
|
||||
:::note
|
||||
|
||||
配置完成后，由于用户权限不会自动迁移，你需要重新申请 Rancher 用户权限。
|
||||
|
||||
:::
|
||||
|
||||
## 附录：故障排除
|
||||
|
||||
如果你在测试与 Keycloak 服务器的连接时遇到问题，请先检查 OIDC 客户端的配置选项。你还可以检查 Rancher 日志来查明问题的原因。调试日志可能包含有关错误的更详细信息。详情请参见[如何启用调试日志](../../../../faq/technical-items.md#如何启用调试日志记录)。
|
||||
|
||||
所有与 Keycloak 相关的日志条目都将添加 `[generic oidc]` 或 `[keycloak oidc]`。
|
||||
|
||||
### 不能重定向到 Keycloak
|
||||
|
||||
完成**配置 Keycloak OIDC 账号**表单并单击**启用**后，你没有被重定向到你的 IdP。
|
||||
|
||||
* 验证你的 Keycloak 客户端配置。
|
||||
|
||||
### 生成的 `Issuer` 和 `Auth 端点`不正确
|
||||
|
||||
* 在**配置 Keycloak OIDC 账号**表单中，将**端点**更改为`指定（高级设置）`并覆盖`发行者` 和 `Auth 端点`的值。要查找这些值，前往 Keycloak 控制台并选择 **Realm Settings**，选择 **General** 选项卡，然后单击 **OpenID Endpoint Configuration**。JSON 输出将显示 `issuer` 和 `authorization_endpoint` 的值。
|
||||
|
||||
### Keycloak 错误："Invalid grant_type"
|
||||
|
||||
* 在某些情况下，这条错误提示信息可能有误导性，实际上造成错误的原因是 `Valid Redirect URI` 配置错误。
|
||||
+190
@@ -0,0 +1,190 @@
|
||||
---
|
||||
title: 配置 Keycloak (SAML)
|
||||
description: 创建 Keycloak SAML 客户端并配置 Rancher 以使用 Keycloak。你的用户将能够使用他们的 Keycloak 登录名登录 Rancher。
|
||||
---
|
||||
|
||||
如果你的组织使用 Keycloak Identity Provider (IdP) 进行用户身份验证，你可以通过配置 Rancher 来允许用户使用 IdP 凭证登录。
|
||||
|
||||
## 先决条件
|
||||
|
||||
- 你必须配置了 [Keycloak IdP 服务器](https://www.keycloak.org/guides#getting-started)。
|
||||
- 在 Keycloak 中，使用以下设置创建一个[新的 SAML 客户端](https://www.keycloak.org/docs/latest/server_admin/#saml-clients)。如需获取帮助，请参见 [Keycloak 文档](https://www.keycloak.org/docs/latest/server_admin/#saml-clients)。
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Sign Documents` | `ON` <sup>1</sup> |
|
||||
| `Sign Assertions` | `ON` <sup>1</sup> |
|
||||
| 所有其他 `ON/OFF` 设置 | `OFF` |
|
||||
| `Client ID` | 输入 `https://yourRancherHostURL/v1-saml/keycloak/saml/metadata`，或在 Rancher Keycloak 配置<sup>2</sup> 中 `Entry ID 字段`的值。 |
|
||||
| `Client Name` | <CLIENT_NAME> (例如 `rancher`) |
|
||||
| `Client Protocol` | `SAML` |
|
||||
| `Valid Redirect URI` | `https://yourRancherHostURL/v1-saml/keycloak/saml/acs` |
|
||||
|
||||
> <sup>1</sup>：可以选择启用这些设置中的一个或两个。
|
||||
> <sup>2</sup>：在配置和保存 SAML 身份提供商之前，不会生成 Rancher SAML 元数据。
|
||||
|
||||
|
||||
|
||||
- 在新的 SAML 客户端中，创建 Mappers 来公开用户字段。
|
||||
- 添加所有 "Builtin Protocol Mappers"
|
||||
|
||||
- 创建一个 "Group list" mapper，来将成员属性映射到用户的组：
|
||||
|
||||
|
||||
## 获取 IDP 元数据
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Keycloak 5 和更早的版本">
|
||||
|
||||
要获取 IDP 元数据，请从 Keycloak 客户端导出 `metadata.xml` 文件。
|
||||
在**安装**选项卡中，选择**SAML 元数据 IDPSSODescriptor** 格式选项并下载你的文件。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Keycloak 6-13">
|
||||
|
||||
1. 在**配置**中，单击 **Realm 设置**选项卡。
|
||||
1. 点击**通用**选项卡。
|
||||
1. 在**端点**字段中，单击 **SAML 2.0 身份提供者元数据**。
|
||||
|
||||
验证 IDP 元数据是否包含以下属性：
|
||||
|
||||
```
|
||||
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
|
||||
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
|
||||
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
|
||||
```
|
||||
|
||||
某些浏览器（例如 Firefox）可能会渲染/处理文档，使得内容看起来已被修改，并且某些属性看起来可能有缺失。在这种情况下，请使用通过浏览器找到的原始响应数据。
|
||||
|
||||
以下是 Firefox 的示例流程，其他浏览器可能会略有不同：
|
||||
|
||||
1. 按下 **F12** 访问开发者控制台。
|
||||
1. 点击 **Network** 选项卡。
|
||||
1. 从表中，单击包含 `descriptor` 的行。
|
||||
1. 在 details 窗格中，单击 **Response** 选项卡。
|
||||
1. 复制原始响应数据。
|
||||
|
||||
获得的 XML 以 `EntitiesDescriptor` 作为根元素。然而，Rancher 希望根元素是 `EntityDescriptor` 而不是 `EntitiesDescriptor`。因此，在将这个 XML 传递给 Rancher 之前，请按照以下步骤调整：
|
||||
|
||||
1. 将所有不存在的属性从 `EntitiesDescriptor` 复制到 `EntityDescriptor`。
|
||||
1. 删除开头的 `<EntitiesDescriptor>` 标签。
|
||||
1. 删除 xml 末尾的 `</EntitiesDescriptor>`。
|
||||
|
||||
最后的代码会是如下：
|
||||
|
||||
```
|
||||
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" entityID="https://{KEYCLOAK-URL}/auth/realms/{REALM-NAME}">
|
||||
....
|
||||
</EntityDescriptor>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Keycloak 14+">
|
||||
|
||||
1. 在**配置**中，单击 **Realm 设置**选项卡。
|
||||
1. 点击**通用**选项卡。
|
||||
1. 在**端点**字段中，单击 **SAML 2.0 身份提供者元数据**。
|
||||
|
||||
验证 IDP 元数据是否包含以下属性：
|
||||
|
||||
```
|
||||
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
|
||||
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
|
||||
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
|
||||
```
|
||||
|
||||
某些浏览器（例如 Firefox）可能会渲染/处理文档，使得内容看起来已被修改，并且某些属性看起来可能有缺失。在这种情况下，请使用通过浏览器找到的原始响应数据。
|
||||
|
||||
以下是 Firefox 的示例流程，其他浏览器可能会略有不同：
|
||||
|
||||
1. 按下 **F12** 访问开发者控制台。
|
||||
1. 点击 **Network** 选项卡。
|
||||
1. 从表中，单击包含 `descriptor` 的行。
|
||||
1. 在 details 窗格中，单击 **Response** 选项卡。
|
||||
1. 复制原始响应数据。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 在 Rancher 中配置 Keycloak
|
||||
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **Keycloak SAML**。
|
||||
1. 填写**配置 Keycloak 账号**表单。有关填写表单的帮助，请参见[配置参考](#配置参考)。
|
||||
1. 完成**配置 Keycloak 账号**表单后，单击**启用**。
|
||||
|
||||
Rancher 会将你重定向到 IdP 登录页面。输入使用 Keycloak IdP 进行身份验证的凭证，来验证你的 Rancher Keycloak 配置。
|
||||
|
||||
:::note
|
||||
|
||||
你可能需要禁用弹出窗口阻止程序才能看到 IdP 登录页面。
|
||||
|
||||
:::
|
||||
|
||||
**结果**：已将 Rancher 配置为使用 Keycloak。你的用户现在可以使用 Keycloak 登录名登录 Rancher。
|
||||
|
||||
:::note SAML 身份提供商注意事项
|
||||
|
||||
- SAML 协议不支持搜索或查找用户或组。因此，将用户或组添加到 Rancher 时不会对其进行验证。
|
||||
- 添加用户时，必须正确输入确切的用户 ID（即 `UID` 字段）。键入用户 ID 时，将不会搜索可能匹配的其他用户 ID。
|
||||
- 添加组时，必须从文本框旁边的下拉列表中选择组。Rancher 假定来自文本框的任何输入都是用户。
|
||||
- 用户组下拉列表仅显示你所属的用户组。如果你不是某个组的成员，你将无法添加该组。
|
||||
|
||||
:::
|
||||
|
||||
## 配置参考
|
||||
|
||||
| 字段 | 描述 |
|
||||
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 显示名称字段 | 包含用户显示名称的属性。<br/><br/>示例：`givenName` |
|
||||
| 用户名字段 | 包含用户名/给定名称的属性。<br/><br/>示例：`email` |
|
||||
| UID 字段 | 每个用户独有的属性。<br/><br/>示例：`email` |
|
||||
| 用户组字段 | 创建用于管理组成员关系的条目。<br/><br/>示例：`member` |
|
||||
| Entity ID 字段 | Keycloak 客户端中需要配置为客户端的 ID。<br/><br/>默认值：`https://yourRancherHostURL/v1-saml/keycloak/saml/metadata` |
|
||||
| Rancher API 主机 | Rancher Server 的 URL。 |
|
||||
| 私钥/证书 | 在 Rancher 和你的 IdP 之间创建安全外壳（SSH）的密钥/证书对。 |
|
||||
| IDP 元数据 | 从 IdP 服务器导出的 `metadata.xml` 文件。 |
|
||||
|
||||
:::tip
|
||||
|
||||
你可以使用 openssl 命令生成一个密钥/证书对。例如：
|
||||
|
||||
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout myservice.key -out myservice.cert
|
||||
|
||||
:::
|
||||
|
||||
## 附录：故障排除
|
||||
|
||||
如果你在测试与 Keycloak 服务器的连接时遇到问题，请先检查 SAML 客户端的配置选项。你还可以检查 Rancher 日志来查明问题的原因。调试日志可能包含有关错误的更详细信息。详情请参见[如何启用调试日志](../../../../faq/technical-items.md#如何启用调试日志记录)。
|
||||
|
||||
### 不能重定向到 Keycloak
|
||||
|
||||
点击**使用 Keycloak 认证**时，没有重定向到你的 IdP。
|
||||
|
||||
* 验证你的 Keycloak 客户端配置。
|
||||
* 确保 `Force Post Binding` 设为 `OFF`。
|
||||
|
||||
|
||||
### IdP 登录后显示禁止消息
|
||||
|
||||
你已正确重定向到你的 IdP 登录页面，并且可以输入凭证，但是之后收到 `Forbidden` 消息。
|
||||
|
||||
* 检查 Rancher 调试日志。
|
||||
* 如果日志显示 `ERROR: either the Response or Assertion must be signed`，确保 `Sign Documents` 或 `Sign assertions` 在 Keycloak 客户端中设置为 `ON`。
|
||||
|
||||
### 访问 `/v1-saml/keycloak/saml/metadata` 时返回 HTTP 502
|
||||
|
||||
常见原因：配置 SAML 提供商之前未创建元数据。
|
||||
尝试配置 Keycloak，并将它保存为你的 SAML 提供商，然后访问元数据。
|
||||
|
||||
### Keycloak 错误："We're sorry, failed to process response"
|
||||
|
||||
* 检查你的 Keycloak 日志。
|
||||
* 如果日志显示 `failed: org.keycloak.common.VerificationException: Client does not have a public key`，请在 Keycloak 客户端中将 `Encrypt Assertions` 设为 `OFF`。
|
||||
|
||||
### Keycloak 错误："We're sorry, invalid requester"
|
||||
|
||||
* 检查你的 Keycloak 日志。
|
||||
* 如果日志显示 `request validation failed: org.keycloak.common.VerificationException: SigAlg was null`，请在 Keycloak 客户端中将 `Client Signature Required` 设为 `OFF`。
|
||||
+107
@@ -0,0 +1,107 @@
|
||||
---
|
||||
title: 配置 Okta (SAML)
|
||||
---
|
||||
|
||||
如果你的组织使用 Okta Identity Provider (IdP) 进行用户身份验证，你可以通过配置 Rancher 来允许用户使用 IdP 凭证登录。
|
||||
|
||||
:::note
|
||||
|
||||
Okta 集成仅支持服务提供商发起的登录。
|
||||
|
||||
:::
|
||||
## 先决条件
|
||||
|
||||
在 Okta 中，使用以下设置创建一个新的 SAML 应用。如需获取帮助，请参见 [Okta 文档](https://developer.okta.com/standards/SAML/setting_up_a_saml_application_in_okta)。
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Single Sign on URL` | `https://yourRancherHostURL/v1-saml/okta/saml/acs` |
|
||||
| `Audience URI (SP Entity ID)` | `https://yourRancherHostURL/v1-saml/okta/saml/metadata` |
|
||||
|
||||
## 在 Rancher 中配置 Okta
|
||||
|
||||
你可以将 Okta 与 Rancher 集成，以便经过身份认证的用户通过组权限访问 Rancher 资源。Okta 会返回一个对用户进行身份认证的 SAML 断言，包括用户所属的组。
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **Okta**。
|
||||
1. 填写**配置 Okta 账号**表单。下面的示例描述了如何将 Okta 属性从属性语句映射到 Rancher 中的字段：
|
||||
|
||||
| 字段 | 描述 |
|
||||
| ------------------------- | ----------------------------------------------------------------------------- |
|
||||
| 显示名称字段 | 属性语句中包含用户显示名称的属性名称。 |
|
||||
| 用户名字段 | 属性语句中包含用户名/给定名称的属性名称。 |
|
||||
| UID 字段 | 属性语句中每个用户唯一的属性名称。 |
|
||||
| 用户组字段 | 组属性语句中公开你的组的属性名称。 |
|
||||
| Rancher API 主机 | Rancher Server 的 URL。 |
|
||||
| 私钥/证书 | 密钥/证书对，用于断言加密。 |
|
||||
| 元数据 XML | 你在应用 `Sign On` 部分中找到的 `Identity Provider metadata` 文件。 |
|
||||
|
||||
:::tip
|
||||
|
||||
你可以使用 openssl 命令生成一个密钥/证书对。例如：
|
||||
|
||||
```
|
||||
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout myservice.key -out myservice.crt
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
|
||||
1. 完成**配置 Okta 账号**表单后，单击**启用**。
|
||||
|
||||
Rancher 会将你重定向到 IdP 登录页面。输入使用 Okta IdP 进行身份验证的凭证，来验证你的 Rancher Okta 配置。
|
||||
|
||||
:::note
|
||||
|
||||
如果什么都没有发生，很可能是因为你的浏览器阻止了弹出窗口。请在弹出窗口阻止程序中禁用 Rancher 域，并在其他类似扩展中将 Rancher 列入白名单。
|
||||
|
||||
:::
|
||||
|
||||
**结果**：已将 Rancher 配置为使用 Okta。你的用户现在可以使用 Okta 登录名登录 Rancher。
|
||||
|
||||
:::note SAML 身份提供商注意事项
|
||||
|
||||
如果你在没有 OpenLDAP 的情况下配置 Okta，你将无法搜索或直接查找用户或组。相关的警告如下：
|
||||
|
||||
- 在 Rancher 中为用户和组分配权限时将不会验证用户和组。
|
||||
- 添加用户时，必须正确输入确切的用户 ID（即 `UID` 字段）。键入用户 ID 时，将不会搜索可能匹配的其他用户 ID。
|
||||
- 添加组时，必须从文本框旁边的下拉列表中选择组。Rancher 假定来自文本框的任何输入都是用户。
|
||||
- 用户组下拉列表仅显示你所属的用户组。如果你不是某个组的成员，你将无法添加该组。
|
||||
|
||||
:::
|
||||
|
||||
## Okta 与 OpenLDAP 搜索
|
||||
|
||||
你可以添加 OpenLDAP 后端来协助用户和组搜索。Rancher 将显示来自 OpenLDAP 服务的其他用户和组。这允许你将权限分配给用户不属于的组。
|
||||
|
||||
### OpenLDAP 先决条件
|
||||
|
||||
如果你使用 Okta 作为 IdP，你可以[设置 LDAP 接口](https://help.okta.com/en-us/Content/Topics/Directory/LDAP-interface-main.htm)以供 Rancher 使用。你还可以配置外部 OpenLDAP Server。
|
||||
|
||||
你必须使用 LDAP 绑定帐户（也称为 ServiceAccount）来配置 Rancher，以便搜索和检索应具有访问权限的用户和组的 LDAP 条目。不要使用管理员帐户或个人帐户作为 LDAP 绑定帐户。在 OpenLDAP 中[创建](https://help.okta.com/en-us/Content/Topics/users-groups-profiles/usgp-add-users.htm)一个专用帐户，对搜索库下的用户和组具有只读访问权限。
|
||||
|
||||
:::warning 安全注意事项
|
||||
|
||||
OpenLDAP ServiceAccount 用于所有搜索。无论用户个人的 SAML 权限是什么，Rancher 用户都将看到 OpenLDAP ServiceAccount 可以查看的用户和组。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
> **使用 TLS？**
|
||||
>
|
||||
> 如果 OpenLDAP Server 使用的证书是自签名的或来自无法识别的证书颁发机构，则 Rancher 需要 PEM 格式的 CA 证书（包含所有中间证书）。你需要在配置期间提供此证书，以便 Rancher 能够验证证书链。
|
||||
|
||||
### 在 Rancher 中配置 OpenLDAP
|
||||
|
||||
[配置 OpenLDAP Server、组和用户的设置](../configure-openldap/openldap-config-reference.md)。请注意，不支持嵌套组成员。
|
||||
|
||||
> 在继续配置之前，请熟悉[外部身份认证配置和主要用户](../../../../pages-for-subheaders/authentication-config.md#外部身份验证配置和用户主体)。
|
||||
|
||||
1. 使用分配了 [administrator](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions) 角色（即 _本地主体_）的本地用户登录到 Rancher。
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **Okta**，如果已配置 SAML，则单击**编辑配置**。
|
||||
1. 在**用户和组搜索**下，选中**配置 OpenLDAP Server**。
|
||||
|
||||
如果你在测试与 OpenLDAP Server 的连接时遇到问题，请确保你输入了ServiceAccount 的凭证并正确配置了搜索库。你可以检查 Rancher 日志来查明根本原因。调试日志可能包含有关错误的更详细信息。请参阅[如何启用调试日志](../../../../faq/technical-items.md#如何启用调试日志记录)了解更多信息。
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: 配置 PingIdentity (SAML)
|
||||
---
|
||||
|
||||
如果你的组织使用 Ping Identity Provider (IdP) 进行用户身份验证，你可以通过配置 Rancher 来允许用户使用 IdP 凭证登录。
|
||||
|
||||
> **先决条件**：
|
||||
>
|
||||
> - 你必须配置了 [Ping IdP 服务器](https://www.pingidentity.com/)。
|
||||
> - 以下是 Rancher Service Provider 配置所需的 URL：
|
||||
> 元数据 URL：`https://<rancher-server>/v1-saml/ping/saml/metadata`
|
||||
> 断言使用者服务 (ACS) URL：`https://<rancher-server>/v1-saml/ping/saml/acs`
|
||||
> 请注意，在 Rancher 中保存验证配置之前，这些 URL 不会返回有效数据。
|
||||
> - 从 IdP 服务器导出 `metadata.xml` 文件。详情请参见 [PingIdentity 文档](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html)。
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **Ping Identity**。
|
||||
1. 填写**配置 Ping 账号**表单。Ping IdP 允许你指定要使用的数据存储。你可以添加数据库或使用现有的 ldap 服务器。例如，如果你选择 Active Directory (AD) 服务器，下面的示例将描述如何将 AD 属性映射到 Rancher 中的字段：
|
||||
|
||||
1. **显示名称字段**：包含用户显示名称的 AD 属性（例如：`displayName`）。
|
||||
|
||||
1. **用户名字段**：包含用户名/给定名称的 AD 属性（例如：`givenName`）。
|
||||
|
||||
1. **UID 字段**：每个用户唯一的 AD 属性（例如：`sAMAccountName`、`distinguishedName`）。
|
||||
|
||||
1. **用户组字段**: 创建用于管理组成员关系的条目（例如：`memberOf`）。
|
||||
|
||||
1. **Entity ID 字段**（可选）：你的合作伙伴已公布的、依赖协议的、唯一的标识符。该 ID 将你的组织定义为将服务器用于 SAML 2.0 事务的实体。这个 ID 可以通过带外传输或 SAML 元数据文件获得。
|
||||
|
||||
1. **Rancher API 主机**：你的 Rancher Server 的 URL。
|
||||
|
||||
1. **私钥**和**证书**：密钥/证书对，用于在 Rancher 和你的 IdP 之间创建一个安全外壳（SSH）。
|
||||
|
||||
你可以使用 openssl 命令进行创建。例如：
|
||||
|
||||
```
|
||||
openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
|
||||
```
|
||||
1. **IDP 元数据**：[从 IdP 服务器导出的 `metadata.xml` 文件](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html)。
|
||||
|
||||
|
||||
1. 完成**配置 Ping 账号**表单后，单击**启用**。
|
||||
|
||||
Rancher 会将你重定向到 IdP 登录页面。输入使用 Ping IdP 进行身份验证的凭证，来验证你的 Rancher PingIdentity 配置。
|
||||
|
||||
:::note
|
||||
|
||||
你可能需要禁用弹出窗口阻止程序才能看到 IdP 登录页面。
|
||||
|
||||
:::
|
||||
|
||||
**结果**：已将 Rancher 配置为使用 PingIdentity。你的用户现在可以使用 PingIdentity 登录名登录 Rancher。
|
||||
|
||||
:::note SAML 身份提供商注意事项
|
||||
|
||||
- SAML 协议不支持搜索或查找用户或组。因此，将用户或组添加到 Rancher 时不会对其进行验证。
|
||||
- 添加用户时，必须正确输入确切的用户 ID（即 `UID` 字段）。键入用户 ID 时，将不会搜索可能匹配的其他用户 ID。
|
||||
- 添加组时，必须从文本框旁边的下拉列表中选择组。Rancher 假定来自文本框的任何输入都是用户。
|
||||
- 用户组下拉列表仅显示你所属的用户组。如果你不是某个组的成员，你将无法添加该组。
|
||||
|
||||
:::
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: 本地身份验证
|
||||
---
|
||||
|
||||
在配置外部验证提供程序之前，你将默认使用本地身份验证。Rancher 将用户帐户信息（例如用户名和密码）存储在本地。默认情况下，用于首次登录 Rancher 的 `admin` 用户就是一个本地用户。
|
||||
|
||||
## 添加本地用户
|
||||
|
||||
无论是否使用外部身份验证服务，你都应创建一些本地身份认证的用户，以便在外部验证服务遇到问题时继续使用 Rancher。
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**用户**。
|
||||
1. 单击**创建**。
|
||||
1. 完成**添加用户**的表单。
|
||||
1. 单击**创建**。
|
||||
+77
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: 用户和组
|
||||
---
|
||||
|
||||
Rancher 依赖用户和组来决定允许登录到 Rancher 的用户，以及他们可以访问哪些资源。你配置外部身份验证提供程序后，该提供程序的用户将能够登录到你的 Rancher Server。用户登录时，验证提供程序将向你的 Rancher Server 提供该用户所属的组列表。
|
||||
|
||||
你可以通过向资源添加用户或组，来控制其对集群、项目、全局 DNS 提供程序和相关资源的访问。将组添加到资源时，身份验证提供程序中属于该组的所有用户都将能够使用组的权限访问该资源。有关角色和权限的更多信息，请参见 [RBAC](../../../../pages-for-subheaders/manage-role-based-access-control-rbac.md)。
|
||||
|
||||
## 管理成员
|
||||
|
||||
向资源添加用户或用户组时，你可以通过输入用户或组的名称来搜索用户或组。Rancher Server 会查询身份验证提供程序，来查找与你输入的内容匹配的用户和组。搜索仅限于你登录时使用的身份验证提供程序。例如，如果你启用了 GitHub 身份验证，但使用[本地](create-local-users.md)用户登录，则无法搜索 GitHub 用户或组。
|
||||
|
||||
你可以查看和管理所有用户，包括本地用户和来自身份验证提供程序的用户。在左上角，单击 **☰ > 用户 & 认证**。在左侧导航栏中单击**用户**。
|
||||
|
||||
:::note SAML 身份提供商注意事项
|
||||
|
||||
- SAML 协议不支持搜索或查找用户或组。因此，将用户或组添加到 Rancher 时不会对其进行验证。
|
||||
- 添加用户时，必须正确输入确切的用户 ID（即 `UID` 字段）。键入用户 ID 时，将不会搜索可能匹配的其他用户 ID。
|
||||
- 添加组时，必须从文本框旁边的下拉列表中选择组。Rancher 假定来自文本框的任何输入都是用户。
|
||||
- 用户组下拉列表仅显示你所属的用户组。如果你不是某个组的成员，你将无法添加该组。
|
||||
|
||||
:::
|
||||
|
||||
## 用户信息
|
||||
|
||||
Rancher 会维护通过身份验证提供程序登录的每个用户的信息，包括用户是否允许访问 Rancher Server，以及用户所属的组的列表。Rancher 保留此用户信息，以便 CLI、API 和 kubectl 能够准确地反映用户基于身份验证提供程序中的组成员关系的访问。
|
||||
|
||||
当用户使用身份验证提供程序登录到 UI 时，Rancher 将自动更新该用户信息。
|
||||
|
||||
### 自动刷新用户信息
|
||||
|
||||
Rancher 会定期刷新用户信息，甚至在用户通过 UI 登录之前也是如此。你可以控制 Rancher 执行刷新的频率。
|
||||
|
||||
有两个参数可以控制这个操作：
|
||||
|
||||
- **`auth-user-info-max-age-seconds`**
|
||||
|
||||
此设置控制用户信息的最大老化时间，如果超过这个时间，Rancher 就会刷新信息。如果用户进行 API 调用（直接 UI 访问或通过使用 Rancher CLI 或 kubectl 调用），并且与 Rancher 上次刷新用户信息的时间间隔大于此设置，则 Rancher 将触发刷新。此设置默认为 `3600` 秒，即 1 小时。
|
||||
|
||||
- **`auth-user-info-resync-cron`**
|
||||
|
||||
此设置控制用于所有用户重新同步身份验证提供程序信息的定期任务周期。无论用户最近是否登录或使用 API，自动刷新任务都会按照指定的时间间隔刷新用户信息。此设置默认为 `0 0 * * *`，即每天午夜进行一次。有关此设置的有效值的更多信息，请参见 [Cron 文档](https://en.wikipedia.org/wiki/Cron)。
|
||||
|
||||
如果需要更改设置：
|
||||
|
||||
1. 在左上角，单击 **☰ > 全局设置**。
|
||||
1. 前往你需要配置的设置，并点击 **⋮ > 编辑设置**。
|
||||
|
||||
:::note
|
||||
|
||||
由于 SAML 不支持用户查找，因此基于 SAML 的身份验证提供程序不支持定期刷新用户信息。只有当用户登录到 Rancher UI 时，才会刷新用户信息。
|
||||
|
||||
:::
|
||||
### 手动刷新用户信息
|
||||
|
||||
如果你不确定 Rancher 上一次执行用户信息自动刷新的时间，则可以通过手动刷新来刷新所有用户的信息。
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在**用户**页面，单击**刷新用户组成员名单**。
|
||||
|
||||
**结果**：Rancher 刷新了所有用户的信息。请求此刷新将更新哪些用户可以访问 Rancher 以及每个用户所属的所有组。
|
||||
|
||||
:::note
|
||||
|
||||
由于 SAML 不支持用户查找，因此基于 SAML 的身份验证提供程序不支持手动刷新用户信息。只有当用户登录到 Rancher UI 时，才会刷新用户信息。
|
||||
|
||||
:::
|
||||
|
||||
## 会话周期
|
||||
|
||||
用户会话的默认生命周期（TTL）是可调的。默认的会话周期是 16 小时。
|
||||
|
||||
1. 在左上角，单击 **☰ > 全局设置**。
|
||||
1. 前往 **`auth-user-session-ttl-minutes`** 并单击**⋮ > 编辑设置**。
|
||||
1. 输入会话应该持续的时间（以分钟为单位），然后单击**Save**。
|
||||
|
||||
**结果**：用户的 Rancher 登录会话在设定的分钟数后自动退出。
|
||||
+85
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: 认证、权限和全局配置
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration"/>
|
||||
</head>
|
||||
|
||||
安装完成后，[系统管理员](manage-role-based-access-control-rbac/global-permissions.md) 应该通过 Rancher 配置认证、授权、安全性、默认设置、安全策略、驱动和全局 DNS 条目。
|
||||
|
||||
## 首次登录
|
||||
|
||||
首次登录 Rancher 后，Rancher 会提示你输入 **Rancher Server URL**，你应该将 URL 设置为访问 Rancher Server 的主入口点。当负载均衡器运行在 Rancher Server 集群前面时，URL 应该设置为负载均衡地址。系统会自动尝试根据运行 Rancher Server 的主机 IP 地址或主机名推断 Rancher Server URL，但只有当 Rancher Server 以单节点方式安装时才有效。因此在大多数情况下，你都需要将 Rancher Server URL 设置为正确的值。
|
||||
|
||||
:::danger
|
||||
|
||||
当设置完 Rancher Server URL 后，我们不支持修改它。请格外小心的设置此项配置。
|
||||
|
||||
:::
|
||||
|
||||
## 认证
|
||||
|
||||
Rancher 为 Kubernetes 增加了一项关键特性是集中式的用户认证。此特性允许设置本地用户和/或连接到外部认证程序。通过连接到外部认证程序，你可以使用该程序提供的用户和组。
|
||||
|
||||
更多关于认证的工作原理以及如何配置对接各个认证程序，请参考[认证](authentication-config/authentication-config.md)。
|
||||
|
||||
## 授权
|
||||
|
||||
在 Rancher 中，每个人都是以 _用户_ 的身份进行鉴权，这是一个授予你访问 Rancher 的登录身份。用户登录 Rancher 后，他们的 _授权_ 或者他们在系统中的访问权限由用户的角色决定。Rancher 提供了内置的角色，允许你你轻松地配置用户对资源的权限，但是 Rancher 还提供了为每个 Kubernetes 资源自定义角色的功能。
|
||||
|
||||
更多关于授权的工作原理以及自定义角色的使用，请参考 [RBAC](manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
|
||||
|
||||
## Pod 安全策略
|
||||
|
||||
_Pod 安全策略_ (或 PSPs) 是控制 Pod 安全敏感方面规范的对象，例如 root 权限。如果一个 Pod 不满足 PSP 中指定的条件，Kubernetes 将不允许 Pod 启动，同时 Rancher 会显示一条错误信息。
|
||||
|
||||
更多关于如何创建和使用 PSPs 的内容，请参考 [Pod 安全策略](create-pod-security-policies.md)。
|
||||
|
||||
## Provisioning Drivers
|
||||
|
||||
Rancher 中的驱动允许你管理哪些程序可以预置[托管的 Kubernetes 集群](../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md) 或 [云服务器节点](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)，允许 Rancher 部署和管理 Kubernetes。
|
||||
|
||||
更多信息请参考 [Provisioning Drivers](about-provisioning-drivers/about-provisioning-drivers.md)。
|
||||
|
||||
## 添加 Kubernetes 版本到 Rancher 中
|
||||
|
||||
使用此功能，你可以在最新版本的 Kubernetes 发布后立即升级，而不需要升级 Rancher。此功能允许你轻松升级 Kubernetes 的补丁版本（例如 `v1.15.X`），但不打算升级 Kubernetes 的次要版本（例如 `v1.X.0`），因为 Kubernetes 倾向于在次要版本之间弃用或添加 API。
|
||||
|
||||
Rancher 用于配置 [RKE 集群](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) 的信息现在存储于 Rancher Kubernetes 元数据中，更多关于元数据的配置以及如何更改用于配置 RKE 集群的 Kubernetes 版本的信息，请参考 [Rancher Kubernetes 元数据](../../../getting-started/installation-and-upgrade/upgrade-kubernetes-without-upgrading-rancher.md)。
|
||||
|
||||
Rancher Kubernetes 元数据包含 Kubernetes 版本信息，Rancher 使用这些信息来配置 [RKE 集群](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)。
|
||||
|
||||
关于元数据的工作原理以及如何配置元数据，请参考 [Rancher Kubernetes 元数据](../../../getting-started/installation-and-upgrade/upgrade-kubernetes-without-upgrading-rancher.md)。
|
||||
|
||||
## 全局设置
|
||||
|
||||
控制某些全局级别 Rancher 配置项可以在顶部的导航栏中找到。
|
||||
|
||||
点击左上角的 **☰** ，然后选择 **全局设置**，查看和配置以下设置：
|
||||
|
||||
- **设置**: 各种 Rancher 默认值，例如用户密码的最小长度 (`password-min-length`)。在修改这些设置项时应该谨慎，因为设置无效的值可能会破坏 Rancher 的安装。
|
||||
- **功能开关**: 可以打开或关闭 Rancher 的某些功能，一些标志用于 [实验性功能](#启用实验性功能).
|
||||
- **横幅**: 可以添加到门户上固定位置的元素，例如你可以使用这些选项在用户登录 Rancher 时为他们设置[自定义的横幅](custom-branding.md#固定横幅)。
|
||||
- **品牌**: 你可以[自定义](custom-branding.md) Rancher UI 的设计元素，你可以增加一个自定义的 logo 或 favicon，也可以修改 UI 的颜色。
|
||||
- **性能**: Rancher UI 的性能设置，例如增量资源加载。
|
||||
- **主页链接**: Rancher UI **主页**页面上显示的链接，你可以修改默认链接的可见性或者增加自己的链接。
|
||||
|
||||
### 启用实验性功能
|
||||
|
||||
Rancher 包含一些默认处于实验性和/或禁用的功能，功能开关允许你启用这些特性。更多信息请参考[功能开关](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。
|
||||
|
||||
### 全局配置
|
||||
|
||||
仅在激活 **legacy** [功能开关](../../advanced-user-guides/enable-experimental-features/enable-experimental-features.md) 时才可以看见**全局配置**选项。在 v2.6 及更新版本新安装的 Rancher 已经默认禁用了 **legacy** 特性。如果你是从早期的 Rancher 版本升级，或者在 Rancher v2.6 及更新版本上启用了 **legacy** 特性，顶部导航菜单中将会显示**全局配置**：
|
||||
|
||||
1. 点击左上角的 **☰**。
|
||||
1. 在 **旧版应用** 中选择 **全局配置**。
|
||||
|
||||
**全局配置**提供以下功能：
|
||||
|
||||
- **应用商店**
|
||||
- **全局 DNS 条目**
|
||||
- **全局 DNS 提供商**
|
||||
|
||||
由于这些是旧版特性，请参考 Rancher v2.0-v2.4 的[应用商店](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md), [全局 DNS 条目](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#adding-a-global-dns-entry), 以及 [全局 DNS 提供商](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/globaldns.md#editing-a-global-dns-provider)。
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: 配置 Microsoft AD FS (SAML)
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-microsoft-ad-federation-service-saml"/>
|
||||
</head>
|
||||
|
||||
如果你的组织使用 Active Directory Federation Service (AD FS) 进行用户身份认证，你可以通过配置 Rancher 来允许用户使用 AD FS 凭证登录。
|
||||
|
||||
## 先决条件
|
||||
|
||||
已安装 Rancher。
|
||||
|
||||
- 获取你的 Rancher Server URL。配置 AD FS 时，请使用该 URL 替换 `<RANCHER_SERVER>` 占位符。
|
||||
- 你必须在 Rancher 安装时具有全局管理员账号。
|
||||
|
||||
你必须配置 [Microsoft AD FS 服务器](https://docs.microsoft.com/en-us/windows-server/identity/active-directory-federation-services)。
|
||||
|
||||
- 获取你的 AD FS 服务器 IP/DNS 名称。配置 AD FS 时，请使用该 IP/DNS 名称替换 `<AD_SERVER>` 占位符。
|
||||
- 你必须有在 AD FS 服务器上添加 [Relying Party Trusts](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust) 的权限。
|
||||
|
||||
## 配置概要
|
||||
|
||||
要让 Rancher Server 使用 Microsoft AD FS，你需要在 Active Directory 服务器上配置 AD FS，并将 Rancher 配置为使用 AD FS 服务器。如果需要获取在 Rancher 中设置 Microsoft AD FS 身份认证的指南，请参见：
|
||||
|
||||
- [1. 在 Microsoft AD FS 中配置 Rancher](configure-ms-adfs-for-rancher.md)
|
||||
- [2. 在 Rancher 中配置 Microsoft AD FS](configure-rancher-for-ms-adfs.md)
|
||||
|
||||
:::note SAML 身份提供商注意事项
|
||||
|
||||
- SAML 协议不支持搜索或查找用户或组。因此，将用户或组添加到 Rancher 时不会对其进行验证。
|
||||
- 添加用户时，必须正确输入确切的用户 ID（即 `UID` 字段）。键入用户 ID 时，将不会搜索可能匹配的其他用户 ID。
|
||||
- 添加组时，必须从文本框旁边的下拉列表中选择组。Rancher 假定来自文本框的任何输入都是用户。
|
||||
- 用户组下拉列表仅显示你所属的用户组。如果你不是某个组的成员，你将无法添加该组。
|
||||
|
||||
:::
|
||||
|
||||
### [后续操作：在 Microsoft AD FS 中配置 Rancher](configure-ms-adfs-for-rancher.md)
|
||||
+88
@@ -0,0 +1,88 @@
|
||||
---
|
||||
title: 1. 在 Microsoft AD FS 中配置 Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-microsoft-ad-federation-service-saml/configure-ms-adfs-for-rancher"/>
|
||||
</head>
|
||||
|
||||
在配置 Rancher 以支持 Active Directory Federation Service (AD FS) 之前，你必须在 AD FS 中将 Rancher 添加为 [relying party trust](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts)（信赖方信任）。
|
||||
|
||||
1. 以管理用户身份登录 AD 服务器。
|
||||
|
||||
1. 打开 **AD FS Management** 控制台。在 **Actions** 菜单中选择 **Add Relying Party Trust...**。然后单击 **Start**。
|
||||
|
||||
|
||||
|
||||
1. 选择 **Enter data about the relying party manually** 作为获取信赖方数据的选项。
|
||||
|
||||
|
||||
|
||||
1. 为 **Relying Party Trust** 设置**显示名称**，例如 `Rancher`。
|
||||
|
||||
|
||||
|
||||
1. 选择 **AD FS profile** 作为信赖方信任的配置文件。
|
||||
|
||||
|
||||
|
||||
1. 留空 **optional token encryption certificate**，因为 Rancher AD FS 不会使用它。
|
||||
|
||||
|
||||
|
||||
1. 选择 **Enable support for the SAML 2.0 WebSSO protocol** 并在 Service URL 处输入 `https://<rancher-server>/v1-saml/adfs/saml/acs`。
|
||||
|
||||
|
||||
|
||||
1. 将 `https://<rancher-server>/v1-saml/adfs/saml/metadata` 添加为 **Relying party trust identifier**。
|
||||
|
||||
|
||||
|
||||
1. 本教程不涉及多重身份认证。如果你想配置多重身份认证，请参见 [Microsoft 文档](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs)。
|
||||
|
||||
|
||||
|
||||
1. 在 **Choose Issuance Authorization RUles** 中，你可以根据用例选择任何一个可用选项。但是考虑到本指南的目的，请选择 **Permit all users to access this relying party**。
|
||||
|
||||
|
||||
|
||||
1. 检查所有设置后，选择 **Next** 来添加信赖方信任。
|
||||
|
||||
|
||||
|
||||
1. 选择 **Open the Edit Claim Rules...**。然后单击 **Close**。
|
||||
|
||||
|
||||
|
||||
1. 在 **Issuance Transform Rules** 选项卡中，单击 **Add Rule...**。
|
||||
|
||||
|
||||
|
||||
1. 在 **Claim rule template** 中选择 **Send LDAP Attributes as Claims**。
|
||||
|
||||
|
||||
|
||||
1. 将 **Claim rule name** 设置为所需的名称（例如 `Rancher Attributes`）并选择 **Active Directory** 作为 **Attribute store**。创建对应下表的映射：
|
||||
|
||||
| LDAP 属性 | 传出声明类型 |
|
||||
| -------------------------------------------- | ------------ |
|
||||
| Given-Name | Given Name |
|
||||
| User-Principal-Name | UPN |
|
||||
| Token-Groups - Qualified by Long Domain Name | Group |
|
||||
| SAM-Account-Name | 名称 |
|
||||
|
||||
<br/>
|
||||
|
||||
|
||||
|
||||
1. 从 AD 服务器的以下位置下载 `federationmetadata.xml`：
|
||||
|
||||
```
|
||||
https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml
|
||||
```
|
||||
|
||||
**结果**：你已将 Rancher 添加为依赖信任方。现在你可以配置 Rancher 来使用 AD。
|
||||
|
||||
### 后续操作
|
||||
|
||||
[在 Rancher 中配置 Microsoft AD FS ](configure-rancher-for-ms-adfs.md)
|
||||
+57
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: 2. 在 Rancher 中配置 Microsoft AD FS
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-microsoft-ad-federation-service-saml/configure-rancher-for-ms-adfs"/>
|
||||
</head>
|
||||
|
||||
完成[在 Microsoft AD FS 中配置 Rancher](configure-ms-adfs-for-rancher.md) 后，将你的 Active Directory Federation Service (AD FS) 信息输入 Rancher，以便 AD FS 用户可以通过 Rancher 进行身份认证。
|
||||
|
||||
:::note 配置 ADFS 服务器的重要说明：
|
||||
|
||||
- SAML 2.0 WebSSO 协议服务 URL 为：`https://<RANCHER_SERVER>/v1-saml/adfs/saml/acs`
|
||||
- 信赖方信任标识符 URL 为：`https://<RANCHER_SERVER>/v1-saml/adfs/saml/metadata`
|
||||
- 你必须从 AD FS 服务器导出 `federationmetadata.xml` 文件。你可以在 `https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml` 中找到该文件。
|
||||
|
||||
:::
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **ADFS**。
|
||||
1. 填写**配置 AD FS 账号**表单。Microsoft AD FS 允许你指定现有的 Active Directory (AD) 服务器。[以下配置示例](#配置)描述了如何将 AD 属性映射到 Rancher 中的字段。
|
||||
1. 完成**配置 AD FS 账号**表单后，单击**启用**。
|
||||
|
||||
Rancher 会将你重定向到 AD FS 登录页面。输入使用 Microsoft AD FS 进行身份验证的凭证，来验证你的 Rancher AD FS 配置。
|
||||
|
||||
:::note
|
||||
|
||||
你可能需要禁用弹出窗口阻止程序才能看到 AD FS 登录页面。
|
||||
|
||||
:::
|
||||
|
||||
**结果**：已将 Rancher 配置为使用 AD FS。你的用户现在可以使用 AD FS 登录名登录 Rancher。
|
||||
|
||||
## 配置
|
||||
|
||||
| 字段 | 描述 |
|
||||
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| 显示名称字段 | 包含用户显示名称的 AD 属性。<br/><br/>示例：`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` |
|
||||
| 用户名字段 | 包含用户名/给定名称的 AD 属性。<br/><br/>示例：`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname` |
|
||||
| UID 字段 | 每个用户独有的 AD 属性。<br/><br/>示例：`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn` |
|
||||
| 用户组字段 | 创建用于管理组成员关系的条目。<br/><br/>示例：`http://schemas.xmlsoap.org/claims/Group` |
|
||||
| Rancher API 主机 | Rancher Server 的 URL。 |
|
||||
| 私钥/证书 | 在 Rancher 和你的 AD FS 之间创建安全外壳（SSH）的密钥/证书对。确保将 Common Name (CN) 设置为 Rancher Server URL。<br/><br/>[证书创建命令](#cert-command) |
|
||||
| 元数据 XML | 从 AD FS 服务器导出的 `federationmetadata.xml` 文件。<br/><br/>你可以在 `https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml` 找到该文件。 |
|
||||
|
||||
<a id="cert-command"></a>
|
||||
|
||||
:::tip
|
||||
|
||||
你可以使用 openssl 命令生成证书。例如：
|
||||
|
||||
```
|
||||
openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
|
||||
```
|
||||
|
||||
:::
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: 配置 OpenLDAP
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-openldap"/>
|
||||
</head>
|
||||
|
||||
如果你的组织使用 LDAP 进行认证，则可以配置 Rancher 与 OpenLDAP 服务器通信以对用户进行认证。这时 Rancher 管理员可以对外部用户系统中的用户和组进行集群和项目的访问控制，同时允许终端用户在登录 Rancher UI 时使用其 LDAP 凭据进行身份认证。
|
||||
|
||||
## 先决条件
|
||||
|
||||
必须为 Rancher 配置 LDAP 绑定账号（即 ServiceAccount），来搜索和检索应该具有访问权限的用户和组的 LDAP 条目。建议不要使用管理员账号或个人账号，而应在 OpenLDAP 中创建一个专用账号，该账号对配置的搜索库下的用户和组需要具有只读权限（参见下文）。
|
||||
|
||||
> **使用 TLS?**
|
||||
>
|
||||
> 如果 OpenLDAP 服务器使用的证书是自签名的或不是来自认可的证书颁发机构，请确保手头有 PEM 格式的 CA 证书（包含所有中间证书）。你必须在配置期间粘贴此证书，以便 Rancher 能够验证证书链。
|
||||
|
||||
## 在 Rancher 中配置 OpenLDAP
|
||||
|
||||
配置 OpenLDAP 服务器，组和用户的设置。有关填写每个字段的帮助，请参见[配置参考](openldap-config-reference.md)
|
||||
|
||||
> 在开始之前，请熟悉[外部认证配置和用户主体](../authentication-config/authentication-config.md#外部认证配置和用户主体)的概念。
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **OpenLDAP**。填写**配置 OpenLDAP 服务器**表单。
|
||||
1. 点击**启用**。
|
||||
|
||||
### 测试认证
|
||||
|
||||
完成配置后，请测试与 OpenLDAP 服务器的连接。如果测试成功，则表明 OpenLDAP 认证已启用。
|
||||
|
||||
:::note
|
||||
|
||||
于此步骤中输入的 OpenLDAP 用户凭证将映射到本地主体账号，并在 Rancher 中分配系统管理员权限。因此，你应该决定使用哪个 OpenLDAP 账号来执行此步骤。
|
||||
|
||||
:::
|
||||
|
||||
1. 输入应映射到本地主体账号的 OpenLDAP 账号的**用户名**和**密码** 。
|
||||
2. 点击**启用 OpenLDAP 认证**来测试 OpenLDAP 的连接并完成设置。
|
||||
|
||||
**结果**：
|
||||
|
||||
- OpenLDAP 认证配置成功。
|
||||
- 与输入凭证对应的 LDAP 用户被映射到本地主体（管理员）账号。
|
||||
|
||||
:::note
|
||||
|
||||
如果 LDAP 服务中断，你仍然可以使用本地配置的 `admin` 账号和密码登录。
|
||||
|
||||
:::
|
||||
|
||||
## 附录：故障排除
|
||||
|
||||
如果在测试与 OpenLDAP 服务器的连接时遇到问题，请首先仔细检查为 ServiceAccount 输入的凭证以及搜索库配置。你还可以检查 Rancher 日志来查明问题的原因。调试日志可能包含有关错误的更详细信息。详情请参见[如何启用调试日志](../../../../faq/technical-items.md#how-can-i-enable-debug-logging)。
|
||||
+81
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: OpenLDAP 配置参考
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-openldap/openldap-config-reference"/>
|
||||
</head>
|
||||
|
||||
有关配置 OpenLDAP 认证的更多详细信息，请参见[官方文档](https://www.openldap.org/doc/)。
|
||||
|
||||
> 在开始之前，请熟悉[外部认证配置和用户主体](../authentication-config/authentication-config.md#外部认证配置和用户主体)的概念。
|
||||
|
||||
## 背景：OpenLDAP 认证流程
|
||||
|
||||
1. 当用户尝试使用其 LDAP 凭证登录时，Rancher 会使用具有搜索目录和读取用户/组属性权限的 ServiceAccount，创建与 LDAP 服务器的初始绑定。
|
||||
2. 然后，Rancher 使用搜索筛选器根据用户名和配置的属性映射为用户搜索目录。
|
||||
3. 找到用户后，将使用用户的 DN 和提供的密码，通过另一个 LDAP 绑定请求对用户进行身份认证。
|
||||
4. 认证成功后，Rancher 将基于用户对象的成员属性和配置的用户映射属性执行组搜索，来解析组成员。
|
||||
|
||||
## OpenLDAP 服务器配置
|
||||
|
||||
你将需要输入地址，端口和协议来连接到 OpenLDAP 服务器。不安全流量的标准端口为 `389`，TLS 流量的标准端口为 `636`。
|
||||
|
||||
> **使用 TLS？**
|
||||
>
|
||||
> 如果 OpenLDAP 服务器使用的证书是自签名的或不是来自认可的证书颁发机构，请确保手头有 PEM 格式的 CA 证书（包含所有中间证书）。你必须在配置期间粘贴此证书，以便 Rancher 能够验证证书链。
|
||||
|
||||
如果你不确定要在用户/组`搜索库`字段中输入什么值，请咨询你的 LDAP 管理员，或参见 Active Directory 身份验证文档中的[使用 ldapsearch 确定搜索库和 Schema](../../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-active-directory.md#附录使用-ldapsearch-确定搜索库和-schema) 章节。
|
||||
|
||||
<figcaption>OpenLDAP 服务器参数</figcaption>
|
||||
|
||||
| 参数 | 描述 |
|
||||
| :---------------------- | :----------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 主机名 | 指定 OpenLDAP 服务器的主机名或 IP 地址。 |
|
||||
| 端口 | 指定 OpenLDAP 服务器监听连接的端口。未加密的 LDAP 通常使用 389 的标准端口，而 LDAPS 使用 636 端口。 |
|
||||
| TLS | 选中此框可启用 SSL/TLS 上的 LDAP（通常称为 LDAPS）。如果服务器使用自签名/企业签名的证书，则还需要粘贴 CA 证书。 |
|
||||
| 服务器连接超时 | Rancher 在认为无法访问服务器之前等待的时间（秒）。 |
|
||||
| ServiceAccount 标识名称 | 输入用于绑定，搜索和检索 LDAP 条目的用户的标识名称（DN）。 |
|
||||
| ServiceAccount 密码 | ServiceAccount 的密码。 |
|
||||
| 用户搜索库 | 输入目录树中开始搜索用户对象的节点的标识名称（DN）。所有用户都必须是此基础标识名称的后代。例如，"ou=people,dc=acme,dc=com"。 |
|
||||
| 组搜索库 | 如果组位于`用户搜索库`下配置的节点之外的其他节点下，则需要在此处提供标识名称。否则，将此字段留空。例如："ou=groups,dc=acme,dc=com"。 |
|
||||
|
||||
## 用户/组 Schema 配置
|
||||
|
||||
如果你的 OpenLDAP 目录不同于标准的 OpenLDAP Schema，则必须完成**自定义 Schema** 部分实现匹配。
|
||||
|
||||
请注意，Rancher 使用本节中配置的属性映射来构造搜索筛选器和解析组成员。因此，我们建议你验证此处的配置是否与你在 OpenLDAP 中使用的 Schema 匹配。
|
||||
|
||||
如果你不确定 OpenLDAP 服务器中使用的用户/组 Schema，请咨询你的 LDAP 管理员，或参见 Active Directory 身份验证文档中的[使用 ldapsearch 确定搜索库和 Schema](../../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-active-directory.md#附录使用-ldapsearch-确定搜索库和-schema) 章节。
|
||||
|
||||
### 用户 Schema 配置
|
||||
|
||||
下表详细说明了用户 Schema 配置的参数。
|
||||
|
||||
<figcaption>用户 Schema 配置参数</figcaption>
|
||||
|
||||
| 参数 | 描述 |
|
||||
| :---------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Object Class | 域中用于用户对象的对象类别名称。如果定义了此参数，则仅指定对象类别的名称 - *请勿*将其放在 LDAP 包装器中，例如 `&(objectClass=xxxx)`。 |
|
||||
| Username Attribute | 用户属性的值适合作为显示名称。 |
|
||||
| Login Attribute | 登录属性的值与用户登录 Rancher 时输入的凭证的用户名部分匹配。通常是 `uid`。 |
|
||||
| User Member Attribute | 包含用户所属组的标识名称的用户属性。通常是 `memberOf` 或 `isMemberOf`。 |
|
||||
| Search Attribute | 当用户输入文本以在用户界面中添加用户或组时，Rancher 会查询 LDAP 服务器，并尝试根据此设置中提供的属性匹配用户。可以通过使用管道（“\|”）符号分隔属性来指定多个属性。 |
|
||||
| User Enabled Attribute | 如果 OpenLDAP 服务器的 Schema 支持使用用户属性的值来评估账号是禁用还是关闭，请输入该属性的名称。默认的 OpenLDAP Schema 不支持此功能，因此此字段通常留空。 |
|
||||
| Disabled Status Bitmask | 禁用/锁定的用户账号的值。如果 `User Enabled Attribute` 是空的，则忽略此参数。 |
|
||||
|
||||
### 组 Schema 配置
|
||||
|
||||
下表详细说明了组 Schema 配置的参数。
|
||||
|
||||
<figcaption>组 Schema 配置参数</figcaption>
|
||||
|
||||
| 参数 | 描述 |
|
||||
| :----------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Object Class | 域中用于组条目的对象类别名称。如果定义了此参数，则仅指定对象类别的名称 - *请勿*将其放在 LDAP 包装器中，例如 `&(objectClass=xxxx)`。 |
|
||||
| Name Attribute | 名称属性的值适合作为显示名称。 |
|
||||
| Group Member User Attribute | **用户属性**的名称。它的格式与 `Group Member Mapping Attribute` 中的组成员匹配。 |
|
||||
| Group Member Mapping Attribute | 包含组成员的组属性的名称。 |
|
||||
| Search Attribute | 在 UI 中将组添加到集群或项目时，用于构造搜索筛选器的属性。请参见用户 Schema 的 `Search Attribute`。 |
|
||||
| Group DN Attribute | 组属性的名称，其格式与用户的组成员属性中的值匹配。参见 `User Member Attribute`。 |
|
||||
| Nested Group Membership | 此设置定义 Rancher 是否应解析嵌套组成员身份。仅当你的组织使用这些嵌套成员身份时才使用（即你有包含其他组作为成员的组）。如果你使用 Shibboleth，此选项会被禁用。 |
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: Shibboleth 和 OpenLDAP 的组权限
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-shibboleth-saml/about-group-permissions"/>
|
||||
</head>
|
||||
|
||||
由于 Shibboleth 是 SAML 提供者，因此它不支持搜索用户组的功能。虽然 Shibboleth 集成可以验证用户凭证，但是如果没有其他配置，Shibboleth 不能在 Rancher 中给用户组分配权限。
|
||||
|
||||
你可以通过配置 OpenLDAP 来解决这个问题。如果让 Shibboleth 使用 OpenLDAP 后端，你将能够在 Rancher 中搜索组，并从 Rancher UI 将集群、项目或命名空间等资源分配给用户组。
|
||||
|
||||
### 名词解释
|
||||
|
||||
- **Shibboleth**：用于计算机网络和互联网的单点登录系统。它允许用户仅使用一种身份登录到各种系统。它验证用户凭证，但不单独处理组成员身份。
|
||||
- **SAML**：安全声明标记语言（Security Assertion Markup Language），用于在身份提供程序和服务提供商之间交换认证和授权数据的开放标准。
|
||||
- **OpenLDAP**：轻型目录访问协议（LDAP）的免费开源实现。它用于管理组织的计算机和用户。OpenLDAP 对 Rancher 用户很有用，因为它支持组。只要组已存在于身份提供程序中，你就可以在 Rancher 中为组分配权限，从而让组访问资源（例如集群，项目或命名空间）。
|
||||
- **IdP 或 IDP**：身份提供程序。OpenLDAP 是身份提供程序的一个例子。
|
||||
|
||||
### 将 OpenLDAP 组权限添加到 Rancher 资源
|
||||
|
||||
下图说明了 OpenLDAP 组的成员如何访问 Rancher 中该组有权访问的资源。
|
||||
|
||||
例如，集群所有者可以将 OpenLDAP 组添加到集群，从而让组有权查看大多数集群级别的资源并创建新项目。然后，OpenLDAP 组成员在登录 Rancher 后就可以访问集群。
|
||||
|
||||
在这种情况下，OpenLDAP 允许集群所有者在分配权限时搜索组。如果没有 OpenLDAP，将不支持搜索组的功能。
|
||||
|
||||
当 OpenLDAP 组的成员登录到 Rancher 时，用户将被重定向到 Shibboleth 并在那里输入用户名和密码。
|
||||
|
||||
Shibboleth 会验证用户的凭证，并从 OpenLDAP 检索用户属性，其中包括用户所在的组信息。然后 Shibboleth 将向 Rancher 发送一个包含用户属性的 SAML 断言。Rancher 会使用组数据，以便用户可以访问他所在的组有权访问的所有资源。
|
||||
|
||||
|
||||
+104
@@ -0,0 +1,104 @@
|
||||
---
|
||||
title: 配置 Shibboleth (SAML)
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-shibboleth-saml"/>
|
||||
</head>
|
||||
|
||||
如果你的组织使用 Shibboleth Identity Provider (IdP) 进行用户身份认证，你可以通过配置 Rancher 来允许用户使用 Shibboleth 凭证登录。
|
||||
|
||||
在此配置中，当 Rancher 用户登录时，他们将被重定向到 Shibboleth IdP 来输入凭证。认证结束后，他们将被重定向回 Rancher UI。
|
||||
|
||||
如果你将 OpenLDAP 配置为 Shibboleth 的后端，SAML 断言会返回到 Rancher，其中包括用于引用组的用户属性。然后，通过认证的用户将能够访问其所在的组有权访问的 Rancher 资源。
|
||||
|
||||
> 本节假定你已了解 Rancher、Shibboleth 和 OpenLDAP 是如何协同工作的。有关工作原理的详细说明，请参见[本页](about-group-permissions.md)
|
||||
|
||||
# 在 Rancher 中设置 Shibboleth
|
||||
|
||||
### Shibboleth 先决条件
|
||||
|
||||
> - 你必须配置了 Shibboleth IdP 服务器。
|
||||
> - 以下是 Rancher Service Provider 配置所需的 URL：
|
||||
> 元数据 URL：`https://<rancher-server>/v1-saml/shibboleth/saml/metadata`
|
||||
> 断言使用者服务 (ACS) URL：`https://<rancher-server>/v1-saml/shibboleth/saml/acs`
|
||||
> - 从 IdP 服务器导出 `metadata.xml` 文件。详情请参见 [Shibboleth 文档](https://wiki.shibboleth.net/confluence/display/SP3/Home)。
|
||||
|
||||
### 在 Rancher 中配置 Shibboleth
|
||||
|
||||
如果你的组织使用 Shibboleth 进行用户身份认证，你可以通过配置 Rancher 来允许你的用户使用 IdP 凭证登录。
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **Shibboleth**。
|
||||
1. 填写**配置 Shibboleth 账号**表单。Shibboleth IdP 允许你指定要使用的数据存储。你可以添加数据库或使用现有的 ldap 服务器。例如，如果你选择 Active Directory (AD) 服务器，下面的示例将描述如何将 AD 属性映射到 Rancher 中的字段：
|
||||
|
||||
1. **显示名称字段**：包含用户显示名称的 AD 属性（例如：`displayName`）。
|
||||
|
||||
1. **用户名字段**：包含用户名/给定名称的 AD 属性（例如：`givenName`）。
|
||||
|
||||
1. **UID 字段**：每个用户唯一的 AD 属性（例如：`sAMAccountName`、`distinguishedName`）。
|
||||
|
||||
1. **用户组字段**: 创建用于管理组成员关系的条目（例如：`memberOf`）。
|
||||
|
||||
1. **Rancher API 主机**：你的 Rancher Server 的 URL。
|
||||
|
||||
1. **私钥**和**证书**：密钥/证书对，用于在 Rancher 和你的 IdP 之间创建一个安全外壳（SSH）。
|
||||
|
||||
你可以使用 openssl 命令进行创建。例如：
|
||||
|
||||
```
|
||||
openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
|
||||
```
|
||||
|
||||
1. **IDP 元数据**：从 IdP 服务器导出的 `metadata.xml` 文件。
|
||||
|
||||
1. 完成**配置 Shibboleth 账号**表单后，单击**启用**。
|
||||
|
||||
Rancher 会将你重定向到 IdP 登录页面。输入使用 Shibboleth IdP 的用户凭证，来验证你的 Rancher Shibboleth 配置。
|
||||
|
||||
:::note
|
||||
|
||||
你可能需要禁用弹出窗口阻止程序才能看到 IdP 登录页面。
|
||||
|
||||
:::
|
||||
|
||||
**结果**：已将 Rancher 配置为使用 Shibboleth。你的用户现在可以使用 Shibboleth 登录名登录 Rancher。
|
||||
|
||||
### SAML 提供商注意事项
|
||||
|
||||
SAML 协议不支持用户或用户组的搜索或查找。因此，如果你没有为 Shibboleth 配置 OpenLDAP，则请留意以下警告。
|
||||
|
||||
- 在 Rancher 中为用户或组分配权限时，不会对用户或组进行验证。
|
||||
- 添加用户时，必须正确输入准确的用户 ID（即 UID 字段）。在你输入用户 ID 时，将不会搜索可能匹配的其他用户 ID。
|
||||
- 添加组时，必须从文本框旁边的下拉列表中选择组。Rancher 假定来自文本框的任何输入都是用户。
|
||||
- 用户组下拉列表仅显示你所属的用户组。如果你不是某个组的成员，你将无法添加该组。
|
||||
|
||||
要在 Rancher 中分配权限时启用搜索组，你需要为 SAML 身份认证服务配置支持组的后端（例如 OpenLDAP）。
|
||||
|
||||
# 在 Rancher 中设置 OpenLDAP
|
||||
|
||||
如果你将 OpenLDAP 配置为 Shibboleth 的后端，SAML 断言会返回到 Rancher，其中包括用于引用组的用户属性。然后，通过认证的用户将能够访问其所在的组有权访问的 Rancher 资源。
|
||||
|
||||
### OpenLDAP 先决条件
|
||||
|
||||
必须为 Rancher 配置 LDAP 绑定账号（即 ServiceAccount），来搜索和检索应该具有访问权限的用户和组的 LDAP 条目。建议不要使用管理员账号或个人账号，而应在 OpenLDAP 中创建一个专用账号，该账号对配置的搜索库下的用户和组需要具有只读权限（参见下文）。
|
||||
|
||||
> **使用 TLS？**
|
||||
>
|
||||
> 如果 OpenLDAP 服务器使用的证书是自签名的或不是来自认可的证书颁发机构，请确保手头有 PEM 格式的 CA 证书（包含所有中间证书）。你必须在配置期间粘贴此证书，以便 Rancher 能够验证证书链。
|
||||
|
||||
### 在 Rancher 中配置 OpenLDAP
|
||||
|
||||
配置 OpenLDAP 服务器，组和用户的设置。有关填写每个字段的帮助，请参见[配置参考](../configure-openldap/openldap-config-reference.md)。请注意，嵌套组成员资格不适用于 Shibboleth。
|
||||
|
||||
> 在开始之前，请熟悉[外部认证配置和用户主体](../authentication-config/authentication-config.md#外部认证配置和用户主体)的概念。
|
||||
|
||||
1. 使用初始的本地 `admin` 账号登录到 Rancher UI。
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏，单击**认证**。
|
||||
1. 单击 **OpenLDAP**。将显示**配置 OpenLDAP 服务器**表单。
|
||||
|
||||
## 故障排除
|
||||
|
||||
如果在测试与 OpenLDAP 服务器的连接时遇到问题，请首先仔细检查为 ServiceAccount 输入的凭证以及搜索库配置。你还可以检查 Rancher 日志来查明问题的原因。调试日志可能包含有关错误的更详细信息。详情请参见[如何启用调试日志](../../../../faq/technical-items.md#how-can-i-enable-debug-logging)。
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: Pod 安全策略
|
||||
---
|
||||
|
||||
:::caution
|
||||
Pod 安全策略仅在 Kubernetes v1.24 之前可用。[Pod 安全标准](pod-security-standards.md) 是内置的替代方案。
|
||||
:::
|
||||
|
||||
[Pod 安全策略（PSP）](https://kubernetes.io/docs/concepts/security/pod-security-policy/)是用来控制安全敏感相关 Pod 规范（例如 root 特权）的对象。
|
||||
|
||||
如果某个 Pod 不满足 PSP 指定的条件，Kubernetes 将不允许它启动，Rancher 中将显示错误消息 `Pod <NAME> is forbidden: unable to validate...`。
|
||||
|
||||
|
||||
## PSP 工作原理
|
||||
|
||||
你可以在集群或项目级别分配 PSP。
|
||||
|
||||
PSP 通过继承的方式工作：
|
||||
|
||||
- 默认情况下，分配给集群的 PSP 由其项目以及添加到这些项目的任何命名空间继承。
|
||||
- **例外**：无论 PSP 是分配给集群还是项目，未分配给项目的命名空间不会继承 PSP。因为这些命名空间没有 PSP，所以这些命名空间的工作负载 deployment 将失败，这是 Kubernetes 的默认行为。
|
||||
- 你可以通过将不同的 PSP 直接分配给项目来覆盖默认 PSP。
|
||||
|
||||
在分配 PSP 之前已经在集群或项目中运行的任何工作负载如果符合 PSP，则不会被检查。你需要克隆或升级工作负载以查看它们是否通过 PSP。
|
||||
|
||||
在 [Kubernetes 文档](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)中阅读有关 Pod 安全策略的更多信息。
|
||||
|
||||
## 默认 PSP
|
||||
|
||||
Rancher 内置了三个默认 Pod 安全策略 (PSP)，分别是 `restricted-noroot`（受限 noroot），`restricted`（受限）和 `unrestricted`（不受限）策略。
|
||||
|
||||
### 受限-NoRoot
|
||||
|
||||
此策略基于 Kubernetes [示例受限策略](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml)。它极大地限制了可以将哪些类型的 Pod 部署到集群或项目中。这项策略：
|
||||
|
||||
- 阻止 Pod 以特权用户身份运行，并防止特权升级。
|
||||
- 验证服务器所需的安全机制是否到位，例如限制哪些卷只能挂载到核心卷类型，并防止添加 root 补充组。
|
||||
|
||||
### 受限
|
||||
|
||||
该策略是宽松版的 `restricted-noroot` 策略，除了允许以特权用户身份运行容器外，几乎所有限制都到位。
|
||||
|
||||
### 不受限
|
||||
|
||||
该策略等效于在禁用 PSP 控制器的情况下运行 Kubernetes。对于可以将哪些 Pod 部署到集群或项目中，它没有任何限制。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
禁用 PSP 时，默认 PSP **不会**自动从集群中删除。如果不再需要它们，你必须手动删除它们。
|
||||
|
||||
:::
|
||||
|
||||
## 创建 PSP
|
||||
|
||||
使用 Rancher，你可以使用我们的 GUI 创建 Pod 安全策略，而不是创建 YAML 文件。
|
||||
|
||||
### 要求
|
||||
|
||||
Rancher 只能为[使用 RKE 启动的集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)分配 PSP。
|
||||
|
||||
你必须先在集群级别启用 PSP，然后才能将它们分配给项目。这可以通过[编辑集群](../../../pages-for-subheaders/cluster-configuration.md)来配置。
|
||||
|
||||
最好的做法是在集群级别设置 PSP。
|
||||
|
||||
我们建议在集群和项目创建期间添加 PSP，而不是将其添加到现有的项目或集群中。
|
||||
|
||||
### 在 Rancher UI 中创建 PSP
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在左侧导航栏中，单击 **Pod 安全策略**。
|
||||
1. 单击**添加策略**。
|
||||
1. 为策略命名。
|
||||
1. 填写表格的每个部分。请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)，了解每个策略的作用。
|
||||
1. 单击**创建**。
|
||||
|
||||
## 配置
|
||||
|
||||
关于 PSP 的 Kubernetes 文档，请参阅[这里](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)。
|
||||
+192
File diff suppressed because one or more lines are too long
+57
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: 配置全局默认私有镜像仓库
|
||||
---
|
||||
|
||||
:::note
|
||||
本页介绍了安装 Rancher 后如何从 Rancher UI 配置全局默认私有镜像仓库。
|
||||
|
||||
有关如何在 Rancher 安装期间设置私有镜像仓库的说明，请参阅[离线安装指南](../../../pages-for-subheaders/air-gapped-helm-cli-install.md)。
|
||||
|
||||
:::
|
||||
|
||||
私有镜像仓库是集群中私有、一致且集中的容器镜像源。你可以使用私有容器镜像仓库，在组织内共享自定义基础镜像。
|
||||
|
||||
在 Rancher 中设置私有镜像仓库主要有两种方式：
|
||||
|
||||
* 通过全局视图中的 **Settings** 选项卡设置全局默认镜像仓库。
|
||||
* 在集群级别设置下的高级选项中设置私有镜像仓库。
|
||||
|
||||
全局默认镜像仓库适用于离线环境，可用于不需要凭证的镜像仓库。而集群级私有镜像仓库用于需要凭证的私有镜像仓库。
|
||||
|
||||
## 将不需要凭证的私有镜像仓库设置为默认镜像仓库
|
||||
|
||||
1. 登录 Rancher 并配置默认管理员密码。
|
||||
1. 选择 **☰ > 全局设置**。
|
||||
1. 转到 `system-default-registry` 并选择 **⋮ > 编辑设置**。
|
||||
1. 输入你镜像仓库的主机名和端口（例如 `registry.yourdomain.com:port`）。不要在文本前加上 `http://` 或 `https://`。
|
||||
|
||||
**结果**：Rancher 会从你的私有镜像仓库中拉取系统镜像。
|
||||
|
||||
### 带 RKE2 下游集群的命名空间私有镜像仓库
|
||||
|
||||
默认情况下，大多数私有镜像仓库应该能与 RKE2 下游集群一起工作。
|
||||
|
||||
但是，如果你尝试设置 URL 格式为 `website/subdomain:portnumber` 的命名空间私有镜像仓库，则需要执行额外的步骤：
|
||||
|
||||
1. 选择 **☰ > 集群管理**。
|
||||
1. 在列表中找到 RKE2 集群，然后点击 **⋮ > 编辑配置**。
|
||||
1. 从**集群配置**菜单中，选择**镜像仓库**。
|
||||
1. 在**镜像仓库**中，选择**配置高级 Containerd Mirror 和仓库认证选项**选项。
|
||||
1. 在 **Mirrors** 下的文本字段中，输入**镜像仓库主机名**和 **Mirror 端点**。
|
||||
1. 单击**保存**。
|
||||
1. 根据需要对每个下游 RKE2 集群重复操作。
|
||||
|
||||
## 创建集群时配置使用凭证的私有镜像仓库
|
||||
|
||||
无法为每个 Rancher 配置的集群全局设置具有授权认证的私有镜像仓库。因此，如果你希望 Rancher 配置的集群从使用凭证的私有镜像仓库中拉取镜像，则每次创建新集群时都必须通过高级集群选项传递镜像仓库凭证。
|
||||
|
||||
由于创建集群后无法配置私有镜像仓库，因此你需要在初始集群设置期间执行这些步骤。
|
||||
|
||||
1. 选择 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，单击**创建**。
|
||||
1. 选择集群类型。
|
||||
1. 在**集群配置**中，转到**镜像仓库**选项卡，然后选择**为 Rancher 从私有镜像仓库中拉取镜像**。
|
||||
1. 输入镜像仓库主机名和凭证。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：新集群将从私有镜像仓库中拉取镜像。
|
||||
+236
@@ -0,0 +1,236 @@
|
||||
---
|
||||
title: 集群和项目角色
|
||||
---
|
||||
|
||||
集群和项目角色定义集群或项目内的用户授权。
|
||||
|
||||
要管理这些角色：
|
||||
|
||||
1. 单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**并转到**集群**或**项目或命名空间**选项卡。
|
||||
|
||||
### 成员资格和角色分配
|
||||
|
||||
非管理用户可以访问的项目和集群由 _成员资格_ 决定。成员资格是根据该集群或项目中分配的角色而有权访问特定集群或项目的用户列表。每个集群和项目都包含一个选项卡，具有适当权限的用户可以使用该选项卡来管理成员资格。
|
||||
|
||||
创建集群或项目时，Rancher 会自动将创建者分配为`所有者`。分配了`所有者`角色的用户可以在集群或项目中给其他用户分配角色。
|
||||
|
||||
:::note
|
||||
|
||||
默认情况下，非管理员用户无法访问任何现有项目/集群。具有适当权限的用户（通常是所有者）必须显式分配项目和集群成员资格。
|
||||
|
||||
:::
|
||||
|
||||
### 集群角色
|
||||
|
||||
_集群角色_ 是你可以分配给用户的角色，以授予他们对集群的访问权限。集群的两个主要角色分别是`所有者`和`成员`。
|
||||
|
||||
- **集群所有者：**
|
||||
|
||||
可以完全控制集群及其中的所有资源。
|
||||
|
||||
- **集群成员：**
|
||||
|
||||
可以查看大多数集群级别的资源并创建新项目。
|
||||
|
||||
#### 自定义集群角色
|
||||
|
||||
Rancher 支持将 _自定义集群角色_ 分配给普通用户，而不是典型的`所有者`或`成员`角色。这些角色可以是内置的自定义集群角色，也可以是 Rancher 管理员定义的角色。这些角色便于为集群内的普通用户定义更受限或特定的访问权限。有关内置自定义集群角色的列表，请参阅下表。
|
||||
|
||||
#### 集群角色参考
|
||||
|
||||
下表列出了可用的内置自定义集群角色，以及默认的集群级别角色`集群所有者`和`集群成员`是否包含该权限：
|
||||
|
||||
| 内置集群角色 | 所有者 | 成员<a id="clus-roles"></a> |
|
||||
| ---------------------------------- | ------------- | --------------------------------- |
|
||||
| 创建项目 | ✓ | ✓ |
|
||||
| 管理集群备份 | ✓ | |
|
||||
| 管理集群应用商店 | ✓ | |
|
||||
| 管理集群成员 | ✓ | |
|
||||
| 管理节点[（见下表）](#管理节点权限) | ✓ | |
|
||||
| 管理存储 | ✓ | |
|
||||
| 查看所有项目 | ✓ | |
|
||||
| 查看集群应用商店 | ✓ | ✓ |
|
||||
| 查看集群成员 | ✓ | ✓ |
|
||||
| 查看节点 | ✓ | ✓ |
|
||||
|
||||
#### 管理节点权限
|
||||
|
||||
下表列出了 RKE 和 RKE2 中`管理节点`角色可用的权限：
|
||||
|
||||
| 管理节点权限 | RKE | RKE2 |
|
||||
|-----------------------------|-------- |--------- |
|
||||
| SSH 访问 | ✓ | ✓ |
|
||||
| 删除节点 | ✓ | ✓ |
|
||||
| 集群的垂直扩缩容 | ✓ | * |
|
||||
\***在 RKE2 中，你必须拥有编辑集群的权限才能对集群进行垂直扩缩容。**
|
||||
<br />
|
||||
|
||||
如果需要了解各个集群角色如何访问 Kubernetes 资源，在 Rancher UI 中找到这些角色：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**。
|
||||
1. 单击**集群**选项卡。
|
||||
1. 单击角色的名称。表格会显示角色授权的所有操作和资源。
|
||||
|
||||
:::note
|
||||
|
||||
在查看 Rancher 创建的默认角色关联的资源时，如果在一行上有多个 Kubernetes API 资源，则该资源将带有 `(Custom)` 标识。这不代表这个资源是自定义资源，而只是表明多个 Kubernetes API 资源作为一个资源。
|
||||
|
||||
:::
|
||||
|
||||
### 为集群成员提供自定义集群角色
|
||||
|
||||
在管理员[设置自定义集群角色后](custom-roles.md)，集群所有者和管理员可以将这些角色分配给集群成员。
|
||||
|
||||
要将自定义角色分配给新的集群成员，你可以使用 Rancher UI。要修改现有成员的权限，你需要使用 Rancher API 视图。
|
||||
|
||||
要将角色分配给新的集群成员：
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher 版本低于 v2.6.4">
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到要将角色分配给成员的集群，然后单击 **Explore**。
|
||||
1. 单击**集群成员**。
|
||||
1. 单击**添加**。
|
||||
1. 在**集群权限**中，选择要分配给成员的自定义集群角色。
|
||||
1. 单击**创建**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher v2.6.4+">
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到要将角色分配给成员的集群，然后单击 **Explore**。
|
||||
1. 点击**集群 > 集群成员**。
|
||||
1. 单击**添加**。
|
||||
1. 在**集群权限**中，选择要分配给成员的自定义集群角色。
|
||||
1. 单击**创建**。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**结果**：成员具有所分配的角色。
|
||||
|
||||
要将自定义角色分配给现有集群成员：
|
||||
|
||||
1. 单击 **☰ > 用户 & 认证**。
|
||||
1. 找到要分配角色的成员。单击 **⋮ > 编辑配置**。
|
||||
1. 如果你添加了自定义角色，它们将显示在**自定义**中。选择要分配给成员的角色。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：成员具有所分配的角色。
|
||||
|
||||
### 项目角色
|
||||
|
||||
_项目角色_ 是用于授予用户访问项目权限的角色。主要的项目角色分别是`所有者`、`成员`和`只读`。
|
||||
|
||||
- **项目所有者：**
|
||||
|
||||
可以完全控制项目及其中的所有资源。
|
||||
|
||||
- **项目成员：**
|
||||
|
||||
可以管理项目范围的资源，如命名空间和工作负载，但不能管理其他项目成员。
|
||||
|
||||
:::note
|
||||
|
||||
默认情况下，Rancher 的`项目成员`角色继承自 `Kubernetes-edit` 角色，而`项目所有者`角色继承自 `Kubernetes-admin` 角色。因此，`项目成员`和`项目所有者`角色都能管理命名空间，包括创建和删除命名空间。
|
||||
|
||||
:::
|
||||
|
||||
- **只读：**
|
||||
|
||||
可以查看项目中的所有内容，但不能创建、更新或删除任何内容。
|
||||
|
||||
:::danger
|
||||
|
||||
如果用户分配到了项目的`所有者`或`成员`角色，用户会自动继承`命名空间创建`角色。然而，这个角色是 [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole)，这表示角色的范围会延展到集群中的所有项目。因此，对于显式分配到了项目`所有者`或`成员`角色的用户来说，即使只有`只读`角色，这些用户也可以在分配给他们的其他项目中创建命名空间。
|
||||
|
||||
:::
|
||||
|
||||
#### 自定义项目角色
|
||||
|
||||
Rancher 支持将 _自定义项目角色_ 分配给普通用户，而不是典型的`所有者`、`成员`或`只读`角色。这些角色可以是内置的自定义项目角色，也可以是 Rancher 管理员定义的角色。这些角色便于为项目内的普通用户定义更受限或特定的访问权限。有关内置自定义项目角色的列表，请参阅下表。
|
||||
|
||||
#### 项目角色参考
|
||||
|
||||
下表列出了 Rancher 中可用的内置自定义项目角色，以及这些角色是否由`所有者`,`成员`或`只读`角色授予的：
|
||||
|
||||
| 内置项目角色 | 所有者 | 成员<a id="proj-roles"></a> | 只读 |
|
||||
| ---------------------------------- | ------------- | ----------------------------- | ------------- |
|
||||
| 管理项目成员 | ✓ | | |
|
||||
| 创建命名空间 | ✓ | ✓ | |
|
||||
| 管理配置映射 | ✓ | ✓ | |
|
||||
| 管理 Ingress | ✓ | ✓ | |
|
||||
| 管理项目应用商店 | ✓ | | |
|
||||
| 管理密文 | ✓ | ✓ | |
|
||||
| 管理 ServiceAccount | ✓ | ✓ | |
|
||||
| 管理服务 | ✓ | ✓ | |
|
||||
| 管理卷 | ✓ | ✓ | |
|
||||
| 管理工作负载 | ✓ | ✓ | |
|
||||
| 查看密文 | ✓ | ✓ | |
|
||||
| 查看配置图 | ✓ | ✓ | ✓ |
|
||||
| 查看 Ingress | ✓ | ✓ | ✓ |
|
||||
| 查看项目成员 | ✓ | ✓ | ✓ |
|
||||
| 查看项目应用商店 | ✓ | ✓ | ✓ |
|
||||
| 查看 ServiceAccount | ✓ | ✓ | ✓ |
|
||||
| 查看服务 | ✓ | ✓ | ✓ |
|
||||
| 查看卷 | ✓ | ✓ | ✓ |
|
||||
| 查看工作负载 | ✓ | ✓ | ✓ |
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
- 上面列出的每个项目角色（包括`所有者`、`成员`和`只读`）均由多个规则组成，这些规则授予对各种资源的访问权限。你可以在**全局 > 安全 > 角色**页面上查看角色及其规则。
|
||||
- 在查看 Rancher 创建的默认角色关联的资源时，如果在一行上有多个 Kubernetes API 资源，则该资源将带有 `(Custom)` 标识。这不代表这个资源是自定义资源，而只是表明多个 Kubernetes API 资源作为一个资源。
|
||||
- `管理项目成员`角色允许项目所有者管理项目的所有成员，**并**授予这些成员任何项目范围的角色（不论他们是否有权访问项目资源）。单独分配此角色时要小心。
|
||||
|
||||
:::
|
||||
|
||||
### 定义自定义角色
|
||||
如前所述，你可以定义自定义角色，并将这些角色用在集群或项目中。上下文字段定义了角色是否显示在集群成员页面、项目成员页面或同时显示在这两个页面。
|
||||
|
||||
定义自定义角色时，你可以授予对特定资源的访问权限，或指定自定义角色应继承的角色。自定义角色可以由特定授权和继承角色组成。所有授权都是累加的。换言之，如果你为特定资源定义更受限的授权，自定义角色继承的角色中定义的更广泛的授权**不会**被覆盖。
|
||||
|
||||
### 默认集群和项目角色
|
||||
|
||||
默认情况下，在普通用户创建新集群或项目时，他们会自动分配到所有者的角色，即[集群所有者](#集群角色)或[项目所有者](#项目角色)。但是，在某些组织中，这些角色可能会被认为有过多的管理访问权限。在这种情况下，你可以将默认角色更改为更具限制性的角色，例如一组单独的角色或一个自定义角色。
|
||||
|
||||
更改默认集群/项目角色有以下两种方法：
|
||||
|
||||
- **分配自定义角色**：为你的[集群](#自定义集群角色)或[项目](#自定义项目角色)创建一个[自定义角色](custom-roles.md)，然后将自定义角色设置为默认。
|
||||
|
||||
- **分配单独的角色**：将多个[集群](#集群角色参考)/[项目](#项目角色参考)角色配置为默认角色，并分配给创建的用户。
|
||||
|
||||
例如，你可以选择混合使用多个角色（例如`管理节点`和`管理存储`），而不是使用继承的角色（例如`集群所有者`）。
|
||||
|
||||
:::note
|
||||
|
||||
- 虽然你可以[锁定](locked-roles.md)一个默认角色，但系统仍会将这个角色分配给创建集群/项目的用户。
|
||||
- 只有创建集群/项目的用户才能继承他们的角色。对于之后添加为集群/项目成员的用户，你必须显式分配角色。
|
||||
|
||||
:::
|
||||
|
||||
### 为集群和项目创建者配置默认角色
|
||||
|
||||
你可以更改为创建集群或项目的用户自动创建的角色：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**。
|
||||
1. 单击**集群**或**项目或命名空间**选项卡。
|
||||
1. 找到你要用作默认角色的自定义或单个角色。然后通过选择 **⋮ > 编辑配置**来编辑角色。
|
||||
1. 在**集群创建者的默认角色**或**项目创建者的默认角色**中，将角色启用为默认。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：默认角色已根据你的更改配置。分配给集群/项目创建者的角色会在**集群创建者的默认角色/项目创建者的默认角色**列中勾选。
|
||||
|
||||
如果要删除默认角色，请编辑权限，并在默认角色选项中选择**否**。
|
||||
|
||||
### 撤销集群成员资格
|
||||
|
||||
如果你撤销一个普通用户的集群成员资格，而且该用户已显式分配集群的集群 _和_ 项目的成员资格，该普通用户将[失去集群角色](#集群角色)但[保留项目角色](#项目角色)。换句话说，即使你已经撤销了用户访问集群和其中的节点的权限，但该普通用户仍然可以：
|
||||
|
||||
- 访问他们拥有成员资格的项目。
|
||||
- 行使分配给他们的任何[单个项目角色](#项目角色参考)。
|
||||
|
||||
如果你想完全撤销用户在集群中的访问权限，请同时撤销他们的集群和项目成员资格。
|
||||
+120
@@ -0,0 +1,120 @@
|
||||
---
|
||||
title: 自定义角色
|
||||
---
|
||||
|
||||
在 Rancher 中，_角色_ 决定了用户可以在集群或项目中执行哪些操作。
|
||||
|
||||
请注意，_角色_ 与 _权限_ 不同，权限决定的是你可以访问哪些集群和项目。
|
||||
|
||||
:::danger
|
||||
|
||||
自定义角色可以启用权限提升。有关详细信息，请参阅[本节](#权限提升)。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
## 先决条件
|
||||
|
||||
要完成此页面上的任务，需要以下权限之一：
|
||||
|
||||
- [管理员全局权限](global-permissions.md)。
|
||||
- 分配了[管理角色](global-permissions.md)的[自定义全局权限](global-permissions.md#自定义全局权限)。
|
||||
|
||||
## 创建自定义角色
|
||||
|
||||
虽然 Rancher 提供一组开箱即用的默认用户角色，但你还可以创建默认的自定义角色，从而在 Rancher 中为用户提供更精细的权限。
|
||||
|
||||
添加自定义角色的步骤因 Rancher 的版本而异。
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**。
|
||||
1. 选择一个选项卡来确定要添加的角色的范围。这些选项卡是：
|
||||
|
||||
- **全局**：仅在允许成员管理全局范围的资源时，可以分配该角色。
|
||||
- **集群**：仅在向集群添加/管理成员时，可以分配该角色。
|
||||
- **项目或命名空间**：仅在向项目或命名空间添加/管理成员时，可以分配该角色。
|
||||
|
||||
1. 根据所需要的范围，单击**创建全局角色**、**创建集群角色**或**创建项目或命名空间的角色**。
|
||||
1. 输入角色的**名称**。
|
||||
1. 可选：选择**集群创建者的默认角色/项目创建者的默认角色**选项，以将该角色分配给集群/项目创建者。使用此功能，你可以扩展或限制集群/项目创建者的默认角色。
|
||||
|
||||
> 开箱即用的**集群创建者的默认角色**和**项目创建者的默认角色**分别是`集群所有者`和`项目所有者`。
|
||||
|
||||
1. 使用**授权资源**选项将各个 [Kubernetes API 端点](https://kubernetes.io/docs/reference/)分配给角色。
|
||||
|
||||
> 在查看 Rancher 创建的默认角色关联的资源时，如果在一行上有多个 Kubernetes API 资源，则该资源将带有 `(Custom)` 标识。这不代表这个资源是自定义资源，而只是表明多个 Kubernetes API 资源作为一个资源。
|
||||
|
||||
> **资源**文本字段可以用来搜索预定义的 Kubernetes API 资源，或者为授权输入自定义资源名称。在此字段中输入资源名称后，必须从下拉列表中选择预定义或`（自定义）`资源。
|
||||
|
||||
你还可以选择每个分配的端点可用的 cURL 方法（`Create`、`Delete`、`Get` 等）。
|
||||
|
||||
1. 使用 **Inherit from** 选项将各个 Rancher 角色分配给你的自定义角色。请注意，如果自定义角色从父角色继承，你需要先删除子角色才能删除父角色。
|
||||
|
||||
1. 单击**创建**。
|
||||
|
||||
## 创建从另一个角色继承的自定义角色
|
||||
|
||||
如果你有一组需要在 Rancher 中具有相同访问权限的用户，一种节省时间的方法是创建一个新的自定义角色，而该角色的规则都是从另一个角色（例如管理员角色）复制而来的。这样，你只需要配置现有角色和新角色之间不同的部分。
|
||||
|
||||
然后，你可以将自定义角色分配给用户或组。该角色在用户首次登录 Rancher 时生效。
|
||||
|
||||
要基于现有角色创建自定义角色：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**。
|
||||
1. 单击**集群**或**项目或命名空间**选项卡。根据所需要的范围，单击**创建集群角色**或**创建项目或命名空间的角色**。请注意，只有集群角色和项目/命名空间角色可以从另一个角色继承。
|
||||
1. 输入角色的名称。
|
||||
1. 在 **Inherit From** 选项卡中，选择自定义角色需要从哪个角色继承权限。
|
||||
1. 在**授权资源**选项卡中，选择拥有自定义角色的用户要启用的 Kubernetes 资源操作。
|
||||
|
||||
> **资源**文本字段可以用来搜索预定义的 Kubernetes API 资源，或者为授权输入自定义资源名称。在此字段中输入资源名称后，必须从下拉列表中选择预定义或`（自定义）`资源。
|
||||
1. 可选：将角色设置为默认。
|
||||
1. 单击**创建**。
|
||||
|
||||
## 删除自定义角色
|
||||
|
||||
删除自定义角色时，具有此自定义角色的所有全局角色绑定（Global Role Bindings）都将被删除。
|
||||
|
||||
如果某个用户仅分配了一个自定义全局角色，而且你删除了这个角色，该用户将不能再访问 Rancher。要让用户重新获得访问权限，管理员需要编辑用户并应用新的全局权限。
|
||||
|
||||
自定义角色可以删除，但内置角色不能删除。
|
||||
|
||||
要删除自定义角色：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**。
|
||||
2. 转到要删除的自定义全局角色，然后单击 **⋮ (…) > 删除**。
|
||||
3. 单击**删除**。
|
||||
|
||||
## 为组分配自定义角色
|
||||
|
||||
如果你有一组需要在 Rancher 中具有相同访问权限的用户，一种节省时间的方法是创建一个新的自定义角色。将角色分配给组时，组中的用户在首次登录 Rancher 时就会拥有配置的访问级别。
|
||||
|
||||
组中的用户登录时，他们默认获得内置的**普通用户**全局角色。他们还将获得分配给他们的组的权限。
|
||||
|
||||
如果将用户从外部身份验证系统的组中删除，用户将失去分配给该组的自定义全局角色的权限。但是，用户仍会拥有**普通用户**角色。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
只有在以下情况下，你才能将全局角色分配给组：
|
||||
|
||||
* 你已设置[外部身份验证提供程序](../../../../pages-for-subheaders/authentication-config.md#外部验证与本地验证)。
|
||||
* 外部身份验证提供程序支持[用户组](../../authentication-permissions-and-global-configuration/authentication-config/manage-users-and-groups.md)。
|
||||
* 你已使用身份验证提供程序设置了至少一个用户组。
|
||||
|
||||
:::
|
||||
|
||||
要将自定义角色分配给组，请执行以下步骤：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**组**。
|
||||
1. 转到将分配自定义角色的组，然后单击 **⋮ > 编辑配置**。
|
||||
1. 如果你已创建角色，角色将显示在**自定义**中。选择要分配给组的自定义角色。
|
||||
1. 可选：在**全局权限**或**内置角色**中，选择要分配给该组的其他权限。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：自定义角色将在组内用户登录 Rancher 时生效。
|
||||
|
||||
## 权限提升
|
||||
|
||||
`配置应用商店`这个自定义权限很强大，应谨慎使用。如果管理员将`配置应用商店`权限分配给普通用户，可能会导致权限提升。在这种情况下，用户可以让自己对 Rancher 配置的集群进行管理员访问。因此，拥有此权限的任何用户都应被视为管理员。
|
||||
+251
@@ -0,0 +1,251 @@
|
||||
---
|
||||
title: 全局权限
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions"/>
|
||||
</head>
|
||||
|
||||
_权限_ 是你在为用户选择自定义权限时可以分配的个人访问权限。
|
||||
|
||||
全局权限定义用户在任何特定集群之外的授权。Rancher 提供四种开箱即用的默认全局权限：`Administrator` (管理员)、`Restricted Admin` (受限管理员)、`Standard User` (标准用户) 和 `User-Base` 用户。
|
||||
|
||||
- **管理员**：可以完全控制整个 Rancher 系统和其中的所有集群。
|
||||
|
||||
- **受限管理员**：可以完全控制下游集群，但不能更改本地 Kubernetes 集群。
|
||||
|
||||
- **普通用户**：可以创建新集群并使用它们。普通用户还可以在自己的集群中向其他用户分配集群权限。
|
||||
|
||||
- **User-Base 用户**：只有登录权限。
|
||||
|
||||
你无法更新或删除内置的全局权限。
|
||||
|
||||
## 受限管理员
|
||||
|
||||
Rancher 2.5 创建了一个新的 `restricted-admin` 角色，以防止本地 Rancher Server Kubernetes 集群的权限提升。此角色对 Rancher 管理的所有下游集群具有完全管理员权限，但没有更改本地 Kubernetes 集群的权限。
|
||||
|
||||
`restricted-admin` 可以创建其他具有同样访问权限的 `restricted-admin` 用户。
|
||||
|
||||
Rancher 还增加了一个新设置，来将初始启动的管理员设置为 `restricted-admin` 角色。该设置适用于 Rancher Server 首次启动时创建的第一个用户。如果设置了这个环境变量，则不会创建全局管理员，也就无法通过 Rancher 创建全局管理员。
|
||||
|
||||
要以 `restricted-admin` 作为初始用户来启动 Rancher，你需要使用以下环境变量来启动 Rancher Server：
|
||||
|
||||
```
|
||||
CATTLE_RESTRICTED_DEFAULT_ADMIN=true
|
||||
```
|
||||
|
||||
### `restricted-admin` 的权限列表
|
||||
|
||||
下表列出了 `restricted-admin` 与 `Administrator` 和 `Standard User` 角色相比应具有的权限和操作：
|
||||
|
||||
| 类别 | 操作 | 全局管理员 | 普通用户 | 受限管理员 | 受限管理员的注意事项 |
|
||||
| --------------------- | ------------------------------------ | -------------- | ---------------- | ---------------- | -------------------------------------------------------- |
|
||||
| 本地集群功能 | 管理本地集群（列出、编辑、导入主机） | 是 | 否 | 否 | |
|
||||
| | 创建项目/命名空间 | 是 | 否 | 否 | |
|
||||
| | 添加集群/项目成员 | 是 | 否 | 否 | |
|
||||
| | 全局 DNS | 是 | 否 | 否 | |
|
||||
| | 访问 CRD 和 CR 的管理集群 | 是 | 否 | 是 | |
|
||||
| | 另存为 RKE 模板 | 是 | 否 | 否 | |
|
||||
| 安全 | | | | | |
|
||||
| 启用身份验证 | 配置身份验证 | 是 | 否 | 是 | |
|
||||
| 角色 | 创建/分配 GlobalRoles | 是 | 否（可列出） | 是 | 认证 Webhook 允许为已经存在的权限创建 globalrole |
|
||||
| | 创建/分配 ClusterRoles | 是 | 否（可列出） | 是 | 不在本地集群中 |
|
||||
| | 创建/分配 ProjectRoles | 是 | 否（可列出） | 是 | 不在本地集群中 |
|
||||
| 用户 | 添加用户/编辑/删除/停用用户 | 是 | 否 | 是 | |
|
||||
| 组 | 将全局角色分配给组 | 是 | 否 | 是 | 在 Webhook 允许的范围内 |
|
||||
| | 刷新组 | 是 | 否 | 是 | |
|
||||
| PSP | 管理 PSP 模板 | 是 | 否（可列出） | 是 | 与 PSP 的全局管理员权限相同 |
|
||||
| 工具 | | | | | |
|
||||
| | 管理 RKE 模板 | 是 | 否 | 是 | |
|
||||
| | 管理全局应用商店 | 是 | 否 | 是 | 无法编辑/删除内置系统应用商店。可以管理 Helm 库 |
|
||||
| | 集群驱动 | 是 | 否 | 是 | |
|
||||
| | 主机驱动 | 是 | 否 | 是 | |
|
||||
| | GlobalDNS 提供商 | 是 | 是（自己） | 是 | |
|
||||
| | GlobalDNS 条目 | 是 | 是（自己） | 是 | |
|
||||
| 设置 | | | | | |
|
||||
| | 管理设置 | 是 | 否（可列出） | 否（可列出） | |
|
||||
| 用户 | | | | | |
|
||||
| | 管理 API 密钥 | 是（管理所有） | 是（管理自己的） | 是（管理自己的） | |
|
||||
| | 管理节点模板 | 是 | 是（管理自己的） | 是（管理自己的） | 只能管理自己的节点模板，不能管理其他用户创建的节点模板。 |
|
||||
| | 管理云凭证 | 是 | 是（管理自己的） | 是（管理自己的） | 只能管理自己的云凭证，不能管理其他用户创建的云凭证。 |
|
||||
| 下游集群 | 创建集群 | 是 | 是 | 是 | |
|
||||
| | 编辑集群 | 是 | 是 | 是 | |
|
||||
| | 轮换证书 | 是 | | 是 | |
|
||||
| | 立即创建快照 | 是 | | 是 | |
|
||||
| | 恢复快照 | 是 | | 是 | |
|
||||
| | 另存为 RKE 模板 | 是 | 否 | 是 | |
|
||||
| | 运行 CIS 扫描 | 是 | 是 | 是 | |
|
||||
| | 添加成员 | 是 | 是 | 是 | |
|
||||
| | 创建项目 | 是 | 是 | 是 | |
|
||||
| 自 2.5 起的功能 Chart | | | | | |
|
||||
| | 安装 Fleet | 是 | | 是 | 无法在本地集群中运行 Fleet |
|
||||
| | 部署 EKS 集群 | 是 | 是 | 是 | |
|
||||
| | 部署 GKE 集群 | 是 | 是 | 是 | |
|
||||
| | 部署 AKS 集群 | 是 | 是 | 是 | |
|
||||
|
||||
### 将全局管理员更改为受限管理员
|
||||
|
||||
如果 Rancher 已经有一个全局管理员，则应该将所有全局管理员更改为新的 `restricted-admin`。
|
||||
|
||||
你可以前往**安全 > 用户**，并将所有管理员角色转为受限管理员。
|
||||
|
||||
已登录的用户可以根据需要将自己更改为 `restricted-admin`，但这应该是他们的最后一步操作，否则他们将没有进行该操作的权限。
|
||||
|
||||
## 分配全局权限
|
||||
|
||||
本地用户的全局权限分配与使用外部认证登录 Rancher 的用户不同。
|
||||
|
||||
### 新本地用户的全局权限
|
||||
|
||||
在创建新本地用户时，请在填写**添加用户**表单时为他分配全局权限。
|
||||
|
||||
如果需要查看新用户的默认权限：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**。
|
||||
1. **角色**页面有按范围分组的角色选项卡。每个表都列出了范围内的角色。在**全局**选项卡的**新用户的默认角色**列中，默认授予新用户的权限用复选标记表示。
|
||||
|
||||
你可以[更改默认全局权限来满足你的需要](#配置默认的全局权限)
|
||||
|
||||
### 使用外部认证登录的用户的全局权限
|
||||
|
||||
当用户首次使用外部认证登录 Rancher 时，他们会自动分配到**新用户的默认角色**的全局权限。默认情况下，Rancher 为新用户分配 **Standard User** 权限。
|
||||
|
||||
如果需要查看新用户的默认权限：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**。
|
||||
1. **角色**页面有按范围分组的角色选项卡。每个表都列出了范围内的角色。在每个页面的**新用户的默认角色**列中，默认授予新用户的权限用复选标记表示。
|
||||
|
||||
你可以[更改默认权限来满足你的需要](#配置默认的全局权限)
|
||||
|
||||
你可以按照[步骤](#为单个用户配置全局权限)操作来将权限分配给单个用户。
|
||||
|
||||
如果外部认证服务支持组，你可以[同时为组中的每个成员分配角色](#为组配置全局权限)。
|
||||
|
||||
## 自定义全局权限
|
||||
|
||||
使用自定义权限可以为用户提供 Rancher 中更为受限或特定的访问权限。
|
||||
|
||||
当来自[外部认证](../authentication-config/authentication-config.md)的用户首次登录 Rancher 时，他们会自动分配到一组全局权限（以下简称权限）。默认情况下，用户第一次登录后会被创建为用户，并分配到默认的`用户`权限。标准的`用户`权限允许用户登录和创建集群。
|
||||
|
||||
但是，在某些组织中，这些权限可能会被认为权限过大。你可以为用户分配一组更具限制性的自定义全局权限，而不是为用户分配 `Administrator` 或 `Standard User` 的默认全局权限。
|
||||
|
||||
默认角色（管理员和标准用户）都内置了多个全局权限。系统管理员角色包括所有全局权限，而默认用户角色包括三个全局权限，分别是创建集群、使用应用商店模板和 User Base（登录 Rancher 的最低权限）。换句话说，自定义全局权限是模块化的，因此，如果你要更改默认用户角色权限，你可以选择需要包括在新的默认用户角色中的全局权限子集。
|
||||
|
||||
管理员可以通过多种方式强制执行自定义全局权限：
|
||||
|
||||
- [更改新用户的默认权限](#配置默认的全局权限).
|
||||
- [为单个用户配置全局权限](#为单个用户配置全局权限).
|
||||
- [为组配置全局权限](#为组配置全局权限).
|
||||
|
||||
### 自定义全局权限参考
|
||||
|
||||
下表列出了每个可用的自定义全局权限，以及该权限是否包含在默认全局权限 `Administrator`、`Standard User` 和 `User-Base` 中：
|
||||
|
||||
| 自定义全局权限 | 管理员 | 普通用户 | User-Base |
|
||||
| ---------------------------------- | ------------- | ------------- |-----------|
|
||||
| 创建集群 | ✓ | ✓ | |
|
||||
| 创建 RKE 模板 | ✓ | ✓ | |
|
||||
| 管理身份验证 | ✓ | | |
|
||||
| 管理应用商店 | ✓ | | |
|
||||
| 管理集群驱动 | ✓ | | |
|
||||
| 管理主机驱动 | ✓ | | |
|
||||
| 管理 PodSecurityPolicy 模板 | ✓ | | |
|
||||
| 管理角色 | ✓ | | |
|
||||
| 管理设置 | ✓ | | |
|
||||
| 管理用户 | ✓ | | |
|
||||
| 使用应用商店模板 | ✓ | ✓ | |
|
||||
| User-Base（基本登录访问） | ✓ | ✓ | |
|
||||
|
||||
如果需要查看每个全局权限对应哪些 Kubernetes 资源：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**。
|
||||
1. 如果单击单个角色的名称，表格会显示该角色授权的所有操作和资源。
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
- 上面列出的每个权限都包含多个未在 Rancher UI 中列出的权限。如果需要获取完整权限列表以及组成权限的规则，请通过 `/v3/globalRoles` API 进行访问。
|
||||
- 在查看 Rancher 创建的默认角色关联的资源时，如果在一行上有多个 Kubernetes API 资源，则该资源将带有 `(Custom)` 标识。这不代表这个资源是自定义资源，而只是表明多个 Kubernetes API 资源作为一个资源。
|
||||
|
||||
:::
|
||||
|
||||
### 配置默认全局权限
|
||||
|
||||
如果你想限制新用户的默认权限，你可以删除作为默认角色的`用户`权限，然后分配多个单独的权限作为默认权限。你也可以在一组其他标准权限之上添加管理权限。
|
||||
|
||||
:::note
|
||||
|
||||
默认角色仅分配给从外部认证登录的用户。对于本地用户，在将用户添加到 Rancher 时，必须显式分配全局权限。你可以在添加用户时自定义这些全局权限。
|
||||
|
||||
:::
|
||||
|
||||
要更改在外部用户首次登录时分配给他们的默认全局权限，请执行以下步骤：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**。在**角色**页面上，确保选择了**全局**选项卡。
|
||||
1. 查找要添加或删除的默认权限集。然后，通过选择 **⋮ > 编辑配置**来编辑权限。
|
||||
1. 如果要将权限添加为默认权限，请选择**是：新用户的默认角色**，然后单击**保存**。如果要删除默认权限，请编辑该权限并选择**否**。
|
||||
|
||||
**结果**：默认全局权限已根据你的更改配置。分配给新用户的权限会在**新用户的默认角色**列中显示为复选标记。
|
||||
|
||||
### 为单个用户配置全局权限
|
||||
|
||||
要为单个用户配置权限：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**用户**。
|
||||
1. 找到要更改访问级别的用户，然后单击 **⋮ > 编辑配置**。
|
||||
1. 在**全局权限**和**内置角色**部分中，选中你希望用户拥有的权限的复选框。如果你在**角色**页面创建了角色，这些角色将出现在**自定义**部分，你也可以选择这些角色。
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：用户的全局权限已更新。
|
||||
|
||||
### 为组配置全局权限
|
||||
|
||||
如果你有一组需要在 Rancher 中有相同访问权限的用户，你可以一次性将权限分配给整个组来节省时间。这样，组中的用户在第一次登录 Rancher 时能拥有相应级别的访问权限。
|
||||
|
||||
将自定义全局角色分配给组后，该角色将在组中用户登录 Rancher 时分配给用户。
|
||||
|
||||
对于现有用户，新权限将在用户退出 Rancher 并重新登录时，或当管理员[刷新用户组成员名单](#刷新用户组成员名单)时生效。
|
||||
|
||||
对于新用户，新权限在用户首次登录 Rancher 时生效。除了**新用户的默认角色**全局权限外，来自该组的新用户还将获得自定义全局角色的权限。默认情况下，**新用户的默认角色**权限等同于 **Standard User** 全局角色，但默认权限可以[配置。](#配置默认的全局权限)
|
||||
|
||||
如果从外部认证服务中将用户从组中删除，该用户将失去分配给该组的自定义全局角色的权限。他们将继续拥有分配给他们的其他剩余角色，这通常包括标记为**新用户的默认角色**的角色。Rancher 将在用户登出或管理员[刷新用户组成员名单](#刷新用户组成员名单)时删除与组关联的权限。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
只有在以下情况下，你才能将全局角色分配给组：
|
||||
|
||||
- 你已设置[外部认证](../authentication-config/authentication-config.md#external-vs-local-authentication)
|
||||
- 外部认证服务支持[用户组](../authentication-config/manage-users-and-groups.md)
|
||||
- 你已使用外部认证服务设置了至少一个用户组。
|
||||
|
||||
:::
|
||||
|
||||
要将自定义全局角色分配给组，请执行以下步骤：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**组**。
|
||||
1. 转到你要分配自定义全局角色的组，然后单击 **⋮ > 编辑配置**。
|
||||
1. 在**全局权限**，**自定义**和/或**内置角色**部分中，选择该组应具有的权限。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：自定义全局角色会在组内用户登录 Rancher 时生效。
|
||||
|
||||
### 刷新用户组成员名单
|
||||
|
||||
当管理员更新组的全局权限时，更改将在组成员退出 Rancher 并重新登录后生效。
|
||||
|
||||
如果要让更改立即生效，管理员或集群所有者可以刷新用户组成员名单。
|
||||
|
||||
如果用户已经从外部认证服务中的组中删除，管理员也需要刷新用户组成员名单。在这种情况下，刷新操作会让 Rancher 知道用户已从组中删除。
|
||||
|
||||
要刷新用户组成员名单：
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**用户**。
|
||||
1. 单击**刷新用户组成员名单**。
|
||||
|
||||
**结果**：对组成员权限的所有更改都会生效。
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: 锁定角色
|
||||
---
|
||||
|
||||
你可以将角色设置为`锁定`状态。锁定角色可防止把这些角色分配给用户。
|
||||
|
||||
处于锁定状态的角色具有如下特性：
|
||||
|
||||
- 无法再分配给当下还没有被分配到该角色的用户。
|
||||
- 将用户添加到集群或项目时，不会在**成员角色**下拉列表中列出。
|
||||
- 不会影响在锁定该角色之前，已经分配了该角色的用户。即使后来锁定了该角色，这些用户仍然保留该角色提供的访问权限。
|
||||
|
||||
**示例**：假设你的组织制定了一个内部策略，禁止把创建项目的权限分配给集群用户。这时候你需要执行这个策略。
|
||||
|
||||
因此，在将新用户添加到集群之前，你需要锁定以下角色：`集群所有者`，`集群成员`和`创建项目`。然后，创建一个新的自定义角色，该角色的权限与`集群成员`相同，但没有创建项目的权限。然后，在将用户添加到集群时使用这个新的自定义角色。
|
||||
|
||||
以下用户可以锁定角色：
|
||||
|
||||
- 任何分配了`管理员`全局权限的用户。
|
||||
- 任何分配了带有`管理角色`权限的`自定义用户`。
|
||||
|
||||
|
||||
## 锁定/解锁角色
|
||||
|
||||
如果要防止将角色分配给用户，可以将其设置为`锁定`状态。
|
||||
|
||||
你可以在两种情况下锁定角色：
|
||||
|
||||
- [添加自定义角色](custom-roles.md)时。
|
||||
- 编辑现有角色时（见下文）。
|
||||
|
||||
集群角色和项目/命名空间角色可以锁定，而全局角色不能锁定。
|
||||
|
||||
1. 在左上角，单击 **☰ > 用户 & 认证**。
|
||||
1. 在左侧导航栏中，单击**角色**。
|
||||
1. 转到**集群**选项卡或**项目或命名空间**选项卡。
|
||||
1. 找到要锁定（或解锁）的角色，选择 **⋮ > 编辑配置**。
|
||||
1. 从**锁定**选项中，选择**是** 或**否**。然后点击**保存**。
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: 管理 RBAC
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac"/>
|
||||
</head>
|
||||
|
||||
Rancher 通过 _用户_ 进行授权管理。如[认证](../authentication-config/authentication-config.md)中所述，用户可以是本地用户，也可以是外部用户。
|
||||
|
||||
配置外部认证后，**用户**页面上显示的用户会发生变化。
|
||||
|
||||
- 如果你以本地用户身份登录，则仅显示本地用户。
|
||||
|
||||
- 如果你以外部用户身份登录，则会同时显示外部用户和本地用户。
|
||||
|
||||
## 用户和角色
|
||||
|
||||
一旦用户登录到 Rancher，他们的 _授权_，也就是他们在系统中的访问权限，将由 _全局权限_ 和 _集群和项目角色_ 决定。
|
||||
|
||||
- [全局权限](global-permissions.md):
|
||||
|
||||
定义用户在任何特定集群之外的授权。
|
||||
|
||||
- [集群和项目角色](cluster-and-project-roles.md):
|
||||
|
||||
定义用户在分配了角色的特定集群或项目中的授权。
|
||||
|
||||
全局权限以及集群和项目角色都是基于 [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 实现的。因此，权限和角色的底层实现是由 Kubernetes 完成的。
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
---
|
||||
title: Pod 安全标准 (PSS) 和 Pod 安全准入 (PSA)
|
||||
---
|
||||
|
||||
[Pod 安全标准 (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/) 和 [Pod 安全准入 (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) 为大量工作负载定义了安全限制。
|
||||
它们在 Kubernetes v1.23 中可用并默认打开，并在 Kubernetes v1.25 及更高版本中替换了 [Pod Security Policies (PSP)](https://kubernetes.io/docs/concepts/security/pod-security-policy/)。
|
||||
|
||||
PSS 定义了工作负载的安全级别。PSA 描述了 Pod 安全上下文和相关字段的要求。PSA 参考 PSS 级别来定义安全限制。
|
||||
|
||||
## 升级到 Pod 安全标准 (PSS)
|
||||
|
||||
确保将所有 PSP 都迁移到了另一个工作负载安全机制，包括将你当前的 PSP 映射到 Pod 安全标准，以便使用 [PSA 控制器](https://kubernetes.io/docs/concepts/security/pod-security-admission/)执行。如果 PSA 控制器不能满足企业的所有需求，建议你使用策略引擎，例如 [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)、[Kubewarden](https://www.kubewarden.io/)、[Kyverno](https://kyverno.io/) 或 [NeuVector](https://neuvector.com/)。有关如何迁移 PSP 的更多信息，请参阅你选择的策略引擎的文档。
|
||||
|
||||
:::caution
|
||||
必须在删除 PodSecurityPolicy 对象_之前_添加新的策略执行机制。否则，你可能会为集群内的特权升级攻击创造机会。
|
||||
:::
|
||||
|
||||
### 从 Rancher 维护的应用程序和市场工作负载中删除 PodSecurityPolicies {#remove-psp-rancher-workloads}
|
||||
|
||||
Rancher v2.7.2 提供了 Rancher 维护的 Helm Chart 的新主要版本。v102.x.y 允许你删除与以前的 Chart 版本一起安装的 PSP。这个新版本使用标准化的 `global.cattle.psp.enabled` 开关（默认关闭）替换了非标准的 PSP 开关。
|
||||
|
||||
你必须在_仍使用 Kubernetes v1.24_ 时执行以下步骤：
|
||||
1. 根据需要配置 PSA 控制器。你可以使用 Rancher 的内置 [PSA 配置模板](#psa-config-templates)，或创建自定义模板并将其应用于正在迁移的集群。
|
||||
|
||||
1. 将活动的 PSP 映射到 Pod 安全标准：
|
||||
1. 查看集群中哪些 PSP 仍处于活动状态：
|
||||
:::caution
|
||||
此策略可能会错过当前未运行的工作负载，例如 CronJobs、当前缩放为零的工作负载或尚未推出的工作负载。
|
||||
:::
|
||||
|
||||
```shell
|
||||
kubectl get pods \
|
||||
--all-namespaces \
|
||||
--output jsonpath='{.items[*].metadata.annotations.kubernetes\.io\/psp}' \
|
||||
| tr " " "\n" | sort -u
|
||||
```
|
||||
|
||||
1. 按照[将 PSP 映射到 Pod 安全标准](https://kubernetes.io/docs/reference/access-authn-authz/psp-to-pod-security-standards/)的 Kubernetes 指南将 PSS 应用于依赖 PSP 的工作负载。有关详细信息，请参阅[从 PodSecurityPolicy 迁移到内置 PodSecurity Admission 控制器](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/)。
|
||||
|
||||
1. 要从 Rancher Chart 中删除 PSP，请在升级到 Kubernetes v1.25 _之前_将 Chart 升级到最新的 v102.x.y 版本。确保 **Enable PodSecurityPolicies** 选项**已禁用**。这将删除与以前的 Chart 版本一起安装的所有 PSP。
|
||||
|
||||
:::info 重要提示
|
||||
如果你想将 Chart 升级到 v102.x.y，但不打算将集群升级到 Kubernetes v1.25 和弃用 PSP，请确保为每个要升级的 Chart 选择 **Enable PodSecurityPolicies** 选项。
|
||||
:::
|
||||
|
||||
### 在 Kubernetes v1.25 升级后清理版本
|
||||
|
||||
如果你在删除 Chart 的 PSP 时遇到问题，或者 Chart 不包含用于删除 PSP 的内置机制，Chart 升级或删除可能会失败并显示如下错误消息：
|
||||
```console
|
||||
Error: UPGRADE FAILED: resource mapping not found for name: "<object-name>" namespace: "<object-namespace>" from "": no matches for kind "PodSecurityPolicy" in version "policy/v1beta1"
|
||||
ensure CRDs are installed first
|
||||
```
|
||||
|
||||
Helm 尝试在集群中查询存储在先前版本的数据 blob 中的对象时，就会发生这种情况。要清理这些版本并避免此错误，请使用 `helm-mapkubeapis` Helm 插件。要详细了解 `helm-mapkubeapis`、它的工作原理以及如何针对你的用例进行微调，请参阅 [Helm 官方文档](https://github.com/helm/helm-mapkubeapis#readme)。
|
||||
|
||||
请注意，Helm 插件安装在你运行命令的机器本地。因此，请确保从同一台机器运行安装和清理。
|
||||
|
||||
#### 安装 `helm-mapkubeapis`
|
||||
|
||||
1. 在打算使用 `helm-mapkubeapis` 的机器上打开你的终端并安装插件：
|
||||
```shell
|
||||
helm plugin install https://github.com/helm/helm-mapkubeapis
|
||||
```
|
||||
|
||||
你将看到类似于以下的输出：
|
||||
```console
|
||||
Downloading and installing helm-mapkubeapis v0.4.1 ...
|
||||
https://github.com/helm/helm-mapkubeapis/releases/download/v0.4.1/helm-mapkubeapis_0.4.1_darwin_amd64.tar.gz
|
||||
Installed plugin: mapkubeapis
|
||||
```
|
||||
|
||||
:::info 重要提示
|
||||
确保 `helm-mapkubeapis` 插件至少为 v0.4.1，因为旧版本_不_支持资源删除。
|
||||
:::
|
||||
|
||||
1. 验证插件是否已正确安装：
|
||||
```shell
|
||||
helm mapkubeapis --help
|
||||
```
|
||||
|
||||
你将看到类似于以下的输出：
|
||||
```console
|
||||
Map release deprecated or removed Kubernetes APIs in-place
|
||||
|
||||
Usage:
|
||||
mapkubeapis [flags] RELEASE
|
||||
|
||||
Flags:
|
||||
--dry-run simulate a command
|
||||
-h, --help help for mapkubeapis
|
||||
--kube-context string name of the kubeconfig context to use
|
||||
--kubeconfig string path to the kubeconfig file
|
||||
--mapfile string path to the API mapping file
|
||||
--namespace string namespace scope of the release
|
||||
```
|
||||
|
||||
#### 清理损坏的版本
|
||||
|
||||
安装 `helm-mapkubeapis` 插件后，清理升级到 Kubernetes v1.25 后损坏的版本。
|
||||
|
||||
1. 打开你的首选终端并通过运行 `kubectl cluster-info` 确保终端已连接到所需集群。
|
||||
|
||||
1. 运行 `helm list --all-namespaces` 列出你在集群中安装的所有版本。
|
||||
|
||||
1. 通过运行 `helm mapkubeapis --dry-run <release-name> --namespace <release-namespace>` 为要清理的每个版本执行试运行。你可以通过此命令的结果了解要替换或删除哪些资源。
|
||||
|
||||
1. 最后，在查看更改后，使用 `helm mapkubeapis <release-name> --namespace <release-namespace>` 执行完整运行。
|
||||
|
||||
#### 将 Chart 升级到支持 Kubernetes v1.25 的版本
|
||||
|
||||
清理了具有 PSP 的所有版本后，你就可以继续升级了。对于 Rancher 维护的工作负载，请按照本文档[从 Rancher 维护的应用程序和市场工作负载中删除 PodSecurityPolicies](#remove-psp-rancher-workloads) 部分中的步骤进行操作。
|
||||
如果工作负载不是由 Rancher 维护的，请参阅对应的提供商的文档。
|
||||
|
||||
:::caution
|
||||
不要跳过此步骤。与 Kubernetes v1.25 不兼容的应用程序不能保证在清理后正常工作。
|
||||
:::
|
||||
|
||||
## Pod 安全准入配置模板 {#psa-config-templates}
|
||||
|
||||
Rancher 提供了 PSA 配置模板。它们是可以应用到集群的预定义安全配置。Rancher 管理员（或具有权限的人员）可以[创建、管理和编辑](./psa-config-templates.md) PSA 模板。
|
||||
|
||||
### 受 PSA 限制的集群上的 Rancher
|
||||
|
||||
Rancher system 命名空间也受到 PSA 模板描述的限制性安全策略的影响。你需要在分配模板后豁免 Rancher 的 system 命名空间，否则集群将无法正常运行。有关详细信息，请参阅 [Pod 安全准入 (PSA) 配置模板](./psa-config-templates.md#豁免必须的-rancher-命名空间)。
|
||||
|
||||
有关运行 Rancher 所需的所有豁免的完整文件，请参阅此[准入配置示例](../../../reference-guides/rancher-security/psa-restricted-exemptions.md)。
|
||||
+142
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: Pod 安全准入 (PSA) 配置模板
|
||||
---
|
||||
|
||||
[Pod Security admission (PSA)](./pod-security-standards.md) 配置模板是 Rancher 自定义资源 (CRD)，在 Rancher v2.7.2 及更高版本中可用。这些模板提供了可应用于集群的预定义安全配置：
|
||||
|
||||
:::info important
|
||||
The policies shipped by default in Rancher aim to provide a trade-off between security and convenience. If a more strict policy configuration is needed, users are able to craft such policies themselves based on their specific requirements. In the case Rancher policies are preferred, you will need to deploy admission controllers that block the creation of any [exempted namespaces](#豁免必须的-rancher-命名空间) that won't be used within your environments.
|
||||
:::
|
||||
|
||||
- `rancher-privileged`：最宽松的配置。它不限制任何 Pod 行为，允许已知的权限升级。该策略没有豁免。
|
||||
- `rancher-restricted`：严格限制的配置，遵循当前加固 pod 的最佳实践。你必须对 Rancher 组件进行[命名空间级别豁免](./pod-security-standards.md#受-psa-限制的集群上的-rancher)。
|
||||
|
||||
## 分配 Pod 安全准入 (PSA) 配置模板
|
||||
|
||||
你可以在创建下游集群的同时分配 PSA 模板。你还可以通过配置现有集群来添加模板。
|
||||
|
||||
### 在集群创建期间分配模板
|
||||
<Tabs>
|
||||
<TabItem value="RKE2 和 K3s">
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，单击**创建**按钮。
|
||||
1. 选择提供商。
|
||||
1. 在**集群: 创建**页面上，转到**基本信息 > 安全**。
|
||||
1. 在 **PSA 配置模板**下拉菜单中，选择要分配的模板。
|
||||
1. 单击**创建**。
|
||||
|
||||
### 将模板分配给现有集群
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**表中找到要更新的集群，点击 **⋮**。
|
||||
1. 选择**编辑配置**。
|
||||
1. 在 **PSA 配置模板**下拉菜单中，选择要分配的模板。
|
||||
1. 单击**保存**。
|
||||
|
||||
### 加固集群
|
||||
|
||||
如果选择 **rancher-restricted** 模板但不选择 **CIS 配置文件**，你将无法满足 CIS Benchmark。有关详细信息，请参阅 [RKE2 加固指南](../../../pages-for-subheaders/rke2-hardening-guide.md)。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE1">
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，单击**创建**按钮。
|
||||
1. 选择提供商。
|
||||
1. 在**添加集群**页面上的**集群选项**下，单击 **高级选项**。
|
||||
1. 在 **PSA 配置模板**下拉菜单中，选择要分配的模板。
|
||||
1. 单击**创建**。
|
||||
|
||||
### 将模板分配给现有集群
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**表中找到要更新的集群，点击 **⋮**。
|
||||
1. 选择**编辑配置**。
|
||||
1. 在**编辑集群**页面上，转到**集群选项 > 高级选项**。
|
||||
1. 在 **PSA 配置模板**中，选择要分配的模板。
|
||||
1. 单击**保存**。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 添加或编辑 Pod 安全准入 (PSA) 配置模板
|
||||
|
||||
如果你拥有管理员权限，则可以通过创建其他 PSA 模板或编辑现有模板来自定义安全限制和权限。
|
||||
|
||||
:::caution
|
||||
如果编辑使用中的现有 PSA 模板，更改将应用于已分配给该模板的所有集群。
|
||||
:::
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 点击**高级选项**打开下拉菜单。
|
||||
1. 选择 **Pod 安全准入**。
|
||||
1. 找到要修改的模板，点击 **⋮**。
|
||||
1. 选择**编辑配置**来编辑模板。
|
||||
1. 完成配置编辑后，单击**保存**。
|
||||
|
||||
### 允许非管理员用户管理 PSA 模板
|
||||
|
||||
如果你想允许其他用户管理模板，你可以将该用户绑定到一个角色，并为该角色授予 `management.cattle.io/podsecurityadmissionconfigurationtemplates` 上的所有操作 (`"*"`)。
|
||||
|
||||
:::caution
|
||||
绑定到上述权限的用户都能够更改使用该 PSA 模板的_所有_托管集群的限制级别，包括用户没有权限的集群。
|
||||
:::
|
||||
|
||||
## 豁免必须的 Rancher 命名空间
|
||||
|
||||
在默认执行限制性安全策略的 Kubernetes 集群上运行 Rancher 时，你需要[豁免以下命名空间](#豁免命名空间)，否则该策略可能会阻止 Rancher system pod 正常运行。
|
||||
|
||||
- `calico-apiserver`
|
||||
- `calico-system`
|
||||
- `cattle-alerting`
|
||||
- `cattle-csp-adapter-system`
|
||||
- `cattle-epinio-system`
|
||||
- `cattle-externalip-system`
|
||||
- `cattle-fleet-local-system`
|
||||
- `cattle-fleet-system`
|
||||
- `cattle-gatekeeper-system`
|
||||
- `cattle-global-data`
|
||||
- `cattle-global-nt`
|
||||
- `cattle-impersonation-system`
|
||||
- `cattle-istio`
|
||||
- `cattle-istio-system`
|
||||
- `cattle-logging`
|
||||
- `cattle-logging-system`
|
||||
- `cattle-monitoring-system`
|
||||
- `cattle-neuvector-system`
|
||||
- `cattle-prometheus`
|
||||
- `cattle-sriov-system`
|
||||
- `cattle-system`
|
||||
- `cattle-ui-plugin-system`
|
||||
- `cattle-windows-gmsa-system`
|
||||
- `cert-manager`
|
||||
- `cis-operator-system`
|
||||
- `fleet-default`
|
||||
- `ingress-nginx`
|
||||
- `istio-system`
|
||||
- `kube-node-lease`
|
||||
- `kube-public`
|
||||
- `kube-system`
|
||||
- `longhorn-system`
|
||||
- `rancher-alerting-drivers`
|
||||
- `security-scan`
|
||||
- `tigera-operator`
|
||||
|
||||
Rancher、Rancher 拥有的一些 Chart 以及 RKE2 和 K3s 发行版都使用这些命名空间。列出的命名空间的一个子集已经在内置的 Rancher `rancher-restricted` 策略中被豁免，用于下游集群。有关运行 Rancher 所需的所有豁免的完整模板，请参阅此[准入配置示例](../../../reference-guides/rancher-security/psa-restricted-exemptions.md)。
|
||||
|
||||
## 豁免命名空间
|
||||
|
||||
如果你将 `rancher-restricted` 模板分配给集群，默认情况下，限制会在命名空间级别应用于整个集群。要在此高度受限的策略下豁免特定的命名空间，执行以下操作：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 点击**高级选项**打开下拉菜单。
|
||||
1. 选择 **Pod 安全准入**。
|
||||
1. 找到要修改的模板，点击 **⋮**。
|
||||
1. 选择**编辑配置**。
|
||||
1. 选中**豁免**下的**命名空间**复选框以编辑**命名空间**字段。
|
||||
1. 豁免命名空间后，单击**保存**。
|
||||
|
||||
:::note
|
||||
你需要更新目标集群才能让新模板在集群中生效。要触发更新，在不更改值的情况下编辑和保存集群。
|
||||
:::
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: 备份 Docker 安装的 Rancher
|
||||
---
|
||||
|
||||
成功使用 Docker 安装 Rancher 后，我们建议你定期创建备份。最近创建的备份能让你在意外灾难发生后快速进行恢复。
|
||||
|
||||
## 在你开始前
|
||||
|
||||
在创建备份的过程中，你将输入一系列命令。请使用环境中的数据替换占位符。占位符用尖括号和大写字母（如 `<EXAMPLE>`）表示。以下是带有占位符的命令示例：
|
||||
|
||||
```
|
||||
docker run --name busybox-backup-<DATE> --volumes-from rancher-data-<DATE> -v $PWD:/backup busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
|
||||
```
|
||||
|
||||
在该命令中，`<DATE>` 是数据容器和备份创建日期的占位符（例如，`9-27-18`）。
|
||||
|
||||
请交叉参考下方的图片和表格，了解获取此占位符数据的方法。在开始[以下步骤](#创建备份)之前，请记下或复制这些信息。
|
||||
|
||||
<sup>终端 <code>docker ps</code> 命令，显示如何找到 <code><RANCHER_CONTAINER_TAG></code> 和 <code><RANCHER_CONTAINER_NAME></code></sup>
|
||||
|
||||
|
||||
|
||||
| 占位符 | 示例 | 描述 |
|
||||
| -------------------------- | -------------------------- | --------------------------------------------------------- |
|
||||
| `<RANCHER_CONTAINER_TAG>` | `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` 以查看正在运行的容器，从而获得 `<RANCHER_CONTAINER_TAG>` 和 `<RANCHER_CONTAINER_NAME>`。你还可以运行 `docker ps -a` 命令查看停止了的容器。在创建备份期间，你随时可以运行这些命令来获得帮助。
|
||||
|
||||
## 创建备份
|
||||
|
||||
此步骤将创建一个备份文件。如果 Rancher 遇到灾难情况，你可以使用该备份文件进行还原。
|
||||
|
||||
|
||||
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-<DATE> rancher/rancher:<RANCHER_CONTAINER_TAG>
|
||||
```
|
||||
|
||||
1. <a id="tarball"></a>从你刚刚创建的数据容器（<code>rancher-data-<DATE></code>）中，创建一个备份 tar 包（<code>rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz</code>）。替换占位符来运行以下命令：
|
||||
|
||||
```
|
||||
docker run --name busybox-backup-<DATE> --volumes-from rancher-data-<DATE> -v $PWD:/backup:z busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
|
||||
```
|
||||
|
||||
**步骤结果**：屏幕上将运行命令流。
|
||||
|
||||
1. 输入 `ls` 命令，确认备份压缩包已创建成功。压缩包的名称格式类似 `rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`。
|
||||
|
||||
1. 将备份压缩包移动到 Rancher Server 外的安全位置。然后从 Rancher Server 中删除 `rancher-data-<DATE>` 和 `busybox-backup-<DATE>` 容器。
|
||||
|
||||
```
|
||||
docker rm rancher-data-<DATE>
|
||||
docker rm busybox-backup-<DATE>
|
||||
```
|
||||
|
||||
1. 重启 Rancher Server。将 `<RANCHER_CONTAINER_NAME>` 替换为 Rancher 容器的名称：
|
||||
|
||||
```
|
||||
docker start <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
|
||||
**结果**：创建了 Rancher Server 数据的备份压缩包。如果你需要恢复备份数据，请参见[恢复备份：Docker 安装](restore-docker-installed-rancher.md)。
|
||||
+307
@@ -0,0 +1,307 @@
|
||||
---
|
||||
title: 备份集群
|
||||
---
|
||||
|
||||
在 Rancher UI 中，你可以轻松备份和恢复 [Rancher 启动的 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)的 etcd。
|
||||
|
||||
Rancher 建议为所有生产集群配置定期 `etcd` 快照。此外，你还可以创建单次快照。
|
||||
|
||||
etcd 数据库的快照会保存在 [etcd 节点](#本地备份目标)或 [S3 兼容目标](#s3-备份目标)上。配置 S3 的好处是，如果所有 etcd 节点都丢失了，你的快照会保存到远端并能用于恢复集群。
|
||||
|
||||
## 快照工作原理
|
||||
|
||||
### 快照组件
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
Rancher 创建快照时，快照里包括三个组件：
|
||||
|
||||
- etcd 中的集群数据
|
||||
- Kubernetes 版本
|
||||
- `cluster.yml` 形式的集群配置
|
||||
|
||||
由于 Kubernetes 版本现在包含在快照中，因此你可以将集群恢复到原本的 Kubernetes 版本。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
Rancher 将快照创建任务委托给下游 Kubernetes 引擎。Kubernetes 引擎创建快照时包括了三个组件：
|
||||
|
||||
- etcd 中的集群数据
|
||||
- Kubernetes 版本
|
||||
- 集群配置
|
||||
|
||||
由于 Kubernetes 版本包含在快照中，因此你可以将集群还原到之前的 Kubernetes 版本，同时还原 etcd 快照。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
如果你需要使用快照恢复集群，快照的多个组件允许你选择：
|
||||
|
||||
- **仅恢复 etcd 内容**：类似于在 Rancher v2.4.0 之前版本中的使用快照恢复。
|
||||
- **恢复 etcd 和 Kubernetes 版本**：如果 Kubernetes 升级导致集群失败，并且你没有更改任何集群配置，则应使用此选项。
|
||||
- **恢复 etcd、Kubernetes 版本和集群配置**：如果你在升级时同时更改了 Kubernetes 版本和集群配置，则应使用此选项。
|
||||
|
||||
建议你在执行配置更改或升级之前创建新快照。
|
||||
|
||||
|
||||
### 从 etcd 节点生成快照
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
集群中的每个 etcd 节点都会检查 etcd 集群的健康状况。如果节点报告 etcd 集群是健康的，则会从中创建一个快照，并可选择上传到 S3。
|
||||
|
||||
快照存储在 `/opt/rke/etcd-snapshots` 中。如果该目录在节点上配置为共享挂载，它将被覆盖。由于所有 etcd 节点都会上传快照并保留最后一个，因此 S3 上始终会保留最后一个上传的节点的快照。
|
||||
|
||||
在存在多个 etcd 节点的情况下，任何快照都是在集群健康检查通过后创建的，因此这些快照可以认为是 etcd 集群中数据的有效快照。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
快照是默认启动的。
|
||||
|
||||
快照目录默认为 `/var/lib/rancher/<RUNTIME>/server/db/snapshots`，其中 `<RUNTIME>` 可以是 `rke2` 或 `k3s`。
|
||||
|
||||
在 RKE2 中，快照会存储在每个 etcd 节点上。如果你有多个 etcd 或 etcd + control plane 节点，你将拥有本地 etcd 快照的多个副本。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 快照命名规则
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
快照的名称是自动生成的。在使用 RKE CLI 创建一次性快照时，你可以使用 `--name` 选项来指定快照的名称。
|
||||
|
||||
Rancher 在创建 RKE 集群的快照时，快照名称是基于快照创建类型（手动快照或定期快照）和目标（快照是保存在本地还是上传到 S3）决定的。命名规则如下：
|
||||
|
||||
- `m` 代表手动
|
||||
- `r` 代表定期
|
||||
- `l` 代表本地
|
||||
- `s` 代表 S3
|
||||
|
||||
快照名称示例如下：
|
||||
|
||||
- c-9dmxz-rl-8b2cx
|
||||
- c-9dmxz-ml-kr56m
|
||||
- c-9dmxz-ms-t6bjb
|
||||
- c-9dmxz-rs-8gxc8
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
快照的名称是自动生成的。使用 RKE2 或 K3s CLI 创建一次性快照时，`--name` 选项可用于覆盖快照的基本名称。
|
||||
|
||||
Rancher 在创建 RKE2 或 K3s 集群的快照时，快照名称是基于快照创建类型（手动快照或定期快照）和目标（快照是保存在本地还是上传到 S3）决定的。命名规则如下：
|
||||
|
||||
`<name>-<node>-<timestamp>`
|
||||
|
||||
`<name>`：`--name` 设置的基本名称，可以是以下之一：
|
||||
|
||||
- `etcd-snapshot`：位于定期快照前面
|
||||
- `on-demand`：位于手动按需快照之前
|
||||
|
||||
`<node>`：创建快照的节点的名称。
|
||||
|
||||
`<timestamp>`：快照创建日期的 unix 时间戳。
|
||||
|
||||
快照名称示例如下：
|
||||
|
||||
- `on-demand-my-super-rancher-k8s-node1-1652288934`
|
||||
- `on-demand-my-super-rancher-k8s-node2-1652288936`
|
||||
- `etcd-snapshot-my-super-rancher-k8s-node1-1652289945`
|
||||
- `etcd-snapshot-my-super-rancher-k8s-node2-1652289948`
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 从快照恢复的工作原理
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
在恢复时会发生以下过程：
|
||||
|
||||
1. 如果配置了 S3，则从 S3 检索快照。
|
||||
2. 如果快照压缩了，则将快照解压缩。
|
||||
3. 集群中的一个 etcd 节点会将该快照文件提供给其他节点。
|
||||
4. 其他 etcd 节点会下载快照并验证校验和，以便都能使用相同的快照进行恢复。
|
||||
5. 集群已恢复，恢复后的操作将在集群中完成。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
在还原时，Rancher 会提供几组执行还原的计划。期间将包括以下阶段：
|
||||
|
||||
- Started
|
||||
- Shutdown
|
||||
- Restore
|
||||
- RestartCluster
|
||||
- Finished
|
||||
|
||||
如果 etcd 快照还原失败，阶段将设置为 `Failed`。
|
||||
|
||||
1. 收到 etcd 快照还原请求后，根据 `restoreRKEConfig` 协调集群配置和 Kubernetes 版本。
|
||||
1. 该阶段设置为 `Started`。
|
||||
1. 该阶段设置为 `Shutdown`，并使用运行 `killall.sh` 脚本的计划来关闭整个集群。一个新的初始节点会被选举出来。如果还原的快照是本地快照，则选择该快照所在的节点作为初始节点。如果使用 S3 还原快照，将使用现有的初始节点。
|
||||
1. 该阶段设置为 `Restore`，并且快照将还原到初始节点上。
|
||||
1. 该阶段设置为 `RestartCluster`，集群将重启并重新加入到具有新还原的快照信息的新初始节点。
|
||||
1. 该阶段设置为 `Finished`，集群被视为已成功还原。`cattle-cluster-agent` 将重新连接，集群将完成协调。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 配置定期快照
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
选择创建定期快照的频率以及要保留的快照数量。时间的单位是小时。用户可以使用时间戳快照进行时间点恢复。
|
||||
|
||||
默认情况下，[Rancher 启动的 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)会配置为创建定期快照（保存到本地磁盘）。为防止本地磁盘故障，建议使用 [S3 目标](#s3-备份目标)或复制磁盘上的路径。
|
||||
|
||||
在集群配置或编辑集群期间，可以在**集群选项**的高级部分中找到快照的配置。点击**显示高级选项**。
|
||||
|
||||
在集群的**高级选项**中可以配置以下选项：
|
||||
|
||||
| 选项 | 描述 | 默认值 |
|
||||
| --- | ---| --- |
|
||||
| etcd 快照备份目标 | 选择要保存快照的位置。可以是本地或 S3 | 本地 |
|
||||
| 启用定期 etcd 快照 | 启用/禁用定期快照 | 是 |
|
||||
| 定期 etcd 快照的创建周期 | 定期快照之间的间隔（以小时为单位） | 12 小时 |
|
||||
| 定期 etcd 快照的保留数量 | 要保留的快照数量 | 6 |
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
设置创建定期快照的方式以及要保留的快照数量。该计划采用传统的 Cron 格式。保留策略规定了在每个节点上要保留的匹配名称的快照数量。
|
||||
|
||||
默认情况下，[Rancher 启动的 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)从凌晨 12 点开始每 5 小时创建一次定期快照（保存到本地磁盘）。为了防止本地磁盘故障，建议使用 [S3 目标](#s3-备份目标)或复制磁盘上的路径。
|
||||
|
||||
在集群配置或编辑集群期间，你可以在**集群配置**下找到快照配置。单击 **etcd**。
|
||||
|
||||
| 选项 | 描述 | 默认值 |
|
||||
| --- | ---| --- |
|
||||
| 启用定期 etcd 快照 | 启用/禁用定期快照 | 是 |
|
||||
| 定期 etcd 快照的创建周期 | 定期快照的 Cron 计划 | `0 */5 * * *` |
|
||||
| 定期 etcd 快照的保留数量 | 要保留的快照数量 | 5 |
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 单次快照
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
除了定期快照之外，你可能还想创建“一次性”快照。例如，在升级集群的 Kubernetes 版本之前，最好备份集群的状态以防止升级失败。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，导航到要在其中创建一次性快照的集群。
|
||||
1. 单击 **⋮ > 拍摄快照**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
除了定期快照之外，你可能还想创建“一次性”快照。例如，在升级集群的 Kubernetes 版本之前，最好备份集群的状态以防止升级失败。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，导航到要在其中创建一次性快照的集群。
|
||||
1. 导航至`快照`选项卡，然后单击`立即创建快照`
|
||||
|
||||
### 创建一次性快照的工作原理
|
||||
|
||||
在创建一次性快照时，Rancher 会传递几组计划来执行快照创建。期间将包括以下阶段：
|
||||
|
||||
- Started
|
||||
- RestartCluster
|
||||
- Finished
|
||||
|
||||
如果 etcd 快照创建失败，阶段将设置为 `Failed`。
|
||||
|
||||
1. 收到 etcd 快照创建请求。
|
||||
1. 该阶段设置为 `Started`。集群中的所有 etcd 节点都会根据集群配置收到创建 etcd 快照的计划。
|
||||
1. 该阶段设置为 `RestartCluster`，并且每个 etcd 节点上的计划都将重置为 etcd 节点的原始计划。
|
||||
1. 该阶段设置为 `Finished`。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**结果**：根据你的[快照备份目标](#快照备份目标)创建一次性快照，并将其保存在选定的备份目标中。
|
||||
|
||||
## 快照备份目标
|
||||
|
||||
Rancher 支持两种不同的备份目标：
|
||||
|
||||
- [本地目标](#本地备份目标)
|
||||
- [S3 目标](#s3-备份目标)
|
||||
|
||||
### 本地备份目标
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
默认情况下会选择 `local` 备份目标。此选项的好处是不需要进行外部配置。快照会在本地自动保存到 [Rancher 启动的 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)中 etcd 节点的 `/opt/rke/etcd-snapshots` 中。所有定期快照都是按照配置的时间间隔创建的。使用 `local` 备份目标的缺点是，如果发生全面灾难并且丢失 _所有_ etcd 节点时，则无法恢复集群。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
默认情况下会选择 `local` 备份目标。此选项的好处是不需要进行外部配置。快照会自动保存到 [Rancher 启动的 Kubernetes 集群](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)中的本地 etcd 节点上的 `/var/lib/rancher/<runtime>/server/db/snapshots` 中，其中 `<runtime>` 可以是 `k3s` 或 `rke2`。所有定期快照均按照 Cron 计划进行。使用 `local` 备份目标的缺点是，如果发生全面灾难并且丢失 _所有_ etcd 节点时，则无法恢复集群。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### S3 备份目标
|
||||
|
||||
我们建议你使用 `S3` 备份目标。你可以将快照存储在外部 S3 兼容的后端上。由于快照不存储在本地，因此即使丢失所有 etcd 节点，你仍然可以还原集群。
|
||||
|
||||
虽然 `S3` 比本地备份具有优势，但它需要额外的配置。
|
||||
|
||||
:::caution
|
||||
|
||||
如果你使用 S3 备份目标，请确保每个集群都有自己的存储桶或文件夹。Rancher 将使用集群配置的 S3 存储桶或文件夹中的可用快照来填充快照信息。
|
||||
|
||||
:::
|
||||
|
||||
| 选项 | 描述 | 必填 |
|
||||
|---|---|---|
|
||||
| S3 存储桶名称 | 用于存储备份的 S3 存储桶名称 | * |
|
||||
| S3 区域 | 备份存储桶的 S3 区域 | |
|
||||
| S3 区域端点 | 备份存储桶的 S3 区域端点 | * |
|
||||
| S3 访问密钥 | 有权访问备份存储桶的 S3 访问密钥 | * |
|
||||
| S3 密文密钥 | 有权访问备份存储桶的 S3 密文密钥 | * |
|
||||
| 自定义 CA 证书 | 用于访问私有 S3 后端的自定义证书 |
|
||||
|
||||
### 为 S3 使用自定义 CA 证书
|
||||
|
||||
备份快照可以存储在自定义 `S3` 备份中，例如 [minio](https://min.io/)。如果 S3 后端使用自签名或自定义证书，请使用`自定义 CA 证书`选项来提供自定义证书，从而连接到 S3 后端。
|
||||
|
||||
### 在 S3 中存储快照的 IAM 支持
|
||||
|
||||
除了使用 API 凭证之外，`S3` 备份目标还支持对 AWS API 使用 IAM 身份验证。IAM 角色会授予应用在对 S3 存储进行 API 调用时的临时权限。要使用 IAM 身份验证，必须满足以下要求：
|
||||
|
||||
- 集群 etcd 节点必须具有实例角色，该角色具有对指定备份存储桶的读/写访问权限。
|
||||
- 集群 etcd 节点必须对指定的 S3 端点具有网络访问权限。
|
||||
- Rancher Server worker 节点必须具有实例角色，该实例角色具有对指定备份存储桶的读/写访问权限。
|
||||
- Rancher Server worker 节点必须对指定的 S3 端点具有网络访问权限。
|
||||
|
||||
要授予应用对 S3 的访问权限，请参阅[使用 IAM 角色向在 Amazon EC2 实例上运行的应用授予权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)的 AWS 文档。
|
||||
|
||||
## 查看可用快照
|
||||
|
||||
Rancher UI 中提供了集群所有可用快照的列表：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面中，转到要查看快照的集群并单击其名称。
|
||||
1. 单击**快照**选项卡来查看已保存快照的列表。这些快照包括创建时间的时间戳。
|
||||
|
||||
## 安全时间戳（RKE）
|
||||
|
||||
快照文件带有时间戳，从而简化使用外部工具和脚本处理文件的过程。但在某些与 S3 兼容的后端中，这些时间戳无法使用。
|
||||
|
||||
添加了选项 `safe_timestamp` 以支持兼容的文件名。当此标志设置为 `true` 时，快照文件名时间戳中的所有特殊字符都将被替换。
|
||||
|
||||
此选项不能直接在 UI 中使用，只能通过`以 YAML 文件编辑`使用。
|
||||
+92
@@ -0,0 +1,92 @@
|
||||
---
|
||||
title: 备份 Rancher
|
||||
---
|
||||
|
||||
在本节中，你将学习如何备份运行在任何 Kubernetes 集群上的 Rancher。要备份通过 Docker 安装的 Rancher，请参见[单节点备份](back-up-docker-installed-rancher.md)。
|
||||
|
||||
`backup-restore` operator 需要安装在 local 集群上，并且只对 Rancher 应用进行备份。备份和恢复操作仅在本地 Kubernetes 集群中执行。
|
||||
|
||||
请知悉，`rancher-backup` operator 的 2.x.x 版本用于 Rancher v2.6.x。
|
||||
|
||||
:::caution
|
||||
|
||||
当把备份恢复到一个新的 Rancher 设置中时，新设置的版本应该与备份的版本相同。在恢复备份时还应考虑 Kubernetes 的版本，因为集群中支持的 apiVersion 和备份文件中的 apiVersion 可能不同。
|
||||
|
||||
:::
|
||||
|
||||
### 先决条件
|
||||
|
||||
Rancher 必须是 2.5.0 或更高版本。
|
||||
|
||||
请参见[此处](migrate-rancher-to-new-cluster.md#2-使用-restore-自定义资源来还原备份)获取在 Rancher 2.6.3 中将现有备份文件恢复到 v1.22 集群的帮助。
|
||||
|
||||
### 1. 安装 Rancher Backup Operator
|
||||
|
||||
备份存储位置是 operator 级别的设置，所以需要在安装或升级 `rancher backup` 应用时进行配置。
|
||||
|
||||
备份文件的格式是 `.tar.gz`。这些文件可以推送到 S3 或 Minio，也可以存储在一个持久卷中。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到 `local` 集群并单击 **Explore**。Rancher Server 运行在 `local` 集群中。
|
||||
1. 单击 **Apps > Charts**。
|
||||
1. 点击 **Rancher 备份**。
|
||||
1. 单击**安装**。
|
||||
1. 配置默认存储位置。如需获取帮助，请参见[存储配置](../../../reference-guides/backup-restore-configuration/storage-configuration.md)。
|
||||
1. 单击**安装**。
|
||||
|
||||
:::note
|
||||
|
||||
使用 `backup-restore` operator 执行恢复后，Fleet 中会出现一个已知问题：用于 `clientSecretName` 和 `helmSecretName` 的密文不包含在 Fleet 的 Git 仓库中。请参见[此处](../deploy-apps-across-clusters/fleet.md#故障排除)获得解决方法。
|
||||
|
||||
:::
|
||||
|
||||
### 2. 执行备份
|
||||
|
||||
要执行备份，必须创建 Backup 类型的自定义资源。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到 `local` 集群并单击 **Explore**。
|
||||
1. 在左侧导航栏中，点击 **Rancher 备份 > 备份**。
|
||||
1. 单击**创建**。
|
||||
1. 使用表单或 YAML 编辑器创建 Backup。
|
||||
1. 要使用该表单配置 Backup 详细信息，请单击**创建**，然后参见[配置参考](../../../reference-guides/backup-restore-configuration/backup-configuration.md)和[示例](../../../reference-guides/backup-restore-configuration/examples.md#备份)进行操作。
|
||||
1. 要使用 YAML 编辑器，单击**创建 > 使用 YAML 文件创建**。输入 Backup YAML。这个示例 Backup 自定义资源将在 S3 中创建加密的定期备份。这个应用使用 `credentialSecretNamespace` 值来确定在哪里寻找 S3 备份的密文：
|
||||
|
||||
```yaml
|
||||
apiVersion: resources.cattle.io/v1
|
||||
kind: Backup
|
||||
metadata:
|
||||
name: s3-recurring-backup
|
||||
spec:
|
||||
storageLocation:
|
||||
s3:
|
||||
credentialSecretName: s3-creds
|
||||
credentialSecretNamespace: default
|
||||
bucketName: rancher-backups
|
||||
folder: rancher
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
resourceSetName: rancher-resource-set
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
schedule: "@every 1h"
|
||||
retentionCount: 10
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
使用 YAML 编辑器创建 Backup 资源时，`resourceSetName` 必须设置为 `rancher-resource-set`。
|
||||
|
||||
:::
|
||||
|
||||
如需获得配置 Backup 的帮助，请参见[配置参考](../../../reference-guides/backup-restore-configuration/backup-configuration.md)和[示例](../../../reference-guides/backup-restore-configuration/examples.md#备份)。
|
||||
|
||||
:::caution
|
||||
|
||||
`rancher-backup` operator 不保存 `EncryptionConfiguration` 文件。创建加密备份时，必须保存 `EncryptionConfiguration` 文件的内容，而且在使用备份还原时必须使用同一个文件。
|
||||
|
||||
:::
|
||||
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：备份文件创建在 Backup 自定义资源中配置的存储位置中。执行还原时使用该文件的名称。
|
||||
|
||||
+129
@@ -0,0 +1,129 @@
|
||||
---
|
||||
title: 备份恢复使用指南
|
||||
---
|
||||
|
||||
Rancher Backups Chart 是我们的灾难恢复和迁移解决方案。此 Chart 用于备份 Kubernetes 资源并将其保存到各种持久存储位置。
|
||||
|
||||
这个 Chart 是一个非常简单的工具，适用于 Rancher 生态系统的许多不同领域。但是，也因此出现了未记录功能的边缘用例。本文档旨在强调 Rancher Backups 正确的用法，并讨论我们遇到的一些边缘情况。
|
||||
|
||||
## 功能概述
|
||||
|
||||
### 备份
|
||||
|
||||
该 Operator 将 Chart 中的 resourceSet 捕获的所有资源收集为内存中的非结构化对象。收集资源后，资源的 tar 包将保存为 JSON 格式的清单集合，然后上传到用户定义的对象存储。该备份可以按重复计划进行，也可以进行加密。由于某些资源是敏感的，并且值以未加密的明文形式存储，因此此加密选项很重要。
|
||||
|
||||
有关配置备份的选项（包括加密），请参阅[备份配置文档](../../../reference-guides/backup-restore-configuration/backup-configuration.md)。
|
||||
|
||||
:::note
|
||||
|
||||
如[备份 Rancher 文档](./back-up-rancher.md)所述，你必须手动保存加密配置文件的内容，因为 Operator **不会**备份它。
|
||||
|
||||
:::
|
||||
|
||||
### 还原
|
||||
|
||||
有两种主要的还原场景：还原正在运行 Rancher 的集群以及还原新集群。只有将备份还原到该备份的源集群，且在还原过程中启用了 [`prune` 选项](../../../reference-guides/backup-restore-configuration/restore-configuration.md#还原过程中修剪)时，你才能还原正在运行 Rancher 的集群。还原具有与备份类似的输入。它需要备份文件名、encryptionConfigSecret 名称和存储位置。
|
||||
|
||||
资源按以下顺序还原：
|
||||
|
||||
1. 自定义资源定义（CRD）
|
||||
2. 集群范围资源
|
||||
3. 命名空间资源
|
||||
|
||||
有关配置还原的选项，请参阅[还原配置文档](../../../reference-guides/backup-restore-configuration/restore-configuration.md)。
|
||||
|
||||
### 资源集
|
||||
|
||||
ResourceSet 确定了 backup-restore-operator 在备份中收集哪些资源。它是一组 ResourceSelector，使用键/值对匹配、正则表达式匹配或 Kubernetes 客户端 labelSelector 来定义选择要求。
|
||||
|
||||
以下是可用于 resourceSelector 的字段：
|
||||
|
||||
- apiVersion
|
||||
- excludeKinds
|
||||
- excludeResourceNameRegexp
|
||||
- kinds
|
||||
- kindsRegexp
|
||||
- labelSelectors
|
||||
- namespaceRegexp
|
||||
- namespaces
|
||||
- resourceNameRegexp
|
||||
- resourceNames
|
||||
|
||||
Rancher Backups Chart 包含了一个[默认 resourceSet](https://github.com/rancher/backup-restore-operator/tree/release/v3.0/charts/rancher-backup/files/default-resourceset-contents)，它是安装 Chart 时附加到一个大型 resourceSet 的 YAML 文件组合。文件顺序并不重要。不同版本的 resourceSet 可能有所不同。
|
||||
|
||||
:::caution
|
||||
|
||||
如果你希望编辑 resourceSet，请在安装 Chart 之前进行**编辑**。
|
||||
|
||||
:::
|
||||
|
||||
## 正确使用
|
||||
|
||||
本节概述了如何根据用例正确使用 Rancher Backups Chart。
|
||||
|
||||
### 所有案例
|
||||
|
||||
- Rancher Backups 必须安装在 local 集群上。
|
||||
- 注意：Rancher Backups 只会处理安装了它的集群。它可能会还原 local 集群上的集群资源，但不会联系或备份下游集群。
|
||||
- 要还原的 Rancher 版本必须与备份中的 Rancher 版本匹配。
|
||||
- 由于你可能需要还原已过时的资源（要还原的 Kubernetes 版本已弃用的资源），因此你需要考虑 Kubernetes 版本。
|
||||
|
||||
### 备份
|
||||
|
||||
- 用户生成的某些资源不会被备份，除非这些资源可以被默认 resourceSet 捕获，或者 resourceSet 已被更改为捕获这些资源。
|
||||
- 我们提供了一个 `resources.cattle.io/backup:true` 标签，将该标签添加到任何命名空间中的 Secret 时，命名空间将被备份。
|
||||
- 备份是不可改变的
|
||||
- 仅备份 local 集群
|
||||
|
||||
### 还原
|
||||
|
||||
- 还原是指将备份还原到原来的集群。可以在安装了 Rancher 的情况下进行（**必须启用 prune**），也可以在未安装 Rancher 的情况下进行（无特殊说明）。
|
||||
- 还原时需要注意的一件事是，你可能需要“擦除”集群中的所有 Rancher 资源。你可以通过将 [Rancher cleanup script](https://github.com/rancher/rancher-cleanup) 脚本作为 job 部署到集群来完成这点。这样，你可以再次安装 Rancher Backups 并还原到全新的集群。
|
||||
- 确保使用了 kubectl 来部署脚本。
|
||||
|
||||
### 迁移
|
||||
|
||||
由于我们要还原到不同的集群，因此对应的迁移有一些细微差别。以下是需要记住但又容易被忘记的事情。
|
||||
|
||||
- 迁移时 Rancher 域必须相同。换言之，你旧集群的域名现在必须指向新集群。
|
||||
- Rancher **不应该**已运行在你要迁移到的集群，这可能会导致 Rancher 备份和某些 Rancher 服务出现许多问题。
|
||||
- **还原备份后**，安装与备份**相同**的 Rancher 版本。
|
||||
- 在其他 Kubernetes 版本上配置新集群可能会出现各种不受支持的情况，这是因为可用的 Kubernetes API 可能与你备份的 API 不同。这可能会导致已弃用的资源被恢复，从而导致问题。
|
||||
- 在迁移期间**不要**执行任何升级操作。
|
||||
|
||||
## 边缘案例和不当使用
|
||||
|
||||
以下是 Rancher Backups 的一些**不当**使用示例。
|
||||
|
||||
### 升级
|
||||
|
||||
- 使用 Rancher Backups 来升级 Rancher 版本不是一个有效用法。推荐的做法是：先备份当前版本，然后按照[说明](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md)升级你的 Rancher 实例，在升级完成后再进行**另一个**备份。这样，如果升级失败，你就有一个可以用来还原的备份，而第二个备份将能用于还原到升级后的 Rancher 版本。
|
||||
- 使用 Rancher Backups 来升级 Kubernetes 版本也不是一个有效用法。由于 Kubernetes API 以及可用资源与版本相关，因此使用备份还原的方法来进行升级可能会导致资源集不对齐的问题，这些资源可能已被弃用、不受支持或已更新。升级集群版本的方式取决于其配置方式，但建议使用上述的流程（备份、升级、备份）。
|
||||
|
||||
### ResourceSet
|
||||
|
||||
- 由于不同团队的资源和服务会不断发展，开发人员应要注意是否需要向默认 resourceSet 添加或删除新资源。
|
||||
- Rancher Backups 仅备份默认 resourceSet 捕获的内容（除非进行编辑）。我们为用户创建的 Secret 添加了特定标签，无论 Secret 的名称是什么，无论它属于哪个命名空间，具有该标签 Secret 都会被备份（请参阅[备份的正确用法](#备份)）。
|
||||
|
||||
### 下游集群
|
||||
|
||||
- Rancher Backups **仅**备份 local 集群上的 Kubernetes 资源。换言之，除了存在于 local 集群中的资源，下游集群**不会**被触及或备份。下游集群的更新和通信由 rancher-agent 和 rancher-webhook 负责。
|
||||
|
||||
### 还原已删除的资源
|
||||
|
||||
- 有些资源会产生外部结果，例如会配置下游集群。删除下游集群并还原 local 集群上的集群资源**不会**导致 Rancher 重新配置所述集群。某些资源可能无法通过还原回到可用状态。
|
||||
- “还原已删除的集群”**不是**受支持的功能。涉及下游集群时，无论集群是配置的还是导入的，删除集群都会执行一系列清理任务，导致我们无法还原已删除的集群。配置的集群节点以及与 Rancher 相关的配置资源将被销毁，而导入的集群的 Rancher Agent 以及与 local 集群注册相关的其他资源/服务可能会被销毁。
|
||||
|
||||
:::caution
|
||||
|
||||
尝试删除和还原下游集群可能会导致 Rancher、Rancher Backups、rancher-webhook、Fleet 等出现各种问题。因此，我们不建议你这样做。
|
||||
|
||||
:::
|
||||
|
||||
### Fleet、Harvester 和其他服务
|
||||
|
||||
由 Rancher Backups 支持的其他服务会经常发生变化和发展。发生这种情况时，他们的资源和备份需求也可能会发生变化。有些资源可能根本不需要备份。团队需要在开发过程中考虑这一点，并评估相关 resourceSet 是否能正确捕获正确的资源集来还原其服务。
|
||||
|
||||
## 结论
|
||||
|
||||
Rancher Backups 是一个非常有用的工具，但它的使用范围和使用目的有限的。为了避免出现问题，请遵循本文所述的流程来确保 Chart 能正确运作。
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user