mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-27 05:28:22 +00:00
Add i18n and Chinese translation
This commit is contained in:
vickyhella
+106
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: 配置
|
||||
weight: 3
|
||||
---
|
||||
|
||||
此配置参考用于帮助你管理由 `rancher-cis-benchmark` 应用创建的自定义资源。这些资源用于在集群上执行 CIS 扫描、跳过测试、设置扫描使用的测试配置文件和其他自定义配置。
|
||||
|
||||
要配置自定义资源，转到**集群**仪表板。要配置 CIS 扫描：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要配置 CIS 扫描的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **CIS Benchmark**。
|
||||
|
||||
### 扫描
|
||||
|
||||
扫描是用来根据定义的配置文件，在集群上触发 CIS 扫描的。扫描完成后会创建一份报告。
|
||||
|
||||
配置扫描时，你需要定义与 `scanProfileName` 参数一起使用的扫描配置文件的名称。
|
||||
|
||||
下面是一个 ClusterScan 自定义资源示例：
|
||||
|
||||
```yaml
|
||||
apiVersion: cis.cattle.io/v1
|
||||
kind: ClusterScan
|
||||
metadata:
|
||||
name: rke-cis
|
||||
spec:
|
||||
scanProfileName: rke-profile-hardened
|
||||
```
|
||||
|
||||
### 配置文件
|
||||
|
||||
配置文件包含 CIS 扫描的配置，包括要使用的 Benchmark 测试版本以及要在该 Benchmark 测试中跳过的测试。
|
||||
|
||||
:::caution
|
||||
|
||||
默认情况下，一些 ClusterScanProfile 会作为 `rancher-cis-benchmark` Chart 的一部分进行安装。如果用户编辑了这些默认 Benchmark 或配置文件，它们会在下一次 Chart 更新时被重置。因此，建议用户不要编辑默认的 ClusterScanProfile。
|
||||
|
||||
:::
|
||||
|
||||
用户可以通过克隆 ClusterScanProfile 来创建自定义配置文件。
|
||||
|
||||
跳过的测试会列在 `skipTests` 参数下。
|
||||
|
||||
创建新配置文件时，你还需要命名配置文件。
|
||||
|
||||
`ClusterScanProfile` 示例如下：
|
||||
|
||||
```yaml
|
||||
apiVersion: cis.cattle.io/v1
|
||||
kind: ClusterScanProfile
|
||||
metadata:
|
||||
annotations:
|
||||
meta.helm.sh/release-name: clusterscan-operator
|
||||
meta.helm.sh/release-namespace: cis-operator-system
|
||||
labels:
|
||||
app.kubernetes.io/managed-by: Helm
|
||||
name: "<example-profile>"
|
||||
spec:
|
||||
benchmarkVersion: cis-1.5
|
||||
skipTests:
|
||||
- "1.1.20"
|
||||
- "1.1.21"
|
||||
```
|
||||
|
||||
### Benchmark 版本
|
||||
|
||||
Benchmark 版本是指使用 `kube-bench` 运行的 Benchmark 名称，以及该 Benchmark 的有效配置参数。
|
||||
|
||||
`ClusterScanBenchmark` 定义了 CIS `BenchmarkVersion` 的名称和测试配置。`BenchmarkVersion` 名称是提供给 `kube-bench` 工具的参数。
|
||||
|
||||
默认情况下，一些 `BenchmarkVersion` 名称和测试配置会作为 CIS 扫描应用的一部分进行打包。启用此功能后，这些默认 BenchmarkVersion 将自动安装，用户可以使用它们来创建 ClusterScanProfile。
|
||||
|
||||
:::caution
|
||||
|
||||
如果用户编辑了默认的 BenchmarkVersion，它们会在下一次 Chart 更新时被重置。因此，不建议编辑默认的 ClusterScanBenchmark。
|
||||
|
||||
:::
|
||||
|
||||
ClusterScanBenchmark 由以下字段组成：
|
||||
|
||||
- `ClusterProvider`：此 Benchmark 适用的集群提供商名称，例如，RKE、EKS、GKE。如果此基准测试可以在任何集群类型上运行，则留空。
|
||||
- `MinKubernetesVersion`：集群运行此 Benchmark 测试所需的最低 kubernetes 版本。如果不依赖特定的 Kubernetes 版本，则留空。
|
||||
- `MaxKubernetesVersion`：集群运行此 Benchmark 测试所需的最高 Kubernetes 版本。如果不依赖特定的 Kubernetes 版本，则留空。
|
||||
|
||||
`ClusterScanBenchmark` 示例如下：
|
||||
|
||||
```yaml
|
||||
apiVersion: cis.cattle.io/v1
|
||||
kind: ClusterScanBenchmark
|
||||
metadata:
|
||||
annotations:
|
||||
meta.helm.sh/release-name: clusterscan-operator
|
||||
meta.helm.sh/release-namespace: cis-operator-system
|
||||
creationTimestamp: "2020-08-28T18:18:07Z"
|
||||
generation: 1
|
||||
labels:
|
||||
app.kubernetes.io/managed-by: Helm
|
||||
name: cis-1.5
|
||||
resourceVersion: "203878"
|
||||
selfLink: /apis/cis.cattle.io/v1/clusterscanbenchmarks/cis-1.5
|
||||
uid: 309e543e-9102-4091-be91-08d7af7fb7a7
|
||||
spec:
|
||||
clusterProvider: ""
|
||||
minKubernetesVersion: 1.15.0
|
||||
```
|
||||
+79
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: 为集群扫描创建自定义 Benchmark 版本
|
||||
weight: 4
|
||||
---
|
||||
|
||||
每个 Benchmark 版本都定义了一组测试配置文件，这些文件定义了由 <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> 工具运行的 CIS 测试。
|
||||
`rancher-cis-benchmark` 应用安装了一些默认的 Benchmark 测试版本，这些版本列在了 CIS Benchmark 测试应用菜单下。
|
||||
|
||||
但是，某些 Kubernetes 集群可能需要自定义配置 Benchmark 测试。例如，Kubernetes 配置文件或证书的路径可能与上游 CIS Benchmark 的标准位置不同。
|
||||
|
||||
现在，你可以使用 `rancher-cis-benchmark` 应用来创建自定义 Benchmark 版本，从而运行集群扫描。
|
||||
|
||||
运行集群扫描时，你需要选择指向特定 Benchmark 版本的配置文件。
|
||||
|
||||
按照以下所有步骤添加自定义 Benchmark 版本并使用它运行扫描。
|
||||
|
||||
### 1. 准备自定义 Benchmark 版本 ConfigMap
|
||||
|
||||
要创建自定义 Benchmark 版本，你需要先创建一个包含 Benchmark 版本配置文件的 ConfigMap，并将其上传到要运行扫描的 Kubernetes 集群。
|
||||
|
||||
假设要添加一个名为 `foo` 的自定义 Benchmark 版本，你可以按照以下步骤准备自定义 Benchmark 版本 ConfigMap：
|
||||
|
||||
1. 创建一个名为 `foo` 的目录，并在该目录中放置所有配置 YAML 文件， <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> 工具会搜索这些文件。例如，通用 CIS 1.5 Benchmark 版本的配置 YAML 文件在[此处](https://github.com/aquasecurity/kube-bench/tree/master/cfg/cis-1.5)。
|
||||
1. 放置完整的 `config.yaml` 文件，其中包括所有要测试的组件。
|
||||
1. 将 Benchmark 版本名称添加到 `config.yaml` 的 `target_mapping` 中：
|
||||
|
||||
```yaml
|
||||
target_mapping:
|
||||
"foo":
|
||||
- "master"
|
||||
- "node"
|
||||
- "controlplane"
|
||||
- "etcd"
|
||||
- "policies"
|
||||
```
|
||||
1. 通过创建 ConfigMap 将此目录上传到 Kubernetes 集群：
|
||||
|
||||
```yaml
|
||||
kubectl create configmap -n <namespace> foo --from-file=<path to directory foo>
|
||||
```
|
||||
|
||||
### 2. 将自定义 Benchmark 版本添加到集群
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要添加自定义 Benchmark 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **CIS Benchmark > Benchmark 版本**。
|
||||
1. 单击**创建**。
|
||||
1. 输入自定义 Benchmark 版本的**名称**和描述。
|
||||
1. 选择要应用 Benchmark 版本的集群提供商。
|
||||
1. 在下拉列表中选择你已上传的 ConfigMap。
|
||||
1. 添加最低和最高 Kubernetes 版本限制（如果有）。
|
||||
1. 单击**创建**。
|
||||
|
||||
### 3. 为自定义 Benchmark 版本创建新配置文件
|
||||
|
||||
要使用你的自定义 Benchmark 版本运行扫描，你需要添加一个指向此 Benchmark 版本的新配置文件：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要添加自定义 Benchmark 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **CIS Benchmark > 配置文件**。
|
||||
1. 单击**创建**。
|
||||
1. 设置**名称**和描述。在本例中，我们将其命名为 `foo-profile`。
|
||||
1. 在下拉列表中选择 Benchmark 版本。
|
||||
1. 单击**创建**。
|
||||
|
||||
### 4. 使用自定义 Benchmark 版本运行扫描
|
||||
|
||||
指向你的自定义 Benchmark 版本的 `foo` 配置文件创建完成后，你可以创建一个新的扫描，从而在 Benchmark 版本中运行自定义测试。
|
||||
|
||||
要运行扫描：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要添加自定义 Benchmark 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击 **CIS Benchmark > 扫描**。
|
||||
1. 单击**创建**。
|
||||
1. 选择新的集群扫描配置文件。
|
||||
1. 单击**创建**。
|
||||
|
||||
**结果**：已生成带有扫描结果的报告。如需查看结果，请单击显示的扫描名称。
|
||||
+48
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: RBAC
|
||||
shortTitle: RBAC
|
||||
weight: 3
|
||||
---
|
||||
|
||||
本文介绍使用 rancher-cis-benchmark 应用所需的权限。
|
||||
|
||||
默认情况下，rancher-cis-benchmark 是集群管理员独有的功能。
|
||||
|
||||
但是，`rancher-cis-benchmark` Chart 安装了这两个默认的 `ClusterRole`：
|
||||
|
||||
- cis-admin
|
||||
- cis-view
|
||||
|
||||
在 Rancher 中，默认情况下只有集群所有者和全局管理员具有 `cis-admin` 访问权限。
|
||||
|
||||
注意：如果你使用在 Rancher 2.5 中添加的 `cis-edit` 角色，该角色从 2.5.2 开始已被删除，删除的原因是该角色本质上与 `cis-admin` 相同。如果你为 `cis-edit` 创建了任何 clusterrolebinding，请更新这些绑定以使用 `cis-admin` ClusterRole。
|
||||
|
||||
## Cluster-Admin 访问
|
||||
|
||||
默认情况下，Rancher CIS 扫描是集群管理员独有的功能。
|
||||
换言之，只有 Rancher 全局管理员和集群的集群所有者可以：
|
||||
|
||||
- 安装/卸载 rancher-cis-benchmark 应用。
|
||||
- 查看 CIS Benchmark CRD 的导航链接 - ClusterScanBenchmarks、ClusterScanProfiles、ClusterScans。
|
||||
- 列出默认的 ClusterScanBenchmarks 和 ClusterScanProfiles。
|
||||
- 创建/编辑/删除新的 ClusterScanProfiles。
|
||||
- 创建/编辑/删除新的 ClusterScan，从而在集群上运行 CIS 扫描。
|
||||
- 在 ClusterScan 完成后查看并下载 ClusterScanReport。
|
||||
|
||||
|
||||
## Kubernetes 默认角色的默认权限摘要
|
||||
|
||||
rancher-cis-benchmark 创建了三个 `ClusterRole`，并将 CIS Benchmark CRD 访问权限添加到以下默认 K8s `ClusterRole`：
|
||||
|
||||
| Chart 创建的 ClusterRole | 默认 K8s ClusterRole | 角色赋予的权限 |
|
||||
| ------------------------------| ---------------------------| ---------------------------|
|
||||
| `cis-admin` | `admin` | 增刪查改（CRUD）clusterscanbenchmarks、clusterscanprofiles、clusterscans、clusterscanreports CR |
|
||||
| `cis-view` | `view ` | 列出 (R) clusterscanbenchmarks、clusterscanprofiles、clusterscans、clusterscanreports CR |
|
||||
|
||||
|
||||
默认情况下，只有 cluster-owner 角色能管理和使用 `rancher-cis-benchmark` 功能。
|
||||
|
||||
默认情况下，其他 Rancher 角色（cluster-member、project-owner 和 project-member）没有管理和使用 rancher-cis-benchmark 资源的权限。
|
||||
|
||||
但是，如果 cluster-owner 想将访问权限分配给其他用户，他们可以手动创建目标用户与上述 CIS ClusterRole 之间的 ClusterRoleBinding，从而实现权限分配。
|
||||
`rancher-cis-benchmark` ClusterRole 不支持自动角色聚合。
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: 跳过和不适用的测试
|
||||
weight: 3
|
||||
---
|
||||
|
||||
本文列出了在 RKE 的 permissive 测试配置文件中跳过的测试。
|
||||
|
||||
> 在 v2.5 生成的报告中，此页面上被跳过且不适用的测试将会计为不适用。跳过的测试计数只会涉及用户定义的跳过测试。这样，你可以区分用户要跳过的测试与 RKE permissive 测试配置文件中默认跳过的测试。
|
||||
|
||||
## CIS Benchmark v1.5
|
||||
|
||||
### CIS Benchmark v1.5 跳过的测试
|
||||
|
||||
| 数字 | 描述 | 跳过的原因 |
|
||||
| ---------- | ------------- | --------- |
|
||||
| 1.1.12 | 确保 etcd 数据目录所有权设置为 etcd:etcd（自动） | etcd 数据目录所有权需要系统 ServiceAccount。有关如何配置所有权的更多信息，请参阅 Rancher 的强化指南。 |
|
||||
| 1.2.6 | 确保根据需要设置 --kubelet-certificate-authority 参数（自动） | 在生成服务证书时，功能可能会与某些云提供商所需的主机名覆盖一起中断。 |
|
||||
| 1.2.16 | 确保设置了准入控制插件 PodSecurityPolicy（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
|
||||
| 1.2.33 | 确保能根据需要设置 --encryption-provider-config 参数（手动） | 启用加密会改变恢复加密数据的方式。 |
|
||||
| 1.2.34 | 确保正确配置了加密提供程序（手动） | 启用加密会改变恢复加密数据的方式。 |
|
||||
| 4.2.6 | 确保 --protect-kernel-defaults 参数设置为 true（自动） | 在配置集群之前需要系统级别的配置，才能将此参数设置为 true。 |
|
||||
| 4.2.10 | 确保根据需要设置 --tls-cert-file 和 --tls-private-key-file 参数（自动） | 在生成服务证书时，功能可能会与某些云提供商所需的主机名覆盖一起中断。 |
|
||||
| 5.1.5 | 确保未主动使用默认 ServiceAccount。（自动） | Kubernetes 提供了要使用的默认 ServiceAccount。 |
|
||||
| 5.2.2 | 最小化需要共享主机进程 ID 命名空间的容器准入（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
|
||||
| 5.2.3 | 最小化需要共享主机 IPC 命名空间的容器准入（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
|
||||
| 5.2.4 | 最小化需要共享主机网络命名空间的容器准入（自动） | 启用 Pod 安全策略可能会导致应用意外失败。 |
|
||||
| 5.2.5 | 使用 allowPrivilegeEscalation（自动）最小化容器的准入 | 启用 Pod 安全策略可能会导致应用意外失败。 |
|
||||
| 5.3.2 | 确保所有命名空间都定义了网络策略（自动） | 启用网络策略可以防止某些应用进行相互通信。 |
|
||||
| 5.6.4 | 确保不使用 Default 命名空间（自动） | Kubernetes 提供了一个 Default 命名空间。 |
|
||||
|
||||
### CIS Benchmark v1.5 不适用的测试
|
||||
|
||||
| 数字 | 描述 | 不适用的原因 |
|
||||
| ---------- | ------------- | --------- |
|
||||
| 1.1.1 | 确保 API Server pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 kube-apiserver 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.2 | 确保 API Server pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 kube-apiserver 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.3 | 确保 Controller Manager pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.4 | 确保 Controller Manager pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.5 | 确保 Scheduler pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.6 | 确保 Scheduler pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.7 | 确保 etcd pod 规范文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 etcd 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.8 | 确保 etcd pod 规范文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 etcd 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.13 | 确保 admin.conf 文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不会在节点上存储 kubernetes 的默认 kubeconfig 凭证文件。 |
|
||||
| 1.1.14 | 确保 admin.conf 文件所有权设置为 root:root（自动） | RKE 配置的集群不会在节点上存储 kubernetes 的默认 kubeconfig 凭证文件。 |
|
||||
| 1.1.15 | 确保 scheduler.conf 文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.16 | 确保 scheduler.conf 文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 Scheduler 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.17 | 确保 controller-manager.conf 文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.1.18 | 确保将 controller-manager.conf 文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 controller-manager 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 1.3.6 | 确保 RotateKubeletServerCertificate 参数设置为 true（自动） | RKE 配置的集群直接使用 RKE 处理证书轮换。 |
|
||||
| 4.1.1 | 确保 kubelet 服务文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 kubelet 服务的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 4.1.2 | 确保 kubelet 服务文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 kubelet 服务的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 4.1.9 | 确保 kubelet 配置文件权限具有 644 或更严格的设置（自动） | RKE 配置的集群不需要或维护 kubelet 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 4.1.10 | 确保 kubelet 配置文件所有权设置为 root:root（自动） | RKE 配置的集群不需要或维护 kubelet 的配置文件。所有配置在容器运行时作为参数传入。 |
|
||||
| 4.2.12 | 确保 RotateKubeletServerCertificate 参数设置为 true（自动） | RKE 配置的集群直接使用 RKE 处理证书轮换。 |
|
||||
+97
@@ -0,0 +1,97 @@
|
||||
---
|
||||
title: 先决条件
|
||||
weight: 1
|
||||
---
|
||||
|
||||
### 1. 设置许可证管理器和购买支持
|
||||
|
||||
首先，完成许可证管理器设置的[第一步](https://docs.aws.amazon.com/license-manager/latest/userguide/getting-started.html)。
|
||||
然后，转到 AWS Marketplace。找到 “Rancher Premium Support Billing Container Starter Pack”。最后，购买至少一项 Entitlement。
|
||||
|
||||
如果你已使用 “Rancher Setup” AWS Marketplace 产品安装了 Rancher，请跳至[步骤 4](#4-创建-oidc-提供商)。
|
||||
|
||||
> **注意**：每项 Entitlement 都对一定数量的节点授予访问支持的权限。你可以后续根据需要购买更多许可证。
|
||||
|
||||
### 2. 创建 EKS 集群
|
||||
按照 [Rancher 文档](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md)创建 EKS 集群。进行到[安装 Rancher Helm Chart](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md#8-安装-rancher-helm-chart)（最后一步）时，**停止并返回此页面**。该集群需要满足以下要求：
|
||||
|
||||
- EKS 1.22 版本。
|
||||
- 集群中的每个节点都可以访问包含 Rancher 及其相关镜像的镜像仓库。
|
||||
- 集群中的每个节点都可以访问存储 CSP Adapter 的 ECR 仓库。
|
||||
- 集群中的每个节点都可以访问许可证管理器服务。
|
||||
- 集群中的每个节点都可以访问 STS 服务的全局端点。
|
||||
|
||||
### 3. 安装 Rancher
|
||||
|
||||
除了在 [Rancher 文档](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md#8-安装-rancher-helm-chart)中指定的 Rancher 安装选项外，你还需要启用其它指标。
|
||||
你可以通过 Helm CLI 使用以下选项来完成：
|
||||
|
||||
```bash
|
||||
--set extraEnv\[0\].name="CATTLE_PROMETHEUS_METRICS" --set-string extraEnv\[0\].value=true
|
||||
```
|
||||
|
||||
你还可以使用 values.yaml，如下所示：
|
||||
|
||||
```yaml
|
||||
extraEnv:
|
||||
- name: "CATTLE_PROMETHEUS_METRICS"
|
||||
value: "true"
|
||||
```
|
||||
|
||||
你还需要安装 Rancher 2.6.7 或更高版本。
|
||||
|
||||
### 4. 创建 OIDC 提供程序
|
||||
|
||||
按照 [AWS 文档](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html)为上一节中指定的集群创建 OIDC 提供程序。
|
||||
|
||||
### 5. 创建 IAM 角色
|
||||
|
||||
CSP Adapter 需要 IAM 角色才能签入/签出 Entitlement。
|
||||
|
||||
首先，配置如下的信任策略。你需要将 `MY_AWS_ACC` 替换为你的 AWS 帐号，将 `MY_AWS_REGION` 替换为你的 AWS 区域，并将 `MY_OIDC_PROVIDER` 替换为你的 OIDC 提供商 ID：
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"Federated": "arn:aws:iam::${MY_AWS_ACC}:oidc-provider/oidc.eks.${MY_AWS_REGION}.amazonaws.com/id/${MY_OIDC_PROVIDER}"
|
||||
},
|
||||
"Action": "sts:AssumeRoleWithWebIdentity",
|
||||
"Condition": {
|
||||
"StringEquals": {
|
||||
"oidc.eks.${MY_AWS_REGION}.amazonaws.com/id/${MY_OIDC_PROVIDER}:sub": "system:serviceaccount:cattle-csp-adapter-system:rancher-csp-adapter",
|
||||
"oidc.eks.${MY_AWS_REGION}.amazonaws.com/id/${MY_OIDC_PROVIDER}:aud": "sts.amazonaws.com"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
接下来，为具有以下权限的角色使用策略：
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "RancherCSPAdapterPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"license-manager:ListReceivedLicenses",
|
||||
"license-manager:CheckoutLicense",
|
||||
"license-manager:ExtendLicenseConsumption",
|
||||
"license-manager:CheckInLicense",
|
||||
"license-manager:GetLicense",
|
||||
"license-manager:GetLicenseUsage"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
保存角色的名称。稍后安装 CSP Adapter 时将需要它。
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: 常见问题
|
||||
weight: 4
|
||||
---
|
||||
|
||||
**安装 Adapter 后，Rancher 中出现一条横幅消息，上面写着 "AWS Marketplace Adapter: Unable to run the adapter, please check the adapter logs"**
|
||||
|
||||
此错误表示 Adapter 安装到集群中时发生了一个错误，导致它无法正确签入/签出许可证。
|
||||
|
||||
这通常是因为 IAM 角色设置不正确。请查看[先决条件](./adapter-requirements.md)并确认：
|
||||
|
||||
- 已创建一个 OIDC 提供程序，并且它已关联到运行 Rancher 的集群。
|
||||
- IAM 角色已配置为信任此 OIDC 提供程序。
|
||||
- IAM 角色至少具有策略中概述的权限。
|
||||
|
||||
如果上述所有配置均已正确配置，请联系支持寻求帮助。
|
||||
|
||||
**我看到一条横幅消息，上面写着 "AWS Marketplace Adapter: You have exceeded your licensed node count. At least x more license(s) are required in AWS to become compliant"**
|
||||
|
||||
此消息表明你没有足够的 Entitlement 来满足 Rancher 当前管理的节点数量。
|
||||
|
||||
请记住以下限制：
|
||||
|
||||
- 每个 Entitlement 仅对一定数量的节点有效。
|
||||
- 当前由 Rancher 管理的每个节点都计入你的总使用量（安装了集群 Rancher 的节点除外）。
|
||||
- 每个 Entitlement 最多可以被一个 Rancher 实例使用。例如，如果你的账户中有两个正在运行的 Rancher 实例（每个都安装在单独的 EKS 集群上），那么你至少需要两个 Entitlement。
|
||||
|
||||
你最近可能还卸载/重新安装了 Adapter。如果 Adapter 丢失了它当前管理的许可证的跟踪，则可能需要一个小时来解析许可证的实际状态。
|
||||
|
||||
+144
@@ -0,0 +1,144 @@
|
||||
---
|
||||
title: 安装 Adapter
|
||||
weight: 2
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
> **重要提示**：如果你尝试重新安装 Adapter，你可能会在长达一小时的时间内收到不合规的错误消息。
|
||||
|
||||
### 1. 获取对 Local 集群的访问权限
|
||||
|
||||
> **注意**：只有管理员用户才能访问 Local 集群。因为 CSP Adapter 必须安装在 Local 集群中，所以此安装必须由管理员用户执行。
|
||||
|
||||
首先，单击 Local 集群并下载 kubeconfig 令牌。然后，使用下方的命令配置 CLI 以使用此新令牌，你需要将 `$TOKEN_PATH` 替换为文件系统上令牌的下载路径：
|
||||
|
||||
```bash
|
||||
export KUBECONFIG=$TOKEN_PATH
|
||||
```
|
||||
|
||||
### 2. 创建 Adapter 命名空间
|
||||
|
||||
创建要安装 Adapter 的命名空间：
|
||||
|
||||
```bash
|
||||
kubectl create ns cattle-csp-adapter-system
|
||||
```
|
||||
|
||||
### 3. 创建证书密文
|
||||
|
||||
Adapter 需要访问 Rancher 用来与 Rancher Server 通信的根 CA。有关 Rancher 支持的证书选项的更多信息，请参阅 [Chart 选项页面](../../../../reference-guides/installation-references/helm-chart-options.md)。
|
||||
|
||||
如果你的 Rancher 使用由公认的证书颁发机构（例如 Let's Encrypt）签发的证书，你可以跳到[步骤 4](#4-安装-chart)。
|
||||
|
||||
但是，如果你的 Rancher 使用了自定义证书（例如 Rancher 生成的证书或由私有证书颁发机构签发的证书），你需要为该 CA 提供 PEM 编码格式的证书以便 Adapter 可以与 Rancher 通信。
|
||||
|
||||
首先，检索 Rancher 正在使用的证书并将其放入名为 `ca-additional.pem` 的文件中。如果你使用 Rancher 生成的证书，你可以使用以下命令完成此操作：
|
||||
|
||||
```bash
|
||||
kubectl get secret tls-rancher -n cattle-system -o jsonpath="{.data.tls\.crt}" | base64 -d >> ca-additional.pem
|
||||
```
|
||||
|
||||
然后，创建一个使用此证书的密文：
|
||||
|
||||
```bash
|
||||
kubectl -n cattle-csp-adapter-system create secret generic tls-ca-additional --from-file=ca-additional.pem
|
||||
```
|
||||
|
||||
> **重要提示**：不要更改文件名或创建的密文的名称，否则可能会导致 Adapter 运行出错。
|
||||
|
||||
### 4. 安装 Chart
|
||||
|
||||
首先，使用以下命令添加 `rancher/charts` 仓库：
|
||||
|
||||
```bash
|
||||
helm repo add rancher-charts https://charts.rancher.io
|
||||
```
|
||||
|
||||
接下来，安装 CSP Adapter。你必须指定多个值，其中包括账号号码以及在先决条件中创建的角色的名称。
|
||||
|
||||
在下方的操作中，将 `$MY_ACC_NUM` 替换为你的 AWS 账号，将 `$MY_ROLE_NAME` 替换为先决条件中创建的角色的名称。
|
||||
|
||||
> **注意**：如果你使用 shell 变量，请不要使用引号。例如，MY_ACC_NUM=123456789012 可用，但 MY_ACC_NUM="123456789012" 将失败。
|
||||
|
||||
> **注意**：使用欧盟和英国的 AWS Marketplace 列表的账号需要额外指定 `--set image.repository=rancher/rancher-csp-adapter-eu` 选项。要查看你的账号在安装 Adapter 时是否需要此选项，请参阅 Marketplace 列表的使用说明。
|
||||
|
||||
> **注意**：请务必严格按照以下说明进行操作。尤其需要注意安装 1.0.1 版本 Adapter 的命令（使用 `--set image.tag=v1.0.1`），这是确保节点数量准确的关键。
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Let's Encrypt/ Public Certificate Authority">
|
||||
|
||||
```bash
|
||||
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter --namespace cattle-csp-adapter-system --set aws.enabled=true --set aws.roleName=$MY_ROLE_NAME --set-string aws.accountNumber=$MY_ACC_NUM --set image.tag=v1.0.1
|
||||
```
|
||||
|
||||
|
||||
你也可以使用 `values.yaml` 并指定以下选项：
|
||||
|
||||
```yaml
|
||||
image:
|
||||
tag: v1.0.1
|
||||
aws:
|
||||
enabled: true
|
||||
accountNumber: "$MY_ACC_NUM"
|
||||
roleName: $MY_ROLE_NAME
|
||||
```
|
||||
|
||||
> **注意**：账号需要像上面那样以字符串格式指定，否则安装会失败。
|
||||
|
||||
然后，使用以下命令安装 Adapter：
|
||||
|
||||
```bash
|
||||
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter -f values.yaml
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Private CA Authority / Rancher-generated Certificates">
|
||||
|
||||
```bash
|
||||
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter --namespace cattle-csp-adapter-system --set aws.enabled=true --set aws.roleName=$MY_ROLE_NAME --set-string aws.accountNumber=$MY_ACC_NUM --set additionalTrustedCAs=true --set image.tag=v1.0.1
|
||||
```
|
||||
|
||||
你也可以使用 `values.yaml` 并指定以下选项：
|
||||
|
||||
```yaml
|
||||
image:
|
||||
tag: v1.0.1
|
||||
aws:
|
||||
enabled: true
|
||||
accountNumber: "$MY_ACC_NUM"
|
||||
roleName: $MY_ROLE_NAME
|
||||
additionalTrustedCAs: true
|
||||
```
|
||||
|
||||
> **注意**：账号需要像上面那样以字符串格式指定，否则安装会失败。
|
||||
|
||||
然后，使用以下命令安装 Adapter：
|
||||
|
||||
```bash
|
||||
helm install rancher-csp-adapter rancher-charts/rancher-csp-adapter -f values.yaml
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 5. 管理证书更新
|
||||
|
||||
如果你在[步骤 3](#3-创建证书密文) 中创建了一个用于存储自定义证书的密文，则随着证书的轮换，你将需要更新此密文。
|
||||
|
||||
首先，使用以下命令删除 cattle-csp-adapter-system 命名空间中的原始密文：
|
||||
|
||||
```bash
|
||||
kubectl delete secret tls-ca-additional -n cattle-csp-adapter-system
|
||||
```
|
||||
|
||||
然后，按照[步骤 3](#3-创建证书密文) 中的安装步骤，将密文的内容替换为更新后的值。
|
||||
|
||||
最后，重新启动 rancher-csp-adapter deployment 来确保更新后的值可供 Adapter 使用：
|
||||
|
||||
```bash
|
||||
kubectl rollout restart deploy rancher-csp-adapter -n cattle-csp-adapter-system
|
||||
```
|
||||
|
||||
> **注意**：有一些方法（例如 cert-manager 的 [trust operator](https://cert-manager.io/docs/projects/trust/)）可以帮助你减少手动轮换任务的数量。这些选项不受官方支持，但可能对想要自动化某些任务的用户有用。
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: 卸载 Adapter
|
||||
weight: 3
|
||||
---
|
||||
|
||||
### 1. 使用 Helm 卸载 Adapter Chart：
|
||||
|
||||
```bash
|
||||
helm uninstall rancher-csp-adapter -n cattle-csp-adapter-system
|
||||
```
|
||||
|
||||
### 2. 删除为 Adapter 创建的命名空间：
|
||||
|
||||
```bash
|
||||
kubectl delete ns cattle-csp-adapter-system
|
||||
```
|
||||
|
||||
### 3. （可选）删除未完成的用户通知：
|
||||
|
||||
```bash
|
||||
kubectl delete RancherUserNotification csp-compliance
|
||||
```
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: Supportconfig Bundle
|
||||
weight: 100
|
||||
---
|
||||
|
||||
安装 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
|
||||
```
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 架构
|
||||
weight: 1
|
||||
---
|
||||
|
||||
Fleet 可以管理来自 Git 的原始 Kubernetes YAML、Helm Chart、Kustomize 或三者的任何组合的部署。无论来源如何，所有资源都会动态转化为 Helm Chart，Helm 会用作引擎来将所有资源部署到集群中。这给了你高度的控制、一致性和可审计性。Fleet 不仅关注扩展能力，而且还提供高度的控制和可见性，从而让用户准确了解集群上安装的内容。
|
||||
|
||||
|
||||
|
||||
+55
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: 在代理后使用 Fleet
|
||||
weight: 3
|
||||
---
|
||||
|
||||
在本节中，你将学习如何在一个设置中启用 Fleet，该设置有一个具有公共 IP 的 Rancher Server，以及一个没有公共 IP 但配置为使用代理的 Kubernetes 集群。
|
||||
|
||||
Rancher 不会与已注册的下游集群建立连接。部署在下游集群上的 Rancher agent 必须能够与 Rancher 建立连接。
|
||||
|
||||
要让 Fleet 在代理后工作，你需要为下游集群设置 **Agent 环境变量**。以下是集群级别的配置选项。
|
||||
|
||||
你可以通过 Rancher UI 为任何集群类型（包括注册集群和自定义集群）配置这些环境变量。可以在编辑现有集群或配置新集群时添加变量。
|
||||
|
||||
对于公共下游集群，[在 Rancher UI 中设置必要的环境变量](#在-rancher-ui-中设置环境变量)就足够了。
|
||||
|
||||
对于私有节点或私有集群，则需要在节点上设置环境变量。然后，在配置自定义集群或注册私有集群时，在 Rancher UI 中配置环境变量。有关如何在 K3s Kubernetes 集群中的 Ubuntu 节点上设置环境变量的示例，请参阅[本节](#在私有节点上设置环境变量)。
|
||||
|
||||
# 必要的环境变量
|
||||
|
||||
为代理添加 Fleet agent 环境变量时，将 <PROXY_IP> 替换为你的私有代理 IP。
|
||||
|
||||
| 变量名称 | 值 |
|
||||
|------------------|--------|
|
||||
| `HTTP_PROXY` | http://<PROXY_IP>:8888 |
|
||||
| `HTTPS_PROXY` | http://<PROXY_IP>:8888 |
|
||||
| `NO_PROXY` | 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local |
|
||||
|
||||
## 在 Rancher UI 中设置环境变量
|
||||
|
||||
要将环境变量添加到现有集群：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 转到要添加环境变量的集群，然后单击 **⋮ > 编辑配置**。
|
||||
1. 单击**高级选项**。
|
||||
1. 单击**添加环境变量**。
|
||||
1. 输入[必要的环境变量](#必要的环境变量)
|
||||
1. 单击**保存**。
|
||||
|
||||
**结果**：Fleet agent 会在代理后工作。
|
||||
|
||||
## 在私有节点上设置环境变量
|
||||
|
||||
对于私有节点和私有集群，代理环境变量需要在节点本身上设置，以及从 Rancher UI 配置。
|
||||
|
||||
此示例显示了如何在 K3s Kubernetes 集群中的 Ubuntu 节点上设置环境变量：
|
||||
|
||||
```
|
||||
ssh -o ForwardAgent=yes ubuntu@<public_proxy_ip>
|
||||
ssh <k3s_ip>
|
||||
export proxy_private_ip=<private_proxy_ip>
|
||||
export HTTP_PROXY=http://${proxy_private_ip}:8888
|
||||
export HTTPS_PROXY=http://${proxy_private_ip}:8888
|
||||
export NO_PROXY=127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
|
||||
```
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Windows 支持
|
||||
weight: 2
|
||||
---
|
||||
|
||||
|
||||
在 Rancher 2.5.6 之前，`agent` 在具有 Windows 节点的下游集群上没有原生的 Windows 清单。这将导致集群的 `agent` pod 失败。
|
||||
|
||||
如果你从旧版本的 Rancher 升级到 2.5.6+，你可以在*下游集群*中部署具有以下工作流的工作 `agent`：
|
||||
|
||||
1. 封锁所有 Windows 节点。
|
||||
1. 对 `agent` 工作负载应用以下容忍度。
|
||||
1. 取消所有 Windows 节点的封锁。
|
||||
1. 删除所有 `agent` pod。使用新的容忍度来创建新 pod。
|
||||
1. `agent` pod 运行并为 Fleet 启用了自动更新后，它们会更新到与 Windows 兼容的 `agent` 版本。
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: cattle.io/os
|
||||
operator: Equal
|
||||
value: linux
|
||||
```
|
||||
+44
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: Harvester 集成
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Harvester 是 Rancher 2.6.1 新增的功能，[Harvester](https://docs.harvesterhci.io/) 是基于 Kubernetes 构建的开源超融合基础架构 (HCI) 软件。Harvester 安装在裸金属服务器上，提供集成的虚拟化和分布式存储功能。虽然 Harvester 使用 Kubernetes 运行，但它不需要用户了解 Kubernetes 概念，因此是一个更加用户友好的应用。
|
||||
|
||||
---
|
||||
**_v2.6.3 的新功能_**
|
||||
|
||||
Harvester 已 GA。有关所有更新，请参阅 [Harvester 发行说明](https://github.com/harvester/harvester/releases)。
|
||||
|
||||
---
|
||||
### 功能开关
|
||||
|
||||
你可以使用 Harvester 的功能开关来管理 Harvester 在 Rancher 虚拟化管理页面的访问，用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。Harvester 的功能开关是默认启用的。如需了解 Rancher 中功能开关的更多详细信息，请单击[此处](../../pages-for-subheaders/enable-experimental-features.md)。
|
||||
|
||||
要导航到 Harvester 集群，请单击 **☰ > 虚拟化管理**。在 **Harvester 集群**页面中，单击集群以转到该 Harvester 集群的视图。
|
||||
|
||||
* 如果启用了 Harvester 功能开关，则会从列出 Kubernetes 集群的任何页面或应用（例如 Fleet 和多集群应用）中过滤掉 Harvester 集群。
|
||||
|
||||
* 如果禁用了 Harvester 功能开关，并且导入了 Harvester 集群，Harvester 集群将显示在**集群管理**页面的 Rancher 集群列表中。仅当功能开关为关闭时，Harvester 集群才会显示在集群列表中。
|
||||
|
||||
* 集成 Harvester 后，你可以将 Harvester 集群导入 Rancher，对应的集群类型是 `Harvester`。
|
||||
|
||||
* 用户只能在**虚拟化管理**页面上导入 Harvester 集群。在**集群管理**页面上导入集群是不支持的，而且会出现警告。建议你返回**虚拟化管理**页面执行此操作。
|
||||
|
||||
### Harvester 主机驱动
|
||||
|
||||
在 Rancher 的 RKE 和 RKE2 选项中，[Harvester 主机驱动](https://docs.harvesterhci.io/v0.3/rancher/node-driver/)被标记为`技术预览`。在**创建**页面和启用驱动后的页面都是一样的情况。无论 Harvester 功能开关是否启用，主机驱动都是可用的。请注意，默认情况下主机驱动是关闭的。用户只能通过**集群管理**页面在 Harvester 上创建 RKE 或 RKE2 集群。
|
||||
|
||||
Harvester 允许通过 Harvester UI 上传和显示 `.ISO` 镜像，但 Rancher UI 不支持。这是因为 `.ISO` 镜像通常需要额外的设置，这会干扰干净的部署（即无需用户干预），并且它们通常不用于云环境。
|
||||
|
||||
如需了解 Rancher 中主机驱动的更多详细信息，请单击[此处](../../pages-for-subheaders/about-provisioning-drivers.md#主机驱动)。
|
||||
|
||||
### 限制
|
||||
|
||||
---
|
||||
**仅适用于 Rancher v2.6.1 和 v2.6.2**：
|
||||
|
||||
- Harvester 0.3.0 不支持离线环境安装。
|
||||
- 不支持将 Harvester 0.2.0 升级到 0.3.0，也不支持升级到新的 1.0.0 版本。
|
||||
|
||||
---
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: 在 RKE2 集群上安装 Istio 的其他步骤
|
||||
weight: 3
|
||||
---
|
||||
|
||||
通过**应用 & 应用市场**页面安装或升级 Istio Helm Chart 时：
|
||||
|
||||
1. 如果要安装 Chart，请单击**在安装前自定义 Helm 选项**，然后单击**下一步**。
|
||||
1. 你将看到配置 Istio Helm Chart 的选项。在**组件**选项卡上，选中**启用 CNI** 旁边的框。
|
||||
1. 添加一个自定义覆盖文件，该文件指定 `cniBinDir` 和 `cniConfDir`。有关这些选项的更多信息，请参阅 [Istio 文档](https://istio.io/latest/docs/setup/additional-setup/cni/#helm-chart-parameters)。下方是一个示例：
|
||||
|
||||
```yaml
|
||||
apiVersion: install.istio.io/v1alpha1
|
||||
kind: IstioOperator
|
||||
spec:
|
||||
components:
|
||||
cni:
|
||||
enabled: true
|
||||
k8s:
|
||||
overlays:
|
||||
- apiVersion: "apps/v1"
|
||||
kind: "DaemonSet"
|
||||
name: "istio-cni-node"
|
||||
patches:
|
||||
- path: spec.template.spec.containers.[name:install-cni].securityContext.privileged
|
||||
value: true
|
||||
values:
|
||||
cni:
|
||||
image: rancher/mirrored-istio-install-cni:1.9.3
|
||||
excludeNamespaces:
|
||||
- istio-system
|
||||
- kube-system
|
||||
logLevel: info
|
||||
cniBinDir: /opt/cni/bin
|
||||
cniConfDir: /etc/cni/net.d
|
||||
```
|
||||
|
||||
**结果**：现在你应该可以根据需要使用 Istio，包括 Sidecar 注入和通过 Kiali 进行监控。
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: 在具有 Pod 安全策略的情况下启用 Istio
|
||||
weight: 1
|
||||
---
|
||||
|
||||
如果你启用了限制性 Pod 安全策略（Pod Security Policy），由于 Istio 需要某些权限才能自行安装和管理 pod 基础设施，因此 Istio 可能无法正常运行。在本文中，我们将配置一个为 Istio 启用了 PSP 的集群，并设置 Istio CNI 插件。
|
||||
|
||||
Istio CNI 插件不再要求每个应用 pod 具有特权 `NET_ADMIN` 容器。如需更多信息，请参阅 [Istio CNI 插件文档](https://istio.io/docs/setup/additional-setup/cni)。请注意，[Istio CNI 插件处于 alpha 阶段](https://istio.io/about/feature-stages/)。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
- 集群必须是 RKE Kubernetes 集群。
|
||||
- 必须使用默认 PodSecurityPolicy 创建集群。
|
||||
|
||||
要在使用 Rancher UI 创建 Kubernetes 集群时启用 Pod 安全策略支持，请转到<b>高级选项</b>。在 <b>Pod 安全策略支持</b>中，单击<b>启用</b>，然后选择一个默认的 pod 安全策略。
|
||||
|
||||
:::
|
||||
|
||||
1. [将 PodSecurityPolicy 设置为不受限制](#1-将-podsecuritypolicy-设置为不受限制)
|
||||
2. [启用 CNI](#2-启用-cni)
|
||||
3. [验证 CNI 是否正常工作](#3-验证-cni-是否正常工作)
|
||||
|
||||
### 1. 将 PodSecurityPolicy 设置为不受限制
|
||||
|
||||
不受限制的 PSP 支持安装 Istio。
|
||||
|
||||
在安装 Istio 的项目或计划安装 Istio 的项目中，将 PSP 设置为 `unrestricted`。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 找到**项目: System**，然后选择 **⋮ > 编辑配置**。
|
||||
1. 将 Pod 安全策略选项更改为不受限制，然后单击**保存**。
|
||||
|
||||
### 2. 启用 CNI
|
||||
|
||||
通过**应用 & 应用市场**安装或升级 Istio 时：
|
||||
|
||||
1. 单击**组件**。
|
||||
2. 选中**启用 CNI**旁边的框。
|
||||
3. 完成 Istio 的安装或升级。
|
||||
|
||||
你也可以通过编辑 `values.yaml` 来启用 CNI：
|
||||
|
||||
```
|
||||
istio_cni.enabled: true
|
||||
```
|
||||
|
||||
在集群中启用 CNI 后，Istio 应该能成功安装。
|
||||
|
||||
### 3. 验证 CNI 是否正常工作
|
||||
|
||||
通过部署[示例应用](https://istio.io/latest/docs/examples/bookinfo/)或部署你自己的应用，来验证 CNI 是否正常工作。
|
||||
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: 项目网络隔离的其他步骤
|
||||
weight: 4
|
||||
---
|
||||
|
||||
在集群中：
|
||||
|
||||
- 你同时使用了 Canal 网络插件与 Rancher 2.5.8 之前版本，或者同时使用了 Rancher 2.5.8+ 以及任意支持执行 Kubernetes 网络策略的 RKE 网络插件（例如 Canal 或 Cisco ACI 插件）。
|
||||
- 启用了项目网络隔离选项。
|
||||
- 安装了 Istio Ingress 模块。
|
||||
|
||||
默认情况下，Istio Ingress Gateway pod 无法将入口流量重定向到工作负载。这是因为安装了 Istio 的命名空间无法访问所有命名空间。为此你有两个选项。
|
||||
|
||||
第一个选项是在需要让 Istio 控制入口的每个命名空间中添加一个新的网络策略。你的策略需要包括以下几行：
|
||||
|
||||
```
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
app: istio-ingressgateway
|
||||
```
|
||||
|
||||
第二个选项是将 `istio-system` 命名空间移动到 `system` 项目中，默认情况下该项目被排除在网络隔离之外。
|
||||
+121
@@ -0,0 +1,121 @@
|
||||
---
|
||||
title: 选择器和抓取配置
|
||||
weight: 2
|
||||
---
|
||||
|
||||
Monitoring 应用设置了 `prometheus.prometheusSpec.ignoreNamespaceSelectors=false`，即在默认情况下跨所有命名空间进行监控。
|
||||
|
||||
这样，你可以查看部署在具有 `istio-injection=enabled` 标签的命名空间中的资源的流量、指标和图。
|
||||
|
||||
如果你想将 Prometheus 限制为特定的命名空间，请设置 `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`。完成此操作后，你需要添加其他配置来继续监控你的资源。
|
||||
|
||||
|
||||
### 通过将 ignoreNamespaceSelectors 设置为 True 来限制对特定命名空间的监控
|
||||
|
||||
要限制对特定命名空间的监控，你需要编辑 `ignoreNamespaceSelectors` Helm Chart 选项。你可以在安装或升级 Monitoring Helm Chart 时配置此选项：
|
||||
|
||||
1. 安装或升级 Monitoring Helm Chart 时，编辑 values.yml 并设置 `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`。
|
||||
1. 完成安装或升级。
|
||||
|
||||
**结果**：Prometheus 将仅用于特定命名空间。换言之，你需要设置以下配置之一才能继续在各种仪表板中查看数据。
|
||||
|
||||
### 让 Prometheus 检测其他命名空间中的资源
|
||||
|
||||
如果设置了 `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`，则有两种方法让 Prometheus 检测其他命名空间中的资源：
|
||||
|
||||
- **监控特定的命名空间**：在命名空间中添加一个 ServiceMonitor 或 PodMonitor 以及要抓取的目标。
|
||||
- **跨命名空间监控**：将 `additionalScrapeConfig` 添加到你的 rancher-monitoring 实例，从而抓取所有命名空间中的所有目标。
|
||||
|
||||
### 监控特定命名空间：创建 ServiceMonitor 或 PodMonitor
|
||||
|
||||
此选项用于定义在特定命名空间中要监控的服务或 pod。
|
||||
|
||||
可用性权衡指的是，由于你无法跨命名空间进行监控，因此你必须为每个命名空间创建 ServiceMonitor 或 PodMonitor。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
为 `<your namespace>` 定义 ServiceMonitor 或 PodMonitor。下面提供了一个 ServiceMonitor 示例。
|
||||
|
||||
:::
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在顶部导航栏中，打开 kubectl shell。
|
||||
1. 如果 ServiceMonitor 或 PodMonitor 文件存储在本地集群中，请运行 `kubectl create -f <name of service/pod monitor file>.yaml`。
|
||||
1. 如果 ServiceMonitor 或 PodMonitor 没有存储在本地，请运行 `cat<< EOF | kubectl apply -f -`，将文件内容粘贴到终端，然后运行 `EOF` 来完成命令。
|
||||
1. 运行 `kubectl label namespace <your namespace> istio-injection=enabled` 来启用 Envoy sidecar 注入。
|
||||
|
||||
**结果**：Prometheus 可以抓取 `<your namespace>`。
|
||||
|
||||
<figcaption>Istio 代理的 ServiceMonitor 示例</figcaption>
|
||||
|
||||
```yaml
|
||||
apiVersion: monitoring.coreos.com/v1
|
||||
kind: ServiceMonitor
|
||||
metadata:
|
||||
name: envoy-stats-monitor
|
||||
namespace: istio-system
|
||||
labels:
|
||||
monitoring: istio-proxies
|
||||
spec:
|
||||
selector:
|
||||
matchExpressions:
|
||||
- {key: istio-prometheus-ignore, operator: DoesNotExist}
|
||||
namespaceSelector:
|
||||
any: true
|
||||
jobLabel: envoy-stats
|
||||
endpoints:
|
||||
- path: /stats/prometheus
|
||||
targetPort: 15090
|
||||
interval: 15s
|
||||
relabelings:
|
||||
- sourceLabels: [__meta_kubernetes_pod_container_port_name]
|
||||
action: keep
|
||||
regex: '.*-envoy-prom'
|
||||
- action: labeldrop
|
||||
regex: "__meta_kubernetes_pod_label_(.+)"
|
||||
- sourceLabels: [__meta_kubernetes_namespace]
|
||||
action: replace
|
||||
targetLabel: namespace
|
||||
- sourceLabels: [__meta_kubernetes_pod_name]
|
||||
action: replace
|
||||
targetLabel: pod_name
|
||||
```
|
||||
|
||||
### 跨命名空间监控：将 ignoreNamespaceSelectors 设置为 False
|
||||
|
||||
此设置为 Prometheus 提供额外的抓取配置来实现跨命名空间监控。
|
||||
|
||||
可用性权衡指的是 Prometheus 的所有 `additionalScrapeConfigs` 都维护在一个 Secret 中。如果在安装 Istio 之前已经使用 additionalScrapeConfigs 部署了监控，升级可能会变得困难。
|
||||
|
||||
1. 安装或升级 Monitoring Helm Chart 时，编辑 values.yml 并将 `prometheus.prometheusSpec.additionalScrapeConfigs` 数组设置为下方的**其它抓取配置**。
|
||||
1. 完成安装或升级。
|
||||
|
||||
**结果**：Promethe 会抓取所有带有 `istio-injection=enabled` 标签的命名空间。
|
||||
|
||||
<figcaption>其它抓取配置</figcaption>
|
||||
|
||||
```yaml
|
||||
- job_name: 'istio/envoy-stats'
|
||||
scrape_interval: 15s
|
||||
metrics_path: /stats/prometheus
|
||||
kubernetes_sd_configs:
|
||||
- role: pod
|
||||
relabel_configs:
|
||||
- source_labels: [__meta_kubernetes_pod_container_port_name]
|
||||
action: keep
|
||||
regex: '.*-envoy-prom'
|
||||
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
|
||||
action: replace
|
||||
regex: ([^:]+)(?::\d+)?;(\d+)
|
||||
replacement: $1:15090
|
||||
target_label: __address__
|
||||
- action: labelmap
|
||||
regex: __meta_kubernetes_pod_label_(.+)
|
||||
- source_labels: [__meta_kubernetes_namespace]
|
||||
action: replace
|
||||
target_label: namespace
|
||||
- source_labels: [__meta_kubernetes_pod_name]
|
||||
action: replace
|
||||
target_label: pod_name
|
||||
```
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: CPU 和内存分配
|
||||
weight: 1
|
||||
---
|
||||
|
||||
本文介绍我们建议在集群中分配给 Istio 组件的最少计算资源。
|
||||
|
||||
每个组件的 CPU 和内存分配是[可配置](#配置资源分配)的。
|
||||
|
||||
在启用 Istio 之前，建议你先确认你的 Rancher worker 节点是否有足够的 CPU 和内存来运行 Istio 的所有组件。
|
||||
|
||||
:::tip
|
||||
|
||||
在规模较大的部署中，我们强烈建议通过为每个 Istio 组件添加节点选择器，来将基础设施放置在集群中的专用节点上。
|
||||
|
||||
:::
|
||||
|
||||
下表总结了每个核心 Istio 组件推荐配置的 CPU 和内存的最低资源请求和限制。
|
||||
|
||||
Kubernetes 中的资源请求指的是，除非该节点至少具有指定数量的可用内存和 CPU，否则工作负载不会部署在节点上。如果工作负载超过 CPU 或内存的限制，则可以将其从节点中终止或驱逐。有关管理容器资源限制的更多信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)。
|
||||
|
||||
| 工作负载 | CPU - 请求 | 内存 - 请求 | CPU - 限制 | 内存 - 限制 |
|
||||
|----------------------|---------------|------------|-----------------|-------------------|
|
||||
| 入口网关 | 100m | 128mi | 2000m | 1024mi |
|
||||
| 出口网关 | 100m | 128mi | 2000m | 1024mi |
|
||||
| istiod | 500m | 2048mi | 没有限制 | 没有限制 |
|
||||
| proxy | 10m | 10mi | 2000m | 1024mi |
|
||||
| **总计：** | **710m** | **2314Mi** | **6000m** | **3072Mi** |
|
||||
|
||||
## 配置资源分配
|
||||
|
||||
你可以为每种类型的 Istio 组件单独配置资源分配。本节介绍了每个组件默认分配的资源。
|
||||
|
||||
为了更轻松地将工作负载调度到节点，集群管理员可以降低组件的 CPU 和内存资源请求。默认 CPU 和内存分配是我们推荐的最小值。
|
||||
|
||||
关于 Istio 配置的更多信息，请参阅 [Istio 官方文档](https://istio.io/)。
|
||||
|
||||
要配置分配给 Istio 组件的资源：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，点击**应用 & 应用市场**。
|
||||
1. 点击**已安装的应用**。
|
||||
1. 转到 `istio-system` 命名空间。在某个 Istio 工作负载中（例如 `rancher-istio`），点击**⋮ > 编辑/升级**。
|
||||
1. 点击**升级**，然后通过更改 values.yaml 或添加[覆盖文件](../../../pages-for-subheaders/configuration-options.md#覆盖文件)来编辑基本组件。有关编辑覆盖文件的更多信息，请参阅[本节](cpu-and-memory-allocations.md#编辑覆盖文件)。
|
||||
1. 更改 CPU 或内存分配、调度各个组件的节点，或节点容忍度。
|
||||
1. 点击**升级**。然后，更改就能启用。
|
||||
|
||||
**结果**：已更新 Istio 组件的资源分配。
|
||||
|
||||
### 编辑覆盖文件
|
||||
|
||||
覆盖文件可以包含 [Istio Operator 规范](https://istio.io/latest/docs/reference/config/istio.operator.v1alpha1/#IstioOperatorSpec)中的任意值。包含 Istio 应用的覆盖文件只是覆盖文件潜在配置的一个示例。
|
||||
|
||||
只要文件包含 `kind: IstioOperator` 且 YAML 选项有效，文件就可以用作覆盖。
|
||||
|
||||
在 Istio 应用提供的示例覆盖文件中，以下部分能让你更改 Kubernetes 资源：
|
||||
|
||||
```
|
||||
# k8s:
|
||||
# resources:
|
||||
# requests:
|
||||
# cpu: 200m
|
||||
```
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: 禁用 Istio
|
||||
weight: 4
|
||||
---
|
||||
|
||||
本文介绍如何在集群中卸载 Istio，以及如何在命名空间或工作负载中禁用 Istio。
|
||||
|
||||
## 在集群中卸载 Istio
|
||||
|
||||
要卸载 Istio：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**应用 & 应用市场 > 已安装的应用**。
|
||||
1. 在 `istio-system` 命名空间中，转到 `rancher-istio` 并单击 **⋮ > 删除**。
|
||||
1. 删除 `rancher-istio` 后，选择 `istio-system` 命名空间中所有剩余的应用，然后单击**删除**。
|
||||
|
||||
**结果**：已删除集群中的 `rancher-istio` 应用。Istio sidecar 不能部署在集群中的任何工作负载上。
|
||||
|
||||
:::note
|
||||
|
||||
你不能再禁用和重新启用你的 Istio 安装。如果你想保存设置以供将来的安装使用，请查看并保存各个 YAML，以便在之后的安装中参考/重复使用。
|
||||
|
||||
:::
|
||||
|
||||
**卸载疑难解答**：如果你没有按照卸载步骤操作，则可能会在卸载过程中遇到以下警告：
|
||||
|
||||
`Error: uninstallation completed with 1 error(s): unable to build kubernetes objects for delete: unable to recognize "": no matches for kind "MonitoringDashboard" in version "monitoring.kiali.io/v1alpha1"`
|
||||
|
||||
这可能意味着几种情况。第一种情况是你选择了 `istio-system` 命名空间中的所有应用并同时删除了它们，另一种情况是你在删除 `rancher-istio` Chart 之前删除了`rancher-istio` Chart 依赖项。由于卸载未正确完成，你将需要手动清理 `istio-system` 命名空间中剩余的资源。如果不想进行手动清理，你可以重新安装 `rancher-istio`，然后按照正确的顺序卸载它。
|
||||
|
||||
## 在命名空间中禁用 Istio
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 单击**集群 > 项目/命名空间**。
|
||||
1. 转到要启用 Istio 的命名空间，然后单击**⋮ > 启用 Istio 自动注入**。或者，你也可以单击命名空间，然后在命名空间详情页面上，单击**⋮ > 启用 Istio 自动注入**。
|
||||
|
||||
**结果**：如果工作负载部署到此命名空间，它们将没有 Istio sidecar。
|
||||
|
||||
## 从工作负载中移除 Istio Sidecar
|
||||
|
||||
在命名空间中禁用 Istio，然后重新部署其中的工作负载。这些工作负载将在没有 Istio sidecar 的情况下部署。
|
||||
+44
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: RBAC
|
||||
weight: 3
|
||||
---
|
||||
|
||||
本文介绍访问 Istio 功能所需的权限。
|
||||
|
||||
Rancher Istio Chart 安装了三个 `ClusterRole`。
|
||||
|
||||
## Cluster-Admin 访问
|
||||
|
||||
默认情况下，只有具有 `cluster-admin` `ClusterRole` 的用户可以：
|
||||
|
||||
- 在集群中安装 Istio 应用。
|
||||
- 为 Istio 配置资源分配。
|
||||
|
||||
|
||||
## Admin 和 Edit 权限
|
||||
|
||||
默认情况下，只有 Admin 和 Edit 角色可以：
|
||||
|
||||
- 为命名空间启用和禁用 Istio sidecar 自动注入。
|
||||
- 将 Istio sidecar 添加到工作负载。
|
||||
- 查看集群的流量指标和流量图。
|
||||
- 配置 Istio 的资源（例如网关、目标规则或虚拟服务）。
|
||||
|
||||
## Kubernetes 默认角色的默认权限摘要
|
||||
|
||||
Istio 创建了三个 `ClusterRole`，并将 Istio CRD 访问权限添加到以下默认 K8s `ClusterRole`：
|
||||
|
||||
| Chart 创建的 ClusterRole | 默认 K8s ClusterRole | Rancher 角色 |
|
||||
------------------------------:| ---------------------------:|---------:|
|
||||
| `istio-admin` | admin | 项目所有者 |
|
||||
| `istio-edit` | edit | 项目成员 |
|
||||
| `istio-view` | view | 只读 |
|
||||
|
||||
Rancher 将继续使用 cluster-owner、cluster-member、project-owner、project-member 等作为角色名称，但会使用默认角色来确定访问权限。每个默认的 K8s `ClusterRole` 都有不同的 Istio CRD 权限以及可以执行的 K8s 操作，包括 Create (C)，Get (G)，List (L)，Watch (W)，Update (U)，Patch (P)，Delete (D) 和 All (*)。
|
||||
|
||||
|
||||
| CRD | Admin | Edit | View |
|
||||
|----------------------------| ------| -----| -----
|
||||
| <ul><li>`config.istio.io`</li><ul><li>`adapters`</li><li>`attributemanifests`</li><li>`handlers`</li><li>`httpapispecbindings`</li><li>`httpapispecs`</li><li>`instances`</li><li>`quotaspecbindings`</li><li>`quotaspecs`</li><li>`rules`</li><li>`templates`</li></ul></ul> | GLW | GLW | GLW |
|
||||
| <ul><li>`networking.istio.io`</li><ul><li>`destinationrules`</li><li>`envoyfilters`</li><li>`gateways`</li><li>`serviceentries`</li><li>`sidecars`</li><li>`virtualservices`</li><li>`workloadentries`</li></ul></ul> | * | * | GLW |
|
||||
| <ul><li>`security.istio.io`</li><ul><li>`authorizationpolicies`</li><li>`peerauthentications`</li><li>`requestauthentications`</li></ul></ul> | * | * | GLW |
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: Flows 和 ClusterFlows
|
||||
weight: 1
|
||||
---
|
||||
|
||||
有关配置 `Flow` 和 `ClusterFlow` 的完整详细信息，请参阅 [Banzai Cloud Logging Operator 文档](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/flow/)。
|
||||
|
||||
|
||||
## Flows
|
||||
|
||||
`Flow` 定义要收集和过滤哪些日志，以及将日志发送到哪个 Output。
|
||||
|
||||
`Flow` 是一个命名空间资源。换言之，只有部署了该 Flow 的命名空间日志才能被 `Flow` 收集。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `Flow`。
|
||||
|
||||
有关 `Flow` 自定义资源的更多详细信息，请参阅 [FlowSpec](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/flow_types/)。
|
||||
|
||||
### Matches
|
||||
|
||||
匹配语句用于选择从哪些容器中拉取日志。
|
||||
|
||||
你可以指定 match 语句，然后根据 Kubernetes 标签、容器和主机名来选择或排除日志。匹配语句会按照定义和处理的顺序进行评估，直到应用了第一个匹配的选择/排除规则。
|
||||
|
||||
你可以通过填写 Rancher UI 中的 `Flow` 或 `ClusterFlow` 表单来配置匹配。
|
||||
|
||||
使用 match 语句的详细示例，请参阅[日志路由的官方文档](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/log-routing/)。
|
||||
|
||||
### Filters
|
||||
|
||||
你可以在 `Flow` 中定义一个或多个过滤器。过滤器可以对日志执行各种操作，例如，添加其他数据、转换日志或解析记录中的值。`Flow` 中的过滤器会按定义的顺序应用。
|
||||
|
||||
有关 Banzai Cloud Logging Operator 支持的过滤器列表，请参阅[此页面](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/filters/)。
|
||||
|
||||
过滤器需要在 YAML 中配置。
|
||||
|
||||
### Outputs
|
||||
|
||||
此 `Output` 会接收来自 `Flow` 的日志。由于 `Flow` 是一个命名空间资源，因此 `Output` 必须与 `Flow` 位于相同的命名空间中。
|
||||
|
||||
在 Rancher UI 中填写 `Flow` 或 `ClusterFlow` 表单时，你可以引用`Output`。
|
||||
|
||||
## ClusterFlows
|
||||
|
||||
为 `ClusterFlow` 配置匹配、过滤器和 `Output` 的方式与 `Flow` 的配置方式相同。主要区别在于 `ClusterFlow` 是集群级别的，并且可以跨所有命名空间配置日志收集。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `ClusterFlow`。
|
||||
|
||||
`ClusterFlow` 选择集群中所有命名空间的日志后，集群的日志会被收集并记录到所选的 `ClusterOutput`。
|
||||
|
||||
## YAML 示例
|
||||
|
||||
以下示例 `Flow` 转换了默认命名空间的日志消息，并将日志发送到 S3 `Output`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Flow
|
||||
metadata:
|
||||
name: flow-sample
|
||||
namespace: default
|
||||
spec:
|
||||
filters:
|
||||
- parser:
|
||||
remove_key_name_field: true
|
||||
parse:
|
||||
type: nginx
|
||||
- tag_normaliser:
|
||||
format: ${namespace_name}.${pod_name}.${container_name}
|
||||
localOutputRefs:
|
||||
- s3-output
|
||||
match:
|
||||
- select:
|
||||
labels:
|
||||
app: nginx
|
||||
```
|
||||
+294
@@ -0,0 +1,294 @@
|
||||
---
|
||||
title: Outputs 和 ClusterOutputs
|
||||
weight: 2
|
||||
---
|
||||
|
||||
有关配置 `Output` 和 `ClusterOutput` 的完整详细信息，请参阅 [Banzai Cloud Logging Operator 文档](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/)。
|
||||
|
||||
## Outputs
|
||||
|
||||
`Output` 资源定义了你的 `Flow` 可以发送日志消息的位置。`Output` 是 Logging `Flow` 的最后阶段。
|
||||
|
||||
`Output` 是命名空间资源，换言之，只有同一命名空间内的 `Flow` 可以访问它。
|
||||
|
||||
你可以在这些定义中使用密文，但这些密文也必须位于同一命名空间中。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `Output`。
|
||||
|
||||
有关 `Output` 自定义资源的更多详细信息，请参阅 [OutputSpec](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/output_types/)。
|
||||
|
||||
Rancher UI 提供了用于配置以下类型 `Output` 的表单：
|
||||
|
||||
- Amazon ElasticSearch
|
||||
- Azure Storage
|
||||
- Cloudwatch
|
||||
- Datadog
|
||||
- Elasticsearch
|
||||
- File
|
||||
- Fluentd
|
||||
- GCS
|
||||
- Kafka
|
||||
- Kinesis Stream
|
||||
- LogDNA
|
||||
- LogZ
|
||||
- Loki
|
||||
- New Relic
|
||||
- Splunk
|
||||
- SumoLogic
|
||||
- Syslog
|
||||
|
||||
Rancher UI 提供了用于配置 `Output` 类型、目标和访问凭证（如果适用）的表单。
|
||||
|
||||
有关 Logging Operator 支持的日志插件配置示例，请参阅 [Logging Operator 文档](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/)。
|
||||
|
||||
## ClusterOutputs
|
||||
|
||||
`ClusterOutput` 定义了一个没有命名空间限制的 `Output`。只有在与 Logging Operator 部署在同一命名空间中时，它才能生效。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `ClusterOutput`。
|
||||
|
||||
有关 `ClusterOutput` 自定义资源的更多详细信息，请参阅 [ClusterOutput](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)。
|
||||
|
||||
## YAML 示例
|
||||
|
||||
安装 Logging 后，你可以参考以下示例来构建你自己的 Logging 流水线：
|
||||
|
||||
- [ClusterOutput 设为 ElasticSearch](#clusteroutput-设为-elasticsearch)
|
||||
- [Output 设为 Splunk](#output-设为-splunk)
|
||||
- [Output 设为 Syslog](#output-设为-syslog)
|
||||
- [不支持的 Output](#不支持的-output)
|
||||
|
||||
### ClusterOutput 设为 ElasticSearch
|
||||
|
||||
假设你想将集群中的所有日志发送到 `elasticsearch` 集群。首先，创建一个集群 `Output`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: "example-es"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
elasticsearch:
|
||||
host: elasticsearch.example.com
|
||||
port: 9200
|
||||
scheme: http
|
||||
```
|
||||
|
||||
在与 Operator 相同的命名空间（`cattle-logging-system`）中，我们创建了这个 `ClusterOutput`（没有 elasticsearch 配置）。每次创建 `ClusterFlow` 或 `ClusterOutput` 时，我们都必须将其放在 `cattle-logging-system` 命名空间中。
|
||||
|
||||
配置日志的目的位置后，我们可以尝试将所有日志都配置到该 `ClusterOutput`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: "all-logs"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- "example-es"
|
||||
```
|
||||
|
||||
现在，我们应该能看到配置的包含日志的索引。
|
||||
|
||||
|
||||
### Output 设为 Splunk
|
||||
|
||||
有时候，你的应用程序团队可能只想将某个命名空间的日志发送到 `splunk` 服务器。对于这种情况，你可以使用命名空间范围的 `Output` 和 `Flow`。
|
||||
|
||||
在开始之前，先设置该团队的应用程序 `coolapp`。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: devteam
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: coolapp
|
||||
namespace: devteam
|
||||
labels:
|
||||
app: coolapp
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
app: coolapp
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: coolapp
|
||||
spec:
|
||||
containers:
|
||||
- name: generator
|
||||
image: paynejacob/loggenerator:latest
|
||||
```
|
||||
|
||||
`coolapp` 运行时，我们将使用与创建 `ClusterOutput` 时类似的路径。但是，我们不使用 `ClusterOutput`，而是在应用程序的命名空间中创建 `Output`。
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Output
|
||||
metadata:
|
||||
name: "devteam-splunk"
|
||||
namespace: "devteam"
|
||||
spec:
|
||||
splunkHec:
|
||||
hec_host: splunk.example.com
|
||||
hec_port: 8088
|
||||
protocol: http
|
||||
```
|
||||
|
||||
然后，再次为 `Output` 提供一些日志：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Flow
|
||||
metadata:
|
||||
name: "devteam-logs"
|
||||
namespace: "devteam"
|
||||
spec:
|
||||
localOutputRefs:
|
||||
- "devteam-splunk"
|
||||
```
|
||||
|
||||
|
||||
### Output 设为 Syslog
|
||||
|
||||
假设你想将集群中的所有日志发送到 `syslog` 服务器。首先，我们创建一个 `ClusterOutput`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: "example-syslog"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
syslog:
|
||||
buffer:
|
||||
timekey: 30s
|
||||
timekey_use_utc: true
|
||||
timekey_wait: 10s
|
||||
flush_interval: 5s
|
||||
format:
|
||||
type: json
|
||||
app_name_field: test
|
||||
host: syslog.example.com
|
||||
insecure: true
|
||||
port: 514
|
||||
transport: tcp
|
||||
```
|
||||
|
||||
配置日志的目的位置后，我们可以尝试将所有日志都配置到该 `Output`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: "all-logs"
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- "example-syslog"
|
||||
```
|
||||
|
||||
### 不支持的 Output
|
||||
|
||||
对于最后一个示例，我们创建一个 `Output` 来将日志写入到不是开箱即用的目标位置：
|
||||
|
||||
:::note Syslog 注意事项：
|
||||
|
||||
`Syslog` 是受支持的 `Output`。但是，此示例仍提供了不受支持的插件概述。
|
||||
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: syslog-config
|
||||
namespace: cattle-logging-system
|
||||
type: Opaque
|
||||
stringData:
|
||||
fluent-bit.conf: |
|
||||
[INPUT]
|
||||
Name forward
|
||||
Port 24224
|
||||
|
||||
[OUTPUT]
|
||||
Name syslog
|
||||
InstanceName syslog-output
|
||||
Match *
|
||||
Addr syslog.example.com
|
||||
Port 514
|
||||
Cluster ranchers
|
||||
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: fluentbit-syslog-forwarder
|
||||
namespace: cattle-logging-system
|
||||
labels:
|
||||
output: syslog
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
output: syslog
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
output: syslog
|
||||
spec:
|
||||
containers:
|
||||
- name: fluentbit
|
||||
image: paynejacob/fluent-bit-out-syslog:latest
|
||||
ports:
|
||||
- containerPort: 24224
|
||||
volumeMounts:
|
||||
- mountPath: "/fluent-bit/etc/"
|
||||
name: configuration
|
||||
volumes:
|
||||
- name: configuration
|
||||
secret:
|
||||
secretName: syslog-config
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: syslog-forwarder
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
selector:
|
||||
output: syslog
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 24224
|
||||
targetPort: 24224
|
||||
---
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: all-logs
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- syslog
|
||||
---
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: syslog
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
forward:
|
||||
servers:
|
||||
- host: "syslog-forwarder.cattle-logging-system"
|
||||
require_ack_response: false
|
||||
ignore_network_errors_at_startup: false
|
||||
```
|
||||
|
||||
现在，我们分解这里的内容。首先，我们创建一个容器 Deployment，该容器具有额外的 `syslog` 插件并支持转发自另一个 `fluentd` 的日志。接下来，我们创建一个配置为 Deployment 转发器的 `Output`。然后，Deployment `fluentd` 会将所有日志转发到配置的 `syslog` 目标。
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: 架构
|
||||
weight: 1
|
||||
---
|
||||
|
||||
本节介绍了 Rancher Logging 应用程序的架构。
|
||||
|
||||
有关 Banzai Cloud Logging Operator 工作原理的更多详细信息，请参阅[官方文档](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture)。
|
||||
|
||||
### Banzai Cloud Logging Operator 工作原理
|
||||
|
||||
Logging Operator 自动部署和配置 Kubernetes 日志流水线。它会在每个节点上部署和配置一个 Fluent Bit DaemonSet，从而收集节点文件系统中的容器和应用程序日志。
|
||||
|
||||
Fluent Bit 查询 Kubernetes API 并使用 pod 的元数据来丰富日志，然后将日志和元数据都传输到 Fluentd。Fluentd 会接收和过滤日志并将日志传输到多个`Output`。
|
||||
|
||||
以下自定义资源用于定义了如何过滤日志并将日志发送到 `Output`：
|
||||
|
||||
- `Flow` 是一个命名空间自定义资源，它使用过滤器和选择器将日志消息路由到对应的 `Output`。
|
||||
- `ClusterFlow` 用于路由集群级别的日志消息。
|
||||
- `Output` 是一个命名空间资源，用于定义发送日志消息的位置。
|
||||
- `ClusterOutput` 定义了一个所有 `Flow` 和 `ClusterFlow` 都可用的 `Output`。
|
||||
|
||||
每个 `Flow` 都必须引用一个 `Output`，而每个 `ClusterFlow` 都必须引用一个 `ClusterOutput`。
|
||||
|
||||
[Banzai 文档](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture)中的下图显示了新的 Logging 架构：
|
||||
|
||||
<figcaption>Banzai Cloud Logging Operator 如何与 Fluentd 和 Fluent Bit 一起使用</figcaption>
|
||||
|
||||
|
||||
+97
@@ -0,0 +1,97 @@
|
||||
---
|
||||
title: rancher-logging Helm Chart 选项
|
||||
shortTitle: Helm Chart 选项
|
||||
weight: 4
|
||||
---
|
||||
|
||||
|
||||
### 启用/禁用 Windows 节点 Logging
|
||||
|
||||
要启用或禁用 Windows 节点 Logging，你可以在 `values.yaml` 中将 `global.cattle.windows.enabled` 设置为 `true` 或 `false`。
|
||||
|
||||
默认情况下，如果使用 Cluster Dashboard UI 在 Windows 集群上安装了 Logging 应用程序，Windows 节点的 Logging 就会启用。
|
||||
|
||||
在这种情况下，将 `global.cattle.windows.enabled` 设置为 `false` 会禁用集群上的 Windows 节点 Logging。
|
||||
禁用后，仍会从 Windows 集群中的 Linux 节点收集日志。
|
||||
|
||||
:::note
|
||||
|
||||
目前存在一个[问题](https://github.com/rancher/rancher/issues/32325)，在 Windows 集群中禁用 Windows Logging 后执行 `helm upgrade` 时不会删除 Windows nodeAgent。在这种情况下，如果已安装 Windows nodeAgents，用户可能需要手动卸载它们。
|
||||
|
||||
:::
|
||||
|
||||
### 使用自定义 Docker 根目录
|
||||
|
||||
如果使用了自定义 Docker 根目录，你可以在 `values.yaml` 中设置 `global.dockerRootDirectory`。
|
||||
|
||||
这将确保创建的 Logging CR 使用你指定的路径，而不是使用默认的 Docker `data-root` 位置。
|
||||
|
||||
请注意，这只影响 Linux 节点。
|
||||
|
||||
如果集群中有任何 Windows 节点，则更改将不适用于这些节点。
|
||||
|
||||
### 为自定义污点添加 NodeSelector 设置和容忍度
|
||||
|
||||
你可以添加 `nodeSelector` 设置，并通过编辑 Logging Helm Chart 值来添加其他`容忍度`。有关详细信息，请参阅[此页面](taints-and-tolerations.md)。
|
||||
|
||||
### 启用 Logging 应用程序以使用 SELinux
|
||||
|
||||
:::note 要求：
|
||||
|
||||
Logging v2 已在 RHEL/CentOS 7 和 8 上使用 SELinux 进行了测试。
|
||||
|
||||
:::
|
||||
|
||||
[安全增强型 Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是对 Linux 的安全增强。被政府机构使用之后，SELinux 已成为行业标准，并在 CentOS 7 和 8 上默认启用。
|
||||
|
||||
要配合使用 Logging V2 与 SELinux，我们建议你根据[此页面](../../../pages-for-subheaders/selinux-rpm.md#安装-rancher-selinux-rpm)的安装说明安装 `rancher-selinux` RPM。
|
||||
|
||||
然后，在安装 Logging 应用程序时，在 `values.yaml` 中将 `global.seLinux.enabled` 更改为 `true`，使 Chart 支持 SELinux。
|
||||
|
||||
### 其他日志来源
|
||||
|
||||
默认情况下，Rancher 会收集所有类型集群的 [controlplane 组件](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components)和[节点组件](https://kubernetes.io/docs/concepts/overview/components/#node-components)的日志。
|
||||
|
||||
在某些情况下，Rancher 也能收集其他的日志。
|
||||
|
||||
下表总结了每种节点类型可以收集的其他日志来源：
|
||||
|
||||
| 日志来源 | Linux 节点（包括在 Windows 集群中） | Windows 节点 |
|
||||
| --- | --- | ---|
|
||||
| RKE | ✓ | ✓ |
|
||||
| RKE2 | ✓ | |
|
||||
| K3s | ✓ | |
|
||||
| AKS | ✓ | |
|
||||
| EKS | ✓ | |
|
||||
| GKE | ✓ | |
|
||||
|
||||
要将托管 Kubernetes 的提供商作为额外的日志来源，在安装或升级 Logging Helm Chart 时，请启用 **Enable enhanced cloud provider logging** 选项。
|
||||
|
||||
启用后，Rancher 会收集提供商开放可用的所有其他节点和 controlplane 日志，不同提供商可能有所不同。
|
||||
|
||||
如果你已经使用了云提供商的日志解决方案，例如 AWS CloudWatch 或 Google Cloud Operations Suite（以前称为 Stackdriver），由于原生解决方案可以不受限制地访问所有日志，因此你无需启用此选项。
|
||||
|
||||
### Systemd 配置
|
||||
|
||||
在 Rancher Logging 中，你必须为 K3s 和 RKE2 Kubernetes 发行版配置 `SystemdLogPath`。
|
||||
|
||||
K3s 和 RKE2 Kubernetes 发行版将日志写入到 journald，它是 systemd 的子系统，用于日志记录。要收集这些日志，你需要定义 `systemdLogPath`。默认路径是 `run/log/journal`，但某些 Linux 发行版不默认使用该路径。例如，Ubuntu 默认使用 `var/log/journal`。要确定你的 `systemdLogPath` 配置，请参阅以下步骤。
|
||||
|
||||
**Systemd 配置步骤：**
|
||||
|
||||
* 在其中一个节点上运行 `cat /etc/systemd/journald.conf | grep -E ^\#?Storage | cut -d"=" -f2`。
|
||||
* 如果返回 `persistent`，则你的 `systemdLogPath` 是 `/var/log/journal`。
|
||||
* 如果返回 `volatile`，则你的 `systemdLogPath` 是 `/run/log/journal`。
|
||||
* 如果返回 `auto`，则检查 `/var/log/journal` 是否存在。
|
||||
* 如果 `/var/log/journal` 存在，则使用 `/var/log/journal`。
|
||||
* 如果 `/var/log/journal` 不存在，则使用 `/run/log/journal`。
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
如果返回的值不包括在上述描述中，Rancher Logging 将无法收集 controlplane 日志。要解决此问题，你需要在每个 controlplane 节点上执行以下操作。
|
||||
|
||||
* 在 journald.conf 中设置 `Storage=volatile`。
|
||||
* 重启主机。
|
||||
* 将 `systemdLogPath` 设置为 `/run/log/journal`。
|
||||
|
||||
:::
|
||||
+189
@@ -0,0 +1,189 @@
|
||||
---
|
||||
title: 迁移到 Rancher 2.5 Logging
|
||||
weight: 2
|
||||
---
|
||||
Rancher 2.5 彻底修改了 Logging 功能。我们现在使用了 Banzai Cloud 的 [logging operator](https://github.com/banzaicloud/logging-operator)，Rancher 配置了此工具以供部署 Logging 使用。
|
||||
|
||||
在新的 Logging 功能的众多特性和变化中，其中一项是取消了项目级别的 Logging 配置。取而代之的是在命名空间级别配置 Logging。集群级日志仍然可用，但配置选项不同。
|
||||
|
||||
## 安装
|
||||
|
||||
要在 Rancher 2.5+ 中安装 Logging，请参阅[安装说明](../../../pages-for-subheaders/logging.md#启用-logging)。
|
||||
|
||||
### 名词解释
|
||||
|
||||
在 Rancher 2.5+ 中，你需要在**集群仪表板**中配置 Logging。要在安装 Logging 应用程序后配置 Logging 自定义资源，请转到左侧导航栏并单击 **Logging**。这个菜单的选项可以配置集群和命名空间的 Logging。
|
||||
|
||||
:::note
|
||||
|
||||
Logging 是按集群安装的。你将需要在集群之间切换以配置每个集群的 Logging。
|
||||
|
||||
:::
|
||||
|
||||
对于 Rancher 2.5+ 中的 Logging 应用程序，你需要了解以下四个关键概念：
|
||||
|
||||
1. Outputs
|
||||
|
||||
`Outputs` 是一种配置资源，用于确定收集日志的目的位置。这是存储 ElasticSearch、Kafka 等聚合器设置的地方。`Outputs` 是命名空间资源。
|
||||
|
||||
2. Flows
|
||||
|
||||
`Flows` 是一种配置资源，用于确定日志的收集、过滤和目标位置规则。在一个 Flow 中，你需要配置要收集哪些日志、如何改变或过滤它们，以及将日志发送到哪个 `Output`。`Flows` 是命名空间资源，可以连接到同一命名空间中的 `Output` 或 `ClusterOutput`。
|
||||
|
||||
3. ClusterOutputs
|
||||
|
||||
`ClusterOutputs` 的功能与 `Outputs` 相同，但 ClusterOutput 是集群级别资源。在集群范围内收集日志或要为集群中的所有命名空间提供 `Output` 时，`ClusterOutput` 是必需的。
|
||||
|
||||
4. ClusterFlows
|
||||
|
||||
`ClusterFlows` 的功能与 `Flows` 相同，但 ClusterFlow 是集群级别资源。它们用于为整个集群配置日志收集，而不是在命名空间级别进行逐个配置。`ClusterFlows` 也是定义改变和过滤器的地方，在功能上与 `Flows` 相同。
|
||||
|
||||
## 集群日志
|
||||
|
||||
要在 Rancher 2.5+ 中配置集群级别的 Logging，你需要设置 `ClusterFlow`。此对象定义了日志的来源、要应用的转换或过滤器，以及日志的一个或多个 `Output`。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
`ClusterFlow` 必须在 `cattle-logging-system` 命名空间中定义。如果在其他命名空间中定义，`ClusterFlow` 将不起作用。
|
||||
|
||||
:::
|
||||
|
||||
在旧版 Logging 中，如果要收集整个集群的日志，你只需要启用集群级别的 Logging 并定义所需的 `Output`。Rancher 2.5+ Logging 保留了这个基本方法。要复制旧版集群级别日志，请执行以下步骤：
|
||||
|
||||
1. 根据[输出配置](#输出配置)下的说明定义 `ClusterOutput`。
|
||||
2. 创建一个 `ClusterFlow`，确保它在 `cattle-logging-system` 命名空间中创建。
|
||||
1. 删除 `Flow` 定义的所有 _Include_ 和 _Exclude_ 规则。这将确保能收集所有日志。
|
||||
2. 如果不需要，你可以不配置任何过滤器（默认不需要创建）。
|
||||
3. 定义你的集群 `Output`。
|
||||
|
||||
操作完成后，集群中所有源（所有 pod 和所有系统组件）上收集的日志都会发送到定义在 `ClusterFlow` 中的 `Output` 处。
|
||||
|
||||
## 项目日志
|
||||
|
||||
Rancher 2.5+ Logging 不支持项目。换言之，如果要收集运行在项目命名空间中的 pod 日志，你需要为这些命名空间定义 `Flow`。
|
||||
|
||||
要收集指定命名空间的日志，请执行以下步骤：
|
||||
|
||||
1. 根据[输出配置](#输出配置)下的说明定义 `Output` 或 `ClusterOutput`。
|
||||
2. 创建一个 `Flow`，确保它在你要收集日志的命名空间中创建。
|
||||
1. 如果有需要，你可以定义 _Include_ 或 _Exclude_ 规则。如果删除所有规则，则会收集目标命名空间中的所有 pod 日志。
|
||||
2. 如果不需要，你可以不配置任何过滤器（默认不需要创建）。
|
||||
3. 定义你的 Output，可以是 `ClusterOutput` 或 `Output` 对象。
|
||||
|
||||
操作完成后，命名空间中所有源（pod）上收集的日志都会发送到你在 `Flow` 中定义的 `Output` 处。
|
||||
|
||||
:::note
|
||||
|
||||
要收集项目中的日志，请在项目中的每个命名空间中重复上述步骤。你也可以使用通用标签（例如 `project=my-project`）标记你的项目工作负载，并使用 `ClusterFlow` 收集匹配此标签的所有 pod 的日志。
|
||||
|
||||
:::
|
||||
|
||||
## 输出配置
|
||||
旧版 Logging 中有五个日志目标位置可供选择，分别是 Elasticsearch、Splunk、Kafka、Fluentd 和 Syslog。除 Syslog 外，这些目标位置都可用于 2.5+ Logging。
|
||||
|
||||
|
||||
### Elasticsearch
|
||||
|
||||
| 旧版 Logging | 2.5+ Logging | 注意 |
|
||||
|-----------------------------------------------|-----------------------------------|-----------------------------------------------------------|
|
||||
| 端点 | Target -> Host | 确保指定了协议 (https/http) 以及端口。 |
|
||||
| X-Pack Security -> Username | Access -> User | |
|
||||
| X-Pack Security -> Password | Access -> Password | 密码必须存储在密文中。 |
|
||||
| SSL Configuration -> Client Private Key | SSL -> Client Key | 密钥必须存储在密文中。 |
|
||||
| SSL Configuration -> Client Certificate | SSL -> Client Cert | 证书必须存储在密文中。 |
|
||||
| SSL Configuration -> Client Key Password | SSL -> Client Key Pass | 密码必须存储在密文中。 |
|
||||
| SSL Configuration -> Enabled SSL Verification | SSL -> Certificate Authority File | 证书必须存储在密文中。 |
|
||||
|
||||
|
||||
在旧版 Logging 中，索引是根据“索引模式”中的格式自动创建的。在 2.5 Logging 中，默认的操作已更改为记录单个索引。你仍然可以编辑 YAML 并输入以下值，从而在 `Output` 对象上配置索引模式功能：
|
||||
|
||||
```yaml
|
||||
...
|
||||
spec:
|
||||
elasticsearch:
|
||||
...
|
||||
logstash_format: true
|
||||
logstash_prefix: <desired prefix>
|
||||
logstash_dateformat: "%Y-%m-%d"
|
||||
```
|
||||
|
||||
将 `<desired prefix>` 替换为要创建的索引的前缀。在旧版 Logging 中，默认值是集群的名称。
|
||||
|
||||
### Splunk
|
||||
|
||||
| 旧版 Logging | 2.5+ Logging | 注意 |
|
||||
|------------------------------------------|----------------------------------------|----------------------------------------------------------------------------------------|
|
||||
| HEC Configuration -> Endpoint | Target -> Host | 协议（https/http）和端口必须与主机分开定义。 |
|
||||
| HEC Configuration -> Token | Access -> Token | 令牌必须作为密文存储。 |
|
||||
| HEC Configuration -> Index | Edit as YAML -> `index` | `index` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。 |
|
||||
| HEC Configuration -> Source | Edit as YAML -> `source` | `source` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。 |
|
||||
| SSL Configuration -> Client Private Key | Edit as YAML -> `client_key` | `client_key` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。详见（1）。 |
|
||||
| SSL Configuration -> Client Certificate | Edit as YAML -> `client_cert` | `client_cert` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。详见（1）。 |
|
||||
| SSL Configuration -> Client Key Password | _Not Supported_ | 现在不支持为客户端私钥指定密码。 |
|
||||
| SSL Configuration -> SSL Verify | Edit as YAML -> `ca_file` or `ca_path` | `ca_file` 或 `ca_path` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。详见（2）。 |
|
||||
|
||||
_(1) `client_key` 和 `client_cert` 的值必须分别是密钥和证书文件的路径。这些文件必须挂载到 `rancher-logging-fluentd` pod 中才能使用_。
|
||||
|
||||
_(2) 用户可以配置 `ca_file`（PEM 编码的 CA 证书的路径）或 `ca_path`（包含 PEM 格式的 CA 证书的目录路径）。这些文件必须挂载到 `rancher-logging-fluentd` pod 中才能使用_。
|
||||
|
||||
### Kafka
|
||||
|
||||
| 旧版 Logging | 2.5+ Logging | 注意 |
|
||||
|-----------------------------------------|----------------------------|------------------------------------------------------|
|
||||
| Kafka Configuration -> Endpoint Type | - | 不再支持将 Zookeeper 作为端点类型。 |
|
||||
| Kafka Configuration -> Endpoint | Target -> Brokers | 逗号分隔的 Broker 列表（host:port）。 |
|
||||
| Kafka Configuration -> Topic | Target -> Default Topic | |
|
||||
| SSL Configuration -> Client Private Key | SSL -> SSL Client Cert | 证书必须作为密文存储。 |
|
||||
| SSL Configuration -> Client Certificate | SSL -> SSL Client Cert Key | 密钥必须作为密文存储。 |
|
||||
| SSL Configuration -> CA Certificate PEM | SSL -> SSL CA Cert | 证书必须作为密文存储。 |
|
||||
| SASL Configuration -> Username | Access -> Username | 用户名必须存储在密文中。 |
|
||||
| SASL Configuration -> Password | Access -> Password | 密码必须存储在密文中。 |
|
||||
| SASL Configuration -> Scram Mechanism | Access -> Scram Mechanism | 输入机制为字符串，例如“sha256”或“sha512”。 |
|
||||
|
||||
### Fluentd
|
||||
|
||||
v2.5.2 开始只支持使用“以表单编辑”选项来添加单个 Fluentd 服务器。要添加多个服务器，请将 `Output` 编辑为 YAML 并输入多个服务器。
|
||||
|
||||
| 旧版 Logging | 2.5+ Logging | 注意 |
|
||||
|------------------------------------------|-----------------------------------------------------|----------------------------------------------------------------------|
|
||||
| Fluentd Configuration -> Endpoint | Target -> Host, Port | 分别输入主机和端口。 |
|
||||
| Fluentd Configuration -> Shared Key | Access -> Shared Key | 共享密钥必须存储为密文。 |
|
||||
| Fluentd Configuration -> Username | Access -> Username | 用户名必须存储为密文。 |
|
||||
| Fluentd Configuration -> Password | Access -> Password | 密码必须存储为密文。 |
|
||||
| Fluentd Configuration -> Hostname | Edit as YAML -> `host` | `host` 字段作为 YAML 键设置在 `spec.forward.servers[n]`下。 |
|
||||
| Fluentd Configuration -> Weight | Edit as YAML -> `weight` | `weight` 字段作为 YAML 键设置在 `spec.forward.servers[n]`下。 |
|
||||
| SSL Configuration -> Use TLS | - | 不需要显式启用。定义客户端证书字段即可。 |
|
||||
| SSL Configuration -> Client Private Key | Edit as YAML -> `tls_private_key_path` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
|
||||
| SSL Configuration -> Client Certificate | Edit as YAML -> `tls_client_cert_path` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
|
||||
| SSL Configuration -> Client Key Password | Edit as YAML -> `tls_client_private_key_passphrase` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
|
||||
| SSL Configuration -> SSL Verify | Edit as YAML -> `tls_insecure_mode` | `spec.forward` 下的字段设置为 YAML 键。默认：`false`。 |
|
||||
| SSL Configuration -> CA Certificate PEM | Edit as YAML -> `tls_cert_path` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
|
||||
| Enable Gzip Compression | - | 2.5+ Logging 不再支持。 |
|
||||
|
||||
_(1) 这些值将被指定为文件的路径。这些文件必须挂载到 `rancher-logging-fluentd` pod 中才能使用。_
|
||||
|
||||
### Syslog
|
||||
|
||||
从 v2.5.2 开始，使用 2.5+ Logging 的 `Output` 不支持 syslog。
|
||||
|
||||
## 自定义日志字段
|
||||
|
||||
要添加自定义日志字段，你需要将以下 YAML 添加到你的 `Flow` 配置中：
|
||||
|
||||
```yaml
|
||||
...
|
||||
spec:
|
||||
filters:
|
||||
- record_modifier:
|
||||
records:
|
||||
- foo: "bar"
|
||||
```
|
||||
|
||||
（将 `foo: "bar"` 替换为要添加的自定义日志字段）
|
||||
|
||||
## 系统日志
|
||||
|
||||
在旧版 Logging 中，你需要在设置集群 Logging 时选中“包括系统日志”来收集系统组件的日志。在 v2.5+ Logging 中，系统日志可以通过以下两种方式之一来收集：
|
||||
|
||||
1. 收集所有集群日志，不指定任何匹配或排除规则。该设置会收集集群所有容器的日志，其中包括系统日志。
|
||||
2. 通过为系统组件添加匹配规则来专门收集系统日志。要收集的组件决定了具体的匹配规则。
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
---
|
||||
shortTitle: RBAC
|
||||
title: Logging 的 RBAC
|
||||
weight: 3
|
||||
---
|
||||
|
||||
Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`。
|
||||
|
||||
- `logging-admin` 允许用户完全访问命名空间的 `Flow` 和 `Output`。
|
||||
- `logging-view` 允许用户*查看*命名空间的 `Flow` 和 `Output`，以及 `ClusterFlow` 和 `ClusterOutput`。
|
||||
|
||||
:::note 为什么选择一个角色而不是另一个角色？
|
||||
|
||||
`ClusterFlow` 和 `ClusterOutput` 资源的编辑权限非常强大。任何拥有该权限的用户都能编辑集群中的所有日志。
|
||||
|
||||
:::
|
||||
|
||||
在 Rancher 中，集群管理员角色是唯一可以完全访问所有 `rancher-logging` 资源的角色。集群成员无法编辑或读取任何 Logging 资源。项目所有者和成员具有以下权限：
|
||||
|
||||
| 项目所有者 | 项目成员 |
|
||||
--- | ---
|
||||
| 能够在其项目命名空间中创建命名空间级别的 `Flow` 和 `Output` | 只能查看项目命名空间中的 `Flow` 和 `Output` |
|
||||
| 可以从项目命名空间中收集任何日志 | 无法在其项目命名空间中收集任何日志 |
|
||||
|
||||
如果项目所有者和项目成员需要使用 Logging，他们需要在项目中至少有*一个*命名空间。如果没有，他们可能看不到顶部导航下拉列表中的 Logging 按钮。
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: 处理污点和容忍度
|
||||
weight: 6
|
||||
---
|
||||
|
||||
在 Kubernetes 节点上添加污点会导致 pod 排斥在该节点上运行。
|
||||
|
||||
除非 pod 对该节点的污点具有`容忍度`（toleration），否则 Pod 将在集群中的其他节点上运行。
|
||||
|
||||
[污点和容忍度](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)可以与 `PodSpec` 中的 `nodeSelector` [字段](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)一起使用，从而实现*相反的*污点效果。
|
||||
|
||||
`nodeSelector` 可以使 pod 被吸引到某类节点。
|
||||
|
||||
两者都能让 pod 选择在哪个节点上运行。
|
||||
|
||||
- [Rancher Logging 堆栈中的默认实现](#rancher-日志堆栈中的默认实现)
|
||||
- [为自定义污点添加 NodeSelector 设置和容忍度](#为自定义污点添加-nodeselector-设置和容忍度)
|
||||
|
||||
|
||||
### Rancher 日志堆栈中的默认实现
|
||||
|
||||
默认情况下，Rancher 使用 `cattle.io/os=linux` 来将污点应用到所有 Linux 节点，而不影响 Windows 节点。
|
||||
日志堆栈 pod 具有针对此污点的`容忍度`，因此它们能够运行在 Linux 节点上。
|
||||
此外，大多数日志堆栈 pod 仅在 Linux 上运行，并添加了 `nodeSelector` 以确保它们在 Linux 节点上运行。
|
||||
|
||||
此示例 Pod YAML 文件显示了与容忍度一起使用的 nodeSelector：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
# metadata...
|
||||
spec:
|
||||
# containers...
|
||||
tolerations:
|
||||
- key: cattle.io/os
|
||||
operator: "Equal"
|
||||
value: "linux"
|
||||
effect: NoSchedule
|
||||
nodeSelector:
|
||||
kubernetes.io/os: linux
|
||||
```
|
||||
|
||||
在上面的示例中，我们确保了的 pod 仅在 Linux 节点上运行，并且为所有 Linux 节点上的污点添加了`容忍度`。
|
||||
|
||||
你可以对 Rancher 现有的污点或你自己的自定义污点执行相同的操作。
|
||||
|
||||
### 为自定义污点添加 NodeSelector 设置和容忍度
|
||||
|
||||
如果要添加你自己的 `nodeSelector` 设置，或者要为其他污点添加 `容忍度`，你可以将以下内容传递给 Chart 的值：
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
# insert tolerations...
|
||||
nodeSelector:
|
||||
# insert nodeSelector...
|
||||
```
|
||||
|
||||
这些值会将这两个设置添加到 `fluentd`、`fluentbit`和 `logging-operator` 容器中。
|
||||
本质上，这些是日志堆栈中所有 pod 的全局设置。
|
||||
|
||||
但是，如果你想*仅*为 `fluentbit` 容器添加容忍度，你可以将以下内容添加到 Chart 的值中：
|
||||
|
||||
```yaml
|
||||
fluentbit_tolerations:
|
||||
# insert tolerations list for fluentbit containers only...
|
||||
```
|
||||
+71
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: Longhorn - Kubernetes 的云原生分布式块存储
|
||||
shortTitle: Longhorn 存储
|
||||
weight: 19
|
||||
---
|
||||
|
||||
[Longhorn](https://longhorn.io/) 是一个轻量级、可靠、易用的 Kubernetes 分布式块存储系统。
|
||||
|
||||
Longhorn 是免费的开源软件。Longhorn 最初由 Rancher Labs 开发，现在正在作为云原生计算基金会的沙盒项目进行开发。它可以通过 Helm、kubectl 或 Rancher UI 安装在任何 Kubernetes 集群上。有关其架构的更多信息，请参阅[此处](https://longhorn.io/docs/latest/concepts/)。
|
||||
|
||||
使用 Longhorn，你可以：
|
||||
|
||||
- 将 Longhorn 卷用作 Kubernetes 集群中分布式有状态应用程序的持久存储
|
||||
- 将你的块存储分区为 Longhorn 卷，以便在有或没有云提供商的情况下使用 Kubernetes 卷
|
||||
- 跨多个节点和数据中心复制块存储以提高可用性
|
||||
- 将备份数据存储在 NFS 或 AWS S3 等外部存储中
|
||||
- 创建跨集群灾难恢复卷，以便使用另一个 Kubernetes 集群中的备份快速恢复主 Kubernetes 集群中的数据
|
||||
- 计划卷的定期快照，并将定期备份调度到 NFS 或兼容 S3 的辅助存储
|
||||
- 使用备份来恢复卷
|
||||
- 在不中断持久卷的情况下升级 Longhorn
|
||||
|
||||
<figcaption>Longhorn 仪表板</figcaption>
|
||||
|
||||
|
||||
|
||||
### 使用 Rancher 安装 Longhorn
|
||||
|
||||
1. 满足所有[安装要求](https://longhorn.io/docs/latest/deploy/install/#installation-requirements)。
|
||||
1. 转到要安装 Longhorn 的集群。
|
||||
1. 单击**应用 & 应用市场**。
|
||||
1. 单击 **Chart**。
|
||||
1. 点击 **Longhorn**。
|
||||
1. 可选：要自定义初始设置，请单击 **Longhorn 默认设置**并编辑配置。如需自定义设置的帮助，请参阅 [Longhorn 文档](https://longhorn.io/docs/latest/references/settings/)。
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**：Longhorn 已部署到 Kubernetes 集群中。
|
||||
|
||||
### 从 Rancher UI 访问 Longhorn
|
||||
|
||||
1. 转到安装了 Longhorn 的集群。在左侧导航菜单中，单击 **Longhorn**。
|
||||
1. 在此页面上，你可以编辑 Longhorn 管理的 Kubernetes 资源。要查看 Longhorn UI，请单击**概述**中的 **Longhorn** 按钮。
|
||||
|
||||
**结果**：你将转到 Longhorn UI，你可以在那里管理 Longhorn 卷及其在 Kubernetes 集群中的副本，还可以查看位于另一个 Kubernetes 集群或 S3 中的 Longhorn 存储辅助备份。
|
||||
|
||||
### 从 Rancher UI 卸载 Longhorn
|
||||
|
||||
1. 转到安装了 Longhorn 的集群，然后单击**应用 & 应用市场**。
|
||||
1. 点击**已安装的应用**。
|
||||
1. 转到 `longhorn-system` 命名空间并选中 `longhorn` 和 `longhorn-crd` 应用程序旁边的框。
|
||||
1. 单击**删除**并确认**删除**。
|
||||
|
||||
**结果**：Longhorn 已被卸载。
|
||||
|
||||
### GitHub 仓库
|
||||
|
||||
Longhorn 项目在[此处](https://github.com/longhorn/longhorn)。
|
||||
|
||||
### 文档
|
||||
|
||||
Longhorn 文档在[此处](https://longhorn.io/docs/)。
|
||||
|
||||
### 架构
|
||||
|
||||
Longhorn 为每个卷创建专用的存储控制器，并在存储在多个节点上的多个副本之间同步复制该卷。
|
||||
|
||||
存储控制器和副本本身是使用 Kubernetes 编排的。
|
||||
|
||||
有关其架构的更多信息，请参阅[此处](https://longhorn.io/docs/latest/concepts/)。
|
||||
|
||||
<figcaption>Longhorn 架构</figcaption>
|
||||
|
||||
+112
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: 内置仪表板
|
||||
weight: 3
|
||||
---
|
||||
|
||||
|
||||
## Grafana UI
|
||||
|
||||
你可以使用 [Grafana](https://grafana.com/grafana/) 对存储在各个地方的指标进行查询、可视化、告警和了解。你能与你的团队创建、探索和共享仪表板，并培养数据驱动的文化。
|
||||
|
||||
要查看时间序列数据可视化的默认仪表板，请转到 Grafana UI。
|
||||
|
||||
### 自定义 Grafana
|
||||
|
||||
要查看和自定义用于支持 Grafana 仪表板的 PromQL 查询，请参阅[此页面](../../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/customize-grafana-dashboard.md)。
|
||||
|
||||
### 持久化 Grafana 仪表板
|
||||
|
||||
要创建持久化 Grafana 仪表板，请参阅[此页面](../../../how-to-guides/advanced-user-guides/monitoring-alerting-guides/create-persistent-grafana-dashboard.md)。
|
||||
|
||||
### 访问 Grafana
|
||||
|
||||
有关 Grafana 的 RBAC，请参阅[本节](rbac-for-monitoring.md#grafana-的-rbac)。
|
||||
|
||||
|
||||
## Alertmanager UI
|
||||
|
||||
安装 `rancher-monitoring` 后，会部署 Prometheus Alertmanager UI，从而让你查看告警以及当前的 Alertmanager 配置。
|
||||
|
||||
:::note
|
||||
|
||||
本节参考假设你已经熟悉 Monitoring 组件的协同工作方式。有关 Alertmanager 的详细信息，请参阅[本节](how-monitoring-works.md#alertmanager-工作原理)。
|
||||
|
||||
:::
|
||||
|
||||
### 访问 Alertmanager UI
|
||||
|
||||
Alertmanager UI 可让你查看最近触发的告警。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
必须安装 `rancher-monitoring` 应用。
|
||||
|
||||
:::
|
||||
|
||||
要查看 Alertmanager UI：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要查看 Alertmanager UI 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**监控**。
|
||||
1. 单击 **Alertmanager**。
|
||||
|
||||
**结果**：在新选项卡中打开 Alertmanager UI。如需配置帮助，请参阅[官方 Alertmanager 文档](https://prometheus.io/docs/alerting/latest/alertmanager/)。
|
||||
|
||||
有关在 Rancher 中配置 Alertmanager 的更多信息，请参阅[此页面](../../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md)。
|
||||
|
||||
<figcaption>Alertmanager UI</figcaption>
|
||||
|
||||
|
||||
|
||||
### 查看默认告警
|
||||
|
||||
要查看默认触发的告警，请转到 Alertmanager UI 并单击**展开所有组**。
|
||||
|
||||
|
||||
## 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)。
|
||||
+250
@@ -0,0 +1,250 @@
|
||||
---
|
||||
title: Monitoring 的工作原理
|
||||
weight: 1
|
||||
---
|
||||
|
||||
|
||||
## 1. 架构概述
|
||||
|
||||
_**下文描述了数据如何流经 Monitoring V2 应用程序：**_
|
||||
|
||||
### Prometheus Operator
|
||||
|
||||
Prometheus Operator 观察正在创建的 ServiceMonitors、PodMonitors 和 PrometheusRules。在创建 Prometheus 配置资源时，Prometheus Operator 会调用 Prometheus API 来同步新配置。如本节末尾的图所示，Prometheus Operator 充当 Prometheus 和 Kubernetes 之间的中介，调用 Prometheus API 来同步 Prometheus 与 Kubernetes 中的监控相关资源。
|
||||
|
||||
### ServiceMonitor 和 PodMonitor
|
||||
|
||||
ServiceMonitor 和 PodMonitor 以声明方式指定需要监控的目标，例如 Service 和 Pod。
|
||||
|
||||
- 目标是根据配置的 Prometheus 抓取间隔定期抓取的，而抓取的指标存储在 Prometheus 时间序列数据库（Time Series Database，TSDB）中。
|
||||
|
||||
- 为了执行抓取，你需要使用标签选择器来定义 ServiceMonitor 和 PodMonitor，这些标签选择器用于确定要抓取的 Service 或 Pod，并能确定端点（端点能确定抓取如何在给定目标上进行，例如在 TCP 10252 中抓取指标，通过 IP 地址 x.x.x.x 进行代理）。
|
||||
|
||||
- 开箱即用地，Monitoring V2 附带了一些预配置的 Exporter，这些 Exporter 根据其所在的 Kubernetes 集群的类型进行部署。有关详细信息，请参阅[抓取和公开指标](#5-抓取和公开指标)。
|
||||
|
||||
### PushProx 的工作原理
|
||||
|
||||
- 某些内部 Kubernetes 组件是通过部署在 Monitoring V2 中名为 **PushProx** 的代理来抓取的。通过 PushProx 向 Prometheus 公开指标的 Kubernetes 组件分别是 `kube-controller-manager`、`kube-scheduler`, `etcd` 和 `kube-proxy`。
|
||||
|
||||
- 对于每个 PushProx Exporter，我们在所有目标节点上都部署一个 PushProx 客户端。例如，将 PushProx 客户端部署到 kube-controller-manager 的所有 controlplane 节点、kube-etcd 的所有 etcd 节点上，和 kubelet 的所有节点上。
|
||||
|
||||
- 我们为每个 Exporter 部署了一个 PushProx 代理。导出指标的流程如下：
|
||||
|
||||
1. PushProx 客户端与 PushProx 代理建立出站连接。
|
||||
1. 然后，客户端会轮询代理以获取进入代理的抓取请求。
|
||||
1. 当代理收到来自 Prometheus 的抓取请求时，客户端会将其视为轮询的结果。
|
||||
1. 客户端抓取内部组件。
|
||||
1. 内部组件通过将指标推回代理来响应。
|
||||
|
||||
|
||||
<figcaption><br/>使用 PushProx 导出指标的过程：<br/></figcaption>
|
||||
|
||||
|
||||
|
||||
### 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 组件。
|
||||
+366
@@ -0,0 +1,366 @@
|
||||
---
|
||||
title: PromQL 表达式参考
|
||||
weight: 6
|
||||
---
|
||||
|
||||
本文档中的 PromQL 表达式可用于配置告警。
|
||||
|
||||
关于查询 Prometheus 时间序列数据库的更多信息，请参阅 [Prometheus 官方文档](https://prometheus.io/docs/prometheus/latest/querying/basics/)。
|
||||
|
||||
|
||||
## 集群指标
|
||||
|
||||
### 集群 CPU 利用率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `1 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance))` |
|
||||
| 摘要 | `1 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])))` |
|
||||
|
||||
### 集群平均负载
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>load1</td><td>`sum(node_load1) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`</td></tr><tr><td>load5</td><td>`sum(node_load5) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`</td></tr><tr><td>load15</td><td>`sum(node_load15) by (instance) / count(node_cpu_seconds_total{mode="system"}) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>load1</td><td>`sum(node_load1) by (instance) / count(node_cpu_seconds_total{mode="system"})`</td></tr><tr><td>load5</td><td>`sum(node_load5) by (instance) / count(node_cpu_seconds_total{mode="system"})`</td></tr><tr><td>load15</td><td>`sum(node_load15) by (instance) / count(node_cpu_seconds_total{mode="system"})`</td></tr></table> |
|
||||
|
||||
### 集群内存利用率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `1 - sum(node_memory_MemAvailable_bytes) by (instance) / sum(node_memory_MemTotal_bytes) by (instance)` |
|
||||
| 摘要 | `1 - sum(node_memory_MemAvailable_bytes) / sum(node_memory_MemTotal_bytes)` |
|
||||
|
||||
### 集群磁盘利用率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `(sum(node_filesystem_size_bytes{device!="rootfs"}) by (instance) - sum(node_filesystem_free_bytes{device!="rootfs"}) by (instance)) / sum(node_filesystem_size_bytes{device!="rootfs"}) by (instance)` |
|
||||
| 摘要 | `(sum(node_filesystem_size_bytes{device!="rootfs"}) - sum(node_filesystem_free_bytes{device!="rootfs"})) / sum(node_filesystem_size_bytes{device!="rootfs"})` |
|
||||
|
||||
### 集群磁盘 I/O
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total[5m])) by (instance)`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total[5m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total[5m]))`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total[5m]))`</td></tr></table> |
|
||||
|
||||
### 集群网络数据包
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo | 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
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <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 利用率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `avg(irate(node_cpu_seconds_total{mode!="idle", instance=~"$instance"}[5m])) by (mode)` |
|
||||
| 摘要 | `1 - (avg(irate(node_cpu_seconds_total{mode="idle", instance=~"$instance"}[5m])))` |
|
||||
|
||||
### 节点平均负载
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>load1</td><td>`sum(node_load1{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load5</td><td>`sum(node_load5{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load15</td><td>`sum(node_load15{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>load1</td><td>`sum(node_load1{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load5</td><td>`sum(node_load5{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr><tr><td>load15</td><td>`sum(node_load15{instance=~"$instance"}) / count(node_cpu_seconds_total{mode="system",instance=~"$instance"})`</td></tr></table> |
|
||||
|
||||
### 节点内存利用率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `1 - sum(node_memory_MemAvailable_bytes{instance=~"$instance"}) / sum(node_memory_MemTotal_bytes{instance=~"$instance"})` |
|
||||
| 摘要 | `1 - sum(node_memory_MemAvailable_bytes{instance=~"$instance"}) / sum(node_memory_MemTotal_bytes{instance=~"$instance"}) ` |
|
||||
|
||||
### 节点磁盘利用率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `(sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"}) by (device) - sum(node_filesystem_free_bytes{device!="rootfs",instance=~"$instance"}) by (device)) / sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"}) by (device)` |
|
||||
| 摘要 | `(sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"}) - sum(node_filesystem_free_bytes{device!="rootfs",instance=~"$instance"})) / sum(node_filesystem_size_bytes{device!="rootfs",instance=~"$instance"})` |
|
||||
|
||||
### 节点磁盘 I/O
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total{instance=~"$instance"}[5m]))`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total{instance=~"$instance"}[5m]))`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>read</td><td>`sum(rate(node_disk_read_bytes_total{instance=~"$instance"}[5m]))`</td></tr><tr><td>written</td><td>`sum(rate(node_disk_written_bytes_total{instance=~"$instance"}[5m]))`</td></tr></table> |
|
||||
|
||||
### 节点网络数据包
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo | 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
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <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 客户端流量
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>in</td><td>`sum(rate(etcd_network_client_grpc_received_bytes_total[5m])) by (instance)`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_client_grpc_sent_bytes_total[5m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>in</td><td>`sum(rate(etcd_network_client_grpc_received_bytes_total[5m]))`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_client_grpc_sent_bytes_total[5m]))`</td></tr></table> |
|
||||
|
||||
### 对等流量
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>in</td><td>`sum(rate(etcd_network_peer_received_bytes_total[5m])) by (instance)`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_peer_sent_bytes_total[5m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>in</td><td>`sum(rate(etcd_network_peer_received_bytes_total[5m]))`</td></tr><tr><td>out</td><td>`sum(rate(etcd_network_peer_sent_bytes_total[5m]))`</td></tr></table> |
|
||||
|
||||
### 数据库大小
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(etcd_debugging_mvcc_db_total_size_in_bytes) by (instance)` |
|
||||
| 摘要 | `sum(etcd_debugging_mvcc_db_total_size_in_bytes)` |
|
||||
|
||||
### 活动流
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>lease-watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) by (instance) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) by (instance)`</td></tr><tr><td>watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) by (instance) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>lease-watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"})`</td></tr><tr><td>watch</td><td>`sum(grpc_server_started_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) - sum(grpc_server_handled_total{grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"})`</td></tr></table> |
|
||||
|
||||
### Raft 方案
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>applied</td><td>`sum(increase(etcd_server_proposals_applied_total[5m])) by (instance)`</td></tr><tr><td>committed</td><td>`sum(increase(etcd_server_proposals_committed_total[5m])) by (instance)`</td></tr><tr><td>pending</td><td>`sum(increase(etcd_server_proposals_pending[5m])) by (instance)`</td></tr><tr><td>failed</td><td>`sum(increase(etcd_server_proposals_failed_total[5m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>applied</td><td>`sum(increase(etcd_server_proposals_applied_total[5m]))`</td></tr><tr><td>committed</td><td>`sum(increase(etcd_server_proposals_committed_total[5m]))`</td></tr><tr><td>pending</td><td>`sum(increase(etcd_server_proposals_pending[5m]))`</td></tr><tr><td>failed</td><td>`sum(increase(etcd_server_proposals_failed_total[5m]))`</td></tr></table> |
|
||||
|
||||
### RPC 速率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>total</td><td>`sum(rate(grpc_server_started_total{grpc_type="unary"}[5m])) by (instance)`</td></tr><tr><td>fail</td><td>`sum(rate(grpc_server_handled_total{grpc_type="unary",grpc_code!="OK"}[5m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>total</td><td>`sum(rate(grpc_server_started_total{grpc_type="unary"}[5m]))`</td></tr><tr><td>fail</td><td>`sum(rate(grpc_server_handled_total{grpc_type="unary",grpc_code!="OK"}[5m]))`</td></tr></table> |
|
||||
|
||||
### 磁盘操作
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>commit-called-by-backend</td><td>`sum(rate(etcd_disk_backend_commit_duration_seconds_sum[1m])) by (instance)`</td></tr><tr><td>fsync-called-by-wal</td><td>`sum(rate(etcd_disk_wal_fsync_duration_seconds_sum[1m])) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>commit-called-by-backend</td><td>`sum(rate(etcd_disk_backend_commit_duration_seconds_sum[1m]))`</td></tr><tr><td>fsync-called-by-wal</td><td>`sum(rate(etcd_disk_wal_fsync_duration_seconds_sum[1m]))`</td></tr></table> |
|
||||
|
||||
### 磁盘同步持续时间
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>wal</td><td>`histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le))`</td></tr><tr><td>db</td><td>`histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le))`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>wal</td><td>`sum(histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le)))`</td></tr><tr><td>db</td><td>`sum(histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le)))`</td></tr></table> |
|
||||
|
||||
## Kubernetes 组件指标
|
||||
|
||||
### API Server 请求延迟
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `avg(apiserver_request_latencies_sum / apiserver_request_latencies_count) by (instance, verb) /1e+06` |
|
||||
| 摘要 | `avg(apiserver_request_latencies_sum / apiserver_request_latencies_count) by (instance) /1e+06` |
|
||||
|
||||
### API Server 请求速率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(apiserver_request_count[5m])) by (instance, code)` |
|
||||
| 摘要 | `sum(rate(apiserver_request_count[5m])) by (instance)` |
|
||||
|
||||
### 调度失败的 Pod
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(kube_pod_status_scheduled{condition="false"})` |
|
||||
| 摘要 | `sum(kube_pod_status_scheduled{condition="false"})` |
|
||||
|
||||
### Controller Manager 队列深度
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>volumes</td><td>`sum(volumes_depth) by instance`</td></tr><tr><td>deployment</td><td>`sum(deployment_depth) by instance`</td></tr><tr><td>replicaset</td><td>`sum(replicaset_depth) by instance`</td></tr><tr><td>service</td><td>`sum(service_depth) by instance`</td></tr><tr><td>serviceaccount</td><td>`sum(serviceaccount_depth) by instance`</td></tr><tr><td>endpoint</td><td>`sum(endpoint_depth) by instance`</td></tr><tr><td>daemonset</td><td>`sum(daemonset_depth) by instance`</td></tr><tr><td>statefulset</td><td>`sum(statefulset_depth) by instance`</td></tr><tr><td>replicationmanager</td><td>`sum(replicationmanager_depth) by instance`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>volumes</td><td>`sum(volumes_depth)`</td></tr><tr><td>deployment</td><td>`sum(deployment_depth)`</td></tr><tr><td>replicaset</td><td>`sum(replicaset_depth)`</td></tr><tr><td>service</td><td>`sum(service_depth)`</td></tr><tr><td>serviceaccount</td><td>`sum(serviceaccount_depth)`</td></tr><tr><td>endpoint</td><td>`sum(endpoint_depth)`</td></tr><tr><td>daemonset</td><td>`sum(daemonset_depth)`</td></tr><tr><td>statefulset</td><td>`sum(statefulset_depth)`</td></tr><tr><td>replicationmanager</td><td>`sum(replicationmanager_depth)`</td></tr></table> |
|
||||
|
||||
### 调度器 E2E 调度延迟
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `histogram_quantile(0.99, sum(scheduler_e2e_scheduling_latency_microseconds_bucket) by (le, instance)) / 1e+06` |
|
||||
| 摘要 | `sum(histogram_quantile(0.99, sum(scheduler_e2e_scheduling_latency_microseconds_bucket) by (le, instance)) / 1e+06)` |
|
||||
|
||||
### 调度器抢占尝试
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(scheduler_total_preemption_attempts[5m])) by (instance)` |
|
||||
| 摘要 | `sum(rate(scheduler_total_preemption_attempts[5m]))` |
|
||||
|
||||
### Ingress Controller 连接数
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>reading</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="reading"}) by (instance)`</td></tr><tr><td>waiting</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"}) by (instance)`</td></tr><tr><td>writing</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="writing"}) by (instance)`</td></tr><tr><td>accepted</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m]))) by (instance)`</td></tr><tr><td>active</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m]))) by (instance)`</td></tr><tr><td>handled</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m]))) by (instance)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>reading</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="reading"})`</td></tr><tr><td>waiting</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"})`</td></tr><tr><td>writing</td><td>`sum(nginx_ingress_controller_nginx_process_connections{state="writing"})`</td></tr><tr><td>accepted</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m])))`</td></tr><tr><td>active</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m])))`</td></tr><tr><td>handled</td><td>`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m])))`</td></tr></table> |
|
||||
|
||||
### Ingress Controller 请求处理时间
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `topk(10, histogram_quantile(0.95,sum by (le, host, path)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` |
|
||||
| 摘要 | `topk(10, histogram_quantile(0.95,sum by (le, host)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` |
|
||||
|
||||
## Rancher Logging 指标
|
||||
|
||||
|
||||
### Fluentd 缓冲区队列速率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(fluentd_output_status_buffer_queue_length[5m])) by (instance)` |
|
||||
| 摘要 | `sum(rate(fluentd_output_status_buffer_queue_length[5m]))` |
|
||||
|
||||
### Fluentd 输入速率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(fluentd_input_status_num_records_total[5m])) by (instance)` |
|
||||
| 摘要 | `sum(rate(fluentd_input_status_num_records_total[5m]))` |
|
||||
|
||||
### Fluentd 输出错误率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(fluentd_output_status_num_errors[5m])) by (type)` |
|
||||
| 摘要 | `sum(rate(fluentd_output_status_num_errors[5m]))` |
|
||||
|
||||
### Fluentd 输出速率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(rate(fluentd_output_status_num_records_total[5m])) by (instance)` |
|
||||
| 摘要 | `sum(rate(fluentd_output_status_num_records_total[5m]))` |
|
||||
|
||||
## 工作负载指标
|
||||
|
||||
### 工作负载 CPU 利用率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### 工作负载内存利用率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(container_memory_working_set_bytes{namespace="$namespace",pod_name=~"$podName", container_name!=""}) by (pod_name)` |
|
||||
| 摘要 | `sum(container_memory_working_set_bytes{namespace="$namespace",pod_name=~"$podName", container_name!=""})` |
|
||||
|
||||
### 工作负载网络数据包
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### 工作负载网络 I/O
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### 工作负载磁盘 I/O
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
## Pod 指标
|
||||
|
||||
### Pod CPU 利用率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m])) by (container_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>cfs throttled seconds</td><td>`sum(rate(container_cpu_cfs_throttled_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr><tr><td>usage seconds</td><td>`sum(rate(container_cpu_usage_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr><tr><td>system seconds</td><td>`sum(rate(container_cpu_system_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr><tr><td>user seconds</td><td>`sum(rate(container_cpu_user_seconds_total{container_name!="POD",namespace="$namespace",pod_name="$podName", container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### Pod 内存利用率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | `sum(container_memory_working_set_bytes{container_name!="POD",namespace="$namespace",pod_name="$podName",container_name!=""}) by (container_name)` |
|
||||
| 摘要 | `sum(container_memory_working_set_bytes{container_name!="POD",namespace="$namespace",pod_name="$podName",container_name!=""})` |
|
||||
|
||||
### Pod 网络数据包
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive-packets</td><td>`sum(rate(container_network_receive_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-dropped</td><td>`sum(rate(container_network_receive_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>receive-errors</td><td>`sum(rate(container_network_receive_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-packets</td><td>`sum(rate(container_network_transmit_packets_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-dropped</td><td>`sum(rate(container_network_transmit_packets_dropped_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit-errors</td><td>`sum(rate(container_network_transmit_errors_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### Pod 网络 I/O
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>receive</td><td>`sum(rate(container_network_receive_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>transmit</td><td>`sum(rate(container_network_transmit_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
### Pod 磁盘 I/O
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| 详情 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`</td></tr></table> |
|
||||
| 摘要 | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |
|
||||
|
||||
## 容器指标
|
||||
|
||||
### 容器 CPU 利用率
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| cfs throttled seconds | `sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
| usage seconds | `sum(rate(container_cpu_usage_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
| system seconds | `sum(rate(container_cpu_system_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
| user seconds | `sum(rate(container_cpu_user_seconds_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
|
||||
### 容器内存利用率
|
||||
|
||||
`sum(container_memory_working_set_bytes{namespace="$namespace",pod_name="$podName",container_name="$containerName"})`
|
||||
|
||||
### 容器磁盘 I/O
|
||||
|
||||
| 目录 | 表达式 |
|
||||
| --- | --- |
|
||||
| read | `sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
| write | `sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name="$containerName"}[5m]))` |
|
||||
+171
@@ -0,0 +1,171 @@
|
||||
---
|
||||
title: RBAC
|
||||
shortTitle: RBAC
|
||||
weight: 2
|
||||
---
|
||||
本节描述了 RBAC 在 Rancher Monitoring 中的作用。
|
||||
|
||||
|
||||
## 集群管理员
|
||||
|
||||
默认情况下，只有具有 cluster-admin `ClusterRole` 的用户才能：
|
||||
|
||||
- 将 `rancher-monitoring` 应用安装到集群上，并在 Chart 部署上执行所有其他相关配置。
|
||||
- 例如，是否创建了默认仪表板，要将哪些 Exporter 部署到集群上以收集指标等。
|
||||
- 通过 Prometheus CR 在集群中创建/修改/删除 Prometheus deployment。
|
||||
- 通过 Alertmanager CR 在集群中创建/修改/删除 Alertmanager deployment。
|
||||
- 通过在命名空间中创建 ConfigMap 来保留新的 Grafana 仪表板或数据源。
|
||||
- 通过 `cattle-monitoring-system` 命名空间中的 Secret 将某些 Prometheus 指标暴露给 HPA 的 K8s Custom Metrics API。
|
||||
|
||||
## 具有基于 Kubernetes ClusterRole 权限的用户
|
||||
|
||||
`rancher-monitoring` Chart 安装了以下三个 `ClusterRole`。默认情况下，它们会聚合到相应的 K8s `ClusterRole` 中：
|
||||
|
||||
| ClusterRole | 聚合到默认的 K8s ClusterRole |
|
||||
| ------------------------------| ---------------------------|
|
||||
| `monitoring-admin` | `admin` |
|
||||
| `monitoring-edit` | `edit` |
|
||||
| `monitoring-view` | `view ` |
|
||||
|
||||
这些 `ClusterRole` 根据可执行的操作提供对 Monitoring CRD 的不同访问级别：
|
||||
|
||||
| CRD (monitoring.coreos.com) | Admin | Edit | View |
|
||||
| ------------------------------| ---------------------------| ---------------------------| ---------------------------|
|
||||
| <ul><li>`prometheuses`</li><li>`alertmanagers`</li></ul> | Get, List, Watch | Get, List, Watch | Get, List, Watch |
|
||||
| <ul><li>`servicemonitors`</li><li>`podmonitors`</li><li>`prometheusrules`</li></ul> | * | * | Get, List, Watch |
|
||||
|
||||
在较高级别上，默认情况下会分配以下权限。
|
||||
|
||||
### 具有 Kubernetes 管理员/编辑权限的用户
|
||||
|
||||
只有具有 cluster-admin、admin 或 edit 的 `ClusterRole` 可以：
|
||||
|
||||
- 通过 ServiceMonitor 和 PodMonitor CR 修改 Prometheus deployment 的抓取配置。
|
||||
- 通过 PrometheusRules CR 修改 Prometheus deployment 的告警/记录规则。
|
||||
|
||||
### 具有 Kubernetes 查看权限的用户
|
||||
|
||||
只有具有 Kubernetes `ClusterRole` 的用户可以：
|
||||
|
||||
- 查看集群内部署的 Prometheuses 的配置。
|
||||
- 查看集群内部署的 Alertmanagers 的配置。
|
||||
- 通过 ServiceMonitor 和 PodMonitor CR 查看 Prometheus deployment 的抓取配置。
|
||||
- 通过 PrometheusRules CR 查看 Prometheus deployment 的告警/记录规则。
|
||||
|
||||
### 其他监控角色
|
||||
|
||||
Monitoring 还会创建其他 `Role`，这些角色默认情况下不会分配给用户，而是在集群中创建。你可以部署引用角色的 `RoleBinding` 来将角色绑定到命名空间。要使用 `kubectl` 而不是通过 Rancher 来定义 `RoleBinding`，请单击[此处](#使用-kubectl-分配-role-和-clusterrole)。
|
||||
|
||||
管理员应使用这些角色为用户提供更细粒度的访问权限：
|
||||
|
||||
| 角色 | 用途 |
|
||||
| ------------------------------| ---------------------------|
|
||||
| monitoring-config-admin | 允许管理员为用户分配角色，以便查看/编辑 cattle-monitoring-system 命名空间中的 Secret 和 ConfigMap。修改此命名空间中的 Secret/ConfigMap 可以允许用户更改集群的 Alertmanager 配置、Prometheus Adapter 配置、其他 Grafana 数据源、TLS 密钥等。 |
|
||||
| monitoring-config-edit | 允许管理员为用户分配角色，以便查看/编辑 cattle-monitoring-system 命名空间中的 Secret 和 ConfigMap。修改此命名空间中的 Secret/ConfigMap 可以允许用户更改集群的 Alertmanager 配置、Prometheus Adapter 配置、其他 Grafana 数据源、TLS 密钥等。 |
|
||||
| monitoring-config-view | 允许管理员为用户分配角色，以便查看 cattle-monitoring-system 命名空间中的 Secret 和 ConfigMap。查看此命名空间中的 Secret/ConfigMap 可以允许用户观察集群的 Alertmanager 配置、Prometheus Adapter 配置、其他 Grafana 数据源、TLS 密钥等。 |
|
||||
| monitoring-dashboard-admin | 允许管理员为用户分配角色，以便查看/编辑 cattle-dashboards 命名空间中的 ConfigMap。此命名空间中的 ConfigMap 将对应于持久化到集群上的 Grafana 仪表板。 |
|
||||
| monitoring-dashboard-edit | 允许管理员为用户分配角色，以便查看/编辑 cattle-dashboards 命名空间中的 ConfigMap。此命名空间中的 ConfigMap 将对应于持久化到集群上的 Grafana 仪表板。 |
|
||||
| monitoring-dashboard-view | 允许管理员为用户分配角色，以便查看 cattle-dashboards 命名空间中的 ConfigMap。此命名空间中的 ConfigMap 将对应于持久化到集群上的 Grafana 仪表板。 |
|
||||
|
||||
### 其他监控集群角色
|
||||
|
||||
Monitoring 还会创建其他 `ClusterRole`，这些角色默认情况下不会分配给用户，而是在集群中创建。默认情况下，这些角色不会聚合，但你可以部署引用角色的 `RoleBinding` 或 `ClusterRoleBinding` 来将角色绑定到命名空间。要使用 `kubectl` 而不是通过 Rancher 来定义 `RoleBinding`，请单击[此处](#使用-kubectl-分配-role-和-clusterrole)。
|
||||
|
||||
| 角色 | 用途 |
|
||||
| ------------------------------| ---------------------------|
|
||||
| monitoring-ui-view | <a id="monitoring-ui-view"></a>_从 Monitoring v2 14.5.100+ 开始可用_。通过授权用户列出 Prometheus、Alertmanager 和 Grafana 端点，并通过 Rancher 代理向 Prometheus、Grafana 和 Alertmanager UI 进行 GET 请求，来允许用户对外部 Monitoring UI 进行只读访问。 |
|
||||
|
||||
### 使用 kubectl 分配 Role 和 ClusterRole
|
||||
|
||||
使用 Rancher 将 `Role` 或 `ClusterRole` 附加到用户或组的另一种方法，是在你创建的 YAML 文件中定义绑定。你必须首先使用 YAML 文件配置 `RoleBinding`，然后运行 `kubectl apply` 命令来应用配置更改。
|
||||
|
||||
|
||||
* **Role**：以下 YAML 文件示例可帮助你在 Kubernetes 中配置 `RoleBinding`。你需要填写下方的 `name`（区分大小写）：
|
||||
|
||||
```yaml
|
||||
# monitoring-config-view-role-binding.yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: monitoring-config-view
|
||||
namespace: cattle-monitoring-system
|
||||
roleRef:
|
||||
kind: Role
|
||||
name: monitoring-config-view
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
subjects:
|
||||
- kind: User
|
||||
name: u-b4qkhsnliz # this can be found via `kubectl get users -A`
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
|
||||
* **kubectl**：以下 `kubectl` 示例命令用于应用 YAML 文件中创建的绑定。如前所述，你需要相应地填写你的 YAML 文件名。
|
||||
|
||||
* `kubectl apply -f monitoring-config-view-role-binding.yaml`
|
||||
|
||||
|
||||
## 具有 Rancher 权限的用户
|
||||
|
||||
Rancher 部署的默认角色（即 cluster-owner、cluster-member、project-owner、project-member）、Kubernetes 默认角色，以及 rancher-monitoring Chart 部署的角色之间的关系如下：
|
||||
|
||||
<figcaption>默认 Rancher 权限和对应的 Kubernetes ClusterRole</figcaption>
|
||||
|
||||
| Rancher 角色 | Kubernetes 角色 | Monitoring ClusterRole/Role | ClusterRoleBinding/RoleBinding |
|
||||
| --------- | --------- | --------- | --------- |
|
||||
| cluster-owner | cluster-admin | N/A | ClusterRoleBinding |
|
||||
| cluster-member | admin | monitoring-admin | ClusterRoleBinding |
|
||||
| project-owner | admin | monitoring-admin | 项目命名空间中的 RoleBinding |
|
||||
| project-member | edit | monitoring-edit | 项目命名空间中的 RoleBinding |
|
||||
|
||||
除这些默认角色之外，你还可以将以下的其他 Rancher 项目角色应用于集群成员，以提供对 Monitoring 的其他访问。这些 Rancher 角色将与 Monitoring Chart 部署的 ClusterRole 相关联：
|
||||
|
||||
<figcaption>非默认的 Rancher 权限和对应的 Kubernetes ClusterRole</figcaption>
|
||||
|
||||
| Rancher 角色 | Kubernetes ClusterRole | 可用 Rancher 版本 | 可用 Monitoring V2 版本 |
|
||||
|--------------------------|-------------------------------|-------|------|
|
||||
| 查看 Monitoring\* | [monitoring-ui-view](#monitoring-ui-view) | 2.4.8+ | 9.4.204+ |
|
||||
|
||||
\* 如果某个用户绑定了 Rancher 的 **View Monitoring** 角色，该用户只有在有 UI 链接时才有权访问外部 Monitoring UI。要访问 Monitoring Pane 以获取这些链接，用户必须是至少一个项目的项目成员。
|
||||
|
||||
### 2.5.x 中的差异
|
||||
|
||||
在 Rancher 2.5.x 中，分配了 project-member 或 project-owner 角色的用户将无法访问 Prometheus 或 Grafana，因为我们仅在集群级别创建 Grafana 或 Prometheus。
|
||||
|
||||
此外，虽然 project-owner 仍然只能添加默认在项目命名空间内抓取资源的 ServiceMonitor/PodMonitor，但 PrometheusRule 并不局限于单个命名空间/项目。因此，即使 project-owner 无法查看/编辑/删除在项目命名空间之外创建的任何规则，project-owner 在其项目命名空间内创建的任何告警规则或记录规则都将应用于整个集群。
|
||||
|
||||
### 分配其他访问权限
|
||||
|
||||
如果 cluster-admin 想要为不具有 rancher-monitoring chart 角色的用户提供 admin/edit 访问权限，则存在下表的潜在影响：
|
||||
|
||||
| CRD (monitoring.coreos.com) | 是否会在命名空间/项目之外造成影响 | 影响 |
|
||||
|----------------------------| ------| ----------------------------|
|
||||
| `prometheuses` | 是。该资源可以从整个集群中的任何目标中抓取指标（除非 Operator 本身进行了额外的配置）。 | 用户将能够定义应在集群中创建的新集群级 Prometheus deployment 的配置。 |
|
||||
| `alertmanagers` | 否 | 用户将能够定义应在集群中创建的新集群级 Alertmanager deployment 的配置。注意：如果你只想允许用户配置路由和接收器等设置，你应该只提供对 Alertmanager Config Secret 的访问权限。 |
|
||||
| <ul><li>`servicemonitors`</li><li>`podmonitors`</li></ul> | 否（默认）。可以通过 Prometheus CR 上的 `ignoreNamespaceSelectors` 进行配置。 | 用户将能够通过 Prometheus，在他们被授予此权限的命名空间内的 Service/Pod 暴露的端点上设置抓取。 |
|
||||
| `prometheusrules` | 是。PrometheusRules 是集群范围的。 | 用户将能够根据在整个集群中收集的任何系列，在 Prometheus 上定义告警或记录规则。 |
|
||||
|
||||
| K8s 资源 | 命名空间 | 是否会在命名空间/项目之外造成影响 | 影响 |
|
||||
|----------------------------| ------| ------| ----------------------------|
|
||||
| <ul><li>`secrets`</li><li>`configmaps`</li></ul> | `cattle-monitoring-system` | 是。此命名空间中的 Config 和 Secret 会影响整个监控/告警流水线。 | 用户将能够创建或编辑 Secret/ ConfigMap，例如 Alertmanager Config、Prometheus Adapter 配置、TLS 密文、其他 Grafana 数据源等。这会对所有集群监控/告警产生广泛影响。 |
|
||||
| <ul><li>`secrets`</li><li>`configmaps`</li></ul> | `cattle-dashboards` | 是。此命名空间中的 Config 和 Secret 可以创建仪表板，对在集群级别收集的所有指标进行查询。 | 用户将能够创建仅保留新 Grafana 仪表板的 Secret/ConfigMap。 |
|
||||
|
||||
|
||||
|
||||
## Grafana 的 RBAC
|
||||
|
||||
对于经过 Kubernetes 认证并可以访问 Rancher Monitoring Chart 部署的 Grafana 服务的任何用户，Rancher 允许他们通过 Rancher Dashboard UI 访问 Grafana。默认情况下，所有能够访问 Grafana 的用户都被赋予 [Viewer](https://grafana.com/docs/grafana/latest/permissions/organization_roles/#viewer-role) 角色，能查看 Rancher 部署的任何默认仪表板。
|
||||
|
||||
但是，如果有需要的话，用户可以选择以 [Admin](https://grafana.com/docs/grafana/latest/permissions/organization_roles/#admin-role) 身份登录 Grafana。Grafana 实例的默认 Admin 用户名和密码是 `admin`/`prom-operator`，但你也可以在部署或升级 Chart 时替换凭证。
|
||||
|
||||
要查看 Grafana UI，请安装 `rancher-monitoring`。然后：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要可视化的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，单击**监控**。
|
||||
1. 点击 **Grafana**。
|
||||
|
||||
<figcaption>Grafana 中的集群计算资源仪表板</figcaption>
|
||||
|
||||
|
||||
<figcaption>Grafana 中的默认仪表板</figcaption>
|
||||
|
||||
+59
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: Monitoring V2 的 Windows 集群支持
|
||||
shortTitle: Windows 支持
|
||||
weight: 5
|
||||
---
|
||||
|
||||
_从 v2.5.8 起可用_
|
||||
|
||||
从 Monitoring V2 14.5.100（Rancher 2.5.8 的默认版本）开始，Monitoring V2 可以部署在 Windows 集群上，并将使用 [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter)（旧名是 `wmi_exporter`）来抓取 Windows 节点的指标。
|
||||
|
||||
|
||||
## 与 Monitoring V1 的对比
|
||||
|
||||
由于命名已根据上游从 `wmi_exporter` 更改为 `windows_exporter`，因此 `windows_exporter` 收集的指标会标记为 `windows_` 而不是 `wmi_`。
|
||||
|
||||
此外，由于主机指标将直接发布到暴露在 windows-exporter Pod 上的端口上，因此 Monitoring V2 for Windows 将不再要求用户在 Windows 主机上保持打开端口 9796。此功能由 `wins` v0.1.0 最近的更改提供，以支持在 Pod 上发布暴露在 hostNetwork 上的端口，这些 Pod 使用 wins 来运行一个有特权的 Windows 二进制文件作为主机进程。
|
||||
|
||||
## 集群要求
|
||||
|
||||
Monitoring V2 for Windows 只能从最低是 `wins` v0.1.0 的 Windows 主机中抓取指标。要完全部署 Monitoring V2 for Windows，你的所有主机都必须满足此要求。
|
||||
|
||||
如果你在 Rancher 2.5.8 中配置新的 RKE1 集群，你的集群应该已经满足此要求。
|
||||
|
||||
### 将现有集群升级到 wins v0.1.0
|
||||
|
||||
如果集群是在 Rancher 2.5.8 之前配置的（即使当前 Rancher 版本是 2.5.8），你将无法成功部署 Monitoring V2 for Windows，除非你将每台主机的 wins 版本升级到 v0.1.0 或以上版本。
|
||||
|
||||
为了方便此次升级，Rancher 2.5.8 发布了一个全新的 Helm Chart，名为 `rancher-wins-upgrader`。
|
||||
|
||||
> **先决条件**：确保已卸载 Monitoring V1 for Windows。
|
||||
|
||||
1. 使用以下覆盖部署 `rancher-wins-upgrader`：
|
||||
```yaml
|
||||
# 通过先前已列入白名单的进程路径
|
||||
# 来引导 win-upgrader 安装，这是因为正常安装路径
|
||||
# c:\\etc\\rancher\\wins\\wins-upgrade.exe 通常不会被列入白名单。
|
||||
# 因此，我们使用 Monitoring V1 之前所用的
|
||||
# 已列入白名单的进程路径。
|
||||
masquerade:
|
||||
enabled: true
|
||||
as: c:\\etc\wmi-exporter\wmi-exporter.exe
|
||||
```
|
||||
:::note 非默认 Windows 前缀路径的注意事项：
|
||||
|
||||
- 如果你使用具有非默认 `win_prefix_path` 的 `cluster.yml` 来设置 RKE 集群，你需要将 `c:\\` 替换为你的前缀路径字段的值来修改 `masquerade.as`。
|
||||
|
||||
- 例如，如果你使用 `win_prefix_path: 'c:\host\opt\'`，则需要设置为 `as: c:\host\opt\etc\wmi-exporter\wmi-exporter.exe`。
|
||||
|
||||
:::
|
||||
|
||||
2. 成功升级所有主机后，请再次使用默认值部署 Helm Chart，以避免与以下设置发生冲突：
|
||||
```yaml
|
||||
masquerade:
|
||||
enabled: false
|
||||
```
|
||||
|
||||
**结果**：主机已准备好安装 Monitoring V2。你可以选择卸载 `rancher-wins-upgrader` Chart，或将其保留在集群中以方便将来升级。
|
||||
|
||||
有关如何使用它的更多信息，请参阅 Chart 的 [README.md](https://github.com/rancher/wins/blob/master/charts/rancher-wins-upgrader/README.md)。
|
||||
+205
@@ -0,0 +1,205 @@
|
||||
---
|
||||
title: NeuVector 集成
|
||||
weight: 22
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
### Rancher 中的 NeuVector 集成
|
||||
|
||||
[NeuVector 5.x](https://open-docs.neuvector.com/) 是一个开源的，以容器为中心的安全应用程序，Rancher 2.6.5 现已集成 NeuVector。NeuVector 在运行时为关键应用程序和数据提供实时的合规、可见和保护功能。NeuVector 提供具有 CIS Benchmark 和漏洞扫描的防火墙、容器进程/文件系统监控和安全审计。有关 Rancher 安全性的更多信息，请参阅[安全文档](../../pages-for-subheaders/rancher-security.md)。
|
||||
|
||||
NeuVector 可以通过 Helm Chart 启用。你可以在**应用 & 应用市场**或 Rancher UI 中的**集群工具**中安装该 Chart。安装 Helm Chart 后，用户可以轻松地[在 Rancher 中部署和管理 NeuVector 集群](https://open-docs.neuvector.com/deploying/rancher#deploy-and-manage-neuvector-through-rancher-apps-marketplace)。
|
||||
|
||||
### 使用 Rancher 安装 NeuVector
|
||||
|
||||
Harvester Helm Chart 用于管理 Rancher 中 NeuVector UI 的访问，用户可以在 Rancher 中直接跳转，然后部署和管理 NeuVector 集群。
|
||||
|
||||
**通过"应用 & 应用市场"导航并安装 NeuVector Chart**：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 在 Clusters 页面上，转到要部署 NeuVector 的集群，然后单击 **Explore**。
|
||||
1. 转到 **应用 & 应用市场 > Charts**，然后从 Chart 仓库中安装 **NeuVector**。
|
||||
1. 不同的集群类型需要不同的容器运行时。配置 Helm Chart 值时，转到**容器运行时**，然后根据集群类型选择运行时。最后，再次单击**安装**。
|
||||
|
||||
以下是一些例子：
|
||||
|
||||
- RKE1：`docker`
|
||||
- K3s 和 RKE2：`k3scontainerd`
|
||||
- AKS：`containerd` 适用于 v1.19 及更高版本
|
||||
- EKS：`docker` 适用于 v1.22 及以下版本；`containerd` 适用于 v1.23 及更高版本
|
||||
- GKE：`containerd`（请参阅 [Google 文档](https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd)了解更多信息）
|
||||
|
||||
:::note
|
||||
|
||||
在安装过程中一次只能选择一个容器运行时引擎。
|
||||
|
||||
:::
|
||||
|
||||
**通过集群工具导航并安装 NeuVector Chart**：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 在 Clusters 页面上，转到要部署 NeuVector 的集群，然后单击 **Explore**。
|
||||
1. 点击左侧导航栏底部的**集群工具**。
|
||||
1. 按照上面的步骤 4 相应地选择你的容器运行时，然后再次单击**安装**。
|
||||
|
||||
### 从 Rancher UI 访问 NeuVector
|
||||
|
||||
1. 导航到安装了 NeuVector 的集群的 Cluster Explorer。在左侧导航栏中，单击 **NeuVector**。
|
||||
1. 单击外部链接以转到 NeuVector UI。选择链接后，用户必须接受`最终用户许可协议`才能访问 NeuVector UI。
|
||||
|
||||
### 从 Rancher UI 卸载 NeuVector
|
||||
|
||||
**通过"应用 & 应用市场"卸载**：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 在**应用 & 应用市场**下，点击**已安装的应用**。
|
||||
1. 在 `cattle-neuvector-system` 下，选择 NeuVector 应用程序（如果需要，还可以选择相关的 CRD），然后单击**删除**。
|
||||
|
||||
**通过集群工具卸载**：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 单击屏幕左下角的**集群工具**，然后单击 NeuVector Chart 下方的垃圾桶图标。如果需要，选择`删除与此应用关联的 CRD`，然后单击**删除**。
|
||||
|
||||
### GitHub 仓库
|
||||
|
||||
NeuVector 项目在[这里](https://github.com/neuvector/neuvector)。
|
||||
|
||||
### 文档
|
||||
|
||||
NeuVector 文档在[这里](https://open-docs.neuvector.com/)。
|
||||
|
||||
### 架构
|
||||
|
||||
NeuVector 安全解决方案包含四种类型的安全容器，分别是 Controller、Enforcer、Manager 和 Scanner。它还提供了一个称为 All-in-One 的特殊容器（主要用于 Docker 原生部署），能将 Controller、Enforcer 和 Manager 功能组合在一个容器中。此外，还有一个 Updater，运行该程序时会更新 CVE 数据库。
|
||||
|
||||
- **Controller**：管理 NeuVector Enforcer 容器；为管理控制台提供 REST API。
|
||||
- **Enforcer**：执行安全策略。
|
||||
- **Manager**：提供一个 web-UI 和 CLI 控制台来管理 NeuVector 平台。
|
||||
- **All-in-One**：包括 Controller、Enforcer 和 Manager。
|
||||
- **Scanner**：对镜像、容器和节点执行漏洞和合规性扫描。
|
||||
- **Updater**：更新 Neuvector 的 CVE 数据库（运行的时候）；重新部署 scanner pod。
|
||||
|
||||
<figcaption>**NeuVector 安全容器：**</figcaption>
|
||||
|
||||
|
||||
<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 组件都是可部署的。
|
||||
|
||||
**_v2.6.7 新功能_**
|
||||
|
||||
你需要为强化集群环境进行额外的配置，如下所示：
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，点击**应用 & 应用市场**。
|
||||
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/>
|
||||
|
||||
**_v2.6.7 新功能_**
|
||||
|
||||
你需要为强化集群环境进行额外的配置。
|
||||
|
||||
> **注意**：你必须更新 RKE2 和 K3s 强化集群中的配置，如下所示。
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 在左侧导航栏中，点击**应用 & 应用市场**。
|
||||
1. 安装（或升级到）NeuVector 版本 `100.0.1+up2.2.2`。
|
||||
|
||||
- 在 **编辑选项** > **其它配置**下，选中复选框来启用 **Pod 安全策略**。请注意，对于 `Manager runAsUser ID`、`Scanner runAsUser ID` 和 `Updater runAsUser ID`，你还必须输入大于 `0` 的值:
|
||||
|
||||
|
||||
|
||||
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 时，不会针对不同的集群类型自动检测容器运行时。要解决此问题，你可以手动指定运行时。
|
||||
|
||||
+112
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: OPA Gatekeeper
|
||||
weight: 16
|
||||
---
|
||||
|
||||
为了确保一致性和合规性，每个组织都需要能够以自动化的方式在环境中定义和执行策略。[OPA（Open Policy Agent）](https://www.openpolicyagent.org/) 是一个策略引擎，用于基于策略控制云原生环境。Rancher 支持在 Kubernetes 集群中启用 OPA Gatekeeper，并且还安装了一些内置的策略定义（也称为约束模板）。
|
||||
|
||||
OPA 提供了一种高级声明性语言，可以让你将策略指定为代码，还能扩展简单的 API，从而减轻策略决策的负担。
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 是一个提供 OPA 和 Kubernetes 集成的项目。OPA Gatekeeper 提供：
|
||||
|
||||
- 一个可扩展的参数化策略库。
|
||||
- 用于实例化策略库的原生 Kubernetes CRD，也称为“约束”。
|
||||
- 用于扩展策略库的原生 Kubernetes CRD，也称为“约束模板”。
|
||||
- 审计功能。
|
||||
|
||||
要了解更多关于 OPA 的信息，请参阅[官方文档](https://www.openpolicyagent.org/docs/latest/)。
|
||||
|
||||
## OPA Gatekeeper 集成的工作原理
|
||||
|
||||
Kubernetes 支持通过准入控制器（准入控制器）webhook 来扩展 API Server 的功能，创建、更新或删除资源时都会调用这些 webhook。Gatekeeper 作为验证 webhook 安装，并执行由 Kubernetes CRD（Custom Resource Definition）定义的策略。除了使用准入控制之外，Gatekeeper 还能审计 Kubernetes 集群中的现有资源，并对违反当前策略的情况进行标记。
|
||||
|
||||
OPA Gatekeeper 由 Rancher 的 Helm system Chart 提供，它安装在名为 `gatekeeper-system` 的命名空间中。
|
||||
|
||||
## 在集群中启用 OPA Gatekeeper
|
||||
|
||||
:::note
|
||||
|
||||
Rancher 2.5 改进了 OPA Gatekeeper 应用。无法从 Rancher 2.4 升级到 Rancher 2.5 中的新版本。如果你在 Rancher 2.4 中安装了 OPA Gatekeeper，则需要在旧 UI 中卸载 OPA Gatekeeper 及其 CRD，然后在 Rancher 2.5 中重新安装它。如需卸载 CRD，请在 kubectl 控制台中运行 `kubectl delete crd configs.config.gatekeeper.sh constrainttemplates.templates.gatekeeper.sh` 命令。
|
||||
|
||||
:::
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
只有管理员和集群所有者才能启用 OPA Gatekeeper。
|
||||
|
||||
:::
|
||||
|
||||
你可以在**应用 & 应用市场**页面安装 OPA Gatekeeper Helm Chart。
|
||||
|
||||
### 启用 OPA Gatekeeper
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面中，转到要启用 OPA Gatekeeper 的集群，然后单击 **Explore**。
|
||||
1. 在左侧导航栏中，点击**应用 & 应用市场**。
|
||||
1. 点击 **Charts** 并点击 **OPA Gatekeeper**。
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**：已将 OPA Gatekeeper 部署到你的 Kubernetes 集群。
|
||||
|
||||
## 约束模板
|
||||
|
||||
[约束模板](https://github.com/open-policy-agent/gatekeeper#constraint-templates)是 Kubernetes 自定义资源，用于定义要由 Gatekeeper 应用的 OPA 策略的架构和 Rego 逻辑。有关 Rego 策略语言的更多信息，请参阅[官方文档](https://www.openpolicyagent.org/docs/latest/policy-language/)。
|
||||
|
||||
启用 OPA Gatekeeper 后，Rancher 默认会安装一些模板。
|
||||
|
||||
要列出集群中安装的约束模板，请转到 OPA Gatekeeper 下的左侧菜单，然后单击**模板**。
|
||||
|
||||
Rancher 还支持通过导入 YAML 定义来创建你自己的约束模板。
|
||||
|
||||
## 创建和配置约束
|
||||
|
||||
[约束](https://github.com/open-policy-agent/gatekeeper#constraints)是 Kubernetes 自定义资源，用于定义要应用约束模板的对象范围。约束模板和约束共同定义一个完整的策略。
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
集群中已启用 OPA Gatekeeper。
|
||||
|
||||
:::
|
||||
|
||||
要列出已安装的约束，请转到 OPA Gatekeeper 下的左侧菜单，然后单击**约束**。
|
||||
|
||||
可以从约束模板创建新的约束。
|
||||
|
||||
Rancher 支持通过使用方便的表单来创建约束，你可以在该表单中输入各种约束字段。
|
||||
|
||||
**以 YAML 文件编辑**选项也可以用于配置约束的 YAML 定义。
|
||||
|
||||
### 使 Rancher 的 System 命名空间不受约束
|
||||
|
||||
创建约束时，请确保该约束不应用于任何 Rancher 或 Kubernetes System 命名空间。如果不排除 System 命名空间，则可能会出现 system 命名空间下的许多资源被标记为违反约束。
|
||||
|
||||
要让约束仅限制用户命名空间，请在约束的**匹配**字段下指定这些命名空间。
|
||||
|
||||
此外，该约束可能会干扰其他 Rancher 功能并拒绝部署系统工作负载。为避免这种情况，请从你的约束中排除所有 Rancher 特定的命名空间。
|
||||
|
||||
## 在集群中实施约束
|
||||
|
||||
如果**执行动作**为 **Deny**，约束会立即启用，并拒绝任何违反策略的请求。默认情况下，执行的值为 **Deny**。
|
||||
|
||||
如果**执行动作** 为 **Dryrun**，违反策略的资源仅会记录在约束的状态字段中。
|
||||
|
||||
要强制执行约束，请使用表单创建约束。在**执行动作**字段中，选择 **Deny**。
|
||||
|
||||
## 集群中的审计和违规
|
||||
|
||||
OPA Gatekeeper 运行定期审计，以检查现有资源是否违反强制执行的约束。你可以在安装 Gatekeeper 时配置审计间隔（默认 300 秒）。
|
||||
|
||||
Gatekeeper 页面上列出了违反已定义的约束的情况。
|
||||
|
||||
此外，你也可以在**约束**页面中找到违反约束的数量。
|
||||
|
||||
每个约束的详细信息视图列出了违反约束的资源的信息。
|
||||
|
||||
## 禁用 Gatekeeper
|
||||
|
||||
1. 导航到集群的仪表板视图。
|
||||
1. 在左侧菜单中，展开集群菜单并单击 **OPA Gatekeeper**。
|
||||
1. 单击 **⋮ > 禁用**。
|
||||
|
||||
**结果**：禁用 OPA Gatekeeper 后，所有约束模板和约束也将被删除。
|
||||
|
||||
Reference in New Issue
Block a user