mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-27 13:38:07 +00:00
Add version 2.9 preview
This commit is contained in:
Billy Tat
+121
@@ -0,0 +1,121 @@
|
||||
---
|
||||
title: CIS 扫描
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/cis-scans"/>
|
||||
</head>
|
||||
|
||||
Rancher 可以通过运行安全扫描来检查 Kubernetes 是否按照 CIS Kubernetes Benchmark 中定义的安全最佳实践进行部署。CIS 扫描可以运行在任何 Kubernetes 集群，包括托管的 Kubernetes，例如 EKS、AKS 和 GKE。
|
||||
|
||||
`rancher-cis-benchmark` 应用使用了 <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench,</a> ，这是 Aqua Security 的开源工具，用于检查集群是否符合 CIS Kubernetes Benchmark。此外，为了生成集群级别的报告，此应用使用了 <a href="https://github.com/vmware-tanzu/sonobuoy" target="_blank">Sonobuoy</a> 来聚合报告。
|
||||
|
||||
## 关于 CIS Benchmark
|
||||
|
||||
CIS（Center for Internet Security）是一个 501(c\)(3) 非营利组织，成立于 2000 年 10 月，其使命是识别、开发、验证、促进和维持网络防御的最佳实践方案，并建立和指导社区，以在网络空间中营造信任的环境。该组织总部位于纽约东格林布什，其成员包括大公司、政府机构和学术机构。
|
||||
|
||||
CIS Benchmark 是目标系统安全配置的最佳实践。CIS Benchmark 是由安全专家、技术供应商、公开和私人社区成员，以及 CIS Benchmark 开发团队共同志愿开发的。
|
||||
|
||||
在 CIS 网站上[注册](https://learn.cisecurity.org/benchmarks)以查看官方 Benchmark 文档。
|
||||
|
||||
## 关于生成的报告
|
||||
|
||||
每次扫描都会生成一份报告，你可以在 Rancher UI 中查看该报告，并以 CSV 格式下载它。
|
||||
|
||||
默认情况下使用 CIS Benchmark v1.6。
|
||||
|
||||
Benchmark 版本包含在生成的报告中。
|
||||
|
||||
Benchmark 提供两种类型的建议，分别是自动（Automated）和手动（Manual）。Benchmark 中标记为 Manual 的建议不包含在生成的报告中。
|
||||
|
||||
一些测试会被标记为“不适用”。由于 Rancher 配置 RKE 集群的方式，这些测试不会在任何 CIS 扫描中运行。有关如何审核测试结果，以及为什么某些测试会被标记为不适用，请参阅 Rancher 的 Kubernetes 对应版本的[自测指南](../../reference-guides/rancher-security/rancher-security.md#CIS-Benchmark-和自我评估)。
|
||||
|
||||
该报告包含以下信息：
|
||||
|
||||
| 报告中的列 | 描述 |
|
||||
|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `id` | CIS Benchmark 的 ID 号。 |
|
||||
| `description` | CIS Benchmark 测试的描述。 |
|
||||
| `remediation` | 为了通过测试需要修复的内容。 |
|
||||
| `state` | 测试的状态，可以是通过、失败、跳过或不适用。 |
|
||||
| `node_type` | 节点角色，角色决定了在节点上运行的测试。主测试在 controlplane 节点上运行，etcd 测试在 etcd 节点上运行，节点测试在 Worker 节点上运行。 |
|
||||
| `audit` | 这是 `kube-bench` 为此测试运行的审计检查。 |
|
||||
| `audit_config` | 适用于审计脚本的任何配置。 |
|
||||
| `test_info` | `kube-bench` 报告的测试相关信息（如果存在）。 |
|
||||
| `commands` | `kube-bench` 报告的测试相关的命令（如果存在）。 |
|
||||
| `config_commands` | `kube-bench` 报告的测试相关的配置数据（如果存在）。 |
|
||||
| `actual_value` | 测试的实际值。如果由 `kube-bench` 报告，则会显示。 |
|
||||
| `expected_result` | 测试的预期值。如果由 `kube-bench` 报告，则会显示。 |
|
||||
|
||||
请参阅[集群加固指南中的表格](../../reference-guides/rancher-security/rancher-security.md)，以了解 Kubernetes、Benchmark、Rancher 以及我们的集群强化指南的版本对应关系。另外，请参阅强化指南，以获取符合 CIS 的集群的配置文件以及修复失败测试的信息。
|
||||
|
||||
## 测试配置文件
|
||||
|
||||
以下是可用的配置文件：
|
||||
|
||||
- Generic CIS 1.6
|
||||
- Generic CIS 1.20
|
||||
- Generic CIS 1.23
|
||||
- RKE permissive 1.6
|
||||
- RKE hardened 1.6
|
||||
- RKE permissive 1.20
|
||||
- RKE hardened 1.20
|
||||
- RKE permissive 1.23
|
||||
- RKE hardened 1.23
|
||||
- RKE2 permissive 1.6
|
||||
- RKE2 hardened 1.6
|
||||
- RKE2 permissive 1.20
|
||||
- RKE2 hardened 1.20
|
||||
- RKE2 permissive 1.23
|
||||
- RKE2 hardened 1.23
|
||||
- K3s permissive 1.6
|
||||
- K3s hardened 1.6
|
||||
- K3s permissive 1.20
|
||||
- K3s hardened 1.20
|
||||
- K3s permissive 1.23
|
||||
- K3s hardened 1.23
|
||||
- AKS
|
||||
- EKS
|
||||
- GKE
|
||||
|
||||
你还可以通过保存一组要跳过的测试来自定义配置文件。
|
||||
|
||||
所有配置文件都会有一组不适用的测试，CIS 扫描会跳过这些测试。RKE 集群管理 Kubernetes 的方式导致这些测试被认为不适用。
|
||||
|
||||
RKE 集群扫描配置文件有两种类型：
|
||||
|
||||
- **Permissive**：此配置文件有一组要跳过的测试，跳过的原因是这些测试会在默认的 RKE Kubernetes 集群上失败。除了跳过的测试列表之外，配置文件也不会运行不适用的测试。
|
||||
- **Hardened**：此配置文件不会跳过任何测试（不适用的测试除外）。
|
||||
|
||||
EKS 和 GKE 集群扫描的配置文件基于这些集群类型特定的 CIS Benchmark 版本。
|
||||
|
||||
要通过 “Hardened” 配置文件，你需要遵从[强化指南](../../reference-guides/rancher-security/rancher-security.md#Rancher-加固指南)并使用强化指南中定义的 `cluster.yml` 来配置一个强化集群。
|
||||
|
||||
默认配置文件和支持的 CIS Benchmark 版本取决于扫描的集群类型：
|
||||
|
||||
`rancher-cis-benchmark` 支持 CIS 1.6 Benchmark 版本。
|
||||
|
||||
- RKE Kubernetes 集群默认使用 RKE Permissive 1.6 配置文件。
|
||||
- EKS 和 GKE 有自己的 CIS Benchmark，由 `kube-bench` 发布。这些集群默认使用相应的测试配置文件。
|
||||
- RKE2 Kubernetes 集群默认使用 RKE2 Permissive 1.6 配置文件。
|
||||
- RKE、RKE2、EKS 和 GKE 以外的集群类型默认使用 Generic CIS 1.5 配置文件。
|
||||
|
||||
## 跳过和不适用的测试
|
||||
|
||||
有关要跳过和不适用的测试列表，请参阅[此页面](../../how-to-guides/advanced-user-guides/cis-scan-guides/skip-tests.md)。
|
||||
|
||||
目前，只有用户定义的跳过测试会在生成报告中标记为跳过。
|
||||
|
||||
如果某个默认配置文件将某个测试定义为跳过，则该测试也会标记为不适用。
|
||||
|
||||
## RBAC
|
||||
|
||||
有关权限的详细信息，请参阅[此页面](rbac-for-cis-scans.md)。
|
||||
|
||||
## 配置
|
||||
|
||||
有关为扫描、配置文件和 Benchmark 版本配置自定义资源的更多信息，请参阅[此页面](configuration-reference.md)。
|
||||
|
||||
## 操作指南
|
||||
|
||||
要了解如何运行 CIS 扫描，请参阅 [CIS 扫描指南](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md)。
|
||||
+105
@@ -0,0 +1,105 @@
|
||||
---
|
||||
title: 配置
|
||||
---
|
||||
|
||||
此配置参考用于帮助你管理由 `rancher-cis-benchmark` 应用创建的自定义资源。这些资源用于在集群上执行 CIS 扫描、跳过测试、设置扫描使用的测试配置文件和其他自定义配置。
|
||||
|
||||
要配置自定义资源，转到**集群**仪表板。要配置 CIS 扫描：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要配置 CIS 扫描的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **CIS Benchmark**。
|
||||
|
||||
### 扫描
|
||||
|
||||
扫描是用来根据定义的配置文件，在集群上触发 CIS 扫描的。扫描完成后会创建一份报告。
|
||||
|
||||
配置扫描时，你需要定义与 `scanProfileName` 参数一起使用的扫描配置文件的名称。
|
||||
|
||||
下面是一个 ClusterScan 自定义资源示例：
|
||||
|
||||
```yaml
|
||||
apiVersion: cis.cattle.io/v1
|
||||
kind: ClusterScan
|
||||
metadata:
|
||||
name: rke-cis
|
||||
spec:
|
||||
scanProfileName: rke-profile-hardened
|
||||
```
|
||||
|
||||
### 配置文件
|
||||
|
||||
配置文件包含 CIS 扫描的配置，包括要使用的 Benchmark 测试版本以及要在该 Benchmark 测试中跳过的测试。
|
||||
|
||||
:::caution
|
||||
|
||||
默认情况下，一些 ClusterScanProfile 会作为 `rancher-cis-benchmark` Chart 的一部分进行安装。如果用户编辑了这些默认 Benchmark 或配置文件，它们会在下一次 Chart 更新时被重置。因此，建议用户不要编辑默认的 ClusterScanProfile。
|
||||
|
||||
:::
|
||||
|
||||
用户可以通过克隆 ClusterScanProfile 来创建自定义配置文件。
|
||||
|
||||
跳过的测试会列在 `skipTests` 参数下。
|
||||
|
||||
创建新配置文件时，你还需要命名配置文件。
|
||||
|
||||
`ClusterScanProfile` 示例如下：
|
||||
|
||||
```yaml
|
||||
apiVersion: cis.cattle.io/v1
|
||||
kind: ClusterScanProfile
|
||||
metadata:
|
||||
annotations:
|
||||
meta.helm.sh/release-name: clusterscan-operator
|
||||
meta.helm.sh/release-namespace: cis-operator-system
|
||||
labels:
|
||||
app.kubernetes.io/managed-by: Helm
|
||||
name: "<example-profile>"
|
||||
spec:
|
||||
benchmarkVersion: cis-1.5
|
||||
skipTests:
|
||||
- "1.1.20"
|
||||
- "1.1.21"
|
||||
```
|
||||
|
||||
### Benchmark 版本
|
||||
|
||||
Benchmark 版本是指使用 `kube-bench` 运行的 Benchmark 名称，以及该 Benchmark 的有效配置参数。
|
||||
|
||||
`ClusterScanBenchmark` 定义了 CIS `BenchmarkVersion` 的名称和测试配置。`BenchmarkVersion` 名称是提供给 `kube-bench` 工具的参数。
|
||||
|
||||
默认情况下，一些 `BenchmarkVersion` 名称和测试配置会作为 CIS 扫描应用的一部分进行打包。启用此功能后，这些默认 BenchmarkVersion 将自动安装，用户可以使用它们来创建 ClusterScanProfile。
|
||||
|
||||
:::caution
|
||||
|
||||
如果用户编辑了默认的 BenchmarkVersion，它们会在下一次 Chart 更新时被重置。因此，不建议编辑默认的 ClusterScanBenchmark。
|
||||
|
||||
:::
|
||||
|
||||
ClusterScanBenchmark 由以下字段组成：
|
||||
|
||||
- `ClusterProvider`：此 Benchmark 适用的集群提供商名称，例如，RKE、EKS、GKE。如果此基准测试可以在任何集群类型上运行，则留空。
|
||||
- `MinKubernetesVersion`：集群运行此 Benchmark 测试所需的最低 kubernetes 版本。如果不依赖特定的 Kubernetes 版本，则留空。
|
||||
- `MaxKubernetesVersion`：集群运行此 Benchmark 测试所需的最高 Kubernetes 版本。如果不依赖特定的 Kubernetes 版本，则留空。
|
||||
|
||||
`ClusterScanBenchmark` 示例如下：
|
||||
|
||||
```yaml
|
||||
apiVersion: cis.cattle.io/v1
|
||||
kind: ClusterScanBenchmark
|
||||
metadata:
|
||||
annotations:
|
||||
meta.helm.sh/release-name: clusterscan-operator
|
||||
meta.helm.sh/release-namespace: cis-operator-system
|
||||
creationTimestamp: "2020-08-28T18:18:07Z"
|
||||
generation: 1
|
||||
labels:
|
||||
app.kubernetes.io/managed-by: Helm
|
||||
name: cis-1.5
|
||||
resourceVersion: "203878"
|
||||
selfLink: /apis/cis.cattle.io/v1/clusterscanbenchmarks/cis-1.5
|
||||
uid: 309e543e-9102-4091-be91-08d7af7fb7a7
|
||||
spec:
|
||||
clusterProvider: ""
|
||||
minKubernetesVersion: 1.15.0
|
||||
```
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: 为集群扫描创建自定义 Benchmark 版本
|
||||
---
|
||||
|
||||
每个 Benchmark 版本都定义了一组测试配置文件，这些文件定义了由 <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> 工具运行的 CIS 测试。
|
||||
`rancher-cis-benchmark` 应用安装了一些默认的 Benchmark 测试版本，这些版本列在了 CIS Benchmark 测试应用菜单下。
|
||||
|
||||
但是，某些 Kubernetes 集群可能需要自定义配置 Benchmark 测试。例如，Kubernetes 配置文件或证书的路径可能与上游 CIS Benchmark 的标准位置不同。
|
||||
|
||||
现在，你可以使用 `rancher-cis-benchmark` 应用来创建自定义 Benchmark 版本，从而运行集群扫描。
|
||||
|
||||
运行集群扫描时，你需要选择指向特定 Benchmark 版本的配置文件。
|
||||
|
||||
按照以下所有步骤添加自定义 Benchmark 版本并使用它运行扫描。
|
||||
|
||||
### 1. 准备自定义 Benchmark 版本 ConfigMap
|
||||
|
||||
要创建自定义 Benchmark 版本，你需要先创建一个包含 Benchmark 版本配置文件的 ConfigMap，并将其上传到要运行扫描的 Kubernetes 集群。
|
||||
|
||||
假设要添加一个名为 `foo` 的自定义 Benchmark 版本，你可以按照以下步骤准备自定义 Benchmark 版本 ConfigMap：
|
||||
|
||||
1. 创建一个名为 `foo` 的目录，并在该目录中放置所有配置 YAML 文件， <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> 工具会搜索这些文件。例如，通用 CIS 1.5 Benchmark 版本的配置 YAML 文件在[此处](https://github.com/aquasecurity/kube-bench/tree/master/cfg/cis-1.5)。
|
||||
1. 放置完整的 `config.yaml` 文件，其中包括所有要测试的组件。
|
||||
1. 将 Benchmark 版本名称添加到 `config.yaml` 的 `target_mapping` 中：
|
||||
|
||||
```yaml
|
||||
target_mapping:
|
||||
"foo":
|
||||
- "master"
|
||||
- "node"
|
||||
- "controlplane"
|
||||
- "etcd"
|
||||
- "policies"
|
||||
```
|
||||
1. 通过创建 ConfigMap 将此目录上传到 Kubernetes 集群：
|
||||
|
||||
```yaml
|
||||
kubectl create configmap -n <namespace> foo --from-file=<path to directory foo>
|
||||
```
|
||||
|
||||
### 2. 将自定义 Benchmark 版本添加到集群
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要添加自定义 Benchmark 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **CIS Benchmark > Benchmark 版本**。
|
||||
1. 单击**创建**。
|
||||
1. 输入自定义 Benchmark 版本的**名称**和描述。
|
||||
1. 选择要应用 Benchmark 版本的集群提供商。
|
||||
1. 在下拉列表中选择你已上传的 ConfigMap。
|
||||
1. 添加最低和最高 Kubernetes 版本限制（如果有）。
|
||||
1. 单击**创建**。
|
||||
|
||||
### 3. 为自定义 Benchmark 版本创建新配置文件
|
||||
|
||||
要使用你的自定义 Benchmark 版本运行扫描，你需要添加一个指向此 Benchmark 版本的新配置文件：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要添加自定义 Benchmark 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **CIS Benchmark > 配置文件**。
|
||||
1. 单击**创建**。
|
||||
1. 设置**名称**和描述。在本例中，我们将其命名为 `foo-profile`。
|
||||
1. 在下拉列表中选择 Benchmark 版本。
|
||||
1. 单击**创建**。
|
||||
|
||||
### 4. 使用自定义 Benchmark 版本运行扫描
|
||||
|
||||
指向你的自定义 Benchmark 版本的 `foo` 配置文件创建完成后，你可以创建一个新的扫描，从而在 Benchmark 版本中运行自定义测试。
|
||||
|
||||
要运行扫描：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要添加自定义 Benchmark 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **CIS Benchmark > 扫描**。
|
||||
1. 单击**创建**。
|
||||
1. 选择新的集群扫描配置文件。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：已生成带有扫描结果的报告。如需查看结果，请单击显示的扫描名称。
|
||||
+46
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: RBAC
|
||||
---
|
||||
|
||||
本文介绍使用 rancher-cis-benchmark 应用所需的权限。
|
||||
|
||||
默认情况下，rancher-cis-benchmark 是集群管理员独有的功能。
|
||||
|
||||
但是，`rancher-cis-benchmark` Chart 安装了这两个默认的 `ClusterRole`：
|
||||
|
||||
- cis-admin
|
||||
- cis-view
|
||||
|
||||
在 Rancher 中，默认情况下只有集群所有者和全局管理员具有 `cis-admin` 访问权限。
|
||||
|
||||
注意：如果你使用在 Rancher 2.5 中添加的 `cis-edit` 角色，该角色从 2.5.2 开始已被删除，删除的原因是该角色本质上与 `cis-admin` 相同。如果你为 `cis-edit` 创建了任何 clusterrolebinding，请更新这些绑定以使用 `cis-admin` ClusterRole。
|
||||
|
||||
## Cluster-Admin 访问
|
||||
|
||||
默认情况下，Rancher CIS 扫描是集群管理员独有的功能。
|
||||
换言之，只有 Rancher 全局管理员和集群的集群所有者可以：
|
||||
|
||||
- 安装/卸载 rancher-cis-benchmark 应用。
|
||||
- 查看 CIS Benchmark CRD 的导航链接 - ClusterScanBenchmarks、ClusterScanProfiles、ClusterScans。
|
||||
- 列出默认的 ClusterScanBenchmarks 和 ClusterScanProfiles。
|
||||
- 创建/编辑/删除新的 ClusterScanProfiles。
|
||||
- 创建/编辑/删除新的 ClusterScan，从而在集群上运行 CIS 扫描。
|
||||
- 在 ClusterScan 完成后查看并下载 ClusterScanReport。
|
||||
|
||||
|
||||
## Kubernetes 默认角色的默认权限摘要
|
||||
|
||||
rancher-cis-benchmark 创建了三个 `ClusterRole`，并将 CIS Benchmark CRD 访问权限添加到以下默认 K8s `ClusterRole`：
|
||||
|
||||
| Chart 创建的 ClusterRole | 默认 K8s ClusterRole | 角色赋予的权限 |
|
||||
| ------------------------------| ---------------------------| ---------------------------|
|
||||
| `cis-admin` | `admin` | 增刪查改（CRUD）clusterscanbenchmarks、clusterscanprofiles、clusterscans、clusterscanreports CR |
|
||||
| `cis-view` | `view ` | 列出 (R) clusterscanbenchmarks、clusterscanprofiles、clusterscans、clusterscanreports CR |
|
||||
|
||||
|
||||
默认情况下，只有 cluster-owner 角色能管理和使用 `rancher-cis-benchmark` 功能。
|
||||
|
||||
默认情况下，其他 Rancher 角色（cluster-member、project-owner 和 project-member）没有管理和使用 rancher-cis-benchmark 资源的权限。
|
||||
|
||||
但是，如果 cluster-owner 想将访问权限分配给其他用户，他们可以手动创建目标用户与上述 CIS ClusterRole 之间的 ClusterRoleBinding，从而实现权限分配。
|
||||
`rancher-cis-benchmark` ClusterRole 不支持自动角色聚合。
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: 跳过和不适用的测试
|
||||
---
|
||||
|
||||
本文列出了在 RKE 的 permissive 测试配置文件中跳过的测试。
|
||||
|
||||
> 在 v2.5 生成的报告中，此页面上被跳过且不适用的测试将会计为不适用。跳过的测试计数只会涉及用户定义的跳过测试。这样，你可以区分用户要跳过的测试与 RKE permissive 测试配置文件中默认跳过的测试。
|
||||
|
||||
## CIS Benchmark v1.5
|
||||
|
||||
### CIS Benchmark v1.5 跳过的测试
|
||||
|
||||
| 数字 | 描述 | 跳过的原因 |
|
||||
| ---------- | ------------- | --------- |
|
||||
| 1.1.12 | 确保 etcd 数据目录所有权设置为 etcd:etcd（自动） | etcd 数据目录所有权需要系统 ServiceAccount。有关如何配置所有权的更多信息，请参阅 Rancher 的强化指南。 |
|
||||
| 1.2.6 | 确保根据需要设置 --kubelet-certificate-authority 参数（自动） | 在生成服务证书时，功能可能会与某些云提供商所需的主机名覆盖一起中断。 |
|
||||
| 1.2.16 | 确保设置了准入控制插件 PodSecurityPolicy（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
|
||||
| 1.2.33 | 确保能根据需要设置 --encryption-provider-config 参数（手动） | 启用加密会改变恢复加密数据的方式。 |
|
||||
| 1.2.34 | 确保正确配置了加密提供程序（手动） | 启用加密会改变恢复加密数据的方式。 |
|
||||
| 4.2.6 | 确保 --protect-kernel-defaults 参数设置为 true（自动） | 在配置集群之前需要系统级别的配置，才能将此参数设置为 true。 |
|
||||
| 4.2.10 | 确保根据需要设置 --tls-cert-file 和 --tls-private-key-file 参数（自动） | 在生成服务证书时，功能可能会与某些云提供商所需的主机名覆盖一起中断。 |
|
||||
| 5.1.5 | 确保未主动使用默认 ServiceAccount。（自动） | Kubernetes 提供了要使用的默认 ServiceAccount。 |
|
||||
| 5.2.2 | 最小化需要共享主机进程 ID 命名空间的容器准入（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
|
||||
| 5.2.3 | 最小化需要共享主机 IPC 命名空间的容器准入（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
|
||||
| 5.2.4 | 最小化需要共享主机网络命名空间的容器准入（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
|
||||
| 5.2.5 | 使用 allowPrivilegeEscalation（自动）最小化容器的准入 | 启用 Pod 安全策略可能会导致应用意外失败。 |
|
||||
| 5.3.2 | 确保所有命名空间都定义了网络策略（自动） | 启用网络策略可以防止某些应用进行相互通信。 |
|
||||
| 5.6.4 | 确保不使用 Default 命名空间（自动） | Kubernetes 提供了一个 Default 命名空间。 |
|
||||
|
||||
### CIS Benchmark v1.5 不适用的测试
|
||||
|
||||
| 数字 | 描述 | 不适用的原因 |
|
||||
| ---------- | ------------- | --------- |
|
||||
| 1.1.1 | 确保 API Server pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 kube-apiserver 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.2 | 确保 API Server pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 kube-apiserver 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.3 | 确保 Controller Manager pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.4 | 确保 Controller Manager pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.5 | 确保 Scheduler pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.6 | 确保 Scheduler pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.7 | 确保 etcd pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 etcd 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.8 | 确保 etcd pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 etcd 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.13 | 确保 admin.conf 文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不会在节点上存储 kubernetes 的默认 kubeconfig 凭证文件。 |
|
||||
| 1.1.14 | 确保 admin.conf 文件所有权设置为 root:root（自动） | RKE 配置的集群不会在节点上存储 kubernetes 的默认 kubeconfig 凭证文件。 |
|
||||
| 1.1.15 | 确保 scheduler.conf 文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.16 | 确保 scheduler.conf 文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.17 | 确保 controller-manager.conf 文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.18 | 确保将 controller-manager.conf 文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.3.6 | 确保 RotateKubeletServerCertificate 参数设置为 true（自动） | RKE 配置的集群直接使用 RKE 处理证书轮换。 |
|
||||
| 4.1.1 | 确保 kubelet 服务文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 kubelet 服务的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 4.1.2 | 确保 kubelet 服务文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 kubelet 服务的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 4.1.9 | 确保 kubelet 配置文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 kubelet 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 4.1.10 | 确保 kubelet 配置文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 kubelet 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 4.2.12 | 确保 RotateKubeletServerCertificate 参数设置为 true（自动） | RKE 配置的集群直接使用 RKE 处理证书轮换。 |
|
||||
+96
@@ -0,0 +1,96 @@
|
||||
---
|
||||
title: 先决条件
|
||||
---
|
||||
|
||||
### 1. 设置许可证管理器和购买支持
|
||||
|
||||
首先，完成许可证管理器设置的[第一步](https://docs.aws.amazon.com/license-manager/latest/userguide/getting-started.html)。
|
||||
然后，转到 AWS Marketplace。找到 “Rancher Premium Support Billing Container Starter Pack”。最后，购买至少一项 Entitlement。
|
||||
|
||||
如果你已使用 “Rancher Setup” AWS Marketplace 产品安装了 Rancher，请跳至[步骤 4](#4-创建-oidc-提供程序)。
|
||||
|
||||
> **注意**：每项 Entitlement 都对一定数量的节点授予访问支持的权限。你可以后续根据需要购买更多许可证。
|
||||
|
||||
### 2. 创建 EKS 集群
|
||||
按照 [Rancher 文档](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md)创建 EKS 集群。进行到[安装 Rancher Helm Chart](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md#8-安装-rancher-helm-chart)（最后一步）时，**停止并返回此页面**。该集群需要满足以下要求：
|
||||
|
||||
- EKS 1.22 版本。
|
||||
- 集群中的每个节点都可以访问包含 Rancher 及其相关镜像的镜像仓库。
|
||||
- 集群中的每个节点都可以访问存储 CSP Adapter 的 ECR 仓库。
|
||||
- 集群中的每个节点都可以访问许可证管理器服务。
|
||||
- 集群中的每个节点都可以访问 STS 服务的全局端点。
|
||||
|
||||
### 3. 安装 Rancher
|
||||
|
||||
除了在 [Rancher 文档](../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md#8-安装-rancher-helm-chart)中指定的 Rancher 安装选项外，你还需要启用其它指标。
|
||||
你可以通过 Helm CLI 使用以下选项来完成：
|
||||
|
||||
```bash
|
||||
--set extraEnv\[0\].name="CATTLE_PROMETHEUS_METRICS" --set-string extraEnv\[0\].value=true
|
||||
```
|
||||
|
||||
你还可以使用 values.yaml，如下所示：
|
||||
|
||||
```yaml
|
||||
extraEnv:
|
||||
- name: "CATTLE_PROMETHEUS_METRICS"
|
||||
value: "true"
|
||||
```
|
||||
|
||||
你还需要安装 Rancher 2.6.7 或更高版本。
|
||||
|
||||
### 4. 创建 OIDC 提供程序
|
||||
|
||||
按照 [AWS 文档](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html)为上一节中指定的集群创建 OIDC 提供程序。
|
||||
|
||||
### 5. 创建 IAM 角色
|
||||
|
||||
CSP Adapter 需要 IAM 角色才能签入/签出 Entitlement。
|
||||
|
||||
首先，配置如下的信任策略。你需要将 `MY_AWS_ACC` 替换为你的 AWS 帐号，将 `MY_AWS_REGION` 替换为你的 AWS 区域，并将 `MY_OIDC_PROVIDER` 替换为你的 OIDC 提供商 ID：
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"Federated": "arn:aws:iam::${MY_AWS_ACC}:oidc-provider/oidc.eks.${MY_AWS_REGION}.amazonaws.com/id/${MY_OIDC_PROVIDER}"
|
||||
},
|
||||
"Action": "sts:AssumeRoleWithWebIdentity",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"oidc.eks.${MY_AWS_REGION}.amazonaws.com/id/${MY_OIDC_PROVIDER}:sub": "system:serviceaccount:cattle-csp-adapter-system:rancher-csp-adapter",
|
||||
"oidc.eks.${MY_AWS_REGION}.amazonaws.com/id/${MY_OIDC_PROVIDER}:aud": "sts.amazonaws.com"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
接下来，为具有以下权限的角色使用策略：
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "RancherCSPAdapterPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"license-manager:ListReceivedLicenses",
|
||||
"license-manager:CheckoutLicense",
|
||||
"license-manager:ExtendLicenseConsumption",
|
||||
"license-manager:CheckInLicense",
|
||||
"license-manager:GetLicense",
|
||||
"license-manager:GetLicenseUsage"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
保存角色的名称。稍后安装 CSP Adapter 时将需要它。
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: AWS Marketplace 集成
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace"/>
|
||||
</head>
|
||||
|
||||
## 概述
|
||||
|
||||
Rancher 提供与 AWS Marketplace 的集成，允许用户购买 SUSE 的支持合同。当你开始支持更多集群时，这种集成使你可以轻松调整支持需求。
|
||||
|
||||
## 限制
|
||||
|
||||
- 你必须运行 Rancher v2.6.7 或更高版本。
|
||||
- Rancher 的部署必须启用额外的指标。
|
||||
- Rancher 必须安装在 EKS 集群上。
|
||||
- 你必须通过 AWS Marketplace 购买至少一项 Rancher 支持的权限。
|
||||
- 你可能需要额外的设置来支持代理/离线用例。有关更多信息，请参阅[先决条件](adapter-requirements.md)。
|
||||
|
||||
## 如何使用
|
||||
|
||||
1. 完成[先决条件](adapter-requirements.md)。
|
||||
2. [安装 CSP Adapter](install-adapter.md)。
|
||||
|
||||
## 常见问题
|
||||
|
||||
**我以后可以购买对更多节点的支持吗？**
|
||||
|
||||
可以。只需转到你最初用于购买支持的 AWS Marketplace 条目并增加权限数量即可。
|
||||
|
||||
**我可以在同一个 AWS 账户中使用多个 Rancher 实例吗？**
|
||||
|
||||
可以。但是，Rancher 安装的每个集群都需要遵守先决条件。
|
||||
|
||||
此外，一个给定的权限一次只能由一个 Rancher 管理服务器使用。
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: 常见问题
|
||||
---
|
||||
|
||||
**安装 Adapter 后，Rancher 中出现一条横幅消息，上面写着 "AWS Marketplace Adapter: Unable to run the adapter, please check the adapter logs"**
|
||||
|
||||
此错误表示 Adapter 安装到集群中时发生了一个错误，导致它无法正确签入/签出许可证。
|
||||
|
||||
这通常是因为 IAM 角色设置不正确。请查看[先决条件](./adapter-requirements.md)并确认：
|
||||
|
||||
- 已创建一个 OIDC 提供程序，并且它已关联到运行 Rancher 的集群。
|
||||
- IAM 角色已配置为信任此 OIDC 提供程序。
|
||||
- IAM 角色至少具有策略中概述的权限。
|
||||
|
||||
如果上述所有配置均已正确配置，请联系支持寻求帮助。
|
||||
|
||||
**我看到一条横幅消息，上面写着 "AWS Marketplace Adapter: You have exceeded your licensed node count. At least x more license(s) are required in AWS to become compliant"**
|
||||
|
||||
此消息表明你没有足够的 Entitlement 来满足 Rancher 当前管理的节点数量。
|
||||
|
||||
请记住以下限制：
|
||||
|
||||
- 每个 Entitlement 仅对一定数量的节点有效。
|
||||
- 当前由 Rancher 管理的每个节点都计入你的总使用量（安装了集群 Rancher 的节点除外）。
|
||||
- 每个 Entitlement 最多可以被一个 Rancher 实例使用。例如，如果你的账户中有两个正在运行的 Rancher 实例（每个都安装在单独的 EKS 集群上），那么你至少需要两个 Entitlement。
|
||||
|
||||
你最近可能还卸载/重新安装了 Adapter。如果 Adapter 丢失了它当前管理的许可证的跟踪，则可能需要一个小时来解析许可证的实际状态。
|
||||
|
||||
+155
@@ -0,0 +1,155 @@
|
||||
---
|
||||
title: 安装 Adapter
|
||||
---
|
||||
|
||||
> **重要提示**：如果你尝试重新安装 Adapter，你可能会在长达一小时的时间内收到不合规的错误消息。
|
||||
|
||||
### Rancher 与 Adapter 的兼容性矩阵
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
不同版本的 CSP Adapter 依赖于特定 Rancher 版本的功能。
|
||||
为了成功部署和运行 Adapter，你需要确保 Adapter 版本与必要的 Rancher 版本对应。
|
||||
|
||||
:::
|
||||
|
||||
| Rancher 版本 | Adapter 版本 |
|
||||
|-----------------|:---------------:|
|
||||
| v2.7.0 | v2.0.0 |
|
||||
| v2.7.1 | v2.0.0 |
|
||||
| v2.7.2 | v2.0.1 |
|
||||
| v2.7.3 | v2.0.1 |
|
||||
| v2.7.4 | v2.0.1 |
|
||||
| v2.7.5 | v2.0.2 |
|
||||
|
||||
|
||||
### 1. 获取对 Local 集群的访问权限
|
||||
|
||||
> **注意**：只有管理员用户才能访问 Local 集群。因为 CSP Adapter 必须安装在 Local 集群中，所以此安装必须由管理员用户执行。
|
||||
|
||||
首先，单击 Local 集群并下载 kubeconfig 令牌。然后，使用下方的命令配置 CLI 以使用此新令牌，你需要将 `$TOKEN_PATH` 替换为文件系统上令牌的下载路径：
|
||||
|
||||
```bash
|
||||
export KUBECONFIG=$TOKEN_PATH
|
||||
```
|
||||
|
||||
### 2. 创建 Adapter 命名空间
|
||||
|
||||
创建要安装 Adapter 的命名空间：
|
||||
|
||||
```bash
|
||||
kubectl create ns cattle-csp-adapter-system
|
||||
```
|
||||
|
||||
### 3. 创建证书密文
|
||||
|
||||
Adapter 需要访问 Rancher 用来与 Rancher Server 通信的根 CA。有关 Rancher 支持的证书选项的更多信息，请参阅 [Chart 选项页面](../../../getting-started/installation-and-upgrade/installation-references/helm-chart-options.md)。
|
||||
|
||||
如果你的 Rancher 使用由公认的证书颁发机构（例如 Let's Encrypt）签发的证书，你可以跳到[步骤 4](#4-安装-chart)。
|
||||
|
||||
但是，如果你的 Rancher 使用了自定义证书（例如 Rancher 生成的证书或由私有证书颁发机构签发的证书），你需要为该 CA 提供 PEM 编码格式的证书以便 Adapter 可以与 Rancher 通信。
|
||||
|
||||
首先，检索 Rancher 正在使用的证书并将其放入名为 `ca-additional.pem` 的文件中。如果你使用 Rancher 生成的证书，你可以使用以下命令完成此操作：
|
||||
|
||||
```bash
|
||||
kubectl get secret tls-rancher -n cattle-system -o jsonpath="{.data.tls\.crt}" | base64 -d >> ca-additional.pem
|
||||
```
|
||||
|
||||
然后，创建一个使用此证书的密文：
|
||||
|
||||
```bash
|
||||
kubectl -n cattle-csp-adapter-system create secret generic tls-ca-additional --from-file=ca-additional.pem
|
||||
```
|
||||
|
||||
> **重要提示**：不要更改文件名或创建的密文的名称，否则可能会导致 Adapter 运行出错。
|
||||
|
||||
### 4. 安装 Chart
|
||||
|
||||
首先，使用以下命令添加 `rancher/charts` 仓库：
|
||||
|
||||
```bash
|
||||
helm repo add rancher-charts https://charts.rancher.io
|
||||
```
|
||||
|
||||
接下来，安装 CSP Adapter。你必须指定多个值，其中包括账号号码以及在先决条件中创建的角色的名称。
|
||||
|
||||
确保你的 CSP Adapter 版本与你正在运行的 Rancher 版本匹配，如[上文](#rancher-与-adapter-的兼容性矩阵)所述。
|
||||
|
||||
在下方的操作中，将 `$MY_ACC_NUM` 替换为你的 AWS 账号，将 `$MY_ROLE_NAME` 替换为先决条件中创建的角色的名称。此外，将 `$CSP_ADAPTER_VERSION` 替换为与[版本矩阵](#rancher-与-adapter-的兼容性矩阵)中的 Rancher 版本匹配的版本。
|
||||
|
||||
> **注意**：如果你使用 shell 变量，请不要使用引号。例如，MY_ACC_NUM=123456789012 可用，但 MY_ACC_NUM="123456789012" 将失败。
|
||||
|
||||
> **注意**：使用欧盟和英国的 AWS Marketplace 列表的账号需要额外指定 `--set image.repository=rancher/rancher-csp-adapter-eu` 选项。要查看你的账号在安装 Adapter 时是否需要此选项，请参阅 Marketplace 列表的使用说明。
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Let's Encrypt/可信的 CA">
|
||||
|
||||
```bash
|
||||
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter --namespace cattle-csp-adapter-system --set aws.enabled=true --set aws.roleName=$MY_ROLE_NAME --set-string aws.accountNumber=$MY_ACC_NUM --version $CSP_ADAPTER_VERSION
|
||||
```
|
||||
|
||||
|
||||
你也可以使用 `values.yaml` 并指定以下选项：
|
||||
|
||||
```yaml
|
||||
aws:
|
||||
enabled: true
|
||||
accountNumber: "$MY_ACC_NUM"
|
||||
roleName: $MY_ROLE_NAME
|
||||
```
|
||||
|
||||
> **注意**：账号需要像上面那样以字符串格式指定，否则安装会失败。
|
||||
|
||||
然后，使用以下命令安装 Adapter：
|
||||
|
||||
```bash
|
||||
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter -f values.yaml --version $CSP_ADAPTER_VERSION
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="私有 CA/Rancher 生成的证书">
|
||||
|
||||
```bash
|
||||
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter --namespace cattle-csp-adapter-system --set aws.enabled=true --set aws.roleName=$MY_ROLE_NAME --set-string aws.accountNumber=$MY_ACC_NUM --set additionalTrustedCAs=true --version $CSP_ADAPTER_VERSION
|
||||
```
|
||||
|
||||
你也可以使用 `values.yaml` 并指定以下选项：
|
||||
|
||||
```yaml
|
||||
aws:
|
||||
enabled: true
|
||||
accountNumber: "$MY_ACC_NUM"
|
||||
roleName: $MY_ROLE_NAME
|
||||
additionalTrustedCAs: true
|
||||
```
|
||||
|
||||
> **注意**：账号需要像上面那样以字符串格式指定，否则安装会失败。
|
||||
|
||||
然后，使用以下命令安装 Adapter：
|
||||
|
||||
```bash
|
||||
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter -f values.yaml --version $CSP_ADAPTER_VERSION
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 5. 管理证书更新
|
||||
|
||||
如果你在[步骤 3](#3-创建证书密文) 中创建了一个用于存储自定义证书的密文，则随着证书的轮换，你将需要更新此密文。
|
||||
|
||||
首先，使用以下命令删除 cattle-csp-adapter-system 命名空间中的原始密文：
|
||||
|
||||
```bash
|
||||
kubectl delete secret tls-ca-additional -n cattle-csp-adapter-system
|
||||
```
|
||||
|
||||
然后，按照[步骤 3](#3-创建证书密文) 中的安装步骤，将密文的内容替换为更新后的值。
|
||||
|
||||
最后，重新启动 rancher-csp-adapter deployment 来确保更新后的值可供 Adapter 使用：
|
||||
|
||||
```bash
|
||||
kubectl rollout restart deploy rancher-csp-adapter -n cattle-csp-adapter-system
|
||||
```
|
||||
|
||||
> **注意**：有一些方法（例如 cert-manager 的 [trust operator](https://cert-manager.io/docs/projects/trust/)）可以帮助你减少手动轮换任务的数量。这些选项不受官方支持，但可能对想要自动化某些任务的用户有用。
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: 卸载 Adapter
|
||||
---
|
||||
|
||||
### 1. 使用 Helm 卸载 Adapter Chart：
|
||||
|
||||
```bash
|
||||
helm uninstall rancher-csp-adapter -n cattle-csp-adapter-system
|
||||
```
|
||||
|
||||
### 2. 删除为 Adapter 创建的命名空间：
|
||||
|
||||
```bash
|
||||
kubectl delete ns cattle-csp-adapter-system
|
||||
```
|
||||
|
||||
### 3. （可选）删除未完成的用户通知：
|
||||
|
||||
```bash
|
||||
kubectl delete RancherUserNotification csp-compliance
|
||||
```
|
||||
+11
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: 云市场集成
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/cloud-marketplace"/>
|
||||
</head>
|
||||
|
||||
Rancher 提供与云市场的集成，以便轻松购买对托管在某些云提供商上的安装支持。此外，此集成还提供了生成 Supportconfig Bundle 的功能，该 Bundle 可以给 rancher 提供支持。
|
||||
|
||||
此集成仅支持 AWS。
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: Supportconfig Bundle
|
||||
---
|
||||
|
||||
安装 CSP Adapter 后，你将能够生成一个 Supportconfig Bundle。此 Bundle 是一个 tar 包，可用于快速提供支持信息。
|
||||
|
||||
你可以通过 Rancher 或通过直接访问安装 Rancher 的集群来创建这些 Bundle。请注意，建议通过 Rancher 访问。
|
||||
|
||||
> **注意**：无论采用何种方法，只有管理员可以生成/下载 Supportconfig Bundle。
|
||||
|
||||
### 通过 Rancher 访问
|
||||
|
||||
首先，点击汉堡菜单。然后单击 `Get Support` 按钮。
|
||||
|
||||
|
||||
|
||||
在下一页中，单击 `Generate Support Config` 按钮。
|
||||
|
||||
> **注意**：如果未安装 Adapter ，则不会出现生成 Supportconfig Bundle 的选项。你必须安装 CSP Adapter 才能生成 Supportconfig Bundle。
|
||||
|
||||
|
||||
|
||||
### 不通过 Rancher 进行访问
|
||||
|
||||
首先，为安装 Rancher 的集群生成 kubeconfig。
|
||||
|
||||
> **注意**：如果 Rancher 宕机，你将无法使用 Rancher 生成的 kubeconfig 令牌访问集群。
|
||||
|
||||
配置你的 shell 环境以使用此 kubeconfig 令牌：
|
||||
|
||||
```bash
|
||||
export KUBECONFIG=$MY_KUBECONFIG_PATH
|
||||
```
|
||||
|
||||
建议在运行此命令时创建一个临时工作目录，如下所示：
|
||||
|
||||
```bash
|
||||
mkdir temp && cd temp
|
||||
```
|
||||
|
||||
然后，检索 Supportconfig Bundle：
|
||||
|
||||
```bash
|
||||
mkdir rancher && kubectl get configmap csp-config -n cattle-csp-adapter-system -o=jsonpath='{.data.data}' >> rancher/config.json && tar -c -f supportconfig_rancher.tar rancher && rm -rf rancher
|
||||
```
|
||||
|
||||
这将在你的当前目录中创建一个 `supportconfig_rancher.tar` 文件。
|
||||
|
||||
由于 gnu-tar 和 bsd-tar 不兼容，在 Mac 上运行这些命令的用户可能会遇到问题。如果支持部门在读取你制作的 Supportconfig 时出现问题，你可以先尝试在你的路径上将 gnu-tar 作为 `gtar` 进行访问，然后运行以下命令：
|
||||
|
||||
```bash
|
||||
mkdir rancher && kubectl get configmap csp-config -n cattle-csp-adapter-system -o=jsonpath='{.data.data}' >> rancher/config.json && gtar -c -f supportconfig_rancher.tar rancher && rm -rf rancher
|
||||
```
|
||||
+14
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Cluster API (CAPI) 与 Rancher Turtles
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/cluster-api"/>
|
||||
</head>
|
||||
|
||||
[Rancher Turtles](https://turtles.docs.rancher.com/) 是一个 [Rancher 扩展](../rancher-extensions.md)，通过提供 Cluster API (CAPI) 和 Rancher 之间的集成来管理配置的 Kubernetes 集群的生命周期。使用 Rancher Turtles，你可以：
|
||||
|
||||
- 通过在 CAPI 配置的集群中安装 Rancher Cluster Agent，将 CAPI 集群导入 Rancher。
|
||||
- 配置 [CAPI Operator](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values#cluster-api-operator-values)。
|
||||
|
||||
[概述](./overview.md)部分介绍了安装选项、Rancher Turtles 架构和简要 Demo。有关详细信息，请参阅 [Rancher Turtles 文档](https://turtles.docs.rancher.com/)。
|
||||
+260
@@ -0,0 +1,260 @@
|
||||
---
|
||||
title: 概述
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/cluster-api/overview"/>
|
||||
</head>
|
||||
|
||||
## 架构图
|
||||
|
||||
下面是 Rancher Turtles 的关键组件及其与 Rancher 和 Rancher Cluster Agent 的关系的架构图，了解这些组件对于深入了解 Rancher 如何利用 CAPI operator 进行集群管理至关重要。
|
||||
|
||||
|
||||
|
||||
## 安全
|
||||
|
||||
[SLSA](https://slsa.dev/spec/v1.0/about) 是一套由行业共识制定的可逐步采用的供应链安全指南。SLSA 制定的规范对软件生产者和消费者都很有用：生产者可以遵循 SLSA 的指导方针，使他们的软件供应链更加安全，消费者可以使用 SLSA 来决定是否信任软件包。
|
||||
|
||||
Rancher Turtles 满足 [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3) 对适当的构建平台、一致的构建过程和来源分布的要求。更多信息请参阅 [Rancher Turtles 安全](https://turtles.docs.rancher.com/security/slsa)文档。
|
||||
|
||||
## 先决条件
|
||||
|
||||
在 Rancher 环境中安装 Rancher Turtles 之前，你必须禁用 Rancher 的 `embedded-cluster-api` 功能。这还包括清理 Rancher 专用的 webhook，否则这些 webhook 将与 CAPI 的 webhook 冲突。
|
||||
|
||||
为了简化 Rancher 安装 Rancher Turtles 的设置，官方的 Rancher Turtles Helm chart 包含一个删除以下内容的 `pre-install` hook：
|
||||
|
||||
- 禁用 Rancher 中的 `embedded-cluster-api` 功能。
|
||||
- 删除不再需要的 `mutating-webhook-configuration` 和 `validating-webhook-configuration` webhook。
|
||||
|
||||
这些 webhook 也可以通过 Rancher UI 删除：
|
||||
|
||||
1. 点击左上角 **☰ > 集群管理**。
|
||||
1. 选择你的 local 集群。
|
||||
1. 在左侧导航菜单，选择 **More Resources** > **Admission**。
|
||||
1. 在下拉菜单中，选择资源页面的 `MutatingWebhookConfiguration` 和 `ValidatingWebhookConfiguration`。
|
||||
1. 在相应的资源页面上，点击 `mutating-webhook-configuration` and `validating-webhook-configuration` 后面的 **⋮** 然后选择 **删除**。
|
||||
|
||||
还可以通过在 **Resource Search** 字段中输入 webhook 的名称来访问到具体的 webhook。
|
||||
|
||||
以下的 `kubectl` 命令可以手动删除必要的 webhook：
|
||||
|
||||
```console
|
||||
kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io mutating-webhook-configuration
|
||||
```
|
||||
|
||||
```console
|
||||
kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io validating-webhook-configuration
|
||||
```
|
||||
|
||||
使用以下示例从控制台禁用 `embedded-cluster-api` 功能：
|
||||
|
||||
1. 创建一个 `feature.yaml` 文件，将 `embedded-cluster-api` 设置为 false：
|
||||
|
||||
```yaml title="feature.yaml"
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: Feature
|
||||
metadata:
|
||||
name: embedded-cluster-api
|
||||
spec:
|
||||
value: false
|
||||
```
|
||||
|
||||
2. 使用 `kubectl` 将 `feature.yaml` 文件应用到集群：
|
||||
|
||||
```bash
|
||||
kubectl apply -f feature.yaml
|
||||
```
|
||||
|
||||
## 安装 Rancher Turtles Operator
|
||||
|
||||
你可以通过 Rancher UI 或使用 Helm 安装 Rancher Turtles operator。对于大多数环境推荐使用第一种方法。
|
||||
|
||||
:::caution
|
||||
|
||||
如果你的集群中已经安装了 Cluster API (CAPI) Operator，你必须使用[手动 Helm 安装方法](#通过-helm-安装)。
|
||||
|
||||
:::
|
||||
|
||||
### 通过 Rancher UI 安装
|
||||
|
||||
通过 Rancher UI 添加 Turtles 仓库，Rancher 可以处理 CAPI 扩展的安装和配置。
|
||||
|
||||
1. 点击 **☰**。在左侧导航栏**浏览集群**的菜单下，选择 **local**。
|
||||
1. 在 **Cluster Dashboard** 的左侧导航菜单中，点击 **Apps > Repositories**。
|
||||
1. 点击 **Create** 创建一个新的仓库。
|
||||
1. 输入以下信息：
|
||||
- **Name**: turtles
|
||||
- **Index URL**: https://rancher.github.io/turtles
|
||||
1. 等待新的仓库状态更新为 `Active`。
|
||||
1. 在左侧导航菜单中，点击 **Apps > Charts**。
|
||||
1. 在搜索过滤器中输入 "turtles" 来查找 Turtles chart。
|
||||
1. 点击 **Rancher Turtles - the Cluster API Extension**。
|
||||
1. 点击 **Install > Next > Install**.
|
||||
|
||||
此过程使用 Helm chart 的默认值，这些值适用于大部分的安装场景。如果你的配置需要覆盖其中一些默认值，你可以在安装期间通过 Rancher UI 指定这些值，也可以通过 [Helm 手动安装 Chart](#通过-helm-安装)。有关可用的 values 设置的详细信息，请参阅 Rancher Turtles 的 [Helm chart 参考指南](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values)。
|
||||
|
||||
安装可能需要几分钟时间，安装完成后，你可以在集群中看到以下新部署：
|
||||
|
||||
- `rancher-turtles-system/rancher-turtles-controller-manager`
|
||||
- `rancher-turtles-system/rancher-turtles-cluster-api-operator`
|
||||
- `capi-system/capi-controller-manager`
|
||||
|
||||
#### Demo
|
||||
|
||||
这个 demo 演示了如何使用 Rancher UI 安装 Rancher Turtles、创建/导入一个 CAPI 集群，以及在集群上安装监控：
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/lGsr7KfBjgU?si=ORkzuAJjcdXUXMxh" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
|
||||
|
||||
### 通过 Helm 安装
|
||||
|
||||
通过 Helm 安装 Rancher Turtles 有两种方法，这取决于你是否将 CAPI operator 作为依赖项包含其中：
|
||||
|
||||
- [使用 CAPI Operator 作为依赖项安装 Rancher Turtles](#使用-cluster-api-capi-operator-作为-helm-依赖项安装-rancher-turtles)。
|
||||
- [安装没有 CAPI Operator 的 Rancher Turtles](#不使用-cluster-api-capi-operator-作为-helm-依赖安装-rancher-turtles)。
|
||||
|
||||
安装 Rancher Turtles 需要 CAPI Operator。你可以选择自己处理此依赖项，还是让 Rancher Turtles Helm chart 替你管理它。[使用 CAPI Operator 作为依赖项安装 Rancher Turtles](#使用-cluster-api-capi-operator-作为-helm-依赖项安装-rancher-turtles) 更简单，但是你的最佳选择取决于你的具体配置。
|
||||
|
||||
CAPI Operator 允许使用声明式方法处理 CAPI provider 的生命周期，扩展了 `clusterctl` 的能力。如果你想了解更多相关内容，可以参考 [Cluster API Operator book](https://cluster-api-operator.sigs.k8s.io/)。
|
||||
|
||||
#### 使用 `Cluster API (CAPI) Operator` 作为 Helm 依赖项安装 Rancher Turtles
|
||||
|
||||
1. 添加包含 `rancher-turtles` chart 的 Helm 仓库作为安装的第一步：
|
||||
|
||||
```bash
|
||||
helm repo add turtles https://rancher.github.io/turtles
|
||||
helm repo update
|
||||
```
|
||||
|
||||
2. 如前面所述，安装 Rancher Turtles 需要 [CAPI Operator](https://github.com/kubernetes-sigs/cluster-api-operator)。Helm chart 可以使用一组最少的参数自动安装：
|
||||
|
||||
```bash
|
||||
helm install rancher-turtles turtles/rancher-turtles --version <version> \
|
||||
-n rancher-turtles-system \
|
||||
--dependency-update \
|
||||
--create-namespace --wait \
|
||||
--timeout 180s
|
||||
```
|
||||
|
||||
3. 此操作可能需要几分钟时间，完成后，你可以查看下面列出的已安装的控制器：
|
||||
|
||||
- `rancher-turtles-controller`
|
||||
- `capi-operator`
|
||||
|
||||
:::note
|
||||
|
||||
- 如果集群中已经有可用的 `cert-manager`，请在安装时通过以下参数将 Rancher Turtles 的此项依赖禁用掉，来阻止冲突：
|
||||
`--set cluster-api-operator.cert-manager.enabled=false`
|
||||
- 有关 Rancher Turtles 的版本列表，请参阅 [Turtles 发布页面](https://github.com/rancher/turtles/releases)。
|
||||
|
||||
:::
|
||||
|
||||
这是最基本的推荐配置，用于管理在核心提供商的命名空间中创建包含所需 CAPI 功能标志（已启用 `CLUSTER_TOPOLOGY`, `EXP_CLUSTER_RESOURCE_SET` 和 `EXP_MACHINE_POOL` ）的 secret。要启用其他 CAPI 功能需要启用上述功能标志。
|
||||
|
||||
如果你需要覆盖默认的行为并使用现有 secret 或添加自定义环境变量，你可以将 secret 名称通过 Helm 参数传入。在这种情况下，你作为负责管理 secret 创建和内容的用户，需要启用的最少特性包括：`CLUSTER_TOPOLOGY`, `EXP_CLUSTER_RESOURCE_SET` 和 `EXP_MACHINE_POOL`。
|
||||
|
||||
```bash
|
||||
helm install ...
|
||||
# Passing secret name and namespace for additional environment variables
|
||||
--set cluster-api-operator.cluster-api.configSecret.name=<secret-name>
|
||||
```
|
||||
|
||||
以下是一个用户管理 secret `cluster-api-operator.cluster-api.configSecret.name=variables` 的示例，其中设置了 `CLUSTER_TOPOLOGY`, `EXP_CLUSTER_RESOURCE_SET` 和 `EXP_MACHINE_POOL` 功能以及一个额外的自定义变量：
|
||||
|
||||
```yaml title="secret.yaml"
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: variables
|
||||
namespace: rancher-turtles-system
|
||||
type: Opaque
|
||||
stringData:
|
||||
CLUSTER_TOPOLOGY: "true"
|
||||
EXP_CLUSTER_RESOURCE_SET: "true"
|
||||
EXP_MACHINE_POOL: "true"
|
||||
CUSTOM_ENV_VAR: "false"
|
||||
```
|
||||
|
||||
:::info
|
||||
|
||||
有关 chart 支持的 values 及其用法的详细信息，请参阅 [Helm chart 选项](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values)
|
||||
|
||||
:::
|
||||
|
||||
#### 不使用 `Cluster API (CAPI) Operator` 作为 Helm 依赖安装 Rancher Turtles
|
||||
|
||||
:::note
|
||||
|
||||
请记住，如果使用此安装选项，你必须自行管理 CAPI Operator 的安装。你可以参照 Rancher Turtles 文档中的 [CAPI Operator 指南](https://turtles.docs.rancher.com/tasks/capi-operator/intro)
|
||||
|
||||
:::
|
||||
|
||||
1. 添加包含 `rancher-turtles` chart 的 Helm 仓库作为安装的第一步：
|
||||
|
||||
```bash
|
||||
helm repo add turtles https://rancher.github.io/turtles
|
||||
helm repo update
|
||||
```
|
||||
|
||||
2. 将 chart 安装到 `rancher-turtles-system` 命名空间：
|
||||
|
||||
```bash
|
||||
helm install rancher-turtles turtles/rancher-turtles --version <version>
|
||||
-n rancher-turtles-system
|
||||
--set cluster-api-operator.enabled=false
|
||||
--set cluster-api-operator.cluster-api.enabled=false
|
||||
--create-namespace --wait
|
||||
--dependency-update
|
||||
```
|
||||
|
||||
前面的命令告诉 Helm 忽略将 `cluster-api-operator` 作为依赖项安装。
|
||||
|
||||
3. 此操作可能需要几分钟，完成后你可以查看下面列出的已安装的控制器：
|
||||
|
||||
- `rancher-turtles-controller`
|
||||
|
||||
## 卸载 Rancher Turtles
|
||||
|
||||
:::caution
|
||||
|
||||
在 Rancher 环境中安装 Rancher Turtles 时，Rancher Turtles 默认会启用 CAPI Operator 清理。这包括清理 CAPI Operator 特定的 webhook 和 deployments，否则会导致 Rancher 配置出现问题。
|
||||
|
||||
为了简化 Rancher Turtles 卸载（通过 Rancher 或 Helm 命令），官方的 Rancher Turtles Helm chart 包含了一个删除以下内容的 `post-delete` hook：
|
||||
|
||||
- 删除不再需要的 `mutating-webhook-configuration` 和 `validating-webhook-configuration` webhook。
|
||||
- 删除不再需要的 CAPI `deployments`。
|
||||
|
||||
:::
|
||||
|
||||
卸载 Rancher Turtles：
|
||||
|
||||
```bash
|
||||
helm uninstall -n rancher-turtles-system rancher-turtles --cascade foreground --wait
|
||||
```
|
||||
|
||||
这可能需要几分钟才能完成。
|
||||
|
||||
:::note
|
||||
|
||||
请记住，如果你在安装时使用了不同的名称或不同的命名空间，你需要针对你的特定配置自定义卸载命令。
|
||||
|
||||
:::
|
||||
|
||||
卸载 Rancher Turtles 后， Rancher 的 `embedded-cluster-api` 功能必须重新启用。
|
||||
|
||||
1. 创建一个 `feature.yaml` 文件，将 `embedded-cluster-api` 设置为 true：
|
||||
|
||||
```yaml title="feature.yaml"
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: Feature
|
||||
metadata:
|
||||
name: embedded-cluster-api
|
||||
spec:
|
||||
value: true
|
||||
```
|
||||
|
||||
2. 使用 `kubectl` 将 `feature.yaml` 文件应用到集群：
|
||||
|
||||
```bash
|
||||
kubectl apply -f feature.yaml
|
||||
```
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: 使用 Elemental 进行操作系统管理
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/elemental"/>
|
||||
</head>
|
||||
|
||||
Elemental 支持云原生主机管理。Elemental 允许你在任何位置装载任何机器，无论是在数据中心还是在边缘，并将它们无缝集成到 Kubernetes 中，同时管理你的工作流程（例如操作系统更新）。
|
||||
|
||||
## Elemental 和 Rancher
|
||||
|
||||
Rancher 中的 Elemental：
|
||||
|
||||
- 是 Kubernetes 原生的，它允许你通过 Kubernetes 集群中的 Elemental 管理操作系统。
|
||||
- 从 Kubernetes 的操作角度来看，不会造成干扰。
|
||||
- 是声明性的，并且 GitOps 友好。
|
||||
- 允许可信的、确定性的和可预测的 OCI Image-based flows。
|
||||
- 大规模运作。它支持 Fleet 规模的操作系统管理。
|
||||
|
||||
### 我什么时候应该使用 Elemental？
|
||||
|
||||
- Elemental 通过 Rancher manager 实现云原生操作系统管理。它适用于任何操作系统（例如，SLE Micro vanilla）。
|
||||
- Elemental 允许对数据中心和边缘的机器进行云原生管理。
|
||||
- Elemental 非常灵活，允许平台团队在其机器群中执行各种工作流。
|
||||
|
||||
## Elemental 和 Rancher Prime
|
||||
|
||||
- 已作为 GUI 扩展深度集成到 Rancher 中。
|
||||
- 将 Rancher 的用例扩展到操作系统，如今 SLE Micro 与 Rancher 可以完美配合。
|
||||
+8
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: 架构
|
||||
---
|
||||
|
||||
Fleet 可以管理来自 Git 的原始 Kubernetes YAML、Helm Chart、Kustomize 或三者的任何组合的部署。无论来源如何，所有资源都会动态转化为 Helm Chart，Helm 会用作引擎来将所有资源部署到集群中。这给了你高度的控制、一致性和可审计性。Fleet 不仅关注扩展能力，而且还提供高度的控制和可见性，从而让用户准确了解集群上安装的内容。
|
||||
|
||||
|
||||
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: 在代理后使用 Fleet
|
||||
---
|
||||
|
||||
在本节中，你将学习如何在一个设置中启用 Fleet，该设置有一个具有公共 IP 的 Rancher Server，以及一个没有公共 IP 但配置为使用代理的 Kubernetes 集群。
|
||||
|
||||
Rancher 不会与已注册的下游集群建立连接。部署在下游集群上的 Rancher agent 必须能够与 Rancher 建立连接。
|
||||
|
||||
要让 Fleet 在代理后工作，你需要为下游集群设置 **Agent 环境变量**。以下是集群级别的配置选项。
|
||||
|
||||
你可以通过 Rancher UI 为任何集群类型（包括注册集群和自定义集群）配置这些环境变量。可以在编辑现有集群或配置新集群时添加变量。
|
||||
|
||||
对于公共下游集群，[在 Rancher UI 中设置必要的环境变量](#在-rancher-ui-中设置环境变量)就足够了。
|
||||
|
||||
对于私有节点或私有集群，则需要在节点上设置环境变量。然后，在配置自定义集群或注册私有集群时，在 Rancher UI 中配置环境变量。有关如何在 K3s Kubernetes 集群中的 Ubuntu 节点上设置环境变量的示例，请参阅[本节](#在私有节点上设置环境变量)。
|
||||
|
||||
## 必要的环境变量
|
||||
|
||||
为代理添加 Fleet agent 环境变量时，将 <PROXY_IP> 替换为你的私有代理 IP。
|
||||
|
||||
| 变量名称 | 值 |
|
||||
|------------------|--------|
|
||||
| `HTTP_PROXY` | http://<PROXY_IP>:8888 |
|
||||
| `HTTPS_PROXY` | http://<PROXY_IP>:8888 |
|
||||
| `NO_PROXY` | 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local |
|
||||
|
||||
## 在 Rancher UI 中设置环境变量
|
||||
|
||||
要将环境变量添加到现有集群：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到要添加环境变量的集群，然后单击 **⋮ > 编辑配置**。
|
||||
1. 单击**高级选项**。
|
||||
1. 单击**添加环境变量**。
|
||||
1. 输入[必要的环境变量](#必要的环境变量)
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：Fleet agent 会在代理后工作。
|
||||
|
||||
## 在私有节点上设置环境变量
|
||||
|
||||
对于私有节点和私有集群，代理环境变量需要在节点本身上设置，以及从 Rancher UI 配置。
|
||||
|
||||
此示例显示了如何在 K3s Kubernetes 集群中的 Ubuntu 节点上设置环境变量：
|
||||
|
||||
```
|
||||
ssh -o ForwardAgent=yes ubuntu@<public_proxy_ip>
|
||||
ssh <k3s_ip>
|
||||
export proxy_private_ip=<private_proxy_ip>
|
||||
export HTTP_PROXY=http://${proxy_private_ip}:8888
|
||||
export HTTPS_PROXY=http://${proxy_private_ip}:8888
|
||||
export NO_PROXY=127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
|
||||
```
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Windows 支持
|
||||
---
|
||||
|
||||
在 Rancher 2.5.6 之前，`agent` 在具有 Windows 节点的下游集群上没有原生的 Windows 清单。这将导致集群的 `agent` pod 失败。
|
||||
|
||||
如果你从旧版本的 Rancher 升级到 2.5.6+，你可以在*下游集群*中部署具有以下工作流的工作 `agent`：
|
||||
|
||||
1. 封锁所有 Windows 节点。
|
||||
1. 对 `agent` 工作负载应用以下容忍度。
|
||||
1. 取消所有 Windows 节点的封锁。
|
||||
1. 删除所有 `agent` pod。使用新的容忍度来创建新 pod。
|
||||
1. `agent` pod 运行并为 Fleet 启用了自动更新后，它们会更新到与 Windows 兼容的 `agent` 版本。
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: cattle.io/os
|
||||
operator: Equal
|
||||
value: linux
|
||||
```
|
||||
+11
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: 架构
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/fleet/architecture"/>
|
||||
</head>
|
||||
|
||||
Fleet 可以管理来自 Git 的原始 Kubernetes YAML、Helm Chart、Kustomize 或三者的任何组合的部署。无论来源如何，所有资源都会动态转化为 Helm Chart，并使用 Helm 作为引擎来部署到集群中的所有内容。这为你提供了高度的控制力、一致性和可审计性。Fleet 不仅关注扩展能力，而且还提供高度的控制和可见性，从而让用户准确了解集群上安装的内容。
|
||||
|
||||
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: 使用 Fleet 进行持续交付
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/fleet"/>
|
||||
</head>
|
||||
|
||||
Fleet 通过集群 Fleet 的供应链协调和管理应用程序的持续交付。Fleet 使用 GitOps 作为一种安全的运营模式，组织供应链，帮助团队及时自信地交付。
|
||||
|
||||
## Fleet 和 Rancher
|
||||
|
||||
许多用户经常同时管理 10 个以上的集群。鉴于集群的激增，持续交付是 Rancher 的重要组成部分。Fleet 使用 GitOps 确保可靠的持续交付体验，这是一种安全且越来越常见的运营模式。
|
||||
|
||||
### 我什么时候应该使用 Fleet?
|
||||
|
||||
- 我需要跨地理区域部署我的监控堆栈（例如 Grafana、Prometheus），每个区域都有不同的保留策略。
|
||||
- 我是一名平台运营商，希望使用可扩展且安全的操作模型（GitOps）为集群配置所有组件。
|
||||
- 我是一名应用程序开发人员，希望我的最新更改自动进入我的开发环境。
|
||||
|
||||
## Fleet 和 Rancher Prime
|
||||
|
||||
Fleet 已经作为持续交付工具和 GitOps 引擎深度集成到 Rancher 中。
|
||||
|
||||
<!--
|
||||
- In future, we can have additional value adds like sharding controller (Manage shards for user) or notification controller (Event dispatcher/receiver) for prime customer only.
|
||||
-->
|
||||
+67
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: 概述
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/fleet/overview"/>
|
||||
</head>
|
||||
|
||||
使用 Fleet 进行持续交付是大规模的 GitOps。Fleet 旨在管理多达一百万个集群。它也足够轻量级，对于[单个集群](https://fleet.rancher.io/installation#default-install)也很有效，但当你达到[大规模](https://fleet.rancher.io/installation#configuration-for-multi-cluster)时，它真的会大放异彩。大规模是指单个组织中的大量集群、大量部署或大量团队。
|
||||
|
||||
Fleet 是 Rancher 的一个独立项目，可以通过 Helm 安装在任何 Kubernetes 集群上。
|
||||
|
||||
## 架构
|
||||
|
||||
有关 Fleet 如何运作的信息，请参阅[架构](./architecture)页面。
|
||||
|
||||
## 在 Rancher UI 中访问 Fleet
|
||||
|
||||
Fleet 预安装在 Rancher 中，并由 Rancher UI 中的**持续交付**选项进行管理。有关持续交付和其他 Fleet 故障排除技巧的更多信息，请参阅[此处](https://fleet.rancher.io/troubleshooting)。
|
||||
|
||||
用户可以按照 **gitops** 实践，利用持续交付将应用程序部署到 git 仓库中的 Kubernetes 集群，而无需任何手动操作。
|
||||
|
||||
按照以下步骤在 Rancher UI 中访问持续交付：
|
||||
|
||||
1. 单击 **☰ > 持续交付**。
|
||||
|
||||
1. 在菜单顶部选择命名空间 ，注意以下事项：
|
||||
|
||||
- 默认情况下，选择 **fleet-default**，包括通过 Rancher 注册的所有下游集群。
|
||||
|
||||
- 你可以切换到 **fleet-local**，它仅包含 **local** 集群，或者你可以创建自己的工作空间，将集群分配和移动到其中。
|
||||
|
||||
- 然后，你可以通过单击左侧导航栏上的**集群**来管理集群。
|
||||
|
||||
1. 单击左侧导航栏上的 **Gitrepos**，将 gitrepo 部署到当前工作空间的集群中。
|
||||
|
||||
1. 选择 [git 仓库](https://fleet.rancher.io/gitrepo-add)和[目标集群/集群组](https://fleet.rancher.io/gitrepo-targets)。你也可以通过单击左侧导航栏中的**集群组**在 UI 中创建集群组。
|
||||
|
||||
1. 部署 gitrepo 后，你可以通过 Rancher UI 监控应用程序。
|
||||
|
||||
## Windows 支持
|
||||
|
||||
有关对具有 Windows 节点的集群的支持的详细信息，请参阅 [Windows 支持](./windows-support)页面。
|
||||
|
||||
## GitHub 仓库
|
||||
|
||||
Fleet Helm charts 可在[此处](https://github.com/rancher/fleet/releases)获取。
|
||||
|
||||
## 在代理后使用 Fleet
|
||||
|
||||
有关在代理后面使用 Fleet 的详细信息，请参阅[在代理后使用 Fleet](./use-fleet-behind-a-proxy) 页面。
|
||||
|
||||
## Helm Chart 依赖
|
||||
|
||||
为了成功部署具有依赖项的 Helm Chart，你必须运行一个手动命令（如下所示），因为用户需要满足依赖列表。如果不执行此操作，继续克隆你的仓库并运行 `helm install`，则会因依赖项丢失而导致安装失败。
|
||||
|
||||
git 仓库中的 Helm Chart 必须在 Chart 子目录中包含其依赖。 你必须手动运行 `helm dependencies update $chart` 或在本地运行 `helm dependencies build $chart`，然后将完整的 Chart 目录提交到 git 仓库。请注意，你需要使用适当的参数更新你的命令。
|
||||
|
||||
## 故障排除
|
||||
|
||||
- **已知问题**：Fleet gitrepos 的 clientSecretName 和 helmSecretName 密文不包含在 [backup-restore-operator](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md#1-install-the-rancher-backup-operator) 创建的备份或恢复中。一旦有永久的解决方案，我们将更新社区内容。
|
||||
|
||||
- **临时解决方法**：默认情况下，用户定义的密文不会在 Fleet 中备份。如果执行灾难恢复或将 Rancher 迁移到新集群，则有必要重新创建密文。要修改 ResourceSet 以包含要备份的额外资源，请参阅文档[此处](https://github.com/rancher/backup-restore-operator#user-flow)。
|
||||
|
||||
## 文档
|
||||
|
||||
Fleet 文档位于 https://fleet.rancher.io/ 。
|
||||
+58
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: 在代理后使用 Fleet
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/fleet/use-fleet-behind-a-proxy"/>
|
||||
</head>
|
||||
|
||||
在本节中，你将学习如何在具有公共 IP 的 Rancher 服务器，以及一个没有公共 IP 但配置为使用代理的 Kubernetes 集群的设置中启用 Fleet。
|
||||
|
||||
Rancher 不会与已注册的下游集群建立连接。部署在下游集群上的 Rancher agent 必须能够与 Rancher 建立连接。
|
||||
|
||||
要让 Fleet 在代理后工作，你需要为下游集群设置 **Agent 环境变量**。以下是集群级别的配置选项。
|
||||
|
||||
你可以通过 Rancher UI 为任何集群类型（包括注册集群和自定义集群）配置这些环境变量。可以在编辑现有集群或配置新集群时添加变量。
|
||||
|
||||
对于公共下游集群，[在 Rancher UI 中设置必要的环境变量](#在-rancher-ui-中设置环境变量)就足够了。
|
||||
|
||||
对于私有节点或私有集群，则需要在节点上设置环境变量。然后，在配置自定义集群或注册私有集群时，在 Rancher UI 中配置环境变量。有关如何在 K3s 集群中的 Ubuntu 节点上设置环境变量的示例，请参阅[本节](#在私有节点上设置环境变量)。
|
||||
|
||||
## 必要的环境变量
|
||||
|
||||
为代理添加 Fleet agent 环境变量时，将 <PROXY_IP> 替换为你的私有代理 IP。
|
||||
|
||||
| 变量名称 | 值 |
|
||||
| ------------- | ----------------------------------------------------------------------- |
|
||||
| `HTTP_PROXY` | http://<PROXY_IP>:8888 |
|
||||
| `HTTPS_PROXY` | http://<PROXY_IP>:8888 |
|
||||
| `NO_PROXY` | 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local |
|
||||
|
||||
## 在 Rancher UI 中设置环境变量
|
||||
|
||||
要将环境变量添加到现有集群：
|
||||
|
||||
1. 单击 **☰ > 集群管理**。
|
||||
1. 转到要添加环境变量的集群，然后单击 **⋮ > 编辑配置**。
|
||||
1. 单击**高级选项**。
|
||||
1. 单击**添加环境变量**。
|
||||
1. 输入[必要的环境变量](#必要的环境变量)
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果：** Fleet agent 会在代理后工作。
|
||||
|
||||
## 在私有节点上设置环境变量
|
||||
|
||||
对于私有节点和私有集群，需要在节点本身上设置代理环境变量，并在 Rancher UI 中进行配置。
|
||||
|
||||
此示例显示了如何在 K3s 集群中的 Ubuntu 节点上设置环境变量：
|
||||
|
||||
```
|
||||
ssh -o ForwardAgent=yes ubuntu@<public_proxy_ip>
|
||||
ssh <k3s_ip>
|
||||
export proxy_private_ip=<private_proxy_ip>
|
||||
export HTTP_PROXY=http://${proxy_private_ip}:8888
|
||||
export HTTPS_PROXY=http://${proxy_private_ip}:8888
|
||||
export NO_PROXY=127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
|
||||
```
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Windows 支持
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/fleet/windows-support"/>
|
||||
</head>
|
||||
|
||||
在 Rancher v2.5.6 之前，`agent` 在具有 Windows 节点的下游集群上没有原生的 Windows 清单。这将导致集群的 `agent` pod 运行失败。
|
||||
|
||||
如果你从旧版本的 Rancher 升级到 v2.5.6+，你可以在 _下游集群_ 中部署具有以下工作流的可运行的 `agent`：
|
||||
|
||||
1. 封锁所有 Windows 节点。
|
||||
1. 对 `agent` 工作负载应用以下容忍度。
|
||||
1. 取消所有 Windows 节点的封锁。
|
||||
1. 删除所有 `agent` pod。使用新的容忍度来创建新 pod。
|
||||
1. 一旦 `agent` pod 运行，并且 Fleet 的自动更新已启用，它们会更新到兼容 Windows 的 `agent` 版本。
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: cattle.io/os
|
||||
operator: Equal
|
||||
value: linux
|
||||
```
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: Harvester 集成
|
||||
---
|
||||
|
||||
Harvester 是 Rancher 2.6.1 新增的功能，[Harvester](https://docs.harvesterhci.io/) 是基于 Kubernetes 构建的开源超融合基础架构 (HCI) 软件。Harvester 安装在裸金属服务器上，提供集成的虚拟化和分布式存储功能。虽然 Harvester 使用 Kubernetes 运行，但它不需要用户了解 Kubernetes 概念，因此是一个更加用户友好的应用。
|
||||
|
||||
### 功能开关
|
||||
|
||||
你可以使用 Harvester 的功能开关来管理 Harvester 在 Rancher 虚拟化管理页面的访问，用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。Harvester 的功能开关是默认启用的。如需了解 Rancher 中功能开关的更多详细信息，请单击[此处](../pages-for-subheaders/enable-experimental-features.md)。
|
||||
|
||||
要导航到 Harvester 集群，请单击 **☰ > 虚拟化管理**。在 **Harvester 集群**页面中，单击集群以转到该 Harvester 集群的视图。
|
||||
|
||||
* 如果启用了 Harvester 功能开关，则会从列出 Kubernetes 集群的任何页面或应用（例如 Fleet 和多集群应用）中过滤掉 Harvester 集群。
|
||||
|
||||
* 如果禁用了 Harvester 功能开关，并且导入了 Harvester 集群，Harvester 集群将显示在**集群管理**页面的 Rancher 集群列表中。仅当功能开关为关闭时，Harvester 集群才会显示在集群列表中。
|
||||
|
||||
* 集成 Harvester 后，你可以将 Harvester 集群导入 Rancher，对应的集群类型是 `Harvester`。
|
||||
|
||||
* 用户只能在**虚拟化管理**页面上导入 Harvester 集群。在**集群管理**页面上导入集群是不支持的，而且会出现警告。建议你返回**虚拟化管理**页面执行此操作。
|
||||
|
||||
### Harvester 主机驱动
|
||||
|
||||
[Harvester 主机驱动](https://docs.harvesterhci.io/v1.1/rancher/node/node-driver/) 通常可用于 Rancher 中的 RKE 和 RKE2 选项。无论 Harvester 功能开关是否启用，主机驱动都是可用的。请注意，默认情况下主机驱动是关闭的。用户只能通过**集群管理**页面在 Harvester 上创建 RKE 或 RKE2 集群。
|
||||
|
||||
Harvester 允许通过 Harvester UI 上传和显示 `.ISO` 镜像，但 Rancher UI 不支持。这是因为 `.ISO` 镜像通常需要额外的设置，这会干扰干净的部署（即无需用户干预），并且它们通常不用于云环境。
|
||||
|
||||
如需了解 Rancher 中主机驱动的更多详细信息，请单击[此处](../pages-for-subheaders/about-provisioning-drivers.md#主机驱动)。
|
||||
|
||||
### 端口要求
|
||||
|
||||
可以在[此处](https://docs.harvesterhci.io/v1.1/install/requirements#networking)找到 Harvester 集群的端口要求。
|
||||
|
||||
此外，其他网络注意事项如下：
|
||||
|
||||
- 请务必为 VM VLAN 网络启用物理交换机的 VLAN 中继端口。
|
||||
- 按照[此处](https://docs.harvesterhci.io/v1.1/networking/clusternetwork)的网络设置指南进行操作。
|
||||
|
||||
对于其他集群（例如 K3s 和 RKE1）的其他端口要求，请参阅[这些文档](https://docs.harvesterhci.io/v1.1/install/requirements/#guest-clusters)。
|
||||
|
||||
### 限制
|
||||
|
||||
---
|
||||
**仅适用于 Rancher v2.6.1 和 v2.6.2**：
|
||||
|
||||
- Harvester 0.3.0 不支持离线环境安装。
|
||||
- 不支持将 Harvester 0.2.0 升级到 0.3.0，也不支持升级到新的 1.0.0 版本。
|
||||
|
||||
---
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: 使用 Harvester 在 Kubernetes 上进行虚拟化
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/harvester"/>
|
||||
</head>
|
||||
|
||||
## Harvester
|
||||
|
||||
Harvester 是 Rancher v2.6.1 新增的功能，是基于 Kubernetes 构建的开源超融合基础架构（HCI）软件。Harvester 安装在裸金属服务器上，提供集成的虚拟化和分布式存储功能。虽然 Harvester 使用 Kubernetes 运行，但它不需要用户了解 Kubernetes 概念，这使得它更加用户友好。
|
||||
|
||||
## Harvester 与 Rancher
|
||||
|
||||
凭借 Rancher Prime 和 Harvester，IT 运维人员现在可以访问一个企业级的、易于使用的基础设施平台，该平台可以协同管理他们的虚拟机和 Kubernetes 集群。有关产品支持的更多信息，请参阅[支持矩阵](https://www.suse.com/suse-harvester/support-matrix/all-supported-versions/harvester-v1-2-0/)。通过 Rancher 虚拟化管理功能，用户可以导入和管理多个 Harvester 集群。利用 Rancher 的认证功能和 RBAC 控制来支持多租户。
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: 概述
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/harvester/overview"/>
|
||||
</head>
|
||||
|
||||
[Harvester](https://docs.harvesterhci.io/) 是 Rancher v2.6.1 新增的功能，是基于 Kubernetes 构建的开源超融合基础架构（HCI）软件。Harvester 安装在裸金属服务器上，提供集成的虚拟化和分布式存储功能。虽然 Harvester 使用 Kubernetes 运行，但它不需要用户了解 Kubernetes 概念，这使得它更加用户友好。
|
||||
|
||||
### 功能开关
|
||||
|
||||
Harvester 功能开关用于管理对 Rancher 中虚拟化管理（VM）页面的访问，用户可以直接导航到 Harvester 集群并访问 Harvester UI。Harvester 的功能开关默认启用。如需了解 Rancher 中功能开关的更多详细信息，请单击[此处](../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。
|
||||
|
||||
要导航到 Harvester 集群，请单击 **☰ > 虚拟化管理**。在 Harvester 集群页面中，单击集群以转到该 Harvester 集群的视图。
|
||||
|
||||
- 如果启用了 Harvester 功能开关，Harvester 集群将会从列出 Kubernetes 集群的任何页面或应用（例如 Fleet 和多集群应用）中过滤掉。
|
||||
|
||||
- 如果禁用了 Harvester 功能开关，并且导入了 Harvester 集群，Harvester 集群将显示在集群管理页面的 Rancher 集群列表中。仅当功能开关为关闭时，Harvester 集群才会显示在集群列表中。
|
||||
|
||||
- 集成 Harvester 后，你可以将 Harvester 集群导入 Rancher，对应的集群类型是 `Harvester`。
|
||||
|
||||
- 用户只能在虚拟化管理页面上导入 Harvester 集群。不支持在集群管理页面上导入集群，并且会出现警告，建议你返回虚拟化管理页面执行此操作。
|
||||
|
||||
### Harvester 主机驱动
|
||||
|
||||
[Harvester 主机驱动](https://docs.harvesterhci.io/v1.1/rancher/node/node-driver/)通常可用于 Rancher 中的 RKE 和 RKE2 选项。无论 Harvester 功能开关是否启用，主机驱动都是可用的。请注意，主机驱动默认处于关闭状态。用户只能通过集群管理页面在 Harvester 上创建 RKE 或 RKE2 集群。
|
||||
|
||||
Harvester 允许通过 Harvester UI 上传和显示 `.ISO` 镜像，但 Rancher UI 是不支持的。这是因为 `.ISO` 镜像通常需要额外的设置，这会干扰干净的部署（即无需用户干预），并且它们通常不用于云环境。
|
||||
|
||||
如需了解 Rancher 中主机驱动的更多详细信息，请单击[此处](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/about-provisioning-drivers#主机驱动)。
|
||||
|
||||
### 端口要求
|
||||
|
||||
Harvester 集群的端口要求可以在[此处](https://docs.harvesterhci.io/v1.1/install/requirements#networking)找到。
|
||||
|
||||
此外，其他网络注意事项如下：
|
||||
|
||||
- 请务必为 VM VLAN 网络启用物理交换机的 VLAN 中继端口。
|
||||
- 按照[此处](https://docs.harvesterhci.io/v1.1/networking/index)的网络设置指南进行操作。
|
||||
|
||||
对于其他集群（例如 K3s 和 RKE1）的其他端口要求，请参阅[这些文档](https://docs.harvesterhci.io/v1.1/install/requirements/#guest-clusters)。
|
||||
+51
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Rancher 中的集成
|
||||
---
|
||||
|
||||
<head>
|
||||
<link
|
||||
rel="canonical"
|
||||
href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher"
|
||||
/>
|
||||
</head>
|
||||
|
||||
import { Card, CardSection } from "@site/src/components/CardComponents";
|
||||
import { RocketRegular } from "@fluentui/react-icons";
|
||||
|
||||
Prime 是 Rancher 生态系统的企业级产品，具有更高的安全性、更长的生命周期和对 Prime 专有文档的访问权限。Rancher Prime 安装资产托管在受信任的 SUSE 注册表上，由 Rancher 拥有和管理。受信任的 Prime 注册表仅包括经过社区测试的稳定版本。
|
||||
|
||||
Prime 还提供生产支持选项，以及根据你的商业需求定制的订阅附加组件。
|
||||
|
||||
要了解更多信息并开始使用 Rancher Prime，请访问[本页](https://www.rancher.com/quick-start)。
|
||||
|
||||
<CardSection id="Gettingstarted" icon={<RocketRegular />}>
|
||||
<Card
|
||||
title="Kubernetes 发行版"
|
||||
to="./integrations-in-rancher/kubernetes-distributions"
|
||||
/>
|
||||
<Card
|
||||
title="使用 Harvester 在 Kubernetes 上进行虚拟化"
|
||||
to="./integrations-in-rancher/harvester"
|
||||
/>
|
||||
<Card
|
||||
title="使用 Longhorn 进行云原生存储"
|
||||
to="./integrations-in-rancher/longhorn"
|
||||
/>
|
||||
<Card
|
||||
title="使用 NeuVector 实现容器安全"
|
||||
to="./integrations-in-rancher/neuvector"
|
||||
/>
|
||||
<Card
|
||||
title="使用 Kubewalden 进行高级策略管理"
|
||||
to="./integrations-in-rancher/kubewarden"
|
||||
/>
|
||||
<Card
|
||||
title="使用 Elemental 进行操作系统管理"
|
||||
to="./integrations-in-rancher/elemental"
|
||||
/>
|
||||
<Card title="使用 Fleet 进行持续交付" to="./integrations-in-rancher/fleet" />
|
||||
<Card
|
||||
title="桌面上的 Kubernetes"
|
||||
to="./integrations-in-rancher/rancher-desktop"
|
||||
/>
|
||||
</CardSection>
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: 配置选项
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/istio/configuration-options"/>
|
||||
</head>
|
||||
|
||||
### Egress 支持
|
||||
|
||||
默认情况下，Egress 网关是禁用的，但你可以在安装或升级时使用 values.yaml 或[覆盖文件](#覆盖文件)启用它。
|
||||
|
||||
### 启用自动 Sidecar 注入
|
||||
|
||||
默认情况下，自动 sidecar 注入是禁用的。要启用此功能，请在安装或升级时在 values.yaml 中设置 `sidecarInjectorWebhook.enableNamespacesByDefault=true`。这会自动将 Istio sidecar 注入到所有已部署的新命名空间。
|
||||
|
||||
### 覆盖文件
|
||||
|
||||
覆盖文件用于为 Istio 进行更广泛的配置。它允许你更改 [IstioOperator API](https://istio.io/latest/docs/reference/config/istio.operator.v1alpha1/) 中可用的任何值。你可以自定义默认安装以满足你的需求。
|
||||
|
||||
覆盖文件将在 Istio Chart 默认安装的基础上添加配置。换言之，你不需要为安装中已定义的组件进行重新定义。
|
||||
|
||||
有关覆盖文件的更多信息，请参阅 [Istio 文档](https://istio.io/latest/docs/setup/install/istioctl/#configure-component-settings)
|
||||
|
||||
### 选择器和抓取配置
|
||||
|
||||
Monitoring 应用设置了 `prometheus.prometheusSpec.ignoreNamespaceSelectors=false`，即在默认情况下跨所有命名空间进行监控。这样，你可以查看部署在具有 `istio-injection=enabled` 标签的命名空间中的资源的流量、指标和图。
|
||||
|
||||
如果你想将 Prometheus 限制为特定的命名空间，请设置 `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`。完成此操作后，你需要添加其他配置来继续监控你的资源。
|
||||
|
||||
详情请参阅[本节](selectors-and-scrape-configurations.md)。
|
||||
|
||||
### 在具有 Pod 安全策略的情况下启用 Istio
|
||||
|
||||
详情请参阅[本节](pod-security-policies.md)。
|
||||
|
||||
### 在 RKE2 集群上安装 Istio 的其他步骤
|
||||
|
||||
详情请参阅[本节](install-istio-on-rke2-cluster.md)。
|
||||
|
||||
### 项目网络隔离的其他步骤
|
||||
|
||||
详情请参阅[本节](project-network-isolation.md)。
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: 在 RKE2 和 K3s 集群上安装 Istio 的其他步骤
|
||||
---
|
||||
|
||||
通过 **Apps** 页面安装或升级 Istio Helm Chart 时：
|
||||
|
||||
1. 如果要安装 Chart，请单击**在安装前自定义 Helm 选项**，然后单击**下一步**。
|
||||
1. 你将看到配置 Istio Helm Chart 的选项。在**组件**选项卡上，选中**启用 CNI** 旁边的框。
|
||||
1. 添加一个自定义覆盖文件，该文件指定 `cniBinDir` 和 `cniConfDir`。有关这些选项的更多信息，请参阅 [Istio 文档](https://istio.io/latest/docs/setup/additional-setup/cni/#helm-chart-parameters)。下方是一个示例：
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
```yaml
|
||||
apiVersion: install.istio.io/v1alpha1
|
||||
kind: IstioOperator
|
||||
spec:
|
||||
components:
|
||||
cni:
|
||||
enabled: true
|
||||
k8s:
|
||||
overlays:
|
||||
- apiVersion: "apps/v1"
|
||||
kind: "DaemonSet"
|
||||
name: "istio-cni-node"
|
||||
patches:
|
||||
- path: spec.template.spec.containers.[name:install-cni].securityContext.privileged
|
||||
value: true
|
||||
values:
|
||||
cni:
|
||||
cniBinDir: /opt/cni/bin
|
||||
cniConfDir: /etc/cni/net.d
|
||||
```
|
||||
</TabItem>
|
||||
<TabItem value="K3s">
|
||||
|
||||
```yaml
|
||||
apiVersion: install.istio.io/v1alpha1
|
||||
kind: IstioOperator
|
||||
spec:
|
||||
components:
|
||||
cni:
|
||||
enabled: true
|
||||
k8s:
|
||||
overlays:
|
||||
- apiVersion: "apps/v1"
|
||||
kind: "DaemonSet"
|
||||
name: "istio-cni-node"
|
||||
patches:
|
||||
- path: spec.template.spec.containers.[name:install-cni].securityContext.privileged
|
||||
value: true
|
||||
values:
|
||||
cni:
|
||||
cniBinDir: /var/lib/rancher/k3s/data/current/bin
|
||||
cniConfDir: /var/lib/rancher/k3s/agent/etc/cni/net.d
|
||||
```
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**结果**：现在你应该可以根据需要使用 Istio，包括 Sidecar 注入和通过 Kiali 进行监控。
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: 在具有 Pod 安全策略的情况下启用 Istio
|
||||
---
|
||||
|
||||
如果你启用了限制性 Pod 安全策略（Pod Security Policy），由于 Istio 需要某些权限才能自行安装和管理 pod 基础设施，因此 Istio 可能无法正常运行。在本文中，我们将配置一个为 Istio 启用了 PSP 的集群，并设置 Istio CNI 插件。
|
||||
|
||||
Istio CNI 插件不再要求每个应用 pod 具有特权 `NET_ADMIN` 容器。如需更多信息，请参阅 [Istio CNI 插件文档](https://istio.io/docs/setup/additional-setup/cni)。请注意，[Istio CNI 插件处于 alpha 阶段](https://istio.io/about/feature-stages/)。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
- 集群必须是 RKE Kubernetes 集群。
|
||||
- 必须使用默认 PodSecurityPolicy 创建集群。
|
||||
|
||||
要在使用 Rancher UI 创建 Kubernetes 集群时启用 Pod 安全策略支持，请转到<b>高级选项</b>。在 <b>Pod 安全策略支持</b>中，单击<b>启用</b>，然后选择一个默认的 pod 安全策略。
|
||||
|
||||
:::
|
||||
|
||||
1. [将 PodSecurityPolicy 设置为不受限制](#1-将-podsecuritypolicy-设置为不受限制)
|
||||
2. [启用 CNI](#2-启用-cni)
|
||||
3. [验证 CNI 是否正常工作](#3-验证-cni-是否正常工作)
|
||||
|
||||
### 1. 将 PodSecurityPolicy 设置为不受限制
|
||||
|
||||
不受限制的 PSP 支持安装 Istio。
|
||||
|
||||
在安装 Istio 的项目或计划安装 Istio 的项目中，将 PSP 设置为 `unrestricted`。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 找到**项目: System**，然后选择 **⋮ > 编辑配置**。
|
||||
1. 将 Pod 安全策略选项更改为不受限制，然后单击**保存**。
|
||||
|
||||
### 2. 启用 CNI
|
||||
|
||||
通过 **Apps** 安装或升级 Istio 时：
|
||||
|
||||
1. 单击**组件**。
|
||||
2. 选中**启用 CNI**旁边的框。
|
||||
3. 完成 Istio 的安装或升级。
|
||||
|
||||
你也可以通过编辑 `values.yaml` 来启用 CNI：
|
||||
|
||||
```
|
||||
istio_cni.enabled: true
|
||||
```
|
||||
|
||||
在集群中启用 CNI 后，Istio 应该能成功安装。
|
||||
|
||||
### 3. 验证 CNI 是否正常工作
|
||||
|
||||
通过部署[示例应用](https://istio.io/latest/docs/examples/bookinfo/)或部署你自己的应用，来验证 CNI 是否正常工作。
|
||||
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: 项目网络隔离的其他步骤
|
||||
---
|
||||
|
||||
在集群中：
|
||||
|
||||
- 你同时使用了 Canal 网络插件与 Rancher 2.5.8 之前版本，或者同时使用了 Rancher 2.5.8+ 以及任意支持执行 Kubernetes 网络策略的 RKE 网络插件（例如 Canal 或 Cisco ACI 插件）。
|
||||
- 启用了项目网络隔离选项。
|
||||
- 安装了 Istio Ingress 模块。
|
||||
|
||||
默认情况下，Istio Ingress Gateway pod 无法将入口流量重定向到工作负载。这是因为安装了 Istio 的命名空间无法访问所有命名空间。为此你有两个选项。
|
||||
|
||||
第一个选项是在需要让 Istio 控制入口的每个命名空间中添加一个新的网络策略。你的策略需要包括以下几行：
|
||||
|
||||
```
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
app: istio-ingressgateway
|
||||
```
|
||||
|
||||
第二个选项是将 `istio-system` 命名空间移动到 `system` 项目中，默认情况下该项目被排除在网络隔离之外。
|
||||
+120
@@ -0,0 +1,120 @@
|
||||
---
|
||||
title: 选择器和抓取配置
|
||||
---
|
||||
|
||||
Monitoring 应用设置了 `prometheus.prometheusSpec.ignoreNamespaceSelectors=false`，即在默认情况下跨所有命名空间进行监控。
|
||||
|
||||
这样，你可以查看部署在具有 `istio-injection=enabled` 标签的命名空间中的资源的流量、指标和图。
|
||||
|
||||
如果你想将 Prometheus 限制为特定的命名空间，请设置 `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`。完成此操作后，你需要添加其他配置来继续监控你的资源。
|
||||
|
||||
|
||||
### 通过将 ignoreNamespaceSelectors 设置为 True 来限制对特定命名空间的监控
|
||||
|
||||
要限制对特定命名空间的监控，你需要编辑 `ignoreNamespaceSelectors` Helm Chart 选项。你可以在安装或升级 Monitoring Helm Chart 时配置此选项：
|
||||
|
||||
1. 安装或升级 Monitoring Helm Chart 时，编辑 values.yml 并设置 `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`。
|
||||
1. 完成安装或升级。
|
||||
|
||||
**结果**：Prometheus 将仅用于特定命名空间。换言之，你需要设置以下配置之一才能继续在各种仪表板中查看数据。
|
||||
|
||||
### 让 Prometheus 检测其他命名空间中的资源
|
||||
|
||||
如果设置了 `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`，则有两种方法让 Prometheus 检测其他命名空间中的资源：
|
||||
|
||||
- **监控特定的命名空间**：在命名空间中添加一个 ServiceMonitor 或 PodMonitor 以及要抓取的目标。
|
||||
- **跨命名空间监控**：将 `additionalScrapeConfig` 添加到你的 rancher-monitoring 实例，从而抓取所有命名空间中的所有目标。
|
||||
|
||||
### 监控特定命名空间：创建 ServiceMonitor 或 PodMonitor
|
||||
|
||||
此选项用于定义在特定命名空间中要监控的服务或 pod。
|
||||
|
||||
可用性权衡指的是，由于你无法跨命名空间进行监控，因此你必须为每个命名空间创建 ServiceMonitor 或 PodMonitor。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
为 `<your namespace>` 定义 ServiceMonitor 或 PodMonitor。下面提供了一个 ServiceMonitor 示例。
|
||||
|
||||
:::
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在顶部导航栏中，打开 kubectl shell。
|
||||
1. 如果 ServiceMonitor 或 PodMonitor 文件存储在本地集群中，请运行 `kubectl create -f <name of service/pod monitor file>.yaml`。
|
||||
1. 如果 ServiceMonitor 或 PodMonitor 没有存储在本地，请运行 `cat<< EOF | kubectl apply -f -`，将文件内容粘贴到终端，然后运行 `EOF` 来完成命令。
|
||||
1. 运行 `kubectl label namespace <your namespace> istio-injection=enabled` 来启用 Envoy sidecar 注入。
|
||||
|
||||
**结果**：Prometheus 可以抓取 `<your namespace>`。
|
||||
|
||||
<figcaption>Istio 代理的 ServiceMonitor 示例</figcaption>
|
||||
|
||||
```yaml
|
||||
apiVersion: monitoring.coreos.com/v1
|
||||
kind: ServiceMonitor
|
||||
metadata:
|
||||
name: envoy-stats-monitor
|
||||
namespace: istio-system
|
||||
labels:
|
||||
monitoring: istio-proxies
|
||||
spec:
|
||||
selector:
|
||||
matchExpressions:
|
||||
- {key: istio-prometheus-ignore, operator: DoesNotExist}
|
||||
namespaceSelector:
|
||||
any: true
|
||||
jobLabel: envoy-stats
|
||||
endpoints:
|
||||
- path: /stats/prometheus
|
||||
targetPort: 15090
|
||||
interval: 15s
|
||||
relabelings:
|
||||
- sourceLabels: [__meta_kubernetes_pod_container_port_name]
|
||||
action: keep
|
||||
regex: '.*-envoy-prom'
|
||||
- action: labeldrop
|
||||
regex: "__meta_kubernetes_pod_label_(.+)"
|
||||
- sourceLabels: [__meta_kubernetes_namespace]
|
||||
action: replace
|
||||
targetLabel: namespace
|
||||
- sourceLabels: [__meta_kubernetes_pod_name]
|
||||
action: replace
|
||||
targetLabel: pod_name
|
||||
```
|
||||
|
||||
### 跨命名空间监控：将 ignoreNamespaceSelectors 设置为 False
|
||||
|
||||
此设置为 Prometheus 提供额外的抓取配置来实现跨命名空间监控。
|
||||
|
||||
可用性权衡指的是 Prometheus 的所有 `additionalScrapeConfigs` 都维护在一个 Secret 中。如果在安装 Istio 之前已经使用 additionalScrapeConfigs 部署了监控，升级可能会变得困难。
|
||||
|
||||
1. 安装或升级 Monitoring Helm Chart 时，编辑 values.yml 并将 `prometheus.prometheusSpec.additionalScrapeConfigs` 数组设置为下方的**其它抓取配置**。
|
||||
1. 完成安装或升级。
|
||||
|
||||
**结果**：Promethe 会抓取所有带有 `istio-injection=enabled` 标签的命名空间。
|
||||
|
||||
<figcaption>其它抓取配置</figcaption>
|
||||
|
||||
```yaml
|
||||
- job_name: 'istio/envoy-stats'
|
||||
scrape_interval: 15s
|
||||
metrics_path: /stats/prometheus
|
||||
kubernetes_sd_configs:
|
||||
- role: pod
|
||||
relabel_configs:
|
||||
- source_labels: [__meta_kubernetes_pod_container_port_name]
|
||||
action: keep
|
||||
regex: '.*-envoy-prom'
|
||||
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
|
||||
action: replace
|
||||
regex: ([^:]+)(?::\d+)?;(\d+)
|
||||
replacement: $1:15090
|
||||
target_label: __address__
|
||||
- action: labelmap
|
||||
regex: __meta_kubernetes_pod_label_(.+)
|
||||
- source_labels: [__meta_kubernetes_namespace]
|
||||
action: replace
|
||||
target_label: namespace
|
||||
- source_labels: [__meta_kubernetes_pod_name]
|
||||
action: replace
|
||||
target_label: pod_name
|
||||
```
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: CPU 和内存分配
|
||||
---
|
||||
|
||||
本文介绍我们建议在集群中分配给 Istio 组件的最少计算资源。
|
||||
|
||||
每个组件的 CPU 和内存分配是[可配置](#配置资源分配)的。
|
||||
|
||||
在启用 Istio 之前，建议你先确认你的 Rancher worker 节点是否有足够的 CPU 和内存来运行 Istio 的所有组件。
|
||||
|
||||
:::tip
|
||||
|
||||
在规模较大的部署中，我们强烈建议通过为每个 Istio 组件添加节点选择器，来将基础设施放置在集群中的专用节点上。
|
||||
|
||||
:::
|
||||
|
||||
下表总结了每个核心 Istio 组件推荐配置的 CPU 和内存的最低资源请求和限制。
|
||||
|
||||
Kubernetes 中的资源请求指的是，除非该节点至少具有指定数量的可用内存和 CPU，否则工作负载不会部署在节点上。如果工作负载超过 CPU 或内存的限制，则可以将其从节点中终止或驱逐。有关管理容器资源限制的更多信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)。
|
||||
|
||||
| 工作负载 | CPU - 请求 | 内存 - 请求 | CPU - 限制 | 内存 - 限制 |
|
||||
|----------------------|---------------|------------|-----------------|-------------------|
|
||||
| 入口网关 | 100m | 128mi | 2000m | 1024mi |
|
||||
| 出口网关 | 100m | 128mi | 2000m | 1024mi |
|
||||
| istiod | 500m | 2048mi | 没有限制 | 没有限制 |
|
||||
| proxy | 10m | 10mi | 2000m | 1024mi |
|
||||
| **总计：** | **710m** | **2314Mi** | **6000m** | **3072Mi** |
|
||||
|
||||
## 配置资源分配
|
||||
|
||||
你可以为每种类型的 Istio 组件单独配置资源分配。本节介绍了每个组件默认分配的资源。
|
||||
|
||||
为了更轻松地将工作负载调度到节点，集群管理员可以降低组件的 CPU 和内存资源请求。默认 CPU 和内存分配是我们推荐的最小值。
|
||||
|
||||
关于 Istio 配置的更多信息，请参阅 [Istio 官方文档](https://istio.io/)。
|
||||
|
||||
要配置分配给 Istio 组件的资源：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，点击 **Apps**。
|
||||
1. 点击**已安装的应用**。
|
||||
1. 转到 `istio-system` 命名空间。在某个 Istio 工作负载中（例如 `rancher-istio`），点击**⋮ > 编辑/升级**。
|
||||
1. 点击**升级**，然后通过更改 values.yaml 或添加[覆盖文件](../../pages-for-subheaders/configuration-options.md#覆盖文件)来编辑基本组件。有关编辑覆盖文件的更多信息，请参阅[本节](cpu-and-memory-allocations.md#编辑覆盖文件)。
|
||||
1. 更改 CPU 或内存分配、调度各个组件的节点，或节点容忍度。
|
||||
1. 点击**升级**。然后，更改就能启用。
|
||||
|
||||
**结果**：已更新 Istio 组件的资源分配。
|
||||
|
||||
### 编辑覆盖文件
|
||||
|
||||
覆盖文件可以包含 [Istio Operator 规范](https://istio.io/latest/docs/reference/config/istio.operator.v1alpha1/#IstioOperatorSpec)中的任意值。包含 Istio 应用的覆盖文件只是覆盖文件潜在配置的一个示例。
|
||||
|
||||
只要文件包含 `kind: IstioOperator` 且 YAML 选项有效，文件就可以用作覆盖。
|
||||
|
||||
在 Istio 应用提供的示例覆盖文件中，以下部分能让你更改 Kubernetes 资源：
|
||||
|
||||
```
|
||||
# k8s:
|
||||
# resources:
|
||||
# requests:
|
||||
# cpu: 200m
|
||||
```
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: 禁用 Istio
|
||||
---
|
||||
|
||||
本文介绍如何在集群中卸载 Istio，以及如何在命名空间或工作负载中禁用 Istio。
|
||||
|
||||
## 在集群中卸载 Istio
|
||||
|
||||
要卸载 Istio：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **Apps > Installed Apps**。
|
||||
1. 在 `istio-system` 命名空间中，转到 `rancher-istio` 并单击 **⋮ > 删除**。
|
||||
1. 删除 `rancher-istio` 后，选择 `istio-system` 命名空间中所有剩余的应用，然后单击**删除**。
|
||||
|
||||
**结果**：已删除集群中的 `rancher-istio` 应用。Istio sidecar 不能部署在集群中的任何工作负载上。
|
||||
|
||||
:::note
|
||||
|
||||
你不能再禁用和重新启用你的 Istio 安装。如果你想保存设置以供将来的安装使用，请查看并保存各个 YAML，以便在之后的安装中参考/重复使用。
|
||||
|
||||
:::
|
||||
|
||||
**卸载疑难解答**：如果你没有按照卸载步骤操作，则可能会在卸载过程中遇到以下警告：
|
||||
|
||||
`Error: uninstallation completed with 1 error(s): unable to build kubernetes objects for delete: unable to recognize "": no matches for kind "MonitoringDashboard" in version "monitoring.kiali.io/v1alpha1"`
|
||||
|
||||
这可能意味着几种情况。第一种情况是你选择了 `istio-system` 命名空间中的所有应用并同时删除了它们，另一种情况是你在删除 `rancher-istio` Chart 之前删除了`rancher-istio` Chart 依赖项。由于卸载未正确完成，你将需要手动清理 `istio-system` 命名空间中剩余的资源。如果不想进行手动清理，你可以重新安装 `rancher-istio`，然后按照正确的顺序卸载它。
|
||||
|
||||
## 在命名空间中禁用 Istio
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 转到要启用 Istio 的命名空间，然后单击**⋮ > 启用 Istio 自动注入**。或者，你也可以单击命名空间，然后在命名空间详情页面上，单击**⋮ > 启用 Istio 自动注入**。
|
||||
|
||||
**结果**：如果工作负载部署到此命名空间，它们将没有 Istio sidecar。
|
||||
|
||||
## 从工作负载中移除 Istio Sidecar
|
||||
|
||||
在命名空间中禁用 Istio，然后重新部署其中的工作负载。这些工作负载将在没有 Istio sidecar 的情况下部署。
|
||||
+140
@@ -0,0 +1,140 @@
|
||||
---
|
||||
title: Istio
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/istio"/>
|
||||
</head>
|
||||
|
||||
[Istio](https://istio.io/) 是一种开源工具，可以让 DevOps 团队更轻松地观察、控制、排查并保护复杂的微服务网络中的流量。
|
||||
|
||||
随着微服务网络的变化和增长，微服务网络之间的交互变得越来越难以管理和理解。在这种情况下，将服务网格作为单独的基础设施层是非常有用的。Istio 的服务网格可以让你在不直接更改微服务的情况下控制微服务之间的流量。
|
||||
|
||||
Rancher 与 Istio 集成，使得管理员或集群所有者可以将 Istio 交给开发者团队，然后开发者使用 Istio 执行安全策略，排查问题，或为蓝绿部署，金丝雀部署，和 A/B 测试进行流量管理。
|
||||
|
||||
此核心服务网格支持但不限于以下功能：
|
||||
|
||||
- **管理流量**：例如入口和出口路由、断路、镜像。
|
||||
- **安全**：具有用于验证和授权流量和用户的资源，包括 mTLS。
|
||||
- **可观察性**：观察日志、指标和分布式流量。
|
||||
|
||||
[设置 Istio](../../how-to-guides/advanced-user-guides/istio-setup-guide/istio-setup-guide.md) 后，你可以通过 Rancher UI、`kubectl` 或 ` Istioctl` 来使用 Istio 的 controlplane 功能。
|
||||
|
||||
Istio 需要由 `cluster-admin` 设置后才能在项目中使用。
|
||||
|
||||
## Rancher 2.5 的新功能
|
||||
|
||||
Istio 已简化了整体架构。结合 Pilot、Citadel、Galley 和 sidecar injector 创建了一个单独的组件 Istiod。Node Agent 功能也已合并到 istio-agent 中。
|
||||
|
||||
以前由 Istio 安装的插件（cert-manager、Grafana、Jaeger、Kiali、Prometheus、Zipkin）现在需要单独安装。Istio 支持安装来自 Istio 项目的集成，并保持与非 Istio 项目的兼容性。
|
||||
|
||||
你仍然可以通过安装 [Rancher Monitoring](../monitoring-and-alerting/monitoring-and-alerting.md) 或安装你自己的 Prometheus operator 来使用 Prometheus 集成。Rancher 的 Istio chart 还默认安装 Kiali，确保你可以开箱即用地全面了解微服务。
|
||||
|
||||
Istio 已经脱离了使用 Helm 安装的方式，现在通过 Istioctl 二进制文件或 Istio Operator 进行安装。为了使用最简单的方式与 Istio 交互，Rancher 的 Istio 会维护一个 Helm Chart，该 Chart 使用 Istioctl 二进制文件来管理你的 Istio 安装。
|
||||
|
||||
此 Helm Chart 将在 UI 的**应用 & 市场**中提供。有权访问 Rancher Chart 应用商店的用户需要先设置 Istio，然后才能在项目中使用它。
|
||||
|
||||
## Istio 附带的工具
|
||||
|
||||
我们的 [Istio](https://istio.io/) 安装程序将 istioctl 二进制命令包装在一个 Helm chart 中，其中包括一个覆盖文件的选项，用来支持复杂的自定义配置。
|
||||
|
||||
它还包括以下内容：
|
||||
|
||||
### Kiali
|
||||
|
||||
Kiali 是一个全面的可视化辅助工具，用于绘制整个服务网格中的流量图。它允许你查看它们的连接方式，包括它们之间的流量速率和延迟。
|
||||
|
||||
你可以检查服务网格的运行状况，或深入查看单个组件的传入和传出请求。
|
||||
|
||||
### Jaeger
|
||||
|
||||
Jaeger 是用于跟踪分布式系统的工具。我们的 Istio 安装程序包括能快速启动的一体化 [Jaeger](https://www.jaegertracing.io/) 安装。
|
||||
|
||||
请注意，这不是符合 Jaeger 生产要求的部署。此部署使用在内存中的存储组件，而 Jaeger 推荐在生产环境中使用持久存储组件。有关你所需的部署策略的更多信息，请参阅 [Jaeger 文档](https://www.jaegertracing.io/docs/latest/operator/#production-strategy)。
|
||||
|
||||
## 先决条件
|
||||
|
||||
在启用 Istio 之前，建议你先确认你的 Rancher worker 节点是否有足够的 [CPU 和内存](cpu-and-memory-allocations.md)来运行 Istio 的所有组件。
|
||||
|
||||
如果要在 RKE2 集群上安装 Istio，则需要执行一些额外的步骤。有关详细信息，请参阅[本节](#在-rke2-集群上安装-istio-的其他步骤)
|
||||
|
||||
## 设置指南
|
||||
|
||||
如需了解如何设置 Istio 并在项目中使用它，请参阅[设置指南](../../how-to-guides/advanced-user-guides/istio-setup-guide/istio-setup-guide.md)。
|
||||
|
||||
## 卸载 Istio
|
||||
|
||||
要从集群、命名空间或工作负载中删除 Istio 组件，请参阅[卸载 Istio](disable-istio.md)。
|
||||
|
||||
## 访问可视化
|
||||
|
||||
> 默认情况下，只有 cluster-admin 可以访问 Kiali。有关如何允许具有管理员、编辑或查看权限的角色访问它们的说明，请参阅[本节](rbac-for-istio.md)。
|
||||
|
||||
在集群中设置 Istio 后，你可以在 Rancher UI 中使用 Grafana、Prometheus 和 Kiali。
|
||||
|
||||
要访问 Grafana 和 Prometheus 可视化：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
2. 在**集群**页面上，转到要可视化的集群，然后单击 **Explore**。
|
||||
3. 在左侧导航栏中，单击**监控**。
|
||||
4. 点击 **Grafana** 或任何其他仪表板。
|
||||
|
||||
要访问 Kiali 可视化：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
2. 在**集群**页面上，转到要查看 Kiali 的集群，然后单击 **Explore**。
|
||||
3. 在左侧导航栏中，单击 **Istio**。
|
||||
4. 单击 **Kiali**。从这里，你可以访问**流量图**或**流量指标**选项卡，从而可视化网络指标。
|
||||
|
||||
默认情况下，prometheus 会拾取所有命名空间，并将数据用于 Kiali 图。如果你想使用不同的配置进行 prometheus 数据抓取，请参阅[选择器/抓取配置](configuration-options/selectors-and-scrape-configurations.md)。
|
||||
|
||||
你的角色决定了你对可视化的访问。只有 `cluster-admin` 角色可以使用 Grafana 和 Prometheus。默认情况下，只有 `cluster-admin` 可以使用 Kiali UI，但是 `cluster-admin` 可以通过编辑 Istio values.yaml 来允许其他角色进行访问。
|
||||
|
||||
## 架构
|
||||
|
||||
Istio 安装了一个服务网格，它使用 [Envoy](https://www.envoyproxy.io) Sidecar 代理来拦截到每个工作负载的流量。这些 sidecar 拦截并管理服务之间的通信，从而实现精细化观察并控制集群内的流量。
|
||||
|
||||
只有注入了 Istio sidecar 的工作负载可以通过 Istio 进行跟踪和控制。
|
||||
|
||||
如果命名空间启用了 Istio，部署到命名空间的新工作负载会自动具有 Istio sidecar。你需要为之前的工作负载手动启用 Istio。
|
||||
|
||||
有关 Istio sidecar 的更多信息，请参阅 [Istio sidecare-injection 文档](https://istio.io/docs/setup/kubernetes/additional-setup/sidecar-injection/)。有关 Istio 架构的更多信息，请参阅 [Istio 架构文档](https://istio.io/latest/docs/ops/deployment/architecture/)。
|
||||
|
||||
### 多个 Ingress
|
||||
|
||||
默认情况下，每个 Rancher 配置的集群都有一个 NGINX Ingress Controller 来允许流量进入集群。Istio 还在 `istio-system` 命名空间中默认安装一个 Ingress Gateway。因此，你的集群将有两个 ingress。
|
||||
|
||||
|
||||
|
||||
可以通过[覆盖文件](configuration-options/configuration-options.md#覆盖文件)来启用其他 Istio Ingress Gateway。
|
||||
|
||||
### Egress 支持
|
||||
|
||||
默认情况下，Egress 网关是禁用的，但你可以在安装或升级时使用 values.yaml 或[覆盖文件](configuration-options/configuration-options.md#覆盖文件)启用它。
|
||||
|
||||
## 在 RKE2 集群上安装 Istio 的其他步骤
|
||||
|
||||
要在 RKE2 集群上安装 Istio，请按照[步骤](configuration-options/install-istio-on-rke2-cluster.md)进行操作。
|
||||
|
||||
## 在离线环境中升级 Istio
|
||||
|
||||
现在，Istio Pod 安全策略默认启用。新值 `installer.releaseMirror.enabled` 已添加到 rancher-istio Chart 中，以启用和禁用支持离线升级的 Server。请注意，`installer.releaseMirror.enabled` 默认设置为 `false`。你可以在安装或升级时根据需要设置该值。按照以下步骤执行：
|
||||
|
||||
1. 在 Rancher UI 中配置离线 Rancher 实例和离线自定义集群。
|
||||
2. 在集群中安装 Monitoring：**Cluster Explorer > Apps & Marketplace > Charts > Monitoring**。
|
||||
3. 将 Istio 所需的所有镜像拉入在离线环境中使用的私有镜像仓库。
|
||||
4. 在集群中安装 Istio：**Cluster Explorer > Apps & Marketplace > Charts > Istio**。
|
||||
|
||||
:::note
|
||||
|
||||
你可以在新安装的 Istio 上启用 [Jaeger](https://www.jaegertracing.io/) 和 [Kiali](https://kiali.io/)。为确保 Jaeger 和 Kiali 正常工作，请在安装期间将 `values.yaml` 中的 `installer.releaseMirror.enabled` 设置为 `true`。
|
||||
|
||||
:::
|
||||
|
||||
5. 升级 Istio。
|
||||
|
||||
:::caution
|
||||
|
||||
如果你还没有执行操作，请设置 `installer.releaseMirror.enabled=true` 以升级 Istio。
|
||||
|
||||
:::
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: RBAC
|
||||
---
|
||||
|
||||
本文介绍访问 Istio 功能所需的权限。
|
||||
|
||||
Rancher Istio Chart 安装了三个 `ClusterRole`。
|
||||
|
||||
## Cluster-Admin 访问
|
||||
|
||||
默认情况下，只有具有 `cluster-admin` `ClusterRole` 的用户可以：
|
||||
|
||||
- 在集群中安装 Istio 应用。
|
||||
- 为 Istio 配置资源分配。
|
||||
|
||||
|
||||
## Admin 和 Edit 权限
|
||||
|
||||
默认情况下，只有 Admin 和 Edit 角色可以：
|
||||
|
||||
- 为命名空间启用和禁用 Istio sidecar 自动注入。
|
||||
- 将 Istio sidecar 添加到工作负载。
|
||||
- 查看集群的流量指标和流量图。
|
||||
- 配置 Istio 的资源（例如网关、目标规则或虚拟服务）。
|
||||
|
||||
## Kubernetes 默认角色的默认权限摘要
|
||||
|
||||
Istio 创建了三个 `ClusterRole`，并将 Istio CRD 访问权限添加到以下默认 K8s `ClusterRole`：
|
||||
|
||||
| Chart 创建的 ClusterRole | 默认 K8s ClusterRole | Rancher 角色 |
|
||||
------------------------------:| ---------------------------:|---------:|
|
||||
| `istio-admin` | admin | 项目所有者 |
|
||||
| `istio-edit` | edit | 项目成员 |
|
||||
| `istio-view` | view | 只读 |
|
||||
|
||||
Rancher 将继续使用 cluster-owner、cluster-member、project-owner、project-member 等作为角色名称，但会使用默认角色来确定访问权限。每个默认的 K8s `ClusterRole` 都有不同的 Istio CRD 权限以及可以执行的 K8s 操作，包括 Create (C)，Get (G)，List (L)，Watch (W)，Update (U)，Patch (P)，Delete (D) 和 All (*)。
|
||||
|
||||
|
||||
| CRD | Admin | Edit | View |
|
||||
|----------------------------| ------| -----| -----
|
||||
| <ul><li>`config.istio.io`</li><ul><li>`adapters`</li><li>`attributemanifests`</li><li>`handlers`</li><li>`httpapispecbindings`</li><li>`httpapispecs`</li><li>`instances`</li><li>`quotaspecbindings`</li><li>`quotaspecs`</li><li>`rules`</li><li>`templates`</li></ul></ul> | GLW | GLW | GLW |
|
||||
| <ul><li>`networking.istio.io`</li><ul><li>`destinationrules`</li><li>`envoyfilters`</li><li>`gateways`</li><li>`serviceentries`</li><li>`sidecars`</li><li>`virtualservices`</li><li>`workloadentries`</li></ul></ul> | * | * | GLW |
|
||||
| <ul><li>`security.istio.io`</li><ul><li>`authorizationpolicies`</li><li>`peerauthentications`</li><li>`requestauthentications`</li></ul></ul> | * | * | GLW |
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: Kubernetes 发行版
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/kubernetes-distributions"/>
|
||||
</head>
|
||||
|
||||
## K3s
|
||||
|
||||
K3s 是一款轻量级、完全兼容的 Kubernetes 发行版，专为一系列用例设计，包括边缘计算、物联网、CI/CD、开发和将 Kubernetes 嵌入到应用程序中。它将系统打包为单个二进制文件，使用 sqlite3 作为默认存储，并提供用户友好的启动器，从而简化了 Kubernetes 的管理。K3s 包括 Local Storage 和负载均衡、Helm Chart 控制器和 Traefik CNI 等基本功能。它最大限度地减少了外部依赖，并提供了精简的 Kubernetes 体验。K3s 于 2020 年 6 月作为沙箱项目捐赠给 CNCF。
|
||||
|
||||
### K3s 与 Rancher
|
||||
|
||||
- Rancher 允许在一系列平台上轻松配置 K3s，包括 Amazon EC2、DigitalOcean、Azure、vSphere 或现有服务器。
|
||||
- Kubernetes 集群的标准 Rancher 管理，包括所有概述[集群管理功能](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup#cluster-management-capabilities-by-cluster-type)。
|
||||
|
||||
## RKE2
|
||||
|
||||
RKE2 是 Rancher 开发的一款兼容 Kubernetes 的发行版。它是专门为美国联邦政府部门的安全性和合规性而设计的。
|
||||
|
||||
RKE2 的主要特性包括:
|
||||
|
||||
1. **安全性和合规性重点**：RKE2 非常重视安全性和合规性，在“默认安全”框架下运行，适用于政府服务以及金融和医疗保健等高度监管的行业。
|
||||
1. **CIS Kubernetes Benchmark 一致性**：RKE2 经过预配置，符合 CIS Kubernetes Hardening Benchmark（目前支持 v1.23 和 v1.7），并且只需最少的手动干预。
|
||||
1. **FIPS 140-2 合规性**：RKE2 符合 FIPS 140-2 标准，使用经过 FIPS 验证的加密模块作为其组件。
|
||||
1. **嵌入式 ETCD**：RKE2 默认使用嵌入式 ETCD 作为其数据存储。这使其与标准的 Kubernetes 实践更加紧密地结合在一起，从而可以更好地与其他 Kubernetes 工具集成并降低错误配置的风险。
|
||||
1. **与上游 Kubernetes 保持一致**：RKE2 旨在与上游 Kubernetes 保持密切一致，降低在使用偏离标准 Kubernetes 实践的发行版时可能出现的不一致风险。
|
||||
1. **多重 CNI 支持**：RKE2 支持多个容器网络接口（CNI）插件，包括 Cilium、Calico 和 Multus。这对于具有各种生产设施的电信分发中心和工厂等用例至关重要。
|
||||
|
||||
## RKE2 与 Rancher
|
||||
|
||||
- Rancher 允许在一系列平台上轻松配置 RKE2，包括 Amazon EC2、DigitalOcean、Azure、vSphere 或现有服务器。
|
||||
- Kubernetes 集群的标准 Rancher 管理，包括所有概述[集群管理功能](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup#cluster-management-capabilities-by-cluster-type)。
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: 使用 Kubewarden 进行高级策略管理
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/kubewarden"/>
|
||||
</head>
|
||||
|
||||
Kubewarden 是一个策略引擎，用于保护和帮助管理集群资源。它允许通过策略验证和更改资源请求，包括上下文感知策略和验证镜像签名。它可以在监视或强制模式下运行策略，并提供集群状态的概述。
|
||||
|
||||
Kubewarden 旨在通过启用和简化“策略即代码”来成为通用策略引擎。Kubewarden 策略被编译到 WebAssembly 中：它们体积小（400KB~2MB），沙箱式，安全且便携。它旨在通过迎合组织中的每个人来实现通用性：
|
||||
|
||||
- 策略用户：使用 Kubernetes 自定义资源管理和声明策略，重新使用 Rego（OPA 和 Gatekeeper）中编写的现有策略。在 CI/CD 中测试群集外部的策略。
|
||||
- 策略开发人员：使用你喜欢的 Wasm 编译语言（Rego、Go、Rust、C#、Swift、Typescript 等）编写策略。重新使用你已经熟悉的工具、库和工作流的生态系统。
|
||||
- 策略分发器：策略是 OCI 工件，通过 OCI 仓库为它们提供服务，并在你的基础设施中使用行业标准，如 Software-Bill-Of-Materials 和工件签名。
|
||||
- 集群操作员：Kubewarden 是模块化的（OCI 注册表、PolicyServers、Audit Scanner、Controller）。配置你的部署以满足你的需求，隔离不同的租户。使用审核扫描程序和策略报告在集群中获取过去、当前和可能的违规行为的概述。
|
||||
- Kubewarden Integrator：将其用作编写新的 Kubewarden 模块和自定义策略的平台。
|
||||
|
||||
## Kubewarden 和 Rancher
|
||||
|
||||
Kubewarden 的上游 Helm Chart 完全集成为 Rancher 应用程序，为安装选项提供了 UI。这些 Chart 还附带了尊重 Rancher 堆栈的默认设置（例如：不监管 Rancher 系统命名空间）以及默认的 PolicyServer 和策略。用户可以访问所有 Kubewarden 功能，并可以通过与 Kubernetes API 交互（例如：使用 kubectl）手动部署 PolicyServer 和策略。
|
||||
|
||||
Kubewarden 提供了对已删除的 Kubernetes Pod 安全策略的完全替换。 Kubewarden 还通过增强其安全功能，与最新版本的 Kubernetes 引入的新 Pod Security Admission 功能进行了集成。
|
||||
|
||||
## Kubewarden 和 Rancher Prime
|
||||
|
||||
Kubewarden 的 Rancher UI 扩展将其集成到 Rancher UI 中。UI 扩展可自动安装和配置 Kubewarden 堆栈，并配置对 SUSE 维护的策略的访问。UI 扩展提供了对现成策略的策划目录的访问。使用 UI 扩展，人们可以浏览、安装和配置这些策略。
|
||||
|
||||
UI 扩展提供了 Kubewarden 堆栈组件及其行为的概述。这包括对 Kubewarden 指标和跟踪事件的访问。操作员可以了解策略对集群的影响并排查问题。
|
||||
|
||||
此外，UI 扩展还提供了 Policy Reporter UI，它可以直观地概述 Kubernetes 集群的合规性状态。通过此 UI，操作员可以快速识别所有不合规的 Kubernetes 资源，了解违规原因并采取相应行动。所有这一切都得益于 Rancher Prime 的支持。
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: 自定义资源配置
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/logging/custom-resource-configuration"/>
|
||||
</head>
|
||||
|
||||
通过以下自定义资源配置 logging：
|
||||
|
||||
- [Flow 和 ClusterFlow](flows-and-clusterflows.md)
|
||||
- [Output 和 ClusterOutput](outputs-and-clusteroutputs.md)
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: Flows 和 ClusterFlows
|
||||
---
|
||||
|
||||
有关如何配置 `Flow` 和 `ClusterFlow` 的完整详细信息，请参阅 [Logging Operator 文档](https://kube-logging.github.io/docs/configuration/flow/)。
|
||||
|
||||
有关如何解决 Logging 缓冲区的内存问题，请参阅 [Rancher 与 Logging 服务的集成：故障排除](../../../pages-for-subheaders/logging.md#日志缓冲区导致-pod-过载)。
|
||||
|
||||
## Flows
|
||||
|
||||
`Flow` 定义要收集和过滤哪些日志，以及将日志发送到哪个 Output。
|
||||
|
||||
`Flow` 是一个命名空间资源。换言之，只有部署了该 Flow 的命名空间日志才能被 `Flow` 收集。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `Flow`。
|
||||
|
||||
有关 `Flow` 自定义资源的更多详细信息，请参阅 [FlowSpec](https://kube-logging.github.io/docs/configuration/crds/v1beta1/flow_types/)。
|
||||
|
||||
### Matches
|
||||
|
||||
匹配语句用于选择从哪些容器中拉取日志。
|
||||
|
||||
你可以指定 match 语句，然后根据 Kubernetes 标签、容器和主机名来选择或排除日志。匹配语句会按照定义和处理的顺序进行评估，直到应用了第一个匹配的选择/排除规则。
|
||||
|
||||
你可以通过填写 Rancher UI 中的 `Flow` 或 `ClusterFlow` 表单来配置匹配。
|
||||
|
||||
使用 match 语句的详细示例，请参阅[日志路由的官方文档](https://kube-logging.github.io/docs/configuration/log-routing/)。
|
||||
|
||||
### Filters
|
||||
|
||||
你可以在 `Flow` 中定义一个或多个过滤器。过滤器可以对日志执行各种操作，例如，添加其他数据、转换日志或解析记录中的值。`Flow` 中的过滤器会按定义的顺序应用。
|
||||
|
||||
有关 Logging Operator 支持的过滤器列表，请参阅 [Fluentd 过滤器的官方文档](https://kube-logging.github.io/docs/configuration/plugins/filters/)。
|
||||
|
||||
过滤器需要在 YAML 中配置。
|
||||
|
||||
### Outputs
|
||||
|
||||
此 `Output` 会接收来自 `Flow` 的日志。由于 `Flow` 是一个命名空间资源，因此 `Output` 必须与 `Flow` 位于相同的命名空间中。
|
||||
|
||||
在 Rancher UI 中填写 `Flow` 或 `ClusterFlow` 表单时，你可以引用`Output`。
|
||||
|
||||
## ClusterFlows
|
||||
|
||||
为 `ClusterFlow` 配置匹配、过滤器和 `Output` 的方式与 `Flow` 的配置方式相同。主要区别在于 `ClusterFlow` 是集群级别的，并且可以跨所有命名空间配置日志收集。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `ClusterFlow`。
|
||||
|
||||
`ClusterFlow` 选择集群中所有命名空间的日志后，集群的日志会被收集并记录到所选的 `ClusterOutput`。
|
||||
|
||||
## YAML 示例
|
||||
|
||||
以下示例 `Flow` 转换了默认命名空间的日志消息，并将日志发送到 S3 `Output`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Flow
|
||||
metadata:
|
||||
name: flow-sample
|
||||
namespace: default
|
||||
spec:
|
||||
filters:
|
||||
- parser:
|
||||
remove_key_name_field: true
|
||||
parse:
|
||||
type: nginx
|
||||
- tag_normaliser:
|
||||
format: ${namespace_name}.${pod_name}.${container_name}
|
||||
localOutputRefs:
|
||||
- s3-output
|
||||
match:
|
||||
- select:
|
||||
labels:
|
||||
app: nginx
|
||||
```
|
||||
+295
@@ -0,0 +1,295 @@
|
||||
---
|
||||
title: Outputs 和 ClusterOutputs
|
||||
---
|
||||
|
||||
有关如何配置 `Flow` 和 `ClusterFlow` 的完整详细信息，请参阅 [Logging Operator 文档](https://kube-logging.github.io/docs/configuration/flow/)。
|
||||
|
||||
有关如何解决 Logging 缓冲区的内存问题，请参阅 [Rancher 与 Logging 服务的集成：故障排除](../../../pages-for-subheaders/logging.md#日志缓冲区导致-pod-过载)。
|
||||
|
||||
## Outputs
|
||||
|
||||
`Output` 资源定义了你的 `Flow` 可以发送日志消息的位置。`Output` 是 Logging `Flow` 的最后阶段。
|
||||
|
||||
`Output` 是命名空间资源，换言之，只有同一命名空间内的 `Flow` 可以访问它。
|
||||
|
||||
你可以在这些定义中使用密文，但这些密文也必须位于同一命名空间中。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `Output`。
|
||||
|
||||
有关 `Output` 自定义资源的更多详细信息，请参阅 [OutputSpec](https://kube-logging.github.io/docs/configuration/crds/v1beta1/output_types/)。
|
||||
|
||||
Rancher UI 提供了用于配置以下类型 `Output` 的表单：
|
||||
|
||||
- Amazon ElasticSearch
|
||||
- Azure Storage
|
||||
- Cloudwatch
|
||||
- Datadog
|
||||
- Elasticsearch
|
||||
- File
|
||||
- Fluentd
|
||||
- GCS
|
||||
- Kafka
|
||||
- Kinesis Stream
|
||||
- LogDNA
|
||||
- LogZ
|
||||
- Loki
|
||||
- New Relic
|
||||
- Splunk
|
||||
- SumoLogic
|
||||
- Syslog
|
||||
|
||||
Rancher UI 提供了用于配置 `Output` 类型、目标和访问凭证（如果适用）的表单。
|
||||
|
||||
有关 Logging Operator 支持的日志插件配置示例，请参阅 [Logging Operator 文档](https://kube-logging.github.io/docs/configuration/plugins/outputs/)。
|
||||
|
||||
## ClusterOutputs
|
||||
|
||||
`ClusterOutput` 定义了一个没有命名空间限制的 `Output`。只有在与 Logging Operator 部署在同一命名空间中时，它才能生效。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `ClusterOutput`。
|
||||
|
||||
有关 `ClusterOutput` 自定义资源的更多详细信息，请参阅 [ClusterOutput](https://kube-logging.github.io/docs/configuration/crds/v1beta1/clusteroutput_types/)。
|
||||
|
||||
## YAML 示例
|
||||
|
||||
安装 Logging 后，你可以参考以下示例来构建你自己的 Logging 流水线：
|
||||
|
||||
- [ClusterOutput 设为 ElasticSearch](#clusteroutput-设为-elasticsearch)
|
||||
- [Output 设为 Splunk](#output-设为-splunk)
|
||||
- [Output 设为 Syslog](#output-设为-syslog)
|
||||
- [不支持的 Output](#不支持的-output)
|
||||
|
||||
### ClusterOutput 设为 ElasticSearch
|
||||
|
||||
假设你想将集群中的所有日志发送到 `elasticsearch` 集群。首先，创建一个集群 `Output`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: "example-es"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
elasticsearch:
|
||||
host: elasticsearch.example.com
|
||||
port: 9200
|
||||
scheme: http
|
||||
```
|
||||
|
||||
在与 Operator 相同的命名空间（`cattle-logging-system`）中，我们创建了这个 `ClusterOutput`（没有 elasticsearch 配置）。每次创建 `ClusterFlow` 或 `ClusterOutput` 时，我们都必须将其放在 `cattle-logging-system` 命名空间中。
|
||||
|
||||
配置日志的目的位置后，我们可以尝试将所有日志都配置到该 `ClusterOutput`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: "all-logs"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- "example-es"
|
||||
```
|
||||
|
||||
现在，我们应该能看到配置的包含日志的索引。
|
||||
|
||||
|
||||
### Output 设为 Splunk
|
||||
|
||||
有时候，你的应用程序团队可能只想将某个命名空间的日志发送到 `splunk` 服务器。对于这种情况，你可以使用命名空间范围的 `Output` 和 `Flow`。
|
||||
|
||||
在开始之前，先设置该团队的应用程序 `coolapp`。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: devteam
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: coolapp
|
||||
namespace: devteam
|
||||
labels:
|
||||
app: coolapp
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
app: coolapp
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: coolapp
|
||||
spec:
|
||||
containers:
|
||||
- name: generator
|
||||
image: paynejacob/loggenerator:latest
|
||||
```
|
||||
|
||||
`coolapp` 运行时，我们将使用与创建 `ClusterOutput` 时类似的路径。但是，我们不使用 `ClusterOutput`，而是在应用程序的命名空间中创建 `Output`。
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Output
|
||||
metadata:
|
||||
name: "devteam-splunk"
|
||||
namespace: "devteam"
|
||||
spec:
|
||||
splunkHec:
|
||||
hec_host: splunk.example.com
|
||||
hec_port: 8088
|
||||
protocol: http
|
||||
```
|
||||
|
||||
然后，再次为 `Output` 提供一些日志：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Flow
|
||||
metadata:
|
||||
name: "devteam-logs"
|
||||
namespace: "devteam"
|
||||
spec:
|
||||
localOutputRefs:
|
||||
- "devteam-splunk"
|
||||
```
|
||||
|
||||
|
||||
### Output 设为 Syslog
|
||||
|
||||
假设你想将集群中的所有日志发送到 `syslog` 服务器。首先，我们创建一个 `ClusterOutput`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: "example-syslog"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
syslog:
|
||||
buffer:
|
||||
timekey: 30s
|
||||
timekey_use_utc: true
|
||||
timekey_wait: 10s
|
||||
flush_interval: 5s
|
||||
format:
|
||||
type: json
|
||||
app_name_field: test
|
||||
host: syslog.example.com
|
||||
insecure: true
|
||||
port: 514
|
||||
transport: tcp
|
||||
```
|
||||
|
||||
配置日志的目的位置后，我们可以尝试将所有日志都配置到该 `Output`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: "all-logs"
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- "example-syslog"
|
||||
```
|
||||
|
||||
### 不支持的 Output
|
||||
|
||||
对于最后一个示例，我们创建一个 `Output` 来将日志写入到不是开箱即用的目标位置：
|
||||
|
||||
:::note Syslog 注意事项：
|
||||
|
||||
`Syslog` 是受支持的 `Output`。但是，此示例仍提供了不受支持的插件概述。
|
||||
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: syslog-config
|
||||
namespace: cattle-logging-system
|
||||
type: Opaque
|
||||
stringData:
|
||||
fluent-bit.conf: |
|
||||
[INPUT]
|
||||
Name forward
|
||||
Port 24224
|
||||
|
||||
[OUTPUT]
|
||||
Name syslog
|
||||
InstanceName syslog-output
|
||||
Match *
|
||||
Addr syslog.example.com
|
||||
Port 514
|
||||
Cluster ranchers
|
||||
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: fluentbit-syslog-forwarder
|
||||
namespace: cattle-logging-system
|
||||
labels:
|
||||
output: syslog
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
output: syslog
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
output: syslog
|
||||
spec:
|
||||
containers:
|
||||
- name: fluentbit
|
||||
image: paynejacob/fluent-bit-out-syslog:latest
|
||||
ports:
|
||||
- containerPort: 24224
|
||||
volumeMounts:
|
||||
- mountPath: "/fluent-bit/etc/"
|
||||
name: configuration
|
||||
volumes:
|
||||
- name: configuration
|
||||
secret:
|
||||
secretName: syslog-config
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: syslog-forwarder
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
selector:
|
||||
output: syslog
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 24224
|
||||
targetPort: 24224
|
||||
---
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: all-logs
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- syslog
|
||||
---
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: syslog
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
forward:
|
||||
servers:
|
||||
- host: "syslog-forwarder.cattle-logging-system"
|
||||
require_ack_response: false
|
||||
ignore_network_errors_at_startup: false
|
||||
```
|
||||
|
||||
现在，我们分解这里的内容。首先，我们创建一个容器 Deployment，该容器具有额外的 `syslog` 插件并支持转发自另一个 `fluentd` 的日志。接下来，我们创建一个配置为 Deployment 转发器的 `Output`。然后，Deployment `fluentd` 会将所有日志转发到配置的 `syslog` 目标。
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: 架构
|
||||
---
|
||||
|
||||
本节介绍了 Rancher Logging 应用程序的架构。
|
||||
|
||||
有关 Logging Operator 工作原理的更多详细信息，请参阅[官方文档](https://kube-logging.github.io/docs/#architecture)。
|
||||
|
||||
### Logging Operator 工作原理
|
||||
|
||||
Logging Operator 自动部署和配置 Kubernetes 日志流水线。它会在每个节点上部署和配置一个 Fluent Bit DaemonSet，从而收集节点文件系统中的容器和应用程序日志。
|
||||
|
||||
Fluent Bit 查询 Kubernetes API 并使用 pod 的元数据来丰富日志，然后将日志和元数据都传输到 Fluentd。Fluentd 会接收和过滤日志并将日志传输到多个`Output`。
|
||||
|
||||
以下自定义资源用于定义了如何过滤日志并将日志发送到 `Output`：
|
||||
|
||||
- `Flow` 是一个命名空间自定义资源，它使用过滤器和选择器将日志消息路由到对应的 `Output`。
|
||||
- `ClusterFlow` 用于路由集群级别的日志消息。
|
||||
- `Output` 是一个命名空间资源，用于定义发送日志消息的位置。
|
||||
- `ClusterOutput` 定义了一个所有 `Flow` 和 `ClusterFlow` 都可用的 `Output`。
|
||||
|
||||
每个 `Flow` 都必须引用一个 `Output`，而每个 `ClusterFlow` 都必须引用一个 `ClusterOutput`。
|
||||
|
||||
[Logging Operator 文档](https://kube-logging.github.io/docs/#architecture)中的下图显示了新的 Logging 架构：
|
||||
|
||||
<figcaption>Logging Operator 如何与 Fluentd 和 Fluent Bit 一起使用</figcaption>
|
||||
|
||||
|
||||
+94
@@ -0,0 +1,94 @@
|
||||
---
|
||||
title: rancher-logging Helm Chart 选项
|
||||
---
|
||||
|
||||
### 启用/禁用 Windows 节点 Logging
|
||||
|
||||
要启用或禁用 Windows 节点 Logging，你可以在 `values.yaml` 中将 `global.cattle.windows.enabled` 设置为 `true` 或 `false`。
|
||||
|
||||
默认情况下，如果使用 Cluster Dashboard UI 在 Windows 集群上安装了 Logging 应用程序，Windows 节点的 Logging 就会启用。
|
||||
|
||||
在这种情况下，将 `global.cattle.windows.enabled` 设置为 `false` 会禁用集群上的 Windows 节点 Logging。
|
||||
禁用后，仍会从 Windows 集群中的 Linux 节点收集日志。
|
||||
|
||||
:::note
|
||||
|
||||
目前存在一个[问题](https://github.com/rancher/rancher/issues/32325)，在 Windows 集群中禁用 Windows Logging 后执行 `helm upgrade` 时不会删除 Windows nodeAgent。在这种情况下，如果已安装 Windows nodeAgents，用户可能需要手动卸载它们。
|
||||
|
||||
:::
|
||||
|
||||
### 使用自定义 Docker 根目录
|
||||
|
||||
如果使用了自定义 Docker 根目录，你可以在 `values.yaml` 中设置 `global.dockerRootDirectory`。
|
||||
|
||||
这将确保创建的 Logging CR 使用你指定的路径，而不是使用默认的 Docker `data-root` 位置。
|
||||
|
||||
请注意，这只影响 Linux 节点。
|
||||
|
||||
如果集群中有任何 Windows 节点，则更改将不适用于这些节点。
|
||||
|
||||
### 为自定义污点添加 NodeSelector 设置和容忍度
|
||||
|
||||
你可以添加 `nodeSelector` 设置，并通过编辑 Logging Helm Chart 值来添加其他`容忍度`。有关详细信息，请参阅[此页面](taints-and-tolerations.md)。
|
||||
|
||||
### 启用 Logging 应用程序以使用 SELinux
|
||||
|
||||
:::note 要求：
|
||||
|
||||
Logging v2 已在 RHEL/CentOS 7 和 8 上使用 SELinux 进行了测试。
|
||||
|
||||
:::
|
||||
|
||||
[安全增强型 Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是对 Linux 的安全增强。被政府机构使用之后，SELinux 已成为行业标准，并在 CentOS 7 和 8 上默认启用。
|
||||
|
||||
要配合使用 Logging V2 与 SELinux，我们建议你根据[此说明](../../pages-for-subheaders/selinux-rpm.md)安装 `rancher-selinux` RPM。
|
||||
|
||||
然后，在安装 Logging 应用程序时，在 `values.yaml` 中将 `global.seLinux.enabled` 更改为 `true`，使 Chart 支持 SELinux。
|
||||
|
||||
### 其他日志来源
|
||||
|
||||
默认情况下，Rancher 会收集所有类型集群的 [controlplane 组件](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components)和[节点组件](https://kubernetes.io/docs/concepts/overview/components/#node-components)的日志。
|
||||
|
||||
在某些情况下，Rancher 也能收集其他的日志。
|
||||
|
||||
下表总结了每种节点类型可以收集的其他日志来源：
|
||||
|
||||
| 日志来源 | Linux 节点（包括在 Windows 集群中） | Windows 节点 |
|
||||
| --- | --- | ---|
|
||||
| RKE | ✓ | ✓ |
|
||||
| RKE2 | ✓ | |
|
||||
| K3s | ✓ | |
|
||||
| AKS | ✓ | |
|
||||
| EKS | ✓ | |
|
||||
| GKE | ✓ | |
|
||||
|
||||
要将托管 Kubernetes 的提供商作为额外的日志来源，在安装或升级 Logging Helm Chart 时，请启用 **Enable enhanced cloud provider logging** 选项。
|
||||
|
||||
启用后，Rancher 会收集提供商开放可用的所有其他节点和 controlplane 日志，不同提供商可能有所不同。
|
||||
|
||||
如果你已经使用了云提供商的日志解决方案，例如 AWS CloudWatch 或 Google Cloud Operations Suite（以前称为 Stackdriver），由于原生解决方案可以不受限制地访问所有日志，因此你无需启用此选项。
|
||||
|
||||
### Systemd 配置
|
||||
|
||||
在 Rancher Logging 中，你必须为 K3s 和 RKE2 Kubernetes 发行版配置 `SystemdLogPath`。
|
||||
|
||||
K3s 和 RKE2 Kubernetes 发行版将日志写入到 journald，它是 systemd 的子系统，用于日志记录。要收集这些日志，你需要定义 `systemdLogPath`。默认路径是 `run/log/journal`，但某些 Linux 发行版不默认使用该路径。例如，Ubuntu 默认使用 `var/log/journal`。要确定你的 `systemdLogPath` 配置，请参阅以下步骤。
|
||||
|
||||
**Systemd 配置步骤：**
|
||||
|
||||
* 在其中一个节点上运行 `cat /etc/systemd/journald.conf | grep -E ^\#?Storage | cut -d"=" -f2`。
|
||||
* 如果返回 `persistent`，则你的 `systemdLogPath` 是 `/var/log/journal`。
|
||||
* 如果返回 `volatile`，则你的 `systemdLogPath` 是 `/run/log/journal`。
|
||||
* 如果返回 `auto`，则检查 `/var/log/journal` 是否存在。
|
||||
* 如果 `/var/log/journal` 存在，则使用 `/var/log/journal`。
|
||||
* 如果 `/var/log/journal` 不存在，则使用 `/run/log/journal`。
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
如果返回的值不包括在上述描述中，Rancher Logging 将无法收集 controlplane 日志。要解决此问题，你需要在每个 controlplane 节点上执行以下操作。
|
||||
|
||||
* 在 journald.conf 中设置 `Storage=volatile`。
|
||||
* 重启主机。
|
||||
* 将 `systemdLogPath` 设置为 `/run/log/journal`。
|
||||
|
||||
:::
|
||||
+115
@@ -0,0 +1,115 @@
|
||||
---
|
||||
title: Rancher Logging 集成
|
||||
description: Rancher 集成了主流的日志服务。了解集成日志服务的要求和优势，并在你的集群上启用 Logging。
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/logging"/>
|
||||
</head>
|
||||
|
||||
现在，Rancher 的日志管理由 [Logging operator](https://kube-logging.github.io/docs/) 提供支持，它取代了以前的内部解决方案。
|
||||
|
||||
## 启用 Logging
|
||||
|
||||
你可以转到**应用**页面并安装 Logging 应用程序，从而为 Rancher 管理的集群启用 Logging：
|
||||
|
||||
1. 转到要安装 Logging 的集群，然后单击 **Apps**。
|
||||
1. 点击 **Logging** 应用。
|
||||
1. 滚动到 Helm Chart README 的底部，然后单击**安装**。
|
||||
|
||||
**结果**：Logging 应用已部署到 `cattle-logging-system` 命名空间中。
|
||||
|
||||
## 卸载 Logging
|
||||
|
||||
1. 转到要安装 Logging 的集群，然后单击 **Apps**。
|
||||
1. 点击**已安装的应用**。
|
||||
1. 转到 `cattle-logging-system` 命名空间并选中 `rancher-logging` 和 `rancher-logging-crd` 框。
|
||||
1. 单击**删除**。
|
||||
1. 确认**删除**。
|
||||
|
||||
**结果**：已卸载 `rancher-logging`。
|
||||
|
||||
## 架构
|
||||
|
||||
有关 Logging 应用程序工作原理的更多信息，请参阅[本节](logging-architecture.md)。
|
||||
|
||||
## RBAC
|
||||
|
||||
Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`。有关如何以及何时使用这些角色的更多信息，请参阅[此页面](rbac-for-logging.md)。
|
||||
|
||||
## 配置 Logging 自定义资源
|
||||
|
||||
要管理 `Flows`、`ClusterFlows`、`Outputs` 和 `ClusterOutputs`：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
2. 在**集群**页面上，转到要配置 Logging 自定义资源的集群，然后单击 **Explore**。
|
||||
3. 在左侧导航栏中，单击 **Logging**。
|
||||
|
||||
### Flows 和 ClusterFlows
|
||||
|
||||
有关配置 `Flows` 和 `ClusterFlows` 的帮助，请参阅[此页面](custom-resource-configuration/flows-and-clusterflows.md)。
|
||||
|
||||
### Outputs 和 ClusterOutputs
|
||||
|
||||
有关配置 `Outputs` 和 `ClusterOutputs` 的帮助，请参阅[此页面](custom-resource-configuration/outputs-and-clusteroutputs.md)。
|
||||
|
||||
## 配置 Logging Helm Chart
|
||||
|
||||
有关在安装或升级 Logging 应用程序时可配置的选项，请参阅[此页面](logging-helm-chart-options.md)。
|
||||
|
||||
### Windows 支持
|
||||
|
||||
你可以从 Windows 节点[启用 Logging](logging-helm-chart-options.md#启用禁用-windows-节点-logging)。
|
||||
|
||||
### 使用自定义 Docker 根目录
|
||||
|
||||
有关使用自定义 Docker 根目录的详细信息，请参阅[本节](logging-helm-chart-options.md#使用自定义-docker-根目录)。
|
||||
|
||||
### 处理污点和容忍度
|
||||
|
||||
有关如何在 Logging 应用程序中使用污点和容忍度的信息，请参阅[此页面](taints-and-tolerations.md)。
|
||||
|
||||
### 在 SELinux 上使用 Logging V2
|
||||
|
||||
有关在启用了 SELinux 的节点上使用 Logging 应用程序的信息，请参阅[本节](logging-helm-chart-options.md#启用-logging-应用程序以使用-selinux)。
|
||||
|
||||
### 其他日志来源
|
||||
|
||||
默认情况下，Rancher 会收集所有类型集群的 controlplane 组件和节点组件的日志。在某些情况下，也会收集其他日志。有关详细信息，请参阅[本节](logging-helm-chart-options.md#其他日志来源)。
|
||||
|
||||
## 故障排除
|
||||
|
||||
### 日志缓冲区导致 Pod 过载
|
||||
|
||||
根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
|
||||
|
||||
有关如何配置日志缓冲区来满足企业需求的更完整说明，请参阅[缓冲区](https://kube-logging.github.io/docs/configuration/plugins/outputs/buffer/)和 [Fluentd 配置](https://kube-logging.github.io/docs/logging-infrastructure/fluentd/)的官方 Logging Operator 文档。
|
||||
|
||||
### `cattle-logging` 命名空间正在重新创建
|
||||
|
||||
如果你的集群之前在旧版 Rancher UI 的全局视图中部署了 Logging，`cattle-logging` 命名空间可能会不断被重新创建。
|
||||
|
||||
要解决这个问题，你可以将所有 `clusterloggings.management.cattle.io` 和 `projectloggings.management.cattle.io` 自定义资源从管理集群中针对该集群的命名空间中删除。
|
||||
这些自定义资源会导致 Rancher 在下游集群中创建 `cattle-logging` 命名空间（如果不存在）。
|
||||
|
||||
集群命名空间与集群 ID 匹配，因此我们需要找到每个集群的集群 ID。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要获取 ID 的集群，然后单击 **Explore**。
|
||||
2. 从以下其中一个 URL 中复制 `<cluster-id>` 的内容。`<cluster-id>` 是集群命名空间名称。
|
||||
|
||||
```bash
|
||||
# Cluster Management UI
|
||||
https://<your-url>/c/<cluster-id>/
|
||||
|
||||
# Cluster Dashboard
|
||||
https://<your-url>/dashboard/c/<cluster-id>/
|
||||
```
|
||||
|
||||
现在我们有了 `<cluster-id>` 命名空间，我们可以删除导致 `cattle-logging` 不断重新创建的自定义资源。
|
||||
*警告*：请确保当前未使用 Logging （从旧版 Rancher UI 全局视图中安装的版本）。
|
||||
|
||||
```bash
|
||||
kubectl delete crd clusterloggings.management.cattle.io -n <cluster-id>
|
||||
kubectl delete crd projectloggings.management.cattle.io -n <cluster-id>
|
||||
```
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Logging 的 RBAC
|
||||
---
|
||||
|
||||
Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`。
|
||||
|
||||
- `logging-admin` 允许用户完全访问命名空间的 `Flow` 和 `Output`。
|
||||
- `logging-view` 允许用户*查看*命名空间的 `Flow` 和 `Output`，以及 `ClusterFlow` 和 `ClusterOutput`。
|
||||
|
||||
:::note 为什么选择一个角色而不是另一个角色？
|
||||
|
||||
`ClusterFlow` 和 `ClusterOutput` 资源的编辑权限非常强大。任何拥有该权限的用户都能编辑集群中的所有日志。
|
||||
|
||||
:::
|
||||
|
||||
在 Rancher 中，集群管理员角色是唯一可以完全访问所有 `rancher-logging` 资源的角色。集群成员无法编辑或读取任何 Logging 资源。项目所有者和成员具有以下权限：
|
||||
|
||||
| 项目所有者 | 项目成员 |
|
||||
--- | ---
|
||||
| 能够在其项目命名空间中创建命名空间级别的 `Flow` 和 `Output` | 只能查看项目命名空间中的 `Flow` 和 `Output` |
|
||||
| 可以从项目命名空间中收集任何日志 | 无法在其项目命名空间中收集任何日志 |
|
||||
|
||||
如果项目所有者和项目成员需要使用 Logging，他们需要在项目中至少有*一个*命名空间。如果没有，他们可能看不到顶部导航下拉列表中的 Logging 按钮。
|
||||
+65
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: 处理污点和容忍度
|
||||
---
|
||||
|
||||
在 Kubernetes 节点上添加污点会导致 pod 排斥在该节点上运行。
|
||||
|
||||
除非 pod 对该节点的污点具有`容忍度`（toleration），否则 Pod 将在集群中的其他节点上运行。
|
||||
|
||||
[污点和容忍度](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)可以与 `PodSpec` 中的 `nodeSelector` [字段](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)一起使用，从而实现*相反的*污点效果。
|
||||
|
||||
`nodeSelector` 可以使 pod 被吸引到某类节点。
|
||||
|
||||
两者都能让 pod 选择在哪个节点上运行。
|
||||
|
||||
- [Rancher 日志堆栈中的默认实现](#rancher-日志堆栈中的默认实现)
|
||||
- [为自定义污点添加 NodeSelector 设置和容忍度](#为自定义污点添加-nodeselector-设置和容忍度)
|
||||
|
||||
|
||||
### Rancher 日志堆栈中的默认实现
|
||||
|
||||
默认情况下，Rancher 使用 `cattle.io/os=linux` 来将污点应用到所有 Linux 节点，而不影响 Windows 节点。
|
||||
日志堆栈 pod 具有针对此污点的`容忍度`，因此它们能够运行在 Linux 节点上。
|
||||
此外，大多数日志堆栈 pod 仅在 Linux 上运行，并添加了 `nodeSelector` 以确保它们在 Linux 节点上运行。
|
||||
|
||||
此示例 Pod YAML 文件显示了与容忍度一起使用的 nodeSelector：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
# metadata...
|
||||
spec:
|
||||
# containers...
|
||||
tolerations:
|
||||
- key: cattle.io/os
|
||||
operator: "Equal"
|
||||
value: "linux"
|
||||
effect: NoSchedule
|
||||
nodeSelector:
|
||||
kubernetes.io/os: linux
|
||||
```
|
||||
|
||||
在上面的示例中，我们确保了的 pod 仅在 Linux 节点上运行，并且为所有 Linux 节点上的污点添加了`容忍度`。
|
||||
|
||||
你可以对 Rancher 现有的污点或你自己的自定义污点执行相同的操作。
|
||||
|
||||
### 为自定义污点添加 NodeSelector 设置和容忍度
|
||||
|
||||
如果要添加你自己的 `nodeSelector` 设置，或者要为其他污点添加 `容忍度`，你可以将以下内容传递给 Chart 的值：
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
# insert tolerations...
|
||||
nodeSelector:
|
||||
# insert nodeSelector...
|
||||
```
|
||||
|
||||
这些值会将这两个设置添加到 `fluentd`、`fluentbit`和 `logging-operator` 容器中。
|
||||
本质上，这些是日志堆栈中所有 pod 的全局设置。
|
||||
|
||||
但是，如果你想*仅*为 `fluentbit` 容器添加容忍度，你可以将以下内容添加到 Chart 的值中：
|
||||
|
||||
```yaml
|
||||
fluentbit_tolerations:
|
||||
# insert tolerations list for fluentbit containers only...
|
||||
```
|
||||
+70
@@ -0,0 +1,70 @@
|
||||
---
|
||||
title: Longhorn - Kubernetes 的云原生分布式块存储
|
||||
---
|
||||
|
||||
[Longhorn](https://longhorn.io/) 是一个轻量级、可靠、易用的 Kubernetes 分布式块存储系统。
|
||||
|
||||
Longhorn 是免费的开源软件。Longhorn 最初由 Rancher Labs 开发，现在正在作为云原生计算基金会的沙盒项目进行开发。它可以通过 Helm、kubectl 或 Rancher UI 安装在任何 Kubernetes 集群上。有关其架构的更多信息，请参阅[此处](https://longhorn.io/docs/latest/concepts/)。
|
||||
|
||||
使用 Longhorn，你可以：
|
||||
|
||||
- 将 Longhorn 卷用作 Kubernetes 集群中分布式有状态应用程序的持久存储
|
||||
- 将你的块存储分区为 Longhorn 卷，以便在有或没有云提供商的情况下使用 Kubernetes 卷
|
||||
- 跨多个节点和数据中心复制块存储以提高可用性
|
||||
- 将备份数据存储在 NFS 或 AWS S3 等外部存储中
|
||||
- 创建跨集群灾难恢复卷，以便使用另一个 Kubernetes 集群中的备份快速恢复主 Kubernetes 集群中的数据
|
||||
- 计划卷的定期快照，并将定期备份调度到 NFS 或兼容 S3 的辅助存储
|
||||
- 使用备份来恢复卷
|
||||
- 在不中断持久卷的情况下升级 Longhorn
|
||||
|
||||
<figcaption>Longhorn 仪表板</figcaption>
|
||||
|
||||
|
||||
|
||||
### 使用 Rancher 安装 Longhorn
|
||||
|
||||
1. 满足所有[安装要求](https://longhorn.io/docs/latest/deploy/install/#installation-requirements)。
|
||||
1. 转到要安装 Longhorn 的集群。
|
||||
1. 单击 **Apps**。
|
||||
1. 单击 **Chart**。
|
||||
1. 点击 **Longhorn**。
|
||||
1. 可选：要自定义初始设置，请单击 **Longhorn 默认设置**并编辑配置。如需自定义设置的帮助，请参阅 [Longhorn 文档](https://longhorn.io/docs/latest/references/settings/)。
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**：Longhorn 已部署到 Kubernetes 集群中。
|
||||
|
||||
### 从 Rancher UI 访问 Longhorn
|
||||
|
||||
1. 转到安装了 Longhorn 的集群。在左侧导航菜单中，单击 **Longhorn**。
|
||||
1. 在此页面上，你可以编辑 Longhorn 管理的 Kubernetes 资源。要查看 Longhorn UI，请单击**概述**中的 **Longhorn** 按钮。
|
||||
|
||||
**结果**：你将转到 Longhorn UI，你可以在那里管理 Longhorn 卷及其在 Kubernetes 集群中的副本，还可以查看位于另一个 Kubernetes 集群或 S3 中的 Longhorn 存储辅助备份。
|
||||
|
||||
### 从 Rancher UI 卸载 Longhorn
|
||||
|
||||
1. 转到安装了 Longhorn 的集群，然后单击 **Apps**。
|
||||
1. 点击**已安装的应用**。
|
||||
1. 转到 `longhorn-system` 命名空间并选中 `longhorn` 和 `longhorn-crd` 应用程序旁边的框。
|
||||
1. 单击**删除**并确认**删除**。
|
||||
|
||||
**结果**：Longhorn 已被卸载。
|
||||
|
||||
### GitHub 仓库
|
||||
|
||||
Longhorn 项目在[此处](https://github.com/longhorn/longhorn)。
|
||||
|
||||
### 文档
|
||||
|
||||
Longhorn 文档在[此处](https://longhorn.io/docs/)。
|
||||
|
||||
### 架构
|
||||
|
||||
Longhorn 为每个卷创建专用的存储控制器，并在存储在多个节点上的多个副本之间同步复制该卷。
|
||||
|
||||
存储控制器和副本本身是使用 Kubernetes 编排的。
|
||||
|
||||
有关其架构的更多信息，请参阅[此处](https://longhorn.io/docs/latest/concepts/)。
|
||||
|
||||
<figcaption>Longhorn 架构</figcaption>
|
||||
|
||||
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: 使用 Longhorn 进行云原生存储
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/longhorn"/>
|
||||
</head>
|
||||
|
||||
## Longhorn
|
||||
|
||||
Longhorn 是官方的[云原生计算基金会（CNCF）](https://cncf.io/)项目，它为 Kubernetes 提供了一个可以在任何地方运行的强大的云原生分布式存储平台。当与 Rancher 相结合使用时，Longhorn 使你可以在 Kubernetes 环境中轻松、快速且可靠地部署高可用的持久块存储。
|
||||
|
||||
## Longhorn 与 Rancher
|
||||
|
||||
凭借 Rancher Prime 和 Longhorn，用户可以通过 Rancher 应用商店一键轻松部署，并对托管集群进行生命周期管理；允许用户能够安装和升级，同时进行清空操作以实现优雅的操作。Longhorn 和 Rancher Prime 还提供了 Windows 的混合集群支持，Rancher 托管的镜像，通过 Rancher 的 UI 代理访问，以及使用 Longhorn 指标进行 Rancher 监控。
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: 概述
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/longhorn/overview"/>
|
||||
</head>
|
||||
|
||||
[Longhorn](https://longhorn.io/) 是一个轻量级、可靠且易于使用的 Kubernetes 分布式块存储系统。
|
||||
|
||||
Longhorn 是免费的开源软件。它最初由 Rancher Labs 开发，现在被开发为云原生计算基金会的沙箱项目。它可以通过 Helm、kubectl 或 Rancher UI 安装在任何 Kubernetes 集群上。有关其架构的更多信息，请参阅[此处](https://longhorn.io/docs/latest/concepts/)。
|
||||
|
||||
使用 Longhorn，你可以：
|
||||
|
||||
- 使用 Longhorn 卷作为 Kubernetes 集群中分布式有状态应用程序的持久存储
|
||||
- 将块存储分区为 Longhorn 卷，以便你可以在有或没有云提供商的情况下使用 Kubernetes 卷
|
||||
- 跨多个节点和数据中心复制块存储以提高可用性
|
||||
- 将备份数据存储在 NFS 或 AWS S3 等外部存储中
|
||||
- 创建跨集群灾难恢复卷，以便使用另一个 Kubernetes 集群中的备份快速恢复主 Kubernetes 集群中的数据
|
||||
- 计划卷的定期快照，并将定期备份调度到 NFS 或兼容 S3 的辅助存储
|
||||
- 使用备份来恢复卷
|
||||
- 在不中断持久卷的情况下升级 Longhorn
|
||||
|
||||
<figcaption>Longhorn 仪表板</figcaption>
|
||||
|
||||
|
||||
|
||||
### 使用 Rancher 安装 Longhorn
|
||||
|
||||
1. 满足所有[安装要求](https://longhorn.io/docs/latest/deploy/install/#installation-requirements)。
|
||||
1. 转到要安装 Longhorn 的集群。
|
||||
1. 单击 **Apps**。
|
||||
1. 单击 **Charts**。
|
||||
1. 单击 **Longhorn**。
|
||||
1. 可选：要自定义初始设置，请单击 **Longhorn 默认设置**并编辑配置。如需自定义设置的帮助，请参阅 [Longhorn 文档](https://longhorn.io/docs/latest/references/settings/)。
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**：Longhorn 已部署到 Kubernetes 集群中。
|
||||
|
||||
### 从 Rancher UI 访问 Longhorn
|
||||
|
||||
1. 转到安装了 Longhorn 的集群。在左侧导航菜单中，单击 **Longhorn**。
|
||||
1. 在此页面上，你可以编辑 Longhorn 管理的 Kubernetes 资源。要查看 Longhorn UI，请单击**概述**中的 **Longhorn** 按钮。
|
||||
|
||||
**结果**：你将转到 Longhorn UI，在这里你可以管理 Kubernetes 集群中的 Longhorn 卷及其副本，以及可能存在于另一个 Kubernetes 集群或 S3 中的 Longhorn 存储辅助备份。
|
||||
|
||||
### 从 Rancher UI 卸载 Longhorn
|
||||
|
||||
1. 转到安装了 Longhorn 的集群，然后单击 **Apps**。
|
||||
1. 点击**已安装的应用**。
|
||||
1. 转到 `longhorn-system` 命名空间并选中 `longhorn` 和 `longhorn-crd` 应用程序旁边的框。
|
||||
1. 单击**删除**并确认**删除**。
|
||||
|
||||
**结果**：Longhorn 已被卸载。
|
||||
|
||||
### GitHub 仓库
|
||||
|
||||
Longhorn 项目可在[此处](https://github.com/longhorn/longhorn)获取。
|
||||
|
||||
### 文档
|
||||
|
||||
Longhorn 文档在[此处](https://longhorn.io/docs/)。
|
||||
|
||||
### 架构
|
||||
|
||||
Longhorn 为每个卷创建专用的存储控制器，并在多个节点上存储的多个副本之间同步复制该卷。
|
||||
|
||||
存储控制器和副本本身是使用 Kubernetes 编排的。
|
||||
|
||||
有关其架构的更多信息，请参阅[此处](https://longhorn.io/docs/latest/concepts/)。
|
||||
|
||||
<figcaption>Longhorn 架构</figcaption>
|
||||
|
||||
|
||||
+117
@@ -0,0 +1,117 @@
|
||||
---
|
||||
title: 内置仪表板
|
||||
---
|
||||
|
||||
## Grafana UI
|
||||
|
||||
你可以使用 [Grafana](https://grafana.com/grafana/) 对存储在各个地方的指标进行查询、可视化、告警和了解。你能与你的团队创建、探索和共享仪表板，并培养数据驱动的文化。
|
||||
|
||||
要查看时间序列数据可视化的默认仪表板，请转到 Grafana UI。
|
||||
|
||||
### 自定义 Grafana
|
||||
|
||||
要查看和自定义用于支持 Grafana 仪表板的 PromQL 查询，请参阅[此页面](../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/customize-grafana-dashboard.md)。
|
||||
|
||||
### 持久化 Grafana 仪表板
|
||||
|
||||
要创建持久化 Grafana 仪表板，请参阅[此页面](../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/create-persistent-grafana-dashboard.md)。
|
||||
|
||||
### 访问 Grafana
|
||||
|
||||
有关 Grafana 的 RBAC，请参阅[本节](rbac-for-monitoring.md#grafana-的-rbac)。
|
||||
|
||||
|
||||
## Alertmanager UI
|
||||
|
||||
安装 `rancher-monitoring` 后，会部署 Prometheus Alertmanager UI，从而让你查看告警以及当前的 Alertmanager 配置。
|
||||
|
||||
:::note
|
||||
|
||||
本节参考假设你已经熟悉 Monitoring 组件的协同工作方式。有关 Alertmanager 的详细信息，请参阅 [Alertmanager 工作原理](how-monitoring-works.md#3-alertmanager-的工作原理)。
|
||||
|
||||
:::
|
||||
|
||||
### 访问 Alertmanager UI
|
||||
|
||||
Alertmanager UI 可让你查看最近触发的告警。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
必须安装 `rancher-monitoring` 应用。
|
||||
|
||||
:::
|
||||
|
||||
要查看 Alertmanager UI：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要查看 Alertmanager UI 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**监控**。
|
||||
1. 单击 **Alertmanager**。
|
||||
|
||||
**结果**：在新选项卡中打开 Alertmanager UI。如需配置帮助，请参阅[官方 Alertmanager 文档](https://prometheus.io/docs/alerting/latest/alertmanager/)。
|
||||
|
||||
有关在 Rancher 中配置 Alertmanager 的更多信息，请参阅[此页面](../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md)。
|
||||
|
||||
<figcaption>Alertmanager UI</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
### 查看默认告警
|
||||
|
||||
要查看默认触发的告警，请转到 Alertmanager UI 并单击**展开所有组**。
|
||||
|
||||
|
||||
## Prometheus UI
|
||||
|
||||
默认情况下，[kube-state-metrics service](https://github.com/kubernetes/kube-state-metrics) 向 monitoring 应用提供 CPU 和内存利用率的大量信息。这些指标涵盖了跨命名空间的 Kubernetes 资源。换言之，如果你要查看服务的资源指标，你无需为其创建新的 ServiceMonitor。由于数据已经在时间序列数据库中，你可以转到 Prometheus UI 并运行 PromQL 查询来获取信息。你可以使用相同的查询来配置 Grafana 仪表板，从而显示这些指标随时间变化的图表。
|
||||
|
||||
要查看 Prometheus UI，请安装 `rancher-monitoring`。然后：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要查看 Prometheus UI 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**监控**。
|
||||
1. 单击 **Prometheus Graph**。
|
||||
|
||||
<figcaption>Prometheus Graph UI</figcaption>
|
||||
|
||||
|
||||
|
||||
### 查看 Prometheus 目标
|
||||
|
||||
要查看你正在监控的服务，你需要查看你的目标。目标是由 ServiceMonitor 和 PodMonitor 设置的，指的是指标抓取的的源。你无需直接编辑目标，但 Prometheus UI 可为你提供抓取的所有指标来源的概览。
|
||||
|
||||
要查看 Prometheus 目标，请安装 `rancher-monitoring`。然后：
|
||||
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要查看 Prometheus 目标的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**监控**。
|
||||
1. 单击 **Prometheus 目标**。
|
||||
|
||||
<figcaption>Prometheus UI 中的目标</figcaption>
|
||||
|
||||
|
||||
|
||||
### 查看 PrometheusRules
|
||||
|
||||
当你定义规则时（在 PrometheusRule 资源的 RuleGroup 中声明），[规则本身的规范](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#rule)会包含标签，然后 Alertmanager 会使用这些标签来确定接收对应告警的路由。
|
||||
|
||||
要查看 PrometheusRule，请安装 `rancher-monitoring`。然后：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要可视化的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**监控**。
|
||||
1. 点击 **Prometheus 规则**。
|
||||
|
||||
你还可以在 Prometheus UI 中查看规则：
|
||||
|
||||
<figcaption>Prometheus UI 中的规则</figcaption>
|
||||
|
||||
|
||||
|
||||
有关在 Rancher 中配置 PrometheusRule 的更多信息，请参阅[此页面](../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheusrules.md)。
|
||||
|
||||
## 旧版 UI
|
||||
|
||||
有关在引入 `rancher-monitoring` 应用程序之前 Rancher v2.2 到 v2.4 中可用仪表板的信息，请参阅 [Rancher v2.0—v2.4 文档](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/viewing-metrics.md)。
|
||||
+248
@@ -0,0 +1,248 @@
|
||||
---
|
||||
title: Monitoring 的工作原理
|
||||
---
|
||||
|
||||
## 1. 架构概述
|
||||
|
||||
_**下文描述了数据如何流经 Monitoring V2 应用程序：**_
|
||||
|
||||
### Prometheus Operator
|
||||
|
||||
Prometheus Operator 观察正在创建的 ServiceMonitors、PodMonitors 和 PrometheusRules。在创建 Prometheus 配置资源时，Prometheus Operator 会调用 Prometheus API 来同步新配置。如本节末尾的图所示，Prometheus Operator 充当 Prometheus 和 Kubernetes 之间的中介，调用 Prometheus API 来同步 Prometheus 与 Kubernetes 中的监控相关资源。
|
||||
|
||||
### ServiceMonitor 和 PodMonitor
|
||||
|
||||
ServiceMonitor 和 PodMonitor 以声明方式指定需要监控的目标，例如 Service 和 Pod。
|
||||
|
||||
- 目标是根据配置的 Prometheus 抓取间隔定期抓取的，而抓取的指标存储在 Prometheus 时间序列数据库（Time Series Database，TSDB）中。
|
||||
|
||||
- 为了执行抓取，你需要使用标签选择器来定义 ServiceMonitor 和 PodMonitor，这些标签选择器用于确定要抓取的 Service 或 Pod，并能确定端点（端点能确定抓取如何在给定目标上进行，例如在 TCP 10252 中抓取指标，通过 IP 地址 x.x.x.x 进行代理）。
|
||||
|
||||
- 开箱即用地，Monitoring V2 附带了一些预配置的 Exporter，这些 Exporter 根据其所在的 Kubernetes 集群的类型进行部署。有关详细信息，请参阅[抓取和公开指标](#5-抓取和公开指标)。
|
||||
|
||||
### PushProx 的工作原理
|
||||
|
||||
- 某些内部 Kubernetes 组件是通过部署在 Monitoring V2 中名为 **PushProx** 的代理来抓取的。通过 PushProx 向 Prometheus 公开指标的 Kubernetes 组件分别是 `kube-controller-manager`、`kube-scheduler`, `etcd` 和 `kube-proxy`。
|
||||
|
||||
- 对于每个 PushProx Exporter，我们在所有目标节点上都部署一个 PushProx 客户端。例如，将 PushProx 客户端部署到 kube-controller-manager 的所有 controlplane 节点、kube-etcd 的所有 etcd 节点上，和 kubelet 的所有节点上。
|
||||
|
||||
- 我们为每个 Exporter 部署了一个 PushProx 代理。导出指标的流程如下：
|
||||
|
||||
1. PushProx 客户端与 PushProx 代理建立出站连接。
|
||||
1. 然后，客户端会轮询代理以获取进入代理的抓取请求。
|
||||
1. 当代理收到来自 Prometheus 的抓取请求时，客户端会将其视为轮询的结果。
|
||||
1. 客户端抓取内部组件。
|
||||
1. 内部组件通过将指标推回代理来响应。
|
||||
|
||||
|
||||
<figcaption><br/>使用 PushProx 导出指标的过程：<br/></figcaption>
|
||||
|
||||
|
||||
|
||||
### PrometheusRules
|
||||
|
||||
PrometheusRule 用于定义指标或时间序列数据库查询触发告警的规则。规则是按时间间隔评估的。
|
||||
|
||||
- **记录规则**根据已收集的现有序列创建一个新的时间序列。它们常用于预先计算的复杂查询。
|
||||
- **告警规则**运行特定查询，如果查询评估为非零值，则从 Prometheus 触发告警。
|
||||
|
||||
### 告警路由
|
||||
|
||||
一旦 Prometheus 确定需要触发告警，就会将告警转发到 **Alertmanager**。
|
||||
|
||||
- 告警包含来自 PromQL 查询本身的标签，以及指定初始 PrometheusRule 时设置的其他标签和注释。
|
||||
|
||||
- 在接收任何告警之前，Alertmanager 会用配置中指定的**路由 (Route)** 和**接收器 (Receiver)** 来形成一个路由树，所有传入的告警都会在该路由树上进行评估。路由树的每个节点都可以根据附加到 Prometheus 告警的标签来指定要进行的其他分组、标签和过滤。路由树上的节点（通常是叶节点）还可以指定到达的告警需要发送到什么接收器，例如 Slack、PagerDuty、SMS 等。请注意，Alertmanager 首先向 **alertingDriver** 发送告警，然后 alertingDriver 再将告警发送或转发到正确的目标位置。
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时，Alertmanager 也会自动更新。请注意，路由仅通过标签发生（而不是通过注释等）。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
收集 Exporter 的指标后，Prometheus 将时间序列存储在本地磁盘时间序列数据库中。Prometheus 可以选择与远程系统集成，但 `rancher-monitoring` 使用本地存储来存储时间序列数据库。
|
||||
|
||||
存储后，用户可以使用 PromQL（Prometheus 的查询语言）查询此 TSDB。
|
||||
|
||||
PromQL 查询可以通过以下两种方式进行可视化：
|
||||
|
||||
1. 通过在 Prometheus 的 Graph UI 中提供查询，UI 会显示数据的简单图形视图。
|
||||
1. 通过创建包含 PromQL 查询和其他格式化指令的 Grafana 仪表板，这些指令用于标记轴、添加单位、更改颜色、使用替代可视化等。
|
||||
|
||||
### 为 Prometheus 定义规则
|
||||
|
||||
规则定义了 Prometheus 需要在常规 `evaluationInterval` 上执行的查询，从而执行某些操作，例如触发告警（告警规则）或根据 TSDB 中存在的其他查询（记录规则）预先计算查询。这些规则编码在 PrometheusRules 自定义资源中。创建或更新 PrometheusRule 自定义资源后，Prometheus Operator 会观察变化，并调用 Prometheus API 来定期同步 Prometheus 当前正在评估的规则集。
|
||||
|
||||
PrometheusRule 支持定义一个或多个 RuleGroup。每个 RuleGroup 由一组 Rule 对象组成，每个 Rule 对象均能表示告警或记录规则，并具有以下字段：
|
||||
|
||||
- 新告警或记录的名称
|
||||
- 新告警或记录的 PromQL 表达式
|
||||
- 用于标记告警或记录的标签（例如集群名称或严重性）
|
||||
- 对需要在告警通知上显示的其他重要信息进行编码的注释（例如摘要、描述、消息、Runbook URL 等）。记录规则不需要此字段。
|
||||
|
||||
在评估[规则](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#rule)时，Prometheus 将执行配置的 PromQL 查询，添加其他标签（或注释 - 仅用于告警规则），并为规则执行所需的操作。例如，如果某个告警规则将 `team:front-end` 作为标签添加到配置的 PromQL 查询，该标签会尾附到触发的告警，这将允许 Alertmanager 将告警转发到正确的接收器。
|
||||
|
||||
### 告警和记录规则
|
||||
|
||||
Prometheus 不会维护告警是否处于 active 状态。它在每个评估间隔内重复触发告警，并根据 Alertmanager 对告警进行分组和过滤成有意义的通知。
|
||||
|
||||
`evaluation_interval` 常量定义了 Prometheus 根据时间序列数据库评估告警规则的频率。与 `scrape_interval` 类似，`evaluation_interval` 的默认值也是一分钟。
|
||||
|
||||
规则包含在一组规则文件中。规则文件包括告警规则和记录规则，但只有告警规则才会在评估后触发告警。
|
||||
|
||||
对于记录规则，Prometheus 会运行查询，然后将其存储为时间序列。如果需要存储非常昂贵或耗时的查询的结果，这种合成的时间序列则非常有用，因此你可以在后续更快地进行查询它们。
|
||||
|
||||
告警规则是更常用的。每当告警规则评估为正数时，Prometheus 都会触发告警。
|
||||
|
||||
在触发告警之前，Rule 文件会根据实际用例将标签和注释添加到告警中：
|
||||
|
||||
- 标签用于标识告警的信息，并可能影响告警的路由。例如，如果在发送有关某个容器的告警时，你可以使用容器 ID 作为标签。
|
||||
|
||||
- 注释用于表示不影响告警路由位置的信息，例如 Runbook 或错误消息。
|
||||
|
||||
## 3. Alertmanager 的工作原理
|
||||
|
||||
Alertmanager 处理由 Prometheus server 等客户端应用发送的告警。它负责以下任务：
|
||||
|
||||
- 删除重复数据，分组，并将告警路由到正确的接收器集成（例如电子邮件、PagerDuty 或 OpsGenie）
|
||||
|
||||
- 静音和抑制告警
|
||||
|
||||
- 跟踪随时间触发的告警
|
||||
|
||||
- 发送告警的状态，即告警是否正在触发，或者是否已经解决
|
||||
|
||||
### 由 alertingDrivers 转发的告警
|
||||
|
||||
安装 alertingDriver 后会根据 alertingDriver 的配置创建一个 `Service`，可用作 Teams 或 SMS 的接收器 URL。接收器中的 URL 会指向 alertingDrivers。因此 Alertmanager 首先向 alertingDriver 发送告警，然后 alertingDriver 将告警转发或发送到正确的目的位置。
|
||||
|
||||
### 将告警路由到接收器
|
||||
|
||||
Alertmanager 负责协调告警的发送位置。它允许你根据标签对告警进行分组，并根据标签匹配情况来触发告警。一个最顶层路由会接受所有告警。然后，Alertmanager 会根据告警是否匹配下一个路由的条件，继续将告警路由到接收器。
|
||||
|
||||
虽然 Rancher UI 表单只允许编辑两层深的路由树，但你可以通过编辑 Alertmanager Secret 来配置更深的嵌套路由结构。
|
||||
|
||||
### 配置多个接收器
|
||||
|
||||
你可以编辑 Rancher UI 中的表单来设置一个接收器资源，其中包含 Alertmanager 将告警发送到你的通知系统所需的所有信息。
|
||||
|
||||
通过在 Alertmanager 或接收器配置中编辑自定义 YAML，你还可以将告警发送到多个通知系统。有关详细信息，请参阅[接收器配置](../../reference-guides/monitoring-v2-configuration/receivers.md#配置多个接收器)。
|
||||
|
||||
## 4. Monitoring V2 特定组件
|
||||
|
||||
Prometheus Operator 引入了一组[自定义资源定义](https://github.com/prometheus-operator/prometheus-operator#customresourcedefinitions)，允许用户通过在集群上创建和修改这些自定义资源来部署和管理 Prometheus 和 Alertmanager 实例。
|
||||
|
||||
Prometheus Operator 会根据 Rancher UI 中编辑的资源和配置选项的实时状态来自动更新 Prometheus 配置。
|
||||
|
||||
### 默认部署的资源
|
||||
|
||||
默认情况下，由 [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus) 项目策划的一组资源会作为 Rancher Monitoring 安装的一部分部署到你的集群上，用来设置基本的 Monitoring/Alerting 堆栈。
|
||||
|
||||
你可以在 [`rancher-monitoring`](https://github.com/rancher/charts/tree/main/charts/rancher-monitoring) Helm Chart 中找到部署到你的集群以支持此解决方案的资源，该 chart 密切跟踪由 Prometheus 社区维护的上游 [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack) Helm Chart，并在 [CHANGELOG.md](https://github.com/rancher/charts/blob/main/charts/rancher-monitoring/CHANGELOG.md) 中跟踪变更。
|
||||
|
||||
### 默认 Exporter
|
||||
|
||||
Monitoring V2 部署了三个默认 Exporter，它们为 Prometheus 提供额外的指标来存储：
|
||||
|
||||
1. `node-exporter`：公开 Linux 主机的硬件和操作系统指标。有关 `node-exporter` 的更多信息，请参阅[上游文档](https://prometheus.io/docs/guides/node-exporter/)。
|
||||
|
||||
1. `windows-exporter`：公开 Windows 主机的硬件和操作系统指标（仅部署在 Windows 集群上）。有关 `windows-exporter` 的更多信息，请参阅[上游文档](https://github.com/prometheus-community/windows_exporter)。
|
||||
|
||||
1. `kube-state-metrics`：公开跟踪 Kubernetes API 中包含的资源状态的其他指标（例如，pod、工作负载等）。有关 `kube-state-metrics` 的更多信息，请参阅[上游文档](https://github.com/kubernetes/kube-state-metrics/tree/master/docs)。
|
||||
|
||||
ServiceMonitor 和 PodMonitor 将按照[此定义](#定义要抓取的指标)来抓取这些 Exporter。Prometheus 会存储这些指标，你可以通过 Prometheus 的 UI 或 Grafana 查询结果。
|
||||
|
||||
有关记录规则、告警规则和 Alertmanager 的更多信息，请参阅[架构](#1-架构概述)。
|
||||
|
||||
### Rancher UI 中公开的组件
|
||||
|
||||
安装 monitoring 应用后，你将能够在 Rancher UI 中编辑以下组件：
|
||||
|
||||
| 组件 | 组件类型 | 编辑的目的和常见用例 |
|
||||
|--------------|------------------------|---------------------------|
|
||||
| ServiceMonitor | 自定义资源 | 设置 Kubernetes Service 来获取其自定义指标。自动更新 Prometheus 自定义资源中的抓取配置。 |
|
||||
| PodMonitor | 自定义资源 | 设置 Kubernetes Pod 来获取其自定义指标。自动更新 Prometheus 自定义资源中的抓取配置。 |
|
||||
| 接收器 | 配置块（Alertmanager 的一部分） | 修改将告警发送到什么位置的信息（例如，Slack、PagerDuty 等）以及发送告警的其他必要信息（例如，TLS 证书、代理 URL 等）。自动更新 Alertmanager 自定义资源。 |
|
||||
| Route | 配置块（Alertmanager 的一部分） | 修改用于根据标签过滤、标记和分组告警的路由树，并将告警发送到所需的接收器。自动更新 Alertmanager 自定义资源。 |
|
||||
| PrometheusRule | 自定义资源 | 定义其他查询，这些查询能触发告警或定义 Prometheus TSDB 中现有的物化视图。自动更新 Prometheus 自定义资源。 |
|
||||
|
||||
### PushProx
|
||||
|
||||
PushProx 允许 Prometheus 跨网络边界抓取指标，这样，用户就不用必须为 Kubernetes 集群中每个节点上的内部 Kubernetes 组件公开指标端口。
|
||||
|
||||
由于 Kubernetes 组件的指标通常暴露在集群中节点的主机网络上，PushProx 部署了一个客户端 DaemonSet，这些客户端位于每个节点的主机网络上，并与位于 Kubernetes API 上的单个代理建立出站连接。然后，你可以让 Prometheus 通过代理将抓取请求发送到每个客户端，这样，Prometheus 能从内部 Kubernetes 组件抓取指标，而不需要打开任何入站节点端口。
|
||||
|
||||
有关更多信息，请参阅[使用 PushProx 抓取指标](#使用-pushprox-抓取指标)。
|
||||
|
||||
## 5. 抓取和公开指标
|
||||
|
||||
### 定义要抓取的指标
|
||||
|
||||
ServiceMonitor 和 PodMonitor 定义了 Prometheus 要抓取的目标。[Prometheus 自定义资源](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md#prometheus)告诉 Prometheus 应该使用哪个 ServiceMonitor 或 PodMonitor 来确定从哪里抓取指标。
|
||||
|
||||
Prometheus Operator 观察 ServiceMonitor 和 PodMonitor。当它观察到二者被创建或更新时，它会调用 Prometheus API 来更新 Prometheus 自定义资源中的抓取配置，并使该配置与 ServiceMonitor 或 PodMonitor 中的抓取配置保持同步。此抓取配置告诉 Prometheus 从哪些端点抓取指标，以及如何标记这些端点的指标。
|
||||
|
||||
Prometheus 会根据 `scrape_interval`（默认为一分钟）来抓取定义在抓取配置中的所有指标。
|
||||
|
||||
抓取配置可以作为 Prometheus 自定义资源的一部分被查看，该资源在 Rancher UI 中公开。
|
||||
|
||||
### Prometheus Operator 如何设置指标抓取
|
||||
|
||||
Prometheus Deployment 或 StatefulSet 能抓取指标，而 Prometheus 的配置由 Prometheus 自定义资源控制。Prometheus Operator 会观察 Prometheus 和 Alertmanager 资源，当它们被创建时，Prometheus Operator 使用用户定义的配置，为 Prometheus 或 Alertmanager 创建一个 Deployment 或 StatefulSet。
|
||||
|
||||
如果 Prometheus Operator 观察到正在创建的 ServiceMonitor、PodMonitor 和 PrometheusRule，它就知道需要在 Prometheus 中更新抓取配置。首先，会通过更新 Prometheus 的 Deployment 或 StatefulSet 卷中的配置和规则文件来更新 Prometheus。然后，再调用 Prometheus API 来同步新配置，从而将 Prometheus Deployment 或 StatefulSet 修改到位。
|
||||
|
||||
### 如何公开 Kubernetes 组件指标
|
||||
|
||||
Prometheus 从称为 [exporter](https://prometheus.io/docs/instrumenting/exporters/) 的 deployment 中抓取指标，exporter 以 Prometheus 可以抓取的格式导出时间序列数据。在 Prometheus 中，时间序列由属于相同指标和相同标记维度集的时间戳值流组成。
|
||||
|
||||
### 使用 PushProx 抓取指标
|
||||
|
||||
某些内部 Kubernetes 组件是通过部署在 Monitoring V2 中名为 PushProx 的代理来抓取的。有关 PushProx 的详细信息，请参阅[此处](#pushprox-的工作原理)和上面的[架构](#1-架构概述)部分。
|
||||
|
||||
### 抓取指标
|
||||
|
||||
Prometheus 直接抓取以下 Kubernetes 组件：
|
||||
|
||||
- kubelet\*
|
||||
- ingress-nginx\*\*
|
||||
- coreDns/kubeDns
|
||||
- kube-api-server
|
||||
|
||||
\* 你可以选择通过 `hardenedKubelet.enabled` 来使用 PushProx，但这不是默认设置。
|
||||
|
||||
\*\* RKE 和 RKE2 集群默认部署 ingress-nginx，并将其视为内部 Kubernetes 组件。
|
||||
|
||||
|
||||
### 基于 Kubernetes 发行版抓取指标
|
||||
|
||||
指标的抓取方式根据 Kubernetes 发行版而有所不同。有关术语的帮助，请参阅[此处](#名词解释)。详情见下表：
|
||||
|
||||
<figcaption>指标如何暴露给 Prometheus</figcaption>
|
||||
|
||||
| Kubernetes 组件 | RKE | RKE2 | KubeADM | K3s |
|
||||
|-----|-----|-----|-----|-----|
|
||||
| kube-controller-manager | rkeControllerManager.enabled | rke2ControllerManager.enabled | kubeAdmControllerManager.enabled | k3sServer.enabled |
|
||||
| kube-scheduler | rkeScheduler.enabled | rke2Scheduler.enabled | kubeAdmScheduler.enabled | k3sServer.enabled |
|
||||
| etcd | rkeEtcd.enabled | rke2Etcd.enabled | kubeAdmEtcd.enabled | 不可用 |
|
||||
| kube-proxy | rkeProxy.enabled | rke2Proxy.enabled | kubeAdmProxy.enabled | k3sServer.enabled |
|
||||
| kubelet | 收集 kubelet 直接公开的指标 | 收集 kubelet 直接公开的指标 | 收集 kubelet 直接公开的指标 | 收集 kubelet 直接公开的指标 |
|
||||
| ingress-nginx* | 收集 kubelet 直接公开的指标，由 rkeIngressNginx.enabled 公开 | 收集 kubelet 直接公开的指标，由 rke2IngressNginx.enabled 公开 | 不可用 | 不可用 |
|
||||
| coreDns/kubeDns | 收集 coreDns/kubeDns 直接公开的指标 | 收集 coreDns/kubeDns 直接公开的指标 | 收集 coreDns/kubeDns 直接公开的指标 | 收集 coreDns/kubeDns 直接公开的指标 |
|
||||
| kube-api-server | 收集 kube-api-server 直接公开的指标 | 收集 kube-api-server 直接公开的指标 | 收集 kube-appi-server 直接公开的指标 | 收集 kube-api-server 直接公开的指标 |
|
||||
|
||||
\* RKE 和 RKE2 集群默认部署 ingress-nginx，并将其视为内部 Kubernetes 组件。
|
||||
|
||||
### 名词解释
|
||||
|
||||
- **kube-scheduler**：内部 Kubernetes 组件，该组件使用 pod 规范中的信息来决定在哪个节点上运行 pod。
|
||||
- **kube-controller-manager**：负责节点管理（检测节点是否失败）、pod 复制，以及端点创建的内部 Kubernetes 组件。
|
||||
- **etcd**：Kubernetes 内部组件，它是 Kubernetes 用于持久存储所有集群信息的分布式键/值存储。
|
||||
- **kube-proxy**：内部 Kubernetes 组件，用于监控 API server 的 pod/service 更改以保持网络最新状态。
|
||||
- **kubelet**：内部 Kubernetes 组件，用于为 pod 监视节点上的 API server 并确保这些 pod 能运行。
|
||||
- **ingress-nginx**：用于 Kubernetes 的 Ingress controller，使用 NGINX 作为反向代理和负载均衡器。
|
||||
- **coreDns/kubeDns**：负责 DNS 的内部 Kubernetes 组件。
|
||||
- **kube-api-server**：负责为其他 master 组件公开 API 的主要内部 Kubernetes 组件。
|
||||
+106
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: 监控和告警
|
||||
description: Prometheus 允许你查看来自不同 Rancher 和 Kubernetes 对象的指标。了解监控范围以及如何启用集群监控
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/monitoring-and-alerting"/>
|
||||
</head>
|
||||
|
||||
你可以使用 `rancher-monitoring` 应用，将业界领先的开源监控和告警解决方案快速部署到你的集群中。
|
||||
|
||||
在 Rancher v2.5 中引入的 `rancher-monitoring` operator 由 [Prometheus](https://prometheus.io/)、[Grafana](https://grafana.com/grafana/)、[Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/)， [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator) 和 [Prometheus adapter](https://github.com/DirectXMan12/k8s-prometheus-adapter) 提供支持。
|
||||
|
||||
有关在 Rancher v2.2 到 v2.4 中可用的 V1 监控和告警的信息，请参阅 Rancher v2.0 到 v2.4 文档中的[集群监控](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md)，[告警](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md)，[通知](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md)和[工具](/versioned_docs/version-2.0-2.4/reference-guides/rancher-project-tools/rancher-project-tools.md)。
|
||||
|
||||
使用 `rancher-monitoring` 应用程序，你可以快速部署领先的开源监控和告警解决方案到你的集群上。
|
||||
|
||||
### 功能
|
||||
|
||||
Prometheus 支持查看 Rancher 和 Kubernetes 对象的指标。通过使用时间戳，Prometheus 能让你通过 Rancher UI 或 Grafana（与 Prometheus 一起部署的分析查看平台）以更容易阅读的图表和视觉形式来查询和查看这些指标。
|
||||
|
||||
通过查看 Prometheus 从集群的 controlplane、节点和 deployment 中抓取的数据，你可以随时了解集群中发生的所有事件。然后，你可以使用这些分析来更好地运行你的环境，例如在系统紧急情况发生之前阻止它们、制定维护策略，或恢复崩溃的服务器。
|
||||
|
||||
Monitoring 应用：
|
||||
|
||||
- 监控集群节点、Kubernetes 组件和软件部署的状态和进程。
|
||||
- 根据 Prometheus 收集的指标定义告警。
|
||||
- 创建自定义 Grafana 仪表板。
|
||||
- 使用 Prometheus Alertmanager 通过电子邮件、Slack、PagerDuty 等配置告警通知。
|
||||
- 根据 Prometheus 收集的指标，将预先计算的、经常需要的，或计算成本高的表达式定义为新的时间序列。
|
||||
- 通过 Prometheus Adapter，将从 Prometheus 收集的指标公开给 Kubernetes Custom Metrics API，以便在 HPA 中使用。
|
||||
|
||||
有关监控组件如何协同工作的说明，请参阅 [Monitoring 工作原理](how-monitoring-works.md)。
|
||||
|
||||
## 默认组件和部署
|
||||
|
||||
### 内置仪表板
|
||||
|
||||
默认情况下，监控应用将 Grafana 仪表板（由 [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus) 项目策划）部署到集群上。
|
||||
|
||||
它还部署一个 Alertmanager UI 和一个 Prometheus UI。有关这些工具的更多信息，请参见[内置仪表板](built-in-dashboards.md)。
|
||||
|
||||
### 默认指标 Exporter
|
||||
|
||||
默认情况下，Rancher Monitoring 会部署 Exporter（例如 [node-exporter](https://github.com/prometheus/node_exporter) 和 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)）。
|
||||
|
||||
这些默认 Exporter 会自动从 Kubernetes 集群的所有组件（包括工作负载）中抓取 CPU 和内存的指标。
|
||||
|
||||
### 默认告警
|
||||
|
||||
Monitoring 应用会默认部署一些告警。要查看默认告警，请转到 [Alertmanager UI](built-in-dashboards.md#alertmanager-ui) 并单击**展开所有组**。
|
||||
|
||||
### Rancher UI 中公开的组件
|
||||
|
||||
有关 Rancher UI 中公开的监控组件列表，以及编辑它们的常见用例，请参阅[本节](how-monitoring-works.md#rancher-ui-中公开的组件)。
|
||||
|
||||
## RBAC
|
||||
|
||||
有关配置 monitoring 访问权限的信息，请参阅[此页面](rbac-for-monitoring.md)。
|
||||
|
||||
:::note
|
||||
|
||||
Rancher 和 Project 的读取权限并不一定适用于监控相关资源. 查看 [monitoring-ui-view](rbac-for-monitoring.md#其他监控角色) 获取更多详细信息.
|
||||
|
||||
:::
|
||||
|
||||
## 指南
|
||||
|
||||
- [启用 monitoring](../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/enable-monitoring.md)
|
||||
- [卸载 monitoring](../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/uninstall-monitoring.md)
|
||||
- [Monitoring 工作负载](../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/set-up-monitoring-for-workloads.md)
|
||||
- [自定义 Grafana 仪表板](../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/customize-grafana-dashboard.md)
|
||||
- [持久化 Grafana 仪表板](../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/create-persistent-grafana-dashboard.md)
|
||||
- [调试高内存使用率](../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/debug-high-memory-usage.md)
|
||||
|
||||
## 配置
|
||||
|
||||
### 在 Rancher 中配置 Monitoring 资源
|
||||
|
||||
此处的配置参考假设你已经熟悉 monitoring 组件的协同工作方式。如需更多信息，请参阅 [monitoring 的工作原理](how-monitoring-works.md)。
|
||||
|
||||
- [ServiceMonitor 和 PodMonitor](../../reference-guides/monitoring-v2-configuration/servicemonitors-and-podmonitors.md)
|
||||
- [接收器](../../reference-guides/monitoring-v2-configuration/receivers.md)
|
||||
- [路由](../../reference-guides/monitoring-v2-configuration/routes.md)
|
||||
- [PrometheusRule](../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheusrules.md)
|
||||
- [Prometheus](../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheus.md)
|
||||
- [Alertmanager](../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md)
|
||||
|
||||
### 配置 Helm Chart 选项
|
||||
|
||||
有关 `rancher-monitoring` Chart 选项的更多信息，包括设置资源限制和请求的选项，请参阅 [Helm Chart 选项](../../reference-guides/monitoring-v2-configuration/helm-chart-options.md)。
|
||||
|
||||
## Windows 集群支持
|
||||
|
||||
如果 Monitoring 部署到 RKE1 Windows 集群，Monitoring V2 将自动部署 [windows-exporter](https://github.com/prometheus-community/windows_exporter) DaemonSet 并设置 ServiceMonitor，以从每个部署的 Pod 中收集指标。这将使用 `windows_` 指标填充 Prometheus，这些指标与 [node_exporter](https://github.com/prometheus/node_exporter) 为 Linux 主机导出的 `node_` 指标类似。
|
||||
|
||||
为了能够为 Windows 完全部署 Monitoring V2，你的所有 Windows 主机都必须至少具有 v0.1.0 的 [wins](https://github.com/rancher/wins) 版本。
|
||||
|
||||
有关如何在现有 Windows 主机上升级 wins 版本的更多信息，请参阅 [Windows 集群对 Monitoring V2 的支持](windows-support.md)。
|
||||
|
||||
|
||||
## 已知问题
|
||||
|
||||
有一个[已知问题](https://github.com/rancher/rancher/issues/28787#issuecomment-693611821)，即 K3s 集群需要的内存超过分配的默认内存。如果你在 K3s 集群上启用 Monitoring，将 `prometheus.prometheusSpec.resources.memory.limit` 设置为 2500 Mi，并将 `prometheus.prometheusSpec.resources.memory.request` 设置为 1750 Mi。
|
||||
|
||||
如需获取意见和建议，请参阅[调试高内存使用情况](../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/debug-high-memory-usage.md)。
|
||||
+365
@@ -0,0 +1,365 @@
|
||||
---
|
||||
title: PromQL 表达式参考
|
||||
---
|
||||
|
||||
本文档中的 PromQL 表达式可用于配置告警。
|
||||
|
||||
关于查询 Prometheus 时间序列数据库的更多信息，请参阅 [Prometheus 官方文档](https://prometheus.io/docs/prometheus/latest/querying/basics/)。
|
||||
|
||||
|
||||
## 集群指标
|
||||
|
||||
### 集群 CPU 利用率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `1 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance))` |
|
||||
| 摘要 | `1 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])))` |
|
||||
|
||||
### 集群平均负载
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>load1</td><td>`sum(node_load1) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`</td></tr><tr><td>load5</td><td>`sum(node_load5) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`</td></tr><tr><td>load15</td><td>`sum(node_load15) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>load1</td><td>`sum(node_load1) by (instance) / count(node_cpu_seconds_total{mode="system"})`</td></tr><tr><td>load5</td><td>`sum(node_load5) by (instance) / count(node_cpu_seconds_total{mode="system"})`</td></tr><tr><td>load15</td><td>`sum(node_load15) by (instance) / count(node_cpu_seconds_total{mode="system"})`</td></tr></table> |
|
||||
|
||||
### 集群内存利用率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `1 - sum(node_memory_MemAvailable_bytes) by (instance) / sum(node_memory_MemTotal_bytes) by (instance)` |
|
||||
| 摘要 | `1 - sum(node_memory_MemAvailable_bytes) / sum(node_memory_MemTotal_bytes)` |
|
||||
|
||||
### 集群磁盘利用率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `(sum(node_filesystem_size_bytes{device!="rootfs"}) by (instance) - sum(node_filesystem_free_bytes{device!="rootfs"}) by (instance)) / sum(node_filesystem_size_bytes{device!="rootfs"}) by (instance)` |
|
||||
| 摘要 | `(sum(node_filesystem_size_bytes{device!="rootfs"}) - sum(node_filesystem_free_bytes{device!="rootfs"})) / sum(node_filesystem_size_bytes{device!="rootfs"})` |
|
||||
|
||||
### 集群磁盘 I/O
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total[5m])) by (instance)`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total[5m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total[5m]))`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total[5m]))`</td></tr></table> |
|
||||
|
||||
### 集群网络数据包
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)</code></td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))</code></td></tr></table> |
|
||||
|
||||
### 集群网络 I/O
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)</code></td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))</code></td></tr></table> |
|
||||
|
||||
## 节点指标
|
||||
|
||||
### 节点 CPU 利用率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `avg(irate(node_cpu_seconds_total{mode!="idle", instance=~"$instance"}[5m])) by (mode)` |
|
||||
| 摘要 | `1 - (avg(irate(node_cpu_seconds_total{mode="idle", instance=~"$instance"}[5m])))` |
|
||||
|
||||
### 节点平均负载
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>load1</td><td>`sum(node_load1{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load5</td><td>`sum(node_load5{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load15</td><td>`sum(node_load15{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>load1</td><td>`sum(node_load1{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load5</td><td>`sum(node_load5{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load15</td><td>`sum(node_load15{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr></table> |
|
||||
|
||||
### 节点内存利用率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `1 - sum(node_memory_MemAvailable_bytes{instance=~"$instance"}) / sum(node_memory_MemTotal_bytes{instance=~"$instance"})` |
|
||||
| 摘要 | `1 - sum(node_memory_MemAvailable_bytes{instance=~"$instance"}) / sum(node_memory_MemTotal_bytes{instance=~"$instance"}) ` |
|
||||
|
||||
### 节点磁盘利用率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `(sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"}) by (device) - sum(node_filesystem_free_bytes{device!="rootfs",instance=~"$instance"}) by (device)) / sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"}) by (device)` |
|
||||
| 摘要 | `(sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"}) - sum(node_filesystem_free_bytes{device!="rootfs",instance=~"$instance"})) / sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"})` |
|
||||
|
||||
### 节点磁盘 I/O
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total{instance=~"$instance"}[5m]))`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total{instance=~"$instance"}[5m]))`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total{instance=~"$instance"}[5m]))`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total{instance=~"$instance"}[5m]))`</td></tr></table> |
|
||||
|
||||
### 节点网络数据包
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))</code></td></tr></table> |
|
||||
|
||||
### 节点网络 I/O
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))</code></td></tr></table> |
|
||||
|
||||
## ETCD 指标
|
||||
|
||||
### ETCD 有一个 Leader
|
||||
|
||||
`max(etcd_server_has_leader)`
|
||||
|
||||
### Leader 更换次数
|
||||
|
||||
`max(etcd_server_leader_changes_seen_total)`
|
||||
|
||||
### 失败的 Proposal 数量
|
||||
|
||||
`sum(etcd_server_proposals_failed_total)`
|
||||
|
||||
### GRPC 客户端流量
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>in</td><td>`sum(rate(etcd_network_client_grpc_received_bytes_total[5m])) by (instance)`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_client_grpc_sent_bytes_total[5m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>in</td><td>`sum(rate(etcd_network_client_grpc_received_bytes_total[5m]))`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_client_grpc_sent_bytes_total[5m]))`</td></tr></table> |
|
||||
|
||||
### 对等流量
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>in</td><td>`sum(rate(etcd_network_peer_received_bytes_total[5m])) by (instance)`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_peer_sent_bytes_total[5m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>in</td><td>`sum(rate(etcd_network_peer_received_bytes_total[5m]))`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_peer_sent_bytes_total[5m]))`</td></tr></table> |
|
||||
|
||||
### 数据库大小
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(etcd_debugging_mvcc_db_total_size_in_bytes) by (instance)` |
|
||||
| 摘要 | `sum(etcd_debugging_mvcc_db_total_size_in_bytes)` |
|
||||
|
||||
### 活动流
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>lease-watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) by (instance) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) by (instance)`</td></tr><tr><td>watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) by (instance) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>lease-watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"})`</td></tr><tr><td>watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"})`</td></tr></table> |
|
||||
|
||||
### Raft 方案
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>applied</td><td>`sum(increase(etcd_server_proposals_applied_total[5m])) by (instance)`</td></tr><tr><td>committed</td><td>`sum(increase(etcd_server_proposals_committed_total[5m])) by (instance)`</td></tr><tr><td>pending</td><td>`sum(increase(etcd_server_proposals_pending[5m])) by (instance)`</td></tr><tr><td>failed</td><td>`sum(increase(etcd_server_proposals_failed_total[5m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>applied</td><td>`sum(increase(etcd_server_proposals_applied_total[5m]))`</td></tr><tr><td>committed</td><td>`sum(increase(etcd_server_proposals_committed_total[5m]))`</td></tr><tr><td>pending</td><td>`sum(increase(etcd_server_proposals_pending[5m]))`</td></tr><tr><td>failed</td><td>`sum(increase(etcd_server_proposals_failed_total[5m]))`</td></tr></table> |
|
||||
|
||||
### RPC 速率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>total</td><td>`sum(rate(grpc_server_started_total{grpc_type="unary"}[5m])) by (instance)`</td></tr><tr><td>fail</td><td>`sum(rate(grpc_server_handled_total{grpc_type="unary",grpc_code!="OK"}[5m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>total</td><td>`sum(rate(grpc_server_started_total{grpc_type="unary"}[5m]))`</td></tr><tr><td>fail</td><td>`sum(rate(grpc_server_handled_total{grpc_type="unary",grpc_code!="OK"}[5m]))`</td></tr></table> |
|
||||
|
||||
### 磁盘操作
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>commit-called-by-backend</td><td>`sum(rate(etcd_disk_backend_commit_duration_seconds_sum[1m])) by (instance)`</td></tr><tr><td>fsync-called-by-wal</td><td>`sum(rate(etcd_disk_wal_fsync_duration_seconds_sum[1m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>commit-called-by-backend</td><td>`sum(rate(etcd_disk_backend_commit_duration_seconds_sum[1m]))`</td></tr><tr><td>fsync-called-by-wal</td><td>`sum(rate(etcd_disk_wal_fsync_duration_seconds_sum[1m]))`</td></tr></table> |
|
||||
|
||||
### 磁盘同步持续时间
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>wal</td><td>`histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le))`</td></tr><tr><td>db</td><td>`histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le))`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>wal</td><td>`sum(histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le)))`</td></tr><tr><td>db</td><td>`sum(histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le)))`</td></tr></table> |
|
||||
|
||||
## Kubernetes 组件指标
|
||||
|
||||
### API Server 请求延迟
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `avg(apiserver_request_latencies_sum / apiserver_request_latencies_count) by (instance, verb) /1e+06` |
|
||||
| 摘要 | `avg(apiserver_request_latencies_sum / apiserver_request_latencies_count) by (instance) /1e+06` |
|
||||
|
||||
### API Server 请求速率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(apiserver_request_count[5m])) by (instance, code)` |
|
||||
| 摘要 | `sum(rate(apiserver_request_count[5m])) by (instance)` |
|
||||
|
||||
### 调度失败的 Pod
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(kube_pod_status_scheduled{condition="false"})` |
|
||||
| 摘要 | `sum(kube_pod_status_scheduled{condition="false"})` |
|
||||
|
||||
### Controller Manager 队列深度
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>volumes</td><td>`sum(volumes_depth) by instance`</td></tr><tr><td>deployment</td><td>`sum(deployment_depth) by instance`</td></tr><tr><td>replicaset</td><td>`sum(replicaset_depth) by instance`</td></tr><tr><td>service</td><td>`sum(service_depth) by instance`</td></tr><tr><td>serviceaccount</td><td>`sum(serviceaccount_depth) by instance`</td></tr><tr><td>endpoint</td><td>`sum(endpoint_depth) by instance`</td></tr><tr><td>daemonset</td><td>`sum(daemonset_depth) by instance`</td></tr><tr><td>statefulset</td><td>`sum(statefulset_depth) by instance`</td></tr><tr><td>replicationmanager</td><td>`sum(replicationmanager_depth) by instance`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>volumes</td><td>`sum(volumes_depth)`</td></tr><tr><td>deployment</td><td>`sum(deployment_depth)`</td></tr><tr><td>replicaset</td><td>`sum(replicaset_depth)`</td></tr><tr><td>service</td><td>`sum(service_depth)`</td></tr><tr><td>serviceaccount</td><td>`sum(serviceaccount_depth)`</td></tr><tr><td>endpoint</td><td>`sum(endpoint_depth)`</td></tr><tr><td>daemonset</td><td>`sum(daemonset_depth)`</td></tr><tr><td>statefulset</td><td>`sum(statefulset_depth)`</td></tr><tr><td>replicationmanager</td><td>`sum(replicationmanager_depth)`</td></tr></table> |
|
||||
|
||||
### 调度器 E2E 调度延迟
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `histogram_quantile(0.99, sum(scheduler_e2e_scheduling_latency_microseconds_bucket) by (le, instance)) / 1e+06` |
|
||||
| 摘要 | `sum(histogram_quantile(0.99, sum(scheduler_e2e_scheduling_latency_microseconds_bucket) by (le, instance)) / 1e+06)` |
|
||||
|
||||
### 调度器抢占尝试
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(scheduler_total_preemption_attempts[5m])) by (instance)` |
|
||||
| 摘要 | `sum(rate(scheduler_total_preemption_attempts[5m]))` |
|
||||
|
||||
### Ingress Controller 连接数
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>reading</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="reading"}) by (instance)`</td></tr><tr><td>waiting</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"}) by (instance)`</td></tr><tr><td>writing</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="writing"}) by (instance)`</td></tr><tr><td>accepted</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m]))) by (instance)`</td></tr><tr><td>active</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m]))) by (instance)`</td></tr><tr><td>handled</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m]))) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>reading</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="reading"})`</td></tr><tr><td>waiting</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"})`</td></tr><tr><td>writing</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="writing"})`</td></tr><tr><td>accepted</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m])))`</td></tr><tr><td>active</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m])))`</td></tr><tr><td>handled</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m])))`</td></tr></table> |
|
||||
|
||||
### Ingress Controller 请求处理时间
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `topk(10, histogram_quantile(0.95,sum by (le, host, path)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` |
|
||||
| 摘要 | `topk(10, histogram_quantile(0.95,sum by (le, host)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` |
|
||||
|
||||
## Rancher Logging 指标
|
||||
|
||||
|
||||
### Fluentd 缓冲区队列速率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(fluentd_output_status_buffer_queue_length[5m])) by (instance)` |
|
||||
| 摘要 | `sum(rate(fluentd_output_status_buffer_queue_length[5m]))` |
|
||||
|
||||
### Fluentd 输入速率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(fluentd_input_status_num_records_total[5m])) by (instance)` |
|
||||
| 摘要 | `sum(rate(fluentd_input_status_num_records_total[5m]))` |
|
||||
|
||||
### Fluentd 输出错误率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(fluentd_output_status_num_errors[5m])) by (type)` |
|
||||
| 摘要 | `sum(rate(fluentd_output_status_num_errors[5m]))` |
|
||||
|
||||
### Fluentd 输出速率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(fluentd_output_status_num_records_total[5m])) by (instance)` |
|
||||
| 摘要 | `sum(rate(fluentd_output_status_num_records_total[5m]))` |
|
||||
|
||||
## 工作负载指标
|
||||
|
||||
### 工作负载 CPU 利用率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### 工作负载内存利用率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(container_memory_working_set_bytes{namespace="$namespace",pod_name=~"$podName", container_name!=""}) by (pod_name)` |
|
||||
| 摘要 | `sum(container_memory_working_set_bytes{namespace="$namespace",pod_name=~"$podName", container_name!=""})` |
|
||||
|
||||
### 工作负载网络数据包
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### 工作负载网络 I/O
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### 工作负载磁盘 I/O
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
## Pod 指标
|
||||
|
||||
### Pod CPU 利用率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### Pod 内存利用率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(container_memory_working_set_bytes{container_name!="POD",namespace="$namespace",pod_name="$podName",container_name!=""}) by (container_name)` |
|
||||
| 摘要 | `sum(container_memory_working_set_bytes{container_name!="POD",namespace="$namespace",pod_name="$podName",container_name!=""})` |
|
||||
|
||||
### Pod 网络数据包
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### Pod 网络 I/O
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### Pod 磁盘 I/O
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
## 容器指标
|
||||
|
||||
### 容器 CPU 利用率
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| cfs throttled seconds | `sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
| usage seconds | `sum(rate(container_cpu_usage_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
| system seconds | `sum(rate(container_cpu_system_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
| user seconds | `sum(rate(container_cpu_user_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
|
||||
### 容器内存利用率
|
||||
|
||||
`sum(container_memory_working_set_bytes{namespace="$namespace",pod_name="$podName",container_name="$containerName"})`
|
||||
|
||||
### 容器磁盘 I/O
|
||||
|
||||
| Catalog | 表达式 |
|
||||
| --- | --- |
|
||||
| read | `sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
| write | `sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
+251
@@ -0,0 +1,251 @@
|
||||
---
|
||||
title: RBAC
|
||||
---
|
||||
本节描述了 RBAC 在 Rancher Monitoring 中的作用。
|
||||
|
||||
|
||||
## 集群管理员
|
||||
|
||||
默认情况下，只有具有 cluster-admin `ClusterRole` 的用户才能：
|
||||
|
||||
- 将 `rancher-monitoring` 应用安装到集群上，并在 Chart 部署上执行所有其他相关配置。
|
||||
- 例如，是否创建了默认仪表板，要将哪些 Exporter 部署到集群上以收集指标等。
|
||||
- 通过 Prometheus CR 在集群中创建/修改/删除 Prometheus deployment。
|
||||
- 通过 Alertmanager CR 在集群中创建/修改/删除 Alertmanager deployment。
|
||||
- 通过在命名空间中创建 ConfigMap 来保留新的 Grafana 仪表板或数据源。
|
||||
- 通过 `cattle-monitoring-system` 命名空间中的 Secret 将某些 Prometheus 指标暴露给 HPA 的 K8s Custom Metrics API。
|
||||
|
||||
## 具有基于 Kubernetes ClusterRole 权限的用户
|
||||
|
||||
`rancher-monitoring` Chart 安装了以下三个 `ClusterRole`。默认情况下，它们会聚合到相应的 K8s `ClusterRole` 中：
|
||||
|
||||
| ClusterRole | 聚合到默认的 K8s ClusterRole |
|
||||
| ------------------------------| ---------------------------|
|
||||
| `monitoring-admin` | `admin` |
|
||||
| `monitoring-edit` | `edit` |
|
||||
| `monitoring-view` | `view ` |
|
||||
|
||||
这些 `ClusterRole` 根据可执行的操作提供对 Monitoring CRD 的不同访问级别：
|
||||
|
||||
| CRD (monitoring.coreos.com) | Admin | Edit | View |
|
||||
| ------------------------------| ---------------------------| ---------------------------| ---------------------------|
|
||||
| <ul><li>`prometheuses`</li><li>`alertmanagers`</li></ul> | Get, List, Watch | Get, List, Watch | Get, List, Watch |
|
||||
| <ul><li>`servicemonitors`</li><li>`podmonitors`</li><li>`prometheusrules`</li></ul> | * | * | Get, List, Watch |
|
||||
|
||||
在较高级别上，默认情况下会分配以下权限。
|
||||
|
||||
### 具有 Kubernetes 管理员/编辑权限的用户
|
||||
|
||||
只有具有 cluster-admin、admin 或 edit 的 `ClusterRole` 可以：
|
||||
|
||||
- 通过 ServiceMonitor 和 PodMonitor CR 修改 Prometheus deployment 的抓取配置。
|
||||
- 通过 PrometheusRules CR 修改 Prometheus deployment 的告警/记录规则。
|
||||
|
||||
### 具有 Kubernetes 查看权限的用户
|
||||
|
||||
只有具有 Kubernetes `ClusterRole` 的用户可以：
|
||||
|
||||
- 查看集群内部署的 Prometheuses 的配置。
|
||||
- 查看集群内部署的 Alertmanagers 的配置。
|
||||
- 通过 ServiceMonitor 和 PodMonitor CR 查看 Prometheus deployment 的抓取配置。
|
||||
- 通过 PrometheusRules CR 查看 Prometheus deployment 的告警/记录规则。
|
||||
|
||||
### 其他监控角色
|
||||
|
||||
Monitoring 还会创建其他 `Role`，这些角色默认情况下不会分配给用户，而是在集群中创建。你可以部署引用角色的 `RoleBinding` 来将角色绑定到命名空间。要使用 `kubectl` 而不是通过 Rancher 来定义 `RoleBinding`，请单击[此处](#使用-kubectl-分配-role-和-clusterrole)。
|
||||
|
||||
管理员应使用这些角色为用户提供更细粒度的访问权限：
|
||||
|
||||
| 角色 | 用途 |
|
||||
| ------------------------------| ---------------------------|
|
||||
| monitoring-config-admin | 允许管理员为用户分配角色，以便查看/编辑 cattle-monitoring-system 命名空间中的 Secret 和 ConfigMap。修改此命名空间中的 Secret/ConfigMap 可以允许用户更改集群的 Alertmanager 配置、Prometheus Adapter 配置、其他 Grafana 数据源、TLS 密钥等。 |
|
||||
| monitoring-config-edit | 允许管理员为用户分配角色，以便查看/编辑 cattle-monitoring-system 命名空间中的 Secret 和 ConfigMap。修改此命名空间中的 Secret/ConfigMap 可以允许用户更改集群的 Alertmanager 配置、Prometheus Adapter 配置、其他 Grafana 数据源、TLS 密钥等。 |
|
||||
| monitoring-config-view | 允许管理员为用户分配角色，以便查看 cattle-monitoring-system 命名空间中的 Secret 和 ConfigMap。查看此命名空间中的 Secret/ConfigMap 可以允许用户观察集群的 Alertmanager 配置、Prometheus Adapter 配置、其他 Grafana 数据源、TLS 密钥等。 |
|
||||
| monitoring-dashboard-admin | 允许管理员为用户分配角色，以便查看/编辑 cattle-dashboards 命名空间中的 ConfigMap。此命名空间中的 ConfigMap 将对应于持久化到集群上的 Grafana 仪表板。 |
|
||||
| monitoring-dashboard-edit | 允许管理员为用户分配角色，以便查看/编辑 cattle-dashboards 命名空间中的 ConfigMap。此命名空间中的 ConfigMap 将对应于持久化到集群上的 Grafana 仪表板。 |
|
||||
| monitoring-dashboard-view | 允许管理员为用户分配角色，以便查看 cattle-dashboards 命名空间中的 ConfigMap。此命名空间中的 ConfigMap 将对应于持久化到集群上的 Grafana 仪表板。 |
|
||||
|
||||
|
||||
### 通过自定义角色分配监控角色
|
||||
|
||||
管理员可以在 Rancher UI 中分配自定义角色以管理、编辑和查看监控。这些“角色”是在安装 Monitoring 应用程序时默认创建的。此外，这些角色也会被部署到相应的 Kubernetes 角色：admin、edit 和 view `ClusterRoles`。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
将用户添加到集群时，UI 不会提供 `monitoring-admin`、`monitoring-edit` 和 `monitoring-view` 选项。这些监控角色只能通过手动创建自定义角色来分配，该自定义角色继承 Project Owner 和 Project Monitoring View 角色。
|
||||
|
||||
:::
|
||||
|
||||
1. 创建自定义角色：
|
||||
|
||||
1.1 单击 **☰ > Users & Authentication > Roles**。
|
||||
|
||||
1.2 选择适当的选项卡，例如 **Cluster** 角色。然后单击 **Create Cluster Role**。
|
||||
|
||||
1.3 在 **Name** 字段中，创建自定义角色，例如 `View Monitoring`、`Edit Monitoring` 或 `Admin Monitoring`。
|
||||
|
||||
1.4 单击 **Inherit From > Add Resource**，然后从下拉列表中选择所需的 Kubernetes 角色。
|
||||
|
||||
1.5 单击 **Create**。
|
||||
|
||||
|
||||
2. 将自定义角色分配给新用户：
|
||||
|
||||
2.1 单击 **☰ > Cluster Management > Cluster Explore > Cluster > Cluster Members > Add**。
|
||||
|
||||
2.2 从显示的 **Select Member** 中搜索你的新用户名。
|
||||
|
||||
2.3 将 **Cluster Permissions** 中的新自定义角色分配给新用户。
|
||||
|
||||
2.4 单击 **Create**。
|
||||
|
||||
**结果**：新用户现在应该能够看到 monitoring 工具。
|
||||
|
||||
### 其他监控集群角色
|
||||
|
||||
Monitoring 还会创建其他 `ClusterRole`，这些角色默认情况下不会分配给用户，而是在集群中创建。默认情况下，这些角色不会聚合，但你可以部署引用角色的 `RoleBinding` 或 `ClusterRoleBinding` 来将角色绑定到命名空间。要使用 `kubectl` 而不是通过 Rancher 来定义 `RoleBinding`，请单击[此处](#使用-kubectl-分配-role-和-clusterrole)。
|
||||
|
||||
| 角色 | 用途 |
|
||||
| ------------------------------| ---------------------------|
|
||||
| monitoring-ui-view | <a id="monitoring-ui-view"></a>_自 Monitoring v2 14.5.100+ 起可用_ 此 ClusterRole 允许用户在 Rancher UI 中查看指定集群的指标图。这是通过授予对外部监控 UI 的只读访问权限来实现的。具有此角色的用户有权限列出 Prometheus、Alertmanager 和 Grafana 端点，并通过 Rancher 代理向 Prometheus、Grafana 和 Alertmanager UI 发出 GET 请求。 |
|
||||
|
||||
### 使用 kubectl 分配 Role 和 ClusterRole
|
||||
|
||||
#### 使用 `kubectl create`
|
||||
|
||||
一种方法是使用 `kubectl create clusterrolebinding` 或 `kubectl create rolebinding` 来分配一个 `Role` 或 `ClusterRole`。如以下示例所示：
|
||||
|
||||
- 分配给特定用户：
|
||||
<Tabs groupId="role-type">
|
||||
<TabItem value="clusterrolebinding">
|
||||
|
||||
```plain
|
||||
kubectl create clusterrolebinding my-binding --clusterrole=monitoring-ui-view --user=u-l4npx
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="rolebinding">
|
||||
|
||||
```plain
|
||||
kubectl create rolebinding my-binding --clusterrole=monitoring-ui-view --user=u-l4npx --namespace=my-namespace
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
- 分配给所有经过身份认证的用户：
|
||||
<Tabs groupId="role-type">
|
||||
<TabItem value="clusterrolebinding">
|
||||
|
||||
```plain
|
||||
kubectl create clusterrolebinding my-binding --clusterrole=monitoring-ui-view --group=system:authenticated
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="rolebinding">
|
||||
|
||||
```plain
|
||||
kubectl create rolebinding my-binding --clusterrole=monitoring-ui-view --group=system:authenticated --namespace=my-namespace
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
#### 使用 YAML 文件
|
||||
|
||||
另一种方法是在你创建的 YAML 文件中定义绑定。你必须先使用 YAML 文件配置 `RoleBinding` 或 `ClusterRoleBinding`。然后，通过运行 `kubectl apply` 命令来应用配置更改。
|
||||
|
||||
- **Role**：以下 YAML 文件示例可帮助你在 Kubernetes 中配置 `RoleBinding`。你需要在下面填写名称。
|
||||
|
||||
:::note
|
||||
|
||||
名称区分大小写。
|
||||
|
||||
:::
|
||||
|
||||
```yaml
|
||||
# monitoring-config-view-role-binding.yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: monitoring-config-view
|
||||
namespace: cattle-monitoring-system
|
||||
roleRef:
|
||||
kind: Role
|
||||
name: monitoring-config-view
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
subjects:
|
||||
- kind: User
|
||||
name: u-b4qkhsnliz # this can be found via `kubectl get users -A`
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
|
||||
- **kubectl**：以下 `kubectl` 示例命令用于应用 YAML 文件中创建的绑定。请记住相应填写你的 YAML 文件名。
|
||||
```plain
|
||||
kubectl apply -f monitoring-config-view-role-binding.yaml
|
||||
```
|
||||
|
||||
## 具有 Rancher 权限的用户
|
||||
|
||||
Rancher 部署的默认角色（即 cluster-owner、cluster-member、project-owner、project-member）、Kubernetes 默认角色，以及 rancher-monitoring Chart 部署的角色之间的关系如下：
|
||||
|
||||
<figcaption>默认 Rancher 权限和对应的 Kubernetes ClusterRole</figcaption>
|
||||
|
||||
| Rancher 角色 | Kubernetes 角色 | Monitoring ClusterRole/Role | ClusterRoleBinding/RoleBinding |
|
||||
| --------- | --------- | --------- | --------- |
|
||||
| cluster-owner | cluster-admin | N/A | ClusterRoleBinding |
|
||||
| cluster-member | admin | monitoring-admin | ClusterRoleBinding |
|
||||
| project-owner | admin | monitoring-admin | 项目命名空间中的 RoleBinding |
|
||||
| project-member | edit | monitoring-edit | 项目命名空间中的 RoleBinding |
|
||||
|
||||
除这些默认角色之外，你还可以将以下的其他 Rancher 项目角色应用于集群成员，以提供对 Monitoring 的其他访问。这些 Rancher 角色将与 Monitoring Chart 部署的 ClusterRole 相关联：
|
||||
|
||||
<figcaption>非默认的 Rancher 权限和对应的 Kubernetes ClusterRole</figcaption>
|
||||
|
||||
| Rancher 角色 | Kubernetes ClusterRole | 可用 Rancher 版本 | 可用 Monitoring V2 版本 |
|
||||
|--------------------------|-------------------------------|-------|------|
|
||||
| 查看 Monitoring\* | [monitoring-ui-view](#monitoring-ui-view) | 2.4.8+ | 9.4.204+ |
|
||||
|
||||
\* 如果某个用户绑定了 Rancher 的 **View Monitoring** 角色，该用户只有在有 UI 链接时才有权访问外部 Monitoring UI。要访问 Monitoring Pane 以获取这些链接，用户必须是至少一个项目的项目成员。
|
||||
|
||||
### 2.5.x 中的差异
|
||||
|
||||
在 Rancher 2.5.x 中，分配了 project-member 或 project-owner 角色的用户将无法访问 Prometheus 或 Grafana，因为我们仅在集群级别创建 Grafana 或 Prometheus。
|
||||
|
||||
此外，虽然 project-owner 仍然只能添加默认在项目命名空间内抓取资源的 ServiceMonitor/PodMonitor，但 PrometheusRule 并不局限于单个命名空间/项目。因此，即使 project-owner 无法查看/编辑/删除在项目命名空间之外创建的任何规则，project-owner 在其项目命名空间内创建的任何告警规则或记录规则都将应用于整个集群。
|
||||
|
||||
### 分配其他访问权限
|
||||
|
||||
如果 cluster-admin 想要为不具有 rancher-monitoring chart 角色的用户提供 admin/edit 访问权限，则存在下表的潜在影响：
|
||||
|
||||
| CRD (monitoring.coreos.com) | 是否会在命名空间/项目之外造成影响 | 影响 |
|
||||
|----------------------------| ------| ----------------------------|
|
||||
| `prometheuses` | 是。该资源可以从整个集群中的任何目标中抓取指标（除非 Operator 本身进行了额外的配置）。 | 用户将能够定义应在集群中创建的新集群级 Prometheus deployment 的配置。 |
|
||||
| `alertmanagers` | 否 | 用户将能够定义应在集群中创建的新集群级 Alertmanager deployment 的配置。注意：如果你只想允许用户配置路由和接收器等设置，你应该只提供对 Alertmanager Config Secret 的访问权限。 |
|
||||
| <ul><li>`servicemonitors`</li><li>`podmonitors`</li></ul> | 否（默认）。可以通过 Prometheus CR 上的 `ignoreNamespaceSelectors` 进行配置。 | 用户将能够通过 Prometheus，在他们被授予此权限的命名空间内的 Service/Pod 暴露的端点上设置抓取。 |
|
||||
| `prometheusrules` | 是。PrometheusRules 是集群范围的。 | 用户将能够根据在整个集群中收集的任何系列，在 Prometheus 上定义告警或记录规则。 |
|
||||
|
||||
| K8s 资源 | 命名空间 | 是否会在命名空间/项目之外造成影响 | 影响 |
|
||||
|----------------------------| ------| ------| ----------------------------|
|
||||
| <ul><li>`secrets`</li><li>`configmaps`</li></ul> | `cattle-monitoring-system` | 是。此命名空间中的 Config 和 Secret 会影响整个监控/告警流水线。 | 用户将能够创建或编辑 Secret/ ConfigMap，例如 Alertmanager Config、Prometheus Adapter 配置、TLS 密文、其他 Grafana 数据源等。这会对所有集群监控/告警产生广泛影响。 |
|
||||
| <ul><li>`secrets`</li><li>`configmaps`</li></ul> | `cattle-dashboards` | 是。此命名空间中的 Config 和 Secret 可以创建仪表板，对在集群级别收集的所有指标进行查询。 | 用户将能够创建仅保留新 Grafana 仪表板的 Secret/ConfigMap。 |
|
||||
|
||||
## Grafana 的 RBAC
|
||||
|
||||
对于经过 Kubernetes 认证并可以访问 Rancher Monitoring Chart 部署的 Grafana 服务的任何用户，Rancher 允许他们通过 Rancher Dashboard UI 访问 Grafana。默认情况下，所有能够访问 Grafana 的用户都被赋予 [Viewer](https://grafana.com/docs/grafana/latest/permissions/organization_roles/#viewer-role) 角色，能查看 Rancher 部署的任何默认仪表板。
|
||||
|
||||
但是，如果有需要的话，用户可以选择以 [Admin](https://grafana.com/docs/grafana/latest/permissions/organization_roles/#admin-role) 身份登录 Grafana。Grafana 实例的默认 Admin 用户名和密码是 `admin`/`prom-operator`，但你也可以在部署或升级 Chart 时替换凭证。
|
||||
|
||||
要查看 Grafana UI，请安装 `rancher-monitoring`。然后：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要可视化的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**监控**。
|
||||
1. 点击 **Grafana**。
|
||||
|
||||
<figcaption>Grafana 中的集群计算资源仪表板</figcaption>
|
||||
|
||||
|
||||
|
||||
<figcaption>Grafana 中的默认仪表板</figcaption>
|
||||
|
||||
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: Monitoring V2 的 Windows 集群支持
|
||||
---
|
||||
|
||||
_从 v2.5.8 起可用_
|
||||
|
||||
从 Monitoring V2 14.5.100（Rancher 2.5.8 的默认版本）开始，Monitoring V2 可以部署在 Windows 集群上，并将使用 [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter)（旧名是 `wmi_exporter`）来抓取 Windows 节点的指标。
|
||||
|
||||
## 集群要求
|
||||
|
||||
Monitoring V2 for Windows 只能从最低是 `wins` v0.1.0 的 Windows 主机中抓取指标。要完全部署 Monitoring V2 for Windows，你的所有主机都必须满足此要求。
|
||||
|
||||
如果你在 Rancher 2.5.8 中配置新的 RKE1 集群，你的集群应该已经满足此要求。
|
||||
|
||||
### 将现有集群升级到 wins v0.1.0
|
||||
|
||||
如果集群是在 Rancher 2.5.8 之前配置的（即使当前 Rancher 版本是 2.5.8），你将无法成功部署 Monitoring V2 for Windows，除非你将每台主机的 wins 版本升级到 v0.1.0 或以上版本。
|
||||
|
||||
为了方便此次升级，Rancher 2.5.8 发布了一个全新的 Helm Chart，名为 `rancher-wins-upgrader`。
|
||||
|
||||
1. 使用以下覆盖部署 `rancher-wins-upgrader`：
|
||||
```yaml
|
||||
# 通过先前已列入白名单的进程路径
|
||||
# 来引导 win-upgrader 安装，这是因为正常安装路径
|
||||
# c:\etc\rancher\wins\wins-upgrade.exe 通常不会被列入白名单。
|
||||
# 因此，我们使用 Monitoring V1 之前所用的
|
||||
# 已列入白名单的进程路径。
|
||||
masquerade:
|
||||
enabled: true
|
||||
as: c:\\etc\wmi-exporter\wmi-exporter.exe
|
||||
```
|
||||
:::note 非默认 Windows 前缀路径的注意事项：
|
||||
|
||||
- 如果你使用具有非默认 `win_prefix_path` 的 `cluster.yml` 来设置 RKE 集群，你需要将 `c:\\` 替换为你的前缀路径字段的值来修改 `masquerade.as`。
|
||||
|
||||
- 例如，如果你使用 `win_prefix_path: 'c:\host\opt\'`，则需要设置为 `as: c:\host\opt\etc\wmi-exporter\wmi-exporter.exe`。
|
||||
|
||||
:::
|
||||
|
||||
2. 成功升级所有主机后，请再次使用默认值部署 Helm Chart，以避免与以下设置发生冲突：
|
||||
```yaml
|
||||
masquerade:
|
||||
enabled: false
|
||||
```
|
||||
|
||||
**结果**：主机已准备好安装 Monitoring V2。你可以选择卸载 `rancher-wins-upgrader` Chart，或将其保留在集群中以方便将来升级。
|
||||
|
||||
有关如何使用它的更多信息，请参阅 Chart 的 [README.md](https://github.com/rancher/wins/blob/master/charts/rancher-wins-upgrader/README.md)。
|
||||
+199
@@ -0,0 +1,199 @@
|
||||
---
|
||||
title: NeuVector 集成
|
||||
---
|
||||
|
||||
### Rancher 中的 NeuVector 集成
|
||||
|
||||
[NeuVector 5.x](https://open-docs.neuvector.com/) 是一个开源的，以容器为中心的安全应用程序，Rancher 已集成 NeuVector。NeuVector 在运行时为关键应用程序和数据提供实时的合规、可见和保护功能。NeuVector 提供具有 CIS Benchmark 和漏洞扫描的防火墙、容器进程/文件系统监控和安全审计。有关 Rancher 安全性的更多信息，请参阅[安全文档](../pages-for-subheaders/rancher-security.md)。
|
||||
|
||||
NeuVector 可以通过 Helm Chart 启用。你可以在 **Apps** 或 Rancher UI 中的 **Cluster Tools** 中安装该 Chart。安装 Helm Chart 后，用户可以轻松地[在 Rancher 中部署和管理 NeuVector 集群](https://open-docs.neuvector.com/deploying/rancher#deploy-and-manage-neuvector-through-rancher-apps-marketplace)。
|
||||
|
||||
### 使用 Rancher 安装 NeuVector
|
||||
|
||||
Harvester Helm Chart 用于管理 Rancher 中 NeuVector UI 的访问，用户可以在 Rancher 中直接跳转，然后部署和管理 NeuVector 集群。
|
||||
|
||||
**通过 "Apps" 导航并安装 NeuVector Chart**：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 在 Clusters 页面上，转到要部署 NeuVector 的集群，然后单击 **Explore**。
|
||||
1. 转到 **Apps > Charts**，然后从 Chart 仓库中安装 **NeuVector**。
|
||||
1. 不同的集群类型需要不同的容器运行时。配置 Helm Chart 值时，转到**容器运行时**，然后根据集群类型选择运行时。最后，再次单击**安装**。
|
||||
|
||||
以下是一些例子：
|
||||
|
||||
- RKE1：`docker`
|
||||
- K3s 和 RKE2：`k3scontainerd`
|
||||
- AKS：`containerd` 适用于 v1.19 及更高版本
|
||||
- EKS：`docker` 适用于 v1.22 及以下版本；`containerd` 适用于 v1.23 及更高版本
|
||||
- GKE：`containerd`（请参阅 [Google 文档](https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd)了解更多信息）
|
||||
|
||||
:::note
|
||||
|
||||
在安装过程中一次只能选择一个容器运行时引擎。
|
||||
|
||||
:::
|
||||
|
||||
**通过集群工具导航并安装 NeuVector Chart**：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 在 Clusters 页面上，转到要部署 NeuVector 的集群，然后单击 **Explore**。
|
||||
1. 点击左侧导航栏底部的**集群工具**。
|
||||
1. 按照上面的步骤 4 相应地选择你的容器运行时，然后再次单击**安装**。
|
||||
|
||||
### 从 Rancher UI 访问 NeuVector
|
||||
|
||||
1. 导航到安装了 NeuVector 的集群的 Cluster Explorer。在左侧导航栏中，单击 **NeuVector**。
|
||||
1. 单击外部链接以转到 NeuVector UI。选择链接后，用户必须接受`最终用户许可协议`才能访问 NeuVector UI。
|
||||
|
||||
### 从 Rancher UI 卸载 NeuVector
|
||||
|
||||
**通过 "Apps" 卸载**：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 在 **Apps** 下，点击 **Installed Apps**。
|
||||
1. 在 `cattle-neuvector-system` 下，选择 NeuVector 应用程序（如果需要，还可以选择相关的 CRD），然后单击**删除**。
|
||||
|
||||
**通过集群工具卸载**：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 单击屏幕左下角的**集群工具**，然后单击 NeuVector Chart 下方的垃圾桶图标。如果需要，选择`删除与此应用关联的 CRD`，然后单击**删除**。
|
||||
|
||||
### GitHub 仓库
|
||||
|
||||
NeuVector 项目在[这里](https://github.com/neuvector/neuvector)。
|
||||
|
||||
### 文档
|
||||
|
||||
NeuVector 文档在[这里](https://open-docs.neuvector.com/)。
|
||||
|
||||
### 架构
|
||||
|
||||
NeuVector 安全解决方案包含四种类型的安全容器，分别是 Controller、Enforcer、Manager 和 Scanner。它还提供了一个称为 All-in-One 的特殊容器（主要用于 Docker 原生部署），能将 Controller、Enforcer 和 Manager 功能组合在一个容器中。此外，还有一个 Updater，运行该程序时会更新 CVE 数据库。
|
||||
|
||||
- **Controller**：管理 NeuVector Enforcer 容器；为管理控制台提供 REST API。
|
||||
- **Enforcer**：执行安全策略。
|
||||
- **Manager**：提供一个 web-UI 和 CLI 控制台来管理 NeuVector 平台。
|
||||
- **All-in-One**：包括 Controller、Enforcer 和 Manager。
|
||||
- **Scanner**：对镜像、容器和节点执行漏洞和合规性扫描。
|
||||
- **Updater**：更新 Neuvector 的 CVE 数据库（运行的时候）；重新部署 scanner pod。
|
||||
|
||||
<figcaption>**NeuVector 安全容器：**</figcaption>
|
||||
|
||||
|
||||
|
||||
<figcaption>**NeuVector 架构：**</figcaption>
|
||||
|
||||
|
||||
|
||||
要了解有关 NeuVector 架构的更多信息，请参阅[此处](https://open-docs.neuvector.com/basics/overview#architecture)。
|
||||
|
||||
### CPU 和内存分配
|
||||
|
||||
以下是默认 NeuVector Chart 安装部署的最低计算资源推荐。请注意，未设置资源限制。
|
||||
|
||||
| 容器 | CPU - 请求 | 内存 - 请求 |
|
||||
|------------|--------|---------|
|
||||
| Controller | 3（每个控制器需要 1GB 1vCPU） | * |
|
||||
| Enforcer | 所有节点上 (500MB .5vCPU) | 1GB |
|
||||
| Manager | 1 (500MB .5vCPU) | * |
|
||||
| Scanner | 3 (100MB .5vCPU) | * |
|
||||
|
||||
\* Controller、Manager 和 Scanner 容器合计至少需要 1GB 内存。
|
||||
|
||||
|
||||
### 强化集群支持 - Calico 和 Canal
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="RKE1">
|
||||
|
||||
- 如果 PSP 设置为 true，则所有 NeuVector 组件都是可部署的。
|
||||
|
||||
你需要为强化集群环境进行额外的配置，如下所示：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，点击 **Apps**。
|
||||
1. 安装（或升级到）NeuVector 版本 `100.0.1+up2.2.2`。
|
||||
|
||||
- 在 **编辑选项** > **其它配置**下，选中复选框来启用 **Pod 安全策略**（无需其他配置）：
|
||||
|
||||
|
||||
|
||||
1. 点击右下角的**安装**。
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
- 如果 PSP 设置为 true，则可以部署 NeuVector 组件 Controller 和 Enforcer。
|
||||
|
||||
|
||||
**仅适用于 NeuVector Chart 版本 100.0.0+up2.2.0**：
|
||||
|
||||
- 对于 Manager、Scanner 和 Updater 组件，需要进行额外的配置，如下所示：
|
||||
|
||||
```
|
||||
kubectl patch deploy neuvector-manager-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
|
||||
kubectl patch deploy neuvector-scanner-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
|
||||
kubectl patch cronjob neuvector-updater-pod -n cattle-neuvector-system --patch '{"spec":{"jobTemplate":{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}}}'
|
||||
```
|
||||
<br/>
|
||||
|
||||
你需要为强化集群环境进行额外的配置。
|
||||
|
||||
> **注意**：你必须更新 RKE2 和 K3s 强化集群中的配置，如下所示。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，点击 **Apps**。
|
||||
1. 安装（或升级到）NeuVector 版本 `100.0.1+up2.2.2`。
|
||||
|
||||
- 在 **编辑选项** > **其它配置**下，选中复选框来启用 **Pod 安全策略**。请注意，对于 `Manager runAsUser ID`、`Scanner runAsUser ID` 和 `Updater runAsUser ID`，你还必须输入大于 `0` 的值:
|
||||
|
||||
|
||||
|
||||
1. 点击右下角的**安装**。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### 启用 SELinux 的集群支持 - Calico 和 Canal
|
||||
|
||||
要在 RKE2 集群上启用 SELinux，请执行以下步骤：
|
||||
|
||||
- 如果 PSP 设置为 true，则可以部署 NeuVector 组件 Controller 和 Enforcer。
|
||||
|
||||
|
||||
**仅适用于 NeuVector Chart 版本 100.0.0+up2.2.0**：
|
||||
|
||||
- 对于 Manager、Scanner 和 Updater 组件，需要进行额外的配置，如下所示：
|
||||
|
||||
```
|
||||
kubectl patch deploy neuvector-manager-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
|
||||
kubectl patch deploy neuvector-scanner-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
|
||||
kubectl patch cronjob neuvector-updater-pod -n cattle-neuvector-system --patch '{"spec":{"jobTemplate":{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}}}'
|
||||
```
|
||||
|
||||
### 离线环境中的集群支持
|
||||
|
||||
- 所有 NeuVector 组件都可部署在离线环境中的集群上，无需任何额外配置。
|
||||
|
||||
|
||||
### 支持限制
|
||||
|
||||
* 目前仅支持管理员和集群所有者。
|
||||
|
||||
* 不支持 Fleet 多集群部署。
|
||||
|
||||
* Windows 集群不支持 NeuVector。
|
||||
|
||||
|
||||
### 其他限制
|
||||
|
||||
* 目前，如果 NeuVector partner Chart 已存在，则 NeuVector 功能 Chart 的安装会失败。要解决此问题，请卸载 NeuVector partner Chart 并重新安装 NeuVector 功能 Chart。
|
||||
|
||||
* Controller 未准备好时，有可能无法从 Rancher UI 访问 NeuVector UI。在此期间，Controller 将尝试重新启动，并且需要几分钟才能进入 active 状态。
|
||||
|
||||
* 安装 NeuVector Chart 时，不会针对不同的集群类型自动检测容器运行时。要解决此问题，你可以手动指定运行时。
|
||||
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: 使用 NeuVector 实现容器安全
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/neuvector"/>
|
||||
</head>
|
||||
|
||||
NeuVector 是唯一一个100%开源、零信任的容器安全平台。在整个容器生命周期中持续扫描。清除安全路障。从一开始就制定安全策略，以最大限度地提高开发人员的灵活性。NeuVector 提供从构建到生产的漏洞和合规性扫描与管理。独特的 NeuVector 运行时保护通过七层容器防火墙保护集群内的网络连接以及集群的入口/出口。此外，NeuVector 还监视容器和主机上的进程和文件活动，以阻止未经授权的活动。
|
||||
|
||||
## NeuVector 和 Rancher
|
||||
|
||||
所有 NeuVector 功能均可通过 Rancher 进行集成部署并单点登录 NeuVector 控制台。Rancher 集群管理员能够在其集群上部署和管理 NeuVector 部署，Helm 值、configMaps、自定义资源定义（CRD）和 NeuVector 控制台轻松配置 NeuVector。
|
||||
|
||||
使用 NeuVector 和 Rancher：
|
||||
|
||||
- 部署、管理和保护多个集群。
|
||||
- 管理和报告 Rancher 工作负载和节点的漏洞和合规性结果。
|
||||
|
||||
## NeuVector Prime 和 Rancher Prime
|
||||
|
||||
Rancher Manager 的 NeuVector UI 扩展可用于并支持 Rancher Prime 和 NeuVector Prime 客户。此扩展提供：
|
||||
|
||||
- NeuVector 自动化部署，包括 Rancher Prime NeuVector 扩展仪表板。
|
||||
- 访问每个集群的重要安全信息，如关键安全事件、漏洞扫描结果和入口/出口暴露。
|
||||
- 直接对 Rancher 资源（例如节点和容器/ Pod）进行集成漏洞 (CVE) 和合规扫描。
|
||||
- 集成操作，如手动触发 Rancher 资源的扫描。
|
||||
+196
@@ -0,0 +1,196 @@
|
||||
---
|
||||
title: 概述
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/neuvector/overview"/>
|
||||
</head>
|
||||
|
||||
### Rancher 中的 NeuVector 集成
|
||||
|
||||
[NeuVector 5.x](https://open-docs.neuvector.com/) 是一个开源的，以容器为中心的安全应用程序，Rancher 已集成 NeuVector。NeuVector 在运行时为关键应用程序和数据提供实时的合规、可见和保护功能。NeuVector 提供具有 CIS Benchmark 和漏洞扫描的防火墙、容器进程/文件系统监控和安全审计。有关 Rancher 安全性的更多信息，请参阅[安全文档](../../reference-guides/rancher-security)。
|
||||
|
||||
NeuVector 可以通过 Helm Chart 启用。你可以在 **Apps** 或 Rancher UI 中的 **Cluster Tools** 中安装该 Chart。安装 Helm Chart 后，用户可以轻松地[在 Rancher 中部署和管理 NeuVector 集群](https://open-docs.neuvector.com/deploying/rancher#deploy-and-manage-neuvector-through-rancher-apps-marketplace)。
|
||||
|
||||
### 使用 Rancher 安装 NeuVector
|
||||
|
||||
Harvester Helm Chart 用于管理 Rancher 中 NeuVector UI 的访问，用户可以在 Rancher 中直接跳转，然后部署和管理 NeuVector 集群。
|
||||
|
||||
**通过 Apps 导航并安装 NeuVector Chart：**
|
||||
|
||||
1. 单击 **☰ > 集群管理**。
|
||||
1. 在 Clusters 页面上，转到要部署 NeuVector 的集群，然后单击 **Explore**。
|
||||
1. 转到 **Apps > Charts**，然后从 Chart 仓库中安装 **NeuVector**。
|
||||
1. 不同的集群类型需要不同的容器运行时。配置 Helm Chart 值时，转到**容器运行时**，然后根据集群类型选择运行时。最后，再次单击**安装**。
|
||||
|
||||
以下是一些例子：
|
||||
|
||||
- RKE1：`docker`
|
||||
- K3s 和 RKE2：`k3scontainerd`
|
||||
- AKS：`containerd` 适用于 v1.19 及更高版本
|
||||
- EKS：`docker` 适用于 v1.22 及以下版本；`containerd` 适用于 v1.23 及更高版本
|
||||
- GKE：`containerd` (请参阅 [Google 文档](https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd)了解更多信息)
|
||||
|
||||
:::note
|
||||
|
||||
在安装过程中一次只能选择一个容器运行时引擎。
|
||||
|
||||
:::
|
||||
|
||||
**通过集群工具导航并安装 NeuVector Chart：**
|
||||
|
||||
1. 单击 **☰ > 集群管理**。
|
||||
1. 在 Clusters 页面上，转到要部署 NeuVector 的集群，然后单击 **Explore**。
|
||||
1. 点击左侧导航栏底部的**集群工具**。
|
||||
1. 按照上面的步骤 4 相应地选择你的容器运行时，然后再次单击**安装**。
|
||||
|
||||
### 从 Rancher UI 访问 NeuVector
|
||||
|
||||
1. 导航到安装了 NeuVector 的集群的 Cluster Explorer。在左侧导航栏中，单击 **NeuVector**。
|
||||
1. 单击外部链接以转到 NeuVector UI。选择链接后，用户必须接受`最终用户许可协议`才能访问 NeuVector UI。
|
||||
|
||||
### 从 Rancher UI 卸载 NeuVector
|
||||
|
||||
**通过 Apps 卸载：**
|
||||
|
||||
1. 单击 **☰ > 集群管理**。
|
||||
1. 在 **Apps** 下，点击 **Installed Apps**。
|
||||
1. 在 `cattle-neuvector-system` 下，选择 NeuVector 应用程序（如果需要，还可以选择相关的 CRD），然后单击**删除**。
|
||||
|
||||
**通过集群工具卸载：**
|
||||
|
||||
1. 单击 **☰ > 集群管理**。
|
||||
1. 单击屏幕左下角的**集群工具**，然后单击 NeuVector Chart 下方的垃圾桶图标。如果需要，选择`删除与此应用关联的 CRD`，然后单击**删除**。
|
||||
|
||||
### GitHub 仓库
|
||||
|
||||
NeuVector 项目在[这里](https://github.com/neuvector/neuvector)。
|
||||
|
||||
### 文档
|
||||
|
||||
NeuVector 文档在[这里](https://open-docs.neuvector.com/)。
|
||||
|
||||
### 架构
|
||||
|
||||
NeuVector 安全解决方案包含四种类型的安全容器，分别是 Controller、Enforcer、Manager 和 Scanner。它还提供了一个称为 All-in-One 的特殊容器（主要用于 Docker 原生部署），能将 Controller、Enforcer 和 Manager 功能组合在一个容器中。此外，还有一个 Updater，运行该程序时会更新 CVE 数据库。
|
||||
|
||||
- **Controller：** 管理 NeuVector Enforcer 容器；为管理控制台提供 REST API。
|
||||
- **Enforcer：** 执行安全策略。
|
||||
- **Manager：** 提供一个 web-UI 和 CLI 控制台来管理 NeuVector 平台。
|
||||
- **All-in-One：** 包括 Controller、Enforcer 和 Manager。
|
||||
- **Scanner：** 对镜像、容器和节点执行漏洞和合规性扫描。
|
||||
- **Updater：** 更新 Neuvector 的 CVE 数据库（运行的时候）；重新部署 scanner pod。
|
||||
|
||||
<figcaption>**NeuVector 安全容器：**</figcaption>
|
||||
|
||||
|
||||
|
||||
<figcaption>**NeuVector 架构：**</figcaption>
|
||||
|
||||
|
||||
|
||||
要了解有关 NeuVector 架构的更多信息，请参阅[此处](https://open-docs.neuvector.com/basics/overview#architecture)。
|
||||
|
||||
### CPU 和内存分配
|
||||
|
||||
以下是默认 NeuVector Chart 安装部署的最低计算资源推荐。请注意，未设置资源限制。
|
||||
|
||||
| 容器 | CPU - 请求 | 内存 - 请求 |
|
||||
| ---------- | ----------------------------- | ----------- |
|
||||
| Controller | 3（每个控制器需要 1GB 1vCPU） | \* |
|
||||
| Enforcer | 所有节点上 (500MB .5vCPU) | 1GB |
|
||||
| Manager | 1 (500MB .5vCPU) | \* |
|
||||
| Scanner | 3 (100MB .5vCPU) | \* |
|
||||
|
||||
\* Controller、Manager 和 Scanner 容器合计至少需要 1GB 内存。
|
||||
|
||||
### 强化集群支持 - Calico 和 Canal
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="RKE1">
|
||||
|
||||
- 如果 PSP 设置为 true，则所有 NeuVector 组件都是可部署的。
|
||||
|
||||
你需要为强化集群环境进行额外的配置，如下所示：
|
||||
|
||||
1. 单击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，点击 **Apps**。
|
||||
1. 安装（或升级到）NeuVector 版本 `100.0.1+up2.2.2`。
|
||||
|
||||
- 在**编辑选项** > **其它配置**下，选中复选框来启用 **Pod 安全策略**（无需其他配置）：
|
||||
|
||||
|
||||
|
||||
1. 点击右下角的**安装**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
- 如果 PSP 设置为 true，则可以部署 NeuVector 组件 Controller 和 Enforcer。
|
||||
|
||||
**仅适用于 NeuVector Chart 版本 100.0.0+up2.2.0：**
|
||||
|
||||
- 对于 Manager、Scanner 和 Updater 组件，需要进行额外的配置，如下所示：
|
||||
|
||||
```
|
||||
kubectl patch deploy neuvector-manager-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
|
||||
kubectl patch deploy neuvector-scanner-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
|
||||
kubectl patch cronjob neuvector-updater-pod -n cattle-neuvector-system --patch '{"spec":{"jobTemplate":{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}}}'
|
||||
```
|
||||
|
||||
<br/>
|
||||
|
||||
你需要为强化集群环境进行额外的配置。
|
||||
|
||||
> **注意：**你必须更新 RKE2 和 K3s 强化集群中的配置，如下所示。
|
||||
|
||||
1. 单击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，点击 **Apps**。
|
||||
1. 安装（或升级到）NeuVector 版本 `100.0.1+up2.2.2`。
|
||||
|
||||
- 在**编辑选项** > **其它配置**下，选中复选框来启用 **Pod 安全策略**。请注意，对于 `Manager runAsUser ID`，`Scanner runAsUser ID` 和 `Updater runAsUser ID`，你还必须输入大于 `0` 的值：
|
||||
|
||||
|
||||
|
||||
1. 点击右下角的**安装**。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 启用 SELinux 的集群支持 - Calico 和 Canal
|
||||
|
||||
要在 RKE2 集群上启用 SELinux，请执行以下步骤：
|
||||
|
||||
- 如果 PSP 设置为 true，则可以部署 NeuVector 组件 Controller 和 Enforcer。
|
||||
|
||||
**仅适用于 NeuVector Chart 版本 100.0.0+up2.2.0：**
|
||||
|
||||
- 对于 Manager、Scanner 和 Updater 组件，需要进行额外的配置，如下所示：
|
||||
|
||||
```
|
||||
kubectl patch deploy neuvector-manager-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
|
||||
kubectl patch deploy neuvector-scanner-pod -n cattle-neuvector-system --patch '{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}'
|
||||
kubectl patch cronjob neuvector-updater-pod -n cattle-neuvector-system --patch '{"spec":{"jobTemplate":{"spec":{"template":{"spec":{"securityContext":{"runAsUser": 5400}}}}}}}'
|
||||
```
|
||||
|
||||
### 离线环境中的集群支持
|
||||
|
||||
- 所有 NeuVector 组件都可部署在离线环境中的集群上，无需任何额外配置。
|
||||
|
||||
### 支持限制
|
||||
|
||||
- 目前仅支持管理员和集群所有者。
|
||||
|
||||
- 不支持 Fleet 多集群部署。
|
||||
|
||||
- Windows 集群不支持 NeuVector。
|
||||
|
||||
### 其他限制
|
||||
|
||||
- 目前，如果 NeuVector partner Chart 已存在，则 NeuVector 功能 Chart 的安装会失败。要解决此问题，请卸载 NeuVector partner Chart 并重新安装 NeuVector 功能 Chart。
|
||||
|
||||
- Controller 未准备好时，有可能无法从 Rancher UI 访问 NeuVector UI。在此期间，Controller 将尝试重新启动，并且需要几分钟才能进入 active 状态。
|
||||
|
||||
- 安装 NeuVector Chart 时，不会针对不同的集群类型自动检测容器运行时。要解决此问题，你可以手动指定运行时。
|
||||
+111
@@ -0,0 +1,111 @@
|
||||
---
|
||||
title: OPA Gatekeeper
|
||||
---
|
||||
|
||||
为了确保一致性和合规性，每个组织都需要能够以自动化的方式在环境中定义和执行策略。[OPA（Open Policy Agent）](https://www.openpolicyagent.org/) 是一个策略引擎，用于基于策略控制云原生环境。Rancher 支持在 Kubernetes 集群中启用 OPA Gatekeeper，并且还安装了一些内置的策略定义（也称为约束模板）。
|
||||
|
||||
OPA 提供了一种高级声明性语言，可以让你将策略指定为代码，还能扩展简单的 API，从而减轻策略决策的负担。
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 是一个提供 OPA 和 Kubernetes 集成的项目。OPA Gatekeeper 提供：
|
||||
|
||||
- 一个可扩展的参数化策略库。
|
||||
- 用于实例化策略库的原生 Kubernetes CRD，也称为“约束”。
|
||||
- 用于扩展策略库的原生 Kubernetes CRD，也称为“约束模板”。
|
||||
- 审计功能。
|
||||
|
||||
要了解更多关于 OPA 的信息，请参阅[官方文档](https://www.openpolicyagent.org/docs/latest/)。
|
||||
|
||||
## OPA Gatekeeper 集成的工作原理
|
||||
|
||||
Kubernetes 支持通过准入控制器（准入控制器）webhook 来扩展 API Server 的功能，创建、更新或删除资源时都会调用这些 webhook。Gatekeeper 作为验证 webhook 安装，并执行由 Kubernetes CRD（Custom Resource Definition）定义的策略。除了使用准入控制之外，Gatekeeper 还能审计 Kubernetes 集群中的现有资源，并对违反当前策略的情况进行标记。
|
||||
|
||||
OPA Gatekeeper 由 Rancher 的 Helm system Chart 提供，它安装在名为 `gatekeeper-system` 的命名空间中。
|
||||
|
||||
## 在集群中启用 OPA Gatekeeper
|
||||
|
||||
:::note
|
||||
|
||||
Rancher 2.5 改进了 OPA Gatekeeper 应用。无法从 Rancher 2.4 升级到 Rancher 2.5 中的新版本。如果你在 Rancher 2.4 中安装了 OPA Gatekeeper，则需要在旧 UI 中卸载 OPA Gatekeeper 及其 CRD，然后在 Rancher 2.5 中重新安装它。如需卸载 CRD，请在 kubectl 控制台中运行 `kubectl delete crd configs.config.gatekeeper.sh constrainttemplates.templates.gatekeeper.sh` 命令。
|
||||
|
||||
:::
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
只有管理员和集群所有者才能启用 OPA Gatekeeper。
|
||||
|
||||
:::
|
||||
|
||||
你可以在 **Apps** 页面安装 OPA Gatekeeper Helm Chart。
|
||||
|
||||
### 启用 OPA Gatekeeper
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面中，转到要启用 OPA Gatekeeper 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，点击 **Apps**。
|
||||
1. 点击 **Charts** 并点击 **OPA Gatekeeper**。
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**：已将 OPA Gatekeeper 部署到你的 Kubernetes 集群。
|
||||
|
||||
## 约束模板
|
||||
|
||||
[约束模板](https://github.com/open-policy-agent/gatekeeper#constraint-templates)是 Kubernetes 自定义资源，用于定义要由 Gatekeeper 应用的 OPA 策略的架构和 Rego 逻辑。有关 Rego 策略语言的更多信息，请参阅[官方文档](https://www.openpolicyagent.org/docs/latest/policy-language/)。
|
||||
|
||||
启用 OPA Gatekeeper 后，Rancher 默认会安装一些模板。
|
||||
|
||||
要列出集群中安装的约束模板，请转到 OPA Gatekeeper 下的左侧菜单，然后单击**模板**。
|
||||
|
||||
Rancher 还支持通过导入 YAML 定义来创建你自己的约束模板。
|
||||
|
||||
## 创建和配置约束
|
||||
|
||||
[约束](https://github.com/open-policy-agent/gatekeeper#constraints)是 Kubernetes 自定义资源，用于定义要应用约束模板的对象范围。约束模板和约束共同定义一个完整的策略。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
集群中已启用 OPA Gatekeeper。
|
||||
|
||||
:::
|
||||
|
||||
要列出已安装的约束，请转到 OPA Gatekeeper 下的左侧菜单，然后单击**约束**。
|
||||
|
||||
可以从约束模板创建新的约束。
|
||||
|
||||
Rancher 支持通过使用方便的表单来创建约束，你可以在该表单中输入各种约束字段。
|
||||
|
||||
**以 YAML 文件编辑**选项也可以用于配置约束的 YAML 定义。
|
||||
|
||||
### 使 Rancher 的 System 命名空间不受约束
|
||||
|
||||
创建约束时，请确保该约束不应用于任何 Rancher 或 Kubernetes System 命名空间。如果不排除 System 命名空间，则可能会出现 system 命名空间下的许多资源被标记为违反约束。
|
||||
|
||||
要让约束仅限制用户命名空间，请在约束的**匹配**字段下指定这些命名空间。
|
||||
|
||||
此外，该约束可能会干扰其他 Rancher 功能并拒绝部署系统工作负载。为避免这种情况，请从你的约束中排除所有 Rancher 特定的命名空间。
|
||||
|
||||
## 在集群中实施约束
|
||||
|
||||
如果**执行动作**为 **Deny**，约束会立即启用，并拒绝任何违反策略的请求。默认情况下，执行的值为 **Deny**。
|
||||
|
||||
如果**执行动作** 为 **Dryrun**，违反策略的资源仅会记录在约束的状态字段中。
|
||||
|
||||
要强制执行约束，请使用表单创建约束。在**执行动作**字段中，选择 **Deny**。
|
||||
|
||||
## 集群中的审计和违规
|
||||
|
||||
OPA Gatekeeper 运行定期审计，以检查现有资源是否违反强制执行的约束。你可以在安装 Gatekeeper 时配置审计间隔（默认 300 秒）。
|
||||
|
||||
Gatekeeper 页面上列出了违反已定义的约束的情况。
|
||||
|
||||
此外，你也可以在**约束**页面中找到违反约束的数量。
|
||||
|
||||
每个约束的详细信息视图列出了违反约束的资源的信息。
|
||||
|
||||
## 禁用 Gatekeeper
|
||||
|
||||
1. 导航到集群的仪表板视图。
|
||||
1. 在左侧菜单中，展开集群菜单并单击 **OPA Gatekeeper**。
|
||||
1. 单击 **⋮ > 禁用**。
|
||||
|
||||
**结果**：禁用 OPA Gatekeeper 后，所有约束模板和约束也将被删除。
|
||||
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: 桌面上的 Kubernetes 与 Rancher Desktop
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/rancher-desktop"/>
|
||||
</head>
|
||||
|
||||
Rancher Desktop 将用于桌面开发和测试云原生应用程序的基本工具捆绑在一起。
|
||||
|
||||
如果你在本地计算机上运行适用于云环境的应用程序，则通常需要进行大量准备工作。你需要选择一个容器运行时,安装 Kubernetes 和流行的实用程序，并且可能还需要设置虚拟机。单独安装组件并使它们协同工作可能是一个耗时的过程。
|
||||
|
||||
为了降低复杂性，Rancher Desktop 为团队提供了以下主要功能：
|
||||
|
||||
- 在 macOS、Linux 和 Windows 操作系统上进行简单易用的安装。
|
||||
- K3s，一个易于使用的轻量级 Kubernetes 发行版。
|
||||
- 能够在 Kubernetes 版本之间轻松切换。
|
||||
- 由 Rancher 支持的基于 GUI 的集群仪表板，用于浏览本地集群。
|
||||
- 自由选择容器引擎：dockerd（moby）或 containerd。
|
||||
- 用于配置应用程序以满足你的需求的首选项设置。
|
||||
- 容器、基于 Kubernetes 的开发和操作工作流程所需的捆绑工具。
|
||||
- 定期更新，使捆绑工具保持最新。
|
||||
- 与流行的工具/IDE 集成，包括 VS Code 和 Skaffold。
|
||||
- 镜像和注册表访问控制。
|
||||
- 支持 Docker 扩展。
|
||||
|
||||
访问 [Rancher Desktop](https://rancherdesktop.io) 网站并阅读[文档](https://docs.rancherdesktop.io/)以了解更多信息。
|
||||
|
||||
要在你的机器上安装 Rancher Desktop，请参阅[安装指南](https://docs.rancherdesktop.io/getting-started/installation)。
|
||||
|
||||
## 在 Rancher Desktop 上尝试 Rancher
|
||||
|
||||
Rancher Desktop 提供了轻松试用容器化、基于 Helm 的应用程序所需的设置和工具。你可以按照此[操作指南](https://docs.rancherdesktop.io/how-to-guides/rancher-on-rancher-desktop)，使用 Rancher Desktop 开始使用 Rancher Kubernetes 管理平台。
|
||||
+84
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: Rancher 扩展
|
||||
---
|
||||
|
||||
Rancher v2.7.0 引入了**扩展（Extension）**的新功能。扩展允许用户、开发人员、合作伙伴和客户扩展和增强 Rancher UI。此外，用户可以独立于 Rancher 版本对其 UI 功能进行更改和增强。有了扩展，用户能够在 Rancher 之上进行构建，从而更好地根据环境进行定制。用户还可以更新到新版本以及回滚到以前的版本。
|
||||
|
||||
扩展是只能在集群中安装一次的 Helm Chart。因此，这些 Chart 已经过简化，并与 **Apps** 下列出的常规 Helm Chart 分开。
|
||||
|
||||
内置的 Rancher 扩展示例包括 Fleet、Explorer 和 Harvester。使用可手动添加的 Extensions API 的其他扩展示例包括 Kubewarden 和 Elemental。
|
||||
|
||||
## 先决条件
|
||||
|
||||
> 你必须以管理员身份登录才能查看扩展管理页面并与之交互。
|
||||
|
||||
## 安装扩展
|
||||
|
||||
1. 点击 **Configuration** 下的 **☰ > Extensions**。
|
||||
|
||||
2. 如果它尚未安装到 **Apps** 中，则你必须通过单击 **Enable** 按钮启用扩展 operator。
|
||||
|
||||
- 如果不是离线安装环境，请单击 **OK** 添加 Rancher 扩展仓库。否则，取消选中复选框并单击 **OK**。
|
||||
|
||||
|
||||
|
||||
3. 在 **Extensions** 页面上，单击 **Available** 选项卡选择要安装的扩展。
|
||||
|
||||
:::info
|
||||
|
||||
在 v2.7.0 中，**Available** 选项卡下不会显示内置扩展。因此，你需要手动添加所需的仓库以安装扩展。一旦这些扩展可用了，我们将同步社区。
|
||||
|
||||
:::
|
||||
<br/>
|
||||
|
||||
4. 如果没有显示可用的扩展，你可以手动添加仓库，如下所示：
|
||||
|
||||
4.1. 在屏幕右上角，点击 **⋮ > Manage Repositories > Create**。
|
||||
|
||||
4.2. 添加所需的仓库名称，确保指定了 Git 仓库 URL 和 Git 分支。
|
||||
|
||||
4.3. 再次点击右下方的 **Create**。
|
||||
|
||||
|
||||
|
||||
5. 在 **Available** 选项卡下，单击所需扩展和版本上的 **Install** 按钮，如下例所示。请注意，如果扩展程序可用，**Update** 按钮将出现在该扩展上，因此你可以轻松更新扩展。
|
||||
|
||||
|
||||
|
||||
6. 点击 **Reload** 按钮，该按钮将在你的扩展成功安装后出现。请注意，对于刚刚安装扩展的登录用户而言，**除非**他们重新加载页面，否则他们不会看到 UI 的变化。
|
||||
|
||||
|
||||
|
||||
## 卸载扩展
|
||||
|
||||
你可以通过两种方式卸载或禁用扩展：
|
||||
|
||||
1. 在 **Installed** 选项卡下，单击要删除的扩展上的 **Uninstall** 按钮。
|
||||
|
||||
|
||||
|
||||
1. 在扩展管理页面，点击 **⋮ > Disable Extension Support**。这将禁用所有已安装的扩展。
|
||||
|
||||
|
||||
|
||||
:::caution
|
||||
|
||||
你必须在禁用扩展后重新加载页面，否则可能会出现显示问题。
|
||||
|
||||
:::
|
||||
|
||||
## 回滚扩展
|
||||
|
||||
在 **Installed** 选项卡下，单击要回滚的扩展上的 **Rollback** 按钮。
|
||||
|
||||
|
||||
|
||||
:::caution
|
||||
|
||||
回滚扩展后必须重新加载页面，否则可能会出现显示问题。
|
||||
|
||||
:::
|
||||
|
||||
## 开发扩展
|
||||
|
||||
要了解如何开发你自己的扩展，请参阅官方[入门指南](https://rancher.github.io/dashboard/extensions/extensions-getting-started)。
|
||||
Reference in New Issue
Block a user